【2022 年】フリーランスエンジニアの４年目振り返り

どうも、Nash です。

この記事は「フリーランスエンジニアの４年目の振り返り記事」です。

去年の活動についてはこちらになります。

３年目フリーランスエンジニアの活動を振り返りする【2021 年】

では、今年度の活動を見ていきます。

フリーランスの活動報告

今年度はフリーランスエンジニアとしての活動比率はかなり少なめでした。

理由は、数年ぶりにフルタイムで就職したため本業の比率が高かったのが大きな理由です。 他にも、カナダでのビザの申請・事務手続きなどプライベートでもやることが多かったのも理由です。

今年度の主な活動は、こちらについてになります。

  • 不動産テックのモバイル開発＋ EM

では見ていきます。

不動産テックのモバイル開発＋ EM

今年も去年から引き続き、不動産テックのスタートアップにて副業として働いていました。 今年度は、技術顧問寄りに近いポジションかと思います。

今年度のチャレンジとして、下記のようなことをしました。

  • プレイヤーから１つ上のレイヤーで活動
  • マネージャー寄りのロールで活動する：EM（エンジニアリングマネージャー）

具体的な活動内容について見ていきます。

RTKQ へのリプレイス（フロントエンド）

RTKQ へのリプレイスと、チームメンバーへレビューなどを通してレクチャーをしました。

去年、Reudx の実装について RTK へのリファクタおよびリプレイスをしていました。

Plain な Redux を段階的に RTK へリファクタリングする心得

この RTK へのリプレイスが完了したので、次のステップとして RTKQ へのリファクタ・リプレイスを行いました。

RTKQ は、RTK が提供しているクエリ系のステートマネジメントです。 同様のライブラリとして、TanStackQuery や SWR などがあります。 ただ、下記の理由で他のライブラリに差し替えることはしないで同じ RTK の中の機能である RTKQ を利用することにしました。

  • 既存の Redux コードから段階的にリプレイスしたい
  • １つのアプリ内で２つのサービスがあり、それぞれで Redux を使っているので他のライブラリに差し替えるコストが高い。
  • RTKQ 自体が後発なため、API の設計が良さそうに見える。

リファクタの所感として、すでに RTK が入っている状態から RTKQ を導入するコストは他のライブラリを入れるよりも遥かに低かったので、この選択は良かったかと思います。 ですが、差し替えるコストはこれらの理由でそれなりにかかりました。

  • チームメンバーが RTKQ などのクエリ系ライブラリに慣れていない。
  • リプレイスしたいロジックが他の RTK のロジックに依存していると、Hook ファーストである RTKQ へ完全に以降できず、過渡期は RTK による Redux の生ロジックを使わないといけない
  • RTKQ が予期しないタイミングで発火したり、レンダリングの最適化が必要な問題がでてくる。

結果として、ある程度のコストを支払ってリファクタを進めましたが、コード量が劇的に減り、ロジックも Hooks ベースになったため支払ったコスト以上に導入メリットがあったと思っています。

Go で API の実装（バックエンド）

Go による API の実装を行いました。

実装した内容は、簡単な API の作成になります。 バックエンドはクリーンアーキテクチャにより複数階層のレイヤー持っており、自分が触ったのはかなり浅い箇所のみになります。 最終的に、フロント側にデータを返す API を作成しました。

仕事で Go を使った肌感として、こういった印象がより強くなりました。

  • 読みやすい言語
  • 書く楽しみがやや薄い言語

いままでプライベートで Go 自体は触ったことがあるのですが、仕事で使ったのが今回がはじめてになります。

その言語特有の哲学にできる限り合わせるべきかと思っていることもあり、できる限り Go らしく書いていたつもりです。 ただ、この Go らしい書き方がどうしても「個人的な好みとズレているなー」というフィーリングがあったのも事実でした。

PR レビュー（技術顧問）

モバイルチームのメンバーが作成した PR のレビューをかなり行いました。

いままでは開発・実装する比率が高かったのですが今年度はレビューをする比率が上がり、実装者からレビュワー寄りのロールで活動していました。

レビューにあたってかなりの数を見てコメントしてきたので、こなれてきた感があります。 これだけやると、自分なりのレビュー哲学みたいなものも固まり、判断に迷う・考えるということがなくなるため、ほぼノータイムで捌けるようになったように思います。

とはいえ、レビューコスト自体はたいてい甘く見積もりがちなのは注意したいです。

チームメンバーへの 1on1（EM）

モバイルチームのエンジニアメンバー全員に自分が 1on1 を行っていました。ロールとして、エンジニアリングマネージャに近いかと思います。

背景として、モバイルチームにて短いスパンかつ定期的にメンバーの考えを拾えるような施策がない、などの理由などで 1on1 を始める提案をしました。 自分としても、エンジニア寄りだけでなくソフトスキルを使うマネージャー寄りのロールをやりたかったのでいい機会だったです。

頻度は、隔週を目安に行いました。 1on1 の回数が多すぎてもお互いに負担だし、少なすぎると近況の話す内容が膨らむのと、前回会話した内容を忘れてしまうので多すぎず少なすぎない回数にしたかったのが理由です。結果として、この頻度はちょうど良かったと思います。

メンバー数について、チーム移動や入脱退などもあるので時期ごとに増減していましたがおおよそ 5〜7 人になります。

内容としては、こういったものでした。

  • ティーチングではなくコーチングを重視。質問して相手に考える機会を作る。
  • 仕事・開発を円滑にするため、いまある問題の対策を考えたりそもそも問題自体を顕在化する。
  • キャリア論や人生観を固めるため、質問するので答えてもらう。

学んだこととして、「人によって 1on1 の進めかたはカスタマイズの必要性があり、そのためにも相手の特性をできる限り早く把握すること。そして、その特性にあった進め方を実行するのが大事」ということでした。

最初は、できる限り均一化したフォーマットで自分の振る舞いも人によって変えることなく 1on1 をしていました。 ですが、メンバーによってはうまく回ることもあれば、そうでないケースがあることも肌感として理解していきます。 そのため、徐々に相手に合わせたカスタマイズしていきました。

具体的には、こういった内容です。

  • 相手の経験が浅い場合は、コーチングからティーチングへ比率を高める。
  • 相手が喋るタイプなら、質問によって会話の方向性の手綱を握る。
  • 相手が寡黙なタイプなら、相手が喋りやすいような質問を多くして発言量を増やす。

いまのところ、まだ自分の 1on1 の経験数が少ないため「こういう人にはこういうアプローチがいい」というバリエーションと質について伸びしろはあると思っています。 ですが、成長した点としては、自分なりのベースとなる 1on1 の方法論が固まってきたことと、そのベースを元にどうカスタマイズしていけばいいのかという感覚は掴めてきたと思っています。

この 1on1 の対外評価としては、クライアントからは「モバイルチームだけでなく Web フロントのチームでもやってほしい」という依頼も貰えたので一定の評価はもらったと思っています。 結局、本業が忙しくなりすぎてこの依頼は受けられなかったのですが、機会があればこの活動は続けていきたいと思っています。

おわりに

４年目フリーランスエンジニアの振り返り記事でした。

例年に比べて活動内容が少なかったのですが、それでも書き出すと思ったよりもいろいろな内容を経験をしていることに気付いて驚いています笑。

来年も引き続き、フリーランスとしての活動はしていこうと思うので、来年の振り返り記事ではどんなことを経験し学んでいるのか楽しみです！