この記事は、Qiita Engineer Festa 2023 の以下のイベント参加記事です。
この記事で書くこと
- 実務未経験でwebエンジニアとして働き始め1年経った感想
- 1年経ってどのような課題を感じているか
- 今後のキャリアについて今の視座で考えた結果
この記事で書かないこと
- ポエムなので技術についての詳細は書きません（すみません）
- エンジニアになってからの話に絞りたいので転職のためのノウハウも書きません
自己紹介
- 地方の社員数1桁の自社開発になりたい受託会社で働いています
- 30過ぎでプログラミングスクールや独学を経て実務未経験で入社しました
- PHP（主にLaravel）でWebの業務システムを開発しています
忙しい人のために3行まとめ
- 日々の業務の中で課題を感じていてまず、一人前にならなければという気持ちが大きく長期的なキャリアについて考えられなかったよ
- なので5年後までにどのようなアクションを取りたいかを今の視座から考えたよ
- 具体的には、技術もマネージメントもまあまあ出来て、各種コミュニティにも還元できる人間になりたいよ。技術に関して会社に積極的に提案していきたいよ。
キャリアの定義
まずキャリアってふわっとした言葉なので調べてみました。
「キャリア」とは、過去から将来の長期にわたる職務経験やこれに伴う計画的な能力開発の連鎖を指すものです。「職業生涯」や「職務経歴」などと訳されます。
引用元
本記事では厚生労働省のこちらの定義に従って記述します。
長期に渡って今後どのように経験を積んでいきたいかの計画と理解しました。
まず1年経った感想
感想書いたら全部、感じている課題の話になってしまいました。
フレームワークの知識は付いたけど、素のPHP分からん
私は、PHPを入社してから触りはじめたので、PHPの言語仕様を体系的に勉強したことがありません。
業務では、新規案件はLaravelを使い、たまーに、昔の案件のCodeIgniterを使ったシステムの改修や追加機能の実装などをしていて、つまりフレームワークの実装からPHP入門してしまったので、素のPHPについての理解が薄いなと危機感を感じています。
具体的には、フレームワークのヘルパー関数なのかPHPの関数なのか、調べないと分からなかったり、PHPマニュアルに出てくる用語が分からず、すらすら読めなかったり、など業務の中でヤバいなと感じることが多々あり、「今年中にPHP8技術者認定上級・準上級試験を取得します！」と会社で宣言しました。
出題範囲はPHPマニュアルなので、マニュアル読んだことないPHPerには良い試験だと思います。
試験対策も兼ねて独習PHPも買いました（まだ読んでいない）
素のSQL分からん
素のPHP分からんと似てる課題ですが、業務ではフレームワーク使った実装なのでORMを使ってクエリを書きます。つまり、素のSQLの理解が（以下同文）
SQLの前にRDBの理解のために以下の本を絶賛読書中です。
クライアントとのコミュニケーション難しい
入社から半年経ったころから、クライアントとのミーティングやチャットのやり取りに参加させてもらうようになり、クライアントからの要望事項見て「何が言いたいのか日本語が全く分からない…」となったり、逆にこちらから実装に関する回答をするときに「どう伝えたら技術に詳しくない人に伝わるか分からない…」となったり、日本語が一番難しいことを実感しています。
先輩のやり取り見てると、結局は経験値なのかなーと思いますが、開発してる時間よりクライアントワーク（作文したり、説明するためのエビデンス資料作ったり、ミーティングだったり）の時間の方が長くなってきつつあり、経験積んでいけば解決するでしょに頼っていては駄目で知識付けなきゃヤバいなと感じています。
この課題に関して今は、アクション取れてないんですが、何かせねばなと。
複数案件の並行が難しい
入社してしばらくは、一つの案件の対応が終わるまで他の案件は任されなかったのですが、最近は1日のなかで複数案件の作業したり、ミーティング参加したりしてて頭の切り替えが上手くいかないです。
まだコード書く業務はコード読んでいるうちに思い出すので良いんですが、仕様検討のミーティングだと「仕様そもそもどうだっけ？」って思い出すのとか、「この仕様なんで変更したんだっけ？変遷は？」とか、「思い出し工数」がかなり掛かっていて改善したい所存です。
テストコードが書けない
会社に「今期は自動テストを導入したいです！」と大見え切ったので、まず手始めに、自分の書いたビジネスロジックのテストコードを書こうとしたんですが、書けませんでした。
まず、テストの書き方をよく理解していないことと、テストが書けるような設計になっていないことで大敗北を喫しています。
そもそも、自動テスト導入したいと思ったきっかけは、案件が立て込んでコードレビューができなくなり、自分の書いたコードを自分で担保しなければならなくなったことが理由です。
手動テストですべての条件を網羅するのは現実的ではないので自動テストは絶対必要だと思いました。
テストが書けるようになることと、テストが書けるようなコード設計にすることは、今最も身に付けなければいけないと感じているスキルです。
人の書いたコードが読めない（読むのに時間がかかる）
自分でコード書くより、人のコードを読む方が難しいのは業務の中で初めて知りました。
コード書いてる時間より、コード読んでる時間の方が長いことも。
入社して日の浅いうちは、自分で一から実装することはあまりなく、既存のシステムへの機能追加や修正など小さな実装から任されることが多いと思うので、人のコードを読んでいる時間はかなり長いです。
人のコードが読めないというか読むのに時間がかかるのは、言語についての知識不足が一因だろうなと推測しています（PHPよりJavaScriptの方が読むのに時間かかるので）
上述したPHP技術者認定試験の勉強のあとはJavaScriptも体系的に勉強したいと思います。
そして、自分がコード書く時には読みやすく書こうと心がけています。
人のコード読んでここ分かりづらいなという経験を反面教師にして自分がコード書くとき気を付けたり、「リーダブルコード」を参考に、適切にコメントを入れる、適切な命名などを心がけています。
前提「健康」の大事さ
エンジニアになってから健康の大切さを実感しています。
業務中、具合が悪いことによる身体の痛みや不快感に脳のリソースが割かれると当然ながら効率が下がります。
休日も、具合が悪かったり、疲労困憊だと日常の家事止まりで勉強まで辿りつけません。
つまり、エンジニアとして仕事をしていくには、365日できるだけ健康な状態を保つことが大事だと実感しています。
自分が実践しているのは、睡眠を削らないことと、（強制しないと運動を継続できない運動嫌いなので）あえて出社にして会社まで歩くことだけですが
日々、腰痛、肩こり、眼精疲労との戦いには大体負けています。
自分の中での健康法を確立したいと切実に思っています。
上の記事とても参考にしてるんですが、スタンディングデスクにしようかな。
今後のキャリアについて
ここでもう一度キャリアの定義
「キャリア」とは、過去から将来の長期にわたる職務経験やこれに伴う計画的な能力開発の連鎖を指すものです。「職業生涯」や「職務経歴」などと訳されます。
引用元
本記事では厚生労働省のこちらの定義に従って記述します。
長期に渡って今後どのように経験を積んでいきたいかの計画と理解しました。
ということで考えていきます。
が、キャリアについて考えようと思ったら事件発生
長期に渡っての視座が足りないことに気づきました。
1年後くらいまでしか今の自分には見えていないし、考えられない…。
これって喫緊の課題である技術不足をある程度解決し、バックエンドエンジニアとして一人前になるまでは、長期に渡ってのキャリアなんて考えられないのでは？
詰んだ…。
ということで、気を取り直して、今の段階では5年後が限界なので、5年後までのキャリアを考えてみます。
5年後には、視座が高くなり新しい地平が見えて長期的なキャリアを計画できることを願って…。
会社に新しい技術を提案し取り入れてもらうことが楽しいので続けていく
最近、自分が提案してGitHub Copilotを会社で導入してもらいました。
Software Design読みたいです！と言ったら会社で定期購読してもらいました。
他にも、各社員のそれぞれの学びを共有する場が無かったので以下の記事を参考にさせていただき「朝礼で共有する時間を設けたらどうか？」と提案し、現在実施しています。
最初は自分が、もっとこうだったら嬉しいなーという気持ちで提案したんですが、上司との面談で「いつも新しい技術をキャッチアップして紹介してくれてありがたい」と言っていただいたり、社内の皆さんに「使ってみたらめっちゃ良かったよ！」と言ってもらえるとすごく嬉しいので、技術的に未熟であるという遠慮はいったん脇に置いておいて、新しい技術や取り組みなどを今後も提案していきたいと思います。
後輩ができたときにいい先輩で居たいのでマネージメント分野も伸ばしたい
エンジニアのキャリアとして一般的に、技術に特化したテックリードを目指す道と、マネージメント方面に進む道とがあると言われてます。
引用元：
ただ、弊社のような社員数1桁の小さな受託会社では、技術やマネージメントに特化した人材より両方をある程度こなせる人材の方が必要なのは明白です。
（実際、社長が採用や総務やりながらバリバリコード書いているので）
将来、会社の規模が大きくなりテックリードやマネージャーといった役職が必要になるかもしれませんが、現在1年に一人ずつの採用ペースであることから、それは少なくとも5年以上先のことではないかと考えています。
つまり、目下のところマネージメントの知識も必要です。
現在は、自分が一番新しく入社した人間なので後輩が居ないですが、積極的に採用活動をしているので近いうちに後輩ができることが予測されます。
小さな会社にとっては人一人雇うのも、辞めるのも大きなインパクトです。
将来マネージメント方面に特化するかは決まっていませんが、後輩が短期で辞めないようにサポートする力は必要だなと思うので技術の勉強と並行してマネージメントというかまずはコミュニケーションについての知識をつけていきたいと思っています。
お世話になっているコミュニティに恩を返したい
普段一方的に皆さんの知見を享受してばかりなので、自分の得た知見を還元してきたいです。
具体的にはQiitaやZennなどへの技術記事の投稿（今回はポエムですみません）や、PHP関連の技術イベントへ登壇することや、オンラインでLTすること、お世話になってるOSSへの寄付やコントリビュートなどです。
そもそも、エンジニアになりたいと思ったきっかけは、知見をみんなで共有しようという文化に感銘を受けたからなので、これは、長期的にというかエンジニアである限り常に、目指していきたいなと思っています。