自社ソフトウェアプロダクトの内製開発チームの振る舞いが、外部ベンダー的だと感じたことはないだろうか。開発チームと企画担当の関係が、請負契約的な受発注構造になっているということだ。
ソフトウェア開発の従来的な請負契約では、何を作るかは発注側の責任で、それを形にして納品するのが受注側となるベンダーの責任となる。これを先程の企画担当と開発チームの関係に置き換えて言えば、「何を作るか」が企画担当の責任で、それを「形にしてリリースする」のが開発チームの責任となる。
このような開発チームのことを私は、「仕様にコミットするチーム」と呼んでいる。「何を作るか」を言語化した存在である「仕様」の通りにソフトウェアを開発してリリースすることが、彼らのゴールだからだ。
しかし、内製でのプロダクト開発の良いところは、開発チームが「何を作るか」にまで踏み込みやすい環境があることだろう。もしそこに挑もうとすれば、チームは必ず顧客体験について考えることになる。だから、それを実践するチームを私は、「体験にコミットするチーム」と呼んでいる。
- 仕様へのコミット
- 体験へのコミット
- 体験にコミットすると顧客視点で仕様を見るようになる
- 体験にコミットすると顧客の反応を計測するようになる
- 体験にコミットするとデプロイ頻度が上がる
- 体験にコミットする開発チームと企画担当の責任分界点
- 最後に
仕様へのコミット
ソフトウェアを開発する過程では、様々な成果物が作られる。中でも最も重要なものが、最終成果物であるソフトウェア自体であることは間違いないだろう。ここでは「プロダクト」と呼ぶことにする。「フィーチャー」や「インクリメント」と読み替えてもらっても構わない。
それに対し、最初の成果物と言うべき「仕様」も、プロダクトそのものと同じぐらい重要な位置付けと言えるだろう。仕様とは言わば、「何を作るか」について定めた、企画担当と開発チームの合意事項と呼べるものだからだ。
完成したプロダクトにはたいてい、仕様とのギャップが存在する。その正体は、仕様に対する実装漏れや不適合といった欠陥だ。
仕様に対する網羅性や適合性が低いプロダクトは、企画担当と開発チームとの合意に反する。だから開発チームは仕様とプロダクトのギャップを最小限に抑えることがミッションとなる。これが、「仕様にコミットする」ということだ。
仕様にコミットすることは必要なことだ。しかし、内製開発チームのミッションとしては、十分と言えないのではないか。
体験へのコミット
プロダクトは、顧客が抱える何らかの課題を解決するソリューションとして生み出される。では、仕様を完全に満たしたプロダクトであればソリューションたり得るかというと、そうとは限らない。いちユーザーとして思い返して見ると、残念ながらそれを肯定する経験がいくつも思い浮かぶ。利用シーンにおいて重要な機能が不足していたり、機能としては事足りていても、非常に使いづらいアプリケーションなんて、珍しくもない。
このように、顧客のソリューションとして完全な仕様を定義することは、おそらく誰にもできない。だから、仕様を「真」として考えることは危険だ。
仕様や、それに基づいて作られたプロダクトは、あくまで仮説に過ぎない。顧客に体験してもらい、その仮説を検証してこそ、プロダクトに対して本当に求められている姿が見えてくる。仕様に対するプロダクトの品質より、体験に対するプロダクトの品質を真としてそこに近づけようとする。それが、「体験にコミットする」ということだ。
自社ソフトウェアプロダクト開発の内製開発チームには、体験にコミットして欲しいと考えている。
体験にコミットすると顧客視点で仕様を見るようになる
体験にコミットするようになると、チームは、「顧客視点」という新たな能力を獲得する。顧客視点を持つと、仕様に対するとらえかたも変わってくる。
開発中に、仕様に関する問題点に気付くことはよくあることだ。顧客視点を得たことでさらに、今までは気付かなかったような問題点について気付くようになる。それを「仕様だから」といって、やみくもに仕様通りに作るようなことはない。そんなことをしたら、顧客体験を損ねてしまいかねない。だから、見つけた問題は、すぐに企画担当と話し合い、より良い形に見直す。この活動が仕様自体の品質を高め、プロダクトがより優れた体験を生み出す可能性を高める。
体験にコミットすると顧客の反応を計測するようになる
仕様にコミットするチームの開発スケジュールは、「リリース」が最終タスクとして配置されている。
一方で、体験にコミットするチームの開発スケジュールでは、リリースが単なる通過点でしかない。リリース日の後に、学びのための期間が組み込まれている。
彼らは、プロダクトが顧客体験に優れたものになるよう、リリース前に可能な限り努力する。しかし、それが必ずしも想定通りの結果になるとは考えていない。仕様やプロダクトを、仮説だと考えているからだ。
だから、リリースしたプロダクトが顧客体験に良い影響を与えられたのかどうかを検証する。そうしなければ、自分たちのやったことが正しかったのか間違っていたのかがわからない。間違いから学ぶこともできない。体験にコミットするチームにとって、リリースとは完了ではなく、学びの開始点なのだ。
顧客体験の評価方法は、開発前にあらかじめ設計する。定量評価の場合もあれば、定性評価の場合もある。とにかく重要なことは、プロダクトを利用した顧客の実際の反応に基づいて評価することだろう。そのために、顧客の反応を収集・計測する仕組みをプロダクト自体に作り込むことさえある。
体験にコミットするとデプロイ頻度が上がる
動くプロダクトがあってこそ、顧客体験に基づいた検証が可能になる。だから、動くプロダクトをまず作り、リリースする。そして、顧客に体験してもらうことによって得たフィードバックを検証する。その評価に基づいて仕様に追加・変更を行い、プロダクトをアップデートする。
このようにプロダクト品質は、顧客も巻き込んだ改善サイクルによって高められていく。
しかし、下の図からも分かるように、「開発」の中でのみ行う「仕様に対するプロダクトの品質改善」に比べ、サイクル全体に及ぶ「体験に対するプロダクトの品質改善」は、時間的に長くなる。
「開発」に要する時間が長くなると、「検証」「適応」に要する時間も長くなることは想像がつく。バッチサイズが大きいほど、検証すべき対象や、その評価に基づいて手を加える対象が増えるからだ。そもそも検証対象が複数あると、何がどれだけ体験に影響を与えたのかを個別に把握することが困難なこともある。
このように考えてみると、体験にコミットする開発チームにとって、大きなバッチサイズでの開発・リリースというのは、非常に効率の悪いものだとわかる。新規で作り上げたプロダクトや、既存プロダクトに対する変更は、あくまでも仮説であり、その内容が 100% 正しいという保証はない。バッチサイズが大きいほど、間違いの数は増える。
だったらバッチサイズを小さくする方が良い。ちょっと出しては検証することを繰り返す。「単位期間あたりにリリースした機能・変更の数」という意味でのスループットは変わらない（あるいは下がる）かもしれないが、変わりにデプロイ頻度（deployment frequency）があがる。この回転数の高いフィードバックループが、ムダなものを作り込むコストを最小限に抑える。
体験にコミットする開発チームと企画担当の責任分界点
ここまで読んで、ひとつ疑問が沸くかもしれない。開発チームが体験にコミットすると、企画担当の責任範囲はどこにあるのだろうか、と。
仕様とのギャップが小さいプロダクトをリリースする責任は開発チームにある。プロダクトの体験をより高める責任は、開発チームと企画担当の双方にある。そして、その体験を「ビジネス価値」に変えるのが企画チームの役割だ。
顧客体験の改善サイクルをまわし続けることで、プロダクトの「顧客価値」が高まっていく。顧客価値が高まることで、ビジネス価値が高まることも期待される。しかし、顧客価値がそのままビジネス価値に変換されるわけではない。この変換に対して責任を持つのが企画担当という構図になる。
最後に
顧客体験に優れたプロダクトを、たった一度のリリースで実現することは難しい。だからこそ、フィードバックループをまわす必要がある。
フォーカスすべき対象を顧客体験に定めたチームは、プロダクトを利用する顧客の実際の反応を測定し、その評価に基づいて改善を積み重ねていく。この繰り返しが、彼らの顧客視点をより研ぎ澄まし、改善の精度はより高まっていく。このようにして高められていった顧客体験が、プロダクトを顧客価値と呼ぶに相応しい存在に押し上げる。そしてその顧客価値があってこそ、ビジネス価値が生まれていくのだ。
