ツールとの付き合い方 (ベターな技術選定)

ツールとの付き合い方 (ベターな技術選定)

はじめに

今日は創立記念日！っということでIdeaというかエモめの話にしよう。

人類で初めての問題を自分で解く！っというケースはなく、すでに人類が体験してた問題を今自分が体験してるケースが多い思う。

完全一致はしてはいないけど、真似て少しカスタマイズして使うことが多いです。

すでに世の中にはたくさんのツール/技術であふれている。技術選定はとっても難しい。技術選定といっても、技術の粒度は、インフラ、アーキテクチャ、ツール、ソースパス設計...はさまざまです。

うまく選定できないと、機能の追加/変更が大変だったり、技術に合わせて仕様をおとすみたいなことが起きがちです。

最近だと、こんな話がちょくちょく聞いたりします。あとは、ベストプラクティスや流行りをいれてみたけど、うまくいかなかったとか。

Atomic　Designでディレクトリ構造したんだけど、Atomc　Designの種類にわけるの難しいし、Molecules(分子)、Organisms(生体)がふくらんじゃっています！

この日進月歩な世の中でベストであり続けるのは大変だけど、少なくともベターな選択をしたいです。

どうやって僕が日頃技術選定をしているのか、言語化してみました。

前提知識

ツールって何？っという話をします。以下の問いに答えられるでしょうか？

トンカチはどうしてあの形になっているのだろう？

これを説明のするための考えとして2つ説明します。

• シーソーに乗せ比較せよ
• トンカチをみるな、釘をみよ

シーソーに乗せ比較せよ

何か比較するには、 観点|単位 を揃えないと比較できない。

• 30cm定規と1リットルの水はどっちが重い？ A.わからん
• 30cm定規の重さ100gと1リットル水1kgどっちが重い？ A.水です

  観点|単位 を決めて比較すると、それ以外ことは関係ないっということです。

重さで比較するのに定規、鉄など素材も関係ないし、大きさも関係ない。何gかだけが重要である。

観点|単位 を選ぶことは、つまり、モノのある一側面/断面の構造を表したものであり、その他は省略したものである

モノ|コト　を 観点|単位 のナイフで切った断面図になる。

すべてを表す 観点|単位 はなく、複数の 観点|単位 のナイフできった断面をあつめて全体を理解しようします。

人間のジェンダーのナイフ、体重のナイフ、性格のナイフ、年収のナイフ、職業のナイフ、たくさんナイフで断面図をつくり、人間というものを理解していく。

ここで次の疑問が、無数にある 観点|単位 ナイフの選び方はどうしたらよい？

トンカチをみるな、釘をみよ

まずは最初の質問にもどる

トンカチはどうしてあの形になっているのだろう？

トンカチを見ている限り、その答えにたどり着かないのです。

柄の部分は長くて、先端は金属で、振りやすいです！

え、それじゃドライバーじゃだめなの？そもそもなんで、そうじゃなくちゃだめなの？

トンカチをどんなどんな 観点|単位 ナイフで断面図（スペック）をみても答えはでこないです。

そう僕らが知るべきは、トンカチが解決したかった問題を分析しない限り、答えがでないのです。

釘を打ちたいから、トンカチを選びますよね？いきなり突然今日はトンカチでも振り回してやろうか、がははってトンカチで一つで日曜大工しようと思いませんよね？釘をみたからトンカチを選んだのです。

釘は、細長く打撃を耐えることで奥に入っていきます。叩く動作が必要ですね。

釘を打つには、釘より硬く、打撃をあたえられ、大きい力が必要なわけです。トンカチの形は釘より硬く、打撃をあたえられ、大きい力を与えやすい形になっている適している。

ドライバーでも解決できなくはありません。柄の部分で、「えい」って頑張って叩けばできるでしょう。ただし、センスある技術選択にはならないでしょう。なぜならドライバーはネジを回すのにとっかしていて、たまたまドライバーが硬かっただけにすぎません。

どうして、ツール（トンカチ）の形がその形になっているか、それは問題(釘)の形にあっているからなのです。

そして間違った技術選定してしまったときはたまたま一部同じ特性があったからたまたま使えちゃったパターンであとから辛くなる。

自分なりの解

Atomic　Designでディレクトリ構造したんだけど、Atomc　Designの種類にわけるの難しいし、Molecules(分子)、Organisms(生体)がふくらんじゃっています！

これはその通りで、Atomic　Designは観点|単位 ナイフの話であり、あなたの問題の構造ではないからです。Atomic　Designは悪くなく、どのくらい粒度でコンポーネントに切り出すのかヒントとしてすごく役に立っていると思う。

もうちょっと極端な例をだすと

人間の性別は男か女にわけることできる。なるほど、人事システムも性別でやれば抜け漏れなく全社員分類できる！

きっと運用者が使いにくいシステムになるでしょう。部署ごとに管理しかったり、ロールごとに管理したかったりする。 性別のナイフが問題の構造にマッチしていない。性別はある世界の断面図にすぎない。きれいに分類できること自体に意味がない。分類して何がうれしいのか。

まずやるべき、ドメイン|問題理解なのだ。ここの理解の解像度が自分の技術的なレベル限界と同義といっていい。

ブレストでもよくあるグルーピングも同様で似てるモノを集めたくなる病でそのグルーピングに何も意味がなかったりする。グルーピング時間かけるなら、優先順位順にならべここの問題に集中すればいいと思う時がある。

まとめ

最近フロントエンドばかり触っている（React）。現在のフロントエンドはカオスで、Rust性のツールが乱立していたり、新しいフレームワークも乱立、CSS関係も乱立、ESM周りでなにか影響もでてきそう。

何を選択しても二年後に古いといわれるプロジェクトになる。たとえ勝ち馬を選択したとしても、メジャーアップデートで大幅変更は一度はくらいそうだ。

ベストは難しい。プロジェクメンバーのスキルも影響するし、採用しやすいように流行りを選択したいという大人な事情もわかる。

でもベターは選択したい、問題解決や提供したい価値を達成しやすいツールは選定できる。古い|流行りじゃないはまだ許容範囲。

• なぜそのツールが生まれたのか
• 作者が解きたかった問題と自分が解きたい問題は同じか
• スペック表|HowToばかりみていないか
• ドライバーで釘を打つようなことしていないか

もちろん問題解決を考えるだけではなく、 プロ のエンジニアとして、毎日寿司屋が包丁をとぐように、手を動かして、ツールを手に馴染めておくことは欠かさずに。個人プロダクトでもなんでもいいから素振りをしておこう。いざ魚を目の前にしたとき、包丁を選択できたとしても、日頃使っていないと満足に捌けないでしょう。

ツールを通して問題みるか、問題を通してツールをみてるか、どうやって技術選定してるでしょうか。