SA

一問一答

40問オリジナル問題5科目中5科目
1 / 40
契約・合意○×

RFPでは、取得する製品やサービスの範囲と技術的制約を整理する。

記録

0解いた
—正解率
0間違えた
記録はこの端末だけに保存
記録はこの端末のこのブラウザ(localStorage)にだけ残り、サーバーには送りません(会員登録なし)。別の端末には引き継がれず、ブラウザのサイトのデータを消したときなどに消えます。最後に間違えた問題が「間違えた問題」に入ります。

練習できる範囲

問題のある科目

  • 契約・合意4問
  • 企画10問
  • 要件定義8問
  • 開発14問
  • 運用・保守4問
形式の違い・注
  • ここは○×と4択だけです。本試験は「CBT。A-1:四肢択一30問・50分、A-2:四肢択一25問・40分、B-1:記述式3問中2問・90分、B-2:論述式2問中1問・120分。」です。
  • 問題の数・時間配分・記述や計算・実技の練習にはなりません。正解できても、SAの合格を約束するものではありません。
  • 同じ科目でも、論点の一部だけを扱っています。科目の名前は、このサイトが問題の分野を公式の科目に当てはめたものです。
  • 公式の資料・条文から作った問題で、過去問の転載ではありません。本試験の形式・範囲の全部の代わりにはなりません。

問題の一覧

  1. 問1RFPでは、取得する製品やサービスの範囲と技術的制約を整理する。

    答え:○(正しい)

    整理します。供給者に示す要求として、対象の一覧や技術的制約を文書化します。

    根拠:SAシラバスVer.5.2 1-1

  2. 問2供給者は、提案書を社内で調整せず提出することがシラバスの原則である。

    答え:×(誤り)

    社内調整の上で提出します。取得者のRFPに応じた提案を用意する活動です。

    根拠:SAシラバスVer.5.2 2-1

  3. 問3システム化計画では、システム変更作業を行うための方針も定める。

    答え:○(正しい)

    変更作業の方針も定めます。運用・保守に対する基本方針の項目で扱います。

    根拠:SAシラバスVer.5.2 4-10

  4. 問4全体開発スケジュールは、サブシステム間の整合性を考慮せず作成する。

    答え:×(誤り)

    整合性も考慮します。要員・納期・コストなどとともに、サブシステム単位の開発予定を組み立てます。

    根拠:SAシラバスVer.5.2 4-16

  5. 問5システム化計画の文書化では、外部委託する作業項目も示す。

    答え:○(正しい)

    作業項目も示します。委託時のスケジュールや品質要求等も文書化して承認を得ます。

    根拠:SAシラバスVer.5.2 4-21

  6. 問6新システムとの連携のために必要な新機能は、業務モデルから除外する。

    答え:×(誤り)

    業務モデルに加えます。他システムとの連携方針を明らかにする活動に含まれます。

    根拠:SAシラバスVer.5.2 4-9

  7. 問7既存システムの再利用を検討するときは、稼働条件も明確にする。

    答え:○(正しい)

    稼働条件も明確にします。継続利用や移行、パッケージ・外部サービス利用の機能範囲も検討します。

    根拠:SAシラバスVer.5.2 4-12

  8. 問8教育訓練の基本方針では、対象者や実施時期を決める必要はない。

    答え:×(誤り)

    対象範囲やスケジュールも決めます。目的・体制・設備・環境とともに明確にします。

    根拠:SAシラバスVer.5.2 4-13

  9. 問9利害関係者の要求をまとめる際は、利用者の能力も制約として扱う。

    答え:○(正しい)

    能力や運用特性も含めます。技術上の要求だけでなく、利用者側の条件も整理します。

    根拠:SAシラバスVer.5.2 5-1

  10. 問10業務要件には、業務用語を含める必要がない。

    答え:×(誤り)

    業務用語も含めます。業務内容やルール・制約、外部環境との関係も記述します。

    根拠:SAシラバスVer.5.2 5-2

残りの30問を見る
  1. 問11組織・環境要件には、新業務で使う事務所や設備の導入方針を含める。

    答え:○(正しい)

    導入方針も含めます。組織構成や要員に加え、必要設備の計画と時期を具体化します。

    根拠:SAシラバスVer.5.2 5-3

  2. 問12システムの実現範囲を決めれば、人が担当する作業は機能要件から除く。

    答え:×(誤り)

    人が担当する作業も明らかにします。機能間のデータの流れやシステム化の範囲とともに整理します。

    根拠:SAシラバスVer.5.2 5-4

  3. 問13非機能要件には、移行時期や移行手順を含める。

    答え:○(正しい)

    移行要件として含めます。対象業務・ソフトウェア・ハードウェアも整理します。

    根拠:SAシラバスVer.5.2 5-5

  4. 問14運用開始時期は、要件定義ではなく稼働後に初めて決める。

    答え:×(誤り)

    要件定義で検討します。定義した要件を実現するスケジュール上の条件として整理します。

    根拠:SAシラバスVer.5.2 5-6

  5. 問15システム要件定義では、顧客だけでなく運用要員のニーズも分析する。

    答え:○(正しい)

    運用要員のニーズも分析します。開発するシステムの具体的用途に関わる要件を文書化します。

    根拠:SAシラバスVer.5.2 7-1

  6. 問16システム方式設計では、ハードウェアと手作業への機能分担を扱わない。

    答え:×(誤り)

    それらへの分担も扱います。ハードウェア・ソフトウェア・手作業で必要な構成品目を識別します。

    根拠:SAシラバスVer.5.2 8-1

  7. 問17ソフトウェア要件では、データ項目の形式や値の範囲も定義する。

    答え:○(正しい)

    データ定義も行います。形式・長さ・値の範囲などを整理します。

    根拠:SAシラバスVer.5.2 9-1

  8. 問18ソフトウェア適格性確認のテスト要件は、詳細設計が終わるまで検討できない。

    答え:×(誤り)

    ソフトウェア要件定義で検討します。要件を満たすことを確認するテスト要件を定義します。

    根拠:SAシラバスVer.5.2 9-2

  9. 問19ソフトウェア方式設計では、構成要素を結合するための暫定テスト要件を定める。

    答え:○(正しい)

    暫定的なテスト要件と予定を定義します。詳細設計の段階で更新される内容です。

    根拠:SAシラバスVer.5.2 10-4

  10. 問20システム結合の計画には、手作業を結合する作業を含めない。

    答え:×(誤り)

    手作業も含めます。ソフトウェア・ハードウェア等と結合し、システム品目とする計画です。

    根拠:SAシラバスVer.5.2 12-1

  11. 問21導入で既存システムを置き換えるときは、並行運用も考慮する。

    答え:○(正しい)

    並行運用も考慮します。既存システムを継続利用するための支援も検討します。

    根拠:SAシラバスVer.5.2 14-1

  12. 問22取得者への支援では、利用者の操作能力に応じた教育を考慮しない。

    答え:×(誤り)

    操作能力に応じた教育を考慮します。契約に沿い、初期だけでなく継続的な教育・支援を提供します。

    根拠:SAシラバスVer.5.2 15-3

  13. 問23運用テストは、新しいリリースを運用する前にも行う。

    答え:○(正しい)

    新しいリリースに対しても行います。運用環境への導入前に、運用上の要求を満たすか確認します。

    根拠:SAシラバスVer.5.2 16-5

  14. 問24システム保守では、変更要求を調べずに直ちに変更作業へ進む。

    答え:×(誤り)

    変更要求や問題報告を分析します。影響を調査し、修正案を検討します。

    根拠:SAシラバスVer.5.2 21-1・21-2

  15. 問25システム運用の評価では、故障の頻度や回復時間を調べる。

    答え:○(正しい)

    故障の頻度や回復時間を調べます。運用評価報告を基に稼働率等を評価し、改善を検討します。

    根拠:SAシラバスVer.5.2 18-1

  16. 問26移行後、旧運用の関連データはアクセスできない状態にするのが原則である。

    答え:×(誤り)

    アクセス可能な状態に保持します。アクセスはデータ保護・監査に関する契約上の要求に従います。

    根拠:SAシラバスVer.5.2 17-3

  17. 問27システム方式設計では、利用者用文書の暫定版を作成する。

    答え:○(正しい)

    暫定版を作成します。システム方式設計の段階で利用者に必要な文書を準備します。

    根拠:SAシラバスVer.5.2 8-2

  18. 問28システム結合後のテスト結果は、文書化する必要がない。

    答え:×(誤り)

    結合結果とテスト結果を文書化します。開発の進捗に応じて結合した集合体を要件に対してテストします。

    根拠:SAシラバスVer.5.2 12-2

  19. 問29供給者へ調達条件を伝える準備として適切なものはどれか。
    1. 1. 受入れ基準を文書化する
    2. 2. 契約条件をすべて伏せる
    3. 3. 実環境の制約を隠す
    4. 4. 対象範囲を供給者に伝えない

    答え:1. 受入れ基準を文書化する

    受入れ基準の文書化です。RFPを準備する際に要求と条件を整理します。

    根拠:SAシラバスVer.5.2 1-1

  20. 問30プロジェクト計画の承認時にSAが行う助言はどれか。
    1. 1. 承認者の質問を破棄する
    2. 2. 承認者からの質問に回答する
    3. 3. 品質要求を計画から除く
    4. 4. 調達する製品の条件を隠す

    答え:2. 承認者からの質問に回答する

    承認者の質問を把握して回答します。システム全体計画の観点から支援します。

    根拠:SAシラバスVer.5.2 3-2

  21. 問31新業務の開始と旧システム停止の予定を整理する方針はどれか。
    1. 1. 画面の文字サイズだけの方針
    2. 2. 開発者の休暇方針
    3. 3. システム移行の基本方針
    4. 4. 入札者への指示だけ

    答え:3. システム移行の基本方針

    移行の基本方針です。開始日程・移行方法・旧システム停止日程を整理します。

    根拠:SAシラバスVer.5.2 4-8

  22. 問32環境整備の基本方針で見積もる対象はどれか。
    1. 1. 利用者の氏名だけ
    2. 2. 広告の色だけ
    3. 3. ソースコードの文字数だけ
    4. 4. 期間別のシステム資源と使用量

    答え:4. 期間別のシステム資源と使用量

    期間別のシステム資源と使用量です。開発・運用・保守の環境を考慮します。

    根拠:SAシラバスVer.5.2 4-11

  23. 問33システム化計画の承認を得るため、誰に説明するか。
    1. 1. 情報戦略推進の責任者
    2. 2. 製品の利用経験のない第三者だけ
    3. 3. 保守用具の販売員だけ
    4. 4. 試験会場の監督員

    答え:1. 情報戦略推進の責任者

    情報戦略推進の責任者に説明します。関係者への説明と協力の要請も行います。

    根拠:SAシラバスVer.5.2 4-21

  24. 問34システム化計画のコスト予測で含める対象はどれか。
    1. 1. 開発終了日の天気だけ
    2. 2. 開発・運用・保守の費用
    3. 3. 機器購入費以外をすべて除外
    4. 4. 会議室の名称だけ

    答え:2. 開発・運用・保守の費用

    開発・運用・保守などの費用です。システム投資効果を判断するために整理します。

    根拠:SAシラバスVer.5.2 4-18

  25. 問35利害関係者の要求が食い違った場合の技能として適切なのはどれか。
    1. 1. 両方の要求を無条件で採用する
    2. 2. 関係者への説明を避ける
    3. 3. 矛盾を整理して解決策を提示する
    4. 4. 食い違いを記録から消す

    答え:3. 矛盾を整理して解決策を提示する

    矛盾を認識し、解決策を提示します。個々の要求をまとめて合意形成につなげます。

    根拠:SAシラバスVer.5.2 5-4・5-5

  26. 問36データの保存周期や保存量を整理する要件はどれか。
    1. 1. 入札者の氏名
    2. 2. 建物の所有者名
    3. 3. 契約書の印刷枚数
    4. 4. 運用・操作要件

    答え:4. 運用・操作要件

    非機能要件の運用・操作要件です。監視や復旧条件などとともに整理します。

    根拠:SAシラバスVer.5.2 5-5

  27. 問37システム要件を評価する際の観点はどれか。
    1. 1. 要件のテスト可能性
    2. 2. 担当者の署名の大きさ
    3. 3. 製品名の長さ
    4. 4. 報告書の紙の色だけ

    答え:1. 要件のテスト可能性

    テスト可能性を評価します。システム方式設計・運用・保守の実現可能性も検討します。

    根拠:SAシラバスVer.5.2 7-2

  28. 問38ソフトウェア詳細設計で到達する設計の粒度はどれか。
    1. 1. 事業名だけ
    2. 2. 実装してテストできるユニット
    3. 3. 調達先候補の一覧だけ
    4. 4. 組織全体の経営理念だけ

    答え:2. 実装してテストできるユニット

    コーディング・コンパイル・テストできるユニットまで具体化します。方式設計より細かな設計です。

    根拠:SAシラバスVer.5.2 11-1

  29. 問39システム適格性確認テストを実施する際の対象はどれか。
    1. 1. 広告の好感度だけ
    2. 2. 提案書の製本方法だけ
    3. 3. 各適格性確認要件
    4. 4. 受験者の人数だけ

    答え:3. 各適格性確認要件

    システムの各適格性確認要件です。要件ごとに適合性を確認するテストを実施します。

    根拠:SAシラバスVer.5.2 13-1

  30. 問40システム方式評価で、要件との対応以外に確認するものはどれか。
    1. 1. 署名の字体だけ
    2. 2. 担当者の住所だけ
    3. 3. 会議の曜日だけ
    4. 4. 設計標準・方法の適切さ

    答え:4. 設計標準・方法の適切さ

    設計標準と方法の適切さです。方式を評価する複数の基準の一つです。

    根拠:SAシラバスVer.5.2 8-4

出典と注(2026年10月確認)9件

注

  • 問題と解説はこのサイトで作ったものです。根拠は各問題の解説の下にリンクしています。法令の改正などで答えが変わることがあります。直したところは訂正履歴に残します。