シェア
はてブ
2024年6月28、29日に「開発生産性Conference2024」がファインディ株式会社により開催されました。
29日に登壇したDMM.comの第1開発部 部長である石垣雅人さんは、「開発生産性のプラクティスはコモディティ化している」と言います。ところが、わかっていても実行できない、必要だけど予算が取れない、といったケースがあり、壁を乗り越えるためには投資対効果を明確にしたり、説明責任を果たす必要があります。本セッションではそうした関係各所を巻き込んで推進していくためのDMM.comの取り組みをご紹介いただきました。
■プロフィール
石垣雅人（いしがき まさと）
合同会社DMM.com
プラットフォーム開発本部 第1開発部 部長 / VPoE室 / アルファ室
DMM.comにエンジニア職で新卒入社し、翌年からプロジェクトマネージャー。いくつかのプロダクトマネージャーを経て2020年、DMM.comの入り口である総合トップなどを管轄する総合トップ開発部の立ち上げを行い、部長を従事。現在は、DMMポイントクラブサービスの立ち上げからグロース、DMM.comの4,507万人(2024年2月時点)会員のID基盤・個人情報を管轄する開発部の部長、DMM全体のエンジニア・デザイナー・PM組織の組織課題を解決するVPoE室 / アルファ室を兼務している。著書に『DMM.comを支えるデータ駆動戦略』（マイナビ出版）。連載に『開発生産性の多角的視点』（CodeZine）、『スモールチームが武器になる時代へ』（ProductZine）、『群知能から紐解く、スケールする“組織”の作り方』（NewsPicks）など。
「開発生産性を上げる改善」を実行に移せる現場を増やしていくために
石垣：今日は少しシビアな話で、「開発生産性を上げる改善って儲かるのか」という質問にエンジニア自身が答えるための話をします。副題は「“信頼”と”儲かる”を実現する開発生産性の改善」としています。
私はDMM.comで部長職をしております。予算を使いながら事業の戦略を考えているため、事業責任者が考えるべき目線で説明していきます。
DMMでは、クリエイター組織と呼ばれている、いわゆる開発をする人、つまりエンジニア・デザイナーが1200～1300名ほどおります。チーム数は200ほどあるので、ある程度規模が大きい組織での考え方をお伝えできればと思います。
最近、「開発生産性の改善」というテーマで話す機会がとても増えています。ファインディさんのイベントをはじめ、Four KeysやSPACE文脈でのメトリックスの話、それ以外に「エンジニアが付加価値の部分を考えるべき」といったテーマもあります。良くも悪くも、プラクティスがコモディティ化してきたと感じています。
ただ、頭の中で考えていても、実行できなければ意味がありません。メトリックス的な開発生産性を語るときに「改善のための工数がない」「うちの会社はFindy Team+にお金を出してくれない」「GitHub CopilotやFigma AIに予算が出ない」といった課題があるのではないでしょうか。実行するためには、その課題から脱却する必要があります。事業責任者側が投資対効果を理解するのはもちろん、エンジニア自身が説明責任を果たさなくてはならないフェーズに入ってきています。
生産性のinとoutを改めて見てみましょう。いろいろな手段でヒト・モノ・カネを入れ、開発などの生産活動をして、何か生産されるというプロセスです。ここでout部分の「生産量」を指標にすると、グッドハートの法則に陥り、歪みが生まれます。数値が状態を作るわけではなく、状態が数値を作ることを忘れてはいけません。すなわち、数字だけを追いかけるのはやめたほうがいい。やはり、その先にあるエンドユーザーの付加価値を考えていかなくてはなりません。
付加価値生産性と物的生産性と、よく言われるものにも言及しておきます。まず、プロダクトチームには、事業責任者やPdM、デザイナーなどいろいろな立場の人がおり、その中にいるエンジニアは間違いなく付加価値について考えているはずです。作るべきものやユーザーが喜ぶ機能について考えている前提で、UIデザインするデザイナー、エンジニアリングするエンジニア、と棲み分けがされている。その中で、エンジニアは基本的に「付加価値生産性」にコミットしつつも、「物的生産性（回転数）」に責任を持っています。責任とコミットは違うのです。
回転数については、昨年、広木大地さんがなさった素晴らしい講演から引用させていただきます。ソフトウェアの生産証明はなかなか難しく、進捗20％や30%という数字は極端に言うと「嘘」なわけです。なぜなら、実体は目に見えないからです。無形資産であるソフトウェアが動くものとして見えるよう、ユーザーにリリースしたり、機能AとBを付けて動くソフトウェアにしたりと、曝露（Exposure）を増やして回転数を上げていくことが非常に大事です。
開発生産性は”信頼”を作ることに価値がある
石垣：ここからは、「信頼を作る大切さ」を話します。開発生産性でなくとも、データは比較的強制力が強いもので、強いメッセージ性を持ちます。ただ、開発生産性においては、正論としての理解を求めるためのものではなく、信頼を作るための糸口だと考えています。
データドリブンではなく、データインフォームドという言い方をします。データに基づいて意思決定するのではなく、組織の中の意思決定に何かしらのデータを置く、という考え方です。
本来、信頼が積みあがっていれば、一部の開発生産性は不要になります。開発生産性のデータが求められるのは、エンジニアが自分たちで「内部的にケイパビリティをよくしたい」「開発生産するメトリックスを取りたい」というニーズによるものと、外部からの「うちの生産性ってどうなってるの」と聞かれる、監視や管理を目的としたケースがあります。特に後者の場合は、信頼が積みあがれば生産性の議論は不要になるのです。
事業責任者の興味は、自分たちが思い描く戦略や戦術内において、「狙ったタイミングでモノが出てくるのか」ということ。それなのに、予定していた日程の直前で「再来週に流れます」と言われたり、後から「予定外の人件費がかかっています」という報告を受けたりする。
事業責任者は、売上目標や予算の中で戦略戦術を立てています。事業責任者にとって、エンジニアからの見積や予測をもとにした計画から遅れや予算オーバーが生じると、一番のネックになるのです。事業責任者の操作可能変数である予算を使って人を投入したり、事業責任者とエンジニアの間にPdMを配置してロードマップを策定したりと、試行錯誤することになります。
一方で開発組織側は「見積にはある程度のずれがつきもの」という認識があります。遅れた事実は数値化しやすく、WBSやスクラムで進捗を見れば遅れた箇所がわかるため突っ込まれやすくなりますが、遅れた原因は数値化しにくいのが問題点です。
事業責任者が予算を使って人を投入しても、フレデリック・ブルックスの著した『人月の神話』にある「ブルックスの法則」に陥り、遅れる要因を増やすだけになりかねません。この状況下で現場は、根本的な解決策となる内部品質の改善に取り組みたいと考えるものの、時間がかかるので後回しになるケースが多いのです。
双方の悩みを踏まえ、信頼ポイントを作る
石垣：開発チームとしては、内部品質改善のためにリファクタリングやミドルウェアのバージョンアップなどに時間を取りたい。ところが、「定量的に価値があるか」「それによって儲かるか」に落とし込まないと、バックログに積まれません。「生産性の向上」を「売上・利益・価値の貢献度の向上」に繋げたいものの、リファクタリングやバージョンアップによって売上が100万円増えるといった話は、基本的に机上の空論になりがちです。
事業責任者側から見て、遅延や工数の増大といった「隠れた失敗」が増えると、開発チームへの信頼が損なわれていきます。そこへ来て、「うちの開発組織の開発生産性ってどうなっているの？」という疑問が生まれるのです。
ところが、本当に知りたいのは、「狙ったタイミングでモノが出てくる開発組織なのか」という事実。例えば「2週間後にこの機能が欲しい」と依頼して、その通りに出てくるのであれば、それ以外で開発組織が何をしていようと問題ありません。
「隠れた失敗」が増えると、事業責任者側は意図の通りにモノを出してもらうために、優先度を決めたくなります。そこで細かく管理し始めると、開発チームが取り組みたい内部改善の時間が減ってしまい、組織として危なくなっていくでしょう。
開発チームが信頼を積み重ねるには、いくつかのポイントがあります。まずは「言葉の丁寧さ」。最近読んだ記事にあったのは「Don’t refactor the code（「リファクタリングする、という言葉を使わない）」という考え方です。「リファクタリング」はなんとなくいいものと思われていますが、作業内容がはっきりとわからない。リファクタリングには終わりがなく、やろうと思えば無限にできます。だから、売上への貢献度は置いておき、「コードのパフォーマンスを向上させた」「コードを変更しやすくした」など、作業内容を具体的に言ったほうがいいのです。
また、事業責任者に対して傾向値を提供するのもよいでしょう。こちらはIPAが提供するグラフで、横軸が計画工数、縦軸が実際の工数です。工数が短いものは予実が合っていますが、工数が長いほどずれていきます。同様のデータを、自分のチームでも取ってみましょう。僕のチームでは、見積が1人月以内だと合うものの、5人月以上になると絶対ずれるという法則があります。これを事業責任者側に提供しておくと、「5人月くらいかかる」と聞いた時に「ある程度のずれがある」と心のバッファーができるはずです。
次に紹介するのは外部のデータで、リファクタリングについての論文です。「低品質のコードは高品質のコードに比べて、欠陥数が15倍あり、問題解決の時間は最大9倍かかる」というもの。こういったデータを提供するのも有効でしょう。
言葉の定義を定めて特性と構造を伝える
石垣：ここまでの話を覆すようですが、信頼の積み上げで一番大事なのは、言葉の定義を定めてその特性と構造を伝えることです。「生産性」という言葉はふわっとしていて市場的にも確立したものではありませんが、だいたい下記の4つの要素があります。
①どのフローの話？
②どのプロセスの話？
③どのレイヤの話？
④生産性を上げて何がしたい？
生産性でフローの話になるのは、「いつリリースされるの？ 遅くない？」「開発に掛けるコストの投資対効果は合っている？」という疑問からが多いと思います。売上1億円に対して人件費が3000万円だった時に、売上を2倍にしたければエンジニア予算を2倍にしなくてはならないのか、と当然考えます。これは「リードタイム」と「スループット」の2つの概念に分けられます。リードタイムとは1つのプロジェクトに対するバリューストリームのようなもので、「これがいつリリースされるのか」という時間軸の見方です。スループットは一定量当たりの生産量と考えればわかりやすいでしょう。
プロセスが話題になる場合、リードタイムよりプロセスタイムを見ていることが多くなります。ただ、デプロイ頻度を変えるような施策の場合、プロセスではなく全体を見ないと速度改善の度合いはわかりません。「事業責任者の発案をきっかけに要件定義設計ミーティングが始まり、開発をスタートし、Jiraでチケットを切り、開発、デプロイしてチケットをクローズする」という一部分だけでなく、開発全体を見る必要がありますが、エンジニアは自分の操作可能なプロセスしか見ない傾向にあります。そのために全体のスケジュールが遅延すると、後ろの工程にしわ寄せが来る。後工程にあるQAを削減しがちですが、「実はその前のミーティングに問題があった」という場合もあるのです。
レイヤの話は、こちらの仮の体制図で説明していきます。はじめに「経営」、その次に「BM(事業責任者)」、続いて「PdM」、その下にエンジニア組織がいると考えた場合、開発生産性の出力単位はレイヤによって違います。下のレイヤの開発組織は、デプロイ回数（スループット）が開発生産性の単位になりますが、EMやPdMのレイヤでは工数で語られる場合が多い。PdMやBMでは工数に単価をかけて金額を算出し、最終的にP/LやB/Sに反映します。それぞれ単位が異なるので、話されているレイヤを知っておく必要があります。
最後の「生産性を上げて何がしたい？」も、目線によって異なります。クリエイターとしては「GitHub CopilotやFigma AIを使いたい」「フロー状態を長くしたい」という期待があり、PdMやEMでは「仮説を検証したい」「開発プロセスのリードタイムを短縮したい」、経営層は「いいものを早く出したい」になります。経営層から見た「いいもの」は省略されるケースがあり、早く市場に投入するために外から購入する場合もあります。
開発生産性の正確性と立体感
生産性に影響しそうな変数は、取ろうと思えばいくらでも取れます。オブザーバビリティー的なソフトウェアの状態、つまりアプリケーションログやCI/CDのデプロイの話もあれば、個やチームの生産性の話もあります。GitHubやAI（Copilot）で算出したり、SonarQubeで内部品質を確かめたり、チームパフォーマンスを可視化するために「Findy Team＋」「Jira」「ZenHub（Burndown ChartやControl Chart）」を使ったり……。フロー状態を測るためにGoogleカレンダーのミーティングのデータを引き合いに出す場合もあります。P/Lにある人件費の数字も同様です。
いずれにしても、どの変数も正確にソフトウェアやチームの状態を示すものではなく、あくまでも傾向値です。とはいえ、組み合わせと傾向を多数組み合わせて確かさを掴んでいくしかありません。そのためには、「個の集合知であるチームの数値」「そのチームが作るシステム・プロダクトの数値」「そのチームとプロダクトを運用するための予算（お金）」に、先ほどの「フロー・プロセス・レイヤー・期待値」をプラスし、立体的に捉えていく必要があります。
先ほどの組織図で、経営層、PM、下位組織それぞれで「スループット」「工数」「金額」と価値の単位が異なり、それを楕円で示しています。赤く斜線を引いたオーバーラップしている箇所で、単位の変換が必要になります。楕円の右側に書いてあるそれぞれの「使っている武器」は認識する必要があるでしょう。エンジニアから見ると、予算はあまり見えないし見る必要がないのですが、経営層はそこしか見ません。「人件費」「減価償却費」「採用費」などの数値ですね。
僕たち開発組織は、チームの生産性とオブザーバビリティーを武器にして生産性を語らなくてはなりません。予算の権限が最も高いのは経営層で、プロセスは上から下に流れてくるので、全体的な立体感を持って、生産性を変換して考える必要があります。ただ、現場の生産性の指標を無理に管理会計に繋げないことが大事です。「このFour Keysのデータが財務諸表にこう影響する」と紐付けたとしても机上の空論になりがちで、事業責任者には響かない場合があります。やはり、下から順繰りに変換して伝えていくのが大事だと考えています。
DMMでは、足元のスループットのデプロイの部分でFindy Team+を使っています。それより上位で従業員データ、プロジェクトのデータ、工数、金額などをBigQueryに取り込み、Lockerで可視化しています。
左下の全体サマリーは、部署やチーム、グループで使っている工数や金額、所属する従業員が確認できます。上側の表では、細かい施策の各プロジェクトコードに対して、かけた工数や完了の予実が見られます。各プロジェクトの資産計上区分では、この後話すバランスシートへの影響の仕方がわかる。右下の表では開発区分が示されており、新規プロジェクトや保守運用、会議にかけている時間が割合でわかります。
各部署はチームの生産性を見る場合が多いものの、DMMでは複数チームで横断的に1つのプロジェクトを完遂するモデルが多いため、プロジェクトベースで検索して全体としての数値を確認できます。スライドで表示したプロジェクトは113人月かかっており、実金額や月別の数値も見られます。例えば「ミーティング、特に要件定義設計が多い」といった課題も可視化できます。
次に、データパイプラインを紹介します。DMMでは、例えば8時間働いたときに、その8時間をプロジェクトコードに振り分けて申請します。人事データとプロジェクトデータに取り込みそこからさらにBPMと呼ばれるシステムに取り込ます。その後で給与が計算されたり、DWH的にBigQueryに取り込まれます。BigQueryに取り込んだデータをLockerで可視化しているわけです。
開発生産性を上げることで「儲かる」のからくり
事業責任者や経営者の頭の中には、次のような疑問があります。
「開発生産性を上げる改善って、どう儲かるの？」
「スクラムを導入したら、どう儲かるの？」
「リファクタリングしたら、どう儲かるの？」
「リモートワークにしたら、どう儲かるの？」
「MVPで小さくしたら、どう儲かるの？」
ここまで露骨ではないにしても、コストに対しての売上や利益への貢献度は、ユーザーが喜ぶ先にあるものです。事業責任者から見れば、論理的な回答が欲しい、というのが正直な気持ちでしょう。
これは目新しいものではありませんが、開発に関する管理会計として、事業責任者はP/Lにある費用「人件費」「福利厚生費」「減価償却費」などを見ています。また、僕たちが作っているソフトウェアは、B/Sの資産に含まれており、特に「無形固定資産」内の「ソフトウェア」「ソフトウェア仮勘定」に入ります。ソフトウェア仮勘定は、作っている最中の開発費用が含まれ、主に人件費となります。
この資産の蓄積と売上の時間軸の違いが、「開発生産性を上げると儲かるの？」という問いへのアンサーに繋がります。
財務諸表で見ると、開発をして会社の資産を作った結果、売上を増やすわけではなく、セールスやマーケターが資産を使って売上を作る、という構造になります。資産が蓄積する時間は長いものの、資産を作った後の施策などは短期間で売上げに直結するケースが多い。例えば、あるECサイトを作ったあと、セールスやマーケターがコンテンツや施策を通じてサイト内での販売を増やせば急激に売上が増えて行きます。売上は直接的に見えますが、僕たちが作っている資産から逆算すると、間接的ではあります。
B/Sの資産を増やすだけでなく、バージョンアップやリファクタリングなどもB/Sの負債を減らし、資産価値を上げる行動として価値があるはずです。いずれにしても時間軸のずれを認識するのが大事な観点でしょう。
この前提で、生産性を上げたときのP/Lを見ていきます。費用の項目を見ると、人が減るわけではないので固定人件費は変わりません。むしろ、開発が早くなり貢献度合いが増えれば、給与が上がるかもしれず、その場合は人件費が増えます。ただし、生産性が低い組織は炎上プロジェクトに人を追加したり、調整コストがあったり、イニシャルコストが膨れたりと、無駄な開発費用がかさむものです。従って、相対的に見ると無駄な人件費が減っている可能性があります。とはいえ、その証明は簡単ではありません。
P/Lの売上げはどうでしょうか。PdMや事業責任者の仮説が「一定の確率で価値を上げる」と仮定すると、価値になると考えられます。前提として、作るべきものとユーザー体験を考えると回転数は非常に重要です。また、1施策当たりのリードタイムが短縮できればその分イニシャルコストが削減できます。
また、P/Lの売上損失の最小化も考える必要があります。よいアーキテクチャやチームで、早いサイクルが回っていればロールバックが早くなり、障害の影響が最小限で済みます。ただ、回転数が上がるとデプロイ回数が増えるので、障害の数は増えます。その分で損失が増える可能性があるので注意が必要ですが、ユーザーからの問い合わせで障害に気づくようなフローでない限りは問題ないでしょう。また、A/Bテストの基盤を作って、初めに1000万人ではなく100万人に試してみてダメだったら撤退するというフローにすれば、900万人の売上の損失が防げます。また、早いサイクルが回っていれば、サーバー費用も最小化できるでしょう。
バランスシートで考えると、僕たちが作っているものは資産化するものと費用化するものの2軸にほぼ分かれ、資産価値があるものは減価償却の対象になります。例えば1億円で作ったものに資産価値があり減価償却する場合、5年つまり60ヶ月で分割して、月ごとに費用計上できます。これが資産価値のない開発だとすると、一度に費用として1億円が計上されます。この差はかなり大きい。資産価値のあるものを多く作ると減価償却で人件費を細かく分けられるので、売上げに対する利益幅が大きくなります。
資産価値をテスラの車の例で考えてみましょう。カーナビのアプリケーションを作っているとすると、資産価値を上げているので減価償却できます。一方、定期的に窓の掃除をしているとしたらどうでしょうか。窓掃除により資産の耐久年数を上げているなら資産価値を増やしているので減価償却できますが、窓をきれいにしているだけなら費用として一度に計上せざるを得ません。さらに、テスラのプロモーションをした場合は、資産価値を上げているわけではないので費用になります。
僕も社内で、「このプロジェクトは資産計上対象か、費用化対象のどちらでしょう」と経理と話しています。国税庁から出ている資料によると、リプレースを修繕費として資産計上していいというパターンもあるので、興味がある方は国税庁のページを見ると面白いと思います。
儲かっていない箇所を最適化していく
「儲かる」という部分に着目すると、儲かっていない箇所を最適化すれば、排他的に残りは儲かるという話になります。儲かっていない箇所は、開発中のもの、無駄なミーティング、保守運用の作業という3つが代表的です。これらは資産計上の対象になりません。
開発中のものは「ソフトウェア仮勘定」で一時的にプールされています。リリースしたら本勘定の減価償却になりますが、売上げを生まない開発中はスピードが早いほうがいい。また、開発に関するミーティングは減価償却できますが、無駄なミーティングは費用化されてしまいます。さらに保守運用の中では、バージョンアップなど「保守」の部分は減価償却できる場合もありますが、「運用」はできない。依頼を受けてデータ抽出するといった作業は価値を一切挙げていないので、運用作業をすると売上に対する利益幅の減少に繋がります。その3つの工数に60～80万円くらいのエンジニア単価をかければ、だいたいの金額に落とし込めるはずです。
また、減価償却対象のものがわかれば、人件費に対して資産価値を作っている業務の割合がわかるので、ぜひ経理に聞いてみてください。
ここで改めて、今日話したことをまとめます。まず、開発生産性は、基本的に信頼を作ることに価値があります。管理と監視のための開発生産性は基本的に不要なので、生産性のメトリックスを使って信頼を少しずつ積み重ねていくと、エンジニアが動きやすい状態になっていきます。
まとめの2つ目は、開発生産性の意味を搾り、特性と構造を伝えていく必要性です。3つ目は、無理に現場の指標と財務諸表を繋げないこと。工数を使って単価を掛けて、少しずつ変換していくのがよいと思います。そのうえで4つ目、開発生産性の向上の「儲かる」を意識してください。先ほど言った「儲からない箇所の最適化」でもいいでしょう。開発組織が資産価値を上げるものをどんどん作っていけば、自然と利益幅が大きくなっていくので、まずは意識することが大事だと思います。
