要件定義を行う最中には，ちょっとした問題でマゴマゴしてしまうことが往々にしてあります。なかなか解説書の通りにはいかないものです。今回は，そんな“マゴマゴ”に手が届く，要件定義の「マゴの手」をご紹介します。
なお，ここでは，要求をヒアリングする対象の人を「ユーザー」としています。ユーザー企業の情報システム部門にとっては，「ユーザー部門」の人であり，SIerにとっては「顧客」に相当します。
■よくあるマゴマゴ
「ユーザーからスケジュール通りに仕様が出てこない！」
よくありますよね。早く決めて，次の作業へ進みたいのに，なかなか出してもらえない。でも「早く出してください！」の一点張りではらちが明きません。そんなときは，このマゴの手で行きましょう。
|
|
| マゴマゴしてしまう問題にぶつかったらコレ！ （という便利な道具はないけれど…） |
解決！マゴの手：
【こちらから出す】
例えば，外部委託で開発を行う場合，開発を請け負った側は，必ずしもユーザーから仕様が出てくるまでひたすら待つことはありません。ユーザーから「仕様」が出てこないのであれば，こちらから出してしまいましょう。
●「たたき台」を叩いて
「仕様」にする
このとき大事なことは，こちらから出すモノは確定した「仕様」ではなく，ユーザーが仕様を決めるための「たたき台」である，ということです。
「たたき台」であるからには，この後，叩いていきます。こちらから提示する「たたき台」に含まれた，いくつものアイデアをユーザーと一緒に叩き上げて，「仕様」としてまとめていくのです。
自分が自信を持って出したアイデアが，目の前で叩かれてしまうのは，とても辛いことです。しかし，プロジェクトにフィットするように叩いているのであって，そのアイデア自体を否定しているわけではなく，もちろんアイデアを出した人を憎んでいるわけでもありません。このことは，ユーザーにも，こちら側にも，もちろん自分自身にも言い含めておく必要があります。
自身を持って叩き，叩かれましょう。
叩き上げ作業は，ユーザーとこちらの双方にメリットがあります。ユーザーとしては，頭にある漠然とした要求を，ゼロからこちら側に伝えるよりも，目の前にある「たたき台」に手を加えていくほうが，ずっとパワーが少なくてすみます。
こちらとしても，ユーザーの要求が伝わりやすく，理解しやすくなります。加えて，今どこを決めて欲しいのか，具体的にユーザーに示すことが出来ます。
「たたき台」に数字が書き込まれていれば，ユーザーはそれを見て“今この数字を決めないといけないのだな”ということがわかります。さらには“この数字を決めるなら，こっちの数字も出しておいたほうがよかろう”と，こちらの気がつかないところまで連鎖的に出してもらえるようになります。
●イメージを膨らませやすい「たたき台」にする
ユーザーから連鎖的に仕様が出てくるかどうかは，「どれだけ具体的に仕様をイメージしやすいか」にかかっています。「たたき台」を見て具体的に「仕様」をイメージできると，それによって周りが見えてきます。ユーザーは周りが見えてくることで，連鎖的に周りの仕様も出しやすくなるのです。
そのため「たたき台」に求められる品質は，「ユーザーに有無を言わせない完璧な品質」ではなく，「ユーザーがそこから具体的なイメージを膨らませられる品質」であることが大切です。
●業務の流れと既存システムを知る
具体的なイメージを膨らませるには，ユーザーと共通した価値観を土台としなければなりません。とはいえ，価値観は一朝一夕に培われるものでもありません。
ユーザーの価値観を知るために有効な手段は，業務の流れと，既存システムを知ることです。現状の業務の流れを知ることは，ユーザーの仕事に対する価値観を知ることにつながります。そこに既存システムがあれば，より具体的にユーザーの仕事をシステムに結び付けて理解することができます。
既存システムの仕様書や設計書があるとなお良いのですが，多く場合，それに期待してはいけません。ドキュメントが揃っていないどころか，もし仮に見つかったとしても，メンテナンスされておらず，実際に動いているものと異なることが多くあります。そのため，仕様書や設計書は参考程度と考えて，実際に動くモノを見ることが大事です。
さらに，ユーザーの業務や，既存システムを理解するためには，ある程度の業務知識を身に付けておかなくてはなりません。とうていその分野では，ユーザーには及びませんから，スカウトされるほどの業務知識を身に付ける必要はありません。最低でも，その分野の書籍を1冊は読んでおきましょう。読む書籍は，ユーザーに聞くのが一番です。お勧めの書籍を聞けば，ユーザーも喜んで教えてくれるでしょう。
●ユーザーの中に「船頭」は一人
「たたき台」を出し，実際に叩き始めたものの，「仕様」の確定にたどり着かない──そんなとき，「たたき台」叩きに参加しているユーザーが，仕様の確定に関して，完全に権限を有していないケースがあります。
ユーザーの中に舵をとる「船頭」がいないようでは，一向に岸にたどり着けません。かといって，こちら側で決めてしまうわけにもいきません（こちら側で決めた仕様は，たとえユーザーから委ねられたとしても，後日，必ずと言っていいほど覆されてしまいます）。
もし「たたき台」叩きの参加者に「船頭」がいない場合は，より「偉い人」に訴えかけましょう。「船頭」に「たたき台」叩きへ参加してもらう，あるいは，参加している誰かに「船頭の権利」を与えてもらうのです。
よほど小さなプロジェクトでない限り，ユーザー側の要件策定者は複数人います。また，できあがったシステムを実際に使用するエンドユーザーは，ユーザーと異なる場合が多いでしょう。よくよく見てみると，ユーザーやエンドユーザーなど，複数の人が舵を握っていることがあります。
「船頭」が多くては，いない場合と同様に「仕様」は確定しにくくなります。また，覆されやすくもなります。ユーザーに話し合ってもらい，一人に舵を渡し，みんなの要求を一つにまとめてもらいましょう。
●ユーザーにスケジュールを意識してもらう
舵とりが出来れば，後はスケジュールを意識してもらうだけです。
要件定義の段階は，プロジェクト全体の期間から見ると，まだまだ始まったばかりで，先は長く，時間がたっぷりあるように感じてしまいがちです。そのため，要件定義の初期の段階では特に，全体のスケジュールよりも，直近の具体的な日付を提示することで，スケジュールを意識してもらいやすくなります。
「たたき台」を“○○日までに叩き上げるために，このあたりは来週火曜日までに叩き終わらなければならない”といったように具体的に示すことが大事です。
さて，スケジュールを意識しながら「たたき台」を叩き上げていけば，なかなか出てこなかった「仕様」が目の前でできあがっていく過程を見ることができるでしょう。
では，良い要件定義を。
| （梅澤 真紀＝要求開発アライアンス） |
