「便利だから作る」が十年後の負債になる――Notes、SharePoint、SAPに共通するシステム延命の罠　※今日は午後休

※複数の事例を混在させ、IT関係のメディア記事も参考にしている。また、わざと実例を変更している箇所があるため、実際の企業のシステムとの一致を目的とはしていない。

企業システムの世界では、「今すぐ作れる」「社内ですでに使っている」「ユーザーが慣れている」という理由が、技術選定を大きく左右する。

もちろん、短期間で業務を改善することは重要だ。現場が困っているのに、何年もかけて理想的なシステムを検討していては意味がない。

しかし、私は複数の製造業で社内システムに関わる中で、目先の便利さを優先した結果、何年も後になって高い代償を支払う事例を見てきた。

そこで起きていたのは、特定の製品だけの問題ではない。

旧来型のグループウェア、社内ポータル基盤、ローコード開発、そして大規模ERP。製品の種類は違っても、失敗の構造は驚くほど似ている。

社内ポータル上に業務システムを作ってしまう

某社では、社内ポータルや文書共有に使われていた基盤上に、顧客から寄せられる製品クレームを管理するシステムを構築していた。

当時は、おそらく次のような判断があったのだと思う。

• 社内ポータルと同じ基盤なので利用者がアクセスしやすい

• 認証や権限管理の仕組みを流用できる

• 社内ですでに利用実績がある

• 新しいパッケージを購入するより安く見える

• 画面やワークフローを柔軟に作れる

一見すると合理的である。

しかし、顧客クレーム対応は、単なる一覧表や文書共有ではない。

案件の受付、調査依頼、原因分析、関係部門への展開、期限管理、承認、顧客への回答、再発防止、過去案件の検索など、多数の業務プロセスが絡む。

製造業の品質保証では、さらに製品、ロット、出荷履歴、設計情報、製造情報などとの連携が必要になる場合もある。

つまり、実際に作っていたのは「社内ポータルの一機能」ではなく、独自の品質・クレーム管理システムだった。

ここで本来必要だったのは、

という検討ではない。

という比較だった。

既存の社内基盤で開発できることと、その基盤が業務システムとして最適であることは、まったく別の話である。

バグなのに追加費用を要求される

そのシステムでは、開発ベンダーが何度も不具合を発生させていた。

社内SEだった私は、かなり強く怒った記憶がある。

特に腹立たしかったのは、明らかに不具合と思われる事象についても、修正には追加費用が必要だという態度を示されたことだった。

もちろん、契約実務は単純ではない。

システム開発では、次の区別が必要になる。

• 合意済みの仕様どおりに動かない不具合

• 当初の要件に含まれていなかった追加要望

• 利用開始後に明らかになった仕様漏れ

• インフラやデータなど、開発物以外に原因がある障害

• 検収後の保守契約に基づく調査・修正

したがって、「バグなら何があっても無償」と一律に言えるわけではない。

しかし、ベンダーが作り込んだ機能に不具合が続いているにもかかわらず、原因説明や再発防止よりも先に追加費用の話を持ち出せば、顧客との信頼関係は壊れる。

しかも、担当者が深刻さを理解していないような態度を見せれば、社内SEの怒りはさらに大きくなる。

社内SEは利用部門から、

「なぜこんなシステムを導入したのか」

と責められる。

一方でベンダーからは、

「修正には追加費用が必要です」

と言われる。

自分がプログラムを作ったわけではなくても、社内ではシステム部門が説明責任を負う。品質への緊張感が感じられないベンダーとの温度差は、非常に大きなストレスになる。

技術選定の失敗は、契約問題にまで連鎖する

この経験から学んだのは、技術選定と契約管理は別々の問題ではないということだ。

適合性の低い基盤上に複雑な業務を構築すると、個別開発が増える。

個別開発が増えれば、仕様書、設計書、テスト項目、例外処理も増える。

そして、業務変更が発生するたびに、

• バグなのか

• 仕様変更なのか

• 当初要件の漏れなのか

• 追加費用の対象なのか

という争いが起きる。

工数精算型の契約で、ベンダー起因の手戻りを非請求とするルールや品質基準が曖昧なら、発注者とベンダーの経済的な利害も一致しにくい。

発注者は、早く安定してほしい。

一方、ベンダーは作業工数に応じて売上が立つ。

ベンダーに悪意があるとは限らない。しかし、契約構造として品質改善へのインセンティブが弱くなる可能性はある。

だからこそ、システム開発では契約時に、少なくとも次を明確にする必要がある。

• 受入基準

• テスト範囲

• 不具合と仕様変更の判定方法

• ベンダー起因の手戻りの費用負担

• 検収後の保証範囲

• 障害調査の費用条件

• 品質指標と再発防止の責任

技術基盤の選定を誤ると、開発難易度が上がるだけではない。調達、契約、品質管理、ベンダー交渉まで難しくなる。

後になってパッケージ中心へ転換する

その企業では、後に従来システムの保守性や変更容易性が問題となり、既製のワークフロー製品を中核にした仕組みへ再構築されたという。

細かい改修にも大きな費用がかかり、入力フォームや承認経路の変更が難しくなっていたためである。

この結末は、「最初から特定のパッケージを選ぶべきだった」という単純な話ではない。

むしろ重要なのは、問題をどのように定義するかである。

当初は「顧客クレーム管理システム」と考えられていたものが、実際には、

だった。

この場合、製品カテゴリとしてCRMか品質管理システムかを考えるだけでは不十分である。

より重要な要件は、

• ワークフローを設定変更できるか

• 入力フォームを柔軟に変更できるか

• 組織変更に追随できるか

• 拠点ごとの承認経路を管理できるか

• 変更のたびにプログラム改修が必要にならないか

という変更容易性だった。

つまり、製品選定では現在必要な機能だけでなく、

を見極めなければならない。

変化の激しい部分を個別プログラムとして固定化すると、小さな業務変更が高額な改修案件になる。

パッケージを使う本当の価値は、単に機能が最初から用意されていることではない。

頻繁に変わる部分を、プログラム改修ではなく設定変更で吸収できることにある。

旧来型グループウェアでも同じことが起きた

某社（別の会社）では、長年利用してきた旧来型グループウェアから、新しい社内ポータル基盤への移行が進められていた。

しかし、私が関わった時点でも、相当数の業務が旧基盤上に残っていた。

旧来型グループウェアは、当時としては非常に便利な製品だった。

• メール

• 掲示板

• 文書共有

• データベース

• 入力フォーム

• ワークフロー

• 簡単なスクリプト開発

これらを一つの基盤で扱えた。

専用のシステムを一から調達しなくても、部門の担当者や社内SEが比較的気軽に業務アプリを作ることができた。

だからこそ、アプリが乱造された。

中には、設計書がほとんど存在しないものも多かったのではないかと思う。

作成当初は、数人で使う簡単な台帳だったのかもしれない。

しかし、長年使われる中で、承認、通知、集計、権限、他システム連携などが追加され、いつの間にか業務に不可欠なシステムになっていく。

それでも、

• 要件定義書がない

• 設計書がない

• テスト仕様書がない

• 作成者が退職している

• 業務責任者が不明

• どの処理が必要なのか説明できない

という状態が残る。

これは、シャドーITが時間をかけて基幹業務化した状態である。

移行プロジェクトが「業務の考古学調査」になる

設計書のない業務アプリを新基盤へ移すのは容易ではない。

単にデータや画面をコピーすればよいわけではないからだ。

フォーム、スクリプト、アクセス権、通知、バッチ処理などを調べ、実際に利用者へ聞き取りを行い、業務仕様を逆算しなければならない。

さらに、移行時には次の判断が必要になる。

• その業務は今も必要か

• 全社標準業務へ統合できないか

• ERPやSaaSへ移せないか

• 新しいポータル基盤で再構築すべきか

• 単なる文書保管に縮小できないか

• 廃止しても問題ないか

こうなると、移行プロジェクトというより、企業内に埋もれた業務を発掘する考古学調査に近い。

しかも、古い基盤の保守が継続されていると、移行を延期することもできてしまう。

「まだ動いている」

「製品サポートも続いている」

「業務は止まっていない」

「今年は予算がない」

こうして移行が先送りされる。

しかし、その間にも設計者は退職し、利用者の記憶は薄れ、移行難易度と費用は上がっていく。

製品サポートの継続は、時間を与えてくれる。

だが、企業独自のアプリの設計書を作り直したり、業務を標準化したりしてくれるわけではない。

保守継続は救命措置にはなるが、根本治療にはならない。

古い基盤から新しい基盤へ移すだけでは解決しない

旧来型グループウェアのアプリを、現在の社内ポータルやローコード基盤へそのまま再構築すれば、問題は解決しない。

負債を別の製品へ引っ越しただけである。

旧アプリのフォームやワークフローを忠実に再現し、再び設計書を作らず、担当者任せで改修を続ければ、十年後には新基盤でも同じ問題が起きる。

これは、現在のローコード・ノーコード開発でも十分に起こり得る。

• SharePoint Lists

• Power Apps

• Power Automate

• Excelマクロ

• Access

• 各種ノーコードツール

• 生成AIで作成した小規模アプリ

技術の進歩によって、「動くもの」を作るのは以前より簡単になった。

しかし、

• 誰が責任者なのか

• 仕様はどこにあるのか

• データの正本は何か

• 障害時にどう復旧するのか

• 担当者の退職後も保守できるのか

• いつ廃止するのか

という問題は、技術だけでは解決しない。

むしろ、簡単に作れるほど統制が重要になる。

SAP ECCの延命も同じ構造である

この「延命によって問題が継続する」という構造は、大規模ERPでも同じである。

SAP ECCを長年利用してきた企業では、標準機能だけでなく、大量の独自開発が蓄積されている。

• 独自帳票

• 独自インターフェース

• 独自バッチ

• 独自承認

• 過去の組織事情に基づく例外処理

• 現在は使われていないプログラム

• 誰も理由を説明できない設定

S/4HANAへの移行では、本来、こうしたアドオンを棚卸しし、廃止、標準化、再設計することが望ましい。

しかし、現実には期限がある。

大規模な基幹システムで、アドオン整理、業務改革、データ整理、海外展開を同時に実施すれば、プロジェクトの規模とリスクは急激に膨らむ。

そのため、期限内の移行を最優先し、既存業務やアドオンをできるだけ維持したまま、ストレートコンバージョンに近い方法を選ぶ企業もある。

これは必ずしも間違いではない。

むしろ、期限と業務停止リスクを考えれば、現実的な判断である場合も多い。

問題は、移行後である。

この二段階目が、本当に実施されるかどうかが重要になる。

ストレートコンバージョンは敗北ではない

アドオンを整理しないまま新ERPへ移すことを、単純に失敗と評価するのは正しくない。

期限が迫っている中で、理想論を追求しすぎれば、

• 要件定義が終わらない

• テスト範囲が膨張する

• 業務部門の合意が取れない

• データ移行が間に合わない

• 稼働延期や業務停止が起きる

可能性がある。

したがって、

第1段階

まず新基盤へ安全に移行する。

第2段階

稼働後にアドオン、業務、インターフェースを整理する。

という戦略は合理的である。

ストレートコンバージョンは、負債の解消ではなく、負債を返済するための時間を買う戦略と考えるべきだ。

しかし、多くの企業では、第2段階が実行されない。

稼働後は障害対応、新規要件、海外展開、法改正、組織変更などに追われる。

そして、

「今動いているものを、なぜ改修する必要があるのか」

と言われる。

予算も人員も付かず、旧ERPの負債が新ERPへそのまま引き継がれる。

その結果、技術名称だけが変わり、システムの複雑性は残る。

これは、旧グループウェアのアプリを新しいポータルへそのまま移すのと同じである。

延命が悪いのではない

保守延長やストレートコンバージョンそのものが悪いわけではない。

無理な期限で全面刷新を行い、大規模障害を起こすより、時間を買う方が合理的な場合もある。

重要なのは、延命期間や移行後の期間を何に使うかである。

良い延命では、時間を使って次を進める。

• システムとアプリの棚卸し

• 利用実績の確認

• 不要機能の廃止

• 業務標準化

• マスタとデータの整理

• パッケージやSaaSへの置き換え

• インターフェースの簡素化

• 設計書とテスト証跡の整備

• 保守責任者の明確化

悪い延命では、古い基盤に新しい機能を追加し続ける。

「移行は数年後に考える」と言いながら、負債を増やし続ければ、将来の移行はさらに難しくなる。

保守契約は時間を買ってくれる。

しかし、技術的負債や業務上の負債を返済してくれるわけではない。

便利な基盤を使うために必要なルール

旧来型グループウェアも、SharePointも、ローコード製品も、SAPも、決して悪い製品ではない。

むしろ優れた製品だからこそ、多くの業務を載せることができた。

問題は、適用範囲と出口戦略を決めずに使ったことである。

新しい業務アプリを作る場合は、最低限、次を確認すべきだ。

1．本当に独自開発が必要か

既存のERP、CRM、QMS、ITSM、SaaS、パッケージで対応できないかを先に検討する。

2．作れるかではなく、作るべきかを問う

社内標準基盤で開発できることを、選定理由の中心にしない。

3．将来の変更箇所を見極める

頻繁に変わるフォーム、ワークフロー、組織、権限は、プログラムではなく設定で変更できるようにする。

4．設計書を必須にする

小さなアプリでも、目的、責任者、データ項目、業務ルール、権限、連携先を記録する。

5．システム台帳へ登録する

誰が作成し、誰が利用し、誰が保守し、いつ見直すのかを管理する。

6．廃止条件を決める

作成時点から、利用期限、見直し時期、データ移行方法を決めておく。

7．契約上の品質責任を明確にする

不具合と追加要望の線引き、受入基準、無償修正範囲を曖昧にしない。

8．移行後の負債返済を予算化する

期限対応で負債を持ち越す場合は、稼働後の整理を正式なプロジェクトとして計画する。

「便利だから」は選定理由として弱い

企業システムでは、短期的な便利さが重視されやすい。

既存のライセンスが使える。

社内の利用者が慣れている。

すぐに画面が作れる。

申請フローを簡単に実装できる。

しかし、システムは一度業務に組み込まれると、簡単には廃止できない。

数日で作ったアプリが、十年後も使われているかもしれない。

作成者が退職した後も、誰かが保守しなければならない。

製品のサポートが終了すれば、別の基盤へ移さなければならない。

その時、設計書も責任者も分からなければ、企業は過去の便利さに対して高額な請求書を受け取ることになる。

私は複数の企業システムを通じて、この構造を実際に見てきた。

それは確かに高い勉強代だった。

しかし、その経験から得た教訓は明確である。

目先の便利さは、決して無料ではない。

その代金は、十年後の移行プロジェクトで支払うことになる。