要件定義とか短い局面のスケジュールの切迫感に潰されない計画の立て方

初めてプロマネを担当したプロジェクトの要件定義に手をつけようとセッション資料を用意していたときにふとこれ間違えると拙いことになるな、と思ったのです。

#何も週末の朝からこんな出だしで始めなくてもいいのにねぇ。キーワードというか、神様が降りてきたから仕様がないのです、はい。

具体的なスケジュールに展開しないと切迫感は感じない

局面の打ち合わせスケジュールを会議開催要領(特に頻度と回数と時間)のうち、何回のセッションでシステム要件を整理し、合意しなければならないのかという事実を具体的なセッションカレンダにプロットしたときに、切迫感がね、もうなんと言っていいやら。例えば、2ヶ月で要件定義のスケジュールとしていたとして2時間/週次の開催要領の場合、8回のセッションしか取れないわけです。1回のセッションは2時間ですから16時間。この時間で要件定義で扱うバウンダリを明確にし、検討テーマについて合意し、契約で定めるアウトプットに仕立て上げる必要があるのです。

局面だけのつもりが全体までに

要件定義の局面だけで言えばそれまでですが、プロジェクト全体のスケジュールを捉えれば、全体のスケジュールの中で収まればいいとついつい要件定義のスケジュールのエンドを伸ばしたくなる誘惑に負けそうになりそうです。この時の判断基準を誤るとプロジェクトマネージャ自身が自分でプロジェクトの時間というリソースをドブに捨てようとしているということを思い出さなければならないとジワリと蝕み始めるのですよ。

番組(セッション)を編成する

 要件定義に関わらず、設計の仕様のテーマを並べてみると即決できるテーマもあれば、討議を経て顧客なりエンジニアが要件やシステム制約を理解した上でないと意思決定できないものがあります。

これは別の見方をすれば、セッションになんども掛けるテーマもあれば1回のセッションの枠で合意に到れるテーマもあるということです。

他の要件を制約するものから番組を編成する

エンジニアサイドはどれがどれだけ手間が掛かるかを見極め、8回のセッション枠のどこから検討を始めてどこで終わらせるかを考え、決めなければなりません。

これを何も考えず仕様書の目次の順番に初めてしまうと運用やセキュリティが後回しになり、運用やセキュリティの要件がそれまで検討してきたテーマの仕様をひっくり返しかねないので注意が必要なのです。

これは、その検討テーマが実は他のテーマの制約条件となるために検討する順序自体に制限するということです。

時間の掛かるものから番組を編成する

制約を考慮した上で番組を編成するときには、 時間の掛かるテーマから手配を始めます。もちろん、エンジニアは検討テーマのタイミングに合わせて検討資料を準備しなければなりません。

このセッション枠に検討する具体的な個別テーマを当てはめることはエンジニアサイドにも重要なことで、これはエンジニアの時間軸の感覚に締め切りの意識をあらかじめ持たせる効果があります。

まあ、最終原稿(完成原稿ではないかもしれない)の締め切りを設定するということです。

捕まえにくい関係者の身柄を確保する

 もう一つ。仕様を決める際に誰がステークルダか誰の合意を得ないとやり直しになってしまうかも押さえておく必要があります。通常は、会議開催要領の中での必須出席者として表現されるものですが、意思決定をするロールを担う人が多忙であればポイントでサマリを報告し、了承を得るとか顧客の担当から逐次報告と了解を得てもらうとか工夫が必要です。

意思決定には関わらないけれど、システム上の役割分担として担うセクションの代表に話を通しておかなければ後々の作業に滞りが生じるのであれば、やはりタイミングを見て出てきてもらわなければなりません。