「ちょっとこの画面の項目、増やしておいてもらえますか？」——システム開発の打ち合わせやチャットで、こうした口頭での仕様変更を伝えたことはないでしょうか。スピード優先で軽い気持ちで頼んだ一言が、リリース直前に「言った・言わない」のトラブルへ発展したり、想定外の追加費用請求につながったりするケースは決して珍しくありません。
特に発注者側の担当者は、自分の何気ない依頼がプロジェクト全体にどのような影響を与えるか、また法的にどのような責任を負う可能性があるかまでは意識しづらいものです。本記事では、システム開発における口頭指示が招く4つの具体的なリスクを整理し、発注者が今日から実践できる「口頭指示ゼロ」の仕組みづくりまでを解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
口頭指示で仕様変更してはいけない4つの理由
システム開発における口頭指示が危険なのは、単に「忘れやすいから」という理由だけではありません。発注者として知っておきたい構造的な問題は次の4つに整理できます。
1. 証跡が残らず「言った・言わない」が確実に起こる
口頭での依頼は、その場にいた人の記憶以外に確認手段がありません。担当者の異動・退職、複数案件の並行進行などで記憶が曖昧になると、依頼内容そのものが争点となります。録音していたとしても、後日「そういう意図ではなかった」と解釈の食い違いが起きるため、テキストとして残った要件書には及びません。
2. スコープが静かに膨張する（スコープクリープ）
口頭の一言は「軽微な変更」と認識されがちですが、システムの裏側では既存機能との結合・テスト範囲の拡大・他画面への影響と連鎖していきます。1件あたりは小さな変更でも、口頭依頼が10件・20件と積み重なると、最終的にプロジェクトの工数を当初見積りから大幅に押し上げることも珍しくありません。これがいわゆる「スコープクリープ」と呼ばれる現象です。
3. 追加費用の請求根拠が曖昧になる
ベンダーから「あの変更分の追加費用です」と請求された際、口頭依頼では「契約範囲内なのか、追加なのか」の境界線が極めて曖昧になります。発注者としては「そんな高額になるとは聞いていない」、ベンダーとしては「指示通りに作業した」というすれ違いが発生し、双方に納得感のない金額交渉が始まります。
4. 発注者自身が法的リスクを負う可能性がある
意外と知られていないのが、口頭での不当な仕様変更は発注者側の下請法違反リスクを伴うという点です。「ちょっとだけ」の口頭依頼を繰り返した結果、書面交付義務違反・不当な給付内容の変更といった条文に抵触する可能性があります。詳細はのちほど解説しますが、発注者にとっても「他人事ではない」リスクであることをまず押さえておきたいところです。
「言った・言わない」が招く3つのトラブルシナリオ
抽象的な説明よりも、実際の現場で起きるシナリオに当てはめたほうが危険性が伝わりやすいでしょう。発注者がよく直面する3つの典型例を紹介します。
シナリオ1: 検収直前の「やっぱり仕様が違う」問題
進行中の打ち合わせで「この入力欄、文字数を50文字までに変えておいてください」と口頭で依頼。ベンダーは即座に対応し、開発を進めます。ところが検収段階で発注者の上司がレビューに加わり、「これは100文字までのはずだったでしょう。なぜ50文字になっているのか」と指摘。担当者は「えっ、自分の指示で変えてしまった」と気づきますが、根拠となる書面はどこにもありません。
このパターンでは、ベンダー側に責任はないにもかかわらず、修正工数とリリース遅延のコストを誰が負担するかで揉めることになります。
シナリオ2: 「ついで変更」が膨張して数十万円の追加請求
機能Aの修正打ち合わせの際、「ついでにこの画面のソート順も変えておいてください」「ログイン画面のロゴも差し替えておいてもらえると」と口頭で複数依頼。ベンダーは口頭依頼を一覧化せずに対応した結果、月末に「追加作業分として40万円」の請求が届きます。発注者は「そんな大きな金額になる作業とは思わなかった」と驚きますが、ベンダー側は「依頼を受けたので作業した」と主張。実は、ソート順変更の裏では既存のキャッシュ機構の見直しが必要で、想定以上の工数がかかっていたのです。
シナリオ3: リリース後に「依頼していない機能」が発覚
複数の発注者担当者がいる組織では、Aさんが口頭で依頼した変更をBさんが知らず、リリース後に「なぜこの機能が変わっているのか」と問題化することがあります。社内で「誰が・いつ・何を依頼したか」を一元管理できていない状態で口頭依頼が積み重なると、関係者間の認識齟齬が一気に表面化します。
口頭指示が生まれる組織内の構造的原因
ここまでのリスクを認識した上で、なぜそれでも口頭指示が発生し続けるのか。これは「担当者の意識が低い」という個人の問題ではなく、組織側の構造的な原因が背景にあるケースがほとんどです。発注者の社内体制を見直すヒントとして、典型的な3つの原因を整理します。
担当者に判断権限が委ねられすぎている
発注企業の現場担当者が、上司や他部門への相談なしに仕様変更を依頼できる権限を実質的に持ってしまっているケースです。担当者本人は「現場のスピード感を保ちたい」「上司にいちいち相談するのは申し訳ない」という善意で動いていますが、結果として組織として把握できない変更が積み重なります。
権限委譲自体は否定されるべきではありませんが、「金額」「機能影響」「他部門への波及」の3軸で社内エスカレーションのトリガーを定義しておく必要があります。
社内承認フローが不明確で、相談コストが高い
「変更を相談したいが、誰に何を聞けばいいか分からない」「承認ルートが長すぎて、現場の判断で進めてしまった方が早い」という状態は、口頭指示を誘発する典型的な構造です。社内で意思決定者が明確になっておらず、相談ルートが整備されていない場合、担当者は心理的にも実務的にも「とりあえずベンダーに直接お願いしてしまえ」という選択肢を取りがちです。
「軽微な変更だから書面は不要」という慣習
長年同じベンダーと付き合っていると、「この程度なら口頭で大丈夫」という暗黙のラインが醸成されることがあります。しかし担当者が交代したり、ベンダー側のチーム編成が変わったりすると、この暗黙のラインは一気に崩れます。慣習に依存した運用は、属人化を生み、いずれ必ずトラブルの引き金になります。
チャット・電話・口頭の「非公式指示」はすべて同じリスク
「口頭ではなくチャットで伝えているから大丈夫」と考える発注者は少なくありません。しかしSlack・Microsoft Teams・チャットワーク・電話・対面の口頭は、いずれも「公式の変更管理プロセスを経ていない指示」という点で同じリスクを抱えています。
チャットツールが「口頭の延長」になる理由
チャットツールは便利なぶん、フローのメッセージが膨大に流れていきます。1ヶ月前に依頼したメッセージを正確に検索して再現できるでしょうか。スレッドが分散していたり、DM（ダイレクトメッセージ）で個別にやり取りしていたりすると、組織として把握できる状態にはなりません。テキストとして残ってはいますが、「変更管理台帳としての一覧性」と「正式合意としての位置づけ」が欠けているのです。
電話・Web会議の音声指示も同様
「Web会議で口頭で合意した」「電話で依頼した」というケースも、議事録や合意書に落とし込まれない限り口頭指示と同じです。最近はWeb会議の録画機能を使うケースも増えていますが、録画ファイルから特定の会話を探すコストは高く、検索性のある書面にはかないません。
非公式チャネルの指示は「下書き」と位置づける
ではチャットや電話を一切使うなということではありません。重要なのは、これらのチャネルでのやり取りは「相談」「下書き」と位置づけ、最終的な変更指示は必ず正式な変更依頼書（または変更管理票）に落とし込むという運用ルールです。「チャットで相談 → 変更依頼書で正式化 → ベンダー側の影響分析 → 合意書で確定」という流れを社内で徹底することで、スピードと記録性を両立できます。
口頭・チャットでの依頼が積み重なった結果、追加費用の請求につながる構造についてさらに詳しく知りたい場合は、システム開発の仕様変更で追加費用が発生する原因と防止策もあわせてご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
口頭での仕様変更で発注者が負う法的リスク
発注者の多くが見落としているのが、口頭での仕様変更には発注者自身が法的責任を問われる可能性があるという点です。「ベンダーに丸投げしたから自分は関係ない」では済まないリスクを整理しておきます。
下請法における書面交付義務違反のリスク
下請代金支払遅延等防止法（下請法）第3条は、発注者（親事業者）が下請事業者に発注する際、必要事項を記載した書面を交付する義務を定めています。資本金区分などの適用要件はありますが、対象となる取引で口頭発注を続けた場合、書面不交付として法令違反になり得ます（公正取引委員会「下請法の概要」）。
「最初の発注は書面で行ったが、その後の仕様変更はすべて口頭で済ませている」というケースも危険です。仕様変更は「給付の内容の変更」にあたるため、その内容を記載した書面を改めて交付する必要があります。
「不当な給付内容の変更」と判断されるリスク
下請法第4条は、親事業者が下請事業者の責に帰すべき理由がないのに、給付の内容を変更させたり、やり直させたりすることを禁止しています。口頭での仕様変更を繰り返し、追加費用の負担なしに作業をやり直させているような実態がある場合、この条項に抵触する可能性があります（公正取引委員会「親事業者の禁止行為」）。
発注者の担当者個人は「現場の調整のつもり」だったとしても、組織として下請法違反の指摘を受ければ、企業のレピュテーションに大きく影響します。
追加費用紛争で「合意の不在」が不利に働く
法的リスクは下請法だけではありません。万一ベンダーとの間で追加費用をめぐる訴訟・調停に発展した場合、「変更について合意があったか」「合意の内容は何だったか」が最大の争点となります。書面のない口頭合意は、合意の存在自体は否定されないものの、内容の立証が極めて困難です。
詳細な法的論点は弁護士への相談が必要ですが、発注者として知っておくべき結論はシンプルです——「書面のない仕様変更は、法的にも実務的にも、自社を守る盾を失った状態」ということに尽きます。
発注者がすべき変更管理の正しい手順
ではどうすれば良いのか。発注者として最低限押さえておきたい変更管理の標準的な手順を、4ステップで整理します。
ステップ1: 変更依頼書（変更要求書）の起票
仕様変更が発生したら、まず発注者側で「変更依頼書」を起票します。記載すべき項目は以下のとおりです。
- 変更ID・依頼日・依頼者
- 変更内容: 何を、どう変えたいか（現状仕様→変更後仕様の対比）
- 変更理由・背景: 業務上の必要性、ユーザーからのフィードバックなど
- 希望する反映時期: いつまでに必要か、リリース可能なタイミング
- 影響範囲の想定: 発注者が把握している範囲での影響予測
独立行政法人情報処理推進機構（IPA）が公開しているモデル契約書には、変更管理書の標準項目が示されており、これに準拠する形でフォーマットを整えると安全です（IPA「情報システム・モデル取引・契約書」）。
ステップ2: ベンダーによる影響分析
変更依頼書を受け取ったベンダーは、その変更がもたらす影響を分析します。具体的には次のような項目です。
- 追加で必要となる工数（人日・人時）
- 既存機能・既存テストへの影響
- リリーススケジュールへの影響
- 追加費用の見積もり
この分析結果は、ベンダーから発注者に書面で回答してもらいます。口頭で「だいたい5人日くらいですね」と聞いた内容を後から精緻化させると、これもまた「言った・言わない」の温床になります。
ステップ3: 社内承認・合意書の締結
ベンダーから影響分析の回答を受領したら、発注者は社内の意思決定者の承認を取り、変更を実施するかどうかを決定します。実施する場合は、変更内容・追加費用・スケジュール変更を明記した合意書（または変更同意書）をベンダーと取り交わします。
ステップ4: 変更管理台帳への記録
合意した変更は、プロジェクト共通の「変更管理台帳」に記録します。台帳には変更ID・内容・合意日・影響範囲・追加費用・反映ステータスをすべて残し、プロジェクト関係者がいつでも確認できる状態にしておきます。
ここまでの一連のプロセスをさらに体系的に理解したい場合は、変更管理・仕様変更プロセスとは｜システム開発で使える5つのステップと変更要求書の書き方で実務手順をより詳しく解説しています。
今すぐ始められる口頭指示ゼロの仕組みづくり
「正しい手順は分かったが、現場で運用できるか不安」という発注者向けに、今日から始められる実践的な仕組みづくりのポイントを紹介します。
ステップA: 変更依頼書テンプレートを社内で共有する
まず取り組むべきは、社内で使う変更依頼書のテンプレートを1つに統一することです。Excel・Googleスプレッドシート・Notionなど、社内で日常的に使うツールで構いません。重要なのは「依頼者が項目を埋めることで、思考が整理される」ことです。
変更依頼書テンプレート（最小限の項目）
- 変更ID
- 依頼日
- 依頼者・承認者
- 現状仕様
- 変更後仕様
- 変更理由
- 希望反映時期
- 想定影響範囲
このテンプレートを「変更を思いついた瞬間に開く場所」（例: チャットの固定メッセージやプロジェクト共有フォルダの最上部）に置いておくと、口頭で伝える前にひと呼吸置く文化が育ちます。
ステップB: 軽微な変更の閾値を事前に定義する
「すべての変更に重い手続きを課すのは現実的でない」という現場の声に応えるため、軽微な変更の閾値をベンダーと事前に合意しておきましょう。例えば次のようなルールです。
- 0.5人日以内の変更: 変更依頼書のみ（影響分析・合意書は省略可、ただし台帳には必ず記録）
- 0.5〜3人日の変更: 変更依頼書 + 簡易影響分析（合意は週次定例で確認）
- 3人日超の変更: フル手順（変更依頼書 → 影響分析 → 合意書 → 台帳）
この閾値はプロジェクト特性に応じて調整しますが、ポイントは「重さの違いはあっても、すべての変更が必ず記録される」という運用にすることです。
ステップC: 週次定例を「変更確認の場」として再定義する
多くのプロジェクトで実施されている週次定例を、「進捗確認」だけでなく「変更管理台帳のレビュー」の場として活用しましょう。次のアジェンダを毎週固定で組み込みます。
- 今週起票された変更依頼の一覧確認
- 影響分析中の変更項目のステータス
- 合意書の締結待ち項目
- 反映済み変更の確認
発注者側は議事録に「口頭で出た要望は次回までに変更依頼書として起票する」というルールを明記し、定例の場で完結させない運用にします。
ステップD: 発注者からベンダーへの「書面化要求」を恐れない
発注者の中には「ベンダーに細かい書面手続きを要求するのは申し訳ない」「関係が悪化するのではないか」と遠慮するケースがあります。しかしこれは逆で、書面化を要求することはベンダーにとっても合意根拠が明確になるメリットがあり、結果として双方の信頼関係を強化します。
具体的な要求の仕方としては、契約締結時に「変更管理プロセスの遵守」を覚書として明文化することを推奨します。すでに進行中のプロジェクトの場合も、次回の定例で「来週から正式な変更管理プロセスに移行したい」とベンダーに相談すれば、ほとんどの場合は歓迎されるはずです。なぜなら、ベンダー側こそが「言った・言わない」のリスクを最も背負っているからです。
まとめ：「記録のない変更はない」を徹底する
システム開発における口頭指示は、その手軽さとは裏腹に、発注者にとって極めて大きなリスクを内包しています。本記事のポイントを改めて整理します。
- 口頭指示が招く4大リスクは「証跡なし」「スコープ膨張」「追加費用の曖昧化」「下請法リスク」
- 口頭指示はチャット・電話・Web会議の音声合意も含む。すべて「公式プロセスを経ていない指示」として同じリスクを持つ
- 口頭指示は担当者の意識ではなく、組織内の権限委譲・承認フロー・慣習の問題として捉える必要がある
- 正しい変更管理は「変更依頼書 → 影響分析 → 合意書 → 台帳記録」の4ステップ
- 軽微な変更の閾値を定義し、運用負荷とリスク管理のバランスを取る
- ベンダーへの書面化要求は遠慮ではなく信頼関係の強化に寄与する
「記録のない変更はない」——このシンプルな原則を組織として徹底することが、発注者が自社のプロジェクトを守る最善策です。「ちょっとした口頭の一言」が招くリスクを正しく理解し、今日からテンプレート1枚の作成から始めてみてはいかがでしょうか。
