dipに入って気づいたエンジニアに必要な力

はじめに

こんにちは、2020年新卒入社しPHPで求人系サービスの開発や社内向けツールの開発を行なっている @naoya_prin です。
今回は、去年dipに新卒入社し私が気づいた"エンジニアに必要な力"についてご紹介したいと思います。
これからエンジニアを目指す方や、dipに興味がある方に少しでも参考になれば嬉しいです。

自己紹介

まず私がどんなバッググラウンドをもってdipに入ったのか、軽くご紹介しておきます。

当時、技術力しか見えてなかった

学生時代、私は主に独学でプログラムの学び、web制作をやっていたりwebアプリを作ったりしていました。

f:id:naoya_prin:20210122151428j:plain — (↑web制作をやってるときのタイで営業講座を受けてたときの写真)

このときは、ほぼ個人開発でやってたので、エンジニアとしてステップアップしていく為に”技術力”をどんどん身につけていこう！と考えていました。

だいぶ端折りましたが、ざっくりそんなことを考えてエンジニアとしてのキャリアをスタートしました。

必要なのは"技術力"だけじゃなかった

dipでは各開発チームに配属される前に開発研修を行っています。

参考：ディップは新卒一年生でも活躍できる爆速成長環境だった

詳しくは、上記の記事をみていただければと思うのですが、
研修では「決まったものをただ作る」のではなくユーザの抱える本質的課題を見極め、「どうすればユーザを幸せにできるか」「対象とすべきユーザはだれか？」というところから考えます。
この研修で、エンジニアに必要なのは「技術力」だけでないということに気づくことができました。

今回は、この研修や配属先での業務で分かった"エンジニアに必要な力"を紹介していきます！

技術力

”エンジニアに必要な力”ひとつ目は技術力です。

技術力というと、ゴリゴリコードを書く力とかそのための知見などを想像されるかと思いますが(私がそうでした。)
エンジニアが行うのはコードを書くだけじゃありません。コードを書く以外にも設計や要件定義でも技術力が必要になります。

例えば私が業務で行ったクラス設計では、MVC(S)アーキテクチャの中で適切な処理を切り分けを考え、一般的に使われるMVCアーキテクチャにServiceを加えることで、
メインロジックとバリデーションチェックの分離を行い、Controllerがファットになることを防止できました。

このようにコードの保守性や拡張性を意識し設計という側面でも技術力が必要であることを学びました。

課題発見力&解決力

次に課題発見力と課題解決力です。

逆説的な言い方になるのですが、例えば「言われたものをただ作る」エンジニアはユーザを幸せにすることができるでしょうか？？
この「言われたこと」がユーザの為に繋がらなければ作ったものは誰の役にも立ちません。(経験が積め技術力は向上するかもですが。)
業務をする上で、誰の役にも立たないものを作っても意味がありません。
そこでユーザの抱える悩みから「解決すべき本質的課題」を見つける力、課題発見力が必要です。
私自身、研修を通じてこの力の必要性に気づき、配属後の業務に活かすことができました。

課題解決力は、課題発見力にもつながるところなのですが、
ユーザの抱える課題をどのように解決するかを考える力も必要ですよね。

私の担当した業務での話を例に上げると、
企画担当者からサイトに表示しているデータを一行表示してほしい。
という依頼を担当したことがあります。

長文のデータの場合にレイアウト崩れが発生するので、長文でも一行表示になるようにしてほしい。とのことでしたが、
この問題の本質は「表示の見づらさ」だと考えました。
「表示の見づらさ」を解決するには「一行表示」が本当に最適なのかを考え、表示される可能性のあるデータの95%以上が、20文字以内であったことを踏まえ「20文字以上の場合は折り返す」という方法がよりユーザの「表示の見づらさ」を解消できると企画担当者に提案しより良い形で実装することができました。

このように、ユーザの抱える課題を解決する方法を考えることもエンジニアに大切なことだと思います。

コミュ力

最後にコミュ力です。
コミュ力というと学生時代では、よく喋る人、誰とでも話せる人などをイメージするかもですが、業務の中では少し違うと思います。
個人開発と違い、業務の中では多くの人と連携しつつ開発を行う必要があります。

例えば要件定義や要求整理といった開発前の段階で、自分の考えだけでユーザの課題を決めつけても実装しようとしてもうまく行かない可能性は高いです。
個人開発であればそれでもよいかもですが、
企画担当者とどんな機能があれば対象ユーザの課題を解決できるかを実装に入る前にすり合わせておかないと、実装に入って認識齟齬が起き大きく手戻りすることも考えられます。
また、実装に入った段階でも開発者同士の認識を合わせて開発を行うことで冗長な処理を共通化できたり手戻りを防ぐことができたりなど様々なメリットがあります。

このように業務の中でのコミュ力とは、相手の立場に寄り添って報連相などを適切に行うことが必要なコミュ力だと思います。