副業を始めた理由
はじめまして、サイボウズ株式会社に所属しているじまぐ（@nakajmg）です。フロントエンドエキスパートチームのメンバーとして、サイボウズ製品のフロントエンドを横断的に支援しています。
▲イベント登壇時の写真
これまで本業の傍ら、フロントエンドの副業を複数受けてきました。今回はその経験から得られたものや、これから副業を検討される方に向けての注意点を紹介します。
まず私が副業を始めた理由は2つ。家賃を副業の収入でまかなえるようにすることと、本業では経験できないことに挑戦してスキルアップを図りたいと思ってのことでした。
副業を始めようと思った当時、私はクライアントワークをメインとしているWeb制作会社に所属していました。クライアントワーク自体は楽しかったのですが、納品して終わりという業務を続けているうちに、自分のスキルの伸びに危機感を覚えるようになりました。
転職という手段も考えましたが、所属していた会社は好きでしたし、クライアントワーク自体にも不満はありませんでした。こういった状況から、自社サービスを開発しているスタートアップで副業することにしました。
これまでの副業を振り返ってみて
副業を通して、自社サービスを成長させていくプロセスや手法を多く学ぶことができ、スキルアップとともに自身の視野を広げることができました。家賃を副業の収入でまかなうという目標も達成できました。
そして副業という立場で関わっていくうちに、副業には人脈を広げるという側面もあることに気づきました。私が副業で関わったスタートアップには優秀なエンジニアも在籍していて、刺激を受けることが多々ありました。
この狭い業界ではそういったエンジニアとの繋がりはとても貴重に思います。繋がりだけであれば勉強会などでも作れますが、一緒に働いたことがあるという繋がりは、ただの顔見知りとは違った価値があります。
サービスのステージに応じた役割の変遷
私が副業で関わったこれまでの案件の中には、開発しているサービスの変化に応じて「求められる役割」が変化していったケースがあります。
その中でも、某HR系スタートアップ企業でのケースをご紹介します。こちらのスタートアップでの稼働は、Twitterで副業募集の投稿を目にしたのがきっかけでした。
その募集には、Vue.jsを使った案件であることや、オフィスが自宅から近かったこともあり、すぐに代表やCTO、開発メンバーと面談し、その翌週には稼働し始めることになりました。
ちなみに契約時点では特に決まった役割はなく、フロントエンドの領域で力を貸して欲しいとのことでした。
正式リリース前後：Vue.jsの技術的負債の解消とガイドの作成
私が関わり始めたのはサービスが正式リリースされる少し前のタイミングでした。基本的な機能は実装されていたものの、リリースに必要な機能が揃っていない状況でした。このときの私の役割は既存実装のリファクタリングやアーキテクチャの見直し、ガイドラインの制定といった基礎固めと追加機能の実装でした。
このサービスはAPIがLaravelで作られていたこともあり、フロントエンド側はLaravelと親和性の高いNuxt.jsを使って実装されていました。ただ、フロントエンド側は速度優先の突貫作業だったのか、改善の余地が多くみられるような状態でした。
特にAPIとの接続部分は近いうちに負債として顕在化しそうな箇所だったので、積極的にリファクタリングして改善を進めました。また、プロジェクト内のコードに統一感をもたせられるように、開発メンバーと話し合ってフロントエンド実装のガイドラインを定めました。
このプロジェクトでは私はフロントエンドを専任していて、APIの実装についてはほかのメンバーが行う体制でした。メンバーとのコミュニケーションはSlackが主だったのですが、初期のころはオフィスに出向いて直接ミーティングを行ったりもしていました。
ちなみに、正式リリース後も機能の見直しや追加機能の実装も頻繁に行っており、このときは月90時間以上を副業にあてていました。
リリース後の安定期：Vue.js特有の視点からレビュー
リリースして数ヶ月が経過したころ、私は現職のサイボウズへ転職しました。本業をおろそかにしたくはないと思い、副業先と相談のうえで月の稼働時間（目安）を40時間程度にするなど、契約内容を変更してもらいました。
稼働時間が変わると、私に求められる役割も少し変化しました。機能の実装に時間を費やすというよりも、どう実装していくかといった設計やアーキテクチャの部分を考えたり、ほかのメンバーが実装したものをレビューするのが主だった役割となりました。
Nuxt.js(Vue.js)はある程度の規約こそあるものの、ページやコンポーネントは作ろうと思えば雑に作れてしまいますので、一貫したコードスタイル、パターンでよりよい実装にするという視点からコードレビューを行っていました。特にcomputedとgettersの使い分けや、methodsの粒度など、後から見たときに迷わないような実装になるように意識していました。
このときは本業の業務時間が終わったあとに数時間レビューをしたり、土日のどちらかを稼働にあてるといった働き方をしていました。コミュニケーションはオンラインで完結させて、オフィスに出向くことはほぼなくなりました。
コロナの影響：コードレビューに専念
2020年3月、副業先の方から契約について相談したいというメッセージが届きました。ある程度は想像していましたが、契約稼働時間を減らせないかといった相談でした。コロナ禍において今後の見通しが誰にもわからないような状況ですので、快く承諾しました。契約の内容としては月の最大稼働時間を10時間に定めるというものでした。
月10時間の稼働だとやれることは限られてきます。追加機能の実装など、時間がかかりそうなものを担当するのは難しくなりました。相談の結果、私はフロントエンドのコードレビューに専念することになりました。業務後などに数分〜数十分でプルリクエストのレビューを行っています。
自分の状況や社会の情勢によって、求められる役割が柔軟に変わっていくというのを身をもって体感できたのはいい経験でした。
>> [新着] Vue.jsの副業・転職の求人を見てみる！ お気に入りの求人を見つけて応募しよう！
副業を進める上で気をつけていたこと
私が副業を進める上で気をつけている点がいくつかあります。
しっかりレスポンスをする
コミュニケーションの方法は関わり方やプロジェクトによって変わりますが、自分宛てに来たメッセージに対して漏れなくリアクションをするように心がけています。
副業という性質上、メンバーとの関わりは本業と比べると時間的にも空間的にも限定されます。そういった状況でお互いがお互いを信用・信頼して気持ちよく働けるようにするにはしっかりレスポンスをすることが大事だと考えています。
働きすぎない
実装が楽しかったり、開発の期限が迫っていたりすると、ついつい時間を忘れて没頭してしまいます。それ自体は悪いことではないですが、睡眠時間を削ったりプライベートの時間をすべて費やしたりすると、収入が増える代わりに失うものが多いです。
私の場合は倦怠感やひどい肩こり・腰痛に悩まされることになりました。その結果、通院したり椅子に座るのもつらくなったりといった状況に陥ることもありました。
生活を豊かにするつもりで始めた副業で健康を失ったりするのは本末転倒です。まだまだ働けると思っても、休む時間や仕事以外をする時間は意識的に取ることをおすすめします。
副業をやってわかったこと
副業を経験してみてわかったことも色々とありました。
▲副業で得た報酬はコレクションに
関わり方には幅がある
サービスのステージに応じた役割の変遷で紹介したように、副業での関わり方には大きな幅があります。がっつりとコミットする関わり方もあれば、レビューだけをするといった関わり方もあります。
副業を始める前は週20時間くらいコミットができないと副業を探すのは難しいのかな？と漠然と思っていましたが、実際に経験してみるとそうではないことがわかりました。自分のできることや使える時間に応じた関わり方にマッチする現場があることが知れたので、今後のキャリアや生き方としていろんな選択肢が考えられるようになりました。
いろいろな人からの刺激
副業のイメージとして、タスクをもらってそれをこなすだけというイメージを持っていました。しかしながら実際にはメンバーと意見を交わして案を出したり、自分から改善点を見つけたりするといった経験ができました。
エンジニアメンバーとの交流はとても刺激をうけることが多く、学びになることもありました。また、エンジニアだけでなく、セールスやカスタマーサクセスといったエンジニア以外のポジションのメンバーからも刺激を受けることが多々ありました。
契約時に気をつけること
契約時にこうしておけばよかった、と後になって思うことがあります。
ミーティングの頻度や参加条件
とある副業で関わった案件では毎週対面での定例ミーティングがあり、参加がほぼ強制されていました。次にやることはそのミーティングで決定され、仕様についてもそこで話されていました。
最初こそ参加することに意義を見出せていましたが、プロジェクトの向かう先が変わり、ディレクターの方が交代したこともあって、私が手伝えることも少なくなっていきました。ミーティングに参加しても特に発言することがない日もありました。
移動時間や準備してる時間は稼働には含まれないので、次第にミーティングをコストとして認識するようになり、欠席することが増えました。副業という関わり方であったことから、ミーティングについて相談することが憚られる状況でもありました。
新しいディレクターの方はそういった私の動きがお気に召さなかったようで、嫌味のようなことを言われることもあり、結果としてそのプロジェクトからは手を引くことになりました。
今でこそオンラインでの参加に難色を示す人は減ったのでいろいろな選択肢がありますが、ミーティングの頻度や参加条件といった部分については契約時にあらかじめ確認しておき、お互いの認識を合わせておけばよかったなと感じています。
チーム構成や意思決定のプロセス
プロダクト開発チームの一員として関わる場合、仕様や新機能について、意思決定のプロセスがどうなっているか事前に確認するのが大事だなと思うことがありました。
チームで話し合って決めたことが、ディレクションサイドのメンバーの独断で覆されたり、開発メンバーとディレクションサイドの間でコミュニケーションを取る機会が極端に少ないといったことがありました。
メンバーがディレクションサイドに不信感を持っているような状態で開発を進めても気持ちよくはありませんし、得てしてそういった現場では開発メンバーには裁量がないことが多いです。
単価などの労働条件の確認も大事ですが、ストレスなく関わるためにも、組織やチームとして健全な状態かどうかを契約の前に確認しておくとよいと思います。
副業を依頼したい企業は思ってるより多い
案件に区切りがついたタイミングや、稼働が減ったタイミングでは新しい副業先を探すことになります。
私が最近試したやり方はTwitterで募集することです。自分のこれまでの経験やスキル、やりたいこととやらないことを簡単にまとめて、そのレジュメとともにフロントエンドの副業を探しているという内容をツイートしました。リツイートしてもらえたことで多くの人に届いたようで、いくつもの案件の相談をいただけました。
フロントエンドの副業先探してますhttps://t.co/wUDUqUnwBf
よろしくおねがいします♀️
— じまぐ (@nakajmg) May 26, 2020
プロジェクトの走り出しやリニューアル、フロントエンドのアーキテクチャについての相談、新人のメンタリングなど、相談内容はいろいろでした。副業でもいいから関わってほしい、手伝ってほしいという企業は思ってるよりも多いようです。フレームワークの内訳はVue.jsとReact.jsが半々くらいでした。
Twitter以外の方法として副業のマッチングサービスなどもいろいろと出てきています。副業を探すハードルがどんどん低くなっているのを肌で感じていますので、副業をしたいなと思っている方がいたら、まずは話を聞く機会だけでも作ってみてはいかがでしょうか。
