あなたの依頼はなぜ失敗するのか？
仕事の依頼を上手く実施する方法について考えてみます。
チーム協働型の仕事では、メンバー間での情報のリレーで成り立っていると考えています。情報のリレーは、何かを成すために必要な情報を必要なところに集めるためにあると思われます。
情報のリレーがうまくいっているチームでは、仕事が進み、そうでないチームでは進みません。
進む進まないを大きく左右するのがコミュニケーションであり、その最小単位が依頼であると考えています（雑談やブレスト自体は、仕事を主としてみると、行為・アクションという側面が強い気がします）。
今日は、情報のリレーの中で重要な役割を担っている依頼について考えてみました。
依頼の定義
まず、国語辞書の定義を読んでみます。
依頼とは物事を頼んで、まかせること、特定の物事をしてもらうように頼むことなどを意味する表現。
実用日本語表現辞典
［名］(スル)
１ 人に用件を頼むこと。「依頼を引き受ける」「執筆を依頼する」
２ 他人を当てにすること。頼み。「依頼心が強い」
デジタル大辞泉より
依頼とは、「頼む人」「要件」「頼まれる人」の要素で成り立っていそうです。
依頼が完了するまでのライフタイムサイクル
願望が生まれ、依頼が生まれ、依頼が受け入れられ、依頼が小さなタスク（作業）群として実施され、実施結果が依頼者に届けられ、依頼に応え、願望が叶う。
そうして仕事は進んで行きます。
依頼が完了するとは、どのような状態でしょうか。
依頼者に対して、期待通りの情報（物質的な物も含む）が届けられ、願望が叶ったタイミングなのではないかと思います。
あなたの依頼はなぜ失敗するのか？
原因分析をすると伝え方の問題と依頼内容自体の問題がありそうです。
伝え方の問題
・依頼者が、期待や完了条件を正しく定義していない、または、伝えていないこと
・作業者が、依頼者の欲求（コンテキスト含む）を正しく理解できていないこと（依頼者が言語化した完了条件が誤っている可能性は頻繁に起きうる）
依頼内容の問題
・作業者が、真の顧客のためでなく、依頼者のために作業をする（コンテキスト理解不足）
・期待や完了条件へのアプローチ方法が不明で、作業ができないこと
などがあります。
・期限が明確でないので忘れ去られること
・依頼内容が巨大すぎる
上記のような問題に対処すべく、依頼をしっかり定義しようと考えたときに、すぐに思い浮かぶのが、要件定義をしっかり文書化しようということになります。
しかし、その要件定義文書は、何バージョンも改変が必要になり、メンテナンス不能に陥りますし、読み手からは読むのが大変！と言われてしまうでしょう。（思えば、10年前は、pptやwordの仕様書でPCが埋め尽くされていました）
しかし、現代はVUCAの時代。完全に見通すことなどできませんし。数々のプロジェクト失敗から人類は学び、ソフトウェア業界のプロジェクト管理方法であるアジャイルがソフトウェア開発以外においてもトレンドとなりつつあります。
我々も、不確実ななかでも着実にプロジェクトを前進させるアジャイル型での依頼が参考になりそうです。
依頼内容の問題は、後述のユーザーストーリーとタスクを分けて意識することで、改善できる可能性があります。
ユーザーストーリーとは
アジャイル開発では要件を核としての依頼は重要視しません。その代わりにユーザーストーリーという概念があります。
ユーザーストーリーは、ユーザーにとっての価値を意味します。ユーザーストーリーでは、ユーザー（顧客）の欲求を記述するもので、ユーザーストーリーが実現されることは、価値を生むものとなります。
ユーザーストーリーを意識することで、まず、価値にフォーカスしようという方向性が生まれます。（ユーザーストーリーとほぼ等価な用語にフィーチャーという言葉があります）
例）
プリンターに赤インクを補填できることは機能であって、ユーザーストーリーではない。この場合はフルカラーで印刷できることがユーザーストーリー
ECならば、商品選択画面、注文処理画面、支払い画面、注文完了画面の各画面はそれぞれ機能であり、ユーザーストーリーではない。欲しい商品を注文できることがユーザーストーリー。
アジャイルな見積りと計画づくり-価値あるソフトウェアを育てる概念と技法 より
ユーザ側の視点から記述している。という点が重要です。
タスクとは実施可能な作業のこと
依頼というのは様々な粒度があります。依頼には様々な階層があるのですが、ユーザーストーリーの実現にあたって登場するタスクという概念を考えてみます。
タスクは、作業のことです。タスク実施＝ユーザーストーリー実現になる場合と、そうでない場合があります。
タスク実施結果は、ユーザ（最終顧客）にとっては価値はないかもしれませんが、ユーザーストーリーを実現するために必要な作業と捉えると良いでしょう。
ユーザーストーリーとタスクの違い
ユーザーストーリーを分割していくと、最終的にはタスクに落とし込まれる。
ユーザーストーリーは複数のタスクから構成されて、すべてのタスクが完了すればユーザーストーリーも完了となる。
一方で、ユーザーストーリーは分割して、小さなユーザーストーリーの集合とすることも可能だ。
参考：ユーザーストーリーとタスクの違い
依頼とユーザーストーリー、タスクの関係
依頼とは、あなたが誰かにタスクを依頼することと言えます。ユーザーストーリーは、あなたが実現したい願望です。
私は、こんな願望（＝ユーザーストーリー）を実現したい、願望実現にはこのタスク達の実施が必要なので、タスク達の実施を依頼できませんか？
という関係になります。ユーザーストーリーがあることで、コンテキストを伝えやすくなります。
あなたの依頼を改善するヒント
良いユーザーストーリーの書き方のヒントが指針になりそうです。
よいストーリーの特徴を覚えやすくするために INVEST という概念があり、日本語翻訳があったので、読んでみます。
Independent（独立している）：どのストーリーも、順番を気にせずに出荷できること。
Negotiable（交渉可能である）：ストーリーの内部の詳細は、開発中にプログラマーと顧客の共同作業で作り上げること。
Valuable（価値がある）：そのストーリーの機能が、顧客あるいはそのソフトウェアのユーザーにとって価値があるものであること。
Estimable（見積もり可能である）：プログラマーがストーリーを実装するにあたって、妥当な見積もりができること。
Small（粒が小さい）：ストーリーの実装にかかる時間は少なくすること。通常は数人日程度になる。 少なくとも、1回のイテレーションで複数のストーリーを完成させるくらいでなければいけない。
Testable（テスト可能である）：ストーリーが正しく機能することを確認するためのテストを書けること
https://bliki-ja.github.io/UserStory/ より
良い依頼の書き方「ユーザーストーリー編」
ユーザーストーリーを書いてみます。注意として後述のタスクとは異なることを意識します。
ユーザが理解できるシンプルな言葉遣いで、テスト可能で、適度な粒度で、見積もり可能な形で、「何を」「誰のために」「なぜやるか」で書き下します。
ユーザーストーリーの例
「役割」として、「機能」が欲しい。それは「利益」のためだ。
「利益」のために、「役割」として、「機能」が欲しい
カンバン仕事術より
ストーリーを書くときによく使われる、お決まりの書式がある。
「…として、…をしたい。なぜなら…だからだ」というものだ。
「として」には、誰がそのストーリーを欲しているのかを書く。
「をしたい」には、どんな機能なのかを書く。
そして「なぜなら」には、なぜその機能が欲しいのかを書く。
「なぜなら」の部分が、 顧客が実際に欲しいと思っていることから、顧客が実際に必要なものを読み取るための重要な手がかりになる
https://bliki-ja.github.io/UserStory/ より
良い依頼の書き方「分割編」
先に紹介したINVESTのSの指針に従った粒にしてみます。
Small（粒が小さい）：ストーリーの実装にかかる時間は少なくすること。通常は数人日程度になる。 少なくとも、1回のイテレーションで複数のストーリーを完成させるくらいでなければいけない
https://bliki-ja.github.io/UserStory/ より
ユーザーストーリーとタスクが異なることを意識しつつ、ユーザーストーリーを小さなユーザーストーリーとタスクに分割します。
ネット検索すると
ストーリーをタスクに分解してはならない。
といった言葉がみられますが、正確にはストーリーを伝えずにタスクを依頼してはならない。だと思います。
ストーリー達成には、タスクを直列・並列でつなぐことが必要だからです。
小さなユーザーストーリーとタスクの違いはなにか。
一番の違いは、完了することでユーザーにとっての価値が生まれるかどうかだと思う。
タスクはどんなに大きいものであっても、内部作業である。開発者の自己満足みたいなもの。
タスクをいくらこなしても、それが結びついているユーザーストーリーとして完了していない場合はユーザーにとって価値が生まれない。
参考：ユーザーストーリーとタスクの違い
だからこそ、MVP（Minimum Viable Product：最低限実行可能なプロダクト）をまず作り出して、そこからインクリメントに開発していくことが重要視される。
多くのタスクを一気にこなすことが素晴らしいのではなく、早く継続的にユーザーストーリーを完了させていくことの方が大切。
可能であれば、「ユーザーストーリー ＝ タスク」となるように分割できるといい。目の前のタスクをひとつ完了すれば、価値が生まれるわけだから。
参考：ユーザーストーリーとタスクの違い
良い依頼の書き方「タスク編」
最後はタスクです。
ユーザーストーリーになる・ならない。は別として、
完了条件と具体的に実現したいコトを書くことが必要です
最後に
書き方にフォーカスして書きましたが、依頼が失敗する主な原因はコミュニケーション・ミスにあると思います。
説明が不適切なために、内容について混乱しないよう、説明は簡潔で、適切で、誰もが理解できるようにする必要がある一方で、チーム内の阿吽の呼吸を訓練して、コミュニケーションしやすい環境やカルチャーを育むことはチームの強みになるでしょう。
ここまで読んでいただき、ありがとうございました！
私たちは共同タスク管理システム「PATHWORK（パスワーク）」を運営しています。
プロジェクト運営や共同タスク管理をもっと効率化したい状況に、とてもおすすめです。
無料プランもありますので、ぜひご利用してください。
この記事が気に入ったらサポートをしてみませんか？