技術選定の進め方5ステップ｜評価軸の作り方と提案を通す型

技術選定とは｜「何を選ぶか」より「何を捨てるか」

技術選定とは、要件と制約を前提に、候補技術の採用理由・却下理由・見直し条件までを決める意思決定プロセスです。比較して優劣をつけること自体が目的ではありません。限られた制約の中で、何を諦めるかを合意する作業だと捉えると、進め方が定まります。

どの技術にも弱点があります。学習コストが低いものは細かい制御が効かない。パフォーマンスが出るものは書ける人が少ない。このトレードオフを誰かが引き受けなければ、決定は前に進みません。

技術選定が紛糾するとき、原因はたいてい「何を優先するか」の合意がないことにあります。速度を優先したい人と、保守性を優先したい人が、同じ土俵で別の話をしている。評価軸を先に決めるのは、この土俵を揃えるためです。

技術選定で決めるもの・決めないもの

線引きを曖昧にすると、技術選定の会議が設計レビューになり、結論が出ないまま時間だけ溶けます。設計の粒度そのものについては基本設計書の書き方｜項目一覧・粒度の判断基準と詳細設計書との違いを参照してください。

フリーランスが技術選定に関わる3つの場面

1. 新規開発の立ち上げ：ゼロから構成を決める。裁量は大きいが、責任も大きい

2. 既存システムへの部分導入：新機能や置き換え対象の一部だけ選ぶ。既存との整合が主論点になる

3. 既存選定への意見：すでに決まっている構成に対して、参画者として懸念を伝える立場

3つめを軽視しないでください。参画直後のフリーランスが最初に呼ばれるのは、多くの場合この場面です。

技術選定の進め方5ステップ

進め方は5つのステップに分けられます。順番を入れ替えると、ほぼ必ず後戻りが発生します。

ステップ1：制約条件を先に言語化する

最初にやるのは候補探しではなく、動かせない条件の洗い出しです。

• 納期と、使える工数（ここが一番効きます）

• チームの現有スキルと人数、採用予定の有無

• 既存システムとの接続要件、認証・データ連携の前提

• 予算（ライセンス費用・クラウド費用・研修費）

• 顧客・業界固有の制約（オンプレ必須、持ち込み機材の制限など）

セキュリティ要件は見落とされやすい制約です。客先常駐や公共系では、使えるサービスそのものが限定されます。詳しくは客先セキュリティ要件対応｜ISMS・Pマーク・持ち込みPCの実務にまとめています。

小〜中規模の案件で、主要関係者の前提がすでに揃っている場合なら、制約の洗い出し自体は30分〜1時間程度でたたき台を作れることが多いです。それをやらずに候補比較から入ると、数日かけた比較が「その構成は予算的に無理」の一言で消えます。

ステップ2：候補は3〜4つに絞って並べる

候補は最低3つ用意します。1つだけだと比較になりませんし、2つだと二者択一の対立構造になりやすい。逆に5つ以上並べると、検証しきれずに「なんとなく有名なもの」に落ち着きます。

候補を出すときのコツは、性質の違うものを混ぜることです。

• 本命（要件に素直に合いそうなもの）

• 保守的な選択肢（チームが既に使っているもの・枯れているもの）

• 攻めた選択肢（要件に対して強いが、学習コストや実績に不安があるもの）

3つめを入れておくと、比較表に幅が出ます。仮に採用しなくても、「検討したうえで見送った」という事実が後の説明で効きます。

ステップ3：評価軸を決めて重みをつける

候補が出そろったら、比較を始める前に評価軸を決めます。ここが技術選定の中核なので、次章で詳しく扱います。

重要なのは順序です。候補を触ってから評価軸を作ると、無意識に「本命が有利になる軸」を選んでしまいます。軸と重みを先に紙に書き、できればチーム内で合意を取っておく。

ステップ4：小さく検証して事実を集める

ドキュメントを読むだけでわかる軸と、触らないとわからない軸があります。後者は短い検証で埋めます。

検証のスコープは絞ってください。初期比較段階の小〜中規模案件であれば、1候補あたり半日〜2日、全体で3〜5営業日以内を目安にすると、選定プロセス自体が長引きにくくなります。対象がライブラリ単体か基盤全体かで必要な工数は大きく変わるため、あくまで初期比較の目安として扱ってください。検証で見るのは「作れるか」ではなく、詰まりやすい箇所で実際に詰まるかです。

• 既存の認証基盤と繋がるか

• 想定データ量でレスポンスが許容範囲か

• エラー時の挙動とログが追えるか

• ローカル環境の構築に何時間かかるか

4つめは軽く見られがちですが、新規メンバーの立ち上がり速度に直結します。

なお、検証フェーズ自体が案件として切り出されるケースもあります。その場合の契約の握り方はAI PoC案件の単価相場と探し方｜契約の握り方と本開発への繋ぎ方が参考になります。

ステップ5：決定と却下理由を記録する

決めたら記録します。採用理由だけでなく、却下した候補とその理由をセットで残すのがポイントです。

記録がないと、半年後に「なぜこれを使っているのか」が誰にもわからなくなります。そして新しく入った人が、すでに検討済みの候補を再提案する。この往復は、記録があれば起きません。記録の形式はADRが扱いやすく、後半の章で書き方を示します。

ミニFAQ：5ステップ全体で、どのくらいの期間を見ればいい？

規模で変わりますが、筆者が関わった範囲では、中規模の新規開発でフレームワークや基盤を選ぶ場合、制約の整理から記録までを1〜2週間程度に収める進め方が現実的でした。検証を含めてもこれ以上長引くと開発着手が遅れ、選定そのものの価値が下がります。部分導入や小さなライブラリ選定なら、数時間〜2日程度で一巡させることもあります。

ミニFAQ：候補を3つ出せないほど選択肢が少ない領域では？

候補が実質1つでも、ステップは省略しないでください。「他に何がありうるか」「それを採らない理由は何か」を書き残すだけで、記録としての価値は生まれます。選択肢が少ないこと自体がリスク（ベンダーロックイン、採用難）なので、その旨も併記します。

評価軸の作り方｜汎用軸とプロジェクト固有軸の組み立て

評価軸は「汎用軸をベースに、プロジェクト固有軸を足す」という二層構造で作ると、毎回ゼロから考えずに済みます。

ベースにする汎用評価軸

多くの技術選定で共通して使える軸は、次の7つに整理できます。

7軸すべてを毎回使う必要はありません。プロジェクトの性質に応じて、使う軸を5つ前後に絞るほうが議論は締まります。

非機能要件から固有軸を足す

汎用軸だけでは、そのプロジェクト固有の論点が抜けます。ここで役立つのが、IPAが公開している非機能要求グレードです。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6カテゴリで非機能要件を整理する枠組みで、評価軸の抜け漏れチェックリストとして使えます。

クラウド前提の構成であれば、AWS Well-Architected Framework や Azure Well-Architected Frameworkの5つの柱 も同じ用途で使えます。どれかひとつを眺めて「うちの案件で効く軸はどれか」を拾う、という使い方で十分です。

重み付けとスコアリングの実務

軸が決まったら重みをつけます。全部が同じ重要度ということはありません。

実務では、重みは3段階（必須・重視・参考）くらいの粗さが扱いやすいです。5段階や10点満点の加重平均にすると、点数の調整で結論を操作できてしまい、議論が「点の付け方」に流れます。

• 必須：満たさない候補はその時点で脱落（足切り）

• 重視：優劣の比較対象。ここで差がつく

• 参考：僅差のときの決め手。それ以外では触れない

足切り軸を先に適用すると、比較対象が減って議論が速くなります。

「調べればわかる軸」と「触らないとわからない軸」を分ける

評価軸を作ったら、各軸に「机上で埋まるか」「検証が要るか」のラベルを付けてください。この仕分けをすると、ステップ4の検証スコープが自動的に決まります。

要件適合性やライセンスは机上で埋まります。一方、学習コストや運用負荷の実感は、半日触ってみないと数字になりません。

候補の健全性を客観指標で確かめる

「情報が多い」「よく使われている」という印象論は、比較表に書くと弱い根拠になります。できるだけ観測できる指標に置き換えてください。

OSSの保守状況を見る

公開リポジトリで確認できるのは、直近のコミット頻度、未解決Issueの滞留期間、リリース間隔、メンテナの人数です。単独メンテナのプロジェクトは、その人が離れた時点で更新が止まります。ただし、成熟したプロジェクトは更新頻度が低くても安定している場合があり、Issueの運用方針もプロジェクトごとに異なります。単一指標で優劣を決めず、複数の指標を合わせて判断してください。

自動化された指標としては、OpenSSFのScorecard があります。依存関係の更新状況、レビュー体制、脆弱性対応などをスコア化する仕組みで、複数候補を横並びで見るときの一次情報になります。

EOL・サポート期限を確認する

サポート期限は最低でも12〜24か月先まで確認してください。選定時点で既にEOLが近いバージョンを採用すると、リリース直後にアップグレード作業が発生します。主要な言語・ランタイム・フレームワークのサポート期限は endoflife.date で横断的に確認できますが、最終的には公式のリリースポリシーで裏を取るのが確実です。

ライセンスを確認する

商用案件では、ライセンスが足切り軸になることがあります。とくにGPL系ライセンスは、リンクの形態・配布の有無・派生物に当たるかどうかで扱いが分かれるため、法務での確認が必要になることがあり、顧客や自社の方針しだいで採用が難しいケースもあります。ここは自己判断で済ませず、案件の法務窓口に確認してください。この論点はOSSライセンスとは｜GPL・MIT・Apacheの違いと商用利用の注意点で詳しく整理しています。

選定段階でライセンスを確認しておくと、実装が進んでからの差し替えを避けられます。

比較表と意思決定記録（ADR）の残し方

技術選定の成果物は2つです。比較表（判断の過程）とADR（判断の結論と理由）。

比較表に入れる列

点数だけの表にしないでください。「○」の横に「認証連携は公式手順どおりで繋がった」と一言添えるだけで、表の説得力が変わります。

落とした候補を表に残す理由

見送った候補を消すと、比較表がただの採用理由書になります。残しておくと3つの効果があります。

1. 「ちゃんと比較した」という事実が伝わり、決定への信頼が上がる

2. 前提が変わったとき（予算が増えた、メンバーが増えた）に再検討の起点になる

3. 新規参画者からの再提案に、短時間で答えられる

ADRの基本フォーマット

ADRとは、1つの技術的意思決定について、背景・決定内容・影響を1件ずつ記録する軽量ドキュメントです。1つの決定を1ファイルで残すのが基本形で、ADRの情報ハブ にテンプレートや関連資料が公開されています。

最小構成は次の4項目です。

• タイトル：決定内容を一文で（例：認証基盤にAuth0を採用する）

• ステータス：提案中／承認済み／廃止／代替済み

• コンテキスト：なぜこの決定が必要になったか、制約は何か

• 決定と結果：何を選んだか、その結果どんな影響（良い面・悪い面）が出るか

選択肢の比較まで構造化したい場合は、MADR のテンプレートが使いやすいです。検討した選択肢と、それぞれの長所短所を書く欄があります。

書き換えず「supersede」する運用

ADR運用で最も重要なルールは、一度書いたADRを書き換えないことです。決定が覆ったら、新しいADRを作って古いものを「代替済み（superseded）」にします。

書き換えてしまうと、「当時どういう判断をしたのか」という履歴が消えます。履歴が残っていれば、同じ議論を繰り返さずに済みます。MicrosoftもAzure Well-Architected Frameworkの中でADRの維持方法を解説しており、記録を残す運用そのものを設計の一部として位置づけています。

ADRを書く時間の目安

1件あたり30〜60分、分量はA4で1〜2ページに収めるのが現実的です。これ以上かけると書かれなくなります。書かれないADRに価値はありません。

参画中のドキュメント化をどう評価につなげるかは、フリーランスの稼働報告とドキュメント｜評価される参画中の可視化と引き継ぎも合わせて読むと整理しやすいと思います。

提案を通す説明の型｜相手別に翻訳する

技術的に正しい提案が却下されることは珍しくありません。原因の多くは、相手の関心事に翻訳されていないことです。

説明の基本構成

説明は4ブロックで組み立てます。

1. 結論：何を採用したいか（1文）

2. 判断の前提：どの制約を優先したか（1〜2文）

3. 却下した選択肢と理由：検討の幅を示す（各1文）

4. 残るリスクと対処：不安要素を自分から出す

4つめを自分から言うのがコツです。リスクを隠した提案は、指摘された瞬間に信頼を失います。先に出しておけば、議論が「採用するか」から「リスクをどう抑えるか」に移ります。

PM・事業側に説明するとき

技術の優劣は響きません。響くのは納期・コスト・運用負荷・撤退可能性です。

• 「型安全だから」→「実装後半のバグ修正が減り、テスト工数が圧縮できる見込みです」

• 「モダンだから」→「採用市場で経験者を見つけやすい傾向があり、メンバー交代時の引き継ぎコストを抑えやすくなります」

• 「パフォーマンスが良い」→「現在の想定データ量なら、インフラ費用を上げずに対応できます」

工数への影響を数字で語れると強いです。見積もりの根拠の作り方は工数見積もりのやり方｜手法4種・根拠の作り方とバッファ設計・失敗パターンで整理しています。

既存メンバー・反対者に説明するとき

反対の理由は、技術そのものではなく「自分が書けなくなること」への不安であるケースが少なくありません。

この場合、正面から論破しても通りません。有効なのは次のような進め方です。

• 学習期間と、その間のサポート体制をセットで提示する

• 全面採用ではなく、影響範囲を限定した部分適用から始める

• 相手が積み上げてきた既存構成の判断を、まず正しいものとして扱う

会議で初めて提案を出さない、というのも実務的なコツです。関係者が複数いて合意形成が要る現場では、提案前に2〜3人へ個別に当てておくと、会議を確認の場にしやすくなります。反対意見は、公開の場より一対一のほうが率直に出てきます。意思決定者が明確な小規模チームなら、この手間は不要なこともあります。

提案が通らないときの立て直し

通らなかった提案は、次の3つのどれかで詰まっています。

3つめは、参画から日が浅い時期に起きやすいパターンです。関連する考え方はフリーランス案件を発注側が見送る7つの理由｜提案が通らない原因やフリーランスエンジニアの信頼の作り方｜継続指名を生む長期設計にも通じます。

ケース別｜立場とフェーズで変わる進め方

新規開発でゼロから選ぶ

裁量が大きい分、チーム適合性の重みを上げてください。自分ひとりが書けても、運用は他の人が引き継ぎます。設計思想の共有までを含めた選定にする必要があります。アーキテクチャの型を揃える議論はクリーンアーキテクチャとは｜4層構造とDDDの関係を実務目線で解説なども参考になります。

既存システムへの部分導入

論点は既存との整合に寄ります。認証、ログ基盤、デプロイパイプライン、監視。ここが揃わないと、技術単体が優れていても運用が二重化します。

部分導入では「撤退可能性」を評価軸に入れておくと安全です。うまくいかなかったときに、どれだけの工数で戻せるか。

参画直後で発言権が弱いとき

いきなり構成全体への異議を唱えるのは得策ではありません。最初の2〜4週間は既存の選定を尊重し、まず理由を聞くほうが結果的に早く進みます。

そのうえで、影響範囲の小さいところから提案します。テストの書き方、Lintの設定、CIの高速化。小さな提案が通ると、大きな提案の通りやすさが変わります。この積み上げ方はコードレビューの作法｜指摘の書き方・受け方と信頼される進め方と地続きです。

よくある失敗と対策

候補を触ってから評価軸を作る

最も多い失敗です。触った後に軸を作ると、本命が有利になる軸を無意識に選びます。軸は候補比較の前に紙に書き、書いた時点をチームに共有しておく。

「best practice」をそのまま持ち込む

他社の事例は、その会社の制約下での最適解です。チーム規模も、既存資産も、予算も違います。事例は候補出しの材料として使い、評価はこちらの制約で行ってください。

技術的な正しさだけで押し切る

正しさは通す力ではありません。相手の言語に翻訳できていない提案は、正しくても止まります。

検証に時間をかけすぎる

検証が2週間を超えたあたりから、「まだ決まらないのか」という圧力が生まれ、選定プロセス自体への信頼が落ちます。期間を先に区切り、区切った時点でわかったことで判断する。完璧な情報は集まりません。

記録を残さず口頭で決める

その場では速いですが、3か月後に誰も理由を説明できなくなります。決定の直後、記憶が新しいうちに30分だけ確保してください。

見直し条件を決めていない

「いつ再検討するか」を決めずに採用すると、問題が起きても誰も言い出せません。「利用者数が○倍を超えたら再評価」「メジャーバージョンが2つ進んだら見直す」のように、条件を決めておくと再検討が個人の批判になりません。

技術選定の実践チェックリスト

着手前と決定前に、この一覧で抜けを確認してください。

着手前

• ☐

  納期・工数・予算・チームスキルを書き出したか

• ☐

  セキュリティ・顧客固有の制約を確認したか

• ☐

  誰が最終決定者かを確認したか

• ☐

  いつまでに決めるかを合意したか

比較中

• ☐

  候補を3つ以上、性質を変えて用意したか

• ☐

  候補を触る前に評価軸と重みを決めたか

• ☐

  足切り軸（必須要件）を明示したか

• ☐

  各軸に「机上／検証」のラベルを付けたか

• ☐

  ライセンスとサポート期限（12〜24か月先）を確認したか

決定後

• ☐

  比較表に落とした候補と却下理由を残したか

• ☐

  ADRを書いたか（コンテキスト・決定・結果の3点）

• ☐

  見直し条件を明記したか

• ☐

  関係者に決定と理由を共有したか

なお、技術選定を含む上流工程の担当範囲と単価の関係はエンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップやフリーランスエンジニアの単価相場と単価の上げ方で扱っています。

まとめ

技術選定は、評価軸を先に決め、3つ以上の候補を同じ土俵で比較し、決定と却下理由を記録に残すところまでが一連の仕事です。 提案が通るかどうかは、技術の正しさより「相手の関心事に翻訳できているか」で決まります。

• 制約の言語化 → 候補3〜4つ → 評価軸と重み → 小さく検証 → 決定と記録、の5ステップで進める

• 評価軸は候補を触る前に決める。重みは「必須・重視・参考」の3段階で十分

• 非機能要件のフレームワーク（IPA非機能要求グレード、Well-Architected Framework）を軸の抜け漏れチェックに使う

• 健全性は印象でなく観測指標で。サポート期限は12〜24か月先まで確認する

• ADRは1件30〜60分・A4で1〜2ページ。書き換えず、新しいADRで置き換える

• 説明は「結論→前提→却下理由→残るリスク」の4ブロック。リスクは自分から出す

• 会議の前に2〜3人へ個別に当てておくと、提案の通り方が変わる

明日から着手できることを3つ挙げます。

1. いまの案件で、制約条件を4項目（納期・工数・スキル・予算）書き出す

2. 直近で決める予定の技術について、候補を3つ並べて足切り軸を決める

3. すでに決まっている技術構成を1つ選び、ADRを1件だけ書いてみる

3つめが一番効きます。「なぜそれが選ばれたのか」を関係者に聞いて、理由が出てこなければ、そこがあなたの最初のADRを書く場所です。担当範囲が広がってきた段階で市場からどう見られるか気になる方は、無料のフリーランスエンジニア単価診断で現在の目安を確認できます。

参照した一次情報

• Architectural Decision Records（ADR）

• MADR（Markdown Architectural Decision Records）

• アーキテクチャデシジョンレコード（ADR）を維持する｜Microsoft Azure Well-Architected Framework

• 非機能要求グレード｜IPA 独立行政法人 情報処理推進機構

• AWS Well-Architected Framework

• Azure Well-Architected Framework の柱

• OpenSSF Scorecard

• endoflife.date