はじめまして。Webアプリエンジニアの村井です。

OpenWorkリクルーティングのプロダクトチームで2年弱、開発リーダーをしていました。大きな案件の開発、スクラム導入、複数プロジェクト合同での開発......など色々なことがありました。

今回、その中でもリリースに悩んだエピソードを紹介させていただきます。

データの整合性や下位互換性を考える案件

Web開発をしていると、稼働中のサイトに改修したソースを追加するにあたって、リリース前後の流れを考える機会があります。（ログインセッションが切れないこと、APIやフォームの下位互換性など）

私が携わったグループ管理機能を開発する案件では、以下の仕様を実現しようとしていました。

仕様

上記の仕様を実現するために、最初は以下の流れでリリースしようかと考えました。

データを作成する（既存のユーザーに初期グループに所属させる）
デプロイする
- 新規登録ユーザーは、登録時に初期グループに所属して、ログインができる
- デプロイ前から存在するユーザーは、データ作成によってグループに所属しているため、ログインができる

ただ、この手順だと、データ作成〜デプロイの間に新規登録したユーザーはどこのグループにも所属していないことになります。

該当ユーザは一時的に機能が利用できない状態となってしまうため、何らかの対応が必要でした。

サービスを停止（メンテナンス状態を表示）してリリースすることも一度検討しましたが、デプロイを細かく分けることでサイトは無停止のまま安全にリリースできると思い直しました。

1回目のデプロイでは裏側でデータを作成するソースのみ、 2回目のデプロイではデータがある前提での管理機能のソースという形で、デプロイを2回に分けました。

結果、リリースは無事に完了し、小さくデプロイしたことで１リリースあたりの負荷やリスクを減らすこともできました。

サービスを利用している方へ最大限価値を提供するために、いかに早くリリースするかは大事ですよね。

なるべく小さな単位で高頻度でリリースしていくことが理想だと思います。（修正差分行数とリリース時の緊張感は比例すると思っているので、エンジニアのやりやすさから見ても1回ごとの負担を小さくしたいものです......）

小さく高頻度でリリースするために、

という意識が、エンジニアだけではなくチーム全体で共通認識としてあると良いと感じます。

オープンワークでは、チーム全体でサービスをより良くする開発に取り組んでいます。

プロダクトマネージャー、デザイナー、アナリストなどエンジニア以外のメンバーもエンジニアリングに理解があり、エンジニアもどうしたら早く良いものをリリースできるかを一生懸命考えています。

大きい案件では、自分の思いついてない考慮すべき事項はたくさん潜んでいるし、問題は無いと考えていてもやはりリリースのときは緊張します。

些細な意見でも気軽にフラットに言い合える環境を作るため、チームメンバーとの相互理解や信頼関係は大事な要素だとこの2年弱開発リーダーを経験してきて実感しました。

裁量を持って開発がしたい！

同じモチベーションを持ったメンバーと一緒にプロダクトの価値を高めていきたい！

そんな方には、きっとオープンワークは楽しい環境だと思います。

この記事を読んでオープンワークに少しでも興味を持った方は、ぜひ採用サイトを覗いていただけると嬉しいです。