仕事に潜む７つの”ムダ”を学ぼう 「リーン開発の本質 〜原則1：ムダをなくす（Eliminate Waste）〜」
[ひとことで言うとこんな記事]
- すべての仕事にはプロセスが存在している
- プロセスに潜む"ムダ"には7種類存在する
- 未完成の作業のムダ（在庫のムダ）
- 余分な機能のムダ（作りすぎのムダ）
- 再学習のムダ（加工そのもののムダ）
- 引き継ぎのムダ（運搬のムダ）
- タスク切換えのムダ（動作のムダ）
- 待ちのムダ、遅れのムダ（手持ちのムダ）
- 欠陥のムダ（不良のムダ）
[こんなひとにおすすめ]
- 自分のやっている作業がなんとなく「ムダだなぁ〜」と感じている方
- ムダだと感じていることを、うまく他の人に言語化できない方
ソフトウェア開発の本の内容ではありますが、オフィス業務当にも当てはまると感じていますので、ぜひ読んでみてください。
[今回紹介する本]
[目次]
- 知識労働者は平均して労働時間の41%をそれほど重要ではない仕事に割いている！？
- "ムダ"をなくす考え方は、生産管理やソフトウェア開発じゃなくても使える！
- "ムダ"は7種類ある！？ "ムダ"の種類を知ろう
- まとめ："ムダ"の種類をしれば、"ムダ"に気がつく感度が上がる
知識労働者は平均して労働時間の41%をそれほど重要ではない仕事に割いている！？
筆者たちの調査によれば、知識労働者は平均して労働時間の４１％をそれほど重要ではない仕事に割いているという。
引用: マネジメント時間を20％増やす法 仕事を見直し、生産性を改善する | ジュリアン・バーキンショー,ジョーダン・コーエン | ["2014年3"]月号｜DIAMOND ハーバード・ビジネス・レビュー
「シンジラレナーイ」とか「思い当たる節あるわー」とかいろいろな声が上がってくるような気がしますね。ムダだと思う仕事は極力減らしていきたいというのは、常にサラリーマンが思っていることではないでしょうか？？
"ムダ"をなくす考え方は、生産管理やソフトウェア開発じゃなくても使える！
私はソフトウェアの世界でしか社会人として仕事をしたことがないですが、どんな業務でも"ムダ"をへらす考え方は活かせると考えています。
- やらねばならぬこと というのは、 その先に「期待する結果」がある
- 「作業開始〜期待する結果」までは「プロセス」がある
- 「プロセス」がある ということはそこに ムダが潜んでいる可能性が高い
例を以下に羅列してみたいと思います。
| やらねばならぬことの例 | プロセス | 期待する結果 |
|---|---|---|
| ソフトウェア開発 | 要件定義 →実装 →テスト →リリース |
ユーザーに新機能の提供 |
| 工場の組み立て | 必要部品の入荷 →組み立て手順１ →組み立て手順２ →完成 |
完成した製品の出荷 |
| 社内承認フロー | 係長 →課長 →部長 →取締役 →社長 |
実施可否を問うなどの意思決定をしてもらう、判断を仰ぐ |
| 普段の業務 | 手順A →手順B →人の目でダブルチェック →提出 |
ミスの許されない業務 |
上記のような例をみると、 どんなものにもプロセスがある ので、ムダが潜んでいる可能性はありますね。
（※"ムダ"というか、 プロセスをもっと改善できる余地がある っていう表現のほうがいいのかもしれませんが、リーン開発の本質の表現に今後も合わせて表記します）
なるべく、オフィス業務等の事例も思い浮かぶ分には記述していきたいと思います。
"ムダ"は7種類ある！？ "ムダ"の種類を知ろう
ここからは、リーン開発の本質（ならびにトヨタ生産方式）で紹介されてきた "ムダ" について1つづつ7つご紹介したいと思います。
未完成の作業のムダ（在庫のムダ）
ひとことで言うと 完了してない仕事/案件/タスク自体のこと を言います。
完了しきっていない仕事/案件/タスクを複数持っているところを想像すると、在庫のムダというワードもしっくり来ると思います。
| 例 | 状態 | 結果 |
|---|---|---|
| ソフトウェア開発 | 実装やテストまで終わってますが、まだドキュメント終わってません〜 | まだユーザーに届きません |
| 工場の組み立て | まだ工程の1/3しか完了してません | まだ出荷できません |
| オフィス業務 | データ入力作業、進捗は80%です〜〜 | 上司「仕事はやく終わらせて〜」 |
考えうる対処
未完了の案件やタスクをなるべく持たないようにするには、 仕事/案件/タスクを速く終わるようにする ことで、未完了の案件やタスクを貯めないことが必要です。以下2つの。アプローチがあります
- 仕事/案件/タスクを完了させる効率をアップし、仕事を速く完了させる
- 仕事/案件/タスクの１つ１つの粒度を小さくすることで、1つ1つが完了しない状態を作り出さない
余分な機能のムダ（作りすぎのムダ）
ひとことで言うと、 せっかく実施した仕事/案件/タスクが、全くもって意味がなかった ということを指します。
| 例 | 状態 | 結果 |
|---|---|---|
| ソフトウェア開発 | 新機能をリリースしました | リリース後にユーザーに利用されず |
| 工場の製品組立 | 製品を100個作りました！ | 20個しか注文が入らず |
| プレゼン資料づくり | メンバー「明日のプレゼン、AのデータもBのデータもCのデータも準備しておきました」 | 上司「Aだけでいいや。ありがと」 |
考えうる対処
このムダは、本当にしんどいムダです。 本当に必要なものは何なのか？ を見極めるという対処法になるかと思います。
上記の例と対応した対処法をご紹介させていただきます。
- ソフトウェア開発：機能導入前に、有用なものかをABテスト等で測定する
- 工場の製品組立：注文された分しか作らないと決めてしまう
- プレゼン資料づくり：事前に上司とプレゼンのアウトラインと必要な情報を確認しておく
再学習のムダ（加工そのもののムダ）
ひとことでいうと 知識共有などがないせいで、本来必要のないことに労力をつかってしまっている ということです。例をみてみましょう。
| 例 | 状態 | 結果 |
|---|---|---|
| ソフトウェア開発 | 新規メンバー「バグ出しちゃった」 | 古参メンバー「それ数ヶ月前にも同じバグあったよ」 |
| 工場の組み立て | 新規メンバー「作業Aはこうやるんだなぁ」 | メンバー「作業Aって本当に必要な作業だった？」 |
| オフィスワーク | 新規メンバー「このシステムの使い方は…むずかしいなぁ…」 | 上司「それに時間かけないで。聞いてくれればすぐ教えてあげたのに」 |
考えうる対処
下記２つのアプローチと、例があると思います。
- 知識共有を仕組み化する
- ドキュメント化
- 部署を超えたナレッジ共有
- 根本的な対処により、本来必要ない作業を発生させない
- バグの対処を暫定対応で終わらさず、恒久対応しきる
引き継ぎのムダ（運搬のムダ）
ひとことでいうと 引き継げば引き継ぐほど、情報は劣化や余分なコストがかかる ということです
| 例 | プロセス | 結果 |
|---|---|---|
| ソフトウェア開発 | 機能横断的な組織で 要件定義者 →バックエンドエンジニア →フロントエンジニア →デザインコーダー |
デザインコーダー 「要件定義者って、どういう意図でこの仕様にしたんだっけ？」 |
| 工場の組み立て | A工場で途中まで組み立てたが、100km先のB工場で続きをする必要がある | 「運搬する時間とか労力って、製品価値をあげるんでしたっけ？」 |
2020年3月26日(木) 22時00分～22時54分 放映の カンブリア宮殿【知られざるローソン コンビニ未来宣言】からの引用ですが
| ローソンの商品企画の例 | プロセス | 結果 |
|---|---|---|
| 旧フロー | メンバー →係長 →課長 →部長 →取締役 → 社長 |
フィードバックを真摯に受け止めてクリアしていった結果 社長にたどり着く間にクソつまらん案になった |
| 新フロー | メンバー →社長 |
エッジの効いた案があり、実際に売れる |
という改革を実施したそうです。
考えうる対処
引き継ぎ回数をなるべく減らすアプローチが必要です。
- 大胆に中間プロセスを無くす
- 関係者を一同に介したチーム等を結成し、同時に情報共有できるようにする
タスク切換えのムダ（動作のムダ）
ひとことでいうと 同時に複数の仕事/案件/タスクをやると、効率が悪いよ ということです
| 例 | プロセス | 結果 |
|---|---|---|
| ソフトウェア開発 | とあるチームが、1ヶ月で終わる案件を同時に5つ実施している | なんか、5ヶ月後にひとつも案件が終わっていない |
| 工場の組み立て | 作業者の教育が行き届かず、あたふたしている | あたふたしている時間は、製品価値を上げていない |
なぜマルチタスクがシングルタスクよりも効率が悪いかでいうと、 現在のタスクと他のタスクを切り替える際に時間を要するから です。
考えうる対処
- 仕事/案件/タスクを差し込まれないために
- 外部のプレッシャーからチームを守る
- タスクが終わるまで、精神と時の部屋に籠もる
- やるべきことが複数ある状況であれば
- 明確な優先順位をつける
上記のような例が有効だと思います。
待ちのムダ、遅れのムダ（手待ちのムダ）
ひとことでいうと 手持ち無沙汰で暇、無業の時間がある ということです。
以下２点のような状況で起こりやすいです
- プロセスの工程毎の処理能力に差があること
- プロセスの工程毎に担当者が変化してしまうこと
| 例 | 状況 | 結果 |
|---|---|---|
| ソフトウェア開発 | コードレビューして欲しいんだけど、○○さん他の案件実施中だしな〜 | 当案件STOP中 |
| 工場の組み立て | 前工程の組み立ておわってないから暇だな〜 | 暇だな〜 |
| オフィス業務 | 上司から次の業務の指示ないな〜 | 暇だな〜 |
上記の例では、「工程２」の処理能力が足りず、在庫を後工程に流せていないことによって発生していることを示しています。
考えうる対処
下記２つのアプローチと、例があると思います。
- プロセスの工程毎の処理能力に差を埋めるために
- ボトルネックとなっている工程に機械を導入して効率化する
- プロセスの工程毎に担当者を変化させないために
- １チームで製品が完成するようなチームを結成し、待ちをフォローし合う
欠陥のムダ（不良のムダ）
ひとことでいうと タスクが完了したけど、なにか問題があった という状況です
| 例 | 状況 | 結果 |
|---|---|---|
| ソフトウェア開発 | 案件Aリリースしたけど、バグが起こった | 追加で障害対応する |
| 工場の組み立て | 製品が組み立て終わったが、最終検査で何個か製品が動かなかった | 出荷できず処分 |
| オフィス業務 | 書類に不備があったため、出し直し | 余分に書類準備の時間を取られた |
まとめ： あなたの感じている"ムダ"は、どのような"ムダ"でしたか？
いかがでしたでしょうか？ つたない例でしたが、7つのムダをしることで、普段の活動でどんなムダがあるかを意識することができます。
何気なく思っているあなたの"ムダ"は、どのような種類のムダだったでしょうか？
実際にムダを排除していく考え方は別途ブログに記載していきたいと考えています。
【お願い】
- 上記7つのムダの例を、みなさん思い浮かぶものがあれば、お問い合わせください！
- もっとわかりやすい例があるといいなと思っています。。。
- 「ここ、こう表現したほうがよいよ〜」「ここ、間違っているよ〜」などございましたら、お問い合わせください！
__一緒に様々なことを学んでいく仲間を募集__しています。
このサイトのお問い合わせなどからご連絡いただけると幸いです。