Zenn
ソーシャリア技術ブログPublicationへの投稿
🚀

複業メンバーだけのプロダクト開発チームが、BubbleとGitHub Projectsで実践していること

hokachan
2024/10/18に公開
GitHub
bubble
tech

この記事では、複業転職サービス ソーシャリア プロダクト開発チームの 2人の複業メンバーが、「1週間サイクルの機能リリース」をどのように実現しているのかについて解説します。

特に、サービスの立ち上げや 0→1 開発を実践している方の参考になれば幸いです。

はじめに

ソーシャリア のプロダクト開発を担当している @hokachan です。

ソーシャリアは、2022年10月にノーコードツール Bubble でプロダクト開発を始めました。現在は、プロジェクト管理ツール GitHub Projects も活用しながら(ミニ)スクラムを実践しています。

チーム結成当初は何も運用ルールが定まっていなかったものの、手探りで少しずつカイゼンを繰り返しながら、今では効率的な開発サイクルを回せるようになりました。

ここ数年でノーコードの解説記事が増えてきたのは嬉しい限りですが、ノーコードを活用した具体的な開発プロセスに関する情報はあまりない印象です。ですので、今回は具体的なツールの活用方法から日々のコミュニケーション方法まで、私たちチームの秘訣を余すことなく公開したいと思います。

↓ Bubbleについて詳しく知りたいという方は、こちらの記事をご覧ください。
https://zenn.dev/sociareer_blog/articles/b1c5dc25c01cc3

開発体制と役割分担

まずは、私たちの開発体制についてお話しします。

開発チームは、POとUXエンジニアの2名のみで、どちらも（リモート）複業メンバーとして参画しています。 それぞれの役割や稼働状況は以下の通りです。

PO（プロダクトオーナー）

  • 役割：バックログ管理、要件定義、ユーザーストーリー作成、設計、QA、リリース
  • 開発スキル：DB設計、UX設計、Bubble
  • 稼働状況：週10-15時間程度
  • 居住地：近畿

UXエンジニア

  • 役割：設計、実装、API連携、外部サービスとの統合、テスト
  • 開発スキル：DB設計、UI設計、Bubble、HTML、CSS、JavaScript
  • 稼働状況：週10-15時間程度
  • 居住地：九州

ただ、このように書いたものの、担当が全て明確に分かれているわけではありません。PO が Bubble 実装を行ったり、UXエンジニアがリリースを行ったりと、日々の状況に応じて役割を変えながらスクラムを実践しています。

ソーシャリアの立ち上げ当初は、Bubble 実装できるのは UXエンジニアのみという状況でした。その後、エンジニア経験のある PO が Bubble を習得しはじめ、次第にこのような役割分担になっていった背景があります。この、「PO が Bubble を習得できる」ことこそがノーコードの強みでもあり、私たち開発チームの強みのように感じています。

GitHub Projects で バックログを管理する

ここからは、私たちが使っているツールとその運用方法を紹介していきます。

ソーシャリアでは、開発チームのバックログ管理に GitHub Projects を活用しています。イシューをチケット化することで、対応状況のメモや後述するQAのレビュー結果などを管理しやすくなります。

チームでスプリントを実践する以前は、恥ずかしながら Slack のスレッドにメモを残しながら開発を行っていました。その後、開発チームの中でイシューを可視化しスケジュールを切ってリズムの良い開発サイクルを回そうとする中で、試験的に GitHub Projects によるイシュー管理を始めました。

https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

GitHub Projects の選定理由は至ってシンプルで、「無料で」「基本的なバックログ管理ができる」という点だけです。　他にも、Notion や Linear などの素晴らしいツールも多くあるので、GitHub Projects に限らずチームメンバーが気持ちよく使えるものを選択すると良いと思います。（個人的には Linear の UX が好きなので、個人開発では Linear を使っています。）

この GitHub Projects によるバックログ管理は、アプリの機能が複雑化していく中で欠かすことができない存在になりました。0→1 という事業フェーズにおいても、リズムの良い開発サイクルで品質の高いプロダクト開発を行う上では、バックログ管理ツールをマストで導入することをおすすめします。

イシューの作成と管理

バックログにイシューを作成するタイミングは、大きく次の3つのパターンに分けることができます。

  1. 機能追加
  2. QA
  3. バグ報告

ここでは、機能追加について、簡単に解説していきます。

機能追加の場合は、「その機能を追加することで、何を実現したいか」をイシューに明記します。これが、後にQAを行い機能の完成を判断するための基準にもなります。

📌 記載内容の一例

機能の目的や背景
- 採用募集を出したい企業と話していて、正社員採用のニーズも一定あることがわかった
- やはり、拡大期で正社員を急ぎ採用したいニーズあるのは、そりゃあそうという感じ

実現したいユーザーストーリー
1. 採用企業（orADMIN）が募集を作成する際、正社員の募集か複業の募集かを選べる（どちらか一つを選ぶ）
2. 候補者が募集を検索する際、検索条件として、複業の募集か正社員の募集かを設定することができる。
3. また、募集詳細画面において、募集の種類をラベル的な感じで確認することができる。

留意事項
- ラベルの見せ方は、募集一覧を一列のUIにするタイミングで再考することになるかも..??一旦今の職種のラベルと同じでいいかなと。

その他、デザイン案など
- 募集一覧画面では正社員か複業かのラベル表示はなしでOK（募集一覧を一列UIにした後なら表示させてもいいかも）
- 検索条件の中では一番上に正社員か複業かを選べるようにする
- 募集詳細画面では、右側の募集職種とかのところに正社員か複業かわかるようにする（スマホだとアレかもだけど、、一旦今はそれでOK）

このイシューは既に対応済みですので、以下のリンクから改修後のUIを確認することができます。
https://sociareer.com/offers

イシューのステータス

GitHub Projects では他のプロジェクト管理ツールと同様にステータスをカスタマイズできます。私たちは主に以下の8つのステータスを活用してイシューを管理し、メンバー間で進捗状況を共有しています。

ステータス 説明
Backlog 将来的に検討するイシューです。スプリントプランニング時に、ここから優先度の高いものを選択します。
Next Sprint Backlog 次週のスプリントで取り組む予定のイシューを集めます。
Sprint Backlog 今週のスプリントで取り組むイシューです。スプリントプランニング時に、イシューを優先度の高い順に並び替えます。
In Progress 現在対応中のイシューです。
実装完了 開発者が実装を終えたイシューです。QAプロセスに進む前の中間ステータスとして機能します。
QA中 QAが進行中のイシューです。バグや改善点がないかを確認します。
QA完了 QAを通過し、リリース準備が整ったイシューです。
Done 全てのプロセスを完了し、本番環境にリリースされたタスクです。

スクラムを実施する中で少しずつステータスを追加していったので日本語と英語が混じっていますが、各ステータス間の移行基準さえチーム内で明確になっていれば良いと考えています。（なので、しばらくはこのまま、、）

参考までに、ステータスを英語に統一する場合は次のように書けるかと思います。

  • Backlog
  • Next Sprint This Sprint
  • Dev in Progress Dev Complete
  • QA in Progress QA Approved
  • Done

Bubble で バージョンを管理する

続いて、私たちが実践している Bubble の バージョン管理システム を活用した、開発環境 / 本番環境の構築方法について解説します。

Bubble のバージョン管理システムにおけるブランチ戦略を考える際、以下の記事を参考にしました。
https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea
https://qiita.com/KosukeSone/items/514dd24828b485c69a05

ソーシャリアの開発チームでは、Git-flow というブランチ戦略を参考にしつつ、Bubble でも実現できるよりシンプルな手法をとっています。

  • Live
    プロダクトの本番環境です。Git-flow の master ブランチに近い役割を担います。
    読み取り専用のため、Live ブランチに直接変更を加えることはできません。

  • Hotfix
    現在のプロダクトのバージョンに対する変更用で、リリース後のクリティカルなバグが発生した場合に使用します。Live ブランチから設定することができます。

  • Main
    Live ブランチにデプロイするためのブランチです。Git-flow の release ブランチに近い役割を担います。
    Bubble Docs にも記載があるように、Main ブランチに直接の変更は原則行いません。

    以前は、Main は変更を加えることができる唯一のブランチであったため、すべて同じブランチから編集してデプロイしていました。作業用にカスタムブランチを作成できるようになったため、Main はデプロイ専用として保持する必要があります。
    一般的に、最上位のブランチをデプロイ用に保持することが、プロジェクトを整理するためのベスト プラクティスです。

    このように Main ブランチを常にデプロイ準備ができている（＝作業中のものがなくアプリが安定して動く）状態にしておくと、ある機能を優先してリリースしたいなどの突発的なビジネス要求にも応えられるというメリットもあります。

  • develop（カスタムブランチ）
    Main ブランチから作成します。develop ブランチについても、原則直接の変更は行いません。次のリリースに向けた開発の変更が反映されている状態にしておきます。

  • feature branches（カスタムブランチ）
    Git-flow のように feature ブランチを作るのではなく、develop ブランチ配下に作成します。新機能の開発や改修を行うブランチで、QA完了後に develop ブランチにマージされます。

    • ブランチ名には、原則イシュー番号と担当者名を紐付けます。例：hoka-295
    • develop ブランチにマージ済のブランチは、デプロイ完了後に削除します。

Bubble の Branching/Merging 機能の課題と対策

Bubble のバージョン管理システムは、（将来的にアップデートされると思われますが）マージする際に変更差分の詳細が分かりにくいという、チーム開発には致命的な課題があります。

例えば、以下では Button クリックのアクションに対して変更を行い、develop ブランチにマージしようとしています。Review changes から読み取れるのは、「アクションが変更された」という情報のみで、「アクションの各ステップが具体的にどのように変更されたのか」までは読み解くことができません。

GitHub Projects のイシューで変更差分を管理する

現状の Bubble のバージョン管理システムでは、チームメンバー間のレビューやQAが困難です。そこでソーシャリアでは、先述したユーザーストーリーなどの記載事項に加え、以下の情報をイシューに記録することで対応しています。

  • 実装前の設計
    まず、イシューで対応する変更の対象となるページやアクションなどを整理します。

  • 実装の途中経過
    必要に応じて、実装ロジックなどを記録します。特に、Bubble 特有の制約が理由で実装に工夫がいる場合は、Bubble の機能に関する特徴も記載しておきます。

  • 改修前後のスクリーンショット
    改修の変更点を視覚的に把握できるように、実装前後のスクリーンショットを添付します。（さすがに全ての変更のスクリーンショットを添付すると読み解きにくくなるので、主要な1-2枚の画像とテキストによる補足説明とすることが多いです。）

Buuble と GitHub Projects による ミニスクラムの実践

さいごは、ソーシャリアの開発チームで実践している「1週間のスプリントサイクル」のミニスクラムについて、各イベントをひとつずつ解説していきます。スクラムを基本としていますが、私たち2人だけの開発チームに必要な最小限の構成になっています。

1.スプリントプランニング（金曜日）

POが主導となり、開発チーム全体で次の1週間で取り組むイシューを決定します。

  • スプリントゴールの設定
  • 各イシューの工数見積り
  • Backlog から優先度の高いイシューを選択し、Next Sprint Backlog に移行
  • Sprint Backlog の優先度を決定
  • 担当者をアサイン

ソーシャリアではイシューの項目で優先度を管理していません。スプリントプランニングのタイミングで PO が Sprint Backlog のイシューを優先度順に並び替え、上から順に実施していくスタイルをとっています。

また、PO も Bubble 実装を 20% 程度担当することで実装の把握や Bubble の知見を深めつつ、UXエンジニアの負担を軽減するようにしています。

2.スプリントレビュー（火曜日）

GitHub Projects や Bubble の画面を共有し、メンバー間で進捗状況の確認と課題の共有を行います。

  • 進捗報告、完了した実装のデモ
  • 実装のフィードバック
  • 課題の共有と解決策の検討
  • 必要に応じて Sprint Backlog の調整

このタイミングでの完成度は70〜90%になることが多いです。というのも、開発メンバー2人の稼働時間を合わせても週 30h 程度のため、設計・実装の考慮もれや改善点がどうしても生じてきます。

私たちのスプリントレビューは、QAに向けた中間レビューのような立ち位置となっています。

3.QA（火〜木曜日）

QAでは、ユーザーストーリーが実現されることはもちろんですが、UXの違和感がないか等も確認するようにしています。

  • スプリントレビューで積み残した実装のレビュー
  • 実装された機能が要件を満たしているかを確認
  • UI / UX の改善点の確認
  • バグの検出
  • セキュリティの確認

原則として、実装者とは別の人がQAを実施するようにしています。その後QAが完了したイシューについて、QA担当者が実装ブランチ（feature branches）を develop へマージします。この時、必ず実装差分（feature branches と develop の差分）も確認するようにしています。

4.リリース（木曜日）

ここでは、Bubble のバージョン管理システムを活用したリリース手順について記載します。

  1. develop ブランチで （Settings > General >）Optimize application を実施する
    ※ Bubble の issue が出たらここで対応
  2. develop ブランチで Savepoints を作る
    ※ description には「YYYYMMDDリリース前 optimize済」と記載
  3. develop ブランチを Main ブランチに Merge する
    ※ マージする前に develop ブランチの History をみて、今回リリース対象のブランチが抜け漏れなく develop ブランチに入っていることを確認
  4. Main ブランチを Live ブランチに Deploy する
    ※ description には「YYYYMMDD定期リリース」と記載
  5. Live ブランチと develop ブランチを Sync する
  6. 必要に応じて、リリース後にしかできないタスクに対応する
    1. データの書き換え（Bulk処理など）
    2. 本番環境でのテスト（決済処理など）
    3. 他サービスとの繋ぎこみ（HubSpot、Stripe、Algolia など）
  7. リリースした実装ブランチ（feature branches）を削除する。
  8. 未リリースの作業中ブランチ（feature branches）について、Main ブランチと Sync する
  9. リリースした GitHub Projects のイシューを close する
    ※ 「YYYYMMDDリリース済」と記載
  10. POが、Next Sprint Backlog のイシューを Sprint Backlog へ移行する
  11. POが、リリースしたことを slack でチーム全体へアナウンスする

おわりに

ここ最近、Bubble や Webflow、FlutterFlow などのノーコード・ビジュアル開発ツールが凄まじい勢いで進化を続けています。特に2023-24年は、効率的なチーム開発を可能にする機能が数多くリリースされました。

新しいテクノロジーが生まれると、プロダクトの開発体制や働き方も変わっていくものです。

私たちの開発チームは、2人のリモート複業メンバーという人的・地理的・時間的な制約がある中で、開発スピードを維持しつつも質の高いプロダクトを世に送り出すことに日々チャレンジしています。（もちろん、まだまだ改善点は多くありますが、、）

進化が止まらないテクノロジーと、これからの 0→1 開発の在り方。先が見えないからこそ、実践していく楽しさがあります。この記事を通して、ノーコード・ビジュアル開発ツールの可能性や魅力を少しでも感じていただけたら嬉しいです。

「自分たちはこうしてるよ」などのご意見・ご感想などなどあれば、お気軽にコメントください。また、いいね！をいただけると励みになります！
最後まで読んでいただき、ありがとうございました😆

ソーシャリア技術ブログ
ソーシャリア技術ブログPublication

『ソーシャリア』という、ハイクラス人材とインパクトスタートアップを｢複業転職｣でつなぐサービスを運営しています。 ノーコード開発ツールであるBubbleを活用しています。 日々の学びを発信していきます。 sociareer.com/

Discussion