こんにちは。ネオシステムの高橋です。
前回はシステム開発チームのメンバー役割について紹介しました。
今回は、ウォーターフォール開発における要件定義フェーズに入ったとき、具体的にどんなことをするのかをまとめたいと思います。
プロジェクトマネージャー(以下、PM)は要件定義において、どのような責任を負わなければならないのか見ていきましょう。

目次

プロジェクトの計画立案と実行
プロジェクトの監視・コントロール
プロジェクトの評価と完了判断
まとめ
参考資料

プロジェクトの計画立案と実行

最初のステップのメインは計画を立てることです。
そこでPMは以下の責任を負う必要があります。

要件定義プロセス計画を作成する

要件定義で必要なプロセスと成果物を見極め、要件定義の計画を立案する
記載レベルを定義する
成果物作成の担当を決める

以下に成果物とその担当者の例を示します。

前回の記事ではメンバー役割について説明しましたが、どのメンバーがどの資料を作成するべきかを表しています。
企画プロセス段階で作られる成果物は業務部門が担当することが多いですが、要件定義が進むにつれ開発部門が担当する範囲が広がります。
要件定義フェーズの中で3つのプロセスに分かれていますが、プロセスの詳細についてはこちらの記事をご参照ください。

スケジュールを作成する

承認に要する期間をあらかじめ織り込んでおく
必ず実施するべきことと省略できることに分ける
するべきことは期間を変更してでも漏らさずやるよう計画する

費用を見積もる

要件定義の途中でもシステム構築費用が概算見積りできるように計画しておく
有識者を投入して規模概算の精度を上げる

体制を組む

プロジェクトに必要な体制を構築する
チームの発達段階を理解し、メンバーに働きかける

プロジェクト体制とは
各部門の責任者を設定したり、部門間で情報を共有したりするための仕組みのことです。
システム開発にかかわる部門数、外部の組織数、人数はプロジェクトによって異なります。

振り返りの実施
要件定義から納品までを1フェーズととらえた時、1フェーズが終わるタイミングでプロジェクト体制やコミュニケーション計画が適切であったのか、改善する必要があるのかを振り返ることも大切です。

品質を計画する

要件定義ドキュメント作成の関係者と合意する
成果物のチェックリストを作成する
定期的にドキュメントのレビューを行う

コミュニケーションを計画する

伝達相手、伝達内容、媒体、頻度を計画する
議事録等に記録・配布し、共通認識を積み重ねていく

コミュニケーション計画とは
「伝達相手」「伝達内容」「媒体」「頻度」を適切に決めることです。
各部門のリーダーは誰か、情報をどのようにして共有・エスカレーションするのか、リーダーや上位層と連絡を取るためにどのような手段を設定するかが重要です。

リスクを認識する

発生の可能性があるリスクを洗い出し、発生確率、影響度を割り出す
優先度を付け、対応策を練る

調達を計画し、契約を結ぶ

各工程において委任か、請負か線を引く

プロジェクトの管理計画を作成する

進捗管理、課題管理、変更管理、品質管理、リスク管理に関する管理ルールを取り決めておく
プロジェクト管理計画(管理の仕組み)を事前に作成し、オーナーを含む関係者と合意する

プロジェクトの監視・コントロール

要件定義が最初に立てた計画通りに進められるように、PMは軌道に乗せる必要があります。

要件量とスコープを設定する

膨らむ要求を収束させる
要件の変更を当事者間で安易に受け入れさせないようにする

スケジュールをコントロールする

細かいチェックポイントを設けて、進捗遅れを早期発見、早期対処する
上位マネジメントの関与不足による遅れ対策をあらかじめ考えておく

スケジュールについての詳細は、WBSを作る前に知っておきたいことを参考にしてみてください。

品質を担保する

要件の抜け漏れをなくすために作ると決めた成果物を作れているかチェックする

チェックリストの例はこちら↓

コミュニケーションをとる

業務知見がある適任者をプロジェクトに参画させ、仕様を決められる人を用意する
うまくいかない場合はエスカレーションし、問題の解決を図る

リスクをフォローする

進捗会議やプロジェクトレビューなどでリスクの棚卸しをして、メンバーと共有する
大きいリスクはエスカレーションする

トレーサビリティ(追跡)を管理する

要求の抜け・漏れを確認する
要求事項を台帳管理し要求が変更になったらもれなく修正する

要求一覧シートの例はこちら↓

プロジェクトの評価と完了判断

要件定義を終了し基本設計に移る前に、PMは何をしなければならないのかを見ていきます。

要求を評価する

関係者を集めて要件定義の結果に問題がないことを確認します。
内容に自信が持てないならそこには何らかの問題があるのかもしれません。
思い切ってやめることも時には重要です。

完了を判断する

成果物の妥当性をプロジェクトオーナーを交えて確認しましょう。
未決事項がある場合は、解決する期日が明確か、システム開発に影響がないか等のリスクを分析する必要があります。

まとめ

PMが要件定義でやらなければならないことについてまとめました。
ウォーターフォール開発では要件定義が一番重要であると言われているのでPMの負担も大きく感じますが、逆を言えばPMの腕の見せ所なのではないかと思います。

次回の記事はビジネス要求定義における問題と解決策について投稿します。
こちらも併せて参考にしてみてください。

参考資料

ユーザのための要件定義ガイド第2版要件定義を成功に導く128の勘どころ