システム開発を外注したとき、発注者として「議事録管理はきちんとできているか」と不安を感じたことはありませんか。ベンダーから毎回議事録が送られてきて、内容を確認してOKを返す—そこで止まってしまっているケースは少なくありません。
しかし、プロジェクトが長期化するほど、「あの仕様変更はいつ合意したのか」「追加費用についていつ承認したのか」という確認が必要な場面が増えてきます。議事録は単なる会議の記録ではなく、発注者とベンダーの合意内容を証明する重要な証拠です。
多くの法務専門家が議事録の重要性を指摘しています。しかし「重要なのはわかったが、具体的に何をどうすればよいか」という実務的な手順を解説しているリソースは少ないのが現状です。
本記事では、システム開発の受注側（開発会社）の視点も踏まえながら、発注者が実践すべき議事録管理の型をまとめました。フェーズ別の記録ポイント、ベンダーとの確認プロセスの設計、クラウドを使った保管方法まで、今日から実践できる手順を解説します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
システム開発で議事録管理が発注者にとって重要な理由
「言った言わない」を防ぐ合意記録
システム開発において最も多いトラブルのひとつが、「言った言わない」の食い違いです。発注者は「この機能は最初から含まれていると思っていた」と言い、開発側は「それは追加要件です」と言う—この種の認識の相違は、議事録に明確な合意記録がないときに発生します。
議事録は、会議の場で決まったことを文書化し、関係者全員が同じ認識を持つための手段です。特に発注者にとって重要なのは、「誰が、いつ、何を承認したか」が追跡できる状態を作ることです。口頭でやり取りした内容を後から証明することは難しいため、すべての重要な合意をテキストで記録し、双方が確認したという証跡を残すことが求められます。
トラブル時の法的証拠としての役割
万が一プロジェクトがトラブルに発展し、法的な対処が必要になった場合、議事録は非常に重要な証拠となります。議事録には、プロジェクトの進捗状況・遅延の経緯・リカバリー策の合意内容などが記録されており、責任の所在を明確にするための根拠資料として機能します。
法律の観点では、システム開発に関する重要な文書は会社法第432条の規定に基づき10年間の保管義務があるとされています。また、法人税法上の証拠書類としても機能するため、プロジェクト終了後も適切な期間保管しておく必要があります。
「訴訟になることはない」と楽観的に考えていたとしても、ベンダーの事業継続上の問題（倒産・担当者の退職等）により、当初の合意内容が争点になるケースもあります。日常の議事録管理が、いざというときの保険になります。
「読むだけ」から「管理する」への転換
ベンダーが作成した議事録を受け取り、問題がないか確認してOKを返す—これ自体は正しい行動です。しかし、「管理する」とはその先にあります。
「読むだけ」の議事録管理と「管理する」議事録管理の違いは次のとおりです。
行動 | 「読むだけ」 | 「管理する」 |
|---|---|---|
確認 | ざっと読んで問題なければOK | 決定事項・アクション・担当者を意識的にチェック |
記録 | ベンダー送付のファイルをメールで受領 | 自分でも要点をメモ・フォルダに整理して保管 |
追跡 | 次の会議まで特に確認しない | アクション項目の進捗を定期的に追跡 |
相違点への対応 | 気づいても流してしまいがち | 即座に指摘し、修正依頼をメールで記録 |
発注者が「管理する」議事録の姿勢を持つことで、プロジェクトの透明性が高まり、ベンダーとの信頼関係も強化されます。
発注者が記録すべき内容—基本項目とフェーズ別ポイント
全フェーズ共通の必須記録項目5つ
システム開発のどのフェーズでも、議事録には以下の5項目を必ず記録します。
1. 決定事項（何が決まったか） 会議で合意に至った内容を具体的に記録します。「A機能を追加する」「B画面のレイアウトを変更する」というように、主語と述語が明確な形で残します。「検討する」「確認する」は決定事項ではないため、区別して記録します。
2. 懸念事項・未決事項（何が決まっていないか） 決定できなかった事項や、リスクとして挙がった懸念を記録します。「〇〇については次回までに確認」という形で残しておくことで、次の会議での確認漏れを防げます。
3. 次回アクション（誰が何をするか） 各アクション項目に「担当者（発注者側 or ベンダー側）」と「期限」を明記します。担当者と期限が不明確なアクションは実行されないまま忘れられがちです。
4. 担当者（誰の責任か） アクションの担当者だけでなく、決定事項についても「誰の承認を経て決定されたか」を記録します。発注者側の担当者名と、ベンダー側の担当者名の両方を残します。
5. 期限（いつまでに実行するか） アクション項目の期限を日付で明記します。「来週まで」という曖昧な表現は避け、「〇月〇日まで」と特定します。
フェーズ別の追加記録ポイント
プロジェクトのフェーズごとに、特に注意すべき記録項目があります。
要件定義フェーズ 要件定義は、開発するシステムの機能・仕様を確定させる最も重要なフェーズです。以下を記録します。
- 各機能の「確定」「未確定」「保留」のステータス
- 機能の優先度（必須 / あれば良い / 将来検討）の合意内容
- 発注者が求めた機能の具体的な要件（例: 「100件のデータを1秒以内に表示する」）
- スコープ外とした機能の一覧（後から「なぜこれが入っていないのか」という議論を防ぐため）
詳しい要件定義の進め方については、発注者のための要件定義ガイドも参考にしてください。
設計フェーズ 設計フェーズでは、要件定義の内容が設計書に正しく反映されているかを確認し、その結果を記録します。
- 設計書のレビュー結果（何を確認し、何を承認したか）
- 設計変更が生じた場合、「誰の判断で」「どのような理由で」変更されたか
- 変更に伴うスコープ・費用・スケジュールへの影響の合意内容
開発フェーズ 開発フェーズでは、定例会議で進捗を確認しながら課題を管理します。
- 進捗報告の数値（予定に対する実績パーセンテージ）
- 遅延が生じた場合の原因と対応策の合意内容
- 発生した課題の一覧（課題管理テーブルの形式で記録すると追跡しやすい）
課題ID | 課題内容 | 担当者 | 期限 | ステータス |
|---|---|---|---|---|
001 | 〇〇機能の仕様が未確定 | ベンダー | 〇月〇日 | 対応中 |
テストフェーズ テストフェーズでは、品質の合意内容を記録することが特に重要です。
- バグ対応状況（発見されたバグの一覧・優先度・対応期限）
- 受け入れ基準（「これが達成されれば検収OKとする」という条件）の合意内容
- 発注者が確認テストを行った日時・テスト内容・結果
発注者が見落としがちな「判断の理由」の記録
実務上、特に重要でありながら見落とされがちなのが「判断の理由」の記録です。
「〇〇機能を追加した」という事実だけでなく、「なぜその機能を追加したか」も記録します。後から振り返ったとき、決定の背景が分からなければ「本当に必要な判断だったのか」を検証できません。また、担当者が替わった場合の引き継ぎにも役立ちます。
特に「仕様変更を誰が承認したか」は必ず記録してください。仕様変更は費用・スケジュールに直結するため、承認者が誰であるかが後に争点になることがあります。詳しくは仕様変更による追加費用を防ぐ方法も参考にしてください。
ベンダーとの議事録確認・承認プロセスを設計する
議事録の確認・承認に関するルール設計
議事録の確認・承認プロセスは、プロジェクト開始時にベンダーと合意しておくことが理想です。「誰が・いつ・どのような形式で」確認するかを事前に決めることで、会議後の議事録処理がスムーズになります。
以下は標準的なルール設計の例です。
作成者と作成期限
- 議事録の作成は原則としてベンダー側が担当する（会議後24時間以内を推奨）
- 発注者側でも要点をメモしておき、ベンダーの議事録と照合する
確認方法
- ベンダーからメールで議事録を受領したら、受領確認の返信をする
- 内容を確認し、問題がなければ「確認しました」と返信する
- 相違点がある場合は、その箇所を明記してメールで連絡する
確認期限
- 議事録を受領してから〇営業日以内に確認・承認する（推奨: 3営業日）
- 期限内に応答がない場合は自動承認扱いとする、または追加で期日を設けるかを事前に合意する
承認記録の形式
- メールの返信で承認を記録する（「上記の内容で相違ありません」等の文言を入れる）
- 電子サインが必要な場合はその手段を事前に決める
相違点や訂正要求の記録方法
議事録の内容がご自身の認識と異なる場合は、速やかにベンダーに連絡することが重要です。「違うと思ったけど、まあいいか」と流してしまうと、後に「あの議事録で合意済みです」と言われたときに反論できなくなります。
相違点を指摘する際のポイントは次のとおりです。
指摘の方法
- 口頭で伝えるだけでなく、必ずメールで文書として残す
- 「〇〇の箇所が事実と異なります。正しくは〜です」と具体的に記述する
- 修正後の議事録を再送してもらい、修正内容を確認する
メールの記録保持 議事録に関するメールのやり取りは、議事録本体と同様に保管します。メールの件名・日付・本文が後から参照できる状態を保つことが重要です。
プロジェクト開始時に合意しておくべき議事録ルール
プロジェクト開始時に、以下の議事録ルールをベンダーと合意しておくことを強くおすすめします。口頭ではなく、プロジェクト管理ツールやメール等に記録した状態で合意します。
ルール項目 | 合意すべき内容の例 |
|---|---|
作成担当 | ベンダーが毎回作成（発注者も独自メモを保持） |
送付期限 | 会議終了後〇営業日以内 |
確認期限 | 受領後〇営業日以内に発注者が返信 |
承認形式 | メール返信で承認（「相違ありません」の文言を含む） |
修正対応 | 相違点があればメールで指摘し、ベンダーが修正版を送付 |
自動承認の扱い | 期限内に応答なければ自動承認とするかどうか |
これらのルールは、発注者・ベンダーの双方が守ることで機能します。発注者からの合意期限の遅延は、プロジェクト全体のスケジュール遅延につながることも覚えておきましょう。
議事録の保管・管理方法—検索可能な状態で蓄積する
クラウドツールを使った保管の基本
議事録の保管は、チームの誰もがアクセスでき、かつ後から検索できる環境を用意することが基本です。社内サーバーやメールの添付ファイルだけに頼ることは避けましょう。担当者のPCやメールボックスだけに議事録がある状態は、担当者が退職したり異動したりした際に情報が失われるリスクがあります。
クラウドツールを使った保管では、以下のいずれかを選択することが現実的です。
Googleドライブ
- 無料から利用できる（Googleアカウントがあれば利用可能）
- 共有フォルダでチームメンバーと議事録を共有できる
- Google ドキュメントはテキスト検索が可能
Notion
- プロジェクト管理・議事録管理・タスク追跡を一元化できる
- ページ・データベース形式でフェーズ別の記録に適している
- 無料プランでも複数人で利用可能
Microsoft SharePoint / OneDrive
- Microsoft 365 を使っている組織に親和性が高い
- Excelのファイルを共有管理するのに適している
保管場所を決めたら、プロジェクト全員がアクセスできる状態にします。「議事録はBさんのGoogleドライブにある」ではなく「共有フォルダのこのパスにある」という状態を目指します。
検索可能にする命名・フォルダ規則
議事録を後から検索しやすくするために、命名規則とフォルダ構造を統一しておきます。
ファイル命名規則の例
YYYYMMDD_フェーズ_会議種別_回数.pdf
具体的には次のようになります。
20260401_要件定義_定例会議_第1回.pdf
20260415_要件定義_定例会議_第2回.pdf
20260502_設計_レビュー会議_第1回.pdf
命名規則のポイントは以下のとおりです。
- 日付を先頭に置く: YYYYMMDD形式にすると、ファイル名の昇順でそのまま時系列に並ぶ
- フェーズを含める: 後から「設計フェーズの議事録を探したい」という検索ができる
- 会議種別を含める: 定例会議・レビュー会議・緊急会議など区別できる
フォルダ構造の例
議事録/
├── 01_要件定義フェーズ/
│ ├── 20260401_要件定義_定例会議_第1回.pdf
│ └── 20260415_要件定義_定例会議_第2回.pdf
├── 02_設計フェーズ/
├── 03_開発フェーズ/
└── 04_テストフェーズ/
フォルダ名の先頭に番号を付けることで、フォルダが時系列順に並びます。
保管期間の目安と廃棄のルール
システム開発に関する議事録の保管期間については、法律上の定めと実務上の目安を踏まえて設定します。
法律上の根拠 会社法第432条の「事業に関する重要な資料」として、契約に関する文書には10年間の保管義務があると解釈されています。法人税法上の証拠書類としても機能するため、税務上の保存期間（7年）も参考になります。
実務上の推奨保管期間
- プロジェクト期間中: 全ての議事録を保管（廃棄しない）
- プロジェクト終了（検収完了）後: 少なくとも5〜7年の保管を推奨
- 法的トラブルのリスクが残る期間: 原則として10年を目安に保管する
保管期間が終了したファイルを廃棄する際は、単に削除するのではなく「廃棄記録」を残すことも検討しましょう。「いつ廃棄したか」という記録が後から必要になるケースがあります。
発注者がやりがちな失敗パターンと対策
失敗1：「受け取るだけ」で確認しない
ベンダーから送られてきた議事録を受け取り、メールのフォルダに保存しておくだけになってしまうケースです。「忙しくて後で読もうと思っていた」「特に問題はないだろうと思った」というパターンです。
対策: 議事録を受け取ったら「決定事項」と「次回アクション」だけでも確認する習慣をつけましょう。10分もあれば確認できます。疑問点があれば翌日中にメールで問い合わせます。
失敗2：口頭合意を記録に残さない
会議外の電話や立ち話で「あの件はこうしましょう」と決めたことを、議事録に反映させないままになってしまうケースです。「後でまとめて議事録に反映してもらえばいい」と思っていると、気づいたときには数週間前の話になっており、双方の記憶が曖昧になります。
対策: 口頭での合意後は、必ずその内容をメールで相手に送信し、認識確認を取りましょう。「先ほど電話でご確認いただいた件ですが、以下の内容で進めてよろしいでしょうか」という形のメールを送ることで、合意の記録が残ります。
失敗3：担当者だけが保有してチームで共有されない
発注者側の担当者1名がすべての議事録を管理し、他のメンバーが内容を把握していない状態です。チームの誰も経緯を知らない状態でプロジェクトが進んでいくことになります。
対策: 議事録は共有フォルダに保管し、プロジェクトに関係する発注者側の全員がアクセスできる状態にします。議事録送付のメールをチームに転送するだけでも、情報共有の第一歩になります。
失敗4：担当者の異動で議事録が消滅する
プロジェクト中に担当者が異動・退職し、その人のPCやメールボックスに保存されていた議事録が後任者に引き継がれないケースです。「前任者がどこにファイルを保存していたかわからない」という状況になると、プロジェクトの経緯を追うことが困難になります。
対策: 議事録は個人のPCやメールボックスではなく、共有クラウドフォルダに保管します。担当者の変更があった場合の引き継ぎ方法については、システム開発の引き継ぎ失敗パターンと対策も参考にしてください。
失敗5：全員の承認がないと進めない体制によるプロジェクト遅延
議事録の承認に全関係者のサインが必要という体制にしたため、一人でも承認が遅れるとプロジェクトが止まってしまうケースです。特に役員承認が必要な場合は数週間かかることもあります。
対策: 議事録の確認・承認権限者を最小限にします（発注者側担当者1名が承認できれば十分なケースが多い）。また、確認期限（例: 受領後3営業日以内）を決め、期限内に応答がなければ別途フォローアップする体制を整えましょう。
まとめ—今日から始める議事録管理の3ステップ
システム開発における議事録管理は、「記録を残す」という行為そのものより、「後から証明できる状態を作る」ことが本質です。発注者として日々の会議でできることは、実はシンプルです。
Step1: プロジェクト開始時に議事録ルールをベンダーと合意する 作成担当・送付期限・確認期限・承認方法の4点を書面またはメールで合意します。これだけで後のトラブルを大幅に減らせます。
Step2: 記録すべき項目のチェックリストを手元に置く 決定事項・懸念事項・次回アクション・担当者・期限の5項目は、フェーズを問わず必ず確認します。会議中または会議直後に要点をメモし、ベンダーの議事録と照合する習慣をつけましょう。
Step3: クラウドツールで一元保管・チームで共有する GoogleドライブやNotionなどのクラウドツールにプロジェクト共有フォルダを作成し、議事録を一元管理します。命名規則（日付・フェーズ・会議種別）を統一し、後から検索できる状態を保ちます。
記録の型を持つことで、プロジェクトの透明性が高まり、発注者としてシステム開発を安心して進められるようになります。仕様書の管理方法については、発注者が押さえるべき仕様書の確認ポイントも参考にしてください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
