#仕様書インスペクション#
##開発に入る前に勝負をつけたい！##

###[1] 仕様書インスペクションの役割###

ここ数ヶ月、仕様書インスペクションについて学んだことや実践したことをお話ししたいと思います。

企画▶開発▶テスト▶リリース

という大雑把な流れでいうと、私が行っているのは企画が仕上げた仕様書について、開発に着手する前に、仕様書とじっくり向き合って、隠れた欠陥がないか検査をする、検査技師のような業務です。

この検査技師がいない状態で仕様書が開発というレールに乗ってしまうと、テストという駅に停車して初めて問題が顕在化することになります。

エンジニアの小さな修正で済めばまだいいですが、大がかりな修正に発展することもあり、よくよく検討した結果仕様書そのものが編集を余儀なくされるということにもなってしまう可能性があります。

それらにかかるコスト全てを防ぐには、検査技師の存在は不可欠なのです。検査技師からの情報提供をうけて、医師の役割である企画者が今のままの仕様で様子を見るか、薬を処方して（細かな仕様書の編集を行い）仕様書に変更を加えるか、手術するか（大幅な仕様変更を行うか）決定をします。

###[2]インスペクションを書籍で学ぶ###

初めて仕様書インスペクションを頼まれたのは一年半くらい前だと思います。「仕様書インスペクションをお願いしたい」と言われて簡単な説明を受け、いざ取り組んでみたものの、何をどうしたらいいのかさっぱり分からずでした。

書いてあることは正しかったので、「終わりました。特に問題ありません。」と回答し、タスクをdoneにしていました。軽微な誤字脱字を指摘したこともありました。

「検査技師が、検査とは何かを知らず検査してみる」

恐ろしいですねー。これが人間に対する検査だったら大変なことになっていますね。

さすがにこのままではまずいと思った私は、まず「仕様書をインスペクションするとは何か」を調べました。

基本的な疑問について素人が学習や調べ物やをするときは、ネットではなく書籍で学ぶのが確実なので、仕様書インスペクションについて書かれている書籍はないのか、探してみました。

そうすると、出るわ出るわ、の逆で、見つからない見つからない。見つからないんです。

インスペクションに特化した書籍が見つけられなかったのです。私の調べ方が悪かったのかもしれないのですが、ようやく見つかった書籍・雑誌は2点ありました。

・ソフトウェアインスペクション
共立出版 1999年8月25日初版
・ソフトウェアテストPRESS Vol.2
技術評論社 2005年12月1日発売

さっそく購入し、読んでいきました。JSTQBのFoundationの勉強をしたことがあったので、中身はスムーズに読めました。インスペクションの方法で、自分でできそうなものが2つあったので紹介します。

###[3]実践その１：三色ボールペンの利用###

1つめ
3色ボールペンを使う
仕様書を印刷し、客観的に最も大事なところに赤、客観的にまあまあ重要なところに青、主観的に気になる（おかしいと感じる）ところに緑の線を引いていくという手法です。

ひととおり線を引き終わったあと、読み直していくと青は一読しただけで、「何かがおかしい」と立ち止まることができる場所です。他の機能と統一が取れているか、または例外処理が正しく書かれているかなど、どこを振りえればよいかが明らかなところに線が引かれてます。これらは仕様書インスペクションとして記録し、最終的に企画者に情報提出を行います。

では緑色はどのような役割を果たすのでしょうか。

赤と青のボールペンだけだと、一瞬気になる箇所があっても、無視して読み続けてしまいます。
無視した結果、テストのときに不具合として発覚し、「あーーー、あのときなんとなく気になってたところだーーー！あのとききちんと掘り起こしておけば良かったーーーーー！！！」という後悔を防ぐ効果が緑にはあるのです。

そのため、緑の線を引いたところとはじっくり向き合う必要があります。「なぜ一瞬引っかかったのか」「この分のどこが気になっているのか」を深く掘り下げていくことによって、仕様書に補足すべき箇所が明らかになってきます。

###[4]実践その２：チェックリストの利用###
2つめは、チェックリストを作り、仕様書を読み進めます。今は主にチェックリストを使っています。例を４つほど書き出してみます。

・他の仕様書と統一が取れていないところが無いか？（不整合がある）
・重大な漏れが無いか？
・曖昧な表現が無いか？
・複数の解釈ができてしまうところが無いか？

など、すべて疑問形になっている十数個のリストに沿って、仕様書を読み進めます。当てはまる箇所が出てきたら記録していきます。
このとき軽微な誤字脱字や言い回しなどは、あまりチェックしません。「名称が誤っている」などは、誤字脱字の範囲を超えているのでインスペクション項目に記載しますが、校正を行っているのではなく、インスペクションを行っているので、その点は注意しながらインスペクションを進めていきます。

インスペクションが終わったら資料にまとめて企画者に提出します。
ここで大事なことは、「編集して欲しい」と依頼を出すことだと書籍に書いてありました。

なぜなら「訂正して欲しい」や「修正して欲しい」などの言い方が重なることによって、企画者によってはどんどん否定されているように感じてしまい、「インスペクションされることを拒否するようになってしまう」ことがあるからだそうです。

「欠陥を憎んで人を憎まず」こんな名言もどこかに書いてありました。

テレワークでチームで仕事を進める今日この頃です。テキストベースであるならなおさら相手の気持ちを立てることは大事ですね。

###[5]いま乗り越えたい課題###
ところで、私は仕様書インスペクションを行うにあたり、ユーザーの視点と工数の観点から「そもそも機能を削除してもいいところ」「仕様を変更したところがいいところ」「機能を追加した方がいいところ」これらを提案する業務も行っています。

行っていますとサラッと書きましたが、この点についてはまだまだ微力です。

仕様書を読んで「ここは動作そのものを変更したほうが良い」と思っても、プロダクトが出来上がっていないドキュメントベースのものを元にうまく自分の意見を相手に伝わるような表現力がまだまだ私には足りません。大きな課題です。

その他の課題で目下試行錯誤中の課題があります。
「仕様書からまるまる記載が抜けていることに気がつくにはどうしたらいいか」です。
欠片が仕様書にあれば、輪郭を書き出すのはまだやさしいことです。
欠片すらなくて、市場に欠陥として流出してしまうなんていうとこを防ぐにはどんな工夫が必要か、まだ答えが出ていません。

それらができるようになったら自分に自信がつきますね。最終的に判断するのは企画者ですが、企画者が判断する材料として十分な情報を自分は出し切れているか？そこは本当に大きな課題です。

自分がどれだけ変われるか。その一点にかかっている気がしますね。

###[6]最後に###
まだ仕様書インスペクションは学び始めたばかりで、実践し始めたばかりです。

でも2～3回実践してみるだけで、自分の中の意識がすごく変わったことを実感できましたし、「上流でなんとか食い止めるぞ」という意欲も高まったように思います。

「あーーー、あのときなんとなく気になってたところだーーー！あのとききちんと掘り起こしておけば良かったーーーーー！！！」という後悔を半年で２度も経験しました。あのときの手戻りにかかってしまった企画・開発・テストのコスト、いったいいくらになるのか想像がつきません。「ほぞをかむ」という言葉はこういうときに使うのであろうと思います。

あの時の悔しさを二度と味わいたくないから、私は今日も仕様書インスペクションを行います。
最後まで読んでいただき、ありがとうございました。