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

問1 では，仕入れ納品システムの変更を例にとり，業務フロー，ファイルレイアウトの変更などについて出 題した。 設問1 は，(1)，(2)の正答率が低く，(3)は正答率が高かった。(2)では，不定貫商品の処理が定貫商品の処理 と異なるので，これを判断する区分が必要になることを問うたが，不定貫商品の処理に必要な属性を想定し て，“内容量”といった誤った解答をしたものが散見された。 設問2 は，正答率が低かった。ピッキングという作業を，納品伝票の作成，値札発行，値札貼付を含む一連 の作業と誤って解釈した解答，また，“数量”と“内容量”を混同した解答が目立った。(2)は不定貫商品に係 るピッキング方法の変更を問うたもので，数量だけでなく，個々のパックの納品先を意識してピッキングを行 う必要があることに気付いてほしかった。 設問3 は，(1)の正答率が低く，(2)は高かった。(1)では，定貫商品は実納品原価，実納品売価を商品マスタ の単価と実納品数量から計算することができるが，不定貫商品は個包装ごとに原価，売価が異なるので，定貫 商品と同じ方法では算出できないことに気付けば正解が導けたはずである。 システムアーキテクトとして，業務要件の変更内容を十分に理解した上で，適切な処理の変更，ファイルの 変更などが行えるように心掛けてほしい。

問2 では，問合せ管理システムの導入を例にとり，システム構成の設計や権限の定義について出題した。 設問1(3)では，新システムの導入と基幹業務システムの再構築の時期が重複することによる影響を問うた が，基幹業務システムの再構築のことだけが記述されている解答が散見された。 設問2 では，D 社の要望に基づく登録のタイミングを問うたが，対応策を相談するタイミングやD 社品質保 証部門に報告するタイミングといった誤った解答が散見された。 設問3(1)は，全体として正答率が高かったが，e は誤った解答が多く見られた。表2 に表記されている，利 用者の所属がD 社品質保証部門又は製品部門の場合の“担当者”の情報に対する権限と同じものを誤って選択 しており，問題文をよく読めば防ぐことができた誤りだった。 設問3(2)では，販売会社及びD 社の両者の要望を踏まえた解答を期待したが，いずれか一方の要望しか記述 されていない解答が多かった。 システムアーキテクトとして，複数のステークホルダの要望を十分に理解した上で，整合性の取れた適切な 情報システムの設計が行えるように心掛けてほしい。

問3 では，商品の出荷後の売上から回収までの業務を例にとり，業務の改善や変更の要件について出題し た。 設問1 は，(1)，(2)ともに正答率は高かった。(1)は，出荷基準と検収基準での売上計上のタイミングが理解 できていれば解答できたはずである。(2)では，勘定科目を二つ解答すべきところを一つだけ解答しているもの が散見された。 設問2(2)は，正答率が低かった。検収基準で出荷された商品の返品の場合，検収前はまだ売上が計上されて いないので，売上修正の対象にはならない。また検収後の商品は，返品は発生しないか，発生したとしても自 社責任の返品とはならず，返品受付処理の対象にはならない。このことを理解してほしかった。 設問4 は，正答率が高かった。誤った解答としては，“顧客の支払条件を含めて”と問うているにもかかわ らず，支払条件を記述していないものが見られた。 システムアーキテクトとして，業務要件の内容を十分に理解した上で，入出力設計，処理設計，システム間 のデータ連携の設計などが行えるように心掛けてほしい。

問4 では，生活支援ロボットシステムを例にとり，システムアーキテクチャの決定，機能仕様の策定につい て出題した。全体として正答率は高かった。 設問2(2)では，データ照合をサーバで行う理由を問うたが，正答率が低かった。システムの要件及び構成を 十分把握した上で解答してもらいたかった。 設問2(3)では，受け取った配達物が在庫管理対象品の場合に，サーバがロボットに指示する動作を問うた。 “在庫管理”との誤った解答が散見されたが，ロボットは対象品をトレイに移し，入庫数をカウントすること を問題文から読み取ってほしかった。 設問4 では，配達物受取機能実施中に，遠隔操縦機能を受け付けないようにした理由を問うた。理由ではな く，表面的な事象を述べた解答が散見されたが，そのような処理を行わない場合，どのような不具合が生じる かを考えた上で解答してほしかった。 システムアーキテクトとして，システム要件をよく理解して，機能仕様を策定するように心掛けてほしい。

全問に共通して，自らの体験に基づき設問に素直に答えている論述が多かった。一方で，問題文に記載して あるプロセスや観点などを抜き出し，一般論と組み合わせただけの表面的な論述も引き続き見られた。問題文 に記載したプロセスや観点は例示である。自らが実際にシステムアーキテクトとして，検討し取り組んだこと を具体的に論述してほしい。

問1（業務要件の優先順位付けについて）では，どのような評価のプロセスと評価項目で業務要件の優先度 を評価したか，また情報システム開発の目的に沿った重み付けをしたか，を具体的に論述することを期待し た。評価のプロセスと評価項目については，多くの受験者が論述できていた。一方で，情報システムの開発の 目的と評価項目・重み付けの間の関連が分からない論述や，業務要件ではなくシステム要件を評価している論 述も多かった。システムアーキテクトには，情報システムの開発目的を理解した上で，業務要件と情報システ ムの両面から分析することが求められる。情報システムだけでなく，業務要件と情報システムの両面からの分 析能力を高めてほしい。

問2（情報システムの移行方法について）では，対象業務の特性による制約条件を踏まえ，どのような移行 方法を選択したか，移行作業後の業務に支障が出ないようにするためにどのような工夫をしたか，を具体的に 論述することを期待した。多くの受験者が業務特性を明確に論述していた。一方で，業務特性の記述がなくシ ステム上の制約条件を考慮しただけの論述や，対象業務の特性ではなく情報システムの開発プロジェクトの制 約を業務特性としていた論述も見られた。システムアーキテクトには，情報システムが業務でどのように使わ れているのかを正しく理解することが求められる。情報システムの設計，開発に当たっては常に業務を意識し てほしい。

問3（組込みシステムにおけるオープンソースソフトウェアの導入について）では，システムへの外部技術 の導入において，オープンソースソフトウェアのもつ利点と注意点を関連部署と検討し，非採用の決定を含め 自社開発ソフトウェアとの組合せを考慮したシステム設計の実践経験をうかがわせる論文を期待した。全体的 に適切に論述されているものが多かった。一方，システムの一部の構成要素の記述だけであったり，既存のシ ステムの説明となっていたりして，オープンソースソフトウェアの検討への関与がうかがえない論述も散見さ れた。