はじめに
このエントリーは with Advent Calendar 2025 の 2日目の記事になります。
こんにちは。株式会社 with でエンジニアリングマネージャーを務めております、@kenichi_ta と申します。
私は 2025 年 3 月から with のエンジニアリングマネージャーとして入社しました。現場からの昇格ではなく、入社当初からマネージャーとしてジョインしたので、正直なところかなりのプレッシャーはありました。「何か変えてくれるのでは？」という期待を向けられつつ、自分は組織のことを何も知らない状態でスタートラインに立つことになるためです。
この記事では、そのような状況で私自身が最初の 100 日間をどう過ごしたのか、何を意識し、何をあえてやらなかったのか、何をやれなかったのかを振り返ってみたいと思います。
入社前に考えていたこと
入社前に「EMとして最初の 100 日をどう過ごすか」を考えるにあたって、特に参考にしたのが次の 2 つの資料でした。
最初の100日で何をすべきで何をすべきではないか？
（元ヤフー社長、現東京都副知事の宮坂さんのNote）
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
（「スクラムの拡張による組織づくり」の著者である粕谷さんの登壇資料）
この 2 つで共通して紹介されている宮坂さんの文章があります。
最初の100日でもっともしてはいけないことで共通するのが「華麗にビジョンを語り戦略を策定して期待値をあげること」はしてはいけない。逆に最初にすべきことはなにか？「勉強マシーンになること。具体的には資料を読み人に会って話を聞きまくる」こと。つまり最初の100日は「口はほどほどにして耳と目と足を動かせ」ということだ。
（粕谷さんの登壇資料の中では、宮坂さんの記事からの引用として紹介されています）
この一節を自分なりに噛み砕くと、だいたい次のような意味になります。
-
情報が不足している状態で判断してはならない。
まずは徹底的に情報を集めることから始めるべきである。 -
早い段階で壮大な戦略やビジョンを語るべきではない。
組織の期待値だけが不必要に上がり、あとで失望を生む。 -
「現場を知らないまま改革を進めるタイプ」と認識されると致命的である。
一度「わかってないのにしゃべる人」というレッテルが貼られると、本音の情報が入ってこなくなる。
マネージャーとして入社するということは、多かれ少なかれ「変化を起こすこと」を期待されている状態です。しかし、そこで焦ってビジョンや戦略を掲げ「自分は仕事している感」を出そうとしてしまうと、むしろ組織の足を引っ張ることになりかねません。
そこで、まず最初の 100 日については「耳と目と足をフル稼働させる」期間としよう、とあらかじめ計画していました。
入社1週目：期待値調整とひたすらインプット
まずは役割と求められる成果の言語化
着任して早々に行ったことは「自分に期待されていることを正しく定義すること」でした。
エンジニアリングマネージャに求められていた役割は大きく次の2点になります。
- エンジニアチームの包括的なマネジメント
- 開発に関する意思決定に広く関与し、成果に責任を持つ
ここには、ピープルマネジメント、開発生産性向上、組織連携など、かなり幅広い責務が含まれています。まずは経営陣や既存のリーダー陣と会話を重ね、そこから求められる成果を言語化していきました。
これは組織のためというよりは、まずは信頼を獲得する意味合いが大きい取り組みでした。期待値が曖昧なままでは「何でもやります」というスタンスになりがちで、（なんとなく）結果的に期待された成果とは違った振る舞いをしてしまいます。自分の守備範囲を明確にし、守備範囲から外れる場合は他のメンバーと協調することを前提とする、ここを整理したことで、自分自身のプレッシャーを軽減させることができたように思います。
読める限りのドキュメントを読み漁る
次に取り掛かったことは、ひたすらインプットをすることでした。
弊社のプロダクト開発に関する情報の多くは、ConfluenceとGoogle Workspace に蓄積されています。既にリリースされた企画や開発のプロセス、仕様、事業計画や週次資料など、読める権限のあるものは可能な限り読み漁りました。Slackの過去ログも、自分の役割とは関連が薄そうに見えるチャンネルも、できる限り目を通すようにしました。
もちろん、このような短期間で会社の全体像を理解することは不可能です。それでも、入社直後に一度「全体を眺めてみる」ことには大きな意味があると考えます。これまでの検討の経緯、議論されてきた論点、たびたび登場するキーワードをつなげていくことで「この会社の成り立ち」が少しずつ立体的に見えるようになりました。
2週目〜：組織とメンバーの現在位置を知る
ドキュメントを読み漁ることも重要ですが、それだけではチームを理解したことにはなりません。次に取り組んだのは、エンジニアチームメンバー全員との1on1でした。
現場のエンジニアは組織のコンディションをリアルに感じ取り、重要な問題について把握しています。対象者のコミュニケーションスタイル、直近の困りごと、働き方の希望など伺いながら、可能な限り聞き役に徹し（あれで？と言われそうですが）、「困ったときに相談してくれる」話しやすいEMであることを第一歩目と心がけました。
また、入社直後に行われたオフラインのイベントでは「誰が誰か分からなくて当たり前」という前提で、多くの人に話しかけました。オンラインでは見えづらい、ちょっとした空気感や温度感、チームを跨いだ関係性など、所謂「肌感」というものを感じられたのは良い収穫でした。
1ヶ月〜2ヶ月：開発プロジェクト参加と課題の整理
入社して1ヶ月が経ったところで、新規プロジェクトに PjM として参加することになりました。これは予定されていたものではなく偶然からのアサインでしたが、結果的に非常に幸運な出来事でした。
このプロジェクトは、既存のプロダクトとは文脈が異なりつつも、技術的な流用は可能というやや特殊な位置づけでした。そのため、
- 既存プロダクトの技術スタック・アーキテクチャ
- 意思決定プロセス
- 企画・デザイン・マーケとの連携
といった情報を「プロジェクトの外側の視点」と「実際に中に入ってみての視点」の両方から把握することができました。
このタイミングにエンジニアチーム以外の組織とのつながりを持つことで、各組織のコンディションや課題も浮かび上がってきます。自分の役割を再整理しながら、「早く手をつけるべき問題」と「時間をかけて取り組むべき問題」を分けて整理するようにしました。
3ヶ月目：小さく始める
組織の全体像が見えてきた2ヶ月を過ぎたあたりから、ようやく「これは早めに手をつける方がよさそう」と判断できたものについて小さく動き始めました。ここでいくつかを紹介します。
開発リソース配分の簡易的な可視化
どのプロジェクトにどれくらいの時間を割り当てているのか、代わりに何ができていないのかについて定量的な情報が十分に得られていない状況でした。これでは、どのタスクを優先するかの議論が空中戦になり、適切なアサインの意思決定が難しくなります。
そこで、大雑把に「工数を把握する」仕組みを整え、開発リソースの配分や優先順位付けの意思決定をするための土台を整えました。意思決定のプロセス自体はこれらの情報が整ってから取り組みました。
情報流通の仕組みづくり
また、何かを解決する前段階として、エンジニアチーム間の情報流通を整えようと考えました。施策としては「エンジニアリーダー定例」の設置と「エンジニア勉強会」の開催です。
エンジニアリーダー定例は、プロダクト開発におけるエンジニア固有の課題を共有し、議論を重ねながら解決に導くための場として設定しました。
エンジニア勉強会は、技術領域を超えた横断的な技術・知識の共有やエンジニア相互のコミュニケーションの活性化を目的として、定例ミーティングとは少し温度の異なる「緩やかな情報流通の場」として用意しました。
100日経って：プロダクトリリースと連携パス構築
こうした組織の基礎的な取り組みと並行して、PjM として関わっていたプロジェクトではプロダクトのリリースを迎えました。
企画・マーケティング・デザインチームといった他職種のメンバーと連携を通し、要件定義からリリースまでの一連の流れを実際に経験したことで、
- 意思決定のボトルネックになりやすい議論はどこか
- どのチームの負荷が高くなりやすいのか
- 各チームが関心を寄せている課題は何か
といった「現場感のある組織の強み・弱み」が一気に立ち上がって見えるようになりました。
これは、情報だけを追っていては決して得られないもので「耳と目と足を動かす」を通じて獲得できた大きな経験だったと感じています。
やれなかったこと
一方で、100 日という限られた期間の中で、まったく手をつけられなかったこともあります。
- 採用強化（採用戦略や採用プロセスの見直し）
- ビジネス側の情報収集の体系化（事業戦略・数値面の深掘りなど）
それぞれ重要度が高く早めに取り組みたいテーマではあったのですが、慌てても上手くいくイメージを持てなかったので、これらの施策は落ち着いて取り組むこととしました。組織としての方向性が固まる前に採用を加速するとミスマッチも増えますし、ビジネス側の情報収集においても、十分な技術・組織理解があってこそ、初めて効果的なシナジーが生まれます。
最初に全てやろうとせず「まずは地ならし」と割り切れたことは、いまのところ良い選択だったと考えています。
おわりに
100日間を振り返ると、派手な改革よりも「地味だが本質的な基盤づくり」に時間を使い続けた期間でした。
- 情報を集める
- 人を理解する
- 認知を揃える
- 組織の構造を把握する
- 小さな改善から着手する
こうして文章に起こして振り返ってみると、この期間は華やかな「改革」など全く考えず、ただただ丁寧に基礎を作ることに専念した時間のように思います。この基礎作りが、今後の組織づくりの土台になっていければよいと感じています。
この記事が、新たに着任されるエンジニアリングマネージャーの方々の参考になれば幸いです。
採用PR
with(enito)ではエンジニアの採用を行っています。
興味がありましたら、ぜひお問い合わせください！