Appをリリースしてみて感じたこと(3) - リリースストラテジー

日本時間の10/5午前、自作Appの最新バージョンであるVersion 1.0.1がリリースされました。申請を出したのが9/26、承認が下りたのが10/4(アメリカ時間)ということで、通常であれば8-9日間程度かかるようです。

審査自体は数時間で終わるくせに待ち時間がやたら長い事を愚痴っても仕方がないので、これを前提としたリリースストラテジーみたいなものを考えないといけないのかな、というのが今日のお話です。

バグはないに越したことはない

人が作ったソフトウェアである以上、多かれ少なかれバグは出来てしまいます。もちろん、そのためにテストは慎重にやるに越したことはありませんが、テストで全てのパターンをカバーするというのは、実際にはかなり非現実的で、どこまで時間的、(人を使った場合に)金銭的コストをかけられるかという部分と相談になるはずです。

なので、開発者目線で言うと、自分であるいはユーザさんが見つけたバグを極力早く直すというのが、ある意味「誠意ある対応」だと考えていました。ただ、早すぎる対応も良くないと思えるようになってきました。

再修正は待ち行列の最後に回される

例を挙げて考えてみましょう。

すでに9/24にVersion1.0がリリースされているとします。リリースしたところ、軽微なバグが見つかったので、その翌日9/25にVersion1.0.1をUploadしました。ところが、また新たにバグが見つかり、熱心なあなたは9/28にVersion1.0.2を用意しました。

もし、この1.0.2をすぐUploadした場合、その時点で審査待ちであったVersion1.0.1は取り下げることになります。となると審査待ちの行列の最後尾に並び直すこととなり、ユーザさんは、10/4頃に手に入れられるはずだったバグ修正を10/8頃にならないと手に入れられなくなるわけです。さらに言えば、10/8より前に新たなバグを見つけて、Version1.0.3を作った場合は、延々とリリースできないなんて事になりかねません。

であれば、図の一番下にあるVersion1.0.2'のように、いったん上げた修正はリリースされるまで待ち、それまでの期間は、バグのCollection(収集)とCorrection(修正)に専念して、1.0.1がリリースされた後に1.0.2'としてUploadする方が、実は時間がかかるように見えて効率的なのです。というのも、ユーザさんにとっては、1.0.1に入っている修正が重要で、1.0.2に入っている修正はあまり大事ではないと考えている場合もあるからです。少なくとも10/4には最低限の修正が受け取れるわけですから。

もちろん、見つかったバグがあまりに致命的だった場合は、この限りではありません。現在上がっている修正を取り下げてでも新たな修正を上げるべきです。このあたりはCase by caseになると思いますが、ただ致命的なバグがあったまま審査が通るってことはあるんでしょうかね？

という事で、私の場合は、上の図よりも少しだけルーズにさせてもらうことにしました。新バージョンがリリースされてから約1週間はBugs collection & correctionに充てさせていただき、(バグが見つかる限りは)おおむね3週間に1回程度新リリースをUplaodすることにしたいと思います。