食品メーカーの生産管理システム刷新、14か月の全データ

※ この事例は、プロジェクトマネジメントの学習を目的に作成した架空の事例です。登場する企業・人物・数値はすべて創作であり、実在のものとは関係ありません。

■ この事例の概要

惣菜・冷凍食品メーカーの加美乃フーズが、3工場の生産管理システムを刷新した14か月の記録です。工場のラインは止められないため、1拠点ずつ順に切り替える段階展開を選びました。

途中、現場のハンディ端末が想定どおりに使えないことが結合テストで判明し、9月末にはSPI 0.91・CPI 0.95まで落ちています。10月に現場での実機検証を3日間行い、そこから立て直しました。

期間	費用	品質
2025年2月17日に全3工場で稼働（目標は2月末）	2億8,560万円（承認枠の96.8%）	稼働後3か月の本番障害3件、製造停止0件

■ 加美乃フーズという会社と、このプロジェクト

項目	内容
業界	食品製造（惣菜・冷凍食品）
会社	加美乃フーズ株式会社（架空）／年商185億円／従業員640名
拠点	関東工場（5ライン）、中部工場（4ライン）、九州工場（2ライン）
プロジェクト名	生産管理システム刷新（受注〜生産計画〜実績収集〜原価計算）
背景	20年前に自社開発した生産管理システムが保守できなくなっていた。生産計画は表計算ソフトで手作りしており、作成に週32時間かかっていた
期間	2024年1月4日〜2025年2月17日（全拠点稼働）／定着確認は5月30日まで
体制	社内11名＋ベンダー16名（ピーク時27名）
総工数	当初318人月 → 実績336人月
平均単価	85万円／人月
当初契約額	2億7,030万円（318人月×85万円）
承認予算枠	2億9,500万円（うち予備費2,470万円）
新規開発規模	138KStep

■ 何を成功とみなしたか

軸	指標	目標
Q（品質）	稼働後3か月の本番障害	5件以内
Q（品質）	製造ラインの停止に至る障害	0件
C（コスト）	総費用	2億9,500万円以内
D（納期）	全3工場での稼働	2025年2月末まで

Qの2行目が、この案件で最も重い条件でした。ラインが1時間止まると、その分の生産量がそのまま失われます。「障害を減らす」ではなく「ラインを止めない」を目標に置いています。

事業上の成果目標は次の3つです。

成果指標	開始時	目標	測り方
生産計画の作成時間	週32時間	週8時間	生産管理課3名の作業記録
原価が確定するまでの日数	翌月20日	翌月8日	経理部の月次締め実績
製造ロス率	3.8%	2.5%	投入重量に対する廃棄・規格外の比率

■ 立ち上げ時に引いた計画

WBSは318人月で積み上げました。開発が104人月と全体の3分の1を占めます。

WBS	作業	当初（人月）	実績（人月）
1	プロジェクト管理	32	32
1.1	計画・統制	16	16
1.2	品質管理	8	8
1.3	展開統括	8	8
2	要件定義	44	44
2.1	生産計画	16	16
2.2	実績収集	14	14
2.3	原価計算	10	10
2.4	非機能要件	4	4
3	設計	66	66
3.1	基本設計	30	30
3.2	詳細設計	28	28
3.3	方式設計	8	8
4	開発	104	119
4.1	生産計画機能	34	34
4.2	実績収集（現場端末・ハンディ）	30	40
4.3	原価計算	22	27
4.4	既存連携（販売・会計）	18	18
5	テスト	46	46
5.1	単体・結合テスト	20	20
5.2	総合テスト	16	16
5.3	受入テスト支援	10	10
6	移行・展開	26	29
6.1	データ移行	10	13
6.2	拠点展開（3拠点）	10	10
6.3	研修	6	6
—	合計	318	336

増えた18人月は、4.2（＋10）・4.3（＋5）・6.1（＋3）です。いずれも後述する現場端末の作り直しと、それに伴う原価按分ロジックの見直しによるものです。

#	マイルストーン	計画	実績	差
M1	要件確定	2024/3/29	2024/3/29	±0
M2	基本設計完了	2024/6/28	2024/6/28	±0
M3	開発完了	2024/10/31	2024/11/15	＋2週
M4	総合テスト完了	2024/12/20	2024/12/20	±0
M5	関東工場稼働	2025/1/6	2025/1/6	±0
M6	全工場稼働	2025/2/28まで	2025/2/17	▲11日

■ 前半9か月：計画どおりに見えていた期間と、その裏側

要件定義と基本設計は、計画どおりに終わりました。EVMの指標も1月から6月までSPI 0.97以上を保っています。

月末	PV	EV	AC	SPI	CPI
2024/1月	700	700	710	1.00	0.99
2月	1,900	1,880	1,900	0.99	0.99
3月	3,500	3,430	3,470	0.98	0.99
4月	5,400	5,290	5,350	0.98	0.99
5月	7,600	7,450	7,530	0.98	0.99
6月	10,000	9,700	9,890	0.97	0.98
7月	12,700	12,070	12,440	0.95	0.97
8月	15,400	14,170	14,760	0.92	0.96
9月	18,100	16,470	17,340	0.91	0.95
10月	20,600	19,150	20,160	0.93	0.95
11月	22,900	21,980	22,890	0.96	0.96
12月	24,900	24,400	25,150	0.98	0.97
2025/1月	26,900	26,630	27,190	0.99	0.98
2月	28,560	28,560	28,560	1.00	1.00

※ 単位は万円、いずれも累計。PVは実績ベースライン（BAC＝2億8,560万円）に基づきます。

図2 EVMの累積推移

■ 7月：結合テストで現場端末が動かなかった

7月の結合テストで、現場で使うハンディ端末の問題が次々に出ました。内容を分類すると、次のとおりです。

分類	件数	具体的な内容
操作性	34	作業用手袋をしたままではボタンを押し分けられない
環境	21	冷凍庫内（マイナス20度）で画面の反応が鈍る／結露する
通信	17	ライン奥で電波が届かず、実績登録が失敗する
業務手順	28	1人が複数ラインを掛け持ちする際の切り替え操作が多すぎる
合計	100	—

原因ははっきりしていました。要件定義も設計も、本社の会議室で行っていたことです。仕様書には「ハンディ端末で実績を登録する」と書かれていましたが、どういう環境で、どんな服装で、どれだけの頻度で操作するかは書かれていませんでした。

■ 10月：3日間の現場実機検証

設計の会議を増やすのではなく、現場に行くことにしました。関東工場に3日間入り、実機を持ち込んで作業者に使ってもらう検証です。

日程	対象	参加者	結果
10/15	常温ライン2本（日勤）	作業者6名＋SE3名	指摘42件。ボタン配置と文字サイズを全面見直し
10/16	冷凍ライン1本（日勤・夜勤）	作業者5名＋SE3名	指摘28件。手袋対応と結露対策のケースを決定
10/17	全ライン（改善版で再検証）	作業者8名＋SE3名	指摘9件。いずれも軽微。実装方針を確定

3日目の指摘が9件まで減ったことで、方向性が正しいと確認できました。この結果をもとに、4.2の開発に10人月を追加しています。

あわせて、通信が届かない場所については端末側にいったん保存し、電波が届いたときに送る方式に変更しました。これが原価計算の按分ロジックに影響し、4.3に5人月が追加されています。

■ 12月〜2月：段階展開

図1 3工場への段階展開と並行運用

3工場を同時に切り替えることはせず、関東から順に展開しました。結果は次のとおりです。

拠点	稼働日	ライン数	並行運用	稼働後2週の問い合わせ	本番障害
関東工場	2025/1/6	5	2週間	214件	2件
中部工場	2025/2/3	4	1週間	96件	1件
九州工場	2025/2/17	2	1週間	41件	0件

問い合わせが214件から96件へ減ったのは、関東での質問内容を分類して手順書に反映したからです。特に多かった上位3項目を、中部の研修資料の冒頭に移しました。

関東で多かった質問	件数	中部への反映
ラインを切り替えるときの操作	48	研修の最初に実機で練習する時間を設けた
実績を間違えて登録したときの訂正方法	37	手順書に1ページの図解を追加
端末が圏外のときの表示の見方	25	端末に貼るシールを作成し、全台に貼付

移行リハーサルは全拠点で合計5回行いました。

回	実施日	対象	所要	結果
第1回	2024/11/23	関東：品目・BOMマスタ	3時間10分	BOMの階層に循環参照12件を検出
第2回	2024/12/7	関東：全マスタ＋仕掛	5時間45分	仕掛在庫の単位換算に誤り。換算表を修正
第3回	2024/12/21	関東：本番相当	4時間50分	差異0件。手順書を確定
第4回	2025/1/25	中部：本番相当	4時間05分	差異0件
第5回	2025/2/8	九州：本番相当	3時間20分	差異0件

■ 品質のデータ

図3 工程別の不具合密度

工程	テストケース数	検出不具合	うち重大（A）	不具合密度（件／KStep）
単体テスト	8,280	428	21	3.10
結合テスト	2,760	262	19	1.90
総合テスト	2,070	97	4	0.70
受入テスト	830	15	0	0.11

結合テストの262件には、7月に出た現場端末の100件が含まれます。この100件を結合テストで出し切ったことが、稼働後の障害を3件に抑えた理由です。もし総合テストまで見つからなければ、作り直す時間はありませんでした。

■ 結果：QCDの計画と実績

軸	指標	目標	実績	判定
Q	稼働後3か月の本番障害	5件以内	3件	達成
Q	製造ライン停止に至る障害	0件	0件	達成
C	総費用	2億9,500万円以内	2億8,560万円（96.8%）	達成
D	全3工場での稼働	2025年2月末まで	2025年2月17日	達成

事業成果は稼働6か月後（2025年8月）に測定しました。

成果指標	開始時	目標	6か月後	達成率
生産計画の作成時間	週32時間	週8時間	週11時間	87.5%
原価が確定するまでの日数	翌月20日	翌月8日	翌月9日	91.7%
製造ロス率	3.8%	2.5%	2.9%	69.2%

製造ロス率だけ達成率が低いのは、システムだけでは動かない指標だからです。ロスを減らすには仕込み量の決め方そのものを変える必要があり、これは稼働後の改善活動として継続しています。

■ このプロジェクトで使っていた管理帳票

課題は全期間で178件。代表的な8件です。

No	発生日	区分	内容	担当	期限	完了日
C-022	2/14	業務	3工場で仕掛品の数え方が異なる	生産管理／吉岡	3/8	3/6
C-051	4/9	システム	会計システムの原価科目と新システムの分類が一致しない	情シス／田渕	4/26	4/24
C-088	7/11	品質	ハンディ端末が手袋で操作できない	ベンダー／森川	8/2	10/17
C-091	7/12	品質	冷凍庫内で端末の反応が鈍る	ベンダー／森川	8/2	10/17
C-103	8/5	計画	端末の作り直しで開発完了日が守れない見込み	PM／堀内	8/23	9/6
C-124	10/18	設計	オフライン登録時の原価按分をどう扱うか未定	経理／新開	11/1	10/31
C-147	12/8	移行	BOMに循環参照12件	生産技術／須田	12/18	12/16
C-166	1/9	運用	関東でライン切替の操作に関する質問が集中	展開／宮原	1/17	1/16

C-088とC-091は、期限8月2日に対して完了が10月17日です。2か月半かかっていますが、これは「直せなかった」のではなく、現場検証の日程を待っていたためです。課題管理表では、この間の状態を「対応中（10/15の現場検証待ち）」と明記していました。

リスクは全期間で38件。主要な6件です。

No	リスク	影響度	発生確率	想定される影響	対応	結果
R-02	製造ラインを止める障害が発生する	大	中	1時間あたり約280万円の生産減	段階展開＋並行運用で保険をかける	発生せず
R-06	現場端末が実際の作業環境で使えない	大	中	実績収集が機能しない	当初は机上レビューのみ。7月に顕在化	顕在化（7月）
R-09	3工場で業務のやり方が違う	中	高	仕様の追加、展開の遅れ	要件定義前に3工場を訪問	回避
R-14	繁忙期（年末）と展開が重なる	中	高	研修の時間が取れない	関東の稼働を年明け1/6に設定	回避
R-21	BOMデータの品質不良	中	中	原価計算が合わない	リハーサルを拠点ごとに実施	対応済
R-30	ベンダーの要員が年度末に抜ける	中	低	定着支援が手薄になる	5月末までの契約を事前に締結	発生せず

R-06が、このプロジェクト最大の反省点です。影響度「大」と評価しながら、対策が「机上レビュー」だけでした。影響度が大きいリスクには、実物で確かめる対策を置くべきでした。

TODOは週次で管理しました。現場検証を決めた9月第1週の一覧です。

No	内容	担当	期限	状態
T-286	関東工場に3日間の検証枠を依頼	堀内	9/6	完了
T-287	検証用の実機5台を手配	森川	9/13	完了
T-288	検証で見る観点のチェックリストを作成	宮原	9/11	完了
T-289	開発完了日の変更をステコミへ報告	堀内	9/9	完了
T-290	追加工数の見積をベンダーへ依頼	堀内	9/6	完了
T-291	予備費充当の稟議を起案	田渕	9/20	完了

■ 振り返り：効いたこと、効かなかったこと

効いたこと	なぜ効いたか
段階展開にした	関東で出た214件の問い合わせを手順書に反映でき、中部96件・九州41件と減らせた
現場に3日間入った	会議室で100回議論しても出なかった指摘が、1日目だけで42件出た
結合テストで端末問題を出し切った	総合テストまで持ち越していたら、作り直す時間がなかった
並行運用の期間を最初に決めていた	「様子を見ながら」にせず、拠点ごとに2週間・1週間と決めたので、旧システムを3月3日に止められた

効かなかったこと	何が足りなかったか
要件定義を本社会議室だけで行った	現場の環境条件（手袋、低温、電波）が仕様に入らなかった。最初に1日でも現場に入っていれば防げた
影響度「大」のリスクに机上対策しか置かなかった	R-06は7月まで放置された。影響度が大きいリスクには実物で確かめる対策が要る
端末の仕様レビューをベンダー内で完結させた	作業者が一度も触っていない状態で設計が確定していた

■ 自分の現場で使うなら

現場で使うものは、現場で確かめる日程を計画に入れる：端末、帳票、掲示物。要件定義と設計の各1回、日付を決めて置く
影響度「大」のリスクには、実物で確かめる対策を置く：机上レビューは対策として弱い
複数拠点は1拠点ずつ展開し、間に手順を直す期間を置く：この事例では関東と中部の間に4週間を確保した
並行運用の期間を数字で決めておく：拠点ごとに何週間と決め、終了日をカレンダーに置く

1つ目が最も重要です。このプロジェクトで追加になった18人月・1,530万円は、要件定義の段階で現場に1日入っていれば、その大半が避けられた可能性があります。