年の瀬ベリサーブ座談会： プラスとマイナスの両面でリスクを捉えれば、テストの必然性が自（おの）ずと見えてくる（後編）

（前編はこちら）

須原：先ほど松木さんが話していた、作ったものへの不安の解消という点についてですが、不安とは別の言葉で「リスク」とも言えます。今こんな研究をやっているので、少し画面をお見せしますね。

これは、テストが進むことによって、受け入れたリスク、取ったリスク、残っているリスクを表現したグラフです。後はリスク以外にも、元のプロダクトが実現したい価値も表現しています。

紺色の部分が価値です。例えば、実施中のプロジェクトを世の中に出すかどうかを判断する材料として、この価値を時系列的にモニタリングする仕組みを用意しています。

先ほどの話に戻すと、こういうものを見つつ、AIがテストした結果やリスクをフィードバックして、不安がない形で判断をする。これは人間がやることになると思っています。

大西：例えば、テスト戦略を立てて、Playable!Mobileを使って、こういうテストケースを作ることになりました。その後にこういったものを活用するということですか？

須原：そうです。

松木：テスト戦略は、リスクの総量をどう取りにいくかという話。今、われわれはリスクの総量を最大でこのくらい見積もりますというのがテスト戦略で、それをどういう方法で識別し、どの時期にどんなアプローチで進めるのかというのがテストの基本設計。そのアプローチに従って、この値とこの値を組み合わせれば、こういうテストできますよね、この領域カバーできますよね、など細かくやっていくのがテスト詳細設計です。

大西：プロジェクトによって戦略も変わってくるじゃないですか。自動車みたいに、もうリリース時期が決まっているのだけれど、やらなきゃいけない領域も決まっている。そこに対してカバレッジを100％満たさなくてはいけないものは、最大リスクをどうつぶし込んでいくかが重要。一方、ゲームやモバイルアプリみたいに、早くリリースしないと価値がなくなるものもあります。

須原：旬があるサービスや商品って、価値が日々低減していくのですよね。低減していく中で、どのタイミングでリスクを受容して、この価値を受け取るかみたいなところがリリース判断になるのかなと思っています。

何が言いたかったかというと、テストの裏側にはプロダクトの価値があるのに、それを見ずに物事を判断していることが結構多いです。だから、価値を受容するためのリリース判断の要素として、われわれのテスト作業の再定義ができればいいなと思います。

松木：価値の定義に関して、G.M.ワインバーグによると、一番はユーザーにとっての価値ですね。ワインバーグの品質の定義は非常に有名で、品質とは何ですかと聞くと、7、8割ぐらいの人が「誰かにとっての価値だよ」とワインバーグを引用します。ただ、それは半分に過ぎず、ワインバーグはきちんと「品質は誰かにとっての価値である」「価値とは、その課題が解決するならユーザーは喜んで対価を払うものである」と言っています。

大西：大事なところは「喜んで」という点。対価を払うところはISO9000で担保されますから。

松木：そう。喜ばれずに嫌々対価を払われても価値ではないでしょうし、たとえ喜んでもお金を払ってくれなければ価値とは言えないでしょう。両方がアンドで存在してこその価値なのですね。でも、JSTQBやISOも基本リスクベースですよね。アプローチは。

大西：リスクベースも当然必要でしょう。ただし、リスクベースドテストはリスクを足切りする理論ではないのですよ。優先順位を付けて、どれを先にやるべきかを考える。まさに価値に基づいて判断するという話だと理解しています。

須原：ここでリスクと言っているのは、本来発揮するべき価値が発揮できないことを示します。本当はそこを最初に取らなくてはいけないリスクなのです。当然、セキュリティリスクなどマイナス面のリスクもありますが、プラス面についても考えるべきだと思っています。

でも、リスクという言葉自体、やはりマイナスイメージがある。先ほどの「不安」もリスクに近いですよね。ここをどうやって表現するのかは考えどころだと感じています。

大西：ISTQBのFoundationレベルのシラバスでは、リスクとは、顕在化することによって悪影響が生じる潜在的な事象、ハザード、脅威または状況のことである、と定義しています。シラバスがさらに参照している規格のISO32000は、リスクを「目的に対する不確かさの影響」としています。

一方、トム・デマルコは、リスクとは「まだ起きていない問題であり、問題とはすでに現実に発生したリスクである」と整理しています。

須原：なるほど。ここでリスクについて話した意図は、ベリサーブという会社がこちらに向かうべきだと思っているからです。それに向けた方法論やツール、場合によっては教育などを将来的に提供できればと考えています。

大西：その他、このメンツだから何か突っ込んで話したいというテーマがあれば。

須原：正直ずっと悩んでいることがあって。それはMBTパターンです。われわれの作業は代替できるのか。というか、当社のテスト設計はMBTだけに成れるのか。

秋山さんやミッキー（鈴木三紀夫）さんなど業界のレジェンドが、これまでテストを機械的に作ることをトライしてきたと思うのですが、実現できなかったといったコメントを結構見るのですよね。私はまだできると思っているのですけれど、どこにその違いがあるのか正直分からなくて。ご意見ありますか？

松木：何をもってテストができたと判定するかだよね。それは良しあしだと思う。私は機能一覧であってもライナーモデルだと思うのですよ。ライナーモデルだと非常に粗い、雑なテストが出来上がりますよねというだけで、ライナーモデルが嫌だったら、フィーチャーを別のモデルに転換して少しずつ詳細度を上げていき、そのモデルに基づいてテストを作ればいい。だから、私はできる、できないというよりは、良しあしの話に過ぎないと思います。

須原：もう少し補足すると、最近秋山さんが言っていたのは、汎用（はんよう）的なテスト観点は存在しない。それを作っても意味がないみたいな。若手の人たちがそういうものを作ろうとするのだけれど、勧めないのだとおっしゃっていて、それに対して湯本さんも同意したのですよね。

大西：汎用（はんよう）的なテスト観点は何らかのレギュレーション、例えば法規とかに基づいてやらなければいけないというバックグラウンドがあれば、それは有効だと思います。

松木：後、ソフトウェアの作りに基づくテスト観点ですね。例えば、リストを見たら要素ゼロ個を確認しろと。これは、リストというものを扱っているソフトウェアであれば汎用（はんよう）的に使える。

大西：それって別に汎用（はんよう）的なテスト観点とか言わなくても、QFD（Quality Function Deployment：品質機能展開）もそうですし、FMEA（Failure Mode and Effect Analysis：故障モード影響解析）、あれがまさにそうだと思います。

松木：作りに関しては、多分作れるのではないかと思います。

大西：結局思うのですが、それができる人とできない人は明らかに分かれていて、自然言語であろうがモデリングであろうが、それを抽象度でできる人って、実は限られているのかもしれません。

松木：本当にそうですね。

須原：それってベリサーブでできるのかな。

大西：できるかできないかと言われると、AIがアシストできる領域がまさにそれでしょう。下手な人は自分が思っていることを言語化できません。ただ、頭の中にはきちんとノウハウが詰まっている。そこでAIが「あなたが言っていることはこう」とか、「あなたの頭の中身を絵にしたらこう」とかやって、モデリングしてくれるわけです。

須原：AIの助けは本当に重要で、それによってできるようになることはあると思います。最初の話に戻ると、希望は捨てないでいようかなと。

大西：私もいろいろと現場を見てきましたが、パターン化を自分でできる人間は組織全体の１割程度。もちろん、残りの９割が使い物にならないのではなくて、あくまでもテストアーキテクチャやテキストモデルについて語れる人の割合がそのくらいという話です。

ただ、実際あり得るのは、欧米ではテクニシャンとエンジニアは明らかに区別されています。テクニシャンは腕を持っていれば給料が上がるのですよね。多能工だから、例えばコピー機を1人で全部組み立てられたりする。一方のエンジニアは、コピー機そのものを設計したり、それをどう効率的に検査できるかを考えたりする人です。今後、テクニシャン的な業務はどんどんAIによってロボット化されていくでしょうから、当社としてはそういった人たちを別のステージに持っていかないとビジネスとしてはペイしません。

そのための武器になるものを須原さんのグループで一生懸命作っていると思っています。それを持たせてあげることによって、ただの村人が、ひょっとしたら騎士になれるかもしれない。そこにどうマジックをかけるかというのが、まさにAIのマジックかなと。

松木：AIがそこを助けてくれるのは、いい話かもしれないですね。

大西：ただし、われわれの中でテストエンジニアのスキルをきれいに分解し切れていない。それはやらなくては駄目でしょう。実際に現場でテストをやる人たちにとっての武器とは何か。昨日入社した素人が持つ武器と、玄人が持つ武器は違うわけですから。もっとも喫緊の課題は、武器を持っていない人に、有効な武器を持たせないといけないという点が挙げられます。

松木：GIHOZは割とそこを狙ったサービスです。お客さんがプロダクトに触れてから「これはいい！」と感じるまでの時間が短い。QFは長過ぎました。データを投入して、日々データが変わっていくのを見て喜ぶまでに最低2日くらいかかる。でも、GIHOZは3クリックで「いいね！」となる。それは武器として一つ挙げられますね。

今はTime to Value（TTV）をいかに短くするかが重要。皆、時間がないから。武器って、使ってみてすぐに、「これ、自分でも使えそう」と思っていただかないといけません。そういう意味で、フレンドリーさはとても大切ですね。

大西：次が最後の質問です。正月休みに入る読者も多いと思うので、その期間に読むことをお勧めしたい本を紹介してください。テストエンジニアに限らず、若手のビジネスパーソンに向けて。

松木：「にしさんの教え: 日本のテストコミュニティを作った男」は読んでおいた方がいいですね。それと「LEADING QUALITY」（Ronald Cummings-John＆Owais Peer著）は面白かった。

3冊目は「確率思考の戦略論 USJでも実証された数学マーケティングの力」（森岡毅＆今西聖貴著）。マーケティングの本で、バイブル的位置付け。ぜひ読んでほしい。

須原：ソフトウェア品質知識体系ガイド「SQuBOK」を。そもそもがリファレンス本なので、ここで参照されている本も次々と読み進めてもらいたいです。

大西：今日はリスクの話をしたので、私は「熊とワルツを－リスクを愉しむプロジェクト管理」（トム・デマルコ＆ティモシー・リスター著）を挙げておきましょうか。後は、同じくデマルコの「ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解」をお勧めしたいと思います。

古典だと、「デスマーチ ソフトウエア開発プロジェクトはなぜ混乱するのか」（エドワード・ヨードン著）、「人月の神話」（フレデリック・P・ブルックス Jr.著）でしょうか。

編集部：お三方、本日はどうもありがとうございました。

一同：皆さん、良いお年を！