🍀概要
システム監査技術者試験 平成21年 午後2 問3について、AIを活用して、詳細分析した結果を示します。
本分析は、AIが問題文からその背景にある本質的な課題を深く掘り下げ、システム監査人が目指すべき理想像の一端を理解することに役立つよう、多角的な視点から考察したものです。これにより、単なる模範解答の提示に留まらず、論述問題を通して試される思考プロセスや問題解決のアプローチを深く理解するための示唆を提供します。
🧾問題・設問（AU-H21-1-PM2-Q3）
出典：情報処理推進機構 システム監査技術者試験 平成21年 午後2 問3(🔗取り扱いガイドライン)
📘問題
■タイトル
企画・開発段階における情報システムの信頼性確保に関するシステム監査について
■内容
組織が業務やサービス提供などをより効果的かつ効率よく行う上で，情報システムの果たす役割はますます広がってきている。その結果，情報システムの不具合や障害による業務・サービスの停止や機能低下の影響度は大きくなり，社会問題にまで発展するおそれもある。このような状況から，情報システムに対する信頼性確保の要請が高まっている。
企画・開発段階における情報システムの信頼性確保とは，情報システムが期待どおりの機能やサービスを提供できるように，設計・構築することをいう。そのためには，情報システムの不具合や障害などを未然に防止し，万が一，発生した場合にも影響範囲を最小限に抑えるためのハードウェアやアプリケーション，ネットワークなどのIT環境を構築することが重要となる。
また，情報システムに求められる信頼性の水準は，業務やサービス提供などの重要度，情報システムの不具合や障害による影響度などによって異なる。例えば，決済システムと人事システムとでは，ディスク障害によって業務が中断した場合の影蓉度や範囲に違いがあるので，それぞれの対応策は異なってくる。
このような点を踏まえて，システム監査人は，企画・開発段階における情報システムの監査において，当該情報システムの信頼性が確保されていることを確かめなければならない。
あなたの経験と考えに基づいて，設問ア～ウに従って論述せよ。
📗設問
■設問ア
あなたが関係した情報システムの概要と，業務やサービス提供において，当該情報システムに求められる信頼性について，800字以内で述べよ。
■設問イ
設問アで述べた情報システムの信頼性を確保するに当たり，企画・開発段階においてどのようなリスクと対応策を想定したか。関連する業務やサービス提供の重要度及び情報システムヘの影響度を含め，700字以上1,400字以内で具体的に述べよ。
■設問ウ
設問イで想定したリスクと対応策に対して，どのような点に留意して監査すべきか。IT環境の特徴などを踏まえて，700字以上1,400字以内で具体的に述べよ。
📔出題趣旨・採点講評(IPA)
■出題趣旨
情報システムに不具合や障害などが発生した場合における業務・サービスの停止や機能低下の影響度が大きくなっていることから，情報システムに対する信頼性確保の要請が高まっている。情報システムの信頼性確保においては，業務やサービス提供などの重要度，当該情報システムの不具合や障害による影響度などを考慮しなければならない。
本問では，システム監査人として，IT環境の特徴を踏まえた情報システムの信頼性確保を確かめるため，リスクと対応策を想定しながら企画・開発段階における監査を実施する知識や能力があるかどうかを評価する。
■採点講評
＜全問共通＞全体として，一般論を展開しただけの論述が目立った。出題趣旨から大きく外れたり，問題文を言い換えただけであったりした論述は論外としても，設問の趣旨を十分に理解し，受験者自らの経験や考えを反映するように心掛けてもらいたい。また，論述内容の意味のない重複，不要な空行，専門用語の誤りなどがないように注意してもらいたい。
＜問3＞問3（企画・開発段階における情報システムの信頼性確保に関するシステム監査について）は，オーソドックスなテーマであることから最も選択率が高かった。しかし，運用段階における監査についての論述や，プロジェクト管理，個人情報漏えい対策についての論述など，設問の趣旨から外れた解答が目立った。設問イ，ウでは，設問アで述べた情報システムとの関係を踏まえずに，一般的な内容にとどまった論述が多かった。設問ウでは監査実施上の留意点についての論述を求めたが，監査手続だけの論述も多く見受けられた。
🪄詳細分析(AI)
📝3行まとめ
- 【背景】情報システムの停止や障害が業務や社会に重大な影響を与えるため、企画・開発段階での信頼性確保が重要です。
- 【監査視点】監査では、システムの重要度や影響度に応じたリスク評価と、それに基づく信頼性設計・対応策の実施状況を確認します。
- 【行動・着眼点】監査人は、要件定義からテスト工程まで一貫して信頼性対策が組み込まれているかを、プロセスと成果物の両面から検証すべきです。
🧭企画・開発段階における情報システムの信頼性確保に関するシステム監査についての考察
1. 問題の背景と現状分析
- 現状の課題・問題点:
- 情報システムの役割が拡大し、その不具合や障害が事業や社会に与える影響が甚大になっている。
- システムの信頼性（期待通りに機能し続ける能力）は、運用段階で確保するものではなく、企画・開発段階で作り込む（Built-in）必要があるという認識が不足している。
- システムの信頼性要件が、そのシステムの重要度や影響度に応じて定義されていない。例えば、決済システムと人事システムに、同じレベルの信頼性対策が適用されている、あるいはどちらも考慮されていない。
- 開発プロジェクトが、機能要件の実装やスケジュールの遵守を優先するあまり、非機能要件である信頼性の確保がおろそかになりがちである。
- 変化の必要性の背景:
- 社会インフラ化する情報システム: 情報システムが、一企業の業務ツールから、社会活動を支えるインフラへとその役割を変え、停止した場合の社会的影響が許容できないレベルになった。
- 手戻りコストの増大: 開発の後工程（テスト、運用）で信頼性に関する問題が発覚すると、その修正には企画・設計段階の何倍ものコストと時間がかかることが広く認識された（1:10:100の法則）。
- リスクベースのアプローチの浸透: 全てのシステムに最高の信頼性を求めるのは非現実的であり、システムの重要性やリスクに応じて、適切なレベルの信頼性を設計・投資するという、合理的な考え方が求められるようになった。
2. 理想像の抽出と具体化
- あるべき理想的な状態:
- リスクベースの信頼性設計: 企画段階で、システムの停止や誤作動がビジネスに与える影響（事業インパクト分析）と、発生しうる脅威（ハードウェア障害、ソフトウェアのバグ、アクセス集中等）が評価される。このリスク評価に基づき、達成すべき信頼性の水準（目標可用性、目標復旧時間など）が明確に定義される。
- アーキテクチャへの信頼性の組み込み: 定義された信頼性水準を達成するため、冗長化、フォールトトレラント設計、負荷分散、バックアップ・リカバリといった具体的な対策が、システムのアーキテクチャ（IT環境）として設計・実装されている。
- 開発プロセス全体での品質保証: 信頼性確保の活動が、特定の工程だけでなく、要件定義、設計、実装、テストの各工程で一貫して行われる。例えば、設計レビューでは信頼性の観点がチェックされ、テスト工程では障害を意図的に発生させる「障害テスト」や、高負荷をかける「性能テスト」が計画・実施される。
- 信頼性の定量的な評価と管理: 求められる信頼性レベルが、具体的な指標（例：可用性99.9%、平均修復時間1時間以内）として定義され、テスト結果がその指標を満たしているか、客観的なデータに基づいて評価・管理される。
- 克服すべき障壁:
- 信頼性要件の定義の難しさ: ビジネス部門が「止まらないシステム」といった曖昧な要求しか出せず、それを具体的な技術要件に落とし込むことが難しい。
- コストとのトレードオフ: 高い信頼性を確保するには相応のコストがかかるため、コスト削減のプレッシャーの中で、信頼性への投資が削られやすい。
- 開発者のスキル不足: 信頼性を高めるための設計技術（冗長化、分散処理など）に関する知識や経験を持つ開発者が不足している。
- 短期的な視点: プロジェクトが、目先の機能実装や納期遵守に追われ、長期的な安定稼働という視点が欠如しがちになる。
- 利害関係者の視点:
- 経営層: システム投資が、ビジネス上のリスク許容度に見合った、適切な信頼性レベルを確保していることを確認できる。予期せぬシステム障害による事業機会の損失や信用の失墜を防ぐことができる。
- 事業部門（利用者）: 自分たちの業務の重要性に応じた、安定したシステムを利用できる。システムが「なぜこのレベルの信頼性なのか」について、合理的な説明を受け、納得できる。
- 開発チーム: 明確な信頼性目標を持つことで、設計やテストの方向性が定まり、手戻りが少なくなる。品質の高いシステムを構築したという達成感を得られる。
- 監査人: 企画・開発段階から関与し、信頼性という非機能要件が、リスク評価に基づいて適切に定義され、設計・テストの各工程で確実に作りこまれているかを評価する。「シフトレフト監査」を実践し、下流での大きな問題発生を未然に防ぐ。
3. 要約
- [200文字]要約:
システムの信頼性は、運用段階ではなく企画・開発段階で作り込む必要がある。理想像は、ビジネスリスクに基づき信頼性目標を定義し、それを達成する設計・テストを一貫して行うこと。監査人は、この信頼性確保のプロセスが開発ライフサイクル全体で有効に機能しているかを評価する。 - [400文字]要約:
システムの障害が与える影響が甚大化し、信頼性の確保が重要課題となっている。信頼性は後から付加するものではなく、企画・開発段階で作り込む必要がある。あるべき理想像は、まずビジネスインパクト分析に基づき、システムに求められる信頼性水準を定義する。次に、その水準を達成するための冗長化などの対策をシステムアーキテクチャに組み込み、開発の全工程で検証する。監査人は、この一連のプロセスが有効に機能しているかを評価し、システムの安定稼働を保証する。 - [800文字]による詳細な考察:
本問題は、品質管理における「シフトレフト」の思想、すなわち、問題の発見と対応を開発ライフサイクルのより上流（左側）で行うことの重要性を、システムの「信頼性」という切り口から論じている。これは、手戻りコストの削減と、最終的なシステムの安定性確保に不可欠なアプローチである。- あるべき理想像とは、「レジリエンス・バイ・デザイン（Resilience by Design）」の原則が開発プロセスに組み込まれている状態である。これは、信頼性や回復力（レジリエンス）を、システムの基本的な設計思想として、企画段階から当たり前のように組み込む文化とプロセスが定着していることを意味する。具体的には、プロジェクトのキックオフ時点で、ビジネス部門と開発部門が共同で「信頼性ワークショップ」を開催し、RTO（目標復旧時間）/RPO（目標復旧時点）を定義する。この非機能要件は、機能要件と同等の重要度で要件定義書に記載される。設計フェーズでは、SPOF（単一障害点）を排除するアーキテクチャが採用され、その妥当性がレビューされる。テストフェーズでは、カオスエンジニアリングのように、本番環境で意図的に障害を発生させ、システムの応答を試すような、より実践的な信頼性テストが行われる。
- 理想像実現へのアプローチとして、システム監査人は、従来の完成品をテストするような事後的な関与から、開発プロセス自体を監査する、より上流での関与へとシフトする。監査手続としては、①企画段階：信頼性目標の定義プロセスの妥当性評価。②要件定義段階：非機能要件定義書のレビュー。③設計段階：設計書やアーキテクチャ図をレビューし、SPOFの有無や冗長化設計の妥当性を評価。④テスト段階：テスト計画書をレビューし、信頼性に関するテスト（障害テスト、性能テスト）が十分に計画されているか、またその結果が目標値を満たしているかを確認する。このように、各工程の成果物をマイルストーンごとにレビューしていくことで、問題の早期発見・早期是正を促す。
- 期待される効果は、リリース後の重大なシステム障害の発生確率を大幅に低減し、システムのライフサイクル全体でのTCO（総所有コスト）を削減することである。
- 考慮すべきリスクは、監査が開発のスピードを阻害する「ゲートキーパー」として機能してしまうことだ。監査人は、開発チームと対立するのではなく、共通の品質目標を持つパートナーとして、建設的な助言を行う姿勢が求められる。