「暗黙の期待が高いこと」はマネージメントの怠慢である。
この記事はユアマイスター アドベントカレンダー2021の25日目の記事です。ユアマイスター社員の皆さんが個性あふれる発信をしていますので、ぜひ他の記事も読んでみてください。
こんにちは。@inase17000です。
今年も年末の季節がやってきましたね。noteを書くこと自体がだいぶ久しぶりになっていました。おかげでエディタがバージョンアップしていることにも今まで気づきませんでした。
さて、今回はマネージャーに必要とされる考え方について言語化に試みて、noteに書き興しておこうと思います。
ちゃんとマネージャーやりたい
まず大前提にあるのは、私が元来「ちゃんとマネージャーやりたい」と思っているところから始まります。
もともとエンジニアとしてのキャリアが長かった私ですが、マネージメントの役割に対して積極的に向き合いたい、どうせやるならちゃんと勉強&実践して一流のマネージャーとしてチームに貢献したいと考えています。(道は長い…)
会社の成長とともにエンジニア組織に対する私の役割が、徐々に変化してきていました。
例えば最近だと、組織内にテックリードを配置し、技術的な計画策定やエンジニアたちのアウトプットのレビュー、開発体験向上のための施策遂行など、非常に力強くエンジニア組織全体の成長に貢献してくれるようになりました。
そこで、私はエンジニアたちがもっと働きやすい環境や、プロダクトの成長に貢献できるチームづくり、プロセスづくりにミッションが移っていきます。
より「マネージャー」としての仕事の割合が増えてきて、エンジニアと手を取り合って一緒に開発せずとも、エンジニアひとりひとりの成長に貢献する方法をとりたいと考えるようになりました。
Getting things done through others
マネージメントの定義は千差万別いろいろな言葉で語られています。私はGetting things done through othersという言葉に集約して考えています。
これは中原淳氏が紹介していることで知ったフレーズなのですが、エンジニアリングマネージャーの分野でも同様に活用するため、迷ったときに思い出すようにしている大事な言葉のひとつです。
このフレーズを気に入っているのは、もともと楽天で働いていた頃、「Get things done」カルチャーを強く刷り込まれ、何事も「Get things done」しなければならないという先入観ができていたことも関係しているかもしれません(笑)
Getting things done through othersとは他者を通じて何かを成し遂げる仕組みをつくることを意味します。1人でやり遂げられる仕事の量やインパクトには限界があるため、大きな成果を出すためにはチーム全体が一致団結してGet things doneする必要があります。
マネージャーができるのは、他者を通じてアウトプットを最大化すること、プロセスを最適化することだと置き換えて使うことが多いです。ここで、マイクロマネジメントすることを求めているのではなく、主役となるエンジニアがマネージャーの信頼に応えるべく前向きなプレッシャーを感じている状態が理想的だと考えています。
「暗黙の期待が高い」というフィードバック
ひとりひとりのエンジニアに最大の成果を出してもらいたい!っていうことで、チャレンジングな毎日を過ごしていたわけですが、ある日、社内の1人のエンジニアから以下のようなフィードバックをもらいました。(原文ママ)
はっとしました。「暗黙の期待がとんでもなく高い」という言い方で、私とエンジニアたちの間にギャップが発生しているということを伝えてくれました。耳が痛い!!
ちなみに、ユアマイスターは行動指針のひとつに「FEEDBACK is GIFT」を持っていることからもわかるように、積極的にフィードバックが行き交う職場です。
ポジティブなことはもちろん、耳の痛いことも言い合えるような誠実なコミュニケーションをとりあえるような環境づくりがされています。そんなユアマイスターの環境がしっかり成立している一例で、とても良いことだと思います。
このフィードバックをもらい、何が課題であり、どのように改善すべきなのかを立ち止まって考えるきっかけをもらいました。
「暗黙の期待が高い」とは何か
まず「暗黙の」という部分に着目してみると、暗黙的に期待を引き上げてしまっているのは私の方であり、今後のコミュニケーションの中で改善していかなければいけないことに気づきました。
私の思っている期待値とエンジニアが出せるアウトプットの期待値に差があり、それに気づけていないということで、これが続いてしまうとチームの心理的安全性を崩す要因にもなり得ます。
各個人の状況を見極めずにとりあえずやらせてみせてる作戦ばかりになってしまっていて、うまくいくかどうか毎回ギャンブルをしていることにしかなっていないというのが問題でした。
結局、マネージャーがエンジニアのスキルや状況を加味しながら働きやすい環境を作ることや障害を取り除くことに注力できておらず、エンジニアにただ任せてみて結果を運任せで見るだけという話では、マネージャーは仕事をしておらず、ただの怠慢だったと気づくのです。
「期待」をコントロールするために
ここで、確率論や統計学などで現れる「期待値」を定義から考えると、確率と値の掛け算になっているため、この2つに因数分解することができます。
今回問題があった「暗黙の期待が高い」のシチュエーションを考えると、私が(1)確率の過大評価、か、(2)値の過大評価と分解できます。
ここで、確率はエンジニアが任されたタスクを成功させる確率、値はそのタスクが完了した結果のエンジニアのアウトプットの量や質を表すと考えてみましょう。
(1)確率の過大評価
スキルや知識は一夜でいきなり増えないし、目の前のタスクが一回の残業をするだけで突然進捗することはありません。
夜寝てる間に小人のおじさんがやっておいてくれたらいいのにな…といつも願っているアレは絶対に起きないことを知っているのに、自分以外の他人だったら起きるかもしれないと思ってしまうのは間違いです。
奇跡的に状況が変わることを祈るよりも、どんな解決策がありえるのかを事前に洗い出し、それぞれの可能性に対してマネージャーとしてできる支援が何かをリストアップ&根回ししておくほうが、よっぽど成功確率を高めることができます。
不用意に確率を過大評価しないためにも、状況の可視化や三角測量が必要になるでしょう。エンジニアが当事者としてタスクをしていると視野が狭まって気づけていないような見落としている穴や、観点の抜け漏れがないかという点も、客観的に視野を広げて亀裂を埋めてチームをのための道を馴らし、時には必要なアドバイスもしていかなければなりません。
結局、確率をコントロールすることはできないので、どのパターンがきても大丈夫という幅のある選択肢を許容できる余裕こそがマネージャーに求められているのかもしれません。
(2)値の過大評価
エンジニアごとにこれまでの経験や担当する領域によって、どうしても得意不得意があります。また、技術の習得度も、理解しているレベルから他人に教えることができるレベルまで様々な状態がありえます。
ひとによって「当たり前品質」が異なっているから、品質基準を定量的にルール化するか完全に属人化させることでしか、絶対的にアウトプットの量や質を言い当てることはできません。
この値の過大評価は、前述の「(1)確率の過大評価」に比べると、発生しづらいのではないかと推測しています。なぜならば、通常会社勤めのエンジニアは同じような技術スタックで開発を続ける環境にいることになり、エンジニアのアウトプットの量や質を大きく左右させるようなタスクをアサインすることは稀だからです。
値を過大評価しないようにするためには、エンジニアごとのスキルセットを把握し、安定したアウトプットを出す環境づくりがマネージャーに求められています。
最後に
自分でタスクをするわけではないのに、成果を最大化するという難易度MAXのマネージャーですが、フィードバックをもらったことをきっかけに、向き合いつつ今後どうすればいいかを考えることができました。
人間は弱い生き物なので、放っておくと思考停止で運まかせのマネージメントになってしまいます。今回考えたことを戒めにして、失敗から何を学び、どう素早く改善していけるかに目線を向けて、今後のマネージメントに継続的に活かしていかねばなりません。
最後に「Googleのソフトウェアエンジニアリング」の一節を引用して終わりたいと思います。
「優れたマネージャー」が何たるかを言語化し続け、自分の血肉にして自分のものにしていこうと思います。
私が働くユアマイスターではエンジニアを積極募集しています。こんなことをウンウン考えながらマネージメントを一緒に作っていけるEMの方もいらっしゃったらぜひ声かけてください。
以下の記事もぜひご覧ください!お会いできるのを楽しみにしています!