MASTER / WORK BASICS
ムダとボトルネックを見つける
業務を工程に分け、作業時間と待ち時間を分けて見ます。ムダと、全体の処理能力を制約する工程を区別し、原因を記録で確かめます。
承認の処理能力（制約になる工程）
12件/日
約20分入門演習 5問講義をはじめる
※ 本レッスンの社内問い合わせの工程と処理能力（受付40・確認25・振り分け35・作成20・承認12・返信30件/日）は、説明のための架空の例です。各工程の条件が同じで、すべての問い合わせが順番に流れるという単純化した仮定で考えています。実際には案件の難易度や並行処理が違うため、記録で確かめてください。
この講義でできるようになること
- 業務を、誰が何を受け取り何をして何を渡すかの順に、工程へ分けて書き出せる
- ムダ（重複・探す手間・やり直し）と、品質・安全・法令に必要な確認を区別できる
- 工程ごとの処理能力を比べ、全体を制約するボトルネックを、前提を添えて特定できる
00:00 / 09:08
1第1章業務を工程に分け、作業時間と待ち時間を見る
Space 再生／停止・← → 10秒移動・N / P で章を移動・C で字幕。右の「文字で読む」で、話している内容を文字で追えます。
演習：手を動かして確かめる
講義を見終えたら取り組みましょう。入力した内容はこの画面の中で使うだけで、どこにも送信されません。
全体の処理数を制約している（ボトルネックになる）工程はどれですか？
ムダとボトルネックを探すときの確認リスト
- 業務を4〜7つの工程に分け、工程ごとの完了条件を書いたか
- 作業時間と待ち時間を分けて記録したか
- ムダと決める前に、その作業を止めると成果や安全に悪影響がないか確かめたか
- 同じ作業を重ねていないか、やり直しの原因は何かを見たか
- 処理能力の低い工程だけでなく、仕事が溜まる場所や待ち時間が長い場所も観察したか
- 対策の前に、工程ごとの待ち時間・依頼が届く時間帯・差し戻し件数などの記録で原因を確かめたか
次に学ぶなら
テキストで読む（文字起こし）
第1章 業務を工程に分け、作業時間と待ち時間を見る
問い合わせの返信が遅れていると聞くと返信担当を増やしたくなるかもしれません でも本当に遅れている場所が返信作業だとは限りません 承認待ちが長いのかもしれませんし 最初の情報が不足して内容確認に時間がかかっているのかもしれません 改善の前に仕事がどこで滞っているのかを見つけましょう 全体を見ずに一部だけ早くすると、次の工程に仕事が積み上がる場合もあります 最初は業務を、誰が、何を受け取り、何をして、何を次へ渡すかの順に書き出します 細かすぎる必要はありません 社内問い合わせなら、受付、内容確認、担当への振り分け、回答の作成、承認、 返信の6つに分けてみます 各工程について作業時間と待ち時間を分けて記録すると重要な違いが見えてきます 例えば回答の作成そのものは十分短くても 確認者からの承認を待つ時間が長ければ全体の所要時間は短くなりません 誰が遅いかではなくどの工程で何がどれくらい起きているかを確認することが重要です ここで演習です 身近な業務を4つから7つの工程に分け矢印でつないでみましょう それぞれの工程に完了条件を1つずつ書き添えてください 動画を止めて書いてみてください
第2章 ムダと、全体を制約するボトルネック
無駄とは仕事の目的に照らして必要な価値を生まない 負荷や手間です 例えば毎回同じファイルを探す 同じ内容を2つのシステムに入力する 情報不足のため依頼者に何度も聞き直す といった行動です 一方確認や承認をすべて無駄と決めつけてはいけません 品質・安全・法令・契約などに必要な手続きは目的を持った工程です なくす前に役割を確認しましょう 無駄を見つけるための質問を3つ紹介します 1つ目 これをしないと成果や安全に悪影響があるか 2つ目 同じ作業を重ねていないか 3つ目 やり直しが発生する原因は何か 作業している人を責めるのではなく 仕事の設計を見ます 例えば問い合わせの添付ファイルを 毎回いくつものフォルダから探しているとします 受付の時に保存先を統一すれば 探す手間は減らせそうです ただし保存先を変えてよいか権限はどうなっているかの確認も必要です ボトルネックは全体の処理能力を制約する工程です この架空ケースでは各工程の条件が同じで すべての問い合わせが順番に流れると仮定します 承認工程が1日12件しか処理できなければ 他の工程だけを増強しても 全体の処理数は基本的に12件を超えられません もちろん実際には問い合わせの難易度や並行処理が違うため 記録を使って確かめます 処理能力が低い工程だけでなく 仕事が溜まっている場所、待ち時間が長い場所 他工程の進み方を左右する場所も観察してください 重要なのは忙しそうな人を当てる のではなく全体の流れを制約している 要因を確かめることですここで 演習ですこのケースで全体を制約 している工程はどこでしょうか そして承認を1日20件まで改善 できたとしたら次に制約になり そうな工程はどこでしょうか 動画を止めて考えてみてください 解説です 最初の制約工程は1日12件の承認です 承認を20件に改善すると 今度は回答作成の20件と承認の20件が並びます ここでは単純なモデルの範囲で考えています
第3章 原因を確かめてから対策を決める
よくある間違いは遅いから人を増やすと原因を確かめずに対策を先に決めることです まずどの工程で待っているのかを確認します なぜ待つのか時間帯が偏っているのか承認基準が曖昧なのか情報が不足して差し戻されるのか と複数の可能性を挙げます それぞれを記録で確かめましょう 原因が違えば効く対策も変わります ここで演習です 対策を決める前に確認すべきデータを2つ挙げてみましょう 動画を止めて考えてみてください 例えば工程ごとの待ち時間、承認依頼が届く時間帯、差し戻しの件数などです 改善対象を選ぶときは仕事を工程に分け 無駄な作業と全体を制約する工程を区別してください その上で何が起きているかという事実と なぜ起きるかという仮説を分けます 次の講義では見つけた問題に対して 小さな改善を試す進め方を扱います 最後に確認問題です 1つ目作業時間と待ち時間を分けて記録するのはなぜでしょうか 2つ目必要な法令確認は無駄でしょうか 3つ目一部の工程だけを効率化しても 全体の改善につながらないのはどんな時でしょうか 動画を止めて考えてみましょう 答えの一例です 一つ目は作業そのものが短くても 待ち時間が長ければ全体の所要時間は短くならないからです 二つ目は無駄ではありません 法令に必要な確認は目的を持った工程です 3つ目は全体を制約している工程以外を早めたときです 次の工程に仕事が積み上がるだけで全体の処理数は増えません