システム監査技術者 2023年 午後1 問02

解答の導き方

1. 問われているのは、管理ルール案によってアプリ開発の利点が損なわれる可能性です。まず、営業部長は利点として「短期間・低コストで、利用部門のニーズに合致したアプリが開発できる」と述べています。つまり、迅速に開発でき、利用部門が必要とするものを作りやすい点が重要です。
2. 次に、表1の「開発申請手続」を確認します。利用部門が開発申請を行い、事務局が開発可否を判断する仕組みです。申請の準備や判断を待つ手続が加わるため、利用部門の作業や待ち時間が増える可能性があります。
3. その結果、開発開始までに時間がかかったり、利用部門の手間が増えたりして、短期間でニーズに合ったアプリを開発できるという利点が弱まるおそれがあります。したがって、監査部が考えた可能性は、開発申請手続によって利用部門の負担が増えることです。

誤りやすいポイント

• 開発ツールの操作が難しくなることを答えるのではありません。問題となるのは、開発申請と事務局による判断という手続が加わることです。
• 管理ルール案の効果や必要性を答えるのではなく、ルールを適用した場合に開発の利点が損なわれる可能性を答えます。
• 利点のうち「短期間で開発できる」点だけに注目し、手続による利用部門の負担を見落とさないようにします。

FAQ

解答の導き方

1. 設問は、開発可否の判断に使う基準へ、すでに挙げられている項目以外に何を加えるべきかを問うています。表1では、判断基準として「使用するデータの種別」「想定されるデータ量」「処理の複雑度（高・中・低）」が示されています。これらは、アプリのデータや処理の規模・難しさを把握する項目です。
2. 一方、表2には「利用部門がそれぞれ独自にアプリを開発し、不要なアプリが乱立する。」というリスクがあります。先ほどの3項目だけでは、開発しようとしている機能を持つアプリがすでにあるかどうかは分かりません。そのため、既存のアプリと機能が重複していても、新たな開発が申請される可能性があります。
3. そこで、開発の必要性や既存アプリの活用可能性を判断できるよう、開発判断基準に、同じような機能を持つアプリがすでに存在するかを確認する項目を加えます。本文には、既存アプリの部品を選定し、テンプレートとして登録する予定も示されています。こうした資産を活用するためにも、申請時に類似アプリの存在を確認することが有効です。

誤りやすいポイント

• データ量や処理の複雑度をさらに細かくするだけでは、アプリの重複や不要な開発を防ぐ観点が不足します。
• テンプレートの利用だけを答えるのは不十分です。問われているのは開発判断基準に追加する項目なので、まず既存の類似アプリがあるかを判断できるようにする必要があります。
• 類似アプリがあるかどうかだけで、開発の可否が自動的に決まるわけではありません。既存アプリの活用や、新たな開発の必要性を判断する材料として使います。

FAQ

解答の導き方

1. この設問は、システム部の開発標準をアプリ開発にそのまま適用するのが適切でない状況を問うています。ポイントは、開発標準の内容と、対象となるアプリの規模や難易度が釣り合っているかどうかです。
2. 本文では、アプリ開発の利点として「短期間・低コスト」であることが挙げられています。また、アプリは「簡易」なものを中心に開発されています。規模が小さく難易度も低いアプリに、システム部の開発標準を一律に適用すると、必要以上に手順や管理作業が増える可能性があります。
3. その結果、開発期間やコストが増え、アプリ開発の利点を損なうおそれがあります。したがって、標準をそのまま流用するのが適切でない場合として、開発するアプリの規模が小さく、難易度が低い状況を考えます。管理をなくすのではなく、アプリの特性に応じて必要な手順を選ぶことが大切です。

誤りやすいポイント

• 「ローコード／ノーコード開発ツールを使うなら、開発標準は不要」と考えるのは誤りです。問われているのは、標準をそのまま適用することの適否です。
• 「適切ではない場合」を、アプリの重要性や個人情報の有無など、別のリスクだけで判断しないようにします。この設問では、規模と難易度が判断の軸です。
• 開発標準を適用すると必ず開発が遅れる、と断定するのではなく、小規模・低難易度のアプリでは標準の内容が過剰になる可能性に着目します。

FAQ

解答の導き方

1. 営業部では、利用者用IDとは別に「営業部の全部員に」開発用IDを付与しています。つまり、開発用IDを持つ人が多数に及ぶ状態です。
2. 利用者用IDには権限に応じたデータの参照・更新範囲が設定される一方、開発用IDは「本番環境のデータの参照が可能」とされています。開発用IDを持つと、本番環境のデータを参照できるため、業務上その権限を必要としない人にも付与されれば、権限のない人がデータを見られるおそれがあります。
3. したがって、表2項番1(3)のリスクは、権限を与えるべきでない利用者が本番環境のデータを参照できることです。開発用IDをシステム部で管理し、申請に基づいて登録するルールは、開発用IDを必要最小限の利用者に付与するための対策です。

誤りやすいポイント

• 開発用IDによるリスクを、開発用IDの不正利用やIDの管理不備だけで捉えないようにします。問題文で具体的に示されているのは、本番環境のデータを参照できる権限です。
• 利用者用IDと開発用IDを混同しないようにします。利用者用IDには権限に応じた制限がある一方、開発用IDでは本番環境のデータを参照できます。
• データの「更新」までできると決めつけないようにします。開発用IDについて本文に示されているのは、本番環境のデータの参照が可能であることです。

FAQ

解答の導き方

1. この確認の目的は、設計ドキュメントの作成基準が実際に機能するかを確かめることです。本文では、基準として「記載が必要な項目の一覧と標準フォーマットが示されている」とされています。
2. ただし、一覧やフォーマットが用意されているだけでは、開発担当者が実際に使って設計ドキュメントを作成できるとは限りません。基準の存在だけでなく、利用部門で無理なく適用できるかを確かめる必要があります。
3. アプリ開発を行っているのは利用部門です。そのため、標準フォーマットを使って設計ドキュメントを作成できるかは、実際にアプリを開発する営業部に確認するのが適切です。
4. したがって、事務局に確認する内容は、標準フォーマットを使った設計ドキュメントの作成が可能かどうかを、事務局が営業部に確認していることです。

誤りやすいポイント

• 設計ドキュメントの作成基準に、項目一覧と標準フォーマットがあることを確認するだけでは不十分です。問われているのは、その基準を実際に適用できるかどうかです。
• 事務局自身がフォーマットを使えるかではなく、アプリを開発する利用部門で作成可能かを確かめる必要があります。
• 作成基準の実効性を問う設問なので、設計ドキュメントの内容を新たに提案するのではなく、作成可能性の確認に焦点を当てます。

FAQ

解答の導き方

誤りやすいポイント

• 「操作ログを取得すること」だけを答えると、本文にある機能の説明を繰り返すだけになり、追加で確認すべき保全要件を示せません。
• 「ログを定期的に確認すること」は、ログの利用方法に関する内容です。今回問われているのは、取得後のログを保護する要件です。
• 「ログをバックアップすること」だけでは、元のログが改ざん・消去されるリスクへの対策を十分に表せない場合があります。

FAQ