人材バンクの案件。私が数日前まで夜更かし連発で制作した画面仕様書を元に、プログラムのアウトソーシング先からデモ画面が提出された。このデモ画面はまだプログラムは組み込まれていないものの、ブラウザ上で実際の画面の動きが確認できるものである。

クライアントにとっては紙ベースの画面遷移図より、完成形がイメージしやすい。
しかしこのデモ画面だが、私の作成した画面仕様書から予算的にオーバーしてしまう機能を削っていますとのことだった。予算的にオーバーするのであればもう少し早く連絡が欲しいところだが、ある程度予測していたことなので冷静に次の手を考えることができる。

とにかく、このデモ画面を本日夕方にクライアントに説明するのだが、見積のベースとなっている要求定義書の内容は絶対に満たしていなければならない。

こういうチェックを行なうときに、準備してきた要求定義書、画面遷移図、画面仕様書が非常に役に立つ。これらのドキュメントに沿ってチェックすればいいのだ。

要求定義書の内容を満たしていない部分は必ず修正してもらい、画面仕様書の内容を満たしていない部分については、予算オーバーの説明を受けていない個所について、説明を要求し、必要に応じて修正してもらう。

昨日はほぼ一日中、このチェックに追われた。なんとか本日クライアントに説明する準備ができたところである。予算オーバーの部分については、当面は無くても支障がないと思われるので、公開後に運用状況の様子を見ながらバージョンアップしていく方針を薦めたいと思っている。

こんな時間にまだ起きている理由は、この人材バンクの案件ではなく、ガーデニング材、建材を扱っている会社サイトの作業が詰まってきているためである。こちらのサイトはスケジュールどおりにはなかなか進んでいない。

サイト公開はまだ1ヶ月先なのだが、今月末に請求を出すためにある程度形にして、先方の担当者が上司に説明しやすい状況にしておかなければならないのである。

今日はコミュニティサイト関連の書評シリーズはお休みにして、私の今の状況を残しておくことにする。

最近たびたび話にでてくる、コミュニティサイトの打ち合わせがあった。

要求定義書、簡単な画面遷移図を作成したあと、クライアントの想像力を点火したような感じだった。あれもしたいこれもしたいという状態で、要望が膨らみすぎてしまった。

予算的に可能な範囲はすでに超えていると思われたので、膨らんだ要望と私のさらなる提案も含めて、プログラムのアウトソーシング先に見積もりをお願いすることにした。このまま綿密な打ち合わせによって膨らんだ要望を仕様書にまとめても、見積もりで予算をはるかにオーバーしてしまっては、モチベーションが下がってしまう。

夢を語っているときに現実的な問題を突きつけられ、自分たちの議論が文字通り夢物語になってしまうようなものだ。

見積もり結果
「小林さん、この機能をすべて実現するとなると○百万円になってしまいますよ。」

遙かに予算オーバーであった。そこで、コミュニティを機能させ、他サイトと差別化をはかるための【必要最小限の機能】に絞り、再度数社に見積を依頼したのだ。

その結果、ようやく現実的な予算に収まった。
その中でも、今回は新しい取引先にお願いすることで話が進みそうである。

まずは必要最小限の機能で構築し、ユーザーを集め、ユーザーの声を聞きながら機能を充実させていくという方向で、クライアントには納得していただいた。

アウトソーシング先への発注段階になったので、仕様書を作らなければならない。仕様書とはサイトの設計図である。

機能リスト、機能ごとの画面遷移、全体の画面遷移、ユーザークラスの定義（サイトを使用するユーザーの分類）、そのユーザークラスがどの機能を使用できるのかを示したリスト、サーバー条件、仕様書に出てくる専門用語解説、これらのことを網羅した「要求仕様書」というものを作成した。

発注前の段階でここまでの資料を作成したのは、今回が初めてである。
今までは大まかな見積もりをもとに発注後、クライアントとの間で仕様を決め、その仕様をアウトソーシング先に渡していた。

この流れには大きな問題があった。アウトソーシング先が思い描いていた機能と、こちらが提出した仕様書の機能のギャップである。こちらは大まかな見積もり依頼時に提出していた概要を具体化しただけだと思っているのにだ。

「この部分は別途お見積もりとなります。」
こんなことを言われることもあった。もともとギリギリの予算なので、別途見積もりなどできない。かと言ってクライアントに予算オーバーですと言うのも恥ずかしい話である。それは、いくらで構築しますとクライアントに言ってしまった後に、クライアントと一緒に仕様を作ったからである。

その仕様が予算オーバーってなんでやねん。ということだ。

アウトソーシング先とのギャップを埋めるために
「発注前にできるだけ仕様を固めておき、それを具体的にドキュメント化しておく」というのは、大きな課題だったのだ。

さて、本日クライアントとの打ち合わせにて、こんないきさつで制作した「要求仕様書」は無事、承認を得ることができた。事前に仕様書を提出していたのだが、内容的に難しいので、イチから説明が必要かなと思っていた。しかし、クライアントは読むだけで内容がよく理解できた、よくできていると言ってくれた。

ドキュメントは読むだけで理解できなければならないものだと、以前の職場でたたき込まれた。その訓練の成果は今でも身に染みついているようだ。

今回の承認をもって、来週にはアウトソーシング先と打ち合わせを行う予定である。

年末ギリギリまで仕事は続く。