生産性向上vs.優先順位付けというプロダクトマネジメント
生産性向上なる課題は、それがエンジニアリング組織の外からの要求であるならば、その解決率はかなり低くなると感じます。そのようなケースの多くは、問題の所在がエンジニアリング組織の外にあるからです。根本的な問題は、やることに「優先順位を付けない」ことではないでしょうか。
私自身の経験から察するに、生産性向上というこの曖昧な課題に秘められた要求は2つです。ひとつは「大きなものを短期間でリリースする」こと。もうひとつは「多くのものを同時にリリースする」こと。
激しい競争の渦中にあるプロダクトほど、それらはより強い要求となります。競合プロダクトに遅れをとりたくはありません。あれもこれも早く作り上げたい。開発チームから提示されるリリース計画では遅すぎて話にならない。と、そんなところでしょうか。
この強烈なプレッシャーが、開発チームに重くのしかかります。おそらく期待されている生産性向上とは、200%や300%といったレベルでしょう。単一期間内で実現可能な開発規模を2倍や3倍に増やすということです。はっきり言って、実現可能性はとてつもなく低い。
そうなると、あとはQCDSで表される「品質（Quality）」「コスト・予算（Cost,Budget）」「納期・時間（Delivery,Time）」「スコープ（Scope）」でのトレードオフしかありません。
ちょっと待ってください。「大きなものを短期間でリリースする」と「多くのものを同時にリリースする」という2つの要求は、納期・時間とスコープに向けられた要求ではないですか。4つの変数のうち、2つの制御権が開発チームに無いということになります。残る品質と予算・コストでのトレードオフが成立するのでしょうか。
生産性を上げるというミッションのもと、納期・時間を短縮したりスコープを広げたりするために、品質を下げる判断を選ぶ組織も多いように思います。さすがに、ユーザー体験に影響するような欠陥だらけのソフトウェアを生み出す真似はしないと思いますが、ソフトウェアの内部的な品質が犠牲になることには目をつぶってしまう。
しかし、内部品質を犠牲にする手段が上手く機能しないことは、この界隈ではいまや誰もが知るところです。いわゆる「技術的負債」がかさみ、結局は生産性を落としていくことになるからです。どうやら、品質での調整は困難なようです。
それでは予算・コストではどうでしょうか。現場判断でこれらを調整するのは難しいでしょう。実現できたとしても、即効性がありそうなのは社外リソースを活用することぐらいですが、調整コストをはじめとするベンダーマネジメントコストが重くのしかかり、なかなか上手くいかなかったりします。
あとは中途採用などを通して内部キャパシティをスケールしていくしかありません。「人が足りない」とボヤくエンジニアリングマネージャーをよく見かけますが、このあたりに背景がありそうです。とは言え、これには即効性がなく、中長期の取り組みになります。今すぐにでも生産性向上を実現したい要求者にとって、そんな長い時間は待てるはずもありません。
このままでは、開発チームの稼働率を上げてでも多くの機能開発を詰め込もうとする力が働きだすことは目に見えています。そのような、エンジニアが常にスケジュールに追われ、擦り減っていくような働き方を強いることは理不尽だし、持続可能性も低いでしょう。
いったいどうすれば良いのでしょうか。ここで一度立ち止まって考えるべきです。優先順位を付けずに「あれもこれも」すべてを早く作ることが、本当に意味のあることなのでしょうか。
「大きなものを短期間でリリースする」、「多くのものを同時にリリースする」という2つの要求は、どちらも「リリースする」ことにフォーカスしすぎて、リリースが不可侵な聖域のように扱われています。しかし、ソフトウェアプロダクト開発では、開発チームの処理能力は制約です。いつまでに、どれだけのものをリリースするかは、この制約に従属して調整しなければ破綻します。
すべてのリリースに等しく価値があるとは思えません。「搭載された64%の機能はほとんど、あるいはまったく使われない」と言います。制約に従い、妥当だと思える優先順位を付け、そのスコアが低いものは作る前に計画を破棄する。無駄な開発を可能な限り避け、成功率を上げていく。そうすれば、2倍や3倍といった生産性向上よりも高いパフォーマンスが得られるはず。
プロダクトマネジメントとは、そういうものではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？