バックエンド開発チームを紹介

この記事は BBSakura Networksアドベントカレンダー2025 の22日目の記事です。

はじめに

最近、バックエンド開発チームのリーダーになった okuno です。

─── BBSakura のソフトウェアエンジニアは、謎に包まれている。

社内外からそんな声をもらうことがありました。

そこで、今回は会社や提供サービスの概要、
またバックエンド開発チームの役割や技術スタックや働き方などを紹介します!


目次

1. 会社概要

1.1. 会社紹介

1.2. 提供サービス

  • OCX(Open Connectivity eXchange) という NaaS を提供しています。
    • OCX とは データセンター間接続 / ルーティング / クラウド事業者との接続 など、
      ネットワークの様々な機能をクラウド化し、それらを管理するコンソール画面を備えたプラットフォームサービスです。

1.3. ブログ記事(抜粋)

2. 開発チーム

OCX のソフトウェア開発には、
他にも フロントエンド開発チームモバイル開発チーム仮想基盤開発チーム など、
複数の専門チームが関わっています。

このページでは、その中でも バックエンド開発チーム にフォーカスして紹介します。

2.1. 開発方針

  • ユーザーに価値を届ける機能を作り、収益を伸ばす
  • 設計やコードの変更容易性を確保し、将来の保守・改修コストを抑える
  • 収益性と費用対効果の両面を意識し、持続的に利益を生み出せる開発を目指す

2.2. 役割と責任

  • OCX におけるバックエンドの設計・開発
    • API / ビジネスロジック / バックグラウンド処理 などが中心
    • 新サービスや新機能の開発、既存機能の保守・改善を中心に、技術的負債の解消など、ソフトウェア開発に関わる領域全般を担当
  • OCX の成長に伴い、技術的負債も少なくありません
    • 以下のような改善提案も大歓迎で、ステークホルダーと合意を取りながら進めています
      • 「この機能があったほうが便利」
      • 「この部分はリファクタしたい」
      • 「ここを改善すればパフォーマンスが上がりそう」
  • 運用は専任チームが担当していますが、運用に関わる開発タスクを担うこともあります
  • 担当領域はありますが、役割に強く縛られることはありません
    • 例:バックエンドエンジニアがフロントエンド開発に関わることも可能です(逆も歓迎)

2.3. 開発体制

  • 開発は、テーマや規模に応じてプロジェクト形式で進めることもあれば、機能追加や改善などをイシュー単位で進めることもあります
    • ビジネスサイドからの要望を起点にする場合もあれば、エンジニア自身の問題提起や改善提案から始まることもあります
  • 開発に関わる業務全般(要件定義・設計・実装・テスト・レビュー・リリースなど)をチームで分担しながら進めてます
    • 特定の担当者に責任が集中しすぎないよう、レビューや相談を前提とした進め方をしています
  • リリース予定日は、開発スコープや優先度、ステークホルダーとの相談を踏まえて現実的に決定しています
  • プロジェクトやイシューはすべて GitHub Projects で一元管理し、チーム内で常に状況を共有しています
    • エンジニア自身が興味のあるテーマに手を挙げて、主体的に開発を進めることもあります
  • 明確な正解がないテーマについても、試行錯誤しながら取り組んでます

2.4. 開発・レビューの進め方

  • GitHub のプルリクエストベースで開発を行っています
  • ブランチ戦略はシンプルな GitHub Flow です
  • 開発手法はアジャイルを基本としていますが、形式に拘りすぎず、チームや状況に応じて進め方を調整しています
    • 「どう進めるのが一番うまくいきそうか」をエンジニア同士で相談しながら決めています
  • レビューは品質の担保だけでなく、ナレッジ共有や設計のすり合わせも目的としています
  • レビューの優先度や意図を分かりやすくするため、プルリクエストのレビューコメントには以下の prefix を付けています
[must] - 必須修正。重大な問題がある場合
[imo]  - 任意提案。改善が望ましい場合
[nits] - 細かい指摘。コードスタイルなど
[ask]  - 質問。意図や実装内容の確認
[fyi]  - 参考情報。関連知識の共有
  • prefix の運用について
    • 人間のレビューだけでなく、AIによる自動レビューでも利用しています
    • prefix に応じて対応の進め方を分けています
      • [must] については、レビュワーと認識を揃えたうえで対応方針を決めています
      • [imo] 以下については、実装者の判断を尊重しつつ対応しています

3. 技術構成

3.1. 技術スタック

*最終更新:2025年12月

Category Technology Stack
AI ChatGPT / Gemini / Codex / Claude Code / GitHub Copilot
業務管理 GitHub Projects
ソース管理 GitHub Enterprise
言語・LIB・FW フロントエンド:TypeScript / React / Next.js
バックエンド:Go / GORM / gRPC
データベース PostgreSQL
インフラ さくらのクラウド / Google Cloud / Cloudflare / VMware / Docker
CI/CD GitHub Actions / Terraform / Ansible
コミュニケーション Slack (Business) / Google Meet / Google Workspace

3.2. アーキテクチャ

  • リポジトリ:モノレポ
  • アプリケーション:現在、明確なアーキテクチャパターンに統一されていません
    • OCX の成長に伴い、責務やレイヤが混在している部分もあり、改善の余地が多くあります
    • チームで議論しながら、より適したアーキテクチャを段階的に導入していく予定です

4. 働く環境

4.1. チームの特徴

  • 技術の流行に振り回されず、原理原則を重視します
    • 技術の流行に左右されない原理原則の思想がある
      • 課題の本質を定義する
      • 複雑な事象を抽象化/構造化し、シンプルなモデルに落とす
    • 技術好奇心が高いメンバーが多いです
    • HRT(謙虚/尊敬/信頼) を大切にしてます
  • 経営層を含め、エンジニアリングへの理解と関与が高い環境です
    • 雑談レベルで設計やコードの話が飛び交うこともあります
    • 代表もコードを書くことがあります

4.2. 働き方

  • リモート勤務
    • 基本はリモートワーク
    • 必要に応じて竹芝オフィスや WeWork に出社することもあります
  • フレックス勤務
    • スーパーフレックスタイム制を導入しています
  • コミュニケーション
    • 主に Slack でテキストコミュニケーション
    • 必要に応じて Slack ハドルや Google Meet を使用します
      • 会話が長くなりそうなときや、テキストでのやりとりに詰まったときは、気軽に声をかけて話すのを推奨してます
  • 業務効率化の工夫
    • 可能な限り本質的な業務に集中できるような環境を作っています
      • 例えば...
        • 勤怠連絡は Slack のみ
        • 生成AIをガンガン使う(セキュリティおよび社内規定を前提)
        • テーブル設計書の自動生成、Lint や AI による自動レビュー、デプロイの自動化
        • Slack ステータスで体調を共有(任意参加)
          slack-thread, width="350"

5. 採用情報

  • エンジニアを中心に中途採用を行っています
  • 興味を持っていただけた方は、以下リンク先よりご応募ください!

さいごに

バックエンド開発チームの雰囲気や考え方が少しでも伝わっていれば幸いです。

「良いサービスやチーム作りに挑戦したい」
「まだ整理されきっていない部分も含めて、一緒に作っていきたい」

そんな方がいれば、ぜひ私たちのチームに来てください!

・・・余談ですが、今後このように各チームの取り組みをまとめて、
Engineer Entrance Book として整理・公開していきたいと考えています。
また進展があれば改めて発信します。