SIが儲からないビジネスになった今、事業構造の転換が求められている。鍵を握るのが、顧客の経営者と直接会話してITニーズを引き出す「システムコンサルタント」の育成だ。普通のSEをシステムコンサルタントに鍛え上げ、真のコンサルティング営業を実現するための実践論を連載する。

 ITサービス業では、SIビジネス構造の転換が喫緊の課題とされ、必要な施策の1つとして「システムコンサルタント」の育成が位置付けられている。

 顧客の経営者と会話してシステムニーズをくみ取り、システム発想ができて、システム化計画を提言する。計画が推進される時には、SI受注を実現する。また、場合によってはSI受注したシステムについての著作権を確保し、それを基に新しいビジネスを創り出す―。単なる技術課題を解決するITコンサルタントではなく、ビジネスの創出ができるのがシステムコンサルタントである。では、システムコンサルタントはどのように育成すればよいのか。

 筆者は20年以上にわたり、民間、官庁を問わず約200社・団体のシステムコンサルティングを、現場の第一線で経験した。また、コンサルティング経験のない多数のSEをシステムコンサルタントへと育成してきた。そして、いくつかのビジネス創造も実現した。現在は、システムの形が見えない段階である“源流”のコンサルティングを行っているが、このシステムが形を現せばSIビジネスは自ずと生まれることになる。

 外資系経営コンサルティング会社では、MBA(経営学修士)資格取得者が経営コンサルタントとして活躍している。しかし、これから紹介するシステムコンサルタントの育成では、特別な資格とか資質を条件としない。普通のSEをシステムコンサルタントに変身させる実践論である。コンサルタントを育成してみて気付いたのは、「泳げるようになった」「自転車に乗れるようになった」のごとくコツをつかめば、誰でもシステムコンサルタントになれるということである。

 そもそもシステムコンサルタントは何者で、どんな訓練をすれば、システムコンサルタントになれるのか。システムコンサルティング事業の実際と併せて、これからの6回の連載で紹介していきたい。

儲からなくなったSIビジネス

 これまでITサービス産業の成長を支えてきた大型SIビジネスがここ数年来、採算の合わないビジネスになった。案件数・発注額が減少して需給バランスが崩れてしまったからだ。採算を度外視した安値受注を行ったり、要件が不明確でハイリスクの案件であっても仕事量確保のために受注したりすることも横行した。その結果、赤字決算や大幅な収益減少が当たり前になってしまった。さすがに最近では、収支の取れない案件やリスクのある案件は受注しないようにするとともに、PMO(プロジェクト・マネジメント・オフィス)の強化が図られるようになって、赤字会社は少なくなった。しかし、それだけではジリ貧である。

 大型SI案件が減少した理由は明確で、大型システム開発が一巡したからにほかならない。例えばメガバンク。親会社の合併に伴い、今年4月に新発足したメガバンクの情報システム子会社は、約4000人の社員のうち2000人が外販部隊であるという。かつて金融機関などは、膨大な開発案件を消化するために、特定のITサービス会社に対して、案件を継続的に出すことを前提に一定の開発力を確保させる方策を取った。人材もITサービス会社に送り込み、強固な関係を構築した。多少の増減があっても優先的に案件が回される時代が長く続いたため、人員の確保だけがITサービス会社の経営の関心事であった。

 ところが金融機関でさえ、そのような良好な関係も成り立たなくなるほど、現在は開発案件が減少してしまった。しかも今日、ユーザー企業が期待するのは、単なるSIではなくソリューションである。従って、ソリューション案件を獲得して、その次に関連したSI案件を発掘することが必要になってきている。しかし、多くのITサービス会社は、来る仕事を消化することは得意であっても、自ら仕事を提案し獲得できる人材がおらず、仕組みも整っていないのが実情だ。

 一方、コンピュータメーカーも構造転換を迫られている。今やインフラビジネスを獲得するためには、アプリケーション分野をまず獲得しなければならず、そのためには上流のコンサルティング案件を獲得しなければならない。このところ相次いでコンサルティング会社を買収しているのは、その証左である。ITサービス会社もコンサルティング会社を買収できないのなら、コンサルタントを雇い入れるか、あるいはSEをシステムコンサルタントへ変身させるしかない。

見えないシステムを見えるようにする

 もともとSEやシステムコンサルタントの定義はあいまいである。どちらも弁護士、会計士などとは違って、資格試験があるわけではない。名刺に「SE」とか、「システムコンサルタント」と記せば、その時からSE、システムコンサルタントとして仕事ができる。もちろん、本物のSEやシステムコンサルタントでなければ顧客からのクレームの対象となるのだが。

 ところで、ITサービス業界では「コンサルタントSE」という言い方がされる場合がある。この言葉には、いろいろな期待が込められている。ある意味では、ITサービス会社の経営にとって理想とするSE像を表現しているといえる(図1)。実際に、優れたSEがシステムコンサルタントを兼ね、成果を出しているケースもある。しかし、ここではSEとシステムコンサルタントを区別して話を進めたい。

図1●コンサルタントSE像
図1●コンサルタントSE像

 システムコンサルタントとSEを「システムコンサルティング工程」と「システム開発工程」の概念で定義する(図2)。システムコンサルティング工程とは、いまだ姿が見えないシステムを見えるようにする工程である。渾沌としてシステムの問題なのかどうかさえ分からない段階から、顧客の経営者、企画部門、ユーザー部門と会話して、経営課題の解決のためのシステムの姿を描き出す工程である。システムの姿が見えてきたら、それが次の工程への“源流”となる。

図2●システムコンサルティング工程とシステム開発工程
図2●システムコンサルティング工程とシステム開発工程

 一方、SEが活躍するシステム開発工程は、作るべきシステムの姿が見えており、それを完成させる工程といえる。顧客の情報システム部門との共同作業が中心となる。

 ところで、システムコンサルティング工程で明らかにしたシステムの姿は、一度決めると動かない世界である。他方、システム開発工程でのシステムの姿は、時間的な経過とともに発生する環境変化、ユーザーの要求変化により揺れ動く。システムコンサルタントとしても、この動く標的に対応することが求められ、 SEと協力して動かさないようにユーザーを説得・誘導する必要がある。

 つまりシステムコンサルタントのミッションは、目的・目標を明確にし、次のフェーズに進むことができるようにすることにある。次のフェーズに進むためには、システム化計画書を作成し、顧客の経営者にオーソライズしてもらわなければならない。システム化計画書とは、経営者やエンドユーザーの期待するものを明確にして、その実現のために何を作ればよいのか、そして費用対効果、また実現手段、プロセス、スケジュールも明確にした文書だ(図3)。オーソライズされれば予算措置が取られるため、開発受託に向けた商談ができる。

図3●オーサライズされるべきシステム化計画書の項目
図3●オーサライズされるべきシステム化計画書の項目

システムコンサルティングで赤字案件も撲滅

 このように、システム化計画書を作り、経営会議でオーソライズできるように支援・代行することが、システムコンサルタントの役目なのだ。一方SEは、明確になった目標を実現するシステムを作るのがミッションである。システム開発の過程で、ネットワーク、セキュリティ、データベースの構築など特別な技術領域では、その道のプロであるITコンサルタントが支援する場合もある。

 ところで先に述べた通り、要件が不明確であるのにSI受託契約を結べば、要件増加、要件変動によりシステム開発工程が膨らみ、受託したソリューションプロバイダが大きな赤字を背負うことになる事態が発生する。ソリューションプロバイダがシステムコンサルタントを擁していれば、要件確定のフェーズを顧客に提案し、まずこの段階までをシステムコンサルティング契約として受託することで、こうしたリスクを回避することができる。少なくとも、どんなリスクがあるのかを把握した上で、SI提案が可能になる。

 今後は、石炭の露天掘りのような目標が明確で、安全確実な新規開発案件はなくなる。代わって多くなってくるのは、海底油田を探すような目標があいまいなソリューション型案件である。受託できるのか、受託するべきかどうかの検討から始めなければならない案件である。これからは、システムコンサルティング契約をまず締結して要件を確定し、リスクの把握に努めなければならない。

 一般的に、システムコンサルティング契約の受託金額とSI受託金額では、ビジネススケールに10倍以上の差がある。しかし、10分の1にすぎないシステムコンサルティング契約が、SIでの赤字削減にもつながるのである。コンサルティングの結果、SI受託を断わるべき案件も多数あることに気付くはずである。

黒岩 暎一
テクノロジストコンサルティング代表取締役社長
元・野村総合研究所常務システムコンサルティング本部長。約200社・団体のシステムコンサルティングを経験。2005年にテクノロジストコンサルティングを設立。CIOやITサービス業向けコンサルティング、システムコンサルタント育成サービスを提供。