システム開発のイニシアチブは誰がとるべきなのか？
徒然に書いてみる。
ユーザなのか、情シスなのか？
これは、プロジェクトの性質にもよりますが、事業会社なんかだと、情シスはほぼいるだけで、ユーザが推進して開発ベンダーとやり取りしているケースなんかも見かけたりします。
取引先の情シスとやり取りしても全然話が通じなくて「基本任せているので連絡してみないとわかりません」って正直すぎませんか？
ただ、これは契約形態にもよりますがうまくなくて、本来的には情シスがリーディングやマネジメントをある程度の技術的な素養をもってしっかりやっていかないと、まあうまくいかないです。
ユーザ側の窓口は明確にしておくべき
そのうえで、ユーザ側の役割は明確にしてあげることは大事。役割に沿って決めるべきところを決めて、確認すべきところを確認してもらえるような体制づくりがプロジェクト成功の肝になります。
プロジェクトマネージャー（PM）とプロジェクトリーダーの違い（PL）を整理してみる
これも割と大事なポイントでして。要は、リーディングする人と責任を取る人は別だってことですね。
指導や監督をする人と、成果を上げるための責任を持つ人は別、と言い換えた方がよいかも。
しかしまあ、弊社のような中小だとそんな豪華な布陣は取れませんで、
・PM…ぴょん吉
・PL…ぴょん吉
・メンバー…ぴょん吉
なんてこともあるわけです。いつでも自分が代打になるくらいの気持ちでなければ、中小のマネージャーなんてやってられませんからね。
極論を言うと、役割を果たせて成果を出せて契約にあった行為をしていればなんでもよい
ちなみに、あまり四角四面に行き過ぎるとうまくいかないよなあというのも考え方として最近思っています。
ベンダーとの区分けはきちんとしないといけないですけどね。
先日もご紹介しましたが、システム開発のあるあるはここに。
しかし、ユーザ側がちゃんと問題認識できなくて、情シスがユーザの意向に唯々諾々従っちゃって失敗するケース、多いんだこれが。
そんなこんなでシステム開発についての書籍をご紹介。
こちらも改めてご紹介。上流工程大切ですよね。Unlimitedで読めます（2021年12月14日現在）。
しかしプロジェクトマネジメントが自分自身うまくやれているかというと、そんなこともなく、日々反省ばかりであります。。。
これは、「数多くのIT現場への取材から導き出されたノウハウと、第一線の専門家らによる解説記事」だそう。第一章で「ダメPM」の例が出てくるのは、日経あるあるですねえ。
おしまい。
この記事が気に入ったらサポートをしてみませんか？