タスクと承認を伴う申請

「新しい同僚が来ます」は、1件のチケットではありません。ノートパソコン1台、アカウント2つ、電話の内線、場合によっては社外からの接続です。それぞれ別のチームが担当しますが、進み具合をまとめて見られる案件も1つ欲しいところです。

そのための仕組みが申請です。申請は、提出された時点でタスクを作るチケットで、タスクはそれぞれ、担当するチームのチケットになります。

申請は、別に管理するものではありません。申請はチケットテンプレートの上に成り立ちます。「Settings → Request workflows」にすべてのチケットテンプレートがあり、そのどれかにタスクを付けます。

タスクごとに、いくつかの欄を入力します。「Task」は依頼者が読む名前、「Handled by」は受け取るチーム、「Ticket title」と「What the team has to do」は、そこからできるチケットの中身です。

複数のタスクが、同じチームを指しても構いません。そのチームには、箇条書きの入った1件ではなく、複数のチケットが届きます。

チームの決まっていないタスクは、そもそも提示されません。欄にも、そう書かれています。「Not assigned yet — this task is not offered」。おかげで、まだ仕上がっていない計画も保存できます。

タスクの上に、計画全体をまとめた1文が表示されます。初期設定で何が作られるか、依頼者がどこまで変えられるか、誰が承認するかが書かれます。設定を変えると、この文も書き変わります。

「Ticket title」の前には、固定の文字列「Parent ticket title -」が付きます。新しいチケットのタイトルは申請のタイトルで始まり、そのあとに入力したタイトルが続きます。たとえば「New colleague in accounting - Set up notebook and docking station」のようになります。これで専門チームは、タスクがどの申請に属するかが分かります。この欄を空のままにすると、代わりにタスクの名前が続きます。

「Main category」と「Subcategory」は、新しいチケットのカテゴリをあらかじめ埋めます。選べるのは「Handled by」のチームのカテゴリだけです。チケットはそのチームで作られるためです。チームを変えると、両方の欄が空になります。両方を設定するか、どちらも設定しないかのどちらかです。空のままなら、チケットはカテゴリなしで作られます。

申請の名前は、タスクの上に表示されます。名前を変えるには、その横の鉛筆を使います。この名前はチケットテンプレートのものなので、「Settings → Templates」と新規チケットのフォームでも変わります。

新しいチケットのフォームでテンプレートを選ぶと、「What is needed?」の枠が現れ、タスクごとにチェックの行が並びます。

種類は3つあり、タスクごとに設定します。「Selectable, off by default」は何も入っていない状態から始まります。「Selectable, on by default」はチェックが入った状態から始まり、外すこともできます。「Always — cannot be deselected」は必ず実行されます。

必ず実行されるタスクも表示され、「(always included)」の印が付きます。依頼者には、どのみち起きることが見えているべきだからです。

枠の下に、その結果どうなるかが書かれています。「Each selected item becomes its own ticket for the team that handles it.」

テンプレートが顧客に公開されていれば、顧客も申請を出せます。そのためのスイッチは、テンプレートの側にあります。

その場合、顧客に見えるのは自分の申請だけです。専門チームのチケットは、その申請から生まれたものであっても、顧客には見えません。そうしたチケットには、認証情報や内部のメモが入るためです。そうしたチケットの内部のメモは、申請の履歴にも表示されません。専門チームが自分のチケットを閉じると、その添付ファイルは「Internal」のバッジ付きで申請にコピーされ、顧客は見ることもダウンロードすることもできません。

申請がメールで届くと、ふつうのチケットになります。その場合は、あとからワークフローを開始します。そのためのボタンが、チケットの上部にある「Start workflow」です。

ダイアログの「Template」で、合うテンプレートを選びます。その下に、新しいチケットのフォームと同じ「What is needed?」の枠が現れます。申請に書かれているものにチェックを入れます。

「Title」で、チケットのタイトルを調整します。タスクのタイトルは、このタイトルで始まります。その下に、テンプレートの追加の項目が並びます。そこに、申請に書かれた内容を入力します。必須の項目には星が付いています。

「Start」を押すと、フォームから出された申請と同じようにタスクが作られます。テンプレートに承認が必要な場合、承認されるまで、チケットとそのタスクは施錠されたままです。

1件のチケットで開始できるワークフローは1つだけです。開始すると、ボタンは消えます。閉じたチケットや、それ自体がタスクであるチケットにも、このボタンはありません。開始できるのは、そのチケットを処理してよい人です。

申請そのものでは、タスクが「Workflow tasks」に並び、その横に件数が出ます。たとえば「1 of 4 done」のように表示されます。

各行に、タスクの名前、そのチケットの番号、チーム、担当者が並びます。名前は、そのチケットへのリンクになっています。

「完了」は、別のチェックではなくチケットのステータスから決まります。チケット一覧で終了と数えられるものが、ここでも完了になります。同じものを2通りに数えれば、いずれずれてしまいます。

この部分は申請にだけ表示されます。ふつうのチケットには出ません。

専門チームが自分のチケットを閉じると、その「Closing comment」が申請に届きます。申請では内部メモとして表示され、その1行目にタスクの番号と名前が書かれます。顧客には、このメモは見えません。

認証情報と、申請を担当するエージェントが伝えるべきことはすべて、終了時のコメントに書きます。専門チームのそれ以外のコメントは、すべてそのチームのチケットに残ります。チームがコメントなしで閉じた場合、メモは作られません。

承認は、個々のタスクではなく申請全体を対象にします。8件の申請でも、上長に届くメールは8通ではなく1通です。

設定は同じ計画の「Approvals」で行い、その上の文が原則を述べます。「One approval covers the whole request. Add a second stage only when single tasks need their own release.」段階ごとに5つの欄があります。「Name」は段階の名前、「Covers」が対象、「Decided by」が承認者の決まり方、「Approver」がその人、「Remind after (hours)」が催促の設定です。

承認する人に、チケットシステムのアカウントは要りません。メールアドレスを入力すれば、リンクから判断できます。四半期に2回承認する上長のために、エージェントの枠を使う必要はありません。

メールに入るリンクは、ちょうど一つです。承認や却下のボタンをメールの中に置いていないのは、意図した設計です。すべてのリンクを開くウイルス対策ソフトが、代わりに承認してしまうからです。

そのページの見出しは段階の名前です。申請の番号とタイトル、依頼者、そして「This decision covers」の下に、この判断の対象となるタスクが表示されます。下にはコメントの欄と2つのボタンがあります。

リンクは永久には使えません。ページに期限が書かれています。「Please decide by …」。有効期間は14日です。それを過ぎると、ページにはリンクが無効か期限切れであることだけが表示され、管理者が「Reassign」で依頼を送り直します。

判断は取り消せません。決めたあと、ページにその旨が表示されます。「A decision cannot be changed.」

タスクの中には、専用の承認が必要なものがあります。社外からの接続は、ノートパソコンとは違います。

そのために2段目を追加し、タスクの「Extra approval」でそれを選びます。「None — the request approval is enough」のままなら、申請の承認だけで足ります。2つの段階は順番にではなく、同時に問われます。段階が問われるのは、選ばれたタスクのどれかがその段階に関わる場合だけです。申請全体の段階は、常に問われます。

タスクが動き出すのは、そのタスクに関わるすべての段階が同意したときです。独自の段階を持たないタスクは、申請全体の段階がまだ待っている場合を除いて、すぐに始まります。待っている場合は、申請が承認された時点で始まります。

それまで、そのタスクは施錠されています。チケットは「Waiting for approval」の状態で、担当者はいません。ステータスのボタンの代わりに、カードにはこう表示されます。「This ticket is waiting for approval and cannot be worked on yet.」それまでは、どの経路でも担当者は付きません。

この施錠は、チケット一覧での一括操作にも効きます。そこでこの種のチケットを選ぶと、理由が表示されます。「This ticket is waiting for approval and cannot be worked on yet.」

チケット自体は、すぐに作られます。専門チームはこれから何が来るかを把握でき、誰も申請を見張っている必要がありません。

段階ごとに催促を設定できます。単位は時間です。

返事が来なければ、その時間のあとに同じメールがもう一度送られます。リンクは1通目と同じです。1通目を残している人は、そのまま使えます。

催促を設定しなければ、申請はただ待ちます。もう一度尋ねることはありません。

存在しないのは、期限切れによる承認です。欄の下に、そのまま書かれています。「A request is never approved automatically. If nobody reacts, it keeps waiting.」自分から同意してしまう期限は、承認ではなく形式にすぎません。

却下には理由が必要です。文がなければ、ページは却下を受け付けません。

欄に、その文がどこへ行くかが書かれています。「Comment (required when you reject — the requester will see it)」。内部向けのメモを書く場所ではありません。

依頼者には理由の入ったメールが届き、なぜ進まないのかを尋ねる必要がなくなります。

承認に理由は要りません。想定される結果だからです。

2段目だけが却下した場合、その影響はその段階のタスクに限られます。申請の残りは進みます。

却下されたタスクはステータス「Rejected」になり、終わったものとして数えられます。決して来ないものを待って、申請がいつまでも止まることはありません。

申請が却下されると、ほかの承認者にはもうメールが届きません。そのリンクには「This request has already been rejected. Your decision is no longer needed.」と表示されます。チケットの一覧では、その段階に「No longer needed: the request was rejected.」と表示されます。

申請の「Approvals」に、段階ごとに1行ずつ、承認する人と状態が並びます。未処理の申請では、どれだけ待っているかも表示されます。

判断のあとは、いつ、どのコメントとともに決まったかが行に出ます。これが監査証跡で、案件とともに残ります。

承認する人が休暇のときは、管理者が申請を別のアドレスに回します。ボタンの名前は「Reassign」で、申請が未処理の間だけ表示されます。

これができるのは管理者だけです。エージェントが回せるなら、自分に回してから自分で決められてしまいます。

回すと新しいリンクができ、古いリンクはその場で無効になります。誰かが転送していた場合も同じです。

回したこと自体も、同じ一覧に出ます。誰が、いつ、誰から誰へ回したかが分かります。

他人の名前で判断することは、誰にもできません。経路はリンクだけで、誰がそれを受け取ったかは案件に記録されます。