インフラエンジニアはエンジニアリングマネージャーの夢を見るか あるいは とある組織における1on1試行錯誤の過程 2

ntk1000
ntk1000
Dec 18, 2018 · 8 min read

浅野です。

前回の記事ではエンジニアとの1on1導入までの話を書きました。今回はSL2というリーダーシップの方法論を取り入れた現在の1on1運用について紹介したいと思います。

半年ほど運用を回す中で、傾聴を通じて誰かしらの問題解決に至ったり、自身がハブになることでチーム間の連携を進めることができたり、それなりにやりがいを感じていました。

そこでもう少し踏み込んで、メンバーの成長に繋がるような支援を行っていきたいと考えるようになりました。ただ、具体的にどのような支援をすればよいのか、コーチングの書籍なども読んで自分なりに試してみるもののなかなかしっくりこない…そこで自分のやり方を見直すきっかけになったのがSL2でした。

SL2とは

シチュエーショナル・リーダーシップ(situational leadership)理論に基づくリーダーシップ理論の一つで、blanchard社にて研修プログラムが提供されています。

via https://www.kenblanchard.com/KBCPublic/media/Content/Products/sl2-situational-leadership-model-diagram.png

有料の研修なのでおそるおそる概要だけざっくり説明すると…

メンティーの仕事それぞれに対してスキルや意欲の観点から開発レベルを判定し、そのレベルに合わせてリーダーシップのスタイルを指示と支援それぞれの観点で調整しながら対応するというものです。

すごく雑な例をあげると…
・社会人1年目の新人はやる気はあるがスキルがないのでレベル1(指示多め、支援少なめ)
・少し経験積んで壁にぶち当たってやる気をなくしている場合はレベル2(指示、支援多め)
・スキルはあるが自信が持てず意欲が低下している場合はレベル3(指示少なめ、支援多め)
・スキル・意欲共に高い場合はレベル4(指示、支援少なめ)
といった感じです。

状況に応じてリーダーシップのスタイルを変えるというのは elastic leadership本 を読んだこともあり、それなりに使い分けているつもりでした。また、自分の傾向として指示よりも支援によりがちであることも自覚していました。メンバーが全員中途採用のエンジニアなので、そこまで厚く指示する必要もないだろう、自主性に委ねようと判断していたからです。私のリーダーシップスタイルはレベル3が多いという状態でした。

会社が主催するマネジメント研修でこのSL2研修を受講する機会があったため、elastic leadershipとの違いも知りたいと思って参加してみたのです。

人ではなく人とタスクの掛け算で見る

研修では色々な事例を元に開発レベルを判定するというゲームをグループワークとして行いました。これが結構な頻度でレベル判定を誤り、わりと判断が難しいケースがあることに気付かされます。例えばレベル2と3の違いとか…

一つ陥りがちだったのは、対象者の経歴から暗黙的にレベルを判定していたことです。例えばこれまで輝かしい実績を積み重ねてきたプレイヤーであれば、自動的にスキルは高いのでレベルは3か4になるのではないか、といったバイアス。

そうではなく、その人とタスクを組み合わせて判断することが必要なのです。先述の例でいえば、優秀なプレイヤーだが抱えているタスクは初めてのマネジメントかもしれない。その場合、対象者のマネジメントスキルは?マネジメントへの意欲は?

一歩引いてみれば当たり前の観点なのですが、意外と意識的に取り組まないと、その対象者の経歴とか印象とかで判断してしまっていることがありました。

SL2を1on1に組み込んでみる

せっかくなのでこのSL2を1on1に組み込んでみようと思ったのです。

どうやるか悩んだのですが、自分だけで判定するのは先の研修でさんざんレベル判定を誤ってすっかり自信をなくしていたので、そこは自分を信用せず、メンティに簡単なアンケートに回答してもらい、その傾向をお互い確認しながらその場で判定することにしました。

こんな感じのformを作って回答してもらい…

回答に対応するレベルを元にspreadsheet上でスコアを出す…

対応するタスク・目標に関して、スキルとモチベーションの観点で当てはまるものにチェックを入れてもらって、対応するレベルのスコアを出すだけの簡易なものです。粒度も荒いので厳密ではありません。実際のところスコアの結果を見ると、スキルとモチベーションのレベルが合わなかったり、複数レベルに満遍なくスコアがついたりというケースがありました。

大事なのはメンティがどのように捉えているかをメンターが知り、それを元にメンターがどのように判断するのかをメンティが理解し、お互いある程度の納得感をもった上でメンティの状態(レベル)を認識することなのかなと考えました。なので、このアンケートの回答とスコアの結果表示とレベル判定も1on1の場でお互いに話しながら進めました。

1on1すること自体が目的ではない

私は期初にあらかじめ隔週で1on1の予定を入れてしまっています。勿論その予定が絶対ではなく、業務やメンバーの状況に応じてしょっちゅう変更していますし、要望があれば突発的に1on1を行ったりもします。メンバーと話をする時間を確保する、話し合える関係性を築くためにはある程度こちらから能動的に動く必要があると考えています。

目的はメンバーと話ができる関係性を築く、話しやすい組織・心理的安全性が高い組織づくりであり、その先にあるのはメンバーの価値を最大化することだと思っています。

1on1は一つの手段に過ぎないので、また半年後・1年後はどのような形になっているかはわかりませんが、対話自体はシンプルながら奥深いツールなので引き続きブラッシュアップしていきたいところです。

オマケ1: ツールの変遷

記録と事前の議題収集という目的ながらツールをころころ変えています…

  1. wiki(confluence)
    記憶力が弱いので記録しないと忘れてしまうと思い、メンバー毎のページを作って日記のようにひたすらメモ
  2. google form + spreadsheet
    あらかじめ話したい議題を書いてもらったほうがよいかもと思い、form経由で書いてもらって、spreadsheetにログを残す
  3. github + markdown ← イマココ
    spreadsheetの可読性が悪い(のとspreadsheetばかり触っていると気が滅入る…)ので private レポジトリをメンバー毎に作ってmarkdownで管理

オマケ2: 参考書籍

seedscompany

seeds company's blog unofficial

ntk1000

Written by

ntk1000

nougatokeru

seedscompany

seeds company's blog unofficial