開発プロジェクトの遅れに早く気づくには

開発プロジェクトの遅れに早く気づくには、「何%終わったか」という報告だけに頼らず、終わった作業と、予定では終わっているはずの作業を、一つずつ比べて確かめることが大切です。システム開発の遅れは、ある日突然に表れるのではなく、小さな兆しが積み重なって表に出ることが多いです。兆しに早く気づけば、打てる手も増えます。

この記事では、はじめてシステム開発を発注する方に向けて、進み具合の見方と、遅れの兆し、発注者ができることを説明します。

「何%終わった」が当てにならない理由

進み具合の報告でよく使われる「全体の80%まで終わりました」という言い方は、遅れを見落としやすい報告です。作業には、思ったより手間のかかる部分が後に残りやすく、「80%から先がなかなか進まない」ということがよく起きるためです。

割合の代わりに、作業を小さく分け、一つずつ「終わった・終わっていない」で数える見方が役に立ちます。作業を分けた一覧（WBS）があれば、次のように比べられます。

「終わった」の基準も決めておきます。たとえば、プログラムを書き終えただけでなく、テストまで終えたら「終わった」とする、といった決め方です。基準があいまいだと、ほとんど終わっているはずの作業が、後でやり直しになることがあります。

遅れの兆しになりやすい出来事

遅れの兆しは、作業そのものよりも、その周りの出来事に表れることがよくあります。次のような出来事が続いたら、注意して様子を見ます。

1. 決めごとの返事が遅れる：発注者が決めるべきこと（画面の内容、業務の決まりなど）の返事が遅れると、開発会社の作業が止まります
2. 課題の一覧が増え続ける：解決するより早く、新しい課題が増えていく
3. 同じ課題が何度も持ち越される：定例の会議で、同じ課題が「検討中」のまま続く
4. 予定の見直しが続く：小さな予定の変更がくり返され、そのたびに後ろの予定が詰まっていく
5. 担当者の交代や不在が続く：開発会社の側でも発注者の側でも、中心になる人が替わると、引き継ぎに時間がかかります
6. テストの開始が遅れる：作る作業が延びて、テストの期間が短くなっていく

見落としやすいのが、1つめの発注者の側の遅れです。システム開発は、発注者と開発会社が分担して進めるものです。発注者の返事が遅れることも、プロジェクト全体の遅れの原因になります。

定例の会議で確かめること

遅れに早く気づくには、定例の会議で、毎回同じ観点で確かめることが役に立ちます。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」では、発注者と開発会社が定期的に連絡協議会を開き、開発会社が進捗管理の報告を出して、遅れている事項の有無、遅れている事項があるときはその理由と対応策、体制の変更の要否などを協議する、という条項例を示しています。協議の結果は議事録に残す形です。

出典：情報システム・モデル取引・契約書（第二版）（IPA）

定例の会議では、次のような問いを毎回聞くと、兆しに気づきやすくなります。

• 前回から今回までに、予定していた作業のうち終わらなかったものはあるか
• 終わらなかった作業は、なぜ終わらなかったか。次はいつ終わるか
• 発注者の側の返事や作業を待っているものはあるか
• 新しく出てきた課題と、その影響
• 次の大きな区切り（テストの開始、公開など）に間に合いそうか

報告を受けるだけでなく、疑問に思ったことはその場で聞くことが大切です。課題の一覧には、課題ごとに担当と期限を書き、期限を過ぎた課題がいくつあるかを毎回数えると、増え方の変化に気づきやすくなります。「問題ありません」という報告が続いていても、具体的な作業の状況を聞くと、隠れていた遅れが見えることがあります。発注する側の担当者がすることは発注する側のプロジェクト管理。担当者がすることでも説明しています。

遅れに気づいたら、発注者ができること

遅れに気づいたら、まず原因と対応策を開発会社と一緒に確かめます。原因によって打つ手が変わるためです。

対応を決めるときは、「範囲」「納期」「体制（費用）」のどれを調整するかを考えます。3つとも変えずに遅れを取り戻すのは、難しいことが多いです。範囲を絞る場合は、どの機能が業務に欠かせないかを、発注者の側で決めておく必要があります。範囲や納期が変わる場合は、変更の手順に沿って記録を残します（開発の途中で仕様を変えたいときの進め方）。

なお、準委任などの契約で、発注者が開発会社の技術者に直接、作業の指示を出して遅れを取り戻そうとすると、偽装請負とみなされるおそれがあります。対応の相談は、開発会社の責任者を通して行います。

始める前にできること

遅れに早く気づける体制は、プロジェクトを始める前に整えておくのが効果的です。始まってから仕組みを作ろうとすると、目の前の作業に追われて後回しになりやすいためです。

• 作業を小さく分けた一覧と、それぞれの終わりの基準を作ってもらう
• 定例の会議の頻度と、報告の形を決めておく
• 発注者の側で、決める人と、返事の期限を決めておく
• 大きな区切りごとに、続けるかどうかを判断する場を設ける

最初の要件を固める段階の進め方は要件定義で決めること：はじめての方へで説明しています。

当社のご支援

当社のWebシステム開発では、区切りごとに、できたものをお客様と一緒に確かめながら進め、食い違いを早く見つけるようにしています。他社と進めているプロジェクトの進め方を相談したい場合は、相談や小さな開発を月単位で頼めるAIタイムシェアもご利用いただけます。技術者がお客様の現場に入って開発を進めるFDEの形もあります。まずはお問い合わせからご相談ください。