【DevSumi2020】質とスピード
概要
プロジェクトマネジメントにおいて、QCD（Quality, Cost, Delivery）という概念があります。 何かを重視すると、別の項目が犠牲になるという考え方ですが、ソフトウェア開発の文脈において、質（Quality）とスピード（Delivery）には本概念は当てはまりません。 質と開発スピードがトレードオフの関係であるというのは典型的な誤解です。 本講演では、どのように質とスピードを考えればよいかについて述べます。
プログラム内容
仮説
- 品質を犠牲ににして開発スピードをあげると、どのような結果を招くのか？
- 短期的には得られる、スピード
- 中期的には逆効果
- 長期的には致命傷になる
と、仮定される。
そもそも品質とは？
様々な切り口はあるが、本セッションでは
内部品質の保守性（テスト容易性、理解容易性、変更容易性の3つ）と定義する
※内部品質に着目するのは、製品側の品質特性を考えるため自然。
この保守性が失われることで、実際の現場では、
- 変更容易性が失われると、動くコードに触るなとなる
- コピーを始めると、可読性が落ちる
- 致命的なバグがあると似た箇所を修正するが、コピーした箇所の漏れがある可能性もでる
現場で保守性を犠牲にした結果起こること
保守性を後回しにするような組織では往々にして市場リリースへの納期のプレッシャーに常にさらされていて、コードがクリーンな状態になることはないされることはない
では、保守性とスピードはトレードオフか？
保守性をあげるために時間を設けても、技術力のない人にとってその人の技術力以上のコードは書けない ※ただ、教育の時間は取れるため改善の流れはできる
一方で、技術力のある人は急いで作っても一定以上の品質のコードを書いてくる コードを書く際に意図的に品質を落としたとしても速度をあがらない
むしろ、最速のプログラマはコードを扱いやすいことに最新の注意を払っていたという事例が観測される。 このことから、実は保守性とスピードは逆相関ではなく相関があるのでは？
保守性とスピードの相関である要因を言及
保守性 → スピードの影響はどうか？
- 可読性があがることで予防コストを低減できる
- 不良対応コスト・本番障害になるとより対応のコストは跳ねあがる（200倍）
- スピードを維持するということは、学びのFBが早まるということ
スピード → 品質への影響はどうか？
- スピードを上げるとバグによる手戻りが発生する。
- 手戻り中は学びを生まない期間である
- 開発のリードタイムへの影響もある。この間は仮説検証プロセスが回らない（遅れる）
つまり、保守性とスピードの相関の相互作用は
- 内部品質がスピードを海
- スピードが学びのループを生み
- 学びのループが外部品質を生み
- 外部品質が競争力を生み
- 競争力が売上を生み
- 売上が内部品質をはぐくむ
構造になっている。
結論
内部品質を削るのではなく、スコープを削る or リリース日の延期が正解となる。
所感
開発者で内部品質と外部品質を意識して開発されているのは凄い。
本題から逸れるが、アジャイル開発の製品の仮説検証の速度が重要視されるケースにおいては、社内での動くモノのレビューもしたいため、多少のコードの汚い状態でもいいので機能の妥当性確認として動くものをレビューするというフェーズもあっていいのかなと思った。
その点は、TDDで動くものからリファクタリングするという流れになると思うが、開発者視点で理解できるよう手を動かしていきたい。
