長らく生産性は測定対象として扱われてきました。コードの行数、PR やレビューの回数、バグの密度、カバレッジ率――。断言してもいいですが、生産性を測るのは不毛です。
理由は単純で、プロジェクトという生き物が本質的に複雑だからです。また人間が本質的に怠惰で、自分本位で、かつ解釈にブレのある曖昧な生き物だからです。
体験性（Experiencity） とは、快適に働ける度合いを指します。
似た概念として開発者体験や Engineering Effectivenessがあります。もっとわかりやすいフレーズをいくつか並べましょう:
エンジニアやクリエイターの皆さんは、この感覚はすでに知っているはずです。私達の直感はやはり正しかった。重要なのは管理でもなければ、チームの歯車となることでもありません。快適であることです。
体験性では、快適であれば自ずとベストなパフォーマンスが出るものだと考えます。これを 体験性の原則 と呼びます。この原則があらゆる状況で常に当てはまるとは限りませんが、現代のプロジェクトであればおおよそ当てはまるか、当てはめることができます。
体験性を実際に運用するには、個人なりに、または組織なりに指標を定義せねばなりません。
すでに述べた Engineering Effectiveness はわかりやすいです。thoughtworks 社が提唱した概念であり、出力ではなく入力を測れ、と謳っています。以下、比較を引用します。
| Measure … (INPUT METRIC) | Don’t measure … (OUTPUT METRIC) |
|---|---|
| The time it takes to do code reviews | The throughput of pull requests |
| The amount of interruptions affecting engineers | How many hours engineers have been working |
| The amount of unplanned work affecting a sprint | Sprint points burned by the team |
これはまさに体験的です。「エンジニアリングの仕事に集中できる」という体験を尊重し、その集中の最大化を良しとしています。そして、これを維持するために、集中を削ぐ要因をモニタリングしています。
私が知る限り、体験性をちゃんとつくった例は EE だけです。ですので、まずは EE を使ってみることをおすすめします。自組織なりの体験性をつくるのは、その後でもいいでしょう。
「開発者体験とは何か」と聞かれたら、あなたはどう答えますか？
正解はありません。軽く Deep Research してみるだけでも、様々な組織が様々な定義を使っています。私の方で軽く整理すると、開発者体験の捉え方にはざっくり三つの派閥があります。
つまり、開発者体験という軸で体験性を実装する場合、この三つの派閥の見方について、それぞれをどの程度取り入れるかを考えることになります。
正解はありません。Platform Engineering は「UX 派」にフルコミットしていますし、現代のエンジニアリング組織やビジョンやチームワークといった点を重視していて「実感派」を重視する傾向にあります。
私個人は「ストレスフリーの度合い」が一番重要だと思っており、ナレッジ・アーキテクトとして体験性の実装に携わる際は、各人のストレスフリーの最大化を目指します。たとえば役割分担や多様性といった考え方を使ったり、ティール組織の概念を取り入れたりします。
生産性に代わる概念として体験性を紹介しました。生産性の管理や向上に悩まれている方は、ぜひ参考にしてみてください。それではまた。