天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Engineering Management | JMDC Tech Talk #2に参加してきた

jmdc.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

「Engineering Management | JMDC Tech Talk #2」は株式会社JMDCが主催するエンジニア勉強会です。

今回は、主にエンジニアリングマネージャーを志す方や新任の方を対象とした勉強会を開催致します。  
ゲストスピーカーとして「エンジニアリングマネージャーのしごと」の翻訳者の一人である原田騎郎様にご登壇頂き、マネージャーに期待される役割の変化と、最近のエンジニアリングマネージャーに求められる役割についてお話頂きます。  
Q&Aの時間も用意しておりますので登壇内容や書籍の内容に関して質問があれば、申込み時もしくは当日にぜひお寄せ下さい。  
また、弊社及びグループ会社のエンジニアによるエンジニアリングマネジメントに関するLTも予定しております。

原田さんの講演

導入〜マネージャーって何?〜

マネージャーって言葉自体が非常に多義的だよね、と言う話からスタートしていきました。

例えば、マネージャーと聞いた時に浮かぶ言葉としては、以下のようにさまざまなものが挙げられるよね、という話が出ていました。

  • 管理者
  • 上司
  • (野球などスポーツの)マネージャー
  • (野球などスポーツの)監督
  • (芸能人についている)マネージャー

...

マネージャーと言う概念の変遷

科学的管理法

どういうやり方をすれば一番うまく仕事ができるのか?をテイラーが考えられた結果、管理者が正しいやり方を教え作業者がそのやり方に従うという考え方が登場し、製造ラインの導入などにつながったあたりの話が管理者という概念のスタートだと言うお話がありました。*1

ホーソン実験

テイラーの後、仕事の生産性を上げるために寄与する要素は何か?と言うのを実験した結果(=ホーソン実験)、寄与すると思われていたどんな要素も生産性に関係がないことがわかり、最終的には職場の人間関係が一番重要だという結果が出たというお話がありました。

X理論/Y理論

「人は怠けるものなので怠けないように監視するべきだ」というX理論と、「人は本来働きたがりなものなので、より自由に意見を述べられ行動できるように支援するべきだ」と言うY理論が登場したというお話がありました。

この結果、監督者としてのマネージャー/支援者としてのマネージャーという概念が登場し、どっちが正しいかわからない状態になったということです。

The New New Product Development Game

その後、The New New Product Development Gameが発表され、ここではものすごい速さでプロダクトをリリースしていた日本ではどのような管理がされていたのか?というのを研究した結果、同じチームの中で「さりげないコントロール」をマネージャーが重要だという結論が出てきたそうです。(=チームを支援する重要性が示された)

パワートゥザエッジ

湾岸戦争でコマンド&コントロールが話題になったこともあり、末端(エッジ)のチームが判断するための情報を提供し、末端(エッジ)のチームが判断する方が組織としてのパフォーマンスが大きく出るよ、と言う話がパワートゥザエッジで紹介されたと言うことです。

エンジニアリングマネージャーのしごと

ここまでの流れでチームを支援する立場としてのマネージャーが大事なのは分かったけど、じゃあチームを支援する立場としてのマネージャーはどんなことをしているのか?と言うのをまとめたのが直近翻訳された「エンジニアリングマネージャーのしごと」には書かれているという紹介がありました。

その上で、本の内容の紹介がされていきました。

まず自分を管理しよう(2章)

「マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット」という2章のお話が紹介されました。

この式から、マネージャーの評価は自分がマネージしている組織に対しての貢献だけでは評価できないことが示唆されている点が重要ポイントだということです。

発達の最近接領域(5章)

「とりあえずやってみて」と育てられたプログラマーは多いと思いますが、それは変な話で、発達の最近接領域の考え方に従うと「学習者が支援ありでできるタスク」をいかに効果的に活用していくかを考えるのが重要だ、という5章のお話が紹介されました。

コントロールを手放す(13章)

マネージャー自身が疲弊しないように、自身でコントロールできないこと/自身でコントロールできること、をまずは分けた上で、自分である程度コントロールできることに対してベストを尽くすんだ、という13章のお話が紹介されました。

いったん落ち着こう/いったん力を抜こう

最後に、本で複数回出てくる、「いったん落ち着こう/いったん力を抜こう」という考え方が紹介されました。
エンジニアリングマネージャーの仕事は覚えなくてはならないことがたくさんあるので、まずは力を抜いてみよう、落ち着いていこうという考え方をぜひ心に留めておいて欲しいということです。

山本さんのLT

kiroさんの講演後は、JMDCの山本さんからLTがありました。

「エンジニアリングマネージャーのしごと」で言及があった内容を参考に、チームが大切にしていることを明文化し、ジョブディスクリプションを作ったお話でした。

結果的にできたジョブディスクリプションももちろん素敵だったのですが、ジョブディスクリプションを作る過程でチームと話し合いを重ね、その中で心理的安全性の構築が実感できたというお話が、非常に印象的でした。

小原さんのLT

続いてJMDCの小原さんから、ツール(15five)を用いてマネジメントのコストを下げたお話を聞いていきました。*2

15fiveの様子をデモしてくれたのですが、1on1やエンゲージメント、OKRの管理など、エンジニアリングマネージャーが担うことが多いであろう業務が幅広くサポートされており、ツールに興味が湧くような内容でした。

Q&A

エッジ(メンバー)を自走させるためのモチベートに苦戦しています。モチベーションが低いメンバーへの動機づけはどのようにするのが有効でしょうか?

kiroさんは非常によく聞かれる質問だそうですが、モチベーションを上げるのは不可能だということです。

ただ、モチベーションを下げないようにすること(仕事を奪って余裕を作ること, モチベーションを上げようと色々な行動をしないこと)はできると言うことです。
また、(エンジニアは特に)面白い問題に飛びつきがちなので、面白い問題を与えておくことと、飛び付ける余裕を作っておくことが大事だとも話されていました。

EMの重要性を社内で布教するコツ等ありますか?

こんなことをやっているよ、というのを周りに見えるようにした上で結果を出し、周りから自然に興味を持ってもらうようにすることがいいのでは?ということでした。

ただ、こうした取り組みをするのにも余裕が必要なので、マネージャー自身がまずは余裕を持つことが重要だと言うことです。

「エンジニアリングマネージャーのしごと」でkiroさんが共感できなかった章があれば教えて欲しいです

最後の方にあった、メンバーのキャリアプランの構築を助ける話が書かれている章については、ちょっと雑すぎないか?(もう少し実験してからやったほうがいいかな?)ということでした。

自分のマネージャーにこの本を読んでもらいたいと思ったときにメンバーとしてできることはありますでしょうか。

複数冊買ってばら撒いて見えるところに置いておくのがいいのでは?ということでした笑

電子書籍だとできないのが難点ですが、読後感があるとその本に食いついてくれる可能性は高まるそうです。

書籍に関してですが、退職のあたりは日本だと法律等の関係で難しいと思いました。この辺りを日本だとどのように進めるべきかといったことがあれば教えてください。

日本では退職は難しいよねという話はありつつ、高いパフォーマンスを発揮できる領域/できない領域が個々人であるので、役割を変えてみるのは一つではないか?ということでした。(逆に海外ではこれはできない)

エンジニアリングマネジメントのバイブルは?

難しいですが、現状はまだないということでした。

なお、マネジメントという観点だと、(バイブルという一神教の存在はないものの)high output managementはおすすめだそうです。

kiroさんが考えるEMの魅力は?

チームが色々なことがみるみる上手になるのを見るのはすごく面白いというお話がありました。

次翻訳したい本は?

山ほどあるそうですが笑、自分が「余裕を大事にしろ」と言っている手前上、今は着手を決めていないということです。

普通のマネジメントとエンジニアリングマネジメントの違いや共通点を教えてください。

違いを見出すより、「マネジメント=チームやメンバーの支援を当たり前にすること」の世界になるといいなあと思っているそうです。

エンジニアリングマネージャーのしごとはピープルマネジメントの話がメインと思いますが、プロダクトマネジメント/プロジェクトマネジメント/テクニカルマネジメントもエンジニアリングマネージャーの範疇だったりしますか?

レイヤーは組織によってなので難しいし、分からないというお話でした。

また、あんまりレイヤー分けを効率よくやることに着眼してもしょうがないし、少し重なっているくらいでも良いのでは?と言うことでした。

英語はどのように学んだのか?

kiroさんは大学時代翻訳のバイトをよくしていたそうで、そこでプロの翻訳者の方と関わる機会があったそうです。

あとは、毎日15分ラジオを聴いていたのとシャドーイングをしていたそうです。

会全体を通した感想

先日ryuzeeさんの出版記念講演(??)も聴いたのですが、今日はkiroさんからまた別の角度でお話を聞くことができて、学びがより深まりました。

Q&Aでは、本に関係ない結構意外な質問も出ており、非常に楽しかったです。

*1:製造業のコンテキストで言うとフォード生産方式の考え方もある

*2:15fiveと利害関係があるわけではない