仕事を人に任せられず忙殺されてる人へ: 小さな組織向け業務設計の方法

f:id:hirokiky:20180505200854j:plain

こんな悩みはありませんか？

なぜか忙しくてメインの仕事が進まない
人に任せられない仕事を常に抱えている
人に任せたは良いがうまくいかない

私はあります。日々仕事をする中で悩んでいます。その中で実践して、見つけたことを今日はお話します（まだまだ勉強中なのでフィードバックを貰えると嬉しいです）。

忙しいのは「見えない仕事」に追われているから です。
人に任せられないのは見えない仕事を定義しないから です。

ただしこの話は「手順書を書こう」という話ではありません。むしろ手順書は無い方が良いです。

ではどう業務設計すれば良いのでしょうか？それを説明します。

対象の人

業務要件定義や業務設計というと、かなりお硬い印象があるかもしれません。実際に「業務設計」などで検索すると硬い組織での情報が多くでます。でも私は小さな組織にこそ業務設計が必要だと私は考えています。

数人規模の組織を対象にしています。とくに新しい事業を始めているチームやスタートアップを想定して書いています。私自身が PyQ のチームでの経験などを元にしているからです。この記事で言う「業務設計」はあくまでも私の中での方法と定義になります。

見えない仕事とは何か

見えない仕事とは「業務として明確に認知されてないがやっている仕事」です（私が今しがた作った言葉です）。

「インフラの状態を確認する」など日々何気なくやっている仕事
「サポート対応」のようにぼんやり認知されているがフローや時間の使い方が明確でない仕事

今回の話では2のような「明確になっていない業務フロー」も改善の対象と考えます。 2を含めれば、組織の中にはむしろ見えない仕事のほうが多いかも知れません。暗黙知として共有されているものの、何をすれば良いかや求める質は人によって違うことが多いものです。

業務になっていないことの問題は？

業務として設計されていない問題はなんでしょうか？理由は2つあります。

仕事として新しい人に任せにくい
任せたとしても品質や作業時間にバラつきができる

定義が曖昧なまま作業を依頼すると、個人の解釈やその人の中での「求めるレベル」に質は依存してしまいます。「なんでこれもできないの」、「なんで反応してくれないの」、「なんでこのレベルで出すの」など依頼者側は思いがちですが、単純に共有できていないのが問題です。

傾向として依頼する側はその仕事や事業により深く関わっていることが多いです。なので「意識レベル」のようなものは依頼される側よりも高いはずです。この意識の格差が軋轢を産んでしまいます。逆に考えれば、あなたにとっても「事務処理」などは重要でない仕事かもしれませんが、総務の人に取っては大切な仕事ですよね。

「それらを共有できてる人とだけ仕事をする」というのは1つの正解です。ですが、それがうまくいっているのは 仕事のできる人は自分の中で業務設計ができる からです。永遠に居続けてもらえるわけではないですし、新しいできる人が脳内で業務設計するコストもかかってしまいます。自分にとっても覚えておくという見えないコストがかかっています。なので、簡単にでも業務設計をすることは大切です。

なぜ業務設計をすべき？

業務設計や業務の定義をするのは、「誰でも効果的に仕事をできるようにする」ため です。上記のような問題を解決するために、先に決めておこう、明確にしておこうというのが業務設計です。

ただし、何でもかんでも業務として定義すれば良いという訳ではありません。暗黙知で回っていて十分な業務はそれで良いです。業務設計をするタイミングは以下です

何もできていないのに、なぜか忙しい
人に依頼していて、かつ依頼される側の負荷や人によるムラが大きい

基本的には人と関わるときにコミュニケーションとして定義するのが一番です。ですが、自分の業務を定義して改善していくキッカケになることを思えば、自分自身のために定義しても良いでしょう（明確でないものを改善していくことはできません）。

業務設計、定義の仕方

ではどう業務を設計すれば良いのでしょうか？重要なのは以下を書き出すことです

「業務」の存在の明確化と細分化
背景、ビジョン、とりくむ姿勢
役割
評価指標の用意
フローや流れ、やること
テンプレートの用意、自動化
（おまけとして）手順書の用意

「業務設計」というと一般的には最後の手順（マニュアル）を指すように思いますが、そうではありません。多くの人はいきなり手順書や事例ベースの説明だけ書いて、本質の伝わらないドキュメントを量産しすぎです。

まずは以上の順でドキュメントに書き出すことが大切です。

1. 業務としての存在と細分化

まずは「その業務がここにある」が分かるだけでも大きな一歩です。仕事には何があるかを細分化して書き出していきましょう。

例えば「サポート対応」という未定義の仕事を対象に考えると、以下のような内容があるのではないでしょうか。

サポート対応
- お客様への質問への回答
- 製品、サービスへのフィードバックの対応
- 法人向けプランの問い合わせや見積もり依頼

細分化することで、明確にすべき業務に何があるのかがよりハッキリ分かるようになります。これにより業務の目的やゴールが見えてきます。人間は名前をつけていないものを認識できません 。まず、「こういう業務があるな」と定義することから始めましょう。

2. 背景、ビジョン、とりくむ姿勢などのバックグラウンド

マニュアル化の問題は作業者を無知にしてしまうことです 。そのならないように、背景の情報や、自分たちのビジョン、とりくむ姿勢があれば共有しておきましょう。「依頼者の期待するレベル」に引き上げるために、バックグラウンドの説明と共有が大切です。

システム系の作業であれば「背景」や「構成」を共有する
タスクや開発であれば「ビジョン」や「あるべき姿」を共有する
お客様対応や人とのやり取りであれば「とりくむ姿勢」や「マインド」を共有する

例えば「サポート対応」業務であれば、以下のような「マインド」を共有しておくと良いでしょう。

サポート対応にとりくむ姿勢、マインド:
- お客様を助けてあげようという姿勢でサポートしよう
- 何かできることは無いかと考えよう。お客様が成功するためには何ができるか考えよう
- クレームはあくまでサービスへの不満として考え、自分の心への攻撃ではないと考えよう
サポート業務への姿勢:
- なるべくFAQや回答のテンプレートを活用して効率化していこう
  - お客様も質問したりメールするのは大変

あなたの姿勢や背景の理解は素晴らしいものです。それを明文化して、関わるすべての人がその水準やポジティブな気持ちで仕事できるようにしましょう。

3. 役割を分ける

仕事の中で複数の役割があるのであれば、明確にしておきましょう。とくに「どの範囲について責任を持つのか」を明確にするとトラブルを避けやすいです。

例えば「研修をする仕事」について役割を設計するとすれば以下のようになります

講師
- 研修当日に研修生が内容を深く理解することに責任を持つ
アシスタント
- 研修当日に講師が滞りなく研修ができることに責任を持つ
マネージャー
- 研修をしたいお客様の求めるレベルに研修生が学ぶことに責任を持つ
- お客様とのやり取りが滞りなく行われることに責任を持つ
- 研修内容、費用、日程、アサインする講師とアシスタントを決める責任を持つ
総務
- お客様への請求、お金のやり取りに責任を持つ
- 研修に必要な新幹線のチケット、ホテルの手配に責任を持つ

このとき 役割は1人が複数を兼任しても良いと考えます 。1人で仕事をしているときは兼任が多くなります。ですが、「それぞれどういう役割があるか」を意識するとこでやるべき業務が明確になります。

4. 評価指標を決める

できれば業務について評価指標があるとより良いでしょう（必須ではありません）。仕事についてどこまでのクオリティを求めるかが明確になるからです。

求める指標が分かることで注力すべき点が明確になる
指標を改善していくサイクルが生まれる

例えば研修後にいただくお客様のアンケートの結果などが考えられます。

注意したいのが、数値に対して早すぎる最適化をしないことです。指標が良い指標であれば良いのですが、業務設計した最初は指標そのもののや取得方法の質が低いものです。指標がどの程度参考にすべき値なのかも共有しておくと安心です。

5. フローや流れ、やること、やらないこと

業務に「大まかにどういった流れがあるのか」を明確にします。役割とあわせて明確にするとより良いでしょう。

例えば「お見積」であれば以下のようなフローが考えられます

お客様からメールでお見積もりの問い合わせをいただく
（事務）メールで一次回答をする
（事務）社内システムに見積もり依頼があったことを登録する
（経営者）担当者をアサインする
（担当者）依頼内容を見て見積もりをする
- 情報が不十分であればメールで返信し、問い合わせする
- 対面のほうが早そうであればお客様にヒアリングをするミーティングを設定する
- ミーティングはお客様が良ければオンラインのほうが効率的
（担当者）社内システムで見積もり書を発行してお客様にメールする
...