Enjoy Architecting

Twitter: @taisho6339

フルリモートメインのフリーランスエンジニアの活動記録 ~2019-05~

記事について

フリーランスとして開業し、 フルリモートメインで仕事を行ってきて7ヶ月ほど経過したので振り返りを行い、 何を考えて仕事を選択し、どんな学びを得てきたかを整理する。 これからフリーランスになる人や、フルリモートでフリーランスって実際どうなの? って人の役に立てると嬉しい。

どんなことをしてきたか

バックエンドのエンジニアとして、

  • GKEによるバッチの開発
  • GCPの環境構築の自動化(terraform)
  • GAE/Go+firestore+GKE on ElasticsearchによるCMSの開発
  • GAE/Go+CloudSQLによるコンシューマ向けWebサービス開発

といったGCPメインでインフラ構築、システム開発に取り組んできた。 基本的には自宅でSlack、HangOut、GitHub、JIRAなどのツールを用いてコミュニケーションを取り、 仕事をしてきた。

契約について

最初こそ請負で受けていたが、今は準委任契約がメインになっている。 毎月安定してお金が入ってくるという安心感と、継続的にチームで開発できるのがメリットである。 特に後者はかなり大きいメリットだ。 フリーランスは技術力が商品になるのだが、一人でもくもくとやっていても限界がある。 優秀な人から学べることはとても多く、新しい視点を与えてくれため自分の能力を効率よく高められる。

どこから仕事を得ているの?

基本直接営業していて、知り合いのツテで紹介してもらった会社にアポを取るか、 wantedlyで気になる会社、スカウトしてきた興味のある会社にたいしてとにかくメッセージを飛ばす、 といったことをして案件を獲得している。

エージェントも最初は検討していたが、

  • エージェントよりも自分のほうが、自分が受けたい案件の要件、自身の売出し方についてくわしい
  • 案件単価が安い
  • フルリモート案件が全然ない

といった理由で使うのをやめた。 これに対しwantedlyは正社員向けのサービスかと思われるかも知れないが業務委託の募集も多く、 フルリモートの交渉も結構通ることが多かったので現在はメインで活用している。 また、エージェントの案件はフルリモートだと単価を安めに設定されることが多いが、 wantedly経由で直接フルリモートの交渉をした場合は今の所希望どおりの単価で通っている。

仕事の選択方針は?

3つあって、

  • 単価が自分の希望に沿っているか
  • リモート可能か(最悪フルでリモートでなくても良い)
  • バックエンドエンジニアとして専門性を高められそうか

これらの基準で選んでいる。 上2つは省略するが、3つ目について少し説明する。

バックエンドとして専門性を高めるということ

前提としてフリーランスとしてやっていくのにフルスタックエンジニアはおすすめできない。 なぜなら、大抵の案件はバックエンド、フロントエンドといった棲み分けがされた状態で募集がされていて、 幅広くできても個々の深さが足りてないと高単価は狙いにくいからだ。 たまに全部ものすごい深さでできるスーパーエンジニアがいるが、自分のような凡才にはムリだ。 よってスキルを選択してフォーカスすることが重要になる。

では、バックエンドにフォーカスしたときに他者と差別化していくためにはどうしたら良いだろうか? ただ単にAPIの開発ができてDBにアクセスしてデータとってきて返せます、 だとこれから大量に流入してくるだろう初心者エンジニアと差別化が大してできない。 ポイントとなるのは、 「インフラ、ソフトウェアのレイヤーにそれぞれにおいて、与えられる要件に対して適切な設計、運用ができる」 ということだと考えた。 もちろん完璧な設計をするのはムリなので、ここでいう適切とは、

機能要件、非機能要件を満たすことができ、 ある程度のアジリティでエンハンスしていくことのできるシステムを作れるか

という基準だと考えている。 よって、

  • サービスに求められる非機能要求やSLAのレベルが何かしら高い
  • 高負荷
  • 大規模データ
  • 要件が特殊

といったようなプロダクトで経験をつもうと考え、選択している。

フルリモートをやっていて気をつけていること、大事なこと

基本的にここでいっていることと同じだ。

フルリモートで3ヶ月働いてみた振り返り

進捗、着手状況を常に見える化し、仕事のゴールと方針のすり合わせ、複雑なタスクは細かくレビューをもらって手戻りを防ぐ、 といったことを実践している。

フルリモートで良かったこと

自分はかなり内向的な性格で、日常会話レベルでも周りの目をどうしても気にしてしまい、 その場では言いたいことを言えなかったりする。 だが、家にいて非同期コミュニケーション中心の場合は整理してから伝えられるので、 言いたいことをはっきり言えてとても気が楽だ。 また、やはり人と対面するとエネルギーを消費するので(嫌いなわけじゃなく、性質の話)、 仕事以外の理由で疲れにくいというのは大きい。 これのおかげで朝勉強し、ジムに言ってから仕事をして、仕事後は個人開発、というリズムをあまりくずさずに実施できている。 独立する前、毎日会社に通っていた頃は常に息切れ状態で他のことをする余裕なんてまったくなかった。

フルリモートで良くなかったこと

フルリモート前提でプロセスが組まれていない限りどうしても気をつかわせてしまう

会議中にリモートの自分に配慮して、 Jamboardといった通話相手にもホワイトボードに書いたことを共有できるようなツールを使ってくれたり、 はっきり聞こえるように大きな声でゆっくり喋ってくれる人がいたりする。 ちょっと申し訳ない。

情報から隔離される

自分が知らない間に設計とか方針とかが会社で決まってしまうことがあり、プロジェクト全体を見通しにくい。 全体が見通せないと、ただの作業する歯車になってしまい、主体性を保ちにくくなってしまう。 なるべくissueやSlackのログや議事録を読んだり、オンラインでの議論に参加することで保っている状態。

まとめ

リモートメインでの活動は良い面だけでなくどうしても課題はある。 ただ、仕事を得られないとか、自分がしたいことができないといったことは幸いなく、 実際の開発プロセスでの課題に終始していることが救いだった。 リモート開発のメインの課題は情報の共有なので、うまくまわってるところはどういうふうにまわしているのかきいてみたい。