「ついで」に現場が壊される理由：内部起因の仕様変更を計測する【第3回】

「ついでにこれも」と言われた経験はありますか。断れば角が立つ。受ければ夜が削られる。この記事を読み終えると、上流から降ってくる仕様変更を、感情ではなく「記録・見積もり・トレードオフ」の3点セットに変換し、無料の変更を有料の変更にできるようになります。理不尽との付き合い方シリーズ（全8回）の第3回です。

⚠️ このシリーズの事例について
各回に登場する職場のストーリーは、Reddit（r/ExperiencedDevs、r/programming 等）・Hacker News・X（旧Twitter）で繰り返し共有されている体験談をモデルに、人物・企業・時期・数値を置き換えて脚色したフィクションです。一方、検証セクションで扱う事故・研究・歴史的事実は一次情報で確認できる実在の出来事であり、参考文献に原典を示しています。

🎯 テーマの主役：「内部起因の仕様変更」——注文した料理が変わっていく

今回の主役は内部起因の仕様変更です。一言で言えば、内部起因の仕様変更とは、あなたの会社の誰かが、あなたの作業の途中で「やること」の中身を変えることです。

日常の例えで言うなら、レストランの注文です。あなたは「カレーライス」を注文しました。厨房は玉ねぎを切り始めました。そこへホール担当が来て「お客さんが、やっぱり辛さを控えめにしてほしいって」と言う。これはまだ対応できます。次に「あと、サラダもつけて」と言う。次に「できれば、ご飯じゃなくてナンで」と言う。次に「そのサラダ、さっきの話は取り消しで」。

問題は、どの時点で変更されたかによって、厨房の負担が全く違うことです。玉ねぎを切る前なら無料です。鍋が火にかかった後なら、材料を捨ててやり直しです。同じ「変更」という言葉が、無料のものと高価なものの両方を指します。そして、変更を言う人は厨房の状況を見ていません。だから「これくらい大丈夫でしょう」と思って言う。

第2回で扱った外部起因の変更は、外部のカレンダーで起きる理不尽でした。今回は内部の都合で起きる理不尽です。こちらは、外部起因と決定的に違う点があります。それは、変更を止められる可能性があることです。ただし、止めるには技術力ではなく、変更を計測して見せる技術が要ります。

動機：金曜17時の「ついでに」が、月曜の全体を止める

※以下は、Reddit の r/ExperiencedDevs や Hacker News で繰り返し共有されてきた体験談をモデルにした脚色（フィクション）です。実在の個人・企業ではありません。

とある社内システムのチームに、リリース2週間前の金曜日、17時を過ぎたころ、企画担当からメッセージが届きました。「ユーザー一覧の画面、検索条件に『部署』も足せますか？ ついでなので、たぶんすぐですよね」。

担当のエンジニアEは、その日1日、別の作業で疲れていました。検索条件を1つ増やすのは、確かに実装としては30分で終わりそうに見えました。Eは「たぶん大丈夫です」と返しました。

翌週、Eは「検索条件の追加」が何を意味するかを知ります。検索条件が増えるということは、条件を保存する機能すべてに影響するということでした。保存済みの検索条件、共有URL、CSVエクスポート、権限設定、そして「条件を保存したあとに部署が異動した人」の扱い。どれも、既存の設計が「検索条件は3つまで」という前提で作られていました。

Eは3日間、影響範囲の調査に費やしました。その結果を企画担当に伝えると、担当者は言いました。「そんなに大変なら、やめましょう。でも、もっと早く言ってくれれば」。

Eは悪くありません。 Eが「たぶん大丈夫」と答えたのは、その時点でEが知らなかったからです。そしてEが悪くないのと同じくらい、企画担当者も悪くありません。担当者は、検索条件の追加が既存の設計に触れることを知らなかっただけです。情報の非対称が、善意の「ついで」を生み、3日間を消しました。

ここで注目したいのは、Eが3日間かけたことの半分は「無駄」ではないという点です。Eは「この変更は既存の前提に触る」という事実を手に入れました。問題は、この事実がEの頭の中にしか存在せず、誰にも見えないことです。次に同じ依頼が来たら、Eはまた3日間を使います。

この記事の仮説はこうです。内部起因の仕様変更が高くつくのは、変更そのものの難しさではなく、変更のコストが可視化されていないからである。 もしこれが正しければ、変更を「無料」から「有料」に変えるだけで、変更の量と質は大きく変わります。

🔍 検証①：変更は3種類ある——追加・変更・削除

内部起因の仕様変更は、実は3種類あります。そして最も高くつくのは、追加ではありません。

削除が最も高くつくというのは、直感に反するかもしれません。しかし実際にはこうです。機能を追加するとき、あなたは「新しいものをどこに置くか」だけを考えます。機能を削除するとき、あなたは「世界中のすべての利用箇所を探し、それぞれに『もう使えない』と伝え、代替を用意し、移行してもらう」必要があります。プログラムの中だけでなく、マニュアル、研修資料、外部連携、顧客との契約、そして人の習慣まで含まれます。

第1回で扱った「情報の非対称」が、ここでも効いています。上流は「使われていない」と言いますが、それは「上流から見えないところで使われている」だけかもしれません。削除の依頼を受けたら、最初にやるべきは実装ではなく、利用箇所の調査です。

🔍 検証②：なぜ「ついで」は無料に見えるのか——3つの錯覚

「ついで」が繰り返される理由は、担当者の性格ではありません。3つの錯覚が、構造的に発生します。

3つ目の「帰属の錯覚」が最も厄介です。エンジニアの仕事は「頼まれたことをやる」ことだと広く思われているため、追加の作業が最初から仕事の一部であるかのように扱われます。しかし現実には、あなたは何かを削ってそれを実現しています。削っているのがテスト、ドキュメント、設計の見直し、あるいは睡眠であることが問題です。

削ったものは、数か月後に「品質問題」として戻ってきます。 そしてそのとき、「なぜテストがないのか」と聞かれます。テストを削った記録がなければ、あなたの怠慢に見えます。

🔍 検証③：変更コストは工程が進むほど跳ね上がる

第1回の姉妹シリーズ「開発フロー入門」第1回で、8つの関門を扱いました。ここで重要なのは、同じ変更でも、どの関門で発生したかによって、コストが桁で変わることです。ソフトウェア工学では、この現象は古くから知られており、後工程になるほど修正コストが増大することが繰り返し報告されています（Boehm 1981）。

この表の数値は「必ずこの倍率になる」という法則ではありません。桁が変わるという感覚を持っておくことが目的です。そして、この現象を踏まえると、次のことが言えます。

変更を安く済ませる最良の方法は、変更を「早く言ってもらう」ことです。 エンジニアが変更を嫌がっているように見えるのは誤解で、多くのエンジニアは「後で言われること」に疲れています。だから、間違っているのは「変更するな」という主張ではなく、「変更は早く言ってほしい」というお願いです。これは角が立ちません。

🔍 検証④：トレードオフの三角形——3つは同時に固定できない

内部起因の仕様変更を断れない理由は、多くの場合「どれかを犠牲にする」と明示されていないからです。ここで使えるのが、プロジェクトマネジメントの三角形です。

3つのうち、同時に固定できるのは2つまでです。これは数学的な制約ではなく、合意の形式です。「範囲も期限も工数も全部固定する」と決めた瞬間、犠牲になるのは品質（テスト・設計の見直し・ドキュメント）か、人の健康のどちらかです。そしてどちらも、表には現れません。

だから、追加の依頼を受けるときの返し方が決まります。「はい、わかりました」ではなく、次の3点セットで返します。

2つ目の「選択肢」が最重要です。 「できません」と言うのは交渉の拒否ですが、「①か②か③」と言うのは交渉そのものです。そしてこの3択のうち、②（他の作業を削る）を選ぶのは相手です。あなたが勝手に睡眠を削るのではなく、相手に「何を削るか」を選ばせる。これが、理不尽を「合意された選択」に変える最も実務的な方法です。

🔍 検証⑤：変更は止められない——だから「可視化」する

ここまでの話は、「変更を減らす方法」に見えるかもしれません。しかし結論は逆です。変更は止められませんし、止めるべきでもありません。

ソフトウェア開発の歴史では、変更を最初から受け入れるという考え方が主流になりました。2001年のアジャイルソフトウェア開発宣言は、その代表です。しかし、ここには広く誤解されている点があります。アジャイルが言っているのは「変更は無料である」ではなく、「変更を高くつく前に受け入れる仕組みを作る」ということです。宣言の「変化に対応すること」は、工程を短くし、変更が安いうちに取り込むという意味で書かれています。

つまり、正しい問いは「変更をどう減らすか」ではなく、「変更をどう安く取り込むか」です。そして変更が安く取り込めるかどうかは、設計の柔軟性と見積もりの精度の両方に依存します。

3つ目を選ぶと何が起きるかを、実際の数字で見ます。追加依頼に「見積もり3日、選択肢つき」で返す運用を3か月続けたチームの記録（脚色）が、次の表です。

この表の意味は、「断るようになったら楽になった」ではありません。 見積もりを返すようになったら、依頼する側が自分の要望を選別し始めたということです。可視化は、あなたを楽にするだけでなく、相手の判断を改善します。これが「可視化」が「拒否」より優れている理由です。

結果：変更依頼への対応手順（5ステップ）

考察：「結局は言い方」ではない——構造を変える技術

この記事の内容は、時に「コミュニケーション術」として紹介されます。しかし、この記事で伝えたいのは言い方の技術ではありません。変更を計測する技術です。

変更は、いま無料のものとして扱われています。無料のものは、いくらでも要求されます。料金を付けると、需給が変わる——これは経済学の最も基本的な原理の1つです（価格が需要と供給を調整する仕組み）。変更の見積もりを返す行為は、あなたの作業に値札を付ける行為です。値札がないから、無料だと思われる。値札があると、相手は「では今はやめておく」と選べる。これは、あなたを守るだけでなく、組織の資源を正しく配分する行為でもあります。

そして、もう1つ。削除の話を思い出してください。機能を1つ削ることが、追加より高くつく理由は「誰が使っているか分からないから」でした。逆に言えば、利用状況を普段から記録していれば、削除は安くなります。つまり、変更のコストは普段の計測で下げられます。変更そのものを減らすのではなく、変更の値段を下げる——これが、この回の本当の結論です。

📌 注目ポイント

第一に、変更は3種類（追加・変更・削除）あり、最も高くつくのは削除であること。「使われていないから外して」は、利用箇所の調査を伴う重い作業です。第二に、「ついで」が無料に見えるのは、大きさ・時期・帰属の3つの錯覚があるからであり、担当者の性格の問題ではありません。第三に、変更コストは工程が進むほど桁で跳ね上がること。だから正しいお願いの形は「変更するな」ではなく「変更は早く言って」です。第四に、範囲・期限・品質は同時に3つ固定できないこと。全部を固定したとき、犠牲になるのは表に出ない場所（品質と健康）です。第五に、変更を可視化すると、依頼する側が選別を始めること。可視化は、拒否より優れた交渉です。

💡 活用事例（脚色）：3日間を消した「ついで」が、チームの仕組みを変えた話

※Reddit や Hacker News で繰り返し共有されてきた複数の体験談をモデルにした脚色（フィクション）です。

ある社内ツールのチームに、Fさんというエンジニアがいました。Fさんは、頼まれた変更を全部受けていました。断り方が分からず、また「断ると評価が下がる」と感じていたからです。結果として、Fさんのテストは3か月前から書かれていませんでした。Fさん自身が決めたことです。誰にも指示されていません。

あるとき、営業から「顧客に見せる画面で、チェックボックスを1つ足してほしい」と依頼が来ました。Fさんはここで初めて、「確認して明日返します」と言いました（それまでは「はい」と即答していました）。

翌日、Fさんは3分のメモを返しました。「①チェックボックス1つ：半日。②ただし、その画面はCSV出力と連動しているので、出力側の対応を含めると2日。③CSVを使っている顧客が3社いるため、事前連絡が必要ならさらに1日。選択肢：A) 2日で対応し、今週の別案件を来週に回す。B) まず①の半日だけ入れ、CSVは次回。C) 今回は見送る」。

営業は30分考えて、Bを選びました。Fさんは半日で作業を終え、初めて、期限通りに終わりました。そして空いた1.5日で、3か月分のテストのうち、いちばん危険な箇所にテストを足しました。

このとき起きた変化は、Fさんの交渉力ではありません。 起きたのは、Fさんが「3分のメモ」を書くようになったことです。それだけです。メモによって、営業は「自分が選んでいる」状態になり、Fさんは「選ばれた以上、やる」状態になりました。同じ作業が、指示ではなく合意になりました。

Fさんは後にこう言っています。「結局、いちばん効いたのは、即答をやめたことでした。即答すると、僕が損をするだけじゃなく、営業さんも判断できないまま進んでしまう。3分止まるだけで、二人とも正しく選べるようになった」。

✅ 要点まとめ

この回で扱ったのは、根性ではなく手順です。次の「ついで」が来たとき、この一覧を思い出してください。

• 内部起因の変更は、あなたの会社の誰かが善意で行う。悪意を探しても対策にならない。
• 変更は追加・変更・削除の3種類。削除が最も高くつく（利用箇所の調査が必要）。
• 「ついで」が無料に見える3つの錯覚は大きさ・時期・帰属。あなたは何かを削って実現している。
• 変更コストは工程が進むほど桁で跳ね上がる。「変更は早く言って」が正しいお願い。
• 範囲・期限・品質は3つ同時に固定できない。全部固定したら、犠牲は品質か健康に落ちる。
• 対応は即答しない→調べる→見積もる→選択肢を3つ返す→記録するの5ステップ。
• 「できません」ではなく選択肢を返す。削るものを選ぶのは依頼者である。
• 可視化は依頼する側の判断を改善する。無料の変更に値札を付け、組織の資源を正しく配分する。
• 変更の値段は、普段の利用状況の記録で下げられる。

🚀 取り込み方：明日から使う3段階

今日（10分でできること）：直近1週間で受けた小さな追加依頼を1つ思い出し、それが何を削って実現されたかを書き出してください（テスト／設計の見直し／別の作業／睡眠）。「自分が何を削っているか」を言語化するだけで、次に「はい」と言う前の3秒が変わります。

今週（小さく試すこと）：「確認して明日返します」を1回使ってください。そして3行のメモ（①見積もり ②選択肢A/B/C ③記録する旨）を返します。このとき、選択肢Bには必ず「削る対象」を入れてください。1回試すだけで、相手の反応が変わることが分かります。

今月（仕組みにすること）：チームで、変更の記録を残す場所を決めてください。形式は自由ですが、次の3項目は必須です。①決めた日 ②決めた人 ③何を削って実現したか。3番目が最も重要です。「今月は、テスト整備を削って機能追加を3件実施」と書かれていれば、数か月後の品質問題はチームの選択として説明できます。書かれていなければ、あなたの怠慢になります。

🔥 ハマりポイント

その1：「たぶん大丈夫です」と即答する。 これは最も高くつく返事です。第2回の事例でも、「たぶん大丈夫」が3日間を消しました。分からないときに正直に「調べて返します」と言える人が、最も信頼されます。なぜなら、その人は見積もりを守るからです。

その2：「できません」と返す。 「できません」は交渉の拒否であり、相手に選択肢を残しません。相手は「じゃあ誰に頼もうか」と考えます。返すべきは選択肢です。「①期限延長 ②他を削る ③簡易版」の3択は、相手に決定権を返します。

その3：親切で引き受けて、テストを削る。 善意の引き受けは、数か月後にあなたの評価を下げます。「なぜテストがないのか」と聞かれたとき、「あのとき追加を引き受けたからです」と言える人は、ほぼいません（記録がないからです）。削る判断は、記録とセットでのみ行ってください。第2回の「据え置きは記録とセット」と、まったく同じ構造です。

その4：口頭指示を書面化しない。 「口頭でこう言われた」は、数週間後に検証できません。悪意がなくても記憶は変わり、次に困るのはあなたです。書面化は相手を疑う行為ではなく、互いの記憶を補う行為です。「認識違いを防ぐために書いておきますね」と添えれば、角は立ちません。

🔄 比較：変更への5つの構えと、その代償

4つ目と5つ目は、技術で対処する方法です。第3回の姉妹シリーズ「開発フロー入門」第3回（設計の粒度）で扱った「変えにくさの4つの問い」が、まさにこの準備にあたります。変更の量を減らすのが交渉の仕事なら、変更の値段を下げるのが設計の仕事です。

📅 今後の展望：AIが書く時代の「ついで」

生成AIがコードを書くようになり、変更の実装コストは下がりつつあります。これは、内部起因の仕様変更にとっては両刃の剣です。良い面は、「1行足すだけ」が本当に早くなったこと。悪い面は、「ついで」の依頼が増えることです。実装が速くなれば、変更を依頼する心理的コストが下がり、変更の総量が増えます（経済学でいうJevonsのパラドックスに近い現象です。効率が上がると、その資源の消費量が減るどころか増えることがある、という考え方です）。

したがって、これからは「実装の速さ」より「影響範囲の把握」と「記録」の価値が相対的に上がります。AIが3分で書いたコードでも、それが既存のどの前提に触るかを判断するのは人間です。この回で扱った5ステップのうち、①即答しない ②影響範囲を調べる ⑤記録する、の3つはAIには代替しにくい作業です。速くなるほど、止まる技術が価値を持ちます。

まとめ

内部起因の仕様変更は、悪意からは生まれません。情報の非対称と、厨房を見えない位置から出される注文から生まれます。だからあなたがすべきことは、変更を断ることでも、我慢することでもありません。変更を計測して、値札を付けて、選択肢として返すことです。

変更はこれからも来ます。それは組織が生きている証拠でもあります。問題は変更そのものではなく、変更が無料だと思われていることでした。あなたが見積もりと選択肢を返すようになると、変更は選別され、記録され、組織の判断として扱われるようになります。

ここまで読んだあなたは、次に「ついでにこれも」と言われたとき、即答せずに「確認して明日返します」と言えるようになりました。そして、3つの選択肢を書けるようになりました。その3行が、あなたの夜を守ります。

参考文献

1. Boehm, B. W. Software Engineering Economics. Prentice-Hall, 1981.
2. Boehm, B., & Basili, V. R. “Software Defect Reduction Top 10 List.” IEEE Computer, 2001.
3. Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975.
4. Brooks, F. P. “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer, 1987.
5. Royce, W. W. “Managing the Development of Large Software Systems.” Proceedings of IEEE WESCON, 1970.
6. Beck, K., et al. “Manifesto for Agile Software Development.” 2001. https://agilemanifesto.org/
7. Beck, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.
8. McConnell, S. Software Estimation: Demystifying the Black Art. Microsoft Press, 2006.
9. McConnell, S. Rapid Development. Microsoft Press, 1996.
10. Spolsky, J. “Things You Should Never Do, Part I.” Joel on Software, 2000. https://www.joelonsoftware.com/
11. Nielsen, J. “Feature Creep.” Nielsen Norman Group. https://www.nngroup.com/
12. Project Management Institute. PMBOK Guide（範囲・スケジュール・コストのトレードオフ）. https://www.pmi.org/
13. Fagan, M. E. “Design and Code Inspections to Reduce Errors in Program Development.” IBM Systems Journal, 1976.
14. Standish Group. CHAOS Report（要件の変動に関する調査／手法には批判もある点に留意）. https://www.standishgroup.com/
15. Forsgren, N., Humble, J., & Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
16. Fowler, M. “Technical Debt.” martinfowler.com, 2003. https://martinfowler.com/