大きくなりがちなデシジョンテーブルはどうすればいいか？
篠原新治氏（以下、篠原）：続きまして、次の質問にいきたいと思います。「畠山さんのパートでやったデシジョンテーブルで表現しようとしたことがあるのですが、どうしても条件が増えてテーブルが大きくなりすぎます。小さなデシジョンテーブルの組み合わせをやってもうまくいきません」という質問に対して多くの方から賛同をいただいています。畠山さん、この質問についてお願いできますか？
畠山塁氏（以下、畠山）：そうですね。すごくよくわかるなというのが思ったところです。たぶんこの方も非常に苦労されているのかなと思います。私自身も最初は本当に小さなものから練習しました。なのでいきなり大きなものはやはり難しいというのと、大きくなりすぎる場合はデシジョンテーブルの整理が本当に合っているのかというところもあると思います。
ほかには、その大きな中でも一部分をまずは表現して、あとは簡略化できるかみたいなところになると思います。そのあたりは『ソフトウェアテストの教科書』にも書いてあります。
篠原：お！ 宣伝をありがとうございます。
（一同笑）
石原一宏氏（以下、石原）：ここで宣伝来たか（笑）。
畠山：石原さんはいかがですか？
石原：デシジョンテーブルは倍々で大きくなるんですよね。Yes・Noが10個並んでいるだけで、2の10乗で1,024という巨大なテーブルになっちゃう。でも、環境条件が4パターンある場合、いきなり1,024が4分の1の250になったり、その半分の128にすることが可能なんです。
なのでレバレッジというか、「この条件はいったん脇にどけておいたほうがいいよね」という、勘所みたいなところがけっこうあるんですよ。環境条件はそういうところで、そこはゴソッと別紙にしてしまうとわりと1枚の紙に収まる。例えば環境条件の2の3乗の8通りを全部デシジョンテーブルにするかというと、8通りのうち普通に使うのは3通りなので、128通りのデシジョンテーブルを3枚くらい作っておくとだいたい収容パターンはいけるよねみたいな。
急にニッチな話になりますが、そういう分割するという発想は悪くないなと思っています。でもそこで大事なのは、環境条件が8通りあるけど、「8通りのうち、今回デシジョンテーブルにしたのは3通りだけで残りの5通りは今回は対象外だからね」とどこかに書いておくことです。
なにが言いたいのかというと、全部をデシジョンテーブルにすることを諦めたのであれば、「これはしています。これはしていません」と、したテーブルとしていないテーブルの両方を明確にしておく。特にテストでは、今回記述対象にしたところはここだけど、ここは対象外ですよというこの「対象外」をあとでわかるようにしておく。
完璧を目指さない。優先順位が高いところから潰していく。優先順位が高いところを選ぶということは、優先順位を落としたところから（不具合が）出てくるということなので、それがどれぐらいあるのかを明確にしておく。そうすると運悪く対象外から不具合が出た場合に「次からはそこも入れます」と言うだけでぜんぜん違ってくると思います。
そういう意味では「完璧なテストをお願いします。バルテスさんはテスト専門会社でしょ？」と言われたら、即座に「無理です」と言いますよ。天文学的な数字になるからできるわけがないんです。オンとオフのスイッチが10個なら1,024回ですが、オンとオフのスイッチが63個並んだら2の63乗で900京を超えますからね。京は京都の「京」ですよ。無理に決まっています。
だったらそれを何パターンにするのか？ という話ですが、実はしていないテストのほうが多いという話です。そこで大事なのは「ここはしていません」とあとでわかるようにしておくこと。デシジョンテーブルみたいな大きな数を扱う時にはそういう分け方はけっこうします。
蛇足ですが、1,024ぐらいのルールだったらわりと作っちゃいます（笑）。それは私の中では大きいほうに入りません。作るのは手間ですが、3日かけて作るとバグは絶対に出ないので。通信系や割り込み系は特にそれぐらいは3日ぐらい作っておいたほうがいいです。あとになって3ヶ月ぐらいの手戻りになる時もあるのでそこは天秤に掛けて、「ここはがんばって作っちゃえ！」とやると不具合が逆に減るという時はありました。すみません、ついしゃべり過ぎちゃいますね（笑）。こんな感じでよろしいでしょうか。
篠原：ありがとうございます。ふだんの教育セミナーでお話している中ですよね。ここはまだ入口の部分だと思いますが（笑）。みなさんNever・Mustというところに非常に共感をしてもらえてうれしく思います。デシジョンテーブル以外にもいろいろトライしながらご苦労されている部分が質問からも取れるかなと思っていました。
低品質のものができてしまった時は「たられば分析」をしてみる
篠原：あと2ついければと思っています。「教育のコツ」は先ほど石原さんからいろいろアドバイス・ヒントをいただきました。少し角度が違っておもしろいなと思った質問があって、「上流工程のひと手間で品質を上げられることは理解できましたが、品質の低いものができてしまった場合はどのように考えるべきでしょうか？」と来ていて、このあたりは石原さんが（笑）。
石原：品質が良くないものができたというのは、すごく良い学びの場だと思っています。もちろんお客さまに怒られるし、上司から怒られるし、ボーナスもマイナス査定になって良いことなしになるかもしれませんが、（品質が）低い原因はどこだろうと探すことは大事です。（原因が）「時間がなかったから」だとけっこうざっくりしていて、時間がないなりに、例えばベンダーさんに渡す仕様が曖昧だった。曖昧だったとしても「どこが曖昧だったんだろう」と考える。書いていなかったとしても最低限これをやるだけでも随分違う。
「書いていないけどここを意識しておいてね」と言うだけで随分違ってくる。品質が悪いところは「何の品質がどう悪かったんだろう」と考えておく。なぜなぜ分析とよく言います。（なぜなぜ分析も）もちろん大事なんですが、よくやるのは「たられば分析」。「もしこうやっていれば」「もしこうだったら良かったのに、品質はこんなに悪くなかったのに」と。ぜひこの「たられば」を。
ギャンブルでは「『たられば』はダメ」と言われますが、実は開発で失敗した時に「なにができていれば良かったんだろう」と考えるのはけっこう有効です。なので悪いんだとすれば、「もうちょっとNever系のところをレビューできていれば」とかですね。そういうところで失敗の原因を炙り出して共有しておくのは意外と有効です。
品質が悪いのには必ず原因があります。品質が悪いなりの原因を共有しておくことができれば、少なくとも次のプロジェクトの頭で、「前回は仕様を書く段階で文字の箇条書きばかりの仕様だったけれど、今度はちょっとデシジョンテーブルや数直線を図表にしてみてから考えようか」とか。そうするとテストケースが考えやすいから単体テストで異常系もけっこう押さえられるよねという話。
ほかには「単体テストが足りなかった」とかですね。「詳細設計が曖昧だった」と原因を考えられたら、じゃあなにができていればもうちょっとマシになったんだろう。完璧を目指すんじゃないんですよ。－30点であればこれをやったら＋5点ぐらい上昇するよねということをピックアップしていくことがけっこう大事かなと思っています。
具体的にと言ったら今からしゃべりたくなってきますけど（笑）。まずは「どうすればこれは防げたんだろうか」という「たられば」を少し考えてみるのもわりと良い方法かなと思っています。「なぜ」よりは効くと思いますね。すみません、こんな感じでいかがでしょう（笑）。
篠原：ありがとうございます。
バグを叩きに行くコツは多発地帯をメンバーに周知しておくこと
篠原：お時間的にはもう1つぐらい……。
司会者：そうですね。せっかく盛り上がっているのでもう1個いきましょうか（笑）。
篠原：もう1個いきますか。わかりました！ そうですね。ド直球と言いますか、すごい質問を1ついただいていまして（笑）。今日は上流工程のお話が中心だったのですが、私たちはブラックボックステストの段階からプロジェクトに入っていくことも非常にたくさんあります。
それに紐づく質問で「バグを叩きに行くコツはありますか？」というものですね。限られた時間の中、限られたリソースの中でいかにクリティカルなものを出し切るか。そのための考え方がなにかあるのか、エッセンスがほしいという質問だと思います。最後に石原さんと畠山さんからご回答をいただきたいと思います。
畠山：コツになるかはわかりませんが、基本的には期間と工数が限られているという制約の中でやることが多いので、私たちの言葉だと「なにができればOKか」というキーワードでやるのが多いですね。すべてをやろうとするとやはり期間も工数も足りないので、なにができればOKなのか優先度を付けてそこを徹底的に叩きに行きます。その中で、先ほどのMust・Neverの考え方を使ってやっていくのが多いかなと思います。
石原：テストは実は2種類あるんですよね。バグがないことを確認する品質保証型、普通に使う分には大丈夫ですよというテスト。時間がない時にはまずこれです。普通に使うシナリオラインの中でバグがないことを発見する。もう1つは、バグをできるだけ時間に余裕がある時にゆすり出していくテストです。
それもやはり優先順位を付けなければいけません。もし起こったら大変なダメージになるバグはなんだろうと考えて、そのバグが誘発しそうな条件の組み合わせはどれだろうという話ですね。だから正常系できちんとできることをテストする。これが起こったら絶対にマズいよねというリスクが高いところを潰していく。
そうすると、100パーセントバグがゼロにはならないけれども、クリティカルなバグはけっこう潰せていますよね、というところまで持っていけるというのがわりと大事なところですね。
あとはバグを叩きに行くコツ。そういう意味で言えば「たくさんのバグを出すにはどうすればいいんですか」という質問なのかもしれませんね。だとすると、先ほども言いましたが、過去そのドメイン・そのソフトウェアにおいてどんな不具合が多かったのか、バグの多発地帯を周知しておくこと。
均等にバグが埋まっていることはなくて、「いつもこのあたりにバグが多い」という情報があるので、そこをメンバーに、「ここはバグが多発地帯だから、このパターンのバグがないかどうかをちょっと見ておいてね」と周知しておくのはPMさんの腕の見せどころかなと思っています。
篠原：ありがとうございます。時間の許す限りですが、回答をいたしました。それでは本日の勉強会は以上とし、運営に戻させていただきたいと思います。本日はありがとうございました。
石原：ありがとうございました。
畠山：ありがとうございました。
エンディングトーク
司会者：ありがとうございます。本当にちょっとあっという間の時間で、みなさんからは切羽詰まるというか「どうしたらいいんだろう」と本当に悩んでいらっしゃるコメントやQ＆Aが多かったなと思います。少しでもみなさんの参考になればうれしいです。
ぜひ今日のお話をチームのみなさんにシェアしてもらえたらなと思います。今回のイベントを主催したバルテスさんはPMを募集しています。今日のお話で、石原さんと畠山さんと一緒に働きたいと思った方がたくさんいるのではないかなと思いますが、ぜひお気軽にお申し込みいただければなと思っています。
そして、バルテスさんの「Qbook」というソフトウェア開発コンテンツを配信しているサイトがあるので、こちらもぜひ今後の参考にしていただければなと思います。
本日は夜遅くまでお時間をいただきましてありがとうございました。せっかくなので登壇者のみなさんから最後に感想をおうかがいできればと思います。篠原さん、やってみてどうでしたか？
篠原：久しぶりのウェビナーだったので、私の出番はちょっとしかないんですけど緊張しましたね（笑）。
司会者：そうですよね。
篠原：でもすごく活発に意見をもらえたので楽しかったです。私だけ趣味を言うのを忘れたので。
司会者：最後にぜひ（笑）。
篠原：はい。なかなかコアですが、私はモータースポーツが大好きです。
司会者：素敵ですね。
篠原：特にF1で今年の10月の鈴鹿（※F1日本グランプリが2022年10月に鈴鹿サーキットで開催）は今からワクワクしながら待っています。すみません最後に（笑）。本日はありがとうございました。
司会者：畠山さんはいかがでしたか？
畠山：みなさんリアルタイムでチャットやQAをどんどん出してくれたのですごく楽しかったです。最後のバグを叩くコツで思い出したことがあって、前工程の品質とか仕様変更が開発時にいっぱい入った箇所とか、そういう前工程の特性から狙っていくというのがあるなとちょっと思い出したのでお伝えしておきます。ありがとうございました。
司会者：ありがとうございます。では最後に石原先生、お願い申し上げます。
石原：はい（笑）。本当に楽しかったです。僕は見られませんでしたが、活発にチャットやQAをもらえたので本当に膝を詰てお話ししている雰囲気があってすごく楽しかったです。技術ではその雰囲気がすごく大事だと思うんですよね。
楽しく仲間と悩みを共有してみんなで乗り越えていく、そんな雰囲気を共有できたのがすごくうれしかったし、みなさんと一緒にいろいろ考えていける機会がまたあればうれしいなと思っています。本日はどうもありがとうございました。
司会者：ありがとうございました。第2回以降のイベントも絶賛企画していきたいなと考えているので、ぜひぜひ今後も参加してもらえればと思います。本日は夜遅くまでありがとうございました。
一同：ありがとうございました。
