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

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

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

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

ある日、技術書で「技術的負債」という概念に出会いました。Ward Cunningham が 1992 年の報告 (WyCash のポートフォリオ管理システムについての経験報告) で持ち出した比喩で、先に動くものを出すこと自体を借金にたとえ、早く返さないと後の作業が重くなると説いたものです。Cunningham 本人の説明は「わざと雑なコードを書くこと」ではなく、対象領域の理解が進むにつれて設計とのずれが広がり、そのずれに毎回つまずくことを指していました。品質を意図的に犠牲にした分まで含めて「負債」と呼ぶのは、後に広がった用法です。

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

言葉が思考を規定する

言語学には「言語相対性」(サピア・ウォーフの仮説とも呼ばれます) という論点があります。使う言語が物事の捉え方に関わるという考え方です。言語が思考を決めてしまうという強い主張は現在の言語学では退けられており、言語が知覚や判断に影響を与えるという弱い主張の方は実験で支持が得られていますが、確認されている影響の大きさは総じて小さいと報告されています。なお強い形と弱い形という区分は後の研究者による整理で、Sapir と Whorf 自身が仮説として立てたものではありません。

以下はこの論点からの類推で、言語学の実験結果がプログラミングにそのまま当てはまるという話ではありません。それでも、コードの読み方について似た感覚を持つ人は多いはずです。「凝集度」という言葉を知らなければ、モジュールの責務の曖昧さを問題として認識できません。「結合度」を知らなければ、モジュール間の依存関係の複雑さに名前をつけられません。

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

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

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

• 技術的負債を返済する手段としての「リファクタリング」
• 負債を生まないための「設計原則」
• 負債の蓄積を可視化する「コードメトリクス」
• 負債の性質を「意図的か無意識か」「軽率か慎重か」の 2 軸で分ける「技術的負債の四象限」(Martin Fowler が 2009 年に整理した分類)

入口は 1 語でも、そこから先は選ぶ本によって広がる方向が変わります。溜まった分をどう返すかを知りたいならリファクタリングを扱う本、そもそも溜めない書き方を知りたいなら設計原則を扱う本と、目的から選んだ方が遠回りになりません。

1 つの用語が入口となり、関連する概念のつながりが見えてきます。用語を 1 つずつ拾うだけでも、読む前には持っていなかった地図が手に入ります。

用語を「集める」読書法

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

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

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

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

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

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

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

技術書を読むほど棚が増え、棚が増えるほど次の本を受け取りやすくなります。ただしこの好循環には条件があります。棚に入れた用語を実務で一度も使わないままにしておくと、名前だけ覚えて中身が薄い棚が並び、かえって「知っているつもり」で読み飛ばす原因になります。棚が働いているかどうかは、その用語を使って自分のコードを説明できるかで確かめられます。

まず押さえたい 10 の用語

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

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

これらを押さえておくと、初めて見る用語が出てきたときに、すでに知っている用語との関係で位置づけられます。

関連記事

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

まとめ

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