テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo

ソフトウェアテスト分野で国内最大のシンポジウム「JaSST'15 Tokyo」が2月20日、21日の2日間、東洋大学で開催されました。

シンポジウムの最後を飾るクロージングパネルでは、基調講演に登壇したマイケル・ボルトン（Michael Bolton）氏、チェンジビジョンの平鍋健児氏、ACCESSの松木晋祐氏、サイバーコネクトツーの八田博和氏が登壇。

（本記事は「テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（前編） JaSST'15 Tokyo」の続きです）

品質は神格化されて怖いもの？

松木氏　さっき平鍋さんの話を聞いて思ったのですが、QAと開発者が距離を置く理由って、たぶん品質を神格化しているからだと思うんです。

ソフトウェアエンジニアは、品質というよく分からないものを尊敬しつつ怖がっている。それを一見分かっている風のテストエンジニアは、品質の神様を祭る司祭っぽくなっていると思うんです。でもそうじゃなくて、品質を神様のようにせず、開発チームにとって分かりやすく表現してあげる。例えば品質属性の中から何が大事かをみんなで検討して、それをコードに当てはめて定量的になるべく早くフィードバックできるシステムを作るようにする。あなたのコードは何点でしたとか、点数で返すとか。

すると、ああそうか、点数をよくするにはどうすればいいか考えてくれるとか。

平鍋　僕が大きな会社とお付き合いしていたときに「出荷判定会議」というのがあって、それはすごく怖かったですね。品質は有無をいわさずつねに最高でなければならないというのがあって、すごく怖いと思います。

野中氏（モデレータ）　ここまでの議論をボルトンさんにも通訳を通じて聞いていただいているので、開発とテストエンジニアとの距離を縮めるという点に関してコメントをもらいたいと思います。

質の高い製品を作るのは誰もが持つ共通の目的だ

ボルトン氏　キャンディの話はいいお話だと思いました。私もキャンディは好きです（笑）。ただ、私がもし、プログラマにとって大事な価値のある人であるなら、プログラマの方からやってくるはずで、そこでキャンディはいらなくなるでしょう。

こちらに意味がある話がなければ、コミュニケーションそのものの意味がありません。伝えるべき大事な事柄があり、それを伝える技術があれば、相手は向こうからやってきます。

また品質の質というものを定量的に表すのも少々抵抗があります。（そのアイデアは）10点満点で3点です。数字とは数字そのものではなく、なにか別のものを表すためのものだからです。

おそらくこれまでのアイデアは、非常に厳しい対話を回避するための試行、努力なのだろうと思います。でもそれ以外の視点もあります。

そうすると、難しい話し合いであってもいまよりうまく対応できるようになりますし、厳しい対話を行うことの価値も見えてくる。初期のアジャイル、特にXPに関して触れると、ソフトウェアの開発に人が関わるときに重要な属性は勇気、勇気です。

自身を表現するスキルが明確にある、それを表現することは勇気があることで、勇気があることによって前に進むことができる。

ターンアラウンドタイムを短くする、というのは誰もが口にすることです。それは、プログラマはコードを生成することに責任を持っているのか、あるいはちゃんとうまいくいくコードを生成することに責任を持っているのかを考えると分かります。もしうまくいかないコードでもいいのであれば、ターンアラウンドタイムは長くてもかまいませんから。

この点についてはJeffrey Fredrick氏が非常によい指摘をしていて、それはプログラムは「パーフェクトなコード」を期待されているのではない。しかし「このコードは機能することを確認（チェック）している」ということは期待されている。

テストとチェックの違いを分けて考えるのは大事なことです。プログラマがツールを使ってコードをチェックする、そしてすぐフィードバックを得るというのは大事です。しかしプログラマにこうしなさい、ああしなさい、というのは皆さんの仕事では無いと思います。

私は実はQuality Assuarance（品質保証）という名前を（私たちの仕事の名前として）使うことは反対です。

質の高い製品を作る、確約するというのはプロジェクトの誰もが持つ共通の目的です。テスターはコードを変更する権利はなありません。スケジュールを変更することも、予算をコントロールすることもできない。スコープも変えられないし、プログラマの採用もできずクビにもできません。リリースするかどうかを決定する権限もありません。

こうしたことが1つもできないなかで、品質を確約することなどできるのでしょうか？

品質について決定権を持つのは開発のマネージャだ

ボルトン氏　製品について、品質について決定権を持つのは誰かと言えば、開発者のマネージャだと私は言いたい。だから開発者やそのマネージャこそQAなんです。

ではテスターの役割はなにかというと、彼らを支援して（開発中の）製品の状態を分かるようにすること。

ですからプログラマとテスターの距離を縮めるのは大賛成です。まず近い場所にいなさいと。違うフロアだから無理、という会社がもしあれば、フロアを変更して同じフロアにしなさいと言います。

コミュニケーションをよくするには物理的に近いところに居ることが重要です。ソフトウェアの開発は、人と人との関係によって行われるからです。

そしてすべてのプロジェクトには納期のプレッシャーがあります。たぶんそれをいちばん感じているのはゲーム業界でしょう。つねに競争が厳しく、またクリスマスシーズンを逃すわけにはいかないからです。

しかし私たちが開発しているのは、これまで誰も作ったことがないものです。だから不確定な要素がある。そして納期へのプレッシャーの中でミスもします。

だから、そういったことが起きるのだということで、できるだけ早い段階でミスを認識しなければならないのです。

そして私はまさにいまここで（長い時間話しすぎたので）締め切りのプレッシャーを受けています（笑）

QAがゲームのモニターをコーディネイトする

野中氏（モデレータ）　さて、残り時間は約23分となりました。これから先を考えたときにソフトウェアのテストにはどういう価値が求められるのでしょうか。

先ほど八田さんは、品質が高くても面白くなかったらだめだ、という話をされました。これは、ややもすればIT業界の立場からすると、テスターが面白い面白くないということを示せるのか、という思いもあります。

八田氏　ゲームの場合、発売日があらかじめ決まっていることがあるので、その納期に対してぎりぎりまでいかに面白い要素を詰め込んでいくかが求められます。ですので、いかに短期間でデバッグするか、も求められています。

例えばプランナー（注：ゲームデザイナーのこと。以下同じ）は実装の締め切りぎりぎりまで、面白くするための要素を入れ込もうとするんです。ですので、出来上がった時点でソフトウェアをモニタしても修正が間に合わないので、できるだけ早期からモニタをしています。

社内で、他のプロジェクトのスタッフや、総務、人事など開発部以外のスタッフにゲームをプレイしてもらい、感想をモニタ表に書いてもらいます。プランナーが想定したような行動をプレイヤーがしてくれているかがメインの調査ですね。もしうまくいっていなければすぐに修正して、できるだけプレイヤーが楽しめるようにします。

平鍋氏　モニタ表というのは、必ずしもQAチームの人が書くのではなく、いろんな人が書くと。

八田氏　QAチームはもうゲームに触ってしまっているので、それをカバーするために例えばモニタ会をするときに「こういう人にモニタしてほしい」というのをQAチームが提案することがあります。例えば某プロジェクトのプランナーに見てほしいとか、某プロジェクトのデザイナー（注：アーティスト）にみてほしいとか、それで幅広い感想を集めています。

平鍋氏　この話がすごく面白く感じるのは、伝統的なQAでは欠陥がないことのみを見るのに対して、面白いかどうかを見るというのが入っている。QAはこういうところまで見るのかと。

野中氏（モデレータ）　会場の参加者の方で、うちもそうだ、という人はいますか？

会場　ミッションクリティカルなソフトウェアで人が死ぬやつは、使いやすさに感情的な面も配慮してます。で、質問させてください。そもそもテストと開発は分けたいんですか？ 分かれているのが前提で世間は進んでいるのか。そもそもなんで分けているのでしょう？

開発チームの外部から品質保証をする場合もある

野中氏（モデレータ）　それは重要な質問だと思います。

ボルトン氏　繰り返しになりますが、私は別れているべきではないと思います。

松木氏　（開発者とテスターに）ロールを分けるべきかどうか、私の個人的な経験では、テストは開発チームに任せるべき、です。そして、開発者の中でテスターのマインドを持つ人をテスターと呼ぶのです。ただ、これはたぶん作る製品によるところがあると思いますが。

で、開発者とテスターが近いところに居るべきというのは大賛成です。ただ、例外的にそれではいけない場合があるときもあります。それは、チームが目指すものと、組織が目指すものが違う場合です。

プロダクトの開発をするチームは、プロダクトを出荷したい。しかし会社のビジョンとして社会的責任がある場合は、チームの外部から製品が社会的責任に見合うものかどうかをチェックしたいと。その場合はチームの外部に品質保証の担当を置くのは正しいと思います。そういうビジョンの表現の仕方というのはあると思います。

日本の会社ではこういう形になっているところは多いと思います。会社が、開発チームで作ったものの社会的責任をチェックする。その場合は分けた方が効率的だと思います。

ボルトン氏　その場合、QAチームとマネジメントチームの違いはどこにあるのでしょう？

松木氏　組織として表現したいビジョンはマネジメントチームから出し、QAチームはそれを受けて、製品がそうなっているかを検証する。QAがチェックする部隊だと思います。

野中氏（モデレータ）　いろいろな議論がありました。実はボルトンさんがこのあと飛行機に乗らなくてはなりません。ここでパネルディスカッションを締めさせていただきます。ありがとうございました。

JaSST'15 Tokyo

• クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（前編）。JaSST'15 Tokyo
• クックパッド、ミクシィ、グリー、ネクストの品質管理マネージャが本音で語る。ソフトウェアテストの課題とこれからの可能性（後編）。JaSST'15 Tokyo
• テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（前編） JaSST'15 Tokyo
• テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo

JaSST関連記事

• テストエンジニアのモチベーションを上げるにはどうすればいいか （前編） JaSST'14 Tokyo
• テストエンジニアのモチベーションを上げるにはどうすればいいか （後編） JaSST'14 Tokyo
• マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo
• マイクロソフトでは「開発プロセスのすべてにテスターが関与している」 JaSST'12 Tokyo
• ソフトウェアテストの近未来を話そう（前編）～テストと開発の融合が必要 JaSST'12 Tokyo
• ソフトウェアテストの近未来を話そう（後編）～テストプロセスには魂が必要だ JaSST'12 Tokyo
• ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo
• ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo