応用情報技術者 2011年 秋期 午後 問03
EA(Enterprise Architecture)に関する次の記述を読んで、設問1~5に答えよ。
全国の5か所に工場をもつ機械部品の製造業X社は、同種の機械部品を製造する旧Y社と旧Z社が半年前に合併して設立された。
旧Y社と旧Z社では、業務の進め方や使用する帳票が異なっており、合併までの限られた期間内に、これらの統一を行うことが困難であった。情報システムについても、統合できておらず、合併前の情報システムに必要最低限のシステム間連携を行って使用している。これによって、効率よくIT投資ができない、全社横断での情報活用ができない、顧客への即日納期回答ができないなどといったことが問題になっている。
これを解決するために、情報システム部門のD課長は部下のE君に、EAの考え方を用いて、情報システムの全体最適化を検討するよう指示した。
〔EAの策定手順〕
E君は、全体最適化の検討を、次のEAの策定手順で行うことにした。
手順1 EA策定の目的と対象範囲の明確化:CIOと情報システム部長(以下、部長という)にヒアリングを行い、EA策定の目的と対象範囲を明確にする。
手順2 現状(AsIs)モデルの分析:現状の業務と情報システムの分析を行い、現状の業務と情報システムの問題を明確にする。
手順3 理想(ToBe)モデルの策定:業務と情報システムの問題を解決し、全社レベルの業務と情報システムのあるべき姿を策定する。
手順4 次期(Target)モデルの設計:理想(ToBe)モデルと現状(AsIs)モデルを対比させ、現実的な業務改革の方針と次期情報システムの導入目標を決める。
〔EAのアウトプット〕
E君は、手順2~4で、EAの四つの体系ごとに、次のアウトプットを作成することにした。
(1) 業務体系(BA:Business Architecture)
業務内容と業務フローを分析するために、業務機能の構造を階層的に分析して業務と情報システムの対象範囲を明確化するaと、データを処理する組織、場所、順序を明確化する業務流れ図(WFA:Work Flow Architecture)を作成する。
(2) データ体系(DA:Data Architecture)
各部門・工場で扱う情報の内容、情報間の関連性を分析するために、情報間の構造を明確化した情報体系整理図を部門・工場ごとに作成する。また、情報システムの実装を意識し、エンティティ間の関連を示したbを作成する。
(3) 適用処理体系(AA:Application Architecture)
業務処理に用いられている情報システムの形態を分析するために、情報システム間でやり取りされる情報の種類及び方向を図式化したcと、情報システムに実装する機能の構成を明確にした情報システム機能構成図を作成する。
(4) 技術体系(TA:Technology Architecture)
情報システムを構成している技術的構成要素を分析するために、ソフトウェア構成図、ハードウェア構成図、及びdを作成する。
〔D課長のレビュー結果〕
E君は、〔EA の策定手順〕、〔EA のアウトプット〕で検討した結果を、D 課長にレビューしてもらった。D 課長から〔EA のアウトプット〕について、①このようなデータ体系の分析では全社レベルの全体最適を検討することが困難であるとの指摘を受けた。
E君は、D 課長の指摘事項を反映し、X社の EA 策定に向けた作業を開始した。
〔問題についてのヒアリング〕
E君は、手順1として、CIO と部長に X社の情報システムの抱える問題についてヒアリングを行った。
CIO:当社では、合併前の情報システムを利用し続けているので、旧 Y社の営業部門と旧 Z 社の営業部門からの報告がバラバラであり、売れ筋商品や売上の状況を全社横断的に把握し、素早い経営判断をすることが困難になっている。この問題を解決するために、情報システムの統合を行い、経営判断に必要な情報を容易に把握できるようにしたい。
部長:現在は、類似機能をもつ営業システムと工場システムが複数存在しているので、運用の対象となるサーバの台数が多く、運用面やコスト面で大きな負担となっている。②サーバの運用に掛かる社内要員を削減し、コストを削減したい。
〔現状(AsIs)モデルの分析〕
E君は、業務上の問題を引き起こす原因を明確にするために、手順2で、旧Z社の商品を旧Y社の営業部門が販売する場合の現状(AsIs)の業務流れ図(抜粋)を図1のとおり作成した。

E君が作成した図1を分析した結果、旧Z社の商品を旧Y社の営業部門が販売する場合に、③“顧客への即日納期回答ができない”原因が情報システムにあることが分かった。その後、E君はEAのその他のアウトプットも作成し、X社の現状(AsIs)モデルの分析を進めた。
〔理想(ToBe)モデルの策定〕
E君は、手順3で、〔問題についてのヒアリング〕と〔現状(AsIs)モデルの分析〕結果を基に、④情報システムの統合に向けた理想(ToBe)モデルを策定した。
設問1:
本文中のa〜dに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:E-R図
イ:アプリケーション構成図
ウ:外部インタフェース関連図
エ:機能構成図
オ:業務説明書
力:状態遷移図
キ:情報システム関連図
ク:データ定義表
ケ:ネットワーク構成図
コ:プログラム構成図
模範解答
a:エ
b:ア
c:キ
d:ケ
解説
解答の論理構成
-
業務体系(BA)
引用:「業務機能の構造を階層的に分析して業務と情報システムの対象範囲を明確化するa」
‐ “階層的に分析”して“対象範囲を明確化”する図は業務機能をブレークダウンした構造図です。選択肢でこれに該当するのは「エ:機能構成図」。 -
データ体系(DA)
引用:「エンティティ間の関連を示したbを作成する」
‐ エンティティとリレーションを描く代表的な図は E-R 図。選択肢「ア:E-R図」を充てる。 -
適用処理体系(AA)
引用:「情報システム間でやり取りされる情報の種類及び方向を図式化したc」
‐ システム間のインタフェースを鳥瞰する図は情報システム関連図。選択肢「キ:情報システム関連図」を選択。 -
技術体系(TA)
引用:「ソフトウェア構成図、ハードウェア構成図、及びdを作成する」
‐ ソフト/ハードに並ぶインフラ要素として必須なのはネットワーク。従って「ケ:ネットワーク構成図」。
結論:
a=「エ」
b=「ア」
c=「キ」
d=「ケ」
a=「エ」
b=「ア」
c=「キ」
d=「ケ」
誤りやすいポイント
- a で「オ:業務説明書」を選んでしまう
“説明書”は文章主体で階層構造を図示しないため不適切です。 - b で「ク:データ定義表」と混同
データ定義表は属性詳細を表で管理する成果物で、エンティティ間の“関連”を図示しません。 - c を「イ:アプリケーション構成図」と誤解
アプリケーション構成図は機能モジュールの内部構造寄りで、システム間の情報授受を主役にしません。 - d を「コ:プログラム構成図」と誤選択
プログラム構成図はアプリケーション内部の構造であり、ネットワークトポロジを示す目的に合致しません。
FAQ
Q: 「機能構成図」と「アプリケーション構成図」は何が違うのですか?
A: 機能構成図は“業務”機能を階層分解した業務視点の図で、アプリケーション構成図は“システム”機能やプログラムの構造を表す技術視点の図です。
A: 機能構成図は“業務”機能を階層分解した業務視点の図で、アプリケーション構成図は“システム”機能やプログラムの構造を表す技術視点の図です。
Q: E-R図とデータ定義表の関係は?
A: E-R図でエンティティ・リレーションを可視化し、データ定義表で各エンティティや属性の詳細(型・桁数など)をドキュメント化します。相互補完の位置づけです。
A: E-R図でエンティティ・リレーションを可視化し、データ定義表で各エンティティや属性の詳細(型・桁数など)をドキュメント化します。相互補完の位置づけです。
Q: ネットワーク構成図はどのレイヤを描くのが一般的?
A: 物理接続(ルータ、スイッチ、ファイアウォール等)と主要な論理セグメント(VLAN、サブネット)の両方を示し、通信経路や冗長構成を把握できる粒度が推奨されます。
A: 物理接続(ルータ、スイッチ、ファイアウォール等)と主要な論理セグメント(VLAN、サブネット)の両方を示し、通信経路や冗長構成を把握できる粒度が推奨されます。
関連キーワード: Enterprise Architecture, 機能構成図、E-R図、情報システム関連図、ネットワーク構成図
設問2:
本文中の下線①について,D課長が指摘した理由を、30字以内で述べよ。
模範解答
情報体系整理図を部門・工場ごとに作成するから
解説
解答の論理構成
- 【問題文】の〔EAのアウトプット〕「各部門・工場で扱う情報の内容、情報間の関連性を分析するために、情報間の構造を明確化した『情報体系整理図を部門・工場ごとに作成する』」と記載されています。
- しかし、D課長は「①このようなデータ体系の分析では全社レベルの全体最適を検討することが困難である」と指摘しました。
- 部門単位で図を作ると横串での比較・統合ができず、統合EAの目的である“全社横断視点”が欠落します。
- 以上から、指摘理由は「部門・工場ごとに個別作成している点」に集約され、模範解答「情報体系整理図を部門・工場ごとに作成するから」となります。
誤りやすいポイント
- 「b(E-R図)を個別に作成したこと」が原因と誤認し、情報体系整理図との区別を見落とす。
- 「分析が浅い」「図が不足」など抽象的な理由を書き、具体的に“部門・工場ごと”という粒度を示さない。
- 「全社横断で無い」だけを記載し、なぜそうなったのか(部門単位で作成)を落とす。
FAQ
Q: なぜ全社共通の1枚図に統合しなければならないのですか?
A: EAのDAレイヤは「全社レベルで情報の重複や不整合を排除し、共通マスタを策定する」ことが目的だからです。部門別では横断的なデータ利活用の検討ができません。
A: EAのDAレイヤは「全社レベルで情報の重複や不整合を排除し、共通マスタを策定する」ことが目的だからです。部門別では横断的なデータ利活用の検討ができません。
Q: 情報体系整理図とE-R図の役割はどう違いますか?
A: 情報体系整理図は概念レベルで“情報の体系”を示し、E-R図は論理レベルで“エンティティ間の関連”を詳細に示します。前者が粒度の統一、後者が正規化の基礎になります。
A: 情報体系整理図は概念レベルで“情報の体系”を示し、E-R図は論理レベルで“エンティティ間の関連”を詳細に示します。前者が粒度の統一、後者が正規化の基礎になります。
Q: 部門ごとに作った図を後で統合すれば良いのでは?
A: 部門単位で先に固定すると項目定義・粒度・命名が統一されず、後から統合するコストが跳ね上がります。最初から全社共通フレームで設計する方が効率的です。
A: 部門単位で先に固定すると項目定義・粒度・命名が統一されず、後から統合するコストが跳ね上がります。最初から全社共通フレームで設計する方が効率的です。
関連キーワード: EA, DA, 情報体系整理図、全社最適化、データ統合
設問3:
本文中の下線②を実現するために検討すべき施策を、解答群の中から二つ選び、記号で答えよ。
解答群
ア:SSO(Single Sign-On)による全社統合認証基盤の構築
イ:仮想化技術を用いたサーバ統合
ウ:サーバの運用業務のアウトソーシング
エ:情報システム利用者教育の実施
オ:ディザスタリカバリを目的としたバックアップサイトの構築
模範解答
イ、ウ
解説
解答の論理構成
-
問題文では部長が、 「現在は、類似機能をもつ営業システムと工場システムが複数存在しているので、運用の対象となるサーバの台数が多く、運用面やコスト面で大きな負担となっている。②サーバの運用に掛かる社内要員を削減し、コストを削減したい。」
と述べています。
つまり“社内要員”を減らすことと“サーバ台数削減によるコスト低減”の両方が求められています。 -
解答群「イ:仮想化技術を用いたサーバ統合」は、物理サーバを仮想サーバへ集約し、 • 台数を減らす
• ハードウェア保守や OS パッチ適用などの作業件数を減らす
ことで運用負荷を直接的に軽減できます。社内要員削減という目的に合致します。 -
解答群「ウ:サーバの運用業務のアウトソーシング」は、運用作業を外部委託する施策です。
• 社内で行っていた監視・障害対応・バックアップなどを外部企業が担当
• 社内の運用担当者を縮小できる
ため、目的である「②サーバの運用に掛かる社内要員を削減」に適合します。 -
他の選択肢を確認します。
• ア:SSO は利用者認証の利便性向上が目的で、運用要員削減とは主眼が異なります。
• エ:利用者教育はユーザ側の操作ミス防止が目的で、サーバ運用要員には直結しません。
• オ:バックアップサイト構築は災害対策であり、むしろサーバ増加や運用増になる可能性があります。 -
以上より、「イ」と「ウ」を選択することが論理的に妥当です。
誤りやすいポイント
- 「ア:SSO」を“認証基盤の集中=運用削減”と早合点するケース
→ 認証基盤そのものの運用が増える場合もあり、サーバ運用要員削減とは結び付きにくい。 - 「オ:バックアップサイト」を“クラウド利用=外部委託”と誤解するケース
→ 目的はディザスタリカバリであり、通常運用サーバが増える可能性もある。 - “サーバ台数削減”と“要員削減”を混同し、仮想化だけを選択して二つ目を誤るケース。
FAQ
Q: 仮想化で台数が減っても運用が複雑化しないのですか?
A: 物理層は集約されますが、管理ツールで一元運用できるため総工数は大幅に減少するのが一般的です。
A: 物理層は集約されますが、管理ツールで一元運用できるため総工数は大幅に減少するのが一般的です。
Q: アウトソーシングはコストが増えるのでは?
A: 外部委託費が発生しても、社内人件費・教育費・24h 体制構築費など総コストが下がる場合が多いため、選択肢となります。
A: 外部委託費が発生しても、社内人件費・教育費・24h 体制構築費など総コストが下がる場合が多いため、選択肢となります。
Q: SSO を導入すると運用要員は増えませんか?
A: 認証サーバや管理基盤の監視・維持が必要になるため、単独では要員削減につながりにくいです。
A: 認証サーバや管理基盤の監視・維持が必要になるため、単独では要員削減につながりにくいです。
関連キーワード: 仮想化、サーバ統合、アウトソーシング、運用コスト
設問4:
本文中の下線③について、原因は何か。25字以内で述べよ。
模範解答
受注データ送信が夜間バッチ処理であるから
解説
解答の論理構成
- 問題文には、旧Y社の営業部門が旧Z社の商品を扱う際、
「③“顧客への即日納期回答ができない”原因が情報システムにあることが分かった」
と明記されています。 - 図1(現状の業務流れ図)を見ると、営業システム(旧Y社)で登録された受注データは、その日のうちに工場システム(旧Z社)へ即時連携されず、夜間にまとめて転送されるバッチ処理となっています。
- 受注データが日中に工場システムへ届かないため、同日に在庫引当や納期確認が行えず、営業担当者は顧客へ当日中の回答が出せません。
- よって、下線③の原因は「受注データ送信が夜間バッチ処理になっていること」です。
誤りやすいポイント
- 「在庫引当が遅い」「工場システム側の処理性能不足」などと考えがちですが、根本は“いつ在庫処理を始められるか”を決める受注データ連携タイミングです。
- 「営業担当者の手作業が遅い」と人の側に原因を求めるミス。図1では営業部門内の手続き後、システム間連携がボトルネックになっています。
- 「バッチ処理=悪い」と短絡的に判断しないこと。夜間バッチ自体は一般的ですが、即日回答という要件に合致していない点が問題です。
FAQ
Q: バッチ処理でも即日回答を実現できないのですか?
A: データが夜間にしか転送されないため、日中の問い合わせには反映されません。リアルタイム処理や複数回バッチが必要です。
A: データが夜間にしか転送されないため、日中の問い合わせには反映されません。リアルタイム処理や複数回バッチが必要です。
Q: 在庫引当の高速化で解決できますか?
A: 在庫引当の着手タイミングが夜間後になる点がボトルネックなので、処理速度を上げても即日回答にはつながりません。
A: 在庫引当の着手タイミングが夜間後になる点がボトルネックなので、処理速度を上げても即日回答にはつながりません。
Q: EA策定時、この問題はどの体系で扱いますか?
A: 業務体系(BA)の業務フローと適用処理体系(AA)のシステム間データ連携、双方で現状を可視化し改善方針を立てます。
A: 業務体系(BA)の業務フローと適用処理体系(AA)のシステム間データ連携、双方で現状を可視化し改善方針を立てます。
関連キーワード: バッチ処理、データ連携、在庫引当、業務フロー
設問5:
本文中の下線④を実現するために、事前に、統一を検討しておくべきものは何か。本文中の字句を使って、20字以内で述べよ。
模範解答
業務の進め方や使用する帳票
解説
解答の論理構成
- 目的の確認
CIO は「情報システムの統合」を望み、部長もコスト削減を求めています。したがって、統合を実現する前提条件が何かを探る必要があります。 - 統合を阻む要因の抽出
問題文冒頭で、合併直後の状況が次のように述べられています。「旧Y社と旧Z社では、業務の進め方や使用する帳票が異なっており、合併までの限られた期間内に、これらの統一を行うことが困難であった。」
ここで “これら” が統合を難しくしている直接要因だと明示されています。 - 情報システム統合の前提
情報システムは業務フローや帳票を基に設計・運用されます。業務手順や帳票が会社ごとに違えば、データ項目・入力タイミング・承認経路なども不一致となり、統合後に一貫した処理ができません。 - 導出
したがって、下線④「情報システムの統合」を進めるには、まず業務の進め方や使用する帳票
を統一しておくことが不可欠となります。
誤りやすいポイント
- 「サーバの運用に掛かる社内要員削減」を統一対象と誤解する
→ これは統合の効果として期待されるものであり、事前に統一すべき対象ではありません。 - 「データベース定義」や「プログラム仕様」を答える
→ それらは業務・帳票が統一された後、情報システム側で整備すべき内容です。 - 「営業システムと工場システムの機能」をそのまま挙げてしまう
→ システム機能は業務フローと帳票の統一結果として設計し直す対象であって、統一の出発点ではありません。
FAQ
Q: 統合前に帳票を揃えるのはなぜ必要なのですか?
A: 帳票はデータ項目・入力ルール・承認手順を規定します。帳票が違うままだと、同じ商品でも異なる属性やコードで登録され、データ統合が破綻します。
A: 帳票はデータ項目・入力ルール・承認手順を規定します。帳票が違うままだと、同じ商品でも異なる属性やコードで登録され、データ統合が破綻します。
Q: 業務フローと帳票の統一はどのフェーズで行うのですか?
A: EA 策定手順では「理想(ToBe)モデルの策定」で全社レベルの業務フローを定義し、その結果として共通帳票を設計します。
A: EA 策定手順では「理想(ToBe)モデルの策定」で全社レベルの業務フローを定義し、その結果として共通帳票を設計します。
Q: 帳票統一後、既存システムはすぐに廃止できますか?
A: いいえ。移行計画を立て、データ移行・利用者教育・並行稼働期間を設けて段階的に切り替えるのが一般的です。
A: いいえ。移行計画を立て、データ移行・利用者教育・並行稼働期間を設けて段階的に切り替えるのが一般的です。
関連キーワード: EA, AsIs-ToBe, 業務プロセス統合、帳票設計、データ統合


