このケースいくらかかる？　～観光ガイドマッチングアプリ～

Wu：最初のケースは、観光ガイドマッチングアプリを開発する場合の費用や考え方についてです。昨今は海外からインバウンドが増えており、その観光客に対して新しい価値を提供したいという背景ですね。ビジネスモデルや機能については下記のとおりですが、まず本村さん、ビジネス視点から見ていかがでしょうか。

本村：試しに「観光ガイドマッチング」で検索してみたところ、1ページ目に表示された会社がすべて違っていたので、おそらく市場はあるのだと思います。同時に、少なく見積もっても10社くらいはライバルがいるということで、「上記の機能で作って本当に勝てるのか」という点は考える必要がありそうです。
とはいえ、こうしたアプリの普及率はまだまだ高くないと感じるので、いかにして頭ひとつ飛び抜けるかがポイントでしょうか。つまり、STPと競合優位性がどこにあるかを既存の各社を比較したうえで「自分たちはこの領域なら勝てる」という戦略が全体にあったほうがよいということです。

流行りの生成AIでもそうですが、ベンダーやサービスプロバイダが急増しているにも関わらず、日本ではあまり普及していません。こうした流れも鑑みると、現在の市場規模がどの程度あるのか、海外からの観光客は何を目的に日本に来ているのかなどの統計的なデータをリサーチすべきだと思います。たとえば京都を訪れる方が一番多いと仮定すると、京都に特化したアプリにセグメンテーションするという仮説もできます。目的のファクトを取るのであれば、国が提供しているデータや有償で購入できる調査会社のデータを活用したり、アナリストに調査を依頼するといった手段もあります。

船木：私は今のお話を聞きながら、こっそりと見積もりを作ってみました。結論としては、開発の部分だけを見ると1,350万円になっています。

表に書いてある「1」や「2」などの数字は、各機能に対するストーリーポイントが、アプリやバックエンドにおいて相対的にどの程度難しいのかを示しています。たとえば「ユーザー管理」と「決済機能」を見比べた場合、後者はフロントエンドだと約2倍以上、バックエンドだと約4倍以上の時間がかかるであろうと分かります。
この難易度の示し方は数字が大きくなってくると判断が難しくなってくるので、1・2・3・5・8・13のように、前の数字2つを足した数列（フィボナッチ数）を利用することも特徴です。これが、ストーリーポイントという見積もりの方法です。この難易度を一度決めてしまえば、「ここが20時間だとすると～」という形で概算を出せるようになります。そして、その概算を足して人月を算出し、そこに単価をかけることで合計が出ます。

1つの機能に対して求められる状況は、プロジェクトによって本当にさまざまです。MVPでクローズドなテストをするのに、ある程度の不具合などはコミュニケーションを取りながら直しますとしながら、ひとまず網羅的な機能が動いているというクオリティの目線だと、開発工数はグッと下がります。一方で、バグが叩かれている状態でリリースに踏み切れば、工数は2倍にも3倍にもなります。

とはいえ、その機能を作ることの相対的な難易度は変わりません。そのため、まずは1つの機能、たとえばユーザー登録機能に関しては「開発はこんな目線でやってきました」「これぐらいの工数がかかりました」ではなく 、「もっと簡単にしてほしい」「もっと時間をかけてクオリティを上げてほしい」となった場合に、表の「1」などの数字がハッキリしてきます。そうなると、修正ができます。もともと「1」の部分は20時間だと思っていたけれど、実は10時間、あるいは30時間だったと分かれば、計画の解像度が急激に増します。

こうした背景からも、相対的な難易度を計画のために作っていくことが重要ですが、この目線を合わせることも難しいです。ですので、別の抽象的な数字も見ながら作っていき、合わなければ変えていくと。PMBOK（※）的にも超概算は取りますが、その幅はマイナス50％からプラス100％、つまり半分にも倍にもなるのがルールとして設定されているので、そこに収める中心としてはこのような手法が非常に優れていると思います。
ちなみに、左下に赤字で書いてあるBIや管理系のサービスは割と抜けがちな部分です。実際に検証してみたときにその数字を追えないとまったく意味がなかったり、管理オペレーションをするときに急に手動対応が挟まってランニングコストが上がってしまったりするので、ここも正確に考えていく必要があります。

 ※：Project Management Body of Knowledgeの略称で、通称「ピンボック」。プロジェクトマネジメント関連の知識やノウハウが体系的に記された、世界標準で使われている参考書のようなもの。

本村：これは、良い本に出会わなければ発見できないレベルの情報提供ですね。

Wu：金額にしてみると、だいたい700万から2700万までの振れ幅があるわけですね。もちろんこの状態では見積もりを出さないと思いますが、発注する側としてはどのようにして予算を取ればよいのでしょうか。

船木：その会社の予算の考え方次第な部分もありますが、こういった増減を踏まえたうえで「○○の機能を作る」ことに対して合意し、まずつくる方法が1つあります。一方で「成果物と金額が分からないと困る」という場合は、ディテールを明らかにする要件定義の策定フェーズを設け、その中で金額感を共有しながら目線に合った仕様のサンプルを用意して、具体的な開発を進める方法もあります。ただ後者はスピード感が損なわれますし、実際に作らずに良い仕様にするのは難しいです。やはり、走りながらの方がプロダクトは良い方向に近づきますね。

この画面イメージいくらかかる？　～認知症診断システム～

Wu：次のケースは、脳波をフックに認知症予防に関わるコンテンツへの導線を検討しているものです。メディア運用での対応や誘導のため、基本的に病院や医療センターに対しては診断サービスとして無償提供する想定です。機能としては、脳波のアップロードやAIの診断ページなどがあります。本村さん、この場合はいかがでしょうか。

本村：簡易診断サービスとして無償提供とのことですが、そもそも認知症の診断は医療行為に該当するので、薬事法などの承認を得なくてはなりません。このプロダクトを開発したいと言っている会社が本当に医療領域での展開を目指しているのか、あくまで予防コンテンツがメインなので、ヘルスケア領域でも問題ないのかがポイントになりそうです。
もし前者であるなら、申請処理をするだけでも年単位の時間を要し、臨床試験にも数億円がかかるはずです。一方で後者の場合は、「MCIや認知症を予防するためのサポートアプリです」といったように、医療行為から遠ざかるようなプロジェクトテーマにする必要があると思います。

私たちのようなAIを扱うプレイヤーの観点では、「あなたには予兆があるので注意が必要です」などの診断を行うためのインプットが脳波であることを踏まえると、何人のデータを取れば最低限の機能を作り込めるのかを計るフェーズも大事になってくるかなと。機能としては先ほどのケースよりも少ないですが、やるべきことが多くて大変そうだなという感触です。
個人情報を取得するのであれば、そのセキュリティ対策や脳波の情報との紐づけに対する倫理観の問題もありますし。ただ、本当にライトな予防のためのアプリを作って、かつ市場性があるなら、さほど高くない金額でリリースはできそうです。

Wu：ここまでのお話を聞いていると、予防コンテンツで元を取れるんかなという点も気になるところですね。

船木：プロダクトとしてはシンプルですが、そのモデリングやレコメンドエンジンの開発を進めるためには「○○の状況では△△の予防コンテンツが適切」といった、答えのある過去の実績データが大量に求められるでしょう。それらがある前提で作った場合に、4,300万という数字を今回は出しました。

ただ、データは大量にあるものの、属性情報が足りないために適切な予測やレコメンドができないといった結果もあり得ます。やってみないと分からないのは、AIの難しい点ですね。このケースでは事前学習が絶対に十分であると断言できないので、AIモデルがない状態なら、そのモデルを既存データから作って、有効な結果を導き出せるかどうかの検証に投資をするところから始まると思います。金額の幅についても超概算の定義に入れられないほどに未知数で、研究投資のようなものが最初に必要になると考えたほうがよいでしょう。

周りから承認をもらうのに困っている

Wu：最後のケースは、どの企業でもあるあるな内容かと思います。今回は従業員数1万人以上の企業をペルソナとしていますが、お二人ならどんなアドバイスをしますか。

本村：前の2つのケースも踏まえて考えてみると、あれらは機能の提示はできていても、得られる成果については言及されていませんでした。そのため、船木さんが出してくださったような概算をこのテーマの状況で上申しても、おそらく取り下げのリスクが高いだろうと思います。

「3D CADデータとシミュレーション結果を基にした解析による予測AI」とありますが、その一点に着目した稟議からは脱却したほうがよいです。つまり、その一連の取り組みのなかで自社にどんなアセットが残るかや、他の部署にどれほどの影響を及ぼす技術が生まれるかなど、「これを通じて得られるアウトカムを全社に展開した際にどうなるのか？」という広い視点を持つことが望ましいのではないかと。

基本的に、決裁者はベンダーとの細かいすり合わせまでは聞いていないので、現場とは知識や理解のキャッチアップ度合いに明らかにギャップがあります。そこでカギを握るのがいわゆる社内政治、つまり根回しです。かのハーバードビジネスレビューでも「イノベーションのためには社内政治が重要」と言われていますし、巻き込むステークホルダーを自分と決裁者にとどめず、より多くのメンバーで稟議に臨むためのテクニックや、最終形態に近い姿のアウトプットが意思決定者を納得させるのに有効という研究もあります。

最終ゴールを目指すための稟議を出す前にペーパープロトタイピングを想定ユーザーに当てて実現性の解像度を上げたり、Figmaベースでフィードバックの声を集めるといったことは、いきなりプロジェクトを作るところから始めなくてもできると思います。その成果と最小限のプロトタイプを決裁者の稟議なく、自分の予算の範囲内で用意できれば、上申の際の納得度も上がるはずです。

私もお客様の新規事業推進の支援をしているときに、上長にプレゼンテーションをしてもなかなか了承を得られないことがありました。しかし、モノを見せながら説明したところ、「そう、それが言いたかった！」と言われ、あっさり話が前に進んだ経験があります。やはり、ロジックよりも最終形に近い世界観を見せるほうが大事なのではないでしょうか。

船木：私は、新規事業に対しての会社の意思決定のフローや“態度”が重要だと考えています。これは方々でお話していることですが、VCはIRR期待でいうと40～50くらいで、5年間で6倍のゲインを得る、奉仕のような形でやっているんですよね。つまり、新規事業で淘汰された結果、どのような投資判断をして定位できるのかという研ぎ澄まされた関係性が、スタートアップとVCの関係性だと思っています。ですので、「ほとんどの新規事業は当たらない」という大前提のもと、当たったときにちゃんとペイできるようなことを考えましょうといったことは、会社の中の事業立ち上げでも学ぶべきなのです。

売り上げを見たとき、「この方針で1本当たれば十分」という投資判断で最初から構えておけば、極端な話ですが1,000万～2,000万くらいは捨てられます。そもそもみんなが当たるプロジェクトに予算投資をすることは不可能なので、数を打ちましょうということです。会社としてありたい未来を描き、ROIとして十分に投資効果もあり、1,000万～2,000万でチャレンジができるのでやらせてくださいというのが、おそらく新規事業におけるフェアな関係なのだと思います。

Wu：船木さんが話してくれたような関係性がベースとしてあればベストですが、目の前では社内政治や抜け穴を使って前に進めるしかないのかもしれませんね。ただ、再現性のある考え方としては、作って見せたほうが早いというのは各社に言えそうです。