業務委託で関わっているプロダクトの開発サイクルをがらりと変えた話
筈井です。
九州で妻と娘2人の四人家族で暮らしています。
元々は東京近郊に住んでいたのですが、第一子の誕生とコロナ禍を機に九州へ移住。独立してフリーランスエンジニアとして生計を立てています。
ありがたいことに現在複数のプロダクトに関わらせて頂いているのですが、その中で最も長いお付き合いの長いのはHANOWAという会社です。
HANOWAとは
歯科医院と歯科医療従事者のマッチングプラットフォームHANOWAを運営する会社です。🦷
働ける日時、働けるエリアで、歯科医院に単発で勤務可能なプラットフォームです。
HANOWAでは私のような業務委託を含め4名のエンジニアが活躍中なのですが、かつてはエンジニアにとって好ましくない状態にありました。
「本番リリースした機能に仕様の考慮漏れが発覚し、ユーザーから問い合わせが寄せられる」
「マージしたプルリクエスト内のコードが読みにくく、技術的負債が徐々に蓄積している」
「実装したコードの動作確認をお願いしたいのに、ステージング環境が1個しかないので順番待ちが発生している」
こうした状態を打開するため、HANOWA開発チームでは開発サイクルの改善に動きました。
改善前の開発サイクル
改善前、HANOWAは大まかに以下のような形で開発を進めていました。
コードはプルリクエスト作成者以外に1名のエンジニアのみがレビュー
開発が終わったらステージング環境にデプロイしてプロダクトマネージャーの動作チェックを受ける
masterブランチへマージしたら即本番リリース
長らくプロダクトに携わるエンジニアが少なかかったため、いわゆるチーム開発とはだいぶ違ったフローで開発が進んでいたんですね。
何をどう変えたのか
ではどのように変わったのか。
以下が、現在のHANOWA開発チームの開発サイクルです。
2週間を1スプリントに変更
スプリント終了の翌週月曜日から数日かけてステージング環境で動作検証
2週間に1回、木曜日に本番リリース
プルリクエスト作成時に手動テストの動作検証項目を書くことを義務化
上記の動作検証項目もレビューの対象
プルリクエストのレビュアーには必ず2名以上のエンジニアを指名
リリース毎にGitタグを使用してバージョン管理
プルリクエストのマージをSquash and mergeに統一
現在の開発サイクルはリリース時のリスクヘッジを行ったことがポイントです。
定期的なリリース日を予めセットし、動作検証を数日かけて行うことでデグレやバグの発生を予防します。また、プルリクエストは複数名でコードレビューを行い、実際にアプリケーションを動作させて要求通りの仕様で実装されていることを確認します。
この開発サイクルの改善は、エンジニアメンバーを初めビジネスサイドからも概ね好評で、施策の振り返りでは以下のような良かった点・もう少しな点が挙がりました。
良かった点
開発メンバーがほど良い緊張感を持つ
開発期間に区切りを設けることで緩い締切を設定
本番リリース後のデグレ・バグ発生件数がほぼゼロになった
リリース予定の機能をまとめて動作確認できる
リリース前に不具合を発見できる
本番リリース前の動作確認時、アプリケーションの仕様や挙動に対する議論が活性化した
人知れず本番リリースされて、人知れず不具合が発生することがなくなった
実装担当者以外のメンバーがプロダクトの仕様変更・新機能への理解を深めることができる
リリース予定の機能の仕様について把握する場としてコードレビューが機能し始めた
知らないうちに知らない機能がリリースされていることがなくなった
実装担当者が動作検証項目を書くことによって、機能開発に対する考慮漏れが減った
Gitのタグ機能でバージョンを付与することにより、本番リリース後に深刻な障害が発生しても切り戻しが容易になった
Squash and mergeをすることによってコミットログ、プルリクエスト、タスクが一意に紐づき履歴を遡ることが容易になった
もう少しな点
プルリクエスト作成時に動作検証手順を書く作業が、開発内容次第ではとても重たい
本番リリース前の動作確認で追加修正が必要になると、1タスクに対して複数のプルリクエストが出来上がってしまう
今回の開発サイクルの改善は、最初に言い出したのは自分だったのですが、HANOWAの開発メンバーがどのように感じ、どのような反応をするのか不安な気持ちがありました。
しかし概ね好印象な反応を頂き、とてもホッとしたのを今でもよく覚えています。
今後やりたいこと
新たな開発サイクルにも慣れてきたので、更に開発チームがワークする施策を打っていきたいと考えています！
エンジニアリソースに限りがある中、開発タスクに追われている日々ではありますが、以下のような取り組みは近々やっていきたいです！
プルリクエスト作成時に専用の検証環境が立ち上がるようにしたい
既存コードのリファクタリングをしたい
フロントエンド側でデザインシステムの導入を推進して開発スピードを挙げたい
以上、開発サイクルを改善した話でした。
最後までお読み頂きありがとうございます！
HANOWAでは他のメンバーもnoteを書いているので、ぜひ見に行ってみてください！