開発生産性を可視化するために、あえて「社内アンケート」をする理由

私は最近、社内で定期的な開発生産性アンケートをするようにしました (実際の作業は他の人に任せています)。本稿では、アンケートという古典的な手段に頼ることにした理由と、得られたものについてお伝えします。

なぜアンケートを取ることにしたのか

アンケートにはいくつも落とし穴があります。その落とし穴を避けるため、私たちはしばしばアンケートに頼らない指標を探すことがあります。

開発生産性チームの課題

ウォンテッドリーにはかつて DX (Developer Experience) チームという、開発生産性の向上を目的としたチームがありました。このチームが抱えていた課題は、その改善対象そのものにありました。つまり、「開発生産性」の可視化が困難だったのです。

Four Keys の問題

私たちは DevOps のベストプラクティスに従い Four Keys と呼ばれる指標の可視化を試みたり、これに関係するケイパビリティーをどうにか数値化できないか考えました。

そして、確かに数値を出すことはできました。しかし、これは私たちを満足させるものではありませんでした。

確かに、 Four Keys の定義に従うと、何かしらの数値を出すことはできます。しかし、それがDXチームの施策とどう結びついているのかが不明瞭なままでした。

計測値のS/N比

たとえば、CIを高速化すればデプロイの頻度に寄与するかもしれません。しかし、私たちの開発チームの規模(40名程度)では、実施中のプロジェクトの性質次第で、デプロイ頻度は大きく変わってしまいます。

こうした環境要因で生じる変化が、DXチームにとってはノイズとなってしまいます。つまり、チームの施策を評価するのに十分な相関を得られないのです。

良い先行指標を求めて

開発生産性をバイアスなく評価するために Four Keys や関連指標は重要です。しかし、これらは開発生産性向上の取り組みに直接使うのにはあまり向いていないと感じています。

いっぽうで、これから実施しようとしている施策そのものの行動量をそのまま計測したのでは、それは健全な自己評価とは言えないでしょう。

そこで私は、実施しようとしている施策の良し悪しに関する洞察を提供する、ほどよい先行指標が必要になると考えました。

アンケートを利用する

アンケートという調査方法には様々な落とし穴があります。私自身もこうした手法の専門家ではないため、得られた結果は無条件に信頼できるようなものにはならないでしょう。

それでも、アンケートを利用することには大きな利点があります。それは、「開発者自身の感覚」を観測可能な形にして出してくれることにあります。もし開発者自身が「開発生産性が向上している」と感じていれば、少なくとも施策の影響は開発者まで届いているというと推測できます。

さらに、開発者自身が自律的に判断できることで、「AI開発の生産性」や「BigQueryは使いやすいか」といった、個々のトピックに絞った評価を得ることができます。このようにトピック別に分解できれば、環境要因で指標が攪乱されにくくなることも期待できます。

アンケートの取り方

以上のような背景から、私はウォンテッドリーの開発組織をターゲットに、開発生産性アンケートを行うことにしました。

工夫したこと

現時点ではこの取り組みは組織の公的な仕組みには組み込まれておらず、あくまでも有志である DevOps guild が主導して行っている形です。そのため、このアンケートの回答は強制ではありません。

アンケートの負担が増えると、回答率が下がり、標本に偏りが出やすくなると考えられます。そこで、負担を抑えながら有益な結果を得るために、私は以下のようなアンケートを作ることにしました。

• 定点観測を主目的とするため、月1回のペースでアンケートを実施する。
• 定点観測を主目的とするため、同じ質問項目はなるべく変更しない。
• 負担を抑えるため、自由記述は全て任意とする。これは、定点観測の目的とも整合する。
• 負担を抑えるため、アンケート自身に自己最適化の仕組みを取り入れる。

自己最適化の仕組み

開発生産性アンケートを作るきっかけとなったDXチームは、アンケート開始時点ではもう存在しませんでした。

それでもこのアンケートを実施しようと考えたのは、生産性の改善は組織全体の課題だと考えていたからです。その課題に応じて、個人が改善に取り組むこともあれば、一時的に改善チームを組織することもありますが、何にせよ全員が参加者であるべきだと考えています。

そのため、開発生産性アンケートも、回答者である開発者一人一人が作っていくものであるのが望ましいと考えました。

以下が、実際に自己最適化のために用意している項目です。

アンケート実施担当者は、このアンケート結果をもとに、次の質問項目を増減させます。

アンケート結果の集計

アンケート結果は DevOps guild と呼ばれる会議体の定例で確認します。特にするべきアクションが決まっているわけではなく、この結果を共有して完了とします。

アンケートを実施してどうなったか

AI活用での利用

このアンケートは実際に以下のような形で活躍されています。

開発組織の全員が Devin と Cursor を活用するための取り組み | Wantedly Engineer Blog

こんにちは、AI Enabling Squad の @fohte です。この記事は夏のアドベントカレンダー 23 日目の記事です。ウォンテッドリーでは、開発時における生成 AI を活用してプロダ...

https://www.wantedly.com/companies/wantedly/post_articles/992908

アンケートを開始してすぐにわかったことは、開発組織内のAI活用に対する危機意識が高い水準にあることでした。これと時を同じくして AI Enabling Squad が結成され、AI活用が進められていきました。

そして、先ほど紹介した記事に書かれているように、開発生産性アンケートは AI Enabling Squad が開発者に与えた影響を非常にわかりやすく可視化することに成功しました。

もちろん、これはあくまでの開発者の主観を集計したものにすぎません。つまり、「開発生産性が向上した気分になっただけ」という可能性は否定されていません。しかし、少なくとも開発者一人一人が環境の変化を実感できる程度には施策が動いた、という評価ができることには大きな意味があると思っています。

社内ツール改善

AI改善の次に出てきたのが、社内ツール (Kubefork) の品質低下に対する不満でした。こうした内容もアンケートに反映され、意思決定に影響を与えていると考えられます。

今後の活用

AI活用と社内ツールの状況が改善したことで、開発生産性アンケートでは別の課題意識が目立つようになってきました。この課題も元々わかっていたものではありますが、こうして優先順位のヒントになる情報が出てくると行動の参考になります。

こうして、その時その時の課題を可視化し、評価するツールとして、開発生産性アンケートを続けていけたらと思っています。

なお、開発生産性アンケートの実際の運用は、 DevOps guild の会議体のメンバーに任せています。対応してくれている皆さんには、ここで感謝を表明したいと思います。

まとめ

• Four Keysは開発生産性を観測するための重要な指標だが、このような計測だけでは行動につなげにくい。
• ウォンテッドリーでは自己最適化する開発生産性アンケートを導入することで、意思決定に適したデータを手に入れることができた。
• もちろん、アンケートには多くの落とし穴があり、データの解釈には注意が必要であることに変わりはない。