話せる信頼関係、情報の透明性、実行する裁量　自走するチーム体制構築に大事な「チームの三領域」

リーダーからの号令が伝わらないと、メンバーは自走できない

伊美沙智穂氏（以下、ムラキ）：さて、どうすればこのビジョンでそれぞれの組織が自走できるのでしょう。部門長との合意が取れただけで、本当の本当に現場まで同じビジョンを目指して自走できるんでしょうか？

というわけで課題2。各組織が自走するチーム体制の構築に移りたいなと思います。

前提として、組織があった時に、戦略は基本的に上から下までつながっているはずですよね。会社ビジョンがあって、会社の戦略があって、事業戦略があって、弊社みたいに事業がプロダクトを基幹にしているんだったら、ここがほぼプロダクト戦略になって、そのあとに各部門の戦略がついてくると思います。

会社戦略ぐらいまではビジョンを作る時に散々話したので、つなげることができていました。

じゃあ下半分。現場の戦略にはどうやったらつなげられるんでしょうという話をしていきたいと思います。

この話をするために、先ほどのように前提の話をしたいなと思いますが、「そもそもどういう組織になってほしいんだっけ？」という話をしておきたいなと思っています。

冒頭から何度も「チームとして動く」「自走する」「自律的」みたいなことを言っていますが、これはつまりどういうことなんでしょう。

おさらいとしての大前提を話しておくと、ここ数年の私たちの組織は、すごく拡大して人が増えてきていました。

再び某海賊団を例に出したいと思うんですが、これまで強烈なリーダーシップでリーダーが直接メンバーをまとめる形式でした。これは組織が小さいうちは効率が良いやり方だと思っています。リーダーがそれぞれ「お前は航海士になれ！」「お前はコックになれ！」「お前は剣士になれ！」と……。この船長が「剣士になれ」って言ったかどうか記憶が定かじゃないんですけど。とにかく直接話して、直接指示を出してまとめるわけですよね。

ただ、これが大きな組織になってくるとそうもいかなくなってきます。10人の船員になら直接話せても、1,000人の船員全員と直接話していたら話すだけで日が暮れるどころか、たぶん365日が終わっちゃうかなと思います。

そういう場合は、「あのボスを倒すぞ！」みたいなビジョンに基づいて、小さく切ったチームがそれぞれ「戦闘します！」「奇襲します！」「物資補給します！」みたいな感じで、自律的に動くような体制が望ましいし、たぶんこうでないとメンバーと話すだけで1日が終わってしまうかなと思っています。

ただ、まずこの号令が伝わらないことには動けないですよね。

自走するために大事な3つのこと

なので、どうすれば情報が伝わって、どうすればメンバーが自走できるのかをうんうん考えていました。

自走するために大事なことは何だろうといろいろと考えて、それこそ『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』とかね。ああいう本をいろいろ読んだりして、最終的にこの3つのことが大事だろうなと思いました。

先ほどのプロダクトの三領域にけっこう近いかなと思いますが、イメージとしては「チームの三領域」という感じですかね。まず上の丸、話せる信頼関係。これはPO（プロダクトオーナー）やPMへの信頼があって、各部と会話をするための関係性が築けていることを指します。次の左の丸は情報の透明性。

情報とかデータにメンバーの誰もがアクセスできて、POとほぼ同じだけの情報をキャッチアップできることを指しています。最後に右下、実行する裁量。これは各部が裁量を持って動ける体制があることを指しています。

プロダクトの三領域と同じで、これはどれかが欠けても自走する組織にはならないだろうなと感じています。例えば仮に信頼関係があって情報に透明性があっても、実行する裁量がなければ自分の意思で実行できないし、信頼関係があって裁量があっても情報が不透明だったら情報がないため判断できないですよね。

「じゃあ今の組織に足りていないところはどこだろう」と考えると、全部テコ入れしないとあかんなと思いました。私はもともとデザイナー兼PdMとして働いていたんですが、オーナーとして着任したばかりで、ビジネスサイドとの関係性はやはり薄いままだったし、情報の透明性の観点では、新ビジョンがまとまっている資料はまだまだ少なかった。

実行する裁量の観点は、私の一存でどうにかなるところじゃないんですが、ビジョンを変えるならチーム体制も変えなきゃいけないんじゃないかと思っていました。

信頼関係を築くために行った取り組み

というわけで、この1年弱ぐらいで、それぞれの観点でいろいろと取り組みを進めてきました。ただ組織作りとなってくると、私のみでやれることの裁量を越えているんですよね。なので社長、事業部長、CTO、エンジニアリングマネージャーとか、いろいろな人と一緒に進めた取り組みの話になります。

それぞれに対していろいろと働きかけをしようという話をしたので、一つひとつ説明したいなと思うんですけど。

まず1つ目。信頼関係を築くこと。ここはいくつかの観点があるんですが、大まかに会話するための会議体とか、意見を出せる仕組みを検討していきました。例えば、経営層との方針合わせのためにはSteering Committee。つまり大規模な方針を決めるための会議体を設置してみたり。

あとは開発メンバー、特にエンジニアに情報を展開するために、「Product All Hands」という、デザイナー、アナリスト、リサーチャー、あとはエンジニアみたいなプロダクト開発陣全体をまとめたオールハンズを開催してみたり。「週次の『Engineering All Hands』にPMとして参加してみよう」みたいな話だったり。

あとは現場のビジネスメンバーがプロダクトに参画して、いわゆるプロダクト意識みたいなものを醸成できるように、言い方はちょっと悪いんですが、全社ミーティングで大規模開発案件のリリース前デモをして、みんなに対して「こういうものが出るよ」「こういう意図でやったよ」みたいなことを丁寧に説明してみたりしました。

あとは会社の誰しもが書けるプロダクト目安箱みたいなものを設置して、現場がプロダクトに対して意見を上げられるようにしました。それに対して私たちもちゃんと返信をして、それがみんなに対して見えるようにするとか。

そういう取り組みをしていって、なるべく全体に対して話せる、信頼関係を築ける体制を構築したいなと思って取り組みを進めていきました。

情報の透明性を確保するために行った取り組み

次に情報の透明性の観点ですね。これはプロダクトに関わるすべての人……エンジニアとかデザイナーとか、ビジネスメンバーとか、もう本当にすべての人を指すんですが、彼らが可能な限りPOと同じ情報にアクセスできる体制や仕組みの構築を行っていきました。

例えば、誰でも参照できるドキュメントを整備して、メンバーがふと困った時にPRD（Product Requirements Document）とかロードマップに立ち返れたり、新しいメンバーが入った時に説明できる紹介資料を用意したり。

あとは、判断材料を増やすためにアナリストと協力して……。データアナリストがよく「データの民主化」と言ったりしますが、こういうデータの民主化を進めていくべくダッシュボードを整理したり。ユーザーリサーチチームを新たに設立して、リサーチャーによる質的調査を進めていったり。

ちなみに弊社はアナリストとリサーチャーが私のチームであるPM部に一緒に入っているので、このあたりは同じ部門だからこそけっこう進めやすかったかなというのはあります。

あとは、先ほど信頼関係の項目で「プロダクト目安箱を設置しましたよ」という話をしましたが、ここへの投書や返信を「Slack」通知するようにしました。

この目安箱への返信は、私だけではなく、私の部門にいる他のPMも行います。ビジネス側からの要望は、正直に言うと「N1のお客さまがこんな要望を出していた」みたいな。

弊社はBtoBtoCサービスなので、アカウントマネージャーというクライアントと直接話すマネージャーたちがいるんですが、彼らだと、自分のお客さまが言ったことを「この人がこうやって言っていたからこういう機能が欲しい」と言っちゃったりとかがわりとあるんですよね。

それをプロダクトにそのまま還元するのは、受託事業ではないのであまり良くなかったりするんです。そういうものが多分に含まれていて、そういうものを断らざるを得ないシーンはあるんですが、断る時にもなるべくそ「プラットフォーマーなので」みたいなところを懇切丁寧に説明をして詳しく理由を書いているし、弊社のメンバーのPMにも「きちんと書いて他の人たちが参照できるようにしてね」という話をしています。

というのも、そうやってプロダクト観点での会話を繰り返すこととか、あとは意見を出した当人だけではなくて、Slackを見ている他のメンバー全体に対して広く開示されることで、ある程度プロダクト意識が醸成されたらいいなという願望がありました。

あと、そういった会話をログとして蓄積していくことで、これから新しく会社に入って来る人たちもこれまでの経験から方針がわかりやすくなるかなと考えたので、こういう取り組みを進めていきました。

裁量のための組織作りのために行った取り組み

最後に実行する、裁量のための組織作りですね。正直ここは本当にPOの範疇を越えていて。それこそ本部長とか人事の領域に入ってきちゃうので、とにかく彼らと方針の話をしていきました。

例えばビジネス側のチーム検討。これはプロダクトのビジョンを書き直した時に、ちょうど人事部側の組織の再編成のタイミングだったこともあって、「ビジョンに合わせた組織構成」というネーミングに変更しました。

今はビジョンと組織名が1:1で合っているような状態になっています。実際にスタートしてみて感じたんですが、この命名が（やっていることに）合っていることはすごくやりやすかったです。

新しい人が来た時にも「この部はこういうことをしているよ。この部はこういうことをしているよ」ということがビジョンと一緒に説明をしやすくて、命名は思ったよりも重要なんだなとすごく感じました。

もう1つ大事なことは、開発側のチーム検討ですね。今聞いている方の中にもエンジニアリングマネージャーの方がたくさんいると思うんですが、これは弊社のEMと一緒に進めていきました。

弊社の開発組織は実は2022年までエンジニアリングマネージャーがいなくて、PMが直接エンジニアにissueを切るような、まったくモダンではない開発体制で進んでいました。

これはまぁ、いろいろ事情があってEMがいなかったから組織作りがままならなかったとか、エンジニアが少なかったからエンジニア構成が「むにゃむにゃ……」みたいな感じで、正直もごもご言い訳を言うしかないんですが（笑）。

組織拡大に伴って、さすがに開発体制をしっかり整備し直さないといけないなということで、EMと協力してチームを切ってスクラムを導入して、スクラムマスターを設置して、各チームにPOを配置して。ある種、当たり前な環境整備に尽力しました。

この際、やはり裁量というのはすごく大事で、チームをどういうドメインで切って、チームごとにどういうオブジェクティブを持ってもらうのかというのは、EMと毎週議論をすごく重ねて、「エンジニアが裁量を持ってプロダクトを進化させられる体制を作りたいね」という話をしています。

ここは本当に道半ばで、例えば「PMからのSpec docをテンプレート化してエンジニアとPMの会話を円滑化しよう」みたいな取り組みとか、いろいろなことをやっています。完璧ではないですが、今もずっと続けてきています。

現状のメンバーからの反応

さて、そんなこんなでいろいろな取り組みをしてきました。まだまだ道半ばではあるんですが、最後に、現状のメンバーの反応がどんなものかという話をしたいなと思います。

結論からいうと、着任から8ヶ月弱でおおむね達成したかったことはできている気がします。例えば、デザイナーから「デザインに悩んだ時に、PRD資料とかビジョンに立ち返って方針を考えるようになったよ」みたいなフィードバックをもらったり、エンジニアに「設計する時にプロダクトロードマップを加味するようになったよ」と言ってもらったり。

あと、これはすごくうれしかったんですが、ビジネスサイドから「プロダクトサイドがなんでそれを作って、なんで作らないかみたいなことが説明がなくても理解できるようになってきた」みたいなことを言ってもらえたのが、すごくうれしいなと思っています。なので、完璧ではないんですが、自走するために最低限の環境を揃えることができたんじゃないかなと考えています。

これからの課題

一方で、これからの課題はいろいろあります。（スライドを示して）プロダクトマネージャーなのでプロダクト側の側面はもちろん粛々とやっていくとして、むしろ難しいなと思っているのは、この右側のメンバー的な側面のほうですね。

これはやはり人対人の話なので、一筋縄ではいかないなと感じています。例えば「ドキュメンテーションをして情報の透明性を図った」という話をしたんですが、実際にどれだけドキュメントを用意してもどれだけデータを開示しても、進んで見に来るメンバーばかりではないんです。

単純にビジネスサイドだと特にデータを読める・読めないというような話もあるし、あとは説明されるのを待っているようなケースもあります。先ほど「プロダクト目安箱を設置した」という話をしたんですが、投書を見ていても方針をあまり理解できていないような内容が上がってくることは稀にあるので、根気強く伝える必要があるかなと思っています。泥臭く話し続けるしかないかなと思っていますね。

とはいえ、先ほども話したように、一人ひとりに対して懇切丁寧に話して回っていても日が暮れちゃうので、適切に責任分掌をしながら、例えばエンジニアにはエンジニアリングマネージャーから説明をしてもらうとか、営業には他のPMからというかたちで、他の人に説明を任せることは必要です。そのためには、他のEMとかPMが説明できるだけの状態を私が作っておくこともすごく大事だなと感じています。

それはそれとして、それぞれのメンバーの能力を底上げしていきたいな。例えば、データアナリストには、今はデータ分析レクチャーみたいなレクチャー会をお願いしているし、リサーチャーにワークショップを開いてもらってユーザー理解の大切さをビジネスサイドとかに知ってもらうような会を設けたりもしています。

これはより足元の課題なんですが、今は開発組織がすごくグローバル化をしてきていて、かなりの割合が非日本語話者になりつつあります。開発チケットとか、開発ミーティングとか、すでに英語を中心にしつつあるんですが、プロダクトロードマップとかはビジネスサイドも読むので、日本語中心で書かれてしまっています。

今後は最低限の英語のドキュメントも必要だろうなと考えているんですが、同じドキュメントを複数言語でメンテナンスしていくのもなかなかコストが大きいので、ベネフィットとコストのバランスをどう取っていくのかみたいなことは悩ましいなと思って模索中です。

最後に、これはどのプロダクトでも永遠に解消しない課題かなと思っているんですが、変化の柔軟性を持ちたいなと考えています。まずはいろいろスタートしたところで取り組みを進めましたという話をしたんですが、状況は常に変わるので、あれこれ考えて作った新しいプロダクトビジョンも、これが本当に正しいのかは誰にもわからないと思っています。

なので、とにかく変化に対応できる体制構築が必要です。これは仕組みというよりも、メンバーの意識の持ち方をどう醸成していくのかとか、私がどういうふうに指針を出すのかという話かなと思っているので。これもまた難しい話ではあるんですが、がんばっていきたいなと思っています。