システムアーキテクト試験 平成24年度秋期

問1 では，食品商社を例にとり，経営層や業務部門の要請を踏まえた，会計システムの再構築について出題 した。全体として，題意はよく理解されていたようであった。 設問1 では，(1)の正答率が高かった。(2)は，渡された情報で行うべき処理について，売上と売掛金への仕 訳計上処理が必要であることに対し，どちらか一方のみの解答が散見された。仕訳は分からなくとも，本問で の出荷という行為が，会計上は売上と売掛金という二面性をもつことを理解してほしい。 設問2 では，資金管理について問うたが，(1)は入金予定を出金予定と取り違えた解答が散見された。(2)， (3)は正答率が高かった。 設問3 は，正答率が高かった。連結子会社の決算情報を合算するとき，各連結子会社の勘定科目がA 社と統 一されていないということが読み取れれば解答できる設問であった。 設問4 は，正答率が低かった。内部統制実施基準の，IT に係る業務処理統制について，入力情報の完全性， 正確性，正当性を確保することの中で，入力情報の完全性の確保について問うたが，取引の入力と会計システ ムへの連携において漏れ及び重複がないことが入力情報の完全性である，ということを読み取ってほしかっ た。 システムアーキテクトとして，経営層や業務部門の要請や課題を踏まえ，関連したシステムとの連携も十分 意識した要件定義，設計が行えるよう心掛けてほしい。

問2 では，Web による写真プリント注文システムを例にとり，ソフトウェアやシステムサービスの汎用化の 検討について出題した。全体として正答率は高かった。 設問2 では，開発方針として汎用化の基本的な留意点を問うたが，“各ショップの創意工夫を出すため”な ど，開発方針とは異なる視点の解答があった。汎用化の観点で問題文から読み取ってほしい。 設問3(1)では，メールでの実装について，“メールを素早く受信できるから”との解答が多かったが，業務 上素早く知りたいのは注文であることを意識してほしい。設問3(2)では，追加する機能が必要な理由を問うた が，“写真データ削除のタイミングを知るため”など，問題文に記載していないシステム上の都合を想像して 解答したと思われる誤った解答が多かった。 システムアーキテクトには，多数の企業への展開を念頭において，ソフトウェアや，システムサービスの汎 用化を検討できる能力が期待されている。要望や前提条件，性能や処理タイミングなどを総合的に考慮して的 確に設計できるように心掛けてほしい。

問3 では，セミナ管理システムを例にとり，利用者の要件に基づいたシステムの設計について出題した。 設問1(1)，(2)は，E-R 図を用いてエンティティタイプの設計に関して出題したが，正答率は低かった。特 に，リレーションシップについては，システムの要件をしっかり理解しなければ正答を導くことができないこ とを十分に理解してほしい。 設問2 は，システム要件に書かれた情報を，属性名を用いて記述する問題であった。システム要件に書かれ た情報は五つあり，設問の記述の中に，その中の二つが書かれているので，残りの三つの情報を属性名を用い てどう表すかを考えれば解答できる設問であったが，正答率は低かった。属性名だけ記述してある解答も多 く，設問の理解が十分でなかったものと思われる。 設問3(1)は，利用者の追加要件から出た項目を，どのエンティティタイプに追加すべきかを問う問題であっ た。その情報は，どの時点で何に対して付与されるものかを理解すれば容易に解けたはずだが，属性名を見て 思い込みで解答したと思われる誤った解答が多く見られた。 システムアーキテクトとして，利用者の要望をシステム要件としてまとめ，それを正確に設計していくこと ができるよう心掛けてほしい。

問4 では，電気自動車専用カーシェアリング運営システムの開発を例にとり，機能及び要件の定義や，機能 仕様の検討及び策定について出題した。全体として，正答率は高かった。 設問2(2)は，“充電所要時間”との解答が散見されたが，充電スタンドからサーバへ送信されるデータとし ては不適切である。問題文を十分理解してもらいたい。 設問4(1)は，“異常発生をトリガにして記録開始する”との解答が散見された。問題文に異常発生時の“前 後”の記録を残す必要があると記述しているので，要件を正確に理解し，実現できる方法を求められているこ とを理解してほしい。 システムアーキテクトとして，開発対象システムの機能及び要件を正しく把握し，機能仕様にまとめる力を 身に付けてほしい。

全問に共通して，具体的で，経験に基づいて記述されていることをうかがわせる論述が多かった。一方で， 問題文の引用で文字数を費やし，結果的に期待した内容が書かれていない論述や，問題文に例示した項目と一 般論の組合せだけで構成された具体性に欠ける論述も見られた。問題文に記載した項目は事例として挙げたも のであり，転記を求めているものではないことを理解してほしい。 また，設問で問うている内容に対応しない論述も散見された。例えば，“対象業務の概要及び特徴”を問う ているにもかかわらず，“プロジェクトの概要”や“システムの概要”を述べているような論述が挙げられ る。このような論述では，受験者の能力や経験を正しく評価できない場合があるので，実際の経験に基づき設 問に沿って具体的に論述してほしい。

問1（業務の変化を見込んだソフトウェア構造の設計について）では，“業務変化によってシステムが受ける 影響”，“ソフトウェア構造の面からの設計”，“業務変化に対応できる理由”，の三つについて，関連付けて論 述することを期待したが，そのような論述は少なかった。 多くの受験者が，“想定した業務の変化”に対応するソフトウェア構造ではなく，設定値をテーブル化する など“汎用化のためのプログラミング方法”や販売管理システムにおいて商品の種類が増加することなど， “当然考慮すべき業務要件やデータ量の変化”に対応するソフトウェア構造について論述していた。また， “どのようなソフトウェア構造を設計したか”と問うているにもかかわらず，“柔軟性を持った構造にした” などの論述にとどまり，具体的なソフトウェア構造に触れていない論述も見られた。 業務の変化が激しくなっている状況において，業務を踏まえてソフトウェア構造を設計する能力は，システ ムアーキテクトとして特に必要とされるものである。その重要性を理解し，実践してほしい。

問2（障害時にもサービスを継続させる業務ソフトウェアの設計について）では，サービス継続の方針に基 づいて，サービスを継続する処理と，継続運用を可能にするための業務ソフトウェア設計について論述するこ とを期待したが，そのような論述は少なかった。多くの受験者が，問題文で除外しているにもかかわらず，機 器やデータベースの二重化など業務ソフトウェア面以外での対策について論述していた。また，“継続運用に 備えた処理や障害復旧処理においてどのような工夫をしたか”と問うているにもかかわらず，“継続運用を可 能にするための設計”に関する工夫を記載している論述も散見された。 システムは，常に正常に稼働しているとは限らない。システムアーキテクトとして，システム障害時の業務 も想定した設計を心掛けてほしい。

問3（組込みシステムの開発プロセスモデルについて）では，具体的な経験をうかがわせる論述が多かっ た。論述されたプロセスモデルについては，プロトタイピングモデルでの開発が多く，ユーザインタフェース を重視する具体的な開発状況を読み取れた。また，システム開発時の品質管理を重視する立場から，ウォータ フォールモデルを採用した論述も散見された。一部の論述では対象が組込みシステムではないものがあり，こ れは出題の趣旨から外れると判断した。