[商品企画] 流行の技術を利用したサービス企画を考える際の注意点
企画の立ち上がりと選別
「上から言われてねえ・・・」という事で急遽、企画を検討しなければならなくなったとか見聞きする事があるのですが、「おお、これは確かに盲点だったわ！さすが社長！」という事もありますし、逆に「これって日経の提灯記事読んで感化されただけでは・・・何周遅れなのよ・・・」みたいなこともあり、突然に話を振られた現場担当の人に同情の念を抱かずにはいられないケースもありました。
その逆で、営業が現場で拾ってきた声を元にナイスなプランニングを立ててくる場合もあれば、エンジニアが、勉強した新しい技術を使いたくて機能を提案してくるものの、「この機能、誰がうれしいんだよ・・・」といった悩ましい事もあります。
トップダウンであれボトムアップであれ、いろいろなレイヤーからいろいろな質のアイディアや指示などが発生します。アイディアが出てくる現場というのは、基本的には非常に望ましいのですが、いまいちイケていないプランに振り回されるのは消耗するのですよね。
例えば「社長からのトップダウン」といっても、ユーザーの潜在ニーズを汲み取った商品開発をしたら、それが当たって会社を大きくしたような、非常に感度の良い方もいれば、あまり現場やマーケットがみえていないサラリーマン社長もおられたりと、個別の事情はバラバラだったりしますので、「トップダウン」が良いとか悪いとかのプロセスの議論はあまり意味がなくて、それらのネタを誰がどのように評価して、製品・サービスに反映させるかを決めるプロセスの方が重要だと思います。
トップダウン方式の功罪
例えば社長（または上層部・幹部クラス）が的確に時流を読み切ったアイディアを投げた場合は、社内は最速で動けるわけですから、企画の進め方として一番スピード効率が高いのは言うまでもありません。予算面でも（妥当な範囲では）トップのバックアップはあるでしょうし、「社長が言っているから」と業務の優先度も上げられます。トップダウンの製品開発で有名なところではアップル社でした。スティーブ・ジョブズさんの強権的なやりかたには是々非々ありますが、トップがビジョンを示して社内を振り回して世界的な製品を作り出したプロセスは、非常に興味深いものがあります。
その逆に、社長のひらめき一発ネタでいろいろと無理があるだろうといったプランでも、社長が社長であるがゆえに周りが止められず、結果的に大惨事になったこともあります。（個人的にも経験があって、社長と大喧嘩して社内のエンジニアは協力しかねると拒否した結果、社外発注でリソースを集めてプロジェクトを強引に進められました。事業としては空回りし、保守を自社で引き取らざるを得なくなって火の粉が降りかかってきた苦い思い出が・・・）
最近では、もっとフワっとしたトーンで、トップが例えば「うちもブロックチェーン」「うちもAI」と号令をかけるケースです。良くも悪くも高めの優先度で社内が動きます。（※2019年の時点では「ブロックチェーン」はコンセプトは面白く、ポテンシャルもあるものの、その使いどころは難しく、技術的にも成熟していないといったレベル感と私は評価しています。）
このような指示が飛んできた現場は、例えばブロックチェーン技術そのものを研究する技術研究部門でない限り、技術の概要や適用事例などの調査から入って、その使いどころの可能性を検討していくわけですが、時として「ブロックチェーンを使ったサービスを作れ」と採用技術を指定した指示が飛んでくる場合や、飛んできた指示がそのように現場で解釈される場合があります。これはキツイ。
少し前にも「ビッグデータ」「IoT」、最近では「AI]などのキーワードが乱舞していますが、業務のドメイン、事業の規模、投資できる予算規模などにより、全く投資効果が変わってきます。例えばビッグデータやAIなどの大量データを運用してビジネスを効率化していくようなサービスでは、それなりに事業規模が大きくないと高いシステム投資を回収できるほどの効率アップが望めないのです。分析結果を活用して数％の効率化を行った＝数千万～数億円以上の削減につながる規模感でなければ、投入するリソースの方が大きくなるでしょう。ある意味、大量データ分析は強者の戦略です。
これが手段が目的化したような指示が飛んできた結果、幹部会用の資料として、無理矢理な理由付けとともに「ビックデータ基盤」「ブロックチェーン基盤」がシステム構成図に入りこむわけですが、IT屋の営業担当を喜ばせるだけのものが少なくありません。数万件のデータレコードにビックデータ基盤は必要でないですし、現場の作業ミスの修正が必要な作業記録データを扱うのに（書き換えが難しい）ブロックチェーンを入れているのは、「社長が使えと言っているから」という理由で正当化されるのは不幸と言わざるをえません。役にたつのかどうか、売れるのかを疑問視しながら開発を続けざるを得ない現場のエンジニアは、横目でみていて可哀そうでした。
ボトムアップが良いとも限らない
一番お客様がみえているのは営業職だったり、サポート担当だったりします。顧客の困り事・悩み事は、そのままサービス企画のネタに直結します。またエンジニアが開発・集めてくる技術シーズは、いままで出来なかった事が出来るようになるという意味で、新しいサービス、新機能に向けたブレークスルーを生み出すポテンシャルがあります。うまく機能すれば良い企画が生まれることでしょう。
その一方で視野が狭い場合があるのも、ボトムアップで生まれた企画で良く見られます。先の「ブロックチェーン」などは典型的ですが、バズワード的に浮上した技術・ビジネスモデルは、意味がないとは言わないまでも事業としてみたリスクは高いという事は意識すべきです。何事もやってみないと分からず保守的になりすぎるのも良くないですが、「これからはシェア・エコノミー」に飛びついたレンタルサイクル事業が中国で自転車の墓場を生み出したように、取れるリスクのレベル感とのバランスは注意すべきでしょう。
またマーケティング面での視点も必要です。確かに必要とされているサービスではあるが、必要としている人が極めて限られている場合であれば、コストを考えると提供価格を物凄く高くせざるを得ず、商用サービスとして成立するのか疑問符が付くケースも珍しくありません。マーケティング視点に立つと市場が小さすぎるといった場合です。合わせて採用した技術が、決定的な差別化要因になるのかも考慮すべき点です。顧客への価値の向上につながるものか、バックエンドのコストダウンにつながり競争力が上がるのかにつながらなければ、リスクやコストが高めになる新技術を採用するメリットは薄いと考えるべきです。担当顧客の売り上げを作りたいがために強硬に特化した機能追加を求めてくる営業マンや、自分の興味ある技術にのみ狭いスコープを向けたエンジニアなど、額面通りに話を受け取ると火傷を負いかねないボトムアップもあるのです。
アイディアを客観的に評価する基準を持とう
組織の事情はいろいろあるので、企画の扱い方についての無理な一般化は出来ないですが、どこから出てきたアイディアであっても、一定の基準で評価するプロセスと基準を持つべきです。
評価基準としては、例えば一般的なマーケティングの視点では
- ユーザー／顧客のどんな悩みを解決しうるのか。または利便性を提供できるのか
- 必要としそうな顧客数は、損益分岐点を超えるくらいに見込めるのか
- 価格は市場感からみて、妥当なレベルで提供できる見込みがあるのか
- 競合は存在するのか。参入障壁／差別化要因を作る事ができるのか
などの問いに答えを出せる必要があります。最近はやりの"PoC(Proof of Concept:概念実証）" では特定の技術利用だけが着目され、マーケティング視点を全く無視しているプランも珍しくありませんので注意が必要です。
プロセスとしては、営業、企画、開発、サポートなどの主要メンバーで企画会議を開催して、いろいろな視点から企画をレビューを行う、企画に責任を持つプロダクトマネージャー(PdM)に採否の裁量を持たせるなど、会社のカルチャーや担当者のバックグラウンドに負う所が大きいので、組織ごとに適切なやり方を模索していくのがよいでしょう。極端な例では剛腕社長が強権的にプロジェクトを進めるような現場であっても、企画の段階では何らかの形でドキュメントに落としてから、社内でレビュープロセスを踏んだ方が、ゴールイメージの社内コンセンサスも出来上がるので良い結果を生む傾向があるとみています。
合わせて一般的な企画書の他に、"Marketing Requirements Document(MRD：市場要求仕様書)"、"Product Requirements Document (PRD：製品要求仕様書）"などを作成していくのがよいでしょう。前者は市場課題やマーケット、後者はソリューションにフォーカスを当てたドキュメントです。製品・サービス開発の仮説や方向感が間違えていると、その手戻りの代償は大きくつきます。市場調査を行ってガッツリと書くのは難しいとしても、簡易版でも良いので作っておくべきです。