【プロマネ】大規模システム開発での、ウォーターフォールとアジャイルの宗教論争
現在の変化が激しい不確実性が高い環境下で、今後、どのように大規模システム開発のプロジェクトを進めていくべきか。その考察一回目として、ウォーターフォールモデルの成り立ちから現在までの流れを書いてみました。
新卒の採用面接で受けた質問
現場を多く経験してきたベテランが避けなければいけないのは、成功体験を通じて無批判な”信者”になってしまうことではないかと思います。これは、いわゆる『成功の罠』によって起きることです。
先日、新卒の採用面接の面接官をしていた際、学生の方から「天野さんは大規模なグローバルプロジェクトでアジャイル手法を用いられたと聞きましたが、先日、別のコンサルティングファームのインターンでは社員の方が『現場の結論としてアジャイルは無理。うまくいっているプロジェクトは全てウォーターフォール。』と仰っていました・・。天野さんは、どのようにアジャイル手法を適用されたんですか？」と質問を受けました。
これは学生にではなく、学生にその発言をした他ファームの方に愕然としました。勉強が不足していることを知るための、勉強すらできていないということではないかと感じました。
もしかしたら、その方はご自身の担当領域に限定し、色々な前提を省いて簡潔にお話しされただけかもしれません。（その場合でも、これからキャリアを歩み始めようという学生相手には、すこし丁寧にコミュニケーションを取ってあげて欲しかったですが・・）
それがどちらだったにせよ、カジュアルな形でプロフェッショナルの方と会話をすると、同じような認識の上に立たれている方が相当数いることはわかります。
一方で、アジャイル手法について書かれている記事を調べると、多くの方が『小規模開発ではアジャイルは有効だが、大規模開発には向いていない』という趣旨のことを述べられています。これも前述の他のファームのコンサルの方が述べられていたことの類型です。
アプローチの問題で、宗教論争ではない
この記事のタイトルを宗教論争としましたが、アジャイルもウォーターフォールもどちらもアプローチであり、神や真理ではないので、絶対ではありません。絶対ではないのに、自身の経験から絶対化するので、アジャイル vs ウォーターフォールの宗教論争になるのです。
本題に入る前に少し脇道にそれますが、長年にわたり成功し続けている企業の経営者は、「成功の罠」による怖さを知っている方が多いのではないかと感じます。少しだけ「成功の罠」について考察してみます。
ハーバート・A・サイモン（1916 - 2001）というアメリカの経済、政治、認知心理学者がいます。サイモンはミクロ経済学の分野での組織の意思決定に関連する研究で、1978年にノーベル経済学賞を受賞しています。いわゆる認知心理学に基づくカーネギー学派を代表する学者ですね。サイモンは以下のように述べています。
人間は合理性をもとに意思決定を下すが、不確実性と認知の範囲の限界により、『限定合理性（bounded rationality）』をもとに『満足（satisficing）』することで意思決定を下す。
人間の認知の範囲には限界があるということがポイントで、これは最近よく聞く『両利きの経営』の考え方のベースになっています。
両利きの経営は、経営には、変化し続ける環境に適応するための『知の探索』と、今日のビジネス管理を効率的に行う『知の深化』があるといいます。そして、人間が両手を使用するのと同様に、経営にも『知の探索』と『知の深化』両方使用する組織作りが必要という理論です。
『知の探索』は、前述の”認知の範囲の限界”を”超える”ために必要です。昨日の世界で、確からしい仮説や前提を置いて『限定合理性』をもとに意思決定したことが、今日のビジネス環境下でも同じように機能するとは限りません。
ただし、企業もそうですが人も、いったん満足する（satisfacing）ことによって『知の探索』に対するモチベーションが下がります。そうして『限定合理性』を完全な合理性と妄信して、認知の範囲外にある環境変化を見逃して意思決定し、"大きな"失敗をします。
優秀かどうか、個人の資質はべつにして、人間とはそういう生き物です。それでも成功し続ける経営者がいらっしゃるのは、そうした方々が"失敗"の経験を通じて、経験的に『成功の罠』をご存知だからではないかと思います。
ここで私が考える、この罠を防ぐために有効なアプローチは、大きく三点です。
① 視座をあげ、視野を広げて、大局観を持つこと
② 常に新しいチャレンジを組織や自身に課すこと
③ 『知の探索』に繋がる、"小さい"失敗をすること
この３点がここでの議論の本質であり、とくに3点目はアジャイル型のアプローチをとり入れたときの最大のメリットになります。
ウォーターフォールモデルの成り立ちと課題
ウォーターフォールとアジャイルの優劣を比較をすることが、この記事の主眼ではありません。
基本的にはアジャイルへの大きな流れがあるなかで、どう補完しあって、現場のプロジェクトマネージャがその運用を考えるかのベースラインになればということでこの記事は書き始めています。そのため、まずはウォーターファールモデルがなにかをまず紹介します。
ウォーターフォールモデルは、ソフトウェア開発に適用される前に製造業、建設業で（同様の考え方で）運用され始めていました。今日ではアジャイルを適応型（Adaptive）アプローチというのに対して、ウォータフォールは予見型（Predictive）アプローチに分類されます。
ソフトウェア工学における最初の発表は、SAGE（英 ソフトウェア企業）用の開発に関するベニントン氏によるものでした。
（出所: "Production of Large Computer Programs" HERBERT D. BENINGTON 1956）
ウォーターフォールモデルでは予見型であるため、計画の段階で完了までを構造化して見通すことが容易で、直線的に考えることができます。つまり、計画の可読性、理解のしやすさが特徴と言えるでしょう。
ウォーターフォールモデルを今に通じる形で定義したと言われるのは、ウィンストン・W・ロイス（1929 - 1995）というアメリカのコンピュータサイエンティストによる、『大規模ソフトウェアシステムの開発管理（"Managing the development of large software systems" 1970）』になります。
ウィンストン・W・ロイス氏
ロイス氏は以下の7ステップでウォーターフォールモデルを描写しました。
・システム要件（System Requirement）
・ソフトウェア要件（Software Requirement）
・分析（Analysis）
・プログラム設計（Program Design）
・コーディング（Coding）
・テスト（Testing）
・運用（Operations）
ただし、ロイス氏は、ウォーターフォールモデルの生みの親のように言われてきましたが、彼自身は論文の中でそれ自体を批判的に記述しています。
ロイス氏は大規模ソフトウェア開発にはウォーターフォールモデルで行われるようなら、構造化したアプローチが必要というと同時に、シングルパス（一方通行）のシーケンシャル（順序性に従った）アプローチに対するリスクも指摘しています。
テストフェーズが実際のプログラミング動作やI/O（Input/Output）を確認する最初のイベントになる。こうしたことを検討初期で、全て正確に分析されることはない。数学の方程式とは異なるからだ。
テスト時にさまざまな条件・制約が満たせないとなった場合に、大規模な再設計が必要になる。この設計変更はソフトウェア開発の根幹を揺るがす可能性が高い。
（ロイス氏の論文を抜粋し、意訳）
そこで、スクラムなどのアジャイル手法に通じる部分ですが、すでに1970年のタイミングでロイス氏はイテラティブ（反復的）という言葉を使い、プロジェクトはいわゆる要件定義～テストまでのイテレーションを２回は通す必要があると主張していました。
（ロイス氏が主張したモデル）
大規模システム導入における、前工程の肥大化
まずは、工業製品の開発アプローチなどを下敷きにして、ソフトウェア開発の現場でもシステムの大規模化に伴う管理上の要請もあって、ウォーターフォールモデルが形作られてきました。その後は、そこでのロイス氏が指摘したような欠陥をどう補うかを試行錯誤してきたのが、アジャイルが隆盛を誇る以前です。
現場での試行錯誤は、主に手戻りをできるだけ少なくするという点に着目されてきました。
手戻りを少なくするために、例えば私たちITコンサルタントはどういうアプローチを取ってきたのかというと、一つは要件定義、設計にかなり時間を掛けるようになりました。今では開発にかける工数、期間と同等の資源を、要件定義と設計それぞれにかけるのがウォータフォールモデルでは一般的になっています。
要件定義、設計では、それぞれのアウトプットに対して、要件の出し手からのサインオフ（確認/承認）を貰います。実際に動くものを見ていないのにです。
要件の出し手が受け入れ時に見つかった差異に対する変更は、文書に記述されていないものは仕様変更の扱いになります。仕様変更は買い手からみると追加コストですので、買い手側のマネジメントは要件定義、設計で現場の人間が正確に理解・判断することを求めます。そう、実際に動くものは見ていないのにです。
そうして、コンサルと要件の出し手双方から、要件定義、設計に十分なコストと時間を割くことは、共通の理解になりました。今日の大規模開発でも、開発にかけるのと同じぐらいの工数・期間を、それぞれ要件定義、概要設計でかけることは珍しくないはずです。
手戻りリスクを緩和するハイブリッドアプローチ
ここからは現在進行形の動きでもあるので、あまり方法論として整理してまとまっているものではありません。昨今、多くの大規模プロジェクトで一般的になりつつあるアプローチを紹介します。
下の図で上部のプロセスが、旧来型のウォーターフォール、下部のプロセスが最近多くなってきているアプローチとお考え下さい。
下のアプローチでは、業務に合わせてシステムを作りこむ形ではなく、ベストプラクティスと言われる、システム化構想に対してフィット率が高いと思われるテンプレートを選定し、それをベースに導入を行います。
次にテンプレートをベースに、プロトタイプを作りFit & Gapを行い、Gapとなった機能についてプロトタイプ環境上で追加・変更の検証を行います。
その一連のプロセスの結果をバックログに、複数回、設計からテストまでのイテレーションを、スプリントとして実行します。
これをアジャイルと呼ぶ方もいらっしゃいますが、プロトタイプやスプリントなど組み込んだ、ウォーターフォールとのハイブリッドアプローチです。この進め方では、手戻りに対するリスクを、ある程度は緩和することができます。
リーンスタートアップとの組合せ
ここからはウォーターフォールモデルにビルトインの、プロセス上の課題である手戻りに対する対応に加えて、大規模システム開発それ自体が内包する問題点の解消に焦点をあてます。
私が関与してきているERPやCRMなどのグローバルシステム導入は、数年がかりで数十億円から数百億円の予算で、コンサルだけで数百名体制になることもザラです。
マーケットや技術の変化が緩やかな時代であれば、数年かけて巨大なシステムを一気に導入する方法も取り得たでしょう。しかし、現状はそうではありません。超巨大なシステムが出来上がった頃には、環境がガラッと変わって使いものにならなくなっていることもあります。
従来の進め方がPredictive（予見可能）なことを前提にしているのに対して、今後はAdaptive（適応可能）であるべきということが非常に重要なポイントです。
リーンスタートアップそれ自体に、ここで紙幅を割くのは避けますが、ここでポイントになる考え方はMVP（Minimum Viable Product）という考え方です。
この考え方はフェーズドアプローチだったり、段階的リリースだったりと、以前から大規模システム導入で用いられてきた考え方と通じるところはあります。また、前述の『"小さい"失敗』を経験するための装置がこれです。
こうした考え方を下敷きにして、私が昨年SAP Nowというイベントで講演を行いました。（現在は視聴不可能ですが・・）
講演でお話した内容含めて、リーンスタートアップを取り入れてのプロジェクト計画と、それに合わせた企業組織の変革については、また次の記事で考察したいと思います。
この記事が気に入ったらサポートをしてみませんか？