技術選定基準と判断軸の作り方
まず「解くべき問題」を5行で固定する：ビジネス目標と非機能の芯
技術選定は手段であり、目的はビジネスの結果です。最初に結論の型を固定すると、流行の情報に流されにくくなります。おすすめは「5行メモ」。
5行メモの雛形
- 誰の：主要ユーザーと関係者（現場/経営/運用）
- 何を：達成したい業務成果（例：在庫差異を半減）
- いつまでに：マイルストンと依存関係（検収/並行運用）
- どれだけ：指標と閾値（例：日次5万件、P95＝800ms以内）
- 何は譲れない：非機能の必須条件（例：個人情報は国内保存）
非機能要件は曖昧にしないほど、選択肢が絞れます。次の8項目を最初に数値化しておくと、後工程が滑らかです。
非機能テンプレ（最小8項目）
- 可用性：稼働率、RTO/RPO、メンテナンス窓
- 性能：スループット/レイテンシ、バースト時の上限
- セキュリティ：認証方式、暗号化、ログの保持と改ざん耐性
- 運用：監視、アラート、バックアップ、障害対応体制
- 可観測性：メトリクス/トレース/ログの整合
- 拡張性：テナント追加/新機能の影響範囲
- 保守性：コード規約、依存関係更新のしやすさ
- 法規/データ所在地：業法準拠、データ持ち出し制約
判断軸は「スコア×可逆性×実証」で作る
選定は主観でなく、スコアと実証で進めます。以下は汎用の判断軸と測り方です。各項目1〜5点で採点し、重みを合意します（例：非機能適合×3、コスト×2、学習コスト×1）。
代表的な判断軸と測り方
- 非機能適合度：必須条件を満たす割合（必須を1つでも満たせなければ0点）
- TCO：3年総コストの見積幅（±%のブレが小さいほど高得点）
- 開発速度：プロトタイプでの実装所要時間（同一要件のスパイクで比較）
- 学習/採用コスト：参画1名が戦力化するまでの時間と採用市場の厚み
- 運用難易度：アラートからMTTRまでの平均手順数と自動化可能性
- ロックイン耐性：代替手段の可用性と移行手順の明確さ
- 実績/成熟度：同規模・同要件での公開事例数と既知の制約
さらに「可逆/不可逆」をラベル付けします。データモデルやID体系、ユーザー移行計画、長期契約は不可逆になりやすいので、特に厳しく評価します。不可逆な決定は意思決定記録（ADR）を1枚残し、撤退条件（Kill Criteria）を明記します。例：「1週間の負荷テストでP95が800msを超過し続ける場合は選定を撤回」。
最後に実証です。2週間の評価スプリントで、同一要件のスパイクを2〜3候補で並走させます。テストデータは本番相当を用意し、計測スクリプトとセットで再現可能にします。リードタイム、エラー率、アラートの誤検知、運用手順化のしやすさを数字で並べると、議論の温度が下がります。
受託開発に最適化する進め方：提案〜検収を見据えた6ステップ
- 制約の棚卸し：検収基準、運用体制、SLA、監査要件、既存資産の残置条件を先に確定。
- 選択肢プール：同カテゴリで少なくとも3案。メインストリーム、ニッチ高性能、保守安定の三極を用意。
- 評価スプリント：2週間でスパイク。テスト計画、ダッシュボード、失敗時の撤退条件を事前合意。
- リスク会計化：技術/人材/運用/法規のリスクを金額化。回避・低減・受容・転嫁を分類。
- 最小構成SLAの定義：まず守るラインを数値で決め、段階的拡張をロードマップ化。
- 提案への落とし込み：判断軸、スコア、実測、ADR、Exit計画（移行や分解可能性）を1セットで提示。
調査や検証の生産性を上げるには、生成AIを活用します。要件整理の素案づくりや比較観点の洗い出しはChatGPTやClaude、API設計やコード雛形のスパイクはCopilot、仕様差分の要約や制約の洗い出しはGeminiが役立ちます。いずれも最終判断は実測とレビューで裏取りし、生成物は必ずリポジトリに記録します。
身近な企業の失敗→改善ケース：中堅スーパーの会員アプリ刷新
地方で20店舗を展開する中堅スーパーの会員アプリ刷新を支援した際、当初はトレンド技術を優先した結果、運用が破綻しかけました。要件は「クーポン配信と来店スタンプ、P95＝800ms、閉店後30分の夜間バッチ、個人情報は国内保存」。選定では最新のリアクティブ構成と新興データベースを採用。開発速度は上がったものの、運用担当が確保できず、夜間障害時の復旧手順が複雑化。さらに採用市場が薄く、増員できない問題が露呈しました。
3週間で立て直し。判断軸を再定義し、不可逆要素（会員ID体系、ポイント台帳、データ所在地）を切り分け。スパイクをやり直し、以下に変更しました。
- 台帳系は実績のあるマネージドRDB＋国内リージョン固定に
- 配信/通知はキューイングでバースト吸収、障害時の手動代替手順を標準化
- フロントは現行チームが保守可能なフレームワークに寄せ、ビルドと監視を簡素化
- ADRと撤退条件を明文化（P95超過継続・夜間復旧30分超過で再選定）
結果、MTTRは平均18分に短縮、夜間当番の属人化が解消、採用リードタイムも半減。検収時はスコア表と実測の添付により合意がスムーズになりました。教訓は「非機能と運用人材の現実を、選定初日に数字に落とす」こと。流行の良さは取り入れつつ、不可逆部分は地味でも堅実に、が効きます。
すぐ使えるチェックリスト（抜粋）
- 必須非機能に閾値を設定しているか（○/×、根拠URL/実測あり）
- 候補は3案以上か、極端な選択肢を1つ含めたか
- 可逆/不可逆の分類とADR、撤退条件があるか
- 3年TCOの幅と前提、為替/トラフィック感度の試算があるか
- 運用手順を新人が90分で再現できるか（手順書＋演習）
- 障害シナリオ3件のドライランを実施したか（結果を記録）
- 人材調達プランと育成期間が見積に反映されているか
技術選定は一度きりの正解探しではなく、可逆性と実測で進める継続的なマネジメントです。受託開発ソリューション事業では、提案前の短期スパイク、判断軸の透明性、ADRと撤退条件の明文化が、納期・品質・運用のバランスを保つ土台になります。選定基準そのものをプロジェクト資産として蓄積し、次の案件で再利用できる形にしておくと、組織の開発速度は着実に上がります。
