リスクを先読みしたプロジェクト管理

見積・要件定義フェーズでのリスク管理

見積・要件定義フェーズは、ユーザー要件に沿って見積（見積もり）を行うフェーズ、または、要件を定義して機能分類化していくフェーズです。リスクを先読みする、という意味では、プロジェクトの開始時にあたる同フェーズが、最も重要なフェーズになります。

筆者は、同フェーズにおいては、以下の観点でリスクを洗い出しています。

メンバー・アサイン時のリスクを洗い出す

見積を行うと、プロジェクト完了までに要する工数を算出できます。これに沿って、メンバーをアサインしていきます。

見積フェーズで意識すべき点は、メンバーにはそれぞれ得意分野と不得意分野があるということです。メンバーの特色を生かすように適正配置することが大切です。そうしないと、想定した生産性が得られず、見積時点における工数との乖離（かいり）が発生します。

メンバーの得意分野（勉強したい分野）と不得意分野をヒアリングするには、メンバーとのコミュニケーションが重要です。プロジェクトの規模が大きくなると、なかなか全員とコミュニケーションを図ることが難しくなります。朝会や夕会を行ったり、世間話をしたりするなど、率先してコミュニケーションの機会を作るようにします。

メンバーをアサインする前に、ユーザーとの間で設計書やマニュアルの記載レベルを確認しておくことを勧めます。設計書やマニュアルの記載レベルが想定と異なる場合、見積工数との間で乖離（かいり）が発生してしまいます。

社内にテンプレートがあるのなら、事前にユーザーに見せて、内容を確認してもらいましょう。こうして、記載レベルを確認したうえで、その後にメンバーをアサインするようにします。

システム要件・非機能要件のリスクを洗い出す

要件定義フェーズで重要なポイントは、ユーザーのシステム環境を把握することです。この範囲は非常に広く、ハードウエア／ソフトウエアと、多岐にわたります。

特に、ハードウエアは、なかなか把握しにくい点があります。しかし、テスト工程時やリリース直前に環境面での調整項目が発生すると、全体のスケジュールに影響を及ぼします。セキュリティやパフォーマンスといった非機能要件の整理とあわせて、ハードウエアのリスクを洗い出しておく必要があります。

機能要件のリスクを洗い出す

要件定義フェーズでユーザーの機能要件をいかに洗い出せるかは、当然ですが重要です。ただし、要件を洗い出すだけでなく、システム全体として整合性が取れているかどうか、特に、時系列でデータの整合性が担保されているかどうか、他システムとの連携時にデータの整合性が担保されているかどうか、などを洗い出すことが大切です。可能な限り、基本設計を進めながら要件を固めていくべきです。

スケジュール面のリスクを洗い出す

スケジュールの作成は、ユーザーが希望するリリース時期をゴールとして、各フェーズの線を引いていく作業を指します。これにあわせて、メンバーのリソースを割り当てていきます。

この際に注意すべき点は、スケジュールにバッファ（余裕）を持たせることです。線を引いたスケジュールに工数を割り当てるだけでは、何かが発生した時に調整がきかなくなります。

「ユーザー提示用のスケジュールが完成した後に、前倒しした社内コントロール用のスケジュールを作成する」など、複数パターンのスケジュールを用意することで、スケジュール調整のタイミングをつかんでおくことが重要です。

工数の割り当ては、スケジュールに多少余裕があるのであれば、1人が1カ月に行う作業を「1.0人月」ではなく「0.8人月」程度に設定したほうが、リスクを軽減できるでしょう。メンバーに対して最初から質と量の両方を求めるより、まずはメンバー数を増やしてから質を求めるようにしたいものです。

ただし、実際に漫然と0.8人月で作業をするわけではありません。メンバーの稼働状況は、できるだけ100％に近付けるようにすべきなので、「0.8人月で構わない」とメンバーが気を緩めないよう、前倒しした社内用スケジュールを用意しておくことが、バッファを作り出すために重要です。