1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

クソザコ社内SEの僕でもシステムアーキテクト試験に一発合格できた話

Last updated at Posted at 2025-07-22

僕について

  • 非IT企業の管理部門でシステム開発や運用を担当しています。(在籍2年)
  • システム開発といっても、社内の各部署にヒアリングを行って、ベンダーと一緒に要件定義をやって、後はベンダーに発注して眺めてる感じの仕事です。(お恥ずかしい...)
  • 2022年の秋期試験で応用情報に合格しました。(その時の体験談はこちら
  • ちなみに応用情報は一回落ちてます。

やるぞ!

応用情報合格後、少しだけ情報処理安全確保支援士試験の勉強をしていたのですが、つまらなすぎて途中でやめてしまいました。
その後はプライベートを謳歌していたのですが、色々と落ち着いたこともあり久々にIPAの試験を受けてみることにしました。

午前1の免除期間は終わっていたので最初からのスタートになりましたが、仕事で少ながらずシステム開発に携わっているのでやる気はそれなりにありました。

勉強を開始したのは2024年12月11でした。(1日目だけ勉強日記をつけていた)

参考書は重要!!!!

見てください。4冊も買っています。不安になって買い足していった結果です。

IMG_2795.JPEG

ですが、結果的にはこの4冊買いが功を奏しました。

午後2の時に書きますが、写真の下2冊の本は両方買って損はないと思います。

午前1

応用情報と同じく、過去問道場を直前10回分を繰り返し解きました。
通勤中、電車の中でほぼ毎日少しずつやってました。

image.png
image.png

いつのまにか有料になってましたが迷わず購入。
神サイト。
サブスク解除はお忘れなく。

午前2

過去問道場がないので、こちらのサイトを利用。
僕が受けたときには更新が止まってて、過去問が1年分だけありませんでした。

image.png

効率を上げるため、Excelに各年度の正答率と苦手な単語をメモってました。
image.png

1周したら正答率が低い年からやっていく感じですね。
知らない単語があったら適当に調べましょう。
まあ大丈夫でしょう。

午後1

さてここからが本番です。
午後1については自分なりのコツや気を付けたことを紹介できればと思います。

コツ1:問題冊子を印刷する

参考書にも当然午後1の問題は載っているのですが、私はわざわざ過去問をコンビニで印刷して解きました。
やはり本番に近づけて練習するのは大切です。
もちろん時間も45分測って解きましょう。

コツ2:問題文に設問番号を書く

各設問には [〇〇の××]について、××を答えよ とだいたいは書かれています。

令和6年春期の問2の設問
image.png

これは問題本編の章のタイトルを指しています。

同じく令和6年春期の問2の問題文
image.png

ここで僕なりの方法をお伝えします。

問題冊子を開いたら、最初に設問を確認します。

次に、設問の番号を、対応する章のタイトルに書き込んでいきます。
(問1だったら「①」を書きます)

本番もやっていました。
IMG_2796.JPEG

番号を付け終わったら、設問自体は読まずに普通に頭から問題を読んでいきます。

そして、自分がつけた印のところまで読んだら中断し、いったん設問を読んで何を聞かれているのかを理解したら、また印のついたところから読み始めます。

ここで、回答できる場合は回答します。
そしたらまた本文を読み始め...の繰り返しで最後まで到達します。

僕はこの方法がいい感じでした。

コツ3:ヤバい箇所に印をつける

問題文には、「なんかヤバい感じ」の文章がちょくちょくまぎれています。
ここが要望に絡んできたり、回答のカギになることがあります。
僕は問題を読んでいて少しでも「ヤバそう」と感じたら下選を引いて「ヤバ」と書いていました。

上の画像でも書いてありますね。
問題を注意深く読む癖もつくのでお勧めです。

コツ4:システム名称に印をつける

問題文ではたくさんシステムが登場するので、何が出てきたのかを忘れないように四角で囲んでいました。
少なくとも、何個のシステムが出てきたのかは把握しやすくなります。

コツ5:その他自分なりの注意点

  • 確信を持てない答えは誤り
  • 回答は誤解を生まないように書く
  • 世間話のような意味のないことが突然書かれている場合は注意。意味もなく書かない。「なぜこの文を書いたのか?」「これが何か問題を起こさないか?」を考える
  • 条件は1つじゃないかもしれない
  • 設問に関連しない章からキーワードを持ってきて答える必要がある時もある
  • なんとなくで答えを決めない。必ず理由は本文に書いてあるから探す
  • 逆に、問題で書かれていないことを勝手に仮定しない

午後1まとめ

難しそうですが、これは「国語の試験」です。
システム開発の知識は一切不要で、答えは必ず問題文の中にあります。

ちょっと慣れれば45分で解くこともそこまで難しくなくなりますので頑張りましょう。

午後2

本番の試験が終わった後、僕は絶対落ちたと思いました。
論文の出来が散々だったからです。

試験当日はトボトボ帰りましたし、合格発表当日も憂鬱な気持ちでマイページを開きました。

合格してた感想は、「えっ、嘘でしょ......」でした。
そんな僕が合格できた理由について色々考えてみたので、午後2はそれらを紹介したいと思います。

理由1:「テンプレート」の存在に気付けた

IPAの午後2の過去問を見ると、1問1ページの問題がありますよね。
でも実はよく見ると、問1の前にこんなページがあることにお気付きでしょうか...?

image.png

そう、実は論文を書く前に、システム開発の概要を書く必要があるのです。
(通称「テンプレート」)

しかも、これ自体も採点対象なのです。

僕は最初TACのピンク色の本で論文の勉強をしていたのですが、この本には一切このことは書かれていませんでした...なんという...

ですから別の本でこのことを知った時にはかなりビビりました。

実際には以下のような用紙が一緒に配られるので、ここに書いていく形になります。

image.png

本番で初めて知ったら取り返しのつかないことになっていました。

理由2:良い参考書に出会えた

少なくとも、以下の2冊の本を買っていなかったら僕は確実に落ちていました。

情報処理教科書 高度試験午後II論述 春期・秋期
画像1.jpg

著者は、高度試験に全部受かったことで有名な三好康之先生です。
この本では論文試験の基本的な考え方が学べます。

鉛筆の選び方や段落番号の付け方のような具体的なところからカバーしてくれており、この本を読んで論文試験との向き合い方を学べました。

システムアーキテクト 合格論文の書き方・事例集

画像2.jpg

僕が本番なんとか論文を書ききれたのは、はっきり言ってこの本のおかげです。
この本では、論文を書くための「型」を徹底的に教えてくれます。

とにかくオススメです。

三好先生の本とどちらか一冊を選ぶならこちらですが、三好先生の本にしか載っていない情報や考え方も多いので、やはり両方買うのが良いかと思います。

理由3:AIを使いまくった

論文の題材については、自分が開発に携わったシステムや比較的関連が深い社内の業務システムを2~3選びました。

題材を決めた後は、テンプレート埋めです。

image.png

僕はサーバーの台数など、さっぱり適切な値が分からなかったので、最初は以下のサイトを参考にしました。

しかし、今はAIの時代です
ChatGPTにシステムの概要をAIに伝え、適切なサーバー台数などを決めてもらいました。
image.png

使いまくれば普通にテンプレートは埋めていけると思います。

これだけでなく、設定に困った時や文章が上手くいかない時など、AIはフル活用していました。

image.png
悩みも聞いてくれる。

理由4:テクニックを身に着けた

まずは、自分で設定した題材に関して、設問アを何も見ずに書けるようにしました。
平日の夜は時間もやる気もないので、せめて設問アだけは素振りしようというような感覚で頑張りました。

論文を通して書くのは土日でしたが、結局120分の時間を測って書いたのは4~5回程度だったかと思います。
しかも、字はめちゃくちゃ雑に書いて、途中で飽きてきたら適当な感じで終わったりもしていました。

終わってから考えると、練習時に大切なことは、完璧な論文を仕上げることでもなければ、設定を磨き上げることでもなく、参考書のテクニックをマスターすることかと思います。
なぜなら......

本番

当日は、自分で用意していた題材が全く使えなさそうな設問が出てきました。
(問1:複数システムを組み合わせたデータ指標、問2:データ移行)
せっかく準備した題材が水の泡です。

データ移行は全く経験したことがなかったので、問1を選択しました。
pythonを使ったデータの処理や分析は普段から行っていましたが、1から設定を練り上げる必要があり、最初から絶望的な気持ちでした。

参考書にあるテクニック通り、
「〇〇という課題があったため、××と考え、△△という仕様にした」
「一方で××という意見や課題があったため、さらに△△という仕様の追加を行った」

というような構造になるように設定を組みましたが、細かい部分は書いている自分も笑ってしまうくらい荒唐無稽になっていた気がします。
もう殆ど忘れていますが、だいたい以下のような感じだったかと思います。

  • 勤怠システムと財務システムからデータを取り、プロジェクトごとの生産性(利益/人月)を指標とする
  • 勤怠システムだけだと複数プロジェクトに従事する人の時間配分が分からない
  • 予定表アプリと連携し、そちらから細かいデータを取ってきて配分を作成する
  • 予定表アプリの入力率が低いから、入っていない時は等配分にする
  • これで大成功!!!

みたいな感じです......
苦しい......

苦しみながらも、最後まで書ききることだけは頑張りました。
字も汚いですし、落ちたことを確信し、合格発表まで憂鬱な日々を過ごしていました。

結果

画像1.png
採点者が仏のように優しかったのでしょう。
やっぱり嬉しいです。
全ての人に感謝。

image.png

まとめ

僕は本当に大したエンジニアではありません。
SQLもたまにググりながら書く程度ですし、DB設計もできません。
当然PMとしてプログラマを導く立場で仕事をしたこともありません。

こんな僕でも合格できたので、IT企業に勤められている方々でしたら頑張れば絶対合格できると思います。

それだけをとにかく伝えたくてこの記事を書きました。

最後までお読みいただきありがとうございました!!

1
1
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
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?