10人規模のチームを自律自走させ、成長組織へ変革するため実践していること

はじめに

チーム全体の管理をするようになって1年程度が経過しました。今回記事を作成した目的は以下になります。

• これまでチームで実践してきたことを整理し、今後の活動に向けた振り返りとする
• 同じような環境やこれからマネジメントを行う人の一助になれば

かなり記事のボリュームが大きくなってしまいました…🙇　自分が実践してきたことや考えていることを振り返るのが主目的なので大目に見てもらえるとありがたいです。興味がある章や節だけでも、かいつまんで読んでいただければ幸いです。

前提

元々メンバー間の横のつながりは強いチームでしたが、上長や部長、その他ステークホルダーを巻き込んだ情報共有に弱みを感じていました。
私自身、チーム管理を引き継ぐ前はチーム内の1プロジェクト(3,4人規模)の開発と管理を担当しており、上記情報共有に頭を悩ませていました。

チームの開発スタイルについても少し補足します。
私達は社内業務を効率化する自動化プロダクトを内製開発しています。開発にはスクラムを採用しており、タスク管理にJira、コード管理にGitHub、コミュニケーションツールとしてTeamsを使用しています。

課題とありたい姿

前任からチーム管理を引き継いだ時点でチームは危機的状況に入り込みつつありました。エンゲージメントは低下し、中長期の目標も見えず、今期の目標も自分事として捉えられていないメンバーが散見されました。このまま状況を放置していると悪化するだけです。自律自走できるチームとなるため、チームの土台を見直し改善する必要がありました。メンバーにヒアリングをする中で以下課題点が見えてきました。

• 情報の透明性が失われ、メンバーごとに持つ認識に差があり情報の非対称性が広がっている
• 部長や経営陣に対するコミュニケーションロスや不信感が重なり、中長期の目標が見えない
• 短期的な目標の妥当性がわからない
• 個人評価の基準がわからず、チームにおけるキャリアパスもはっきりしない

ここから私がありたい姿として設定した状態は以下になります。

• 情報の透明性が回復し、メンバー間の認識が統一されている
• チームのビジョンとミッションが明確である
• 単年と中長期、どちらの目標も具体的かつ現実的である
• エンジニア評価の基準と制度が明確かつ、具体的なキャリアパスもイメージできる

ありたい姿に近づけば近づくほど、各メンバーが自律自走し、自ら成長していく土台が整ったチームだと考えています。

それでは、ありたい姿を目指して実践していることを以下の章で説明していきます。

チームの土台を改善するために

情報の透明性を回復する

まずは失われた情報の透明性を回復させることからです。

部長を含めた全メンバーを意思決定へ巻き込む

チームに関わる意思決定の場には部長を含めた全員が参加する形を取りました。また、プロジェクトごとのMTGにもプロジェクトに関わる全員(3,4人)が参加するようにしました。
最大人数によるMTG開催は当然ながら従来のMTGよりもコストが増大ます。しかしながら、コスト増大のデメリットよりも、「伝言ゲームによる情報の欠落」と「意思決定に参画できないことが及ぼすエンゲージメント低下」によるデメリットを重く評価しました。当時のチーム状態を考慮しての判断でした。

デメリットの評価

「伝言ゲームによる情報の欠落」+「エンゲージメント低下」 > 「最大人数参加によるコスト増加」

全員参加を実施することでお互いに生の声を伝え、聞くことができ、相互理解と相互認識が深まりました。

振り返ると、10人規模のチームだからぎりぎり行えたこととも思えます。最近は情報の透明性も維持できており、組織の拡大も計画しているため、全員参加にこだわることは減っています。情報の欠落を防ぎ、関係するメンバーが自分事として捉えられる働きかけが重要だと考えています。

情報の表出化を徹底する

せっかく透明性が増した情報も時間がたつと埋もれてしまい、新たな非対称性を生み出す原因になります。誰でも後から簡単にアクセスできるよう、情報は整理(表出化)しておく必要があります。
例えば、対面で行われた話し合いやMTGで挙がった情報は関連するissueや社内Wikiにテキストベースで整理します。TeamsやSlackといったチャットツールのやり取りも情報が流れやすいため、同様にissueや社内Wikiに転記しました。issueや社内Wikiは情報の階層化が容易で、かつ検索機能も強力なため情報の格納先として採用しています。

情報整理は透明性を担保するだけでなく、チーム内で新たな知見を生み出すきっかけになるため重要です。(興味がある方は「SECIモデル」で検索してみてください)

心理的安全性を維持する

チームの心理的安全性が高くないとメンバー間で建設的な議論を行うことが難しくなります。MTGに参加する人数を増やしても効果的な議論が行えないチーム状態だともったいないです。従来から行っていたことを含め、心理的安全性を高め、維持する取り組みを紹介します。

GKPTで賞賛文化と組織改善文化を醸成する

スプリントや各種イベントを振り返る際のフレームワークとしてGKPTを採用しています。GKPTはKPTという振り返りフレームワークにG(Good)を追加したものになります。お互いにGoodを挙げることでメンバー間の賞賛文化が少しずつ醸成します。
振り返りMTGの際にはスプリント中にあったGoodとProblemを各自に発表してもらっています。その後は深堀りしたいProblemや既存のTryの実践状況について話し合い、TryとKeepを整理します。継続的にProblemとTryの話し合い続け、成果を積み上げることでチーム内に組織を改善しようという力学が生まれます。
例えば、以下のようなボードを用意すると進行や管理がスムーズになります。実際にチームではOffice365のPlannerをボード表示にして活用しています。

例: ハイブリッドワークを検証した際のGKPTです。検証時に導入したoViceに対するFBもありました。
(業務関連の情報は黒塗りにしています)

オンボーディングを活用する

新しいメンバーがチームに馴染み、心理的安全性を高めるためにオンボーディングを活用します。チームでは開発文化に馴染むためのコーディング研修期間を必ず設けていますが、期間中にチーム文化へ馴染んでもらうため以下取り組みも行っています。

• 社内Wikiや社内勉強会資料に目を通してもらう
  社内Wikiや社内勉強会資料の中に、チーム文化や「心理的安全性」「SECIモデル」についての内容があるので目を通してもらっています。
• チーム開発に関連するワード検索や書籍の一読
  『Team Geek』を一読してもらうのが一番なのですが、他の開発系書籍も読んでもらうため、状況に応じて「心理的安全性」「HRT(謙虚・尊敬・信頼)」といったワードを調べて理解を深めてもらっています。
• ドラッカー風エクササイズの実践
  既存メンバーのドラッカー風エクササイズに目を通してもらっています。ある程度、新規メンバーが増えた際にはMTGも実施し内容を更新しています。ドラッカー風エクササイズのテンプレートとして以下を使用しています。

テンプレート

テンプレート.md

## ドラッカー風エクササイズ
名前：　  
入社時期：　2000-00-00  
作成日：　2022-01-XX  

### ■Positive Side
1. 自分の強み(得意なこと)  
   .....
2. 自分はどういう風に仕事をするか  
   .....
3. 業務上大切にしていること  
   .....
4. チームから期待されていること  
   .....

### ■このスキル・分野については聞いてもらって大丈夫(人に説明できる)
例) Python, Linux, ...  
....

### ■Negative Side ※実務配属後2ヶ月以上のメンバーが対象
**これまでの社会人生活を思い起こし実際にあったエピソードありきで以下へ回答してください。**
1. 自分は何が不得意なのか  
   ......
2. どういう風に仕事をしてしまうか  
   ......
3. 自分の地雷(腹が立つこと)は何か  
   ......
4. チームメンバーの期待に応えられなかったこと  
   ......

1on1を活用する

相互理解を目的に、メンバー同士の1on1、上長との1on1をそれぞれ行っています。

• メンバー同士の1on1
  メンバー同士の1on1には『donut』の『virtual-coffee』を活用しています。定期的にSlack上で任意のペアを組んでくれるため、そのペアで1on1を行うかランチに行くかという運用をしています。内容に上長は一切関与せず、実施完了の報告だけを受けるようにしています。

https://www.donut.com/

• 上長との1on1
  定期的に上長との1on1も実施しています。お互いに慣れるまではどうしても上下の力学が発生してしまうため、以下をアジェンダとして事前に共有しています。

• 目的は皆さんの気分転換とお互いの情報共有です
• 業務の話でもプライベートの話でもOK
• 自分で話すでも話を聞くでもどちらでもOK
• 上長だからとかしこまる必要はないですし、逆に上長だからお願いできることを話しても良いです

それでも話題が出ないこともあると思っているので、自分なりに聞きたい話題をいくつか用意して臨んでいます。

ビジョンとミッションを共有する

私達は「何を行うチームなのか」「どこへ向かっているのか」というチームの存在意義については事あるごとに共有します。チームで議論を行う際や方針を決める際の基準点になるためです。ここの共有が不足していると、チームが迷走しかねません。

定期的な振り返りMTGと方針決定MTGを開催する

日々の業務はスプリントに従って取り組んでいますが、より大きなタイムスパンで(月単位やクオーター単位など)定期的な振り返りを行っています。これまでの足跡を少し俯瞰的に振り返ることで、チームの軌道修正と方針共有を行う目的があります。

平時の取り組みで気をつけていること

チームの土台が改善されつつあっても、平時の取り組みに気をつけないと状況はなかなか好転しません。自律自走できるチームを維持するために意識していることを以下で説明します。
また、この章の考え方はメンバー全員に知っていてほしいことになります。

業務を委任する

メンバーの志向やポジションに応じて業務を任せることが、そのメンバーの成長につながります。私自身は以下2点を例外として、それ以外の業務は任せられないかを普段考慮しています。

• チームに発生するイレギュラーな業務
  メンバーの成長に寄与しないものや、普段の業務を邪魔するイレギュラーな業務は巻き取るのが良いです。
• 自身の成長に必要な業務
  自身の成長についても考慮する必要があります。私の場合、部長が行う業務の一部を委任してもらえるよう働きかけるということになります。

各メンバーの成長がひいてはチームの成長につながります。

マイクロマネジメントを減らす

メンバーへ任せた業務に対して、細かく指示したり、ヒアリングすることはやめます。自律につながらないのと、マネージャーの時間が足りなくなるのが理由です。代わりに「マイルストーンの把握」と「報告の機会設定」を行います。

マイルストーンを把握する

マイクロマネジメントを減らすためには、業務ごとに適切な中間ポイント(マイルストーン)を設定することです。方向性の修正が困難になる分水嶺ごとに設定するのが適切だと考えています。(なお、単純な業務では設定不要です。結果を報告してもらえば十分なため)
マイルストーンを設定してから業務を依頼するでも、依頼してからマイルストーンを設定してもらうのでも方法は問いません。マイルストーンに対するアクションが不透明な場合、メンバーへ状況をヒアリングするようにします。

報告の機会を設ける

チームに存在する全ての業務に対して、何かしらの報告する機会を設定します。定期的に開催しているものでは、デイリースクラムとスプリントごとの振り返りMTGが該当します。緊急性の高いものは、Teamsにて一報を挙げてもらっています。報告機会を習慣化することで、担当業務の自己管理能力と説明能力が向上します。報告の中で不明点や疑問点があれば、チーム全体で積極的に意見を交換してください。(マイクロマネジメントに陥らないよう注意は必要です)
また、マネージャー自身の業務もチームへの報告を忘れないようにします。チーム内に特権階級を作りたくないのが理由です。

ただし、メンバーにとって難易度が高い業務や初めて取り組む業務の場合は例外もありえます。状況を細かくヒアリングしたり状況に応じて伴走したりします。(コーディングにおけるペアプロのようなものです)

エンジニアの評価をクリアにするために

これまで挙げてきた改善や取り組みにはチームメンバー全員の協力と参画が不可欠です。メンバー各々がエンゲージメントを高め、これらへ参画するためにもクリアな評価を行うことは避けて通れません。(ここで「クリア」とはエンジニア(評価される側)とマネージャー(評価する側)双方が納得できるという意味で使用しています)
エンジニアの評価は難しい部分もあるのですが、私なりの考えと実践していることをまとめます。

問題は何か

何も制度を整えず、マネージャーが漠然と各メンバーを評価する場合、以下のような問題が考えられます。

評価される側の目線

• 行ってきたことが評価されない
• 何をどれくらい頑張れば良いのかはっきりしない

評価する側の目線

• 個人の成果が見えづらい
• 業務の難易度と個人の能力との相対関係がわかりづらい
• 給与テーブルをどう設定するか
  (給与テーブルの話は今回の記事では触れない話になります)

お互いに納得するためには、一方的な評価が行われる状況を避ける必要があります。そのためには評価されるエンジニア自身が目標を設定するべきです。ただし、目標設定に際して条件が何もなければ、評価する側のマネージャーが納得できる目標からは離れてしまう可能性があります。従って、双方が納得可能な目標設定条件に辿り着くことが重要になります。

私達の場合、チームで評価される指標と業務の難易度、キャリアパスを整理することで目標設定条件の土台としています。

施行した制度

採用のインタビュー記事で回答した制度を施行しているのですが、ここではその内容を補足します。なお、この制度が完璧だと言うつもりはなく、継続的に改善していく必要があると考えています。何も制度がないよりは遥かに良いと思い、チーム内での議論を重ねた結果、本制度を施行しています。
https://pr.forkwell.com/articles/fierte/#toc-6

1. 評価モデルを定義

チームで評価される人材を考察することで評価指標を抽出しました。私達の場合、「技術力」「ドメイン理解(会計領域の知見)」「管理能力」という3つの評価軸が定義できました。

• 技術力
  エンジニアとして絶対的に必要な土台です。課題に対する"How(どうやって)"を解決する能力です。
• ドメイン理解
  私達は社内プロダクトの開発をしています。社内スタッフの業務内容を理解していないと、業務内容の改善提案や新規プロダクトの企画ができません。課題に対する"What(何を)"や"Why(なぜ)"を解決する能力です。
• 管理能力
  管理能力にはチーム管理やプロダクト管理だけでなく、自己管理や採用、教育も含めています。チームとして開発する以上、チーム状況の把握と自律自走するためのポータブルスキルが個人単位で必要となります。課題に対する"When(いつ)"や"Where(どこで)"、"Who(誰が)"を解決する能力です。

なお、3つの軸は独立したものではなく、お互いに影響を与える複合領域(業務)が存在するとしています。

2. キャリアパスを定義

評価モデルに対して、能力に応じたポジションをいくつか定義しました。「リードエンジニア」→「シニアエンジニア」→「プロダクトマネージャー」→「製品部長」など代表的なキャリアパスを可視化し、各ポジションの評価モデル上の能力値や要件も明記しました。

説明用に簡略化した図です。実運用ではより多くのポジションについて要件と能力値を明記しています。

3. 各メンバー個人の目標を設定

チームの全体目標と評価モデルに沿って、個人ごとの目標を目標管理シートに設定してもらいます。(前提として、チームの全体目標を事前にきめています)　目標設定時の指針は以下になります。

• 半期で3～5個の目標を設定する。評価モデルの3軸から2つ以上の観点を目標に採用する。
• 目標はチームや会社のビジョン・方針に沿ったものとする。
• 定性的な目標があっても良いが定性的なものしかない場合は評価が困難なため，定量的な目標がメインとしてある事が望ましい。
• 目標の難易度は設定時点で見通しができる(達成できそうな)レベル感でOK。
• 過程を振り返れるよう、目標のマイルストーンや難易度も記載しておく。

作成した個人目標は必ず上長と話し合い、お互いに合意を取る運用としています。

4. 定期的な目標フォローMTGを実施

設定した目標は定期的に上長と振り返りを行い、達成状況や過程を目標管理シートに記録します。また、状況や環境の変化に応じた目標の見直しもこのタイミングで行います。

5. 評価を決定

半期ごとに目標管理シートを踏まえて評価を決定します。そして、次半期の目標設定を行い上記を繰り返します。

付録

組織を拡大するために

今後の課題のひとつとして、チーム(組織)の拡大を掲げています。今回の話からは少し離れるため、付録としてどういった取り組みをしていきたいか簡潔に記載したいと思います。

採用を強化する

まずは採用強化です。メンバーを増やさないことには組織は拡大しません。私達が行っている業務やビジョンとミッション、組織の文化を正しく伝えることが当然大切になります。それ以外にも採用の土台強化として以下を意識して向上させたいと考えています。

• EVP
  EVPは「Employee Value Proposition」の略で企業が従業員に提供できる価値を指しています。単純な報酬や福利厚生だけでなく、その企業で何ができるか、どういった成長ができるか、どういった環境や文化の下で働くことができるか整理し、組織としての魅力を向上させていく必要があります。
• 知名度
  多くのエンジニア(開発者)に会社を知ってもらい、知名度やつながりを強くする必要があります。エンジニア採用はこちらが「選ぶ」のではなく「選んでいただく」という考え方が重要だと考えています。(DevRelの強化とも言えるのですが、私達は開発者向けのサービスを現状提供できているわけではないため「知名度」としています)
  この記事もその一環です。個人単位、チーム単位で外部へ発信する機会は増やせればと思います。

定着率を向上させる

メンバーの定着率を上げないと採用を強化しても組織は思ったようには拡大しません。また、経験を積んだメンバーが定着しない状況は組織の成長にも悪影響を与えます。採用強化でも挙げたEVPですが、既存メンバーに対するEVPも合わせて改善していく必要があります。そのためには現状に満足することなく、継続的な組織改善や制度の見直しに組織として取り組むことが重要です。

人材配置を再構成する

正直なところ、コミュニケーションパスの増大などを考えると10名程度が1チームの上限に近いと感じています。(むしろ、すでに多い気もしています…)　今後人数を増やしていくためには、チームの分割といった新たな組織構成を運用していく必要があります。組織全体と各チームごとのビジョンとミッションの定義、チーム内・外それぞれの情報経路や制度の定義など、検討すべき事項が眼前に広がっている状態です。

参考になった書籍

• エンジニアリング組織論への招待
• Team Geek
• チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
• エンジニアのためのマネジメントキャリアパス
• エラスティックリーダーシップ