レガシーコードからの脱却

プラクティス８ 協力しあう 8.1 エクストリーム・プログラミング 8.2 コミュニケーションと協働 内容 すべてのスキルに方法論、テクニック、プラクティス、原則があるように、協働も１つのスキル。 協働をすることで、お互いに学び合い、ともに学べるようになる。しかし、ある日突然それができるようにはならない。チームの一員になって、ただ隣にいるだけでは足りない。 チームの文化を受け入れ、チームメンバーと相互理解を深めて「本当の一員」になる必要がある。 そうしてこそ、互いに質問しあい、議論し合うことができ、高い生産性を出すことができる。 ソフトウェア開発は多くのコミュニケーションが必要で、人と人との調整が極めて重要。成功させるために、ゴールの定義、品質の意味、完成の意味の共有から始め、設計のための共通言語を共有していく必要がある。部屋のパーティションがコミュニケーションを阻害するのであれば排除する必要がある。そしてオープンな空間の中で、人と人がどのように相互作用するかが一番重要なポイント。 学び すばやいコミュニケーションをとるスキルがソフトウェア開発において超重要。 そのために、日頃のチームビルディング（メンバー間の相互理解、様々な共通認識合わせ）も重要。 学びを活かすアイディア・行動 現場でのペアプログラミング導入

7.7.2 リスクを減らす７つの戦略 内容 継続的に統合する未知のリスクを最後に入れないため ブランチを避ける未知のリスクを最後に入れないため。フィーチャーフラグを使っておいて、マージは先にする 自動テストに投資する開発のコストを抑えることにつながるため。 リスクのある場所を特定する未知の場所、コントロール不可の場所を特定し依存関係を切り離す。 未知の中で働く未知のものを発見したら短時間でそれだけに取り組み、記録しながら進捗を確認する。 価値のわかる最小のものからつくる２割で８割の効果を得られるなら２割のものから作る。 頻繁に検証する顧客は実際に見てみなければ欲しい物がわからないかも知れない。完成品でなくても早い段階で作って、見てもらう。 学び そのまま 学びを活かすアイディア・行動 いまのところ特になし

7.7.1 アジャイルインフラストラクチャーの７つの戦略 内容 すべてをバージョン管理するコード、ドキュメントなどビルドに関連するすべてをバージョン管理し、ワンクリックでEnd to Endのビルドをできるようにする 継続的に統合する最後に問題を入れ込まないため タスクの受け入れ基準を定義する？ テスト可能なコードを書くビルドも早くなるし、高品質なコードになる傾向にあるため 必要な箇所のテストカバレッジを維持する難しい箇所はテストカバレッジをを維持してテスト漏れがないように。 壊れたビルドをすぐ直す壊したならすぐに直すか、できなければロールバック。 学び バージョン管理の仕方が重要だと思った。ロールバックできるようにするためにも。 始めは難易度が高いところの必要最低限の箇所でもいいかと思う。 学びを活かすアイディア・行動 難易度が高い箇所の洗い出し ブランチモデルの再考

７ プラクティス３ 継続的に統合する 7.1 プロジェクトの鼓動を確立する 7.2 完了と、完了の完了と、完了の完了の完了の違いを知る 7.3 継続的にデプロイする 7.4 ビルドを自動化する 7.5 ビルドは頻繁にする 7.6 最初の一歩を踏み出す 内容 問題を後回しにすることは、リスクと努力が必要な状況を作り出している。継続的インテグレーション（CI）とは、統合＆ビルドをリリース直前にするのではなく、こまめに行っていくこと。開発で最も重要な環境で、作るのも簡単。 CIはビルドサーバーを作って（クラウドサービスでも可）、そこにバージョン管理システムで随時統合し、統合したらビルドと自動テストを実行するようにする。 「完了」と「完了の完了」と「完了の完了の完了」の３つの状態を知り「完了の完了の完了」を目指そう。 完了・・・ローカルでビルド、テストが通る 完了の完了・・・ローカルで通ったものが統合される 完了の完了の完了・・・さらに、保守可能な状態にリファクタリングされている ３つ目を目指すことで、保守可能なコードになり、テストも高速に実行できるコードになっていることが多い。 ビルドサーバーにはコードの他にも、ビルドスクリプトやDBレイアウト、必要なドキュメントなど、リリースに関連するものはすべて一元管理をし、ビルドの整合性を保つようにしよう。 頻度は最低１日１回、一日の最後ではなく最後にビルド失敗しても修正可能なタイミングで行おう。多ければ多いほど良い。 この癖をつけるのは最初は大変かもしれないが、この価値を知り、軌道に乗れば、今までの方法には戻れなくなる。 学び CI環境は高速フィードバックのために超重要 学びを活かすアイディア・行動 現場で作る

6.13.2 ストーリーを分割する７つの戦略 内容 複数のサブストーリーを要素に分解する複数のサブストーリーで構成されている場合、分けることでモジュール化しやすくなる 複雑なストーリーは既知と未知で分ける分けることで既知の部分が効率的に進む 未知のことをわかるまで繰り返す未知の課題を解決する。そのまま 受け入れ基準をもとに分解するストーリーの受け入れ基準と整合性を保つ必要があるので、受け入れ基準をベースに分解する 依存関係を最小限にするストーリー同士の依存関係を少なくし、それぞれが独立してリリース可能にする 意図を１つにするそのまま ストーリーをテスト可能に保つそのまま 学び そのまま 学びを活かすアイディア・行動 これらをチェックリストに、バックログを見る・分解する

6.13.1 ソフトウェア開発を設計するための７つの戦略 価値実現までの時間を計測する価値実現までの全体プロセスの時間を知ることで全体像に注目できるため コーディングに使った時間を計測する品質改善に使える時間が少なすぎないかチェックできる 欠陥密度を調べるコード1000行あたりのバグの数は品質改善のための指標となる 欠陥検出までの時間を計測する欠陥発生から時間が経てば経つほど修正コストは上がる 機能ごとの顧客価値を計測する価値の高いものから時間を費やすことができるため 機能を提供しない場合のコストを計測するその機能がないとどのようなコストが発生するかが、機能を作る理由になる場合がある フィードバックループの効率を計測する失敗から改善までどれくらいかかっているかを知り、プロセスが改善されているかを知ることができる 学び そのまま 学びを活かすアイディア・行動 まだ具体的な行動は思いつかない

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