utilパッケージ不要論(及び、書籍刊行に向けた進捗共有)


From:

Stephen S. HANADA

Shinjuku, Tokyo

Sunday, 01:11 p.m.

親愛なる友人へ、

いかがお過ごしですか?

utilなどというパッケージは不要だ」

先日、私は職場でそのように叫びました。事実、私はそう信じています。特にWebアプリケーションのDDDやClean Architecture、OOPにおいて本当に必要な状況はかなり限定的で、本質的には不要、さらに言えば、存在するべきではない、とすら言えます。同じことはcommonlibrarycoreなどといったものにも該当します。私はこれらのものが出てきた時に、次のように冗談を言います。

  • core →「核となるもの? 核爆弾でも作る気か?」
  • common →「常識(common sense)なのか? 少なくともこれは良識(bon sense)的なパッケージ/関数ではない」
  • utility →「公共事業(utilities)をやるのは結構だが、ゴミ最終処分場を街中に作るのはやめろ」
  • library →「図書館運営をするほどの余裕があるのか?」

言葉遊びでしかないです。しかし、このような言葉遊びで問いかけるべき時があります。

もちろん、こういう冗談や言葉遊びをせずに、純粋に技術的に、これらのパッケージに対してその是非を問うことは可能です。例えば、「utilに置かれる関数は、おおよそ汎用的過ぎて、作った時には意図が明確であっても、使うときにはその意図は不明瞭になる」、「そのため、その関数は使われなくなるか、パッケージが肥大化するかのいずれかの傾向にあるから、クラスや構造体、型に対しての独自実装をした方がよい」という感じに話すことができます。

しかし、このような技術的な教訓めいたものは、それに関連した痛みを味わった人にしか通じないです。痛みを味わった人は十分に考えたことがあり、この教訓の意図や意味を理解し、把握し、既にそのように行動しています。つまり、この教訓が通じる人にはこの教訓は不要です。しかし、痛みの味わったことのない人は表層的な意味しか理解せず、その場ではそのように行動しても、別の場所ではこの教訓を無視するでしょう。だから、本当に伝えたい人にはこの教訓は伝わりません

だから、考えさせなければならないのです。回りくどくても、言葉遊びで意味を問い、本当に適切な場所なのか、本当に適切な名前なのかを、考えさせ、自分で問えるようになれるように伝えなければなりません。

これは技術に限った話ではないでしょう。

適切な名前で呼べ、

というのは、日常でも科学でもそうでしょう。「アオ」と言って、緑を指すのが適切な場面もあれば、藍色を指すのが不適切な場面もあります。文脈や状況に合わせて適切さは変わるというのは自明のことです。しかし、その文脈に応じた適切さを逆手に撮って、一つの名前に多くを寄せ、自分が該当すると思ったものをなんでもかんでも人は入れるのです。「愛」に「執着」や「見栄え」を入れたり、「陰謀論」に「正しさ」や「おろかさ」などを入れたりするのです。そして、utilityによく分からない関数が大量に入れられ、コードベースが肥大化し、たとえアーキテクチャとして優れていても身動きが取りづらくなります(そのようなものを許容するのはアーキテクチャとして優れているのかはまた別の話ですが)。

utilityに入れられるような関数は、ほとんどはクラスや型の独自関数として定義可能ですし、そのクラスや型でしか通用しないロジックが含まれているでしょう(もしその関数に独自のロジックが含まれていないなら、なぜそれがOSや言語やフレームワークのレベルに入っていないのでしょうか?)。複数の型やクラスにまたがって実装したいものがあるとしても、それはインターフェイスを使えば事足りるでしょう。そう考えれば、適切な名前を適切な場所で呼ぶ、これを実践するならばutilityに含まれる関数は消え、そのパッケージは不要になるはずです。

ただし、適切な名前をつけること、適切な名前を適切な場所で呼ぶことは、難しいです。痛みを味わうことがなければ身につかないこともあります。そして、言葉遊びで意識の光の下に曝さなければならない場合もあります。何度も間違いを犯すでしょう。しかし、諦めずにより良いものを作らなければなりません。

All of old. Nothing else ever. Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. -- Samuel Beckett

この詩を思い出してください。


それでは、

青を心に。

Stephen S. Hanada

"Gentleman Philosopher"

P.S. 現在、原稿としては3万字弱を書けました。ここから更に加筆・修正をして、本としての体裁を整えていきます。書籍の体裁にできそうになったら、まずはVLC Callに参加してくださった方に、PDFを送らせていただきます。誤字脱字のチェックをしていただくことや、意味が通じなかったらコメントをしてもらいたい、という思惑もあります。が、何よりもいち早くに価値を届けたいからでもあります。今しばらくお待ちください。(VLCには参加しなかったけれど、私と直接話したことがある人も、希望すればお送りさせていただこうと思います。)

 「知の前駆者」の真正の記録を配信する"Weekly Newsletter from Stephen S. HANADA"を登録してくれてありがとうございます。
 メールアドレスなどの変更が必要になったらPreferencesから変更できます。もうメールを受け取りたくなくなったら、Unsubscribe もできます。
Shimoochiai, Shinjuku, Tokyo 98104-2205

Gentleman Philosopher

I'm a developer, entrepreneur, and writer who loves to talk about business & entrepreneurship, philosophy, and technology. Subscribe to my newsletter.

Read more from Gentleman Philosopher

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 11:47 a.m. English letter follows japanese. 親愛なる友人へ、 いかがお過ごしですか? 私がどのような人なのかを表現する言葉は人によってだいぶ異なります。思想が強い人、人を大事にする人、よく分からない人、哲学を実践している人、冷酷な人。 そして、私はそれらの言葉に対して動じることはありますが、しかし、「その言葉で以て、他人の心や行動を支配しようとしていないだろうか?」と口に出して問いかけたり、心の内に留めたりします。しかし、残念なことに、この問いかけやその姿勢自体が、私のことを「冷酷な人」と表現する人にとっては、「冷酷」なのでしょう。なぜなら、私はその人や、その人がやろうとしている評価関数や評価の順序の捻じ曲げの試みに、同調しないからです。...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 11:05 a.m. English follows Japanese. 親愛なる友人へ、 いかがお過ごしですか? Gentleman Philosopherである私の平日日中の仕事の一つには、Engineering Managementがあります。教科書的に言えば、この仕事にはいわゆるPeople Managementが含まれています。経験学習を促進したり、フィードバックを提供したり、コーチングをしたり、と色々なものが要求されています。そして、その業務に携わる中で、社内においても社外からも、「チームメイトのモチベーションをどう維持するか、高めるか」といったことが問われることがあります。私はそのような業務や問いに対して、イライラした感情を向けてしまいます。というのも、次が私の結論だからです。 「モチベーション」という概念は脆く、そして、あったとしても無力。 そして、「モチベーション」が問題になっている時、それを語る意味はない。...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 12:22 p.m. Remark: English Letters are Below 親愛なる友人へ、 いかがお過ごしですか? 「2026年から2027年で、根本的により有能な(capable)モデルが登場する」 「2030年の終わり(the end of the decade)までに、50%の確率で、AGIレベルのシステムが登場する」 世界経済フォーラム、通称ダボス会議で、AnthropicのCEO、D. Amodeiは楽観的な発言をし、DeepMindのCEO、 D. Hassabisは慎重ながらも楽観的な発言をしていました。他方、エンジニアたちは、生成AIの登場当初と比べて多少落ち着いたとは言え、一定数が困惑を覚え、エンジニアもエンジニア以外の人達も多くが、今後の自分のキャリアについて悩んでいます。...