仕事術マニアが考える、業務改善の進め方

仕事術マニアが考える、業務改善の進め方

はじめに

仕事が多すぎる。ミスが多すぎる。この状態を何とかしたい。でもどうやって改善したいか途方に暮れる人もいるかと思います。

そこで、仕事術マニア(仕事マニアではない)の自分が業務改善をどのように考えているのか、そしてどのように行っているのかを書いてみます(以下単に「改善」と書きます)。

ただし分かりやすくするために、1人で行う改善に限定して話します。チームで行う改善については最後に少し触れます。

1. 改善したいところを探す

1.1. 改善したいところとは何か

まずは改善したい点を見つけます。これがないと始まりません。さて、改善したい点はどこから探せばいいのでしょうか。

それの答えは、今困っているところからです。今困ってるからどうにかしたい。それが改善したい点です。簡単ですね。

しかし会議でいきなり「さあ、困っているところを出してほしい」と言われて思いつくでしょうか。思いつかないでしょう。人の記憶力はあてになりません。

なので、自分は改善につながりそうな困ったこと、具体的には次のようなことに気づいたら、すぐメモを取っています。

  • ミスが多い作業
  • 時間がかかる作業
  • ムダが多い作業
  • つらい作業

自分はこの中でも特に、「ミスが多い作業」「つらい作業」をきっかけにして改善を行うことが多いです。

ここから先は説明しやすくするために、「ミス」を例にして話を進めます。

1.2. どのようなミスをメモするか

どのようなミスをメモするか。その答えは「全部」です。例えば次のように、どんな小さなミスも改善につなげることができます。

  • タイプミスをする → 辞書に登録する、スペルチェッカーを使う
  • ソースコードを読み間違えた → コメントを入れる、リファクタリングする
  • 手順書を読み間違えた → 文章を見直す、スクリプトで自動化する

実際はすべてのミスを記録するとその整理だけで大変なため、記録しないことも多いです(もちろん記録忘れもあります)。しかし小さなミスだから記録しない、そんな考え方はしません。小さなミスも積もり積もれば大きな時間のロスになるので。

ミスの中には数分で修正できるものもあります。ミスを管理する手間もかかるので、すぐ修正できるものはその場で修正してしまいます。タスク管理手法「GTD」における「2分ルール」と同じです。

自分だけではなく、他の人がミスしたところも同様に改善につなげられます。こちらもメモしておくといいでしょう。ただしあくまで改善が目的なので、ミスした人を責めないこと。むしろミスしたことを称えるくらいでちょうどいいです。

2. 改善計画を立てる

次にミスと向き合って、どのように改善するかの計画を立てます。手順は2.1.から2.3.までありますが、この順番の通りに進める必要性はありません。自分も、やりやすいところから手をつけることが多いです。

2.1. 問題を整理する

自分はプログラマーなのでプログラムを書いて自動化する・・・のではありません。むしろプログラムを書くのは最終手段で、まずはいかにプログラムを書かずに解決できるかを考えます。そのために次の内容に取り組みます。

  • 根本的な原因を考える
  • そもそも不要な作業がないかどうかを考える
  • 同じ問題を別の人が解決していないかを調べる
  • 簡単にできる改善に取り組む
    • 手順書がない場合、作成する
    • 手順書が分かりにくい場合、分かりやすくする
    • チェックリストを作成する

まずは改善案を出せる程度に根本的な原因を考えます。トヨタ生産方式の「なぜなぜ分析」みたいなものです。

次に、その作業が不要な可能性を考えます。例えば、資料作成を改善する場合はまずそもそも「誰がその資料を見るか」を考えます。答えが「誰も見ない」だったら、資料作成をいくら効率化しても意味がありません(契約や法律上必要なものは別として)。

次に、同じ問題を別の人が解決していないかを調べます。解決したいものが全くの未知であることはほとんどありません。既に解決法がある場合、その手法を使った方がいいです。

最後に、簡単にできる改善があれば、まずそれに取り組みます。その理由は、いきなり大きい問題を解決しようとしても、問題が複雑すぎて解決案が思いつかないからです。多くの場合、小さい問題を片付けていくうちに、問題が整理され、大きい問題の解決案が思いつきます。

注意が必要なのは、「ダブルチェック」という改善案です。自分はダブルチェックは効果が低いと考えています。2人でチェックする場合も、視点を変える、ペアで作業するなど、チェックする方法を工夫しています。

2.2. 改善の優先度を決める

真面目にメモをとると、改善したい点はたくさん出てきます。しかし一気に全ては改善できません。そのため、改善の優先度を決めます。

改善の優先度を決めるときには、次の4つを考慮します。

  • そのミスが起きる頻度
  • そのミスによって失われる時間
  • その作業に必要な集中力
  • ミスが起きたときの損害

「その作業に必要な集中力」というのはゲームに例えると消費MPに相当します。

スライムを倒すために毎回イオナズンを唱えていたらすぐMPがなくなりますよね。普通はメラ、ギラ、イオあたりを使いたいところです。まあ、そもそもスライム相手に呪文を使う必要はないですが・・・。

このように簡単な作業のはずなのに集中力が必要なもの、これは改善の優先度が高いです。

ただし優先度を数値で表したり、順番で並べたりはしません。自分が一番気になっているものから取り組むことが多いです。なぜなら「自分が一番気になっている=優先度が高い」と脳が判断しているからです。

2.3. 改善の方向性を考える

ここまで来ると多くの場合、改善の方向性が見えてきます。その場合は3.に進んでください。また逆に全く改善の方向性が見えない場合は、アイデアが思いつくまで頭の中に寝かせることもあります。

しかし全く改善の方向性が見えない場合に試してほしい考え方があります。それは「完璧を目指さない」です。ミスを100%防ごうとすると多くの場合仕掛けが大掛かりになり、手をつけるのがつらくなります。完璧を諦めることで、ちょっとした仕掛けで改善できることが多いです。具体的には次のような考え方を使います。

  • 一部の手順だけ自動化する
  • 実行と確認を分離する
  • 「ポカヨケ」を導入する

まず長い複雑な手順がある場合は、一部の手順だけでも自動化できないかを考えます。プログラムを書かなくても、コピペでできる作業を増やす、スプレッドシートに式を追加するなど、できることはたくさんあります。

次に、実行と確認を分離できないかを考えます。コンピュータが得意なのは定型的な作業です。そして、作業の実行は定型作業になりやすく、結果を見て判断をするのは定型作業になりにくいです。

そのため、作業の実行は自動化した上で、目視での確認を残します。もちろん目視はミスに繋がりやすいため、怪しい箇所のみ抜き出すなど、さらなる工夫が必要です。

プログラムを書く場合でも、自動化が最善とは限りません。自分はよく「ポカヨケ」ができないかを考えます。

「ポカヨケ」とは人がミスをするのを避けるための仕組みです(NHKの「2355」で知りました)。製造業で使われる言葉ですが、ITでも有用です。例えばファイルを削除しようとしたときに出るダイアログや、ゴミ箱機能はポカヨケの一種です。

前に書いたGoogle Meetでの離脱防止、ステータス表示もポカヨケの一種です。現在のステータスを目立つところに書くことで、ミスが激減しました。

このように、いろんな考え方を用いて改善の方向性を検討します。

3. 改善に取り組む

改善の方向性が決まったら、実際に改善に取り組みます。

3.1. 手順書の書き方

Googleドキュメントを使うこともありますが、基本はプレーンテキストです。もちろん、Markdownが基本です。

手順書は簡潔明瞭でないといけません。そして簡潔明瞭な文章を書くために必要なことは、読者層を考えることです。言い換えると、読者の前提知識を考えます。

例えば以前書いたHugoの記事の場合、CLI(コマンドライン)を使えること、Gitを使えること、GitHubにアカウントを持っていることを前提としています。Gitの解説記事ではないので、Gitのオプションの説明は最小限にしています。

また細かい話をすると、自分は書式設定をほとんど使いません。使うのは次の4つくらいです。

  • 見出し
  • 箇条書き(番号あり、番号なし)
  • 水平線
  • 太字(または赤字)

斜体は見づらく、下線は目立たないので使いません。強調するために文字の大きさは変えません。なぜなら、装飾は余計なノイズだからです。何種類も装飾を使いたくなるときは、文章自体を見直します。

ただし書式設定を避けるのは手順書だけで、それ以外の文書では積極的に使います。例えば赤は危険、青は安全のように、色に意味を持たせることで、文章が読みやすくなるからです。

3.2. 一から手順書を作る場合

ときには、一から手順書を作るときもあります。そのとき自分は、作業を実行する前に手順書を作れないかを考えます。

もちろん想像だけで作った手順書には間違いがたくさんあるでしょう。しかし、実行しながら手順書を作るよりは効率的でミスも少なくなります。そして事前に考え抜くことで、作業の理解が深まります。

作業をした後に可能ならば、作った手順書を一から見直して問題なく実行できるかどうかを確認します。最初に作った手順に漏れがあると次に手順書を読む人が困ります。手順書が冗長になる場合もありますが、それは構いません。

3.3. 判断は最初にまとめる

ときには、条件によって手順が変わる場合もあります。この場合は条件判断を手順の最初にまとめられないかを考えます。

プログラミングで言えば、最初に変数を設定するのと同じです。作業の途中で判断を入れると、ミスが起きやすくなります。最初に判断をまとめると以降の手順はほぼコピペで良くなり、ミスも少なくなります。

3.4. チェックリストを作る2つの場面

チェックリストは二つの使い道があります。

一つは、手順を考えるまでもない場合です。例えば自分は「毎朝やること」のチェックリストを作っており、その中の1つに「Slackを起動」があります。しかしSlackの起動方法は書きません。書くと冗長になります。

もう一つは、手順そのものが重要ではない場合です。例えばチーム開発のためにとあるネットサービスのアカウントが必要だとします。しかしそのアカウント取得手順を詳しく記載しても、使われる頻度に見合わないでしょう。そのような場合はチェックリストで済ませます。

チェックリストを作るときに気をつけているのは、チェックの順番です。チェックリストは通常上から順番にチェックしていきます。そのため、上から流れるように実行される必要があります。もし順番がズレていると、ミスが起きる可能性があります。順番が不自然だなと感じたら、並び替えをします。

3.5. 自動化の手法

3.1.から3.4.まで、手作業を前提とした手順書と、チェックリストの作り方を解説しました。なぜ手順書の説明を先にして、自動化の手法を後に解説したのでしょうか。その理由は、手順書を整備しておくと、自動化がものすごく楽になるからです。

逆に言えば、業務が整理されてない状態で自動化をすると、苦労が多くなります。自動化のコツは、現在の業務にツールを合わせるのではなく、ツールに業務を合わせることです。その第一歩としての標準化です。

自分が自動化をする場合、次のツールをよく使います。

  • シェルスクリプト
  • Ruby, Pythonなどのスクリプト言語
  • Ansible
  • Google Apps Script
  • Google Chrome拡張
    • Tampermonkey、Stylus
    • 自作する

これらは少ないコードで色々なことが出来るため、改善にはピッタリです。

自分は大きなプログラムを書くときはオブジェクト指向プログラミングを好みますが、小さいプログラムを書くときは、データ処理を意識して小さい関数に分けた方がメンテナンスしやすいです。

4. 改善を続ける

このように手順書、チェックリスト、自動化を使って改善を行います。しかし改善はその場かぎりのものではなく、継続的に行うものです。改善を行うことによって見えてきた新しい課題が出てくることもあります。また改善したつもりが逆効果になったり、もっと良い改善案が出てきてやったことが無駄になることもあります。一直線には進みません。

しかし少しずつでも改善を進めることで、ミスが減っていきます。スキルがアップします。仕事に余裕が出てきます。その余裕を改善に使うことで、さらに余裕が出てきます。余裕が出てくるとアイデアが出てくる、自分はそう考えています。

5. チームで取り組む場合

ここでは個人での業務改善について取り上げましたが、チームで取り組む場合は、個々のフェーズでチームメンバーへの相談・合意が入ります。特に多いのは「2.1.問題を整理する」「2.3.改善の方向性を考える」の2つです。

改善案を考えていると、どうしても自分中心になりがちです。そのまま突き進むと方向性がズレてしまうことが多いです。なので、問題を整理するときと、方向性を考えるときには他の人に相談することが多いです。

ただし、すべてにおいて合意を得ようとすると、改善のスピードが落ちてしまいます。ときには独断で進めることも必要です。もしそれで問題が起きたら素直に「ごめんなさい」と言います。

おわりに

かなり長くなりましたが、改善について自分が考えていること、取り組んでいることをまとめてみました。

自分でいうのもなんですが、ここまでこだわりがある人はなかなかいないと思います。自分にとって改善は仕事ではなく、もはや趣味の粋に達しています。楽しいので。

趣味とまではいかなくても、苦労を減らすために、いろいろ改善を楽しんでみるのはどうでしょうか。

採用情報

メンバーズエッジで最高のチームで最高のプロダクトを作りませんか?

最高のプロダクトをつくる 最高のチームで働く

在宅でも、地方でも、首都圏でも。多様な働き方で最高のチームをつくり、お客様のプロダクトパートナーを目指します。アジャイル開発を通じ、開発現場の第一線で活躍し続けたいエンジニアを募集しています。