週次定例での発注者の役割｜炎上を防ぐ確認10項目と質問例

「進捗は順調です」「問題ありません」――今週の定例でも、開発会社からそんな報告を受けたまま、何となく釈然としないまま会議室を後にしませんでしたか。発注者として参加しているはずなのに、議題はベンダー主導で進み、自分は資料を眺めてうなずくだけ。後になって「もう少し早く気づいていれば」と後悔した経験があるかもしれません。

システム開発の現場では、納期遅れや仕様の食い違いに気づくのが遅れるほど、炎上の規模は大きくなります。トラブルの多くが「コミュニケーション不足」と「進捗管理の不備」に起因することは、古くから繰り返し指摘されてきました（参考: 情報システム・ソフトウェア取引トラブル事例集（2010年経済産業省委託調査））。つまり、週次定例こそが炎上を未然に防ぐ最も重要な「監視ポイント」なのです。

しかし、発注者向けに「定例で何を聞けばよいか」を具体的にまとめた情報は意外と少なく、世の中の解説の多くは PM やベンダー側の運営ノウハウに偏っています。エンジニア出身ではない発注担当者にとっては、「報告を聞いて承認する」以外の関わり方がイメージしにくいのが実情でしょう。

そこで本記事では、システム開発の週次定例における発注者の役割を再定義したうえで、毎回の定例でそのまま使える「5つのチェックポイント」「掘り下げ質問テンプレート」「質問リスト10項目」「早期警戒サイン7つ」「明日から始められる3ステップ」を体系的に解説します。読み終える頃には、ベンダーの「順調です」を鵜呑みにせず、能動的に問題を発見できる発注者へと関わり方を変えるための、具体的な道具が手に入っているはずです。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

週次定例とは何か：発注者にとっての本当の位置づけ

システム開発における週次定例とは、発注者と開発会社（ベンダー）が毎週決まった曜日・時間に顔を合わせ、進捗・課題・意思決定事項をすり合わせる場を指します。プロジェクトの規模にかかわらず広く採用されている、最も基本的な進行管理の仕組みです。一方で、「定例」という言葉のニュアンスから、つい「報告を聞く場」と捉えがちです。本章では、まずこの誤解を解きほぐすところから始めます。

週次定例の一般的な構成と参加者

週次定例の基本形は、次のようなパラメータで設計されることが多いです。

頻度・時間・参加者そのものに正解はありませんが、「30分以内で終わる」「進捗報告だけで終わる」状態が続く場合は、定例が形骸化しているサインと考えてよいでしょう。

なお、本記事は「週次定例の場での発注者の立ち居振る舞い」に焦点を絞っています。スケジュール管理全般（遅延対応の意思決定フレーム、仕様変更管理、進捗報告フォーマットの標準化など、定例の外側で扱うべき論点）についてはシステム開発の遅延を防ぐ発注者のスケジュール管理ガイド｜進捗確認・納期対応の実務を参照してください。

「報告を聞く場」と「問題を早期発見する場」の違い

定例の位置づけは、発注者の関わり方によって大きく2つに分かれます。

• 報告を聞く場: ベンダーが用意した資料をもとに進捗を共有し、発注者は質問せずに承認する。会議は短く終わるが、問題は表に出てこない
• 問題を早期発見する場: 発注者が事前に観点を持って参加し、報告内容を能動的に掘り下げる。会議の所要時間は変わらなくても、得られる情報の質が大きく変わる

豆蔵デベロッパーサイトの記事でも、定例が形骸化する原因は「進捗報告のみで対話が生まれない構造」にあると整理されています（形骸化しない定例会議の進め方（豆蔵デベロッパーサイト））。発注者として目指すべきは後者、すなわち「問題を早期発見する場」へと定例の役割を引き上げることです。

ステアリング委員会・進捗報告書との役割の違い

発注者が関わる進行管理の仕組みは、週次定例だけではありません。混同しがちですが、それぞれ役割が異なります。

ステアリング委員会は経営判断レベルの大きな意思決定の場であり、週次定例で扱う「現場レベルの課題」とは射程が異なります。両者の役割分担についてはステアリングコミッティ運営ガイドも併せてご確認ください。本記事では、現場の発注窓口担当者が毎週関わる「週次定例」に絞って解説します。

発注者が定例で確認すべき5つのチェックポイント

「定例で何を確認すればよいか分からない」という悩みに対して、まず押さえてほしいのが次の5つの観点です。スコープ・スケジュール・品質・コスト・チーム健全性。プロジェクトマネジメントの古典的なフレームワーク（QCD＋人）に基づいたものですが、発注者目線で「毎週確認すべきポイント」に絞り込んで整理し直しました。

スコープの確認：決まったはずの仕様が揺れていないか

要件が曖昧なまま開発が進むと、後工程での手戻りが致命的になります（システム開発はなぜ失敗するのか（Sun*））。週次定例では、次の観点を毎回確認しましょう。

• 先週からスコープに変更はなかったか（追加要件・削除要件の有無）
• 仕様レビューで「保留」となった項目はないか、あるとすればいつ判断するか
• 自社の業務部門・関連部署から、開発開始後に出てきた追加要望はないか

スコープの揺れは、後述するスケジュール・コスト・品質すべてに連鎖して影響します。最も上流で監視すべき観点です。

スケジュールの確認：マイルストーン達成度と残タスクの妥当性

進捗報告で「○%完了」と言われると安心しがちですが、発注者が見るべきは「マイルストーンに対する達成度」と「残タスクの妥当性」です。

• 直近のマイルストーン（要件定義完了・基本設計完了・結合テスト開始など）は予定通りか
• 遅延がある場合、何が原因で、いつ取り戻す計画か
• 残タスクの粒度は妥当か（粒度が粗いタスクが大量に残っていないか）

「進捗60%」のような数字よりも、「来週の◯日までに何を完了させるか」というコミットメントの具体性に注目してください。

品質の確認：テスト工程・バグ件数・レビュー状況

品質に関する確認は、技術的な詳細に踏み込まずとも次の観点で十分にチェックできます。

• バグ検出件数の推移（今週見つかったバグの件数・深刻度）
• テストケース消化率（計画に対する実績）
• コードレビューの実施状況（レビュー観点・指摘件数）

テスト工程が後ろ倒しになっているプロジェクトは、終盤での品質トラブルが起こりやすい傾向にあります。納期直前にバグが集中して見つかる事態は、リリース直前の混乱を生みます（システム開発の失敗事例（walker-s））。テスト計画とバグ件数の推移は、毎週淡々と数字で確認するのが鉄則です。

コスト・工数の確認：残工数・残予算・追加要件の影響

固定価格契約でも準委任契約でも、コスト・工数の見える化は欠かせません。

• 当初の見積工数に対する消化率は何%か
• 残工数で残タスクをすべて完了できる見込みがあるか
• 追加要件が発生した場合、契約・見積への影響をどう扱うか

「契約金額の範囲内で進めています」だけでは不十分です。残工数と残タスクの突合せをベンダー側に依頼し、定量的に確認しましょう。

チーム健全性の確認：稼働・体制変更・モチベーション

技術的な観点だけでなく、チームそのものの状態にも目を向けるべきです。

• メンバーの稼働状況（残業・休日対応の発生有無）
• 体制変更（メンバーの追加・離脱・役割変更）
• 議論の雰囲気（活発な質問・課題提起があるか）

リソース不足や引継ぎ不全は炎上の典型的な火種です。とくにメンバー増員が必ずしも遅延解消につながらないことは、ソフトウェア工学の古典的な知見として知られています（参考: ブルックスの法則）。「最近メンバー A の発言が減った」「PM が代理で答える場面が増えた」といった微妙な変化は、後述する早期警戒サインにも直結します。

「問題ありません」をそのまま受け入れないための掘り下げ質問

ここからが本記事の中核です。多くの発注者が陥る最大の落とし穴は、ベンダーからの「順調です」「問題ありません」という報告を、そのまま受け取ってしまうことにあります。本章では、その報告を能動的に掘り下げるための具体的な質問テンプレートを紹介します。

なぜ「問題ありません」は危険なのか：悪い情報が沈む構造

プロジェクトの現場では、悪い情報ほど報告が遅れる構造的な力学が働きます。シンクイットのプロマネ連載でも、「責められるのが嫌で『残業すれば取り戻せる』と安易に見切る」姿勢が遅延の隠ぺいにつながる典型例として紹介されています（プロジェクトを炎上させないためのひと手間「兆候管理」（Think IT））。

発注者側にも、悪い情報を引き出しにくくしている要因があります。

• 「順調か？」と聞かれれば、現場は「順調です」と答えやすい（聞き方が誘導している）
• 報告者（PM・テックリード）が、現場の細部まで把握していない
• 発注者が「責める姿勢」を見せると、現場はますます報告しにくくなる

つまり「問題ありません」という答えは、必ずしも問題がないことを意味しません。「問題が報告されていない」だけかもしれないのです。だからこそ、発注者からの質問の仕方を工夫し、悪い情報が表に出やすい場を作る必要があります。

「進捗○%」報告を掘り下げる3つの追加質問

「進捗70%です」と報告を受けたら、そのまま受け入れずに次の3つを質問してください。

1. 「進捗70%とは、具体的に何が完了している状態ですか？」
   • 進捗率は定義が曖昧になりがちです。「コーディング完了」なのか「テスト完了」なのかで意味が全く違います
2. 「残りの30%で、最もリスクの高いタスクはどれですか？」
   • 残タスクを均一に見るのではなく、リスクの濃淡を引き出します
3. 「マイルストーン日に間に合わせるために、いま発注者側で支援できることはありますか？」
   • 「順調」と答えづらい状況を作り、隠れた支援要望（仕様確定の催促・関連部署の調整など）を引き出します

「問題ありません」報告を掘り下げる3つの追加質問

「特に問題ありません」と報告された場合は、次の3つを必ず尋ねましょう。

1. 「先週から今週にかけて、ヒヤッとした場面はありませんでしたか？」
   • 「問題」というと大事になりますが、「ヒヤッとした場面」という言葉なら現場も口に出しやすくなります
2. 「来週・再来週で、もしうまくいかないとしたら何が原因になりそうですか？」
   • 現在の問題ではなく、未来のリスクを聞くことで、現場の懸念を吐き出してもらえます
3. 「今のペースが続いた場合、本当に当初の納期で間に合いますか？」
   • 「順調か？」ではなく「間に合うか？」と再確認することで、楽観的な見立てを揺さぶります

答え方から危険度を見抜くポイント

質問への「答え方」そのものにも、危険度を読み取るシグナルが隠れています。

これらは個別に見れば気にならないかもしれません。しかし、同時期に複数のシグナルが揃ったときは、後述する早期警戒サインを念頭に置いて、より踏み込んだ確認に切り替えてください。

発注者から毎回確認すべき質問リスト10項目

ここまでの観点を、定例ですぐ使える質問リストにまとめました。「進捗」「課題・リスク」「意思決定」「品質・テスト」「次週」の5フェーズで、各2項目ずつ計10項目です。週次定例のアジェンダを設計する際の土台としても活用できる構成にしてあります。

進捗確認の質問（2項目）

課題・リスクの質問（2項目）

意思決定の質問（2項目）

品質・テストの質問（2項目）

次週へのアクション質問（2項目）

この10項目は、すべての回でゼロから読み上げる必要はありません。事前に Excel・スプレッドシート・Notion などにテンプレートとして保存しておき、毎回の定例で「今週はどれを重点的に確認するか」を選んで使うのが現実的です。

定例で見逃してはいけない早期警戒サイン7つ

質問への答えそのものが「問題なし」であっても、定例全体の様子から炎上の兆候が読み取れる場合があります。本章では、発注者が現場で観察しやすい早期警戒サインを7つに整理しました。

発言・コミュニケーションのサイン

サイン1: 担当者の発言量が急に減った これまで自分の担当領域について率直に発言していたメンバーが、ここ数週静かになっている場合、何らかのプレッシャーや問題を抱えている可能性があります。

サイン2: PM が代理で答える場面が増えた 本来担当者が答えるべき領域を PM がフォローし続けている場合、現場と PM の間に情報の断絶が生じている兆候です。NRI の DX プロジェクトに関する解説でも、現場の当事者意識の欠如や、ベンダー成果物への積極的なフィードバックがない状態は危険な兆候として挙げられています（DXプロジェクトの危険な兆候（NRI））。

数字・成果物のサイン

サイン3: 進捗率が複数週同じ数字で止まっている 「先週も70%、今週も70%」が続く場合、計画と実態が乖離しているか、進捗の計測方法そのものに問題があります。

サイン4: デモ・動作確認の機会が出てこない 「もう少し形になってから見せます」が繰り返される場合、実装が予定通り進んでいない可能性があります。動くものを見ない期間が長引くほど、ズレに気づくタイミングが遅れます。

サイン5: バグ件数が急増している、あるいは0件のまま推移している バグの急増は品質危機の兆候ですが、逆に「ずっと0件」も警戒すべきサインです。テストが実施されていない、あるいは記録されていない可能性があります。

課題管理のサイン

サイン6: 同じ課題が3週連続で議事録に登場する 同じ課題が解決されないまま週をまたぐ場合、誰が・いつまでに・どう解決するかの責任分担が曖昧になっている可能性があります。

サイン7: 課題の優先度や担当者が曖昧になっている 課題管理表があっても、優先度が「中」ばかり、担当者が「全員」になっているような状態は、実質的に課題管理が機能していません。

これら7つのサインは、1つだけなら一時的な事象かもしれません。しかし複数が同時期に重なって観察される場合は、プロジェクトに何らかの構造的な問題が発生していると考えるべきです。発注者として、ベンダー側の PM に踏み込んだヒアリングを設定するタイミングです。

定例を「管理する場」に変えるために発注者が今日からできること

ここまで解説してきた「5つのチェックポイント」「掘り下げ質問」「質問リスト10項目」「早期警戒サイン7つ」は、知識として読むだけでは行動を変えられません。本章では、これらの観点や質問を「実際の定例サイクル」に落とし込むための実践ガイドとして、明日からの定例運用に組み込む方法を3ステップで提示します。

定例前にやるべき事前準備

定例の質は、会議前の30分で決まると言っても過言ではありません。次の3つを習慣化してください。

1. 前回議事録を読み返す: 前回の宿題・ペンディング事項・課題ステータスを確認し、今回必ず確認したい点に印をつける
2. 質問リスト10項目から、今週の重点質問を3〜4個選ぶ: 全項目を毎回確認するのは現実的でないため、進捗フェーズに応じて重点を絞る
3. 社内の関連部署にヒアリングする: 業務部門・関連システムの担当者から、開発に影響する社内動向（仕様変更・新規要望・スケジュール変更）を事前に拾っておく

事前準備があるだけで、定例での発注者の発言の質は驚くほど変わります。

定例中の進め方：最初の5分と最後の5分

定例の30〜60分は、次のような時間配分を意識すると、ベンダー主導の「報告会」から発注者主導の「対話の場」へと変えていけます。

特に「最初の5分」で発注者がアジェンダを再確認する習慣を作ると、定例の主導権が緩やかに発注者側にシフトします。「報告を聞く側」ではなく「議論をリードする側」に立つ第一歩です。

定例後にやるべきこと

定例が終わった直後に、次の3つをこなしましょう。

1. 議事録を当日のうちにレビュー・確定する: 翌日以降に持ち越すと、認識ズレが温存されます
2. 社内の関係者に要点を共有する: 上位会議（ステアリングコミッティ運営ガイド）に上げるべき事項があれば、当日のうちに整理しておく
3. 次回までの自分自身の宿題を管理する: 発注者側の意思決定遅延は、ベンダー側の進捗を直撃します。質問リストの Q5・Q6・Q10 で確認した宿題は、必ず期限とともにタスク化してください

定例は「ベンダーが進捗を報告し、発注者が承認する場」ではありません。発注者がプロジェクトのリスクを早期発見し、必要な意思決定をその場で行い、次週の動きを設計する場です。本記事で紹介したチェックポイント・質問リスト・早期警戒サインを、次の定例から1つでも持ち込んでみてください。「進捗は順調です」という言葉の意味が、これまでとは違って聞こえてくるはずです。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。