Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

開発者体験サーベイ、めっちゃよかったんで、おすすめです

エンジニアリング戦略室の高井といいます。

みなさん、開発生産性を高めていますか? 近頃、開発生産性という言葉をよく聞くようになってきました。開発生産性について書かれたブログや技術イベントでの発表を目にする機会が増えています。これはソフトウェアの重要性が高まってきていることや、またアメリカの金利政策によってマクロ経済状況が変化したという背景が影響しているようにも感じます。開発生産性という言葉がバズワードのようになりつつあります。

誰もが重要だと考えている開発生産性ですが、それが何であるのか、またどのように改善していくのか、という具体的な話になると喧喧諤諤の議論になってしまうようです。開発生産性とは、どうにも茫漠としていて、とらえどころがない、そしてなかなか難しいものです。

本エントリーでは、いくつかの研究を補助線にしつつ、開発生産性というよりも開発者体験にフォーカスしてみた私たちの経験についてご紹介します。抽象的な議論が欲しいんじゃなくて具体的なアクションをしたいんだよなあ、という方の参考になれば幸いです。

開発生産性は難しい

開発生産性の向上に取り組もうとしたときに困ってしまうのが、どのようにそれを定義して、測定し、改善していくかという三点になります。定義した生産性はその指標によって表すことができているのか、どのように指標をもとに改善活動をおこなうのか、これらの関係が明瞭でないと「本当にそれが重要なのか」とか「どう改善につなげられるのか分からない」ということになってしまいます。

マネーフォワードでは、エンジニアリング生産性を示す指標として Four Keys を採用しています。本来、 Four Keys は DevOps に関する指標ですので、厳密には開発の生産性というよりも、エンジニアリングチームの生産性に関する指標です。しかし、私たちは SaaS サービスを提供していますので、各プロダクトが継続的な価値提供ができているかどうかが本質的に重要です。そのため、 Four Keys を生産性指標として設定し、改善活動を行なってきました。

Four Keys はよく設計されたメトリクスで、それを測定することでプロダクト毎の課題を明らかにすることができました。個々の指標がどれくらいのパフォーマンスなのかを示す基準も提示されているので、その指標をもとに「 medium になっている項目を high にしよう」といった具体的な目標を持つこともできるようになりました。たとえば、変更のリードタイムが medium だったチームがフィーチャートグルを導入することで、変更のリードタイムを改善することができた、そのような事例も生まれています。

一方、 Four Keys だけでは全てカバーできないということも分かってきました。 Four Keys はエンジニアリングチームの生産性に関する指標なので、Four Keys にもとづく改善活動が開発プロセスやワークフローの改善に関する取り組みが中心となります。また、チームや開発者の状態を敏感に反映するものではないので、細かな施策のフィードバックをすぐに得ることができません。実際のところ、私たちの Four Keys の指標は「それほど悪くない」という状態だったので、どう指標を改善していくのかという観点で、すぐに頭打ちになってしまいました。


【PR】 Developer Experience Engineer 募集中!

Developer Experience Engineer になって開発者体験を一緒に向上させませんか? マネーフォワードでは、開発者生産性と開発者体験の向上に責任を持ち、幅広い領域で活躍するエンジニアを募集しています。


開発生産性から開発者体験へ

Four Keys のようなチームやデリバリーに着目をした生産性の指標だけではなく、もう少し別のアプローチから開発生産性にフォーカスをしていくこともできるかもしれません。

たとえば、 SPACE というものが開発生産性を測定するためのフレームワークとして提案されています。 SPACE は Satisfaction and well being、Performance、Activity、Communication and collaboration、Efficiency and flow という五つの軸について、個人、チーム、システムという三つの側面から焦点をあわせることで、開発生産性をよりホリスティックにとらえる視点を提供します。

しかし、 SPACE はあくまでも開発生産性をとらえるためのフレームワークであり、具体的な手法を提供するものではありません。私たちの困りごとである、開発生産性をどのように定義して、測定し、改善していくかという悩みは、依然として残されたままになっています。

そんなときに知ったのが開発者体験に関する研究です。『DevEx: What Actually Drives Productivity 』は Abi Noda らによる研究で、『LeanとDevOpsの科学』 を著した Nicole Forsgren も共著者として名前を連ねています。開発者体験とは、開発者が開発を行なう過程で考えたり、感じたりする総合的な体験のことです。この研究の興味深いところは、開発者体験というはっきりとしない概念について、それを測定する枠組みを提供しているところです。研究では、フィードバックループ、認知負荷、フロー状態の三つの軸からとらえ、開発者のパーセプションとシステムやプロセスといったワークフローの側面から把握するとともに、全体的なKPIを加えたメトリクスを構成することを提案しています。

このフレームワークにもとづいて開発者体験を調査し、把握することで、より開発現場に近い課題の発見や、それにもとづく改善ができるのではないかと考えました。

さらに、都合のよいことに、同じ研究グループによって『DevEx in Action』という研究も発表されています。こちらは、開発者体験を構成するフィードバックループ、認知負荷、フロー状態が、開発者やチーム、組織のアウトカムに影響をしているということを明らかにしています。ようするに、開発者体験を良くすることで、開発生産性の向上が見込めるというわけです。

開発者体験サーベイの設計

開発者体験サーベイの実施にあたっては、私たちマネーフォワードのワークフローを考慮したうえで、開発者体験のフレームワークにもとづいて調査票を設計しました。先ほど紹介した論考で紹介されていた例も参考にしています。調査票は次のような質問から構成されており、問1から問22が5段階評価で回答するもの、問23から問25が自由回答です。

  1. 会社から提供される機材は充実しており、十分な性能を備えている。
  2. 開発に必要なツールは、必要に応じて会社から提供される。
  3. プロジェクトの開発環境の設定手順はよく整備されており、すぐに開発を開始できる。
  4. 開発環境で修正したソースコードをすぐに検証し、その機能を確認することができる。
  5. プロジェクトのソースコードの品質は優れており、よくメンテナンスされている。
  6. プロジェクトのソースコードを理解するためのドキュメントは十分である。
  7. コードレビューを依頼すると、迅速に実施される。
  8. 開発環境にはよく整備された自動テストがあり、結果を迅速に確認できる。
  9. テスト環境としてのCIは十分に整えられており、テスト結果を迅速に確認できる。
  10. 変更したソースコードは、短いリードタイムで本番環境にリリースされる。
  11. デプロイの手順は最小限で、比較的容易である。
  12. テスト環境は本番環境と同等であり、事前に潜在的な問題を特定できる。
  13. テスト環境では、パフォーマンスなどの非機能要件に関連するテストを効率的に行うことができる。
  14. 本番環境で問題が発生した場合、その原因を迅速に特定し、修正するための環境が整っている。
  15. 本番環境の運用手順はしっかりと確立され、維持されている。
  16. 技術的な質問をすると、迅速に回答を受けることができる。
  17. 途切れることなく継続的に開発に集中できる。
  18. プロジェクトやタスクの目標は明確で理解しやすい。
  19. オンコールの精神的・身体的負担は最小限である。
  20. 会議や中断がなく、開発にかなりの時間を確保できる。
  21. 当初予期していなかった予定外のタスクや要求をほとんど受けない。
  22. チームが協力して対処する必要があるインシデントの頻度は低い。
  23. 私たちの開発で使用しているツールやワークフローで最も気に入っている点は何ですか?
  24. 私たちの開発で使用しているツールやワークフローで最も難しいと感じる点は何ですか?
  25. マネーフォワードでの開発経験について、一つだけ改善できるとしたら何ですか?

次のアクションに向けて

具体的な調査の結果について、ここでは割愛させていただきますが、開発者体験について定量的に把握できるようになったことは大きな成果です。開発環境構築支援など、制度として支援している項目については、それが高い評価として表れています。また、私たちのコードベースが大きく複雑化していて、開発者の認知的負荷が高まっていることが数値からも読み取れます。自由回答からも具体的な改善項目が見えてきました。

開発者体験サーベイの実施によって、定量的に開発者体験をメトリクスとしてとらえることができました。そして、それを単に指標として把握するだけではなく、具体的な改善にもつなげることができそうです。開発者体験サーベイの指標は、具体的な開発者の活動に結びついているので、改善ポイントが分かりやすいのです。

開発者体験のメトリクスについては、私たちがこれまでエンジニアリング生産性を示す指標として採用してきた Four Keys とともに継続的に活用していきたいと考えています。


ここまでお読みいただきありがとうございました。マネーフォワードでは、このような開発者体験に関する改善に責任を持つ Developer Experience Engineer に興味があるエンジニアの方を募集しています。 Team Topologies でいうところの enabling team として、各プロダクトチームの支援をするポジションを想定しています。

いきなり応募するのも気が引けるという方のために、カジュアル面談もご用意してございます。開発者サーベイについて詳細を聞いてみたいという方も、どうぞこちらからお気軽にお問い合わせください。どうぞよろしくお願いします。