Table of Contents
Open Table of Contents
はじめに
こんにちは。
様々なソフトウェア開発の現場において、開発生産性を高めるというトピックが常に関心の高いテーマとして議論されていると思います。
自動テストを整備することや、CI/CDによって継続的にリリースできるようにする、変更容易性の高いアーキテクチャを作るといった従来の実践的なプラクティスに加えて、 AIを開発プロセスに組み込んで実装や調査にかかる時間を短くすることも、最近ではその取り組みの一つとなっています。
こういった取り組みについて考えていると、そもそも何のために開発生産性を高めたいのか、というところに改めて注目して整理しておく必要があると思っています。
コードを速く書けるようになることと、事業として価値を生み出せるようになることは、そのまま同じではないんですよね。 同時に、生産性とは具体的に何を指すのか？ということも人によって捉え方が微妙に違ったりするので、きちんと整理しておく必要があります。
今回は、開発生産性を高めることが何につながるのか、そして開発チームの改善だけで十分なのか、ということについて、自分なりに考えを整理してみようと思います。
仮説検証サイクルを早める
例えば、外部システムと連携する機能を追加すれば新しい顧客を獲得できるのではないか、というアイデアがあったとします。 こういったアイデアに対して、数十年前までのやり方だと、顧客へのヒアリングや市場調査によって、ある程度の確度を高めて、数ヶ月・数年（！）かけて機能開発をする、という動きが一般的であったと思います。 ただ、実際に提供したときにどのくらい使ってもらえるのか、それが売上向上の決め手になるのかというところまで、当然ながら最初からすべて分かるわけではありません。
そうすると、最初に立てた計画をそのまま実現するだけではなくて、素早くデリバリーしてその結果から学び、その学びを次の開発に反映する必要があります。 仮説が正しそうであれば方針を維持してさらに開発を行う一方で、期待した結果が得られなければ、機能を見直したり別の課題に取り組んだりする必要があります。 この判断を行うまでに半年かかるのか、一か月で行えるのかによって、その後に取れる選択肢はかなり変わりますよね。
開発生産性を高めることの大きな意味は、こうした仮説検証をより短いサイクルで繰り返せるようになることだと考えています。 単に決められたものを速く作るというだけでなく、作って得られた学びに応じて次に作るものを変えられる状態を目指すことが重要です。
たくさんリリースすれば成果が出るのか
ここで、開発のデリバリー能力と事業の成果は分けて考える必要があります。
例えば、毎週10個の機能をリリースしているチームがあったとします。ただ、その機能が使われているのか、顧客の課題を解決できているのかは確認していません。 一方で、毎週2個の機能をリリースし、それぞれの利用状況や顧客の反応を確認しながら、継続的に事業指標を改善しているチームがあったとします。
この場合、リリースした機能の数だけを見れば、前者の方が生産性が高いように見えるかもしれません。 ただ、自分は後者のように、作った結果として何が変わったのかを確認できていることが重要だと思っています。
もちろん、機能の数だけで開発能力を比較できるわけでもなくて、機能ごとに規模も難しさも違いますし、障害を減らすための改善のように、新機能として数えられない仕事もあります。 ただこの例で考えるべき本質的な部分としては、アウトプットが増えたことと、アウトカムが増えたことは別だということです。
機能のリリース → 顧客に価値を届けることができ継続して使ってもらえるようになる → 契約の継続や売上につながる
上記のようなフローでしっかり見ていく必要があります。
ただし、開発生産性を高めたからといって、必ず売上や利益が増えるわけではありません。検証した結果、そもそもそのアイデアには期待した価値がなかったと分かることもあります。 それでも、価値がないと早く分かれば、それ以上の投資を止めて別の可能性を探せます。
以上を踏まえると、開発生産性の向上は事業成果を保証するものではなく、事業成果を生み出せる可能性を高めるための投資として必要だと思います。
物的生産性と付加価値生産性
この話を整理するうえで、物的生産性と付加価値生産性という二つの観点が出てきます。
物的生産性は、投入した資源に対して、どれだけの量を生み出せたかという観点です。 一方で付加価値生産性は、その資源を使って、どれだけの付加価値を生み出せたかという観点になります。
ここで重要なポイントは、ソフトウェアの場合はそもそも生産量を何で測るのかが難しいんですよね。 コードの行数が多ければよいわけでは当然ありません、むしろ、不要なコードを削除したことで、変更しやすくなる側面もあります。機能の数も、先ほど触れた通り、そのまま比較できるものではありません。
なので開発チームとしては、生産量だけでなく、変更をどれだけ短い時間で安全に届けられるかというデリバリー性能を見る必要があります。
例えば、実装が終わってからリリースするまでに、どこで待ち時間が発生しているのか。変更するたびに、どのくらいの手作業で確認しているのか。障害が起きたときに元の状態へ戻せるのか。 こういったところは、開発チームが改善に取り組みやすい部分です。
一方で、その能力を使って何を作るべきか、作ったものがどのくらいの価値を生むかは、開発チームの中だけでは残念ながら決まりません。 顧客の課題を理解すること、事業として優先順位を決めること、実際に利用してもらい結果を確認することまで必要になります。
だからこそ、自分たちで改善できる開発能力を高めながら、その能力を事業成果につなげるための連携も考えなければいけません。
開発生産性と価値創造の関係については、吉羽龍太郎さんの講演資料「価値創造と開発生産性」でも詳しく整理されています。何のために生産性を高めるのかを考えるうえで非常に良い資料ですので、こちらも参照してみてください。
AIで実装が速くなったら何が変わる？
コードの生成やテストの作成、既存コードの調査にAIを活用することで、個々の作業にかかる時間を短くすることは、開発能力を高めるための重要な取り組みです。 AIの力を適切に生産性へと還元するためには、AIに何を伝える必要があるのかを整理し、必要な設計上の判断や制約を参照できるようにしておくことが重要になります。いわゆるコンテキストエンジニアリングの考え方ですね。
また、変更の影響を確かめる自動テストや、小さくリリースできるCI/CDといった、従来からのプラクティスの重要性も変わりません。
例えば、StrongDMの「The StrongDM Software Factory: Building Software with AI」では、人間が仕様や制約を定め、AIエージェントがコード生成から検証、改善まで進めるソフトウェアファクトリーの事例が紹介されています。
ただ、そこまで整えたとしても、作るべきものの判断や、作った結果の検証が止まっていれば、事業としての仮説検証は速くなりません。
開発が速くなるとコミュニケーションが更なるボトルネックになる
例えば、機能を数日で実装できても、部署間の調整や承認に数週間かかり、リリース後の顧客の反応も届かなければ、仮説検証は速くなりません。 開発が速くなるほど、こうしたコミュニケーションの停滞がボトルネックになります。
また、組織がサイロ化し、ビジネスサイドが知る顧客の課題と、開発チームが持つ技術的な知識が共有されなければ、より小さな変更で検証する方法も見つけにくくなります。 仕様を受け渡すだけでは、既存機能を少し変えれば済む課題に、大きな機能を作ってしまうかもしれません。
つまり、コミュニケーションは、待ち時間だけでなく、何をどの大きさで検証するかという判断にも影響し、開発サイクル全体のボトルネックとなります。
仮説検証を一緒に進められる体制を作る
こういった問題に向き合ううえで、Team TopologiesやDevOpsのように、チーム間の関係や協働のあり方を考える視点は重要だと思っています。 自分たちの組織で情報や意思決定がどこで止まっているのかを確認し、チームの役割や承認の流れを見直す必要があります。
そのうえで、ビジネスサイドと開発が顧客の課題や事業目標を共有し、最小限の変更で仮説を検証する。結果を一緒に確認して、次の判断につなげるところまで協働したいわけです。
必要な確認は残しつつ、慣習で生まれている待ち時間を減らす。開発チーム単体の生産性だけでなく、企業全体として仮説検証を速く回せる状態を作ることが重要だと考えています。
終わりに
開発生産性を高めることで、変更をより短い時間で届けられるようになる。その結果、市場や顧客から学び、次の判断を行うまでの時間を短くできる。 この流れが非常に重要です。
なので、自動テストやCI/CD、アーキテクチャの改善、AIの活用には取り組んでいきたいですし、それによって得られた開発能力を、きちんと事業の中で使える状態にしていく必要がある。 そのためには、開発の中にあるボトルネックだけでなく、部署間の調整や意思決定、顧客から学ぶプロセスまで見る必要があります。
開発生産性の改善を考えるときには、そこまでつなげて考えていくことが重要だと思います。