読者です 読者をやめる 読者になる 読者になる

IT業界で気づいたことをこっそり書くブログ

何とかする系アプリエンジニア(SE)が、日々気づいたことの中で、役に立ちそうなことを綴っていきます(受託→ベンチャー→フリー→大企業、ベンチャー)

外罰型とプロジェクト

前と同じ話題を別の切り口から

 

P-F Studyという心理学のテストがある

問題、課題、面倒事、バグやミスなど、フラストレーションが発生した時

その責任の所在をどこに求めるかという分類だ

 

外罰型 ・・・ 他人が悪い

内罰型 ・・・ 自分が悪い

無罰型 ・・・ 誰も悪くない

 

本来はもう1軸合わせて11種に分類されるが、ITプロジェクトにおいて重要なのは上記3つだ

 

結論から言うと、マネージャーを除いた場合、外罰型は不要であり今すぐ解雇するべきだ

本人ももっと別の職業の方が幸せになれるだろう

プロジェクトの進捗を遅らせ、品質を落とし、コストを上げ、メンバーの心労を増やす

いいことはない

 

その理由を(何となく分かるだろうが)具体的に書くとこうなる

 

・問題が発生する → 自分以外が悪いとのたまう → 自己改善しない

・自分がミスをする → 自分のミスだと認めない → 誰かがその人のミスだと確定させる必要が出てくる

・他者がミスをする → 叱責に終始し改善に繋げようとしない

結果として内罰型のタスクが1人あたり2割〜5割増えるだろう

 

内罰型が居なかったらどうなるか?

外罰型+外罰型だと、責任の押し付け合いになりプロジェクトが前進しない

外罰型+内罰型だと、「仕方がない」になるのでこれも解決しない

 

回避策としては、指揮系統と責任の所在の明確化であるが、ITプロジェクトは往々にして上下関係が不明確だ

今から考えてみればチケット駆動型開発はそういった理由でも重宝されていたのかもしれない

 

やや蛇足になるが

外罰型がどのくらい居るかという問いは難しいが 、過半数は居ないが、少なくはないというイメージで概ね間違っていないと思う

多から少なかれどこにでも居て、少しずつプロジェクトを停滞させていく原因になっているのは業界人なら記憶にあるのではないだろうか

見方を変えれば、いかにそういったメンバーを扱うか、あるいは除外してしまうかというのがPMのスキルの一つにもなるだろう

(似たようなことがPMBOKに書かれているかもしれないが、私はまだ全部読めていないので分からない)

 

 

 

P-Fスタディの11分類については色んな論文に書いているが

今回この論文を参考にした


甲南女子大学学術情報リポジトリ