mineoマイページなどにおけるデータ通信使用量表示誤りの発生原因について
以前、mienoのオペレーション構築を担当していました。
おもいっきり“ビールかけ”がしてみたい!!!
ご無沙汰しております。2番バッターです。
今回は、『mineoマイページなどにおけるデータ通信使用量表示誤りの発生原因について』ということで、いわゆる“ゴースト”がどういう理由で発生してしまっているのか?を説明します。
難解な内容をいかに簡単にお伝えするかはもちろんのこと、
・お客さまにご迷惑をおかけしている事象の原因公開。(ネガティブ案件)
・容量管理の仕組み開示。(技術仕様の開示)
という点からも、約2カ月ぶりの打席にしては、なかなか手強いテーマですが、良い面だけでなく、抱えている問題点も包み隠さずお伝えしようというマイネ王らしい試みなので頑張ります!
ちなみに“ゴースト”という表現は、マイネ王メンバーのさとさんの掲示板(王国広場)への下記投稿から生まれたものと認識してます。
マイページの円グラフが見難い…|さとさんの掲示板
>さとさん
マイネ王内でずいぶん定着していることを受け、mineoスタッフも、「ゴースト」という呼び方を愛用?させていただいております。ご了承ください。
前置きが長くなりましたが、本題に入りましょう。
っといっても、なかなか文字だけでは伝えづらい内容ですので、、今回は、パワーポイントで説明資料を作成してみました。
ご覧ください。
mineoマイページなどにおけるデータ通信使用量表示誤りの発生原因について
ご理解いただけましたでしょうか?
ご覧いただいたとおり、残容量は確実に正しい値を提供できるのですが、使用量に関しては誤った値を示す可能性があるというのが今のmineoの状況です。
この状況を踏まえ、“ゴースト”を防ぐ手立てがないものか、私たちも検討しましたが、この容量管理の仕組みは、現在提供している通信サービスの根幹になるため、そう簡単には直すことが出来ません。100%正しい情報をということであれば、逃げになりますが、マイページから使用量表示を無くすくらいしか対策がありません。
そんな中でも、なんとか情報の見せ方を工夫することでこの問題を緩和できないか?ということで、現在、マイページ内のデータ通信量明細ページの改善を進めております。
これは、リアルな情報ではないものの、前日までの概算値を詳細かつ一元的に提供することで、≒ 使用量をご覧いただけるようにしようとするもので、具体的には、以下の4点を実現しようと動いています。
※アイデア ラボでご提案いただいた案件です。
当月の通信量を知りたい|さとさんのアイデア ラボ
日次のデータ消費量を確認したい|あかぎれさんのアイデア ラボ
・現在提供している『データ通信量』を高速/制限に分離する。
・ギフトの履歴(IN/OUT別)を追加する。
・フリータンクやチップといったマイネ王上のサービスの履歴(IN/OUT別)を追加する。
・直近4日分だけでなく、過去3カ月の情報を提供する。
上記の取り組み状況については、アイデア ラボ内で随時コメントしていきますので、お待ちくださいね。
※今は12月実現予定を目標に検討・開発を進めていますが、一部、次期開発(2017年2~3月頃リリース)にずれ込みそうですm(。。)m
では、また次の打席で!
残容量が正確なのはたしかにうれしいですが「バケツ」という単位で測ってる以上(わかりやすい説明ありがとうございます)この問題の根本的な解決は難しいのですね〜
使用量明確にがわかる仕組みはいいですね〜
12月楽しみにしてます
よくわからなかったのですが、ユーザーごとに
・基本データ(残)容量
・前月繰越(残)容量
の2つの項目を持っていて(高速データの)使用量というバケツがないことはわかりました。(これが残容量を正しく出せない原因ですね。)
説明資料で、ギフトバケツの説明がよくわかりません。
バケツ③の容量が最初10MBなのに、その後100MBになっているし、たとえば、500MBのギフトと、300MBのギフトを2つもらったら、合計の容量ではなくばらばらに管理しているのでしょうか?
P22の「以上をまとめるとこんな感じです。」のところで、バケツ③ギフト1、バケツ④ギフト2とあるのですが、3つ以上ギフトがあれば、バケツ④ギフト3...というようになるのでしょうか?
個々のスライドはわかりやすいと思うのですが、全体の説明の流れは、ちょっと冗長でわかりにくい感じがしました。
使用量はそのうち管理できるようになるといいですね。大変だと思いますが期待しています。
フリータンクのOUTやチップが翌日に反映されるとおもいますが、月末に「フリータンクやチップは発行した日の翌月まで」としてしまったほうが、ルールがシンプルで問題が少ないのではと思いました。月末に発行して期限を延ばそうということがおきますが、いまの仕組みでいえば、月末の処理で当月のギフト容量、ギフト残容量に足した後、繰越容量に移す方が処理もシンプルで間違いがありません。
システム改定大変だとは思いますが、わかりやすくシンプルな仕組みになることを期待しています。
月始めに家族に「めっちゃ使用量あるんやけど何で?」と聞かれて、「使ったんやろ?」と答えたことがあったのですが、間違いだったかもしれないですね…(´・ω・`)
使用量をバケツ容量から残量を引いて求めているということは、「使用量」という名称自体が実態と食い違ってるなぁと感じました。これからの改善に期待します!
ところで、、
家族でパケットシェアしてる場合はバケツはどのように繰り越されているのでしょう?
パケットシェア分の使用量の内訳(自分が使ったのは○MB)がわかるといいなぁと常々思っていたので、その辺りもまた改善していただけると嬉しいです(._.)
システムの根幹とのことで難しいとは思いますが、よろしくお願いします^_^
あれ、でもギフトバケツには消費期限をつけることができて当月とか繰越とかないということなのかな...
残容量が正しく計算できないことはなんとなくわかるんですが、バケツという概念が、頭が弱いのでわたしにはよくわかりませんでした。
だれかわかる人がいたら教えてください....
・バケツにはチャージバケツもあるんですよね?...(きっと)
・基本バケツと繰越バケツがあるのに、ギフトバケツやチャージバケツはギフト繰越バケツやチャージ繰越バケツとはならないんでしょうか?
・バケツに有効期間がつけられるのなら、どうして新しく付与する基本容量バケツは、有効期間を翌月末としないのでしょうか?
(わざわざ当月末にしてから繰越バケツに変える理由がわかりません。単にバケツの総容量を変えるため!?)
バケツに総容量と残容量があるというのはわかるのですが、パワポ資料をみればみるほどわざと複雑なことをしているようでよくわからなくなってきました。
分かる人、教えてください。
よくわかりました。
解説PDFの作成ありがとうございます!
今回はおみくじに当選した分の関係で月初めの使用量を見たときに
「ん?」と思いましたが、「前月分の繰り越し全体容量とそこからの使用量が
表示されているんだな」と理解したので特に問題とは思っていませんでした。
「当月の使用量」の文字を「使用量」にすれば問題ではなくなりますね^^
(「※使用量には繰り越し分、ギフト分が含まれます」と表示あれば完璧w)
パワーポイント見る限りかなり複雑な仕組みに見えてきます。ここまで詳細に解っているのならシステムを構築する際、不具合も出ることまで予想していたのかな?
しかし、ここまでガラス張りの運営もある意味スゴイですね。
で、システム屋としては理解しようとしてみましたが…(^_^;)
恐らくDBで管理してると思いますが、
ざっくりと所謂バケツに最終利用年月日と時刻(年~ミリ秒までとか)と、その時間情報更新時の残容量を別に項目として保持しておけば計算可能なんじゃないかと思いました。
もし月替わりで処理が追いつかないなら上記の項目を2ヶ月分(前月、当月)用意して項目更新時の実日と照らしてどちらの項目群に更新しにいけばよいかで月跨ぎギリギリのタイミングでも追っかけて計算(処理)可能なんじゃ?と…(^_^;)
勿論思いつきでキチンと設計なり検討してないので穴があるかも知れませんが(笑)
一般的には総容量と残容量が分かれば良いのだと思いますが、各月度末で容量の変更などをした場合など、締め日との関係で、処理が複雑になるのだと思います。
原則的には今のままで良いとは思うのですが、正確を期したいのであれば、各バケツごとの容量、残容量、有効期限がわかるようにするのが一番簡単ではないかと思いますがいかがでしょうか?
なんにしても、ご苦労様です。
色々大変だと思いますが、頑張って下さい。
と、頑張っているスタッフには感謝です。ブログを出すにあたって、どう表現すれば・どう見せたら・どう説明すればわかってもらいやすいか…一生懸命考えたり、作ったモノをやり直したり練り直したり…
大変だったんでしょうね。
お疲れ様です、ありがとう。
いやぁ、mineoってイイなぁ♪
少しでも解決の方向に向かうといいですね。
1つ疑問なのですが、p.22の表ですが、ギフトの残容量は、どうして基本容量のように月またぎでサイズに合ったバケツに移し替えを行わないのでしょうか?
どなたか分かる方みえますでしょうか?
現在の残量と月初め残容量
現在MB/月初めMB
と表示すれば解決しませんか?
バケツは2種類しか無かったからだと思います。
基本バケツ…N月
繰越バケツ…N+1月
繰越バケツは期限が来ると消滅する。
ここまでは、シンプルなんですよね。
ギフトバケツは元は他人のバケツ
他人のバケツを纏めると後が面倒になる。
(システムエラー時手間がかかる)
ギフトバケツの容量はギフト時点で決定しているので
新しいバケツを用意するよりもはじめからN+1月にした方が
システムに負担をかけない。
システムにふたんをかけないように
来月の基本バケツを26日に用意している。
(新入りさんが月跨ぎ開通で慌てるのもこれが原因でしょうね。)
なるほどね!バケツ総量ごと移動してたからゴースト発生したのね。
これはシステムの基幹部分から、やり直しなので大変でしょうね。
後からギフト、チップ、タンクなど追加したのでバケツの数が足りない!
これを合わせるには・・・・・
二番バッターさんが逆転サヨナラホームラン打つぐらい難しいですねw
気合い入れてホームラン出るの楽しみにしてます。(キツイか^^)
とのことなんですから、月初めだけ使用量の表示をやめてそこだけ「メンテナンス中」と表示するんじゃダメなんですかね?
残容量は正しいのだからそのまま表示して、正しく表示されない可能性がある物はとりあえず初日は隠しとく。
で十分だと思うんですが、問題というか実害ありますか?
とりあえずどこかに注意書きをしておけば良いのではと思います。
マイネ王に参加していないユーザさんもいらっしゃいますし。
早期に改善されることを期待します。
関係ないですが”2番バッター”とかどうやって決めているのでしょうか。
これ、皆知ってる内容じゃないですか。
ゴーストの仕様を理解している人は、皆わかっている事です。
超ガッカリしました~~~
「なぜ、この仕様になっているのか」
「なぜ直せないのか」
「なぜシステムの根幹にかかわるのか」
がこの説明では、全くわからないです。
具体的には、
P19「ギフトバケツも中の残容量もそのまま移行します。」
この理由がわからないです。
これは、ギフト機能ができるずっと前から、mineo開業時からパケットチャージも同じ仕様ですよね?
ギフトバケツが、使用量も一緒に翌月へ繰り越してしまうのは、何故なのでしょうか?
なぜギフトは残容量だけを繰越できないのでしょうか。
例えば、通信管理システムに繰越容量バケツがあって、ギフトバケツは契約管理システムの別のプラットフォームに存在して連携タイミングがこうだから、とか通信管理システムの繰越容量バケツの締め日が25日であるとか、何か理由があると思うのですが…
あとは、シェアしている人が、ゴーストが出ないのも、どういう仕組みになっているのかがわかりません。
もうちょっと詳しく説明してください~。
この説明はゴーストの「仕様」説明編ですので、「原因」説明編を求む!
参考になるかわかりませんが、楽天のポイントとかは、付与されるタイミングが特定の日で決まっていて、その前後は表示がおかしくなるよって注記されます。
ゴースト発生のタイミングで注記出すか、一時的非表示でよいのではないかと思います。
バケツの大きさと残った量の差でちまちま計算するよりも、どーんと「使用量カウンタ」を作って、そこに放り込んで表示して、月初めにリセットすれば簡単に解決すると思うのは僕だけ?
今のユーザー管理テーブルに「use_data」っていう変数を1個追加するだけで、その変数に他のバケツの減算時に引いた量を足していけばいいだけだよねっ。
ちなみに(あまりよくわかっていませんが)
発生するのは月初ですよね?
月初って事は、容量をそこそこ気にする必要もないので、
個人的にあまり気にする事案ではないと思っていますが、
ここまで気にされていらっしゃる方がいるってことは、
やっぱり気になる物なんでしょうね・・・。
物事、中の人にしかわからない「仕様」はどんな業界でもあって、
それはそれでいいと思います。
(それを開示してくれるだけでもまだマシです。)
この記事でわかって良かった事は、
・前月末時点の残容量データは翌月には消滅
→現状の残容量管理データから、使用量を知る事は不可能
・データ通信量明細ページで、高速/制限に通信量を分離する
という事で、高速通信量がわかるようになれば、OKだと思います。
もちろん円グラフの率がちゃんと出る方が良いですが。
円グラフと使用状況内訳の方は、どうにも改善できないという事だけはわかりました
(具体的な理由はわからないですけど)。
バケツの例えはとてもわかりやすいと思いました。そして、ギフトのバケツがあるなら、シェアのバケツもあるのかな、とも思いました。
ゴーストを知っていて、ゴーストが出る理由が知りたい人にとっては有効な解説と思いましたが、開通したばかりのユーザーがこの説明を読んでも、なんのことかわからないと思います。
毎月初、Q&Aで話題にあがる件です。正しく表示するための仕様で、そう簡単に変更できないのもわかりますが、ならばせめて、あれれ?と不安になるユーザーさんが少しでも減るよう、マイページに補足するなり、周知する必要があるのでは、と思います。