タスク管理とは
タスク管理とは、作業の実行状況を把握することです。プロジェクトにおける作業は、通常WBS(Work Breakdown Structure)により階層型に分解します。こうして分解された階層構造の各作業のことをタスク(=Work）と呼び、タスクの実行状況を把握して共有することをタスク管理と言います。
タスク管理のやり方としては、ガントチャートのようにチャート（横棒）で管理する方式とTODOのようにOn/Offで管理する方式があります。通常、作業ボリュームの大きなタスクはチャート型で管理します。チャートの場合は開始予定日だけでなく終了予定日もビジュアルに可視化でき、30%とか70%など中間の進捗も細かく管理できるメリットがあるからです。一方、作業ボリュームが小さなタスクならやったかやらないかだけ管理するTODOの方が楽です。
すべてのタスクをチャート形式で管理するケースも多いのですが、チャートとTODOを組み合わせるケースもあります。WBSは大きなタスクをブレークダウンし、下の階層に行くほどタスクが小さくなります。そのため上位タスクはチャート形式とし、末端タスクはTODO形式で管理するという方法です。さらにアジャイル開発のようにすべてのタスクを小さな作業単位に分解した場合、プロジェクトの規模が大きくなければ全てTODO形式で管理することも少なくありません。その場合、やったかやらないかだけだと粗いので、タスクボードを使ってTODO（未実施）、Doing（実施中）、Done（完了）の3モードで管理します（これでも粗いと感じるチームは、Check（確認中）やPending（ペンディング）などさらにモードを増やしたりしています）。
なお、タスク管理は、本来はチャート形式とToDo(On/Off)形式の両方を対象に含みます。しかし、通常、タスク管理と言った場合にTODO形式のみを意味することが多いです。
チケット管理とチケット駆動開発
チケット管理とは、タスクをチケットとして作業担当者に発行し、タスクボードなどを用いて作業の進捗状況を管理することです。「今日、Aさんはこの作業、Bさんはこの作業ね」と工事現場で日雇い労働者に作業を采配するようにチケット（作業指示）を発行するイメージでしょうか。最初にチケットを発行するところから作業が始まるので、この開発手法はチケット駆動開発とも呼ばれています。
チケット駆動開発は、主にアジャイル開発で多用されます。一般にウォーターフォール開発の場合は、ガントチャート作成時にタスクと担当者を決めてしっかり計画を立てます。一方、アジャイル開発の場合は、プロジェクトの進捗に応じて新たなタスクが発生したりするので、あらかじめタスクと担当者を決めるやり方はそぐいません。そのためプロジェクトを進めながら、デイリースクラムミーティングなどでどのタスクを誰にやってもらうかを柔軟に決めてゆくのです。
ガントチャートとタスク管理
「ガントチャートを制すものはプロジェクトを制す！」はちょっと言い過ぎかも知れませんが、ガントチャートはプロジェクト管理上必須のアイテムなのは異論がないと思います。
旅行における行程表や料理におけるレシピも、単なるTODOメモではなくガントチャートにまとめると、旅の良い思い出を作ったり、よりおいしい料理が作ったりすることができます。ガントチャートは、時間の長さをバーで表すことができるので、誰が見てもプロジェクト全体像をわかりやすく把握できるのです。
一方、日々の業務の中ではもっと細かいTODOレベルでの管理が必要になってきます。例えば、「勤怠入力画面」をコーディングするのに、「アカウント情報の取得ロジック」、「超過時間を月稼働日数から算出するロジック」といった細かなロジックを作成するタスクは、いちいちガントチャートのバーで表すほどでもないので、TODOレベルで管理したいところです。
全体を一目で見られるガントチャートと、現場レベルの作業内容（TODO）をどのように使い分ければ効率的でしょうか。
WBSの最下層をタスク管理にする
サブ明細の便利さを理解するために、身近な例で説明しましょう。１年がかりで手掛けたシステムが無事リリースを迎えることができて、１週間程お休みをもらえることになりました。忙しいさなかに思った「終わったら最新技術を勉強しよう！」という決意を実行しようといったんは考えたのです。でも、「いや、その前にイタリア旅行だ！」とふと思ってしまい、結局夢だった「イタリア旅行」に行くことにしました。この心境、きっと数々のプロジェクトを乗り越えてきた方は共感していただけると思いますが…。
思わずほおが緩むのを抑えながらも、そこはPMのプロ（？）ですので、ガントチャートを使ってイタリア旅行の行程表を画面１のように作成しました。１日目に東京からミラノへの移動、２日目にミラノ探索といった日程に従った計画をガントチャート上で立てましたが、実際現地でやるべきことをどう表すかで迷ってしまいます。例えば、「成田空港でWiFiをレンタルする」「真実の口に手を入れる」「スペイン広場でアイスを食べる」といった“やるべきこと”（＝TODO）は、どうタスク化すればいいでしょうか。
これらをWBSの最下層としてチャートで表すのも1つの方法です。しかし、期間を表すほどのタスクではありませんし、チャートが増えすぎても管理が煩雑になります。とにかく夢のイタリアですからやりたいことがいっぱいあるので、WBS上のタスクではなく、そこに関連付けできるTODOで管理することにします。OBPMでは、WBSの最下層のタスク（ワークパッケージと呼びます）の下にサブ明細というTODOを設定できるようになっています。
画面1のWBS欄にある「ローマ探索」というタスクのサブ明細欄を見ると「0/5」と表示されています。これはローマ検索には5個のTODOがあり、全て未完了であることを示しています。「0/5」のリンクをクリックするとこの5個のサブ明細が表示されます。「ローマ探索」にまつわる5つのTODOが、やった、やらないで管理されるのです。個々のサブ明細を選択すると画面右側にその詳細が表示され、何をやるべきか明確に記されます。
実際の旅行では、行程表とは別にやりたいことを紙に書きだしたり、旅行ガイド片手に付箋をつけたりして目的を果たすと思います。プロジェクト遂行においてもガントチャートとTODOを関連付けて、楽しい旅行を成し遂げる計画を立てると、思い残すことのない想いで深い旅行になるのです。
画面1：イタリア旅行の日程表をさらにサブ明細化して管理
ウォーターフォールにおけるタスク管理
え、旅行は行き当たりばったりの方が楽しいアジャイルだからTODOが向いているのでは？まあ、確かにそういうところもありますね。では、通常の開発プロジェクト「A社向け勤怠システム構築プロジェクト」の例で考えてみます。
WBS(Work breakdown Structure)でタスクを分解する際に難しいのは、タスクをどこまで分解するか、つまりワークパッケージを何にするかです。これをWBSの粒度とも言います。 画面2の例で考えてみましょう。WBSでタスクを「製造」→「コーディング」→「勤怠入力」とブレークダウンしました。これ以上分解すると煩雑になるので、ワークパッケージは「勤怠入力」で管理することにします。
プロジェクト全体の管理としてはここで分解を止めることが多いのですが、現場の作業指示＆進捗確認としてはもう少し細かく管理したいところです。そこで作業を始める前に「勤怠入力」コーディングの具体的な内容を洗い出します。「アカウント情報の取得：4時間」「日別入力モードの表示：12時間」「月別入力モードの表示：8時間」等のように実施する作業内容が洗い出されたら、それを明細タスク（TODO）として登録します。
ウォーターフォール開発の場合は、設計書にもとづいて実装作業を行います。この場合、設計書の１ページ目から順番にコーディングするわけではありません。はじめの１日で画面項目説明書に記述されている内容を実装する、2日目にイベント制御の更新前チェック部分を実装する、といった段取りを行ってからコーディングするはずです。その段取りを頭の中で覚えていればいいのですが、私に限らず人間忘れるようにできているようです。そのため、こうした段取りをきちんとTODO登録するのです。TODO登録するとやるべきことが明確になるほか、進捗管理もできるので「あ、間に合わない」と焦ることが少なくなります。
営業担当がスケジュール表にアポイントの日程やTODOを登録するように、エンジニアもガントチャートというスケジュール表にやるべきことを登録して管理すれば、効率よく作業がでます。決めたTODOの順に作業を実施し、ガントチャート上のタスクスケジュール内で全てのTODOタスクが完了するように作業します。
作業を始める際にTODOを書き出すことは自己レビューにも似ています。これから実施する作業に漏れがないか、早期解決しておくべきことは何かを明確にすることができます。また、ガントチャートにTODOを登録すればチーム共有できますので、チーム内での調整やアドバイス、進捗状況の共有化をしやすくなるメリットもあります。
画面2：「勤怠入力」をTODO（サブ明細）化して管理
TODO管理とチケット管理
先程説明したサブ明細の一つひとつは、担当者に割り当てられた作業そのものです。これを作業一覧としてリスト化し、それぞれの担当者を明確にすることも可能です。この担当者の作業をチケットという単位に割り当てると、作業一覧はチケット一覧そのものになります。
一般のチケット管理は、現場監督（PL）が作業内容を書き出して、それをチケットとして発行して「はい、これは山田君」「これは佐藤さん、お願いします」と担当者に配り、それぞれの期限を定めます。この柔軟な方式はアジャイルには向いていますが、上位タスクで担当者が決まっているウォーターフォールにはそぐいません。ガントチャートのサブ明細にTODOを登録すると、それが自動的に別画面でチケット一覧として管理される仕組みなら、自然な流れでチケットが発行されて作業管理されるメリットがあります。またチケット一覧を見れば誰がどれくらいの作業ボリュームをいつまでに実施するかが一目瞭然になるので、作業負荷を皆で共有することができ、チームの作業効率が高まります。
チケットは“担当者がやらなければならない作業”です。なので、ガントチャートの作業タスクだけとは限りません。質問の回答や障害の修正など、あらゆる作業がチケットとなります。一般のチケット管理は、これらをひっくるめた汎用的なチケットを発行して、その進捗を管理するのですが、OBPMは逆の流れでチケット管理できるようにしています。
OBPMは統合型のプロジェクト管理システムなので、さまざまな管理項目(PMBOKの10の知識エリア)で発生する作業をすべてチケットとして統括管理します。チケットは「サブ明細」のほかに「障害」「質問」「課題」「リスク」「レビュー」などで発行されます。発行するというよりも、それぞれの管理において担当者の作業が決まると自動的にチケットになるという仕組みです。例えば、障害管理において障害判定者がバグと判定して、修正者に酒井君を指名すると、その修正指示内容は酒井君のチケットとなります。
同様に、質問回答や課題の対応担当など、それぞれの管理において対応者を決めるとそれがチケットとなってチケット一覧で管理できます。現場監督はこれを使って作業の空きや偏りがないよう調整することができます。また担当者も割り当てられたチケットから優先順位を判断して作業を行うことが可能です。
画面3：チケット（TODO）一覧から各チケットに適した管理を実施
仕事ができる人はタスク管理も上手です。「タスク管理を制すものは仕事を制す！」と心得て嫌な作業もタスク化してさっさと終わらせましょう。と言いつつ、私はさっさと終わらせられないタイプなので、毎日チケット一覧とにらめっこしながらぎりぎりの進捗を綱渡りしています。
OBPMとタスク管理
OBPMは、ウォーターフォール開発とアジャイル開発の両方に適合したプロジェクト管理システムで、当社でも両方の開発方式に適用しています。ウォーターフォールはもちろんですが、規模が比較的大きなアジャイル開発になるとイテレーションなどの作業タスクをガントチャートでチャート管理する必要があります。その場合、ガントチャートとチケット管理が別々だと、総合的なタスク管理がやりにくくなります。OBPMは、チャート管理とTODO管理を連携することができますので、それぞれの良さを活かしたプロジェクト管理が行えます。
（株式会社システムインテグレータ 羽佐田奈津美）
