企画・開発業務に対するシステム監査--システム監査基準の批判的考察を中心に---香川大学学術情報リポジトリ

企画・開発業務に対するシステム監査

一 一 一 シ ス テ ム 監 査 基 準 の 批 判 的 考 察 を 中 心 に 一 一 一

岡 田 純

I.序 コンビュータを中心とした情報処理システムに対する監査としづ意味で、こ れまで関連する諸機関・諸団体によって，

EDP

監査，

EDP

システム監査， 情報システム監査， コンピコータ監査等といった名称が用いられてきた。これ に対して rシステム監査」という用語法は我が国独特のものであり，昭和

4

9

年 に通商産業省の外郭団体である側日本情報処理開発協会が提唱して以来，現在 では一般的に用いられるようになっている。同協会が昭和

5

5

年に公表した「シ ステム監査基準(試案)Jによれば，システム監査の意義・目的は r監査対象 から独立した客観的な立場で， コンビュータを中心とする情報処理システムを 総合的に点検・評価し，関係者に助言，勧告することをいい，システムの有効 利用の促進と弊害の除去とを同時に追及して，システムの健全化をはかるもの である」とされている。とりわけ，昭和

6

0

年

1

月に通商産業省から「システム 監査基準」が公表されるとともに，翌年

1

0

月より情報処理技術者試験の一環と して「システム監査技術者試験」が実施され，社会的にも広く認知されること (1) システム監査というものが従来の監査概念にあてはまるかとしヴ議論もある。例えば， 槍悶 [12Jを参照。なお，本稿では「システム監査」自体を1つの概念枠組をもつものと して捉えているので，上記の議論は除外されている。 ( 2 ) この他にもシステム監査に関するガイドラインとして代表的なものは， 日本公認会計 土協会電子計算機会計委員会'EDPシステムの監査基準および監査手続試案j (昭和51 年9月)， EDP 歎査人協会東京支部『システム監査ガイドラインー管理目標と監査実施 基準一J(日経マグロウヒノレ社 昭和60年入金融情報システムセンター「金融機関等の システム監査指針j (昭和62年7月〉等がある。

-206- 第61巻 第3号 536 になった。 「システム監査基準」は，形式面では大蔵省企業会計審議会の「監査基準」に 則っており，基本要件となる目的，対象，システム監査人，監査時期，監査計 画，監査手順を定めた「一般基準J，システム監査人が企画・開発・運用業務の 流れに沿って監査を実施する上でのポイントを定めた「実施基準J，監査結果を 取りまとめる上で必要な事項と対処措置を定めた「報告基準」から成っている。 しかしながら，実施基準についてみれば，実質的には，基準というよりもむし ろ，準則ないしチェッグリストという内容となっている。 本稿では，システム監査基準における実施基準のうち，特に企画業務および 開発業務に焦点を当てて，そこでの問題点を検討することを目的としている。 そのためにまず予備的な議論として，第

I

I

節において，企画・開発業務の遂行 にあたって有効な管理手法を，そしてまた第

I

I

I

節において，企画・開発業務に 対するシステム監査のアプローチ方法を検討している。これらの検討を踏まえ て，第

I

V

節において，システム監査基準における問題点を指摘するとともに， 改善案を提示している。

I

I

.

企画・開発業務とプロジェクト管理 、一ドウェアの技術進歩，オペレーティング・システムの機能拡充に伴い， コンピュータ化の対象業務が，比較的単純かっ小規模なパッチ処理システムか ら，複雑かつ大規模なオンライン・リアルタイム処理システムへと拡大され， ソフトウェアの開発工程は，複雑化・広範囲化の一途をたどっている。このよ うな環境のもとで，プログラマの生産性向上とプログラムの品質改善の要求は 一層強まってきており，従来の

EDP

部門内での縦割り組織では，短期的かっ 効率的にシステム開発を行うことが困難になってきた。そこで，開発プロジェ クトを策定し，開発局面毎にプロジェクト・チームを編成し，厳密なプロジェ クト管理を実施していくことが，今やシステム開発において不可欠のものと なってい￡すなわち，企画業務の初期段階で綿密なプロジェグト計画を立て， (3) 開発プロジェクトとは，システム開発を目標として編成される作業体制または組織の

537 企画・開発業務に対するシステム監査 -207 ￨局面1¥局面2¥局面

n n

局面N

￨

工

程

1

¥

工

程

2

¥

工

程

3¥

.

.

.

)

)

.

.

.

.

.

¥

工

程

M¥

己主￨作業項目 2¥

作

業

項

目

0 l

=J作業項目 L

¥

開 発 案 件 の 優 先 順 位 に 基 づ き ， 開 発 局 面 毎 に 広 く 関 連 部 門 か ら 必 要 な 要 員 を 集 め て プ ロ ジ ェ ク ト ・ チ ー ム を 編 成 し ， プ ロ ジ ェ グ ト 管 理 者 と し て 適 格 な プ ロ ジ ェ ク ト ・ マ ネ ー ジ ャ あ る い は ま た プ ロ ジ ェ グ ト ・ リ ー ダ を 任 命 し た 上 で ， プ ロ ジ ェ ク ト 毎 に ， 進 捗 管 理 ， 品 質 管 理 ， 要 員 管 理 ， 予 算 管 理 ， シ ス テ ム 変 更 管 理 等 を 行ってし、く必要が出てきたのである。 プロジェグト管理は，システム開発の生産性を向上させ，かつまた，計画通りに シ ス テ ム を 完 成 さ せ る た め の 手 法 で あ り ， シ ス テ ム 開 発 ラ イ フ サ イ ク ル

(

S

y

s

-tem Development L

i

f

e

C

y

c

l

e

;

S

D

L

C)

の 標 準 化 が 前 提 と な っ て い る 。 こ の 標 準 化 の 手 順 と し て は ， 通 常 ， 対 象 と な る シ ス テ ム に 合 致 し た 管 理 可 能 な ① 開 発 局 面 ， ② 各 局 面 を 構 成 す る 工 程 ， さ ら に ③ 各 工 程 に 含 ま れ る 作 業 項 目 を 定 義 し て い く フ ェ ー ズ ド ・ ア プ ロ ー チ

(

P

h

a

s

e

dA

p

p

r

o

a

c

h

)

が 用 い ら れ て い る (図

l

丈 〕 こ こ で 重 要 な の は ， 各 工 程 の 作 業 項 目 に は プ ロ ジ ェ ク ト 管 理 自 体 の 作 ことをいい，プロジェグト・チームは，開発対象となる範囲または局面の内容・特質に適 したスキノレを有する最少人員から構成されることになる。 (4) プロジェタト・チームの構成としては，開発局面にもよるが，プロジェクト管理者，シ ステム・アナリスト，プログラム・アナリスト，プログラマ，ライブラリアン，ユーザ部 門代表者，等が挙げられる。ただし，具体的な要員構成や投入要員数は，開発局面に応じ て異なってくることになる。 (5) システム開発の方法としては，このフェーズド・アプローチ以外にも，開発初期におい て厳密な要件定義をせずに発見的あるいは試行錯誤的に開発を行っていくプロトタイピ ング・アプローチが有望な候補として提唱されている。両者の比較およびプロトタイピン グ・アプローチを採った場合の内部統制に関する議論として，市田[3 ]を参照のこと。

208~ 第61巻 第3号 538 業 項 目 も 含 ま れ て い る と い う こ と で あ り ， 厳 密 な プ ロ ジ ェ グ ト 管 理 の 遂 行 に は ， 全 作 業 主 数 の

10%

前 後 が 必 要 と さ れ る 。 シ ス テ ム 開 発 ラ イ フ サ イ ク ル の 局 面 は ， 例 え ば ， ① 設 計 フ ェ ー ズ ， ② 製 造 フ ェ ー ズ ， ③ テ ス ト ・ フ ェ ー ズ に 大 き く 三 分 す る こ と が で き る 。 設 計 フ ェ ー ズ は ， ユ ー ザ ・ ニ ー ズ 調 査 に 基 づ く シ ス テ ム 要 件 の 選 定 で あ る 要 件 定 義 ， ユ ー ザ と シ ス テ ム と の イ ン タ ー フ ェ イ ス の 設 計 を 行 う 外 部 設 計 お よ び シ ス テ ム の 内 部 構 成 の 定 義 を 行 う 内 部 設 計 か ら 成 る シ ス テ ム 設 計 ， シ ス テ ム 機 能 の 細 分 化 に よ り サ ブ シ ス テ ム ， モ ジ ュ ー ル に 分 割 し た 上 で ， プ ロ グ ラ ム 仕 様 ( モ ジ ュ ラ 構 造 〉 設計フェース テスト"フェース 要

E

コ

4 1

運用テスl

o

合 ンステム設計 ￨モ

￨

ンステムテスト G 'II' ￨ 内 グ ラ ム 設 計

1

4

仁

E

スi G 合

¥

、

!

?

?

と

:

￨

ノ

(6 ) 凶2 システム開発ライフサイクノレ (6 ) システム開発ライフサイクノレの分け方や局面の用語法としては，この他にも様々なも のがある。例えば，システム設計をシステム基本設計とシステム詳細設計に分けるケー ス，同じく概要設計，機能設計，論理設計に分けるケース，さらに内部設計をプログラム 設計と同一視するケース等がある。なお，プログラミングとL、う用語法は，最広義には， プログラム設計，モジューノレ設計， コーディング，単体テスト，総合テストまでを含め， 最狭義には，コーディングおよびそれに前後するフローチャート作成，単体テストをいう 場合に用いられており，必ずしも 義的ではない。システム監査基準では，モジューノレ設 計から結合テストまでのプロセスという意味で用いていると解されるので，本稿でも使 用する場合にはこれに従っている。また，システムテストの後にユーザ部門の承認テスト (受け入れテスト〉を入れるケースもあるが，ここでのシステムテストでは，ユーザ部門 の代表者の参画を前提としているので，特に両者を分けていなし、。

539 企画・開発業務に対するシステム監査 -209-を決定するプログラム設計，モジュール内部の論理設計を行うモジュール設計 といった各フェーズに分かれる。また，製造フヱーズは， モジュール単位での コーディングを行うコーディング・フェーズから成る。さらに，テスト・フェー ズは，個々のモジューノレの完成度のテストを行う単体テスト，モジューノレの機 能グノレープ単位での完成度のテストを行う結合テスト，結合テストの終了した 機 能 グ ル ー プ 群 の す べ て を 連 結 し て 総 合 的 な 機 能 テ ス ト を 行 う シ ス テ ム テ ス ト，完成したシステムを実運用と同一条件で稼動させ，ユーザの訓練をも含め た最終チェックを行う運用テストといった各フェーズに分かれる。 図

2

において，設計フェーズはトップダウン，テスト・フェーズはボトムアッ プの関係にあることを想定している。また， ここでのテスト・フェーズについ ては，各局面の流れの概念を簡略化するために，単体テスト終了後に，テスト 済 モ ジ ュ ー ル 聞 の 結 合 テ ス ト を 実 施 す る と い う 非 増 加 テ ス ト 法 を 想 定 し て い る。さらに図

2

は，設計フェーズとテスト・フェーズとの聞において，要件定 義と運用テスト，システム設計とシステムテスト，プログラム設計と結合テス ト，モジュール設計と単体テストがそれぞれ対応関係にあることを示している。 しかしながら，プログラミングおよびプログラム・テストに関しては，従来， 下位モジューノレから上位モジュールへと展開するボトムアップ方式が採られる こ と が 多 か っ た が ， プ ロ グ ラ ム と モ ジ ュ ー ル の 聞 の イ ン タ ー フ ェ イ ス を コ ン ピュータで検証するのがシステム開発の最終段階近くにならないと実施しえな いことから， トップダウン・プログラミング

(To

p

-Down Programming)

，すな わち，プログラムの実行IJ頃序に従ってコーディングとプログラム・テストを随 時行う方法がむしろ効果的であるとして提唱されている。この方法によると， 下位のモジュールのテスト時には，テスト済の上位レベルのそジュールを使用 することが可能となり，結果としてテスト用のドライパ・モジュールやスタブ・ モジュールの量は少なくなり，生産性や品質の向上に結びつくことになる。か (7) プログラム・テストとは，単体テストおよび結合テストを示す場合とテスト・フェーズ におけるすべてのテストを含める場合とがある。本稿は，前者の意味で使用している。

-210- 第61巻 第3号 540 かるテスト法は，増加法と呼ばれている。 シ ス テ ム 開 発 ラ イ フ サ イ ク ル を 可 能 に し て い る の は ， 設 計 フ ェ ー ズ に お け る 複 合 設 計 (CompositeDesign)と ， プ ロ グ ラ ミ ン グ ・ フ ェ ー ズ に お け る 構 造 化 コーディング (StructuredCoding)の手法である。前者は，構造化設計とも呼ば れ ， プ ロ グ ラ ム 設 計 段 階 で ， 各 プ ロ グ ラ ム 毎 の モ ジ ュ ラ 構 造 の 設 計 を 行 う た め の 手 法 で あ る 。 モ ジ ュ ラ 構 造 を 設 計 す る 際 ， プ ロ グ ラ ム 機 能 を ト ッ プ ダ ウ ン で 詳 細 化 し て 機 能 の 階 層 構 造 を 作 り ， 構 成 要 素 と な る

1

つ の 機 能 を 各 モ ジ ュ ー ル に 対 応 さ せ る と と も に ， モ ジ ュ ー ル 聞 の イ ン タ ー フ ェ イ ス を 明 確 に 定 義 し て お く と い う も の で あ る 。 後 者 は ， 構 造 化 プ ロ グ ラ ミ ン グ と も 呼 ば れ 1つ の イ ン プ ッ ト と ア ウ ト プ ッ ト の み を も っ プ ロ グ ラ ム で あ れ ば ， い か な る デ ー タ 処 理 の 論 理 で も

3

つ の 基 本 的 ノ ミ タ ー ン ， す な わ ち ， 連 続

(SEQUENCE)

・ 選 択

(

I

F

THEN ELSE)

・反復

(DOWHILE)

を用いれば記述できること(構造化定 理)を利用して， コ ー デ ィ ン グ 作 業 を 標 準 化 し よ う と す る も の で あ る 。 こ れ に よ り ， テ ス ト ・ ケ ー ス の 設 定 や テ ス ト ・ デ ー タ の 作 成 が 容 易 と な り ， 品 質 の 向 上 が 図 ら れ る と と も に ， モ ジ ュ ー ル の 部 品 化 に よ る シ ス テ ム 開 発 の 効 率 化 や メ イ ン テ ナ ン ス の 向 上 も 達 成 さ れ る こ と に な る 。 こ の 他 ， シ ス テ ム 開 発 の 効 率 化 に あ た っ て ， プ ロ グ ラ ミ ン グ 支 援 ， テ ス ト 支 援 ， 保 守 支 援 ， 設 計 支 援 ， 要 求 定 義 支 援 等 と い っ た 各 種 開 発 支 援 ツ ー ル を 利 用 す る こ と も 有 効 で あ る が ， 実 際 に 利用されているケースは未だ多いとはいえない状況である。 (8) ただし，ボトムアップ・プログラミングは必然、的に非増加法のみに結び付いているわけ ではない。テスト方法については，非増加法よりも増加法の方が効率的であるとされてい るが，プログラミングについては，ボトムアップ方式とトップダウン方式のいずれが効率 的かはケース・パイ・ケースであるといえる。なお，非増加法と噌加法の対比，そしてま たボトムアッフ。方式とトップダウン方式の対比についての詳細な議論として，松尾訳 [13J，玉井[8 J，園友[5 Jを参照のこと。 (9) システム開発の効率化のための技法を体系化したものとして，例えば， 1 B M社の開発 した効果的プログラム開発技法(ImporovedProgramming Technologies; IPT)等があ る。複合設計や構造化コーディングを初めとする効果的プログラミング開発投法につい て詳細に解説したものとして，園友[5

J

がある。 (10) 利用状況については，情報サービス産業協会編[7

J

206-208ページを参照のこと。各 種開発支援ツーノレの紹介としては，中原・三次編 [10JIII編 3章および 4章， さらに情報 サービス産業協会編[7]第2部第 2章を参照のこと。

541 企画・開発業務に対するシステム監査 -211 プロジェグト・チームにあっては， メンバ信人間の能力のパラアキをなくす とともに，安定した品質を確保するために， ドキュメンテーションの標準化も また重要!となる。 ドキコメンテーションは，プロジェクト・チーム内のメンバ 間ばかりでなく，プロジェグト・チーム聞のコミュニケーションを円滑化し， システム移行後のメインテナンスを確実なものにする上で必要となる。

HIP

o

(

H

i

e

r

a

r

c

h

y

p

l

u

s

l

n

p

u

t

P

r

o

c

e

s

s

O

u

t

p

u

t

)

や

NS

チャート

(

Na

s

s

i

-

S

c

h

-n

e

i

d

e

r

m

a

n

C

h

a

r

t

)

は，ドキュメンテーションのための有力な方法論を提供して いる。開発手順・作業の標準化のためのドキュメントとしては，開発マニュア ルが重要で、あり，技術動向に合わせて絶えずアップデイトを図っていく必要が ある。他方，システムとユーザとのインターフェイスのためのドキコメントと しては，ユーザ・マニュアノレがあるが，何よりユーザにとって理解可能なもの でなければならない。こうした一連のドキュメントは，システムの変更・修正 時において速やかに改訂されなければならない。特に，設計フェーズにおいて は，部分的な変更・修正は頻繁に生じることになるので，それに伴い改訂作業 も絶えず行ってL、く必要性がある。 ドキュメントのための保守ツーノレとして， 改訂作業の自動化機能を備えたドキュメント自動化システムが開発されてい る。

I

I

I

.

企画・開発業務に対するシステム監査 我が国においてはシステム監査の歴史は未だ浅く，稼動後のシステムに対し てシステム監査を実施している割合も決して高いとはいえない。金融業および 官公庁といった公共性の高い分野を除けば，システムの企画・開発段階からシ ステム監査を導入しているケースは極めて少ないといわなければならな〈!?し かしながら，システム開発の規模が拡大し，開発に要する資金や期間が増大す るにつれ，システム開発に伴うリスクも増大し，私的企業であれば，開発の遅 (11) 図 友 [5

J

第4章，第7章および付録Aを参照のこと。 (12) 中原・三次編[10J248-252ページを参照のこと。なお，利用状況については，情報サー ビス産業協会編[7 J 205-206ページを参照のこと。 (3) 日本情報処理開発協会編[l1J184 -185ベージおよび458-460ページを参加のこと。

212- 第61巻 第3号 542 延・失敗は企業存続の基盤を揺るがすことにもなりかねなし、。さらに，近い将 来において， ソフトウェア・クライシスといわれる開発要員不足が深刻な問題 ともなっており，システム開発の効率化は差し追った重要課題といえる。また， 通信システムが普及するに伴い，コンピュータ・ネットワークに侵入して，デー タ改窟・破壊を行うといったコンビュータ犯罪やプライパシーの侵害が多発し てきており，コンピュータ・システムの安全性も深刻な社会問題となりつつあ る。このため， システム企画・開発段階からアクセス・コントロール等のセキュ リティ対策を綿密に講じて，安全性の高いシステムを構築していかなければな らなし、。したがって，かかる問題を克服するためにも，プロジェクト管理を徹 底するとともに，企闘・開発段階よりシステム監査を実施し，システムの安全 性・信頼性・効率性を確保することが必要となるのである。 企画・開発業務に対して，システム監査を実施しようとする場合，アプロー チ方法としては，①継続的監査，②完成前監査，③稼動後監査，④局面監査の 四つが挙げられる。継続的監査とは，企画ないし開発プロジェクト・チームに， システム監査人が常に関与し，その全過程を通じて継続的に監査を実施するこ とをし、う。完成前監査および稼動後監査では，企画・開発段階ではシステム監 査人は関与せず，前者は本番移行直前に，そしてまた，後者は本番移行直後に 監査を実施する。局面監査は，システム開発ライアサイクルの各局面毎にスポッ ト的に監査を実施し，監査意見をフィードバッグさせるというものである。そ れぞれのアプローチ方法の長所・短所をまとめると表

1

の様になる。 システム監査人自らがプロジェクト・チームに参画して，企画・開発業務に 絶えず関与し，監督することは，システム監査人の独立性を損いかねないとい う問題以前に，本来それはプロジェクト管理者の職務であるといえる。この意 (14) 日本情報処理開発協会編 [llJ 1編6部l章および3章を参照のこと。 (15) 日本情報処理開発協会編 [llJ II編l部2章および3章を参照のこと。 (16) 青山監査法人システム監査部編 [lJ252-253ページを参照。 (17) 事前監査と事後監査という分類によれば，前者には①継続的監査と④局面監査とが該 当し，後者には②完成前致査と③稼動後監査とが該当することになる。なお，会計監査に おいては r継続弦査」とL、う用語があるが，ここでの継続的監査と同義ではない。「継続 監査」については，森 [14J82-83ページを参照のこと。

543 アプローチ方法 継 続 的 監 査 完 成 前 監 査 稼 動 後 監 査 局 面 監 査 企画・開発業務に対するシステム監査 -213 (8) 表1 開発フロジェグトの監査アプローチ方法の比較 長 所 短 所 1 内部統制が不備である場合に 1 監 査 人 の 独 立 性 が 失 わ れ や す 指導的機能を発揮できる。 く，批判的機能の発揮が困難とな 2 内部統制に関する改善を適時 る。 行っていくことヵ:できる。 2 システム開発の生産性の低下を 3 問題の早期発見・事前解決を 招く恐れがある。 図ることができる。 3 監査コストが増大する。 1 監査の実施を最小限に留め， 1 問題が発見されても，解決に費 監査コストを最小化できる。 用と時間がかかる。 2 稼動前にシステムをレビュー 2 時間と費用の制約から対処しう することができる。 る問題が限定され，開発遅延や予 算超過といったリスグも大きい。 1 監査の実施を最小限に留め， 1 稼動後に生じたトラフツレを回避 監査コストを最小化できる。 することができない。 2 システムの稼動状況を確認し 2 次期開発に意見をフィードバッ 報告することができる。 クできても，稼動しているシステ ムの問題解決はかなりの制約を受 ける。 1 費用対効果の点で，監査効率 l フェーズド・アプローチに従っ を最大化することができる。 たプロジェタト管理が実施されて 2 最小費用で，局面毎に内部統 いることが前提となる。 制について勧告できる。 2 徽密な監査計画が要求される。 味で，内部統(舗が整備されていない場合や，システム監査導入の初期段階にお いて，システム監査人がその指導的機能をフルに発揮す町る必要があるケースで は，継続的監査も意義を有しているといえる。さらにまた，システム監査導入 の初期段階において，システム監査人の不足から，完成前監査ないし稼動後監 査を過渡的に実施することも止むを得ないところである。 (18) 青山監査法人システム監査部編[1] 253ページの表1-4-1をもとに，加筆・修正し ている。 (19) 内部統制とは，企業目標達成のための経営者機能に関する「経営統制J.業務遂行に関 する「業務統制J.財産保全と会計記録の信頼性に関する「会計統制」の三つから構成さ れるが，本稿では，企画・開発業務を有効に機能させるための業務統制をプロジェクト管 理として位置付けている。

-214- 第61巻 第3号 544 いずれにせよ，本来システム監査人の採るべき監査のアプローチ方法として は，監査効率の点からいっても，局面監査が最も適しているといえる。局面監 査 の ア プ ロ ー チ に よ れ ば ， シ ス テ ム 監 査 人 は ， シ ス テ ム 開 発 ラ イ フ サ イ ク ル に 合 致 し た 局 面 毎 に 監 査 計 画 を 立 て ， 所 定 の 監 査 手 順 に 従 っ て シ ス テ ム 監 査 を 実 施することになる。システム監査人の不足から，すべての開発局面についてシ ステム監査を実施することが困難であり，いくつかの重要局面〔例えば，要求 定義，システム設計，システムテスト等〉に限定して実施するケースもあろう が，この場合，省略した局面をも含めて監査対象としなければならない。ただ し，この場合には，監査意見のフィードバックの適時性が損われる危険性は避 けられないことになろう。 ところで，前掲図

2

における開発局面は単に開発手順のフローチャートを示 しているにすぎず，局面毎の全工程がすべて終了した後に次期局面に移るとい うことを意味しているわけてずはない。別言すれば，これは開発局面に重なり合っ ている部分が存在しているということであり，計画と実績との聞にギャップが (22) 生じるのも主としてこの部分である。図

3

および図

4

に見られるように，右下 がりの境界線においては，前後の局面が同時進行していることを意味している。 例えば，設計フェーズとプログラミング・フェーズとの間においては，プログ ラム仕様の変更による修正作業が生じることが多く，また，プログラミング・ フェーズ内においても， コーディングと単体テスト，結合テストにおいては絶 えずデノミッギングを繰り返しながら，モジュールを構築していくことになる。 (20) 局面弦査において，各局面毎のシステム監査人の指摘・勧告が効果的にフィードバッタ されるためには，プロジェグト管理者のレヒューだけでなく，システム致査人のレビュー 結果をフィードパックできるように，予め開発プロジェクトのスケジュールを組んでお くことが必要となる。 (21) システム監査基準の一般基準51iiii:査計画(2ゅでは，重点監査テーマを基本最査計画に 記載することを要求しているが，これは決して局面監査において重要な局商に限定して 弦査を実施すべきである〈あるいは，実施してもよしうということを意味していると解す べきではなし、。 (22) 図 3および図 4は，基本的にはそれぞれ盟友[5 ] 181ベージ図 81および 187ベージ 図 88に従っているが，本稿で使用している用語に統ーしているほか，プロジェクト管理 の工程を含めている。 (23) システム監査人自らが膨大な量のプログラム・リストをチェックしたり，単体テスト，

545 企画・開発業務に対するシステム監査 -215 7 ンパワ l プロジェクト管理 時間 図3 ボトムアップ・ブログラとングによるシヌテム開発ライフサイクノレ しかしながら，システム監査人が局面監査を実施しようとする場合， こうした 現実的な問題が監査スケジュールを設定するのを困難にしている。したがって， 当初の監査計画は弾力的なものであることが望ましく，システム監査人の指 摘・勧告が有効にフィードパックされるように局面監査を実施していくには， 監査実施時期のタイミングを逸しないよう，監査スケジュールを慎重に立てる とともに，実際の開発スケジュールの進捗度に合わせて，随時見直していくこ とが必要となる。 企画・開発業務についてシステム監査を実施する場合，監査対象としてはま ず，プロジェクト管理体制とプロジェクト管理活動の二つの側面が考えられる。 前者は，システム開発において前提となる管理体制が適切に整備されているか 結合テストを独自に実施すべきであるというわけではない。プログラム・テストに関して は，あくまで開発マZ ユアノレおよびテスト計画・仕様書に従っているか，プロジェクト管 理(特に進捗管理と品質管理〕が実行されているか，所定のドキュメントが作成され，権 限者の承認を得ているかを確認するに留まる。 (24) ただし，局面監査といっても，開発局面の終結時になって初めてシステム監査人が関与 するとL、う意味ではなく，システム監査人の指摘・勧告がシステム開発の遅延を招くこと なく，なおかつ有効にフィードパックされるよう，システム監査人は重要な工程ないし作 業項目について適時レビューしておく必要がある。

-216ー _第61_{巻 第}3_{号 546} プログラム設計 モジュール設計 コーディング 単 体 テ ス ト 結 合 テ ス ト マ ン パ ワ プロジェクト管理 時間 図4 トップダウン・プログラミングによるシステム開発ライフサイクノレ どうかに，そしてまた後者は，実際のシステム開発にあたって管理体制が目的 通り機能しているかどうかにかかわっている。システム監査の導入初期の段階 においては，内部統制の整備状況(したがってまた，プロジェクト管理体制〉 の適否が重要な監査対象となるが，システム監査の実施回数を重ねるにつれて， 内部統制の実施状況(したがってまた，プロジェク卜管理活動〉にウエイトが 移っていくことになろう。 このように，システム監査人は，開発プロジェグトの監査にあたり，まず第 一にプロジェクト管理体制の適否について確認し，必要に応じて助言，勧告を 行わなければならなし、。その上で，システム開発ライフサイクルに従って，各 局面毎のプロジェクト管理活動の実施状況の適否をレビューすることになる。 企画段階において，システム監査人自らが調査・分析，開発検討を行ったり， またシステムテスト段階において，コンピュータ利用監査として，種々のコン ピュータ利用監査技法によってシステム監査人自らがテストを実施することも あるが，通常はコンピュータ周辺監査として，内部統制質

F

d

蓄を利用したり， (25) 内部統制質問書のガイドラインとして，日本公認会計士協会電子計算機会計委員会が 昭和55年12月にiEDPシステムの内部統制質問書について」を公表している。なお， そこでの問題点と改善点を指摘したものとして，大矢知[4 ]を参照のこと。

-217ー 企画・開発業務に対するシステム監査 骨一ーー一一ーーーー一一一一-547 運用テスト

A

U

ー-> システムテスト

ー

→

，

モー一一ーー一一---一ー一一一 ンステム設計

合

結合テスト <E--ー一一一四一一一一ー一一ーー

G

プログラム設計 ーさ沙

合

単体テスト 時ー一ー一一一一ー一一ー一一ー一一

G

モジュール設計

グ

システム開発ライフサイクノレにおけるドキュメント 図5

-218- 第61巻 第3号 548 開発局面毎に作成されるドキュメントをレピコーすることによって，プロジェ グト管理の妥当性を確認することになる。 システム開発ライフサイクルにおけるドキュメンテーションには，開発の規 模に応じて様々なものが設定されるが，代表的なものを挙げると図

5

の様にな る。

I

V

.

システム監査基準〔企画・開発業務に対する実施基準〕 における問題点 システム監査基準の掲げる企画・開発業務に対する実施基準は，アベンディ クスとして稿末に掲載しているが，本節ではそこでの問題点および改善案につ いて，構成上，内容上の二つの観点から取り上げることにする。 (1) 構成上の問題 まず第一に，システム監査基準では r基準の考え方2基本的事項(2)Jにおい て r実施基準は，企画業務，開発業務，運用業務の流れに沿ってシステム監査 人が監査を行うに当たっての観点と内容について定めたものである」とされて いるものの，企画・開発業務に対する実施基準の各項目の関係に一貫性が欠け ているという点である。換言すれば，実施基準の各項目の配列がシステム監査 のライフサイクルに必ずしも一致していないということである。企画業務に対 する実施基準では r要員管理」を除けば，監査項目が「計画Jr調査・分析」 「開発検討」の順となっている。このような背景として，まず計画書を立案・ 作成した上で，調査・分析を経て，開発検討を行うという理解があるものと思 われる。しかしながら，企画業務自体の手順としては，実際には，ユーザ・ニー ズ調査や現状分析等の調査・分析を行い，開発検討による実現可能性の要件を 満たした上で，システム計画書を具体的に立案・作成す町ることになる。したがっ て，この企画業務に対する実施基準では，企画業務の流れにしたがって監査を (26) 計図書，仕様書，帳票，マニュアノレ等のドキュメントの名称および種類，さらにまた作 成時期は，システムを開発する個々の組織によって異なっている。ここで挙げているのは あくまで一例にすぎない。

企画・開発業務に対するシステム監査 549 2 7i Qd 実施するというよりも，計画書の立案・作成後にシステム監査人が独自に調査・ 分析をチェックし，その後に開発の実現可能性についてチェッグするというこ とを意図しているといえる。しかし，システム計画書の作成後になってしまう と，たとえシステム監査人が指摘・勧告を行って，そのフィードパックを図る としても，企画業務の遅延を招いてしまうことになる。したがって，企画プロ ジェグト・チームの作業と同時並行的に，システム監査人自らも調査・分析， そしてまた開発検討を行って，各種調査書・分析結果・開発検討の素案がまと まった段階で意見を随時フィードパックさせる必要があるといえよう。他方， 開発業務に対する実施基準では，監査項目が「開発手順Ji要 員 管 理Jiシステ ム設計Jiプログラム設計JiプログラミングJiシステム・テスト」の順となっ ている。このうち iシステム設計」以降は，確かにシステム開発ライフサイク ルのフェーズに沿っているといえる。しかしながら i開発手順」はシステム開 発の前提となる開発体制(および開発方法)にかかわるものであり i要員管理」 もシステム開発ライフサイクルを通してチェッグすべき性格のものといえる。 その一方で i運用テスト」やそれに伴う「システム移行」についての監査項目 が欠如している。 第二に，監査項目とそこでの基準との聞に一貫性が欠けているという点であ る。これは，企画業務の実施基準の「計画」および開発業務の実施基準の「開 発手順」が該当している。すなわち，前者においては， (1)の長期・短期計画の 策定と見直し， .(2)前段の(個別開発)計画に対する承認ルーノレは，いわばシス テム開発の前提となる内部統制の整備状況に関するものであるのに対して， (2) 後段の(個別開発〉計画の承認の有無や(3)以降の(個別開発〉計画書(すなわ ち，システム計画書〉の記載事項の充足性は，企画業務終了時のチエググ・ポ (27) システム監査基準においては，プログラミングとL、う用語によって，モジューノレ設計， コーディング，単体テスト，結合テストの局面を含めて表している。第 II節で指摘したよ うに，モジューノレ設計， コーディングおよびプログラム・テストに関しては， ドップダウ ン方式とボトムアァプ方式とがあり，むしろシステム監査基準による局面の設定方法の 方が適しているといえるかもしれなし、。しかしながら，プロトタイピング方式を採用して いる場合には，システム監査基準では対応できないことになる。この問題については，稿 を改めて検討したし、。

-220- 第61巻 第3号 550 イントである。したがって i計画」という監査項目の中に異なるレベルのもの が混在しているといわなければならなし、。また後者の「開発手順」においては， (1)は開発手IJ債の妥当性であるのに対して， (2)は開発マニュアルの標準化・理解 可能性および

(

3

)

は開発マニュアルのアップ・デイトを挙げている。しかし，開 発手順は開発マニュアルに記載されるべき性格のものであり，むしろここでの 監査項目は「開発マニュアル」とした方が適切であろう。 第三に，企画・開発業務に共通の監査項目とシステム開発ライフサイクルの 特定局面の監査項目とが混在している点である。例えば i要員管理」は企画・ 開発業務に対する実施基準の双方に挙がっている。〈さらにまた，運用業務に対 する実施基準の中にも含まれている。〉しかしながら，その一方で，企画・開発 業務においても多く見られる外部委託に関するチェック・ポイントは，運用業 務に対する実施基準の中においてのみ挙げられており，果たして適切であるか どうか疑問視される。 したがって，構成面についていえば，前提となるプロジェクト管理の整備状 況に関する監査項目(例えば i長期・短期システム化計画j，i承認ノレールj， 「開発手順j，i開発マニュアル」等)と個々のプロジェグト開発毎のプロジz クト管理の実施状況に関する監査項目(例えば i進捗管理j，i品質管理!j，iド キュメンテーション」等〉を分けるとともに，システム開発ライフサイクルの 各フェーズ毎の監査項目と企画・開発業務に共通の監査項目(例えば「要員管 理」や「外部委託j)とを分ける必要があろう。いずれにしても，システム監査 人の指摘・勧告が有効にフィードパックされるように，システム監査人の監査 実施時期に合わせた体系化が必要で、あるといわなければならなし、。 (2) 内容上の問題 まず第一に，システム監査基準の中の実施基準は，いずれも「……されてい るか」あるいはまた i，・・"，."が適切か」という，いわばチェックリストの性格を 有したものとなっている点である。しかしながら，イエスかノーかの二者択一 では単純に判断することが困難であるような基準が多く，実質的な内容まで立 ち入ってはいない。これは，実施基準に従ってシステム監査人が内部統制質問

551 企画・開発業務に対するシステム監査 -221 書あるし、はまたチェックリストを作成し，関係者に対してインタビューや質問 等によって回答を求めようとする場合にまず問題となろう。また，実施基準を 基にシステム監査人自らがチェックを行う場合でも，監査マニュアノ

J

において 判断基準を予め明確化しておかなければ，第三者的な立場から指導的機能を果 たすことは難しいといわなければならない。「基準の考え方2基本的事項(4)Jで は i、ンステム監査人は，業務に応じ実施基準を適切に運用するための監査マ ニュアノレ等を整備すること」としているが，実施基準自体は何ら具体的な判断 基準を与えてはいない。 第二に，個々の監査項目の中に実質的に意味の乏しいものが含まれている点 が挙げられる。例えば，企画業務に対する実施基準の「計画」では， (3)以降で システム計画書の記載内容の充足性が問われているが，内容の妥当性について までは問われていなL、。また，開発業務に対する実施基準の「システム設計」 では， (2)および(3)においてシステム設計書に盛り込むべき要件の充足性が問わ れているが iシステム・テスト」ではかかる要件の確認が具体的には要求され ていない。そしてまた， (4)では移行計画および運用計画が記載要件となってい るが，同じく両計画が適切に実施されたかどうかについての確認は要求されて いない。さらに iプログラミング」では， (1)で「プログラム仕様どおり正確に プログラミングされているか」がチェック・ポイントとなっているが，システ ム監査人自らが膨大な量のコーディングの正確性を逐一チェックすることは不 可能に近いので，むしろ単体テスト，結合テストの結果についてチェックし， モ ジ ュ ー ル な い し プ ロ グ ラ ム の 完 全 性 を 確 認 す る こ と に な ろ う 。 そ の 意 味 で も， (3)で「プログラム・テストの結果は，すべて記録されているか」を問うだ けでは不十分であるといわなければならなし、。 (4)では「重要プログラムは，プ (28) 致査マニュアノレについては，例えば，小早川[6 ]を参照のこと。

(

2

9

)

確かに，内容の妥当性については i調査・分析」および「開発検討」の箇所でチェッ ク・ポイントとして挙げられてはいるが，(1)構成上の問題で指摘したように，

E

t

査の手順 としては逆であるといえよう。 (30) 前述したように，これは「運用テスト」と「システム移行」の局面が欠如していること に起因している。 (31) この点については注(24)でも，指摘した通りである。

-222 第61巻 第3号 552 ロ グ ラ ム 作 成 者 以 外 の 者 に よ っ て テ ス ト さ れ て い る か 」 を 問 う て い る が ， 重 要 性 の 程 度 に か か わ ら ず ， テ ス ト 結 果 に 基 づ く 修 正 作 業 は 担 当 プ ロ グ ラ マ 自 ら が 実 施 す る に せ よ ， テ ス ト の 実 施 は 原 則 と し て 担 当 プ ロ グ ラ マ 以 外 の 者 が あ た る ことが適切で、あろう。「システム・テスト」では，システム監査人自らがシステ ム テ ス ト に 関 与 す る な り ， 独 自 に シ ス テ ム テ ス ト を 実 施 す る こ と は 要 件 と な っ ていない。システム機能の最終チェック段階であるシステムテストにおいては， コ ン ビ ュ ー タ 周 辺 監 査 だ け で な く ， シ ス テ ム 監 査 人 自 ら が テ ス ト ・ デ ー タ 法 等 の コ ン ビ ュ ー タ 利 用 監 査 に よ っ て 独 自 に シ ス テ ム テ ス ト の 一 部 を 実 施 し て み る こ と の 意 義 は 高 い と い え る 。 仮 に そ の 実 施 が 不 可 能 で あ る 場 合 で あ っ て も ， 少 な く と も シ ス テ ム 監 査 人 が シ ス テ ム テ ス ト に 参 加 し て ， 客 観 的 立 場 か ら シ ス テ ム テ ス ト 計 画 お よ び シ ス テ ム テ ス ト 仕 様 書 へ の 準 拠 性 を 確 認 す る 必 要 が あ ろ う。 第 三 に ， 実 施 基 準 で 挙 げ て い る チzッ グ ・ ポ イ ン ト が ， 多 様 化 し て い る コ ン ピ ュ ー タ ・ シ ス テ ム の 形 態 に 必 ず し も 対 応 し て い な い と い う 点 で あ る 。 開 発 業 務 に 対 す る 実 施 基 準 の 「 シ ス テ ム 設 計 」 の(7)でデータベース構造， (8)でデータ ベ ー ス の ア グ セ ス ・ コ ン ト ロ ー ル に 言 及 し て い る よ う に ， シ ス テ ム 監 査 基 準 は デ ー タ ベ ー ス を 中 核 と す る 大 型 ホ ス ト ・ コ ン ピ コ ー タ の ノ ミ ッ チ 処 理 な い し オ ン ラ イ ン ・ リ ア ル タ イ ム 処 理 シ ス テ ム を 想 定 し て い る と 考 え ら れ る 。 し か し な が ら，これは逆にいって， ロ ー カ ル エ リ ア ・ ネ ッ ト ワ ー ク に よ る 分 散 処 理 シ ス テ ムやミニコン，オフコン，ノfソ コ ン 等 に よ る 小 規 模 シ ス テ ム に つ い て は 対 象 と (32) ただし，このことは，システム監査人が膨大な作業時間とコストを要するシステムテス トを再現すべきであるという意味ではなし、。あくまで，システムテストにおけるプロジェ クト管理が満足すべきものであるならば，テスト・データを検討し，サンプリングによっ て主要機能に対して確認を得るなり，監査上必要であれば追加的なテストを実施するこ とで十分であるといえよう。その際，汎周監査ソストウェア・パッケージを利用すること も一計である。なお，コンピュータ利用監査技法については，青山監査法人システム監査 部 編 [1 ]第I編第 3章を参照のこと。 (33) システムテストにシステム監査人が関与するということは，システムテスト・チームの 一員として参加するということを意味するものではない。むしろ，会計監査でいう「立合」 に相当するものであり，テスト・フェーズにおいては，システムテストに限らず，テスト 実施体制なり，テスト実施状況なりを第三者的立場から評価することが必要となる。

553 企画・開発業務に対するシステム監査 -223 していないことを意味している。 システム監査基準を補足することを目的として，その後『システム監査基準 解説書』や『システム監査

Q&AllO~ が公表され，システム監査基準の理解・

普及を図っている。『システム監査基準解説書』では，各基準毎に説明が加えら れ，複数の監査ポイントが掲げられている。しかしながら，監査ポイントにつ いてみれば，基準の文章を単にブレークダウンしたもののほか，各監査項目と の関連性はあっても基準の文章のみからは演縛的に導出しえないものも多い。 これは特に，システム監査基準自体が包括性に欠けていることを意味している。 システム監査基準は，簡潔で理解容易なものであることが望ましいが，基準と して包括的であることもまた必要である。この問題は，そもそも現行のシステ ム監査基準が，基準と準則とし、う形式を採らずに，両者をともに含めてしまっ ているところに起因しているといえよう。したがって，解説書や

Q&A

による フォローといった変則的な体裁をいつまでも採り続けることは決して好ましい ものではなく，早急に全面的かっ根本的な改訂が待たれるところである。

v

.

結 システム監査の歴史が浅い我が園において，システム監査を普及・定着させ る上で rシステム監査基準」の果たしている役割・責務は大きいといわなけれ ばならない。特に rシステム監査技術者試験」制度が発足するに及んで，受験 者はなべて「システム監査基準」に取り組み rシステム監査基準」を身に付け た合格者がシステム監査人として認定され，現場でシステム監査を実施してい くことになる。確かに，権威ある団体がシステム監査に関する基準を制定し， イニシアティブをとってその啓蒙を図りながら，システム監査制度を確立して いくことは，単に自然発生的な形成を待つよりもはるかに効率的であるといえ る。しかしながらその半面，将来の我が国におけるシステム監査体制に与える 影響の大きさゆえに，憤重な配慮が大いに望まれるところでもある。 (34) た だ し シ ス テ ム 監 査Q&A110;では.rV運用業務の監査5その他」において，こ れらのシステムについても言及している。

-224- 第61巻 第3号 554 し た が っ て ， 今 後 と も 「 シ ス テ ム 監 査 基 準 」 が そ の イ ユ シ ア テ ィ ブ を 健 全 か っ 効 果 的 に 発 揮 し て い く に は ， 社 会 的 ・ 技 術 的 動 向 に 合 わ せ て 随 時 見 直 し を 図 っ て い く こ と に よ っ て ， シ ス テ ム 監 査 の ガ イ ド ラ イ ン と し て の 妥 当 性 を 常 に 保 持 し 続 け る こ と が 必 要 で 、 あ る と い え よ う 。 参 考 文 献 [ 1

J

青山監査法人システム監査部編『高度情報化時代のシステム監査の方法ーコンビュー タ・セキュリティ対策のあり方ー』中央経済社 1986年 [ 2 J 天野武門・他『システム監査Q&A1l 0.~ 日本情報処理開発協会 1987年 [ 3 J 市田陽児「システム開発の新潮流と内部統制jW情報科学研究~(日本大学)第2号 1986 年 [ 4

J

大矢知浩司「システム監査と内部統制 内部統制質問書の自動化に向けて j W企業会 計』第39巻 第3号 1987年 [ 5 J 園友義久『効果的プログラム開発技法~ (第2版〉近代科学社 1987年 [ 6

J

小早川久佳「システム監査マニュアノレ等の整備についてj W企業会計』第37巻 第5号 1985年 [ 7 J 情報サービス産業協会編 f情報サービス産業白書1986Jコンビュータ・エイジ社1986 年 [ 8 J 玉井哲雄・他『ソフトウェアのテスト技法』共立出版株式会社 1988年

[

9

J

通商産業省機械情報産業局監修『システム監査基準解説書』日本情報処理開発協会 1975年 [10J 中原啓一・三次衛編『新版システムスエンジニプハンドブック』オーム社 1986年 [l1J 日本情報処理開発協会編『情報化白書 1988J日本情報処理開発協会 1988年 [12J 檎田信男「システム監査固有の対象と殴査的性格ー『システム践査は監査か』に関連し てーj W情報科学研究所J(日本大学〉第2号 1986年 [13J 松尾正信訳『ソフトウェア・テストの技法」近代科学社 1987年 [14J 森賞「ディスクロージャーとシステム監査j W企業会計』第38巻 第10号 1986年

555 実施基準 I.企画業務 項 目 企画・開発業務に対するシステム監査 アペンディクス l システム監査基準(抜粋〕 内 何 』 廿 -225-1 計 画

I

(1) システム開発の長期及び短期計画が策定され，定期的かつ情況の 変化に対応した克直Lが行われているか。 (2) 計画の規模・重要性等を勘案した承認ノレーノレが確立されているか。 また，計画はこれらノレーノレに従い権限者の承認を得ているか。 (3) 計画書には， 目的，手段，資金，期間，要員，設備等の項目が記 載されているか。 (4) 計画書には，他の業務との整合性を踏まえたシステム開発の優先 度が記載されているか。 (5) 計画書には，システム開発によって生ずる組織の変更，業務の改 廃についての対策が記載されているか。 (6) 計画警には，適切なセキュリティ対策が記載されているか。 2 調査・分析

I

(

]

)

ユーザ・ニーズの調査において，調査の対象，範囲，方法は適切 3 開発検討 4. 要員管理 カミ。 (2)現状分析には，ユーザが参画しているか。また，基礎資料の収集 及び分析結果の評価が適切に行われているか。 (3) 技術調査は，ハードウェア， ソフ「ウェアについて，内外の技術 予測まで含め広く行われているか。 (4) 電子計算機システムの停止・誤動作は，発生頻度，影響度，損害 額等の観点から分析されているか。 (5) システム導入によって生ずるエラー，データの漏洩・破壊・改ざ ん，不正使用，プライパシーの侵害等は，発生頻度，影響度，損害 額等の観点から分析されているか。 (6) システム導入に当たって関係する法律，制度等が全て調査されて L 、る治、。 (7) システム導入によって影響を受ける業務，管理体制，諸規定等は， 見直しを含めて検討が行われているか。 (8) システムのライフサイクノレを設定するに当たって，前提となる諸 条件が適切か。 (]) 開発計画を遂行する上で，必要な資金，要員，設備，期間等が確 保されているか。 (2) 開発計闘を遂行する上で，業務分担及び責任体制が妥当か。 (3) システム全体として信頼性・安全性・効率性が確保されるように， 機種及び個々の技術が選択されているか。 (4) システムの目的を達成し，かっ実現可能な代替案が作成・検討さ れているか。 (5) 開発及び運用費用の算出基礎は適切か。 (6) 効果の定量的，定性的評価は適切か。 (1)職務権限は明確に規定されているか。また，要員は権限外のこと を行っていないか。 (2) 要員の技術向上のため，効果的かつ定期的な教育・訓練が行われ ているか。

-226-II.開発業務 項 目 1 開発手順 2 要員管理 3 システム設計 4 プログラム設 計 5 プログラミン グ 6 システム・テ スト 第61巻 第3号 556 内 容 (1)開発手11際は，開発の規模・期間及びシステム特性等の観点から適切か。 (2) 開発マエュアノレは，標準化され，かっ作業内容がわかりやすく記 述されているか。 (3) 開発マニュアルは，技術進歩等に応じて改善されているか。 (1) 職務権限は明確に規定されているか。また，要員は権限外のこと を行っていないか。 (2) 残業時間，休暇の取得状況等が把握され，作業環境の改善に努め ているか。 (3) 要員の技術及びモラル向上のため，効果的かっ定期的な教育・司11 練が行われているか。 (4) 要員は，開発マニュアノレに習熟し，かつマニュアノレに従って開発 を行っているか。 (5) 要員に対し適切な健康診断及びカウンセリングが行われているか。 (1) システム設計書，ユーザ・''<.:::ュアルは，開発マニュアルに従っ て作成され，かつ権限者及びユーザの承認を得ているか。 (2) システム設計書には，電子計算機システムの障害対策が盛り込ま れているか。 (3) システム設計警には，セキュリティ確保のため各種コントロール が盛り込まれているか。 (4) システム設計書には，妥当な移行計画及び移行に伴う運用計画が 記載されているか。 (5) データのインテグリティ(一貫性，不変性等)が確保されるよう に設計されているか。 (6) ファイノレ仕様は， ピーク時を想定したアクセス時間，記憶容量等 の観点から適切か。 (7) コード及び入出力帳票の仕様は，ユーザが利用しやすく設計され ている泊、 (8) データベース構造は，利用形態に応じて設計されているか。 (9) データベースのアクセスは，適切にコントローノレされているか。 側 システム・テスト計画のg的，範囲，スケジューノレ等は適切か。 (1) システム設計書に基づいて，プログラム仕様が設計されているか。 (2) プログラム仕様の設計に当たって，技術的，論理的な矛盾が生じ た場合，システム設計の再検討が行われているか。 (3) プログラム仕様の標準化， モジュール等は，作業量，スケジュー ル，セキュリティ，保守等の観点から適切か。 (1) プログラム仕様どおり正確にプログラミングされているか。 (2) プログラミングに当たっての分担が適切か。また，管理者は作業 状況を的確に把握しているか。 (3) プログラム・テストの結果は，全て記録されているか。 (4) 重要プログラムは，プログラム作成者以外の者によってテストさ れているか。 (5) プログラム・ドキュメントは，開発マニュアノレに従って作成され ているか。 (1) テスト・データの作成及びテストの実施は，テスト計画に基づい て行われているか。 (2) テストは，プログラム作成者以外の者が行っているか。 (3) テストには，ユーザが参画しているか。 (4) テスト結果は，開発部門及びユーザ部門の責任者の承認を得ているか。 (5) テスト結果の記録，テスト・データが保管されているか。