（本記事はBizauthが提供する「BA BLOG」から転載、編集しています）
どうして要件定義は失敗するのだろうか。その対応方法を考える前に、失敗の要因について列挙していこう。
要件定義の失敗は、作成段階で分かることもあるが、その作業自体をごまかして進め、後に失敗が発覚するということが多い。詳細設計やシステムテストなどの工程で失敗かどうか判明するのだ。つまり、要件定義がまだ終わっていないのに、既に終わったものとして前に進めてしまったり、間違っているのに検証することなく進めてしまったりすることで後工程で問題が噴出する。
これは言うなれば、主要な要件を決めていないということだ。仮置きを行って前に進むということになる。要件定義を行う際には、ユーザー部門にも参加してもらい、どういう仕様にするかを決めることに主眼を置く。しかし、ユーザーでは判断できない部分が残るケースもある。それなりに発言力のあるシステム開発のプロジェクトマネージャーがいれば、「決めてください」と言うことができる。
だが、ユーザーも「自分には決められない」と大きな問題にぶち当たることも多い。例えば、「商品の箱詰めのパターンを制限する」「配送時間を3回から2回に変える」「請求限度額を顧客の与信に応じて制限を加える」といったように、複数の部門にまたがるものやシステム開発に伴って別の変更が生じるようなもの、多かれ少なかれ業績に影響が出るようなものは、その代表例だろう。
多くの組織やユーザー、顧客、取引先に影響があり、自分が決められる範囲を超えていると分かれば、二の足を踏んでも当然だろう。プロジェクトの運営委員会としてステアリングコミッティなどを編成して、幹部層で議論をしてもらえるように体制を組むことは半ば常識化している。しかし、ステアリングコミッティもそうそう頻繁に開催できるものではない。その運営だけでも結構な手間となってしまうし、仕様を一つひとつ検討することなど現実的にはできるものではない。結果として、結構な数の重要課題がプロジェクト終盤まで残ってしまう。
また、技術構成やサイジングについては、そもそもユーザー側で分かる人が少ない。仮に分かる人がいたとしても、部門内で発言力があるとは限らない。結果的に、ITベンダーに提案を持ってきてとお願いすることが多いのであるが、少し手もコストを下げたいと思って削りに削ってスレスレの構成を持ってくることが多い。
「大丈夫か？ これで問題なく動くのか？」と確認するものの、詳しいわけではないのでその他の手立てもない。先方とて「大丈夫じゃありません」というわけにはいかない。それが後でどういう問題を起こすかはうすうす分かっている。その場をしのいで何とか受注しておけば、次のビジネスチャンス（＝問題の噴出）につながるのだ。
上述のケースよりもっと多いのは、現行の機能やデータが適切に反映されないというものだ。トップダウンでシステム化を進める際に陥ることが多い。既存プロセスをそのまま置き換えてしまうと、膨大な規模になることが分かっているため、ゼロベースで新たなプロセスを作ろうと考える。そうすると、具体的な仕様や機能、データの不足が顕著になってしまい、後続のシステムでは機能開発ができないという事態が起きてしまう。
この問題の奥には個別化の問題がある。顧客や事業所の個別仕様が積み重ねられ、膨大なロジックが個別に組まれている場合、これらを標準化するというスローガンを掲げたとしても、いざとなると決断する勇気が出ず、ビジネスモデルの転換を意味しているわけなので、ユーザー部門とシステム部門だけでは決められない。
しかし、プロジェクトは進めなければならない。そのため、現状を刷新する方向で動くのだが、度重なる人事異動や仕様変更を把握している人がどこにいるのか見当もつかない。結果的に、テストで潰すとか、プログラムをそのまま移行するとか、何とか影響が少ない方法で構築しようということになる。しかし、本当のところ、それでできるか分からないのだ。
こうしたことだけではない。パイロット開発をやろうと要件定義を進めていったのはいいものの、全くそれが機能せず要件が永遠に深まり切らない。ユーザーが提案してきたパッケージ製品に業務用件を当てはめていくと、本来のやりたいことが全くできないと分かり、システム機能が膨大になっていく。とにかくスピード重視の開発を求められ、少々の利便性を犠牲にして開発をしようとしたところ、ユーザーの業務量がそれなりに増えることが分かり、大きなやり直しを強いられる。システム開発などそうそうない機会なので、これまでためにためてきた事柄を一気に実現してもらおうと膨大な要件を持ってくる、といったことがある。
失敗には相当のパターンが存在している。これが一つだけ悪い、こういうことが悪い、というように問題点を非常に特定しにくい。経営全体が何か一つだけ悪いということがないように、要件定義も何か一つだけ悪いということもない。経営が経営者、従業員、戦略、組織、業務プロセスといった総合的な施策の集合を考えなければならないように、要件定義力の回復も、本来的にはリーダシップ、体制、進め方、検討方針といった総合的な対策を施さなければならない類のものである。
ただ、一つだけ言えるのは、要件定義という仕事は、非常に難易度が高いということだ。システムの重要性や規模によって難易度は変わるが、そうそう簡単に済むようなものではないということだ。求められるものは高度なバランスであり、やりたいこと、コスト、変化の影響、実行の難易度など、難しい変数を勘案して、落とすべきところに落とす作業である。高度な政治感覚も、平衡感覚も求められる、非常に高難度の仕事なのだ。
もちろん、世の中で言われている要件定義のセオリーについても、精通しておいた方がいいに越したことはない。「業務フローをしっかりと書く」「入出力をしっかりと定義する」「データをしっかりと定義する」――こうしたセオリーは、システム化の基礎中の基礎なので、本来的に重要なことをきっちりとこなせるようになっておきたい。
しかし、本来的に政治的要素が多い仕事なのだ。経営の利害、ユーザーの利害、それぞれの人の思惑、受注側であるITベンダーのビジネス上の思惑、そうした非論理的なものが多く入り込んでくる作業なのである。当たり前に標準化など、できるはずがないものだ。
- 宮本認(みやもと・みとむ)
- ビズオース マネージング ディレクター
- 大手外資系コンサルティングファーム、大手SIer、大手外資系リサーチファームを経て現職。17業種のNo.1/No.2企業に対するコンサルティング実績を持つ。金融業、流通業、サービス業を中心に、IT戦略の立案、デジタル戦略の立案、情報システム部門改革、デジタル事業の立ち上げ支援を行う。
