The Rational Edge
隣のテストチームが優秀ないくつかの理由（後編）
（マネージャとチームリーダーのためのガイド）


Len DiMaggio
Software QE Engineer and Manager, IBM
2005/5/21

前編の内容：「隣のテストチームが優秀ないくつかの理由（前編）」では、優秀なテストチームを編成するために求められる人材の種類を考察した。要件に応じてさまざまなタイプの人材をうまく登用することが上手なチーム編成の決め手になる。後編では逆に、問題のあるスタッフのタイプをリストアップし、彼らをどうすれば“矯正”できるかを考える。そのうえで、テストチームにおけるマネージャの役割を考えてみよう。

◎ 矯正の必要があるタイプ

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

　先へと進む前に、ここでテストチームの作業の足を引っ張る可能性のある人種と、彼らのエネルギーをもっと生産的な作業へと向かわせる方法についても考えてみよう。

　「レポート中毒」：ソフトウェアテストエンジニアにとって重要なのは、すべての欠陥の報告や、特定のハードウェアおよびソフトウェアコンフィグレーションを網羅したテストなど、テストの進ちょく状況を正確に追跡する作業だ。一般的に「メトリックス」と呼ばれるこの進ちょく状況／欠陥情報は、テスト中のソフトウェアをアルファテストからベータテストへ移行させるかどうか、ベータテストから一般リリースに移行させるかどうかなど、極めて重要な判断材料になる。この進ちょく状況関連の情報は、常に目的を達成するための手段となるので必ず覚えておきたい。

　 ここでいう目的とは、売り上げ達成に向けたソフトウェア製品の開発、テスト、およびリリースを指す。決して、進ちょく状況情報の収集や提示自体が目標になってはならない。ソフトウェアテストエンジニアが設計、コーディング、実施、デバッグというソフトウェアテストの実作業より多くの時間と労力を進ちょく関連の作業に掛けていることに気付いたら、それは「レポート中毒」［9］が潜んでいることを意味する。「レポート中毒」を示唆するものとしては、ほかにどのような兆候があるだろうか？ 第1に、これらの人々は、問題克服に向けた新しい方法を試すことをせず、作業が完了しない理由を極めて詳細に報告することに労力の大半を費やす。第2に、彼らは多くの時間をかけ、現状報告の書式をめぐってあれこれ議論する。筆者は、数ページに及ぶ文章と、膨大な量の色鮮やかなグラフや図がレイアウトされながら、有益な情報はほとんど含まれていない現状報告書を見たことがある。特に難しいプロジェクトを進めていた数年前には、同僚の1人から「現状報告書を売った方がよいのではないか。こちらの方が開発している製品よりはるかに見栄えが良い」というジョークを聞いたこともある。

［9］韻を踏むのが好きな筆者の同僚は、メトリックスの収集とレポートの作成が好きな人々を「Maniacal Misanthrophic Metrics-aholics（人間嫌いの熱狂的メトリックス中毒）」と呼ぶ。何ともすごいいい回しである。

　「レポート中毒」はどうすれば治せるだろうか？ よくいえば、彼らは素晴らしい労働観とエネルギーの持ち主である可能性が高い。彼らはまた、欠陥やテストの進ちょく状況など、各種メトリックスを追跡することの重要性も理解している。つまり、これだけのエネルギーを正しい方向へ向けさせ、ソフトウェアテストにおける現状報告書の作成に関する正しい認識を持たせる作業が必要になる。まず「介入」することから始め、現状報告書も重要だが、実際に出荷を目指す製品の開発／テスト作業を犠牲にしてはならないことを説く。そして、現状報告書の内容にある程度制限を加える。

　筆者の場合は、新聞記事を書く感覚で現状報告書を書くよう説明して良い結果が得られた。そうすることで、重要な問題だけ簡潔に伝えることに意識が集中する。最後に、「規則」が柔軟であることを理解しているかどうか確認する。報告書の量や詳細は、状況に応じて変えるべきだ。テストがだいたい予定どおりに進んでいる場合は簡単な報告書で十分だ。しかし、もし開発サイクルの終盤に来て深刻な問題に対処しようとしている場合は、毎日（あるいはもっと頻繁に）報告書を提出することも必要になる。

　「えせ賢人」：新しい技術課題にどう対応するかチーム内で議論している最中に、「これと全く同じ状況に遭遇したことがある。同じ問題はかなり前のプロジェクトで解決済みだ。そのときの対応を説明しよう」と声高に発言する人もいる。過去の成功事例について長々と話をし、全員を喜ばせるのだ。ここで問題なのは、この人物が貢献できるのはそのソリューションを口頭で説明することだけであり、せいぜいホワイトボードに図を描いて補足する程度だということだ。実際に機能する一連のプログラムを提供したり、詳細な資料を見せることはできない。何か具体的なものを要求しても、言葉を飾るだけで、ホワイトボードにまた別の図を描く程度しかできないのだ。さらに、この人物がいまの問題を本当に理解していなければ、参加した過去のプロジェクトのアプローチが違っている可能性だってある。

　このような人物から具体的な成果を得るにはどうすればよいだろうか？ 表面上は役に立たない話や図を描いてばかりでも、この「えせ賢人」（の少なくとも一部）の経験は、実際にチームの有益な情報源になるかもしれない。そうするためには、これらの問題を分けて考えるのだ。最初に、もしこの人物が実際はいまの作業を理解しておらず、古いソリューションを無理に合わせようとしているような場合は、その場ですぐに制止し、話の内容を逐一検討する。現行のプロジェクトをどのように理解しているのか説明させ、次々に質問をさせていく。そうすればたぶん、現状把握にはさらなる勉強の必要があることをすぐに納得するだろう。

　次に、過去に携わったプロジェクトで作った実用コードモデルが存在しない場合は、過去の作業を基盤にして現在のプロジェクト用に新しいプロトタイプを早急に構築するよう提案する。つまり、「有言実行」を促すのだ。最悪の場合でも、これで目の前にある問題の解決に向けた技術を学ばざるを得なくなり、うまくすれば、チームが利用できるプロトタイプも完成する。

　「八方美人」：先に指摘したように、絶え間ない変化に対応することがソフトウェアエンジニアリング作業の課題だ。新技術の市場投入など、変化が起きる原因が自分たちの組織以外にある場合もあるし、それが組織の中にある場合もある。例えば、ソフトウェアの進化に合わせ、設計や、計画したテスト手順を変更しなくてはならないかもしれない。これらの変化への対応には、いくつもの作業手順が必要になることも多い。

　テスターは、自分たちの作業に優先順位を付け、作業の完成に向けて時間を管理できなくてはならない。最優先される作業の進行を何かが妨害する場合は、次に優先順位の高い作業へとスムーズに移行し、後で最初の作業に戻る。中には、大量の作業を任せても、一度にはわずかな数の作業しか進められないテストエンジニアがいる。これが「八方美人」だ。

　彼らは正直で、勤勉で、チームの目標達成に役立ちたいと思っているにすぎない。作業の進行が止まると、彼らは必ず別の作業を志願する。そして結局、あまりに多くの作業を引き受けてしまい、何もかもやろうとして、実際には何も完成できなかったり、優先順位の高い作業の責任を果たせなくなるほど忙しくなる。単に手を広げ過ぎなのだ。

　これの変種が「逃亡者」だ。「逃亡者」と「八方美人」との間には、自分の能力を超えた数の作業を意図的に志願するという決定的な違いがある。なぜそのようなことをするのだろうか？ ある作業を理由にして、現在自分に割り当てられた別の作業を避けるためだ。「A」という作業の進ちょく状況を聞くと、「B」の仕事があるため忙しくて作業ができなかった、と答えるのだ。

　このような「八方美人」や「逃亡者」のタイプは、どうすれば生産力のあるチームメンバーに変えられるだろうか？ 解決策はどちらの場合もほぼ同じだ。集中力を付けさせ、管理できる作業と目標を明確にする必要性を説き、きちんとした形で作業を完了できるようエネルギーを向けさせるのだ。最初は、飲み過ぎの客に対するバーテンダーと同じ対応を取ることだ。「中断させ」て、割り当てを減らし、残りの作業で実際に進展があるかどうかを定期的に確認する。「逃亡者」への対応は、もっと思い切った処置を取り、一度に1つずつ作業を減らしていく必要があるかもしれない。こうすれば、作業に集中できるようになるし、逃げられなくなる。

　ではここで、優れたテストチームの特性に話を戻そう。

◎ 継続性を維持するチーム

　短時間で成功を収められるチームを作るのは難しいかもしれない。人材確保、教育、技術の変化に合わせた再教育、計画、そしてプロジェクトの目標や要件の変化に合わせた計画の見直しが必要になる。長期にわたって繰り返し成功できるチームを編成することはさらに難しい。チームのメンバーは年を取り、チーム内での役割も代わり、スキル、経験、そして記憶と一緒に退職することもある。

　チームは、どうすれば長期にわたって成功し続けられるのだろうか？ それには、どのような変化が起こっても継続性を保つことだ。便利なスポーツの例え話がもう1つある。大リーグで最も有名なチームはヤンキースだ。なぜだろう？ それは、「球界の王者」と呼ばれるほど過去80年間の優勝回数が多いためだ。彼らが成功する要素は何だろうか？ そこには、優勝することに血眼のオーナーたち、優秀な監督たち、スター選手を次々に発掘し、育てる人事体制がある。

　以下のように、これらと同じ資質がソフトウェアの開発やテストチームの成功にも役立つ。

　人材：成功するチームを編成するには、単に「スター」を集めるのではなく、補完し合える多様なスキル、経験、そして視野を持つ人材を集めてチームを編成することが最善であることはすでに説明した。さらに、チームが常に将来に備えるようにすることも重要だ。先のスポーツの例え話を続けると、20世紀半ばにヤンキースが圧倒的に優位な立場にあったのは、チームの主力選手のキャリアがうまく重なったためだ。チームの主力選手が下り坂に差し掛かるころには、コーチがすでに次の偉大な選手を育てていたのだ。1920年代前半にはベーブ・ルースがチームを引っ張り、20年代後半のRuthのキャリアの終盤にはルー・ゲーリッグが台頭してきた。1930年代半ばになると、不調のルー・ゲーリッグを若いジョー・ディマジオが助けた。そして、1950年代初めになると、ディマジオのキャリアの最後の年にミッキー・マントルがセンターの代役を務めた。これらの偉大な選手のキャリアが重なったことが、ほかの選手が入れ替わる中でのチームの確固たる成功を助けた。

　ソフトウェアテストチームも、これと同じように将来に向けた計画を立てる必要がある。チームのマネージャや年長者は、常に次の（重なる）世代の主力メンバーを育てなくてはならない。これで、チームの主力メンバーが（疾病や出産などで）短期的に抜けたり、退職するようなことがあっても、確実にうまく運営し続けられるようになる。このオーバーラップアプローチを取れば、チームメンバーが複数の能力を持ち、誰1人として絶対に「単一障害点」にならぬようになる。筆者はここ数年、「やり方を知っている唯一の人間が病欠を取っている」ために特定の作業が進まない例を何度も見てきた。

　組織の記録：チームの継続性を維持するにはスタッフの配備だけでは不十分で、スタッフが作業で利用するハードウェア、ソフトウェア、そして資料も必要になってくる。テストネットワークの構築、テストツールの開発、そしてその使い方を説明した書類の作成も重要な作業だ。見落とされがちで、あまり面白くない作業が、これらの資料、特にマニュアルの保守だ。しかし、この作業に時間と労力を掛けることで、チームが継続性を維持できるようになる。この書類が、チームとしての組織の記録を示すのだ。人が入れ替わっても、チームの役割、作業、およびツールを正確に説明した最新の書類があれば、メンバーが「何世代」にもわたってチームを成功させ続けるのに役立つ。
　
　 次項では、効果的な管理と管理者の重要性について説明する（会社に対する献身的な帰属意識を確立する方法については本稿の内容の範囲外となる）。

◎ チームにおけるマネージャと管理の重要性

　筆者は本項のタイトルを慎重に選んだ。チームが成功するにはチームのマネージャの業績も非常に重要だが、マネージャを含むチーム全員の管理手法はもっと重要なのだ。

　チームが成功するには、マネージャが複数の作業を進める必要がある。予算を管理し、トレーニングの準備を行い、（ハードウェアなどの）物理的な作業環境の設定も管理しなくてはならない。しかし、マネージャにはもっと重要な仕事がある。

　チームの枠組みの中で自主管理を可能にする：一部には、融通の利かないトップダウン型の管理方法を取る人がいる。彼らは、すべての意思決定を集中管理し続け、チームメンバー全員の日々の行動まで指図する。時にはこのような管理が必要な場合もあるが（非常に若く、未熟なエンジニアだけでチームが構成されている場合など）、これはかなり非効率的なモデルだ。マネージャの明確な許可がないと誰も行動に移れないのでは、マネージャが不在だったり、マネージャの明確な指示を待っている間は、チームがまひしてしまう。「speed kills」（スピードは万能）という表現は、チームメンバーがマネージャの指示を待つことに慣れているため、早急に問題に対処する必要がありながらそうできなくするという負の意味にも取れる。

　バスケットボールを見ていると、選手がリバウンドを競い合ってボールを奪取し、すぐにパスを出すか、ドリブルに入って相手チームのすきを突く代わりに、動作を止めて監督に次の指示を仰ぐ光景を恐らく見たことがあるかと思う。相手チームはその間に態勢を立て直せる場合があり、これで相手より優位に立つチャンスが失われてしまう。マネージャとしては、明確なガイドラインのフレームワークと原則をチームに示すことで、同様のまひ状態を回避することができる。意思決定ポイントで素早く対応できるよう、メンバーには自主管理を奨励するのだ。そのためには、効率的なソフトウェアテスト計画を立てることだ。だが、中には暗に物事がうまく進むと仮定する人もいる。

　しかし周知のとおり、ソフトウェアをテストしているときは失敗することが多い。マネージャとしては、問題の発生に対処するため、どのテストにも不測事態対応計画が用意されていることを確認すべきだ。つまり、チームメンバーが個々にイニシアティブを取れるよう、柔軟な計画を用意したい。「計画には行動を伴わせる」という格言は、ソフトウェアのテストにピタリと当てはまる。

　「未完の課題」を用意する：管理で最も重要な作業の1つが、チームの作業の方向性を定めることだ。この点に関して、筆者には米国大統領のJohn F. Kennedyが1960年の選挙戦で語ったお気に入りの言葉がある。Kennedyは、国のために「未完の課題を示す」ことが大統領の責務だと語った。ソフトウェアテストチームにとっては、未完の課題には、テストの自動化や、新しい技術もしくはプラットフォーム（J2EEなど）の修得など、複数の行動が含まれる。ここで重要なことは、マネージャがチームの現在のプロジェクトや作業のための短期の戦略的リーダーシップを発揮すると同時に、チームの将来に向けた長期の戦略的なビジョンも示すことだ。

◆

　本稿はまず、「ソフトウェアテストで成功するチームと失敗するチームがあるのはなぜだろう？」という疑問から入ってきた。単純な答えや月並みの決まり文句以外に、本稿では、チームが自分たちの役割を明確にしてチーム内およびチーム間の関係を確立していく流れ、マネージャがチームに欲しがる人物のタイプ、プロジェクトマネージャやチームのメンバーがチームを成功させるべく行う管理の役割について説明してきた。

　結局のところ、何がチームを成功させるのか、という問いに対する簡単な答えはない。個人と同じように、これも環境、特性、そしてリーダーシップの組み合わせになる。もちろん、努力も欠かせない。

<筆者について>　Len DiMaggioはIBM Rationalのソフトウェア品質保証エンジニア／マネージャ。Rational以前には、BBN、GTE、およびGenuityでソフトウェアテストチームを率いてきた。STQE、Software Development、Dr. Dobbs Journal、およびQAI Journalにソフトウェアテストに関する記事を書いている。

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

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）