Outcomeと開発生産性

「完了」か、「完成」か

もうずいぶん昔の話になる。Certified ScrumMasterのコースを受けたときに、Whyは大事だよという話を聞いた。その時はレンガ積みの話で、ただレンガを積む作業をするだけではなくて、「何を作るか」を知ることで、工夫がうまれやすくなるよねという話だったと記憶している。

ここでいうレンガを積む作業で大事なことは生産性で、それは時間あたりの積んだレンガの数で表現されることが多い。一方で、レンガの壁を作るには、毎日最大限のレンガの壁を並べることよりも、工夫で早くなる余地があるかもしれない。それは生産性という数字だけでは表現できない。しかし、そちらの方が価値を素早く提供できることになる。

アジャイルが広まってきて、個人で取り組むもの、チームで取り組むもの、から、組織で対応するもの、になってきた。最近は、「開発生産性」というキーワードが飛び交っている。ここでいう「開発生産性」は、DevOpsから生まれた"Four Keys"を発端とするキーワードで、アジャイルなプロダクトチームはイテレーションごとに"レトロスペクティブ"をやることで、KAIZENを進めていくために、そのKPI的な指標として用いられることが多いと感じている。

アジャイルは、レンガ積み作業を効率よく完了させることを目指したものではなく、ユーザーに"Just in Time"にプロダクトを提供することで、プロダクトの価値を最大化することを目指したものだ。DevOpsや、そこから生まれた"Four Keys"は、変化に柔軟に適応できるチームを作ることに貢献できるが、それだけでプロダクトの価値が最大化するわけではない。

何のための「開発生産性」か、は常に意識したいなと思う。

当たり前機能の肥大化

RSGT2024のクロージングキーノートは、狩野さんだった。あの狩野モデルを作った狩野さんだった。セッションの中で、こんなことがあった。

テレビにリモコンがつき始めた頃はリモコンは「魅力的品質」だった。今は、テレビにリモコンがあるのは「当たり前品質」だよね

大きな組織、特に大きなブランドを持ったプロダクトを見ていると、この「当たり前品質」が肥大化しているのを感じる。例えば、ユーザー登録や、アカウント削除などの機能は、プロダクトの価値を知るためのコア機能にはならないのだけど、ブランド的に"持っていて当たり前"の機能になる。
それ以外にも、デザイン的に、UI的に、ここまでは担保しなくちゃいけない、みたいなものがあったりする。

こうやって、本当にユーザー提供したい、もしくはユーザーが使ってくれるか検証したいコアバリューを提供する前に検討が必要な量が増えていき、開発に必要な量が増えていく。プロダクトバックログの先頭が"テンプレート"になっていく。

そのような開発を見ていると、「当たり前品質」部分をウォーターフォールで作り込んでしまいたくなるのもわかる。そうすると、いわゆる「開発生産性」（単純化すると単位時間あたりのコードの行数とかFPみたいなもの）を指標として採用したくなる気持ちも出てくる。

最後に

アジャイルなプロダクトチームに必要なのは、Outcomeを提供できたかどうかに尽きる。それは、プロダクトがユーザーの行動変化を誘発することが、"金儲け"に直結しやすいからだ。Outputの提供では何も変わらない。

さまざまな邪念を振り払い、理性的に・論理的に、Outcomeを求め続けられる組織であり続けられるかが、プロダクトチームのありようなのだと今は感じる。