見出し画像

開発生産性フレームワークSPACEについての覚書

dora_e_m

はじめに

自分たちのチームがどういう状態なのか推定するための指標として、開発生産性フレームワークSPACEの活用を試みているところです。いまのところは概要記事を読んで、元の論文をざっくり読んで、それをもとに「自分たちで追いかけるならこういう指標かな？」って考えて、チームに共有して、みんなでどうするといいだろうねって考える段階。だからnoteとかにまとめるのは、もうすこしカッチリ言語化できたり、その指標を追うことで何か変化が起こったタイミングにしようと思っていました。

先日参加した「EMゆるミートアップ vol.6〜LT会〜」で、HACOBUのけんにぃさんが「チーム実績をSPACEで表現してみるチャレンジ」という発表をされていました。なぜSPACEで表現してみようと思ったのか、何に気をつけているのかなどがコンパクトにまとまった良いLT資料なのでぜひ目を通していただいたのですが、この発表を聞いて「そうか、どう活用しようか考えている途中のプロセスを聞くのは十分に価値のあることだな。」と感じました。

なので、自分がSPACEについて考えていることも役に立つだろう、と信じてnoteにまとめることにしました。少なくとも明日の僕の役には立つだろう。

SPACEとは

LeanとDevOpsの科学の著者の一人でもあるNicole Forsgren氏が著者に名を連ねる論文の中で提唱されているのが、今回の主題であるSPACEフレームワークです。

開発生産性を計測しようとしたときに、ひとつの指標に着目してしまうと「数値ハック」のような事象が起こりえます。（何もこれは開発生産性に限ったことではなく、目標を数値で追いかけるときにつきまとう永遠の課題ですが）
SPACEではそういった課題に対処するためにバランスよく指標を選定することを提唱しています。

Satisfaction and well being

  • 開発者が自分の仕事、チーム、ツール、文化にどれだけ充実感を感じているか

  • 開発者がどれだけで健康で幸せであるか、仕事がそれにどのような影響を与えているか

Performance

  • システムやプロセスの成果

  • 品質: 信頼性、バグのなさ、継続的なサービスの健全性

  • 影響: 顧客満足度、顧客導入と維持、機能利用、コスト削減

Activity

  • 業務遂行の過程で完了したアクションやアウトプットの数

  • 設計とコーディング: 設計文書や仕様書、作業項目、プルリクエスト、コミット、コードレビューの量や数

  • 継続的インテグレーションとデプロイメント: ビルド、テスト、デプロイメント/リリース、インフラの利用回数

  • 運用活動: インシデント/問題の数または量、およびその重大度、オンコールへの参加、およびインシデントの軽減に基づく分布

Communication and collaboration

  • どのようにコミュニケーションしどのように協働するか

  • 文書と専門知識の発見可能性

  • インテグレーションの速さ

  • チームメンバーが貢献した仕事のレビューの質

  • 誰が誰とどのようにつながっているかを示すネットワーク指標

  • 新メンバーのオンボーディング時間と経験

Efficiency and flow

  • 中断や遅延を最小限に抑えて仕事を完了させたり、進捗させたりする能力

  • プロセス内のハンドオフ数、プロセス内の異なるチーム間のハンドオフ数

  • フロー状態を作り出す能力

  • 中断の数、タイミング

  • 時間: 合計時間、価値を創出している時間、待ち時間

SPACEはどうやってつかうといいの?

論文のHow to Use the Frameworkを読むと、複数のディメンションのメトリクスを取得することを推奨しています。少なくとも3つのディメンションから取ることをおすすめしているとのこと。

これはどういうことかというと、ビルド回数やテスト回数をすでに指標として計測しているときに、プルリクエストの数、インシデント発生頻度などを指標として追加しても、SPACEが目指す多面的な評価はできないということです。たしかに。

そして、少なくとも1つには調査データなど知覚的な尺度を含めよう、とのこと。定量的に計測できるもの以外の、人間の心理に踏み込んだ情報を入れ込んでおきたいということなのかな？という理解をしています。

ここまで、とてもざっくりとSPACEについて紹介してきました。ここからは、今私が考えていることの覚書になります。

自分たちのチームにどうやって適用するといいだろう

まず、5つのディメンションを眺めながら、自分たちのチームにとってどんなメトリクスを設定すると嬉しさがあるのか考えてみました。

  • Satisfaction and well being

  • Performance

  • Activity

  • Communication and collaboration

  • Efficiency and flow

Satisfaction and well being。計測するのがとても難しそうですが、これはぜひとも指標化したい。チームがいきいきしていると、自分たちでも驚くようなパフォーマンスを発揮していくものです。逆に、ふだんいきいきしているチームがちょっとシナシナしていたとしたら、メンバーの誰か、もしくはみんながアンハッピーになっている可能性があります。一緒に働く仲間がアンハッピーだったらアンハッピーですよね。だから、測れるものなら測りたい。毎日検温しておこうぜ！みたいなイメージ。

Performance。これもとっておきたい。自分たちが充実感を得ていて、そのうえでチームが成すべきことが成されているというのは非常に重要なポイントです。充実感を感じているけど顧客がなにひとつ満足していないとしたら、チームのあり方は見直さなければならない。

Activity。アウトプット量については、開発生産性を測定するうえで重要な要素です。また、Satisfaction and well beingやPerformanceと比べると、自分たちでコントロールの効きやすいディメンションです。努力がストレートに反映されていく。一方で目標達成自体が目的化すると数値ハックが起こったりするので、用法用量に注意ではあります。

Communication and collaboration。コミュニケーションやコラボレーションしやすい状態が整っているか？を計測するとよさそう。新メンバーのオンボーディング時間とかいいかもしれない、と思いました。

Efficiency and flow。いかに効率的に働けているか、フロー状態に入れているか。うーん、これは難しいな。いわんとしていることはわかる。フロー状態に入っておくことは大切。なんだけど結局フロー状態になったかどうか自体は計測が難しいから、周辺の数値をとることになりそう。論文にある中断の数とかになるのかもしれないけど、「外部からの問い合わせを遮断します」という意思決定の誘発にもつながる。
今のチームでそうなっちゃうとは考えづらいけど。
※2024/03/04追記 けんにぃさんが「レビューの待ち時間とかCI、テストの実行待ち時間も指標の対象になるよ」とコメントしてくれました。ここについては、自分たちのチームはペア/モブ主体でやっているのでレビューの待ち時間は発生しづらい、テストについても昨年末にjest->vitest移行した結果かなり高速になったので、現時点では追いかけたい指標として設定する優先順位が低いと判断しました。コメント感謝！

ディメンションと指標を選択する

いまのところ、以下の指標を選択しようかな、と思っています。

  • Satisfaction and well being

    • チームのwevoxスコアを使う

      • 会社全体で使用しているものだから活用しやすい

      • 自分で状態を考えて回答するサーベイ形式のものだから、うまく主観を乗せやすい

      • ただ、wevoxスコア自体を目標にしちゃうとみんなが入力する数値に偏りを発生させてしまわないか？は心配

  • Performance

    • プロダクトの利用数や顧客の行動変容を指標にする

    • ここはPdMと相談して目下検討中

  • Activity

    • シンプルにデプロイ数/頻度がよさそう

    • 仮説検証サイクルを高速にまわしていきたい、というチームのあり方を考えると、「自分たちが満足いくくらい仮説検証サイクルをまわしたとしたら、どれくらいデプロイしてる？」というのが目指す指標になりそう

当初はCommunication and collaborationで新メンバーのオンボーディング時間も設定しようと思っていたのですが、メンバーたちと話している中で「その指標を設定することでチームがよりよくなるイメージ」があまり湧いてこなかったので、思い切って設定しないことにしました。

現時点での自分なりのベストであって不変のものではない

いまのところは、こんなかんじでSPACEを活用してみようと思っています。けんにぃさんがスライドで紹介していたようにFIndy Team+、ふりかえりの付箋数、ファイブフィンガーを活用するのも面白そうだから、どこかで試してみようかな。
大事なのは、どうなっていたいかを描くこと。それを示す指標はなんだろう？と考えること。そして実際に計測してみること。
やってみたら思っていたのとは違った、というのはよくあることなので、もっといい指標があるかも？と思ったら変更してみたり、ちょっと今はいい指標がないかも？と思ったら計測自体辞めてみるのも１つの手段です。

SPACEについてはまだわかっていないことが多いし、世の中の活用事例もそこまで多くない気がするから、これからいろんなケーススタディが出てきたり、このnoteに対してリアクションしてもらえたりすることを期待してます。

この記事が気に入ったらサポートをしてみませんか？