浦10Xは、ネットスーパーを始めることができるサービス「Stailer」を提供しています。ネットスーパーは毎年10～12％ほどの成長をしている市場で、15兆円ある店頭の小売り市場が流れてくる見込み(※出典：経済産業省「商業動態」、日本生活協同組合連合会HP、富士経済、一部自社調べ)もあり、非常に経済インパクトの大きい領域。利用者向けのECサイトはもちろん、業者側が注文が入った後の袋詰め、配送、在庫管理などをデジタルで提供するサービスです。

リリースは2020年5月で、当初はCEOやCTOが組織全体をリードしていましたが、23年8月末時点で社内にPMは8人います。現在、「お届け」「お買い物」などの業務ドメインに合わせた開発チームが5つ。旧来から続いている企業向けのチームもありますが、原則エンジニアのアサインはなく、BizDevやPMがアサインされている状態です。

組織について、簡単にこれまでの推移を説明します。22年4月に、ある1社を担当する「A社チーム」、複数企業のサービスローンチを支援する「ローンチチーム」、横断的にサービスを改善する「体験改善チーム」の3チーム体制に。同年9月にはローンチチームを「複数社チーム」に改め、特定の大企業を括って「B社チーム」を組成し4チームになりました。

その後、この度の組織変革によって、業務ドメインベースの5チーム+パートナーに向き合うチームのアサインの編成になりました。エンジニアは業務ドメインの開発チームにアサインし、PMは業務ドメインチームへのアサインと企業チームへのアサインの双方が存在しています。

浦組織変革の背景にあった課題は2つ。「PM含めた開発メンバー認知コスト増大」と「その場限り（アドホック）なカスタマイズ対応の蓄積」がありました。

例えば、A社の担当となったPMは、お客様、店舗スタッフ、配達スタッフ…と、全領域の課題把握と開発をしなければならない。把握しなければならない事柄が多く、負担が大きくなる傾向にありました。

また、企業ごとのチーム編成では個社の成長に深くコミットできる反面、パートナー企業ごとに個別の実装に追われる中で、長期的な視座に立った開発が進みづらい状況になります。種々の課題と向き合う中で、業務ドメインごとのチーム編成に切り替えることが適切ではないかと考え、開発体制の移行に踏み切ったのです。

浦組織の大きな変更なので、「エイヤ」でやってしまうと、組織が混乱してしまいます。そのため、3ヶ月間の移行期間を設け、複数のチームで小さく試して検証していました。移行期間では、コミュニケーションのハブになるPMを、いかに仕組み化してコミュニケーションフローを整備していくかに難航した印象があります。

個社ごとのチーム編成では「パートナー企業の課題にコミットする」ことに専念できました。しかし、機能別にチームを分けると「これはどっちのチームの課題か」の線引きが曖昧な課題も出てきます。こうした課題に対しては議論の場を設けるようにしています。また、開発チームごとに「何を達成すべきチームなのか」というミッションの策定をするようにしていました。

宮前先述した組織改革の背景にあった2つの課題「アドホックなカスタマイズ対応の蓄積」と「認知コストの増大」がどのように変化したのか、説明していきます。

まず、「アドホックなカスタマイズ対応の蓄積」ですが、現体制でより適切に対応できるようになりつつあると思っています。移行前はパートナー企業にとにかくコミットする体制だったため、プロダクトのあるべき将来像に沿った開発ができていないなどの課題がありました。移行後はプロダクトとしての将来像を共有した上で、長期的な視野で、カスタマイズの受け入れができるようになりました。

たとえば、私が担当している「お届けチーム」で、パートナー企業から「管理画面から～～な指示が出せるようにしたい」要望があったとします。この時、単に実装するのではなく、サービスとしての理想的なオペレーションがそもそも何なのか…といった議論が生まれるようになりました。結果的に、パートナー企業の要求を実現しつつ、プラットフォームの資産となるような提案が出来るようになってきていると思います。

もう1つの課題は、認知コストの増大。こちらも開発チームが絞られた領域を深く見ていくので、自分たちが向き合うべきことを深く理解できるようになっています。

移行前のチーム編成では、1つ1つのイシューに対して理解度高く要求をこなすことが出来ていました。一方で、自分たちで課題を見つけて自分たちで解決する──といった動きがいまに比べて弱かったと感じています。

企業ごとの対応だったので、ノウハウもたまりづらい側面がありました。開発チームになることで、自分たちが担当している領域にオーナーシップを持てるようになり、プロダクトに対する理解が深まっている実感もあります。

宮前移行後、新たに課題も見えてきました。代表的なものが次の3つです。

1． 事業のイシューにどう向き合うか
2． チームをまたいだロードマップ作り
3． 各種プロセスのメンテナンス

1つずつ説明していきます。まず「事業のイシューにどう向き合うか」。現体制では自分たちの領域に対してのオーナーシップが強まり、知識が深まることがメリットでした。一方で、事業全体として考えるべきイシューを自分たちの領域に閉じて考えてしまうような状況が生まれてもいます。

担当しているお届けチームに引きつけて考えてみます。「注文を受けて配送できる総量を増やしたい」といった課題があるとき、本来であれば、お買い物チームやお会計チームと連携して最適なものを生み出す必要があるでしょう。しかし、お届けチームを担当していると、どうしてもお届けチームを起点に考えてしまう。これが、直近で起きている課題です。

2つ目は「チームをまたいだロードマップ作り」。現体制では当初、各チームにパートナー企業各社の要望（課題）を割り振ってロードマップを作るようにしていました。しかし、チームをまたがって解決すべきアイテムについて、各チームごとで優先度に差があったりして、何をやるべきなのか適切なアロケーションができていない状況がありました。

この課題は今まさに改善中なのですが、パートナー企業からいただいた要望についてチーム横断で話し合って優先度を決めることにしました。その後、各チームで優先度に沿ったロードマップを引くようなプロセスを、試験的に試しているところです。

宮前3つ目が「各種プロセスのメンテナンス」。組織の拡大と、業務領域ごとのチーム編成になったことで、コミュニケーションのプロセスをいろいろな領域で整備する必要性が生じました。

先述したロードマップ作りにおいては、各パートナー企業などから要望を集め、PMに共有。優先度を加味してドラフトを作り、各パートナー企業ですりあわせをした後、経営承認を得る…といったプロセスをとるような形です。このとき、社内外のステークホルダーが納得感ある形でロードマップを作れるよう、適切なタイミングでコミュニケーションをとるように常にアップデートしています。

整備したプロセスで言えば、開発チームへの依頼フローも変更しました。従来の体制だと、古くからいる社員やパートナー企業に近い社員の属人的なノウハウに頼ってしまうことがありましたが、それでは組織としてスケールしない。依頼や要望があれば「問い合わせフォーム」を通じて各開発チームに共有、対応するようになっています。

最後に、パートナー企業へのリリース共有のプロセスも整備しました。全チームが開発したものがいつ配信され、どのように変化するのか、リリースの担当者を設けて一括でパートナー企業に共有するようにしました。

現状の課題は以上です。事業が伸びていく中で、1チームの責任範囲が大きすぎたり、PMが複数チームを兼務したりするようになりました。今後はより適切にチームを細分化したり、専任のPMを当てるようにもしていければと考えています。

浦前提として、パートナー企業がどのようなカスタマイズ要求をしてくるかは、これまでの経験則で掴んでいる実感があります。ドメインベースでの開発体制移行も相まって、要求に応えられる土壌が整いつつあると感じていますね。

既存のパートナーではありませんが、導入を検討している企業から「○○な機能があればStailerを使いたい」と言われることがあります。こうした企業に対する「案件を取るためのカスタマイズ」は基本的にしていません。プロダクトとしてStailerがどうあるべきかを大上段に考え、やるべきかどうかを判断しています。

小谷プロダクトが成長すると、カスタマイズの要求は減っていくものだと思います。肌感覚で、現状をどのように捉えていますか？

浦プロダクトが成長する中で、機能追加やカスタマイズの要求自体は原則減ってきていると思います。

一方で、様々な要因で、機能追加やカスタマイズの要求をいただくケースも発生している状況です。そういった場合には、Stailerの成長機会でもあるのでBizDevと連携しパートナーと議論を繰り返します。要求の背景等を深ぼる、近しいニーズがないかを調査するなどを経てプラットフォームの機能としてどのように昇華できるかを考えています。

椿原さまざまな企業からカスタマイズ要求があると思います。どの機能を優先するかは、社内方針で決まっているのでしょうか？それとも、ディスカッションを重ねているのでしょうか？

宮前今まさに、明確な指針を作ろうとしている現状です。コスト、成長確度、インパクト、10Xとしてのビジョンとの合致…。様々な要素でスコアリングし、定量的な優先度をつけられるようにしています。数字だけで語れないオペレーションの改善点などもあるので、引き続き議論して調整していく必要もあると思っていますね。

椿原Stailerを運営する上で、配送や会計といった各業務の内容を理解することが必要だと思います。PMの皆さんは、担当領域に関わる業務内容やオペレーションをどのように理解し、メンバーに伝えているのでしょうか？直接、現場に足を運ぶこともあるのでしょうか？

浦PMに限らず、現場に行く機会を設けています。特に「お届けチーム」は、現場のオペレーションを見たうえで実態を把握することは重要。今は実施していませんが、プロダクトの改善に向けたインサイトを得られるのであれば、「お買い物チームの人間がお届けチームの現場に行く」ような横断的な取り組みがあってもいいと思っています。

椿原参加者から続々と質問がきています。「PMとしての業務範囲を決めているのか」「開発にどの程度踏み込んでいるのか」。PMとしての仕事について、お三方はどのように考えていますか？

浦会社として整理しなければならないと思いつつ…。個人的には、プロダクトの成功のために何でもやることが仕事だと思っています。その中でもプロダクトの課題を見つけて評価すること、デリバリーすることが重要です。

宮前スクラムの形式を取っているので、セレモニーに参加し、リリースされるまでを見守るようにしています。ただ、開発チームが大きくなったり、エンジニアの中の役割も細分化されたりする中で、手前の課題の探索にリソースを割きたいと思っていますね。

太田垣チームにおいて何をすべきかっていう部分を起点に動いています。私が担当している「お買い物チーム」では以前、RACI（レイシー）チャートを使ってエンジニアの役割分担を整理しました。開発スケジュールの責任はエンジニアにあるのかPMにあるのか…など、役割をはっきりさせるのも、手法の1つだと思っています。

椿原採用についても教えてください。PMは外部からの採用が多いのか、チーム内のエンジニアがPMに挑戦するようなパスもあるのでしょうか？

宮前現状は外部からの採用が多いですが、社内の優先度が低いわけではありません。PMに限らず、10Xでは職種をチェンジするプロセスも整備されているので、外部採用と同じような基準で、職種の変更を評価するようになっています。

椿原PMのアサインはどのような基準で決めていますか？

浦過去の経験や適正に加え、本人の意思がある部門に入ってもらえるよう、調整するようにしていますね。

太田垣個人的には、ロードマップの作り方にPMの力量が現れると考えています。

合議制で丸い結論になった中途半端なロードマップは、いいものを生まない。何をどういう順番でやるべきか、説明責任を果たせる芯を持ったロードマップを作れることが、優秀なPMの条件だと考えています。

ただ、一方的に押しつけたロードマップは、うまくいかないことがあることも留意しなければなりません。メンバーに納得感を持たせ「やりたい」と思ってもらえるように設計することも肝要です。

太田垣担当している「お買い物チーム」は、売場そのものや、それをデザインするツールなどで足りない部分が顕在化しやすく、対処するための選択肢も多様です。さまざまな可能性が想定できる中、ベストではなくてもベリーベターなロードマップを考えるのはおもしろいですし、打った施策があたれば、率直にうれしいと感じます。

また、プロダクトを作り上げていく過程で、PMがかっちり仕様を決めるのではなく、デザイナーから想像を超えた斜め上の解決方法が示されると、快感を感じますね（笑）

宮前お届けチームは、「どれだけ多くの注文を出荷できるか（キャパシティ）」と、「どれだけ効率よくピックパックや配送作業ができるか（オペレーション）」の両面から、サービスを改善しています。ただ、2つの課題を解決するには私たちのチームだけでなく、他チームと連携が必須。そんな課題に対して、チームをまたいで一気通貫で解決できるアイデアが浮かんだ瞬間に快感を覚えますね。

浦私たちが取り組んでいるネットスーパーという領域は、いかに多くの人に使ってもらえる状態にできるかが勝負だと考えています。そんな目標に対して、たどり着くための課題やヒントが見えた瞬間に喜びを感じますね。