「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。
なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。
勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。
失敗につながる要件定義の実態
DX（デジタルトランスフォーメーション）のためか、事業環境の変化や既存システム老朽化への対処か。あるいはアプリケーションやサーバーの更新時期が来たのか、社長や事業部長が交代したからか。理由はともあれ、企業情報システムを更新する際に要件定義から始める企業や団体が多い。お金を出せる組織であればコンサルティング会社を入れ、そこまでお金を出せない組織であればコンピューターメーカーやソフト開発会社を呼んで要件定義を支援してもらう。
やってきたコンサルタントやSE（システムエンジニア）は更新対象となる情報システムを使う複数の部門の担当者と面談する。そして「今後事業をどの方向に進めるのか」「困っていることは何か」「現状の情報システムで直したい点はあるか」などを質問する。出てきた回答を整理し、新システムの全体像やそこに盛り込む要件をまとめてくれる。
特段の問題はない進め方のようだが、その結果は現状とあまり変わらない情報システム像だ。それぞれの担当者が指摘した課題には対処されているものの、小改善の積み重ねにとどまる。トランスフォーメーションとはとても言えない。「要件定義をやめよう」と喝破した参加者は「高度成長期に業務改善で日本企業は成功した。この体験から抜け出せないことが今の日本の沈滞を招いた」とも語っていた。
情報システムの要件がさほど変わらないなら、要件定義にかけたお金と時間ははっきり言って無駄である。情報システムの現状を正確に反映した文書があれば、その内容を改定するだけで済んでしまう。実際には既存システムに加えられた変更をきちんと記録している組織は少ない。かなりのお金と時間をかけて、かつての要件定義書を改善するはめになる。
ERPパッケージソフトの場合、SEではなくコンサルタントを使う習わしがある。別のERPパッケージやアーキテクチャーが違う新版に乗り換える場合、コンサルティング会社からコンサルタントがやってくる。質問し、要件をまとめ、それとパッケージに合うかどうかを確認する。いわゆるフィット＆ギャップ分析だ。
ERPパッケージを今使っているということは、10～20年くらい前に苦労をして導入したはずだ。利用する側の責任者や担当者、導入を支援するコンサルタント、いずれも交代しているだろう。過去の経緯と経験が引き継がれていない。要件定義をやり直し、合う合わない、業務を変えるべき、パッケージをカスタマイズすべきといった、過去とほぼ同様の議論を繰り返す。議論して出てくる結果は、今使っているERPパッケージによるシステムに反映されていることばかりである。
