Q. 要求仕様書をどのくらいのレベルで書いて開発を進めるべきか？

要求仕様書のテンプレート自体はことさら私が述べる必要もなく、各種機関およびボランティアが様々なものを提供してくれています。自分の感覚やチームに合っているものを使用していただければそれで良いと思います。 したがってここでは「これがないとマズい」という典型例についていくつか取り上げます。

＜オーソライズされていない＞

ドキュメントの重要な役割が「みんなで確認して」「承認して」「いつでも取り出し可能にしておく」ということです。 自分の脳みその中をまとめたメモ、というものも当然あって構いませんが、それは仕様書ではありません。 むしろ情報の粒度によらず、きちんとチームでレビューをして修正を施し、そしてオーソライズされたものが仕様書です。 クライアントがいるのであればクライアントのレビューをもらったものが仕様書です。 頭の中にあるものをまとめただけのドキュメントで開発を進めることは危険です。一度きちんとレビューをしましょう。

＜性能要求が明確になっていない＞

要求仕様署には最低限「何を目的に」「この機能を載せて」「OK/NGの判断はこのくらいにする」ということが書いてある必要があります。この「OK/NGの判断」を決めるのが性能要件です。これは極力数字で書かれていることが好ましいです。

例えば、工場の工程で不良品をはじく画像検査装置を開発するとします。当然「カメラで画像を撮る」必要がありますし「画像を計算機へ転送する」必要があるかも知れません。そして「不良品を検出する」必要があります。 カメラについては例えば「30fps以上」とか「画素数12Mピクセル以上」とか「JPEGでファイルを保存できる」などというような性能が求められると思います。設計を進める過程でこれらの要件を満たしているかどうか確認するわけです。 そして通信については「USB3.0を用いる」とか「10ms以内に画像転送を完了する(TBD)」などの要件が入ります。ここでTBDを入れてみました。画像の転送に求められる条件は実際は画像の処理にかかる時間に大きく影響を受けるために開発当初では明確に決まっていないからです。しかしここであえて数値を書くこと、そしてTBDであると明記することがポイントです。

そして厄介なのが「不良品の検出」の部分です。何をOK/NGの基準とするか？どのような不良を必ず検出し、逆にどのような不良に関してはベストエフォートとするか？非常に難しいですが、ここを決めなければ開発を進めることはできません。

「とりあえず作ってみてあとで考えよう」というわけにはいきません。何故なら例えばここで仮に「1mm以上の擦れ傷を検出する」ということが重要だったとします。解像度とカメラの距離から検出可能な傷のサイズは概ね計算が可能です。とりあえずカメラを在り物で選定してしまったあとでこの仕様が発覚した場合どのように対応するか。カメラを近づける？レンズを取り付ける？AIの精度を上げる？いやいや、最初からカメラの選定の時点でこの性能を踏まえるべきだったでしょ、となるに違いありません。

性能要求を明確にすること、そしてその要求が影響を及ぼす範囲の担当者たちでその共通認識を持っておくこと。それらの手を抜くとあとで痛い目を見ることになります。

＜履歴管理がされていない＞

仕様書は開発中にガンガン書き直します。そうあるべきですし、いざ開発を始めると必然的にそうなるものです。 その際に「履歴管理ができるツールを使用していること」「更新履歴がチームに周知されるシステムになっていること」が極めて重要です。 仕様書は前述のとおりオーソライズされたものです。しかしそれを変えなければならない時があるし、変えていくべきです。その際にはチームでの共有の粒度を高く確保することが必然的に求められます。

近年は便利なツールが沢山あります。gitで管理するのも手ですしGoogle Docなども使えます。ライトなものであればKibelaやesa, Qiita Teamsなども使えます。更新履歴をSlack連携すればチームへの伝達も容易です。 このようにツールを活用すればきたるべきレビューの際の負荷を減らすこともでき、その点でもメリットがあります。

ここまでで示した通り、仕様書を書いて開発を始めるにあたって内容のレベル感は実はそこまで重要ではありません。大事なことはツールやシステムなどの体制周りを整えること、そして書くべきことは書いて、書けないのであれば書けないと書いておくこと、それら基本的なポイントを押さえておくことが肝要となります。

このポストの内容は以下の書籍の一部（原文）です。興味のある方はぜひ書籍をお求めください。

幸せなIoTスタートアップの輪郭