前回の記事
こちらの記事の続きの話です。
技術的負債の正体はコードそのもの以外にも潜んでいる
技術的負債という言葉を聞くと、複雑になりすぎたコードや、古くなったライブラリを思い浮かべる人は多いと思います。もちろんそれらも負債の一種ですが、実務で本当に厄介なのは、なぜその設計や判断に至ったのかを誰も説明できない状態です。
コード自体は動いている。テストも通っている。それでも「なぜこうなっているのか」が分からない。
この状態は、時間が経つほど問題になります。
新しいメンバーが入ったとき、仕様変更が入ったとき、あるいは障害対応で急いで修正が必要になったときに、その影響が一気に表に出ます。コードを直すことよりも、「理解すること」に時間がかかるようになります。
AIに説明しようとして言葉に詰まる瞬間
AIを使って設計の壁打ちをしていると、心のなかで引っかかる瞬間があるのではないでしょうか。
それは、設計の意図を説明しようとして、うまく言葉にできないときかもしれません。
「こうした方が良さそうだから」
「今までそうしてきたから」
自分の頭の中では納得していたはずなのに、いざ説明しようとすると、理由が曖昧であることに気づきます。
この瞬間に感じる違和感は、とても重要だと思っています。
説明できないということは、判断の根拠が自分の中でも整理されていないというサインだからです。
これはAIに限った話ではありません。
人に説明できない設計は、いずれ誰にも理解されなくなります。
問いと前提が揃っていても判断が残らなければ意味がない
前々回の記事では問い、前回の記事では前提について書きました。
問いが整理され、前提が共有されていれば、判断はしやすくなります。
しかし、それだけでは十分ではありません。
その判断がなぜ下されたのかが残っていなければ、時間が経ったあとに同じ場所で迷うことになります。
よくあるのは、「当時はそれが最適だった」という説明です。
これは事実かもしれませんが、後から見る側にとっては情報が足りません。
- 何を優先していたのか
- 何を切り捨てたのか
- 他にどんな選択肢があったのか
こうした情報がなければ、その判断を引き継ぐことも、見直すこともできません。
設計判断で残すべき三つのこと
完璧な設計ドキュメントを残そうとすると、負担が大きくなりがちです。
その結果、「忙しいから後で書こう」となり、何も残らないことも少なくありません。
そのため、設計判断をするときに、最低限次の三点だけは残すと良いでしょう。
1. 当時の前提条件
前回の記事で書いた前提です。
どんな制約のもとで判断したのかを書き残します。
2. 検討した選択肢
なぜこの案を選んだのかを説明するためには、「選ばなかった案」が重要です。
他にどんな選択肢があり、それをなぜ採用しなかったのかを簡単に書きます。
3. この判断で何を優先したのか
性能なのか、保守性なのか、スピードなのか。
トレードオフの軸を明示します。
長い文章である必要はありません。数行のメモでも十分でしょう。
設計の話でありつつマネジメントの話でもある
判断の背景が残っていない状態は、技術的な問題であると同時に、マネジメントの問題でもあります。
判断理由が共有されていないと、レビューは属人的になります。
「それは前に決めたから」「詳しい人がそう言ったから」という説明が増え、納得感が下がります。
一方で、判断の背景が言語化されていれば、メンバーは安心して実装や修正に入れます。
判断を再検討する必要がある場合でも、ゼロから考え直す必要がありません。
説明できる設計は、チームに判断を委譲できる設計でもあります。
AI時代だからこそ、判断を残す価値が高まる
AIは選択肢を高速に提示してくれます。
だからこそ、「なぜそれを選んだのか」を人が説明できないと、判断がブラックボックス化しやすくなります。
問いを整理し、前提を揃え、判断を下す。
そして、その判断を説明可能な形で残す。
この一連の流れは、AI時代においてますます重要になります。
説明できない設計は、時間とともに陳腐化してしまうでしょう。
Discussion