TOP ＞ マネジメント ＞ エンジニアリングチームのマネジメント、対象にすべきは指標では...
関連カテゴリー： アプリ／OS
筆者はソフトウエアエンジニアリング企業を営んでいる。弊社のような企業に業務を委託する企業の幹部や管理者は数字が大好きで、成果物の価値を定量化できるとされる指標を重視する。コードの可読性や簡潔さを高めるリファクタリングの細かな話は通じないかもしれないが、コードカバレッジが85％から90％に上がったという報告には喜ぶ。数字が増えたからには価値のある成果が生まれたはずだと考える。
Credit: Thinkstock
だが現実問題として、この手の数字にはナンセンスなものも多々ある。指標としては妥当性があったとしても、マネジメントの手段としてはうまく機能しない。指標にも存在意義はあるが、先に来るべきはあくまでチームの方向性だ。そうでなければ、チームが開発するソリューションの品質や価値を定量化できない。最初から指標ありきで、ストーリーポイントの尺度に開発者が合わせるやり方では、イノベーションや創造性、意味のある問題解決といった面で、チームの能力発揮をむしろ妨げることになる。
エンジニアリングチームが効果を発揮し、本当の意味で価値のあるソフトウエアソリューションを開発するためには、リーダーがマネジメントすべきは指標の数字ではなく、開発者の士気や満足度、チームの共通認識だ。さらには、こうした点に対する信頼を土台として、効率と品質を高め、一人ひとりが優れた成果を上げられる企業文化を育む必要がある。
指標に対するマネジメントは非効率で効果も低い
簡単な例で考えてみよう。ある開発チームが各スプリントで20件のチケットをコンスタントに完了しているとする。指標の数字は上出来で、チームは明らかに優秀だ。プロダクトオーナーは進捗についてステークホルダーに素晴らしい報告ができる。
だがチームの実情に目を向けたところ、週60時間の勤務を続けることで達成している数字だとしたらどうだろうか。メンバーは疲労困憊し、燃え尽き、友人や家族との時間も取れないでいる。自分たちが生み出している成果物の価値もよく分からない。ひどい疲れ目と手根管症候群に苦しみながら、汎用ロボットのような扱いを受け、当人たちもそのように感じている。果てしなく続く製造ラインでコードを組み立て続けるロボットだ。
指標の数字は素晴らしい。しかしチームの士気は悲惨だ。
細かく見ていくと、コードの品質にも間違いなく影響が表れていて、ソリューションの潜在的な価値が損なわれているはずだ。自動テストやリファクタリングはほとんどなく、やっつけ仕事を重ねている。技術的負債や拡張性の問題、望ましいユーザー体験と実際のコードとの乖離など、課題が次々と見つかることだろう。
チームが採用しているメンバーは、本来は品質を大切にするエンジニアのはずだ（そうでなければ採用してはいけない）。つまり、現在の仕事のレベルが低いことは本人たちも分かっている。おかげで士気はますます下がる。
こういう状況が長く続けば、メンバーの退職という新たな損失に見舞われる日も近い。加えて、プロジェクトの途中で新しいエンジニアを迎え入れるのにも時間と費用がかかる。
士気ではなく指標を対象としたマネジメントを続けていては、こうした問題が目に入ってこない。気づいた頃には手遅れになっている。
からの記事と詳細 ( エンジニアリングチームのマネジメント、対象にすべきは指標ではなく士気（上） - エンジニアリングチームのマネジメント、対象にすべきは指標ではなく士...：CIO Magazine - Nikkei Business Publications )
https://ift.tt/JjlpAeF
0 Comments:
Post a Comment