DIGGLEエンジニアのreenjです。
2024年11月から新規事業開発に携わるようになりました。立ち上げから約4か月が経過しました。今回のブログではこの間の経験や学びを共有させていただこうかと思います。

新規事業の始まりから現在まで

※ Bubble®はBubble Group, Inc.の商標です。DIGGLEは独立した法人であり、Bubbleとは関係ありません。

プロジェクトの始動

2024年11月初旬に人員管理プロダクトの開発プロジェクトのキックオフが行われました。キックオフでは2つの大まかな方針が決定されました。

1つ目はMVP(Minimum Viable Product)でなるべく早くにプロダクトを開発し、早期のフィードバックループ構築を目指すこと
2つ目は、まずはローコード開発ツールのBubble® を使用して画面イメージを具体化し、Bubble® によるMVP開発が可能か検証することです。

ただし、この時点では画面イメージや主軸となる機能の方針などは大まかに決まっていたものの、具体的に開発する機能についてはあまり定まっていませんでした。

ローコード開発の限界

Bubble® による開発を開始してみると、そのメリットとデメリットが明確になってきました。基本的な機能の実装は比較的容易でしたが、少し複雑な処理を実装しようとすると、さまざまな工夫やプラグインの活用が必要になりました。

例えば、スプレッドシートとの連携です。これはプラグインなしでは実現できず、プラグインで実現できたとしても、プラグイン側で何ができるかの制約が発生します。より自由に連携できるように、APIでの操作をサポートするプラグインを使用した場合は、自由度は上がるものの、コードで書いてしまうほうが早いかもしれません。

また、テーブルも複雑な処理を行う場合は作成が難しくなります。
以下の画像は、部門×ポジション×等級で、各月の人員計画とその実績を表示するBubble® のテーブルです。データとして保存された各月の値の表示は、それほど苦労せずに表示することができます。
しかしながら、この値を累積させようとしたり、表示している期間より前のデータを取得し、累積値に含めようとしたりした場合などは、表示することが難しくなります。
そういった計算を行うためには、表示しないテーブルを作成し計算を行い、その見えないテーブルの要素を参照するといった工夫が必要になったり、プラグインを入れたりする必要が出てくるかと思います。

約2週間の検証期間を経て、私たちが目指す機能の複雑さを考慮すると、Bubble® での開発継続はメリットが少ないと判断。Railsでの開発への移行を決定しました。

Bubble: The full-stack no-code app builder

Railsによる開発への移行

Railsでの開発に移行後も、MVPの早期実現という方針は同じです。私一人での開発であることを考慮し、既存プロダクトの基盤を活用し、認証機能やインフラ整備などの基盤構築に時間を取られることを避けて開発を行うことにしました。

ここで課題となったことは、新規開発部分を既存システムからいかに適切に分離するかということでした。Railsのエンジン機能を活用することで、新規事業に関するコードの大部分は独立した名前空間に分離することができました。

既存システムに依存した箇所はあるものの限定的であり、MVPの早期実現という点ではこの方法は効果的でした。

railsguides.jp

顧客価値の創造に向けて

1月下旬には当初想定していたMVPが概ね完成し、顧客への提案を開始しました。顧客との直接的なコミュニケーションを通じて、真に価値のある機能の特定と開発を進めています。複数の顧客からのフィードバックを集約し、次期開発機能を考えタスク化しその優先順位付けを行っています。

直面した課題

横断的なチームの難しさ

新規事業では、これまで同じチームとして働いていたエンジニア以外のメンバーと新たなチームを構築し、事業を推進することになりました。このチームは複数部署からのメンバーで構成される横断的な組織体制です。

通常のスクラムチームでは、メンバーの役割を固定せず、必要に応じて柔軟に協力し合うことが重要とされています。しかし、新たに組織されたチームで、異なる知識領域や業務分野を持つメンバーが、主にリモートワークで一つのプロジェクトを進める状況では、柔軟な協力体制の構築をするのはとてもチャレンジングでした。

意思決定プロセスの難しさ

従来の開発フローであれば、タスクやストーリーをカンバンボードに作成し、優先順位を付け、開発を進めるという流れが確立されています。この流れを支えるのは、定例ミーティングやデイリースクラムといったイベントと、それらに参加するメンバーの構成です。これらは効果的な意思決定プロセスを作る上で非常に重要な要素となります。

少人数のチームであれば、全員がデイリーイベントに参加することが全体の意思決定をスムーズにするもっともシンプルで効果的な方法かと思います。

しかし私たちのケースでは、多くのメンバーは新規事業に100%専念はできないという制約がありました。そのため、イベントへの参加者が分散し、一部のメンバーが参加したイベントで決定したことは、別のイベントの際に再度他のメンバーへ共有し、全体の認識を合わせて意思決定を行う必要が出てきました。結果として意思決定プロセスが不明瞭になり、決定事項と決定していない事項が不明瞭になりました。また、意思決定されるまでに時間がかかってしまうようにもなりました。

解決策

新規事業が開始してしばらく経過した頃、私はコミュニケーション不足を感じるようになり、横断的なチームの各メンバーが柔軟に協力し、効果的な問題解決や意思決定のプロセスを作るためには、オープンなコミュニケーション環境の整備が極めて重要だと実感しました。リモートも多くこれまで交流の少なかったメンバー同士であるため、新規事業のメンバーでのデイリーミーティングを行ったり、ランチセッションなどコミュニケーションの機会を意図的に増やしました。

また、私の場合はDIGGLEのオフィスから近い場所に住んでいたため、手頃にコミュニケーションを増やす手段として、フルリモートワークから一部出社に切り替え、物理的な距離が縮まることでメンバー同士のコミュニケーションが少しばかり増えました。これによる変化は大きかったです。徐々に意思決定のスピードが上がり、認識の齟齬も減少。結果として、プロジェクトが以前より円滑に進行するようになりました。

異なるバックグラウンドを持つメンバーで構成される横断的なチームにおいては、ポイントポイントで対面コミュニケーションも織り交ぜながらプロジェクトを進行するのもよい効果があるかもしれません。