この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前々回(「客観的なデータ」は幻想、定量データは必要悪)と前回(パターンが見えたと思ったら危険、「再現性」の追求はNG)は、「数字」に振り回されずに現場での調査結果を整理・分析するためのポイントを取り上げた。

 今回と次回では、暗闇プロジェクトに役立つ要件定義の進め方を紹介する。この種のプロジェクトでは要件を創作し、合意していかなければならない。今回は、要求仕様に関する二つのセオリーを紹介する。

セオリー1
用語の定義はほどほどに

 システム構築プロジェクトの要件定義の段階で、用語の定義が大切なのは言うまでもない。「仕様変更」という言葉一つを取っても、「どこまでを仕様とみなすのか」「何をもって変更とするのか」を統一しておかないと、意思決定やコミュニケーションに支障が生じてしまう。

 ただ、用語を定義していく作業は時間も費用もかかる。細かく定義しようとするときりがなくなり、メンバー同士の関係がかえって悪化する恐れもある。まして先が見えない暗闇プロジェクトでは、用語の定義はほどほどにしておくことが大切になる。これが一つめのセオリーである。

 ルールを細分化しすぎたり、用語を正確に定義しようと時間をかけすぎたりすると、プロジェクトの生産性に大きく影響するので注意したい。

「これは仕様変更ではないだろう?」

 IT企業X社に所属するA氏。若手ながら、あるプロジェクトのマネジャーを任された。A氏はX社の中でも優等生で、プロジェクトマネジメントの勉強はばっちり。仕様変更のプロセスも教科書通りにきちんと定義しており、ユーザーとは事前にルールに関する認識合わせを行っていた。

 ところがA氏の努力は報われなかった。ユーザーからの仕様変更の嵐で散々な目に遭ったのである。