第3部 出す · 第8回 / 全12回 · 10分くらい
出したあとに壊さない。データ・更新・声の受け取り口
出したあとがむしろ本番です。使う人の手元には、自分の手元とは違うデータと環境があります。この回では、出したあとに起きやすい事故を3つに分け、出す前に用意しておく仕組みを決めます。
履修 0 / 12 回
この回を読み終えると、できるようになること
- 出したあとに起きやすい事故を3つ挙げ、それぞれの備えを説明できる
- 保存の形式を変えるとき、データを失わずに移す手順を書ける
- 使う人の声を受け取る場所を、追跡の仕組みに頼らずに用意できる
専門用語は、初めて出たところで括弧に短い説明を付けています。説明が長くなるものには ※番号を付け、ページの終わりの用語メモにまとめました。
1事故1：更新したらデータが読めなくなる
いちばん避けたいのが、更新したら前のデータが読めなくなる事故です。保存の形式を変えたとき、移す処理（マイグレーション※1）に不具合があると、使う人のデータが壊れます。
備えは3つです。
- 保存するデータに、形式の版を書いておく：読み込むときに、どの形式かがわかる
- 移す前に、元のデータの控えを取る：移す処理が失敗しても、元に戻せる
- 前の版のデータで試してから出す：自分の手元の古いデータを、試験の材料として取っておく
2つ目は特に大事です。控えさえあれば、移す処理の不具合は直して入れ直せば済みます。控えが無ければ、取り返しがつきません。
2事故2：更新が届かない
不具合を直した版を出しても、使う人が入れ直してくれなければ、不具合は残ったままです。App Store なら Apple が更新を届けてくれますが、直接配布では、アプリが自分で新しい版を確かめる仕組み（第6回の Sparkle など）を、最初の版から入れておく必要があります。
あとから更新の仕組みを足そうとしても、それを足した版を入れてもらうまでは届きません。更新の仕組みは、最初に出す版に入れておくのが鉄則です。段3で GitHub に置くだけの段階なら、「新しい版はここで確かめてください」と README に書いておくだけでも違います。
3事故3：困っているのに、声が届かない
使っている人が困っていても、その声が届く場所がなければ、気づけません。気づかないまま、その人は静かに使うのをやめます。
声の受け取り口は、出す前に決めておきます。メールのアドレス、GitHub の Issues※2、フォームなど、何でも構いません。大事なのは、アプリの中から1回の操作でたどり着けることです。メニューに「問題を報告する」を置き、押すとメールの下書きが開いて、版の番号と環境が最初から書き込まれている、くらいだと理想的です。
4追跡の仕組みに頼らずに、困りごとを知る
使い方を細かく記録して送る仕組み（アナリティクス※3）を入れると、多くのことがわかります。一方で、使う人のプライバシーに関わり、プライバシーポリシーにも書く必要が出てきます。自分のサイトでは、外部の追跡の仕組みを入れない方針にしています。
追跡に頼らなくても、困りごとを知る方法はあります。
- エラーが起きたら、アプリの中に記録を残し、報告するときに本人の操作で添付できるようにする
- 最初の1人に、使っているところを見せてもらう（第2回）
- 出して1週間後に、「何をしようとして、どこで止まりましたか」と1つだけ聞く
5出したものを支え続ける量を、先に決めておく
出したものが増えるほど、支える仕事（問い合わせへの返事、OS の更新への対応、不具合の修正）も増えます。第1回のリトルの法則は、ここでも効きます。支えるものが多いほど、1つあたりにかけられる時間が減ります。
だから、出すときに「どこまで支えるか」を決めて、README などに書いておきます。たとえば「最新の macOS とその1つ前まで対応」「問い合わせへの返事は週に1回まとめて」。決めて書いておけば、使う人の期待と自分の負担がずれずにすみます。
誤解よくある思い違い
出したあとで問題が見つかったら、そのとき更新の仕組みを足せばいい
更新の仕組みを足した版を入れてもらうまでは、更新が届きません。最初に出す版に入れておきます。
困っている人がいれば、向こうから連絡が来る
連絡する場所が見つからなければ、多くの人は黙って使うのをやめます。アプリの中から1回でたどり着ける受け取り口を置きます。
演習手を動かして確かめる
演習1
メモのアプリで、保存の形式を「1つの大きなファイル」から「メモごとのファイル」に変える版を出します。データを失わないために、移す処理の前後でやることを順に書いてください。
答えを見る
- 起動時に、保存されているデータの形式の版を読む（古い形式なら移す処理へ）
- 移す前に、元の大きなファイルを日付つきの名前で控えとして残す
- メモごとのファイルに書き出す
- 書き出したメモの数と、元のメモの数が一致するかを確かめる
- 一致したら、形式の版を新しいものに書き換える。一致しなければ、移す処理を取り消して元のファイルで起動し、報告を促す
出す前に、自分の手元の古いデータ（できれば大きいもの）で試しておきます。控えは、少なくとも次の版まで消しません。
頼み方そのまま使える頼み方の例
次のアプリを出す前に、出したあとの事故に備えたいです。次の3つについて、今の状態と、足りないものを表にしてください。
1. データ：保存の形式の版を書いているか、移す前に控えを取るか、前の版のデータで試したか
2. 更新：使う人に新しい版を届ける仕組みがあるか
3. 声：アプリの中から1回で報告にたどり着けるか、そのとき何が添付されるか
追跡の仕組み（アナリティクス）は使わない前提で考えてください。
アプリ：（何をするものか、配り方）