日本でアジャイルはツライ。だとしたらこれはどう？あるいはウォーターフォールとアジャイルの狭間にて
★日本でのアジャイル
日本にアジャイルが紹介されて20年近くたった。webサービスやアプリ開発では標準的な開発手法になっていると思う。一方で、エンタープライズ領域（大企業で基幹システムなどを作るプロジェクト）でアジャイルを適用しようとして大失敗した、という話はたくさん聞く。そもそも「アジャイルなにそれ？」という大企業も多い。
これはアジャイル発祥の地である、アメリカの状況とはかなりギャップがある。
ケンブリッジのアメリカ支社に、長くアメリカ企業でシステム部門のマネージャーをしていた社員がいる。彼に「ねえ、日本ではアジャイルがうまく導入できていないんだけど、アメリカではどうなの？」と聞くと、「え？普通にもうアジャイルがスタンダードですよ」という答えが返ってきた。ですよねぇ。
日本でアジャイル開発がうまくいかないのは、商慣習がアジャイル向きではないからだ。（どの商慣習が合わないのかは、以下で説明する）
だからアジャイルでプロジェクトをやるなら商慣習ごと変えるべきだが、プロジェクト関係者にその権限がなかったりして、無理なことが多い。偉い人になぜその商慣習を変えるべきなのかを説明しても全く理解してくれなかったり・・。
これを読んでいる人がアジャイル開発についてどれくらい詳しいか分からないので、雑に説明しておこう。
アジャイル開発はそれまでの開発（ウォーターフォール）へのアンチテーゼだ。
ウォーターフォールは各工程で完璧な成果物を作り、積み重ねていく。だが実際に完璧な成果物は作れないので、稼働直前になって、「そもそもこんな機能を求めていなかった！」みたいなことになる。その際の手戻りが大きい。
それに対してアジャイルは、小さく区切った機能ごとに「設計⇒開発⇒テスト⇒ユーザーレビュー」を高速回転していく。2週ごとに小さな機能が追加されていくイメージだ。
ウォーターフォールと同様に人間は完璧な仕事はできないのだが、傷が大きくなる前にユーザーに見せ、フィードバックを受けて修正するので、大失敗を防げるし、大失敗を防ぐための管理工数も少なくて済む。とされている。
★CambridgeRADはウォーターフォールとアジャイルの中間
そんなこんなで、日本企業、特に老舗大企業では、アジャイルはほとんど使われていない。ほとんどの会社でシステム開発といったら、ゴリゴリのウォータフォールを指す。
ところで、僕らケンブリッジはアメリカ東海岸で生まれたCambridgeRADという方法論でプロジェクトを成功に導いている。いま良く売れている「システムを作らせる技術」も、CambridgeRADを噛み砕いた本といっていい。
その詳細は「分厚い本を読んでください」と言うしかないのだが、極めてざっくりいうと、CambridgeRADはウォーターフォールとアジャイルの中間的な方法論である。
ただし「ウォーターフォールとアジャイルのいいとこ取りをしてCambridgeRADを作った」というストーリーではない。CambridgeRADができたのはおおよそ1990年ぐらい。アジャイルソフトウェア開発宣言が書かれたのが2001年なので、実はCambridgeRADの方が古いのだ。
僕としては、
「ケンブリッジはCambridgeRADという方法論を、いわばガラパゴス的に進化させてきた。一方で世の中ではアジャイルという、より柔軟な方法が提唱され、広がっていった。20年たって改めて俯瞰すると、CambridgeRADはアジャイルと旧来型のウォーターフォールの中間くらいに（結果として）位置していた。」
と理解している。
そしてこのCambridgeRADの中間的な塩梅が、日本の大企業、中堅企業で基幹システムを作る時にちょうどいいのだ。ウォータフォールの硬直的な弱点をうまくフォローしつつ、システム内製力が低くて外注するケースや、品質や納期を非常に重視するといった、日本企業の商慣習にも、きちんと応えられる。
その中間的な塩梅について、いくつかの切り口で、このブログの残りを使って説明していこう。
ピュアなウォータフォールでは、基本的には1度に完成品を稼働させる。
一方アジャイルは2週間単位で少しずつ機能を追加していく。究極の多段階稼働だ。
その中間であるCambridgeRADでは通常3段階くらいの段階稼働とする。これはアジャイルに比べると全く過激な作戦ではないが、これでもウォータフォールに慣れたお客さんに話すと拒否感を示される事が多い。「プロジェクトリスクを下げるためにも、なるべく段階的に、大事なものから稼働させていきましょう」と言っても。
ウォータフォールは、日本の製造業で大事にしている「自工程完結」という哲学と近い。
自工程完結とは、自分が担当している工程で完璧な品質を目指す姿勢だ。もし次の工程に微妙な品質の成果物を渡してしまうと、問題が発覚した後で、修正工数が大きくなるからだ。（1つの部品だけだとしても、部品が壊れている自動車には誰も乗りたくないし、リコールするには莫大なコストがかかる）
したがってウォータフォールでは完璧な要件定義書、完璧な設計書を目指す。ただ自動車を1万台作るのと違って、初めて書く要件定義書でミスゼロは達成できない。だから盛大な手戻りが発生してしまうんだけどね。
一方でアジャイルは中間成果物は重視しない。作らなかったり、保守のために後追いで作ったりする。そんなものより動くプログラムを作ったほうがいい、という感覚。
CambridgeRADでは中間成果物を結構作る。大企業で大規模なシステムを作るためには最低限の中間成果物を作っていかないと、品質が上がらないからだ。
だが、完璧は目指さない。無理だから。その代わりに問題があったら次の工程で判明するような仕掛けを組み込む（次のプロトタイピングもその1つ）。ウォータフォールのように稼働直前に問題が発覚するのは最悪だからね・・。
ウォータフォールにはプロトタイピングという考え方がない。これは単に、昔は気軽にプロトタイプ作るための技術が出揃っていなかったことの名残だろう。
一方でアジャイルは2週に1回新しい機能をリリースするのだから、そのたびにプロトタイピングするのと同じだ。
CambridgeRADではそれほど頻繁ではないが、全工程でたいてい2回、プロトタイピングセッションを行う。システム機能のチェックというよりはむしろ「想定どおりの業務が回るか？」のチェックを一番重視しているので、「BPP：ビジネスプロセスプロトタイピング」と呼んでいる。（BPPのやり方も「システムを作らせる技術」に詳しく書いた）
ウォータフォールでは意思決定プロセスとか、意思決定者について深く考慮されていないように思う。その組織の一般論に従うというか。
結果として「要件定義書にハンコが7個並ぶ」みたいになり、誰が決めたのか不明確（総無責任体制）になりがちだ。
総無責任体制を避け、スピードを上げるため、アジャイルではPO（プロダクトオーナー）という役割を決め、その人がすべてを決定する。
だが、ビジネスがシステムに求めるものを理解し、何にどれくらいお金をかけるべきか判断でき、技術のことも（ある程度は）理解している。そんな完璧超人、あなたの会社にいますか？
いたとしても日本企業ではそういう人が全権を握ることが許されないので、やはりPOにはなりきれない。
CambridgeRADでは「関係者をなるべく1箇所に集めて、一気にコンセンサスを作る」というやり方で物事を進めようとする。誰かの独裁でもなく、ゆるゆるとハンコを押していくのでもなく、会議を重視する。ぼくらが20年以上前から、ファシリテーション力をひたすら磨いてきたのはこのためだ。
日本では社員のクビを切れない。だから「システム開発が佳境な時に、必要な分だけ社員を雇う」という柔軟性は日本企業にとっては夢でしかない。結果として日本企業はエンジニアを抱えたがらない。
そのためシステムは内製ではなく外注するのがスタンダードだ。情報システム部はあるが、そこにいる社員の仕事はシステム構築ではなくシステム購買だったりする。
そして外部に発注する以上、徹底してリスクを避けるために、請負契約が主流となる。「1億でコレを全部作ってください。それ以上は何があっても払いませんよ」という。
請負契約の問題を書き始めるとブログ3本分くらいになりそうなのでここでは避けるが、まあ、ほんと、システム構築の根深い問題の多くが請負契約から生じている。
だが、アジャイルは外注とは徹底的に相性が悪い。根本思想が合わない。「請負は成果物をコミットさせるが、アジャイルでは最大効率でシステム構築をすることを信じてください」みたいなギャップがあるからだ（分かる人にしか分からない説明になってしまったが、これまた話し始めると長いので・・）
アジャイルは内製でやるしかない。でも日本企業は内製力が弱い。これが日本でアジャイルをうまく適用できない大きな要因になっている。
CambridgeRADでは「プロジェクト全体ではなく、フェーズごとに成果物をコミットする」という少し独特な方法をつかう。全リスクをシステム構築業者が背負うのでもなく、全リスクを発注者が背負うのでもない。リスクを互いにシェアするので、「結果としてプロジェクトがスムーズに進まないと誰もが損するので、協力するしかない」という状態を作れる。僕らが「会社の立場を超えたOne Team」を作るのにこだわるのも、このあたりが背景にある。
などなど、長くなってきたのでそろそろやめるが、「CambridgeRADはウォーターフォールとアジャイルの中間」と書いたのが、なんとなくイメージしてもらえるだろうか？
これがいい塩梅だからこそ、
・日本の硬めの大企業でも、
・内製前提ではなくても、
・ミッションクリティカルなシステムでも、
・納期やコスト制約が厳しくても、
ガチガチなウォータフォールの呪縛から逃れることができている。
「ウチの会社にアジャイルなんてとんでもない！」という方も、ウォータフォールの硬直性にうんざりしているならば、CambridgeRADについてもう少し学んで見ませんか。別に全面的に取り入れなくても、つまみ食い的に参考にしてもらえることも多いと思います。
詳しくはこの本で！