フリーランス1社目の契約を満了した

開業以来お世話になっていた企業との契約が2017年3月末で完了しました。

• 期間: 2016年06月 - 2017年03月 (10ヶ月)
• 担当: サーバーアプリケーション開発(ToCスマホアプリのバックエンド)

参画した日がちょうどサービスローンチ日。 出社して席についた時「ちょうど公開したところなんです」と言われたことが強く印象に残っています。 それから2回ほど契約を延長いただき早10ヶ月。3月末で無事契約を満了することとなりました。

コンシューマー向けスマートフォンアプリ(iOS/Android)のバックエンドAPIの開発運用を主に担当しました。 開発チームのなかで、バックエンドAPIまわりの担当は1〜2人と少人数体制でした。

橋渡し的な役割

初期はローンチまで開発を担った社員の方から徐々にタスクを引き継ぎつつ、ローンチ後の足場固めを行いました。 中期になると単独でバックエンドAPIまわりを担当し、新規機能追加や日々の運用を行いました。 後期は新しく社員の方がJOINされたのを契機として、主開発者としての引き継ぎやコードレビューによるサポートを主に行いました。

全体を通してみると、社内の開発リソースが確保できるまでの橋渡し的な役割を果たせたのではないかと思います。

Go in production

これまでGoは趣味プログラミングや社内向けの簡易的なツール程度に使った事しかなく、本番稼働するGoプロダクトの開発は今回が初めてのケースでした。 ディレクトリ構成やインターフェース定義といった詳細なものから、ビルドフローやデプロイ方法まで、開発サイクルをまわすためのノウハウを学びました。 基本的には他のメンバーがすでにレールを敷いてくれていたので、自分はその上を走っていただけですが。

Goのテストまわりはまだまだ未成熟で、記述スタイルに多様性が生まれやすいかなというのが率直な感想です。 がっちりフレームワークによるサポートがあるわけでもないので、その点は模索が必要であると感じました。

Microservices in production

携わったシステムはMicroservices構成をとっていました。 アプリの動作に関わるAPI系だけでも10数個のサービスから成り立っているため、全体を俯瞰するとそれなりの規模感でした。

ローンチ時点でMicroservices構成をとっているサービスはまだまだ少ないと思います。 チーム構成とシステム構成は密接に関係するため、現状の少人数なチーム構成を鑑みても改善の余地はあるかもしれません。

ただ、新メンバーにとっては初期の関心事を限定できるというProsも確かに感じましたし、 データアクセス経路を整然としたものに維持していくためにも有用なものと言えるでしょう。

初期段階での落とし所としては、物理的なサービス分割を見据えた論理的分割が妥当なところなのかな、と。 開発時のリポジトリ（＝サービス）の行き来と、それらの共有物（＝ライブラリ）のコントロールが大変なので、 そのコストに見あるメリットを見いだせるか否かは常に意識しておかないといけないと感じました。

システムアーキテクチャというのは取捨選択の連続である、ということを改めて実感できたように思います。

フリーランスとしての未経験分野への挑戦

実際フリーランスになるまでは、フリーランスは基本的にそれまで積み上げてきた技術や知識で戦っていくものだというイメージをもっていました。 ですが、今回の案件に関してGoもMicroservicesも未経験分野にもかかわらず挑戦の機会が得られたことに、そのイメージを良い意味で覆されました。 すべての案件で同じ事が言えるわけではないと思いますが、フリーランスでも当面はやっていけそうです。

今後の活動について

次の案件も１サービスにフルタイムで参画します。 ただ、並行して案件を受けることも可能と考えているので、ご要望がありましたらお気軽にご相談いただければ幸いです。

• contact