A collection of notes and resources
D社は、スーパー向けの弁当・総菜を作るメーカーです。この問題は、製造現場の「品質検査」をどう情報システム化するか、という話です。製造業になじみがなくても読めるよう、まず全体の流れを整理します。
製造の流れとロット
D社の製品は「仕込み→加熱→冷却→包装」という工程を経て完成します。原材料や前工程の半製品(仕掛品)を各工程に投入し、最後の包装工程で完成品(製品)になります。出荷は1日3回あり、その1回分を「便」と呼びます。
ここで大事なのが「ロット」という考え方です。1回に製造する品目のまとまりをロットと呼び、ロットNo.という連番が付きます。同じ「便」で同じ品目を作る場合でも、複数回に分けて製造することがあり、その1回ずつがロットです。品質検査は、このロット単位で行われます(検査担当者は受け取った全ロットを製造完了日時が古い順に検査します)。
品質検査と合格/不合格
各工程で作られた仕掛品・製品は、検査担当者が検査基準に基づいてチェックします。合格なら次工程(または出荷)に進み、不合格なら製造担当者に通知され、同じロット数で新しいロットNo.の追加製造が行われます。つまり「不合格になったら同じ量を作り直す」という業務ルールです。
検査担当者の割当てと変更
D社では、曜日・便・品目ごとに検査担当者が1人ずつ割り当てられています。しかし当日の都合で担当できないことがあり、その場合は検査責任者が製造指示の直前に、品目ごとに他の検査担当者へ変更します。この「変更」がこの問題のシステム設計の中心テーマの一つです。
変更する際、検査責任者は「この検査担当者に振り分けたら忙しすぎないか」を確認したいので、システムは「見込み回数」(前週の同じ曜日・同じ便における実績回数)を、変更元・変更先それぞれの検査担当者について表示します。ここで、なぜ変更元は「品目ごと」、変更先は「検査担当者ごと」に見るのかがポイントです。変更元は「この品目を他の人に渡すかどうか」を品目単位で判断し、変更先は「この人はもうどれだけ仕事を抱えているか」を人単位で判断するためで、見る粒度が違います。
ファイル設計の基礎: マスタと主キー
この問題ではデータベースの「ファイル(テーブル)設計」も問われます。「マスタ」は品目や検査担当者など、あまり変化しない基本情報を持つデータのまとまりです。「主キー」とは、そのテーブルの中で1件のレコードを一意に特定できる項目(の組合せ)のことです。例えば「検査担当者変更ファイル」であれば、「いつ・どの便で・どの品目の検査担当者を変更したか」が分かって初めて1件のレコードとして特定できるので、主キーには製造日・便コード・品目コードが必要になる、という考え方です(設問1(1)がこれを問うています)。
出荷前承認
その日・その便の製品検査が全て完了したことを確認してから、検査責任者が最終承認を行う仕組みです。ここが自動化されず「人が承認ボタンを押す」設計になっているのは、品質管理規定に基づく設備異常の有無や従業員の衛生チェックなど、システムの外側にある情報も踏まえて最終確認する必要があるためです(設問3(3))。システム内のデータだけで自動判定できない業務は、あえて人の承認ステップを残す、という設計判断は、システムアーキテクトとしてよく出てくる考え方です。
D社(弁当・総菜メーカー)の品質検査業務のシステム化を題材にした問題です。ロット単位の品質検査、検査担当者の当日変更、変更時の作業負荷確認(見込み回数)、出荷前承認、という業務フローを、表1(新システムの主要ファイル)・表2(機能概要)と突き合わせて読み解きます。設計のポイントは「見込み回数の集計粒度が変更元(品目ごと)と変更先(検査担当者ごと)で非対称であること」「品質検査指示実績ファイルに検査担当者変更ファイルの内容を優先反映すること」「出荷前承認を自動化せず人の承認操作を残す理由(システム外情報への依存)」の3点です。
状況設定は要点を要約しています。表1・表2は原文の要点を掲載します。
D社は、スーパーマーケットなどの小売店向けの弁当、総菜の製造及び販売を行うメーカーである。品質管理の効率化を図るため、品質管理システム(以下、新システム)を構築することになった。
〔製造から出荷までの流れ〕
製品は仕込み、加熱、冷却、包装という工程を経て完成する。各工程に原材料や前工程で製造された仕掛品を投入する。仕込みから冷却までは仕掛品を、最後の包装工程では製品を製造する。出荷は1日3回行い、その単位を便と呼ぶ。その便で出荷する全ての製品を製造し、品質管理規定に従った最終確認を行った後に出荷を開始する。
〔現行の製造及び品質管理の概要〕
品質検査担当者(検査担当者)が各工程で製造された仕掛品及び製品の品質検査を行っている。
〔新システムへの要望〕
〔新システムの設計〕表1(主要ファイルと属性、抜粋):
表2(機能概要、抜粋):
設問1 検査担当者変更機能、及び品質検査指示作成機能について、(1)~(3)に答えよ。
(1) 表1中の検査担当者変更ファイルの[a]に入れる、主キーとなる属性を全て答えよ。 (2) 表2中の[b]に入れる適切な字句を20字以内で述べよ。 (3) 社員コードを、表2中の(A)で品質検査指示実績ファイルから抽出せずに、表2中の(B)で検査担当者マスタから抽出している理由を、新システムへの要望を踏まえて30字以内で述べよ。
設問2 表2中の下線①における条件の対象となる二つの項目を、表1中の属性の中から答えよ。また、それぞれの項目が満たすべき条件を15字以内で述べよ。
設問3 出荷前承認機能について、(1)~(3)に答えよ。
(1) 〔現行の製造及び品質管理の概要〕の(ア)~(キ)までの業務のうち、新システムでは不要となる業務が二つある。不要となる業務を(ア)~(キ)の記号で二つ答えよ。また、その理由を30字以内で述べよ。 (2) 表2中の[c]、[d]に入れる抽出条件を、表1中の属性を用いて15字以内で述べよ。 (3) 製品検査の完了後、承認入力の操作を必須とした理由は二つある。一つは出荷前承認記録ファイルのレコードを作成し出荷前承認の記録を残すためである。もう一つの理由を35字以内で述べよ。
設問1(1) 解答例:「製造日、便コード、品目コード」
検査担当者変更は「いつ・どの便の・どの品目について」誰に変更したかで1件が定まります。検査担当者マスタが「曜日、便コード、品目コード」で1件を特定しているのと対応関係にあり、「変更」も同じ粒度(製造日単位。曜日でなく実際の日付になる点に注意)で管理する必要がある、という考え方です。
設問1(2) 解答例:「各検査担当者の作業負荷の確認」
新システムへの要望に「検査担当者の変更時に、変更する製造日、便における各検査担当者の作業負荷を確認したい」と明記されています。表2の(D)で集計・表示された見込み回数を見て、検査責任者が何をするか、というと、要望文そのままの「作業負荷の確認」です。
設問1(3) 解答例:「変更前の検査担当者の割当てに従って集計するから」
要望に「品質検査の実績の中で他の検査担当者への変更が行われていた場合でも、変更前の検査担当者の割当てに従って集計してほしい」とあります。もし(A)で品質検査指示実績ファイル(実際に検査した人=変更後の担当者が入る)から社員コードを抽出すると、変更後の実績が混ざってしまいます。変更の影響を受けない検査担当者マスタ(本来の割当て)から抽出することで、要望どおり「変更前の割当てベース」の集計になります。
設問2 解答例: 項目「製造完了日時」、条件「最も古いこと」/ 項目「検査結果」、条件「“未実施”であること」
現行業務(エ)の「受け取った全てのロットに対して製造完了日時が古い順に品質検査を実施」というルールがそのままシステム化されています。次に検査すべきロットは、自分が担当していて(社員コードが自身と一致)、かつまだ検査していない(検査結果が未実施)ロットの中で、一番製造完了が古いもの、という2条件です。
設問3(1) 解答例: 業務「(オ)、(カ)」、理由「検査責任者が直接、製品検査の完了状況を確認できるから」
(オ)製品検査完了確認と(カ)製品検査完了報告は、いずれも「検査が終わったことを人づてに(電話などで)伝える」業務です。新システムでは、出荷前承認機能が検査担当者ごとの完了状況をリアルタイムに表示するため、この人手での確認・報告連絡が不要になります。採点講評では、この設問の正答率がやや低かったとされ、「顧客の業務がどのように変更されて効率化されるのか」を本文から丁寧に追う必要があると指摘されています。
設問3(2) 解答例: [c]「追加フラグが“通常”」、[d]「検査結果が“合格”」
出荷前承認の判定式は「(1)製造開始時の製造指示数の合計」と「(2)出荷可能な製品の製造数」が一致するかどうかです。(1)は最初に決まっていた分だけを数えるので、後から追加された分(追加フラグ=“追加”)を含めない「追加フラグが“通常”」のレコードを合計します。(2)は実際に出荷してよい状態、つまり検査に合格したロットの数なので「検査結果が“合格”」のレコードを合計します。
設問3(3) 解答例:「出荷前承認には、各部署からの報告に基づいた最終確認が必要だから」
これが概念解説で触れた「システム外情報に依存する承認は自動化せず人を残す」という設計判断の答えです。現行業務(キ)に「品質管理規定に従い、製造設備の異常有無、従業員の衛生チェック結果など、各部署からの報告に基づいた最終確認を行った上で」とあり、これらはシステムのデータだけでは判定できない情報です。採点講評でも「承認するための業務上の前提条件を明確に解答していない受験者が多かった」と指摘されており、「なぜ自動化しないのか」を問われたら「システムの外側にある、人でなければ確認できない情報があるから」という構造を書く必要があります。