開発会社との定例ミーティングは週1回が望ましいとよく言われます。実際、要件定義やテストフェーズのように認識のズレが起きやすい局面では、週1回の頻度が有効です。しかし、10〜30人規模の会社で情シスを兼任している担当者にとって、毎週1時間を開発会社との定例に割くことは、本業への影響を考えると現実的でない場合があります。特に、すでに稼働しているシステムの小規模な改修や、緊急度の低い追加開発案件では、週1回の定例を維持すること自体が過剰な負担になっているケースも少なくありません。
このガイドでは、「定例を月1回にまで絞っても、進捗管理が破綻しない」ための最小限の型を解説します。頻度を落とすこと自体は悪いことではありません。問題は、頻度を落とした分だけ生じる「情報の抜け漏れ」をどう防ぐかです。兼任担当者が本業と両立しながら、月1回の定例だけで開発案件を安全に進行させるための考え方と具体的な運用方法を紹介します。
なぜ月1回で十分なケースがあるのか
すべての開発案件で月1回の定例が適切というわけではありません。月1回への頻度低下が現実的に機能するのは、次のような条件を満たす案件です。
- 要件がすでに固まっている: 大きな仕様変更が発生する可能性が低く、認識合わせの頻度をそこまで必要としない
- 開発の規模が小さい: 数週間〜数ヶ月単位の改修で、複雑な工程が絡み合っていない
- 緊急度の高い障害対応ではない: 業務が止まるような緊急案件ではなく、計画的に進められる案件である
逆に、要件定義の真っ最中であったり、複数の機能が並行して開発されていたりする案件では、月1回の定例では認識のズレを検出するタイミングが遅すぎます。頻度を落とす判断は、案件の性質を見極めたうえで行う必要があります。判断に迷う場合は、まず現在の頻度(週1回や隔週)を維持しつつ、案件が落ち着いてきた段階で段階的に間隔を空けていくのが安全です。
月1回定例の最大のリスクは「1ヶ月分のズレが一気に見つかること」
定例の頻度を落とす最大のリスクは、認識のズレが発見されるまでの期間が長くなることです。週1回であれば、多少のズレがあっても翌週には軌道修正できますが、月1回になると、そのズレが1ヶ月分蓄積してから発覚することになります。1ヶ月分のズレは、修正にかかる工数も費用も大きくなりがちです。
このリスクを踏まえると、月1回の定例を成立させる条件は「定例と定例のあいだに、ズレが発生しにくい・発生してもすぐに検知できる仕組みがあること」だと言い換えられます。次のセクションから、この仕組みの具体的な作り方を紹介します。
月1回定例を支える3つの補助線
月1回の定例だけに頼るのではなく、定例と定例のあいだを埋める「補助線」を3つ用意することで、頻度を落としても情報の抜け漏れを防げます。
1. 非同期の進捗共有を週次で受け取る
定例自体は月1回でも、進捗状況の共有は週次のメールやチャットで受け取る運用に切り替えます。会議を開く必要はなく、開発会社側から「今週やったこと」「来週やる予定」を数行のテキストで送ってもらうだけで十分です。この非同期の共有があれば、兼任担当者は忙しい週でも数分で目を通すだけで状況を把握でき、月1回の定例では「1ヶ月分をゼロから聞く」のではなく「気になった点を深掘りする」場として使えます。
| 頻度 | 手段 | 目的 |
|---|---|---|
| 週次 | メール・チャットでの簡易進捗報告 | ズレの早期発見、負担の少ない状況把握 |
| 月次 | 定例ミーティング | 深掘りの議論、意思決定が必要な事項の確認 |
2. 「即連絡すべき事項」をあらかじめ合意しておく
月1回の定例を待たずに連絡してもらうべき事項を、あらかじめ開発会社側とすり合わせておくことが重要です。次のような事項は、定例を待たず都度連絡するというルールを最初に決めておいてください。
- 当初の見積もりから追加費用が発生しそうな場合
- 納期に遅延が生じる見込みが出た場合
- 仕様について発注者側の判断が必要な事項が出た場合
- システムに影響する重大な不具合が見つかった場合
このルールがないまま月1回の定例に移行すると、開発会社側が「次の定例で報告すればいいか」と判断し、本来もっと早く共有されるべき情報が1ヶ月近く止め置かれるリスクがあります。仕様変更や追加費用の伝え方そのものについては仕様変更・追加要望の正しい伝え方と追加費用の考え方で詳しく扱っていますので、あわせて確認してください。
3. 定例1回分の議題を最小限のフォーマットに固定する
月1回しか開催しない定例だからこそ、限られた時間を有効に使うために議題のフォーマットをあらかじめ固定しておきます。目安としては、次の4項目で30分程度に収まる構成です。
- 前回の定例からの進捗サマリー(5分)
- 今月中に判断が必要な事項の確認(10分)
- 次月の作業予定とスケジュールの確認(10分)
- その他懸念事項・質問(5分)
この固定フォーマットがあることで、毎回議題をゼロから考える手間がなくなり、兼任担当者が会議の準備に割く時間も最小限で済みます。
議事録は「決まったこと」だけ最小限に残す
週1回の定例であれば、その場の細かいやり取りまで議事録に残す余裕もありますが、月1回の定例では、次の3点に絞って記録すれば十分機能します。
| 記録項目 | 記録する理由 |
|---|---|
| 今回の定例で決定した事項 | 「言った・言わない」のトラブルを防ぐ |
| 次回までに発注者側がやること | 兼任担当者自身がタスクを見失わないようにする |
| 次回までに開発会社側がやること | 進捗の遅れを次回定例で照合できるようにする |
議事録の作成に時間をかけすぎないことも重要です。定例終了後、その場で決まった事項を箇条書きで3〜5行にまとめ、開発会社側と発注者側の双方に共有すれば十分です。凝った体裁の議事録を作ろうとして時間を割くより、簡素でもすぐに共有できる形を優先してください。
兼任担当者だけで抱え込まない: 定例に誰を同席させるか
月1回という限られた頻度だからこそ、定例には兼任担当者1人だけでなく、可能であれば関係する部署の担当者や、権限を持つ副窓口を同席させることをお勧めします。定例の頻度が少ない分、その場で決まったことを共有できる人が複数いれば、兼任担当者が体調不良などで次回の定例に出席できない場合でも、状況の引き継ぎがしやすくなります。窓口を1人に集中させないための体制づくり全般については開発会社とのやり取りを総務兼任者1人に集中させない体制の作り方で詳しく扱っています。
定例の頻度を落とすことは、関わる人数を減らすこととイコールではありません。むしろ頻度が少ないからこそ、1回の定例に立ち会う人を厚めにしておくことが安全策になります。
月1回では拾いきれない「部署からの個別要望」に注意する
定例が月1回になると、その間に発生した各部署からの細かい要望が、次の定例まで宙に浮いてしまうことがあります。特に部署が複数化している10〜30人規模の会社では、営業部や製造部から「ちょっとした修正をお願いしたい」という声が個別に上がってくることが珍しくありません。これらの要望を兼任担当者が都度個別に開発会社へ伝えてしまうと、月1回の定例で合意したはずの優先順位が崩れ、結果的にプロジェクト全体の進行が乱れます。
部署からの個別要望をどう社内で受け止め、整理してから開発会社に伝えるかについては部署の担当者が個別に開発会社へ要望を出してしまう状態を防ぐ方法で扱っています。月1回定例と組み合わせることで、「日々の要望は社内で一次整理し、月1回の定例でまとめて優先順位をつける」という流れが作れます。
月1回定例が向かないシグナル
月1回の頻度で運用を始めた後も、状況が変わればより頻度を上げる必要が出てきます。次のようなシグナルが出てきたら、頻度の見直しを検討してください。
- 週次の非同期進捗報告に「懸念事項」の記載が続けて出てくる
- 定例の場で毎回、想定外の追加費用や仕様変更の相談が発生する
- 開発会社側から「もう少し頻繁に確認したい」という要望が出る
- 兼任担当者自身が、次の定例まで状況が分からず不安を感じる場面が増える
頻度を上げること自体はコストの増加に見えますが、認識のズレが積み重なって手戻りが発生することに比べれば、多くの場合は小さなコストです。頻度の調整は一度決めたら固定するものではなく、案件の進行状況に応じて柔軟に見直す前提で運用してください。
開発会社側の体制によっても向き不向きがある
月1回の定例が機能するかどうかは、発注者側の事情だけでなく、開発会社側の体制にも左右されます。次のような開発会社であれば、月1回の定例でも比較的安全に運用できる傾向があります。
- 進捗管理を自社内でしっかり行っており、依頼した内容の抜け漏れが少ない
- 過去の取引実績があり、発注者側の業務や優先順位をある程度理解している
- メールやチャットでの問い合わせに対するレスポンスが早い
逆に、担当者の入れ替わりが多い、あるいは複数の案件を掛け持ちしていて対応が後手に回りがちな開発会社の場合、月1回の定例だけでは進捗の実態を正確に把握しきれないことがあります。開発会社との付き合いが浅い段階や、担当者が変わったばかりのタイミングでは、いきなり月1回に頻度を落とすのではなく、まずは隔週程度の頻度で信頼関係と進行パターンを確認してから、段階的に月1回へ移行することをお勧めします。開発会社の担当者が変わった際の引き継ぎ確認については開発会社の担当者が変わったときの引き継ぎ確認で詳しく扱っています。
定例を欠席・延期せざるを得ない場合の対応
月1回しかない定例だからこそ、1回の欠席や延期が与える影響は、週1回の定例に比べて相対的に大きくなります。兼任担当者が本業の繁忙期と重なって定例に出席できない、あるいは開発会社側の都合で延期になるといった事態は、10〜30人規模の会社では珍しくありません。このような場合に備え、あらかじめ次のようなルールを決めておくと安心です。
- 定例を延期する場合、代替日は元の予定日から2週間以内に設定する(先延ばしにしすぎない)
- どうしても日程が合わない場合は、短時間のオンライン通話や電話で要点だけ確認する簡易版に切り替える
- 定例が延期になった場合でも、週次の非同期進捗共有だけは止めない
定例が1回飛んでしまうこと自体は大きな問題ではありません。問題なのは、定例が飛んだことをきっかけに、週次の進捗共有まで曖昧になり、気づいたときには2ヶ月分の状況が分からなくなっているという事態です。定例の代替手段と、非同期共有の継続を切り分けて考えることが、月1回運用を安定させるコツです。
保守フェーズへの移行時は改めて頻度を見直す
開発案件が完了し、保守フェーズに移行するタイミングでは、定例の頻度をあらためて見直す好機です。保守フェーズでは新規開発ほど頻繁な確認は不要になることが多く、月1回の定例をさらに隔月や四半期に落とすことも選択肢に入ります。ただし、保守費で何がカバーされているかを定期的に確認する場は残しておくべきです。保守費の範囲や請求内容の確認については開発会社からの請求内容を経理と一緒に確認する体制の作り方、月額保守費でカバーされる作業範囲については月額保守費で何をやってもらえるのかで詳しく扱っています。
SLA・契約形態と定例頻度の関係
定例の頻度を検討する際、契約形態によっても適切な頻度は変わります。準委任契約で進めている案件は、成果物の完成そのものよりも作業プロセスの妥当性が問われるため、定例で作業内容を確認する重要性が相対的に高くなります。一方、請負契約で仕様と納期が明確に固まっている案件では、進捗確認の頻度をやや落としても、最終的な検収時点で仕様通りに仕上がっているかを確認すれば大きな問題にはなりにくい傾向があります。
また、保守契約にSLA（サービス品質保証）が設定されている場合、SLAで定められた対応時間や報告義務が、定例とは別に機能します。障害対応や緊急の不具合報告はSLAに基づいて都度対応されるため、定例はあくまで計画的な改修・開発案件の進捗確認に特化させることができます。契約形態ごとに「定例で確認すべきこと」と「定例を待たずに個別対応すべきこと」を切り分けておくと、月1回という限られた頻度でも役割が明確になります。
| 契約形態・条件 | 定例の位置づけ |
|---|---|
| 準委任契約 | 作業プロセスの妥当性を定例で継続的に確認する必要性が高い |
| 請負契約(仕様・納期確定済み) | 定例の頻度を落としても、検収時の確認で大きな齟齬は起きにくい |
| SLA付き保守契約 | 障害・緊急対応はSLAに基づき都度対応。定例は計画的な改修の確認に特化 |
経営層への報告とのタイミング調整
月1回の定例は、社内の経営層への報告タイミングと合わせて設定すると、二度手間を防げます。多くの10〜30人規模の会社では、月次の経営会議や部門会議が既に存在しています。定例をこの月次サイクルに合わせておけば、定例で得た最新の進捗情報を、そのまま経営層への報告資料に転用できます。
逆に、定例のタイミングと社内報告のタイミングがずれていると、兼任担当者は「定例のための準備」と「経営層報告のための準備」を別々に行うことになり、月1回に絞ったはずの負担がかえって増えてしまいます。定例の日程を決める際は、開発会社側の都合だけでなく、自社の月次報告サイクルも考慮に入れて調整することをお勧めします。
議事録の保管場所も定例と同時に決めておく
月1回の定例で作成した議事録は、その場で開発会社側と共有して終わりにせず、社内でも見返せる場所に保管しておく必要があります。兼任担当者個人のメールボックスにしか議事録が残っていない状態は、その担当者が不在のときに過去の合意事項を誰も確認できないという、窓口一極集中と同種のリスクを生みます。共有フォルダや社内チャットの固定チャンネルなど、部署を横断して参照できる場所に議事録を蓄積していく運用を、定例の頻度を決めるのと同時に決めておくとよいでしょう。この記録の共有化は、開発会社とのやり取りを特定の1人に依存させないための取り組みの一部でもあります。
セルフチェック: 月1回定例への移行は適切か
次の項目に多く当てはまるほど、月1回の定例への移行が安全に進められる状態にあると考えられます。
- 現在進行中の案件の要件はほぼ固まっており、大きな仕様変更の予定がない
- 開発会社との週次の非同期進捗共有について、すでに合意できている、または合意の見込みがある
- 「即連絡すべき事項」について、開発会社側とすり合わせ済みである
- 各部署からの個別要望を、社内で一次整理してから開発会社に伝える流れができている
- 定例に兼任担当者以外の同席者を確保できる見込みがある
これらの条件が整っていない状態でいきなり月1回に移行すると、認識のズレの発見が遅れ、かえって手戻りコストが増える可能性があります。まずは週次の非同期共有の仕組みから整え、段階的に定例の頻度を落としていくことをお勧めします。
月1回定例の1年間の運用イメージ
月1回定例が実際にどのように積み重なっていくのか、1年間を通したイメージを持っておくと、導入後の見通しが立てやすくなります。次はあくまで一例ですが、多くの小規模改修案件で見られる典型的な流れです。
- 1〜3ヶ月目: 移行直後は非同期の週次共有やルールの定着に手間取りやすい時期。定例の議題フォーマットを試行錯誤しながら固めていく
- 4〜8ヶ月目: ルールが定着し、定例準備の負担が最小化される時期。想定外の相談が減り、定例が本来の「深掘りと意思決定」の場として機能し始める
- 9〜12ヶ月目: 案件の進行状況によっては保守フェーズへの移行や、頻度のさらなる見直しを検討する時期
この流れからも分かる通り、月1回定例への移行は「切り替えた瞬間から完璧に回る」ものではありません。最初の数ヶ月は多少の手戻りやルールの修正が発生することを見込んでおき、焦らず定着させていく姿勢が重要です。特に1〜3ヶ月目に「思ったより手間がかかる」と感じても、それは移行期特有のものであり、月1回運用そのものが失敗しているわけではないケースがほとんどです。
兼任担当者が定例準備にかけるべき時間の目安
月1回の定例といっても、準備を一切しなくてよいわけではありません。ただし、兼任担当者が本業と両立できる範囲に収めるため、準備にかける時間の目安を持っておくことは有効です。多くのケースでは、定例前の準備は30分〜1時間程度で十分収まります。
具体的には、次のような作業が準備の中心になります。
- 週次の非同期進捗報告を1ヶ月分ざっと読み返し、気になる点をメモする(15分程度)
- 各部署から寄せられた個別要望のうち、開発会社に伝えるべきものを整理する(15分程度)
- 固定フォーマットの議題に沿って、確認したい項目を箇条書きにする(15分程度)
この程度の準備であれば、本業の合間の隙間時間でも十分にこなせます。逆に、準備に半日以上かかっているようであれば、週次の非同期共有がうまく機能していない、あるいは記録の残し方が煩雑になりすぎている可能性があります。準備の負担が重くなってきたと感じたら、記録のフォーマットを見直すタイミングだと捉えてください。
定例で使う資料は毎回ゼロから作らない
月1回の定例に向けて、毎回ゼロから資料を作成していると、頻度を落としたはずなのに準備の負担が減らないという本末転倒な事態になります。定例資料は、前回作成したものをベースに更新する「テンプレートの使い回し」を前提に設計しておくとよいでしょう。
具体的には、進捗サマリー・判断事項・次月予定・懸念事項という4項目の枠組み自体は固定しておき、毎回の定例では中身の数行を書き換えるだけで済むようにします。この運用であれば、資料作成にかかる時間は回を重ねるごとに短縮されていきます。逆に、毎回異なるフォーマットで資料を作ろうとすると、兼任担当者は都度ゼロから構成を考えることになり、月1回という頻度の低さが準備負担の軽さに直結しません。
よくある質問
Q. 開発会社側から「月1回では管理しづらい」と言われた場合はどうすればよいですか。
開発会社側の懸念は、多くの場合「発注者側の判断待ちで作業が止まること」への不安から来ています。即連絡すべき事項のルールを明確にし、判断が必要な事項はメールやチャットでも都度対応する姿勢を示せば、開発会社側の懸念は和らぐことが多いです。それでも開発会社側が難色を示す場合は、案件の複雑さに対して月1回が本当に適切かどうか、自社側でも見直してみてください。
Q. 非同期の週次進捗報告を、開発会社側が負担に感じませんか。
数行のテキストで済む簡易な報告であれば、多くの開発会社にとって大きな負担にはなりません。むしろ、進捗を定期的に言語化する習慣は開発会社側の管理にも役立つことが多く、抵抗なく受け入れられるケースがほとんどです。フォーマットを複雑にしすぎず、箇条書き数行程度に留めることがポイントです。
Q. 月1回の定例をオンラインと対面のどちらで行うべきですか。
10〜30人規模の会社では、対面での定例開催にこだわる必然性は薄く、オンライン会議で十分機能するケースが大半です。移動時間を削減できる分、兼任担当者の負担軽減にもつながります。ただし、契約更新や大きな方針転換を話し合うタイミングでは、対面での打ち合わせを設定することも検討してください。
Q. 定例の頻度を落としたことで、開発会社との関係が疎遠になってしまわないか心配です。
頻度を落とすことと関係が疎遠になることは、必ずしもイコールではありません。週次の非同期共有を続けていれば、顔を合わせる回数は減っても、状況を把握し合う関係性は維持できます。むしろ、無理に頻度を保とうとして双方が形骸化した定例をこなすだけの状態のほうが、実質的な関係の疎遠化につながりやすいものです。頻度よりも、やり取りの質と継続性を重視してください。
複数案件を並行している場合の定例の分け方
10〜30人規模の会社では、1社の開発会社と複数の案件を同時並行で進めているケースもあります。たとえば、基幹システムの小規模改修とホームページのリニューアルを、同じ開発会社に依頼しているような状況です。この場合、すべての案件をひとまとめにして月1回の定例で扱おうとすると、議題が膨らみすぎて1回の定例で消化しきれなくなります。
案件の性質が大きく異なる場合は、次のいずれかの方法で整理することをお勧めします。
- 案件ごとに定例を分ける: それぞれの案件の進行速度や重要度に応じて、個別に頻度を設定する(例: 基幹システムは月1回、ホームページは隔月)
- 1回の定例内で案件ごとに時間を区切る: 議題の前半・後半で案件を分け、それぞれ15分ずつなど時間配分を明確にする
どちらの方法を選ぶかは、案件の規模や兼任担当者が確保できる時間によって変わります。案件数が2つ程度であれば1回の定例内で時間を区切る方法で十分ですが、3つ以上の案件を並行している場合は、案件ごとに定例を分けたほうが、それぞれの議論の質を保ちやすくなります。いずれの方法を取るにしても、案件をまたいだ優先順位の調整は、定例の場とは別に、社内で先に整理しておく必要があります。この社内調整の進め方は部署の担当者が個別に開発会社へ要望を出してしまう状態を防ぐ方法でも扱っている考え方と共通しています。
まとめ
定例ミーティングを月1回に絞ることは、兼任担当者の負担を減らすための有効な選択肢です。ただし、頻度を落とした分だけ生じる「情報の抜け漏れ」を防ぐ仕組みがなければ、認識のズレが1ヶ月分蓄積してから発覚するリスクを抱えることになります。週次の非同期進捗共有、即連絡すべき事項の事前合意、固定フォーマットの議題――この3つの補助線を組み合わせることで、月1回という限られた頻度でも、開発案件を安全に進行させることができます。頻度の調整は一度きりの判断ではなく、案件の進行状況に応じて柔軟に見直す前提で運用してください。