【第21回】会計システム刷新の進め方

システム導入方法論

システム導入方法論には、ウォーターフォール型とアジャイル型があります。

基幹システム開発はウォーターフォール型がメインなので、ここではウォーターフォール型の導入手法をご紹介します。

※ソフトウェアパッケージやクラウドサービス
ソフトウェアパッケージやクラウドサービスでは、機能の一部をお試しで導入できるものもあります。
例えば、経費精算クラウドサービスやAI-OCRクラウドサービスなどを一部導入する場合です。このような場合は、厳格な導入方法論に基づかずに導入することもあります。しかし、会計システムの場合、企業の決算情報の元になり、かつ内部統制上の要件を満たす必要があるため、しっかりとした導入方法論で推進することを推奨します。

ウォーターフォール型の導入プロセス

ウォーターフォール型では、一般的に下記のプロセスでシステム導入を進めます。

ここでは、それぞれのフェーズについて概要を説明します。

※導入プロセスは、ITベンダーによって独自の方法論があり、用語や内容が異なることがあるため、ベンダーごとに確認が必要です。

会計システム刷新の全体構想（グランドデザイン）策定フェーズでは、一般的に財務経理部門の中長期的な目指す姿、一定のゴール（5年-10年）で実現したい要件、そこまでに何をすべきかとその時間軸（ロードマップ）などを描きます。会計システムは、全体構想を実現するための手段（HOW）として位置付けられます。

全体構想策定フェーズ推進上のポイント

• • 会計システム刷新プロジェクトで問題となるのは、この目指すべき姿が不明確なまま、HOWである会計システム刷新自体が目的化するケースです。一般的に、会計システムを入れ替えたからといって劇的に生産性が向上するわけではありません。システム投資に見合うだけの効率化効果がだせないため（システム投資はコスト削減だけしか考えない経営者が少なくないのも事実ですが）、何年も刷新が停滞している会社も多く見受けられます。

• • 単体の会社のことしか考えていないケースもあります。今後の少子化を考慮すれば、グループ全体の経理財務部門としてどうすべきかを考えなければいけないはずですが、プロジェクトが大きくなることの躊躇から、グループ会社を巻き込めていないケースもあります。

• • 全体構想策定では、現状業務の分析を行いますが、この分析が網羅的でなかったり、現場の困りごとだけの分析にとどまっていたりするケースもあります。現状分析は、目指す姿と現状の姿のギャップ、そのギャップをどう解消するかを検討することが目的ですから、そのことに十分留意して進めることが重要です。

• • 経理財務業務は企業のプロセス全体の中では下流に位置することが一般的なため、上流まで遡って分析をする必要も出てきます。しかし、部門の壁を超えることの躊躇から、経理財務領域内にとどまり、抜本的な検討が疎かになっているケースも少なくありません。

• • 目指す姿を実現するIT基盤としては、会計システムはその一部を構成するだけの場合も多くあります。計画実績管理や着地見込管理などの管理会計の高度化の方が、経営ニーズが高いことも少なくありません。したがって、経理財務部門が目指す姿が何で、その姿を実現するためにどんなIT基盤が必要で、そのなかで会計システム刷新がどう位置付けられるのかを明確にすることが重要です。

以上のように、会計システム刷新における全体構想策定においては、システム刷新が目的化しないように検討することが重要です。

業務要件定義フェーズは、今後目指す新しい業務を具体化し、それを実現するためのシステム化方針を明確化するとともに、導入対象となる製品・サービスと導入ベンダーを選定するフェーズです。

現状分析

業務要件定義フェーズで重要なのは、現状業務（As-Is）を網羅的に押さえることです。
全体を押さえずに、現在の会計システムで実施している業務やオペレーション上の課題だけを洗い出し、それが実現できるERPや会計パッケージを選定しているケースもよく見受けられます。このような場合、会計システムを刷新したのにも係わらず、Excel作業に人員が忙殺され続け、ユーザーにとって何もメリットがなく、結果として導入ベンダーを儲けさせただけといった笑えない話もあます。
業務要件定義では、業務全体を棚卸し、全体観の中でどこを変革すればいいのか、その変革のために会計システムにはどのような要件が備わっているべきかを考える必要があります。

新業務検討（業務改革施策検討）

ERPや会計パッケージには様々な製品・サービスがありますが、概ね機能は類似している部分が少なくありません。したがって、会計システム刷新をFit to Standardで導入するためには、まずはERPや会計パッケージの標準機能を理解したうえで、業務要件定義を行うことが必要です。せっかく検討した新しい業務が標準機能で実現できない場合、結果として手戻りが起こるからです。
標準機能を理解したうえでの検討としては、ERPや会計パッケージに詳しいコンサルタントが当初から参加し、彼らの知見の提供を受けながら業務要件を検討する方法や、いくつかのERPや会計パッケージを決めて提供ベンダーから情報提供を受けながら業務要件を決めるという方法があります。

システム機能配置検討

業務要件定義の中でシステム機能配置も検討します。
例えば、債権管理や債務管理は、販売管理システムや購買管理システムと関連するため、どこの機能を上流システムに配置し、どの機能を会計システムに配置するかなどを検討します。また、会計システムにおけるサブシステムとして何を今回導入するかなども検討します。

インターフェース要件検討

会計システム刷新の場合、上流システムからのデータを取り込むため、インターフェース要件の検討も重要です。それぞれのシステムから、どのデータがどのような形式でどんなタイミングでインターフェースされるかを洗い出します。上流のシステムが数多く存在している場合、インターフェース要件が非常に複雑になるので注意してください。特に、上流にスクラッチ開発のシステムが残っている場合、そのシステムに追加開発できない、そのシステムの仕様を誰も知らないといったこともよく見受けられるので、これらの検討は早い段階から取り組む必要があります。

インターフェース要件においては、管理会計の要件や分析ニーズから、どのようなデータ粒度やどのようなデータ項目が必要か、どんなタイミングでデータが必要か、なども検討する必要があります。以前は、インターフェースした会計仕訳を月末にサマリー（合計仕訳）で計上することが一般的でしたが、昨今は上流システムの明細データに近い形で仕訳を日々持つことがトレンドになっています。このように従前と異なるニーズも漏らさず要件に加えていくことが重要です。

非機能要件検討

業務要件定義では、ユーザーのシステムに対する機能要求事項だけでなく、セキュリティやレスポンス等の非機能要件も検討します。また、新システムにどのように移行していくか（データも含めて）といった移行要件も検討します。

システム化方針検討

業務要件定義では、会計システム刷新プロジェクトとしてのシステム化に係わる全体方針を策定します。
システム化方針としては、システム化の目的、範囲、システム構成、業務要件、インターフェース要件、非機能要件、スケジュール等をまとめます。

製品・導入ベンダー選定

業務要件はRFP（提案依頼書）にまとめられます。このRFPをITベンダーに発出して提案依頼を行い、ITベンダーからの提案を受けます。各社からの提案を受け、その提案の中から自社にあったERPや会計パッケージを選定します。また、この段階で、ITベンダーから導入までに費用も出てくる場合もありますが、概算見積もりとして提示されることが一般的です。

次フェーズ移行判定

業務要件定義の完了と次フェーズへの移行を意思決定機関（例えば、ステアリングコミッティ、経営会議等）で審議し、承認します。この移行判定承認を得るためには、経理財務部門としての現状と目指す姿、そのための取り組み、投資対効果などをしっかり経営層に説明できることが重要です。

システム要件定義フェーズは、導入対象となる製品・サービスを前提に、今後目指す新しい業務プロセスを検証しながら、標準機能設定やアドオン要件、インターフェース要件を具体化し、今後のプロジェクトのQCD計画を詳細化するフェーズです。

標準機能検証

システム要件定義では、選定したERPや会計パッケージの標準機能で業務要件をどのように実現するかを検討します。スクラッチ開発では、この段階では製品は見ることができませんが、ERPや会計パッケージの場合、実際に画面や処理プロセス、出力データなどを確認することができます。

したがって、ERPや会計パッケージの導入では、実際の製品を使いながら標準機能を確認する実機検証を行うことが一般的です。この実機検証を、デモ、CRP（Conference Room Pilot）、POC（Proof of Concept）、プロトタイプ検証などと称すことがあります。選定したERPや会計パッケージのITベンダーによって用語や意味が異なることから、どういう言葉を使うか、その概念は期待していることと同じかを確認することが必要です。

また、この実機検証を有効に行うためには、実現したい業務について業務シナリオを作って、そのシナリオに基づいて実際にシステムがどういう振る舞いをするかを確認していくことが重要です。業務シナリオでは、IF要件とも関連しますが、上流からのデータの流れと会計システム内での処理を一気通貫で検証するシナリオを準備することも重要です。この業務シナリオをしっかりつくらず、実機検証を行った場合、大きな要件が漏れていたり、期待したことができなかったりするので注意してください。

アドオン開発要件定義

CRP等を実施した結果、標準機能で対応できない場合、アドオン開発を行うかどうかの検討が必要になります。しかし、Fit to Standardでの導入をするためには、アドオン開発をできるだけ認めない方針で進めることが重要です。

例えば、支払手段やサイト等が取引先ごとに複雑に定義され、標準機能で対応できない場合などでは、支払条件を見直すくらいの抜本的な変革を行うことが重要です。私どもの経験でも、なぜそんなことを後生大事に守っているのか不思議に思う慣習も少なくありません。また、そのような支払条件による金融効果より、それにともなうシステムコストや人件費の方が明らかに高いといったこともあります。

Fit to Standardによる導入を目指すなら、TOPや関連部門を巻き込んで聖域なき改革を行い、こうした旧態依然の因習を打破することも重要です。

インターフェース要件定義

ERPや会計パッケージのIF要件に合わせて、各種データのインターフェース要件を具体化します。
インターフェース要件として、どのシステムからどのデータがどのような形式でいつインターフェースされ、そのデータをいつどのようにERPや会計パッケージが求める形式に編集し、どうERPや会計パッケージに渡すかといったことを具体化していきます。

特に、上流のシステムが数多く存在している場合、インターフェース開発のボリュームが多くなるため、その開発規模見積もりも重要になります。こうしたインターフェースの設計・開発は、上流のシステムに大きく依存し、ERPや会計パッケージの導入ベンダーの支援範囲外になるため、一般的に自社の情報システム部門が行います。

導入費用検討

システム要件定義が完了すると、ERPや会計パッケージの導入ベンダーから導入費用の提案がでます。
導入費用の内訳は、ライセンス、システム開発費用、保守費用等などがあります。また、ベンダーからの見積もりが当初の想定開発費を超える場合には、要求機能の一部を削減するといった調整もこの段階でおこないます。

次フェーズ移行判定

システム要件定義の完了と次フェーズへの移行を意思決定機関（例えば、ステアリングコミッティ、経営会議等）で審議し承認します。特に、Fit to Standardでの導入の場合、アドオン開発は経営層からその必要性を求められます。

システム開発フェーズでは、システム要件定義できまった要件をシステムとして実装していきます。

標準機能設定

ERPや会計パッケージの標準機能であれば、システム要件の基づきマスタ設定やパラメーター設定等を行い、システムの動作をチューニングしていきます。

アドオン機能開発

アドオン開発がある場合には、アドオン要件に関する基本設計（画面や帳票などを具体的に決める）、詳細設計（システムへの実装方法を決める）、開発（プログラミング）を並行して行う必要があります。

インターフェース開発

会計システム刷新の場合、上流システムからのデータを取り込むため、IFの設計・開発も必要です。

テスト

テストは、一般的に単体テスト、結合テスト、システムテスト、業務運用テストがあります。

1. 単体テスト
   個々の機能やプログラムが仕様通りに動作するかを確認
2. 結合テスト
   複数の機能やモジュールが連携して正しく動作するかを検証
3. システムテスト
   システム全体としての動作確認。業務フローに沿ったテストを実施
4. 業務運用テスト
   実際のユーザーが業務シナリオに基づき操作し、要件が満たされているかを確認

導入ベンダーが主体的に行うのはシステムテストまでです。業務運用テストはユーザーが主体的に行うため、ここでは業務運用整備フェーズとして扱います。

業務運用整備フェーズは、新システム稼働前ならびに新システム稼働後の安定した業務遂行を支えるためのフェーズです。また、業務運用整備フェーズは、基本的にユーザー部門である経理財務部門が主体的に進めます。

業務改革推進（ルール・プロセス・体制等）

業務変革推進は、システムの稼働前、稼働後におけるルール・プロセス・組織などに係わる変革を推進します。例えば、取引先との取引条件（支払サイト、支払手段等）を見直す場合、取引条件の見直し、取引先への説明、取引先との基本契約の変更などを行います。つまり業務変革推進は、全体構想で策定した目指す姿を実現するため変革施策を具体化して、実行していくフェーズです。

業務運用設計

業務運用設計では、新システムを前提として行う業務を具体的に設計します。業務運用設計においては、新システムを直接操作する業務だけでなく、その周辺の業務についても含めて、具体的に設計します。

ユーザー教育

ユーザー教育は、新システムの円滑な導入と安定稼働を支えるために、新システムのユーザーに必要な知識・技能を習得させる重要な活動です。ユーザー教育は、ユーザーのタイプに応じて、座学や実機研修などを含めた教育プログラムを作成し計画的に実施していきます。

業務運用テスト

業務運用テスト（ユーザー受入テスト：UAT：User Acceptance Test）は、開発されたシステムがユーザーの業務要件や期待に合致しているかを確認する最終段階のテストです。業務運用テストは、実際の業務をイメージした業務シナリオに基づき、ユーザーである経理財務部門が中心となって実施していきます。

移行・展開フェーズは、新システムの導入企業・拠点において、旧システムから新システムへシステムを切り替え、新業務での運用を開始するフェーズです。

移行

会計システムには、仕訳データや元帳残高データがあります。これらを旧システムから新システムにどう移行するかが問題になります。例えば、元帳残高データは、過去何年分まで移行する必要があるか、仕訳データは移行するのかしないのかといったことです。移行については、ERPや会計パッケージで条件や制約があるため、詳細な確認が必要です。

移行においては、実際に新システムに移行するデータを用意します。また、旧システムから新システムへの切り替え手順を具体的に決め、本番前に何回かリハーサルすることが一般的です。特に、上流のシステムが複雑な場合、「上流システム→旧システム」と「上流システム→新システム」がタイミング、データ形式等が異なるため、入念なリハーサルを行うことが重要です。

展開

展開は、システムを複数拠点に導入することをいいます。生産管理システムの導入などでは、工場ごとにタイミングを変えて導入することがありますが、会計システムは会社ごとに一括導入することが一般的です。ただし、会計システムを複数の会社に導入する場合には、どのように展開して行くのかを展開計画として策定し、順次導入していく必要があります。

今回は、ERPや会計システムパッケージによる「会計システム刷新」のキホンのキとして、会計システム刷新における導入プロセスの概要をご紹介しました。レイヤーズ・コンサルティングでは、会計システム刷新に関するご支援実績を多数保有しておりますので、詳細についてご興味のある方は、是非お問い合わせください。