スピーディな成長が求められるスタートアップにおいては、プロダクトの進化と共に組織の形も急速に変化していきます。

とはいえ、特にアーリーステージでは事業の成長が何よりも優先されることや、CxOがプロダクト開発に必要な役割を兼任することも多く、組織づくりが後手に回ることも珍しくありません。

そこで10月27日（木）に開催した「SELECK LIVE! for Startup」では、「スタートアップにおけるプロダクト開発の組織化」をテーマに設定。

これまでに数々の組織課題を乗り越えながら、プロダクト開発の組織化を推進してきたSmartHR社、LayerX社、STORES社の3社からそれぞれゲストスピーカーをお迎えし、個別発表、トークセッションを実施しました。

当日は240名近い方から参加申込みをいただき、Twitter実況等も大変な盛り上がりを見せました。今回の記事では、その内容の一部をダイジェスト版でお届けいたします。

▼ゲスト
株式会社SmartHR 執行役員 / VP of Product 安達 隆 さん
STORES 株式会社 プラットフォーム事業部門 部門長 / CRM事業シニアプロダクトマネージャー 浅田 純史 さん
株式会社LayerX 取締役 兼 バクラク事業部 CTO / CPO 榎本 悠介 さん

▼司会・モデレーター
SELECK株式会社 編集長 / 舟迫 鈴
株式会社ゆめみ 取締役 / SELECK株式会社 取締役 工藤 元気

登壇各社の「プロダクト開発の組織化」の取り組み

1.株式会社LayerX 取締役 兼 バクラク事業部 CTO / CPO 榎本 悠介さん

「すべての経済活動を、デジタル化する。」をミッションに掲げ、バックオフィス向けSaaSサービスを複数展開する株式会社LayerX。

同社の取締役兼バクラク事業部のCTO、CPOとして活躍する榎本 悠介さんからは、「バクラクの爆速開発を支えるチームとアーキテクチャ」をテーマにお話しいただきました。

▼過去にLayerX社に取材したこちらの記事も、ぜひ一緒にご覧ください
「爆速開発×ユーザー体験向上」を実現するLayerX。その鍵となる「地図とコンパス」とは – SELECK

2. STORES 株式会社 プラットフォーム事業部門 部門長 / CRM事業シニアプロダクトマネージャー 浅田 純史さん

「Just for fun」をミッションに掲げ、お商売のデジタル化を支援する「STORES」を展開するSTORES 株式会社。

同社のプラットフォーム事業部門の部門長、そしてCRM事業部のシニアプロダクトマネージャーとして活躍する浅田 純史さんからは、「経営統合効果を最大化するPMI。その時、現場はどうするマニュアル」をテーマにお話しいただきました。

3. 株式会社SmartHR 執行役員 / VP of Product 安達 隆さん

「労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。」をミッションに掲げ、クラウド人事労務ソフト「SmartHR」を展開する、株式会社SmartHR。

同社の執行役員 VPoPとして活躍する安達 隆さんからは、「急成長SaaSのプロダクト組織課題四天王を連れて来たよ」をテーマにお話しいただきました。

【3社の組織図で比べる】パネルディスカッションとQ&Aスタート！

今回は、ゲスト3社のプロダクト開発周りの組織図を事前にいただき、フォーマットを揃えて比較した図をオリジナルで作成しました。

会社の規模やプロダクトの特性も異なるので、単に並べて比較することが一概に良いとはいえませんが、ひとつの考え方として、組織図を元に深掘りを行いました。

ここからはモデレーターとして株式会社ゆめみ 取締役 / SELECK株式会社 取締役 工藤 元気 も参加し、セッション形式で進行をしていきました。後半では、参加者の皆さまからの質問にもお答えしています。

▼3社の組織図を比較したもの

ーー（工藤、以下同じ）まずは各社の組織図をそれぞれ見ていきたいと思います。LayerXさんは、発表にもあった通り生産性を高めるための「Enabling Team」を立ち上げたという点が特徴的ですよね。ただ、その際に既存チームからメンバーを引っ張ってしまうと、開発側の人数が減ってしまうと思うのですが、どのように対応されたのでしょうか？

▼LayerX社の組織図

榎本　正直、苦渋の決断でしたね。基盤だけ先に走ってもしょうがないので、そのプロダクトやドメインに密接に関わった上で「こういう要件があるから、この仕組みではダメだよね」と全体を俯瞰して言える人をアサインする必要があり、エース級のエンジニアを入れました。

ーーなるほど、選抜チームのような形で立ち上げられたのですね。次にSTORESさんの組織図についてですが、各メンバーが事業部門に所属しつつ横断する組織も兼務しているとお話されていましたよね。元々は別々だった会社に所属しながら、各プロダクトに所属している形なのでしょうか？

▼STORES 社の組織図

浅田　その背景もありますが、ジョブ型の組織にしてしまうと事業目標にコミットしないメンバーが出てくる懸念があったのでこの体制にしています。ただ、事業責任者がエンジニアやデザイナーの評価ができるかというと、なかなか難しいんですよね。

ですので、ジョブに関する評価はジョブの部門長が見るようにしていて、主務としては事業部門に付きながらジョブ型を兼務する形として、両方を担保できる体制にしています。

ーー最後にSmartHRさんの組織図です。目立つ存在が「ドメインエキスパート」ですが、これは社内から生まれた部門なのでしょうか。

▼SmartHR社の組織図

安達　そうですね。SmartHRの立ち上げ当初、元々人事・労務の実務をされていた方がプロダクトのディレクションをしていた時期があったんです。当時はその方がPdMと呼ばれていたのですが、いわゆる一般的なPdMというより「ドメインエキスパート」的な動きをされていて。

その後、会社がある程度大きくなったタイミングで本格的にPdMの採用を始めたので、 元々いた方をドメインエキスパートという役職に再定義し、新たな部門として採用を進めて今に至っています。

ーー元々バックオフィスの経験をお持ちの方をプロダクトサイドで採用していたということですね。

安達　当初は社内労務を担いつつドメインエキスパートも担えるような部門を作ったのですが、事業部門と管理部門の兼務がNGということになり、現在はプロダクトサイド専任のポジションになっています。

ーーLayerXさんでも、特に経理関連のドメインを貪欲に吸収してらっしゃいますよね。

榎本　LayerXでもドメインエキスパートとして組織化する話が過去にあったのですが、チーム化するとふわっとしてしまいそうで。プロダクトに足場を置きながらドメインを生かすなど、 何かしらの足場を持った上で緩やかに連携する形に着地しています。

今のメンバーの良い点として、それぞれが「ユーザーさんに喜んでほしい」「いいものを作りたい」といったこだわりを持ちながらドメインを貪欲に吸収する姿勢があります。なので、ドメインエキスパートとして独立させるよりも、各々がPdMほどの精神を持ち合わせている方がいいなと思いますね。

ーー広義で捉えると、STORESさんのショップ運営もドメインだと思うのですが、お客さまのユーザーストーリーを考慮した際に、Shopifyやスマレジを経由するロードマップを意思決定されていますよね。その点に愛があるなと感じたのですが、そうした意思決定はどなたがされているのでしょうか？

浅田　PdMや営業のメンバーです。いかにお客さまを第一に考えるか、というSTORESの文化を軸に優先順位を決めてもらっています。

意思決定の例として、IDの統合はお客さまからすると見た目が変わったり機能が増えるわけではないので、2018年にheyができた時からずっとIDを統合してないんですよね。今になって、ようやくIDを統合するメリットを出せるようになったので実行しようとしている段階です。

組織構造の「耐用年数」って、どのくらい？

ーーID統合の例のように、基盤チームを作る難しさについては、3社様とも苦労されてきたのではないでしょうか。

榎本　LayerXは異なるサービスを後から統合した経験はないですが、やはり共通の認証部分や管理画面をどうするかという問題はよく挙がります。組織が拡大するにつれてボールが落ちがちになる部分ですし、今ちょうどその問題が起きていて。

そのために設置しているのが「遊撃」というチームです。ボールを拾いつつ、新しいプロジェクトをやる際に一度受け止める意味を込めて遊撃というチーム名にしています。ただ、誰がこの役割を担えるのかという問題もあったりして、うまくワークしているかというと怪しいのが現状です。ここが機能すれば柔軟な組織にできるのではないかと思っています。

安達　SmartHRでも、「これって、どこのチームのミッションにもないよね」というこぼれ玉が今少しずつ出始めています。

理由として、プロダクトが増えると横断的なUXをどう担保するかという話が出るのですが、プロダクト毎に組織を分けているので、誰も横断したミッションを持っていない状態になっているんですよね。技術基盤も横断課題なので、そういった課題解決を担うチームを作るべく議論を始めたところです。

ーーまさに、これからチームが増えるかもしれないというタイミングですね。

安達　そうですね。今の組織構造の「耐用年数」が過ぎたのではと、個人的に感じています。

ーー「組織の耐用年数」って面白いですね。STORESさんは会社の統合を行っているので、組織の耐用年数を予測するのが難しそうだなと感じたのですが、組織設計はどのタイミングでどう見直しているのでしょうか。

浅田　毎年、事業のテーマを決めるタイミングで組織も見直しています。実は、私が入社した去年はジョブ型の組織だったんですよ。それをもっと事業に軸足置いた形にするべく、現在はこの組織体制にしてます。

今後、例えばサービスを一つにしていこうという話になると、機能別の組織がいいのではと思っていますね。2、3年後にまた組織が変わっているかもしれません。

ーーなるほど。統合後にメンバーが別の事業部門に移動することもあるのでしょうか？

浅田　ありますね。積極的にジョブローテーションを推奨している訳ではないですが、他のことにチャレンジしたいというメンバーが異動するケースもあります。また、部門毎の強み弱みがあるので、部門間でリソースの調節を行っています。

ーーLayerXさんはいかがですか？

榎本　バクラクは去年の1月にリリースしたばかりの若いプロダクトなので、ローテーションって言ってる場合じゃないよねという雰囲気は正直あります（笑）。

その中で、今は僕がアロケーションをすべて行っているのですが、事業の状態を見ながら局地的に爆速でやる必要が生じた際に、最適な人をアサインすることはありますね。また、フェーズが変わってきた部分に対して、事業上の要件に従って最適配置を行うという泥くさい状態です。

ーー現状はトップダウンでの意思決定者がいるということですね。

榎本　もちろん、各メンバーのWillを加味するので機械的に行ってはいないですが、現状はそうですね。

安達　SmartHRもローテーションの仕組みがあるわけではなくて、本人のWillと適正と事業上の要請のバランスを取って、必要に応じて配置替えをしています。

例えば、新しいプロダクトを作る際に0から採用をするわけにはいかないので、各チームから少しずつアサインしたりしていますね。その際のルールは明確には無いので、マネージャー間での話し合いと、希望があれば聞く形で進めています。

SmartHR社の大規模スクラムの実態は？

ーーここで一旦、それぞれの組織を見てお互いに聞いてみたいことはありますか？

榎本　SmartHRさんの大規模スクラムの実態が気になりました。スクラムチーム下の連携やどう切っているのかなど。

安達　正直、全然綺麗には切れてなくて…。今6チームいて、大きく3チームずつでドメイン分けしています。どちらにも入らないフィーチャーも多いので、その場合は都度話し合ったりリソースの空き具合で調整したりして泥くさくやっていますね。

榎本　機能単位で切ろうとしてる感じなのでしょうか？

安達　機能よりは提供価値ですね。従業員データベースとフロントシステムというドメインで分けています。

榎本　その複数のスクラムをさらに束ねる組織はありますか？ スクラムオブスクラム的な。また、必ず横断する機能があると思うので、そのフロントシステムと事業のデータベースをどう繋ぐかが気になりました。

安達　さらに上のレイヤーにチームがあるというよりは、「アジャイル推進室」という有志のコミュニティがあります。 アジャイルやスクラムの取り組みとしてやったことを毎週持ち寄ってシェアしています。

意思決定のレイヤーに関しては、基本的には、大規模スクラムの中にPOが1人いて、その人がオーナーシップを持っています。加えて、各職能ごとの責任者が集まって話し合うこともあります。また前提として、大規模スクラムでどういうフィーチャーを作るかは、全社のロードマップに合わせて決めてもらっています。

ーーSTORESさんも統合する際にスクラムを導入した話がありましたが、それまでスクラムをしていなかったところに導入したのでしょうか？

浅田　そうですね。SHOP FORCEはエンジニアが2名しかいなかったので、スクラムを組むほどではなかったという背景もあります。STORESに統合されたタイミングでチームが大きくなり、優先順位をつけて開発できるようにとスクラムを導入しました。ただ、すべての事業部門がスクラムを導入しているわけではなく、部門毎にやりやすい開発のフレームワークを入れてもらっています。

チームの統合・分割の際に気をつけるべきことは？

ーーここからは、参加者の皆様から頂戴した質問にも答えていければと思います。まず、事前にいただいていた質問ですが、人が増えてチームを分割する際、どのような点に考慮して行っていますか？

浅田　私の考え方ですが、チームの人数は野球ができる人数プラス、マイナス2が限界かなと。12人の場合は6：6で分割するようにしていて、今はどの開発チームも6〜9人で構成しています。

榎本　LayerXでいうと、この組織図に載せているチームは大体4名ほどで他は1、2人の場合が多いです。結構カツカツという状況ではあるのですが、最初はみんなで集まってワイワイしてた環境が、今は徐々にチーム化してきましたね。

基本リモートの体制なのですが、「今、話しかけてもいいですか？」の会話をなくすために、Zoomに常駐するルールにしています。最初は全員メインルームでしたが、最近はブレイクアウトルーム機能を使ってチーム毎に分かれています。Slackも徐々に分かれてきていますね。

安達　SmartHRも基本的には1チーム10人ほどに収まるようにしています。大規模スクラムをやってるところは、人が増えるたびにスクラムチームを増やしていますね。

ーー分割する時のリーダー的存在は、どのように決めているのでしょうか？

安達　職能横断型のチームなので、リーダーのような人はいないですね。すべてのチームにPdMはいますが、あくまでプロダクトマネジメントをする人であって、指揮命令系統があるわけではありません。とはいえ、エンジニアを取りまとめるチーフが各チームに1名ずついるので、その人が開発リーダー的なポジションといえます。

榎本　LayerXでは今年の4月からマネージャーを置いています。職能型のチームとプロダクトチームそれぞれにマネージャーがいる状態ですが、元々フラットだったところにマネージャーをアサインした形です。

1on1のコツや、「マネージャーは役割であり、メンバーのフォロワーシップとの相互関係である」といった話を伝えるマネジメント研修を行ったり、HRが新任マネージャーの1on1に同席するなどの支援を行ってうまく立ち上がったのかなと。

浅田　今まさに、STORESはマネージャーをどう育成、配置するかを決め始めた段階です。元々フラットだったものの、マネージャーを置かないとちゃんと評価ができないタイミングになってきたと思っていて。

現時点では、元々外部でマネージャーだった方を採用したり、社内のメンバーをマネージャーに登用したりしています。それに伴い、HRのメンバー内でマネージャー研修を設計して運用しようとしているところです。

評価は誰が、どのように行っているの？

ーー人材育成から話を広げて、評価制度についてもお伺いしようかなと。現状の評価制度はメリット・デメリットを把握した上で運用されていると思うのですが、その点について詳しくお話いただけますか？

安達　まず、SmartHRの場合は僕の入社時から今の評価制度だったので、それを変えずに運用しているという背景が前提としてあります。メリットでいうと、専門性があるメンバーが評価をするので被評価者の納得感は高くなると思いますね。

一方で、各プロダクトチームにマネージャーはおらず職能毎にいる体制なので、評価者と被評価者が普段は一緒に仕事をしてないんですよね。例えば、私がPdMを評価する場合、そのPdMは僕とは別のプロダクトチームに入ってるので普段の仕事ぶりを直接は見れなくて。

ですので、関係者にかなり細かくヒアリングをしないと評価ができず、その点で手間がかかるなと思いますね。

ーーLayerXさんは、評価についてはいかがでしょうか？

榎本　メンバーの仕事ぶりがわからないマネージャーが評価するようなことはなくヘルシーな状態ですね。ソフトウェアエンジニアとPdMが各プロダクトに所属している状態です。プロダクトチーム付のソフトウェアエンジニアについてはそのプロダクトに所属するEMが評価していて、PdMは僕がCPOとして評価しています。

QA、Enabling Team、DevOps、AI-OCR、デザインチームには各々マネージャーがいて、横串で評価していますね。

ーーSTORESさんは、統合する際に評価制度もマージされたのでしょうか？

浅田　まさに去年、STORESとしての評価制度を作りました。そもそも会社のバリューもなかったので、まずはバリューの策定を行うべく全社員でワークショップをやって、人事が取りまとめた後に社長が最終的に三つに絞って決めました。

評価制度としては、全員が納得いく形を人事が一から作って模索している状況ですね。SHOP FORCEのメンバーにとっては、いきなり新しい人事制度を運用されると困惑すると思うので、SHOP FORCEのメンバーには遅れて適用させ、全員が理解した上でスタートするよう慎重に進めています。

ーー「統合前の会社に出向いて、新しいルールの元で働くのは大変そう」と視聴者の方から共感のコメントをいただいていますが、出向いた先のルールと相反する部分もやはりあるのでしょうか。

浅田　SHOP FORCEはそもそも人数が少なく、評価制度もきっちり運用していなかったので相反する部分は少なかったのではと思いますね。ただ、勤怠のシステムは統合しました。また、元々STORESのメンバーはフルリモートだったのでSHOP FORCEのメンバーに合わせて出勤するようにしたり、勤務時間を合わせるようにするなどしてバランスをとりました。

プロダクトのUX設計は、誰が責任をもつ？

ーー視聴者の方から、「SmartHRさんがUXライターをあえて組織図に載せるほど組織化されている背景を知りたいです」というご質問が届いています。

安達　元々、UXライターは独立した組織ではなくカスタマーサポートの中にありました。カスタマーサポートの方々がお客さまに対応しながらヘルプページを作成していたのですが、そこに編集者やライター出身の方も何名かいらっしゃって。彼らにボタンの文言や機能説明の文章などを相談することが増えたので、チームとして独立させた形ですね。

ーーLayerXさんも先ほど体験設計にこだわっているとお話されていましたが、UXはデザインチームが司っているのでしょうか？

榎本　LayerXではPdMが担っています。とはいえ、エンジニアもデザイナーも、自分が割り当てられたユーザーストーリーは「自分が主役だ」という気概で開発する前提です。また、PdMはお客さまへのヒアリングを相当行っていることもあって、最終的な意思決定や複雑な機能の体験設計はPdMが責任を持っています。

ーーSTORESさんだとプロダクト毎にお客さまがいらっしゃるので、UXの設計が難しそうだと思いましたが…

浅田　基本的にUXの責任はPdMがオーナーの方々にインタビューして決めています。新しいプロダクトの方向性もまずはプロトタイプを作って意見をいただいてからリリースするようにしていますね。

また、オーナーさんからの要望はSlackに流れるようにしているので、すぐできる改善はエンジニアがやってくれたり、意図がわからないものは電話をかけて確認したりしています。

過去に「チームや組織をなくした」経験は？

ーー組織面に話を戻しまして、過去に「特定のチーム or 組織をなくした」というご経験はされたことがありますでしょうか？

浅田　組織がなくなった経験というよりも、組織名にこだわるようにしています。例えば、エンジニア組織のプラットフォーム開発をしている部門があったのですが、「プラットフォーム」って魔法のワードだと思っていて（笑）。「なんでもプラットフォームがやってくれるだろう」という空気感が生まれてしまったんです。

すると、何を担当している人なのか曖昧になってしまったので、プラットフォームの中でもIDを担当している人はID基盤、顧客管理の基盤を作る人は顧客管理基盤と明確に示すようにしました。

事業部門だと、機能毎のチーム名にしたが故に個別最適化してしまうと事業全体としては不健全なので、「リテールABC」のような抽象的な名前にして、「一つの機能に特化したチームではない」と意識づけを行うこともあります。

榎本　当社だと、品質を担保するQAチームは未だに模索中です。プロダクト数が増えたり機能が複雑化しているものの、それに応じて増員することはあまり好ましくないなと。そこで、どう品質を担保するかを考えているところですね。

そもそも、QAエンジニアの採用が難しいというのが大前提にあります。SET（Software Engineer in Test）がいないと回らないのではないかと去年は話していたのですが、一周回って、各プロダクトチームで単体テストを拡充しつつ、エンジニアリングがすごい強くなくても品質を保証できるようなツールを使うやり方も並行して模索していますね。

安達　SmartHRの場合、僕の入社前の話なので詳細はわかりませんがSREはなくなっています。今の組織をみていると、SREに代わるチームがあるというよりも各プロダクトで担保する形になっていますね。

「プロダクト組織を立ち上げて！」と言われたら、まず何をする？

ーー視聴者の何名かの方から、プロジェクトを立ち上げる際に一番留意しておくべきことは何かという質問がありました。「これは外せない」というものはございますでしょうか。

安達　最初に、プロダクト組織を内製で作るということを経営陣としっかり握ることかなと思います。自分1人で出来ることは限られているので、会社としてのバックアップを受けるべく期待値調整も含めて話しておくことが大切かなと。組織を作る目的や、どんなスケジュール感で規模を拡大していくかなども踏まえて話せると良いですね。

ーー例えば、安達さんが新しいプロダクト組織を立ち上げる際にご自身のミッションも明確にする感覚ですか。

安達　そうですね。具体的にどこまで求められてるのか、どういうアウトカムが欲しいのかなどを握っておかないと。なんとなく「プロダクト組織作ってね。よろしく！」と、感覚が擦り合ってない状態でスタートさせても難しいですよね。

浅田　組織作りもプロダクト作りも、一番はやはり目的を明確にすることかなと。何のために組織を作るのか、どんなプロダクトで誰にどんな未来を見せたいのか。その点をぶらさずに仮説検証を行うことが重要だと思います。

とはいえ、少人数でできることは限られているので同時に「やらないこと」も決めます。例えば、初期フェーズであれば評価・育成よりも体制づくりを優先しますし、プロダクトに関してもやらないことを決めた方が意思決定のスピードが早くなるのではないかと。

榎本　僕はせっかくなので、2種類の尖った回答をしようかなと思います（笑）。

一つは、そもそも組織化を考える必要があるのかどうかですね。目の前の課題ややりたいことに対して、組織化して解決していくのか、あるいは自分の馬力で何かしらアウトプットを出しながら徐々に組織化していくのか。その二つの道があると思います。

僕は馬力を出すタイプなので、まず自分の持てる最大限の力で動くものを作ってPMFに近づけるようにします。結局、動くものや文化がないと人も集まらないですし、集めるのもしんどいので。なので、いきなり組織化だけ考えるのも難しいと思っています。

もう一つは実体験に基づいているのですが、LayerXは元々はブロックチェーン領域の事業をやっていた会社で、前身となるGunosyからMBOした当時、僕が1人でブロックチェーンのチームの立ち上げを任されたんです。

ブロックチェーンという大枠のテーマは決まっていたものの、馬力を出すにも本当に何をやったらいいのかわからなくなってしまって。そこで、逆に組織化してしまった方がアイデアが生まれると思い、ブランディングと仲間集めに振り切って、ひたすらブロックチェーンについて調べて尖った発信をしたこともありました。

ーー冒頭でお話されていた、榎本さんが9割開発に集中できる体制ってすごいと思うのですが、具体的に何をされたのかという質問もいただいています。

榎本　一つは、みんなに宣言することですね。定例の場などで、「僕はもうバクラクビジネスカードの立ち上げしかやらないから」と（笑）。もう一つは、やはり周囲の助けのおかげです。榎本は立ち上げが1番馬力を発揮するからと、お膳立てをしてくれたという二つの背景があります。

「コンウェイの法則」と今後の課題

ーー最後の質問です。組織論では避けられない「コンウェイの法則（※）」がありますが、今の組織だからできていること、反対に課題などはありますか？

※メルヴィン・コンウェイが提唱した概念で、組織の構造は、その組織が開発するシステムの設計（アーキテクチャ）に似るという法則のこと

榎本　「コンウェイだな」と思えるチームが、今まさにプロダクト毎にできているなと感じています。 AI-OCRのチームに対応したマイクロサービスがあるというわかりやすいアーキテクチャになっていて。

ただ、プロダクト横断の難しい話がどんどん出てきていて、そう簡単なことは言ってられないという状況になりつつあります。

例えば、まさにEnabling Teamが立ち上がったことで、プロダクトカットではないマイクロサービスのあり方を検証するようにもなっています。ある意味カジュアルに切れる基盤モノレポの中で、切ったりくっつけたりが試せるような基盤とインフラ基盤が整った時にどうなるのか。そのタイミングでチーム構成がまた変わっているかもしれないと思いますね。

浅田　まさに私たちも「組織イコール事業」の体制になっているのですが。今後、オーナーさんから見た時に一つのプロダクトにしていきたいと考えると、今個別になっているものを機能としての形に変えていける組織にしたいですね。

つまり、現状ではEC事業、決済事業、予約事業になっていますが、これらが予約機能、EC機能といった形にできたら良いなと。そのために組織も変えていくべきだと感じていますね。

安達　当社もLayerXさんと課題感が似ていて、やはり複数のプロダクトがあると横断の課題が出てくるんですよね。技術的な基盤の話もそうですし、UX面でもプロダクト毎に少しずつ体験が違ったり、シームレスに繋がっていない場合もあって、それらがまさにコンウェイの法則が出てるところだなと。

その横断課題を解決しようと経営レベルで動き始めているのですが、現場の意識はどうしてもプロダクト単位になってしまうので、そのトランジションに結構カロリーがいるなと感じているところですね。

ーー局所で議論が発生しているし、経営でもその課題感を感じてらっしゃる状態なんですね。

安達　そうですね。組織のいろんなレイヤーや場所から「そろそろ変えていかないとダメだよね」という空気感がまさに出てきているという状況です。来年以降にどうなっていくのかとても楽しみですね。

ーー改めまして、みなさま本日は本当にありがとうございました！（了）

おわりに

いかがでしたでしょうか。プロダクト組織を立ち上げる際のポイントや、組織やチームを統合する際に留意すべき点など、たくさんの知見が詰まったお話をしていただきました。皆さまのプロダクト組織との向き合い方のヒントになれば幸いです。

今後も、現場で役立つナレッジをお伝えするイベント「SELECK LIVE!」を、定期的に実施していきますので、興味のある方はぜひご参加くださいませ。