上流工程スキル習得ガイド - SE・PG向け
Upstream Engineering Skills Guide for SE/PG
目次 / Table of Contents
はじめに
なぜ上流工程を学ぶのか / Why Learn Upstream Processes
基本設計より上流工程の重要性:
- プロジェクト成功の80%は上流で決まる - 要件定義の質がプロジェクト全体の成否を左右
- 技術的負債の予防 - 適切な技術選定により、後工程での手戻りを最小化
- キャリアパス - 上流工程スキルはSE・アーキテクトへの必須要件
本ガイドの対象者:
- コーディング経験3年以上のPG
- 基本設計経験のあるSE
- 上流工程への関与を目指すエンジニア
要件定義の理解と実践
1. 要件定義とは何か / What is Requirements Definition
定義と目的
要件定義 = ビジネス課題を解決するために、システムが「何を」実現すべきかを明確化するプロセス
目的:
- ステークホルダーの期待を明確化
- 開発の成功基準を定義
- プロジェクトスコープの確定
要件の種類
機能要件 (Functional Requirements):
- ユーザーが実行できる操作
- システムが提供する機能
- データの入出力
非機能要件 (Non-Functional Requirements):
- 性能要件: レスポンスタイム、スループット
- 可用性: 稼働率、MTBF/MTTR
- セキュリティ: 認証、暗号化、アクセス制御
- 保守性: 拡張性、テスタビリティ
- 運用性: バックアップ、監視、ログ
2. 日々の実践ポイント / Daily Practice Points
ビジネス理解を深める習慣
現場のプロセスを観察する:
✅ 日々の実践チェックリスト:
- [ ] ユーザー部門の業務フローを理解しているか?
- [ ] なぜこの機能が必要なのか、ビジネス上の理由を説明できるか?
- [ ] この機能の使用頻度・優先度を把握しているか?
- [ ] 代替案を3つ以上考えたか?
例: ファイル管理システムの場合
❌ 悪い要件定義:
「ファイルをアップロードできるようにする」
✅ 良い要件定義:
「コンテンツ管理者が、1日平均500ファイル(最大1000ファイル)を
並行アップロード可能とし、各ファイルのバージョン履歴を
3年間保持できるようにする。
アップロード完了までの時間は95パーセンタイルで10秒以内。」
理由:
- 定量的な指標(500/1000ファイル、3年間、10秒)
- 利用者の役割(コンテンツ管理者)
- 非機能要件(性能、保存期間)が明確
「なぜ」を5回繰り返す習慣
5 Whys Technique:
例: S3統合の要件定義
Q1: なぜS3を使うのか?
A1: ファイルを保存するため
Q2: なぜローカルストレージではダメなのか?
A2: 容量が足りない
Q3: なぜ容量が足りないのか?
A3: 動画ファイルなど大容量コンテンツが増えている
Q4: なぜ大容量コンテンツが増えているのか?
A4: マーケティング部門がプロモーション動画を多用する戦略に変更
Q5: なぜその戦略になったのか?
A5: モバイルユーザーが増加し、動画視聴率が3倍になった
→ 真の要件:
「モバイルユーザー向け動画コンテンツの配信基盤構築」
「ストリーミング最適化」「CDN連携」も検討すべき
3. 要件を引き出すテクニック / Requirements Elicitation Techniques
ステークホルダーインタビュー
質問の型:
## 現状把握 (As-Is Analysis)
- 「現在はどのように作業していますか?」
- 「1日に何回、何件処理しますか?」
- 「どこで困っていますか?」
## 理想の把握 (To-Be Vision)
- 「理想的にはどうなっていてほしいですか?」
- 「どういう状態になれば成功ですか?」
- 「3年後、このシステムはどう進化していてほしいですか?」
## 制約条件 (Constraints)
- 「予算の上限は?」
- 「いつまでに必要ですか?」
- 「法規制やコンプライアンス要件は?」
## 優先順位 (Priority)
- 「これがないと業務が止まりますか?」
- 「Must Have / Nice to Have を分けると?」
ユーザーストーリー作成
テンプレート:
As a [役割],
I want [機能],
So that [ビジネス価値].
受け入れ条件:
- Given [前提条件]
- When [アクション]
- Then [期待結果]
実例:
### ユーザーストーリー: ファイル一括リバート
As a コンテンツ管理者,
I want 複数ファイルを指定バージョンに一括リバート,
So that 誤った更新を迅速に元に戻せる.
受け入れ条件:
- Given 1000ファイルのリバート指示
- When リバート実行
- Then 5分以内に全ファイルがリバート完了
- And 処理状況がリアルタイムで表示される
- And エラー発生時も他ファイルの処理は継続
技術的制約:
- Virtual Threads使用によるスケーラビリティ確保
- データベースのトランザクション分離レベル検討
- S3のAPI Rate Limit考慮
技術選定の考え方
1. 技術選定の基本フレームワーク
選定プロセス
評価軸 (Decision Matrix)
技術選定の評価項目:
| 評価軸 | 重要度 | 技術A | 技術B | 技術C |
|--------|--------|-------|-------|-------|
| 性能要件適合 | 高 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| スケーラビリティ | 高 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 学習コスト | 中 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| コミュニティ | 中 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| ライセンス | 低 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 既存資産活用 | 中 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| 運用コスト | 高 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
総合スコア: 技術A=89点, 技術B=78点, 技術C=84点
2. 日々の技術研究習慣 / Daily Technical Research Habits
情報収集ルーチン
毎日30分の技術情報収集:
## Morning Routine (朝30分)
- [ ] Hacker News / Tech Feeds チェック
- [ ] GitHub Trending 確認
- [ ] 自分の技術領域のブログ1本読む
## Weekly Deep Dive (週1回1時間)
- [ ] 気になる技術のドキュメント精読
- [ ] 簡単なPOC(Proof of Concept)作成
- [ ] 学習メモをMarkdownで記録
## Monthly Review (月1回)
- [ ] 新技術の評価レポート作成
- [ ] チーム内で技術共有会開催
技術の深掘り方法
3層学習アプローチ:
Level 1: What (何ができるか)
- 公式ドキュメントのQuick Start
- 簡単なサンプル実装
- 所要時間: 2-3時間
Level 2: How (どう動くか)
- アーキテクチャ理解
- 内部実装の調査
- 所要時間: 1-2日
Level 3: Why (なぜこの設計か)
- 設計思想の理解
- 代替案との比較
- 所要時間: 1週間
例: Java Virtual Threads学習
Level 1: コード例で基本動作確認
Level 2: キャリアスレッドとの関係理解
Level 3: Project Loomの設計思想、従来のThreadPoolとの比較
3. 実践的な技術選定例
Case Study: AAプロジェクトでの並列処理技術選定
背景:
- 要件: 1000ファイルの並列処理
- 既存: Java 11 + ThreadPool
- 課題: スレッド数制約、コンテキストスイッチコスト
選定プロセス:
## 候補技術
1. Java Virtual Threads (Java 21+)
2. CompletableFuture + ForkJoinPool
3. Reactive Streams (Project Reactor)
4. Kotlin Coroutines
## 評価
### Virtual Threads
✅ メリット:
- 軽量: 100万スレッド作成可能
- 既存コード移行容易: Thread APIそのまま
- デバッグ容易: スタックトレース明瞭
❌ デメリット:
- Java 21必須(移行コスト)
- CPU-boundタスクでは優位性小
POC結果:
- 1000ファイル処理: 45秒 → 12秒 (62%改善)
- メモリ使用量: 2GB → 800MB
### CompletableFuture
✅ メリット:
- Java 8から使用可能
- 既存資産活用
❌ デメリット:
- コード複雑化
- エラーハンドリング困難
## 意思決定
選択: Virtual Threads
理由:
1. 性能要件を満たす(目標10秒以内)
2. コード可読性が高い
3. Java 25移行は既定路線
4. 将来的な拡張性(Structured Concurrency導入可能)
リスク対策:
- Java 25移行を先行実施
- 段階的移行(まず非クリティカルな処理から)
ADR (Architecture Decision Record) 作成
テンプレート:
# ADR-001: Virtual Threads採用
## Status
採用 (2025-01-29)
## Context
ファイル一括処理の性能改善が必要。
現状: 1000ファイル処理に45秒
要件: 10秒以内
## Decision
Java Virtual Threadsを並列処理基盤として採用。
## Consequences
### Positive
- 性能目標達成(12秒)
- コード可読性向上
- スケーラビリティ確保
### Negative
- Java 25移行が必須
- 学習コスト(チーム全体)
### Risks
- 本番環境での予期せぬ問題
→ 段階的ロールアウトで対応
日々の心がけと習慣
1. ビジネス視点の養成
ビジネスKPI理解
日々のチェックポイント:
自分が開発する機能について:
📊 ビジネスインパクト
- [ ] この機能で何人のユーザーが恩恵を受けるか?
- [ ] この機能でどれくらいの時間削減/コスト削減?
- [ ] この機能がないとどんな業務が止まるか?
💰 コスト意識
- [ ] 開発工数 vs ビジネスバリュー
- [ ] 運用コスト(インフラ、保守)
- [ ] 技術的負債の将来コスト
📈 成功指標
- [ ] KPI定義(ユーザー満足度、利用率など)
- [ ] 測定方法(ログ、アンケート)
実例: ファイルリバート機能
❌ エンジニア視点のみ:
「効率的なアルゴリズムでリバート処理を実装」
✅ ビジネス視点を含む:
「誤更新時の復旧時間を60分→5分に短縮することで、
年間推定240時間の業務停止を防止。
売上機会損失を年間XXX万円削減。」
2. コミュニケーション能力の向上
非技術者への説明力
技術的内容を平易に説明するテクニック:
## KISS原則 (Keep It Simple, Stupid)
❌ 技術用語そのまま:
「Virtual Threadsを使って非同期I/O処理を
ノンブロッキングで実装します」
✅ 平易な説明:
「処理を待っている間に別の仕事ができる仕組みを使って、
1000ファイルを同時に処理できるようにします。
これで処理時間が1/3になります。」
## メタファー活用
技術: データベースインデックス
説明: 「本の索引のようなものです。
目次から直接ページを開けるので、
最初から全部読む必要がありません。」
技術: キャッシュ
説明: 「よく使うものを手元に置いておく感じです。
毎回倉庫に取りに行かなくて済むので速いです。」
ドキュメンテーション習慣
日々のドキュメント作成:
## 毎日作成すべきドキュメント
### 技術調査メモ
- 調査した技術
- なぜ調査したか
- 分かったこと/分からなかったこと
- 次のアクション
### 設計判断の記録
- 何を決めたか
- なぜその選択をしたか
- 代替案は何だったか
- リスクと対策
### トラブルシューティングログ
- 何が起きたか
- 原因は何か
- どう解決したか
- 再発防止策
ドキュメントテンプレート例:
# 技術調査: [技術名]
## 調査理由
- ビジネス要件: XXX
- 技術的課題: YYY
## 調査内容
- 公式ドキュメント
- サンプル実装
- パフォーマンステスト
## 結論
- 採用可否: ⭕/❌
- 理由: ...
- 次のアクション: ...
## 参考資料
- [リンク1]
- [リンク2]
3. 継続的学習の仕組み化
パーソナル学習ロードマップ
3ヶ月スプリント学習計画:
## Q1 2025: アーキテクチャ設計強化
### Month 1: ドメイン駆動設計(DDD)
- Week 1-2: エリック・エヴァンス本精読
- Week 3: 集約・エンティティ設計演習
- Week 4: プロジェクトでDDD適用検討
### Month 2: クラウドアーキテクチャ
- Week 1-2: AWS Well-Architected Framework学習
- Week 3: S3/CloudFront設計パターン
- Week 4: コスト最適化設計
### Month 3: セキュリティ設計
- Week 1-2: OWASP Top 10対策
- Week 3: 認証・認可設計パターン
- Week 4: セキュリティレビュープロセス構築
成果物:
- 各月の学習メモ(Markdown)
- 実装サンプル
- チーム共有会資料
学ぶべきスキルセット
1. 技術スキル
アーキテクチャパターン
必須知識:
## レイヤードアーキテクチャ
- Presentation Layer
- Application Layer
- Domain Layer
- Infrastructure Layer
Spring Bootでの実装例:
/controller (Presentation)
/service (Application)
/domain (Domain)
/repository (Infrastructure)
## マイクロサービスパターン
- API Gateway
- Service Mesh
- Event-Driven Architecture
- CQRS (Command Query Responsibility Segregation)
## データアーキテクチャ
- RDBMS vs NoSQL選定基準
- キャッシュ戦略
- データレプリケーション
非機能要件の設計
性能設計:
## スループット設計
要件例: 1000 requests/sec
計算:
- 1 request = 100ms処理時間
- 必要並列度 = 1000 * 0.1 = 100
- Virtual Threads: 100並列は余裕
- ThreadPool: 100スレッド確保必要
ボトルネック分析:
1. CPU: プロファイラで確認
2. I/O: データベース・ネットワーク
3. メモリ: GCログ分析
## 可用性設計
目標: 99.9% (月間ダウンタイム43分以内)
対策:
- 冗長化: アプリケーション・DBマルチAZ
- フェイルオーバー: 自動切り替え
- 監視: ヘルスチェック + アラート
セキュリティ設計
基本原則:
## 認証・認可
認証 (Authentication): "誰か"を確認
- JWT (JSON Web Token)
- OAuth 2.0
- SAML
認可 (Authorization): "何ができるか"を確認
- RBAC (Role-Based Access Control)
- ABAC (Attribute-Based Access Control)
実装例:
@PreAuthorize("hasRole('ADMIN')")
public void adminOnlyMethod() { ... }
## 入力検証
必須チェック:
- SQLインジェクション対策
- XSS対策
- CSRF対策
- ファイルアップロード検証
Spring Bootでの実装:
@Valid @RequestBody UserDto user
2. ビジネススキル
要求分析スキル
ビジネスモデル理解:
## Business Model Canvas活用
顧客セグメント → 価値提案 → チャネル
↓
収益の流れ ← コスト構造 ← 主要活動
質問例:
- 顧客の課題は何か?
- 現在の解決方法は?
- なぜ新しいシステムが必要か?
- ROI(投資対効果)は?
プロジェクトマネジメント基礎
工数見積もり:
## 三点見積もり法
楽観値(O): 全て順調な場合 = 20時間
悲観値(P): 最悪の場合 = 80時間
最頻値(M): 通常の場合 = 40時間
期待値(E) = (O + 4M + P) / 6
= (20 + 160 + 80) / 6
= 43.3時間
バッファ20%追加 → 52時間
## WBS (Work Breakdown Structure)
要件定義
├─ ビジネス要件整理 (8h)
├─ ユーザーインタビュー (16h)
├─ 要件仕様書作成 (24h)
└─ レビュー・承認 (4h)
合計: 52h
3. ソフトスキル
ファシリテーション
会議運営:
## 効果的な要件ヒアリング会議
事前準備:
- [ ] アジェンダ送付
- [ ] 参加者の役割確認
- [ ] 質問リスト準備
会議中:
- [ ] タイムキーピング
- [ ] 全員の意見を引き出す
- [ ] 決定事項の明確化
- [ ] Next Actionの合意
事後:
- [ ] 議事録共有(24時間以内)
- [ ] 決定事項のトラッキング
交渉・調整力
ステークホルダー調整:
## 利害対立の調整例
状況:
- 営業部門: 「3ヶ月で全機能欲しい」
- 開発: 「6ヶ月必要」
調整アプローチ:
1. 優先順位付け
- Must Have機能の洗い出し
- 段階リリース提案
2. トレードオフ明示
- 品質 vs 速度
- 機能 vs 納期
3. Win-Win案の提示
- Phase 1: コア機能 (3ヶ月)
- Phase 2: 拡張機能 (+3ヶ月)
- Early Access β版 (2ヶ月)
実践的アプローチ
1. 小さく始める
現在のプロジェクトで実践
今日から始められること:
## Level 1: 観察と質問
- [ ] 今実装中の機能のビジネス価値を上司に聞く
- [ ] この機能を使うユーザーの1日の業務フローを調べる
- [ ] 非機能要件(性能、セキュリティ)を確認する
## Level 2: ドキュメント化
- [ ] 技術選定理由をADR形式で記録
- [ ] 設計判断の背景をコメントに残す
- [ ] トラブル解決の手順書作成
## Level 3: 提案
- [ ] パフォーマンス改善提案
- [ ] セキュリティ改善提案
- [ ] アーキテクチャリファクタリング提案
プロジェクトでの実践例:
## 実装中: ファイルリバート機能
### 上流工程視点での確認
1. ビジネス要件確認
Q: リバートはどのくらいの頻度で発生?
A: 週に2-3回、誤更新時
2. 非機能要件確認
Q: 1000ファイルのリバート時間要件は?
A: 業務停止時間最小化、10分以内希望
3. 技術選定
候補: Virtual Threads vs CompletableFuture
選択: Virtual Threads
理由: 性能・可読性・Java 25移行計画
4. ADR作成
→ チームで共有、レビュー
2. メンターを見つける
学びの加速
メンターとの関わり方:
## 効果的な質問の仕方
❌ 悪い質問:
「要件定義ってどうやるんですか?」
→ 抽象的すぎて答えにくい
✅ 良い質問:
「ファイルリバート機能の要件定義で、
非機能要件(性能)の目標値をどう決めたら良いですか?
現状、1000ファイルで45秒かかっています。」
→ 具体的で、コンテキストが明確
## メンターレビューの活用
コードレビュー依頼時:
- 「この技術選定の理由は〇〇です。
他の選択肢との比較観点で不足はありますか?」
設計レビュー依頼時:
- 「非機能要件でカバーできていない観点はありますか?」
3. コミュニティ参加
知見の共有と吸収
社内外コミュニティ:
## 社内勉強会
- 月1回の技術共有会で発表
- テーマ例: 「Virtual Threads導入事例」
- 準備で理解が深まる
## 外部コミュニティ
- JJUG (日本Javaユーザーグループ)
- AWS User Group
- 技術カンファレンス参加
## オンライン発信
- Qiita/Zenn記事執筆
- GitHub OSS貢献
- 技術ブログ
よくある落とし穴と対策
1. 上流工程の罠
Over-Engineering
問題:
❌ やりがちなミス:
「将来の拡張性を考えて、マイクロサービスで
設計しよう」
現状: ユーザー10人、リクエスト10/日
リスク:
- 複雑性の増大
- 運用コスト増
- 開発速度低下
対策:
✅ YAGNI原則 (You Aren't Gonna Need It)
現在の要件に集中:
- ユーザー10人 → モノリス十分
- スケール必要になったらリファクタリング
判断基準:
- 6ヶ月以内に必要になる? → 実装
- 「いつか」必要? → 実装しない
要件の曖昧性放置
問題:
曖昧な要件例:
「高速に処理する」
「使いやすくする」
「セキュアにする」
→ 後工程で認識齟齬、手戻り
対策:
定量化・具体化:
❌「高速に処理」
✅「95パーセンタイルで5秒以内」
❌「使いやすく」
✅「3クリック以内で目的の操作完了」
「新人が2時間の研修で操作可能」
❌「セキュア」
✅「OWASP Top 10対策実施」
「全通信TLS 1.3以上」
2. コミュニケーションの罠
専門用語の乱用
問題:
非技術者への説明:
「CQRSパターンでEvent Sourcingを実装し、
結果整合性を確保します」
→ 相手は理解できない、信頼を失う
対策:
レイヤー別の説明:
経営層向け:
「システムの変更を記録する仕組みで、
万が一の時に過去の状態に戻せます。
監査要件にも対応できます。」
ユーザー部門向け:
「操作履歴が全部残るので、
いつでも前の状態を確認できます。」
技術者向け:
「CQRSパターンで... (詳細説明)」
一方的な提案
問題:
「この技術を使うべきです!」
→ 理由不明、押し付けがましい
対策:
選択肢提示型:
「要件を満たす方法として3つ検討しました。
Option 1: Virtual Threads
メリット: 性能最高、コード明快
デメリット: Java 25必須
Option 2: CompletableFuture
メリット: 既存Java 11で可能
デメリット: コード複雑
Option 3: 外部サービス利用
メリット: 開発不要
デメリット: ランニングコスト
推奨はOption 1ですが、Java移行スケジュール次第で
Option 2も選択可能です。ご判断いただけますか?」
アクションプラン / Action Plan
30日間チャレンジ
Week 1: 現状把握
Day 1-2:
- [ ] 現在のプロジェクトのビジネス要件を上司に確認
- [ ] ステークホルダーマップ作成
Day 3-4:
- [ ] 非機能要件のドキュメント確認
- [ ] 不明点をリストアップ
Day 5-7:
- [ ] 技術選定理由の整理
- [ ] 簡易ADR作成
Week 2: 小さな実践
Day 8-10:
- [ ] 実装中機能の要件をユーザーストーリー形式で書く
- [ ] レビュー依頼
Day 11-14:
- [ ] 技術調査メモを1日1本作成
- [ ] チーム内共有
Week 3: 提案準備
Day 15-17:
- [ ] 改善提案の候補リストアップ
- [ ] ビジネスインパクト試算
Day 18-21:
- [ ] 提案資料作成
- [ ] メンターレビュー
Week 4: 発表と振り返り
Day 22-24:
- [ ] 提案プレゼン
- [ ] フィードバック収集
Day 25-28:
- [ ] 30日間の学習ログ整理
- [ ] 次の30日計画策定
Day 29-30:
- [ ] チーム内共有会
- [ ] 改善点の洗い出し
まとめ / Summary
上流工程スキル習得の要点
1. ビジネス視点の獲得
- 技術は手段、ビジネス価値が目的
- 常に「なぜ」を問う習慣
- 定量的な効果測定
2. 技術選定の体系化
- 評価軸の明確化
- POCによる検証
- ADRでの記録
3. 継続的な学習
- 毎日30分の情報収集
- 3層学習アプローチ
- ドキュメント化による定着
4. コミュニケーション力
- 相手に合わせた説明
- 選択肢の提示
- 合意形成のスキル
次のステップ
今日から始める3つのこと:
1. 現在の開発タスクのビジネス価値を確認
→ 上司・PMに質問
2. 技術選定の理由を簡単にメモ
→ ADR形式で記録開始
3. 1つ新しい技術を深掘り学習
→ 30分/日の時間確保
参考資料 / References
書籍
- 『リーン開発の本質』- ソフトウェア開発の上流工程の考え方
- 『エリック・エヴァンスのドメイン駆動設計』- ビジネスロジックの設計
- 『Clean Architecture』- アーキテクチャ設計の原則
- 『ソフトウェアアーキテクチャの基礎』- 体系的なアーキテクチャ学習
オンラインリソース
- AWS Well-Architected Framework
- Microsoft Azure Architecture Center
- Martin Fowler's Blog (https://martinfowler.com/)
- ThoughtWorks Technology Radar
コミュニティ
- JJUG (日本Javaユーザーグループ)
- DDD Community Japan
- AWS User Group Japan
tst