パッケージシステムの導入でユーザー側が心掛けるべきこと
【本記事は会計系 Advent Calendar 2023における9日目のエントリーです】
システム導入に失敗してしまう確率は、5割とも7割とも言われています。
失敗の原因ばかりがよくネットの記事で取り上げられ、成功に導くポイントと題した記事といえば、やれ「トップダウンで進める」だとか「目的を明確にする」だとか「全社員を巻き込む」なんて当たり障りのない文章が載っているだけなのが気掛かりです。
今回は、職場でシステムの導入や入替えを予定している、右往左往する経理部の方々へ少しでもヒントになれたらいいなと思い、記事にしました。
心がけるべきこと。
１．営業のトークに惑わされない。デモで徹底的に分析しよう。
2．アドオン開発は最低限にしよう。
3．データ移行は意外と奥が深い。
4．ユーザー側もデータベースの知識があると、導入が楽になる。
システム選定編
１．営業のトークに惑わされない。デモで徹底的に分析しよう。
1-1. 業務の棚卸、要求事項の明確化
社内で経費精算システムを刷新することになったとします。
最初にやることといえば、市場に出回っているベンダー各社の資料を取り寄せる作業だと思いますが、ここで注意してください。資料を取り寄せた翌日か翌々日には、ベンダーから営業電話がかかってきて、猛烈な営業トークの後にデモの日程調整を要求してきます。
これは、ベンダー側のレスポンスが良いと捉えることもできますが、狙いとしてはシステムのメリット・デメリットを考える暇をユーザーに与えず、競合他社よりも先にさっさと契約を結んでしまおうという算段です。
ベンダー側のペースに乗らず、現行の業務フローをしっかりと棚卸しを行って、システムの機能で絶対に外せないポイント、削ってもいいポイント、今困っているポイントなどを整理してからデモに臨むのがコツです。
経費精算システムに求める機能は、例えば以下のようなものが挙げられるでしょう。
ワークフローによる申請・承認機能があるか
クレジットカードや交通系ICカードと連携できるか
インボイス制度、電子帳簿保存法に対応しているか
AI-OCRで領収書を自動読み取りできるか
操作性が良いか
プロジェクトコードや製品コードをタグ付けできるか
会計システムと容易に連携できるか
これらの機能の中には、営業資料を見ればわかるものもあれば、実際に操作してみないと分からないものもあります。
例えば操作性は、ショートカットキーの有無や画面遷移の設計によっては、業務に掛かる時間がぐっと短縮されるかもしれません。また、タグ付けや連携などは、自社の業務フローやシステム環境に合わせてパラメーター調整できるかどうかが重要です。
デモの時間では、事前に自社の要求する機能を明確にしておいて、それらが満たされているかどうかを確認する時間にしましょう。
もし、デモの時間だけでは結論が出せなかった場合は、トライアルの用意がないかベンダーに確認しましょう。
1-2. 評価表
ここで、システム選定のための評価表を紹介します。
上記の例は、縦軸に候補となるシステム（選択肢）、横軸に重視する点（評価項目）を並べます。評価項目と選択肢の数は任意です。
各評価項目には、その重要度を示す重み（wait）を付けます。また、選択肢に対して、各評価項目ごとに評価点を付けます。重みと評価点は、計算しやすいように５段階評価もしくは１０段階評価が一般的です。
重みと評価点の積である相対点を求め、各選択肢の合計点を比較することで、各社システムの優劣を判断します。
表を見ると、A社製のシステムが最も高い合計点を得ており、採用したいところです。しかし、これは絶対ではありません。なぜなら、当社が最も重要視している評価項目は「求める機能との適合性」であり、この項目ではA社製のシステムよりもC社製のシステムの方が優れているからです。
このように、最終的には合計点だけでなく、各評価項目の重みも考慮に入れて、A社製かC社製かを慎重に選ぶ必要があります。
システム導入編
2．アドオン開発は最低限にしよう。
2-1. アドオン開発のリスク
ERPパッケージの導入では、よくアドオン開発が話題になります。ERPの標準仕様では現行の業務フローに合わせることができない点について、ユーザーの要望で追加機能を実装し、対応してしまおうという話です。
しかし、あらゆるWebサイトや書籍で「アドオン開発はやらない。もしくは最低限にするべき。」と解説されているでしょう。
日経コンピュータ（日経BP社）の「『動かないコンピュータ』裁判を読み解く」（2016年10月13日号）で取り上げられた、請求額が1億円を超えるIT訴訟11件のうち、実に8件が追加の開発に関わるトラブルが原因だったそうです。
アドオン開発があれば開発工数が膨れ上がり、導入期間が長期になりがちで、かつ、余計にコストが嵩みます。また、不具合が発生する危険性が高くなるでしょう。
そもそも、今のパッケージは昔のパッケージと違い、安易にカスタマイズすべきものではないのです。
【1980年代のパッケージ】
・どこかの会社用に開発したものをテンプレート化してパッケージと称していた
・パッケージのソースコードは原則ユーザーに提供された
・ユーザー企業もしくはソフト会社（販売店）が自由にカスタマイズが可能だった
・パッケージベンダーがサポート停止しても利用可能だった
・パッケージソースコードは買取が基本で、ソフト保守という概念はなかった
・バージョンアップはほとんどなかった（当時のOSは上位互換を保証していた）
個別のカスタマイズが前提
【現在のパッケージ（ERPほか）】
・ベンダー独自の設計思想に基づき開発されている
・パッケージのソースコードは非公開で、ブラックボックス化されている
・カスタマイズはベンダーしかできない（アドオンも制限有）
・パッケージベンダーがなくなったり、サポート停止すると原則的に継続利用は難しくなる
・ソフト保守料が必要（ソフト保守の内容はあいまいなことが多い）
・ベンダー都合やOS対応のバージョンアップがあり、莫大な対応費用がかかることもある
ノンカスタマイズが前提
日刊工業新聞社. 2023, p161.
昔はソフトは買い切りで、ユーザーもソースコードを見ることができたところ、現在はアドオン開発はベンダーにお願いするしかなく、非常にリスクが高くなっています。
アドオン開発をするにしても、最低限欲しい帳票を追加する程度に留めるのが良いでしょう。
2-2. ERPの標準機能をカバーするには
では、ERPで対応しきれない業務はどうすればよいのでしょうか。下記は、X（旧Twitter）で話題になった、とある海外ユーザーのERPに関する投稿です。
— memes.xlsx (@ExcelHumor) November 5, 2023
「穴が開いた部分はExcelでやればいいじゃない」と言っているわけです。酷い話ですね。しかし、実際問題としてExcelで業務をカバーしている現場は非常に多いです。（弊社もそうです）
解決方法の１つとしてExcelは非常に有力です。
ERPの標準機能を補う方法として、あと２つ手段があります。
一つ目の手段は、ERPと連携する形で別のシステムを導入する方法です。
例えば海外製のERPパッケージでは、単体ではワークフロー機能を持たない、もしくは機能が要件に満たないものが多く、別途ワークフローシステムを導入して仕訳連携を行うといった運用事例が多くあります。
よく導入されているシステムとして、NTTデータイントラマート社のintra-martが有名でしょう。
また、ERPのデータベースを開放し、BIツールで分析・出力することで、ユーザーが自由自在に帳票を扱うことができるようになります。
代表的な製品としては、Microsoft社のPower BIや、Tableau、MotionBoardといったものがあります。
二つ目の手段は、ローコード開発ツール（もしくはノーコード開発ツール）で足りない機能をアプリ開発する方法です。
サイボウズ社のキントーンがお馴染みですね。（他にはMicrosoft社のPower Apps、先ほど挙げたintra-martなど）
「わざわざ自分たちでアプリを開発する必要があるならExcelでいい」と思う方もいるでしょう。
しかし、例えば共有フォルダにExcelファイルが置いてあり、複数のユーザーがそのExcelを編集するとなったらどうでしょう？もしかしたら、数式が壊されてしまうかもしれません。もしくは、全く予想外の場所に列や行が追加され、残念なExcelファイルになってしまうかもしれません。
Excelをアプリに置き換えることで、複数のユーザーが同時にデータを更新できるようになり、操作すべきことが視覚的に分かりやすく、またERPや他のシステムとの連携が可能な場合があります。
3．データ移行は意外と奥が深い。
3-1. 筆者の失敗談
データ移行（データマイグレーション）とは、古いシステムから新しいシステムへデータを移すことです。
「たかがデータ移行で何が難しいのか」と思うかもしれません。
筆者がデータ移行で失敗してしまった例を紹介します。
固定資産管理システムの導入期間中に組織改編があり、部署間の固定資産移動が百数件ほど発生しました。
これを受け、私は対象の資産を1月1日付で旧部署から新部署へ移動登録を行いました。登録が完了し、試しに償却資産申告書を出力してみると、理論値と合わない・・・。
そう、償却資産申告は、その年の1月1日時点で所有する償却資産を申告する制度であり、その年は旧部署に付けるべきところ、新部署に付いてしまったのです。つまり、移動登録の時に日付を1月2日とすべきでした。
上記の例は、単に筆者の確認不足ではありましたが、前提知識がないと意外と落とし穴にハマってしまうことがあります。（導入したシステムは移動データの削除が画面上からでしかできず、丸2日間かけて、削除ボタンをポチポチ押して修正したのを付記しておきます）
データの移行をユーザー側が行うにしてもベンダー側が行うにしても、移行対象データの選定や注意事項の確認など、コミュニケーションはしっかりと取るべきでしょう。
また、データ移行後の検証も大切な工程の1つです。
例えば会計システムであれば、仕訳の本数や日付、勘定科目の残高などを見て、現行システムと新システムで差異がないか確認します。
もし、差異があれば原因を探り、修正して徐々に差を埋める地味な作業が待っています。
3-2. ERPのデータ移行
ERPパッケージのデータ移行は、他のシステム導入と比較して特に難易度の高いものになるでしょう。
ERP程の規模となると、データの移行作業やその後の検証もベンダー側が行うのが一般的ですが、ベンダーの作業者が必ずしもユーザーの業務を理解しているとは限りません。
ERPは、販売や購買、生産管理、在庫管理、債権債務管理、会計などの複数のモジュールの集合体です。ERPの導入とは、言わばモジュールの数だけ一度にシステムを導入しているようなものです。
国産ERPパッケージのモジュール構成図
ここで問題になるのは、業務を横断的に理解している人材が本当に少ないということです。経理の仕事は知っていても、営業事務や工場の仕事を理解している人は世の中にどれだけいるでしょうか。
・例えば販売では…
「取引先情報は、商社が間に入っているので需要家（エンドユーザー）の情報も必要」
「納品書には納品先の倉庫コードと倉庫名も印字したい」
・例えば在庫管理では…
「ロット番号で管理したい」
「在庫の数量を、荷姿単位（ドラム、缶など）とkg単位の両方で把握したい」
・例えば債権債務では…
「売掛金の消込は、請求書番号を照合して行っている」
あなたが普段行っている業務は、あなたにとっては常識でも、もしかしたら他の人にとっては全く知らないやり方かもしれません。
ベンダーとのコミュニケーション不足が原因で、本当に必要だったデータが移行対象から漏れてしまったり、想定外の加工がされてしまうかもしれません。
ベンダーとの打ち合わせの場では、現行の業務フローの棚卸しを行い、何のためにそのデータが存在するかをしっかり伝えるのが大切です。
4．ユーザー側もデータベースの知識があると、導入が楽になる。
4-1. データベースの知識
３章でデータ移行は非常に注意が必要であると述べましたが、ユーザー側でデータベースの知識があるメンバーがいると非常に導入が楽になります。
これは、（大規模な基幹システムの移行プロジェクトであれば別でしょうが）大抵は移行対象のデータをユーザー自身が用意しなければならないためです。
ここでは、最低限データベースの知っておくべき知識を解説します。
【データベース】
データベースとは、コンピュータ上で集積・整理された情報群のことです。
一般的に主流となっているデータベースは、リレーショナルデータベース（Relational Database：RDB）と呼ばれるもので、世の中のありとあらゆるシステムの裏側に存在しています。これから解説する内容も、このリレーショナルデータベースを前提としています。
【テーブル】
テーブルとは、データベース内でデータを格納するための領域のことです。データベースの中に、テーブルが幾つも存在しています。
テーブルは表形式で表され、Excelのシートとよく似ています。
テーブルの縦の列は「カラム」と呼ばれ、データの項目を表します。
テーブルの横の行は「レコード」と呼ばれ、一件分のデータとして扱われます。
テーブルにはExcelと違い、幾つかのルールがあります。
① カラムごとに、文字列、数値、日付のように属性が定められ、定められた属性でないデータを入力することはできません。
上記の例は、単価カラムに数値の属性が定められているにもかかわらず、「あああ」という文字列のデータが入ってしまっています。このような状態は、データベースの世界では受け入れられません。
ちなみに、文字列、数値、日付などの属性のことを「データ型」と呼びます。
このルールがないと、例えばコンピュータが「納豆」の単価に何らかの数値データが入っていると思い込んで何らかの四則演算をした時、【あああ × 10% = ？？？】の様なとんでもない計算が走ってしまうのです。
② レコードに重複があってはいけません。
上記の例では、「から揚げ」というレコードがかぶっています。このようにデータを重複してテーブルに保存することはできません。
この様なデータの重複は全くのムダであって、データの容量をかさ増しするだけですね。
③ 1つのセルの中には、1つのデータしか入れられません。
行と列が交わるマス目のことを、セルと呼んだりフィールドと呼んだりするのですが、１つのセルの中には１つのデータしか入れられません。
Excelでいう「セルの結合」といった機能も、当然ありません。
④ 入力必須に指定されたカラムには、必ずデータが入っていなければいけません。
テーブルのカラムには、必ず何らかのデータが入っていないとダメというルールが、指定されている場合があります。（空の状態にしようとするとエラーになります）
一方で備考欄やメモ欄など、必ずしもデータが入っていなくてもよいカラムも存在します。
【マスタテーブルとトランザクションテーブル】
会計システムをはじめ、世の中のシステムのデータベースは、主にマスタテーブルとトランザクションテーブルの2種類のテーブルで構成されています。（例外あり）
("CD" は "コード" の意)
上記は会計システムを想定し、【勘定科目マスタ】をマスタテーブル、【仕訳データ】をトランザクションテーブルに見立てた例です。
マスタテーブルは、他のテーブルから参照されるために存在します。それに対して、トランザクションテーブルは実際に取引が発生する都度（仕訳が発生する都度）、レコードが増加するテーブルです。
学習簿記では、借方が左側、貸方が右側と習うこともあり、【仕訳データ】テーブルのように仕訳が縦に並んでいると戸惑うかもしれませんが、筆者の感覚ではこの様なテーブル設計をしているシステムが多いと感じます。
仕訳No.が同じレコードを集めると1つの仕訳になります。
仕訳No.110561の例では、以下の仕訳が入力されています。
2023年12月8日 (借方) 現金 20,000 / (貸方) 売掛金 20,000
さて、ここで疑問ですが、なぜ【仕訳データ】テーブルには勘定科目名のカラムが無いのでしょうか。ぱっと見て、【仕訳データ】にはどのような仕訳が入っているのかが分かりづらいですよね。
【仕訳データ】テーブルに勘定科目名を追加してみました。すると、人間にとっては非常に見やすくなりましたね。しかし、データベースの世界では、この様な設計は悪い見本とされています。
先ほど、マスタテーブルは他のテーブルから参照されるものと言いました。
つまり、【仕訳データ】の勘定科目CDを、ExcelでいうVLOOKUP関数を用いて【勘定科目マスタ】から検索すれば、「コード1100の勘定科目名は現金だ！」と、情報を引っ張ってこれるのです。
従って、【仕訳データ】にある勘定科目名はムダ（冗長）なカラムであり、データベースにとっては容量のかさ増し要因でしかないのです。
ちなみに、このようなムダ（冗長性）を排除することを、データベースの正規化と呼びます。
4-2. 役に立つこと
さて、データベースについて長々と語ってきましたが、この知識が結局、システム導入でどう役立つのでしょうか。
１つ目は、インポートファイルを作成する上で非常に理解が深まります。
３章で述べたデータ移行は、実務では旧システムから出力したデータをExcelやcsvで加工し、指定のフォーマットで新システムにインポートするのが一般的です。
システムによってインポートファイルのフォーマットはまちまちですが、カラムの項目名を見るだけでそのシステムのテーブルはどのような設計か、他のテーブルとどのように繋がっているか、などを（おおよそ）理解できるようになります。
２つ目は、そのシステムでできそうなこと、できなそうなことの感覚が掴めるようになります。
そもそもシステムというものは、①インプット②プロセス③アウトプットの3つの要素で成り立っています。
①インプットとは、システムに入力されるデータのことです。マウスやキーボードの操作、データベースからのデータ呼び出しなどが該当します。
②プロセスとは、インプットされたデータに対して行われる処理のことです。
③アウトプットとは、システムから出力されるデータや成果物のことです。モニターに表示されたり、データベースに保存されたりします。
データベースを理解すれば、このシステムの3つの要素のうち①インプットと③アウトプットを概ね制覇することができます。（大げさだが）
特に業務アプリケーションにおいては、大量データを扱うことが多く、データベースの役割が非常に大きいです。従って、システムの裏側に存在するデータベースがどのようなものかを理解すれば、自ずとシステムの限界も見えてくるのです。
おわりに
とりあえず、システム導入はベンダーに丸投げじゃダメだよーってことがこの記事で伝われば。
参考文献
広川敬祐 他.「経営のイロハをDX化する 『開発しないシステム』導入のポイント」. 中央経済社, 2021.
本間峯一.「誰も教えてくれない『生産管理システム』の正しい使い方」. 日刊工業新聞社, 2023.
ミック.「SQL 第2版 ゼロからはじめるデータベース操作 (プログラミング学習シリーズ)」. 翔泳社, 2016.
日経コンピュータ.「『動かないコンピュータ』裁判を読み解く」（2016年10月13日号）. 日経BP,
この記事が気に入ったらサポートをしてみませんか？