2017 年 3 月より justInCase にエンジニアとしてお手伝いさせてもらっています。

その当時から justInCase 最初の保険商品としてモバイルアプリで完結するスマホ保険を提供するというのは決まっていました。

保険商品は当局の許可がないとリリースできません。 CEO の畑さんと CTO 小泉さんは、当局への折衝や営業なども含めて、すべての業務をこなしている状況でした（その状況自体は今も大きく変わっていないような気はしますが）。

そんな中、開発をより促進すべく、私ともうひとりアプリエンジニアがほぼ同時期にお手伝いとして参加することになったわけです。

当時の状況

Swift でコーディングされた動くアプリはあった（デモアプリ的な位置づけ）
AppStore 申請も試されていた
BitBucket (git) を使ってコードのバージョン管理はされていた
基本 master ブランチ一本
CEO / CTO がコーディングして、変更状況や内容は Slack 上で情報共有されていた
BitBucket で将来的にやりたいことは簡易ながら数点チケット化はされていた

BitBucket を使ってアプリ開発の管理するという形にはなっていましたが、まだ試行錯誤な状態でした。

ガイドラインの作成

justInCase に参加して私が最初にやったのは……

コードならびにアプリ動作の確認
ガイドライン (開発工程・コーディング) の作成・提案
ガイドラインに沿って実践

私が参加した段階で CEO / CTO もまだ開発を行っていく前提でしたし、私とほぼ同時期に参加するもう一人のエンジニアもいらっしゃいました。つまり、私を含めて少なくとも 4 人ほどの開発人員がいる状態でした。また、それぞれ別々の場所で業務をこなしていて、開発要員全員がリモートでの開発という環境でもありました。

少人数の開発でうまく回っている、とりあえず開発が前進している、状態では、ガイドラインそのものはあまり必要でないというか、意識されないものです。

ただ、今回は今後のコミュケーションを円滑に進めるためにもたたき台となれるドキュメントはあった方がよいと判断しました。

開発工程

開発の手順を明確にしました。つまり、

チケットの発行・割り当て
feature ブランチの生成
実装作業・feature ブランチへコミット
develop ブランチへの pull-request を作成
コードレビュー
pull-request のマージ・チケットの resolve

という手順に沿って開発しましょう、というのを文書化しました。

文書化と実践

文書にすると

フィードバックを受けやすく、それを元に改善できる
後から参加する人に説明しやすい・共有できる

という大きな利点があります。一方

メンテコストがかかる

という欠点もあります。メンテされない文書は害にもなりえるので、いつ更新したのかが分かる形で文書を残した方がいいでしょう。

ただ文書化しただけではダメで、それを私が実践してみせるということもすぐに実行しています。自ら実践してみて改善点が見えたり、言葉足らずの部分を発見します、そうして、それをまた文書に反映していきます。

エンジニア募集中

そんな感じでフルリモートで開発のお手伝いを始めてもうすぐ二年になろうとしていますが、まだまだやることいっぱいです。

justInCase では一緒にアプリ・サービスを作り上げていただけるエンジニアを絶賛募集中です。

よろしくお願いします。