ストーリー
田
田中VPoE
スコープ設計、言語戦略、アーキテクチャ標準、品質標準 — すべてを統合して「技術標準ドキュメント」の初版を設計してもらう
あなた
Step 1の棚卸し結果も踏まえて、TaskFlow社向けの標準を作るんですね
あ
田
田中VPoE
そうだ。ただし「机上の空論」にしないでくれ。標準を作っても現場が受け入れなければ意味がない。棚卸しで明らかになった課題を解決しつつ、エンジニアが「これなら納得できる」と思えるバランスを目指せ
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | 技術標準ドキュメント設計 |
| 想定時間 | 90分 |
| 成果物 | 技術標準ドキュメント（言語戦略 + アーキテクチャ標準 + 品質標準） |
| 対象組織 | TaskFlow株式会社（Step 1の演習と同じ） |
Mission 1: 言語・フレームワーク戦略を策定する
要件
TaskFlow社の棚卸し結果（言語7種、FW6種）を踏まえ、以下を策定してください。
- 言語ポートフォリオ（Primary / Secondary / Specialist / Legacy の分類と根拠）
- 用途別マッピング（各用途での推奨言語・フレームワーク）
- 移行計画の概要（Hold/Legacy技術からの移行パス）
解答例
言語ポートフォリオ
| 分類 | 言語 | 根拠 |
|---|---|---|
| Primary | TypeScript | フロントエンド全体 + バックエンドの一部。エコシステム最大、採用容易 |
| Primary | Go | 高パフォーマンスAPI。既に2チームで実績。採用市場も拡大中 |
| Secondary | Python | データパイプライン専用。ライブラリ群が不可欠 |
| Specialist | Kotlin / Swift | モバイルネイティブ専用 |
| Legacy | Java | 課金サービスのみ。新規採用禁止、TypeScript/Goへの移行を計画 |
| Legacy | Node.js (Express) | 通知・連携サービスのみ。Go/TypeScript(NestJS)への移行を計画 |
用途別マッピング
| 用途 | 推奨言語 | 推奨フレームワーク |
|---|---|---|
| Webフロントエンド | TypeScript | React + Next.js |
| バックエンドAPI（高負荷） | Go | Echo + gRPC-Go |
| バックエンドAPI（標準） | TypeScript | NestJS |
| データパイプライン | Python 3.11+ | Airflow + pandas |
| モバイル | Kotlin / Swift | Jetpack Compose / SwiftUI |
| インフラツール | Go | 標準ライブラリ |
Mission 2: アーキテクチャ標準を設計する
要件
TaskFlow社のサービスアーキテクチャ標準を設計してください。
- アーキテクチャ原則（5つ以上。各原則に「なぜ必要か」の根拠を付記）
- API設計規約（バージョニング、エラーレスポンス、認証方式）
- サービス構造テンプレート（推奨ディレクトリ構造）
解答例
アーキテクチャ原則
| 原則 | 内容 | 根拠 | レベル |
|---|---|---|---|
| APIファースト | サービス間は必ずAPI経由 | 棚卸しで直接DB参照が2件発見された。疎結合を確保 | Must |
| データ所有権 | サービスは自身のDBのみ操作 | 課金サービスがユーザーDBに直接アクセスしている問題を解消 | Must |
| 環境非依存 | 設定は環境変数で注入 | 検索チームのサービスがハードコードされた接続先を持つ | Must |
| オブザーバビリティ | 構造化ログ+メトリクス+トレース | 監視ツールがDatadog/CloudWatchで分裂している問題の解消 | Must |
| ヘキサゴナル設計 | 新規サービスはポート&アダプタ | テスタビリティ向上、インフラ依存の分離 | Should |
エラーレスポンス標準
{
"type": "https://taskflow.example.com/errors/TFL-VAL-001",
"title": "Validation Error",
"status": 400,
"detail": "project_name は3文字以上64文字以下で入力してください",
"instance": "/v1/projects",
"error_code": "TFL-VAL-001",
"trace_id": "abc123def456"
}Mission 3: 品質標準を設計する
要件
TaskFlow社の品質標準を設計してください。
- テスト品質基準（カバレッジ目標、テスト種別ごとの基準）
- CI/CDパイプラインの品質ゲート（PRマージの条件）
- セキュリティチェックリスト（自動化すべきチェック項目）
解答例
テスト品質基準
| 指標 | 最低基準（Must） | 推奨値（Should） | 対象 |
|---|---|---|---|
| ユニットテストカバレッジ | 60% | 80% | 全サービス |
| ビジネスロジック層カバレッジ | 80% | 90% | domain/usecase |
| E2Eテスト | クリティカルパス3本以上 | 主要シナリオ10本以上 | プロダクト全体 |
| テスト実行時間 | 10分以内 | 5分以内 | CIパイプライン |
CI/CD品質ゲート
| ゲート | 条件 | ブロック |
|---|---|---|
| ビルド | コンパイル成功 | マージ不可 |
| テスト | 全テスト通過 | マージ不可 |
| カバレッジ | 60%以上（差分は80%以上） | マージ不可 |
| リンター | ESLint / golangci-lint エラーゼロ | マージ不可 |
| セキュリティ | Critical CVE ゼロ | マージ不可 |
| シークレット | 機密情報検出ゼロ | マージ不可 |
| レビュー | 1名以上のApprove | マージ不可 |
セキュリティチェックリスト
| チェック | タイミング | ツール | 自動化 |
|---|---|---|---|
| 依存関係脆弱性 | PR / 日次 | Trivy | 自動 |
| SAST | PR | Semgrep | 自動 |
| シークレット検出 | pre-commit / PR | gitleaks | 自動 |
| コンテナスキャン | ビルド時 | Trivy | 自動 |
| ライセンスチェック | PR | license-checker | 自動 |
| DAST | ステージング（週次） | OWASP ZAP | 半自動 |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| 言語戦略の妥当性 | 棚卸し結果を踏まえた合理的なポートフォリオ設計 |
| 移行計画 | Legacy技術からの移行パスが明示されている |
| アーキテクチャ原則 | 原則の根拠が組織の課題と紐づいている |
| 品質基準の具体性 | 数値目標が設定されている |
| セキュリティ | 自動化すべきチェックが網羅されている |
| バランス | Must/Should/Mayが適切に使い分けられている |
| 実現可能性 | 現状から段階的に移行できる計画になっている |
推定所要時間: 90分