writing by MASA *このコラムはiPM naviで配信しています PMは、プロジェクト遅延が発生した場合に、スケジュールを圧迫している原因を考えるものです。 その時、所用期間や作業工数の計画ミスを疑うことがあります。 これは、原因追求の『きっかけ』としては正しいです。 しかし足りません❗️メンバーがプロジェクトを成功に導くスキルを持っているか・持ってないか、それを原因の一つとして考えてください。 やはり、プロジェクトで必要なスキルとメンバーのスキルが合致していなければプロジェクトは成功できません。 意外にも、このことを知らないPMが多いってご存知でしょうか？
監修：Yuichiro Hayashiのキャリア 2000年に大手コンサルファームBにジョイン。 同社の創業時からパートナーとして、セールス・コンサルティングとあらゆる組織で活躍しビジネスの拡大に貢献。 2005年にコンサルファームを設立。 総数2,000以上のプロジェクトに携わり、経験したプロジェクトの検証と分析から『現場で使えるノウハウやリスク情報』を法人顧客やフリーランスPMOに提供。 2020年に大手クラウドソーシング 取締役としてジョイン。 大手コンサルファームBでのセールススキルを活かして同社スタートアップサービスの拡大に貢献
こんにちは、プロコンサルのMASAです。 私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。 その中のオプションサービスとして、『トラブルプロジェクトの実例から学ぶ失敗しないマネジメント』をお伝えしています。 このコラムでは、読者のあなたへ、実際に私がPMアドバイザーとして参画し解決した、トラブルプロジェクトの実例を紹介します。 今回は、『要件定義と設計を同時進行、ますますスケジュールが遅延！』というテーマです。 あなたのマネジメント業務で活用できるように、解決までのアプロローチを以下の順番でお伝えします。 ・プロジェクトの状況 ・問題の設定 ・原因追求 ・解決策 ・教訓（リスク管理表へ整理）
目次
プロジェクトの状況
1.プロジェクトのスコープと体制 ・顧客は大手卸売業会社。 ・顧客の情報システム部で新規構開発を実施。 ・情報システム部の窓口は木村。 ・プロジェクトオーナーは情報システム部の山田。 ・システム化スコープは倉庫管理、在庫管理、仕訳管理。 ・中堅SierのA社が開発ベンダーとして参画。 ・A社は全開発工程の成果物の納品、システムリリースの責任を請け負う。 ・A社の開発体制は業務チーム、基盤チーム、テストチーム、管理チームで構成。 ・A社のPMは佐藤（初心者PM） 2.プロジェクト目標 品質目標：100%の不具合修正 スケジュール目標：予定通りのリリース コスト目標：予算内でのシステム完成 3.プロジェクトの進捗状況 現在、プロジェクトは基本設計工程ある。 しかし、要件定義が計画通りに進んでいないことから、基本設計も同時に実施していた。 基本設計工程の予定期間を50%消化した時点で、要件定義と基本設計を同時進行していたことで、顧客のリクエストと設計が噛み合わずプロジェクトの進行に悪影響が出ている。 そのために、PM佐藤は顧客の木村に、未確定要件は今回のプロジェクトの対象外させて欲しいと依頼したが、 『貴社のメンバーが要件に必要なスキルを持っていないからである』 『当初の計画通り進めてほしい』 と一蹴された。 しかし、佐藤は状況を把握しているが、具体的な問題や解決策が分からない状態である。 **守秘義務により企業名・団体名・個人名等は架空名称となります。
問題の設定
*私がアドバイザーとして、プロジェクトに参画して解決させた経緯のスタートです。 問題を考える場合は、どのマネジメント領域で発生したかを分類することで、後続のアプローチがスムーズに行え、得られた結果の根拠も説得力を持つ。 そこで、今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報から考えをもとに考たところ『組織マネージメント領域』で発生した問題として取り扱った。 また、今回のプロジェクトの問題をこのように設定した。 ”設計をやりながら要件定義の遅延を取り戻す策が失敗” この問題を放置することで、品質目標である要望達成率100%を逸脱する恐れがあった。
様々なプロジェクト情報とは
プロジェクト計画書、レービュー結果報告書、要求変更書、レビュー対象物、作業実績情報、作業範囲記述書、要件定義書、成果物一覧、課題問題整理表、役割分担表、要員の選定根拠、勤務表、成果物、関係者からのヒアリング結果
原因の追求
原因を特定するためには関係者へのヒアリングが重要である。 しかし、闇雲に関係者から聞き取りを行っても時間の無駄であることから原因の仮説を3つ立てた。 1.原因の仮説と検証 仮説1 要件定義に必要な所用期間が間違っている。
仮説の検証
有識者の算出し所要期間も計画と同じであったか？ 【 検証結果 】 有識者の算出した所要期間と同じであった。
仮説2 プロジェクト計画の承認以降に仕様追加があった。
仮説の検証
追加された仕様が議事録、メール等に記録されていなかった？ 【 検証結果 】 追加された仕様は課題管理表に記載されていた。
仮説3 メンバーの要件理解度が低かった。
仮説の検証
メンバーは要件を正確にとらえるスキルが適正であったか？ 【 検証結果 】 メンバは設計者としては優秀であるが要件を具現化させるスキルはなかった。
2.今回の問題の原因 メンバは設計者としては優秀であるが要件を具現化させるスキルはなかった。 と判明した。 また、プロジェクトに必要なスキルを技術的な部分だけに絞り、メンバーを選んでいたことが分かった。
解決策
わたしは3つの解決策を準備しました。 解決策A 現場のメンバーは、要件定義を行えるスキルを持っていない。そのため、要件定義スキルがあるメンバーに交代し、全体のスケジュールを見直す。 解決策B 一部のクリティカルな要件を理解できるメンバーを投入し、要件定義を行ってから基本設計を再開する。 解決策C 一部のクリティカルな要件を理解できるメンバーを投入し、要件定義を行ってから全体のスケジュールを見直す。 現在のプロジェクトの状況とこの解決策の案をPO山田へ提言した。 PO山田は、このような意向があった。 ⚫︎ 組織について 要件定義スキルを持ったメンバーの増員に問題なし。 ⚫︎ リリース日について リリース日の延期はできない。 このことから、解決策Bを採用した。 また、この解決策を施行することで、開発ベンダーA社は基本設計のスケジュールを担保することにより、計画工数を30%超過することになった。
教訓（リスク管理表へ整理）
今回の原因は、メンバは設計者としては優秀であるが要件を具現化させるスキルはなかったということであった。 このような事態を、事前に回避することはできる。 それは、プロジェクト計画の段階でこれらを実施することで防止できるのである。 ・必要とされる業務知識、技術知識を洗い出して有識者のレビューを受ける。 ・要件定義のスケジュールに影響するリスクをクライアントと合意しておく。 今回のトラブルプロジェクトをリスク管理表に整理したので、あなたのマネジメント業務で活用して頂ければ幸いである。
最後まで、読んでいただき有難う御座いました。
プロコンサル MASAさんのコラムを、もっと読むにはiPM naviメンバーサイトへログインして下さい。 アカウントをお持ちでない方は、画像をタッチして無料メンバーに登録して下さい