テストエンジニアとデベロッパーとの幸せな関係はどう変化していくのか（後編）

前編はこちら

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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