エンジニアと出世

全く参考にならないと思うのだが、自分はメンバのどこを評価して職位を引き上げているかというところを書こうと思う。なぜ、参考にならないかというと、自分はこのエントリの読み手のマネージャではないからだ。過去に見聞きした範囲や世間話などで知っている限りでは、マネージャも評価の付け方（エンジニア個人のレーティング、担当配下の割り当てなど）はガイドされても、エンジニアの評価のした方は丸投げされているところもある。運用と言えば運用。自分からすれば、その運用がひどいところも箸にも棒にも引っかからない運用もあるということだ。とは言え、自分の運用が良いとは思わないエンジニアもいるだろう。

出世＝収益寄与

 エンジニアで出世するのであれば、端的には組織の中でビジネスを引っ張るロールにつくことができるかどうか、と考えている。

担当のエンジニアよりは、プロジェクトマネージャ（単体のビジネスで収益を上げる）、マネージャ（担当ビジネスで収益を上げる）というようにロールを上げることが出世だろうと思う。その先もあるがここでは端折る。

組織の活動で収益を増やしたのだから、ロールの中でのレーティングを上げろ、と言い換えても良い。

ロールを上がる条件

エンジニアからいきなりマネージャのラインは考えにくい。少なくとも小さなプロジェクトであってもプレイングマネジャで実績を重ねているからマネージャに引っ張るのだろうし、自分も引っ張るなら、任せるビジネス領域を任せてもやれると見切れるか、フォローのポイントを押さえて（要は、チャレンジされるけど支援する前提）なければ任せられない。

プロジェクトマネージャもそうだが、やれると見切れているからアサイメントするわけで、そこはマネージャもプロジェクトマネージャも同じである。条件をつければやれそうだと思えばアサイメントするがそれは誰がフォローするか体制を作れれば、である。

つまり、アサイメントする側の考えとしては完璧な人材を求めているのではなく、できると思えるかどうか（ただし、マネージャは組織のロールのため空き席を作れないとアサイメントできない）という観点で決める。

マネージャに比べたら、プロジェクトマネージャなら案件があれば機会は遥かに多い。

実はそれほど競争相手は多くない

なり手が少ないから、である。プロジェクトマネージャやマネージャは大変だ、と思うエンジニアが多いので避ける。案件はあるのにプロマネがいないのである。

やってもいないのに、避けるなんて勿体無い。実はものすごく向いているのかもしれないのだから。

ある程度の経験を積めば、リーダ役は必ず付いて回る。そういう構造にしないとビジネスにならない。だったら、小さなプロジェクトから始めると良い。

準備は素振りから

リーダになったら、プロジェクトマネージャになったつもりで、現場で素振りすることを意識する。エンジニアがプロジェクトマネージャにアサインされてからどうしようか考えていては手遅れだ。

実務のシステム開発はできたとしてもそればかりじゃない。数字の予実管理もあるし、チーム運営もある。チームの協力がなければ何も実現できない。

どんなチームでプロジェクトをやりたいか、それを現場で素振りをしておく。

ビジネスへの寄与（収益）を意識する

何もこれをやって利益が増えた的な感じで捉えるとコストカットや労務時間のセーブに走りかねない。狙うのはそこじゃない。

エンジニアとして興味のある手法に入れ替えて生産性をあげられたから、その結果収益に貢献したとか、エンジニアの業務プロセスを変えて手戻りを無くしたから初期の工数は掛かったがトータルでは類似プロジェクトより品質がよく、顧客満足も高くなったなどとToDoとビジネス寄与を結ぶ習慣をつけると良い。  

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド