---
title: 実装方法・仕様の選び方
tags:  #システム工学  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/VJPK14NWE8.jpg?width=480
description: 実装方法・仕様の選び方 by Yukiko
published: September 02, 26
canonical: https://image.docswell.com/s/yukiko_it/KL38NG-2026-09-02-082502
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/VJPK14NWE8.jpg)

実装方法・仕様の選び方
技術選定とトレードオフ分析の実践
法人研修・実務講座向け教材
うさうさ研修工房


# Page. 2

![Page Image](https://bcdn.docswell.com/page/2EVVYXK9EQ.jpg)

今日学ぶこと
1
選定の前提
→
2
選定基準
→
3
比較・記録
→
4
見直し
「何となく前と同じ方法」ではなく、選んだ理由を説明できる状態を目指します
実装方法・仕様の選び方 2 / 12


# Page. 3

![Page Image](https://bcdn.docswell.com/page/57GL9VQ4EL.jpg)

なぜ選定に時間をかけるべきか
設計・実装段階で見つかる欠陥修正コストは、要件段階の欠陥修正コストの数倍〜数十
倍に達するという実証研究があります。
（Boehm, 1981, Software Engineering Economics／後年の追試では倍率に幅があるが、上流での手戻りが安価という傾向自体は一貫して
支持される）
実装方式の選定ミスは、あとから静かに「技術的負債」として積み上がります。最初の選定に時間をか
けることは、遠回りではありません。
実装方法・仕様の選び方 3 / 12


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4EQYW6KRJP.jpg)

①選定の前提をそろえる
制約条件
予算・納期・既存システムとの互換性・チームのスキルセット
非機能要件
性能・セキュリティ・拡張性・保守性の優先順位
ステークホルダーの期待
何を最優先するか（速さ／堅牢さ／コスト）の事前合意
実装方法・仕様の選び方 4 / 12


# Page. 5

![Page Image](https://bcdn.docswell.com/page/KJ4WK4PQ71.jpg)

②選定基準： 4つの観点
実現性
コスト
保守性
リスク
その方式で要件を満たせる
か
開発・運用・ライセンスコスト
将来の変更・引き継ぎのしや
すさ
実績の少なさ・依存先の将来
性
4つすべてで満点の方式は存在しません。何を優先するかを先に決めるのが選定の本質です。
実装方法・仕様の選び方 5 / 12


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LE1YX49L7G.jpg)

②よくある選定：自作 vs 既存活用
自作（スクラッチ実装）
既存ライブラリ・サービス活用
○ 要件に完全に合わせられる
○ 外部依存のリスクがない
✕ 開発・保守コストが高い
✕ 車輪の再発明になりやすい
○ 開発スピードが速い
○ 実績・コミュニティの知見を活用できる
✕ 要件との細部のズレが出ることがある
✕ 依存先の将来性・保守状況に左右される
判断の軸：その機能は「差別化に直結するか」。直結しないなら既存活用を優先する
実装方法・仕様の選び方 6 / 12


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GEWGNXQQJ2.jpg)

③選択肢を比較する：重み付けスコアリング
観点
重み
案A
案B
実現性
×3
5
4
コスト
×2
3
5
保守性
×2
4
3
リスク
×1
4
2
合計：案A＝5×3+3×2+4×2+4×1＝37 ／ 案B＝4×3+5×2+3×2+2×1＝36
重みは「何を優先するか」の合意を数値化したもの。点数を出すこと自体より、重みづけの議論に価値がありま
す。
実装方法・仕様の選び方 7 / 12


# Page. 8

![Page Image](https://bcdn.docswell.com/page/47ZL36W3J3.jpg)

③意思決定を記録する： ADR
Architecture Decision Record（Nygard, 2011）
# タイトル：認証方式にJWTを採用する
## 状況（Context）
セッション管理をサーバーレス構成でも簡潔にしたい
## 決定（Decision）
JWTベースの認証を採用する
## 根拠（Consequences）
＋ サーバー側の状態管理が不要になる
－ トークンの即時失効が難しい（対策：短い有効期限＋リフレッシュトークン）
実装方法・仕様の選び方 8 / 12


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YJ6WX2GZJV.jpg)

③選定結果を仕様書に落とし込む
1
採用した方式と、採用しなかった選択肢・却下理由を明記する
2
前提とした制約条件（予算・納期等）を仕様書に残す
3
非機能要件（性能目標値等）を数値で明記する
実装方法・仕様の選び方 9 / 12


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJ5MX2V9J4.jpg)

④選定は一度で終わらない
技術的負債（ Technical Debt）は、選定時点では正しかった判断が、状況変化によって負債化す
る現象として説明されます。
（Cunningham, 1992の負債メタファーに端を発する概念）
見直しのきっかけの例：利用規模の急拡大、依存ライブラリの保守終了、チーム構成の変化
実装方法・仕様の選び方 10 / 12


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LE3WXKD2E5.jpg)

まとめ
1
前提（制約・非機能要件）を揃えてから選定を始める
2
満点の選択肢はない。優先順位を先に決めて重み付けで比較する
3
決定理由をADR等の形で記録し、将来の見直しに備える
実装方法・仕様の選び方 11 / 12


# Page. 12

![Page Image](https://bcdn.docswell.com/page/8EDK23P67G.jpg)

出典・参考文献
・Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall.
・Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA experience report.（技術的負債メタファーの初
出）
・Nygard, M. (2011). Documenting Architecture Decisions.（ADRの提唱）
・Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software.
うさうさ研修工房