PoCを実サービス、事業に繋げるため 「発注者、受注者」から脱却しよう

2017.09.28
リスト
このエントリーをはてなブックマークに追加

新製品やサービスを開発するために欠かせないのが市場分析やテストマーケティング。デジタルジャーニーにおいて、それに相当するのが稼働するシステムやサービスを開発し、実際にリリースしてみることである。得られる反応や意見を分析し、それに基づいて必要な機能を追加したり、不要な機能を削ったりするのだ。いわゆるPoC(概念検証)である。

その必要性は言うまでもないだろう。たとえアイデアが秀逸で成功は確実に思えるにしても、実際にやってみると想定外の問題が発覚することがある。それをチェックしないまま、本格的なシステムやサービスを開発するのは、大きなリスクを抱えることと等価である。一方で実際に動くシステムやサービスを開発するコストは劇的に下がっているから、実際に動くシステムやサービスを作ってみるのは自然かつ当然である。

しかし日本企業がPoCを実践し、サービスを実用化するのは必ずしも容易ではない。「PoCに時間と費用がかかりすぎる」、「PoCをやったが、それで終わり」といった話をよく聞くし、筆者自身も経験したことがある。そこにはどんな壁があり、どう乗り越えればいいのだろうか?

問題1:PoCに時間がかかる費用が膨らむ

よく知られていることだが、日本におけるシステム開発では開発量(工数)と費用がリンクするため、開発パートナーはコーディング量を増やしたり、できるだけ時間をかけたくなってしまう誘惑がある。この点で硬直的な予算執行、つまりQCDに枠を設けるウォーターフォール型の開発が馴染まないことは明らかである。PoCではスピードを重視し、見直しのループを高速に回す必要がある。そのためには新規に作る部分をできるだけ少なくし、オープンソースやクラウドサービスなどで使えるものは使い、新規の開発を最少にすることが重要である。少なくともアイデアのすべてを最初から実装することは合理的ではなく、小さく産んで大きく育てるアプローチをとる必要があるのに、それがやりにくいのだ。

問題2:PoCで終わってしまう

PoCを実施したものの、本格的なシステムやサービスの開発に至らないケースは多い。これ自体はPoCの目的でもあるため大きな問題とは言えないが、その一部にはPoCで得られた利用者からのフィードバックを既存組織の制約の中でハンドリングできないため、事業化が困難と判断する場合がある。つまり発注者のどの部門が責任を持ってフィードバックをハンドリングするか、あるいは発注者と受注者のどちらがそれを担うかを決めきれないことが理由で、宙に浮いてしまうようなケースが存在する。発注者がアイデア(要求)を出し、受注者がそれを実装するといった従来型のアプローチではうまく機能しないことが容易に想像できるはずだ。

解決策

筆者は米国シリコンバレーにあるR&D拠点、米国富士通研究所(Fujitsu Laboratories of America、以下FLA)で様々な新サービスの開発に携わっているが、日頃から痛感していることがある。米国と日本では、企業が斬新なサービスを生み出そうとするアプローチに大きな違いがあることだ。

多くの米国企業は自社内に専任人材を抱え、同時に外部のコミュニティと協働しながら、主体性を持ってサービス開発を行っている。これに対し日本企業は、表面上はさておき発注者と受注者という関係性が根底にあり、相互に依存し合う状況から抜け出していない(もちろん例外はある)。

例えば「ほう(報告)・れん(連絡)・そう(相談)」や「稟議」。日本企業の組織コミュニケーションのベースとなる重要な概念なので、シリコンバレーに拠点を置く日本企業では今もこれが生きているところが少なくない。ところがマーケットとの対話に基づくリーン型事業創出プロセスにおいては、これらが開発スピードを削ぎ、担当チーム(者)の主体性を奪ってしまう。「報告しているのに意思決定してくれない。だから遅れるのは仕方がない」といった状況が生じるのである。

筆者がボードメンバーを務めるブロックチェーンのOSSコミュニティでは、数カ月で主流となるテクノロジーやアイデアが変わる。このスピードに対応するため、SNSなどを駆使して日常のコミュニケーションをとることが必須だ。報告やレポーティングがSNSで完了することが前提なので、ボードメンバーは常にSNSをチェックすることが求められる。一方で異論が出なければコミュニティメンバーは主体的にどんどんプロジェクトを進めることができる仕組みである。

このような取り組みから学べる点は多いと思う。端的に結論を言えば、「発注者、受注者」という関係から脱却することだ。具体的には、主体性を持ったデジタルビジネスの推進者と、命運を共にするICTパートナーシップという関係を形成することである。なお発注者、受注者には社内組織同士の場合も、外部企業の場合もある点に注意していただきたい。

自前主義も改める必要がある。自社が不得手の領域まで自社リソースで完結させようとするとPoCの不確実性が増し、遂行の困難さも増大する。得意ではないところに時間をかけてしまい、本来やるべきことがおざなりになるのだ。FLAでは、事業創出プロジェクトはコア事業の創出に特化し、それ以外の付帯事業はスピードとコストを最適化するパートナーとの提携に任せることがある。

FLAでは先行的にこの取り組みを実践し、シリコンバレーに留まらないワールドワイドにいる人材を巻き込みながら、リーン型の事業創出フレームワークを策定、評価、そして改善している。そのノウハウは「共創のためのサービス体系=情報収集・問題発見、アイデア創出、サービスの実装」に生かされている(『デジタルジャーニーを歩む羅針盤 「共創のためのサービス体系」のすべて』参照)。このフレームワークは事業創出に加えて、組織のあり方も同時に変えていくダイナミズムを志向している。デジタルジャーニーを歩む真のパートナーとなるべく、FLAという組織から始まった取り組みが、海を越えて、富士通の組織のあり方を変えようとしている。

執筆者:澤野 佳伸(米国富士通研究所 R&Dマネジメントオフィス マネージャー)

この記事は、IT Leaders特別編集版『Knowledge Integration in Action 2017 in Summer』からの抜粋です。

トップ写真:graphicnoi/Getty Images

EVENTイベント