マネジメントを知らないエンジニアが本を読んで感じたこと

はじめに

Teachme Player開発チームの山川 (@jyamakawa) です。
私たちのチームでは今年だけでも2人のメンバーが新しく加わりました。

それに伴い、入社オンボーディングやプロジェクト参画・コードベース理解の支援など、コーディング以外の業務を担うことが増えてきました。
コードを書く以外のことはあまりやってこないで仕事をしてきましたが、エンジニアであれば「必要なのであれば学ぶ」姿勢は重要でしょう。ということで、マネジメントについて何も知らない自分がマネジメントを学んで得た気づきをまとめます。
（ちなみに私自身、新卒3年目、スタディスト入社から約1年を過ぎたところです）

まだまだ学びの途中ですが、マネジメントとは何かを全く知らない、過去の自分のような人は「マネジメントってこういう感じなのかなー」と。マネジメントの酸いも甘いも知っているエキスパートは「マネジメントを知らないとこういう風に思うんだ」と、参考にしていただければと思います。

学習前のマネジメントへの認識

元々、本当にマネジメントに対して全く理解がありませんでした。以下に当時の認識の一例を述べます。

• 目標設定って大変だけど、何故やるんだろう？
• 1on1って意味あるの？
• ミッション・ビジョンってぶっちゃけ意味があるのかな？
• そもそもマネジメントって何？

読んだ本と簡単な感想

• エンジニアリングチームのリード術 ―Googleに学ぶインディビジュアルコントリビューターとマネージャーのための実践ガイド
  • 上司からオススメされた内の1冊です。ボリュームが最も少なかったため最初に読みました。
  • 抽象的な話も多く、前提知識が無い状態で読むには少し厳しい本でした。
• エンジニアリングリーダー ―技術組織を育てるリーダーシップとセルフマネジメント
  • 上司からオススメされた内の1冊です。
  • 具体的な話が多く、何も知らない状態でも非常に読みやすかったです。この本を読むことで、エンジニアリング組織におけるマネジメントのイメージが強く持てるようになりました。
• マネジメント【エッセンシャル版】 - 基本と原則
  • エンジニアリング組織に限った話ではなく、一般的なマネジメントに関する話も重要だと思い、自分で選択した本の1冊です。
  • 自分の求めているものとは違いそうだなと感じ、30-40%程度で読むのをやめました。
• HIGH OUTPUT MANAGEMENT 人を育て、成果を最大にするマネジメント
  • 上と同じ理由で、自分で選択した本です。筆者はインテルの元CEOです。
  • まだ読み終わっていないですが、実際の体験に基づいた話を非常に分かりやすく説明しており、凄く良い本と感じます。

本を色々読んで考えた「マネジメントとは何か」

「HIGH OUTPUT MANAGEMENT」では、マネージャーのアウトプットは「自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット」と定義されています。
「エンジニアリングリーダー」では、チームに対して働きかけることで、チームのアウトプットを最大化させることを目指していました。

本を読み、考えた結論としてはマネジメント = 対象のアウトプットを最大化させようとする行為なのではないかということです。
例えば、メンバーが困っていそうなときに話を聞くことでそのメンバーがより活躍できるようになる。このような例のように、何らかの対象のアウトプットを考えて行う全ての行動がマネジメントなのではないかと考えました。

振り返ると、本を読む前から自分の仕事の意識として「チームのアウトプットを最大化しよう」というものが強くありました。
意識がチームのアウトプットに向いていたため、その結果として生まれていた行動にも多くの (適切な呼称かは分からないですが) マネジメント的行動が存在していたのではないかと考えました。

• 定期的なチームメンバーとの1on1
• 短期的に自分の出力を下げ、チームメンバーのサポートを行うことで中・長期的な出力の最大化を行う
• 自分が持っている仕事の内、任せられそうなものを積極的にチームメンバーに委譲していく

自分の解釈では、どうやら知らない内に「マネジメント」と呼ばれることをやっていたようでした。

今までにされていた「マネジメント」

「過去には何のためにやっているんだろう？」と思っていた行為が、マネジメントについて知ることでより意味を為すものに自分の中で変化しました。

目標設定

目標設定という行為が、イマイチ理解できていませんでした。「やれと言われるから設定する」に近い感覚でした。
ですが、マネジメントについて考え始めてから、目標設定というのは非常に大切かつ有効なマネジメント手法であると理解するようになりました。

目標設定というのは、メンバーとマネージャーの向く方向を合わせる行為と捉えることができます。
メンバーには、目標を達成することに対するインセンティブが存在します。(= 目標達成による昇給など)
マネージャーからすると、そのインセンティブを使用して特定の方向にメンバーの労力を誘導することができます。これはマネージャーが使用することのできる非常に強力なツールと言えるでしょう。

1on1

これも、雑談して終了じゃないか？と正直思っている自分がいました。しかし、「雑談して終了」ですら得る情報があるのではないかと今は考えます。
マネージャーはチームメンバーの状況を逐次で把握できるだけで十分なメリットとなります。悩み事があるのに検知できないリスクを考えると、悩み事がなくて雑談することに払うコストもリターンに合うかもしれません。

また、雑談で終わるくらい元気なのであれば、その余裕を利用して新しい行動にチャレンジすることを勧めることもできます。
そもそも、この記事を書くこと自体、上司との1on1で「マネージャーの本とか読んでみたら？」と勧められたことに起因します。たった30分の1on1によって、メンバーの成長を促すという成果を得られる可能性がある。そう考えるとマネジメントにおいて1on1が持つ意義というのが感じられます。

会社のミッション・ビジョン

ぶっちゃけ、意味があるのかな？と思っている人も多いのではないでしょうか。
これはチームよりも大きな規模でもマネジメントと言えるでしょう。会社の規模で、推奨する行動・推奨しない行動を示すことです。
直接的にこれを意識する人は少ないのではないかと思います。(「会社のミッションがこうだから、自分はこうするんだ！」は少ない。)

しかし、間接的に影響を受けているという捉え方を現在はしています。例えば目標設定を行う際に、目標がミッション・ビジョンと大きく乖離したものであるとすると、それはおそらく受理されないでしょう。
ミッション・ビジョンといった明文化された価値観を定義することによって、目標設定やその他の行為を通して従業員の行動を望んだ方向に推進させている。見えにくいマネジメントとして、会社のミッションなどは機能しているのではないか、と今は考えます。

まとめ

全くマネジメントについて知らなかった自分が、マネジメントの本を数冊読んで考えたことを長々と語らせていただきました。

エンジニアには、「マネジメント」に対してネガティブなニュアンスを感じたり、あるいは自分には関係ないことだからと思う人も多いんじゃないかと思います。
しかし、周りの人を気にかけるという行為ですら「マネジメント」であり、マネジメントをやりたくないと言っているけど意外と「マネジメント」やってるんじゃないか？と思っていただけると、非常に嬉しいです。