自社開発企業でフロントエンドエンジニアしている@Mayuko_Yamagishiという者です。
未経験転職して早 1 年経過したので、振り返りをつらつらと書いていこうと思います ☝️
① 1 年目でやって良かったこと／感想
1. クリーンコードを知る
1 年目でクリーンコード抑えられてホント良かった!!!
と思っています。
クリーンコードとは、名前の通り「綺麗なコード」の意味ですが、
具体的には下記のようなコードを指します。
・変数が適切な名前になっている。
・楽に読むことができる。
・一貫した規則性がある。
・冗長な記述がない。
・拡張性に優れる。
・既存機能の改修がしやすい。
・テストコードが書きやすい。
半年経過したくらいに、CodeMafia 先生の講座をたまたま発見して学び始めたのがラッキーでした ✌️
クリーンコードを網羅的に解説してくれている教材で、1 年目でこれ抑えてないとちょっと恥ずかしいと思うレベルで、ここで学んだことはめちゃくちゃ役に立っているし、必ず意識してコード書くようにしてます。
私は社外エンジニアと交流することがあるのですが、自分より経験ある人でも「意外とこの観点抑えられてないな〜」 みたいなことが割とあるので、1 年目のうちに本気でおすすめしたい教材だなと思います。
命名はいつまで経っても難しい。
😺 <大切なことは全て CodeMafia 先生が教えてくれるんやで~
2. レビューのリードタイム改善した
チーム全体で「開発生産性上げよう！」という動きがあり、一つの計測指標として レビューリードタイム（レビュー着手までの時間） がありました。
そこでチームで下記を導入することになりました。
- Findy team+を使った生産力の見える化（計測）
- GitHub の Projects 機能を使ってレビュータスクの管理
結果、直近のプロジェクトと前回のプロジェクトを比較したところ、
レビューまでの着手時間を、約 180 時間程短縮させることができました 🎉
これまでの私はレビュー着手までのハードルが高く、止めてしまっている自覚すらもあったのですが、「早く着手する！」と意識するだけでこんなに変わるんだな〜、とちょっと感動しました。
😺 <あと、Findy team+を見ると数値が日々改善していく楽しさもありましたね！
※Findy から何も受け取っていません。
3. PR の粒度を細かくした
レビューのリードタイムに関連して、PR の変更行数（PR の粒度） という指標もあります。
PR は大き過ぎるとレビューに時間がかかるし、修正事項も多くなるし、見落としが発生しやすくなる等の弊害が起こり得るので、なるべく小さくするよう工夫しました。
結果、直近のプロジェクトと前回のプロジェクトを比較したところ、
平均変更行数 191.2 行 → 125.2 行（70 行程）減らすことができました 🎉
元々そんなに大きい PR を出していたわけではない（React の思想的に大きくなり辛い）のですが、PR が小さい程レビューリードタイム短縮に繋がっている実感があります。
一方で、小さくすると脈絡がわからなくなるというデメリットもあるので、「この処理はここで使ってます」というような補足コメントとコードの明記をするようにしていました。
😺 <レビュワー側の視点に立つのも大事ですね...！
4. コミットメッセージに理由を書く
プライベートで親交のある先輩エンジニアが、「コード見れば何をしてるのかはわかるから、何故変更したのか理由を書いて欲しい」と言っているのを聞いてから書くようになりました。
現職は密にコミュニケーションを取る文化なので、実装意図がわからなくても直接聞ける環境ではあるのですが、 複雑な実装や、仕様の都合であえてこうしている時には理由があると大変助かります。
🙀 <同じ会社に何十年もいるとは限らないですしね
とはいえ全てのコミットにつけるわけでもなければ、プロジェクトの方針もあると思うので必須ではないと思っています。
5. 相手の視点に立ってコミュニケーションとる
PdM に仕様確認する時、テキストだけではなく、なるべく実際の画面や図解を用いるよう工夫していました。
例えば、直近のプロジェクトでは仕様変更が必要な箇所があったので、before/after の画面スクショを用意し、仕様変更が必要な理由を添えた資料を PdM に確認していただいたのですが、この動きが良かったとテックリードから good 評価いただきました 😊🙌 \ﾜｰｲ/
😺 <テキストって読むのに負荷がかかるし、すれ違う可能性もあるので、丁寧にし過ぎてもし過ぎることはない心意気でやっています！
あと自分が意識していることとしては、仕様確認する時に PdM に丸投げするのではなく、なるべく自分の考えも添えるようにしていることです。
これは開発的な観点を伝えると同時に、比較する案（考える基準）があった方が、PdM 的に検討しやすいのではないかと思っているからです。
😺 <「今日の晩御飯なにが良い？」と聞かれるより、「ちょっと時間かかるカレーか、すぐに食べられるハンバーグどっちが良い？」と聞かれる楽さに近いですね（たぶん）（しらんけど）。
② 1 年目でやれば良かったこと
1. 既存コードの熟読
これはプライベートで親交のある先輩エンジニアが、「1 年目の頃は早く活躍したくて、休日に既存コード読んだりしてた」と言っていたんですよね〜〜。
最近この言葉がすごく刺さる出来事がありました。
「これエラーになってしまうんだけど、他に良い実装方法が思いつかないんだよな、、」と思った時に先輩エンジニアに相談してみたところ、
先輩つよつよエンジニア：「既存コードだとこうしてますね 😺（秒）」
ワイ：「ｱｯ、、😇」
えも言われぬ気持ちになりました。
自社開発企業の良いところの 1 つは先人達の知恵が蓄積されていることなので、まずは宝庫を当たりに行くべきだったなと。
それに 1 年居て把握していなかったのもちょっと情けないなと思いました。
😿 <愚者は経験に学び、賢者は歴史に学ぶのですね...。
2. 状態管理ライブラリの扱い方をちゃんと学ぶ
全くわからないわけではないけど、説明しろと言われたらきっと困るのが状態管理ライブラリ。
1 年目でちゃんと学んでおきたかったものの 1 つであります。。
既存コードは何をやっているのか理解してるつもりだし、直近のプロジェクトで実装できたけど、自分の中でまだまだ苦手意識がある分野です。
今年 10 月中にはちゃんと理解しようと思います 😇
3. テスト書く習慣をつける
現職はテストを書く文化がまだ確立されておらず、必要に迫られていないという理由でキャッチアップしてきませんでした。
これも 1 年目でちゃんと習得しておきたかったものの 1 つです。。
キャッチアップは勿論のこと、フロントエンドのテスト運用ルールみたいなものも作っていきたいなと思っています（← これ系のやった方が良さそうなことを主導しやすいのは、自社開発スタートアップの良いところだなと思います！）。
来 Q はテスト入れられるようチームで動いていきたい...！
4. パフォーマンスを考慮したコードを書く
今の自分の実力的には、目的のものは作れるけど、パフォーマンスを考慮したコードを書くのはまだまだのレベルだと思っています。
実装のバリエーションが少ないのですよね。
こういう力はどこで育むのか...🤔
まだ対策が出せていないのですが、最近はテックリードにあれこれ教えていただいています。
🙀 <何か良い方法があれば教えてください。
5. フロントの PM 力をつける
今はフロントエンドの PM のような役割をやらせていただいているのですが、
直近のプロジェクトではスケジュールが遅延した時に、チーム全体の PM とテックリードに任せきりになってしまいました。
時間さえあれば解決する問題で対応策がわからず、身動きできなかったなと反省しています。
PM にこの話をすると、「フロントのコミュニケーションのハブになることを期待していた（できていた）」と言われたのですが、自分の期待値には達せていないので悔しいポイントであります。
今回の PM とテックリードの対応策を学びに、次回以降は自分が動けるようにしたいと思います 👿🔥
おわりに
キャッチアップ力は自分の課題であると自覚しつつも、やるべきことは挙げたらキリがないので、優先順位をつけてやっていくしかないですね...！
今 Q の反省点として、新しいことをキャッチアップするのに熱意で頑張ろうとしたところがあるので、自動化して脳死でキャッチアップする習慣をつけたいなと思っております（熱意は常時あるものではないので） 🫡
振り返ってみれば、未経験転職した最初の会社として良い環境でスタートさせてもらったなと思います。
半年経過した頃にフロント人材が私ひとり()になってしまったのですが、「自分でなんとかするしかない」という気持ちが私を粘って考えさせてきたなと思っています。
今は FE をハンドリングできる楽しさもありますしね 😊
また 1 年後良い振り返りができるように頑張ります〜！
自己満な記事を読んでくださってありがとうございました 🙇♂️