アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知
翔泳社
著者：常松祐一
監修：川口恭伸、松元健
はじめに
この本はどんな本ですか?
この本の対象読者
この本の読み方
本書で取り扱うプラクティスについて
監修者序文
はじめまして!
一方そのころ
第1章 アジャイル開発を支えるプラクティス
1-1 プラクティスの実践
アジャイルの「ライトウィング」と「レフトウィング」
技術プラクティスの実践を通じ、文化を定着させる
1-2 高速に石橋を叩いて渡る
早く気がつく
小さい単位で完成させる
継続的に見直す
1-3 広く知られたアジャイル開発手法とプラクティス
スクラム
エクストリームプログラミング
カンバン
1-4 プラクティス理解に役立つ考え方
同時に取り掛かるタスクを絞る
WIP制限
リソース効率とフロー効率
小さい単位で完成させつつ、全体バランスにも目を配る
インクリメンタル
イテレーティブ
動作する状態を保ちつつ、変化させていく
第2章 「実装」で活用できるプラクティス
2-1 実装方針
実装前に方針を話して手戻りを防ぐ
実装前に方針を話す
ユーザーストーリーをタスク分解する
タスク分解
カンバン
完了基準を明確にする
準備完了の定義(Definition of Ready)
完成の定義(Definition of Done)
受け入れ基準(Acceptance Criteria)
未完了作業(Undoneワーク)
コメントで実装のガイドラインを用意する
疑似コードプログラミング
2-2 ブランチ戦略
並行して修正を進めるための運用規約
ブランチ戦略
細かく頻繁に直接コミットを積み重ねて開発を進める
トランクベース開発
動く状態を保ったまま小さくマージしていく仕組み
フィーチャーフラグ
長命ブランチが必要な場合
長命ブランチへの定期マージ
2-3 コミット
標準的なコミットメッセージを書く
読み手に配慮したコミットメッセージ
異なる目的の修正を1つのコミットに混ぜない
コミットを目的別に分ける
コミットにプレフィックスを付与する
コミット履歴を書き換える方法
コミット履歴を書き換える
読み手に受け取ってほしい流れでコミットを並べる
物語のようにコミットを並べる
2-4 コードレビュー
コードレビューの目的
ソースコードの共同所有
コードレビューの取り組み方
コードレビューにも積極的に参加する
ソースコード全体を見てコードレビューする
レビュアーはグループにアサイン
コードオーナーの設定
ツールにできる指摘はツールに任せる
linter、formatterの活用
ツールの出力結果をプルリクエストにコメントする
作業が確認できる場を早期に用意する
実装の着手と同時にプルリクエストを作る
親ブランチを使ったコードレビューとマージ
建設的なコミュニケーションのための心構え
レビュアー/レビュイーから伝える努力
プルリクエストテンプレート
協働作業でソースコードをよくする
コードレビューのやり方を見直す
コメントにフィードバックのニュアンスを含める
コードレビューでコメントが思いつかない状態を乗り越える
質問することで学ぶ姿勢を持つ
2-5 協働作業
1つのユーザーストーリーに多くの関係者を巻き込む
スウォーミング
2人で協働し開発を進める
ペアプログラミング
リアルタイム共同編集機能のある開発環境を使う
複数人で協働し開発を進める
モブプログラミング、モブワーク
2-6 テスト
検証(Verification)と妥当性確認(Validation)の観点
検証(Verification)と妥当性確認(Validation)
妥当性確認はステークホルダーと一緒に進める
テストの自動化に関する技術プラクティスの違い
自動テスト
テストファースト
テスト駆動開発
テストコードを長く運用するためにできること
読みやすいテストコードを書く
テーブル駆動テスト
テストコードの分量を適正に保つ
必要十分なテストコードを用意する
ミューテーションテスト
2-7 長期的な開発/運用ができるソースコード
日々の開発からソースコードの品質に気を配る
長期的に開発/運用できるソースコード
ソースコードを長期的に開発/運用できるようにする
リファクタリング
リアーキテクチャ
元のソースコードよりも綺麗にする
ボーイスカウトルール
機能の取り下げ方を身につける
ソフトウェアの依存関係を見直す
依存関係の自動更新
第3章 「CI/CD」で活用できるプラクティス
3-1 継続的インテグレーション
ビルドやテストを繰り返し、問題を早期発見する
継続的インテグレーション
ローカル環境で頻繁にチェックを動かす
フックスクリプト
ドキュメントの継続的な更新
ツールによるドキュメント自動生成
3-2 継続的デリバリー
常にデプロイ可能な状態にシステムを保つ
継続的デリバリー
CI/CDパイプラインの構築
CI/CDパイプライン
利用環境をブランチ戦略と紐づけ自動更新する
ブランチ戦略と利用環境との紐づけ
ブランチ保護を設定し、リリースできる状態を保つ
ブランチ保護
3-3 継続的テスト
自動テストの望ましいテスト分量
テストピラミッド
ユーザー環境に近しいシステム全体のテスト
E2Eテストの自動化
開発にまつわるすべての工程でテストする
継続的テスト
第4章 「運用」で活用できるプラクティス
4-1 デプロイ/リリース
デプロイ戦略の選択
ローリングアップデート
ブルーグリーンデプロイメント
カナリアリリース
データベーススキーマの管理とマイグレーション
データベーススキーマの定義と管理
誰でもデプロイ/リリースできるように整備する
デプロイツール
ChatOps
定期リリースを守るリリーストレイン
リリーストレイン
4-2 モニタリング
メトリクス/ログ/トレース
メトリクス
ログ
トレース
モニタリングとオブザーバビリティ
モニタリング、オブザーバビリティ
有用なログを出力する
ログレベル
JSONによるログ出力
4-3 ドキュメント
チームのためにドキュメントを書く
チーム内のコミュニケーションのためのドキュメント
READMEファイル
Playbook/Runbook
目的を意識してドキュメントを書く
Diátaxisフレームワーク
第5章 「認識合わせ」で活用できるプラクティス
5-1 関係者との認識合わせ
関係者を集め、ゴールやスコープを揃える
関係者を揃える/ゴールを揃える/スコープを揃える
ユビキタス言語
実例による仕様
話題が減るまで毎日話す
進め方の認識を揃える
不確実性の高いものからやる
コントロールできる事項は早めに決定する
コントロールできない事項の決定はできるだけ先送りする
進捗状況の認識を揃える
関係者の期待値を聞いて認識を合わせる
報告フォーマットを揃える
技術プラクティスを適用する余力を確保する
5-2 開発内での認識合わせ
設計を事前に協議する
事前の設計相談
リスクがあるユーザーストーリーは「スパイク調査」
スパイク調査
大きめの開発はDesign Docで目線を合わせる
Design Doc
5-3 計画の継続的な見直し
ユーザーストーリーを小さく分ける
ユーザーストーリーの分割
INVEST
ユーザーストーリーを整理して見通しをよくする
ユーザーストーリーの定期的な棚卸し
第6章 「チーム連携」で活用できるプラクティス
6-1 チームの基本単位
チームで仕事を担う
フィーチャーチーム
フィーチャーチームがよく受ける疑問や誤解
コンポーネントメンターを任命する
会社組織とチーム体制の合わせ方
6-2 属人化の解消
危険のサイン「トラックナンバー= 1」を避ける
トラックナンバー
スキルマップを作成し、属人化スキルを特定する
スキルマップ
6-3 パフォーマンスの測定
メトリクスを最大化する力学を避ける
相関のあるメトリクスの組み合わせを複数見る
“FourKeysMetrics”でチームのパフォーマンスを測る
Four Keys Metrics
6-4 円滑なコミュニケーションのアイデア
必要なときに直接やりとりする
ただ話す
トラベラーがチームを渡り歩く
トラベラー
声に出して働く
Working Out Loud
リモートワークを前提とした仕組み
同期コミュニケーションを柔軟に取り入れる
ワーキングアグリーメント
オンサイトをリモートと同じ条件にする
コラボレーションツールの活用
6-5 認識を揃えるワークショップ
ユーザー目線で優先順位を確認する
ユーザーストーリーマッピング
短時間で見積もり、実績に基づいた進捗を示す
サイレントグルーピング
バーンアップチャート
アイデアが生まれてからデリバリーまでを短くする
バリューストリームマッピング
おわりに
コラム執筆者紹介
著者・監修者紹介
索引
コラム
■チームで1つずつ終わらせよう
椎葉光行
■ペアプログラミングの効果と影響
安井力
■テスト駆動開発ではTODOリストがテストよりも先
大谷和紀
■技術的負債―問題発見までの時間とリスクをビジネス側に説明する
川口恭伸
■インフラ構築を自動化しよう
吉羽龍太郎
■Logging as API contract
牛尾剛
■AIフレンドリーなドキュメントを書こう
服部佑樹
■開発と運用、分けて考えていませんか?―ダッシュボードのその先へ―
河野通宗
■開発項目をコンパクトに保つには、クリーンなコード
大谷和紀
■チームに命を吹き込むゴール設定
天野祐介
■グラデーションで考える 12年間のアジャイル実践
きょん