システムアーキテクト資格|2022年4月挑戦ログ 4月17日

高度IT・基礎知識

本日は試験当日のため、最終振り返りとして整理する。

本試験の注意点

全般

  • 受験票に写真、会場の行き方と時間確認
  • 必要なもの用意

午前2

  • 約5割の過去問の再掲は確実におさえること
  • しかし、再掲でも選択肢の順が入れ替わったり、内容が少し変わる場合がある
  • よって過去問の再掲こそ焦らず、じっくり暗記したキーワードに沿って回答
  • 残り5割の新規問題も、少し考えれば選択肢を絞れるのであきらめないこと

午後1

  • クリアな頭で。とにかく頭をよい状態にもってくること。前日良く寝て、昼休みは外の空気も吸って軽く運動し、昼寝も15分。コーヒーや水は控える(トイレが近くなる)。焦らずリラックスし、儀式的に「ここまでやったから落ち着けば6割取れる」と確信を持つ
  • 3問の中から2問選ぶときは、慎重・迅速に得意項目を。1問40分。アテ付け25分
  • タイトル・見出し・小見出しに線を引き、その下1~2行に目を通し、現在・要望・新規の「構造」把握
  • 「構造」意識し、「ダメ・のみ・だけ・しかし」に×つけ、「また、なお」を囲み、2度目「ざっと」読む
  • 設問に丁寧に線を引き、システム表現に焦らず、ユーザーニーズに着目し、表や図も注意し、直感的にアテをつける
  • ④アテをつけた情報を簡潔に、本文中の言葉を使い表現
  • この流れを体感で掴み、慣れる
  • 直感でアテがつかないものは深追いしない全体で6割取れればよいし、後から見えることもある
  • ただし何らか答えは書く。部分点がもらえるかもしれないため
  • 繰り返しだが設問に注意。絞り込みのヒントであり、聞かれたことに答えるため

午後2

  • 2問の中から1問選ぶときは、できるだけ得意分野
  • 最低文字数ラインはかならず超える
  • 知らない人に説明することをふまえ、シンプルでわかりやすい構成にする

論文準備

午後2 攻略のポイント

  1. 充足性・妥当性・具体性。本文・設問のフラグを全て回収し、システムアーキテクトの役割に沿って、具体的に書く
  2. 充足性について。設問で聞かれたことを大見出しにして書き始め、本文の要求(お題)に合った内容にして、本文の事例(例えば…)も全て小見出し的に回収して書く
  3. 妥当性について。システムアーキテクトの役割を意識して書く。すなわち大まかな方針(目的・制約・方法)の中で、ユーザーニーズを整理し、解決のための事務・システムをデザインすること。戦略・マネジメント・技術寄りにならないように注意
  4. 具体性について。「(お題)について、私は(結論)した。なぜなら(理由)だからだ。具体的には(事例)だ。(結論)は大事だ」のように。いわゆるPREP法でわかりやすくアピール。数値や具体名称も入れると効果的

午後2 論文ネタと注意点(自己紹介部分)

  • 名称:銀行窓口における生命保険のペーパーレス申込システム ※どの業界のどんな仕事のためのシステムか簡潔に
  • 概要:私は大手生命保険会社のA社に所属するシステムアーキテクト。論述の対象とするのはA社が委託先の大手銀行B行の窓口で保険を販売してもらうためのシステム(以下、申込システムと言う)。申込システムは従来の書面による保険申込内容をタブレット上で入力するWEBシステム。 ※自己紹介、どの業界のどんな仕事のシステムか、構成を簡潔に
  • 制約:競争の激化に対応するため。2019年8月までに申込システム構築が必要 ※戦略や〆感。簡潔に
  • 業務要件:B行窓口に来訪した顧客が保険申込を希望した場合、B行行員がタブレットを用いて申込システムを起動。「申込情報の入力・顧客の意向確認・行員によるチェック」などの機能を用いる。99.99%の可用性・直感的でわかりやすい操作性・ユーザー操作後5秒以内のレスポンスを実現する性能。 ※いわゆる業務フロー、機能要件、非機能要件。お題によってはこのあたりを丁寧目に書く。
  • システム構成:B行タブレットからHTTPS通信してA社WEBサーバに接続して使用。A社内ではWEBサーバ、アプリケーションサーバ、DBサーバを用意。それぞれのOSとミドルウェアは、アプリはLINUXとTOMCAT。DBはLINUXとOracle。
  • 重要ポイント1つ目。文系には取っつきにくいが本資格の論述ではシステム構成の準備が必須。システムの設計士なので。書籍「おうちで学べるデータベースのきほん」あたりでイメージを掴み、自分の経験したプロジェクトの事例を調べておくとよい。
  • 重要ポイント2つ目。これ以降、与えられたお題に沿ってかなり具体的な論述に入る。そのとき対象のシステム範囲が広すぎると伝わらないので、語る範囲を絞るのがおすすめ。私の事例なら「お客様が申込情報を入力する機能(以下、申込機能)は機能全体の中でも半分以上を占める開発規模であるため重要なものである。以降はこの機能に絞って論述する」のように。
  • ここは大事なポイントであるが、一方時間をかけすぎると最後まで書けなくなる(設問ア~ウまで規定文字ライン超えないと問答無用で不合格)ので、十分に下準備し、本文と設問にあわせ速やかに書いてしまう事。

午後2 論文ネタと注意点(経験を語る部分)

  • お題と解答例:「ビジネス環境変化に伴う、業務内容の変化に対応するための、本番稼働後の改修を見越した拡張性について」⇒「保険市場競争の激化に伴い、取り扱い保険商品の変更による業務内容の変化に対応するため…」と続ける。 ※ポイントは徹底的にお題に合わせて、そのことを分かりやすくアピールすること。この例なら「業務内容の変化」のレベルまで合わせる。半分フィクションでもOK。最初のここがずれてると、以降何を書いても読んでもらえない懸念がある。
  • 事例と解答例:「システム設計段階でオブジェクト指向設計技法を活用…例えば…キーワードをいくつか」⇒「概念モデリングの技法を活用。ユーザーにもわかりやすく全体を俯瞰できるため。具体的にはユースケース図、概念機能モデル図」「コンポーネント化の技法を活用。後からの改修を効率的にするため。具体的には各画面のボタンやヘッダーなど共通要素をまとめてコンポーネントにする」「構造化設計の技法を活用。後からの改修を効率的にするため。具体的にはまず共通の基本構造をオブジェクトとして設計し、これをベースに各画面の独自要素をコーディング」「パラメータ化の技法を活用。後からの改修を効率的にするため。具体的には各商品ごとの背景色や言い回しを、商品ごとパラメータ設定で簡素に切り替え可能とする」 ※ここに挙げたのは事例。人間とコンピュータの溝を埋めるため先人が努力してきた知恵と工夫の結晶について、本質(いかにうまくユーザーと合意し、後からの手入れを楽に作るか)を把握し、自分の経験に沿って下準備しておき、上記ワードが出てきたら具体例として語れるようにしておきたい。全ての事例に対して漏らさず、徹底して合わせて自分の経験を解答し、そのことを分かりやすくアピールすること。
  • ここも勿論大事な部分だが、設問イの最低文字数ラインを越えたらまずウを書くのもおすすめ。ウも最低ライン超えないと合格できない。

午後2 論文ネタと注意点(結果の振り返りを語る部分)

  • 結果として成功したことを、お題のポイントに沿って漏らさず、具体数値も入れてわかりやすくアピール
  • 今回はうまくいったが、次はこうしたい…的なことを入れ、アジャイルや先端技術の活用など常に学び・向上し、貢献していくアピールを入れて〆。

システムとの付き合い方・考察

  • 今日は家族で新築祝い(母と兄弟の共同名義)を兼ね皆元気に集合。自分らしい生き方を模索するうえで、帰る場所・信頼関係があるのは何よりの宝物。これからはリアルだけでなく、バーチャルでの居場所作りもより加速すると想定
  • 4月17日試験終了後、早速メタバースのコミュニティ参加など実践しつつ、皆の役に立つこともモチベーションにインプット・アウトプットの好循環を回したい。

コメント

タイトルとURLをコピーしました