開発会社との定例ミーティングで、画面共有された進捗表を見ながら「順調です」「予定通りです」というやり取りだけで終わっていないでしょうか。たとえば、想定例として、週1回の定例で消化したタスク数と残タスク数だけを確認し、質問の時間がほとんどないまま次の議題に移ってしまうケースがあります。進捗の数字は追えていても、仕様の認識がずれていたり、懸念点が共有されないまま開発が進んでしまうことは珍しくありません。結果として、リリース直前になって「思っていたものと違う」という手戻りが発生し、スケジュールと予算の両方に影響が出ます。定例で進捗以外に何を確認するべきか、具体的に整理します。
仕様の解釈がずれていないかを確認する
要件定義書や仕様書は、書いた側と読んだ側で解釈が異なることがあります。特に「〜の場合は適切に処理する」のような曖昧な表現が残っていると、開発側の判断で実装が進み、発注側の想定と食い違う可能性があります。定例では、進捗だけでなく、直近で開発側が判断に迷った点や、独自の解釈で進めた部分がないかを聞く習慣をつけると有効です。
「ここ最近、仕様書に明記されていなくて、御社の判断で決めた部分はありますか。あれば教えてください」
この質問を定例の冒頭か最後に毎回入れることで、小さな認識のずれを早期に発見しやすくなります。ずれを見つけたタイミングが早ければ早いほど、手戻りの範囲を小さく抑えられます。
リスクや懸念点を早めに引き出す
開発会社は、進捗が遅れている箇所や技術的に難しい箇所について、自分から積極的に報告しないことがあります。遅れを報告すると関係が悪化するのではないかという心理が働く場合や、まだ解決できると思って様子を見ている場合もあります。しかし、懸念点の共有が遅れるほど、対応の選択肢は狭まります。
「今の時点で一番不安に感じている部分はどこですか。まだ解決していない技術的な課題があれば教えてください」
この問いかけは、進捗が良好に見えるときほど効果があります。問題がないときにこそ聞いておくことで、問題が起きたときの対応速度が変わります。
テストの範囲と残課題を具体的に聞く
「テスト中です」という報告だけでは、どの範囲をどの程度の深さで検証しているのかが分かりません。テストには、個々の機能が正しく動くかを確認する単体テストと、機能同士を組み合わせて全体の流れを確認する結合テストなど、段階があります。どの段階のテストを、どのような条件で実施しているかを確認しないと、リリース後に想定外の不具合が見つかるリスクが残ります。
「現在のテストは、どの機能とどの機能の組み合わせまで確認済みですか。まだ手をつけていない範囲はどこですか」
この質問によって、残りの作業量や品質の見通しを具体的に把握できます。
追加開発が必要か、既存の運用改善で足りるかを見極める
定例で課題が見えてきたとき、すべてを追加開発で解決しようとすると、費用も期間も膨らみます。追加開発を検討すべきなのは、運用上の手順変更だけでは解決できない構造的な問題がある場合、同じ不具合や手戻りが繰り返し発生している場合、今後の利用拡大を見込んで仕組みごと見直す必要がある場合です。一方、入力ルールの周知不足や、担当者間の確認手順が整理されていないことが原因であれば、マニュアルの整備や運用フローの見直しで対応できることがあります。まずは原因が「仕組みの不足」なのか「運用の不足」なのかを切り分けることが先決です。
定例で確認したい項目のチェックリスト
- 仕様書に明記されていない部分で、開発側が独自判断した箇所はないか
- 直近で一番不安に感じている技術的な課題は何か
- テストはどの機能の組み合わせまで完了しているか
- 残っている課題は追加開発が必要か、運用改善で対応できるか
- 次回の定例までに、発注側が用意すべき情報や判断事項は何か
- 想定しているリリース日に対して、現時点で遅延リスクがあるか
- 議事録やタスク一覧が、双方で同じ内容を指しているか
進捗確認だけで終わる定例から一歩進み、仕様のずれやリスクを早期に拾い上げる習慣をつけることで、手戻りの発生を抑えやすくなります。社内だけで判断が難しい場合や、開発会社との定例の進め方そのものを見直したい場合は、お気軽にご相談ください。