第1章　Product Requirements Document

1-1　Whatを書くPRD

• チーム開発の難しさ
  • チーム参加者の職種の多様さ
  • コミュニケーションの難しさ
  • 異なる認識によるブレ
  • 合意形成が遅れることによる弊害
• PRDとはプロダクトへの要求が書かれた文書
  • プロダクトへの要求を明確にする
  • 関係者間の認識を統一する
  • プロダクトの品質を向上させる
  • 後で振り返ることができる
• PRDと似た文書
  • プレスリリース
  • インセプションデッキ
  • 基本設計書と外部設計書

1-2　PRDに記載すべき内容

• 決まった章立てで書く
  • PRDの全体像を把握しやすくなる
  • チームメンバー間での合意形成がしやすくなる
  • PRDの改訂や更新がしやすくなる
• 代表的な章立て
  • 「なぜ開発するのか（Why）」を含めてよいか
  • 「概要」の章
  • 「背景」の章
  • 「製品原則」の章
  • 「対象ユーザー」の章
  • 「ユースケース」の章
  • 「市場分析」の章
  • 「競合分析」の章
  • 「機能要求」の章
  • 「その他の技術的要求」の章
  • 「スコープ」の章
  • 「KPI」の章
  • 「リリーススケジュールおよびマイルストーン」の章
  • 「マーケティング計画」の章

1-3　運用時の注意点

• PRDの書き進め方
  • 企画立案者によるドラフト版の執筆
  • マーケティングに関する執筆
  • 機能に関する執筆
  • 進め方に関する執筆
• PRDを書く単位
  • 既存のPRDを更新する方式
  • 新規にPRDを作成していく方式

1-4　まとめ

第2章　Design Doc

2-1　Design Docとは

• コードレビューの限界
• 書くべきか，書かざるべきか
• 書くタイミング
• 何を使って書くか
• ウォーターフォール開発の設計書との比較

2-2　Design Docの構成

• 構成の基本方針
• タイトル
• 目次
• 目的セクション
• 背景セクション
• 設計の概要セクション
  • 重要な要素：モジュール，データモデル，クラス，APIなど
  • 設計の基本的なアイディア
  • 簡略化したシーケンスやデータフロー
• 設計の詳細セクション
  • 設計の説明の細分化
  • 代替案の比較
  • APIなどの一覧
  • 使い方の例示
• 計画セクション
• その他の関心事セクション
• Design Docのメタデータ

2-3　運用上の注意点

• 短いフィードバックサイクルを心がける
• タスクごとに使い捨てる
• ドキュメントへのリンクを活用する
• Design Docの共通認識を持つ
• Design Doc以外の選択肢を持つ

2-4　まとめ

第3章　ブランチ・リリース戦略

3-1　現代のソフトウェア開発におけるブランチ・リリース戦略の重要性

3-2　CI/CD（継続的インテグレーション，継続的デリバリー）

• CI/CDとは
  • DevOpsとの関係
  • 代表的なCIの選択肢
  • 代表的なCDの選択肢
  • デプロイ環境
• CI/CD実践のための考え方

3-3　ブランチ戦略

• ブランチの種類と役割の定義
  • mainブランチ
  • developブランチ
  • featureブランチ
  • releaseブランチ
• 代表的なブランチモデルの特徴と比較
  • GitFlow
  • GitLab Flow
  • GitHub Flow
  • Trunk Based Development
  • Stacked Diffs
• CI/CDとの関係
  • GitFlow
  • GitLab Flow
  • GitHub Flow
  • Trunk Based Development
• featureブランチの扱い
• releaseブランチの扱い
• ケーススタディ：モバイルアプリのブランチ間オートマージ

3-4　リリースサイクル戦略

• 技術ドメインごとのリリースサイクル戦略
  • バックエンドのリリース
  • Webフロントエンドのリリース
  • モバイルアプリのリリース
• 最近のリリース戦略の傾向
  • 任意のタイミングでの頻繁なリリース
  • 定期的なリリースサイクル
• ケーススタディ：モバイルアプリのリリースサイクルアップデート

3-5　リポジトリ戦略

• Polyrepo
• Monorepo
• 選択にあたっての論点
  • 分散管理と集中管理
  • 依存関係の解決
  • アクセス制御とセキュリティ対策
• ケーススタディ：Monorepoベースの開発体験

3-6　フィーチャーフラグの活用

• フィーチャーフラグの実装
  • 静的または動的なフィーチャーフラグ
  • 自前のフィーチャーフラグシステム
  • サードパーティのフィーチャーフラグシステム
  • フィーチャーフラグのクリーンアップ
• フィーチャーフラグの用途
  • 実装中の機能のガード
  • A/Bテスト
  • キルスイッチ
  • 特定のユーザーグループに向けた機能のロールアウト
  • パーセンテージベースのロールアウト
  • ベータリリース
• ブランチ戦略との関連性

3-7　まとめ

3-8　参考文献

第4章　リアーキテクトにおけるテスト戦略

4-1　リアーキテクトにおけるテスト

• 検証と妥当性確認
  • 仕様の把握およびその背景に対する理解を深める
  • 要件を満たしているか，ステークホルダーの期待に沿うか
• 限られた開発期間におけるテスト
  • 選択的テスト手法による開発期間の有効活用
  • リグレッションテストの活用

4-2　リアーキテクトにおけるテスト戦略例

• リアーキテクトにおけるテスト戦略
• 各工程詳細
  • テスト計画〜テスト設計
  • 機能ごとの優先度算出
  • 優先度に基づくテスト分析の繰り返しとテスト設計への反映
  • テスト実装〜テスト実行
• リアーキテクトにおけるテストの課題への対応

4-3　ケーススタディ：出前館アプリリアーキテクトにおけるテスト

• 出前館におけるソフトウェア開発
  • プロダクトマネジメント
  • 開発プロセス
• 実践結果
  • 2023年5月〜　既存アプリへの機能追加
  • 2023年6月　テスト対象の優先度算出
  • 2023年7月〜8月　優先度に基づくテスト分析の繰り返し
  • 2023年9月〜　テスト実行
  • 2023年11月　不具合の収束と段階的リリースの実施
• 注意点

4-4　まとめ

4-5　参考文献

第5章　実践エンジニア組織づくり

5-1　なぜエンジニア組織を作ることになったか

• 筆者がやることになった経緯
• なぜ社内で開発したいのか
• 社員として採用する必要はあるのか
• メガベンチャーから転職したらエンジニアが10人と少しの会社
• 社内でサービス開発ができるようになるには何をすればよいか

5-2　兎にも角にも採用

• エンジニアフレンドリーな会社にするために
  • 専門職向けに等級・評価・報酬制度をつくる
  • 給与設計をする
  • 採用ページの作成
• 中途採用と新卒採用
  • 中途採用
  • 新卒採用
  • 魅惑の未経験者採用
• エンジニアだけ増えてもよくない

5-3　定着と育成

• オンボーディングは大事
  • ブートキャンプチーム
• 定着のためにできそうなこと
  • やりたそうな仕事を渡す
  • 新しいことをしている
  • 自分よりすごい人がいる
• 育成について
  • 技術書を読みやすく。自己研鑽だけに頼らない
  • 入社時の選書
  • 実は優秀な人は勝手に育ってくれる（そして羽ばたいていく）

5-4　開発と運用どっちもやる

• 「実装だけをする開発組織」からの脱却
• 運用支援ツールの導入
• 技術的負債の返済は専任チームでやるべきか
• DevOps／SRE／プラットフォームエンジニアリング

5-5　チームで動き，スケールさせる

• なぜ少人数チームを単位にするか，なぜチームの大きさはピザ２枚か
• いわゆる「大規模アジャイル」をいくつか
• フィーチャーチームかコンポーネントチームか
• アーキテクチャと組織構造，コンウェイと逆コンウェイの話
• 全貌は誰が見るか。分割統治をしすぎると……
• コミュニケーションは大事。エスパーではない

5-6　まとめ

第6章　エンジニアリングイネーブルメント

6-1　エンジニアリングイネーブルメントとは

• エンジニアリングイネーブルメントが目指す姿
• エンジニアリングイネーブルメントが必要な理由

6-2　能力向上と成果向上

• 能力向上と成果向上のためにチームを分化

6-3　エンジニア職以外でのイネーブルメントの活動

6-4　エンジニアリングイネーブルメントの活動の進め方

• エンジニアリングイネーブルメントの活動の外観
  • 開発プロセスの全体像の定義
  • 能力向上施策の定義と実施
  • 成果向上施策の定義と実施

6-5　開発プロセスの全体像

• 開発ステップの定義
• 開発プロセスの成功ファクターの定義
  • 計画フェーズ
  • 設計フェーズ
  • 開発フェーズ
  • リリースフェーズ
  • 運用フェーズ
• 開発プロセスの見直し

6-6　能力向上のための仕組み

• スキルマップの作成
  • スキルの抜き出し
  • スキルレベルの定義
• チームのスキルの把握
  • スキルレベル表の公開
• スキルマップに基づいた能力向上施策
  • 勉強会・研修
  • ペアプロ・モブプロ
  • 研修費補助・資格取得費補助
  • イネーブリングチームの組成

6-7　成果向上のための施策

• アウトカムを高めることが成果向上に必要ではなかったのか？
  • 木こりのジレンマ
• ドキュメントの整備
  • ドキュメントの作成
  • ドキュメントの更新
  • ドキュメントの整理
• オンボーディングプロセスの整備
• ツールの整備
  • プラットフォームエンジニアリングチームの組成

6-8　エンジニアリングイネーブルメントは誰がやるべきか

6-9　まとめ

第7章　開発基盤の改善と開発者生産性の向上

7-1　開発基盤の改善とは

7-2　誰が基盤を開発するのか

• 小規模なチームでの開発基盤
• 大規模なチームでの開発基盤

7-3　開発者生産性とは，価値提供の速度を高めること

7-4　開発基盤の改善の様々な取り組み

• 実装，価値検証のサイクルを高速化する
• オペレーション業務を省力化する
• 開発上の迷いや不安点を減らす

7-5　開発効率の改善のサイクルと全体像

1. 抽象課題の発見
2. 課題の具体化と改善策の発見
3. メトリクスを使ったベンチマークの考案と検証
4. 改善の実行

7-6　抽象課題の発見（Step 1）

• プロダクトコードとの接触を増やす
• コードレビューを通した課題発見
• 可能な限り自分で実装する機会を持つ
• プロダクト開発者との対話を通して課題を発見する
  • プロダクト開発者との交流を仕組み化する
  • 他チームの動向を把握する

7-7　課題の具体化と改善策の発見（Step 2）

• 抽象課題：CIの実行時間が長い
• 課題の具体化のアイデアを出すには
  • 一次情報と技術トレンドを追う

7-8　メトリクスを使ったベンチマークの考案と検証（Step 3）

• 開発者生産性とメトリクス
• 定量化できないメトリクス
• 生産性を定義するメトリクスの考案
  • Four Keys
  • SPACEフレームワーク
• モバイルアプリ開発の生産性をSPACEフレームワークで定義する
  • モバイルアプリのビルドにまつわる課題
  • Satisfaction & Well-Being
  • Performance
  • Activity
  • Communication & Collaboration
  • Efficiency & Flow
• メトリクスを多次元的に評価する
  • ビルドの待ち時間を減らしたい
  • ビルドについての質問を減らしたい
  • SPACEを使ったメトリクスの評価
• 開発者生産性の定義のまとめ

7-9　改善の実行（Step 4）

• 開発基盤改善のアンチパターン
  • アンチパターン1：特定領域への理解が薄れてしまう
  • 解決策1：プロダクトコードや手薄な部分への理解を持ち，抽象課題を発見し続ける
  • アンチパターン2：定量化が局所最適を起こしてしまう
  • 解決策2：複合的なメトリクスを設定する
  • アンチパターン3：改善を優先して開発を止めてしまう
  • 解決策3：前方互換を重視した移行計画を設計する
  • アンチパターン4：過剰に規約や規律，正当性を重視してしまう
  • 解決策4：落としどころを明確にする
• 他の開発者と協調していくために
  • 心理的に相談してもらいやすい環境を作る
  • 小まめな状況の共有
  • 夢を語る

7-10　まとめ