開発部門マネージャーの仕事についての棚卸しとふりかえり

この記事は、ポート株式会社 サービス開発部 Advent Calendar 2024の、25日目の記事です。

ざっくり記事の内容

• 弊社の開発部門におけるマネージャーの業務内容を、体験談を交えて紹介
• マネジメント業務の整理や分類を通じてふりかえり、弊社の開発部門におけるマネジメント業務について考察
• 今後の取り組みを検討

想定読者

• 社内･社外を含め、マネージャーを目指しているエンジニア
  • 「次のキャリアステップとしてマネージャー職を考えているけど、実際の業務内容がイメージしづらい」と感じている人。
• 現役のマネージャー
  • 自身の業務を見直したり、他の会社のマネージャー像と比較したいと思っている人。

---

イントロダクション

自己紹介

ポート株式会社に所属している@kehondaです。
2015年に入社し、現在、サービス開発部という部門のエンジニアリンググループでマネージャーをしています。

入社当初はバックエンドエンジニアとしてキャリアパークの開発に携わっていました。その後、2020年頃から同サービスのエンジニアリングマネージャーを務めながら、分析基盤やインフラの開発に携わりました。

現在は、その他就活会議等のプロダクト開発やインフラ、SREを含むエンジニアリンググループ全体のマネジメント業務を行っています。

弊社の開発組織について紹介

私が所属しているサービス開発部は、エンジニアリング、クリエイティブ、ディレクションの3つのグループで構成されています。

部門名	所属メンバーの職種
エンジニアリンググループ	アプリケーションエンジニア、インフラ/SREエンジニアなど
クリエイティブグループ	UI/UXデザイナー、グラフィックデザイナー、Webデザイナーなど
ディレクショングループ	プロダクトマネージャー、ディレクター、採用担当、部門運営、事務担当など

これらのグループからエンジニア、デザイナー、プロダクトマネージャー（PdM）、ディレクター、などのメンバーが集まり、プロダクトごとに複数のチームが編成されています。

部門全体の規模は約100名で、現在私を含む5名のマネージャーが所属しています。

弊社におけるマネージャーやエンジニアリングマネージャーについて補足

弊社における「マネージャー」は管理監督者としての役割を担う役職の名称です。

一方で、「エンジニアリングマネージャー」という名称は職能上の役割を示すものであり、役職としての位置付けではありません。現在の私は、会社から管理監督者としての役職を任されると同時に、エンジニアリングマネージャーとしての職能上の役割も担っていることになります。

この記事を書こうと思ったきっかけ

手探りのマネジメントを続けていた

ここ数年、社内にはエンジニアリングマネージャーとしてのロールモデルが存在せず、自分自身もマネジメント業務をするにあたって、CTOやVPoEの業務を見ながら手探りで取り組んできました。

管理監督者は存在していたものの、エンジニアリングマネージャー専任のメンバーはいませんでした。そのため、書籍やカンファレンス動画などでインプットを続けつつも、事業拡大や組織成長に伴う課題や問題への対応に追われ、体系的・網羅的に業務をこなせているという実感を持てないままでした。

結果として、目の前の課題解決に集中するあまり、十分なアウトカムを出す動きができていなかったと痛感しています。また、メンバーに業務を移譲するという点でも、戦略的に進めることができず、試行錯誤が続いている状況です。

まずは役割･業務整理から

最近、新しくマネージャーになったメンバーがいたり、エンジニアリングマネージャーとして新たなメンバーがJOINしてくれたりしました。
さらに組織の拡大に伴い、マネジメント業務を他のメンバーに移譲する必要性を感じています。

なぜ移譲を進めるべきかというと、マネージャーがボトルネックとなり、チームが自律的に動けなくなることを防ぎ、プロダクトを通じた価値提供を鈍化させないためです。
また、自分よりもプロフェッショナルで多様な考えを持つメンバーへの移譲が実現すれば、より良い選択や成果につながるとも思いました。
総じて、移譲によってチームが自律的に成長し、推進力を高めることができるため、組織全体の成長にとって欠かせない取り組みになると感じているためです。

マネジメント業務を移譲し、組織の成長を推進する取り組みの第一歩として、まずは自分や他のマネージャーが対応している業務を棚卸しし、全体を俯瞰して整理する取り組みを始めようと思いました。

マネージャーの主な役割を棚卸ししてみた

前提

今回、エンジニアリングマネージャーとしての業務というよりも、開発チーム部門全体としてのマネジメント業務を整理の対象としています。

また、これは個人的な業務の棚卸しであり、文献などを参考にした網羅的なものではありません。抜け漏れや重複がある点はご了承ください。

マネージャー複数名で棚卸し

棚卸しの方法として、問題解決やアイディア発想に用いられるようなフレームワークは使用せず、FigJamを活用してシンプルに各自でアイデアを付箋にまとめていきました。その後、各自が記載した内容を読み合わせながら議論を進め、深掘りや抽象化を通じて視点を広げました。

整理して分類してみた

棚卸しを進めるにおいては、粒度や重複を気にせず、思いつくままに付箋に記載を進めました。
各自が出した付箋の読み合わせをしながら、大まかに分類分けをしていきました。結果、以下のようなアウトプットになりました。

さらに、マネージャー数名で行ったディスカッションを元に、今後の方針も含め検討するために、個人的に再検討･再構築を進めました。
（初めは自分で悩みながら進めていましたが、生成AIを活用することで大枠が整い、違和感のある部分を調整して仕上げました）

結果として、以下のような整理となりました。

• 人材マネジメントの領域
  • 採用と組織設計
  • メンバー育成とキャリア支援
  • 人事評価
  • 労務管理
  • 組織運営と文化の醸成
  • チームの成長とコミュニケーション支援
• 業務マネジメントの領域
  • プロジェクト管理と連携推進
  • 事業推進
  • セキュリティとリスク管理
  • 予算管理

以下、業務の詳細や具体的な業務例を記載します。

人材マネジメントの領域

採用と組織設計

• 採用活動

  • 候補者の書類選考や面接の実施
  • 採用フローの整備
  • 採用基準を他の面接官とも共有し、認識を揃えるための基準の言語化と議論
    • 例: 技術スキルだけでなく、チーム適性や価値観のマッチングも含める基準設定

• 組織体制の検討

  • プロジェクトやビジネスニーズに合わせ、チーム編成や体制変更の計画を立案
  • 個々のメンバーや組織に適した役割を定義し、異動計画を作成

メンバー育成とキャリア支援

• キャリアパス支援

  • メンバーと目標を共に考え、キャリア形成の支援を実施
    • 例: 1on1の実施。両者が感じる課題点を認識し合い、フィードバックやアドバイスを提供
  • 必要に応じて職種変更やチーム異動を検討
    • 例: 目指すキャリア設計や習得したいスキルに応じて、職種やチームの変更を検討･提案

• 育成支援

  • 社会人として求められるスタンスやプロ意識、リーダーシップスキルに関する指導･指針作り
    • 例: 新卒や若手社員を対象とした研修プログラムの設計
    • 例: キャリアラダーの検討･提示
  • メンター体制の整備と、メンターに求める具体的な役割や期待値の明示
  • 日々の業務やチーム・プロジェクト活動における改善ポイントを踏まえたフィードバックの提供
    • 例: チームのふりかえり等に参加し、マネジメント視点での意見の提示
  • 生産性向上を目指したチーム全体へのサポート
    • 例: 開発生産性を定量的に計測し、個人やチームのふりかえりに活かす
  • 専門技能を体系的に学んでいくための指針作り
    • 例: スキルマップの提示や運用

人事評価

• 評価基準の策定
  • 例: キャリアラダーの検討や調整
• 適正に応じた、期待値の調整や目標設定
  • 例: 日々の面談の実施や求めたい期待値の共有やすりあわせ
• 給与に関しての経営陣とのすり合わせや評価結果のフィードバック

労務管理

• 勤怠や残業時間をモニタリングし、過重労働を防ぐための指導や対応
• メンバーの健康状態やモチベーションを把握し、適切な支援を提供
  • 例:エンゲージメントサーベイの実施と施策の立案

組織運営と文化の醸成

• 組織のミッション・行動規範の提示

  • チームの方向性を示すミッションや行動規範を策定し共有
    • 例: ミッションの提示やミッションの背景を言語化
    • 例: 会社として提示されているコアバリューを開発部門に沿った形での解釈を提示

• 制度設計・運用

  • 新たな人事制度やチーム運営ルールの企画と導入を通し、組織や個人の成長促進
    • 例: 技術学習支援制度の立案
    • 例: リモートワーク制度の立案
  • 部内･外の制度や施策が正しく運用されているかのモニタリングや是正。

チームの成長とコミュニケーション支援

• チームビルディング

  • チームのふりかえり（レトロスペクティブ）を促進し、改善点を議論
  • チームの目指すべき成長方向性を議論し、合意形成を図る
  • コードレビューやタスクアサインの方針を明確化

• コミュニケーション支援

  • ビジネスサイドとエンジニア間、またエンジニア同士の仲裁や円滑化を図る
  • 情報共有の促進
    • 例: ポストモーテムの作成支援やオンボーディング資料の拡充
  • 誤解や適切ではない摩擦を避け、チームとして成功に導くための、仲介役を担い調整する

業務マネジメントの領域

プロジェクト管理と連携推進

• プロジェクト・タスク管理

  • 要件が妥当であるかの確認
    • 例: 適切に価値として提供できるかを確認。技術的･ビジネス的視点
  • プロジェクト進行の停滞時に迅速に対応できるよう対策の実施
    • 例: 人員配置の調整やメンバーへ取捨選択のアドバイスや業務整理
  • 技術的な意思決定のサポートやリード

• プロジェクト間の連携推進

  • 異なるプロジェクト間での連携強化
    • 例: 事業サイドのプロダクトチームや管理部門チーム × エンジニアの他部門連携支援
  • プロジェクトマネジメント業務
    • 特にプロジェクトの隙間に落ちがちなボールを拾う
      • 例: ファシリテーションやキックオフの実施

事業推進

• 事業連携

  • 事業KPIや目標をマネージャー自身が理解し、開発チームに浸透させる
    • フェーズや状況に柔軟に対応し、事業の目標に向かっていけるチームを作る
      • 例: 技術的な負債を減らす感覚を持ちつつも、求められる事業スピードにも対応する
  • 事業サイドと開発サイドの間でのコミュニケーションを支援。
    • 例: 目的達成のためにできる･できない視点ではなく、どうやったらできるのかを一緒に考える
    • 例: 技術的リスクを事業サイドに説明した上で、リスクヘッジする方法を提案
  • 業務推進
    • 抽象的な課題においても、具体的に何を求められているのかをすり合わせして、ズレなく前に進める
      • 例: 能動的に課題を抽出･分析し施策に落とし込んでいく

• インシデント対応

  • 障害が事業に与える影響を評価し、関係者に速やかに報告
    • 例: 障害の規模に応じて、事業サイドだけではなく経営層への報告の実施

セキュリティとリスク管理

• セキュリティ対策

  • セキュリティインシデント発生時に適切な対応を指揮
  • システムやインフラのセキュリティ対策が実施されているかの確認
    • 例: システム監査対応の計画・実行
  • メンバーのアカウント権限の適正管理（付与・剥奪を含む）

• 障害・リスク管理

  • 障害発生時の迅速な報告と対応を推進
    • プロセスの見直しや提示
  • 技術的リスクの特定とリスクヘッジ案の提示
    • 例: プロダクト開発において、事業へ与える影響度に応じた設計レビューやコードレビュー

予算管理

• 予算とコスト管理

  • ツールやサブスクリプションのコスト管理
    • 例: 利用しているSaaSの棚卸しやリプレイス案の提示
  • 人件費、業務委託費用の把握と最適化
  • 資産管理や資産計上の把握と最適化

• 経営層への報告

  • 予算進捗やリスク状況を経営層に報告
  • 必要に応じて承認・否認を含む判断を依頼

棚卸しをした感想

担っている業務や役割の多さを改めて実感しました（全てを完璧にこなせていた、なんてことは全くなく、社内で一緒に働いている皆様には、ボトルネックになることが多く、迷惑をかけていることが多いと感じています）。

更に、会社としての役職としてのマネージャー（管理監督者）と、エンジニアリングマネージャーの役割は重複する部分があるからこそ、自分自身の認識も曖昧で整理することができていなかったと感じました。このまま新人マネージャーやメンバーにすべてを担ってもらおうとすると、それは困難なことだったかもしれません。
立ち止まって業務をふりかえる時間を持てたことは非常に有意義でした。

また、今回マネジメント業務を大きく2分類に分けましたが、人材マネジメントの面では、個々のメンバーの成長がプロダクトの成長につながることを意識し、メンバーの成長を支援する取り組みが必要です。一方で、業務マネジメントの観点からは、事業の目標を深く理解し、チーム全体が同じ方向を向きながらその目標達成に向けて進む体制を作ることが求められます。
どちらの要素も欠かすことはできず、マネージャー（管理監督者としての）にとって、非常に重要な責務であり、より丁寧で迅速に業務を前にすすめる必要があると改めて感じました。

ふりかえり

マネージャーおよびエンジニアリングマネージャーとしての私自身の取り組みをふりかえりました。
うまくいった点と今後注力していきたい部分、さらに移譲すべき領域をまとめてみました。

⁠成果を挙げられた点

チームビルディングにおいて、ふりかえりを促進したり、コミュニケーションを円滑に行うための取り組みを積極的に行えたことが、今年成果を挙げられた部分かなと思います。（もちろん、私としての取り組みではなく、一緒に働いている他のマネージャーやエンジニアリングマネージャ、メンバーのおかげです）
これにより、チーム全体の改善活動の習慣化やコミュニケーションのハードルが下がったのでは？と感じています。

これから注力していきたいと考えている領域

弊社は若手メンバーが多い現状を踏まえ、キャリアパスや育成支援に力を入れる必要性を強く感じています。特に、抽象的なものを具体的に変換し前に進めていくスキル（タスクマネジメント･プロジェクトマネジメント）を学ぶことは私達の部門として重要であると感じていますが、体系的に進めることはできていなかったと感じました。

また、採用活動においては、私自身がボトルネックになってしまっていたと感じます。採用基準の言語化を進めることで採用プロセスに関わる人を増やし、組織全体の採用力を高めたいと考えています。

さらに、組織のミッションや行動規範の提示、その実現に向けた制度設計にも積極的に取り組み、私達個々の成長実感がプロダクトの成長につながっていることをより感じられるようにしていきたいと思いました。

移譲していきたいとおもっている領域

チームメンバー自身が自律的にかつリーダーシップを持って取り組む役割や責任範囲を移譲していきたいと考えています。エンジニアリングでいうと、例えば、テクニカルな領域やセキュリティの領域にプロ意識を持ち、高水準なプロダクト作りにつながると良いと感じます。

また、プロジェクト管理やプロジェクト間の連携に加え、事業部と同じ目線で事業推進に取り組めるメンバーがさらに増えるよう、事業理解の促進を進めていきたいと思っています。

これからの展望

弊社のマネージャーにとって、人材マネジメントと業務マネジメントはどちらも重要と記載しましたが、
改めて個人の成長、さらに組織の成長のためには権限委譲を進める必要があると感じます。ただし、権限委譲を推進していくうえで、必ずしも、今回分類したマネジメント領域を特定の人がすべてを担う必要はないし、そもそも全てを担うことはとても難しいことであると感じています。

また、人材マネジメント、業務マネジメントの中で更に細かく分類されている業務･役割にフォーカスしたとき、メンバーの経験･強みを活かせる領域やチャレンジとして挑戦できる領域も多くあると思いました。
例を挙げるとすれば以下のような領域になるかなと思いました。

• 職能やスキルを活かせる領域（テクニカルマネージャーやエンジニアリングマネージャーなど）
• リーダーシップを持って責任を果たせる領域（リーダーなど）

今後、弊社の開発チームでは、これらの領域を横断するプロジェクトとして取り組むことや、ポジションを新たに作ること、特定領域のマネジメントをチャレンジとしてメンバーに任せることを積極的に進めていきたいと考えています。