SI'er から ビジネスデザイナーへ

こんな本があると釣りと思ってもつい読んでしまう。まぁよしとしてさらっと読めるし考えさせらることもあるのでSI'erの方には一見の価値はあるかも。
なぜこの本を手に取ったかはこの1点につきる。

  • 大きな見積に失敗するとその後数年苦しい道を歩むことになるというモデルへの疑問

ということで、内容を引用しつつそれらに対する解を考えてみたい。

SI'erというシゴト

 SI'erは顧客に価値を提供しているはずであるが、原点に戻ってそもそもSI'erとは何かから考えてみる。

システムインテグレーションとは、システムを構築する際に、ユーザーの業務を把握・分析し、ユーザーの課題を解決するようなシステムの企画、構築、運用サポートなどの業務をすべて請け負うことである。これらを行う業者がSIerである。(IT用語辞典より引用)

「システムを構築する際に、ユーザーの業務を把握・分析し、ユーザーの課題を解決するようなシステムの企画、構築、運用サポートなどの業務をすべて請け負う」とある通りなのだが、どうもインテグレートという言葉がしっくりこない。でも実際はRFPをもらい、経営効率化のためにこんなことをシステム化したいという要望をもってどんなシステムでどんな機能があるからといったことを積み上げて工数を算出し、その上でより詳しくどんな機能をどういう作りでといったところを検討・設計していくわけだ。

システムを提供するわけではないということへの理解

 SI'erの定義は上記の通りだが、いつからだろうか、文字通りシステムを売るのではなく価値を売るのだ、と言われ出すようになったのは。結構長いこと言われているように思うが、誤解を恐れずに言えばやっぱり大半の人は分かっていない。正確に言うと「頭では分かっている(つもり)だが・・・」という人が大半なのだ。あまりにも言われることだから見聞きしたことはもちろんあるので「価値を提供するんだ」と言われると「そうだよね」「その通りだ」とは思えるものの、いざ「価値を提供せよ」と言われても理解できていないからやっぱりシステムを提供しようとしてしまう、これが世の中の人の大半だ、と私は言い切ってもいい。

システムインテグレーションの本来の役割は、テクノロジーを使って、お客様のビジネスの価値を高めることです。ビジネスプロセスを革新することであり、お客様のビジネスにイノベーションをもたらすことが、本来の目的です。しかし、それがいつの間にか、手段であるはずの「情報システムを作ること」へと目的がすり替わってしまったようにも見えます。 この「顧客価値を高めて、その対価を得ることで、ビジネスを成り立たせる」という原点をあらためて見つめ直す必要があります。

SI'erの未来

 ではSI'erは終わりなのだろうか。その答えは御社の中にあるという実にズルい回答だが、ひとつだけ言えるのは今と同じやり方・考え方で10年はもたないだろう。「変わらなければ!!」もはや私には滑稽にさえ聞こえるこの言葉は耳にタコができるほど聞いているが、私も含め「誰かが変えてくれるわけではない」ことにもっと恐怖を感じなければならない。SI'erの未来は私が語るわけではないが、このあたりはヒントになるだろう。

手段であるテクノロジー要素のひとつひとつがどんなに優れていても、プロセスの断片が正しくても、全体として事業目標を達成させるためのデザインがないビジネスは、お客様に魅力を感じてもらえません。新規事業のプロジェクト責任者は「ビジネスデザイナー」でなければなりません。

システムのデザインだけでなく、顧客のビジネスデザインを創造する、そのデザインをシステムを使って実現し、それによって顧客が得られる価値こそがまさに提供するもの、というわけである。大それた考え方にうつるだろうか。例えばいきなり数百億円級の案件でこれをやろうとしても破綻しそうである。ならば小さい案件から少しずつというのが現実的な解であろう。劇的な変化ではなく身近なものから少しずつ、そういうことだ。

SI'erのゴールは何か

 ゴール、今までの話上もちろんシステムを作ることではないはずですが現実はどうか。SI'er側はまず見積だが、ここでは競争がベースとなっているため、ギリギリの利益ラインのせめぎ合いとなる。そんな見積上の少ない利益を少しでも増やすためギリギリまで原価を落としたいところだ。ここでビジネスのデザインがどうとか言っているとどうか。もうすでに貰える金額は決まっているので、作る予定の機能を粛々と作る以外の作業をしていると逆に原価が食われてしまう。ということで、SI'erは作るといった機能を予定通りにシステムとして作り上げていく、それに従事することになる。これはSI'erの利益の最大化という面では最も効率が良い方法になるのでとてもじゃないがSI'erを責めるわけにはいかない。一方、SI'er側の売上を支払った顧客はどうか、顧客はもちろん自分たちの利益を上げるため、経営上の課題解決のためのシステムを目指している。当然ながらそこには目指すべきものがあるわけだが、SI'erは最初に決めた通りにどんどん作っていく。それは使い勝手が悪かろうが、要らない機能だろうが関係ない。当然のことながら顧客は不満を漏らし始め、改修・変更を要求する。するとSi'erは改修費用がかかるので仕様変更として追加のお金をくれと言い出す。顧客としては要らない機能を提案して作ったのはSI'er側のビジネスの理解不足としてお互いの言い分が激突する。とはいえSi'erはシステムを収めてお金を貰わないと今までの工数がまるまる赤字となるので立場上は弱く悪い条件でも飲まなければならない事態にも陥る(実際はここは両社の関係次第で、後から別案件で回収とかもできる可能性がある)。結果としてどうなるか、本書ではこう書いてある。

情報システム部門は、工数積算で予算を確定でき、瑕疵担保で成果物の完成責任をSI事業者に負わせることができます。一方、SI事業者は、作業負担が増大するリスクを抱えながら、低利益を強いられます。問題が起きれば、情報システム部門は「SI事業者の要件定義が不十分であり、スキル不足なのが悪い」「自業自得だ」といい、SI事業者は「要件定義を適性に評価できなかった情報システム部門の問題だ」と頭を抱えます。このような、「ゴールの不一致」と「相互不信」といった「構造的不幸」を内在したままのSIビジネスが、双方にとって健全であるはずはありません。

なので重要なのはここのゴールを一致させることだ。それってどうするのか、そこが今後のSI'erの収益モデルの変更になるだろうし、「変わらなければ!!」の行く先でもあることだろう。

SI'erと顧客のゴールを同じにすれば解決する

 そう、もう答えは簡単だ。顧客とSI'erのゴールを同じにしさえすればよい(簡単に言うな、と)。正確には顧客とSI'erのゴールを同じにできる仕組み(モデル)の構築が答えのひとつだ。さて、どうすればよいか。その一つの恒例が成果報酬である。去年、こんな記事を新聞で目にした。

簡単に説明すると、NTTデータANAの貨物の予約や搬入、積載など一連の中核業務を支援する新基幹システムを無償で構築し、本番稼働後はANAが取り扱った貨物量(貨物の搭載重量)に応じて月額利用料金をANAから貰うと言うものだ。これの凄いところは単に継続的な収入を得られるということだけではない。先のゴールの不一致を解決するモデルなのだ。当然ながらシステム構築がまるまる初期投資なので採算の管理が丸ごと変わる上に、使えないシステムを作ってしまうと利益どころか初期投資回収すらできない状態に陥るのでNTTデータは単にシステムを作ればよいという訳にはいかない。真剣にANAの経営課題に向き合い、どういったシステムならANAの利益が最大化するかを考え抜いたことだろう。ANAとしてはもちろん使えるシステムを作りたいはずなので思惑は一致する。
 母体となる会社規模が大きくないとこんなことはできないと思うかもしれない。だからこそスモールスタートである。会社によってスモールの規模は異なるかもしれないが、まずはごく小さいシステムから試してみてはどうだろう。その中で今まで見えてこなかったことが見えるようになるとともに今まで直面しなかった課題にぶちあたるに違いない。それを乗り越えてこそ、新しいビジネスデザイナーへの道が開ける、そう私は思っている。また、本書では成果報酬の他に、レベニューシェアサブスクリプションが挙げられている。ぜひ読んでみて欲しいが、時間のない人は下記スライドでも。