2017.11.24

要件定義力を徹底的に再構築する：③難易度の高いIT部門の仕事の中でも最も難易度の高い業務

難易度の高いIT部門の仕事の中でも最も難易度の高い業務

では、なぜ要件定義は、失敗するのであろうか。対応を考えていく前に、要件定義の失敗について列挙していこう。

要件定義の失敗は、要件定義段階でわかることもあるが、要件定義をごまかして進め、後に失敗していたと発覚することの方が多い。詳細設計段階、システムテスト段階など、後工程で失敗かどうかわかってくる。すなわち、要件定義がまだ終わっていないのに、要件定義は終わったものとして前に進めてしまったり、要件定義が間違っていたのに、検証することなく進めてしまうことで、後工程で問題が噴出する。
要件定義が終わっていないというのは、言うなれば主要な要件を決めていないということだ。仮置きを行って、前へと進むこととなる。要件定義は、ユーザー部門にも参加をしてもらって、どういう仕様で行くか決定してもらうことを主眼とするが、ユーザーが決めることが出来ない仕様が残っている状態である。それなりに推進力を持っているシステム開発のPMがいるならば、「決めてください」と言うことができる。しかし、ユーザーも「自分には決めることが出来ない」大きな問題にぶち当たることも多い。例えば、商品の箱詰めのパターンを制限する、配送時間を3回から2回に変える、請求限度額を顧客の与信に応じて制限を加える。。。といった、いくつかの部門に渡り決定しなければならないようなものや、付随する修正が結構生じるようなもの、業績の上下が多かれ少なかれ生じるようなものは、代表例だろう。
多くの組織やユーザー、顧客や取引先に影響があり、自分が決められる範囲を超えているとわかれば、ユーザーは二の足を踏む。ステアリング・コミッティなどを編成して、幹部層での議論をしてもらえるように体制編成することは半ば常識化してはいるのだが、ステアリング・コミッティはそうそう数を開催できるものではなく、その運営だけでも結構な手間となってしまうので、仕様を一つ一つ検討することなど、現実的にはできるものではない。結果として、重要課題がプロジェクト終盤までに結構な数が残ってしまう。

また、さきほど、技術のところで技術構成やサイジングが違うことがあるとも書いたが、技術構成やサイジングはそもそもユーザー企業ではわかる人が少ない。仮にわかる人がいたとしても、部門内で発言権がない人が多い。結果的に、ベンダーに提案を持ってきてとお願いすることが多いのであるが、ベンダーも少しでも値下げをしたいと思い、削りに削ってスレスレの構成を持ってくることが多い。「大丈夫か？これで問題なく動くのか？」そう確認はするものの、詳しいわけではないので確認する手立てもない。ベンダーとて、「大丈夫じゃありません」というわけにはいかない。「大丈夫です」と答える。それが、後でどういう問題を起こすかは、薄々わかっている。その場をしのいで、何とか受注し、次につなげておけば、なんとか次のビジネスチャンス=問題の噴出につながるのだ。

そうしたケースよりももっと多いのは、現行の機能やデータが適切に反映されない場合だ。これは、トップダウンでシステム化が進むケースで多いのだが、現状をそのまま置き換えてしまうと、全くもって膨大なシステムになることが分かっているので、現状リプレースで考えるのではなく、新たなプロセスを作ろうという、ゼロベースのアプローチをとってしまった場合には、具体的な仕様や機能、データの不足が顕著になってしまい、後続のシステム機能では開発が出来ないということが起きてしまう。
この問題の奥には、個別化の問題がある。顧客の個別仕様、事業所の個別仕様、こうした積み重ねで膨大な個別ロジックが組まれている場合は、個別化は標準化するというスローガンを掲げたとしても、いざそれを決定するとなると、決定する勇気・決断はシステムの仕様のレベルを超え、ビジネスモデルそのものの転換を意味しているわけなので、ユーザー部門とシステム部門だけでは決めることが出来ない。しかし、プロジェクトは進めなければならないので、現状をリプレースする方向で動くのだが、度重なる人事異動や仕様の変遷等を分かっている人というのはもうどこにどれだけ分散しているか、検討もつかない。結果的に、テストで潰すとか、プログラムをそのまま移行するとか、なんとかインパクトが少ない方法で実現しようということとなる。しかし、本当のところ、それでできるかわからないのだ。

こうしたことだけではない。パイロットアプローチでやろうと、要件定義を進めていったのはいいものの、全くパイロットが機能せず、要件が永遠に深まり切らない。。。ということもあるし、ユーザーが「これでやりたい」ともってきたパッケージが、いざ、業務要件をきちんと当てはめていくと、入力や参照用データの抽出で、全くユーザーのやりたいことが出来ないということがわかり、システム機能が膨大になっていくとか、兎に角スピード重視の開発などと言われ、少々の利便性を犠牲にして開発をしようとしたところ、ユーザーの業務量がそれなりに増えることが後でわかり、大きなやり直しを強いられることとなるといったことや、システム開発なんてそうはない機会なので、これまでやってもらいたいと思ってきた事柄を、これを機に一気に実現してしまおうと膨大な要件を持ってくることなどをしたりする。

失敗には相当のパターンが存在している。これが一つだけ悪い…こういうことが悪い…ということが、非常に特定しにくい。経営全体が、何か一つだけ悪いということがないように、要件定義も何か一つだけ悪いということもない。経営が経営者、従業員、戦略、組織、業務プロセスといった総合的な施策の集合を考えなければならないように、要件定義力の回復も、本来的にはリーダーシップ、体制、進め方、検討方針といった総合的な対策を施さなければならない類のものである。

ただ、一つだけ言えるのは、要件定義という仕事は、非常に難易度が高いということだ。システムの重要性や規模によって難易度は変わるのではあるが、そうそう簡単に済むような仕事ではないということだ。求められるものは、高度なバランスあり、やりたいこと、コスト、変化の影響、実行の難易度など、難しい変数を勘案して、落とすべきところに落とす作業である。高度な政治感覚も、平衡感覚も求められる、非常に高難度の仕事なのだ。
もちろん、世の中で言われている要件定義のセオリーについても、精通しておいた方がいいに越したことはない。業務フローをしっかりと書く。IOをしっかりと定義する。データをしっかりと定義する。こうしたセオリーは、システム化の基礎中の基礎なので、本来的に重要なことをきっちりとこなせるようになっておきたい。
しかし、本来的に政治的要素が多い仕事なのだ。経営の利害、ユーザーの利害、それぞれの人の思惑、受注サイドであるベンダーのビジネス上の思惑、そうした非論理的なものが多く入り込んでくる作業なのである。当たり前に標準化など、できるはずがないものだ。