bubble開発の裏側

先日、以下のnoteを見てくださった人で、bubble開発、の件で何件かご連絡を頂いたので、本noteでは、先日開発したSkillAssignのbubbleの開発の裏側を書いていこうと思います。
（その他にも、たくさんメッセージ頂き、感謝感激です、ありがとうございます！）

１，bubbleとは？

GPTで叩けばすぐ出てきますが、念のため。

プログラミング知識がなくても、カスタマイズ可能なウェブアプリを簡単に作成できる、ノーコードアプリビルダーです。

デザインや機能を直感的にドラッグ＆ドロップで追加できるため、初めての方でも安心して始められます。

２，bubbleで開発した背景

・既にある社内のオペレーションを改善したい
・差別化しにくい事業ドメインにおいて、事業の優位性を担保し続けるため
・すぐ（2ヶ月以内に）検証ができる
・開発予算がない（笑）※もう失敗できない

…他にも多々要素がありますが、こんなところでしょうか。

もちろん、他のノーコード・ローコード開発を検討しましたが、

将来的な複雑性/拡張性（他サービスとの連携等）のリスクの許容度

が初期開発段階では判断できなかったので、ある一定の規模までの成長や利用も想定して、一定カスタマイズやスケーラビリティを担保した上で、bubbleを選択しました。

３，開発概要

①概要

・開発期間：約2ヶ月
・開発費用：約180万円
・開発体制：徳満＋開発者1名

②主な機能（機能要件部分）

・案件人材登録（AI登録、人材側は他登録方法を3種類用意）※1分で登録可
・検索機能
・面談申請（マッチング申請）
・案件レコメンド
・案件一覧/詳細
・人材一覧/詳細
・メール通知

※マッチングのサービスなので、いたってシンプルな機能のみ

③主なデザイン（画面数）

・Admin：8ページ
・案件側：10ページ
・人材側：10ページ

④体制・役割

開発者：デザイン・開発

・デザイン設計
・開発

徳満役割：PdM

★要件/要求定義（仕様/機能の整理・策定）
・顧客ヒアリング/セールス
・開発ディレクション

*****

★部分が、初期のローコード開発の際に、通常の開発より、めちゃくちゃ重要なので、念のため記載。

⑤要求定義

• 目的とゴールの明確化:　※めちゃくちゃ重要※
  プロジェクトの目的や達成したいゴールを具体的に定義します。ユーザーが実現したいこと
  （例：顧客管理システムの効率化、販売プロセスの自動化など）を明確にします。

• ユーザー要件:　※めちゃくちゃ重要※
  アプリケーションのエンドユーザー（社内スタッフ、顧客など）がどのように使うかを具体的に理解し、どのような機能が求められるかを洗い出します。

• データ要件:　※今回のスコープにおいては重要度低※
  扱うデータの種類や量、データの保存方法、セキュリティ要件なども確認し、データ構造の基盤を定めます。

• 環境要件:　※今回のスコープにおいては重要度低※
  対象のデバイスやOS（PC、モバイル、タブレットなど）、ブラウザ対応が求められる場合も考慮します。

⑥要件定義

• 機能要件:　※めちゃくちゃ重要（特に開発する優先度）※
  アプリケーションの具体的な機能をリスト化します（例：ユーザー認証、データ検索、レポート生成など）。
  Bubbleのウィジェットやプラグインを活用できるかどうかも評価に含めます。

• UI/UXの要件:　※今回のプロダクトにおいては重要度中※
  ユーザーインターフェースのデザインや操作性について、ユーザーが迷わず利用できることを意識して設計します。
  シンプルかつ直感的なUIを目指し、プロトタイプを早期に確認することでフィードバックを取り入れやすくします。

• 技術要件:　※最終ゴールにおける技術要件の定義は最重要※
  Bubbleが持つ制約や機能範囲を考慮し、Bubbleの標準機能で実現可能か、または外部APIなどの連携が必要かを検討。
  APIワークフロー、プラグインの使用可能性、外部データベースの連携方法なども定義に含めることが重要です。

• 非機能要件: 　※開発前に最低限の定義は必要※
  セキュリティ、パフォーマンス（ページ読み込み速度など）、メンテナンス性、拡張性に関する要件も明確にしておきます。
  特にBubbleはパフォーマンスに関する制約があるため、ロード速度やデータの量などに影響する設計には注意が必要です。

４，本当に気をつけた初期開発

・初期は、本当に必要な機能のみ作り検証
（と考えながら、今すぐ必要ではない機能も作ってしまった汗）

・初期は、デザイン、UIUXは拘らない・Figmaなどで作らない
（時間の無駄、後でどうせ変わる、特にtoCサービスでなければ、UIUXは拘らなくても、初期でも使われるサービスにはなる。）
※但し使い続けられるかは別問題

・初期は、営業を自ら（徳満）行い、自分自身がユーザーになった
（ユーザーになり得る顧客（クライアント）に営業しながら、開発＋開発ディレクションを行った）

５，ノーコード・ローコードで、開発のハードルは圧倒的に下がった

・エンジニアが採用できない
・開発費用がない

など、いまだに開発環境周りには、大きな課題があります。

ですが、開発、という観点だけでいうと、本当に下がりました。

色々調べると、実はわざわざスクラッチで作らなくても、
”このサービスは、ローコード開発で間に合うんじゃない？”
と思うプロダクトもあったりします。

*****

余談ですが、過去に2回初期開発しましたが、劇的にコストが下がりました。

1回目：Rails×GCPで、SaaS開発
2回目：TY×Next/NustのFE・BE一体型×AWSで、Shopifyアプリ開発

今回作ったbubbleをスクラッチで開発したイメージは以下（肌感）。

▼スクラッチ開発のイメージ（例：初期開発予算～800万）
・必要リソース：デザイナー1名、開発者1 or 2名
・期間：6ヶ月

・要件定義、要求定義、：～200万円（～1.5人月）
・基本設計、詳細設計：～100万円（～1人月）
・開発：～400万円（～5人月）
・テスト：～100万円

開発コスト・開発期間は、劇的に落とせました。

６，ノーコード・ローコード開発における重要なこと

開発のハードルは圧倒的に下がった

ので、開発自体に価値が薄れたように思えます。
（bubbleというアプリが、コードを書く、部分を代替した）

早く、安く、価値検証し、価値提供が実現できるようになりました。

*****

PdM・PMの力量

• ビジネスオペレーションの深い理解とディレクション

• （スクラッチの開発より）開発後のユーザー価値、検証力

• 意思決定力（ビジネス×開発、両面において総合的な優先度の切り分け）

エンジニア（開発者）の力量

• ビジネス側のスケーラビリティを考慮した設計力

• ビジネス要件の理解と、UIUXの設計、開発

• 推進力

  • PMの要件を高速でデザイン×開発に落として、ユーザー価値を提供できること
    ※言われたこと・言われた機能しか開発できない・提案できない人は向かない

７，ノーコード・ローコード開発に向く領域

ずばり、社内の業務効率化、を目指す、いわゆる「社内DX領域」は、ほぼ全てはまる、と考えています。
※はまる＝失敗を限りなく減らせる、という意味です。

理由は以下です。

①利用の価値やゴールが具体的に定義しやすい

②利用者が社内なので、インサイトを得やすい

③ワークフローをスクラッチより比較的柔軟に定義して、開発ができる

特にコマース、リテール領域においては、パッと思いつくだけでも以下の領域で応用できそうな気がします。

• 販売管理におけるオペレーション

• 在庫管理におけるオペレーション

• 店舗×EC連携におけるオペレーション

などの領域で

・繰り返し行う業務
・データを集めたり集約/活用する領域
は、bubble×GPT（or ‎Gemini）で代替できたり、基幹システムを使っていて、SaaSと連携できないという場合でも、開発の仕方やワークフローの設計、構築の仕方により、bubbleの開発で効率化・代替できる部分もあります。

特にカスタマイズすると高価だが、既存サービスがない…など規模が大きく、効率化のメリットを享受しやすい領域などが沢山ある気がしています。（長期では、SaaSを利用するより費用的に安価になる可能性もあるかもしれません）

８，最後に

bubble開発のことについて書きましたが、決してスクラッチでの開発を否定しているわけではありません。

目的、ゴール、予算、時間軸、やりたいこと、実現のハードル、AIの活用度、想定されるリスク…etc、様々な観点から判断して、スクラッチでの開発が良い場合もあります。

ということで、今回は以上です！

「学びになった！」

という方、ぜひいいね、お願いします！