はじめに

Hubbleでバックエンドエンジニアをしている @power3812 です。オブジェクト指向大好きマンで、神クラスを作れないかと模索の日々です

今回は技術が課題解決手段から目的化することに対して自身の考えを書いてみようと思います。

前提

よくWeb系の事業会社の採用において、エンジニアにおいてもユーザー志向やサービス志向であることが、求められることが多いと思います。

自社サービスを開発している企業に入社しても、好きなものを好きなように作れるわけではありません。サービスにはそれを使うユーザーがいるため、「ユーザーを意識した仕事ができる人」が求められます。
不採用理由で「〇〇志向が足りない」と言われてしまう人の対策より引用

これは自分自身も新卒・中途転職の際に下記のような質問を受けました。

エンジニアである以上、ビジネスドメインよりも技術に目が行きがちです。

自分自身も、Hubbleに転職する際に、契約書のバージョン管理というビジネスドメインよりも、Wordのバージョン管理をWebでやっている技術に興味を最初持ちました。
そして実際に、WebDAVやAsposeと言った普段のWeb開発では使用しないであろう技術を使っています。

ここで表題のエンジニアはサービス視点を持つべきかですが、そもそもサービス視点だったり技術志向だったりはどちらに重きをおいても良いと思います。

大事なのはその考えをどうやって他人に伝えるかです。

例えば、そのまま「自分は最新技術にしか興味がありません」と言うのと「自分は最新技術に興味があるので、最新技術でユーザの課題を解決できます」と言うのだと全然印象が違います。
相手目線の目的に立って、自分の考えを言い換えるだけでかなり印象が違います。

自分がやっていきたいことがある場合は、相手の考えや目的を汲み取ってそれとどういう関連性があったりメリットがあるのかを提示することが大事です。

今の自分自身もサービス視点を持てるようになりたいなと思う一方、技術に重きを起きがちです。

Hubbleでは、技術的にやってみたいことであれば何でも挑戦することができます。

例えば、Hubbleでは主にRubyでアプリケーションを作成していますが、過去にGoで新規アプリケーションを作成しました。
その当時Go人気がかなりあったため挑戦しました。特段、要件としてGoにする必要はなかったですが、プロダクションレベルのGoを学びたかったので選定しました。

結果として、Goとしてのメリット、デメリット、付随してDDDの知見が貯まりました。
そのため、今後要件毎にユーザビリティが高い言語を選ぶ幅が広がりました。

また、GPT-4が発表された当時早々にアプリケーションに組み込んだりなど、最新技術に触れつつユーザの課題を解決しました。

このように個人のやりたいこととユーザの課題解決はクロスするのでどこに目的を置くかだけの差でしかないのです。

今回は技術が課題解決手段から目的化することに対して自身の考えを書いてみました！
これからも最新技術に触りつつユーザの課題解決できていければなと思っています！

次回はQAの @miney さんです！