品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020

ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。

はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。

本記事は前編と後編に分かれています。いまお読みの記事は後編です。

品質とコストのトレードオフ関係も一概

ここでちょっと視点を変えて、Philip Crosbyさんの「Quality is Free」を見てみたいと思います。

というのも、今日のテーマでは品質と開発スピードを天秤にかけていますけど、品質とコストを天秤にかける議論もよくありますね。

このグラフでは、左のグラフのようにコストを上げることで品質が上がるのは94％くらいまでで、それ以上に品質を上げようとするとコストばっかりかかるという、「品質アップ＝コストアップ」説がある。

その一方で、右のグラフにあるように、（品質が悪ければ）不良対応コストとか検査コストや予防コストがあるのだから、品質を上げて不良率がゼロに近づくほどコストが最適に近づきます、という考え方もあります。

これはたくさんの議論を巻き起こしていまして、どちらが正しいかはこの講演のスコープから外れていますが、品質とコストのトレードオフも一概には言えない、ということなんですね。

で、この「Quality is Free」という言葉をうまく品質保証に入れた知人がいるのですが、彼はQuality is Freeのことを品質“実質無料”と言ったんです。

実質無料とは何か。品質を向上させることで手戻りを減らすことができる、本番障害を減らすことができる。するとこれらにかかっていたコストが減る。

つまり品質向上にかかるコストは、品質の向上の結果として減る手戻りや障害対応にかかるコストの減少と相殺されるため、結果的に品質向上は実質無料になると言っているんです。

これは知っている人は知っている事柄について、ポップな呼び名を付けた、いい例だと思います。

品質は制御変数ではない

話を戻しまして、質（保守性）を減らせれば開発スピードが上がる、開発スピードを上げると質が下がる、というトレードオフの関係は典型的な誤解である、ということが分かってきたわけですね。

『エクストリームプログラミング』の中で、Kent Beckは「品質は制御変数ではない」と書いてるんですね。

「むしろ品質を高めることで、デリバリーが高速になることが多い。品質基準を下げてしまうと、デリバリーが遅くなり、予測できなくなってしまう」と、こう言ってるんです。

また、『Clean Architecture』のBob Martinは、「短期的にも長期的にも、崩壊したコードを書く方がクリーンなコードを書くよりも常に遅い」

こう言い切っています。この著者は過激派なのでよくこういう言い切りをしていますが。

『レガシーコードからの脱却』から引用します。

『コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。』

これはとても大事なフレーズです。質を上げたからスピードが増えた。ということが見えてきたわけです。

品質が劣化すれば手戻りが発生するだけで、結局はリードタイムの増加に跳ね返ります。

手戻りをしてる時間は学びを生まない時間です。品質を下げるというのは学びの速度低下を許容するということです。すると、近年のソフトウェア開発にとって大事なフィードバックサイクルにおける仮説と検証のサイクルの回る時間が遅くなります。

よりよいものにたどりつくにはサイクルを速く回さなければなりません。サイクルが遅ければ、よいものにたどりつくまで時間がかかる。

昔は時間単位でのコードを書く量などがソフトウェア開発の大事なメトリクスでしたが、最近ではその代わりに『LeanとDevOpsの科学』で提唱された4つのメトリクスを使うことが増えてきています。

これについて今日は特に深く触れませんが、リードタイムとデプロイ頻度が特にスピードに関するメトリクス。MTTRと変更失敗率が品質に関するメトリクスです。

リードタイムは、書いたコードがデプロイされてお客様が使い始めるまでの時間。デプロイ頻度は分かりますよね。

MTTR（Mean Time to Recovery）は障害が発生してから復旧するまでの時間。これまでは障害が発生しない期間を計るMTBF（Mean Time Between Failure）でしたが、近年はMTTRの短さも品質の高さだと見ましょうと変わってきました。

質とスピードの本当の関係とは

さて、これまで見てきた質とスピードについての考え方を並べてみると、本当の関係は次のようになります。

内部品質がスピードを生みます。スピードが学びのループを生み、ループの回転数を上げると外部品質が上がり、その外部品質が競争力を生み、競争力が売り上げを生み、売り上げが内部品質を育む。

質が上がればスピードが上がり、スピードが上がれば質が上がる。普通に考えられていた関係とは根本的に逆なんじゃないかと言えます。

質vsスピードという概念は根本的に間違っている、と言い出している人もいます。この人はFacebookの伝説的なプログラマEvan Priestleyさん。

「質とスピードは二律背反の関係は局所的なものでしかない。大域的には片方を犠牲にした場合、知らぬうちにもう一方も犠牲にしている」

内部品質や保守性への投資はいつ実るのか？

さて、質とスピードの関係で、質への投資が有効ならば、投資に対する損益分岐点はいつ来るのでしょうか。

内部品質や保守性への投資が、いつ実って開発スピードが速くなるのか。

例えば損益分岐点が3年後になるんですよと言われても、時期的にあまりに遠いし、その頃にまだ会社があるのか、自分がいるかも分からないのであれば、そうした投資へのモチベーションも下がってしまいます。

一例として、保守性を構成する3つの要素の中には「テスト容易性」がありましたね。テスト容易性を強制的に高めて維持する仕組みが「テストの自動化」です。

テストの自動化の損益分岐点がいつになるかは諸説ありますが『Experiences of Test automation』という本から引用すると、およそ4回テストを繰り返すのであれば、（手動でのテストと比較して）自動化されたテストの方がコストが下がるということです。

私が知ってる例でも、3回、4回、5回程度のテストの繰り返しでコストが逆転するというあたりに収束する傾向があります。

そして4回目のテストなんて、すぐやってくるわけです。

近年出た本のなかでとてもよい本に『A Philosophy of Software Design』があります。まだ日本語訳は出ていませんが。

このなかにStrategic approachとTactical approachとの比較があります。Strategic approachは質や保守性に投資しながら進めるもの、Tactical approachはまず短期的なスピードを求めるものです。中長期的にはStrategic approachの方が進捗が早くなるのはこれまでの話でも分かっていますが、それがいつ来るのか？

この本では「あなたが思うよりも早くやってくる」と書いてある。

それはいつか。我らがMartin Fowler先生が、定量化したデータをこのあいだ発表しました。

それによると、短期的なスピードを追って作業するものと、そうでないもののスピードがいつ逆転するかというと、1カ月だと。

1カ月というのはとても大事で、つまり1カ月だと投資に対する受益者が自分たちであるということなんですね。

3年後に報われるとなると、そのときに自分がそこにいるかどうか分からない。それでも質のよいコードを書くためには、プライドとか意識、道徳に依存することになります。

そうじゃなくて1カ月であれば、自分たちが得をする。それを怠れば損をするという、損得の話になります。内部品質の顧客は開発者自身であり、自分たちが当事者であると。

荒ぶる四天王との闘いにはスコープを削れ

というわけで、保守性を犠牲にすれば開発スピードは得られるかというと、短期的には得られるが、1カ月後には逆効果になって、長期的には致命傷になる、ということが言えるようになったわけです。

冒頭の問いに戻りましょう。荒ぶる四天王が出てきたとき、品質を犠牲にしても意味はない。ではなにを犠牲にするべきなのでしょう。

答えはスコープです。

実際には、リリースを優先して機能数を削るか、機能数を優先してリリース日を延期するか、二択です。

ただしリリース日を延期すると、今度は単位時間当たりのチームの生産性がよく分からなくなってくるので、どちらかというとスコープを削ることを選ぶ方がアジャイルなプロジェクトでは多いです。

質とスピードは何に対してトレードオフになっていたのか？

質とスピードがトレードオフの関係にはないとすると、質とスピードはまとめてなにかとトレードオフになっていたのでしょうか。

私がこのようなテーマで話をしてきたなかで得たフィードバックでは、教育とトレードオフになっているのではないか、という意見が多かったですね。

つまり、スピードを上げるのに有効なのは教育をなくすことで、ベテランがよってたかって開発すれば早くリリースできるけど、若者が育つ機会がなくて、組織としては死んでいく。

あるいは、学習や調査に時間をかけて個人やチームの能力を底上げしていくというものを削って、短期的もしくは中長期的なスピードを上げていくと。

質とスピードを上げていくとどんどんモノカルチャーになっていきスピードは上がるが、多様性が失われて変化に弱くなるのではないか。そのあたりを犠牲にしているのではないか。

こういったことが言えるかもしれない。というのが今日の結論です。

ご清聴ありがとうございました。

≫公開されているスライド「質とスピード」（2020春版）