システムアーキテクト試験・午後Ⅱの勉強方法・攻略方法
この記事は、上記リンクの関連記事です。
＜概要＞
午後Ⅱは論文です。
得手、不得手の方がハッキリわかれる問題ではないでしょうか。
採点者がA～Dで評価し、Aランクで合格となります。
正直、採点基準はよくわかりませんが、
文書が題意に沿っており、不自然な流れでなければ、合格に近づくと思います。
試験当日は、ひたすら書くという感じで、
あっという間に制限時間がやってくるイメージです。
システムアーキテクト試験が敬遠される理由として、
この論文の存在が大きいのではないでしょうか。
＜勉強法＞
いきなり論文を書けと言われても、書けないと思います。
論文をスムーズに書くための準備をすることが目的となります。
■イメージトレーニング
参考書に乗っている問題と解答例を読み込みます。
完成形をイメージするためです。
目安として最低5,6問の解答例は読んだ方がよいと思います。
■題材を決める
私はこれまで大小含めて15件程プロジェクトに携わっています。
なお、私は組込みシステムには携わったことがないため、
組込みシステム以外の選択となります。
どんな問題が出題されても、
汎用的に対応できるプロジェクトを選定します。
選定の基準としては以下のとおりです。
①システムの要件定義から携わったプロジェクト
②できるだけ苦労したプロジェクト
③あまり大きすぎず、ステークホルダーが少ないプロジェクト
④スクラッチのシステム開発
①について
人によっては、そんなプロジェクトは経験したことがない方もいると思います。
別に自分自身が、リーダー的な立ち位置で直接経験していなくても良いのです。
人づてで聞いたというものでもOKだと思います。
要は、ストーリーの材料となればよいのです。
出題の傾向としては、要件定義・画面設計のユーザとの調整が必須な工程が最も多く出題される印象です。
次いで、テスト工程…と言った感じでしょうか。
要件定義工程の材料が必須となります。
②について
とにかく材料の幅を広げるイメージです。
平穏なプロジェクトなんてないと思いますが、できるだけいろんなイベントがあったプロジェクトの方が、書きやすいかと思います。
③について
ステークホルダーが多くなると、論文がゴチャゴチャしてしまいます。
材料は多く、でも登場人物は少なく…といった無茶な要望かもです。
④について
私の受験時はパッケージの選定に関する出題ないようでしたが、
スクラッチ開発したシステムをパッケージに置き換えて乗り切りました。
個人的な勝手なイメージですが、
スクラッチ開発→パッケージ利用の置き換えは可能な気がしますが、その逆は難しいかな？と思います。
■システム概要の準備
試験では論文を書く前にシステム概要を記載することになります。
システム概要を書く際に、まごついていては時間切れとなってしまいますので、
選んだ題材について、あらかじめ試験答案のフォーマットに落とし込んでおきます。
■本文の練習
いきなり、紙とペンを用いて練習するのではなく、
イメージトレーニングによって得られた傾向を利用しつつ、選んだ題材について材料となる事柄を簡単にまとめます。
まとめる工程としては、要件定義、外部設計、テストの3つのみです。
その他の工程が出題された場合は、終了です笑
近年ではインフラ関係の問題が出ることもあるようです。
私の場合は、インフラ用の問題は完全に捨てることとし、準備をしませんでした。
あとは、実際に時間どおりに記述できるよう、実戦形式で紙とペンを用いて練習します。
PCのワード機能で練習する方もいると思いますが、
最低、2回は実際に紙とペンを用いて練習したほうが良いと思います。
実践形式での練習については、後述する＜攻略法＞を意識します。
＜攻略法＞
私の場合、ブドウ糖が多く含まれるラムネを用意します。
これを数粒食べてから試験に臨みます。
設問は全部で3つです。
時間配分としては、システム概要～設問アで35分、設問イで50分、設問ウで35分で計120分をイメージします。
私の場合の文字数の目安としては
設問ア：750文字
設問イ：1,200文字
設問ウ：750文字
としました。
■文書設計
まずは、選択した問題文を読み、システム概要を書いたのちに、
いきなり設問アに取り掛かるのではなく、全体の文書設計を行います。
設問ア～ウで記載予定の章立てと、
本文の内容を箇条書きで簡単に列挙します。
その際、問題文をよく読み、題意に沿った章立てとなっていることを確認します。
文書は、川が流れるようにスムーズな筋道が立っていれば、
多少、表現が汚くても見栄えがよくなるものと信じています。
最初に全体を見渡し、不自然な流れとならないことが重要と考えます。
文書設計は5分程度を目安にします。
続いて、各設問ごとに攻略法を紹介します。
■設問ア
設問アには必ず、システムの概要を記載することになります。
800字中400文字を概要に当てます。
システムの概要は、PC等で書き出し、およそ400字になるように調整します。
そして、内容を覚えます。
残り400字については、
目的、特徴、業務上の背景を問われることが多い傾向です。
過去問の解答を参考に、上記の3パターンについては、すぐにイメージできるようにします。
また、テクニックとして問題文に記載されている事例を無理やり使うこともできます。
設問アは、しっかり準備すれば、まったく問題ありません。
むしろ、ここでまごついてしまうと合格が絶望的となります。
■設問イ
ここは完全に運頼みとなります。
自分がイメージしやすい題材であることをひたすら願うのみです。
かつ、この設問が一番の山場だと思います。
いくつかテクニックを挙げます。
①丸パクリ
問題文の冒頭に、システムアーキテクトとして期待される役割が記載されていることが多いかと思います。
論文の冒頭に、問題文に記載されている内容を丸パクリすることで、3行程度文字数を稼ぐことができます。
②事実と背景のみを書く
設問ウでは、工夫をした点や、今後の課題を書くことが多いですので、
設問イにおいては、題意に沿って、実行した内容とその背景のみを書きます。
その際、なぜその"アクション"をしたのかといったような「なぜなら・・・」という形で、話を膨らますことを心がけます。
ピックアップする"アクション"については、最低2種類、理想的には3種類を事例として挙げます。
字数を稼ぐことが目的ですが、設問ウへの布石の意味合いもあります。
設問ウでは今後の課題について問われることが多いですので、
3種類のアクションのうち、1種類は改善の余地があるアクションを選ぶとよいでしょう。
■設問ウ
設問イの流れから、工夫した点や課題についてを書くことが多いです。
都合よく、実際のプロジェクトで工夫したことや課題が明確となっていればよいですが、そんなことは、なかなかないと思いますので、創作するつもりで臨んだ方がいいかもしれません。
どうしても思いつかない場合は、パターンを使います。
工夫した点であれば
要件定義：会議の出席者が多く意見が発散する→代表者のみに出席してもらい、コンセンサスを取った
画面設計：後からダメ出しを食らうリスク→モックアップを作成し、合意を得た
などといったように、ある程度パターン化が可能と考えています。
課題へのアプローチの方法についても同様に、「勉強会を開く」「優先度を決めて取り掛かる」といった一般的な方法で逃げることが可能と考えます。
