こんな悩みはありませんか？
- なぜか忙しくてメインの仕事が進まない
- 人に任せられない仕事を常に抱えている
- 人に任せたは良いがうまくいかない
私はあります。日々仕事をする中で悩んでいます。その中で実践して、見つけたことを今日はお話します（まだまだ勉強中なのでフィードバックを貰えると嬉しいです）。
- 忙しいのは「見えない仕事」に追われているから です。
- 人に任せられないのは見えない仕事を定義しないから です。
ただしこの話は「手順書を書こう」という話ではありません。
むしろ手順書は無い方が良いです。
ではどう業務設計すれば良いのでしょうか？
それを説明します。
対象の人
業務要件定義や業務設計というと、かなりお硬い印象があるかもしれません。
実際に「業務設計」などで検索すると硬い組織での情報が多くでます。
でも私は小さな組織にこそ業務設計が必要だと私は考えています。
数人規模の組織を対象にしています。とくに新しい事業を始めているチームやスタートアップを想定して書いています。私自身が PyQ のチームでの経験などを元にしているからです。
この記事で言う「業務設計」はあくまでも私の中での方法と定義になります。
見えない仕事とは何か
見えない仕事とは「業務として明確に認知されてないがやっている仕事」です（私が今しがた作った言葉です）。
- 「インフラの状態を確認する」など日々何気なくやっている仕事
- 「サポート対応」のようにぼんやり認知されているがフローや時間の使い方が明確でない仕事
今回の話では2のような「明確になっていない業務フロー」も改善の対象と考えます。
2を含めれば、組織の中にはむしろ見えない仕事のほうが多いかも知れません。
暗黙知として共有されているものの、何をすれば良いかや求める質は人によって違うことが多いものです。
業務になっていないことの問題は？
業務として設計されていない問題はなんでしょうか？理由は2つあります。
- 仕事として新しい人に任せにくい
- 任せたとしても品質や作業時間にバラつきができる
定義が曖昧なまま作業を依頼すると、個人の解釈やその人の中での「求めるレベル」に質は依存してしまいます。「なんでこれもできないの」、「なんで反応してくれないの」、「なんでこのレベルで出すの」など依頼者側は思いがちですが、単純に共有できていないのが問題です。
傾向として依頼する側はその仕事や事業により深く関わっていることが多いです。なので「意識レベル」のようなものは依頼される側よりも高いはずです。この意識の格差が軋轢を産んでしまいます。逆に考えれば、あなたにとっても「事務処理」などは重要でない仕事かもしれませんが、総務の人に取っては大切な仕事ですよね。
「それらを共有できてる人とだけ仕事をする」というのは1つの正解です。ですが、それがうまくいっているのは 仕事のできる人は自分の中で業務設計ができる からです。
永遠に居続けてもらえるわけではないですし、新しいできる人が脳内で業務設計するコストもかかってしまいます。自分にとっても覚えておくという見えないコストがかかっています。なので、簡単にでも業務設計をすることは大切です。
なぜ業務設計をすべき？
業務設計や業務の定義をするのは、「誰でも効果的に仕事をできるようにする」ため です。
上記のような問題を解決するために、先に決めておこう、明確にしておこうというのが業務設計です。
ただし、何でもかんでも業務として定義すれば良いという訳ではありません。
暗黙知で回っていて十分な業務はそれで良いです。業務設計をするタイミングは以下です
- 何もできていないのに、なぜか忙しい
- 人に依頼していて、かつ依頼される側の負荷や人によるムラが大きい
基本的には人と関わるときにコミュニケーションとして定義するのが一番です。
ですが、自分の業務を定義して改善していくキッカケになることを思えば、自分自身のために定義しても良いでしょう（明確でないものを改善していくことはできません）。
業務設計、定義の仕方
ではどう業務を設計すれば良いのでしょうか？
重要なのは以下を書き出すことです
- 「業務」の存在の明確化と細分化
- 背景、ビジョン、とりくむ姿勢
- 役割
- 評価指標の用意
- フローや流れ、やること
- テンプレートの用意、自動化
- （おまけとして）手順書の用意
「業務設計」というと一般的には最後の手順（マニュアル）を指すように思いますが、そうではありません。
多くの人はいきなり手順書や事例ベースの説明だけ書いて、本質の伝わらないドキュメントを量産しすぎです。
まずは以上の順でドキュメントに書き出すことが大切です。
1. 業務としての存在と細分化
まずは「その業務がここにある」が分かるだけでも大きな一歩です。
仕事には何があるかを細分化して書き出していきましょう。
例えば「サポート対応」という未定義の仕事を対象に考えると、以下のような内容があるのではないでしょうか。
- サポート対応
- お客様への質問への回答
- 製品、サービスへのフィードバックの対応
- 法人向けプランの問い合わせや見積もり依頼
細分化することで、明確にすべき業務に何があるのかがよりハッキリ分かるようになります。
これにより業務の目的やゴールが見えてきます。人間は名前をつけていないものを認識できません 。まず、「こういう業務があるな」と定義することから始めましょう。
2. 背景、ビジョン、とりくむ姿勢などのバックグラウンド
マニュアル化の問題は作業者を無知にしてしまうことです 。
そのならないように、背景の情報や、自分たちのビジョン、とりくむ姿勢があれば共有しておきましょう。「依頼者の期待するレベル」に引き上げるために、バックグラウンドの説明と共有が大切です。
- システム系の作業であれば「背景」や「構成」を共有する
- タスクや開発であれば「ビジョン」や「あるべき姿」を共有する
- お客様対応や人とのやり取りであれば「とりくむ姿勢」や「マインド」を共有する
例えば「サポート対応」業務であれば、以下のような「マインド」を共有しておくと良いでしょう。
- サポート対応にとりくむ姿勢、マインド:
- お客様を助けてあげようという姿勢でサポートしよう
- 何かできることは無いかと考えよう。お客様が成功するためには何ができるか考えよう
- クレームはあくまでサービスへの不満として考え、自分の心への攻撃ではないと考えよう
- サポート業務への姿勢:
- なるべくFAQや回答のテンプレートを活用して効率化していこう
あなたの姿勢や背景の理解は素晴らしいものです。それを明文化して、関わるすべての人がその水準やポジティブな気持ちで仕事できるようにしましょう。
3. 役割を分ける
仕事の中で複数の役割があるのであれば、明確にしておきましょう。
とくに「どの範囲について責任を持つのか」を明確にするとトラブルを避けやすいです。
例えば「研修をする仕事」について役割を設計するとすれば以下のようになります
- 講師
- 研修当日に研修生が内容を深く理解することに責任を持つ
- アシスタント
- 研修当日に講師が滞りなく研修ができることに責任を持つ
- マネージャー
- 研修をしたいお客様の求めるレベルに研修生が学ぶことに責任を持つ
- お客様とのやり取りが滞りなく行われることに責任を持つ
- 研修内容、費用、日程、アサインする講師とアシスタントを決める責任を持つ
- 総務
- お客様への請求、お金のやり取りに責任を持つ
- 研修に必要な新幹線のチケット、ホテルの手配に責任を持つ
このとき 役割は1人が複数を兼任しても良いと考えます 。1人で仕事をしているときは兼任が多くなります。ですが、「それぞれどういう役割があるか」を意識するとこでやるべき業務が明確になります。
4. 評価指標を決める
できれば業務について評価指標があるとより良いでしょう（必須ではありません）。
仕事についてどこまでのクオリティを求めるかが明確になるからです。
- 求める指標が分かることで注力すべき点が明確になる
- 指標を改善していくサイクルが生まれる
例えば研修後にいただくお客様のアンケートの結果などが考えられます。
注意したいのが、数値に対して早すぎる最適化をしないことです。
指標が良い指標であれば良いのですが、業務設計した最初は指標そのもののや取得方法の質が低いものです。指標がどの程度参考にすべき値なのかも共有しておくと安心です。
5. フローや流れ、やること、やらないこと
業務に「大まかにどういった流れがあるのか」を明確にします。
役割とあわせて明確にするとより良いでしょう。
例えば「お見積」であれば以下のようなフローが考えられます
- お客様からメールでお見積もりの問い合わせをいただく
- （事務）メールで一次回答をする
- （事務）社内システムに見積もり依頼があったことを登録する
- （経営者）担当者をアサインする
- （担当者）依頼内容を見て見積もりをする
- 情報が不十分であればメールで返信し、問い合わせする
- 対面のほうが早そうであればお客様にヒアリングをするミーティングを設定する
- ミーティングはお客様が良ければオンラインのほうが効率的
- （担当者）社内システムで見積もり書を発行してお客様にメールする
- ...
このように大まかな流れと、どんな役割の人が関わるかを明記すると良いでしょう。
これによって「作業の取りこぼし」や「誰にも触れられない仕事」が発生することを防ぎます。
「やってはいけないこと」があるのであれば明確に書いておくと安心です。
やることは書いていて 「やらないこと」「やってはいけないこと」が書いていないと、どこまで自由に考えてやっていいかが分かりません 。ある程度は自由に動けるように、やらないこと・やってはいけないことを明確にしておきましょう。
また、「こうした方が良いよ」というTipsもあれば書いておくと良いでしょう。
新しく仕事をする人がノウハウを身につけるよりも、教えてあげたほうが早いです。
6. テンプレートを用意、自動化
上記のフローについて「タスク」のテンプレートなどを用意しておくと良いでしょう。
- 業務を追跡するタスクのテンプレートを用意しておく
- 作るべき書類やシートのテンプレートを用意しておく
- 必要な作業を自動化して短縮できるようにしておく
このテンプレートがカッチリと決まっていると、作業者は「何を作れば良いのか」が明確になって安心です。また、仕事を終わりまでトラッキングするタスクがあれば「仕事の取りこぼし」も発生しませんし、「背景」や「姿勢」を説明したドキュメントへのリンクも書いておくことができます。
7. 手順書（はあまり大事じゃない？)
手順は、明確にどういう操作をすべきかを書いたものです。
これは操作方法を知らない人がどうすれば良いかがハッキリ分かるように決めたものです。
ですが、私個人としては 手順書はないに越したことはない と考えています。
理由は以下です
- 簡単な画面の操作方法であれば一度伝えれば十分
- 画面が分かりやすく、ミスや失敗がおこらない用に設計されているべき
- 手順よりも「テンプレート」を用意したほうが効率が良い
- 「メールを書く」作業よりも、そのテンプレートを用意した方が楽で早い
- 自動化する
- 仕組みで自動化したり、ヒアリングしなくて済むようにシステムを用意したほうが早い
手順書は画面が変われば壊れてしまいますし、手順通りでない場合の対応ができなくなりやすいです。
私は用意するコストの割に効果が薄いと考えています。
大事なのは上記の「背景」を共有しておくことと、テンプレートやフローを定義しておくことです。
それがあれば「業務」としては十分に明確です。
業務設計と聞いて手順書を用意するのは絶対にやめましょう。むしろ、一番費用対効果が悪いのが手順書です。
おわりに
「見えない仕事」があるから忙しい、「見えない仕事」だから人に依頼できないと話しました。
それには業務設計が必要だと話しました。業務設計には「明確化と細分化」、「背景」、「役割、「フロー」、「テンプレートと自動化」とおまけで「手順書」が大切と話しました。
今回の話は私が PyQ で製品開発をするなかや、会社での仕事を見直すときに使った考え方です。小さい組織にこそ大切な考え方だと思っています。
繰り返しになりますが、これはあくまでも私の考えであり、私なりの定義です。
謝辞
今回の内容は以下の「はじめの一歩を踏み出そう」という本から強く影響を受けています。
学んだ中で実践して、私なりに定義したのが今回お話したことです。
レッツトライ
明日からの仕事で、ぜひ参考にしてくれると嬉しいです
- どういう「見えない業務」があるかを考えてみよう
- 人に依頼している、一緒にやっているが明確でない業務はどれくらいあるだろう
- 依頼したほうが楽になるなということはどれくらいあるだろう
できれば、今回の内容で業務設計をしてみて、フィードバックいただければと思います。
私もまだまだ勉強中で改良中の身です。ぜひ新しく事業を始める人たちの助けになり、私も勉強できればと思っています。
