5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

皆さま情報処理技術者試験は好きですか?
私は好きです。
対策は苦しいこともありますし、試験も長丁場ですが、合格したときの嬉しさはひとしおです。

情報処理技術者試験を複数区分受験していると、ある区分で実施した対策が他の区分にも活きてくることが多々あります。
その中でも、高度区分の論述対策は解き方がある程度共通なため、ある区分で得た知見を別の区分に流用しやすいと思います。
本記事では自分が午後Ⅱの論述対策1をする中で、区分に関わらずやっていることについて書いていきます。

まとまりのない内容となってしまいましたが、、どなたかのお役に立てれば幸いです。

論述問題の基本の解き方

基本的に以下のような順番で解いています。

  1. 問題選択
  2. 設問から要求事項を抽出
  3. 章立てを整理
  4. ネタの整理
  5. 第1章(設問ア)を書く
  6. 質問票を埋める
  7. 第2, 3章(設問イ、ウ)を書く
  8. 受験番号、氏名、問題選択の丸などの確認
  9. できる範囲で見直し
  10. 消しゴムかすなどの除去

以降、2~4について2023年春期のシステムアーキテクト試験の問2「利用者と直接の接点がない情報システムのユーザーインタフェースの検討について」2をサンプルに書いていきます。

2. 設問から要求事項を抽出

設問1~3の要求事項に番号を振っていきます。
サンプル問題の設問で実施すると、例えば下記のようになります。

  1. あなたが開発に携わった、開発者が利用者と直接の接点を持つことが難しい情報システム
  2. 開発の目的
  3. 対象の業務
  4. 情報システムの概要
  5. 設問アで述べた情報システムにおけるUIについて
  6. 利用者をどのように想定し
  7. どのようなUIを検討したか
  8. 検討で発生した適切なUIを選択する際の課題
  9. その対応策
  10. 設問アで述べた情報システムでUIを継続的に適切化していくための工夫について

image.png

3. 章立てを整理

抽出した要求事項を盛り込んで章題を決めます。
本番では章題を書き出す時間が惜しいので、設問に1-1, 1-2とか書きこんでいます。

章題は例えばこんな感じです。

第1章 携わった情報システム
1-1 開発の目的
1-2 対象の業務と情報システムの概要
1-3 利用者と直接の接点を持つことが難しい理由
第2章 利用者像をどのように想定し、どのようなUIを検討したか
2-1 利用者像の想定
2-2 UIの検討
2-3 UIを選択する際の課題とその対応策
第3章 UIを継続的に適切化していくための工夫

4. ネタの整理

問題文を読んで使えそうな経験やアイデアを書き込んでいきます。
サンプルの例でいうと、次のようなことをしています。

  • 通販サイトかスマートフォンアプリケーションの書けそうな方を丸で囲む
  • 利用者に直接確認することが困難な状況の具体例を書く
  • 利用者の性別や年齢層、ITリテラシーの具体例を書く
  • 開発サイクルの短期化や画面や機能の利用状況のモニタリングする機能の書けそうな例を思い出して書き込む

自分の経験や知識から問題文に対応する具体例を引っ張り出してきて紐づけていくようなイメージです。

image.png

論述で心がけていること

設問アを書くときは経験を元に単純化

過去問演習で設問アに概要を書こうとして800字に収まらなかったことはありますか?
私はあります。
自分の携わったプロジェクトなりITサービスなり情報システムなりの概要を不足なく説明しようとすると800字では到底足りないのです。
ではどうするか。
設問イ、ウに必要な情報以外は極力削るのです。

具体的には、会社とシステムに関する情報を中心に整理しています。

会社

現実の世界だと1つのお仕事に複数の会社が関わってくることが多々あるかと思います。
システムを使う会社と作る会社が別だったり、1つのシステムを作るのに複数の会社が関わってきたりします。

しかし、複数の会社の役割や関係性を読み手に判りやすく説明しようとすると、800字しかない貴重な文字数を費やす必要があります……。
そこで、複数の会社が登場することが設問イ、ウを書く上で必要な設定でなければ、登場する会社を減らすなり統合するなりしています。

私の場合、B to Cのシステムの場合は1社(自社開発)、B to Bのシステムの場合は2社(発注企業と受注企業)に整理することが多いです。
プロジェクトマネージャ試験等で、複数企業間の関係を設問イ、ウに書く場合は、書きたい内容に合わせて3社目、4社目を登場させています。

システム

現実の世界だと1つのお仕事で複数のシステムを扱うことが多々あるかと思います
しかし、複数のシステムの概要について読み手に判りやすく説明しようとすると、800字しかない貴重な文字数を費やす必要があります……。
そこで、複数のシステムが登場することが設問イ、ウを書く上で必要な設定でなければ、登場するシステムを減らすなり統合するなりしています。

また、説明が難しいシステムの場合は、説明しやすい機能に絞って論述したり、より説明しやすい近いシステムに置き換えたりしています。

臨場感の出るエピソードは積極的に入れていく

設問アの文字数を鑑み会社やシステムの情報は整理していますが、設問イ、ウに書くと臨場感の出るエピソードは積極的に入れていくようにしています。
具体的には、時事ネタ(改元の影響で~、コロナ禍の影響で~、Y年施行の○○法の影響で~等)や業界固有のネタ(○○業界ではM月が繁忙期なので~、○○なユーザが多いという特性があるので~等)があれば極力取り入れています。

社名人名は機械的にイニシャル化

論述内に社名や人名を出すときは元の社名、人名を連想させないよう機械的に命名しています。
社名はアルファベットの前半からA社、B社、C社、人名は後半からX氏、Y氏、Z氏といった形でつけています。

対策時に論述がまとまらなくて困ったとき

あまり業務経験のない区分などで、論述対策を進めようとしても筆が進まないこともあるかと思います。
そういう時は、次のような対策を実施しています。

  • 参考書の論述例をアレンジして書き写してみる
  • 午後Ⅰをアレンジして論述してみる

参考書の論述例をアレンジして書き写してみる

参考書に掲載されている論述の例の内、自分の経験に近そうなものを選び、書き写してみます。
この時、題材にする業界やシステムは自分が取り上げようと思っているものに適宜置き換えて書くと、本番で書くときに頭から取り出しやすいと思います。
アイテックの合格論文の書き方・事例集シリーズが論述のサンプルが沢山掲載されていておすすめです。

午後Ⅰをアレンジして論述してみる

午後Ⅰの過去問の内、すでに解いた問題を午後Ⅱのネタ集めの題材にすることもあります。
この時も、自分の経験に近いものが使いやすいと思います。

余談:午後Ⅱ直前の休憩時間にやっていること

午前Ⅰと午後Ⅱの休憩時間に以下のようなことをやっています。
私は筆圧が高く、2時間文字を書いていると腕が痛くなってしまいます。
痛みを軽減し、最後まで書ききるために、休憩時間中に腕に湿布を貼っています。

  • シャープペンシルの芯を補充する
  • 消しゴムを綺麗にしておく
  • 糖分とカフェインを補給する
  • 利き腕に湿布を貼る
  • 対策時に自分が書いた設問ア、質問票を見返す

おわりに

午後Ⅱの論述についていつか書いてみたいと思っていたので、アドベントカレンダーで書くことができて良かったです。

最後まで読んでくださった方ありがとうございます。

  1. 論述有の区分としては、PM, SM, AU, SAの4区分を取得しています。ES, STについては未取得です……。

  2. https://www.ipa.go.jp/shiken/mondai-kaiotu/ps6vr70000010d6y-att/2023r05h_sa_pm2_qs.pdf

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?