「困難な状況の方が面白いと思った。」エンジニアとして次のキャリアに助太刀を選んだ理由
こんにちは。「建設現場を魅力ある職場に。」というミッションを掲げて建設業向けマッチングプラットフォームを運営している「助太刀」でエンジニアをしています、市川です。助太刀には2022年2月にジョインしました。今回は、私が助太刀に入社した経緯や、当社開発チームの課題と今後の展望などについてお話ししたいと思い、記事を書かせてもらいます。
まずは簡単な自己紹介から
大学院を卒業後、エンジニアとして、Webシステム受託会社、ECサイト運営会社に在籍していました。エンジニアが少数の組織だったので、システム開発の上流から下流・テスト等の全行程や、インフラ・フロントエンド・バックエンド等、横断的に携わってきました。そこで幅広い業務知識や経験が身についたと思います。前職の解体企業のマッチングプラットフォームを運営する企業を経て、2022年2月に助太刀に入社をしました。助太刀では、主にバックエンドをメインに開発をしています。業務委託のエンジニア複数名をリードしながら作業を行っています。趣味はレコード、音楽鑑賞。特に90s〜オルタナティブロックが好きです。あと、猫が大好きで、猫と暮らしています。
転職軸について
転職時に考えたことは、開発をするだけではなく、チームビルディングに配慮があるかどうかを重視しました。私は、これまでの経験から、チームの雰囲気の良さとパフォーマンスの高さは比例すると考えており、チームビルディングの重要性を感じていました。すでに完成されたチームを求めていたというわけではなく、組織作りについての考え方や価値観が合う方々と働きたいと思って転職活動をしていました。
入社の理由
カジュアル面談や選考を通して、助太刀は今まさにチームを作っている段階だという話をVPoEの月澤さんからお聞きしたり、マネージャーの赤星さんからは、開発チームの課題なども赤裸々に共有してもらいました。そんな中で、私も一緒にチーム作りに携わりつつ、プロダクトをスケールさせていきたいと感じたため、入社することを決めました。また、事業内容にも興味を持っていました。昔、親戚が建設業を営んでいて、今はもう畳んでしまったのですが、その当時に業界をもっと良くできていたら何か変わったのではないかとふと考えたりするんです。そんな身近な経験からか、私には「職人さんの地位を向上させたい」という想いがあり、建設業界で働くすべての方を支えるプラットフォーム化を目指す助太刀は、私にピッタリだと思いました。入社して3ヶ月が過ぎましたが、今のところギャップなどはなく働けています。実は、入社前、こちらから何度か実際に働くメンバーと面談の機会をもらいました。内定を承諾する前に何度も話し合いをすることができたので、納得した形で転職することができたと思います。
今後について
ここからは今後、助太刀でチャレンジしてみたいことを書きます。直近だと、サービスのリリース以降に溜まった負債を返却しつつ、継続的な開発ができる土壌を作らなければいけない状況なので、チームビルディングを進めながら、開発プロセス含めて改善していきたいと思ってます。
2022年2月に入社後〜現在、市川が取り組んだこととしては、以下です。
入社したばかりで、正直自分に求められているものが何なのかまだはっきりとはしていませんが、現場の開発フローには課題ばかりな状況でしたので、CI/CDの整備を軸に、以下の開発業務の改善を行いました。
1. 本番環境など各種環境へのデプロイを自動化
2. テストコードを書く文化の浸透
3. チーム単位で週毎の振り返りミーティングを実施
すべて、開発をする上で当たり前のことなのですが、やらないと前に進めないと思っているので。
1. 本番環境など各種環境へのデプロイを自動化
ソースコードはオンプレ環境のgitlabで管理しており、以前はgitlab runnerを使って自動でデプロイしていたみたいなのですが、ある時を境にgitlab runnerが動作しなくなり、それ以降は、とある社員がメモを片手に手動でローカルからデプロイしていました。社内にメンテできるエンジニアがいなかったので、放置されていたみたいです。なので、ここは単純にgitlab runnerを動作させるようにし、今まで通りマージをhookに各種環境に自動デプロイするようにしました。
ただ、オンプレ環境のgitlabを利用している限り、gitlab / gitlab runnerのサーバ自体管理が必要になるので、現在githubへ移行中です。
少しでも人の手作業によるオペレーションミスや、オペレーションの属人化は無くしていきたいと思っています！
2. テストコードを書く文化の浸透
テストコードがないプロダクトはいくつか見てきました。しかし、結局、開発効率が落ちたりと、書かないことのメリットは書くコスト/時間の削減以外ないのではないかと思います。また、ロジックの質も、テストコードを書くことを意識することで自然と良いコードになると思います（きっと多分
業務ではAPIサーバの開発をメインとしており、リポジトリには、ユニットテストがいくつか存在してました。ただ、ローカルで実行したところ、いくつかのテストが失敗していたりと、テストコード自体が正しいかどうか、誰も判別がつかない意味不明な状態で、尚且つユニットテストがCI上で実行されている形跡もありませんでした。
なので、完全に使えなくなってしまった既存ユニットテストのコードを一度全部削除し、ゼロから追加していくことにしました。
また、バックエンドチームは私含めて4人なのですが、私以外テストコードを書いた経験がない状態でしたので、同時にテストコードの書き方を共有しつつ、地道にテストコードを書く文化を浸透させていきました。
全てのテストを一気に追加することは、エンジニアのリソース/時間的にも現実的ではなかったので、テストコードの追加方針は以下のようにしました。
既存機能の改修時は、先にテストコードを追加
既存の仕様を把握すること
追加するユニットテストは、APIレスポンスに対するjson構造のアサーションテスト
ドメイン部分のロジックはモックしない
アプリケーションの実装アーキテクチャがMVCではなく、ADRを採用し実装しているため、業務ロジックとなるドメイン部分がはっきりしており、尚且つドメインとレスポンスがほぼ1対1となっているので、まずはドメイン部分のロジックをモックせずに大味なテストを用意することが大事だと判断しました。ある程度、APIレスポンスのアサーションテストが充実してきたら、ドメイン部分のテストを拡充していく方針です。
また、当たり前ですが、新たに追加していくテストコードが腐らないようにCI上でテストが自動実行されるようにもしておきました。
副次的な効果として、テストコードがあることで、仕様の把握がしやすくなり、コードレビューもしやすくなりました。
3. チーム単位で週毎の振り返りミーティングを実施
現状の開発チームは、社員/業務委託合わせて１０人ほどになります。バックエンド/フロントエンド（アプリ）と2チームに分け、それぞれ隔週毎に振り返りミーティングを実施するようにしました。主な目的は、コミュニケーションの促進、日々のヘイトを吐き出してもらい、ミーティング中に出た意見を吸い上げ、次のプロジェクト/スプリントで、吸い上げた意見に対するアクションを小さく始めたりして、開発プロセスを少しでもよりよくしていきたいからです。ダメだったり、効果がなければすぐやめて違うやり方をすればいいという方針で行ってます。また、堅苦しい雰囲気にもしたくないので、意見を言いやすい雰囲気を作るように心がけてます。
チームメンバーが、「おかしくない？」と思っていることをカジュアルに共有することができ、開発プロセスで曖昧になっている部分を大小関わらず洗い出すことができるようになりました。以前よりもdiscord/slackでのコミュニケーションが活発になったような気がします。回を重ねるごとに、良い意見が出てくるようになっているので、今後も継続していきたいと思ってます。
最後に
振り返りをすると、まだまだダメなところばっかり出やすいのですが、いいところもたくさん意見し、お互いに尊敬しつつチームビルディングできればなと思っています！
助太刀は事業も組織も拡大フェーズです。サービスをより良いものにし、さらにスケールさせるために、各ポジションでご一緒してくれる方を募集をしています！組織作りにご興味ある方、レガシー産業を変えたいという方、大きな社会問題の解決に切り込みたいという方、まずはカジュアルにお話ししましょう！
▼助太刀の情報はこちら
この記事が気に入ったらサポートをしてみませんか？