●●●● パッケージソフト開発のテスト体制

●●● 前書き
●● はじめに
2001年4月、筆者は他の数人と一緒にアリエルネットワーク株式会社(以下アリエルネットワーク)を創業しました。創業以来、一貫してパッケージソフトウェアの開発を行っています。
パッケージソフトの開発を通じて製品の品質を上げるために様々な試行錯誤を行ってきました。本特集では開発の現場で行ってきた品質を上げる施策について、過去、現在、未来に分けて書きたいと思います。

●●● 過去
●● アリエルネットワークの成立ち
アリエルネットワークは5人のメンバーで創業しました。5人のうち(筆者を含む)4人は現役のプログラマで残り1人の創業社長も元ソフトウェア技術者という開発者の集まりでした。そして5人全員が外資系ソフトウェア開発会社で働いた経歴を持っていました。外資系ソフトウェア会社もDEC、Lotus(IBM)、Microsoftなど、開発プロセスを確立していた企業でした。このため、ありがちな学生ベンチャーに比べれば創業当時から開発プロセスらしきものがあったかもしれません。一方で、開発プロセスは出来の悪いプログラマのための言い訳であって、信用できるのはコードだけだと言わんばかりのハッカー精神(反骨精神?)にも満ち溢れた出発でもありました。

●● 少数開発体制でのテスト体制
創業当時の主力製品が、現在アリエル・マルチスケジューラ(以下マルチスケジューラ)として知られるP2P型グループウェア製品でした。製品の紹介はWebサイトに譲ります(http://www.ariel-networks.com/multischeduler/)。

創業当時から存在した開発プロセス(開発文化)には以下のものがありました。

- ソースコード管理システム(SCM)
- バグトラッキングシステム(BTS)
- デイリービルド(ビルドの自動化)

SCMとBTSは今はどこでも当り前のツールだと思うので説明を省略します。デイリービルドは最近の用語を使うと構成管理のひとつとして位置づけることが多いかもしれません。毎日自動的にビルドが走り最新版の製品ができる仕組みです。

筆者はアリエルネットワーク創業の前に、米国でLotus Notesの開発に携わっていました。そこではビルドマスターと呼ばれる人が定期的にビルドをしていました。ビルドが通らない、つまりコンパイルエラーを起こすコードをコミットすると、ビルドマスターから呼び出しがありました。ビルドルームでビルドマスターからコンパイルエラーの起きたコードを示されます。その場でコードの意図の説明を求められその場で修正する必要がありました。ビルドマスターの仕事はビルドを通すことです。できあがったビルドはスモークテストチームに渡ります。スモークテストを無事に通過したビルドはテスト可能ビルドとしてテストチームに渡ります。テストできるビルドがなければテストチームの計画が狂います。開発チームの規模の大きくなるとデイリービルドの意味は大きくなります。

閑話休題。それに比べればアリエルネットワークのデイリービルドの価値は些細なものでした。実質、開発者の全員がプログラマだったので全員が手元でビルドできたからです。デイリービルドの価値はソースコードから最終成果物(インストーラまで含めた配布物)を自動で生成できる仕組みにありました。成果物をキットと呼ぶことからこの工程をキッティングと呼びます。パッケージソフト開発の中でキットに誤りが混入する危険は意外に高いのでキッティングを自動化することは重要です。ここから得られる教訓は明確です。日常的に行わない作業に誤りが混入しやすい問題に対して、作業そのものを日常化する解決策が有効だということです。

デイリービルドの仕組みと同時に重要だったことは(書籍「闘うプログラマー」で有名な)ドッグフードモデルを徹底していたことです。ドッグフードモデルでは、自分たちの作ったソフトウェアを開発中から自分たちで使います。開発中なのでバグもあります。データが消える危険もあります。それを恐れず自分たちで使います。この文化は今でも継続しています。

一方、存在しなかった開発プロセスは以下のようなものでした。

- (公式の)コードレビューやコードインスペクション
- 自動化した単体テスト
- テスト専任チーム
- (まともな)機能仕様書
- (まともな)テスト計画
- テスト管理ツール
- バグ統計
- システム化あるいは自動化されたリグレッションテストの体制
- (まともな)リリース管理

ないものばかりで恥ずかしいのですが現実はこんなものでした。

コードレビューについては補足があります。当時の開発チームの規模では、各プログラマは他人の書いたコードにたいてい目を通していました。公式な開発プロセスとしてのコードレビューはありませんでしたが、プログラマの中に恥ずかしいコードは書けないという雰囲気がありました。結果として非公式にピアレビューが機能していました。そして、まあだいたいのところコードの全体像がプログラマの頭の中に入っていました。個人的には、理想的な品質確保の方策は、ソフトウェア(モジュール)の規模をひとりのプログラマの頭の中に入るぐらい小さく保つことだと思っています。もちろんこれは理想であり現実の複雑さは簡単にひとりのプログラマの頭の容量を越えます。

●● テスト計画もリリース管理もない
ない開発プロセスばかりでしたが、その中でもテスト計画がなかったという事実に驚くかもしれません。笑われるかもしれませんが、当時の筆者たちは、だいたい機能が揃った日をフィーチャーフリーズ、だいたいコードが安定した日をコードフリーズ、それから1ヶ月ぐらいテスト期間とバグ修正期間をもうければアルファ版リリース、バグ修正がある程度落ち着いたらベータ版リリースぐらいに考えていたのです。それなりにテスト期間を経れば、リリースできる品質になって正式版リリースできる、と考えていました。

恥ずかしながら、初めてパッケージソフトをゼロから開発してリリースするプログラマの集まりの実体はこんなものでした。

最近のよくできたフレームワークを使って作ったWebアプリであれば、このぐらいいい加減なリリース計画でもなんとかなるかもしれません。しかし、アリエルネットワークはベンチャーキャピタル(以下VC)からの資金で創業したベンチャー企業でした。当時も今も平凡な製品にVCは資金を投下しません。マルチスケジューラは非同期IO、マルチスレッド、独自のXMLストレージ、マルチプラットフォーム等々と難易度が高い上に、P2Pというテストの難しい分散システムでした(言語はCおよびC++)。いい加減な計画でリリースするのは難しい製品でした。

当時、しばしばVCから製品がリリース品質に達しているのか質問されました。できる回答は、このぐらいの期間テストしたので大丈夫、制限事項は当然あります、バグのないソフトウェアはありません、という言い訳と区別のつかない根拠のない回答ばかりでした。

最終的に製品をリリースしました。ベンチャー企業は製品をリリースしなければゲームが始まらないからです。リリースに当たって特別な品質基準はありませんでした。当然、利用者からのバグ報告もありました。バグ報告には俊敏に対応するというスタイルでリリースを積み重ねました。

リリースを重ねる中で開発者の数も増え、様々な開発プロセスの試行を行ってきました。しかし、昔話ばかり続けるのも気がひけるので時代を飛ばして現在に話を移します。良くも悪くもマルチスケジューラの開発は今も少数開発体制を続けています。一方、次に述べる現在の開発は大規模開発とまではいきませんが中規模と言えるぐらいの開発体制になっています。


●●● 現在
●● エンタープライズ向け製品
現在の主力製品がアリエルエンタープライズというエンタープライズ向け製品です。製品の詳細はWebサイトに譲ります(http://enterprise.ariel-networks.com/)。

マルチスケジューラの開発との前提の違いを挙げます。

- 開発者の人数が多い(30人以上)
- 顧客は大企業

言語はJava、データベースはOracle、いわゆるWebアプリです。大企業向けの製品で、スケーラビリティや既存システムとの連携に力をいれています。大規模システムなので品質への要求が非常に高くなっています。マルチスケジューラの利用者は中小企業や個人が中心のため、バグがあっても迅速に修正版を出せば対応の速さが評価されます。大企業向けシステムは事情が異なります。最初から安定したリリースを求めます。バージョンアップがなるべく不要な製品が求められます。Web 2.0で言う永遠のベータ版のような都合のよい言い訳が通用しない世界です。


●● 開発体制
現在存在する開発プロセスは次のものです。

- 自動化した単体テスト
- テスト専任チーム
- テスト計画
- バグ統計
- 自動化したパフォーマンステスト
- リグレッションテストの体制
- リリース管理
- テスト管理ツール

随分立派な開発体制になりました。もっとも個々に見れば実はほころびもあります。詳細は後述します。

試行して結局続かなかった開発プロセスもあります。

- (正式な)コードレビューやコードインスペクション
- (まともな)機能仕様書
- 自動化した機能テスト

最も大きな変化はテスト専任チームができたことです。

●● テストチームを持つべきか
過去、緊急的にテストチームを作ったことがありましたが継続はしませんでした。本論での「テストチーム」の意味はプログラムを書かずにテストを専任に行う技術者のチームのことを指します。

今はテストチームがあります。既に1年近く継続して今後も強化しようと考えています。

テストチームを作るにあたっては賛否両論がありました。反対派の急先鋒は筆者自身であり他にどれほど反対派がいたのかは定かではありません。

テストチームに反対した理由は主にふたつありました。ひとつはプログラマが品質に対して他人任せになることを恐れたからです。プログラマはテストまで含めて自分のコードに責任を追うべきだと考えていました。俗に言う、品質責任者を置くと品質が落ちるという都市伝説につながります。プログラマが思い込みにより自分の書いたコードのバグを見つけられない危険は理解しています。この問題はプログラマが相互にテストすることで解決可能だと考えています。

もうひとつの理由は世の中のテスト技術者への不信感でした。不信感にはふたつ背景がありました。能力の問題とモチベーションの問題です。能力の問題はテスト技術者の採用面接での印象です。採用面接の場で、基本的な論理的思考能力に疑問を抱く人が多かったのです。オールペア法や直交表を知る必要は感じませんが、諸条件の組み合せを頭に展開できるだけの思考力は必要です。ソフトウェアのテストを行う以上、境界値の意識や2分探索的な発想は必要だと思います。プログラマであれば自然と身につけているこれらの発想に欠ける人が多かったのです。もうひとつはテスト技術者のモチベーションの問題です。以前の会社でテスト技術者の知り合いが何人かいました。外資系ソフトウェア会社にはテスト技術者と翻訳担当が多かったからです。彼らの多くが、本当はプログラミングがしたいのに仕方なくテストをしていると愚痴を言っていました。はっきり言うと、彼らは楽しそうではなかったのです。嫌々仕事をしている人を会社に雇いたくなかった、というのがテストチームに反対していた理由のひとつでした。

反対派の筆者がテストチーム成立に至った経緯は必要に迫られてです。プログラマの数が増える中、高い品質を達成するため開発期間の半分をプログラマがテストをしている状況になってきました。テスト期間中、プログラマはバグ修正も行います。開発規模の小さいうちはなんとかなっていましたが、人が増えると非効率が目立つようになってきました。テストを分業すべき時かもしれないと思いテストチームを発足する決断をしました。


●● テスト技術者に求めること
創業当時のコード至上主義の名残で今も社内には文書化を軽視する傾向があります。開発者の人数が増えて文書化の必要性が増していますが、動いているコードが仕様という風潮が残っています。ある面では恥ずかしい事実ですが、ある面では必要悪の文化でもあります。デマルコも言うように、ソフトウェアの品質とはバグの少なさだけではないからです。機能や魅力、市場への素早い提供まで含めて顧客満足度こそが品質なのです。バグの数を最少にしたソフトウェアが最高品質ではないのです。

まともな機能仕様書があるとは限らない前提でテスト技術者を採用する必要がありました。重要なのがプログラマから話を聞き出す能力です。コミュニケーション能力と呼ぶと安っぽいですが、そう呼んでも構いません。プログラマがテスト仕様書らしきものを書くことはありますが、仕様書に書いてある項目だけをテストするのでは不充分です。仕様書の出来が悪いから、もひとつの理由ですが、たとえ仕様書の出来が良くても事情は同じです。なぜなら多くのバグはプログラマが仕様書に書かない(書けない)部分に存在するからです。テスト技術者の役割は単にテスト仕様書に書いてある項目を機械的にこなすことではありません。プログラマと会話をして機能の意図や詳細を聞き出す必要があります。意図を聞き出す過程でプログラマ自身に気づきを促すこともあります。テスト技術者が利用者視点でプログラマから話を引き出すことで、副次的にデマルコの言う本当の品質、つまりバグの多寡ではない製品そのものの魅力を引き上げることができます。

白状すると、この副次的な効果は後から気づいたことです。仕様書がまともにない環境ではテスト技術者がプログラマから話を引き出さざるをえない必要悪から始まった話です。結果としてテスト技術者は製品のグランドデザインに貢献する存在になります。外資系ソフトウェア会社で、ただバグ報告をして修正を待つ受身の存在とは異なるものです。

プログラマと話をできる必要から導かれる、テスト技術者に求める資質は次のようになります。まず基本的な頭の良さがある人です。プログラマは頭の悪い人と話をするのが嫌いだからです。過度に感情的にならない人。同じ理由です。素直な人、知らないことを知らないと言える人。プログラマはシステムの専門家なので生半可な知識で対抗しようとすると喧嘩になるからです。

こう書くとテスト技術者に無知を求めているように読めてしまうかもしれません。それは誤解です。広い視点を持てる人や細かいことを覚えてくれる人はプログラマから頼りにされます。これを製品知識と呼んでもいいでしょう。プログラマは覚えておく必要のないことを頭から追い出す人種です。筆者も自分の作った機能の詳細を簡単に忘れます。コードを見て調べればわかるのですが、調べてわかることは覚えておく必要を感じないからです。製品の機能を事細かに覚えているテスト技術者ほどありがたい存在はいません。

テスト技術者はプログラマとの会話からテスト仕様書を作成します。テスト仕様書には、文書として明示化する意図とリグレッションテストでの再利用のふたつの目的があります。


●● テスト自動化の夢
下世話な話になりますがテストチームの人数を増やすと人件費がかかります。ソフトウェア開発でコストは無視できません。前節ではテスト技術者の創造的な面を強調しすぎました。現実には単調な仕事も多いのです。ソフトウェアをバージョンアップした時、既存の機能が壊れていないかを確認するリグレッションテストは特にその傾向が強くなります。

テストを自動化して単調な仕事を減らすべく努力を続けています。結論から言うと、現状うまく機能しているのは自動パフォーマンステストだけです。JMeterを使い毎日自動でパフォーマンス計測を実施しています。

JUnitを使った単体テストの自動化も実施しています。一部に効果はありますが、本当にバグが多いUIまわりに効果はありません。

UIまで含めた機能テストの自動化の試みをしたことがあります。結論から言えばテストスクリプトを保守できず放置状態です。失敗の原因は欲張りすぎたことにある気がします。正常系に限定する割り切りが必要かもしれないと感じ始めています。

●● リリース管理
長い間、アリエルネットワークではリリース管理が懸念事項でした。一般に、品質がリリース基準に達したかを測るためにバグ収束曲線を描きます。横軸に時間経過、縦軸に(有効)バグ報告数をプロットします。テスト期間の初期はバグ報告数が増え、品質が安定すればバグ報告数が減り一定数以下で落ち着く理屈です。より精緻に行うにはテスト技術者を増やしてもバグ報告数が上昇しないことで、リリース基準品質に達したと信じることもできます。

信じると書いたのは皮肉ですが事実です。個人的にバグ収束曲線の罠と呼んでいる現象があります。バグ収束曲線というのは簡単に操作可能です。特に開発者(プログラマとテスト技術者の両方)がリリース予定日を知っている場合、なおさらです。テスト技術者はテスト範囲を絞ることで、そして有効バグ報告数はトリアージによってコントロールされます。トリアージという用語は最近だいぶ知られるようになりましたが、バグを対処するか無視(制限事項)するかの判断をすることです。リリース間際に本当に致命的なバグだけを修正するのは、ソフトウェア開発の鉄則です。些細なバグを修正することで副作用バグを埋め込む危険の方が恐いからです。適切なトリアージはソフトウェアのリリース管理に必須の技法ですが、バグ収束曲線を簡単に操作可能であることも示唆します。

開発者がリリース間際にバグ報告数を抑えるのは不誠実だと感じるかもしれません。しかし、ソフトウェアを何度もリリースしてきた経験から言って人間心理の避けられない事実です。終わりの見えない目標に立ち向かえるほど強い人は滅多にいません。

この問題への対策はタイムボックス開発です。一部のオープンソースが採用しているので言葉を知る人もいると思います。よほど致命的なバグが見つかればリリース日を延期しますが、基本的にバグ収束曲線を気にせずに事前に決めたリリース日にリリースします(脚注)。一般にソフトウェア開発では、時間、機能、人の3つで品質を制御します。品質が低い場合に取るべき手段は、時間を延ばす(リリース日を延期する)、機能を削る、人を増やすの3つが大きな方策です。人はそう簡単に増やせません(かつ安易に増やしても有効とは限りません)。なので、通常、時間を延ばすか機能を削るかの2択を迫られます。タイムボックス開発では時間を厳守して機能を削ります。これがパッケージソフトのリリースをしてきた経験から得られた黄金則です。

<脚注>
バグ報告がたくさんあってもリリースするのかと聞かれそうですが、大丈夫、それなりに収束します。
</脚注>

最後に今も残る課題を含めて未来について書きます。

●●● 未来
●● 情報洪水
過去にはメーリングリストや掲示板を使う時代もありましたが、現在、開発内のコミュニケーションの大部分をBTSのtracで行っています(脚注)。すべてのバグはtracにチケット化します。更にすべての実装予定もtracにチケット化します。仕様に関する議論や実装の進捗はすべてtrac上のコメントで行います。

<脚注>
tracのコメントはメーリングリストに流れるので、筆者をはじめ実際にはメールで読む人も多いです。
</脚注>

情報をtracに集約することはポケットひとつの原則に従っていますが、残念ながら問題もあります。量の問題です。現在、1ヶ月あたりに新規チケットが約300個程度作られます。それぞれにコメントがついた時の情報量の爆発は想像できると思います。もはや社内に議論をすべて追えている人は僅かです。社内でtracは完全にオープンな場です。誰もが読めて誰もが書けます。にも関わらず、誰も知らない場になる危険があります。

情報洪水の問題は深刻です。タグ付けやビュー(フィルタ)などの解決を試みていますが決定打はありません。ひとつヒントに感じているのがオープンソースの世界の「まとめサイト」や「定期ステータスレポート」です。オープンソースの世界では重要な議論や決定をメーリングリストやIRCで行うことが多くあります。開発規模が大きくなるとこれはオープンな密室になりがちです。このような時、状況を簡潔にまとめたサイトやレポートを作る人がいます。伝令や広報の役目を負う人です。広い視野を持つテスト技術者に適任の役割だと思います。

●● テスト管理ツール
リグレッションテストの体制を整えたことは開発プロセスの大きな進歩でした。しかしバージョンアップを重ねるごとにリグレッションテストの量が膨大になってきました。リグレッションテストに優先順位をつけて適切に管理しなければ破綻します。

この目的のためにテスト管理ツールTestLinkを導入しました。TestLink以前はテスト仕様書をテキストファイルで管理していました。テキストファイルでもフォーマットを統一すればコマンドラインツールで管理可能ですが、テスト技術者の誰もがgrepやsortのコマンドを使えるわけではありません。

TestLinkを使う前は効果に半信半疑でしたが、結論は非常に有効だと判断しています。これからは、ソースコード管理システムやバグ管理システムと同程度にテスト管理システムも常識になっていくべきだと感じました。

●● テスト技術者の地位向上
今まで、テスト技術者はプログラマと同じチームに所属していました。最近、テストチームを独立しました。名称は品質グループです。名称がテストグループではない点にこだわりがあります。本書の書名が「ソフトウェアテストPRESS」なので大きな声で言いづらいのですが、テスト技術者はテストをしてバグを見つけるだけの存在であってはいけないと思っています。品質全般に気を配るべきです。テストが品質を確保する有効な手段であることは間違いありませんが、品質グループは開発プロセスの改善まで視野にいれて活動することがミッションです。