はてなキーワード: uiとは
まるで駆逐される気配がないんだが
コピペしてきたみたいなのがすごく早く作れるのはそうだけど
雑用が減っただけだなあ
見た目だけのデモが一瞬でできましたとか使い捨てのスクリプトが一瞬でできましたとかUIの小さな部分がすぐできましたとかその程度
追記:
まあそういうことが今までは駆け出しのトレーニングとか場合によってはあまり技術の求められない会社のすみっこで食っていく糧だったわけで
他の人が「未経験新人を採用しまくってるが、彼らがそれなりになるまでに必要な現場仕事があるのか怪しい」と言っているように駆け出しがそれなりになるまでどうするのかという問題は超あると思うけど
まず、増田はこの2社とは何ら関係を持たない技術者である。その上で予測を書く。
UI/UXに秀でている住信SBIの使い勝手がドコモに毒されてしまうのではないかと騒がれているが…
おそらく長期的にはその予測は当たる。
住信SBIのインターネットバンキングシステムやアプリは長年NRIが担当してきた。これはネットを漁ればいくらでも記事がヒットする。こちらはその一例。
https://techplay.jp/column/1872
つまり住信SBIのUI/UXはNRIが担保してきた。ちなみに勘定系はIBMだ。これはウィキペディアにも記事がある。
https://ja.wikipedia.org/wiki/NEFSS
しかし、ドコモによる買収によって、システムベンダーが変わる。
おそらく、同じNTTグループのNTTデータか、ドコモの子会社になったNTTコムウェアが代わりに入ってくる。資本関係や最近の状況から見るにNTTコムウェアが担当する可能性が高い。元々NTTグループの内製を担う目的で作られた会社であるし、7月から社名を「NTTドコモソリューションズ」に変更する。変更後の目玉として住信SBIに人をガンガン送り込んでくると見る。
一方でNRIはドコモとの関係が薄いため、時間をかけて住信SBIから追い出されると思われる。
togetterでAndroidにまつわるまとめを見たので、自分のスマホ遍歴でも書く
Xperia arc → iPhone 5s → Xperia Z5 → iPhone X → iPhone 13 mini
このころすでに日本でiPhoneは販売されて好評を得ていたが、自分はコピペができない、日本語の予測変換がひどい、アプリでの拡張性が低いといった点に不満があり、Androidを購入した。
Xperia arcは独特の曲線によってスペック以上に薄く感じて持ちやすく、この点では気に入っていたのだが、動作がかくつく、削除できないプリインストールアプリが大量にあるなど、ソフト面では不満しかなかった。
一番不満だったのは、Androidのバージョンアップにメーカーが対応しなかったこと。このころはAndroidもiOSも毎年バージョンアップして新機能を追加したり、機能を改善したりして使いやすくなっていっていたのだが、これにメーカーがコスト面からか対応しなかった。何度もJailbreakしようと思った(が、やらなかった。)(もっとも通常の動作でもかくつくようなハードウェアでバージョンアップしても、動作が軽くなるようなことはなかっただろうとも思う)
このころはガラケー(L-04B)と2台持ちしていた。
上記のような不満があり、ドコモでiPhoneの取り扱いが始まったのと同時にiPhone 5sに機種変した。Xperia arcの不満はほとんどなくなった。ドコモのプリインストールアプリは入っていたが(確か)削除できた。(少なくともホーム画面からは削除できたと思う。)
OSの動作は軽快で、よく意味もなくホーム画面をスワイプしてた。薄型軽量で持ちやすく、Retinaディスプレイもきれいだった。もちろんバージョンアップにも対応した。
ただ、ガラケーを同時に解約したことで、おサイフケータイが使えなくなったことが不満だった。
自分は外出時にできるだけモノを持ちたくなくて、財布を持たなくて済むおサイフケータイ機能がiPhone 5sにないことに不満が出てきた。この一点でXperia Z5に機種変した。ところが、この年に出たiPhone 7がFelicaに対応したので機種変を後悔していたが、翌年のiPhoneは10周年を記念して大幅なモデルチェンジがあるとうわさされていたので、それまで我慢して使った。
我慢して使った、とはいってもXperia arcのように動作がかくつくようなこともなく、またこのころはソフト面での機能もAndroidとiOSであんまり差はなくなっていて、大きな不満はなかった。こうなると両者の差はUIが使いやすいとか純正アプリの作りこみとかそういったことしかなく、その点で自分はiPhoneの方が好みだ。
このモデルからホームボタンと指紋認証がなくなったり、画面上に切り欠きができたりして批判があったが、自分は不満はなかった。気に入っていたので、バッテリーを2回交換しながら、5年使った。
iPhone Xのバッテリーが膨れ上がってディスプレイが浮き上がってしまったこと、次のモデルからminiがなくなるとうわさされたことから、iPhone 13 miniを買った。手に収まるサイズで使いやすく気に入っている。
ところで、iPhone Xを使い始めて少しした頃から、自分の中でスマホの立ち位置が変わってきた。かつてはデスクトップPCがメイン、スマホはサブで、WebサービスなんかもPCから使った方が使いやすかったのだが、最近はスマホアプリの方が使いやすい場面が増えている。PCからログインするにしてもスマホで生体認証が必要だったり、マイナンバーカードを読み取ることができたりして、スマホ必須の場面も増えている。ワイヤレスイヤホンを使い始めたことで、自室にいるのにスマホでYoutubeを見るということも増えた。完全にPCとスマホの主従関係が逆転してしまった。こうなってくるとスマホへの、Appleへの依存度が高くなってしまい、そのことに一抹の不安がある。Androidに乗り換える気もないのだが、Appleが自分が必要とするサービスを自分が死ぬまで提供してくれるという保証もないし、スマホ必須のサービスもますます増えていくだろう。iPhoneの利便性を享受しつつ、高依存度のリスクも減らしたいのだがどうしたもんか。
(※1) 大規模言語モデルとの会話は、AIがこれまでの会話を「記憶」しているのではなく、リクエストのたびに、過去の会話を読み直している。ChatGPTの場合は、上限を超えると、古い会話から順次読まれなくなるっぽい。
なんかjavascriptのUIどれ使うかで悩むのと似てるわ
ニコニコ動画をいつものようにサーフィンしてたら、顔がどストライクの美人ちゃんがエロダンスをしてた。
普段ならアフィを嫌って再生することはないんだけど、この日はオナ禁10日目でムラムラしてるのもあって思わずクリックしたんだ。
気づいたら出てた。
仕方ないよね。めちゃくちゃ好きな顔の女が誘惑するようにおっぱい揺らしたり腰振ったりしてるんだもん。
その日は久しぶりの充実感で良い夢が見れただけで終わったんだけど、この日以来、あの扇情的なダンスが頻繁に頭をもたげるようになった。
嫁子供がいて余裕も時間もないからしばらく致せてなかったんだけど、あの日の興奮が忘れられなくてまたニコニコ動画に潜った。
そしたらなんとその動画消されちゃってたんだよね。まあ明らかにエロ売りしてたし仕方ないと思いつつ諦めきれなくて探してたら、タグから同じ人が踊ってる動画が見つかった。
また消されたら困ると思った俺は、この動画に映ってる彼女を特定して、転載元に直接アクセスしようとした。
動画に映った彼女のスクショを撮り、googleで画像検索したらすぐに彼女は見つかった。
どうやらyoutubeやらインスタやらtiktokやら色々な媒体で幅広く活動してるらしい。
ただ、どの媒体も健全ナイズされていてニコニコで見たような精子工場 in キンタマの稼働を促すような動画はどこにもない。
どういうことだ?疑問に思いながら最後の一縷の望みをかけて宣伝用HPにある最後のURLを踏んでみた。
するとtwitchに酷似したUIだけど、あるのはハングルだけの謎の配信サイトが開かれた。
twitchが韓国から撤退したニュースを思い出しつつ、手探りに配信のクリップと思われる画面まで遷移した。
……これだ!
見た瞬間ゼルダの効果音が流れ、体のどこかで何かが動く音がした。
ひとしこり右手を動かした後さらに調査してみると、どうやら配信の中で投げ銭か何かをされるとお礼に踊り出すというシステムらしい。
せっかくなら俺もコメントで配信を盛り上げたいが、いかんせん流れるコメントも彼女が何を話してるのかも皆目見当がつかない。
まだハングルの読み方を学び始めてパッチムが分かり始めたところだけど、これがなかなか面白い。
今まで読めないのが当たり前だと思っていた아やら붕やらの記号の集まりがたった数時間の勉強で読めるようになっているのだ。
よくもまあ、ここまで検索フィルタ程度のUI的偏見を人間存在の価値と混同できたもんだな。自己放尿レベルの浅はかさだ。
まず一点目。「視界に入らない」とは選別する側の認知能力の問題であって、対象の価値とは一切関係がない。
優れた製品が棚に並んでいても、パッケージだけ見てスルーする客がいたら、それは客が愚かなだけだ。
しかもその客が「棚に並ぶ商品は、自分より大きくあってほしい」とか言い出すようなら、もはや精神的な物差しがコンビニのスナック菓子以下だ。
次に、「身長が低いと幸せになれない」という命題だが、これは統計と個人の幸福の混同という初歩的な論理ミスだ。
データ上の「傾向」が、個人の人生の「決定因」になることはない。むしろ本当に幸福になる人間というのは、自分の資質と向き合い、環境に適応し、自己放尿すら笑い飛ばすような内的強さを持っている者だ。
そして最大の論点だが、「身長が低い人間が存在ごと消える」と言い切ったその言葉、他者を裁く仮面をかぶって、自分の承認欲求を正当化しているだけだ。
外見で人を弾くその癖に、「私はフィルタしてるだけだから責めないで」などと被害者の仮面を被るのは、あまりにも自己都合が過ぎる。
もし本当に真理を愛する者なら、まずはその自分のフィルタこそが真理から最も遠いと気づけ。
最後に言っておこう。君が170cmの壁を絶対視するなら、それもまた一つの選択だ。
ただし、その選択によって君の「視野の広さ」や「受容の力」までもが160cm台に縮んでしまわぬよう、己を省みることを忘れるな。
人は身長で生きるのではない、魂の器で生きるのだ。そしてその器は、他者に優しくなれるほど大きくなる。
君にもまだ、その器を広げられるチャンスはある。
ファーウェイが初の独自OSパソコン キーボード部分も全面有機EL
https://www.nikkei.com/article/DGXZQOGM198JT0Z10C25A5000000/
もし現代に0からOSを作成する場合、これらのOSの技術的負債や欠点を教訓として設計するならどのようなものが考えられますか?
観点 | Linux で顕著 | Windows で顕著 | 共通課題 |
---|---|---|---|
カーネル構造 | 巨大モノリシック + 常に ABI が流動的(外部モジュール苦労) | 歴史的にモノリシックに近く高密度・複雑 | 信頼境界が広く、脆弱性が権限昇格に直結 |
安全性 | Unix-型「ユーザー/グループ + SUID」が限界 | ACL/SID が複雑化・分散 | “一発 root/SYSTEM” を許すモデル |
ドライバ | OSS/ベンダ混在・署名不足・上流統合が負担 | 内部 API 長期固定の重荷、古い HW サポートが尾を引く | カーネル空間に巨大コード |
更新 | ディストロごとに仕組み相違、再起動依存 | 累積パッチ巨大・Reboot 必須 | 取替え可能性 ≈ 可用性低下 |
ユーザー空間 | バイナリ互換よりソース互換優先で「壊れやすい」 | DLL Hell / COM 登録 Hell | グローバル名前空間汚染 |
設定管理 | /etc + 点在 config → 形式・権限バラバラ | Registry 巨大モノリス → 腐敗 | アトミックではない変更が多発 |
開発プロセス | メーリングリスト文化でレビューボトルネック | 閉鎖的で古いコード維持不可避 | 純粋なモジュール性が欠如 |
マイクロカーネル(あるいは hybrid microkernel)+ ユーザー空間ドライバ。
カーネル定義の “secure capability” ハンドルのみを他プロセスへ授与。
seL4 や Fuchsia の Zircon が示す「検証可能サイズ」を目標に。
観点 | デメリット | 旧 OS が採用しなかった背景 |
---|---|---|
性能 | コンテキストスイッチと IPC が頻発し、90 年代 CPU では大きなオーバーヘッド。 | ハードウェア性能が不足し、リアルタイム性やスループットを優先した結果、モノリシック構造に。 |
実装コスト | OS サービスが分散し、デバッグやトレーシングが煩雑。 | 完全分離を行うツールチェーン/デバッガが未成熟だった。 |
ドライバ移植 | ユーザー空間化で ABI は安定するが、低レイテンシ要求デバイス(GPU など)の処理が難しい。 | 当時は “音声が途切れる” 程度でも市場競争力を失うためカーネル内に残す決断。 |
Rust や Zig のような safe systems 言語。
C 部分は必要最低限に隔離し、unsafe 領域は形式検証 / fuzz 前提。
デメリット | 背景 |
---|---|
ランタイム負荷 言語ランタイムを最小に削る必要があり、一部 unsafe が不可避。 | 70〜90 年代は C 以外に bare-metal 向け安全言語が事実上存在せず。 |
コンパイラ信頼性 コンパイラ自身の欠陥がカーネル欠陥に直結。 | “自己ホスト” 安全言語を実機に載せる環境が不足。 |
学習コスト OSS/商用エコシステムが C 前提で巨大。 | ドライバサンプル・書籍・人材が C/C++ に集中していた。 |
外部インタフェース(syscall, driver ABI)は長期安定。
その裏で内部サービスは gRPC/FlatBuffers 相当の IDL で世代管理し交換可能。
デメリット | 背景 |
---|---|
進化速度の拘束 ユーザ空間から見える syscall を変えにくい。 | MS-DOS 互換・Unix 互換という既存ソフト資産が最重視された。 |
バイナリサイズ肥大 旧世代 ABI を残すため “脂肪” がたまる。 | ストレージ単価が高く「後方互換より容量削減」が優先された時期が長い。 |
アプリは原則 container-like sandbox(Wasmtime, OCI など)で実行。
ファイルシステムは per-app の仮想 Namespaces、権限委譲は capability passing。
デメリット | 背景 |
---|---|
複雑な権限委譲 ファイルダイアログすら Capability 伝搬を要し、開発者負担。 | “単一 PC=単一ユーザー” が前提で、砂箱の必要性が薄かった。 |
互換レイヤ 既存ネイティブアプリを仮想化するとパフォーマンス低下。 | RoM の小規模ゲームですら速度が死活問題だった 80~90 年代。 |
A/B partition や OSTree 型 “全イメージ” 交換。
任意時点へ atomic rollback;カーネル更新も Live-patchable。
デメリット | 背景 |
---|---|
ストレージ消費 OS イメージを常時二重に保持。組み込みでは致命的。 | HDD が高価・遅い、SSD がない時代には非現実的。 |
アップデート粒度 小パッチ配布より帯域を食う。 | ダイヤルアップ回線や CD リリースが主流で “差分パッチ” が合理的だった。 |
systemd-や Kubernetes-風の “状態 = 宣言” を1か所に。
デメリット | 背景 |
---|---|
学習曲線 既存の `vim /etc/xxx.conf` 流儀や regedit から大きく変わる。 | 管理者層が “設定=テキスト or レジストリ” に慣れ切っていた。 |
複雑なマイグレーション 全サービスが同時に対応しないと一貫性が壊れる。 | OSS は分散開発で統一仕様を打ち立てる強権がなかった。 |
ベンダーは署名した “driver capsule” をリリースするだけ。
デメリット | 背景 |
---|---|
パフォーマンス JIT / interpreter を挟むぶんネイティブより遅い。 | 当時 JIT 技術が未成熟で、リアルタイム I/O を捌けなかった。 |
ハード依存 API DMA や割込みの抽象化が難しく、結局 “逃げ” でネイティブ部が残る。 | 旧 OS ではベンダがアセンブリ最適化で差別化していた。 |
ユーザー空間 API は async/await; カーネルはメッセージ転送中心。
NUMA・GPU・FPGA などヘテロ資源を first-class に。
デメリット | 背景 |
---|---|
コード複雑化 async/await で “状態機械” を書けないとデッドロックを誘発。 | 90 年代はシングルコア前提で同期 API が単純・高速だった。 |
デバッグ困難 スタックトレースが非同期に飛び、ツールチェーンが未整備。 | OS デバッガ/プロファイラがプリエンプティブスレッド中心に設計されていた。 |
Capability + Labels (MAC) + Hardware root-of-trust (TPM, DICE) を統合。
デメリット | 背景 |
---|---|
ポリシー設計負担 SELinux でも “設定が難し過ぎて結局無効化” が多発。 | 当時はネット接続率が低く、ローカル攻撃ベクトルのリスク認識が薄かった。 |
互換問題 古いアプリが過剰特権を要求し、制御を有効にすると動かない。 | 商用ソフト対応を優先し無効化せざるを得なかった。 |
すべての公式バイナリは reproducible build エビデンスと SBOM 付与。
脆弱性スキャンと revocation を OS レイヤが自動化。
デメリット | 背景 |
---|---|
ビルドパイプライン整備コスト 全パッケージを byte-identical に再現するにはツール統制が必要。 | オープンソース文化自体が黎明期で、ビルド環境を標準化する動機も手段も希薄。 |
秘密ロジック公開の葛藤 一部ベンダはソースハッシュ公開を嫌がる。 | IP 保護が優先され、署名のみ・SBOM なしがデファクトだった。 |
User Apps (Wasm / OCI Sandboxes) ------------------------------------- │ Capabilities ▼ Services ──▶ Driver Svcs(user-space) (Pkg, GUI, FS) ------------------------------------- │ syscalls = message send / recv (stable ABI) ▼ Microkernel ~100 kLoC, memory-safe (sched, vm) ------------------------------------- │ Secure IPC (SMC / VTL) ▼ Hypervisor(optional, for legacy guests / composable sandboxes)
Legacy Compatibility は Type-2 ハイパーバイザで提供し、歴史的 API を隔離。
UI Stack もユーザー空間サービスとしてホットリロード可。
Policy Engine で JSON/YAML 宣言→バイトコードへ compile、ランタイム適用。
教訓 | 新 OS プロジェクトでの対策 |
---|---|
Linux: 大規模パッチはレビューパンクする | GitHub PR + 公式 LTS gatekeeper、CLA & コーディング規約を機械検証 |
Windows: Close-source で内部知識が属人化 | 100% open-design、Spec⇄Impl 双方向ドキュメント、自動生成 |
両者: “一社主導 vs 実質無政府” の二極端 | 財団モデル (Rust, Cloud Native) で技術運営と商用版の両輪 |
これらを先天的に組み込むことで、Linux/Windows が数十年かけて抱えた技術的負債(巨大特権領域・ABI拘束・設定の散逸・更新の非原子性 etc.)を回避しながら、クラウド・エッジ・IoT・AI アクセラレータ が混在する 2020-30年代以降の計算環境に即した OS が実現できます。
国家プロジェクトれべるだわ
この数年で、「コンサル」って肩書に対して、かなり不信感を持つようになった。
会って話してるときは、それっぽい言葉をそれっぽい声で言うから、なんとなく知的な雰囲気もあって「おお……?」となるんだけど、
実際に一緒に仕事をしてみると、びっくりするくらい何もしない。
じゃあ何をしてるのかというと、「ユーザーに寄り添った体験を作っていきましょう」とか抽象的な発言を繰り返して、なぜか最初から「答えだけ」は決まっている。
たとえば、「業務アプリに〇〇を導入しましょう」とか言うんだけど、その理由はない。
いや、たぶん本人の中にはあるのかもしれないけど、それを言語化して誰かに説明しようという意思はまったく見えない。
聞いても煙に巻かれるだけだし、結局「アプリUIは大事」みたいな話にしかならない。
そういう“答えありきの進行”を繰り返していると、当然ながら現場は混乱する。
こちらとしては、クライアントの要望を整理して、実現可能な設計に落とし込んでいくプロセスを一緒に作っていきたいんだけど、彼らはそこに一切関わってこない。
むしろ、要望が歪んだまま彼らのフィルターを通って伝わってくるから、最初からズレた設計図を手渡される感じになる。
そして後になってクライアントが懸念を示し「そもそも違ったかも〜」となるんだけど、そこで責任を取るわけでもないし、「あとよろ」みたいなテンションで流される。
たぶん彼らは、自分たちの持っている結論をクライアントに割り当てることが仕事だと思ってる。
「解決する」んじゃなくて、「自分たちが持ってるサービスをとりあえず当てはめる」のが目的とでもいうか。
それって、本来の課題と噛み合ってなければ機能しないし、誰も幸せにならない。
実際、要件定義の見直しが案件後半で発生して、残り少ない期間での突貫修正になった。結果として、誰も望んでいない業務用アプリが完成した。
いったいあれは何だったんだろう。
クライアントの意図は歪められ、制作側の時間と労力は削られ、成果物のクオリティは下がり、関わった人の満足度は限りなくゼロに近い。
正直言って、そこまで期待してたわけではなかったんだよな。
まあ水星も良かったし、ガンダムだし盛り上がるよなって。普通に構えてたよ。
ファーストのパラレルやるってなった時も、庵野秀明脚本だからなァ〜そういう仕掛けでやりますか〜ハイハイって思ってた。
全然心配してなかったんだよね。脚本家として、そのぐらいの厚い設定まとめる力はあると思うから。
案の定、というかなんというか、実際にアニメ始まったらいい感じのキャラ出てきて二次創作がバンバン盛り上がってるし、ガンダムらしい酷薄さもあって、
もう大ヒットですねという感じになってるよね。俺もザクのデザインとかすごい気に入ったし、ジムがゲルググっつって出てきたのはすごい笑ったわ。
とはいえ水星の魔女とか鉄血のオルフェンズぐらいの「良い作品」でしかないと思ってたわけ。
異質感はあるけど、それはファーストのパラレルであることによるものだろうってね。
しかし、ここで流れが変わってきた。そう、例の鶴巻和哉が仕込んだと思われる数々のアイドルネタが入ってきたこと。
ジークアクス騒動まとめ https://anond.hatelabo.jp/20250517001611
ジークアクスのあれは鶴巻なりに爪痕を残そうとした結果 https://anond.hatelabo.jp/20250517103302
オメガサイコミュ=監督の好き嫌いなんじゃないかな https://anond.hatelabo.jp/20250517122841
ガンダムのコックピットが手をつなぐUIになっているのも握手会だし、乃木坂とは握手したいですがHKTや男とは握手したくないですという表れだよね。
あー、ニャアンが急に下着姿になってニャアンとマチュが下着姿でガンダムにぴったり身を寄せて寝そべる展開、元々意味がわからない唐突な展開だったけどガンダム=…って思うとそういうことなのか。
ジークアクス https://anond.hatelabo.jp/20250517142105
一年戦争の終戦日は0080/01/01でアバオアクーでの戦いは紅白真っ最中なんだよな
こういう偏執狂的な情熱が、マスターピースと呼べる作品には必要なんだと、俺は常々思っているんだよ。
トトロ、AKIRA、エヴァ、攻殻、そしてガンダム。本物の「作品」には、いずれも狂気のような情熱が作品に込められている。アニメーション表現そのものであったり戦争に向かう人間の物語であったり、その対象はさまざまだったと思うが、そこにはいずれも作家たちのREALが込められている。
おっしゃる通りです。その通りすぎて、現場でもよく問題になります。
子供向け教材のIT化(デジタル教材化)におけるゲーミフィケーションの本質は、「遊びの感覚で自然に学習を促すこと」です。
そこにゲームとしての完成度や没入感が伴っていないと、単に「UIがうるさい」「操作がめんどくさい」「意味のないポイント制度」みたいなクソゲー感が出てしまい、逆効果になるんですよね。
特にゲーミフィケーション=飾り付けと誤解されることが多いですが、実際は行動心理に基づいた設計こそが価値の核心です。つまり、
子供が「もう1問だけやろう」と思える設計か?が重要で、ゲームとしての体験がチープだと、「勉強なのに遊びっぽくてつまらない」という最悪なバランスになります。
もし教育系のプロジェクトや企画の中でこの話題を提起される場があれば、「学習効果のある良ゲーの設計と同じくらいの品質目標が必要」という視点が伝わると、関係者の認識も変わるはずです。
エグザベくんがオメガサイコミュ起動できなくて、マチュとニャアンは簡単に起動できたけど、マチュとニャアンはJKだし乃木坂がモデルだから起動できて、エグザベくんは23歳男性のキャラクターだしモデルが指原莉乃(乃木坂の敵のHKT48、大分出身で銘菓「ざびえる」をディナーイベントで配る)だから起動できないっていう、監督は若い男や乃木坂のライバルが嫌いですよっていう話なんじゃないかな。
ガンダムのコックピットが手をつなぐUIになっているのも握手会だし、乃木坂とは握手したいですがHKTや男とは握手したくないですという表れだよね。
個人的にはアイドルネタが多すぎることよりも(アイドルネタも十分に気持ち悪くて萎えるんだけど)、今更小保方・佐村河内ネタをやるほうが寒すぎて完膚なきまでに萎えてる。
追記:
あー、ニャアンが急に下着姿になってニャアンとマチュが下着姿でガンダムにぴったり身を寄せて寝そべる展開、元々意味がわからない唐突な展開だったけどガンダム=…って思うとそういうことなのか。
はてな匿名ダイアリー(通称「増田」)は、匿名で自由に日記や意見を投稿できるプラットフォームとして、2006年から続く独特な存在です。以下に、私の考えを簡潔にまとめます。
### 良い点
### 気になる点
### 総評
はてな匿名ダイアリーは、ネットの片隅で「なんでもあり」の仮面舞踏会を続けている、貴重な空間。自由さとカオスさが共存するからこそ、面白い話も問題も生まれる。たまに覗くと、世の中の生々しい断面が見えるけど、投稿の真偽を見極めるリテラシーは必要。あなたはどういう投稿に惹かれる? 何か好きな「増田」記事があれば教えてほしいな。
できないなんてことないだろ。やろうとしないだけ。
一昔前のやたら複雑で色々やらせる札束カードバトルなソシャゲと違って、今のスマホゲームはゲーム的にまともになった分だけ、ある程度要素も洗練されてわかりやすくなってるから、致命的なレベルのコンピュータ音痴でもなければ中卒の人間だってスムーズに遊ぶことはできる。
そもそも、ウィザードリィシリーズはPCやコンシューマ向けに珠玉の名作が多数存在する。たとえば「ウィザードリィ外伝」、「BUSIN」、「狂王の試練場」など、名作揃いの正統派RPGが今なお評価されている。
PSストアやSTEAMを探せばフォロワー的な作品だっていくらでも見つかるわけで、高品質な3Dダンジョン体験はいくらでも再現できるのだ。なぜ、それを差し置いて、課金とガチャで引き延ばされたスマホゲーに時間を費やす必要があるのか?
お前は目先の「基本無料」とちょっと可愛いキャラにつられて時間を溝に捨てているだけだ。
実際にプレイした人のレビューを見れば一目瞭然だが、頻繁なバグ・フリーズ・UIのもたつきといった問題がいくらでも目に付く。アップデートによってある程度改善された部分もあるが、それはあくまで「最低限の修正」にすぎない。
頻度が減ったところで「バグらないかな……」とビクビク怯えながらゲームをやることになる時点で終わっていると言わざるを得ないだろ。
スマホゲーの利点は
・短時間で遊べる
・気軽に中断・再開できる
・指一本で完結する操作性
・ちょっとした油断で壊滅
これ、本当にスマホでやるべきなのか?
「時間も頭も使わせるタイプのゲーム」をスマホでやること自体がミスマッチだという意見も無視できない。
でもダフネにはスタミナがないから……とかいう奴はそもそもの観点が間違えてる。スタミナがないから腰を据えてじっくり遊べるとか言い出すならもうスマホじゃなくてちゃんとしたゲーム機でちゃんとしたゲームやればいいだけだから。スタミナないゆーてもメンタル回復待ちとかいう艦これレベルの縛りを課されている時点でゲーム体験が濁ってるのは間違いないんだよね。
まだまだストーリー的に初期の段階だけど、今の時点で「良心的」「遊びやすい」といった評価がされていることに安心要素なんてそんなあるか?
ソーシャルゲームの宿命として「運営の方針次第で課金圧が急激に高まるリスク」は常につきまとうし、そこに3Dダンジョン系の「終盤で更に加速するイカれた理不尽さ」が重なった時、どんな絶望が待ってるか想像しておいて欲しい。
・ヤバすぎる強敵に対する「特効薬」がガチャレアになる(≒俗称「持ち物検査)
こういった「ソシャゲあるある」が後からじわじわ効いてくる可能性は高い。
WIZのような手間とリスクのあるゲーム性こそ、課金で「時短」や「保険」を売りつけやすい土壌でもある。
今は「良心的」と思っても、数年後に「これは金払わないとやってられん」状態になる未来も十分にあり得る。
攻略情報探したって課金しろ課金しろばかりになるリスクがあるわけで、そんなのもうWIZのあり方として美しくないじゃん?
無課金「ストーリー終盤まで来たけど理不尽すぎてクリア出来ない……どうしたらいいですか?」
課金者「それ、課金したら解決するよ?どうせお前無課金だから◯◯も◯◯も持ってないだろ?それじゃ無理だよ。迷宮を舐めるな」
無課金「俺は課金したからクリア出来たとか思いたくないんだよ」
課金者「課金せずにクリアしたいとか、試食コーナーで腹いっぱい食べたいでしかないからね。お前がアホ」
課金者「それは課金が少なすぎるだけ。何年も楽しませてもらって今更ちょっと月パス買うだけで済ませようみたいな発想が乞食なんだよね」
俺は嫌だよ。だから俺はSTEAMで旧作を買うことをオススメするわけ。まあぶっちゃけ旧作よりフォロワー系の名作を色々探してその中からあう奴を探すべきだな。萌え萌えキャラとダンジョン潜りたいって需要を満たせるゲームも沢山あるしな。