「バッチサイズは小さめに」: ムダの少ない作業の進め方

この記事は模擬授業の書き起こしです (教員の教育能力向上を目的とする東京大学 Future Faculty Program の一環)。学部 1, 2 年生を想定対象、6 分という時間制限付きなので一部の説明を簡略化しています。

いつもの Medium の読者の皆様へ

スタートアップの文脈で言えば、

  • バッチサイズを小さくする = MVP を作って仮説検証する

という風に少しだけ文脈を補足していただければいいのかなと思います。

授業の導入

今日はムダの少ない作業の進め方について解説します。

この講義を通して達成する目的は、バッチサイズという考え方を知ってもらうことです。その目的を達成するために、授業終了後に皆さんが、

  • バッチサイズの概念を知る
  • バッチサイズを小さくすることのメリットを言える
  • バッチサイズを小さくしたほうが良い例を考えられる

という状態に到達することを目標としています。

例:寿司工場

さて、まず手作業で寿司を握る寿司工場を思い浮かべてみて下さい。

Image for post
Image for post

寿司職人の元には握られたご飯が流れてきます。その後、職人さんは、わさびを乗せて、うにを乗せて、お皿に乗せて完成です。

Image for post
Image for post
うに寿司を完成させるプロセス

さて、同じ寿司スキルを持つ 3 人の寿司職人がここにいるとします。彼らが 10 個の完成した寿司を作ろうとしたとき、

  1. 10個ずつ作る
  2. 5個ずつ作る
  3. 1個ずつ作る

の 3 つのうち、どのパターンで作る寿司職人さんが最も早く「完成」に辿り着くでしょうか?

Image for post
Image for post

10個ずつやっていったほうが良い、という人もいれば、いやいや全部同時だ、という人もいると思います。色々な前提条件が抜けているので分からない、という人もいるでしょう。

大体の場合だと、一番上の「10個」のパターンが一番早い、と回答する人が多いです。

一個流しのシミュレーション

シミュレーションした動画 (Youtube) を見てみましょう。

Image for post
Image for post
https://www.youtube.com/watch?v=JoLHKSE8sfU

多くの人の直感に反して、「1個ずつ」やったほうが作業が早く終るのが、上のシミュレーション動画でした。

以下では、なぜ 1 個ずつのほうが早く終わるのかの理由を考えていきたいと思います。

用語の整理:バッチとバッチサイズとは

まず用語の整理をします。以下では、段階的に進む作業において、

  • 一回あたりの処理量のことを「バッチ」
  • バッチの大きさを「バッチサイズ」

と呼びます。

先ほどの動画の例では、バッチサイズが 1 のものが一番早く、バッチサイズが 10 のものが一番遅かった、という結果になります。

普通に考えれば、大きなバッチサイズで作業を回していったほうが早いように思えます。たとえば工場の大量生産の現場などを思い出すと、バッチサイズが大きな作業が多いように思えます。そのため、直感的にバッチサイズが大きい方が早い、と考えてしまった方も多いのではないでしょうか。

しかし上の例のように、バッチサイズが小さいほうが作業が早く終わるときがあります。ではなぜこのようなことが起こるのでしょうか? それを考えるために、一度作業の流れを分解してみます。

作業の流れの分解

一般的に言えば、作業の流れは

  • 段取り時間
  • 処理時間
  • 待ち時間

という形で構成されています。

(※ TOC では待ち時間はキュータイムとウェイトタイムに分けていますが、今回は簡略化して待ち時間としてまとめています)

Image for post
Image for post

この流れにそって考えてみても、大きなバッチで回したほうが良い用に思えます。

Image for post
Image for post

実際、バッチサイズが大きい方が早くなるケースはたくさんあります。大きな理由は以下の二つです。

1. 小さなバッチだと段取り回数が増えて時間がかかる

一つ目は、バッチを細かく分けると、その分段取り時間(黄色の部分)がその回数分多くかかってしまうので、時間が長くなってしまうこと。

Image for post
Image for post

2. 大きなバッチだと処理時間が短くなる

そして 2 つ目は、大きなバッチで大量に処理すると、その処理の習熟などにより、処理時間が短くなる印象があるからです(もちろん大量に処理できる機械などを導入するとそうなることもあります)。

Image for post
Image for post

小さなバッチのほうが良いケース

しかし、段取り時間を少なくできるのであればどうでしょう。また、バッチサイズに応じて待ち時間が変わるのであれば、どうでしょう。

そうしたケースでは、小さなバッチで処理したほうが早く終わるケースがでてきます。先ほどの寿司の例はまさにこうした例となっていました。

Image for post
Image for post

先ほどの寿司工場の例でどこで待ち時間が発生しているか、もう一度動画を見てみましょう。

Image for post
Image for post

上の画像で強調している部分で上2つは「10個揃うまで」「5個揃うまで」、それぞれ待ち時間が発生しています。

実際の製品の工場だと、次の機械が前の作業をしているための待ち時間や、組み立てのために他のパーツが来るまでの待ち時間などが発生することがあり、そこで待ち時間が発生してしまいます。

しかし、一部のそうでないケースにおいては、一個流しのほうが早いケースが存在します。

その他によく紹介される例では、封筒に書類などを詰める作業を一気にやったほうがよいか、一つずつやったほうがよいかで、一つずつのほうが早く終わる、というものがあったりします。

バッチサイズを小さくするメリット (1): 早く作業が進む場合がある

ですので、バッチサイズを小さくするメリットをまとめてみるとこうなります。

Image for post
Image for post
バッチサイズを小さくすると、早く作業が進む場合がある(ただし段取り時間が十分に短くできるとき)

さらに、バッチサイズを小さくするメリットはもう一つあります。それが不確実性や変化への対応です。

バッチサイズを小さくするメリット (2): バッチサイズを小さくして不確実性によるムダを少なくする

バッチサイズを小さくする二つ目のメリットは、処理の間違いが起こったときなどのミスに早く気付けるという点があります。

設計していた処理の流れで「間違い」が途中でわかったときのことを考えてみて下さい。

たとえば先の寿司の例だと、用意したシャリが大きすぎて、お皿に乗らないということが起こったとします。

Image for post
Image for post
シャリがお皿に対して大きすぎる、もしくはお皿が小さすぎた

これはプロセス C で間違いがあったことに相当します。

Image for post
Image for post

そんなとき、もし小さなバッチサイズで処理を進めていれば、間違いが分かるタイミングは明らかに早くなります。

寿司の例の場合でいえば、バッチサイズを 1 にしておけば、わずか数秒でお皿に問題があることが発覚します。

Image for post
Image for post

他の観点から見てみると、大きなバッチで作業をすすめていれば、気づくのが遅れ、ムダになる量が多くなってしまいます。お寿司の例の場合、10個のシャリがムダになってしまうことになります。

Image for post
Image for post

あるいは顧客がほしいのが「うにの寿司」ではなく、「いくら丼」だったときはどうでしょう? 大きめのバッチで間違いが分かってしまうと、10 個分のうにがムダになってしまいます。

Image for post
Image for post
顧客が本当に欲しかったもの

一般的な例

一般的に言えば、様々な新製品の開発などには、処理に不確実性が含まれます。作るプロセスだけではなく、「作ったものが顧客の欲しいものではなかった」ということで、作ったもの全部がムダになることすらあります。

このような例を見てみても、処理に間違いが含まれているかもしれないような、初めての作業の場合はバッチサイズを小さく回したほうが良い、ということが一般的に言えそうです。

論文やレポートでの例

皆さんが論文執筆や何度でも提出できるレポートを作成しなければならないときも、この考え方が使えます。

Image for post
Image for post

たとえば「1章」ずつ、全部書いてから先生にレビューしてもらうとしましょう。

Image for post
Image for post

1章と2章はOKだったようです。

Image for post
Image for post

しかし 3 章で「前提からやり直せ」と言われてしまいました。

Image for post
Image for post

そうなるとこれまでの作業がほぼムダになってしまうことになります。

Image for post
Image for post

大きなバッチで章を全部書き終えてから持っていこうとすると、こういうことが起こりえます。

一方、小さなバッチサイズで回してみるとどうなるでしょうか。

先生には各章の3割ずつ、しかも間違いが含まれているかもしれないようなリスクの高い部分の文章を持っていくようにしてみます。すると…

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

このように仮に間違いが第3章に含まれていたとしても、小さなバッチで進めていればムダになる量が少なくすむだけではなく、早く間違いに気づいて早く方向転換をすることができます。

このように、バッチサイズを小さくする二つ目のメリットとして、間違いに素早く対応できるという点が挙げられます。

バッチサイズの大小による向き不向き

これまでの話をまとめて、バッチサイズの作業の向き不向きを比較をしてみるとこうなります。

Image for post
Image for post

特に不確実性の高い、処理に間違いが含まれているかもしれない作業では、バッチサイズは小さめにして流していくことが、ムダを少なくする一つの手法として使えるのではないでしょうか。

問いかけ

それでは皆さんの身近に、「バッチサイズを小さくする」ほうがムダが少なくなりそうな作業はあるでしょうか? 少し考えてみて下さい。

Image for post
Image for post

たとえばスタートアップの文脈では、Minimum Viable Product(実用最小限の製品)や MMF (Mimum Marketable Feature) を作って仮説検証をしようと言われます。Minimum なバッチで作業を進めて検証し、顧客からの学びを得るというのは、まさにバッチサイズを小さくすることとも言えます。

またもう一つは今回やっている6 分間の模擬授業がそれに当たるかもしれません。大きなバッチである 105 分の授業よりも、6 分の模擬授業で何度もデリバリーしてフィードバックをもらうことで、より質の高い授業ができそうです。

まとめ

今日の 6 分の模擬授業では、バッチサイズの概念と、バッチサイズを小さくしたほうがムダが少なくなる作業の種類についてお話ししました。

  1. 段取り時間を十分短くできる作業
  2. 間違いが含まれているかもしれない作業

今回のケースではバッチサイズを小さくしたほうが良い作業について、その背景を解説しました。その上で次回は新しい概念として、

  • ボトルネック
  • ばらつき

について解説していきます。

(以上で模擬授業終了)

最後に

いらすとやさんのイラストを利用させていただきました。また、リーンスタートアップの 9 章はバッチサイズの話で、今回主に参考にさせていただきました。

Written by

The University of Tokyo, Ex-Microsoft, Visual Studio; “Nur das Leben ist glücklich, welches auf die Annehmlichkeiten der Welt verzichten kann.” — Wittgenstein

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store