はじめてマネージャになってすることは、一人ひとりのエンジニアのas isを知ることでエンジニアとして高く売れるto beを狙うしくみをつくること

もう、10年は経つような気がしますが初めてマネージャになってしたことは、これからマネージャになる人の一つの参考になるかもしれないので、そのとき何をしたかを、その後何をしたかを共有しておこうかと、ふと、思ったので。

ワタシの場合、マネージャにアサインされた組織は異動してからそれほど経っていなかったんですね。だから、ということもあるんですが、一緒に仕事＝プロジェクトをとおしてメンバがどんな人なりなのか良く知らないでなった背景があります。じゃあ、組織の中で5年、10年と長くいれば一緒に働くメンバを良く知っているかと訊かれると意外と「あれ？あんまりよく知らないかも？」って、気づくんじゃないかと思ったりします。

それは、プロジェクトで一緒に過ごしていてもそれはプロジェクト上のロール上で関わる“一面”しか知らない、ってことなんですね。一方、マネージャとしてメンバこのことを“知りたい”と思うことは全方位的に知りたくなるんですね。そうしたプロジェクトのメンバで知っていることとマネージャで知りたいこととの違いがあることを知っておくことは大事なことの一つです。

知らないなら知りましょう
マネージャになった組織のメンバを良く知らない、と識別したわけですから知らないなら知るためのタスクをすればいいわけです。で、どうしたか。組織はエンタープライズとしての一つの役割を担うので、それぞれに専門性を持っているんですね。で、メンバが持っていると知っている技術領域を横軸に、メンバを縦軸にプロットした一覧を作ります。

で、それを手に持って、メンバと接触の多いプロジェクトマネージャやSEリーダを順にラウンドロビンで聴いて回ります。貴方の得意な技術領域はどれか、一緒にプロジェクトをやったメンバで知っている技術領域は何か、その技術レベルは松竹梅でどのあたりか、を。

プロジェクトマネージャやSEリーダを順に回るとき、Aプロジェクトマネージャにほかのプロジェクトマネージャの技術領域と技術レベルも訊きます。Bプロジェクトマネージャに訊くときに、Aプロジェクトマネージャのことについても聴きます。これで、相互のレベル間の認識のズレがあるかないか、360度の視点で補正を掛けていきます。

プロジェクトマネージャやSEリーダに訊いた後、担当メンバも順にインタビューします。そこで、本人しか知らない得意技を知ることが出来て意外と「そうだったんだー。へー。」ってなることがあったりします。そして、明確なキャリアパスを持っているか、持っていないかも。

エンジニアの価値を高めるアサインを考える
エンジニアのプロジェクトへのアサインは、プロジェクトで必要なスキルセットとロールの数を手持ちのリソースを組み合わせてチーミングするんですね。で、よくありがちなのは、過去の実績と安全性を最優先に判断すると、結果、“いつも同じ顔ぶれ”になっちゃうわけです。それが良いか悪いかと言えば、いつも同じ所掌なのであれば、ワタシ的には良くないことです。

毎年、何か一つでも新しい技術、所掌を経験しないとエンジニアは学びの酸欠になると思っています。少なくともワタシは酸欠になるんです。面倒なことでも難しいことでも何か新しいことを仕事を自己研鑚をとおしてやりたい。それは新しいことを経験することで自分の幅も深さも広げることが出来るからです。

同じことをやっていたら以前よりも早く、正確に、出来て当然だと思っています。でも、それは成熟しただけであって組織の目標にそって振り返れば価値があることかどうかはそれだけで評価をするのか、というところに結び付くのではないかと思います。TQCのように改善を介した習熟度を上げるのもプロセスなりインプット、アウトプットを変化させることが必要で、そこにはただ早く、正確だけではない別のものが含まれていると思うのです。

担当のメンバにインタビューするのは、そうしたアサインを変えていくための希望を訊くことでもあるんですね。

経験が浅いメンバで、開発から試験の工程を数回しか経験していないのであれば、担当する工程を広げることを狙うのか、担当している工程を自立させて担当できるようになることを目標とするのか、とか。

そうしたインタビューを踏まえて、プロジェクトのチームにアサインすることを常に考えておく必要があります。それを意識することが出来るのが先の一覧になるんです。

メンバの技術一覧は公開する
公開しちゃいますね。メンバ限定、ですが。この技術のリーダは、Aさん、とか。サブリーダはBさんとか。メンバのCさんはこのソリューションの経験があるとか。で、適宜、更新していくんですね。

で、毎年、年度初めに公開するんです。そうすることで、プロジェクトマネージャやSEリーダは、だれがどの技術をカバーしているか一目でわかるし、プロジェクトで火急の対応が必要なとき、ワタシに相談しやすくなるんです。

「もし空いていれば、DさんかEさんに○○工程を1ヶ月手伝ってほしいんですが。」

まぁ、週次で事細かくプロジェクトの成り行きは生暖かい目でウォッチしているのでワタシの我慢できる範囲ではこっちからは誘い水を投げませんが、一線を越えるとこっちからお誘いしますね。

コレコレの課題、リソースが足らないでしょ。Dさんならスポットでよければjoinできるよ。

と。

兎に角、一人ひとりのエンジニアのas isを知ることでエンジニアとして高く売れるto beを狙う
もう、エンジニアのマネージャなら、目指すのはコレです。エンジニアは持つ技術を如何に高く買ってもらうか、だと思っています。組織の目標なんて、エンジニアが高く売れるなら、自然と基礎スキルも技術スキルも持っているのだから如何様にもなるものです。また、そう対応できるように育ってもらうんです。

でも、そこまで行くには短い時間ではたどり着けませんし、メンバ自身が目標を具体的にイメージして手に取るとは限りません。それ自体にそれなりに時間が掛かるかもしれません。でも、いいんです。何度でも話はするのは、それがマネージャの仕事だから、です。

いつも新しい経験を与える、ロールにあったアウトプットを要求する。そうしたアクティビティで自己伸長を“自然”と促すことで彼/彼女らがいつの間にか一つ上のロールにアサインされていることに気付かせないでやってもらえれば、それはそれでしたり顔をできるのもマネージャの役得なのです。