目次
第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 開発効率の改善のサイクルと全体像
- 抽象課題の発見
- 課題の具体化と改善策の発見
- メトリクスを使ったベンチマークの考案と検証
- 改善の実行
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：落としどころを明確にする
- 他の開発者と協調していくために
- 心理的に相談してもらいやすい環境を作る
- 小まめな状況の共有
- 夢を語る