6.9 バックログを作る 6.10 ストーリーをタスクに分解する 6.11 タイムボックスの外側を考える 6.12 スコープを管理する 内容 アジャイル開発の進め方の重要なポイントはスコープを管理しながらリリースできるかどうか。 そのための方法として、バックログ（ストーリーをリスト化したもの）を作る。最初に優先順を決めて進める。なにか良いアイディアが出れば、途中でそれを入れる。優先順は入れ替えれば良い。 ストーリーは実際に行うタスクに分解する。理想は最大で4時間程度。8時間の労働時間の場合、4時間が理想。稼働率１００％の高速道路は、駐車場のようにびっしり車がつまってしまっていて、まったく機能していない状態を指す。ある程度のゆとりがあるからスピードを出すことができる。人間も同じでバッファがないと逆に動きづらくなる。 ある程度、小さな時間のタスクを消化し、リリースすることに慣れたら、機能をスコープにしてリリースすることにシフトしよう。 学び ビジネスに対して主体性が伴ってこその方法だと感じた。 やらされてやっているようではその意味を感じられない可能性がある。 学びを活かすアイディア・行動 大きなタスクを分解するときに、概算見積もりをつける

6.5 分割統治 6.6 フィードバックを短くする 6.7 ビルドを高速化する 6.8 フィードバックを早くする 内容 大前提として、私たちは常に間違うようにできている。だから問題は発生するし、どのように問題を解決するかがポイント。 問題は小さいうちのほうが単純でわかりやすく解決しやすい。だから複雑な問題を分解するスキルは重要。 複雑さは未知から生まれる。 未知に対するアプローチは２つ。 未知のことを既知になるように理解する カプセル化して、置いておく 複数のタスクをこなす場合、一度に取り掛かるタスクが多いと作業切り替え時の無駄が発生するので、カプセル化して置いておくと有効。 また、問題を常に小さく保つためには、常にビルドして統合しておくことが重要。ビルドのフィードバックは開発中の失敗を検知するのに非常に有効。間違いを検知すればそこから間違った原因を探すことができる。なので、ビルドに時間をかけてはいけない。3秒以内のビルドを目指そう。できないならメモリを増やそう。それでもできないなら設計を見直そう。 そして、フィードバックを得られたなら、フィードバックに対応しよう。そのためのフィードバックだ。 学び 未知のことは理解できるようになることが、１ｓｔステップ。 複数の未知がある場合は、カプセル化できるところまで進めて、あとは置いておく。 全体統合ビルドは常に高速を目指す 学びを活かすアイディア・行動 まだ思いつかない

6.3 ケイデンスがプロセスを決める 6.4 小さいことは良いこと 内容 作るものを小さくするほうが良い理由は 理解しやすい 見積もりやすい 実装しやすい テストしやすい 結果、早く作れて早く顧客に価値を届けられる。 リリースサイクルが長ければ長いほど1機能ごとに完成するまでのプロセス効率は悪くなる。人員の変動の可能性が出たりして、引き継ぐためのドキュメント作成の必要性が高くなり、正式なテストフェーズや統合フェーズを必要とするようになり、結果、ウォーターフォールとやってることは変わらなくなる。 また、価値提供の効率も悪くなる。全10機能を10ヶ月で一度にリリースすると、機能は価値を提供するまでに10ヶ月かかるが、1ヶ月ごとに1機能をリリースすれば、早くからリリースされた機能は早い段階から価値を提供できる。 ウォーターフォール開発は開発効率をコード行数で表すが、そもそもソフトウェアは顧客にどれだけ価値を与えたかで計測できなければならない。ベロシティ、コード行数が圧倒的にすごくても顧客に価値を与えていなければ意味がない。これらは顧客への価値を計測するための二次的な参考値にすぎない。 学び 顧客への価値を計測することが重要 生産性だけにフォーカスしても意味はない 学びを活かすアイディア・行動 KPIを意識することが重要と思うが、具体的な行動は思いつかない

6 プラクティス２ 小さなバッチを作る 6.1 小さなウソをつく 6.2 柔軟に進める 内容 タイムボックス、スコープボックスという枠を使って進める。作業単位ごとに結果が見えるように自分たちにとって正しいサイズにする。 タイムボックスは時間内にタスクを入れる。スコープボックスは時間ではなく機能単位で作る。 大きなタスクよりも小さなタスクの方がリスクが小さくて済む。タスクの見積もりが確実になることはないため、１年間で見積もりの誤りを隠しながら積み上げて大きくするよりも、小さな間違いを露見しながら軌道修正しながら進もう。 生産性を上げるために人を増やすことをするが、一概に正しいとは言えない。例として、子どもを産むのに９ヶ月かかるが、９人集めれば１ヶ月で産める、とはならない。ソフトウェア開発で大量の要求をさばかないといけない場合も、人数が増えたからといって大量の要求がスムーズに決まり、課題がスムーズに解決するとは限らない。多くの場合、人を増やすとコミュニケーションラインが増え、複雑化し、速度が落ちるか止まるかする。リリース日が決まっているのであれば、スコープを絞るべき。 学び 要求は人が集まれば解決するものでもない。必要最低限の有識者が課題を解決しながら決まるため、不用意に人数を集めるとリスクになる可能性が高い。 人を増やすよりも、有識者になるための情報共有する仕組みが必要 学びを活かすアイディア・行動 定期的な勉強会で有識者を作る

5.7.2 良いストーリーを書くための７つの戦略 内容 プレースホルダーとして見るストーリーは詳細な要求ではない。議論の本筋を掴むためのプレースホルダーとして使うと良い。 目的に注力する開発者はコードを書きながらやり方を模索すべきだが、まず機能の目的を理解すべき 「誰」を擬人化する誰のための機能かを知ることで、使われ方の理解が深まり、設計の改善ができる。 なぜ機能が必要とされたのかを知る機能の目的の経緯をしることで、より良い選択肢に至ることができる。 シンプルに始めて、あとで追加するリファクタリングと創発設計ができるようになると理想的な設計になるので、始めはシンプルに考えすぎない。 エッジケースを考えるストーリーはハッピーパスを表すが、他のパスもあるのがほとんど。浮かび上がったパスはメモしてあとでテストする。 学び コミュニケーションによって要件の詳細を詰めていき、ドキュメントはなるべくコードに寄せるというイメージでした。 学びを活かすアイディア・行動 特になし

5.7.1 プロダクトオーナーのための７つの戦略 内容 SMEになるその分野、プロダクトにおける専門家になる。 開発を発見のために利用する開発中の機能を何百というユーザーに触ってもらい、正しく進んでいるかを確認する。 どうやって手に入れるかより、何が欲しいかを説明する開発者には何が欲しいかを説明し、やり方は裁量を与える。それにより保守性が高くなる。 質問をすばやく答えるPOはボトルネックになりやすいので質問が来たら早く答える。 依存性を取り除く誰かが何かにかかりきりにならないようにタスク分割し優先順を変え、チームが柔軟に動けるようにする。 リファクタリングを後押しする機能要求だけでなく、保守性にも敏感である必要がある。 学び イメージが沸かないことが多いので具体的な経験を積む必要がある 学びを活かすアイディア・行動 ユーザーのABテスト

5.3 プロダクトオーナーをおく 5.4 ストーリーで目的、理由、誰のためかを語る 5.5 明確な受け入れ基準を設定する 5.6 受け入れ基準を自動化する 内容 プロダクトオーナー（PO）はプロダクトに一番精通している人で、この人が監督のようなもので、正しく進んでいるか確認しながら進める。プロジェクトマネージャーとか、呼び方はさまざま。 POは「誰が」「何を」「何のために」が１文でわかる「ストーリー」を作る。これが要件を表す「かろうじて分かる最低限のドキュメント」で、これをもとに開発を進める。ストーリーの例）・映画を見る客が・オンラインでチケット購入する・映画館でチケット購入のために待ち時間を作らないために ストーリーができたらPOは受け入れ基準を明確にする。・それは何をするはずか・それはいつ動くか・どうなったら次に進むことができるかこれがハッピーパスとなり、例外やその他の分岐はこれが基準となる。 受け入れ基準が明確になったら、ふるまいのIN/OUTを明確にしてプログラムレベルで検証できるようにする。ここまで明確になれば、不要な作り込みは起きない。 学び ちょっとまだ具体的なイメージがわかないので、学習が必要だと感じた。 学びを活かすアイディア・行動 ストーリー作りから作り込むことについて学習

5 プラクティス１ やり方より先に目的、理由、誰のためかを伝える 5.1 やり方は言わない 5.2 やり方を目的に転換させる 内容 ソフトウェア開発では半分を要求収集に使っていると言われている。そして、顧客から開発者までに情報が流れるなかで情報は欠落したり歪んでいったりしていく。 開発に精通していない顧客やマネージャーが要求の「やり方」まで伝えることがあるが、これは良くない。情報が専門知識が無い前提のもので、開発者は専門知識を前提に見るので混乱を招く。 なので「やり方」は専門家である開発者に任せるべき。 また、「やり方」も開発者によって千差万別で、似たようなものもあれど完全に同じやり方をするということは無いが、これはこれで良さがある。新しいアイディアが生まれるから。 細かいやり方を統一することは難しいので、原則・パターン、プラクティスを共通認識として持ち、その域を越えて標準化しなくてもよい。 学び やり方は細かすぎるものは標準化しなくてよい。 学びを活かすアイディア・行動 現場のコーディング標準

4.8 「良い」ソフトウェアを定義する 4.9 ９つのプラクティス 内容 「良い」ソフトウェアの定義はまちまちだが、本書では保守性を表す内部品質の高いものを指す。 目に見える品質を外部品質（バグがない、早い、使い勝手が良い、など）といい、目に見えない品質を内部品質（バグが発見しやすい、変更しやすい、わかりやすい、などの保守性）と言う。 本書では、保守可能なソフトウェアを作るためのプラクティスを、スクラムから２つ、XPから７つの計９つを紹介する。 ９つにしているのは人間は一度に記憶できることが７個プラマイ２個といわれているので最大９個にしている。 学び 9個覚えれば良いというものでもない。 学びを活かすアイディア・行動 特になし

4.7 予測か対応か 内容 決まっていないけど起こりうることを予測して開発するか、決まってないことはやらずにいつでも簡単に変更可能にしておくようにするか、この２つの選択肢であれば後者が断然良い。決まっていないことはやらないかもしれないから。 学び 予測できることは要件にするかどうかの確認は必要。 学びを活かすアイディア・行動 特になし