要件定義のタイムマネジメント

様々なプロジェクトをレビューする立場でときどき見かけるケースが「このプロジェクトの要件定義、月末でだったよね？終わせる気があるの？」と思ってしまうことが多いです。
プロジェクトがウォーターフォールなら計画駆動なわけだから、立てた計画どおりに進まなければ先行き大変なことが目に見えて予見できます。誰もがわかっていることなのに、本当にわかっているのかなぁと疑わざる得ないような日程や進め方をしているプロジェクトマネージャを見かけると、要件定義のタイムマネジメントを知らないか意識していないのかなぁ、と。

要件定義が終わらない！
要件定義ですから、顧客要件をシステムの機能要件と非機能要件を基本設計にインプットにできるように整理分解したり、開発環境やステージング環境のスケジュール化などの環境に纏わる日程や人の手配、移行での協力調整などもろもろ付帯作業の準備をしたりしなければなりません。
＃もち、契約の範囲に依りますけど。

で、プロジェクトが躓くのは大体はじめの要件定義にその原因があるものです。その原因も、技術的な問題よりも、間違ったものをつくるか、間違ったやり方で進めるからということの方が多いです。その間違える原因の中のうち、“間違ったやり方で進める”ことの本当の原因には、やることが沢山あるのに時間軸、つまりタイムマネジメントに気を配っていないというものがあります。

決められた、いや、プロジェクトマネージャ自身が決めた時間の中での作業は、プロジェクトマネージャ自身がそのシナリオを描いているわけですから責任を負っているのに、そのやり方が間抜けならどう足掻いても上手くいくわけがないのです。
決して祈っても女神は微笑まない。やることをやりきったプロジェクトマネージャだけに女神は微笑むかもしれない、のです。

要件定義で何をするのか
先のレビューアの立場で見ると、要件定義の期間に対する作業の配分がどうもおかしい。期限に対していかに守ろうとする気持ちがルーズになっているのか、それとも、根拠のない出来るはずだというお花畑のような思考をしてしまっているのか。

大雑把に整理すると、要件定義では、顧客要求からシステム要件を抽出して整理すればいいだけ(表1)です。しかし、忘れがちなことがあってそれが付帯作業でまとめてある環境、試験、移行などの作業です。これらの付帯作業は、マスタースケジュールで描いたシナリオを実現するために、はじめから気にかけて必要な手配はしておかなければなりません。例えば、そのシステムをインターネットに繋ぐなら回線工事の手配で1か月から2か月のリードタイムが必要になるからです。

表1

インプット	プロセス	アウトプット
顧客要件 付帯資料	機能要件 非機能要件(運用含め) 付帯作業(環境/試験/移行含め)	要件定義書 付帯資料

要件定義なのでシステムの実現仕様の検討は次工程の範疇ですが、このフェーズで契約した範囲のことのシステムの要件については、顧客と決めていかなければなりません。顧客と決めることも大事なのですが、このプロジェクトを成功裏にリリースするために、顧客が支払う対価に見合う価値を手に入れるためには、これだけの作業を共同で終えなければ手中にすることはできないんですよ、と顧客に知らしめることでもあります。

で、沢山のやることがあるのに要件定義の時間は限られている、と。

時間割を作る
例えば要件定義を1か月でやらなければならないとき、ガントチャートだと1か月の長さでフェーズを表現しますが、WBSに日付を入れてスケジュール化したものも、細かく日程を刻んだスケジュールを見ることは稀です。刻んであっても、日単位よりは1週間単位くらいで緩く表現されていることもあるくらいです。
プログラミングとユニットテストのフェーズだと、割と日単位でスケジュール化することに誰も異議は出さないものですが、要件定義だと、そうならなくて、がーと線を引きたがる。

なぜか。

顧客の要件をすべて知らないから。

顧客の要件を知り、システム化要件に落とすのは、顧客から資料をもらっていたとしても、対面でなぜこのような要件なのか、その要件でどのような業務を機械化したいのか、それを聞き、理解した上で、システムのアーキテクチャの図面を引いたときにシステムとして考慮する事項や顧客にその要件を下げてもらわなければならないことを見つけられるか、など、理解と整理と方針を出すための“考える時間”が必要になるのです。

“考える時間”が必要であることは、もっともな理由だし、当事者であったときでも今でもそれは必要な経費だと、同意し主張するでしょう。

ただ、だからと言って、スケジュールの線をどかんと一本の線を引いていいわけではないのです。プロジェクトが始まれば時計は動き始めます。それは誰にも止められない。
止められないのに、一本のひと月の線だけでいいのか。それでは終わるものだって終わりません。
だから、その中で必要なことを“いつまでに”しなければならないかをプロジェクトマネージャ自身が知るために、時間割を作る(表2)のです。

表2　2013年1月　要件定義日程

日	月	火	水	木	金	土
30日	31日	1日	2日	3日	4日	5日
6日	7日	8日 キックオフ 次回宿題説明(課題1〜3)	9日	10日 第1回個別検討会(課題1〜3) 次回宿題説明(課題4〜7)	11日	12日

その時間割は、「マスタースケジュールでいいじゃない。」と思うでしょうし、日割りまで展開してあるマスタースケジュールでもいいのですが、人の感覚として横長の巻物のようなマスタースケジュールだと、期限にルーズになる傾向が出てくるのです。

横長の巻物のマスタースケジュールより、月極めのスケジュールの方が日頃スケジュール管理ソフトや手帳で見慣れている分、いつまでにこれをやらなくてはと意識を植えやすいメリットがあるのです。

なので、顧客とのプロジェクトの時間を共有するものにマスタースケジュールの他に、日程の表を使うことを勧めます。

時間割からタイムマネジメントを意識する
顧客との時間の共有のメリットを先に述べましたが、本来の目的は、プロジェクトマネージャがプロジェクトを推進する上でのタイムマネジメントを意識させるために使用します。
仮に検討する課題が20あったとして、それをひと月でフェーズをexitしようと思うなら、ひと月をこんな感じに過ごすことになります。

表3　2013年1月　要件定義日程

日	月	火	水	木	金	土
30日	31日	1日	2日	3日	4日 この日と	5日
6日	7日 この日で8日の準備をしなければならない	8日 キックオフ 週次進捗会議 次回宿題説明(課題1〜3)	9日 この日で7日まとめと9日の準備をしなければならない	10日 第1回個別検討会(課題1〜3) 次回宿題説明(課題4〜7)	11日 10日の検討課題が決まらなければ次回の継続検討の資料準備。 15日の検討課題の資料準備。 週次進捗会議の資料の準備	12日
13日	14日　成人の日 休みなので作業できない！	15日 週次進捗会議 第2回個別検討会(課題4〜7) 次回宿題説明(課題8〜10)	16日	17日 第3回個別検討会(課題8〜10) 次回宿題説明(課題11〜12)	18日	19日
20日	21日	22日 週次進捗会議 第4回個別検討会(課題11〜12) 次回宿題説明(課題13〜15)	23日	24日 第5回個別検討会(課題13〜15) 次回宿題説明(課題16〜20)	25日	26日
27日	28日	29日 週次進捗会議 要件定義レビュー	30日	31日 要件定義レビュー(予備)	1日	2日

要件定義レビューの日程、これでもぎりぎりですね。それより、そのぎりぎりにするためにも日々の日程の目一杯の感じが実感できましたか。
月極めの日程に顧客との打ち合わせを入れるだけで、これだけ「うぇー」ってなりますもの。このほか、プロジェクトチームの中でのコミュニケーションも作業指示と予実の確認と遅れたときの対策案とコスト管理と組織の中のレポートも...。

こうやってわざわざ時間割を作るのは手間ですが、この形式の方が人は時間に対する意識が高まるのも事実です。何て言ったって、40日間の夏休みのスケジュールを作っても、宿題に手を付けるのは最後の1週間になってからでしょう。それをプロジェクトでやったらどうなるかは、もう、わかりますね。

だから、こうやって時間割を作りタイムマネジメントを意識するのです。