はじめに
打ち合わせのあとで「そういう意味ではありませんでした」が起きるチーム向けの記事です。発注側と開発側が別の会社のとき、特に拠点や母語が違うときに使えます。
内容は3つです。リポジトリに置いてそのまま使えるMarkdownのテンプレート、あいまいな言葉の言い換え表、運用のための短いコマンド。全部を入れる必要はないので、テンプレートだけ持ち帰ってもらっても構いません。
私たちのチームでは、打ち合わせのたびに「こう理解しました」を1枚にまとめて相手に確認してもらう、という習慣を続けています。この記事のテンプレートは、そこで使っている項目をもとに、ほかのチームでも使える形に整えたものです。
議事録と何が違うのか
議事録に残るのは、話された内容。認識合わせメモは、書いた側の理解を相手に見せて、合っているかを確かめるための文書です。
そのため、発言の経緯は書きません。書くのは、決まったこと、その理由、決まっていないこと、そして書いた側が勝手に置いている前提です。長さはA4で1枚までにしています。
テンプレート
docs/alignment/_template.md として置く想定です。
# 認識合わせメモ: {トピック}
- 打ち合わせ日: YYYY-MM-DD
- 作成者: {名前}(作成日: YYYY-MM-DD)
- 確認者: {名前}
- 状態: 確認待ち
- 関連: {Issue / PR / 設計書へのリンク}
## 1. 決まったこと
| # | 決定 | 理由 | 担当 | 期限 |
|---|---|---|---|---|
| D1 | | | | YYYY-MM-DD |
## 2. 決まっていないこと
| # | 論点 | 決める人 | いつまでに |
|---|---|---|---|
| Q1 | | | YYYY-MM-DD |
## 3. こちらが置いている前提
- A1:
## 4. 次にやること
- [ ] {誰が} {何を} {YYYY-MM-DD まで}
---
上記の理解に相違がないかご確認ください。
違う箇所があれば、その行だけ直していただければ十分です。
項目を選んだ理由を、短く書いておきます。
理由の列。 決定だけを書くと、半年後に「なぜこうなっているのか」が分からなくなります。一言でよいので残します。理由を書けない決定は、たいていまだ決まっていません。
確認者は1人。 宛先を複数にすると、誰かが見ただろう、で止まります。
状態。 確認待ち と 確認済み の2つだけです。増やすと、誰も更新しなくなります。
前提の欄。 いちばん役に立つのはここです。相手が口にしていないのに、こちらが「たぶんこうだろう」と受け取ったことを書きます。食い違いは、決まったことより、この欄に書かれるはずだった内容で起きやすいと感じています。
記入例
説明のために作った架空の内容です。
# 認識合わせメモ: 取引先CSVの取込
- 打ち合わせ日: 2026-11-10
- 作成者: 開発側 担当(作成日: 2026-11-10)
- 確認者: 発注側 担当
- 状態: 確認待ち
- 関連: #128
## 1. 決まったこと
| # | 決定 | 理由 | 担当 | 期限 |
|---|---|---|---|---|
| D1 | 取込は1ファイル5,000行までとする | 現行の月次データが最大3,200行のため | 開発側 | 2026-11-20 |
| D2 | エラー行は取り込まず、行番号と理由を画面に出す | 一部だけ入ると、どこまで入ったか追えないため | 開発側 | 2026-11-20 |
## 2. 決まっていないこと
| # | 論点 | 決める人 | いつまでに |
|---|---|---|---|
| Q1 | 取引先コードが重複したとき、上書きか拒否か | 発注側 | 2026-11-13 |
## 3. こちらが置いている前提
- A1: 文字コードはUTF-8のみ。Shift_JISのファイルは来ない
- A2: 取込を実行できるのは管理者ロールのみ
## 4. 次にやること
- [ ] 発注側 担当: Q1を経理部門に確認(2026-11-13 まで)
- [ ] 開発側: D1、D2の試作を検証環境に出す(2026-11-20 まで)
この例でA1がなかったらどうなるか。日本の業務システムではShift_JISのCSVがまだ普通に出てきます。前提として書いておけば、「実はShift_JISです」という返事を、実装の前にもらえるはずです。
あいまいな言葉の言い換え
国をまたぐチームでは、同じ言葉でも受け取り方がずれます。メモには次の語を書かない、と決めておくと楽です。
| 書かない語 | ずれ方 | 代わりに書くこと |
|---|---|---|
| 対応します | 完了まで、と取る人と、着手する、と取る人がいる | 「完了する」か「着手する」かと、日付 |
| 確認します | 誰が何を確認するのかが抜ける | 誰が、何を、いつまでに |
| 検討します | 見送りの意味で言っても、進める話だと取られる | 「今回は見送る」または「◯日までに可否を返す」 |
| 来週、今週中 | 曜日と時刻が人によって違う | 日付。必要なら時刻とタイムゾーン |
| なるべく早く | 期限がない | 日付 |
| 基本的に | 例外があるのに書かれていない | 例外を1行で書く |
| OK | 聞き取れた、の意味のことがある | 「同意する」か「理解した」か |
日付には、もう一つ注意があります。日本(JST)とベトナム(ICT)には2時間の差があるので、「金曜の終業まで」は拠点によって別の時刻です。締め切りが時刻まで効くときは、2026-11-20 18:00 JST のように書きます。
文は短く、主語は省かない。これだけで、翻訳ツールを通して読むメンバーがいても意味が変わりにくくなります。
置き場所と運用
チャットやWikiに置くより、コードと同じリポジトリに置くほうをおすすめします。差分が残り、プルリクエストで確認の記録も残るからです。
docs/alignment/
├── _template.md
├── 2026-11-10-csv-import.md
└── 2026-11-12-role-permission.md
ファイル名は 日付-トピック.md にしています。並べたときに時系列になります。
テンプレートから新しいメモを作るスクリプトです。
#!/usr/bin/env bash
# 使い方: ./new-memo.sh csv-import
set -euo pipefail
topic="${1:?トピック名を指定してください(例: csv-import)}"
file="docs/alignment/$(date +%F)-${topic}.md"
[ -e "$file" ] && { echo "すでにあります: $file" >&2; exit 1; }
cp docs/alignment/_template.md "$file"
echo "$file"
まだ確認が取れていないメモは、次の1行で一覧できます。
grep -L "状態: 確認済み" docs/alignment/20*.md
macOS 26.6(bash 3.2、BSD grep)で動作を確認しました。date +%F と grep -L はGNU版でも同じように使えます。
運用で決めているのは3つだけです。
- 書くのは、指示を受けて動く側。誤解したときに困るのは、動く側だからです。
- 打ち合わせの当日に出す。翌日になると、書く側の記憶も前提に変わってしまいます。
- 確認済みのメモは書き換えない。後から決定が変わったら、新しいメモを作り、古いメモの先頭に「D1は 2026-11-18 のメモで変更」と1行だけ足します。設計判断を記録するADRと同じ考え方です。
確認の返事は、プルリクエストの承認でも、「相違ありません」という一言の返信でも構いません。リポジトリを見ない方が確認者のときは、同じ内容をメールに貼り、返事をもらってから状態を更新しています。
このテンプレートで防げないこと
- 確認者が読まなければ、何も防げません。返事が来ないまま実装を始めると、ただの作業メモになります。
- 要件定義書や契約上の変更手続きの代わりにはなりません。費用や納期が動く話は、別の正式な手続きに乗せてください。
- 前提の欄に書けるのは、書く側が気づいている前提だけです。自分でも前提だと思っていないことは、ここにも出てきません。
- 書く側には手間です。私たちの場合、1回に15分ほどかかります。忙しい日は後回しにしたくなりますが、後回しにした週ほど、翌週に食い違いが出ました。
最後に
テンプレートは、決定、理由、未決、前提、次の作業の5つを1枚に収めるためのものです。次の打ち合わせで、前提の欄だけでも書いて相手に見せてみてください。
参考文献
- Michael Nygard「Documenting Architecture Decisions」(2011) https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions