［新連載］クリエイターがクリエイティブであるために DMM VPoE室が実践する「生産性」の可視化とは

クリエイター組織が、クリエイティブであるために

　こんにちは、石垣雅人（@i35.267）です。初回となる今回は、私が最近注力している組織全体の「生産性」に関する取り組みについて紹介します。

　DMM.comには、デザイナー・エンジニア・PM（プロジェクトマネージャー）を中心とする1,000名以上のクリエイターからなる「クリエイター組織」が存在します。進行中の開発プロジェクトは約500個、チーム数は100以上、プロジェクトはほとんどが内製です。

　DMMの開発体制はプロダクトチームであることが多く、ひとつの事業プロダクトのひとつの開発プロセスの中でデザイナー・エンジニア・PM・PdM（プロダクトマネージャー）が動いているケースが多いです。また大規模になればなるほど、複数のチームにまたがって進めていくこともあります。

　本記事で取りあげるのは、「生産性」の可視化によって生まれる変化についてです。ひとつのプロセスの中でクリエイターが動いているため、デザイナーだけが頑張っても生産性向上にはつながりません。エンジニアもPMも同様に組織としてリードタイムを考え、できるだけムダをなくし、付加価値生産性を高めていく必要があります。

　クリエイティブ職の生産性評価の基本は「労働時間当たりの成果」だと思います。どのような職種や仕事であっても労働には報酬が与えられるため、営利企業である以上は一定の成果が求められます。

　「生産性」という言葉からは誰もが逃げられず、直面するのが怖い指標でもあります。「クリエイティビティ」と「生産性」はイコールではないですし、多くの時間をクリエイティブな時間に割いたからといって生産能力が高くなるわけでもない。ましてや良い成果物が提供できる保証もありません。

　一方、生産性を可視化するといっても、製造業で用いられるラインの「有効稼働率」のように個人の労働力を監視したいわけでも、過度なプレッシャーを与えたいわけでもありません。クリエイターがクリエイティブに時間を割くために、生産性に注目する必要があるのです。

　本来はよりクリエイティブな活動をしたいはずなのにミーティングが多かったり、エンジニアであればシステムの保守・運用の割合が多かったり、デザイナーであればデザインシステムがなかったり、Figmaのファイル管理が煩雑になっていたり、ほかの作業に阻害されるケースが多くあるでしょう。そういった問題をクリアにするための定量化なのです。

　新しい価値を何も生み出していないのであればプロダクトも停滞していることと同義です。近年の環境では、現状維持は停滞に当たります。クリエイターはできるだけ、「思案時間を増やし、製品を作る技能を早めていく」ことが理想で、新しいクリエイティブな開発に時間をかけていきたいところです。

　また、生産性へ注目するのは、マネジメント層へ向けた「見える化」の意味もあります。DMMもリモート環境に移行してから早3年が経とうとしていますが、そうした中で「クリエイター組織の生産性が見えないし計測できない」「結局クリエイティビティは上がったんだろうか」という課題を抱えるマネジメント層が多く存在します。実際、完全リモートワークはオフィス勤務と比べて生産性が18％劣るというアメリカの大学の研究もあります。

　本記事で紹介する取り組みでは、可観測性（オブザーバビリティ）の考えかたを導入しています。可観測性とはシステムの出力をうまく観測することで内部の状態、品質を計測するやりかたです。これを生産性の可視化に応用していきます。

ムダ・ムラがない生産性を作るために、まず”観測する”

　最近では、個々人のスキルを支えるためのエコシステムは多くなってきました。エンジニア界隈では、「GitHub Copilot」の利用が促進されたり、デザイナーであればデザインシステムを導入したりするなどして、各領域でプロセスを効率化し、業務効率を上げられるようになっています。

　できるだけ、ムダ・ムラなく生産性を高めていくために、まずはムダ・ムラを観測しなければいけません。科学的アプローチとして「観測できないものは改善できない」という言葉があるよう、取るべき指標を決め、捉えられるものを捉えていきます。

　また、改善プラクティスが先行し、現在地点や改善前の状態を観測できていない組織は多く存在するでしょう。効果を図るために、何事もまず可視化をしておくと改善幅がわかりやすくなるはずです。

　弊社ではクリエイター組織全般で次のふたつを一覧化する取り組みを始めました。

1. 勤怠時間
2. （勤怠時間に紐づく）プロジェクトコードにかかった工数・工期・費用

　DMM.comは、勤怠打刻とともに工数を入力しないと承認されないような仕組みになっています。つまり、1日8時間働いた内訳、つまりどんな仕事に何時間費やしたのかをプロジェクトコードベースに入力していきます。

　これらのデータは人事とBPM（Business Process Management）のデータに入っているため、かけ合わせてGoogleのデータウェアハウス「BigQuery」に投入。毎月保存することでSQLライクに分析することが可能になりました。実金額など一部データを除き、誰でも分析できます。ビジュアライズとしてはBIツール「Looker」や「Google スプレットシート」で可視化していきます。

　少しエンジニア寄りになりますが、現状のスナップショットでいうと次の数値をGoogleスプレットシートで出しています。

• 開発区分
  　新規開発
  　保守運用・エンハンス開発
  　管理業務（ミーティングなど）
• 開発コード
  　毎月の工数・金額
  　毎月の人数
  　進行ステータス
• 完了予定日・完了日（予実）
• ソフトウェア資産計上区分（計上するのか、費用化するのか）

　また、BigQueryを使ったDWH（データウェアハウス）にデータを流し込むことで柔軟な分析も可能になります。たとえば、同じプロジェクトコードをさまざまな組織が使っていたとしても、デザイナー組織、あるいは自分のチームのみに絞った分析も簡単にできます。