そのプロセスが開発チームのパフォーマンス発揮を阻害する
ソフトウェアプロダクトに対する新たなアイデアや改善要望は、日々、途切れることなく生まれ続けます。このペースに開発チームのパフォーマンスが追いついていない状況は、プロダクトマネージャーにとってもどかしいものです。一見すると、このような状況はエンジニアの人手不足に原因があるかのように思えますが、実はバリューストリーム上のプロセスに問題があるのかもしれません。
問題を生じさせるプロセスはどこか
一般的なバリューストリームは次のようなものだと思います（参考：『リーンエンタープライズ』）。
既存プロダクトに新たなアイデアや改善要望を取り込んでいくために、まずビジネス担当が中心となって「設計と分析」「承認」を通じて企画が進められ、「リリース計画と見積り」を経てエンジニアリングチームによる開発が進んでいくフローです。
ここで問題を起こしやすいのが、「設計と分析」「承認」の2つと、その影響を受ける「リリース計画と見積り」です。これらのプロセスブロックの組み立てが悪いと、その後に控える開発以降のプロセスのパフォーマンスを悪化させてしまいます。
「承認」での議論対象が詳細すぎる
企画したアイデアを開発に進める承認を得るために、どのような情報を揃えなければならないかは組織によって異なります。基本的にはここで、仮説としているユーザー価値やビジネス価値を中心として議論されるはずです。
しかし、ユーザインタフェースを中心とした外部設計や細部の仕様についての議論に時間が割かれることが多いようなら注意が必要です。これでは「承認」と言うより「レビュー」です。承認プロセスでそのような議論が繰り返されると、「設計と分析」でのアウトプットは外部設計レベルに及ぶようになります。その結果、「ビジネスサイドによる企画」と、「エンジニアサイドによる開発」という分断が進み、それぞれがサイロとなってウォーターフォール的なフローが構築されていきます。
このように分断された状況では、エンジニアが受け取る「承認」プロセスブロックからのアウトプットのサイズがとても大きなものとなります。外部設計として完成形に近いものになるからです。
しかも、承認を得たその外部設計は、エンジニアからの差し戻しがしづらい状況になります。「リリース計画と見積り」の結果、期待される期日までに実現するのが困難であっても、スコープを調整するにはまた外部設計レベルでの見直しを行い、「承認」という名の気の重い「レビュー」プロセスを通さなければなりません。そんなことをしていたら、手戻りコストが大きすぎて、スコープ調整によって得られるはずの開発期間が失われてしまいます。
ビジネス担当者としても、承認を得た外部設計は、承認者に対するコミットメントになっています。加えて、承認を得る過程で、おおよそのリリース日も合意が交わされることも多いでしょう。つまりこの時点で、開発スコープとリリース日がロックされてしまうのです。
この状況はトレードオフ不全です。開発スコープが大きすぎたり開発難易度が高すぎても、スコープとリリース日のどちらも調整できない、あるいはやりづらい。そのような新たなアイデアや要望が、日々、途切れること無くプロダクトバックログに追加されていき、エンジニアリングチームに渡されていくわけです。当然ながら、エンジニアリングチームはそれらを捌ききれません。
「設計と分析」に時間をかけすぎる
「設計と分析」の平均プロセスタイムが長過ぎるケースも要注意です。ここで言うプロセスタイムとは、ひとつのアイデアや改善要望に関する「設計と分析」に要する実質の時間です。
「設計と分析」での長過ぎるプロセスタイムは、開発スコープを大きくするだけでなく、サンクコスト効果となって「リリース計画と見積り」でのスコープ調整を困難にします。このプロセスブロックの担当者にとって、時間や労力をかけた分だけ、そのアウトプットの詳細まで全てが「捨てられない重要なもの」と感じるものとなるからです。先述したような、「承認」プロセスブロックで外部設計レベルの議論が交わされる組織は、「設計と分析」のプロセスタイムが特に長くなり易いと考えられます。
「リリース計画と見積り」でのスコープ調整に、「設計と分析」の担当者が関わらないことでこの問題は回避できそうにも思えますが、この手段は少々非効率です。「設計と分析」のアウトプットについてエンジニアリングチームに説明する役割は、その内容に詳しい人がやるべきです。それなら「設計と分析」の担当者が最も適しています。加えて、説明する役割を別のビジネス担当者が実行するためには、引き継ぎコストも発生してしまいます。
このようにして、開発スコープが大きくなる傾向が高まる一方で、スコープ調整もリリース日の調整もできない、あるいはやりづらいというトレードオフ不全がここでも発生してしまうのです。
トレードオフ不全がフローを詰まらせている
以上のように、「設計と分析」「承認」におけるプロセスが、スコープの肥大化と固定化を促進し、「リリース計画と見積り」におけるトレードオフ不全を引き起こしていることがわかります。それが、バリューストリームのフローを詰まらせているわけです。
ソフトウェア開発にはトレードオフが欠かせません。その調整弁としてよく使われるものが、いわゆるQCDにスコープ（Scope）のSを加えたQCDSです。しかし実際のところ、Qを調整弁に使うことはできませんし、Cが調整弁として機能するケースもまれでしょう。残るは、DとSです。
肥大化したSが固定化されてしまっているなら、Dで調整せざるを得ません。しかし、Dを調整弁とするのはビジネスにおいて好ましい選択ではありません。そのため、Dを固定化しようとする力も働きます。このようなトレードオフ不全の中、Qのうちの内部品質を犠牲にしたり、エンジニアリングチームが残業でカバーしながら、それでも時間が足りず、結局はビジネス担当者とエンジニアリングチームで話し合い、渋々と、SやDを逐次的に微調整していくことが繰り返されるようになるのです。
このような状態が続けば続くほど、承認を経た開発案件が未着手のまま積み上がっていきます。そうすると、開発の優先順に入れ替えが頻発するようになります。そして、この調整コストがエンジニアリングチームの時間を更に奪う結果となります。
フローを改善する
これらのトレードオフ不全とその副作用を抑制するには、バリューストリーム上のプロセスに潜む問題に対峙するしかありません。ここで挙げた問題とは、次の2つでした。
「承認」での議論対象が詳細すぎる
「設計と分析」に時間をかけすぎる
ひとつめの「承認」問題について考えられる原因は、プロセスでフォーカスすべきことと、そうでないことを明らかにしていないことではないでしょうか。
例えばここでフォーカスすべきこととして、ユーザーやビジネスにとっての価値（User-Business Value）があります。経済価値であれば売上や粗利などで表現できますし、MAU（Monthly Active Users）やアプリのダウンロード数といったメトリクスでも良いでしょう。開発に進めようとするアイデアや改善要望などをリリースすることで、どのような価値を生み出すかを数値として表現するわけです。
ユーザーやビジネスにとっての価値以外にも、リリース時期に対する制約の強さ（Time Criticality）や、将来のデリバリーリスク軽減効果やビジネス機会創出の可能性（RROE, Risk Reduction and/or Opportunity Enabling value）なども合わせて数値化すると良いでしょう。
実際にはこういった数値を見積もることは難しいため、相対見積もりをおすすめします。過去にリリースしたあるフィーチャーを基準値として、今回のアイデアや改善要望がその何倍の価値があるか、といったように見積もるのです。
こうした数値を事前に見積もっておくことで、「承認」時の議論は、見積りの妥当性にフォーカスして、その新たなアイデアや改善要望を評価するようになるはずです。
ふたつめの「設計と分析」問題については、このプロセスブロックで何をやるかとそのスケジュールを明らかにすることで概ね解決できそうです。
また、「設計と分析」にエンジニアリングチームが参加することも解決策として期待できます。そうすることで、「リリース計画と見積り」でのトレードオフの必要性が最小化するように、「設計と分析」時のアウトプットが最適化されるようになるからです。さらに、「ビジネスサイドによる企画」と「エンジニアサイドによる開発」という分断問題も解決・緩和することもでき、一石二鳥です。
もちろん、エンジニアリングチームの担当領域が広がれば、エンジニアが開発に割くことができる時間がその分だけ減ってしまいます。これもまたトレードオフです。最終的に、バリューストリーム全体として最もパフォーマンスが高いプロセスを構築するという観点で判断すべきでしょう。
関連記事
今回の記事と近いテーマを組織の「アジリティ」に注目して紐解いた記事がこちらです。
本記事で取り上げたUser-Business ValueやTime Criticality, RROEは、「遅延コスト」の構成要素です。その詳細は、はてなブログに書いた記事にまとめてあります。
「ビジネスサイドによる企画」と「エンジニアサイドによる開発」という分断問題については、はてなブログでも取り上げました。
この記事が気に入ったらサポートをしてみませんか？