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

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

4.2 守破離 4.3 第一原理 4.4 原則となるために 4.5 プラクティスとなるために 4.6 原則がプラクティスをガイドする 内容 ソフトウェア開発を守破離に則った考えで説明。 守ルールや形式知を学び、背景の理論、目的をそこまで深く知らずに型から入る。型から入るのは、背景の理論や目的は抽象的で理解しづらいから、実践し経験しながら理解を深める。ソフトウェア開発で例えると「TDDのルールを覚える」など。 破実践し経験しながら、背景の理論、目的を理解していくフェーズ。ソフトウェア開発で例えると「TDDを実践し、メリットを体で感じる」など。 離背景の理論、目的を体現した状態で、さらに新しい理論を導き出すことができるようになる。継続的な学習・鍛錬で行き着くことができる。ソフトウェア開発においても同じことが言える。 ソフトウェア開発の「守」にあたる原則として代表的なもので、「単一責務の原則」「オープン・クローズドの原則」などがある。 単一責務の原則原則：クラスを変更する理由は１つでなければならない。理論：システム内のクラスがそれぞれ一意の役割を持つことで、クラス間の相互作用がわかりやすくなる。テストもしやすくなる。 オープン・クローズドの原則原則：エンティティは拡張に対して開いていて、変更に対して閉じているべき。理論：既存コードを変更するほうが新しいコードを作るよりバグが発生しやすいから、機能追加する場合は既存コードを変更せずに新しいコードを追加できるようにしたほうがよい。 これらはソフトウェア開発で重要な原則の一部として一般的だが、原則なだけであって、どうやればそれができるかは語らない。実現するためのプラクティスはいろいろあるが、さまざまな経験を通して理論を実感し体で理解していかないと、「変更可能な品質を作り出すためにプラクティスを使いこなしている」ということにはならない。 また、ソフトウェア開発もまだまだ未発達なので新しい原則やプラクティスが生まれることもあると考えられる。 原則は簡潔でなければならない。原則は良いソフトウェア開発に導いてくれるため、くどくどとわかりにくいものではだめだ。 原則ができたのなら合わせてプラクティスも必要で、プラクティスは ほとんどの場合に価値がある 学ぶこと、教えることが簡単 考えなくてもいいくらい実施が簡単 でないと、チームの習慣化はできない。 原則とプラクティスがこの条件を満たしたとき、これらは良いソフトウェア開発のためのツールとなり得る。 この本では、これらの条件を満たした９つのプラクティスを紹介する。 学び 守破離の例がわかりやすい 頭だけ理解してもだめ。体でも理解しないと。 実際に経験するには、自分で機会を作っていかないと、会社の案件だけではチャンスが恵まれない可能性もある。 学びを活かすアイディア・行動 自分でサービスを作り、プラクティスの練習をする

4 9つのプラクティス 4.1 専門家が知っていること 内容 成功するための開発メソッド、原則は１つということはないと考える。あのとき上手くいった方法もとある条件下ではうまくいかないということもある。 しかし、成功するためにはそのときどきで、共通理解、共通のプラクティス、共通語彙が必要なことは確か。 改めて共通認識として持つ必要があるのは、レガシーコードが様々な理由で生まれるのは、品質にフォーカスしていなかったから、ということ。 ソフトウェアはビジネス拡張の役割を担うのと、バグ修正する場合も開発時とリリース後ではリリース後の方が修正コストが１００倍かかると言われている。だからソフトウェアは変更可能であることが重要だし、そのための品質を保つことが重要。 専門家たちは品質を保つ方法と、ソフトウェア開発は品質に力を入れることは、長期的にも短期的にもあまりコストがかからないことを知っている。 著者が見てきた最速級のエンジニアは、品質にフォーカスし、きれいな状態を保っていたからこそ早かった。 学び ソフトウェア開発では、品質と生産性はトレードオフではなく、シナジー関係にある。 高い品質を作るには相応のスキルがいる。 学びを活かすアイディア・行動 質を高めるプラクティスの学習と実践

3.5 アジャイルはキャズムを超える 3.6 技術的卓越性を高める 内容 ジェフリー・ムーア著書「キャズム」による革新的な新製品採用する人たちの５つのグルーピング。 ・イノベーター・・・最新に飛びつく人・アーリーアダプター・・・イノベーターの次に飛びつく人　　↑　　アーリーアダプターになることを「キャズムを超える」と言う　　↓・アーリーマジョリティ・・・不具合が解消されてから飛びつく人・レイトマジョリティ・・・メジャーになってから使う人・ラガード・・・代用品がないから使う人 アジャイルはキャズムを超えたと言えるが言い切るには難しい。まだ、イノベーター的な側面があり、XPなどの技術プラクティスが相当する。 そのせいで、技術プラクティスに一貫性がない。 スクラム提唱者のジェフ・サザーランドは開発の成功要因は技術的卓越性を高めることだと言っている。 これは技術プラクティスをもっと磨く必要があるということを言っている。 学び アジャイルの歴史感と現状。マネジメントプラクティスはキャズムを越えてきているが、技術プラクティスは越えていない 学びを活かすアイディア・行動 ペアプロ、TDDの実践

3.4 芸術と技能のバランスを保つ 内容 ソフトウェア開発は左脳（論理、客観、スキル）と右脳（創造性、芸術性）の両方を使う。 だからスキル（左脳）だけ磨いても上手くいかない。 今の学校ではスキルを教えている。しかもどんどん古くなっていくもので、そのせいで世にレガシーコードが増えている。 学び ソフトウェア開発が右脳を使っているということ 学びを活かすアイディア・行動 右脳トレーニング、瞬読トレーニング