アジャイルとウォーターフォールの対比について話題になるのは、いつものことな感じがしますが、今回はウォーターフォールを支持する側の意見がはっきりと形になっているのがちょっと違うなと思いました。とは言え、読んでいて違和感を感じるところがないこともないので、僕の考えをまとめてみます。
制約理論とアジャイル
制約理論というのは、いくつかのシンプルなルールの元に作られている理論です。ソフトウェアの世界だと、制約理論の中のCCPMぐらいしか興味を持たれているようなものがない気はするんですが、ドラム・バッファ・ロープ周辺のいろいろなアイディアもソフトウェア工学、コンピュータ科学の両方に応用できると思っています。ボトルネック以外改善しても意味ないよというのもそうですし、製造工程のボトルネックをすべて取り払っていくと、最終的には製造工程の外の市場に製造数の制約が移っていくよ、とかですね。日本ではトヨタ生産方式の方が通りがいいのかもしれませんが、個人的には制約理論の言葉を使ってアジャイルソフトウェア開発を再定義するというのはありじゃないかと思っています。
まず、ウォーターフォール型開発の前提としては、仕様が安定している、変化がないというものが上げられています。そして、オリジナルのものは置いといて、一般にコモンセンスとして伝わっているウォーターフォールでは、それなりに正しい計画と設計がなければ、後工程でどうがんばってもリカバリーには限度があります。この工程のアウトプットがダイレクトに結果に影響を与えるという点で、これはどう見てもボトルネックです。現物がない状態での未来予測、これはとてつもなく難しく、人類の能力を超えていると思います。下記のまとめが良いエクササイズになると思います。
仕様書って、この例の「つまらない説明」に近いと思うんですよ。で、完成品のゲームが想像できるか。顧客にとっては、この状態でOKと判定しないといけないという難しい知能ゲームです。続編ものなら、1作目を見て、差分の仕様を文章でもらえばより具体的に想像できますよね。これがアジャイルソフトウェア開発がもたらす最大の効能ですよね。想像の難しさ、人間の脳力というボトルネックにかかる負荷を下げたのがアジャイルソフトウェア開発と言ってもいい気がします。
僕は昨年は完全にボトルネックが開発の外にある状態で仕事ができたのですごい楽しかったです。制約理論でいうところの、制約が市場にうつりきった状態ですね。日本の製造業の状況も一緒ですね。日本の製造業が売っている製品って、もう買う人にはほぼ渡りきっている状態です。なかなか壊れないし。そうなると、新しい機能をつけたり、付加価値をつけて「市場を作り出す」ことが大事になります。市場を作って受け入れる余地ができて、初めてラインが動かせます。ユーザと同じミーティングに参加し、ユーザと席をならべて業務をじっくり観察し、ユーザのためにいろいろ機能を考えて、今は業務は回っているんだけど、ここを改善したらもっと良くなるぞ、という機能を開発して提案してどんどん使ってもらう。もちろん、使ってもらってない機能もあって無駄があったと言えば無駄なんですが、それでいいんです。開発側がボトルネックじゃないんですから。ある意味アジャイルソフトウェア開発の先をちら見した気がしました。
ちなみに、そういう状況であれば別にウォーターフォールでもいいんですよね。フィードバックを適切に返せるユーザもいない。市場もこれから作る。ユーザへのインパクトを考えてきちんと製品を作りこんで市場に出す。RFCな通信プロトコルをかっちり実装したサーバ製品なんかは特にそうですね。
実はウォーターフォールにとって最大のボトルネックは仕様策定ではない
そんなにそこがボトルネックなら、なぜ改善しないのか。もちろんそこはいろいろ改善されているという話は聞きます。フレームワークやツールを整備して、いろいろ平準化したりしていると。ボトルネックがボトルネックのまま放置されることはないはず。実は、ウォーターフォールの世界から見たボトルネックはそこではなくて、予算獲得というその前段階。予算獲得というインプットの制約をもろに受けます。つまり、製造業でいうところの、材料がまったくなく、材料が来た時だけラインが動くという逆の制約状態です。
アジャイルが日本の商習慣に合わないという話の9割は、予算獲得がまず必要という話です。なので、予算を出してもらうための計画づくりをみんなでやっているという状態です。予算獲得とは言うものの、基本的には「額を減らす」というフォースがその場を支配しています。金額を減らすために、いろいろ交渉し、システムインテグレータの会社に仕事をお願いする。システムインテグレータは保険屋的な存在なので、何倍かのマージンを取ってシステムを開発します。ユーザにとってベストな状態は、ギリギリまで予算を絞り、デスマ炎上した状態です。そうすると、今までギリギリだった開発人員が潤沢になって、なんとか開発を完了させようとします。
そのような状況なので、開発側も余裕のない人数で開発を行っています。その状況では「2人月開発余計にかかるけど、ユーザ側の工数を10人月減らすような機能を思いついた！」となっても、それが開発計画に組み入れられることはあまりないでしょう。むしろ、「ユーザ側の工数が10人月増えるかもしれないけど予算足りないから、スコープ見直しでこの機能落とすか」という会話がされることの方が多いのではないでしょうか？僕はそういう場にいたことはあります。
アジャイル開発がもっと広まって欲しいという人の気持ち
アジャイル開発は、前提条件からして仕様が未確定ほど(ウォーターフォール開発よりも)得意というものです。仕様が未確定というのは、ビジネス側代表がボヤボヤしててユーザの意見の取りまとめができてない、ということではなくて(というのもあるかもしれないけど)、そもそもまだ誰もチャレンジしてないウェブサービス、まだ誰も挑戦してない新しい業務フローを支える社内システム、そういうリスクを取ってチャレンジしたいビジネス側の人たちと一緒に仕事したいということですよね。
つまり「アジャイルソフトウェア開発がもっと広まって欲しい」というのは、「ソフトウェアの価格を値切るのにフォーカスするのではなく、積極投資でソフトウェアでビジネスチャンスを広げようとする企業が増えて欲しい」ということと同義と言えるかと思います。
ちなみに、ややこしくしているのがDevOpsというやつで、1日10回とか20回とか、そういう数字が一人歩きして「そんなのいらん」と言われている状態だと思います。アジャイルにも流派がいろいろあって、「おっし、効果があるならとことんやったろじゃん」というのが過激派アジャイラーのケント・ベックが提唱するエクストリームプログラミング派です。少なくとも、要求の変化も一週間の枠が終わるまでは一切受け付けない、というスクラムであればそんなことは言わないかと。一部過激派の犯行です。
「AIに環境を合わせた企業が勝つ」というのは、今後起こりそう。
— ところてん (@tokoroten) June 27, 2016
業務フローにツールを合わせて爆死した日本企業の死体を見るに。
例えば、ロボット農業にしても、ロボット農業が働きやすい広い平地をどれだけ確保できるか、みたいな勝負になるんじゃないかと。日本の小作農の細切れの土地じゃ無理
これはあるよなぁ
— kの人 (@kyokuheki) June 28, 2016
ルンバが働きやすい室内環境作れる人と、そうでない人ですごい差がある。
https://t.co/iu3UbUsLEl
AIや機械学習をシステムに組み込んでいくには仕事のやり方を変えていく必要があります。実際に実データを収集し、それを分析し、それを業務フローの中で活かせるかどうかというのは、なかなかトップダウンで仕様化はしにくく、実データの質や量とにらめっこしつつ最適解を見つけて適用し・・・というフローが大切になります。そして、仕組みを入れたらまたモデルの質が変化し、それを最大限に活用するために・・・というイテレーションになります。データ分析側だけではなく、それを活用する側もAIの恩恵が受けられるように、適切にログを出すように改良したりと日々手を入れていく必要があります。「商習慣が変わらないからウォーターフォールしかムリ」といってしまうのは、このように業界全体が新しい技術を取り入れて進歩していこうという流れの中で、後ろ向きにとどまることを選択していることと同義です。
アジャイル開発がもっと広まって欲しいという人の焦り
@tokorotenのツイートにもあるように、このような事態になることは、一度や二度ではありません。何度もいろいろな日本の業界で起きていることです。全体最適が得意じゃない。ITが進歩していくというのは既定路線でした。今でこそ、デスクトップコンピュータのCPUというごく一部に限れば、進歩は遅れているように見えますが、さまざまな技術の進歩を掛け算していけば、まだまだいろいろなところが伸びていて、トータルでは処理速度はまだ上がっています。GeForce GTX 1080欲しいですよね。ですが、上記のレポートにあるように、日本はどうもこのような進歩を自分のものとして取り込むのが得意じゃないんですよね。
僕なんかは個人的には英語圏で生活したこともあるし、いろいろアウトプットも含めて勉強はし続けているので、日本が沈んでもなんとかなるとは思っています。子供がアメリカ国籍なので、21歳になったらビザとかなくてもアメリカ住めますしね。とはいえ、多くの人が同じように努力をして「自分は大丈夫」と思っているわけではありません。僕も、自分以外の人にも元気に生き残って欲しいとは思いますが、そんなにタイムリミットもないし、放っておけば良くなるというものではないんですよね。
海外は、多重構造がなかった(と思われる)ので、アジャイルが始まって数年で、「アジャイルやりたいなぁ」と思ってた開発者が偉くなって適用が増える流れがあったけど、日本は開発者が偉くなって意思決定側に回らないので、増えなかった。新陳代謝もないし新しい物も入らないという仮説。
— 渋川よしき (@shibu_jp) June 25, 2016
そういう意味では、今後の様々なアジャイラー側の活動が実を結んでマネジメント側が認めてアジャイル開発が普及したとしても、「日本は開発者が持った意思・希望が尊重されるのに時間だけでは解決できない」という問題は今のままでは残ったままなんだよね。そこは悩ましい。
— 渋川よしき (@shibu_jp) June 25, 2016
15年前、別に日本は遅れてなかったんですよね。長瀬さん、平鍋さんのお二人の努力によって、洋書のXP本が出てからわずか1年遅れで日本語版が出て、なおかつ何度もケント・ベック、マーチン・ファウラーなどの大物が何度も日本にやってきて(長瀬さんが連れて来て)・・・・みんなで英語の情報を読み漁り、勉強会や雑誌などでシェアをして広めたり・・・しかし日本ではそれに影響されることもなく、なおかつ情報をアップデートしない人も多く、世界との差は広がるばかり。
その後僕は海外に行って、日本に帰ってきて、業界全体を云々は僕の手に負えるものではないし、せめて受信(翻訳とか)一辺倒ではなくて、発信もしていけるようになって、日本が滅びても僕個人は滅びないようにしたい(世界最速でMithril本をリリースした話にも書きましたが)な、ぐらいの気持ちで日々過ごしています。
アジャイルの適用は「組織が新しい物を取り入れる」ケーススタディの１つでしかありません。業界が新しい波に乗るというのをやろうとしない、というのが続けばアジャイル以外の新しいものもすべて取りこぼすことになりかねない。少なくとも、そういう焦りを感じるのもよく分かります。今後も、新しい技術が出てくるたびに「このままじゃ日本のソフトウェアはダメになる」という気持ちを持っている人が、その技術を旗印に「組織を変える」活動をしていくと思います。もちろん、事業会社であれば自分でハンドリングしやすくするために、すでにウォーターフォールではないプロセスで業務を日々回していると思います。そういう会社に転職するのが楽です。でも、そうじゃないんだ。今の会社を改善したい、日本の商習慣を変えていきたいんだという人もいます。そういう気持ちを持っている人に比べたら、僕は冷たい人間だな、とは思います。とはいっても、そういう人の気持ちを折る側ではなく、応援する側には付きたいと思います。
まあ大規模開発がウォーターフォール中心というのは、飲み会で「新潟県のいちばんの名産品は公共事業」と言って笑いを取るようなもんで、外人向けのジョークのネタにはなる気がします。
ウォーターフォールでも今後は2or3フェーズ開発に変わるかも
@shibu_jp 工事会計基準の導入は、ソフトウェアでは比較的新しくて導入が進んでないかも。とはいえ10年位前には言われ始めてたけどw
— MURAOKA Taro (@kaoriya) June 20, 2016
調べてみたら、2009年ぐらいからプロジェクト進行の会計方法が変わるって書かれていますね。ウォーターフォールのアジャイルに対する反論として、「現場ですり合わせてなんとか回している」というコメントもありました。ただし、工事会計基準だか工事進行基準となると、プロセスの成果物をあわせる必要が出てくるため、後工程でやりくりできなくなります。そうなると、精度を上げる必要があるはずですが、精度を上げるにはプロトタイプで十分に検証するしかないでしょう。
人の命をあずかる輸送機器(自動車ともいう)の制御のソフトウェアは、MATLAB等でモデルを作って検証しつくしたところで、それを仕様化して発注しているはず。ロケット等も、実機開発とは別にリサーチの予算をしっかりとって、試行錯誤を何度も繰り返して方向性を決めているはずです。会計上、契約を結ぶまではソフトウェアを開発しちゃいけないはずなので、精度を上げるには、「予算をとって」設計するしかないですよね。そこをけちって工事会計基準を適用したら事故る未来しか見えないですし・・・
