はじめに
2023年11月28日に汐留で開催された 「開発生産性の未来：世界と日本の最前線事例から培うFour Keys向上〜ハイブリッドカンファレンス〜] の感想を以下にまとめる。
開発生産性の未来：世界と日本の最前線事例から培うFour Keys向上〜ハイブリッドカンファレンス〜
「Findy Team+ Award 2023」受賞企業の中から、多様なテーマで、"開発生産性向上を実現した具体的な事例"を集め、エンジニア組織づくりや、開発生産性や開発者体験の向上に向けた最先端のベストプラクティスが得られるカンファレンスである。
感想
まず「開発生産性」という言葉について、
本カンファレンスに参加するまではぼーんやりと「まあ、開発の生産性（スピードとか質とか、）」くらいの理解でしかなかった。
ただ、様々な企業やチームの開発生産性の定義を聞き、なんとなく「開発生産性」という言葉における解像度は上がった。また、開発生産性は企業やチーム、さらには経営層、マネージャー層、エンジニア層といったレイヤー毎で異なり、定量的に定義していくことが多いということを学んだ。
その中でも私の立場的に最も近しく感じた開発生産性の定義は、株式会社モリサワさんの公演の中にあった「プルリクの数」である。
また、その公演の中で出た「ハックをするのは自由」という言葉が個人的にかなり印象的だった。
、、、。どういうことか、少し詳しく説明する。株式会社モリサワさんのプロダクトチームの中にある職能型チームでは、プルリク数をKPIとして設定している。そしてこのKPIの目安は「1人1日1プルリク」だそう。つまり、このKPIのプルリク数をハックしたかったらご自由にどうぞ、というスタンスを株式会社モリサワさんはとっているということだ。
「え、それってKPIとして成り立つの、、」と最初は困惑した。
確かに「1人1日1プルリク」としてKPIを設定することで、達成に向けた指針も立てやすいし、達成しているか否かも誰の目から見ても一目瞭然でわかる。
ただ、ハックが可能であることを考えると、作ったものの量やスピードばかりにフォーカスして、実際に生み出した価値とか、顧客の満足度への関心が薄れてしまうのではないかと思った。
（ちなみにこのように、組織がアウトカムではなくアウトプットで成功を計測しようとして行き詰まる状況を、「ビルドトラップ」というそう。）
これに対し株式会社モリサワさんの答えはこうだ。
「プルリク数を増やすには課題を分割する必要があり、結果的にレビューアーの負担も減るというメリットがある。また、この施策を行った結果、非効率で意味のないプルリクが増えることはなかった。」
「たーしかに。」と思った。
「1人1日1プルリク」というKPIがあったらどうにかして1日で終わる量にスプリットしようという癖がつくし、日を跨がないので効率的、モリサワさんがおっしゃる通りレビューの負担が減る、結果的に生産性向上に寄与している。
私も実際の現場で実感することがあるので納得したし、開発生産性の向上に繋がるのは理解した。
ただ、やはりそれだけだと本質的なアウトカムに繋がるのか、と少し疑問は残る。
そこで私が思うのは、やはりチームメンバー1人1人の意識が重要になってくるのだと思う。
株式会社ZOZOさんの公演ではこのようなことを仰っていた。
「開発生産性を上げることは目的ではなく、ユーザーに届ける価値を大きくすることの目標である。」
結局このマインドをチームのメンバー1人1人が常に意識していることが肝なのかなと感じたし、自分の中ではかなり合点がいった。
おわりに
本カンファレンスへの参加を通じて、率直な意見を言うと、エンジニア歴1年の私からすると、組織のあり方、開発生産性の捉え方、みたいな話が大半で、自分が実践するには少し早いかなー、と感じたというのが率直な感想ではある。
ただその中でも、上に述べたような、開発生産性を意識しすぎてユーザーの満足度や感動への意識が疎かになる、というのは、最近ようやく少しJavaが書けるようになってきて、コードを書くのに精一杯な私からすると、次のステップへ進むために重要なことなのかなと感じる。
ロボットのようにPOからの要件通りにチケットを切って、デプロイしていくだけでなく、果たしてユーザーは何に関心があるのか、何に感動するのか、ということを意識しながらサービスを作っていく必要があると感じた。
そうすることでビジネスサイドの思考を持った、POと深い議論を交わせる、より強いエンジニアになれる気がする。頑張ろう。