本ページは、3/9に実施された「構想開始から4か月でMVPローンチ！新規事業”ウルカモ”開発の裏側を大公開します！」のまとめ記事の後編になります。4か月でサービスローンチまでに至った背景を”スピード”をテーマに、ウルカモ開発に携わった3名にお話を伺いました。

● ファシリテーター 上村康太 ＠kota
● プロジェクトリーダー 黒田励 ＠kuro
● 開発責任者兼PdM 門田英晃 ＠kadota
● デザイン責任者 光井英子 ＠qoo
※以下、Slackネームでお届けします。

＜前編はこちら＞

デザインにおけるスピード向上のポイント

kota：デザインを早く進める上ではどういうことを心がけたんですか？

qoo：①〜③は早く進めるために絶対に大事だと思っていました。特に新規事業でかつスピーディーにスクラッチでやらなきゃいけない場合は、デザインシステムを作らない方がいいなと思っていて。今回作らないと決めたのがスピードを出せたポイントだったかと思います。

qoo：まだ答えを誰も持っていないのに、色々デザインについての意見が集まってきていつまでたっても決まらず、自分が御用聞きみたいになってくる状況は、一番最初に防がなきゃいけないなと思いました。ウルカモというサービスにおいて影響が大きいこと、かつ答えがないことに関しては、事業部長の山田も含めて合意する、逆に影響範囲がプロダクトに限るようなところであれば、それは私とkadotaさんが責任者として決められるようにできたのは大事なポイントだったと思っています。

qoo：「デザインを都度見せない」と繋がるんですけど、逆にワイヤーフレーム（以下、WF）は粗くてもとにかく早く作って、全機能と画面が網羅されている状態で全員に見せていました。そこでアウトライン等は合意して、WFを見ながらオペレーションチームはオペレーション設計を、マーケはマーケの戦略を考え始めるといった進め方をしてました。

（実際のFigmaの画面）

kota：WFはどれぐらいの期間で作りましたか？

qoo：WFは2営業日とって集中して一通り全部作り、そこから更に詰めて、完成までは1か月かかったかな？ぐらいの感じでした。コンポーネントは最低限だけを使っていて、（カウカモはデザインシステムを作っているので）それを活用して拡張性のある形で進めていました。

kota：デザインシステムは作らないけど、カウカモのデザインシステムはベースになっていたという感じですかね。

qoo：参考にしつつ、カラーパレットとかタイポグラフィみたいなベーシックなコンポーネントはカウカモのデザインシステムを基準にする作り方でした。

開発におけるスピード向上のポイント

kota：開発ではスピード実現のために何をやりましたか？

kadota：まずエンジニアリソースとしては、フロントエンド1人、バックエンド1人。年明けから本格的にスタートみたいな状況でしたね。
ローンチしてうまくいかなかったら廃止にするっていう選択肢もありうるので、できるだけ作らないっていうのを心がけていて、本当のMVPってどこなのっていうのを議論し、それしか作らないと決めて取り掛かりました。

最短で開発を進めるために、エンジニア間で議論しながらという状況は避けたかったので、②（API仕様の定義と合意に時間をかける）を心がけました。ウルカモは API を介してフロントエンドとバックエンドが分かれているんですけど、そこでどういう情報をやりとりするという定義を入念に決めておいて、それぞれ開発に入りました。Slackでここはどうだっけ？みたいな確認は随時していましたが、接続テストまでに1回もMTGはしてないと思います。総じてトリッキーなことはやっていなくて、ひたすら自分の得意領域でコードを書き続けた1か月でした。テストの際に本当に動いているよ、と思いながら皆さんに見せてました(笑)

kota：うまくいったのは API 仕様の定義の精度が高かったということなんでしょうか？

kadota：フロントエンドは API から定義通りの情報が来るというところで作っているし、バックエンドは絶対に定義通りの情報を出すっていうのを合意して、OpenAPI Specificationという規格に基づいて作ってました。

kota：①の SaaS の活用というのは具体的にどんな感じですか？

kadota：技術的にはフロントエンドは Next.js を使っていて、Vercel という基盤の上で動いていて、バックエンドは Ruby on Rail で API だけで動いていて、ログインのところにFirebase がフロントエンドと繋ぎであったりだとか、管理画面は Querier というサービスを使って、コードを書かずに運用画面を作ったところもスピードに貢献していました。

kota：今回小さく生むことにフォーカスして作られたと思うんですが、拡張をする上で積み上げていけるものなのか、刷新するものなのか、どのように行うんですか？

kadota：刷新までは考えてなくて、いまはまだ機能が足りない状態なので、どんどん付け足していく開発を想定していますね。

kota：機能を絞るのは大変だったと思うのですが、kadotaさんが決めるぞって感じで進めたんですか？

kadota：最初はデザインを作っていく中で、ここは怪しいなというのを関係者と合意していましたが、開発して動くものが出てくると、みんな品質向上を求めてくるんですよね（笑）じゃあ品質に振る分、この機能は捨てよう、例えば具体的には退会は問い合わせにメール送ってもらおう、みたいに機能を落として絞り込んでいきましたね。

kota：今回、開発責任者とPdMを一人でやることのメリット/デメリットってどんな感じだったんですか？

kadota：メリットは関係者が減ることでコミュニケーションロスが減るから、ダイレクトに意思決定者間でコミュニケーションができるっていうのがあったと思います。

qoo：あとPdMというところでいくと、見ているところがサービスや事業とか全体に渡ると思うので、プロダクト全体を通して、ここを優先すべきとかこういう体験にすべきだよねという論点で話しつつ、「ちなみにバックエンドではこうなっているよ」みたいな、一人が担っている良さもありつつ、やりやすかったと思います。

kadota：嬉しいでござる。

qoo：デメリットとして、忙しそうというのはありました(笑)
あと開発者としての自分とPdMとしての自分という人格の切り分けは大変だったかと思います。

kadota：自分が使っていて嫌なものは作りたくないなというのはあって。qooさんが作っているものはいいものだから実現したいけど、この期間で実現するのはどうしようみたいなのは考えましたね。

kota：意思決定者の中でも、プロダクトの中でも、コミュニケーションコストを削るのは全体的にビッグテーマだったというのはありますね。

今後の展開について（質疑応答）

kota：（チャットでいただいた質問）今後の展開や勝ち筋はどんなことを思い描いているのでしょうか？

kuro：そもそも根本的には住まいを売るユーザーさんのペインとか大変そうな思いを解決したくて作っていて、そういうところがちゃんと届けられているなって声をいただいてます。個人的にびっくりしているのがSNSとか結構すごく喜んでくださる方が多くて、こういった声が僕らの励みになるし、丁寧に拾っていくことが勝ち筋というか、大事にしなきゃいけないことだなぁって。しっかりユーザーの声をちゃんと拾って、事業を作っていくことを大事にしたいと思っています。
そういう人々に価値を提供する、愛されるプロダクトなり、サービスになるっていうのが一番の勝ち筋かなと思います。

おわりに

今回の座談会には30名以上の方にご参加いただきました。残念ながら本記事には書けなかった開発の裏話や、登壇者の関係性も垣間見えるような掛け合いも多く、皆様から多くのコメントや質問をチャットでいただけ、運営担当として温かい気持ちになりました。
是非ウルカモの応援をよろしくおねがいします！

＼ウルカモを一緒につくる仲間を募集中／
カジュアル面談からも歓迎です！是非お気軽にご連絡ください！