Ch5 02: フィッシャープライスからデジタルへ#

テスラのライン末端品質追跡システムの初期バージョンは――控えめに言っても――原始的だった。

生産ラインの末端にいる作業員が一台一台を検査し、問題箇所にカラーステッカーを貼っていた。赤は重大欠陥。黄色は軽微な問題。緑は合格。ステッカーは物理的なもの――実際の粘着ラベルを実際の車に貼り付けていた。追跡システムは、ラインスーパーバイザーのステーションの横にあるホワイトボードで、ホワイトボードマーカーで手書き更新されていた。

もしあなたがその現場に足を踏み入れてこの仕組みを見たら、ここは1兆ドル規模のテクノロジー企業なのか、それとも幼稚園の工作教室なのかと首をかしげたかもしれない。道具はまるでフィッシャープライスのおもちゃのようだった。

まさに、それが狙いだった。

特にテクノロジー主導の組織では、最初から使える最も高機能なツールを導入したいという強い誘惑がある。品質管理が必要？デジタルシステムを構築しよう。生産監視が必要？センサーを設置しよう。データ分析が必要？機械学習を導入しよう。前提はこうだ――優れたツールが優れた成果を生む、と。

時にはその通りだ。しかしより多くの場合、優れたツールが生み出すのは見栄えの良いダッシュボードであり、それが理解の浅さを覆い隠してしまう。ツールが複雑さを処理するため、人間はその複雑さと格闘する必要がなくなる。そして人間が複雑さを理解していなければ、ツールの出力がどれほど精密であっても、適切に解釈し、疑問を投げかけ、改善することはできない。

テスラのカラーステッカー方式は、その逆を強制した。すべての欠陥を人間の目で確認しなければならなかった。すべてのステッカーは、車を見て、問題を発見し、その深刻度を判断した人が貼らなければならなかった。ホワイトボードの更新は、誰かが実際にそこまで歩いていき、マーカーを手に取り、書き込むことを意味した。

遅い？もちろん。労力がかかる？間違いなく。恥ずかしいほどローテク？疑いの余地なく。しかしこの方式は、あの段階ではどんなセンサーアレイにも実現できなかったものを生み出した――何が壊れているのか、なぜ壊れるのかについての、深い人間的理解だ。

ステッカー運用を数週間続けると、パターンが浮かび上がってきた――データベースの中にではなく、人々の頭の中に。ラインスーパーバイザーたちは、直接の観察から、どのステーションが最も多くの赤ステッカーを出しているかを知っていた。どのシフトで欠陥率が高くなるかを知っていた。どの特定の問題がクラスター化し、共通の根本原因を示唆しているかを知っていた。彼らが築いたのは、私が手動認知資本と呼ぶもの――直接的な関与からしか得られない、プロセスに対する実践的・経験的な理解だった。

この認知資本こそがステッカーフェーズの真の成果物だった。ステッカーは単なる手段に過ぎない。重要だったのは、チームがすべての車を目視確認し、すべての欠陥について考え、生産ラインが実際にどう動いているかの直感的モデルを構築することを余儀なくされたことだ。

チームがやがてステッカーに代わるデジタルシステムを設計したとき、あらゆる設計判断がその直感的モデルに基づいていた。センサーの配置は恣意的ではなかった――チームが欠陥の発生確率が最も高いと分かっている場所を反映していた。アラートの閾値は工場出荷時のデフォルトではなかった――意味のある逸脱とは何かについてチームが苦労して得た感覚を反映していた。ダッシュボードのレイアウトは汎用テンプレートではなかった――ラインスーパーバイザーたちが数週間の手動観察を通じて最も必要だと学んだ情報を表示していた。

デジタルシステムは優れていた。しかしそれが優れていたのは、ステッカーフェーズがあったからこそであり、ステッカーフェーズがあったにもかかわらずではない。

これが、あらゆる自動化の取り組みに対して私が推奨するプロセスだ――まず物理的な可視化、次にデータ収集、そして自動化。

フェーズ1：見える化する。 何かをデジタル化する前に、情報を物理的に観察可能にする。付箋、ホワイトボード、カラータグ、空間的な整理――プロセスの現状を肉眼で見えるようにするものなら何でもいい。目的は効率ではない。理解だ。自分自身とチームに、ソフトウェアを仲介させずにプロセスと直接向き合い、そのパターンと失敗を見ることを強いるのだ。

フェーズ2：記録を始める。 パターンが明確になったら――直接の経験から何が起こりなぜそうなるかを説明できるようになったら――データの収集を始める。スプレッドシートで十分だ。シンプルなデータベースで十分だ。目標は、すでに定性的に理解しているパターンの裏付けとなる数字を得ることだ。このフェーズで、あなたのメンタルモデルをハードデータで検証する。

フェーズ3：安定した部分を自動化する。 定性的理解と定量的データの両方を手にしたら、プロセスの中で最も安定し、最も予測可能で、人間の判断への依存が最も低い部分を特定する。そこからまず自動化する。複雑で変動が大きく、判断を要する部分は――当面は――人間に任せる。

フェーズ4：自動化を段階的に拡大する。 自動化された各要素が実証されたら、次に適した作業へ自動化を広げる。各拡張は前のフェーズのデータに基づき、チームの理解によって検証される。プロセスは、一部自動化された手動中心の状態から、重要なノードに人間の監視を残した自動化中心の状態へと進化する。

ローテクから始めることの利点は、理解を深めるだけにとどまらない。同様に重要なものも生み出す――学習データだ。

あらゆる手動作業は、実世界のデータを生み出す。車に貼られたすべてのステッカーは、欠陥の位置、種類、頻度に関するデータポイントだ。ホワイトボードの更新はすべて、タイムスタンプ付きの生産状況の記録だ。このデータが――たとえ非公式にでも――収集されれば、自動化システムのロジックの土台となる。

例えば機械学習モデルは、機能するために学習データを必要とする。そのデータは実世界の混沌を反映していなければならない――教科書通りのプロセスだけでなく、例外だらけで回避策に満ちた現実を。手動作業はまさにこの種のデータを生み出す。なぜなら、すべてを捕捉するからだ――通常の稼働、エッジケース、故障、即興の修正。理論的な前提に基づいて設計された自動化システムには、このようなデータセットがない。設計者が予想しなかった状況に初めて遭遇したとき――実世界の運用では日常的に起こることだが――システムは行き詰まるだろう。

手動フェーズは、3つの異なる資産を同時に生み出す。

サービスのアウトプット。 仕事が完了する。車が検査される。顧客にサービスが提供される。収益が生まれる。手動フェーズはコストセンターではない――他の2つの資産をたまたま生み出す、生産的な事業活動なのだ。

プロセスの理解。 チームは直接的な接触を通じて、プロセスが実際にどう機能するかを学ぶ――設計通りに機能しないすべての側面も含めて。この理解が、自動化システムの設計インプットとなる。

学習データ。 あらゆる手動作業が、自動化システムの学習・調整・検証に使える実世界の状況の記録を生み出す。

手動フェーズを飛ばせば、3つすべてを失う。プロセスを理解せず、実世界のデータもなく、手動運用が稼いでくれたはずの収益もないまま、自動化システムを設計することになる。

ガイダンス#

プロセスの自動化を準備しているなら、テクノロジーの誘惑に抗おう。代わりに観察から始めよう。

1週目：手動で行う。 想像できる最もシンプルなツールを使って、プロセスを完全に手作業で実行する。物理的なマーカー、紙のフォーム、ホワイトボード。目標は効率ではない――気づきだ。
2週目から4週目：パターンを観察する。 何が失敗するか？何が変動するか？何が判断を要するか？何が退屈なほど予測可能か？予測可能なものが自動化の候補リストだ。変動するものは、準備が整うまでもっと手動で繰り返す必要がある。
2ヶ月目：記録を始める。 体系的にデータを収集する――スプレッドシート、シンプルなフォーム、基本的な指標。自動化システムの設計に使うデータセットを構築しているのだ。
3ヶ月目以降：1つだけ自動化する。 プロセスの中で最も安定し、最も予測可能なタスクを1つ選び、それを自動化する。1サイクル完全に稼働させる。デバッグする。安定させる。そして次のタスクを選ぶ。

フィッシャープライスからデジタルへの道は回り道ではない。実際に機能する自動化にたどり着く唯一の道だ。なぜなら、その代わりに――お金で買える最も洗練されたシステムから始めるという選択肢は――洗練されていて、高価で、間違ったシステムを与えるからだ。

醜くても始めよう。エレガントに仕上げよう。醜いフェーズで築いた理解こそが、エレガントなフェーズを可能にするのだ。