エンジニア全般

エンジニアにおけるプロダクト志向と技術志向について

プロダクト志向

reisuta

Webエンジニア | 20代中盤 | 大学時代はGmailすら知らないIT音痴でプログラミングとは無縁の生活を送る → 独学でプログラミングを学ぶ → Web系受託開発企業にエンジニアとして就職 → Web系自社サービス企業に転職 | 実務未経験の頃からVimを愛好しており、仕事でもプライベートでも開発はVimとTmuxを使っているので、VSCodeに疎いのが最近の悩み。何だかんだでやっぱりRubyが好き。

エンジニアのキャリアを考える上で、
しばしば話題になる、
プロダクト志向と技術志向の問題。

自分がどちらの志向性なのかによっても、
Sierにいくべきか、自社サービスに行くべきかといったことも、
変わってくると思います。

本記事では、この2つについて考察してみたいと思います。

ちなみに、以前の記事で強強エンジニアについて解説しましたが、
こちらは本記事でいうところの、技術志向のエンジニアの強強エンジニアとも言えるでしょう。

※その点、プロダクト志向の強強エンジニアは、
また別の強みが要求されるでしょう。
(わかりやすいものでいうと、Bizへの要件定義能力と、
提案力や、Bizやプロダクトへの深い理解と、それらの課題を解決するための最低限の技術力など)

プロダクト志向と技術志向とは?

そもそもプロダクト志向と、技術志向は、
その名の通り、そのプロダクトに対する関心が強いか、
またはプロダクトよりも技術への関心が強いかといった、
個々のエンジニアの興味関心の志向性のことをいうかと思います。

一般的に、プロダクト志向は、
サービスに対する愛が強く、
そのサービスをより成長させていくためにはどうしたらいいか、
ユーザーにもっと使ってもらうにはどうしたらいいか、
自分が実装した機能がどうユーザーに跳ね返るか、
自分が実装した機能がどう営業利益に結びつくかといったことに
興味関心が強いことが多いかと思います。

それに比べ、どういう技術を使いたいとか、
技術選定とかアーキテクチャはどうしたらいいかといった、
技術の詳細にはこだわりがないことが多いでしょう。

これに対して、技術志向は、これの逆で、
サービスに対する思い入れが強いわけではなく、
興味関心は、興味深い最新技術を使うことや、
アーキテクチャを選定することや、
内部実装を洗練させてパフォーマンスを上げて行くなど、
技術的な課題についての興味関心が強いことが多く、
そのプロダクトが実際に成長していくかどうかや、
営業利益にどう結びつくかといったBiz的なことには、
興味が薄いことが多いかと思います。

プロダクト志向のエンジニア

さて、これらを踏まえて改めて、
プロダクト志向のエンジニアとはなにか?

プロダクト志向のエンジニアは、基本的にBizに興味がある人が多く、
営業利益にどう結びつくかといったことへの関心が強いことが多いので、
基本的にBizからは歓迎されるし、評価もされやすいでしょう。

そのため、上長がBizの場合、
プロダクト志向のエンジニアは評価を得やすいでしょう。

そして、そもそも論として、
技術力は何らかの課題解決の手段として存在するという側面は、
どうしても否めないため、その点においてプロダクト志向というのは、
ある種最も素直な志向性とも言えるため、
キャリアとしても最も無難な選択だと私は感じます。

特に自社サービス、事業会社において、
プロダクト志向は、ある種必須の一面もあるので、
仮に技術志向であったとしても、
プロダクト志向の側面も必ず必要になってくるでしょう。

自社サービスは、そのサービスをいかに大きくし、
いかに営業利益を伸ばしていき、そのサービスで
missionの課題を解決していくかということを重要視しているので、
その企業に雇われているエンジニアが、プロダクト志向ではないというのは、
ある種致命的になりうることもあります。

技術力に定評がある、自社サービス企業も、
他の自社サービスに比べると、
技術志向も重視するかもしれませんが、
それでもプロダクト志向が抜きのエンジニアは、
かなり厳しいことになりうるのと、
仮に採用されても、本人がそのプロダクトに愛着を持てないと、
なかなか厳しいと思います
(異動とかがない限り、基本的にそのプロダクトをずっとメンテナンスしていくことになるため、
やりがいを感じにくくなるのではないかという懸念が残ります)

ここまで読むとプロダクト志向のエンジニアは、
完璧のようにも思えますが、懸念点もあります。

プロダクト志向のエンジニアの懸念点

ずばり、技術に関心がなさすぎる場合です。

結局のところ、プロダクト志向を突き詰めすぎてしまい、
技術に対する関心を失ってしまったら、
それはもはやエンジニアではなくBiz職になってしまうという問題があります。

わかりやすい例でいうと、
Bizの人がちょっとかじった程度のGASやPython使って、
メンテナンスしづらいコードを量産してしまい、
手に負えなくなってしまったりという、
技術的関心がなさすぎることにより起こる、
技術的負債などでしょう。

こういったことは、プロダクト志向が強すぎるエンジニアにも当てはまるかもしれません。
(例えば直近のBizの課題を解決できれば問題ないと、あまりに冗長なコードを使ったり、
コピペでソースコードを使ってしまったりなど)

なので、プロダクト志向のエンジニアも、
結局のところ、エンジニアであるということを忘れず、
自身の技術的興味関心を追求することを、
やめてはいけないということがあるでしょう。

Macとマグカップの画像

技術志向のエンジニア

さて、プロダクト志向のエンジニアに対して、
技術志向のエンジニアは、
わかりやすく技術バカと言う感じの人が多く、
いわゆるエンジニアっぽい人が多い印象です。

アーキテクチャ探求や、最新の技術などが好きだったり、
それらを使う手段としてプロダクト開発を行っているという、
思考の人が多いかもしれません。(私もどちらかというとこちら寄りのエンジニアです)

もちろん、企業にもよるとは思いますが、
あまりに技術志向に振り切っているエンジニアは、
自社サービスとか事業会社では、評価されにくいです。

それは、すでにプロダクト志向のエンジニアのところで述べた通り、
サービスへの興味関心がないと、
かなりの技術力があるとかでない限り、
Bizとしても評価しづらいからでしょう。
(自社サービスのカルチャー的にも、そのサービスに対する愛はかなり重視されるので、
そういうものがない人は、カルチャー的にも冷遇されやすい気がします)

そのため、基本的に技術志向のエンジニアは、
Sierなどが向いていると思います。

技術志向のエンジニアの問題点

これもずばり、Bizへの理解と興味がなさすぎることに尽きるでしょう。
結局のところ、利益を出すには、そのサービスを大きくしたりと、
少なからずBiz的要素が不可欠になるので、
そのあたりへの視点がないとかなり偏ってしまいますし、
どこかで頭打ちになる懸念があります。

また、技術志向の最大の懸念点は、
戦う土壌が良くないというのもあります。

世の中、技術力が高いエンジニアは、
死ぬほど存在します。

技術志向を突き通すということは、
ある意味、それらの歴戦のエンジニアを相手にしても、
自身の技術力のみでアピールできなくてはならないということです。

もちろん、それだけの自信がある人は、
それに挑戦するのもありだと思います。

ただ多くの人にとって、これは必ずしもいい選択とは言えないかもしれません。

それに加え、最近では生成AIなどの台頭で、
単純なコーディングができるだけでは淘汰されやすい時代が突入しており、
将来的には技術志向と生成AIは領域が衝突する懸念もあるため、
この点においても、戦う土壌が良いとは言い難いといえるでしょう。

それに技術の進化は早い事に加え、
現時点での技術的興味関心がずっと続くとは限らず、
いつか技術に飽きる日が来るかもしれません。

技術志向は、そういった際のリスクヘッジが非常にしにくく、
その点でかなり限られた人しかできないキャリアのような気もしています。

結局どちらがいいのか?

こちらの記事と似たような結論になってしまいますが、
結局のところ、どちらか片方ではだめだということを前提としても、
プロダクト志向のエンジニアの方が、賢い(というより器用)な生き方なような気はしています。

結局のところ、プロダクト志向は、
仮にSierとかに行ったとしても、
持っていて損にはなりませんし、
基本的にデメリットは技術的好奇心を失わないように気をつけたいということにあるので、
ある種心がけ次第でなんとでもできる領域だとも思います。

過度にプロダクト志向に寄せる必要はありませんが、
最低限、そのビジネスがどういう構造になっていて、
何をすれば利益が出て、営業利益を上げるために、
効果的な開発はどのようなものがあって、
どうすればユーザーがもっと使いやすいかとかを、
考えられれば、最低限は十分なような気もします。

これらに思いを馳せつつ、
一方で、最新の良いアーキテクチャについても議論をして、
よりパフォーマンスを上げる実装や、内部品質構造のための、
リファクタリングや抽象化などを考察するのも、
非常に素晴らしいことだと思います。
(今思えば、技術力に定評がある自社サービスとかは、
この2つが自然とできているような気もします。)

そもそも、エンジニアである以上、
技術志向というのはある種当たり前ともいえるので、
そこに少しプロダクト志向を入れるだけで、
かなり視野が広いエンジニアになれるのかなと個人的には感じました。

技術志向とプロダクト志向は関係性のなかでも変化する

そもそも、プロダクト志向は、
そのプロダクトに対する愛みたいなものなので、
いくら性質的にプロダクト志向のエンジニアの人でも、
そのプロダクト自体になんの興味もなければ、
プロダクト志向にはなりきれないでしょう。

逆に、性質的に技術志向の人でも、
自分が普段利用しているサービスであれば、
愛着もわくでしょうし、いくらかプロダクト志向寄りになるでしょう。

そのため、結局のところ、
自分がどちらのタイプのエンジニアかは、
正直のところ、そのプロダクトによっても変わると思いますし、
実際は、福利厚生に目がくらんで、
対して興味がないプロダクトのエンジニアとして就職することもあると思います。

プロダクト志向は、その点流動的なものかもしれませんが、
エンジニアとしてプロダクト志向をアピールしておくことは、
一定の処世術として効果的なのかなと個人的には感じています。

  • この記事を書いた人
  • 最新記事

reisuta

Webエンジニア | 20代中盤 | 大学時代はGmailすら知らないIT音痴でプログラミングとは無縁の生活を送る → 独学でプログラミングを学ぶ → Web系受託開発企業にエンジニアとして就職 → Web系自社サービス企業に転職 | 実務未経験の頃からVimを愛好しており、仕事でもプライベートでも開発はVimとTmuxを使っているので、VSCodeに疎いのが最近の悩み。何だかんだでやっぱりRubyが好き。

おすすめ記事はこちら

Vim/Neovimプラグイン 1

プラグインをどれだけ入れるかは、その人の思想なども関係するので、一概にこれがいいというのはないかもしれません。 プラグインを全く入れない人もいれば、100個以上入れる人もいます。 ただそれでも、これだ ...

VimとNeovimの比較 2

本記事では、VimとNeovimの違いについて、解説します。 VimとNeovimの違いについては、普段頻繁にVimなどを使う方でなければ、正直、あまり気にしなくてもいいかなと思います。 ただ、Vim ...

Ruby変数やすべてがオブジェクトについて 3

本記事は、Rubyの基礎文法である、変数や真偽値、論理演算子に触れると同時に、「すべてがオブジェクト」というRubyの特徴的な思想についても解説します。 この思想は、Rubyの文法の根幹になっているの ...

4

エンジニアにおすすめの技術書 書籍学習は、エンジニアの嗜みみたいなところがありますが、 良書というものは、意外とそこまで多くもありません。 そこで本記事では「技術書マニアの筆者が厳選した技術書20選」 ...

5

エンジニアになるには? プログラミングは、専門性が高く自分一人で勉強するのが大変に感じることも多いですよね。 そこで本記事では「おすすめのプログラミングスクール5選」を特徴と、現役エンジニア目線で優れ ...

-エンジニア全般