人気ブログランキング | 話題のタグを見る

ActivityとTaskはどう違うか 〜 ガントチャートと課題管理表から考える

最近、ある読者の方から久しぶりにメールをいただいた。工場のマネジメント職についたのだが、社内プロジェクトを進めるにあたって悩みがあり、アドバイスいただきたいとの内容だった。

その方が率いておられているのは、自発型かつ小型のプロジェクトらしい。だったら、大げさなモダンPM手法を持ち出さずとも、各種リーダーシップ論でカバーできる範囲だ（と、わたしは拙著「世界を動かすプロジェクトマネジメントの教科書」に書いた）。だが、リーダーシップで引っ張る以外、何かないのだろうか？　——そういうご質問だった。

この方が本当はどんな点で悩まれているのかは、現場に行って仕事の実際を見てみないと、よくわからない。しかし昨今の時勢では、それもなかなか叶わないことなので、わたしはこんなふうに、ご返事した。

「自発型で小規模なプロジェクトを引っ張るのは、実は見かけほど簡単ではありません。受注型ならば結局、顧客との契約で『やらなきゃならない』し、お金をもらってビジネスをしている以上、誰かに頭を下げるのだって我慢できます。

しかし社内のボランタリーな仕事の場合、『つまんないから自分は手を引く』とか『あいつにだけは頭を下げたくない』とか、ヒューマン・ファクター（別名、感情的対応）がまかり通ります。感情は理屈ではマネージできないのは世界共通で、だから面倒なのです。

とはいえ、自発型で小規模のプロジェクトを引っ張るならば、最低限、

・工程表（ガントチャート）に、大きなアクション項目とマイルストーンを引いたもの
・課題管理表に、細かなTo Doを並べたもの

の二つを作成し、チーム内で共有されることをおすすめします。工程表は大きくプリントして、プロジェクトチームの部屋（もしあれば）の壁に貼っておくと、もっと良いでしょう。」

（ちなみに工程表と課題管理表のサンプルは、「世界を動かすプロジェクトマネジメントの教科書」のP.165とP.216に、それぞれ掲載している）

そうしたら、「ガントチャートと課題管理表は、既に作ってありますが、壁に貼ると言うのは忘れていました。早速やってみます」との事だった。

このアドバイスがどれほどお役に立ったのかは、よく知らない。ただわたしにとっては、1つのことを考え直すきっかけにはなった。それは、工程表に描かれるアクティビティと、課題管理表やTo Do リストに書くタスクとは、何が違うのかと言う問題だ。

念のため、用語について再確認しておく。PMBOK Guideをはじめ、現代のPM理論の教科書では普通、プロジェクトは複数のアクティビティから成り立つ、と定義している。プロジェクトを構成する要素、プロジェクトの直下にある仕事は、アクティビティと呼ぶ約束である。

これに対してタスクとは、日々の細々としたやらなければならない仕事を指す。これがPM標準の世界の約束である。

そんなバカな。自分の所では、プロジェクトを構成するのがタスクだし、WBSのバーチャートの線の1本1本も、タスクと言うのが普通だ。そんな感想をお持ちの方もいらっしゃるに違いない。少なくとも日本のIT業界では、そういう言葉の使い方が珍しくない。

これは業界の習慣の問題なので、それが正しいとか間違っているとか、議論するつもりはない。ただこのサイトでは、誤解がおきないよう、PM標準的な用語に準拠して、話を進めることにさせていただく。

アクティビティとタスクでは、仕事の粒度が違う。つまり、粒の大きさである。工程表の顔とチャートに書いてあるアクティビティの線は、数日とか数週間、ときには月単位の長さだろう。例えば基本設計であるとか、要件定義であるとか、ハードウェアの調達だとか、そういった項目が並んでいるはずだ。

これに対して、日々のタスクは、ずっと細かい。次回の会議日程を調整するだとか、入力上のある項目を確認するとか、出力時に見つかった計算ミスを修正するとか、そういった事柄だ。数10分、数時間、あるいは数日といった時間尺度で動いている。

期間の長さ、あるいは時間尺度の違いだけが本質だろうか？　じつは関わる人数も違うかもしれない。要件定義のアクティビティには5人が、基本設計には10人が関わる。しかし会議日程の調整をする人は多分1人だし、計算ミスの修正も担当者が自分でやるだろう。つまり人数が多いか少ないか、工数の違いである、と。

では、期間や工数を基準にして、アクティビティとタスクの間に線引きをすることができるだろうか?　例えば1週間以上をアクティビティとし、それより短いものはタスクと呼ぶとか、5人日以上の工数がかかる作業をアクティビティとし、それよりも軽いものをタスクと呼ぶ、など。

そんなふうに問い詰められたらきっと、大抵の人は、そもそもアクティビティとタスクの区別なんて、不要じゃないの?　と答えるに違いない。タスクはさらに、サブタスクに分解することができるんだし、それこそWBSは “Work Breakdown Structure” の略だ。プロジェクト全体の仕事をどんどん分解し、階層化していける、というのが、モダンPMの発想なのだから。

それにアクティビティもタスクも、「やらなければならない仕事」である点には変わりがない。だとしたら本質的な区別は無いのではないか。

じゃぁ現実問題として、プロジェクトに関わる人々は、会議日程の調整だとか、インプット項目の確認だとか言った作業を、全部ガントチャートに書き加えていっているだろうか?　多分そんなことはしない。ガントチャートが煩雑になりすぎるのは目に見えている。

だからこそ、課題管理表の登場なのである。そういった細かなタスクというか、サブ・アクティビティを、まとめて共有するための道具立てが課題管理表だ。つまり、工程表のガントチャートに描かれる線が、主要なアクティビティであり、課題管理表で登録するのがタスクである、と。

でもこれでは、問題が堂々巡りであるような気もしなくもない。ガントチャートに書くべき作業と、課題管理表に書くべき作業は、どこで線引きをするのか。基準は期間なのか工数なのか人数なのか。

そろそろ察しの良い読者の方は、答えがお分かりになったと思う。両者の区分は、粒の大きさでは無いのだ。本質的な違いは、それが計画された作業かどうか、にある。アクティビティとは計画された作業であり、タスクとは随時発生してくる作業なのである。

ガントチャートの工程表は、プロジェクトの計画時点で作成する。これは計画の表現である。別の言い方をすると、「プロジェクトのモデル」だと考えても良い。

ところが、課題管理表は、計画時点で作りようがない。単にブランクフォームが存在しているだけだ。プロジェクトの成功とともに、だんだんと埋まっていくのである。

なぜ遂行段階で課題管理表が必要なのか。それは、計画時点では全てを見通すことができないからだ。

プロジェクトが全体でやるべき仕事を、日本地図に例えてみよう。日本全体は、北海道、東北、関東など地方に分けることができる。各地方はたとえば、青森県、岩手県、秋田県などのように県単位に分けることができる。県はさらに、市区町村に分かれる。つまり階層的なブレイクダウンである。

そこで、県単位に線引きした地図を用意して、それぞれの県の面積を測ることにする。面積がスコープの大きさを表す、と思って欲しい。50都道府県で面積の大小は多少あるけれども、概ね似た粒度で表現されている。

さて、この地図を色分けして正確に塗りつぶすのが、プロジェクトのミッションである。ところが実際にやり始めてみると、最初に描いたラフな日本地図では、細かな県間の境目の凹凸が、正確には表現しきれないことがわかる。離島もある。

ラフに引いた線と、現実の細かな凹凸の差を埋めるのが、課題管理表の役割である。ラフな線は、最初の計画を表す。

ActivityとTaskはどう違うか 〜 ガントチャートと課題管理表から考える_e0058447_19261524.jpg
プロジェクトは決して計画通りには進まない。これは誰もが知っていることだ。計画と言うのはある種の見通し、ないしは初期の近似である。でも、これがないと、全体の納期や、工数や、コストが見積もれない。だから、プロジェクトが計画通りに進まないことを知りつつも、計画は絶対に必要なのだ。

計画を現実に合わせるために必要な、細かな調整的作業がタスクである。最初の計画で引いたラフな線が、アクティビティなのだ。この2つは必ずセットになる。どちらか一方だけで済む事は、まずない。だから私は、最初に挙げた読者の方の質問に、「ガントチャートと課題管理表が必要です」と答えたのだ。

ちなみに、課題管理表は英語で “Issues Log” と呼ぶ。Issueとは問題のことで、直訳すると「問題登録簿」である。それを日本語ではかっこつけて、課題管理表と呼んでいるだけのことだ。さらに言うと、課題と問題は別のことなのだが、ここでは深入りは避けておく（「超入門・問題解決力　－　問題とは何か、課題とはどう違うか」 参照のこと）。

チケット管理システムとして知られるRedmineの元の英語版では、登録する単位的作業を、Issueと呼んでいるらしい（最近、自分の主催する研究会で、小川明彦さんから伺った）。これはRedmineが元々、課題管理表ソフトとして出発したためなのだろう。

もっとも、計画が必要だからと言って、プロジェクトでは必ずガントチャートと、課題管理表のツールの二本立てが必須だと言うつもりはない。ある種のプロジェクト、例えば、比較的小規模なアジャイル開発プロジェクトなどは、タスクボードだけで回すことができる。

でもそれは計画が存在しないとか、計画が不要だとかの意味ではない。「アイタレーション単位で回していく」と言う計画が、タスクボードの外側に存在しており、それはわざわざ複雑なガントチャートに書く必要がないだけのことである。アジャイル開発は決して、計画のない（言い換えると行き当たりばったりな）プロジェクトではない。その点は誤解を避けるべきだろう。

そして、それぞれのタスクについても、ミクロに計画を回す事は可能である。だからこそ課題管理表には、合理的な期限を設定するのである。しかしこうしたタスクは、プロジェクトの出発時点で見通して計画することができない。

最初の計画でおおまかな線を描き(Push)、実行段階で現実と合うように細かな調整とコントロールを行う(Pull)。このようなプッシュとプルの関係は、トヨタ生産方式の考え方にも通じる。トヨタ生産方式では、月度計画でプッシュし、かんばん等のプル型の仕組みで、現実と調整する。プッシュとプルは車の両輪で、どちらも必要なのだ。

あいにくわたし達の社会には、ある種の「現場力」信仰みたいなものがあって、計画軽視の文化が強い。計画というものに、何となく中央集権の管理思想みたいな匂いを感じる人もいるのだろう。自律分散、臨機応変。たしかに、いい言葉だ。だが、それだからこそ、わたし達の社会は、大きな環境変化に対応して、組織を変革する力が弱いのではないか。

冒頭の読者の方がリードされていたプロジェクトも、おそらく工場の変革に関わる事では、と想像している。縦割り組織に横串を指すような変革なのであろう。そうでなければ工場長が自ら、引っ張る必要はない。そしてきっと、計画抜きで、調整だけで進む仕事ではないはずだ。


＜関連エントリ＞
　 (2021-07-07)


by Tomoichi_Sato | 2022-02-10 19:31 | プロジェクト・マネジメント | Comments(0)
<< システムの科学理論は、はたして... 透明な燃料アンモニアに、なぜ青... >>

ファン申請

※ メッセージを入力してください