2022/12/27：更新
こんにちは。本記事ではシステムアーキテクトの午後ＩＩ過去問分析を行います。
本記事を読んでいただければ、
- 論述問題はどのように過去問分析を行えばよいか
- 最近のシステムアーキテクトに求められる論述力は何か
が分かると思います。
なお、本記事で参照している過去問はIPAサイトからダウンロードができます。
はじめに
まずはどのように過去問分析を行えばよいか？という問いに対して、
回答を出しておきます。
- 問題文を設問ア、イ、ウに区切る
- 問われているのがどのフェーズ(要件定義・開発・テストなど)かを読み取る
- 出題要旨を読み、最も問われていることを読み取る
- 採点講評を読み、期待されている論述例と失敗例を読み取る
ひとつずつ解説していきます。
すぐに具体的な問題分析をしたい方は、本節は読み飛ばしてください。
1. 問題文を設問ア、イ、ウに区切る
このことは、多くの参考書でも言われていることですが、
試験用紙を配られたらすぐにやる、
本番においても有効な手順です。
問題文を読んだ後、設問文を読んで、
もう一度問題文を読みながら、問題文のうち、
ここからここまでは設問アのことをいっている、
ここからここまでは設問イのことをいっている、
というように、文章を対応付けする（区切る）作業のことです。
これを行うことで、設問に応じた「望ましい振る舞い」を
問題文からあぶりだすことができます。
本記事では、設問ア、イ、ウに区切ることを黒の太線で区切り、
設問で問われていることと問題文での対応箇所を黒線をひいて
分析します。
2. 問われているのがどのフェーズなのか
設問で問われているのがどのフェーズなのかを、
システム開発のＶ字モデル（下図）を参照にして、
明らかにして論述に臨む必要があります。
たとえば、要件定義とシステム要件定義は明確に異なります。
前者は業務目線、後者はシステム目線での論述が必要です。
両方いっぺんに設問で問われることがあります。
例：対象の業務ならびにシステムについて述べよ
いっぺんに問われる場合でも、「自分はわかっているんだぞ」と
明確に分けて記載する必要があります。
これをごっちゃに捉えて記載しているだけで、合格圏内から
大きく遠のくことになるでしょう。
本記事では、問題文の横に四角でどのフェーズかを明示します。
3. 出題要旨を読む
出題要旨を読み、どこに力点を置いて評価しているかを
読み取ります。
多くの場合、出題要旨の文章は問題文と同じ表現・類似表現になっています。
出題要旨と問題文を見比べて、対応箇所をマークするだけでも
分析になると思います。
本記事では、出題要旨で最も問われている箇所と、
問題文・設問文で対応する箇所を青線で示します。
4. 採点講評を読む
採点講評を読み、何が適切な論述で、
何が不適な論述であるかを読み取ります。
特に、不適な論述から読み取れることは多いです。
本記事では、採点講評で適切とされる論述を説明している箇所と、
問題文・設問文で対応する箇所を赤線で示し、
不適とされる論述を説明している箇所を赤の破線で示します。
令和3年春
問1 アジャイル開発における要件定義の進め方について
●問題文
●設問文
●問題文・設問文からの分析
アジャイル開発という、ウォーターフォール開発とは異なる手法では
ありますが、システム開発フェーズとしてはV字モデルにあてはめて
考えることができます。
設問イ・ウにおいてはスプリント期間でユーザストーリ単位での開発を
行うことになります。
ユーザストーリとはユーザ要求の表し方の一つですが、
INVEST*1という特徴があり、
テスト可能であるということまで考えることから、
フェーズとしては要件定義～開発～テストまでを含んでいると言えるでしょう。
設問イはユーザストーリの分類の仕方と、
それをどうスプリント期間におさめるか規模・難易度を調整したかを
主に問われており、
設問ウは抽出したユーザストーリの
優先順位のつけ方について主に問われています。
イとウで共通しているのは、どちらもプロダクトオーナーと
呼ばれる関係者（利用者）との合意を踏まえて決定する必要があり、
業務要望とシステム要求を明確に分けて論述する必要があるでしょう。
●出題要旨
●採点講評
●出題要旨・採点講評からの分析
出題要旨の最初の段落は、問題文と同一の文章も多く、
設問アのゾーンは全く同一の文章となっています。
設問イとウのゾーンは要点だけが記載されているので、
問題文において出題要旨文からの消込を行えば、
問題文上の具体例などだけが残り、問題文の骨子が理解できると
思うので、ぜひやってみてください。
青線で記載している点が最も重要な箇所であり、
その内容は採点講評の赤線（適切とされる論述に必要なもの）と
一致します。
ユーザストーリの分類、規模・難易度の調整（設問イ）
ユーザストーリの価値に基づく優先順位付け（設問ウ）
赤の破線からは、不適切な論述例が書かれています。
ここを読めば、
- 一般的な要件定義ではない踏み込んだUSの具体性
- USの価値
- 規模・難易度の説明だけでなく調整とその結果
が求められていることが分かります。
●所感・対策
まず、アジャイル開発を採用せざるを得ない背景・制約条件の作りこみ（設問ア）が
重要になると感じました。
- 断続的なリリースが必要な状況
- 圧倒的なニーズ・認知があるため都度改善が求められる状況
などが考えられると思います。
設問イを論述するには、
要求分析～USの分類～規模・難易度の仮決定～USの設計・実装～スプリントごとの調整
の順序をイメージし、プロダクトオーナと協議しながら
調整したことを盛り込むとよいでしょう。
設問ウの論述には、
イがスプリントサイクルのプロセスに着目しているのに対し、
USの優先順位をユーザ価値に基づき決定したことを
記載するのがよいでしょう。
プロダクトバックログの分析～優先順位付けの基準の定義～USの決定
の順序をイメージし、具体的な複数のUSからユーザ価値に
基づいてプロダクトオーナとともに選定したことを
盛り込むのがよいでしょう。
この問題の具体的な論文の書き方についてはこの記事も参照ください。
問2 情報システムの機能追加における業務要件の分析と設計について
●問題文
●設問文
●問題文・設問文からの分析
設問ア・イ・ウで問われているフェーズが明確であり、
各フェーズの論文エピソードが用意できていれば
取り組みやすい問題だと思います。
設問アでは要件定義フェーズまでのことが聞かれているので、
背景のことと、業務要件までを記載します。
情報システムのそのものの概要も記載しますが、
システムに求められるシステム要件まで記載してはいけません。
設問イでシステム要件～ソフトウェア要件を記載しますが、
要件定義を分析するフェーズを盛り込まなくてはなりません。
設問ウはソフトウェア要件定義の範囲として記載するのがよいでしょう。
不適切であると考えられます。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
出題要旨の3段落目でも触れられていますが、
「情報システムの機能追加で」という前提があります。
中心となる要件定義～設計に気を取られ過ぎて、
前提が「新規システムの構築」となっていないか注意しましょう。
出題要旨・採点講評からは、「業務要件の分析とその設計」が
最重要と読み取れます。
採点講評のNG例としては、
- 業務要件の分析の視点がない
- 分析結果に基づく設計ということが説明されていない
ことが言われているので、
分析の視点を盛り込めば合格圏内に大きく近づけると思います。
●所感
要件定義～システム要件定義の"橋渡し"を
いかにうまく行うかが論述ポイントとなり、
SA区分として比較的王道的な問題と思います。
設問ウは設計の中でも特に工夫したという部分なので、
具体的な実装の引き出しの多い方は、論述しやすい内容と思います。
注意したいのは、設問イでも設問ウでも「設計」について
論じなければなりませんが、
- 設問イ：要件定義分析に基づいてこう設計した（設計の結果）
- 設問ウ：業務要件を踏まえて工夫した具体的な設計（実装の具体例）
の違いを意識しなければなりません。
問3 IoTの普及に伴う組込みシステムのネットワーク化について
●問題文
●設問文
●問題文と設問文からの分析
組込みシステムの問題全般に言えるかもしれませんが、
問われているフェーズの範囲は小さいですね。
設問アですら、システム要件定義寄りの業務要件であり、
「ネットワーク化の目的」を中心に書くと、業務要件を
書く配分は必然的に小さくなりそうです。
しかし、設問イでは障害の想定や被害拡大を未然に防ぐ
必要があることから、業務への影響を加味せねばならず、
業務要件は必ず必要でしょう。
ただ、その背景となるシステム化計画などまで触れると、
紙面が足りなくなるのではないでしょうか。
設問ウは達成状況と今後の課題が問われているので、
評価と追加の課題に言及すれば良いです。
書きやすい反面、他の受験者と差をつけにくい設問と思います。
●出題要旨
●採点講評
●出題要旨と採点講評の分析
出題要旨は何度も「ネットワーク」という単語が出ています。
組込みシステムを中心に、ネットワーク経由で連携する各システムと
システム全体のことを記載することは必須でしょう。
それゆえ発生するセキュリティや障害のリスク顕在時に
どのように各システムが動作するのかを説明することが
求められています。
採点講評からは、NG例が次のように述べられています。
- システム全体の抽象的・一般的な説明に終始する
- 実装の細部にとどまっている
全体だけでも細部だけでも足りないということですね。
全体の説明と、その特徴に基づく課題・解決策（細部）という
流れが論述しやすいと思われます。
●所感
当然ながらエンベデッドスペシャリストを合格していると有利として、
この問題の場合はネットワークスペシャリストも合格していると
論述の引き出しが増えるでしょう。
本問ほど"ネットワーク押し"でなかったとしても、IoTの本質は
ネットワーク経由でのシステムの協調動作なので、
各年度の問3はネットワークスペシャリストを保持していると
有利と言えると思います。
脆弱性が放置されたIoTデバイスは攻撃者の格好の餌食となり、
問題となっています。
- 踏み台にされるような脆弱性は放置せず、当初から対策すること
- 協調動作する上では監視の仕組みも盛り込むこと
- ネットワーク断絶に備え内臓メモリを持つ設計にすること
などが具体的に論述できるかがポイントとなると思います。
令和1年秋
問1 ユーザビリティを重視したユーザインタフェースの設計について
●問題文
●設問文
●問題文と設問文からの分析
設問アとイの区分けを問題文からしづらい問題でした。
設問アは業務（要件定義）を問われていて、
設問イはシステム（システム要件定義）を問われています。
問題文は業務要件＝想定する利用シーンと
システム要件＝ユーザビリティが混ぜ込まれて書かれており、
何をどの設問で論述すべきか整理する必要があったでしょう。
設問ウは打って変わって設計プロセスに聞かれており、
仮説検証のしやすい設計プロセスである、
アジャイル的開発手法を提案できたかというところが
ポイントとなると思います。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
出題要旨からは、設問イならびに設問ウが重点出題であったことが
うかがわれます。
設問イを適切に論述するには、設問アとの論じ分けが重要です。
設問アで想定利用者の利用シーンを定義し、
設問イで想定利用者向けのUIを論述する
といったように進めるべきかと思いました。
最低2つはユースケースを定義して、各々について
説明すると論点が伝わりやすく、字数も増えると思います。
採点講評からも、設問アとイで問われていることの
境目が不明瞭であったり、どちらかしか書かれていなかったりする
論述がNG例として紹介されています。
●所感
令和3年問1と同じく、ユーザストーリの考えを取り入れた、
スクラム的開発手法が求められる問題であったように感じます。
また、問題文を設問文単位で素直に分割できないことから、
難易度としては高めであったのではないでしょうか。
採点講評で言われている通り、業務要件（利用者にとっての価値）と
システム要件（操作性などといったユーザビリティ）を
きちんと分けて論述することも肝であったと思います。
問2 システム適格性確認テストについて
●問題文
●設問文
●問題文と設問文からの分析
同年度の問1とは打って変わって、問題文を設問の3つに
区分けしやすい問題でした。
設問アは王道的な前提条件の問いかけです。
鍵は設問イとウですが、いずれもシステム適格性テストの
フェーズであることが重要で、ソフトウェア適格性テストや
運用テストのフェーズでないということに
注意が必要です。
さらに、問題文を区分けした各中身も、SAとして望ましい振る舞いが
説明された後に具体例を列挙されているという、
とても読みやすい素直な問題です。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
出題要旨からは、設問イとウが重点出題であったことが読み取れます。
効率的なテストのための区分けや配慮：設問イ
結果を効率的に確認する方法：設問ウ
という対応ですね。
採点講評からは、設問イに関する指摘が中心で、
システム適格性テストというフェーズにフォーカスしていないと、
減点になるということが読み取れます。
また、システム適格性テストの一部の実施にとどまる論述も
NG例と書かれていることから、システム適格性テストの在り様を
頭に入れてかかる必要があるでしょう。
すなわち、
システム適格性テストとはシステム要件定義の対となるもの
であり、
システム要件定義とは業務要件を分析してシステム要件を抽出する
フェーズであるという理解です。
このことを頭に入れておけば、システム適格性テストにおいて、
なぜ業務の観点を取り入れて計画する必要があるかが
分かると思います。
●所感
一言で言って、素直な出題であり、
テスト系の王道的な出題であったと思います。
設問イがプロセス重視であるのに対し、
設問ウはよりテクニカルな工夫が問われており、
技術的な能力を示すエピソードが求められるでしょう。
他のプロジェクトとのバッティングを回避したり、
負荷試験のフェーズを調整したりするなど、
マネジメント的な工夫も盛り込むことができるので、
様々な異なるバックグラウンドをもった受験者でも、
各々に書きやすい問題だったと思います。
問3 組込みシステムのデバッグモニタ機能について
●問題文
●設問文
●問題文と設問文からの分析
設問アではシステム化計画からの記述が求められているのが
エンベデ系にしては特徴的と思います。
設問ウは「評価」というフェーズを割り当てましたが、
設問イで論述した内容（各種要件定義）に対する評価が
述べられていれば十分と考えます。
「開発・検証・出荷後の各段階」というのがキーフレーズであり、
出荷後を「評価」するためには実際に出荷後がどうであったかを
論述するのが最も無難であるので、設問ウについては、
時系列としてはプロダクトがリリースされた後の時点から
評価するのがよいでしょう。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
出題要旨は設問イが最大の出題意図であることがうかがわれることに
加え、「セキュリティ」という記述があるのが特徴的と思われます。
設問ウで評価する観点に、セキュリティを配慮したかという観点が
論述できているかも重要なポイントとなるでしょう。
採点講評からは「開発・検証・出荷時の各段階」の要求と対応内容が
重要であることが読み取れます。
各段階の要求が異なるというのが組込みシステムならではの特徴であり、
システム要件定義のフェーズである、
SW要求・HW要求・運用ワークアラウンドのどれに割り振るかを
システムアーキテクトとして検討する姿勢が重要でしょう。
●所感
令和3年秋の問3ほどではないにしろ、
問題文の中断に「IoT」「ネットワーク」という記載がある以上、
IoTデバイスを意識したシステムを論述対象にすると
書きやすかったのではないかと思います。
また、「開発・検証・出荷時の各段階」は指定されているので、
ここは変えずにそれぞれの段階について論述するのが無難でしょう。
その結果、それなりに字数が必要となるので、制限字数内に
抑えるため、簡潔に論述しきる方針で臨むのがよいでしょう。
平成30年秋
問1 業務からのニーズに応えるためのデータを活用した情報の提供について
●問題文
●設問文
●問題文と設問文からの分析
フェーズとしては典型的な「要件定義」フェーズの問題です。
設問ウは課題に対する工夫ということでより実装に近い工夫を
書けばよく、開発・設計技術のアピールをしましょう。
論述テーマとしてはスマートプロモーションや
ビジネスインテリジェンスの抽出など、
単なるデータの提供ではなく、一定の範囲・量を前提した
累積データを基にする必要があります。
新規設計のシステムでも書けなくはないですが、
既存のシステムに対する論述とした方が無難なテーマと
言えると思います。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
求められたニーズ（設問ア）、分析結果と提供情報（設問イ）、
課題と工夫（設問ウ）といずれも力点の置かれた、
ある意味でバランスの良い問題だったと思われます。
ア・イ・ウを通じて具体的・明晰に論述できていないと、
評価の土俵に上がれない、敷居の高い問題だったとも
いえると思います。
採点講評からは、分析を伴わない要望元のいいなりになった
情報提供ではいけないと釘をさしています。
要望元のニーズを分析して、真のニーズを探り当てる
フェーズが必要となり、ST寄りの出題であったと
言えるかもしれません。
●所感
黒線（設問）、青線（出題要旨）、赤線（採点講評）の
いずれも問題文の同じ所にひかれるという結果になりました。
一本筋の通った問題であるともいえますが、
分析しにくい問題でもありました。
抽象化すれば、
- 設問アは背景、業務要求
- 設問イは要求分析、情報提供（システム要件定義）
- 設問ウは課題、工夫
ということで、王道的な構造の問題であったとも言えます。
求められている論文構造はそれほど難しくないので、
難しさがあったとすれば、データ分析・インテリジェンス出力系の
開発経験に携わったことがあるか？というところが
取り組みやすさをわけるところと言えるのではないでしょうか。
問2 業務ソフトウェアパッケージの導入について
●問題文
●設問文
●問題文と設問文からの分析
パッケージの導入を主題とした問題。
ソフトウェア要件定義（方式設計）のフェーズが中心と
思いきや、問題文の例に運用ワークアラウンドが触れられている
ことから、主題（設問イ）のフェーズは「システム要件定義（方式設計）～
ソフトウェア要件定義（方式設計）」としました。
設問ウは施策への評価が問われていますが、
問題文は対応箇所が無いというパターンです。
パッケージ導入のフィット＆ギャップ分析を中心的に論述する
問題で、比較的素直な出題形式と思います。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
パッケージの導入の背景として、業務要件を適切に記載することが
求められていることが読み取れます。
業務要件の記載がないと、「業務への踏み込み」ができないためです。
また、業務要件の分析というフェーズも論述として求められます。
業務要件を総体的に分析した上で解決策を述べないと、
「その解決策で本当に業務が円滑に遂行できるか」が不明なためです。
さらに解決策を抽出する上で、検討方針が必要と書かれています。
このことから、一連の流れは、
業務要件～パッケージの機能～分析～検討方針～解決策
という形で展開するのがよいと思います。
●所感
パッケージ導入はソフトウェア方式設計のフェーズですが、
導入期間の短縮が図れるなどの期待から、
システム化計画時点から検討に入ってくるということは、
実際の現場においてもよくあることと思います。
要件定義のフェーズ、
システム方式設計のフェーズ、
ソフトウェア方式設計のフェーズなど
各フェーズは意識した上で、パッケージ導入の検討を
進めたいです。
これらのフェーズは、理論上、逆向きにはいかないので、
論述する上では、順序だてる必要があります。
パッケージ導入ありきで物事が進む現場でもありがちですが、
なぜパッケージを選定しているのか、何の課題が解決するからなのか
といったところは意識したいですね。
問3 組込みシステムのAI利用、IoT化などに伴うデータ量増加への対応について
●問題文
●設問文
●問題文と設問文からの分析
文章量は多い印象。
設問ウは、問題文からはほぼ対応箇所がありません。
フェーズとしては、ソフトウェア要件定義以降～としています。
解決策の達成度や開発段階で生じた未達事項などの問題を
問われているため、開発段階、テスト段階、リリース後評価などを
駆使して論述すればよいと思います。
設問イの問題文対応箇所は、組込み系システムの一般的な
制約、課題についてかなり具体的に書かれているので、
別年度の論述においても参考になりそうな記述です。
●出題要旨
●採点講評
●出題要旨と採点講評からの分析
採点講評からは、データ量の増加という観点を踏まえる必要があると
読み取れるので、設問アで、背景部分を伏線として論述できるかが
鍵となるでしょう。
発生した問題をシステムアーキテクトとしてどう解決したかと理由が
問われていると読み取れます。
その書き方ですが、採点講評によれば、
- 部分的な処理の対策内容にとどまる
- システム全体を俯瞰していない
ような論述はNGとしています。
きちんと論述するには、設問イで理由部分に、
なぜその対策で解決できるかといった＝要件定義を満たすためにどう分析したか
という視点を盛り込んで論述する必要があるでしょう。
●所感
問題タイトルにも含まれている通り、IoTやAIといった技術が
意識されています。
AIに関しては処理が高度になるので、デバイス側で処理するのは
非現実的であり、IoTはネットワーク経由という制約を加味した
システム設計が必要になってきます。
主題としては「データ量の増加」というところに
かかってくるので、業務要件上、なぜデータ量が増える必要が
あったのか、というところは触れておかないと
NGだと思います。
ソフトウェアとハードウェアの役割分担など、
エンベデ系の設計スペシャリストとして、
采配する姿勢でもって論述する必要があるでしょう。
最近のシステムアーキテクトの傾向
共通の採点講評の分析
各年度の採点講評は、問1～問3に共通する部分があるので、
あげてみます。
●令和3年
●令和1年
●平成30年
キーフレーズとしては、
- 自らの体験に基づき素直に答えていること
が適切であり、
- 問題文に記載してあるプロセスや観点を抜き出し、
一般論と組み合わせただけ - 実施事項にとどまり、理由や検討の経緯が不在
はNGとあります。
これらのことを意識しないと
- システムアーキテクトとして考慮し、取り組んだこと
にはならないと読み取れますね。
結論としては、書かれている内容は大同小異ですが、
それだけ適切とされない論述が提出されるということが、
後を絶たないのだと思います。
まとめ
それでは、具体的にどういった論述をすれば、
NG例にならないのでしょうか？
3年分の過去問・採点講評を分析をして見えてきたこととしては、
- システムと業務をきちんとわけて論述すること
- 部分的な論述ではなく総体的に把握して論述すること
- 要件を「分析」して次のフェーズの要件につなげること
といったことが重要ということです。
3点目については、システム要件定義フェーズであれば、
前フェーズで定義された業務要件を分析してシステム要件を
抽出する、といった具合ですね。
以下、本記事の集大成としてまとめておきます。
採点講評（共通）より
- [OK]自らの体験に基づき素直に答えていること
- [NG]問題文に記載してあるプロセスや観点を抜き出し、
一般論と組み合わせただけ - [NG]実施事項にとどまり、理由や検討の経緯が不在
これらを意識しないとシステムアーキテクトとして考慮し、
取り組んだことにならない。
重要なポイント
- システムと業務をきちんとわけて論述すること
- 部分的な論述ではなく総体的に把握して論述すること
- 要件を「分析」して次のフェーズの要件につなげること
おわりに
いかがでしたでしょうか？
システムアーキテクトに限らず、
過去問分析の仕方や、最近の傾向について
理解できる記事になっていれば幸いに思います。
では、合格を目指して共に頑張りましょう。
本ブログでは、高度情報処理試験の、合格に向けたサポート記事を充実していきます。
「読者になる」ボタンで、ブログの更新時に通知されますので、ご検討ください。
ではそれまで。
*1:Independent(独立性)、Negotiable(対話可能)、Valuable(ユーザ価値)、Estimable(見積もり可能)、Small(小さい)、Testable(テスト可能)を示す頭文字
