開発組織のマネジメントの役割ついて考える
はじめに
転職して今の会社に勤めて1年と少し経過した。今回の転職では、これまでのエンジニア業務である開発であったり、システム運用を期待される役割から、明確にマネジメントを実施するポジションでの採用であった。開発組織のマネジメントという役割を切り出して考察すると改めて何をすることがマネジメントの役割であろうか。また、中途採用でマネジメントを遂行することの難しさを感じる一年だった。年末ということもあり、振り返ってみることにする。
マネジメントとテクニカルエンジニアの役割分担について
開発組織のマネジメントという役割を切り出して考察するために、マネジメントのラインとエンジニア(テクニカル)のラインで考えてみる。もちろん、ココで述べていることは会社によって違うし、すべてが当てはまる訳ではない。
マネジメントの役割
いわゆるエンジニアメンバのピープルマネジメントを行う役割。EM(エンジニアリングマネジャー)が一番近いイメージであろうか。エンジニア開発部門の課長・部長といった役職者にあたる。
通常の部課長が行うであろうタスク「予算管理」「稟議決裁」「勤怠管理」等々に加えて、エンジニアメンバの組織編制を行う。重要な施策ポイントは以下。
- ロードマップにそった開発の遂行
- エンジニア部隊の組織運営
ロードマップにそった開発の遂行
ビジネス側とすり合わせをし、開発をなるべくロードマップに沿った形でリリースする。なるべくと書いたのは、よくビジネス側からの要求が開発に一方通行で、言われたとおりのものを作るだけのやらされ仕事になって、エンジニアのモチベーションが上がらない状態の組織もある(ほとんど)。
売れ筋の自社プロダクトを持っている会社であれば、このような流れになるのは、ある程度は許容しなければならない。結局売りが立たないと何にも成り立たないから、SIer的な業務を実施する中で、どうやってエンジニアのモチベーションを上げていくかというのが、開発マネジメント側の課題になる。ここの課題に対する答えは現状まだ持ち合わせていない。
エンジニア部隊の組織運営
エンジニアをリードするリーダを選定して、組織を運営する。当たり前のことだけど、これが大変だった。
- エンジニア退職問題
直近の市場状況を鑑みると、これまでに無いくらいエンジニアの市場価格は高騰していて、特にフロントエンドエンジニアの給与は自分の認識と相違がある。REACT 2年くらいの経験者が結構な単価で市場で評価されている。ベンチャー以外は、この市場価格と社内の給与評価システムはあってないし、追い付けない組織体がほとんどだと思う。なんでエンジニア部門だけが給料高いんだよという歪みは必ず生じてしまうし、それを理解してもらうのは時間がかかる。この歪みを解消するには時間がかかるため開発部隊であれば、ある程度退職者がでることを見越して組織編成をする必要がある。
大切なことは退職者が出たことに対してマネージャーは、自分に矢印を向けすぎないということ。これとても重要。特に着任してすぐに退職者が出ると、何か自分に非があったのではないかと考えるし、退職者が退職を決断した時点で、ポジティブな退職理由の人を除いては、ほとんどが現環境にマイナスのベクトルが作用しているので、ネガティブな発言を残していく。それはそれで割り切らないと到底やっていけないので割り切るしかない。
ここの解決は、時間をかけてでも、エンジニアのみを評価する制度を個別に制定するしかないと思う。それはきっと年齢に関係無く、技術力でのみ評価する形になるが、この年齢に関係無くという制度を定着させるリスクはあるが、進めなければならない。他社のエンジニア評価制度に注目している。
- マネジメントラインを担うリーダーを選出する。
プロダクトやサービスを良くしたいといった外向きのベクトルを備えた人財を年齢に関係なくリーダーとして据える。
「自分の経験値を積む」であったり、「仕事とプライベートをしっかり分けることができる」であったりを会社へ要求するのは理解できる。それがない会社は今のご時世ダメであることも分かっている。だが、やっぱり自社のプロダクトにコミットしたい、自社のプロダクトを通じで世の中を良くしていきたい。なによりも自社プロダクトに愛着がある人財を育てることが大事。これは技術力とはまた違うベクトルになる。ベクトルが内向きの人はやっぱり採用でも止めないといけない面はある。
テクニカルエンジニアの役割
エンジニアにも2種類ある。プロダクトに貢献するエンジニアと、会社の技術選定であったり、新規事業などのR＆Dを実施する組織横断のエンジニアである。後者がテクニカルエンジニアにあたる。テクニカルエンジニアという言葉はまあそれっぽい名前としている。エンジニア(テクニカル)のラインは、このエンジニアが該当する。テクニカルエンジニアの役割を記載しているが、マネジメント側がどう立ち回るかという視点でも記載する。
数年先を見据えた技術選定をする
例えば、アサインされたエンジニアがRAILSが得意という理由で、あるバックエンドサービスにRAILSを採用し、プロダクションへ適用した時点で、そのコードを保守するRAILSエンジニアをサービスが継続する年数分確保することが必須となる。技術選定は会社の方針を決めるうえで重要な分岐点となる。RAILS採用を決めた場合は、そこからRAILSエンジニアを5年くらい確保して、会社の中核技術とするくらいの決断になる。ここにGolangなどの言語を加えたい場合は、既存のRAILSエンジニアの生産性は落ちる、かつ多様な言語が混在するブラックボックスが生まれやすい環境かつ、コードを書いた人しか機能が分からない状態に陥ってしまう可能性が高い。
つまり何が言いたいかというと、技術選定は割と開発部隊にとって大きな判断が必要になるのに、それに見合った経営判断ができてないユースケースが多い。何となくプラットフォームにAWS選定してみたりも同様。
組織を超えた技術選定を共通化できる役割がテクニカルエンジニア組織である。技術選定だけでなく、細かな運用ツールであったり、WIKIのようなポータルやDWHであったり、似通ったツールが複数混在しないように制御するというのも重要。マネジメントが意識することは、テクニカルエンジニアのジャッジメントレビューがすでに通ったものであるか確認することである。技術選定、ツールを共通化することで、組織運営は楽になる。採用も同様。RAILSに舵を切ったのであれば、市場からRAILSエンジニアを取れば良い。
テクニカルエンジニアは技術で評価
基本テクニカルエンジニアは技術力で評価する。実施タスクの難易度・スピードとか、会社によって様々なやり方があると思うが、重要なことはマネジメントが100%全部評価をしないこと。会社のコアスキルを持ったエンジニアが、技術力の高い人に評価される仕組みを作る。マネジメント側の評価比率は10%とかに落ち着くのがベストではなかろうか。そもそも部課長よりメンバのスキルが高いのは普通だから。
言いたかったこと
マネジメントだけの軸だと厳しい
これまでの部長・課長といったマネジメントのラインだけでは開発組織の運営を続けることが難しくなってきている。ピープルマネジメントやモチベーション管理をやりつつ、数年先を見据えた技術選定をするといったことはできない。
技術のことは技術に特化した部隊に切り出して、技術的な判断を任せた上で組織運営する、というのがベストでその組織体をどう構築していくかが、マネジメントの課題であると感じている。評価についても、技術で評価してほしい場合は、テクニカルエンジニアに配置転換して評価する。ただし、技術で評価が低い人はしっかりとしたマイナス評価をすることも大事。これができると、プラス評価は市場価格以上の評価に追いつく。
強い組織を作る
エンジニアにおいても技術を極める軸と同様に、強い開発組織を作る・強いプロダクトチームを作りビジネス貢献をする、という目標をもったエンジニアが課長・部長を目指せる仕組みを作る。技術軸の人はテクニカルエンジニアとしてCTO的なポジションを目指す。両方の軸で目指す道しるべがあるという組織を作ることがマネジメントの役割である。
さいごに
役職付きで中途入社すると、まわりのメンバが積極的に教えてくれるということはあまりない。なので、地味にその会社特有のルールであったり、やり方を理解することがやっぱりキツい。どのプリンタを使って印刷するのか、また紙媒体の契約書の押印ルール確認とか、このあたりは自分で確認するしかなかったのが結構な負担だった。役職付きで転職するとまぁ、割と大変だなと改めて感じた。これはどの会社に行っても同じ。
また最近、BLOGとか見ても、テクニカルエンジニアとしてさらなる高みを目指すため転職しましたウェーイ!!エントリーが多くみられるが、一方、退職者が出ても開発が回るようなチームを維持する仕組みを考えて作り、支えているマネジメントの課長・部長にもっと光があたる世界であっても良いと思う。
課長・部長の守備範囲があまりに広く、職位が上がるにつれて技術から離れていくイメージがあるから、そこを目指さない組織体になってしまうケースが今後増加するのではないだろうか。若手エンジニアが技術のトップに立つように部長・課長ももっともっと若い世代が立つべきだと思うし、技術から離れるわけではなく、技術に対する貢献のスタンスが変わるだけなので、もっともっとマネジメント側の人達に光があたりますように。
Discussion