ビジネスインパクトのない新機能に費やす時間とコストを低減する
リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。
このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。
失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。それが繰り返されると、組織全体の士気が落ち、学習性無力感に支配されていきます。ソフトウェアプロダクトは、そのマネジメントにおいて、常にこれらのリスクを抱えています。
本記事では、機能リリースに伴うこのようなリスクを制御する方法について考えます。
期待する成果が得られないことを前提に計画する
機能リリースが期待どおりのインパクトをビジネスにもたらすかどうか。それを事前に予測し、世の中に送り出すべきアイデアを正確に選別することなどできるのでしょうか。
マイクロソフトによる自社プロダクトを対象とした研究結果からは、そのような予測がいかに難しいかがうかがえます。A/Bテストをはじめとする対照実験において、期待どおりの価値を示したアイデアの数が、全体のたった1/3だったのです。残りの2/3のアイデアには、価値がなかったか、あるいは逆に価値を損なわせるものでした。次の円グラフは、この結果をもとに作成したものです。
また、Netflixは自分たちのアイデアの90%が間違っていると言い、Amazonでは成功率が50%を下回ると言う。ソフトウェア産業におけるアイデアの成功率は、対照実験によって科学的に評価した場合、50％以下であるという報告で溢れているようです。
これらについての詳細は、はてなブログの記事『リリースした新機能や改善の多くに価値がないという調査結果が意味すること』としてまとめています。
アイデアの良し悪しの予測に関する人間の感度というものは、これほどまでに信頼できないものだということです。「このアイデアは必ず成功する」といった楽観的な期待に基づいてリリースを繰り返す行為や、大規模なリリースを行う行為が、いかに無謀であるか。
ソフトウェアプロダクトの開発やマネジメントに携わる私たちは、これを念頭に置く必要があります。つまり、開発計画や開発プロセスそのものを、この現実を前提として受け入れて最適化すべきだということです。
プロジェクト期間中に何度もリリースする
ソフトウェア業界のプロジェクトを定期的に調査して作成されるCHAOSレポート（Standish Group）は、かつて、一部のひとたちに問題視されたことがありました。プロジェクトの「成功」を測る評価基準が、「期限内、予算内、要件通り」と定義されていたからです。要件通りにソフトウェアが完成したからといって、それが価値を生み出すとは限りません。
その批判を受けてなのか、2015年版のCHAOSレポートからは、「要件通り」ではなく「当初のスコープに関わらず顧客とユーザーに満足をもたらした」ことを評価するよう変更が加えられています。
先述のような「このアイデアは必ず成功する」という思考は、「リリースすること」をプロジェクトのゴールにしてしまいかねません。リリースさえすれば成果が手に入ると信じているわけですから、プロジェクトの予算と期間いっぱいを使って機能を開発し、それらをプロジェクト期間の最後にリリースするという計画を立てることになります。つまり、「期限内、予算内、要件通り」を目指します。
その行く先は、マイクロソフトの調査にもあるように、高い確率での失敗です。期待どおりの成果が得られません。
しかし、その時にはもう、それをリカバリするための期間も予算もプロジェクトには残されていません。
プロジェクトの本来の目的は、プロダクトのユーザー価値を高め、それに伴ってビジネス価値を高めることのはず。プロジェクトは、それらを計測する指標に基づいたゴールが設定されるべきでしょう。そうすれば、プロジェクトの予算と期間は、プロダクトのユーザー価値・ビジネス価値が期待値に達することに費やされることになります。
その活動の中ではもはや、リリースはプロジェクトの最後に1度だけ実施されるものではなくなります。プロジェクト期間の間、トライ&エラーを繰り返しながら、価値を高めていくアクションとしてリリースサイクルをまわすことが自然です。
ユーザー価値・ビジネス価値に対し、1度めのリリースで効果がなかったなら、2度めはアプローチを変えてリリースする。うまく行けば、その方向性でさらに機能を改善・追加してリリースする。この繰り返しでプロジェクトの本来のゴールを目指します。
「ロードマップには、機能を書かずに数字やアウトカムを書く」というプロダクトマネジメント手法は、この観点で、とても理に適っていると思います。
リリース1回あたりのバッチサイズを小さくする
プロダクトの長いライフタイムにおいて、プロジェクトは何度も繰り返されます。そして、プロジェクトの目的は、プロダクトのユーザー価値・ビジネス価値を高めることであり、そのゴール・目標は、それら価値を計測する指標を高めることです。その実現のため、プロジェクト期間の中で、リリースは何度も繰り返されます。これがプロダクト開発のサイクルです。
プロジェクト期間内で複数回のリリースを繰り返すわけですから、たった1度しかリリースしない従来の手法と比べ、1回あたりのリースが扱うスコープは小さくなります。
このようなリリーススコープの縮小、つまりバッチサイズを小さくすることには、いくつも利点があります。たとえば、個々のリリースのため開発に費やした時間やコストが小さい。それゆえ、リリースがもし期待する効果を得られなかったとしても、そこで無駄になった時間とコストが小さく抑えられます。そのような失敗による手戻りコストが小さくなることも利点でしょう。さらに、小さな開発とリリースは、その複雑性や難易度を押し下げることになり、リリースに失敗してトラブルを引き起こすリスクも下げることができます。たとえトラブルが生じたとしても、その影響も小さくなる可能性が高い。
これらの利点はいずれもプロジェクトをフェイルセーフに近づけます。「安全に失敗できる」という点で、ビジネスリスクを下げるだけでなく、プロジェクトメンバーの心理面でのストレスも軽減します。
前回の記事『ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する』で、「バッチサイズ」の代替指標である「デプロイの頻度」を計測すべき対象としてあげたのは、こういった理由もありました。
小さくするには経験とスキルと意思が必要になる
一方で、スコープを小さくすることに対して、チームや関係者の間で反対の声があがることもあります。「ユーザーに対して十分な価値を提供できなくなる」といった意見や、「ユーザーや市場に対するインパクトが小さくなる」といった意見が主であるように思います。
前者の意見は、関連するひとまとまりの機能一式を揃えてリリースしなければ、ソリューションとして成立しない、ストーリーとして完結しないというものです。これは本当にそうなのでしょうか。ソリューションやストーリーとして成立する上でコアとなる機能や仕様と、それ以外とを区別して認識できていないだけかもしれません。整理を進めてみれば、必須ではなかったり、よく見れば1つのソリューションやストーリーだと認識していたものに、複数のソリューションやストーリーが混在していることもあり得ます。
後者の意見は、プレスリリースによるインパクトを狙うマーケティング担当などから聞くことがある声です。しかし、何度かに分けてリリースしていたとしても、対象とする機能一式が揃ってからプレスリリースを出すことだってできます。プレスリリースを出す何週間も前に新機能がユーザーの目に触れることが駄目だと言うのであれば、クローズドリリースを行い、プレスリリースを出すまでは、関連する機能群の公開を一部のユーザーに限定しておくことだって可能なはずです。
このような反対意見が出る背景には、これまでの慣習による思考が影響しています。これについては、過去の記事『「いかに作らないか」が考え抜かれた機能開発を。』で次のように書きました。
かくして、「優れたユーザー体験」を導き出そうと、徹底的な分析が進められます。時間をかけて綿密に分析するほどに、あれもこれもと機能要件が洗い出され、継ぎ足されていく。こうして、網羅的な機能要件ができあがります。
さて、この機能網羅型アプローチは、「優れたユーザー体験をカタチにしなければならない」という信念を行動原理としています。機能要件を網羅することで、作り上げようとする機能のユーザー価値を、リリースに先だって「保証」しようとしているのです。
リリースに先だって価値を保証できないことは、残念ながら先述のとおりです。思考を反転させなければなりませんが、それは容易ではありません。小さくすることに不安を感じるし、そもそもどこを切り出すべきなのか、その見極めが難しい。こればかりは、何度も試行錯誤を繰り返しすことで慣れ、経験を積み上げ、スキルを高めていくしかないでしょう。
どれぐらい小さくするのか
バッチサイズを小さくすると言っても、具体的にどの程度が適切なのでしょうか。
バッチサイズの縮小には、1度のリリースに含まれるプロダクトバックログアイテム（以降は「PBI」と呼ぶ）の数を減らすとともに、個々のPBIのサイズも小さくすることが求められます。そして、PBIの単位を決定する上で参考にできる原則が、アジャイルソフトウェア開発の「INVEST」です。
INVESTとは、良質なPBIが持つ6つの特性のことです。その特性とは、「Independent（独立している）」「Negotiable（交渉可能である）」「Valuable（価値がある）」「Estimable（見積り可能である）」「Small（小さい）」「Testable（テスト可能である）」であり、これらの頭文字を取ってINVESTと名付けられました。ここで言う「独立している」とは、PBIが、他のPBIになるべく依存することなくその優先順位を自由に決定できることを言います。また、「交渉可能である」とは、実現すべき内容やその方法が具体的すぎず、それらについてチームやプロジェクト内で話し合える自由があることを指します。
これらの原則に従うことで、それぞれが独立していて短期間で完了できる単位でPBIを管理できるようになります。
INVESTでは、Smallが示すサイズについて具体的に示されていませんが、DORA（DevOps Research and Assessment）に関連する文献などによれば、1週間未満で開発を完了させリリースできることが望ましいとされています。このケイパビリティは、次のように記述されています。
1週間未満で製品と機能を完成して頻繁にリリースできるよう、関連作業を細分化して進める能力
ここに書かれているように、PBIはさらに、いくつかの開発単位に細分化することになります。記事『エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく』に書いたカンバンボード上のチケットの単位がこれにあたります。スクラム開発なら、スプリントバックログ内のひとつひとつのアイテムを、この開発単位か、あるいはそこで発生する「設計・実装」「コードレビュー」といったタスク単位で管理していることが多いのではないでしょうか。
DevOpsや継続的デリバリーでは、開発単位（タスク単位ではなく）のフローの中で、「設計や実装の開始から、その変更内容を、全ての変更の統合先となるコードセット（統合ブランチ）にマージするまで」の期間を1日以内とすることが多いようです。私は過去の記事で、開発単位の個々のフローにおけるこの期間を「開発フェーズ」と呼び、それ以降の「製造フェーズ（デリバリフェーズ）」と分けてリードタイムを計測することを推奨しました。ここで言っているのはつまり、開発フェーズのリードタイムを1日以内にするということです。
チームやイテレーションも小さくする
ここまでで、PBIや開発単位のサイズについては具体的にイメージできるようになったので、次は、リリースに含めるPBIの個数について検討することになります。
これはシンプルな話で、スクラム開発をはじめとするアジャイル開発であれば、チームのベロシティによって決まります。
少人数の固定メンバーで構成されるチームと、短い固定期間に設定されたイテレーション（スプリント）での反復開発。アジャイル開発の体制やプロセスには、そもそもバッチサイズを小さくする仕掛けが組み込まれています。人数が少ないほど、また、イテレーションが短いほど、ベロシティは小さくなり、一度のイテレーションで実現できるスコープが小さくなるからです。
2020年版のスクラムガイドでは、スクラムマスターやプロダクトオーナーむ含め、チームの人数は10名以下が通常であるとされています。人数が多すぎるとコミュニケーションコストが高くなるからでしょう。フルリモートワークでコラボレーションするチームであれば、さらに人数を減らした方が良いようにも感じます。リモートで高いコミュニケーション効率を実現することは難易度が高いので、人数を減らすことでコミュニケーションコストを下げるというねらいです。
ただし、チームあたりの人数を減らせばチーム数が増え、チームとチームの間でのコミュニケーションコストが上がってしまいかねません。この罠に陥った組織は、チーム間でのミーティングが多くなるという形で症状があらわれます。
それを抑制するためには、チームの凝集度を上げ、チーム間の結合度を下げる必要があります。つまり、他のチームの力を借りたり調整したりすることなく、チームがなるべく単独で開発・リリースできるよう、組織設計することです。これについては長くなるため本記事では割愛しますが、参考までに、はてなブログに書いた関連記事へのリンクを記載します。
同スクラムガイドでは、イテレーション（スプリント）の期間は1か月未満とされています。私の観測範囲では、1週間から2週間程度が主流でしょうか。あまりに短くし過ぎると、イテレーションをまわす上で必要なミーティングなどのオーバーヘッドが大きくなり、非効率になってしまうようです。また、製造フェーズの自動化が不十分だと、手作業による非効率性に時間を食われ、イテレーションを短くできないという制約を受けてしまいます。
必ずしもイテレーションごとにリリースする必要はありませんが、アジャイル開発ではこのイテレーション期間が最短のリリースサイクルになります。
ただしこれは、バッチ単位でのリリースを想定した場合です。製造フェーズの自動化が十分であれば、個々のPBI単位、あるいはさらに細かい開発単位でも本番環境にデプロイできるため、より高い頻度でのリリースが実現可能となります。
開発単位でのデプロイをはじめると、PBIが提供しようとするフィーチャーに必要な要素がすべて揃う前にその一部がユーザーに露出してしまいかねません。
このような事態を避けるなら、フィーチャートグル（フィーチャーフラグ）を組み込んでおき、未完成のフィーチャーの露出をオフにしておきます。そして、全ての要素が揃った時に、トグルをオンに切り替えます。
また、ユーザインタフェースレイヤーの開発をなるべく後にまわすことでも、未完成のフィーチャーの露出をふせぐことができます。新しいバージョンのAPIを先にローンチしておけば、現行のバージョンのAPIを稼働させつつ、その本番トラフィックのコピーを使って新バージョンの動作検証を行うこと（ダークローンチ）だってできます。
フィードバックを得る
リリースした機能がユーザーに使われているか、ソリューション足り得ているか。それを調査せずに、放置したままになっている組織も多いのではないでしょうか。もちろん、ソフトウェアプロダクトをビジネスで展開しているのなら、ビジネス指標は少なくとも月次レベルで計測しているでしょう。しかし、それらの指標に対し、どのリリースが役立ち、どのリリースがそうでなかったのか関連付けしておらず、実態を把握していないのです。
このようなプロダクトマネジメントのもとでは、大量の使われない機能にプロダクトが埋め尽くされかねません。ユーザーに受け入れられなかった機能がいつまでも改善されることなく残り続けるからです。下手をすれば、改善の名のもとに、さらに使われない変更がおこなわれてしまうかもしれません。
前述のStandish Groupのレポートでは、リリースした機能のうち80%はほとんど使われないという調査結果が出ています。マイクロソフトの「2/3のアイデアには、価値がなかったか、あるいは逆に価値を損なわせる」という調査結果を思い出せば、納得できる数字です。
このようなプロダクトが優れたユーザー体験を提供できているとは思えません。ソフトウェア開発の観点からも、無駄な機能で肥大化し、複雑化したコードの保守は、不必要なコストを発生させるだけです。
大量の使われない機能にプロダクトが埋め尽くされないようにするためには、追加した機能の利用実態を把握する、つまり、リリースした機能に対するユーザーフィードバックを収集する必要があります。そうすれば、リリースした機能を価値ある形に改善したり、不要な機能ならば削除するという判断もできます。もちろん、そのような改善や削除に対してもさらに、ユーザーフィードバックで評価することができます。
機能を追加したらフィードバックを得て課題を把握し、改善する。場合によっては機能を削除する。そして、その改善結果や削除結果もフィードバックを得て評価する。改善や削除もまた、そのアイデアの2/3は期待する結果とならないかもしれないですからね。この延々と続くフィードバックサイクルが、プロダクトから無駄をなくし、価値を高め続けてくれます。
もちろん、ユーザー調査などを経ることで、アイデアにユーザーの意見を十分に反映させることは可能です。そのようなアイデアならば、リリース後にフィードバックを得ることは、二重コストのようにも思えます。しかし、ユーザーや顧客が、自分たちの必要とするものを正確に把握しているわけではありません。
したがって、リリースしようとするアイデアは、あくまでも仮説にすぎないということになります。アイデアが仮説であるなら、検証が必要です。それが、リリース後のユーザーフィードバック収集の必要性です。
書籍『リーン・スタートアップ』でエリック・リースは、このような開発プロセスを「プル」方式と呼び、従来の「プッシュ」方式と区別して呼びました。
リーン・スタートアップにおける製品開発プロセスでは「行わなければならない実験をプル信号としてそれに反応する」と考えるべきだ。
プル方式のプロダクト開発における計画づくりでは、ユーザーの需要を仮説とみなします。その上で、何を検証すればその仮説の真偽を確かめられるかを考え、それに基づいて機能を設計します。機能を先に設計するのではなく、先に検証方法を設計するのです。これが、結果としてバッチサイズを小さくし、PBIをINVESTに近づけます。
検証方法としてよく利用されるのは、ウェブコンテンツの検証でおなじみのA/Bテストをはじめとする対照実験です。「わざわざA/Bテストを行わなくても、リリース前後の指標の変化を見れば結果を把握できるじゃないか」と思うかもしれません。しかし、A/Bテストでは、変更前のバージョンと変更後のバージョンの違いが、変更した箇所だけとなり、その他の条件が全てそろう点が優れています。実験結果として得られた両者の測定値に違いが出たなら、それは、変更した箇所が影響したと言えます。単なるリリース前後の比較では、そう言い切れません。季節トレンドによる影響を受けたかもしれませんし、トラフィックの突発的なスパイクが影響したかもしれません。
フィードバックを計画づくりに接続してループを形成する
プル方式への移行は、プロダクトマネジメにおける計画づくりをユーザーフィードバックと接続するという変化をもたらします。
次の図のように、計画づくり（プランニング）は入れ子構造を持ちます。
プロジェクトにはプロジェクト計画があり、リリースにはリリース計画があります。また、スクラムにスプリント計画が存在することから分かるように、イテレーションにも計画があります。これらは互いに独立して完結しているわけではなく、プロジェクトからリリース、リリースからイテレーションという方向で詳細化されたものです。このような図を「プランニングオニオン」と呼びます。その計画構造としては、さらに外側にはポートフォリオや戦略があるだろうし、逆に内側には今日計画するもの、継続的（continuous）なものもあるでしょう。
そしてここにフィードバックが接続されることで、それぞれの円環がフィードバックサイクルに変わるのです。
バッチサイズを小さくして、フィードバックサイクルを高速化する。これこそが、アジャイルソフトウェア開発やDevOpsの本質ではないかと思います。デプロイ頻度を高める理由は、ここにあったのだと私は考えています。2/3のアイデアは期待する結果を得られないことを前提とし、80%の使われない機能に埋もれるプロダクトを作り上げることを避ける。これが結果として、開発生産性を高めるということなのでしょう。