はじめに
こんにちは！BASE株式会社で開発担当役員をしているえふしんです。
今年もBASEグループ 2024年のアドベントカレンダーのトップバッターを務めさせてもらっています。
今回の記事では、2024年では、Xのタイムラインなどでよく聞いた「開発生産性」について考えてみたいと思います。
開発生産性を高めるとは
開発生産性という言葉を今年よく聞きましたが、その定義は、なかなか難解です。
生産性を定義する難しさについては、廣木さんの下記ドキュメントが参考になります。
経営レベルのマクロな意味であれば、GDPなどと同様に単純に
「売上総利益 ÷ 開発に携わる人数」
などでいいはずです。単純に、そのプロダクトの成果としての売上総利益や営業利益に対して、人数で割って見ておけば、過剰人員になった場合はこの値が落ちるわけですから、コスト的に効率の良い製品開発かは測ることがしやすいです。
一方で、開発チームで考えたいと思うのは、開発という行為に対して、我々の開発活動のあり方が今のままでいいのかそうでないのかを推し量る指標のことで、いろんなものが提案されていますが、何かを妥協して決めつけていかないと万能な指標はでないというのが定説です。また、開発という投資に対する遅行指標である売上総利益を待ってたらもう遅いです。
世間ではFour Keysが定番化しているようですが、ちょっとDevOps寄りすぎるというか、自分がイメージしている改善のアクションへの接続がちょっと難しそうだなと思って、活用自体はポジティブですが、もう少し納得できるように考えたいと思いました。
そもそも自動車の生産ラインのように一つの生産ラインで同じ類の製品をひたすら量産して、一定のものさしを前提としている仕事とは違って、一品一様で二度も同じコードを作らないWebサービスのソフトウエアの開発活動をなんらかしらの指標で平準化して求めようなんてのは難しい話です。
個人的には目標値として一切、置かない形で、デプロイ頻度を見ておくことがチームの活気を示すという意味ではありかなと思うぐらいで、間違っても、LL言語やオープンソースライブラリ、コード補完エディタに依存してるプロダクトがソースコード量を生産性指標にするのは違うと思いますし、案件難易度がプロジェクトごとに違うのにスプリントやバックログの数を複数チーム間での比較指標にするのも違うかなと思います。むしろ目的達成に対して変更するソースコード量の少なさを測りたいくらいです（いや、それも違うと思うが、更新するWebサービスにおける理想はむしろそっちかと思いますし、知識労働者がコード量だけで測られるのはおかしい話）。
指標化というのはカジュアルにやってしまいがちですが、不適切な指標化は人間の行動をミスリードすることがあります。そんな簡単なものではないと思えばこそ、慎重に考えたいものです。それこそ、馬のおしりをムチで叩くようなマネジメントなどになってしまったら、知識労働者であるソフトウエアエンジニアがその状況に我慢できるハズはありません。脳内がポジティブでなければ、適切にソースコードが生み出せないので、生産性云々以前の話です。
そもそも何のために継続的に開発をやっているのか？といえば、ユーザーに価値を届け、ユーザがなんらかしらのメリットを獲得し、その成果としてのビジネス指標が改善され、我々のビジネスの成長につながることを実現するということです。
つまり重要なのは「何回、ユーザさんに「いい変更だね！」という評価を受けたか？」という回数にあると思います。そのためには告知を含めた機能リリースや改善リリースの数を増やすということがプロダクト開発がやりたいことで、その中から成功確率を上げていくというのは、ビジネス全体視点での提供品質の話になります。
なので、プロダクト開発視点では「ユーザさんが知るリリース数を増やす」「トライの数を増やす」ということを「アウトプット量の増加」＝ 「結果としての生産性の向上をもたらす取り組み」に着目できたらと思っています。測定ツールとしては、品質指標や集計のことを考えて、まるっとFour Keysの利用でいい気がしてますが、重要なのはユーザインパクトをもたらすことを目指したトライの数を意識することです。
たとえソースコード１行でも迅速に素晴らしい改善をしてユーザの感動を得れば、それは「有益だった１トライ」だと思いますし、大きい機能開発で大きなインパクトを得ることも重要なことです。
トライの数を増やすために必要なこと
個人的に継続開発するWebサービスの開発生産性に対する考え方として個人的に好みなのは、牛尾 剛さんという米国マイクロソフトで働かれている方の著書「世界一流エンジニアの思考法」に書かれている、
生産性とはいかに「レベル１（ = 何もググらずに実装できる）」を増やすかどうかではないか？
という文章にジワジワ来ました。
つまり人間のアウトプットを計測した数字の多寡を重視するアプローチではなく、能力に着目した考え方です。なお、牛尾さんの本では、このことが生産性の高さの指標だと書いてるわけではなくて、そのような能力を獲得することが重要なのではないか？という形で書かれています。
めちゃめちゃわかりやすく、いい感じに煽られてると思いませんか？
そう言われてみれば、社内で一番望ましい開発能力というのは、いわゆる汎用的な地頭の良さである仕様理解力に加えて、
- 大まかにソースコードを把握していて、どこをいじれば望み通りの結果が出るかを如何に素早く見積もりできて、見積もり通りに実現できること
ではないかと思いました。正確には案件仕様と現場の仕様をかけあわせて、何をどこまでやるべきかについて正しい見積もりと脳内設計をして、適切にアウトプットできる人が一番確実な仕事ができるはずです。CTOへの仕様レビューも、さくっと口頭でやれてしまうのが望ましい（それだけの信頼と実績があることも含め）。
開発言語や開発ライブラリの知識はもちろんですが、自分たちのソースコードを掌握している人が一番、仕事の対応速度は早いと考えられます。同じだけの設計能力があるなら知識量が多い方が仕事が早い可能性が高いです。
そもそも、開発生産性に対する社内議論が出てきたのは、自分たちのプロダクトが、新入社員では簡単には把握できないほど大きくなってしまったと言われ始めた頃と符号します。もっと会社が小さかった頃の創業当初のメンバーは、今よりも少ないソースコードを把握していて、おそらく生産性という面では、一番そのころが早かったのでしょう。新しい機能の話が出てきても、話を聞きながら大まかの設計は完了していて、あの辺とこの辺を直せばいいと思っていて、即座に開発作業に取り組んでいました。
しかし、昨今の中途採用や業務委託の方による一定の人の出入りを前提とした組織において、ソースコードやサービスの仕様を知るというオーバーヘッドと、コード量やプロジェクト量の増加に伴う把握のしにくさが、開発者の作業性のオーバーヘッドにつながっていったと考えると、極論すると、全部のソースコードを把握していて、頭の中で整理してくれるような脳内のLLMを保有しているエンジニアが、結果として、一番、速やかに実装できると考えることが可能です。
ちゃんと改善を前提とした時に、エンジニア個々人のスキル評価にあわせることができれば、エンジニアの評価を上げる ＝ エンジニアのグレード（給料）が上がる ＝ 生産性が上がるはずです。機能リリースが増えて、ユーザー評価を受けるためのトライの数が増えたのに「売上総利益 ÷ 開発に携わる人数」が改善しなければ、それ以外の何かが間違ってるって話になり、根本から見直す必要があるでしょう。
トライを増やすための「オーナーシップ」と「脳内LLMへのインプット」
内製開発におけるエンジニアの能力を「何もググらずに実装できるレベルのこと」に置いたと仮定します。もちろん何もググらずというのは、かなりの理想の話で、Google検索したって、社内ドキュメントを調べても良いのですが、それらの行動と理解速度が最速で作業を進められるようになることを意識することが大事です。
これをもう少し抽象化し、このような状態を「ソースコードのオーナーシップ」を持っている状態と表現してもいいかもしれません。そして、同時に複数人が同じリポジトリのソースコードをいじってるわけですから、毎日、どこかしらの新しいソースコードが生成されると考えると、これはstaticな記憶力のことではなく、コードリーディングを通じて人間の動的に脳に備わっているLLM（人間の知力）が再構築できる能力ということになります。
また、エンジニアの能力をあげていくことを前提として、それを阻害する要素を取り除くことも重要な取り組みです。この場合は、アウトプットに着目するよりも、エンジニアへのインプットの最適化を考えるアプローチになると思います。こちらの方が、ふわっとアウトプットの量を高めようとするよりは、具体的な施策に落ちてきそうな気がしてきませんか？
例えば、議論や会議の質を高めるであるとか、オンボーディングの改善、ドキュメントの整理の最速化、リファクタリング、更新情報の共有の仕方などが挙げられます。BASEのリアーキテクチャで取り組んでいるclean architecture化（バックエンドリポジトリ）への貢献もオーナーシップ化を促す活動とも言えます。コードを大きく書き換えるタイミングは、オーナーシップ獲得のチャンスです。また、如何に、最少人数、最小構成でリスクを伴った意思決定を最速にできるかというのも重要になってきます。
当社のCTOは、チームメンバーが増えた今もリリースされているプルリクを把握してると聞いてますが、脳内LLMのインデックスを更新する作業を自然にやっているのは素直にすごいと思います。普段、プロジェクトに関わってなくてもコードリーディングを通じて、プロダクトに何が起きてるかを把握し続けているわけです。
なお、ChatGPTなどの生成AIなどの取り組みについても触れておきますと、人間の記憶力は揮発性ですし、年齢や体調によっても脳の力の活用度は変わってきます。ただ単に人間の記憶力だけに頼るのは芸がありません。人間としてのスキルだけでなく、検索や生成AIの活用などで外部記憶を効率よく人間の脳内LLMと連結することができれば、とても生産的なAIに対する向き合い方もできると思います。プロンプトに仕様を書いてコード生成されるだけのAIの利用はイマイチだと思っていますが、人間の理解や意思決定を支援するAIというのであれば歓迎です。開発エディタへのAI支援機能の搭載やNotion AIの活用など開発環境も進化していきますから、AIに対する老害にならず、しっかり取り入れていきましょう。
マネージャが意識しないといけないこと
マネジメントラインにおいても、現実的に中途採用、転職、社員、業務委託などの属性を考えて、かつ、エンジニアの成長曲線とグレード評価に必要な時間などを勘案すると、現状の我々が構成しうる、チームメンバーのグレード構成の布陣というのは、一定の範囲を取るはずです。
要は退職が増えて、代わりに入っていただいた新人が増えれば、コードの知識、ドメイン知識がないのは当然だから、学びのリードタイムが必要になり、その時点のチームの人材ポートフォリオは弱くなるでしょうし、経験者が長く働いてスキルが向上していけば、給与もあがって、チームメンバーのグレード構成も高いからこそ、高い生産性で開発プロジェクトをこなしていけるというのは、自分で書いても実感のあるところもあります。
つまり開発生産性の高みを目指すというのは、チームマネージャが望む人材ポートフォリオを、状況にあわせて構成することで、高い生産性を発揮できるチームを作ることに邁進することそのものではないかと思いました。新規事業やM&Aなどでも組織が拡張されていくので動的な概念です。常にチームはアメーバのように分裂したりして増加減可能なことが大前提です。BASEグループのカルチャーが組織の増加スピードと人員移動に対して適切に平準化したりお互いに相乗効果を生み出し続けることも大事です。
マネージャは自分を城を作るという考え方ではなく、会社全体の開発力を上げて、よいアウトプットを生み出す状況を作り続けるのが仕事です。その際にチャンスを得て適切にソフトウエアエンジニアとしての信頼を評価に結びつけていくためにも、メンバーと日常のコミュニケーションを取ってほしいと思います。
人間は機械じゃないので、安定したアウトプット量を出すことでさえ大変だと思いますが、生成AIがどれだけ進化したとしても最後の決断は人間が下し続けると思いますので、最適、最速な意思決定をして、適切なリスクにチャレンジするためにメンバーのスキルを上げ続けることになると思います。ちなみに、適切なリスクとは「基本は無茶をする」です。意思決定の際に無難な方と無茶な方の２つの選択肢があったとしたら、無茶をした側の意思決定じゃないと、プロダクトは成功しないです。でも、できないことを部下にやらせるわけにはいかないと思いますので、ちゃんと実現できるように頑張ってください。
おわりに
なお、開発だけの話を書いているように見えるかもしれませんが、当然、開発プロジェクトは開発チーム、ビジネスチーム、プロダクトマネージャやデザイナーが渾然一体となってスケジュールタイムラインを成すので、すべてのチームにおける考慮は不可欠です。オーナーシップという視点でも、それぞれが、ビジネスのオーナーシップ、プロダクトのオーナーシップ、プロジェクトのオーナーシップ、UXのオーナーシップなどを適切に発揮できているかは最重要な確認事項とも言えます。
特に、各々がリスクを伴った意思決定を増やし、失敗を恐れず、朝令暮改も上等という考え方で、チーム間のトライも増やしてく。そのための心理的安全性の構築などが重要です。
改善においても適切なリスクの取り方、意思決定のあり方、リモートワークとリアルmtgの使い方、会議の質の向上など要素は多岐に渡りますが、トータルで言うサービス開発の生産性を阻害するものを効率化しつつ、それぞれの役割のスキルを向上させていくことで、トライを増やし、アウトプットの総量は増えていくのではないでしょうか。来年はこのことについて、一つ一つ考えていけたらいいなと思っています。
現在、2025年に向けた人員計画を立てている真っ最中ですが、引き続き採用活動をすると思いますので、以下の採用情報ページからマッチする求人があるかを見ていただけると幸いです。
明日のアドベントカレンダーは @Panda_Program さんの「「読書会のジレンマ」を克服する: 成果を生むアクティブラーニング勉強会の実践法」です！お楽しみに！
