プロジェクトにおけるサーバント・リーダーシップ -10- | キットPM奮闘記 改め キットビジネスアナリスト奮闘記

キットPM奮闘記 改め キットビジネスアナリスト奮闘記

PMの世界からビジネスアナリストへ、キットPM2.0を目指して奮闘中です。BAを超上流とか言いますが、当たり前のようで難しいビジネス要件をどうやればちゃんとまとめられるのか、皆さんとご一緒に考えていきます。

ットPMは今長崎に来ています。もちろん仕事です。ということで、ちょっとバタバタで更新が遅くなりました。

  長崎は台風一過の秋晴れ、というわけにもいかず、秋とは程遠い猛烈に蒸し暑い日が続いています。皆さんはいかがお過ごしでしょうか。

て、サーバント・リーダーシップについて考えています。前回はサーバント・リーダーシップをプロジェクトマネジメントに適用しようとすると問題になるであろう、2つの点を上げました。

  一つは、示したゴールに向けてどのような道筋でたどり着こうとするのか、プロジェクトの方針を、フォロワーであるプロジェクトメンバー自身が考え、全員が合意するようなプロセスをいかにサポートするかということです。

  2つ目はサーバントであるPMを見守り手助けする手段を確保するということでした。




つ目については、キットPMがこのブログで何度かご紹介した「タスク抽出」という手法を使うことが、もっとも合理的な方法であると考えます。

  繰り返しになりますが、タスク抽出はプロジェクトの中心となる複数のメンバーがそれぞれの経験と知恵を持ち寄って、ゴールから逆にたどりながら必要な作業を上げていく作業となります。

  例えば、仕様を決定するという中間のゴールがあったとすると、仕様を決定するためには、仕様が権限者に承認される必要があり、承認を得るためには仕様書が完成してレビューが終了している必要がある。という具合に一つ一つ遡って必要な作業を探していきます。

  こすることで、スタートから順番に作業を組み立てることで発生しがちな、タスクの見落とし(プロジェクトにとっては致命的になる場合があります)を少なくすることが可能になるわけです。




う書くと単純なようですが、実はタスク抽出に多くの機能が存在する、非常にパワフルなツールなのです。

  実はタスクを選ぶという行為は、プロジェクトジェクトの方針を決めることとイクォールな作業になります。
  例えば、業務上必要なあるシステムを構築仕様とするとき、スクラッチでえ開発するのか、パッケージを導入するのかでプロジェクトの性質そのものが大きく異なってきます。

  当初開発案件としてスタートしたプロジェクトであっても、プロジェクト現場での分析の結果覆される可能性もあります。まぁこれは極端な例ですが。




の時PMがセッションをリードするのではなく、参加するメンバー自ら考えるようにサポートするようにします。

  こうすることで、メンバーがプロジェクトに積極的に参加する雰囲気を作り出し、しかも全員で議論の過程を共有することで、十分な納得を得ることができます。

  もし、タスク抽出作業に参加できないメンバーがいたとしても、タスク抽出の過程自体がネットワーク図として記録にのこるので、説明は容易です。もちろん、プロジェクトオーナーなどの上位管理者に対してもしかりです。

  タスク抽出の詳細については、こちらをご参照ください。

   
https://www.facebook.com/note.php?note_id=209142372483304




回は、2つ目の課題に対する対策を考えます。