今月の視点

　ＥＲＰパッケージ＊ （以下、ＥＲＰとする。） の導入を前提とした基幹システム刷新プロジェクトでは、自社の業務や導入目的に適したＥＲＰを選ぶことが重要である。

　しかし、ＥＲＰが標準機能のまま100％適合することはごく稀であり、多くの場合、追加開発か業務調整のいずれかの選択を迫られる。この方針を定めていく工程が要件定義工程である。

　ＥＲＰを業務に合わせるため過度に追加開発をしてしまうと、開発コスト・リスクが大きくなり、業務をＥＲＰに無理に合わせると、稼働後の業務運用に支障をきたす。

　コスト・リスクは抑えながら、ユーザー満足度を限りなく大きくするには、ベンダーの力を借りつつも、導入企業自らが、要件定義の段階で新しいシステムと業務運用を具体的に想像し、開発仕様や運用方法を納得ずくで定めることが肝要である。

　今月は、ＥＲＰ導入の失敗と成功を経験したＡ社の事例をもとに、質の高い要件定義を実施するための留意点を考えたい。

＊ＥＲＰパッケージとは、 財務会計、 販売、 購買、 在庫管理など事業の基幹業務を支える情報システムを、一つに統合して製品化したパッケージシステムの総称。

1　要件定義の概要

要件定義は、ＥＲＰベンダー選定後に行う最初の工程である。

ベンダー選定前のマスタープラン策定段階では、ＥＲＰ導入によってユーザーが実現したい目的を果たすための要求仕様を取りまとめる。一方、要件定義では、要求仕様とその背景にある自社の業務特性を踏まえ、ユーザーとベンダーが協同で、システムの適用方法を具体化していく。

要件定義は、ＥＲＰ導入によって所期の目的が実現できるかどうかを見極める重要な工程であり、以下の３つについてユーザーが主導的な役割を果たすことが求められる。

（※プロジェクト全体の一般的な推進手順は図１参照。）

（１）適合性検証・仕様調整

マスタープラン策定段階で作成した要求仕様書をもとに、入力画面や出力帳票などといったＥＲＰ標準機能を具に検証する。

要件定義の段階では、機能の仕様を詳細に確認するとともに、自社ではどういった使い方ができそうかまで具体化することになる。

要求仕様書で定めた品質条件と、ＥＲＰ標準機能との間に乖離がある場合は、追加開発を行うか、ＥＲＰ標準機能を前提として業務を変更するかを判断する。

（２）適用・設計監理

ＥＲＰの適用方針や、使用機能の選択、ＥＲＰへの追加開発に対する設計仕様、周辺サブシステムとＥＲＰとをデータ連携する場合の連携仕様をベンダーと協議する。協議結果に基づきベンダーが作成した設計書を精査し、設計仕様を確定していく。

（３）業務運用検証（運用定義書の作成）

ユーザーとベンダーが運用イメージをすり合わせ、ＥＲＰを前提とする新しい業務手順・運用ルールを具体化し、結果を運用定義書として取りまとめる。運用定義書は、稼働後の業務運用のガイドラインになる。

以降の工程では、要件定義工程で定めた通りに適用作業や、追加開発部分の設計・開発が始まり、システムが完成する。すなわち、要件定義工程で定めた内容がその後のシステムの導入品質、コスト、納期を左右することになる。

質の高い要件定義を行えるかどうかが、ＥＲＰ導入の成否を握る。

2　Ａ社の事例

（１）手痛い失敗

Ａ社は業務用調味料メーカーである。全国各地に販売子会社を有し、大小合わせて15の製造工場を持っている。近年では、高齢化や健康志向の高まりをうけ、機能性素材の開発・製造・販売にも力を入れている。

Ａ社グループは、およそ20年前、基幹システムを独自に開発（以下、スクラッチ開発と呼ぶ。）した。現行基幹システムは20年前の業務を前提としているため、使用しなくなった機能もあれば、改修・追加開発が必要になった機能もある。

開発は大手ベンダーに委託しており、改修・追加開発の度に高額な開発費用を支払っていた。また、当初から開発に携わっていたシステムエンジニア（以下、ＳＥと略す。）が退職し、新しい担当ＳＥの技術力が低いこともあって、ここ数年のベンダーの対応はＡ社にとって満足のいくものとは言えなくなっていた。

ＯＳの保守期限が迫っていること、サーバーのメンテナンスコストが増えてきたことも相まって、Ａ社情報システム部は基幹システムの刷新を決断した。

基幹システムの刷新に際しては、スクラッチ開発ではなく、ＥＲＰの導入を前提とすることとした。ＥＲＰ導入は、スクラッチ開発と比較すると導入・維持にかかる総額が大きくなりやすいが、保守・メンテナンスの負荷軽減が期待できる。一般的な業務手順を前提としており、法改正やユーザーのニーズに合わせてＥＲＰの機能は随時アップデートされていく。

Ａ社情報システム部は早速自社の業態向けＥＲＰを持つベンダーへ提案依頼を行った。３社から具体的な提案を受け、大手ＩＴベンダーＸ社を選定した。最も安価な開発コストを提示したことと、大手ゆえの技術力の高さや経験の豊富さをＡ社は評価した。

Ｘ社のＳＥチーム主導で要件定義工程が始まった。ＥＲＰのデモ環境を使いながら、標準機能を現行業務に適用することができそうか議論していくことで、Ａ社がシステムに求める要件を明らかにしていくこととした。

要件定義工程からは現行基幹システムへ日々入力しているＡ社実務担当者を交えて検討を進めていったが、Ａ社実務担当者からは厳しい声が多く聞かれた。

「ＥＲＰの想定している業務は現行と異なる部分がかなり多い。システムに業務を合わせると現状から大きく変わってしまうことになる。現場の混乱を招き、日々の業務に支障が出るのではないか。」

Ｘ社ＳＥチームは、現状業務に合わせて追加開発をしてしまうと、ＥＲＰが前提としているデータの処理ロジックやマスタ・データの関係性や階層構造（以降、「ＥＲＰの構造」と呼ぶ。）に大きな影響を与えることになり、開発リスク・コストともに大きくなってしまうことを懸念した。Ｘ社ＳＥチームはＥＲＰの構造を一から説明し、追加開発のリスクを示したが、Ａ社実務担当者にはうまく伝わらず、理解は得られなかった。

ＥＲＰで現行業務を継続するための要望は膨み、追加開発範囲の増加に歯止めがかからなかった。要件定義工程終了時点での見積金額は、ベンダー選定段階で提示された金額の倍近くになってしまった。

事態を重く捉えたＡ社社長は、プロジェクトを中止する判断を下した。

（２）プロジェクト再始動

これまではＡ社情報システム部が日々の業務と並行して、ベンダーの作成資料の検証、社内関係者への確認といった事務局機能を担ってきたが、ＥＲＰ導入は初の試みということもあり、プロジェクト管理に苦心していた。

そこで、Ａ社社長は、ＥＲＰ導入のプロジェクト管理に定評のある外部コンサルタントに参画を依頼し、事務局機能を強化することにした。

事務局は、まずはＥＲＰ導入の目的を再認識し、マスタープランを策定することから始めた。

ＥＲＰ導入に対するＡ社社長の想いは以下の通りであった。

「まず、ＥＲＰ導入を前提に検討することには賛成している。基幹システムは、いまや企業活動と切っても切り離せない。システムは戦略実行を下支えしている。

ＥＲＰは常に便利な機能が追加され、進化すると聞く。インボイス制度や電子帳簿等保存法などの法改正にも低コストかつ迅速に対応できる。当社の長所は変化する環境に対して迅速に柔軟に適応してきたことであり、ＥＲＰの導入によりこの長所をさらに伸ばしていけるのではないか。改修を加えるたびに決して小さいとは言えないコストを支払い続けるといった従来からの悩みも解消されよう。

ＥＲＰを導入するということは、現状の業務を少なからず変える覚悟も必要になる。しかし、これまでと異なる業務手順になったとしても、現行業務の背後にある目的を果たすことができ、業務として無理なく回るのであれば、それで十分なはずだ。業務の目的自体が変わってきているもの、あるいは変えるべきものもあるかもしれない。

その意味で、現行業務や現行基幹システムを良く知っている実務担当者だけでなく、大所高所での意思決定ができる幹部クラスも検討に参加させる。」

社長の命を受け、社内の部門横断的なプロジェクトチームが組成された。販売、製造、会計などの機能別に分科会を作り、各分科会のリーダーには部長級が任命された。

事務局はまず、現状業務処理の手順やパターン、業務負荷、システムの活用状況、製造原価計算制度や在庫評価方法、会計仕訳などを丁寧に分析した。

現状分析と並行して、今後の事業運営・組織運営に基づく業務・管理のあるべき姿を確認し、その実現にむけた業務運用上の課題を棚卸した。課題一つ一つに対して、分科会メンバーと集中的に検討し、対応の基本方針を定めていった。

分科会メンバーと定めた基本方針をもとに、基幹システム刷新後の業務フローを作成し、そのために必要なシステムの機能を定義していった。事務局は、これらの検討内容を要求仕様書として取りまとめた。

また、事務局はＥＲＰの調査を行った。製造業向けのＥＲＰから、特に食品製造業で定評のある６つに絞り込み、詳細な情報提供を受けた。

そこからさらに３社に絞り込み、要求仕様書を提示したうえで具体的な提案を受け、比較・評価を行った。

機能面での適合度評価は、要求仕様書で定めたシステムに求める機能をＥＲＰが有しているか否かといった観点で行った。

また、ベンダーの力量に対する評価も実施した。ベンダーのプロジェクトリーダーが発する質問内容や、事務局との打ち合わせ時の受け答えの水準感などをもとに、Ａ社の要求仕様の理解度、プロジェクトマネジメント力の高さを推し量った。

評価の結果、システムと業務の適合度が８割を超え、かつプロジェクトリーダーの力量も高いＹ社のＥＲＰ導入を決定した。

（３）要件定義工程

①議論のための土台作り

Ｙ社のＳＥチームは、Ｘ社と同様、まずＹ社ＥＲＰのデモ環境を用いながら、ＥＲＰ標準機能と現状業務・システムとの乖離を細かく把握し、課題を洗い出していく、といった進め方を事務局に提案した。

しかしながら、事務局は、この進め方では検討が停滞するのではないかと危惧した。検討を進めるためには、ＥＲＰ標準機能を正しく理解し、新しい業務・システム運用を具体的に想像したうえで、システムの追加開発を選ぶか、業務の調整を選ぶか、納得づくの意思決定をする必要がある。そのためには、仮にＡ社グループにおいてＹ社ＥＲＰの標準機能のみで運用する場合の業務運用が想像しやすいように、リアリティのある環境を構築するべきであると事務局は考えた。Ｙ社が用意しているデモ環境では、分科会メンバーの判断にばらつきが生じてしまう懸念があった。

そこで、現行基幹システムで実際に使用している取引先名や製商品名、組織名などをＹ社ＥＲＰに設定するなど、使用する入力画面・項目レベルまで稼働後の運用をイメージした環境を構築し、新しい業務の想定とギャップがないかを検証するための基盤を整えた。

②ＥＲＰ適用に向けた対応策の検討

事務局は、設定した環境下で分科会メンバーにＹ社ＥＲＰを実際に操作してもらい、課題を漏れなく抽出した。

明確になった課題は、まず事務局とＹ社ＳＥチームとで、対応策の代替案を検討し、代替案ごとの具体的な内容、リスク、費用を検証し、分科会メンバーと協議することとした。

検討に際して、以下の観点を軸に代替案を比較した。

以下に課題と対応策の例を４つ示す。

ａ．代理人取引の識別

＜課題認識＞

Ａ社の場合、代理人取引に該当するのは限られた商品の販売のみである。そのため、現行基幹システムでは、当該商品を販売したら自動的に代理人取引と識別される仕組みをとっている。

しかし、Ｙ社ＥＲＰにはこのような仕組みがなく、取引を行う都度、代理人取引に該当するかどうかを入力者が識別することを前提としている。入力者が正しく判断して正しく処理しなければ、代理人取引が漏れてしまう。

＜対応策＞

＜協議結果＞

代理人取引の識別は会計処理においても重要であるため、正確に処理したい。開発コストを抑えつつ運用上のリスクも回避できることから効果は高いと判断し、追加開発で対応する。

ｂ．製造会社・販売会社間の売上・仕入の連携

＜課題認識＞

現行基幹システムは、Ａ社（製造会社）の売上データをもとに、販売子会社の仕入データを自動生成する機能を有している。販売子会社では、Ａ社からの仕入は入力作業を省略できている。

それに対してＹ社ＥＲＰはグループ会社間のデータの自動連携を想定しておらず、標準機能では手作業が発生してしまう。

＜対応策＞

＜協議結果＞

販売子会社の仕入は７割以上がＡ社からであることを鑑みると、ＣＳＶ取込とはいえ、作業量の増加により業務効率は著しく低下することが懸念された。改修範囲は大きいもののリスクは限定的であることを踏まえ、追加開発で対応することとした。

ｃ．請求書の発行

＜課題認識＞

ⅰ．業務スケジュール

現状、請求書発行と入金消込入力はＡ社本社で集約している。請求書の着日には取引先からの指定があり、本社の限られた人員で対応するために、入金消込処理を行う前に、請求書発行を行っている。

それに対して、Ｙ社ＥＲＰでは、前回請求分の入金消込入力を完了してはじめて今回請求分の請求書を発行できる仕組みになっており、現状の業務スケジュールとはフィットしない。

しかし、現状業務スケジュールが実現できるように追加開発するとなると、Ｙ社ＥＲＰの構造に大きな影響を与える、リスクの高い開発になることが想定され、現実的ではない。

ⅱ．電子請求への対応

現行基幹システムでは電子請求に対応しておらず、すべて紙で請求書を印刷している。

Ｙ社ＥＲＰでは請求書のＰＤＦ出力には対応しているが、自動メール配信機能やWeb上でのダウンロード機能はなく、これまで通り、紙で印刷することが基本線となる。

ⅲ．指定請求書への対応

現行基幹システムは指定請求書の発行に対応していない。指定請求書をExcelで作成し、担当者・上長によるダブルチェックののち、責任者による承認をもって郵送している。

Ｙ社ＥＲＰも指定請求書様式での発行には対応しておらず、現状のExcelを前提とした業務運用は継続せざるを得ない。

＜対応策＞

＜協議結果＞

標準適用案の採用は現実的ではない。本社のある東京から北海道や九州などの遠隔地の取引先に請求書が到着するまでには、どうしても２,３日はかかる。Ｙ社ＥＲＰに業務を合わせるために本社の人員を増やすことも本意ではない。

それに対して、請求書発行専門の外部ソフトを活用する追加開発案は、業務改善効果が大いに期待できる。電子帳簿保存法の改正に伴い、電子請求書の受取に応じる顧客は多くなるはずである。電子請求が増えれば、紙での請求書発行にかかっている労力も減らせる。指定請求書も、レイアウト作成には手間がかかるが、一度作成すれば、Excelでの手作業やチェックにかかる負荷も軽減できる。追加開発案を採用する。

ｄ．製造原価計算　直接作業時間の入力

＜課題認識＞

現行基幹システムにおいて、製造に携わった作業者の直接作業時間は、製造実績の入力画面において、原材料投入量、副資材などの使用量と同一画面で入力している。

それに対して、Ｙ社ＥＲＰでは、原材料や副資材など入力画面と、作業時間の入力画面が分かれている。作業時間の入力画面は、直接作業だけでなく間接作業も含めてその日一日の作業を入力する画面である。製品製造と作業時間を、入力者自身がシステム内で選択して紐づける仕様であるため、誤って紐づけてしまうリスクがある。

＜対応方針＞

＜協議結果＞

事務局およびＹ社ＳＥチームは、標準適用案の方が業務負荷が大きいと考え、追加開発案を推奨したが、製造分科会リーダーのＡ社生産部部長から下記の言葉があった。

「かねてからデータに基づく分析の一環として、製造担当者の活動を分析し、生産性向上に役立てたいと考えてきたが、これまでの業務前提では、直接作業時間しか入力しないため、そもそも分析するためのデータが取れなかった。

作業時間の入力時に誤った製造実績を選択してしまうと、製造原価計算に影響が出てしまうが、製造担当者一人当たりが一日に携わる製品の種類はさほど多くない。ダブルチェックの徹底など運用の工夫でカバーできる範疇ではないか。

標準適用案を選ぶと、入力負荷やチェック業務は増えるが、製造担当者がその日一日どのような作業に従事したかといったデータが残り、分析できるようになる。生産性向上に資する業務・管理のレベルアップがより重要ではないだろうか。」

この考え方を踏まえ、生産部の現場担当者にも実際に入力してもらい、実現性・継続性を確保できることが確認できたため、標準適用案を採用することとした。

③運用定義書の作成

事務局は、上記の検討と並行して、運用定義書を作成した。

運用定義書では、基幹業務を業務セグメントに分け、業務セグメントごとに以下の項目を整理した。

・ 現状業務フローとＥＲＰ導入後の想定業務フローの対比

・ 検討内容のとりまとめ

ａ．追加開発事項と、追加開発の設計仕様

ｂ．運用対応事項

ｃ．次工程以降の検討事項

事務局が作成した運用定義書と、Ｙ社ＳＥチームが作成した要件定義書とを突き合わせ、認識の齟齬がないかを相互に確認した。認識に誤りのあった内容がいくつか見つかったが、素早くすり合わせを行うことができた。

また、運用定義書を分科会メンバーとも共有し、これをガイドラインとして実際にＹ社ＥＲＰへの入力をしながら、自社独自の想定業務フローの実現性・継続性を検証し、運用定義書の精度を高めていった。

運用上の疑問点や懸念点が挙がる都度、事務局とＹ社ＳＥチームが一丸となって検討し、分科会との協議を経て意思決定をした。

販売分科会のあるメンバーからは、以下のようなコメントがあった。

「事務局が当社向けのリアルな環境を設定して、業務起点で議論を整理してくれたからこそ、我々の理解が進み、この場合はどうする、あの場合はどうなる、と次々に疑問点が湧き、議論が深まった。Ｙ社ＳＥチームも限られた時間のなかで高いレベルの選択肢を提示してくれた。検証と検討のサイクルを何度も回せたことで、納得のいくシステム・業務になったと思う。」

（４）設計・開発、稼働へ

要件定義工程完了後は、Ａ社とＹ社が合意した仕様をもとに、開発費用の再見積が行われたが、ベンダー選定時からの金額変動はほぼなかった。そのため、Ｙ社のＥＲＰを導入する最終意思決定を行い、設計・開発工程へ移った。

要件定義工程段階から事務局とＹ社ＳＥチームとで具体的な設計内容にまで踏み込んで認識をすり合わせたことが奏功し、予定通りの品質・コスト・納期で開発・導入が進んだ。

本稼働後は日次業務、月次業務で多少の不具合や運用ミスが発生したものの、すぐに収束し、安定運用状態に至った。

3　留意点

手痛い失敗を経たものの、質の高い要件定義を行うことでプロジェクトを成功に導いたＡ社の事例から学ぶことができる留意点を以下に整理する。

①システム・業務運用がありありと目に浮かぶ工夫を凝らす

ベンダー選定段階までは「システムで実現したいこと」に着眼した抽象的な議論が中心であったが、要件定義工程からは「実現するための手段」が主な検討内容になる。システムの具体的な仕組みについての議論は避けて通れない。システムの仕組みにまで踏み込み、プロジェクトチームにおいて精度の高い意思決定ができなければ、稼働後の業務が成り立たなくなる可能性すらある。

「標準機能では日々の業務は回らない」「この機能ならば業務は十分回る」と判断していくためには、プロジェクトメンバー全員がＥＲＰ標準機能を高いレベルで理解していることが必要になる。だれが、どの画面を使って、どういった項目に対して入力し、どういった画面・帳票でチェック、承認を行っていくか、ＥＲＰを使った日々の業務がありありと目に浮ぶ水準で理解していることが肝要になる。

ＥＲＰ導入プロジェクトの場合、ベンダーから、ＥＲＰを自由に触れる環境を提供してもらうことが可能である。

Ａ社の事例では、この機会を最大限活用し、現実と同様の業務環境を迅速に構築した。そして、構築した環境をもとに自社独自の業務運用を早期に具体化し、検証を行った。これによって、関係者のＥＲＰ標準機能に対する理解が深まった。

ＥＲＰに対する理解が深まると、関係者から思わぬ運用アイディアが浮かんでくることもある。共通の深い理解があることによって、関係者の知恵を結集し、協同作業を実現することができ、精度の高い、かつ納得感のある意思決定につながっていく。

②追加開発仕様は極力深堀りし、ベンダーと認識をそろえる

システム開発は失敗やトラブルが後を絶たない。ＥＲＰ導入で後々問題になりやすいのは、追加開発仕様である。開発が進んだ後に、ユーザーが求める通りの開発仕様になっていないことに気づくケースが多々発生している。

こうした不幸を招かないためには、追加開発の設計仕様を詳細にすり合わせ、ユーザーとベンダーの認識に齟齬がないようにしておくことが重要である。

Ａ社の事例では、運用定義書がその役割を果たした。ベンダーに任せきりにするのではなく、ユーザーとしての認識をきちんと落とし込んだ文書をベンダーに提示することで、すれ違いを特定し、いち早くすり合わせることができる。

③経営トップが心構えを明確に示す

ＥＲＰを導入すると、どうしても業務は変わってしまう。しかし、現場担当者からすると、日々の業務が変わることには大きな不安が伴う。Ａ社の失敗事例にも現場の危機感が顕著に表れていた。

Ａ社社長は「変えざるを得ない業務は必ずある。現状業務の維持を是とするのではなく、業務の目的に立ち返り、時には業務目的自体も見直すべし」という決意と方針を明確に示した。これがあったからこそ、分科会メンバーは変えてはならない業務か、変えるべき業務か、追加開発か、業務調整か、悩みながらも決断することができた。

経営トップの決意と方針は、進むべき道を迷った際の道しるべになる。

④ベンダーと手を携え、前向きな機運を作る

ＥＲＰベンダーは自社が提供するＥＲＰの専門家であり、ＥＲＰ導入プロジェクトはベンダーの協力なしには進まない。

また、ベンダーは専門家の見地からリスクやコストをより抑えた開発方法はないか、落とし穴がないか、緻密に、着実に検討してくれる。

一方で、ベンダーは、自社のＥＲＰの仕様に厳密すぎるために、仕様の詳細を知らないユーザーへの説明はうまくないケースがしばしばある。Ａ社の失敗事例では、それによって、ユーザーからの信頼を失ってしまった。

Ａ社の成功事例では、分科会との協議の前に、事務局とＹ社とで事前に打ち合わせし、分科会に「これなら業務が回る」と思ってもらえる打ち出し方をすり合わせていった。ＥＲＰで実現できないことにどうしても目が行きがちだが、前向きな機運づくりが上手くいき、分科会メンバーのＹ社に対する評価も高まっていった。

長く付き合っていくパートナーたるベンダーの強みが最大限活きるように心を配り、ベンダーと手を携え、リスク・コストは抑えながら満足度の高いシステムを作り上げたい。