コミュ障が1on1をやり始めたので参考になりそうなことを書いておく

この記事は、Feedforce Advent Calendar 2018 24 日目の投稿になる。前日は弊社フォントマニア、mashabow 氏による「typeの話」だった。

今年中盤からバックエンドエンジニアの 1on1 を始めることになった。一般的なベストプラクティスはすでにいろいろなところで書かれていると思うので、Feedforce Advent Calendar 2018 24 日目の記事として 1on1 をやる上での自分なりにどうしているかなどを書き散らしてみたい。

そもそも

そもそも、自分は元々 1on1 とか MTG が苦手だった。より具体的に書くと、

他人の話を聞けない。人の話を聞いていると自分の話をぶっ込みたくなる。
人の話を大体は批判的に聞いている。批判するのは得意だが肯定するのは大の苦手。
他人の成長・悩みに興味がない。「そんなの自分でやること・解決することでしょ?」的発想。
チームマネジメント?　何それ儲かるの?

といった感じだった。

以前は、元 CTO がこのあたりをまるっとやっていてくれていたので、自分はソーシャル PLUS や Feedmatic、さらには弊社喜多が Feedtech 2018 でぽろっと言っていた「ぽしゃった某プラットフォームのダイナミック広告」向けの UI などの新規プロダクトのプロトタイピングといった自分が得意とする分野にフォーカスすることができていた。

だがしかし、昨年 7 月に彼が CTO を降りて以来、

エンジニアは技術チームではなくプロダクトチームに所属
技術チームとしての問題点は週 1 回の合議で決める

ことになった。これはこれでうまく回ってはいるが、一方で

エンジニアが抱える問題を個別に相談する相手がいない。
エンジニアのキャリアパスを相談する相手がいない。

という問題が出てきてしまった。

そこで、対外的には開発本部長という肩書きの自分がその役割を担うことにしたのがこの 1 年で一番大きな仕事上の変化といえる。

1on1 noob struggles to become a professional

事前に

とはいえ、これまでは 1on1 は受ける立場でしかなかったので、特にこれといったベストプラクティスがあるわけではなかった。まず読んだのは、Qiita::Team にあった「1on1ベストプラクティス改」という記事。こちらを元に最低限の知識を摑んでから 1on1 を始める宣言をすることにした。

とはいえ、最低限の知識だけでは厳しい局面も多い。そこで、まずは定番となる本を何冊か読んでみた。

ある程度読んではみたものの、そもそも自分がそれを実践できる気が全くしない。

そこで気がついたのは、最初にも書いたとおり、「そもそも自分は人の話を聞くのが嫌いで、だからこそマネジメント系タスクが苦手だ」ということ。ここで完全に行き詰まってしまった。

コーチングを受けはじめる

ラッキーなことに、昨年1年間集中的に英会話を勉強していたときに知り合った英会話講師とビジネスコーチングを始めたという営業を受けたｗ

いずれグローバルで活躍できる人材になりたいと考え始めていたこと、さらに彼とは何かとウマが合ったこともあり、まずは初歩的なコミュニケーションの手ほどきを受けることにした。

そこで最初に紹介された本が以下になる。

この本を元にディスカッションを進めたが、典型的な「嫌なヤツ」だった自分にとっては基本的なコミュニケーション方法を探る上で非常に役立ったと思う。

ディスカッションは英語だが、自分の英語力がないが故に細かく言い換える必要があり、逆にそれが自分の理解を深める上で非常に役立った。

自分なりの基本原則

これらを踏まえて、自分なりに基本原則を決めた。

非常にプリミティブではあるが、まずは聞くことを徹底する。相手が話すことを考えている間も原則として待つ。
年末年始などの 1 週間以上の長期休暇を除き、絶対にスキップはしない。自分都合、相手都合によらず、予定が合わなかったら必ずリスケする。
規定枠で話しきれなかったらそのまま延長するか、別の枠を取って相手が話しきるまで十分に話を聞く。
WHY は絶対に問いかけない。WHAT か HOW のみにする。
極力否定しない。そこから何ができるかを全力で考える。
何か具体的な懸案事項があれば、解決できるように動く。解決できなくても理由とともに共有する。
絶対にネガティブな雰囲気は出さない。特に、何があっても疲労感は絶対に出さない。

基本原則なだけあって、どれも自分の中では同じくらい重要な項目になる。1 〜 3 は本当に基本で、これが自分のことを「話をするに値する」と思ってもらえるかどうかの最低限のラインだと思っている。

4, 5 も重要で、1on1 は何かを問い詰める場ではなく、一緒にパフォーマンスを最大化するための場である。4, 5 を守らないと単に問い詰める場になってしまい、相手から聞くべきことを聞けなくなってしまう。

6 は意外に忘れがちではあるが、The SPEED of Trust の最初の方にもこう書いてある。

Trust is a function of two things, character and competence. Character includes your integrity, your motive, your intent with people. Competence includes your capabilities, your skills, your results, your track record. And both are vital.

マネジメントをするとなった以上、エンジニアとしてのスキルやこれまでの実績そのものは周りから認められているとは思う。だがしかし、1on1 で出てきた課題や懸案事項に対して具体的に対処できない限り、いずれは 1on1 が形骸化してしまう。その意味で、自分の職域で要求される結果に加えて個別の 1on1 で出てきた課題も対処する必要がある。

とりあえずやってみて

上で決めた基本原則を元に、徐々に 1on1 対象を増やしつつ自分でもうまく回せるかを徐々に確認するようにしてみた。

正直な話、最初は 1. すら守れるか相当怪しかったし、「なぜあんなことを言ったんだろう」と思うことは数え切れないくらいだった。しかし、相手に WHY を投げないと決めた以上、自分でも WHY ではなく WHAT か HOW で考えるようにすると、なんとなく次はこう言えばいいということが浮かぶようになる。

すると不思議なもので、これまではあんなに苦手だった他人の話を聞くこと、否定的に話をしないことが、少なくとも 1on1 ではそこまで気にならなくなってきた。こうなると単細胞なもので、1on1 が楽しくなってきたｗ

キャリアパス

1on1 を始めた時点での問題点としてもう一つあったのが、エンジニアのキャリアパスのサポートをどうするかだった。そのため、ある程度 1on1 に慣れてきた時点で、対象を増やしつつキャリアパス相談も始めることにした。

弊社の場合、「Feedforce Developer Blog – デザイナーのキャリアパスを見直している話」にもあるとおり、職種に限らず等級に応じて満たすべき criteria が細かく決まっている。一定以上の等級まで来ればある程度抽象的に話をしたほうがいいと思うが、最初の方の等級はそもそも相手が慣れていないこともあって何をしていいのかさっぱり分からないことも多い。

さらに、本人の自己評価が実際の貢献や周囲の評価と比べて低い、または高いという期待のミスマッチも多く、色々と納得感に欠けるという問題があった。

キャリアパス計画

そこで、要求項目ごとにセルに落とし込んだキャリアパス相談用のスプレッドシートを作った。

その上で、本人に加えてマネージャやリーダー、メンター (以下、周囲) にそれぞれできている項目とできていない項目のセルを塗り分けてもらう。

これを見比べつつ、

本人と周囲がともにできていると思っていること。
本人はできていると思っているが、周囲はそうは思っていないこと。(自己評価が高過ぎるケース)
本人はできていないと思っているが、周囲はそうは思っていないこと。(自己評価が低すぎるケース)
本人と周囲がともにできていないと思っていること。

項目を色分けし、周囲のコメントを追加したシートを作る。(カラーリングは状況に応じてそれぞれ微妙に変えている)

マネージャコメントは原則としてすべてフィードバックはするが、上の原則に従い、肯定的なものにそろえることにした。例えば、上のスプレッドシートの場合、本来のフィードバックが「問題が発生したときの共有が遅い」であったとしても上のように書き換える。

1on1で現状をトラッキングする

これで期待のミスマッチが可視化されるので、まずはこれを元に 1on1 で各項目をレビューする。場合によっては改善点が 10 個以上あったりすることもあるが、何度かレビューをすることで改善点は 2 〜 3 個に絞り込めるので、この時点では焦る必要もないし、その旨はちゃんと伝えておく。

このシートを元に、隔週で改善が必要な各項目につき

そのイテレーションでの進捗、気づき
次のイテレーションでどう進めるか

を話すようにした。3 〜 4 イテレーション進めればそれぞれがより具体化していき、改善点がクリアになってくる。弊社の場合は KPT が広く使われているが、個別の項目を正確にトラッキングしづらいのでスプレッドシートでこのように管理するようにした。

まだ始めて数ヶ月なのでここまで来たところだが、いずれ近いうちに次のステップに進められるという手応えを感じてきた。

おわりに

キャリアパスの話まで含めるとまだまだ本格的に始めて半年前後しか経っていないので、思い当たる改善点は多々ある。さらに、プロダクト軸ではなくエンジニアという職種軸でのみ見ていることもあり、KPI を意識しなくてもいいが故の気楽さというものはあると思う。

とはいえ、自画自賛になってしまうが、ある程度は自信もついてきたし、あれだけ苦手だったにも関わらず進んでやれるようになってきた。その結果、あれだけ興味のなかったマネジメントや組織に関する本も(コーチングの兼ね合いで英語版がほとんどだが)気楽に読めるようになってきた。

来年はこの勢いで多々ある改善点に真摯に向かい合い、より効果的なマネジメントができるよう努力を続けたいと考えている。

明日はいよいよ第 25 回、弊社代表取締役、塚田による「自分の人生をどんな未来にベットするのか？」。アントレプレナーとして必須かつ見失いがちなことが詰まっていると思う。