開発者の 高速なPDCAサイクル を支援するデータの見せ方をぼんやり考えている

# はじめに

データ利活用したいよねということで、タイトルのようなことを考えています。

# もくじ

- [前提](#前提)
- [背景](#背景)
- [現状の課題](#現状の課題)
- [ユーザーストーリーを考えてみる](#ユーザーストーリーを考えてみる)
- [大まかなニーズを抽出する](#大まかなニーズを抽出する)
- [分析のための基本原則](#分析のための基本原則)
  - [原則１：大きさを考える](#原則１大きさを考える)
  - [原則２：分けて考える](#原則２分けて考える)
  - [原則３：比較して考える](#原則３比較して考える)
  - [原則４：時系列を考える](#原則４時系列を考える)
- [必要そうなデータ](#必要そうなデータ)
- [テーマツリーをつくってみる](#テーマツリーをつくってみる)
- [おわりに](#おわりに)


# 前提

価値を出していくために、開発者個人がアウトプットを出すための「土台の構築」は重要だと考えています。私が所属している組織の特徴、また状況的に、「物的生産性」を上げていかないと「付加価値生産性」が頭打ちになりそうなぁと思うからです。なので「物的生産性」にピン止めした施策をしたいと思っています。

https://levtech.jp/media/article/interview/detail_406/

考える上での前提として、「開発者は自身の成果を最大化するために行動を改善するためのモチベーションがある」こととします。（これいちばん大事）


# 背景

というわけで「開発組織でアウトカムを向上させるため、開発者1人あたりのアウトプットを上げる」ということに何か貢献できないかと思っています。以前こんな記事を書いたのですが、現在は手を動かして具体的なツールを作ろうとしている段階です。

https://qiita.com/_mi/items/b5b1da1857c672fc60ef

対象にしているのは、「開発生産性」の中でも「時間あたりの仕事量」の部分で、単位時間あたりに生み出せるアウトプットの量を増やすことです。そのために、開発者個人の各種アクティビティを可視化し、いつでも確認可能なダッシュボードの形で実現しようと考えています。


- 大目的：組織のアウトカムの向上
  - 中目的：組織のアウトプットの向上が必要
    - 小目的：組織の「開発者個人」のアウトプット向上
- 打ち手：
  - ダッシュボードを活用し、開発者の意思決定を支援する
  - それにより、開発者はデータをもとに高速なPDCAサイクルをまわせるようになる


あくまで個人のアウトプット量を向上していくのは各開発者自身ではあるものの、私はそのためのデータ基盤を構築しようとしているというわけです。


# 現状の課題

今回達成したいゴールとしては、**開発者が自身を客観視し、改善のポイントを見つけ、効果的な打ち手を考え、行動に移すための意思決定を支援できる状態（そんなダッシュボード)** です。

https://speakerdeck.com/sansan_randd/project-management-to-avoid-creating-unused-dashboards?slide=19

実を言うと、最小の動くツールはすでにできており以下のようなことを実現しています。

- `GitHub Actions` で開発者の各種アクティビティを取得する
- そのままデータを `MySQL` にINSERT
- `Metabase` を使って可視化
- 上記をスケジュール実行させる

なのですが、**表示させているデータの " 見せ方 " が 開発者の意思決定を支援するものになっておらず** 、価値のあるデータを提供できていないことに課題を感じています。また、拡張性を考えると今のテーブル設計では微妙そうだなぁと考えています。


# ユーザーストーリーを考えてみる

私の現在の最大の関心事は **『開発者にとって毎日見たくなる情報が載っている画面てどんなの？』** です。毎日見たくなるというのは、開発者の意思決定によるフィードバックが数字として反映されるダッシュボードであり、また、開発者が意思決定しやすいように加工されたデータが出力されているものだろうなと思います。

なのでまずは、**『開発者はどんな情報があれば行動改善のための意思決定ができるか』** を検討する必要があります。 

というわけで最初に、ダッシュボードを利用する開発者を年次というセグメントで分けたユーザーストーリーを（生成AIが）考えてみました。

- **ジュニアエンジニア**
  - 入社後約 0 ~ 3 年の実務経験を持つエンジニア
  - 基本的な技術スキルは勉強中
  - 独立して複雑な問題を解決するには監督やサポートが一部必要
- **ミッドレベルエンジニア**
  - 約 3 ~ 7 年の実務経験を持つエンジニア
  - 一人でタスクを完遂できる能力を持ち、より大規模かつ複雑なプロジェクトに取り組むことができる
- **シニアエンジニア**
  - 約 7 年以上の実務経験を持つエンジニア
  - 高度なテクニカルスキルと深い業務知識を持ち、プロジェクトのリーダーを担ったり、他のエンジニアのメンタリングを行うなどの役割を担う

※ 弊社の背景的に、開発未経験の新卒が毎年増えていくことを加味して年次（入社からの経過年数）というセグメントを利用しました。

| < ペルソナ > として | < 機能・性能 > でできる | < 価値 > のためだ |
| :--: | :--: | :--: |
|ジュニアエンジニアとして | 自分のコードコミットの履歴を見返すことができる | どのように改善されたかを理解し、書くコードが徐々により質の高いものになるような学習を継続するためだ |
|ジュニアエンジニアとして | チーム内のベテランエンジニアと自分の活動を比較できる | 自分がどの領域で成長すべきかを理解し、目標設定とパーソナル成長を視覚化するためだ |
|ジュニアエンジニアとして | 自分のプルリクエストがどれだけ迅速にレビューされるかを追跡できる | コードレビューのサイクルタイムを改善し、より円滑に作業を進めるためだ |
| ミッドレベルエンジニアとして | 自分が頻繁に作業するリポジトリの活動状況を見られる | リソースの配分を最適化し、効率的にタスクを進めるためだ |
| ミッドレベルエンジニアとして | チームのイシュー解決タイムと自分の解決タイムを比較できる | 問題解決スキルを客観的に評価し、自己改善のためだ |
|ミッドレベルエンジニアとして | チーム内での自分の影響度をクオリティやコミット量で知ることができる | 自分の影響力を理解し、キャリアパス形成に役立てるためだ |
|シニアエンジニアとして | プロジェクト全体の進捗と健全性（コードヘルス、依存関係、ビルド状況など）を一眼できる | 技術的意思決定を迅速に行い、リスクを管理するためだ |
| シニアエンジニアとして | チームのメンバーによるコードレビューのフィードバックサイクルをモニタリングできる | コード品質の維持および改善と、メンタリングの機会を最大化するためだ |
| シニアエンジニアとして | チーム内のスキルセットと知識の分布を把握できる | 能力開発の機会を特定し、教育プログラムの策定に役立てるためだ |

割と妥当なニーズだろうなとは思いつつ、こういうのは使ってもらってフィードバックを得る方がよいのでざっくりで終わらせます。

# 大まかなニーズを抽出する

ユーザーストーリーから、必要そうな軸としてはやっぱり「個人のデータ」と「チームのデータ」の２軸かなぁと思いました。

1. 個人が、自身の過去と比較して振り返る（評価する）
1. 個人が、他者（同じくらいの年次の人）と比較して打ち手を検討する
1. 個人が、他者（自身よりパフォーマンスが高い人）と比較して打ち手を検討する
1. 個人が、チームと比較してチームへの影響度を知る
1. 現在のチームと、過去のチームを比較して振り返る（評価する）
1. 現在のチームのアクティビティと、理想のリソース配分を比較する
1. 自身のチームと、他チームを比較して、改善点を見つける


# 分析のための基本原則

さて、理想は「見ただけで課題が見つかり、改善のアクションが実行できる（プランが思いついて行動に移すことができる）」ようなダッシュボードです。つまり、ある程度「分析」のための情報が載っている状態になっていなければいけません。

分析とは、「物事の実態、本質を正しく理解するための作業」の総称であり、「正しい認識・判断」により「正しい対応」をするためのものです。分析の基本は以下の４つになります。

- 原則１：大きさを考える
- 原則２：分けて考える
- 原則３：比較して考える
- 原則４：時系列を考える


## 原則１：大きさを考える

「大きさを考える」とは、問題や対象を分析し判断する際に、それが占める割合や影響度、さらには重要性のレベルを理解し、評価することを意味します。開発者にとって、この観点は各種タスクや改善活動の優先順位を定める際、またはリソース（つまり工数）配分を決める際に重要になってきます。

例えば、工数の80%を顧客対応（問い合わせ対応）に費やしている開発者が、残りの20%である開発業務の効率化を図ったところで改善の幅はそこまで大きくならなそうですよね。20%をよりうまくやる努力よりも、80%の割合を減らしてその時間を開発に充てる努力をしたほうが全体としてのインパクトは大きそうです。

全体を把握して、大きなところから考えて手を付ける（より詳細な改善すべきポイントを探す）、つまり自分が使えるリソースを「どこに」「どのように」配分するかは、基本的で最も重要な意思決定事項です。

ゆえに、開発業務の全体を考えるためにも開発者の工数の情報は必要になりそうですね。


## 原則２：分けて考える

「分けること」は、いろいろな要素が絡み合った複雑な問題を分解して各要素を個別に吟味し、全体の理解を深めるための方法です。大事なのは、「分けて、原因にさかのぼって理解」することで適切な仮説を立て、具体的な打ち手（アクション）を生み出すという目的を明確に意識することです。逆に、具体的なアクションが見えてこない場合には分け方がよくなかったりします。

例えば「アウトプットを向上させる」という目的であれば、それを適切な細かい要素に分解することではじめて妥当そうで具体的なアクションが見えてきます。適切に分けることで、効果的かつ実行しやすいと思われるものから順に優先度をつけ、検討・実施することができるようになるわけです。

分けて考えるためのフレームワークとしては MECE（`Mutually Exclusive, Collectively Exhaustive`：もれなくダブりなく）が有名ですね。

今回の話で考えるなら、以下のように分けられそうです。

- $組織の物的生産性 = 開発者Aさんの物的生産性 + 開発者Bさんの物的生産性 + ...$
  - $開発者個人の物的生産性 = アウトプット / 時間$
    - $アウトプット = 個人としてのアウトプット + 他者に対するアウトプット$
      - $個人としてのアウトプット = hoge + fuga + piyo + ...$
      - $他者に対するアウトプット = boo + koko + ...$


## 原則３：比較して考える

「比較する」「比較して類似や差異を推論する」は「分ける」ことと共に、現象を理解するための主要な手段であり、基本的な分析の手法です。1つの事象を単独でいくら細かく分解してもよく分からなかったことが、2つ以上の事象を比較することでいろいろなことが見えてきたりします。

比較のための基本姿勢としてはアップル・ツー・アップルを考えることです。これは「意味ある比較ができるか否か」を考えることであり、 「共通の目的」を持って、それに適した「同一の指標」を用いましょうということです。例えば、「リンゴとミカンを比較してね」といっても無理な話ですが、「リンゴとミカンをカロリーという同一な指標を用いて比較してね」であれば比較ができます。

比較をする際には以下を意識する必要があります。

- できるだけ同じものを比較すること
- 異なるものを比較するときには、意味があり かつ 比較できる指標を探すこと
- 似た者同士を比較する場合も、同じ要素と異なる要素を正しく見分け、異なる部分の影響を勘案しつつ合理的な比較を心がけること

前述のユーザーストーリーで抽出したニーズを「比較して考える」にあてはめると以下のようになりそうです。（比較の対象はきちんと揃える必要がある）

| 軸１ | 軸２ | 比較方法 |
| :--: | :--: | :--: |
| 個人 | 個人 | 個人が自身の過去と比較する |
| 個人 | 個人 | 個人が他者（同じくらいの年次の人）と比較する |
| 個人 | 個人 | 個人が他者（自身よりパフォーマンスが高い人）と比較する |
| 個人 | チーム | 個人がチームと比較する |
| チーム | チーム | 現在のチームと過去のチームを比較する |
| チーム | チーム | 現在のチームのアクティビティと理想のリソース配分を比較する |
| チーム | チーム | 自身のチームと他チームを比較する（※ 一部アンチパターン） |


## 原則４：時系列を考える

「現在の状況」はいきなりそこに現れたものではなく、過去のいろいろな経過を経て生まれたものでです。したがって、現在を正しく理解するためには、現在の状況だけでは不十分であり、なぜ現在の状況がそうなっているのかを「過去と関連づけて」考えることが必要です。

時系列を考えることは必然的に「比較して考える」の考え方を含むものですが、そのうえで「分けて考える」を使って、より根幹の要素・詳細な要素などを総合的に考えることができれば、さらに有意義に分析ができるようになります。

データの見方は様々あるわけですが、時系列のデータがあると分析の幅がかなり広がるので、ちゃんと同じデータを一定期間取り続ける必要がありますね。


# 必要そうなデータ

上記の原則を踏まえると、ざっくり以下のような情報があると嬉しいものになる可能性が高いなと思います。

- **原則１：大きさを考える：**
  - 開発者によって入力された「工数」のデータ
  - 投下できるリソース（時間）という大きい単位で、インパクトの大きそうな領域を見つけるために使う
  - そのうえで、分けられた各領域に関するデータがあるとよい
- **原則２：分けて考える：**
  - 物的生産性をMECEで考える（全量を漏れなくは不可能に近そうなので「その他」として諦める）
    - $開発者個人の物的生産性 = アウトプット / 時間$
      - $アウトプット = 個人としてのアウトプット + 他者に対するアウトプット$
        - $個人としてのアウトプット = hoge + fuga + piyo + ...$
        - $他者に対するアウトプット = boo + koko + ...$
- **原則３：比較して考える：**
  - ユーザーストーリーで抽出したニーズから、比較のための大きな軸は「個人」と「チーム」でよさげ
  - その枠組みの中で「分けて考える」を実現する
- **原則４：時系列を考える：**
  - 継続的に同じ項目を取得する
  - また、適切な期間（2週間、1か月、6か月など）で絞ったデータを振り返れるようにする


# テーマツリーをつくってみる

まぁこんな感じになるよねという感じではありますが、開発者個人のダッシュボードを充実させることが優先度高めかなと感じました。

具体的指標について、実際どんなの採用する？については、例えば [SPACEフレームワーク](https://queue.acm.org/detail.cfm?id=3454124) あたりを使えば、いろんな他社事例もあるしよさげ。

とはいえこの辺の話は周りの協力してくれるメンバーと相談しながら形にしていこうと思います。

![テーマツリー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3388832/7ec82b3f-889f-a34d-9e14-e95a4594e46f.png)


結局、さっさとダッシュボードつくって開発者からフィードバックをもらった方がよいんですけどね！開発者にいろいろとフィードバックをもらいながら進めていこうと思います。


# おわりに

機会があれば、「結局どんな指標を採用したか」「その後どう変化したか」みたいな話もまた記事にして共有したいと思います。

# 参考

[意思決定のための「分析の技術」―最大の経営成果をあげる問題発見・解決の思考法](https://www.amazon.co.jp/%E6%84%8F%E6%80%9D%E6%B1%BA%E5%AE%9A%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%80%8C%E5%88%86%E6%9E%90%E3%81%AE%E6%8A%80%E8%A1%93%E3%80%8D%E2%80%95%E6%9C%80%E5%A4%A7%E3%81%AE%E7%B5%8C%E5%96%B6%E6%88%90%E6%9E%9C%E3%82%92%E3%81%82%E3%81%92%E3%82%8B%E5%95%8F%E9%A1%8C%E7%99%BA%E8%A6%8B%E3%83%BB%E8%A7%A3%E6%B1%BA%E3%81%AE%E6%80%9D%E8%80%83%E6%B3%95-%E6%88%A6%E7%95%A5%E3%83%96%E3%83%AC%E3%83%BC%E3%83%B3BOOKS-%E5%BE%8C-%E6%AD%A3%E6%AD%A6/dp/4478372608)