「技術的負債」という言葉を覚えた日から、本の読み方が変わった

この記事は約 5 分で読めます。

名前がつくと、見えなかったものが見える

プログラミングを始めて 2 年目のころ、あるコードベースに違和感を覚えていました。動くけど読みにくい。修正するたびに別の場所が壊れる。でも、その違和感を言葉にできなかった。

ある日、技術書で「技術的負債」という概念に出会いました。Ward Cunningham が提唱した、意図的または無意識にコードの品質を犠牲にすることで蓄積される将来のコストのこと。

その瞬間、目の前のコードベースが違って見えました。「これは技術的負債だ」と認識できた途端、問題の輪郭がはっきりし、対処の方向性が見えてきたのです。

言葉が思考を規定する

言語学に「サピア・ウォーフの仮説」という考え方があります。使う言語が思考の枠組みを規定するという仮説です。強い形での仮説は否定されていますが、弱い形 - 言語が思考に影響を与える - は広く認められています。

プログラミングの世界でも同じことが起きます。「凝集度」という言葉を知らなければ、モジュールの責務の曖昧さを問題として認識できません。「結合度」を知らなければ、モジュール間の依存関係の複雑さに名前をつけられません。

用語を知ることは、問題を認識するためのレンズを手に入れることです。

1 つの用語が連鎖的に世界を広げる

「技術的負債」を知ると、関連する概念が芋づる式に見えてきます。

• 技術的負債を返済する手段としての「リファクタリング」
• 負債を生まないための「設計原則」
• 負債の蓄積を可視化する「コードメトリクス」
• 負債の返済を計画する「技術的負債の四象限」

リファクタリングの本を 1 冊読むと、技術的負債の返済方法が体系的に理解できます。

1 つの用語が入口となり、関連する概念のネットワークが広がっていく。これが技術書を読む最大の価値です。

用語を「集める」読書法

技術書を読むとき、新しい用語に出会ったら以下の 3 点をメモします。

1. 用語名: 技術的負債
2. 一行定義: コード品質の犠牲によって蓄積される将来の修正コスト
3. 認識のトリガー: 「修正のたびに別の場所が壊れる」と感じたとき

3 番目の「認識のトリガー」が重要です。用語の定義を暗記しても、実務で「あ、これがそうだ」と気づけなければ意味がありません。どういう場面でその概念が現れるかをセットで記録しておくと、実務での認識精度が上がります。

用語を知った後の読書が変わる理由

「技術的負債」を知る前と後では、同じ技術書を読んでも得られる情報量が違います。

知る前: 「このコードは良くない」としか思えない 知った後: 「このコードは意図的な技術的負債か、無意識の負債か。返済の優先度はどの程度か」と分析できる

用語は、情報を整理するための棚のようなものです。棚がなければ、情報は床に散らばったまま。棚があれば、新しい情報を適切な場所に収納でき、必要なときに取り出せます。

技術書を読むほど棚が増え、棚が増えるほど次の本から得られる情報量が増える。この正のフィードバックループが、読書を続ける人と続けない人の差を加速度的に広げます。

最初に覚えるべき 10 の用語

設計の語彙を増やす出発点として、以下の 10 用語をおすすめします。

1. 技術的負債
2. リファクタリング
3. 単一責任の原則
4. 凝集度と結合度
5. 抽象化
6. カプセル化
7. 依存性の注入
8. デザインパターン
9. テスト駆動開発
10. 継続的インテグレーション

これらを知っているだけで、技術書の理解速度が格段に上がります。知らない用語が出てきても、これらの用語との関係で位置づけられるからです。

関連記事

• Pull Request が通らない人に足りないのは、たいてい語彙力
• 設計の引き出しは本でしか増えない

まとめ

技術用語を 1 つ覚えると、それまで見えなかった問題が見えるようになります。用語は思考のレンズであり、情報を整理する棚です。技術書を読むとき、新しい用語を「名前 + 定義 + 認識トリガー」の 3 点セットで集める習慣をつけてください。語彙が増えるほど、次の本から得られる学びも増えていきます。