【プロジェクト計画書作成編】リスクの明確化と対策をお忘れなく（後編）

ボクの普段の仕事は、ザックリいうとWebサイトの構築、システム開発などのプロジェクトマネージャーとしてプロジェクトを設計したり管理・進行を15年以上行っております。

プロジェクトの規模としては、数千万円～億単位のものまで様々で、期間としては数か月～年単位のプロジェクトが多いです。

今回は、プロジェクトマネージャーの業務としてプロジェクト計画書を作成することがあると思います。そこで、プロジェクト計画書を作成する際に最も重要なプロジェクトのリスクについて（前編）（後編）で記事を書きます。
今回も備忘録として残しておきますので興味がある方は、参考にしてみてください。

プロジェクトにおけるリスクとは何か?

構築プロジェクトを進行していくうえで、リスクの洗い出しと周りへの周知はとても重要な業務です。
この工程で手を抜いてしまうと、大きなトラブルに発展してしまい、プロジェクト進行どころではなくなってしまいますので、しっかりとプロジェクト開始時にリスクの明確化と対策を計画して、請負の場合は、クライアントへ丁寧に周知させて、ルールを定めておきましょう。

プロジェクトのリスクを洗い出す際は、大きく下記の3つに分けてリスクを洗い出します。
①プロジェクト進行リスク
②技術的リスク
③契約上におけるリスク（請負の場合）

（後編）

②技術的リスク

プロジェクト計画を作成するときの状態では、詳細設計まで見えている状態ではないので、ある程度、想定での計画となってしまいます。
技術的リスクにおいては、ちょっとした認識の齟齬で、工数やスケジュールに大きな影響を与えてしましますので、プロジェクト計画では、しっかりと技術的前提事項をしっかりと明記しておくことが必要です。

• スコープと技術的要件

• 納品成果物

• 品質と評価

• 納品・検収

＜スコープと範囲＞

まずは、ここを曖昧にしてしまうとリスクが高いので、できるだけ細かく定義しましょう。
※下記の想定は、要約しているので、できるだけ細かいほうがリスク回避になります。

フロントエンド

• 対象サイト（ドメイン単位）

• 想定サイト構成

• 想定ページ数

• ページカテゴリーごとの制作難易度ランク分け（設計・デザイン、コーディング、外部ツール組み込みなど）

• 想定開発言語・フレームワーク・ライブラリー

• 外部ツール（CMS・地図・検索など）

バックエンド

• 対象システム

• 想定システム構成図

• 想定開発言語・フレームワーク・ライブラリー

• 想定API数

• 想定バッチ数

• 外部連携

• 想定サーバー構成

• 想定使用ツール、サービス（セキュリティなど）

＜納品成果物＞

納品成果物については、項目とざっくりとした内容だけを記載しているプロジェクト計画書を見かけますが、これだと、検収時にトラブルになる要因となりますので、できるだけ、＜スコープと範囲＞に合わせて細かく定義しましょう。
成果物イメージなどを付けると、想定外だったなんてリスクも避けられます。

＜品質と評価＞

品質と評価基準を記載することで、プロジェクトオーナーに対して安心感を得られます。
また、ここを明確にしておかないと、開発メンバーが複数の場合、最終的な品質担保が難しくなるため、早い段階で明確化して周知しておく必要があります。

1. 品質基準を設定し、プロジェクトの目標と一致する品質レベルを確保

2. 品質管理計画を策定し、品質監査やテストのスケジュールをスケジュールに組み込む

3. 品質基準の明確化と合意

4. 必要な修正や改善をスケジュールに組み込む

5. 最終的な品質チェックと、プロジェクトの成果物が要求仕様に適合していることを確認するスケジュールを明確にして組み込む

＜納品・検収＞

プロジェクトマネージャーとして、一番気を回す箇所です。
よって、プロジェクト計画段階でいかにここのルールを明確にして、合意をとっているかが、その後のプロジェクト進行において、トラブル回避となります。

また、いくらプロジェクト計画段階で明記していたとしても、プロジェクトを進行している中での要件変更や仕様変更など必ずと言ってもよいほど起きてしまいますので、必ず、納品タイミングの遅くとも１ヶ月前には、最終成果物の擦り合わせMTGをプロジェクトオーナーと実施し、成果物の受け入れルールの最終確認、現在進行している実際の成果物を踏まえて、成果物目線で認識合わせを行いましょう。
※プロジェクト進行中の制作物と成果物では、認識の齟齬があったりしますので、成果物目線というのが重要なポイントです。
これを怠ると、検収ができないなど、トラブルに発展してしまします。

プロジェクトオーナーとの成果物の受け入れルールの最終確認、成果物目線で認識合わせのMTGでは、認識の齟齬が生まれないためにも、議事録・録画などエビデンスをしっかりと取っておくとよいでしょう。

③契約上におけるリスク（請負の場合）

請負などプロジェクトオーナー（クライアント）から委託をうけて、開発を行う場合は、契約書の作成にも気を配る必要があります。

中には、請負ということを理由に、散々確認遅延、明らかな要件変更、要件追加をしても、発注元の認識としては、スコープ内と考えているので、スケジュールを超えても対応を迫ってきたり、何度も成果物のすり合わせを行い合意を取って、エビデンスを共有していても、表現の違いや認識の違いを理由に最終的な成果物が納得いかないと検収を行わず、追加で対応を迫ってくるプロジェクトオーナーも存在します。

そこで、重要になってくるのが契約書です。

請負契約とは、「業務受注者が、委託された業務を完成させることを約束し、業務発注者は完成された仕事の結果に対して報酬を支払う契約」と定義されていますので、上記のようなトラブルに発展するケースが出てくるのが現状です。

これを回避するためには、条項の取り決めを細かく評価して、スコープ、スケジュール、工数（費用）への影響リスクを洗い出し、対策を条項に組み込むことにって回避することが必要です。
請負契約の定義としては、「完成された仕事の結果に対して報酬を支払う」とありますが、プロジェクト進行においては、スコープ、要件、スケジュールなどの変更によって、工数（費用）が増加することが当たり前です。しかし、請負だからって詰め放題の認識で、それを認識していないプロジェクトオーナーもいらっしゃいますので、条項に要件変更や遅延によって費用の増加やスケジュールの変更について明記しておくとよいでしょう。

プロジェクトマネージャーは、契約書の条項を細かく把握してプロジェクトを進行しないと泣き寝入りをするとともにすべての責任を押し付けられる事も容易にあるため、細心の注意をはらっておきましょう。

以上

プロジェクト計画書を作成するうえで、ボクが一番気を使うのが、うまく進行する事よりもリスクへの対策をしっかりと行うことです。

これを、しっかりと行うことにより、プロジェクトオーナーを含めてストレスなくプロジェクトを進行できますので、よろしければ参考にしてみてください。

また、気が向きましたら記事を書きます。