この記事はテックタッチアドベントカレンダー14日目の記事です
こんにちは、テックタッチ株式会社の kenyu (@mxxxxkxxxx) です。ソフトウェアエンジニア兼ピープルマネジメントを担当しています。
弊社ではマネージャの責務を分解し、チーム運用しています。この記事では実例を交えつつその説明をしたいと思います。
注意
当記事は B2B SaaS のスタートアップにおける15人程度の開発組織を前提としています。そのため、記事の内容は組織によって成立しない可能性があることをご了承ください。
背景
弊社は B2B SaaS のスタートアップです。それがゆえに、ヒト・モノ・カネのようないわゆる経営資源の乏しい会社です。
そんな状況で普通にやっていては、例えば IPO のような大きな目標を達成することは困難です。ではどうすればいいか？と自分に問いを立てたとき、脳裏に浮かんだのは、
メンバーひとりひとりの成長と成果を最大化すること
です。さらに、それを実現するために必要なコンピテンシーとは、
1, 自律的であること
2, 大きな目標に挑戦し続けること
と考えました。したがって、次に考えたのは、
そのコンピテンシーを毀損する要因を排除すること
です。
ではその要因とは何か？私は要因の一つとして組織の階層構造を挙げられると考えています。階層構造によってどのように毀損されるのか、それは下記の通りです。
1', 上意下達が基本の指揮命令系統により、自律的行動に制約がかかる（1の毀損）
2', 階層によって責務が細分化され、裁量が限定される（2の毀損）
1' は上司が部下を指揮した上で業務を進めることになるため、部下が自発的に何かに挑戦するとするならば上司に相談した上で、となります。リスクヘッジという観点では当然のことですが、一方でそれは一定の心理的ハードルや開始までのリードタイムを生じさせるデメリットがあります。
2' については自分の守備範囲を越えて何かをしようとするのであれば越権と見なされないように上司含め根回しする必要があります。これも 1' と同じデメリットがあります。
1', 2' の課題を解決するため、私達は上司に相談ではなく仲間にフィードバックをもらうという形を選びました（合意形成はせず、意思決定はあくまで本人が行います）。ゆえに、私達は階層組織ではなくフラットな組織を目指すこととなります（いわゆるティール組織やホラクラシー組織のエッセンスを加えつつ、全体の組織設計をし続けることになるのですが、今回は開発組織にフォーカスするため、全体に関しては割愛します）。
もちろん階層構造であっても上記の如くコンピテンシーが毀損されないための文化や仕組みがある会社もあります。
とはいえ、安定して着実に成果を上げ続けることを目的とするのであれば階層構造は適してはいますが、その構造上、スタートアップのように非連続的成長を実現し続けるには適していない部分があるものと考えています。
責務の分解
開発組織のフラット化を図るために、階層構造の構成要素を分解してフラットな形に合うように再構成する必要があります。そこでまず必要になるのがマネージャの責務を分解することです。
一般的なマネージャはプロジェクトマネジメントなどのワーク（業務）マネジメント、及び 1on1 などを通してそれぞれの部下の目標管理やキャリアパスのすり合わせ、人間関係の課題解決などのピープル（組織）マネジメントを担っています。
つまり2種類のマネジメントを担当していることになりますが、これを分解して上下関係を廃し、対等な関係の上で再構成可能と考えます。
そうすると、例えばワークマネジメントはプロジェクトマネージャやスクラムマスターなど既知のロールが担えそうですが、ピープルマネジメントにおいてはそれのみを担うロールというものが思い浮かびません。
そこで私達は、エンハンサーという新しいロールをつくることにしました。
エンハンサーとは
エンハンサーの責務はチームとメンバーの力をエンハンス（増幅）することです。もう少し詳しくミッションを挙げると、
・チームとしての意思決定の土台をつくる
・メンバーの成長、及び成果を最大化する
・メンバーの抱える人間関係や業務上の懸念や課題の解決に取り組む
となります。
ワークマネジメントとピープルマネジメントを分離することによって、個人が持つ権限を限定することができます。これによって生じるメリットに、
・ピープルマネジメント担当者とメンバーの業務上の関係が間接的であるため、懸念や課題の共有がしやすくなる
・ワークマネジメントにおいて人事評価はスコープ外であるため、評価を気にして上司の顔色を伺いながら不健全な仕事をする、ということがなくなる（とはいえエンジニアという人種はそういうのに無頓着だったりしますが…笑）
などがあります。一方でデメリットもあります。
・ワークマネジメント担当者と対等であるがゆえ、意見の衝突などにより意思決定や行動に遅れが生じるリスクがある
・メンバーの業務と目標を一体的に管理した上で成長を促す手法がとれない（成長がある程度メンバー自身のコンピテンシーに委ねられるため、人を選ぶ）
また、エンハンサーは一人ではなくチームで運用しています。これは特定の人物に権限が偏らないようにするためであるのと同時に、一人より複数人で議論しながら意思決定していった方が誤りが少ないと考えているためです。
人間一人の判断は容易に誤りうるものと前提を置くと、階層構造のデメリットとして、マネージャの冗長化が十分にできていないことを挙げられると考えています。
以降はミッション毎にどのような施策を実行しているのか、その一部を例を交えつつ説明していきます。
チームとしての意思決定の土台をつくる
マネージャの責務を分解してフラットにするということは、意思決定は特定の人物のみが行うのではなく、メンバー全員がすることとなります。これは単にあらゆることで合意形成が必須となるということではありません。下記の通り、意思決定にはいくつかのパターンがあります。
1, テーマ毎にオーナーがおり、適切なフィードバックを受けた上で最終的な意思決定はオーナーが行う
2, 全体に関わるものはチーム全員で合意形成して意思決定する
1 の例はメンバーからの提案と実行です。例えば監視サービスを導入したいと提案した場合、提案者はそのオーナーとなります。そして提案内容に対するフィードバックを他のメンバーから受けた上で意思決定と実行をします。
フィードバックには意見と懸念がありますが、意見は必ずしも取り入れる必要はなく、取り扱いはオーナーに委ねられます。ただし懸念に関しては必ず明瞭化する義務があります。
明瞭化とはその懸念をどうすれば払拭できるか明らかにすることです。ニュアンスとしてはホラクラシーのそれに似ています。
2 の例はチームにおけるビジョンの策定です。価値観は共有すべきもので特定の人物のものではないため、チームメンバー全員で議論しながら価値観をすり合わせていきます。これはしっかり合意形成するパターンです。
エンハンサーが積極的に関与するのは 2 のパターンで、意思決定プロセスの土台をつくります。例えば私達が開発チームでビジョンを策定したとき、数回アンケートして材料を集めた上でグループワークをして決めたのですが、その進め方を設計して進行をリードしたのがエンハンサーとなります。エンハンサー自身が意思決定するのではなく、その土台を作った上で全員に議論してもらい、全員で意思決定するということになります。
メンバーの成長、及び成果を最大化する
私達は自分自身の成長を促し、成果を最大化するためにフィードバックを活用しています。
階層組織のメリットの一つに上司からのフィードバックがあります。部下からすると耳が痛いことでも上司が指摘してくれるので、それが成長促進と成果向上に寄与します。
しかしフラットな組織では上司が存在しないため、フィードバックは対等な仲間から得ることになりますが、上下関係なしに相手にとって耳が痛いような踏み込んだフィードバックをするのはなかなか難しいものがあります。
それを踏まえ、いかに仲間からのフィードバックを価値あるものにするかを念頭に次のようなフィードバックの仕組みをつくりました（正確には社内にフィードバックシステムをつくるワーキングチームがあり、そのワーキングチームと共同でつくりました）。
1, 最初に全員がそれぞれの課題を挙げ、それを改善するためのアクションと達成条件を定義する
・アクションは可能な限り定期的、定量的、かつ成果が明確（≒プロセス指標）であること
・達成条件は可能な限り定量的（≒結果指標）であること
・自分でコントロールできること（外部要因にブロックされないこと）
2, 業務上近しいメンバーとバディを組む
3, バディは相手の業務を一週間観察しフィードバックする
・業務の中で、改善アクションに対して相手の行動がどうだったか、記憶、記録しておく（ミーティング、顧客との対話、日々の成果物、スケジュール感など）
・改善アクションにフィットしないものでも、指摘する価値があれば OK（改善アクションを設定する目的は指摘しやすくするため）
・相手の良かった点 / 指摘内容 / 相手の良かった点、で1セットとし、上記の記憶、記録からまとめておく（サンドイッチ型）。良かった点で挟むのは厳しい指摘を受け止めやすくするため（厳しい指摘は正論であっても心理的に厳しいことがある）
・客観性を担保するため、指摘内容は OILS モデルに則る
※OILS モデルとは
- Observation (見たことを事実のまま伝える)
- Impact (何が起きたか、どう思ったか伝える)
- Listen (フィードバックをもらう人にその意図を聞く)
- Suggestion (建設的で実行可能なアドバイスを行う)
4, フィードバックをふまえ、改善のための Try/Action を相談しながら決める
5, 3 と 4 を一週間毎に3ヶ月間繰り返す
MBO や OKR に比べると目標のスケールが小さいのですが、その分実現されない絵に描いた餅のような目標にはなりづらいため、フィードバックを通して継続的な成長と短期的な成果の向上が実現しやすくなっています。
メンバーの抱える人間関係や業務上の懸念や課題の解決に取り組む
このミッションを達成するために、エンハンサーは業務上関わることが少ないメンバーと 1on1 をします。対象者を業務上関わることが少ないメンバーとしているのは、関係が間接的であることで客観的に対応することができるようにするためです（さらに言えば第三者の方が課題を正確に分析できるという仮説を実験的に検証している側面もあります）。前述のとおりエンハンサーはチームで運用しているため、エンハンサー一人あたり最大7人までを 1on1 の対象としています。
1on1 では主にダウンサイド（パフォーマンスが低下する要因）に着目して質問します。以下、質問例です。
・人間関係で気になっていることはありますか？どんな些細なことでも大丈夫です。
・誰々のこういう言動、行動が気になる、などありますか？
・もっとこうしたら業務効率があがる、あのやり方は非効率だといった意見はありますか？
・勤怠など働き方で気になっていることはありますか？
・誰々の業務の進め方によって、あなたがやりたいことでできなくなっていることはありますか？
この質問を毎回するのですが、一つ一つを深堀りするように重ねて質問します。例えば、
エンハンサー「人間関係で気になっていることはありますか？」
メンバー「特にないです。」
エンハンサー「本当にないですか？どんな些細なことでも大丈夫です。」
メンバー「う～ん…そういえば…」
といったように、最初は質問しても特に何もないと答えていたのが、二回目の質問で（本当になかったかな？）と考えてくれます。
相手の様子を伺いつつ深堀りしていくのである程度の人間観察力は求められるのですが、質問の内容と方法を定めることで誰であれ一定の回答を引き出すことができます。
この 1on1 を繰り返して気づいたのが、引き出した懸念や課題の大部分が個人的な内容というよりチームとしての課題であることです。その課題をチーム全体で議論するように持っていくのもエンハンサーの責務です（「チームとしての意思決定の土台をつくる」ミッションに通じます）。
最後に
この記事では私達がマネージャの責務をどのように分解し、どのようにチーム運用しているのか、その一部を実例を交えつつ説明しました。
私個人の目標として、いかにスタープレイヤーに依存せず、再現性を持って成長と成果を最大化しつづけるチームをつくれるかを追求しつづけており、仲間達と協力しながらその実装をつくっています。ただし、理想はそういうチームにスタープレイヤーが続々と参加してくれることです（ますます成長が促進されて大きな成果を生めるようになりますからね）。
そんな感じで組織課題に興味のある仲間をいつでも歓迎していますので、気になった方はぜひ採用情報をご覧いただけると嬉しいです！
明日の記事は terunuma による
「Chrome 拡張の Overview of Manifest V3 を翻訳しました」
です！ぜひお読みください！
