----------------------------------------------------------------------

　（Ａ社発注業務刷新におけるシステム企画内容の監査）

----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
1.Ａ社システム企画と私の立場
----------------------------------------------------------------------
1.1.Ａ社とシステムの概要
----
　Ａ社は東日本を中心に１００店舗を展開する中堅のス
ーパーである。商品の発注については、商談結果による
新商品の投入や売出商品等を本部からオンライン端末で
行い、店舗からは補充発注をＨＴより行っている。
　長引く不況の中、収益力強化のためにＡ社では在庫削
減を経営戦略に掲げている。そして、それをサポートす
る情報システムとして、仕入先・製造メーカを含めた企
業間連携に取り組む事となった。
　特に発注業務については、以下内容に基づき、全面的
に刷新する事となった。

a.販売実績・在庫のメーカ・仕入先との共有
b.発注回数の追加
c.ＥＯＢの導入による発注精度の向上

----
1.2.Ａ社システム企画における私の立場
----
　システムインテグレータであるＮ社に勤務する私はＡ
社企業間連携について内部監査員として携わってきた。
具体的には、Ｎ社の品質管理部門に所属しており、実際
の開発を行うプロジェクトに対しシステム監査を行う立
場にあった。
　Ａ社プロジェクトについては基本計画までを委託契約
により受注しており、内部監査の実施後に、基本設計以
降の工程を一括契約で請け負う予定である。
　Ｎ社内では一括請負に掛かるリスクコントロールのた
めにＡ社プロジェクトの内部監査を実施する事となった。
一方で内部監査の実施は、システムと経営戦略の整合性
を確認し、プロジェクトを予定の工期・コストで収める
意味でＡ社にとっても意味があるものである。


----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
2.システムの企画内容を監査する場合の留意点
----------------------------------------------------------------------
2.1.ユーザニーズの調査範囲と対象
----
　Ａ社プロジェクトのように全社レベルにおいて経営戦
略を実行するシステムにおいては、先ずトップマネジメ
ントの意思が確実にシステムの企画に反映されていなけ
ればならない。これを誤るとＡ社にとってシステムの価
値は下がり、最悪のケースでは企画のやり直しになり、
カットオーバーの時期を遅らせる事となる。
　一方で、システムの利用者はあくまでも現場が中心で
あり、細部にわたっての業務フロー、システム機能設計
については現場の意見を幅広く取り入れる必要がある。
　　
----
2.2.ユーザニーズの調査方法
----
　ユーザニーズを調査する場合には一般的にはヒヤリン
グが適当であるとされている。しかし、私は今回のプロ
ジェクトについては以下の理由により、何等かの工夫を
行う必要があったはずであると考えた。

a.店舗については、出店範囲が広く対象者を集めヒヤリ
　ングを行う事は困難である。

b.店舗には正社員・パート社員が勤務しており、仕事に
　対する姿勢・権限・責任も異なっている。

　従って、私は監査を行う上で、ユーザニーズの調査結
果だけでは無く、その調査方法についても確認する事が
重要であると考えた。

----
2.3.ユーザニーズの調査内容
----
　ユーザニーズの調査範囲・対象・方法が妥当であった
としても結果として上がってきたユーザニーズが経営戦
略を実現可能なものでなければシステムは意味をなさな
い。そこで今回の監査では、ユーザニーズと経営戦略の
整合性を慎重に確認する必要があると考えた。

----
2.4.ユーザニーズの調査結果の承認方法
----
　前述の通り、トップマネジメント・利用部門から収集
したニーズについては最終的にはＡ社の承認が必要であ
る。一般的にはシステムの方向性と投資対効果をトップ
マネジメントが承認し、詳細についてはトップマネジメ
ントから権限を委譲された利用部門、及びシステム部門
の責任者が承認を行うものである。
　従って、私は監査を行う上で、Ａ社のプロジェクト体
制を確認し、トップメネジメント以下、関係部門に対す
る承認方法を確認する事とした。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
3.システムの企画内容を監査する場合の監査手続き
----------------------------------------------------------------------
3.1.ユーザニーズの調査範囲と対象
----
　実際の監査においては先ず、プロジェクトがＡ社の経
営戦略および情報戦略を正しく把握している事を確認す
る事から着手した。これについては、Ａ社の中期計画書
等を査閲し、システム企画書と照らし合わせる事で監査
を実施した。
　一方で利用部門としてのユーザニーズの調査範囲が妥
当である事については以下の手順で監査を実施した。

a.システム企画書の業務フローよりシステムに関わる対
　象部門の洗い出し。

b.各対象部門のニーズが調査されている事を、調査結果
　の議事録や、後述するアンケートシステム企画書との
　突合せ。
　
----
3.2.ユーザニーズの調査方法
----
　前述の通り、Ａ社プロジェクトにおいてはユーザニー
ズの調査において何等かの工夫が必要である事は事前に
予測可能であった。調査の結果、プロジェクトにおいて
は、具体的に以下の方法を採用していた。

a.ヒヤリングについては１００店舗中１０店舗について
　実施。ヒヤリングを行えない店舗については、アンケ
　ートを実施。

c.アンケートについては幅広く意見を収集するために記
　述方式だけでは無く、選択方式による簡易な方法も採
　用。

　私は各々について以下の確認を行った。

a.ヒヤリング対象店舗については、Ａ社の代表的な店舗
　であり、対象店舗の絞込みについてはＡ社の承認が得
　られている事。

b.アンケートについては少なくとも全ての店舗から回収
　されている事。個人レベルの回収率については６０％
　程度であったが、その回収率についてＡ社の承認が得
　られている事。

----
3.3.ユーザニーズの調査内容
----
　ユーザニーズの調査内容が妥当であり、経営戦略との
整合性が確保されている事。これにについては、システ
ム企画書よりユーザニーズの一覧を査閲し、経営戦略と
の関係と、経営戦略への貢献度が評価されている事を確
認した。

----
3.4.ユーザニーズの調査結果の承認方法
----
　システム監査を行ったタイミングは、最終的なシステ
ム企画書をＡ社に提出する前のタイミングであり、企画
書への捺印状況では確認を行う事ができなかった。従っ
て、企画書のレビューを行った際の議事録より、以下を
確認する事とした。

a.トップマネジメントと、対象部門の責任者がレビュー
　に出席している事。

b.レビューでの指摘事項が最終的な納品物であるシステ
　ム企画書に反映されている事。

----------------------------------------------------------------------
4.最後に
----------------------------------------------------------------------
　以上の監査を行った結果、唯一の問題点は、3.3.に記
述したユーザニーズと経営戦略との関係は整理されてい
るものの、貢献度について数値的な評価がなされていな
い事が判った。これにについて、プロジェクト側で追加
作業を実施し、システム企画書は最終版となった。
　現在はＡ社より基本設計工程以降の発注を受け、プロ
ジェクトは進行中である。