SIerのエンジニアを悩ませるのが「いずれ開発をやめてマネジメントに進むのか」というキャリアの分かれ道です。
コードを書きたいエンジニアからすれば、マネジメント業務をやっていくことに抵抗があるかもしれません。実際に会社からマネジャーへの転向を求められて、開発を続けるために転職を選んだ人も少なくないでしょう。
ネイティブ広告配信プラットフォームを提供するログリー株式会社で、開発グループ主任を務める田中玄伍さんも、SIerでキャリアを積んだのち「マネジャーになるよりもコードを書き続けたい」という思いで同社に入社されました。しかし現在は開発チームのリーダーとして、チームマネジメントやメンバーの育成に注力されています。
コードを書きたくて転職したエンジニアが、なぜチームマネジメントをするようになったのか。現在のポジションに至るまでの思いや、SIerでの業務を経験したからこそできるマネジメントや若手の育成についても解説していただきました。
コードを書き続けるエンジニアでいるためにSIerからログリーへ
――最初に田中さんがログリーに入社されるまでのキャリアについて教えてください。
田中玄伍氏（以下、「田中」）：前職はSIerで、開発メンバーとしてコードを書いたり、プロジェクトマネジメントに関わったりしていました。転職のきっかけは、10年ほど勤めてきて今後のキャリアを考えたときに「これからもコードを書いていたい。プロジェクトマネジメントがメインの仕事になってしまうのは嫌だ」と思ったことです。もちろんログリーにも、開発チームのメンバーとしてコードを書いていくつもりで入社しました。
前職では、プロジェクトマネジメントの経験はありましたが、チームマネジメントをしたことはありませんでした。それもあって自分がいずれリーダーとしてエンジニアチームをマネジメントしたり、新人を育成したりするポジションにつくなんて、当時は思ってもいませんでしたね。
――入社後、マネジメントに携わることになるまでの経緯も伺えますか。
田中：入社して一年半くらいで初めてチームリーダーになったのですが、それまではチームのメンバーとして手を動かしていました。この期間にわたしの中で大きな心境の変化が2つ起きました。
まずメンバーとして働く中で、向き・不向きと言いますか、自分自身のエンジニアとしての適性の限界に直面しました。「コードを書き続けたい」と意気込んで30代で転職してきたものの、周りのエンジニアや若手の中には、ものすごく優秀な人たちがたくさんいました。彼らを見ているうちに「自分ががむしゃらにがんばるよりも、メインの開発業務は彼らに任せて、それ以外の仕事を担ったほうが大きな成果につながるだろうな」という考えが大きくなっていきました。
もちろんコードを書くのが好きで転職してきたので、彼らとの差に悩んだこともあります。若くスキルもあるエンジニアがどんどん増えてくる中で、「自分は何をやっているんだろう、もっとがんばらねば」と思ってやっていました。ただ、本当に優秀なエンジニアというのは、がんばっても追いつけるようなレベル感ではありません。そんな中で「今後、自分が第一線のエンジニアを目指して働き続けるのは難しいのではないか」と思うようになりました。
もうひとつは、当時のチームリーダーが退職して、わたしがチームマネジメントや育成の業務を引き継いでみたときに「こっちのほうが合っているかもしれない」と手応えを感じたことです。加えて、ログリーには技術志向のエンジニアが多く、マネジメント志向の人は非常に少ない状況でした。ここでわたしがマネジメント職にキャリアチェンジすることで、自分の市場価値向上と、会社への貢献を両立させられるのではと考えました。
若手のチームを任され、すぐに取り組んだ教育体制の強化
――実際にマネジメントに携わるようになって、注力されていることはなんでしょうか？
田中：わたしのチームで扱っているプロダクトはサービス開始から約10年と社内でも歴史が古く、仕様も複雑でメンテナンスの難しいシステムになっています。その上メンバーは入社3年未満の若手が多く、営業メンバーにシステムの仕様を聞かれても即答できないような状況が続いていました。
そこで取り組んだのが教育体制の強化でした。具体的には3つのことに力を入れていきました。
はじめにドキュメンテーションです。わたしが入社した当時、開発ドキュメント類はほとんど整理されていない状態でした。誰かに聞かなければわからない情報が多く、たとえ資料が残っていても更新されていなかったり、断片的な情報しか書いていないケースがほとんどでした。そこで、ドキュメント整備を始めることにしました。文書作成にも工数がかかりますので、費用対効果が高そうな情報から優先で資料化していきました。まずはシステムの全体概要。新しく参画したメンバーでも「このシステムがどんなものか」をつかめる資料を作り、新メンバーには必ず読んでもらうようにしました。
また、古いメンバーしか知らない属人化している知識や、みんなが詰まりやすい場所の情報などを集めて、四択問題＆解説集も作りました。入社当時の自分が「こういうのがほしかったんだ」と思えるようなものを目指して、徐々にドキュメントを増やしていきました。
――人によるかもしれませんが、エンジニアの中にはドキュメント作成が苦手な方も結構いらっしゃるイメージです。田中さんはあまり苦にならなかったほうですか？
田中：そうですね。ドキュメンテーションについては、前職での経験が生きているのかもしれません。SIerの場合、ほとんどのプロジェクトでシステムの概要図やサーバ構成、機能仕様書などが資料としてそろえられています。新規参画者はそれらを読み込めばシステムの概要や開発の流れが一通りつかめるようになっています。こうした状態を今のチームでも実現したいですね。今でも100%網羅できているわけではないですが、新しく入った方が迷子にならないレベルのドキュメントはそろえられたかと思っています。
ふたつめに、調査やトラブルシューティングのタスクに対して複数人で取り組み、徹底してノウハウ共有するようにしたことです。
わたしのチームでは開発だけでなく、トラブルシューティングが必要になる場面が少なくありません。たとえば広告を配信する設定をしているのにうまく表示されない、広告のクリック数が記録されていないから調べてほしい、顧客から技術的な質問が来たけど答えがわからない、などです。こうした問い合わせが週3、4件ほど寄せられます。
以前はチームの誰か一人が調査や返答の対応をしていたのですが、一人で対応して解決しても、どんな調査をしてどうやって解決したのか、どこに何の情報があったのかといったナレッジが共有されず、属人化が進んでいました。ここを若手メンバーに任せれば、こうしたトラブル対応は多くの学びが得られるよい機会になると考えました。
最初はチームメンバー全員で問題を解決するようにしました。問い合わせが来たら、まずメンバー全員で集まって、全員で問題を解決する。もちろん効率は悪いので、どんな開発チームでも使える技ではありません。ただ、当時のチームにはわたしと1年目・2年目の若手しかいない状態だったため、とにかく情報共有をしあって、メンバー全員の知識量を増やすことを優先しました。
――育成という観点で、効率よりもメンバーに経験を積んでもらうことを選んだのですね。
田中：はじめのうちはそうでしたね。最近は人数も増えて各メンバーの知識量もかなり増えてきたので、当番制にして、担当者が困ったときなどに集まる形になっています。
これに限らず、リーダーとして「チーム全体に情報が伝わるようにする」のをずっと意識して心がけています。一人でできることには限界があるので、なるべく多くのメンバーがいろいろなことをできるようにしていきたいですね。みんなで成長していかないと、巨大で複雑なプロダクトには立ち向かえないですから。
最後の３つめは、社内のSlackでチーム版のtimesを導入したことです。一人1スレッドを使って、作業内容や仕事中の悩みなど、とにかくなんでもつぶやきまくってもらっています。「これからこのコマンドを打つぞ」「ここのコードの意味がわからない」みたいな独り言を、みんながつぶやいていくんですね。これでどんなメリットがあるかというと、誰がどこで詰まっているかを周りがすぐに把握して、リアルタイムで助けられるんです。逆に育成目的で取り組んでもらっているときは、あえて放置して自分で考えてもらったり、ヒントだけ与えたりといった対応もできます。
リモートワークでも若手の状況を細かく把握して育成するためには、Slackがかなり活用できます。新人でも臆せずどんどんつぶやいてもらうようにしているので、最近では追っていくのがしんどいくらいです（笑）。
ビジネス側との距離を近づけるための取り組み
――経験の浅いエンジニアをいかに早期に戦力化するかは多くの企業での課題でもありますね。そのほかに力を入れていることはありますか。
田中：これも多くの会社で悩む課題だと思いますが、開発チームとビジネス側との距離をどう縮めるかですね。
以前はやや距離があったというか、「システムが実際にどう使われているか」をエンジニアがあまり把握できていないなと感じていました。わたし自身、入社したばかりの頃はシステムについて「開発しているのに、どうやって使われているのかよくわからないな」と思う場面が多くありました。
これを解決するために、ビジネスメンバーの定例の打ち合わせにエンジニアも参加させてもらったり、お金の流れなどのビジネス側の知識を得るための勉強会を開いたりしました。徐々に開発チームもビジネスの理解が進んでいって、今ではより解像度の高い開発や提案ができるようになってきたと思います。
――田中さんはもちろんだと思いますが、メンバーも積極的に理解を深めたいという気持ちがあったのでしょうか？
田中：ログリーの場合、自分の価値を提供したい、人のために何かしたいという考えが強いメンバーが多く、ビジネス側の勉強をしようという流れを作ることができました。エンジニアでもビジネスを理解すれば、より解像度の高い開発ができるようになるし、それでみんなが喜んでくれたらうれしいよねといったマインドが醸成できているのだと思います。
採用や組織づくりにも携わるエンジニアリングマネジャーに
――マネジャーが初めてとは思えないくらい、着実に組織の課題解決を進められていますね。最後に、今後のキャリアについてのお考えも教えてください。
田中：今後はマネジメント業務の質をもっと高めて、エンジニア組織をよりよいものにできるエンジニアリングマネジャーになりたいと思っています。今のわたしはどちらかというとリードエンジニアに近いポジションで、まだまだ胸を張って「エンジニアリングマネジャーです」と言える状態ではないと思っています。今後は採用や組織設計、制度設計などにもかかわっていきたいですね。
そのためには、まだまだ自分自身に課題を感じる部分もあります。まずは技術力ですね。プレーヤーとしての技術力というよりは、メンバーの育成やサポートのために幅広い知識が必要だと思っていて、そこはまだ足りないと感じています。あとはマネジャーとしての意思決定の質をもっと磨いていきたいです。
SIerのエンジニア組織と自社開発のエンジニア組織はミッションが全然違うので、SIerでの経験だけでなく、自社開発での事例などももっと情報収集していきたいと思っています。他社でエンジニアリングマネジャーやリーダーをされている方とのコミュニケーションも増やしたいですね。組織をよりよくしていくにあたって、さまざまな事例や解決策の引き出しを増やしておきたいと思います。
