複(副)業をやってきての振り返り
Runtrip社で複(副)業（以後は複業で統一）を始めて、早いもので2年半が経とうとしております。
そこで、この記事では複業という業務形態でどんなことをしてきたのかを備忘録的に振り返ろうと思います。
そのため、この記事は下記のような方にお役に立てれば幸いですmm
・複業とか流行ってる？みたいだけど、世の中ではどんなことを複業でやってんだろ？（特に開発）
・Runtripって複業とかで関われるんだ！でも実際はどんなことやってんの？（特に開発）
（もちろん、複業には色々な形があるので、あくまで1つの事例として^^）
背景
Runtripで複業を始めたきっかけは下記の記事にまとまっておりますので、ご興味ある方は是非mm
その複業を始める上で、自分が考えたこと、かつRuntrip社と期待値合わせしたこと等に関しては こちらの記事 に記載しておりますので、ご興味ある方は是非Part2。
複業のイマ
Runtrip社では複業メンバーを PRO PLAYER というユニークな表現をしておりまして、多くの PRO PLAYER の方が所属しております（ちなみに社員のことを STAFF という表現をしているみたいです）
そのPRO PLAYERとしてインタビューしていただいた記事は下記になりますので、ご興味ある方は是非Part3（いい加減しつこいですね＞＜
余談ですが、この記事の写真を撮って頂いた方も、同じチームRuntripのPRO PLAYERの方です^^
これまでやったきたこと
Runtrip社では大きく3つのことにコミットさせていただきました。
①Androidアプリのフルスクラッチ開発
②非同期処理アプリケーション（batch系）をGo言語で作り直し
③インフラ（AWS）環境のコード化（infrastructure as code）
詳細は後述いたしますが、特徴としては 事業貢献度が高いもの から 緊急度は高くないが優先度は高い（技術的負債） もの まで幅広く担当させていただいたこと。そして何より、このようなことが複業という形（しかも週1〜2日程度）でもできるんだ！というのが、この2年半での驚きでした。その驚きの中？でやっていたことは下記になります。
①Androidアプリのフルスクラッチ開発
目的
Runtripで ジャーナル機能 というものがリリースされましたが、当時はiOSアプリしかありませんでした。
Androidユーザの方にも使っていただくため、ジャーナル機能に特化してAndroidアプリをフルスクラッチで開発することに。
技術的なお話
Androidに関しては、世の中の流れになるべく沿う形で開発。
開発言語はkotlinを採用し、なるべく純正ライブラリ（Jetpackなど）を使いつつ、その他は世の中でよく使われているOSS（通信、画像など）を導入するなど。
背景としては、新しくRuntripにJoinする方が増えた際、オンボーディングコストを避けるためにこの方針を取りました。
CI/CDに関しても、なるべく人手の時間を減らすため、下記のような構成に。
①CircleCIでlintやtestを実行（レビューコストや動作確認時間の削減）
②動作確認用アプリは、特定ブランチにマージすると、CircleCI→FirebaseのApp Distributionに配信
③本番リリース用アプリは、tagを切ると CircleCI → play storeに配信
この辺の構成なども、相談はしつつもですが複業メンバーに任せてもらえているのは素晴らしい環境ですね^^ ちなみのそのアプリは下記になります（宣伝）
②非同期処理アプリケーション（batch系）をGo言語で作り直し
目的
上記でも触れましたが ジャーナル機能 が多くの方に使われ出して、そこに纏わる非同期処理部分の負荷が高まってきたました（コスト的にも）。
今後もジャーナル機能は多くの方に使って欲しいので、この部分をスケールしやすくしておきたい！、ある意味技術的負債の解消をしておくことに。
技術的な話
当時のRuntripのサーバサイドは PHP + FuelPHP という構成で、この非同期処理も FuelPHP の Tasks を使って実現しておりました。
FuelPHP の Tasks が悪いとかではありませんが、どうしても現状の構成だとスケールがしにくい状況だったため、ここは思い切って変えてみようという話になり、「並行処理が実現しやすい」「コンテナ化し、それがスケールしやすい（スピードも含めて）」ということでGo言語で書き換えるという思い切った？決断をしますw
（世の中的には異なる言語で書き換えるというのは普通かもしれませんが、社員エンジニアが少ない中では、何かあった時に自分たちで見なければならないので、ある意味チャンレンジングな決断だったのではないかと想像しております）
Go言語での書き換えに関しても特別なことはしておらず、
①アプリケーション側でSQSからメッセージを取得
②goroutineで並行にメッセージを処理
ということを実施しており（細かい部分では色々とやっておりますが、詳細は割愛）、このアプリケーションをコンテナ（ECS on Fargate）にのせている、かつAuto Scallingも入れているので、スケールはしやすい環境になったと思います。
③インフラ（AWS）環境のコード化（infrastructure as code）
目的
こちらの一番の目的は 俗人化の排除 になります。
サービス立ち上げ当初からメインで面倒見てきた人しか知らないことが非常に多かったので、それをコード化して他の人でも知ることができる、かつ他の人でも作業ができる状況を作ることを第一の目標とすることにしました。
かつ人的オペレーション（ex. rsyncによる手動リリース作業）を減らすことで社員リソースをフォーカスすべきところに集中できるようにすることも^^
技術的なお話
前提として、Runtripでは AWS を利用しております。
コード化していくにはいくつかの方法がありましたが、世の中のトレンドも鑑みて Terraform を選択することに。その中でやったこととしては下記になります。
①既存環境をコード化（主にネットワーク周り）
②新しく構築するアプリケーション環境は ECS on Fargate で動かせるようにする
③CI/CD環境は完全自動化するために Code Pipeline + Code Build を採用
④②〜③の環境は、同じような構成になるので terraform の module + workspace を利用
Terraform化した時の詳細なお話は下記にまとめております。
Terraformのチェック機構（構文が正しいとかplanが問題ないかなど）は、 GitHub Actions で実施。
これらのことをしてきた結果がこちら。
既存の環境も徐々にコンテナに置き換わってきていて、新しい環境も基本はコンテナで動かせるようになってきております。
リリース作業も以前は手作業していたのが、GitHubにマージ or タグを切ることでリリースができるようになっています。
その他
今まで紹介した以外にも、Runtripでは下記のような取り組みも行われていました（直接関わっていない部分も多いので紹介だけw 他の PRO PLAYER の方が詳細は書いてくれることを期待）
・VRWC を新しく作る際、FEをReact.jsで構築
・上記の社内管理画面のFEをReact.js + TypeScript で構築
・データ分析基盤周りを Digdag + Embulk でBQ連携
・かなりの環境をコンテナに移行できてきたので、local環境で複数のコンテナを動かすためにk8s（kind）を導入
・k8s、terraformなどの複業メンバーが発表する勉強会
ここまでで、技術だけ見ると「世の中的には普通では？」と思われるかもしれませんが（それはそう）、これを複業メンバー、しかも週1〜2稼働のメンバーが中心となり実現できているのは、よくやってるなと感心させられますw（これらをハンドリングしている社員の方には感服&感謝しかない^^）
まとめ
技術要素のbefore/afterは下記。
■before
EC2、PHP + FuelPHP、rsync、etc...
■after
ECS on Fargate、PHP + Laravel、Go言語、Code Pipeline + Code Build、Terraform、Digdag + Embulk、React.js + TypeScript、GitHub Actions、etc...
書き出すとこんな感じですが、少ない社員、かつ稼働時間が限られた複業メンバーでもこのような変化を加えることができるのは素敵ですね^^
最後に
複業という形でも、チャレンジをしつつ（エンジニアでいうと技術的チャレンジ）事業に貢献できるというのは、とても素敵な働き方だなと感じております。
そして、社員の方が、フォーカスすべきところにフォーカスできるようになったという話も聞けると、会社への貢献度も高いのだなと感じることができます。
この記事を見て、「複業という形でも技術的なチャレンジや成長はできるんだ！」「Runtrip面白そう！」と思っていただける方いらっしゃいましたら、下記から是非お声がけください（番宣かっ！
拙い文章で読みにくい箇所があったかもしれませんが、最後まで読んでいただき、誠にありがとうございました。
この記事が気に入ったらサポートをしてみませんか？