変化に対応する自立自走する組織の創り方
Retty執行役員VPoPの野口です。どんな組織を創っていくべきか、経営層やマネージャーの方々向けに書いていきます。メインは開発組織向け、ただそれ以外でもお役に立つ内容になればなと。この記事は「マネジメントアドベントカレンダー2021」の16日目です。EVeMの紺野さんお誘い有難うございます!
改めまして、RettyでPM・デザイナー・CS・コミュニティマネージャーが所属する部門を担当している野口です。普段はPMコミュニティに顔を出すことが多いです。今年はpmconf2021で登壇の機会も頂きました。アジャイルの勉強をすることも好きです。
マネジメントとは組織の成果を生み出すもの
組織に成果をあげさせるのがマネジメントであり、マネージャーの力
と、マネジメント 基本と原則 / P.F.ドラッカーには書かれています。
そのために、マネージャーは何をすべきか。Rettyではマネージャーの役割を以下のように定義しています。
世の中的に語られる役割と近いと言えるでしょう。
この中で「②チームを創って育てる」と「③メンバーのモチベーションアップ」の「メンバー支援」という文脈。これらについては、EVeM社のマネジメント研修を受けたRetty諏訪が詳しくまとめてくれています。
マネジメントの役割や基礎をインストールした上で、特に開発チームビルディングとして、どんな組織を創るべきでしょう。
変化が激しい時代をいかに戦うべきか
現代はVUCAの時代と言われています。
Volatility:変動性
Uncertainty:不確実性
Complexity:複雑性
Ambiguity:曖昧性
スタートアップで戦っていると、身に沁みてわかりますよね。競合との争いはより熾烈に。かつてのようなシンプルなメディアやアプリリリースだけではプロダクトは市場を勝ち抜けず、開発の複雑性は増す一方。にもかかわらず、ますます優秀人材の獲得難易度が上がる採用市場。そして、コロナ禍による影響。まさに不確実性の高い、変化の激しい時代です。
変化に対応できる組織こそ求められる
市場や外部環境による変化が激しい時代において、会社の方向転換に対して直ちにチームが順応することは重要です。また時にはトップの決断を待たずにチームや個人が即判断して実行すべきタイミングもあるでしょう。
これは開発においてはも当てはまります。外部環境や顧客の変化によって、不要もしくは優先度が下がる機能があったとします。にもかかわらず、その開発を中止もしくは軌道修正せずに当初の計画通り開発していると、ビルドトラップに陥ってしまいます。これはアジャイル開発宣言で記されている「計画に従うことよりも変化への対応を」とも一致します。変化に対応できる組織が今まさに求められています。
元来、"Management"は「管理する」と日本語で訳されることが多かったワードです。これを鵜呑みにしてトップダウンに指示命令・進捗管理を行うだけのマネジメント・組織では、変化への対応について、マネージャーが全て判断→指示を行わないといけません。これではスピードが出ず、場合によっては現場で起こっている顧客の声や市場変化の予兆を見逃す恐れがあります。これが管理するマネジメントの限界です。ではどんなチームを作れば良いのでしょうか。
自立自走する組織しか勝たん
変化に対応する強いチームとは"自立自走するチーム"ではないでしょうか。
抽象的な組織が目指すゴールを見据えて、あるいは抱える課題を突破するために。時には上司の指示を待たずとも、自ら判断し、実行することができる。そんな自立自走型のチームが求められると言えるでしょう。
もちろん、大きな局面ではトップやマネージャーからの方針提示が必要です。しかし日々直面する課題によっては、即決断・即実行が求められることもあります。そうした場面ではマネジメント層の判断を待たずに、時にチームメンバーで決断することも重要です。
また開発においてはプロダクトオーナーやプロダクトマネージャーがWhyやWhatを考えるものの、Howつまり実際のソリューションは技術に長けたエンジニアが考えた方が良い解決策に繋がりやすいです。変化に対応し成果を残すためには、課題発見→解決をできる限り現場で迅速に行えるチームこそ求められています。
では経営陣・マネジメント層はどうやって自立自走するチームを創っていけば良いか。以下の5つが重要です。
①ビジョン・方向性への共感
②振り返り
③正しい期待値
④学習の促進
⑤仲間を集める
①ビジョン・方向性への共感
ビジョン・方向性をチームにしっかりと浸透させましょう。
会社やプロダクトのビジョン、何のためにこのミッションに取り組んでいるかしっかりと説くことが重要です。
方針転換もこまめに共有
ビジョンに加えて戦略や会社の方向性についても同様です。IR関連や重要人事情報は例外として、会社戦略の方針転換がある場合、私は前もってまだ不確定なタイミングからマネージャー陣に伝えるようにしています。
・方針が変わりそう
・方針を変える意思決定する
・方針が変わる意思決定になった
・新しい方針を全体周知する予定
このくらいの粒度でできる限り伝えるようにしています。これにより悪いサプライズや決定に対する大きな反発はあまり起きません。嬉しい驚き以外のサプライズはなるべくなくすべきです。
チームが方針転換をある程度事前に感じ取ることができれば、臨機応変に柔軟な動きができるようになります。逆に方針転換を決定後に初めて聞き、急な対応を迫られると背景を理解しきれないため直ぐに対応できず、チームは徒労感を覚えます。全員に対してでなくても良いですが、今後の方向性について、上司からメンバーに対してフランクに1on1で壁打ちしていく。戦略方針の確度を上げる効果もあり、非常に有効なプロセスです。
トップダウンなき良質なボトムアップはない
「開発チームからの提案がない、積極的に動いていない」
そんな声をよく聞きます。メンバーが動かないのはあなたが道を示さないからです。トップがどういう方向に進みたいかを示せないとメンバーは動きにくいはずです。もしメンバーがアクションを取れたとしても、各々が噛み合わないもしくは全体の方向性とマッチしない状況に陥ります。
数年前のRettyでは優秀なエンジニアメンバーを採用し、各々がやりたい技術選定やチームビルディングを行い、自由に開発を進めていた時期がありました。ただ全体でどういう開発チームになりたいか、どういう技術スタックでいくのかの絵がなく、各人が合意できていませんでした。結果として、各々のやりたいようには進まず空中分解してしまいました。
現在では反省として、エンジニアチームは技術ロードマップを描き、その絵の下メンバーが各々やりたいことを提案→実行するようになり、ボトムアップを起点とした成果も出てくるようになりました。
私自身もある程度方針が固まってない段階でも、ざっくり「〇〇なプロダクトにしたい」「組織は××な人を増やし、△△なカルチャーにしたい」というのを事前に共有しておくようにしています。そうするとチームが次の動きを察知して動いてくれます。全体の大きな絵がおぼろげでも、向かっていきたい方向性は発信していくことが大切です。まずは1on1やtimesを活用し、「まだ解像度が低いけど・・・」と断った上でも良いでしょう。発信しないと何も伝わりません。
と色々書きましたが、弊開発チームでもプロダクトビジョンを今まさに再定義しており、戦略方針を浸透させる動きについても継続的に行っています。ここは経営陣・マネジメント層は日々努力し続けることですね。
②振り返り
過去の良かったことを継続する、課題に対して改善アクションをし続ける。マネージャーに言われなくても、チームで自発的に振り返り、次に繋げるサイクルが回っていく。そうなれば、少しずつでも確実に組織は成長します。
チームの振り返りの習慣化
まず大事なのはチームで振り返りを行うことを習慣化すること。Rettyではエンジニア組織5チーム、PMデザイナー組織4チームで毎週のイテレーション終わりに振り返りのKPTを行います。そして、各チームのスクラムマスターや代表者が集まり、振り返りで出た声を共有。1チームの振り返りでの学びを全体で活かせるよう取り組んでいます。一個人や5人程度の1チームで経験できることはどれだけ頑張っても限界があります。ただ他チームの振り返りも毎週インプットできるというのは、学びが広がり倍速成長できている感覚があります。個人的にも毎週の振り返り共有会は学び多き場です。
RettyのPMが振り返りについて書いた記事
リーダーは朝令暮改を恐れるな
振り返りの重要性は経営層やマネージャー自身についても言えます。
チームを率いる立場であれば"Keep良いこと"は振り返りやすいでしょう。大抵のリーダーはポジティブなことをチーム内に共有することは得意です。一方で、自戒を込めてでもありますが、トップが引き起こした失敗を振り返ることはかなり難しいことです。「過去の方針が間違っていた」、「誤ったチーム編成を行った」など。過去の間違いを認める発言をすると、「無能なリーダーと思われるのではないか」、「方針がコロコロ変わっていると思われないか」などと心配になりますよね。
確かにコロコロ変わるように見えるのは問題なのですが、今は変化が激しく、やり方もどんどんアップデートされる時代。施策を打ち始めると思っていた結果が得られなかったことも往々にしてあるでしょう。そんな時は、誤ったやり方を続ける時間がもったいないので、過ちを認めてすぐに方針転換すべきです。変化の激しい時代には朝令暮改も必要です。私もチーム編成やKPI設定で失敗したことは何度もありますが、謝った上で、失敗を分析して次のアクションを伝えるようにしています。
もちろんCOREのビジョンや戦略大上段がブレないことが前提です。COREの思想がブレていなければ、チームは納得して次の打ち手方針に沿ってやり方を変えていってくれるはずです。
最近では新庄BIGBOSSがコーチ陣にも身だしなみを考え、白髪染めするように指示を出しました。しかし「カラーアレルギーの人もいるのではないか」という世間の声を受けて、翌日には前言撤回。彼は「明るくカッコ良く楽しいプロ野球チームになる」というブレないビジョンの元改革を進めていて、自分の発言の過ちがあれば、すぐに修正なさっています。ちょっとしたエピソードかもしれませんが、素晴らしいリーダーだと感じます。
③正しい期待値
自立自走するためには、上司からの正しい期待値が必要です。目標数値の設定、定性的な達成したい状態の言語化、そのためのアクションの明確化など。短期・中期でどんな組織貢献をしてもらいたいかは言語化をして、マネージャーからメンバーに正しく伝達する。会社・上司から何を期待されているかがわからなければ、パフォーマンスが最大化されません。
また「どこまでの権限・責任をもって実行したいのか」、逆に「報告・相談して欲しいのはどういう場合なのか」など権限移譲が曖昧な場合は、正しい期待値摺り合せのためにデリゲーションポーカーが有効です。
加えて、メンバーの得意・不得意を正しく把握しましょう。Rettyではストレングスファインダーを活用しています。例えば、技術面に強くないメンバーにBigQuery習得と分析タスクを依頼する、これまで作業タスク中心のメンバーに合意形成が必要なタスクをお願いするなど苦手なミッションを与える場合、「不得意かもしれないが、チャレンジしてほしい」という期待値が擦り合っているだけで心理的安全性は高まり、メンバーは挑戦しやすくなります。
④学習の促進
言わずもがなではありますが、継続的にチームが学習しないと、自立自走したチームにはなりません。
開発に限らず、スタートアップが取り組み課題の複雑性と難易度は日々上がるので、メンバーがアンテナを張って継続的にスキルインプットをしていくチームは強いです。数年前と比べて、良書・良記事、再現性のあるフレームワーク、勉強会やコミュニティも圧倒的に増えました。業務時間と被っても、良い勉強会であれば積極的に出席するよう支援してあげるべきです。社内勉強会や輪読会もRettyでは積極的に行っています。
一緒に勉強会に出るのはおすすめ
「メンバーにすすめても、なかなか勉強会に出ない」という方には一緒にオンライン勉強会に出席することをおすすめします。Rettyではよくやるのですが、pmconf2021の時にも専用のSlackチャンネルを作って20名くらいでワイワイ話したり、その後公開されたアーカイブ動画を集まって見たりしていました。皆でワイワイすると、イベント感覚で参加のハードルがぐんと下がります。
また記事を見せたり、勉強会の後日共有ではなかなか重要なポイントやそれを踏まえて導入したいアクションが具体的に伝わりにくいこともありますが、一緒に見るとライブ感があるので勉強会の重要ポイントの共感度が上がります。上司を説得して新たなフレームワークを導入したいという時にも有効な手法です。
⑤仲間を集める
色々書きましたが、なぜRetty開発組織が自立自走しているのか。それは過去の採用が上手くいっていたからと言えます。専門スキルはもちろんのこと、こんなマインドやスタンスのメンバーがいるからこそですね。
・組織で成果を出すことを重視する
・技術やチームで成果を出すために学習することが好き
・顧客の課題にアンテナを張ることを厭わない
組織で成果を出す経験がなくても、学習サイクルがまだ上手く回っていなくても、顧客課題の拾い方を知らなくても問題ありません。大事なのはそれをやりたいと思うか。機会があった時にそれをチョイスできるかです。スキルは伸ばせても、マインドやスタンスの変化は一筋縄ではありません。
Rettyの開発メンバーは得意不得意はあれど、皆この3つのマインドを持っているように思います。会社や職種によって色んなスキルが必要になるとは思いますが、これらのマインドは外せませんね。
MeetyとRetty Advent Calendarの宣伝
今回はマネジメントの観点で"自立自走する組織を創るために"というnoteを書きました。少しでも組織作りの参考になれば幸いです。
RettyではMeetyをやっております。もう少し話を聞きたいという方はぜひこちらで「話したい」を押してみてください!
Retty社では今年は2種類のAdvent Calendarが動いてます。そちらも見てみてくださいね。
頂いたサポートを記事を書くためのインプットに活用します