EM歴1年でやってよかった取り組みNo.1「よもやま行脚」の紹介
こんにちは。noteでエンジニアリングマネージャー(EM)をしている福井です。
EM専任になってからちょうど1年くらいになりますが、この1年でやって良かった取り組みってなんだろうなと振り返ったときに圧倒的に自信を持ってコレだと言える「よもやま行脚」を紹介します。
1. よもやま行脚とは
決まったアジェンダは無し、業務に関する話で無くてもOKのていで、一対一の対話を全エンジニアと月次で実施します。ん?それ1on1と何が違うの?と思った方もいらっしゃると思いますが、一般的には1on1とも言えると思います。ただ、私は以下の理由から1on1とは使い分けています。
1on1は、基本的にアジェンダ有
1on1は、かしこまったイメージ
1on1は、する側とされる側の上下関係(される側が主役)が作られやすくフラットではない
※ 1on1をディスっているわけではありません。あくまでケースバイケースで使い分けたいという意図です。
※ よもやまはリクルート社のカルチャーをオマージュしてます。
2. なぜやろうと思ったのか
昨今、1on1の重要性を多くの企業が認知し、全社の取り組みとして取り組まれている会社がほとんどなんじゃないかと思います。個々人でも大事なのはなんとなくわかるよという方が大半なんじゃないでしょうか。私自身もEMになる以前はなんとなく大事なのはわかるくらいの認識でした。
当時40名ほど在籍していたエンジニアのうち半分程は対面でお話をしたことがない方でした。マネジメントを勉強する中で、日々の業務もとい、一対一の対話もとい、コミュニケーションは、
「社会構成主義」と「相互理解」
の元に成り立っていると自分の中で結論づき、対面でのコミュニケーション(= よもやま行脚)することを決めました。
3. 「社会構成主義」と「相互理解」
社会構成主義
つまりどういうことか。私の解釈は以下です。
人との関係性によって認知してるものが違う
だから、対話を通じて関係性を構築し、合意形成を経て意味(現実)を作り上げていく必要がある
だから、コミュニケーションを取らないとお互いの認知は歪んでいく
社会構成主義についてもっと詳しく知りたいと思われた方は以下の書籍がオススメです。
また、対話と関係性(ナラティブコミュニケーション)の文脈で以下の書籍も強くオススメします。
相互理解
相互理解については、私が理解を深めるきっかけになり、勝手にマネジメントの師と仰いでいる長村さん著の急成長を導くマネージャーの型から紹介します。
相互理解は「認知の相互理解」と「仲間の相互理解」の大きく2種あり、認知を経て仲間の相互理解が得られます。
認知の相互理解: お互いの顔、名前、人となりを知っている状態
仲間の相互理解: 仕事に関する考え方や、人間性について深く知っている状態
仲間の相互理解まで進むと得られるものとして大きく3点が挙げられます。
連携指示コストの低減
アイディアや意見の創出
成長実感
最初のステップである「認知の相互理解」すらない状況ではコミュニケーションは上手くいきません。例えば、「何かあったら相談してくださいね」と声をかけたとしても残念ながら相談されることはないでしょう。日常生活で考えると至極当たり前だと思うのですが、大して知りもしない方に恋愛相談とかしないですよね。が、EMになった当初はそれをまさにやってしまっており、「全然相談こないなー」と嘆いていました。今考えるとお恥ずかしい限りです。
4. どう進めたか
ルール作り
決まったアジェンダは無し、業務に関する話で無くてもOK以外について、コミュニケーションの敷居を下げるにはどういったルールが必要かを考えました。ポジもネガも内容問わず何でも話してもらうにはクローズドであることを約束することが必要であると考え、情報の公開範囲を以下のルールとしました。
話した内容はGoogleドキュメントに記録します。ただしGoogleドキュメントの閲覧権限は当事者のみとします。
話した内容の公開範囲は非展開とし、経営陣や人事など他者への展開可否は都度確認します。逆に展開してほしいものがあれば仰ってください。
また、オンラインコミュニケーションのメリットを活かした形をとりました。チャネルはZoomでもMeetでもSlackハドルどれでも自由、顔出しも強制はしないとし、個々がコミュニケーションを取りやすいチャネルを選べるようにしました。
社内LTで協力要請
それなりに時間的コストを払ってもらうことに対して熱量を伝えるためには同期コミュニケーションが良いと判断し、毎週実施している社内のLT大会で全エンジニアにアナウンスをしました。
LT実施後、特に大きなハレーションもなかったので実施に向けて準備を進めることにしました。
スケジューリング
全エンジニアと1ヶ月15分の頻度で組み、15分で足りない場合や延長リクエストがあった場合は都度別枠で場を設けることにしました。
また、コンテキストスイッチがなるべく発生しないように決まった期間(月末の2日間)に集中してスケジューリングすることにしました。
コンテキストスイッチがなるべく発生しないようにという部分は狙い通りでしたが、もし参考にするのであればトイレマネジメントの観点から一定間隔でインターバルを取ることをおすすめします。
5. どんな効果が生まれたか
全エンジニアにどの程度プラスの効果をもたらせることができたかはわかりません。意味のない時間を過ごしたと思われている方もいるでしょう。ただ、直接「よもやまの時間楽しみにしてます」や「れつさんってちょっと怖い方だと思ってたんですが勘違いでした」と直接仰ってくれる方も少なからずいらっしゃいました。何より、自分自身が全エンジニアに対して少なからず「認知の相互理解」があると思えるようになったことで業務上のコミュニケーションが取りやすくなりましたし、「仲間の相互理解」に向かうための土台作りができたことには一定の価値があったと思っています。
6. 実施することでのデメリット
特定の期間に集約することのデメリットになりますが、調整コストがかかるので有給は取りづらくなりました。また、時間的コストはそれなりに消費しますが、何かを直接的に生産しているわけではないので、効果を可視化しづらい(定量的に測るのが難しい)というのはあるかと思います。
7. おわりに
仕事をする上でコミュニケーションはなぜ大事なのか。あくまで一つの考え方ですが、「社会構成主義」と「相互理解」という切り口で紹介しました。この他にも様々な考え方や、コミュニケーションを円滑にするための先人達の知恵が世にはたくさん溢れています。武器として持てるだけ持っておくことは大事だと思いますが、コミュニケーションする上での心得として何より大事なのは、
「相手に関心を持ち、いかに真剣に考え、熱量をもって接することができるか」
だと思っています。
最後に…お付き合い頂いた弊社エンジニアの皆さんには感謝しかないです。いつもありがとうございます🙏
明日の執筆担当はnote社の発明王こと いえもんさん です。引き続きよろしくお願いします!
==========
各種SNSもよかったらフォローいただけると嬉しいです!
ここから先は
¥ 100
技術書購入や勉強会・セミナー参加の費用にあてたいと思います🙏