2020/11/25

【誤解あるある】システム開発の品質とスピードはトレードオフなのか？

中島 洋一
NewsPicks Brand Design DeskEditor ／ NewsPicksパブリッシング 編集者
 システム開発をマネジメントする際に、4つ要素がある。
時間、予算、品質、スコープ（開発範囲）
 案件によって条件は違えども、どれも大切だが、リソースが逼迫しているとする。
 であれば、そのうちどれを削り、どこを死守するべきか、あなたは答えられるだろうか。
 及川卓也氏、吉羽龍太郎氏とともにNTTコミュニケーションズの技術顧問を務める和田卓人氏は「品質とスピードがトレードオフと考えるのは、典型的な誤解」と言う。
 3人の技術顧問のうち、「もっとも技術寄り」と自認するプログラマーとして名高い和田氏による講演をダイジェストでお届けする。
プロジェクトに訪れる厳しい問い「荒ぶる四天王」
 本日は、ソフトウェア開発の現場で誤解されがちな「質とスピード」の関係について、プログラミングの側面からお話していきたいと思います。
プログラマー、コンサルタント。技術書の翻訳、監訳、監修などにも関わる。タワーズ・クエスト株式会社代表取締役。2019年、及川卓也氏、吉羽龍太郎氏とともにNTTコミュニケーションズの技術顧問に就任。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『Engineers in VOYAGE』（ラムダノート、2020）編者。
 最初にご紹介したいのが、「荒ぶる四天王」という概念です。これは、時間・予算・品質・スコープを意味します。
 プロジェクトには厳しい問いがやってくる瞬間があります。そのとき、問題になるのがこの「荒ぶる四天王」です。
出典：『アジャイルサムライ――達人開発者への道』（オーム社）
 与えられた時間に対してやるべきことが多すぎる場合、我々は、どうするべきなのでしょうか。主に、次の4つの選択肢が挙げられます。
①機能数を減らす
②もっと人員を増やす
③リリース日を延期する
④品質を犠牲にする
 多くのプロジェクトにおいて選択されるのが、選択肢④です。品質を犠牲にしてスケジュールに間に合わせようという判断が行われがちです。
 品質を犠牲にすれば、短期的にはスピードは得られると私は考えています。しかし、中期的には逆効果になるでしょう。さらに長期的に品質を犠牲にし続けると、プロジェクトとして、またソフトウェアとして致命傷が生まれてしまいます。
 では、犠牲にしてしまいがちな「品質」とは具体的に何を指しているのか？　
 また、逆効果になる「中期的」とはどのくらいのスパンなのか？　
 この2つが本日のテーマになります。
犠牲にする品質とは「保守性」
 まず、「品質を犠牲にして先を急ぐ」という選択をした場合、我々は実際に何を犠牲にしているのでしょう？
 ソフトウェアの世界では品質のことを「ilities」と表現されています。Accessibility（利便性）、Adaptability（順応性）、Administrability（管理可能性）、Analyzability（解析性）など、その多くが～ilityで終わる内容だからです。
 たくさんの「ilities」は大きく「お客様から見える品質（外部品質）」と「お客様から見えない品質（内部品質）」という２つのカテゴリーに分類することができます。
 では、我々は「品質を犠牲にして先を急ごう」と言う際、外部品質と内部品質のどちらを優先し、どちらを犠牲にしているのでしょうか？
 答えは内部品質です。納品を急ぐために、お客様から見えない内部品質を犠牲にし、お客様から見える外部品質を優先しようという判断がよく行われています。
 内部品質の中でも、特に削られがちなのがMaintainability（保守性）です。
 Maintainability（保守性）は、Testability（テスト容易性）、Understandability（理解容易性）、Modifiability（変更容易性）から構成されています。テスト容易性とは、テストのやりやすさ。理解性容易性は、ソフトウェアが理解しやすいかどうか。変更容易性は、ソフトウェアが変更しやすいかどうか。この3つの要素によって保守性は構成されています。
 我々は時間に追い詰められたとき、保守性を犠牲にして、スピードを得ようという判断をよくしてしまいがちです。今回の講演テーマの「質とスピード」は「保守性とスピード」と言い換えることができます。
質とスピードは本当にトレードオフなのか？
 では、保守性を犠牲にすると、何が起こるのでしょうか？　保守性を犠牲にして先に急ぎ続けると、保守性の低さがだんだんスピードを蝕んでいきます。
 例えば、バグが出てきてそれに対応しようとしても、様々なものに足をとられて余計な時間がかかるようになってきてしまう。最初に開発したときは4週間で作業ができたのに、保守性を犠牲にし続けるとそもそも新機能の開発ができないという構造になり、4週間でできたものが8週間、1週間でできたものが5週間かかってしまう事態になります。それが、保守性を犠牲にし続けることのデメリットです。
出典：Is High Quality Software Worth the Cost?｜martinfowler.com
 では、スピードを落とせば、保守性は上がるのでしょうか？　実は両者はあまり関係ありません。
 技術力のある人は、ある程度急いで作ったとしても一定以上の品質のコードを書きますし、意図的に品質を落としたとしても書き上げるスピードはあまり変わりません。逆に、技術力が高くない人が時間をかけてコードを作ったとしても、その人の技術力以上の品質のコードは書くことはできません。残酷ですがこれが真実です。
 スピードを落としても質が上がらないのであれば、保守性とスピードはトレードオフではありません。保守性とスピードがトレードオフと考えるのは、典型的な誤解なのです。
 書籍『レガシーコードからの脱却』の著者、デイビッド（David Scott Bernstein）さんは次のように言っています。
 速いプログラマーは雑なプログラマーだと思っていたが、実際は正反対だった。私が出会った中で最速のプログラマーは、扱いやすいようにコードを保つことに特に注意を払っていた。

コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。
 大事なのは「コードの品質を高く保っていたからこそ速い」という点です。コードの品質を犠牲にしたから速く進めるのではなく、コードの品質を高く保っていたからこそ、スピードを出すことができる。
 つまり、保守性とスピードの関係は、我々が考えていたものとは正反対だったのです。彼は、このことを理解したあと、ソフトウェア開発に対する見方が変わったと言っています。
 内部品質を犠牲にするからスピードが上がるのではなく、内部品質を高めることでスピードが上がるのです。「質とスピード」の本当の関係を示すとこうなります。
 質が良くなればスピードも速くなる、スピードが速くなれば質も良くなる。そのことが、このような好循環を生むのでしょう。
品質への投資が報われ始める損益分岐点は？
 では、もう一つの問いの方にまいりましょう。質を犠牲にしてスピードを得ようとしたとき、逆効果が現れはじめる「中期的」はいつのことなのでしょうか？　言い換えると、内部品質や保守性への投資が、短期的なスピードを上回る形で報われ始める損益分岐点はどこなのでしょう？
 内部品質や保守性への投資という観点において有名なレポートが「テストの自動化」についてのものです。手と目でテストした方が圧倒的に簡単で速いのに、なぜテストを自動化しなければいけないのか、という議論はよく起こります。
 結論を言うと、テスト自動化が報われる損益分岐点は、概ね4回です。
出典：『Experiences of Test Automation』Dorothy Graham, Mark Fewster
 つまり、手と目を使って4回テストをすれば、もう損になっているのです。逆に、自動化されたテストが4回以上実行されると、手動のテストより投資対効果が高く、その後、逆転されることはありません。
 では、ソフトウェアの設計に関してはどうでしょうか。理解容易性や変更容易性といったさまざまなソフトウェアの内部品質に投資したものの効果はいつ得られ、その投資の損益分岐点はどこにあるのでしょう？
 Martin Fowlerさんという著名なコンサルタントが発表した内部品質への投資の損益分岐点についての定量化されたレポートでは、損益分岐点は1ヶ月以内と言及しています。
出典：Is High Quality Software Worth the Cost?｜martinfowler.com
 1ヶ月以内というのは、かなりインパクトのある数字です。製品をローンチする前に損益分岐点はやってきて、投資効果は得られるということです。
 つまり、内部品質を犠牲にしても、1ヶ月後にはもう逆効果になり始めるということです。逆に言えば、1ヶ月後に効果が現れるということは、プログラマーたち自身の損得の話ということでもあります。内部品質に投資した方が自分にとって得であり、楽であるということなのです。
 では、冒頭の問いに戻りましょう。時間、予算、品質、スコープという4つの課題に対し、限られた時間内でやるべきことが多すぎる場合はどうすればいいのでしょうか？
 4つの選択肢のうち、「品質を犠牲にする」と良い結果につながらないことがわかってきたと思います。有効な答えは基本的に2つしかありません。スコープを削るか、リリース日を延期するかのどちらかです。つまり、機能を重視してリリースを延期するか、機能を削ってリリースを優先するか。
 難しい２択ですが、私は機能を減らしてリリース日を優先することをおすすめします。なぜなら、リリース日を固定した方がチームのパフォーマンスや生産性が測りやすいからです。そのためにやることを減らし、作業時間を一定にして、パフォーマンスを自分たちで測りながら改善していく方がおすすめです。
出典：『アジャイルサムライ――達人開発者への道』（オーム社）
 つまり、4つの課題のうち、スコープを削るという選択が答えになります。
大規模なDX戦略を学べる講演アーカイブ
 本講演を含む、10月14日～16日に開催された「NTT Communications Digital Forum 2020」では、3日間で延べ1万人の参加者が、アバターの姿でバーチャル空間に集った。

 人と会う・集まるのはオンライン上──わずか数カ月で、常識が変わった2020年。NTTコミュニケーションズが例年開催しているプライベートイベントも、新型コロナウイルスの影響で、初のバーチャル空間でのオンラインイベントとなった。

 NTTのコミュニケーションズの技術顧問を務める、及川卓也氏、吉羽龍太郎氏の講演アーカイブも視聴できる「NTT Communications Digital Forum 2020」の全コンテンツをアーカイブした「Digital Showcase」が公開中（2021年3月末まで）です。
特別講演「プロダクトマネジメントの重要性」
及川卓也氏（Tably株式会社 代表取締役/Technology Enabler/ NTTコミュニケーションズ株式会社 技術顧問）
 日本におけるプロダクトマネジメントの第一人者であり、NTT Comの技術顧問を務める及川氏が、プロダクトマネジメントという考え方や役割の重要性について語っていきます。
特別講演「NTT Comにおけるアジャイル開発チームのマネージャーの振る舞いとは」
吉羽龍太郎氏（株式会社アトラクタFounder/CTO/ NTTコミュニケーションズ株式会社 技術顧問）✕大津谷亮祐氏（NTTコミュニケーションズ株式会社　イノベーションセンター 担当部長）
 アジャイル開発の第一人者である吉羽氏と、NTT Com社内でアジャイル開発チームのマネージャーを務める大津谷氏が、アジャイル開発におけるマネージャーの役割や従来のマネージャーとの振る舞い方の違いについて議論します。
構成：大山くまお
編集：中島洋一