見出し画像

新規事業の立ち上げにおける、技術意思決定の振り返り ~ mikan for Schoolの場合 ~

mikan Advent Calendar 22日目の記事です!
昨日の記事はmaruちゃんがmikanの総会について書いてくれてました。
社員数名の時は、ただの飲み会だったのが、持ち回りで運営するようになって、徐々にコンテンツが進化してきてスゴイです。
普段がフルリモート体制な分、みんなで集まる機会は引き続き大事にしていきたいですね!

mikanの代表をやっております、髙岡 (@takaokazumasa) です。
娘が2歳半になり、スクスクと元気に大きくなってます。サンタクロースの服が気に入ったみたいで、ほぼ毎日娘がサンタの服を着て、家の中で踊ってます。クリスマス過ぎてからも、ウチにはサンタが居座ることになるかもしれないです。

この記事のまとめ

  • 特に、立ち上げの技術意思決定は「事業」が変数として大きくなる

  • mikan for Schoolの立ち上げの場合、良かったのは「意思決定を先送りしたこと」、やり直したいのは「データをどこに置くか」「共通化と分離を判断する優先順位の判断」

  • 事業解像度を高く持って、技術意思決定を一緒にやってくれる方、助けてください、探してます

mikan for Schoolを新規事業として立ち上げてます

英語学習アプリmikanは2014年10月リリースから10年目を迎えて、750万ダウンロードを突破してます。
そして、mikanでは新規事業として、教育機関向けの「mikan for School」を2022年4月にサービスリリースして、toCだけでなく、学校・学習塾で英語学習アプリmikanを活用いただいております。立ち上げから2年弱ほど経過して、ありがたいことに現在で全国250校舎ほどで利用いただいております。

https://speakerdeck.com/mikan_inc/techstack?slide=6

まだまだ立ち上げフェイズですが、2年前の0校舎と比べると状況が変わってきているので、今日はプロダクトに関する技術意思決定を振り返って、少しでも学びを抽出できればと思ってます。
(ターゲットセグメントや注力する課題などなど、ビジネス上の意思決定も当然たくさんあったので、こちらも機会あれば書きます。)

大前提、事業フェイズやプロダクト特性、組織構成などなどによって、技術意思決定は大きく変化します。そのため、あくまでmikan for Schoolのケースにおいての振り返りになります。
技術意思決定は、めちゃめちゃケースバイケースになるので、それが面白さであり、難しさですね。
また、振り返る過程で、当時の私自身の失敗や未熟さにぶち当たって、恥ずかしいところも多いのですが、リアルな振り返りにするためにそのまま書き下してますので、一般的には学びとして弱いところあるかと思いますが、ご了承ください。

3つの技術意思決定の振り返り

では、立ち上げからの、3つの技術意思決定を振り返っていきます。

まずは概観として、顧客数0・売上0の時に構築したシステム構成図はこちら。

mikan for Schoolに関連するところのみを抜粋。現在の構成図も後半に掲載。

事業機会を得ながら、技術意思決定を先送りするための、技術意思決定

振り返りたい、1つ目の技術意思決定は、2018年に作ってあった、mikan for Schoolのプロトタイプのシステムをそのまま流用して、初期リリースを実現させていったことです。
いきなり、「どういうことやねん!」という話ですが、本当の話です。

mikanでは、学校・学習塾向けには、何度か事業立ち上げをトライして、社内の状況などから、ストップをすることをやってきていました。そして、2021年の秋に、学校・学習塾の両方から問い合わせが入ったことと、私自身が育休明けでtoC事業のボールを渡し切っていたことから、再度立ち上げていくことになります。
その際に、今回のリード顧客も想定しつつスクラッチしていくか、以前作ったプロトタイプを流用するかを判断することになり、後者を選択しました。

この決断は、2年経った今振り返っても、同じ決断をするかなと思ってます。
この意思決定をした理由はは、大きく2つあります。

1つは、事業機会を得るためには、すぐに提供を開始できることが必須だったことです。学校や学習塾は、年度単位で運営がなされているため、決裁タイミングが基本年に1回しかなく、また、システム活用のPDCAまで考えると、導入から少なくとも2-3年は運用していくことになります。そのため、問い合わせがあったタイミングを逃すと、その顧客への導入は2-3年難しいということになります。

もう1つは、システムを設計に必要な情報が増えている状態では無かったため、再設計タイミングを先送りしたかったことです。ドメインの再設計などをスクラッチでやっても、事業フェイズが進む中で、また再設計するタイミングがすぐにやってくる可能性が高いと想定していたため、商談で期待値やオペレーションを調整して、流用できる形でスタートを切ることができました。

2年経過した現在では、顧客数も増えて情報も増えたので、今後どのように再設計を進めていくか、は重要な技術issueとして積まれています。

データをどこに置くか(当然大事)

振り返りたい、2つ目の技術意思決定は、初期顧客のMUST要件で必要になった、「小テストを配布する機能」のデータストアをFirestoreで構築していったことです。
生徒が学習するWebフロントがReact、先生が配信設定や結果を閲覧する管理画面がRails、小テストを保存するのをFirestoreとなってます。

この決断は、今振り返ってみると、違うデータストアにすれば良かったと思ってます。
当然ケースバイケースなんですが、管理画面でさまざまな集計を実施するときに、集約関数が無いことが圧倒的にネックとなって、工数や読み込み速度に無視できない影響が出てきてしまっています。それを上回るメリットをFirestoreから得ていれば良いのですが、当時の決定の背景も、Firestoreに慣れていて、フロントからRead/Writeできて工数圧縮できる、という観点からのみだったので、リアルタイム通信やオフライン対応などの強みは特に活きていない状態です。
そして、データを移すのも、関連箇所の変更からKVSのようなFirestoreのスキーマをRDBへマイグレーションするなど、影響箇所も懸念事項も大きくなってしまって、工数が巨大になってしまってます。

戻ってやり直すなら、FirestoreをRDB + APIの構成にして、管理画面側でさまざまな軸で集約したい話が出てきても、非正規化した形のスキーマ設計や大量のドキュメントリード無しに、対応できる設計にしたいと思ってます。

ココは、RDBへ近いうちに実際に移したいなと思っていますが、そもそもその是非や、いざ移行する時の構成などなどは、社内の今後の重要な議論ポイントになってます。

共通化と分離

振り返りたい、3つ目の技術意思決定は、to Cアプリとスクール向けのアプリを切り分けずに、共通化して、初期リリースしていったことです。

mikan for Schoolのユーザーには、大きく分けて、生徒と先生がいます。そして、生徒はto Cのユーザーと同様に、英語学習に取り組みつつ、先生から配信されてくるテストや宿題に解いたりしています。そのため、自分で英語学習に取り組む部分は、to Cとスクールで差分が無いので、アプリは共通にして、スクール向けのログインと先生からの配信内容へアクセルできる動線を追加する構成にしました。

これは今振り返っても、どうするべきだったのか、かなり迷うポイントだなと思ってます。
ただ、当時と現在では、共通化するか、分離するか、についての考えは変わっています。

当時は、共通化しておくと、to Cの改善がそのままスクール向けにも自動展開されてくるから、機能差分も少ないし、メリットが大きいので、基本はずっと共通化したままだろう、と考えていました。
しかし、MDM(Mobile Device Management)のシステムを利用している学校・学習塾に対しては、モバイルアプリは圧倒的に相性が悪いことに加えて、to Cとfor Schoolのプロダクト改善サイクルや注力ポイントが全く異なっていたこと、徐々に分岐が増えて工数もQAケースも増大していったことから、現時点の機能が同じでもユースケースが異なる場合には、分離が基本と考えるようになりました。
そのため、最初期は工数観点から共通化していても、分離に向けた動きはもっともっと早くから動かしておくべきだったと思ってます。

現在は、分離に向けてプロジェクトが動いている状況です。分離が完了してからも、特にto Cアプリで改善した内容をどのように、どのタイミングで取り込んでいくのか、などは、継続的に判断していく必要があるポイントになっていく想定をしています。

3つの意思決定を振り返ってみて

初期リリースから、2年弱経過した現在のシステム構成図(方向性を含む)はこちらです。

mikan for Schoolに関するところのみを抜粋。

今回振り返ってみて、技術意思決定は、事業の現在・未来とプロダクトの現在・未来を結びつけてしていくものだと、改めて痛感してました。
mikan for Schoolでは、この2年で事業が変化する中で、プロトタイプはまだ基盤になっているけども、Firestoreは移行する方針だし、生徒側はto Cとは分離させてWEBで統一した対応にしていくことになってきています。

唯一解は存在しないことがほとんどではあるけども、複利的に効いてくる意思決定であることも多いので、より幅広い観点から検討できるように、私としてはドンドン任せつつ、一緒に議論できるチームを作っていきたいと思ってます。

最後に

mikan for Schoolでは、事業部としては1人目エンジニアのポジションを募集してます!幅広く技術意思決定も担いつつ、事業を一緒に立ち上げていけるポジションになるかなと思います!

また、今回は、mikan for Schoolのプロダクトにまつわる話でしたが、mikan全体でも採用強化してます!
そのほかのポジションでも、カジュアルに話しましょう!

お気軽に、ご連絡ください!


いいなと思ったら応援しよう!

この記事が参加している募集