メンバーのあなたこそ、プロジェクトマネジメントを学ぼう
プロジェクトマネジメントは、PMだけが学ぶものだと思っていませんか？
それはもったいない。
メンバーのあなたこそ、学ぶべきです。
統計によると、ITプロジェクトの成功率は31% 。
ということは、エンジニアはほぼ確実にうまく行っていないプロジェクトに配属されることになる。
その時プロジェクトマネジメントに関する知識がないとどうなるか。
そういう現場では大抵メンバーに何らかの負荷がかかり、タスクがうまくこなせなかったりします。
それは本来マネジメントやプロセスに問題があるのであって、本人の資質や能力の問題ではない(※1)のに「自分が悪いんだ」と自分を責めてしまうことになります。
※1）仮にあなたの技術力が足りなくてタスクが遂行できなかったとしても、そのような人員をアサインしたマネージャーに原因があります。
しかし、プロジェクトマネジメントの正解をあらかじめ知っておくと、自責と他責の境界が分かって自分を守ることができるようになります。
というわけで、私もPMになる予定はありませんが、以下の本を読んでみたので刺さった部分の引用と感想を書きます。
交渉
本来はプロジェクトマネージャーがやるべき交渉や調整をメンバーに丸投げして全体の進行を阻害する結果になったり
自分もまぁまぁ丸投げされていました。しかも、範囲外のことをやらされていると認識できていませんでした。
高圧的に重箱の隅をつついてくるお客さんの盾になってくれなかったり。
今後は、やるなら銭もらいます💰
タスクマネジメント
単にタスクを割り振ったり進捗を「管理」したりするだけでなく、プロジェクトの目的達成のためにタスクを采配することが本来のタスクマネジメントです。
権威を振りかざして「仕事なんだからやれよ」というスタンスでプロジェクトメンバーに負荷の高いタスクを丸投げし、その進捗や結果について厳しい判断を下し続ければ、メンバーの離職を招きプロジェクトにとって致命的な状況を招く可能性があります。
はい、丸投げされていました。離脱しました。
タスクの担当者個人の中で解決が難しい課題などをプロジェクトマネージャーが早めに検知して対策を打つことがプロジェクト全体の効率性につながっていくのです。
無理、分からない、見通しが持てないってアラート上げまくったのに、「ゆっくりできるようになればいいですよ」としか言ってくれなかったマネージャーがいました。
開発手法の選択
スクラム開発は実際のプロダクトを確認しながら開発を行うことができますが、4つの重要な前提条件を満たさない場合はウォーターフォール開発よりもプロジェクトが難航することがあります。
1.素早い意思決定
2.プロジェクトメンバーの要求レベルが高い
3.外部システムやサブシステムとのシステム連携がない
4.プロジェクト全体の予算やスケジュールを調整できる
なんと、4つの条件を1つも満たさないスクラム開発にいたことがありました。
まぁぁぁぁぁぁぁぁ苦しかった。
アジャイルは絶対に良いとされてる風潮があるけど、日本企業の特性やシステムの条件を鑑みて、本当にアジャイルでできるのか冷静に判断すべきです。
全体を通して
タスクマネジメント、要件定義、設計、デザインのあたりを読んで気づいたこと。
エンジニアの仕事を領域/工程/役割で分類すると、私はインフラ/運用/メンバーのことが多いです。
ある時、インフラ/構築/(メンバー)と聞いて案件に入ってみたら、全領域/全工程/全役割できるよね？みたいな現場だったことがありました。
前述の、4つの条件を1つも満たさないスクラム開発の現場です。
ちぬ。
周りが侃々諤々(かんかんがくがく)やってても自分は何もできない。
しかも、フォローしてもらえないどころか「特定の分野しかやりたがらない人はいらない」とか「言われたことだけをやっていたら作業者からは抜け出せない」みたいな発言もされました。
当時の私は真に受けてしまっていましたが、そもそも明らかなミスマッチが起きていたので、できなくて当然だしそれで自分を責める必要はなかった、ということに、この本を読んでようやく気付いたのでした。
まぁ、どうやら2次請けと3次請けの間に認識齟齬があってこんなことになってしまったようでしたが、私からしたらたまりません。
というわけで、自分の身を守るためにもメンバーこそプロジェクトマネジメントを勉強しようねという話でした。
