出版書誌データベース

ソフトウェア開発の世界では、生産性の向上は永遠のテーマです。ユーザーニーズの変遷や技術の進歩など、環境が変化し続ける中でいかにして効率的に開発を継続していくかは、多くのソフトウェア開発チームにとって切実な問題です。本書は、そのような問題に対する解決のヒントを提供することを目指しています。
しかし、本書が提供するのは汎用的な解決策や、普遍的な理論ではありません。各章に記されているのは、それぞれの著者が、自身の経験と専門性をもとに導き出した、生産性を向上させるための具体的かつ実践的な自説です。生産性を向上させるための網羅的な解説書というわけではなく、むしろ多角的な視点からの提案と捉えてください。
本書は2部構成になっています。第1部『開発プロセスと生産性』では、開発プロセスの改善をどう実現するかについて述べます。具体的には、Product Requirements DocumentやDesign Docといったドキュメント作成や、ブランチ・リリース戦略、リアーキテクト時のテスト戦略というトピックから、生産性を向上させる方法を解説します。第2部『開発チームと生産性』では、チームの立ち上げ、スキルの向上、開発基盤の改善というトピックで、開発者とその組織に焦点を当てて解説します。
本書は、エンジニアリングマネージャーやテックリードを含む、開発生産性を改善したいと考えている方々に向けて書かれています。必ずしも、すべてを通して読む必要はありません。それぞれの章は、独立して理解できるように構成されているため、必要に応じて部分的に読むことができます。興味のあるトピックや現在直面している課題に関連する章を読み、そのアイデアをご自身のチームに採用してみてください。

▲
【凡例】
# 節見出し
## 項見出し
### 小見出し
▲

第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 まとめ

他著：田中 洋一郎
Tably株式会社 CTO。Google Developers Expert（Web Technology担当）。

他著：石川 宗寿
LINEヤフー株式会社所属。著書に『読みやすいコードのガイドライン -持続可能なソフトウェア開発のために』（技術評論社）。

他著：若狹 建
合同会社桜文舎 代表社員。東京大学大学院工学系研究科情報工学専攻修了。Sun Microsystems、Sony、Google、Apple、LINEなどを経て、メルカリにて執行役員としてCTO Marketplace、Group CTOを歴任。現在は数社の技術顧問を務める。