タスク管理の実現のために、WBSを標準化するためにはどうしたら良いのか？
今日は、タスク管理についてはお話ししたいと思います。
前回（Vol.5）のブログで触れましたが、私たちはプロジェクト管理ツール OBPMのパッケージの導入支援を行っています。
OBPMには、プロジェクト管理をするための機能が豊富に備わっているのですが、その中の「ドメインマスタ設定」機能を使って、WBSや成果物を標準化したものをテンプレートとして定義することができます。
お客様には、とても好評な機能なのですが、いざ設定するとなると、「WBSを標準化したい。が、そのためには、タスクはどう管理するのが正しいのですか」と聞かれることがあります。
そもそもタスクとは、何を示しているのか具体的なイメージはおありでしょうか。
先ずは、WBSをどのように作成していけばよいのか考えてみたいと思います。
タスク管理のためのWBSとは
WBSとは、ワーク・ブレイクダウン・ストラクチャーの略です。一般的に「作業分解図」と訳されています。「ワーク」は、日本語で「作業」と約しますが、これは誤りです。本来はワークというのは「成果物」を示します。
成果物を分解するというのが、本来のワーク・ブレイクダウン・ストラクチャーを意味しています。
ただし、成果物はプロセスやタイミングがわからないとイメージできない場合があります。
そのためWBSを作成する方法は大きく２種類あります。
①プロセスで分解する
多くのIT企業様の開発現場で使われている手法です。
例えば、システム開発だと、立上げ→要求分析→設計→製造といったプロセスに分けてそれぞれで必要な成果物・タスクを定義していきます。
②成果物で分解する
成果物とはドキュメントやプログラムを示します。
これらをベースにしてタスクをブレイクダウンしていく方法です。
②の成果物ベースで考えることに慣れていないため、何をアウトプットとして良いかわからないとなり、なかなかWBSが作れません。
そのため、①のプロセスがわかったほうがイメージし易いですよね。
ちなみに、OBPMでは「①プロセスで分解する」方法を採用しています。
タスクとは
ネットで「タスクとは」と検索すると
1. 課された仕事。課題。
2. コンピュータで処理される作業の最小単位。ジョブ。
と表示されます。
なるほど「仕事の単位」ということですね。
プロジェクトにおいて「仕事の単位」はどの粒度で定義すればよいでしょうか。
タスク粒度を誤ると作業進捗の管理が煩雑になったり、タスクの抜け・漏れによる手戻りが発生し、品質低下を招いてプロジェクトへ大きな影響を与えてしまうことがあります。
タスク管理とは
次にタスクの作り方について考えていきたいと思います。
その前に、タスク管理の失敗例を上げてみます。
①タスクの粒度が粗すぎて、具体的な作業内容や終了状態がわからない。
- 成果物イメージ（ゴールイメージ）が出来ていない。（メンバから見たら）PLや指示者の言っていることがコロコロと変わっている。
- 成果物までの道のりがイメージできておらず、不明確なタスクや中途半端なタスクとなっている。
②タスクの粒度が細すぎて、実行イメージがわかない。
- 先々の作業まで細かく切られており、実現味がない。
- 必要以上に細すぎてメンバを縛りつけているだけになっている。（Todoレベルまでタスク化されている）
③タスクの挿し込みが多すぎて、管理が煩雑になっている。
- お客様とスコープ・成果物の共有ができていないため、後からタスクが追加される。
- タスクの抜け・漏れにより、追加タスクがどんどん増えていく。
④タスクの必要条件が整っていないため実施できない。
- 必要な資料・確定情報が整っていない・共有されていないため着手できない。（要件未確定、仕様書未完成、レビュー未実施など）
いかがでしょうか。
自身の経験や他プロジェクトのヒアリング結果をもとに記載した内容なので、他にも代表的なものあるかもしれませんが、これら失敗経験を活かしてタスク管理することが重要となります。
プロジェクトを成功に導くタスク管理とは
プロジェクトを成功へ導くタスク管理とは、
①成果物イメージ、プロジェクトのゴールイメージが明確なタスクとなっている。
- とりあえず的なタスクは作成しない。
- 具体的な作業がイメージできるようお客様と合意した成果物サンプルがある。
②先々の作業については、最初からあまり細かくしすぎていない。
- いきなり細かい計画を立てても意味がない。
- 最初からやることが全て細かく決まっているプロジェクトはありません。タスクは自分たちだけでなく、お客様のタスクもあるため、プロジェクトの状況によっては柔軟に対応できるよう身構えておく必要があります。
③不確定要素をできるだけ取り除いている。
- 課題管理をしっかり行って、お客様やメンバと情報共有している。
④タスクの必要条件や複数タスクの関係性が明確である。
- タスクへのIN/OUTが明確で、かつタスク間の関係が整理できている。
- IPO（インプット・プロセス・アウトプット）を明確にしてお客様やメンバとしっかりコミュニケーションが図れている。
以上のことを踏まえ、先ずは、プロセスごとにインプットとアウトプットを洗い出してIPO（インプット・プロセス・アウトプット）を作成してみてはいかがでしょうか。
アウトプット（成果物や終了状態）に対して、タスクを１階層、深くても２階層までで作成してみてください。
WBSを標準化するためのタスク管理とは
先に述べましたが、タスクとは仕事の単位を示します。タスクの粒度は、粗すぎては駄目ですし、逆に細すぎても意味がありません。先ずは、全体計画を大まかに立てた後、一番近いマイルストーンまでの計画を詳細化していくことをお勧めします。
（この時マイルストーンは、一番大きなプロセス（工程）の終了を示します）
直近の工程であれば、情報量が多く作業が見えているので計画が立て易いはずです。
次のマイルストーンが近くなったら、次の詳細なタスクを作成していくのはいかがでしょうか。
現場は、最初からいきなり100%の成果物やWBSができるかというとそうではありません。ああでもないこうでもないと試行錯誤しながら、タスクの粒度・精度を上げていくのです。そのための雛形があると便利と思いますよね。
OBPMはそれが、「ドメインマスタ設定」にあたるのです。
「ドメインマスタ設定」でタスク管理のベースを作る
「ドメインマスタ設定」とは、プロジェクト計画策定時に必要なプロジェクト管理情報をテンプレートとして予め登録しておき、プロジェクト立上げ時に管理項目の抜け漏れを防いだり、管理粒度を統一するために設定します。
俗人的な管理をやめ、プロジェクト管理、タスク管理を標準化するための機能です。
この画面で標準WBSを作成していきます。
アウトプット（成果物）に着目してWBSを作成していきます。
1階層目は工程となりますが、2階層目は、成果物とした方良いのか、成果物を完成させるタスクとした方が良いのか悩みますが、これまでのわたくしの経験では、正解はないと考えます。
好みはあるかもしれませんが、わたくしは、パターン２の方がタスク管理しやすいと考えます。
いかがでしょうか。
どちらが今まで自分たちがやってきたタスク管理とマッチしているでしょうか。
上記パターン以外にもタスク管理の方法はあると思います。
「工程タスク成果物登録画面」では、詳細タスク（アクティビティ）まで作成する必要はありません。
ただし、今後、スケジュールやタスクの進捗管理を行うイメージを作っておかないと、実際に利用するイメージがわきませんよね。
OBPMでは、タスクの進捗実績（進捗率）についても標準化してドメインマスタへ設定しておくことができます。
先ほどのパターン１を使うのかパターン２を使うのかでは、進捗管理の指標の方法も変わってくる可能性があります。
わかりやすいタスク管理とは
これまでのことを纏めると、タスク管理とは
- プロセスごとに成果物（ドキュメントや終了状態）が明確であり、成果物に紐付いたタスクとなっている。
- タスク間の関係性（タスク関連線）が明確であり、作業開始条件や進捗状況、課題が共有されている。
- タスクの粒度は、粗すぎず・細すぎず（Todoまで落し込まない）長くても３人日程度の作業計画である。
最後の作業計画については、ここで初めて触れる話ですが、プロジェクト管理に関する資料では、よく最大でも５人日以内に収めるとよい記載されてありますが、実際は、一週間全く同じ作業をすることはあまりないと考えます。
そのため、長くても３人日に収まるようなタスク管理をする（タスクを分割する）ことが理想的であると考えます。
タスク管理とは、PLがプロジェク管理を行う上で、もっとも重要な計画作業です。タスク管理がきちんとできないとプロジェクトはあっという間に崩壊してしまいます。タスク管理がきちんとできるPLは、プロセスを確実に早く回すことができメンバからの信頼も厚いです。
タスク管理でしっかりと見える化を進めて、成功プロジェクトを増やしていきましょう。
プロジェクト管理に関する詳しい資料もご用意しています。ぜひご活用ください。
