仕様を完璧にするのではなく、少しの投資で仕事を楽にする
品質とコストを“ほんのひと手間”で改善する方法

文字はできるだけ可視化、Must・Neverの考え方でテストの範囲を決める

石原一宏氏（以下、石原）：畠山さんありがとうございます。

見えない仕様を可視化する、できないことを考慮する、図表を活用する。上流工程のひと手間で手戻りリスクは大きく減ることをお話ししていただきました。先ほどもありましたが、範囲が曖昧、条件が複雑、全体像がわからない、書いていることの箇条書きだけを見ても全体像がわからないんですよね。

一方で全体像がわかっても、細かいところが見えない逆パターンがあります。できることしか定義していない、チャットにもありました。Never・MustでNeverしか書いていないことが多いんですよね。「非機能を考慮していない」、そうですね。仕様書にはだいたい機能系の正常系、Mustしか書いていない。非機能のNeverなんて書いていないんですよね。

書いていなければテストをしなくてもいいのかというと、ぜんぜんそんなことはないよという話です。「非機能要件に関してもちょっと知りたい」とコメントされた方がいましたね。それについてちょっとお話をしておこうと思います。

対象の一例ですが、私たちは文字をできるだけ図表化していきます。範囲が曖昧であれば数直線を書いて境界値を明らかにしたり、先ほどのデシジョンテーブルにしたり。全体像がわからない・細部がわからない。書いているものが全体かというとそうではないので図にしてみるとけっこうわかるよという話がありました。

あとはMust・Neverの考え方。これは応用範囲が広いです。そのシステム丸ごとのMustとNeverはなにかと考えることもできるし、機能単位・画面単位・モジュール単位のどんな小さなものでも正常系のMustと、異常系のNeverはなんだろうとセットで考える癖を付けておくとすごくいいですね。仕様書に書いてあろうがなかろうが、正常系のMustに対して異常系や準正常系のできないことが正しいというNeverをテストしなければいけないという発想（は必要です）。

テスト担当者は、仕様書がなくてもテストをしなければいけないと骨身に染みているので、仕様書があろうがなかろうがこういうふうに読んでいくという考え方がすごく大事です。ほかにも非機能系に関してコメントをすると、「非機能要件も見ておいてね」とお客さまや上司から言われることが多いのですが、「非機能ってなんだ？」という話ですね。意外と範囲は広いぞという話です。

仕様書を読み込む中で、ここは抜けがちなんじゃないかな、やばいんじゃないかな、テストをしておいたほうがいいよなというところを見ていくわけです。こういうのを毎回全部埋めなくてもいいのですが、デシジョンテーブルを使ってみたり、MustだけではなくてNeverはなにかを書いてみたりをテンプレート化するだけでも随分違ってきます。

あとは非機能の話でしたね。これは有名なISO25010、通称SQuaREです。ISOが決めた、ソフトウェアの品質が良いとはどういうことか。機能性の他にも、使用性とか信頼性とかセキュリティとかありますが、この中で非機能はどれかというと、8個ある中の7つが非機能です。つまり機能以外は全部非機能なんですね。「これを全部仕様書に書いていますか？」というと、まだらにしか書いていないですよねという話です。

仕様書に書かれていようがいまいが、考えなければいけないところはけっこうある

「Never・Mustとかは大事ですか？」「そういう考え方を持っていない人はどう考えればいいんでしょうか？」という質問もけっこういただいていますね。これは本当に九九みたいなものなんですよね。九九ってみなさんも使っていますよね？　九九を使わずに日常生活や仕事をするのはなかなか難しいと思います。

それと同じでテストをする時も品質で考えないといけません。こういうカテゴリがあるよね、それからNever・Mustという考え方があるよね。一例ですが、ECサイトで考えるのであれば横軸にNeverとMustを考える。縦軸に機能性、信頼性、使用性などのカテゴリーを考える。それで機能性のNever・Mustとはなんだろうという話。

上流の要件定義が増えたら、さらに付加価値があるなと横軸にWantも出したりするんですけどね。だいたい仕様書にはここぐらいしか書かれていないですよね。機能性のMustしか書かれていないですよねという話です。でもテストでは使用性のNever・Mustも考えなければいけません。スマホ、タブレットで各種ブラウザーからアクセスできるかとか、レスポンスタイムで時間がかかったら頭にきますよねというところがあるので、使用性は書いていないけれどやらないといけません。

信頼性でのNever・Mustももちろんあります。例えば想定の10倍以上のアクセスがあったとしてもシステムダウンしないために負荷テストをしなければいけないし、24時間365日使えなければいけないからシステムダウンはしちゃダメだよねという話。仕様は意外とここしか書かれていないんですよね。そういうかたちで俯瞰して見ることが大事です。

ただ3×8の24マスのうち、仕様に書かれているのは1マスだけだったということはけっこうあるんですよ。これはけっこう大変で、全部埋める必要はありません。でも、例えば使用性で考えないといけないことは確かにあるよなとか、そう考えていくと書かれていようがいまいが考えなければいけないところはけっこうあるよねという発想を持つことが大事なんです。

デシジョンテーブル作成の考え方

（コメントを見て）「縦軸はこんなに重要なんですか？」。こんなには必要ないです。みなさんの開発であったところでかまいません。ただ、使用性やセキュリティはあったほうがいいし、細かいですがバージョンアップをたくさんするのであれば、保守性と仕様書に書いていなくても書いておいたほうがいいです。

サーバーの増数が考慮されているか、ホテルのデータベースのカテゴリ追加を想定しているか。これは想定しているかしていないかで、メンテナンスやデグレードが天と地ほど変わってくるじゃないですか。こういうマトリクス的な発想があると、「仕様書に書いているところはここだよね。書いていないけれど、こういうところは注意しないといけないよね」ということがメンバー間やプログラマー間で話ができるんですよね。

「ごめん、今回は本当に時間がなくて使用性や信頼性がぜんぜん書いていないんだけど、これは実装段階で考えてくれないかな」と一言PMがプログラマーに言うだけでけっこう違ってくる。書かれているところしか見ないというのは人間の性なので、「書かれていないけどこのあたりもあるからね」とリマインドを始めるところからちょっとやってみる。

「こんなにたくさんの大きな表なんか作れない！」というのであれば、まずはNever・Mustを横軸、縦軸は機能とそれ以外でかまいません。これだったら2×2のマトリクスで済むでしょう。でもやはり書いてある1に対して4の領域を見なければいけないところがあるので、そういうところをちょっと考えてもらうだけでも随分違うのかなと思います。

（コメントを見て）「このドキュメントほしい」（笑）。これはあげられないかな。ちょっと覚えて帰ってください。Never・Mustが横軸、縦軸に機能性・使用性。意外と考えない領域が広いよねというところは、こういうところから話をしています。

先ほどお話ししましたよね。このイメージですね。本当に書かれているのはこの黄色のごく一部で、書かれていなくてもやらなければいけないことはこれだけ広いです。これはけっこう質問もいただいたのでお話をした次第です。

というわけで、いったん私のパートはこれぐらいにしてQAコーナーに持っていけたらなと思っています。

身の回りの小さなものからMustとNeverを考えて見せ合ってみる

司会者：石原さん、畠山さんありがとうございました。

「仕様を100にするべきだ」ではなく、本当に少しのひと手間で後工程が抑える具体的な事例を紹介いただきました。ありがとうございました。鬼気迫る質問がたくさん来ておりますので。

（一同笑）

司会者：さっそくですがQAに移っていきたいと思っています。ではここからのファシリテーターは、グループ開発事業推進部の篠原さんにお願いできればと思います。

篠原新治氏（以下、篠原）：では私、篠原が進行したいと思います。始まる前はQAが来なかったらどうしようとドキドキしていたのですが（笑）。勉強会中にたくさん質問をいただきましてありがとうございます。

「仕様の充実化に向けて特別な訓練が必要でしょうか？」という質問が来ています。「仕様を書く人が仕様を正しく理解していなかったり、ドキュメント化することが苦手だったりします」というところについて、まず石原さんお願いできますでしょうか。

石原：「テストのコツ、レビューのコツはなんですか？」と聞かれるのですが、地道ですがやはりMustはなんなのか、それに対してNeverはなんなのかをまず考えるのが一番の基礎の基礎だと思います。それらをワンセットで考えることがすごく大事だと思います。

例えば、みなさんがふだんから使っているシャープペンシルでも、あるいはテレビのリモコンでもいいんです。Mustがなんだろう、そしてNeverがなんだろうと目の前のものでやってみるトレーニングをやるだけでもぜんぜん違ってくると思います。いきなり難しい対象ではなくて簡単なものからやってみる。

仕事以外のものだとリアリティが湧かないというのであれば、画面単位やボックス単位、メッセージボックスの単位の中でなにがMustでなにがNeverなんだろうかと小振りにすることですね。本当に3分ぐらいで考えられるところがあります。考えてみてこれでいいかなと2人以上で見せ合ったりすると意外と一致していないところが多いんですよ。

先輩と後輩でやると、自分の視点がすごく偏っているのがけっこうわかってくると思います。それを地道に繰り返すことが、1つのポイントですね。3分自分で考えてみて、他の人と見比べ合うのはお互いにとって相乗効果がすごく高いです。うまい人のテクニックなりを盗むのであればまずは自分で考えてみる。それから共有するということをやるだけでも随分違うかなと思っています。

それをやると意外と「それいただき！　盗んじゃおう」と考えられたりするので、そういうふうにちょっと楽しみながらできるといいかなと思っています。畠山さんはどうでしょう？

畠山塁氏（以下、畠山）：そうですね。やはり身近な事例でやるのはけっこういいかなと思っています。私たちも電子レンジで考えたりしますね。電子レンジのMustとNeverを考えてみる。Mustは分数を設定して、ワット数を指定して、スタートすると温め開始とか、時間が経つと止まってお知らせするとかです。

Neverのところで、途中でドアを開けたらどうなるかというところで人によってズレが出てきて、そこがまたおもしろいんですけど。見せ合ったりすると観点が違うので、いろいろ身近なところでMustとNeverの観点を考える。親しみやすい事例から入って、そういう思考の癖を付けていくのはけっこう有効かなと思います。

石原：今の畠山さんの話で思い出したのですが、新人さんはなかなかNeverを出せなかったりするじゃないですか。初めて金融の業務に携わった人にNeverを出せと言ってもなかなか難しいですよね。

畠山：そうですね。

石原：仕様を理解してもらうことももちろん重要ですが、「こんな不具合が過去にあったんだよ」と不具合を共有することを私もよくやっています。あとから入った人にも「こんな不具合があるんですね」と思ってもらう。それが仕様の理解につながることもけっこうあるので、そういうことはけっこうやっていますがいかがでしょうか？

畠山：そうですね。過去の事例も非常に参考になりますし、新人でも人によってけっこう観点が違うので「バグを見つけてやる！」という新人もたまにいるんですよね（笑）。細かいところを突っつくことで他の人の参考になったり、全体の底上げになったりするところはあるかなと思います。

石原：そうですね。新人さんの、ベテランには持っていない発想はすごく大事ですし、ベテランや業務経験者だけが持っているありがちなあるある不具合は良い刺激になるので、こういうのを共有し合うのはすごく文化としても良いと思います。「昔こんな不具合があってひどい目にあったんだよ」という話を共有していく、過去事例から導いてみるというのはチームメンバーにとってもけっこう良いと思います。

「ヤバそうなところはどこ？」という話ですね。私はけっこうキャンプが好きなんですが、危険地帯を知っておくのは大事です。ここは滑落しやすいとか、雨が降ったらここは滑りやすいとか。そういうところを共有しておくことがNeverを未然に防ぐことにけっこうつながったりすると思っています。

篠原：ありがとうございます。コメントやチャットにも「やっていこう！」といただいているので大変うれしいですね。

（次回へつづく）