Tsuzura

技術選定の進め方

要件と品質条件から候補を絞り、必須条件、証拠、検証、費用、運用、見直しまでを技術選定票にまとめる手順です。

公開日
更新日

同じ機能を作れる技術でも、必要な品質、運用の負担、費用、変更のしやすさは変わります。技術名を先に決めると、後からサービスに必要な条件へ合わないことが分かっても、選び直しにくくなります。

技術選定は、サービスの中で一つの役割を担う技術について、サービスが満たす条件と、公式資料や検証結果を基に採用・保留・不採用を決める作業です。先に判断材料と条件をそろえ、候補を同じ前提で比べます。分からない点は点数へ置き換えず、結論に影響するものだけを小さく確かめます。

この記事は、AIを補助に使いながら初めて小規模なWebサービスや業務システムを作る人を対象にしています。専門知識は必要ありません。ただし、選定の入力として一機能分の要件と品質条件が必要です。読み終えると、一件の判断について、候補、条件、証拠、未確認事項、採否、見直し条件を「技術選定票」へまとめられます。

一機能分の要件がまだない場合は、先に要件と受入条件の決め方を確認してください。品質条件が曖昧な場合は、非機能要件の決め方から始めます。この記事では、特定製品の順位、案件を問わない技術構成、作る・買う・外注する判断、コードの構成方式、設計判断の記録（ADR）の詳しい運用は扱いません。

技術選定が必要な理由

技術選定が必要なのは、技術の違いが実装だけでなく、品質、運用、費用、データの扱い、将来の変更へ影響するからです。何も比較せず既定値を使う場合も、その既定値を採用する判断は残ります。

英国政府の技術選定ガイドは、既存システムとデータ、過去の判断、セキュリティ、総費用、データの管理、後から変更できるかを確認項目に挙げています。英国政府サービス向けのガイドであり、日本の小規模サービスへの義務ではありません。この記事では、候補を調べる前に確認する観点として使います。

技術選定で決めること

一回の技術選定では、一つの役割について候補を比べます。その結果を、採用、保留、不採用のいずれかに分け、理由と証拠を残します。

NASAのDecision Analysisガイドは、判断の状況と目的を確認した後に、評価条件、代替案、評価方法、比較結果、推奨、最終判断を扱います。分析の細かさは、判断の影響、複雑さ、不確実性に合わせるとしています。NASAの正式な工程をそのまま使う必要はありませんが、判断の順序は小さな選定にも使えます。

採用は、必須条件を満たし、結論を変える未確認事項を解決したか、判断者が残る不確実性を受け入れた状態です。保留は、重要な証拠や判断者が足りず、まだ決められない状態です。不採用は、必須条件を満たさないか、負担と得られる価値の関係を受け入れられない状態です。

周辺の記事と役割を分ける

技術選定は、要件やコードアーキテクチャの代わりではありません。各判断の役割を分けると、同じ内容を別の名前で決め直さずに済みます。

判断 決めること 技術選定との関係
要件と受入条件 サービスが何をし、何を満たせば受け入れるか 選定条件の入力になる
非機能要件 どの利用条件で、どの程度の品質を求めるか 性能、信頼性、セキュリティ、費用などの基準になる
技術選定 一つの役割をどの技術へ任せるか 候補と証拠から採否を決める
コードアーキテクチャ コードの責務と依存をどう分けるか 選定した技術の中で構成を決める
設計原則 一つの変更をどう分け、保つか 実装と変更を判断する基準になる
設計判断の記録（ADR） 重要な設計判断を後から追える形で管理する 技術選定票の結果を正式な判断記録へ移す

ADRはArchitecture Decision Recordの略で、設計判断の背景、結論、影響を残す記録です。詳しい書式と更新方法は、技術判断をADRに残すで扱います。本記事では、ADRへ渡せる判断材料までを作ります。

選定の準備をする

候補を探す前に、必要な結果と現在の条件をそろえます。入力が曖昧なままでは、候補の違いを確認しても採否を決められません。

必要な結果と品質条件を確認する

最初に参照するのは、機能要件、受入条件、非機能要件です。実現方法ではなく、必要な結果と合格条件を確認します。

NASAの要件記述ガイドは、要件へ実装方法を先に混ぜないことと、満たしたかを確認できる状態にすることを確認項目にしています。一方で、互換性、契約、既存環境などにより、特定の技術や環境が正当な制約になる場合もあります。制約にするなら、固定する内容だけでなく理由と見直す条件も残します。

IEEE Computer SocietyのSWEBOK V4.0aは、特定技術に関する制約と、解決方法が満たす品質水準を分けています。品質条件どうしが影響し合い、求める水準には価値と費用の関係があることも説明しています。本記事では、必要な結果、品質条件、正当な技術上の制約を別の入力として扱います。

既存環境と担当範囲を確認する

新しい技術だけを見ても、既存のサービスへ組み込めるかは分かりません。結果を変える現在の条件を先に記録します。

確認するもの 選定前に分かるようにする内容
既存システム 使っている言語、実行環境、接続方法、変更できない部分
データ 保存場所、形式、量、機密性、正しい情報の管理元
接続と権限 外部サービス、ネットワーク、利用者とサービスの権限
運用 公開方法、監視、更新、障害対応、バックアップ、復旧の担当
チーム 導入、実装、確認、運用、更新を担える範囲
制約 予算、期限、利用量、契約、適用する規格や組織の方針

分からない項目は「問題なし」にしません。候補の採否を変える可能性があれば未確認とし、確認する人と期限、決まるまで止める作業を残します。

判断者と見直す人を決める

候補を調べる人と、採否を決める人は同じとは限りません。業務への影響、費用、データ、権限、運用を引き受けられる人を判断者として記録します。

判断者が決まらない場合は保留です。技術担当だけで決められない条件があるなら、業務責任者、セキュリティ、法務、プライバシー、購買など、必要な担当へ確認します。見直し時に誰が再判断するかも、最初の選定票へ入れておきます。

候補と条件をそろえる

候補は、同じ役割を担えるものだけを並べます。先に条件を決め、候補ごとに同じ確認方法を使える状態にします。

選ぶ対象を一件に分ける

技術を選ぶ単位が違うと、候補どうしを比べられません。役割を区別しやすいように、主な役割を次のように分けます。

選ぶ対象 サービス内での役割
プログラミング言語 処理を記述するための言語
ランタイム 書いたコードを実行する環境
フレームワーク アプリ全体の構成と共通処理を支える枠組み
ライブラリ 特定の処理をコードから呼び出す部品
データベース・ストレージ データを保存し、読み書きする仕組み
実行基盤 サービスを配置し、外部から利用できる状態で動かす場所
外部サービス API（別のシステムの機能やデータを呼び出すための接続方法）などを通して、別の事業者やシステムの機能を使う仕組み

一枚の選定票では、このうち一つだけを対象にします。複数の技術が一体でないと判断できない場合は、判断の依存関係を残し、それぞれの必須条件と責任範囲を分けます。

同じ役割の候補を出す

候補は、判断の目的と条件に合う範囲で出します。新しい技術だけでなく、現状を維持する案や依存を追加しない案も、意味がある場合は含めます。

NASAのDecision Analysisガイドは、判断条件に合う代替案を検討し、必要に応じて何もしない案も含めると説明しています。固定の候補数は示していません。数を増やすことより、同じ役割を担い、採否を判断できる候補かが重要です。検討後に外した候補も、外した理由だけは残します。

候補名だけでは情報が足りません。確認した版、提供形態、公式資料のURL、資料の確認日を一緒に記録します。クラウドサービスや外部サービスでは、料金プランや提供地域も結果を変える場合があります。

必須条件と比較条件を分ける

条件は、満たせなければ候補から外す「必須条件」と、満たす程度を比べる「比較条件」に分けます。二つを同じ合計点へ混ぜると、必須条件の不適合が別の長所で隠れてしまいます。

条件の種類 使い方 結果の扱い
必須条件 採用に必要な最低条件を確認する 一件でも不適合なら、その候補は採用対象から外す
比較条件 必須条件を満たした候補の差を比べる 証拠と負担の違いを判断材料にする

NASAのDecision Analysisガイドは、評価条件を客観的で測定可能にし、候補の違いを判断できるものにするよう説明しています。数値だけが条件ではありません。公式資料の確認、契約条項の確認、実演、テストなどで合否を判断できる条件も含みます。

証拠の状態を分ける

この記事では、候補ごとの証拠を四つの状態に分けます。これは外部規格の分類ではなく、未確認を合格や不合格に変えないための記録方法です。

状態 意味 次の扱い
確認済み 条件と確認方法が決まり、結果を示す証拠がある 比較または判断へ使える
未確認 情報、検証、担当者の確認が足りない 確認方法、担当、期限、停止条件を付ける
不適合 必須条件または受け入れられる範囲を満たさない 理由を残し、採用対象から外す
該当なし 今回の対象には適用しない 理由と見直す条件を残す

資料が見つからない、AIが推測した、検証環境が違う、といった状態は未確認です。数値の点数へ変えず、その情報が結論を変えるなら判断を保留します。

同じ条件で比較する

候補の比較では、確認項目だけでなく利用期間、利用量、対象環境をそろえます。条件が違う結果を同じ表へ並べても、候補の差なのか前提の差なのかを判断できません。

機能・品質・接続・データ・セキュリティを確認する

最初に、機能要件と品質条件を満たせるかを確認します。その後で、既存環境との接続、データの読み書き、権限、障害時の影響を見ます。

比較する観点 記録する内容
機能 対応する要件、未対応の範囲、回避方法の有無
品質 対象条件、合格基準、確認方法、結果の証拠
接続 対応する方式と版、接続元・接続先、失敗時の扱い
データ 保存場所、形式、移行、削除、書き出し、管理責任
セキュリティ 認証、権限、秘密情報、更新、記録、報告の責任範囲

セキュリティやプライバシーを一つの点数だけで合格にしません。扱う情報、公開範囲、権限、契約、法令により確認内容が変わります。個人情報、決済、高い権限、組織全体への展開が関わる場合は、必要な責任者へ確認します。

運用・更新・サポート・チームを確認する

導入できることと、継続して維持できることは別です。運用担当、更新方法、障害時の問い合わせ先、サポート終了時の移行を確認します。

NIST Cybersecurity Framework 2.0は、ソフトウェアをリスクに応じて保守、交換、削除することを望ましい成果として示しています。NISTの任意フレームワークであり、特定の更新頻度や製品を決める資料ではありません。候補を採用した後も、更新や終了へ対応できるかを見る根拠として使います。

英国政府の購入戦略ガイドは、組織の技能と能力、現実的なチーム、構築後または購入後の管理を確認するよう説明しています。現在の経験だけで候補を外しません。Microsoftの費用最適化ガイドが挙げる教育、採用、外部支援も含め、不足を補う費用と責任を比べます。

総費用を同じ前提で確認する

総費用は、利用料金だけでなく、導入から終了までに必要な費用を合わせたものです。候補ごとに同じ利用期間と利用量を置き、前提が違う場合は別に記録します。このそろえ方は、本記事の比較ルールです。

Microsoft AzureのCost Optimizationガイドは、構築と購入、料金体系、ライセンス、教育、運用、自動化、取得、変更管理などの直接・間接費用を挙げています。英国政府の購入戦略ガイドは、構築・購入、更新、継続改善、終了までを含むライフサイクル全体の費用を確認するよう説明しています。

将来の費用は推計です。対象期間、利用量、成長、為替、料金改定、移行の前提を残します。最も安い候補が要件を満たすとは限らず、費用を下げた結果が品質や運用へ与える影響も確認します。

マネージドサービスとロックインを一方向に評価しない

マネージドサービスは、基盤の管理など一部の作業を提供者が担うサービスです。任せられる作業は増えますが、利用者側のデータ、設定、権限、監視、契約、終了時の対応まで自動的になくなるわけではありません。

ロックインは、特定の提供者や技術への依存が強くなり、変更に費用や作業がかかる状態です。英国政府のCloud lock-inガイドは、マネージドサービスが開発・運用負担を減らす一方で、提供者への依存を増やし得ると説明しています。ロックインを常に避けるのではなく、得られる価値、データと技術の移しやすさ、移行費用、終了方法を比べます。

IPAの中小企業向けクラウド安全利用手引きも、社内の管理担当を決め、利用終了時に必要なデータを確保できるか確認する項目を示しています。サービス名だけで責任範囲を推測せず、公式資料、規約、契約、サポート条件で確認します。

点数は判断材料として使う

NASAのDecision Analysisガイドは、評価結果を意思決定者へ渡し、意思決定者が不確実性なども踏まえて最終判断する流れを示しています。点数は比較条件の差を整理するために使えますが、合計点をそのまま結論にしません。必須条件の不適合、未確認事項、条件間の影響は別に残します。

重みには、どの条件をどれだけ重く見るかという判断が入ります。全案件に共通する重みはありません。判断者、理由、使った尺度を記録し、わずかな点差よりも証拠の確かさと受け入れる負担を確認します。

未確認事項を検証する

すべてを試すのではなく、確認すると結論が変わり得る未確認事項だけを検証します。検証前に、何が分かれば候補の扱いがどう変わるかを決めます。

検証する条件を一つに絞る

NASAのDecision Analysisガイドは、試作、テスト、シミュレーション、利用者による確認などを評価方法に挙げています。英国政府の技術選定ガイドも、試作で技術、セキュリティ、データ、接続に関する仮定を確かめるよう説明しています。さらに、英国政府のAlpha工程ガイドは、危険度の高い仮定から検証するよう説明しています。

検証は次の順で組み立てます。

  1. 未確認の条件を一つ選ぶ
  2. 確認結果によって変わる採否を記録する
  3. 合格条件、確認方法、停止条件を決める
  4. 使う候補の版、環境、データ、権限を固定する
  5. 結果、証拠、確認できなかった範囲を残す

外部製品を候補にする場合、英国政府の購入戦略ガイドは、範囲は小さいものの実現が難しい条件、既存製品との接続、利用者の操作、公開手順との適合を小規模な試用で確かめるよう説明しています。政府調達の手順をそのまま使うのではなく、採否を変える条件へ絞る考え方だけを使います。

検証結果の範囲を残す

試作は、本番と同じ安全性、性能、可用性を保証しません。使った環境、データ量、接続先、候補の版、実行手順を記録し、確認できた範囲だけを証拠にします。

本記事では、本番データの変更、外部への書き込み、権限の拡張、購入や契約が必要な検証は、組織のルールに従って必要な承認を得てから実行します。秘密情報や個人情報をAIや未承認の外部サービスへ渡しません。安全に試せる環境がない場合は無理に進めず、保留理由と必要な準備を残します。

検証で得られる成果は、合格の確認だけではありません。不適合が分かった、または現在の方法では確認できないと分かった場合も、候補の扱いを決められる証拠になります。結果が曖昧なら未確認のままとし、別の確認方法か判断者を決めます。

技術選定票にまとめる

技術選定票は、一件の判断について、入力、候補、条件、証拠、結論を追えるようにする記録です。次の書式は、提供元や公的機関が公開した原資料（一次資料）を小規模サービス向けに整理した本記事独自の形式で、NASAやADRの公式書式ではありません。

最初に五つの項目を埋める

最初から全欄を埋める必要はありません。次の順で一件の判断を整理します。

  1. 選ぶ対象と役割を一つ決める
  2. 要件、品質条件、制約、既存環境を参照する
  3. 必須条件と比較条件を分ける
  4. 候補、版、公式資料、証拠の状態を記録する
  5. 採否を決める人を記録する

この五つのうち、結論を変える項目が未確認なら保留です。費用の詳細、移行、見直し、次工程への引き渡しは、五つをそろえながら必要な欄を追加します。

# 技術選定票

## 1. 判断すること（まず記入）

- 判断名:
- 選ぶ対象と役割:
- 対象に含む範囲:
- 対象に含まない範囲:
- 必要な結果:
- 参照する要件・受入条件:
- 参照する品質条件・設計上の制約:
- 採否を決める人:
- 状態: [下書き / 保留 / 決定済み]

## 2. 現在の条件（まず記入）

- 既存システム・実行環境:
- データ・接続先:
- 権限・セキュリティ上の条件:
- 公開・監視・更新・復旧の担当:
- チームが担える範囲:
- 予算・期限:
- 費用を比べる期間・利用量:

## 3. 候補（まず記入）

| 候補 | 版・提供形態 | 現状維持・新規 | 公式資料 | 確認日 | 候補の扱い |
|---|---|---|---|---|---|
| | | | | | [比較中 / 保留 / 採用 / 不採用] |

## 4. 条件と証拠（まず記入）

| 候補 | 種類 | 条件 | 確認方法 | 証拠 | 状態 |
|---|---|---|---|---|---|
| | 必須 | | | | [確認済み / 未確認 / 不適合 / 該当なし] |
| | 比較 | | | | [確認済み / 未確認 / 不適合 / 該当なし] |

## 5. 未確認事項と検証（未確認がある場合に記入）

| 未確認の内容 | 結論への影響 | 確認方法 | 担当・期限 | 停止条件 | 結果・限界 |
|---|---|---|---|---|---|
| | | | | | |

## 6. 判断（条件と証拠を確認した後に記入）

- 結果: [採用 / 保留 / 不採用]
- 採用する候補:
- 採用理由:
- 不採用候補と理由:
- 満たせない条件:
- 残る未確認事項:
- 対策後にも残る影響の可能性（残るリスク）:
- 運用・更新を担う人:
- データ・権限・外部提供者との責任範囲:
- 終了・移行方法:
- 判断した人:
- 判断日:

## 7. 見直しと引き渡し（決定後、該当する項目を記入）

- 見直す条件:
- 見直す人:
- 次回確認の条件または日付:
- ADRへ渡す記録:
- コードアーキテクチャへ渡す条件:
- 実装タスクへ渡す条件:
- テストへ渡す条件と証拠:
- 公開・運用へ渡す担当と記録:

採用・保留・不採用を記録する

採用には、必須条件を満たした証拠が必要です。結論を変える未確認事項が残る場合は、誰がどの影響を受け入れたかを記録できない限り保留にします。

不採用候補にも理由を残します。「点数が低い」だけでは、条件や候補が変わったときに再判断できません。満たさなかった条件、確認できなかった点、受け入れられなかった負担を分けます。

NASAのDecision Analysisガイドは、判断の状況、条件、候補、評価方法、前提、限界、不確実性、結果、最終判断と理由を記録対象にしています。小さな判断では短くまとめられますが、証拠と理由を後から追える状態は保ちます。

見直し条件を記録する

技術選定は一度決めて終わりではありません。要件、利用量、価格、サポート、契約、チーム、セキュリティ上の出来事、提供終了が変われば、以前の判断が合わなくなる場合があります。

固定の見直し間隔はありません。結果を変える出来事を条件として書き、誰が再確認するかを決めます。外部サービスでは、料金、規約、データの書き出し、提供地域、サポート終了も確認対象です。

AIを使い、次へ引き渡す

AIは、候補、確認項目、一次資料、未確認事項を整理する補助に使えます。採否、許容できる費用、残るリスク、契約や法令の判断は、必要な責任を持つ人が決めます。これは本記事の運用ルールです。

AIへ任せるのは候補と根拠の整理

AIへ渡すのは、要件、品質条件、既存環境の説明、選ぶ対象、参照してよい公式資料です。入力してよいと確認できていない秘密情報、個人情報、顧客情報は渡しません。

依頼する作業は、同じ役割の候補を分けること、必須条件と比較条件を表へ移すこと、資料のURLと確認日を整理すること、足りない情報を未確認として示すことです。AIが候補を出した理由と、どの資料に基づくかを分けて書かせます。

根拠を追えない情報では決めない

AIが示した仕様、料金、サポート期間、規約、セキュリティ機能は、候補の公式資料か安全な検証で確認します。根拠を追えない情報は削除せず、未確認へ戻します。

AIが点数や結論を出しても、自動的には採用しません。条件の重み、許容する負担、残るリスクには判断者の責任が含まれます。候補の公式資料が古い、版が違う、利用条件が合わない場合も保留です。

次へ進むか確認する

次の項目を説明できれば、一件の技術選定を次工程へ渡せる状態です。

  • 選ぶ対象と役割を一件に分けている
  • 要件、品質条件、制約、既存環境を参照できる
  • 同じ役割の候補と、必要なら現状維持の案がある
  • 必須条件と比較条件を分けている
  • 候補の版、公式資料、確認日、証拠の状態が分かる
  • 結論を変える未確認事項に、確認方法、担当、期限、停止条件がある
  • 採用・保留・不採用の理由と、残るリスクを判断者が確認している
  • 運用、更新、終了、見直しを担う人が分かる

選定後、システムの境界と内部構成を図で共有する必要があれば、C4モデルで構成図を2枚描くへ進みます。技術の中でコードをどう分けるかはコードアーキテクチャの選び方で決めます。一つの変更をどう進めるかはソフトウェア設計の基本原則と実装タスクの分け方へ渡します。

確認方法と証拠はテストの種類と選び方へつなぎます。公開前にはサービス公開前の確認で同じ候補版の証拠を照合し、公開後の担当と見直しはWebサービスの最低限の運用設計へ渡します。

未確認事項が残っていても、影響しない範囲の調査や準備は進められます。ただし、その事項が採否を変えるなら「決定済み」にはしません。技術選定票に確認する行動と判断者を残し、決められる状態になってから次へ渡します。

画面や機能のレンダリング方式を決める場合は、SSR・CSR・SSG・ISRの選び方で、HTMLを作る時点、処理場所、利用者別データ、秘密情報、認可、キャッシュを確認します。

出典