Merge pull request #1761 from future-architect/feature

新規事業

Author: ma91n

source/_posts/2026/20260209a_新規事業開発にて「ITやAIは目的ではなく手段である」と再確認した話.md

@@ -0,0 +1,164 @@
+---
+title: "新規事業開発にて「ITやAIは目的ではなく手段である」と再確認した話"
+date: 2026/02/09 00:00:00
+postid: a
+tag:
+  - 新規事業
+  - デザインワーク
+category:
+  - Business
+thumbnail: /images/2026/20260209a/thumbnail.png
+author: 土屋建
+lede: "ITを主軸に仕事をしてきた人間が新規事業開発の「仮説検証」を行った際に直面した壁とそこから得た気づきについて共有できればと思います。"
+---
+
+<img src="/images/2026/20260209a/top.png" alt="" width="800" height="714">
+
+## はじめに
+
+こんにちは。Core Technology Groupに所属する土屋です。
+
+本記事では、ITを主軸に仕事をしてきた人間が新規事業開発の「仮説検証」を行った際に直面した壁とそこから得た気づきについて共有できればと思います。
+
+## このブログを3行で
+
+* 社内の新規事業開発ピッチに参加した。
+* AIとの壁打ちだけで、顧客ヒアリングをした気になってはいけない。
+* 「まずはIT実装」は危険。初期コストが新規事業のボトルネックになり得る。
+
+## 私の生い立ち
+
+私は学部・大学院ともに情報系に所属し、大学院では画像解析を専攻していました。
+フューチャー株式会社に入社後もPoCや社内R&Dで一貫して開発を行い早3年たちました。
+
+## 参加した社内の新規事業開発ピッチについて
+
+当社には、社員の新規事業への取り組みを応援する仕組み、通称FIBP（Future Innovation Boost Program）があります。
+
+プログラムの詳細は以下をご参照ください。
+
+- https://note.future.co.jp/n/ndd2493c4541d?magazine_key=mc4cc99038085
+
+今年度は大きく外部講師による新規事業開発の講義と参加者の実際の仮説検証からなり、最終的にスタートアップ投資委員会のメンバーやFIBPに関わっている先輩方へピッチを行います。
+
+本ブログでは、このプログラムで私が実際にぶつかった2つの壁とそこからの学びを中心に述べたいと思います。
+
+## 第1の壁：顧客との接点の壁と逃げのAI
+
+私は「海外進出支援」という大きなテーマから深堀りし、新規事業を作れないかと考えました。
+
+まず最初に行うのは課題を抱えている企業担当者へのヒアリングです。
+
+しかしこれが想像以上に難しかったです。特に **「課題を持っている人」とつながること自体が非常に困難**でした。
+
+### 門前払いの連続と、課題の解像度の限界
+
+最初に試したのはメールです。
+
+色々な企業にお話を聞かせてくださいとメールを送りましたが、ほとんどメールに返信がありませんでした。冷静に考えれば、相手企業の利益につながる明確なメリットがなければ、メールにリアクションなんてしてくれないのです。
+
+**プロダクトを作るには、解像度の高い課題のヒアリングが必要です。**
+
+しかし解像度を高めるためのヒアリング先が見つからず、解像度が低いままプロダクトを作っても結局誰にも刺さらないゴミが出来上がってしまいます。
+
+### 「AIとの壁打ち」≠「顧客ヒアリング」
+
+アポが取れないと、つい手元のAIに頼りたくなります。今の時代、AIと壁打ちすれば「もっともらしい課題の仮説」はいくらでも作ることができます。
+
+しかし、その課題を「本当に」抱えている人はどれだけいるのでしょうか？そして、その課題を解決することに対して、顧客は本当にお金を払う価値を感じてくれるのでしょうか？
+
+プログラミングでAIを使う際、出力されたコードはテストや動作確認などですぐに検証できます。テストが通ったからといって「良いコード」とは限りませんが、少なくとも「動作する」という品質の最低ラインは保証できます。
+
+一方、事業開発における「市場仮説」の検証において、テストや動作確認などの役割を担うのが、**「顧客へのヒアリング」** です。
+
+AIが出したもっともらしい仮説も、顧客にぶつけてフィードバックをもらわない限り、テストをしていないコードと同じで、動く保証がどこにもないのです。顧客に何度も会って、仮説に対する生のフィードバックを何度ももらい、修正し続ける必要があります。
+
+**AIと会話して顧客と話した気になってはいけません。**
+
+「課題解決を手伝ってくれるパートナー」を早期に確保し、関係性を継続することがいかに重要か。普段、当社のプロジェクトがお客様との良好な関係を継続していることのすごさを改めて痛感しました。
+
+（ちなみにですが、最終的には名刺交換会などの対面が一番連絡を取りやすかったです。）
+
+## 第2の壁：「いきなりITで解決する」の罠
+
+何とか課題の輪郭が見えてきた後の話です。
+
+技術がわかる人であれば誰しも一度は陥る最大の罠があります。「あれもこれも作りたい」という実装欲です。
+
+私も御多分にもれず、ITを通した解決策ばかりが頭をめぐりました。色々ITでの解決を妄想するのはとても楽しいのですよね。特に昨今はAIの進化が目覚ましく、「あれもできる、これも自動化できるだろう」と夢が広がってしまいます。
+
+しかし、冷静になって事業計画（コストと売上）を立ててみると、**「いきなりITで解決する」ことの不合理さ** を体感しました。
+
+### 1. 見えにくい「開発・保守コスト」の積み上げ
+
+アプリで課題解決をする場合、コードを書く以外にも多くの「付帯コスト」がかかります。
+
+* **決済機能の実装：** マネタイズするなら必須ですが、Stripeなどを組み込むだけでも相応の実装・検証コストがかかります
+* **AIの不確実性：** 「AIで自動化」は言葉にするのは簡単ですが、意図した出力を安定させるにはプロンプトの膨大な試行錯誤が必要です
+* **APIの改廃リスク：** 外部APIは仕様が変わったり停止したりします。特にAI関連のAPIは改廃が早く1年以内にサービス終了することも多いです
+
+### 2. 「サブスクモデル」の収益化の遅れ
+
+ITアプリの多くはサブスクリプションモデルになるでしょう。
+
+しかしこれこそが初期の新規事業の足かせとなる可能性があります。
+
+売上は「単価×有料ユーザー数」です。ユーザー数を増やすには地道な営業か広告宣伝が必要です。認知のない初期フェーズでユーザーを集めるにはかなりの広告費がかかります。開発費に加えて広告費がかさむ一方で、月額の売上は雀の涙です。
+
+累計黒字化がはるか先になってしまいます。
+
+### 3. 検証サイクルの鈍化
+
+これが最も致命的かもしれません。
+
+ITのアプリをしっかり作りこもうとすると、それこそAIの検証などもあるため、リリースまで半年～1年はかかります。その間、市場の反応は見られません。「一年かけて苦労して作ったのに、出してみたら誰も使わなかった」が起こりえてしまいます。
+
+このリスクを抱えたまま開発を続けるのはあまりに不健全です。
+
+## 2つの壁からの気づき
+
+### 1. 「AI依存」への自戒と、ヒアリングの重要性
+
+どんな新規事業でも、多くの顧客が本当に解決したい課題でなければ市場に受け入れてもらえません。
+
+**仮説の精度を高めるためには、必ず「人間」からのフィードバックが必要です。**
+
+昨今のAIは非常に優秀で、相談すればとても賢い回答をしてくれます。そして多くのAIはユーザーの考えを肯定して褒めてくれることが多いです。
+
+そんな優しいAIとばかり壁打ちを続けていると、思考がどんどん現実から離れていってしまいます。AIは仮説検証の補助ツールとしては優秀ですが、仮説の検証はできません。お金を払うのは、AIではなく人間です。
+
+一緒にFIBPで仮説検証を行った方とも話しましたが、「AIには出せない、人間だからこそ出せる価値」とは、 **「現実の他者との対話から得られる一次情報」** にあると考えています。
+
+### 2. ITは「拡張ツール」である
+
+一度立ち止まって考えてみます。
+
+パートナーの課題を解決するのに、最初からITは本当に必要なのでしょうか？規模と時間さえ度外視すれば、ITでできることの多くは、人力でも代用可能です。
+
+**ITの本質的な価値は「省力化」と「規模拡大」** だと考えています。
+
+だとするならば...
+
+1. 最初の数人の顧客に対してはITを使わずに人力で手厚く課題解決して対価をもらう。
+2. そこで確実な収益を得て、その収益を元手に規模を拡大し、利益率を上げるためにITで作業を代替していく。
+
+...この順序が正解だと考えています。
+
+1はいわゆるPoCと呼ばれるものですが、PoC後も人手による課題解決は多分に残っても良いと私は考えています。人手の収益化をゴールにおいてはいけませんが、IT実装を見据えすぎてもよくありません。
+
+私はITが好きでつい「How（どう作るか）」から入ってしまいます。しかし顧客がお金を払うのは「ITシステムそのもの」に対してではなく...
+
+**「課題が解決されたという事実」** に対してです。
+
+ITという手段に盲目になってはいけませんでした。
+
+## 最後に
+
+今回のFIBPプログラムを通じて新規事業開発における重要な点を2つ学びました。
+
+1. 入念な顧客ヒアリングをし、課題の解像度をとにかく高めること。
+2. 課題の解決策をITありきで考えないこと。
+
+いろいろな方がすでに体感している当たり前のことかもしれませんが、
+
+これから新規事業に挑戦する技術者の方々へ、少しでも参考や気づきになれば幸いです。