応用情報技術者 2015年 秋期 午後 問08
ソフトウェアパッケージの利用に関する次の記述を読んで、設問1~3に答えよ。
K社は、現行の購買システムの再構築のために、短期間で導入できる購買業務用ソフトウェアパッケージ(以下、購買パッケージという)の利用を検討している。現行業務を分析し改善要望を整理した結果を基に、業務機能を定義し、新業務フローを作成した。その上で、購買パッケージとのフィット&ギャップ分析を行い、ギャップ部分についてはできるだけ購買パッケージに合わせることとし、重要度が高いギャップだけ、追加プログラムの開発を行う方針とした。
(1)改善要望の整理
現行業務を分析し、改善要望を理した。
・現在の見積りの業務では、現場担当者が仕入先に対して見積りを依頼している。仕入額の削減や発注遅延の防止を目的として、購買部から仕入先に対して見積りを依頼するようにしたい。
・仕入先とのやり取りの業務では、仕入先から受領した情報をシステムに入力する手間や、データの入カミスが問題となっている。特に入力量が多い見積回答データや請求データについては、仕入先に直接入力させたい。
(2)業務機能の定義
改善要望を整理した結果から、表1に示す業務機能を定義した。

(3) 新業務フローの作成
業務機能を定義した結果から、図1に示す新業務フローを作成した。

〔購買パッケージの機能〕
導入を検討している購買パッケージの標準機能を表2に示す。

〔フィット&ギャップ分析〕
業務機能と購買パッケージの標準機能とのフィット&ギャップ分析を行ったところ、表3の結果が得られた。
〔追加プログラムの外部設計〕
フィット&ギャップ分析によってギャップと判定された業務機能のうち、見積回答と、請求については、購買パッケージに合わせて、仕入先から受領した情報をK社の社員がシステムに入力する運用を継続することにした。見積取得依頼については、現場担当者からの依頼に基づいて、購買部が仕入先から見積りを取得するという改善要望を優先することとし、購買パッケージに対して、K社独自の機能を追加プログラムとして開発することにした。
追加プログラムとして開発が必要な、現場担当者が入力する見積取得依頼の画面設計の一部を図2に、見積取得依頼のクラス図を図3に示す。追加プログラムは、購買パッケージが提供しているテーブル(パッケージテーブル)を直接参照せず、購買パッケージが提供しているプログラム(パッケージプログラム)を使用してパッケージテーブルにアクセスする。追加プログラムが必要とするデータでパッケージテーブルに存在しないデータは、K社独自のテーブルとして新たに作成する。

見積取得依頼画面のボタンとその機能を次に示す。
・品目名を入力する際、又は希望する仕入先があり希望仕入先名を入力する際は、品目ボタン又は仕入先ボタンを押すことによって、それぞれの入力補助画面へ遷移する。遷移先の入力補助画面でマスタ検索を行い、出力される品目又は仕入先をラジオボタンで選択し、確定ボタンを押すことによって、見積取得依頼画面の明細に、品目名又は希望仕入先名を指定する。
・明細追加ボタンを押すことによって、品目名、数量などを入力するための新たな明細行が追加される。
・選択欄のチェックボックスにチェックを入力した後、明細削除ボタンを押すことによって、選択した明細行が削除される。
・見積取得依頼画面で案件名及び明細行を入力し登録ボタンを押すことによって、見積取得依頼及びその明細が登録される。
〔購買パッケージのバージョンアップ対応〕
購買システムの本番リリース後、購買パッケージのバージョンアップがあり、見積回答機能が強化されて、K社の業務機能(表1のNo.3)に合致するようになった。そこで、購買パッケージのバージョンアップを検討し、追加プログラムへの影響調査を実施した。購買パッケージにおいては、バージョンアップの際に既存のパッケージテーブルに対する変更は一切行われていないことを確認した。また、追加プログラムの開発に当たって、K社ではパッケージプログラムやパッケージテーブルに対する改修を一切行っていない。
念のため、テスト環境を用意して、購パッケージのバージョンアップを行い、購買システムの動作検証を実施したところ、①追加プログラムが異常終了した。この原因を調査して追加プログラムの修正を実施し、本番環境のバージョンアップを無事に完了した。
設問1:
模範解答
a:見積金額をシステムに入力
b:仕入先が見積回答を直接入力
c:仕入先が請求内容を直接入力
解説
解答の論理構成
- 【問題文】の〔購買パッケージの標準機能〕では、
- 「見積回答入力」=「仕入先から受領した見積回答書の内容を基に、見積金額を入力する。」
と記載されています。この文言から分かる標準機能は“見積金額を入力する”ことであり、これは a に該当します。
- 「見積回答入力」=「仕入先から受領した見積回答書の内容を基に、見積金額を入力する。」
- 同じく標準機能一覧に、仕入先が Web 画面等で直接データを入力する仕組みは示されていません。従って、ギャップ分析表の「標準機能では、aすることが可能。bする機能はなし。」の後半は、“仕入先が見積回答を直接入力する”が入るのが自然です。
- 「請求」について、標準機能には「請求書照合」=「仕入先から受領した請求書の請求内容と検収データを照合し、仕入先への支払い金額を確定する。」しかなく、仕入先自身が請求データを直接入力する仕組みは無いと明言されています。よって c は“仕入先が請求内容を直接入力”となります。
- 以上から、
- a:見積金額をシステムに入力
- b:仕入先が見積回答を直接入力
- c:仕入先が請求内容を直接入力
が導かれます。
誤りやすいポイント
- 「見積回答照会」を見て “a”を“見積回答を閲覧”と誤記する。照会は閲覧であり入力ではない点に注意が必要です。
- 表2に「請求書照合」があるため “c”を“請求書照合”と思い込む。照合は社内処理であり、仕入先入力機能ではないことを見落としがちです。
- “b”と“c”の主語を省略して記述し減点される。ギャップの原因は“仕入先が直接入力できない”ことであり、主語が明示されていないと意図が伝わりません。
FAQ
Q: 見積回答で“入力”と“照会”の違いは何ですか?
A: “入力”はデータを新規登録する行為、“照会”は登録済みデータを閲覧する行為です。標準機能に入力はあっても仕入先による直接入力は無い点がギャップになります。
A: “入力”はデータを新規登録する行為、“照会”は登録済みデータを閲覧する行為です。標準機能に入力はあっても仕入先による直接入力は無い点がギャップになります。
Q: 請求機能のギャップを放置しても問題ありませんか?
A: K社は「仕入先から受領した情報を社員が入力する運用を継続」と決定しているため、短期導入という目的を損ねない範囲で容認しています。ただし運用負荷は残るため、将来的な改善余地はあります。
A: K社は「仕入先から受領した情報を社員が入力する運用を継続」と決定しているため、短期導入という目的を損ねない範囲で容認しています。ただし運用負荷は残るため、将来的な改善余地はあります。
Q: パッケージのバージョンアップ時、追加プログラムが異常終了する主な原因は?
A: テーブル定義は変わらなくても、パッケージプログラムの振る舞いが変わり、追加プログラムが想定していた戻り値や例外仕様が変化した可能性があります。API 仕様確認とリトライ/例外処理の強化が対策となります。
A: テーブル定義は変わらなくても、パッケージプログラムの振る舞いが変わり、追加プログラムが想定していた戻り値や例外仕様が変化した可能性があります。API 仕様確認とリトライ/例外処理の強化が対策となります。
関連キーワード: ギャップ分析、パッケージカスタマイズ、標準機能、要件定義、業務プロセス
設問2:図3について、(1)、(2)に答えよ。
(1)d、fに入れる適切な字句を答えよ。
模範解答
d:明細追加()
f:0..1
解説
解答の論理構成
-
【問題文】には、見積取得依頼画面で用意されるボタンと機能が列挙されている。
引用:「・明細追加ボタンを押すことによって、品目名、数量などを入力するための新たな明細行が追加される。」
ここから、クラス〈見積取得依頼〉には “明細行を追加する” 操作が必要であると分かります。
クラス図の操作一覧には
・「+ 見積取得依頼登録()」
・「+ 明細削除(明細番号)」
が既に記載されており、追加されていないのは “明細追加” に対応する操作だけです。
よって d には「明細追加()」が入ります。 -
〈見積取得依頼明細〉と〈仕入先〉の関連多重度を決定します。
【問題文】の引用:「希望する仕入先があり希望仕入先名を入力する際は…仕入先ボタンを押すことによって…希望仕入先名を指定する。」
また、注記として「*品目名と数量は必須入力」とあり、仕入先については必須とは書かれていません。
つまり、明細は
・仕入先が “指定されない” 場合もある(0件可)
・指定しても1件に限定される(複数不可)
という要件になります。
この条件を UML の多重度で表すと「0..1」となるため、f には「0..1」が入ります。
誤りやすいポイント
- 「品目名と数量は必須入力」という記述だけを見て、仕入先も必須と誤解し “1” としてしまう。
- 画面側の “明細追加ボタン” を見落とし、クラス図に既に存在する「明細削除(明細番号)」と対になる操作の必要性に気付かない。
- 多重度を “1..1” と書く、あるいは “1” と “0..1” の書き分けルールそのものを忘れてしまう。
FAQ
Q: 明細ごとに必ず仕入先を入力してもらう運用に将来変わった場合はどうしますか?
A: 運用変更だけではなく、UML モデルも “0..1” → “1” に修正し、画面入力チェックも合わせて改修する必要があります。
A: 運用変更だけではなく、UML モデルも “0..1” → “1” に修正し、画面入力チェックも合わせて改修する必要があります。
Q: 「明細追加()」の戻り値や引数を定義しなくてよいのですか?
A: 本問題では操作名だけを問われており、引数・戻り値は設計の詳細段階で決めればよい事項とされています。
A: 本問題では操作名だけを問われており、引数・戻り値は設計の詳細段階で決めればよい事項とされています。
Q: 仕入先が複数候補ある場合はどう表現すればよいですか?
A: 1明細に複数仕入先を持たせるなら、多重度を “0..*” に変更し、中間クラス(候補仕入先)を設ける方法が一般的です。
A: 1明細に複数仕入先を持たせるなら、多重度を “0..*” に変更し、中間クラス(候補仕入先)を設ける方法が一般的です。
関連キーワード: UML, クラス図、多重度、操作設計、要件分析
設問2:図3について、(1)、(2)に答えよ。
(2)eに入れる適切な関連と多重度を答えよ。図3の凡例に倣って解答すること。
模範解答
e:(図を参照)


解説
解答の論理構成
-
業務仕様の確認
- 【問題文】には「明細追加ボタンを押すことによって、品目名、数量などを入力するための新たな明細行が追加される。」とあります。
- また「見積取得依頼画面で案件名及び明細行を入力し登録ボタンを押すことによって、見積取得依頼及びその明細が登録される。」とも記載されています。
⇒ 1件の「見積取得依頼」が0件ではなく1件以上の「明細行」を必ず持つことが読み取れます。
-
クラス間のライフサイクル依存
- 「選択欄のチェックボックスにチェックを入力した後、明細削除ボタンを押すことによって、選択した明細行が削除される。」という操作は、親である見積取得依頼の管理下で明細の生成・削除が行われることを示しています。
⇒ 明細オブジェクトは親オブジェクトに強く従属し、親が消滅すれば子も存在し得ません。これは UML でいうコンポジション(黒ひし形)に相当します。
- 「選択欄のチェックボックスにチェックを入力した後、明細削除ボタンを押すことによって、選択した明細行が削除される。」という操作は、親である見積取得依頼の管理下で明細の生成・削除が行われることを示しています。
-
多重度の決定
- 親側(見積取得依頼)から見た子側(見積取得依頼明細)は「1..*」が必要。
- 子側から親側は、各明細が必ず1つの親をもつため「1」。
⇒ 関連端の多重度は「1」対「1..*」。
-
結論
- 関連:コンポジション
- 多重度:左端(親)「1」、右端(子)「1..*」
これが[ e ]に入る正しい記述です。
誤りやすいポイント
- 「0..*」と書いてしまう
→ 【問題文】により明細0件の登録は許可されないため誤りです。 - 集約(白ひし形)で表記する
→ ライフサイクル依存が明確なのでコンポジションが正解です。 - 多重度の左右を逆に記載する
→ 子クラス側に「1..*」、親クラス側に「1」が正しい向きです。
FAQ
Q: 見積取得依頼を削除しても明細を残したい場合はどう表すのですか?
A: ライフサイクルの独立性が必要ならコンポジションではなく集約や単なる関連で表現し、多重度も「0..*」などに変更します。
A: ライフサイクルの独立性が必要ならコンポジションではなく集約や単なる関連で表現し、多重度も「0..*」などに変更します。
Q: 明細行が1件しかなくても「1..*」でいいのですか?
A: はい。最小値1は必須を示し、最大値*は将来の行追加を許容するため業務仕様と一致します。
A: はい。最小値1は必須を示し、最大値*は将来の行追加を許容するため業務仕様と一致します。
Q: コンポジションと集約の違いは試験で重要ですか?
A: 重要です。コンポジションは「部品が親の寿命に厳密に従う」点が特徴で、今回のように親の操作で子の生成・削除を行うケースでよく問われます。
A: 重要です。コンポジションは「部品が親の寿命に厳密に従う」点が特徴で、今回のように親の操作で子の生成・削除を行うケースでよく問われます。
関連キーワード: コンポジション、多重度、クラス図、関連端、設計モデル
設問3:
本文中の下線①の異常終了を予見できなかったのは、バージョンアップの影響調査において何が不足していたからか。調査が必要であった内容について40字以内で述べよ。
模範解答
追加プログラムが使用するパッケージプログラムの変更内容
解説
解答の論理構成
- 追加プログラムは「購買パッケージが提供しているプログラム(パッケージプログラム)を使用してパッケージテーブルにアクセスする」と明記されています。
- バージョンアップ調査では「既存のパッケージテーブルに対する変更は一切行われていないことを確認」しただけで、パッケージプログラム側は確認していません。
- その結果、インタフェース仕様や戻り値の型などパッケージプログラムの振る舞いが変わっていても見逃されました。
- 追加プログラムはパッケージプログラムに依存しているため、そこで仕様差異が生じると「追加プログラムが異常終了」するのは当然です。
- よって不足していた調査内容は「追加プログラムが使用するパッケージプログラムの変更内容」です。
誤りやすいポイント
- テーブル構造が不変なら安全と短絡的に判断し、API やサービスの振る舞いまで確認しない。
- 「改修していない」=「影響がない」と思い込み、疎結合設計でも実装依存を見逃す。
- 単体テストだけで安心し、バージョンアップ後の結合テストや回帰テストを省略する。
FAQ
Q: テーブルが変わらないのにプログラムが落ちるのはなぜですか?
A: 呼び出し先プログラムのパラメータ順や戻り値、例外ハンドリングの仕様が変われば、呼び出し元は正常に動けません。データベースと API は別物です。
A: 呼び出し先プログラムのパラメータ順や戻り値、例外ハンドリングの仕様が変われば、呼び出し元は正常に動けません。データベースと API は別物です。
Q: 予防策はありますか?
A: バージョンアップ時はパブリック API のリリースノートを必ず確認し、テーブル・プログラムの双方について自動化された回帰テストを実行します。
A: バージョンアップ時はパブリック API のリリースノートを必ず確認し、テーブル・プログラムの双方について自動化された回帰テストを実行します。
Q: パッケージプログラム変更の有無をどう検知しますか?
A: ハッシュ比較やバージョン管理システムの差分、ベンダ提供の変更一覧を用いたレビューが有効です。
A: ハッシュ比較やバージョン管理システムの差分、ベンダ提供の変更一覧を用いたレビューが有効です。
関連キーワード: API互換性、回帰テスト、インタフェース仕様、バージョン管理、結合テスト




