技術選定は技術的正しさだけでは伝わらない
「この技術の方が優れているから使う」という理由は、PMには伝わりにくい。
PMが判断軸にするのは技術的な優劣ではなく、スケジュール・コスト・リスク・保守性への影響だ。同じ選定理由でも、PMの言葉に変換すると意思決定がスムーズになる。
判断軸1：目的適合
「この要件を実現するためにAを選んだ」を説明する。性能が必要なのか、柔軟性が必要なのか、将来の変更に対応できる必要があるのかを、システムの目的に紐付けて話す。
「高トラフィックへの対応が必要なため、処理速度の観点からAを選定しています。」
判断軸2：保守性
長期間運用したときのメンテナンスのしやすさを伝える。ドキュメントの充実度・コミュニティの活発さ・アップデートのしやすさなどが保守性の要素になる。
「Aは活発にメンテナンスされており、2〜3年後も保守しやすい環境を維持できます。Bは現在メンテナンスが低調で、長期運用リスクがあります。」
判断軸3：チーム習熟度
チームの現在のスキルセットを考慮した選定理由を説明する。「誰も触ったことがない技術」と「チームが経験済みの技術」では、立ち上がり工数やリスクが変わる。
「Aは現チームが経験済みで、立ち上がり工数が最小化できます。Bを採用する場合は学習コストとして2週間の追加工数が必要です。」
判断軸4：コストとリスク
ライセンス費用・インフラコスト・移行コスト、および採用時のリスク（実績の少なさ・互換性など）を整理して伝える。
「Aはオープンソースでライセンスコストがかかりません。Bは月額3万円のライセンスコストが発生します。」
PMへの説明テンプレート
技術選定：○○に○○（技術名）を採用することを提案します。
目的適合：このシステムに必要なXXの要件を満たすため
保守性：長期運用に向けてコミュニティとドキュメントが充実しており保守しやすい
習熟度：チームが既に経験しており立ち上がりコストが最小化できる
コスト：ライセンス費用なし、インフラコストは約5,000円/月（AWS t3.small想定）
代替案（B）との比較：
・Bはサポート体制とSLAの点で優れているが、チーム学習コストとして+2週間が必要
・長期サポートの観点ではAの方がリスクが低い
判断のお願い：来週の設計レビューまでに合意いただけますか？選定理由の記録も残す
口頭で説明するだけでなく、選定理由を設計書や議事録に残しておくと、後から「なぜこれを選んだのか」という質問にすぐ答えられる。