T

仕様書

この2週間、ずっと仕様書を作成している。来週で1回目のレビューだ。

気づいたらこの作業をやる他ない状況にいたのだが、はからずもちょっとした面白さのはじっこに自分が齧りついているかもしれない気がしてきたので、メモしておく。

まず、仕様書の作成を依頼された(本来自分から言い出すべきだったのだが)時に念を押されたのは以下の3つ:

(1)実装の詳細は書かない

つまり、これは機能仕様書であって、技術仕様書ではない。

(2)全ての機能と機能のフローを記載する

要するに、仕様書で大事なのはINとOUTがはっきりと書かれていること。

想定される読者は、プロジェクトマネージャ、営業マネージャ、この製品を使って実際のサービスを構築する開発チームのマネージャ、リリース後に保守を担当するテクニカルサポートチームのマネージャ。この人たちを、ただの読者にしておくことはやらない。それぞれの視点から、自分の担当する業務や今後の戦略に照らし合わせ、この仕様書に記載された内容で過不足ないかどうかをチェックする義務を負う。

(3)レビューの目的と期日、目的を明確にして通知する

最初の打ち合わせの時に、期日までにレビューを完了してリクエストを返さない限り、希望する機能が他にあったとしても、そしてそれが自分の業務に欠かすことの出来ないものであっても、絶対に組み込まれない旨を想定読者全員に通知する。もちろん、本当にそうするつもりだ。何か機能を組み込み忘れたせいで製品が売れなかったら、それはリクエストしなかった人の責任になる。

実は、この仕様書を作成する前に、もうプログラムを作成する日程を決めて実際に作業を始めようとしていた。そこへ、リリース後のサポートを担当するチームのマネージャからストップがかかった。現状のままで開発を進めた場合、製品の品質に重大な懸念があり、サポートは責任を持てないというのだ。まったくもってノリの悪い奴だ、と思ってやろうとしたが、その前にじっくりと考えて、確かにその通りだと思うことにした。まったくその通りだから。うん、実にその通りだ。当初は、複雑な製品なのだから、作ってからバージョンアップして改良していけばいい、と考えていた。でも、その割には改良のためのコストは誰もどこにも計上していない。自社製品なのだから、日々改良するのは当たり前、みたいな雰囲気もあったせいかもしれない。

最初は、どんな機能を実装するかは企画担当者に任せて、こちらはそれをプログラムにするにあたって必要な作業に集中していればなんとかなる、と思っていたのだが、それだといろんな人たちとの間で本当にコンセスサスが取れたものが作れないし、みんな忙しいから、いつも都合がいいときに内容をチェックして、要望をくれるわけでもない。だから、大規模な商談がまとまりそうになってはじめて「そういえばこんな機能あるよね?」といわれたりする。こういったことは作るコストに含まれていないから、結果的にずるずると金ばかりかかってしまう。

追記:
ギャーッッッッ!!!仕様書が5MBを越えたらWordが落ちて二度と開けなくなっちゃったよ!どうしよう!もう間に合わない!

Posted by on 9月 11, 2007 in Work

コメントを残す