全2637文字
PR

 互いに思いは同じなのだが、立場の違いによりそれぞれが逆の方向に向かってしまうことがある。システム開発において、それはしばしば発生する。

 要件定義をどのように進めていくかを検討する、プロジェクトのキックオフでのことである。プロジェクトに参加するエンドユーザーから「要点定義が遅れたらどうなるのだろう。1カ月の延長とかはしてもらえるのか」と質問が出た。

 このプロジェクトの要件定義期間は3カ月で契約されていた。要件定義終了時に開発スコープと見積もりを確定させて以降のフェーズに進むという、よくあるスタイルの契約である。要件定義の進め方は週2回の頻度でエンドユーザー部門にヒアリングを実施し、洗い出された要件の検討と整理を行っていく計画だ。

 このエンドユーザーは素朴な疑問として「週に2回の打ち合わせを欠かさずにできるのか。プロジェクトに参加するからといって定常業務が減るわけではない。ただでさえ忙しいのに、毎週やりきれるかな」と感じたらしい。

 さらに、このエンドユーザーは要件定義の主要メンバーとして参加するのは初めてのため、それがどのように進められ、どのようなプロセスで要件が固まっていき、そして自分が何をやりどんな責任があるのか、キックオフの時点で理解しきれていなかった。「自分が何をするのよくわかってないのに、期限を切られて大丈夫か」という不安もあったのだろう。

 エンドユーザーの懸念含みの質問に対して、ベンダーのプロジェクトマネジャーは胸を張って答えた。「要件定義は必ず予定通り3カ月でやります。遅れるようなら、週2回の打ち合わせを3回、4回と増やしてでも対応し、スケジュールをキープします」と。ベンダーの立場からすれば、なんとしてもスケジュールをキープするという姿勢は正しい。ましてやキックオフミーティングの場である。プロジェクトマネジャーが「私にお任せください」と立ち振る舞うのは頼もしいとさえいえる。

 しかし、この質問の意図と回答はまったくかみ合っていない。

 週2回の打ち合わせでさえ履行できるかどうかが不安で質問しているのに、回数を増やすという答えは期待とは真逆である。このエンドユーザーは内心思ったかもしれない。「こちらは業務多忙だから不安で質問したのに、打ち合わせの回数を増やすってドヤ顔で言われてもね。ユーザーのこと何もわかっていない。もし遅延したら、ユーザーがサボって遅れたのだからと責任をこちらに“丸投げ”するわけか」。

 一方、ベンダーのプロジェクトマネジャーも表面上はにこやかに答えていても、心中は穏やかではなかったかもしれない。「キックオフの日から要件定義を1カ月延ばせるかとは何を考えているんだ。打ち合わせの回数を増やすのは我々にとっても負担が大きいが、それでもスケジュールキープのために背に腹は代えられない。そもそも要件定義はユーザーが主体的にやる作業だ。延ばしたってどうせ追加費用は出すつもりはなく、なあなあでやってほしいってことだろう。発注者の責任をこちらに“丸投げ”されても困る」。