アジャイル開発成功の鍵：実装の合理化手段と専門知識
犬小屋のようなものではなく、高層ビルや航空機といった複雑な工学構築物を想像してみよう。複雑であるだけでなく、誰も見たことのないもの、例えばある種の「惑星探査機」だとしよう。そういうものを開発するプロジェクトは「プロトタイピング」を旨として進行する。複雑な制約を満たすデザインを事前にまとめ、試作して動作確認してデザインを修正することを繰り返すやり方だ。
本稿のテーマである業務システム（企業向け基幹システム）も、複雑さや規模を考えれば高層ビルや航空機や惑星探査機と変わらない。ところがその開発はこれまで、要件定義、基本設計、詳細設計、実装、テストといった、滝のように一方向へ進むばかりで後戻りのないウォーターフォール方式でなされてきた。こうした構築物のデザインの妥当性は、実際に使ってみるまで分からない。ところがウォーターフォール方式では、その検証が一度しかなされない。必然的に多くのプロジェクトが、テストと作り替えが延々に続くデスマーチに陥った。
ではなぜ業務システム開発はプロトタイピング方式ではなく、不合理とも思えるウォーターフォール方式でなされてきたのだろう。単純な話で、実装に手間暇がかかり過ぎていたからだ。膨大な数のプログラムを人海戦術で組み立てることでしか業務システムは完成しない。そうである限りプロトタイピングなどやりようがなかったのである。
そこに登場したのが「アジャイル手法」だった。ソフトウェアを小さめのブロックに分割して、1～2週間のイテレーション（反復）で実装することを繰り返すやり方だ。実際の動きを確認しながら仕様策定を進められるので、業務システム開発にも有効だろうと期待された。
しかし、業務システムのように複雑で巨大なソフトウェアを扱うアジャイル手法の問題は、すぐに明らかになった。高層ビルは「住みやすい部屋の集積」ではないし、航空機は「いい感じに機能する部品の集積」ではないからだ。イテレーション内でプログラミング可能な小さなブロックを切り出し、それぞれの仕様評価を厳密に実施したとしても、ブロックの集積が業務システム全体のデザインとして整合的にまとまる保証はない。
ローコード開発技術のような実装合理化の工夫がこの問題を解決する。これによって、それまでプログラマーが1週間かけて手組みしていたソフトウェアのまとまりが、数時間で出来上がってしまうこともある。これによって「小さなブロック単位」ではなく「システム全体」をイテレーションで扱えるようになる。「業務システムのアジャイル開発」が名実ともに実施可能になったということだ。
一方、ここに至って明らかになったのは、要件定義や基本設計といった「上流工程」の重要性だった。いくらプロトタイピングが可能になったとはいえ、素人が試作を繰り返すことで「的確にデザインされた惑星探査機」が手に入るわけではない。対象分野についての専門性を持つ技術者の関与がなければ、プロトタイピングを延々と繰り返してもうまくいかない。特に大規模ソフトウェアのアジャイル開発は「実装の合理化手段」だけでなく、「その分野の専門性」とセットになって初めて生きてくるものである。第1回ではそんなことを説明した。
「工期」は変わらず「仕様の妥当性」が向上する
実装合理化によって開発工数の削減を期待できるが、実際どの程度なのだろう。筆者らの実感としては、例えば月平均10人で12カ月（120人月）かけていた案件が3人で12カ月（36人月）で賄えるようになる。1人が練達のチーフエンジニアで、2人が若手の補佐要員といったイメージだ。従来はプログラミングに手間がかかり過ぎていたので、そのための専任要員を抱えざるを得なかった。しかし実装の生産性が桁違いに向上したおかげで、設計者自身が実装を担えるようになる。自分が設計して自分で実装するのだから効率が悪いはずがない。
「3人で12カ月」が可能であれば「12人で3カ月」でも可能ではないかといった意見があるかもしれない。しかし、この算術の実効性はとっくに否定されている（『人月の神話』ブルックス,1975）。人員の追加に伴ってさまざまなコストが急増するからなのだが、何よりも「実装の合理化による速度向上効果」が、プロトタイピングの繰り返しによって帳消しにされるからだ。プロトタイピングとは「不適切な設計」を（ある程度は）認めることであって、フィードバックによる微調整を繰り返す過程で、設計はようやく妥当なものに近づいてゆく。
つまり、工期は変わらないが、仕様の的確さが向上するということだ。これはユーザー企業にとって計り知れない恩恵であろう。何しろこれまでは技術者たちが不眠不休で完成させてくれたが、何だか使えないシステムのオンパレードだったからだ。ユーザー企業の立場になって考えてみれば、「早く完成させる」よりは「効果的なシステム仕様を確立する」ことの方が優先度は高い。システムが「適切な仕様」を備えているからこそ「工期」を検討する意義がある。使えないシステムが納期通りに完成しても意味はない。
前回記事でも述べたように、これはシステム開発におけるボトルネック（律速過程）が、「プログラミング」ではなかったということだ。本当のボトルネックは「仕様策定」にある。プログラミングはものすごく手間がかかるが故に注目されがちなのだが、それが合理化されても仕様策定の難しさは変わらない。
それにしても「工期が変わらず工数が減る」という変化には、開発者側にとって大きなインパクトがある。例えば10人で12カ月（120人月）かかった案件が3人で12カ月（36人月）で賄えるのであれば、84人月分の稼ぎネタが消えることになる。プロジェクトに起用された3人以外の7人が、つまり従来の7割の要員が仕事にあぶれるということでもある。この要員の激減といっていい事態に、開発業者や技術者は備えなければならない。
