エンジニア組織 マネジメントの導入 | パフォーマンスの可視化

マネジメントでは状態の可視化を行い基準を決めて、それを監視し、基準から外れる場合はコントロールするかと思います。その辺りを一度整理しておこうと思います。

状態を可視化する目的

ITから外れたところから少し入ると、ダイエットをする際に体重を減らすために日々（もしくはある程度のサイクルで）確認する指標値があるかと思います。まず、体重、そして人によっては消費カロリーや歩数など様々な見方をしています。

その指標値が無ければどうでしょうか？

昔のスボンを履けるようにダイエットに取り組んでいるけれども、体重すらも量っていないとなると、途中で逆に体重が増えていても気づかず、その増えた原因を取り除けないことになります。そうすると思ってたよりもダイエット期間が長くなってしまったり、全然昔のズボンが履けないので途中で諦めてしまうかもしれません。

エンジニア組織（に限らず）もそのようなことは言えるかと思います。

人数も増えてくるとプロダクトへの追加・変更などは増えているように感じますが、生産性が上がっているかを判断するには何かしらの指標値が必要になります。また、何か組織的な変更や施策を行なった際にそれがどのように影響しているか判断するために指標値が必要になります。

具体的な可視化の例

実際、過去に指標値として用いたものは以下のようなものがあります。

・コード変更量
・タスク消化数
・Pull Requestのマージ数

これにより、同じ人数でも習熟度が上がってパフォーマンスが上がってきていることや、人数が増えたけれどもパフォーマンスが上がっていないことなどを分析することが出来ます。

ただ、タスクの中には調整がメインのものや、簡単な修正などボリュームや粒度が異なるものがあります。また、チームとして高い生産性を伸ばしているかという観点も重視したいと考えています。

そこで、最近では何に時間がかかっているかについても計測して可視化を進めています。以下のような項目でも可視化して改善の判断に用いています。

・タスクの所要時間
・ステークホルダーとの調整・設計の所要時間
・実装の所要時間
・コードレビューの所要時間

※他にも指標値があり、アルバイトインターンが詳細化・可視化してくれました！

これらを可視化していくと全体的にコードレビューの時間割合が高い場合に、コードレビューのやり方やサイクルなど何かしら改善すればさらに実装に集中でき、他のタスクの消化も早くなるかもしれません。

可視化を行なった上でのマネジメント

これらは一概に言えることはなく、組織を運用していく上で試行錯誤することでより良くなっていくと考えています。

サーバー管理でもWebサーバーのCPU利用率が高いことを理由にスケールアウトするとDBサーバーの負荷が増大し、システムダウンしてしまうことなどあるかと思います。

可視化せずにマネジメントしようとしても暗中模索となり、組織改善のつもりで取り組んで効果的なのか、むしろ悪影響を与えているのかは分からないと思います。

コスト、スケジュール、品質なども同様に可視化しないとマネジメント出来ません。プロダクトも同様かと思います。

可視化を行う上で注意していること

このように、計測と可視化はどんどん進めたいのですが、注意しているのは、あまり個人の監視にならないように集団としてどうかを見るようにしています。その方が組織の改善として施策も考えやすく、受け入れやすいと考えています。