派遣で働くエンジニアのスキルアップを応援するサイト

PRODUCED BY RECRUIT

ソフトウェア品質を高めるために知りたい開発者テストの最前線【第2回】シフトレフトの本質とは

テスト界の第一人者、高橋寿一さんに実践的、かつ効率的な開発者テストに関してご解説いただくこのコラム。前回の「なぜテストは必要なの?」はいかがでしたか。「バグは常に見つける気持ちで、でも全部見つけるのは無理だから工夫しなきゃ!」と締めくくられていましたよね。さて今回の内容は、そんなバグをどこで見つけ、どこで修正するといいのか。キーワードは、ブルシット・ジョブとシフトレフト。知っておいて損はないお話です。

この記事でわかること
・品質の向上活動を設計コーディングェーズにもっていくことのメリット
・「テスト担当者がバグを見つけること」と「開発者が単体テストを書くこと」の差

【筆者】高橋寿一(たかはし じゅいち)さん
情報工学博士。1964 年東京生まれ。フロリダ工科大学大学院にてCem Kaner 博士(探索的テスト手法考案者)、James Whittaker 博士(『How Google Tests Software』著者)にソフトウェア品質の指導を受けたあと、広島市立大学にてソフトウェア品質研究により博士号取得。Microsoft シアトル本社・SAP ジャパンでソフトウェアテスト業務に従事、ソニー(株)ソフトウェア品質担当部長を経て、株式会社AGEST 執行役員。

バグをガムテープで留めるとは、これいかに?

今回は少し短めに。

『ブルシット・ジョブ――クソどうでもいい仕事の理論』(デヴィッド・グレーバー / 酒井隆史・芳賀達彦・森田和樹 訳)では、以下のものが(言葉は乱暴になってしまいますが)クソどうでもいい仕事と定義されています。

・取り巻き/flunkies
・脅し屋/goons
・尻ぬぐい(ガムテープでふさぐ人)/duct tapers
・書類穴埋め人/box tickers
・タスクマスター/taskmasters

詳しくは『ブルシット・ジョブ』をお読みいただくとして。タスクマスターは他人に仕事を割り当てるためだけに存在し、それこそブルシット・ジョブを作り出す人で、取り巻きとはドアマンのような存在なのですが、いや、ドアをわざわざ開けてくれなくていいよと言いたくなるような仕事ぶりだとか。皆さんの中にも「あー、心当たりあるなー」というかたも多いと思います。

この中で「ガムテープでふさぐ人」が、ソフトウェア開発におけるブルシット・ジョブ。シンプルに言うと、他人が書いたバグのあるコードの、バグを見つけさせられている人!この説明はもう少し深慮が必要かもしれません。要は、バグを生む人は、テスト担当者にそれを見つけさせる。けれども、その時点で書かれた修正コードは、いわゆる故障箇所をガムデープで留めたような中途半端なものなので、時間がたつとその修正箇所から派生バグが発生する、といった感じでしょうか。そう、とても困った人たちです。

シフトレフト一択である、とてもシンプルな理由

ウォーターフォール時代にはバグが混入されると、以下のような恐ろしく長いステップで一つひとつのバグが修正されていました。

長いステップ。そもそも、開発者がちゃんとしたコードを書けば、この長いステップはゼロになるのですけど。そう、開発者がちゃんとしたコードを書く!終わり!みたいなイメージですね。

そこで登場するのがシフトレフトという考え方。テストを最後にまとめて、ではなく、それぞれの工程の直後に実施、修正していくと。もしも、開発者のミスによってバグが混入してしまったとしても、「シフトレフト」を意識して単体テストを書いていれば、

2つのステップで収まる。これがシフトレフトの本質です。

▲Capers Jonesの言う正しい状態
(書籍『ソフトウェア品質を高める開発者テスト』より)

上記図のように、開発中のコードミスは開発者が見つけるべきだと思っています。それを最後のフェーズまで残しておくと、以下のようにコストが多くかかることに。

▲Capers Jonesの言うカオスな状態
(書籍『ソフトウェア品質を高める開発者テスト』より)

世界的に著名な学者・Capers Jonesもバグの混入フェーズと発見フェーズが1つ遅れると2倍のコストがかかると説いています。例えば、要求のコーディングのバグが設計で見つかれば2倍。要求のバグが保守で見つかれば2×2×2×2=16倍というように。

わたしは、自分のした仕事のミスは自分で見つける、もしくはミスをしない!というのが仕事の基本だと思っています。これ、すごく普通のことを言っているけれど、かなりの組織でできていないことかと。(ソニー在籍中の上司は、「自分のケツは自分で拭け!」といつも言っていました。ケツとかクソとか汚い話が続き申し訳ないですが……)

また、独立行政法人情報処理推進機構は以下の数値を出していて、上流工程で品質を担保したほうが、出荷後の品質は上がると書いてあります。例えば下記図・右の「出荷後品質が悪い」であれば、66%のバグしか上流工程で発見できなかったということです。反対に、左の「出荷後品質が良い」ときには、85%ものバグを上流過程で発見できているのです。

▲上流工程でのバグ発見数の割合と出荷後の品質
(書籍『ソフトウェア品質を高める開発者テスト』より)

わたしは、製品全体のバグの密度(LOCあたりのバグ数)が多いものほど、上流工程でバグを発見できていないと考えています。もしも品質コストを下げたいのであれば、上流工程でバグを見つけることが一番てっとり早いと思いませんか?
*Line of Codeの略

どんなポジションでも意識すると良いこと

最後に。ついているポジションによって求められる仕事は変わってくることを前提にしても、個人でできることは、まず、ミスのない仕事をする、そして、自分のした仕事のミスは自分で見つけ、修正するという意識を持つことが大事だ、ということです。

▼これまでのソフトウェア品質を高めるために知りたい開発者テストの最前線
第1回 なぜテストは必要なの?