問題解決能力の高い「強いエンジニア」は強力な福利厚生
エンジニアリングのコモディティ化も、生産性と切り離せない要素だ。AWSやMicrosoft Azureなど、誰でも使えるツールが台頭したことで開発速度は向上している。また、万人が同じSaaSプロダクトを使うようになったことで、他社とのエンジニアリングを差別化する要素も限られてきている。
そのため、「いかに競合他社よりも狙ったタイミングで出せるか」という、競争優位性としての生産性が注目され始めている。生成AIの台頭に伴ってこうした潮流は加速しているといい、こうした速さを担保するためのポイントとして石垣氏は、「各施策におけるリードタイムを短縮し、迅速さを実現することで継続的な速さという価値が生まれる」と、仮説検証の回転数の重要さを示した。
事業的な視点では、売上損失の最小化も生産性と関連する領域だ。開発生産性が高い組織の傾向としてデプロイ回数が多ければ自ずとCI/CDが整備されており、たとえ障害を起こしても、迅速にロールバックができる強い開発組織を持つ事業は売上の損失が少なくなる傾向がある。
開発生産性の向上は、無駄な開発費用の削減にもつながる。開発組織として充実したエコシステムを提供することで「車輪の再開発」を防ぎ、無駄な人件費としての炎上プロジェクトへの人員投下が防げるようになった。これにより損失は最小化され、無駄な開発費用（販管費）も削減できるという。やはり事業的観点からも、開発生産性の議論は避けて通れないのだ。
なお、開発生産性の議論にあたっては、「新規採用をするか、開発生産性を上げるか」もよく俎上に載せる。これについて石垣氏は、「強いエンジニアを採用することで、多くの問題が解決するのは事実」と新規採用を勧める一方で、優秀なエンジニアの採用は難しい現実に鑑み、「メトリクスを取って、分析や改善を行うことが最短ルートだ」とも示した。
組織全体の生産性向上にはバックオフィスの目線も必要
続いて、石垣氏は開発生産性という言葉を組織全体にいきわたらせるための考え方について話を展開した。石垣氏によれば、ときに経営層や事業責任者に開発生産性の価値が伝わらないのは「言語が違う」ことに起因するという。
たとえばある組織があったとして、現場のエンジニアにおける「生産性」は「マージまでの時間を短くすることで1人月当たりのアウトプットを増やすこと」のように定義される。対してPdMやEMでは、「施策を行うのに何人月かかるか」「どのぐらいの速さでリリースできるか」が論点になる。
さらには経営層になると、「その事業がどのくらいの資産価値を生み出すのか」「価値を生み出すための人件費はいくらか」などが主要なトピックになり、この視点のもとで、1人あたりの生産性がどうあるべきかを捉えることになる。
そして当然ながら、エンジニアの人数・役割などの開発体制やビジネスの規模によっても、「生産性」をどう定義するかは変わりうる。現場と経営層の間で「生産性」をめぐる摩擦が起きるのは、このような理由からだという。
このような複雑性を含めて生産性を可視化するため、DMMでは、エンジニア目線の生産性向上はGitHubやFindy Team+で確認し、従業員データ・BPM（Business Process Management）関連データや事業目線の生産性はBig Queryやスプレッドシートを活用している。具体的にはBig Queryに工期や工数、実金額データを投入し、Lookerのスプレッドシートにこれらの情報を出力し、複合的な開発生産性のデータをモニタリングしているという。
こうした体制は各部署レベルで存在しており、年間で使った費用や開発にかける工数などを組織ごとに確認できる。チームを横断するプロジェクトにおいてもKPIを横断的に観測し、新規開発に注力できているか、保守に時間をかけすぎていないかをチェックしている。
データパイプラインは勤怠ツールと紐づけられており、人事データやプロジェクトデータを加えた状態でBPMシステムに投入される。これをBPMを挟んでBig Queryに投入し、App Scriptを使ってLookerやスプレッドシートに反映するという仕組みを作っている。
こうした仕組みの実践について、石垣氏は「50人以上の企業組織で行うのがベスト。生産性レポートは決裁権限がある部長以上が中心になって見るもので、会社組織が小さければシンプルなメトリクスでカバーできる」と語る。33部署、約1200名以上のエンジニアが所属するDMMだからこその取り組みというわけだ。
