2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。
品質とスピードはトレード・オフの関係にある。どちらを優先するか?要バランスだ。
そう思っていた時期が私にもありました。
けど、そんなことはなかった!
■追記
個人的な捉え方としては、
プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。
保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。
スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。
@t_wadaさんのスライド
犠牲にされる品質
- 荒ぶる四天王(QCDS)があらわれた!
- 「品質を犠牲にする」が選ばれやすい
- プロジェクトマネジメントの現場で行われてきたこと
- 品質を犠牲にすればスピードは得られる?
- 短期的には得られる
- 中期的には逆効果になる
- 長期的には致命傷になる
- 品質を犠牲にしてスピードをあげると言うが
- 「品質とは何か?」
「品質」とは何か?という問い
内部品質(のうち保守性)を犠牲にしてスピードを得る
- では、どのような内部品質を犠牲に捧げたのか?
- 一番犠牲にされがちな内部品質は「保守性」
この左上の三角が確かに削られがち。 #eof2019 #hall pic.twitter.com/rnIMeHvuI0
— Kenji Nakamura (@o2_knj) 2019年10月31日
- スピードを得るために犠牲に捧げられた「保守性」
- テスト容易性
- 理解容易性
- 変更容易性
速度を得るために犠牲に捧げた3人の子#eof2019 #hall pic.twitter.com/XjI7mvHQm5
— Kenji Nakamura (@o2_knj) 2019年10月31日
- 保守性(テスト容易性、理解容易性、変更容易性)を犠牲に捧げて、仮初の速さを得る
- コピーアンドペーストによる増改築→荒みきったコード→「動くコードに触れるな」
- 動いてるかどうかわからないけど、爆弾処理のようなリリース
- 「たぶん動くからリリースしようぜ」
ビジネスをしていると常にスピード優先なので、品質を優先することは、永遠にこない
- マスター先生「時間を優先するためなら品質を優先できると考えているものもいるようだが、それは間違いだ」
Web系企業でよく言う「今は大事な時期だからスピード優先で、コードの質は下げても構わん」みたいなの、会社が存続している限りスピード優先なので、真に受けるとクソコードしか存在しない会社になるから常にちゃんとしたものを書いた方がいい。
— nekoya (@nekoya) 2014年8月6日
「後でキレイにリファクタしますのでスピード重視で作ります」は実装した後に「リファクタしたいとは思っているが現状動いているから優先度低いね」になるから、コイツラは詐欺師。
— がお@1日目(土) 南カ-39b (@gaogao_9) 2019年10月17日
毎度スピード優先だからとか言ってクソコード投げてくるひとに十分な時間を与えたら果たしていいコードが返ってくるのだろうかというと
— このツイートは表示できません (@drillbits) 2018年7月3日
経験上、十分時間を与えたから良いコードを書いてくる人は、スピード優先でも良いコードを書いてくる。クソコードを書いてくる人は結局クソコードしか書いてこない。 https://t.co/wZNmqYLf7E
— V (@voluntas) 2018年7月4日
- テスト容易性が下がる→テストされない→テスト容易性が下がる→ループ
- 影響範囲調査と修正がひとつひとつの作業に乗ってきてしまう。
- 「全体工数の4割くらい失敗するテスト直してる気がする」
品質とスピードは、トレードオフではない
- 「要はバランス」おじさん
何かにつけてトレードオフ構造を見出して「要はバランス」という結論で満足してしまう人を揶揄して「要はバランスおじさん」と呼ぶことがあります。
— チーフ (@katzchang) 2019年9月9日
品質"実質無料"
- 品質アップは、コストアップかコストダウンか?
- Quality is free.
品質 "実質無料"
— Kenji Nakamura (@o2_knj) 2019年10月31日
出戻りを減らすことで、コストを減らす。
なので、かかる時間がとりもどせる。#eof2019 #hall pic.twitter.com/zD9BuE6EdM
- クオリティ&ダーティの神話
- むしろ品質を高めることで、デリバリーが高速になることが多い by エクストリームプログラミング
- 最高の開発者はいちばんのきれい好き
- コードの品質を高く保っていた「からこそ」速い
コードの品質を高く保つことで、品質を高く保つ。#eof2019 #hall pic.twitter.com/OeFDsRDV01
— Kenji Nakamura (@o2_knj) 2019年10月31日
QCDのトレードオフなんて本当は無かったんだ
- 内部品質を高く保って、外部品質で勝負したかった。
- 品質を下げると、デリバリーが遅くなる→スピードが遅くなると仮説検証の回数が少なくなる→検証できないので外部品質が低くなる
内部品質がスピードを
— kamo shinichiro@スクラムマスター (@tyantya41717651) 2019年10月31日
スピードが学びのループを
学びのループが外部品質を
外部品質が競争力を
競争力が売り上げを
売り上げが内部品質を生む
#eof2019 pic.twitter.com/VthxPliFJC
- 4つのキーメトリクス(by Accelerate)
- リードタイム
- デプロイ頻度
- MTTR
- 変更失敗率
「質 v.s. スピード」という考え方は根本的にまちがっている
- Done is better than perfect - をどう訳すか
- 「多分動くと思うからリリースしようぜ」?
- 「完璧を目指すよりまず終わらせろ」?
- 片方を犠牲にした場合、知らぬうちに片方も犠牲にしている
"「質v.s.スピード」という概念は根本的に間違っている" "質v.s.スピードという二律背反の関係は、局所的なものでしかない。大域的には、片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしている" https://t.co/jfZK5juCU6
— Takuto Wada (@t_wada) 2017年2月14日
テストの自動化の損益分岐点
— Kenji Nakamura (@o2_knj) 2019年10月31日
4回以上は損 #eof2019 #hall pic.twitter.com/qMtDDZ8KLv
- コードがスパゲッティになったら直すのは、ほぼ不可能である
- ファウラーさんが数字を出した。
- 「内部の質への投資は1ヶ月以内に現れる」
- 中期=1ヶ月
まとめ
「質とスピードはトレードオフの関係にある」は大きな誤解です
t_wadaさんまとめ。 #eof2019 #hall pic.twitter.com/Ux6HxwXg4Y
— Kenji Nakamura (@o2_knj) 2019年10月31日