Oisix REBORNプロジェクトにおけるバックエンドチームでの開発の進め方

1. はじめに

こんにちは。Oisixエンジニアリング部バックエンドセクションの栗崎です。

以前「負債解消Prjにおけるナビ運用CMS化の取り組み」を紹介しました。 今回は負債解消Prj改めOisix REBORNプロジェクトにおけるバックエンドチームでの開発の進め方について紹介します。

本記事では、とくにOisixのバックエンド開発に興味をお持ちの方が、入社後の働き方を具体的にイメージできるよう、私たちが日常的に使っているツールや具体的な開発フロー、そしてデータに基づいた改善の取り組みまで詳しくご紹介します。

2. 利用ツール

開発に利用している主なツールを紹介します。これらのツールはバックエンドチームに限らず、Oisix REBORNプロジェクト全体で共通して利用しています。

• Backlog¹
  • プロジェクト管理ツールとして利用
  • タスクの可視化と進捗・課題管理
• Notion
  • ドキュメント管理ツールとして利用
  • プロジェクトの仕様書や設計書の作成
• GitHub
  • ソースコードのバージョン管理
  • プルリクエスト（以下、PR）によるコードレビュー
• Slack
  • コミュニケーションツールとして利用
  • チーム内の情報共有と連絡手段
• Findy Team+
  • 開発生産性の可視化

3. 開発の進め方

Oisix REBORNプロジェクトでは、設計からリリースまでの開発フローをチーム内で共有しながら進めています。 この章では「設計」「実装」「テスト」の3つのフェーズに分けて、それぞれで誰が、何を、どう進めているかをご紹介します。 基本的にAPI単位で担当者を割当て、設計からテストまでを担当します。 リリースはアプリケーション単位でリリースすることもあれば、まとまった機能単位で（複数のアプリケーションを一度に）リリースすることもあります。

3-1. 設計フェーズ

• 誰が
  • 担当者（バックエンドエンジニア）
• 何を
  • OpenAPI Spec：コントラクトベース設計の考えに則り、形式や説明を厚めに記載することを心がけています。
  • API仕様：Notionで記述します。概要・処理フローやレスポンス例などを具体的に設計します。Notionに設計書テンプレートを用意してあり、それに従い記述していきます。
• どのように
  • Specや仕様が記載できたら、オンラインでチーム内レビューを行います。ボリュームによってはランダムでレビュアーを割り当てることもあります。

3-2. 実装フェーズ

設計が固まったら、その内容をもとに具体的なコードを書いていく実装フェーズへと進みます。

• 誰が
  • 設計の担当者が引き続き実装を担当します。
• 何を
  • Backlogチケット単位はスコープが広いため、GitHub Issueで細分化します。Backlogチケットに対応するIssueを作成し、実装単位でSub Issueに分割します。
  • 原則として「1 Sub Issue = 1 PR」となるように開発を進めるため、PRの単位は自然とレビューしやすい適切なサイズに保たれます。
    • 
  • 実装コードとユニットテストをセットで作成しPRを出します。PRが作成されると、GitHub Actions上でユニットテストが自動実行され、CIの一部として品質保証される仕組みです。
    • 
    • 
• どのように
  • PRを作成したら、まずGitHub Copilotをレビュアーに割り当てます。細かなTYPOや静的チェックでは拾いづらいコメントをしてくれるため、初期レビューとして重宝しています。
  • その後、チームをレビュアーにアサインし、ランダムで一人が割り当てられます。属人化を防ぎつつ、チーム全体のコード品質を担保しています。

3-3. テストフェーズ

実装が完了したら、機能の品質を保証するためのテストフェーズに移ります。私たちのチームでは「品質はチーム全員で作り込むもの」という考えのもと、テスト設計から実施までを体系的に行っています。

3-3-1. テスト設計

API仕様をもとにテスト観点を整理します（テスト分析）。 これまでの実装担当者がテスト観点をスプレッドシートにまとめ、必要なテストケースを洗い出します。 設計工程でのレビュアーがテストケースのレビューをします。

3-3-2. テスト実装

設計したテスト観点に基づき、テストを実装します。私たちのチームのテストは、大きく分けて「サービス結合テスト」と「結合テスト（機能ごと）」の2種類で構成されており、 これらをGitHub Actions上で自動実行することを基本方針としています。

• サービス結合テスト

  • 目的
    • 自サービスが連携する他サービス（対向サービス）をブラックボックスとして扱い、アプリケーション層・インフラ層の両観点から、通信の成立だけでなく、リクエストの受信・レスポンスの返却が期待通りに行われるかを確認するための自動テストです。
  • 誰が
    • 実装担当者がテストコードを作成します。
  • 何を
    • テストコードは各サービスのリポジトリに同居します。Rest Assuredを主なテストフレームワークとして利用し、ユニットテストと同様にAAAパターン構造で実装します。
  • どのように
    • 対向サービスをモック化したWireMockのDocker Imageを作成します。テスト対象のアプリケーションとWireMockコンテナをDocker Compose上で起動し、APIを呼び出して期待通りのやり取りができるかを確認します。このテストはCIの一部として自動実行され、マージ前に連携部分の品質を担保する重要な役割を担っています。

• 結合テスト

  • 目的
    • 実際の開発環境で、複数のサービスを横断して機能全体が正しく動作するかを確認する、より大きな単位のテストです。
  • 誰が
    • 実装担当者がテストコードを作成します。
  • 何を
    • 機能横断の結合テストはアプリケーションのリポジトリとは別の独立したリポジトリにテストケースを作成します。（テストケースの実装の仕方はサービス結合テストと基本的に同様です。）
  • どのように
    • サービス間のデータ連携やビジネスロジックが全体として正しく機能することを確認します。
    • 開発環境にデプロイされた各サービスに対して、テストを実行します（GitHub Actionsより手動で実行します）。現在、このレイヤーの自動テスト実装を推進しており、より広範囲な品質保証を効率的に行える体制を目指しています。

4. 開発生産性の可視化

私たちのチームでは、客観的なデータに基づいて自分たちの強みや課題を把握し、継続的に開発プロセスを改善していくことを大切にしています。 そのためのツールとしてFindy Team+を活用しています。

この章では、Findy Team+のデータから見えてきた、私たちのチームのもっとも顕著な特徴をご紹介します。

データが語るチームの特徴：「仕様決定後の圧倒的な実装スピード」

私たちのチームの最大の特徴は、設計仕様が固まってからの実装スピードの速さです。これはFindy Team+の複数の指標にも明確に表れています。

特徴1：PRのリードタイムの短さ

PRが作成されてからマージされるまでの時間を示す「リードタイム」のグラフです。

このグラフが示すように、私たちのチームではPRが平均して約6時間でマージされています。 これは、一度実装に着手したコードが、レビュープロセスで滞留することなく、迅速にプロダクトに統合されていることを意味します。

特徴2：小さく、活発なPR

リードタイムの短さを支えているのが、PRの単位を小さく保つ文化です。

PRの数が多いことは、単に開発が活発であることだけを示しているのではありません。ひとつひとつのPRが適切なサイズに保たれているため、レビュアーの負担が少なく、迅速かつ質の高いレビューが可能になっています。

なぜこのスピードを実現できるのか？

この圧倒的な実装スピードは、これまでの章でご紹介してきた、私たちの開発プロセスや文化に支えられています。

• 明確な「設計書」: 設計フェーズでOpenAPI Specに基づいた明確な仕様を定義しているため、実装中の手戻りや認識齟齬が最小限に抑えられます。
• 徹底した自動テスト: サービス結合テストをCIに組み込んでいるため、マージ前に品質が担保され、レビュアーは安心してレビューに集中できます。
• 効率的なレビュー文化: GitHub Copilotによる一次レビューや、ランダムアサインによるレビューの属人化防止など、プロセス全体で効率化を図っています。

5. まとめ

本記事では、Oisix REBORNプロジェクトにおけるバックエンドチームの開発の進め方について、ツールやフロー、具体的な実務の流れに沿ってご紹介しました。 ここで紹介した取り組みや仕組みは、プロジェクトのある時点でのやり方であり、常に最適とは限りません。 チームのフェーズやプロダクトの性質、開発者それぞれの視点に応じて、これからも柔軟に変えていく必要があると考えています。

6. おわりに

私たちは日々、よりよい開発体験とプロダクトづくりのために、仕組みやプロセスの改善に取り組んでいます。 今回ご紹介した開発の進め方も、その中の1つのスナップショットに過ぎません。 もしOisixでの開発のあり方や働き方に興味を持っていただけたら、ぜひカジュアルにお話ししましょう。

• 採用ポジション

---

1. 組織全体でプロジェクト管理をNotionへ移行する計画がありますが、Oisix REBORNプロジェクトでは、現在の開発フェーズが一段落するまでBacklogを継続して利用する予定です。↩