依頼のライフサイクルとは。止まるのは作業中ではなく、受ける返事の前

コラム一覧へ戻る

依頼を出して3日、画面には送信済みしか出ていない

営業担当が、制作チームに提案書の図版作成を頼むとします。チャットで仕様を書いて送り、期限を来週金曜と添えます。

3日経ちます。制作チームからの返事はありません。営業担当が見られるのは、自分が送ったメッセージが既読になっているかどうかだけです。制作チームが着手したのか、後回しにしたのか、そもそも受けるつもりがあるのかは、画面に出ていません。

4日目に営業担当が催促します。制作チームの返事は「先週の件、仕様のここが決まってなくて止めてました」でした。3日間、作業は1分も進んでいません。それでも記録上は、依頼を出してから4日が経過しています。

消えた3日は、作業の遅れではありません。かといって、制作チームが放置したとも言い切れません。名前のついていない区間で消えています。

依頼1件は4つの段階を通る

この区間に名前を与えた研究があります。Action Technologies の Raul Medina-Mora、Terry Winograd、Rodrigo Flores、Fernando Flores が1992年の CSCW（コンピュータ支援協調作業）会議で発表した論文で、業務の1件を「アクションワークフロー・ループ」として描いています。

論文は、ループには必ず依頼者（customer）と受け手（performer）がいて、受け手が依頼者の満足するところまで仕上げると約束した1つの行為を扱う、と書いています¹。そのうえで、ループは4つの段階を進むとしています²。

1. 提案。依頼者が、何ができたら終わりかを示して依頼する（受け手から申し出る場合もある）
2. 合意。両者が、終わりの条件と、次の手を打つ期日について合意する
3. 実行。受け手が、依頼者に対して完了を宣言する
4. 受領。依頼者が、受け手に対して完了で問題ないと宣言する

レペリオでは以前から、この前後を広げて整理してきました。依頼の手前には依頼者の「こうなってほしい」があり、後ろにはそれが叶ったかどうかがあります。頼まれた文面と、叶えたい状態は別物です。

先ほどの3日間は、この並びのどこかというと、1と2の間です。提案は済んでいて、合意はまだ起きていません。

2番目の段階で、なぜ返事が止まるのか

論文は、2番目の段階で決めるものを2つ挙げています。何ができたら終わりかという条件と、次の手を打つ期日です。裏返すと、この2つが揃わないうちは、受け手は「受けます」と言えません。

依頼文に書かれた文字が、依頼の全部ではないからです。ユーザーストーリーの3C（カード、会話、確認）を2001年に書いた Ron Jeffries は、カードは要求を作る情報を全部は含んでおらず、要求を指し示すための札だと説明しています³。依頼のチャット1通も同じで、指し示しているだけです。

Jeffries はもう1つ書いています。依頼者は、してほしいことを伝えるときに、どうやって出来たことを確かめるかを一緒に伝える、としています⁴。確かめ方まで渡されて、受け手はようやく引き受けられます。

営業担当のチャットには、確かめ方が書かれていませんでした。制作チームは仕様を聞き返そうとしましたが、その日は別件で埋まっていて、翌日には忘れました。聞き返さなかったことは、どこにも記録されません。

止まっているのは3番目の実行ではなく、2番目の合意です。ただし、タスク管理ツールでよく見る状態は「未着手／作業中／完了」の3つで、これは3番目と4番目を分けたものです。1番目と2番目はどちらも「未着手」に入ります。合意が起きたかどうかは、画面のどこにも出ません。

「チャットで『お願いします』『了解です』とやり取りしているから足りている」という見方はあります。ただし、その「了解です」は会話の流れに混ざって、数十件下へ流れます。3日後に「あの件、了解って返ってきてたっけ」と探すのは依頼者です。探す作業が発生する時点で、状態として持てていません。

線を引くのは、責任が移る2か所に絞る

段階を細かく分けるほど、記録の手間は増えます。4段階それぞれに入力欄を作り、全部の依頼に通そうとすれば、今度は入力のほうで業務が止まります。

線を引くのは、ボールの持ち主が入れ替わる箇所だけで足ります。依頼1件では2か所です。

• 依頼者から受け手へ移る箇所（受け手が「受けます」と返したとき）
• 受け手から依頼者へ戻る箇所（受け手が「終わりました」と返したとき）

この2か所に状態を置くと、遅れの内訳が出せます。受けるまでに何日、受けてから終わるまでに何日、と分かれます。前者が長いチームは、依頼文の書き方か、受け手の手前の詰まりを直す話になります。後者が長いチームは、作業量か割り込みの話になります。打つ手がまるで違うので、この2つは分けておく価値があります。

なお、依頼のうち「受けます」の返事を待つ意味があるのは、相手が動かないと自分の作業が止まるものだけです。共有のための連絡まで合意の段階を通すと、確認の往復だけが増えます。

PATHWORKで、受けたかどうかを記録に残す

PATHWORK では、依頼と@メンションを「パス」という1つの単位で扱い、delivered（届いた）、seen（見られた）、acknowledged（受領応答済み）、replied（返信）、escalated（エスカレート済み）、closed（完了）の6つを状態として記録します。4段階のうち2番目の合意にあたるのが acknowledged です。届いたことと受けたことが、別の状態として並びます。

担当を変えるときも「送付 → 承諾／差し戻し」を通ります。受け手が承諾しなければ、依頼は依頼者の側に残ったままです。

制作チームが聞き返せずに忘れた場面には、need_info という返し方があります。受け手が情報不足を返すと自動で「返しパス」が作られ、ボールが依頼者に戻ります。聞き返す作業が、記憶ではなく1回の操作になります。

依頼の中身の側では、タスクに目的（Goal）と受入条件の欄があります。論文の言う「何ができたら終わりか」を、依頼文の本文に埋めずに独立した欄で持つ形です。欄が空のまま送られた依頼は、受け手が承諾を保留する材料になります。

限界も書いておきます。欄を用意しても、埋めるのは人です。受入条件を「いい感じに」と書いて送れば、承諾の段階はやはり止まります。仕組みが引き受けられるのは、止まっていることを見えるようにするところまでです。

導入前に確かめておくこと

• 直近で遅れた依頼を3件選び、依頼を出した日と、受け手が受けると返した日を記録から拾えるか
• 拾えないなら、その依頼が「受けられていない」のか「受けたうえで進んでいない」のかを、今どうやって判別しているか
• 依頼文に、何ができたら終わりかが書かれているか。書く場所が用意されているか
• 受け手が聞き返すとき、その保留がどこに残るか
• 合意の段階を通す依頼と、通さない連絡の線引きを決めているか

まとめ

依頼のライフサイクルは、提案、合意、実行、受領の4段階で進みます。遅れの相談が来たときに疑うのは実行の段階ですが、日数が消えているのは提案と合意の間であることが多いです。この区間に状態が置かれていないと、依頼者からは送信済みとしか見えません。

段階を全部記録する話ではありません。線を引くのはボールの持ち主が入れ替わる2か所で足ります。受けるまでの日数と、受けてから終わるまでの日数が分かれれば、直す場所も分かれます。

次の一手として、直近で遅れた依頼を3件、記録から「受けると返ってきた日」を拾ってみてください。拾えなければ、その段階はまだ管理の外にあります。依頼1件ごとに届いたことと受け取ったことを分けて追う方法はメンションの記事で、受け渡しに承認ポイントと差し戻し条件を置く設計は受け渡し設計の記事で書いています。

参考

本文中の番号をクリックすると、その記述の根拠にした原文にジャンプします。原文は改変せず、英語のまま載せています。

1. Raul Medina-Mora, Terry Winograd, Rodrigo Flores, Fernando Flores「The Action Workflow Approach to Workflow Management Technology」CSCW '92 Proceedings（Action Technologies, Inc.）

   Figure 1 shows the basic sequence of actions in the action workflow loop. There is always an identified customer and a performer, and the loop deals with a particular action that the performer agrees to complete to the satisfaction of the customer.

   WORKFLOW 節（本文の「依頼者と受け手がいて、受け手が依頼者の満足するところまで仕上げると約束した1つの行為を扱う」の根拠） 本文の該当箇所へ戻る
2. Raul Medina-Mora, Terry Winograd, Rodrigo Flores, Fernando Flores「The Action Workflow Approach to Workflow Management Technology」CSCW '92 Proceedings（Action Technologies, Inc.）

   The loop proceeds in four phases: 1) Proposal The customer requests (or the performer offers) completion of a particular action according to some stated conditions of satisfaction. 2) Agreement The two parties come to mutual agreement on the conditions of satisfaction, including the times by which further steps will be taken. This agreement is only partially explicit in the negotiations, resting on a shared background of assumptions and standard practices. 3) Performance The performer declares to the customer that the action is complete. 4) Satisfaction The customer declares to the performer that the completion is satisfactory.

   WORKFLOW 節の4段階の記述（本文の提案・合意・実行・受領の内容と、合意で決める「終わりの条件」「次の手を打つ期日」の根拠） 本文の該当箇所へ戻る
3. Ron Jeffries「Essential XP: Card, Conversation, Confirmation」ronjeffries.com（2001年8月30日）

   The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement.

   Card 節（本文の「カードは要求を作る情報を全部は含んでおらず、要求を指し示すための札」の根拠） 本文の該当箇所へ戻る
4. Ron Jeffries「Essential XP: Card, Conversation, Confirmation」ronjeffries.com（2001年8月30日）

   At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they've done what is needed.

   Confirmation 節（本文の「してほしいことを伝えるときに、どうやって出来たことを確かめるかを一緒に伝える」の根拠） 本文の該当箇所へ戻る