［課題管理編］重い課題のまま管理してはいけない
課題管理表に、どう対処すればいいか分からない「重い課題」が載せられていたことはないだろうか。例えば高いソフトウエア品質が求められるプロジェクトにおいて、納期が迫った時点で、データ連携する外部システムのインタフェース仕様が急遽変更になり、システムの機能を大幅に改修しなければならなくなったとする。その際、「一定の品質を確保しつつ、短期間で機能を改修する」という課題が発生する。 そんな重い課題を課題管理表に載せてメンバーに任せたところで、「外部システム担当者と検討会議を開く」のようなもっともらしい解決策が書き込まれるかもしれないが、解決への道筋は示されていない。結局は解決されずに放置される可能性が高い。PMは、重い課題のまま課題管理表に載せてはいけないのだ。 ロジックツリーで課題を掘り下げる 重い課題である場合、課題管理表に記録する前に、具体的なアクション（解決策）にまで掘り下げることが大切だ。
［課題管理編］ツールを押し付けてはいけない
課題管理に向くサーバーソフトやGoogleドキュメントといったクラウドサービスなど、便利なツールを手軽に利用できる環境が整ってきた。そうしたツールを使うと、効率よく課題管理ができる。 しかし、ツールを導入しさえすればうまくいくとは限らない。特に、複数の開発現場を担当する「掛け持ちプロマネ」にとって要注意である。 掛け持ちプロマネは、それぞれのプロジェクトの管理業務に十分な時間を割けないもの。そこで「ツールでカバーしよう」と考え、課題管理のツールを現場に導入し、メンバーにツールを利用してもらって管理の効率化を図ろうとする。そして、ついメンバーにツールの利用を任せきりにしがちになる。 確かにツールは便利なものだ。だが、それを現場に押し付けてはいけない。 入力の煩わしさなどでツールが使われず このことは筆者の実体験から言える。以前に筆者が担当していたあるプロジェクトでのこと。そのプロジェクトでは
［課題管理編］問題を課題と勘違いしてはいけない
プロジェクトマネージャやリーダーにとって、課題管理はこなすのが当たり前の仕事だ。ところが現実には、この課題管理をうまく行えていないために、プロジェクトの進行に悪影響を及ぼしていることが少なくない。 課題管理がうまくいかない最たる原因は何か。そういったプロジェクトを支援することが多い筆者の経験から言えるのは、課題管理の方法（How）ではなく、管理すべき課題（What）に誤りがあるからだ。つまり、そもそも管理する「課題」の定義が正しく行われていないのだ。課題ではなく、現場で発生している事象である「問題」を管理していることがとても多い。 ここで言う課題の定義とは、「目的を達成するために解決すべき事柄」である。つまり課題管理で扱うのは、プロジェクトのメンバーが「次にどのような手を打つべきか」を検討したり実施したりできる内容になっていなければならない。 この違いを明確にするために、例を挙げよう。「仕
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
