メインコンテンツへスキップ
    コラム一覧に戻る
    AI + 人間編集

    自動化の前にやるべきこと:物と情報の流れを整理する

    板野光司
    12分で読めます
    製造DX

    自動化の前にやるべきこと:物と情報の流れを整理する

    「この業務、AIで自動化できませんか?」

    製造業のDX推進者や業務改善担当者から、最も多くいただく相談のひとつです。AIやRPAへの期待は年々高まっており、「自動化すれば楽になる」「人手不足を解消できる」という声は切実です。

    しかし、自動化プロジェクトの多くが期待した効果を出せずに終わります。その原因は、技術の問題ではありません。「何を自動化するか」の選定を間違えているのです。

    見かけ上やりやすいところ、つまり「Excelの転記作業」や「定型メールの送信」など目につく作業から手をつけがちです。ところが、その作業自体がそもそも不要だったり、前後の工程に問題があったりすると、自動化しても全体の効率は上がりません。むしろ、不要な工程を高速に回す「きれいなムダ」 が生まれるだけです。

    自動化そのものが悪いわけではありません。順序が大事なのです。

    本記事では、自動化の前にやるべき「物と情報の流れの整理」について、トヨタ生産方式(TPS)の思想と実例を交えながら、4段階のアプローチで解説します。


    TPSにおける「流れ」の思想

    大野耐一が最初にやったのは「流れをつくること」

    トヨタ生産方式(TPS)の生みの親である大野耐一氏は、著書『トヨタ生産方式 ―脱規模の経営をめざして―』(ダイヤモンド社、1978年)のなかで、生産の本質は「物の流れ」であることを繰り返し説いています。

    大野氏がトヨタの機械工場で最初に取り組んだのは、機械を加工工程の順に並べ替えて「流れ」をつくることでした。当時の工場では「旋盤は旋盤工、フライス盤はフライス盤工」と、機種ごとに職人が固定され、同種の機械をまとめて配置する「機能別レイアウト」が常識でした。大野氏はこの固定化された体制を打破し、一つの製品が流れるように加工できる順序に機械を並べ替えたのです。昭和22年(1947年)には機械をニの字型やL字型に配置し、一人の作業者が2台の機械を受け持つ「2台持ち」を試みました。これが後の「多工程持ち」へと発展し、TPSの基盤のひとつとなりました。

    大野氏が「流れ」にこだわった背景には、当時の工場に蔓延していた**「でかんしょ生産」** の問題がありました。月の前半は部品が揃わず組立てに着手できず、月末になって一気に追い込む。この波のある生産パターンでは、月末に残業が集中し、品質も安定しません。大野氏はこの問題を「流れが途切れている」ことの表れと捉え、工程間の同期と平準化を追求しました。これが後のTPSにおける平準化生産の出発点です。

    さらに重要なのが、物の流れの方向を逆転させた発想です。従来の生産方式では「前工程が後工程へ物を供給する」のが当たり前でした。大野氏はこれを逆転させ、「後工程が前工程に引き取りに行く」 という仕組みを考案しました。前工程は後工程が引き取った分だけ補充生産する。これにより、つくりすぎのムダが抑制され、工程間に必要以上の在庫が滞留しなくなります。この発想の転換がジャスト・イン・タイム(JIT)の基盤となり、「かんばん」はその運用手段として生まれました。

    つまり、TPSの出発点は「ツールの導入」ではなく、「流れを理解し、流れをつくること」 だったのです。

    「物と情報の流れ図」はTPSの事技系展開で使われている手法

    TPSは工場の生産ラインで生まれた思想ですが、その適用範囲は製造現場に留まりません。事務・技術系(事技系)の業務にもTPSを展開する取り組みが、トヨタ社内で進められています。

    事技系の業務改善で中心的に使われる手法が、「物と情報の流れ図」 です。これは、対象業務のなかで「物(データ、帳票、成果物)」と「情報(指示、依頼、承認)」がどのように流れているかを一枚の図に可視化するものです。英語では「Value Stream Mapping(バリューストリームマッピング)」とも呼ばれ、リーン生産方式の文脈で世界的に普及しています。

    トヨタの実例:メーター開発のリードタイムを120日から35日へ

    Toyota Timesで紹介されている事例が、この手法の威力を示しています。

    トヨタの事技系TPS自主研において、メーター開発業務のリードタイムを120日から35日に短縮した取り組みが報じられています。この改善で最初にやったのは、やはり**「物と情報の流れ図」による問題の可視化**でした。

    開発業務の全工程を流れ図に落とし込み、各工程の所要時間・待ち時間・手戻りの発生箇所を見える化した結果、「仕事をしている時間」よりも「待っている時間」が圧倒的に長いことが明らかになりました。問題は個々の作業の遅さではなく、工程間の「流れの悪さ」にあったのです。

    この事例で注目すべきは、最初に着手したのがツールの導入でも作業の高速化でもなく、流れの可視化だったという点です。問題の構造を正確に把握してから改善策を打つ。これがTPSの基本であり、自動化を考える際にも同じアプローチが有効です。

    (参照:Toyota Times「本気ですか?」仕入先の一言に応えた"本気のTPS" https://toyotatimes.jp/spotlights/032.html


    自動化を成功させる4段階アプローチ

    自動化を成功させるには、「いきなり自動化する」のではなく、以下の4段階を踏むことが重要です。

    段階1:物と情報の流れを見える化する

    最初にやるべきことは、対象業務の流れを一枚の図にすることです。

    具体的な手順:

    1. 対象業務の始点と終点を決める — 例えば「受注から出荷指示まで」「図面依頼から検査成績書の発行まで」のように、範囲を明確にする
    2. 関係者を洗い出す — その業務に関わる人・部署・システムをすべてリストアップする
    3. 物(データ)の流れを追う — どこでデータが作られ、誰に渡り、何に使われているかを時系列で追跡する。「このExcelファイルは誰が作って、誰に送って、相手は何に使っているのか」を一つひとつ確認する
    4. 情報(指示・承認)の流れを追う — 作業指示、承認依頼、確認連絡がどのように流れているかを追跡する
    5. 各工程の所要時間と待ち時間を記録する — 実際に作業している時間と、次の工程に進むまでの待ち時間を分けて記録する

    書き方のポイント:

    流れ図には、以下の要素を含めます。

    • 入力(Input): その工程に入ってくるデータや物
    • 処理(Process): その工程で行われる作業の内容
    • 出力(Output): その工程から出ていくデータや物
    • 判断(Decision): 分岐が発生するポイント(合否判定、承認/差戻しなど)
    • 待ち時間(Wait): 次の工程に進むまでの滞留時間

    最初から完璧な図を目指す必要はありません。まずは現場の担当者に聞き取りをしながらラフに書き、徐々に精度を上げていくのが実践的です。重要なのは、業務の全体像を一枚で見渡せる状態をつくることです。

    ここで多くの場合、驚くべき発見があります。「この帳票、誰も見ていないのにずっと作り続けていた」「この承認プロセス、3人が同じ内容を確認している」「この工程の待ち時間が全体の70%を占めている」といった事実が浮かび上がります。

    段階2:不要な工程を先に削除する

    流れを可視化したら、次にやるべきは自動化ではなく、不要な工程の削除です。

    各工程に対して「なぜこの工程が必要なのか」を問いかけます。ここで有効なのが、TPSでおなじみの**「なぜなぜ分析」(なぜを5回繰り返す)** です。

    例:受注情報の転記作業

    • なぜ転記しているのか? → 受注システムと生産管理システムが連携していないから
    • なぜ連携していないのか? → 導入時期が違い、データ形式が異なるから
    • なぜデータ形式が異なるのか? → 各システムの導入時に全社統一の設計方針がなかったから

    この場合、「転記作業をRPAで自動化する」のも一つの手ですが、そもそもシステム間のデータ連携を実現すれば転記作業自体が不要になる可能性があります。不要な工程を自動化しても、ムダを高速に回すだけです。

    削除の判断基準:

    • その工程の成果物を、誰が、何の目的で使っているか — 使う人がいない成果物を作る工程は削除できる
    • 同じ情報を複数箇所で入力・確認していないか — 重複工程は統合できる
    • 過去の問題への対策として追加された工程が、今も必要か — 環境が変わって不要になっている場合がある
    • 承認・確認のステップが過剰でないか — リスクに対して承認者が多すぎる場合は簡素化できる

    段階3:残った工程を効率化する

    不要な工程を削除した後、残った工程について「人間にもAIにも扱いやすい形」に整えます。

    この段階でとくに重要なのが、データのフォーマット標準化です。

    製造業の現場では、Excelファイルが業務の中核を担っていることが多いですが、そのExcelファイルが「人間が見るための体裁」に最適化されていて、「データとして扱う」ことが困難な状態になっていることが少なくありません。

    総務省が公開している統計表のガイドライン(「統計表における機械判読可能なデータの表記方法の統一ルール」)では、機械判読可能なデータの基本原則として以下のような項目が挙げられています。

    • 1セル1データ — 1つのセルに複数の情報を詰め込まない
    • セルの結合をしない — 結合セルはプログラムからの読み取りを困難にする
    • 数値と単位を分離する — 「100個」ではなく、数値列に「100」、単位列に「個」と分ける
    • データの配置は縦持ち(1行1レコード) — 横に展開するピボット形式は分析に不向き

    (参照:総務省「統計表における機械判読可能なデータの表記方法の統一ルール」 https://www.soumu.go.jp/main_content/000723626.pdf

    これは統計表のルールですが、製造業の社内帳票にもそのまま適用できる考え方です。検査記録、在庫管理表、生産日報など、日常的に使っているExcelファイルを「データとして扱える形式」に整えることが、後の自動化を円滑にする基盤になります。

    効率化のポイント:

    • 入力インターフェースの改善 — 自由記述をプルダウン選択やチェックボックスに変える。入力のばらつきを減らし、データ品質を向上させる
    • 命名規則の統一 — ファイル名、フォルダ構成、項目名を統一する。「検査成績書_20260407.xlsx」「検査成績書(最新).xlsx」「検査成績書_v2_final.xlsx」が混在する状態を解消する
    • マスターデータの整備 — 品番、工程名、不良区分などのマスターを一元管理し、各帳票から参照する仕組みをつくる

    段階4:部分的に自動化する

    ここまで来て、ようやく自動化の段階です。そして、ここでも「一気にやらない」ことが重要です。

    段階的自動化の原則:

    1. 効果が大きく、リスクが小さい工程から始める — 定型的な転記作業、集計処理、通知メールの送信など、ルールが明確で例外が少ない業務が最適
    2. 小さく始めて効果を確認する — 1つの工程を自動化し、実際にどれだけ時間が削減されたか、エラーが減ったかを数値で確認する
    3. 現場に定着してから次に進む — 自動化したプロセスを現場の担当者が理解し、問題発生時に対応できる状態になってから、次の工程に着手する
    4. 例外処理のルールを先に決める — 自動化は「正常系」を対象にする。イレギュラーケースの処理ルールを事前に決めておかないと、例外発生のたびに業務が止まる

    自動化手段の選定基準:

    • ルールベースの定型処理 → RPA、Excelマクロ、スクリプト
    • 判断を伴う処理(分類、異常検知) → AI(機械学習モデル)
    • システム間のデータ連携 → API連携、ETLツール
    • 文書の読み取り・構造化 → AI-OCR、自然言語処理

    重要なのは、ツールの選定は最後だということです。「RPAを導入したいのですが」「ChatGPTで何かできませんか」という相談をよくいただきますが、ツールはあくまで手段です。まず課題を特定し、その課題に最適な手段を選ぶ。この順序を間違えると、ツールに振り回される結果になります。


    やりがちな間違い

    自動化プロジェクトで頻繁に見られる典型的な間違いを整理します。

    間違い1:ツール選定から始める

    「RPAツールを比較検討しています」「AIプラットフォームの選定をお願いしたい」という相談は多いですが、ツールの選定は本来、課題の特定→業務フローの可視化→改善方針の決定の後に行うべきステップです。

    ツールから入ると、そのツールで「できること」に業務を合わせようとする本末転倒が起きます。大野耐一氏が「かんばんはTPSの手段であって目的ではない」と戒めたのと同じ構造です。

    間違い2:全工程を一度に自動化しようとする

    「どうせやるなら全部自動化したい」という気持ちは理解できますが、これは最も失敗確率の高いアプローチです。

    全工程を同時に自動化すると、問題が発生したときにどこが原因か特定できません。また、開発期間が長期化し、その間に業務自体が変わってしまうリスクもあります。TPSの「1個流し」の思想と同様に、1つの工程を確実に改善してから次に進むのが正しいアプローチです。

    間違い3:現場の声を聞かずにIT部門だけで進める

    IT部門やDX推進室が主導してシステムを構築し、現場に「使ってください」と渡す。これは、自動化が定着しない最大の原因です。

    業務フローの可視化の段階から現場の担当者を巻き込むことが不可欠です。実際に手を動かしている人しか知らない「暗黙のルール」「例外処理の実態」「本当のボトルネック」は、業務マニュアルやシステム仕様書には書かれていません。

    流れ図を現場の人と一緒に書く。この工程自体が、現場と改善推進者の間の共通認識をつくるプロセスになります。

    間違い4:効果を測定しない

    「自動化しました。便利になったと思います」で終わらせてしまうケースです。自動化前後で、処理時間・エラー率・手戻り回数など、具体的な指標で効果を測定しなければ、投資に見合う改善ができているか判断できません。

    段階1で流れ図を作る際に各工程の所要時間を記録しておくのは、この効果測定のためでもあります。


    まとめ:流れを理解してから、自動化する

    本記事で提案した4段階のアプローチを改めて整理します。

    段階やること目的
    1. 見える化物と情報の流れ図を作成する業務の全体像と問題点を把握する
    2. 削除不要な工程をなぜなぜ分析で特定し、削除する自動化対象を本当に必要な工程に絞る
    3. 効率化データフォーマットの標準化、入力方式の改善自動化しやすい状態を整える
    4. 自動化効果が大きくリスクが小さい工程から段階的に自動化する確実に成果を出し、定着させる

    大野耐一氏が『トヨタ生産方式』で説いたように、改善の出発点は「流れをつくること」にあります。機械を工程順に並べ替え、でかんしょ生産を平準化し、後工程引き取りで在庫を減らす――すべて「流れを理解し、整える」ことから始まりました。自動化の出発点もまた同じです。

    トヨタの事技系TPS自主研がメーター開発のリードタイムを120日から35日に短縮できたのは、最初に「物と情報の流れ図」で問題構造を可視化したからです。流れが見えれば、どこにムダがあるか分かる。ムダが分かれば、削除すべきものと改善すべきものを正しく判断できる。その上で自動化すれば、効果は確実に出ます。

    自動化は強力な手段です。しかし、その力を正しく発揮するためには、「何を自動化するか」を見極める前工程が欠かせません。

    まずは、目の前の業務の「物と情報の流れ」を一枚の図に書いてみてください。それが、自動化を成功させる最初の一歩です。


    参考文献


    外観検査プログラム作成や検査条件の検討を進めたい方は、インダストリエイトのVisual Inspection AI Agentをご覧ください。サンプル画像と検査仕様をもとに、外観検査プログラム草案の生成方法を確認できます。AI導入の投資対効果を試算したい方はROI計算ツールもご活用ください。