プロジェクトマネジメントが人気がない３つの理由
プロセスデザインエージェントの芝本秀徳です。
コンサルティング先、研修、セミナーなどで、よくお話するのが「すべてのソフトウェアエンジニアはプロジェクトマネジャーでなければならない」ということです。それはなぜなのか、というのが今日のテーマです。
■ なぜプロジェクトマネジメントは人気がないのか？
すべての知識労働者にはプロジェクトマネジメントは必要だし、プロジェクトマネジメントほど、仕事に直結して役に立つ知識も少ない。特にソフトウェアエンジニアは、仕事の対象であるソフトウェアというものの性質上、プロジェクトマネジメントの必要性は、他の業種より高いはずだ。しかし、プロジェクトマネジメントはさっぱり人気がないのはなぜだろう？
新しい言語や開発環境などのソフトウェア構築の習得には熱心なソフトウェアエンジニアも、プロジェクトマネジメントを学ぶ人は多くない。むしろまれといってもいいかもしれない。１０人に１人も学ばないのではないだろうか。
なにしろ、ビジネス書を書くときにも「プロジェクトマネジメントをテーマにしても売れない」と出版社に断言されるくらいだ。自己啓発書よりは役に立つはずなのに、市場が小さい（＝求めている人が少ない）のだ。
ソフトウェアエンジニアがプロジェクトマネジメント技術を学ばない理由の一つには、「学ばなくても仕事がある」「とりあえず仕事が成立している」ことが大きい。言語、開発環境などのソフトウェア技術は、手に入れなければ仕事がもらえない。しかし、プロジェクトマネジメント技術がなくても開発者としての仕事はあるし、プロジェクトもとりあえず「なんとか終わらせる」ことはできる。
そして、この「とりあえず仕事が成立している」状況、これこそが、多くのデスマーチを生み出している大きな要因となっている。
プロジェクトマネジメントを学ぶエンジニアが一人増えれば、これから発生しうる多くのデスマーチを救うことができるし、新たにプロジェクトマネジメントを学ぶ機会を持つ人が増える。その理由はあとで述べるけれど、いまソフトウェアエンジニアとして仕事をしている人たちに、プロジェクトマネジメントを学ぶべき理由を示すことで、一人でも多くの人のきっかけとなればと思う。
■ 理由その１：ソフトウェアは外からマネジメントしにくい
ソフトウェア開発は、他のエンジニアリング分野と比較して、一人ひとりの個人に任せられる範囲が大きい。自分の担当モジュールについては、仕様を決め、設計をし、コーディング、テストまでやる。つまり、設計・製造・評価を一人でやるのだ。
これはソフトウェアが純粋に「知識」に関わる仕事だからだ。ソフトウェアの材料となる知識は、エンジニアの頭の中にしかない。知識にはカタチがない。知識そのものも、製造プロセスも、外からは見えないのだ。ドキュメントにすることで、カタチらしきものを見ることはできても、すべてではない。
目に見えないものをマネジメントすることはむずかしい。ソフトウェアプロジェクトの進捗管理がむずかしい理由はここにある。一人ひとりの裁量が大きく、さらに成果物も製造プロセスも見ることができない。一人ひとりのエンジニアがコントロールしなければならない部分が大きいのだ。
つまり、ソフトウェアエンジニアは少なくとも「担当モジュールプロジェクト」のプロジェクトマネジャーである必要があるということだ。
■ 理由その２：無茶な要求に根拠ある反論ができなければならない
ソフトウェアが持つ「カタチがない」という性質上、外からはマネジメントがしづらい。さらにというか、だからというべきか、ソフトウェアエンジニアリングを知り、かつメンバーのマネジメントもできるというプロジェクトマネジャーは非常に少ない。そのため、エンジニアは無茶な要求にさらされることも多い。
無理解なマネジャーから「要件定義の工数を半分にしろ」「動いているところまででいいから、きょうリリースしろ」「いつまで設計ばっかりやってるんだ」など、エンジニアからすれば狂気としか思えない要求がとんでくる。
エンジニアは概して口下手だ。こういった無茶な要求に反論するすべを持たない。「なんでできないんだ」と言われると黙るしかない。結局「少し無理すればいいか」と要求をのんでしまう。しかし、無茶な要求を呑めば、自分の時間を犠牲にしたり、プロセスを省いたりするしかない。結果としてそれが「デスマーチ」の入り口だったということになる。そして責められるのはエンジニアだ。これはやってられない。
かといって、マネジャーにソフトウェアエンジニアリングを勉強しろ、プロジェクトマネジメントを学べといっても無理な話だ。そんな奇跡を待っていたら、いつまで経っても状況は変わらない。
もっとも手っ取り早く、かつ確実なのは、こういった無茶な要求に対して、「なぜその要求が無茶なのか」「その要求を実現すればどのような影響があるのか」「次善策として何があるのか」を論理的に説明できるようになることだ。
そのためには、プロジェクトというもののメカニズム、プロジェクトマネジメントのセオリー、プロジェクトのタブーなどを、言葉で学ばなければならない。自分とプロジェクトを守るためには理論武装しなければならないのだ。
■ 理由その３：ある日突然、プロジェクトマネジャーに任命される
ソフトウェア開発のプロジェクトマネジャーの多くは、エンジニア上がりだ。ほとんどのプロジェクトマネジャーは、プロジェクトマネジメントについて専門的な教育を受けていない。なぜなら、ある日突然、プロジェクトマネジャーに任命されるからだ。
プロジェクトマネジャーに任命されれば、やらなければならないことが山のようにある。プロジェクトマネジメントなんて学んでいる時間はない。それまでの経験しか、手持ちの武器はないのだ。しかし、その経験はあくまでもエンジニアとしての経験であって、プロジェクトマネジャーとしての経験ではない。
開発メンバーとしての視点と、プロジェクトマネジャーの視点はまったく異なる。極論すれば、メンバーは自分の担当範囲だけ見ていればよい（本当はダメなのだけれど）。しかし、プロジェクトマネジャーは、プロジェクト全体の「品質・コスト・納期」に責任を持たされている。つまり「部分最適から全体最適へ」視点が変わるのだ。
一方で、持っている武器は開発メンバーのときと同じだ。すると「部分最適の武器で、全体最適を目指そう」としてしまう。とにかく納期をせっついたり、プレッシャーをかけたりするしかできないのは、それしか方法を知らないからなのだ。
こうして「プロジェクトマネジメントができないプロジェクトマネジャー」が出来上がる。メンバーからの信頼など望むべくもない。こうしてデスマーチが再生産されていく。
■ メンバーのうちに学んでおく
プロジェクトマネジメントを学ぶには、理論と実践の両輪が必要だ。理論だけ学んでも使えるようにわけではない。理論の実践のあいだには大きな隔たりがある。また、実践だけでも通用しない。自分が経験できるプロジェクトは限られている。多くのプロジェクト経験の蓄積から抽出された理論から学べることは多い。
もっともよいのは、メンバーであるうちにプロジェクトマネジメントについて学んでおくことだ。そして自分が携わっているプロジェクトで「自分ならどうするか？」をつねに自問し、自分なりの答えを持っておく。
そうやって知識の習得と、自問を重ねていれば、ある日突然プロジェクトマネジャーに任命されても、何も恐いことはない。「よし、やってやろう」という気になる。そして、自分のチームのメンバーにもプロジェクトマネジメントを学ぶ機会を与えることができるだろう。
いま負のスパイラルに入っている組織であっても、正のスパイラルに入ることはできる。それはいまあなたがプロジェクトマネジメントを学びはじめるかどうかにかかっている。
週１回、メールマガジンを発行しています
ビジネススキル、プロジェクト管理、チームマネジメントなど、
仕事の役に立つ情報を知りたい方はこちらからご登録ください。