しばらく開発から離れていたエンジニアリングマネージャーが現場の開発に戻った話

初めに

初めまして、新卒からAdwaysに入社し8年目になります。杉内と申します。
アプリケーションエンジニアやプロジェクトマネージャー、データアナリスト、広告運用者などを経験し、ここ4年程は複数の開発チームをマネジメントするエンジニアリングマネージャーをしています。
今回は、「しばらく開発から離れていたエンジニアリングマネージャーが現場の開発に戻った話」として、最近の動きを記事にします。

この記事に書く内容

• マネージャーが開発者として、入る時のノウハウ
• 開発を離れたマネージャーが久しぶりに開発を経験し、得た効果
• エンジニアリングマネージャーに必要な技術分野のスキルセットとは。

なぜ開発業務を改めてしようと思ったのか

そもそも、なぜこういった取り組みを行なったのかを最初に説明します。
私の今までの役割を簡単に説明すると、以下のような感じでした。

エンジニア 1年目~4年目
プロジェクトマネジメント 2年目~4年目
ディレクション 2年目~4年目
広告運用者 3年目
データ分析 2年目~3年目
複数チームのマネジメント 4年目~7年目

若手の頃から、非常に幅広い役割で動いてきたため、スキルの幅は開発以外の分野にもとても広く積めたと思っています。
ただ、今の役割で、複数チームにおいてマネジメントをする上で、課題を感じつつもありました。

それは、私自身の開発レベルが高くないことによって、技術という分野においては、組織の施策を推進しづらいという課題でした。
新しく出てきている技術を実際に触っているわけではないので、施策を企画しても、創出価値のイメージがしづらいため、推進に今ひとつパワーが足りない感じです。
技術文化を醸成する立場として、ある程度の技術力の基盤を持っておくことも武器になると考え、もう一度開発現場に入り、技術の勉強をしなおしたかったことが今回の取り組みの理由になります。

マネージャーが開発者として、現場へ入る時のノウハウ

私は、マネージャー業務（複数チームの組織運用のための業務）を行いながら、兼務状態で開発業務を行いました。
私と同じように、マネージャー兼、他の業務を行う方がいるかもしれないと思い、私が感じた開発現場への入り方のノウハウを書いておきます。

• 優先度判断
• 期待値調整

上記2点のノウハウになります。
この2つは今回のケースに関わらず、新しい環境で業務するときにしておくべきことですね。

○優先度判断

新しい業務を始める際、必ず何かが犠牲になります。リソースは有限であるからです。
今回は開発リソースを創出するため、既存の業務のリソースを減らすつもりでした。

ただ、人間は現状の業務品質を下げることに抵抗を感じるものだと思います。
どうにかして、今と同じ品質を保ちつつ、その上で新しい取り組みを行おうとします。
自分が今まで行ってきた品質を保つことに注目しがちになり、取捨選択が行えず、新規の取り組みが中途半端で、疎かになってしまう事が多いと思います。

既存の業務品質を維持する方法は考えつつも、時には、『選択と集中』することが必要なケースもあると思います。
私は、既存のマネージャー業務の品質を及第点まで落とし、新しく注力したい開発業務に集中しました。
（後々のマネジメント品質を上げるためと考え、長期視点でそういった判断をしました。）

○期待値調整

新しい方が業務に参加される際、その方がどのようなスキルセットなのか、期待値調整はしておくべきです。
そして、今回のようなケース、知らず知らずのうちに周りからの期待値が高まっている事が多いです。

これは、技術力だけの話ではないです。
課題発見力、コミュニケーション能力、情報収集能力、ロジカルシンキング、行動力、忍耐力、セルフマネジメント、計画力、推進力、探究力、表現力
他にもいろんな分野の能力があると思いますが、マネージャーはこれらの能力が全て高いわけではないです。

得意不得意がある中で、強みを生かしパフォーマンスを発揮している人が大半だと思います。
知らず知らずのうちに、期待が高まり過ぎていると、お互いの不満につながってしまいます。
どんな人間か知るぐらいの勢いで、期待値調整は行えると良いですね。

開発を離れたマネージャーが久しぶりに開発を経験し、得た効果

私はこの取り組みを行い、約1年ほどになります。
まだ、技術の取り組みをメイン業務として推進は行っていないため、価値の測定段階として途中経過のような状態です。
現状感じている効果を紹介します。

• 使用しているツールに関する理解の解像度が上がった
• ヒューマンマネジメントやプロダクトマネジメントと言った視点と組み合わせて判断ができる

○使用しているツールに関する理解の解像度が上がった

触った事がないツールに触る事が多かったのですが、わかりやすい例として、テストコードについて話します。

テストコードの理解度が増したことによって、以下の具体的なイメージができるようになりました。

• テストコードを書くことによるコストはどの程度かかるのか、どんな要件によってコストが上振れるのか
• テストが整備されている状態で防げた障害の数、障害によって影響する事業的なリスクの大きさ
• エンジニアが障害に対応するコスト、それに伴い遅れる開発、プロダクトや事業の優位性に対する影響

システム品質にもいろんな種類があると思います。
なんとなく理解していただけの分野が、この技術はどういった影響を及ぼすのかを解像度高くイメージできることができるようになりました。

そのため、大きい組織として取り組んでいる施策の価値も判断しやすくなりました。

○ヒューマンマネジメントやプロダクトマネジメントと言った視点と組み合わせて判断ができる

どういった部分でシステムのつらみを抱えているのか、チーム体制とシステム品質がどう関連するのか
プロダクトの優先度とシステム品質の優先度をどう判断すべきか

他のジャンルのマネジメントに活かせる知見が広がったと思います。

エンジニアリングマネージャーに必要な技術分野のスキルセットとは

最後に、エンジニアリングマネージャーがどの程度技術的な経験・知見を持つべきなのか、私の考えを書きたいと思います。
※私個人の考え方です。

極端なことを言えば『他者と連携することで、課題発見・解決をできる能力』が超高ければ、技術的な経験・知見は無くても良いと私は思います。
なぜなら、専門的な経験・知見は、あくまでも、課題発見や解決のため手段の一つであるからです。

とはいえ、自身の経験・知見から、課題発見・解決をできる方が適切な判断ができるに決まってます。
理想を言うと、開発技術以外も含め、自らが全ての分野の経験・知見を持っているのが完璧ですが、どの分野においてもそんな能力があるようなスーパーマンは存在しません。
大半の方は、各々の強みとなる分野の経験・知見を伸ばしていくしかないと考えます。

では、最低限と言う話で言うと、技術的な経験・知見はどの程度必要なのか？
私は『自らがコントロールして技術課題を発見できる環境が作れているかどうか』を基準として考えています。

その環境を作るために、大多数の人は、多少なりとも技術力が必要になってくると思います。
ただ、その必要になってくる技術力の深さはその人の『他者と連携することで、課題発見・解決をできる能力』によって、度合いが変わる印象です。

上記の能力がある人は、例を挙げると、
新しいプロダクトを作る必要がある際に、「どんな技術を使うのか。どんなデータを取り扱うのか。運用をどうするのか。他プロダクトとの棲み分けはどうするのか。事業成長を見越して、考えられた設計になっているのか。」
人と連携することで、いろんな角度から理解を深め、課題発見をする事ができると思います。

それを行うために、”抽象的なイメージだけの状態から深ぼって、課題発見できる人”もいれば、
”具体的なイメージを自分が持っていないと課題発見できない人”もいると思います。
あくまでも、課題発見・解決を行うための手段として、『技術の経験・知見』の必要性を考えれば良いのではないかと自分は思います。

まとめ

しばらく開発から離れていたエンジニアリングマネージャーが現場の開発に戻る時は、優先度判断と期待値調整をしましょう。
やってみた結果、今後のマネジメントに活かせるような能力を身につけることができました。（結果測定はまだなので、コスパなどは不明）
大半のマネージャーはある程度の技術力が必要であり、その程度は『他者と連携することで、課題発見・解決をできる能力』によって変化します。
最低限、達成しておかないといけない基準は、『自らがコントロールして技術課題を発見できる環境が作れているかどうか』 と考えています。