00:00
ゼロトピックです。新年明けましておめでとうございます。今年もゼロトピをよろしくお願いします。
ということで早速、年末に僕が書いたブログについて質問をいただいたので、その質問への回答をとっていきたいと思います。
早速質問の内容を読み上げます。
本年もゼロトピを含め、ヤモトさん、10Xさんの取り組みを楽しみにしています。
ブログ「10Xと私、2021年」やゼロトピの新体制JDの3回分の配信に触れ、質問です。
新組織への移行に伴い、その前段でボードメンバーを除く社内メンバーがどのように関わり、マトリックス型組織がデザインされたかをお聞きしたいです。
背景は自分も直近で組織構造を組み直す予定をしており、ボードメンバーを除く社内メンバーがいかに腹落ちし、新組織でスタートダッシュできるかを考え中のためです。
差し支えでなければどうぞよろしくお願いします。ということでご質問ありがとうございます。
この中でいただいているブログは、僕が年末に書いた「10Xと私」という1年間10Xがどういう事業の繊維をしてきて、
その中でどういう組織構造に変わったかとか、あとは2022年、今年どういう形でStaylerを進化させていきたいかみたいなものを、
グルッとまとめて書いた記事になっているので、ぜひまだ読んだことがないという方は概要欄に貼っておくので読んでいただければなと思っています。
この組織構に伴ってボードメンバー以外、経営人とかトップダウンをするようなメンバー以外がどうやって関わったかみたいなご質問だと思うんですが、
まず結論から言うと、相当な量の対話を通じて社内のメンバーからのアラートだったり、
イシューみたいなのを吸い上げた上で、組織のデザインに最後落とすという仕事を僕とか経営人で行うという形で進めたので、
そういう意味で言うと、プロセスの大半はむしろ社内メンバー側に進めてもらったというか、社内メンバー側の意向を反映するというプロセスだったかなと思っています。
どういうことかというと、もうちょっと前提をお話しする必要があって、
去年の後半ぐらいからですね、授業はとにかく忙しい忙しいみたいなことをちょこちょこ話したと思うんですけど、
本当に求められるものの水準が変わったなという瞬間があったんですね。
どういうことかというと、いわゆるシステムのQCDと言われるようなクオリティ、コスト、デリバリーという3つの要素、
このフレームワークすごい便利だなと思うんですが、
特に我々、もともとC向けのタビリーでプロダクトを作る、あるいは何もないとこにプロダクトを1個作って市場の評価を得ていくっていう、
03:05
そういう戦い方をしてきた背景が長いので、そこにある種会社自体が最適化されてたなというふうに思うんですよね。
例えばユーザー、お客様がどういう意思を持っているのかとか、それがどの程度頭の中で燃えているのかというのをどうやって判断していくかですとか、
それに対して仮説を持った時に、いかに素早くプロダクトというフォーマットに落として検証していくかとか、
その検証の結果とかお客様からのフィードバックを受け取った時に、どうやって反映していくか、どう受け取るかみたいな、
そういったサイクルがすごく早く回るような会社のプロセスだったり仕組みにすごく特化した状態で、
それが2020年で、Staylerを始めて去年の中頃ぐらいまで、かなりこれの延長というか引き延ばしに近い形で開発組織とか事業組織というものがデザインされていたなと思っています。
記事の中にも書いているんですけど、こういう前提を持っていた、コンテキストを持っていたので、
どちらかというと、さっきのQCDでいうとデリバリーに特化した体制だったんですよね。
あるいはコストみたいな、デリバリー、コスト、クオリティみたいな順で僕らが得意だったと思っています。
それが昨年、まさにバリュープロップが変わったということをブログの中にも書いているんですけど、
ある種、伊東洋稼働ネットスーパーのお客様アプリを担当する、パーツ的なStaylerという存在から、
ネットスーパーの後ろ側、要は使う方がネットスーパーのスタッフとか、デリバリーのスタッフとか、ネットスーパーを運営している小売企業のアドミンの方とか、
そういった方が日常的に1日8時間とか9時間とか使う、まさに業務を支えるオペレーティングシステムに変わったというのが去年起きたことで、
これに伴ってデリバリー、コスト、クオリティでいうと、クオリティの比重というのが急激に上昇したというのがあります。
それは当然なんですよね。普通、例えばメルカリとかLINEとかも1日8時間9時間使う人っていないじゃないですか。
でも業務用のシステムってそうじゃないんですよ。9時間つきっぱなしなんですよね。
9時間10時間本当に使いっぱなし、それがないとその人は仕事ができないっていう、そういった重大なパートを担当するものなので、
品質、要はちゃんと動くかっていうこととか、落ちないかとか、当たり前っちゃ当たり前なんだけど、
当たり前の水準を高いところで維持し続けるっていう、そういった仕組みだったり、その問題を超え続ける、期待を超え続けるような構造が必要になっていくっていうのが事業上我々に起きたことです。
06:08
これを未然に、事前に理解して対処ができていたかというと全然NOで、やっぱり現場ベースでのアラートっていうのはたくさん上がってたんですよね。
当時アラートのような強度ではなかったかもしれないけど、拾う人が拾えていたらそれは間違いなくアラートで、
それを拾えなかったのがある種経営の未熟さだったなというふうに思っています。
どういうものが上がっていたかというと、例えばスタッフはアプリを使われる、氷さんのパートナーの方の声が氷のアドミニアに上がってきて、それを対面しているビジネスデブが拾うとか、
あるいは氷のスタッフさんからの問い合わせが直接うちのカスタマーサポートとかパートナーサポートのチームに飛んでくるんですよね。
そこで問題が発覚するとか、単純にモニタリングしていてもエラーがものすごい増えているとか、
そういったものでソースコード、パートナーと相対している、スタッフと相対している人っていうところの中に負荷がどんどん溜まっていくような状態になっていたんですね。
その負荷が溜まるってことは、要は新しいことに着手ができないってことでもあるので、その状態になるっていう、その構造自体を脱さなきゃいけないっていう危機感が社内の中で醸成されていたけど、
強い手が打てていなくて、記事の中にも書いてるんですけど、いわゆるプロジェクト型の組織でパーマネントではない、一時的なテンポラリーなリソースでその問題を解消しようとしていたっていうところに結構大きな落とし穴がありました。
で、ある事象があったことで、これはもうこのままではダメだ、強い施策を打たなければいけないってことを、ある種後付け的じゃないですけど、意思決定せざるを得ないタイミングが来て、
そこで自分もその事態を初めて正確に理解するようになって、今回の組織を再編するという意思決定に繋がったわけですと。
ただ当時は組織を再編するっていうのが答えかどうかわからなくて、どこに正しいソリューションレバーがあるのかっていうのを探るってところからスタートしたので、
僕個人としては、それこそさっきのユーザーに相対している色んなメンバーのヒアリングとか、そこで起きている問題の解像度を上げるとか、それを解消するためにはどうしたいかっていうところまで
ヒアリングを通じて自分の中に蓄積していって、結果的に最後会社としてどう整合性を取るか、それは短期的な問題の解消の仕方と中長期の解消の仕方あると思っていて、
そのバランスをどう取るかっていうのが会社の中の整合性だと思うんですよね。
そこを色々検討した結果、このマトリックス型組織っていうものが浮かび上がってきて、この中にしていったっていうのがあります。
09:05
これを決めていく過程で一個自分的には契機だったなという思いがあって、
出張でその西側に出張した時に、うちの中に西側に住んでいるSREのメンバーが一名いるんですけど、
まずは彼にちょっとここまで来てくれって言って、今起きている問題をどう捉えているかっていうのを結構長い時間かけてヒアリングさせてもらうような時間を取れたんですよね。
普通であれば多分Google MeetとかZoomとかでオンラインでちょっと聞いて、30分聞いてふむふむって言ってメモ取って終わりだったと思うんですけど、
やっぱ対面でしっかり会えるのってすごい重要だったと思ってて、そこで結構問題の解像度が3段ぐらい一気に上がったっていうのが個人的にありますし、
特に彼はSREなので、特にそのコードと組織、いわゆる婚姻の法則みたいな、どういうサービスでどういう組織っていうのは必ず一致するんだよっていうものに対して、
うちが今後どうなっていくべきかみたいなところの解像度がすごく高かったんですよね。
なので、ある種組織と事業っていうのは一緒にリファクトしていく必要があるっていうのを、そこでこう改めて再認識させてもらえたっていうのが結構大きかったなと思っていて、
それを機に少しずつ少しずつ検証化されながら、こういう形がいいんじゃないかっていうのを書いていって、
彼とか他のメンバー、特にアラートを上げてくれているようなメンバーを中心に当てていきながら、最後自分と石川さんとで意思決定をしたっていうような、そんな形になっています。
意思決定が結構後手になってしまったことはすごく恥ずべきことだし、反省すべきことではあるんですけど、
改めてこの組織に移行して以降、やっぱ各チームの自立性がものすごい高まっているというか、オーナーシップがより強くなった一つ一つのチームが区切られていて、
そのチームの中の責任分解の中で全力でスルプトを出せるっていう、そういう集中しやすい状態になってきたのかなっていうのは最近実感していて、
年始以降もかなりスタートダッシュが切れているかなというふうに思っています。
ということで、質問内容はいかにメンバーが腹落ちしてスタートダッシュできるかというところだったんですけど、
この浸透みたいなプロセスを強く持ったわけではないんですよね。
結論を全体に伝えたのはたった1回、全体のオフサイトで30分で話しただけ、その前にドキュメントがあってみたいな流れなので、
腹落ちを頑張ったっていうよりも、むしろ現場に漂っていたものっていうのをちゃんとすくい上げて構造にして、やるぞって決めてガラッと動かすっていう、
ガラッと動かすのは大変だっていうのをVizDevのメンバーとかもポトキャストで話してたと思うんですけど、
それをやり切るって決めたら、あとはやり切るだけなんで、そこを決めるっていうのがすごい大事だったのかなというふうに思っています。
こんな回答で参考になれば嬉しいですね。
もし追加に何かあれば、ぜひこれを聞いた上でまたいただければと思っています。
12:05
ということで、チーム切れてからかなりスタートダッシュがうまくかかっているんじゃないかなっていうのを客観的には感じていて、
今年もその域をそのままに大きく飛躍できる年にできればいいなと思っているので、
ぜひTenX、StayLar、Zerotopy、私みたいな形で今年もよろしくお願いできればなと思っています。
それでは。
