内製 vs 外注の判断基準

連載「ICTからDXへ — 現場発・社長内製・実装の話」第10回

第2部の最終回です。ここまで「社長が自分でコードを書いている」という内製の話を続けてきました。でも、すべてを内製しているわけではありません。今回は、何を内製し、何を外注すべきか――その判断基準をお話しします。第3部の個別システムの話に入る前の整理です。

全部内製は、やってはいけない

最初に強く言いたいのは、全部を内製で作ろうとしてはいけないということです。

理由は単純で、世の中にすでに優れたサービスがある領域に、自分で作る理由がないから。会計ソフト・勤怠管理・チャットツール――こうした成熟した領域は、専門の会社が何年もかけて磨き上げています。同じものを内製で作っても、品質も価格も勝てません。

279でも、以下のような領域は外部のサービスを使っています。

• 会計：クラウド会計ソフト

• 勤怠管理：既存の介護人事ソフト

• チャット：Google Chat

• メール：Gmail

• ストレージ：Google Drive

• クラウド基盤：Google Cloud / Firebase

• AI：Claude・Gemini・OpenAI（本番での利用はGoogle Cloud経由に統一）

「車輪を再発明しない」というのは、ITの世界の鉄則です。

では、何を内製するのか

判断の軸は3つあります。

軸1：介護ドメインに固有か

介護業界に固有の業務――支援経過記録、ケアプラン、加算管理、担当者会議の運営、利用者情報の事業所間共有――これらは内製対象です。

理由は、汎用ソフトで作られていないから。あるいは作られていても、介護現場の細かい要件にフィットしないから。例えば一般的なCRM（顧客管理ソフト）は、介護の利用者管理にはまったく合いません。家族構成、要介護度の変遷、医療情報、認知症の進行――これらを扱うには専用の構造が必要です。

軸2：競争優位の源泉になるか

事業の差別化に直結する領域は、内製すべきです。

279の場合、利用者さんへのサービスの質が事業の差別化要因です。その質を支えているのが、職員間・事業所間の情報の流れ。だから統合利用者DBやCareNoteは、必ず内製で作ります。これは外に出してしまうと、他社も同じものが買えてしまうので、差別化が消えます。

軸3：頻繁に変更が必要か

毎週・毎月のように変えたい領域は、内製のほうが圧倒的に速いです。

介護報酬は3年ごとに改定されます。次は2027年度の改定です。現場の運用も四半期ごとに変わります。外注したシステムを「ちょっと変えてください」と頼むと、見積もり・契約・実装で1ヶ月以上かかります。内製なら、私が話してClaudeが実装し、その日のうちに本番に出せます。

逆に、年に1回しか触らないような領域は、外注で十分です。

3軸のマトリクス

3つの軸を組み合わせると、こうなります。

• → ドメイン固有（競争優位。変更頻度。結論）

• 統合利用者DB → ○（○。○。内製）

• CareNote（支援経過記録） → ○（○。○。内製）

• 介護情報基盤（当社の経営ダッシュボード） → ○（○。○。内製）

• レジェンドケアマネMCP → ○（○。○。内製）

• 会計（クラウド会計ソフト） → ×（×。×。外注）

• 勤怠管理 → ×（×。△。外注）

• Google Workspace → ×（×。×。外注）

• クラウド基盤（GCP） → ×（×。×。外注（基盤として利用））

表の「介護情報基盤」は当社の社内システムの名前です。国が進めている介護情報基盤とは別のものなので、念のため。

3つともに○がつくものは、迷わず内製。3つとも×なら迷わず外注。混ざる場合は要検討、というのが実用的な判断基準です。

「ちょっと作ってみる」のコストが下がった

ここでも前回までの話に戻りますが、AIで開発のハードルが下がったことで、「内製を試す」コストが劇的に下がりました。

以前なら、内製を始めるには「数人のエンジニアを雇って、半年プロジェクトを組む」必要がありました。失敗したときのダメージが大きいので、やる前から慎重に判断するしかなかった。

今は違います。私が1日コードを書いて、土台が動くものができる。それを現場に使ってもらって、駄目なら捨てる。捨てる前提で試せるので、判断基準が「どれが正解か」から「どれを先に試すか」に変わりました。

これは経営判断の質を変える、地味だけど大きな変化です。

外注先との付き合い方も変わる

ついでに言うと、外注先との関係も変わってきています。

以前は「丸ごとお任せします」という発注の仕方が多かった。今は「ここの設計はこっちで決めるので、実装の一部だけお願いします」という分担が増えました。一番難しい設計判断は内製で握り、量産的な実装の一部だけ外に出す形です。

これは外注先にとっても、無茶な要件で振り回されることが減るので、win-winの関係になります。

まとめ

全部内製はNG。判断は3軸――ドメイン固有か、競争優位の源泉か、変更頻度が高いか。3つ揃えば内製、揃わなければ外注。AIで「内製を試す」コストが下がったので、判断は柔軟に。

第2部はこれで終わりです。第3部からは、私たちが内製で作っている個別システムの中身を、ひとつずつ紹介していきます。

▼ この記事の内容を、40秒の動画にしました

次回予告 — 第11回 統合利用者DB — すべての中心

第3部のスタートです。私たちのシステム群の中心にあるのが「統合利用者DB」。拠点をまたいで利用者情報を一本に束ねる仕組みです。なぜこれを最初に作ったのか、何を解決しているのか、どんな構造なのか。次回はこれを深掘りします。

株式会社279（ツナグ）　介護の現場に、ちょうどいいテクノロジーを。

完全リモートで居宅介護支援事業所を運営しながら、介護事業所向けのICT・DX支援を手がけています。

▼ 会社のこと

https://279279.net

▼ 書いている人（次田芳尚／ケアマネジャー）

https://tsukuda.279279.net