‹

システムアーキテクト 午後Ⅱの書き方

システムアーキテクト試験の午後Ⅱは，自分の経験をもとに2時間で答案を書く論述式です。 このページでは，当サイトが収録している16年度分・46問の出題テーマと採点講評を読み比べて， 出題の傾向，くり返し指摘されていること，設問ア〜ウの書き方をまとめます。 最後に，令和7年度の2問について骨子（答案の設計図）の例を載せます。

午後Ⅱの形

時間配分や練習の進め方など，区分によらない進め方は高度試験の勉強方法にまとめています。

出題テーマの傾向

平成21年度から令和7年度までの問題名を並べると，問われる場面は次のように分けられます。 どの場面でも，業務を理解したうえで，情報システムをどう設計したかを問う点は共通しています。

場面問題名の例
要件定義・業務の分析 要件定義（平成21年度），業務要件の優先順位付け（平成28年度），非機能要件を定義するプロセス（平成29年度），アジャイル開発における要件定義の進め方（令和3年度）
方式・構造の設計 システム間連携方式（平成22年度），システム方式設計（平成27年度），柔軟性をもたせた機能の設計（平成29年度），バッチ処理の設計（令和6年度）
画面の設計 ユーザビリティを重視したユーザインタフェースの設計（令和元年度），利用者と直接の接点がない情報システムのユーザーインタフェースの検討（令和5年度）
移行・テスト システムの段階移行（平成21年度），システムテスト計画の策定（平成23年度），情報システムの移行方法（平成28年度），現行システムと新システム間の差異を踏まえたデータ移行（令和7年度）
データ活用・新技術 データを活用した情報の提供（平成30年度），概念実証（PoC）を活用した情報システム開発（令和4年度），先進技術の適用（令和6年度），複数の情報システムのデータを収集する必要がある指標の提供（令和7年度）

令和4年度からは，PoC・DX・先進技術・データ活用のように新しい技術や業務の変化を扱う問題が毎年1問は出ています。 一方で，移行や設計のような定番の場面もくり返し出ています。 題材を用意するときは，新しい技術を使った経験と，移行・設計のような定番の経験の両方を用意しておくと，どちらの問題にも対応しやすくなります。

令和5年度までの問3（組込みシステム）は，令和6年度から出題されていません。

採点講評でくり返し指摘されていること

IPA は毎年，採点講評で答案の傾向を公表しています。年度をまたいで読み比べると，同じ指摘が何度も出てきます。 裏を返せば，ここを避けるだけで答案の評価は上がりやすいということです。

1. やったことだけで，理由や経緯がない

令和3年度から令和7年度まで5回続けて，全問に共通する講評で指摘されています。 令和7年度の講評は「実施した事項を論述するだけにとどまり，実施した理由や検討の経緯が読み取れない論述も少なからず見受けられた」としています。

「〇〇を採用した」で終わらせず，ほかにどんな案があり，どういう理由で〇〇を選んだのかまで書きます。 案を2つ比べて，業務の制約から1つを選んだ，という流れにすると，検討の経緯が自然に入ります。

2. 問題文の観点を抜き出して，一般論と組み合わせただけ

平成23年度から平成28年度まで毎年，令和4年度から令和6年度まで毎年，全問に共通する講評で指摘されています。 令和4年度の講評の言葉では「問題文に記載してあるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述」です。 平成27年度の講評は「問題文に記載した観点や事例は，例示である。」とはっきり書いています。

問題文の例をそのまま使うのではなく，自分の題材ではそれが具体的に何だったのか（どの業務の，どのデータの，どんな制約か）に置き換えて書きます。

3. 業務の視点が抜けている

SA の講評で特に多い指摘です。業務要件を書かずにシステムの話だけをしている， 業務の特性ではなくプロジェクトの制約を書いている，といった答案が多くの年度で挙げられています。 平成28年度の講評は「情報システムの設計，開発に当たっては常に業務を意識してほしい」， 令和3年度の講評は「システムアーキテクトは，業務と情報システムを橋渡しする役割を担う」と書いています。

設計の理由を書くときは，「性能がよいから」のようなシステムの理由だけでなく， その業務では何が困るのか，何を守らなければならないのかから説明します。

4. 問われたことと違うことを書いている

計画を問われているのに実施の話を書く（平成23年度）， 業務の概要を問われているのにプロジェクトの概要を書く（平成24年度）， 複数の項目を問われているのに一部にしか答えていない（平成25年度）などが挙げられています。

書き始める前に，設問文を問われている項目ごとに区切り，答案の段落と1対1で対応させます。 このサイトの演習画面では，設問ごとに問われている項目を整理して表示しています。

設問ア〜ウの書き方

設問ア：業務とシステムの概要（400〜800字）

設問アは，設問イ・ウの土台です。問われる項目は年度によって違いますが， ほとんどの年度で対象とした業務と情報システムの概要が入っています。 SA では「業務の特徴」を書けるかが特に大事で，ここで書いた業務の特徴や制約が，イの設計の理由になります。

設問イ：何をどう検討・設計したか（800〜1,600字）

答案の中心で，字数も最も多い部分です。 「状況 → 検討した案 → 選んだ案と理由 → 工夫」の流れで，検討の経緯が見えるように書きます。

設問ウ：問われ方は年度によって違う（600〜1,200字）

ほかの区分では設問ウで評価と今後の改善を問うことが多いのですが， SA の令和以降の問題では，設問イの続き（直面した問題と対応，移行のタイミングと実施方法，など）を問うことが少なくありません。 「ウは評価を書くもの」と決めつけず，設問文が求めていることに答えます。

骨子の例：令和7年度

骨子は，書き始める前に作る答案の設計図です。本番では構成に15分ほどかけ， 設問ごとに「何を，どの順で書くか」をメモしてから書き始めます。

ここに載せる骨子は，書き方を示すために運営者が作った架空の事例です。 IPA の解答例ではありません（IPA は午後Ⅱの解答例を公表していません）。 実際の答案は，自分が関わった業務とシステムで組み立ててください。

問1　複数の情報システムのデータを収集する必要がある指標の提供について

題材の例：食品スーパーのチェーン（40店舗）で，廃棄ロスを減らすために， 店舗別・商品分類別の廃棄率を指標として商品部と各店長に提供した。

設問書くこと（字数の目安）
ア
  • 業務目標：日配品・総菜の廃棄ロスを前年比で2割減らす。廃棄は利益を直接押し下げており，経営の重点課題だった
  • 指標：店舗別・商品分類別の日次の廃棄率（廃棄数量 ÷ 仕入数量）。商品部は発注の基準づくりに，店長は翌日の発注量の判断に使う
  • 収集元：POS システム（販売実績），発注システム（仕入数量），店舗の在庫管理システム（廃棄の登録）
  • 自分の立場：指標を提供する機能の設計を担当（約700字）
イ
  • （1）算出の手順と提供のタイミング：店長は朝9時の発注締めまでに前日の廃棄率を見る必要がある。日中の随時連携と夜間の一括集計を比べ，締めに間に合い，店舗システムへの負荷も小さい夜間一括を選んだ
  • （2）データ定義の差の吸収：POS は JAN コード，発注システムは自社の商品コードで，総菜は POS では個数，廃棄登録では重量だった。対応表を商品マスタ側に持たせ，重量は商品ごとの標準重量で個数に換算する方式にした。個別に変換処理を作る案より，マスタの保守に一本化できる点を重視した
  • （3）提供のしかた：店長は売場で見るので，前日の値と過去4週の同じ曜日の平均を並べ，基準を超えた分類だけを強調する画面にした（約1,300字）
ウ
  • データの内容の問題：①繁忙な店舗ほど廃棄の登録漏れが多く，廃棄率が実態より低く出ていた　②天候が売れ行きに大きく影響するが，社内に天候のデータがなかった
  • 対応：①仕入数量 −（販売数量 ＋ 在庫の増減）で廃棄数量をみなし計算し，登録値との差が大きい店舗には登録を促す通知を出した。あわせて，バックヤードの端末でバーコードを読むだけで登録できるようにした　②外部の気象データを日次で取得し，天候別に比べられるようにした（約800字）

ポイント：講評が挙げた「業務目標と指標の関係が不明確な論述」を避けるため，アで目標と指標の関係（誰が，何の判断に使うか）をはっきり書いています。 ウは，イの設計の話（コードの違いなど）と混ぜず，データそのものの欠落・不在に絞っています。

問2　現行システムと新システム間の差異を踏まえたデータ移行について

題材の例：機械部品の卸売会社2社の合併に伴い，2社の販売管理システムを1つの新システムに統合した。

設問書くこと（字数の目安）
ア
  • 業務：工場向けの部品の受注・出荷・請求。得意先は約3,000社，受注は1日約2,000件。月末の請求締めは止められない
  • システム：A社は自社開発の販売管理システム，B社はパッケージを個別に改修したもの。新システムは A 社のシステムを基に再構築
  • 背景：合併後も2つのシステムで受注していたため，同じ得意先への請求が2通に分かれ，与信の管理も別々だった（約650字）
イ
  • 調査：両社の得意先・単価・受注残のデータについて，項目の意味と値のバリエーションを調べた
  • 差異①：両社に同じ得意先が別のコードで登録されていた（約400社）→ システム面：法人番号と住所で名寄せ候補を自動で作る。業務面：候補は両社の営業担当が確認して確定する
  • 差異②：単価の持ち方。A 社は得意先別の単価，B 社は数量に応じた段階単価 → システム面：段階単価を新システムの数量条件付き単価に変換する。業務面：変換できない個別の特約単価（約150件）は，営業担当が新システムの画面から登録する
  • 差異ごとに，自動で変換するか人が登録するかを分けた理由（件数と，誤ったときの業務への影響）を書く（約1,300字）
ウ
  • 移行計画を検討した観点：①受注を止められるのは土日の2日間だけ（作業時間）　②請求金額の誤りは取引先の信用に直結する（作業品質）
  • タイミング：月末の請求締めを終えた直後の週末。締めた後なら，移行する売掛の残高が確定しているため
  • 実施方法：得意先・単価のマスタは2週間前に移行して営業担当が確認し，その後の変更は差分で反映した。受注残と売掛残高は移行日に一括で移行し，件数と金額の合計を現行システムと突き合わせた。リハーサルを2回行い，作業時間が2日に収まることを確かめた（約800字）

ポイント：講評が挙げた「現行システムと新システム間の差異を明確にせず，実施した事項の記述にとどまっている論述」を避けるため， イは差異を先に書き，移行方法がどの差異に対応するかが分かる順にしています。 ウは「観点を踏まえて」と問われているので，観点を先に示し，そこからタイミングと実施方法の理由を説明しています。

過去の出題テーマ

当サイトに収録している SA の午後Ⅱの問題名です。年度を選ぶと，問題文・出題趣旨・採点講評を読めます。

システムアーキテクトの過去問を演習する