エンジニアは一生コーディングに集中すべきか、それともマネジメントに回るべきか。

自分のキャリアを真剣に考えているエンジニアにとって、避けては通れぬ人生の岐路だと思います。

本記事ではディベートを通して、価値のあるエンジニアになるためにはどちらが正しいのかを判定します！

ディベートのルール

ディベートとは、与えられたテーマに対し肯定側と否定側に別れて、いかに審判を説得できるかを競う競技のことです。

審判の判定基準は

• それぞれの主張に尤もらしい根拠があったか
• 相手の主張に対応した反論ができているか
• 例やデータを用いて客観性のある説明ができているか

です。

今回の審判はエンジニア1年目の三須さんにお願いしました。

「エンジニアとしての価値を高めるためには、コーディングに集中すべき」

中條：エンジニアとしての価値を高めるためには、コードを書くことだけに専念するべきです。マネジメントをするよりも、キャッチアップに力を入れるという時間の使い方をしないと、移り変わりの激しい業界なので他のエンジニアに遅れを取ってしまう可能性があるのかなと思います。

小山内：いえ、エンジニアこそマネジメントを積極的に行うべきです。僕たちはチームで仕事をしているので、自分一人の技術力よりも、チーム単位でのアウトプットといかにプロジェクトを円滑に進めるかに注力すべきで、そのために必要であればマネジメント業務も引き受けるのは当然のことだと考えています。

中條：プログラミングに専念することで得られる技術力がエンジニアとしての価値を高めると同時に、プロジェクトの成功確率を上げることにも繋がります。

そもそもプロジェクトの成功に拘っていますが、それは自分のエンジニアとしてのキャリアを考えた時に本当に重要なんですかね。プロジェクトの成否って、どうしても運の要素もあるじゃないですか。すでに決定された設計が間違っていたりとか、クライアント側の事情で人員、期間が足りないとか。自分の努力以外のところで炎上するかどうかが決まってしまうところも大きいと思うんですよ。

それを考えると、プロジェクトの成功に拘るというよりも、自分の技術力を磨き続ける努力だけがエンジニアとしての価値を高めていく確実で唯一の方法なんじゃないでしょうか。

小山内：大前提として、自分たちはエンジニアという職種の「社会人」です。社会人というのはクライアントやユーザーに価値を提供して、その対価として賃金を貰っています。コーディングはあくまで手段であって、仕事の本質は他者への価値提供であり、そのために必要であればマネジメントに回るべきです。

また、マネジメントと技術力の追求は二者択一ではなく、両立できます。コードを書かなくても技術力を向上させるというのは可能で、実際にコードを書かなくても、コードレビューやプロジェクトで採用する技術を選定するためのキャッチアップなど、マネージャーになっても技術力を高める機会はたくさんあります。また、ずっとコーディングだけに集中すると、どうしても視野が狭くなっちゃうと思うんですよ。深い理解を得られるのはメリットだと思いますが、先ほども述べたように、僕たちエンジニアが本当に力を入れるべきなのはクライアントへの貢献、基本的にはプロジェクトの成功です。

プロジェクトの成功のための効率的なキャッチアップは、マネジメント経験を積んで視座が一段上がったエンジニアの方がやりやすいんじゃないかなと思います。

中條：僕たちはエンジニアである前に一人の社会人ということで、プロジェクト成功の重要性は理解できました。

ですが、技術力への拘りがプロジェクトを成功に導いたという実体験があります。
クライアントから一ヶ月である機能を実装したいという要望があったのですが、我々の見積もりだとその機能だと少なくとも三ヶ月はかかるという見通しでした。ですが、一緒に入っていたいわゆるエースエンジニアの方が「設計をもっと効率化したり、この技術はこっちで置き換えたりして、それだと一ヶ月で実装できそうじゃないか」ということを提案してくれて、そのおかげでクライアントの要望通り一ヶ月でプロダクトを完成させられたという経験があります。このように、技術力を追求することでプロジェクトの成功確率を上げるという方法もあると思います。

また、逆に言えば、専門性の追求を軽視することがプロジェクトの失敗に繋がるとも考えられますよね。プログラミングに必要な技術は常に進歩していて、新しい言語やフレームワークの習得が効率的なプログラミングのためには必要不可欠です。マネジメントに時間を割くことでキャッチアップが遅れ、結果としてプロジェクトの失敗に繋がる可能性があります。
マネーシャーというのはあくまで進捗管理に責任を持つ役職であって、専任のプロジェクトマネージャー職を設けて、彼らがマネジメントを担当するべきです。無理にエンジニアをマネージャーにする必要は全くないと考えます。

小山内：まず、マネジメントを行うことは専門性を軽視しているという訳ではありません。むしろ専門性を重視しているからこそ、マネージャーは開発経験がある人材が担うべきだと考えています。
マネージャーはあくまで進捗管理と言いましたが、我々エンジニアが行っているのはプロダクト開発です。マネージャーに開発経験があることで、プロジェクトの全体像を把握しやすくなります。技術的な問題を理解しながらリソースの配分や進捗管理を行うことができるので、結果としてプロジェクト全体の成功率が高まると考えられます。

また、元々エンジニア上がりのマネージャーであれば、技術的なコミュニケーションが円滑になるためチーム内の連携も強化されます。エンジニア経験があるマネージャーは技術的な課題を理解しているため、適切なフィードバックやサポートを提供できます。これにより、チーム全体のパフォーマンスが向上し、結果的にプロジェクトが成功する可能性が高くなります。

中條：なるほど...。でも、積み上げてきたキャリアを考えるとリスクがありますよね。マネージャーを検討するということはある程度のレベルのエンジニアなのかなと思います。エンジニアとして成長していける可能性を捨てて、向いてないかもしれないマネージャーになるにはリスクが大きすぎます。

小山内：生成AIによって、コードが書けるだけのエンジニアの価値は低下していくと考えられます。マネジメントなり何なりでプラスαの価値を提供できるようにならないと、絶対に生き残れない。
それに、一生プレイヤーとして働いていくなら、歳を重ねても全盛期と同様のアウトプットが求められることを考慮すべきです。勉強する体力や記憶力の低下等を考えると、プレイヤーではなくマネージャーとしての自分の価値を高めた方が、結果的にエンジニアとして長く働けます。

また、経験値が増えると成長が鈍化します。はじめのうちは新しい経験が多いから、学ぶことも多いですが、徐々に得るものが少なくなってきます。そういうときにロールチェンジするのは自分の成長率を上げる有効な手段の一つかなと思います。

勝敗

三須：今回は小山内さんが勝者ですね。エンジニアはマネージャーにもなるべきだと、完璧に納得させられました。以下、それぞれの判断基準と照らし合わせてジャッジの理由を説明します。

まず、それぞれの主張に尤もらしい根拠があったかですが、小山内さんは生成AIによりエンジニアの価値が変わっていく将来の視点を取り入れ、技術力とマネジメントの両立が重要である点を強調しています。これにより、エンジニアが単にコーディングだけに専念することのリスクを浮き彫りにしています。

次に、相手の主張に対応した反論ができているかですが、中條さんのコーディングによる技術力の追求のみが重要だという主張に対して、小山内さんは技術力の追求とマネジメントの両立が可能であることを具体的に説明しています。

最後に、例やデータを用いて客観性のある説明ができているかですが、中條さんの技術力の追求がプロジェクトの成功にどれほど重要かを具体的な例を用いて示した点は評価に値します。ですが、小山内さんもエンジニア上がりのマネージャーがプロジェクト成功に寄与する具体例とともに、将来的な技術の変化を示唆する生成AIについて言及しています。これにより、彼の主張がより現実的であることを補強しています。

中條さんも技術力の重要性や実際の成功事例を挙げて説得力のある主張をしていますが、小山内さんの方がより広い視野と将来の変化を踏まえた論理的な説明をしており、相手の主張に対する反論も適切に行えていました。そのため、今回は小山内さんが勝者となります。

まとめ

価値の高いエンジニアであり続けるためには、技術力のみならずマネジメント経験も必須だということが分かりました。
Nucoでは、コーディングだけに拘らず、クライアント貢献を第一に見据えて行動できるエンジニアになりたい方からの応募をお待ちしています！