Month: January 2021

14.7 成長する勇気 内容 私たちは未知なものを恐れるあまり、失敗したとしても同じことを繰り返してしまいがち。それは、成功するかもしれないがまだリスクが見えない新しいことをするよりも、リスクがわかっている失敗を繰り返す方が計画が立ってマシだと思ってしまう傾向にあるから。 人間は、成功でも失敗でも現状に変化を脅かすものであれば潜在的に恐怖を感じているという。 しかし、新しいものは未知なるものの内側にある。そこに至るには勇気がいる。 本書で紹介したプラクティスを実践する勇気を持つには、まずソフトウェアの性質を理解して、「なぜそのプラクティスをやるか」を理解する必要がある。その上で、一度成果を出せれば怖くなくなっているはず。 さらに言うと、経験上、チーム全員が「なぜやるか」を理解し全員が「やりたい」と願い、主体的に動けるようになっているチームが成功している。 そして、マイクロソフト、IBM、Yahoo、さまざまな企業を見てきたが、問題解決の方法は、本当にさまざまで、すべてが正しい。 本書のプラクティスを実践して、現状の改善に役立ってほしいし、目的を意識しながら、さらなる新しい良いやり方を模索しながら、ソフトウェアを作り上げていくことを願っている。 学び 本書のプラクティスはエンジニアに安心感を与えるものだが、実践するにあたり、やったことがあるかのような安心感がないと一歩を踏み出す勇気が持てないかもしれない。 学びを活かすアイディア・行動 プラクティスでできる小さなことを実践し、少しずつ実績を積む。

14.6 理解を体現する 内容 今後も便利なツールは増え今とはまったく違った形でソフトウェアを考え出して提供しなければいけなくなるだろう。 だが、慌てずに、常に一歩戻って「理解するための効果的な手段」に手を伸ばさなければいけない。 良いソフトウェアを作るための公式はない。今後もないだろう。良い本、良い曲、良い脚本、良い絵を創るための公式がないのと同じ。 従うことのできる指針、活かすことのできる技術、習得できる（そのあと破ることができる）法則、利用できるプラクティスが「ツール」としてあり、結果はツールをいかにうまく使いこなせるかにかかっている。 しかし、ツールが強力になればなるほど、適用を誤りがちになる。のこぎりよりチェーンソーのほうが多くの木を切れるが、自分自身を傷つけるのも簡単で、ソフトウェア開発でも同じことが言える。 ドメインを正確に理解し正確にモデル化するという原則に則り、その理解が壊れないようにツールを適用していくことが大切だ。 理解を体現することが良いソフトウェアを作るということだ。 学び 良いソフトウェアはドメインの正確な理解とモデル化から生まれ、ツールはそれを助けてくれる。しかしツールは、便利な反面、理解するために思考する機会を奪ったり、正確なモデル化を阻害する可能性が、いつもあることを理解し適用する必要がある。 学びを活かすアイディア・行動 今の所思い浮かばない。

14.4 ソフトウェア職のスキルを高める 14.5 アジャイルの向こうへ 内容 1990年代には、ソフトウェアを作るための新しい技術が競争優位性だと考えられるようになっていて、開発方法が企業に閉じていた。 しかしこれは健全ではなく、方法論は業界内で共有すべき。且つ企業は独占的なソフトウェアを独占したままにすることに重点的に取り組むべき。 だから企業の機密は漏らさずに方法論だけ共有するような自己規制は必要。 その上で、この業界のエンジニア全員が進歩し、支え合うのがベスト。 例えば、医師は命を救うことにつながる情報を別の病院の医師に渡さないというのは、倫理的ではない。ソフトウェアはビジネスに直結しているから、ソフトウェア開発者にも同じことが言える。（医療で言えば医療システム。） さまざまなプラクティス、パラダイムなどのツールが公開されてきて未来は明るくなってきている。しかしまだまだ困難は脱していない。 「私たちはソフトウェア開発者だ。現在利用可能なツールを最大限に活用して、ソフトウェアを開発している。」 将来はアジャイルよりすぐれたやり方が生まれ、現在のやり方でソフトウェアを作ることは、機械語でコードを書いている人たちを見るような目で見られるようになるだろう。 しかし、ソフトウェア開発は、ドメインを正確に理解し、正確にモデル化しないとうまくできないということは変わらないだろう。 そのために創造力を働かせながら多くのスキルを習得するプロセスは変わらないだろう。 学び 独自のサービスを磨いて価値を発信することは重要だ。そしてそのプロセスを可能な限り公開し、業界のソフトウェア開発者に影響し、ともに成長するスパイラルを作ろう。それが結果として自分たちのサービスを磨くことにもつながる。 方法を秘密にして、Win-Loseの形になるようでは発展しない。 エンジニアは、変化に適用していくため本当に多くのことを学ぶ必要がある。そのモチベーションのために、自分が関わっているビジネスに動機を持っているかどうかは超重要。 学びを活かすアイディア・行動 まずは現場でノウハウ共有会 イベントへの参加で開発プロセスを学んだり、継続的な学習

14.3 まっすぐで狭いところを歩く 内容 プラクティスで効果を上げるには、プラクティスの目的を理解して実践するのが早道。目的を理解しないと、習得するのに12か月以上もかかったり、効果的にできなかったりする。 開発者の最大の見過ごしの１つは、エンティティを正しくモデル化しそこなうこと。それがメソッドを置く場所をわからなくさせ、わかりにくいコードになり、バグを生む。そして問題が起きてから後手後手に「火消し」をするようなスパイラルにつながる。 先手先手で進むにはじっくり考える必要があり、遅くてもいけない。テストファースト開発では、テストを書くことは正しい理解をすることが含まれ、コードの正しさを担保する役割も持つ。そして創発設計しながらさらに理解を深め、モデル化していく。 ソフトウェア開発は先手先手で正しく進むことが難しいが、テストファースト開発はそれをするための１つの方法と言える。 学び TDDは先手先手で正しく進むための方法の１つ 学びを活かすアイディア・行動 簡単な案件をペアプロでTDDする。

14.2 不要な出費はしない 内容 保守性に注力し「CLEAN」でテスト可能なコードを書くことが、ソフトウェアを保守するにも拡張するにもコストを下げる唯一の方法だ。 開発チームの中には、テスト駆動開発（TDD）をしておらず、QAプロセスをあてにして、開発者がコードに関するフィードバックをもらうのに2週間もかかるチームもある。そしてバグを修正するために数週間前に書いたコードを思い出す。そのために開発者の1日のほとんどを費やすようになる。同じバグならTDDで数秒でバグを直すほうが、よほど安くて済む。 本書でも言ったがQAが不要というわけではない。しかし、QAプロセスで品質を保証するだけよりも、良いプラクティスを使って品質を作り出すことに取り組もう。 学び CI/CD、ペアプロ、TDDなどのプラクティスは品質につながるものだが、最終的にランニングコスト削減につながる。ランニングコストが減るから続けることができる。 テストを自動化しリファクタリングしやすい状況を作り、リファクタリングして保守しやすいコードを作り、減った改修コストで更にテストとリファクタリングをする、というサイクルを作る努力をしよう。 学びを活かすアイディア・行動 CI/CD環境構築 テストコードの運用 簡単な案件のペアプロでペアプロ力を増やす

14.1 もっと良く速く安く 内容 アジャイルプラクティスの各種効果事例を紹介している。 それらによりテスト駆動開発（TDD）は「テストも書くのでコードは倍書くが、質もスピードも上げることができる」と論理付けている。開発者はコーディングとテストに時間を費やしているわけではない。仕様書の解読、ドキュメント作成、会議出席にも時間を費やすし、いちばん多くの時間を浪費しているデバッグ。 TDDはバグを意図的に発生させ修正しながら進める。「それがバグであること」と「修正が正しいこと」を仕様となるテストコードで担保しながら開発を進める。そしてコード変更のたびにテスト実行するため、後で意図しないバグ発生を抑え、デバッグの時間を減らすことができる。 生産性を向上させるのに、品質低下の犠牲を払う必要はない。 以下、論文や調査事例を紹介。 QSMA社によるアジャイルプラクティス導入効果調査 ウォーターフォール 欠陥率が大規模チームであるほど高い。 平均の４倍以上の場合もある。 XP、スクラム 欠陥率が平均より30%〜50%減。 論文：Realizing Quality Improvement Through Test-driven Development: Results and Experiences of Four Industrial Teams（テスト駆動開発を通じた品質向上の気づき：4つの事業チームの事例から） 調査対象のTDDを実践しているすべてのチームが欠陥密度の大幅な低下を示し、「テスト駆動開発は開発チームは生産性を大幅に減らすことなく、開発したソフトウェアの欠陥密度を大幅に減らす」ことができるとしている。 IBMのチーム → 40%減 マイクロソフトのチーム → 60%〜90%減 論文：Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies（テスト駆動開発の有効性評価：業界事例） 同じ組織で、TDDを使ったプロジェクトと使っていない似たようなプロジェクトで、使った方がコード品質が2倍以上良い。 ノースカロライナ州立大学のボビー・ジョージとローリー・ウィリアムズによる２つのソフトウェア開発者のグループ調査 テスト駆動開発者は 高品質なコードを生み出した 18%多くブラックボックステストをパス 開発できる時間が16%も長くなったにも関わらず、テスト駆動開発者のテストケースは平均「メソッドの98%、命令文の92%、分岐の97%のカバー」を達成。 開発者の92%が「テスト駆動開発は高品質なコードを生み出す」と信じていることもわかった Exploring Extreme Programming in Context: …

14 レガシーコードからの学び 内容 紹介した９つのプラクティスによって保守可能なコードができ、それによって保守コストを下げることができ、それによってユーザーに価値を提供し続けられることを知った。 特に、テストファースト開発、リファクタリング、ペアプログラミング、設計スキル、継続的インテグレーションといったXPの技術プラクティスが、開発成功の鍵。 アジャイルもXPもソフトウェア開発者がソフトウェア開発のために始めたものであるにもかかわらず、それが正しく定着していない。 オブジェクト指向プログラミングが一般的になったのは1990年代だが、うまく活用し保守性を高められた人は少なかった。 スクラムはXPを支えるはずだったが、技術的なプラクティスはそれほど重きを置かれず、マネジメントプラクティスになってしまった。経験上、アジャイルの本質的な価値は技術プラクティスを適用することによって得られる。だから技術プラクティスはマネジメントプラクティスと同じくらい重要。 プラクティスを正しく使うためには根本にある原則を理解する必要がある。開発者もマネージャーもそれを理解する必要がある。 ここで紹介したプラクティスを「習得する」のは一つのゴールと言える。 学び アジャイル開発シーンには紹介されたプラクティスがいくらか適用されていることが少なくない。しかしそれを開発者が意識してない場合があり、それぞれのプラクティスの習得に向けた動きが出来ていないことは多い。 開発者が意識できていない理由として、以下が思い当たる。 プラクティス適用を明言していない。明言しないと、フォーカスした取り組みが難しくなる。例えば、経験の浅いメンバーへの教育が出来ないし、いちメンバーとして習得に対しての学習効率も悪い可能性がある。プラクティスの適用は、チーム内のレベル感は置いておくとしても、明言することが大事だと感じた。 また、プラクティス習得をトライはしたが、納期の関係などにより、未熟なまま一時中断し、そのまま陳腐化してしまった場合も考えられる。 プラクティスの習得には時間がかかるが、習得しないままだと本質的なプロセス改善はできない。既存の慣れた方法で開発しながらも、同時に練度を上げる方法を考えて進めたい。 学びを活かすアイディア・行動 現場で簡単な案件をペアプログラミング。 現場でCI/CD環境構築

13.10 本章のふりかえり 内容 13章の内容のふりかえり。 効果的なリファクタリングの観点 オープン・クローズドの原則 機能追加する場合、変更前に変更するためのリファクタリングをする DIできるようにするところを目指す ストラングラーパターンでシステムをリファクタリングする 機能追加の前準備と、実際の機能の追加を切り離すことで、作業が大幅に単純化され、バグ発生リスクが減る 学び なし 学びを活かすアイディア・行動 なし

13.9.2 いつリファクタリングを行うかについての７つの戦略 内容 リファクタリングできるコードはかなり多いはずだ。基本的に触ることもないし、拡張する必要もないコードはリファクタリングしなくてもよい。ここでは何をいつリファクタリングすれば効果的なのかを判断するための７つの戦略を紹介。 戦略 説明 重要なコードがうまく保守されていないとき 明らかに主要機能で、今後も修正は見込まれるけど、複雑になりすぎている場合。まずはテストコードから追加しよう。 コードを理解している人がいなくなったとき いなくなる前に、関連コードを修正する場合は、そのキーパーソンがクリーンアップしよう。基本全員が扱える状態を目指そう。 新しい情報によって、より良い設計が見つかったとき 今の設計を改修するコストよりもメリットが大きい場合リファクタリングが選択肢となる。 バグを修正するとき テストがなかったからバグが発生したと考えることができる。テストを書いてついでにリファクタリングするとよいだろう。 新機能を追加するとき 安全に機能追加する方法は、まず機能追加できるようにリファクタリングしてから機能追加すること。 レガシーコードのドキュメントを書くとき 難解なコードを理解するためのドキュメントに起こすとき。製造中であれば設計を見直し、リファクタリングできるか検討しよう。 作り直すより安いとき 同じような開発プロセスで作り直す場合、高い確率で同じような技術的負債を産む。リファクタリングをプロセスに組み込む方が安くなるか検討しよう。 学び リファクタリングできるタイミングは意外と多い 学びを活かすアイディア・行動 何をいつリファクタリングできるか整理 リファクタリング内容と関連しているコードの整理

13.9 実践しよう 13.9.1 リファクタリングから価値を得るための７つの戦略 内容 リファクタリングから効果的に価値を得るための７つの戦略を紹介。 戦略 説明 既存のシステムを学ぶ わかりにくいところは全部反面教師。 小さく改良する メソッド、クラスの移動、名前変更はツールで安全にできる。これを先にやるとロジックの修正がしやすくなる。 レガシーコードをテストで改良する リファクタリングは後々の開発コストを減らすことができる。テストはリファクタリングを安全にサポートする。まずテストを書こう。 クリーンアップしながら進める 開発を進める中、常にリファクタリングは行おう。 詳細がわかったら実装を再設計する 既存の設計では実現が難しい場合や、明らかに既存設計より良い設計が出た場合、今後を見越して再設計実施を検討する。 進む前にクリーンアップする 動作確認したら次に進む前にかならずリファクタリングする。 やってはいけないことを学ぶリファクタリング リファクタリングには良い学びがある。間違いを認識し、良いプラクティスを積み上げよう。 学び これまでのまとめなので、特になし 学びを活かすアイディア・行動 現場メンバーへの展開