こんにちは、生成AI事業開発・データサイエンティストのikegameです。
最近当社では、「60％最速」すなわち「60%の成果物を最速で出す」という行動指針を掲げています（ご参考：エモーションテックという船の加速度をあげるために｜エモーションテック）。
最初から完璧を目指すのではなく、周囲からフィードバックをもらえる回数を増やそう、という考え方ですね。
この指針は、他の行動指針に比べても、意識できている社員が多いように思います。プロダクトチーム内でも「60%最速で」という発言がよく聞かれるようになりました。
ただ、この考え方は、理解しやすい反面、認識を誤るとプロダクトの崩壊にもつながり得る、諸刃の剣だと考えています。私たちも、この言葉を使う時は、非常に気を遣います。
今日はこの指針の正しい捉え方について考察してみようと思います。
※個人的な考察であり、組織やチームとしての意見ではありません。
60%とは何か
当たり前ですが、「60%最速」を意識する上で、まず「60%とは何か」を定義する必要があります。
例えば、「来週クライアントに提案予定のプレゼン資料、今週中に上司に見せておこう。60%最速で。」というシーンがあったとします。 この時、完成形が全10枚のスライドだったとして、「6枚目まで完成させたらいったん上司に見せよう」と考えている人がいたら、間違いなく上司からは落第点を受けるでしょう。
なぜなら、その資料には提案の「骨子」が描かれていないからです。骨子がなければ、その資料の良し悪しを正しく判断できません。 （多分その資料には、前段の「クライアントの課題」や「サービス紹介」などは作り込まれている一方、肝心な「プランの提示」や「見積もり料金」が書かれていないと思います。）
見方によっては、「6割完成させたのだから、60％最速の行動じゃないか」と捉えることも可能ではありますが、上司からすると「この提案資料がもたらす価値」がわからない以上、60%どころか、0%＝無価値です。 言ってしまえば「60%拙速」です。
「そんなことするのは新入社員くらいだろ」と思うかもしれませんが、プロダクト開発の現場でも、残念ながら起こりうるケースです。
プロダクト開発における「60%」の罠
プロダクト開発においても、「60%最速」というアプローチは、迅速な価値検証と早期の軌道修正を可能にする強力な戦略です。
しかし、この「60%」が指し示す「この機能が生み出す価値」について組織内で明確な合意がない場合、意図せず「価値不在の60%」を生み出してしまう「罠」に陥ることがあります。
例えば、営業支援ツール（SFA）に新たに顧客分析機能を搭載するという例があったとします。
開発チームは「60%最速」を掲げ、顧客データを様々な角度から集計し、グラフや表で可視化するダッシュボードの「見た目」を素早く作り上げました。
しかし、この例では、「営業担当者がデータに基づいて具体的な次のアクションを判断できる」あるいは「営業戦略の意思決定に繋がるインサイトを得られる」という分析機能が提供すべき本質的な価値（＝データの意味づけや示唆）という観点が抜け落ちたまま、リリースすることになりました。
つまり、検証するべき価値が完成しないまま、顧客に届けることになってしまった。（ここで言う「検証するべき価値」は、先述の提案資料で言うところの「骨子」ですね。）
ユーザーにとっては、たくさんのグラフや数字が並んでいるだけで、そこから「何を読み取り」「どう行動すべきか」が全く伝わってきません。「データは色々見られるようになったけど、結局、このツールで何ができるようになったんだっけ？」「分析結果をどう活かせばいいの？」と、フラストレーションが溜まる一方です。
最悪の場合、「この機能は使えない」と判断され、二度と触ってもらえなくなるかもしれません。
一方で、開発チームは、営業チームに対して「分析機能は60％完成しているはずです。ユーザーに使ってもらってフィードバックをもらってください！」と言ってしまう。
営業チームは、ユーザーから「よくわからない」「使いにくい」という声が上がってきても、「もうすぐ残り40%が開発予定で、もっと分かりやすく、もっと深い洞察が得られるようになる予定なので、それまでお待ちください…」と苦しい説明を繰り返すしかありません。
これでは、貴重なフィードバックの機会を失うだけでなく、顧客の期待値を下げ、信頼を損なうことにも繋がりかねません。
「骨子」を捉えた「60%最速」とは
では、私たちは「60%最速」という指針とどう向き合うべきなのでしょうか。
重要なのは、「何をもって価値とするか」そして「その価値を検証できる最小限の形は何か」を考え抜き、営業チームを巻き込んだ社内全員で共通認識を持つことです。
先のSFAの顧客分析機能の例で言えば、「単にデータを表示する」のではなく、「特定の課題（例えば、"今月アプローチすべき優先顧客リスト"や"失注リスクの高い顧客アラート"など）に対して、具体的な示唆を与えること」を最初の「骨子」として定義すべきだったのかもしれません。
その上で、その骨子を最もシンプルな形で実現できる機能セット（例えば、特定のロジックに基づいた顧客リストの表示と、その理由の簡単な説明）を「60%」とし、最速でユーザーに届け、その仮説が正しかったのか、ユーザーはその情報から行動に移せるのかを検証するのです。
この「骨子」がしっかりしていれば、たとえ初期の機能が限定的であっても、ユーザーは「なるほど、こういう視点で顧客を見ればいいのか」「次はこういう情報も欲しいな」といった、本質的なフィードバックをくれるはずです。
それこそが、「フィードバックをもらえる回数を増やす」という本来の目的に繋がるのではないでしょうか。
「ユーザーに届けたい本質的な価値の60%（＝骨子）を最速で届け、そこから学びを得て、残りの40%をより確かなものにするための手段」と捉えるべきです。
そのためには、
- プロダクトが解決したい課題と、提供するミニマムの価値（＝骨子）を明確に定義する
- その骨子を検証できる最小限の機能は何かを特定する
- それを最速で実装し、ユーザーに届ける
- 得られたフィードバックを元に、仮説検証と改善のサイクルを回す
このサイクルを高速に回すことこそが、「60%最速」の本質であり、真の価値だと考えます。
最後に
「60%最速」という指針は、正しく理解し運用すれば、プロダクト開発のスピードと質を飛躍的に向上させる可能性を秘めています。しかし、その解釈を誤れば、価値のないものを素早く作り続ける「60%拙速」に陥りかねません。
常に「ユーザーにとっての価値とは何か」「今、検証すべき骨子は何か」を問い続け、会社全体でその認識を合わせながら進めていくことが、この諸刃の剣を使いこなす唯一の道ではないでしょうか。
エモーションテックでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。「60%最速を体現するプロダクトづくり」に興味のある方は、ぜひ採用ページからご応募をお願いいたします。
