テストファースト開発、リファクタリング、ペアプログラミング等の解説で評判の高い「レガシーコードからの脱却」ですが、それ以外にも多数の面白い箇所があります。プログラマではなくても楽しめると思いますが、あまりフォーカスされてない所に焦点を当てつつ紹介をしてみようと思います。
書籍情報
David Scott Bernstine 著 吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳
レガシーコードからの脱却 ソフトウェアの寿命を延ばし価値を高める９つのプラクティス
オライリージャパン
出版社サイトページ
面白かったところ その① ウォーターフォールモデルはソフトウェア開発には向かないよ
エンジニアからは好かれていないのに未だにしぶとく生き残っているウォーターフォール。
個人的には十分なバッファがあればそこまで悪くはないと思いますが、バッファが十分ということは開発コストが高いというとこになるので、まあ、その、業務ではいろいろと（ゴニョゴニョ）。
ウォーターフォールも無意識の世界から生まれたわけではないので、何か由来があるはずです。著者はこのように述べています。
ソフトウェア開発のウォーターフォールモデルは製造業や建設業をもとにしており、1970年にウィンストン・ロイスがソフトウェアを作る一連のステージとして言及したのが始まりだ。そして彼は、このやり方は機能しないだろうと次のページに書いていた。どうやら、これまでに誰もそれを読んでいないようだ。
ウォーターフォールモデルは、橋の建設や部品の製造では理にかなっている。機能の要求をリリース単位でまとめたほうが効率的だからだ。だが、ソフトウェア開発は製造プロセスではない。ソフトウェア開発者は、あらかじめできあがった部品を組み立てるわけではないのだ。確かに、一部の部品は事前に用意できるかもしれない。だが、必要としている部品の大部分は、自分たちで開発、修正、そして発明しなければいけない。その上、何を作り、何を修正し、何を発明しなければいけないのかは、その場になってみないとわからないことがほとんどだ。それでも、しっかりしたアーキテクチャーにしなければいけないのだ。
私は組み込み系から開発業に入ったので、ソフトウェア開発とは設計が完了したものをその通りに組み立てることだ、というウォーターフォール的開発を最初に叩き込まれました。「永遠のベータ版」のWeb 2.0的世界とは正反対ですね。
なんでそうなったのかなと考えてみると、最初に浮かぶのは修正コストの違いでした。
私が仕事を始めた当時は、更新パッチをインターネットで配布してユーザーが更新するという事がまだ一般的ではなかったので（携帯も3G回線しかなかったし、家庭用ネットもADSLが大半）、バグを残したまま出荷するとメーカーが１個ずつ回収してアップデートして返却しなければなりませんでした。バグ１個で数千万円の損害だとチームリーダーから聞いたこともあります。
アジャイル的に反復しながら品質を向上させていく手法は、完全な品質と期限の厳守を要求する当時の現場では「いつ完全な品質になるんだ？そんなに金をかけていられん」という風潮が強かった覚えがあります。
あれ？今でもありそうな話だな・・・。
ソフトウェアは更新しつづけるものとして、筆者はこのように続けています。
結局のところ、まとめて何かをするのは仮想環境ではうまくいかない。
まとめて何かをするのは非効率なだけではなく、さまざまなリリースサイクルの流れを見るのも非効率であることの触れるつもりだ。こういうやり方は変更不可能なものを作ることを強いられる。細かい点ではあるが、極めて重要なポイントだ。
インクリメンタルに作るときだけ、あとで拡張できるようにジョイントをつけられる。リリースにあわせてソフトウェアを作るように最適化していると、このようなことは考えもしないだろう。ウォーターフォールの世界では、優先順位もなければ、課題もない。家を作るときに、誰もあとで部屋が必要になるなどとは考えもしない。設計図に従って家を作るだけだ。家に部屋を追加するということがどれだけあるだろうか？ソフトウェアに新しい機能が追加される頻度と比べてほしい。
ハードウェア開発の方法をソフトウェア開発に持ち込んでも、ソフトウェアの変化速度はハードウェアのそれよりもずっと早いのだからミスマッチなんですね。
面白かったところ その② バグだ！バグだ！巣をつぶせ！
バグは氷山の一角にすぎない。１つのバグを直すあいだに、ほかの複数のバグを直すことになる。ソフトウェアの構造は絡み合っていることが多く、１つのバグを直すともぐら叩きのような状況に陥る。数分で直ると思っていた修正が、システム全体に到達する変更の波となることもあるのだ。
せやな！（白目）。
バグは1匹見たら30匹。リアルバグと違って勝手に繁殖はしないけど、一般に１つしかない問題がたまたま１つ見つかるということはまずないです。問題は結果で、問題を生み出すプロセスの存在そのものが生きている限り幾つもの問題を生み出しているはずです。経験則ですけど・・・。
この手の問題追及と根本対策は経験と勘がものをいいますが、それだけに頼るのも厳しいので、真に対処するべきことは何なのかを探すのにTOC（Theory of Constraints/制約条件の理論）の現状問題構造ツリー1を使うと手助けになります。別の本なので詳細は省きますが、ザ・ゴール２2にその辺りのことが説明されていますのでこちらもお勧めです。
面白かったところ その③ １人月足りないけど、１人増やしたいってことじゃないからー
古くは人月の神話3から言われ続けている人月でのスケジューリング問題。人を足しても足した人の数だけコミュニケーションコストが増えるので、3人足したら3人月の開発力が増えるわけではないですね。私の経験だと追加された人は必要なスキルが備わっていても既存メンバーの7割働ければ十分といった感じでした。たまに3倍くらい働くメタルスライム4みたいな人もいますけど。
でも、人を足すことの注意点はコミュニケーションコストだけではないですね。なぜかというと、大抵の場合予算をつけて人を足す側の人は、コミュニケーションコストがあるからといって、１人足して１人月未満の仕事をすることは許してくれないからです。
製造では並列化のルールがある。２つの完全に独立した組み立てラインの場合には、生産性は倍になる。だがソフトウェアでは、人同士のやり取りがとても多い。そのため、人を追加すればするほど、やり取りが増えて速度が落ちていくのだ。組み立てラインでの機械的なタスクはそれぞれが完全に独立しているが、ソフトウェア開発にはそのようなタスクは含まれない。プロジェクトに多くの人を追加すると。コミュニケーションと調整がより多く必要になる。これによってプロジェクトはスピードが上がるのではなく下がるのだ。
人を追加できず、リリース日を約束していて時間も延ばせず、それでもマーケティングがすでに約束してしまった機能を出荷しなければいけないとしたら、何を捨てるだろうか？
開発者はそれが何かわかっている。自分達がコントロールできるたった１つのものだ。
そう。自分達の作業の品質だ。そして、品質は自分たちが絶対に犠牲にしたくないものの１つだ。
またまた経験則になりますが、品質の低い製品は開発者の作れる最上級の製品品質が低いからではなく、スケジュールと引き換えに品質を落としてなんとか納期に間に合わせるというトレードオフの結果そうなることが多いです。では必要な品質を保つためにはどうすればいいかというと、できないことは約束しないという社会人としては「やる気あるのか」「そうか、そうか、君はそんなやつなんだ5」「精神的に向上心のないものは馬鹿だ6」と叱咤されそうな結論になります。
でも、仕事ができる人というのは、この線引きがきちんとできていて、そのレベルが高いということに他ならなかったりします。
あまり内容の紹介ばかりしても本書に悪いので今回は3つの点について紹介しましたが、私は167箇所に付箋をつけたので本書を読めば55倍は発見があるはず！いろいろと考えながら読む本なので時間はかかるかと思いますが、年末年始に一冊いかがですか？
注釈
-
数ある問題は１つまたは２つの根源的問題から派生した症状であるという考えに基づいて、根源的問題を探るための図法。 ↩
-
複数の問題を抱える工場を改革するために問題解決手法で立ち向かうビジネス小説。https://www.diamond.co.jp/book/9784478420416.html ↩
-
人月工数管理はうまくいかないよ。https://www.seshop.com/product/detail/3509 ↩
-
ドラゴンクエストシリーズに出てくるモンスター。速い、強い、経験豊富。 ↩
-
国語の教科書に掲載されていたヘルマン・ヘッセの「少年の日の思い出」の一節。罪を告白した主人公に怒るでも許すでもなく、静かに侮蔑するエーミールは授業を受けた学生たちを嫌な気持ちにさせた。同様の小説はヘルマン・ヘッセ全集６巻に「クジャクヤママユ」という題名で掲載されれいる。 ↩
-
これも国語の教科書に掲載されていた夏目漱石「こころ」の一節。授業の後の夏休みでこころの読書感想文を提出する生徒が続出した。 ↩