隣のテストチームが優秀ないくつかの理由（前編）：The Rational Edge

Rational Edgeより：ソフトウェア開発チームを編成するときの成功の秘訣は何だろうか？ スーパースターを採用するのではなく、多様な長所やスキルセットを持つメンバーを確保することだ、と本稿は断言する。本稿はプロジェクトやチームのマネージャのために、チームメンバーにとって望ましい特性や、監視や矯正の必要なチームメンバーの特徴について解説する。

» 2005年05月18日 12時00分 公開
[Len DiMaggio（Software QE Engineer and Manager, IBM），＠IT]

　ソフトウェアテストで成功するチームと失敗するチームがあるのはなぜだろう？ 単に、チームに割り当てられた作業の内容だけで決まるのだろうか？ つまり、成功と失敗の違いは前もって分かっているのか、つまり、チームは事前に対応できないのだろうか？ あるいは、「スーパースター」を集めて完全に任せてしまうことだけが成功のカギなのだろうか？ 逆に、効果的なチームリーダーシップだけで成否が決まるのかもしれない。果たして正しい答えは何だろう？

ALT 本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　手短にいえば、簡単なソリューションはない、というのが答えになる。どのチームでも、その自立性と、外部の支配力やチーム内の責任に対応する必要性とのバランスを取る必要がある。いうまでもなく、輝かしい能力を持つ人間を採用することもチーム編成には役立つが、それが成功を保証するわけではない。

　本稿では、能力の高いテストチームを際立たせる具体的な特性についていくつか見ていく。ソフトウェアテストを行うエンジニアやマネージャが、これらの特性や、それを自分たちのチーム内で養う方法を理解できるよう支援することが狙いだ。

◆ 優れたテストチームの特性

　「個を捨て、チームプレーに徹せよ」「力を合わせれば1＋1が3になる」など、チームの能力向上を表現する言葉は多い。これらは、個人の集まりとしてではなく結束した1つの単位として行動するのが優れたチームだ、との解釈だ。しかし、有能なソフトウェアテストチームには、それよりもっと複雑な（そしてありきたりの言葉では表現できない）特性を持つという共通点がある。最初にこれらについて見ていく。

◎ テストチームと明確な役割

　John Donneの言葉を借りれば、単独で作業をするソフトウェアエンジニア（やチーム）は存在しない、ということになる。iPodだけをそばに置き、1人きりで何時間も会社の仕事でコードを書き続けることもできるが、それが成功するかどうかは仲間の努力次第だ。そして、チームの成功も、ほかのチームの努力にかかっている。

　相互に依存するソフトウェア開発やテスト作業を成功させるには、各自の責任、成果物、チームメンバー間およびチーム間相互のやりとりの基準となる手順を、チームが明確に定義する必要がある。つまり、チーム内およびチーム間の作業を進めるため、チームは社会契約を結ばなくてはならない。チームメンバーの個人としての役割や、ほかのチームとの関連におけるチームの役割は、これらが明確にしてくれる。

　なぜ、これが必要なのだろう？ まず、これがあることでチームはその目標達成に集中できる。本当の目標を見つけるにも、それを擁護するのにも、特殊な作業や能力は一切必要ない。

　次に、このような社会契約が存在しない場合は、ソフトウェアプロジェクト（ついでにいえば、人間の複雑な事業すべて）は、「法律の集まりではなく、人の集まり」として機能するようになる。つまり、プロジェクトチームとそのメンバーの仕事の進め方は、個人の経験、判断、そして特定の関係者の集まりが犯す失敗だけで決まってくる。誰もが頼りにできる、明確かつ詳細に文書化された規則の集まりは作り出せない［注1］。プロジェクトの成功は、これらの人々が問題や相互のニーズを予期する力、相互の問題に感情移入する力、そしてプロジェクトの利益拡大路線を進めるために個を捨てて献身的になる力だけに依存するようになる。このような環境で信頼できる人物をあなたは何人ご存じだろうか？

［注1］ 明確な「規則」のないプロジェクト環境でチームの編成と運営を行うことは、Franz Kafkaの「審判」の主人公の身に起こる出来事と似ている。主人公は犯罪を告発されながら、自分が何の罪を犯したか分からないのだ。

　ソフトウェアプロジェクトが定義した開発およびテストプロセスに左右される度合いには、プロジェクトの環境に応じて大きな開きがある。入念に定義されたIBM Rational Unified Process（RUP2）［注2］のような包括的プロセスで組織化されたプロジェクトもあれば、場当たり的なアプローチもある。後者のような環境では、ソフトウェアテストチームはゼロからスタートし、その役割を明確にして、ほかのプロジェクトチームと社会契約を交わす必要がある。一方、前者のような環境では、テストチームの役割を明確にする作業はわずかしかないが、「プロセスに従って進めていく」などとプロジェクトリーダーが単純に宣言するだけでは進まない。彼らは、プロジェクト独自のニーズや要件を考慮に入れる必要がある。トマス・ワトソン・シニアは、「『考えること』を忘れるな」というのが口癖だった。


◎ テストチームは多種多様

　近ごろでは「多様性」という言葉を聞くと、会社の労働力が実社会における民族、人種、社会の構成を全体的に反映するよう目指す比較的最近の取り組みを思い起こすことだろう。ソフトウェアテストチームを編成する場合も、チームメンバーのスキル、個性、そして経験の多様性を考慮しなくてはならない。ソフトウェアテストチームのメンバーは比較的均質になるはずだと思われるかもしれないが、多様な個人の集まりがチームとしては最強だ。この点を詳しく見てから、チーム編成時に結集すべき個性の種類やスキルセットについて詳しく述べる。

　ビジネスやエンジニアリングチームの力はしばしばスポーツに例えられる。実際に、これらの例え話がビジネスの世界でも決まり文句になっている。しかし、多くの決まり文句が不思議なのは、それがかつては正確かつ独創的な思考を反映していたことだ。例えば、筆者のようにマサチューセッツ州ボストンで育ち、少しでもスポーツに興味がある読者なら、野球のボストン・レッドソックスにまつわる1967年の話はしょっちゅう耳にする。その年、チームは20年来の悲願だったペナントレースで初優勝を飾った。彼らはスーパースターをそろえるのではなく、一握りの本物の「スター」と、経験はないが可能性を秘めた多数の若手選手、そして経験豊かだが無名で、さまざまな役割を演じられる選手を集めて偉業を達成した。それは、多様性に富み、偶然にもかなりエキサイティングなチームだった。チームが成功したのは、個々の選手が輝かしいシーズンを送っただけではなく、選手の多様なスキルと個性がかみ合ったからだった。

　これと同じような多様性は、成功するソフトウェアテストチームを編成するときにも重要だ。Javaのような特定のプログラミング言語の習熟度や、J2EEのようなアーキテクチャの経験値など、スキルを数値化するのは比較的簡単だ。しかし、チームのメンバーに期待する思考過程、癖、習慣、視野など、そのほかの経験内容はどうだろう？

◎ テストチームに望まれるタイプ

　テストチームは、演劇や映画の配役のように、「性格分けされた」人物一覧からプロジェクトの要件に応じて選抜し、編成するのが理想だ。確実な成功を目指すには、チームにどのようなタイプが必要なのだろうか？ 可能性をいくつか見ていこう。

　「早期導入者（The Early Adopter）」：ソフトウェアエンジニアリング作業の一面が、「絶え間ない変化」によって同時に訪れる喜びと苦しみだ。最新だと思って技術やツールを用意した途端に新バージョンや新製品がリリースされ、また後れを取ってしまう。しかも、それに対しては最新の進歩に追随すべく努力するしかないのだ。立ち止まっていると、すぐに後れを取ってしまう。従って、チームには最新ソフトウェアの探求を楽しみ、チームのソフトウェアテスト環境に対する追加提案が行える人物が必要となる。

　「安定導入者（The Constant Adopter）」：「早期導入者」を補完するのがこの人物で、チームの特定のニーズに合わせて新しいものと既存のものの両方のソフトウェアツールを導入する。例えば、データベース管理者が壊滅的な障害を復旧させるのに役立つツールを「早期導入者」が見つけたとする。すると「安定導入者」がそのツールの使い方を習得して、それを別の目的にも利用し、一連のテストを行ってからテストチームのメンバーがデータベースを再構築し、「クリーン」なテスト環境を復元できるようにする。

　「統合愛好家（The Happy Integrator）」：管理計画より必ず時間がかかり、深刻でデバッグの難しい問題を明らかにするに当たり、一般にはほかのテストほど重要でない、と考えられているテストが1つある。それが統合テストだ。最近では、自社製品のソフトウェアを実際にすべて自分たちで書くチームはないようだ。その代わり、他社が提供するコードやオープンソースコードを使って自社製品用の多数のパーツを開発する。複数の場所で開発されたコードの統合テストは、1カ所で開発されたコードをテストするのとは大きく異なる。統合されるサブシステム間の境界（および潜在的なギャップ［注3］）から見て製品の動作を検証する必要がある。サブシステムの部品間におけるデータとプロセスフローを理解および解読する必要から、このようなテストにいら立ちを見せる人もいる。しかし幸いにも、一部には「探偵のような仕事」を楽しむ人が存在するのだ。

［注3］「Orchestrating Integration Tests」、2003年7月、Software Testing and Quality Engineering刊（http://stqe.net）

　「経験豊かな炭鉱夫（The Experienced Miner）」：地図を見ないで石炭鉱床を探し当てるベテラン炭鉱夫の話がある。炭鉱夫としての経験が非常に長いため、直感的に石炭の場所が分かり、つるはしを一振りしただけで掘り当ててしまうという。彫刻家がのみを石のどこに入れればいいか正確に感じるのと同じように、石の表面が割れて石炭が現れるのに最適な場所が感覚で分かるのだ。一方、ソフトウェアのテストに関しても、このような人々が存在する。非常に重要なバグを発見するテストをする際に、テストするソフトウェアの実行に適した場所を状況にかかわらず見つけられるのだ。このスキルはテストされるソフトウェアの種類に関する経験が基盤になることもある。

　例えば、Javaサーブレットの設計や運用で直接の経験がある人は、サーブレットベースのアプリケーションにある欠陥を見つけるのもうまい［注4］。また、ソフトウェアテストエンジニアは、同じようなタイプのプロジェクトで得た経験に基づいて「重大なバグ」が正確にどこにあるのか分かるようになる。また、同様の設計もしくはプロジェクト管理上の問題を抱えたプロジェクトに参加した経験も考えられる。例えば、一部のソフトウェアには、市場や技術の変化に応じて開発やテストの課程でどうしても設計を変化／進化させなくてはならないものもある［注5］。

［注4］「Testing Java Servlets」、Dr. Dobbs Journal、2004年8月号
［注5］ソフトウェアデザインに関する概念的統合性は、Fredrick Brooksの傑作、「The Mythical Man-Month」に詳しい。

　「革新の鬼（The Indefatigable Innovator）」：問題へのアプローチで常に新しい方法を見つけ出す人を指す。手前みそだが、筆者は多くのプロジェクトチームでこの役を演じてきた。筆者はかなり以前に、面白いプロジェクトからほとんど面白くないプロジェクトへと、突然に担当の変更をいい渡されたことがある。逆境での最善策を模索した筆者は、新しいテストサーバのソフトウェアコンフィグレーション定義とトラッキングツールを、XMLデータベースを基盤にして設計／構築することにした。面白くないプロジェクトに不満を抱いたチームの別のメンバーと筆者がこのアイデアについて議論したところ、彼女は悲しい目を向け、「クリエイティブなことは一切しないでほしい」と戒めてきた。いまの（問題を抱えた）プロジェクトの状況に縛られ過ぎていて、古い問題に新しいアプローチで取り組むメリットが見えなかったのだ。プロジェクトに参加したばかりで、有益な新しいスキルの修得にやる気満々だった筆者には、違うことを試すのは全く問題なかった。複雑なテストサーバコンフィグレーションを自動構築するツールの開発、という究極の目標を達成することはなかったが、筆者はXML DTD［注6］のデザインに関するかなりの知識を修得し、複雑なサーバコンフィグレーションを数値化する（主に手作業による）アプローチも明確にできた。

［注6］Document Type Definition。XMLやDTDに関する優れたチュートリアルはhttp://www-128.ibm.com/developerworks/views/xml/libraryview.jsp?type_by=Tutorialsを参照。

　「予見者（The Visionary）」：「革新の鬼」に技術的な問題に対する新しいアプローチ方法が見えるのに対し、「予見者」にはレベルの高い戦略的な問題に対するソリューションが見える。チームには、特定のアプリケーションのテストだけでなく、ソフトウェア全般のテスト方法に関する幅広いビジョンを持ち、「全体像」の見える人物が必要だ。既存のソリューションを新しい問題に当てはめようとすれば、簡単に落とし穴にはまってしまう。それが最も現実的なアプローチである場合もあれば、「新たな考え方」［注7］で新しいソリューションを考え出さなくてはならない場合もある。技術が変化するスピードはかつてなく速まっている。昨日がすでに「過去」になることもあり、行動に出ないと簡単に追い抜かれてしまう［注8］。どのチームにも、先を見て考え、行動するビジョンを持つ人物が必要なのだ。

［注7］筆者はAbraham Lincoln大統領の次の言葉も以前から好きだ。「何事もない過去の定説は　激動の現在には当てはまらない。好機には障害が山積みだが、われわれは好機に乗じなくてはならない。新たな問題に遭遇したら、新たな考え方と行動によって対処しなくてはならない」
［注8］「Four Lessons for Software Testers and Their Managers」、The Rational Edge刊（http://www-106.ibm.com/developerworks/rational/library/4865.html）

　これらの人物に共通する特性に気付かれただろうか？ 彼らは皆飢えている。もちろん彼らの食習慣についての話ではない（ただ、一般にテスターは差し入れの食べ物をガツガツ食べる傾向にあることも事実だが）。ソフトウェアのテスト手法に対するアプローチについての話だ。彼らは好奇心が強く、積極的で、順応性があり、新しいことを積極的に試みたり、「それがなぜか」を考える。彼らは常に技術的に成長していて、学習も怠らない。静観することしかせず後れを取るようなことはない。

（後編へ続く）

本記事は「The Rational Edge」に掲載された「High-performance software testing teams: A guide for managers and team leads」をアットマーク・アイティが翻訳したものです。
「The Rational Edge」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ