![\"タスク改善の6つの視点「判断・入力・ばらつき・記憶・探索・習得」を、それぞれの削減方針とともに示した図。不要な作業を減らし、効率の良い属人化を予防した作業を目指す。\"](\"https://mochibenashi.pages.dev/media/posts/12/2.png\")
判断・入力・ばらつき・記憶・探索・習得を前提としたタスクはなくしましょう。いきなり６つすべては難しいですが、ひとつでも減らせれば体感かなり楽になるはずです。
\n判断なし 判定ロジックを単純化し、可能であれば自動化しましょう。人間が考えるより機械が処理したほうが早く、正確です。
\n入力なし 兎にも角にもコピペで済むようにしましょう。右利きの場合右手はマウス、左手小指は[Ctrl]・薬指は[A]・人差し指で[C]と[V]で固定が理想です。
\nばらつきなし 作業を統一しましょう。例えば、毎日朝の挨拶をチャットする決まりがあるなら、「おはようございます」以外は打たないと決めて明日からはコピペで対応しましょう。
\n記憶なし タスクや進捗を記憶に頼るのはやめましょう。人間は通常忘れるものだと考え、見て確認できる状態にしましょう。タスク・進捗の見える化によって、属人化も予防できます。
\n探索なし 作業時の参照資料をなくしましょう。ゼロにできなくても減らしましょう。\"判断なし\"と重複する部分がありますが、自動で結果が出るように出来るのがベストです。資料を見ないとできない作業そのものをなくす、でもOKです。資料を開かない分、PCの動きも軽くなりますよ。
\n習得なし 一人前になるまでの期間を減らしましょう。煩雑な作業はミスを引き起こしますし、属人化につながります。管理職の立場なら、新入社員の教育工数削減、ベテランさんの急な離職・休職リスク回避といいことづくめです。ベテランさんでできている組織では効果が見えにくいので優先順位が落ちがちですが、私はこれを重く考えています。
\n大きく分類すると作業を減らす（入力なし・探索なし）と考えないようにする（判断なし・ばらつきなし・記憶なし・習得なし）に分けられます。作業を減らす → 業務効率向上は想像しやすいので割愛しますが、考えを減らす方はないがしろにしがちなのではと思います。頭使うのって意外と疲れるので、とにかく何も考えずに作業できる状態にもっていきましょう。あと人間の作業精度って低いので、あまり自分を信じすぎないほうがいいですね...。
\nお気づきだと思いますが、これらは完全には独立してませんので、ひとつ改善したら自動的に他のも改善されると思います。例えば、ばらつきをなくしたら判断も入力も減るはずですし、探索には判断が付随しますよね。あくまで切り口として考えていただけたら幸いです。
", "author": { "name": "餅辺なし" }, "tags": [ "業務改善" ], "date_published": "2026-09-08T00:17:01+09:00", "date_modified": "2026-10-08T22:24:56+09:00" }, { "id": "https://mochibenashi.pages.dev/tasukuhurosisutemudekao-eruye-wu-gai-shan.html", "url": "https://mochibenashi.pages.dev/tasukuhurosisutemudekao-eruye-wu-gai-shan.html", "title": "タスク・フロー・システムで考える業務改善【基礎】", "summary": "「業務を改善しよう」「作業効率を上げよう」とよく言われますが、いざ考えるとなったときの思考の軸がないなあと思いまして。 下手をすると、見かけ上の数値は良くなったものの作業者の負担は増えた、なんてこともありえる話なのではないでしょうか。 そこで、業務改善を考える対象をタスク・フロー・システムの3つに分け、それぞれに思考の軸を作成しました。 この3つには考える順番があります。 「システムを\"作った\"」という実績に目が向きがちですが、業務改善で最も優先されるべきはタスク・フローの精査です。 まず、業務タスクを担当者・部署ごとにすべて書き出し、業務全体の流れ（フロー）を明確にします。 例えば、上図において各個人が抱えるタスクの量とその理解度に注目すると以下の通りです。 また、フローに注目するとAさん - Bさん間では往復が生じています。 次に、洗い出したタスク・フローから問題の原因や潜在的なリスクを探ります。 図からは断定できませんが、Bさんが一部のタスクを理解しきれていないのは、Aさんから引き継がれる情報の精度に影響されているのかもしれません。Aさん - Bさん間の往復はお互いの業務・責任範囲が曖昧なことが原因とも考えられます。Cさんはすべてのタスクを問題なくこなせているため、一見すると改善の必要がないようにも見えますが、Cさん以外に同様の業務をこなせる人がいない（属人化している）可能性があります。 原因が明らかになったら、タスク・フローを再設計します。作業者単位ではなく、フロー全体のタスク数が減るように調整します。 例えば、Aさんの負担を減らすためにBさんにタスクを移動しても、業務全体のタスク数は減っていません。反対に、Aさんにひとつ確認作業を追加することで、後工程にある複数の確認作業をなくせるのであれば、Aさんのタスクは増えていても業務全体としては改善されたと考えられます。（理想は全員の負担が減ることですけどね） 最後に、機械的な制限や補助を入れたほうが業務精度が向上する部分にのみシステムを導入します。 図に倣うとAさん - Bさん間の引継ぎ部分には入力フォームを含んだシステムを作成しました。結果的にこのシステムはBさんのタスクの補助もできました。Cさんのタスクは大幅に削減できたうえに、残ったタスクの一部は自動化できたためCさんの属人化リスクが低減しました。 ここで考えていただきたいのですが、タスク・フローを精査せずにシステムを導入していたらどうなっていたでしょうか。 AさんとBさんの業務範囲や引継ぎ手順が曖昧なままシステム化すれば、その曖昧さもシステムに組み込まれます。後から手順を整理した際に、システムの改修や、システムを補うためのタスクが増えるかもしれません。Cさんのタスクはシステムの管理に置き換わっただけで属人化リスクが低減しないかもしれません。 この状態を「業務改善された」と評価するのは厳しいでしょう。 1. システムはタスクを減らしてくれない システムはタスクを代行・補助できますが、業務上「やる必要があること」そのものを減らすわけではありません。不要なタスクをシステム化すれば、そのタスクは形を変えて残り続けます。 2. システムの作成 = 新たなタスクの発生である システムを作ると、設定変更、不具合対応、仕様変更などの保守タスクが増加します。場合によっては、これまで単純作業だったタスクを自動化する代わりに、より専門性の高い保守タスクを生み出すことになり、タスクの属人化リスクが高まります。必ず属人化リスクと単純作業工数を天秤にかけ、リスクが大きすぎるときはシステム導入を見送る判断をしましょう。 システムを開発しないで済む業務改善が、最高の業務改善です。", "content_html": "「業務を改善しよう」「作業効率を上げよう」とよく言われますが、いざ考えるとなったときの思考の軸がないなあと思いまして。
\n下手をすると、見かけ上の数値は良くなったものの作業者の負担は増えた、なんてこともありえる話なのではないでしょうか。
\nそこで、業務改善を考える対象をタスク・フロー・システムの3つに分け、それぞれに思考の軸を作成しました。
\n![\"\"](\"https://mochibenashi.pages.dev/media/posts/11/1-2.png\")
この3つには考える順番があります。
\n「システムを\"作った\"」という実績に目が向きがちですが、業務改善で最も優先されるべきはタスク・フローの精査です。
\nまず、業務タスクを担当者・部署ごとにすべて書き出し、業務全体の流れ（フロー）を明確にします。
\n例えば、上図において各個人が抱えるタスクの量とその理解度に注目すると以下の通りです。
\nまた、フローに注目するとAさん - Bさん間では往復が生じています。
\n次に、洗い出したタスク・フローから問題の原因や潜在的なリスクを探ります。
\n図からは断定できませんが、Bさんが一部のタスクを理解しきれていないのは、Aさんから引き継がれる情報の精度に影響されているのかもしれません。Aさん - Bさん間の往復はお互いの業務・責任範囲が曖昧なことが原因とも考えられます。Cさんはすべてのタスクを問題なくこなせているため、一見すると改善の必要がないようにも見えますが、Cさん以外に同様の業務をこなせる人がいない（属人化している）可能性があります。
\n原因が明らかになったら、タスク・フローを再設計します。作業者単位ではなく、フロー全体のタスク数が減るように調整します。
\n例えば、Aさんの負担を減らすためにBさんにタスクを移動しても、業務全体のタスク数は減っていません。反対に、Aさんにひとつ確認作業を追加することで、後工程にある複数の確認作業をなくせるのであれば、Aさんのタスクは増えていても業務全体としては改善されたと考えられます。（理想は全員の負担が減ることですけどね）
\n最後に、機械的な制限や補助を入れたほうが業務精度が向上する部分にのみシステムを導入します。
\n図に倣うとAさん - Bさん間の引継ぎ部分には入力フォームを含んだシステムを作成しました。結果的にこのシステムはBさんのタスクの補助もできました。Cさんのタスクは大幅に削減できたうえに、残ったタスクの一部は自動化できたためCさんの属人化リスクが低減しました。
\nここで考えていただきたいのですが、タスク・フローを精査せずにシステムを導入していたらどうなっていたでしょうか。
\nAさんとBさんの業務範囲や引継ぎ手順が曖昧なままシステム化すれば、その曖昧さもシステムに組み込まれます。後から手順を整理した際に、システムの改修や、システムを補うためのタスクが増えるかもしれません。Cさんのタスクはシステムの管理に置き換わっただけで属人化リスクが低減しないかもしれません。
\nこの状態を「業務改善された」と評価するのは厳しいでしょう。
\n1. システムはタスクを減らしてくれない システムはタスクを代行・補助できますが、業務上「やる必要があること」そのものを減らすわけではありません。不要なタスクをシステム化すれば、そのタスクは形を変えて残り続けます。
\n2. システムの作成 = 新たなタスクの発生である システムを作ると、設定変更、不具合対応、仕様変更などの保守タスクが増加します。場合によっては、これまで単純作業だったタスクを自動化する代わりに、より専門性の高い保守タスクを生み出すことになり、タスクの属人化リスクが高まります。必ず属人化リスクと単純作業工数を天秤にかけ、リスクが大きすぎるときはシステム導入を見送る判断をしましょう。
\nシステムを開発しないで済む業務改善が、最高の業務改善です。
", "author": { "name": "餅辺なし" }, "tags": [ "業務改善" ], "date_published": "2026-09-04T18:20:19+09:00", "date_modified": "2026-10-15T00:26:10+09:00" } ] }