MEGUMI SHIMABUKURO

技術選定、ライブラリ選定の妥当性についてあらためて考えることがあったので備忘録メモ書きです。

考えたことを書き殴ったものからGPTに記事生成させてます。

「この選定って妥当なんですか？」

技術レビューや設計議論の場で、そんな質問に詰まってしまった経験はありませんか？

ライブラリ、アーキテクチャ、インフラ構成、方式設計──技術選定の現場は日常的にありますが、「なぜその選択をしたのか」を自信を持って説明するのは意外と難しいものです。

本記事では、技術選定における「妥当性」の本質と、誰でも再現可能な判断アプローチを解説します。MECEの考え方も取り入れながら、汎用的な判断軸として使える内容に仕上げました。

一言でまとめるなら、

「なぜその選択肢を選んだのか」を自分の言葉で説明できること

が妥当性です。

• 他にどういう選択肢があったのか？
• その中でなぜ今それを選んだのか？
• どんな利点とトレードオフがあるのか？

これを整理・説明できていれば、少なくとも“なんとなく”の選定ではなく、“意図ある選定”になります。

やりたいことに対してどんな選択肢があり、その選択肢にはどんなメリットとデメリットがあり、その選択肢からどんな理由で選んだのかを説明できることが妥当性

• 「広く使われてるライブラリだから」
• 「有名なライブラリだったから」
• 「過去のプロジェクトでも使ったし」
• 「みんな使ってるから大丈夫そう」

こうした“他人依存”や“前例踏襲”だけの理由では、プロジェクトごとの目的・制約に対しての適合性が説明できません。

• 何を実現したいのか？
• それに対して過剰・過小ではないか？

Mutually Exclusive（相互に重複せず）

Collectively Exhaustive（漏れなく）

選択肢を網羅的かつ重複なく挙げるための考え方です。

たとえば「型安全な結果型を導入したい」という課題に対して：

• 自作する
• 軽量なミニマム実装を使う（例：small-result）
• フル機能のライブラリを使う（例：neverthrow）

のように、「やりたいことの粒度」や「外部依存の有無」で軸を切って選択肢を分類することで、思考の抜け漏れが減ります。

→ 判断の透明性と納得感が高まる

• 学習コスト、認知負荷
• メンテナンスの頻度・難度
• 依存の増加によるリスク

• OSSであればソースコード、メンテナンスされてるか
• アーキテクチャであれば構成図とデータフロー
• クラウド構成であればサービス仕様や制限事項

妥当性の説明で最も重要なのが「トレードオフの認識」です。

何かを選ぶということは、何かを捨てるということ。

• 導入が早い = 学習コストが高いかもしれない
• 柔軟性が高い = 実装が複雑になる
• フル機能 = 過剰な依存・将来的なロックイン
• 自作 = 保守責任を自分たちで負う

つまり、「なぜそれを選んだか」だけでなく、「どのデメリットを許容したか」まで語れることが、真の意味での“妥当性のある選定”です。

• 「neverthrowは便利だが捨てやすさが低くなるので、本当に必要な機能だけを使う方針にする」
• 「OSS Aは機能が豊富でメンテされてるが、認知コストが高い。今のチーム状況では軽量なBを選ぶ」

Pros / Cons を比較してみたものの…

「どれも悪くないし、決め手がないな…」

そんなときに有効なアプローチも紹介します。

• 要件追加・仕様変更・チームの変化などを想定し、「後から変えにくいもの／変えやすいもの」で比較する
• 柔軟性・拡張性のある構成を優先する

• 試しに入れてみて問題があれば後から差し替えられる方（Lock-inが弱いもの）
• 初期コストが低く、フェイルファストできる構成

• 明確な“判断基準”を一つ決めて優先度をつける（例：学習コスト・チーム全体の習熟度・導入速度）
• 「このプロジェクトでは“運用のラクさ”を最優先する」など方針を明確にする

• 技術的に五分五分なら、チーム全体で議論し、合意形成できたものを選ぶ
• 理解・共通認識が取りやすいものは、トラブル対応や運用フェーズで強い

• 本格導入前にPoC（試験導入）やスパイクで触ってみる
• 実際に触って得た感触で「合う／合わない」が見えてくることも多い

# 技術選定の妥当性チェックリスト

## 目的整理
- [ ] 解決したい課題が明確か？
- [ ] その課題が技術的選定で解決できるものか？

## 選択肢の洗い出し（MECE）
- [ ] 自作・OSS利用・既存資産活用など、構成がMECEか？
- [ ] 網羅的に比較した上での選定か？

## 判断理由の整理
- [ ] Pros / Cons が明確になっているか？
- [ ] トレードオフ（何を捨て、何を得たか）を説明できるか？
- [ ] 学習コスト・運用コストを把握しているか？
- [ ] 導入による長期的な影響を評価しているか？

## 実装・信頼性の確認
- [ ] 中身（コード・構成・仕様）を理解しているか？
- [ ] メンテナンスされていることを確認したか？
- [ ] 他人が読んでも納得できる資料になっているか？

## どうしても差がつかない場合、下記の視点で補助判断したか
- [ ] 将来の変化への強さ
- [ ] 捨てやすさ（Lock-inの低さ）
- [ ] 判断軸の明確化
- [ ] チームの納得感

良い選定は、良い答えより良い問いから始まります。

• 他に手はないか？
• それは将来も耐えられるか？
• チームが使い続けられる設計か？

この問いを自分に、そしてチームに投げかけ続けることで、

「自信を持って説明できる選定」ができるようになっていきます。

## 技術選定名：〇〇の導入について

### 目的・課題
- なぜこの技術選定が必要なのか？
- 現状の問題 or 解決したいこと

### 選択肢と比較
- A案（自作）
  - Pros: ...
  - Cons: ...
- B案（OSS）
  - Pros: ...
  - Cons: ...
- C案（既存の◯◯を流用）

### 結論
- なぜ今回これを選んだのか？
- 懸念点とその対策