| 項目 | 評価 |
|---|---|
| 内容がためになるか | |
| 説明の分かりやすさ |
ベリサーブ アカデミック イニシアティブ 2022 オンデマンド配信にて。
2022/12/6 – 2022/12/16
講師
タワーズ・クエスト株式会社
取締役社長／テスト駆動開発者
和田 卓人 氏（ワダ タクト）
学生時代にソフトウェア工学を学び、オブジェクト指向分析／設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努めている。
『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。
概要
「開発スピードを上げるために品質を落とす」という言葉をよく聞きますが、果たして開発スピードと品質は交換可能なものでしょうか。本講演では「スピードと品質はトレードオフの関係にある」という誤解にアプローチします。
※今回の発表資料とは別だが、定期的に講演されている内容で前回と基本的には同じため、前回の資料を貼っておく。
初めに
与えられた時間に対してやるべきことが多すぎる場合、どうすべきか？
a) スコープを削る
b) もっと人を増やす
c) リリース日を延期する
d) 品質を犠牲にする <===
現場では、「品質を犠牲にする」を選んでしまうことが多い。
これは、「品質を犠牲にすればスピードは得られる」という仮説があると考えられているため。それは本当か？
- 短期的には得られる？
- 中期的には逆効果になりそう
- 長期的には致命傷になる
参考文献
アジャイルサムライ――達人開発者への道 (Jonathan Rasmusson)
ポチップ
和田卓人さんのコメント：アジャイルサムライは、アジャイル開発でまず最初に読むべき本。心構え、実装等すべてについてわかりやすく書かれている。
ここでいう品質とは？
品質は、ilitiesで表される。
Accesibility, Flexibility, Operability, …
外部品質と内部品質がある。外部品質はユーザビリティや信頼性等、内部品質はメンテナンス性や移植性等。
内部品質を作り込んだ結果として、外部品質として定義される特性の実現に近づくことができる。内部品質は結果ではなく原因であり、良いソフトウェアが備えているべきものだ。
参考文献
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス (David Scott Bernstein)
犠牲にされるのは内部品質。内部品質の受益者・被害者は開発チーム自信。自分達が犠牲になることで、調整コストが低い内部品質の方を削るという判断をしがちなのではないか。
犠牲にされる内部品質は保守性。保守性は、
- モジュール性
- 再利用性
- 解析性 ≒ 理解容易性
- 修正性 ≒ 変更容易性
- 試験性 ≒ テスト容易性
で構成される。
保守性を犠牲にするとどうなるか？
「あとでクリーンにすれば良い、先に市場に出さなければ！」
開発者はそうやっていつもごまかす。だが、あとでクリーンにすることはない。市場からのプレッシャーは止まらないからだ。競合他社に追い抜かれないためには、これからも走り続けるしか無い。
その結果、次の機能、次の機能、また次の機能を追加することになり、コードをクリーンにすることまで手が回らない。
そして崩壊が始まる。生産性がゼロに近づいていく。
参考文献
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (Robert C. Martin)
この言葉にうっとなる人は多いかもしれないとのことだったが、確かにその通りだと思った。
保守性を犠牲にすればスピードは得られるか？
- 短期的には得られる？
- 中期的には逆効果になりそう
- 長期的には致命傷になる
ではスピードを落とせば保守性は上がるか？
技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。
逆に、技術力の高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。
残酷だが、これが現実。
与えられた開発期間から柔軟に汚さと速さを選択するというような器用な芸当はほとんど不可能。
参考文献
エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング (広木 大地)
つまり、トレードオフではない。
Clean Architectureで、著者のAncle Bobは「短期的にも長期的にも、崩壊したコードを書く方がクリーンなコードを書くよりも常に遅い」と言い切っている。
レガシーコードからの脱却でも、コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。とあるとのこと。
品質は劣化すればリードタイムの増加に跳ね返る
- プロセス品質：下げると手順ミス等により手戻りが発生し、デリバリーへのリードタイムが長くなる
- 内部品質：下げるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さなどにより手戻りや速度低下を招き、デリバリーへのリードタイムが長くなる。
- 外部品質：下げるとUXバグを生み、本来検証したいことが検証できず学びまでのリードタイムが長くなる。障害発生により、それの対応に追われリソースが枯渇し本来やるべきことの足枷になり、リードタイムが長くなる。
- 利用時の品質：下げると、カスタマーサポートが頻発し、その対応に組織のパワーが持っていかれリードタイムが長くなる。
品質は悪いと基本的に手戻りを生むためスピードに跳ね返る。手戻り時間は学びを生まない時間。品質を下げるという判断は学びの速度低下を許容するということ。
従来の鉄板と誤解されていた品質すててスピードあげようは、品質は劣化すれば手戻りが発生するだけで、結局はリードタイムの増加に跳ね返るのでやめましょう。
本当の関係
- 内部品質がスピードを生み
- スピードが学びのループを生み
- 学びのループが外部品質を生み
- 外部品質が競争力を生み
- 競争力が売上を生み（そう単純でもないが）
- 売上が内部品質を育む
テスト自動化の損益分岐点は「４回」らしい。およそ４回で手動テストと自動化されたテストのコストが逆転する。
内部品質への投資の損益分岐点は３年後とかではなく１ヶ月以内に現れる。つまり、３年後自分がいないかもしれない時のことではない。道徳等ではなく、自分達の損得の話になる。これが重要な点。
キャディ株式会社で、この「質とスピード」の講演を聞いて決断し、スプリント内の20-30%をリファクタリング用に割り当てたところ、最初はベロシティが落ちたが、１−２ヶ月経った後は明確にデリバリー速度が高まったらしい。（例えば、１ヶ月かかると言われていた規模の開発が５日で終わった等）
最初の問い
与えられた時間に対してやるべきことが多すぎる場合、どうすべきか？
a) スコープを削る<===
b) もっと人を増やす
c) リリース日を延期する
d) 品質を犠牲にする
もし選ぶとしたら、「a)スコープを削る」が解となる。
まとめ
-「 品質とスピードはトレードオフの関係にある」は大きな誤解
- 「品質」の名のもとに犠牲にされるのは内部品質の特に保守性（テスト容易性、理解容易性、変更容易性）
- 実際には保守性を高めればスピードは上がるし、保守性を落とせばスピードは下がる
- スピードを落としても保守性は上がらないし、スピードを落とすと仮説検証プロセスが回らない
- 内部品質への投資の損益分岐点は意外と早く（１ヶ月以内）にやってくる
- １ヶ月以内ということは受益者は自分たち自身であり、つまり道徳やプライドの話ではなく損得の話である。
感想
非常にわかりやすく、ためになる内容だった。この話は自分の中だけで完結すべきではなく、上位者やチーム、別部署にも積極的に共有した。結果的にTDDにもつながる話と思った。
実際、残念な古い人はこの誤解をしており、内部品質を上げる活動を無駄な工数を使うなと言ってきたりもする。
内部品質を上げるためには、結局は技術力を上げる必要がある。ドメイン知識、設計力、デザインパターン、TDD、リファクタリング等、様々な能力を身につける必要がある。日々、怠けず研鑽したいと思った。
コメント