システム開発のプロジェクト管理で注意すべき点を解説

はじめに

皆さまの会社では、基幹システムの構築など大掛かりなシステム開発を外部のベンダへ委託する際に、プロジェクト管理にはどこまで関与されますか？
一般的にはユーザー側と合意したスケジュールに沿ってベンダ側がマイルストーンやWBSを作成し、週次や月次でベンダからの進捗や課題の状況などが報告され、ユーザーが確認するということが多いかと思います。
ユーザーからするとよほど大きな遅延や課題などがベンダから報告されない限り、WBSの細かいチェックや今後のリスク管理を積極的に行うということは少ないと思います。

ですが、実際に進めてみるとシステム開発のプロジェクトは基本的に遅れるもの、というイメージも強く、多少の遅延はユーザーとしても許容せざるを得ないというのが多くのプロジェクトの現状ではないでしょうか。サーバーの保守期限の兼ね合いなどで納期を厳格に守る必要があるプロジェクトの場合はリリース時期を分けて初期リリース分だけは納期通りに行う、などの対応を取るケースも多いと思います。
いずれにしても計画通りに行かずにシステム開発費用が膨らんだり、事業に悪影響を及ぼす可能性もあるため、困るのはユーザー側です。

さて、それではそのような大事なプロジェクトの管理をベンダに任せきりで本当に大丈夫なのでしょうか。
ユーザー側でも積極的にプロジェクトの管理について、計画、進捗のチェックやリスク管理などに関与していく必要があるのではないでしょうか。
以下に、ユーザー側としてプロジェクト管理について確認すべきポイントをいくつか挙げます。

ベンダ選定フェーズ

計画のチェック

まずはベンダ選定フェーズのベンダ提案時に、ユーザー側で依頼した納期に対してベンダ側は大まかなスケジュールを作成します。スケジュールの妥当性をユーザー側でも確認する必要があります。

・バッファ

スケジュールにどの程度のバッファ（不測の事態に備えて設定する安全余裕期間）を見込んでいるのかをベンダに確認しましょう。見積工数自体を全体的に多く算出する、タイトに算出した見積工数にバッファ係数を掛けている、などベンダにより様々だと思いますが、根拠としては後者が望ましいですし、説明を明確にできない、バッファ自体を一切積んでいないなどのベンダは、プロジェクト管理に不安があるため委託しないのが賢明懸命だと思います。

・リスク管理

プロジェクトに外部要因として不確定要素がある場合（例えば別のシステムと連携するが連携先は別のベンダが開発するなど）、どの時点までに何が決まっていない場合はプロジェクト進行に影響を及ぼす、などのリスク管理が必要です。提案書に記載が無い場合は確認しておきましょう。リスクと対応策の案まで出てくると安心です。

ユーザー側作業のチェック

要件定義時の打合せ参加や、ユーザーテストの計画をベンダ、ユーザーどちらが作成するのかなど、ユーザー側としてどの時期にどれくらいの工数を割く必要があるのかを確認しましょう。土壇場になって作業を依頼されてユーザー側が対応できずにプロジェクトが遅延するようなことは避けたいですし、土壇場になって作業を依頼するようなベンダには委託したくないため、この時点でベンダがどこまでプロジェクト計画を検討できているのかを見定める目的でも確認しておいた方が良いです。

開発フェーズ

開発フェーズに入ると、プロジェクト管理としては主に進捗や課題状況の確認が必要となります。このフェーズでもユーザー側としてしっかりとプロジェクト管理に関与していきましょう。

計画のチェック

提案時よりも、より詳細な計画をベンダが作成します。こちらもユーザー側で妥当性を確認する必要があります。

・バッファの詳細

どこに、どれだけ、どんな根拠でバッファを積んでいるのかを明確にする必要があります。参考までにプロジェクト管理手法CCPM（クリティカルチェーン・プロジェクトマネジメント）では各タスクのバッファを取り除き工程全体の最後にバッファを積むべきという考え方です。バッファの積み方はプロジェクト規模にもよるため、ベンダがどのようにバッファを管理していくのかを確認します。

・外部調整

特に外部システムとの連携がある場合などには、インタフェース部分の仕様調整や結合テストをどの時点でどこまで実施するのか、外部との調整が必要となります。ベンダ側としては外部要因で遅延する場合には責任を追及されないことも多いため、それほど積極的には課題とせずにユーザー側に丸投げのことも多いです。ユーザー側から積極的にプロジェクト内での計画と外部の計画との間で問題が生じないか確認する必要があります。

進捗のチェック

・進捗報告自体の正確性

○○作業は何割程度の進捗なので問題ありません、という報告を受けることがあります。どのように割合を算出しているのか根拠を確認しましょう。例えば画面数を単純に割合とするなどとすると、画面ごとの難易度が考慮されておらずに、難易度の高い画面の作業に差し掛かると突然進捗が止まり、遅延することになりかねません。画面ごとに重みづけをした上で割合を出す、割合ではなく画面ごとの残作業の日数ベースで報告する、など進捗報告の仕方について改善を要求しましょう。

・リカバリプランの妥当性

予定より○○日遅延です。など遅延の報告のみの場合、どのようにリカバリするのかを必ず確認しましょう。人を増やすのか、優先度の低いタスクを後回しにするのか、その場合の後続タスクへの影響はどうなるのか、単に来週までにはリカバリします、の報告が毎週続くと雪崩式にプロジェクトが崩壊していく危険があります。

課題管理

プロジェクトを進めていくと必ず大なり小なり課題が山積みになります。ベンダへ任せきりになっていると、プロジェクトの最後になってユーザー側の課題が解決できていないことが理由でプロジェクトの遅延に繋がることも多いです。

・課題の色分け

課題ごとにユーザーとベンダでどちらがボールを持っているのか、今後どのように課題を解決していくのか、いつまでに課題が解決しないと何に影響を及ぼすのかを、課題を色分けして優先順位付けをできる課題管理の仕組みとなっているか確認しましょう。

・コミュニケーションと頻度

週次で課題の打合せを行う、棚卸を行う、など、課題が置き去りになってしまわない課題管理の進め方となっているか確認しましょう。

リスク管理

前述したリスク管理についても、ものにはよりますが最低月次くらいの頻度では、現在のリスクがどのような状況となっているのかを確認しましょう。

おわりに

今回は、ユーザー側としてプロジェクト管理について確認すべきポイントをいくつか挙げました。

会社の大事なプロジェクトをベンダに任せ切りにしてしまい、プロジェクトを失敗させてしまうことは、当然ベンダ側にも責任はありますが、厳しい言い方をするとユーザー側としての怠慢でもあります。

今回のコラムをご参考にして頂き、是非積極的にユーザー側としてもプロジェクト管理に関与して頂くことを強く願います。

弊社もサービスとしてプロジェクト管理の支援やベンダ評価・選定サービスを行っておりますが、ユーザーに主体性が無いと支援が困難なケースもございますので、まずは自分ごととしての意識を持って頂くことが何より重要と考えております。

少し毛色は違いますが、最近弊社のメンバーが執筆した書籍「図解即戦力-システム外注の知識と実践がこれ1冊でしっかりわかる教科書」（出版：技術評論社）にもプロジェクトの各工程でユーザーが気を付けなければならないポイントなどがまとまっておりますので、機会がございましたら併せてお読み頂けますと、よりシステム外注を行う際の開発プロジェクトへの理解が深まるのではないでしょうか。

システム開発のプロジェクト管理で注意すべき点を解説