システムアーキテクト試験を受けてきた
前に情報処理技術者試験はもう飽きたとか言ってたような気もしますが,懲りずに受けてきましたので,毎度のように何やってたか簡単にまとめておきます.
概要
システムアーキテクト試験(SA試験)は,主にシステム開発の上流工程を担当するエンジニアに向けた試験で,簡単に言えば,要件定義,外部仕様設計あたりを主な出題範囲としている. 対象となるシステムは,情報システムと組込みシステムの2つがあり,その中から自分が得意な分野の設問を選択して解答できる作りになっている.
出題傾向
試験は,
- 午前1(全問必答.多肢選択式.50分.問題は全高度試験で共通)
- 午前2(全問必答.多肢選択式.40分)
- 午後1(4問中2問選択.記述式.90分)
- 午後2(3問中1問選択.論述式.120分)
の4つ.
スペシャリスト試験とは違い,午後2試験が論述問題になっている.
出題形式はわりと明確で,かつ年度によるブレは大きくない印象.
午前2で基本的な知識を確認.
午後1では,与えられた現状仕様/システムを理解し,そこからシステムを設計したり改修したりする問題が多く出題される. 4問中3問が情報システム,残りの1問が組込みシステムについての設問.
午後2では,リード文を読んだ上で,自身の経験をもとにした論文を書く. 試験の最初に,関わった業務やシステムについての基本情報の欄を埋めてから,各設問について論述していく. 「設問ア」,「設問イ」,「設問ウ」の3つの設問があり,それぞれ,「800字以内」,「800字以上1,600字以内」,「600字以上1,200字以内」という字数制限がある. 3問中2問が情報システム,残りの1問が組込みシステムについての設問.
受験動機
正直に言って,スペシャリストを3つ取ってしまって情処に対するモチベーションはかなり下がっていたし,やろうと思えばいくらでもネタのでっち上げができそうな論述試験なんてやる意味あるのかという疑問は拭えなかったが,
- 業務で上位設計者としての仕事を任されることが増え,一般的なアーキテクトができる(しなければならない)ことが知りたくなった
- モチベーションが高かった頃になんとなく買った参考書が残っていた
午前1免除がもったいなかった- 「エンジニアにも説明力が必要」というこちらのブログ記事の内容に大きく頷くことができた
これらから,受験を決めた.
やったこと
2017年8月中旬
上記のように思い悩みながらも受験申し込み.
8月下旬〜9月上旬
少し時間が取れたので,午後試験を中心に勉強を始めた. 自身の業務領域と問題数を考えて,組込みシステムの問題を取ることは100%ないと思ったので,最初の段階で捨て,情報システムの問題にヤマを張ることにした.
使ったのは,先ほど挙げた参考書.
- 作者: 松田幹子,松原敬二,満川一彦
- 出版社/メーカー: 翔泳社
- 発売日: 2017/03/07
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
午後1については,1問やってみて多少の手応えを感じられたので,労力少なめで進めることに決めた. やはりスペシャリスト試験に比べると技術まわりの出題の難易度は低く,業務でもアーキテクトとして理不尽&&意味不明な仕様と闘っていることもあり,問題文の勘違いさえしなければ,さほど厳しくはならないだろうと感じた. 解く際には,問題文の重要そうな点には線を引くようにし,また,データの流れが複雑な場合についてはできるだけ図を書くように工夫した.
やはりキモになってくるのは午後2で,一度何も考えず問題を解いてみて,これは慣れが必要だと感じた.
まず,とにかく手書きがダルい. 普段はほとんどシャーペンを持たないので,腱鞘炎になりそうで文字を書くのがただただつらかった. また,手書きはPC入力と違ってBackSpaceやコピペが使えず,かつ,解答用紙はマス目のついたタイプのものなので,文章の構成ミスや誤字脱字に後から気づくと修正が事実上不可能になってしまうのもいただけない.
加えて,時間は120分と,字数を考慮すると非常に短く*2,時間配分もキッチリやらないと到底書き切ることができない.
結果,1問目は途中で解くのを諦め,おとなしく上述の参考書やWeb記事にしたがうことにした.
どうやら,この試験にはある種の必勝法があるらしく,合格体験記を見ると,大方の人がそれを実践していた.
0.設問アについては,毎年ほぼ変わらず「関わった業務とシステムについての概要」を問われるので,表現も含めて暗記しておく(ついでにある程度字数調整できるようにしておく).
1.試験開始後の30~35分程度で,その後の設問で書きたいことを,(字数制限を考慮した上で)箇条書きにしてまとめる.ここで,論旨展開(設問アで設問イへの伏線を張っておく,設問ウで書きたいことは設問イでは書かない,など)についても考慮しておく.
2.残りの時間でひたすら書く.ここで,箇条書きの部分はそのままそれをタイトルとして書き,その後に詳細を書いていくスタイルで進める(ここで筆が止まる場合は,1での論旨のまとめ方が不十分ということなので反省する).
といっても,やはり最初から手書きは厳しいので,まずはPCのテキストエディタに要点をまとめることとした.
現在はWeb企業で業務APIプラットフォームの内製開発,運用をしているが,現状運用している業務とシステムについて,その概要を書くというのは,自分にとって意外と新鮮な体験だった. ふわっとした理解だったものも,論理的な文章にしようと思うと,間を埋める努力をしなければならず,その度に運用ドキュメントを当たるなどした. これは非常にいい経験になったと思う.
ある程度まとまってきた段階で,同じ問題を時間を測って解いてみて,「この方法で行けそう」と確信した.
字数が数えられるタイプの紙が家になかったので,罫線の上にドットがついているタイプ*3のレポート用紙を買った. ホントは原稿用紙みたいなマス目になってるやつが欲しかったけど,これはこれで結構便利だった↓
コクヨ キャンパス レポートパッド ドット入り罫線 A4 B罫 50枚 レ-110BT
- 出版社/メーカー: コクヨ(KOKUYO)
- メディア: オフィス用品
- この商品を含むブログを見る
9月中旬〜下旬
少し仕事が忙しくなってきたが,ペースを落としつつ午後2の対策を続けた.
難しいのは,30分程度で十分な字数を確保できる内容を考えるところと,箇条書きの部分をちゃんとスジの通った文章にするところ.
前者については,結局はプロジェクトを経験した数(≒引き出しの数)による部分が大きく,特に苦しんだが,それでも内容のでっち上げはできるだけ避けたかったので,関わったプロジェクトの内容を逐一思い出して書くようにした. それでもダメな部分については,実際には運用しかしていないシステムを開発した体で書くようにするなど,できるだけ具体性を損なわないようにした*4.
後者については,ある程度問題演習をすることで慣れてきたと思う.
また,問題で問われていることを勘違いして2時間をムダにすることもあったので,問題文だけでなく,リード文もよく読むように心がけた. 特に,リード文における例示については,注意を払って読むようにした*5.
加えて,問題を解いた後に,参考書の合格論文をざっと読んでみて,解答の方向性にズレがないかを常に確かめるようにした.
10月上旬〜中旬
このあたりから少しだけ午前対策を始めた. といっても,2年分過去問をやって,イケそうなのですぐにやめた.
基本的には午後試験の対策をしていた. 結局試験前までに解いたのは,午後1が3年分(6問),午後2が5年分(5問). これは今までの情処の試験対策の中では最も少ない.
当日
実際に解いた問題↓
IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2017、平成29年)
午前1
免除.
午前2
いつもの起床ゲー+暗記ゲー. 受けた記憶すら曖昧.
午後1
「ああマイナンバー出たかー.これ問題難しくしたらいろんなとこから怒られるんだろうなー」と思って問1,雰囲気で問3を選択.
問1はデータの流れが追えれば比較的簡単だったが,問3の人事関連の業務フローを理解するのは少し難しかった. パッケージソフトウェアのFit & Gap分析の問題はちょいちょい出るらしいので,来年以降受けるなら調べておいてもいいかもしれない.
午後2
「非機能要件」の定義に少し自信がなくなって問2を取ろうかと思ったが,問2の方がふわっとしてて出題意図を踏み外しそうなので問1を選択.
自分が問題用紙にメモした内容(をちょっとキレイにして出しちゃうと身バレしそうなところを改変したもの)を晒しておく.
設問ア: アー1:要件定義に関わった対象業務の概要と情報システムの概要 * 自身はWeb企業のシステムアーキテクト * XXXサービスに従事 * XXXサービスとはうんぬん(を書く) アー2:情報システムの概要 * 自身が担当したのはYYYバッチシステム * YYYバッチシステムは,XXXサービスを運用するためのYYYシステムの一部 * 自社他部署及び他社がクライアント * クライアントから連携されるデータ(1000万レコード/日程度)をもとに,システムのDBを更新 * コスト面から,運用できるサーバ数には限りあり 設問イ: イー1:検討した非機能要件 * 効率性と運用性のトレードオフについて検討 イー2:検討した際の視点とプロセス (1)業務観点での検討における視点とそのプロセス * 利用部署へのヒアリングを行う * 業務要件:データの更新は更新データの連携日の翌日午前中まで(できればもっと早く)に行いたい.データ量は1000万レコード+バッファ (2)情報システム観点での検討における視点とそのプロセス * 現状のサーバを調査する * 簡単なストレステストを行う * バッチプログラムはシングルスレッドを想定(簡単な実装であり,運用性が高いから) イー3:検討した結果 * バッファ込み3000万レコードでストレステストしてみた -> 9hかかる! * 業務要件を考えると時間がかかりすぎ * バッチのマルチスレッド化を検討 設問ウ: * 意思決定者=YYYシステムの開発責任者 * 現状のサーバ構成は変えられないことを意思決定者に確認 * シングルスレッド版,マルチスレッド版のそれぞれについて,バッチのプロトタイプを作り,3000万レコードを読み込ませた時の速度を見てもらう * マルチスレッド化により運用性が下がることを示す
基本的に,上記のメモベースで箇条書きを行い,それぞれに内容を補足する形で実際の論文を書いた.
少しでも大量データを触る機会のあるエンジニアなら,最初はシンプルなコードでとりあえずプログラムを書いてみて,負荷試験でダメなら仕方なく手を入れる*6という開発経験をされた方は多いのではないだろうか. わりと自身の経験に基づいたものになったかなとは感じる.
設問イまではわりとうまく書けたが,設問ウでネタ切れを起こしてしまい,字数を必死に稼いで600字超ギリギリまで持っていった. やはり,文章構成を考える段階で字数制限より少し多めにネタを考えておいた方がいいと思う.
結果
合格でした.
感想
全体的に暗記する項目が少なかったので,比較的コンパクトな勉強で合格点まで持っていくことができた. どちらかと言うと,特定の分野について勉強したことを問うというよりは,地頭の良さと日頃の文章力を見る試験という印象.
個人的には,ただただシステムの設計について記述するだけでなく,数多くいるステークホルダへそれをどのように説明するかという観点が問題に組み込まれているのが面白いと思った. 実際に上位設計者としてやっていく以上,ただシステムを作ればいいのではなく,システムの対象領域となる業務を理解し,かつ,作ったものの仕様や設計意図を(相手の背景知識に合わせて)説明できるようになることが重要なのだと感じた*7.
でもまあやっぱり,「こんな妄想たっぷりの論述で本当にシステムアーキテクトととしての能力がわかるんだろうか」という疑問は最後まで解決されなかったのと,イマドキの試験で数千字の文章を手書きで書かせるのはどうなのという感じはした.
たまには資格試験以外の技術記事も書きたいのでちょっとがんばります…
*1:こちらの記事,試験対策記事としても非常にお世話になった.感謝.
*2:2,500字って大学の期末レポートより少し短いぐらいだし.
*3:伝われ.
*4:たぶんシステムへの理解を深めることも試験の重要な目的だと思うので許して.
*5:基本的に例示に沿ってそのまま書けば得点的には問題ない気もするが,あまりにコピペをしてしまうとそれはそれでなんかダメな気がする.試験講評でも毎年怒られてるし.
*6:だいたい後からいじった部分がぐちゃぐちゃになって保守できない原因になってくるのだが.
*7:流暢な文章にできることと,同じ内容を口頭で伝えられることは(特にコミュ障にとっては)一致しないが,相手に説明すべき観点が理解できるようになるだけでも,まあ一歩前進という感じはする.