導入

新規事業創出制度の起案者、そして事務局やメンターが新規事業の創出に挑む中で、多くの人が抱える悩みや課題がある。
その解決のヒントを提供しているのが、新規事業開発支援を行う株式会社アルファドライブの「新規事業よろず相談室」だ。
第5回目となる今回のテーマは「新規事業のプロダクト開発」。相談室に寄せられた、初期開発の品質基準の設定方法や開発ベンダーの選定方法などの「お悩み」に答えていく。

初期開発のフェーズに入ったら腹をくくって品質管理基準で進める

お悩み1：プロトタイプ・初期開発の品質保証の考え方

古川：食品メーカー勤務の方から、新規事業の品質保証に関する質問です。既存商品の品質管理基準が適用されるため、「プロトタイプを使ってもらい、改善していく」というアプローチが、なじまないことで悩んでいます。

麻生：確かに食品には厳しい品質管理基準があり、どの段階から基準を守っていくかは難しい問題です。ただ、経営会議で商品リリースが決まり投資判断された後の段階だとしたら、それはもう既存の商品と同レベルの品質管理基準でやるしかないと思います。一方、例えば商品リリースが決まっていない構想段階、事業計画書の段階であれば、「検証ポイントを分解」し、その上で判断するのがよいでしょう。例えば、「売れるかどうか」の検証はクラウドファンディングなどでつくらずに進めるのであれば、品質管理基準は関係ない。商品開発部内で「おいしいかどうか」を検証する場合も、品質管理基準は保留しておいて構わないでしょう。ただ、自社工場と契約工場で「つくれるかどうか」を検証するのであれば、品質管理基準に沿って検討する必要があります。

古川：プロトタイプフェーズと初期開発のフェーズで、判断が異なるということですね。前者であれば、限定的なコミュニティで試作品を持ち寄り試食するなど、品質管理基準に関係なく進める方法があります。一方、初期開発のフェーズに入ったら、腹をくくって品質管理基準に沿って進めるしかないでしょう。初期開発フェーズのアドバイスとしては、「品質管理基準で開発を進める」ということと「時間と費用がかかる」ということは、セットだと認識しておいた方がよいということです。

新規事業には、ITリテラシーを根付かせる時間はない

お悩み2：システム開発のリテラシーについて

古川：ソフトウエア開発の知見がない大企業に勤めている事務局の方からの質問です。事業開発を進めるに当たり、システム開発のリテラシーが会社全体に根付いておらず、苦労しているようです。

麻生：事務局にITリテラシーがないのであれば、IT顧問などのポジションに外部人材を招請すればよいと思います。

古川：定石の1つですね。

麻生：リテラシーを身に付けてもらうという考え方もありますが、新規事業には制限時間がありますからそんな時間はないはずです。それなら「外部から連れてくればよい」というのが私の意見です。リテラシーを高める時間があるなら、その時間を顧客開発に使うことに専念しましょう。

古川：それを短期的な解決法とするなら、中長期的にリテラシーを会社全体に根付かせる方法はありますか。

麻生：結局、社員のリテラシーを高めるには、「失敗」しかありません。チームに予算を与え、失敗してもいいからアプリなどをつくらせてみる。そうした人事発令やチーム組成すら難しいのなら、ベンチャーに出向させて出向先でプロダクト開発を経験させる。業務契約でIT部隊を外部につくり、そこに対してマネジメントすると同時に、外部のITリテラシーの高いプロと一緒に仕事をしてもらうのです。そうすることで多くの失敗から学び、リテラシーが高まっていきます。

古川：失敗しながらITリテラシーを根付かせていくということですね。

麻生：社内のITリテラシーに関連して、「システム開発を内製すべきかどうか」は大きなテーマです。2000年代前半から中盤は、「アプリをつくれる」「UXが良い」「データ処理速度が速い」といったことを会社の“なか”で持っておくことが、サービスの競争優位であり提供価値になりました。ところが “ノーコード”が象徴するように、最近はシステムがコモディティー化をしています。コモディティー化されたものを自社で抱える必要があるのかどうか、多くの会社が議論し、自社専属の開発チームを社外に構築する「ラボ型開発」も増えています。

古川：その流れは、理解できます。事業計画をつくってみると、外部委託の方がコストを抑えられることも多いですしね。

麻生：これからはフルアウトソースの時代が来るかもしれない。それくらいシステムはありふれたものになっています。

古川：ただ、フルアウトソースといっても、完全な“丸投げ”は避けるべきですね。やはりビジネスとシステムをつなぐプロダクトマネージャーのような立場の人材は、内部に置かなければいけません。パートナー（開発会社）は、「開発をたくさんすること」で売り上げを得ますから、開発会社にプロダクトマネジメントまで預けてしまうと、余計な開発も生まれてしまう恐れがあります。新規事業の力学から考えても、プロダクトマネージャーは、内部に置いておきたいですね。

麻生：そういう意味では、IT部隊への発注権限を持った担当者の役割が重要になってきますね。もし質問者の会社のようにリテラシーが根付いていない会社で、その発注権限すら分からないというなら、“第三の会社”に入ってもらう方法も効果的です。ビジネスを内部でつくり、開発はラボ型開発で取り組む。その上で、ビジネスとシステムをつなぐIT顧問のような機能を、当社のような第三の会社に任せてしまうわけです。これならフルアウトソースも可能になります。

開発ベンダーの選定は「実績を重視」せよ

お悩み3：新規事業における良いベンダーとは？

古川：先ほど、開発は外部に委託する話が出ましたが、新規事業開発における“良い開発ベンダー”の選び方を教えてください、という質問です。

麻生：見極めのポイントは、新規事業のプロダクトをつくったことあるかどうか。質問者はインフラ企業の方なので、「社内の付き合いの深いベンダー」とはおそらく重厚長大なシステムを受託しているSIerだと思います。最初からそこに頼んだら駄目です。

古川：確かにインフラ企業がクライアントの場合、開発ベンダーもおそらく日頃から失敗できない開発をしていますから、必然的にウォーターフォール型の開発になりますね。新規事業におけるシステム開発はアジャイル型でなければならず、それが得意な開発会社であることが第一ですね。ただ、アジャイルを強みにしている開発ベンダーはたくさんいます。その中から選ぶにはどうしたらよいのでしょうか？

麻生：実績を聞くのがよいと思います。どのようなものをどのようにつくったのかを聞いて、自社のやりたい開発のサイズとスピードに近しい実績と持つ会社を選ぶのがよいでしょう。

古川：もう一歩踏み込んだ話をすると、開発ベンダーの選定では“あまり大きな実績がない会社”の方がうまくいく場合があります。実績がある会社を選定すると、起案者（システム発注者）は顧客に中途半端なものは出せないから仕様・機能を盛り込もうとし、さらに開発会社も売り上げになるから、必要のない仕様・機能まで盛り込みがちになります。「お互いが盛り込みたがる」力学が働き、開発費が膨れ上がるケースが頻発します。大きな実績のない会社の方が、新規事業に適したミニマムな開発を得意としていたりします。

麻生：ただ、中には「仕事ができないから大層な実績がない」というケースも存在します。この点も踏まえると、発注の仕方を見直した方がよいのかもしれません。例えば、「お悩み②」で紹介した「ラボ型開発」であればそれを回避できます。一般的な請負型開発では、提示された要件に対して工数を乗せていくため、おのずと見積が高くなりますが、ラボ型開発はそもそも「人工（にんく）を抑える＝一定期間人員を押さえる」という発想があるため、そうなりません。

仮説が何度も変わっても検証できていれば開発メンバーは納得する

お悩み4：プロダクトの仮説がころころ変わり現場が混乱

古川：開発チームを束ねるプロダクトマネージャーの悩みです。顧客や会社側の都合でプロダクトの仮説が目まぐるしく変わり、結果的に現場を混乱させている。そのような状況の中、どう現場を納得させながら、いかにアジャイル開発を進めていくべきか。

麻生：事業開発の現場でよく見られる悩みですね。

古川：アジャイル開発で、仮説がコロコロと変わるのは仕方がないこと。新規事業は、顧客ニーズに応えるのが絶対ですから。

麻生：その通りですね。だから、このお悩みに「解」はないといえます。ただ、現場の納得感を得るために立ち返りたいのは、顧客ニーズをきちんと検証しているか。例えば、顧客から「このボタンは、こうしてもらわないと困る」というクレームがあったら、それに即反応し「顧客が言っているから、変えてくれ」としていては、現場は納得しません。しかし、きちんと検証し「確かにこうした方が利便性は高まる」とプロダクトマネージャーが納得した上で、開発要件に落とし込めれば、たとえ朝令暮改だったとしても、現場は付いてきてくれると思います。

古川：一方で質問者は、社外に開発メンバーを持つ発注権限者です。自分が思っている以上に、現場は「クライアント様の決定事項」として受け止めているかもしれません。そうしたプロセスやコミュニケーションから見直してみるのも必要な視点ですね。

麻生：開発メンバー側の立場で言えば、ビジネスサイドがそんなことを言い始めたとき、「本当にそれ必要ですか？」と進言できる開発チームであってほしいですね。新規事業はそういうオープンな関係性を備えたチームで挑む方がうまくいきます。

アプリ至上主義者には「検証時のつくり込み度合いに論旨をすり替える」

お悩み5：アプリ or ウェブ？

古川：次は、開発コストの低いウェブ開発から始められる事業アイデアなのに、起案者がアプリをつくりたがって困っている、という悩みです。

麻生：こういう起案者は少なくありません。それに対応している事務局の方には、本当に頭が下がる思いです。

古川：アプリ至上主義の起案者に多いのは、「アプリじゃないと使ってくれない」というロジックです。「アプリでないと顧客を納得させるUI/UXが達成できない」、もっと言うと「ウェブでつくったら失敗する」とすら思っています。

麻生：実際は、つくるものによって、アプリとウェブのどちらが適しているか決まります。例えば、ゲームはいまさらブラウザでは無理でしょう。ブラウザゲームでは使用感も高められませんし、楽しさを提供できません。

古川：どういう基準で選べばよいのでしょうか。

麻生：顧客の望む最低限の価値に到達するために、アプリが必要かどうかを見極めることではないでしょうか。つまり、ゲームのようなエンタメ系は顧客の要求ハードルが高く、アプリでつくり込まないとお金を払ってもらう価値にまで到達しないためアプリが適しています。一方、単なる情報サービスならウェブでも十分に価値を提供できるので、アプリにする必要はありません。

古川：おそらく質問者（事務局）を悩ませている起案者は、こうした話にも聞く耳を持たないタイプだと思います。この場合は、「やがてアプリは必要になるかもしれませんが、今は検証のフェーズなので、いったんウェブで構築しましょう。コンバージョンレートなどの数値も分かりますので、その結果を見てアプリにするかどうか検討しましょう」と言って、目標を下げてあげるのがよいと思います。

麻生：「ウェブかアプリか」ではなく、検証時のつくり込み度合いの話に論旨をすり替えるやり方ですね。とてもよい方法です。

Q＆Aセッション

以下、その他に寄せられた質問に短くお答えします。

——新規事業に開発リソースを充てられない。新規事業の優先度を上げるために、できることはありますか？

麻生：新規事業は、PoCの段階までならほとんどお金がかかりません。どのような事業かによりますが、事業化することになって最初のサービスを設計・開発する段階でかかるお金も、せいぜい数千万～1億円くらいでしょう。その金額すら出せないというなら、もうその会社で新規事業は無理です。そもそも「新規事業をやるのかやらないのか」という根本の話し合いが必要です。経営陣を説得しますから、私（麻生）を経営会議に呼んでください（笑）。私でなくてもいいですが、経営陣を説得するのが先決だと思います。

——やたらプロトタイプをつくりたがるメンバーがいて、「リーンに検証派」と「つくりたがる派」の争いで困っています。

麻生：このケースでは、事業開発上の検証ポイントを分解するのがよいでしょう。「リーンに検証派」は複数のポイントをまとめて検証しようとするから、A・B・Cにプロセスを分解し実証させる。当然その方が早く、安くできます。「つくりたがる派」は完成形を欲しがりますが、その完成形をつくるには検証しなければならず、検証するには分解しなければいけない。完成形をつくるのは、分解したそれぞれのパーツで検証できた後のタイミングです。それを分かってもらいましょう。

もし分かってくれないなら、制度でカウンターパンチを出す方法もあります。PoCであれば上限予算があるからその予算を下げる。例えば、通常500万の予算だったものが50万になれば予算を抑えるため分解するしかなくなくなります。つくりたくてもつくれない状況にしてしまうのが解決策です。

———開発をディレクションする上で、ビジネスオーナーが持つべき心構えを教えてください。システム開発のイメージがつかめておらず不安です。また、どうキャッチアップするのがよいのでしょうか。

古川：これは2つの質問を組み合わせたものですが、どちらもビジネスオーナー（起案者）からの質問で、ビジネス開発の心構え・マインドに関する内容です。

麻生：「ビジネスパーソンとしてテクノロジーの知見・スキルをためていくには？」みたいな話ならいくらでも相談に乗れますが、質問者のように、一度起案者に任命されれば、すでに新規事業のルートに乗っているため、数カ月後には何かしらの成果を出さなければならない。そのスケジュールにおいて、テックの経験値がない人が必要なスキルを身に付けるのは、正直難しいと思います。プロジェクトの成功を考えるのなら、外部からそれができる人間（テックを含めてビジネス開発を熟知した人間）を呼んできた方がよいと思います。

それを前提に1つアドバイスするとすれば、ビジネスオーナーはどれだけ顧客志向であろうとしても、どれだけフラットに見ようとしても、自分がつくり出したプロダクトのことを“好き”になってしまいます。そうして可愛くなると判断を間違え、失敗する。自分のことを信じすぎないのが賢明です。

——開発機能を内製化する際の注意点を教えてください。

古川：通常エンジニアの稼働は会社の資産になりますが、R&Dの一環なので資産化しないで扱うとか、全社のセキュリティールールに基本的には準拠するけれど、新規事業では特区的に扱ってもらうとか、細かいことを挙げればキリがありません。多くは運用に関わる話です。

麻生：既存事業の上に新規事業のインフラを構築するのか、それとも横に全く違うインフラを構築するのか。開発内製化は人・組織ももちろん大事ですが、それ以上に重要なのが、そうしたインフラ設計です。その上でエンジニアをたくさん採用し内製化部隊をつくるのだと思いますが、「何の能力を持った何の職種の人を内製化させるのか」「どこから先は外注にするのか」という線引きも重要になります。

古川：あと、内製化部隊がうまく立ち上がるケースは、開発チームの“1人目”にリファラル能力（紹介する能力）が高い人がいるパターンが多い。そうした人は有能で最適な人材を芋づる式に連れて来ることができますから、1人目の人選に力を入れるのがよいと思います。

——最初からエンジニアを巻き込んだ方がいい事業の特性を教えてください。

麻生：アルファドライブの事業開発の進め方は「顧客課題」から始めるので、そもそもエンジニアを必要とするかどうかも分かりません。教科書的にお答えするなら、最初からエンジニアを巻き込んだ方がよいケースは、「ない」というのが回答になります。とはいえエンジニアが「絶対に不要」なサービス開発なんてほとんどありません。後で必要になるなら最初から巻き込んでおいた方がよい、とする考え方も成立すると思います。いずれにせよ、天才エンジニアのような存在が最初からいる必要はありませんが、エンジニアでなくともテックに詳しい人は巻き込んでおいた方がよいでしょう。

——開発費用の見積もりをチェックする際のポイントを教えてください。

古川：一発目に上がってくる開発ベンダーからの見積もりは、さまざまなリスクを吸収するための費用が乗っかっています。だから突き返して、内訳を聞いてみるのがよいでしょう。すると今度は細かい見積もりが上がってくるので、そのときは相場感をチェックしましょう。

麻生：ただ新規事業ではそもそもオーナー側からのオーダーが曖昧で、それが原因でリスク分を含んだ見積もりが上がってくることもあります。すると分解したところで意味のない議論に発展する。その場合は、見積もりの裏側にある開発体制を聞くのがよいと思います。つまり「この要件でこのプロジェクトを進めるとき、御社の中で誰と誰を毎週何時間稼働させて開発チームを組みますか」と聞いてみる。例えば総額何千万の半年間のプロジェクトに「0.8×4人」の稼働が割かれていれば人月単価が出るので、それで高いか安いかを判断できます。