◆５回のなぜで、シナリオを検証
さて、前述の例で、情報処理をＩＴでスピードアップすると、Ｗｈｅｎが変わり、それが顧客満足や競争力強化に繋がると書いたが、本当にそうだろうか。それで、本当に儲かるのか、ここを５回の「なぜ」を繰り返して、シナリオの因果関係を検証する必要がある。情報処理にＩＴを利用すると「なぜ」スピードアップするのか。スピードアップすると、なぜ、Ｗｈｅｎが変わるのか。Ｗｈｅｎが変わると「なぜ」顧客満足が得られるのか。顧客満足が得られると「なぜ」儲かるのか。
このように、原因（システム要件）～結果（儲け）に至るまでのシナリオを充分に掘り下げ、そこに矛盾や飛躍が無いか、検証する。こうすることで、ビジョン実現に対して、システム要件自体が目的化してしまったり、ムダな要件が入り込むことを防止する。あくまで、「儲ける」ことが最終目的であり、システム構築することが目的ではない。そこを、忘れてしまい、儲けに繋がらない要件を盛り込みすぎて、システム構築費用が膨れ上がったり、人間系がやるべきプロセスまで、システム要件としている例が少なくない。また、実際の運用段階で、シナリオどうりにシステムが機能せずに、儲けにつながらず、効果が生まれないという例もある。
前述したように、くれぐれも「システム構築の為の、システム要件」、問題解決ではなく、「解決問題」としての、ソリューションとならないように注意が必要である。今一度、前述の「最小の投資で最大の効果を生むシステム戦略」を読み返していただき、必要最低限のシステム要件を定義していただきたい。ここまでの段階での失敗が原因で、プロジェクトが暗礁に乗り上げるケースが実に多い。調査によると、ＩＴプロジェクトの２／３が失敗しており、その内の原因のトップを占めるのが、企画～要件定義における失敗である。逆に、成功事例での、要因の半分は、要件の明確化と適切な管理である。
最近では、この要件定義に時間をかけず、最初から「要件は分からないもの」として、プログラムを早急に作りながら考えようという傾向もあるが、しかし、「最小の投資で最大の効果を生む、儲かるシステム」を構築したいのであれば、ここを安易に流すべきではない。徹底的に知恵を絞り、考え抜くべきところである。それが、できなければ、ＩＴ業者の言うがままに、追加開発を止め処なく繰り返し、良いカモにされても仕方がない。要件定義に時間をかけ、知恵を絞らないシステム構築は、ＩＴ業者にとってこそ「儲かるシステム」であっても、決して、あなたが「儲かる」システムにはならない。これは、パッケージソフトを利用する場合であっても同じである。
コメント