先日、私が所属する品質コンサルティング組織「QE&A」の活動の一環として、初めて全社的なイベント「QualityConf」を開催しました。
今回は、TDD（テスト駆動開発）のエバンジェリストとして国内外で知られるtwadaさん（和田卓人さん）をゲストにお招きし、Accenture Innovation Hub Tokyoにて「質とスピード ～ソフトウェア開発の典型的な誤解を解く～」というテーマで講演をしていただきました。
普段、テスト自動化やQA活動に携わる私にとって、twadaさんとはずっとお会いしてみたいと常日頃から思っていましたので、社内向けイベントで直接お話しいただく機会を設けられたこと、非常に嬉しく思っています。
今回は、twadaさんの当日の講演の内容をダイジェストでお届けします！
なぜ今、「質とスピード」なのか？
ソフトウェア開発に携わる誰もが直面する問題、それが「質とスピード」のジレンマです。
プロジェクトの現場では、限られた時間やリソースで実現すべきことが多すぎる場合、以下のような4つの選択肢が浮かび上がります。
a) スコープを削る
b) 人を増やす
c) リリース日を延期する
d) 品質を犠牲にする
この中でも実務上、開発者や管理者が特に選択しがちなのは「d) 品質を犠牲にする」です。しかし、この判断は一時的な効果を生むかもしれませんが、ほぼ確実に長期的には致命的な結果を招きます。
品質とはそもそも何なのか
講演では、まず「品質」という言葉を深掘りするところから始まりました。ソフトウェア品質には大きく「外部品質」と「内部品質」の二つがあります。
- 外部品質：ユーザーが実際に体験する品質（速度、信頼性、ユーザビリティなど）
- 内部品質：開発者が直接感じる、コードの保守性、可読性、変更のしやすさ
講演で強調されていたたのは、この「内部品質」です。
- 内部品質とは結果ではなく、原因である
- 内部品質を高めることで、外部品質（ユーザー体験）は自然と高まっていく
開発現場がよく陥る誤解は、「とりあえずリリースを優先して、後からリファクタリングしよう」というものです。しかしTwadaさんは明確に否定します。
「後でクリーンにする」という幻想
講演で引用されていた『Clean Architecture』の著者、Bob Martin氏の言葉が非常に印象的でした。
「『あとでクリーンにすればいい』という状況はまず来ない。コードはそのまま悪化を続け、ついには崩壊に向かう。短期的にも長期的にも、品質を犠牲にしたコードは、品質の高いコードよりも常に遅くなる」
Twadaさんも同じ意見を共有しています。コードが乱雑になればなるほど、新機能の追加やバグの修正が難しくなり、結局開発速度はどんどん落ちてしまいます。
品質の高いコードは「速さ」に寄与する
実際、多くの現場では「質とスピードはトレードオフの関係にある」と考えられています。しかし、講演では、まったく逆のポジションを基軸にしていました。
「コードの品質を高く保っていた『にも関わらず』速いのではない。
「コードの品質を高く保っていた『からこそ』速いのだ。（David Scott Bernstein氏『レガシーコードからの脱却』）
つまり、内部品質が高い→速い という因果関係がソフトウェア開発においては成り立つ、ということです。
内部品質への投資効果は驚くほど早い
内部品質を高めることは速さに寄与する、とここまでで述べられていましたが、それではどのくらいの期間でそのリターンを得られるのか？
「頑張って綺麗に作っても、効果を得られるのは運用とか、だいぶ先でしょ？」
この問いに対し講演で話されていた答えは、「内部品質への投資の損益分岐点は、1ヶ月以内に現れる」とのことでした。つまり、保守性を高めることは、「数年後の誰かのためではなく、1ヶ月後の自分のためにやる」、とのことでした。
確かに、私の経験としても、個人で動くコードを作っても、可読性を含む内部品質をおろそかにしてしまい、数週間後に開いて「誰が書いたんだこんなコード！」となった経験があるので、ロジカルな説明として聞けてよかったな、と思います。
講演で紹介されていた会社の事例では、Sprintのうち20～30%を内部品質（リファクタリングやコード改善）に投資することを決定したところ、最初は開発速度が低下したものの、1～2ヶ月後には明らかに開発スピードが大幅に改善されました。
「当初は1ヶ月かかると想定されていた開発が、わずか5日で完了できるようになった」という劇的な変化もあったそうです。
内部品質の直接の受益者は、開発チーム自身であり、
それをおろそかにすることによる直接の被害者も、開発チーム自身である。
テスト自動化は「まずやってみる」
普段テスト自動化の導入や提案に携わっている立場として、個人的にtwadaさんの講演の中で本当にその通りだなと強く思った1フレーズをご紹介します。
自動テストは最初から厳密な網羅性を求めるのではなく、導入できるところから自動化していくのが良い。少しでも手動だったところが自動に変わることでコスト構造の変化を得られるためである。
後からテストコードを書こうとしても、「今までテストを書いてこなかったコードは、後からテストコードを書きにくい」というジレンマに陥る場合がある。だからこそ個人レベルでも「テストコードの作り方」を押さえておくことが非常に重要となる。
テストが書きやすいソフトウェア構造になっていることは、内部品質の「テスト容易性」にも定義されているように、非常に重要だ！ということを広めていきたいな、と思います。
まとめ
講演を通して、私自身も改めて考えさせられたことばかりでした。品質（特に内部品質）への投資は、決して理想論や倫理的な話ではなく、非常に実利的な意思決定であること。内部品質への投資の効果は、想像以上に早く現実的な成果として現れること。プロジェクトにおいても非常に重要な示唆となる内容だったな、と強く思います。
私たちQE&Aは、品質にこだわり、プロジェクトを支援するプロフェッショナル集団です。現在、採用も行っています。ご興味がある方は、ぜひお気軽にご応募・ご連絡ください。
最後に、素晴らしい講演をしてくださったtwadaさん、本当にありがとうございました！
Views: 0
