プロジェクト管理ガイド「PMBOK」の続きです。
前回は10の知識体系の「スコープ管理」でしたが、今回は「スケジュール管理」についてのお話です。
スケジュール管理はQCDの視点でも大きく関りがありますので絡めて説明していきます。
スケジュールの階層化
スケジュールを立案する大前提として、数か月以上掛かるプロジェクトを１つのスケジュール表で管理するのは現実的ではないです。
個々の作業の進捗を管理できるような詳細化されたEXCELだけで管理すようとすると全体が捉えにくくなりますし、かといってパワポ資料１枚に収まる大日程表だけで進捗管理をするには大雑把すぎます。
よって、プロジェクトの開始から終了までの全体を１枚のチャートで見渡せる大日程レベルの上位スケジュールが上位の階層で１つ。
チームで進捗を管理できる下位レベルのスケジュールを１つ。
この下位レベルのものは１～３か月単位でプロジェクトの進行と共に詳細化し作り足していくのがよくあるやり方です。
さらにこの下の最下位に個人の週次スケジュールを作って管理するやり方もありますが、これはあまりお薦めしません。細かく管理し過ぎるとマネジメントのオーバーヘッドになるからです。
個人の週次のタスクの管理はホワイトボードを使った「ToDoリスト」で充分だと思います。
一方で上位レベルの大日程表は、プロジェクトメンバーだけでなくマネジメント層やステークホルダーにスケジュールの意図が理解できるようにしておく必要があります。
上位レベルのスケジュール
このスケジュールはプロジェクトを上手く進めるためのアイデアが織り込むもので、何かのスケジュール管理ツールを導入するだけではだめだと思います。
アイデアとはプロジェクトゴールを実現するためのテーマや課題の優先順位をどう決めるかということです。
必要な機能と品質を確保した上で、リスクが少なく、できるだけコストを掛けずに、短い期間でプロジェクトゴールを実現するための知恵の塊になっているべきです。
例えば、以下の様なことです。
・技術的に実現が難しそうな機能の開発を先行させる
・ユーザー評価が見通せないのでプロトタイプを先に開発してユーザーからのフィードバックを要件定義に織り込む
・部品表データベースの開発と移行を先にやることで周辺システムの混乱を減らす
・実績収集系システムの開発を先に行い、実績データを見て計画系システムを設計開発する
・日本のシステムはガラパゴス化しているので海外拠点のシステムをコア機能として最初に開発する
等々
さらに、この様なすばらしい優先順位付けができたとしても、これを実行できる人的リソースのスキルレベルとボリューム、そしてどのタイミングで調達できるのかも大きなファクターになります。
スケジュールを作ったのにそれを実行・実現できる人が居ないのはまさに「絵に描いた餅」です。
現実的な裏付けのあるリソース調達計画も上位スケジュールには織り込まれなくてはなりません。
この様なプロジェクトプランニングは巨大なプロジェクトになればなるほど、プロジェクトマネージャーの知見だけで策定するのは難しいものです。
プロジェクトに関わるITコンサルタント、ITアーキテクト、アプリケーションエンジニア、さらには組織マネジメント層の協力も得てプロジェクト全体の知見を集約して答えを出すべきです。
この優先順位、実行順序を決める方法として、以前「階段モデル」という手法を紹介したことがありますがそちらも参考にしてもらいたいです。
階段モデル – IT業界カウンセリング雑談 (taworks.jp)
スケジューリングツールと手法
スケジュール策定のためのいくつかのツールや考え方があるので紹介します。
これらのツールはもちろんプロジェクト全体のスケジューリングに活用できますし、下位レベルのスケジューリングでも利用できます。
まずは基本的な「プロジェクト・スケジュール・ネットワーク図」からです。
ADM (Arrow Diagramming Method)
作業（アクティビティ））を矢印（→）、作業と作業の接続点（ノード）を丸（○）で前後依存関係を明確にしたチャート。
作業と接続点を結ぶにはルールがあり、シンプルではありますが作業の流れを抜け漏れなく表現する時に活用できます。
PDM (Precedence Diagramming Method)
作業（アクティビティ）を四角（□）、作業の関係を矢印（→）として表現したチャート。
作業が四角になっているので、スケジュールを定義するにはこちらの方が視覚的に判り易いかも知れません。
次はこれらのチャートを使いながらスケジューリングする際の技法ですが、クリティカルパス法、資源最適化、データ分析法（What-ifシナリオ分析、シミュレーション）などがあります。
ここでは一番よく使われるクリティカルパス法に属する3つの手法を説明します。
１つめ
PERT (Program Evaluation and Review Technique)
1958年に米国で開発された工程管理手法です。
プロジェクトリスクを計画に反映させるのが特徴的で、工数見積もりに3つのパターン（楽観値・悲観値・最頻値）から算出した期待値を使います。
期待値=(楽観値+悲観値)+(最頻値×4))÷6
このことからプロジェクトの完了に必要な所要期間の見積にも利用されています。さらに、重点管理が必要なクリティカルパスを算出し、管理が必要な工程を明確にします。
2つ目
CPM (Critical Path Method)
PERTと同時期に開発された技法でPDM等のネットワーク図を基にクリティカルパスを算出しプロジェクトの柔軟性を判定するものです。
分析の手順としては、フォワードパス分析→バックワードパス分析→バッファ計算とクリティカルパスの設定があります。
3つ目
CCPM（Critical Chain Project Management)
かの有名な「The Goal」の著者であるゴールドラット博士がTOC（制約性理論）を基に提唱したプロジェクトマネジメント手法です。
特徴としてはCPMにリソースの競合を取り込んだことやバッファをタスクからプロジェクトへ集約すること等がありますね。
これは別の投稿で詳しい説明をするのでここでは割愛せて頂きます。
スケジュールとQCDF
スケジュール管理にはQCDが大きく関係します。今回はさらにF:機能（Function）も入れてみました。
最適なスケジュールが策定できたとしても、プロジェクトの進行途上で想定しない事態が起こりスケジュール変更をしなければならないことが起こり得ます。
Q:品質
システム品質の問題はプロジェクトの後半、システムテストやユーザーテストで発覚することが多いです。
特にユーザーテストで想定以上の不具合や要望が発生した場合、非常に大きな想定外工数と時間が掛かるものです。
一説によると開発工程で修正する場合の4倍以上の工数が掛かるとも言われています。それはそうですね、詳細設計、コーディング、単体テスト、システムテスト、ユーザー検証をやり直すわけですから。
ウォーターフォールモデルではこれが一番避けたいこと。よって、品質を守るための施策の工数を織り込んだスケジュールが求められます。
要求事項の網羅性担保方法、設計手法、レビュー技法、テスト技法など品質計画上のアクティビティをステークホルダーにも見えるようキチンとスケジューリングしておくことにつきます。
が、それでも起こってしまった場合どうするか？
これはプロジェクトの特性によって対応策も変わってきます。
D:納期最優先のケース、Q:品質最優先のケース、C:コスト最優先のケースです。
これらを後述します。
C:コスト
私の経験したプロジェクトでは、億単位規模のプロジェクトが当初の見積もりコスト内で終わったケースはあまり記憶にないです。
中には当初見積1億円のプロジェクトが、終わってみたら4億円掛かったというのもありました。流石に会社を辞める覚悟をしましたね。
このプロジェクト、途中で打ち切りになると思っていたのですが、会社としては新しい製品IoTとして目玉のプロジェクトであり、新製品の一機能として広報でアピールしてしまっていたので予算オーバーでもやりきる、という経営判断があったのです。
神風が吹くこともあります。
これは極端な例ですが今までに経験値の無いプロジェクトや、技術的に難易度の高いプロジェクト等ではこの様なことも起こりうるということです。
このプロジェクトも不確実性やリスクの評価を企画段階でやっていたのですが、誰も経験が無いことですから、評価することすら難しかったのです。
そこで得た教訓
発注する側：見積規模金額はあくまでプロジェクトを開始させるための参考値だと思ってください。潜在的なリスクが見えていないだけです。
受注する側；不確実性が高い規模の大きなプロジェクトを一括で受注してはいけません。
発注会社の予算取得や決裁のために規模金額は出さなければいけませんが、それをそのまま契約の単位にしてはいけません。
スケジュール管理上の留意点としては以下の通りです。
・規模見積もりでは算出の根拠とリスクを明確にしておくこと
・プロジェクト計画自体をステップ展開、スモールスタート計画にする
・契約はステップ展開等の小さな単位、もしくは準委任契約とする
・後工程の見積とスケジュールは開発実績を加味しながら精度を上げていく
その時に当初の算出根拠のどこが相違したのかその理由も説明できるようにしておく
D:納期
対象としているプロジェクトの特性にもよりますが、納期必達（納期最優先）のプロジェクトの場合、何かを犠牲（言い方が悪いのでトレードオフ）しなければならないケースがあります。
例えば「新製品の市場投入が早まったので開発期間を短縮してくれ」という場合、以下の様なことが考えられます。
Q:品質→致命的な不具合以外は許容する（リリース後に直す）
F:機能→本当に必要な機能に絞って開発&リリースする/リリースする機能を減らす（段階的な開発&リリースとする）
C:コスト→開発要員を増加させタスク期間を短縮する
一方で、納期最優先ではないプロジェクトの場合は少々対応策が違います。
金融関係のシステムではいくら納期があるからといってもQ:品質が不十分なシステムをリリースすることは無いでしょう。
C:コストを使い開発要員を増加させたとしても、品質保証のためのテストの期間を犠牲にすることはしないと思われます。
その場合はやはりD:納期を調整し延期とするのが正しい判断です。
みずほ銀行の様にシステムの不具合で窓口取り扱いやATMが停止したなんていうことは絶対に避けなければなりませんね。
まとめ
スケジュール管理について説明してきましたが如何だったでしょうか。
スケジュール管理ではプロジェクトの進捗管理上でも活用する知見なのですが、それはまた別のお話にさせてください。
最後まで読んで頂きありがとうございました。
以上です。
コメント