品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020

ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。

はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。

この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。

質とスピード

和田卓人と申します。ネット上ではt-wada（もしくはt_wada）と呼ばれています。最近ではライオンとだいたいセットで出てくることが多いようです。

今日は「質とスピード」というテーマでお話をさせていただきます。

さて、「荒ぶる四天王」はみなさんご存じですかね。『アジャイルサムライ』に出てくる4つの強敵のことです。

荒ぶる四天王が現れた！

与えられた時間に対してやるべきことが多すぎる場合、どうするべきか？ 時間、予算、品質、スコープの4つの荒ぶる四天王のうち、どれを犠牲にするか。

考えられる選択肢は、a）スコープを削る、b）もっと人を増やす、c）リリース日を延期する。d）品質を犠牲にする、がありますが、だいたいにおいて選ばれがちなのが、d）品質を犠牲にする、です。

品質を犠牲にすることで残りの、時間、予算、スコープを満たそうとする。よくあるプロジェクトマネジメントの現場の判断ですよね。

じゃあ 品質を犠牲にすることでスピードが得られるのか。

これは個人の意見ですが、品質を犠牲にすることで短期的なスピードは得られると思います。しかし中期的にはそれが逆効果になって、長期的には品質を犠牲にすることがプロジェクトにとって致命傷になる。

長期的に致命傷になる点は直観に反しないというか、議論の余地はないと思いますけれど、中期的とはどのくらいのことでしょうか？ これが今日の大きなテーマの1つになります。

ここでいう「品質」と何か？

まず、「品質を犠牲にする」と言うときの「品質」とは何か？ という話から掘り下げていこうと思います。

偉大なるGerald Weinberg氏は『ワインバーグのシステム思考法』で、「品質とは誰かにとっての価値である」と言っています。

とても深い言葉ではあるんですけれど、これだけだとちょっと分かりにくいので、もう少し具体的に品質とは何かについてアプローチしていこうと思います。

まず品質というものをリストアップしてみます。保守性や信頼性など、いろいろなものがあります。

これをもう少し立体的に見てみましょう。

日本で品質を語るときによく出てくるのが、「狩野モデル」です。狩野モデルは「顧客の満足感」と「物理的な充足度」という2軸をとって、そこに対して3つの品質のジャンルというようなものを名付けます。

この3つの品質のジャンルは「当たり前品質」「一元的品質」「魅力品質」です。

ECサイトを例に考えてみましょう。そもそもECサイトで、ものが買える、検索ができる、といったものが「当たり前」品質。そもそもそれが満たされていないと話にならない品質です。

「一元的品質」は、あればあっただけ魅力が増していく。例えば商品数であるとかジャンル分けであるとか、そういったものです。

そして「魅力品質」は、例えばSNSとの連携みたいな、なくてもかまわないけれどあれば魅力的に見える。

これが狩野モデルという整理の仕方です。

外部品質と内部品質

品質のリストアップや狩野モデルを見てきましたが、もうちょっと違う視点から品質というものを見てみると、顧客から見える品質と、見えない品質というものがありそうだ、ということが分かってきます。

これを「利用時の品質」と「製品品質」と言ったり、「機能要件」と「非機能要件」と言ったりしますよね。

今日の講演では「外部品質」と「内部品質」という言葉を使います。

お客様から見える品質が「外部品質」、見えない品質が「内部品質」。

荒ぶる四天王と戦うときに、品質を犠牲にするという話をしました。しかし、品質にはとても広い意味があります。

だけど恐らく私たちはもう少し狭いものをイメージして「品質を犠牲にしよう」と言ってるわけです。

で、その品質には「外部品質」と「内部品質」があって、私たちが犠牲にしようとしているのは、おおむね「内部品質」だと思います。

『レガシーコードからの脱却』という本から一文をとってくると「内部品質は結果ではなく原因である」とあります。

内部品質をだんだん掘り下げていきましょう。

内部品質、外部品質には例えばこんなものがあります。外部品質にはCorrectness（正しさ）とかUsability（ユーザビリティ）とかEfficiency（効率性）とかReliability（信頼性）とか。

内部品質にはMaintainability（メンテナンス性）とかFlexibility（フレキシビリティ）とかPortability（ポータビリティ）、Testability（テスタビリティ）とかが並んでいます。

なので今日の講演、タイトルは「質とスピード」とやや広めになっていますが、これを内部品質とスピードと、狭くしてみます。

どのような内部品質を犠牲にするのか

では「内部品質を犠牲にして開発のスピードを優先しよう」となったときに、実はどのような内部品質を犠牲に捧げるのか。

今度は内部品質を立体的に見てみようと、いくつかモデルを持ってきたのですが、例えば1978年の三角形のモデル。

三角形の各辺が「プロダクトの移行」（Product Transition）に関するもの、「プロダクトの運用」（Product Operations）に関するもの、「プロダクトの改定」（Product Revision）に関するもの、の3つを示しています。

そしてPortabilityやReusabilityとかがここ（右辺：プロダクトの移行）、CorrectnessやReliabilityなどがここ（底辺：プロダクトの運用）、MaintainabilityやFlexibilityなどがここ（左辺：プロダクトの改定）になるわけです。

内部品質を犠牲にするといったときに、これらのどれを犠牲にするかというと、この左側の辺、Maintanability（保守性）などを主に犠牲にするのだろうと考えます。

もう1つ見ていきましょう。これは1976年にBarry Boehmさんが中心になって作った品質の樹形図です。

品質は「Portability」「Usability」「Maintainability」の3つに分けられています。

そして「Maintainability」（保守性）は何から構成されているかというと、「Testability」「Understandability」「Modifiability」つまりテスト容易性、理解容易性、変更容易性となっています。

この3つを犠牲に捧げることで、短期的なスピードを召喚していると、そんな感じになるんですね。

というわけで、今日のテーマをもっと狭くするとこうなります。「保守性とスピード」

保守性を犠牲にしたらスピードは上がるか？

では、保守性とスピードというのは、はたしてトレードオフの関係にあるのでしょうか。保守性を犠牲にすることで開発スピードを得られるのか、得られないのか、という問いに進んでいきます。

保守性を犠牲に捧げるとどうなるでしょうか。『Clean Architecture』という本から引用します。

「市場からのプレッシャーは止まらない」そして「崩壊が始まる。生産性がゼロに近づいていく」とあります。

保守性を犠牲に捧げたコードは、理解容易性やテスト容易性や変更容易性に問題を抱えているわけですから、手を入れにくい。

保守性が低いと、ひとつひとつの変更に余計な時間がかかるようになるので、単位あたりの生産性がどんどん落ちていく。開発スピードが落ちていきます。

さて、保守性を犠牲にすればスピードが得られるのかについて、いままで見てきたのはこんな感じです。

短期的にはたぶん得られるけれど、中期的には逆効果、つまり生産性が落ちる。それを長期的に放置していたら死んじゃいますよね。

開発スピードを落とせば保守性は上がるか？

保守性と開発スピードのあいだにトレードオフの関係があるなら、逆に、開発スピードを落とせば保守性は上がるでしょうか？

『エンジニアリング組織論への招待』から引用します。

「与えられた開発期間から、柔軟に汚さと速さを選択するというような芸当はほとんど不可能だといえます」とあります。

つまり保守性と開発スピードというのはトレードオフではないんです。

実際には、コードが汚くて遅い人もいれば、きれいで速い人もいる。つまり人の問題であって、トレードオフの関係ではないんですね。

≫後編に続く ～ 後編では質とスピードの本当の関係、そして内部品質や保守性への投資はいつ実るのか？ について説明します。