トップ > 開発現場の風景 > プロダクションレディな品質を目指すために取り組んでいること

プロダクションレディな品質を目指すために取り組んでいること

開発現場の風景 チーム開発

はじめに

初めまして。人材紹介開発グループにて、介護職向け人材紹介サービス カイゴジョブエージェントの開発を担当している和田です。

本記事では、「プロダクションレディな品質」を目指すための取り組みについて紹介させていただきます。

同様の取り組みをしている方や、興味のある方の目に留まり少しでもお役に立てたら幸いです。

取り組みの背景

ある障害が発生した際に、原因の一つとして「リリース可能な品質水準について共通認識を持てていない」事が挙げられたのが発端でした。

「本番にリリースしていい状態 = プロダクションレディな状態」に対して、まず前段として開発のフローが一定の水準で確立されていることが最低限の品質担保に寄与すると考え、相互学習の場も兼ねて「構成管理」「テスト」「自動化」の観点で議論がスタートしました。

プロセス

ここでは実際にどのようなプロセスで進行していくか紹介していきます。

テーマによって若干の差異はあるものの、大枠以下のようなプロセスで進めていきます。

議論フェーズ

  1. 一定期間議論するテーマを決め、参加メンバーでディスカッションを行う
    • 参加メンバーはそのテーマに対して気になる事を意見していく
    • 議論が発散しないよう留意しつつ、そのテーマにおける「プロダクションレディ」について共通認識を揃えていく
  2. オーナー(旗振り役)とサポート役の選定
    • オーナーの役割
      • 進捗把握、課題整理、実行手順の取りまとめなど、必要な事を適宜行いプロジェクト実行を推進する
    • サポート役の役割
      • 基本的にはオーナーが行う各作業においての補助的な立ち位置で一緒に考え作業する

実行フェーズ

  1. オーナーとサポート役が、実行するにあたって流れをまとめる
  2. 各プロダクト毎に作業を進め、毎週オーナー役が進捗を確認し、全プロダクトの対応が完了するまでテーマの実行を推進していく

実際のテーマとそこから得た学び

取り組み自体がまだ浅いので現時点で完了したテーマがまだ存在せず、基本的に全て進行中のステータスにはなりますが、ここでは実際に今動いている以下のテーマについて自身の学びを交えて簡単に紹介させて頂きます。

  • データベースの構成管理
  • テストに対する認識を揃える

データベースの構成管理

このテーマは、構成管理の一つとしてデータベースの管理を見直す取り組みです。

テーブルの変更履歴が正しく管理されていない、複数のプロダクトで同じテーブルをメンテナンスしている、などの問題があります。解決策について議論を重ねた結果、既存のモノリシックなデータベースをプロダクトごとに分割してプロダクト単位でデータベース定義の管理からデプロイまで行えるようにする、という方向でステップを踏んで作業を進めています。

学び

私自身データベースを分割することに対する知見が少なかったのもあり、O’Reillyの『モノリスからマイクロサービスへ』を参考に基本的な部分から学びました。

参加メンバー内でも同書籍を用いた勉強会も開催され、「うちのプロダクトだとこういうことなのか？」といった会話がなされて学びが多いです。

全てのテーマで共通していますが、各議論の中で他のプロダクトを担当するメンバーの意見、担当外のプロダクトで既に行っている取り組みなども知れるので参考になります。

テストに対する認識を揃える

このテーマは、どのフェーズでどのようなテストが行われるべきか、また、それぞれのテストをどのように書くのか、などを整理し、プロダクト間で共通認識を持った上で各プロダクトのテストを作成していくための取り組みです。

学び

私自身、そもそもこのテストはどの開発サイクルで行われるべきで、それに必要なデータは何でどういったデータがあるべきか？といったことを深く考える機会は初めてでした。

この取り組みを通じてモブプロ的にテスト内容の検討やテストコードの追加なども実施され、学びを得る機会が多いです。

プロセスを通じて得られたこと

私の場合、データベースの構成管理の部分でオーナーとして活動していました。

上でも書いていますが、この領域に関する知見が少なかったので、他メンバーの考えや書籍を参考にしつつ解決までのロードマップを引くといった感じでした。

単に自己学習をした場合よりも、業務内でアウトプットを並行して行う必要があったので、より理解も深まる機会になったと思います。

加えて、オーナーの役割を担うことで、リーダーシップを取りプロジェクトを推進する経験が出来たこともよかったと思います。

ゴールはどうあるべきでどう進めるのか、ロードマップは納得できるもので行動に移せるのかなど、リーダーシップを取り、人を巻き込みながら共通の目標に向かっていく事は思っていたよりもプレッシャーを感じましたが、自身の成長に繋がっています。

最後に

プロダクションレディな品質を担保する為に実施している取り組みについて事例を交え紹介させて頂きました。

私自身感じているのは、個別のタスクレベルで発生する課題だけでなくプロダクト横断レベルの複雑な課題に取り組む機会が多く、開発者として成長につながる場面にも恵まれている環境だということです。

もしこの記事を読んで少しでもエス・エム・エスに興味を持ってくださった方がいたら嬉しいです。