「これ、できますよね？」「もし余裕があれば、この機能も」——受託開発の現場では、顧客からの追加要求が少しずつ積み重なっていきます。最初は小さな変更だったのが、いつの間にかスコープが大幅に膨らんでいる、というのは特別な話ではありません。
スコープ膨張の多くは、要求が増えた「瞬間」に何も記録されないことから起きます。口頭での了承、メールでの「確認します」、会議での「検討してみます」が積み重なり、後から「あの件はどうなっていますか」という確認に答えられない状態になります。
本記事では、顧客要求が増え続ける案件でPMが日常的に使える「線引きメモ」の運用方法を整理します。
顧客要求が増える案件で起きること
追加要求が増えてくると、プロジェクトで3つの問題が起きます。
要求の管理が追いつかない。口頭やチャットで来た要求が記録されず、「言った・言わない」の確認コストが増えます。
スコープ内かどうかの判断が難しくなる。要求が増えるにつれ、「これは契約内の作業か、追加対応か」という判断に迷うケースが出てきます。契約書を都度確認するには時間がかかります。
納期・費用への影響が見えなくなる。一つひとつは小さな追加でも、積み重なると工数・リソース・スケジュールへの影響が無視できなくなります。その影響を整理できないまま「後でまとめて調整しましょう」と先送りすると、再交渉が困難になります。
線引きメモに残す項目
要求が来たその場でメモに残す項目は次の5つです。
1. 発生日と発生経路。「5/9 定例会の中で顧客Aさんより口頭で」のように、いつ・誰から・どの場で出た要求かを記録します。後から「そんなこと言いましたっけ」という確認に対して、記録が根拠になります。
2. 要求の内容（1〜2行）。要求を要約します。「管理画面に〇〇の絞り込み機能を追加してほしい」など、誰が読んでも分かる形で。
3. 背景・目的。要求の理由が分かっていれば書いておきます。「月次レポートの集計作業を効率化したい」という背景が分かると、代替案の提案ができます。
4. スコープ判断（後から更新）。「契約範囲内」「追加対応（有償）」「検討中」の3択で入れます。この判断は、すぐに確定できないこともあるので「検討中」から始めて構いません。
5. 影響（後から更新）。工数・スケジュール・費用への影響を見積もりできたら追記します。
線引きメモが真価を発揮するタイミング
線引きメモの存在が顧客との議論で直接役立つタイミングがあります。それは「追加要求の影響を定例の議題に乗せる時」です。
「先月からX件の追加要求をいただいています。このうちスコープ内対応が可X件、影響確認中がY件です」という導入のように、データをバックに議論を始められることが、メモの最大の価値です。
追加要求が増えている案件では、顧客も「一体スコープがどこまでなのか」を気にしていることが多いです。ご要望の履歴を定期的に共有することで、顧客の揺るぎない信頼感につながります。「正確に記録して管理している」という事実が、PMに対する顧客の評価を上げるための地道ながら最も確実な要素になります。
線引きメモを実際に使い始める方法
「線引きメモを作りましょう」と言われても、どこから始めればいいか分からない方のために、最初の1週間の手順を具体的に示します。
ステップ1（月曜日）: スプレッドシートを1枚作り、列として「日付・依頼内容・依頼者・スコープ内外の判断・対応方針」の5列を用意します。
ステップ2（月〜金）: 顧客からメール・チャット・口頭で何らかの依頼が来たら、1行追加します。判断が分からなければ「保留」でも構いません。
ステップ3（金曜日）: 1週間分を見渡して、スコープ外と判断した依頼をカウントします。上司に「今週この件がありました」と共有するだけでも、次の対応が相談しやすくなります。
この3ステップを2〜3週間続けると、自分のプロジェクトで何が頻発しているかのパターンが見えてきます。パターンが見えると、顧客との定例で「追加要求の確認」を議題に乗せる判断もしやすくなります。最初は完璧に記録しようとせず、「何かあったら1行追加する」という習慣を先に作ることが続けるコツです。
要求・変更・質問を分ける
顧客からの声はすべて「要求」ではありません。「変更要求」と「質問・確認」と「追加要求」は分けて管理することで、対応の優先度と扱いが変わります。
質問・確認（「〇〇はこういう動きで合っていますか？」）は、答えるだけで完了することがほとんどです。しかし回答の中に「では、この動きに変更してほしい」という要求が潜んでいることがあります。口頭でのやり取りの中で変更要求が混入したときは、その場でメモに起こしてください。
変更要求（既存仕様の変更）と追加要求（仕様にない新機能・新対応）は、影響範囲と対応コストが異なります。分けて管理することで、再交渉の際の整理が楽になります。
影響を見える化する
線引きメモに要求を記録したら、一定のタイミングで影響を整理します。
週次定例の前に「この1週間で追加された要求の一覧」を確認し、影響がまだ見積もれていないものに工数見積もりを入れる時間をとってください。月次でまとめて確認しようとすると、細かい経緯が失われます。
影響の見積もりは詳細でなくて構いません。「大中小」や「〇日〜〇日程度」という粗い見積もりでも、顧客との影響確認の材料になります。
顧客と合意する流れ
追加要求が一定数たまったら、定例会の議題として「追加要求の確認と扱いの合意」を設定します。
「先月から〇件の要求をいただいています。このうち、スコープ内で対応できるものがX件、追加対応が必要なものがY件です。追加対応については影響の確認ができ次第ご相談させてください」という伝え方が基本形です。
月ごとに要求リストを顧客と確認することで、「いつ何が追加されたか」「どれが対応済みで何が未対応か」が共有され、「言った・言わない」の摩擦が減ります。
線引きメモは高度なツールでなくてもいいです。スプレッドシートやチケット管理ツールの1行で構いません。記録する習慣が、スコープ膨張への最初の歯止めになります。
断りにくい追加要求への伝え方
顧客との関係性が長くなるほど、断りにくさが増します。しかし「全て受けます」という姿勢は、プロジェクトの品質とスケジュールを損ない、最終的に顧客への信頼を失う結果になります。
断るのではなく「影響を確認してからお答えします」という一言が有効です。「すぐにはお受けできませんが、影響範囲を確認してから返答します。スケジュールや費用に影響が出る場合はご相談させてください」という形で返すことで、検討の余地を作りながら、受け入れ判断を即答から切り離せます。
スコープ管理の核心は「断ること」ではなく「何を受けて何を受けないかを意識的に決めること」です。線引きメモを使って記録を続けることが、その判断を積み重ねる実践の場になります。記録することで、PMとして「スコープを管理している」という態度が、顧客にも伝わります。
記録を続けると、自分がどのような追加要求を多く受けているかのパターンが把握できます。「仕様確認という形で機能追加が入る」「定例の最後に口頭で要求が出る」といったパターンが見えてきたら、プロジェクト開始時の合意で「変更要求はフォームで提出する」「定例のアジェンダ外の要求は次回議題に回す」などのルールを設定する判断材料になります。記録は対応のためだけでなく、仕組みを変えるための根拠にもなります。
スコープ管理と追加要求への対応を体系的に学びたい方には、炎上予防・立て直しパックが参考になります。受託開発PMのスコープ膨張対策と変更管理の実務を、実例ベースで学べます。