総務システム開発/導入の失敗/課題/注意点/リスクについて

総務システムの失敗は、導入後に表面化する課題、契約やコストの問題、現場の形骸化など、導入の前後にわたって起こります。業務設計や契約条件、現場への定着、運用管理、発注準備を整えておくと、こうした失敗は防ぎやすくなります。

失敗の全体像は、総務システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・総務システムの完全ガイド

導入後に表面化する典型的な課題

導入後に挙がった3つの課題と割合を並べた図。
情報管理と業務の分断が上位に並びます。

総務システムの課題は、導入時よりも運用が始まってから表面化することがあります。調査では約8割の企業が、導入後に何らかの課題を感じていました。どんな課題がどれくらい起きているかを知ることが、リスクを避ける第一歩になります。

情報の一元管理の不足と業務の分断

導入後に起きやすいのは、情報を探しにくくなることと、作業の手間が増えることです。

  • 情報の分散:必要な情報が一か所にまとまらない
  • 業務の分断:複数の仕組みを行き来しながら進める処理

調査では、情報を一元管理できない課題が39.5%で最も多く、システム間で業務が分かれることによる非効率が38%でした。

たとえば、契約書はAのシステム、申請履歴はBのシステム、文書はCの共有フォルダに分かれることがあります。そうなると、どこに何があるか分からず、総務への問い合わせも減りません。また、業務の一部だけが電子化され、残りが紙や別システムに残ると、二重運用になって担当者の手間が増えます。

情報の分散や業務の分断を避けるには、導入前に総務業務全体のつなぎ方を設計し、部分ごとにツールを入れないようにします。

紙データが処理されないまま残るリスク

導入前に溜まった紙データの扱いを決めておかないと、新しいシステムに過去の情報を集約できません。

  • 移行の優先順位:検索頻度の高い重要契約から取り込む
  • 検索用の情報:契約日、取引先、更新期限など、検索に使う項目を残す

同じ調査で、導入前の紙データが処理されていない課題は33.6%に上りました。移行の方針がないと、新しく発生した分だけが電子化され、過去の契約書や規程は紙のまま残ることがあります。

過去の契約を探すのに紙の束をめくることになり、一元管理の効果が半減します。すべての紙を一度にスキャンするのは現実的ではないので、導入時に紙データの移行計画を立てておきます。

メタデータを付けずにスキャンしただけでは、後から検索できません。そのため、紙データの扱いは先送りせず、移行計画に組み込んでおくことが大切です。

ポイント

情報の所在、業務をまたぐ流れ、紙データの移行は、導入前に決めておきます。どれか1つでも決まっていないと、運用が始まってから課題が表面化しがちです。

契約・コスト面のリスクと注意点

総務システム、とくに契約の電子化には、自社だけでは制御しにくいリスクと、料金体系から生じる費用のリスクがあります。事前に把握しておけば備えられます。ただし、運用が軌道に乗った後で表面化する問題もあります。

取引先の同意が得られないリスク

契約の電子化で典型的なリスクは、取引先の同意が得られないことです。紙の押印にこだわる場合や、社内規則で電子契約が認められない場合は、紙で進めざるを得ません。

  • 相手方の負担:立会人型を中心に検討する
  • 運用の備え:紙と電子の併用を想定した運用設計
  • 対象契約:電子化できる契約と、できない契約の切り分け

たとえば、当事者型の署名方式では、相手方に電子証明書の発行費として1万円前後の負担を求めるため、合意のハードルが上がります。

電子化の利点を丁寧に説明して理解を得ます。それでも応じない取引先が残る場合は、その取引先とのやり取りを、紙のまま続ける前提で考えます。

定期借地契約や任意後見契約など、法律で書面が義務づけられた契約は電子化できません。そのため、対象範囲を見極めたうえで、紙で扱う契約の運用も整えておきます。

想定外の従量課金で費用が膨らむリスク

見落としやすいのは、従量課金で費用が膨らむリスクです。電子契約は、月額の基本料に送信料が加わる料金構成が一般的で、送信料は1件あたり50〜300円です。

  • 比較の基準:導入直後より定着後の件数で試算する
  • 料金体系:送信課金型と送信無料型の違い

固定費が無料で送信課金のプランは、導入初期の件数が少ない間は割安に見えます。一方で、利用件数が増えると費用が膨らむことがあります。

件数ごとに見ると、送信課金型は件数が増えるほど費用が上がるのに対し、送信無料型の費用は一定に保たれます。このため、月5件・50件・200件など複数のシナリオで比べ、運用が定着した後も無理のない体系を選びます。

件数が今後増える見込みなら、固定費は高めでも送信無料のプランが有利になることがあります。目先の安さだけで決めず、将来の件数も考えに入れます。

ポイント

取引先の同意、従量課金の試算、電子化できない契約の扱いを、契約の前に一度に確かめておくと、運用が軌道に乗った後の想定外を減らせます。

現場で使われず形骸化するリスク

承認ルート、段階的な導入、経営層の後押しを示すチェックカードの図。
仕組みの設計と社内の後押しをそろえます。

総務システムの失敗のなかで最も根深く避けたいのは、現場で使われず形骸化することです。高機能なシステムでも、現場が紙やExcelに戻ってしまうことがあります。その背景は人と運用の問題なので、対策もそこに踏み込む必要があります。

承認ルートの作り込みすぎ

形骸化の典型例は、複雑な承認ルートをそのまま再現して、誰も使えないシステムにしてしまうことです。

  • 現状の把握:導入前に承認ルートを一覧にする
  • ルートの見直し:必要な承認だけを残した簡素なルート

申請は金額や部署によって承認者が変わるため、条件分岐が多くなりがちです。作り込みすぎると、申請者はどこへ提出すればよいか迷います。また、承認者も、自分に申請が回ってきた理由を把握できず、メールや口頭での依頼に戻ることがあります。

まず現状(AsIs)を確認し、冗長な承認や不要な合議を整理します。そのうえで、あるべき姿(ToBe)を設計します。

ルートを簡潔にすると、現場は迷わず使えるようになります。また、業務を見直す機会と捉えることが、形骸化を防ぐ要点です。

定着支援の不足と運用ルールの未整備

導入後の定着(チェンジマネジメント)を支援しないと、現場は使い方が分からず、従来の方法に戻ってしまうことがあります。取引先への説明を扱う記事は多い一方で、自社内の定着手順は十分に語られないことがあります。

  • 段階的な導入:効果の大きい申請から始める
  • 利用環境:誰が何をできるかを定める
  • 社内支援:問い合わせ窓口の用意

権限設定が放置されたまま、承認ルールや社内マニュアルもない状態だと、現場は混乱し、システムを使いにくくなります。そこで、一部の申請から始めて、現場が便利になったと実感できる小さな成功を重ねてから、対象を広げていきます。

riplaは、フルスクラッチ受託と業務伴走の立場から、総務業務を起点にToBeを設計し、導入後の定着支援も重視しています。

経営層の関与不足と二重運用の放置

経営層が電子化を全社方針として示さないと、各部門は従来の運用を変えようとせず、新システムが一部でしか使われないことがあります。

  • 経営層の後押し:電子化を全社方針として伝える
  • 移行方針:紙の併用期間の区切り

最終決裁者の役員が紙にこだわると、現場も電子化を進められず、紙とシステムの二重運用が残ります。紙と電子の二重運用を放置することも、形骸化につながる典型的な失敗です。移行期間を決めないまま併用を続けると、現場が紙へ戻り、システムの利用が進まなくなることがあります。

このため、移行期間の後は原則として電子に一本化する方針を明確にしておきます。形骸化を防ぐには、技術面だけでなく、経営層を巻き込んだ全社的な変革が必要です。

ポイント

承認ルートが現場の負担になっていないか、運用ルールと問い合わせ窓口が整っているかが、形骸化を防ぐ目安になります。紙と電子の二重運用が続いていないかも、判断の材料になります。

見落とされがちな運用リスク

導入直後の課題が落ち着いた後も、情報の鮮度低下、権限の放置、シャドーITなどの問題が起こることがあります。長く使うシステムだからこそ、運用リスクを継続して確認していく必要があります。

権限放置と情報の鮮度低下

アクセス権限と登録情報を定期的に見直さないと、退職者のアカウントや古い規程が残り、運用上のリスクになります。

  • 権限の棚卸し:不要なアカウントや過剰な権限を洗い出す
  • 情報の更新:見直しの責任者と頻度を決めておく

異動や退職の後もアカウントが有効だと、契約書や人事文書にアクセスできる状態が残ります。それが情報漏えいにつながり、監査で指摘されることもあります。

登録した規程やひな形を更新しないと、古い版を最新版と思い込んで、誤った情報のまま業務を進めるおそれがあります。更新漏れを防ぐには、バージョン管理に加えて、誰がいつ見直すかを運用ルールに定め、情報を最新に保つ必要があります。

シャドーITとAI機能への過信

使いにくいシステムは、現場が別のツールやチャットで申請を回すシャドーITの一因になります。

  • シャドーIT:現場の声を拾い、仕組みを改める
  • AI機能:人による最終確認の継続

公式システムの外で承認や情報共有が行われると、証跡が残らず、ガバナンスが崩れてしまいます。そのため、こうした動きが起きたら、まず現場のニーズを確認します。

AI-OCRやAI契約レビューは、標準機能に含まれるか、月額数万円の追加オプションかによって費用が変わります。また、読み取りの誤りにも注意が必要です。

AIの内容や指摘を鵜呑みにすると、誤ったデータや見落としが業務に紛れ込みます。運用リスクを継続して見直しつつ、AIの結果は最後に人が確かめることで、システムの価値を保てます。

ポイント

権限と登録情報の見直しを誰がいつ行うかを決めておくかどうかで、運用リスクの大きさは変わります。AI機能は、人が最後に確かめる前提で使います。

ベンダー選定と発注の進め方による失敗

現場の聞き取りから現状とあるべき姿を整理し、RFPにまとめる流れの図。
要件の整理が、提案の方向を定める土台になります。

導入の進め方、とくにベンダー選定や発注を誤ると、現場に合わないシステムができあがることがあります。発注側が判断を誤りやすい点を先に知っておくことが、失敗の予防につながります。

要件を固めずベンダーに丸投げする失敗

発注段階の典型的な失敗は、自社の要件を固めないまま開発をベンダーに丸投げすることです。「総務をデジタル化したい」という依頼のままでは、業務の実態に沿った提案を得にくくなります。

  • 業務の可視化:現場の聞き取りで現状(AsIs)を洗い出す
  • 要件の言語化:あるべき姿(ToBe)をRFPの形にまとめる

業務フローや商習慣に合わない仕組みは、現場に使われないまま放置されることがあります。投資額が大きくても、要件が曖昧なままでは定着しません。

前提となる業務の流れを押さえてからRFPにまとめると、ベンダーは提案の方向をつかめます。工数を見積もれる粒度まで具体化しておくと、提案を比べやすくなります。さらに、見積もりの妥当性も判断できます。

失敗を分けるのは、技術力や予算よりも、発注側が要件を固められるかどうかです。現場の業務を言葉にしたうえで要件を固めることが、丸投げを防ぐ要です。

失敗を避けるためのチェックポイント

これまでの失敗や課題を踏まえ、発注前には業務設計と移行の準備状況を確認します。契約や費用、導入後の運用は、下に挙げた項目で確かめます。

  • 業務・データ:全体設計、承認ルート、紙の移行の確認
  • 契約・費用:電子化の範囲と定着後の件数を見積もる
  • 運用・体制:定着支援、権限、規程の見直しを決める

承認ルートが複雑なまま発注すると、導入後に使われない原因になります。また、紙データの移行計画がないと、過去の契約が紙に残り、一元管理の効果が半減します。

契約面では、取引先の同意や電子化できない書面の扱いも、発注前に検討しておきます。従量課金は、運用が定着した後の件数で試算しておきます。また、導入後の定着支援や、権限・規程を定期的に見直す方法も決めておきます。

調査では約8割の企業が導入後に課題を感じていました。そのため、確認項目を丁寧に押さえておくと、失敗の確率を大きく下げられます。

riplaは、フルスクラッチ受託と業務伴走の立場から、発注前のToBe設計と、導入後の定着・運用支援を一貫して提供しています。

ポイント

発注前に、現場の業務を言葉にして要件をRFPにまとめられているかが、ベンダー選定の成否を左右します。契約や費用、導入後の体制まで含めて、準備が整っているかを見ておきます。

まとめ

導入がうまくいけば、申請処理を約4割削減できます。契約電子化では年間約96万円のコストを削減できる一方で、システムが定着しない場合もあります。

導入後の課題には、情報を一元管理できないこと(39.5%)、業務が分断されること(38%)、紙データが処理されないこと(33.6%)があります。

取引先の同意や従量課金、形骸化は、見落とせないリスクです。運用の中では、権限の放置や情報の鮮度低下、シャドーITも起こり得ます。AI機能への過信にも注意が必要です。

業務全体を設計し、承認ルートを簡素にし、紙データの移行計画を立てることで、多くの課題を防げます。定着支援と運用ルールの整備も、課題を防ぐ助けになります。

成否を分けるのは、機能の多さよりも、現場の業務と運用に合う設計かどうかです。導入後に課題を感じた企業が約8割いる点を踏まえて、効果の大きい業務から始めます。

riplaは、ToBe設計から定着・運用支援までを提供しています。また、全体像の確認には、総務システムの完全ガイドをご活用ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。