Factory Advance

生産管理システムの要件定義の作り方|現場が回る最低限の機能から決める

各部門に「システムに何を求めますか」と聞いて回った結果、要件が100項目を超えた。全部を満たす製品は見つからず、見つかっても予算が合わない。そのまま検討が止まって半年が過ぎる。中小製造業のシステム導入でよくある行き詰まり方です。原因は要望を集めたことではなく、集めた要望に優先順位をつける基準を持たないまま集めたことにあります。本記事では、要件定義の出発点を「現場が回る最低限」に置き、そこから広げていく作り方を扱います。導入プロジェクト全体の進め方は生産管理システム導入手順で扱っているので、本記事は要件をどう決めるかに絞ります。

生産管理システムの要件定義とは

要件定義とは、システムに何をさせるかを、選定や構築の前に文章で確定させる作業です。ここで決めた内容が製品選定の物差しになり、導入後に「思っていたものと違う」が起きるかどうかを分けます。

中小製造業の要件定義で特徴的なのは、専任のシステム担当がいないことです。工場長か経営者が本業の傍らで進めるため、時間をかけられません。大企業向けの手順書にある「業務フロー図を全工程分作成する」といった進め方は、そのままでは現実的ではありません。

だからこそ、最初に決める範囲を絞る必要があります。

要件定義が膨らむ3つの原因

要件が手に負えない量になるのは、たいてい次の3つのどれかです。

要件が膨らむ3つの原因
原因 起きること 見分け方 対処
各部門の要望を足し算した 部門ごとの都合が総和になり、会社全体の最適から離れる 要件表が部門別の章立てになっている **業務の流れ順に並べ直す**。部門で切らない
「今できていること」を全部要件にした Excelの帳票をそのまま再現する要件が並ぶ 「現行と同じ」という記述が多い **なぜその項目が要るのか**を1件ずつ問う
将来やりたいことを今の要件に入れた 使う予定のない機能が必須要件に混ざる 「いずれ〜したい」という記述がある **時期を書いて別リストに分ける**

1つ目が最も多く、最も厄介です。 各部門に希望を聞くと、それぞれの部門にとっては正しい要望が返ってきます。しかしそれを足し算すると、会社全体では過剰な仕様になります。

判断は会社全体で行ってください。増やすべきは各部門の便利さではなく、会社全体で回る仕組みです。 部門の要望を1つ削ることで導入が2か月早まるなら、その2か月分の効果と比べて判断します。

「現場が回る最低限」の判定基準

要件を絞るには基準が要ります。次の問いに置き換えてください。

その機能がなかったら、明日の出荷は止まるか。

止まるなら必須、止まらないなら後回しです。単純ですが、部門間の議論をこの一点に集約できます。

もう1つ、判断が分かれたときの補助基準があります。

その機能がなかったら、案件ごとの利益が分からなくなるか。

生産管理システムを入れる目的が「忙しいのに利益が残らない」の解消であるなら、利益が見えなくなる機能は最低限に含まれます。 逆に、あれば便利だが利益の把握には影響しない機能は後回しにできます。

この2つの問いで仕分けると、要件は驚くほど減ります。

最低限の機能は5つ。受注から請求までの一本線

「現場が回る最低限」を具体化すると、受注から請求までが1本の線でつながっていることに行き着きます。

最低限つながっているべき一本線
受注を登録する
案件に工番を発行する
工番に対して工程の実績を記録する
工番に材料費・外注費・工数を集める
工番から請求する

この5つが途切れずにつながっていれば、現場は回り、案件別の利益も見えます。逆に、どこか1か所でも人が転記している箇所があると、そこでデータが切れます。

とくに重要なのが2番目の工番の発行です。要件定義で最初に決めるべきは、機能ではなく「何を管理の単位にするか」です。個別受注生産であれば、それは案件=工番になります。この単位が決まらないまま機能の議論を始めると、要件が発散します。工番の考え方は工番とは何かを整理した記事で扱っています。

必須要件と後回しにできる要件の仕分け例
機能 明日の出荷が止まるか 案件別の利益が見えなくなるか 判定
受注内容の登録と工番発行 **止まる** **見えなくなる** **必須**
工程の実績(誰が・どの工程に・何時間) 止まらない **見えなくなる** **必須**
材料費と外注費の工番への集約 止まらない **見えなくなる** **必須**
納期と進捗の一覧 **止まる** 見える **必須**
請求データの作成 **止まる** 見える **必須**
設備の稼働率の自動集計 止まらない 見える 後回し
スキルマップと力量管理 止まらない 見える 後回し
需要予測と自動発注 止まらない 見える 後回し
会計システムとのリアルタイム連携 止まらない 見える 後回し

後回しにしてよい機能

後回しにできる機能には共通点があります。入り口のデータが貯まっていないと、そもそも動かない機能だという点です。

  • 設備の稼働率の自動集計 工程実績が集まっていなければ計算できません。実績収集が先です
  • スキルマップと力量管理 誰がどの工程を何時間やったかの実績がなければ、評価の根拠が印象だけになります
  • 需要予測と自動発注 過去の実績が一定期間貯まってからでないと精度が出ません
  • 会計との連携 月次の集計値をCSVで渡す程度で足りる場合が多く、リアルタイム連携が要るのは受発注の量が多い場合に限られます

これらを初期要件に入れると、導入が遅れるだけでなく、動かない機能を抱えることになります。 実績が貯まってから第2段階として足すのが正しい順序です。

「連携が必要か」を判断するときは、機能の有無ではなく 「連携しない場合に二重入力が痛むのはどこか」を1か所特定してから要件に入れると、費用を抑えられます。

要件は動詞で書く。画面名で書かない

要件の書き方で結果が変わります。「〜の画面があること」と書かないでください。

書き方 何が起きるか
画面で書く 「工程進捗画面があること」 画面の有無で製品を判定してしまう。実際に運用できるかが分からない
動詞で書く 工程の担当者が、自分の作業の開始と終了を記録できること 誰が何をするかが決まる。 デモで実際にやってもらえば判定できる

動詞で書くと、主語(誰が操作するか)が必ず入ります。 ここが要件定義で最も見落とされる点です。

現場の作業者が操作する機能なのか、事務が操作するのか、経営者が見るだけなのかで、求められる使いやすさがまったく違います。主語が現場の作業者である要件は、入力にかかる時間を必ず書いてください。「1日3分以内で入力が終わること」のように書けば、デモで検証できます。

実績入力が続かない仕組みは、どれだけ機能が揃っていても使われません。入力の設計については作業日報を「作業記録」から「利益データ」に変えるにまとめています。

要件定義書に入れる4項目

体裁の立派な書類は要りません。A4で数枚あれば十分です。次の4つが入っていれば、製品選定の物差しとして機能します。

要件定義書に入れる4項目
項目 書く内容 これが無いと起きること
**解決したい経営課題** 「案件別の利益が決算まで分からない」など、1〜3個に絞る 機能の議論が目的から離れる。何を優先すべきか決められない
**管理の単位** 工番か、製番か、品番か。何に対して原価と進捗を集めるか **要件が発散する。** 製品ごとに前提が違うため比較もできない
**必須要件** 「明日の出荷が止まるか」「利益が見えなくなるか」で選んだもの。動詞と主語で書く 全部が必須になり、選定できない
**後回し要件と、その時期** 第2段階でやること。時期の目安も書く 将来の要望が今の必須要件に混ざる

1つ目の経営課題を1〜3個に絞ることが、この書類の価値を決めます。 課題が10個あると、機能の優先順位はつけられません。

製品を実際に比較する段階では、必須要件が満たせるかを実機で確認します。満たせない要件が出たときの扱い(運用で吸収する・カスタマイズする・要件を落とす)は生産管理システム導入手順のFit/GAP分析で扱っています。タイプ別の比較の観点は個別受注向け生産管理システム比較、選定全体の流れは中小製造業の生産管理システム選び方をご覧ください。

要件定義でやってはいけない3つ

現行業務をそのまま要件にする

Excelの帳票を1枚ずつ再現する要件を書くと、Excelの不便さごとシステムに移植することになります。「なぜこの項目が要るのか」を1件ずつ問い、答えられないものは落としてください。

長年続いている運用ほど、始めた理由が失われています。残す判断も落とす判断も、理由を言えることが条件です。

全部入りを目指して導入を遅らせる

要件を100項目にして完璧な製品を探すより、30項目で3か月後に動かすほうが利益は早く出ます。

年間で回収できる効果が仮に月20万円だとすると、導入が6か月遅れることの機会損失は120万円です。全部入りの検討にかけた時間そのものがコストになります。

さらに、段階導入には別の利点があります。第1段階の効果が数字で出てから、第2段階の投資を判断できることです。一度に全部入れると、どの機能が効いたのかが分かりません。

使う人を要件定義に入れない

現場の作業者が1人も参加していない要件定義は、ほぼ確実に失敗します。 入力の負担を実際に負う人が「これなら続けられる」と言っていない仕組みは、導入から3か月で形骸化します。

全員を集める必要はありません。入力の主語になる人を1人、要件のレビューに入れるだけで結果が変わります。

Factory Advance を要件定義の物差しとして使う

クラウド型の案件管理システム「Factory Advance」は、個別受注・多品種少量生産の中小製造業向けに、受注から工程、実績、請求までを工番で貫く設計になっています。前述の一本線がそのまま製品の構造になっているため、要件定義の物差しとして使えます。

  • 受注登録と工番の自動発行
  • 工程実績の収集(作業日報・QRコード打刻)
  • 材料費・外注費・工数の工番への集約と案件別の収益管理
  • 納期と進捗の一覧、請求データの作成

適している場面がはっきりしています。 紙とExcel中心で運用している、個別受注で多品種少量、案件別の利益が見えていない、外注と内製が混在している、20名以下で1品物や専用機製作が多い。逆に、量産が主で複雑な所要量計算が要る場合や、高度な工程スケジューリングが要件の中心になる場合は向きません。

要件定義の段階で「自社はどちら側か」を判断しておくと、製品選定で迷いません。工程管理の機能は工程管理機能のページにまとめています。

料金は環境構築費がスモールプラン20万円・スタンダードプラン40万円、月額費がスモールプラン3万円・スタンダードプラン5万円(いずれも税抜、2026年8月時点)です。スモールプランから始めて、実績が貯まってから機能を広げる進め方が、段階導入と相性のよい構成になっています。

要件を絞って早く動かしたい中小製造業の経営者・工場長は、Factory Advance 公式サイト、および製品紹介資料をご覧ください。

まとめ

要件定義は、要望を集める作業ではなく、優先順位をつける作業です。要点を整理します。

  • 要件が膨らむ最大の原因は各部門の要望を足し算すること。業務の流れ順に並べ直す
  • 判定基準は2つ。「明日の出荷が止まるか」「案件別の利益が見えなくなるか」
  • 最低限は受注 → 工番発行 → 工程実績 → 原価集計 → 請求の一本線。どこかで人が転記していればデータが切れる
  • 最初に決めるのは機能ではなく管理の単位。 個別受注なら工番。ここが決まらないと要件は発散する
  • 稼働率・スキル管理・需要予測・会計連携は後回しでよい。入り口の実績が貯まっていないと動かない機能だから
  • 要件は動詞と主語で書く。 画面名で書くと運用できるかが判定できない
  • 要件定義書はA4数枚でよい。経営課題は1〜3個に絞る
  • 30項目で3か月後に動かすほうが、100項目で完璧を目指すより利益が早く出る。 段階導入なら第1段階の効果で第2段階を判断できる
  • 入力の主語になる人を1人、要件のレビューに入れる

まず「明日の出荷が止まるか」で手元の要望リストを仕分けてみてください。必須に残る項目は、思っているより少ないはずです。

参考文献

投稿者プロフィール

尾畠 悠樹
尾畠 悠樹
株式会社イーポート 代表取締役

■ ITコーディネーター
■ キャッシュフローコーチ®
■ JRCA認定ISMS審査員補
■ 東京都中小企業向け
  デジタル技術導入促進ナビゲーター
■ 中小企業庁「みらデジ」デジタル化支援者

兵庫県出身。大学卒業後、外資系コンピューターメーカーを経て2008年に会社設立。業務用システムの受託開発及び中小製造業向けのパッケージの開発・販売を行う。