技術でリードするチーム作り - 理想と現実を往復した1年間の記録

ADWAYS DEEEでユニットマネージャー(以下UM)をしています、中村です。
先月でUMになってから1年が経ちました。自分のチームを作るために、時には前に出て技術的なリードをし、時にはメンバーの成長を促すために後ろに下がることもありました。その中で見えてきた大事なことや、UMとしての振る舞いについて書いていきます。

本記事の対象者としては、技術で意思決定するロール(テックリード)、およびプロダクトというよりはプラットフォームに向き合っているチームのエンジニアリングマネージャー(EM)を想定しています。

前提：所属するディビジョンの概要とエンジニアリングマネジメントについて

技術改善ディビジョン(以下技術改善Div)は、「挑戦するプロダクトチームのエンジニアの背中を支える」をミッションとしています。メインユーザーは社内のエンジニアですが、時には社外に影響する部分も担当します。既存サービスの保守・運用を通して全体をより良い状態にすることを目指しています。

このミッションには明確な期限はありませんが、手を付けないままにしておくと徐々に身動きが取れなくなってしまう領域であり、積極的に投資していくことが求められます。例えば、Perlのモダナイゼーションやクラウド移行など、モダンなアーキテクチャを実現するための前提となる部分です。自チームはこの中でクラウド移行を主に担当しています。

主な技術スタックとしてはIaC(Infrastructure as Code)とAWSで、サーバの構築・運用にAnsibleを、インフラのコード化にTerraformを使用しています。これらのツールを活用して、効率的なインフラ管理と自動化を実現しています。

また、エンジニアリングマネジメントには「4つのP」が求められるとされています。

参考: エンジニアリングマネジメントの「4つのP」

People、Platform、Project、そしてProductです。技術改善Divでは顧客のグロースサイクルを作るというより、その基盤となるプラットフォーム・アーキテクチャ刷新が主なスコープです。そのため、Productを除いた3つを意識しながらチームやプロジェクトを推進しています。

目指したこと

自分がUMになるにあたってどんなチームにしたかったかを振り返ると、以下の3つになります。

技術に興味を持ち、手を動かし続けるチーム

エンジニアの土台はなんといっても技術力です。越境してプロダクトやビジネスドメイン方向に進むとしても、AI Agentを活用していくにしても、技術力という軸足があってこそです。また、ただインプットするだけではなく、具体のアウトプットとして動くものを作り続けていく・考え続けていくことが大事です。

理想から逆算し、成果を追求するチーム

プロジェクトを回す立場になるとつい目の前の課題を小さく解いてまとまりがちです。しかし、理想から逆算することで初めて見えてくるものが多いため、それを踏まえて今回のプロジェクトの落とし所を見つけることが大事です。

個人の成長と組織成果を両立するチーム

一般に、プロジェクトの成果を追求することとメンバー育成は相反することが多いです。
強いメンバーでガッと進めればプロジェクトは進みますが、チームメンバーは育ちません。一方で、メンバー育成ばかりを優先してしまうと、プロジェクトの進捗が遅くなってしまいます。
そのため、プロジェクトの進捗とメンバー育成のバランスを取ることが重要です。

やったこと・UMとしての振る舞い

目指したことを実現するために自分が行ったことのうち、特に重要なものを書いていきます。

技術が大事というメッセージを発信し続ける

「技術が大事！」と言い続けるだけでは心許ないので、具体的な取り組みを通じてその重要性を示しました。

朝会での記事共有
- 朝会で昨日やったことや学んだことを共有してもらっていますが、それとは別に技術系の記事をslackのスレッドに書いてもらっています
スキルマップの作成
- 四半期(Q)ごとにチームのプロジェクトで使った具体的なスキルを洗い出し、それに対する評価を4段階で書いてもらっています
勉強会
- AWSのre:Inventやオンラインで見られるセッションをチームでもくもく視聴して、その後チームに活かせそうな部分はないか議論しました
- AWSとかは特にチームで結論を出した一週間後にちょうどいいソリューションが発表されたりするので、キャッチアップも大事です
チーム内LT
- チーム内で興味のあること(技術・仕事関連)を発表してもらう時間を不定期で設けてます
- 希望制なので毎月ではないですが、多い時は月に2回ほどやったりもします

その他個人では以下のことを行いました。

PR読む、コードレビューする
- 手を動かす時間は限られていますが、どんなに忙しくてもチームから出たPRは全て読むようにしています
- 余裕がある時はチームが触りそうな関連リポジトリもざっと読んだり、理解が怪しかったり深掘りたい部分のドキュメントを読む時間を確保して読みます
  - 前者はバッティングを未然に防ぐ・キャッチアップするためなので軽くてokで、後者はエンジニアとしての基礎体力を落とさないためにしっかり行います
背中を見せる
- チームの人が何日も詰まってそうな問題があったら、自分が直接手を動かしてプロジェクトに介入することで「なんとかする」姿を見せるようにしています

解決策を短期と中長期に分けて考える

チームの振り返りやプロジェクトを進める中で出てきた問題で議論がワッと盛り上がった後そのままになることはありませんか？

参考: 何かを変える際は絶対に独断はしない

そういう時は一旦その場は切り上げて、別議論の時間をしっかり取るようにしています。メンバーや組織にとって大事にしているものが隠れていることが多いからです。
ちゃんと前提や理想状態(：中長期)について認識を合わせた上で、プロジェクトのスコープとしてどこまでやるか(：短期)の落とし所を見つけます。その上で、チーム外ともきちんと合意形成を行います。コストをかけてもいい部分だと思っているので、時間は決めた上でしっかり議論します。
あまりに議論が長引くものやそもそも問題として大きいものは、UMとしてえいやで決めてしまったり、別プロジェクトとして切り出して判断を遅らせることもありますが、基本的にはメンバーの意見も聞いた上で判断をしています。

メンバー育成について

メンバー育成もUMの役割の一つです。メンバー一人一人の特性やフェーズを認識し、それに応じた育成を行うことが大事です。

具体的には以下のようなことを行いました。

期待値をまず最初にしっかり伝える、定期的に振り返る

新卒はチームjoin時、それ以外のメンバーには個人目標(以下個人OKR)面談の時にきちんと期待値を伝えました。

例えば新卒には「マインド面で積極性と素直さを意識してほしい」ということや、リードエンジニアには「メインプロジェクトの単なる遂行にとどまらずより早く進めるには？を考え続けてほしい」など、役割に応じた期待値を伝えました
期中の面談で細かく確認はしつつ、期末の締めの時に期待値を満たせていたか？を改めて確認します

また、チームとしてはドラッガー風エクササイズを行い、自己紹介的な部分に加えて「自分が期待されてると思っていること」「自分が周りに期待すること」を各メンバーから各メンバーへ伝え合うことで、期待値をすり合わせました。

巻き取りすぎず、転ぶ前提で任せてみる

UMとして仕事を進めていると、ここは自分でやってしまった方が早いのでは？と思う場面もあります。
メンバーが技術的に詰まってプロジェクトが遅くなってしまったり、チームとしての大事な意思決定など、どの場面でどの程度やるべきかは毎回異なるため都度判断をしています。

自分なりに意識していることは以下の通りです。

委譲・関与・介入を使い分ける
- 委譲：特定の業務や権限を完全にメンバーに任せる
- 関与：基本はメンバーに任せるが、必要に応じてアドバイスやサポートを行う
- 介入：問題が発生した際、自分が直接介入して解決を図る

特に移譲か関与か迷うことはよくありますが、メンバーのやる気次第でチャレンジングだと思っても委譲してみたり、最初は関与から始めて徐々に委譲スタンスに移ったりと、状況に応じて使い分けています。

説明責任に部分的に巻き込む

前提として、UMには説明責任があります
- 主にプロジェクトが想定より遅れた時、早まった時などです
しかし、説明材料について一番理解してるのは現場で手を動かしているメンバーであることが多いです
- そのため材料になりそうなものは一通りメンバーから出してもらいます
自分の理解をきちんとすり合わせておくことが大事です。場合によってはメンバーに逆に教えられることもあります
- 特に1日会議が連続してチームの状況が追えてない時などは、素直に「分からない」と言って教えてもらっています

常に準備しておく

チームやプロセスのあり方として理想は何か？みたいな部分は定期的に考え続け、チームに伝える必要があります
他にも主に新卒向けですが、チームのプロジェクト以外でインパクトの大きい案件や、設計から実装まで丸ごと経験できる案件は貴重なので新卒用案件として準備しておきます

得られた成果・変化

目指したチーム像に対して、どの程度満たせたかを振り返ります。

技術に興味を持ち、手を動かし続けるチーム

ここは比較的満たせているかなと思っています。

個人OKRとスキルマップの連動

個人OKRを決める際や振り返る際、具体的な技術として「前の四半期ではAmazon Athenaで基本的なS3のデータを見れるようになった」などの会話が出てくるようになりました。また、「Apacheは動いてはいるもののバージョンが古いものがある」など技術を軸にした改善候補・提案を出してくれた人もいました。

社外の勉強会への参加

自分自身、昨年までは半年に一回くらいの社外勉強会への参加でしたが、UMになってから二ヶ月に一回は参加するようになりました。印象に残ったセッションや学び・使えそうな技術もチームに随時共有しています。
また、チームメンバーも勉強会に参加し、学んだことを共有する文化が根付いてきました。

理想から逆算し、成果を追求するチーム

ここは正直道半ばですが、以下のような変化はありました。

意思決定プロセスの民主化

「この問題は決めでいきましょう」「この問題は今は判断せず、xxxが決まってからやりましょう」のような言葉が、議論の中でメンバーから出てくるようになりました。これにより、チーム全体での合意形成が進み、プロジェクトの進行がスムーズになりました。

期待値を意識した自主的な行動

チームのコアタイム以外でも、メインプロジェクトの障害になりそうな部分の先行調査をメンバー同士が自主的に時間を決めて行うようになりました。解決までいかなくても事前の調査で解像度が上がるため、チームが取り組む際により具体化された状態でプロジェクトが進められるようになりました。

個人の成長と組織成果を両立するチーム

これも比較的満たせたかなと思います。

新人王

24卒の山本くんは昨年の新人王に輝きました。チームで用意した案件を通じて調査・設計〜実装までを経験し、技術力を大きく向上させました。彼の成長はチーム全体にとっても大きな励みとなっています。

IaC部分のCI/CD基盤の確立

Ansibleについては以下の記事をご覧ください。

参考: 長年塩漬け状態にあるAnsibleの運用から脱却するためのCI/CDパイプライン構築

Terraformについてもdrift detectionの仕組みを導入し、週に一回通知しています。コードと実体の差分が出た場合は、チームの誰かが対応するようにしています。これにより、インフラの状態を常に最新に保つことができ、運用の効率化を図っています。

クラウド移行プロジェクトの順調な推進

年内にオンプレミスサーバの撲滅が見えてきました。また、単なるクラウド移行にとどまらず、CodeDeployを使ったデプロイフローの改善などクラウドシフトを狙える部分は積極的に狙っています。

課題と今後の展望

まずはクラウド移行を完遂させることが最優先です。今まさに行なっているプロジェクトで実装が膨らんでいるため、自身の介入という手段もうまく使いながら、プロジェクトを推進していきます。

次に、意思決定プロセスを民主化したことで逆に議論が白熱することも増えたなと感じています。それぞれが意見を持っているため議論が活発になるのは良いことですが、時には決めるべきところで決められずに時間がかかってしまうこともあります。この辺りは時間を区切ったり、何か基準や観点を明確にすることで、よりスムーズに進められるようにしたいです。

また、プロダクトチームとの連携が薄い点も課題として認識しています。
背景として、プロダクトチームとのスキルセットの違いがあります。
クラウド移行は主にインフラ・サーバ関連を触りますが、プロダクトチームはフロントエンドやバックエンドのアプリケーション開発が中心です。技術的な関連性は薄いです。
そのため、まずは接点を増やすことでお互いの理解を深めることが必要だと考えています。

最後に、理想を掲げ続けることです。
チームの文化として技術に明るくあるべきという思想は伝えられたものの、それを具体的なプロジェクトで実践・啓蒙する部分がまだ道半ばです。
そのため、定期的に振り返りの場を設け、自分たちの理想を再確認し、次の一手を打ち続ける必要があると感じています。

UM2年目も頑張っていきます！！