この記事は『LITALICO Advent Calendar 2023』のカレンダー1最終日の記事です。
プライベートでは、妻にもらった紅茶のアドベントカレンダーを楽しんでいる(ほんとに毎日違う紅茶が出てくる！)LITALICO CTOの@yuyaichihashiです。
今年もLITALICOでは、エンジニアだけでなく、デザイナーやPdMのみなさん含めバラエティ豊かでカラフルなアドベントカレンダーになりました。
ぜひ、他の記事も読んでみてください！
どんな記事か？
タイトルに技術戦略とは入れたものの、業態や事業ドメインなどを踏まえて、LITALICOにおけるエンジニア組織の取り組みやあり方をどのように考えているか、手短に書いてみたものです。
具体的な技術戦略というより、前提の考えのようなものです。
一部、いくらか具体性のある話も出てきます。
技術戦略という言葉が使われている時に、それが何を指しているかやどういう範囲での話かは様々ですが、たとえば、 LITALICOのように多数のプロダクトがある中でのエンジニアリソースの投資配分については、VPoEのこちらの記事に書かれています。
マトリクス型のIT組織(250名)かつ多様な事業がある企業でIT投資戦略を策定する10のステップ
LITALICOでは、個々のサービスにおける事業戦略やプロダクト戦略を踏まえた、開発計画やデリバリーと負債解消の配分であったり、技術的な意思決定の多くは、各プロダクトのエンジニアリングマネージャーらに委ねられています。
CTOとしては、広い範囲のシステム群全体に対しての構想を描いたりしています。
今回、ふと、3年くらい前に自分が作成した資料を見返しましたが、このシンプルな資料から始まり、各チームが推進し、コラボレーションし、今ほぼ実現に至っているの、LITALICOのみんなすごいなって手前味噌ですがあらためて感心してしまいました
(さすがにこの資料は公開できませんが、もっとちゃんと書けって話でもあります)
どんな会社か？
ビジョン
「障害のない社会をつくる」
障害の有無や、その他にも様々なマイノリティーの特性によって、生活の様々な場面で困難があったり、人生を歩む上での選択肢が狭められたりしている社会のあり方を変えていくのが、実現したいことです。
事業ドメイン
障害福祉、介護福祉、教育
ビジョンを実現するために、将来的にさらなる拡張もあるでしょう。
事業群
8社の子会社を持つグループ会社です。
- 直接支援 - グループ全体で400近い事業所を持ち、障害のある方々や介護を必要とする方々の支援を行ったり、ご家族向けのサービスも提供しています。
- toC Webサービス - 当事者、ご家族、福祉従事者向けの様々なWebサービスを提供しています。
- toB SaaS等 - 福祉事業所、小中学校向けの様々なSaaSやWebサービスやアプリケーションを提供しています。
エンジニア組織
プロダクト系だけでなく社内IT系のエンジニア含め、200名程度の組織です。
ほかに、プロダクトマネージャーやデザイナーが50名程度います。
技術戦略(？)的ショートショート
プロダクトの多種多産を可能にする
障害のある方々にとって、取り巻く様々な社会環境や生活の場面それぞれに困りごとがあり、また、ライフステージによってもまた様々な困難があります。
そのため、何か一つの特定の課題を解決しただけでは、「障害のない社会をつくる」というビジョンを実現することはできず、数多くのサービスを作っていく必要があります。
LITALICOにはすでに多くのサービスがありますが、まだまだラインナップとしては足りません。
また、ただ多数のプロダクトを開発するというのではなく、toCのWebサービスから、toBのSaaS、そしてリアルビジネスにおける業務システム、独自のアルゴリズムを組み込んだ支援業務のサポートをするものなど、様々な特性のプロダクト/システムを開発する必要があります。
そのため、採用する技術スタックやアーキテクチャ、開発プロセスなどは、プロダクト特性に応じて、何が重要視されるかも変わり、何が適切かも違ってきます。
一方で、ある程度類似の特性や構造のプロダクトをグルーピングすることも可能なため、グループ内では統一的な選択をしつつ、グループ毎にはそれぞれに最適な選択を行うという、全体最適と個別最適のバランスを考慮した選択をしています。
組織もそれに合わせた構造となっています。
成長や変化の比較的早い会社で、特にIT系事業群の増加やエンジニア組織の拡大はここ数年急激に進んでいるため、現在が最適というより、どこでグルーピングするのか、組織はどういう構造が良いのかは、継続的にアップデートが必要ですが、上記が基本の考え方です。
たとえば、エンジニア組織全体の中でどれくらい人材の流動性を作りやすいかや、事業観点で適した組織構造とシステム観点で適した組織構造の変換点をどこでどう表現するのかなど、適切なバランスを探る上での観点は他にも多数あり、言うは易く行うは難しです。
未知のものを作れる組織力
ビジョンや社会課題から発して事業やサービスを考える、まだ価値提供できていない生活場面やライフステージに対して事業やサービスを立ち上げる、となると、現在の組織のケイパビリティはもちろん踏まえつつも、これまで開発してきたものとは違うタイプのプロダクトを開発する必要や、違うタイプの技術を扱う必要は出てきます。
アプローチは2つあります。
1つは、「組織として」未知なだけであって、「全ての個人にとって」未知なわけではない状態を作ることです。
LITALICOのエンジニア組織では、新卒も中途も採用をしていますが、中途採用においては、もちろん、まずは募集ポジションとのスキルや経験のマッチ度ありきですが、まだLITALICOでは手がけていないタイプのプロダクトや技術だが、将来的に必要となるだろうものを経験しているというのも意識して見てきていたので、多様な経験を持った方々がいる組織になってきたかなと思っています。
もう1つは、エンジニアリング能力として何を重視するかと言う点で、特定の言語やフレームワークなどへの知見や経験の深さだけでなく、土台となるコンピュータサイエンスの理解、システム全体からアプリケーション設計やデータモデリングなどの設計能力、非機能要件を実現できるエンジニアリング力など、表層的な技術の移り変わりに左右されづらい力、未知の技術を早期にキャッチアップしたり、経験のないタイプのプロダクトを適切に設計できたりする基礎力の高さを大切に考えています。
これらは、まだ、共通認識として明確にしていたり、仕組みに落とし込んだりできていない部分が多いので、特に後者は、技術力に関する評価指標に盛り込んだり、育成や研修の仕組みを作り込んだりといったことをしていけるといいなと思っています。
また、少し話は逸れますが、技術は、あくまでも解決したい課題を解決したり、ユーザーへ提供したい価値を作り上げたりするための手段であると考えています。
仮に、その課題を解決するのに適した技術が古い技術であれば、それを選択できることも大切だと考えています。
もちろん、技術を蔑ろにしているのではなく、より良い手段を選択できるためには、新しい技術をキャッチアップしたり、様々な技術の本質を理解している必要があり、それらを扱うスキルも磨かないといけません。
なので、技術を好きであってほしいし、技術力を磨くには、技術的な好奇心も必要ですので、影響が少ない箇所で、それが最適か考え尽くすことなく、新しい関心のある技術を試してみるとか、そういった余地を作るのも必要だと思っています。
サービス/プロダクト群をつなぐ
先ほど多くのサービスを作っていく必要性について触れましたが、サービスを利用する方の視点に立った時、サービスを利用する多くの生活の場面は関連し合っていることが多く、ライフステージに応じたサービスラインナップも、その方の連続性のある時間の経過により移り変わっていくものです。
一般的に、事業の多角化を進めていった企業では、顧客IDを統合しようというようなアイデアはよくある話だと思いますが、LITALICOの場合、その事業群がビジョンに紐づいていること、通底するテーマを持っていることから、横断的にデータを統合して扱えたり、サービス間で相互にデータを活用できることが、個々のサービスの提供価値を大きく高めたり、包括的な新たな提供価値を作れるポテンシャルが非常に高いと考えています。
イメージとしては、取り巻く社会環境やライフステージの変化に合わせたサービスラインナップを様々用意しつつ、大きく包括的にLITALICOという1つのサービスを作っていくようなことを、エンジニア組織としても実現していければと考えています。
ここ数年は、toCからtoBまでいくつもの異なるタイプのプロダクトを実現することに取り組んでいましたが、これからは、それらと並行して、共通のIDやデータ連携等の基盤開発も、中長期的な取り組みとして進めていきたいと考えています。
実現にあたっては、これらの基盤は、できるだけ小さく、責務を限定し、各プロダクト/システムとは疎で基盤への依存を最小限にする、各プロダクト/システムの開発チームの認知負荷の増加も最小限に抑えるのがコンセプトです。
ドメインxエンジニアリング：共通
一般的にも、開発するプロダクトやシステムが扱うドメインやユーザーへの理解が深まるほど、より良いものが作れると思いますが、LITALICOの場合、扱っているドメインの特性や、そのドメインにおける前例の少ないことに取り組んでいることから、よりドメインやユーザーの理解が重要だと考えています。
また、それは、リアルビジネスとITビジネスの両輪を持つLITALICOという組織の強みでもあり、ただ両方の事業が同じ会社に存在しているだけの状態では強みたり得ません。
エンジニアがドメインやユーザーへの理解を得るには、そういった機会があることと、深め蓄積していく時間が必要だと思います。
機会については、まだまだ作っていきたいものの、
- 事業所の見学
- 事業所で支援員として働く方々向けの研修資料へのアクセスや座学研修へは参加も可能(中には、実際に働いてみたエンジニアもいます)
- 各サービス用のコンテンツ自体が、豊富な資料
- エンジニア向けの勉強会の企画
- 法令関連については研修プログラムの開発
- toCのユーザーヒアリングやtoBの顧客への訪問へのエンジニアの同席
などなどの機会があります。
LITALICOのリアルビジネスを行なっている事業部の方々の話を聞くこともできますし、プロダクト開発やグロース等の日頃の業務の中で、対象とするユーザーや社会課題への理解度が深まる情報に触れたり議論する機会も多くあります。
時間については、エンジニアは転職を繰り返しキャリア形成していくことも当たり前のことですし、2,3年程度で退職していくことを前提に組織設計する考え方もありますが、可能な限り長く働いてもらえるように組織環境を設計するという方針にしています。
エンジニア組織専任のHRチームも組成し、マネジメント陣と協力し、働きやすくモチベーションを得やすい組織環境、挑戦機会や成長できる環境、納得感のある制度や待遇などを作っていっています。
ドメインxエンジニアリング：支援の品質
LITALICOでは常時1万人以上の利用者の方々に対人の障害福祉サービスを提供しています。
日々、数千人の支援員が利用者の支援を実施したデータがありますが、これらを活用して、支援員がより良い支援を行うためのサポートを行うシステムをいくつか開発して利用してきています。
また、これらはLITALICO社内だけでなくtoBのプロダクトとしても提供しています。
こういった、障害とは？支援とは？その科学的根拠とは？といったことを深く理解していないと作ることができない類のプロダクトに関しては、(もちろん学びもするのですが)エンジニアが理解を深めれば実現できることでもなく、SaaS等におけるドメインエキスパートともまた少し違い、支援の実践とエンジニアリングの間にサイエンスの力が必要です。
LITALICOでは、そういった役割を担う人たちがおり、その方々を中心に、外部のアカデミアの研究者等の協力も得ながら、支援の実践を形式知化し、エンジニアリングの力でみんなが使えるシステムの形にするということを実現しています。
ドメインxエンジニアリング：法令への取り組み
LITALICOが手掛けるSaaSやリアルビジネス向けの業務システムでは、全てではないですが、障害者総合支援法や介護保険制度といった法令に基づいた業務を扱っています。
これらは数年毎に法改正があり、改正後の内容が定まってから施行まで限られた期間しかない中、いかにしてプロダクト/システムの対応を行うかという戦略がとても重要です。
技術戦略x組織戦略として、該当する複数のプロダクト/システムにおいて、法令の深い知識が必要であり、共通化が現実的であるラインで切り離し、共通基盤化するという試みを進めています。
組織戦略でもあるとしているのは、これが単なる共通処理を切り出すことでの効率化ではなく、これらの処理を局所化することによって、該当機能部分の開発に必要な法令の深い知識を持ち、限られた期間に正確に改正内容を設計に落とし込むことができる開発者を各プロダクトチームに安定的に配置する必要がなくなることを狙っているからです。
また、各プロダクトでは、それぞれのプロダクトが扱う福祉サービス特有の業務ロジックについて、法改正内容の対応をしていく必要があり、よりそれらに集中して対応できる環境を作るという意味もあります。
また、 LITALICOの中では、ドメインエキスパート相当の役割を担える方々が各所にいたり、開発者やQAエンジニア向けに法令知識を学ぶための研修プログラムを作っていたり、どのように改正内容を仕様や設計として落とし込むかのプロセスや設計上の工夫も多数取り組まれています。
エンジニアリング能力が高い社内IT内製チーム
LITALICOの社内IT組織は、元々はプロダクト開発やインフラを手がけていたようなエンジニアもいる組織です。
また、ITコンサル会社やSIerは利用せず、各種ソリューションを提供するベンダーもしくはその代理店と直接契約するのみで、全て内製で進めています。
(ちなみに私は、CTOという肩書きですが、CIOやCISOの役割も担っています。)
これは以下のような考え方のもとに、そのような方針としています。
適切な製品選定や活用
実際に開発やインフラ設計等をできるレベルでのエンジニアリング能力を有していることで、製品の良し悪しやそのベンダーの技術力や保守運用品質、持続性などの評価が一段深いレベルで行えます。
業務システム開発を行える能力から、対象となる社内業務のAsIs分析やToBe業務設計、データフローの設計などを、社内組織だからこその蓄積されたベースの理解の上で行えます。
SaaS等を利用するにあたって、製品側の業務へのマッチ度と、業務を製品に合わせていくことの相互影響がありますが、それもより適切な設計や判断が行えると考えています。
また、内製エンジニアのリソースを適切なミッションに振り分ける上で、時には外注でスクラッチシステムの開発をするという選択もあり得ますが、その際に、SIerとともにより適切な要件定義や仕様設計ができたり、内部設計等の品質コントロールも行えます。
スクラッチ開発という選択肢によるソリューションの広がり
今の時代、よほどの大規模な企業でなければ、事業特有のものであったり、独自のシステムであることが競争優位性に強く寄与するものでなければ、フルスクラッチで開発することなく、SaaS製品などを活用していくことが多いと思いますし、LITALICOでもそのようにしています。
ただ、社内IT組織として、スクラッチ開発する能力を有しており、選択肢の一つに持っていると、SaaS間の連携など不足する部分は作ってしまえたりします。
たとえば統合型ERPではなく、個々の領域が得意なベンダーのSaaSを組み合わせたり、それにより、領域ごとにより良いSaaSに入れ替えることができたりします。
会社や事業の成長や変化への対応速度
スピーディーに解決したい課題が発生した時、まだその業務設計が良い状態かわからない時、新規事業でまだ十分なシステム投資が難しかったり、業務が固まっていないフェーズなどで、短期的にライトなシステムを用意し利用してもらいつつ、中長期のシステム検討をするなどできます。
LITALICOでは継続的に新規事業を立ち上げているので、まだ不確実性の高い状況や、大きな投資がしづらい状況への対応をしていくことは重要です。
また、スピードが求められる場面の一例として、新型コロナの流行に対して、大きな影響もなく増収増益を継続できているのは、この社内IT体制であったことも大きかったと思います。
(まさに八面六臂の活躍でした。逆に違う組織方針を取っていたらと思うとゾッとします。)
費用対効果の最大化
同じ成果を得るために、より小さい、というかかなり小さい投資で同様のリターンを得られる場面が多いです。
一例として、社内インフラ系の中期計画として、ゼロトラストモデルのネットワーク/セキュリティ環境への移行を進めてきましたが、ゼロトラスト化したい！くらいの状態から、外部のITコンサルやSIerに発注するとなると、これはもうとんでもない金額の投資(暴利という意味ではないです)が必要になります。
LITALICOでは、ゼロトラストモデルの全体の設計や、それにより各所で影響が発生する様々な仕組みやシステムの再設計から、プランニングや実行まで、全て内製で行えるので、社内人件費以外では、純粋に各製品のライセンスコストのみで実現ができています。
「サービス/プロダクト群をつなぐ」の実現のしやすさ
中長期的に全サービス/プロダクト群を横断的に接続していくにあたって、共通基盤を開発するチームであったり、データサイエンティストやデータエンジニアなどと、エンジニア同士としてコミュニケーションやディスカッションし、担当領域のシステム群の対応をすることができます。
おわりに
ここで書いたことのいくつかは、たまーにあるインタビュー記事などの際にも喋ってることもありますので、もしご興味があれば、そちらも読んでみてください。
(基本的に、人前に出たりするのが得意ではないので、たまーになのですが、CTOとしてはもっと出ないといけないなぁと、みんなに怒られながら思っています。)
「3年に1回の法改正」にシステムをどう対応させる？LITALICOの事例に見る、事業特性に合わせた設計のヒント
【CTO×CQO対談】本質的な課題解決を追求するLITALICOのテクノロジー×サイエンスの活用戦略とは
【リンクアンドモチベーション×LITALICO】成長中の2社が語る、複数プロダクトを跨ぐデータ活用を実現するためのアーキテクチャとは #イベントレポート
謝辞
LITALICOのみなさん
今年もたくさんの記事を書いてくれたり、盛り上げてくれてありがとう！
そして、この一年もみなさんのおかげで、ビジョンの実現へ一歩も二歩も歩を進めることができました、ありがとう！
良いクリスマスを