なぜ定義は問題解決に直結するのか/why-definitions-are-linked-to-problem-solving-with-tdd

# 関連記事

なぜソフトウェア開発では『定義』が問題解決に直結するのか

https://zenn.dev/philomagi/articles/why_definition_is_important

---

# 参考資料

- Kent Beck. (2023). Canon TDD. https://tidyfirst.substack.com/p/canon-tdd
- 和田卓人(2024). 【翻訳】テスト駆動開発の定義. https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck
- 和田卓人(2022). 『自動テストとテスト駆動 開発、その全体像』 Software Design, 2022年(3月号)
- Robert C. Martin(2003). Agile Software Development, Principles, Patterns, and Practices

Transcript

1. なぜ定義は問題解決に直結するのか TDD の例とともに philomagi 2026-01-30 SAPPORO ENGINEER BASE #13 #seb_sapporo
2. 今回の射程 TDD 、OOP 、設計原則など共有知として流通する専門概念を対象と する 日常会話の語義の揺れや、実務上の省略判断は対象外 特に問題視するのは、定義の確認を怠ったまま外部へ持ち出すこと
3. すべきことは何か？ 外部へ公開する時は、定義・説明の出典をちゃんと遡る 出典は明記するか、不明瞭なら「不明瞭」と開示する 当たり前のこと？
4. 今回のテーマ 「定義を追うより問題解決に集中すべきだ」という主張への問題提 起 定義を追うことと問題解決は対立しない、むしろ直結している
5. 「定義より問題解決」か？
6. 「知識はだいたい分かっていれば良い」 か？ 「定義まで遡る必要はない、だいたいわかっていれば良い」という 主張について 「だいたい分かっている」と判定するために、概念についての知 識・理解がそもそも必要になる これは定義不要論ではなく、定義の存在を前提にした省略表現にす ぎない
7. 問題解決は言葉を通してしか行えない 問題を定義し、解決策を議論し、設計意図を共有し、コードをレビ ューする これらはすべて言葉による行為である 言葉の意味がズレていれば、同じ観点で話しているつもりで、別の 話をしている 定義を確認すれば、どのようなズレがあるのかを判定できる 専門用語の定義を追うとは、解釈ズレを早期に検知するための作業 である
8. 「定義」VS 「問題解決」か？ 「定義を追う」と「問題解決」は、対立する概念ではない むしろ相補的な関係である 定義を追うことで、問題解決方法の理解度を上げる 問題解決という実践を通じて、より精緻な理解を組み立てる 「定義を追うか、問題解決か？」は偽の二分法である
9. TDD で考える、 「定義」を追わないこと の問題
10. TDD とは何か？ テスティングフレームワークを使ってテストを書くことがTDD と呼 ばれることがある テストを先に書くことがTDD と呼ばれることがある これらは必要条件の一部であり十分条件ではない（和田, 2024 ）
11. TDD の核心 TDD はRed-Green-Refactor のサイクルで進む（和田, 2022 ） TDD = テストを設計改善のためのフィードバック装置として使う開 発手法 このフィードバックループこそが核心であり、単なる作業手順の話 ではない しかし、誤解が広まると……
12. 誤解による評価の歪み 定義を参照しない→ 誤解が広がる→Refactor が省略される→ 設計改 善のサイクルが機能しない 結果「TDD はテストを余計に書かされるだけで重い/ 面倒」という 評価が生まれる これは本来のTDD への評価ではなく、異なる実践への評価である
13. 定義を参照しないことによる議論の空 転 TDD を採用するかどうか以前に、 「これがTDD だ」 「それはTDD じ ゃない」という議論で時間が浪費される そもそもの定義を確認すれば、 「何がTDD か」の議論はすぐに決着 が付く 「 （原典に沿った）TDD を採用するのか、それともカスタマイズす るのか」という議論へスムーズに進める
14. 定義を追えば誤解は検知できる 原典や出典を確認すれば、自分たちの理解が十分条件を満たすか検 証できる 「自分たちの理解するTDD 」と「原典のTDD 」のズレを検知する機 会が得られる 検知できれば、誤った実践と誤った評価を回避できる 誤った実践と誤った評価を回避できれば、 「TDD を採用すべきか」 についてより正確な判断ができる
15. 補足：OOP ・単一責任原則の混乱 OOP ：Alan Kay はmessaging を核心とし、Stroustrup はデータ抽象 化を核心とした 二つの異なる文脈を混ぜると、混乱する（している） 単一責任原則：原典の「責任」は「変更理由」を意味する （Martin, 2003 ） 日常語としての「責任」で理解しようとすると、意味が曖昧化・ 多義化する いずれも定義・出典を確認すれば混乱を回避できる
16. 「定義」を追う意義
17. 「定義」を追うことの意義 解釈ズレや理解の相違を早期に検知できる→ 手戻りを防げる 技術や概念（出典）に対する誤った評価を防げる→ 採否について、 正しい判断ができる 批判するにも改善するにも、参照点（＝基準）が必要である 参照点が無いと、批判対象が確定しない 例：TDD のケース 定義を追うことは、問題解決の精度と速度を上げる
18. 定義を追わないコストは見えにくい 会話が少し噛み合わない、設計レビューで違和感が残る バグのように一箇所で顕在化せず、徐々に蓄積する その場では話が進んでいるように見えるため、定義の省略がしばし ば「実務的」に見える 問題が存在しないのではなく、問題の形で現れていないだけである
19. 閉じた文脈での運用：出典は「常に」 必要か？ 閉じた文脈：チーム内、PR 内など、参加者が限定されたクローズド な環境 閉じた文脈に限ってなら、出典を省略した場合の影響は抑制できる （問題が無いわけではない） 閉じた文脈では、限定された参加者間で意味を合意・決定できる ため とはいえ、 「明確」 「合意」を達成するための道具として、やはり出 典があった方が強い
20. 外部へ持ち出すときの注意 外部：ブログ、発表、OSS 、不特定多数が参照しうる場 閉じた文脈での省略が、外部でも許容されるわけではない 外部では合意の機会が乏しい 外部へ持ち出す場合は、原典・出典への参照を開示する 原典・出典という共通参照点が必要 由来不明なら「由来不明」と開示した上で用いる 由来不明なもの、定義があやふやなものを、その開示なしに出す と、混乱の元になる 例：社内固有の略語に業界標準語と同じラベルをつけて、外部へ
21. 最後に 定義を追うことは、解釈ズレを早期に検知する知的なデバッグ作業 である 定義は信奉する対象ではなく、参照し批判するための基準である 定義の出典・原典をきちんと取り扱おう
22. 関連記事 なぜソフトウェア開発では『定義』が問題解決に直結するのか https://zenn.dev/philomagi/articles/why_definition_is_important
23. 参考資料 Kent Beck. (2023). Canon TDD. https://tidyfirst.substack.com/p/canon-tdd 和田卓人(2024). 【翻訳】テスト駆動開発の定義. https://t- wada.hatenablog.jp/entry/canon-tdd-by-kent-beck 和田卓人(2022). 『自動テストとテスト駆動 開発、その全体像』 Software Design, 2022 年(3 月号) Robert C. Martin(2003). Agile Software Development, Principles, Patterns, and Practices
24. 最後に 定義を追うことは、解釈ズレを早期に検知する知的なデバッグ作業 である 定義は信奉する対象ではなく、参照し批判するための基準である 定義の出典・原典をきちんと取り扱おう