定量的な測定では開発者の生産性は向上しない！──「手助け」に焦点を当てた発想転換とは？
オーストラリアのシドニーに本社を構え、「Jira」をはじめとするさまざまなソフトウェア開発者向けツールを開発・提供するアトラシアン。同社には1万1000人以上の従業員が所属しており、「Team Anywhere」という大方針の下、オフィスや自宅など好きな場所でリモートワークをすることができる。
また同社の従業員の約半数は開発者が占めており、よって開発者の生産性がサービス品質や企業収益に直結する。そのためこれまで開発者の生産性を高めるためのさまざまな施策を講じてきたが、皆川氏によればその取り組み内容は世に言う一般的な「生産性向上」とは一線を画してきたという。
「開発者の生産性は大抵の場合、『どのようにして生産性を測定するか？』という文脈の下で語られます。具体的には『書いたコードの量』『プルリクエストの数』『コードレビューの数』などのKPIを用いて定量的に計測しようと試みられてきました。しかし、開発者の方にとってはどれも的外れのように感じられるのではないでしょうか」
コードの行数やレビュー数がいくら多くても、それらの品質が悪ければ結果的に生産性は低下してしまう。そのためこうしたKPIを測定するだけでは、実質的な生産性向上は見込めないというのが、同社が至った結論だったという。
そこで皆川氏は「発想を変えてみましょう」と提案する。
「『どのように開発者の生産性を測定するか』という課題設定がそもそも間違っていました。そうではなく、『どのようにして開発者の生産性を高める手助けができるか』というふうにマネジメント層の発想を転換することが重要です」
開発者が情熱を持って仕事に取り組むために必要な「Developer Joy」とは？
ここで皆川氏は、開発者の仕事を画家に例えて説明する。
「自社のオフィスで、来客の目に留まる場所に飾る絵の制作を、とある著名な画家に依頼したとしましょう。その絵を描くためにやってきた画家がキャンバスを取り出したところ、あなたはこう言わざるを得ませんでした。『すいません、我が社のポリシーで絵はキャンバスではなく紙に描くことになっているんです……』」
その後も画家が絵の具を取り出そうとすると「我が社のポリシーに従って絵の具ではなくクレヨンを使ってください」、イーゼルを設置しようとすると「イーゼルを使わず、会議室のテーブルで描いてください」。こうしてさまざまな縛りを設けた結果、最終的に画家はやる気を失って何も言葉を発しなくなる。そして締切が迫ってくると、今度は画家の仕事ぶりを監視するために部屋に監視カメラを設置。その結果、最終的に完成した絵画は悲惨な出来に……。
「同じようなことを、開発者に対しても行ってはいないでしょうか？」と皆川氏は問う。膨大な数の開発者を抱え、かつ世界中の開発者に向けて有益なツールを提供し続けているアトラシアンですら、かつてはこのような状態に陥りかけていたという。
開発者は画家やアーティストと同様に、高い専門性と技術を駆使して作品を作り上げ、世の中やコミュニティの発展に寄与することを願う「職人」だ。よって先ほど挙げた画家の例のように情熱をもって仕事をするための環境を奪われてしまうと、一気にモチベーションを失ってしまう。
そこで開発者の生産性を考える上で最も重視すべきなのは「Developer Joy」、つまり「開発者にとっての喜び」であるとの結論に、同社は至ったという。
「どうやったら開発者が情熱をもって仕事に取り組めるのか。これを追求していった結果、副産物として得られるのが開発生産性の向上であると理解しています。そのため弊社では、『開発者の働き方の中に価値を見出し、それを還元していくこと』こそが開発者の生産性であると定義しています」
開発者にとっての喜び「Developer Joy」を構成する2つの要素
ただし同社でも、こうした洞察に至るまでには紆余曲折があったという。同社がDeveloper Joyの向上に本格的に取り組むようになったきっかけは、約2年前に実施した社内アンケート調査だった。社員数が急増していた時期に「開発者の満足度」についてアンケート調査を実施したところ、「満足している」と答えた社員が半数を割ってしまった。
この結果にショックを受けた同社の経営陣は、早速その改善に乗り出した。大規模なサーベイやインタビューを実施して現場の声を拾い集めた結果、「多すぎる“摩擦”」「自律性の欠如」「コードを壊してしまうことへの恐れ」といったさまざまな要因によって、Developer Joyが損なわれていることが分かった。
こうして収集した開発現場の声を基に、Developer Joyを構成する要素について考察を重ねた結果、最終的に「Developer Experience（DevEx）」と「Engineering Culture」の2つが重要であるとの結論に至ったという。
Developer Experience（DevEx）とはその名の通り、開発者が日々の開発業務を行う上での「開発者体験」のことを指す。このDevExは開発業務で利用されるツールやフレームワーク、プラットフォームなどの充実ぶりに大きく左右されるが、ここで重視すべきは「ツールが揃っているかどうか」ではなく、そのツールについて「開発者がどう感じているか」であると皆川氏は力説する。
「ツールに対して開発者が不満を持っている状態が続くと、Developer Joyは決して高まりません。そこで現状のツールやフレームワークについて開発者が主観的にどう感じているか、定期的に開発現場の声を集めてツールの見直しや追加を行い、場合によっては自分たちでツールを自作するなどしています」
またEngineering Culture、つまりエンジニアリングの「文化」を醸成することも極めて重要だ。その組織の価値観や仕事の進め方、規範、意思決定の在り方などの要素を融合させることで、Developer Joyを高められる組織文化が形成されるという。
「私自身の開発者としての経験を踏まえても、日本企業はこのEngineering Cultureの部分が弱いと感じています。開発者同士で共通の価値観やストーリーを共有できないと、『何のためにこのソフトウェアを作っているのだろう』と疑心暗鬼になってしまい、自ずとDeveloper Joyも低下してしまいます」
Developer Joy向上への旅──開発者が楽しく働ける環境づくりの3ステップ施策とは？
同社ではDevExを高めるために、まずは現状の可視化を行ったという。現場の開発者がDevExの現状についてどう感じているか、直接ヒアリングを行った。また開発者の人数が増えすぎて直接のヒアリングが困難になった後は、計画的なサーベイを実施して現場の声を集めた。
さらには個人レベルだけではなく、チームレベルで抱えている課題を拾い集めて、チームの健康状態もチェックした。そのために開発者体験プラットフォームツール「Compass」を開発・運用し、これを通じて各チームで「うまくいっていること」「課題になっていること」をメンバーに1週間おきに入力してもらうようにしたそうだ。
またDevEx向上の取り組みを自主活動とはせず、そのための専任チームを設けた。このチームが主体となり、サーベイの実施やその結果の評価、先ほど紹介したようなCompassを通じたさまざまな仕掛けや内部サービスの開発など、DevEx向上のために必要なあらゆる取り組みを推進している。
その結果、同社は現在「DevExプラットフォーム」と呼ばれる仕組みを構築・運用している。開発に必要なあらゆる情報やツールをCompass上に集約し、開発者が情報や環境を探す手間や時間を省くことでより快適な開発体験を提供しているという。また必要に応じて、開発者がプラットフォームに機能を追加するなど、既存ツールと連携するための仕組みも提供している。
こうした取り組みを進めていった結果、現在では「開発者の満足度」も70％という高い水準を達成できているという。ただしこれでもまだ、同社のDevEx向上の取り組みは「道半ばだ」と皆川氏は語る。
「Developer Joy向上の取り組みは、終わりのない長い冒険の旅のようなものです。しかし、開発者が生き生きと働ける環境を作り上げる過程は実に楽しいものですから、ぜひ1人でも多くの開発マネジャーの方に、その旅を体験していただければと思います」
