テストすべき領域の30パーセントが仕様書に書いてあればいいほう
石原一宏氏（以下、石原）：というわけで、上流工程が重要で、べき論ではなくて具体的にどうすればいいの？ みたいな話ですね。上流で品質を作り込むという話です。実は下流工程で大量のバグを出すのはあまりうれしいことではありません。もちろん私たちはたくさんバグを出すつもりでテストをするのですが、できれば上流工程でできるだけバグがないようにしたい。
「だったら完璧な仕様書を書けという意味ですか？」ということではありません。完璧な仕様なんて私は30年やっていて見たことがないです。テストをしなければいけない領域を100とすると、みなさんがふだん書いたり読んだりしている仕様書は何パーセントぐらいが書かれていますか？
チャットで思いついた数字を（書いてみてください）。「50は書いている」「70は書いている」。「40」「60」「30」「70」「55」「10パーセントぐらい」、「50もなさそう」。そうですね。「80はほしい」「68」「70」、いろいろありますね。「5パーセント」もいますね。
なにを100とするかで随分パーセンテージが違ってくるんですが、100という方は少なくともいませんよね。「自分は100だ」と勇気のある方はあまりいませんね。真の勇者だと思います。ちなみに私も100の仕様書なんて30年間やっていて見たことがないです。先ほども言いましたが、テストの領域を100とすると、私は30書いてあればいいほうだなと思っています。
先ほども言ったとおり、なにを100とするかで随分変わってきますが、範囲が曖昧だったり、条件が逆に複雑だったりで見通せない。全体像がわからない。細部ばかりが書いてある。逆もあって、全体像がわかっても細部が見えてこないというのも見たことがあります。正常系しか定義をしていなくて、排他処理、禁則処理、同時処理、準正常系などエラー処理を定義していない。
機能は書いているけど非機能は書いていないとなってくると、いったい何パーセントが書いているんだとなって、どんどんパーセンテージが100から少なくなってくるわけです。そんなことを含めると、だいたい分母を100とするとだいたい30ぐらい（あればいい）。では残りの書かれていないところをどうするのか？ というところが今日のテーマです。がんばって100に近づけるというのが言いたいことかというと、そんなこと言う気はありません。
ただ、「ここは書かれていないけど考えたほうがいいですね」とリマインドできるだけでも随分違ってきますよね。先ほども言いました。仕様書に書かれていることは一部です。でもテストをしなければいけないわけです。準正常系、異常系、排他処理、エラー処理などが書かれていなかったとしてもテストをしなければいけないわけです。
書かれていないところでも、こういうことができなきゃダメだよなと見てみると、書かれていないけれど実装やテストやレビューで見つけなきゃいけないところがけっこう見えてきます。私はこのテクニックがテスト技法だと思っているんですよ。それも言い始めると本1冊とか3日間のセミナーとかになっちゃうので、今日はその一部なんですけど。
今日やりたいことは、書かれていることをテストするのではなくて書かれていないけれどテストしなきゃいけないこと、実装しなきゃいけないこと。特にアジャイルなんかはそうですよね。アジャイルで決めることは本当に実装しなければいけないこと、テストしなければいけないことから見ると、ごく一部だったりしますけれど。でもそこは書いてあろうがなかろうができるだけわからなければいけないという話です。
ちょっとの投資で今の仕事を楽にしていく
結論から言うと、30年前、テストドリブンデベロップメントやテストファーストやシフトレフトという言葉が存在する前からうまい人は「今回は納期が短いな、人が少ないな。だったら設計する前にどんなテストをすればいいのかを考えてから、それから仕様を書いてみたりレビューしたり実装したりしようか」と（考える）。
うまい人はやはり最初からテストの発想なんですよね。だからそのテストのコツをみなさんと共有することによってちょっとヒントを。ワンポイントでもいいので、「完璧は無理にしても観点を持っているだけでも随分違うよな」というところを持って帰ってもらえるとうれしいなと思っています。
というわけでほんのひと手間。例えば私たちは仕様書がなくてもデシジョンテーブルや状態遷移図表を書いたりするのですが、実装のあとに書くのと手間が変わらないんだから、実装の前に10分、15分で書けばそのあとの手戻りの3日や1週間分が随分抑えられるよ。15分の投資で3日が返ってくるんだったら、投資としては本当に何十倍マシ、何百倍マシで、かなり割の良い投資ですよね。
そんなところでやはり楽がしたい。ちょっとの投資で今の仕事を楽にできたらなという話。ほんのひと手間をちょっとお話ししていければな、みんなと一緒に考えていければなと思っています。
見えない仕様を可視化する、できないことを考慮する、図表を活用する。そして「これらをしなかったばかりにこんなひどい目にあっちゃった！」という事例。人の成功の話は聞いていてもうれしくないですよね（笑）。ブラックなことを言って申し訳ないですが、人の失敗の話を聞くことによって自分の糧にするというところを持って帰ってもらいたいと思っています。
実際にあったプロジェクトから、こういうところにひと手間かけるだけでも随分違うというところを現場担当のエンジニアである畠山からお話ししようと思います。では畠山さん、バトンタッチしたいと思いますのでお願いできますか？
畠山塁氏の自己紹介
畠山塁氏（以下、畠山）：石原さんありがとうございました。それではここからは私のパートということでお話ししていきます。
先ほどバルテスがテストを中心にやってきて年間2,600プロジェクト以上というお話もありましたが、その中で遭遇した、テストで見つけた上流でこんなことをやっておけばよかったという事例をここからお話ししていきます。
ということで「上流工程が原因で炎上した事例2選と、対策ポイント」というテーマでお話をしていきます。
まず私の自己紹介です。今はエンタープライズ品質サービス事業部で主に金融機関のお客さまに向けた品質のサービスを提供するグループを統括しています。これまでの経歴です。最初は金融系SI企業と書いてありますが、銀行のシステム子会社に新卒で入り、そこでシステム開発をひと通り経験しました。
その後銀行のIT部門に移り、要件定義等の上流工程や受け入れテストやPMOなどを経験したあとにバルテスに入社しました。バルテスでも品質コンサルティングを中心に、お客さまに対して品質のサービスを提供してきています。そんな中でこのようなイベントに登壇する機会も何回かあり、いろいろと経験させてもらっています。
私も最初に「趣味や自己紹介を入れてほしい」と言われてちょっと考えていました。私は競馬を見るのがすごく好きで、年代的には「競馬と言えば武豊」の世代です。あの方も52歳だと思うのですが、まだまだ一線で向上心を持ってやられているので私もずっと現役で同じようにやっていきたいななんて思っています。
事例その1 特定条件の記載漏れで機能のリリース延期
では事例2選ということで、リリース延期とか、売上に影響とか、命の危険とか、あまり起きてほしくない事例だと思いますが、実際にバルテスでテストをした中で遭遇した事例、テストで見つけた事例をお見せできる範囲でエッセンスをまとめたかたちで紹介をしていきます。
まず1つ目ですね。特定条件の記載が漏れていた。とあるECサイトでクーポンの機能が新しく実装されました。10パーセント引き、100円引きのクーポンがあって、それを商品に適用すると割引される機能があると思いますが、そのようなものです。クーポンの対象を検索する機能も一緒に実装されたのでテストの工程に入ってきたわけです。
クーポンが設定可能な商品が1つもない場合、挙動がちょっとおかしく、こういったケースにハマると検索でエラーが発生して検索機能が動作しなくなってしまったということが起こりました。お客さまが商品を検索できないと購入も当然できないので、結果的にリリース延期になってしまったという事例です。
では上流工程でどんなことに気をつけておけばよかったのかを次のページで紹介します。ここでは、デシジョンテーブルを紹介します。このようにいくつかの条件が組み合わさって挙動が決まるという場合、デシジョンテーブルで整理するのは非常に有効な方法です。
条件を整理して、その結果で起こるアクションを整理するやり方ですね。この事例では、この赤枠のところ、クーポンなしの場合の挙動が漏れていたことで起こりました。今回のように、クーポンを新しく適用しますという時に、要件を出してくれるユーザーさんもあることばかりを「ある」と言ってくるケースがよくあると思います。
それに対して開発側はいろいろ仕様を考えていくわけですが、要件に引っ張られると「ないパターン」が漏れていたり、考慮していてもいくつかパターンが漏れるというのは起こりうると思います。
そのような時にデシジョンテーブルを使ってすべてのパターンを1回洗い出した上で、ユーザーさんが見えない仕様も可視化して「じゃあこの場合の動きはどうしますか？」「エラーメッセージを出しますか？」とか「そもそもあり得ませんか？」という議論の話につなげることで、仕様の抜け漏れをなくしていくことができる有効なやり方です。ということで、デシジョンテーブルの紹介でした。
事例その2 できてはいけないことが考慮されていなかった
では、2つ目の事例です。2つ目は「できてはいけないことが考慮されていない」という事例です。これはサブスクリプションサービスの話で、PCとスマートフォン1台につき1アカウントを契約するという条件がありました。1契約で2台の利用はできない仕様でした。
PC2台での同時利用は制御されていましたが、PCとスマートフォンでの同時サービス利用が制御できておらず、ちょっと仕様に合っていなかった。結果的にはそういうことが見つかりましたということで、これもテストで見つけられていなかったらサービスの不正利用や、売上にも影響が出ていた可能性がある事例ですね。
こういった「できてはいけない」という場合に有効な整理の仕方を紹介します。「Must」と「Never」というものをご紹介しますが、これは私たちバルテスでも仕様の整理によく使う言葉・やり方です。Mustは「できるのが正しい」ということ、Neverは「できないのが正しい・できてはいけない」という2つで整理をしていきます。
とあるサービスの機能においてなにができなければいけないのか、なにができてはいけないのかですね。この事例だと、できなければいけないのが「1台の端末でサービスを利用できる」ことですね。逆にできてはいけない・できないのが正しいのは、「複数の端末の同時利用ができない」ということになります。
この場合は、どのようなパターンがあるのか枝分かれさせて洗い出していきます。マインドマップを使うことも多いのですが、この場合、「1台の端末でサービスを利用できる」は1台では動くということを確認する必要がありますが、それ以外にも1台の端末を解除して再度利用した場合にできるのかというような場合など、いくつかパターンがあると思います。
逆にNeverですね。できないのが正しい。「複数の端末で利用できない」という場合に、同じ環境2台でできないことを確認する。ほかにも異なる環境でも複数台同時に利用はできないのかというパターンもあります。今回の事例ではここが漏れていたわけです。
ということで、MustとNeverを洗い出して、さらにどんなパターンがあるのか。ポイントは仕様どおりにできること・仕様どおりにできないこと。いわゆる正常系で考えて、それ以外にどんなパターンがあるのか。「バグを叩きにいく」という表現をしていますが、どんな場合に誤動作が起きるのかというパターンをどんどん洗い出して網羅性を高めていくやり方ですね。
ここでは1つの組み合わせで書いていますが、1つの機能なりサービスなりでいくつもできるのが正しい・できないのが正しい、Must・Neverでいろいろな組み合わせがあると思います。この裏返しでMustとNeverをどんどん洗い出して、できないことを考慮していくことが非常に有効なやり方です。
以上で2つの事例を紹介しました。1つ目の「特定条件の仕様が漏れてリリース延期」は、見えない仕様を可視化する。デシジョンテーブルで整理をして可視化をするということですね。2つ目の「できてはいけないことの仕様漏れで売上に影響」はMustとNeverの関係を使って、できないことを洗い出していく手法を紹介しました。
仕様を見やすくすることのメリット3つ
2つで共通しているところは、やはり仕様を見えるようにしていくということだと思います。利点は大きく3つあると思っています。1つ目は仕様の要件を出してくれるユーザーと認識合わせがしやすいというところです。それによって（ユーザーが）言ってきていない仕様の認識合わせができたり、全体の網羅性を見やすくするという利点があると思います。
2つ目がレビューがしやすいということですね。設計書なりドキュメントなりをレビューする立場の方も多いと思いますが、1つ図表が付いているだけで仕様がどう整理されているのかが非常にわかりやすくなると思います。
3つ目がテストをしやすいということですね。設計書を基にテストケースを組んでいくと思いますが、設計書に図表があって網羅性がわかるだけで、テストの抜け漏れがなくなるというところで、3つの利点があると思っています。以上、私のパートでは3つの事例を紹介しました。では石原さんにお返ししたいと思います。
（次回へつづく）
