アプリ開発現場におけるエンジニアリングマネージャーの役割について

私は現在、 家族アルバム「みてね」を開発するエンジニアチームにおいて、役職（職位？）としての「マネージャー」という責務を担っています。この役職は明示された権限・役割があるのと同時に、暗黙の「複数のエンジニアの生産性を最大化し、チームとしてプロダクトの目標を大幅に超える成果を出す」という役割が存在しています。

ただ、その暗黙の役割をどう果たしていくかは基本的にマネージャー個々人に一任されており、我々マネージャーはそれらをよく考え・実現していく必要があります。このポストでは、その暗黙でぼんやりとした役割を明確にしていくことを目的としています。

エンジニアリングマネージャーとは？

「複数のエンジニアの生産性を最大化しプロダクトの目標を大幅に超える成果を出す」という役割を与えられた「職種」のことをここでは「エンジニアリングマネージャー(以下EM)」と定義しています。様々な意見はあると思いますし、いくらかオーバーラップする部分があるのは理解していますが、エンジニアの評価、採用や予算についての決裁権の行使など、経営上の意思決定者つまり「役職」としての「マネージャー」とは便宜上区別しています。

このポストで書いていること

このポストでは、主に以下の2点について個人の意見を述べたいと思います。

・エンジニアチームの理想の姿とは何か
・エンジニアチームが理想の姿になっていくためにEMはどのような役割を担っているか

目指しているエンジニアチームの姿

私がEMをやっていくにあたって、マネジメント対象のエンジニアチームの姿はどうあるべきかを表現するために、ふたつのキーワードを用意しています。

・ボトムアップ
・学習

このふたつが実現できている状態のにエンジニアチームは、理想のチームであると私は考えます。

ボトムアップ

エンジニアチームは、常にボトムアップで物事を進めていくべきです。ボトムアップなチームである、とは以下のような状態を継続できるチームです。

エンジニア個人やチームの意見の重要性を経営者も含めて全員が理解している

どんな場面・相手であっても、エンジニア個人やチームは、ある一定のルールのもとで責任をもって意見や主張ができるべきです。そのためには、チームメンバーとPOや経営者がお互いにその重要性を理解しあい、意識的にそういった意見のできる空気と場が提供されていることが必要です。

様々な課題はエンジニアの責任によって解決されるべきとエンジニア自身が感じている

プロダクト開発の現場ではプロダクト自身やその開発プロセスなどにおいて複雑な問題が発生しますが、それらは誰かが勝手に解決してくれるものではありません。どんな場面・相手でも意見ができる現場において、エンジニア個々人が責任を感じ、解決のために考え、自ら行動を起こしていく必要があります。

大きな声に忠実になりすぎないためのコミュニケーション

プロダクト開発をおこなっていると時々、経営者やPO/PM、はたまた単に話の上手な人によって現場の空気が一転してしまうことがあります。このようなときも「あの人が言っているからしょうがない」と思考停止せず、冷静にそういった空気を捉え、エンジニア個々人が即座に一度自分たちの頭で考えて見て納得した上で物事に対処することができるようなコミュニケーションの方法を確立する必要があります。

以上のようにエンジニアチームが「ボトムアップ」で動くことによって、チーム内の意見・行動の自由度は徐々に上がり、トップダウンでチーム運営が行われるよりも自分たちが開発するプロダクトに対してより大きく責任を感じ、適切な緊張感のもとで開発と改善を継続していける冷静なエンジニアチームを形成できるはずです。

学習

エンジニアチームは常に失敗と成功から組織的に学習を繰り返すことが必要です。学習とは単に「新しい技術や知識を身につけてプロダクトに反映しよう」というだけの意味ではありません。学習ができるチームとはどのようなチームか具体的に考えてみました。

短期的・中期的な振り返りの時間が確保されている

エンジニアチームは短期的に自身のプロセスや目標に対しての進捗を振り返るための時間が確保されている必要があります。そういった場において「プロセスがうまく働いていない」「目標に対しての進捗が悪い」と感じる場合、チーム内のメンバーが率直にそれを発言し、改善案を議論した結果、できる限り早く改善のための具体的行動を起こすことができるようなチームは「学習」していると感じられます。

失敗や意見の対立を冷静に受け入れることができる

何かチーム内に問題が発生している場合、それらを解決するための議論は必ず必要ですが、そういった場において、他者の失敗や意見の対立をいかに冷静に受け入れるかが、「学習」をより効果的なものとするために重要なことです。失敗の事例や対立する意見に対して、冷静にむしろ好奇心を持って耳を傾けると、そこには自分が気づきもしなかった視点があることがわかり、より大きな改善や成功に向かって道が開けることが多いと思います。

上記のようにエンジニアチームが常に「学習」し、プロセスやプロダクトを改善し続けることで、失敗を糧により大きな成功がより早い段階で実現できると信じています。また、エンジニアチームの学習を積極的におこなっていくためには「ボトムアップ」な運営がなされていることもとても重要で、「ボトムアップ」と「学習」は相互に必要不可欠な要素であると考えています。

エンジニアチームにおけるEMの役割

「ボトムアップ」で「学習」が行える理想的なエンジニアチームとなることを目指し、EMは何をすべきでしょうか。EMは理想とするチームを形成するために障害となる物事を予防し・いち早く気づき・万が一チーム内に障害がある場合はそれら取り除いていくことが重要な役割となります。もう少し具体的に言うと、EMの役割は以下のようなものだと考えています。

チーム運営に関わる最低限のルールを作る

チーム内で闊達な意見交換や失敗の共有を行うために、最低限のルールを作っていくことはEMの大事な役割です。ここで重要なのは、ルールとは制約を作りメンバーの突飛な行動を抑制するようなものではなく、思わぬところから危険が発生しないように「メンバーを守るため」のものであることです。また、作られるルールは、大きなプロセスを遂行していくためのルールであることもありますし、単に小さな会議の中での「発言の仕方」だったり時と場合によって様々なものがあると考えています。

メンバーと一緒にわくわくするようなチームの目標を作る

メンバーが自らの手を動かして大きな責任を持ちながらもチャレンジしたいと考えるに値する、わくわくするような目標を「メンバーと一緒に」作るため、EMは努力すべきです。メンバーが自ら考え「この目標を達成したい」と感じてくれることでよりプロダクトに対してのチャレンジが活発になり、チームを理想的なものにするために行動しやすい空気が生まれると考えています。

チームやメンバーが失敗した時・成功した時には、それらをどちらも賞賛するような場と空気を作る

プロダクト開発をおこなっていると、チームや個人の判断や行動・選択が成功することもあれば、もちろん失敗することもあります。そういった時に、チーム全体が失敗から次の成功のための学びを得ることができるようにEMは行動する必要があります。私は、責任感をもったエンジニアやエンジニアチームが起こした、たった数回の失敗は今後の成功のための糧であると本当に思っているので、常に賞賛したいと思っています。失敗から上手く学ぶためには、「いかに失敗の影響範囲を小さくするか」「失敗した時に冷めないうちにすぐに改善を導き出せるか」が重要だと考えています。また一方で、成功した時により感動を大きくさせるための空気作りもEMにとって必要な役割であります。

意見の対立を冷静に解決させるよう促す

メンバー間での意見の対立が起こった場合にはすぐさま問題を整理させ、冷静に対立する意見に向き合うよう促すこともEMの役割です。意見が対立している状況においては感情や価値観が優先され、本来の問題に対しての解決策としてお互いが意見を適切に提示できていないこともあります。意見の対立を「まぁまぁ、落ち着きなよ」と感情を抑えることだけで収束させるのではなく、対立し合う意見を当事者同士で整理させ、自分たちが解決したい課題は何なのかをもう一度気づかせるための行動がEMには求められると思います。

フレームワークを用いたマネジメント

EMの役割を適切に果たしていくためには、プログラミングと同様いくつかのフレームワークを導入した方が「単純に楽」です。私は、以下のようなフレームワークを導入し、理想のチームを形成するためのマネジメントのサポートをしてもらっています。

OKR

OKRを導入することでと以下が実現できます。

・事業に対してチームや個人が何をすべきか？をエンジニア自身が自分たちの頭で考えることができる
・事業におけるチームの責任が明確になり、エンジニア自身が自分の能力の重要性を感じることができる
・客観的な指標を用いることで失敗・成功を振り返りやすくすることができる

私たちのチームでは、2018年10月からOKRを導入したばかりなので、上記が本当に上手くいくかはもう少しあとに結果を振り返る必要がありますが、普段、チームのエンジニアが「プロダクトのどこに課題を感じているか」であったり「自分は〇〇なことが得意なので、そういった面で貢献したい」などのエンジニア間の会話の透明性が高くなり、お互いの信頼関係を深めることに少なからず寄与できた気もしています。

1on1

1on1は以下のことを確認する目的で行います。

・OKRや開発の進捗を確認する
・進捗が悪い場合に阻害している要素が何かを確認する
・阻害している要素を取り除くために何をすべきかを一緒に考える

私のチームでは2週間に1回、かならず全てのエンジニアとEMが会話する時間を20~30分とるようにしています。
この時間では、例えば、進捗が悪い場合にそれを阻害する要素が何なのかを確認してみると、実はエンジニア間で小さな意見の対立が起こっていたりすることがあります。それらを第三者である自分を前に冷静に振り返ってもらい、次にその意見の対立に対してどう行動すべきかを具体的で行動しやすい形に落としてもらうことができたりします。1on1は、短期的で内省的な振り返り・クールダウンの場として、とても良い時間であると感じています。

スクラム開発

スクラム開発は、失敗と成功をエンジニアチーム自身（とPO・その他ステークホルダー）が振り返る場として「スプリントレトロスペクティブ」が用意されています。それが適切に運用されると、以下のようなことが実現できます。

・短期間で振り返りができるので、失敗の規模をできる限り小さくできる
・改善のための行動を起こすところまでがフレームワークとして組み込まれているため確実な改善行動が見込める

このように、私はEMとして、中期的な振り返りの場としてOKRを、短期的でオープンな振り返りの場としてのスクラム開発を、よりパーソナルで内省的な振り返りの場として1on1を、という形で各種フレームワークを導入しながら「ボトムアップ」と「学習」を効果的に実践できるようにしています。

EMの評価

EMという職種が果たした役割を客観的に評価する指標が何なのかは非常に難しく、私自身まだよくわかっていません。

ただ、EMである私が自己を評価する方法があるとすれば、チームのトップであるPO/PMが事前に掲げ、エンジニアチームが合意したはずの事業の目標について、それぞれのエンジニアメンバーが自信を持って「達成した！」「すくなくともこの点については客観的な成果が認められる！」であったり、「これはちょっと無駄な時間を使ってしまった、次の半期ではこういう行動に変えていこう」という「学習」を前提とした振り返りができているかどうかだと思います。

非常に主観的ではありますが、一定の期間が終わった時に、こういった言葉がチーム内の至る所で飛び交っていることが、EMとしての役割を果たせたかどうかの自己評価に、少なからず繋がるのではないでしょうか。

まとめ

とても長く抽象的な話が多かったかとは思いますが、私がEMという役割を果たしていくために必要であると個人的に感じている物事を整理して説明しました。

まとめると以下の通りです。

・EMは「生産性の最大化」のためにチームに貢献する役割を与えられた職種である
・エンジニアチームは「ボトムアップ」で常に「学習」を行うことができる組織であることが理想である
・EMは時にいくつかのフレームワークを使いながらも理想のエンジニアチームの実現のために常に具体的行動を取るべきである

EMをやっていると本当に様々で複雑な問題が発生してなかなかツラいこともありますが、軸をブラさず・また、ある一定のルールのもとで考え、行動を起こすことで感情的にならず冷静に物事に対処できます。またこういった考え方を持つことで組織最適になりすぎない汎用的な「マネジメント」能力を身に付けることも可能だと思っています。

EMは組織において他の職種に比べて相対的に人数も少なく、なかなか難しい立場だとは思いますが、このような汎用的に使える「マネジメント」の考え方や技術を共有することも現役EMとしては非常に重要な役割であると考えているので、今回このような記事をポストしました。

以上、ここまで読んでいただきありがとうございました！