実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】

昨今、「開発生産性向上」や「ベロシティを高める」といったフレーズをよく耳にします。プロダクトマネジメントの一環としてこうした指標を取り入れるチームも増えてきました。しかし、アジャイルコーチとしてさまざまなプロダクト開発チームを支援している吉羽龍太郎さんは、「この流れには危機感を覚える」と発信しています。

なぜ吉羽さんは警鐘を鳴らすのでしょうか。アジャイルのエキスパートである彼から、プロダクトマネージャーやプロダクトオーナーに「開発生産性を測ってもなんだかうまくいかない」という組織を好転させるためのアドバイスをいただきました。

• keyboard_arrow_down アジャイルなプロダクト開発において、“生産性”は取扱注意
• keyboard_arrow_down 「開発生産性」に頼りたくなるのは「逃げ」
• keyboard_arrow_down 負のループから抜け出したいなら「動くものを見せる」に集中するべき

——2023年末、吉羽さんがXで「生産性」の捉え方に疑問を呈する内容の投稿をされていたのを拝見しました。どんな経緯があったのですか？

吉羽：2023年の夏、米系コンサルティング会社が「ソフトウェア開発者の生産性は測定できる」といった趣旨の記事を公表したところ、アジャイル開発の有識者たちが一斉に反論して話題になりました。

ここ数年、アジャイルなプロダクト開発にかかわる人々の中で「開発生産性」や、開発の進行速度を数値化した「ベロシティ」といった言葉が濫用気味になっているのが、私自身も気にかかっていたのです。

——作業時間やコストを成果物の量で割れば開発生産性は容易に測れるはずですが、なぜアジャイル開発の有識者たちは反論したのでしょうか？

吉羽：「生産性」という言葉の意味をもう少し詳しく紐解くと、「物的生産性」と「付加価値生産性」に分けられます。「物的生産性」は、投下した資源に対してどれだけの物量を生み出せたかを知る指標です。対して「付加価値生産性」は、どれだけの価値が創出されたか、乱暴にいえばプロダクトでいくら儲かったかを測るための指標です。

前述の米系コンサルティング会社の主張は、「開発者個人」の「物的生産性」は計測できる、と受け取られかねない内容でした。しかし、アジャイルなプロダクト開発の強みは、「物量」を担保することではなく、「価値」を生み出せることにあるのです。

あらかじめ開発すべきものが決まっており、工程の手戻りをよしとしない工業製品の開発ならまだしも、アジャイルに試行錯誤しながら価値を届けることを前提としたプロダクト開発に「物的生産性」の指標を適用するのは、効果的とは言えないでしょう。それどころか、物的生産性を担保するために価値のないものを大量に生み出すというように、「生産性」という指標がマイナスに働いてしまうこともありえます。

「物的生産性」と「付加価値生産性」の区別をつけないまま、一括りに「生産性」を測ったところで意味がなく、むしろ悪影響だ、というのが反論の内容です。

——物的生産性を計測したところで、アジャイル開発の推進には貢献できない、ということでしょうか？

吉羽：その通りです。開発者や開発チームの物的生産性を数値化したところでプロダクトの成功率は高まりませんし、ましてや失敗のリスクを下げるわけでもない。物的生産性を測るために労力を割くくらいなら、最小限の機能を実装したプロダクトをリリースし、ユーザーのフィードバックを受けながら検証と改善に取り組むなど、価値提供にコストを費やす方がはるかに健全ですし、プロダクトの成功に直結します。

もちろん物的生産性の計測は意味がないとはいいませんが、付加価値生産性を担保できた上で、価値提供の総量を高めることを意識し始めた段階ではじめて検討すべき指標です。

——物的生産性が高い、つまりたくさん効率的につくれるということは、たくさん失敗できるってことでもありますよね。量が質を担保すると考えれば、物的生産性を見ることにも一定の意味があるのでは？

吉羽：物量を生み出す能力が高ければたくさん実験できる、という意味では正しいのですが、それを加味しても付加価値生産性を重視すべきなのは変わりません。

そもそも「アジャイル」という考え方は、早く安くプロダクトを生み出すための方法論ではなく、変化に対して柔軟に対応しながらプロダクトの価値を高め続けるために編み出された方法論だからです。

言うなれば、アジャイルという手法は「物的生産性」が低いんです。事実、アジャイルのフレームワークの1つであるスクラムにおいては、スプリントプランニングやデイリースクラム、スプリントレビュー、スプリントレトロスペクティブなど、全体の3割近くの時間を開発以外に費やしています。これは物的生産性を高めるためでなく、プロダクトの価値を高めることに振り切っているからできることです。

物的生産性を高めたいなら、ウォーターフォール方式で決まった機能を決まったように開発すればよくて、アジャイルを取り入れる必要はないと思います。

——「生産性」という言葉が独り歩きしてしまい、アジャイルなプロダクト開発の本質からズレてしまったと感じます。

吉羽：そう思います。ひとたびプロダクトをリリースすれば、お金を生み出しているかどうかはすぐわかります。その上で「さらに成果を上げるために物的生産性に目を向ける必要がある」と開発者自身が声を上げるのであればまだいいのですが、開発チームの外にいる人たちがチームを管理する目的で「開発生産性」という指標を用いようとするのは、明らかな間違いだと思います。

——だとすると、なぜ多くのプロダクト開発チームは開発生産性の計測に頼るのでしょうか？

吉羽：ひと言でいえば不安だからです。

アジャイルでは、一定間隔内で実際に動作可能なソフトウェアをつくって関係者に見せ、レビューを受ける機会を設けるのがセオリーとされています。でも、開発がうまくいっていないとき、約束した期日までに動作するものを見せられていないこともよくあります。

こうなると、ステークホルダーは「コストはかかっているが、本当に進んでいるのだろうか」と、そして開発チームも「自分たちがリソースをかけてつくっているものは、本当に価値貢献につながっているのだろうか」と不安を覚えてしまう。そのような不安から、「物量」というわかりやすい計測指標に逃げてしまうのでしょう。

——「動くものが出せない」という状況に陥ってしまうのはなぜでしょうか？

吉羽：開発チーム、PM、経営者など、プロダクト開発にかかわる人が、「アジャイル」の意義や考え方を正しく理解できていないまま、枠組みだけはめて実践しようとするからです。あらかじめ定義した仕様を納期と予算の枠内で実現することがプロダクトの成功と捉えていたり、ハードウェアを量産するような感覚でプロダクトを開発しようとしたりする組織によく見られます。

開発チームの意向を反映しないまま、実装する機能やリリース日が決められたり、そうした無茶なオーダーをPMが却下できなかったりする。また、開発チームが自ら実力を超えた計画を立ててしまったり、ステークホルダー側の意向を忖度して無理をしてしまったりすることもありますね。こうした歪みが積み重なり、プロダクトチームが機能不全に陥ってしまいます。

アジャイルが目指すのは、企業に利益をもたらす価値の創出であり、それがプロダクトの成功につながります。プロダクト開発はいわゆる「プロジェクト」のような、終わりがある類いの取り組みではなく、試行錯誤を重ねて改善を重ね続けることによって価値を増大させていくもの。そうした基本的な理解を欠いているからこそ起こる問題です。

——無茶なオーダーが積み重なって動くものが出せなくなり、動くものが出せないから不安になって有効でない指標を測り、開発にさらに悪影響をもたらす…。こうした負のループから抜け出すには、どうしたらよいのでしょうか。

吉羽：まず、プロダクト開発にかかわる全員が「アジャイル」の意義や考え方を理解する必要があると思います。特に「何をつくってどう価値を届けるか」を決めるPMと、実際にプロダクトをつくる開発チームには深い理解が求められます。機能のリリースや変更の影響を受けるセールスチームや経営者も、「アジャイル」という手法をとる目的や進め方の基礎くらいは、しっかり理解しておいた方がいいでしょう。そうでなくては、PMの判断や開発チームの動き方を誤解されたり、過度に期待されたりして、歪みが出てしまうと思います。

アジャイルへの理解を深めたいなら、関係者を巻き込んで輪読会なり勉強会なりを実施して共通認識を育てるとよいですよ。それだけでも、アジャイルの基本から逸脱してしまう恐れはかなり減るはずです。

——とはいっても、ひとりひとりがアジャイルへの理解を深めるには、一定の時間が必要そうです。機能不全に陥ってしまったチームの状況を少しでもよくするために、すぐにできることはないですか？

吉羽：それなら「動くもの」をつくって関係者に見せることに集中するべきでしょう。動くものを出せないことによって生じる不安をまず解消するのです。

定期的に動くものを見せられる状態をつくりたいなら、実装すべき機能を絞り込むことに尽きます。プロダクトの品質は、達成すべきスコープと開発期間、コストの三角形で成り立っており、同時に満たせるのはふたつまでです。健全な状態でプロダクトに向き合えていないなら、まずは1スプリントで実現するプロダクトバックログアイテムを本当に大切なものだけに絞って、それに集中すること。そして、「動くもの」としての成果（インクリメント）を確実に見せましょう。大事なところから手をつけ、評価を積み上げながら開発を前に進めていくのがアジャイルの基本姿勢ですからね。

——プロダクトマネージャーやプロダクトオーナーの手綱さばきが重要になりそうですね。

吉羽：各方面から「あれもつくりたい、これもつくりたい」、「この機能がほしい、あの機能もほしい」という声が聞こえてきたとしても、できないものはできないと伝え、開発の指針と優先順位を示しつつ物事を前に進めるのが彼らの仕事です。アジャイルなプロダクト開発をよりよく行うためには、開発チームが自らの創造性と自由を守り、開発の主導権を握ることが欠かせませんから。

プロダクトマネージャーやプロダクトオーナーが、価値の最大化に責任を負う立場である以上、安請け合いをしたり期待値のすり合わせを怠ったりするようでは、職務をまっとうしているとはいえません。エンジニアが常に追い立てられているような状態が続けば、開発チームのモチベーションは確実に下がりますし、離職リスクも高まります。様々なステークホルダーとの合意形成は簡単にできることではありませんが、プロダクトの価値を高められる開発を健全に行いたいなら、理想を阻んでいる現実としっかり向き合うべきだと思います。

とはいえ、プロダクトマネージャーとプロダクトオーナーが、価値の最大化のためのすべてを担う必要はありません。スクラムマスターやプロダクトオーナーでなくてもできることはあるはずです。それぞれがそれぞれの立場で最善を尽くすことによって、アジャイルのあるべき姿の実現を目指してほしいですね。

取材・執筆：武田敏則
編集：光松瞳・王雨舟