メダップ開発組織が今後注力する技術トピック
メダップでCTOをしている馬場と申します。
2021年8月31日にシリーズA調達完了のプレスリリースを出しました！
開発組織としては、ここからギアを上げてプロダクト・技術ともにより一層チャレンジングな環境になってくるかなと考えています。
技術領域でどういったチャレンジが待っているのかを言語化する意味も込めて、
(普段は、もう少し開発組織や開発プロセスに寄った話が多いのですが...)
今回は、メダップでいま採用している技術を踏まえて今後どういった技術トピックに注力していこうとしているのかをまとめてみました！
開発組織全体の戦略については、下記note御覧ください。
(※ 今回は、あくまで技術にフォーカスして話を進めます)
これまでの技術トピック
2021年1月から開発組織の内製化が始まり、技術トピックとしては下記3点に注力してやってきました。
- Rails App からのフロントエンドの切り離し(SPA-API構成への移行)
- TypeScript の導入
- Swagger & OpenAPI-generator を利用したSchema駆動開発の導入
■ 注力トピック3つの要約
もともと Rails を利用してシンプルな構成で作られていたforoCRMですが、内製化のタイミングと同時にView部分を Next.js + TypeScript を利用したアプリケーションとして切り離すことを決めました。
foroCRMは機能が非常に豊富であり、データ分析機能として多くのグラフを描画する, 地図に医療機関をマッピングするなどフロント側で厚めにロジックを書く機会が多くなる想定もできていたため、今回こうした決断に至りました。
TypeScript の導入に関しては、今後バックエンドの開発でもTypeScript(Node.js) を導入していくことを想定しており(後述あり)、フロントエンド側で先に慣れ親しむことができる状態を作っておこうという狙いも一部ありました。
こうしたフロントエンドの切り離し、TypeScript 導入の恩恵を最大限活用する仕組みとしてSchema駆動開発を取り入れられたことが、今回のフロントエンド移行を促進できた要因だったと考えています。
API仕様書を OpenAPI に沿って記述しており、swagger-ui でそれらを描画する仕組みを取り入れています。
また、OpenAPI-Generator を利用することで、swagger.yml から TypeScript のコードを自動生成する仕組みを構築しています。
更にバックエンド側では APIリクエストをテストする際に、この swagger.yml で定義されたスキーマ通りに値が返ってきているかを確認するようにしています。
この仕組みにそって開発をすすめることで、フロントエンド - バックエンド間で発生するAPI疎通を円滑に作ることができていると思います。
これから注力していく技術トピック
ここまでは、フロントエンドを切り離し TypeScript を導入していくこと
そして、その移行を促進する仕組みとしてSchema駆動開発を推し進めてきました。
フロントエンドの切り離しも一段落する目処が立っており、技術的な挑戦としては次のステップに入れそうかなと考えています。
現在、注力していきたいと考えている技術トピックは下記3点です。
- ドメインのリモデリング & バックエンドのアーキテクチャ移行
- Design System の作り込み
- TypeScript/Node.js を主要技術とした技術刷新
■ ドメインリモデリング & バックエンドのアーキテクチャ移行
これまでバックエンドでは内製化するタイミングで既に出来上がっていた Rails アプリケーションをAPI化する形で開発を進めてきました。
(このアプリケーションは、Model-Presenter(View)-Controller といった一般的なMVC構成で構築されています)
foroCRMが扱っている事業ドメインは、病院業界特化型ということもあり専門性も高く
また、CRMシステムということもあり扱うドメインが多岐にわたっています。
この先もプロダクトを開発し価値をデリバリし続けていくためには、foroCRMが扱っている専門的なドメインをソフトウェアとして上手く表現していくことが重要だと考えています。
そこでここから重要となってくるのは、下記2点です。
- ドメインをリモデリングし扱っているドメイン間の境界を明確に定義していくこと
- そのモデリングに沿った形でアーキテクチャを移行していくこと
アーキテクチャ移行に関しては、いきなりマイクロサービスのような構成に作り変えようということではなく、あくまで自分たちが整理したドメインモデルを適切に表現することが大切だと考えています。
マイクロサービスはあくまでもその表現手段の1つだと思うので、その他にもモジュール式のモノリス構成にするなど、ここからあらゆる選択肢を探索しながら検討していきます。
(Shopifyでは、moduler monolith という概念が出してました)
■ Design System の作り込み
切り離しが進んでいるフロントエンドに関しては、開発の型を作っていくことがテーマになってくると考えています。
現在も Atomic Design の考えに基づき、ある程度コンポーネント設計のルールを決めたり Design System として基底コンポーネントを作成するなどは進めているのですが、Next.js への移行もほぼ完了し、よく使うデザインのパターンも見えつつあります。
フロントエンドとしては、デザイナーと協調しながら、デザインルールに沿った Design System の構築を行っていくことで、よりスピード感を持って機能開発が実現できると考えています。
経営・事業戦略としてはここから複数のプロダクトの立ち上げも想定しているので、テーマを切り替えながら使い回すことができる Design System へと昇華できるかどうかがポイントになりそうです。
■ TypeScript/Node.js を主要技術とした技術刷新
現在は主にフロントエンドで TypeScript の導入を行っていますが、バックエンドに関しても TypeScript(Node.js) の導入を進めていきます。
サービスとは切り離すことができるジョブなどから取り入れつつ、徐々にドメインリモデリング・アーキテクチャ移行と合わせて TypeScript の導入に取り組みます。
TypeScript/Node.js を主要な技術として設定した背景には大きく下記3つの理由があります。
(正直、私の主観も大きいと思いますが... ある程度えいやで決断して軸を持つことが開発組織としては大切かなと思い、決断いたしました)
まず1つ目が、エンジニア採用ブランディングです。これは私自身の感覚的な問題でもあり賛否あると思うのですが
Web界隈で注目を集めつつあり、これからTypeScript を実践で使ってみたいと考えているエンジニアの方は増えてくるのではないかなと考えています。
2つ目の理由として、ドメインを表現する型システムの柔軟さがあります。
専門性も高く、複雑なドメインを扱うVerticalSaaS において、ドメインの表現性が高い言語が良いなと考えていました。他の選択肢として Scala などもいいなと考えていたんですが、他の検討要素との兼ね合いで、TypeScript を優先しました。
3つ目の理由として、フロント ~ バックまで統一した言語で開発ができることがあります。
もちろん、フロントエンドで採用している React の理解が必要ですし、バックエンドでもAPI・DB設計などその領域ならでは概念をキャッチアップする必要はあります。
その一方で、言語が統一されていることで挑戦しやすい環境になるとも思いますし、何よりフロント ~ バックの垣根を超えた交流がしやすいと考えています。
Dart も選択肢には上がるかなと思うのですが、他の検討要素も考慮して TypeScript を優先しました。
まとめ
これまで注力してきた技術トピックの要約とここからビジネスを加速させるために注力していく想定の技術トピックについてまとめてみました！
いずれのトピックもメダップの成長を見据えて、その成長を支えるために必要なことだと考えています。
開発メンバーで定期的にこうした視点で常に何をやるべきか？をディスカッションする場を設けるなど、チーム一丸となって技術そして会社・事業の成長に向き合っている開発組織です。
もし少しでもご興味お持ちいただけるようでしたら、最寄りの馬場までDMください！！！(副業からの参加もOKです！)
(弊社採用ページもぜひご覧ください！)