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

1. 何かが間違っている 負のスパイラルの原因は「レガシーコード」が原因という側面がある。そうならないために技術プラクティスがどのように機能するかを理解し実践すると、負のスパイラルにはならない。ということを長い例え話で説明している。 負のスパイラルの例チームの中心的な開発者たちは優秀だった。 一方で、チームにはコードモンキーがいて、自分の機能を作ることだけしか見ていなかった。その機能が全体にどう影響するかは考えておらず、彼らの仕事のいくつかが短期間で大きな問題を引き起こし、そのあとさらに大きな問題を引き起こすことに気づいていなかった。 チーム全体は、技術プラクティスの背後にある理由を理解してはいなかった。しまいには、あっちこっちで異なる標準を使って作業を進め、システム全体は見ていなかった。 そして、賢くて経験豊富なエキスパートがリードしていたのにも関わらず、ソフトウェアは扱いづらいものになった。 コードの統合は、誰も楽しみにしていない悪夢のような体験になった。 重量級のソフトウェア開発プロセスは大きな妨げになっていて、もはやまったくコードを生み出せないほどだった。 マネージャーたちも賢くて経験豊富だったが、結局、開発者と同じようにイライラしやる気を失った。もう、開発者に何を指示すればよいかわからないかのようだった。 組織内に信頼はなかった。 そこで経営陣は、多くのプロセスを追加する対応を取った。それがさらに信頼を損ね、締切がさらに変更となった。 会社全体が死のスパイラルに陥っていて、7億5,000万ドルの事業全体が危機に瀕していた。 会社は過去10年間で飛躍的に成長したにもかかわらず、結果としてコードはひどいことになっていた。この会社は何年にもわたって「アジャイル」を進めようとしていたが、多くのチームでアジャイルプラクティスのいくつかを導入すると、既存のコードがいつも邪魔をした。既存のレガシーコードと、こんな状況になるまで蓄積してきたすべての悪習の両方に対処しなければいけないことを彼らはわかっていた。 私は、この問題を「人の問題」ではなく「レガシーコードの問題」だと考えた。 学び アーキテクチャや設計を考慮せず、言われたことだけやるプログラマをコードモンキーと言うのか。 長い例え話に思いが詰まっていることが伝わる。そして共感する部分もある。 経験が浅いうちはやる気があっても視野が狭かったりスキルが追いつかなかったりで、実質コードモンキーの時期はある。 学びを活かすアイディア・行動 キャリア整理のための資料作り

はじめに 内容 本書は開発と保守のコストを下げるために書いた。内容は、開発者、マネージャー、顧客（システム担当）それぞれが、ソフトウェア開発そのものの理解を深めることを目的に、９つのプラクティスに焦点を当てて説明する。 開発者は変更可能なコードを書くための原則とプラクティスを学べる。マネージャーはそのプラクティスへの投資の仕方を学べる。そして開発者、マネージャー、顧客間のコミュニケーションギャップを埋めるサポートとなる。 レガシーコードがもたらす損失私達はレガシーコードのせいで、開発より保守にコストをかけて、チャンスを失っている。アメリカだけで年間何十億ドルも損失している。本書でのレガシーコードの定義は「理由はなんであれ修正、拡張、作業が非常に難しいコード」のこと。 ソフトウェア開発は他のものづくりとは違うソフトウェア開発は物理的なモノの開発とは大きく異なる。この業界の問題における原因の1つは、この認識を間違って捉えていることかもしれない。ソフトウェア開発を理解し予測可能にしようとする中で、製造業や土木業と比較されてきたが、ソフトウェア開発は「より変更可能」にするために特化したプラクティスが必要で、他とは違うのである。 プラクティスを使い、ソフトウェア開発での短期的なコストを減らし、問題となりやすい長期的な保守コストも削減のサポートとしてほしい。 注意紹介するプラクティスは重要性の説明に重きを置くため、HowToはそんなに書いていないので、HowToを見たい場合は具体的な参考書籍があるのでそちらを見てほしい。この本ではプラクティスの背景にある原則や目的を理解し、「なぜ」それを適用させるのかということを議論できるようになることに価値をおいている。 学び ソフトウェア開発は他の物理的なものづくり業界のノウハウを参考にされてきたが、ソフトウェアの特性である「変更しやすさ」にフォーカスしたときに、もう他の業界とは別のアプローチをしていかないと、変更しながら時代についていけないということを結論付け、今後はより「変更しやすさ」のためのアプローチを磨いていかなければならない。でないと、今後も無駄な損失を多く出すことになる。 学びを活かすアイディア・行動 特になし。

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できるようにするところを目指す ストラングラーパターンでシステムをリファクタリングする 機能追加の前準備と、実際の機能の追加を切り離すことで、作業が大幅に単純化され、バグ発生リスクが減る 学び なし 学びを活かすアイディア・行動 なし