https://logmi.jp/tech/articles/327393
石原一宏氏（以下、石原）：というわけで、上流工程が重要で、べき論ではなくて具体的にどうすればいいの？ みたいな話ですね。上流で品質を作り込むという話です。実は下流工程で大量のバグを出すのはあまりうれしいことではありません。もちろん私たちはたくさんバグを出すつもりでテストをするのですが、できれば上流工程でできるだけバグがないようにしたい。
「だったら完璧な仕様書を書けという意味ですか？」ということではありません。完璧な仕様なんて私は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日が返ってくるんだったら、投資としては本当に何十倍マシ、何百倍マシで、かなり割の良い投資ですよね。
そんなところでやはり楽がしたい。ちょっとの投資で今の仕事を楽にできたらなという話。ほんのひと手間をちょっとお話ししていければな、みんなと一緒に考えていければなと思っています。
見えない仕様を可視化する、できないことを考慮する、図表を活用する。そして「これらをしなかったばかりにこんなひどい目にあっちゃった！」という事例。人の成功の話は聞いていてもうれしくないですよね（笑）。ブラックなことを言って申し訳ないですが、人の失敗の話を聞くことによって自分の糧にするというところを持って帰ってもらいたいと思っています。
実際にあったプロジェクトから、こういうところにひと手間かけるだけでも随分違うというところを現場担当のエンジニアである畠山からお話ししようと思います。では畠山さん、バトンタッチしたいと思いますのでお願いできますか？