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

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

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

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

3.2 小さいほどよい 3.3 アジャイルの実践 内容 アジャイルでは、長距離ランナーのように小さなラップでゴールまでの道のりを徐々に明確にしていくことを良しとしている。 プロジェクトが計画が立てづらい理由は様々だが、惰性ではない。 ポイントになるのは、小さなスコープ、仕事を決めていき、それをタイムボックスの中で消化していく。タイムボックスは１イテレーション１〜２週間にすることが多いが、重要なのは期間ではなく、小さくスコープ、仕事を分けられているかどうか。 それが明確なゴールへと近づけてくれる。 この点を理解していないと、アジャイルしているとは言えない。 ソフトウェアは物理法則に従っていないため、同じように捉えると痛い目に合う。そして群を抜いて不安定なので、小さく確実に進めたほうがよい。 学び 小さな仮説検証サイクルを回すために小さなタスクをつくる 学びを活かすアイディア・行動 大きな案件は小さいタスクにちぎる

3 賢人による新しいアイデア 3.1 アジャイルへの入門 内容 2000年終わり頃から開発プロセスはアジャイルへと向かっている。 エドワード・デミングは戦後、アメリカからやって来て日本復興のために取り組んだ。 フォーカスしたのは、「無駄をなくし、取り組むべき課題を継続的に改善すること」。 その考え方はトヨタに取り込まれ、トヨタ生産方式となり、やがてアメリカに逆輸入され、リーンやスクラムの基礎となった。 ソフトウェア開発において無駄なのは「着手したものの、完了しておらず、まだ価値を提供していないすべての仕事」という考えで、これをベースにXP、スクラム、リーンが生まれた。 学び アジャイルの歴史を知れた。トヨタ生産方式がアメリカの方が原案を持ってきたんだということを知れた。 アジャイルの基本思想が、「無駄をなくし継続的に改善すること」 学びを活かすアイディア・行動 今は思い浮かばない

2.4 失敗のコスト 2.4.1 ここにも１０億ドル、あそこにも１０億ドル 2.4.2 新しい研究、相変わらず危機 内容 ソフトウェア開発にはとにかくコストがかかっていて２００２年時点ではアメリカだけで年間６００億ドルの損失がある。 コストの内訳を見てみると、リリース後のコストが多く、最大で８０％増しにかかっている。 それは保守性に重きをおいてこなかったから。 学び 保守性はコストで図れるかもしれない。 ランニングコストがどれくらいかかっているかを測るのは重要。 学びを活かすアイディア・行動 何にいくらかかっているか、利益がどれくらいかを出す

2.3 プロジェクトがなぜ失敗するのか 2.3.1 コードの変更 2.3.2 蔓延 2.3.3 複雑性の危機 内容 失敗する理由を大きく分けると２つ。 ビジネスの優先度変化や市場ニーズの変化などの開発側がコントロールできないことが要因 技術プラクティス不足による開発側の要因 技術プラクティス不足が招いてる原因はさらに３つに分けられる。 コード変更ができない バグの修正が時間がかかる 複雑さが増している コード変更ができない大きな改修する場合、多くのチームは既存のコードや設計を理解しようとせず、自分たちのやり方でやる傾向にある。それはコードが複雑でわかりにくいから。結果として一貫性がなくなり、さらに変更しづらいコードになる。 バグの修正が時間がかかる何が時間がかかるかって、大量コードの中からバグを見つけること。どれだけバグを見つけやすい作りになっているかが重要。 複雑さが増している調査によると使っていない機能が45%もある。なのに残っているから複雑になり、バグが見つけられなくなる。バグ修正に時間がかかる件に関連しているが、このせいで開発の80％はバグ修正にコストをかけていると調査結果が出ている。 学び 複雑さが保守不可能にしてる 学びを活かすアイディア・行動 保守しやすいアーキテクチャを考える

1.7 ここにドラゴンがいる 1.8 未知を見積もる 1.9 素人業界 1.10 本章のまとめ 内容 ソフトウェア開発の未知について説明している。 エンジニアは経験から作業を見積もるが、これは結局の憶測を越えない。全部で9ヶ月のPJを8ヶ月目にふたを開けてみたら全体で6ヶ月の遅れがあるなんてこともある。 なぜこんなことになるかというと、単にわかっていないで憶測したから。 業界の冗談で、開発の3つの状態「終わった」「始めていない」「ほとんど終わった」とういのがある。 ドラゴンというのは、モンスターが多くて恐ろしいことや未知なことの例え。 タスクを見積もることができないのはやったことがないから。わからないことが多いから。 見積もりはちゃんとやろうとすると時間がかかる。再利用できるもの、ライブラリの利用などを始め、作ろうとすることに対してもろもろの経験を活かしながら。 しかし、一見似たようなことも進めてみると違っていて、当初の見積もりどおりにならないことがほとんど。 間違った前提で見積もりをすることもある。ウォーターフォールでコーディングに時間をかけずに設計書を最新に保つことに多くの時間を割くのが代表的。これが問題解決の手助けになると信じて作られているが、こういった設計書は実際は殆ど使われず、価値を発揮できないまま捨てられるので、無駄が多い。 ソフトウェア業界は安定して成功できる決まったやり方はまだない。 エンジニアによって多種多様なアプローチをする。その中でもうまくいくのは本当に自分たちの問題を直視し、過去のやり方にとらわれずに勇気をもって踏み出す人たちだけ。 まだまだ未熟な業界だからエンジニアもマネージャーも、ソフトウェアは変化できるという性質と、その必要性を共通認識としてもち、協力して勇気を持って進まなければいけない。 今の業界は全然未熟で、特にウォーターフォールは全然間違っていることが多い。 時代の変化についていくためのソフトウェアづくりのために、みんな目を覚まして真剣に変えていこう。 学び 経験上、「ほとんど終わった」は怪しい。 正確に見積もるのは難しい 自分たちの問題をどんなことでも直視し、他のやり方は参考にすれど、囚われずに考え実践する姿勢がまず大事。特に、コミュニケーションプロセス。多くのジャンルの人達が関連するから。 学びを活かすアイディア・行動 特になし