マトリクス型のIT組織(250名)かつ多様な事業がある企業でIT投資戦略を策定する10のステップ

はじめに

LITALICOの亀田 ( @kamesennin ) です。執行役員VPoEとしてプロダクト開発や組織づくりに携わっています。

※ LITALICO Engineers Advent Calendar 2023 の14日目の記事です。

今年もアドベントカレンダーは2記事書きました。1記事目の

• 新たに学ぶ領域の技術書・専門書の記憶定着力と実践力を上げる読書手法

も是非ご覧になって下さい。ややマニアックです。

前提. LITALICOの現状

事業概要

LITALICOの事業はかなり多種多様です。
障害福祉領域を中心に以下のようなラインナップがあります。

• BtoC（障害のある方・ご家族向け）の店舗型の支援やライフプランニングのサービス
• BtoC（障害のある方・ご家族・従事者向け）のマッチングプラットフォームやHR系のサービス
• BtoB（福祉事業所・介護事業所向け）のSaaS型のサービス
• BtoB（学校向け）のパッケージ型ソフトウェアサービス
• 自社店舗事業向けの業務システムサービス

また最近ではM&Aも通してグループ会社の数も6~7つほどに増えてきました（2023年10月時点）。
ビジョンを共にする仲間が増えてきて嬉しいです。

参考： 2024年3月期第２四半期 決算説明資料 株式会社 LITALICO

全社のプロダクトやシステム

自分たちで開発・運用が必要かつ特定レベルの専門性の人がマネジメントする必要ある単位を1システムと定義した時に、システム単位では50システム以上あります。

更に、上記システムの組み合わせで構成される、かつユーザーへの提供価値や戦略を考えるべき単位を1プロダクトと定義したときに、20ほどのプロダクトが存在しています。

また、システムとは事業に紐づくプロダクト開発だけではありません。

• コーポレート組織（人事、採用、財務、経理、法務など）の生産性向上のシステム投資
• 自社で運営する福祉施設のDX化に必要なシステム投資
• (2023年10月時点)4,000名以上いる従業員中心にエンプロイーエクスペリエンス向上のITインフラ整備

など多岐にわたるのも特徴です。

全社の売上や利益

2024年3月期第２四半期の決算説明資料で公開している業績予想は以下です。

• FY2023の売上: 300億円
• FY2023の営利: 38.5億円

参考: 2024年3月期第２四半期 決算説明資料 株式会社 LITALICO

組織

2023年3月時点で従業員は4,137名です。そのうち多くが店舗事業での支援者の方々で、弊社のコアであり、最大の強みであると認識しています。

参考： 実績と今後の方針 | 株式会社LITALICO

その内の組織構造は以下3つの本部から構成されるマトリクス型組織です。

• 事業本部: 各事業運営を行う組織
• コーポレート本部: 財務管理や経理、採用や人事、などの管理部門組織
• プロダクト本部: エンジニアでデザイナー、PdMやマーケター、コンテンツ開発等の専門組織

プロダクト本部では、個別事業やコーポレート組織を支えるプロダクトやシステム、マーケやコンテンツ開発を各組織に入り込んで推進する役割はもちろんありますが、全社横断での成果最大化を狙う取り組み(セキュリティ対策やリスクマネジメント、相互送客のようなマーケティング施策、データ基盤やシステム共通化、コンテンツの品質管理）は重要な役割です。

さらに、プロダクト開発やIT投資を推進する専門組織はざっくり以下のような人数規模です。

• エンジニア: 約200名
• デザイナー: 約30名
• プロダクトマネージャー: 約20名

外注はほぼなしの内製型の組織です。「支援のプロフェッショナル」として強みがあるLITALICOから、ITに関する専門性強化で、より大きな進化に取り組んできました。

図で表現すると以下のような形です。（ﾌﾟﾛﾀﾞｸﾄ開発に特化した表現です）

本記事を書く背景

上記のような多様な事業に対して、

• 採用難易度もなかなか高い職種でもあるため、人員増での補填の難しさ
• 急拡大を行っても、良いプロセスとコラボレーションが生まれる組織づくりの大変さ

もあるため、250名と結構な人数のIT組織（エンジニア、デザイナー、PdM）をどのように配置し、どこに投資を行うべきかを、緩急も付けながら定期的に判断することが、より一層重要なフェーズに入ってきています。

また、LITALICOは3月決算（2023年10月時点）であり、毎年夏の終わり頃(今年は9月)から来期予算（+3年~5年ほど先までの中期計画）先の予算検討始めます。

IT組織は上記の通り、投資額の大きさもそうですが、上手く進められるか（ex. 適切なものが作れるか、ただしく開発が進むか）によって、全社へのインパクトが良くも悪くも大きくなる対象と認識しています。

そして、今年は8月〜10月のかけて、来期のIT組織の投資戦略の策定を行い、そこの取りまとめを担ってきました。

結構な事業数や人員数を全社視点でどう投資配分を行うかは、過去も何度か行いましたが、改めてどのような視点で判断すると良いのかを、このタイミングまとめておこうと思い、本記事を書くことにしました。

改めて、本記事の前提

1. IT投資戦略とは
   • 「IT資産を、どの組織や事業にどれくらいのバランスで配分するか」のこと。
   • 全社戦略として成し遂げたい状態に合わせて、どういった専門性の人材をどう揃え、配置すべきかを現実的な範囲も踏まえて判断を行う。
2. IT資産とは
   • 本記事において、IT資産の範囲は「人員（人件費・業務委託費・採用費）」である。
   • 圧倒的に多くの割合を占める人員に絞る（ツールやインフラ等の費用は対象外）。
   • 人員とは具体的には「エンジニア、デザイナー、PdM」である。
3. 組織構造と対象組織
   • マトリクス型組織かつ、各事業等への配置戦略はエンジニア、デザイナー、PdM組織が行う。
   • 「事業個別での人員調達は大変、プロダクト開発プロセスの個別整備は結構非効率」、かつ、「多様なフェーズの事業がある中で柔軟な配置計画を考えられることが現時点では効率的」と考え、全社横断での採用活動やプロセス整備や配置計画を行う方針としている。
   • よって、採用責任や育成責任、人員配置の最終決定はエンジニア、デザイナー、PdM組織が持つ。
4. 検討順序
   • 先にIT組織の投資配分を確定させ、それを前提として事業計画を策定する。
   • もちろん各事業計画を前提とした投資配分の検討になる。
   • ただし、具体計画は、IT組織の投資配分を確定した上で事業計画を詰める流れとしている。
5. IT資産に該当する組織が取り組むこと
   • 全社のIT投資戦略として今回は、上記にも書いた通りのあらゆるIT投資である「事業に紐づくプロダクト開発、コーポレート組織の生産性向上のシステム投資、自社で運営する福祉施設のDX化、エンプロイーエクスペリエンス向上のITインフラ整備」などをまとめて考えます
6. 記事の書き方
   • 詳細は結構ぼやかして書く、あくまで考え方のフレームを中心を記載。
   • 当たり前だが、上場企業として公開している情報以外は詳細は基本カット。
   • ぼやかす最優先の上で、できるだけ参考となるフレームは表現する努力を行う。

本記事の目的・目標・概要

目的

• IT投資戦略（全社戦略からIT人員の配置方針を定める）をどういう考え方で行っているか、その一連の流れを共有すること。

目標

• IT投資戦略を検討する1つの考え方が、近しい立場で戦略判断を行う方々に対して、何か少しでも参考になっている状態。

以下本題の構成

• ① 全体の流れを整理
• ② IT組織の現状理解
• ③ 全社目標の確認
• ④ 全社戦略（優先度）の把握
• ⑤ IT組織の優先度を整理
• ⑥ 投資戦略の前提条件の整理
• ⑦ 個別プロダクトやPJ毎の検討
• ⑧ 全体視点での検討
• ⑨ 投資戦略の策定
• ⑩ 具体計画の策定

それでは、上記目的、目標、構成に従って、以下本題を書いていきます。

※以下、スクショが大量に貼られていますが、重要な情報に少しでもなりそうな点は、ほぼ全部ぼやかしています。

① 全体の流れを整理

行ったこと

• 「どういった手順で考えるか」と「どこにどのようなアウトプットを行うか」をはじめに整理しました。

行った理由

• 検討の変数が大量で、検討に参加する方も一定多い中で、観点にヌケモレが発生しないよう、まず何を考えるべきかの整理は大切と考えます

具体的なアウトプット

考える手順

• 整理内容
  • 上記「本題の構成」にも書きましたが、以下「参考」のような手順を整理しました。
• 参考
  • 

アウトプット先

• 背景
  • Amazonのあり方を参考にしています。具体的には、Amazonの会議では何かしらの提案・議論を行う際には、パワポや箇条書きではなくナラティブ・文章でWord等に記載を行うとあります。
  • これは、Wordかつ文章を中心に丁寧に書かれることで、提案のロジックの全体像が把握しやすく、詳細の繋がりも丁寧に確認しやすいという運用にとても共感をしています。
  • 特に今回の事例では，大量にある②〜⑨で整理する情報やロジックが正しく前後で接続されるように、この資料を見る人全員が読むだけで理解できることを大事にしました。
• アウトプット先
  • それを実現するために今回は提案したい内容を踏まえ、SpreadSheetを選択しました。
  • 理由は同様のメリットは大体は満たせると考える点、表や数値の計算をしながら、細かくいじりながら資料作成と検討、その場の議論も進められるので、非常に効率的と考えているからです。
  • （ちなみに私は社内の提案資料は基本すべてSpreadSheetを活用します。）
• 参考記事
  • アマゾンのすごい会議。ルールは「パワポ禁止、箇条書き資料禁止」
  • アマゾンの最強の働き方――Working Backwards
• 資料の例
  • 

② IT組織の現状理解

行ったこと

• 全組織や個人が同一パフォーマンスであるわけもないので、現時点でのIT組織のパフォーマンスがどの程度か、どこに課題があって、どこが強みか、を理解することから始めました。

行った理由

• それは後半の具体配分を考える時に、より適切な、実効性が伴った戦略になるために必要なためです。

具体的に整理したこと

過去の投資額や人数の推移

• 出した情報
  • （エンジニアやデザイナー組織が出来てから過去12年分くらいのデータはありますが）、今回は過去3年分の人員数とキャッシュアウトフロー(以下COF)の推移を出しました。
• 理由
  • IT投資が全社的な貢献性を測る指標として「全体の売上や利益の伸びに対して、どの程度の人員数やCOFを投資してきたか」のモニタリングは1つの重要指標と考えるためです。
• 参考
  • 

「製品開発・IT投資」の成果を測る観点

• 以下3つの観点で状況を可視化しました。

項目	概要	必要な理由
1.安定的な推進	大きな手戻りを起こさず、進められる	「（IT投資では特に）戦略や設計や連携ミス」で大きな手戻りが発生し、数ヶ月や数千万単位の無駄が生じるため
2.生産性の向上	開発やIT投資の単位人員あたりの生産量	「定めた内容を、より少ない投資額や時間で開発が出来るか」は生産性に数倍の違いが生じるため
3.売上・利益貢献	売上や利益により繋がる、投資対象の選択	「定めた内容を、より少ない投資額や時間で開発が出来るか」は生産性に数倍の違いが生じるため

• 「1.安定的な推進」の分析
  • 指標について
    • 日々活動を行っている大きな案件単位と1チーム単位としています。
    • 月次で各チーム単位での状況を経営陣でモニタリングし、「PJの遅れや体制再構築」などの影響発生を「問題」と定義し、課題・対策報告と検討を行います。（参考: 200名を超えるエンジニアリング組織のヘルスチェックで三方良しの世界観を作りたい）
    • 全体のチーム数と問題発生数、その率を並べてみます。
  • 指標の結果例
    • 
  • 分析したこと
    • 指標の結果を元に、その原因や現状の対策、今後の見通しを整理しました。
    • これで今後どの組織は安定的なのか、まだ不安定なのかが見えてきて、どこが攻め時でどこはまだ守り時かを判断する材料にします。
  • 分析の結果例
    • 
• 「2.生産性の向上」の分析
  • 前提
    • ここは、まだ上手く整理、モニタリングが出来ていません、課題です。次の半年〜1年をかけて、検討を進めたいと考えている所です。
  • 定めてみた指標
    • 何もないのもあれなので、GithubAPI使って期間毎（週、月、四半期）のPRマージ数や、人員数辺りの運営システム数やプロダクト数の推移を出してみました。
  • 分析したこと
    • 結果すごい変な生産量ではない（人員増加に合わせてPRマージ数は増えているし、システム辺りのエンジニア数やデザイナー、PdM数は違和感はない）ことくらいは分かりました。
    • マネジメント陣の実感値としての改善点があるので、今回はそういった視点からの分析にとどまっています。
  • 分析の結果例
    • 
• 「3.売上・利益貢献」の分析
  • 指標について
    • 上記「過去の投資額や人数の推移」で出した値を用いて、売上高や営業利益に対して、どの程度IT資産を投資してきたかを見ます。
  • 指標の結果例
    • 
  • 分析したこと
    • 上記指標から特定の傾向は導けましたが、重要な判断材料にはしていませんが、明らかに変更できると良い実態はあるので、そちらを投資配分先の参考情報として整理しました。
  • 分析の結果例
    • 
  • 今後
    • 以降も部内のKPIとして判断材料にはせず、モニタリング指標としては見ておくくらいの現状です。
    • 少しズレますが、何を目的とした投資なのか（リスク対応なのか、コスト削減・利益向上なのか、売上向上なのか）は分類し、傾向を追っていきましょうとして整理を進めています。

③ 全社目標の確認

行ったこと

• 1.自分で整理
  • 自身が執行役としてある程度社内の方針や情報は公開されていて、「こういう方針でこうありたい」という情報は見れるので、それを元に全社の目標を改めて自分の言葉でまとめました。
• 2.社長に確認
  • そして代表取締役社長に「今回検討する際の前提条件としては良いか」と確認しました。具体的な指標と内容はカットします。

行った理由

• 今回の場合において、全社目標は戦略の重要な前提にもなるので、しっかり確認をはさみました。

④ 全社戦略（優先度）の把握

行ったこと

手順

• 1.自分で整理
  • 「③ 全社目標の確認」と同じタイミングですが、「全社の事業や投資優先度(より強化したいポイント)」を社長との1on1で何度か聞きながら、また目標と同じく社内方針として公開されているものがあるので、それを自分なりにまとめました。
• 2.社長に確認
  • 「全社目標の確認」と同時に「今回検討する際の前提条件となる戦略、優先度はこれで違和感ないか」と確認しました。具体的な指標と内容はカットします。
  • 「ここは違う」と幾つか社長からフィードバックを頂きながら修正は入りましたが、誤った認識を理解できていたことも含めて、自分の頭で考えてみるのは視座の観点から良かったです。
• 3.同時にCTO・CPOとも確認
  • 「社長とこんな話をして整理したが、違和感はないか、他漏れている視点がないか」をCTOとCPOにもぶつけて認識をそろえるステップも合間合間に踏んでいます。

優先度の観点

• ◯◯機能組織の強化、〇〇リスクの対応、◯◯事業領域の強化、横断的な◯◯基盤の強化、新規◯◯への挑戦、などいくつかカテゴライズをして会社全体の取り組みを整理してみました。

アウトプットのイメージ（一部抜粋）

行った理由

• 全社目標や戦略、優先度に従ってIT投資の優先度も変わる、と考えているので、その前提を確認する必要は重要としています。

⑤ IT組織の優先度を整理

行ったこと

手順

• 「④ 全社戦略（優先度）の把握」で定めた戦略・優先度を元に、IT組織の優先度を検討します。
• 手順は「④ 全社戦略（優先度）の把握」に記載の手順と同時に進めています。

優先度の観点

• 全社戦略（優先度）がそのままIT投資の優先度にならないのも特徴でした。全社戦略（優先度）に限らずIT組織としては十分な対応が出来ており改めて強化の必要がない所もあれば、全社戦略（優先度）としては1番に高くはないがIT組織観点ではさすがに少し投資をすべき、などの観点もあるためです
• ただあくまでも全社戦略の推進が最大化されるIT投資の優先度は何なのかを重視して整理することを意識しました。

行った理由

• IT投資の優先度に従って、実際の投資配分を判断する時にトレードオフが発生する場合や、緩急をどう付けるかを検討する場合の思考の軸になるためです。

アウトプットのイメージ

⑥ 投資戦略の前提条件の整理

行ったこと

• 今回は「IT組織の人数やCOF観点での投資の上限」を決めました。それを制限として次のステップ以降で投資配分の検討を行います。
• 実際に活用した具体的な観点はぼやかします。

行った理由

• これはどちらかというとその前提で考えてみて欲しいというオーダーを取締役・財務のチームから承った所です。
• 理由には納得感がありますし、自分が説明側に回ってもある程度は自信を持って話せます。そういう視点で考えるんだなと学びになりました。

⑦ 個別プロダクトやPJ毎の検討

行ったこと

方針

• 各プロダクト・PJごとに、PdMや開発責任者で投資余地を複数パターン検討しました。

補足

• 実際は少し異なりますが、ぼやかして人数ベースのみパターンを考えたことにします。

検討のフォーマット

• 松竹梅の3パターンを作成
  • 松: 人員が増える場合
  • 竹: 人数が横引きの場合
  • 梅: 人員が減る場合
• 各パターン（松竹梅）ごとに「取り組みの概要」「戦略・リスク」を記載
  • 取り組みの概要: 何を具体的に行うのか。
  • 戦略・リスク: 何が出来るのか、どういうリスクがあるか。

行った理由

• 3パターンに分けた理由は「増員と横引きと減員」と明記することで強制的に発想を広がると考えたためです。

アウトプットのイメージ

⑧ 全体視点での検討

行ったこと

方針

• 個別案件の視点とは別途、プロダクト開発やIT組織全体の視点からみて、経営戦略に沿って投資すべき対象がないかを検討します。

具体視点

• ex. マネジメント体制
  • 必要最低限のマネジメント体制が揃っているか。
  • 特に無茶な兼務、あるべきリーダーシップの体制から見た乖離の検討。
• ex. リスク観点
  • 前提、全体視点からIT投資観点でのリスク分析を別途行っています（これはまた別記事を書こうと思います）。
  • 結果、対応すべき内容がないかどうかを検討しました。

行った理由

• 個別だけでは見えない、全体最適や漏れる視点があると考えたためです。

アウトプットのイメージ

リスク観点の評価

⑨ 投資戦略の策定

行ったこと

流れ

• 1.執行役陣中心に個別プランの松竹梅をすべて確認し、現実的な選択肢のパターンと計画の幅を把握します。
• 2.全体を集計します。
• 3.「⑥ 投資戦略の前提条件の整理」で定めた条件を満たすかを確認します。
• 4.いきなりは条件を満たさないので(笑)、「⑤ IT組織の優先度を整理」で定めた優先度を元に全社戦略が最も確実性高く実現出来るプランを目指して、個別松竹梅を何度も関係者で議論し、選択します。
• 5.初めに提出された松竹梅の上下も取っ払って広げて考えることもしました。
• 6.上手く条件を満たすまで頑張ります。
• 7.投資配分とその理由（どういう戦略でその判断なのか）を正しく言語化します。

補足

• 結構大胆な緩急が必要なタイミングでもあったのと、そうしないと適切な戦略にもならないと思っていたので、個別個別を丁寧に見て、「5」にも書いたように仮にこうやった変化を起こしたらどうなるのかを、実現可能性がつくれそうなチームがどこかとセットで大きく考えることを意識しました。
• 多面的かつ現状にひっぱられない大胆な視点と、実現不可能だと意味がない戦略や計画になるので検討可能な範囲がどこかの観点の2つのバランスを取ることが大変でした。

行った理由

• 「投資戦略」という観点では最終的なアウトプットの根幹となるものです。

アウトプットのイメージ

⑩ 具体計画の策定

行ったこと

方針

• 1.基本は定めた投資戦略にしたがって、事業計画を策定していきます。
• 2.事業計画を一次案として取締役に提出する前、執行役陣で個別計画の簡単なレビューを入れます。
• 3.集約し全体の戦略とそれに従った計画を提出します。

レビューの観点

• ex.結果投資戦略の制限通りにおさまっているか。
• ex.リーダー陣や正社員不足など無理した体制になっていないか。
• ex.新規採用や異動などの場合は立ち上がりを加味したプランか(配置即戦力にしていないか）。
• ex.事業計画が無理な計画になっていないか（無理なグロース計画、リリーススケジュールになっていないか）。
• ex.さすがに無理な人員そう、こういった増員でやはりプラスの影響が出せそうなどの確認。

行った理由

• 修正が多く入るというより、念のため簡単なレビューを挟むことで計画のリスク把握や、全体を集計した後の調整余地、などを理解することで、少しでも計画の確実性を上げて、全体最適を考えられるようにするためです。

他意識したポイントや学び

意識したポイント. 情報の見える化、納得感をどう作るか

• (権限の縛りは大きいですが)できるだけ検討の関係者に検討中の情報がオープンになることを意識しました。
• 編集中も含めて、常にシートは公開し、アップデート中も共有しながらできるだけ考えられるようにしました。
• 特に具体計画に入るときには前提条件や全社戦略の理解を踏まえた個別投資強弱が納得感あってこそ、初めて計画策定やその後の実行にコミットメント出来るかどうかが変わってくると思ったためです。
• 策定のプロセスで納得感の観点もそうですし、他に上手く出来たかは、計画完了後に関係者のみなさんにヒアリングしたいと思っています。

学び. 丁寧な練られた計画であるが、丁寧さの外にある大胆さが漏れていないか

• 代表取締役会長に「丁寧に考えられているが、制限に従うことを意識した結果、投資したかったが出来なかった対象はあるか？もっと大きな成果が出せる投資の可能性は本当にないのか」と聞かれました。
• 確かに全体の統制や整理を意識することにやや偏っていた自分に気付きました。適切に管理し、でも創造性を阻害しないような最低限の枠組みを作ることは企業経営において重要という学びもありながら、枠を作った上で、枠の外に出る発想も常に持たねばならないなと思いました。

最後に

もちろん、この戦略を計画として確定させ、より良く実行に移しながら、ときには修正を行いつつ、成果に繋げられたかが、最重要です。

この戦略を実現するために「② IT組織の現状理解」で分析した組織課題や解決策が正しく遂行できるかは重要な要素の1つです。今から半年はそういった課題解決もミッションとして取り組んでいます。結果どうなったかはまたできる限り発信していきたいです。

ゆくゆくは自社だけに限らず、IT投資の生産性を上げていくべき日本（はたまた世界）全般の戦略から成果まで何かしらの貢献が出来るよになりたいのですが、まず初めのステップとして自社での学びを発信してみました。改めて振り返りとなってよかったです。

今後もエンジニアリングの専門性を学習と実践を通して高めながら、プロダクト開発の現場にもしっかり足を置いて、ドメインや社会全般の理解を深めることで、ITを通して社会全般に貢献できる自分と会社になれたら良いなと思っています。

こんな会社でございます、興味もって下さったら方、ぜひ私に直接でもご連絡をください！
X(旧Twitter): @ka_me_sen_nin

それでは、明日(15日目)のLITALICOのアドベントカレンダーは

• コーポレートエンジニアのスペシャリスト @gate9 さん: Google Apps Script 開発マイルール（開発環境編）
• 新卒内定者の @zacky_50 さん: わからないことが分からない話（ChatGPTの使い方：プロンプトエンジニアリング）

の2記事です。

僕はこれで今年のアドベントカレンダーも終わりです。
少し早いですが、来年も引き続き、LITALICOをよろしくお願いいたします！