課題管理表に、どう対処すればいいか分からない「重い課題」が載せられていたことはないだろうか。例えば高いソフトウエア品質が求められるプロジェクトにおいて、納期が迫った時点で、データ連携する外部システムのインタフェース仕様が急遽変更になり、システムの機能を大幅に改修しなければならなくなったとする。その際、「一定の品質を確保しつつ、短期間で機能を改修する」という課題が発生する。 そんな重い課題を課題管理表に載せてメンバーに任せたところで、「外部システム担当者と検討会議を開く」のようなもっともらしい解決策が書き込まれるかもしれないが、解決への道筋は示されていない。結局は解決されずに放置される可能性が高い。PMは、重い課題のまま課題管理表に載せてはいけないのだ。 ロジックツリーで課題を掘り下げる 重い課題である場合、課題管理表に記録する前に、具体的なアクション（解決策）にまで掘り下げることが大切だ。
課題管理に向くサーバーソフトやGoogleドキュメントといったクラウドサービスなど、便利なツールを手軽に利用できる環境が整ってきた。そうしたツールを使うと、効率よく課題管理ができる。 しかし、ツールを導入しさえすればうまくいくとは限らない。特に、複数の開発現場を担当する「掛け持ちプロマネ」にとって要注意である。 掛け持ちプロマネは、それぞれのプロジェクトの管理業務に十分な時間を割けないもの。そこで「ツールでカバーしよう」と考え、課題管理のツールを現場に導入し、メンバーにツールを利用してもらって管理の効率化を図ろうとする。そして、ついメンバーにツールの利用を任せきりにしがちになる。 確かにツールは便利なものだ。だが、それを現場に押し付けてはいけない。 入力の煩わしさなどでツールが使われず このことは筆者の実体験から言える。以前に筆者が担当していたあるプロジェクトでのこと。そのプロジェクトでは
プロジェクトマネージャやリーダーにとって、課題管理はこなすのが当たり前の仕事だ。ところが現実には、この課題管理をうまく行えていないために、プロジェクトの進行に悪影響を及ぼしていることが少なくない。 課題管理がうまくいかない最たる原因は何か。そういったプロジェクトを支援することが多い筆者の経験から言えるのは、課題管理の方法（How）ではなく、管理すべき課題（What）に誤りがあるからだ。つまり、そもそも管理する「課題」の定義が正しく行われていないのだ。課題ではなく、現場で発生している事象である「問題」を管理していることがとても多い。 ここで言う課題の定義とは、「目的を達成するために解決すべき事柄」である。つまり課題管理で扱うのは、プロジェクトのメンバーが「次にどのような手を打つべきか」を検討したり実施したりできる内容になっていなければならない。 この違いを明確にするために、例を挙げよう。「仕
毎年、梅雨明けの7月末に情報化研究会のコアなメンバーで旅行会をしている。1995年以来だから今年で16年目だ。梅雨明けの時期にしているのは天候が安定していて盛夏らしい強烈な日射しや、群青色の海を楽しむことができるからだ。烈日と呼ばれる強い陽を浴びると、体にエネルギーを注ぎ込まれるように感じる。 今年は東京、名古屋、松山から12人が参加し、2001年以来、9年ぶりに高知へ行った。もちろん大河ドラマ「龍馬伝」の影響だ。前回は桂浜の龍馬像、岩崎弥太郎の生家などを見学した。今回も高知が初めてという三菱グループの方が3人いたので、この2カ所も再訪したのだが、筆者の目当ては武市半平太と岡田以蔵の墓に参ることだった。 さて、今回は企業ネットワークの設計や試験、移行の準備がきちんと行われ、サービス開始（旧ネットワークから新ネットワークへの移行開始）が可能かどうか判断する「サービス可否判定」（以下、サービス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
