こんにちは。やまさんです！
システム開発プロジェクトの
主なリーダー職は
大きく２つあります。
- プロジェクトマネージャー（PM）
- プロジェクトリーダー（PL）
結局のところ、リーダー職は
プロジェクトを成功を導くために
活動しますが、
プロジェクトの成功の基準って
考えたことありますか？
プロジェクトを成功させるために
頑張っているのに
プロジェクトがどうなったら
成功といえるのか知らないのは
ゴールを知らずにマラソンを
走るようなもので
とても危険です^^;
ということで今日は
そもそもプロジェクトの成功って
結局なんなの？
PMとPLの役割ってどう違うの？
という話をしてみたいと思います。
プロジェクトの成功とは何なのか？ プロジェクトで守らないといけないもの
結論から言うと、システム開発でいう
プロジェクトの成功とは
QCDの達成です。
QCDは有名な考え方ですが、
念のため補足しておくと、
- Quality（品質）
- Cost（コスト）
- Delivery（納期）
QCDの達成とは
品質、コスト、納期が決められた水準を
満たしていることをさします。
PM、PLを代表する
リーダーの役割を持ったのSEは
プロジェクトを成功へ導くのが仕事です。
なので、PM、PLはQCDを守ることに
全力をつくします。
ここで言う、Quality（品質）はバグの数だけでなくシステムで何をするかも含めます。
設計書通りに作っていも、お客さんが満足しない場合、設計が間違っているということで仕様変更が発生することがあります。
仕様変更はQuality（品質）の達成基準を変えてしまうのでプロジェクトの成功を遠ざける大きな要因となります。
プロジェクトを成功に導くPMとPLの役目
PMとPLはプロジェクトを
成功させるため、
つまり、QCDを守るために
全力をつくします。
ただ、役割は違うんですよね。
ここからはPMとPLの役割を
紹介していきます。
PMの役割
PMの役割は大きく２つです。
- QCDの基準をお客さんと合意すること。
- プロジェクト進行中にはQCDが守られているか管理すること
C（コスト）とD（納期）は
分かりやすいですね。
プロジェクト（システム）の価格と
開発するシステムの納期を
お客さんと合意します。
納期はシステムのリリース日を
合意することもありますね。
Q（品質）は概要レベルで合意します。
「社員管理システムを提供します」
など、
こんな感じですね。
想像してみると、分かりやすいかと
思うのですが、
などのレベルでOK/NGを
PMやお客さんの経営層レベルで
判断するのは難しいですよね^^;
お客さんの経営層もこんな
細かいところまで把握できないです^^;
なので、
そういった細かい部分を把握したり
管理するのはPLの役割となります。
こんな感じで書くと、
PMはラクそうな仕事な気がしますが、
基本的にC（コスト）とD（納期）は
お客さんから小さく、短くするように
たいてい求められます。
投入できる人の数や期間が
決まる調整を行うので
とても重要な役割を担っています。
ここで劣勢になると、
厳しいプロジェクトになるため
難しいです…
ここをいかに確保してくるかが
PMの役割であり、能力の１つです。
PLの役割
PLの役割は大きく２つです。
- PLが合意したQCDの詳細な基準を検討する
- QCDが守られるようにプロジェクトを運営する
PLはPMが合意してきた
大枠のQ（品質）C（コスト）D（納期）の
細かなところをつめていきます。
PMが確保してきた
リソース（人員や開発期間）を
どう活用していくか方針を決めいく
イメージですね。
PLが担当する仕事の一例としては
- 提供するシステムが持つべき機能の検討
- チーム間の役割分担
- 各開発工程の細かなマイルストーンの決定
など、たくさんあります。
開発途中で出てきた問題の解決も
PLの役割です。
問題を分析し、解決策の立案、実行まで
行う必要があるため、
担当するシステムの知識や
場合によっては
お客さんの業務フローに関する
知識も求められます。
なので、プログラマーなどと比べ
PLは育成に時間がかかりますし
交代させることも難しいです。
さらにプロジェクトはたくさん問題が
発生します。
プロジェクト＝問題解決の活動と
言っていいぐらい問題だらけです^^;
なので、問題解決のスキルは
PLにとって必携といえるでしょう。
意外に知られていないかもしれませんが、PMに必要とされる能力は汎用的なマネジメントスキルなので理論上は交代が可能です。ただ、実際のIT業界では優秀なスキルを持ったPMはあまりいないので交代したくても交代できないのが現実です。
まとめ
この記事ではこんなことをお話しました。
- プロジェクトの成功とはQCDを守ること
- PMはお客さんとQCDを合意してプロジェクトを管理することが役割
- PLはQCDを満たすためにプロジェクトを運営していくことが役割
ただ、Q（品質）は数字で表現することが
難しいです。
なので、お客さんとしっかりすり合わせを
しておく必要があります。
実は炎上プロジェクトはQ（品質）を
お客さんとうまく合意できていないことが
原因で発生していることが多いんですよね。
Q（品質）をお客さんと
しっかり合意できていないと
この記事内でも紹介しましたが、
仕様変更が発生してしまいます^^;
さらに、C(コスト)とD（納期）の変更は
許されないケースが大半…
結果、Q（品質）水準は上がったのに
C(コスト)とD（納期）が下がらないので
プロジェクトは炎上します。
デスマーチというやつですね^^;
仕様変更が多発する理由は
以下の記事で紹介していますので
ぜひ読んでみてくださいね。
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
