2018年8月から2019年1月末までの6ヶ月間、週3日ほど愛知県（名古屋市、豊田市）にソフトウェア開発におけるアジャイル/スクラム開発手法のコーチングという形で、コンサルティングの仕事を請け、なんとか無事完了した。
タイトルが指すところの”失敗するプロジェクト”とは、このプロジェクトのことではない。失敗はしていない。ちゃんと現実を意識しスクラムをマスターしてもらうことができたと自負している。なのでこのタイトルの指す”失敗するプロジェクト”とは直近で私が携わったプロジェクトのことではなく、お隣さんのプロジェクトだったり、失敗に向かっている最中にお声がけいただいてなんとかしてくれと言われ中を覗いてみたら手遅れお手上げだったのでお断りしたもの、などのプロジェクトのことである。
『当たらない予測』が『計画』という形で『約束』と化す
計画駆動開発（通称 ウォーターフォール型開発）は今も多くのソフトウェア開発の現場で用いられている。これが手法として問題あることは各所で言われて随分となるが、それでもまだまだ現役の手法である。
最初に、どんなものを作るか/どのように作るか、を日程に落とし込んだ計画を作成する。このときに必要な人員数（予算）や日数を算出し、お客様と合意する。「こんな機能が欲しい」「こんな感じの機能は要りますか？」と互いに話しながら、希望の予算・期限内に収まるように見積りと計画を作り、契約書に盛り込んでいく。実際にプログラムコードを書く前に「機能」「納期」が決まるのである。
そして先にどこかの『上流コンサルタント』と称する方々によってシステム全体の設計・仕様が決められてしまった状態で、コードを書くプログラマに渡される。ん？そう、上流コンサルタントさんは、実際にはコードを書かない。なのに日数が見積もられている。「この機能は2人/日です（2人なら1日、1人なら2日、という意味）」なんて感じにだ。
そう、おかしいよな？プログラマの能力は均質ではない。とてつもなく速く作り上げてしまう人もいればそうでない人もいる。いや、もうすでに仕様も設計も決められてしまっている状態では速く作れるプログラマも速さが出せないので、結果的に均質化されていく、という悲劇が起こるので、そこは問題ないかもしれない。
しかし、その「この機能は2人/日です」という見積りの根拠はなんだろうか？「ステップ数がこれくらいになるはずなので〜」とか「以前の似た機能ではこれくらいだったので〜」とか一応根拠っぽいものは示してくるものの、「実際に誰（どのような能力を持った人）が作るのか」という変数が決まらないまま見積られた数字にはさほどの意味はない。作る本人ですら「作ってみなければどれくらい時間がかかるか事前に予測することは難しい」となるのにだ。しかしこうしたプロジェクトではこうした見積りが意味を持っているように扱われてしまう。組み入れなければならない情報を無視した見積りの通りに事が運ぶほど現実は甘くない。こうして悲劇の序章の幕が上がる。
そして最初に全ての要望を出し切ったつもりでも現実にはまだ出しきれていなかった、ということは当たり前に起こる。ヒトは、まだ見ぬ形のない状態で完成を想像できるほどまだ進化をしきれてはいない。ましてや大規模なシステムであればよりその難易度は増すので、完成を完璧に近い状態で事前に想像することなどもはや不可能である。
最初に「こういうものを作りますよ」「うん」と互いに合意したはずなのに、完成したシステムを渡されて「え？こんなの違う」「いえ、これが欲しいとおっしゃってました」と、言った/言わないの泥のかけ合いが始まる。それが、泥んこ遊びのように楽しかったら良いのだが、ご想像の通り全く楽しくない。大金がかかってんだ、業務が滞って被害が拡大してんだ、一体どうしてくれるんだあー、という感じで展開されていく大人の泥仕合の中では参加者誰もが不幸な目に遭う。
問題は何なのか？間違っているのは何か？ソフトウェアの開発手法として、「全てを最初に計画してしまって、その後は次の工程に引き継いでいきながら、そして基本的に工程上の戻りは認めない」という手法そのものに問題があるのである。そこで前提とされているもののいくつかが間違っている。
未来は予測できない。予測が当たったとしたらそれは『まぐれ』である。
まずは、「未来を予測することができる。予測できないのは予測能力が未熟だからである」という間違った前提である。予測する能力は確かに向上はする。しかしそれが大規模で長期にかかるソフトウェアシステムの構築の計画を十分正確に作成できるほどまでには向上しない。規模が大きくなるほど不確実性が増大する。未来を予測できないのは予測能力が未熟だからではあるが、それほどまでに増大した不確実性を前にして未来を予測できるまでに予測能力は向上はしない。人の能力をもってすれば未来を予測できるという錯覚が幻想を抱かせてしまう。
そして次の間違った前提は「人は自分が欲しいもの・必要と思っているものを十分理解している」というものである。人は、形になって目の前に差し出されて触って使ってみるまで、自分が本当に必要なものに気付けない。自分は自分の欲しいものを知っているというものまた錯覚であり幻想である。
そして次の間違った前提は「ソフトウェア開発能力は測定可能で、その測定された能力値が同じであれば誰が作ってもだいたい一緒」というものである。プログラミング能力自体はなんらかの基準を設けた評価によって一見、測定可能と思えるが、しかしその評価は使い物になるようなものではない。「この能力評価であればこの機能を作るのに2人/日でいける」という見積りの根拠となるようなものではない。システムで用いられる技術的アーキテクチャによっても左右されてしまう上に、その人がどのような開発環境を与えられるのかによっても、構成されるチームメンバーによっても変わってくるのに、そこまで厳密にプログラミング能力を算出することは不可能である。
であれば、一体どうすればいいのか？
現実を基に不確実性に迅速に対応する手法
そう、「将来を予測できなくても良い」「欲しいものが最初からわからなくても良い」「開発者の厳密な開発能力がわからなくても良い」という開発手法があれば良い。なんだか夢のような話じゃないか。しかしそれらを目指したのがアジャイル開発手法である。
つづく。
