エンジニアリングマネージャーの仕事　その3（ピープルマネジメント以外の業務）

前回は、ピープルマネジメントの業務をブレイクダウンしてみましたが、今回はピープルマネジメント以外の業務を整理してみます
ピープルマネジメント以外は、主にプロジェクトマネジメント、テクニカルマネジメント、プロダクトマネジメントの3つのマネジメントに大別されますが、どの分野が期待値になってくるのかは、企業フェーズ、事業フェーズ、会社組織によってまちまちですので、現組織における定義および期待値のすり合わせが必須です

上記のマインドマップはあくまで業務の一例です

プロジェクトマネジメント
EM自身が受け持っているチームでは、開発プロジェクトが走っていることが一般的と思われます
ピープルマネジメントが軸であるからといって、プロジェクトの動向に対して無関心であってはいけません
開発プロジェクトを成功させるためのピープルマネジメントとも言えますので、開発プロジェクトのQCDS（品質、コスト、納期、スコープ）に一定の責任を持つケースの方が多いのではないでしょうか
よって、チームメンバーとQCDSの設定を行い、そのモニタリングを定期実行し、課題があれば一緒になって解決する、アドバイスを行うというのが理想的な形であると考えています
また、番外編としては、外部委託をするケースがある場合、EMがその契約管理であったり、プロジェクトマネジメントに責任を持つケースもあります

テクニカルマネジメント
技術面にEMとしてどこまで入り込むかも組織によってまちまちですし、EMとしての色が出る部分でもあります
理想的には、マインドマップに記載した通りの業務ができることです
しかし、ピープルマネジメントに忙殺されるとどうしてもテクニカル面が弱くなり始めるのもEMならではの悩みです
よって、どこかのタイミングでテックリードをチームに準備し、テクニカルマネジメントを移譲するのが平和的解決だと考えています
ただ一つ、テクニカルマネジメントにおいて重要だと考えているのが「チームメンバーとの壁打ち」です
これは開発メンバーが技術面で悩んでいる時の相談相手になるという意味です
意思決定をせずとも少なくとも、チームメンバーが技術面でどんなことに悩んでいるかを理解し、次のアクションを起こすためのきっかけは作ってあげる必要があると考えています
その時に、テーマとなる技術に対して、ちんぷんかんぷんではさすがに話になりません
よって、最低限チームが扱っている技術の特徴やトレンドは追いかけ、会話ができるレベルには知識を高めておく必要があります
技術のトレンドは日進月歩ですから、技術の概要やトレンドを追いかけるだけでもそれなりに時間を割かなくてはできない業務だと考えています
またピープルマネジメントにおける評価の面においてもチームが扱っている技術の最低限の知識がなければ適切な評価ができないと考えられます

プロダクトマネジメント
現代のプロダクト開発の現場においては、プロダクトマネージャーやプロダクトオーナーといった役割が確立されているので、EM自身がプロダクトマネジメントに手を出したり、責任を負うケースは少ないと考えていますが、まだ組織にプロダクト責任者が存在しない場合はEMがその役割を担うケースもゼロではないと思います
必要に迫られてのケースが多いと思いますが、最低限の仮説検証のサイクル程度は理解しておいた方が良いでしょう

以上で、EMが担うべきおおよその業務の解説はおしまいです
今後はEMが求められる成果とは何かといったことや、ピープルマネジメントのさらに深堀りをしていきたいと思います