システムアーキテクト試験 2010年 午後1 問01

模範解答

解説

解答の論理構成

1. 生産方式変更の内容を確認
   • 【問題文】「(1)ユニット品までは、…見込生産方式」「(2)製品組立は、製番で管理する受注生産方式」
2. 営業上の優位性を導く
   • 見込生産したユニット品を「顧客から受注した後、製品組立計画を立案するときに…引き当てる」ため、受注後は組立だけですぐ出荷できる → リードタイム短縮。
3. 在庫管理上のリスクを導く
   • 見込生産では販売予測の精度が課題。「ユニット品を見込生産するために…精度を上げることが要求」されるが、誤差が残れば余剰・不足両方の在庫リスクが発生する。
4. 25字以内にまとめる
   • 優位性：受注から出荷までのリードタイムが短縮できること
   • リスク：ユニット品，資材の在庫過不足が発生すること

誤りやすいポイント

• リードタイム短縮を「生産性向上」とだけ書いて具体性を欠く。
• リスクを「在庫が増える」と一方向で記述し、不足リスクを落とす。
• 「部品」だけに触れ、「ユニット品」や「資材」を忘れる。
• 見込生産と受注生産の境界を取り違え、優位性とリスクの因果を逆に書く。

FAQ

模範解答

解説

解答の論理構成

1. システム方式の読み取り
   • 製品組立： “製品組立は、製番で管理する受注生産方式”【生産方式の見直し】。
   • ユニット品： “ユニット品までは…機種ごとの販売予測に基づく見込生産方式”【生産方式の見直し】。
2. 営業システムが持つ情報
   • “見積り、受注、売上・請求の機能がある”【現在の業務内容 (1)営業部門】。
   • 販売予測精度向上が “営業部門には…要求された”【生産方式の変更に伴う各部門への要求事項 (1)】。
3. インタフェース要件の導出
   • 製品組立計画モジュールは “営業システムとのインタフェース”【表 新生産管理システムの概要】—受注生産なので見積・受注情報を受け取る。
   • ユニット品生産計画モジュールも “営業システムとのインタフェース”【同表】—見込生産なので販売予測を受け取る。
4. 15字以内で整理
   • 「見積り提示及び受注の情報」（12字）
   • 「機種ごとの販売予測情報」（11字）

誤りやすいポイント

• 製品組立計画に「販売予測」を渡してしまう。製品は受注生産であり見込ではない。
• ユニット品生産計画に「製番情報」を渡すと、在庫前提の見込生産ロジックが破綻する。
• 見積段階のデータ連携を省き「受注確定情報のみ」と答えてしまい、計画立案の前倒し要件を外す。

FAQ

模範解答

解説

解答の論理構成

1. フィードバックすべき情報
   • 生産計画サブシステムには「製品組立計画」のモジュールがあり、ここで組立日程や進捗が管理されます。
2. 営業部門への要求
   • 【問題文】では、生産管理部門への要求として「納期回答のために、製番で管理する製品組立計画の内容やその進捗状況を営業部門に適時にフィードバック」と記載されています。
3. 情報を使う業務の特定
   • 営業業務一覧の中で「顧客からの引合対応」「見積り」「納期回答」「受注」などがあります。
   • 納期回答を行う際には製品組立の最新日程が必須であるため、製品組立計画から得た情報が直接活用されます。
4. 結論
   • 以上より、営業システムが受け取る情報を必要とする業務は「納期回答業務」となります。

誤りやすいポイント

• 「見積り業務」と混同する
  見積りの際にはコスト情報が中心で、組立日程の詳細は不要。
• 「受注業務」と早合点する
  受注確定後に正式な製番が付くが、納期回答は受注より前のプロセス。
• 業務名を曖昧に書く
  「回答業務」「納期確認」など設問が求める語句とずれると減点対象。

FAQ

模範解答

解説

解答の論理構成

1. 設計システムが生成し、生産管理側へ渡す設計成果物を確認
   • 【問題文】
     「設計・技術部門では、製品を構成するユニット品・資材の情報と、製品・ユニット品組立及び部品加工の製造工程情報を設計仕様書に記載して生産管理部門に渡す。」
2. 基準情報管理サブシステムの役割を確認
   • 表「新生産管理システムの概要」より、基準情報管理－部品表管理の機能に「設計システムとのインタフェース」が設定されている。
3. したがって、設計システムから基準情報管理へ流れる情報は上記２種類であると論理的に決定できる。
4. 25字以内で簡潔に表現し、模範解答と一致するかを検証
   • ①「製品を構成するユニット品・資材の情報」
   • ②「製品・ユニット品組立及び部品加工の製造工程情報」
     いずれも原文そのままで要件を満たす。

誤りやすいポイント

• 「部品表そのもの」と回答してしまい、資材情報を漏らす。
• 「工程情報」を「作業指示」と混同し、設計側でなく工程管理側の情報と誤認。
• 「ユニット品」を省略して「製品構成情報」とだけ書き、具体性を欠く。

FAQ

模範解答

解説

解答の論理構成

1. 現行業務の確認
   【問題文】
   「所要量計画の基準となる部品表及び加工計画の基準となる工程表の生成や情報追加は、担当者が…生産管理システムに入力することによって行われている。」
   ─ 現状では“生成”と“情報追加”の両方を人手で実施している。
2. 再構築方針
   (1)～(4) で「生産管理システムを中心に見直し」「基準情報を迅速かつ適時に提供」と指示。既存手作業をシステム化することが要求されている。
3. 表「新生産管理システムの概要」の空欄
   ・部品表管理モジュールの機能が列挙され、最後に「部品表、工程表への情報追加」がある。
   ・この直前の (a) は同じ粒度で並ぶ機能名を補う欄。
4. 組み合わせて導出
   現行で「生成＋情報追加」を行っている ⇒ 新システムでも「生成」を明示する必要がある。
   よって (a) = 「部品表, 工程表の生成」。

誤りやすいポイント

• 「情報追加」と類似表現のみを書き、生成を落とす。
• 「部品表【又は】工程表」と単数で書き、両方を漏らす。
• “作成”“展開”など別語を当てはめ、表の他行との用語統一を崩す。

FAQ

模範解答

解説

解答の論理構成

1. モジュールの対象確認
   表の「生産計画」－「製品組立計画」機能に「ユニット品所要量計算」が列挙されています。
2. 業務要求との対応付け
   【問題文】〔生産方式の変更に伴う各部門への要求事項〕(3) 生産管理部門 に
   「製品組立計画の立案では、ユニット品の所要量計算とユニット品在庫の引当てを行う。」
   と具体的に記載されています。
3. 「同時に行うべき機能」を抽出
   既に所要量計算はモジュールに含まれているため、残る機能は「ユニット品在庫の引当て」。
4. 20字以内で表現
   「ユニット品在庫を引き当てる機能」で要件を満たします。

誤りやすいポイント

• 「在庫管理資料作成」など他モジュールのキーワードを流用し、引当てを忘れる。
• 「資材在庫の引当て」と書き換え、ユニット品と資材を混同する。
• 「ユニット品在庫管理」とだけ書き、引当ての動作まで示さない。

FAQ

模範解答

解説

解答の論理構成

1. 資材正味所要量計算に必要な情報を把握
   • 【問題文】「資材所要量計画では、ユニット品の生産計画を基に…資材の在庫量を加味した上で、正味の資材所要量を決める」。
     ⇒ 必要なのは「ユニット品生産計画」と「資材の在庫量」。
2. 表から該当モジュールを抽出
   • 「ユニット品生産計画」：機能内容に「ユニット品正味所要量計算」。
   • 「資材在庫管理」：機能内容に「資材入出庫処理／資材棚卸処理」。
3. それぞれの“考慮すべきこと”を設定
   • ユニット品生産計画：販売予測精度が所要量の精度に直結。
   • 資材在庫管理：入出庫記録が不正確だと在庫量が狂い、正味計算も誤る。
4. よって模範解答のとおりとなる。

誤りやすいポイント

• 「ユニット品在庫管理」を選択してしまう
  → 資材の在庫量ではなくユニット品の在庫量なので目的が異なる。
• 「製品組立計画」を入れてしまう
  → 資材所要量計画はユニット品ベースで計算するため製品組立計画は直接関与しない。
• “販売予測”の重要性を忘れ、予定生産量を固定値で考えてしまう。

FAQ