応用情報技術者 2012年 秋期 午後 問11

解答の論理構成

1. a の位置に着目
   • 図1では「情報システム部」列の最上段が a、その直前に利用部門から矢印が入っています。
   • 本文冒頭に「情報システム部自らも、不具合対策などを行うに当たって、変更依頼票を作成する。」とあります。
   • したがって、情報システム部が最初に行う作業は“変更依頼票”を自部門で「作成」することになります。
   • よって a ＝ 変更依頼票作成 となります。
2. b の位置に着目
   • 「変更作業実施」後の判定「問題あり？」で“あり”となったときに遷移するボックスが b です。
   • 表2「チェックリスト」の“リスク”項目に「変更後に問題が見つかった場合に備え、変更を元に戻す切戻しの計画があるか。」と明記されています。
   • したがって“問題あり”時に実行される処理は「切戻し（＝変更を元に戻す）」です。
   • よって b ＝ 切戻し又は変更を元に戻す となります。

誤りやすいポイント

• 「提出」や「受付」と混同
  a は“受付”の前段階なので「変更依頼票提出」と思いがちですが、提出は利用部門の視点。情報システム部側では「作成」が正解です。
• 「再作業」との取り違え
  b を「再作業」や「リカバリ」と書いてしまうケースが見られます。本文では“切戻し”という正式語が使われているので要注意。
• チェックリストの読み落とし
  表2の“リスク”行を見逃すと b を特定できません。

FAQ

解答の論理構成

1. 影響範囲の確認
   ・問題文に「発注システムは、資材課専用サーバで稼働しており、資材課だけが使用している。」とある。
   ・よって影響は「変更を依頼した部門だけ」に限定される。
2. 新規開発の有無
   ・表4には「上長承認（新規）」および「承認者設定（新規）」と明記されており、新規モジュールを開発する変更である。
3. リスクレベル定義との照合
   ・表1のリスクレベルＣは「変更を依頼した部門だけに影響する。」かつ「含む（新規開発を含む）」である。
   ・前項1・2の条件が完全に一致するため、c＝「Ｃ」と判断できる。
4. 理由（40字以内×2）
   ①「資材課専用サーバで稼働しており、資材課だけが使用しているから」
   ②「上長承認モジュールと承認者設定モジュールを新規に開発するから」

誤りやすいポイント

• 「他部門にメール通知するから影響範囲は全社」と誤認し、Ａ／Ｂを選ぶ。
• 新規開発＝影響大と短絡し、影響範囲の条件を見落とす。
• 表1の「含む・含まない」を“機能追加の有無”と勘違いし、既存改修のみでもＡ／Ｃを選択。

FAQ

解答の論理構成

• 変更の目的は、監査担当である 「Ｃ氏」 が指摘した
  「発注担当者のミスによって、上長の承認を得ていない発注伝票が仕入先のファックス宛てに送信されてしまうおそれ」
  を排除することです。
• 追加後の機能一覧は 表4 にまとめられていますが、そこでは
  「ファックス送信」 モジュールの説明が、従来と同じ
  「伝票番号を指定すると、該当する発注伝票のファックス送信用データを作成し、仕入先のファックス宛てに送信する。」
  で止まっており、承認ステータスを参照していないことが分かります。
• 一方、同じ 表4 によって
  「発注伝票に承認のステータスを設け、初期値として未承認を設定する。」
  という新属性が導入されました。にもかかわらず、それを実際の送信プロセスに活用する記述がありません。
• したがって、ファックスを送る直前に
  「ステータスが承認済みであること」をチェックし、未承認なら送信しない
  という機能を 「ファックス送信」 モジュールに追加しなければ、Ｃ氏 の指摘には対応できません。
• よって解答は
  モジュール：ファックス送信
  追加機能：ステータスが承認済みの発注伝票に限って処理する。

誤りやすいポイント

• 「承認ステータスを付ければ自動的に安全」と誤解し、送信側のロジック変更を見逃す。
• 新規に作られる 「上長承認」 モジュールへ機能を寄せてしまい、既存モジュールの改修を忘れる。
• 変更対象を「発注伝票登録」と誤回答しがちだが、登録時点では未承認が規定値なので実害は発生しない。

FAQ

解答の論理構成

1. 変更依頼票の現状を確認
   図2の変更依頼票には
   「変更名称」「変更責任者」「変更依頼者」「変更内容」「希望利用開始日」「変更対象」
   しか項目がありません。
2. レビューで起きた問題点
   本文で B 君は「表4の変更後の発注システムの機能では不足があり、C氏の指摘には対処できていない」と判定されました。この“機能不足”は、未承認伝票が送信されるリスクを解消し切れていない点です。
3. 原因の分析
   下線②には「図2の変更依頼票の記述内容や表2のチェックリストに不足がある」とあります。
   ・表2のチェックリストは「変更対象」「作業計画」「作業体制」…といった実装・運用面中心で、**狙い（理由／目的）**を確認する項目が存在しません。
   ・図2の変更依頼票も同様に、なぜ変更したいのかを示す欄がありません。
4. 足りない情報
   レビュー時に目的・理由が文書化されていれば、「未承認伝票を送信させないこと」という本質要件を読み取れ、FAX送信モジュールの改修漏れを早期に発見できたはずです。
5. したがって、改善策として追加すべき項目は変更の理由（または目的・効果）となります。

誤りやすいポイント

• 「チェックリストに手順書レビューはあるから十分」と考え、要件面の抜けに気付かない。
• 機能不足＝設計ミスと思い込み、依頼票の情報量不足が原因だと結び付けられない。
• 「影響範囲」チェック項目があるので目的確認も含まれると解釈してしまう。

FAQ