Q. 要求仕様書は初期に書くべきか？

【異論①】

できる限り初期にきちんとしたものを書くべき。早めにどのようなものを何故作るのかきちんと定義しておかないと、開発中の判断がいきあたりばったりになってしまう。

【異論②】

外部とのコミュニケーションが発生するときに書くべき。内部で運用している限りはメモ書きやホワイトボード上のまとめで十分。何故なら仕様なんてコロコロ変わるから。その都度書き直していたら毎日書き直す羽目になる。

【異論③】

本当に必要なとき以外は書かない。コスト＝労力に見合うメリットが無い。

【九頭龍の考え】

アメリカに行った当初。あまりに周囲がドキュメントを書かないことに驚きました。 それまでは私のキャリアは所謂「日本的大企業の開発職」だけでしたので、ドキュメント仕事に煩わしさを感じながらも日々アレコレと書類を作成し、上司の検印をもらっていました。 そのような当時の私の基準からすると、本当に「こいつら誰もドキュメント書かないな」と思ったものでした。しかし、私としてはその日本的な書類文化にも辟易していたので一気にシリコンバレー的な文化に流れました。 そしてあるところで気が付きました。

「みんなはドキュメントを書かない代わりにコミュニケーションを重視してるんだな」と。

例えば当時のボスのJは「それについてはドキュメント読んどいて」と言っても読んでくれないのです。私に直接聞きにきました。 Yes/Noの一言で終わるような話でも聞きにきます。書いてあるのに。 そして10回中8回くらいはそっけないやりとりで、2回くらい脱線して他の話もします。人懐っこいPは10回中9回は私のところで話し込んでいくし（大抵音楽か漫画の話）博識なEは大抵質問への答えとともに豆知識や彼のAppleでの経験を付け足してくれました。 なるほど、こういうことなんだな、と思いました。 彼らはドキュメントのような無機質なものに依存せずに「わからないならなんでも聞いてくれ」という常にオープンなスタンスで、チームで問題に取り組みそして解決していくスタイルが染み付いているのです。 このような環境においてドキュメントはほとんどお飾りでしかなく、プロジェクトのまとめの時期にもし必要だったら作る、という程度のものでしかなかったのです。あるいは退職する時に。

一方、とある会社で関わった案件に「案件を引っ張ってきた担当者が辞め、その後任の担当者も2名辞めた」という地獄のようなものがありました。担当者たちが次々と辞めた理由や経緯について私は知りませんが、私が合流した時は最初から関わっていたジュニアレベルのエンジニアのSさんが責任者のような立場（彼しか経緯を把握していないので当然と言えば当然ですが）になっていました。 短期間ながらそのプロジェクトをサポートしましたが、とにかくどこまでが達成できていてどこが課題なのかがさっぱりわからない。また元々どういう要望を受けていて、それに対して何は断って何はやることにしたのかもわからない。スケジュールも納品物もなし崩し的に変わってきてしまっていて今クライアントとどのような約束をしているのかもわからない。 このあと行ったことが仕様書の整理でした。

完全な後付けになってしまいますが、現状と経緯を紐解いて、どのような要求があり、どのような議論でどのような落とし所に決定したか。またそれに基づき基本スペック及び使用部品を決定し、どのようにテストを行うか。それらの内容を今更ながら書いて、先方に承認していただくという作業を行いました。 「なんでドキュメント残してないんだよ・・・」と呪いましたね。 正確にはドキュメントはありました。しかし断片的であったり、重要な経緯の部分を書いていなかったり、結局どうなったのかが書いてなかったり、不十分なものばかりでした。 Sさんが一人とはいえ残っていたことがせめてもの救いでした。Sさんに聞いたり、Sさんとクライアントで会話することで経緯や詳細を紐解くことができ、またSさんとクライアントの関係性は良好でした。 その後なんとかそのプロジェクトはクローズすることができました。

さて、極端な２例について触れましたが、片や自社開発製品、片やクライアント案件と話の前提がだいぶ違います。しかしながら「開発」という意味では本質は何も変わらないと私は思います。 何か目的や目標があってモノを作り、その品質を確認した上でアウトプットするというプロセスそのものは全く同じです。

では仕様書およびドキュメントについてどう考えるべきでしょうか。 私がオススメするのは「ドキュメントは常にコントラストをつけて書いておくべき」という考え方です。

実は前述のようなコミュニケーション重視の手法には大きな欠点があります。それは「個人の素養に大きく左右される」ということです。 シリコンバレーのエンジニアは色々な意味でレベルが高いです。それはコミュニケーションのレベルも含まれます。上記のような手法が成立している部分がある、ということについては否めません。 したがって個人のスキルだけなく、組織の成熟度、チームのマネージメントスタイルなどによっても成立しない可能性が十分にあります。 またコミュニケーションを重視し過ぎる傾向にあると「声が大きいやつが勝つ」だとか「口から出まかせを積み重ねて墓穴を掘る前にトンズラするやつが出る」などのトラブルを避けることができません。

しかしながらドキュメントの作成は得てして多大なる時間＝コストを要します。 新卒3年目の時にとあるプラットフォームの開発を外部委託するプロジェクトに関わったことがあります。彼これ十年以上自社開発を続けてきた言わば秘伝のタレのようなものの詳細を仕様書の形でまとめるというのは非常に骨が折れる話でした。英語で書かなければならないということもあり、結局その作業には4人がかりで2ヶ月以上は費やした記憶があります。

そこで提案したいのは常にコントラスト（強弱）を意識するということです。レゾリューション（解像度）と言っても良いかもしれません。

例えば以前「コンサル案件の場合は要求仕様の書きようがない。そもそも顧客の要求自体が固まっていないことが多いので。どうしたらよいか」という相談を受けました。私は「『顧客要望を明確にする』というゴールで要求仕様を書いておけばいいんだよ」と返答しました。 プロジェクトにおいて何をやっているのか、そのゴールがわからなくなるのが最も恐ろしいことです。 それは「製品を出す」というようなレイヤではなく「何を、どんな社会を実現するために、この製品を出すのか」というレイヤです。 このゴールは、明文化されていて、誰が見ても解釈の余地なく、意味が明白であることが重要です。ドキュメントとはそのためにあります。

また場合によっては「現時点では不明＝TBD」と書いておくことが仕様書にとって重要であったりもします。 「わからない、決まっていないから書かない」ではなく「決まっていないということを書いておく」と考えるべきです。 そう気楽に考えれば仕様書を書くことはさほど負担ではなくなるはずです。
このように上手く手加減をつけることでいつでもドキュメントを作成しておくことは可能になります。ぜひチャレンジして自分なりのやり方を編み出して下さい。

ちなみに私がドキュメントの重要性を唱える最も重大な理由は「私は私の記憶力をさほど信頼していない」からです。

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

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