TOPSoftware > ソフトウエア開発者の管理と評価、マイクロマネジメントを避ける...

Software

ソフトウエア開発者の管理と評価、マイクロマネジメントを避ける7つのポイント(上)

2022/03/07

Isaac Sacolick InfoWorld

 筆者は最近、ソフトウエア開発者の生産性、品質、成果を測定する方法について、何度か相談を受けた。主に、上層部がハイブリッドワークのモデルを推進している企業からの相談だった。だが、優秀なソフトウエア開発者は、上司に一挙手一投足をチェックされるような管理手法には強く反発する。マイクロマネジメントの文化に嫌気が差して退職するケースも少なくない。人材の採用や維持に苦労しているテクノロジー企業は、この種の問題に直面している。

Credit: NDAB Creativity / Shutterstock
Credit: NDAB Creativity / Shutterstock

 ソフトウエア開発の経験がない人の部下になるよう命じられた開発者は、形式主義的なプロセスへの恐れを感じる。自己組織化の原則を極限まで取り入れているアジャイル開発者であれば、完全な自律性を追求している場合もある。人によっては、生産性や品質などのパフォーマンス面を上層部が測定しようとする兆候を感じただけでも、抵抗するかもしれない。

 マイクロマネジメントが反感を招くとなれば、年次人事評価に対する嫌悪感はさらに強い。開発者が追求しているのは、リアルタイムのパフォーマンス目標であり、ベロシティ、デプロイ頻度、サイクルタイムなどのKPIの改善だ。パフォーマンスについてスプリントの最後に毎回話し合っているスクラムチームであれば、年単位や四半期単位の人事評価でフィードバックを得るなんて、無意味と思うかもしれない。

 だが現実問題として、会社側からすると、パフォーマンス、開発、ビジネスの各面で、アジャイルチームやソフトウエア開発者が目標を達成できているのかどうか、把握するための手段は欠かせない。マネージャーとして必要な情報を入手しつつ、開発者の気分を害さないようにするには、どうすればよいだろうか。

 以下に取り上げる7つの推奨プラクティスは、アジャイル、スクラム、DevOps、ソフトウエア開発ライフサイクルの原則に沿ったもので、場合によってはソフトウエア開発者の評価に適用できるかもしれない。SMART(具体的、測定可能、達成可能、関連性、期限設定)の法則に沿った目標の形では示していないが、各社のアジャイル手法やビジネス目標に合わせて、適切な項目を取り入れてほしい。チームレベルでのみ関係する項目もあれば、直属の部下の評価に関係する項目もある。

↑ページ先頭へ