ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守(アプリ方面)のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

タスク管理におけるリスクの扱い方

今日もちょっと手を抜いてプロジェクト内で作成途中の講義マテリアルのために書いている文を流用。プロマネというより、個々人のタスク管理の話です。

不確実性のあるタスクを先に片付ける

以下の2つのタスクを抱えていて、どちらも期限は今週中だとします。どちらから手を付けますか?

  1. 新しく入れる予定のチェックロジックの技術検証。始めて使用する技術で何から手を付けていいか分からない
  2. 月次定常作業のデータ変換&投入作業。変換ロジックが複雑なため自動化されていないが、これまでも実施したことがあり手順は確立している。

正解は1から着手すべきです。そして1に割く時間は「今週の作業可能時間 - 2の見積作業時間」に区切ることを厳守して、そこまでに終わらならそうなことが分かった時点でアラートをあげます。これを逆の順序で行ってしまうと、アラートをあげられるのが遅くなってしまいます。

不確実性のあるタスクを先に片付けることで、早いタイミングでアラートをあげることが出来、期限ギリギリ、もしくは過ぎてから遅延報告するという最悪の事態を避けることが出来ます。

これは、当たり前じゃんと思う人がほとんどなのですが、実際にそれに従って動けている人は少ない。「うーん、1はどこから手を付けていいか分からないし、とりあえず2を始めるか」とやってしまうことって多いですよね。

<不確実性のあるタスク例>

  • SVのレビュー結果によって手戻りが発生する可能性のある(可能性が高い)作業
  • 始めての作業で完了までに必要な工数に検討がつかない作業

<不確実性のない(小さい)タスク例>

  • (たとえ作業時間が長くとも)既に一度実施したことがあり、どのくらいの時間が必要か判明している作業

リスクを低減させるところまでを先に片付ける 

一つ前の応用問題です。以下の2つのタスクを抱えていて、どれも期限は2週間後。前半1週間で何を終わらせますか?

  1. 新しく入れる予定のチェックロジックの技術検証
  2. 「こんな感じで資料まとめといて」とSVから丸投げされた資料作成
  3. 先日ユーザから声の上がった仕様変更の要件定義(要求仕様書作成まで)

正解は1-3を並行して作業し「各作業にどのくらいの時間・工数がかかるか」を見極めるところまでを前半で行うべきです。

<前半でやるべきこと>

  1. えいやでPGM組んでみてメインストリームの検証
  2. たたき台を作ってSVと認識合わせ
  3. メール・口頭でユーザと要件概要をすり合わせ

までをやってしまいましょう。

 <前半にやるべきでないこと(後半にやるべきこと)>

  1. 例外処理等細かな検証、仕様書や報告書の作成
  2. 資料の細かい中身の作り込み、見栄えの調整
  3. 要求仕様書の作成

 不確実性のあるタスクを複数抱えているのであれば、1つのタスクに注力せずに、各タスクの「不確実性をなくす」ところまでの作業を先にやってしまうべきです。

※ ただし、自分がマルチタスキングすると極端に効率が落ちる自覚があるのであれば、SVにタスク割り振りを相談することも考えましょう。

リスクを外部化する 

ある月の初旬、ユーザからあるデータの一括更新をしてほしいとの依頼がありました。来月から更新されたデータが必要なので、同月末までにやってほしいとのことですが、まだ更新対象のデータの選定中なのでそのうちに送るそうです。

あなたはこの依頼に対してどのように回答しますか?

正解はデータ受領後に必要な時間を見積もり、いつまでにデータを送ってほしいかをユーザに伝える、です。その際に「XX/XXまでにデータ受領出来ない場合は、今月中に対応出来ない可能性がある」とリスクを共有することが大事です。また、見積時間があいまいな場合は、最悪のケースを想定して最大でかかる時間・工数を採用すべきでしょう。

特に運用保守の現場では「言われたらやるしかない」という状況になりがちですが、上記のような予防線を張っておかないと以下の様な状況に陥ってしまう可能性があります。 

  • 当月中にタスクを完了させるために、残業や休日出勤が発生する。
  • 当月中にタスクを完了出来なかったことを自社の責任にされる。
  • 当月中にタスクが完了出来なかったことによる追加の作業をさらに依頼される。

リスクの管理は進捗・工数と違って(そして品質と似て)定量的に測定しづらいもののため軽視(というよりは見ないふり)されがちです。一方で後々にならないと顕在化しにくく、顕在化した時点では手遅れという可能性があるという意味では可視化しやすい進捗・工数よりも厄介なものですね。そのため、それら以上に意識的に扱う必要がある、と思います。

 

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

 

  

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理