高速でサイクルをまわす開発(1)：試作品とリリースするものを分けよう

皆さんこんにちは。

一つのプロダクトの保守・運用・開発に4年程度従事していて、10か月ほどPOという立場も経験しました。
その中で、たくさんの失敗と少しの成功を通して、最良かどうかはわかりませんが、今のところ最も成功につながりそうなプロダクトにおける開発のやり方が見えました。それは、結局のところプロダクト開発においては、高速でサイクルをまわす開発というのがいいんじゃないかというものです。

なお、あくまで開発の方法のみに着目しているので、アジャイルといっていいかわからんため、あえてアジャイル開発とは呼んでません。

高速でサイクルをまわす開発

別に大したものではありません。短い期間でなされるサイクルをたくさん回そうというものです。サイクルは1～2週間くらいでいいかなって思います。1サイクルが長い場合、いろいろと問題が出ますので、なるべく短くするといいと思います。
スクラムやXPみたいなアジャイル開発でも、イテレーションやらスプリントっていう形でサイクル回しているわけですし、そういうすでにサイクルをまわす開発をしているのなら、そのままでもいいです。

サイクルでやること

プロダクト開発を前提とした時、各サイクルでは次のことをやるといいです。

• 必ず動かせるものを作る。いくつ作ってもいいし、複数の課題について取り組んでもいいが、とにかく動くものを作る
• 作ったものについて、サイクルの終わりに必ずデモをする。デモはPOやCS、営業などフィードバックをもらえる人を呼んで行う。複数作ったのなら全部見せる
• デモの際に、ただの試作品かリリースするものなのかは伝える
• フィードバックをもとに次のサイクルでやることを決める

まあ、異様なほど当たり前のことを言っていて、目新しさのかけらもありません。わざわざ言葉にする必要はあるのでしょうか？

たかがこの程度のことを理解するのに4年かかりました。

高速でサイクルをまわす開発で重要なこと

高速でサイクルをまわす開発において、自分が身に染みて思い知ったエッセンスをこれから述べていきます。

動かせるものを作る

我々はエンジニアです。あーだこーだ考える脳もありますが、最も得意なのは物を作ることでしょう。なので作っちゃえばいいじゃんという、単純な話です。
単純な話なのですが、驚くほど実践が難しいものでもあります。
動かせるものを作るという単純なことを妨げる要因としては以下のようなものがあります。

• そもそも何を作ったらいいかわからない
• 作っちゃっていいか、誰に許可をもらえばいいかわからない
• 作るにしても分量が多いので、1サイクル中に終わらない
• まず設計したいので、1サイクル中に動くものは作れない
• デザインがないので作れない

これらについて、どのように解決するのかについてはまたあとで述べます。

ところで、動かせるものであって、動くものではありません。これは次のデモにつながっていきます。

作ったものをデモする

スクラムではスプリントレビューというイベントがありますが、一つのサイクルで作った「動かせるもの」をデモして、顧客やステークホルダからフィードバックをもらいます。顧客というのは、プロダクトを使ってもらうユーザーの場合もあれば、ユーザーからの要望を吸い上げてまとめた後に、解決したい課題を提示したプロダクトマネージャーやPOの場合もあります。また、カスタマーサクセスチームでも営業チームが参加するともっと良いでしょう。
「動かせるもの」であるべき理由としては、このデモにおいて、より多くのフィードバックを得るためです。顧客から操作のリクエストがあったり、よりよいケースとしては、顧客やステークホルダに実際に操作してもらうと、生々しいフィードバックを得られるのではないでしょうか。

フィードバックを得られれば、次にやることを決めることができます。
不具合があれば直しましょうとなりますし、不足した機能があればその機能を実装するかどうか検討するでしょう。全然使い物にならないようであれば捨てるというのもまた、一つの選択肢でしょう。

しかし、デモをした後にもらえるフィードバックですが、次のような理由で不十分なものになってしまう可能性があります。

• 開発チームからリリースしたい感が強く感じられて、厳しいフィードバックを出しにくい
• 開発チームがどんなフィードバックを望んでいるのかわからないし、開発チームはどんなフィードバックを望めばいいのかもわからない
• せっかく作ったものなので、開発チームが厳しいフィードバックを受け入れられない

経験則ですが、フィードバックを得られるかどうかは、かなりの部分を開発チームの姿勢に依存していると考えています。

試作品とリリースするものを分ける

意図的に説明をすっ飛ばしましたが、高速でサイクルをまわす時に導入すべきだと考えているのが、「試作品」と「リリースするもの」を分けるということです。
試作品とリリースするものについてはおおよそ次のようなものです。

• 試作品
  • 見聞きした課題について、とりあえず解決策として作ったもの
  • 一つのサイクルで作り切れない場合は作れる分だけ作る
  • リリースしないもの
  • 主にUX（使い心地や有用かどうか、ユーザの動線にあっているかなど）についてフィードバックを得るためのもの
• リリースするもの
  • いくつかの試作品を経て、製品としての形が判明したもの
  • 顧客やステークホルダは事前に何をリリースしようとしているかを知っているべき
  • 主にセキュリティや性能など、UXにかかわらない非機能な部分についてフィードバックを得る
  • 一つのサイクルで終わらないケースが普通だが、進捗の報告のために動かせるものを共有する

これもまた、特に大して難しいところのない、いたって普通に見えるでしょう。
しかしながら自分が開発者であるとき、ほとんど試作品というのはなく、大体がリリースするものになりました。「試作品である」という意識を持つことはほとんどありませんでした。

なぜ試作品を作るのか

なぜ試作品を作るのかといえば、何を作ればいいかを探るためです。要望に上がった課題を解決するとき、それをどうやって解決すべきかについて、延々と話し合ったり、長々と設計すると、デモによりこちらが提示した解決策が、適切かどうかについてのジャッジをするまでに時間がかかります。
それだったら、短い時間で解決策の提案を出して、よさそうなものを適当に動く形で作って、さっさとデモしちゃったほうが、フィードバックにより課題が明確化したり、方向性が決まるかもしれません。

このように、試作品を作る目的は早く・多く・頻度高くフィードバックを得ることです。試作品はリリースするものではないので、簡単に撤回したり、何だったらなかったことにもできます。なので、フィードバックをいただくときには、
「これは試作品です。皆さんの忌憚のない意見をいただきたいです。厳しい否定的意見や懸念点なども遠慮なくいただきたいです」
と宣言しましょう。
試作品の作成と廃棄を繰り返し、多くのフィードバックから本当の課題の中心や我々が実装すべきものを掘り出していきましょう。

今回のまとめ

今回は自分が結局のところこれで行くしかないと思っている開発方法は、高速でサイクルをまわすことであり、そのサイクルの中に試作品とリリースするものという概念を導入したらいいのではという話でした。
実は試作品とリリースするものの間には大きな違いがあって、試作品は基本的に捨てるものです。プロトタイプってやつですが、なぜ捨てるのかというのと、サンクコストという、おそらく多くの開発者にとってかなり大きな障害となっている概念に絡めて、高速でサイクルをまわす開発について深堀していこうと思います。

今回はこんなところです。