この記事はOPENLOGI Advent Calendar 2024の記事です。
はじめに
先日、エンジニア組織のマネジメント層が集まる交流会に参加しました。参加者は主に、EM（Engineering Manager）やGM（General Manager）、VPoE（VP of Engineering）といったエンジニアリング組織の責任者をやっておられる方々でした。
BtoB、BtoC問わず多くの日本のSaaS自社開発企業が集まり、開発組織のROI最大化、経営層/Biz側との意思疎通、チームトポロジー、開発生産性、エンジニア採用、エンジニアの評価と目標設定、育成とオンボーディング、セキュリティ対策など、幅広いテーマについて情報交換・議論を行ってきました。
本記事では、その中でも印象的だったトピックやマネジメントの悩みをお伝えできればと思います。
1. 開発生産性の「見える化」とその先の壁
Four Keysの導入と運用の悩み
デプロイ頻度、変更リードタイム、変更障害率、サービス復元時間、というソフトウェア開発チームのパフォーマンスを測る4つの指標がFour Keysです。
この言わずと知れたFour Keysですが、多くの企業が（全ての指標とまでは言いませんが）導入していることが分かりました。一方で、ほぼ全員が同じ悩みを持っていました。
「数値は取れるけれど、どう活用すればよいか分からない」
導入の動機までは話として出てきませんでしたが、経営層や事業サイドからの要望もしくは、開発組織である自分達自身からの能動的な行動である可能性が高いと考えており、「数値を出すこと自体が目的化してしまう」という問題が発生しやすいものと推察できます。
以前、知り合いのテックリードは「Four Keysの指標は自分達の健全性を測定するためのもので、それ自体を自組織外に共有したり、数値目標にするのはおかしい」と言っていたのですが、まさにその通りだなと思う内容でした。
SPACEフレームワークの課題
Four Keysとは別の視点で開発者の生産性を計測するための下記5つの指標の頭文字を取ったのがSPACEです。
- Satisfaction and well-being
- Performance
- Activity
- Communication and collaboration
- Efficiency and flow
それぞれの指標を自社の合う指標に置き換える必要があります。例えば、「Activity」についてはPR数、コミット数、コード行数などがありそうです。
今回情報交換した企業では「Satisfaction and well-being」のみ計測しているところがほとんどでした。計測方法はアンケート形式が主流だったのも関係しているのか、次のような悩みを聞くことが多かったです。
- 人事部等が主導している組織サーベイが別にあって、その違いが分からない
- 社員から「やる意味あるの？」と言われる
指標導入の本質
-
トップダウンの限界
指標導入は「上から与えられたもの」ではなく、チームや現場の当事者意識が伴わなければ、形骸化しやすいです。 -
熱量のあるリーダーシップ
勉強会では、「指標導入を推進する熱意を持った人がチームにいること」が成功のカギだと何度も語られていました。熱意を持っているということは、それだけ導入する必要性を語ることができるという考えです。
2. 経営層との意思疎通
開発生産性の指標と並び、企業のVPoEやEMが共通して直面しているのが、経営層との意思疎通です。
合意形成の難しさ
なんといっても、経営層と「開発の成果とは何か？」の合意を取る必要があります。しかし、実際には「成果の定義が曖昧」であるケースが多く、前述の開発生産性指標も『やれる範囲で』になりがちだと感じました。
改善へのヒント
「成果の定義」について、ビジネス側とエンジニア側で継続的な対話が必要で、成果指標に対する「経営層の納得感」を高める仕組みが求められていると感じました。
開発組織だけで決めてしまわないように注意が必要ですね。
3. セキュリティ対策と経営層へのアプローチ
セキュリティ対策においては、経営層の理解度がある一方で、費用面での壁が多く議論されました。
現状のセキュリティ対策
年に1回の大規模な脆弱性診断を実施し、その後は開発案件のボリュームに応じて対策の判断をしているケースが多かったです。しかし、経営が厳しくなった時のコスト削減対象として一番最初に挙げられるのが年1回の診断費用という話も多かったです。
経営層との交渉ポイント
「やらないと起こるリスク」というネガティブな訴えより、「やることで得られるポジティブな効果」を伝える方が話が通りやすいという意見が多くありました。
例：「セキュリティ対策を行うことで、顧客からの信頼を得られ、ビジネスの競争力が高まる」など。
経営層も人なので、マイナス面による危機感よりプラス面の方が聞いてもらいやすいというのもありそうです。
まとめ
今回の交流会はトピックありきでの交流会だったため、そこに課題を持っている人が集まっていました。主催者側の狙いとしては「うちはこうやっているんだけど、そちらはどうやってます？」というのがあったような気もしますが、実際は「どうすれば良いか分からなくて悩んでいる」人が多く、主催者側の狙い通りだったのかは気になりました。
さて、今回の交流会を通じて、エンジニア組織のマネジメントに共通する課題が見えました。
- 開発生産性指標は導入後の活用が大きな壁
- 経営陣との合意形成には、成果の定義と納得感が欠かせない
- セキュリティ対策はポジティブなアプローチでの交渉が効果的
私自身も今回の学びを自社組織に活かしつつ、こういったリアルな課題に向き合う仲間たちと引き続き知見を共有していきたいと思います。
終わりに
同じ課題に直面している方や、うまく乗り越えた事例をお持ちの方は、ぜひ情報交換させてください！エンジニア組織の成長を支える取り組みを一緒に進めていきましょう。