DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、野口悠紀雄氏の『「超」整理法』を参考に、問題・課題、ToDo、リスクを分類せずに同じ一覧で管理して効率化を図ることができるのではないかと問題提起しました。原理原則も大事ですが、自分たちに合ったやり方を探って創意工夫することも大切なことです。

今回は、システム開発プロジェクトにおけるスケジュールの階層化について考察します。

【　プロジェクト・スケジュールの３層構造　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログの　【第３０回】マスタースケジュール・フェチ　では、マスタースケジュールはプロジェクト計画書の要（かなめ）であり、最も重要な問題発見のための物差しだとしました。
また、【第２３回】プロジェクト計画書の段階的詳細化とは？　では、「得られる情報が増え、より正確な見積りが可能になるにつれ、プロジェクトマネジメント計画書がより詳細化していく」段階的詳細化についてご紹介しました。

つまり、システム開発プロジェクトにおけるスケジュールは、マスタースケジュールを出発点にして、開発工程が進むにつれ、下位レベルのスケジュールに段階的に詳細化されていくというのが一般的な流れになります。

プロジェクト・スコープの大きさや体制の組み方にもよるところはありますが、基本的には、プロジェクトのスケジュールは３層構造で考えます。

第一階層は、プロジェクトの全体を管理するためのマスタースケジュールです。【第３０回】マスタースケジュール・フェチ　では「マスタースケジュールの目的は、プロジェクト全体を俯瞰するためのものであるため、情報量が多すぎると、一見して全体を把握することができず、本来の目的が達成できなくなってしまう」ため、「プロジェクトの全てのタスクが盛り込まれるわけではなく、プロジェクト管理上の重要ポイントに絞って記述する」と説明しました。つまり、全てのタスクを盛り込んだスケジュールは、マスタースケジュールとは別に必要だということです。

先に第三階層ですが、全てのタスクを詳細化し、担当者や成果物なども盛り込んだ詳細WBSになります。WBS（Work Breakdown Structure）は、本来はタスクを階層化したものですが、詳細WBSの各タスクに開始終了の予定／実績の期日を記入して管理することが多く、ここでは最小単位のスケジュールとして扱うことにします。

そして、第二階層は中日程になります。小規模プロジェクトの場合は、マスタースケジュールから直接、詳細WBSに落とし込むことが可能な場合もありますが、大規模プロジェクトでは詳細WBSのタスク数は、チームごと、工程ごとに分割したとしても、数百に及ぶことがあるので、詳細WBSを用いてチームの進捗状況を把握するのは至難の業です。

詳細WBSを用いて進捗状況を把握しようとしたときによくあるのが、タスク数が多すぎるので、進捗会議で議論するのが各担当者から申告のあった遅延タスクのみとなり、チーム全体、工程全体でみたときの重大なタスクの漏れやタスク間の依存関係のひずみなどが見えなくなってしまうことです。要は木を見て森を見ぬ管理に陥ってしまうリスクが高くなってしまうのです。そこで、チームごとの進捗を管理するための中日程が必要になるのです。

【　プロジェクト・スケジュールのミドル・アップダウン・マネジメント　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、このようなスケジュールの階層構造を現実のプロジェクトでしっかり維持していくのは、簡単なようでなかなか実現するのが難しいものです。良く見かけるのが、プロジェクトの開始時点で作ったマスタースケジュール、各工程開始時点で作った中日程が、プロジェクトの進行に伴い、詳細WBSとかけ離れていってしまうという現象です。

これは、ウォーターフォールモデルの開発で、要件定義⇒外部設計⇒内部設計と進めていく過程で、仕様の詳細化とともに要件定義書が陳腐化していく現象と似ています。システム開発の場合、最終的に出来上がったシステムに全ての要件が具備されていれば良いという発想のもと、上流工程の成果物が、いわば中間成果物として扱われる傾向があるためです。

この発想に慣れてしまうと、スケジュールの詳細化にも同じように、詳細WBSさえできてしまえば、マスタースケジュールや中日程を捨てても進捗管理ができるという誤った考え方をしてしまう危険があります。マスタースケジュール⇒中日程⇒詳細WBSの階層構造は、決してウォーターフォールモデルではありません。日本的経営として良く言われる「ミドル・アップダウン」に近いと私は考えています。（※１）

プロジェクトマネージャがプロジェクト全体のビジョンをマスタースケジュールに表現して、各チームに示しただけでは実効性のあるスケジュールにまで落とせていません。最初に作られるマスタースケジュールは、開発規模見積りや標準生産性、各工程の工数比率モデルなどをもとにして、さまざまなスケジュール制約事項なども考慮した上で、トップダウンで落とし込んだものです。標準生産性や工数比率モデルなどは、あくまでも過去の統計に基づいた過程値でしかありません。

それを各チームで受け止めて、具体的に各工程をどう進めるかタスクを具体化し、実効性のある中日程として組み直すのです。そして、各チームの中日程を持ち寄り、全体の整合性を確保しながらマスタースケジュールにフィードバックして、初めてマスタースケジュールに魂が吹き込まれるのです。

もちろん、この作業はプロジェクトの開始時だけ行えばよいというわけではありません。各工程開始時の中日程策定時、また、テスト計画や移行計画策定など、プロジェクト計画の段階的詳細化を行うたびに、マスタースケジュールへのフィードバックを必ず行うことで、プロジェクトマネージャが示したビジョンとの整合性を維持し続ける必要があります。

このように、実効性のある中日程をもとにマスタースケジュールへのフィードバックを行う過程は、まさに「ミドル・アップダウン」のプロセスと言えます。そして、詳細WBSのベースとなり、チームごとの進捗管理を行う中心となるのが中日程であり、中日程はまさにプロジェクト進捗管理の中心的な役割を担うのです。

「マスタースケジュールはビジョンであり、
中日程は実効性のある進捗管理の中心である！」

ただし、会社経営でもミドルが突出することで全体のビジョンが失われて組織が迷走してしまうリスクがあるのと同様、プロジェクトもマスタースケジュールが置いてきぼりにならないよう、週次の進捗会議などでマスタースケジュールにイナズマ線を引いて、配布するなどの工夫が必要であることはもちろんです。

【　究極目標と中間目標　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで少し話は飛躍しますが、ビジョンを示すマスタースケジュールと実効性のある中日程の関係性は、ジェラルド・ナドラー氏の『新・ブレークスルー思考』をヒントにした、以前からの私の持論である究極目標と中間目標の関係性を連想します。(※２)

あまり高すぎる目標を掲げてしまうと着実な進歩が得られないという考え方と、逆に現実的な目標だけでは大きな飛躍（イノベーションやブレークスルー）は期待できないという考え方がありますが、どちらかというと後者（究極目標）を中心に置きながら前者（現実目標＝中間目標）も配慮した考え方になります。

究極目標（考えられる最高の目標、夢、理想）を持つことの意義として、私は以下の３点を考えています。

＜　究極目標を持つ意義　＞

１．軸がブレない
究極目標を意識することで、目標達成のための施策が場当たり的になることや一部のステークフォルダのメリットだけを優先することなどが回避できる。

２．リバウンド防止
究極目標を意識することで、中間目標達成だけで満足して改革のスピードが鈍ることがなく、次の中間目標設定に向かうなど継続的改善に結びつけられる。

３．イノベーションの可能性
究極目標を意識することで、現実的な中間目標達成のための施策にとどまらず、独創的な発想によるイノベーションの可能性を創出できる。

システム開発のプロジェクトにおいて、マスタースケジュールは決して理想像ではありませんが、計画時点で作ったまま忘れ去られないように、プロジェクトのゴールを記したビジョンのようなものとして、常にプロジェクトメンバーやその他のすべてのステークフォルダに対して示し続ける必要があるのです！

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「ミドル・アップダウン・マネジメント」については、以下文献参照。
・野中 郁次郎、竹内 弘高(1996)『知識創造企業』東洋経済新報社

※２　ジェラルド ナドラー、日比野 省三(1997)
『新・ブレイクスルー思考―ニュー・コンセプトを創造する7つの原則』ダイヤモンド社