あなたの依頼はなぜ失敗するのか?
仕事の依頼を上手く実施する方法について考えてみます。
チーム協働型の仕事では、メンバー間での情報のリレーで成り立っていると考えています。情報のリレーは、何かを成すために必要な情報を必要なところに集めるためにあると思われます。
情報のリレーがうまくいっているチームでは、仕事が進み、そうでないチームでは進みません。
進む進まないを大きく左右するのがコミュニケーションであり、その最小単位が依頼であると考えています(雑談やブレスト自体は、仕事を主としてみると、行為・アクションという側面が強い気がします)。
今日は、情報のリレーの中で重要な役割を担っている依頼について考えてみました。
依頼の定義
まず、国語辞書の定義を読んでみます。
依頼とは、「頼む人」「要件」「頼まれる人」の要素で成り立っていそうです。
依頼が完了するまでのライフタイムサイクル
願望が生まれ、依頼が生まれ、依頼が受け入れられ、依頼が小さなタスク(作業)群として実施され、実施結果が依頼者に届けられ、依頼に応え、願望が叶う。
そうして仕事は進んで行きます。
依頼が完了するとは、どのような状態でしょうか。
依頼者に対して、期待通りの情報(物質的な物も含む)が届けられ、願望が叶ったタイミングなのではないかと思います。
あなたの依頼はなぜ失敗するのか?
原因分析をすると伝え方の問題と依頼内容自体の問題がありそうです。
伝え方の問題
・依頼者が、期待や完了条件を正しく定義していない、または、伝えていないこと
・作業者が、依頼者の欲求(コンテキスト含む)を正しく理解できていないこと(依頼者が言語化した完了条件が誤っている可能性は頻繁に起きうる)
依頼内容の問題
・作業者が、真の顧客のためでなく、依頼者のために作業をする(コンテキスト理解不足)
・期待や完了条件へのアプローチ方法が不明で、作業ができないこと
などがあります。
・期限が明確でないので忘れ去られること
・依頼内容が巨大すぎる
上記のような問題に対処すべく、依頼をしっかり定義しようと考えたときに、すぐに思い浮かぶのが、要件定義をしっかり文書化しようということになります。
しかし、その要件定義文書は、何バージョンも改変が必要になり、メンテナンス不能に陥りますし、読み手からは読むのが大変!と言われてしまうでしょう。(思えば、10年前は、pptやwordの仕様書でPCが埋め尽くされていました)
しかし、現代はVUCAの時代。完全に見通すことなどできませんし。数々のプロジェクト失敗から人類は学び、ソフトウェア業界のプロジェクト管理方法であるアジャイルがソフトウェア開発以外においてもトレンドとなりつつあります。
我々も、不確実ななかでも着実にプロジェクトを前進させるアジャイル型での依頼が参考になりそうです。
依頼内容の問題は、後述のユーザーストーリーとタスクを分けて意識することで、改善できる可能性があります。
ユーザーストーリーとは
アジャイル開発では要件を核としての依頼は重要視しません。その代わりにユーザーストーリーという概念があります。
ユーザーストーリーは、ユーザーにとっての価値を意味します。ユーザーストーリーでは、ユーザー(顧客)の欲求を記述するもので、ユーザーストーリーが実現されることは、価値を生むものとなります。
ユーザーストーリーを意識することで、まず、価値にフォーカスしようという方向性が生まれます。(ユーザーストーリーとほぼ等価な用語にフィーチャーという言葉があります)
ユーザ側の視点から記述している。という点が重要です。
タスクとは実施可能な作業のこと
依頼というのは様々な粒度があります。依頼には様々な階層があるのですが、ユーザーストーリーの実現にあたって登場するタスクという概念を考えてみます。
タスクは、作業のことです。タスク実施=ユーザーストーリー実現になる場合と、そうでない場合があります。
タスク実施結果は、ユーザ(最終顧客)にとっては価値はないかもしれませんが、ユーザーストーリーを実現するために必要な作業と捉えると良いでしょう。
依頼とユーザーストーリー、タスクの関係
依頼とは、あなたが誰かにタスクを依頼することと言えます。ユーザーストーリーは、あなたが実現したい願望です。
私は、こんな願望(=ユーザーストーリー)を実現したい、願望実現にはこのタスク達の実施が必要なので、タスク達の実施を依頼できませんか?
という関係になります。ユーザーストーリーがあることで、コンテキストを伝えやすくなります。
あなたの依頼を改善するヒント
良いユーザーストーリーの書き方のヒントが指針になりそうです。
よいストーリーの特徴を覚えやすくするために INVEST という概念があり、日本語翻訳があったので、読んでみます。
良い依頼の書き方「ユーザーストーリー編」
ユーザーストーリーを書いてみます。注意として後述のタスクとは異なることを意識します。
ユーザが理解できるシンプルな言葉遣いで、テスト可能で、適度な粒度で、見積もり可能な形で、「何を」「誰のために」「なぜやるか」で書き下します。
良い依頼の書き方「分割編」
先に紹介したINVESTのSの指針に従った粒にしてみます。
ユーザーストーリーとタスクが異なることを意識しつつ、ユーザーストーリーを小さなユーザーストーリーとタスクに分割します。
ネット検索すると
といった言葉がみられますが、正確にはストーリーを伝えずにタスクを依頼してはならない。だと思います。
ストーリー達成には、タスクを直列・並列でつなぐことが必要だからです。
良い依頼の書き方「タスク編」
最後はタスクです。
ユーザーストーリーになる・ならない。は別として、
完了条件と具体的に実現したいコトを書くことが必要です
最後に
書き方にフォーカスして書きましたが、依頼が失敗する主な原因はコミュニケーション・ミスにあると思います。
説明が不適切なために、内容について混乱しないよう、説明は簡潔で、適切で、誰もが理解できるようにする必要がある一方で、チーム内の阿吽の呼吸を訓練して、コミュニケーションしやすい環境やカルチャーを育むことはチームの強みになるでしょう。
ここまで読んでいただき、ありがとうございました!
私たちは共同タスク管理システム「PATHWORK(パスワーク)」を運営しています。
プロジェクト運営や共同タスク管理をもっと効率化したい状況に、とてもおすすめです。
無料プランもありますので、ぜひご利用してください。
この記事が気に入ったらサポートをしてみませんか?