応用情報技術者 2015年 秋期 午後 問04
システム要件定義に関する次の記述を読んで、設問1~5に答えよ。
A社は、乳製品を製造・販売する会社であり、主な顧客はスーパーマーケットや小売店である。A社は首都圏近郊に三つの工場(X工場、Y工場、Z工場)をもち、牛乳、ヨーグルト、乳飲料など約30種類の製品を製造している。製品には、全ての工場で共通して生産する標準的な製品に加えて、それぞれの工場だけで生産するその地域限定の製品がある。また、1か月に1回製品価格の改定を行っており、顧客へは受注時点の製品価格で販売している。
現在は、工場近郊の顧客からの注文を工場内にある営業部が受注し、受注した工場で製品を製造して顧客に出荷している。しかし、近年、工場近郊の顧客数にばらつきが生じ、X工場の製造量は限界に達しているが、Y工場の製造量には余裕がある状態となっている。そこで、各工場内にある営業部を本社へ統合し、顧客からの注文を本社で一括して受注し、製造を各工場に割り当てる業務改革を実施することになった。
現在の受注システムは、各工場の営業部で受注することを前提に設計されており、業務改革に合わせて再構築が必要となった。再構築に当たり、システムインテグレータであるB社のC君がシステム要件定義を担当することになった。
〔システム要件定義の進め方の検討〕
C君は、まずシステム要件定義の進め方を検討し、次の①~③の流れでシステム要件定義を進めることにした。
① 現行システム分析:現行システムの設計書やソースコードを基に、システムの現状をシステム機能一覧、a、概念データモデルなどにまとめる。
② 新業務分析:営業部にヒアリングやアンケートを実施し、業務改革後の新業務の概要をb、業務フロー、概念データモデルなどにまとめる。
③ 課題分析:現行システム分析と新業務分析の結果から、現行の受注システムの課題を分析する。
〔現行システム分析〕
C君は、現行システムの設計書を基に、現行の受注システムがもつテーブルを調査し、概念データモデルを作成した。現行の受注システムのテーブル構造(抜粋)を表1に、C君が作成した概念データモデル(抜粋)を図1に示す。表1において、下線は主キーを表す。


〔新業務分析と課題分析〕
C君は、営業部にヒアリングやアンケートを実施し、業務改革後の新受注業務及び新出荷業務の業務フローの作成を行った(図2)。また、現行の受注システムの課題を次のように分析した。
課題1:業務改革後は顧客からの注文を本社で一括して受注するが、現行の受注システムでは、本社で一括して受注した受注データを登録できない。受注データの管理単位を変更する必要がある。
課題2:1回の受注で受け付けた製品を複数の工場から出荷する場合に、出荷データを登録できない。同一工場から、同一顧客へ、同一出荷日の製品を一つの出荷として扱い、工場ごとに別々の出荷ができるように、出荷データの管理単位を変更する必要がある。

〔新システムの概念データモデル〕
C君は、〔新業務分析と課題分析〕の結果から新システムの概念データモデルを作成した。C君が作成中の新システムの概念データモデルを図3に示す。

設問1:
本文中のa、bに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:課題問題点一覧
イ:業務一覧
ウ:システム機能関連図
エ:要求一覧
模範解答
a:ウ
b:イ
解説
解答の論理構成
-
現行システム分析(①)の成果物
【問題文】には「システムの現状をシステム機能一覧、a、概念データモデルなどにまとめる」とあります。- 現行システムの“機能”を一覧化した後は、それら機能同士の関係や入出力を図示するのが一般的です。
- 解答群で機能間の関係を示す成果物は「ウ:システム機能関連図」のみです。
よって a=「ウ:システム機能関連図」となります。
-
新業務分析(②)の成果物
【問題文】には「新業務の概要をb、業務フロー、概念データモデルなどにまとめる」とあります。- 新業務をまず“業務単位”で棚卸しし、それをフロー化・モデル化していくのが定石です。
- 解答群で業務を一覧にまとめる成果物は「イ:業務一覧」のみです。
よって b=「イ:業務一覧」となります。
-
まとめ
a=「ウ:システム機能関連図」
b=「イ:業務一覧」
誤りやすいポイント
- 「エ:要求一覧」を選ぶ誤答
要件定義フェーズまでは業務・機能を整理する段階であり、“要求”という言葉は上位工程(ビジネス要求・ユーザ要求)で使用されがちです。 - 「ア:課題問題点一覧」との混同
現行システム分析で課題を洗い出す作業は③の課題分析で行われるため、①の成果物には含まれません。 - “機能”と“業務”の区別が曖昧になる
現行=システム中心なので「機能」、新業務=ビジネス中心なので「業務」という視点が鍵です。
FAQ
Q: システム機能関連図と業務フローの違いは何ですか?
A: 前者は「機能間の関係」を示す静的な図、後者は「業務プロセスの流れ」を示す動的な図です。目的も粒度も異なるため両方作成します。
A: 前者は「機能間の関係」を示す静的な図、後者は「業務プロセスの流れ」を示す動的な図です。目的も粒度も異なるため両方作成します。
Q: 要求一覧はいつ作成するのですか?
A: ビジネス要求・ユーザ要求を整理する上流工程で作ります。本問の①②はそれより詳細化された“機能”“業務”レベルの整理フェーズです。
A: ビジネス要求・ユーザ要求を整理する上流工程で作ります。本問の①②はそれより詳細化された“機能”“業務”レベルの整理フェーズです。
Q: 課題分析で使う「課題問題点一覧」はどこで登場しますか?
A: ③課題分析の成果物として利用されます。現行と新業務を突き合わせてギャップを抽出する際に必要になります。
A: ③課題分析の成果物として利用されます。現行と新業務を突き合わせてギャップを抽出する際に必要になります。
関連キーワード: 概念データモデル、業務フロー、機能分析、ギャップ分析、要件定義
設問2:
図1及び図3について、cに入れる適切なリレーションシップを解答群の中から選び、記号で答えよ。
解答群
ア:|
イ:↓
ウ:↑
エ:↕︎
模範解答
c:エ
解説
解答の論理構成
-
製造実態の確認
表1には、 「製造製品 工場コード、製品コード」
とあります。どちらも主キー(下線)となっており、同一テーブルに二つの主キーが並列で置かれていることから、これは 「工場」と「製品」を結び付ける中間テーブル であると読み取れます。 -
多対多リレーションの導出
中間テーブルが存在するということは、 ・一つの工場が複数の製品を製造する
・同一製品が複数の工場で製造される
という “多対多” の関係が成立していることを意味します。 -
図1の記号との対応付け
図1では「工場」から「製品」へ線が延び、その途中に小さな四角(製造製品)と c の記号が付いています。凡例には
「↔ :多対多」
と記載されていますので、c には “多対多” を示す記号を入れる必要があります。 -
解答群の選択
解答群のうち “多対多” を表すのは
エ:↕︎
です。よって
c:エ
誤りやすいポイント
- 「下線が複数付いている=複合主キー」という認識が甘いと、中間テーブルと気付かず 1対多 と誤判断しやすいです。
- 図中の小さな四角を単なるノード装飾と見てしまい、リレーションシップの意味を見落とすケースがあります。
- 解答群の記号(|、↓、↑、↕︎)のイメージ先行で選択すると、多対多=左右に広がる ↔ と誤記憶して “↓” などを選ぶミスが起こりがちです。
FAQ
Q: 「製造製品」テーブルを見つけたら必ず多対多と決め付けても良いですか?
A: 主キーが他テーブルの主キーだけで構成される場合は多対多の可能性が高いですが、別の属性を持つケースもあります。属性有無を確認してから判断すると確実です。
A: 主キーが他テーブルの主キーだけで構成される場合は多対多の可能性が高いですが、別の属性を持つケースもあります。属性有無を確認してから判断すると確実です。
Q: 図の途中にある小さな四角は何を表していますか?
A: 多くの場合 “連結エンティティ(連係エンティティ)” を示します。今回で言えば「製造製品」がそれに当たり、工場と製品の多対多関係を解消する役割を担っています。
A: 多くの場合 “連結エンティティ(連係エンティティ)” を示します。今回で言えば「製造製品」がそれに当たり、工場と製品の多対多関係を解消する役割を担っています。
Q: 一対多と多対多を間違えないコツはありますか?
A: 「片方の主キーが相手テーブルに外部キーとして入っているだけなら一対多」「両方の主キーが合体して別テーブルを作っているなら多対多」と整理するとミスが減ります。
A: 「片方の主キーが相手テーブルに外部キーとして入っているだけなら一対多」「両方の主キーが合体して別テーブルを作っているなら多対多」と整理するとミスが減ります。
関連キーワード: 多対多、概念データモデル、複合主キー、リレーションシップ、中間テーブル
設問3:
図1中の属性“製品単価”と“受注単価”の両方が必要な理由を20字以内で述べよ。
模範解答
受注時点の製品価格で販売するから
解説
解答の論理構成
- 【問題文】には「1か月に1回製品価格の改定を行っており、顧客へは受注時点の製品価格で販売している。」と記載されています。
- したがってエンティティ「製品」に格納する「製品単価」は“最新の標準価格”を保持する属性です。
- 一方、エンティティ「受注明細」に格納する「受注単価」は“受注時点”に確定した価格を保持し、後続の請求・出荷計算で参照します。
- 価格改定後に「製品単価」が更新されても、過去の受注が影響を受けないようにするため、両方の属性が必要となります。
誤りやすいポイント
- 「同じ価格なら一つで良い」と考え、履歴保持の必要性を見落とす。
- 「受注明細」で「製品単価」を参照すればよいと誤解し、価格改定後の整合性崩壊を招く。
- 「受注単価」を割引額やキャンペーン価格と混同し、本来の目的を曖昧にしてしまう。
FAQ
Q: 価格改定がなければ「受注単価」は不要ですか?
A: 改定が想定されていないシステムなら不要ですが、本問題では改定が明示されているため必須です。
A: 改定が想定されていないシステムなら不要ですが、本問題では改定が明示されているため必須です。
Q: 「受注単価」はどのタイミングで決定・保存されますか?
A: 顧客の注文を「注文受付」した直後、受注登録時点で確定し「受注明細」に保存します。
A: 顧客の注文を「注文受付」した直後、受注登録時点で確定し「受注明細」に保存します。
Q: もし出荷時に再度値引きが発生したらどう扱いますか?
A: 値引きは「受注単価」に反映するか別属性(値引額など)で管理し、履歴を壊さない構造にします。
A: 値引きは「受注単価」に反映するか別属性(値引額など)で管理し、履歴を壊さない構造にします。
関連キーワード: マスタデータ、スナップショット、価格改定、データ整合性
設問4:
〔新業務分析と課題分析]の課題1は、図1の概念データモデルにおいて、どのエンティティのどの属性が原因であるか。エンティティ名と属性名を答えよ。
模範解答
エンティティ名:受注
属性名:工場コード
解説
解答の論理構成
-
課題の確認
【問題文】には、課題1として
「課題1:業務改革後は顧客からの注文を本社で一括して受注するが、現行の受注システムでは、本社で一括して受注した受注データを登録できない。」
と明記されています。つまり、“受注データの管理単位”が工場単位になっている点が問題です。 -
現行データモデルの原因箇所を特定
図1の現行概念データモデルで、エンティティ「受注」の属性一覧は
「受注伝票番号、工場コード、顧客コード、受注日、納入予定日」
となっています。ここに「工場コード」が含まれているため、受注レコード=工場ごとに1件 という縛りが作られ、本社一括受注が表現できません。 -
図2・図3との整合性
新業務では図2に示すように、「X工場・Y工場・Z工場への引当」を営業部が判断し、後段で製品単位に割り当てます。この流れを反映するためには、受注自体に工場情報を持たせず、後続の「引当製品」などで工場を管理する構造にする必要があります。 -
結論
以上より、課題1を引き起こしているのは
エンティティ名:「受注」
属性名:「工場コード」
であると導けます。
誤りやすいポイント
- 「受注明細」にも「製品コード」が含まれているため、製品単位の問題と誤解しやすい。実際の制約は受注ヘッダにある「工場コード」です。
- 課題2(出荷単位の変更)と混同し、出荷関連エンティティを原因と答えてしまうケース。設問は課題1だけを問うています。
- 「工場コード」が主キーでないため影響が少ないと考えてしまうミス。主キーでなくても業務的には受注を工場に帰属させる強制力があります。
FAQ
Q: 「工場コード」を削除せずに解決する方法はありますか?
A: 工場コードを非必須にする、または別テーブルに分離する方法もありますが、受注エンティティの粒度を顧客単位に統一した方がシンプルで保守性も高まります。
A: 工場コードを非必須にする、または別テーブルに分離する方法もありますが、受注エンティティの粒度を顧客単位に統一した方がシンプルで保守性も高まります。
Q: 課題1と課題2は同時に解決すべきですか?
A: はい。受注を工場単位で持たない構造にし、その後の「出荷」や「出荷明細」で工場別に管理することで、両課題を一貫して解決できます。
A: はい。受注を工場単位で持たない構造にし、その後の「出荷」や「出荷明細」で工場別に管理することで、両課題を一貫して解決できます。
Q: 「受注」から「工場コード」を削除すると検索性能に影響しませんか?
A: 工場別検索は「引当製品」や「出荷」側でインデックスを設ければ対応可能です。受注明細は受注と1対多で結合できるため、大きな性能劣化は発生しにくいです。
A: 工場別検索は「引当製品」や「出荷」側でインデックスを設ければ対応可能です。受注明細は受注と1対多で結合できるため、大きな性能劣化は発生しにくいです。
関連キーワード: データ正規化、概念データモデル、主キー設計、エンティティ分割、業務フロー分析
設問5:〔新システムの概念データモデル〕について、(1)、(2)に答えよ。
(1)図3中のdに入れる適切な属性名を答えよ。
模範解答
d:工場コード
解説
解答の論理構成
-
受注後に製品をどの工場から出荷するかを管理する必要
問題文では「課題2」として「同一工場から、同一顧客へ、同一出荷日の製品を一つの出荷として扱い、工場ごとに別々の出荷ができるように、出荷データの管理単位を変更する必要がある。」と記載されています。ここから、製品と工場の組合せを明確に保持するエンティティが必須であると分かります。 -
引当処理の結果を保持するエンティティの確認
図3では「引当製品」エンティティがあり、既に主キーになっている「受注伝票番号」「製品コード」に加えて d が未決定です。課題2の要件を満たすには、同じ受注・同じ製品でも工場が異なれば別レコードになる設計が必要です。 -
工場を区別する属性の特定
工場を識別する属性は表1の「工場」テーブルに示されている「工場コード」しかありません。したがって、「引当製品」エンティティが工場単位でレコードを区別できるようにするには d に「工場コード」を追加するしかありません。
以上より、d に入る適切な属性名は
工場コード
となります。
工場コード
となります。
誤りやすいポイント
- 「出荷」エンティティにも工場情報が入るので「引当製品」には不要だと判断してしまう。実際には引当段階でも工場別に在庫・能力を管理するため必須です。
- 「顧客コード」や「出荷伝票番号」を追加したくなるが、これらは既に他のエンティティで一意に管理されており、工場区分の要件を満たしません。
- 「工場名」を入れたくなるケース。コード体系を正規化するときは名前ではなく「工場コード」を格納し、名称は参照関係で取得します。
FAQ
Q: 「引当製品」に「工場コード」を入れると冗長になりませんか?
A: 課題2の通り「同一工場」単位で出荷管理を行うため、工場を区別できなければ正しい引当結果を保持できません。正規化の観点でもキー候補に含めるのが妥当です。
A: 課題2の通り「同一工場」単位で出荷管理を行うため、工場を区別できなければ正しい引当結果を保持できません。正規化の観点でもキー候補に含めるのが妥当です。
Q: 「工場コード」を主キーに含めると複合キーが増えますが性能影響は?
A: 主キーに列を追加すれば索引幅は広がりますが、検索条件に必ず「工場コード」が含まれる業務フローなので選択度が向上し、むしろアクセス効率は改善します。
A: 主キーに列を追加すれば索引幅は広がりますが、検索条件に必ず「工場コード」が含まれる業務フローなので選択度が向上し、むしろアクセス効率は改善します。
Q: 出荷時に工場を変更したくなった場合は?
A: 引当変更=「引当製品」の「工場コード」を更新することになります。出荷確定後は「出荷明細」にも工場が含まれるため、整合性制約で相互更新が求められます。
A: 引当変更=「引当製品」の「工場コード」を更新することになります。出荷確定後は「出荷明細」にも工場が含まれるため、整合性制約で相互更新が求められます。
関連キーワード: 正規化、概念データモデル、リレーションシップ、主キー、エンティティ
設問5:〔新システムの概念データモデル〕について、(1)、(2)に答えよ。
(2)〔新業務分析と課題分析〕の課題2を解決するためには、“出荷”エンティティの属性を変更し、“出荷明細”エンティティを追加する必要がある。図3中のe、fに入れる適切な属性名を答えよ。さらに、“出荷明細”エンティティに追加すべき必要最小限の属性の属性名を、図1中の字句を用いて答えよ(eとfは順不同)。
模範解答
e:顧客コード
f:工場コード
属性名:出荷伝票番号、受注伝票番号、製品コード
解説
解答の論理構成
-
課題の抽出
- 【問題文】では課題2として「同一工場から、同一顧客へ、同一出荷日の製品を一つの出荷として扱い、工場ごとに別々の出荷ができるように、出荷データの管理単位を変更する必要がある。」と明示されています。
- したがって、新しい“出荷”エンティティは「工場ごと」「顧客ごと」「出荷日ごと」にレコードを区別する設計が必須です。
-
“出荷”エンティティの属性決定
- 「出荷日」は既に属性として存在します。残るキー要素は「工場ごと」「顧客ごと」です。
- 現行システムのテーブル構造(表1)には“工場”テーブルの主キー「工場コード」、“顧客”テーブルの主キー「顧客コード」があり、これをそのまま利用すれば要件を満たします。
- よって図3の e と f に入るのは「顧客コード」と「工場コード」となります(順不同)。
-
“出荷明細”エンティティに必要な最小属性
- “出荷明細”は「どの出荷伝票で」「どの受注明細(製品)」を「何個」出荷したかを保持するエンティティです。
- 追跡性を担保するため、主キーである「出荷伝票番号」と、出荷元である受注を参照する「受注伝票番号」、さらに品目特定のための「製品コード」が最低限必要です。
- これにより「1回の受注 ⇒ 複数の出荷 ⇒ 各出荷に複数の製品」という多段階の多対多関係を正規化して管理できます。
-
回答のまとめ
・e:顧客コード
・f:工場コード
・“出荷明細”に追加すべき属性:出荷伝票番号、受注伝票番号、製品コード
誤りやすいポイント
- 「出荷伝票番号があるから顧客コードは不要」と考えてしまう
→ 課題2は“同一顧客へ”を管理単位に含めることを要求しています。伝票番号だけでは要件を満たしません。 - “出荷明細”に数量(個数)だけを追加して主キーを欠落させる
→ 受注と製品を識別する複合キーがなければ明細行を一意に特定できず、重複登録を招きます。 - “受注明細”の主キーをそのまま流用し、“出荷明細”に「出荷伝票番号」を入れ忘れる
→ 出荷レベルでの集計やトレーサビリティが行えなくなります。
FAQ
Q: 出荷伝票番号を主キーにすれば十分ではありませんか?
A: 複数の製品が同じ出荷伝票で送られるため、明細側には製品を区別する「製品コード」が必要です。また受注とのひも付けとして「受注伝票番号」を保持すると整合性が保たれます。
A: 複数の製品が同じ出荷伝票で送られるため、明細側には製品を区別する「製品コード」が必要です。また受注とのひも付けとして「受注伝票番号」を保持すると整合性が保たれます。
Q: “出荷”エンティティに受注伝票番号を入れないのはなぜですか?
A: 1回の受注を複数工場に分割して出荷するため、出荷と受注は1対多関係になります。受注伝票番号は“出荷”ではなく“出荷明細”で保持するほうが、複数受注明細をまとめて1出荷に載せる設計と親和性が高くなります。
A: 1回の受注を複数工場に分割して出荷するため、出荷と受注は1対多関係になります。受注伝票番号は“出荷”ではなく“出荷明細”で保持するほうが、複数受注明細をまとめて1出荷に載せる設計と親和性が高くなります。
Q: 個数は“出荷明細”に入れなくてよいのですか?
A: 試験の設問は「必要最小限の属性」を問うています。数量は業務上必要ですが、要求された範囲(主キーおよび外部キー)には含まれていないため、本問の解答対象外です。
A: 試験の設問は「必要最小限の属性」を問うています。数量は業務上必要ですが、要求された範囲(主キーおよび外部キー)には含まれていないため、本問の解答対象外です。
関連キーワード: 概念データモデル、主キー、多対多関係、正規化、トレーサビリティ


