『メンバのスキルがプロジェクトを成功に導く』プロジェクトに取り入れたいポイント！
スケジュールを圧迫する理由にスキルの選定ミスがあります。
✅プロジェクト遅延の際に並行で別工程を実施して失敗した方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者
にお伝えしたいプロジェクトリスクの情報です。
プロジェクト遅延が発生した場合に、スケジュールを圧迫している原因を考えるものです。
その時、多くのプロジェクトマネージャーは、所用期間、作業工数の計画ミスを疑うことがあります。
これは、原因を追求する『きっかけ』としては正しいのですが、これでは足りません。
メンバーがプロジェクトを成功に導くことができるスキルが備わっているかを原因の一つとして考えなければなりません。
プロジェクトで必要とされているスキルを理解していないとスケジュールは圧迫されるものです。
やはり、プロジェクトで必要なスキルとトメンバーのスキルが合致していなければプロジェクトは成功できません。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？
■今回のテーマ
プロジェクト計画における『体制の構築』の検討の中で、『プロジェクトに必要なスキルとメンバのスキルのギャップがあった』ことにより、『品質担保が困難になった』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
prologue
株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。 目的を達成させるためには、個々の目標の設定が必要です。 品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。
コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。
【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
▷PMアドバイザー
The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー。
【プロジェクト状況】
現在のプロジェクトは、基本設計工程である。
（しかし、要件定義工程では未確定の要件が多いことから、確定までに時間が掛かるため全体のスケジュールを考慮して、無理やり基本設計を開始してしまった。）
当該工程が所要期間の50%を消化した時点で、要件定義の遅れを取り戻すために基本設計と並行して行なっていたことが仇となり、要件と設計が噛み合わず、プロジェクトの進行に悪影響が出てしまった。
そのため、プロマネ初心者の佐藤は『未確定要件をプロジェクト対象外とすること』を依頼した。
しかし、クライアント窓口の木村の回答は『貴社のメンバーが要件に必要なスキルが不足しているため要件が確定しないのである。当初の計画通り進めて欲しい』と要望された。
プロマネの佐藤は、状況の把握をしていますが、具体的な問題が分かっていない。
そのため、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）
目次
STEP1：問題の設定
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『組織マネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『設計をやりながら要件定義の遅延を取り戻す策が失敗』、このように問題を設定した。
STEP2：原因の究明
この問題は、品質目標である要望達成率100%を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)要件定義に必要な所要期間が間違っている
(2)プロジェクト計画の承認以降に仕様追加があった
(3)メンバーの要件理解度が低い
そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)要件定義に必要な所要期間が間違っている
▷有識者の算出した所要期間も計画と同じであったか？
➡︎YES
(仮説2)プロジェクト計画の承認以降に仕様追加があった
▷追加された仕様が議事録、メールなどに記録されていなかったか？
➡︎YES
(仮説3)メンバーの要件理解度が低い
▷メンバーは要件を正確に捉えるスキルが適正であったか？
➡︎NO
問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、計画段階でプロジェクトに必要なスキルを技術的な部分だけに絞り、メンバーを選んでいたことが分かった。
そして、 メンバーのインタビューから、要件と設計が噛み合わない部分は、一部のクリティカルな要件であることが把握できた。
STEP3：解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】解決策A：
現状のメンバーは、要件定義を行えるスキルを持っていないため、要件定義スキルを持ったメンバーに交代して、全体のスケジュールを見直す。
解決策B：
一部のクリティカルな要件を理解できるメンバーを投入し、要件定義を行なってから基本設計を行う。
解決策C：
一部のクリティカルな要件を理解できるメンバーを投入し、要件定義を行なってから全体のスケジュールを見直す。
調査の結果から、計画段階でプロジェクトに必要なスキルを技術的な部分だけに絞り、メンバーを選んでいたことが分かっている。
そして、 要件と設計が噛み合わない部分は、一部のクリティカルな要件であることも把握している。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
山田の意向は、 メンバーを象んすることに問題はないとの見解であった。
しかし、リリース日の延期は避けて欲しいとの要望があり、『解決策B』を採用した。
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダーに一部の要件定義を行うメンバーの投入と基本設計の計画を担保することによる工数が30%超過した。
今回の問題における原因は、メンバーの要件理解度が低かったということである。
今後、このような事態を避けるために、以下を教訓とした。
【教訓】
(1)プロジェクト計画で必要とされる業務知識、技術知識を洗い出して有識者のレビューを受ける。
(2)要件定義で要件定義のスケジュールに悪影響を及ぼす要因の排除と今後の進め方についてクライアントと合意する。
STEP4：リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。
最後まで、読んで頂き有難うございました。
今後の貴方のプロジェクト活動の参考になれば幸いです。
