【第64回】「要件」という蜃気楼（１）

さて、今度は上流工程の話を。

ビジネス系情報システムの構築において、最初に行う工程は「要件定義」です。

これから作るものの「要件」を「定義」する。つまり「何をつくるのかの大まかな形」を最初に決める工程ですね。

最も難しいと言われる工程です。

当社は小さいながらも顧客と直接打ち合わせを重ねながら情報システム構築を進めます。

そのため、業務範囲や開発規模こそ小さいものの、工程的には「要件定義」から業務スタートすることが多いです。

会社設立から二十数年。これまで行ってきた「要件定義」も数十件になるのではないでしょうか。

で、ですね。

これまでの経験から言わせてもらうと。

「要件がすべて正しく定義できた」ことなど、ただの一度もありません。（笑）←笑いごとか？？

だって、これから構築する情報システムが完成時に実現すべき「要件」など、誰に聞いても本当のところはわからないのですよ。まだ何も見えていないし。

だから、最初のうちはかなり大風呂敷を広げ、抽象的な表現に終始せざるを得ません。

工程が進むにつれ、徐々に具体的な姿に落とし込む必要がありますが、そうなればなったで「実現可能性」や「費用対効果」など、夢物語を阻害する要素が入り、開発機能の優先順位付けにはセクショナリズムが絡んできます。

挙句の果てに、成果物の提出期日が迫るにつれて、あとからあとからどんどん出てくる追加要件の数々。

これ、当社の手が届かないような大規模プロジェクトなら、なおのこと頻発する事態でしょう。

えっと、ですね。

昨今の私はもう、

「要件をもれなく正しく定義することなど不可能という前提」

に立つべきではないか、とすら考え始めています。

極論すると、「定義すべき要件が（目に見えないけど）そこに存在している」と言うこと自体が実は幻想なのでは、と。

とは言え、「そうはいっても要件定義しないと仕事が始まらない」というのもまた事実でして、だからこそ「情報システム構築は難しい（失敗が多い）」と言えるわけでして。

（続く）