令和6年度秋期午前Ⅱ試験問題の問２１〜２５までを解説

今回も、先日受験した令和６年度秋期午前Ⅱ試験の問題を解説しなががら、次回試験の対策を行っていきます。今回で午前Ⅱ試験の解説は終わりになります。

今回解説するのは、問２１〜２５です。これらの問題で使用されていた用語は、以下の5つです。

関係モデルにおける外部キー
GoF
エクストリームプログラミング
サービスマネジメントシステムにおける継続的改善
ITに関わる業務処理統制

是非、最後までご覧いただけると嬉しいです。

関係モデルにおける外部キー
GoF
エクストリームプログラミング
サービスマネジメントシステムにおける継続的改善
ITに関わる業務処理統制
まとめ

関係モデルにおける外部キー

関係モデルにおける外部キーに関する記述のうち、適切なものはどれか。

ア　外部キーの値は、その関係の中で一意でなければならない。

イ　外部キーは、それが参照する候補キーと比較可能でなくてもよい。

ウ　参照先の関係に、参照元の外部キーの値と一致する候補キーが存在しなくてもよい。

エ　一つの関係に外部キーが複数存在してもよい。

引用：情報処理安全確保支援士試験　令和6年秋午前Ⅱ問２１

解答

エ

外部キーの概要

関係モデルにおける外部キー（Foreign Key）は、あるテーブルの列または列の組み合わせが、別のテーブルの主キー（Primary Key）を参照し、データの整合性を保つための重要な仕組みです。外部キーは、テーブル間の関連性を定義し、データを結びつけることでリレーションシップを構築します。

外部キーの特徴

参照整合性の確保：外部キーによって、参照元のテーブルに存在するデータのみが挿入されるため、データの一貫性を維持できます。外部キーの列には、参照するテーブルの主キーや候補キー（Unique Key）に存在する値のみが許可されます。
複数の外部キー：一つのテーブル（関係）に外部キーが複数存在しても問題ありません。複数の外部キーを設定することで、他の複数のテーブルと関係を持つことができます。たとえば、ある注文テーブルに「顧客ID」と「商品ID」という2つの外部キーを設定し、それぞれ顧客テーブルと商品テーブルを参照することで、注文がどの顧客によって行われ、どの商品が注文されたかを明確に表すことができます。
複数テーブル間の関係：外部キーは、「1対多」や「多対多」など、異なるテーブル間の関係を表現します。たとえば、顧客テーブルと注文テーブル間の「1対多」の関係では、注文テーブルに外部キーとして顧客IDを持たせることで、複数の注文が1つの顧客に関連付けられることを示せます。
カスケード動作：カスケードとは、あるテーブルで実行された操作が、それに関連する別のテーブルにも自動的に影響を及ぼす仕組みを指します。カスケード動作には、主に以下の２つがあります。
- カスケード削除（ON DELETE CASCADE）: 参照先のデータが削除されたとき、それを参照しているデータも削除されます。
- カスケード更新（ON UPDATE CASCADE）: 参照先のデータが更新された場合、それに従って外部キーの値も更新されます。

例

「顧客テーブル（customers）」と「注文テーブル（orders）」に加えて、「商品テーブル（products）」を用意し、注文テーブルに2つの外部キー（顧客IDと商品ID）を持たせます。

＜顧客テーブル＞

顧客ID (customer_id)	名前 (name)
1	佐藤
2	鈴木

＜商品テーブル＞

商品ID (product_id)	商品名 (product_name)
1001	本
1002	ペン

＜注文テーブル＞

注文ID (order_id)	顧客ID (customer_id)	商品ID (product_id)
101	1	1001
102	2	1002
103	1	1002

注文テーブルでは、「顧客ID」と「商品ID」の2つの外部キーが設定されています。これにより、各注文がどの顧客によって行われ、どの商品が注文されたかを明示できます。

外部キーのまとめ

外部キーは、関係モデルにおいてテーブル間の関連性を保つ重要な役割を担い、一つのテーブルに複数の外部キーが存在することも可能です。これにより、複数のテーブルと関係を持つデータ構造を構築でき、データの整合性を効率的に管理できます。

GoF

ソフトウェアアパターンのうち、GoFのデバインパターンの説明はどれか。

ア　Javaのパターンとして、引数オブジェクト、オブジェクトの可変性などで構成される。

イ　オブジェクト指向開発のためのパターンであって、生成、構造、振る舞いの三つのカテゴリに分類される。

ウ　構造、分散システム、対話側システム及び適合型システムの四つのカテゴリに分類される。

エ　抽象度が異なる要素を分割して階層化するためのLayers、コンポーネント分割のためのBrokerなどで構成される。

引用：情報処理安全確保支援士試験　令和6年秋午前Ⅱ問２２

解答

イ

GoFの解説

GoFのデザインパターンは、オブジェクト指向開発のためのパターンであり、再利用可能で効果的な設計手法を提供します。これらのパターンは、ソフトウェアの設計を柔軟で保守しやすくするために、頻繁に直面する設計上の問題に対する解決策として使われます。デザインパターンは、以下の三つのカテゴリに分類されます。

生成パターン (Creational Patterns)：オブジェクトの生成に関するパターンで、オブジェクトの生成過程を抽象化し、システムの柔軟性と再利用性を向上させます。代表例として、シングルトン、ファクトリーメソッド、ビルダーなどがあります。
- シングルトンは、あるクラスのインスタンスがシステム全体でただ1つしか存在しないことを保証するデザインパターンです。また、そのインスタンスへのアクセスを提供します。主に、共有リソースや設定情報の管理に使用されます。
- ファクトリーメソッドは、オブジェクトの生成をサブクラスに任せることで、生成する具体的なクラスをクライアント側に隠蔽するデザインパターンです。これにより、柔軟性と拡張性を高めることができます。
- ビルダーは、複雑なオブジェクトの生成過程を段階的に組み立てるデザインパターンです。オブジェクトの内部構造を隠しつつ、柔軟にカスタマイズできるのが特徴です。特に、オプションや複数の段階的な構成要素を持つオブジェクトの生成に適しています。
構造パターン (Structural Patterns)：クラスやオブジェクトを組み合わせて、より大きな構造を作るためのパターンです。オブジェクト間の関係を明確にし、システムを効率的に構築・拡張するのに役立ちます。代表例として、アダプター、ブリッジ、デコレーターなどが挙げられます。
- アダプターは、異なるインターフェースを持つクラス同士を接続し、互換性を持たせるデザインパターンです。既存のコードを変更せずに、他のコードと統合するために使用されます。
- ブリッジは、機能の階層と実装の階層を分離するデザインパターンです。これにより、機能と実装をそれぞれ独立して拡張できるようになります。実装と機能を橋渡しすることで、変更による影響を最小限に抑えられます。
- デコレーターは、オブジェクトの機能を動的に拡張するデザインパターンです。元のオブジェクトを変更することなく、追加の機能を付加することができます。このパターンでは、デコレーション用のオブジェクトをチェーンのように繋ぐことで、柔軟な拡張が可能です。
振る舞いパターン (Behavioral Patterns)：オブジェクト間のコミュニケーションや責任の分担に関するパターンです。オブジェクト同士の協調を効率化し、動的な振る舞いを柔軟に管理することが目的です。代表例として、オブザーバー、ストラテジー、コマンドパターンなどがあります。
- オブザーバーは、1つのオブジェクト（Subject）の状態変化を、複数のオブジェクト（Observers）に通知するデザインパターンです。オブザーバーを登録すると、Subjectの変化を自動的に追跡できるようになります。この仕組みにより、状態変更に応じたリアルタイムの更新が可能です。
- ストラテジーは、アルゴリズムや振る舞いを切り替えることができるデザインパターンです。異なるアルゴリズムをそれぞれ独立したクラスとして定義し、それらを動的に切り替えることができます。このパターンは、実行時に異なる処理を柔軟に選択できるようにするために使用されます。
- コマンドは、操作（振る舞い）をオブジェクトとしてカプセル化するデザインパターンです。このパターンでは、コマンドを送信する側（Invoker）とコマンドを実行する側（Receiver）の結合を緩やかにし、操作の履歴管理や実行の取り消し（Undo）を可能にします。

これらのパターンを活用することで、コードの再利用性、拡張性、保守性を向上させることが可能となります。

ビルダーパターン (Builder Pattern)

選択肢アのソフトウェアパターンは、ビルダーパターンです。

ビルダーパターン (Builder Pattern) は、複雑なオブジェクトを段階的に構築する際に使用されるソフトウェアデザインパターンです。このパターンでは、オブジェクトの生成過程を分離し、同じ構築プロセスで異なる種類や構成のオブジェクトを生成することができます。設計の際にコードの可読性を向上させ、オプションパラメータを扱いやすくする特徴があります。また、クライアントコードから具体的な構築方法を隠蔽し、柔軟性を高める利点があります。典型的な例として、オブジェクトの設定を連続的に行うためのメソッドチェーンが挙げられます。

POSAパターン (Pattern-Oriented Software Architecture)

選択肢ウのソフトウェアパターンは、POSAパターンです。

POSAパターン (Pattern-Oriented Software Architecture) は、ソフトウェアシステム全体のアーキテクチャ設計に焦点を当てたデザインパターンの体系です。このパターン集は、分散システムや複雑なシステム設計を支援するために、繰り返し利用可能な設計解決策を提供します。代表的なパターンには、階層構造を扱う「Layers」や、分散環境での通信を仲介する「Broker」などがあります。これらのパターンは、システムの柔軟性、再利用性、スケーラビリティの向上を目的としています。POSAは特にエンタープライズや分散アーキテクチャ設計において有用です。

アーキテクチャパターン(Architecture Pattern)

選択肢エのソフトウェアパターンは、アーキテクチャパターンです。

アーキテクチャパターン (Architecture Pattern) は、ソフトウェアシステム全体の構造や設計指針を提供するパターンで、システムの特定のニーズや課題に対する一般的な解決策を示します。これにより、システム設計の再利用性や整合性を高めることができます。代表的な例として、「MVC（Model-View-Controller）」、「マイクロサービス」、「レイヤードアーキテクチャ」などがあります。これらのパターンは、開発者が設計の決定を効率的に行い、柔軟で保守可能なシステムを構築するのに役立ちます。アーキテクチャ全体の設計方針を標準化する点で、デザインパターンより高い抽象度を持ちます。

エクストリームプログラミング

エクストリームプログラミング（XP：Extreme Programing）における”テスト駆動開発”の特徴はどれか。

ア　最初のテストで、なるべく多くのバグを摘出する。

イ　テストケースの改善を繰り返す。

ウ　テストでのカバレージを高めることを目的とする。

エ　プログラムコードを書く前にテストコードを書く。

引用：情報処理安全確保支援士試験　令和6年秋午前Ⅱ問２３

解答

エ

エクストリームプログラミングの概要

エクストリームプログラミング（XP）の中核的なプラクティスの一つである「テスト駆動開発 (TDD：Test-Driven Development)」は、ソフトウェア開発において、テストを先に書き、その後にそのテストをパスするコードを書くという開発手法です。TDDは品質の高いコードを効率的に生み出すための手法であり、次のようなステップで進められます。

テストの作成 (Red Phase)
最初に、まだ実装されていない機能のためのテストケースを作成します。ここでの目標は、失敗するテストを書くことです。テストは、アプリケーションが満たすべき具体的な要件や期待される動作を確認するものです。この段階では、テストが必ず失敗することが前提です（なぜなら、まだコードが実装されていないためです）。
実装 (Green Phase)
次に、そのテストをパスさせるために、必要最低限のコードを実装します。ここでは、テストが成功することだけを目指してコードを書き、過剰な設計や機能追加は行いません。このフェーズでテストがすべて成功すれば、基本的な機能が正しく動作していることが確認できます。
リファクタリング (Refactor Phase)
テストがすべて成功したら、コードをリファクタリングして改善します。リファクタリングとは、コードの振る舞いを変えずに内部構造を整理し、読みやすく、保守しやすい形にすることです。リファクタリング後もすべてのテストがパスすることを確認し、品質を維持します。

TDDのサイクルは「Red → Green → Refactor」と呼ばれ、これを小さな単位で繰り返すことによって、バグの少ない堅牢なコードを継続的に作成することができます。

テスト駆動開発の利点

早期にバグを発見：コードを書く前にテストを定義するため、問題が発生する前に検出できます。
設計の向上：テストを書くことで、開発者が設計に集中でき、シンプルで拡張しやすいコードを作りやすくなります。
リファクタリングの安全性：テストがあることで、リファクタリングによるバグを防ぐことができ、コードの改善がしやすくなります。
ドキュメンテーション：テストケースは、コードがどのように動作するべきかを示すドキュメントのような役割を果たします。

テスト駆動開発は、XPのプラクティスとともに、アジャイル開発の中で特に重要な役割を果たし、継続的な品質向上と迅速なフィードバックを提供する方法として広く採用されています。

エクストリームプログラミング（XP）におけるテスト駆動開発（TDD）のまとめ

テスト駆動開発（TDD）は、エクストリームプログラミング（XP）の重要なプラクティスで、テストを先に書き、そのテストをパスするコードを書く開発手法です。「テスト→実装→リファクタリング」のサイクルを繰り返し、高品質なコードを効率的に構築します。メリットには、早期のバグ発見、設計改善、リファクタリングの安全性があり、アジャイル開発全般でも重要です。具体的な手順は、テスト作成（Red Phase）、実装（Green Phase）、リファクタリング（Refactor Phase）の3段階です。この手法は、保守性や拡張性に優れたコード開発を可能にします。

サービスマネジメントシステムにおける継続的改善

JIS Q 20000-1:2020（サービスマネジメントシステム要求事項）によれば、サービスマネジメントシステム（SMS)における継続的改善の定義はどれか。

ア　意図した結果を得るためにインプットを使用する、相互に関連する又は相互に作業する一連の活動

イ　価値を提供するため、サービスの計画立案、設計、移行、提供及び改善のための組織の活動及び資源を指揮し、管理する、一連の能力及びプロセス

ウ　サービスを中断なしに、又は合意した可用性を一貫して提供する能力

エ　パフォーマンスを向上するために繰り返し行われる活動

引用：情報処理安全確保支援士試験　令和6年秋午前Ⅱ問２４

解答

エ

サービスマネジメントシステムにおける継続的改善の概要

JIS Q 20000-1:2020（サービスマネジメントシステム要求事項）における継続的改善は、サービスマネジメントシステム（SMS）の有効性と効率性を継続的に向上させ、組織が提供するサービスの質を維持・向上するための重要な活動です。継続的改善は、サービス提供におけるパフォーマンスを持続的に向上させ、顧客や利害関係者の期待に応え、組織全体の価値を最大化することを目的としています。

継続的改善のポイント

計画-実行-確認-処置（PDCA）サイクル
継続的改善は、一般的にPDCAサイクルに基づいて実施されます。これにより、計画（Plan）段階での目標設定、実行（Do）段階での施策実施、確認（Check）段階での評価、処置（Act）段階での改善措置を循環的に行うことで、サービスの質を段階的に向上させます。
- Plan（計画）：改善すべき領域を特定し、具体的な目標と戦略を設定します。ここでは、リスクや機会の評価が行われ、改善のためのアクションが計画されます。
- Do（実行）：計画に基づいて改善策を実行します。この段階では、計画されたプロセスの実施や新しい手法の適用が行われます。
- Check（確認）：実行された改善措置の結果をモニタリングし、成果を評価します。パフォーマンス指標や顧客満足度の測定が行われ、どの程度改善が達成されたかを確認します。
- Act（処置）：評価結果に基づき、さらに改善するべきか、または標準化するべきかを判断し、必要に応じて次の改善を計画します。
リスクベースのアプローチ
継続的改善においては、リスクと機会の評価が重要です。JIS Q 20000-1では、リスクを管理し、予防的な措置を取ることによって、サービスの質や効率性に悪影響を及ぼす問題を未然に防ぐことが求められています。また、潜在的な機会を特定し、これを活用することで、サービスの競争力や価値を向上させることが可能です。
顧客フィードバックの活用
サービス改善の重要な要素として、顧客や利害関係者からのフィードバックを活用します。顧客満足度調査や苦情の分析を通じて、サービス提供の問題点や改善のヒントを得ることができ、これをSMSの改善に反映させます。
パフォーマンスのモニタリングと評価
サービスのパフォーマンスを継続的にモニタリングし、評価することが求められます。特定のパフォーマンス指標を設定し、定期的にその指標をレビューすることで、サービスの現状と目標との差を明確にし、効果的な改善策を策定します。
内部監査とマネジメントレビュー
内部監査やマネジメントレビューは、SMSの継続的改善のための重要なプロセスです。内部監査では、SMSの適合性と有効性を確認し、必要な改善点を特定します。また、マネジメントレビューでは、トップマネジメントがシステム全体のパフォーマンスを評価し、改善の方針や戦略を検討します。

継続的改善の意義

継続的改善は、SMSが単なる運用管理の枠を超え、戦略的な価値提供を行うための基盤となります。これにより、組織は顧客の期待を満たし、さらには超えるサービスを提供し続けることができ、長期的な競争優位性を確保することが可能になります。

SMSにおける継続的改善は、組織のサービス品質向上と業務プロセスの効率化に不可欠であり、JIS Q 20000-1:2020においてもその重要性が強調されています。

サービスマネジメントシステムにおける継続的改善のまとめ

JIS Q 20000-1:2020に基づくサービスマネジメントシステム（SMS）では、継続的改善がサービス品質向上と顧客満足度向上の中核活動とされています。PDCAサイクルを基盤に、リスク管理、顧客フィードバック、内部監査などを活用し、改善を繰り返します。具体的には「計画→実行→確認→処置」のプロセスで目標達成と次の改善を図ります。継続的改善の効果は、品質向上、業務効率化、リスク低減、組織価値向上に繋がり、競争力と持続的成長を支えます。この活動を規格に基づき推進することが組織に求められます。

ITに関わる業務処理統制

アクセス管理に関する内部統制のうち、金融庁”財務報告に係る内部統制の評価及び監査に関する実施基準（令和５年）”におけるITに係る業務処理統制に該当するものはどれか。

ア　組織としてアクセス管理規程を定め、統一的なアクセス管理を行う。

イ　組織としてアクセス制限の設定方針を定め、周知徹底を図る。

ウ　組織内のアプリケーションシステムに利用者IDとパスワードによって利用者を認証する機能を設ける。

エ　組織内の全ての利用者に対して、アクセス管理の重要性についての教育を行う。

引用：情報処理安全確保支援士試験　令和6年秋午前Ⅱ問２５

解答

ウ

ITに係る業務処理統制の概要

ITを利用した業務処理における統制を指し、財務報告の信頼性を確保するために、ITを活用した業務プロセス全体で適切な統制が設計・運用されているかどうかを評価するものです。

具体的な要素

ITに係る業務処理統制は、以下の観点で構成されます：

1. ITを利用した業務処理の正確性・完全性の確保

財務データを処理するためのシステムが、誤りなく正確なデータ処理を行うことを保証します。
具体例：
- データ入力時の検証（例：入力エラーを防ぐためのチェック機能）
- データの更新履歴やトランザクションのログ管理
- 自動計算や集計機能の正確性の確認

2. アクセス権限の管理

ITシステムやデータへのアクセスが適切に制御されているかを確認します。
具体例：
- 業務上必要な職務に応じたアクセス権の付与
- 不正アクセス防止のためのパスワード管理や多要素認証の導入

3. データの変更管理

システム内の重要なデータやプログラムの変更が正当かつ記録されているかを確認します。
具体例：
- マスタデータの変更ログの記録
- プログラム修正時のテストおよび承認手続き

4. ITシステム間の連携

システム間でデータが適切に連携・同期され、処理が一貫していることを確認します。
具体例：
- システム間インターフェースのテストや監視
- データの変換・移行時の正確性の検証

評価と監査のポイント

統制の設計と運用の有効性
- 統制がどのように設計されているか（設計の有効性）
- 設計された統制が実際に運用され、適切に機能しているか（運用の有効性）
リスクベースアプローチ
- 重要性の高いIT業務処理統制に重点を置き評価します。たとえば、財務報告に直接影響を及ぼすシステムやプロセスが優先的な評価対象です。
内部統制の文書化と証拠
- ITに係る業務処理統制のプロセスや実施状況は、文書化され、必要に応じて証拠として提出できるようにしておく必要があります。

ITに係る業務処理統制の重要性

ITに依存する業務プロセスが増加する現代において、ITに係る業務処理統制の適切な評価と運用は、財務報告の正確性や信頼性を担保する上で不可欠です。特に、システムの脆弱性や不正リスクを軽減するための統制が適切であるかを確認することは、内部統制全体の健全性にも寄与します。

ITに係る業務処理統制のまとめ

ITに係る業務処理統制は、ITシステムを活用した業務で、財務データの正確性・完全性を確保し、不正やエラーを防ぐための仕組みを評価するものです。主な要素は、データ処理の正確性、アクセス権限の管理、データ変更管理、システム間の連携確認です。統制の設計・運用が有効であることを確認し、リスクベースアプローチで重要なシステムやプロセスを重点的に評価します。さらに、内部統制の文書化や証拠の記録が求められます。この統制は、財務報告の信頼性確保と業務全体の健全性向上に不可欠です。