開発プロジェクトの定例ミーティングの回し方

開発会社との契約が決まり、いよいよプロジェクトが動き出す。キックオフミーティングも終わり、「では来週から定例で進捗を確認していきましょう」と言われた。しかし、いざ最初の定例の招集をかけようとして、ふと手が止まる。誰を呼べばいいのか。何を話せばいいのか。1時間の枠を取ったはいいが、進捗報告を聞いて「順調です」「はい、お願いします」で終わってしまいそうな予感がする——。

これは、初めて開発プロジェクトの発注側に立つ担当者の多くが感じる戸惑いです。定例ミーティングは、開発会社側にとっては何度も経験している「型」がありますが、発注側の担当者にとっては数年に一度、あるいは初めての経験であることがほとんどです。型を知らないまま臨むと、開発会社の進行に身を委ねる形になり、気づいたときには仕様のズレや遅延が取り返しのつかないところまで進んでいた、という事態になりかねません。

この記事では、定例ミーティングを「発注者側が主導権を持って回す場」にするための考え方と具体的な進め方を解説します。頻度や参加者の決め方、議事録の残し方、進捗報告の数字をどう読むか、そして「何かがおかしい」と感じたときにどう動くかまで、開発プロジェクトが始まったばかりの担当者が最初につまずきやすいポイントを順番に整理していきます。

この記事で分かること

開発プロジェクトの定例ミーティングを、発注者側が受け身にならずに運営するための実務知識をまとめます。定例の目的設定、頻度・参加者・時間配分の決め方、議事録とアクションアイテムの管理方法、進捗報告で確認すべき観点、そして問題が発生した際のエスカレーションの考え方まで、プロジェクト開始直後から使える内容です。本記事は「開発会社とのつきあいかた」カテゴリの入口となる記事で、契約後から検収までの間、継続的に発生する定例運営という論点にフォーカスしています。発注前の準備については別記事で扱っているため、そちらもあわせてご覧ください。

そもそも定例ミーティングは何のためにあるのか

定例ミーティングの目的は、突き詰めると「認識のズレを、致命傷になる前に見つけて修正すること」の一点に尽きます。システム開発は、発注者が思い描いている完成形と、開発会社が実装しているものが、少しずつズレていくのが普通です。要件定義の段階でどれだけ丁寧にすり合わせても、実際に画面や機能ができあがってくる過程で「思っていたのと違う」という部分は必ず出てきます。

このズレを検収の直前、つまりプロジェクトの最終段階で初めて発見してしまうと、修正には大きな手戻りが発生します。仕様変更として追加費用が発生することもあれば、納期そのものが延びることもあります。定例ミーティングは、このズレを1週間や2週間という短いサイクルで検出し、小さいうちに軌道修正するための仕組みです。

もう一つ見落とされがちな目的が、進捗の可視化です。開発は発注者の目に見えない場所で進むため、何もしなければ「進んでいるのかどうか分からない」状態がプロジェクト終了まで続きます。定例で定期的に進捗を確認する習慣があれば、遅延の兆候にも早く気づけますし、経営層や社内の関係者に対して「今どうなっているか」を説明する材料にもなります。

つまり定例ミーティングは、単なる「報告を聞く場」ではなく、発注者が自らプロジェクトの状態を把握し、必要な軌道修正を能動的に行うための場だと捉え直す必要があります。この視点の転換が、これから紹介する具体的な進め方すべての土台になります。

頻度はどれくらいが適切か

定例の頻度に絶対の正解はありませんが、多くの中小規模のシステム開発プロジェクトでは、週1回の開催が扱いやすい単位です。月1回では前回からの変化が大きすぎて、ズレの発見が遅れます。逆に毎日となると、発注者側の負担が大きく、開発会社側の作業時間も圧迫してしまいます。

プロジェクトの局面によって頻度を調整するという考え方も有効です。

• 要件定義・設計フェーズ: 認識合わせの密度が特に重要な時期のため、週1回、場合によっては週2回
• 実装フェーズ: 大きな仕様のブレが出にくい時期のため、週1回、または隔週
• テスト・検収フェーズ: 不具合の報告と対応状況の確認が頻発するため、週1回以上、場合によっては都度連絡

ただし、フェーズごとに頻度を変える提案は、基本的に開発会社側から出てくることが多いものです。発注者側としては、「なぜこのタイミングで頻度を変えるのか」を必ず質問し、納得したうえで合意する姿勢を持ってください。開発会社の都合だけで頻度が決められ、発注者側の状況把握が疎かになるケースもあり得るためです。

時間配分についても触れておきます。1回あたりの定例は30分〜1時間程度に収めるのが一般的です。長すぎる定例は形骸化しやすく、逆に短すぎると重要な確認事項を詰め込みきれません。議題が多い週は延長するのではなく、別途臨時の打ち合わせを設定するほうが、参加者の集中力を保てます。

誰を呼ぶべきか。参加者の決め方

定例の参加者選びは、頻度と並んで最初につまずきやすいポイントです。基本的な考え方は、「意思決定できる人」と「実務を把握している人」の両方が発注者側に最低1人ずつ参加することです。

開発会社側は通常、プロジェクトマネージャー（進行管理の責任者）とエンジニアの代表者、場合によっては営業担当者が参加します。これに対して発注者側の参加者が、システムの利用部門の意見を代弁できない立場の人だけだと、定例の場で決められることが限られてしまいます。

参加者の役割分担を整理すると、次のようになります。

小規模な会社では、これらすべてを1人が兼務することも珍しくありません。その場合は、意思決定者を毎回の定例に同席させる代わりに、「持ち帰って確認し、翌営業日までに回答する」というルールを開発会社側とあらかじめ合意しておくと、定例の場で答えに詰まって時間を浪費する事態を避けられます。

逆に開発会社側の参加者についても、発注者側から確認しておくべき点があります。エンジニアが参加しない定例が続く場合、技術的な質問への回答が翌週に持ち越しになりがちです。プロジェクトの重要な局面では、実装を担当しているエンジニアの同席を依頼することも検討してください。

アジェンダを発注者側から用意する

定例ミーティングのアジェンダ（議題一覧）は、開発会社側が用意するのが一般的な進め方です。しかし、開発会社任せのアジェンダだけに従っていると、開発会社にとって都合の良い議題ばかりが並び、発注者側が本当に確認したい点が漏れてしまうことがあります。

理想的なのは、開発会社側が用意する定型のアジェンダに加えて、発注者側からも「今回確認したいこと」を事前に1〜2点持ち込む運用です。これにより、定例が単なる報告会ではなく、双方向のすり合わせの場になります。

一般的な定例のアジェンダ構成は、次のような流れになることが多いです。

1. 前回のアクションアイテムの確認（宿題の消化状況）
2. 今週の進捗報告（完了した作業、進行中の作業）
3. 課題・懸念事項の共有
4. 次回までのアクションアイテムの確認
5. その他（発注者側からの質問事項など）

このうち、発注者側が特に主導すべきなのが1番目と4番目です。「前回、確認すると言っていた件はどうなりましたか」を毎回冒頭で確認する習慣があるだけで、宿題の放置を防げます。曖昧なまま次に進んでしまうと、数週間後に「言った・言わない」の水掛け論になりやすいためです。

アジェンダは、可能であれば定例の前日までに開発会社側と発注者側の双方から項目を出し合い、共有しておくことをおすすめします。当日いきなり議題を出されると、発注者側が十分な検討をせずにその場で判断を迫られる場面が増えてしまいます。

定例は「報告を聞く会」ではなく「双方の宿題を消化する会」だと捉えると、アジェンダの持ち込み方が変わってきます。

議事録とアクションアイテムの管理

定例ミーティングで決まったこと、確認できなかったこと、次回までにやるべきことは、必ず記録に残す必要があります。議事録がないと、数週間後に「その仕様変更は合意した覚えがない」といった認識の食い違いが起きたときに、確認する手立てがなくなってしまいます。

議事録は開発会社側が作成して共有してくれるケースが多いですが、発注者側でも簡単な形でよいので、独自にメモを残すことを強くおすすめします。理由は、開発会社側が作成する議事録は、どうしても開発会社にとって都合の良い解釈やニュアンスで書かれる可能性があるためです。悪意がなくても、立場が違えば同じ会話でも受け取り方は変わります。発注者側の視点でのメモを残しておけば、後から議事録の内容にズレがあった場合の照合材料になります。

議事録に最低限含めるべき項目は、次の通りです。

• 日時・参加者
• 決定事項（何を、誰が、いつまでに決めたか）
• 懸案事項（保留になっている論点、判断待ちの項目）
• アクションアイテム（誰が、何を、いつまでにやるか）
• 次回の定例日程

特に重要なのがアクションアイテムの管理です。「持ち帰って検討します」という発言だけで終わらせず、「誰が」「いつまでに」を必ず言語化してもらう習慣をつけてください。担当者と期限が曖昧なアクションアイテムは、高い確率で次回の定例まで放置されます。

議事録の保存場所についても一言触れておきます。メールのやり取りに埋もれさせず、共有のドキュメントツールやチャットツールの固定チャンネルなど、後から検索しやすい場所に集約しておくと、プロジェクトが長期化したときに過去の経緯を追いやすくなります。

進捗報告の「順調です」を鵜呑みにしない

定例ミーティングで最も注意が必要なのが、進捗報告の受け取り方です。開発会社側から「順調に進んでいます」「予定通りです」という報告を受けたとき、それをそのまま信じてよいかどうかは、報告の中身次第です。

進捗報告でありがちなのが、「進捗率80%」のような大まかな数字だけが伝えられ、その内訳が説明されないケースです。進捗率という数字は、実は非常に曖昧な指標です。作業項目の数で数えているのか、工数で数えているのか、難易度の高い項目が後回しになっていないか、といった前提によって、同じ「80%」でも意味がまったく変わってきます。

進捗報告を受けたときに確認したい観点を整理します。

• 完了した項目は「動くもの」で確認できるか: 口頭で「完了しました」と言われるだけでなく、実際に画面や機能を見せてもらえるかを聞く
• 未着手・遅延している項目は何か、なぜ遅れているか: 順調な部分だけでなく、遅れている部分の理由まで説明を求める
• 残りの作業量は、残りの期間で現実的に終わる見込みか: 進捗率だけでなく、終盤に難易度の高い作業が集中していないか
• 仕様の解釈に、開発会社側の独自判断が入っていないか: 「ここはこう作りました」という説明の中に、要件定義で合意していない解釈が紛れ込んでいないか

これらを毎回すべて詳細に確認する必要はありませんが、「進捗率」という一言だけで終わらせず、具体的な完了物や課題を確認する習慣を持つことが、後の手戻りを防ぐ最も効果的な方法です。

なお、進捗の遅れそのものは、プロジェクトにおいてある程度発生するものです。問題は遅れが発生することではなく、遅れが発注者側に共有されないまま進んでしまうことです。多少の遅延であっても正直に報告してくれる開発会社は、むしろ信頼できる相手だと捉えてよいでしょう。

仕様変更が発生したときの扱い方

定例ミーティングを重ねていく中で、当初の要件定義になかった仕様変更が発生することは珍しくありません。発注者側が「やっぱりこうしてほしい」と気づくこともあれば、開発会社側から「この仕様のままだと運用上こういう問題が起きる」と提案されることもあります。

仕様変更が発生したとき、定例の場でその場のノリで「じゃあお願いします」と即答してしまうのは避けるべきです。特に、追加費用や納期への影響が見込まれる変更については、必ず次のプロセスを踏むことをおすすめします。

1. 変更内容を文書化する（口頭だけで済ませない）
2. 追加費用・納期への影響を開発会社側から見積もってもらう
3. 社内の意思決定者に確認を取る
4. 双方合意のうえで、契約書やSOW（作業範囲記述書）（作業範囲記述書。開発会社が実施する作業の範囲・成果物・スケジュールを明文化した文書）に反映する

このプロセスを省略して口頭合意だけで進めてしまうと、後になって「その変更は契約範囲内のサービスのつもりだった」「いや追加費用が発生する話だった」という認識の食い違いが起こりやすくなります。特に準委任契約で契約している場合は、業務の遂行そのものが契約対象のため、どこまでが契約範囲内の作業かの線引きが曖昧になりがちです。定例の議事録に、仕様変更の合意内容と費用・納期への影響を明記しておくことが、後々のトラブル防止につながります。

小さな仕様変更であれば、その都度大げさな手続きを踏む必要はありません。ただし「小さいかどうか」の判断を開発会社側だけに委ねず、発注者側でも「これは追加費用が発生しそうな変更かどうか」を都度意識しておくことが重要です。

定例と定例の間で連絡が来ないときの対処

定例は週1回や隔週で開催されることが多いため、その間の期間に何が起きているかは、発注者側からは見えにくいものです。理想的には、進捗に大きな変化や問題が発生した場合、定例を待たずに随時連絡が来る関係が望ましいのですが、実際には開発会社側が「次の定例でまとめて報告すればいい」と考え、連絡が滞ることもあります。

これを防ぐには、プロジェクト開始時点で「定例を待たずに連絡してほしい基準」を開発会社側とすり合わせておくことが有効です。たとえば次のような基準を、最初の定例やキックオフの段階で合意しておくとよいでしょう。

こうした基準を事前に合意しておかないと、「連絡すべきかどうか」の判断が開発会社側の裁量に委ねられてしまい、発注者側にとって都合の悪い情報ほど後回しにされるリスクがあります。もちろん、これは開発会社が悪意を持っているという意味ではなく、報告のハードルや基準がすり合っていないだけで起きる、ごく自然なコミュニケーションのズレです。

もし定例の間に何も連絡がなく、次の定例まで進捗が見えない状態が続くようであれば、発注者側から「今どうなっていますか」と一言確認するだけでも、状況把握の精度は大きく変わります。受け身で待つのではなく、気になったタイミングで問い合わせる姿勢を持つことが、結果的にプロジェクト全体の透明性を高めます。

「何かがおかしい」と感じたときのエスカレーション

定例を重ねる中で、「言っていることが前回と違う」「質問への回答がいつも曖昧」「同じ問題が繰り返し発生している」といった違和感を覚えることがあります。こうした違和感は、放置すると徐々に大きなトラブルへと発展しかねません。

定例の窓口担当者だけで解決が難しいと感じた場合は、エスカレーション、つまり自社側のより上位の意思決定者や、開発会社側の管理職クラスを交えた話し合いの場を設けることを検討してください。エスカレーションは「大げさな対応」ではなく、プロジェクトを正常な軌道に戻すための正当な手段です。

エスカレーションを検討すべき具体的なサインをいくつか挙げます。

• 進捗報告の内容が、定例のたびに説明が変わる
• 質問に対する回答が、いつも「確認して折り返します」で止まり、折り返しが来ない
• 同じ不具合や問題が、対応したはずなのに再発する
• 窓口担当者の説明と、実際に納品されたものの内容にズレがある
• 契約内容や追加費用について、書面での確認を渋られる

これらのサインが1つ単発で出ただけであれば、様子を見てもよいかもしれません。しかし複数が重なって見られるようであれば、定例の窓口レベルでのやり取りを続けるのではなく、双方の上位者を交えた場を早めに設定することをおすすめします。早期のエスカレーションは、関係が完全にこじれる前に軌道修正できる可能性を高めます。

なお、保守契約や開発委託契約に、対応時間の目安を定めたSLA（サービス品質保証）が明記されている場合は、それを基準にエスカレーションの是非を判断できます。契約書にSLAの記載がない場合でも、「〇日以内に回答がなければ上位者に相談する」といった自社内のルールをあらかじめ決めておくと、感情的な対立を避けながら冷静にエスカレーションの判断ができます。

契約形態によって定例の意味合いが変わる

定例ミーティングの重要度や進め方は、開発会社とどのような契約形態を結んでいるかによっても変わってきます。中小企業のシステム開発でよく使われる契約形態は、大きく分けて請負契約（あらかじめ決めた仕様通りの成果物を完成させることを約束する契約）と準委任契約の2種類です。

請負契約の場合、開発会社は「決められた成果物を、決められた期日までに完成させる」ことを約束しています。この場合の定例は、あくまで進捗の確認と、契約時に固めた仕様からのズレを早期に発見するための場という位置づけになります。仕様そのものを定例の場で大きく変えると、追加費用や納期への影響が発生しやすい点に注意が必要です。

一方、準委任契約の場合は「業務を遂行すること」自体が契約の対象であり、仕様が固まりきっていない開発や、要件が変化しやすいプロジェクトで採用されることが多い契約形態です。この場合、定例ミーティングはより重要な意味を持ちます。仕様そのものが定例の場で継続的にすり合わされ、決まっていくためです。準委任契約のプロジェクトで定例をおろそかにすると、開発の方向性そのものが発注者の意図しない方向へ進んでしまうリスクが、請負契約よりも高くなります。

自社のプロジェクトがどちらの契約形態で進んでいるかを、定例に臨む前にあらためて確認しておくことをおすすめします。契約書や見積書に明記されているはずですが、もし曖昧なまま進んでいるようであれば、次の定例で開発会社に確認してみてください。契約形態が分かれば、定例で「どこまで柔軟に仕様変更を持ち込んでよいか」の感覚もつかみやすくなります。

議事録・進捗管理に使うツールの選び方

定例ミーティングの議事録や進捗管理をどのようなツールで残すかも、実務上悩みやすいポイントです。特別なプロジェクト管理ツールを新たに導入する必要はなく、多くの場合、既存の環境で十分に運用できます。

小規模なプロジェクトであれば、次のような選択肢が現実的です。

• 共有ドキュメント（クラウド上のワード・表計算ソフトなど）: 議事録を蓄積していく形式に向く。過去の経緯を時系列で追いやすい
• チャットツールの専用チャンネル: 開発会社とのやり取りが多い場合、日常のコミュニケーションと議事録を同じ場所に集約できる
• プロジェクト管理ツール（タスク管理系のサービスなど）: アクションアイテムの担当者・期限をタスクとして可視化したい場合に向く。ただし新たに操作を覚える負担がある

どのツールを選ぶかより重要なのは、「発注者側と開発会社側の双方が同じ場所を見ている」状態を作ることです。開発会社が独自のツールで議事録を管理し、発注者側には都度メールで共有されるだけ、という運用だと、過去の経緯を振り返りたいときにメールを掘り返す手間が発生します。プロジェクト開始時点で、議事録の置き場所を開発会社側と合意しておくと、後々の確認作業がスムーズになります。

ツール選びで完璧を目指す必要はありません。むしろ、凝ったツールを導入して運用が続かなくなるより、使い慣れたツールで最低限の記録を確実に残し続けるほうが、実務上は機能します。

リモートと対面、どちらで定例を行うべきか

近年はオンライン会議ツールでの定例が主流になっていますが、プロジェクトの局面によっては対面での定例を挟むことにも意味があります。

オンラインでの定例は、移動時間がかからず頻度を上げやすい、画面共有で実際の画面を見ながら議論しやすいという利点があります。特に実装フェーズの進捗確認では、実際に動く画面を共有してもらいながら会話するほうが、口頭だけの報告より認識のズレを防ぎやすくなります。

一方で、プロジェクトのキックオフ時や、要件定義の重要な局面、あるいはトラブルが発生してエスカレーションが必要になった局面では、対面での打ち合わせを提案することも検討に値します。対面の場のほうが、双方の温度感や本音を読み取りやすく、複雑な合意形成がしやすい場面があるためです。

すべてを対面にする必要はありません。日常的な進捗確認はオンラインで効率よく、重要な意思決定や関係構築が必要な局面は対面で、という使い分けができると、限られた時間を有効に使えます。

定例を「作業」にしないための工夫

プロジェクトが数ヶ月、あるいは1年を超える長期にわたる場合、定例ミーティングはどうしても形骸化しやすくなります。毎回同じフォーマットで「進捗どうですか」「順調です」を繰り返すだけの会になってしまうと、本来の目的である「ズレの早期発見」という機能が失われてしまいます。

定例を形骸化させないための工夫をいくつか紹介します。

• 数ヶ月に1回、定例の進め方自体を見直す: 頻度や時間配分、参加者が今のフェーズに合っているかを定期的に点検する
• 画面共有や実際の動作確認を毎回組み込む: 口頭報告だけで済ませず、動くものを見る機会を作る
• アジェンダを使い回さない: 前回と同じ議題をなんとなく繰り返すのではなく、そのフェーズで確認すべきことを毎回考え直す
• たまには雑談的な時間も持つ: 事務的なやり取りだけでなく、開発会社側の担当者との関係性を築く時間も、長期的にはプロジェクトの円滑さに寄与する

定例は一度型を決めたら固定するものではなく、プロジェクトの状況に応じて柔軟に調整していくものだと捉えてください。発注者側から「そろそろ進め方を見直しませんか」と提案することも、決して失礼な行為ではありません。

プロジェクト終盤、検収に向けた定例の変化

プロジェクトが終盤に近づき、検収の時期が見えてくると、定例の内容も自然と変化していきます。それまでの「進捗確認」中心の議題から、「テスト結果の共有」「不具合の対応状況」「検収基準の確認」といった議題の比重が増えていきます。

この時期の定例では、検収に向けて何を確認すればよいのか、どのような基準で「完成」と判断するのかを、開発会社側とあらためてすり合わせておくことが重要です。契約時に取り決めた仕様書や要件定義の内容と、実際に納品されるものが一致しているかを、定例の場で段階的に確認していく姿勢が求められます。

検収そのものの具体的な進め方や確認観点については、別記事で詳しく解説する予定です。ここでは、検収直前になって慌てないためにも、定例の後半フェーズから徐々に検収を意識した議題に切り替えていく、という心構えを持っておいてください。

まとめ

開発プロジェクトの定例ミーティングは、単なる進捗の報告会ではなく、発注者側が主体的にプロジェクトの状態を把握し、ズレを早期に修正するための重要な仕組みです。頻度や参加者を最初にしっかり設計し、アジェンダは開発会社任せにせず発注者側からも持ち込み、議事録とアクションアイテムを確実に記録する。進捗報告の数字を鵜呑みにせず、具体的な完了物で確認する習慣を持つ。仕様変更は口頭合意で済ませず文書化する。そして違和感を覚えたら、我慢せずにエスカレーションを検討する。

これらはどれも特別に難しいテクニックではなく、一つひとつは地道な積み重ねです。しかし、この積み重ねがあるかないかで、プロジェクトが円滑に進むかどうかは大きく変わってきます。発注してからが本番だという意識を持ち、定例ミーティングを「開発会社に主導権を委ねる場」ではなく「自社が状況を把握し、判断していく場」として運営していくことが、開発プロジェクトを成功に導く土台になります。

発注後に起きがちな個別の場面についても記事を用意しています。小さな改修を安く早く進めるコツ、契約書に書いておくべきトラブル条項、システムの品質が低いと感じたときの伝え方、開発会社の担当者が変わったときの引き継ぎ確認、障害発生時の連絡フローとSLAの基礎、保守費の値上げを打診されたときの判断基準、開発会社を解約するときの伝え方、良い発注者になるための7つの習慣も、状況に応じて読んでみてください。