システム開発の打合せ議事録｜要件と仕様の変更を、あとから追える形で残す

「言った仕様」と「決まった仕様」が混ざる

要件定義や設計の打合せでは、いくつもの状態の発言が同時に飛び交います。

• 発注側の要望（こうしたい）
• 開発側の提案（こうする方法があります）
• 検討中の案（ひとまずこれで進めてみますか）
• 決定（これで確定します）

発言の順に議事録を書くと、この4つが同じ粒度で並びます。読む側は、どれが確定なのかを文脈から推測することになります。当日は分かっていても、3か月後には書いた本人も判別できません。

実装が始まってから「この画面、こうなっていませんでしたっけ」が出るのは、誰かが嘘をついているからではありません。議事録の書式が、確定と検討中を区別していないからです。書式の問題は、担当者を替えても直りません。

決定・保留・宿題の三分割

打合せの終わりに、その日の内容を3つに振り分けます。この3つ以外は、議事録に載せなくても構いません。

決定事項

以後、変えるには手続きが要るものです。「一応こうしておきましょう」は決定ではありません。変更する場合に、どの立場の誰が合意すれば変えられるかまで含めて、決定と呼びます。ここを厳しく運用するほど、あとが楽になります。

保留

決まっていないことです。保留で大事なのは、「いつまでに、誰が決めるか」を添えることです。期限のない保留は忘れられ、実装の段階で開発者の判断に化けます。その判断が後から覆ると、手戻りは設計まで戻ります。

宿題

次回までの作業です。「確認する」「調べる」で終わらせず、成果物の形まで書きます。メール1通なのか、画面キャプチャなのか、サンプルデータ1ファイルなのか。形を決めておくと、次回の冒頭で完了したかどうかを判定できます。

三分割の効果は、議事録の読みやすさよりも、打合せの終わり方が変わることにあります。最後の5分で「これは決定でいいですか、それとも保留ですか」と口に出して確認する習慣がつくと、認識のずれの多くはその場で消えます。あとから議事録を読み合わせるより、はるかに安く済みます。

なぜそう決めたかを、1行残す

決定事項だけを残すと、半年後に別の問題が起きます。理由が分からない決定は、後から誰かが善意で覆します。

たとえば「検索結果は100件で打ち切る」という決定があったとします。理由が書かれていないと、運用が始まってからの改善要望で「全件出せるようにしましょう」という話になります。実際には「対象データが年間200万件あり、全件取得すると画面が返らなくなるため」という理由だったとすれば、覆した瞬間に障害が起きます。

理由は長く書く必要はありません。1行で足ります。

• 性能上の制約から
• 既存の基幹システムの仕様に合わせるため
• 現場の運用が月次のため
• 社内規程の要件のため

「なぜその案を選んだか」と同じくらい、「なぜ他の案を採らなかったか」も効きます。後から同じ案が再提案されたとき、ひとつ前の検討をなぞり直さずに済みます。打合せの中でこれを書き取るのは負担が大きいので、録音から作った文字起こしを見て、決定の隣に1行足す形のほうが現実的です。

画面名・テーブル名・略語の誤変換

開発の打合せは、記録が崩れる場所がおおむね決まっています。

• 画面名やテーブル名（受注明細、出荷指示、マスタ更新）
• 社内の略称（基幹、旧シス、本番、ステージング）
• 英字の略語（API、CSV、SSO、IF）
• 数値（1万件、100ミリ秒、3営業日）

「IF」が「以下」として残る、「ステージング」が別の語に化ける、応答時間の数値が一桁ずれる。どれも日本語の文としては通ってしまうので、読み流すと気づけません。画面名が一文字違うだけで、どの画面の話なのかを後から追えなくなりますし、数値が変われば性能要件がそのまま書き換わります。

打合せの側でできることが二つあります。

• 冒頭で、その日に扱う画面名と機能名を一度声に出して確認する
• 議事録を確認するときは、画面名とテーブル名、そして件数や応答時間の数値だけを目で追う

呼び方をそろえておくのも効きます。同じものを「受注明細」「明細画面」「明細」と呼び分けていると、記録の側が正しく書けていても、どの層の話なのかが読み取れません。プロジェクトの用語集を一枚作り、画面名は正式名称で呼ぶと決めるだけで、確認の手間はかなり減ります。

仕様変更を、あとから追える形にする

変更は起きます。問題は変更そのものではなく、変更前の状態と理由が残っていないことです。議事録に次の5点が並んでいれば、追える記録になります。

• いつの打合せで変わったか（日付）
• 変更前はどうなっていたか
• 変えた理由
• 誰が合意したか
• 影響範囲（他の画面、帳票、データ移行への波及）

この形になっていれば、課題管理表や変更管理表への転記は機械的に済みます。逆に、議事録が発言の羅列だと、転記の前に読み解く作業が入ります。ここで時間が溶けますし、読み解いた人の解釈が混ざります。

打合せの冒頭で、前回の決定事項と保留を読み上げるのも効きます。30秒で終わりますし、「あれ、そこは変わりましたよね」がここで出ます。テストの直前に出てくるより、桁違いに安く済みます。

発注側・受注側、どちらの立場でも

発注側の場合

発注側にとって議事録は、頼んだことが残っているかの確認手段です。開発会社が作った議事録を受け取るだけの運用だと、自社の要望が要約の過程で落ちても気づけません。悪意の問題ではなく、要約は話された量の多い話題を重く見るためです。短く述べられた重要な要望ほど落ちます。自社でも記録を取り、決定事項の欄だけを突き合わせる形にすると、抜けが見つかります。

受注側の場合

受注側にとっては、追加要望と当初要件の線を引く材料です。「それは最初から入っていたはずです」への回答を、記憶ではなく記録で行えると、関係を壊さずに済みます。線を引くこと自体が目的ではありません。どこから追加なのかを双方が同じ資料で見られる状態にすることが目的です。

どちらの立場でも、議事録を相手に投げっぱなしにしないことが要点です。当日中に共有し、翌営業日までに異議がなければ確定、という運用を最初に決めておきます。この一文をプロジェクト開始時の取り決めに入れておくだけで、後半の揉め方が変わります。

相手方の社員が入る打合せを録音するなら、開始前に目的を伝えて了解を取ってから始めてください。HANALOGなら、オンラインの打合せでは、対応ブラウザから、マイクとパソコンの音を録音できます（環境によってはマイクの音だけになります）。会議室に入れるボットを使わないため、相手側の設定変更は要りません。

仕様を決める責任は移せない

自動で起こせるのは、その日に話された内容までです。HANALOGの下書きにも決定事項の欄は並びますが、そこへ何を上げるかという三分割そのものは、書式で片づく仕事ではありません。

いちばん重いのは、その発言が決定なのか、まだ案なのかという線引きです。打合せの場にいれば、発注側の「それでいいと思います」が承認なのか相づちなのかは、前後のやり取りまで含めて分かります。文字になると、その手がかりは落ちます。だから線を引くのは、その場にいた人が当日のうちにやる仕事です。翌週に回すと、書いた本人にも判別できなくなります。

次に、保留の期限をどちら側に持たせるかです。「次回までに確認します」の主語が曖昧なまま議事録に載ると、双方が相手の宿題だと思ったまま二週間が過ぎます。開発側が待っていたのか、発注側が待っていたのかは、あとから決められません。名前を書くかどうかを決めるのは、その場の力関係も見えている人です。

三つめは、影響範囲の見積もりです。ある画面の仕様を変えたときに、帳票やデータ移行、他システムとの連携にどこまで及ぶか。ここは設計を持っている人にしか書けませんし、書き漏らすと後工程で見つかります。

そして、AIは間違えます。誤変換だけでなく、要約の重みづけも外します。長く揉めた些末な議論が厚く残り、一言で決まった重要な決定が薄くなることがあります。だから、決定事項の欄を目で見て過不足を直す工程は残ります。

議事録の自動化で減るのは、書く時間です。決める時間は減りません。むしろ、打合せの最後に三分割の確認を入れるぶん、会議はわずかに長くなります。その数分が、後工程での数日分の手戻りを防ぐ、という取引です。ここを理解せずに導入すると、会議が短くならないという不満だけが残ります。

まずは1つのプロジェクトの定例会から試すのが、いちばん分かりやすい方法です。決定・保留・宿題の三分割だけを1か月続ければ、その時点で変更履歴が追える状態になっています。