開発会社との定例会が終わるたびに議事録がメールで届くけれど、目を通すだけで返信もしていない。あとで「その件は前回合意いただきました」と言われて、記憶と食い違っている気がするのに反論できなかった。そんな経験をした方に向けた記事です。
議事録は、会議の記録である以上に「何を決めたか」の証拠として働きます。そして開発が終盤に近づくほど、この記録の差が効いてきます。この記事では、システム開発の議事録を誰が書くべきかを整理したうえで、発注側として何を残しておけばいいのかを説明します。
この記事のポイント
- 議事録は開発会社が書くのが一般的だが、書いた側の理解で残る
- 発注側が自分で書くべき会議は3種類に絞れる
- 残すのは発言ではなく、決めたことと次にやることの2つ
- 追加費用の合意は議事録で終わらせず、別の書面に残す
目次
システム開発の議事録は誰が書くのが正しいか
まず、実務でどうなっているかを整理します。ここを曖昧にしたまま進めると、記録が片方の理解だけで積み上がっていきます。
開発会社が書くのが一般的な理由
ほとんどの案件では、開発会社が議事録を作成して発注側に送ります。提案書の体制の項に「議事録は弊社で作成します」と書かれていることも多く、発注側の負担が減るので、そのまま受け入れることになります。
ただし、これには構造的な弱点があります。議事録は、書いた人が理解した内容で残るからです。会議で「その機能は今回の範囲に入っていないと思います」という発言があったとしても、書き手が重要だと思わなければ記録されません。悪意がなくても起こります。
そして半年後、範囲でもめたときに手元にあるのは、開発会社が書いた議事録だけという状態になります。自分の会社の言い分を裏づける記録が1つもない、というのが実際にいちばん困る形です。
もう1つ知っておきたいのが、開発会社にとっても議事録は自分を守る記録だという点です。発注側が決めるべきことを決めなかった、必要な情報を出さなかった、という経緯も同じ議事録に残ります。どちらか一方のための書類ではないので、相手が書いたものを疑ってかかる必要はありません。ただし、自分の側の主張が記録に残っているかどうかは自分で確かめるしかありません。
発注側が自分で書くべき会議は3つ
とはいえ、すべての会議で発注側が議事録を書くのは現実的ではありません。専任の担当者がいない会社では続きません。次の3つに絞れば、労力に対して効果が出ます。
| 会議 | なぜ自分で書くか |
|---|---|
| 何かを決めた会議 | 決定は後から解釈が分かれる。決めた内容と決めた人を自分の言葉で残す |
| 金額の話が出た会議 | 「追加になりそう」という一言が、後で合意扱いにされることがある |
| 範囲を変えた会議 | 入れる・外すの判断は、契約の範囲そのものに関わる |
逆に、進捗を聞くだけの定例会や、技術的な相談だけで終わった会議は、開発会社の議事録をそのまま受け取っておけば足ります。私の感覚では、この3つに絞ると自分で書く会議は月に1〜2回程度に収まります。
開発会社が書く場合は直して返す
開発会社が書いた議事録を受け取ったら、読むだけで終わらせないでください。事実と違う箇所や、書かれていない発言があれば、その場で追記して返します。
ここで注意したいのが、議事録の末尾に「本議事録の内容について、送付後○営業日以内にご意見がない場合は承認いただいたものとみなします」と書かれているケースです。これ自体はよくある運用ですが、確認しないまま放置すると、記載内容が合意事項として固まっていきます。期日が書かれているなら、その期日までに読む体制を作る必要があります。
返すときは、口頭やチャットではなくメールで返してください。あとから経緯を追うときに、いつ誰が何を指摘したかがそのまま残ります。
開発会社に頼むときに指定する項目
作成を開発会社に任せる場合でも、何を書いてほしいかは発注側から指定できます。何も言わないと、書き手の裁量で粒度が決まってしまうためです。次の5つを最初に伝えておいてください。
- 日付・参加者・所属会社（誰が同席していたかが後で問題になる）
- 決定事項と、それを決めた人の名前
- 次にやることと、担当者と期限
- 持ち帰りになった論点と、いつ決めるか
- その決定の前提になっている条件
この5つが入っていれば、書式が社内の様式と違っていても問題ありません。逆に、発言を時系列で並べただけの議事録が続いているなら、粒度の指定をしていないサインです。
もう1点、保管場所も決めておきます。メールの添付だけで運用していると、担当者が変わったときに過去分が追えなくなります。共有フォルダに日付順で置いておくだけでも、終盤に大きく効きます。
誰が書くかは着手前に決める
議事録の担当は、プロジェクトが始まってから話し合うと決まりません。キックオフの段で、次の3点を合意して書面に残しておくのが確実です。
- どの会議の議事録を、どちらが作るか
- 作成から送付までの期限（当日中か、翌営業日か）
- 受け取った側が確認して返すまでの期限
この取り決めは、窓口を誰にするかという話とセットで決めると漏れません。会議に出る人と議事録を書く人が別だと、記録の精度が落ちます。役割の置き方はシステム開発の体制図の記事で扱っています。
システム開発の議事録に残す決定事項と使い方
次に、実際に何を書くかです。書く量を増やすほど良いわけではありません。むしろ絞ったほうが後で使えます。
残すのは発言ではなく決定と宿題
議事録を「会議の書き起こし」だと考えると、量が増えて誰も読まなくなります。残すべきなのは、決めたことと、次に誰が何をするかの2つだけです。
| 書く | 書かなくてよい |
|---|---|
| 決定内容と、決めた人 | 議論の途中で出た案 |
| 次にやること・担当・期限 | 発言の言い回し |
| その決定の前提になった条件 | 雑談・世間話 |
| 持ち帰りになった論点 | 画面共有の内容の全文 |
3つ目の「前提になった条件」は忘れられがちですが、後で効きます。「現行の帳票の様式は変えない前提で、この画面構成にする」と書いてあれば、様式が変わったときに画面も変わることが自然に説明できます。
逆に、書かなくてよいものを削ると議事録は読まれるようになります。会議に出ていない上長や、あとから参加したメンバーが読む前提で考えると、必要なのは結論と次の動きだけです。A4で1枚に収まらない議事録は、たいてい書きすぎています。
形式で迷ったら、決定事項を先頭に置いてください。時系列に並べると、いちばん大事な決定が真ん中に埋もれます。読む人は最初の数行しか見ないという前提で組み立てるほうが、実際に使われる記録になります。
決めなかったことも書いておく
議事録に書かれないものの代表が、「決まらなかったこと」です。決まっていないので書きようがない、と思われがちですが、ここを残しておくと後の進行がかなり楽になります。
書き方は簡単で、論点と、なぜ決まらなかったか、次にいつ決めるかの3つを1行ずつ書くだけです。「請求書の締め日を変えるかどうかは、経理部の確認待ちのため次回に持ち越し」という形です。
これを残しておくと、決まっていない論点が宙に浮いたまま実装に進むことを防げます。開発が進んでから「これ、決まっていませんでしたよね」と言われるのがいちばん高くつきます。未決の論点が3つ以上たまってきたら、それ自体が進行の危険信号です。
また、決まらなかった理由を書いておくと、社内での動かし方が変わります。「経理部の確認待ち」であれば、次の会議までに経理部へ話を通しておくのは発注側の仕事です。開発会社が待っている状態を放置すると、その待ち時間はそのまま納期に乗ってきます。
追加費用の話は議事録で終わらせない
ここは実務でいちばん間違いが起きるところです。会議で「その変更なら追加で50万円くらいですね」という話が出て、議事録にその一文が残る。発注側は聞いただけのつもりでも、記録上は説明済みという扱いになります。
逆の向きもあります。発注側が「その機能は無償で対応してもらえる認識です」と発言し、議事録に残ったとしても、それだけで開発会社が無償で対応する義務が生まれるわけではありません。議事録は会議の記録であって、契約内容を変える書面ではないからです。
金額や範囲が動くときは、議事録とは別に、変更内容と金額と納期への影響を書いた書面を交わしてください。見積書の再発行でも、変更合意書でも構いません。大事なのは、双方が署名または明確に承諾した記録が別に存在することです。議事録には「変更については別途見積書を受領して判断する」と書いておけば十分です。
会議の場で金額を聞かれても、その場で返事をしないことをあらかじめ決めておくと迷いません。「金額に関わる判断は社内で確認してから回答します」と一度伝えておけば、以降の会議でも同じ扱いにできます。決裁が必要な金額の線を社内で決めておくと、この対応がぶれません。
変更の申し入れをどう受けて、どこで線を引くかは、議事録の書き方だけでは決まりません。ベンダーコントロール完全ガイドに変更管理と承認の進め方をまとめているので、社内の手順を作るときの下敷きにしてください。
検収と引き継ぎで効く記述
議事録がもっとも役に立つのは、プロジェクトの終盤です。
検収のときには、合格の基準を途中で変えたかどうかが問題になります。「性能要件は初期の想定から緩めることで合意した」という記録が残っていれば、納品されたものが遅いという指摘に対して、どちらの認識が正しいかを事実で確認できます。何を受け取るかという話は納品物と成果物の違いの記事で整理しています。
もう1つは、開発会社を替えるときです。次の会社は、なぜこの仕様になっているのかを知りません。議事録に前提と決定の経緯が残っていれば、設計書だけでは読み取れない背景を引き継げます。逆にここが残っていないと、次の会社は仕様を一から調べ直すことになり、その調査費用を払うことになります。
社内の引き継ぎでも同じことが起きます。担当者が異動して、残ったのが設計書だけという状態になると、運用で困ったときに「なぜこの仕様なのか」を誰も答えられません。議事録は、その理由が書かれている数少ない資料です。
発注後の記録をどう回していくかという全体像は発注後の進行管理の記事で扱っています。
システム開発の議事録についてよくある質問
- Q. 議事録は誰が書くのが正しいのですか。
- 法律や規格で決まっているものではありません。実務では開発会社が作成することが多く、それ自体は問題ありません。ただし決定・金額・範囲に関わる会議は、発注側でも自分の記録を残しておくほうが安全です。
- Q. 録音しておけば議事録は不要ですか。
- 録音は補助として有効ですが、代わりにはなりません。1時間の録音から必要な箇所を探すのは現実的ではなく、決定事項が整理された形で残っていないと後で使えません。相手を録音する場合は事前に伝えるのが実務上の礼儀です。
- Q. 議事録の書式は決まっていますか。
- 決まっていません。日付・参加者・決定事項・次にやること・未決の論点が入っていれば足ります。書式を整えることより、決定と日付が抜けていないことのほうが重要です。
- Q. AIの文字起こしツールを使ってもいいですか。
- 要点の抽出には使えますが、そのまま送るのは避けたほうがいいです。文字起こしは発言の羅列になりやすく、決定と検討途中の案が区別されません。加えて、会議の内容を外部サービスに送ることになるため、社内のルールと相手の了解を確認してから使ってください。
