TriTry

ソフトウェア開発手法として知られるアジャイルとウォーターフォール。どちらが優れているかを論じる前に大切なのは、開発プロジェクトの規模やマネージャーの特性によって向き不向きが異なるという視点です。本稿ではまず開発規模、次にマネージャーのタイプから両者を整理し、最後にマンガ「キングダム」の登場人物になぞらえて考えてみます。

開発規模が小さく、かつ要件が頻繁に変わるプロジェクトではアジャイル型が適しています。顧客のフィードバックを素早く取り込みながら進められるため、途中で要件が揺れても対応しやすいのが特徴です。ここで「小規模」の目安は内部結合テストが３か所未満であること。結合ポイントが少なければ、ひとりのマネージャーが全体を感覚的に把握しやすくなります。

一方で、多機能かつ複数チームでの並行開発が必要な大規模プロジェクトではウォーターフォール型が適しています。要件定義から設計、実装、テストまでを段階的に計画し、チーム間の調整を明確にして進めることで混乱を避けられます。結合テスト箇所が３か所以上になると、アジャイルの感覚だけでは見切れない場合が多いためです。

これはよく言われている内容ですね。

マネージャーのタイプには大きく二種類あります。感覚的なものとその逆。

開発を「感覚的」に進行させ、細かな兆しを捉えて即座に対応するのが得意なマネージャーはアジャイル志向です。現場に入り込みつつ、野生的な勘を持つサブリーダークラスのメンバーを集めることで、規模が大きくなっても迅速な調整が可能になります。
この「野生の勘」にも、言語化しづらいながらもいくつかの共通するパターンが存在します。たとえば、進捗の停滞を肌感覚で察知したり、仕様変更の兆しを顧客の表情から読み取ったりといった直感的な判断です。こうした感覚を共有できるサブリーダーが集まれば、チーム全体としての反応速度が高まり、アジャイル型の開発でも安定した成果を出すことが可能になります。

逆に、綿密な計画を立て、報告や事象を基に管理しながら進めるのが得意なマネージャーはウォーターフォール志向です。要件変更を想定してあらかじめ設計に盛り込み、事象が起きたときにはその原因を分析し、波及を防ぐ一手先の対策を練ります。思考に時間をかけるため現場には常駐せず、信頼できる要員にコントロールを委譲するスタイルが見られます。

マンガ「キングダム」を例に、両タイプを登場人物に重ね合わせてみます。今更キングダムなのは、筆者が今更はまっているからです。。。

感覚で感じ取るタイプの将軍である廉頗、麃公はアジャイル型です。彼らは進捗で気になる点があれば即座に修正を指示し、敵の動きや味方の表情から最適な一手を導きます。まさにプレイングマネージャーとして現場感覚を重視しながら、柔軟に対応する姿勢が共通しています。

一方、李牧や昌平君、王毅は綿密に策を巡らせるタイプの将軍で、ウォーターフォール型に相当します。戦いの前から戦局を想定し、変更が起きうる局面を予測して設計を組み立てます。戦闘が始まれば基本計画に従って進め、問題が発生するとその原因を深く考察して再発を防ぐ策を講じます。思索と信頼を重視するため、自ら現場に立つことは少ないものの、的確な部下を配置して状況を把握させ、コントロールしています。

アジャイルとウォーターフォールは優劣をつけるものではなく、開発規模とマネージャーのタイプによって使い分けるのが合理的です。大規模プロジェクトの大枠はウォーターフォールでも、分割した小さな機能単位ではアジャイルを適用することも多々あります。どちらの手法でも現場経験を積み、自身の得意分野を広げていくことが大切です。

――――――――――――――――――――――
【補足情報】
もしアジャイルとウォーターフォールを組み合わせるハイブリッド手法にご興味があれば、スクラムとWATERFALLの長所を活かした「ウォータースクラムフォール」や、リーン開発のアプローチを取り入れた「リーンウォーターフォール」なども参考になるでしょう。プロジェクトの特性に合わせた柔軟な設計が、成功への鍵となります。