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

問1 では，安否確認システムの導入を例にとり，ASP サービスを導入するに当たって，利用者の要求を満た すために必要な業務の変更，及びシステム運用の変更について出題した。全体として正答率は高かった。 設問1 では，安否確認自主登録機能について，“どのような場合に，どのように利用するか”を問う問題で あったが，“どのような場合に”だけを解答した受験者が多かった。 設問2(1)では，社員コードの変換方式について，三つの方式の比較で，他の二つの方式に比べてどう優位か を問うたが，単に“覚えやすいから”といった，客観的な根拠に乏しい解答が見受けられた。一方，(2)は正 答率が高かった。多くの受験者が，社内システムの共通パスワードが安否確認システムに反映されるタイミン グを理解し，正解を導くことができたと思われる。 設問3(3)では，個別確認の対象人数を少なくするための情報を問うた。個別確認は，地震区域にいないこと が明らかである社員以外について行われるので，地震区域にいないことを示す情報が必要となる。社員の勤務 場所や担当営業区域といった解答が散見されたが，これらの情報だけでは判断できないことに注意して解答す ることが求められる。 システムアーキテクトとして，システムを正確に作ることだけではなく，利用者がシステムを使って業務を どのように行うかまで，常に意識することを心掛けてほしい。

問2 では，銀行のATM サービスの機能追加を例にとり，業務要件に基づいたシステム設計について出題し た。 設問1 では，(1)の正答率が高かった。(2)は，代行処理した取引の反映が処理時間内に終了しなかった場合 にE 銀行元帳に不整合が生じる理由について記述する問題であったが，単に“処理時間内に終了しないから” との解答が散見された。 設問2(1)では，属性名の正答率は高かったが，理由については，関係のない時間帯を記述しているなど，誤 った解答が多かった。受験者が各処理と時間帯の整理を十分にできていなかったものと思われる。設問2(2)の 正答率は低かった。バッチ処理と即時更新のリアルタイム処理の更新タイミングは前提条件であるにもかかわ らず，“バッチ処理の終了後にリアルタイム処理を行う”など，本文中の前提条件を考慮せず更新タイミング を変更してしまう解答が多く見られた。 設問3 は，商品企画部からの追加要望への対応内容について，その方法と理由を記述する問題であった。 (2)は正答率が低かった。E 銀行システムの変更内容について問うているが，D 社システムの対応も必要な方法 を記述している解答が多く，D 社システムとE 銀行システムの機能配置の理解が不十分だったと思われる。 システムアーキテクトとして，業務に基づく前提条件，及びシステムの制約条件を理解し，関連システムと の機能配置，及びシステム間連携を十分に意識した要件定義，設計が行えるよう心掛けてほしい。

問3 では，食品製造業を例にとり，基幹システムの改善要件を踏まえた，ファイル設計，処理設計などにつ いて出題した。全体として正答率は高く，題意はよく理解されていた。 設問1 は(1)，(2)とも正答率が低かった。(1)は，生産計画業務の効率化，省力化，精度向上といった抽象 的な表現が散見された。(2)は，与信限度額から更に受注残高を減算すべきことが理解できていないと思われ る誤った解答が多く見られた。 設問2 では，(1)の正答率が高く，(2)は低かった。(2)では，原材料倉庫に加え，製造現場も原材料在庫の 管理場所になることから，両者を総称した解答を求めていたが，単に“製造現場コード”と解答したものが多 かった。 設問3 は，a，b とも正答率が高かった。a では“≦”と記述すべきところを，“＜”と記述した解答が散見 された。 設問4 は，c，d とも正答率が高かった。ロット追跡の手順については，よく理解されているようだった。 システムアーキテクトとして，業務要件を十分に理解した上で，適切な処理設計，ファイル設計が行えるよ う心掛けてほしい。

問4 では，電動車いすの自動運転システムの開発を例にとり，機能及び要件の定義，機能仕様の検討及び策 定について出題した。全体として正答率は高かった。 設問2(2)は，本文中に記述した二つを解答に期待したが，その一つである“他の利用要求”について記述し ていない解答が散見された。題意を十分理解してもらいたい。 設問3(2)は，“車体の幅をカバーするためにタグリーダを3 台設置した”との解答が散見された。本文にあ る“ずれを修正しながら走行”するために，どのような方法が求められているかが問われていることを理解し てほしい。 設問4(2)は，“バッテリ残量”などの解答が散見された。ある項目を見積りツールに入力すれば急速充電器 の台数が求まることから，設問の要件に不足している事項を解答すればよいはずである。 システムアーキテクトとして，仕様策定に当たっては，開発対象システムに求められる機能及び要件を正し く把握し，確実に無駄なく策定できるよう心掛けてほしい。

全問に共通して，具体的で，経験に基づいていることをうかがわせる論述が多かった。また，問題文の引用 で文字数を費やし，内容が薄くなってしまっている論述については昨年度から減少した。一方で，問題文に例 示した項目を抜き出し，一般論と組み合わせて論述を構成する傾向については，昨年度と同様に多く見受けら れた。問題文に記載した項目は事例として挙げたものであり，受験者は設問で求められていることを把握した 上で，問題文中の事例にとらわれ過ぎることなく，実際の経験に基づいた具体的な論述をするよう，心掛けて ほしい。

問1（要求を実現する上での問題を解消するための業務部門への提案について）は，多くの解答が，経験を 踏まえ，設問に沿って具体的に論述をしていた。本問では，要件定義における問題の解消をシステムアーキテ クトとして論述することを求めた。しかし，要件定義ではなく，設計段階やテストにおける問題に関する論述 や，解消策が体制面や期間調整などプロジェクトマネジメントの側面からの論述なども散見された。

問2（設計内容の説明責任について）では，設計した内容を，関係者に対して，どのような観点から説明し たのかについて，自らの経験に沿って論述することを期待した。この意図を理解して選択した受験者は，適切 な論述をしていた。ただ，“説明した内容”と“説明の観点”の違いを理解できずに選択したと思われる受験 者も多く，この場合は設計項目を羅列した論述や設計過程を述べただけの論述になっていた。この意味で，全 体では題意に沿った論述と，そうでない論述に二極化しており，後者が多かった。 システム開発においては，関係者が多くなることは必至である。このため，関係者に期待する役割を果たして もらえるよう，観点を明確にして設計内容を説明する能力がシステムアーキテクトには必要とされる。この能 力の重要性を理解し，実践してほしい。

問3（組込みシステムの開発における信頼性設計について）では，おおむね組込みシステムの開発経験を具 体的に論述できていた。しかし，その内容は，信頼性設計に対する十分な知見をうかがわせる論述がある一 方，明らかな知識不足と思われるものもあり，二極化していた。また，各設問において，複数の項目について 論述を求めていたにもかかわらず，その一部の項目に対してしか論述していないものが散見された。評価につ いての考察については，多くは具体的，定量的に論述されていた。それに加え，複数の視点から論述されてい るものなどもあり，高く評価できるものが多かった。