前フェーズを総括すれば、その後の見通しが得られるようになる
itpjstudy
以前の回で、何か問題がある場合は、たいてい前のフェーズで原因が埋め込まれているというお話をしました。今回は、その逆のお話です。現フェーズできちんと状況を把握できていれば、次フェーズ以降に起こりえる問題を捉えることができる。そうすれば、うまく問題に対処できるのではないか、というお話です。
今回は、どのように現フェーズを確認すれば良いのかについて、説明します。
Must-Read Insights
問題の原因は、前のフェーズで埋め込まれている
以前、システムテストフェーズで検知される問題について取り上げました。問題として顕在化したのはシステムテストフェーズですが、その原因は、たいてい、それよりも前のフェーズで埋め込まれています。
以前のケースでは、前のフェーズでは検知できなかったため、システムテストフェーズで問題になっていました。しかし、問題が埋め込まれたタイミングで、問題の原因事象を検知できていれば、もっと簡単に対処ができたはずです。
後続フェーズのリスクは、実は、簡単に把握することができる
例えば、要件定義フェーズで、色々な困難があったとします。そういった場合、なんとかツジツマをつけて、設計フェーズに入ったとしても、色々な問題に直面する可能性が高いです。
例❶ 要件定義フェーズ終了時点で見えている設計フェーズのリスク
[きちんと見ていれば、分かること] 他業務領域に比べて、出荷業務に関してはリスクが大きい。
- 要件定義フェーズで課題が多発している業務領域は、設計においても、色々な課題が出てくることが多い
- 要件定義フェーズ中にすべての検討項目を検討完了できず、設計フェーズに持ち越した場合は、本来決まっているべき業務要件が決まっていないため、関連設計で手戻りのリスクが発生する
他の例も見てみましょう。
例❷ 開発フェーズ終了時点で見えているテストフェーズのリスク
[きちんと見ていれば、分かること] 出荷領域は引き続き、リスクが大きい。
- 設計残や仕様変更で手戻りが多発している場合、必要な品質が維持できずに、テストフェーズで品質問題が起きる
- 若手が大量に投入されることで、開発品質が下がるうえに、スキル者によるレビューが十分に行えず、こちらも、テストフェーズの品質問題を引き起こす
このように、実施中のフェーズの状況をきちんと理解できていれば、後続フェーズのリスクを把握するのは、それほど難しくはありません。しかし、実際には、問題事象を把握しつつも、後続フェーズでの対策を打ち切れずに、問題発生に至るケースも珍しくありません。
なぜか。
せっかくのリスク把握も、後続フェーズのスケジュール調整で終わってしまうことが多い
終わらなかったタスクを、次フェーズへ持ち越しすることは、よくあることです。それ自体は、大きな問題ではありません。ただ、多くのプロジェクトでは、単純なスケジュール調整で終わっているように見受けます。
全体リーダ
設計フェーズで決め切れなかった課題がいくつかありますが、後続スケジュールを考えると、開発フェーズを始める必要があります。
リーダ
設計課題が全部解消していないのに、開発フェーズを始めてしまって、大丈夫ですか。
全体リーダ
設計課題の解決が遅れても、後続のスケジュールが大丈夫なように、設計スケジュールを見直したので、問題ありません。
こういったやり取りは、皆さんのプロジェクト現場でも、多くあるのではないでしょうか。しかし、このスケジュール調整だけでは、せっかく把握している情報を生かし切れていません。ほんとうは、もっと色々な打ち手が考えられるはずです。
では、どうするか。
大きなフェーズやタスクに関して、総括をする
王道は、きちんと総括レポートを作成して、皆で確認することです。プロジェクトが順調なときは、フェーズごとに総括レポートを作成しながら、後続フェーズへ進んで行くと思います。しかし、順調でなくなってくると、「レポーティングよりも、現場作業を少しでも前に進めたい」と、総括レポートがおざなりになっていく傾向があります。
ただ、総括レポートは、単にレポーティングのためのものではありません。そのフェーズでの状況を皆で振り返って、次フェーズに備えていくためのものです。
今回は、ERPプロジェクトの要件定義フェーズの総括レポートを題材に深掘りしていきます。
要件定義フェーズ 総括の目次イメージ
- はじめに
- 本書の目的
- プロジェクト概要（スコープ／期間／体制）
- 要件定義フェーズの位置づけと進め方
- 要件定義フェーズの実施内容
- ワークショップ／Fit-to-Standardセッション実施概要
- 各種インタビュー・業務分析の概要
- プロセス範囲（業務領域：販売、購買、生産、会計など）
- 標準機能とFit & Gap判定の方針
- 各チームのアウトプット一覧（業務フロー、業務要件、画面要件、帳票要件、IF要件 等）
- 業務要件のサマリ
- 業務プロセス概要（To-Be）
- 業務フロー（ハイレベル）
- 業務要件一覧（主要要件の要約）
- 標準対応（Fit）項目
- アドオン開発（Gap）項目のサマリ
- 今後の詳細設計で深掘りが必要な論点
- システム要件サマリ
- 機能要件
- 非機能要件（性能、アクセス、セキュリティ、ログ、運用など）
- 他システム連携（IF）概要
- データ移行要件（移行対象範囲、方針）
- マスタ整備方針（マスタ範囲、整備責任分担）
- Fit & Gap 分析結果のまとめ
- Gap件数・分類（難易度、優先度など）
- Gap対応方針（アドオン、プロセス変更、運用対応など）
- 主要Gapの説明（対応案、検討状況）
- コスト・工数見積もりへの反映
- 課題・リスク
- 現時点の課題一覧
- リスク一覧（影響度・発生可能性）
- 課題／リスクの対応方針・オーナー
- 次フェーズへの持ち越し事項
- 成果物一覧
- 要件定義フェーズで作成した成果物（一覧 + 保管場所）
- 承認状況（ワークショップ議事録、要件一覧、スコープ文書 等）
- スコープ確定内容
- 対象プロセス（In-scope / Out-of-scope）
- 開発スコープ（アドオン一覧・優先度）
- データ移行スコープ
- テスト・教育向け準備に関するスコープ
- 次フェーズ（設計フェーズ）への申し送り
- 次フェーズの目的と主な作業
- 申し送り事項（課題、決定待ち事項）
- スケジュール（マイルストン）
- 今後の体制（役割・責任）
- 総括コメント
- プロジェクト全体総括
- 要件定義フェーズの振り返り（成功点・改善点）
上記は、典型的な要件定義フェーズの総括レポートの目次です。ここから、どんなことが見えてくるでしょうか。いくつかを例に見てみましょう。
例1. 「Fit & Gap分析結果のまとめ」の章
把握できるリスク例
- Gapが多く発生している業務機能は、今後も継続的にGapが検知される可能性がある
- また、設計や開発のボリュームが大きくなり、遅延やコスト増の可能性がある
リスク回避のための打ち手例
- リスクのある業務機能に対して、高スキル者を配置するなどして、体制を増強する
- 加えて、週次進捗報告で、他業務領域よりも詳細な報告を求めることで、適宜対策が打てるようにする
例2. 「課題・リスク」の章
把握できるリスク例
- 未解決の課題には、更なる遅延や手戻りの可能性がある
- また、未解決の課題に引きつられて、関連する業務領域の作業を止めてしまう可能性がある
リスク回避のための打ち手例
- 更なる遅延や手戻りを想定して、予めスケジュール・バッファを設けておく
- 課題の早期解決を促すべく、検討段取りの詳細化やマネジメントの巻き込みなどの仕掛けを設ける
例3. 「システム要件サマリ」の章
把握できるリスク例
- 重要で難しいインタフェースを開発しなければならない既存システムがあり、当既存システム側の改修が遅れると、プロジェクト全体の大きな遅延になる可能性がある
リスク回避のための打ち手例
- ERP側との設計すり合わせがスムーズに進むよう、個別に定例会を設定して、高頻度にコミュニケーションする
- 本既存システムについては、ERPプロジェクトの全体進捗会議にて、進捗を報告して貰うことし、ERP側と同レベルの見える化を実現する
こうやって総括レポートを作って、ちゃんと見てみると、単純にスケジュール調整するだけでなく、本当は色々なリスクがあり、様々な打ち手を考えなければならないことが分かります。
冒頭でもお話したように、後続フェーズでの問題の多くは、前のフェーズにその原因があります。そして、実は、そういった原因事象があるということは、前のフェーズの時点で把握できていることが多いです。しかし、日々の忙しさにかまけて、十分に目を向け切れていないように思います。
「総括レポート」は、面倒に見えます。しかし、節目節目で立ち止まって、しっかり現状を振り返ることが、色々な気づきにつながっていきます。そういう意味では、気付きを得る大事な機会だと考えて、面倒でも総括していくことが重要だと考えます。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
