0→1段階のプロダクトは“はじめの90日”で土台を作る　「失敗を許容できる環境作り」のためにPMが取り組んだこと

武政氏の自己紹介

武政成彦氏：よろしくお願いします。私はアダコテックの武政と申します。今、0→1から1→10にちょうどかかっているようなフェーズですが、そこの1人目のPM（プロダクトマネジャー）として入りました。

入社して最初の90日間で、けっこう挑戦的なことをいっぱいしなければいけなかったんですが、その中でも大事だったのが、進歩的な失敗に対して耐える土台を作ることです。このフェーズではとても大事だなと思ったので、今日はそのあたりを共有させてください。

（スライドを示して）まず自己紹介ですが、あらためて、私は武政と申します。これまでのキャリアの軸は、プロダクトを中心にいろいろな成果を作ることをやってきました。

直近の経歴で言うと、ラクスルという印刷のプラットフォームをやっている会社があるのですが、その1領域で事業責任者とプロダクトマネージャーを兼務していました。そして、ちょうど明日かあさってで1年になりますが、2021年の9月にアダコテックにPMとして入社して、6月からCPO職をしています。

これまで経験した職種は、例えばバックグラウンド的なところで言うと、初めにメーカーに入社して、商品企画やプロダクトデザイナーを、ビットではなくアトムでやっていました。そこから徐々にITに、事業を作るほうに寄っていって、今はプロダクトマネージャーのラベルを名乗っています。

アダコテックという会社に入社した経緯をnoteで公開しています。「1人目プロダクトマネージャーの採用プロセス全公開」としてプチバズりもしたので、もし、興味があればググってご覧ください。

アダコテックの紹介

（スライドを示して）弊社アダコテックのご紹介を簡単にすると、大半の方が「初めて聞く会社だな」と思っていると思います。我々は製造業の分野で“検品”という、工場のラインで傷がないかとか、OK、NGなのかを判断する工程があるのですが、そこを自動化するための特許技術のAIの学習環境や、実行環境を提供しています。

ビジョンには「モノづくりの進化と革新を支える」というものを掲げています。産業技術総合研究所という国の研究機関がありますが、そこの特許を事業化するベンチャーを前身として設立しています。現在、社員数は20人と、まだ小さい会社ですが、累計の調達金額は20億円ぐらいで、これからどんどん大きく事業とお客さまの価値を作っていくフェーズになってきています。

お客さまとしては、自動車メーカーや電子部品や半導体メーカーにお取引いただいています。いわゆるDeeptechと言われるような分野です。

スタートアップのBtoBの事業の0→1段階

（スライドを示して）今日お話ししたい内容は「事業開発や事業の0→1段階では、PMF（Product Market Fit）までにたくさんの失敗を許容できるプロダクトマネジメントが重要」ということをシェアしていきたいと思います。

今日の話の前提ですが、「スタートアップのBtoB事業、0→1ってどんな状態なんだっけ」という前提確認からシェアさせてください。やっている人には「あ～」という感じですが、あまり経験したことがない人には「あ、そうなんだ」みたいな感じになると思うので、ここはけっこうおもしろいかなと思います。

（スライド示して）例えば、これはどんな状態かと言うと、よくPMFの話があると思うのですが、そこの達成を目指す探索段階のところです。ひたすらトライアンドエラーを繰り返すようなフェーズになっています。

左側の「PMF達成までのプロセス」で青文字で書いてあるところが、まさに常にやっていることです。「ちゃんと事業として成長可能な」という前提のもとに、市場の選定、ターゲットの特定、お客さまの課題の特定、お客さまの要求を満たす解決策の特定。そして、そのお客さまたちを何倍にもしていくためのプロダクト開発が、0→1でやっていくことと言われています。ここがうまく達成できるとPMFして、そのあと1→10や10→100の拡大をしていく感じになっています。

このPMFもけっこうくせ者で、いろいろなルートがあります。それが右側の図です。青いAという線とBという線がありますが、下が時間軸で、上がARR（Annual Recurring Revenue）や売上の話ですが、どのルートを描くかで、1年後や3年後に大きく結果が変わってきます。

例えば、現在から1年後を見ると、ABルートも同じ3億円です。それが3年後に10億円になるのか4億円で止まるのかというところで、逆算して1年後の状態を描いてどんどん開発をしていくとか、お客さまにサービスを提供していくことが重要になってきます。

0→1段階のプロダクトの課題

（スライドを示して）事業はそういう感じですが、そこでプロダクトがどのような課題を抱えるかという話です。これはけっこうあるあるで、事業進捗や新しい事実はすごく歓迎すべきことですが、それによって前提条件が容易にひっくり返ります。

一方で、僕らはスタートアップなので、資金を調達して投資していただいて、それが尽きる前に、お客さんに対して価値の高いプロダクトを作るのが生命線になってきます。これはけっこう矛盾するような内容かなと思っていて。

具体的にどういうポイントが難しいかと言うと、やはりPMFに至るような良質な解決策は、進歩的な失敗、トライ・アンド・エラーを繰り返して、はじめてもたらされる状態です。

一方で、プロダクト投資はみなさん知っていると思いますが、メチャクチャ重いです。1回作ると、間違っていても変えられない状況です。こういう状況は「プロダクトさえあれば」みたいなワンチャンを狙いに行く世界で、「PMを採用したらなんとかなるかも」と期待するポイントも多いですが、そういうワンチャンはない世界です。ちゃんと着実に前に進めていくようなプロセスが必要になってきます。

（スライドを示して）そういう前提があって、ちょっと追記していますが、0→1段階では初手の施策はうまくいかないので、ちゃんとたくさんの失敗を許容できるような、開発対象の見極めをしっかり行ってプロダクトマネジメントしていくことが重要になってきます。

アダコテックのPMが取り組んだ全社での目線合わせ

（スライドを示して）ここからが、アダコテックのPMはどう取り組んだかという事例です。これは私の話ですが、一定の効果と再現性が見えている事例があるので、そのあたりはぜひシェアしたいなと思っています。

最初にやったことが、プロダクトの役割について全社で目線を揃えることで、これがとても大事です。みんなが見ている方向が違っていたり、プロダクトに対して期待する役割がずれていると、あっちに行ったりこっちに行ったり、迷走しちゃうんです。

なので、まず「アダコテックにとってのプロダクトは何だっけ」ということを、ちゃんとみんなで握りました。弊社が定義しているのは「上手な課題の解決方法を誰でも再現できるための道具である」ということです。

一方で、解決方法を「その時点で固定化してしまう諸刃の剣である」と定義して、その上でやること・やらないことを決めました。

やることは、事業上の事実と固定要因への投資です。これはどういうことかというと、いろいろな事業のパターンがあって、その中で共通するものと、パターンによってまったく異なる変動要因があります。

固定要因は、「どのルートを行ってもこれは大事だよね」というもので、固定に対して集中的に投資をするような意思決定をしています。

2番目に、ユースケースの再現性が高いところへの投資です。ユースケースも幹や枝葉という言い方をすると思いますが、枝葉はやはり変わってしまうので、ちゃんと幹に対して投資をしていきましょうというところです。

最後に解決策は、ちゃんとPDCAを回した後にプロダクトにするのが、けっこう大事なポイントかなと思っています。脊髄反射でアイデアをプロダクトに乗せてしまうと、それをずっと使うことになるので、けっこう危ない話です。ということを最初にしっかり握り、これによって目線を揃えました。

過不足ない解決プロセスの設計のための3ステップ

（スライドを示して）その上で手戻りを最小限にするような、過不足ない解決プロセスの設計に取り組んできました。BtoBのプロダクトは、お客さまへの提供価値と同時に、提供するためのオペレーション設計が必要になってきます。

弊社はそこを磨き込むために、ちゃんとプロダクト未満の状態でPDCAを回した解決手段を、（最終的に）プロダクトにすることを徹底してやっています。それは大きく3ステップになっています。

まず1ステップ目です。解決手段をまず力業で提供するところで、これは「気合いでがんばる」みたいなフェーズです。例えば、お客さまの要求水準をちゃんと超えていかないと入れてもらえないので、まずはそこは超えていきましょうと。効率は気にしません。ここは社員がちゃんと手段を提供して、モノに関しても、Excelやスプレッドシートなど、あるものでがんばって提供しましょうというところです。

それで一定水準を超えてきたら、次にオペレーションの磨き込みのところです。ここがプロダクト未満と呼んでいるポイントです。

ベストプラクティス、うまい解決策の模索です。それによってオペレーションの生産性を改善していくフェーズになっています。ここは社員やインターンが取り組むようなポイントです。

ここはプロダクト未満という言い方をしていますが、例えば、データベースのスキーマや構造を変更可能な状態でPDCAを回せるような状態です。コードベースの自動化がそれに当たるとは思います。それによって一定自由度を担保しつつ、どんどん磨いていこうぜみたいなフェーズが、2番の磨き込みになっています。

そこでうまいやり方ができたら、はじめて解決手段をプロダクトで再現していくフェーズに移る運用をしています。ここでは、お客さま自身が自分でベストプラクティスを再現できるようにすることを、プロダクトの役目として捉えています。なので、お客さま自身がプロダクトとして使います。この時点では、データ構造のスキーマも固定しています。

プロダクトの典型的な失敗パターン

（スライドを示して）今なぜそういうやり方をしているかということに対して、反対の典型的な失敗パターンです。これはどの立場でも、プロダクトを作ってきた人のあるあるだと思うのですが、一番つらいのは、作ったものを使ってもらえないとか、使ってもらえていないのに保守コストだけを払い続けるような状態です。このプロセスは「それを防ぐためにはどうしたらいいか」という考え方で作りました。

（スライドを示して）ABがアンチパターンです。Aは仮説でいきなりプロダクトを作っちゃうところですね。これもけっこうあるあるだと思いますが、そもそもお客さんへの提供価値が間違っている可能性が高いです。作り直すのに膨大なコストがかかります。

Bはもうちょっとマシですが、解決策が未熟なままプロダクトを作っちゃったみたいなところですね。これの良くないポイントは、現場のオペレーションを簡単に改善できないので、プロダクトが生産性や改善の足を引っ張る状態になってしまいます。これが起きてしまうと、みんなが「使いにくいな」と漠然と思いながら、「でも作っちゃったから売らないと」みたいな、つらい状況になります。

このA、Bを防ぐためには、ちゃんとPDCAを回した解決手段を、お客さまが再現できるようにプロダクトを作ること（が必要）で、ラスト3ステップが大事かなと思っています。

解決手段の目安感で言うと、「社内でこのやり方が2～3年は耐えられるよね」「確度高く使えるよね」というレベルに改善して、プロダクトにしてお客さまに提供するのが大事かなと思っています。

（スライドを示して）ここの2～3年間はけっこうざっくりしていますが、僕らスタートアップの場合は、だいたいこれぐらいのスパンで新しい資金調達の時期が来て、新しいお金とリソースが手に入ったりするので、そのタイミングで必要があれば作り直しましょうぐらいの心持ちです。