介入事例
以下は守秘範囲で公開可能な介入事例です。企業名・固有名詞は伏せていますが、構造的な問題と介入の手順はそのまま記載しています。「うちと同じだ」と感じた項目があれば、それは偶然ではありません。
医療法人──人事・給与システム移行（2024年）
病院2施設＋約80事業所、職員約2,200名の社会医療法人。人事システムを奉行からSmartHRへ切り替え、給与計算は給与計算システムに外注する体制へ移行する計画だった。
連携境界が6ヶ月間未定義。毎月の定例で同じ議題が蒸し返される
SmartHRと給与計算システムの間で「どちらがどのデータを持つか」が決まらなかった。人事部門は「SmartHRに入れたから給与計算システムが取りに来るだろう」、給与計算システム側は「SmartHRの仕様変更が頻発するため、ぎりぎりまで対応できない」。結果として、データが届くまで仕様が不明であり、届いてから急ピッチで変換処理を組む綱渡りが常態化していた。
さらに、事業所ごとの社会保険料支払い帳票の生成など監査対応に必要なデータ連携も宙に浮いており、「誰がデータの正を持つか」を誰も決めないまま半年が経過していた。
「？」の部分が6ヶ月間、未定義のまま放置されていた。
責任境界の確定とAPI連携の出口戦略設計
まず「SmartHRで管理すべきデータ」と「給与計算システムで管理すべきデータ」を業務フロー上で明確化した。「どちらが正」かではなく、「どちらに書き込み権限があり、どちらは参照のみか」という一方向のルールに落とした。
次に、SmartHR側の仕様変更が頻発する前提で、データ到着ベースの即時構築──届いたデータの構造を見て変換処理を組む──を設計。仕様確定を待たずに動ける構造にした。
加えて、各部門の責任者に「この項目はあなたの部門が確定する」「この項目の不整合はこちらにエスカレーションする」というルールを文書化し、合意を取得した。
各ボックスの責任者と、不整合時のエスカレーション先を文書化。
追加開発費を2/3圧縮し、予定通り本稼働
問題は「技術」ではなかった。SmartHRもEcomicも正常に動いていた。止まっていたのは「誰がデータの正を持つか」という責任の定義だけだった。システムを変えなくても、責任境界を1枚の文書にするだけで、半年間の堂々巡りが4週間で終わった。
以下に心当たりはありませんか？
- クラウドサービス間の連携で「どちらがデータを持つか」が決まらない
- 外注先（BPO・SaaS）に丸投げしたが、不整合の責任を誰も負っていない
- 定例会議で毎回同じ議題が蒸し返され、決定事項が残らない
- 「仕様が変わるから」を理由に、いつまでも設計が確定しない
製造業──基幹システム移行の迷走と止血（2020〜2024年）
1,200名規模の製造事業部。AS400ベースの基幹システムと、DB2・Oracle・Accessが混在する部門システムの保守切れが迫っていた。
3年間で要件定義すら完了しなかった
管理者主導で「3年で移行完了」の計画が立てられた。しかし、PMの立場にいた管理職はシステム管理の経験がなく、以下の問題が連鎖的に発生した。
DB2かMS SQLかの議論が蒸し返され、DBの選定すら確定しない。部門システムの解析を試みるもスパゲッティ状態と判明し早々に塩漬け宣言。外部ベンダーに発注した別事業部の話を聞いて「内製は無理」と発言するも、後日「ハイブリッドで」と方針転換。スタートアップやコンサルとの面談で開発言語の議論にまで話が広がり、これまでの資産や経緯を無視した方向性が乱立した。
さらに、本社部門のシステム管理が解体され人員が各事業部に割り振られたことで、200本超のRPGプログラムの保守責任が宙に浮いた。保守者の定年退職も迫っていた。
5種類のDBが混在。移行先のDB種別すら3年間確定しなかった。
WebAPIによる疎結合設計──「DB側が何に変わっても壊れない構造」の実装
DB選定の議論が終わるのを待っていたら永遠に開発できない。そこで、DBへのアクセスをプログラムから完全に切り離す設計を選択した。WebAPIで抽象化すれば、DB側が何に変わっても、API側で変更を吸収できる。
具体的には、SQLのハードコーディングを禁止し、DBコネクションをAPI側で吸収する構造を実装。これにより、サーバー側を任意のタイミングで更新しても、クライアント側に改修が発生しない構造を担保した。
並行して、設定定義により異なるDB（Oracle、SQLite等）を共通インターフェースで利用可能にする「金型」を開発し、事業部内へ配布。高額投資による全置換を回避し、次世代システムへの退路を確保した。
DB側が変わってもクライアント側は改修不要。「不確定な環境下で唯一破綻しない構造」として選択。
保守2名体制のまま全社リアルタイムアクセスを実現
「どのDBにするか」を決めることが目的化し、3年間誰も動けなかった。問題は技術選定ではなく、「決まらない前提でも動ける構造を誰も設計しなかった」こと。WebAPIという選択は「技術的に洗練された選択」ではなく、不確定な環境下で唯一破綻しない構造として消去法で残った。
全置換を待つのではなく、今ある環境で今止まらない構造を引く。それが止血の本質。
以下に心当たりはありませんか？
- 基幹システムの移行計画が「検討中」のまま1年以上経過している
- DBやプラットフォームの選定が堂々巡りになっている
- 保守担当者の退職が近づいているのに、引き継ぎ先が決まっていない
- 野良Access・野良VBA・野良RPGが乱立し、全体像を誰も把握できていない
- 「全面刷新」の号令は出たが、要件定義が終わる気配がない
- 外部ベンダーに発注すべきか内製すべきかの判断が先送りされている
医療法人──クラウド型請求書受領サービス導入（2024年）
職員約2,200名、大小80事業所を抱える医療法人。経理グループは8名。請求書は郵送・社内便・事業所内回覧を経て届き、仕訳入力は毎月数日がかりの手作業だった。クラウド型請求書受領サービスの導入で効率化を図る計画だったが、事前打ち合わせ＋見積もりが決裁待ちのまま塩漬けになっていた。
値引き交渉で急発進──3ヶ月で運用開始目標。しかし準備ゼロ
取引先からの値引き交渉をきっかけに急遽契約が成立。3ヶ月で運用開始という期限が決まった。しかし、以下が全て未整備だった。
取引先の一覧が存在しない。各エリアの担当者や事業所が独自に契約しており、全社で何社と取引しているかすら把握できていなかった。なんとか一覧を作成したものの住所・正式名称が不明。幸いにもインボイス番号があったため、国税庁APIを申請──しかし間に合うかどうか怪しかったため、各APIを組み合わせて自力で取得した。
請求書受領後の処理が丸投げ。ベンダーは伴走型支援を謳っていたが、原則としてデータには触らない。それだけではなく、各システムへの繋ぎ込み──経理ソフトへのデータ連携──についてもシステム面のサポートは一切なし。「ヘルプサイトで確認を」との回答だった。400社超の取引先×100名のユーザーの組み合わせ、各事業所の配置、仕訳コードの生成、経理ソフトに読み込める仕様への変換──すべて自前で対応する必要があった。
唯一の救いは、ベンダーが進捗管理を担ってくれたこと。「何をいつまでに」という部分が第三者に移ることで、社内だけでは生まれなかった期限意識が芽生えた。同じ部署・同じ会社の中だと「忙しくて」という言い訳が通ってしまう。外部の目があるだけで「いつまでになんとかしよう」に変わる。結果的に当初の3ヶ月目標から1ヶ月延期となったが、進捗管理がなければ動き出しすらしなかった可能性が高い。
経理グループの本音は「現状維持」。新しい仕組みを理解する手間と、これまで通り手入力で作業する手間を天秤にかけ、クラウドに移行しても結局手入力で現行の仕組みを使いたいと考えていた。それぐらい、移行に必要なことの整理ができていなかった。
ベンダーは「伴走型」だがデータに触らない。「？」は全て自前対応が必要だった。
取引先マスタの自力構築＋仕訳変換パイプラインの設計＋エラー検証ルールの確立
まずインボイス番号を起点に国税庁API＋複数APIを組み合わせ、400社超の取引先マスタ（正式名称・住所・仕訳コード紐付け）を構築した。
次に、クラウドサービスからの出力データを経理ソフトに読み込める仕様に変換するパイプラインを設計。事業所配置×取引先×仕訳コードの組み合わせルールを定義し、手入力ではなくデータフローとして処理が回る構造を作った。
最も重要だったのは検証のコンセンサス。切り替え初回、一気に仕訳データを流し込んだ際に100件超のエラーが発生した。ここで各担当者が各自で勝手に修正したため、エラーログが残らなくなった。
そこで「手修正が必要な境界」──このまま取り込むとエラーになる箇所──を明確に定義し、エラーを潰すのではなく、エラーを積み上げて構造的に潰す検証プロセスを確立した。
「エラー0件」ではなく「何件のエラーを未然に防いだか」を可視化。実務担当の貢献が数字で見える。
当初3ヶ月目標→1ヶ月延期で運用開始。経理の仕訳入力を数日→即日処理に転換
クラウドサービスは入った。ベンダーもいる。しかし「データの前処理と検証ルール」が丸ごと空白だった。ベンダーの「伴走型支援」は、データにもシステム連携にも触らない以上、仕訳変換からエラー対応まで全て自前で設計する必要がある。
一方で、ベンダーが進捗管理を担ったことで「いつまでに何を終わらせるか」の期限が機能した。同じ組織の中では「忙しい」で先送りできることが、第三者がいると先送りできなくなる。外部の介入が効くのは技術だけではない。「期限と責任を逃げられない状態にする」だけでも、プロジェクトは動き出す。
もう一つ。エラーを「ゼロにする」ことを目標にすると、各担当が勝手に修正してログが消える。エラーを「未然に防いだ件数」として可視化・価格化すると、実務担当は「自分たちがいくらの事故を防いでいるか」が分かり、作業の意味が変わる。モチベーション設計は技術ではなく、見せ方の設計。
以下に心当たりはありませんか？
- クラウドサービスを契約したが、データの前処理は「現場でやって」状態
- ベンダーの「伴走型支援」が、実際にはデータに触らない契約だった
- 取引先マスタや仕訳コードの整備が終わらないまま運用開始が迫っている
- 移行したのに現場が「結局手入力の方が早い」と旧来のやり方に戻りかけている
- エラーが出ても各自が勝手に直し、何が原因だったか追跡できない
- 経理や事務部門の貢献が「数字」で見えず、改善のモチベーションが上がらない
3件の事例に共通するのは、問題がシステムではなく「誰が・何を・いつまでに決めるか」と「検証のルール」が未定義だったことです。
この構造は、システムを変えても、ベンダーを変えても、解決しません。
まずは無料診断で、御社の「未定義箇所」を特定します。