« Javaで関数型言語みたいに書く | トップページ | JudeからRoRのWebアプリを作る »

2007/12/23

【再考】プロジェクトリーダーの仕事

プロジェクトを成功させる 現場リーダーの「技術」 」を読んだ。
この本は、プロジェクトリーダーがプロジェクトファシリテーションをどのように使えばよいか、というヒントがたくさんある。
プロジェクトリーダーの仕事について、自分なりに考えたことを書いてみる。

【1】課題と問題の違い

 「課題と問題は違う」というフレーズがある。
 この本では、下記のように定義している。

a.問題・・・目的達成の障害となる現象。例:トラブルなど。
b.課題・・・目的を達成するために解決すべき事象。プロジェクトの仕事は課題と捉えうる。

 現場でプロジェクトが立ち止まってしまう時、その事象が問題なのか課題なのかを見極めることは重要だと思う。

 問題となる事象は、因果ループ図で言うと、悪循環の負のループに陥っている構造のこと。
 特に、トラブルが起きた時、応急処置で解決することも大事だが、根本的な原因は何かを探ることも大事。
 そうでなければ、同じようなトラブルが何度も繰り返される。
 この種の管理スキルは、リスク管理で捉えることが出来ると思う。

 課題となる現象は、この課題を解決すればチームが前進する、というポジティブな問題とも言い直せる。
 だから、プロジェクトリーダーは、課題を定義し、課題を解決するHowをイメージして、担当者をアサインできれば、後は、課題をトレースすればいいだけ。
 課題さえ定義できれば、後はHowを考えて、アクションを起こすだけにすぎない。
 この種のスキルは、PDCAサイクル。

 目的から課題がスムーズに導かれるのは良い傾向とも言える。
 つまり、ゴールから論理的に導ける課題があるということ。これは、チームメンバー全員で、ゴールも課題も共有しやすいことを意味している。
 ゴールツリー、ロジックツリーから自然に導けるはず。

 この時、課題を細分化した時、課題には、What課題とHow課題の2種類があると言う。

 What課題は、ロジックツリーの第1階層に当たる。 何を実現するのか、価値があるものは何か、という観点に相当する。
 How課題は、ロジックツリーの第2階層以降に当たる。どうやって実現するのか、と言う観点に相当する。

 課題管理をすると、課題の粒度や優先順位付けに迷ってしまう所にある。
 どの課題が最優先なのか、この課題を解決するにはどれだけのリソースが必要か、を考える時、課題を細分化しないといけないが、細分化しすぎて混乱する時もある。

 僕のイメージでは、顧客からの要求はWhat課題にまで落とし、担当者1人でアサインできる粒度までHow課題を落とす。
 そうすれば、複数のHow課題をまとめたら自然に一つのWhat課題(つまり要求)が実現できることになる。


【2】問題(課題)解決がプロジェクトリーダーの仕事

 プロジェクトの仕事は課題と捉えうることもできる。
 また、突然起きるトラブル解決も、プロジェクトリーダーが解決すべき仕事の一つでもあり、責任に含まれる。

 プロジェクトリーダーに要求される役割は、論理的フレームワーク(メタ認識)を使って、問題を図式化し、チームメンバーに共有させることだと思う。
 その時に必要なスキルは、問題を図式化するモデリング技術と、チームメンバーに説明し鼓舞するファシリテーション技術。
 
 自分がプロジェクトリーダーになってから、アクティビティ図を使って、作業フローを説明する時が多くなった。
 誰が何を担当するか、そして、自分の作業はチームのどこに位置するのか、をメンバーに説明し納得してもらうことはすごく大事。
 役割と責任範囲を明確にすると、メンバーは仕事しやすくなる。
 複数のメンバーの作業のインターフェイスを調整するのがプロジェクトリーダーの仕事だと思う。

【3】管理と言うより演出

 「プロジェクトをストーリーに見立てる」というフレーズがあり、なるほどと思った。
 プロジェクトは必ずスタートとクローズがある。特に、プロジェクトをクローズする定義をあらかじめ作っておくのが大事だと思う。
 そうでなければ、プロジェクトの評価が悪くなり、従ってメンバーの士気も下がる。
 必ずハッピーエンドになるように持って行く準備をしておくことだ。

 プロジェクトをストーリーだと思えば、ストーリーに出てくる担当者が役者であり、プロジェクトリーダーは演出家だと喩えることが出来る。
 担当者が思う存分力を発揮できるように、責任範囲を決めて、開発しやすい環境を整えて、割り込みタスクを防ぐのがプロジェクトリーダーの仕事。
 管理という言葉を使いたくなるが、実際は、メンバーをサポートし、メンバーをゴールへリードするのがお仕事。
 そこには、信頼関係という基盤があり、権限と責任が発生する。
 この部分を円滑化させる技術がプロジェクトファシリテーションなのだと思う。

 この本で眼を引いた一節が「リーダーの演出」。
 プロジェクトリーダーも、チームの一員であるのだから、その役割がある。
 だから、メンバーにその役割が見れば分かるように、言動を一致するように努めたり、約束を守る、包容力を持つ、などの基本所作が必要とのこと。
 結局、プロジェクトと言う舞台では、メンバーだけでなく、プロジェクトリーダーも俳優の一部なのだ、と。

 時々、プロジェクトリーダーも現場の仕事をやる一担当者になる時もある。
 この本では「伝家の宝刀はひっそり抜く」と語られている。確かにリーダーが一担当者になると、チーム全体を見る人がいなくなるので、混乱してしまう危険性を孕む。だから、いつも刀を抜いてはいけない。

 更に「抜かない刀はさびる」とも。確かに、プログラミング技術は鍛えないと、最新技術に乗り遅れてすぐに落ちる。常に最新技術の動向はおさえておかないといけない。

 現場で働くリーダーにとって、参考になる知恵がたくさん詰まっているように思った。

|

« Javaで関数型言語みたいに書く | トップページ | JudeからRoRのWebアプリを作る »

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/17452840

この記事へのトラックバック一覧です: 【再考】プロジェクトリーダーの仕事:

« Javaで関数型言語みたいに書く | トップページ | JudeからRoRのWebアプリを作る »