プロジェクト工程のつなぎ目に注意する

はじめに

ITシステムの開発プロジェクト、特に基幹システムの構築といった大規模で長期間にわたるプロジェクトでは、複数の工程に分けて進めていくのが一般的です。各工程の呼称や構成はベンダーやプロジェクトごとに若干の違いはありますが、おおむね以下のような流れで共通しています。

出典）青山システムコンサルティング株式会社『図解即戦力システム外注の知識と実践がこれ1冊でしっかりわかる教科書』, 技術評論社, 2024年5月, 162ページ

これは、前の工程をきちんと終えてから、次の工程を開始する進め方です。
プロジェクトが順調であるほど、次の工程には勢いそのまま移っていきたいものですが、工程の間をつなぐタスクにしっかりと対応できていないと、前の工程をきちんと終えられない、次の工程で良いスタートを切れない、といったことが起き、それが後々までプロジェクトの足を引っ張ってしまうことがあります。

工程の間をつなぐタスクにはどのようなものがあるか

工程の間をつなぐタスクには、ユーザー側が主体的に行わなければならないものが少なくありません。
しかも、それらはベンダーが作成するスケジュールには考慮されていないことが多いので注意が必要です。

また、ユーザー側もベンダーとの日々のやり取りに追われていると、社内中心で行うタスクについては、対応を後回しにしたり、軽視したりしてしまうことがあります。

これらの対応が中途半端な形になると、後々のトラブルにつながってしまうことがあるため、あらかじめスケジュールに織り込んで準備を進めておくことが必要です。

どのようなタスクがあるか、具体例で見ていきましょう。

前工程の成果物の確認

特に、先に示した図の要求分析、要件定義、基本設計といった工程では、ベンダーは相当量の成果物を作成してきます。ユーザー側の担当者が、それらの成果物をしっかりと確認するためには、十分な時間を確保することが必要です。

もし、成果物に重大な不備が存在し、確認を怠ったことでそれを発見できなかった場合、必要な機能や性能を満たせていないシステムが作られてしまいます。

どのくらいの期間で確認できる量なのかを把握し、あらかじめスケジュールに反映させておくことや、作成されたものから順次確認するといった工夫をすることが必要です。

次工程以降の計画の確認

次工程以降の計画については、基本的にはベンダーが作成しますが、ユーザー側もその内容を十分に確認する必要があります。次工程以降における、ユーザーとベンダーの作業分担をよく理解し、どの時期にどのような作業があり、どのくらいのリソースを費やすことになるのかを想定しておきます。

そして、それに応じた社内体制を整備したり、必要に応じて、ユーザー側の意向をベンダーに伝え、計画に反映してもらったりといったことも必要です。

計画の内容は、次に述べる見積書や契約書の内容にも影響します。見積書や契約書の確認や交渉にかかる時間も踏まえて、あらかじめベンダーには、計画を提示してほしい時期を伝えておきましょう。

次工程以降の見積書や契約書の確認

ITシステム開発の見積書や契約書の内容は、不慣れな人にとってはとても難解です。さらに、価格や契約内容について交渉することも含めると、相当な時間と労力を要します。しかし、ここで手を抜くことも禁物です。

見積書の確認をおろそかにすると、後になって、見積り漏れによる追加費用が発生してしまったり、不必要なものに対して支払いをしてしまったりといったことが起きる恐れがあります。

また、契約書については、十分な確認や交渉の時間が持てずに、ベンダーが持っている雛型をそのまま採用してしまうケースがありますが、そうした雛形は往々にしてベンダーに有利な内容になっています。争いは起きないに越したことはありませんが、重大なトラブルが発生した際に、依るべきものは契約書です。最悪のケースも想定し、契約書は内容をしっかりと確認した上で締結すべきです。

ここでは十分な時間を確保すること以外にも、法務部門などの社内有識者や、外部の専門家の協力を仰ぐといったことも検討しておきましょう。

社内の承認手続き

ITシステムの開発プロジェクトはかかる費用も大きいため、前工程の終了、次工程の着手には、経営層の承認が必要となることが多いかと思います。

承認が行われる役員会などは、あまり高い頻度で開催されるものではありません。ここをスムーズに進められずやり直しを繰り返してしまうと、簡単に何週間も遅れを発生させてしまいます。できる限り、「ここだ」と決めた会で、きっちりと済ませたいものです。

スムーズに承認手続きを進めるためにも、経営層とプロジェクトチームの間には定期的なコミュニケーションの場を別途設けておきましょう。プロジェクトについて、普段から経営層とプロジェクトチームで意見交換ができていれば、承認に必要なものの準備も適切に行えることでしょう。

おわりに

今回あげたようなタスクは、どれも相応の時間と労力を要するものですが、プロジェクトのスケジュールやリソースの制約により、全てをしっかりと対応できているケースはそれほど多くないように思います。

もし、スケジュールや費用の面で許容できるのであれば、作業量が特に多くなりそうな工程の間には、ベンダーとも合意の上で、それらに対応するための期間を設けておくのもひとつの手です。

プロジェクトをより成功に近付けるためにも、工程の終わりと始まりに対応すべきことが他にもないか再度確認し、必要な対策を講じていただければと思います。