チームで越えるから面白い。エンジニアリングマネージャーが語る成長と信頼とは

こんにちは！25卒イノベーションに入社した東航平です！入社して間もない私ですが、今回、現場でバリバリ活躍されているエンジニアリングマネージャーの田中さんにインタビューする機会をいただきました！

「信頼されるってどういうこと？」「マネージャーって何してるの？」そんな素朴な疑問から、イノベーションのカルチャーや、マネージャーの本音まで、ぐいぐい聞いてみました。

ーこの記事は新卒の視点から「働く」のリアルをお届けします。ー

この記事でわかること

エンジニアリングマネージャーの実際の仕事
信頼される人に共通する姿勢や、チームで任されるということ
「働く」を変えるという理念が、マネジメントや組織にどう生きているのか
イノベーションのエンジニア組織の雰囲気やカルチャー

田中洋平さん / エンジニアリングマネージャー

出版社の営業職として社会人キャリアをスタート。長年にわたり営業の現場を経験した後、30歳を過ぎてからエンジニアの道へ未経験で転身。受託開発からスタートし、金融や終活といった領域での自社プロダクト開発を経て、開発・マネジメントの両面で経験を積む。2024年4月、イノベーションにエンジニアグループマネージャーとして入社。現在は組織づくりの中心的な役割を担う一人となっている。

Q. イノベーションに興味を持ったきっかけや経緯をお聞かせください。

前職では、会社全体のシステムを刷新するような大規模プロジェクトに関わっていて、PMOとして立ち上げから技術リードや全体のプロジェクト管理の役割を担っていました。そのプロジェクトが一段落したタイミングで、現在の上司から声をかけてもらったことが入社のきっかけです。マネージャーがまだ少ないフェーズの組織で、コアメンバーとして組織づくりに関われる環境に魅力を感じ、入社を決めました。もともと、エンジニアがより良く働ける環境を整えるような“組織づくり”に関わっていきたいという思いがあったので、それが実現できる場所だと感じたのも大きかったです。

Q. GM(グループマネージャー)としてどんなプロダクトを扱っていますか？またチーム構成についても教えてください。

私がGMとして担当しているのは、業界最大級のIT製品比較サイト「ITトレンド」です。企業の情報収集や選定に使われるサービスで、当社の中でも中核を担うプロダクトですね。昨年立ち上げに関わった新サービスなど、ITトレンドブランドの関連プロダクトも各種担当しています。

それぞれのプロダクトや、ITトレンド開発に関連する各種プロジェクトの開発チームがありつつ、相互に連携したり状況やプロジェクト内容に合わせて柔軟にチームが組める構成になっています。

Q. そうした組織設計には、どんな狙いや工夫があるんでしょうか？

現在、エンジニア組織は大きく分けて3つの開発部門に分かれています。ひとつがメディア開発、次にSaaS開発、そしてもうひとつがインフラや共通基盤を担当するプラットフォームの部門です。その中でさらにチームが分かれているのですが、特徴的なのは、プロダクト名をそのままチーム名にしていないことです。例えば「ITトレンドチーム」のようにチーム名をプロダクトに紐づけることで、人が固定されてしまったり、動きにくくなってしまう場合もある。そこで、「メディアディベロップメント」など、プロダクトに縛られない名前をつけて、状況に応じてメンバーを柔軟に動かせるように設計しています。

もちろん、これがベストな形とは限りませんし、今後の組織の成長やプロダクトの変化によって、また形を変える必要も出てくると思っています。常にその時の要件に合わせて、最適なチームの形を考えていけるようにしていきたいと思っています。

Q. マネージャーの視点から「こんな人に仕事を任せたい」と思うのは、どんな人ですか？

もちろん、信頼できる人というのは大前提としてあるのですが、それ以上に積極性やオープンさを持っている人は、より機会を得やすいと思います。ただ一方で、そういったことが得意ではない人もたくさんいます。だからこそ、頑張って一歩踏み出そうとしている人を見つけて、チャンスを提供すること、そして、オープンに話すのが苦手な人に対しても、自然と声を出せるような場をつくることが、マネージャーの役割だと思っています。

「この人になら任せたい」という視点もありますが、それ以上に、誰にでも任せられるような環境を整えていくことの方が、私にとっては大切です。

Q. チームづくりを進める中で、マネージャーとしてやりがいを感じる瞬間や、難しさを感じる場面はありますか？

やりがいで言うと、自分一人で開発しているわけではないので、チームで何かをやり遂げたときの達成感が一番大きいですね。例えば、自分が一人で取り組んだとしたら時間がかかるような、難易度の高い開発でも、チームで協力して取り組むことで、より早く、より良い形で仕上げられる。そういう瞬間に、マネジメントの面白さを感じます。

一方で、難しさももちろんあります。というのも、自分一人ではコントロールしきれない要素が多いんですよね。例えば「この日までにリリースしなければいけない」となった時に、メンバーそれぞれのスキルや状況を考慮すると、どうしても間に合わないかもしれない……ということもある。自分一人で頑張ればどうにかなるという話ではないので、その調整やバランスを取るのが難しい部分です。とはいえ、そこをどうにかするのがマネージャーの役割でもあると思っています。難しければ事業部とすり合わせて調整したり、「こういうふうに進めた方がスムーズは？」という提案をしたり。チームがより良く動けるように、計画策定や体制構築の部分でもサポートしています。

Q. 短期的, 中長期的にマネージャーとしてやっていきたいことはありますでしょうか?

短期的には、開発体制の整備に注力しています。

これまでは新規プロダクトの立ち上げに携わってきましたが、今年の4月からは「ITトレンド」全体のマネジメントを担うことになりました。ITトレンドは当社で最大規模のプロダクトなので、安全に開発・公開できるように、ルールや体制の見直し・整備を改めて進めているところです。

中期的には、メンバーが「ITトレンドを担当していて楽しい」と思えるチームづくりを目指しています。

キャリアを考える中で、例えば「そろそろ別のプロダクトも経験したい」と思うことも自然だと思うんですが、むしろ「ITトレンドって面白いよね」「あそこに関わってみたい」と言われるような魅力ある環境にしたいです。そのために、技術的なチャレンジの機会を作ったり、成果の可視化や社内ユーザーからのフィードバックがしっかり届く仕組みを整えたり、「頑張った分だけ手応えがある」状態をつくることを意識しています。

マネージャーとしては、新しい技術の導入や技術的負債の解消といった意思決定も含めて、他部門との調整や現場の声の吸い上げにしっかり向き合っていきたいと思っています。

長期的には、組織全体として、エンジニアの満足度を上げる仕組みを作っていきたいです。制度やコミュニケーションの設計などを通して、「この組織で働いていてよかった」と感じてもらえるような環境づくりを、時間をかけて丁寧に行なっていければと考えています。

Q. イノベーションの「働く」を変えることは、チームマネジメントや設計にどう影響しているのでしょうか?

メンバーが働いている状態を想像しながらエンジニア組織を設計しています。自分がこうだったらいいのにとか、メンバーが思う”こうあるべき”を踏まえて、変革するということも含めて「働く」を変えていっていると思います。例えば、既存がこうだからこうしかできないとか、そういうのをなくして、あるべき姿を考えたいと思っています。実際にここ一年の事例だとエンジニアの育成のためにUdemyのライセンスだったりAWSのSandboxの環境を付与したりと、これまでになかった制度を生み出すことができているので、働いている姿を想像しながら変えるっていうところを含めて設計しています。

Q.「働く」を変えるという理念を感じる瞬間は業務中にありますか？

「働く」を変えるという理念には、「今あるものを前提にしなくてもいい」「変えていいんだ」というメッセージが込められていると感じています。たとえば、目の前のやり方や仕組みを「そういうものだ」と受け入れるのではなく、「もっと良いやり方があるんじゃないか」と考えて提案していける。そんな柔軟な姿勢を肯定してくれる考え方だと思うんです。

もちろん、組織そのものを自分ひとりの力で変えるのは簡単ではないですが、日々の進め方を工夫したり、チームの中で新しい提案をしたり、そういった積み重ねも「働く」を変えることにつながっていると感じます。

Q. エンジニア組織としての特徴や、文化の面で印象的なことはありますか？

私が感じる当社のエンジニア組織の特徴は、とにかく風通しが良いことです。これは私が入社する前から自然とできあがっていた文化で、誰とでもフラットに話せる雰囲気があります。制度としても、1on1の仕組みやSlackなどのテキストでのやり取り、Meetで気軽に話せる環境など、コミュニケーションの取りやすい環境が整っているのも特徴のひとつです。

Q. 風通しの良さがある一方で、「言いづらいこと」まで話せる関係を築くには工夫も必要だと思いますが、意識していることはありますか？

「言いづらいこと」を言えるようになるには、まずは“言ってもいい場”を用意することが大事だと思っています。入ったばかりのメンバーが「この設計ちょっとおかしくないかな」と思ったとしても、それをいきなり全体に言うのは難しいですよね。なので、例えば新しく入った人の新鮮な意見を取り入れるためのSlackチャンネルを立ち上げるなど行なっています。そこでは「他の人は見てないから、思ったことを書いていいよ」と伝えることで、少しでも意見を出しやすくなるように工夫しています。

「言っていい空気」を作ることが信頼の第一歩になると考えています。

Q. 風通しがよく、意見を出しやすい関係性があるからこそ、信頼関係の深さも大切になってくると思います。チーム内で信頼を築くうえで、意識していることはありますか？

信頼を築くうえで大事にしているのは、「嘘をつかない」「誤魔化さない」という基本的なことです。エンジニアの仕事では、不具合などの問題が起きることは避けられません。だからこそ、何かあったときは早く共有して、早くリカバリーする・再発防止の体制をしっかり組む、など、その積み重ねが信頼を生むと思っています。

もちろん、自分のミスは言いづらいものです。でもそこを隠さずにオープンにしていく。失敗を素直に伝えることで、かえって信頼が深まる場面も、これまでたくさん見てきました。

エンジニアリングの現場では、時に「予期せぬトラブル」が生まれることも少なくありません。大切なのは、それをどう共有し、どう乗り越えるか。

そのためにも、風通しの良い空気や話しやすい関係性は、常に意識しています。