未経験がエンジニアとして働く上で気をつけると良さそうなこと

概要

エンジニアとして働くためにみなさん当然面接を受けることと思います。

面接自体はエンジニアとでなくても受けますが、
とりわけ、昨今のエンジニアへのジョブチェンジが激しいのもあり
どういったところを気をつける（企業側が求める像）かというところを知っておくと働く上でも重要になってきます。

あくまで自分の主観であり、全ての企業に当てはまるものでもなければ
これをすれば必ず受かる！といったものでもないです。

ただ、自分が働く上で考えていること、気をつけていること、というところを書いてみました。
これから面接を控えてる方や、エンジニアとして働き始めたばかりといった人に、多少参考になれば幸いです。

この記事の対象者

独学のみでの開発体験しかないレベルの方を対象としています。
基本的に業務経験はなく、チーム開発もほとんどないというような方です。

自分もそうだったのですが、勘違いしやすい箇所だったところを明確にしてから対処法を書いていこうと思います。

「未経験の認識の違い」という罠

罠というと、何か陥れるみたいな印象を持たれるかもしれないですが
ここでの文脈では、単純に「企業側の考える未経験」と「求職者の考える未経験」の差が異なるというところを指しています。

未経験という文脈は未知のもので、一度もその領域で働いたことがなければ未経験になるので
1ヶ月勉強した人も、3年勉強した人も、お金はもらっていない(労働ではない)けどエンジニアの方と一緒に開発した人も、一括りに「未経験」と捉えられてしまいます。

よほどの人でないと、業務の経験がない人には「育てる」ということが前提となるのは、企業側も求職者も同じ認識を持っているとは思いますが、その認識には大きなギャップがあるような気がします。

企業側の育てるというのは、「エンジニアとしての働き方」について教えることを考えてるのであって、プログラムの書き方を教えるということは考えていないという点で、求職者の持つ認識とのギャップを生み出してるような気がします。

つまり、プログラムは書けるけど、エンジニアとしてどのように立ち振る舞うかということについての動きにおいて未経験という枠組みに当てはめているように感じます。
少なくとも、プログラム自体は自分で学んで書いてくれというような。

とは言え、さすがにこれまで自分の思うままに書いてきた人に、野放しでプログラムを書かせることは社員として雇う上で無下な気がします。
プログラムを書く事に対しての成長自体は、求職者の意向を聞いた上で、目指すキャリアに合わせたタスクを(その人のレベル感を見つつ)割り当てること、というのが企業側が用意できる成長の機会であると思います。

プログラム自体の成長は、機会を利用して自分で成長する。
それ以外の働き方については、フォローをもらうという認識を合わせることが大事になるように思います。

これがお互いがウィンウィンになる考え方であると思っています。

企業は未経験者が何をしているのか想像しにくい

FPSゲームや格闘ゲームとかでもよくある話だと思いますが(ゲームをあまりした事がない方はすみません)
やっているうちに相手の動きというのが読めるようになります。
この動きをしたら相手は次にこうするだろう、だから自分はそれに備えてこれを用意しよう、と言った様に
相手の行動が読めると、その分安心感があります。

しかし、たまに相手が始めたばっかりの初心者になった場合、自分の想像した動きとは全く違う動きをする事があると思います。初心者は定石といった動きが入っていないため、定石で動くことに慣れた熟練者からすると定石外れの動きになるからです。
その時自分の動きもリズムが狂いますし、どう対処すれば良いか一瞬止まってしまいます。

これはエンジニアという仕事の中でも似た様なものがあると思っています。
ある程度の流れが掴めてる人同士であれば、タスクの消化には個々人の速さに違いはあれど、似通った行動になると思います。
PRを作る時、実装する際のプログラムを書く時に調べること、見るべきところ、報告すべき事はなにか、質問する時の書き方、聞き方など。
プロジェクト間で固有のルールはあれど、大体似た様な感じになるかと思います。

しかし、未経験にはそこの感覚がまだない状態なのでそこのギャップを埋める事ができれば、技術力が低くとも違和感が少なく働けるし、先輩エンジニアの方もやりやすいかと思います。

まずは企業側に、自分と一緒に働いた時のイメージがしやすい状況を作ることが大事のように思います。

ひたすら手を動かす

では、具体的にどう気をつければいいかについて書いていきます。

できるエンジニアはよく考えます。
考えて考えた末に出た結論をプログラムとして表現します。

しかし、未経験の人は経験がないため、考えても何も出ないことが多いです。
では、先輩エンジニアが後輩エンジニアにやって欲しいことはなんでしょう。

それはひたすら手を動かすことで経験を養って欲しいということ。
書いてはエラーを出し、そのエラーを解消し、また書いてはエラーを出し、というのを繰り返すことを指しています。
そしてそれを繰り返すことで勘所が養われたりします。
例え完遂できなかったとしても、手を動かし、やったこと(調べたこと)を先輩エンジニアに伝えることで、どこまでやってできなかったかが伝わります。
そこから、まだやっていないことを助言しやすくなることに繋がります。
その助言を蓄え、またひたすら手を動かすことができるようになります。

ひたすらエラーをググり、出てきた方法を試し、ダメだったら次の方法を探し、というのを繰り返してると
手を止めている暇がない状態になります。
未経験エンジニアの方が考えている時、何を考えているか先輩エンジニアは想像がしにくいのでひたすら手を動かしてくれる方が想像しやすく、働きやすいのです。

どのように手を動かせばいいか

上記で、手を動かすことが大事なのは分かったけども、どう手を動かせばいいか分からないという方も多いでしょう。
基本的にはまず、動くものを作るということに注力することが大事だと思っています。
そして、未知の技術だった場合、無から作り上げることは経験者でも難しいことが多いです。
では、無ではない状態をどう作り出すか。

以下に方法をいくつか書こうと思います。

• 同じ実装をプロジェクト内から探す
  全部とまではいかずとも、似た様な実装は必ずあると思います。
  ないような実装をいきなり未経験にお願いすることは普通であればしないからです。
  もしかしたら、先輩エンジニアから実装に入る前に、「こことここ、参考になるかも」といった助言があるかもしれません。
  もしなければ、IDE(統合開発環境)の機能を使って調べると良いでしょう。
  プロジェクト内を検索かけれるような機能など便利なものが備わっています。

• 記事などでイメージを掴む
  調べて出た記事を3、４つと読んでいき、既存のコードを見比べることでその処理がやっていることの流れのイメージを掴むことをする。
  すると、自分が作る実装に関しても、その流れを適用できるポイントが見えてくると思います。
  そしたら、実際に書くという手順に移れますね。

• 書き方はGitHubも参考に
  実際書き始めたはいいけど、この書き方でいいのか不安になることもあると思います。
  もちろん、先輩エンジニアに相談することもいいかと思いますが、できるだけ手を煩わせないために自分で調べたい。
  そう言った時には、GitHubの全てのコードから調べる検索機能があるので、そこで使うライブラリやフレームワークの名前を入れて検索をかけて、いろんな人の書き方を参考にしてみることをしてみましょう。

• 実際に書き始める前に見ておくと良い箇所
  インターフェースの仕様書などがあれば、見ておくと良いでしょう。
  どういったデータが必要で、どういったデータが手に入るのかというのをざっくり見ておくと、実装中に思い出して助けになることがあります。
  これは特に、プロジェクト固有の仕様に限らず、ライブラリやフレームワークに関してもドキュメントにあるインターフェースに目を通しておくと、思わぬ所で役に立ったり、既存のコードを読む際の助けになります。

コミュニケーション

エンジニアとして働く上で非常に重要になるソフトスキルが、コミュニケーションと言われています。
なぜコミュニケーションが重要で、どうしたら良いかを自分の視点から書こうと思います。

なぜコミュニケーションが重要なのか

昨今特にリモートで働くということが一般化したことで、各々の作業が見えていないことがコミュニケーションの重要性を高めてる様に思えます。
互いに知り合った人同士であれば、多少のコミュニケーションでも問題ない所も
新しく入社した人であったり、未経験者となるとコミュニケーションをうまくとらないと仕事もうまくいかず、精神的に辛くなる時もあるかもしれません。

どうしたら良いか

これまでも何度も書いていることではあるのですが
先輩エンジニアが想像できないという状況を作らないことがお互いにとってウィンウィンの状況です。

ではコミュニケーションでどのようなことに気をつけていれば想像しやすいかについて書こうと思います。

コミュニケーションをする時に気を付けること

よく言われてることではありますが、いかに読む側の負担を減らせるかという注意が必要のように思います。
もちろん、全てがうまくいくコミュニケーションはないので、いろんな手法で意思疎通を図る必要があるため、あくまで自分が行っている一例です。

コミュニケーションにおける大事なことはテンポだと思っています。
テンポ良くするためにどうするか。

• 質問をする時は、文字にした場合3~5行程度に収める
• ３回以上やりとりが続く場合は、音声でのやりとりに切り替える
• 質問の前に前提条件をあらかじめ箇条書きで伝える
• やりとりの中で完璧な答えを求めるのではなく、得られたヒントを基に再び自分で深く考える事を前提とする(聞かれた方も完璧な答えを持っていない事が多いため)

このように気を付けるだけで幾分コミュニケーションが楽になるように思います。
また、文面にする時でも気をつけておくと良いポイントもあります。

• タイトルをつける
  (例: 作業プルリクのURLをただ貼り付けるより、一つ上に「○○の作業」など付けるだけでも視覚的な理解度が上がります)
• Slackなどを使っている場合、文章が長くなりそうな時は詳細をスレッドにする
• あとから検索しやすいように大枠の議題について文字化しておく（例:「Github Actionsのキーについて」 など入れておくと後で検索しやすい）

このようなことも気をつけています。

最後に

いろいろと長く書いて来ましたが、基本的にチームで働く上で気をつけたり、念頭に置いている事になります。

僕自身もまだ、未熟なプログラマーでもあり、改善点は多いところもありますが
多少働いてきて、自分を育ててくれた先輩や企業に恩返しというのも含めて、これからエンジニアになる方、目指してる方の参考になればと思い、少しまとめてみました。

やはり、ギスギスした中で働くのはお互い良くないので、こういった小さい積み重ねからチーム全体の精神衛生を整えることがすごく大事だなということを学びました。