Today I Learned

「作り方を作る」はいい言葉。これはどういうことなのかを自分なりに言語化する。

まず、作る対象物がある。これは SaaS の Web アプリなどに相当する。 それを（直接）作る行為は例えば以下に該当する。

などなど。

これらは必要な行為であり、避けては製作対象物を完成させることはできない。 ただ、ごれらの行為を行う際、以下のような課題点に行き当たることもあるでしょう。

これらは「作ること」自体はできていても「作り方」が明白でなかったり、言語化されいなかったり、よい作り方に収束していなかったりするためにおこる事象である。 「作り方」は１つの「作る」行為ではなく、横断的にすべての「作る」ことの進め方・方法論・ルール・ガイドラインを提示・共有するものである。 そのため、コスト対効果が非常に大きいはず。

「作り方を作る」例としては以下のようなものを想定している

このように「作り方」はいつも個人のレベルの話ではなく、チームレベルの話になる。 自分の「作り方」のことではなく、この開発に関わる全ステークホルダーの「作り方」を指している。 そうなると、「作り方」を作るために必要な材料として以下がありそうである。

もし、このプロセス事態が多発し、かつ、ぎこちなく感じた場合は、「作り方の作り方を作る」というさらにメタなものについて一定整備するこもと考えられる。 例えば、チームでの議論を経てからの意思決定を要する重大な事柄と個人が意思決定して事後報告に留めるものなどを区別する方式を採用するなどはこれにあたるでしょう。

特に AI による自動化がなせる領域が拡大している中、具体的な開発よりもこのようなプロセス化・仕組み化・大局的な作り方について考えて効率化していくことが重要であることは自明だ。 とはいえ、第一線で戦う経験が薄いと、作り方で解決しようとする痛み事態を知らないことになり、正しい課題感を持てなかったり、解決策の方に潜んでいる隠れコストを把握できなかったりすることもあるでしょう。 そのため、一定「作ること」をすることによって「作り方を作る」こともできるようになるんだろうな。その塩梅が難しいが、それは何事についても言える。

また、より未来に目線を揃えると、AI がガイドラインや方針の改善を自立的に推薦するようになってくると、次は本当にそれらの「作り方を作る」行為のレビューをしたり、制御したりするので本当に「作り方を作る作り方」みたいなより上位でありメタな開発行為になっていくのかね、、 人間はどこまでの抽象度に耐えられるのだろうか。具体を知らないまま抽象度だけ上がっていってたら、徐々に夢や魔法の世界に向かっていく。 もちろんいままでも抽象度を上げてきた。0101 からアセンブリから高級言語までとか。今回も同じようなたたの１ステップなのか、もっと性質が違うものなのか、違う気がする、、また別の機会に考察しよう。

Today, I created a tmux plugin to list all claude sessions, and jump to their respective tmux windows.

I use tmux extensively with many sessions and windows existing at the same time. Also, I use claude code a lot resulting in many claude code session dispersed across many tmux sessions / windows. As a result, I often had a hard time tracking which claude code session is still running, what is done and what requires additional input.

Futhermore, I have it setup such that I get notified with a sound when claude code has completed or requires permissions. But when I run multiple claude code sessions, I had a hard time figuring out where to go, which caused some friction in my development process.

My tailored solution was to create a plugin that utilizes tmux-fzf, a tmux plugin that can have a floating pane where you can fuzzy find, and list all running claude code sessions & their respective states (completed, waiting, running) shown. Also, it allows me to attach to that specific tmux window that runs it. Not with one stroke I open this pane, can confirm the total state, and then jump directly to wherever I need to be.

Shared it with some coworkers and they seem to enjoy it too!

Recently I think about this phrase from Earl Nightingale a lot. "We become what we think about". This implies that our thoughts shape what we become.

If you think about failure every day, you're likely to fail. If you think about becoming a great engineer every day, you move in that direction. If you do NOT think about that every day, it won't gonna happen miraculously.

It makes sense to me. If you think about something everyday, you will have many opportunities to think about it, and that gives you many chances to take smaller steps directed towards it. In contrast when something is out of your mind, you'll most likely forget about it and when you remember it, months and years will have past. If just that thing was in your center of focus, you'd have lived such as different life.

It shows how important it is to control and direct your thoughts, especially the core parts. Any great goal, is not achieved in a day. It is the accumulation of what you do on a daily. So governing the daily you, is what enables you to steer yourself conciously.

One way you can do that is to do with journaling and reflection on the daily. More is not always better, if you have 10 things you want to be, that dillutes and often nothing remains. For me, pick only one thing and focus on that. And only once that is fully incoroporated into your focus, should you move on to incoroporate other things.

We become what we think about, so think about what you want to become.

DDD において腐敗防止層という大層な名前のものがある。 すごく重要であり、だからこそ大層な名前をつけているのだと思った。

実質変換行う "だけ" の外部と内部の間を取り持つ一種の「層」である。 内部とは DDD に基づいて実装している自分らのドメインモデルのことである。 外部とは連携しているレガシーシステムや他社の API などである。 これらの外部の都合につられて、ドメインモデルで同じような表現をしていたら、元も子もない。 外部の都合ではなく、ドメインモデルとしてどうあるべきに基づいてモデリングし、実装したい。 それを実現するには独立性が必要である。独立性を実現するには、内部と外部の間をよしなにしてくれるものが必要で、それが「腐敗防止層」に相当する。

腐敗防止層の話をすると Adapter, Facade, Translator が出てくる。これらはなんぞや？

これらが解決する問題を見よう。外部の都合に引きづられると困る問題として以下がある。

この問題を解消するのが以下

また、外部では REST API であったり SOAP API であったり XML を返したり JSON を返したりで、それらの都合もどこかで吸収したい。

でその問題を解消するのが Adapter。

これらを組み合わせて以下のような「腐敗防止層」が構成できる。（文字がちょい小さいが、、）

ドメインの表現と外部の表現の間に「腐敗防止層」があり、それが更に３つのサブ層からなっている。 Adapter でファイル形式やプロトコルの違いを吸収し、Facade でインターフェース・APIの粒度の違いを吸収し、Translator でフィールドの型・値・命名・構造などを変換して、ついに我々がドメイン表現に至る。

個人的には Facade のところが一番面白く学びが多いところであった。 Adapter と Translator の方が行っている処理については、まあ必要だろうなと思っていたが、Facade であー自分らの都合に合わせてインターフェースの粒度を調整するのか！という点は面白かった。 あとは純粋に Facade というワードチョイスがイケている。

これで ACL の初歩は掴めたのではないだろうか。

大きめの機能を開発するとき、もしくは CLEAN アーキテクチャを採用していて１つの機能開発が複数のレイヤーのサブチケットに分割されているときに、複数の Claude Code セッションで実装することになる。 このとき、そのセッション達が重要な情報を共有するための有効な手段がデフォルトではない。 Claude には Auto-memory という機能があり、プロジェクトレベルで重要なことを自動で記憶してくれる機能もあるが、機能レベルだと基本的にはない。 そこでその機能にまつわる重要な決まりごとを毎回説明するのも億劫であったり、他の方と分担して実装する場合もその決まりごとが正しく共有されていなかったりの問題が発生する。

このような問題の対処法として Feature Document という選択肢を知った。 Feature Document は機能の実装期間だけ生存するドキュメントである。 機能の重要な決まりごとを記載し、各セッションで読み込めんで共有し、実装中の追加決定事項があれば、その場で更新もできる。

具体的には、レポジトリのどこかに配置して git にチェックインしてもいいが、自分はまずは試験的に使うために以下の設定を使った。

When doing any kind of feature implementation, look at `~/feature_documents/` to see if there are any relevant feature documents.
If available, read that document and follow its instructions.
Also, if new decisions have been made about the feature or how to implement it that are specific to that feature, then update the document.
 
File format is `<date>-<content>` e.g. `2026-03-18-add-fuzzy-search`

本来はプロジェクト特化の情報のため、プロジェクト付近におくのが好ましいが、まずは試験的に導入ということでこのようにした。 個人の Claude 権限 ~/.claude/settings.json においてこのロケーションの読み書き権限を追記し、権限許可を聞かれないようにもした。

これで、わりとうまい具合に、同一の機能開発に属するセッション間で情報・コンテキストを共有できるようになった。 使用していって、また知見があれば記載する。

ソース）martinFowler.com - Context Anchoring