← 一覧に戻る

要約カード

JA 2026-03-12 23:00
JTBD製造業業務効率化

TechFusion社の生産管理システム化依頼。JTBDモデルが照らし出した、DXの本当の依頼人は誰か。

ROI事件ファイル No.441『紙の墓場に眠るジョブ』

JA 2026-03-12 23:00

ICATCH

紙の墓場に眠るジョブ


第一章:紙が積み重なる工場

「日報が、どこにあるか分からなくなることがあります」

TechFusion社の製造部長、田中誠一氏は、そう言いながら分厚いバインダーをデスクに置いた。生産ラインの日報、品質確認結果、設備点検記録——三十センチはあろうかという書類の束が、そこにある。

「当社は精密部品の製造を手がけており、現在約150名が工場に従事しています。生産ラインは六系統。毎日、各ラインの担当者が手書きで日報を記入し、それを品質管理部門が回収して確認する。この運用を、二十年以上続けてきました」

「問題が起きたのはいつからですか」と私は尋ねた。

田中氏が少し間を置いた。「去年の秋です。品質クレームが発生した際、原因を追跡しようとしたのですが、関係する日報が見つかるまでに三日かかりました。その間、顧客への報告が遅れ、取引関係に傷がついた」

「DX推進が会社のテーマになった背景には」とClaudeが確認した。「そのクレーム対応の遅れがあったわけですね」

「ええ。ただ——」田中氏は声を落とした。「経営層は『デジタル化しろ』と言います。しかし現場の担当者は、今の紙の運用に慣れています。新しいシステムを入れても、使ってもらえないのではないかという不安があって」

その言葉が、事件の核心を指していた。依頼の表面には「システム化」という言葉があった。しかし本当の問題は、もっと別の場所に埋まっているように見えた。

第二章:ジョブの正体

「まず、ROI Polygraphで現状のデータを整理させてください」

Geminiがノートパソコンを開き、TechFusion社から事前に提供された業務フローのデータをROI Polygraphに入力し始めた。このツールは、数字と業務フローの矛盾を可視化するために私たちが日常的に使っている分析装置だ。

「興味深い数字が出ました」とGeminiが画面を指した。「日報の記入に要する時間は、一人あたり一日平均二十分。六系統、各ライン担当者が三名として、一日の記入工数は合計三百六十分——六時間です。しかしその情報が、翌日の生産判断に使われているケースは全体の十八パーセントに過ぎない」

「つまり」と私が引き取った。「日報は書かれているが、活かされていない。情報は存在するが、死んでいる」

田中氏が目を見開いた。「言われてみれば——日報を書くことが目的になっていたかもしれません」

「ここで、JTBD——ジョブ理論を使います」とClaudeが立ち上がり、ホワイトボードに向かった。

「JTBDとは、Job To Be Doneの略です。人は製品やサービスを購入するのではなく、ある『ジョブ』を片付けるために雇用する、という考え方です。TechFusion社がシステムを導入したい本当の理由——つまり、片付けたいジョブは何でしょうか」

「品質クレームへの迅速な対応、でしょうか」と田中氏が答えた。

「それは結果です」とClaudeが続けた。「ジョブをもう一段深く掘り下げると——『問題が起きた時に、原因を即座に特定できる状態にしたい』。これが機能的ジョブです。そしてその背後には、『経営層に言われる前に、現場で問題を解決できているという自信を持ちたい』という感情的ジョブがある」

田中氏がゆっくりと頷いた。「その通りです。去年のクレームの後、私は経営層に呼ばれました。あの経験はもうしたくない」

「だとすると」と私が整理した。「導入すべきシステムの要件が変わります。単なる日報のデジタル化では不十分です。必要なのは、異常が発生した瞬間に、過去データと照合して原因を浮かび上がらせる仕組みです」

第三章:三つのジョブを一枚に

Claudeがホワイトボードに三つの層を描いた。

[機能的ジョブ:データを探せる状態にする]

「第一層は、最もシンプルな機能的ジョブです」とClaudeが説明した。「日報と品質記録をデジタル化し、キーワードや日付で即座に検索できる状態にする。これだけで、去年のクレーム対応で三日かかった原因追跡は、数分に短縮されます」

「具体的なKPIとしては」とGeminiが補足した。「クレーム発生時の原因特定リードタイムを、現在の平均二・八日から四時間以内に短縮することを目標にしてください」

[感情的ジョブ:現場が主体的に動ける状態にする]

「第二層が、田中さんが本当に解決したかったジョブです」とClaudeが続けた。「現場担当者が、入力した日報がリアルタイムで品質管理部門に共有され、異常の兆候があれば即座にアラートが届く。これにより、問題が大きくなる前に現場が自分たちで対処できる」

「これは重要な設計思想の転換です」と私が強調した。「日報は『報告書』から『センサー』に変わる。現場が受け身から主体になる」

田中氏の表情が変わった。「それができれば——現場のモチベーションも変わりますね。今は書いても何も変わらないから、形式的になっている」

[社会的ジョブ:DXの成功事例として社内で証明する]

「第三層は」とGeminiが指摘した。「見落とされがちですが重要です。TechFusion社はDX推進を会社のテーマにしている。つまり、このプロジェクトが成功すれば、他部門への展開モデルになる。最初から『横展開できる設計』を意識することが、投資対効果を大きく左右します」

「ROI Proposal Generatorで試算してみましょう」と私が提案し、ROI Proposal Generatorを開いた。入力した数字——日報工数の削減、クレーム対応コストの削減、品質向上による不良率低減——から弾き出された数字は、初期投資の回収期間が十四ヶ月という試算だった。

「横展開で六系統から全工場に広げると」とGeminiが付け加えた。「回収期間はさらに九ヶ月に縮まります」

第四章:ジョブが目覚める朝

田中氏は、三層のジョブを書き写しながら深く頷いた。

「私は『システムを入れること』がゴールだと思っていました。しかし本当のジョブは、現場が自信を持って問題に向き合える環境を作ることだったのですね」

「JTBDの本質は」と私が応じた。「手段と目的を混同しないことです。デジタル化はジョブではない。ジョブを片付けるための手段に過ぎない。この順序を間違えると、誰も使わないシステムを作って終わります」

「現場担当者が新システムに抵抗する理由も」とClaudeが付け加えた。「彼らの感情的ジョブが満たされていないからです。『自分が入力したデータが、何かの役に立っている』という実感——それがなければ、どんなに便利なシステムでも形骸化します」

「まずパイロットとして」とGeminiが提案した。「一系統のラインで三ヶ月間、デジタル化を試験運用してください。機能的・感情的・社会的、三つのジョブが満たされているかを、週次で担当者にフィードバックを取りながら確認する。その結果を持って、残り五系統への展開を判断してください」

田中氏が立ち上がり、深く頭を下げた。「ありがとうございます。来週、現場の担当者を集めてジョブの話から始めます」


五ヶ月後、TechFusion社から報告が届いた。

パイロットを経て全六系統にシステムを展開。クレーム発生時の原因特定リードタイムは平均二・八日から三時間四十分に短縮。品質記録のデジタル化により、不良品の発生パターンが可視化され、月次の不良率が導入前比で二十三パーセント改善した。

しかし田中氏が最も価値を感じたのは、数字の外にあった。現場担当者の一人が、自ら異常の兆候に気づき、ラインを止める判断を下したのだ。そのラインを止めなければ、百万円超の不良品が発生していた可能性があったという。

田中氏は報告書の末尾にこう記していた。「現場が変わりました。日報を書くことの意味が変わったからだと思います。データが生きている、という実感が、人を変えるのだと気づきました」

紙の墓場に眠っていたジョブが、ようやく目を覚ましたのだ。

「システムを導入することは、ジョブではない。人がある状況において片付けたい仕事——それがジョブだ。JTBDが問うのは、機能的・感情的・社会的という三層のジョブを、設計の出発点に置けるかどうかだ。手段から始めると、誰も使わないシステムが生まれる。ジョブから始めると、現場が自ら動き出す仕組みが生まれる。その違いは、投資額ではなく、問いの順序にある」


関連ファイル

jtbd

使用ツール

事件の概要をお聞かせください