メンバーのあなたこそ、プロジェクトマネジメントを学ぼう

プロジェクトマネジメントは、PMだけが学ぶものだと思っていませんか？

それはもったいない。
メンバーのあなたこそ、学ぶべきです。

統計によると、ITプロジェクトの成功率は31% 。

ということは、エンジニアはほぼ確実にうまく行っていないプロジェクトに配属されることになる。

その時プロジェクトマネジメントに関する知識がないとどうなるか。

そういう現場では大抵メンバーに何らかの負荷がかかり、タスクがうまくこなせなかったりします。

それは本来マネジメントやプロセスに問題があるのであって、本人の資質や能力の問題ではない(※1)のに「自分が悪いんだ」と自分を責めてしまうことになります。

※1）仮にあなたの技術力が足りなくてタスクが遂行できなかったとしても、そのような人員をアサインしたマネージャーに原因があります。

しかし、プロジェクトマネジメントの正解をあらかじめ知っておくと、自責と他責の境界が分かって自分を守ることができるようになります。

というわけで、私もPMになる予定はありませんが、以下の本を読んでみたので刺さった部分の引用と感想を書きます。

交渉

自分もまぁまぁ丸投げされていました。しかも、範囲外のことをやらされていると認識できていませんでした。
高圧的に重箱の隅をつついてくるお客さんの盾になってくれなかったり。
今後は、やるなら銭もらいます💰

タスクマネジメント

はい、丸投げされていました。離脱しました。

無理、分からない、見通しが持てないってアラート上げまくったのに、「ゆっくりできるようになればいいですよ」としか言ってくれなかったマネージャーがいました。

開発手法の選択

なんと、4つの条件を1つも満たさないスクラム開発にいたことがありました。
まぁぁぁぁぁぁぁぁ苦しかった。
アジャイルは絶対に良いとされてる風潮があるけど、日本企業の特性やシステムの条件を鑑みて、本当にアジャイルでできるのか冷静に判断すべきです。

全体を通して

タスクマネジメント、要件定義、設計、デザインのあたりを読んで気づいたこと。

エンジニアの仕事を領域/工程/役割で分類すると、私はインフラ/運用/メンバーのことが多いです。

ある時、インフラ/構築/(メンバー)と聞いて案件に入ってみたら、全領域/全工程/全役割できるよね？みたいな現場だったことがありました。

前述の、4つの条件を1つも満たさないスクラム開発の現場です。

ちぬ。

周りが侃々諤々(かんかんがくがく)やってても自分は何もできない。

しかも、フォローしてもらえないどころか「特定の分野しかやりたがらない人はいらない」とか「言われたことだけをやっていたら作業者からは抜け出せない」みたいな発言もされました。

当時の私は真に受けてしまっていましたが、そもそも明らかなミスマッチが起きていたので、できなくて当然だしそれで自分を責める必要はなかった、ということに、この本を読んでようやく気付いたのでした。

まぁ、どうやら2次請けと3次請けの間に認識齟齬があってこんなことになってしまったようでしたが、私からしたらたまりません。

というわけで、自分の身を守るためにもメンバーこそプロジェクトマネジメントを勉強しようねという話でした。