| title | 技術選定はツール比較ではなく破綻単位で考えるのがいいんじゃないかなって | |
|---|---|---|
| emoji | 🔧 | |
| type | idea | |
| topics |
|
|
| published | true |
- パッケージマネージャーの選定論争？を見た
- いつかひっくり返るかもしれないメリデメでツールの優位性を語るのは意味がないんじゃないかと思った
- 前提条件が違う中で、優位性（メリット）を根拠に選定を促すのはフェアじゃないなって
- 個人で使うツール（パッケージマネージャー）の選定くらい自分でやれ（やりたい。やらせてください。自分まだやれますｗ）
- チームで使うツールの選定はメンバーの合意が取れれば好きにすればいいと思うけど、そもそも優先するべきことは何か、本当にソレが必要か、最適かは充分に議論したほうがいい
- 組織で押し付けるのはやめておけ。各チームの自主性と組織としての多様性を信じてむしろ全部異なる選定を推奨してもいいくらい。もちろん他と足並みを揃えるという選択も咎めない
- 個人的にはいつでも「こんなこともあろうかと」を実践できるように、情報収集や試してみることをサボらずに、自分の言葉で良し悪しや理由を説明できるようにしておくのが一番いいと思うんだぜ、という記事が書きたかった
:::details AIにしれっと記事っぽくしてもらった
## なぜ議論が噛み合わないのか
多くの記事は、暗黙のうちに次の前提を置いている。
- 利用者は全員同じ立場である
- 選定すべきツールは一つである
- 長期的な継続リスクは考慮しなくてよい
だが実際には、技術選定の答えは立場によって変わる。
技術的に「優れているかどうか」と、それを「採用し続けられるかどうか」は、別の問題だ。
## 技術選定はスコープで答えが変わる
### 個人開発の場合
個人開発では、最適化対象は自分自身だ。
- 学習コスト
- 使い慣れ
- 好み
これらを優先してよい。
Homebrew でも nix でも MacPorts でも、本人が快適ならそれが正解になる。
### チーム開発の場合
チームでは話が変わる。
- オンボーディング
- 環境差分
- 作業の再現性
これらを考えると、チーム内での統一は合理的だ。
ただし、それはあくまで「チーム単位」で閉じている必要がある。
### 組織の場合
組織全体で見ると、さらに視点が変わる。
- ツールの信用失墜（コミュニティ、セキュリティその他）
- 開発停止
- 方針転換
- 採用・教育コストの爆発
単一のツールに全振りするということは、そのツールが破綻したときの影響範囲を最大化するということでもある。
現在の普及率や勢いが、将来の安全性を保証するわけではない。
## 単一ツール全振りはリスク集中である
「これが一番優れているから統一する」という判断は、一見合理的に見える。
しかしそれは、時間軸のリスクを見落としている。
技術選定において重要なのは、
- どこで壊れるか
- 壊れたとき、どこまで影響するか
という点だ。
これはツールの優劣の話ではなく、破綻単位の設計の話である。
## 多様性は無秩序ではない
「複数のツールを許容する」と言うと、無秩序に聞こえるかもしれない。
だが実際には、統一すべきものと、しなくてよいものは分けられる。
- 成果物の形式
- CI での再現性
- デプロイ手順
これらは統一すべきだ。
一方で、
- ローカル環境の構築方法
- パッケージマネージャ
- 開発ツールの管理方法
は、ある程度の自由度を残した方が、組織としての耐性は高くなる。:::
- 他人に振り回されるのはおやめなさい
- 現時点のメリデメや優位性を根拠に他と比べるのはおやめなさい
- 自分（たち）で決めなさい
- 決めたならADRを書いておきなさい
- どうしても必要になるまでは戦略的後回しにすることを視野にいれなさい
- どれを選んだとしても、将来にわたって変更してはいけないということではないと知りなさい
- 10年後はまったく別のものが幅を利かせているかもしれないよ
なんてことを思ったので残しておくことにしたというわけ。