2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

マネージャー見習いになった私の失敗と挑戦の記録

2
Last updated at Posted at 2025-12-21

はじめに

私は2019年に新卒として株式会社エイチームフィナジーに入社し、2022年からアシスタントマネージャーという役割を担うことになりました。

アシスタントマネージャーはいわばマネージャー見習いです。上長であるマネージャーの負担を軽減しつつ、メンバーやプロジェクトのマネジメント業務を補佐・遂行する役割です。

本記事では、私が現場エンジニアからリーダーへのステップアップする過程で経験した葛藤や、取り組んできたことを、当時の記事を引用しながら振り返ります。

エンジニアリングマネージャーとは

そもそもマネージャーの仕事とは何でしょうか。当初の私は自身の開発をこなしつつ、メンバーのフォローや依頼事項を対応することと捉えていました。

しかし、体系的な知識の必要性を感じ、「エンジニアリングマネージャーのしごと」を手に取ったことで、その認識は大きく変わりました。

本書ではエンジニアリングマネージャーの仕事として以下の4つが挙げられています。

  • 情報収集: チームの内外で何が起きているかを把握する
  • 意思決定: チームが進むべき方向を定める
  • ナッジング: 議論に示唆を与え、メンバーの背中を後押しする
  • ロールモデル: メンバーの模範となる振る舞いを示す

マネージャーのアウトプットは、自分のチームのアウトプット + 影響を与えた他チームのアウトプットとして定義されていました。総じて、チームのパフォーマンスを最大化することで、チームのアウトカムを最大化することなのだと思いました。

マネジメントの4領域における実践

エンジニアリングマネージャーの仕事を整理したところで、具体的にどのようなアクションを取ったのか。プロダクト・テクノロジー・プロジェクト・ピープルの4領域で整理しました。

プロダクトマネジメント

当時のチームでは、売上向上の施策はマーケティング・企画営業側が主導していました。依頼のタイミングでバックログを作成してもらい、開発チームも交えて施策を動かしていました。もともとはバックログを書くこと自体をしていなかったため、このような枠組みをマネージャーとメンバーで策定していただきました。私はテンプレート内容を記載して運用に乗せる動きをしました。

エンジニアグループが主導していたこととしては運用・保守となります。ライブラリアップデートをルーチン化し、ランダムでアサインされるようにしていただきました。コードレビューを徹底することで、誰でもメンテナンスできる状態を構築しました。

テクノロジーマネジメント

技術選定において、私より知見のあるメンバーがいる場合は積極的に委譲しました。私は内容が論理的かどうかのチェックと意思決定に専念し、メンバーの主体性を尊重しました。

また、スキルアップとしては、Google Cloud の G.I.G.プログラムにお声がけいただき、各メンバーが最終的には資格取得することができました。

プロジェクトマネジメント

プロジェクトマネジメントでは、朝会にて状態を把握し、適宜テキストコミュニケーションや1on1にて情報収集していました。

大きくプロジェクトマネジメントをしたものとしては、保険代理店事業特有のシステム開発のタイミングでスクラムを導入したことです。プロジェクト開始初期は従来のやり方だと明らかにメンバーのパフォーマンスが低下した時期がありました。そこで議論を重ね、スクラムの導入まで至りました。私はスクラムマスターとしてプロダクトオーナーや開発チームの橋渡しやスプリントバックログの調整をしてました。

事業承継では、タスクの洗い出し・管理だけではなく、ロールモデルを意識して序盤でのやり取り・開発を率先して実施させていただきました。

ピープルマネジメント

最も苦戦したのはピープルマネジメントです。相手をどう導くかの前に、前提条件を揃えるアセスメントの重要性を痛感しました。

アセスメント・ティーチング・コーチングといった用語があります。前提条件を揃えるアセスメント、前提条件を揃えることでお互いコーチャブルな状態となり、正解を示すティーチングと正解に導くコーチングを使い分ける形となります。

私は感覚的に話してしまう癖があり、論理的な思考を持つメンバーとのコミュニケーションが噛み合わない場面がありました。自分の感覚をいかに論理的な言語へ変換して伝えるか。この思考プロセスの醸成が、今も続く私の課題です。

一方で、スクラムを通じて「まずはやってみる(試着する)」文化が根付いたことは大きな収穫でした。新しいワークやAI活用などの提案があった際に、時間を確保してワークしたり、背中を押す「ナッジング」を意識したことで、チームに挑戦の火を灯すことができたと感じています。

おわりに

マネジメントにおいて、仕組みを大きく変えることは労力が伴います。だからこそ、如何に小さく回して、フィードバッグが得られるか。アクションのハードルを下げ、習慣化・仕組み化ができるかが考えるポイントだと感じました。

約6年間、フィナジー保険代理店事業でのテクノロジー・マネジメントを通じて得た経験は、私にとってかけがえのない財産です。

私自身は事業承継を終え、Qiita株式会社に転籍となりました。保険代理店事業で積み重ねた経験をQiitaでも活かし、より多くのエンジニアに貢献していきたいと考えております。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?