work
気が付くとまた事業とプロダクトの交差点に立っている
僕のキャリアは、ZOZOやヤフーといったIT企業でのデータ分析やマネジメントが土台となっている。そして前職である10Xでは、ネットスーパーのプラットフォーム運営に携わっていたが、その中で求められたのは、「どの部分をプラットフォームとして抽象化して機能提供し、どの部分をカスタマイズ対応や相手方の運用に任せるか」という、難易度の高い線引きだった。
現職のLayerX・Ai Workforce事業部では、これまでの経歴とは少し異なるテーマとして、主にエンタープライズ向けのAIプラットフォームを提供している。そして所属するチームでは、Deployment Strategistという役割を担うメンバーが多く在籍している。Deployment Strategistの詳細については、ぜひ以下の記事を参照していただきたい。
AI時代の新しいコンサルタント像「Deployment Strategist」 〜 Palantir モデルの解説
同じチームで働くメンバーは、今まで主にコンサルティングやプロジェクトマネジメントの経験を豊富に積んできたキャリアである場合が多い。その中で、データ関連業務やスタートアップのプラットフォーム開発を歩んできた僕の経歴は、少し異質かもしれない。
しかし、「複雑な課題や要件を構造化し、汎用化の道筋を探ってきた」という経験は、いまの環境でも大きな糧になっている。プラットフォームとしての磨き込みを行いながら、個社ごとにラストワンマイルを届ける。その過程で発生する無数の顧客要望を、プラットフォームの機能へと昇華させる。対象がネットスーパーの在庫データから、エンタープライズ企業の非構造化ドキュメントに変わっても、その難しさと面白さの本質は変わっていないと考えている。
個別要件最適化とプラットフォーム抽象化の終わりなきトレードオフ
Deployment Strategistは「特定ドメイン・アカウントのCPO（Chief Product Officer）」と呼ばれる。しかし、最前線で顧客に深く向き合いながら、同時に抽象的かつ中長期を見据えたプロダクトマネジメントを両立させることは、決して簡単ではない。
特にコンサルタントとして優秀であるほど、目の前のお客様の現状課題解決にフルコミットするあまり、個別最適に寄りすぎてプロダクトマネジメントの観点≒プラットフォームの抽象化や保守性とトレードオフになることも多い。だからこそ、個人の力だけでなく、組織全体の仕組みとしてそのバランスを担保している側面もある。
現在、僕が個人として担っている役割は大きく分けて以下の3つだ。
- ギャップの把握と横展開の模索：大規模なエンタープライズ顧客の導入プロセスで生じる要件要望を捉え、それを個別対応で終わらせず、共通機能として横展開可能かを考える。
- 優先順位の意思決定：個社とプラットフォームのバランスを取る役割として、ビジネス的な要望とプロダクトとしての要件を正しく切り分ける。顧客のペインを把握した上で、事業状況に合わせて横断的に優先度をつけ、開発方針を決定する。
- 開発チームへのスムーズな連携：PdMや開発チームが即座に着手・事に向き合えるよう、情報を網羅的に集めたり、事前調査やコミュニケーションを行う。
ここで僕個人が心がけている介在価値は、単に要望を開発へ横流しするような伝書鳩にならないことである。第一線のDeployment Strategistやお客様から上がってくる要望を把握しているものの、プラットフォームとして全てを上から順に実行することは悪手で、事業・プロダクトのバランスを見て優先度をつける必要がある。自身が介入することで、各々の向かう方向を少しでもアラインさせたり、三方良しで仕事がより楽になることを目指している。
とはいえ、黎明期であるが故に一歩誤れば、特定顧客に言われるがままに作ってしまったり、声の大きさが優先されてしまう可能性も否めない。僕はある意味、特定の顧客やプロジェクトに加担し過ぎることがないように、それでいて全方位が滞りなく進捗を生むことができるように、推進する立場である。
そう言う意味では、もはや自身は純粋なDeployment Strategistではないのかもしれない。
人間の介在価値と組織の自律分散
Ai WorkforceはAIを主軸に置いたプラットフォームではあるが、もちろん個人ツールとしてもAI活用は欠かせない。例えば現行業務や課題のヒアリング結果をNotebookLMに食わせると、ユースケース整理が効率化できる。
プロダクトのリポジトリを読み込ませれば、現状のコードやDB構造をわかりやすく解説してくれる。そのため、業務ユーザー・エンジニアの手を煩わせることなく、ユースケース・課題・方針策定をセットでドキュメント化できる。
また、すべてを中央集権的にコントロールする必要もない。最近では、FDE（Forward Deployed Engineer）を含めて現場のメンバーが自律分散的に開発を進め、各プロジェクトからプラットフォーム側へ直接Pull Requestが投げられるような素晴らしい循環も生まれてきた。
このように、AIの進化によって、コードリーディングや情報整理のハードルは劇的に下がった。
しかし個人の所管では、課題の言語化や要件の優先順位付けなどは、まだまだ人間が行うべき泥臭い領域だと実感している。ユーザーがどんなペインを抱え、何を期待しているのか。それは人間が現場で感じたままに書き出すのが一番精度が高い。
そして、黎明期のプロダクトにおいては、声の大きい顧客要望の勢いに押され、管理機能がおざなりになったり、言われるがままの機能を作ってしまったりする罠が常に口を開けている。
そうならないために、「これはいま着手すべきタイミングではない」「これはプラットフォームとして負債になる」などを横断的に俯瞰し、優先順位を決定することは、人間にしかできない重要な意思決定だ。すなわち意味するところは、ある要望者や顧客については要件の簡素化や後ろ倒しを泣く泣く飲んでもらうシチュエーションも、どうしても存在してしまうこととなる。
最近、前職時代から尊敬する人物が言っていた、「協調と牽制」というフレーズがよく頭に浮かぶ。事業とプロダクトの交差点に立つ者の心がけとして、この表現に勝るものは無いのではないと、実感する昨今である。
同時に、もしかするとAIエージェントがこれらを人格に類するものを持ってして判断するようになったとすれば、人間に残る介在価値は相手に対する「寄り添い力」なのかもしれない。
そしてデータ領域への次なる挑戦
これまでDeployment Strategistが所属するチームにおいて、「各案件を推進するに当たり、何を優先して取り組むべきか？」を考えてきた僕だが、最近はデータ領域のミッションも担っていく見立てとなっている。
事業の持続性を鑑みても、toBプロダクトである以上は、顧客に継続利用してもらうことが何より重要である。プロダクトの健康状態やROIの説明責任などは、今後尚一層増していくはずであり、その裏付けには正しい数量データも欠かせない。機能開発の優先順位付けを行うとしても、やらなければいけないことだらけの状態から一巡してきたとすると、定性だけの議論に限界が来ることも想定される。
また、Ai Workforceの裏側には、まだまだ黎明期・スタートアップならではの属人的で、オペレーション負荷の高い領域も残っている。Deployment Strategistとして、エンタープライズの複雑な要件と格闘し、プラットフォームの機能ギャップと向き合ってきたからこそ、どんなデータベース・どんな画面・どんなアクションのログが必要か、などは想像しやすくなったし、これまでのデータ関連業務経験とのかけ合わせが楽しみである。
他方、数字は嘘を付かないが故に、もしかすると目を背けたくなる事実を可視化することや、残酷な優先順位付けや意思決定に加担してしまう可能性もある。万が一その場合でも、協調と牽制の精神を忘れず、組織における分散的な自律活動を促しながら、事業とプロダクトのバランスをとる役割を担っていきたい。
いまの環境に身を置いて約9か月が経過したが、これまで言及したDeployment Strategist然り、かつて自認していたData Product Manager然り、入社当時は自身がどのような領域で価値発揮をすれば良いのか明確に想像できておらず、手探りで仕事を続けてきたところがあった。長きに渡る試行錯誤や、組織拡大などを経て、近頃ようやくどこでどんな役割を果たせば良いのか理解できたり、周囲に協力を仰ぐことができるようになってきた。
事業領域においても、膨大なドキュメントを構造化したり、マルチモーダルなデータの取り扱いに挑んだりと、AI本流では無い側面に光を当てたとしても取り組みがいがあるテーマが数多く転がっている。ここまで読んでいただいた方で、もしLayerXのAi Workforce事業部に興味があり、より理解を深めたい方がいれば、以下のリンクを辿っていただきたい。
