学習用の教材です。重要な判断では一次資料や専門家を確認してください。
TRADING COMPANY CORE SKILLS · 012
システム開発
事業課題を、使われ続ける安全なデジタル能力へ変える
社会人版位置づけと到達点
高校生でもわかる説明へシステム開発で最低限知ることを、具体例から読みます。
最初に押さえる3点
- 誰のどんな仕事を改善するかを先に決める。
- 機能だけでなく安全・速さ・障害時の対応を決める。
- 小さく確認し、承認して公開し、運用でも改善する。
全体方法論
高校生でもわかる説明へ段階 1
課題を定義
課題を定義
→
段階 2
要求を選別
要求を選別
→
段階 3
設計
設計
→
段階 4
小さく開発
小さく開発
→
段階 5
品質確認
品質確認
→
段階 6
安全にリリース
安全にリリース
→
段階 7
運用・改善
運用・改善
ゲートの考え方：各ステップで、次へ進む条件・追加検証・停止条件を明文化する。資料完成ではなく、意思決定の質を成果とする。
テーマ 01
課題・要求定義
高校生でもわかる説明へユーザーと事業の課題を、機能・非機能・制約・受入基準へ変換する。
具体的な進め方
- 解決策より課題を先に書く
- Must/Should/Couldで優先する
- 性能・可用性・セキュリティを明示する
必須成果物
- PRD
- User Story
- 受入基準
代表KPI
要求変更率価値仮説未確定要件典型的な失敗
- 要望を全部機能化する
実務の問い
- 課題・要求定義の最大の不確実性は何か
- その不確実性はどの証拠で判定するか
- 結果を価格・計画・契約・行動のどこへ反映するか
テーマ 02
アーキテクチャ・データ
高校生でもわかる説明へ拡張性、保守性、コスト、安全性のトレードオフを設計する。
具体的な進め方
- 境界と責任を明確にする
- データ所有者と品質を定義する
- Build/Buy/SaaSを比較する
必須成果物
- 構成図
- データモデル
- ADR
代表KPI
技術負債クラウド単価データ品質典型的な失敗
- 最新技術を目的化する
実務の問い
- アーキテクチャ・データの最大の不確実性は何か
- その不確実性はどの証拠で判定するか
- 結果を価格・計画・契約・行動のどこへ反映するか
テーマ 03
開発マネジメント
高校生でもわかる説明へBacklog、Sprint、依存関係、リスクを管理し、小さく価値を届ける。
具体的な進め方
- 成果物でなくOutcomeを見る
- WIPを制限する
- Definition of Doneを揃える
必須成果物
- Roadmap
- Backlog
- Release Plan
代表KPI
Lead TimeThroughput予測精度典型的な失敗
- 進捗率90%を長期間報告する
実務の問い
- 開発マネジメントの最大の不確実性は何か
- その不確実性はどの証拠で判定するか
- 結果を価格・計画・契約・行動のどこへ反映するか
テーマ 04
品質・テスト
高校生でもわかる説明へ単体、結合、E2E、性能、セキュリティ、受入をリスクベースで設計する。
具体的な進め方
- 重要業務からテストする
- 自動化と探索的テストを使い分ける
- 本番相当データを安全に準備する
必須成果物
- Test Plan
- Traceability
- 不具合分析
代表KPI
欠陥流出率自動化率復旧時間典型的な失敗
- テスト件数を品質とみなす
実務の問い
- 品質・テストの最大の不確実性は何か
- その不確実性はどの証拠で判定するか
- 結果を価格・計画・契約・行動のどこへ反映するか
テーマ 05
DevSecOps・リリース
高校生でもわかる説明へCI/CD、権限、秘密、脆弱性、監視、ロールバックを標準化する。
具体的な進め方
- 小さな変更を頻繁に出す
- 承認と自動統制を組み合わせる
- Feature Flagを使う
必須成果物
- Pipeline
- Runbook
- Release Checklist
代表KPI
変更失敗率デプロイ頻度MTTR典型的な失敗
- 本番作業を個人技にする
実務の問い
- DevSecOps・リリースの最大の不確実性は何か
- その不確実性はどの証拠で判定するか
- 結果を価格・計画・契約・行動のどこへ反映するか
テーマ 06
運用・プロダクト改善
高校生でもわかる説明へ公開後も利用・障害・費用を見ます。SLO（サービス品質の目標）を置く場合は測り方と期間を決めます。すべての小さなサイトで同じ運用体制を必要とするわけではありません。
同じ具体例で判断の流れを読む
高校生でもわかる説明へ仮想の受注入力例です。1日20件、1件5分だった仕事を、同じ作業範囲で3分にする目標とします。1日40分、20営業日なら月800分（13時間20分）の短縮です。実測結果ではありません。
入力 → 内容確認 → 権限を持つ担当が確定 → 記録を保存 → エラー時は担当へ通知
他人の注文を操作できないこと、入力ミスを修正できること、保存できなければ完了表示をしないことも受入条件にします。導入費用・再確認の手間を含めて効果を実測し、短縮時間だけを金額の利益と扱いません。
成果物とKPIの運用
高校生でもわかる説明へ次の成果物・指標は運用例です。目的と意思決定の期限に合わせて、使う項目・定義・確認頻度を決めます。
| # | 成果物 | 確認指標 |
|---|---|---|
| 1 | PRD | 要求変更率 |
| 2 | User Story | 価値仮説 |
| 3 | 受入基準 | 未確定要件 |
| 4 | 構成図 | 技術負債 |
| 5 | データモデル | クラウド単価 |
| 6 | ADR | データ品質 |
| 7 | Roadmap | Lead Time |
| 8 | Backlog | Throughput |
| 9 | Release Plan | 予測精度 |
| 10 | Test Plan | 欠陥流出率 |
| 11 | Traceability | 自動化率 |
| 12 | 不具合分析 | 復旧時間 |
注意：KPIは報告のためではなく、異常を早く発見し、行動を変えるために使う。指標ごとに定義・データ源・責任者・閾値を置く。
短時間で読む順番
高校生でもわかる説明へ- 入口で最低限の3点をつかむ。
- 同じ具体例で、前提と判断の流れを読む。
- 必要な節へ戻る。難しければ右上から高校生版へ移る。