ゴールを決めてから因数分解し、やることを見つける

プロジェクトマネジメントの話をする前に、みなさん自身が抱えている日々の仕事について考えてみてください。そう、

　セルフマネジメント

の領域の話です。

オフィシャルにプライベート、やりたいことにやらなきゃいけないことまで一気に「わーっ」って押し寄せてくると頭の中がパニックになる人っていますよね。

頭の中の「やらなきゃいけないこと」や「やりたいこと」が複雑に絡み合ってきて整理するのが困難な場合は、すべてを一箇所に集めたリストを作るのが理想です。

一般的にはシステム手帳など、現代ではGoogleカレンダーなどを活用している人も多いかも知れません。スマホ等と連動させればアラームで教えてくれたりもして、スケジューリングの正確性も圧倒的に向上するので便利です。

ちなみに私は自分の仕事でも整理したい場合は常にガントチャートを作ってしまいます。癖なのかもしれませんね。

こうして管理しておくことで

　「ここさえ見れば、自分がやるべきことはすべて書いてある状態」

をつくることができると、

• 脳の記憶容量に負荷を掛けず一つひとつの仕事で集中力が増加する

• 俯瞰してみることができ、優先順位の設定等で苦労しなくなる

といった恩恵を得ることができるようになります。こうしたタスクリストは、プロジェクトマネジメントの世界では、

　WBS（Work Breakdown Structure）

と呼びます。

しかしこうしたWBSを作ってみても「実際はなかなか行動に移すことができない」、書いたはいいけど「何から手を付けていいかわからない」、そんな経験のある人は多いのではないでしょうか。

おそらくは、WBSを大雑把にしか活用できず

　「複雑なタスク」

のままで放置しているからかも知れません。タスクというのはその管理の仕方、分解の仕方でシンプルにもなるものですが、なかなかそこまでできていない…と言う人は多いものです。

WBSはその名の通り、

　Work(仕事)を、breakdown（分解して）、structure（構造化する）

ものです。であるにもかかわらず、ただのタスクリストだと思っていると上図でいうところのレベル１～２あたりでまとめてしまっていて、具体的に何をすればいいかわからない状態となってしまうのです。

みなさんのプロジェクトでも、スケジュール表などで

　「〇〇設計」

とだけ書かれていて、「何の機能かもわからない」「具体的な作業レベルでは何をしたらいいのかわからない」「何から始めればいいのかわからない」といった記載があったりしないでしょうか。

これでは担当者が誰かもわかりませんし、名指しで担当者を決めたとしてもその担当者はこれを見て、

　「なにから始めればいいのか」
　「なにを作ればいいのか」

もわかりません。そう、

　タスクがアクションに落とし込めていない！

ということが問題なのです。

アクション…つまり具体的行動まで落とし込めていないということはどういうことかと言うと、実際の活動そのものがイメージできていないため、当然ながら具体的な工数もわからないということになります。

工数と言うのは、

　１人がある作業を行うために必要な時間 × 実際に必要とする人数

で算出されます。
ここで言う「作業」がアクションです。

たとえば、「要件整理」と言うタスクにはどんな作業があるのでしょう？

「お客さまとの打ち合わせ？何回？１回あたり何時間は？」
「資料作成？どんな様式？」
「１ページ当たり何分？何ページ分くらいになるの？」
「レビューは？何時間？何名参加するの？」
「修正時間はどの程度見込んでる？」

こうした分解をしないまま「要件整理」とだけ言われても、それで工数が見積りできるとは到底思えません。当然、どんなに整理されているように見えても、その実やってることはただの"KKD（勘、経験、度胸）"にしかなっていない…というのはよくあることです。

スケジュールを作成する際の工数もある一定のルールや標準ありきで計算し、予測するため、こうした工数のことを

　"理論工数"

と呼びますが、この理論工数が正確でないとプロジェクトは瞬く間に瓦解します。なぜなら工数によってスケジュールが確定し、工数によって予算が決定するからです。というかKKDには明確な論理が存在しないわけですから、KKDベースで算出した工数は理論工数とも呼べません。

タスク管理が上手くできない人は、自身の言う「タスク」が大きすぎて、一口では咀嚼できないレベルのまま管理している可能性が非常に高いのではないでしょうか。

たとえば「○○さんにTELする」「△△さんに□□を質問する」などというタスクは、一つのアクションで済む比較的単純なタスクといえそうです。

タスクを分解するうえで、

　「もうこれ以上、分解しなくてもすることがわかる」

と言うレベルに落とし込めています。
しかし「会議の準備をする」などは、その中に

• 各関係者との日程調整

• 会場の確保

• 会議用資料作成

• アジェンダの事前送付

• 会場のセッティング　etc.

多くのアクションを含む「複雑なタスク」です。

「複雑なタスク」は多数のアクションを含んでいるにもかかわらず、あたかも一つのタスクのように書かれています。ですから一つひとつの作業がイメージしにくく、ひいては全体像の把握が曖昧で、やり始めてからてんやわんやの状態になったり、そうしたことばかりが続くといつまでも手付かずのままリストの中に居座り続けてしまったりするわけです。

複雑なタスクは「分解する」しかありません。

WBSを「WBS」と言わしめるのは、分解し、構造化して管理するからです。
分解もしないWBSは「WBS」と呼びません。管理もできない「ただ作っただけのリスト」です。

そして「もうこれ以上、分解できない！」という状態までタスクを分解することを私は「タスクの素因数分解」と呼んでいます。

素因数分解の例

WBSはプロジェクトマネジメントの第一歩です。

計画するにしても、管理（監視）するにしても、コントロール（やりくり）するにしても、何をするにしても必要不可欠なものです。なにせ『自分が何をしなければならないのか』『具体的に何をすればいいのか』を理解していなければ何も始まりません。

WBSは自分たちの責任範囲「スコープ」を決めるうえでもとても重要なことです。WBSが作れなければ「計画」は絶対にできません。

こうすることで、そのタスクを構成するアクションが明確になります。
つまり

　「どうすればこの複雑なタスクが片付くか」

が分かりやすくなり、行動に移しやすくなります。

これが為されていないプロジェクトでは、

「あとは担当ごとに勝手にやって」

と言われているようなものでです。到底、プロジェクトマネージャーが自らの責任を果たしているとは言えない状況です。企業組織においても同様で、善管注意義務を放棄している状態と言って差し支えないでしょう。

もしそうなっているようであれば、残念ながらそのプロジェクトマネージャーや上司に任せていても、上手く進むことはないでしょう。

ですがそういう時に、

　「プロジェクトマネージャー（上司）が悪い」

と言ったところで問題は解決しません。プロジェクトマネージャーや上司にその力量が無ければ「悪い、悪い」と言って責めたところで、そのプロジェクトマネージャーや上司にはどうすることもできないからです。

その際には、自分に与えられたタスクリストを眺めて、

　「これは複数のアクションをはらむ複雑なタスクだ」
　「まだまだ細かく分解できるんじゃない？」

というものを見つけたらまずは自分で分解してみましょう。
その上で、プロジェクトマネージャーや上司に

　「こういう進め方で行こうと思いますけど、いいですか？」

と確認してみてください。きちんとコンセンサスが取れた進め方は、そのまま具体的計画（アクションプラン）として認知されます。

もしもプロジェクトマネージャーや上司がマネジメントのできないような人であったとしても「それはそれ」として、自分自身のタスクのマネジメントは自分自身でできるようになっておいた方がいいのは間違いありません。マネジメントを任せるというのは、その期間中の自分の人生を預けるようなものです。できない人に任せっぱなしにはしたくないですよね。