🅱️

WEB開発未経験者は新規サービスを立ち上げられるのか?(ローコードツールBubbleとWEB開発に詳しい方がいればできる)

2024/12/11に公開

今年3月、弊社はデジタルスキルを可視化するアセスメントサービス、DPAS[1]を立ち上げました。
自分は開発メンバーとして参加し、なんとかローンチまで辿り着けました。
とはいえ順風満帆ではなく山もあり谷もあり、とても大変でした。でも周りのサポートもあってかサービスの開発メンバーは開発未経験者の自分と、超絶技巧アルティメットWEB開発に詳しい弊社CTOの2人で、開発に着手してから四ヶ月ほどでなんとかリリースまで辿り着けました。
Bubbleでサービス作るのどうなのよって気になっている方は参考にしてください。

なぜ未経験者が開発に携わったのか

遡ること1年ほど前

「コンテンツ作りもいいけど、プロダクト作りに携わりたい。プロダクトマネージャーになりたい。」


「しかし社内転職で希望を出したけど難しそう、諦めるしかないか。」

と思った時に


CTO「新規事業を立ち上げるんだけど」(画像はイメージです、実際はもっと穏やかな方です。)


「作らないか?」

とCTOから連絡がありました。


(あれ、これプロダクト作りに携われるし、なんならプロダクトマネージャーも狙えるのでは?)


「やりますッ゛!」

と返事しました。

プロマネ目指したいって話は元々聞いてて、汲み取ってくださったらしいのと社内でリソースが割けそうだったのが自分だったのでアサインしてくださったらしいです。
とはいえ、開発の経験は前職で半年ぐらいしかなく、WEBの開発に至っては経験0。
本当にできるのでしょうか?

使ったツール

今回はBubbleというローコードツールで開発しました。
パーツをポコポコ置いてワークフローを作るとあら不思議、サイトができるとんでもないツールです。


Bubbleの編集画面 パーツを置くだけでアプリができる

開発側でBubbleを使って開発する人をBubblerと呼んでいるのですが、全く流行りませんでした。

進め方

四ヶ月でリリースまで持っていった軌跡をまとめます。

1~2ヶ月目 要件が実現可能かひたすら検証

そもそもBubbleでアセスメントサービスが作れるのかをひたすら検証しました。(できないとの話であればBubbleを使わず開発していたらしいです。)

顧客からヒアリングをしてできたあらかじめ何の機能を作るかがリストアップされており、実装の順序をCTOと二人で話しながら決めつつ実装していきました。
アセスメントサービスと言っても意外と複雑で、例えば問題セット1つとっても

  • 問題セットがある
    • 問題とアンケート形式の2つの形式がある
      • 毎月入れ替わるセットと入れ替わらないセットがある
        • 入れ替わるものはgoogle spreadsheetからアップできるようにする
          • 毎月スプレッドシート上で問題セットを作れる

と意外と細かい要素があります。
「では問題セットのアップの仕方は?直接アップロードするの?それともAPI経由なの?」
のように詳細を詰めなければ開発が進みません。困ったときはCTOあるいは営業の方達に相談して決めるを繰り返していました。

役立った知識と考え方

未経験だけど役立った知識とか考え方とかをまとめます。

プログラミングに関する知識

ローコードツールとはいえプログラミングの知識もあった方が圧倒的に開発に有利です。
とはいえPythonで深層学習を回すみたいな難しいのではなく、if文の条件とかbool代数のような最初の方で習う知識です。
どの条件でこのアイコンを表示するか、この属性のユーザーには表示しないのような表示をロジックを考える時に役立ちました。

SQLに関する知識

SQLはプログラミングじゃないのか?と言われたらその通りなのですが、ここだけ特筆したかったので別見出しにしました。
中でもSQLについては本当に役立ちました。
ローコードツールとはいえ結局DBとは切ってもきれない関係、ユーザーの情報、スコアを出す場合などDBにアクセスする場面は山ほどあります。
例えばDBにスコアのデータを貯めつつスコアの総合得点とカテゴリごとのスコアを出すのようなテーブルデータの集約や連結されているデータの抜き出しのような場面でSQLの知識が役立ちました。
とはいえSQL構文を書くわけではなく(User's name)のように構文わからなくても書けるような書き方でした。

Gitの知識

Gitと同様、ブランチの機能やマージ、コンフリクト解消の機能もあります。
元々知識があったので作業がごっちゃにならないようにこの機能はこのブランチで、このタイミングでマージするからコンフリクトが起きる可能性あるから気をつけてと作業が進められました。

とにかく手を動かす、分からなかったら聞く

あれこれわからんと考えるのではなく、自分なりの仮説を立てて実装するを徹底しました。
わからない事象が起きたらまず自分で調べて、それでもわからなければ「こう作ったけどうまく動かない」をまとめて聞くを徹底しました。

するとCTOがエラーが解消されてくださり、動く。
(忙しいのに合間縫って対応してくださったCTOには感謝しかないです)

苦戦した箇所

うまくいかない箇所もたくさんありました。

DBの構造設計

正解もない上に、後述するパフォーマンスの話もあるので本当に難しかったです。というかほとんどCTOがやってくださりました。
一個のDBではなく複数DBがどのように連携するのかも考えないといけないし、シンプルにするとデータの抜き出しやソートがうまくいかなくなったりとそれはそれは大変でした。

API連携

次にAPI、ドキュメントを読んでもいざ実行ってやると、うまく動かないがよくありました。
サーバーのログとか見ても404とか403とかインターネットのミームでしか見ない数字がわんさか、原因を探ろうにもサーバー側は数値といまいちパッとしないエラー文が返るのでよくわからないし、全部設定削除して作り直したらできたとかよくありました。
作り直したり、なんなら0から設定をしてくださったのもだいたい弊社CTO。

生成AIを使ったコード生成が使えない箇所が多い

変数を入力する際にクリックでしか入力できない点も苦労しました。(場合によってはコピペで可能です。)
表を作成するところはHTMLを使って書いたりはできたのですが、それ以外はクリックでしか入力ができないので
chat gptを使って生成→変数名を入力
ができません。
ワークフローもクリックで設定するので同様です、やや生成AIと相性が悪い箇所があるなと思いました。

3~4ヶ月目 ひたすら実装

1〜2ヶ月目の検証を並行しつつ実装を進めていきました。

苦戦した箇所

デザイン

ただ動けばいいは終わり。ではなくユーザーが使いやすく有用であるサービスでないと使ってくれません。
使いやすくするためにも良いデザインで作る必要があります。
とはいえデザインなんて学会の発表のポスター以来やっていないし、実装したら


「こんな画面を作ったんですけどどうですか?。」


「うーーん、ゆとりが欲しい」(画像はイメージです、実際はもっと穏やかな言い方をしてくださります。)

とやり直しのFBをいただくのもしばしばあり、自分たちでページのレイアウトこんなのどう?ゆとりがないからもうちょっと広げよう、ゆとりがない男はモテない[2]みたいな議論をしながら作り進めていきました。

他にもBubbleにはグループという概念があります。グループ内で横揃え、だけどグループの枠は立て揃えになるなど細かい配置の条件ができるのですが、どっちがどっちの配置を指しているのかわからなくなり、よく混乱しました。

パフォーマンス

ただ実装すればいいではなく表示が遅かったらだめです。
このあたりについては知識があまりなく、CTOが大体やってくれました。

単体だとうまくいくけど他のページと連携するとうまくいかなくなる

一個一個のページは問題なく動くのですが

トップページ→問題受検ページ→結果表示

のようにページが遷移すると結果表示の箇所でスコアがうまく表示できない場面がありました。
そのあたりはBubble側でデバック機能があり、ページ遷移した時にどんな値が渡されているかを可視化できるので助かりました。

ついにリリース

これも開発あるあるなのでしょうか、リリース直前の社内のユーザーテストでバグが発覚して大変な目に遭いました。がCTOがなんとかしてくださりました。
そして今年の3月、ついにサービスをリリースしました。


打ち上げで食べたモンブランが身に染みた

リリースしたら各所からいい反応もあればこれこうして欲しい、これどうにかならないのかのような指摘がいろいろなとこから飛んできており、自分たちが作ったプロダクトが世の中に出たんだなぁととても感慨深かったです。

今やっている仕事

リリースしたら終わりではなく、

お客さんの声を聞いて要求の裏側を探る→新規機能を実装する

仕事に取り組んでいます。
開発もしつつPdM的な内容もしており、1年前ぐらいにPdMになりたかったなって願いはなんとか叶いました。
がとにかく想像以上にPdMって大変だなぁと思う場面が山ほどあります。例えば開発計画1つとっても

  • 将来なんてわからないのに開発計画を立てないといけない
    • じゃあ「その計画を立てた根拠は?」と言われるとふわっとした回答しかできない
    • 根拠付も客観データを使おうが解釈は主観によるのでやはりふわっとしたものになる
    • 計画が立ってる上で各所からこれを実装して欲しいって声が飛んでくる

と将来を考えないといけないし、各所との折り合いをつけないといけないしと想像していたPdMとは離れていました。

とはいえ自分たちが作ったプロダクトの声をお客さんから直接聞くと我が子が旅立って活躍しているような気分になり、嬉しく参考になります。

今後もよりよいサービスになるようがんばります。

前回書いた記事
https://zenn.dev/aidemy/articles/b30501ee3e1737

脚注
  1. https://dpas.org/ ↩︎

  2. 出典はない ↩︎

Aidemy Tech Blog

Discussion