「ネイティブアプリ」を含む日記 RSS

はてなキーワード: ネイティブアプリとは

2021-01-07

ipadクリスタめちゃくちゃ使いづらくない?

普段ipadお絵描きするときはProcreateとAffinity designer使ってるんだけど

イラスト解説動画とかでクリスタ説明されてること多いから、そろそろ使い方覚えた方がいいかなとか思ってインストールしたんだ。

で、色々触ってみたんだけど印象としては「よくこんな不親切なアプリが支持されてるなって」ってところ。

アイコン説明とか一切ないし使って覚えろってことなんだろうけど、こんなんイラスト初心者絶対挫折するんじゃないか

あとipadネイティブアプリで画面上部のタブがあるアプリとか初めてみたわ。逆に斬新すぎる。

マニュアル00年代Windowsネイティブアプリみたいに見にくいしデザインアプリなのにデザインセンスがなさすぎると思う。

あと28無料期間残ってるけどもう使わないな

2020-12-23

ソースを送らないレコメンド方法、及びSmooz炎上理由考察

ソースを送らないレコメンド

あれを一番簡単に実現するのはソース送信だけどそれは無しとして他の方法模索してみる。ちなみに解は出てない。

※想定問答 Q「サーバサイドでやれ」 A「石油王連れてきて」

レコメンド対象キーワードを絞る

レコメンド対象にしたいキーワード辞書アプリに同梱してマッチした単語だけ送る。

本文丸ごとでは無いんで多少は忌避感下がるけど、いつ・誰が・どのURLでそのキーワードブラウザで見たかは伝わっちゃう。

パーソナライズ不要なら「誰が」も落とせるけどそれだと精度出なかったからあの仕組みにしたんだろうしねぇ…

あと本当に本文だけ使ったレコメンド目的ならURL不要だけどwww.muji.com→オサレみたいな特徴を加えたかったのかな。

--

クライアント側でレコメンドまでやる

機械学習かじった程度なんで理解が間違ってたらすまんけど、

最近iOS(CoreML)にもAndroid(NNAPI)にも機械学習機能あるようで、

ネイティブアプリなんだからその辺触れるんだしクライアント側で完結しちゃえば?という発想。

レコメンド先のコンテンツ丸ごとスマホに持つわけにはいかんから

コンテンツID?カテゴリ?的なものを出すとこまでやって中身はサーバに取りに行くんで本当にクライアントだけで閉じるわけじゃ無い。

パーソナライズ観点で一人一人特注のモデル作って配るとかはしんどそうだけど、

ある程度セグメント切った層ごとに事前にモデル作るぐらいなら何とかなるんでは。

ああでもレコメンド対象が日々増えるWeb記事だとモデル頻繁に更新するからデプロイが辛いか

スペックもりもりのサーバでやる推薦が現代スマホそもそも代替出来るのかはわからん

エッジAIなる名目で各社頑張ってて目的の一つはセキュリティから、今は無理でも将来に期待?

--

特徴ベクトルだけ送る

分類にしろ推薦にしろデータのものダイレクトに結果に変換するんじゃ無くて一度単なる数値の配列(特徴ベクトル)に変換して、

そのあとモデルに突っ込んだら中でこねこねヘイお待ち!と出てくるんだよね?

その特徴ベクトルに変換のとこだけクライアントでやってそれ送れば?という発想。

スペック問題はあるけどレコメンド全部やるよりはマシだよねと淡い期待を抱いている。

特徴ベクトルから元のデータに戻せるとアウトだけど可能なのかね。

文字列を数値にしててかつ情報量が落ちて結果が1対1にならないから、完全な復元は無理だと思うけどどうだろう。

ありとあらゆるキーワードを事前に変換しといて結果から逆引きすれば変換元候補を出すくらいはできるんかな。

--

Smoozは何故燃えたか

いろいろ考えたけどソースのものじゃ無くてもそれに近い情報はどうやっても送るんだから

コールセンター電話すると自動音声で「サービス品質向上のために通話を録音します」的なアナウンス流れたりするのと同じで、

おすすめ機能ってこういう情報送ります的な説明アプリ内ですべきでそれ無しにやっちゃダメだったんでしょう。

アプリの実物触る前に終わったので実際には説明してたんならごめんなさい。

--

もちろん規約にもちゃんと書くべきだろう。例えばこんな風に。

楽天ウェブ検索楽天スーパーブラウザ利用規約

https://toolbar.rakuten.co.jp/mobile/rule.html

利用者が本アプリを利用した場合利用者は、第6項の定めに従い、これを停止しない限り、本アプリデバイスインストールされているブラウザの全てのウェブ閲覧履歴httphttps含む。以下本条において同じ。)で始まる閲覧ページURLアクセス日時(分秒)、表示されたウェブページのHTMLソースクッキー情報Cookie), ウェブサイト閲覧履歴リファラ, ユーザー使用しているOSアプリバージョン位置情報をいい、以下「ウェブ閲覧履歴取得情報取得情報」といいます。)が当社によって取得されることに同意するものします。

当社が取得するウェブ閲覧履歴取得情報には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLIDパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本アプリを利用される場合には十分にご留意ください。

ソースどころか脆弱性無い限り聖域のクッキーまで取る豪快さを見習おう。

--

ちなみにフェアじゃないので一応書いておくと「楽天ウェブ検索 規約」でググると出てくるこっちのブラウザ拡張機能版は微妙に内容が違ってクッキーは入ってない。

上のアプリ版はアプリストアの説明URLが書いてある。なんでアプリブラウザ拡張機能で2種類あるのかは分からん

拡張機能じゃ取れないから? でもサイトごとのクッキー編集する拡張とかあったような・・・

楽天ウェブ検索利用規約

https://toolbar.rakuten.co.jp/intro/rule/

2. 利用者が本機能を利用した場合利用者は、第6項の定めに従い、これを停止しない限り、本機能インストールされたブラウザの全てのウェブ閲覧履歴httphttps含む。以下本条において同じ。)で始まる閲覧ページURLアクセス日時(分秒)、表示されたウェブページのHTMLソースをいい、以下「ウェブ閲覧履歴」といいます。)が当社によって取得されることに同意するものします。

3. 当社が取得するウェブ閲覧履歴には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLIDパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本機能を利用される場合には十分にご留意ください。

あとこの規約についても先日malaさんが突っ込んでいるので第一発見者ではないです。

https://twitter.com/bulkneets/status/1339435587015639041

--

ソースどころかクッキーまで取ってますと堂々と書いてるほうが燃えずに、

はっきりとは書かずに取ってたほうが燃えてるの、

表面上は正直は美徳という状態なのでなんとも微妙

やらないと思ってたやつがやる・やると思ってたやつがやる、どっちもやってるけど燃えるの大抵前の方なの、

多分ヤンキー捨て猫効果みたいなもんで(俺用語だけどわかれください)

人間合理的に動く前提とか幻想です感があって本当に辛い。

2020-11-11

自分用に開発した音声認識機能付の単語サービス公開してみた

中国語勉強を始めるにあたって自分用に単語アプリを作ってたら思ったより

大掛かりになってしまったのでせっかくなのでドメイン取得して公開してみたよ

当初は1週間くらいで完成させる予定だったけど2ヶ月くらいかかってしまった……

https://ankilt.net/

サービス名はankilt(アンキルト)

イメージとしては↓な感じ

https://i.imgur.com/VE4mA72.mp4

単語アプリなんて今どき競合だらけだと思うけど

既存スマホアプリは多くがデバイス間のデータの共有(特にPCとの)がやたら面倒だったり

編集画面スマホしか提供してなかったり微妙に不便なものが多かったので

今回はWebサービス(+PWA)として自分好みなUIで開発してみたよ、粗い部分もあるけどとりあえず公開だけ。

途中経過の保存とかは無理だけど一応未ログインでも使えるのと、

会員登録さえすれば覚えた単語、覚えてない単語シャッフル機能で並び替えたカードの順番とかが更新した瞬間にDBと同期されるので

朝に自宅のPCで半分くらい暗記して残りは職場の昼休みスマホからワンタップでそのまま続きを実行する、とかができる。

正否判定的な機能自由度高くするため敢えて緩め。



目玉機能としては音声認識発音確認ができること(win&androidchrome限定だけど)

一応中国語以外も英語韓国語などには対応してる

日本人には『right』『light』とか『year』『ear』の発音が難しいとはよく言われてるけど、その辺りの発音感覚音声認識のできる範囲で掴むことができるよ

あとは、中国語(簡体字限定)ではピンイン自動で表示してくれたりする



今回開発してて一番失敗だったと思ったのは、公開前提じゃなかったのでマネタイズかについての展開を開発中あんまり考えてなかったこと。

今回PWAとしてスマホアプリと近いものWeb実装する感じを意識したけど、このやり方だと広告サービス審査にはまあ大体は落ちる。

Ankilt単語帳一覧があって、その下に詳細ページ的な位置づけとして単語帳の実行画面があるページ設計になっている。

実行画面のファーストビューでは大体『apple』とかの1ワードが表示されてるだけなので、AdSenseを始めとしたASPからすると『文字が少ない=価値がないコンテンツ』と見なされてしまうみたいだった。

多くのASPSSPWeb広告あくまWebメディアブログ用のサービスであって、

いかがでしたブログでも適当に作った5chコピペブログでもいいか一定文字数で埋まったページではないと価値があるとは認めてくれないようで、

文字が少ないこの手のアプリブラウザゲームPWAとして実装した場合、仮にどんなに高機能品質の高いものを開発したとしても上記理由

基本的には単価が低いかアダルト寄りなもの以外つけにくく、サブスクモデルならともかくとして既存の人気ASP依存した広告収入モデルとはかなり相性悪そうだと思った。

マネタイズを狙うならもっとちゃんWebライクなインターフェースにして文字をなんとか埋めたりしてASP忖度するか、

またはガワネイティブででも同じ仕様ネイティブアプリを作ってアプリ広告(これはWeb広告審査基準がまた異なる)を載せた上でPlay Storeとかで配信する、

みたいなところに結局行き着いちゃう気がする(そこまでやるならPWAをやる意味は…)

要するにWeb用の広告からは「こんなのWebメディアじゃないか広告載せさせない」って言われてて、アプリ用の広告からは「こんなのアプリじゃないか広告載せさせない」って言われているような状態

ちなみにガワネイティブ案の場合広告審査とは別にGoogleAppleアプリ審査を通過するためにまた知恵を絞らなければならない。

調べてみるとPWA開発で同じような問題に直面してる人はまあまあいそうだった。

PWAってこの辺の事情があるから魅力的な技術の割に未だに流行んないのかなぁって気がした。

既存Webサービスを補助としてPWA対応するとかならまだしもガチガチアプリゲーム最初からPWAで作るなら心捨てていかがでしたブログでも作った方が金目当てだったらどう考えても楽だし得。

この辺りなんか良いサービス選択肢ないのかなぁ。

まあ今回は公開しても利用者自分だけとかになる可能性もあるので次回の教訓としてとりあえずは考えないことに。



今は最低限だけ実装してる感じだけどモチベの問題もあるのでもし需要があれば拡張していく予定。

まあよかったら見てみてね。

2020-09-22

anond:20200922114928

PWAの普及でWebアプリネイティブアプリ境界がなくなってきているっていう話ならわかるけど、アプリOS境界がなくなっているっていうのは、すまんがイマイチよくわからん

WebアプリPWAアプリケーションであって、OSとは異なるレイヤーにあるっていうのはこれまでと特に変わってないと思ってる

ただ、アプリインストール不要になりつつある分、OSの責務が減ってきてるねっていう話なら、確かにそうだと思う

2020-05-28

anond:20200528085809

DMMゲーのくせにエロもないっていう過去遺産、今やDMMクソゲーソムリエたちも誰も艦これの話はしてないしプレイしてるそぶりもない

ここ2年間くらいに出たDMMゲーの中には最近ネイティブアプリに見劣りしないゲームもちょいちょいあるけどね

2020-04-30

anond:20200430224136

chromeリモートデスクトップって以前ネイティブアプリとして実装されていたときはそこそこ使えたけど、今webアプリとして配信されてる版は速度も遅いし使えなくね?

というかRDP使ったことあるならchromeリモートデスクトップで何とかなるって発想はふつうしないと思うが。

2019-11-29

anond:20191129135009

フロントやってるが、まあ気持ちは分かる。

とりあえずスマホ対応結構かいかな。10年前にスマホあったけど、普及はこの10年。PCだけ考えていればOKだったのが、スマホも考えるとなると結構キツイところ。(PC横長、スマホ縦長だし)

あとはWebアプリ作る感じだとパフォーマンスの制約(ここにもスマホは絡む)と実現したいことのギャップキツイ普通に常時通信とか当たり前だし、Flash死んだし。

結構普通にネイティブアプリでやってたことがWebでできないとおかしい的な感じもでかいかな。ゲーム界隈とかほんとすごいと思うよ。使ってると気づかないんだけど、気づかせないのがすごい。10年前ならネイティブアプリWeb機能全然違うとか普通だったしね。。。今同じな方が普通だしね。。。そうなると開発規模が増えてFWとかモジュール管理が欲しくなってきて、ただそこも独自ルールを覚える必要もあるし更なる問題も出てくるからそこにも対応せんといかんしね。。。同じように実現できてても「まだNode.jsで消耗してるの?」とかクソヤローもたまに出てきて確かに便利だけど面倒なんじゃ!ってなるし。←ここは主の主張とマッチしてござるなwwwんんwww

いろんなライブラリたちがバージョンアップして、適材適所でやってたつもりが一本化できるんじゃね?できないの?検証しなきゃ・・・とかやらんとならんってのもあるなぁ。

まあなんだ、この10年でWebも変わってはいるんスよ。ただ同時にWeb"系"が隆盛して、マウンティーになっているのも事実かもなーなんて思う。俺なんてjQueryおじさんにもWebイケメンにもバーニーおじさんにもなれないような人間たわごとですけどね・・トホホ

2019-09-24

.net Core3.0はwindowsネイティブアプリケーションもサポート

ワイ「おっ、ええやんけ。さっそくインストールしてみっか」

dotnetコマンド「Running 'dotnet restore' on winformtest/winformtest.csproj...

/usr/share/dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(59,5): error NETSDK1100: Windows デスクトップ アプリケーションを構築するには Windows必要です。」

ワイ「そういうとこだぞ!」

2019-01-23

PWAネイティブアプリに取って代わるって去年の春頃に言ってた奴、

全く取って変われてないけど、どう落とし前つける?

指の一本くらい詰めてみるか?

2018-09-22

JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当コメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意セッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザー

「これは、セッションハイジャックか・・・!?

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ!」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッション任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記懸念全てにきれい対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字keyが生成された

解読時間は下記を参考に、計算windows10電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

数字大文字文字で約60の時は10桁で20万年と書いているが

現代の解析技術20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークン実装しなかったことを告白しておく

そのためapiサーバ上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険

JWT送信セッション(cookie形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン情報が奪われる危険が上がる
アプリから直接ログイン情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能識別子)が含まれ

おそらく一般構成仮定で書く

https通信するのでパケットキャプチャによる傍受は不可能と思っていた

(http通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記理由で納得できていない

アプリから情報が抜かれる危険性に関して

クライアントネイティブアプリ場合

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信セッション(cookie形式?)送信セッションからuser_id取得 

接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる

まりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

まりcookieだろうがjwtだろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメント発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意サーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初段落問題と同一と思っている

余談だが、ブコメ雰囲気日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意セッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたしま

2018-09-21

ネイティブアプリ開発者

Webに近いけど

正直Webの界隈こわい

あそこは例えるなら紛争地帯

ネイティブ平和日本って感じ

平和ボケしてそのうち絶滅しそうだけど

2018-09-14

Webアプリ検索性と網羅性の悪さ

クラウドWebアプリは嫌いだ。

HTML5宣伝されて、世間クラウドだのと言い始めたが、

iPhoneAndroidネイティブアプリが普及して、Chrome bookが廃れたのを見て、ざまあみろと思った。

社内のアプリケーションが InternetExplorer専用のクソ使いにくいWebアプリになったりして印象が悪かった。

開発元企業が、あたか先進的なテクノロジーのように宣伝しているのを見て死ねと思った。

ところが2018年現在、未だかつてないほど、Webアプリを使う人生を送るようになっている。

やはり Microsoft OfficeWebアプリ化した影響は大きかった。

俺の中で Webアプリもなかなかやる、という認識に変わった。

そうなると、Webアプリ検索性の悪さが気になる。

ストレージGoogle Drive使用するとして、Googleドライブから接続できる範囲Webアプリしか見えてこない。

iPhoneAndroidMacWindowsといった胴元のいるプラットフォームなら、アプリストアが整備されるので、

必要サービスが探しやすいが、Webアプリはとにかく検索性が悪いと思う。

検索性が悪いため、ユーザーが集まらず、サービス簡単に終了したりする。

なんだかんだでネイティブアプリが好きだが、Webアプリも使っていきたい。

この問題が解消されることを願っている。

2018-09-13

つのソースiOSAndroid両方対応

「一つのソースiOSAndroid両方対応」みたいな某フレームワーク

画面はHTMLロジックJSで書くようなやつ。

会社アプリがそれで作っているけど、iPhoneXで動作おかしいともめてる。

から、そんなのやめて普通にネイティブアプリで作っとけって言ったのに。

2018-06-30

anond:20180630230123

そう思うだろ?

そこら辺の問題ネイティブアプリで「広告がない代わりに値段がついているアプリ」と、「広告がある代わりに無料であるアプリ」を比較した際に

圧倒的に後者の方が収益性DL数も高かったこから、やっぱりガラケーおじさん並みの「珍種」でしかないことが市場によって証明されている。

はい一定広告を嫌う人間はいるので、その人間をも食い物にするために「広告オフにするオプション」を有料で提供したりもしている。

まりは、オフにできない広告がある現状がまだ不自由なだけで、アドオン広告を消すための有料オプション基本的広告を出力する全てのプラットフォーム採用されれば解決する問題とも言えるわけだ。

世は増田が思うよりは広告に寛容なんだぜ。

増田だって電車降りて駅から出た途端に無数の広告に囲まれてるやんか。

時間テレビ見たら12広告見てるじゃねえか。

そこで蕁麻疹起こすんか? 起こさんだろ。そういうこっちゃ。

2018-05-26

Webアプリしろネイティブアプリしろアプリケーションを作れるっていうことは要は

自分スキル学習を記録したり加速したりするアプリケーションも作れる」

っていうことなので

別に十年後に力が衰える心配とかはする必要が無いんだと思います

2018-03-22

https://anond.hatelabo.jp/20180321171652

調べたら、本当にPWAネイティブアプリの見分けがつかないって書いてる人がいて、うわぁ……と思ったけど、まあ将来的に改善される可能性はあるんじゃない?

今のPWAオワコンというのには禿同

2018-02-26

ミリオンvsシンデレラ、好敵手が育てた2つのアイマス

さてさて、いきなりタイトルがこれですが、何で書こうかと思えば2月14日配信したミリオンニコ生ミリシタのことは触れてもコンテンツとしてのミリオン5周年に全然触れてないので、5周年前日というこの日にこちらが勝手に振り返ってみましょうかと。本当は副題に「-ミリオンライブ 5周年に寄せて-」と入れるつもりでしたが、入らなかったのでここに記載w

なお、筆者はどちらかといえばデレマス寄りの人間ですので、それを承知の上でお読みください。

モバマス成功からグリマス誕生まで

元よりこの作品、あらゆる意味で「大人の事情」が複雑に絡み合った作品でした。遡ること2011年11月に先んじて「シンデレラガールズ」(モバマス)がリリースされたわけですが、想定の10倍の売上を記録したもんだからバンナムにとってもソーシャルゲームは稼げると確信付けたに違いありません。しかモバマスCygames外注したが故に当然レベニューシェアが何割か取られることになります。そこで本家の開発陣で作った純正アイマスソシャゲを作ることで自社の収益を最大化したいのは言うまでもありません。

一方でモバマスの人気に指を咥えていた会社もいました。モバゲー(DeNA)のライバルであるGREEです。元々他でヒットしたソーシャルゲーム模倣して売上を伸ばしていた同社からすれば、アイマスは喉から手が出る程欲しい作品です。こうした利害の一致からバンナムGREE戦略的業務提携し、GREEアイマスの開発がスタートしました。

ところでこのGREEアイマスは当初男性アイドル物になるはずでしたが、坂上総合プロデューサーによって時期尚早と待ったがかけられ「765プロ新人」という設定に変わりました。また、上層部からモバマスのように100人アイドルを出せとの指示もあったようですが、結局は50人(765AS13人+新規37人)に落ち着きました。グリマスがいわゆるSideMのようなものとして生まれてたらどんな未来だったか想像つきませんよね。

さらバンナムはもう一つの課題を抱えていました。IP(知的財産)を軸としたグループ企業間連携です。今までアイマス音楽CD日本コロムビア販売してますが、これを自社グループ傘下のランティスからも発売すれば当然グループ連結の売上にも寄与します。そんな形でGREEアイマス、即ちミリオンライブ!(以下グリマス)は誕生します。

モバマスの逆襲

ここで寝耳に水だったのはモバマスの開発元であるCygamesモバマスの出演声優陣です。木村取締役(当時)の「サイゲームスとモバマスユーザーズッ友だよ」発言や、一部出演声優から発言からも察するに、グリマスが出れば自分たちはお役御免になってしまうのではないか、そういう危機感があったのです。

奇しくもモバマステーマ曲お願い!シンデレラ」(4月10日)とグリマステーマ曲「Thank you!」(4月24日)はほぼ同時期に発売、しかも「Thank you!」は8thライブの先行抽選販売まで付いていました。極め付けは2014年公開の「THE IDOLM@STER MOVIE 輝きの向こう側へ!」でミリオンアイドル7人が出演すると聴いてアニメ出演まで出し抜かれてしまます。なお2013年当時のモバマスオンラインゲームとしては「艦これ」、二次元アイドル物としては「ラブライブ!」という強力なライバルの奇襲に囲まれてました。つまり前門の艦これラブライブ、後門のミリオンライブ!という状況だったのです。

もっともこれがモバマスが奮起する原動力にもなりました。CINDERELLA MASTERシリーズや年1回の総選挙でボイス付きのアイドルを増やし、新規イベントを次々と増やすことでユーザー繋ぎ止めを図ったのです。単独ライブアニメ化も、いわば自分達で掴んだようなものです。

さらCygamesが水面下で開発していた新作RPGグランブルーファンタジー」も助け舟になりました。2014年秋に開催されたコラボイベントモバマスを梃子にグラブルユーザー数や売上を拡大した契機になり、またアニメ化前にPの熱気を暖めることにも成功しています。つまりこの逆境が無ければ今のシンデレラガールズCygamesもなかったことでしょう。

グリマスに訪れる苦境、そしてミリシタへの道

2015年から始まったアニメ軌道に乗ったシンデレラガールズに対して、ミリオンライブ!は苦境を迎えることになります。初年度から2年目こそ毎月のようにCDリリースされる程勢いは良かったのですが、コアであるゲームアクティブユーザーや売上が漸減していってたのです。それもそのはず、グリマスリリースされた2013年は前年に「iPhone5」が発売し、「パズル&ドラゴンズ」(パスドラ)等のヒットでブラウザソーシャルゲームからネイティブアプリトレンドが移行していました。アイドル物でも「ラブライブ!スクールアイドルフェスティバル」(スクフェス)などアプリを主戦場とするタイトルが中心となり、前時代的なブラウザソーシャルゲームでは太刀打ちできる状況ではなかったのです。でも楽曲ストックは沢山あるのだからリズムゲームを中心にしたアプリに移行すればいいと皆考えるでしょう。

ところがここで思わぬ伏兵が出てきます。そう、シンデレラガールズリズムゲームスターライトステージ」(以下デレステ)です。完成度の高い3Dモデルによるリッチ演出アニメまでの楽曲の少なさを逆手に取ったイベント新曲の導入、まるで玩具箱の人形が飛び出してきたかのようなルーム機能…元よりのシンデレラガールズ達の知名度の高さも手伝って、デレステは瞬く間にスマホ向けリズムゲームトップシェア上り詰め、今や国産ゲームアプリでも年間10位以内の売上を誇ります。想定以上の大型タイトルが出現したため、当初2Dで開発していたというミリオンライブアプリ計画は振り出しに戻されます

そして2017年にようやくリズムゲーム「シアターデイズ」(ミリシタ)をリリースすることになりますデレステを越えるアプリにすべくパートによる歌い分けやフルポゴンによるコミュニケーションパートなど意欲的な技術が導入されるのでした。サービス開始当初は配信楽曲の少なさやイベントスケジュールの遅さなどが響きつまづきましたが、最近になりようやく毎週のセールスランキングで上位に食い込むようになりました。さすがにデレステ程でなくてもリスクヘッジのようにデレステが売上の谷間を作りやすい月の半ばから下旬を補完するくらいにはなったのです。P視点ではグリマスサービス終了の影響か「俺たちがミリオンを支えなくてどうするんだ」と奮起するようになったのではないかとも考えられます

765プロ未来」を摑み取れ!

てな訳で皮肉なことに同じアイマス一家の姉シンデレラと妹ミリオンライバルとして、互いを高め合うべく切磋琢磨しているのです。しかシンデレラミリオンもまだ安穏としていられません。スマホ向けアイドルリズムゲーム元祖スクフェス3DCGを身につけた新アプリとなって逆襲の機会を伺ってますし、今春グリマスサービス終了と引き換えに、完全新作「アイドルマスター シャイニーカラーズ」(シャニマス)が控えています。同じアイマス一家にも新入りの後輩というライバルが生まれるのです。

思えばアイマス歴史逆境を乗り越える歴史でした。大体最初アニメ化サンライズ側の都合で設定や声優まで替えられてしまうような作品でした((ゼノグラシア自体スパロボX-Ω参戦など、むしろ公式積極的に弄ってくれてるのでもう誰も気にしてませんがね))。それでも9.18という混乱を乗り越えてアニメで栄華を極めた765プロ所詮傍流という立場から奮起し、今やアイマスは元より二次元アイドル物有数の稼ぎ頭に進化したシンデレラガールズ、先の9.18で生まれたが故に「忌み子」扱いされたJupiterが新たな事務所、新たな仲間と共に真の栄光を掴んだSideM…みんな苦難を乗り越えて今の栄華があるのです。

ならばミリオンライブ!逆境はまさしく今ではないでしょうか。原典の終了、アニメ化の目処も立たず、シャニマスという後輩が生まれる今だからこそです。ミリシタを拠点に再起を図り、逆境を乗り越えた先にこそミリオンライブ!の真の未来が見えるはずです。だって、「765プロ未来はここにある」んですから

2018-02-04

何故ソシャゲサービス終了するのか?

最近サービス終了したソシャゲと、そのユーザーの反応を見ていて思う所があったので書いてみる。

ソシャゲサービス終了する理由

一言で言うと「会社として続けていくことが難しくなったから」ということになる。

で、9割方はお金問題になる。売上がでなければ当然サービスを維持できないので終了する。

開発チームの人員が確保出来なくなったとか細かい事情は色々考えられるけど、結局どれも根本お金問題だったりする。(お金があれば人は離れないし、確保もできる)

逆に言えば、例えばApp Storeセールスランキングトップ10に居るようなアプリはハッキリ言って突然サービス終了するなんてことはあり得ない。

なんで売れなかったの?

ソシャゲビジネスモデルは大きく分けて2つある。

ソシャゲの売上はざっくり言うとDAUアクティブユーザー数) × ARPUユーザー一人あたりの平均課金額)で求められるので、どちらかを上げれば売上も上がると言える。

DAUモデル

DAUを増やして売上を上げようという算段のモデル。要は薄利多売。

有名所で言えばモンストFGOなどが挙げられる(FGOは一人あたりの課金額もすごそうだけど…

ARPUモデル

ARPUを増やして売上を上げようという算段のモデル。言い方は悪いけど、一部の廃課金者にごっそり貢がせようという形。

有名(と言えるのかよくわからないけど売り上げランキング上位の)例としては戦国炎舞 -KIZNA-など。

ここ数年はアプリの数も増えてソシャゲ市場は完全にレッドオーシャン状態なので、特にユーザー数の獲得が難しいオリジナル新規タイトルはこのモデルに寄りがち。

売れなかったアプリはこのどちらのモデルにも寄せられなかったということになる。

DAUモデル場合はちゃんと万人受けするものを作れていなかったとか、広告宣伝が足りてなかったとか、そもそもターゲティングを読み間違えていたか

ARPUモデル場合は、しっかりとコアユーザーに課金をさせるためのゲームデザインができていなかったということになる。

こんなに人気があるのになんで終了しちゃう!?

それは多分あなたの見えている範囲内だけでの話。

Twitterなんて近しい人間フォローするのでその中で盛り上がっているように見えるのは当たり前。

とりあえず試しに人気アプリFGOとか)と自分のやってるアプリTwitter検索して、ツイートの流速とか比較してみるといいと思う。

極めつけに言うと、ソシャゲの売上はストアランキング見れば大体分かってしまうので、ランキング推移を人気アプリ比較してみるといい。(「アプリ ストアランキング」とかで検索すると推移を見れるサイトが出る)

実際どれくらいになったらヤバいの?

会社の規模とかにもよると思うけど、ざっくりとした感覚で言うと、ストアランキングの「"総合"セールスランキング」で、月に一回(ガチャ更新の日など)くらい「100位以内」(ゆとりを持って見ても200位以内)に上がらないアプリ結構厳しい。

圏外の場合はハッキリ言って論外なので、いつ終了してもおかしくない。

色んな推論が飛び交ったりするけど、ランキングさえ見れば9割方は判断が付くので、変な憶測飛ばしたりする前に、まずはランキングを見て欲しい。

売れないからって打ち切るのはひどい!

これは結構見るけど、売れないから打ち切るのは至極当然の判断

結局金かよ!とか冷たい判断、とか思うのかもしれないけど、そんな感情論ではなく世の中はお金で動いている。

当然アプリを開発するのにもお金がかかっている訳で、開発チームの人件費だったり、サーバー等の運用費だったり、広告費だったりと、恐らく皆が思っている以上のお金がかかっている。(特にネイティブアプリに移行してからは開発費用も期間も大幅に増えている)

そのお金を賄うのは会社経営陣)な訳で、その回収が見込めなければ終了せざるを得ないのは当然。

「開発チームはまだまだ続けたかったはずだ!」なんてのも見るけど、その開発チームの給料を払うのも会社な訳で、極論を言えば売上が出なければ開発チームの人間給料を払うこともできなくなる。

結局売上が無ければ開発チームも満足に開発できる環境は得られないし、最終的には誰も幸せにならない未来しか残らない。

あと、これは個人的意見だけど、ゲームが好きとは言え、売上の上がらないゲームの開発をし続けるのは正直モチベーション的にも厳しい所があるし、

それを何も知らない外部から勝手憶測で「まだやりたかったはずだ」とか言われたり、誰かを悪者にされたりしてもあまり気持ちの良いものではない。

サービス終了を悲しむのはいいけど、変な妄想で周りを攻撃したり、自分勝手エゴ押し付けるのは辞めておいたほうが良い。

そんな事をしてもサービスは復活しないし、作り手も嬉しくはない。

お金払えば復活してくれるの?

サービス終了の判断まで行くという事は既に結構厳しい状況という事なので、現実的には難しい。

例えば仮に有志100人が集まって毎月皆でン十万円課金してくれるとかなら続けられるかもしれないけど、そんな事をしても運営ユーザー疲弊していくだけ。

現状で売上が上がっていないということは、無理をして解決しようとしたって絶対破綻する。

結局誰が悪かったの?

売上を上げられなかった開発チーム(具体的に言えばターゲティングとそれに合わせた課金モデルをうまく作れなかったプロデューサーディレクタープランナーなどの責任が重い)と、

適切な判断ができずにGOサインを出してしまった経営陣が悪い。

サービス終了で悲しまないためにはどうすればいいか

身も蓋もないことを言ってしまえば、サービス終了しそうなゲームプレイしないこと。(ランキング圏外のゲームプレイしないこと)

とは言え、そうやってニッチゲームに誰も課金しなくなって、人気ゲームだけに一極集中してしまうのは少し寂しいものがある。

大人な心をもって、無理のない課金ゲームを楽しんでくれれば作り手としては嬉しい。

お前は誰だ?

ソシャゲ業界に居た人間。いくつかのソシャゲサービス終了を看取ってきた。

ソシャゲに関わるのに疲れて、今はWeb系の会社まったり仕事している。


2018/02/05 追記

なんか結構反響があったので、改めてこの記事で言いたかたことの整理と、いくつか多く見られたコメントへの返信も書いておく。

 言いたかたこ

特に言いたかったのは3つ目で、別にソシャゲの話でなくてもこういう事は多いけど、ちょっとむしゃくしゃしたので書いた。

コメント返信

当たり前の話じゃん

全くもって本当にその通り。こんなことをわざわざ書いた理由としては前述の通りで、まあ単に個人的ストレス発散が目的

増田なんか読んでるような人間は当たり前に思うかもしれないけど、実際当たり前な事を理解してない人間は多い。

お金以外の問題で終了するパターンは?

そのパターン自分も直面したことは無いので知らない。自分ソシャゲ業界全てを知ってる訳じゃないので免責も込めて9割と言ったけど、まあ99%くらいはお金問題帰結すると思う。

拡散性ミリオンアーサー乖離性に移行する以前の問題として「運営の体力が厳しかたから」って事らしいし。

https://app.famitsu.com/20141226_479007/

FGOが高DAUモデル

FGOは割と特殊な例なので今回の例としては相応しくなかったなと思うけど、DAUが多いのは確か。(と言ってもモンストとかツムツムレベルでは無いが)

実態としてはDAU結構多くてARPUも高めって感じだと思うので線引が微妙な所。

個人的にもFateは一部の古参ファンが金をめちゃくちゃ注ぎ込むコンテンツという認識だったので、ここまでユーザーが増えたのには驚いてる。

ちなみに今回はシンプルで分かりやすいようにDAUARPUを挙げたが、売上の指標としては他にPUR(課金ユーザー割合)、ARPPU(課金ユーザー一人辺りの平均課金額)とかもある。

この辺の話は割とよく出てくるので、興味があったら調べてみると良い。

終了後にコンテンツを残してほしい

この声結構多くて、実際最近では終了後にも楽しめるようにコンテンツを残してくれるソシャゲも増えてきている。(ポプストとかあんガルとか)

その取り組み自体は素晴らしい事だと思うけど、実際これをやろうと思うと思った以上に手間が掛かる。それはつまりお金(人件費)が掛かる。

結構簡単にやって欲しいとか言うけど、アプリ簡単オフライン化できることなんてまず無くて、結構根本から作り直さないと難しかったりする。

それにオフライン化してリリースたからと言ってそれで終わりにもできなくて、リリースする以上ある程度はサポートバグ修正などもしなければいけないので、それに対応する運用体制必要になってくる。

設定資料集みたいな物を作るとしてもデータをまとめたり編集作業したりでそれなりに工数が掛かるし、印刷費なども掛かる。

データアーカイブの公開も、主に外注権利関係問題などがあったりして、簡単にすぐ出せるようなものでもない。

から、あまり期待を膨らませられても困るし、サービス終了を検討するような状況の所に身銭を切らせてやらせるのは酷だという事は理解して欲しい。

ソシャゲ業界はいつ潰れる?

これも数年前から言われ続けてるけど、自分は潰れること無く続いていくんじゃないかなと思ってる。

最近任天堂まで参入してきたし、去年はアズールレーンみたいなオリジナルでのメガヒットタイトルが久々に出てきた。

あと、Appleガチャ確率表記義務付けた話も、裏を返せばAppleガチャモデル容認したとも取れる。

今更大規模な法規制が起きる事も考えにくい(誰も得しない)し、仮にソシャゲ規制してもコンシューマに金が流れるとは思わない。

ただ、「日本の」ソシャゲ業界は厳しい状況になってきてるだろうなと思う。

アズールレーンの台頭から既に騒がれつつはあるけど、中国の持つ資金力に加えて、日本でも売れるコンテンツ力が付くと、正直勝ち目は無いんじゃないだろうか。

もうソシャゲ業界でも「金がなくてもワンチャン成り上がれる」みたいな夢のある話は無くなってて、体力(資金力、開発力)のある企業がしっかり丁寧に作らないと勝負にならない。

それができる企業というのはもう本当に少ない。悔しいけど、多分Cygamesくらいしかいかも。

正確に言うなら、ソシャゲビジネス自体は無くなることは無いけど、日本ソシャゲ業界は衰退していくのかもしれない。(あるいは既に衰退し始めている)

2017-12-08

anond:20171208141536

厳密に言うと「ソーシャルゲーム」とはSNS上でプレイできるゲームことなんだけど、

ご存知のとおり現在の主流はネイティブアプリだし、

それ以外のブラゲもSNSの衰退に伴って「いろんなSNSアカウント連携できる」程度になってしまっている。

なのでもう「ソシャゲ」という表現はどう頑張っても実態に即さないし、

その呼称を使ってる人たちもガラケー時代からの習慣で使ってるだけ(「写メ」と同じ)。

その上で、たまにガチで「ソシャゲ」で認識が止まっている奴がいて、

ポチポチゲー」を思い浮かべながら「ソーシャル性」について語ったりするから嘲笑されるんだな。

2017-07-10

職業プログラマに向いてない

新卒プログラマー受託下請けじゃないSI会社で働いている。

現在ネイティブアプリの開発をしている。

プログラミングが嫌いなわけじゃない。

会社以外でもコーディングをしている。

副業のためのプロダクトを作ったり、単に自分にとって便利なスクリプトを書いたり。

ただ、業務で書くプログラム情熱が注げない。

rubyに比べて書きにくいJavaを使っているからか、それともモバイルが良くないのか、私がやりたいことはコーディングじゃなくてプロダクトを作ることだったのか、どれが原因なのかはわからないし、全てなのかもしれない。

ただ、情熱が湧いてこないのだ。

2017-07-09

BA以外の回答を見るにはChiebukuroViewer.exeインストールしてください

Y!知恵袋が少し前まで、スマホ版ではWebではBAしか見せず、それ以外の回答はアプリで見ろとアプリゴリ押ししてたのは記憶に新しいだろう。幸いにも今はWebで全部見れるようになった

なぜスマホサイトアプリゴリ押ししたがるのだろうか。Webで完結するサイトをわざわざネイティブアプリを介して見させる意味がわからない。(*よく利用する*人なら通知がくる、手軽に投稿できるなどネイティブアプリメリットはあるが)

togetterだってアプリ推してくるし・・・

もしPC知恵袋を見ててChiebukuroViewer.exeインストールして続きを見るとか言われたら(゚Д゚)ハァ?となるだろう。

ブラウザで完結するコンテンツでなぜスマホだけ専用アプリを使わそうとするのか。

ログイン ユーザー登録
ようこそ ゲスト さん