そして要件定義をできるエンジニアはいなくなる

要件定義では要件を決める。少なくともシステム化要件を知らなければ、システム方式や実現仕様に詳細化、展開しようがない。

ところが、システムが何世代も続くと要件定義をせずに、基本設計からとか、詳細設計からプロジェクトが始まることがある。こうしたやり方を繰り返すと開発者のエンジニアサイドに弊害が起きる。

何が弊害となって困るか想像がつくだろうか。

いくつかの改修を繰り返してしばらく経つと、途中から人が入ってくる。特に、大規模なシステムや数年経ったパッケージ開発ではよくあることだ。そうした環境下で中途参画してくるエンジニアが入ってくれば、まず、業務説明をする。

その業務説明では、こんな風に業務は説明される。

『こうなっているので』

『これがこのプロジェクトのルールに決まっているから』

経緯は一切説明されない。

これが拙い。『なぜ』がないのである。

気づきの感性を持っているエンジニアはそこに違和感を覚えるものだ。だから、

『どうしてですか』

『なぜですか』

と素朴に、本当に素朴に質問を投げかけても答えられないことが出てくる。

要件定義を経験した当事者が残っていれば、まだ良いのである。要件定義を定義した経緯を知ってるからその関係者を引っ張ってくればいい。残っているならば。

ところが、いつの間にかエンジニアサイドに一人として要件定義をしたエンジニアが誰もいなくなっていることなんてことになるのである。

その上、エンドユーザ側も誰一人としていなくなる。

そこに残されるのは、要件定義をできないエンジニアのチームである。

嘘だと思うかもしれない。

でも、周りを見て欲しい。そう、今座っている席で同じチームのエンジニアを眺めるのである。

例えば、今担当しているシステムをリプレースすることになったとしよう。グローバル化するので要件定義からすると、エンドユーザの役員からオーダがあった。

さて、誰が要件定義を引っ張ることができるだろうか。

それは周りの誰か。

それともあなた自身か。

要件定義をする実力がないことがバレたとき、他のベンダに乗り換えられるのである。