きちんとしよう、実装確認
仕事が忙しくて更新が疎かになってしまってました。。
さて、実装確認されてますか？
運営している以上、機能開発をしてどんどんアプリを
アップデートしていると思うのですが、
・機能開発の仕様をオーダーする人
・機能開発の実装者
・その機能を使って運営する人
最低でもこの3つの役割の中で追加開発する機能の認識統一が出来ていないと、
折角作った機能が碌に使われないまま放置されたり、
かゆい所に手が届かなくて中途半端な運営になったりと
結果的に無駄が多いコンテンツになってしまいます。
そこで是非やっていただきたいのが「実装確認会」。
完璧に動く状態でなくとも良いので、前述の3者が
実際にデータ設定を行い、動かしてみる事で
頭の中に思い描いてた思惑を実際に形として目に見える状態にして
認識統一と実際の運営イメージを固める作業です。
大抵、「仕事が忙しい」「オーダーは出してるから」で
なぁなぁにされやすい部分ではあるのですが、
「自分の常識は他人の非常識」
本当にこれです。よく、私が仕事中に感じる言葉です。
「何故こうしないの？」と思う前に
「自分としてはこうして欲しいと思ってるんだけど」を
すり合わせる作業、それが実装確認会です。
思ってたものと出来上がったものが違う…といった事象に
悩まされている方は是非一度試してみて下さい。
ちなみに、折角やるなら調整込みでスケジュールに余裕をもって
実行してくださいね。
アップデート版のリリースってどうやるの？
前回のエントリーでは、アプリ申請のポイントについて纏めました。
今回はいよいよ申請に通ったアプリをリリースする際に
気を付けないといけない点について纏めます。
ユーザーがアプリを更新する手段は大体2種類あります。
1つ目はユーザーが自動更新をONにしている場合、
2つ目はユーザーが自動更新をOFFにしている場合です。
1つ目はプラットフォーム側の機能でやってくれるので
特に気にする必要はありません。
今回は2つ目の、ユーザーが自動更新をOFFにしている場合に焦点を当てます。
ユーザーが自動更新をOFFにしているならどうやって
更新されたアプリをインストールして貰えばいいのか。
恐らく皆さん経験があるのは、アプリを立ち上げた時に
「新しいアプリがあります」と言われて
プラットフォーム側に飛ばされる事（強制更新）だと思います。
方法としてはそれで何も問題はないのですが、ここで気を付けるべきは
強制更新を行わせるタイミングです。
アプリの更新版をリリースした時にユーザーは
すぐにインストールできるようになるわけではありません。
プラットフォーム側で更新作業を行った際にも表示されますが
更新が反映されるまでは若干のタイムラグがあります。
プラットフォーム側では24時間と書かれていたりもしますが
経験上、大体30分～2時間位で反映される印象です。
ただし、時には4～5時間かかる場合もありますので、
やはり時間には余裕をもって、
可能な限り午前中にリリースするのが望ましいです。
（※24時間体制などをしいていないのであれば）
重要なのは必ずこの浸透が終わってから、
強制更新を行うようにすることです。
でないとアプリ側で更新を促される
➡浸透が終わってないのでアプリがDLできない
という無限ループに入ってしまうからです。
また、浸透は端末によって差があるので、
1台アップデートできたからといって
全員が浸透できる訳ではないので注意してください。
参考までに、複数台アップデート可能なことが確認できてから
30分～1時間位置いたら今の所、
無限ループって怖くねにならずに済んでます。
後、必ず強制更新確認用と、アップデート版確認用の端末を
用意しておきましょう。
アップデート確認用の端末で、まずはアップデート確認を行い、
問題なければ強制更新、強制更新を端末で確認という流れにしましょう。
何故なら強制更新の時点で、
例えばストア遷移先のURLが間違っているとか
ボタンが反応しないといったトラブルが起きる可能性があるからです。
纏めるとこんな流れです。
1.アプリ更新版のリリースを行う
2.浸透を待つ（30分～数時間）
3.浸透した端末でアップデートを行う
4.アップデート版のアプリが問題ないことを確認する
5.浸透が完全に行われたことを確認する
6.強制更新を行う
以上、アップデートリリース時の流れについて纏めてみました。
アプリをアップデートする時に必要なチェック
さて、アプリのリリース方法などは、既に色々なサイトで取り上げられて
参考になる物も世の中に沢山公開されているので
ある程度はスムーズに進められるかと思います。
今回は、アプリリリース後からずっと付き合うことになる
アプリ更新について焦点を当てたいと思います。
アップデートを行う際に、まず考えないといけないのが
押さえなければならない内容が3軸あると言う事です。
既にリリース済みのアプリをVer1.0.0、今から焦点を当てる
アプリ更新をVer1.1.0と仮定すると
まず、1つ目がVer1.0.0を遊んでいる既存ユーザー
2つ目がVer1.1.0を開発、検証する開発者
そして3つ目がVer1.1.0を審査するAppleです。
1つ目と2つ目に関しては、通常時はさほど気にする必要はありません。
１つ目は言わずもがな本番環境でプレイしていますし、
2つ目は開発用の環境でまずは開発、検証をするので
さほどお互いが干渉するようなことはないでしょう。
問題は、Ver1.1.0の開発も目途がつき、
リリースに向けて動き出せるとなった時です。
アプリは「クライアント」と「サーバー（DB含む）」の
２つの要素から成り立ちます。
先ほど定義した1つ目のユーザーは勿論
クライアントVer1.0.0サーバーVer1.0.0でプレイすることを
想定して作られています。
しかしながらAppleに審査をしてもらう為には
クライアントVer1.1.0、サーバーVer1.1.0の本番環境で審査して貰う事が
必要になります。
と言う事はその間1つ目のユーザーは
クライアントVer1.0.0、サーバーVer1.1.0というイレギュラーな環境で
プレイする事になるのです。
サーバーに大きな変更がない場合は良いのですが、
メジャーアップデートとなると
サーバー変更を伴うことが多々あります。
その為、アプリ更新を行う場合は、2つ目の開発者の段階で
リリース対象のVer1.1.0のクライアントのチェックだけではなく、
新サーバーVer1.1.0、旧クライアントVer1.0.0が正常に
プレイできるかどうかの確認を行う必要があります。
意外とこの件は見落としがちなのですが、特に既存機能の仕様変更が
アップデート内容に含まれている場合等は、新クライアントにあわせて
サーバーの変更が入ってる場合がありますので、アプリの審査に出す前に
必ず確認を行っていた方が良いでしょう。
ちなみに、この検証は新サーバーの設定が完成している状態でないと
意味がありませんので、どうしてもこの検証はスケジュールの最後の方になります。
それを見越してバッファを用意しておきましょう。
尚、どうしても新サーバーと旧クライアントが同居できない場合は
メンテナンスを行うという手もありはしますが、アプリをリリースして
浸透（すべてのユーザーが新しいクライアントを落とせるようになる）まで
タイムラグがある事が多々あり、確実な手とは言い難いので
その場合は状況に応じて取捨選択しましょう。
以上、アプリ更新の時に見落としがちなチェックについて纏めました。
次回、アプリ審査が通っていよいよアップデート版リリースという時に
必要な事について纏めたいと思います。
フリーランス初心者が焦って見積書作った時の話+その前に確認しといたが良い事
こんにちは。
今日はちょっと毛色を変えてフリーランス初心者として
体験した事を備忘録がてら纏めていきたいと思います。
某日。打ち合わせ。
「～～ではお見積書を頂けますでしょうか～」
「（えっ！見積書？何それ！え！）畏まりました～（ニッコリ」
から、家に帰って大慌てで
「フリーランス 見積書 作成」
「フリーランス 見積書 テンプレート」
でぐぐって色々調べて作ってみました。
ちなみに我が家の装備ですがプリンターもスキャナーもありません。
幸いOffice付きのPCを買ってたのでExcelとWordは使えます。
Officeないよ！って方はKink〇'sいきましょ。安いし。
やる事事前に把握しておけば、最短時間で終われると思います。
参考にしたサイトはこちら
フリーランス必見！見積書作成のポイントとノウハウ | はじめようフリーランス！【クラウドワークス】
ここの、ページ中段①～⑨のポイントが参考になりました。
ふむ、印鑑は必須じゃないのね、ありがたい。
Kink〇'sまで出向かなくて済みそう。（いつもお世話になってます）
でも私の場合は品名を細かく書くのが難しかったので
全部まとめて一行にしました。。工程分けれなかったので…。
そして今回使ったテンプレートがこちら。シンプルさ重視
振込先を記入する欄が無かったので、下の備考欄に入力しました。
また、「お手数ですが振込手数料はご負担願います。」の一言も添えました。
見積書はPDF形式で出したのですが、
このテンプレートそのままPDF化すると
ページが変にずれるので、Excelの改ページプレビュー機能で
ページ調整してからPDF化しましょう。
そして、ここからが私が見積書作成段階でつまずいた事なのですが、
恥ずかしながら消費税の事を把握してなくて見積書を作る段階になって
初めて気付きました。
なので、事前に先方に
報酬が税抜きなのか、税込みなのかをはっきり確認しておきましょう。
その他には、見積書の宛名も必要になりますので、
こちらも確認しておきましょう。参考サイトにもあったように
会社、部署宛なら「御中」、担当者宛なら「様」ですよ！
休日の条件や出勤日数の交渉などをしているのであれば、
それも備考としてお見積書に記載しておいた方が良いのかな、と思います。
後は、私が最終的に参考にしたサイトは上のリンクなのですが、
色んなサイトを見て、「こう書いている場合もあるんだ」ってのを知るのが
大事かなと思います。
サンプルは多ければ多いほど自分にあったものが選べますからね。
１回やってしまえば後は自分のテンプレートが出来上がると思いますので
必要に応じて運用していきましょう！
クローズ時に返金で焦らない為に
運営していたアプリをクローズするというのは
運営者にとっても心苦しい時ですが、いざクローズするという時に
あれに対応していない、これに対応していない、
でもプロジェクトは縮小しているから工数がかけられないなど
困ったことにならない為に、事前にこういう風に組んでおくと良いですよ。
といった内容を今回はまとめてみました。
◆前提：一般的なクローズ時のフローについて
・アプリクローズの60日前まで：ユーザーに対して終了告知
・アプリクローズの30日前まで：課金終了
・アプリクローズ当日：クローズ処理
・アプリクローズ後2カ月以上：返金対応
※会社によって、多少のずれはありますが、
大体こういったスケジュール感が多いです。
気になる方は、以下リンクから他社事例が確認できます。
一般社団法人日本資金決済業協会｜前払式支払手段払戻しのお知らせ
≪クローズの時に焦らない事前準備≫
1.有償課金アイテムの価値を等価にしておく
2.有償アイテムと無償アイテムの個数をユーザーが確認できるようにしておく
3.ショップ等の課金箇所だけのメンテナンス機能を用意しておく
4.タイトル画面でユーザーに告知する機能を用意しておく（メーラーもあると良）
1.有償課金アイテムの価値を等価にしておく
アプリクローズの際に資金決済法に基づき
有償アイテムの払い戻し義務が発生します。
※利用規約などで返金には応じないって書いてても発生します。
※ちなみに、資金決済法の対象でない場合は、この払い戻し義務は発生しません。
その場合、残っている有償アイテムの数に応じて
払い戻し請求が行われるのですが、
有償アイテムが高額になればお得になる（個数が多くなる）
売り方をしていた場合、
ちょっとしたトラブルになる可能性があります。
例えば、1個120円のアイテムが、2400円出すと30個手に入れられると
1個当たり80円になった様に見えますよね？
しかし、クローズ時に25個アイテムが残っていた場合、
25個*120円=3,000円の払い戻しになるのか、
25個*80円=2,000円の払い戻しになるのか
揉めてしまいそうですね。そうならない様に以前のエントリでも書いた、
「有償+無償のおまけ」という形式に見せておくと、有償アイテムの価値が
どの課金額でも変わらなくなり、単純に個数で払い戻し額を算出する事が可能です。
2.有償アイテムと無償アイテムの個数をユーザーが確認できるようにしておく
払い戻し義務があるのは有償アイテムのみになります。
ただ、ユーザーからとってみれば、
例えば自分が課金アイテムを100個（内、有償50、無償50）もっていたら
100個全て払い戻し対象になる様に感じてもしょうがないかと思います。
なので、ユーザーに誤解を与えないように、有償アイテムと無償アイテムの内訳を
きちんと確認できる場所を用意しておき、クローズ後もそれを確認できるように
しておいた方が良いでしょう。
※クローズ後の確認場所はタイトル画面でダイアログを出して
その中に情報を表示させる等で良いかと思います。
3.ショップ等の課金箇所だけのメンテナンス機能を用意しておく
クローズの際に、まず最初に課金機能をストップしますが、
課金機能を止めるための方法としてスマートなのがメンテナンス機能です。
不測の事態発生時に役立つのに加え、
課金終了に伴いメンテナンス状態にしておけば
ユーザーが遷移しようとした際にストップでき、
綺麗な見せ方をする事ができます。
その為にも、メンテナンスダイアログに表示させる文言は
自由に設定出来る様にしておきましょう。
4.タイトル画面でユーザーに告知する機能を用意しておく（メーラーもあると良）
これはアプリがクローズした後の、返金対応の時のための対応です。
アプリを起動した際にきちんとユーザーに終了告知をする事と、
返金時にスムーズに本人確認が出来るようにするのが目的です。
と言うのも、終了後、アプリ内からの動線を全て塞いでしまうと
いざ、返金請求があった際に、本人確認に非常にコストを要してしまうからです。
それだったら、クローズ後もアプリ内からのメーラー起動で、
ユーザー情報をセットでメールを送らせれば、余計な手間もかかりません。
専用テンプレート（口座情報の質問など）を用いる事が出来れば完璧です。
また、これはちょっと出来るのか不明ですが、
タイトル画面で何らかのデータ破損でアプリ内に入れないって時に
これと同じ機能を使ってお問合せ出来たら便利そうですね。
如何でしたでしょうか。もちろん、これ以外にも気を付けるべき内容は
あるとは思いますが、最初にここに書いたように作っておくと
後の大変さが段違いになりますので、良かったら参考にしてみて下さい。
アプリ運営で気を付ける資金決済法入門その2
さて、前のエントリーでは資金決済法について色々と書き連ねましたが、
利益が潤沢に出てるなら素直に供託金or保証会社と提携するで良いと思いますが
まだそこまでって場合は可能な限り出てくお金を抑えたい所だと思います。
なので、今日はそうする為の具体的な打ち手とその理由について纏めます。
なお、今回のエントリーは駆け出しのアプリ運営者向けに纏めましたが、
ユーザーあってのアプリ運営ですので、
1日でも長くユーザーに面白いアプリが届けられる様に
会社が存続するための方法の一つとして受け取ってもらえたらと思います。
＜打ち手＞
1.課金原資を使用する際に、有償の物から消費させる
2.課金原資を購入させる際に、高額になるほどお得にする場合は、
お得分を「無償のおまけ」扱いにする
（解説）
資金決済法の対象になるのは有償アイテムだけです。
つまり、身も蓋もない言い方になりますが、
有償アイテムとしての取得は最小限に、そして
入手させたものは早く消費してもらう作りにする、という打ち手になります。
※勿論、ユーザーが支払った対価以下の有償アイテム数にするのはNGです。
1.は分かり易いかと思います。例え手に入れた時期が最近だったとしても
有償アイテムがあるのであれば、有償個数が極力滞留しないよう、
そちらから消費する作りにするという事です。
実際に有償アイテムから消費する様にしているアプリも幾つかありますので、
気になった方は利用規約や、ガチャ画面の注意事項等を見てみると良いかと思います。
2.はよくゲームアプリとかで、1個120円の課金原資が、2400円出すと
30個（10個多く）入手できるといった仕組みを見たことがあるかと思います。
この時、30個全てを有償とするのではなく、20個（有償）+10個（無償）という
扱いにすると、対象となる有償アイテムの個数としては少なくなります。
これは資金決済法の打ち手として有効になる以外にも
アプリクローズ時にも役立ちますので、高額の物ほどお得になる
売り方をされたい方は、是非有償+無償という見せ方にすることをお勧めします。
アプリクローズの話はまた別エントリで記載したいと思います。
3.Androidの有償アイテムは有効期限を180日とする
これは前のエントリーでも触れましたので軽くいきたいと思いますが、
6カ月以内の有償アイテムは対象になりませんので、
180日制限を設けることで、資金決済法の対象外にすると言う事になります。
しかしながら、iOSユーザーにはその期限を設けることが規約的に出来ませんので、
これを行う場合、アプリ内で表示する資金決済法の記載をAndroidとiOSで出しわける
（orプラットフォーム毎に仕様が異なる事を明記する）事が必要になります。
※資金決済法の記載って何？という方に補足です。課金原資を購入する際の
ショップなどに、資金決済法についてと言ったリンクがある事を見たことがあると思います。
書かれている内容はそれぞれ何なのかというのは、下記リンクの
「表示義務」と「情報提供義務」をご覧ください。
http://www.s-kessai.jp/businesses/prepaid_means_overview.html
ただ、もしこの対応を入れる場合はユーザーに期限が近い課金原資がある事を
通知するようなシステムも一緒に組み込めると親切だなと個人的には思います。
4.3月や9月に課金原資を消費するような施策（イベントなど）を実施する
3月末と9月末時点の未使用残高を基に判断されるため、
そのタイミング以外で未使用残高が1000万を超えたとしても
資金決済法の対象にはなりません。
よって、該当タイミング前に課金原資を消費させる系の施策が有効になります。
逆を返すと、課金原資のおまけ増量など、
購入を促すような施策はこの時期は避けておいた方が良いかと思います。
以上、簡単にですが、資金決済法とその打ち手について纏めてみました。
ただ、別に資金決済法に該当するのが悪い事という訳ではありませんので
資金決済法ってものがあるんだ、こういうのが該当するんだ、と
知っていただけたらなぁと思います。
ユーザーが楽しんでくれるアプリが1日でも長く存続する様に、
少しでもご覧になった方の参考になればと思います。
アプリ運営で気を付ける資金決済法入門その1
アプリ運営をするに当たって無視する事が出来ない事項の中に
資金決済法というものがあります。
今回の記事では
1.資金決済法とは何なのか
2.具体的にアプリ運営の時に気を付けることはなんなのか
についてなるべく分かり易く纏めます。
1.資金決済法とは何なのか
ざっくりと資金決済法の概要だけ言うと、
・毎年3月末、9月末に有効期限が6カ月より長い有償アイテムの未使用残高が
「1,000万」を超えている場合は2ヶ月以内に
その2分の1以上の額を供託金として預けないといけない
という法律です。
つまり、1000万を超えていなければ何も気にすることはありません。
ただし、これは1アプリで、ではなく、会社が運営している全てのサービスの合算で
カウントされますので、注意して下さい。
http://www.s-kessai.jp/businesses/prepaid_means_overview.html
有償アイテム、有効期限、未使用残高の定義についても
簡単にご説明しておきます。
有償アイテムとは、消費者が購入した課金原資の事です。
例えば、モンストのオーブやパズドラの魔法石はアプリ内のショップで購入できますが
ショップで購入したものを有償アイテムとして扱います。
※ですが、例えば1個だと120円だけど2400円支払えば25個買えるなど、
購入額が高くなるほどおまけが付いてくる場合、
差分の5個はおまけなので無償アイテムと扱われる事もあります。
無償アイテムはユーザーが対価を支払わずに手に入れた課金原資です。
運営からのプレゼントだったり、いわゆる詫び石だったりが該当します。
次に、有効期限についてです。
有償アイテムの内、有効期限が6カ月以内のアイテムは
資金決済法の対象にならないとされています。
コンシューマですが、任天堂の大合奏バンドブラザーズPというゲームがあります。
このゲームは、お金を支払うことで課金原資（トマト）を購入できますが、
このトマトは最大5カ月で腐る仕様になっています。https://www.nintendo.co.jp/3ds/anej/tomato/index.html
こうすることで、資金決済法の対象にならないようにしているのです。
ではスマホアプリもそうすれば良いのではと思われるかもしれませんが、
Appleが規約で、購入したコンテンツに期限を設けることを禁止していますので、
残念ながらスマホアプリ側では少なくとも、iOSに対しては
期限をつける対応は出来ないのです。
※Apple Developer Guidelines3.1.1に該当（2016年10月現在）
GooglePlay側は、現状購入コンテンツに期限を設けることを禁止していません。
その為、AndroidとiOSで不公平感を無くすため、
どちらも有効期限なしとしている企業も多く存在します。
最後に未使用残高というのは
今まで発行した全ての有償アイテムの内、3月末or9月末までに
使われていない有償アイテムの価値の額
と認識いただければ大丈夫です。
分かり易く、ケースごとにまとめます。
1個120円の課金原資を今までにAndroidで5万個（600万）、iOSで5万個（600万）売りました。
≪ケース1≫
Androidで課金原資の有効期限を6カ月以内にしていました。
➡Android分は資金決済法の対象にならないので、600万の未使用分があったとしても
1000万未満のため、資金決済法の対象にはなりません。
≪ケース2≫
Androidで課金原資の有効期限を特に定めていませんでした。
3月末の時点でAndroidで4.5万個、iOSで4万個使われていない有償アイテムがありました。
➡（4.5万個+4万個）×120円=1020万円が未使用残高になるため
資金決済法の対象になります。
では、資金決済法の対象になってしまいました、
いざ支払わないといけないとなった時に、
未使用残高の2分の1以上はかなりの額になる可能性もあります。
そういった場合は既定の信託銀行や保証会社と契約を結ぶことで
OKとするケースもありますので、
自社の状況を踏まえたうえでどちらのケースが適しているのかを
判断されるとよいかと思います。
こうやって見てみるとあっさりと資金決済法に該当するので
サービス提供者側に対して優しくない法律に見えますが、
資金決済法とは、そもそもの背景として消費者を守るための法律として制定されました。
サービス提供者側は消費者に対して有事（サービスクローズ等）の際に
消費者からの要請があれば返金義務を負います。
その支払い能力を担保する為の決まりだとお考え下さい。
ちなみに、スマホアプリ等でよく見るアイテム課金を導入しているサービス提供者は
資金決済法における「自家型前払式支払手段発行者」に当たります。
ご自分でもっと詳しいことを調べたいと思われた際は
この語句でも検索してみるとよいかと思います。
長くなりましたので、2.具体的にアプリ運営の時に気を付けることはなんなのかは
次のエントリに纏めます。
