さらにWebサービスのようにソフトウエアで構成されているシステムが継続的に提供されていかなくてはいけないので、価値の向上とサービス継続性を保っていかねばならない。具体的には機能性の向上やセキュリティーの維持、スケーラビリティーの維持、技術的負債の返済、そもそも技術的負債を減らすプロセス改善、災害などの事業継続性の維持、システム老朽化に適応するための再開発など様々な課題に対してプライオリティーを考えながらサービスを開発する必要がある。
このような責任をチームのメンバーと共に担っていくのがエンジニアリングマネジャーの重要な責務である。サービスの価値を向上させるために何を作るべきかを考え、ビジネスとユーザー体験の両軸を満たしながら、成果を上げることにコミットするのがプロダクトマネジャーの責務だ。これらの開発プロジェクトを取りまとめる役割を担うのがプロジェクトマネジャーである。
これらの役割の違いが意識されていないと、プロダクトマネジャーとプロジェクトマネジャーの言葉が似ていることから混乱しかねない。それぞれの役割を肌感で理解できるようになれば、そのような混同は決してしない。
プロダクトマネジャーにせよエンジニアリングマネジャーにせよ、持ち場は違うがソフトウエアの価値向上に責務を担うことに変わりはない。責務を果たすため、必要な人員が活躍できるように管理するのがマネジャーとしての役割となる。
プロダクトマネジャーの役割はピープルマネジメントではないと思う読者がいるかもしれないが、チームメンバーにサービスの理念を正しく理解してもらい、UXなど無形の価値をチームでどう生み出すか、実現に向けた人員をどう育てていくかといった視野においては、ピープルマネジメントのスキルがなければうまくいかない。組織図上の直属の上司でなくても、責任を持ち実力者として一目置かれ続けることで、メンバーのリスペクトを得て説得力を発揮していくために、業務を通じて人を引きつける力を備えていることが重要である。
エンジニアリングマネジャーも同様に、不確実な荒波を部下と共に歩んでいく役割なので、メンバーから一目置かれ続けるマネジャーでなければ指導者としての説得力が足りなくなる。例えばコードを書けない状態でエンジニアリングマネジャーの座を得ることはできない。従来のマネジャーは主にピープルマネジャーとして期待されておりエンジニアのキャリアとしては死を覚悟してコードを書く作業から完全に離れていく。
開発するサービスのカテゴリーが10年、20年と固定されているなら可能かもしれないが、インターネット業界のように日進月歩の変化を前提とするビジネスでは足元が変化してしまうためその選択肢は採れない。つまりエンジニアリングマネジャーも役割が違うだけで、基本的には「先輩エンジニア」であり続ける必要がある。いざというときには自らプレーヤーとして活躍可能なフットワークを持っている人材が望ましい。自分たちが発展、かつ継続させる対象であるWebサービスが常に変化していってしまうので、スキルが固定されてしまうことはむしろエンジニアとしての死を意味する。
