パフォーマンスの高いエンジニア組織とは？#2
このNoteでは、エンジニアとして10年に渡り正社員・フリーランスで働いている森と、エンジニア採用支援の経験を活かしフリーランスで働く高木が、エンジニア採用や組織に関する課題を解決するための解決策を議論しながら考え、提案していきます。
この記事はパフォーマンスの高いエンジニア組織とは？というテーマで議論した内容をまとめたNoteです。
非エンジニアの経営者の方々や人事の方々にとって、エンジニア組織のパフォーマンスはどのように考えたら良いのかと悩まれている方も多いのではないでしょうか。
そこでエンジニアの生の意見をお伝えしつつ、エンジニア組織のパフォーマンスについて少しでも理解頂けたら嬉しいです。
この記事は概要版ですので、大枠を掴んで頂けたらと思っています。
もし詳しい内容が気になる場合は、さらに詳細な内容の記事もありますので、ぜひチェックしてみて下さい。
ポッドキャストはこちら↓
エンジニアのパフォーマンスを計測するのは難しい？どのような方法がある？
営業の場合、1人がどれだけ売上を上げたか分かりやすいですが、エンジニアの場合パフォーマンスを計測するのは難しいと考えられます。
なぜエンジニアのパフォーマンスを計測するのは難しいのか、エンジニアのパフォーマンスとビジネスの成果をどのように考えればいいのか議論しました。
エンジニアのパフォーマンスと成果が出ないことを安直につなげるべきではないのでは
今エンジニアの界隈でも、パフォーマンスをどううまく計測するか、計測してどう改善するか、ということはホットなトピックになっていると思っています。
その試みは、いろんな方々によって行われていると思いますが、現時点では、もちろんパフォーマンスが測れれば価値は絶対にあるのですが、正直に言ってかなり複雑で、なかなか難しいという側面があると感じています。
だからこそエンジニアのパフォーマンスが測れないことと成果が出せないことを、安直に連結させない方がいいと考えています。
なぜなら、特に自社サービスでは現在の状況に応じてどんどん仕様を変えていったり、ソフトウェアの機能を変えていることをどんどんアジャストしていかなければいけません。
そういったソフトウェアの開発の仕方においては、他の職種のようにボトルネックを取り除けば生産性が上がると言った単純な話ではないというのがエンジニア側の意見だと思ってます。
またエンジニアから見た厳しめの意見を言うと、ソフトウェアさえできればそれが結果になるというものではないような気がしています。つまりソフトウェアをどれだけ生産したかということが、そのままビジネス上の成果につながるというわけではない、とも言えると考えています。
なぜエンジニアのパフォーマンスを計測するのは難しいのか
特に、自社サービスを作る仕事を考えた時、それは設計図がないような建築物を作っているようなイメージです。ビジネスの環境要因や状況に応じて要求が増えたり、機能のアウトプットを変えたり、さまざまな変化に対応しなければなりません。
たとえば、水道管を今までの配置から変える必要が出てきたとき、それが見えづらい建築物の一部であるようにソフトウェアも同じようなものです。そして、その変更が建物全体を壊さないようにしながら、設計図を書き直し、開発を進めていかなければいけません。
それに加えて、3人で開発していたものを9人で開発すると、3倍の性能や生産性が出ると簡単に考えられがちです。
しかし、建築物が大きくなるほど、少しの変更でも確認しなければならない場所が増えます。これにより、確認しなければならない事項や考慮しなければならない事項が増えていき、チーム間でのコミュニケーションも増えていきます。
この辺りも含めて、エンジニア組織のパフォーマンスを測定するのは難しいと感じています。
エンジニアリングをあまり理解されていない経営者の方や人事の方は、開発スピードが遅いと感じたら、人を採用しようと考えてしまうこともあると思います。
しかしながらエンジニアの仕事やシステム開発のプロセスを理解しなければ、生産性が上がるどころか、下げてしまう可能性すらあります。
非エンジニアでも、エンジニアの方が日々どのように仕事をされて、システム開発がどのように進められているのか、それを少しでも理解しようとすることが非常に重要なのではないでしょうか。
パフォーマンスの低いエンジニア組織とはどういう状態を指すのか？
経営者や人事担当者からすると、「うちのチームのパフォーマンスは大丈夫なのか、低すぎないのか、本当にこれでいいのか？」という疑問や心配は常にあるかもしれません。
パフォーマンスが低い、またはチーム力が低いエンジニア組織とは具体的にどういう状態を指すのでしょうか？
比較対象がないとパフォーマンスが高い、低いは言えない
それぞれケースバイケースなので一概には言えないとは思いつつ、パフォーマンスが低いという判断は、何らかの比較対象があるときにできることのように思います。
例えば、ビジネスの経験も豊富で、エンジニアリングも完璧に理解するようなスーパーマンがいたとして、自社と競合他社の状況を同じようなレベルで理解した上で、その人たちのパフォーマンスが低いと判断するんであれば、合理的だとは思います。ただ現実として非常に困難なことだと思うので、パフォーマンスが低いと判断しているところは、掘り下げが足りない可能性があるのではないでしょうか。
エンジニアはベストを尽くしている
エンジニア組織の中で働いてきた視点から見ると、常にエンジニアはベストを尽くしているし、できる限りのことをやっている人ばかりだと感じてきました。
ベストを尽くしている中で、パフォーマンス的に期待するものでない、もしくはアウトプットが期待するものでないのであれば、もう少し別の角度や広い視点から見る必要があるかもしれません。
その本質的な原因をもう少し深掘りして探していくことが大事なんじゃないかと思っています。
もし仮に、エンジニアがベストを尽くしてるのかどうかについて疑問を持たれているのであれば、それは一緒に働いているチームのメンバーが信頼できていないということの裏返しなのではないでしょうか。その場合は、信頼できるチームを作るためにどうしたらいいかをまずは考える必要があると考えています。
どうしても非エンジニアから見ると、「もっとできるのではないか？」と分からないからこそ思ってしまうことがあるのだと思います。
ただ本当に信頼ができてればそのようなことは思わないはずです。
なぜ信頼ができないのか、どうしてそう感じてしまうのか、そこを一つ一つ解消していき、信頼できるチームを作ることを最優先すべきなのかもしれません。
エンジニアのパフォーマンスを測定するよりも大事なこと？
エンジニア組織のパフォーマンスに対し、高い低いを判断するということは非常に難しいです。ではそれよりも大事なこととは何なのでしょうか？
まずは難しいということを理解する
ソフトウェアは非エンジニアの方から見ると、いつでも簡単に変更できる何かすごい便利なツールのように見えるかもしれないですが、実際変更するのはとても大変です。
あくまでもソフトウェアは十得ナイフのように、ちょっと便利なものでしかありません。大切なことは、その出来上がった便利な十得ナイフをどう使うと、ビジネス側が本来やりたかったことや、期待する成果に繋がるか、なのではないかと考えています。エンジニアチームはその便利な十得ナイフを作る職人さんたちです。なのでその職人さんたちに対して、「自分たちがこういうことを目指していて、こうやってナイフを使うことでこのような結果を期待しています」ということを話し合い、職人さんにも理解をしてもらい、どうするとそれの結果に少しでも近づけるかを考えるべきなのではないでしょうか。
「ここは作るの難しいからこうしてみたらどうかな」と提案ができたりするようなワンチームを作っていき、相談しながらコミュニケーションをしながら進めていくことが大事になると考えています。
エンジニアチームとビジネスサイド、お互いの歩み寄りが重要
それを実現するには、お互いに歩み寄ることが大切です。
それぞれの役割について理解しあうことで、より効果的なコミュニケーションや合意ができると思ってます。
エンジニアの方にビジネスマインドや理解を求めるケースは多いですが、エンジニアの方がビジネスを理解するだけでは不十分で、ビジネス側もエンジニアリングをきちんと理解する必要があるのかもしれません。
エンジニア組織のパフォーマンスが下がってしまったと感じる具体例？
エンジニア組織のパフォーマンスを下げる要因はあるのでしょうか？
私たちにできることは何なのか、議論しました。
仮説を立てて繰り返さないようにPDCAを回すのは大事、ただし複雑性が高いので一概には言えない
以前ある会社で、非常に優秀なエンジニアの方がアーキテクトとして中心に入っていただけたので、これからうまく開発が進んでいくと思っていましたが、実際はそんな簡単な話ではありませんでした。
一緒にやるチームのメンバーの相性だったり、チーム内でのコミュニケーションがしっかり取れていなかったということが原因だったと振り返りますが、必ずしもそれが原因とは言い難いということです。
エンジニアリングは色々な要素が絡み合って、複雑性を増しながら開発・コミュニケーションをしているものであり、その状況をきちんと全て把握できないと一概には言えないと考えています。
幅広い視点で現象を捉え、お互いが信頼できるチームを作ることがとにかく大事
例えば期待した納期までにソフトウェアができなかったとか、出来上がったものに期待するような機能がなかったときに、全てがエンジニアの責任になりがちだと感じています。
これまでの経験上、必ずしもエンジニアだけがその原因にあるとは限らないことの方が多いと感じているので、もう少し幅広い視点で現象を捉えた方が良いのではないでしょうか。
またお互いが信頼して一つのチームを作って、お互いの理解を深めようとすることが大事です。
エンジニアはビジネスの側の人たちの言葉を理解すべきであり、ビジネス側の方々もどうしてシステムの開発に時間がかかるのか、理解することが大事だと思っています。
その上でお互いにプロとして尊敬し信頼し尊重しながら、きちんとコミュニケーションを取り、自分たちが本来目指してるビジネスの目的をどうやって達成していくのかをフラットに考えていくことが大事なのではないでしょうか。
お読み頂きありがとうございました！
エンジニア採用にお困りの企業様はぜひ一度カジュアルに情報交換をさせて頂けたらと思います。
以下のフォームからお気軽にご連絡下さい。
私たちは実際に業務委託として働く中で、働き方の違いで裁量が違ったり、ケアやフィードバックに違いがあることに疑問を感じてきました。
そういった中で、業務委託エンジニアが自分の強みを活かして、業務での活躍を支援する「プロレポ」というサービスを開発しています。
現在、30分ほどヒアリングにご協力をいただける企業様を探しています。
もしご興味を持って頂ける方がいらっしゃいましたら、お気軽にご連絡下さい。
『プロレポ』は業務委託エンジニアが自分の強みや好きを活かし、パフォーマンスを最大化させるためのフィードバックレポートツールサービスです。
働く側は自分の好きなことや強みを活かしながら事業に貢献をし、企業側はそれを実現するために理解し機会を提供することで実現しようと考えています。
この記事が気に入ったらサポートをしてみませんか？