質とスピード〜ソフトウェア開発の典型的な誤解を解く〜（2020 秋バージョン）
Nov 20, 2020 @ JaSST'20 Kyushu 基調講演

和田 卓人 (@t̲wada)

自己紹介t-wadat_wadatwada📷🙆 📹🙅
🙆 #jasstkyushu

自己紹介

t-wadat_wadatwada📷🙆 📹🙅
🙆 #jasstkyushu
illustrated by @mty_mno

技術書の出版に関わっていますよろしくお願いします

illustrated by @mty_mno#jasstkyushu

荒ぶる四天王があらわれた！

与えられた時間に対してやるべきことが多すぎる場合、どうすべきか?
a) スコープを削るb) もっと人を増やすc) リリース日を延期する

d)
品質を犠牲にする👉『アジャイルサムライ』 p.86

品質を犠牲にすればスピードは得られる？
•短期的には得られる•中期的には逆効果になる•長期的には致命傷になる「短期的/中期的」の境目は？
ここでいう「品質」とは？

「短期的/中期的」の境目は？
ここでいう「品質」とは？

“品質とは誰かにとっての価値である”-- Gerald Weinberg
https://www.amazon.co.jp/dp/432002706X

"ilities"
Accessibility

Functionality

Portability

Transactionality

Adaptability

Installability

Recoverability

Understandability

Administrability

Integrability

Reliability

Upgradeability

Analyzability

Internationalizab
ility

Replaceability

Usability

Auditability
Availability
Calibrability
Changeability
Compatibility
Configurability
Exploitability
Extensibility
Flexibility

Interoperability
Learnability
Maintainability
Marketability
Maturity
Modifiability
Operability
Personalizability

Reusability
Scalability
Security
Sensitivity
Stability
Suitability
Supportability
TestabilityTraceability... and lotsmore!

狩野モデルhttps://www.juse.or.jp/departmental/point02/08.html

（お客様から）見える品質と見えない品質•外部品質と内部品質•利用時の品質と製品品質•機能要件と非機能要件

外部品質と内部品質

External Quality:
Correctness, Usability, Efficiency, Reliability,Integrity, Adaptability, Accuracy, Robustness
Internal Quality:
Maintainability, Flexibility, Portability,Re-usability, Readability, Testability,
Understandability

ソフトウェアの品質を外部指標で特徴づける人は多い。正しいことをする、バグがない、速い、などだ。だが、それらはより深い原因の症状にすぎない。
本書で説明するソフトウェアの品質は内部品質である。内部品質を作り込んだ結果として、外部品質として定義される特性の実現に近づくことができる。内部品質は結果ではなく原因であり、良いソフトウェアが備えているべきものだ。

『レガシーコードからの脱却』p.58

内部品質（Internal Quality）

External Quality:
Correctness, Usability, Efficiency, Reliability,Integrity, Adaptability, Accuracy, Robustness
Internal Quality:

自分たちの射程内にある内部品質の方を犠牲にするという判断をしがちなのではないか

Maintainability, Flexibility, Portability,
Re-usability, Readability, Testability,
Understandability

質とスピード〜ソフトウェア開発の典型的な誤解を解く〜

和田 卓人 (@t̲wada)内部品質とスピード〜ソフトウェア開発の典型的な誤解を解く〜

和田 卓人 (@t̲wada)

ではどのような内部品質を犠牲に捧げたのか

内部品質（Internal Quality）

External Quality:
Correctness, Usability, Efficiency, Reliability,Integrity, Adaptability, Accuracy, Robustness
Internal Quality:
Maintainability, Flexibility, Portability,
Re-usability, Readability, Testability,Understandability保守性（Maintainability）

External Quality:
Correctness, Usability, Efficiency, Reliability,Integrity, Adaptability, Accuracy, Robustness
Internal Quality:
Maintainability, Flexibility, Portability,
Re-usability, Readability, Testability,Understandability

保守性
Maintainability

Boehm, Brown, and Lipow's 23 Quality Characteristics (1976)

https://www.thomasalspaugh.org/pub/fnd/ility.html

Boehm, Brown, and Lipow's 23 Quality Characteristics (1976)

https://www.thomasalspaugh.org/pub/fnd/ility.html

Boehm, Brown, and Lipow's 23 Quality Characteristics (1976)

https://www.thomasalspaugh.org/pub/fnd/ility.html

Maintainability（保守性）を構成するもの•Testability: テスト容易性•Understandability: 理解容易性•Modiﬁability: 変更容易性

自動テストにおけるテスタビリティ• 実行円滑性（Operability）• 自動実行が容易でかつ高速• 観測容易性（Observability）• テスト結果の取得・期待値比較を自動化しやすい• 制御容易性（Controllability）• 事前状態を制御し、テスト対象を自動操作しやすい• 分解可能性（Decomposability）• テスト対象の切り出し、テスト環境への部分置換が容易
https://speakerdeck.com/goyoki/testability-in-embedded-software内部品質とスピード〜ソフトウェア開発の典型的な誤解を解く〜

和田 卓人 (@t̲wada)保守性とスピード〜ソフトウェア開発の典型的な誤解を解く〜

和田 卓人 (@t̲wada)

保守性を犠牲に捧げるとどうなるか「あとでクリーンにすればいいよ。先に市場に出さなければ！」
開発者はそうやっていつもごまかす。だが、あとでクリーンにすることはない。市場からのプレッシャーは止まらないからだ。「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるということである。競合他社に追い抜かれないためには、これからも走り続けるしかない。
その結果、開発者はモードを切り替えることができない。次の機能、また次の機能、またまた次の機能を追加することになり、コードをクリーンにすることまで手が回らない。
そして、崩壊が始まる。生産性がゼロに近づいていく。
『Clean Architecture』 p.38

https://twitter.com/nekoya/status/496947962182791168

保守性の低さがもたらすもの

ひとつひとつの変更に余計な時間がかかる

https://martinfowler.com/articles/is-quality-worth-cost.html

保守性を犠牲にすればスピードは得られる？
•短期的には得られる•中期的には逆効果になる•長期的には致命傷になるではスピードを落とせば保守性は上がる？

https://twitter.com/voluntas/status/1014316381041381376

技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。
逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。

https://osa.hatenablog.com/entry/2017/05/31/233319

クイック&ダーティの神話

経営的な要求に合わせて、与えられた開発期間から柔軟に汚さと速さを選択するというような器用な芸当はほとんど不可能だといえます。これは、極めて基礎的なところであれば多少はできるかもしれませんが、実際には、ソースコードが汚くて遅い人もいれば、綺麗で速い人も多くいます。
『エンジニアリング組織論への招待』 p.255

つまりトレードオフではないhttps://twitter.com/katzchang/status/1171080561948942336

トレードオフと考えるのは典型的な誤解質(保守性)

スピード

白丸付き矢印: 負の接続 = 根元が増えれば先は減る。根元が減れば先は増える品質を犠牲にするのは、効果的なコントロール方法ではない。品質は制御変数ではない。
低品質を受け入れることで、プロジェクトが速くなることはない。
高品質を要求することで、プロジェクトが遅くなることもない。
むしろ品質を高めることで、デリバリーが高速になることが多い。
品質基準を下げてしまうと、デリバリーが遅くなり、予測できなくなってしまう。
『エクストリームプログラミング』 p.30

先ほどの開発者のごまかしは、崩壊したコードを書けば長期的には遅くなるものの、短期的には速度が上がるという考え方にもとづいている。
このことを信じている開発者は、崩壊したコードを書くモードから、いずれどこかでクリーンにするモードに切り替われる、という（ウサギとカメの）ウサギのような自信を持っている。
だが、それは事実誤認である。
事実は、短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。
『Clean Architecture』 pp.38-39

短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。
-- Bob Martin『Clean Architecture』 p.39

最高の開発者がいちばんきれい好きな開発者であることに気づいたとき、私はびっくりした。速いプログラマーは雑なプログラマーだと思っていたからだ。
だが、実際は正反対だった。私が会った中で最速のプログラ
マーは、コードを扱いやすいように保つことに特に注意を払っていた。

『レガシーコードからの脱却』 p.49

コードを書く速さとコードのきれいさに関連があると認識した
あとでも、私はその2つのあいだの因果関係を見つけるのに時間を要した。
コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。
このことを理解したら、ソフトウェア開発に対する見方が変わった。
『レガシーコードからの脱却』 pp.49-50

コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。
-- David Scott Bernstein『レガシーコードからの脱却』
pp.49-50

コードの品質を犠牲にしたから速いのではなく質(保守性)スピード

白丸付き矢印: 負の接続 = 根元が増えれば先は減る。根元が減れば先は増える

コードの品質を高く保っていた「からこそ」速い

質(保守性)

スピード

矢印: 正の接続 = 根元が増えれば先も増える。根元が減れば先も減る

ではスピードから質への影響はどうか

ではスピードから質(保守性)への影響はどうか

質(保守性)

スピード

品質は劣化すればリードタイムの増加に跳ね返る

品質は悪いと基本的に手戻りを生むので速度に跳ね返る。手戻ってる時間は学びをうまない時間。品質を下げるという判断は学びの速度低下を許容するとこと。
従来の鉄板(だと誤解されていた)だった品質すてて速度あげようは品質は劣化すれば手戻りが発生するだけで、結局はリードタイムの増加に跳ね返るのでやめましょう。

http://i2key.hateblo.jp/entry/2017/05/15/082655

リードタイムが増加すると仮説検証プロセスが回らない

http://i2key.hateblo.jp/entry/2017/05/15/082655

本当の関係本当の関係•内部品質がスピードを生み•スピードが学びのループを生み•学びのループが外部品質を生み•外部品質が競争力を生み•競争力が売上を生み•売上が内部品質を育む※良いものを作れば売れるというわけではないので、ここはそう簡単でも単純でもない本当の関係"質"スピード

矢印: 正の接続 = 根元が増えれば先も増える。根元が減れば先も減る

「質v.s.スピード」という概念は根本的に間違っていると思う。
だって素早く開発をしなくては環境、あるいは自分の環境の理解の変化にソフトウェアがついてこれず、ソフトウェアが解決すべき問題が解決できなくなり、必然的に質が落ちてしまう。
逆に、質の高いソフトウェアを書かなくては、なにかある度にインフラが崩壊し、素早く開発をすることができなくなってしまう。インフラの崩壊は、やる気を削ぐので特にたちが悪い。

Evan Priestley
https://knoh.jp/answers/d65c7a82/

質v.s.スピードという二律背反の関係は、局所的なものでしかない。
大域的には、片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしているということをお忘れなく。
Evan Priestley
https://knoh.jp/answers/d65c7a82/

現代における質とスピード: 4つのキーメトリクス•リードタイム•デプロイ頻度•MTTR(平均修復時間)•変更失敗率https://www.amazon.co.jp/dp/4295004901/

リードタイムとデプロイ頻度: 仮説検証プロセスを迅速に回す

http://i2key.hateblo.jp/entry/2017/05/15/082655

リードタイムとデプロイ頻度: フロー効率とリソース効率

リソース効率

フロー効率

http://i2key.hateblo.jp/entry/2017/05/15/082655

MTTR: Mean time to Recovery/RepairMTTR

https://www.slideshare.net/decode2017/do05-sre-site-reliability-engineering-in-azure-on-azure (一部改変)

MTBFを捨てるのではなく品質をプロセスで作り込む

https://www.ryuzee.com/contents/blog/13147

https://cloud.google.com/devops/state-of-devops/4つのキーメトリクス: 2019年の調査（3万件以上の回答をクラスター分析）
エリート

ハイパフォーマー

ミディアム
パフォーマー

リードタイム

1日未満

1日から1週間

1週間から1ヵ月

1ヵ月から6ヵ月

デプロイ頻度オンデマンド(1日複数回)

1日1回から週1回

週1回から月1回

1ヵ月から6ヵ月

MTTR

1時間未満

1日未満

1日未満

1週間から1ヵ月

変更失敗率

0 - 15%0 - 15%0 - 15%46 - 60%

ローパフォーマー• 開発速度と品質はトレードオフの関係ではない• 組織間の差はかなり大きく、さらに開いている（2016 - 2019）• 圧倒的な差は継続的デリバリやDevOpsへの組織的な投資の差
https://www.slideshare.net/DevOpsWebinars/2019-accelerate-state-of-devops-survey-results-are-in4つのキーメトリクス: エリートクラスタとローパフォーマークラスタの差
エリート

エリートとローパフォーマーの差

ローパフォーマー

リードタイム

1日未満

106倍

1ヵ月から6ヵ月

デプロイ頻度オンデマンド(1日複数回)

208倍

1ヵ月から6ヵ月

MTTR

1時間未満

1/2604

1週間から1ヵ月

変更失敗率

0 - 15%

1/7

46 - 60%• 開発速度と品質はトレードオフの関係ではない• 組織間の差はかなり大きく、さらに開いている（2016 - 2019）• 圧倒的な差は継続的デリバリやDevOpsへの組織的な投資の差
https://www.slideshare.net/DevOpsWebinars/2019-accelerate-state-of-devops-survey-results-are-in保守性を犠牲にすればスピードは得られる？
•短期的には得られる•中期的には逆効果になる•長期的には致命傷になる「短期的/中期的」の境目は？
ここでいう「品質」とは？

テスト自動化の損益分岐点は「4回」

およそ4回で手動テストと自動化されたテストのコストが逆転する
https://www.amazon.co.jp/dp/0321754069

A Philosophy of Software Design

good design eventually pays for itself,and sooner than you might think.

https://www.amazon.co.jp/dp/1732102201

木こりのジレンマ

illustrated by @mty_mno
http://testerchan.hatenadiary.com/entry/2018/03/05/075544

内部品質への投資の損益分岐点は1ヶ月以内に現れる

内部品質への投資の損益分岐点は3年後とかではなく1ヶ月以内に現れる
https://martinfowler.com/articles/is-quality-worth-cost.html

保守性を犠牲にすればスピードは得られる？
•短期的には得られる•1ヶ月後には逆効果になる•長期的には致命傷になる
1ヶ月以内であれば、内部品質への投資の受益者は自分たち自身であり、つまり道徳や矜恃の話ではなく損得の話である

キャディ株式会社様の事例
リファクタリング用のリソースを純増した訳ではない。sprint 内の 20-30% を投資すると決めた。最初はベロシティが落ちたが、1-2ヶ月経った後は明確にデリバリー速度が高まった。（例を挙げると、1ヶ月かかると言われていた規模の開発が5日で終わるようになった）
たまたま参加したイベントで t̲wada さんの「質とスピード」に関する講演を聞き、もともと悩んでいたポイントだったので吹っ切ることができた。
https://caddi.tech/archives/1614

荒ぶる四天王はスコープを削れ与えられた時間に対してやるべきことが多すぎる場合、どうすべきか?

👉 a) スコープを削るb) もっと人を増やすc) リリース日を延期するd) 品質を犠牲にする『アジャイルサムライ』 p.86

ここから延長戦

ではスピードおよび質は何とトレードオフなのかではスピードと質は何とトレードオフなのか: 次世代への教育、新技術の調査、多様性の確保

https://b.hatena.ne.jp/entry/s/speakerdeck.com/twada/quality-and-speed

では、品質と速度についてのトレードオフが意識される
とき、実際には何と何が秤にかけられているのか。
それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。言い換えれば、プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。
https://osa.hatenablog.com/entry/2017/05/31/233319

本物の力をつけるには時間がかかるソフトウェアの開発に最初から最後まで関わるという経験はとても貴重だったんじゃないだろうか。なぜなら、プロジェクト開始時のダメなデザインのしっぺ返しを、後で自分でモロに受けるからだ。
当初ぼくは、ほとんど考えずコードを「アンダーエンジニアリング」していた。後々これを過度に修正してしまい、全てを「オーバーエンジニアリング」し作り込みすぎてしまった。２年半という時間はこういった失敗を経験するには十分な時間で、辞めるころにはシステムのデザインの塩梅が、かなりわかるようになっていたと思う。

Evan Priestley
https://knoh.jp/answers/d65c7a82/

一番重要で一番やっかいなスキルはシステムを設計するための判断力だ。
限りなくシンプルなデザインというのはなかなか教えられるものではな
く、大方経験を重ねて覚えるものだ。
この「判断力」は、プログラマーにとって非常に重要なのだが、そう簡単に教えられるものでもない。ぼくが知る限り、判断力をつける
一番の方法は、自分で設計したシステムを長い間メンテすることだと思う

Evan Priestley
https://knoh.jp/answers/d65c7a82/

品質とコストはトレードオフかPhilip Crosby "Quality is Free": 品質アップはコストアップかダウンかコストアップ説

コストダウン説

"Quality is Free"

品質 "実質無料"

https://speakerdeck.com/shimashima35/start-quality-real-free-campaign

どのくらい設計に投資するかアーキテクティング: いつ、どれだけ？
100KSLOC = 10万行のプロジェクトの先行設計のスイートスポット

https://www.oreilly.co.jp/books/9784873118956/

ソフトウェアの規模がスイートスポットに与える影響

https://www.oreilly.co.jp/books/9784873118956/

ソフトウェアの規模がスイートスポットに与える影響• ソフトウェアシステムが大きくなればなるほど、前払いのアーキテクチャ設計から受ける恩恵は大きくなる• 小規模（1万行）のソフトウェアシステムでは、前払いのアーキテクチャ策定からはほとんど恩恵を受けられない• アーキテクチャ設計に少ししか投資しないと、強烈なしっぺ返しが来ることが予想される• アーキテクチャに投資すればするほど、必要な手直しは少なくなる

https://www.oreilly.co.jp/books/9784873118956/

要求の変動や欠陥コストがスイートスポットに与える影響

高い信頼性を求められ欠陥コストが高い場合は、アーキテクティングの必要性が高まる

要求の変動が大きい場合
は、急速な変化に対応するための分析や文書化の手戻りのため、先行設計の効果は下がる

https://www.oreilly.co.jp/books/9784873115115/

ご清聴ありがとうございました• 「品質とスピードはトレードオフの関係にある」は大きな誤解• 「品質」の名のもとに犠牲にされるのは内部品質の特に保守性（テスト容易性、理解容易性、変更容易性）• 実際には保守性を高めればスピードは上がるし、保守性を落とせばスピードは下がる• スピードを落としても保守性は上がらないし、スピードを落とすと仮説検証プロセスが回らない• 内部品質への投資の損益分岐点は意外と早く(1ヶ月以内)やってくる• 1ヶ月以内ということは受益者は自分たち自身であり、つまり道徳や矜恃の話ではなく損得の話である• スピードおよび質とトレードオフなのは教育、成長、多様性への投資