エンジニアリングマネージャーが意識しているコミュニケーションテクニック
この記事は、弁護士ドットコム Advent Calendar 2019 - Qiitaの15日目の記事です。
いよいよ年末感がヤバいですね。
私は2018年12月1日に弁護士ドットコム株式会社に入社しましたので、ちょうど1年がたちました。
毎年アドベントカレンダーの時期に入社n年目をキリよく振り返ることができるので、リズム感があって良いですね。
さて、弁護士ドットコムではエンジニアリングマネージャー(以下EM)として働いてきたわけなんですけれども、今回はこの1年間EMとしてコミュニケーションを取るさいに意識していた、名付けと言語化について話してみたいと思います。
とはいえ、別にEMに特化したものではなく、働く上で誰でも使えるものだと思いますので、少しでも誰かの参考になれば。
(立場上、1on1とかを通して活用する機会が多いので EM、というかマネージャーの人は活用しやすいかも?くらいに思っています)
名付け
名付けとは
まずはじめに、名付けとは何を意味しているのかです。
名付けとは、その名の通り「名前をつけること」なのですが、特にここでは「事象・現象・概念 あるいはその関係性に名前をつけること」を指しています。
名付けをすると何が良いのか
ものごとに名前がつけられることで、意思疎通の効率化が図れたり、認識がしやすくなったり、対策しやすくなります。
多くのエンジニアは、日常的にこの名付けの恩恵にあやかっているのではないでしょうか。 著名な法則、原則、アンチパターンなどを思い浮かべると、よりイメージが湧きやすいかもしれません。
例えば、さっと思い浮かぶだけでも下記とかはいかがでしょう。
- Conwayの法則
- Kissの法則
- Yak Shaving
- YAGNI
- DRY
- n+1問題
これらが名付けられていることにより、指摘しやすかったり、意識しやすかったり、説明しやすかった経験はありませんか?
このように、一般的に発生しうる技術課題への対策の多くは、先人たちの知恵により名付けられ、定義化、法則化、アンチパターン化されてきています。
これは何もエンジニアリングに限ったことではなく、人類は複雑な概念、事象を端的な言葉で表現することで、その先にある認知を獲得し、更なる発展を遂げることができてきました。 つまり名付けという行為は、単なる識別子を付与するというだけでなく、認知を拡張するという行いでもあるわけです。
言語化
言語化とは
次に言語化とは何を指しているのでしょう。先程説明した名付けも一種の言語化ではありますが、ここではより広く、自身の考えや置かれている状況、行動原理や目的、ルールや暗黙知など様々なものごとを改めて言葉に起こし、説明可能な状態にすることを指しています。
例えば、評価制度や評価基準などは、会社がどういう人・行いを評価するか、あるいは評価しないかを明確化し、他者に対して説明可能なように言語化したものになりますし、Daily Scrumなどで行う、やったこと・やること・困っていることを報告することも言語化です。
言語化すると何が良いのか
言語化の一番の意義は上述したとおり、説明可能な状態にすることで、他者へ情報を伝達しやすくすることにあります。当たり前といえば当たり前ですし、今更言われるまでもないことかもしれません。
しかしEMをやっていると、業務を遂行する上でこれほど重要なことは無いなと思う場面が多々あります。それは自分の考えを適切に言語化することの難しさゆえになります。
みなさんは、「不安なんだけど、何が不安なのかうまく言葉にできない」や「腹立たしいんだけど何に怒りを感じているのか自分でもわからない」といったことを経験したことはないでしょうか。そして「人に話しているうちに、自分が何を考えて、どうしたいのかがわかった」という経験も。
これらは、自分が何を考えているか、どうしたいかという問いに答えることが、実はなかなか難しいということを示しています。そしてそれはイコール、多くの人は自分自身の考えを他者に十分に伝えることができていないということも。
そして、こうした困難さがコミュニケーションにおける障害となり、情報伝達の欠落に繋がり、多くの組織において生じる組織課題の要因となってしまいます。
言語化とは、日々発生する課題を解決するため、あるいは課題そのものを明確化し対策を検討するために重要なステップなのです。
EM業務における名付けと言語化事例
では実際に私がEM業務を行う上で、どう名付けと言語化を行っているかを紹介します。
と、言っても実際に業務上行っているのはほぼ言語化になります。
なぜなら、名付けについては、わざわざ自分がその概念に新たに命名するまでもなく、すでに名付けられていることが多いためです。
ですので、名付けについては「この事象/現象/概念には何か名前がありそうだぞ」と思い、調べ、知識の引き出しの中に入れておき、必要なときにさっと使える状態にしておくくらいで良いと思います。
というわけで、業務上私が言語化を意識する場面をいくつかピックアップしてみました。
1on1
1on1の際は、メンティーが何を考えているか、どうしたいのか、何を課題に感じているのかといったことを、メンティー自身の言葉で言語化してもらうことを意識しています。これは、「言語化とは何か」 で書いたように、多くの場合 人は自分自身で言語化を行わないと、ものごとを自覚することが難しいという理由からになります。
そのため、1on1のときは直接的にアドバイスをするよりも、なるべく多くをメンティーの言葉で語ってもらうようにし、自身で課題を発見してもらい、次のアクションへつなげてもらうようにしています。
この際よく用いるのが、コーチングだったり、Whyの掘り下げといった手法で、いわゆる壁打ち相手となるようにすることです。
例えば
- 今困っていること、ストレスを感じていること、体調面で何か問題はないか。あるいは逆に最近楽しかったこと、テンションが上がったことはないかを聞く
- そうなっている背景にはどんな理由がありそうか、なぜなのかをいくつかの角度から確認する
- メンティーに話してもらった内容を、私の理解でサマリーして伝え、合っているか確認する
- そこに課題感がありそうな場合は、どうアクションするのが良さそうか確認する
といった感じです。 こうして可能な限り状況を言語化して他者に伝えていく過程で、考えが整理されたり、思考の刺激を受けることでお互いに新たな発見ができていったりします。
プロジェクトマネジメント
プロジェクトマネジメント時には、いろいろな場面で言語化と、名付けられた言葉の利用を行うのですが、今回はキックオフ時や新メンバージョイン時を想定してみます。
この際自分が最も大事にしているのが、Whyの言語化です。
- なぜこのプロジェクトを行うのか
- 自分たちがやる意義、現在の状況、目指している世界
- なぜこのメンバーなのか
- 今までやってきたことと、なぜその手段を取ったのか
- 複数ある選択肢の中からそれを選んだ理由
などなど。重要なのはあらたに HowやWhatを伝える必要が出てきたときに、その事実だけを伝えるのではなく必ず Why を伝えるようにするということです。
もし、プロジェクトキックオフ時にメンバーに集まってもらい「今後のプロジェクトはこれです。みんなにはこういうことをやってもらいたい。」ということだけを伝えたらいかがでしょう。
あるいは新メンバーが入ってきたときに、「このプロジェクトはこういう機能を開発しています。今まではこういうことをやってきてて、あなたにはこれを任せたい」と伝えたら。
これだけでも、HowやWhatは言語化できているので、動き出すことはできると思います。 しかし、メンバーが自律性を持ち、自ら考え工夫し、みんなでゴールへ向かうことを考えた場合 かなりの混乱が起きることは容易に想像できるのではないでしょうか。
極論、Why で言語化された課題が解決し、ゴールへ到達できるのであれば、HowやWhatの部分は何でも良いですし、メンバーが自らどんどん変更していって良い部分です。
大切なのは、同じゴールを目指すこと。そのためには、何よりも Whyの言語化 が重要になってきます。
まとめ
実際、多くの方が言われるまでもなくここに書かれていることは理解されていると思いますし、業務で自然と実践してると思います。
でもいかがでしょう。改めて言われることで、より意識できたような気がしませんか?
それこそが、名付けと言語化の効果だと思います。
みなさんもぜひ、自分の今の状況・考えを言語化したり、周りにいる人の言語化を促してみてください。きっと新たな発見があると思います。
それでは、良いお年を。
(言語化の次にくる大事なものは可視化なのですが、それは機会があればまたどこかで書こうと思います)