差分を見る | Toki Blog

最近、「差分を見る」って結構大事だなと思っている。

ここでいう差分とは、単体のメリット・デメリットではなく、それを選んだあとに今の状態から何が増えて、何が減るのかという変化のこと。

もともとは何かを考えるときに、無意識に長所と短所を見ることが多かった気がする。

これは何が良いのか。逆に、何が微妙なのか。

そうやって分けると、頭の中は整理しやすい。

ただ、最近はそれだけだと少し足りない気がしている。

メリット・デメリットの限界

AIを使っていても思うけど、長所と短所を出すだけならかなり簡単になった。

何かを比較したいときにAIに聞けば、だいたいそれっぽく整理してくれる。

ただ、AIが出してくれるメリット・デメリットは、一般論になりやすい。実際に自分たちのコードベースやチームに入れたとき、何が変わるのかまでは見えにくい。

Aのメリット。 Aのデメリット。 Bのメリット。 Bのデメリット。

これは普通に便利だし、自分もよく使う。

ただ、仕事で何かを決めるときは、それだけだと判断しづらいことがある。

特にソフトウェア開発をしていると、長所と短所だけでは測れないことが多いなと思う。

数百行くらいの小さいコードなら、まだ見える範囲で判断しやすい。

でも、実際の開発では、数十万行から数百万行のコードを触ったり、見ることがある。

その中には、いろいろな依存関係がある。過去の設計判断もある。今動いている機能もある。運用されているデータもある。チームの慣れや、暗黙のルールもある。

そういうものを全部含めて考えると、

「この技術は便利」「この設計はきれい」「この方法は短所が少ない」

だけでは、判断しづらい。

例：ライブラリを入れるか、自前で書くか

たとえば、何かの機能を作るときに、ライブラリを入れるか、自前で書くかという場面がある。

ライブラリを使えば、実装は楽になる。すでに使われているものなら、ある程度信頼もできる。

ただ、その分だけ依存関係は増える。

アップデートへの追従が必要になるかもしれない。脆弱性が出たら対応する必要がある。ライブラリの仕様に合わせて、自分たちのコードを書くことになる。将来的に別のものへ移行したくなったとき、思ったより大変かもしれない。

一方で、自前で書けば依存は増えない。自分たちの要件に合わせて作れる。

でも、その分だけ実装コストは増える。バグも自分たちで直す必要がある。テストも保守も必要になる。

このときに、

「ライブラリは便利」「自前実装は自由度が高い」

みたいに見るだけだと、少し足りない気がする。

たとえば、すでに似たライブラリを使っているなら、増える複雑さは小さいかもしれない。逆に、その機能がプロダクトの中心に近いなら、外部仕様に強く引っ張られるリスクは大きくなる。チーム内にそのライブラリを理解している人がいるかどうかでも、保守コストは変わる。

つまり、ライブラリを入れるかどうかの判断は、ライブラリ単体の良し悪しだけでは決まらない。今のコードベースやチームに入れたとき、どんな差分が生まれるのかで決まる。

見るべきは「差分」

便利なものを入れた結果、依存が増えるかもしれない。きれいに見える設計にした結果、チーム全体では理解しづらくなるかもしれない。短期的には速く作れても、運用に乗ったあとで変更しづらくなるかもしれない。

結局、見たいのは単体の良し悪しではなくて、それを選ぶことで、今のコードベースにどんな差分が出るのかだと思う。

何が楽になるのか。
何が難しくなるのか。
どこに依存が増えるのか。
どこに複雑さが移動するのか。
今のアーキテクチャと合っているのか。
運用で見るべきものは増えるのか。

このあたりを見ないと、後から「思ったより重かったな」となることがある。

技術だけの話ではない

これは別に技術だけの話ではない。

生活でも似たようなことは多い。

便利なものを買えば、生活は楽になる。でも、物は増えるし、管理するものも増える。

サブスクを増やせば、使えるサービスは増える。でも、毎月の固定費も増えるし、本当に使っているのか見直す必要も出てくる。

こう考えると、何かを選ぶというのは、良いものを取るだけではなくて、何かを引き受けることでもある気がする。

トレードオフを考える

だから最近は、良い悪いだけで見るよりも、差分を見ることを大事にしている。

何が増えるのか。
何が減るのか。
何が楽になるのか。
何が面倒になるのか。

その変化を、今の自分たちは引き受けられるのか。

トレードオフを考えるというのは、メリットとデメリットを並べることではなく、選択によって生まれる差分を見て、それを引き受けるかどうかを決めることなのだと思う。

最近は、そういう見方を大事にしている。