私は、プロジェクトマネージャーになりたいと思ったことが一度もありません。
機械学習エンジニアとして今の会社に入ったのですが、最初に関わった案件が、顧客はもういるのに何をやるかは誰も決めていないという状態でした。放っておけば燃えるのが明らかだったので、心配性な性格もあって、勝手にゴール設定を作り、検証項目を整理し始めました。結果として、最初の数か月はほとんどパワーポイントを触っていました。
そこから何となく、そういう役回りが回ってくるようになりました。任命された記憶はありません。
この記事は、体系立ったキャリアプランの話ではなく、エンジニアからそちら側に移ると何が変わるのかという話です。似たような入り方をして戸惑っている人には、多少参考になるかもしれません。
目次
1. なりたくてなる人ばかりではない
プロジェクトマネージャーという役割は、気づいたら任されていた、という入り方をする人が多い職種だと思います。エンジニアとして数年やって、ある日から進捗管理と調整をやることになる。
私の場合もそうでした。そして最初は、正直なところ嫌でした。
エンジニアとして入ったのに資料ばかり作っていることに、これでいいのかという気持ちがありました。技術者としての価値が落ちていくような感覚もありました。周りが実装している間、自分は会議に出ている。この構図に慣れるのに時間がかかりました。
考え方が変わったのは、あの最初の案件が、当初の状態からすればかなり穏当に終わったときです。プチ炎上くらいはしたのですが、放っておいたときに起きたであろう事態とは比べものになりませんでした。
そのときに、自分がやった整理には意味があったのだと思えました。この経験がその後の自分にかなり効いているのですが、その話は生きる意味に悩む人に伝えたいことの方に書いています。
2. 最初に失うのは、自分で手を動かす時間
移行して最初に直面するのは、まとまった集中時間がなくなることです。
エンジニアの仕事は、数時間まとめて集中できるかどうかで効率がまったく違います。マネジメント側の一日は、会議と問い合わせで細切れになります。30分ずつの隙間が並んでいるような状態で、そこに実装を差し込もうとしても進みません。
私は最初、これを根性でどうにかしようとしました。夜に実装をやろうとして、単に稼働時間が伸びただけでした。
今は割り切っていて、自分が実装を持つ場合は「細切れでもできる作業」に限定しています。設計の検討や調査は隙間でもできますが、まとまった実装は持たない。持つと、自分がボトルネックになってチーム全体を止めます。
ここは、エンジニアとしての自己像を手放す必要がある部分でもありました。「自分がいちばん書ける」という状態を維持しようとすると、どちらも中途半端になります。
3. 技術力は捨てなくていい
一方で、技術から完全に離れるのは違うと思っています。少なくとも、私がやっているような受託の現場では成立しません。
理由は単純で、技術的に無理な計画を止められなくなるからです。
顧客から「この機能も入れてほしい」と言われたときに、それがどれくらいの重さなのかを自分で判断できないと、持ち帰って確認するしかありません。その場で「それは今回のスコープでは厳しいです」と言えるかどうかで、案件の形はかなり変わります。
特に機械学習の案件では、そもそも技術的にできることとできないことの線引きが顧客に伝わっていないことが多いです。この線引きを説明できるのは、中身が分かっている人だけです。
なので私は、実装の主力からは外れましたが、使っている技術については追い続けるようにしています。全部を深く知る必要はなく、何ができて何ができないかの当たりがつく程度で判断はかなり変わります。
採用面接で毎回「機械学習って何ですか」と聞いているのも、この線引きが本人の中でどれだけはっきりしているかを見たいからです。詳しくは面接で毎回「機械学習って何ですか」と聞いているに書きました。
4. 評価のされ方が変わる
これは移ってしばらく経ってから気づいたことですが、成果の見え方がまったく変わります。
エンジニアのときは、自分が書いたものが動けば成果でした。分かりやすいです。
マネジメント側の成果は、起きなかったことに宿ります。炎上しなかった、手戻りが発生しなかった、メンバーが潰れなかった。どれも起きていないので、外からは見えません。うまくやるほど「特に何もなかった案件」に見えます。
逆に、失敗は非常に目立ちます。遅れれば分かりますし、揉めれば伝わります。
この非対称性は、最初はかなりしんどく感じました。今は、そういうものだと思っています。ただ、自分が部下を評価する側になってからは、この見えにくい部分を意識して見るようにしています。何も起きていないチームは、たまたま平和なのではなく、誰かが手を打っている場合があります。
部下を見る側になってから考えたことは降格していくのは、いつも『自分で決められない人』だったにも書きました。
5. 資格と勉強について正直なところ
キャリアの記事だとPMPのような資格を勧める流れになりがちですが、正直に書いておくと、私は取っていません。
理由は、私のいる規模の会社で、資格があることで変わる場面が実際にはなかったからです。数十人規模の受託開発では、顧客が資格の有無を気にすることはまずありませんし、社内の評価制度にも紐づいていません。
ただ、これは「不要だ」という主張ではありません。大手のSIerや、公共系の案件を扱う会社では、提案時に資格保有者の人数が要件になることがあると聞きます。そういう環境なら、話はまったく変わります。自分がいる場所で効くかどうかで判断するのが妥当だと思います。
体系立った知識そのものには価値があると思っていて、私も書籍で一通りは押さえました。ただ、実際に効いたのは資格の勉強より、自分の案件の振り返りを記録に残すことでした。見積もりがどれだけ外れたか、問題に気づくのが何日遅れたか。これを続けると、次に似た場面が来たときに具体的に判断できます。この記録の取り方はITプロジェクトマネジメントの基本知識と実践方法に書きました。
6. まとめ
エンジニアからプロジェクトマネージャー側に移って変わったことを整理すると、こうなります。
- なりたくてなったわけではない。 必要に迫られて始めた人は、たぶん少なくない。
- まとまった集中時間は失われる。 実装を持つなら細切れでできる作業に限定しないと、自分がボトルネックになる。
- 技術は追い続ける必要がある。 できないことを「できない」と言えるかどうかで案件の形が変わる。
- 成果は「起きなかったこと」に宿る。 見えにくいので、評価される側としてはしんどい。
- 資格が効くかどうかは環境次第。 私は取っていないが、それは私の環境ではそうだったというだけ。
最初から全部揃っている人はいないので、今の自分に足りない部分から順に手をつけるのがいいと思います。私自身、まだ埋まっていない部分がいくつもあります。
ここで挙げた要素の中身は、それぞれ別の記事で扱っています。管理手法の全体像はITプロジェクトマネジメントの基礎とその重要性、リスクの扱いはプロジェクトのリスク管理：失敗を防ぐための戦略、予算はプロジェクトの予算管理の重要性を参照してください。IT以外の道を考えて結局戻ってきた経緯はIT以外の仕事を考えて、結局ITに戻ってきた話にあります。