Contents

トヨタ生産方式

DX という言葉に飛びつく前に、まず知的労働者が知っておくべき概念がある──トヨタ生産方式だ。

/images/tps.jpg

みんなの心の声が聞こえてくる。

「トヨタ?よく知ってるよ。 でも自分の仕事は製造業じゃないから関係ない。DX の話しようよ。」

そうじゃない。 ここには、効果的な価値づくりのエッセンスが詰まっているんだ。 知的労働者であるぼくらにとっても、自分ごととして学ぶ価値がある。

トヨタ生産方式(TPS)はいくつかの原則からなっており、中でも重要な位置を占めているのが「徹底的なムダの排除」だ。 一言に無駄の排除と言っても、TPS ではその解像度がすこぶる高い; 単に「無駄遣いはやめましょう」という程度の話ではないんだ。 TPS を学べば、知的労働の現場においても多くのムダがあることがわかるようになるだろう。

見えない負債の蓄積

TPS のストイックなやり方は、直感的には効率が悪いとさえ思うかもしれない。 なにせ工場のラインに異常が見つかったら、紐を引いて全てのラインを停止させるんだ。 「常識」的に考えれば、ある工程に問題があった場合にで下流工程が動き続けられるよう、ある程度のバッファが欲しい気がする。 しかしこのような短絡的な防御策──言ってみれば甘え──が積み重なることで、システム全体には多くの見えない負債が蓄積することになってしまう。

TPS では流れているコンベアそのものが、社内のどこにも異常がないことの証明となる。 もちろん、その時点において不良として認識されていない特徴をもった部品は流れていってしまうわけだが、言ってみればそれはソフトウェアのバグと同じだ。 組織としての「不良」の定義と、動く現場の状況とが常に一致している──これは、気の遠くなるような努力の結果として得られる大きなメリットだ。

作りすぎの無駄

「作りすぎのムダ」という概念をつくったことも、TPS の大きな貢献だ。 前述の「バッファ」は明らかな作りすぎだし、視野の狭い生産性向上も作りすぎのムダにつながる。

自動車の生産と聞くとつい、コンベアをおびただしい数の車が流れ、作業員は延々と同じ作業をしているところを想像するかもしれない。 これは半分あたっているけれど、半分は間違っている。 トヨタのコンベアには、いろいろな車種が入り乱れて流れている。 まとめて流さないことで、ひとつの車種だけが作られすぎる: つまりバッファが生じることを避けているんだ。 もちろん、コンベア上を流れる各車種の割合は、それぞれの販売実績に応じて決定される。 極端な話、販売店でプリウスが 1 台売れたら、1 台分のプリウスの生産が始まるってことだ。

バッファを根絶しようとするトヨタのこだわりはなみなみならぬもので、 ランダムな要素が関与するプロセス──例えば、回転部品の微細な重量バランスを調整するための金属片の生産量──においても、過去の使用頻度データをもとに、できるだけ在庫を持たないようにする (大野 1978)。

トヨタの理想は「ジャスト・イン・タイム」。 作ったものは全て、生産が完了するとともに次の工程に引き取られるべきという考え方だ。 ストイックなジャスト・イン・タイムを追求することで、バッファを少なく抑えたまま、生産性を向上させられるわけだ。

ぼくらの仕事との関係

ここで、トヨタ生産方式を、よくある知的労働者の仕事に置き換えてみよう。 例えば図のようなフローだ。 (csv 形式で保存されたデータを Excel ファイルで集計・グラフ化し、そのデータを Word に(参照していればセーフ。値貼り付けしたらアウト) -> Word -> pdf)

明らかに、このフローはバッファだらけだ。 データの修正や要件の変更などでプロジェクトが複雑になると、すぐに負債が貯まるだろう。 ある部分を変化させたときに、それに追従して動かない部分は全てバッファだ。 視野をこのシステム内に限定しても、バッファは 2 箇所ある: Excel に集計するところと、Word を作っているところだ1。 バッファという言葉が表すように、Excel への集計や図表のレイアウト調整をどれだけ頑張ったところで、成果物は古いままだ。 業務システム内にこのようなバッファがあると、單純にバージョン管理の対象が増えるだけでなく、バージョンの整合性にも注意を払う必要が出てくる。 「作りすぎムダ」と「工程のムダ」は、本質と無関係な複雑さを、プロジェクトにもたらしてしまうんだ。

TPS 的に作り変えるなら、この業務システムは、フローのどこか──csv や計算過程、文章など──を変更したらそれが即座に PDF に反映されるものになる。 実は、これを可能にする方法はすでにある。 カジュアルな HTML ファイルでよければ、JupyterLabJupyter notebook で充分だろう; 40 以上のプログラミング言語に対応しているので、ノンプログラマが困ることはないはずだ。 ただし、文章中に数値の埋め込みをしたいのであれば Rmarkdown のほうがよいだろう。 もともと R 言語のために開発されたシステムではあるが、最近は Python との連携が充実してきたため、ノンプログラマの仕事にもフィットするはずだ。 紙媒体の報告書が必要で、しかも体裁を細かく調整したいなら、LaTeX を使うといい。 いずれもドキュメントを生成するためのシステムだが、要するに、目的に応じて選定する必要があるということだ。

これらの文書生成システムは、ソースファイルに不具合があるとすぐにエラーとなってしまい、文書の生成ができなくなってしまう。 そんなことでは実戦投入はとうてい無理と思われるかもしれないが、それは違う。 この「潔癖さ」こそが重要なのだ。 些細な間違いですぐ停止するシステムは、異常を発見したらすぐにラインを止める TPS の手法にも似ている。

電子ファイルは簡単に作ることができるが、きちんと設計しないと、バッファなって業務の流れを滞らせてしまう。 僕ら知的労働者は自動車を作っているわけではないけれど、業務の設計において TPS の哲学から学べることは大きい。 今の業務の流れを、いま一度設計してみてはどうだろう。

やってみよう!

  1. いまの業務フローを、図で描き表してみよう。
  2. その業務は最終的に何を成し遂げることを目的にしているのかを、フローのゴールに書いてみよう。
  3. 各ステップに「つまり何をやっているのか」の名前をつけてみよう。どうしてその工程が必要なのだろう?寄り道をしていないだろうか?
  4. 上流の仕事に更新があったとき、下流の仕事は追従して変化するだろうか?ひとつのステップにまとめられる工程はないだろうか?

References

大野耐一. 1978. トヨタ生産方式. ダイヤモンド社.


  1. さらに言えば、csv さえバッファかもしれない。 ↩︎