令和5年度秋期システム監査技術者試験午後 I 問題問2 ローコード／ノーコード開発の監査手続

この問題は2023(R5)秋システム監査技術者午後Iに出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。

本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています（改行・記号・数式・図表参照の調整）。設問の趣旨および正解に影響する変更は加えていません。

学習ガイド

自動車部品メーカーで、利用部門がコードを書かずにアプリを内製できるローコード／ノーコード開発ツールを監査対象とする問題です。短期間・低コストで現場ニーズに合うという利点の裏で、開発者の異動でアプリが保守不能になる、営業部の全員に本番データを参照できる開発用IDが配られる、といったリスクが潜みます。この記事では、事務局が作った管理ルール案が利点を殺していないか、開発判断基準に穴はないかという監査部の視点で、各設問の狙いをたどります。

この記事で押さえる論点

短期間・低コストというアプリ開発の利点と管理ルール適用の副作用を対比する
開発判断基準に不足している項目をリスク低減の観点から補う
基幹系の開発標準をアプリ開発へそのまま流用できない場面を判断する
開発用IDによる本番データ参照が招くリスクと必要なログ保全要件を特定する

出題情報

出題: 2023(R5)秋システム監査技術者午後I 問2
配点: 50点満点
模範解答: 公表(設問ごとに掲載)

出題趣旨・採点講評(IPA 公表)

システム開発の生産性向上や納期の短縮を目的としてローコード／ノーコード開発を採用する組織が増えてきている。しかし，開発手法の標準化や管理ルールを明確に定めずに導入を進めると，あまり利用されないシステムが増えたり，開発手法や開発ツールが乱立して管理不能になったりするといったリスクがある。本問では，ローコード／ノーコード開発ツールを利用したシステム開発を題材として，システム監査人として，開発手法の特性，長所・短所を理解し，開発業務を監査する場合の監査手続を設定する能力を問う。

問2では，ローコード／ノーコード開発ツールを利用したシステム開発の監査を題材に，開発ツールを効果的に活用していく上でのリスクや開発手法の標準化に関する監査手続について出題した。全体として正答率は平均的であった。

問題本文

問2 ローコード／ノーコード開発ツールを利用したシステム開発の監査に関する次の記述を読んで，設問に答えよ。

C社は，自動車部品を製造販売する企業である。販売，購買，生産などを管理する基幹系システムの開発・保守は，システム部が主体となって行っている。一方，業務効率の向上を目的とした簡易なシステム（以下，アプリという）については，利用部門が主体となって，プログラムのコードを書かなくても開発できるローコード／ノーコード開発ツール（以下，開発ツールという）を利用して開発を行ってきた。

C社のCIOは，開発ツールを利用したアプリの開発（以下，アプリ開発という）には利点があることは認識していた。一方で，アプリ開発の管理ルールが定められていなければ，開発者の異動や退職などによって保守できなくなるアプリが発生するといったリスクがあることを懸念していた。そこでCIOは，システム部にアプリ開発の管理ルールを作成するよう指示し，システム部のシステム企画課に設置された事務局が管理ルール案を作成した。

〔アプリ開発の状況〕

営業部などの各利用部門でクラウドサービス事業者と契約して開発ツールを導入し，データの照会や集計など，簡易で高い可用性を求められないアプリを中心に開発している。

〔システム監査の目的と対象部門〕

監査部では，アプリ開発の状況を監査することにした。監査目的は，管理ルール案によってアプリ開発のリスクが低減できるかどうか，という点である。監査部は，アプリ開発を積極的におこなっている営業部，及び管理ルール案を作成したシステム企画課を対象に予備調査を実施した。

〔予備調査の結果〕

監査部が予備調査を行った結果，次のことが分かった。

営業部長へのインタビュー結果

(1) アプリ開発は，短期間・低コストで，利用部門のニーズに合致したアプリが開発できるという利点がある。

(2) 開発ツールの利用方法に習熟してもらうために，営業部の全部員に利用者用IDとは別に開発用IDを付与している。利用者用IDでは，権限に応じてデータの参照・更新の範囲が設定される。一方，開発用IDでは，開発を効率よく進めるために，本番環境のデータの参照が可能となる設定にしている。

システム企画課長へのインタビュー結果

(1) アプリ開発の利点を生かし，かつ，リスクを低減するために，必要最小限の管理ルールの作成を行う。

(2) 事務局が作成した管理ルール案の概要を表1に示す。システム部が開発するアプリについても，開発コストの削減や開発期間の短縮を目的として，開発ツールの利用を検討している。

項番	項目	内容
1	適用対象	・利用部門によるアプリ開発の場合，アプリの利用者は部門内であることを原則とする。・個人情報を扱うアプリは，利用部門によるアプリ開発の対象外とする。
2	開発申請手続	・利用部門によるアプリ開発の場合，利用部門からの開発申請に基づき，開発可否を事務局が判断する。・次の項目を含む開発判断基準を設ける。 - 使用するデータの種別 - 想定されるデータ量（マスターファイル，トランザクションなど） - 処理の複雑度（高・中・低）
3	テスト	・データ量が多い，又は関連データが多いアプリの開発は，テストの実施基準を設ける。
4	ID管理	・開発用 ID をシステム部で管理する。
5	リリース管理	・リリース手順及び利用者への周知手順を作成する。
6	開発後の管理	・開発したアプリは，管理台帳に登録して事務局で一元管理する。・必要最小限の設計ドキュメントを作成する。

(3) これまで開発されたアプリの中から，他のアプリでも利用可能なアプリの部品をシステム部が選定し，動作確認や分類を行ってテンプレートとして登録する。

今後開発するアプリは，それらのテンプレートを可能な限り利用する。開発ツールの利用方法や登録したテンプレートの利用ルールについて，利用部門に対して説明会を実施する予定である。

〔リスクの識別〕

監査部は，予備調査の結果を踏まえ，アプリ開発のリスクを識別し，それに対応する管理ルール案の内容を洗い出した。アプリ開発のリスクと管理ルール案の内容を表2に示す。

項番	分類	リスク	管理ルール案の内容
1	企画・開発段階	(1) 利用部門がそれぞれ独自にアプリを開発し，不要なアプリが乱立する。	・アプリの開発判断基準を作成し，周知する。
1	企画・開発段階	(2) 必要な設計ドキュメントが作成されなかったり，テストが不足したりして，品質が低下する。	・必要最小限の設計ドキュメントを作成する。
1	企画・開発段階	(3) ア	・開発用 ID をシステム部で管理する。・開発ツールの開発用 ID の登録は申請に基づき行う。
2	運用・保守段階	(1) 開発担当者の異動や退職によって，アプリの仕様が分からず保守ができなくなる。	・必要最小限の設計ドキュメントを作成する。・テンプレートの利用ルールを定める。
2	運用・保守段階	(2) システム部が開発ツールを利用して開発するアプリに管理ルール案を適用した場合，必要なセキュリティ機能が実装されない。	・個人情報などの重要データにアクセスした際の操作内容を操作ログに記録する。

〔監査手続書の作成〕

監査部はリスクの高い項目について，本調査で確認すべきことを整理し，監査手続書を作成した。その概要は次のとおりである。

(1) 営業部長へのインタビュー結果(1)を踏まえ，表1の管理ルール案の適用によってアプリ開発の利点が損なわれる可能性がないか，管理ルール案の内容を確認する。

(2) 表2項番 1(1)について，開発判断基準がリスクを低減する内容になっているか，開発の可否を判断するのに必要な項目に漏れがないことを確認する。

(3) 表2項番 1(2)についてシステム部に確認したところ，システム部で利用している開発標準を流用して進捗管理や品質管理を行う予定であるとのことであった。しかし，そのまま流用するのは適切ではない場合もあることに留意する。

(4) 表2項番 1(3)について，開発用IDを申請に基づいて必要最小限の部員に付与することでリスクの低減が期待できることに留意する。

(5) 表2項番 2(1)について，設計ドキュメントの作成基準として，記載が必要な項目の一覧と標準フォーマットが示されている。この作成基準の適用が実効性のあるものかどうかを事務局に確認する。

(6) 表2項番 2(2)について，開発ツールには，画面操作を行った利用者用ID，操作内容などを記録した操作ログを取得する機能が備わっている。ただし，操作ログを取得するだけでは不十分なので，その他に必要なログの保全の要件についてもルールが定められていることを確認する。

設問と解答・解説

設問1

〔監査手続書の作成〕 (1)について，監査部が考えた，アプリ開発の利点が損なわれる可能性を 35字以内で答えよ。

模範解答

開発申請手続の適用によって利用部門の負担が増える可能性

採点基準(配点 8点)

知識・理解度（内容）(5点)

5点: 開発申請手続の適用による「利用部門の負担増」というリスクを的確かつ具体的に記述している。
4点: 利用部門の負担増に触れているが、開発申請手続との関連性の記述がやや曖昧である。
3点: 負担の増加や利点の喪失に触れているが、監査要点に沿った具体的なリスクとしての記述が不足している。
1点: リスクについて触れているが、短期間・低コストという利点との関連性が薄い、または一般的なリスクにとどまる。
0点: 無関係な内容、または無回答。

論理性（構造）(3点)

3点: 事象の因果関係が明確で、簡潔かつ論理的に表現できている。
2点: 因果関係は概ね伝わるが、表現にやや冗長な部分がある。
1点: 意図は伝わるが、文脈が分かりにくく不自然な記述となっている。
0点: 論理的に破綻している、または無回答。

解説

設問の趣旨

ローコード／ノーコード開発ツールの「短期間・低コスト」という利点が、開発手法の標準化や管理ルールの適用によってどのように損なわれるかを問う問題です。

高得点のポイント

開発申請手続が新たに適用されることに着目する。
手続の増加によって利用部門の負担が増えるという具体的なリスク事象を記述する。
一般的なシステム開発のリスクではなく、監査要点に沿ったローコード／ノーコード特有の影響を明記する。

誤答の傾向

「利点が損なわれる」という事象に直接関連しない解答（例えば、単に「管理不能になる」といった解答）は低評価となります。監査の観点から、どのような手続が誰の負担になるのかを具体的に示す必要があります。

設問1は，正答率はやや高かった。“短期間・低コスト”で開発できるという利点と直接関連しない解答も散見された。リスクを問う設問ではあるが，一般的なリスクではなく，監査要点に沿ったリスクを把握することが重要である点を理解してほしい。

設問2

〔監査手続書の作成〕 (2)について，検討されている開発判断基準に追加すべきと思われる項目を答えよ。

模範解答

類似アプリの有無

採点基準(配点 10点)

知識・理解度（内容）(6点)

6点: アプリの乱立や重複を防ぐための「類似アプリの有無」という確認項目を的確に挙げている。
4点: 既存アプリとの重複や類似性に触れているが、判断基準の項目名としてやや不正確な表現となっている。
3点: システムの乱立を防ぐ意図は見受けられるが、具体的な「類似」や「重複」の確認という観点が弱い。
1点: 開発判断に関する事項を挙げているが、乱立防止という監査目的に沿っていない。
0点: 無関係な内容、または無回答。

論理性（構造）(4点)

4点: 開発判断基準に追加すべき項目として、名詞句等で端的に記述できている。
3点: 項目としては理解できるが、文章表現が含まれるなど冗長な記述となっている。
1点: 意図は推測できるが、項目としての体裁をなしていない。
0点: 論理的に破綻している、または無回答。

解説

設問の趣旨

ローコード／ノーコード開発ツールの導入に伴うシステムの乱立や管理不能といったリスクを防ぐため、開発の判断基準に追加すべき項目を問う問題です。

高得点のポイント

無秩序なアプリ作成による重複を防ぐため、類似アプリの有無に着目する。
既存のアプリや他部門での開発状況を確認することが、無駄な開発を抑止するコントロールであることを理解する。
短いキーワードで端的に回答を構成する。

設問3

〔監査手続書の作成〕 (3)について，そのまま流用するのが適切ではない場合とはどのような場合か。25字以内で答えよ。

模範解答

開発するアプリの規模が小さく難易度が低い場合

採点基準(配点 8点)

知識・理解度（内容）(5点)

5点: 「アプリの規模が小さい」ことと「難易度が低い」ことの2つの条件を両方とも的確に捉えている。
4点: 規模の小ささと難易度の低さの両方に触れているが、やや曖昧な表現となっている。
3点: 「規模が小さい」または「難易度が低い」のいずれか一方の条件にしか触れていない。
1点: 簡便なアプリ開発であることには触れているが、条件の特定が不正確である。
0点: 無関係な内容、または無回答。

論理性（構造）(3点)

3点: どのような場合であるかを簡潔かつ明確に表現できている。
2点: 意図は伝わるが、文脈がやや分かりにくく冗長な記述となっている。
1点: 表現が不自然であり、条件としての説明が不足している。
0点: 論理的に破綻している、または無回答。

解説

設問の趣旨

標準的なシステム開発手法や管理ルールをそのまま適用することが、かえってローコード／ノーコード開発において非効率となる条件を問う問題です。

高得点のポイント

開発対象となるアプリの規模が小さいことを明記する。
対象アプリの難易度が低いという条件を含める。
手続が過剰となり、本来のツール導入目的を阻害するケースを的確に言語化する。

設問4

〔監査手続書の作成〕 (4)について，監査部が考えたリスクアを 35字以内で答えよ。

模範解答

権限を与えるべきでない利用者が本番環境のデータを参照できる。

採点基準(配点 8点)

知識・理解度（内容）(5点)

5点: 「権限のない利用者」が「本番環境のデータを参照できる」というセキュリティ上のリスクを正確に記述している。
4点: 権限外のアクセスと本番データに触れているが、事象の記述がやや曖昧である。
3点: 権限外のアクセスには触れているが、「本番環境のデータ」への参照という具体的な対象が欠けている。
1点: 不正アクセスや情報漏えいなどのリスクについて抽象的に触れているのみである。
0点: 無関係な内容、または無回答。

論理性（構造）(3点)

3点: リスク事象として成立する文で簡潔かつ論理的に記述できている。
2点: 意味は伝わるが、文末の結び方などリスク事象としての記述がやや不自然である。
1点: 主語や述語の対応が不適切であり、状況が正しく伝わらない。
0点: 論理的に破綻している、または無回答。

解説

設問の趣旨

ローコード／ノーコード開発特有の容易な環境構築によって引き起こされる、情報セキュリティ上のリスク事象を問う問題です。

高得点のポイント

アクセス統制の不備により、権限を与えるべきでない利用者がアクセス可能になる点を明記する。
対象が本番環境のデータであることを特定し、テストデータ等と明確に区別する。
不正な参照や情報漏えいにつながる具体的なリスク状態として記述する。

設問5

〔監査手続書の作成〕 (5)について，監査部が事務局に確認しようとしている内容を 45字以内で答えよ。

模範解答

標準フォーマットを使用した設計ドキュメント作成が可能かどうかを営業部に確認していること

採点基準(配点 8点)

知識・理解度（内容）(5点)

5点: 運用開始前の段階で、標準フォーマットを使用した設計ドキュメントの作成が可能かを「営業部」に確認することの必要性を正確に記述している。
4点: 標準フォーマットでの作成可否に触れているが、確認先（営業部）の明示が抜けている、または表現がやや不正確。
3点: ドキュメントの作成に関する確認であることには触れているが、具体的な確認内容（実現可能性など）の記載が不足している。
1点: 運用段階の監査手続（査閲や品質確認など）を記述しており、運用前の確認という設問の趣旨から外れている。
0点: 無関係な内容、または無回答。

論理性（構造）(3点)

3点: 確認する対象と内容を論理的かつ簡潔に一つの文にまとめられている。
2点: 内容は伝わるが、言い回しが冗長であるか、やや不自然な構成となっている。
1点: 文脈がわかりづらく、誰が何をするのかの関係性が不明瞭である。
0点: 論理的に破綻している、または無回答。

解説

設問の趣旨

開発手法の標準化に関する管理ルール案が、実際の業務プロセス（運用段階）ではなく、その手前の導入可能かどうかの段階において確認すべき内容を問う問題です。

高得点のポイント

開発を担当する営業部に対するヒアリングであることを明示する。
提示された標準フォーマットを使用した設計ドキュメントの作成が可能かどうかを確認する点を含める。
運用開始前の実現可能性の確認であることを踏まえた記述にする。

誤答の傾向

「分かりやすい記述になっているか」といった、運用開始後のドキュメント査閲を想定した解答は設問の趣旨（ルール案の適用前の確認）から外れているため減点となります。

設問5は，正答率が平均的であった。管理ルールが運用開始前にもかかわらず，実際のドキュメントを査閲して“分かりやすい記述になっていることを確認する”といった趣旨の解答が散見された。本設問は，管理ルール案の適用前に確認すべきことを問うており，運用段階の監査ではないことを理解してほしい。

設問6

〔監査手続書の作成〕 (6)について，監査部が確認すべき具体的な要件を 30字以内で答えよ。

模範解答

取得した操作ログが改ざん・消去されないよう保護すること

採点基準(配点 8点)

知識・理解度（内容）(5点)

5点: 操作ログの取得に留まらず、改ざんや消去から「保護（保全）」することの要件を正確に記述している。
4点: ログの保護について触れているが、「改ざん・消去」といった具体的な脅威の記述が曖昧である。
3点: ログの保全の必要性には触れているが、記述が抽象的であり要件としての具体性に欠ける。
1点: ログの種類や不正検知など、保全以外の要件に終始している。
0点: 無関係な内容、または無回答。

論理性（構造）(3点)

3点: システムが満たすべき要件としての記述形式を適切に満たしている。
2点: 内容は要件に合致しているが、監査手続（「～を確認する」等）に近い表現が混じっている。
1点: 完全に監査手続や監査ポイントの記述形式になっており、要件としての体裁をなしていない。
0点: 論理的に破綻している、または無回答。

解説

設問の趣旨

システム監査において、操作ログを適切に管理するための具体的なコントロール要件（ログの保全）を問う問題です。

高得点のポイント

単にログを取得するだけでなく、取得した操作ログが改ざん・消去されないようにすることを明記する。
そのための保護（保全）の措置が要件であることを示す。
「～すること」といったシステムの要件定義としての体裁で答える。

誤答の傾向

「どのようなログを取得すべきか（種類）」や「不正を検知する」といった目的論、または「ログの保護設定を確認する」といった監査手続そのものを記述した解答は、設問が求める「具体的な要件」に合致しないため減点対象となります。

設問6は，正答率がやや低かった。ログの種類や操作ログによる不正検知などの解答が散見された。ログの取得だけではなく，“ログの保全”に関する要件まで理解してほしい。また，監査手続や監査ポイントなど設問の趣旨と異なる記載も多く見られた。システム監査実務では，必要なコントロールを理解して，それが有効に機能しているかという観点で監査手続を検討する必要があることを理解してほしい。