Vol.4 Railsの導入背景や取り組みについて
おはようございます。こんにちは。こんばんは。
ハグカムでCTOをやっておりますPontoです。
今回のテーマはRails導入背景や取り組み、となっています。
弊社ではもともとPHPでサービスを展開していたのですが、新サービスを立ち上げるとき(2019年)にRailsを選択しました。PHPで統一するのではなくなぜRailsにしたのですか？と聞かれることが多いのでその辺りの意思決定のプロセスや理由について今回は書いてみようと思います。
背景
2019年はまだマンツーマンの英会話のサービスのみを展開していました。この頃はまだコロナの前でオンライン教育も今ほど浸透していないような時期でした。
基本的にはオフラインが主流のため、あまりサービスも伸びていませんでした。
そのときに展開していたビジネスは、
英会話のマンツーマンレッスンをtoC向けに（主流）
英会話のマンツーマンレッスンをtoB向けに（数社程度・積極的な営業なし）
といった感じでした。ただ問題なのは集客の伸び悩みであり、新しく何かを試す必要がありました。細かい点は省略しますが、その中の一つの案としてグループレッスンを試してみるという形になりました。
このグループレッスンに関していくつか考えていたのは、
お安く提供できるので顧客層を広げられるかもしれない
toCは未知数。(値段がネックであれば)伸びるかもしれないし、そうでもないかもしれない
toBはむしろマンツーマンよりも市場の機会がありそうだ（よくある塾のコースの値段帯と原価がマンツーマンだと合わないが、グループであれば合う、など）
さて、全部作りますか？
3ヶ月とかかけて作ってようやく持っていってから、事業検証しますか？遅いですよね。。。人はたくさんいますか？いないですよね。。。お金たくさんかけますか？お金ないですよね。。。ベンチャーってそんなもんですね。
じゃどうするか？
よくあるパターンだとは思いますが！何でも作るのはやめましょう！
開発コストを劇的に下げる方法を考える
何かを検証したいですか？この開発で成し遂げなくてはならないのは何でしょうか？本当に必要なものはどれでしょうか？
プロジェクトの進め方を工夫する
A → Bの順番で作るか。B → A なのか。
開発側の選択肢は何でしょう？
大きく3つ考慮しました。
マンツーマンのシステムを増築してグループレッスンを提供
別のアプリケーションとする。但しマンツーマンのシステムをクローンし、必要な機能を残す・必要な機能を足す
別のアプリケーションを1から作る
はてさて、どれがいいのか...
さて、状況を取りまとめてみましょう。
覚えている範囲で...
ビジネス側の条件面
toCマーケットのグループレッスン需要
需要はなくはない
当たったら大きいのはこちら、けど可能性は低そう
toBマーケットのグループレッスン需要
前評判: 顧客ヒアリングである程度よさそうな仮説があった
一度入れば安定収益
状況を鑑みると、おおよそこんな感じで行けば良いのでは？
まずはティザーサイトを作り、集客をする。( ~1w)
toC向け集客がうまくいった場合、そのままtoCのサービスを展開する。toBは急がず展開していく
toCの集客がうまくいかなかった場合、toBを優先して営業を行う。うまくいけばまずtoBをベースにサービス展開。遅れてtoCへ展開。
toBもあまり芳しくない場合はtoCへサービス展開。但しそこまで急がない。
では、次にプロダクトの条件面を詰めていきましょう。
プロダクトの条件面
まず初期はLPとユーザ登録程度の機能で良い
マーケット選定が超重要
状況に応じて必要なものが違うので、開発優先順位が大きく変わる
このような感じかと思われます。
→ 少なくとも別プラットフォーム以外の選択肢でスピーディな構築ができなさそう。(ティザー以降の開発で急激に詰まるだろう）
条件を満たす開発条件は？
各選択肢の良いところ・悪いところを確認してみましょう。
マンツーマンのシステムを増築してグループレッスンを提供
レッスン画面などは作り直しもしくは追加が必要
DBがマンツーマンが大前提となる作りのため、追加もしくは変更
先生のスケジュールの管理が一箇所に集まる
同じフレームワークなので学習コストなどは比較的少ない
古いフレームワークリスク(メンテが止まってしまっている)
別のアプリケーションとする。但しマンツーマンのシステムをクローンし、必要な機能を残す・必要な機能を足す
必要ではない機能が思ったよりも多い
先生のスケジュールの管理が複数箇所になる
レッスン周りの一番複雑な部分が結局作り直しになる
同じフレームワークなので学習コストなどは比較的少ない
古いフレームワークリスク(メンテが止まってしまっている)
別のアプリケーションを1から作る
不要な機能は少ない
必要な機能はすべて自作する必要がある
(やるなら)違うフレームワークにするため、古いフレームワークリスクはなくなる
先生のスケジュールの管理が複数箇所になる
上記を鑑みたとき、以下の観点より「別のアプリケーションを1から作る」の採用に至りました。
スピーディさ
素早く機能を提供できること
軽やかさ
計画変更が容易であること
また、フレームワークはその時点での社内の人員が一番開発スピードが出るものを選ぶことにし、Railsに慣れているメンバーだったため、Railsを採用するに至りました。このタイミングではフレームワークや言語間での差異は重視はしませんでした。
但し、この選択をする際に一点だけ問題が残りました。オペレーションとして大きく請け負わなくてはならないリスクとして、先生のスケジュール管理の複雑姓が増すという影響がありました。
その後どうなったか？
toCの反応は必要だと思う規模感ではなく、toBマーケットの反応が良かった。
計画通りに事業展開
集客のタイミング上短い期間でtoBへサービスが展開できる形を作らなければならなかったが、大きな開発リスクを避けたため問題なく展開できた
先生のスケジュール管理問題は予想通り問題が大きくなった
後ほど仕組みを整えることで解消
まとめ
Railsを何故入れたか！
それは...マンツーマンで利用しているフレームワークのメンテナンスが止まってしまい、入れ替えを検討していたからではありません。上記のようなビジネス上・リソース上・タイミング上の問題のバランス良い展開を考えての意思決定でした。当然いくつかのリスクも引き受けることになってはしまいますが、比較的影響を小さく抑えられたのかなと感じています。
リスク
上記の意思決定は何らリスクを含有していないのでしょうか？そんなことは無く、例えば以下のような部分では不利にはたらきます。
言語数が増えるのでエンジニアの確保の難易度が上がる
その後のチーム構成の難易度が上がる
将来的にIDを連携するとなると、大変になる
など
デメリットが有ることが悪いわけではなく、何をリスクとして許容するかを理解しておくことが重要です。楽しい意思決定を！
おわりに
以上、我々がRailsを導入したきっかけに関してご紹介いたしました。
少しでも興味を持っていただけましたら、ぜひ一度お話しましょう！
募集ポジションはこちらから！
・テックリード
・Reactエンジニア
・バックエンドエンジニア
採用情報はこちらから！
それではまた！