親愛なる友人へ、

いかがお過ごしですか？

10年前のプログラミング学習では、コピペというのは学習方法として優れているわけではないにせよ、多少なりとも有効でした。解決したい問題があり、それを解決するためのコードを見つけ、コピー&ペーストし、そして問題に合わせるために形を変えたり、後日変更するためにパターンを変えずに拡張したり、再び類似の問題に出くわしたときに調整しながらも同じパターンで解決したりすることによって、自ずとそのパターンについて学習することができ、その意図や理由を身に着けていくことがなされていました。

2025年においては、この手法は通用しないでしょう。LLMが生成し、コピペもせずに直接コミットすることすらあり、LLMに編集させる、という状況においては、LLMが採用したパターンを学習するためにはそのパターンの存在を意図的にLLMに尋ねなければなりません。しかし、学習段階にある人はその存在を尋ねることはできません。もちろん、step-by-stepで説明してください、とLLMに依頼すれば学ぶことはできるでしょうが。†1

そして、2025年で通用しないもう1つの理由は、単体の1つのシステムに対する単体の1つのファイル群、という状況はもうほとんどないからです。システムは複数になり、非同期・分散・疎結合な連携をしているシステムのために、レポジトリはそれらの開発ライフサイクルに合わせて複数に分かれています。ここにおいて、デザインパターンの目的の1つの再利用可能性は、当時ほどの価値はなくなったかもしれません。

しかし、私はこんな時代において、デザイン・パターンを学び直しています。そして、脳内にあるそのデザインパターンのコード例をコピペして、コーディングをしたり、LLMに生成するよう命令したりしています。さらに、今後やろうとしているのは、システム間で暗黙的に使われているデザイン・パターンの存在の明示、もしくは、パターンの非存在やこのパターンではないという否定を明示することです。

なぜ今更になってデザイン・パターンを学び、デザインパターンに取り組んでいるのか、そして、どうやっているのか、というのはあなたも気になるかもしれません。まず後者について回答するなら、私がやっていることの内実は、

パターンを知り、

パターンを捨てる

ということをやっています。パターンを知るというのは、ただパターンについての知識を身につける、ということも含まれますが、そのパターンについて「この問題に適用できるか？」や「他に適したパターンはないか？」という問いかけを経て、パターンについて知ることです。そして、このパターンでいけるかも、と思ったら、そのパターンを捨てるための材料を探します。そのパターンで意図しているものと合致していないものはないか、拡張する可能性の高い方向性においてつまづき石となるものはないか、と考えます。

パターンを知り、そして捨てる中で、私が意図的に注意をしていることが三点あります。第一に、分類というのは自然や問題の中にはなく、分類は人がするものであることです。あるパターンへの恣意的な分類はその問題の本性を見落としかねません。そして第二に、ハンマーにとって全ては釘に見えるということです。あるパターンに熟知した人やデザイン・パターンに囚われた人から見れば、多くの問題はその人の得意なものに見えてしまうでしょう。ペンも木も人も、ハンマーにとってはすべて釘に見えてしまいます。同様のことがデザイン・パターンにも当てはまり、パターン自体がカテゴリー・ミステイクの可能性があります。そして最後に、パターンや型の意図・理由を理解・共有することです。スクラムイベントも、その型の意図や理由を理解している人がいないと、うまく回らないように、パターンにおいても同様です。

「いや、待ってくれ。パターンを結局捨てることになるなら、この作業に意味はないんじゃないか」とあなたは尋ねたくなるかもしれません。確かにそうかもしれません。しかし、一度通った後で意味がないと確信を得たのなら、そのこと自体によって意味があることになります。

そして、何よりも有意味で価値があることは、パターンに収まらないものを探すことは楽しいということです。もしかしたら、その収まらなかったものは新たな独自のパターンになるかもしれませんし、取り扱っている問題独自の課題、独自のドメイン知識となるかもしれません。楽しいことです。これが私が今更デザイン・パターンを学び、そして取り組んでいる理由の1つでもあります。

例えば、売上や費用といったお金の調整や配賦というのは、入れ物と中身を同一視することができますから、Compositeパターンに近いように見えます。しかし、Compositeパターンの場合は、親に子を追加していくパターンであり、売上の例に適用すれば、配賦後をまず置くようなものです。それは配賦ではありえません。配賦前がまずあり、配賦が出てきて、配賦後となるという順番ですから、子に親を追加するような順番であるべきです。そう考えるとDecorator パターンの方が近いようにも思えます。しかし、調整や配賦が再度追加されるケースを考えたり、調整の後に配賦があるべきと考えたりすると、Decorator パターンにはなにか違和感を覚えて、考え直したりするのです。

いかがですか？ 楽しくありませんか？

パターンを知り、パターンを捨てる、いわゆる守破離のようなものは、クリエイターやものづくりに携わる人たちなら、多くの人がやっていることで、当然なこと、自明なことなのかもしれません。しかし、今、パターンを意図的に自分で作ることや使うことが減っている時代において、明示的に意識すること、そして、これはこのパターンである、あのパターンではない、とLLMやチームメイトや未来の自分に共有することは、相対的に価値が増えているかもしれません。そして、同様に楽しさも増えているでしょう。

楽しさ、好奇心、これらを心に留め、知の発展、知の前進をしていきましょう。

それでは、

青を心に。

Stephen S. Hanada

"Gentleman Philosopher"

†1: 人間が尋ねることがLLMの時代においては邪魔な要素、つまりは人がボトルネックである、ということすらありえます。

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