IPAの令和7年度春期試験にて、システムアーキテクト試験を受験しました。
論文課題のある試験を受験するのは初めてで、大分苦戦したので自分のやった試験対策をまとめておきます。
受験時の状況やスキル等
受験状況
- 午前Iの免除は今回から期限切れ
- システムアーキテクト試験の受験は2回目
1年前の受験結果
- 去年は論文対策で心が折れ、午前IIと午後Iの過去問演習だけした状態で受験
- 午前IIは80点取れていたが、1年経って忘れていると思うので改めて勉強の必要がある
- 午後Iは95点取れていた、知識問題はないので改めての勉強は不要と判断
- ぶっつけ本番で書いた論文は文字数が足りずC判定
実務経験
- SE5年目
- 要件定義の経験はない
- スマホアプリ、Webアプリの開発経験がある
- 設計書は少し作ったことがある
- サーバの構築は、AWSを使用した構築を研修でやった程度
- テスト項目の作成や運用・保守は経験なし
主な所持資格
- 応用情報技術者試験
- 情報セキュリティマネジメント試験
- 情報処理安全確保支援士試験
- データベーススペシャリスト試験
- AWS Certified Developer ASSOCIARTE
- 簿記3級
やったこと
12月～1月
購入した参考書、「システムアーキテクト 合格論文の書き方・事例集」を読み、論文の書き方を知る。
論文事例を読んだり、書き写したりして論文の雰囲気や構成をつかむ。
システムアーキテクト 合格論文の書き方・事例集
システムアーキテクト試験の論文対策と、論文例について書かれた本。
業務経験のない若手向けに書かれている部分もあったので進めやすかった。
入社1年程度で受かる人が毎年いると書いてあったので、自分は業務経験が少ないから論文が書けない、とネガティブになったときもモチベーションにつながった。
2月～3月
そろそろ論文を書き始めないとまずいと思い、アイテックの論文添削コース（2回分）に申し込む。
論文演習や、章立て練習を週に2,3回の頻度で行う。
1回目の提出
2/22頃に1回目の提出用論文を書く。さぼりつつ書いたせいでもあるが、書き上げるまでに2日かかった。
論文を書いている途中で分からないことがあったときや、書く内容に詰まったときは、Web検索やChatGPTを活用しながら論述内容を決めた。
特に論文のネタ出しが苦手であり、業務の知識や事例を収集する必要があると判断し、本を読むことにする。(読んだ本は次の章にまとめる。)
採点結果は59点と合格まであと一歩及ばない点数だった。
論文で扱う業務事例の決定
参考書や、試験対策ブログを読んでいると、あらかじめ論文で使う業務事例を3つ程度に絞っておき、問題に合わせてその中から選択すると良いと書いてあったので、論文で扱う業務事例を決定する。
どの過去問にも対応できるような業務事例を考えた結果、「基幹業務システムの構築」「アパレル系ECサイトの構築」「基幹業務システムとECサイトの連携」の3つを業務事例として用意しておくことにした。
開発工数やサーバ台数、一日のアクセス数などは見当がつかなかったため、ChatGPTに相談しつつあらかじめ決定する。
この3つの業務事例について、論文の章立て練習を何回か行い、バッチ処理やシステム移行など、あらゆる設問に対応できるように、ネタをストックしておく。
2回目の提出
2回目の提出を3/16頃に行う。このときは4時間程度で書き上げることができた。
添削結果は62点、「もっと専門家としての考えをアピールしましょう」という内容が多かった。
このあたりで、論述問題で重視されるのは、業務事例としてのリアリティではなく、専門家としての問題解決能力だと思うようになる。
これまでは、バッチ処理の実行時間や利用者数の数値が妥当か、この数字や問題は実際にあり得ることなのか、というリアリティを気にして書いていることが多かったが、それよりも、「どういう問題があって」「どういう解決方法があって」「どういう理由でどの解決方法を選択したか」の流れを重視して書くよう意識するようになった。
読んだ本
システム設計の先導者 ITアーキテクトの教科書 改訂版
試験対策への貢献度：高
要件定義～運用まで、システムアーキテクトが何をすべきかが書かれている。
システムアーキテクトは何をすべきか、この本で理解することができた。
論述の話を膨らませるためにかなり役に立った。
システムを作らせる技術
試験対策への貢献度：中
システムを発注する側の視点で、要件定義で注意すべき点などが書かれている。
購入時期が遅かったため、あまり読む時間がなかった。
業務事例のみピックアップして読んだ。
SAP担当者として活躍するための ERP入門
試験対策への貢献度：中
業務システムの開発パッケージであるSAPの使い方について説明している。
基幹業務システムを論文で扱うにあたり、基幹業務システムパッケージの使い方を知っておこうと思い読んだ。
新人エンジニアのためのインフラ入門 ThinkIT Books
試験対策への貢献度：低
インフラの構築について、初心者向けに詳しく説明されている。
既に知っている内容が多かったが、改めて復習することができた。
基幹業務システムの設計理論
試験対策への貢献度：低
業務要件からではなく、業務の本質をとらえて設計する基幹業務システムの設計論が書かれている。
試験対策としては生かしにくかったが、内容はかなり面白かった。
4月
およそ3時間で論文が書けるようになる。
専門家としての考えを盛り込むことが苦手なので、引き続き論文対策をしつつ、午前I,IIの対策を始める。
午前I,IIは直近1年分を除く過去6回分の過去問を演習。およそ9割くらいの正解率にもっていった。
振り返り
受験してよかったこと
要件定義の流れが理解できた
普段の仕事では、自分の手元に仕事が来るときは要件定義が終わっていることがほとんどだが、その自分の手元に仕事が来るまでにどういう仕事があるのかを知ることができた。
文章作成能力の向上
特に苦手意識のあった文章作成能力を多少鍛えることができた。
興味のある分野の発見
学習の過程でソフトウェア設計に興味を持ち、さらに勉強しようと思えた。
モチベーションアップ
普段の業務より広い視点を持つことで、自分ももっとスキルアップしようというモチベーションになった。
試験対策の反省点
午前問の対策を余裕をもって始めるべきだった
試験直前に対策を始めたので、対策に掛けられる時間があまりなく、試験当日まで自信がないままだった。
論文演習をもっと回数をこなしてやるべきだった
特に、第1章を書き上げるまで35分という参考書に載っていた目標タイムを、最後まで切ることができなかったので、もっと回数をこなしてスピードを上げられるとよかった
第2章、第3章の文章を長くしすぎて、論述に時間がかかることが多かった。
どの程度のネタを用意して、どの程度細かく説明すればどの程度の文字数になるかという感覚を持てると良かった。
普段から本を読んでおくべきだった
普段文章を読む・書くということが少ないせいか、文章の組み立てが苦手だと実感した。
自分が書いた文章を読み返すと読みにくく、日本語としてもおかしいところがあったので、普段から文章の読み書きになれておけばよかった。
試験本番でも「〇〇した上で□□した上で☆☆を行い」というような、分かりにくい文章を書いてしまっていたが、気づいたのが試験終了直前で直せなかった。
今後の予定
せっかく論文を書く力を鍛えたので、プロジェクトマネージャー試験を受験する。
自分がプロジェクトマネージャーの仕事をすることは当分ないと思うが、マネージャー職の業務を勉強することで、上司の視点を理解できたり、マネジメントの視点をもって開発業務に取り組めるかもしれない。