いちばんやさしいアジャイル開発の教本
なんちゃってアジャイル開発から離脱したく、読んでみました。体系的にアジャイル開発を学べるので、これからリーダーになる方やアジャイル開発を始める方にとって有益な情報がたくさん載っていました。
ぜひ読んでください！
簡単な違い
ウォータフォール
- 各工程での成果物を完成品としていて、あと工程で手戻りが発生することがなるべくないようにする。
- 良くも悪くも不確実性を減らすモデル。開発を進めていく中で得られる気づきをソフトウェアや自分達の開発の進め方に反映できない
アジャイル
- 短期間のタイムボックスごとに動くソフトウェアが作られ、次のタイムボックスで得られた気づきを元に要件レベルから改善・改良を繰り返す
- 開発をしていく中での学びを活かすことができる。
顧客が本当に欲しいもの
開発したけど使われないということがしばしばある。完成した機能の6割は使われていないデータがある（スタンディッシュグループ調べ）
ソフトウェアの贅肉
開発を進めていく中で余計な機能が追加されていく。
- 不要な機能の多くは開発してから気づく
- 開発に無駄な労力や運用保守コストが発生する
開発途中で利用動向を確認しながら使われなくったら機能を削除するなど早めの対応をすることが大事
贅肉を見える化する
期待している効果が得られているか、利用されているのかといった観点で定量的に計測を行う
バリューストリームマッピングという手法がある。
全体のプロセスを視覚化し、価値の流れを最適化することが目的
- 開発が始まってからユーザーの手に届けられるまでのプロセスを全て洗い出してみる
- 待ち時間が多いところや手戻りが発生する箇所を見つけられる
「アジャイル宣言の背後にある原則」（https://agilemanifesto.org/iso/ja/principles.html）より引用
動くソフトウェア
ソフトウェアは何かしらの課題を解決するために仮説のもとに作られる。仮説はあくまでも仮説であるため、多くの場合本来必要なものとの間にはギャップが存在する。
そのため、最初から作り込んだ機能を開発してもユーザーが期待していたものとはずれていたり、ユーザーの行動パターンとがっちしていないなど、大きな手戻りが発生してしまう。
しかし、早い段階で動くソフトウェアをリリースしていれば、早い段階でギャップに気づくことができ軌道修正を行うことができる。
クライアントとの協調
バックグラウンドを共有する
要件定義でソフトウェアで実現することを決める。この要件には、背景、解決したい課題が存在している。
しかし、要件の背景となる課題が顧客と開発者とで共有されることがないまま開発とフィードバックのループを回しても、作成されたソフトウェアによって課題解決できる可能性は低い。
背景が共有されていると本質的なアプローチが可能となるまた、課題自体が再定義される可能性すらある。
顧客とプロダクトを作り上げる
「契約交渉よりも顧客との協調を」がアジャイルのモットー
自社開発では顧客（ユーザー）のフィードバックに当たる
ネガティブなフィードバックこそ本当のニーズからのズレのヒントになる
注意が必要なのが、顧客の言いなりになってものづくりをすることではない。
顧客の声の裏側の本当の要望を見極めることが大事
変化の対応
意思決定はなるべくあとで行う
開発には期間や予算という制約があるのが実情、この制約を満たしながら変化に対応する戦略が意思決定を遅らせること
具体的には、確実性が高いものから決定し、不確実性が高いものはなるべく遅らせる。
質とスピードは両立する
スピードが質を高くする
4週間でソフトウェアをリリースするとき、4週間一度にリリースするより、一週間に一度のリリースをする方が質が良くなる。
- 前者
一度のリリースで対応するためテスト対象が広くなる。
いざリリースして不具合が発生した場合、すべてのものが切り戻されることになる - 後者
1週間に一度のリリースで変更点を小さく抑えられる。
テスト対象は絞られ、テスト漏れのリスクが低くなり、リリースに関連した不具合が発生しづらくなる
結果、少しずつリリースした方が品質が良くなる
質がスピードを高める
高品質のソフトウェアは手戻りが少ない。
実現するためには？
- シンプルな設計を保つこと
- テストが行われていること
- 可読性の高いコードになっていること
- チーム内のレビューの質が大切
チームづくり
成長戦略
日本ではチーム発足時に何かしらのスキルが欠損していることが多い。
そのため開発を進める中で成長戦略を練り込み、後天的にスキルを身につけていくことでより強いチームへ成長する
新人の成長がチーム自身の成長を後押しする
インセプションデッキ
チームの外側や関係者から寄せられいる期待を言語化する
10個の質問を行う
ドラッカー風エクササイズ
お互いの理解のために、チーム内部のお互いの期待の可視化をする。
4つの質問をjam boardで行い、全員で眺めて認識の違いや感想をフィードバックを行う。
- 自分は何が得意なのか？
- どいうふうに仕事をして貢献するつもりか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどんな成果を期待していると思うか？（期待効果）
- 特にこの質問で「期待成果」に対する自己認識を正し、チームで合わせるのが狙い
ワーキングアグリーメント
チームで仕事、開発をする際に前提としたい約束事を共通理解する
様々な観点でルールを作成し、適宜追加や変更を行う。
少しずつ形作る
初めから車を作るのではなく、スケボ、自転車、車の順のように小規模のものから作っていく。
そのために、変更できるように作る
- 1つの機能が可能な限り独立して存在できるような設計が求められる
- 品質の低下をもたらすのは、プログラム間で強い依存性が高い時
- オブジェクト思考設計、ドメイン駆動設計などが著名
- テストの自動化を行う
- 変更がある度にテストを行うのは、コストが高いため
- テスト用の環境を構築する必要があるが、変更が頻繁にあるプロダクトではほぼ必須
構想とプロダクトを合わせる
バックログの管理方法
プロダクトを少しずつ開発するために、タスク一覧（スクラムではプロダクトバックログ）で管理する
- 優先順に並べる
- なるべく他のタスクに依存しないようにする
- 優先度の入れ替えが困難になるため
- 各タスクの十分に小さくする
- 一日以内に終えることを目安にすることで独立性を高める
ユーザー指定で全体像を把握する
プロダクトの全体像を理解するために、ユーザー視点で捉えるアプローチが必要
ユーザーストーリーマッピング
- ユーザーの行動を時系列に書き出して並べ、その行動中で発生する課題を捉え、それらの課題を解決するために必要な機能を洗い出す
- どんな機能が必要となるのか概要を把握することができる
アジャイルの初めの一歩
状況の見える化
繰り返し進めていく中で、より良くするがコンセプトのアジャイルだが、現在抱えている課題や今の状況がわからなければ次の手は打てない。
そのためにタスクや状況の見える化をする。
朝会で日常を見える化し、日々発生する課題と向き合い、スプリントの終わりには振り返りをする
ペアプログラミングをする
ペアプロで生産性を上げる
コーディングをしていく中で、ケアレスミス、可読性の低いコードを書いてしまうことがある。
ベテランでもやってしまう。
そこでペアプロ。
二人で作業することで常にレビューしている状態になること、書いたコードを知っている人が二人以上になることやお互いの得意分野を活かしてチームワークを発揮できるという効果がある。
ペアワーク
緊急トラブルやツール設定などの辛い作業の場合、心理的障壁が下げられる
また、ベテランと新人が一緒になってやることで暗黙知の伝授など教育に役立つ
ペア作業は非効率？
一人でやるところを二人でやることで、半分の時間でできるようになるわけではない。
しかし、一人で実装する場合レビューの待ち時間やレビュー対応に時間が必要になる。
ペアプロすることで常にレビューし、レビュー対応が少なくなるためリリースまでの時間が短くなる
エンジニアリングでテストの無駄を解消する
機能の追加や不具合の修正のたびソフトウェアは更新される。
その度に行われる目視による動作確認や修正後の影響範囲への考慮を解消する
意図した動作かの確認を自動化する
人手による広範囲の確認は時間の浪費や気持ちの疲弊に繋がる
テスト駆動開発
- 確認作業の自動化を支え、問題があったら知らせてくれる仕組み
- プロダクトのコードより先にテストコードを書く開発手法
メリット - 保守と拡張が楽になる
- 自動実行可能
- 不具合の再発を低下
- 品質の安定、人手による網羅的に確認していた時間の削減
- 過度の集中力を要するストレス削減
振り返り
チームの活動が形骸化したら？
朝会や振り返りで目的を忘れ、開催することが目的になってしまうことがある。メンバーの発言に無関心になったり、次の行動に繋がらなくなると悪い兆候
朝会で時間の無駄を感じたら
チームの関心事だけを発言するようにして特定のメンバーへの連絡や報告は禁止にし、規定の時間よりも短くする。
相談や問題解決、意思決定は朝会終了後に関係者だけで二次会として実施するのも対策の一つ
問題ありませんが頻発したら
問題解決を諦めているか、そもそも問題に気づいていないかの]可能性が高い。
解決策
- 「困っていること」から「モヤモヤと違和感を感じていること」へと問題の共有を下げる
- 個人レベルの失敗はチームで成果を出すための成長と全身のきっかけ、「学びのきっかけ」であることを強調するためにマネージャーなどから積極的に行うと○
- ファイブフィンガーで現状のタスクの達成度を5つのレベルで表すのもあり
振り返りで暗くなる反省会に陥ったら
YWT
- やったこと
- わかったこと
- 次にやること
「気づいた学びを次に活かす」という流れで成長を促進する
Fun!Done!Learn!
以下の区分で振り返りをする - 楽しかったこと
- やったこと
- 学んだこと
やったことの中で楽しさと楽しさや学びをアウトプットすることで記憶に残りやすい成功体験の学びなる
アクションプランが放置されたら
アクションプランの進捗がないことで振り返り自体の無力感を感じたらマンネリ化している証
「ふりかえりのふりかえり」を実施する
KPTで振り返る
- Keep
- ふりかえりを実践して良かったこと
- Problem
- 実施したけどうまくいかなかったこと
- Try
- 次にやること
アジャイル開発の理解を深める
二つの見積もり
- 全体感の見積もり
開発初期段階で必要とされる機能群全体を見積もり、タイムボックスを数える。
タイムボックスの数が明らかになれば、開発全体の期間についておおよその見立てをつけることができる
あとは体制にかかるコストを算出すれば、体制コストと期間の乗算で予算感が見えてくる - タイムボックスごとに行う見積もり
タイムボックスごとに実際に作る範囲を、やりいられるか見立てを都度行う。
全体感の見積もり
- おおよそこのような機能が必要であろうというレベルかんで洗い出す
- 反復開発の中で必要な分を詳細化しながら進めていく
- チームのアウトプット量を想定する
- 一回のタイムボックスでどのくらいの開発ができるか算出する
- 最初は仮定して行う
計画づくり
アジャイルで行う計画づくりは三種類
- リリースプランニング
- スプリントプランニング
- デイリースクラム
頻繁に計画づくりを行うことで、現実で起こる変化や開発を進める中で得られた理解に基づいて計画を変更する
ドキュメント
アジャイル開発では必要に応じてドキュメントを書く
目的
- ドキュメントは作るものの認識を揃えるためとは別に、作ったものにそのあと関わる人たちの理解を助ける
モノづくり前にドキュメントを作成する - ドキュメントとして何が必要になるかわからないため、作る範囲が広くなりがち
- 作った分のメンテナンスが延々と発生する
モノづくり後にドキュメントを作成する - 成果物のメンテナンスに必要なドキュメントは何か判断しやすい
- 成果物に基づいてドキュメントを作成するために、内容の言語化に悩むことが少ない
要件定義
二種類ある
- 全体を知るための要件定義
リリースプランニングの段階で作るべきもの「全体を知る」ために整理を行う
初期段階では詳しく決定されいない部分もあるため - スプリントごとの要件定義
スプリントごとに機能を作り切るため、何を作るべきか詳細までイメージできるようにする必要がある
設計
全体と部分に分けて設計をする
誤ると手戻りになるような観点と、スプリントという分割された期間のなかでの活動にできる観点に分けて設計を行う
- 全体（プロジェクト単位）
- リリースプランニングとそれに必要な作るべきものの整理
- アーキテクチャ設計
- プロダクトの情報設計
- 概要レベルのデータモデリング、ドメインモデリング
- 部分（スプリント単位）
- スプリントに必要な作るべきものの整理
- 機能やデータ設計
- UIデザイン
- 成果物のドキュメント
全体の決定を遅らせるようにする
何を作るべきか定めにくいようなプロダクトや
不確実性の高い状況で全体を決めるには情報が足りていない場合が多い。
SPAなどのフロントエンドとバックエンドを分ける設計などは依存性が低いため柔軟性が高い
テスト戦略
- ビジネスと技術観点でテストを行う
二つの観点からテスト項目が不足していないか確認し、適宜追加する - テストの自動化にコストがかかるため、選出する
- プロダクトの土台部分の品質を維持するため、以下のテスト項目を自動化する
- ユニットテスト
- コンポーネントテスト
- 接続テスト
段階的な広げ方と守破離で深め方
広げ方
難易度を下げるために、最初はまず一人から
一人からできることで初めて、まずは自分の練度を高めていく
そしてチーム、その先に組織を
深め方
まずは、既存のアジャイルの方を学び、小さな範囲でタイムボックスを切って実践する
そこから学びを得て、取り組みを修正する
やがて型から離れて、それぞれの状況に適した振る舞いを型作るような進め方でいく。