プロジェクトで失敗しないチームの要素
システム開発のプロジェクトで割と結果を出せていたのはある意味不思議と言えば不思議なのかもしれない。
世の中では、プロジェクト自体かなりの割合で失敗しているとか（古いPMIのNetwork誌だったか）とかウォーターフォールの失敗の割合とかアジャイルのプロジェクトの失敗とかをときどき見かける。
ご想像のとおり金額で言えば大規模なプロジェクトではないし、小さい方かもしれない。ただ、プロジェクトの規模が小さければ、案件数は大規模に比べて数桁も多い。規模の小さいプロジェクトは元々のQCDのリソースのサイズは小さいので1つ間違えると致命的になるのは想像に難くないだろう。
どのプロジェクトでも、その中で特に立て直しのプロジェクトに巻き込まれたり、召喚された場合、何をやっていたかと言う言えば、色々と思いつくことやらなければならないことをあれこれとやっていたのであるが、思いつくことを書き出してみるとこんなことをやっていた（はず）。
- プロジェクト目的の刷り込み
- プロジェクトのカルチャー作り
- 自律したマインド作り
- 個々のエンジニアのスキルの理解
- エンジニア同士で言い合える関係
１は、プロジェクトの仕事のゴールである。これを曖昧にしておく理由はない。終わるまで続ける。
２はプロマネの考え方、例えば項番3以降を実現できるチームをプロマネが作りたいと思っているから、それを具現化できるチームの文化を作ることである。
3は、プロマネが指示するは、プロジェクトの目的の設定、向かう方向、進むスピードであって、エンジニアへの箸の上げ下げではない。であるから、それに少なくとも理解してもらえるためのマインドをチームとして持たなければならない。
4はプロジェクトであるからプロジェクト目的の達成に必要なチームとしてのスキルセットがあるはずで（これについては何度もこのブログで取り上げている）、個々に違うスキルとスキルレベルを持ったエンジニアを招集している。それが前提になければおかしい。その前提を理解し、エンジニアひとり一人違うバリューを持っていることを受け止められるチーム作りを必要とする。これがないとただ経験の長いエンジニアがろくに成果を出せないのに若手エンジニアにマウントしたり、若手エンジニアが忖度してしまいかねない。そんなのは求めていない。ここに違いがあることを受け止め、相互に尊敬がなければならない。
5はプロジェクトチームは4を前提として1を目指すのだから、それぞれのスキルやレベルを根底に、ロールの役割を果たさなければならない。そのミッションを履行するためには、つまらないと思ったことでも言える関係でなければならないし、他のメンバの視点は自分にないものだとして、ニュートラルに傾聴する心根を持ち合わせていなければならない。決めつけや思い込みをなくすための1つの方法でもある。
この他に当たり前のようにプロセスデザインやプロジェクトマネジメントなど色々とするのであるが、それもやるし、そうした成果に直接結びつくことと並行してチーム作りをしていると案外とプロジェクトは失敗しない。
