kiyoshi.saito@tttsunagari.jp

1.5 「プロセス」が「忙しい仕事」になるとき 1.6 ガチガチのマネジメント 内容 人は成果を出せないとやる気を失う。初めはやる気があったとしても。 IBMのプログラミングのコメントポリシーは何をやっているかをすべて書くことだったが、これは良くなかった。自明なコメントはコードが読みづらくなったり、シンプルすぎるメソッド名にコメントで注釈を入れて実際のふるまいとメソッド名にギャップがあったり、コメントへの反映し忘れでコメントが嘘になってしまったり。 このような良くないプロセスは忙しさを産み、やる気を無くさせる。 マネージャーは開発者が正しいことをしていると保証したい。 正しいこととは何か？答えられる人はほとんどいない。 ソフトウェア開発でやっていることは、考えること、モデル化、コーディングで、これらは創造的でそれぞれが違うことがほとんど。実質、定量的に図ることは難しい。 正しいことをしたいあまり、プロセスを追加することがあるが、追加すればするほど悪くなる傾向がある。創造性にプロセスは影響しないから、単純に作業が複雑になり創造性を阻害し忙しくなるだけ。 学び コメントはプログラムで表現できないことを書く。 結局の所どうやって計測する？という疑問が出た 学びを活かすアイディア・行動 現場のコーディング規約づくり

1.2 滝（ウォーターフォール）に流される 内容 ウォーターフォールモデルは製造業や建設業をもとにしており、1970年にウィンストン・ロイスが言及したもの。そして彼は「このやり方は機能しないだろう」と次のページに書いていた。どうやら、これまでに誰もそれを読んでいないようだ。 ウォーターフォールは、機能の要求をリリース単位でまとめるような橋の建設や部品の製造では効率的で理にかなっている。しかし、ソフトウェア開発はあらかじめできあがった部品を組み立てるわけではない。一部の部品は事前に用意できるかもしれないが、大部分は、何をしなければいけないかは、その場になってみないとわからないことがほとんど。 だからフェーズをきっちり分けるウォーターフォールモデルは機能しない。 学び 習慣や当たり前を疑う大切さ。 ウォーターフォールはきっちりした計画を立てて進めていかないと意味がないにもかかわらず、ソフトウェア開発は進めてみないとわからない事が多いので、それは難しい。だからバッファを多く取るが、ウォーターフォールでの開発は基本ロングスパンなので早い段階のバッファも信憑性が薄いことが多いと思う。 似たようなソフトウェアを創るのであればバッファの信憑性も上がるが、経験上、一見似ているが、進めてみると結構違うことがあるので、やっぱり計画が難しい。 学びを活かすアイディア・行動 アジャイルプラクティスを学んで取り入れていく

1.1 レガシーコードとは何か 内容 「レガシーコード改善ガイド」著者のマイケル・フェザーズは、テストのないコードをレガシーコードと定義している。 変更のリスクが大きく、事実上、ほとんど変更不可能で、置き換えるしかないようなコード。 保守できないようなわかりにくいコード。 ソフトウェアの延命措置程度の改修しかできないようなコード。 ソフトウェアの作り方の欠点や他の業界との違いを知れば、どのようにレガシーコードが生まれるかがわかり、対処できるようになる。 学び レガシーコードの定義 学びを活かすアイディア・行動 なし

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する。