エンジニアのパフォーマンスを計測するのは難しい？どのような方法がある？#2-1
この記事は以下の「パフォーマンスの高いエンジニア組織とは？」の詳細版です。
ここでは、なぜエンジニアのパフォーマンスを計測するのは難しいのか、エンジニアのパフォーマンスとビジネスの成果をどのように考えればいいのか議論しました。
高木 本日は、「パフォーマンスの高いエンジニア組織とは？」というお話をしていきたいと思います。
経営者や人事の方々の多くは非エンジニアなのではないでしょうか？私もエンジニア採用の仕事をしてきましたが、ソフトウェアエンジニアではありません。そんな中で、エンジニアの仕事内容やモチベーションを理解するのは難しいと感じています。
特にチームとしてのパフォーマンスになると、より理解が難しいです。営業の場合、1人が1件売り上げたり、チームでいくら売り上げたなど分かりやすいですが、エンジニア組織の場合はパフォーマンスが測りづらいと感じています。
しかし、エンジニア組織はプロダクト開発の鍵を握っており、会社の事業の成長に大きく影響します。そのためパフォーマンスの高いエンジニア組織とは何か、言語化ができたらと思い、このテーマとしました。
私自身なかなか理解ができていないところですので、今日はエンジニアの森さんの意見も交えながら、このテーマを深堀りしていきたいと考えています。
さて、エンジニア組織のパフォーマンスについては、そもそもパフォーマンスを測るのが難しく、また計測できないから成果に繋がらないのではないかという声もありますが、どう思われますか？
森 今エンジニアの界隈でも、パフォーマンスをどううまく計測するか、計測してどう改善するか、というのはホットなトピックになっていると思っています。
その試みは、いろんな方々によって行われていると思いますが、現時点では、もちろんパフォーマンスが測れれば価値は絶対にあるのですが、正直に言ってかなり複雑で、なかなか難しいという側面があると感じています。
また、エンジニアのパフォーマンスが測れないことと成果が出せないことを、安直につなげない方がいいと考えています。
高木 どうしてもパフォーマンスが測れないから、どれだけやってくれたのかが分からない、そしてそれをビジネス側の売り上げやユーザー数などにつなげて考えてしまうケースがあるように感じます。どうしてそのようにつなげて考えてしまうのだと思われますか？
森 例えば「この機能を開発してほしい」「こんなアプリを作ってほしい」という要望があったとします。エンジニアは期待された納期から少し遅れたり、リリースしたものに対して期待された機能が少し足りなかったり、少しバグがあったりすると、結果として見たときに成果につながってないのではないかと感じるかもしれません。
このようにエンジニアが作ったアウトプットが成果につながらないと見えてしまうので、エンジニアのパフォーマンスが悪いと捉えられてしまうのではないかと推測しています。
高木 確かに営業や他の職種のように数字があれば分かりやすいですし、例えば「ここがボトルネックになっている」と分かれば、そこを取り除けばもっと生産性が上がるのではないかと考えてしまいがちです。しかし、そのような考え方はエンジニア組織ではなかなか当てはまらないのでしょうか？
森 当てはまらないというのが僕の経験です。このあたりは受託型の開発をしてるか、自社サービスの開発をしてるか、実際にやっている事業でのソフトウェアの重要度の比率によって全然変わってくると思います。一概には言えないという前提のもとで、僕が経験が長い自社サービスについて話をさせていただきます。
自社サービスでは現在の状況に応じてどんどん仕様を変えていったり、ソフトウェアの機能を変え、どんどんアジャストしていかないといけないと思っています。ですが、そういったソフトウェアの開発の仕方について、ビジネス側の方々の理解が少し不足しているんじゃないか、というのがエンジニア側の意見だと思ってます。
あともう一つ、エンジニアから見た厳しめの意見を言うと、ソフトウェアさえできればそれが結果になるというものではないような気がしています。つまりソフトウェアをどれだけ生産したかということがそのまま結果につながるというのは、見た目上はそう見えることもよくあるですが、そのままイコールにはならないのでは、というのが僕の意見です。
高木 確かにその通りかもしれません。特にテック系の企業だと、どうしてもプロダクトありきでビジネスを考えてしまうところがあるだと思います。ただ必ずしも絶対その開発が必要なのか、開発をしなくてももっと売れる、あるいらユーザー数を獲得する方法があるかもしれないですよね。こういった話を普段どれだけ社内でされてるかというところも、もしかすると大事なポイントになってくるのではないでしょうか。
実際、先ほどもいろんな会社さんがエンジニア組織のパフォーマンスを測定しようと試みているような話もありましたが、どういったものがあるんでしょうか？
森 そうですね、最近流行り始めていると感じるのはFindyチームというツールだったり、Office MGRのような、ある側面からのエンジニア組織のパフォーマンスを測定するツールというのが出始めていると思います。おそらく海外でもいくつかサービスがあると思います。
あとはGitHubでも、実際にコーディングする作業に関しては計測できる機能が提供され始めてます。
とはいえ、例えばプログラミングの作業というのはエンジニアがやってる実際の業務の中のごく一部だったりするので、これだけで全てを計測できるというわけではないと考えてます。
高木 そうですよね、プログラミングだけじゃなくいろんな業務が絡み合ってますし、しかもそれがチームでとなると、エンジニア組織のパフォーマンスは定義自体が難しそうですね。
森 はい、定義から非常に難しいと感じています。
特に、自社サービスを作る仕事を考えた時、それは設計図がないような建築物を作っているようなイメージです。ビジネスの環境要因や状況に応じて要求が増えたり、機能のアウトプットを変えたり、さまざまな変化に対応しなければならないですよね。
たとえば、水道管を今までの配置から変える必要が出てきたとき、それが建築物の一部であり、非常に見えづらいものだとイメージができるかと思います。
ソフトウェアを作るときも同様です。常に考慮し、その変更が建物全体を壊さないようにしながら、設計図を書き直し、開発を進めています。
それに加えて、3人で開発していたものを9人で開発すると、3倍の生産性が出ると簡単に考えられがちです。しかし、建築物が大きくなるほど、少しの変更でも確認しなければならない場所が増えます。これにより、確認しなければならない事項や考慮しなければならない事項が増えていき、チーム間でのコミュニケーションも増えていきます。この辺りも含めて、エンジニア組織のパフォーマンスを測定するのは難しいと感じています。
高木 開発スピードが遅いと感じたら、人を採用しようと考えてしまう経営者や人事担当者の方は多いのではないでしょうか。
しかし、エンジニアの仕事やシステム開発のプロセスを理解しなければ、単純に人を増やせばいいと考えてしまうのは避けられないと感じています。
エンジニアの方が日々どのように仕事をされて、システム開発がどのように進められているのか、それを理解することが非常に重要だと感じました。
次回に続きます↓
エンジニア採用にお困りの企業様はぜひ一度カジュアルに情報交換をさせて頂けたらと思います。
以下のフォームからお気軽にご連絡下さい。
私たちは実際に業務委託として働く中で、働き方の違いで裁量が違ったり、ケアやフィードバックに違いがあることに疑問を感じてきました。
そういった中で、業務委託エンジニアが自分の強みを活かして、業務での活躍を支援する「プロレポ」というサービスを開発しています。
現在、30分ほどヒアリングにご協力をいただける企業様を探しています。
もしご興味を持って頂ける方がいらっしゃいましたら、お気軽にご連絡下さい。
『プロレポ』は業務委託エンジニアが自分の強みや好きを活かし、パフォーマンスを最大化させるためのフィードバックレポートツールサービスです。
働く側は自分の好きなことや強みを活かしながら事業に貢献をし、企業側はそれを実現するために理解し機会を提供することで実現しようと考えています。
この記事が気に入ったらサポートをしてみませんか？