Mozillaサポート業務を主に担当している結城です。

タスク管理の悩み

明日までにこれを作らなくてはならない、何月何日までにこれを直さなくてはならない、期日は決まっていないがなるべく早くそれを完成させなくてはならない……こういった「タスク」をどのように管理するかは永遠の課題です。

例えば、プロジェクト管理ツールとして広く使われているRedmineには「チケット」（英語版では「issue」）を単位としてタスクを管理する機能が含まれています。 GmailのTODO機能も一種のタスク管理ですし、Remember The Milkのように専門のサービスもあります。

しかし、残念なことに筆者個人はそれらを使いこなせていません。 「このように使うツールだ」という説明を見聞きして「なるほど」と思っても、その使い方をどうしても憶えられなかったり、だんだん億劫になりいいかげんな使い方をして結局役に立たなくなってしまったりと、これまでタスク管理では失敗続きでした。

とはいえそれでは仕事が回りませんので、対策として、タスク管理が苦にならないタイプの人とチームを組む事により、会社としては安定したサービスを提供するという事を行っていました。 個人個人は不得意分野を抱えていながらも、お互いの得意分野を持ち寄ってそれをカバーし合うことによって、全体として最大の効果を上げられるというのは、個人ではできないチームプレイならではの利点だと言えます。

ただ、タスクを管理してくれる人がいなければ全く仕事ができないというのは、業務のアサインやチーム編成に制限が生じるということで、やはり望ましくない状況です。 そこで、筆者だけでも無理なくこなせるタスク管理方法を改めて模索していて、現在ではRedmineのチケット1つを軸にすることにより、筆者単独でも業務上のタスクをある程度までは管理できる状態になってきました。

この記事では、筆者が現在行っている「Redmineをほぼ既定の設定のままで運用している状態で、チケット機能を使って日々発生するタスクをこなしていく」というタスク管理の流れをご紹介します。

背景・前提

クリアコードでは開発業務以外に、フリーソフトウェアのサポート業務も行っています。 サポート業務では、例えば「Thundebrirdを使用していて削除できないメールができてしまった」や「Firefoxを使用していてTLSのページでエラーが表示されてしまった」といったトラブルについて調査・回答をするという事を行っています。 具体的なサービス内容については過去に詳しい紹介を掲載済みですので、そちらも併せてご覧下さい。

このサービスでは、お問い合わせを頂くタイミングが重なる場合や、お客様環境でのログ収集を依頼してその結果を待つ必要がある場合などがあり、個々のお問い合わせにその都度専任の人員を張り付けるという訳にはいかない場合が多いです。 そのため、「お問い合わせに対して回答をすること」をタスクとして一旦キューに溜め込んでおき、「受け付けから3営業日以内に回答する」という基準の範囲で順に処理しています。

実際のタスク管理

タスク登録の流れ

何を置いても、まずはタスクがタスクとして登録される必要があります。

弊社サポート業務では、お客様からのお問い合わせはサポート業務担当者が参加しているメーリングリストへの投稿という形で受信されます。 例えば以下のような内容です。

クリアコード 担当者様

XXXのxxxです。
Firefoxを使用していて○○機能が動作しませんでした。
回避方法の調査をお願いします。

これを担当者が確認した後、まずRedmineの該当プロジェクト（クリアコード社内のRedmineでは、お客様ごと・ご契約ごとにRedmineのプロジェクトを作成して管理しています）のチケット一覧を調べます。

• 受信メールの内容が既存のチケットについての物であれば、受信したメールの内容を当該チケットのコメントとして追加し、ステータスを「フィードバック」に変更します。

• 既存のチケットに関係しない新規のお問い合わせであれば、新しいチケットを作成し、受信したメールの内容を情報として記載します（ステータスは「新規」になります）。

お問い合わせがいつ来るかはお客様次第なので、キューイングの作業は常に他の作業と並行して行う必要があります。

タスク処理の流れ

このようにしてタスク化されたお問い合わせは、以下のような流れで処理していきます。

毎朝のタスク把握

クリアコードでは毎日朝会を実施しており、その際、「前日行った業務内容」と「当日行う予定の業務内容」を簡単に報告します。

その材料として、Redmineの「朝会」プロジェクトにはその日ごとの朝会に対応するチケットが用意されています。 朝会に参加するメンバーは各自で、朝会で喋る内容をこのチケットにコメントとしてメモしています。

後述しますが、筆者は当日分のチケットのコメントに、「当日の予定」として前日のうちに未処理のチケットの番号を以下のようなリスト形式で記載しています。

 * #1234 Aさま 問い合わせ回答
 * #1235 Bさま 問い合わせ回答
 * #1236 Cさま 問い合わせ回答

Redmineでは #チケット番号 という記法で書いたテキストが自動的に当該チケットへのリンクになります。 そのため、この朝会用チケットを参照して個々のチケットを辿れば、回答するべきお問い合わせの内容やそれまでの議論をすべて読む事ができます。 筆者は、このチケットを一日中タブで開いたままの状態にしていて、その日の仕事の起点として何かある度に参照するようにしています。

なおこの時、前日の終業以後に新たに頂いたお問い合わせがある場合は、それもチケットに記録して「当日の予定」のリストに加えておきます。

タスクの処理

その日の朝の段階で把握したタスクは、上から順に処理していきます。 一番上のチケットを開き、そこに書かれた内容に基づいて調査を実施して、結果が出たら、その内容を適宜当該チケットに記録しておきます。

その後、調査結果を元に最終回答や途中経過の報告をまとめて、お客様に回答します。 例えば以下のような内容です。

XXX xxx様。

クリアコード ***です。

お問い合わせを頂きました件について調査した結果、△△の可能性がある事が分かりました。
お手数をおかけしますが、××の手順でログを収集してご連絡いただけませんでしょうか？

回答をメールでお客様に送信したら、チケットのステータスを「解決」に変更します。 この場合、お客様からの連絡を待つ必要があるので、チケットは再びキューに戻った事になります。 （なので、ここでの「解決」とは「問題が解決した」ではなく「未処理のタスクを処理した」という意味になります。）

タスクの処理中に発生した新しいタスクの登録

調査を行っている間に、既に回答した別のお問い合わせについての追加のお問い合わせや、依頼していた情報の提供の連絡を頂く事もあります。

その場合は、先に述べた通りのルールで新規チケットを作成したり、既存チケットへコメントを追加したりして、未処理タスクのキューに入れます。 具体的には、朝に参照したその日の朝会用チケットの「当日の予定」の末尾に項目を追加します。

 * #1234 Aさま 問い合わせ回答
 * #1235 Bさま 問い合わせ回答
 * #1236 Cさま 問い合わせ回答
 * #1237 Dさま 問い合わせ回答

業務時間中に受け付けたお問い合わせについては、その場ですぐに回答しないで、必ずこのようにキューにしてから処理するという運用を取っています。 そうしないと、レスポンスが速いお客様からすぐに回答を得られた場合や、問い合わせの件数が多いお客様がいた場合に、他の事が全くできなくなってしまいます。

翌日のタスクの準備

一日の終わりには、次の日の朝会用チケットの準備をします。

この時にはまず、当日の朝会用チケットにコメントとして書いていた内容を丸ごとコピーして、翌日の朝会用チケットのコメント追加用のフォームにそのまま貼り付けます。 その後、「前日の業務」の内容を消して、「当日の予定」欄にあったタスクのうち処理済みの物を「前日の業務」欄に移動します。 そして、当日処理しきれなかった分のタスクはそのまま「当日の予定」欄に置いておきます。

これにより、翌日の朝には「その日処理するべきタスク」の一覧ができているという事になります。

前日の業務

 * #1234 Aさま 問い合わせ回答
 * #1235 Bさま 問い合わせ回答
 * #1236 Cさま 問い合わせ回答

当日の予定

 * #1237 Dさま 問い合わせ回答

また、前述したとおり、翌日朝には終業後に受信したメールを確認し、チケットに反映されていないお問い合わせを既存チケットのコメントや新規チケットとして記録して、「当日の予定」に反映します。 筆者はこのようにして、毎日コンスタントにタスクを消化していっています。

まとめ

以上、五月雨式にタスクが発生する業務について、Redmineの標準的なチケット管理機能でタスクを管理する運用の例をご紹介しました。

このタスク管理の方法には「優先順位」という考え方が入っていませんので、処理能力を超えて多数のタスクが発生する状況では破綻してしまいます。 また、実際には個別のお問い合わせに対するサポート業務と並行して、「カスタマイズして導入済みのFirefox 38esrをFirefox 45esrに更新するために、それぞれのカスタマイズの反映方法をFirefox 45ベースで確認する」のような大きなまとまりのタスクもあります。 それらをどう管理していくかという点で、このタスク管理の流れにはまだ改善の余地があり、現在もそのような場面では、タスク管理を得意とする人の手助けを得て運用しています。

とはいえ、1人ではタスク管理ができないという状態からスタートして、ここまでは辿り着くことができたということで、筆者にとっては大きな改善でした。

ソフトランディングということ

筆者の場合、数ヶ月にわたって事前に朝会用チケットの運用を既に行っていた事から、「作業は朝会用チケットを起点にして行う」「作業内容は個別のチケットで把握する」ということについては既にできている状態でした。 そのため、「新しいお問い合わせを受け付けた際に、その情報をチケットに即座に記載する」ということと「朝会用チケットに記載する内容に必ず、タスクに対応するチケットの番号を記載してリンクするようにする」というインプットの2点に新たに気をつけるようにするだけで、そのままタスク管理の流れを確立することができました。

まず、他の人が用意してくれたタスクリストをそのまま使う形ででも、とにかく「自分のその日のタスクをチケットの一覧として把握して」「作業の節目にはタスクに対応するチケットにまめに情報を反映する」のを習慣づけること。

そして、それらを無理なく行えるようになった上で、「流入してくる情報から新たにタスクを作成し、タスクリストに項目を追加する」という、今まで自分では行っていなかった事を新たに行うようにすること。

このような2段階を経たソフトランディングによって、筆者は単独でもタスクの管理を行えるようになってきたと思います。 全く下地のない所から完全なタスク管理を始めようとしたら、あるいは、それまでの習慣とは全く別の「画期的なタスク管理手法」に飛びついて無理をしていたら、うまくいっていなかったのではないでしょうか。

状況が許すのであれば、このように時間をかけて少しずつ成功体験を重ねて要素要素の技能を身に付けていくことが、結果的には不得意を克服する近道となるのではないか……というのが、この記事を通じて筆者が最も伝えたかった事です。 今まさに苦手を抱えている人や、苦手を抱えているメンバーが近くにいるという人は、参考にしていただければ幸いです。