#237 チームトポロジーを活用した・活用しない組織設計 (w/kameike)

00:00

はいこんにちはゼロトピックです今回はタイミィ今はCTOかな

CTの方です今は CTOちょっとやり直します

全然大丈夫ですよ全然間違ったところ面白いんで

撮っててもいいですよ本当ですか

じゃあもうこんまま行こうかなタイミィCTOの亀池さんに来ていただきました

よろしくお願いしますよろしくお願いします

タイミィCTOをやってる亀池と申しますただしですね結構この5月ぐらいから

プロダクトマネジメントももう包括的に統括したりしていてですね

若干テクノロジーの旗を立てつつプロダクトマネジメント側でも

頑張っていくぞみたいな感じでやっております

それいきなりそっからちょっと入っちゃうと認知負荷が爆発しませんか

認知負荷爆発しちゃうんですよねなので結構やっぱ人を探してちゃんと

異常していかないといけないんですけど結構幸い組織面を見てくれる方々

みたいなところの採用は結構うまくいってて VPoVとプロダクトマネジメント

も組織化を図ってるのでプロダクトマネジメントのマネジメントラインですね

っていうところの人が採用できてるのであんまり人の問題とかは僕が頑張って

解かなくてもいいような状況が作れそうだなと思っててなので結構ことの方に

フォーカスできる状況みたいなところを目指すっていう感じです

あと結構長くいるんで一定その認知負荷貯金はあるかなと思ったりはしてます

なるほどピープルマネジメント部分については

大きく任せられてるっていうのはめちゃめちゃでかいですね

ああそうですかやっぱり結構大変ですよね

割とピープルマネジメントの運用もすごいシステムと同じくらい複雑だし

結構大変だなと思いながら

そうですね運用命ですよね

組織もデブとオプスがあるなと思ってて

ああはいはいめちゃくちゃ悪いと思います

やっぱりそこが分断したりとかあとオプスが回らなくてデブばっかりやってると

よくプロダクトも崩壊していくんですけど組織も結構浮き目にあったりとか

すごいあるなと思ってて

めちゃくちゃプロダクトとかとアナロジーがあるなってすごい思ってますね

いやめっちゃそう思います僕もなんかいやでも今日ちょっとそうですね

本題が多分そこなので本題に入った方がいいかなと思うんですけど

あの深堀FM出られててなんかあれを聞いたんですよ

確か深堀FMってチートポが出た直後ぐらいに役者の方直接日本語役者の方も

執筆者かなもう呼んでお話されてたりとかしてて

その後亀池さん出てるのを聞いてタイミーではこういう変遷があってとか

チートポを捉えてみたいな話されてたと思ってて

これはなんかうちもまさに今組織企画というか組織設計を作り直したり

あるいはその中で走らせる制度みたいなものを作り直して

03:03

その中の結構参考題材としてチートポをかなりチームトポロジーですね

あれをかなり活用したりあとは活用するしないっていう以前に

結構自分が持ってる考え方とすごい近かったなっていうふうに読んだと思ってたんで

この辺りをもう少し現場目線というか事業会社があれを使うとか

組織設計したり運用したりする上でのあれこれみたいなのを話せればいいなと思って

今日来てもらったっていうそんな背景でございます

いやありがとうございましたどうぞよろしくお願いします

ちなみに山本さんが考え方が近いなと思われたってどういう点があって感じなんですか?チームトポロジー

例えばストリームアラインドチームみたいな

要は事業というか顧客とか事業成果みたいなものに向き合うチームと

それに対して例えばもう少し横軸というかプラットフォームチームとか

チームの名前は今4つ空で出てこないですか? イネブレメントチームだったかな

あともう1個なんでしたっけ?

Complicated Subsystemsみたいな

その4つの概念って会社の中には確実に区分けして存在してるなとか

これはComplicated UntaraだよねとかこれはStream Untaraだよねっていう

区分けがしやすい形で割と会社の中作ってたんですよねもともと

なるほど

あの関わり方の中で特に僕の組織の最も理想の状態は

組織間がAPIのようにドキュメントでそのリクワイアメントが完全に定義されていて

呼び出し方とそこに対する機能の価値の発揮の仕方も型になっているみたいな

なのでコミュニケーションじゃなくてコンテンツで全てが解決できる世界っていうのが

一応最強の理想だと思ってるんですけど

当然事業とか組織って不確実事項いっぱいあるんで

それを理想のインタラクションの仕組みだとしつつそれ以外のものっていうのをちゃんと定義して

どういう時にどういうふうに使っていくといいよみたいなことが

簡単に言うとチートポのコシというかかなっていうふうに思ってるんですけど

この辺は自分の考え方とめっちゃ近いなと思ったんですよね

うんうんうん

僕も全てがAPIで組織機関やり取りしてる Jeff Bezosじゃないですけど

そういう感じの考え方すごい好きなんでですね

理想はそれだなっていうのはすごい思ってますけど

なかなかベンチャーとかやってると全然そこまであと何キロあるんだみたいな感じ

すごい遠く感じますよね

そうですねなんかあれ全部Complicated Subsystem Team

(笑)

大体コラボレーションモードというか一緒にやるぞって言って

集まってるのがずっと続いてるなみたいな感じになったり

そうですねでも本当10Xの場合だと

それでやってることによるコミュニケーション負荷が高すぎるっていうのが

06:03

ちょうど昨年末ぐらいに大きい問題だったり

実際に事業上障害みたいな形で発露しちゃったんですよね

なるほどなるほど

これはあかんっていうので

ちょうど年末ぐらいからまさに組織図の再設計みたいな感じで

本当は顧客家でいうとパートナーというか

氷さん一社一社と向き合う縦の事業部みたいなものと

そこに対して横串で機能を提供するプラットフォームのような

あとはコーポレートの人事機能とかそういうのも基本横串っていう

縦横の整理とその中で縦と横はどのようにコミュニケーションして

どう関わるかっていうのをドラフト1を去年の末に作って

1から3月運用してそこで出た問題を拾って

10月1日に新しいものに施行するための改善と検証みたいなのを

この半年ぐらいでやってるんですよ

っていうタイミングとちょうどチートポを読んだり

さっきの亀行さんの話聞いたりみたいなのがめっちゃかぶったんで

すごい自分の課題意識とか

自分のやってることと超リンクしたっていうのがありましたね

なるほどステイラーさん結構プロダクト複雑ですから

ステークホルダーも4軸ぐらいありますよね

しかも小写ごとに出なかったりとか

そうなんですよ

認知負荷が無限にありそうな

そうなんですよ

本当爆発しちゃったんですよね

タイミングも結構チームの切り方とかを間違えることによって

起こるものは結構あったなと思っていて

それこそ最初はステークホルダー軸で切ってたんですよね

チームはそれによって

でもマッチングプラットフォーマーって

両軸の幸せを見ていかない限り結構うまく進まなかったりとか

滑らかなものに到達しない中で

そこで切ってしまったがゆえに

結構大事な部分をやるのに

なんでこんなにコラボレーションしたりとか

会議とかドキュメント書かないといけないんだみたいな事故が

結構去年の後半ぐらいから起こっていて

タイミングが似ていて12月末ぐらいに

それこそこういう感じできますっていうドラフト

中トップイベントとかで行ってるアンドロフトを出して

そこから移行してるんですけど

今10月ってお話を伺ってすごい安心して

組織のリアーキテクチャリングって

めちゃくちゃ時間かかりますよね

かかります

チートコの本にも2年だと

1年半で見積もったら4年かかったとか

半年と見たら2年かかったって言ってる

多分タイミングの組織の移行も

2、3年かかるんだろうなって

そうですね

なんで僕らで言うと

賞味1年で丸っと移行みたいなのを目指してるってことになるので

そうするとすごい早いタイムラインで

なんでそれをできるかっていうと

僕がほぼ時間の1の半分は

いわゆる人事企画と組織企画的なものにコミットしてるので

トップなんでこうだからってすると

いろんな説明席に自分に寄せられるから

早いっちゃ早いなみたいなのはあるかなっていう感じはしてます

組織移動のコンセンサー取るのめちゃくちゃ大変なんで

09:02

誰かが独占的に決めるのが一番いいですよね

そうですね僕が一人怪我するのが一番いいだろうな

そうですね

いやでも創業者の方がやれるのが多分一番進みがいいし

まあなんかその究極の自己責任みたいな世界だと思うので

そうなんです

でもなんか今の過程の中で

もう1個話そうと思ったことがあそうだ

ステーキスホルダーベースで切ってったって話じゃないですか

タイミングのプロダクトだと

具体的にどういうステーキスホルダーの切りになるんですか

はいありがとうございます

結構そのいくつかあるんですけど

メインは働かれる方と雇う方のマッチングプラットフォームやってるんですけども

実はそのマッチングした後のローム管理とかも含めて全部やることによって

そのワンストップな客家地に変えてるんですよね

なので大きく分けて3ステーキスホルダーいて

まず働かれる方ですね

その方もなんならお昼ぐらいからだったら

今日でも仕事を見つけることができて

でQRコードで出退金してお金もらうって感じなんですけど

一方で雇う方は現場ですよ

いわゆる何かしらのお店みたいなところを持ってて

そのお店が全国に何拠点もある中で

本社機能ですね

アルバイト際を考えたりとか

それの係数計画をしたりっていうところの2種類で

彼らにとって要件を満たすプロダクトになることでご利用いただけるっていうところが

タイミングとしてはあったりしていて

それごとに最初は切ろうっていうところをやっていました

なるほど

一番認知負荷が起きた具体のサンプルみたいなのとかありますか?

いいですね

結構認知負荷の起きやすさっていうと

やっぱり認知負荷っていくつかあって

ビジネスモデルとかに紐づく認知負荷と

技術力とかもともと持ってる特性によって紐づく認知負荷があるんですよね

それぞれ名前がちょっとあるんです

ちょっと今名前忘れてしまったんです

で結構タイミングで起きたのは

どちらかというとスキルセットの方の認知負荷の高さが結構高くて

一番最初ってマッチングプラットフォームなんで

ゲームみたいな要はかなりカジュアルに色々とガチャガチャ組み替えつつ

グロスハックしてそこの値を最大化していく

みたいなスキルセットが必要だったりとか

でも後半になってくると絶対に間違ってはいけない

ローム管理とか給与計算とかそういう仕組みが大量にあるので

そこってもう少し固い基幹システム的な考え方が適用することで

ものづくりがうまくいくんですよね

なんですけどそこをじゃあ一つのチームは

ワーカーとかクライアントで切ってしまった際に

マッチングのグロスハック的なところから

最後まで見ないといけないっていうところが

あまりにも技術の幅がありすぎて

一つのチームで負けない結果

その得意領域みたいなのが生まれてきてしまって

なんかその苦手な部分に関しての回収が進みづらく

みたいなところもあって

それめちゃくちゃ面白くて

うちもすごい類似してて

なんか僕は僕らのところで起きたのは

結構SOEとSORの境の認知負荷みたいな感じで

自分は捉えてたので

今の話すごい似てると思ったんですよね

12:01

いわゆる基幹システム的な部分って

システムオブレコード的な考え方というか

もう少しお客様のエンゲージメントとか

顧客体験とか

あるいは売り上げに直接影響を与える指標とか

こういうのってシステムオブエンゲージメント的な

考え方っていう

その二つの考え方を我々で言うとB2B2Cで

特にスタッフの方が使うスタッフのアプリケーションと

そのスタッフを束ねてる本体の方が使う

管理画面みたいな管理用のアプリケーションと

またお客様使う

お客様向けのクライアントアプリとかってあった時に

お客様向けは割々エンゲージメント

で真ん中の基幹システムに近い部分は

割々SOR的な考え方で

スタッフの方が使う部分っていうのは

その両方の特徴を合わせ持ってるみたいな

そういう設計になってて

これをちゃんと認識しないまま

もう一つのチームで

とりあえずパートナーAさんが成功するもの

全部作るのだって言ったら

必要な知識とか

その開発への向き合い方とか

あとは足りない事業知見とか

現場知識の補い方とかのやり方が全く違うんで

そこでミーティングの数とか

認知不可を解消するための

あれこれが爆発してしまったみたいなのが

そもそも手に負えなくなってるみたいなのが

ちょっとあったかなって思ってます

ちなみにこの問題って

タイミングだと採用まで波及していて

全部求め始めるんです

やっぱりこれもできてほしい

これもできてほしいみたいな感じで

スーパーマンみたいなジョブディスクリプション

自分たちこれ満たしてるのかみたいな感じの

要求になってくるんですよね

なんですけどそこって多分

多様化も結構難しくなってきますし

ちゃんと切れ目を作っていくことで

色んなスキルスタックとか

背景の方が活用できる状況になるなっていうのも

あったりしていて

結構採用のチームをうまく切るってことを

考え始めたところくらいから

採用の打席がうまく明確化してきたりとかって

すごいあったなって思ったりしてます

でもそれは本当そうですね

結局どういう働き方をするのかっていう

規定自体が変わってくんで

そうすると

旧人のJDに書かれることってのも

変わっていくっていう

多分TENXの場合とJDに書かれることまでは

今まだそんな買い切れてない気はするんですよね

特にソフトエンジニアとかのレベルだと

ざっくりジュニアというか

経験がそこまで多くなくても

迎えられるっていうところと

またシニアの方みたいな

エンジニアにも話し合って

多分そのぐらいの割から

そんなに買い切れてはないと思うんですけど

それぞれの場所にアサインされた時に

どういう仕事の仕方をするかっていうところは

結構明確にコミュニケーションを外部にできるようには

15:01

少しずつ近づいてきたかもな

というふうに思ったんです

でもまさにタイムは別に

JDレベルではまだ再分化できてないんですけど

一時面接以降ぐらいで

この人例えばですけど

もう少ししっかりとした

合成としたものづくりがしたがってる

みたいな方だったら

いわゆるシステムレコード的なところ

この人はもう少し

もっとグロースハックみたいなものだったりとか

最終的にAIとかデータにつなぎ込みたい

なんてシステムエンゲージメント寄りのこと

みたいな話とかで

面接の過程でその聞き方がやりたいことと

組織が準備できる脱席みたいなところが

割と明確化されていったなと思った

最初はもうこっち側に入ってもらって

全部やってくださいみたいな話とか

やってしまってたので

必ずしもそういう感じの人だけで

作った組織は強いかって言うと

そうでもないと思うし

そもそもスケールしないなって思ったりして

いや本当ですね

僕らもたぶん去年の末ぐらいまでは

全員ソフトウェアエンジニアと呼んでいた

みたいな

そこからさすがに品質管理をする人とか

品質管理をするチームとか

あるいはテストを改善するチームとか

カバレッジ上げるチームとか

リアーキテクチャやるチームとか

あるいは検索を改善するチームとか

顧客体験作るチームとか

なんだかの責任分解点を区切っていくことによって

活躍の仕方も提示しやすくなるし

人のアサインみたいなのもあるし

この枠の中で考えられるし

アサインされた人もその中で

理想を描いて逆算するとか

箱が綺麗に割れてるからこそ

自律的に動けるっていう側面あるなと思って

そういう良い効果はあったなと思います

確かにめちゃくちゃ思いますね

やっぱりチームとしても書き根があって

自分たちのどこを庭がった方が

中長期的なことも考えやすくなると思うんですよね

リアーキテクチャリングでチームを切った場合は

そのシステムの可用性を見て

作り直していくこと自体が

会社のミッションと接続していくのもあったりしていて

めちゃくちゃわかります

チームのミッションとかも明確に

そこでやっとチームごとに

ミッションとかタイミングを立てるようになってきてるんですよ

このチームはこういうことをやりましょうみたいな

でも一応完全にそうですね

本当ですかなるほど

チームがなかったときは

その単位でのミッション出ないんで

会社としてやりたいこと

トップ5みたいなのを経営が掲げたときに

この5以外の漏れてるやつはどうすんのみたいな

絶対それはそのまま漏れるんですけど

チームが割れてると

経営として追っかけていく5個のフォーカスみたいなものと

区別してそのチームとして

中長期的にこういう反映の仕方がしたいから

短期中期を折り混ぜて

こういうイシューを根拠をやっていくぜみたいな

そういう目標の計画の立て方っていうのが

しやすい状況になってるなっていうふうには思いますね

それこそインシデントみたいなのが起こると

18:01

経営としては絶対に対応しないといけなくなるじゃないですか

なんですけどそういうチームがあると

そこから経営がフォーカスを外せて

長期的なものとかを見るリソースが確保できるみたいな話で

そういうチームもすごい大事ですよね

本当ですね

だから去年までは石川さん

CTOが障害あるとまず障害対応に行くみたいな

いやーすごいですね

天地下が石川さんもやばそうですね

多分結構心が来てたと思いますけど

なるほどなるほど

少しずつそこを剥がしながらって感じですね

でもなんか1個目

授業とエンジニアリングと組織のリンクみたいな

その辺の話をしようと思ったんですけど

結構今の話でカバーできたかなっていう感じがしてて

もう少しチートポ側に入ると

チートポって共通言語として今使ってますか

領域を限って使ってるって言うのが多分正しくて

チートポ自体僕の認識だと

認知不可の塊だと思うんですよね

フォーキーズみたいな概念とか

あとスクラムのアジアのソフトウェア開発とか

手法都市のスクラムとか

でValue Streamにフルサイクルにしていくことが

いいよねっていうこと自体

多分そうだねって言える人は

だいぶエンジニアリング組織に詳しい方だと思うんですよね

なので多分あんまり

全員が全員組織に興味があるわけではないので

結構伝える先を区切ったりとか

その功能に関する説明をはしょったりとかは

結構僕はしていて

なのでその正直

チートポが共通言語と運用されてるのは

僕とエンジニアリングマネージャー系と

ピープルマネージメント系の人ですね

とプロダクトマネージャーで切ってるって感じですね

あーなるほど

それ以外の開発メンバーとか

アナリストの方だったりとか

デザイナーの方とかは

まあ知りたければイベントとかしてますし

文章とか書いてるんで読んでもいいですけど

なんか必修科目にはしていないっていうのがあります

あーでもそれもすごくうちも同じで

本当ですか

組織設計のマスタードキュメントみたいなのがあって

その中に組織上のどういう移順を解消したい

みたいなことを書いてあって

その中の一つの参考文献として

チートポ以外にも参考文献いっぱい並べてるんですけど

一個ですって書いてる

そしたら社内の中で

倫読会っていう部活が立ち上がって

そこで10人とかで倫読会やって

そこに自分も入ってチートポを一緒に読んで

その中で今TXが施行している組織とかっていうのを

このチートポのこの概念で説明できるみたいなのを

一緒に咀嚼したり一緒に考えたり

あるいはさらにもう少し区切ったチームの中の

もう少し小っちゃいサブチームみたいな

サブシステム的な話の中でも

これはチートポでいうとここに当てはまるねとか

あとこのチームとこのチームのインタラクションは

初めはイネブリングとか

このインタラクションでスタートするけど

21:01

最後はX as a Serviceにしたいよねみたいな

共通認識が取れたりとか

そういう使い方であくまで草の音的な概念として

用いているし

僕もチートポを初めて読んだ日のTwitterに

もうカタカナが多すぎて何もわからない

書くぐらいあれが認知不可の塊っていうのは

激しく共感しますね

そうですね

すごい逆にそこの認知不可を乗り越える努力をされて

すごいなと思ったりしました

何かあった意味だともうプロダクトマネジメントで

切ってしまうとプロダクトバックログの切り方が

もう変わってくるので

チームとして自動的にトポロジーが適用されるんですよね

そこでプラスアートスクラムのやり方で

そのプロダクトゴールみたいな立てましょう

みたいな話とかそれをOKR化しましょう

みたいなことをやってると

結構チームトポロジーとして成立し始めてはいて

なのでただしそれがチームトポロジーというもので

説明し切りたいかって

結果うまくいっておけばなんとかなるみたいな感じの気持ちで

やっております

そうですね

全てをチームトポロジーのものに揃えていくってことは

やりたいわけではなくて

あくまで今の組織を動かすための仕組みとか設計の背景にある

考え方の参考資料でしかないって

道づけにうちもしてるんで

なんかホワイが知りたかったらちょっと読んでみてちょうぐらいの

カタカナ多いけどみたいな感じですね

あと読み始める前に必ず

この深堀FMの著者による解説会を先に聞いてからの方が

いいよって風に進めてますね

僕も教授者の方とイベント

ソーケルさんの下でやらせていただいたんですが

30分で分かるって言ったのでそれもおすすめです

スライドですよね

あれめちゃくちゃ良いですよね

ていうかあれでいいですよね

あれでいいです

特にあれめちゃくちゃいいのが

何から始まって何を目的としているのがチームトポロジーなのか

ってのを全部分かるように説明されている

多分本当に30分で分かれるんじゃないかなと思ったりしてます

そうですよね

逆コンベイ逆コンベイ逆コンベイ

確かに

あとチートポみたいなものとセットで

最後が人事制度とか

そこをどう合わせていくかみたいなのって

一緒に検討されたりとかしてますか

チートポは主に組織の設計とか

インタラクションの設計に最後落ちると思うんですけど

人事制度にまで影響を及ぼすかみたいな意味合いで

どう捉えたり考えたりしますか

そうですね

人体にチームトポロジーと人事制度は

切り離しているところが多いかなと思っていて

結構人事制度をスケールしたいので

24:03

割と簡素でかつ運用でカバーとかDevOpsで言うと

Ops側にかなり重心がかかるような人事制度になってます

なのでそういうことも

10Xはこんな感じだと思うんですけど

今レイヤーXって言ったな

すみません

噛みました

申し訳ない

デイクさんのやつ事前に判決させていただいてたんですけど

G1からG5みたいなのあるじゃないですか

あれぐらいの多分解像度でL1からL5まであって

結構コンピテンシーみたいなのもあるんですけど

基軸となるものとしては

時間軸と影響範囲みたいなところが

グレードが上がるほど伸びていくみたいな形で

一番下のグレードだと

例えば2週間とかのスプリントの中で価値が出せて

影響範囲は自分個人に閉じてるってところから始まって

上がっていくと複数チームだったりとか

1、2年先のことを見て半年の計画が立てれるみたいな話で

評価制度を作っていて

結構それで統一的にエンジニアとプロダクトマネジメントは

評価をしているというのが現状としてあります

いいですね

うちも切り離してるので

また関係ないものとして捉えてるんですけど

組織の説教の中で

組織自体が僕はソフトウェアだなと思ってて

さらにそれを動かすソフトウェアが

人事制度みたいな感じだなと思ってるんですけど

その人事制度も同時に結構リファクターしなきゃなっていうので

4月から10月一比試行に向けて

人事制度自体もゼロから作り直しみたいなのを

やってるんですよね

そうなんですね

なるほど

でも考え方はあんまり変わってなくて

次1から8等級ぐらいまで等級の幅を広げて

迎えられる人材の等級のレンジを

上にも下にもガッと広げるっていうのを

捉えとしてやってたり

あとは等級ごとに

役職じゃないですけど

さっきおっしゃった通り影響の範囲

影響の範囲と何とおっしゃいましたっけ

時間軸の長さですね見せる時間軸の長さと影響範囲です

でもまさにまさに

例えばその組み合わせで高い等級がついてくっていうのは

結構近くて

なんで本部長を書くだったら

6等級以上だよねみたいな

その次の組織設計と

そこで求めてく役職における

大体の水準となる等級をセットで

ゆえにその時間軸と影響範囲ってリーズナブルだよね

っていう説明の仕方をしようとしてるんで

一定リンクさせつつ

人事制度も作り直しみたいなのをやったりしてますね

結構タイミングだと運用に結構負荷を置いていて

EMの方が結構先任でそこらへんをやられてるんです

人事制度のメンテナンスもそうですし

27:01

あとは自分の等級に対しての説明と

言語化みたいなのをするために

結構学習レベルでワンワンをやってるんですよね

おーすごいですね

そこで何かしらの言語化を一緒にやっていく上で

グレードに対しての認識がそろっていくみたいなところを

結構重きを置いたりしていて

なのであんまり定義よりも

運用の方が結構評価の方が大事で

かつ運用のスケーラビリティを意識した

結構ゆるいじゃないですか時間軸の話とかも

そこは運用の中でちゃんと一緒に言語化していけば

何とかなるっていうところを

結構思ったりはしていますね

でもなんかこれ今僕も等級とか評価制度とか

報酬エイトとか設計してみて思うんですけど

どんだけ超設計頑張っても

運用にかなり負荷は常にかかると思うなと思って

はいはいそう思います

運用しないと結構評価制度の基準の分って

解釈が人それぞれになっていくと思うんですよ

例えばタイミングでも1年という時間軸に置いてみたいな話だと

結構1年のリファクタリングを見据えた人は

じゃあもうその時にいるかっていうと

必ずしもそうではなかったりする際に

なんで必ずしもそうでないんだっけっていうところは

ちゃんとその情報を保管し続けないと

多分ずれていくなって思っていて

本当そうだと思います

なんかやっぱりキャリブレーション1回やって

2回やって3回やって4回やってみたいな

認識を合わせる回っていうのを重ねれば重ねるほど

東急で1回目定義してみたことと

実際に起きてることのずれで

何がデルタで出てくるかみたいなのも初めてわかるし

それに対して何を保管情報として使っていくかっていうのも

初めてわかるかなと思ってるので

設計の段階からマネージャーにこれ使って

東急の格付けやってみてみたいなテストをしながら

今は設計をしてるような感じですね

いいですねいいですね

結構そのEMを専任で今置いてるんですよね

ここって結構組織的には一定コストがかかってるから

その方にはもうコードを書かないでもらっていて

人事系のものに結構フォーカスをしてもらってるんですけど

コストが一定かかるなと思いつつ

なんかさっきの顧客価値から逆算していくと

多分顧客価値を留めつけるチームがあって

それをサポートする会社組織みたいな

そんな感じの構造になっていってそうだなって思っていて

それはすごいいいなと思ってますね

あとちょっとその分けてる部分で

すごい後悔してる部分があって

やっぱり前は事業推進者の人が

ピープルマネジメントもやってたんですよね

そうするとやっぱり事業推進者として

こっちに行きたいみたいな

今ここが大事だからここにフォーカスを置いてほしい

いわゆるWILLとCANでいうと

CANの方に結構重圧がかかって

働いてくださってた方も結構CANとしてできるし

会社のためにはこれやるべきだと自分も思います

ってやってくださってたんですけど

結局そのWILLが追いつかなくなって

転職されたみたいなことがあって

創業に近いメンバーだったんですよね

30:01

それがすごい悔しくて

じゃあそこはどうしたらいいかなってところで

その分け方にたどり着いたりとかはしました

なるほど

うちも今EMっていう型書きというか

役割を持ってまっている3名いらっしゃいますけど

3名は事業上も重たい負荷

リーダーシップを持っているっていう

多分あるあるというか

早くこの負荷を取り除かなきゃいけない

っていうふうには思っているんですけど

取り除き方から今検討しているみたいな感じですね

EMに限らないですね

ビズネフとかもプロダクトマネージャーとかも

普通に高い登休の人がそのままマネージャーも

やってるっていう形になってるかなと思いますね

そこがうまく分散できるといいんじゃないかなと

思いついてもスーパーマンは

そんなに組織としていなくなるのかもしれないなと

思いつつ

そのちゃんと深めていきたい領域が

明確な人にとってはいいんじゃないかなと

思ったりはしてますねタイミングの場合は

1000人のEMが置ける状態に

僕らもなりたいなとは思っているので

はい

でもそのデンクさんだったら

普通に募集してますって言ったら

実は結構1000人のEMやりたいって方が多かったりしていて

やっぱりその人事とかって

今取り組まれているので十分承知だと思うんですけど

かなり広いじゃないですか

で、その頬っていくとかなり広がりがあって

っていうところに挑戦したい時に

結構技術的なこともやらないといけないことって

重みになってたりするんですよね

なので結構そこの荷を下ろして

人事系のことをもっとやっていきたいっていう方は

結構いらっしゃって

割と僕は最初結構コード書かなくなるってことに対して

結構ネガティブに取られる方多いんじゃないかなと思いつつやってたんですけど

結構刺さる人にはすごい刺さって共感いただけたりしております

それはなんか素敵ないいアドバイスをいただきました

いいです、すいません

ありがとうございます

いやなんかすごく

やっぱり生々しい話が出てくるの面白いですね

まあ多分同じぐらいのタイミングで組織を始めてるんで

多分似たようなトピックが結構あるなと思いながら

そうですね

ちなみにこの組織移行みたいなのって

ある種何名とか

どのぐらいのスケールの組織みたいなのを

逆算して作ってらっしゃると思うんですよ

はい

どのぐらいのスケール化を目指して今は移行してますか

それ対応年数としては何年ぐらいを考えられてますか

ありがとうございます

一応なんですけど2年後とかそれぐらいに

今の4倍ぐらいですね

今25名ぐらいプロダクトマネジメントに入れてるんですけど

それの4倍ぐらいの規模にしたいなと思っていて

そこを目指してますという感じですね

ただしどちらかというと

そこにできるだけ早く到達したいと思ってるので

33:01

そこに向けて収束していくというよりは

そこが坂の途中みたいな感じの採用の仕方をしていて

なのでおそらく落ち着いて収束していく先が

150とか200ぐらいの規模になればいいな

というのは個人的に思ってるところです

なので結構組織側の投資をかなり先行してやっていて

EMの方とかをできるだけ取って

その方のボリューム

その方が見れる数だけ人を増やしていく

というのをやりたいなと思っている感じですね

でもめっちゃ正しいですね

なんか器のサイズを広げてから人に入ってもらうみたいな順序を作ってる

そうなんです

結構やっぱり人の問題って拾うのめちゃくちゃ遅れたりとか

結構定期的にセンシングしていかないと辿り情報って取れないんですよ

だからやっぱり先俗でちゃんと信頼関係を築いて話せる人っていうのがいる状況を作ると

まあ何かあったときにそっち側に流れてきたりとかして

早めに問題に気づけるみたいな話

それがないまま結構組織を大きくしていくと

本当に誰が何を感じながら

どういう思いをしながら働いているかっていうのはわかりづらくなっていくので

そっち側からできるといいなというのはすごく思ってます

めちゃくちゃいいし

亀池さん自身がEMとしてのキャリアが長いんでしたっけ?

そんなこともない?

いや、組織化について

でも僕がCTOになったタイミング2020年8月とかは

結構組織化を頑張りますというところを名目

技術組織です

エンジニアリング組織でちゃんとやりましょうというところなんで

結構2年選手ぐらいっていう感じではあります

まあそこの設計も運用も両方見ていく中で

結構いろんな情報が入ってくるから

これだけの解像度があるんだろうなっていう

ああ、まさに

そうなんです

やっぱり組織について詳しくなるなら

本当に組織と触れ合ってる時間が一番詳しくなってる

その角度が高いなって思ってます

初期に書かれてることとかの答え合わせみたいなの

目にいつも合うんですよね

まあ、すごいわかります

なるほど

いや、なるほどな

あのー

はい

すごい今、感心しました

ああ、なるほど

それこそ前回ポッドキャストの話いただいた時とか

あの、差分で言うと

本当に、あの

もしかしたら山本さんも怖いって言われがちみたいな話が

よくなんかいろんなところで言われてるんですけど

僕も結構言われていて

この問題を解消することに

すごくその

全身全霊を最近注いだりあうしてます

なんかアサーティブコミュニケーションみたいなところとか

その人とのコミュニケーションとしたいに

その踏み込み方みたいなところとかって

結構僕、割とガツガツなんか

ロンパするみたいな

路地腹みたいなのやってしまうタイプだったりしたんで

あのー

なんか、あの

そこらへんを頑張るぞって感じで最近やってます

ああ、でもまあ

僕も気を付けようという気持ちはあります

気を付けようという気持ちでか

まあ、いろいろケアを頑張ろうっていう気持ちはありますね

そこらへんはなんか技術って感じだなって

36:00

ちょっと思ったりはしてやってあります

確かに

あと、その今の話だと

プロダクト組織とかマインジェニアリングとか含めた組織と

今の話って前社単位には適用されてないんですか?

されてないです

あのー

マーケティングだったりとか

そのカスタマーサクセスだったりとか

前社の組織あるんですけど

ちょっとそこに対しての適用は今遅れてて

まあ、あの今

HRBPみたいな形で

プロダクト単位にプロダクトHRって組織を持っていて

まあそこで企画運用してるんですよね

なので前社はまた前社で別の人事制度を考えたりしつつ

ちょっとその話しながらどう盛り合いをつけていこうかみたいな話は

まだそのめちゃくちゃ過渡期っていう感じでありますね

あーなるほど

なるほどですね

なんか僕の場合はもう初めから前社組織として

設計手を入れ始めたみたいな感じなんで

ビジネス組織とかコーポレートとかも

一定このルールというか考え方をもとに

こうバコッと作るみたいな形で走ってますね

組織構造については

それが多分一番風通しも良くなりますし

なんかその組織間で評価制度使うと

それこそあのーなんでしょう評価制度みたいなもので

ミッション達成のための手段みたいな

先ほどされてたと思うんですけど

なんかそこがずれると多分組織としてありたい姿も

ちょっとだけずれていって

なんかそこを合わせていくのって

多分大変になるんだろうなと思ってはいるので

あの多分一番いいやり方は多分それだと思います

僕はあの自分の干渉領域でやろうとして

結果こんな感じになってるっていう感じである

なるほどなるほど

じゃあある種こう途中というか

全体とそこのこうね

足並み合わせていくってところは

まああの一種として捉えつつっていう感じですね

そうですそうですまさに

あの未来にちょっと課題を先送りしてしまってる

節はあるんですけど

送り場んとしますか

そうですそうです

わかりましたありがとうございます

だいたい僕が結構話したいことはこの辺りで

ちょっと後半戦に入っていこうかなと思うんですが

よろしくお願いします

はい

この

はいどうぞお願いします

あどうぞどうぞお願いします

あなんかあの僕すごい

宮本さんのツイートで気になってることがあって

そのなんかプロダクトマネージャーの組織化も

なんかするぞみたいな話を

最近ツイートされてたと思っていて

あそこをすごく

あのタイミングも結構プロダクトマネージメント

組織化したいなってのは思っていて

あのやっぱりプロダクトマネージャーって

認知不可の塊みたいな職業だと思ってるので

なんかただしその課題の発見とか探索って

まあ技能として分解できるなと思っていて

まあPMMとかそのプロダクトマネージャーとか

あとGoogleとかでS&Oみたいなのがいたりとか

いろんな役割があるんですけど

そんな感じに分けていくことができると

すごくいいなと思っていて

なんかそのエンジニアリング組織でやったことを

プロダクトマネージメント組織でもやってみるぞ

みたいなところのトライを結構今やろうとしてるんですけど

なんかそのTENKさんの事例を聞きたいなと思ったりとか

39:03

考えられてることを知りたいなと思ったりしてます

そうですね

まあまず僕がプロダクトマネージメント組織を預かると決まった

というかまあなんか移動というか

っていう意味で

まあ石川さんが持ってたんですよね

元CTOが持ってたんですけど

なんか僕が預かりますってなったら

7月1日で今日収録日が6日なので

まだ何もしていない

さっき言ってまだ何もしていないっていうのが正しいです

でもどっちかというと

その組織を預かる税ってなった背景があって

それはなんか

ステーラーという事業が認知不可の塊だったところから

その責任の分解点を

例えばチームとかそのステーキスホルダーとか

どういうふうに割って

その間はどうインタラクションして欲しくて

チームとしては例えば県務はどう管理するかとか

そういうものをいろいろ定めてって

ここに向けて移行してくぞっていうのと同時に

あとは事業としては

今僕らのテーマはスケーラビリティなんですよね

導入いただく方々がエンタープライズなので

1回1回の導入のサイクルっていうのが

すごい負荷が高かったり時間がかかったり

ビジネスプロセスもすごい重かったりっていうのがあります

その状態で200社とか400社とか

我々がパイプラインで捌けるかっていうとNOなので

それはできるようにするためにはとか

あとはそういった多様な勤業の人たち向けの

コミュニケーションの負荷を

どうやって下げていくかっていう

答えが2つあって

両方ともプロダクト上の大きいソリューションだと思ってるんですけど

1個はステーラっていうものをプラットフォーム化していく

それは1つ記事を書いてて

要はステーラをサードパーティーの開発ベンダーでも

使えるプラットフォームにしていく

彼らがいろんな

例えばコーリさんとかに対して

ステーラを使って価値提供できるような環境を整えてくっていうのが

1個目プラットフォーム化の話で

もう1個はそのプラットフォームの中に乗っていくアプリケーションとか

プラグインみたいな機能開発を

これまで全部が全部ではないんですけど

ある種パワー当たり的な部分ってすごいあるんですよね

例えばこのすごいGNVが大きいパートナーから来た要求なので

受けざるを得ないとか

あとはその来た要求って

2つに区分できるみたいな

ステーラが元々やりたい

プラットフォームに乗せたかった機能と

あとはパートナー向けのカスタマイズと

だけどプラットフォーム上にその機能がまず乗ってない段階だと

この線がまず曖昧だよねみたいな

それと我々が過剰なコストを払って

向こうのカスタマイズを例えばタダで実現しちゃうみたいなことが

これまで正直あったりしたんですよ

これって我々の負荷を上げてるし

逆にそれをやることによって

上がる事業の成果との見合いがすごい悪いっていう

ROIがすごい低かったり

そういう事業上のコストを下げるために

まず機能としてどういうものを作っていくのかっていうのを

42:00

中長期でロードマップとして提示して

この中身については我々が使用策定して

先に出してパートナーとコミュニケーションができたり

いついつこういうものが使えるようになるから

TENXと契約したいですっていう事業開発に使えるようになったり

コミュニケーションの負荷を下げていったりするっていう

そういう事を形にしたいなっていう

既往のロードマップとプラットフォーム化っていう

2つを掲げたんですよ

前者はかなりソフトウェアアーキテクチャの話になると

しかもすごい重たいトランジションなので

ここはそのいわゆるCTOに

ガッツリアーキテクトのレイヤーから入ってもらいたいっていうので

彼にここに集中してもらいたかったっていうのが一つと

もう一つはこの機能的なロードマップで

事業がどう成長するか

僕らで言うとネットスーパー事業がどう成長するかって思うと

完全にアラインしてないと

要はイケてるって思ってる機能を作った

例えばアプリを開いたら毎回じゃんけんができて

じゃんけんで勝つとこうやって思えるみたいな

悪魔のような機能が大量にできる可能性がある

イケてるって上がりましたとかね

そうじゃなくて事業と完全にアラインしてるものが

ロードマップに乗ってるべきで

それをちゃんと正しい機構を使って

マネージしていく必要があるってなったら

これはプロダクトマネジメントの領域だなってなって

僕がじゃあ干渉を預かろうっていう

ちょっと長い背景だったんですけど

こんな背景がまずあったんですけど

はいはい

そこで組織化をしていくみたいな

でもすごく考え方すごい共感して

結局バレーチェーンステラさんも多分長いですし

タイム長いんですけど

そこがいかに組み合わせるようになるかっていうところとか

そこをいかにエンジニアリングが噛まない形で

ものづくりができるかみたいなところで

すごくお客たちのスピード提供スピード

それこそバリューストリームが

めちゃくちゃ速くなると思ってるんですよね

まさに

エンジニアはそっち側の

バリューストリームが速くするためのツールを作って

ビズデムの方だというかセースの方がそれを用いて

多分どんどん複雑

そこで多様化していくみたいなことができるのが

多分一番プロダクトとしてイケてるなってのは

すごい常々思ったので

すごい分かるなという気持ちで

作らかってました

めっちゃそうです

多分分かりやすい例だと

eコマースの領域だとショピファイとか

もうちょっとCRMとかデータベースの領域だと

セールスフォースとか

あるいはもっと低いレイヤーの話だと

モンゴDBとか

そういうのが理想的なプラットフォーム企業だと思っていて

それに近しい形にステラを持っていくと

もっとスケールするねっていう

バリューストリーム短くなるねっていうのを

それって組織の形態と一緒なので

組織の形態を睨みながら

組織の形態というかプロダクトの状態というか

プラットフォームとしての状態も

急に一足飛びにそこになるわけじゃないので

トランジションはステップがあると思ってて

このステップと組織の状態に

構造を合わせていく必要があると思ったので

プロダクトマネジメントと人事っていう両方を

45:02

今僕が見てやるみたいな感じに

めちゃくちゃ長い旅ですね

長い旅ですね

なのでこの6日間ぐらいで僕がやったのは

まずはホンプタイム

プロダクトマネジメントというのは

ミッションと責務はこれであるっていうのを

定義するっていうことからまず始まってますと

なんで組織図とかその中でどういう関わり方で

各プロダクトマネージャーが

ワークするようにするかっていう定義は

これからなんですよ

なるほどなるほど

最初にその役割をバンって出せるのって

代表ならではのプレイングでいいなって

すごい思ったりしました

そこに多分普通の

執行役品レアの人がだったら

これどうすかねみたいな感じの

コミュニケーションが結構発生するな

と思ったりしていて

そこをガッて決めれるのは

スピードは出ますよねってすごい思いました

そうですね議論ゼロみたいな

そうなんだみたいな感じになって

いいですよね

書いたこれねみたいな

たぶん急にバーンってくるんで

すごい原爆がすると

なんかちょっと認知負荷たけみたいな

まる可能性あるんですけど

まあなんか創業者あるなんですけど

とりあえず決めて半年動かしたら

規定事実になってるプレイを

生まれてからずっとやってるのが創業者と思うんで

会社が生まれてからやってるのが

なるほどなるほど

でもそういうプロダクトを作るための

プロダクトマネージメントって

結構難しいというか

難度がすごい高いと思っていて

なんかそれができると

競合がそんなにハードトゥコピーになっていく気がするんですよね

表面で出てる機能だけをマネして作ると

すごい硬直化がすぐ起きると思っていて

そういう感じの小ノづけができると

結構モートを作れるんじゃないかなって

すごく最近思ったりしてます

そうですね

なんか技術不再を競合が作りまくるっていう

状態になると思うんですよね

そうなんですよ

っていうのがすごい思ったりしながら

タイムも結構競合が多いサービスになってきそうな

雰囲気を感じていてですね

お疲れ様です

前もおっしゃってましたよね

そうです

でもよりっていう感じを最近感じてはいますね

そうなんですね

でもなんかうちで言うと

あとロードマップもまずバコンって示したんですよ

いったん

とりあえず優先順位はついてないけど

アイテムのリストにはなってるみたいな

それがなんか事業の各ケースを伸ばすための

どこに聞くのかみたいなのが

一応全部リンクしてるっていう

ロードマップもバコンって作って

プロダクトマネジメントのミッションも定めたと

はい

基本的にプロダクトマネジメントのミッションって

このロードマップを永久的にアップデートして

でかつこれを開発に載せてリリースして

アナウンスして改善し続けるっていうのは

この全体にミッションを持つのだっていうのと

もう一個はこのロードマップを

各パートナーが活用していく

イネーブリングにミッションを持つのだみたいな

48:00

で活用していく上で絶対ギャップが出るんで

ギャップの吸い上げ方を定義していくのだみたいな

はいなるほど

プロダクトマネージャーってやることは

ここだよねっていう場頭を決めて

あとはこの組織をそれぞれ定義したり

プロダクトマネージャーのアサインを定義していくと

このアサインの中では例えば

そのさっきのギャップの定義

ギャップの発見とか

そのセンシングに全力を咲いてくるみたいな

個人としての仕事の持ち方をしてもらえるし

それが仮に開発フェーズに入ったのであれば

開発マネジメントがっつりやって

そのチームのリリースの生産性を上げていくってことに

張ってもらってほしいとか

多様が故にプロダクトマネージャーに問われる

というみたいなのって

今どこに何割削くのかっていうのを

結構自意識的になれるってことかな

っていうふうに思ってるので

多様なミッションの幅の中で

今はこれ上のセンシングに5割って

一周定義に2割って

開発マネージメントに2割って

残り採用に10%みたいな

そういうのをちゃんと

ガチガチ管理したいわけじゃないんですけど

一旦定めて自分の投資アロケごとに

ちゃんとパフォーマンスが出るようにしてもらう

っていうのをママさん組織として作ろうかな

っていうふうに思ってますね

結構プロダクトマネージャーが直すべきギャップって

無限にありますよね本当に

すごい多いなと思っていて

いつになったらプロダクトマネージャーの

認知負荷が下がるんだろうって

すごいタイミングやりながら思ってます

プロダクトマネージャーじゃないですか

プロダクトって認知負荷の塊じゃないですか

ギャップの塊というか

理想と現実のギャップを常に内包するものって

それを何とかする人っていう役職なんで

負荷が下がることはないでしょうっていうのと

ロジカルに全部決められないでしょう

っていうのも思ってるんで

割と各個人の意思をどの程度で反映できて

どの程度はエスカレしてもらう必要があるのかみたいな

ここは社長の意思で決めたい

ここはプロダクトマネージャー本部長の意思で決めたい

これは現場のプロダクトマネージャーの

意思で決めたいみたいな

レイヤー構造を作っていくとかも

これからはちょっとやってかなきゃいけないんだろうな

っていうふうに思ってます

めちゃくちゃわかります

結構説明が終えないことって

めちゃくちゃプロダクト作る上でありますよね

PL上だったりとか

何かしらのKPIに対してどう効くのかっていうところの

説明は無理ですみたいなところも

ちょっとあったりする中で

その決裁者を題にするか問題も

結構タイミングがあったりはしますね

結構そこにリソースも投稿していくので

あまりにも長い仮説になってしまってると

どうしても途中でこっち側からめちゃくちゃ干渉しないと

そこの組織のコミュニケーションが難しくなっていったり

みたいなのもあったりしていて

その時間軸の切り方とかも

結構ちゃんとやっていかないといけないなって思ったりしてます

めっちゃありま…

ただロードマップについては

今人の決裁権限に任せなくて

基幹を作ろうとしてるんですよね

51:00

はいなるほど

インプットロードマップ策定委員会みたいなのがあって

そこに事業責任者とCTOと

今いないですけどCPUみたいなのがいたら

その3人でロードマップの最終確定をするけど

そこまでのインプットは各本部からこういう形で吸い上げて

どの観点を思い出してほしいみたいなのの基幹を作ろうとしてて

はい

でその3人がロードマップ

要はアイテムはこのリストで

で有請順次の半期はこれやりますみたいなのを作って

経会議で矢本承認をとって

合意してチームにバラばかれるみたいな

いいですねなるほど

ちなみにロードマップの流度って

アイテムあたりどれぐらいの長さで見落とされてるんですか?

いわゆるユーザーストーリーベースで描いてるので

ロードマップ自体は

なるほど

そうですね

アジアでやっぱりかなり大きいサイズだと思います

1つ開発するのに

半年とか1年かかるものもあれば

3ヶ月のものもあれば1ヶ月のものもあるっていうので

ストーリーごとに重さは結構変わるかなと思ってます

短いやつだとでも1ヶ月ぐらいで見られてるんですね

見てますね

はいはいはい

じゃあ結構同じぐらいですね

タイミングも結構今ロードマップを作る作業に

結構前不審してる感じがすごいあったりする

はい

大きいサービスとかプラットフォームとかやろうと思うと

絶対どっかで顧客数とかが爆発するんで

そこに対応する手段として

ロードマップってマストになっていくなっていうのを

周囲を観測しながら感じてます

いやまさにタイミングでも最初はもう

アジャイルにやりたくないからいらんやろっていう感じで

しばらく開発してたんですけど

いやあった方がめちゃくちゃ便利だなっていう気持ちに

スター

Yamoto Masatake

スター

コメント

こちらもおすすめ