「3年に1回の法改正」にシステムをどう対応させる？LITALICOの事例に見る、事業特性に合わせた設計のヒント

LITALICOグループでは、障害福祉・教育・介護領域で300拠点以上の事業所を運営し、主に発達障害のある児童への教育や、働くことに障害のある大人への就労支援などを行っています。また、そうして培われた支援や事業所運営のノウハウをもとに、当事者やご家族や福祉従事者向けのWebサービス、福祉事業所や学校向けのSaaSなどの数多くのプロダクトを提供しています。

こうした数々のサービスの可用性や信頼性を高く保ち、かつ開発生産性も向上させるには、適切なアーキテクチャ設計が必要不可欠です。これまで、LITALICOではどのような技術的意思決定をしてきたのでしょうか。今回は同社の執行役員CTO/エンジニアリング統括部長である市橋佑弥さんにインタビューしました。

目的を達成するための技術選定

――最初に、LITALICOの開発組織において技術選定で大事にしている考え方をお伺いしたいです。

私たちは多種多様なプロダクトを運営しているため、それを前提とした技術選定が必要になります。具体的には、各プロダクトの特性に合わせた技術戦略を、プロダクトチームのリードをしているエンジニアに立ててもらうケースが多いです。そのリードエンジニアには大きな裁量を渡して、それぞれのプロダクトにおけるCTOのような役割を担ってもらっています。

私たちの技術選定において共通しているのは、あくまで「目的を達成するための技術選定」であるということです。企業やプロダクトの大きなビジョンがまずあり、ユーザーに届けたい価値や解決したい課題がその下にあります。技術はそういった目的を実現していくための手段だと捉えています。一方で、技術の本質を見極めなければ適切な判断はできないため、技術が好きなエンジニアが多いのもLITALICOの開発組織の特徴です。

他に技術選定に影響を与える要素としては、障害者総合支援法の改正が挙げられます。これは障害のある方への支援を定めた法律なのですが、3年ごとに法改正が行われます。この改正では、障害福祉サービスを運営する上でのルールや給付費の報酬体系などの変更があります。そのため、プロダクトのロジックもそれに合わせて変えていく必要があるんです。

――LITALICOで用いている技術スタックについても知りたいです。

複数のプロダクトがあるため扱っている技術の差はありますが、基本的にはインフラはAWSを用いており、Amazon ECS on AWS Fargateを採用しています。

SaaS系プロダクトを例にすると、フロントエンドはVue+Nuxt.jsでSPAの設計になっているシステムが多いです。バックエンドは主にPHPとLaravelで作っていますが、部分的にGoやJavaを採用しています。たとえば、パフォーマンスが求められる箇所はGoを、帳票出力の処理でJavaを採用するなどですね。その他、toC向けのWebサービスではRuby on RailsやReact.jsなどを採用しています。

また、SaaS系プロダクトでは扱う業務ロジックも複雑かつ量が多いため、DDD（ドメイン駆動設計）を設計に取り入れてサービスを分割しています。関心事によってシステムを分離しているため、マイクロサービスというよりはもう少し粒度の大きい分割の仕方です。1つのプロダクトごとに、20〜30くらいの小さなサービス群から構成しています。DDDを導入した経緯については、この後に話します。

DDDを導入。そして法令単位でシステムを分割

――ここからは、過去に取り組んできた技術的な意思決定の事例を伺います。

まず、先ほど述べた法改正に関するアーキテクチャ設計の事例をお話しします。障害者総合支援法では、レセプト（給付費計算）の不備があった際などに過去のデータを最大で5年分さかのぼって参照するケースがあるため、過去の法令用のロジックもプロダクトにそのまま残しておかなければなりません。私がLITALICOに入社したのは7年ほど前だったのですが、当時は「どの法令を用いて処理を行うか」を、プロダクトのコードの中にたくさんの条件分岐を書くことで判定していました。しかし、この実装方法にはいくつもの課題があります。

法改正のたびに条件分岐が増えていくため、徐々に複雑性が増します。既存のコードに手を入れることになるので、改正後の法令のテストだけではなく改正前の法令のテストもすべて実施する必要が生じます。

そこで対応策として、設計手法としてDDDを取り入れサービス分割をした上で、障害者総合支援法における給付費計算を担うような部分を、法令の年度ごとにリポジトリを分けて別々のアプリケーションとしてデプロイする方針を選びました。そして、リクエストの内容に応じてALBで適切なアプリケーションに振り分けています。

――アプリケーションではなく、インフラで分岐させたということですね。

はい。これによって新しい法令に対応する際に、古い法令の側のアプリケーションには一切手を入れずに済みます。古い法令の側のロジックが壊れないことを保証できますし、テストにかかる工数もまるまる削れるんです。そして、アプリケーション内には法改正に起因した条件分岐が入り込まないので、実装がシンプルになります。

――この事例を踏まえて、読者に伝えたいことはありますか？

私はこれまでのキャリアでアプリケーションからインフラまでさまざまな領域のエンジニアリングに携わってきたため、この事例で「ALBで振り分ければよい」というアイデアが浮かびました。

もし、設計をするエンジニアがアプリケーションのことしか考えていなければ、こうした分岐をアプリケーションで実装する案しか浮かばなくなってしまいます。だからこそ、インフラやデータベース、アプリケーションといった幅広い技術領域に触れておくことをおすすめしたいです。

開発にドメイン知識が必要なロジックを共通基盤化する

――3年ごとの法改正に対応したシステム改修について、今後さらに改善したい点はありますか？

各種の障害福祉サービスでは、給付費計算を行ったうえで国民健康保険団体連合会を通じて自治体に請求処理をかけるような業務が発生します。LITALICOはそういった業務で扱えるようなシステムをSaaSや社内システムなどでたくさん持っているんですね。

そして、そうした計算処理や帳票作成の処理などは、各システムで処理内容が共通する部分や似通っている部分がたくさんあります。そこで、そのコアロジック部分を切り出した共通基盤を作り、各プロダクトからその共通基盤を呼び出すようなアーキテクチャを構築しています。この移行作業を、今まさに進行中です。

――基盤構築の意図や利点などを知りたいです。

この共通基盤のコンセプトは、プロダクト間でデータを共有したいというようなことではなくて、法令の専門知識が必要な部分の処理をいかにして局所化するかにあります。これは技術戦略でもありますし、組織戦略でもあるんですよ。

LITALICOでSaaS系プロダクトに関わるエンジニアの多くは、障害者総合支援法についての知識が求められます。しかし、みんながこの法令の深い知識を持っていなければプロダクト開発ができないという状況では、プロジェクトに支障が出てしまいます。もちろん、ある程度の知識はみんな持っておくことが必要ですが、法令以外にも必要なドメイン知識は色々あります。

そこで、特に深い法令知識が必要な箇所を共通基盤に局所化することを目指しています。要するに、共通基盤の開発に携わるメンバーだけが法令の複雑な部分を正確に理解すればよいという状態にするということですね。先ほど述べたように障害者総合支援法は3年おきに改正されますし、新しい法令が発表されてからシステムをそれに対応させるまでは時間が限られているため短期決戦になります。それもあり、こうした方針を採用していますね。

――この事例を踏まえて、読者に伝えたいことはあるでしょうか？

世の中にある設計のプラクティスや開発手法などは、先人たちの実践や経験からエッセンスを抽象化して汎用化されているものです。それらを学ぶことは前提として、原理主義的に「こうでなければならない」と考えるのではなく、「自社に最適な状態で反映させるには何が必要だろう」と考えていく必要があります。

たとえば私たちの事例では3年おきに法改正のための対応を行うという状況において、フォーカスすべき課題は何か、その課題を取り除くには何をするべきかなどを考える必要があります。だからこそ、技術のことだけではなくそのプロダクトや事業ドメインのことを知らなければ、適切な設計はできません。

Electronを用いた現代的なデスクトップアプリ開発

――他の事例についてもお話しください。

私たちは2年ほど前から、公立の小中学校向けの事業を開始しました。主には、その学校の特別支援教育において、障害のある子どもたちのための支援や教育を支える事業です。その先生たちが使うための、パソコンで動くデスクトップアプリを開発したのですが、その事例についてお話しさせてください。

――Webアプリではなく、デスクトップアプリなのですね。

このプロダクトでは、児童・生徒の要配慮個人情報などを扱います。そのため、小中学校では、クローズドなネットワーク内で情報を扱いたいニーズが強いです。そうした情報もクラウドで扱っていく動きはあるのですが、まだまだ時間もかかるでしょうし、現状では自治体も導入しづらい状況です。

今は、特に若いエンジニアはWebアプリの開発経験はあるもののデスクトップアプリの開発経験がない方がほとんどです。そこで、HTMLとCSS、JavaScriptといったWebアプリの技術を用いてデスクトップアプリを作れるElectronというフレームワークを使いました。

また、スタンドアローンで動くシステムは、そのサポートにかかるコストをなるべく減らさなければなりません。Webアプリのようにサーバー側にログなどが残らないため、サポートでのトラブルシューティングの難易度が非常に高いからです。そのため、開発においてなるべくハードウェアやOS、ブラウザへの依存度を減らす必要があります。Electronにはブラウザのエンジンとかも内蔵されているため、環境にあまり依存せずにアプリが動作します。

この事例においては、ポイントは開発の持続可能性ですよね。社内にどのようなスキルの人たちがいるか、将来的にも開発体制を維持しやすいか。そして、サポートにかかる工数なども考慮して、技術選定を行ったのが重要だと思っています。

今回はせっかくなので、この技術選定における振り返りのポイントもお話しますね。将来的には、このプロダクトをWebアプリとして提供したいと思っています。そのときのために、Electronで開発したアプリの中に擬似的にフロントエンドとバックエンドがあるような設計にしたんです。SPAのような設計にして、のちのちクラウドに移行する際にそのままフロントエンドとバックエンドに変換することを目指していました。

でも、もしもこのプロジェクトをやり直せるならば、その構造にはしないかもしれません。その設計方針にしたことで、Electronが想定しているオーソドックスな設計のパターンからは外れてしまいました。そのため、開発において意図せぬ動作が起きたり、その調査が難しかったりという課題が生じてしまったんです。この事例においては、将来のことを考え過ぎた選択をしたかもしれません。

――この事例を踏まえて、読者に伝えたいことはあるでしょうか？

今回の事例では、擬似的にフロントエンドとバックエンドがあるような設計にすることの利点を享受できるのは数年先で、でもシステムの複雑性と戦うのは今という状態です。新規事業というのはビジネスの行く先がわからないにもかかわらず、今のリターンを捨てて将来的なリターンを取り過ぎたかもしれません。

一見するときれいなプランなんですけれど、理想像を見過ぎていました。今回のような新規事業においては今後ビジネスがどう変化するのかわからないので、あまり先のことを想定し過ぎるよりも、必要になったらその都度対応する考え方のほうがうまくいくことも多いです。技術レベルが上がるほど、「いろいろなケースを考慮してシステムを作り込み過ぎる」ということに気をつける必要がありますね。

プロダクト間のデータ連携を行い、サービスの質を向上させる

――LITALICOの開発組織における今後の目標を教えてください。

引き続き、新規事業や新規プロダクトの数も増える見込みのため、組織力や開発プロセスを磨いていきます。さらにビジョナリーな話をすると、「障害のない社会をつくる」というビジョンを実現するには、何か1つの困難さを解消するだけでは不十分です。人間の生活のいろいろな場面やさまざまなライフステージの困難さを解消するために、事業を多角化していく必要があります。

現在は、各プロダクトや学校・施設などで、扱っているデータがそれぞれ独立しています。これを、たとえばユーザーのIDを統合して、IDをキーにして横断的にデータを扱えるとか、別々のプロダクト間で相互にデータ連携できるというような施策を推進していきたいです。これによって、ユーザーへの提供価値は飛躍的に高まると考えています。

実際、すでに私を含む一部のメンバーで、システムの設計方針やアーキテクチャのグランドデザインなどを検討して、技術検証やプロトタイプ開発といったことに手をつけています。

――事業のさらなる飛躍が楽しみですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

どれほど長くエンジニアを続けても、一人の人間が経験できることには限界がありますよね。でも、世の中にはたくさんの優れたエンジニアがいて、その人たちが自らの経験や学びを発信してくれているわけですから、それを学ばないのはナンセンスだと思います。

それに、自分がエンジニアとして成長していく過程では、より責任の重い仕事や裁量の大きい仕事に携わる機会に必ず遭遇します。その業務において、これまで経験したことがないようなチャレンジをすると思うんですが、その課題に対して手ぶらで挑むのか、先人の知恵を学んでヒントを自分の頭の引き出しに入れて挑むのかでは、結果がだいぶ違うはずです。エンジニアリングに限らず、歴史を学んでより良い状態で未来に引き継いでいくことは、人類として大切なことだと思います。

ただ、書籍やWebの記事などで学んだことを、うのみにするのはおすすめしません。普段の業務の中で、学んだことを活かして小さな意思決定をくり返してみるとか、他のメンバーとの議論に参加してみるなどして、「覚えた知識」を「活用できる知識」にしていくことが重要になります。

私が若い頃によくやっていたのは、たとえばプログラミング言語やフレームワークに触れているときに「こういう仕様なんだな」と思うだけではなくて「どうして開発者はこういう仕様にしたのだろう」とか「私だったらこうする」といったことを考えながら使ってみる。そういった習慣が、エンジニアとしてのスキルを向上させるための良いトレーニングになると思います。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul