開発チームと品質保証チームは、どちらも製品やソリューションを、よりよい品質でお客様に届けるために必要不可欠なチームで、共通のゴールにたどり着くためには協力が必要です。ですが、それぞれのチームの背景、思想、文化、知識、様々な要因によりうまくかみ合わない、チームが対立するという経験をしたことはありませんか？
私はあります。
これは、過去に私が参加した、とあるプロジェクトの話です。
開発を担当するのは海外の開発ベンダーで、開発されたソフトウェアを受け入れる部門はソフトウェアに関する知識が乏しい。そのため、私が所属する部署が製品としてリリースする前に、ソフトウェアの品質を確認することになりました。
私が参画したころは、すでにいくつかのお客様先にインストールがされていて、現場ではトラブルが起きていました。発生した問題を開発チームに伝えると…
「Ah, it’s a known issue!（知ってた）」
「It will be fixed in the next release, so it is not a problem.（次で直すから、問題なし）」
という回答。入ってすぐにこの光景を目の当たりにして、私は愕然としました。
今思えば、このプロジェクトに散見していた課題は、JSTQB® Advanced Levelテストマネージャのシラバスで語られる典型的な課題そのものでした。機能していない欠陥マネジメントプロセス、そして何より深刻だったのは、主要なステークホルダー（開発チーム）とのコミュニケーション不全です。
では、この教科書通りの「詰んだ状況」を、私たちはどうやって乗り越えたのか。
当時はただがむしゃらに、目の前の課題に対して地道で人間的なアプローチを繰り返すだけでした。しかし、今こうして振り返ってみると、その一つひとつの行動が、JSTQB® Advanced Levelテストマネージャで語られる概念に見事に当てはまることが分かったのです。
この記事では、過去の出来事をJSTQB® Advanced Levelテストマネージャで学ぶ概念と対比させながら振り返っていきたいと思います。私の経験が、皆さんがJSTQB® Advanced Levelテストマネージャの知識を、実践で活用するための一助となれば幸いです。
開発チームとのコミュニケーション不全
「話せば分かる」と最初は楽観視していました。それまでの私は品質保証側ではなく開発側の立場でしか仕事をしたことがなかったので、自分の経験をベースに考えていたのです。自分は品質保証チームのいうことに対して、多少の面倒くささは感じましたが、品質を上げるためには仕方がないと思って対応をしてきました。きっと他の開発者も同じように考えてくれるだろうと安易に考えていたのです。
そこでまずは、理解を深める場として、定例のミーティングを実施し、こちらのソフトウェアの仕様に対する知識を深めると同時に、こちらが課題だと感じている点を理解してもらおうとしました。ところが、このミーティングは当初の目的をなかなか果たせませんでした。
現状を把握するために、技術資料やソースコード、バグ管理システムへのアクセスを依頼しても、なかなか情報を開示してくれません。提供してもらった情報を基に、問題の深堀をして、根本的な課題を解決したかったのですが、できないので、表面的な問題についてばかり話をする羽目になりました。
そんなことばかり話すから、開発チームからは「次のリリースで直すのに何が不満なんだ？」と不満が続出。
お互いの主張がぶつかり合い、折り合いがつかず、またこちらも言葉の壁のせいで、言い負かされて、うまく言いたいことも伝えられません。あっという間に予定時間を超え、2時間3時間ひたすら会話が平行線をたどって決着がつかないこともありました。
こんな状況で、顧客からきているクレームの対処をこれからどうしていけばいいのか、どうやっていいものを作っていけばいいのか、途方にくれました。
コミュニケーションの改善
この試行錯誤は、まさにテストマネージャに求められるスキルの実践でした。今振り返ると、私たちが無意識に行っていた工夫は、JSTQB® Advanced Levelテストマネージャで学ぶ重要な概念と見事に一致していたのです。
JSTQB® Advanced Levelテストマネージャのシラバス「7.6 コミュニケーション」で語られているように、とにかく「メッセージが受け入れられるための適切な土壌を作るのに必要な説明は何であるかということを、理解することが重要」です。
彼らに響く言葉は何なのか、どういう振る舞いをすれば話を聞いてもらえるようになるのか。そこでまずは、相手が自分の話を聞いてあげてもいい、お互いのためになると思ってもらうためにはどうしたらよいかを、今までのやり取りを基に考えるようになりました。
何故、こちらの伝えたい言葉が伝わらないのか？
JSTQB® Advanced Levelテストマネージャのシラバス「2.8 分散テスト、アウトソーステスト、およびインソーステスト」に「地域、時間帯、文化、言語の違いが、コミュニケーションの問題と、期待との差異による問題を引き起こしやすくする」という記述があります。まさに、私たちが直面していた課題そのものでした。そこで、こちらから話を伝える際に、いくつか工夫をして、「メッセージが受け入れられるための適切な土壌」を作るようにしました。
雑談で距離を縮める
直接会える機会があれば、積極的に雑談をして話すチャンスを増やしました。人となりを知ることで、話しやすい関係を作るように試みたのです。昔彼らの国に父が駐在していたことがあったので、その話をすると、向こうの開発チームのマネージャーの住んでいる街だったようで、そこから徐々に色々な話ができるようになりました。
対等なパートナーとして意見を伝える
また、これはよく外国の方と話していると感じるのですが、彼らは自分の意見もはっきり言いますが、こちらの意見も求めてきます。日本人はあいまいに「いいと思う」と言ってしまいがちかと思いますが、議論に値する相手だと思ってもらうためにも、自分の意見を理由と共に伝えるようにしました。向こうの社長にUIについて意見を求められた時も、「ここのこの部分が直感的ではないのでユーザーには使いにくいと思う」とはっきり言い、世界共通でわかりやすいUIとは何かという議論を、スタバで繰り広げたこともあります。
伝え方を工夫する
とにかく話せと言われても、うまく伝えられないと話す気持ちも萎えてしまいますよね。そんな時は伝わりやすい言葉を選んで、伝えるようにしました。例えば、彼らがよく使う言葉に言い換えたり、時にはあらかじめ図を用意して説明をしたり。会議中にうまく口頭で答えられないことはいったん持ち帰り、話したい内容を整理してからメールで補足をするようにしたのです。分からないことは自分の言葉で言い換えて正しく理解できているか都度確認をして、相互の理解を深めることを意識しました。
会議は効率よく
さらには、会議の進め方も、改善をしていきました。
時差がある分をうまく有効活用し、会議の前日までに議論したいアジェンダを送付することで、翌朝には一次回答がもらえている状態になり、会議では合意をするだけか、細かい部分のずれの調整のみで済むようになりました。
大小合わせて10以上の議題があっても、会議の時間が1時間を超えるようなケースはほとんどなくなりました。
リスクベースドテストのアプローチを活用する
人って納得できないことはやりたくないですよね。何故そんなことを聞くのかわからない質問にも答えたくないという気持ちが働くのは当然です。ですから、質問や依頼をする際には、背景や理由を説明するようにしました。
例えば、「開発側では軽微なバグだと思われているような内容でも、日本のプロジェクトでは非常によくお客様が目にする機能なので問い合わせが相次いでいる。このままでは、重要顧客の信頼を損ねるので対応をしてください」というような形です。
なぜ必要なのかが分かると彼らも、柔軟に考えを変えてくれるようになりました。「そういうことなら、こちらの問題の方を優先度を上げて確認してみるよ」と、前向きに問題に向き合ってくれるようになった瞬間は、今でも忘れられません。
この「なぜ重要か」を伝える行為は、JSTQB® Advanced Levelテストマネージャのシラバス「2.3.1 リスクベースドテスト」のアプローチそのものです。テストマネージャは、単に欠陥を報告するだけでなく、「その欠陥がビジネスや顧客に与えるリスクの大きさ」を評価し、ステークホルダーに理解可能な言葉で伝える責任があります。私たちは、開発チームにこの「ビジネスリスク」を共有することで、初めて修正の優先順位について同じテーブルで議論できるようになったのです。
ステークホルダー間の利害を調整する
相手の意見とこちらの意見がぶつかってしまう時には、自分の意見を押し通す前に、まず相手の考えをきちんと聞くことから始めます。そのうえで、もともとの要求のプロジェクトへの影響度を再確認し、プロジェクトの成功を大きくするためには、何をどう優先して対応していくべきか議論をするようにしたのです。
この時、自分たちの意見が一方的な要求にならないように、気を付けました。私たちは同じゴールを目指す仲間で、敵ではないのですから。
これは、JSTQB® Advanced Levelテストマネージャで重要視されるステークホルダーマネジメントの一環です。JSTQB® Advanced Levelテストマネージャのシラバス「2.2.1 テストステークホルダについて」には「ステークホルダとテストとの関係の本質、およびテストチームがステークホルダのニーズに応える方法について理解する必要がある。」とありますが、そのためにテストマネージャは、「7.6 コミュニケーション」に記載されたような、開発、ビジネス、運用など、異なる目的を持つステークホルダー間の利害を調整し、プロジェクト全体の成功という共通ゴールに向かって合意形成を導く、高度なピープルスキルが求められます。
気持ちは伝わる
こうした相手を尊重した動きは、少しずつではありますが実を結んでいきます。尊重には尊重を返してくれるようになり、こちらが根気強く訴えていた、開発側での品質の作りこみが開始されるようになりました。私たちの対話は、単に目の前のバグを修正させるだけでなく、彼らの組織構造そのものを変え、専門の品質保証チームを設立させるという、大きな変化のきっかけになったのです。
この品質保証チームの設立は、単なる組織変更以上の意味がありました。テスト組織の成熟度を測るモデルであるTMMi（Test Maturity Model integration）に照らし合わせれば、場当たり的なテスト（レベル1）から、組織として管理されたテストプロセス（レベル2以上）へと移行する、非常に大きな一歩だったのです。
テストのモニタリングとコントロールを続ける
こうして、お互いを信頼できるパートナーとして認め合うほど、2つのチームの信頼関係はかなり強固なものとなったのです。だからこそ、私たちは「次なる問題」に、チームとして立ち向かうことができました。
導入してくれる顧客が増えてくると、関わってくる人も増え、想定していなかった使われ方により新たな問題が現場で発生することが増えます。オペレーターが設定機能をうまく使いこなせず、誤った設定をデバイスに送ってしまい、デバイスが全く動作をしなくなることがあったり、フィールドに設置してみたら周囲の電波環境の影響かうまく通信が出来なかったり、などなど。
ラボでテストをしている人たちの想定している状況とは異なる何かがフィールドにはあったのですが、ベンダーの開発チームや品質保証チームにはフィールドでの使われ方の情報が伝わりきらないため、テストでは検出できず、問題が流出してしまうという現象が続きました。
そこで、顧客が望む運用方法や、オペレーターの設置フェーズのプロセスについてを、オペレーション担当からヒアリングし、インシデントの傾向を分析することで、設置フェーズ、運用フェーズそれぞれで「できなければいけないこと」の観点を抽出し、受け入れテストのブラッシュアップを図りました。
ベンダー側に品質保証チームが設立されるまでは、受け入れテストで開発チームのテストの妥当性を再確認する必要もあったため、ベンダーで実施しているテストとオーバーラップするテストが多くありました。これらを半分に減らし、その分ヒアリングや分析から得られた観点を基に、シナリオテストや組み合わせテストを追加したのです。
この対応により、今まで見逃されていた、設定の画面での操作ミスで発生するバグや、機能追加により作りこまれてしまったけれど特定条件でしか発見できないデグレードも、受け入れテストの段階で検出できるようになってきました。
この活動は、テスト計画が一度作って終わりではないことを示しています。JSTQB® Advanced Levelテストマネージャのシラバス「1.2.2 テストのモニタリングとコントロール」で学ぶテストのモニタリングとコントロールの一環として、プロジェクトから得られた新たな情報（今回の場合はフィールドでの利用状況という新たなリスク情報）を元に、テスト戦略を動的に見直すことが求められます。これもテストマネージャの重要な役割です。
まとめ
この記事で見てきたように、私たちの旅は、コミュニケーションが崩壊したチームという厳しい状況から始まりました。その分厚い壁を壊したのは、魔法のような特効薬ではなく、「対話」と「尊重」という地道な積み重ねでした。
そして最も重要なのは、それらの実践の一つひとつが、JSTQB® Advanced Levelテストマネージャで語られる「リスクベースドテスト」や「ステークホルダーマネジメント」といった理論と、後から見事に結びついていたという事実です。
この経験から得た学びは、JSTQB® Advanced Levelテストマネージャの知識によって、より普遍的な原則へと昇華されました。
- 人は、自分を尊重してくれる相手を、信頼する。（これは「コミュニケーション」の核心です）
- 背景（ビジネスリスク）を理解すれば、相手は自ら動いてくれる。（これが「リスクベースドテスト」の実践です）
- そして、その全ての土台となるのが、諦めない「対話」です。（これこそ「ステークホルダーマネジメント」そのものです）
JSTQB® Advanced Levelテストマネージャの知識は、資格取得のためだけの暗記項目ではありません。それは、複雑で困難な現場で人間関係の課題を解決し、チームを前に進めるための、強力な「思考のフレームワーク」なのです。
もしあなたがチームの壁に悩んでいるのなら、ぜひその知識を武器に、隣にいる仲間との「対話」から始めてみてください。きっと、あなたのチームも「対立」から「共創」へと変わるはずです。
