50代でAIベンチャーに飛び込んで気づいたこと
50代になって、AIベンチャーに飛び込んだ。
それまで長く、事業会社側でシステム開発やPM、アーキテクトとして仕事をしてきた。
要件定義をして、業務を整理して、関係者の話を聞いて、システムに落とす。
どちらかといえば、地味な仕事である。
一方、AIベンチャーに来ると景色が違う。
新しいモデルが出る。
新しい手法が出る。
生成AI、AIエージェント、VLM、ベイズ、クラスタリング。
技術の進化が速い。
そして顧客からも、
「AIで何かできませんか」
という相談が来る。
そこにいると、どうしても思考の出発点が、
「AIでどう解くか」
になりやすい。
最近、若手メンバーからある案件を引き継いだ。
テーマは、価格改定のAI化だった。
商品数が多く、人手では価格判断が追いつかない。
そこで、
AIで商品をグルーピングする。
価格弾力性を推定する。
ベイズ推論でリスクを出す。
AIエージェントで例外商品を洗い出す。
最終的には価格決定を自動化する。
提案としては、きれいだった。
若手らしく、技術の選択肢も豊富だった。
データもかなり見ていて、価格変更前後の傾向や、データ品質上の問題も見つけていた。
だから、技術案そのものを否定する気はなかった。
ただ、引き継いで全体を眺めたとき、少し違和感があった。
そもそも今、価格はどうやって決めているのだろう。
この問いが抜けていた。
若い頃なら、自分も同じ提案をしていたかもしれない
これは若手が悪いという話ではない。
むしろ、AIベンチャーで「価格をAI化したい」と言われたら、AIの技術で考えるのは自然だ。
自分が若い頃なら、たぶん同じだったと思う。
新しい技術を覚えれば、使いたくなる。
難しい手法を知れば、案件に適用したくなる。
それは健全な成長でもある。
ただ、50代になって長く企業システムを見てきたからなのか、今は少し違うところを見るようになった。
技術より先に、
「今、この会社はどうやって意思決定しているのか」
を見る。
価格改定ひとつ取っても、実際の業務はかなり複雑だ。
原価を見ているのか。
競合価格を見ているのか。
粗利率なのか。
販売数量なのか。
成約率なのか。
営業担当者の感覚なのか。
商品カテゴリごとの慣習なのか。
経営戦略上の判断なのか。
さらに、
「なぜこの商品を値下げしたのか」
という理由が、システムには残っていないこともある。
データだけを見れば、間違った結論にもなる
例えば、ある商品を20％値下げした。
しかし、その後の成約率はほとんど変わらなかった。
データだけを見ると、
「値下げする必要はなかったのではないか」
と思う。
しかし、本当にそうだろうか。
競合が30％下げたため、20％下げてシェアを守ったのかもしれない。
原価が下がったのかもしれない。
戦略商品だったのかもしれない。
別の商品群と一括で改定されたのかもしれない。
つまり、
何が起きたか
はデータから見える。
でも、
なぜそうしたか
は、業務を知らないと分からない。
ここを飛ばしてAIを作ると、AIは人間の意思決定を再現するのではなく、単に過去の結果を学習するだけになる。
これはAI案件ではなく、まずDX案件なのではないか
そこで、案件の見方を変えた。
「価格自動決定AIを作る案件」
ではなく、
「価格改定の意思決定プロセスを高度化する案件」
と考えた。
そうすると、最初に必要なのはモデルではない。
要件定義になる。
誰が価格を決めているのか。
どんなデータを見ているのか。
どこまでがルールなのか。
どこからが担当者判断なのか。
どんな例外があるのか。
誰が承認するのか。
価格変更後に何を評価しているのか。
まずAs-Isを整理する。
そこから、
ルールで置き換えられる部分。
統計で支援できる部分。
AIでなければスケールしない部分。
人間に残すべき部分。
を分けていく。
ここまで来て、初めて技術選定になる。
50代でベンチャーに来て思うこと
ベンチャーには勢いがある。
若いメンバーは新しい技術へのキャッチアップが速い。
実装も速い。
試すことを恐れない。
これは大きな強みだと思う。
一方で、長く企業システムを見てきた人間には、別の役割があるのかもしれない。
新しい技術を一番早く知ることではない。
コードを一番速く書くことでもない。
「その前提、本当に合っているか」
と聞くこと。
AIをどう使うかではなく、
そもそも何を解くべきなのか
を問い直すこと。
若いエンジニアが解法を考え、
ベテランが問題設定を疑う。
これはかなり相性がいい。
50代でベンチャーに入ってみると、若い人と同じ土俵でスピード勝負をする必要はないのだと思うようになった。
むしろ、
過去に何度も見てきた失敗。
要件が曖昧なまま始まったプロジェクト。
技術ありきで作ったものの、業務に定着しなかったシステム。
PoCだけ成功して本番に進まなかった案件。
そういう経験が、意外なところで役に立つ。
AIベンチャーあるある
AIベンチャーでは、こんな流れになりやすい。
顧客：
「AIで何かできませんか？」
ベンダー：
「できます。クラスタリングして、ベイズで推論して、AIエージェントで……」
ここで一度止まりたい。
いや、そもそも今どうやって決めているんだ？
地味な質問である。
生成AIも出てこない。
Transformerも出てこない。
ベイズもまだ出てこない。
でも、企業システムでは、たぶんこの質問の方が重要だ。
高度なAIは最後でいい
ベイズ推論も、AIエージェントも、使える可能性はある。
ただし最後でいい。
まず業務を見る。
データを見る。
単純な集計をする。
価格変更前後を見る。
ベースラインを作る。
そこで初めて、
商品ごとのデータが少なすぎる。
不確実性を含めてリスクを出したい。
大量の商品を人手では処理できない。
という課題が見えてくる。
そこにAIを使えばいい。
技術は、課題の結果として選ばれるべきである。
PMが引き継ぐ意味
今回、若手から案件を引き継いで思った。
エンジニアやデータサイエンティストは、
「どう解くか」
を考えるのが得意だ。
PMやアーキテクトは、
「そもそも何を解くか」
を見る。
若手案を見て、
「ベイズではなく別のモデルにしよう」
と言うだけなら、技術レビューで終わる。
でも、
「その前に、現行の価格改定業務そのものを見よう」
と変えると、案件の形そのものが変わる。
たぶん、長く企業システムをやってきた人間がAIベンチャーに入る意味は、こういうところにある。
AI案件を始める前に確認したい7項目
- 現在、誰が意思決定しているか
- 何を根拠に判断しているか
- 判断ルールは明文化されているか
- 例外判断は何か
- 成果を測るKPIは何か
- 必要なデータは存在するか
- AIに任せたいのは「作業」か「判断」か
おわりに
50代でAIベンチャーに入ると、若い人たちのスピードに驚くことがある。
新しいモデル。
新しいツール。
新しい開発手法。
どれも面白い。
でも、自分まで同じ走り方をする必要はない。
若い人がアクセルを踏むなら、
ベテランは地図を見る。
本当にその道でいいのか。
目的地は合っているのか。
そもそも、何のために走っているのか。
AI案件でも同じだと思う。
AIを使うことが目的ではない。
より良い意思決定の仕組みを作ることが目的である。
そして、そのことを一度立ち止まって確認する役割は、
意外と50代のベンチャー社員に向いているのかもしれない。
AI導入を検討している企業の方へ
もし今、
「AIで何かできないか」
「この業務をAI化できないか」
というところから検討を始めているなら、最初から技術を決める必要はないと思っています。
まず整理すべきなのは、
- 現在、その業務がどう回っているのか
- 誰が、何を根拠に判断しているのか
- どこに時間がかかっているのか
- どこが属人化しているのか
- 何を改善できれば事業上の価値が出るのか
という部分です。
その結果、AIが最適ならAIを使えばいい。
ルールベースや統計モデルで十分なら、それでもいい。
重要なのは「AIを導入したこと」ではなく、業務や意思決定が実際に良くなったかどうかです。
AIベンダーに相談するときも、
「どのAIを使いますか？」
だけではなく、
「この業務のどこを、なぜ変えるべきだと考えますか？」
と聞いてみると、そのベンダーが技術起点なのか、業務起点なのかが少し見えてくるかもしれません。
AIの活用方法がまだ明確でなくても構いません。
むしろ、その状態から業務と意思決定を整理し、AIを使うべき場所を一緒に見つけるところに、AIプロジェクトの本当のスタートがあると私は考えています。
