経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。

　野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。

　前回（第13回）は、ERP（統合基幹業務）システムなどのパッケージソフトを「ソリューション」と呼んで担ぐシステム会社はどんな付加価値を提供しているのか、という疑問について説明しました。

　私が“システム屋”と呼ぶIT（情報技術）ベンダーやシステム・インテグレーターの中には、ただ担いでいるだけの人が多いばかりか、付加価値を提供するプロフェッショナルな“システム屋”であることをあきらめた人たちが“担ぎ屋”に堕落してしまったケースが少なくありません。

　ソリューションとは問題解決のことです。問題解決のためには、どんな業種、業態、成長過程、事業構成、市場環境にあるユーザーが、いかなる状況でいかなる問題を抱えているのかという仮説があるはずです。その問題を、この製品ならこのように解決でき、そのうえ、費用対効果にも優れているということが必要です。

顧客企業の課題よりも懐具合に関心がある“システム屋”

　製品ベンダーの立場ならば、その製品がどういった特徴を持ち、一般論としてどういった課題を解決してくれるものかを説明すれば十分かもしれません。しかしながら販売代理店の役割も担うシステム会社であれば、想定するユーザー企業に特有の課題を想像し、仮説を構築したうえでそのユーザー企業のドアをたたくべきではないでしょうか。

　これとは逆で、実際に多いのは以下のようなケースです。例えばユーザー企業が流通業であれば、「流通業向けのあのパッケージが適用できる」あるいは「このユーザー企業には“スクラッチ開発”をする予算はない」「今“スクラッチ開発”する体制がウチにはない」といった直感を持った“システム屋”が、パッケージを使ったシステムの提案を考えるケースです。ここで“スクラッチ開発”とは、パッケージなどを使わずに、カスタムメードでシステムを開発することを意味します。

　ユーザー企業のニーズを知るはずの流通業担当部門と、パッケージ製品の特徴を知るはずのソリューション部門の両方からメンバーがやってきてユーザーに提案するのですが、ユーザーのいかなる課題をどのように解決するかというアイデアはありません。ニーズ・オリエンテッドな前者とシーズ・オリエンテッドな後者とのギャップは、「ユーザーが自分で埋めろ」と言わんばかりのケースがあります。