プロジェクトの目標とプロセスと私


ポジショントーク
自分は、プロジェクトマネージャになる前から、プロジェクトで人を動かすとき、プロセスがキーであると考えている。だから、無秩序なプロジェクトに関わった途端、とても違和感を感じる。プロジェクトは人の寄せ集めであり、そのときどきによりその人たちがプロジェクトの目標を達成するためのコンピテンシを有しているかはバラバラであることを基本とする。だからこそ、プロジェクトの目標であるdeliverablesの作業品質を確保するためにプロセスが必要なのである。

プロジェクトの目標であるdeliverablesの必要な作業品質を確保したい

エンジニアの技量は様々だ

deliverablesの品質を担保するためにプロジェクトのプロセスを導入する

必要な規律を導入する


プロジェクトもさまざま
プロジェクトに関わることが多くなると、最小限の規律でキャリーしているプロジェクトもあるし、まったくの無法地帯のプロジェクトもある一方、管理のための管理の作業が主な作業にすり替わってしまっているプロジェクトもある。最小限の規律でプロジェクトをキャリーしているプロジェクトマネージャは、プロジェクトのプロセスを理解し、実際のイメージを掴んでいるから“最小限”に数多のプロセスをテラーリングできているのである。
アナーキーなプロジェクトはプロジェクトマネージャが自ら行っているはずのプロジェクト管理手法やシステム開発方法論を知らない、若しくは、理解していないために思いつきで対処しており、そこに本来のプロジェクトマネージメントは存在しない。
プロジェクトをマネージするために、必要な最低限の段取りをプロセスとして規律化し、運用することこそ、本質なのである。


プロセスが目標と入れ替わる
なら、deliverablesを達成するためにプロジェクトに規律を導入後、プロセスが目標に変わってしまうのはなぜだろうか。

プロジェクトの目標であるdeliverablesの必要な作業品質を確保したい

エンジニアの技量は様々だ

deliverablesの品質を担保するためにプロジェクトのプロセスを導入する

必要な規律を導入する

規律を管理することに“いつの間にか”目標がすり替わる?

それは、規律のためにチームに作らせる進捗報告や管理表などの資料だけを見るようになるからだ。プロジェクトはチームがいる現場にあるのであって、資料には、すべては存在しない。チームが資料作成のために避ける時間は限られており、資料には一部しか表現されない。対面で聞かれれば深刻な内容も資料では当たり障りのないようにバイアスが掛かってレポートされる。対面なら、その表情や実際に口頭で選ばれる言葉や表情から違和感を感じ、聞き出すことができるのに。
人は自分に都合の良い、耳障りの良いレポートだけを聞きたいものだ。もし、不都合な情報が上がってきたとしてもレポートされた資料に対して指示を返す方が、直接面と向かって指示するより何倍も楽をすることができる。そうなると、問題のある現場ではなく、机上で資料のみでプロジェクトを何とかしようと考え始めるのである。
問題は現場にいるチームの前で起きているのにも関わらず。


プロジェクトマネージャが忘れてはいけないこと
プロジェクトマネージャにとって、チームはプロジェクトそのものである。だからこそ、必要な規律でチームを運営し、常に無駄がないかを見直す必要があることを忘れてはいけない。無駄な作業をチームにさせるのは、プロジェクトマネージャが自ら首を絞めるようなものなのだ。





  • 道具室(アプリとか)
  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します)
  • 視聴覚室
  • 調達室