「うちの開発、遅くないか？」──定義なき重圧が生む誤解のはじまり
合同会社DMM.comでプラットフォーム開発本部 副本部長を務め、全社的なAI推進も担う石垣雅人氏は、7月21日に翔泳社から発売された著書『誤解だらけの開発生産性』を引き合いに出しながら、開発生産性をめぐる誤解と重圧について語った。
書籍『誤解だらけの開発生産性』のストーリー
『誤解だらけの開発生産性』（石垣雅人 著、翔泳社）は、中小企業向けSaaSを開発する架空の企業を舞台にした物語だ。「うちの開発、もう少し早くならないか」。上司からそう問われた新米チームリーダーの湊太郎は、開発生産性という言葉の重圧に振り回される。要件は揺れ、技術的負債は積み上がり、QAやサポートからの声も押し寄せる。湊はプロダクトマネージャーやテックリード、QA、事業責任者と向き合いながら、開発生産性という言葉の輪郭を自分なりに掴み直し、やがてチームだけでなく組織を動かすリーダーへと変わっていく。本セッションは、このストーリーを引き合いに出しながら語られた。
同書は、部長からの「うちって開発遅くないか？」といういきなりの感覚的な問いから始まる。開発組織に課題があるとなった時、開発生産性という言葉は便利に使われるようになった。2020年あたりから使われ始め、バズワード的に広まったこの言葉は、言われる側にとって次第に居心地の悪いものになっていったと石垣氏は振り返る。
その居心地の悪さの正体は、開発生産性という言葉が持つ構造的な問題にある。何が問題で、何を測るのか。エンジニア、デザイナー、PM、事業責任者、経営者といったレイヤーごとにその認識が揃わないまま、イメージだけで語られてしまう。石垣氏は、開発生産性の議論には「外発的動機」と「内発的動機」の二つがあると整理する。
自分たちの成長のため、ユーザーに価値を早く届けたいという内発的動機であれば健全だが、世の中の多くの現場では、事業責任者やマネージャーから「開発が遅いから測ろう」という外発的な監視・管理の意味合いで生産性が測られてしまう。これはアンチパターンだと石垣氏は言う。
信頼が積み上がれば、開発生産性は話題に上がらない
本来、開発生産性が外発的な動機で問われる時、そこにあるべきなのは信頼だ。
「この機能を来月までにリリースする」というコミットメントが守られ続ければ、事業責任者からわざわざ開発生産性を問われることはない。逆に、その約束がずれ始めた瞬間から信頼は崩れていく。石垣氏はここに、開発生産性の議論の本質があると指摘する。
もう一つの構造的なずれが、改善の体感と経営が求める数字との時間差だ。現場の「速くなった実感」は先に現れるが、経営が求める売上や利益の改善という数字は、最終結果としてしか、それもあとからしか見えてこない。この先行指標と遅行指標のずれを体感として理解しておく必要があるという。
そしてスピード重視の代償は、技術的な裏付けを持って語られる。「大枠で進めて」という判断は計画が柔軟なのではなく、修正コストを後工程に先送りしているだけだ。NISTの調査によれば、欠陥の修正コストは要件定義の段階を1倍とすると、コーディング・単体テストの段階で5倍、結合・システムテストで10倍、リリース後には30倍にまで膨らむ。マーティン・ファウラーが論じるように、内部品質を軽視して削った時間は、数週間から1カ月ほどで障害対応という利息をともなって返ってくる。
ソフトウェアには変更できない「本質的複雑性」と、設計や実装で減らせる「偶有的複雑性」があるとフレデリック・ブルックスは説いたが、AIによって後者を扱う速度が上がったとしても、本質に向き合わなければ改善効果は長続きしない。DORAやFour Keys、SPACEといった指標も、TOCやCCPMが扱うプロジェクト全体の制約も、結局は開発リードタイムのごく一部でしかない。
ここまでは、まだ「測れる」領域の話だ。本当に重圧となるのは、測れない生産性を求められる場面だと石垣氏は続ける。
