writing by MIRIO *このコラムはiPM naviで配信しています スケジュールを見積もるには、これらの親和性が成り立っていなければなりません。 ・作業ボリューム（作業工数） ・作業を完了させるための所要日数（スケジュール） これが不成立とは、間違ったスケジュール見積もりを意味します。 経験の浅いプロジェクトマネージャは、過去の類似プロジェクトを参考にするのは最良の手です。 しかし、『なぜ、このようなスケジューリングにしたのか？』という根拠を見つけ出すのに苦労します。 そんな時こそ、有識者に支援してもらうのが得策です。 意外にも、これをやらないPMが多いってご存知でしょうか？
監修：Yuichiro Hayashiのキャリア 2000年に大手コンサルファームBにジョイン。
同社の創業時からパートナーとして、セールス・コンサルティングとあらゆる組織で活躍しビジネスの拡大に貢献。
2005年にコンサルファームを設立。
総数2,000以上のプロジェクトに携わり、経験したプロジェクトの検証と分析から『現場で使えるノウハウやリスク情報』を法人顧客やフリーランスPMOに提供。
2020年に大手クラウドソーシング 取締役としてジョイン。
大手コンサルファームBでのセールススキルを活かして同社スタートアップサービスの拡大に貢献
こんにちは、プロコンサルのMIRIOです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『スケジュール破綻！リリースできない..._』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプローチを以下の順番でお伝えします。 ・プロジェクトの状況 ・問題の設定 ・原因追求 ・解決策 ・教訓（リスク管理表へ整理）
目次
・プロジェクトの状況 ・問題の設定 ・原因の追求 ・解決策 ・教訓（リスク管理表へ整理）
プロジェクトの状況
1.プロジェクトのスコープと体制 ・顧客は大手ファイナンス会社。 ・顧客の情報システム部で新規構開発を実施。 ・情報システム部の窓口は木村。 ・プロジェクトオーナーは情報システム部の山田。 ・システム化スコープは商品管理、資産管理、顧客管理。 ・中堅SierのA社が開発ベンダーとして参画。 ・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。 ・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。 ・A社のPMは佐藤（初心者PM） 2.プロジェクト目標 品質目標：100%の不具合修正 スケジュール目標：予定通りのリリース コスト目標：予算内でのシステム完成 3.プロジェクトの進捗状況 現在、プロジェクトは要件定義工程であり、最終日であった。 想定よりも要件のボリュームが多いためスケジュールの延期を顧客の情報システム部 木村に依頼した。 しかし、木村から 「事情は分かった。」 「しかし、当初の計画通り進めてほしい。」 と一蹴された。 佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。 問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。 そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『スケジュールマネジメント領域』で発生した問題として取り扱った。 また、今回のプロジェクトの問題をこのように設定した。 ”クライアント要求を予定通りにリリースできない” また、この問題を放置することで、スケジュール目標であるリリース日を逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 要件定義工程において、トラブルによって作業が遅れた。
仮説の検証
課題問題整理表の中で作業遅延に起因するトラブル事項の記載があったか？ 【 検証結果 】 トラブルの記載はなかった。
仮説2 要件定義工程において、計画フェーズよりも要件が増えた。
仮説の検証
議事録、メール等に要件追加の事実が記載されていたか？ 【 検証結果 】 全ての資料を調査したが記録されていなかった。
仮説3 計画した作業スケジュールが間違っていた。
仮説の検証
有識者のスケジュールも計画と同じだったか？ 【 検証結果 】 改めて有識者が当該プロジェクトのスケジュールを見積もったところ、作業期間が極端に短かった。
2.今回の問題の原因 計画した作業スケジュールが間違っていた。 と判明した。 また、PMはスケジュールの見積もり方法を知らず、直感を頼りに見積もりを行ったことが分かった。
解決策
わたしは3つの解決策を準備した。 解決策A クライアントの理解が得られなければプロジェクトを中止する。 解決策B ビジネスインパクトの強い機能を優先して段階的にリリースする。 解決策C クライアントの要望に応えるため、増員してスケジュールを延ばす。 現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。 PO山田は、このような意向があった。 ⚫︎ スコープについて ビジネスインパクトの強い機能を優先して段階的にリリースすることに問題はなし。 ⚫︎ スケジュールについて スケジュールの延期はできない。 このことから、解決策Bを採用した。 また、この解決策を施行することで、スケジュールが30%超過することになった。 *但し、ビジネスインパクトの強い要件は計画していたリリース日にサービスインした。
教訓（リスク管理表へ整理）
今回の原因は、計画した作業スケジュールが間違っていたということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・作業工数、スケジュールの見積もりは有識者を含めて行う。 ・要件定義が終了した時に、作業工数、スケジュールの調整を行えるようにルール化する。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
プロコンサル MIRIOさんのコラムを、もっと読むにはiPM naviメンバーサイトへログインして下さい。 アカウントをお持ちでない方は、画像をタッチして無料メンバーに登録して下さい。
＼お知らせです ／
プロジェクトマネージャを目指してる方
なぜ、プロジェクトが破綻したのか？
今回、プロジェクトが破綻したのは、PM経験が少ないことによるプロジェクト計画の策定を失敗したからです❗️
PM経験が浅い方は、プロジェクト計画で何を考えれば良いかが曖昧になっているケースがあります。
プロジェクト計画で、重要なのはプロジェクトを成功させるための要素を認識していなくはなりません。
プロジェクト計画を構成するは3つの要素 WHY： なぜプロジェクトを行うのか。 WHAT： どのような作業を行なって、どんな成果物を作るのか。 HOW： どんな成功に導くための手段や方法を用意するのか。
破綻するプロジェクトは、3つの要素に対して、これらのことが出来ていないからです。
・どれか一つが漏れてしまった。
・間違った手順で作ってしまった。
・正しいメソッドやノウハウを使えなかった。
そのため、PMはプロジェクト計画を立てる時に、以下を意識してください。
1.構成を順番通りに、
2.正しい手順で、
3.メソッドやノウハウを使って、
4.「プロジェクト計画書」に、まとめる。
もし、あなたがこれらを意識していけど、
「勉強したいけど、何から手をつけていいか分からない」
「今の勉強方法が実践で使えるか自信が持てない」
「体系的にプロジェクトマネジメントを学び体験したい」
このように感じているなら、iPM TRAININGにチャレンジしてください。
あなたのプロジェクト計画書を作るスキルUPをサポートするサービスです❗️
