目次
問題解決・原因分析フレームワーク
QC7つ道具
概要: 品質管理（Quality Control）のための7つの基本的な統計ツール
実務テンプレート:
1. チェックシート
| 項目/時間帯 | 9-10時 | 10-11時 | 11-12時 | 13-14時 | 14-15時 | 15-16時 | 17-18時 | 合計 |
|------------|--------|---------|---------|---------|---------|---------|---------|------|
| エラーA | | | | | | | | |
| エラーB | | | | | | | | |
| エラーC | | | | | | | | |
| エラーD | | | | | | | | |
| 合計 | | | | | | | | |
2. パレート図
- データを収集（問題とその発生頻度）
- 問題を発生頻度の降順で並べ替え
- 以下のテンプレートでグラフ化
頻度 |■■■■■■■■■■ | 100%
| ■■■■■■■ |
| ■■■■■ |
| ■■■ |
| ■■ |
| ■ |
| ■ |
+---------------------------------------------------- |
問題A 問題B 問題C 問題D 問題E 問題F 問題G
3. 特性要因図（魚骨図）
原因カテゴリA 原因カテゴリC
│ │
├── 細かい原因A1 ├── 細かい原因C1
├── 細かい原因A2 ├── 細かい原因C2
│ │
──┼───────────────────────────────┼────────────── 問題
│ │
├── 細かい原因B1 ├── 細かい原因D1
├── 細かい原因B2 ├── 細かい原因D2
│ │
原因カテゴリB 原因カテゴリD
SE向け魚骨図テンプレート:
人（People） 方法（Method）
│ │
├── スキル不足 ├── 手順の不備
├── コミュニケーション不足 ├── テスト方法の問題
│ │
──┼───────────────────────────────┼────────────── システム障害
│ │
├── サーバースペック ├── 設計の問題
├── ネットワーク帯域 ├── コードの品質
│ │
環境（Environment） 技術（Technology）
4. ヒストグラム
- データの範囲を決定（最大値-最小値）
- 適切な区間数を決定（一般的に5-15区間）
- 各区間のデータ数をカウント
- 以下のテンプレートで作成
頻度 | ■■
| ■■ ■■
| ■■ ■■ ■■
| ■■ ■■ ■■ ■■
| ■■ ■■ ■■ ■■ ■■
| ■■ ■■ ■■ ■■ ■■ ■■
+--------------------------------
区間1 区間2 区間3 区間4 区間5 区間6
5. 散布図
- 2つの変数のデータを収集
- X軸、Y軸にプロット
- 傾向を確認（相関関係の有無）
Y軸 | *
| * *
| * *
| * *
| * *
| * *
+--------------------------------
X軸
6. 管理図
上部管理限界（UCL）------------------------------------------------
*
* *
平均線 ---------*-------*---------*---*--------*---------------
* * *
*
下部管理限界（LCL）------------------------------------------------
時間1 時間2 時間3 時間4 時間5 時間6 時間7
7. グラフ・層別
値 | □
| □ □
| □ □ △
| □ □ △
| ○ □ □ △
| ○ □ □ △
+-------------------------
グループA B C
使用上のコツ:
- 問題の80%は20%の原因から生じる（パレートの法則）
- 特性要因図は「4M（Man, Machine, Material, Method）」または「5M+1E（Man, Machine, Material, Method, Measurement + Environment）」で整理するとSE業務でも使いやすい
- データがあるならパレート図から始め、なければ特性要因図から始めるのが効率的
新QC7つ道具
概要: 非数値データや構造的な問題を扱うためのツール群
実務テンプレート:
1. 親和図
- 付箋などにアイデアや情報を1つずつ書き出す
- 似た内容のものをグループ化
- 各グループに見出しをつける
【グループA：システム性能】 【グループB：ユーザビリティ】
- レスポンス遅延 - 操作手順が複雑
- バッチ処理の遅延 - エラーメッセージが不明瞭
- メモリ使用量の増大 - 検索機能が使いにくい
【グループC：セキュリティ】 【グループD：保守性】
- 脆弱性対応の遅れ - ドキュメント不足
- アクセス制御の不備 - コードの可読性不足
- 監査ログの不足 - テスト環境の不備
2. 連関図
┌───────────┐
│ 根本原因 │
└─────┬─────┘
↓
┌───────────┐ ┌───────────┐ ┌───────────┐
┌─→│ 原因A │───→│ 原因B │───→│ 原因C │
│ └───────────┘ └───────────┘ └───────────┘
│ │
┌─┴────────────┐ ┌─────┴─────┐
│フィードバック├─────────────────────←┤ 結果 │
└──────────────┘ └───────────┘
3. 系統図
レベル1: 【システム障害の削減】
│
├── レベル2: 【開発プロセスの改善】
│ │
│ ├── レベル3: 【要件定義の厳密化】
│ │ │
│ │ ├── レベル4: 【ステークホルダーとの合意形成】
│ │ └── レベル4: 【曖昧な要件の明確化】
│ │
│ └── レベル3: 【テスト強化】
│ │
│ ├── レベル4: 【単体テスト自動化】
│ └── レベル4: 【負荷テスト実施】
│
└── レベル2: 【運用体制の改善】
│
├── レベル3: 【監視体制強化】
└── レベル3: 【障害対応フロー整備】
4. マトリックス図
│ 要件A │ 要件B │ 要件C │
───────────────┼─────────┼─────────┼─────────┤
機能1 │ ◎ │ ○ │ △ │
───────────────┼─────────┼─────────┼─────────┤
機能2 │ ○ │ ◎ │ × │
───────────────┼─────────┼─────────┼─────────┤
機能3 │ △ │ ○ │ ◎ │
───────────────┼─────────┼─────────┼─────────┤
凡例: ◎=強い関連(5点)、○=関連あり(3点)、△=弱い関連(1点)、×=関連なし(0点)
5. アローダイアグラム（PERT図）
4日 3日 2日
[開始] --------> [タスクA] ------> [タスクC] ------> [終了]
│ │ ↑
│ │ │
│ 2日 ↓ 5日 │
└------------> [タスクB] ----------┘
6. PDPC（Process Decision Program Chart）
目標: 【新システムの安定稼働】
│
├── 計画A: 【段階的リリース】
│ │
│ ├── 問題点: 【一部機能のみでは業務に支障】
│ │ └── 対策: 【優先度の高い機能から実装】
│ │
│ └── 問題点: 【テスト期間の延長】
│ └── 対策: 【並行稼働期間の設定】
│
└── 計画B: 【一斉リリース】
│
├── 問題点: 【障害発生時の影響大】
│ └── 対策: 【ロールバック手順の整備】
│
└── 問題点: 【ユーザー教育が間に合わない】
└── 対策: 【オンライントレーニングの実施】
7. 活動計画表（ガントチャート）
タスク │週1 │週2 │週3 │週4 │週5 │週6 │週7 │週8 │担当
──────────────┼────┼────┼────┼────┼────┼────┼────┼────┼──────
要件定義 │████│████│ │ │ │ │ │ │山田
───────────── ┼────┼────┼────┼────┼────┼────┼────┼────┼──────
基本設計 │ │████│████│ │ │ │ │ │鈴木
───────────── ┼────┼────┼────┼────┼────┼────┼────┼────┼──────
詳細設計 │ │ │████│████│ │ │ │ │佐藤
───────────── ┼────┼────┼────┼────┼────┼────┼────┼────┼──────
実装 │ │ │ │████│████│████│ │ │田中
───────────── ┼────┼────┼────┼────┼────┼────┼────┼────┼──────
テスト │ │ │ │ │ │████│████│ │高橋
───────────── ┼────┼────┼────┼────┼────┼────┼────┼────┼──────
リリース │ │ │ │ │ │ │ │████│全員
使用上のコツ:
- 親和図は議論の冒頭でブレインストーミングの整理に最適
- 連関図は複雑な因果関係を把握したいときに使用
- システム開発では、アローダイアグラムと活動計画表を組み合わせるとプロジェクト管理が効率的になる
なぜなぜ分析
概要: 問題の根本原因を特定するために「なぜ？」を5回繰り返す分析手法
実務テンプレート:
問題: 【システムがピーク時に応答遅延を起こす】
なぜ1: なぜシステムがピーク時に応答遅延を起こすのか？
→ DBへのクエリ処理が遅くなるため
なぜ2: なぜDBへのクエリ処理が遅くなるのか？
→ 同時アクセスが増加し、コネクションプールが枯渇するため
なぜ3: なぜコネクションプールが枯渇するのか？
→ コネクションの解放処理が適切に行われていないため
なぜ4: なぜコネクションの解放処理が適切に行われていないのか？
→ エラー発生時にコネクションをクローズする例外処理が不足しているため
なぜ5: なぜ例外処理が不足しているのか？
→ コーディングスタンダードにtry-with-resources使用の明示がなく、レビューでも見逃されたため
根本原因: コーディングスタンダードの不備とレビュー基準の甘さ
対策:
1. コーディングスタンダードにリソース解放処理の明確な規定を追加
2. 静的解析ツールでリソースリークを検出する仕組みを導入
3. レビューチェックリストに「リソース解放処理」の項目を追加
拡張テンプレート（なぜなぜ分析表）:
問題: 【 】
発生日時: 【 】 発生場所: 【 】
影響範囲: 【 】
┌────────────┬────────────────────────┬───────────────────┐
│ 質問レベル │ なぜ？（原因の分析） │ 根拠（事実） │
├────────────┼────────────────────────┼───────────────────┤
│ なぜ1 │ │ │
├────────────┼────────────────────────┼───────────────────┤
│ なぜ2 │ │ │
├────────────┼────────────────────────┼───────────────────┤
│ なぜ3 │ │ │
├────────────┼────────────────────────┼───────────────────┤
│ なぜ4 │ │ │
├────────────┼────────────────────────┼───────────────────┤
│ なぜ5 │ │ │
└────────────┴────────────────────────┴───────────────────┘
根本原因: 【 】
対策:
1. 【 】
2. 【 】
3. 【 】
検証方法: 【 】
責任者: 【 】 期限: 【 】
使用上のコツ:
- 単に「なぜ」を5回繰り返すのではなく、各段階で「それは事実か？」と確認する
- 複数の因果経路がある場合は、各経路で分析を行う
- 最終的な根本原因は「人・物・方法・システム・環境」のどれかに分類できるか確認する
- システムエンジニアの場合、「仕様」「設計」「実装」「運用」「教育」の5つの視点で分類すると効果的
PDCA/PDSA
概要: 継続的改善のサイクル。Plan(計画)-Do(実行)-Check(評価)-Act(改善)または
Plan(計画)-Do(実行)-Study(学習)-Act(改善)
実務テンプレート:
┌─────────────────────────────────────────────────────────┐
│ PDCA/PDSA改善サイクルシート │
├─────────────────────────────────────────────────────────┤
│ プロジェクト/課題名: 【 】 │
│ 担当者: 【 】 日付: 【 】 │
├─────────────┬───────────────────────────────────────────┤
│ Plan(計画) │ 目標: 【 】 │
│ │ │
│ │ 現状分析: │
│ │ 【 】 │
│ │ │
│ │ 具体的な実施項目: │
│ │ 1. 【 】 │
│ │ 2. 【 】 │
│ │ 3. 【 】 │
│ │ │
│ │ 成功基準(KPI): 【 】 │
│ │ 予定期間: 【 】 │
├─────────────┼───────────────────────────────────────────┤
│ Do(実行) │ 実施事項と実施結果: │
│ │ 1. 【 】 │
│ │ 2. 【 】 │
│ │ 3. 【 】 │
│ │ │
│ │ 予定外の出来事: 【 】 │
├─────────────┼───────────────────────────────────────────┤
│ Check/Study │ 結果測定: │
│ (評価/学習) │ 【 】 │
│ │ │
│ │ 目標との差異: │
│ │ 【 】 │
│ │ │
│ │ 学んだこと: │
│ │ 【 】 │
├─────────────┼───────────────────────────────────────────┤
│ Act(改善) │ 継続すべき事項: │
│ │ 【 】 │
│ │ │
│ │ 修正すべき事項: │
│ │ 【 】 │
│ │ │
│ │ 次サイクルへの提案: │
│ │ 【 】 │
└─────────────┴───────────────────────────────────────────┘
使用上のコツ:
- PDCAよりPDSAの方がより「学習」に重点を置いており、新規システム開発には適している
- 「Check」は単なる確認だが、「Study」はより深い分析と学習を含む
- 小さな改善から始め、徐々にスコープを広げる
- KPIを明確に設定し、測定可能な指標で評価する
- システム開発では複数のPDCAを並行して回すことも多い（機能改善、パフォーマンス改善、セキュリティ改善など）
A3思考法
概要: トヨタ生産方式から生まれた、A3用紙1枚に問題解決のプロセスを凝縮する方法
実務テンプレート:
┌─────────────────────────────────────────────────────────┐
│ [タイトル] [日付: yyyy/mm/dd] │
│ [作成者: ] [部署: ] │
├─────────────────────────┬───────────────────────────────┤
│ 1. 背景 │ 2. 現状分析 │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
├─────────────────────────┼───────────────────────────────┤
│ 3. 目標 │ 4. 根本原因分析 │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
├─────────────────────────┼───────────────────────────────┤
│ 5. 対策案 │ 6. 実施計画 │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
├─────────────────────────┴───────────────────────────────┤
│ 7. フォローアップと検証 │
│ │
│ │
│ │
└─────────────────────────────────────────────────────────┘
使用上のコツ:
- 本当に重要な情報だけをA3用紙1枚に収める規律を守る
- 視覚的な表現（グラフ、図表）を積極的に活用する
- 「誰が見ても理解できる」レベルの明確さを目指す
- 作成プロセス自体が思考を整理する助けになる
- システム開発では、各フェーズの終了報告や問題解決策の提案に効果的
思考整理フレームワーク
MECE
概要: Mutually Exclusive, Collectively Exhaustive（相互に排他的、全体として網羅的）な思考法
実務テンプレート:
【テーマ: システム障害の原因分析】
■ ハードウェア関連
□ サーバー機器の問題
・CPU/メモリ不足
・ディスク容量不足
・ハードウェア故障
□ ネットワーク機器の問題
・ルーター/スイッチの故障
・回線容量不足
・設定ミス
■ ソフトウェア関連
□ アプリケーションの問題
・バグ/仕様の不備
・パフォーマンスの問題
・例外処理の不備
□ ミドルウェアの問題
・DB設定の問題
・Webサーバー設定の問題
・キャッシュの問題
□ OS/基盤ソフトウェアの問題
・パッチ適用状況
・リソース設定の問題
・OS自体の不具合
■ 運用関連
□ 監視の問題
・監視漏れ
・アラート設定の問題
□ 操作ミス
・手順書の不備
・オペレーションミス
□ 変更管理の問題
・変更影響の見落とし
・テスト不足
■ 外部要因
□ セキュリティインシデント
・不正アクセス
・DoS/DDoS攻撃
□ 災害/インフラ障害
・停電
・空調故障
・自然災害
□ 外部サービス連携の問題
・API障害
・SLA未達
MECE分析チェックリスト:
1. 分類に漏れはないか？
□ 考えられる全ての要素を列挙したか
□ 「その他」カテゴリを設けるなら具体的に何があるかリストアップしたか
2. 分類に重複はないか？
□ 同じ要素が複数のカテゴリに入っていないか
□ カテゴリ間の境界は明確か
3. 分類の粒度は適切か？
□ 重要な項目は詳細に分解されているか
□ 各カテゴリの要素数はバランスが取れているか
4. 目的に合った分類になっているか？
□ 分析の目的に沿った切り口になっているか
□ 実務で活用できる分類になっているか
使用上のコツ:
- 「大分類→中分類→小分類」と階層的に整理すると理解しやすい
- 「プロセス（時系列）」「組織（責任範囲）」「構成要素」など、複数の切り口で整理してみる
- 完璧なMECEを目指すよりも、実用的な分類を優先する
- システム開発では要件定義や設計書のレビュー時に活用すると抜け漏れを防げる
ロジックツリー
概要: 課題や目標を論理的に分解し、構造化する思考法
実務テンプレート:
目標: 【Webサイトのコンバージョン率向上】
│
├── 1. 訪問者数の増加
│ ├── 1.1 SEO対策の強化
│ │ ├── 1.1.1 キーワード最適化
│ │ ├── 1.1.2 コンテンツ充実
│ │ └── 1.1.3 内部リンク構造改善
│ │
│ ├── 1.2 広告施策の見直し
│ │ ├── 1.2.1 リスティング広告の最適化
│ │ ├── 1.2.2 SNS広告の活用
│ │ └── 1.2.3 リターゲティング広告の強化
│ │
│ └── 1.3 外部連携の拡大
│ ├── 1.3.1 アフィリエイト提携
│ ├── 1.3.2 業界サイトとの相互リンク
│ └── 1.3.3 インフルエンサーマーケティング
│
├── 2. 直帰率の低減
│ ├── 2.1 UI/UXの改善
│ │ ├── 2.1.1 レスポンシブデザイン最適化
│ │ ├── 2.1.2 ナビゲーション改善
│ │ └── 2.1.3 レイアウト見直し
│ │
│ └── 2.2 コンテンツの質向上
│ ├── 2.2.1 有益な情報提供
│ ├── 2.2.2 視覚的コンテンツ追加
│ └── 2.2.3 ターゲット別コンテンツ作成
│
└── 3. 購買導線の最適化
├── 3.1 カート導線の簡略化
│ ├── 3.1.1 ステップ数削減
│ ├── 3.1.2 進捗表示の改善
│ └── 3.1.3 離脱ポイントの特定と改善
│
├── 3.2 信頼性の向上
│ ├── 3.2.1 セキュリティ表示の強化
│ ├── 3.2.2 レビュー/評価の表示
│ └── 3.2.3 保証/返品ポリシーの明確化
│
└── 3.3 購入障壁の排除
├── 3.3.1 支払い方法の多様化
├── 3.3.2 配送オプションの拡充
└── 3.3.3 ゲスト購入の許可
空のロジックツリーテンプレート:
目標: 【 】
│
├── 1. 【 】
│ ├── 1.1 【 】
│ │ ├── 1.1.1 【 】
│ │ ├── 1.1.2 【 】
│ │ └── 1.1.3 【 】
│ │
│ ├── 1.2 【 】
│ │ ├── 1.2.1 【 】
│ │ ├── 1.2.2 【 】
│ │ └── 1.2.3 【 】
│ │
│ └── 1.3 【 】
│ ├── 1.3.1 【 】
│ ├── 1.3.2 【 】
│ └── 1.3.3 【 】
│
├── 2. 【 】
│ ├── 2.1 【 】
│ │ ├── 2.1.1 【 】
│ │ ├── 2.1.2 【 】
│ │ └── 2.1.3 【 】
│ │
│ └── 2.2 【 】
│ ├── 2.2.1 【 】
│ ├── 2.2.2 【 】
│ └── 2.2.3 【 】
│
└── 3. 【 】
├── 3.1 【 】
│ ├── 3.1.1 【 】
│ ├── 3.1.2 【 】
│ └── 3.1.3 【 】
│
├── 3.2 【 】
│ ├── 3.2.1 【 】
│ ├── 3.2.2 【 】
│ └── 3.2.3 【 】
│
└── 3.3 【 】
├── 3.3.1 【 】
├── 3.3.2 【 】
└── 3.3.3 【 】
使用上のコツ:
- 最初に大きな枠組み（第1階層）を3-5項目に分類してから詳細化する
- MECEを意識して分類する
- 各階層での分類は同じロジックで行う（例：第1階層が「機能別」なら第2階層も「機能別」）
- 現実的な対応が可能なレベルまで分解する（具体的なアクション項目になるまで）
- システムエンジニアは要件分析や機能分解、障害原因の特定に活用すると効果的
ピラミッドストラクチャー
概要: 結論から始まり、それを支える論理を階層的に構造化する思考法
実務テンプレート:
┌───────────────────────────────────────────────────────┐
│ 【結論】 │
│ システムリプレイスは2025年度第2四半期に実施すべき │
└───────────────────────────────────────────────────────┘
↑ ↑ ↑
┌───────────────────┬───────────────────┬───────────────────┐
│ 【主張1】 │ 【主張2】 │ 【主張3】 │
│現行システムの │技術的な準備が │予算と人員の │
│限界が近づいている│整う時期である │確保が可能である │
└───────────────────┴───────────────────┴───────────────────┘
↑ ↑ ↑ ↑ ↑ ↑
┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│【根拠1-1】│【根拠1-2】│【根拠2-1】│【根拠2-2】│【根拠3-1】│【根拠3-2】│
│パフォー │保守期限が│新技術の │移行ツール│来年度予算│主要メン │
│マンス低下│2026年 │検証完了 │の開発完了│に計上済み│バーの確保│
└─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
↑ ↑ ↑
┌─────────────────┬─────────────────┬─────────────────┐
│ 【データ】 │ 【データ】 │ 【データ】 │
│レスポンス時間 │AWS検証結果 │予算承認文書 │
│が30%増加 │移行テスト成功率 │リソース計画書 │
└─────────────────┴─────────────────┴─────────────────┘
空のピラミッドストラクチャーテンプレート:
┌───────────────────────────────────────────────────────┐
│ 【結論】 │
│ │
└───────────────────────────────────────────────────────┘
↑ ↑ ↑
┌───────────────────┬───────────────────┬───────────────────┐
│ 【主張1】 │ 【主張2】 │ 【主張3】 │
│ │ │ │
└───────────────────┴───────────────────┴───────────────────┘
↑ ↑ ↑ ↑ ↑ ↑
┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│【根拠1-1】│【根拠1-2】│【根拠2-1】│【根拠2-2】│【根拠3-1】│【根拠3-2】│
│ │ │ │ │ │ │
└─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
↑ ↑ ↑
┌─────────────────┬─────────────────┬─────────────────┐
│ 【データ】 │ 【データ】 │ 【データ】 │
│ │ │ │
└─────────────────┴─────────────────┴─────────────────┘
使用上のコツ:
- MECE原則を適用して主張を構成する
- 各階層の要素数は3-5個程度に抑える
- 根拠とデータは常に事実に基づくものにする
- データは可能な限り数値化する
- システム提案書、プロジェクト計画書、報告書などで活用すると説得力が増す
KPT法
概要: Keep（続けること）、Problem（問題点）、Try（試すこと）の3つの視点からふりかえりを行う方法
実務テンプレート:
┌─────────────────────────────────────────────────────────┐
│ KPTふりかえりシート │
├─────────────────────────────────────────────────────────┤
│ プロジェクト/チーム名: 【 】 │
│ 期間: 【 】 実施日: 【 】 │
│ 参加者: 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Keep】 - 継続すべきこと │
│ │
│ • 【 】 │
│ • 【 】 │
│ • 【 】 │
│ • 【 】 │
│ • 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Problem】 - 問題点・課題 │
│ │
│ • 【 】 │
│ • 【 】 │
│ • 【 】 │
│ • 【 】 │
│ • 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Try】 - 次回試すこと・改善案 │
│ │
│ • 【 】← 問題【 】に対応 │
│ • 【 】← 問題【 】に対応 │
│ • 【 】← 問題【 】に対応 │
│ • 【 】← 問題【 】に対応 │
│ • 【 】← 新たな試み │
├─────────────────────────────────────────────────────────┤
│ 【アクションアイテム】 │
│ │
│ • 【内容 】【担当者 】【期限 】 │
│ • 【 】【 】【 】 │
│ • 【 】【 】【 】 │
│ • 【 】【 】【 】 │
└─────────────────────────────────────────────────────────┘
使用上のコツ:
- 定期的に（イテレーション/スプリント終了時、マイルストーン達成時など）実施する
- 全員が発言できる環境を作る
- Problemを責める場にしない
- TryはProblemに紐づける
- システム開発ではスプリントレビューやプロジェクト振り返りに最適
OODA
概要: Observe（観察）、Orient（状況判断）、Decide（意思決定）、Act（行動）のループを高速で回す意思決定フレームワーク
実務テンプレート:
┌─────────────────────────────────────────────────────────┐
│ OODAループワークシート │
├─────────────────────────────────────────────────────────┤
│ 状況/課題: 【 】 │
│ 記入者: 【 】 日付: 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Observe】 - 観察（何が起きているか） │
│ • 客観的な事実: │
│ - 【 】 │
│ - 【 】 │
│ │
│ • データ/指標: │
│ - 【 】 │
│ - 【 】 │
│ │
│ • フィードバック: │
│ - 【 】 │
│ - 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Orient】 - 状況判断（どういう状況か） │
│ • 分析: │
│ - 【 】 │
│ │
│ • 過去の経験・教訓: │
│ - 【 】 │
│ │
│ • 複数の視点: │
│ - 技術的視点: 【 】 │
│ - ビジネス的視点: 【 】 │
│ - ユーザー視点: 【 】 │
│ │
│ • リスク評価: │
│ - 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Decide】 - 意思決定（何をするか） │
│ • 可能な選択肢: │
│ 1. 【 】 │
│ 2. 【 】 │
│ 3. 【 】 │
│ │
│ • 意思決定: │
│ - 【 】 │
│ │
│ • 決定理由: │
│ - 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【Act】 - 行動（どう実行するか） │
│ • 具体的なアクション: │
│ 1. 【 】 │
│ 2. 【 】 │
│ 3. 【 】 │
│ │
│ • タイムライン: │
│ - 【 】 │
│ │
│ • 責任者: │
│ - 【 】 │
│ │
│ • 成功の指標: │
│ - 【 】 │
├─────────────────────────────────────────────────────────┤
│ 【次のループの準備】 │
│ • 観察すべきフィードバック: │
│ - 【 】 │
│ │
│ • データ収集計画: │
│ - 【 】 │
└─────────────────────────────────────────────────────────┘
使用上のコツ:
- 不確実性の高い状況や緊急対応が必要な場合に特に有効
- 完璧な計画を立てるよりも、迅速な行動と学習を重視する
- データと直感の両方を活用する
- 重要なのは一回のループの質ではなく、ループを素早く回す速度
- システム障害対応、セキュリティインシデント対応、アジャイル開発において特に有効
プロジェクト管理フレームワーク
WBS
概要: Work Breakdown Structure（作業分解構造）。プロジェクトの全作業を階層的に分解する手法
実務テンプレート:
プロジェクト名: 【顧客管理システム開発】
1. 要件定義 (10日)
1.1 現状業務分析 (3日)
1.1.1 インタビュー実施 (2日) [担当: 鈴木]
1.1.2 ドキュメント整理 (1日) [担当: 佐藤]
1.2 要件整理 (4日)
1.2.1 機能要件定義 (2日) [担当: 鈴木, 佐藤]
1.2.2 非機能要件定義 (2日) [担当: 山田]
1.3 要件定義書作成 (3日)
1.3.1 ドラフト作成 (2日) [担当: 鈴木]
1.3.2 レビュー・修正 (1日) [担当: 全員]
2. 基本設計 (15日)
2.1 システム方式設計 (4日)
2.1.1 アーキテクチャ設計 (2日) [担当: 田中]
2.1.2 インフラ構成設計 (2日) [担当: 高橋]
...
3. 詳細設計 (20日)
...
4. 開発 (30日)
...
5. テスト (15日)
...
6. 導入 (10日)
...
WBSテンプレート（表形式）:
┌────┬────────────────────┬──────┬──────────┬────────┬────────┬─────────────┐
│WBS │タスク名 │期間 │開始日 │終了日 │担当者 │先行タスク │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1 │要件定義 │10日 │2023/4/1 │2023/4/14│ │ │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1.1 │現状業務分析 │3日 │2023/4/1 │2023/4/5 │ │ │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1.1.1│インタビュー実施 │2日 │2023/4/1 │2023/4/2 │鈴木 │ │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1.1.2│ドキュメント整理 │1日 │2023/4/3 │2023/4/3 │佐藤 │1.1.1 │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1.2 │要件整理 │4日 │2023/4/6 │2023/4/9 │ │1.1 │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1.2.1│機能要件定義 │2日 │2023/4/6 │2023/4/7 │鈴木,佐藤│1.1.2 │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│1.2.2│非機能要件定義 │2日 │2023/4/8 │2023/4/9 │山田 │1.2.1 │
├────┼────────────────────┼──────┼──────────┼────────┼────────┼─────────────┤
│... │... │... │... │... │... │... │
└────┴────────────────────┴──────┴──────────┴────────┴────────┴─────────────┘
使用上のコツ:
- WBSコードは階層構造を表す（例: 1.2.3は第1フェーズの第2作業の第3タスク）
- 最下位レベルのタスク（ワークパッケージ）は、明確な成果物と担当者を持つべき
- 粒度は「1人が2-5日で完了できる規模」が目安
- 先行タスクを明確にして依存関係を示す
- システム開発では標準的な工程（要件→設計→開発→テスト→導入）をベースに調整
- アジャイル開発でも全体を把握するためのWBSは有効
バーンダウンチャート
概要: プロジェクトまたはスプリントの残作業量の推移を可視化するツール
実務テンプレート:
残作業量 |
(ストーリー|
ポイント)|
100 |*
| \
90 | \
| \
80 | *
| \
70 | \
| \
60 | \
| *
50 | \
| \
40 | *
| \
30 | \
| *
20 | \
| \
10 | *
| \
0 +---------------------*---------
1 2 3 4 5 6 7 8 9 10 日数
--- 理想ライン
*** 実績ライン
バーンダウンチャートテンプレート（表形式）:
┌────────────┬────────┬────────┬────────────────┬────────────────┐
│日付 │残タスク│消化 │理想残タスク │差異 │
│ │ポイント│ポイント│ポイント │ │
├────────────┼────────┼────────┼────────────────┼────────────────┤
│2023/5/1 │100 │0 │100 │0 │
├────────────┼────────┼────────┼────────────────┼────────────────┤
│2023/5/2 │95 │5 │90 │+5（遅れ） │
├────────────┼────────┼────────┼────────────────┼────────────────┤
│2023/5/3 │85 │10 │80 │+5（遅れ） │
├────────────┼────────┼────────┼────────────────┼────────────────┤
│2023/5/4 │70 │15 │70 │0（予定通り） │
├────────────┼────────┼────────┼────────────────┼────────────────┤
│2023/5/5 │55 │15 │60 │-5（先行） │
├────────────┼────────┼────────┼────────────────┼────────────────┤
│... │... │... │... │... │
└────────────┴────────┴────────┴────────────────┴────────────────┘
使用上のコツ:
- スプリントやイテレーションの開始時に全タスクを洗い出し、ポイント見積りを行う
- 日次でチャートを更新し、進捗状況を確認する
- 理想ラインとの乖離が大きい場合は、原因を分析し対策を講じる
- スコープの追加があった場合は、明示的に記録する
- チーム全体の作業をバーンダウンチャートで、個人の作業はタスクボードで管理するとよい
カンバン
概要: タスクの流れを可視化し、ワークフローを最適化するためのツール
実務テンプレート:
┌───────────────┬───────────────┬───────────────┬───────────────┐
│ ToDo │ In Progress │ Review │ Done │
│ (WIP上限なし) │ (WIP上限:3) │ (WIP上限:2) │ │
├───────────────┼───────────────┼───────────────┼───────────────┤
│ ┌───────────┐ │ ┌───────────┐ │ ┌───────────┐ │ ┌───────────┐ │
│ │タスクA │ │ │タスクC │ │ │タスクE │ │ │タスクF │ │
│ │優先度:高 │ │ │担当:鈴木 │ │ │担当:山田 │ │ │完了:5/1 │ │
│ │見積:3ポイント│ │開始:5/1 │ │ │ │ │ │ │ │
│ └───────────┘ │ └───────────┘ │ └───────────┘ │ └───────────┘ │
│ │ │ │ │
│ ┌───────────┐ │ ┌───────────┐ │ │ ┌───────────┐ │
│ │タスクB │ │ │タスクD │ │ │ │タスクG │ │
│ │優先度:中 │ │ │担当:佐藤 │ │ │ │完了:5/2 │ │
│ │見積:2ポイント│ │開始:5/2 │ │ │ │ │ │
│ └───────────┘ │ └───────────┘ │ │ └───────────┘ │
│ │ │ │ │
│ ┌───────────┐ │ │ │ │
│ │タスクH │ │ │ │ │
│ │優先度:低 │ │ │ │ │
│ │見積:1ポイント│ │ │ │
│ └───────────┘ │ │ │ │
└───────────────┴───────────────┴───────────────┴───────────────┘
拡張カンバンテンプレート:
┌────────────┬────────────┬────────────┬────────────┬────────────┬────────────┐
│ Backlog │ Ready │ In Progress│ Testing │ Review │ Done │
│ │ │ (WIP:3) │ (WIP:2) │ (WIP:2) │ │
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
│ブロッカー/待機事項: │
│ │
│ │
├────────────┬────────────┬────────────┬────────────┬────────────┬────────────┤
│メトリクス │今日のWIP │平均リードタイム │平均サイクルタイム │
│ │ │ │ │
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘
カンバンカードテンプレート:
┌───────────────────────────────────────┐
│ [タスクID] [優先度: 高/中/低] │
├───────────────────────────────────────┤
│ タイトル: [タスク名] │
├───────────────────────────────────────┤
│ 説明: │
│ [簡潔な説明] │
├───────────────────────────────────────┤
│ 担当者: [名前] │
├───────────────────────────────────────┤
│ 見積: [ポイント/時間] │
├───────────────────────────────────────┤
│ 開始日: [日付] 完了日: [日付] │
├───────────────────────────────────────┤
│ ブロッカー: │
│ [ブロックしている要素があれば記載] │
└───────────────────────────────────────┘
使用上のコツ:
- 仕掛品（WIP）の上限を設定し、フロー効率を高める
- ボトルネックが発生している列には注目し、改善する
- タスクのブロッカー（障害）は明示的に表示する
- リードタイム（タスクが入ってから出るまでの時間）を計測し、改善に活用する
- チームの状況に合わせて列（ステータス）を追加・変更する
- プロジェクト管理ツール（Jira, Trello, Azure DevOpsなど）でデジタルカンバンを作成するとよい
クリティカルパス法
概要: プロジェクトの最短完了時間と遅延するとプロジェクト全体が遅延する重要タスクの経路（クリティカルパス）を特定する手法
実務テンプレート:
[タスクリスト]
ID | タスク名 | 所要期間 | 先行タスク
---+-------------+----------+------------
A | 要件定義 | 5日 | -
B | 基本設計 | 10日 | A
C | DB設計 | 7日 | B
D | UI設計 | 5日 | B
E | バックエンド開発 | 15日 | C
F | フロントエンド開発 | 12日 | D
G | 単体テスト | 8日 | E, F
H | 結合テスト | 5日 | G
I | システムテスト | 7日 | H
J | リリース準備 | 3日 | I
[ネットワーク図]
(5) (10) (7) (15)
[開始] --> [A] --> [B] --> [C] --> [E]
\ /
\ /
v (5) v \
[D] --> [F] --> [G] --> [H] --> [I] --> [J] --> [終了]
(12) (8) (5) (7) (3)
クリティカルパス分析表:
┌────┬──────────────────┬──────┬─────┬─────┬─────┬─────┬─────────────┐
│タス│タスク名 │所要 │最早 │最早 │最遅 │最遅 │トータル │
│クID│ │期間 │開始 │完了 │開始 │完了 │フロート │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│A │要件定義 │5日 │0 │5 │0 │5 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│B │基本設計 │10日 │5 │15 │5 │15 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│C │DB設計 │7日 │15 │22 │15 │22 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│D │UI設計 │5日 │15 │20 │17 │22 │2 │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│E │バックエンド開発 │15日 │22 │37 │22 │37 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│F │フロントエンド開発│12日 │20 │32 │25 │37 │5 │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│G │単体テスト │8日 │37 │45 │37 │45 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│H │結合テスト │5日 │45 │50 │45 │50 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│I │システムテスト │7日 │50 │57 │50 │57 │0 (CP) │
├────┼──────────────────┼──────┼─────┼─────┼─────┼─────┼─────────────┤
│J │リリース準備 │3日 │57 │60 │57 │60 │0 (CP) │
└────┴──────────────────┴──────┴─────┴─────┴─────┴─────┴─────────────┘
クリティカルパス: A → B → C → E → G → H → I → J (合計: 60日)
使用上のコツ:
- クリティカルパス上のタスクは遅延するとプロジェクト全体が遅れるため、特に注意して管理する
- フロート（余裕時間）があるタスクは、リソース配分を調整する際の候補となる
- クリティカルパスが複数ある場合はすべて注意深く管理する
- 進捗に応じてクリティカルパスは変わる可能性があるため、定期的に再計算する
- 依存関係を正確に把握することが重要
- MSプロジェクトなどのツールを使えば自動的に計算可能
RACI表
概要: プロジェクトにおける責任と役割を明確にするマトリックス表。R（Responsible：実行責任）、A（Accountable：説明責任）、C（Consulted：相談対象）、I（Informed：報告対象）の4つの役割を定義
実務テンプレート:
┌────────────────────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│タスク/役割 │プロジェクト│システム │開発 │テスト │お客様 │
│ │マネージャー│アーキテクト│リーダー │リーダー │担当者 │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│プロジェクト計画策定 │A/R │C │C │C │I │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│要件定義 │A │C │C │ │R │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│システム設計 │A │R │C │C │I │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│コーディング │A │C │R │ │ │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│単体テスト │I │C │R │A │ │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│結合テスト │I │C │C │R/A │ │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ユーザーテスト │A │ │I │R │C │
├────────────────────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│導入・リリース │A/R │C │C │C │I │
└────────────────────────┴──────────┴──────────┴──────────┴──────────┴──────────┘
R = Responsible（実行責任者）: 作業を実行する責任
A = Accountable（説明責任者）: 最終的な承認権限と責任
C = Consulted（相談対象者）: 意思決定前に意見を求められる
I = Informed（報告対象者）: 意思決定や進捗について情報を受け取る
使用上のコツ:
- 各タスクにはただ一人のAccountable（A）を設定する
- Aの役割は委譲可能だが、責任は残ることを認識する
- RとAは同一人物が兼ねることもある
- タスクごとにR（実行責任者）は必ず1人以上指定する
- CとIは多すぎないように注意する
- プロジェクト開始時に作成し、全員で合意することが重要
- 役割の変更があれば、都度RACI表を更新し共有する
システム設計フレームワーク
UML
概要: Unified Modeling Language（統一モデリング言語）。システムの構造と振る舞いを視覚的に表現するための標準化された図法
実務テンプレート:
1. クラス図
┌───────────────────┐ ┌───────────────────┐
│ Order │ │ Customer │
├───────────────────┤ ├───────────────────┤
│ - orderId: int │ │ - customerId: int │
│ - orderDate: Date │ │ - name: String │
│ - totalAmt: double│ │ - email: String │
├───────────────────┤ ├───────────────────┤
│ + placeOrder() │ │ + register() │
│ + cancelOrder() │ │ + update() │
└─────────┬─────────┘ └─────────┬─────────┘
│ 1 │ 1
│ │
│ 0..* │ 0..*
┌─────────▼─────────┐ ┌─────────▼─────────┐
│ OrderItem │ │ Address │
├───────────────────┤ ├───────────────────┤
│ - itemId: int │ │ - addressId: int │
│ - quantity: int │ │ - street: String │
│ - price: double │ │ - city: String │
├───────────────────┤ ├───────────────────┤
│ + updateQuantity()│ │ + validate() │
└───────────────────┘ └───────────────────┘
2. シーケンス図
┌──────┐ ┌───────┐ ┌──────────┐ ┌─────────┐
│ユーザー│ │Webページ│ │コントローラ│ │データベース│
└───┬───┘ └───┬───┘ └────┬─────┘ └────┬────┘
│ │ │ │
│ ログイン要求 │ │ │
│────────────>│ │ │
│ │ ログイン情報送信│ │
│ │─────────────>│ │
│ │ │ ユーザー情報照会 │
│ │ │───────────────>│
│ │ │ │
│ │ │ ユーザー情報応答 │
│ │ │<───────────────│
│ │ ログイン結果 │ │
│ │<─────────────│ │
│ ログイン完了 │ │ │
│<────────────│ │ │
│ │ │ │
3. ユースケース図
┌──────────────────────────────────────────────┐
│ ECサイト │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ │ │ │ │
│ │ 商品を検索 │ │ カートを確認 │ │
│ │ │ │ │ │
│ └──────────────┘ └──────────────┘ │
│ ▲ ▲ │
│ │ │ │
│ │ │ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ │ │ │ │
┌─┴──┴─┐ 商品を注文 │─────>│ 支払いをする │ │
│ 顧客 │ │ │ │ │
└─┬──┬─┘ │ │ │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ │
│ │ │ │
└──────>│ 会員登録する │ │
│ │ │
└──────────────┘ │
└──────────────────────────────────────────────┘
4. 状態遷移図
┌───────────┐
│ 開始 │
└─────┬─────┘
│
▼
┌───────────┐
│ カート内 │
└─────┬─────┘
│ [注文確定]
▼
┌───────────┐ ┌───────────┐
│ キャンセル │<─────────┤ 注文確定 │
└───────────┘ └─────┬─────┘
│ [支払い完了]
▼
┌───────────┐
│ 支払い完了 │
└─────┬─────┘
│ [出荷]
▼
┌───────────┐
│ 出荷中 │
└─────┬─────┘
│ [配達完了]
▼
┌───────────┐
│ 配達完了 │
└───────────┘
5. コンポーネント図
┌────────────────────────────────────────┐
│ Webアプリケーション │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ │ │ │ │
│ │ Webフロント │◄────┤ APIサーバー │ │
│ │ │ │ │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
└─────────┼────────────────────┼─────────┘
│ │
┌─────────▼────────┐ ┌────────▼─────────┐
│ │ │ │
│ 認証サービス │ │ データベース │
│ │ │ │
└──────────────────┘ └──────────────────┘
使用上のコツ:
- UMLは13種類の図があるが、上記5種類を抑えておけば基本的な設計は表現可能
- 詳細さのレベルを適切に保ち、過剰に複雑にしない
- 必要に応じて図に説明文やノートを追加する
- プロジェクトの初期段階ではハイレベルの図から始め、設計が進むにつれて詳細化する
- チーム内で記法を統一し、表記の揺れを防ぐ
- PlantUML, draw.io, Lucidchartなどのツールを活用する
ERD
概要: Entity-Relationship Diagram（実体関連図）。データベースの構造、特にテーブル（エンティティ）間の関係を視覚的に表現する図
実務テンプレート:
┌───────────────┐ ┌───────────────┐
│ 顧客 │ │ 注文 │
├───────────────┤ ┌─┴───────────────┤
│ PK 顧客ID │<┐ │ PK 注文ID │
├───────────────┤ │ ├─────────────────┤
│ 氏名 │ │ │ FK 顧客ID │
│ メールアドレス │ └───>│ 注文日 │
│ 電話番号 │ │ 合計金額 │
│ 登録日 │ │ ステータス │
└───────────────┘ └─────────────────┘
│
│
▼
┌───────────────┐ ┌───────────────┐
│ 商品 │ │ 注文明細 │
├───────────────┤ ├───────────────┤
│ PK 商品ID │<┐ │ PK 明細ID │
├───────────────┤ │ ├───────────────┤
│ 商品名 │ │ │ FK 注文ID │
│ 説明 │ │ │ FK 商品ID │
│ 価格 │ └───>│ 数量 │
│ 在庫数 │ │ 単価 │
└───────────────┘ └───────────────┘
ER図作成チェックリスト:
□ すべてのエンティティ（テーブル）を特定
□ 各エンティティの主キー（PK）を定義
□ すべての属性（列）を列挙
□ エンティティ間の関連を特定
□ 1対1関連
□ 1対多関連
□ 多対多関連（中間テーブルに分解）
□ 外部キー（FK）を適切に設定
□ 正規化レベルの確認（第3正規形程度が一般的）
□ インデックスの検討
□ データ型の適切な選択
□ NULL許容/非許容の決定
□ デフォルト値の設定
□ 制約の定義（一意性制約、チェック制約など）
使用上のコツ:
- 業務の実態を反映したエンティティ設計を心がける
- 命名規則を統一する（例：単数形/複数形、プレフィックスなど）
- 将来的な拡張性を考慮した設計にする
- 多対多の関連は中間テーブルに分解する
- パフォーマンスに影響する可能性がある大規模テーブルは特に注意して設計する
- 非正規化が必要な場合は理由を明確にドキュメント化する
- 設計ツール（A5:SQL Mk-2, MySQL Workbench, ERDiagramなど）を活用する
DFD
概要: Data Flow Diagram（データフロー図）。システム内でのデータの流れ、処理、外部とのインタラクションを視覚的に表現する図
実務テンプレート:
レベル0 DFD（コンテキスト図）
┌──────────┐
│ │
┌─────┐ │ │ ┌───────────┐
│顧客 │──┤ ECサイト ├──│ 決済代行 │
└─────┘ │ システム │ │ サービス │
│ │ └───────────┘
┌─────┐ │ │ ┌───────────┐
│管理者├──┤ ├──│ 配送業者 │
└─────┘ │ │ └───────────┘
└──────────┘
レベル1 DFD
┌───────────┐
│ データ │
│ストレージ │
└─────┬─────┘
│
│
┌─────┐ ┌───────────┐ │ ┌───────────┐ ┌───────────┐
│ │ │ │ │ │ │ │ │
│顧客 │───>│ 1.0 │<───┘───>│ 2.0 │───>│ 3.0 │
│ │ │ 注文受付 │ │ 決済処理 │ │ 出荷処理 │
└─────┘ │ │─┐ │ │ │ │
└───────────┘ │ └───────────┘ └───────────┘
│ ▲ │
│ │ │
│ ┌─────┴─────┐ ┌─────▼─────┐
│ │ │ │ │
└──────>│ 4.0 │<───┤ 決済代行 │
│ 在庫管理 │ │ サービス │
│ │ │ │
└───────────┘ └───────────┘
使用上のコツ:
- DFDの基本要素を理解する：プロセス（丸または角丸）、データフロー（矢印）、データストア（平行線または開いた矩形）、外部エンティティ（矩形）
- 複数のレベルで階層的に作成する
- レベル0：システム全体とその環境との関係（コンテキスト図）
- レベル1：主要な機能とデータフロー
- レベル2以降：さらに詳細な処理とデータフロー
- プロセスには明確な名前と番号を付ける（例：1.0 注文受付）
- データフローには具体的に流れるデータの内容を記述する
- プロセスは入力と出力を必ず持つようにする（データの変換を表現）
- 同じレベルのDFDでは、親プロセスのすべての入出力を子プロセスで表現する（バランシング）
- 矛盾や不整合がないかチェックする
アーキテクチャパターン
概要: システム設計の標準的な構造パターン。ソフトウェアの基本構造と構成要素間の関係を定義する
実務テンプレート:
1. レイヤードアーキテクチャ（3層アーキテクチャ）
┌───────────────────────────────────┐
│ プレゼンテーション層 │
│ (UIコンポーネント、画面制御) │
└───────────────┬───────────────────┘
│
┌───────────────┴───────────────────┐
│ ビジネスロジック層 │
│ (業務ルール、ワークフロー) │
└───────────────┬───────────────────┘
│
┌───────────────┴───────────────────┐
│ データアクセス層 │
│ (DB操作、永続化処理) │
└───────────────────────────────────┘
2. MVCアーキテクチャ
┌────────────┐
│ │
更新 ─────┤ モデル │
│ (Model) │
│ │
└─────┬──────┘
│ 通知
│
┌─────▼──────┐ ┌────────────┐
│ │ │ │
表示 ─────┤ ビュー │◄────┤ コントローラ│◄─── 操作
│ (View) │ │(Controller)│
│ │ │ │
└────────────┘ └────────────┘
3. マイクロサービスアーキテクチャ
┌─────────────────────────────────────────────────────────┐
│ API Gateway │
└───────┬─────────────┬──────────────┬──────────────┬─────┘
│ │ │ │
┌───────▼────┐ ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐
│ │ │ │ │ │ │ │
│ ユーザー │ │ 商品 │ │ 注文 │ │ 決済 │
│ サービス │ │ サービス │ │ サービス │ │ サービス │
│ │ │ │ │ │ │ │
└───────┬────┘ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘
│ │ │ │
┌───────▼────┐ ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐
│ │ │ │ │ │ │ │
│ ユーザーDB │ │ 商品DB │ │ 注文DB │ │ 決済DB │
│ │ │ │ │ │ │ │
└────────────┘ └────────────┘ └────────────┘ └────────────┘
4. クリーンアーキテクチャ
┌───────────────────────────────────┐
│ エンティティ │
│ (ビジネスルール、ドメインモデル) │
└─────────────────┬─────────────────┘
│
┌─────────────────▼─────────────────┐
│ ユースケース │
│ (アプリケーション固有のビジネスルール) │
└─────────────────┬─────────────────┘
│
┌─────────────────▼─────────────────┐
│ インターフェースアダプター │
│ (コントローラ、ゲートウェイ、プレゼンター) │
└─────────────────┬─────────────────┘
│
┌─────────────────▼─────────────────┐
│ フレームワーク │
│ (DB、Web、UI、デバイス、外部システム) │
└───────────────────────────────────┘
使用上のコツ:
- レイヤードアーキテクチャは理解しやすく、多くのシステムで採用される基本パターン
- MVCは特にWeb/UIアプリケーションで有効
- マイクロサービスは大規模システムや継続的デリバリーが必要な場合に適している
- クリーンアーキテクチャは変更に強い設計を実現したい場合に有効
- どのパターンも「関心の分離」と「依存関係の方向性の制御」が重要
- システムの規模や要件に応じて適切なパターンを選択する
- 複数のパターンを組み合わせて利用することも多い
4+1ビュー
概要: システムアーキテクチャを「論理ビュー」「プロセスビュー」「開発ビュー」「物理ビュー」+「ユースケースビュー」の5つの視点で記述するフレームワーク
実務テンプレート:
1. 論理ビュー（Logical View）
- 記述内容: システムの機能要件を実現するためのオブジェクトモデル
- 表現方法: クラス図、オブジェクト図
- 例:
┌───────────────────┐ ┌───────────────────┐
│ OrderService │ │ CustomerService │
├───────────────────┤ ├───────────────────┤
│ + placeOrder() │─────>│ + validateCustomer() │
│ + cancelOrder() │ │ + getProfile() │
└───────────────────┘ └───────────────────┘
2. プロセスビュー（Process View）
- 記述内容: 並行処理、分散処理、同期・非同期処理などの動的側面
- 表現方法: シーケンス図、アクティビティ図
- 例:
┌──────┐ ┌────────────┐ ┌────────────┐
│Client │ │OrderService│ │PaymentService│
└───┬───┘ └─────┬──────┘ └──────┬─────┘
│ 注文リクエスト │ │
│──────────────>│ │
│ │ 支払い処理 │
│ │─────────────────>│
│ │ 支払い結果 │
│ │<─────────────────│
│ 注文結果 │ │
│<──────────────│ │
3. 開発ビュー（Development View）
- 記述内容: ソフトウェアモジュールの構成、パッケージ、レイヤー構造
- 表現方法: パッケージ図、コンポーネント図
- 例:
┌────────────────────────────────────────────────────┐
│ アプリケーション層 │
├──────────┬───────────────┬─────────────┬───────────┤
│ 顧客管理 │ 商品管理 │ 注文管理 │ 決済管理 │
└──────────┴───────────────┴─────────────┴───────────┘
│
┌────────────────────┴───────────────────────────────┐
│ インフラ層 │
├──────────┬───────────────┬─────────────┬───────────┤
│ データベース│ メッセージング │ キャッシュ │ 外部API │
└──────────┴───────────────┴─────────────┴───────────┘
4. 物理ビュー（Physical View）
- 記述内容: システムのデプロイメント構成、ハードウェア構成
- 表現方法: デプロイメント図、ネットワーク図
- 例:
┌─────────────┐ ┌─────────────┐
│ Webサーバー │──HTTP──→│ アプリサーバー│
└─────────────┘ └──────┬──────┘
│
┌─────▼──────┐
│ データベース │
└────────────┘
5. ユースケースビュー（+1 View）
- 記述内容: 他の4つのビューをつなぐ、システムのユースケース
- 表現方法: ユースケース図、ユースケース記述
- 例:
┌─────────────────────────────────────────┐
│ ECサイトシステム │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 注文を行う │ │ 支払いを行う │ │
│ └─────────────┘ └─────────────┘ │
│ ▲ ▲ │
│ │ │ │
│ └─────┬─────────────┘ │
│ │ │
┌─────────┐ │ │
│ 顧客 │─────┘ │
└─────────┘ │
使用上のコツ:
- アーキテクチャ文書は1つのビューだけでなく、複数のビューで構成する
- ビューごとに異なるステークホルダーの関心事に対応する
- 論理ビューは機能要件を、プロセスビューと物理ビューは非機能要件を表現する
- 開発ビューは開発チームが、物理ビューはインフラチームが主に参照する
- すべてのビューで同じ用語や命名規則を使用し、一貫性を保つ
- 大規模システムでは、各ビューをさらに詳細なサブビューに分解する
ビジネス分析フレームワーク
SWOT分析
概要: Strengths（強み）、Weaknesses（弱み）、Opportunities（機会）、Threats（脅威）の4つの視点から事業や組織を分析するフレームワーク
実務テンプレート:
┌─────────────────────────────┬─────────────────────────────┐
│ 【Strengths: 強み】 │ 【Weaknesses: 弱み】 │
│ 内部要因・プラス │ 内部要因・マイナス │
│ │ │
│ ・ │ ・ │
│ ・ │ ・ │
│ ・ │ ・ │
│ ・ │ ・ │
│ │ │
├─────────────────────────────┼─────────────────────────────┤
│ 【Opportunities: 機会】 │ 【Threats: 脅威】 │
│ 外部要因・プラス │ 外部要因・マイナス │
│ │ │
│ ・ │ ・ │
│ ・ │ ・ │
│ ・ │ ・ │
│ ・ │ ・ │
│ │ │
└─────────────────────────────┴─────────────────────────────┘
SWOT戦略マトリックス（クロスSWOT）:
┌───────────────┬────────────────────────────┬────────────────────────────┐
│ │ Strengths（強み） │ Weaknesses（弱み） │
├───────────────┼────────────────────────────┼────────────────────────────┤
│Opportunities │【積極戦略】 │【改善戦略】 │
│（機会） │強みを活かして機会を捉える │弱みを克服して機会を捉える │
│ │ │ │
│ │・ │・ │
│ │・ │・ │
├───────────────┼────────────────────────────┼────────────────────────────┤
│Threats │【差別化戦略】 │【防衛戦略】 │
│（脅威） │強みを活かして脅威に対抗する│弱みと脅威の最悪の事態を回避│
│ │ │ │
│ │・ │・ │
│ │・ │・ │
└───────────────┴────────────────────────────┴────────────────────────────┘
使用上のコツ:
- 各要素は「具体的」「測定可能」「証拠に基づく」ものを記載する
- 主観的な意見ではなく、客観的な事実に基づいて分析する
- 強みと弱みは「競合と比較して」評価する
- 機会と脅威は外部環境の変化（市場・技術・規制など）に着目する
- 単なる現状分析にとどまらず、クロスSWOTで戦略立案につなげる
- IT部門/システム開発でもSWOT分析は有効（例：新技術導入の判断）
- 定期的に見直し、環境変化に応じて更新する
3C分析
概要: Customer（顧客）、Competitor（競合）、Company（自社）の3つの視点から分析し、事業戦略を立案するフレームワーク
実務テンプレート:
┌───────────────────────────────────────────────────────────────┐
│ 【Customer: 顧客】 │
│ │
│ ■顧客セグメント: │
│ ・ │
│ ・ │
│ │
│ ■顧客ニーズ: │
│ ・ │
│ ・ │
│ │
│ ■購買行動: │
│ ・ │
│ ・ │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐
│ 【Competitor: 競合】 │
│ │
│ ■主要競合: │
│ ・ │
│ ・ │
│ │
│ ■競合の強み: │
│ ・ │
│ ・ │
│ │
│ ■競合の弱み: │
│ ・ │
│ ・ │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐
│ 【Company: 自社】 │
│ │
│ ■自社リソース: │
│ ・ │
│ ・ │
│ │
│ ■自社の強み: │
│ ・ │
│ ・ │
│ │
│ ■自社の弱み: │
│ ・ │
│ ・ │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐
│ 【戦略の方向性】 │
│ │
│ ■差別化ポイント: │
│ ・ │
│ ・ │
│ │
│ ■ターゲット顧客: │
│ ・ │
│ ・ │
│ │
│ ■具体的戦略: │
│ ・ │
│ ・ │
└───────────────────────────────────────────────────────────────┘
使用上のコツ:
- 顧客分析では定量的なデータ（市場規模、成長率など）と定性的なデータ（ニーズ、不満点など）の両方を収集する
- 競合分析では直接競合だけでなく、間接競合や潜在競合も考慮する
- 自社分析では、客観的な視点で自社の強みと弱みを評価する
- 3つのCを個別に分析した後、それらの関係性を考慮して戦略を立案する
- システム開発においては、開発する製品・サービスの市場適合性を評価する際に活用できる
- 定期的に見直し、変化する環境に合わせて更新する
5Forces
概要: マイケル・ポーターが提唱した、業界の競争環境を5つの力（新規参入の脅威、代替品の脅威、買い手の交渉力、売り手の交渉力、競争企業間の敵対関係）から分析するフレームワーク
実務テンプレート:
┌─────────────────┐
│ 新規参入の脅威 │
│ │
│ ・ │
│ ・ │
│ ・ │
└────────┬───────┘
│
▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 売り手の交渉力 │ │ 競争企業間の │ │ 買い手の交渉力 │
│ │───>│ 敵対関係 │<───│ │
│ ・ │ │ │ │ ・ │
│ ・ │ │ ・ │ │ ・ │
│ ・ │ │ ・ │ │ ・ │
└─────────────────┘ └────────┬───────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ 代替品の脅威 │
│ │
│ ・ │
│ ・ │
│ ・ │
└─────────────────┘
5Forcesチェックリスト:
1. 新規参入の脅威
□ 市場への参入障壁は高いか？
□ 規模の経済性が働くか？
□ ブランドの差別化の程度は？
□ 資本投資の必要性は？
□ 規制や法的障壁は？
2. 代替品の脅威
□ 代替品・代替サービスの存在は？
□ 代替品への切り替えコストは？
□ 代替品の価格対性能比は？
□ 技術革新による代替の可能性は？
3. 買い手の交渉力
□ 買い手の集中度は？
□ 購入量/規模は？
□ 製品の差別化度合いは？
□ 買い手の切り替えコストは？
□ 後方統合の可能性は？
4. 売り手の交渉力
□ 供給企業の集中度は？
□ 代替供給源の有無は？
□ 投入物の差別化度合いは？
□ 前方統合の可能性は？
□ 売り手の切り替えコストは？
5. 競争企業間の敵対関係
□ 競合企業の数と集中度は？
□ 業界の成長率は？
□ 固定費と退出障壁は？
□ 製品の差別化度合いは？
□ 競合他社の多様性は？
使用上のコツ:
- 各要因を「高い/中程度/低い」などで評価し、業界の魅力度を総合的に判断する
- 5つの力の相対的な強さを理解し、最も影響が大きいものに戦略的に対応する
- 時間の経過とともに変化する力を継続的に監視する
- ITシステム開発の文脈では、システムが支援すべきビジネス領域の競争環境を理解するために活用する
- 特に新規事業やシステム企画の段階で有効
- 業界全体だけでなく、特定の製品/サービスセグメントに焦点を当てて分析することも可能
ビジネスモデルキャンバス
概要: ビジネスモデルを9つの要素（顧客セグメント、価値提案、チャネル、顧客関係、収益の流れ、主なリソース、主な活動、主なパートナー、コスト構造）で可視化するフレームワーク
実務テンプレート:
┌────────────────┬────────────────┬────────────────┬────────────────┬────────────────┐
│ 8. パートナー │ 7. 主な活動 │ 2. 価値提案 │ 4. 顧客関係 │ 1. 顧客セグメント│
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ ├────────────────┤ ├────────────────┤ │
│ │ 6. 主なリソース │ │ 3. チャネル │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
├────────────────┴────────────────┼────────────────┴────────────────┴────────────────┤
│ 9. コスト構造 │ 5. 収益の流れ │
│ │ │
│ │ │
│ │ │
└─────────────────────────────────┴─────────────────────────────────────────────────┘
各要素の主な検討ポイント:
1. 顧客セグメント（Customer Segments）
- 誰に価値を提供するのか？
- 最も重要な顧客は誰か？
2. 価値提案（Value Propositions）
- 顧客にどんな価値を提供するのか？
- どのような問題を解決するのか？
- どのニーズを満たすのか？
3. チャネル（Channels）
- どのように顧客に製品/サービスを届けるか？
- どのチャネルが最も効果的か？
4. 顧客関係（Customer Relationships）
- 各顧客セグメントとどのような関係を構築するか？
- 既に構築している関係は何か？
- コストと統合方法は？
5. 収益の流れ（Revenue Streams）
- 顧客は何に対してお金を払うのか？
- 現在どのように支払っているか？
- 価格設定メカニズムは？
6. 主なリソース（Key Resources）
- ビジネスに必要な重要なリソースは？
- 物理的、知的、人的、財務的リソースは？
7. 主な活動（Key Activities）
- ビジネスモデルに必要な重要な活動は？
- 価値提案、チャネル、顧客関係、収益に必要な活動は？
8. パートナー（Key Partners）
- 主要なパートナーと供給者は誰か？
- パートナーから得る主要リソースは？
- パートナーが行う主要活動は？
9. コスト構造（Cost Structure）
- 最も重要なコストは？
- 最も高価なリソースと活動は？
- ビジネスモデルはコスト主導型か価値主導型か？
使用上のコツ:
- 大きな紙やボードに描き、付箋を使って各要素を検討すると効果的
- ビジネスモデル全体を俯瞰し、各要素間の整合性を確認する
- 既存ビジネスの分析だけでなく、新規事業やピボット検討にも活用できる
- 複数のバリエーションを作成し比較検討する
- 定期的に見直し、変化する環境に適応させる
- IT部門では、提供するシステムやサービスのビジネスモデルを検討する際に活用
- ユーザー企業のビジネスモデルを理解することで、より適切なシステム要件を定義できる
ジョブ理論
概要: クレイトン・クリステンセンが提唱した、顧客が「雇う」ジョブ（達成したい進歩）に注目してイノベーションを考えるフレームワーク
実務テンプレート:
ジョブステートメント
状況: 【 】
↓
動機: 【 】
↓
望む結果:【 】
「〜〜なとき（状況）に、〜〜したい（動機）ので、〜〜できる方法を探している（望む結果）」
ジョブ分析シート
┌───────────────────────────────────────────────────────────────┐
│ 【ジョブの概要】 │
│ │
│ ジョブステートメント: │
│ 「 」│
│ │
├───────────────────────────────────────────────────────────────┤
│ 【ジョブの多層構造】 │
│ │
│ ■機能的側面: │
│ ・ │
│ ・ │
│ │
│ ■感情的側面: │
│ ・ │
│ ・ │
│ │
│ ■社会的側面: │
│ ・ │
│ ・ │
├───────────────────────────────────────────────────────────────┤
│ 【競合分析】 │
│ │
│ ■現在の解決策: │
│ ・ │
│ ・ │
│ │
│ ■不満点: │
│ ・ │
│ ・ │
├───────────────────────────────────────────────────────────────┤
│ 【価値提案】 │
│ │
│ ■提供できる解決策: │
│ ・ │
│ ・ │
│ │
│ ■差別化ポイント: │
│ ・ │
│ ・ │
└───────────────────────────────────────────────────────────────┘
使用上のコツ:
- 製品やサービスの機能ではなく、顧客が達成したい「ジョブ」に焦点を当てる
- ジョブには、機能的側面（実用的な目的）、感情的側面（感情的な目的）、社会的側面（他者からどう見られたいか）がある
- 顧客インタビューや観察を通じて、真のジョブを理解する
- 「なぜそれを使うのか？」を繰り返し問いかけることで、表面的なニーズの背後にある本質的なジョブを発見する
- 競合は同じカテゴリの製品だけでなく、同じジョブを果たす異なる解決策も含める
- IT開発では、システムの機能要件を定義する前にユーザーのジョブを理解することで、より価値のあるソリューションを設計できる
- UXデザインとの親和性が高く、ユーザーストーリーをジョブの視点で書くことも効果的
AIプロジェクト向けフレームワーク
MLOps
概要: 機械学習モデルの開発から運用までのライフサイクルを効率的に管理するためのプラクティス集
実務テンプレート:
MLOpsマチュリティモデル
┌────────────────────┬────────────────────┬────────────────────┬────────────────────┐
│レベル0: 手動プロセス│レベル1: MLパイプライン│レベル2: CI/CD自動化 │レベル3: 完全自動化 │
│ │自動化 │ │ │
├────────────────────┼────────────────────┼────────────────────┼────────────────────┤
│・手動でのデータ処理 │・データ処理の自動化 │・CI/CDパイプライン │・全プロセスの自動化 │
│・手動でのモデル学習 │・モデル学習の自動化 │・テスト自動化 │・A/Bテスト自動化 │
│・手動でのデプロイ │・手動デプロイ │・自動デプロイ │・カナリアリリース │
│・モニタリングなし │・基本的モニタリング │・高度なモニタリング │・自己最適化 │
└────────────────────┴────────────────────┴────────────────────┴────────────────────┘
MLOpsパイプラインのコンポーネント
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ データ収集 │→│ データ処理 │→│ モデル開発 │→│ モデル評価 │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │ │
↓ ↓ ↓ ↓
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ コード管理 │ │ コンポーネント │ │ CI/CDパイプ │ │ モデルレジストリ│
└───────────────┘ │ バージョニング │ │ ライン │ └───────────────┘
└───────────────┘ └───────────────┘
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ モデルデプロイ │→│ モデルサービング│→│ モニタリング │→│ フィードバック │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │ │
↓ ↓ ↓ ↓
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 機能ストア │ │ モデル説明可能 │ │ データドリフト │ │ ヒューマンイン│
└───────────────┘ │ 性 │ │ 検出 │ │ ザループ │
└───────────────┘ └───────────────┘ └───────────────┘
MLOpsツールチェックリスト
□ データパイプライン管理
□ データ収集・取得ツール
□ データバージョニング (DVC, Delta Lake)
□ データ品質チェック
□ 特徴量ストア (Feature Store)
□ ML実験管理
□ 実験追跡ツール (MLflow, Weights & Biases)
□ ハイパーパラメータ最適化 (Optuna)
□ バージョン管理 (Git)
□ モデル管理
□ モデルレジストリ (MLflow Model Registry)
□ モデルパッケージング
□ モデルドキュメント化
□ モデル説明可能性 (SHAP, LIME)
□ CI/CD
□ テスト自動化 (pytest)
□ ビルドパイプライン (Jenkins, GitHub Actions)
□ デプロイ自動化 (ArgoCD, GitOps)
□ モデルデプロイ・サービング
□ コンテナ化 (Docker)
□ オーケストレーション (Kubernetes)
□ 推論サーバー (TensorFlow Serving, Triton)
□ エッジデプロイ (TensorFlow Lite, ONNX)
□ モニタリング
□ モデルパフォーマンス (精度, レイテンシ)
□ データドリフト検出
□ 説明可能性モニタリング
□ アラート設定
□ ガバナンス
□ モデル系譜追跡 (Lineage)
□ コンプライアンス管理
□ アクセス制御
□ 監査証跡
使用上のコツ:
- 小規模から始め、徐々に成熟度を高めていく
- すべてのコンポーネントをいきなり導入するのではなく、プロジェクトの課題に応じて優先順位をつける
- データパイプラインとモデル管理は早期に自動化すると効果が高い
- 再現性を確保するため、環境、データ、コードのバージョン管理を徹底する
- モニタリングは本番環境での異常を早期発見するために重要
- 組織の既存のDevOpsプラクティスとの統合を考慮する
- チームのスキルセットに合ったツールを選定する
- ドキュメンテーションを自動化し、モデルカードなどの形式で残す
RAI（責任あるAI）
概要: AI技術の開発・運用において、倫理的、法的、社会的影響を考慮し、責任ある利用を実現するためのフレームワーク
実務テンプレート:
RAIリスクアセスメントシート
┌───────────────────────────────────────────────────────────────┐
│ 【プロジェクト概要】 │
│ │
│ プロジェクト名: │
│ 目的: │
│ 利用するAI技術: │
│ 対象ユーザー/ステークホルダー: │
│ │
├───────────────────────────────────────────────────────────────┤
│ 【リスク評価】 │
│ │
│ ■公平性・バイアス │
│ リスク: │
│ 影響を受ける可能性のあるグループ: │
│ 対策: │
│ │
│ ■説明可能性・透明性 │
│ リスク: │
│ 影響: │
│ 対策: │
│ │
│ ■プライバシー・セキュリティ │
│ リスク: │
│ 影響: │
│ 対策: │
│ │
│ ■頑健性・安全性 │
│ リスク: │
│ 影響: │
│ 対策: │
│ │
│ ■人間の自律性・意思決定 │
│ リスク: │
│ 影響: │
│ 対策: │
│ │
│ ■環境・社会的影響 │
│ リスク: │
│ 影響: │
│ 対策: │
├───────────────────────────────────────────────────────────────┤
│ 【総合評価】 │
│ │
│ リスクレベル: □低 □中 □高 │
│ │
│ 推奨アクション: │
│ │
│ 次回レビュー日: │
│ │
│ 承認者: 日付: │
└───────────────────────────────────────────────────────────────┘
RAI実装チェックリスト
□ ガバナンス体制
□ RAI原則と方針の策定
□ 役割と責任の明確化
□ レビュープロセスの確立
□ インシデント対応手順の策定
□ データガバナンス
□ データ収集の同意確認
□ データ品質チェック
□ バイアス検出と軽減
□ データセキュリティ対策
□ プライバシー保護対策
□ モデル開発
□ バイアス評価の実施
□ フェアネスメトリクスの追跡
□ 敵対的テストの実施
□ ロバストネステスト
□ 説明可能性の確保
□ デプロイと運用
□ A/Bテストで公平性確認
□ 決定境界のモニタリング
□ 人間によるレビュープロセス
□ ドリフト検出メカニズム
□ 異常検知と対応
□ ユーザー体験
□ 適切な開示と説明
□ ユーザーコントロールの提供
□ フィードバックメカニズム
□ オプトアウトの選択肢
□ ドキュメンテーション
□ モデルカードの作成
□ データシートの作成
□ リスク評価ドキュメント
□ 監査証跡の保存
使用上のコツ:
- プロジェクト初期段階からRAIを考慮し、後付けではなく設計に組み込む
- リスク評価は定期的に見直し、プロジェクトの進行や環境変化に応じて更新する
- 特に影響を受けやすいグループ（マイノリティなど）への影響を慎重に評価する
- 技術的対策だけでなく、プロセスとガバナンスの両面から取り組む
- 専門分野に特化したガイドライン（医療AIなど）がある場合は参照する
- ステークホルダーとのコミュニケーションを重視し、透明性を確保する
- AI倫理の専門家や法務部門と連携する
- インシデント発生時の対応プランを事前に準備しておく
プロンプトエンジニアリングパターン
概要: 大規模言語モデル（LLM）に効果的に指示を出し、望ましい出力を得るためのテクニックやパターン
実務テンプレート:
基本プロンプトテンプレート
[役割]: あなたは[専門性/役割]として振る舞ってください。
[背景]: [関連する背景情報や文脈を提供]
[タスク]: [具体的な指示や達成してほしいことを明確に説明]
[形式]: 回答は[構造/形式/長さ]で提供してください。
[制約]: [考慮すべき制約条件や避けるべきこと]
[例]: 以下は期待する出力の例です：[具体例]
[評価基準]: あなたの回答は[基準]に基づいて評価されます。
[追加情報]: [参考になる追加リソースや情報]
主要プロンプトパターン
1. チェーン・オブ・ソート (Chain-of-Thought)
問題：[具体的な問題や課題]
ステップバイステップで考えてください。
1. まず、[問題の分解や初期分析]
2. 次に、[中間ステップや推論]
3. 最後に、[最終的な解決策や回答]
各ステップで何を考えているか説明し、最終的な答えを導き出してください。
2. ゼロショット・CoT
問題：[具体的な問題や課題]
一歩一歩考えていきましょう。
3. ロールプレイ
あなたは[専門家/役割]です。[専門分野]で[X年]の経験があります。
以下の[課題/問題]について、あなたの専門知識を活かして回答してください。
[課題/問題の詳細]
4. フューショット学習
以下は[タスクの説明]の例です。
例1:
入力: [入力例1]
出力: [出力例1]
例2:
入力: [入力例2]
出力: [出力例2]
例3:
入力: [入力例3]
出力: [出力例3]
これらの例に基づいて、以下の入力に対する出力を生成してください。
入力: [実際の入力]
5. セルフコンシストンシー
問題：[具体的な問題]
この問題を解くために、異なるアプローチで3回考えてみてください。
それぞれのアプローチを詳細に説明し、最終的に最も信頼できると思われる答えを選んでください。
6. 一般的な制約指定
[具体的なタスク]を実行する際、以下の制約を守ってください：
- [制約1]
- [制約2]
- [制約3]
[タスクの追加詳細]
使用上のコツ:
- 具体的で明確な指示を出す（曖昧さを避ける）
- 複雑なタスクは小さなステップに分解する
- タスクに応じて適切なプロンプトパターンを選択する
- フューショット（少数例示）を活用して期待する出力形式を示す
- 重要な制約条件は明示的に記載する
- 適切な専門的役割を設定して回答の質を高める
- プロンプトは繰り返し改良し、結果を評価する
- システム的に利用する場合は、入出力を厳密に定義してAPI利用する
- 機密情報や個人情報をプロンプトに含めないよう注意する
- プロンプトのバージョン管理と文書化を行う
AI導入ROI計算フレームワーク
概要: AI技術の導入における投資対効果（ROI）を体系的に評価し、意思決定を支援するフレームワーク
実務テンプレート:
AI ROI評価シート
┌───────────────────────────────────────────────────────────────┐
│ 【プロジェクト概要】 │
│ │
│ プロジェクト名: │
│ AI活用領域: │
│ 目的: │
│ │
├───────────────────────────────────────────────────────────────┤
│ 【コスト（投資）項目】 │
│ │
│ ■初期コスト: │
│ □ データ収集/クレンジング : ¥ │
│ □ モデル開発/調整 : ¥ │
│ □ インフラ構築 : ¥ │
│ □ 統合/カスタマイズ : ¥ │
│ □ 初期トレーニング : ¥ │
│ │
│ ■ランニングコスト（年間）: │
│ □ クラウド/コンピューティング費用 : ¥ │
│ □ 保守/運用費 : ¥ │
│ □ モデル更新/再トレーニング : ¥ │
│ □ 継続的トレーニング : ¥ │
│ │
│ ■間接コスト: │
│ □ 業務プロセス変更 : ¥ │
│ □ リスク対策費 : ¥ │
│ │
│ 総コスト（初年度）: ¥ │
│ 総コスト（X年間）: ¥ │
│ │
├───────────────────────────────────────────────────────────────┤
│ 【ベネフィット（効果）項目】 │
│ │
│ ■直接的効果（定量）: │
│ □ 作業時間削減: [時間/月] × [人件費/時間] = ¥/月 │
│ □ エラー削減: [影響額/件] × [削減件数/月] = ¥/月 │
│ □ 生産性向上: [産出増加] × [単価] = ¥/月 │
│ □ コスト削減: ¥/月 │
│ □ 売上増加: ¥/月 │
│ │
│ ■間接的効果（準定量）: │
│ □ 顧客満足度向上: [スコア変化] ⟹ [収益影響額]: ¥ │
│ □ 従業員満足度向上: [スコア変化] ⟹ [収益影響額]: ¥ │
│ □ 意思決定速度向上: [時間短縮] ⟹ [収益影響額]: ¥ │
│ │
│ ■定性的効果: │
│ □ [効果1] : 重要度 (高/中/低) │
│ □ [効果2] : 重要度 (高/中/低) │
│ │
│ 総ベネフィット（年間）: ¥ │
│ 総ベネフィット（X年間）: ¥ │
│ │
├───────────────────────────────────────────────────────────────┤
│ 【ROI計算】 │
│ │
│ シンプルROI（%）: (総ベネフィット - 総コスト) / 総コスト × 100 │
│ = (¥ - ¥ ) / ¥ × 100 │
│ = % │
│ │
│ 回収期間: 総初期コスト ÷ 年間純ベネフィット │
│ = ¥ ÷ ¥ /年 │
│ = 年 ヶ月 │
│ │
│ 正味現在価値(NPV): ¥ │
│ 内部収益率(IRR): % │
│ │
├───────────────────────────────────────────────────────────────┤
│ 【リスク評価】 │
│ │
│ ■技術的リスク: │
│ □ [リスク1]: 確率(高/中/低) × 影響度(高/中/低) = 評価(高/中/低)│
│ □ [リスク2]: 確率(高/中/低) × 影響度(高/中/低) = 評価(高/中/低)│
│ │
│ ■ビジネスリスク: │
│ □ [リスク1]: 確率(高/中/低) × 影響度(高/中/低) = 評価(高/中/低)│
│ □ [リスク2]: 確率(高/中/低) × 影響度(高/中/低) = 評価(高/中/低)│
│ │
│ リスク調整後ROI: % │
│ │
├───────────────────────────────────────────────────────────────┤
│ 【結論と推奨】 │
│ │
│ □ 推奨: [実施/保留/見送り] │
│ │
│ □ 根拠: │
│ │
│ □ 次のステップ: │
│ │
└───────────────────────────────────────────────────────────────┘
使用上のコツ:
- AIプロジェクトの価値は直接的な効果だけでなく、間接的効果や定性的効果も含めて評価する
- 初期コストだけでなく、継続的なメンテナンスやモデル更新のコストも考慮する
- 効果の数値化が難しい場合は、類似事例や業界ベンチマークを参考にする
- 段階的アプローチ（PoC→パイロット→本格導入）で投資リスクを抑える
- 基準値（ベースライン）を明確にし、改善効果を測定できるようにする
- リスク要因を洗い出し、ROI計算に反映させる
- 定量化できない効果についても、戦略的重要性を評価し意思決定に反映させる
- 経時的にROIを再評価し、必要に応じて方向転換する
- AI特有の不確実性を考慮し、保守的な見積もりを基本とする
- プロジェクト初期から成功指標（KPI）を定義しておく