これから始めるエンジニアの1on1


1on1はチームの状態変化のタックマンモデルを参考に、やり始めた時期からパフォーマンスを発揮する時期まで1on1の中での関係性や運用も変わると考えました。
今回はこれについて話したいと思います。

単純に言うと画一的に1on1を行うのではなく相手の状態によって長さや頻度を変えましょう。
↑本などではこのレベルの説明なので、もう少し掘り下げた1on1のやりかたの話です。

タックマンモデル

タックマンモデルはチームメンバーが集まったときには、まだチームではなく、ただのグループ(群衆)であると言う風に言われています。

そのメンバーが時間を減るに従って相互理解やルールが作成され、パフォーマンスを発揮すると言うことです。

  • 形成期 (forming)
    • 完成性を築く
  • 混乱期 (storming)
    • 考え方、感情がぶつかり合う
  • 統一期 (norming)
    • 共通の規範、役割分担が形成
  • 機能期 (performing)
    • チームが機能し、成果を出す

上の4つのフェーズを経て、最後にはチームの役割が終わったときには解散期が訪れます。

1on1とタックマンモデル

2人の人の価値観が存在し、そこにそれぞれが持つ情報(価値観)が存在すれば、タックマンモデルは適応されると考えました。
その流れで、それぞれの期間について1on1で行う観点を書いてみました。

形成期

まだ出会って間もない2人はどんな人間か理解し合っていません。
1on1メンバーは今まで言えなかった上手く行っていないと感じたこと、不安に思っていること、知りたいと思っていた情報などが沢山頭の中に存在します。
1on1を担当する自分は、まずはそれらをすべて引き出して理解する必要があります。
引き出す会話をしつつ、その場で答えられなかったことは後日、会社の情報を調べたり、関係各所の関係者に話を聞いたりして自分の結論として話せる状態になって次の1on1に望みます。

今まで話せなかったことが大量に頭の中に存在するため、時間は長く、フィードバックの感覚も短くするため頻度高く1on1を行います。
私の場合は週に1回、1時間を設定します。
初回の1時間が足りないと感じたときには1週間に2回行ったりします。

この時期に必要なこと

◯ 観る力

見るのではなく観る

見える部分としては

  • 損得
  • 思考
  • 判断

見えにくい部分

  • 好き嫌い
  • 感情
  • 関係
  • 価値
  • 自尊心

特に見えにくい部分の理解が必要です。
プロジェクトマネジメントだけの観点で言えば見える部分だけで1on1が出来ますが、見えるを進めてしまうと、どこかで価値観のズレが発覚します。
中長期にピープルマネジメントの観点で活躍や成長を考慮するのであれば、見えにくい部分の理解が重要です。

心理的安全性を育てていく

自分から開示する。1on1をするマネージャであっても全てが出来る人間ではない。
ジョハリの窓。人に指摘されることで見つけられる可能性があることを示します。
1on1するメリットを感じてもらうことが重要。 1on1が楽しみになるように。

混乱期

相手のやりたいことと会社のやりたいことをすり合わせていく必要があります。
目標定義の仕方によってやりがいや発揮するパフォーマンスは劇的に変わると思います。
会社都合でやらなければならないことも多くあるため、1on1をする自分はそれを実行する価値を十分に理解して、ストーリーとして話せる必要があります。

会社の決定を伝えるだけではなく、なぜその決定に至ったのか、この開発を進めることで何が生まれるかを理解して1on1の相手に伝えられるようになりましょう。

情報収集

相手のやりたいことを聞き出す。
場合によっては人生そのもの価値観になりうる。
前提として心理的安全性が必要。
コーチングによる質問の仕方。

情報入力

技術のトレンド、それぞれの技術の強みの定義
会社の現状、経営、決算、強み、エンジニア組織について、採用技術、プロジェクトの方向性
経営的視点やプロダクトマネジメントに近い視点

目標定義

MBO、OKR
会社のやりたいことと相手のやりたいことの方向性を合わせる & 会社の期待値と個人のゴールを合わせる => 目標

  1. そもそも方向が期待とズレていたら意味がない。成長やパフォーマンスを出す方向性を合わせる

  2. どのくらいのパフォーマンスが出せればいいかを合意する。成長は無限に指標がある1000を期待していたが100しか結果が出なければ、方向が一緒でも低評価になってしまうが、本人は100でも結果を出した!と思ってしまう。

上手くいかないOKRの運用ではKRを計測不能な指標にしてしまうことがある。
Done or Progress (パーセント表記) 出来るような、計測方法についても合意をすること。

統一期

目標が合意できたならば、その目標に向かって実行が出来ているか、パフォーマンスが発揮できているかを会話していきます。
ここまでのフェーズになれば、1on1の時間は週に30分でも大丈夫だと思います。

このフェーズになっても日々の不安に思ったことはいつも聞きましょう。
そのための情報収集の行動は怠りません。

計測実行

1on1は週1や隔週などの定期で行われるので、OKRの進捗を確認しましょう。
実業務のプロジェクトマネジメントの観点のOKR目標の進捗は、通常の全体のスケジュール確認や朝会で行えばよいので、個人にフォーカスした成長やパフォーマンスについての進捗を考えましょう。

さらなる成長

情報収集は今までは自分が行っていましたが、情報収集を出来る方法そのものを伝えていって良いフェーズだと思います。
最初にやるには自分のやりたい作業や不安もあり行動できないこともありますが、心理的安全性が確立して、自分も成長のゴールが見えている段階であれば、それは自分自身が解決したいものなので、それ自体の行動を促しても実行しやすい状態にあります。

そうやって、さまざまな行動例を示したり、観点を広げてもらいながら自走できるように成長してもらいましょう!

機能期

目指すべき目標も見え、自主的に行動できる力もついてきたならば、1on1の役割も半分終わりました。
自分で成長する方法を考え実行する出来る状態に近づきます。

独り立ち

機能期を過ぎたメンバーは自立した行動が取れるようになります。
必要があればメンバーを巻き込み、技術のキャッチアップの仕方を覚え、成長の観点で自分自身で考えられるようになります。
このようになったならば、問題が発生したときに自らが求めて1on1を設定でき、課題を持ってきて話が出来るようになります。

そうした場合には1on1の頻度を減らしたり時間を減らすことが出来ます。
私のケースでは隔週の15分程度まで短く出来ると考えています。

インシデントが起きたときだけ不定期で30-60分などの1on1をします。

失敗1on1

形だけの1on1になっているケースも多くあるのでは?と感じているので書いてみます。

雑談だけで終わってしまう

困ったことや不安を取り除いたり、心理的安全性を高めるためには雑談は効果があります。
しかし、本当の目的は成長を促しと自立性を向上させることでパフォーマンスを最大に発揮してもらうことです。
メンバーと会社の相互理解を深め、認識が合致できるようなアプローチが必要です。

見える部分だけで1on1してしまう

プロジェクトマネジメントの観点では上手く行っているように見えます。
しかし本人のやりたいことや価値観と合致出来ていない場合には心理的安全性は実は下がっていて、本音を言えない状態になってしまいます。
やりがいを失ったエンジニアはいつか会社を辞めてしまいます。
プロジェクトマネジメントの観点だけでなく、ピープルマネジメントの観点で本人の価値観を大事にしたアドバイスが出来る必要があります。

インシデントフォローしない人

困ったこと、不安に思っていることはいつでも発生します。

チームの状態に関係なく突発的に起きる問題です。チームの問題ならばチームで解決すれば良いですが、チームの中で心理的安全性が担保できない場合、1on1で聞く必要があります。
そのときチームの心理的安全性より1on1をする自分の心理的安全性が高くないと結局は話をしてくれないので、しっかり関係性を作ることが必要です。

定期的な1on1は完全にやめてはいけません。困ったことを話す場がなくなってしまうかの性があります。
また、大きな問題が発生したことが分かったときには定期的な1on1を待たずにすぐに1on1を設定しましょう。

立てた目標が計測不能

OKRで
XXXプロジェクトを成功させる!
XXXを頑張る!
XXXの勉強をする!
のようなKRを立てると、成功した!頑張った!勉強した!って言ってしまえばなんとでもなります。

目標として正しい状態になるは計測可能にする必要があります。以下は例です。
成功の定義をしっかりする。 => XXXXリリースを行う。 売上XXX円を達成する。
頑張る定義をしっかりする。 => XXXプロジェクトのXXXの分野でXXXとXXXを行う
勉強する定義をしっかりする。 => XXXの技術を本をX冊読んで、知識としてまとめたものをXXX勉強会で発表する

数値や達成した状態を合わせることで期待値と目標のズレをなくし、結果の評価を行うことが出来ます。

おわりに

1on1は定型的なものではありません。
あらゆるスキルが組み合わされた非常に難しい高度なミーティングです。
いくつもの技術が必要です。

ロジカルシンキング
コーチング
ファシリテーション
フィードバック
情報収集力
巻き込み力
エンジニアリング技術力
開発プロセス知識
仮説ドリブン
会話力、伝え方

しかし、最初から全てを上手く出来るわけがありません。
1on1の相手と共に自分も成長します。

ジョハリの窓の自分の開示の部分でも書きましたが、マネージャでも完璧ではないです。
完璧ではないけれど、自分は本気でマネジメントを勉強しているから、一緒に成長しよう!と話をすれば良いと思います。

1on1を使って、仕事が楽しく出来るようになり、最大のスピードで成長しながら、最大のスピードで成果を出せるようになれたらいいな!