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ヶ月ぐらいで見られてるんですね
見てますね
はいはいはい
じゃあ結構同じぐらいですね
タイミングも結構今ロードマップを作る作業に
結構前不審してる感じがすごいあったりする
はい
大きいサービスとかプラットフォームとかやろうと思うと
絶対どっかで顧客数とかが爆発するんで
そこに対応する手段として
ロードマップってマストになっていくなっていうのを
周囲を観測しながら感じてます
いやまさにタイミングでも最初はもう
アジャイルにやりたくないからいらんやろっていう感じで
しばらく開発してたんですけど
いやあった方がめちゃくちゃ便利だなっていう気持ちに
最近になってきて
なりますよね
あとそこに情報を収集されることで
何か公平な検査が行えたりとか
ディスカッションのベースになっていくので
ロードマップ中心に
どれだけリスク取るかみたいな話とかも結構できたりとか
将来的なスケールにおいての
ここまでやらないとまずいみたいなものとかを
ちゃんと示せるようになってるので
そういう感じにやっていくと
結構安全だなっていうのを最近思ってます
そうですよね
だからそこにロードマップにどういう負荷情報を足して
何を判断軸として持っていくかって
めちゃめちゃ色が出るんで
次はその設定をしなきゃなっていうのを
今は思ってるところですね
確かにわかります
タイミングだとリスクも結構多いんですね
ローム管理とか給与管理とかしていて
そこが間違った時のリスクとかを評価するのに
使ったりとかしていたりしますね
あとはなんだろうな
あと採用計画に圧をかけるための
ロードマップでもあったりしていて
ここやりたいっていうところは
ジーナロケーションもなんとなく
Tシャツサイズぐらいでやってるんですけど
大きいの買ったら割と人いるよねっていうところが
半年後とかにプラス5人とか10人が居りますね
みたいな状況にしておくと
採用やってる人にすごい
そうですねっていう感じになってもらえたりして
そんな感じで弊社は使ってます
そうですね
それも採用とかHRBP的に
54:00
割と組織を預かる機能っていうのが
結構責任分解きっちり分かれてるから
いい県政関係ができてるんでしょうね
まさにそういう感じですし
なんならこれを全社的にやっていきたいな
っていうのは最近すごく思ったりはしてますね
わかる
全社にHRBPとか採用サポートとか
そういう機能を付与したいぜみたいなのも
最近僕が人事本部長を権任することになって
急に発信されて現場が戸惑うみたいなのがありました
いやーその領域に詳しい人じゃないと
HRBPとか人事に勤まらないってのはありますよね
ありますね
なんで昨日エンジニア出身のHRBPやりたい人
EM出身のHRBPやりたい人ってのを
タイツに募集してますと
おつぶやきさせていただきました
という感じで
だいぶ時間も時間ですが
すごく濃いお話ができて
大変勉強になりました
こちらこそすごく楽しく話したい
割と用意ドンが一緒だった感じもしてるので
またどこかで答え合わせじゃないですけど
どうですかみたいな話とかもできると嬉しいなと思いました
そうですね
ぜひどっかでWhatsAppさせてください
じゃあ最後に宣伝があればどうぞ
宣伝
てんきくんさんもタイミーも等しく採用しております
ぜひ皆さん興味を持ったら話しましょう
よろしくお願いします
タイミーに興味を持つ人は
何がフックになることが多いんですか
キャリア的な話で言うと
何かしらの専門性を持つことがしたい方には
結構フックになってるかな
先ほどのチームトプロジーとかもそれに合わせて作ってるので
そこらへんがあるかなと思ってます
事業に関しては
アルバイトという働き方を全部塗り替えようと
今だと非正規雇用と呼ばれてるんですけど
それを全部変えてしまいたいなと思っていて
そういう部分に興味ある方は
ぜひ楽しい仕事を働けるんじゃないかなと思っております
でかいですね 産業DXですね
そうです
素晴らしい
ぜひタイミーもTENXもよろしくお願いします
今回亀木さんに来ていただきました
ありがとうございました
ありがとうございました
♪~
