どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
CCPMのおはなし2-6(原理編6):プロマネで発生しやすい問題 Д織好編(前編)
CCPMのおはなしシリーズです。
今回も原理編です。プロジェクトマネジメント知識体系を取り入れたプロジェクトで発生しやすい典型的な問題を紹介してみます。こちらがCCPMにて解決を行う対象となります。
まずはタスク編(前編)です。やたら長いです。

-----------------------------
<参考情報>
本内容は連載的に紹介しております。本記事の前提や全体的な構成についてはこちら(リンク)を参照ください。
現在記載の内容は原理編です。こちらの前提や構成に関してはこちら(リンク)を確認ください。
-----------------------------

前回、CCPMに関連するプロジェクトマネジメント知識体系を紹介してみました。このプロジェクトマネジメント知識体系を取り入れた場合に典型的に発生しやすい問題点というものが存在します。
今回からは、その問題点について紹介してみます。まずはタスク定義、見積り、進捗管理に関わる部分を紹介します。

※注:本内容はプロジェクトマネジメントの知識体系をけなしている訳ではありません。CCPMが解決する対象となる典型的な問題点をまとめることを意図した内容ですのでご了承ください。


■プロジェクトマネジメント知識体系の典型的な問題の全体像

最初に、前回紹介したプロジェクトマネジメント知識体系の理想的な世界における問題点をマッピングしてみます。
図は1時間くらいかけて作ったのですが…無念な感じに。
折角描いたのに…
※クリックで拡大

全体像としては、以下のような問題点が発生しやすいだろうと考えられます。
・誰も見ない、更新されない計画
・見積もりの化かし合い
・遅れは許さない進捗管理(コスト管理のプレッシャー)
・マトリクス管理の誤解
・稼働率100%、複数業務並列
・目先・気になった問題を優先解決
・いつのまにか挽回できない遅れに
・人員導入でカバーするも?


以下、問題の発生する背景や状況について順次深堀していきましょう。


■プロマネ体系における典型的な計画、タスク管理方法

問題に入る前に、プロジェクトマネジメント知識体系を取り入れた場合の典型的な手順を確認してみましょう。

※なお、本内容は(なんとなくでも)「プロジェクトマネジメント知識体系」を取り入れた組織・人を前提としております。その「典型的」な例を盛り込んだ紹介になります。
そのため、「タスク定義なんてやったことないよ」もしくは「ボトムアップ的にチケット(タスク)管理している」というような状況とは異なる場合も当然あるはずです。


★タスク定義〜管理のフロー
プロジェクトマネジメント知識体系を取り入れたプロジェクトでの典型的なタスク定義から進捗管理までのフローを紹介すると以下のようになります。

タスク定義⇒見積り⇒担当割り当て⇒進捗管理

担当割り当てと見積もりの部分は前後する場合もあるかもしれませんが、このようになることが多いのではないでしょうか。


★個々のフローでの実施内容
それぞれの例を紹介してみます。

1.タスク定義
WBSのような形式などでタスク分解することで、実施するタスクを定義していきます。
正確には、WBSでの分解はワークパッケージ単位ですので、それをアクティビティに落とし込んだものがタスクにはなりますが、まぁこの辺は「分解してタスクにする」くらいにしておきます。
わーくぶれーくだうん

何となく作業が決まってる、分解なんてしない…という場合も有りますが、そのようなプロジェクトは大抵後半で炎上してますね…。

2.見積り
個々のタスクに対して、見積りをして予定・期限との調整をしていきます。

3.担当割り当て
タスクの責任者を割り当てて行きます。タスク定義・見積り・担当割り当てがされると、ガントチャートのような形式にまとめることが多いです。
割り当てと見積もり
※クリックで拡大

4.進捗管理
決まった予定に対して進捗管理を行っていきます。
週の定例会や朝会などで停滞する問題を確認して解決するなどが行われることが多いのではないでしょうか。


まあ、そもそも「こんなことやってないよ!」という方もいるかもしれませんが、プロジェクトが遅れて修羅場になり、エライ人が厳しく監視している時などはこのような方法に固まることが多いかもしれません。


■計画、見積り、担当割り当てから起こりうる問題

★計画、見積り、担当割り当て後の進捗管理の見え方
ガントチャートでもRAMでも良いですが、計画・見積り・担当割り当てが決まった後の進捗管理はどのようになるでしょう?

実際に見えるカタチをいくつか図にしてみましょう。

・人(組織)の見積り割り当てマトリクスでの見え方。
もぐらたたき!
※クリックで拡大

・ガントチャート+イナヅマ線での見え方。
ガント&イナヅマ
※クリックで拡大

実際にはもっと複雑でしょうが、見え方の感覚的には同じのはずです。


★遅れを許さない進捗管理
さて、これらを進捗管理として見たらどう考えるでしょうか…?

「超過した部分をモグラたたきする」ことになりやすいのではないでしょうか。「遅れたらどうなるか分かってんだろうな」というような遅れを許さないプレッシャー、厳しいフォローが与えられる場合もあるかもしれません。

キッチリとタスクに役割と見積もり時間を割り当てるほど、遅れが明確になります。また、タスクの見積りというのは実施タイミングとの時間の開きがあるほど外れる確率・外れ値の差も大きいです。
さらに、プロジェクトは「新しいこと」を行うことが多いです。これをプロジェクトの新規性と呼びますが、この新規性のあるものは予測が難しいことが多いです。

そのため、直近で決めたタスクの見積りでさえも(新規性によって)ブレは発生してしまいます。
※本記事後半の「■(参考)見積りの不確実性」参照。

結果、タスク単位で遅れがそれなりの確率で発生してしまうのですが、進捗管理が見えてしまうため、「遅れを許さず厳しくフォローする」ような状況になりがちです。(特に自分に甘く他人に厳しい管理職なんて酷いものです…ストレスタカイ)

このような「遅れている人に無理に業務をさせる」、「計画に縛り付ける」行為が行われると現場はウンザリしてしまう状況になってしまいますね。


★誰も見ない、更新されない計画
さらに「計画作りが大変であるほど、後生大事にされる」という傾向があります。計画を修正する作業時間が計画の時にかかる時間(例:2週間…)と同じくらい大変だと考えると、手をつけたくないと考えてしまうでしょう。

また、計画の見直しのタイミングはあまり明確に示されてはおりません。このことも、計画を役立つように見直し更新する行為から遠のいて行く一因でしょう。

結果として、作成した計画は見直しされないまま現実状況とかけ離れて行き、現場では「役に立たない計画は見ない」という判断が行われることもあるでしょう。

こちらの結果は、チームがバラバラの活動を行うようになり、最終的にやるコトが出来てなく炎上…となることが多いです。


★結果
こういったことから「計画で縛り付け、遅れを許さない」、もしくは「計画は役に立たないもの」という感覚が強くなってしまいます。

それでは「計画で縛り付け、遅れを許さない」行為が他の問題を引き起こす件について続いて紹介します。


■プロマネ体系における典型的な計画、タスク管理による見積り問題

では、上記の結果である「計画で縛り付け、遅れを許さない」という考え方が発生するとどうなるでしょう?
「遅れたらどうなるか分かってるだろうな!」というようなプレッシャーの状況下ではでどのように見積りを行うでしょうか考えてみましょう。
プレッシャーをかけると?

遅れたら怒られるのであれば、個々の見積りは「個別バッファ(=安全余裕)」を入れて「これ以上短く出来ません!」と主張するかもしれません。
※普段からたんまりバッファとってノンビリ仕事してる人も見かけますが…
見積りは減らせないッ!

他にも、同時にプロジェクトを複数対応している場合などは、他の仕事状況を考慮して100%集中して作業する前提の見積りなどは行わない可能性も有ります。(後述する「バッドマルチタスク」に関連)

このように、遅れを許さない進捗管理、コスト管理をハッキリ見えるように管理した結果、進捗に対するプレッシャーが与えられます。
このせいで、個々のタスクに個別バッファを入れた見積もりを入れてしまうことになるのです。

酷い場合には「見積もりの化かし合い」といった、見積もりの場が多くの運命を決めるような世界になる場合も有ります。この世界に達すると、政治的に強いタイプの人が上手くやりくりする状況になりがちです…ストレスタカイ

ただ、この個別バッファを入れる行為は悪いことではなく「どうしても守らないといけない大事な期限」であるほど余裕を持って対処しようとする傾向によるものです。
大事な人との待ち合わせ、人生の一大イベントのような場合には早めに準備して余裕を持って対処します。これと同じようなことが個々のタスク見積りに発生してしまうのです。


■稼働率100%と仕事の割り当てによるマルチタスク

もう一つ発生しやすい問題点を紹介します。
会計的には組織における人の稼働は該当時間まで達していないと「不利差異」とみなされることがあります。いわゆる操業度的な計算となりますね。

上記の理由だけに限りませんが、「稼働率100%」という謎の用語が飛び交うことになることもあります。経営者やマネージャ的にはみんな動いていた方が安心することが多いらしいです。

この稼働率100%想定を沢山あるプロジェクト状況と組み合わせるとどうなるでしょうか?当然複数のプロジェクトに同一担当者を割り当てて「稼働率100%」を達成しようするでしょう。
片方のプロジェクトは60%、もう片方は40%などで業務をする指示があるような状況になります。
稼働率100%のジレンマ

この条件下では、担当者は2つ、3つ、それ以上にぶった切られた状況で仕事をこなすことになってしまいます。酷い時は17分割…
上手な人は複数作業を効率を落とさずに作業をすることもあるのですが、この複数作業が増え続け、切り替えが多数発生するような状況下では、一般的には業務効率の落ちる「バッドマルチタスク」という状況に陥ります。

結果として、個々のプロジェクトは担当者の100%の速度などは出せず、さらには想定した速度すらも出せない…ということになってしまいます。


■(参考)バッドマルチタスク

バッドマルチタスクはマルチタスク自体を否定しているのではありません。
進捗に大きなマイナス影響を与える多数の切り替えが行われる「バッド」マルチタスクを問題としております。

バッドマルチタスクは単純に複数の作業に切り替わるだけでなく、「切り替え時の(頭や資料等の)準備コスト(=オーバーヘッド)」も必要になります。そのため、多数の仕事が切り替わることが多いほど効率が落ちると言われております。

以下の図のような感じでしょう。
おーばーへっど発生

図で見ることで明らかに作業が遅くなっている状況が分かります。

バッドマルチタスクを例として挙げるのであれば、英語の単語書き取り、数学の問題、国語の漢字書き取り20問を1問ずつ切り替えながら行うようなものです。
計算と漢字と英語

上記をやったことはある人は少ないと思われますが、1つずつシリアルに完成させるより遅い結果が得られます。
実際の業務でも頭の切り替えが多数発生すると業務が遅くなり、ストレスがたまる状況というのは感覚的に理解頂けるはずです。


■前提のまとめ

一旦まとめてみましょう。大きなポイントは2つです。

1.個々のタスクに対する個別バッファ
計画でタスク分割、見積り、担当者割り振りを明確にすると「厳しい」進捗管理で遅れを厳しくフォローする状況になります。
その結果、個々のタスクの見積りに対して個別バッファ(安全余裕)を入れることで確実に終わらせるような傾向が増加してしまいます。
なお、見積りに個別バッファを入れる理由は、「■(参考)見積りの不確実性」に後述する内容も関連しております。

2.バッドマルチタスクによる効率低下
また、稼働率100%を求める組織においては複数のプロジェクトに一人の担当者を割り当てようとします。その結果、それぞれのプロジェクトに対する作業割合が減るだけでなく、オーバーヘッドによる切り替えコストがかかってしまいバッドマルチタスクという効率低下状態が発生してしまいます。

バッドマルチタスクは、効率低下以外にタスク見積りに対する個別バッファを追加してしまう理由にもなってしまいます。


■(参考)見積りの不確実性

見積りも100%確実な内容を出すことが出来るのであれば、上記のような心配は不要なのですが、実際にはプロジェクトとは「何か新しいことを行う」ということで新規性が存在します。

そのため、新規性を持つ業務では”見積りは不確実なものである”という前提を持つ必要があります。
この見積りの不確実性を示す情報として2つ紹介しようと思います。


★不確実性コーン
不確実性コーンはプロジェクトの進行と見積もりのばらつきの関連性を示したものです。
簡単に言うと「プロジェクトの最初の(全体にかかる)見積りはばらつきが大きく、最後になるほど小さくなる」というものです。
当たり前ですが、実際に数値的に示されているのが興味深い部分です。
プロジェクト初期での見積もりは、実際の1/4〜4倍となる可能性が有るというものです。
不確実性コーン

こちらはCCPMとは直接関連するモノではないのですが、見積りがばらつく可能性があるということを数値的に示している根拠の1つとして紹介しておきます。


★見積りの不確実性
見積りの不確実性は、個々の見積りに対して提示する見積もり期間と完了する確率を示したものです。
以下のような「β分布」に従うと言われております。
見積りの不確実性β分布

グラフからは以下を読み取る事が出来ます。
・タスクが50%で完了する可能性を考慮すると結構短い見積りとなる。
・80%、90%以上と確実に完了するように見積もると、長い時間となる。

ざっくり「2日で終わりそうだけど一声で2倍にしておこう!」というのは、
2日で50%の確率で終わりそうだけど、80%の確率で終わる4日にしよう、ということを意味するような感じです。

実際に、このようなタスクの見積もり-実績状況が発生していると言われております。

例として1点紹介します。
趣味?で「折り紙の鶴」を折る時間を複数人分測定してグラフ化しております。
折り鶴の完了時間例

さて、以上のグラフような終了可能性が得られるとしましょう。
4分あれば50%の可能性で完了しそうです。8分あればほぼ確実に完了するかもしれませんね。
あなたは、どんな状況で何分の見積りを行うでしょうか?

…まあ、説明や補足は以上として、CCPMではこの見積もりの不確実性に関する統計的分布を考慮した解決策を提案しております。


■見積り時のジレンマとタスクの個別バッファ

結果として、個々のタスク見積りには(状況や人の特性によりますが)個別バッファ(安全余裕)が含まれる状況が発生してしまいます。
この理由は、既に紹介した遅れを許さない進捗管理や見積もりの不確実性、確実に終わらせようとする人の責任感によるものです。
個別バッファのまとめ!

この辺、見積り時には「信頼できる人/出来ない人」が相手で個別バッファを増やしたりする場合もあるかもしれませんね。
また、積極的な見積もりを行うことで生産性も高くなり成長にもつながるコトも多いです。
この辺はジレンマが発生する部分になるでしょう。


さて、タスク編かつ前編でこんなに長いという状況になってしまいました。
次回は、「タスクに含まれる個別バッファ」がもたらす影響に関して紹介してみます。
| TOC/TOCfE/CCPM | 12:28 | comments(0) | - |









      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ