開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと
Posted: Updated:
目次
開発生産性を掘り下げるサービスたち
開発に関わるインテリジェンスを提供する SaaS には国内では私が勤める overflow 社の Offers MGR（オファーズマネージャー）や Findy 社の Findy Team+ 、海外では Jellyfish、Swarmia などのプレイヤーが存在している。
国内では特に「開発生産性」という業界キャンペーンの文脈で持ち出されることが多く、チーム内のアクティビティを何らか可視化するサービスカテゴリーである。また国外勢は数歩踏み込んでリソース配分や費用効果に迫ろうとする機能も提供している。大まかには同じカテゴリーだが細部ではプレイヤーごとの考え方に差異が見られて興味深い。
以下、当時の社内勉強会資料から一部抜粋しつつ話を進める。
生産性 = 産出量 / 投入量
開発生産性について論じる既存の記事の多くでソフトウェア開発においても物的生産性と付加価値生産性を分ける考え方が紹介されている。案外日本語のほうが耳に慣れないので、アウトプット（出力）およびアウトカム（成果）と捉えても良いだろう。
生産性が投下量に対する産出量であるという前提に付け加えると、習熟が進んでいない主体（チーム、メンバー）は「アウトプット」に多くの関心を払い、成熟した主体では「アウトカム」に多くの関心が自然と払われるようになるということだ。
生産性を向上させる3側面による整理
基本的な考え方の出発点として、おそらく従来的な製造業を念頭に置いて書かれたと思われる生産性向上の3側面という Web ページから分類を拝借して整理を試みる。
①メソッド（生産方式や業務処理方法）
①メソッド面（M面）とは、現在の標準作業方法を改善し、より良い方法を追及していく取り組みである。たとえば、現在5人で生産している作業を、作業方法の工夫や治具の工夫などによって、3人で作業できるようになるというものである 生産性向上の3側面 | 用語集 | 株式会社 日本能率協会コンサルティング
ソフトウェアエンジニアリングにおいてはチームレベルの業務プロセスや技術利用に当てはめることができそうであり、アウトプットの向上に係る側面と考えられる。
チームワークを見直したり、作業効率が高くなる技術を導入したりなど、開発者がいわゆる開発生産性にアプローチするときはこの部分に伸び代を見いだすことが多いのではないだろうか。
②パフォーマンス（能率や業務実施効率）
②パフォーマンス面（P面）とは、標準作業方法を時間に置き換えた標準時間の達成度を改善し、高いレベルで維持していく取り組みである。たとえば、微小な作業中断の改善や標準作業方法の訓練によって、標準時間の達成度100％を超える上手い作業者に近づける取組で、現場監督者の力量が問われる項目である。また、達成度を常にモニターできる測定システムも重要である。 生産性向上の3側面 | 用語集 | 株式会社 日本能率協会コンサルティング
ソフトウェアエンジニアリングにおいては個人レベルの作業効率に当てはめることができそうであり、アウトプットの向上に係る側面と考えられる。
チームとして生産方式や業務の標準化、環境の整備を前提としつつもソフトウェア開発は依然として工業化されていない領域であり個人レベルの作業効率を高める手段は限られる。寄り道せず最短でコーディングをする装置たれという文脈では今後 AI への置き換えのほうが積極的に進むだろう。
古典的な大規模開発であれば、それ自体の効率性の是非はさておきモジュールごとに定められた仕様書を元に決められた手順で生産するという形が成り立つこともあるだろうが適用範囲は限られそうだ。
③ユーティライゼーション（計画や活用のうまさ加減）
③ユーティライゼーション面（U面）とは、就業時間中に作業ができない状態を改善していく取り組みである。たとえば、仕事の負荷が少ない日は別の職場の応援に行かせる、取り付ける部品の不具合で作業がストップすることを事前に防ぐ、品種切り替えや段取り替えの時間をできるだけ短くするなどの取り組みが必要となる。 生産性向上の3側面 | 用語集 | 株式会社 日本能率協会コンサルティング
ソフトウェアエンジニアリングにおいては組織または上流工程レベルの計画、意思決定に当てはめることができそうだ。
請け負い仕事を除いてソフトウェア開発の多くが、常に価値があると決まったものを生産できるわけではないため、時間あたりのアウトプットの多寡がアウトカムを保証しない。メソッドとパフォーマンスの側面からアウトプットをいくらか効率化しても、アウトカムに繋がらない生産が続けばそもそもの前提が誤っていることになる。
※ アウトプットの多寡がアウトカムを保証しない時点で「お前らが言っている生産性とは一体何なんだ」という声もある。ごもっともだがアウトプットなしにアウトカムも無いので幾ばくかの相関は期待したい。
前向きには試行回数を増やすことを念頭にイテレーションの高速化を志向するのが現代のソフトウェア開発におけるユーティライゼーションだが、例えば「無駄なものを作らない」という意思決定の有無というユーティライゼーションがアウトカムの生産性に最も響くという可能性も大きい。
(余談) SPACE フレームワークについて
The SPACE of Developer Productivity - ACM Queue で示された SPACE フレームワークというものがあって、生産性の観測にはより多角的な視点が必要という話がある。これには「生産性に関わる開発アクティビティの観測」だけでなく「生産性の高い環境を持続させるための観測」が含まれる。
後者は定性的にならざるをえない部分が大きく、定性アンケートや組織・チームのコンディションダッシュボードの観点としては優れているかもしれないが直接的な生産性の議論に営みの持続可能性を混ぜると話が拡がりすぎるため今回は割愛する。
生産性関連データの可視化で何を見いだせるのか
ここまでアウトプットとアウトカムの生産性視点と、メソッドとパフォーマンス、ユーティライゼーションの側面を整理してきた。そもそも我々は生産性の可視化に何を期待しているのだろうか。
アウトカムの厳密な可視化は難しい
生産性の可視化においてアウトプットに連なるアクティビティの可視化は容易だが、アウトプットの結果がアウトカムに繋がったかを解像度高く測定するのはサービスとしても容易ではない。評価のリアルタイム性を鑑みると実際的なアウトカムの代用として、何らかの期待値スコアを用いることになるだろう。開発部門内の責任の分解点によるが評価指標としてもそれほどズレないはずだ。
あるプロジェクトに投下されたリソースとプロジェクトが結果的に生み出した成果を紐付けることは可能だが、その程度であれば人月換算で大まかな勘定はどこでもしている。Jellyfish や Swarima は何らか費用効果として見せる機能を提供しているようだが、個人的にはそれらも魔法のような機能ではなく現実的な枠組みによって意義を示すコンセプチュアルなものと認識している。
機能としてはアウトプットの可視化に比重が寄る
サービスの機能の多くは単純なアウトプットやアクティビティの収集にかなりの比重が寄っているし、サービス提供側としてもそのような機能のほうが提供難度、確実性において現実的である。各社のマーケティングにおいて大きい前提にありそうな「開発部門の説明責任を果たすため」というニーズとは別に「チームの自己組織化とパフォーマンス改善」が巧妙に使い分けられる背景の一端でもあるだろう。
狙える的としてはアウトプット → アウトカムへの変換効率・変換後総量に係るユーティライゼーションが根本的かつ影響度が大きいと思われるが、それでも開発のアウトプットに係る細かいアクティビティから可視化せずにはいられないのがソフトウェア開発の新しい潮流かもしれない。
生産性の可視化を必要としないこともある
盲目的に可視化をすることを推奨することは本意でない。生産性において課題感がない（向上させる必要性を感じていない）、開発部門の生産性について特段の説明責任を求められない、に当てはまるならば可視化サービスは必要ないだろう。
生産性の向上は可視化サービスを用いずとも従来的なチームワーク、チームコミュニケーションによるアプローチが可能だ。その場合もサービスによって定量的な評価・議論ができるメリットはあるが、定量化の副作用に懸念があるならば絶対に必要なパーツというわけでもない。
とはいえ自信をもって可視化による改善を要しない、社内的にどこからも突っ込まれない、という環境は稀なのではないだろうか。
可視化された情報から何ができるのか
現行の生産性可視化サービスの多くはアウトプットに係るデータの可視化、各種の指標提供を主たる機能として備える。
アクティビティ傾向の変化や異常の発見
結論から述べると各種の一次指標（直接のアクティビティデータ）・二次指標（一次を元に見せ方を工夫したデータ）を観測しても即座に具体的な問題や課題を発見することは難しい。ましてや絶対値として意味のある数字が得られるわけでもない。
上下する数字に一喜一憂するのではなく、継続的な観測による傾向の変化や異常の発見を前提として運用するべきだ。これは世間一般のコンディションサーベイサービスでも同様であり、複数要因が絡み合った結果の擬似的な定量に絶対値を見いだすことは難しい。
意思決定における再現性の担保
チームの自己組織化とパフォーマンス改善を念頭に置いたとき、可視化サービスだけで何かしらの意思決定が完結することはない。サービスのデータから得られた洞察を現実世界で検証し、また現実における違和感や得られた仮説のためにサービスのデータを検証するというサイクルが前提にある。個人的には Google Analytics を想起するところだ。
意思決定者の主観とデータによる客観を相互に運用することで、個人やチームという当事者が意思決定の再現性を高められる。あくまで仮説検証における補助的な観測装置であることを念頭に置いておくと健全な運用が期待できる。
説明責任における透明性の担保
時間あたりのアウトプットの多寡がアウトカムを保証しない、と断じてしまったので開発部門の説明責任という話もいよいよ難易度が高いのだが、可視化サービスは少なくともアクティビティのブラックボックス化を解消する。説明責任について特定のサービスだけでそれを果たすことは難しいが、開示すべきを開示して開発部門のコンテキストを理解している人物がそれを説明する上では有用だ。
公開範囲を定義して数字の読み取り方や根底にある生産性の考え方などこ手の可視化サービスを取り扱う上でのコツや前提となる部分を共有しておかないと無用な誤解を生む恐れがあることは注意すべきだろう。
総じて、すべきでは無いこと
可視化サービス自体が一歩間違えれば開発者に対して「お前の ×× が低いから生産性を上げろ」というコミュニケーションを生じさせるセンシティブな特性をもつ。導入の文脈や運用の方法次第では容易にダークサイドに墜ちてアンチパターンを踏み抜いてしまう。
賢明な諸氏であればこそ導入の文脈を整理した上でサービスの導入を検討するはずだが、特に言及しておきたいアンチパターンだけ触れておく。
Common Pitfalls When Designing Metrics | The LinkedIn DPH Framework では指標運用におけるさまざまな落とし穴を紹介されているので、まじめに可視化サービスの導入を検討している場合は一読すると良い。
速度と量の回し車にしない
ネズミを回し車に載せるが如く高回転にしたところでアウトカムは保証されない。開発部門の倫理・誠意においてアウトプットの最大化は善処すべき関心だが、全体としてはアウトカムの最大化が優先されるべきだ。一定のアウトプットで十分なアウトカムが得られているのであれば持続可能な開発体制として肯定できる。
アウトカムが出ていないから開発組織という回し車を速くしようという話が挙がってしまうようなら、それはかなり危険な兆候だろう。（人をすり潰せばお金に変換できる類のビジネスは除く）
意味を見いだせない指標を運用しない
サービスでは色々な数字がとれてしまうからこそ、それぞれの指標に対してどれくらいの意味を見いだせるか、利用者側のリテラシーに大きく依存する。あまり意味のない指標だってあるし、何にでも意味を見い出して使い込もうとしても混迷が極まる。
- その指標の変化に意味を見いだして説明できるか
- 指標の変化に対して明確なアクションが可能なのか
- その指標に誰が対応することになっているのか
このようなことをよくよく考えれば現実的に運用可能で有意義な指標は限定されるので、闇雲にすべての指標を運用しようとは思わないはずだ。SPACE の S (satisfaction and well being) もこのように考えると開発側からはアプローチしづらく、組織マネージャーや人事に委ねたほうが賢明だろう。
どうぞご健康で！
このようなデータの可視化を伴うサービスは自分が欲しい結論のためのデータを拾ってしまうこと（バイアスの作用）が往々にして起こるため仮説検証におけるデータリテラシーが基礎として求められることも覚えておきたい。
人は休むと止まる。対戦よろしくお願いします。
心身の健康以上の開発生産性要素はないので、体力測定とストレスチェックを定期実施しましょう
— あほむ｜副業転職 Offers の overflow (@ahomu) November 1, 2023
