DXは「作る」より「育てる」｜2つの成功事例で実証する「小さくはじめて大きく育てる」
こんにちは。ライジングサン・システムコンサルティングの岩佐です。
前編では、DXが停滞しやすい背景を IT経営の4ステージ という切り口で整理しました。 中編では、「小さくはじめて大きく育てるDX」がなぜ中小企業の文化にフィットしやすいのか、そして ステージ2からステージ3へ進む局面 で何が起きやすいのかを掘り下げました。
そして今回（後編）は、その考え方が 本当に現場で機能するのか を、私たちのクライアントの成功事例をもとに実証します。
ただ、「DXの成功」と言っても、人によって指しているものが違います。
なのでこの記事では一旦、次の3つを満たしている状態を「DXが成功している」と仮置きします。
- ステージ3（全社を一気通貫する仕組み）が構築されている
- その仕組みが、ビジネス環境の変化に合わせて 今もブラッシュアップされ続けている
- DXの取り組みが、効率化にとどまらず 新規事業 にまでつながっている
前者2つは八光電機様、最後の1つはイメージワン様の事例を見ると、イメージが掴みやすいと思います。
この記事でお伝えしたいこと（結論）はシンプルです。
DXは「最初から立派なものを作る」ことで成功するのではありません。 DXは「育つように設計する」ことで成功確率が上がります。
その設計には、再現可能な共通条件があります。 本編では、その条件を提示したうえで、2つの事例で裏付けます。
1. 「育つDX」に共通する5つの条件
ここでいうDXは、壮大なビジョンの話ではありません。 現場が一歩目を踏み出し、学習しながら前に進み、結果として全社の意思決定や事業に波及していく――その 進め方の設計 の話です。
私たちが多くの現場を見てきた中で、「育つDX」には次の共通条件があります。
1-1. 小さく始める（スモールスタート）
最初から全社DXをやろうとすると、要件も関係者も増え、必ず動きが鈍くなります。 しかも、最初の段階では「何が正解か」がまだ分かっていないので、大きく作るほど手戻りも大きくなります。
だから私たちは、最初の一歩を 少人数・単一部門・限定業務 に絞ります。 ポイントは「小さく始めること」そのものではなく、早く学べる状態を作ること です。
たとえば「5ユーザでも回せる業務」を1つ選び、まずはそこで成果を出す。 その成果が、次の投資判断の”証拠”になります。
1-2. まずは、自分たちで手を動かす（学習）
外部に丸投げして「完成」を待つと、社内に学習が残りません。 その結果、次の改善が回らず、結局また外注するしかない状態になります。
重要なのは、成果だけでなく 学びが社内に残る進め方 になっているかどうかです。 具体的には、要件を言語化する、触りながら直す、運用しながら改善する――この一連を 自分たちの手で回せる状態 を作る。
内製化支援で私たちがよくやるのは、まず外部で80%を形にし、残り20%をペアプロやレビューで仕上げる、というやり方です。 「完成品を納品する」のではなく、「自走できる状態を残す」ためです。
1-3. 無駄な機能はつくらない（段階的リリース）
一般的なシステム開発、特にアウトソーシング開発で用いられるウォーターフォール開発では、最初に要件をすべて定義して、完成したら一気にリリースする、というやり方が取られがちです。 しかし、私たちは、あえてその手法を取りません。
作る機能は必要最低限の機能に絞り、優先順位の高いものから、短いサイクルで何度も何度もリリースするというアプローチを取ります。 こうする最大の理由は、DXに関するの投資対効果を高めるためです。 ある調査によると、完成したソフトウェアの約６割は全く使われない、もしくは殆ど使われないというレポートがあります。 だからこそ、最初から全部作るのではなく、投資対効果が高い機能から段階的に作って、段階的に出す。
「少しずつ広げる」というのは、慎重だからではなく、無駄な機能を作らないための、合理的な戦略 です。
1-4. 内製とアウトソーシングのハイブリッド（内製化の闇対策）
内製化は正義のように語られることもありますが、現実には 属人化 という大きな落とし穴があります。 属人化が起きると、エース離脱や評価制度の歪みで、DXは突然止まります。
だからこそ、最初から「内製か外注か」ではなく、内製とアウトソーシングのハイブリッド体制 を前提にしています。
このことで、内製開発の最大のメリットである 開発スピード を活かしつつ、設計レビューや難所（連携・セキュリティなど）については 外部の知見で支える ことができます。 つまり、内製とアウトソーシングの「いいとこ取り」を狙うわけです。
また、レビューや規約といった仕組みを前提にしておくことで、内製開発エースの退職リスク――いわゆる 内製化の闇 に対するリスクヘッジにもなります。
だから私たちは、最初からハイブリッドを前提にします。
1-5. 経営者はDXにどう関与するべきか（経営者の役割）
経営者が現場のやり方に口を出す、という意味ではありません。 経営が担うべきなのは、現場が安心して前に進めるための 土台の意思決定 です。
たとえば次のような話です。
- どこまでを投資対象とするか（中長期ロードマップ）
- 部門間をまたぐ優先順位付け（「どれからやるか」を決める）
- ガバナンス（全社最適へ進むときの意思決定の場）
- 人と評価の設計（内製を続けられる状態）
現場の改善がうまく回り始めたとき、次に必ず「つなぐ話」「全社で使う話」が出てきます。 この局面――つまり ステージ2からステージ3へ進む局面 で、経営がこの意思決定を担えるかどうかが、分岐点になります。
2. 事例①：八光電機｜5ユーザの物流から全社へ育ったDX
最初の事例は、株式会社八光電機様です。 「小さくはじめて大きく育てるDX」を最も体現している事例だと、私たちは考えています。
2-1. きっかけは「印刷が止まる」という現場の危機
当時、物流管理部門では、受注情報を 自動で印刷するだけ のシステムが動いていました。 しかし、その仕組みはWindowsのサポート切れ等の事情で維持が難しくなり、動かなくなるリスクが現実化していました。
受注情報は、別会社が開発したメールフォームから入力され、電子メールで届きます。 旧システムは、そのメールを受け取って 内容をそのまま自動印刷するだけ。
そして現場では、印刷された紙を見ながら、エンドユーザがMS-Accessで作った受注管理システムへ手入力していました。
この構造は、言い換えるとこうです。
- 情報はメールで届いているのに
- 紙にして
- 人がまた入力している
改善余地は明確でした。
2-2. 最初の一手：メール本文を解析し、受注情報をDB化して手入力を削る
そこで最初に取り組んだのは、メール本文の内容を解析し、受注情報としてデータベース化することでした。 つまり「印刷の置き換え」ではなく、転記の構造そのもの を変える設計です。
さらにこのプロジェクトには、もう一つ重要な要件がありました。 それは、「自分たちでも開発できるようになりたいので、開発手法を教えてほしい」という要望です。
ここが、単なる外注ではなく「育つDX」に変わる入口でした。
進め方としては、
- まず外部（私たち）が、短期間で完成度80%まで形にする
- 残り20%を、ペアプログラミングをしながら仕上げていく
という設計を取りました。
この「最初に形がある」ことが、学習速度を一気に引き上げます。 ゼロから教えるよりも、完成形に近いものを題材にしたほうが、理解が速いからです。
2-3. 成果：誤配送ゼロ、月140時間の残業ゼロ
結果として、現場には明確な成果が出ました。
- 誤配送がゼロ件になった
- 誤配送により発生していた 月間140時間の残業がゼロになった
数字のインパクトだけではありません。 誤配送がゼロになるということは、顧客からの信頼という「見えない資産」が積み上がる、ということでもあります。
2-4. 育て方：ペアプロ → 宿題 → レビュー → 担当領域を広げる
この事例が「育つDX」として強いのは、成果だけではありません。 内製化を「属人化させずに育てる」プロセスが組み込まれていた点です。
実際に行ったのは、次のような進め方です。
- 最初は、私が書いたプログラムを「解剖」する形で説明する
- 次に、ペアプログラミングで少しずつ書いてもらう
- 次に、「次回までにこの機能を実装してみて」という宿題を出し、レビューする
- そして、内製担当者が実装する領域を少しずつ広げていく
この過程で、
- データモデリングの重要性
- コーディング規約の重要性
- 開発ドキュメントの重要性
- 安全で可搬性の高いスクリプトの書き方
といった「将来の属人化を防ぐ土台」もあわせて指導していきました。
2-5. ステージ2→3：経営を巻き込むのは、このタイミング
当時の八光電機様の一部の方は、FileMakerに対して大きな不信感を持っていました。 それまで社内システムはMS-Accessでされており、FileMakerは「素人向けのカード型データベース」という印象があったのです。
しかし物流部門で成果が出たことで、その認識が覆りました。 社内の開発者も育ち始め、内製とアウトソーシングの比率は おおむね50<50>。 ユーザー数も10ライセンス程度まで増えていました。
ここで私たちは、現場の成功を「単発」で終わらせないために、次の一手を打ちます。
- より広範囲な業務で活用していくための 中長期のIT投資ロードマップ を作成
- 経営層にプレゼンテーションし、意思決定を取りに行く
物流部門での成功が証拠になっていたこともあり、承認は得られました。 その結果、FileMakerが社内の公式な開発ツールとして認められ、ライセンス費の増額も承認されました。
ここが、明確に ステージ2からステージ3へ移行する局面 です。
2-6. 育ち方：物流 → 出荷 → 在庫 → 基幹連携 → 販売管理 → 生産管理
その後、内製とアウトソーシングのハイブリッドで開発されたソフトウェアの活用範囲は、段階的に広がっていきました。
最初は、物流部門のほんの小さな業務効率化を目的としたDXのスタートでした。
そこから順を追って在庫管理や購買管理を含めた物流管理業務全体を包括するシステムを構築しました。
その後、このシステムは基幹系システムとの連携機能を実現します。
更には、営業部門が利用する販売管理システム、そして製造部門の基幹業務をカバーする生産管理システムも、内製とアウトソーシングのハイブリッドで開発しました。
重要なのは、最初から「全社システム」を作ったのではなく、 成果と学習を積み上げながら、少しずつ広げていった ということです。
現在ではユーザー数は 170名超 となり、社内で継続的に進化する仕組みとして機能しています。
参考：八光電機様の事例は、過去のFileMakerカンファレンスでも公開されています。
3. 事例②：イメージワン｜社内ツールがSaaSに育ったDX
次の事例は、株式会社イメージワン様です。 こちらは「社内の仕組み」として始まったものが、結果的に SaaSとしての事業 に育っていったケースです。
DXの文脈でいうと、「新規事業の創造」というひとつの到達点を示す事例だと考えています。
3-1. 出発点：病院経営層向けエグゼクティブレポート
最初の要望は、医療経営コンサルティング事業における 病院経営層向けのエグゼクティブレポート を自動生成したい、というものでした。 もう少し正確に言うと、「このレポーティングツールを 自分たち（内製）で実装したいので、その立ち上げを手伝ってほしい」という依頼からスタートしました。
一見すると「レポート自動化」の話に見えます。 しかし、ヒアリングを進めると、実態は別物でした。
3-2. 実態は「病院経営に特化したBIダッシュボード」だった
よくよく整理すると、作りたかったのは単なるレポーティングツールではなく、 病院経営に特化したBIダッシュボード に近いものでした。
具体的には、医事科のレセプト（UKEファイル）を正規化して取り込み、各種集計を行い、ダッシュボード上にグラフとして描画する。
ご存知の通り、UKEファイルは構造が複雑です。 それを正規化し、集計し、可視化する――この工程を、コーディング経験がない人に教えながら進めるのは、かえって時間もコストもかかります。
ここで重要なのは、「内製化支援＝なんでも内製させる」ではない、ということです。
3-3. 内製化を一度止める判断：まずベータを作り、教材にする
そこで私たちは、方針を切り替える提案をしました。
- まずは私たちがベータ版を作る
- それをモチーフにして、内製エンジニアを育てる
こうご提案したのは、八光電機様の事例と同じく、「先に形がある」ほうが学習が速いからです。
3-4. 3ヶ月で「ほぼ完成形のBIダッシュボード」ができた
結果として、開発開始から3ヶ月で、ほぼ完成形に近い「BIダッシュボードシステム」ができました。
- 操作性も見栄えも、SaaSプロダクトのMVPとして十分
- 開発スピードにも驚かれた
当時は FileMaker + Webix という構成で作っていたこともあり、短期間で形にできたのも大きかったと思います。
そして、社内でこんな声が上がります。
「これなら、以前失敗したSaaSプロダクトの開発を復活できるんじゃないか」
3-5. SaaS化の議論：反対意見を踏まえ、段階設計に落とす
実はこのとき、私はSaaS化にかなり反対していました。
- FileMakerのライセンス体系は、一般的にSaaSに向きにくい
- FileMakerの開発者人口が少なく、プロダクト開発者を社内で育てるのは現実的ではない
- SaaSで売るなら、単なるツール売りではなく、継続サービスとして成立させる「合せ技」が必要
つまり、技術だけでなくビジネスとして成立するか、という話です。
それでも社内からは、次のような理由が返ってきました。
- 病院経営は制度ビジネス（医療保険）で、全国共通の仕組みで動いている
- 同種のサービスを提供しているSaaSが見当たらない
- UKEだけでなく会計データのBI（管理会計機能）まで広がれば可能性がさらに出る
- BIは日常業務の基幹ではないため、ミッションクリティカル度が相対的に低いので、サポート負荷は高くない
この議論を踏まえて、最終的にこういう方針に落ちました。
「まずFileMakerで10〜20法人に提供して検証し、うまくいったら完全Webシステムに切り替える」
ここでも、最初から完璧な最終形を作るのではなく、 不確実性を前提に 段階的に育てる設計 を選んでいます。
3-6. 追い風：FileMaker Cloud と WebDirect の進化
そして、これはかなり運が良かったのですが、方針決定の直後に FileMaker Cloud が登場しました。
従来のFileMakerは、PCにFileMaker Proをインストールして使う、社内利用前提の色合いが強いライセンス体系でした。 しかしFileMaker Cloudは Claris ID を課金単位とし、所属法人を問わない形で利用できる体系です。
これにより、
- ライセンスを保有するのはイメージワン
- 利用者はSaaS契約法人（医療法人）
というフォーメーションが可能になります。
さらに WebDirect も進化していました。 SaaS利用で「クライアントにFileMaker Proをインストールしてください」とは言えません。 しかしWebDirectなら、モダンブラウザがあれば動きます。
プロダクトを利用する医療法人のユーザには、Claris IDさえ用意してもらえれば、すぐにアプリケーションを利用していただくことができます。
参考：当時の経緯は、こちらの動画でも公開されています。
4. 2つの事例から見えた「育つDX」の実装ポイント
ここまでの2つの事例は、業種も目的も違います。 しかし「育つDX」という視点で見ると、同じ構造が見えます。
八光電機様は、5ユーザの物流から始まり、全社の仕組みへと育っていきました。 イメージワン様は、社内の仕組みとして始まったものが、SaaSという新規事業に育っていきました。
どちらも、最初から「完成形」を狙っていたわけではありません。 だからこそ、再現性のある”育て方”が残っています。
ここからは、その育て方を、もう少し具体的な「実装ポイント」として整理してみます。
4-1. DX担当者向け：最初のスコープは「5ユーザで始められる業務」から
DX担当者の方が最初に悩むのは、たいていここです。 「どの業務からやればいいのか」「何をテーマにすればいいのか」。
このとき、多くの人が「重要そうなテーマ」から選びたくなります。 でも実は、最初の一歩で大事なのは、重要度よりも “動かせるかどうか” です。
八光電機様の出発点は「印刷が止まる」という現場の危機でした。 イメージワン様の出発点は「レポートを自動生成したい」という相談でした。
どちらも、現場にとって切実で、かつスコープを切りやすい。 だから最初の一歩として成立しています。
たとえば、次のような条件を満たしている業務は、スモールスタートに向いています。
- 入力が自然に集まる起点がある（メール、ファイル、日報など）
- 現場に負荷が集中していて、改善の効果が見えやすい
- 失敗しても致命傷にならない（やり直しが効く）
最初から全社を変えようとしなくていい。 まずは「5ユーザで始められる業務」をひとつ選び、そこで成果を出す。
その成果が、次の投資判断の”証拠”になります。
4-2. 学習の設計：「80%を早く形にし、残り20%で自走力をつける」
内製化支援でよく起きる失敗は、「ゼロから教えよう」としてしまうことです。 教える側も教わる側も真面目なので、最初から丁寧にやろうとする。 その結果、学習コストが膨らみ、プロジェクトの速度が落ちてしまいます。
八光電機様の事例でも、最初にやったのは「完成度80%まで短期で形にする」ことでした。 イメージワン様の事例でも、内製にこだわらず「まずベータを作り、教材にする」という判断をしています。
ここで共通しているのは、「完成」が目的ではないという点です。 目的は、学習が残り、自走できる状態を作ること。
そのために有効なのが、次の設計です。
- まず外部で80%を早く形にする
- 残り20%をペアプロ・宿題・レビューで内製化する
ゼロから教えるのではなく、動くものを題材にして学ぶ。 このほうが、理解のスピードも、成果のスピードも上がります。
「完成品を納品する」のではなく、 「自走できる状態を残す」。
ここを意識すると、DXは”育つ方向”に動き始めます。
4-3. 経営者向け：関与すべきなのは「現場」ではなく「土台」
経営者の方からよく聞くのが、こんな悩みです。 「DXは経営者の関与が大切って言われるけど、結局どう関わればいいのか分からない」。
ここで誤解されやすいのですが、経営者が現場のやり方に口を出す、という意味ではありません。 むしろ逆で、現場のツール選びや画面設計に踏み込むほど、現場は動けなくなります。
経営が関与すべきなのは、現場が安心して前に進めるための 土台の意思決定 です。
たとえば、こういう話です。
- 中長期でどこまで投資するか（ロードマップ）
- 部門間の優先順位をどう決めるか（「どれからやるか」を決める）
- 全社最適へ進むときの意思決定の場をどう作るか（ガバナンス）
- 人と評価をどう設計するか（内製を続けられる状態）
八光電機様の事例では、ステージ2からステージ3へ進む局面で、 中長期のIT投資ロードマップを整理し、経営の意思決定を取りに行きました。
この関与があったからこそ、局所最適で終わらず、全社最適へ育てることができた。 経営が担うべき役割は、まさにここです。
4-4. 内製化の闇を避ける：属人化を前提に「仕組み」を作る
内製化は、放っておくと属人化します。 属人化すると、DXは突然止まります。
ここは、きれいごとでは済みません。 「内製化＝良いこと」という話の裏側に、必ずリスクがある。
だからこそ、最初から属人化を前提にして、 それを”仕組みで潰す”設計が必要になります。
たとえば、八光電機様の事例でも、ペアプロ・宿題・レビューという育成プロセスが組み込まれていました。 「できる人を作る」だけではなく、「できる人が抜けても回る」状態を作るためです。
そのために、後付けではなく、最初から次の要素を組み込みます。
- データモデリング（全体が崩れない土台）
- 規約（書き方・作り方を揃える）
- レビュー（品質と学習を同時に残す）
- ペアプロ（知識を分散させる）
- 外部との役割分担（難所を抱え込まない）
内製化の本当のポイントは、「作れる」ことではありません。 作り続けられる状態にすること です。
この4章で整理した内容は、派手さはありません。 でも、DXを”育てる”ためには、どれも外せない土台です。
そして重要なのは、これらを「努力」でやるのではなく、最初から「設計」として組み込むこと。 少なくとも、私たちはそう考えています。
5. 生成AI時代でも、「小さくはじめて大きく育てる」は有効
5-1. AI駆動開発は、DXを加速させる強力な道具
ここ数年、生成AIの進化によって AI駆動開発 が注目を集めています。 DXをスピーディーに進めるために、「内製化 × AI駆動開発」に取り組む企業も、これからさらに増えていくと思います。
私たち自身も、生成AIを使った開発にいろいろ挑戦しています。 たとえば Webビューア内で動かすWebixのコードは、生成AIに書いてもらうこともあります。 AIの力を借りることで、実装スピードが上がるのは間違いありません。
5-2. 難しいのは「コード」ではなく、「仕様を自然言語で正確に書く」こと
ただ一方で、AI駆動開発には、ローコード開発とは違う難しさがある、と感じています。 それは「コードを書くこと」よりも、自然言語で仕様を正確に記述すること のほうが難しい、という点です。
実装経験が豊富で、仕様を言葉で正確に切り出せるエンジニアであれば、生成AIをとても上手く使いこなせます。 しかし現実には、このレベルのスキルを安定して発揮できる人は限られます。 ましてやコーディング経験のない人が、内製化と称してAI駆動開発を始めた場合、意図せずして「理解負債」を抱えたアプリケーションが増えてしまう――そんな未来も、十分に起こり得ると思っています。
5-3. PoCやMVPでは強いが、業務で使うなら「責任主体」が必要
2025年以降、とくにAIエージェント開発が本格化してからは、「数万行のコードで動くアプリケーションを数日で実装できた」といった話も珍しくなくなりました。 個人開発や、PoC / MVPのように「まず動くものを作る」局面では、これは素晴らしい武器になります。
ただ、実業務で使うシステム、特にミッションクリティカル度の高いシステム――つまり「止まったら業務が止まる」性質を持つシステムでは、話が少し変わってきます。 たとえAIが書いたコードであっても、動いているコードに責任を持つ人間が必要 です。 トラブル対応や機能追加、バグ修正を現実的な速度で回すには、「なぜ動いているのか」を人間が理解できる状態にしておく必要があります。
5-4. だからこそ「小さくはじめて大きく育てる」が効く
そう考えると、生成AIが短期間で大量のコードを出力できたとしても、それを人間が「正確に」レビューし、運用・保守できる状態に落とし込めるかどうかは、慎重に見極める必要があります。
だからこそ私たちは、生成AIを使う時代になっても、DXの進め方として 「小さくはじめて大きく育てる」 というアプローチは相変わらず有効だと考えています。 まずは小さな範囲で始め、使いながら学び、レビューできるサイズで改善を積み重ねていく。 その結果として、組織に知識が残り、仕組みが育ち、次の投資判断も取りやすくなる。
生成AIは、DXを加速させる強力な道具です。 しかし、道具を使いこなすためには、育つように設計された進め方が必要です。 少なくとも、私たちはそう考えています。
6. まとめ
この記事では、「小さくはじめて大きく育てるDX」が机上の理屈ではなく、現実の現場で機能していることを、2つの事例で実証してきました。
6-1. 5ユーザの小規模開発からスタートし、170名の全社システムへ成長
八光電機様の事例は、5ユーザの物流部門からスタートし、段階的に全社へ広がっていきました。 重要なのは、最初から全社システムを作ったのではなく、成果と学習を積み上げながら、投資対効果の高いものから少しずつ広げていった、という点です。
6-2. 小さな社内ツールがSaaSプロダクトへ昇華
イメージワン様の事例は、社内向けの仕組みとして始まったものが、結果としてSaaSの新規事業にまで育っていきました。 こちらも、最初から完成形のプロダクトを狙ったのではなく、10〜20法人から検証し、うまくいけば完全Webへという段階設計を取りました。
6-3. DXの成功確率を上げる「学習する組織」と「経営者の適切な関与」
この2つの事例を通じて、私たちが改めて強く感じたのは、DXの成否を分けるのは「技術」そのものではない、ということです。 DXを前に進める鍵は、立派なシステムを一気に作ることでもありません。
- 小さく始める
- 自分たちで手を動かし、学習を残す
- 無駄な機能を作らないために、段階的にリリースする
- 内製とアウトソーシングを組み合わせ、属人化のリスクを設計で潰す
- 経営が「土台の意思決定」を担い、ステージ2からステージ3への移行を支える
これらが揃ったとき、DXは「単発のプロジェクト」ではなく、組織の中で育つ仕組みになります。
そしてこれは、生成AIが普及し、AI駆動開発が現実の選択肢になった今でも変わりません。 AIは強力な道具ですが、道具を使いこなすには、学習が残り、レビューでき、責任を持てるサイズで前に進める設計が必要です。
だからこそ、DXは「作る」より「育てる」。 少なくとも、私たちはそう考えています。
