サービスの成長を支える商品データモデリングの更新記録

サービスは成長にともない扱う商品の種類が増えていくことがあります。さらに、最初のシステム設計時の想定を超えるような種類の商品を取り扱う必要が出てくることもしばしばです。

今回の話では、誰でも成績がトップクラスになると評判の算数・数学専門の家庭教師が、元教え子達と協力してオンライン家庭教師サービス事業としてやっていくことになります。

システム開発の経験が豊富ではないチームですが、データモデリングを通してビジネス側と開発側で協力しながらシステム設計を行い、サービスを成長させていく様子が楽しんでいただけたらと思います。

はじめての開発ミーティング

アルバイトMの高校の同級生で、スタートアップでシステム開発の経験のある開発者Yが初めてのミーティングにやってきてくれました。

開発者Y:
「早速ですが、今考えているシステム概要ってどんな感じでしょうか。」

家庭教師A:
「私と元教え子のアルバイトのシフトを管理して、インターネットで予約できるようにしたいです。」

アルバイトM:
「普通の家庭教師サービスと違って、必要なときの一週間前に電話で予約してもらっていたんだ。家庭教師Aさんが自らスケジュール帳でアルバイトも含めて管理してくれていたんだけど、人数も増えてきたので１人で管理するのが難しくなってしまったんだ。」

開発者Y:
「ということは、これまでの家庭教師Aさんが行っていたことをそのままシステムにする感じですね。UIはこんな感じになりそうですね。」

開発者Y:
「そして、データの構造はこんな感じになりそうです。」

アルバイトM:
「このデータ構造の図がよくわからないんだけど。」

開発者Y:
「そうだよね。これはER図っていって、データのグループをエンティティと言って、エンティティの型とつながり方がわかる図ですね。UIの注文画面の具体的なデータはこんな感じなります。」

アルバイトM:
「端に3本にわかれているものは教師も生徒が注文の中で複数使われるし、十字架になっているところは注文からは教師も生徒も１つずつしかないってことかな？」

開発者Y:
「すごい飲み込みがはやいな！そのとおりだよ。」

家庭教師A:
「注文画面では、1回に１つの注文ができて、管理画面では教師の一覧と教師のスケジュールが◯と✕で管理できるということですね？」

開発者Y:
「まさしくその通りです！最初のお話だとこんな感じかなと思ったのですが。」

家庭教師A:
「管理画面は、こんな感じで大丈夫ですね。ただ注文が電話だと一度に複数の予定をお聞きしていたのでそこをなんとかしてほしいですね。」

開発者Y:
「確かに、テスト期間前だと集中して教えてほしいですから複数枠を取りたいですよね。」

アルバイトM:
「ER図を見ると１つの注文に複数の注文明細があるってことで、UIの複数の日付とかが指定できるのと一致しているんだね。」

開発者Y:
「そうそう。もう少し詳しくいうと担当教師は、スケジュールから空いている教師を割り当てるようにシステム自動設定するようにしています。」

家庭教師A:
「担当教師は私が選んでいたんですが自動だと楽でいいですね。アルバイトのみんなは私のやり方をよくわかっていて安心してまかせているので、ほとんど変わりないです。」

開発者Y:
「ありがとうございます。ではこれで開発進めていきますね！」

家庭教師A・アルバイトM:
「お願いします！」

ECサイト化

3カ月後、開発者Yの頑張りによりサービスは完成し順調に動いていた。家庭教師Aも現在のシステムのおかげで多くの生徒に数学を教えることができて満足だった。

サービスの認知が進むにつれてあるリクエストも増えてきた。それはオリジナルのテキストの販売をしてほしいとのことだった。

そこで、今のサービスにさらにテキスト販売機能を追加できないかを検討することになった。

アルバイトM:
「今まで順調にサービスが成長してきているんだけど、家庭教師としていけない地域の人たちからオリジナルのテキストをだしてほしいって要望がたくさんあるんだよ。どうにかできないかな？」

開発者Y:
「それぐらいならすぐにできそう。こんな感じのデータ構造にしたらいけると思う。」

アルバイトM:
「注文明細のテキストIDと冊数があるときと無いときで種類が分けられるということだね。」

家庭教師A:
「このときの具体的なデータってこの前みたいな表にするとどんな感じになりますか？」

アルバイトM:
「テキストの注文のときは隙間が多いデータになるんだね。」

家庭教師A:
「ちょっと欲張って授業動画の販売の機能を増やすというのもこんな感じで注文明細のデータに動画用のデータを増やすことになりますか？」

開発者Y:
「それでもできるんですが、それだとこの注文明細データの空白がもっと増えますし、なんとなくよくなさそうなんですよね。」

アルバイトM:
「無駄なところが多そうでスッキリしないね。最初の時に注文に複数の注文明細をつくって１つの注文から分けたときみたいなことってできないかな？販売の種類によってデータを分けるみたいなこと。」

開発者Y:
「なるほど、ちょっと考えてみるよ。」

開発者Y:
「注文の種類でデータを分けて見たんだ。これだと授業動画だけじゃなくて、マスコット人形とかも販売していけるようになると思うんだ。」

アルバイトM:
「分けると隙間の無いデータになりそうで良さそうに見えるけど、だいぶ注文明細のデータが変わっちゃってるね。いままでのデータはどうするの？」

開発者Y:
「そこが実際にはどうしたら良いのかわかっていないんだ・・・」

家庭教師A:
「２回にわけておくのはどうですか？今回の新規２種類のエンティティにもデータを保存して、元の注文明細エンティティに注文種類を加えてこっちにもデータを入れておくようなことですね。そして、うまく新規2種類のエンティティにデータが貯まるようになって古いデータも移行できたら注文明細のデータの種類を提案してもらっている形にするという感じです。」

開発者Y:
「一度、こういう形で様子を見てみるんですね？」

家庭教師A:
「そうです！これは重複したデータが多いのでやっぱりよくないのでしょうか？」

開発者Y:
「一時的なものですし、大丈夫だと思います！それにサービスも止めなくてもよさそうなところもいいですね。」

アルバイトM:
「じゃ、決まりだね！これでオリジナルテキストを通じて算数・数学を楽しんでもらえるといいな！」

開発者Y:
「ただ、今回は、やっぱりサービスのメンテナンスとして止めて、一気にデータ移行もやってもいいですか？こういうデータの移行が初めてなので不安というか、確認しながらデータを移行したいんです。」

家庭教師A:
「なるほど、それなら、全然サービスを止めてもらって結構ですよ。サービスの成長を支えてもらって助かってます。」

開発者Y:
「ありがとうございます！では、移行計画もきまったので準備ができたらお知らせしますね。」

家庭教師A・アルバイトM:
「お願いします！」

おわりに

サービスの成長はどういう方向に進んでいくのかわからないものですね。今回は算数・数学専門でしたが、英語や国語もできるアルバイトの方が増えたり、地元から離れた場所の大学にいってそこで家庭教師としてできたら、もっと違う機能が必要になったりします。

予測が難しい時に、今回のように、ちょっと出来過ぎなアルバイトM君のちょっとスッキリしない感じや、いろんなデータが混在していると気づいたときには、しっかりとエンティティをわける努力を怠らないことがサービスの成長を止めにくくする大事な技術の1つです。

今回のようにUIだけでなく、データモデリングを理解し、システムが扱っているデータがわかれば、無理難題で困らせたり簡単だと思っていたものが意外に難しい修正になったりすることがわかるようになります。そうなれば、開発を通じてより良いサービスづくりができるようになります。