システム開発の進捗確認のしかた｜定例会とデモの見どころ
システム開発を外注すると、進み具合が見えにくくなりがちです。この記事では、発注側が進捗を確かめるための二つの場、定例会とデモで何を見ればよいかを整理します。「順調です」という報告の中身を確かめる質問と、動く画面を見るときの着眼点が分かります。
進捗の報告を聞くだけでは、状況が分かりにくい理由
外注先から「進捗は8割です」と報告を受けても、残りの2割が同じ大きさとは限りません。システム開発では、最後の調整や結合、テストに想定以上の時間がかかることが珍しくないためです。進捗率という数字だけでは、実際の状況を測りにくいのが実情です。
背景には、発注側と開発側で「できた」の意味が違うことがあります。開発側は「プログラムを書き終えた」を完了と捉え、発注側は「業務で使える状態になった」を完了と捉える。この差が、終盤になって「思っていた状態と違う」という形で表に出ます。遅延の原因はシステム開発が遅延する原因と、発注時にできる防ぎ方でも整理しています。
進捗確認で大切なのは、報告を疑うことではありません。お互いが同じものを見て、同じ言葉で状況を話せる場をつくることです。そのための仕組みが、定例会とデモです。
- 定例会：進み具合、課題、決めるべきことを言葉と資料で確認する場
- デモ：実際に動く状態を見て、触って、できていることを確かめる場
この二つは役割が違います。定例会だけだと言葉の世界に閉じてしまい、デモだけだと判断すべき事項や課題の整理が抜けます。両方を組み合わせて初めて、進捗が立体的に見えてきます。
定例会で確認したいこと
定例会は、週に1回、または2週間に1回といった決まった頻度で開くのが一般的です。時間を取られるだけの会にしないために、毎回同じ観点で確認します。
進捗率ではなく「完了の定義」で聞く
「何%進みましたか」と聞く代わりに、「どの機能が、どの状態になりましたか」と聞きます。たとえば次のような区切りです。
- 画面ができた
- 画面とデータ登録がつながった
- 想定外の入力でも壊れないことを確かめた
- 発注側が実際に触って確認した
機能ごとにどの段階まで来たかを一覧にしてもらうと、報告が具体的になります。「完了」と書かれた項目が、上のどの状態を指すのかを最初に合意しておくと、後のすれ違いが減ります。
予定と実績の差、その理由
当初の計画と比べて、進んでいるのか遅れているのかを確認します。差が出ていること自体は問題ではなく、むしろ自然なことです。見るべきは差が出た理由です。
- 想定より作業が大きかったのか
- 仕様が曖昧で手が止まったのか
- 発注側の確認や回答を待っていたのか
- 技術的な課題が見つかったのか
理由が分かれば、対処も決まります。発注側の確認待ちが原因なら、発注側が動くことで解消できます。反対に、理由があいまいなまま「少し遅れています」とだけ報告される状態が続くなら、状況を整理して共有してもらうよう依頼します。
決めてほしい事項と、その期限
開発側が止まっている原因が、発注側の判断待ちであることはよくあります。定例会では「次回までに発注側が決めること」を一覧にして、期限を添えて確認します。
- 画面の文言や表示項目をどうするか
- 例外的なケースの扱いをどうするか
- 外部サービスのアカウントや資料の提供
- 社内の関係者への確認
これらを議事録に残し、誰がいつまでに答えるかを明確にしておきます。判断が遅れると、そのまま開発の遅れに直結します。誰が判断するかを決めておく考え方は、発注側のプロダクトオーナーとは｜役割と判断のしかたが参考になります。
課題とリスクを早めに出してもらう
進捗確認の目的のひとつは、悪い知らせを早く知ることです。定例会の議題に「気になっていること」「懸念点」の項目を固定で入れておくと、小さな課題の段階で共有されやすくなります。
「問題はありません」という答えが続く場合は、聞き方を変えます。「いま一番時間がかかっている部分はどこですか」「仕様で迷っている箇所はありますか」といった具体的な問いにすると、見えていなかった論点が出てきます。
デモで見るべきこと
デモは、動く画面を見て進捗を確かめる場です。資料の説明では分からない「実際に使えるか」を、発注側が自分の目で判断できます。この見方は、仕様のすれ違いを防ぐ意味でも有効です。実物を見ながらすり合わせる考え方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも触れています。
見るだけでなく、実際に触らせてもらう
デモが「開発側が操作して見せる」だけで終わると、うまく動く場面しか見えません。可能な範囲で、発注側が自分で操作する時間をもらいます。画面を触ると、説明では気づかない違和感が見つかります。
- ボタンの位置や文言が、業務の感覚と合っているか
- 入力の手間が想定より多くないか
- 画面を移るときの流れに無理がないか
「これじゃない」と感じる点は、早いほど直しやすくなります。気づいた点はその場で口に出して、記録に残してもらいます。
業務や利用の流れに沿って確認する
機能を1つずつ見るだけでなく、実際の利用の流れに沿って通しで確認します。たとえば、利用者が登録して、サービスを選び、利用して、結果を確認するまでを一続きで操作します。
個々の画面は問題なくても、つなげてみると「この情報が次の画面に引き継がれていない」といった不具合が見つかることがあります。新規事業のシステムでは、事業の中心となる流れが途切れず動くかどうかが重要です。
例外やエラーの扱いを見る
正常な操作だけでなく、うまくいかない場面でどう振る舞うかも確認します。
- 必須の項目を空のまま送信したらどうなるか
- 想定外の文字や長い文章を入力したらどうなるか
- 通信が途切れたときや、データが1件もないときの表示はどうか
これらは仕様に書かれていないことが多く、開発が進んでから「決めていなかった」と分かる典型的な箇所です。デモの段階で見ておくと、仕様の抜けを早く見つけられます。
本番に近いデータで動かす
ダミーの少量データでは問題なく動いても、実際の件数や内容では表示が崩れたり、動作が重くなったりすることがあります。可能なら、実際の利用に近い内容のデータで見せてもらいます。機密にあたるデータを扱う場合は、取り扱いの方法を事前に取り決めておきます。
「できていないこと」も見せてもらう
デモでは、完成した部分だけでなく、未着手や作りかけの部分も聞きます。「この画面は今回のデモに含まれていますか」「まだ動かない部分はどこですか」と確認すると、進捗の全体像が分かります。見せられる部分だけを見せる形になっていないかを確かめるためです。
定例会とデモを機能させる進め方
形だけの会議にしないために、運用面でも次のような工夫ができます。
頻度と所要時間を固定する
開催の曜日や時間を固定し、短くても定期的に続けます。開発の初期は仕様の確認が多いため頻度を高く、安定してきたら少し間隔を空けるといった調整もできます。
事前に資料とデモ環境を共有してもらう
当日に初めて資料を見ると、議論が浅くなります。進捗の一覧、決めてほしい事項、デモで見せる内容を、前日までに共有してもらうと、質問を準備できます。
議事録と宿題を残す
決まったこと、持ち帰ったこと、次回までの担当と期限を文章で残します。後から「言った・言わない」にならないための記録であり、仕様変更の経緯を追うときにも役立ちます。変更の扱いはシステム開発の仕様変更への対応｜追加要望の扱い方で詳しく整理しています。
発注側の出席者を決める
判断できる人が出席していないと、「持ち帰って確認します」が続き、決定が遅れます。現場の担当者と、最終的に判断する立場の人の両方が、少なくとも節目のデモに出られる形が望ましいです。
遅れの兆しに気づくポイント
進捗が悪化する前には、いくつかの兆しが現れます。次のような状態が続くときは、早めに原因を確認します。
- 毎回のデモで見せる内容がほとんど変わらない
- 進捗の報告が「順調」ばかりで、具体的な説明が少ない
- 仕様についての質問が、開発の後半になって急に増えた
- 動く画面を見せてもらう機会が、先延ばしにされている
- 当初の計画の見直しが、説明なく後ろ倒しになる
兆しを見つけたときも、責める必要はありません。「何が一番の障害になっていますか」「発注側で支援できることはありますか」と聞き、原因を一緒に整理します。範囲を見直す、優先順位を入れ替える、判断を前倒しするなど、取れる対応はいくつかあります。
また、最終的な納品の確認は、日々の進捗確認とは別の場面です。途中のデモで確認した内容は、納品時の確認項目にも関わってきます。納品時の見方はシステム開発の検収とは｜納品時の確認項目と進め方にまとめています。
契約や準備の段階で決めておくと確認しやすくなること
進捗確認のしやすさは、開発が始まる前の取り決めでも変わります。次のような点を、依頼の段階で話しておくと安心です。
- 定例会の頻度と、デモを行うタイミング
- デモの環境（発注側が自分で触れる環境が用意されるか）
- 進捗の報告に使う指標（機能ごとの完了状態など）
- 課題や遅れが出たときの連絡の方法と期限
- 仕様の確認や判断に関する、発注側の窓口
開発会社を選ぶときにも、これらに丁寧に答えてくれるかは判断材料になります。選び方の視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点でも整理しています。外注全体の流れはシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方から確認できます。
まとめ
システム開発の進捗確認は、報告の数字を受け取るだけでは足りません。定例会とデモを組み合わせ、言葉と実物の両方で状況を確かめることが基本になります。
- 定例会では、進捗率ではなく「どの機能が、どの状態か」で聞く
- 予定との差が出た理由と、発注側が決めるべき事項を、期限つきで確認する
- 課題や懸念は、固定の議題にして早めに出してもらう
- デモでは、実際に触り、利用の流れに沿って通しで確かめる
- 例外やエラー、本番に近いデータでの動きも見る
- 完成した部分だけでなく、できていない部分も聞く
- 議事録と宿題を残し、判断できる人が出席する
私たちJustFitは、「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを先に開発します。お客様は実物を触りながら「ここはこう」と指摘でき、契約するかどうかも実物を見てから判断できます。進み具合を言葉だけでなく動く画面で確かめたい新規事業の担当者の方は、JustFitのサービス紹介もご覧ください。