クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

新規プロダクト開発におけるPhaseごとの技術選定あれこれ

f:id:APPLE4869:20191225135543p:plain

はじめに

このブログはクラウドワークスのアドベントカレンダーの最終日の記事です。(今年もクリスマスイブをアドベントカレンダーで使ってしまった・・・。)

クラウドワークスの副社長をやってます @shuzonariata です。

現在自分はエンジニアリングDivの管掌役員やその他事業管掌もしているのですが、新規事業の開発の責任者も行っています。新規事業では、クラウドワーカーの新しいマッチング体験を実現するプラットフォームサービスを作っています。

そこで今回のアドベントカレンダーでは、そんな新規プロダクト作りの裏側で、どんな技術選定をしてきたか、なぜその考えに至ったか、どんな結果になったか、そんな経緯をまとめてみることにしました。(ちなみに新規サービスは2020年の年始には公に発表できると思います。乞うご期待)

※なおこのブログは新規事業のチームメンバーで、プロダクトマネージャーでありUXデザイナーの@takuto0516との共著です。

そもそもなんで新規プロダクト開発のことを書くか?

これまでクラウドワークスでも色んなプロダクトを検討し、試してきました。多くの会社でも何度となく新規事業を試してきた経験があるんじゃないでしょうか?

ただ、当然新規事業や新規プロダクトは、とても不確実性が高いです。特に世の中の多くの人に刺さるようなプロダクトを作ることは容易ではなく、アートの部分が多くを占める部分も実際あります。

一方で、アート的側面に加えて、イノベーションを起こしていくプロセス自体は、技術選定や開発手法などサイエンス的要素も強く、実体験に基づいた意思決定を追体験してもらうことで、今後新規プロダクトを作っていく開発チームやプロダクトマネージャーの参考になればと思ってこの記事を書くことにしました。

プロダクト開発に関する技術選定のステップ

さて、実際、プロダクト開発における技術選定ですが、考えるステップとしては

  1. 立ち上げ期の技術選定をどうするか?
  2. 拡大期にどんな技術選定を行い、立ち上げ期からどう移行するか?

を考えていく必要があると思ってます。

で、下記の図が、実際の意思決定の分岐点を整理してみたものです。

f:id:shuzonarita:20191225105835j:plain

*上記画像の選択肢はあらゆる可能性の中から残った有力なもののみ記載してます。

順を追って説明します。

Phase1:立ち上げ期にどのような技術選定で進めるか?

f:id:shuzonarita:20191225110346j:plain

技術選定のパターン整理と意思決定

まず新規プロダクト開発は、一般的に

  1. コンセプト(顧客の課題と、その解決方法)の仮説立て
  2. MVP(Minimum Viable Product:最小検証可能プロダクト)でのコンセプト検証
  3. コンセプト検証に従って、初期プロダクト作りとPMF(Product Market Fit:ビジネスモデル含めてプロダクトが経済的に成り立つことの証明)
  4. プロダクトのスケール(マーケティング投資+システム規模拡大)

と進んでいきます。

1と2で、MVPを使ったコンセプト検証を終えて、「なんとなくこんなプロダクトを作ったらよさそうだ」ということが見えたら、実際に具体的なプロダクトを開発していくわけですが、一番初期の技術選定はとても大事です。

というのも、初期の技術選定で、スピードと品質と拡張性を大きく変えてしまう可能性すらあって、そのまま進んだ結果巨大サービスになっても初期の技術的な制約に引っ張られたり、初期の検証段階なのにやたら時間とコストがかかって、結局うまくいかないことが半年後わかった、なんてことも多々起きるからです。

今回僕らの手元にあった選択肢としては、ざっくり

  1. スピード重視でライトに作る(この場合、例えばHerokuを使ったり、Firebaseを使ったり)
  2. 初期から丁寧に作る(この場合、例えばAWS×Railsで実装)

の二択です。

1の中でも、HerokuなどのPaaSを使う、とか、Firebaseを使う、とか、選択肢があがったのですが、今回は最終的にはAWSに移行する予定も明確にあったり、Herokuは使ったことあるけどFirebaseはない、みたいな理由もあり、技術的チャレンジ観点からも「Firebaseを試してみる」選択肢が濃厚になり、結局、スピード重視パターンでFirebaseでSPAのプロダクトにするか、AWS環境かつ社内知見の多いRailsで作るか、という意思決定を考えました。

このスピード重視でライトに作るverと、初期から丁寧に作るverで、それぞれいい面悪い面があると思ったので、時系列も意識してメリデメを整理してみると、以下のようになりました。

  • スピード重視でライトに(Firebase)

    • メリット
      • 初期は圧倒的にスピード感を出せる(最速簡単なアプリなら1日程度でスタートできる)のでメリット大きい
      • よりモダンな開発環境になることで技術的なチャレンジになり採用効果にもつながる可能性
    • デメリット:
      • スケールする段階だと開発効率の観点からバックエンドの移行(AWSへの移行、Railsなど別フレームワークへのコードの書き換え)が求められる
  • 初期から丁寧に作る(AWS+Rails)

    • メリット:
      • AWSRailsもcrowdworks.jpで使われている技術なので、すでに社内知見があり、無理なく実装を進められるので、安心感がある+後々の移行コストは低い
    • デメリット:
      • 初期コストでFirebaseと比較すると遅い(AWSの環境設定や初期実装項目をFirebaseよりもコーディングする必要から、大体14~20日程度追加でかかる)
      • Railsで作ったとして、複雑化してくると開発スピードが逓減していく(ので本当にスケールすることを想定すると別の型付け言語とかの方がいいし、結局そのタイミングで別の技術への移行も必要かも)

この整理のうえでどちらにするか、ですが、今回のプロダクト開発は、コンセプト自体の検証はできたものの、ビジネスモデル(課金方法、体系)、サービスでカバーする体験の全容自体はまだ固まりきっておらず、初期のプロダクトを作ったあとも、継続的に顧客ニーズ調査を行ていく必要があると考えていました。

この段階は、まだまだアイデアレベルのプロダクトなので、実際に作ったサービスが最終的に使われない可能性は十分にあります(むしろ早い段階で使われない理由を明らかになればそれはそれでGood)。

その前提に立つと、初期の技術選定では、捨てることになっても何とかなり、品質よりもスピード優先で実装できるものの方がいいだろうという話になりました。作り始める時点から、サンクコストがかからないように上記を重視して技術選定を行い、中期的には移行コストや多少の無理はあっても短期のスピード感を重視して、今回はFirebase×SPAでの実装でいこうと決めました。

その結果どんなことが起きた?

その結果として、MVP~初期プロダクトレベルでは、最初のフェーズの要件定義からデザイン、開発までトータルで1週間でプロダクトを作ることができました。

ユーザーにフィードバックをもらう中で一度0からの作り直しも経験しましたが、これもプロダクトの品質を高めるうえでよい点で、これはまさにFirebaseでライトに作るメリットでした。

その結果、作り直しも含めて1ヶ月程度で、プロダクトの方向性が定まり、ユーザーに受け入れられる形を見つけることに成功しました。ここは事業立ち上げにとにかく早くユーザーにぶつけられたので非常に良い意思決定になったと思います。

Phase2:拡大期にどのタイミングでバックエンドの移行をおこなうか?

f:id:shuzonarita:20191225105919j:plain

技術選定のパターン整理と意思決定

次に、バックエンド移行の意思決定です。

上記の通り、初期はFirebase環境でプロダクト開発を進めましたが、デメリットとして書いた通り、中長期では開発スピードや効率が落ち、バックエンドの移行(インフラだとAWSへの移行、バックエンドのコーディングはRailsなり別の言語・フレームワークでのコード書き換えなど)はいずれにせよどこかで必要になりました。

プロダクトがある程度離陸するイメージしたらAWSへ移行し、バックエンドもRailsないし別の型付け言語や拡張性の高いフレームワークへの移行を検討していたのですが、このタイミングが結構ポイントです。

というのも、そもそものサービスレベルとして、どこまでが初期プロダクトで、どこからがスケール段階なのかの線引きが難しい。

開発を進めていくと、あの機能もほしい、この機能もほしい、となり、結果的に初期プロダクトで想定していた機能群の何倍にも必要機能が膨らむことがあります。

今回もそこまでではないにしても、当初想定していたプロダクトよりも工数が膨らみ、結果、Firebaseのままでいくのか、AWSへの移行とRails(や別フレームワーク)への移行をしてからその追加項目を実現するのかで悩みました。

その中での判断軸は、

  1. ビジネスモデルの成立を証明できるレベルに、ユーザーが最小限満足するサービスレベルは必要
  2. そのサービスレベルに行く前に移行しても、結局サービスがうまくいかず今までの努力がおじゃんになる可能性もある
  3. 一方で、そのビジネスモデルの成立が見えたタイミングでは、次のシステムスケールを想定してインフラやバックエンドも移行しないといけない

みたいな点でした。

これらの状況を踏まえインフラとバックエンドの移行をいつやるかが問題となりましたが、チームの開発リソース(フルタイム1名、週2日の業務委託2名)で、移行をするとなるとプロダクト改善のスピードが一定期間かなり落ちてしまう状況でした。

この短期的な検証とグロース、そして長期的なプロダクトの拡張性のトレードオフの中で、結果的にはプロダクトのグロースをより重要ポイントとして、バックエンドに移行せずにFirebaseの開発でしばらくいくことにしました。

結局、サービスとして、最小限ビジネスモデルが成り立つポイントまで開発していかないと、結局作ったものが無駄になりかねない。それだけは避けたいし、そうなったとしても最小コストでいきたい。そのためには、バックエンドへの移行に時間をかけるのではなく、まず最小限ビジネスとして成立するユーザー価値提供を完結してから次のことを考えるべきだと思いました。

ユーザーの課題解決だけでなく、ビジネスモデル、課金のところまで含めてがプロダクトです。そこまでの検証を終えるまでは、本格的なバックエンドの移行もインフラの移行も不要。まずは顧客価値を検証することに集中すべきでした。一方で、それができたら、迷うことなく時間をかけてちゃんとバックエンドを整える。

そんな意思決定が重要なんじゃないかと改めて思いました。

その結果どんなことが起きた?

結果、この方針に沿って、中の人の手を介さずともサービス体験を完結し、お金を支払うレベルのサービスにまでプロダクトの作り込みを行うことができ、コンセプト検証から追加1か月程度で無事リリースレベルにまで持っていくことができました。初期の顧客獲得も一定度成功し、これからはスケールを考えるステージに入っています。コストを大きくかけず、顧客提供価値に一旦集中し開発を進められたからこそできたことだと思っています。

今後は、スケールするタイミングに入っていくので、ズルズルと短期機能の開発を続けてそのままフロントエンドが肥大化することは避けるべきです。次はいよいよバックエンドの移行が待っていて、そのタイムラインについても整理ができました。

必要最低限のサービスレベルの見直しと、バックエンド移行のタイミングを柔軟に設定しなおし、明確化したことで、それまでに必要な機能の優先順位づけやリファクタリングを緊張感をもって進めることができた点が、よかった点じゃないかと思っています。

蛇足:副業人材活用

話は逸れますが、今回のプロダクト作りでは、最初から副業のエンジニアの方にも助けてもらって、スピーディな開発体制の構築と実装を意識しました。

必ずしも社内のエンジニアだけでなくとも今やクラウドワーキングの時代ですので、副業や業務委託で関わってもらい、どんどんサービス開発していくというのはこれからますます自然になっていくなあと感じました。

新規プロダクトを作る場合は、上記のように状況状況に応じた意思決定も重要ですし、チームビルディングも柔軟に行う必要があるなと、改めて感じました。蛇足です。

最後に:今後の構想

f:id:shuzonarita:20191225105934j:plain

最後に今後の開発の構想ですが、これからはサービスがスケールするPhaseに入っていきますので、いよいよバックエンドの移行についても真剣に考えるタイミングになってきました。

具体的な選択肢は拡張性重視なのか知見・開発スピード重視なのかで、Springなどを使うのか、Railsを今まで通り使うのか、など意思決定を迫られていて、絶賛検討中です。

また、今後は早期のAPI公開なども検討し、できる限りファットにならず、スモールなコンポーネントを維持し続けることと、可能な限りドメインを明確に区切り、それぞれが疎結合な状態を保つこと、そしてコード当たりの売上(生産性)の最大化を図っていけるような、そんな開発チームへと進化していきたいと考えています。データ基盤を作ってマッチングアルゴリズムを洗練させたり、見えないところでの価値増強にも早期に着手していく予定です。

日本を代表するギーク達の血の滲むような努力の結晶であるコード・システムが、想像以上に顧客価値につながらないケースは多いと思っているし、そんなことはあってはならないと思ってるので、その点を改めて意識しながら、システム・ソフトウェアを通じた社会的価値の最大化に向けて、洗練度の高い開発を行っていけるようにがんばります!

これまで話してきた新規プロダクト。来月にはサービスの全容も明らかになってくると思いますので、新しいクラウドワーキングの形を作っていきたいエンジニアの方がいたら、@shuzonarita まで是非お気軽にご連絡ください~

読んでいただいてありがとうございました!メリークリスマス!

© 2016 CrowdWorks, Inc., All rights reserved.