バリューアップパラダイムの中心にあるのが、フローの重視です。「フロー」という言葉には異なる2つの意味があり、どちらもソフトウェアプロジェクトの計画において重要です。

　第一の意味は、人間がうまく実行できる経験です。Mihaly Csikszentmihalyiは 『Flow: The Psychology of Optimal Experience』で以下のように述べています。

　この意味での「フロー」は、eXtreme Programming（XP）提唱者や個人の活動を重視するその他の手法の提唱者がよく取り上げています。

　第二の意味は、進捗の測定基準としての顧客価値フローです。この考え方について、David J. Andersonは『Agile Management for Software Engineering』で以下のように述べています。

　このパラダイムでは、計画した各タスクの完了を基本基準として進捗を把握するのではなく、達成できた価値を単位とします。達成した価値の処理能力および価値単位の達成度で示される進捗率が、計画と進捗測定の指標になります。

　これに相応して、価値フローという考え方では、フローに課される制約を把握することが必然的に求められます。フロー全体の流れを調整するには、最も重大なボトルネック、つまりプロセスで特に非効率的な部分を特定し、それを修正してから次に大きいボトルネックに対処します。Andersonは次のように説明しています。

　フローに基づく計画とプロジェクトマネジメントの手法では、図1-3に示すように、中間工程の進行中作業（Work in Process）を最小限に抑えることが求められます。そうすることで、問題の発見が遅れたり、想定外のやり直し作業が突然発生したりするリスクが軽減されます。

図1-3　シナリオ達成フローを日単位で測定すると、進捗のリズムを把握でき、ボトルネックの発生時にすぐ発見できる。

　図1-3 が示すように、フローを継続的に測定するとボトルネックの形成が明らかになります。このイテレーションで計画した作業は、開発工程（「アクティブ」から「解決済み」へ移行）では順調に進んでいますが、テスト工程（「解決済み」から「終了」へ移行）ではどんどん積み重なっています。これにより、進行中作業が中間工程にたまってしまいます。開発工程だけを見れば、アクティブ作業項目が減少しているので完了予定日までに作業が終わるように見えるかもしれませんが、ボトルネックがあるために終了項目のラインはなかなか上昇せず、予定日までに作業が完了しないことがわかります。これに基づいてボトルネックを調査すると、テストリソースが足りないのか、または開発工程の作業品質が低いのか、問題の原因を突き止めることができます。

■1.3.1 ワークダウン手法との対比

　ワークダウン手法の象徴として、プロジェクトマネジメントを表現する「鉄の三角形」が広く説かれています。この考え方では、プロジェクトマネージャが管理する可変要素は、時間、リソース（とりわけ人的資源が最重要）、機能の3つに限定されています。4番目の要素として品質も考慮するなら（現在はこれが一般的）、図1-4のような四面体になります。

図1-4　ワークダウン手法の古典的概念において、「鉄の三角形」（または四面体）はプロジェクトをタスクの固定的集合と見なす。この四面体のいずれかの面を拡大するには、他の面も拡大する必要がある。

　Steve McConnell は『Rapid Development』の中で、鉄の三角形について以下のように述べています。

　この考え方では、プロジェクトマネージャは最初にある程度のリソースと時間を用意しています。機能または品質を変更する場合は、時間またはリソースを増やす必要があります。すべての面がつながっているので、どれか1つを大きくするなら他も大きくしなければなりません。

　このパラダイムは広く普及していますが、うまく機能していません。ニュートン物理学が特殊状況であったと今では知られているように、鉄の三角形も、工程は順調に進むものであるという前提に基づく特殊状況なのです。つまり、リソースの生産性はきわめて均等であり、タスク達成効率にはばらつきがほとんどなく、システムのどこにも余分なキャパシティはないということが前提となっています。このような前提が成立するプロジェクトもときには存在します（特にリスクの低いプロジェクトの場合）。しかし残念ながら、一般的なソフトウェアプロジェクトはそうではありません。

　アジャイル手法のユーザーの多くは、このような見方と相反する実例を示してきました。たとえば、信頼性などのサービス品質を向上させることで時間を「短縮」できることがよくあります。リソースと時間はそのままでも、フローを大きく改善するこ とが可能です。（!4）

■1.3.2 透明性

　誰もが知っているとおり、ほとんどのソフトウェアプロジェクトは計画より遅れます。進行が遅れるだけでなく、遅れが発見されるのも遅いのが実情です。（!5）本書のほとんどすべての章では、この現象がもたらすさまざまな結果を取り上げています。こうした結果の1つが、フローの効率を損なう集団思考と否認の悪循環です。作業が遅れると、計画の見直しが求められ、それがより楽観的な見通しにつながり、それによってさらに作業が遅れるという繰り返しです。このようなプロジェクトではほとんどの構成員が楽観的な計画を立て、計画の見直しに次ぐ見直しを行いますが、現実的な見通しは立ちません。当然ながら、行き着く先はデスマーチ（死の行進）です。

　こうなる原因は、計画能力や時間管理能力の欠如ではありません。ほとんどの場合、チームメンバ間で優先順位や期待が一致していないことが原因です。多くのソフトウェアエンジニアリング手法では、作業状況がさまざまな場所で管理されます。各種スプレッドシート、Microsoft Projectファイル、要求データベース、バグデータ ベース、テスト管理システム、トリアージ（優先順位）議事録などがあります。情報がこのように分散していると、プロジェクトの全体像を把握することは非常に困難です。参照しなければならない情報の管理場所が多すぎて、すべての情報を1つのスケジュールで調整するのは難しくなります。また、あまりに多くの場所で管理していると、見つかった情報が既に古くなっているという場合も多くなります。

　すべてのプロジェクトがそうであるとは限りません。一部のコミュニティプロジェク トでは、開発スケジュールをWebで公開しており、個人参加者がそれぞれのタスクに何を期待するかを明確にしてコミュニティで共有しています。プロジェクト内のすべての作業を見えるようにすると、好循環が生まれます。もちろん、その前提として、プロジェクトがイテレーション（反復）方式で構築されていること、スケジュールと見積もりの精度が適切であること、トリアージによってそのイテレーションで利用可能なリソースに合わせて作業項目の優先度が適切に調整されていることが必要です。

　アジャイル手法の1つであるスクラム（SCRUM）では、図1-5で示すように、製品バックログの透明性という考えを提唱しています。スクラムの考案者Ken SchwaberとMike Beedleによる製品バックログの定義は以下のとおりです。

　このような透明性は、さまざまな理由から非常に効果的です。これによって作られる「資料一式」は、完了作業と残存作業に関する1つの固有の情報源として管理されます。図1-3のようなフローの測定基準と組み合わせると、全チームメンバが同じデータと計画を参照できるので、チーム内の信頼性が築かれます。そして最終的に、チームの連帯責任と個人の責任の間に好循環が生まれます。自分のタスクの完了を待っている人の存在がはっきりすると、タスクを終わらせようという気持ちが強くな ります。（!7）

図1-5　スクラム手法の中心的な概念図。この図は管理の視点で見たフローをよく表している。スクラムは、管理技法としての製品バックログという概念を提唱した先駆的存在である。

Microsoft .NETはエンタープライズのシステム基盤として、多くの企業向けシステムでの開発基盤、および運用プラットフォームという形で導入が進んでいる。 .NETにかかわるキーマンたちの声を聞き、実際の導入事例を見て、.NETが開発をどう変えるのかを知ろう。 【注目インタビュー】 〜 .NETのキーマンがエンタープライズ戦略を語る 道具を使いながらソフトウェア開発の文化を変える 　“Visual Studio Team System” Visual Studio Team Systemで実践する ソフトウェアエンジニアリング 相対立するパラダイム フローの重視 【導入事例】 〜 SIerに聞く。エンタープライズ向け.NET導入の実際 第1回 日本ユニシス株式会社 第2回 株式会社 富士通関西システムズ 第3回 アバナード株式会社 第4回 株式会社アークウェイ 第5回 株式会社ビジネス・インフィニティ ＆ 株式会社NTTデータ