日本版SOX法でプログラム開発に求められるもの：セキュリティツールで作る内部統制（8）（2/3 ページ）

[中島 浩光，＠IT]

「プログラム開発」で求められる統制活動

　では、プログラム開発で求められる統制活動にはどのようなものがあるのでしょうか？正しいアウトプットを開発するには以下の2つの条件を満たす必要があります。

1. 要件（アプリケーション統制）が正しいか（インプット）
   
   
2. 要件が正しく開発されているか（プロセス）

　この2つの視点に沿って、ポイントを説明します。

1. 要件（アプリケーション統制）は正しいか？

　「要件が正しいかどうか？」はどのようにして担保するのでしょうか。また、「正しい」とはどういうことでしょうか。

　会計基準などには「こういう基準が正しい」という、ある種「絶対的な正しさの基準」が存在し、その基準に従っていないものは必ず誤りになります。ところが統制活動においてはこのような“絶対的”な基準は存在しません。というのも統制活動はリスク管理の一環であり、リスクを低減させる方法は通常複数存在するため、その中の1つもしくは複数を選択する、また、場合によっては選択しないことになるからです。

　従って、「要件としての統制活動」が正しいかどうかは、何か別のものとの整合性、あるいは組織内の権威者や責任者による判断をもって担保する必要があるのです。

　そのため、以下のような点を考慮する必要があります。

（1）システム開発が企業の戦略・方針に従ったものであるか？

　これは評価・監査の対象となっているシステム開発が、企業として必要なものであるかどうかということです。具体的には、企業の戦略・ビジネス上の方針などに沿っているかどうかであり、経営層やしかるべきビジネスオーナーなど、承認権限のある人間の承認が得られているかどうかが重要になってきます。

　また、ITの戦略・方針の観点からは、もし社内の標準技術などがあれば、それらを使用しているかどうかも考慮する必要があります。

　上記のような点をチェックすることで、案件レベルでの正しさを担保します。

（2）設計・パッケージ選択・テストにおけるユーザー部門の参画

　これは案件に関してではなく、具体的な設計内容や機能の正しさについてユーザー部門が参加し、かつ承認しているかどうかということです。つまり、ユーザー部門の承認・判断により正しさを担保するのです。

　ただし、この段階ではシステムはまだ実装されていない状態であるため、実装後のテストの内容や結果についてもユーザー部門が参加し、再度承認する必要があります。

（3）導入後のレビュー

　システムを導入した後、実際に運用に乗せてみて、初めて出てくる問題や明らかになる要件もあります。そういった要件（新たな統制活動）の中に緊急に対処しなければならないもの、例えば不正に直結するような問題があったとしたら、すぐにシステムを改善することになるでしょう。

　そういった場合も想定し、システムが導入された後に統制活動が有効に機能しているかどうかをレビューすることが必要になります。

2. 要件が正しく開発されているか？

　実際の開発プロセスにおいて必要とされる要素に関しては、以下のような点を検証する必要があります。

（1）開発方法論の存在

　システム開発プロセスにおいても、プロセスの観点でのチェックが行われます。従って、システム開発プロセスの業務フローや業務記述書などの「開発方法論」が必要になります。

　開発方法論は「ソフトウェア開発ライフサイクル（Software Development Life Cycle: SDLC）」とも呼ばれます。こういった方法論が個別のシステム開発において定義されているかどうか、あるいはもし社内の標準としてそういった方法論を定めている場合、個別のシステム開発がそれを採用し、従っているかどうかをチェックする必要があります。

（2）要件定義フェイズにおけるセキュリティと完全性の検討

　開発方法論が存在したとしても、要件がきちんと定義されていなくてはなりません。従って、セキュリティやデータ処理の完全性、また、アプリケーション統制の要件定義が作業項目として入っているかどうかは、開発方法論において重要なポイントになります。

　また、方法論の中にそういった作業が設定されているかどうか（整備されているか）だけでなく、実際のシステム開発においてこれらの要件が検討されているか（運用されているか）もチェックされます。つまり成果物を検証されると考えてよいでしょう。

（3）システム調達の標準手続き

　システム開発においてはハードウェアやパッケージ、また、システム開発自体を外注することが多いと思われます。そこで、調達先の選定から実際の調達に至るまで、標準的な手続きが存在するか、また、それに沿った調達がされているかどうかがチェックされることになります。

（4）各種のテスト

　システム開発を行うときにまったくテストをせずに、本番環境でいきなり利用開始することはまずないと思いますが、実際にはテスト工程は軽視されがちです。

　しかし、システムが要件を満たしているかどうかは、実際に動かしてみなくては分からないため、要件を確認するためのテストは非常に重要です。実際にどのようなテストを行うかは、案件や開発手法によっても変わってくると思われますが、どちらにしてもテストを行うためのテスト戦略（方針）やテスト計画を早い段階で策定し、それに従ったテストを行っていくことが必要となります。

　また、業務システムの機能面のテストが重要であるのはもちろんですが、それだけではなくパフォーマンス／負荷テストやシステム間のインターフェイス、データ移行などについてもしっかりとテストしておくことが重要です。

（5）ユーザー研修

　ユーザー研修を「プログラム開発」の一部ととらえるか、統制環境の一部ととらえるかは微妙なのですが、開発された業務システムを利用者が正しく利用できるようにすることは非常に重要であるといってよいでしょう。

　そのため、ユーザーへの研修の必要性の有無や、研修に必要な資料および時間などをきちんと検討し、実施していくことが重要になります。