CodeZine(コードジン)

特集ページ一覧

アーキテクチャを『事業・チーム・スピード』バランス良く設計するには? ユニファのバックエンド分割に学ぶ

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 技術選定、意思決定、評価検証……普段あなたの会社では誰がどのように行っていますか? ビジネスの急成長を支えるシステムを構築する必要があるスタートアップ企業では、どのような課題があり、どのような検討過程を経て、どのような技術選定が行われているのでしょうか。本連載では、必ずしも華々しくキラキラした選択肢ではなく、ときには泥臭い現実に向き合って地に足のついた意思決定を行っている事例をスタートアップ企業各社に伺います。 第1回は、ユニファ株式会社 取締役 CTO 赤沼 寛明氏に、複数サービスの分割・共通化の判断をした事例を伺います。記事の最後には、SAによるポイント解説もあります。(編集部)

目次

はじめに

 こんにちは、ユニファ株式会社取締役 CTO の赤沼 寛明です。

 2015年に一人目の正社員エンジニアとしてユニファに入社し、当初は開発に注力しながら採用なども進めてきました。気持ちとしてはずっと技術的なところをやっていたいのですが、今では開発メンバーが50名ぐらいになり、会社全体としても組織が大きくなってきたこともあり、直接的な開発業務はメンバーに任せて私は採用や組織面に主に注力しています。

 今回は「あえてこの選択しています」ということで、弊社が2021年7月に発表した新「ルクミー」シリーズのうち5サービスについて、バックエンドをどう分割・共有したか、その判断の過程をお話します。少しでも複数サービスの持ち方、考え方の参考になれば幸いです。

新規サービスの設計に向けた検討材料

 ユニファは「スマート保育園・スマート幼稚園・スマートこども園」構想を掲げて、保育施設向け総合ICTサービス「ルクミー」を提供しています。現在の日本において、保育士不足や保育現場の長時間労働や高負荷業務は深刻な社会課題です。ルクミーは、ICTを活用して保育施設の保育現場業務の負担削減と、保育の質の向上を目指しています。

 今回のリニューアルで新たに設計したサービスとして、「ルクミークラスボード」「ルクミー連絡帳」「ルクミーおたより」「ルクミー帳票管理」「ルクミー登降園」があります。これらのアーキテクチャを考えるにあたって、主に以下のような検討材料がありました。

  • クライアントは保育者向け、保護者向けなど複数のモバイルアプリからアクセスしてくる
  • ユーザー・クライアント認証は全サービスで共通のロジックが必要
  • ビジネスロジックはサービスごとに全く異なる
  • サービスは今後も増えていく見込みがある
  • データはサービス間で共通に使うものが多いが、登降園サービスは比較的データの独立性が高い(完全に独立ではない)
  • 各サービスでアクセス特性が異なるが、特に登降園サービスは朝と夕方の登降園時間帯に激しいスパイクがある(日本全国、一斉に園児が登園・降園する時間帯がある)
  • 特にそのスパイクは導入先の保育施設数に応じて大きくなっていく
  • 既存プロダクトの延べ導入数は1万以上であり、これらのユーザーが順次流入してくる
  • 上記の業界固有のアクセス特性やユーザー数増加に対しても高い安定性が求められる

 また、開発開始当時、以下のようなチーム体制でこのサービスのサーバーサイドのアーキテクチャ設計を進めました。

  • エンジニアリングマネージャー2人
  • サーバーサイドエンジニア4人
  • インフラエンジニア2人
  • プロダクトマネージャー1人
  • CTO(私)

今後の事業展開も考えた、バランスの良いアーキテクチャを探る

 クライアントサイドはスーパーアプリとして一つのUXを提供しつつ、バックエンドのサービスをどう分けるべきか(あるいは分けないか)が正解のない論点でした。今後のサービス・事業展開を考えたスケーラビリティ、保守性、設計のシンプルさ、そして開発のスピードのバランスを取るために最適なアーキテクチャは何かを検討しました。

 まず、「クライアントは保育者向け、保護者向けなど複数のモバイルアプリからアクセスしてくる」「ユーザー・クライアント認証は全サービスで共通のロジックが必要」という点は、全てのサービスにおいて共通の要件となるため、ICTフロントエンドサービスとしてゲートウェイ的に前面に立てることにしました。そもそも切り出す必要があるのか、そのバックエンドと分ける必要があるのかなどの議論もありましたが、モバイルアプリの開発を考えてもアクセス先は統一されていたほうが良い、認証は一手に受けておいてバックエンドの各サービスには意識させないほうが良いなどの理由から切り出すことにしました。

 ここでは、スケーラブルでありながら運用負荷の少ないサーバーレスなサービスとして Amazon API GatewayAWS Lambdaを使いました。

 より検討が必要だったのはそのバックエンドです。最初にインフラエンジニア主導でいくつかの案を出してもらい、他のメンバーを交えて議論しました。

  • 案1:各サービスを個別に分けて作る。データベースもサービスごとに持つ
  • 案2:全部をひとまとめにする。データベースは一つだけ
  • 案3:園児の活動系、保護者連絡系、その他で分ける
  • 案4:登降園、保護者連絡系、その他で分ける
  • 案5:登降園、その他で分ける

 このとき「マイクロサービスとして正しく作る」ことを意識したわけではなく、あくまでもプロダクトの特性と自チームの体制、開発期間的な制約などから考えて、ビジネス上の成果を上げるための合理的な判断をすることに徹しました。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 赤沼 寛明(ユニファ株式会社)(アカヌマ ヒロアキ)

     エムスリーやNubee Tokyoでの開発業務を経て、2015年にユニファ東京オフィスの立ち上げ時に入社。ユニファの開発体制を構築し、様々な新規サービスの立ち上げにも関与。現在はCTOとして、機械学習・深層学習をメインとした研究開発チームを含むシステム開発チームを統括。また、外国人エンジニアも積極...

  • 塚田 朗弘(アマゾン ウェブ サービス ジャパン株式会社)(ツカダ アキヒロ)

     アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト。  2011年から生放送系ウェブサービスの開発を経験した後、2013年よりスタートアップ企業にJoin。CTOとしてモバイルアプリ、サーバサイド、AWS上のインフラ管理を担当しつつ、採用やチームマネジメントを行う。2015...

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5