8.2 ダッシュボード設計は3つの角度で捉える
では、実際にダッシュボード設計を見ていきましょう。 まずは、これらの開発生産性を見たときに何を知りたいかを考えていきます。 たとえば、以下の事象です。
-
個人・開発チーム視点
- いま作業しているプロジェクト
- 自分たちのチームが施策にどのぐらいの工数と金額を使っているか知りたい
- ミーティングが多く、開発に時間を当てられていない現状を定量的に表したい
-
PM・PdM視点
- プロジェクト振り返りの定量データとして使いたい
- 複数部署を跨いだプロジェクトにかかった工数のトータルを見たい
-
経営層視点
- 開発組織への投資コストの内訳を知りたい
- 開発組織全体で毎月何をリリースしたかを知りたい
これらを解決するためには、以下3つのダッシュボードを用意します。
- 部署単位の生産性を見るダッシュボード
- プロジェクトの学習データ蓄積ダッシュボード
- 開発組織全体の生産性を見るダッシュボード
8.2.1 部署単位の生産性を見るダッシュボード
このダッシュボードは、部署単位で作成されるものです。その部署に所属しているメンバーが工数をつけているプロジェクトコードに関する情報が集まっています。
主な利用方法は以下です。
- オンプロダクト指標といった、どれだけ開発作業に時間を使えているかの確認
- 月別の工数・実額実績
- 従業員属性（正社員や業務委託などの割合）
- どの開発に時間をかけているか（新規開発や保守開発、ミーティングなど）
- 各施策にどのぐらい工数を割いているかを月ごとに詳細確認
こうした情報をフィルターでチーム単位や雇用体系ごとに絞り込みながら、欲しい情報にアクセスしてもらっています。
8.2.2 プロジェクトの学習データ蓄積ダッシュボード
プロジェクトの学習データの蓄積を目的にしたダッシュボードです。プロジェクトは、違う部署のチームなども巻き込みながら行うため、横断検索できるようにしています。
インターフェイスとしては、プロジェクト名を検索できるようにしています。その上で、部署やチーム横断で累計工数や、月別にかかった工数・実額、雇用形態ごとの分布などが見れます。
これはプロジェクト学習のデータ蓄積に活用できます。特にPMがプロジェクトの完了後の振り返りで使った工数などを改めて確認するために利用します。
基本的に組織規模が大きいほど、並列でプロジェクトが入っており同時に終了しています。それぞれの傾向（設計に時間がかかるなど）に応じたデータを横断的に学習できる基盤としても活用できます。
例えば、 DMM.comの開発組織ではおおよそ900個のプロジェクトが走っているため、それぞれの予想工数と実工数の差分や傾向を見るだけでも学習が捗ります。
8.2.3 開発組織全体の生産性を見るダッシュボード
最後は、開発組織全体の生産性ダッシュボードです。主に予算権限を持っている部長以上や管掌役員が見るダッシュボードです。基本は、部署単位のダッシュボードを集約したものになります。需要としては以下のケースです。
- 部署ごとの投入工数のバランスを見ながら、適切なプロダクトに適切な工数が割かれているか
- 従業員数・雇用形態の全体を見ながら、全体最適化を行う
- 役職ごとの業務割合を観察し、適切な開発に工数がさけているか
データを1つ紹介します。役職ごとにどういった開発に工数が割けているかを見てみると面白いデータが見れます。データの傾向を見た際、開発区分を以下5つとすると、一般的にマネジメント層は管理業務が多くなってくると予想できます。
- 新規開発：新しい価値を0から作る
- エンハンス開発：既存システムの拡張・変更
- 保守開発：資産価値の耐久年数を維持する・伸ばす（振る舞いを変えずに現状維持を行うリファクタリング・バージョンアップ）
- 運用：障害対応、問い合わせ対応
- その他：会議やその他開発以外の作業
実際のデータを見ると、以下のことがわかります。
- 全体を通してその他の管理業務（ミーティング）が多い。メンバーでも33％を何かしらの管理業務に使っている
- Team leaderやManagerがプレイングマネージャーとして動いており、コンテクストスイッチで負荷がかかっている
これらのデータは、組織全体で可視化することにより見えてくるデータです。 個別の部署課題ではなく、全体としてそういった傾向があることがわかることで対策が打ちやすくなります。
