自分たちでタスク管理システムを作ろうと思った〜Getting Things Done!（仕事を成し遂げる技術）〜：自社プロダクト立ち上げ奮闘記（1）

[吉原日出彦, 橋本 正徳，株式会社ヌーラボ]

ヌーラボが開発した「課題管理ツール Backlog」は、開発プロジェクトにおけるさまざまなタスクを管理するツールである。本連載は、同社がこのツールを開発するに至った経緯から、開発段階で起きた問題とその解決手法を彼らの経験を踏まえて紹介する。ある1つの開発チームが製品を企画し、開発プロジェクトを遂行、完了させていくまでのドキュメントでもある。（編集部）

Getting Things Done!

　私たちの携わるプロジェクトは、「やらなければいけないこと」「やろうと計画していること」の塊で成り立っています。その「やらなければいけないこと」「やろうと計画していること」を「タスク」や「ジョブ」と呼び、「仕事を成し遂げる」「プロジェクトを達成する」とは、その「タスク」をすべて終わらせることになります。つまり「タスク（ジョブ）の割り出しから終わり」を管理すれば、おのずとプロジェクトを管理することになります。

　しかし、残念なことに人間の頭には、限界があります。大事なことを「うっかり」「すっかり」「それっきり」なんてことありませんでしょうか？ さらに、人間の頭はその場の雰囲気に流されやすくもあります。「やらなければいけないこと」を挙げてみても、本当にやらなければいけないことかどうか、怪しいものです。試験の勉強中に、試験とは全く関係のないことを思い出し、そちらに没頭してしまった覚えがないでしょうか？ 恥ずかしながら、私にも経験があります。普段気にもしないのに、部屋の掃除や、本棚の整理、アルバムを見つけて思いにふけったり……、現実逃避だったのかもしれません。

　「タスク管理、されどタスク管理！」「タスクを制す者、プロジェクトを制す！」なのです。そこで、迷えるプロジェクト管理のために「タスク管理」のツールを、自社ASPサービスとして立ち上げることに決めました。

プロジェクト管理、タスク管理の考え方を検討

　「タスク管理」と一言でいっても、たくさんの手法や、考え方、ツールがあります。例えば、WBS（ワークブレイクダウンストラクチャ）や、ガントチャートや、PERT図、さらにアジャイル開発手法のXP（エクストリーム・プログラミング）における「タスクカード」などです。

　プロダクト開発者間で、「タスク管理とは？」を検討した際に、プロジェクト・チーム自身でタスク管理を行えることに重点を置き、そもそもの「プロジェクト管理、タスク管理の考え方」自体を検討しました。

　さてさて、今回の記事のサブタイトルにもなっている「Getting Things Done!」というセリフ、一体なんでしょうか？ これは、David Allen氏の著書「Getting Things Done（邦題 ：仕事を成し遂げる技術）」のタイトルからいただきました。その書籍では、「仕事を効率よ く成し遂げる」ための手法が取り上げられ、lifehacks系のブログの中でも「GTD（Getting Things Doneの略）」という言葉が注目を浴びています。

　開発当時、「GTD」という言葉があったのかどうかは知りませんが、プロダクト開発者は「GTD」という言葉は知らなくても 、「『チームで進めるタスク管理の根幹となる考え方』は何か？」ということを、開発者同士で話し合った際、GTDと同じようなことが話題となっていました。

　GTDは、次の5つの工程から構成されています。

　GTDの内容は、「仕事を効率良く成し遂げる」ための考え方が主であり、手法もシンプルでツールについても限定されていません。では「チームで進めるタスク管理の考え方」を「GTD」の工程になぞらえて、説明します。

Collection［収集］

　タスクがなければ、何も始まりません。「やらなければいけないこと」「やろうと計画していること」といっても、非常に抽象的です。タスクとは、一体なんでしょうか？ 何をタスクにしたらいいのでしょうか？ 「ソースレビュー」もタスクならば、「プレゼンテーション」もタスク、「障害対応」も、「環境構築」もタスクです。いやいや「会議」も「勉強会」も「懇親会」だって立派なタスクです。頭に引っかかるささいなこと、すべてがタスクなのです。

　ただ、そんなささいなことをチャートやダイヤグラムに載せるにはちゅうちょしてしまうものです。管理できる枠に収まらないとも考えてしまうでしょう。実は、そんなささいなことが、大きな問題に発展していったり、情報の洩れにつながることが多々あるからです。何よりも頭の中のもやもやをいつまでも抱えていることは、好ましいとは思いません。

　私は、タスクの登録は、容易で開かれていなければいけないと考えます。そして、できればタスクが登録されたことをチームのみんなに通知でき、共有できればよいでしょう。個人で頭に思い付いたことも、話し合いの中で出てきたことも、どんなことでもいいのです。

　まずはタスクを集めることから始めます。

Processing［処理］

　GTDでは、集められたタスクを「いつかやること・多分やること」「資料」「プロジェクト」「連絡待ち」「次の物理的なアクション」の5つのリストと「ゴミ箱に」に決まった処理で振り分けを行い、タスクのブレイクダウンや実行するタスクの見極めを行います。

　チームで行うタスク管理には、振り分けとは別に、優先度や、種別（「問題」「要望」）、期日のように全タスクが共通に持つ属性情報を設けて、タスクに規則性をもたらす方がいいようです。

　似たタスクをグループ化する、いつでも取り出し可能な入れ物で振り分けを行う感覚が分かりやすいです。例えば、床に散らばった、たくさんの本を取りあえず本棚に押し込むと考えてください。文庫や、雑誌、ハードカバーなど、ある程度の高さに合わせた本棚に収納して、それから整理を行うと案外手間が掛かりません。すべてをきっちりと本棚に納める必要はありません、入り切れないものはそのまま床に転がしておきましょう。寝転んだとき、手に取った本の中から新しい発見があるものです。

Organizing［整理］

　振り分けた、タスクは膨大な数になるかもしれませんし、頻繁に更新する必要があるかもしれません。このようなことは、システムの得意分野ですが、先に述べたようにGTDは、ツールの限定を行っていません。使い慣れたツールが使用できれば好ましいのですが、チームで管理する以上は、共通で使えるものでなければいけないでしょう。あらゆるニーズに答えるツールを探すのは難しいものです。

　最低限度、Processing［処理］で行った、振り分けが条件や並べ替えとしてシステマチックに整理が行えること。そして、タスクが持つ文字列情報を検索できる属人的な整理が行えればなおよいと思います。

　また、チームでタスクの状況に対しての共通意識を持つことが重要です。いま現在このタスクが「未着手」か「開始」しているか「終了」しているといったように状態の判断そして、変更を管理できることが必要です。状態の把握は、GTDの中でも「終わっていない仕事」を「Open Loop（未着手のタスク）」として悩みの原因に挙げ、「Open Loop」から「Close Loop（着手済みのタスク）」に変えていくことが、達成意欲の向上へとつながると考えています。

Reviewing［レビュー］

　整理できたタスクを実行へと移します。その前にいまから行うタスクについて、定期的に見直しを行うことが重要であると述べています。

　物事は日々変わっていくものであり、いつまでも古い情報を放置していてはいけないとの考えでしょう。振り分けの見直しでも、期日を設けたなら、本当にその日までに完了できるか、タスクそのものの実行の可否で構いません。

　また、通常プロジェクトは、マイルストーンというタスク終了の指標を設けて進めていきます。マイルストーンには期日が定められ、マイルストーンに所属するタスクはその期日までにすべて完了していなければいけません。レビューのタイミングで、マイルストーンを作成してタスクを整理することが意識の向上と、目の前に目標が見えることで安心感につながるようです。

　このような見直し作業は、気が付いたときに自由に行ってもよいことですが、できるならチームで毎週決まった時間に、チーム全員で集まって行うことが好ましいでしょう。

Doing［実行］

　当たり前のことですが、タスクの実行をタスク管理に期待してはいけません。タスクを片付けるのは、担当者です。そこで、困難な壁にぶつかったとき、1人で悩んでいてはいけません。とにもかくにも、聞いてみることです。そのためのチームなのですから。そして、できることならタスクに対してassign（振り分けられる）ではなく、自分から進んでsign up（取り組む）しましょう。

　以上の、工程を繰り返しながらプロジェクトを進めていきます。何度も繰り返すようですが、「タスクの割り出しから終わりまでを管理できる」、それだけで十分なのです。

　今回は、チームで行うタスク管理についてGTDと絡めて（便乗かもしれません）ご説明いたしました。このタスク管理に対する取り組みは実際に弊社で行われているもので、GTDでは言及していないツールを自社ASPプロダクト「Backlog」を使って行っています。「Backlog」の開発を進める中で、プロジェクト（タスク）管理に対するプロセスも確立していく、非常に面白い結果を生み出しています。

　GTDについてのより詳しい情報は、以下を参考にご覧ください。

• David Allen Getting Things Done（英語）
• Getting Things Done (a.k.a. GTD) part （1）
• 仕事を成し遂げる技術―ストレスなく生産性を発揮する方法（書籍）
• はじめてのGTD

　次回は、「Backog」の開発で実際に行った設計手法「ペルソナ手法」を解説します。ユーザーを仮定し、モノやシステムの使い方を想定しながら要件を整理していく設計手法です。