「UX」を含む日記 RSS

はてなキーワード: UXとは

2017-12-04

増田にも

気まぐれでIDが表示されるような、低コストかつスリリングUXを実現するアイデア実装が求められている。

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

anond:20171129031452

しかしたら「マークアップエンジニア」と名乗ったほうがいいかもしれない。

あとアクセシビリティUXハニカムの1構造に含まれるしYahoo!とかの大きい企業でも見直しがされてるから「WAI-ARIAやれる」ってのは強く推して行ってもいいんじゃないだろうか。苦手なことで悩むよりも得意分野を強みにしてどう活かすか考えていくのがあなたにとって一番良いはず。

ニコニコ(く)でニコ生は死んだ

1.ニコニコ(く)がニコ生崩壊の引き金を引いた

有料会員は、2017年11月に発表したデータによると、前年同期の256万人から28万人減少。

まるで、シャッター街と化した賑わいをなくした商店街のように、客と店が閑散とし、それが負のスパイラルとなって更に客と店が逃げていくような状況に陥っている。

思い返してみれば、2009年から2013年頃は配信者も、リスナーも勢いがあり、ニコ生には熱があった。

しかし、その熱は徐々に失われ、人々の感情を動かす熱情は冷めつつある。

もちろん、一部例外はある。七原くんや、加藤純一のように、未だニコ生を楽しんで盛り上げている人もいる。ここで指摘しているのは、サイト全体の空気感の話だ。

しかし現状は、Twitterを眺めても、ニコ生を愛し、毎日のように生主話題で埋め尽くしていた重度のニコ生愛好者のアカウントの多くが、ニコ生のことをつぶやくのをやめてしまっている。自分が2年前に作った、情報収集用のヘビーリスナーを放り込んだリストの3~4割が休止状態だ。

先の見えない、絶望感漂う現状に、ニコ生にしがみついている(過去の盛り上がりを忘れられない)人々は、再びニコ生の隆盛を、最後希望ニコニコ(く)に託していた。

しかし、期待はやっぱりと言うべきか裏切られた。

この発表で、乾坤一擲、人々の希望を与えられるような内容があれば、まだニコ生は数年持ったかもしれない。だが、ニコニコ(く)の発表内容は、サーバーが重い、閲覧がプツプツ止まる、とにかく見づらいという、一番利用者が望み、改善を期待していたところすら手がつかず、子供だましのようなお茶を濁した機能追加のオンパレードで、我々利用者最後希望を打ち砕いた。

もう、ニコ生に期待することはないと思うので、その死に水を取るキモチで、ニコ生が衰退した原因を考察しつつ、何故ニコニコ(く)がダメなのかを書いていきたい。

2.ニコ生衰退の原因

ニコ生が衰退した原因は、一体何だったのだろうか?

そう問われた時、その人の立場により、多様な回答が出てくると思われる。

外部サイトの隆盛、稚拙運営、逃げた配信者、通報厨、リスナーの変化、支援者…。

それらは、複合的に絡み合い、単純ではない。これらを少しでも払拭するような内容であったならと、慚愧に堪えない

(1)環境の変化
外部サイトの隆盛

2013年頃までは、競合サイト比較してニコ生の優位点が多く、ニコ生1強の時代が4年ほど続いていたように思える。石川典行渋谷キングなどの有力な荒らし配信者(当時)を外部に放逐しても、隆盛を保っていた。しかし、現状は違う。YouTubeLiveLINE LiveInstagram Storiesなどの、巨大SNSを基盤とした巨大な競合サイトの台頭が顕著になり、その他独立系ツイキャス、ふわっち、showroom、OPENRECなどがニコ生の牙城を日々切り崩し、今や見る影もない。マクロミル2017年7月に行った調査によると、これから配信をはじめる10代の視聴しているライブ配信サービストップはYouTubeLive、2位がニコニコ生放送配信しているトップInstagram Storiesで、ニコ生ツイキャスYouTube LiveInstagramLiveなどの後塵を拝し、LINE Liveと同率の6位となっている。

実感としても、配信者やリスナーの外部流出が著しく、1強を誇っていた数年前と比べるべくもなく、シャッター街となった商店街様相を呈しており、寂れた印象を与えている。外部に人が流出した上で、新規が競合サイトに吸われたため、サイトとしての熱や勢いを失ってしまったのだ。

スマホ利用者の急増

ニコ生の弱点として、よく上がるのが「スマホ対応の不備」だ。

若年層のインターネット利用の主流がスマホに移りつつあった2013年から、競合サイトであるツイキャスはそのニーズを捉え、低帯域でも閲覧が可能な高性能なスマホ閲覧アプリ提供していた。一方で、ニコ生は未だにバックグラウンド再生もできず、低帯域での再生は断続的な切断によるストレスが多く、基本機能であるアンケートにも参加できないなどのチープなスマホ対応しか行ってこなかった。

利用者の利用環境の変化に対応できなかったことにより、より使いやすツイキャスなどの競合サイト新規ユーザー獲得負けてしまった。

利用者層の変化

ニコ生サービス開始2009年から8年。8年という歳月は、中学1年生が成人するほどの環境の変化をもたらす。

配信者、リスナーともにライフスタイルの変化により、閲覧を辞めることもあるだろう。

それに加え、ライブ配信自体認知が広がり、よりライト層が閲覧を始めたことにより、2ch文化を引き継いだ、垢抜けないニコ生ギーク感(おたくっぽさ)は忌避され、よりスマートツイキャスLINE LiveInstagramなどに流れていった。(ここは、他サイト利用者意見を拾ったわけではないので、根拠に薄く、想像が含まれる。異論があれば教えて欲しい)

ニコ生時代に取り残されてしまったのだ。

(2)運営ドワンゴ
システム改善不備

ニコ生システムは今年実装された「新配信」になるまで、ここ5年ほど、ほとんど改善が加えられていない。

それは、無計画増改築を繰り返した上、低待遇技術者が大量に退職した結果、システム改修がほぼできなくなってしまたことに起因する。

 参考URLhttp://hiroki-uemura.hateblo.jp/entry/2015/09/01/230611

結果、超会議や町会議などの「イベント」を繰り返すことにより、利用者の不満をかわす方針を取ったドワンゴ。不満は見事抑えられたが、上記の外部環境の変化についていけず、緩やかに競争力を失っていった。

しかし、ツイキャスの台頭に危機感を覚えたドワンゴは、ツイキャスパクリのような「ニコキャス」をローンチするも、あまりのできの悪さに3日で閉鎖に追い込まれしまった。

それから2年、2017年システムの大幅な刷新を予告しているが、大幅な後手に回ってしまった感が否めない。

加えて、マネタイズ収益化)が競合よりも上手くいっていたことが、結果的に変化に対応するリスクを取ることができなくなったという面も考えられる。

ニコ生では、リスナーが「広告」を打つことにより、配信時間を延長できるチケット配信者にプレゼントできるシステムがある。これ、運営収益を上げることができ、配信者は延長料500円を払わずに延長でき、リスナーは目立つ形で広告を売って、配信者に名前を覚えてもらったり感謝してもらえるなど、「三方良し」の理想的システムだった。

しかし、競合サイト投げ銭システム一般的となった今、一部配信者は「自分の懐に入らない投げ銭広告)」に不満を感じ、上記Win-Win構造が崩れてしまっている。

技術的な問題と、成功体験による現状維持が原因となり、外部環境の変化に対応できず、ずるずると現状を維持し続けたことで、結果的競争力を失ってしまった。

サイト操作性(UI)とユーザー体験UX)が最悪

ニコ生は、同時閲覧数がある一定数を超えると「満員」状態になって配信をみることができなくなる。

それはシステム上の問題なのだが、ここで「プレミアム会員なら優先入場!」的なボタンが出てきて、プレミアム会員への入会が促される。渋々入会して「優先入場」ボタンを押すも、画面が1瞬切り替わって同じ画面に戻される。プレミアム会員にはいっても入場できない状態が続いているのに「こちらが入り口です」と入れない入り口への誘導が繰り返される。このような、利用者視点がまったくない操作性の悪さがサイト内に山ほど散見され、利用者ストレスを与える作りになっている。ストレスを抱えた利用者は、このような稚拙サイトを再度利用したいと思うだろうか?ユーザー体験UX)が全く配慮されていないのだ。

新規配信者のケア不足

ニコ生トップページをみると、他サイトと大きく違う点が1つある。

それは、他の配信サイトの多くが、盛り上がっている配信や、新規配信者をトップページで紹介しているのに対し、ニコ生企業配信の紹介が大きく割かれているのだ。これにより、新規配信者が配信をはじめても、ふらっと立ち寄るリスナーの数が減り、いつまで経っても過疎から脱せない停滞感が生まれる。

過去においては、ある程度の閲覧数を稼げば、ちくらん上位に掲載されてリスナーを獲得することが出来たり、ミラー大手のこざまミラー新規配信者を「発掘」してリスナーを獲得する機会があった。

また、ランダムでいろいろな配信を見せる「ニコ生クルーズ」や、配信者のコンテスト「ナマケット」などで配信者が発掘されることもあったが、今や殆ど機能していない。

現状においては、新規リスナーがただでさえ減っているのにもかかわらず、初見が最も訪れやすニコ生トップページ企業配信大手チャンネル配信に埋め尽くされ、過疎配信者は日の目を見ることもなく、ただ根絶されていっている。

ビジョンの欠如

ニコニコサービス追加は、これまで良い意味でも悪い意味でも、ノリと思いつきで行われてきた。

既になくなった機能ニコる」然り、マストドンの追加然り。

スタンプなど、ユーザーモチベーション維持に役立ったものもあったが、これらの機能追加は、裏を返すとシステムの複雑化を招き、システム改善難易度を高めていった。ニコニコ(く)において、ニコ生ニコキャスが並行して運用されるのも、複雑化した現状を整理できなかった苦肉の策だろう。

しかし、それらを今回の改定で、整理し、川上社長は、あるべきコミュニケーション像を、ビジョン提示すべきだった。

それらのビジョンなく、枝葉のどうでもいい機能追加に終始し、抜本的な根治を目指さなかったことが、今回のニコニコ(く)の失敗だと思う。

(3)配信

配信者の離脱マンネリ化も、ニコ生の衰退の一因であろう。

新規配信者の参入が困難な現状も相まって、リスナー大手配信者に固定化し、一部の大手はその座にあぐらをかいて惰性で続けている。それは、いつまでも「安泰」な地位約束されている、新規が伸びてきにくい環境からこそ、古参大手既得権益が守られ、切磋琢磨が生まれにくい環境にある為だ。

しかし、ニコ生全体の熱が失われた今、先を考えている配信者の多くはニコ生に見切りをつけ、配信環境が整い、収入源としても有望な競合サイトに流れていっている。

(4)リスナー

配信者だけでなく、リスナーも惰性で続けている人が多い。

惰性で配信を見続けると、様々な弊害が出てくる。

過去と同じことを見ていても、再放送のような気分になり、楽しみを見いだせなくなる。

しかし、配信を一度見るのを辞めると、「流れ」がわからなくなり、取り残されたキモチになる。

結果、面白くもないのに、飽きた配信者の配信をずっと閲覧することもなり、不満を抱えながら配信を見続ける。その中の歪んだリスナーは、楽しみを通報などの妨害行為に見出すようになったり、特定をして配信者を潰すなどの犯罪スレスレ好意に手を染めるものも居る。

リスナー流動性がある程度あれば、このような弊害は生まれにくいが、リスナー固定化された環境下では、このような現状になってしまうのも自明の理かもしれない。

3.ニコニコ(く)を「失敗」と断じる理由

これは簡単な話だ。

上記で掲げられた課題殆どこなすことができず、既存利用者失望を招き、期待感を生むことができなかったことにある。

期待感さえあれば、様々なニュースサイト露出し、SNS拡散され、人々の話題に上がって熱が戻ってくるきっかけになったかもしれない。加えて、一度外に出た配信者やリスナーが「古巣」を見に来ることも会ったかもしれないし、その流れで他サイトリスナーがやってきた「かも」しれない。

しかし、その機会は永遠に失われた。

この先、ニコ生は、数年前にmixi体験した、坂道を転げるようなユーザー離脱が待っている。

2017-11-28

niconicoく、なんでこうなるんだ

ドワンゴめっちゃ技術者育成してるじゃん

ネットに浸かってる人間も多いはずじゃん

なんで需要の見えない方向にサービスを追加する方向に舵を切ってしまうんだ

UX向上したら負けみたいなルールがあるの?訳がわからない

2017-11-23

UXとかデータ分析とかその辺の勉強の仕方

仕事柄、UXとかデータ分析とか、その辺が少し強いと思われているらしい。

職場の人からその辺の勉強の仕方を聞かれたので答えようとしたら、意外と長くなりそうだったのでメモがわりに書く。

これを書いている人のスペック

UX勉強方法とかの話

そもそもUXという言葉流行りだしたのは最近の話だと理解していて、バズワードに近いと思っている。概念自体は遥か昔からあるものだし、何を今更世の中がUXというワードを使いたがっているのかが良くわからない。(が、ここでは面倒くさいので、定義曖昧UXという言葉で色々お茶を濁す

また、UX勉強するという言葉も、正直なところ違和感がある。

というのも、具体的なケースと紐づいて考えない限りは意味がない気がするからだ。文章批評ばかりしていても小説家になれないのと一緒で、UXについて本や講義だけで勉強していても、UXに強くなることはないと思っている。つまり自分たちが作っている(関わっている)サービスの中でUXを考えつくすこと自体が、一番の勉強なんじゃないかと思っているので、UXを本や何かで勉強するというのは効果は薄いんじゃないかと思っている。

はいえ、体系化出来るメタスキル的なものがあるのは事実だし、その部分の話を書いてみる。

UXを良くするって何にきちんと答えられるようになる

UXを良くしたい」という話をよく相談されるのだが、そもそもとして、UXが良くなった後の世界をちゃんと考えられていないことが多い。

「そのサービスを使ってユーザ幸せになるの?」という問いにきちんと答えられない場合黄色信号という印象。

UXUXってバカみたいに唱えている人はたくさんいるけど、自分たちサービスUXが良くなることでこんな世界が実現できるよっていう話を、具体的に、鮮明に、誰が聞いても腹落ちする形で話せる人ってどれだけいるのかな。UXを良くしたいと言っているのに、良くした後の先世界イメージできていなくて、どうやって良くしていくのか甚だ疑問なんだよね。

なので、UXを考えるにあたっては、「自分たちがどうしても叶えたい世界」があって、それが叶うことによって「世の中の誰かがすごく幸せになる」という確信必要条件だと思ってる。なので、そこがない時点でUX改善どころかサービスを作ること自体をやめた方がいい。

もし、そんな感じの祈りにも似た思いが少しでもある場合は、自分たちが作りたい世界についてしっかりと考えて、そしてそれらを検証して確信に変え、具体的な言葉に落とし込むというプロセスを徹底的に行うことを、UX改善の前に行なった方が良い。そうやって生み出された言葉が、UXを考えるにあたっての拠り所になる部分になっていくから

ユーザを観察して想像し、検証する

自分たちが作りたい世界言語化できた後は、ユーザの観察と妄想に尽きる。

課題解決系のサービスなら、ユーザに当たる人が本当に困っているのか、何に困っているのかを見極めるために観察すべきだし、何らかのバリューを付加するサービスなら、「このサービスを使ってもらうことで幸せになるのかという妄想」をいかに具体的にできるかが鍵になる。

これらの観察および、具体的な妄想をしていくこと自体UXを考えることである

炊飯器が目に入ったので炊飯器UXを考えるとした時の例で話す。

多分、こんな妄想をする。

炊飯器とか既に他の製品存在するものは、ユーザの行動もだいたい想像できるし、何より自分が使うものから妄想やすい。

逆に、全く新しいものを作ろうとする時なんかは、妄想も中々大変だと思う。バイアウトして話題CASHとかは、その辺りの参考になるものが中々なく、妄想もやり辛かったと思うので、それを形にできたUXデザイナーの人はすごいなと思う。会ってみたい。

もちろん妄想だけだとダメで、そのあとに検証が入る。

これはかなり適当に書いたが、自分たちが行なった観察に基づく妄想に対して、それらが意味のあるものかどうかを見極めていく必要がある。これがいわゆる価値仮説の検証と呼ばれるもので、妄想が本当に必要とされるものなのかを見極めるフェーズである必要とされないものなんて作っても意味がないから、この段階できちんと仮説の検証をしておく。検証については対象によって全く異なるため、都度考える必要があるので割愛

例はかなり適当に書いたが、ユーザをしっかり観察して、その上でどうやったら幸せになるかを妄想して、それらを検証していくというフェーズを、手抜きせず行うことが大事だ。これが業務系のサービスだと、業務フローを作ったりするのだろうし、C向けサービスだとカスタマージャーニーなんかを作ったりすることになる。その辺りの手法は色々あるが、ユーザを見て、考えて、検証してという基本はどれも変わらない。

観察結果をもとに解決策を生み出す

ユーザをひたすら観察したあとに、初めて解決策を考えるフェーズに移る。

解決策ありきのプロダクトだと(昔の技術先行型の日本家電だけど)、あまりいい感じにはならない。

あくまでも、ユーザの観察が先にあって、それに対する「解」としてプロダクトを作っていく。

この、課題に対して適切な解を出していくこと自体が、UXの磨き込みに当たるという理解をしている。

そして、それらが部分最適にならないよう、全体最適意識しながら解決策を考え、プロダクトに落とし込んでいく。

「ご飯は1分で炊けるけど、風呂釜より大きい炊飯器」とか、誰も必要としないよね。だけど、部分最適だけを考えるとそんなことになりがちである。そのためにも、部分を考えたら、全体を見るということを繰り返し行なっていくことが大切だと感じている。その意味では、捨てるべき部分と、活かすべき部分のバランスをどう取るかが大切になる。ここも結局ユーザが教えてくれるので、事前にしっかり観察できていれば、勝手に答えが出る。

小括

長々と書いたが、自分たちが作るサービスを使ってくれる人たちが、「どうやったら素敵な感じになるかを考え尽くすこと」が最高の勉強方法だと思っている。なので頑張って考えると良いと思う。

はいえ、何を考えればいいかからないということもありそうなので、その時は

・誰のためのデザイン

・複雑さと共に暮らす

・融けるデザイン

あたりを読んでみるのは良いかもしれない。少なくとも、何かを考えるにあたっての視野は広がるような気がする。

また、解決策を生み出していくにあたっては、ロジカルシンキングが出来るに越したことはないので、

・考える技術・書く技術

ライト、ついてますか

あたりを読んで見るのも良いかもしれない。後者は分類的にはロジカルシンキングの本ではないのだが、ロジカルに考えた時の解決策って一つだけじゃないよねということを身を以て知るためには良い本だと思う。

また、散々書いたが、UX云々の前に、自分たちが作っているサービス(だったり、炊飯器だったり椅子だったり)で「何を届けたいか」という部分が一番大事だと思う。それ抜きにはUXがどうとか議論するのは無駄というか、意味がないので、しっかり考え抜いてほしい。

データ分析勉強方法とかの話

なんかめっちゃ長くなったが、続いてデータ分析の話を書く。

データ分析というと、Pythonごにょごにょやるのがそれだと思われがちだが、一部のデータサイエンティストを除いては、基本的スプレッドシートで十分なんじゃないかと思っている。むしろ電卓レベルでも足りるんじゃないかという気がしている。(ここで話しているのは一般的インターネットサービス運営していくときの話で、気象予報とか経済予測とかそんな感じの難しいデータ分析の話ではない)

というのも、多くの場合において、四則演算以上のことをしなくてもなんとかなるからだ。

どちらかといえば

といったことの方が大事だし、そもそも「何のために分析するか」が抜け落ちていることが多い。

whyの部分が明確でない分析そもそも意味がないので、まずはなぜ分析するのかを考えるところから始める方が良い。

データ分析ときいて「統計学」や「Python」を勉強すること自体は悪くないのだが、それよりもまず先に、「なぜ分析するのか」「どんなデータ自分たちサービスキモになるのか」といった分析の前提になる部分をまずはしっかり見極めることの方が、統計学勉強よりも優先されるべきだ。それらがハッキリすれば、手法はいくらでもあるし、だいたいはスプレッドシート関数でなんとかなるので、難しい計算特に必要ない。

実務でよく使うデータなんて、売上、利益利益率、ARPUCPACTRCVCVRとかくらいだし、これら全て四則演算のみで出せる。分析といっても、平均だったりそれらをユーザ属性で割り振ったりするだけだし、中学生でも問題なく出来ると思う。ただ、重ね重ねになるが、whyの部分がない場合はいくら分析しても何も生まないので、まずはそこを見極めることに重点をおいた方が良い。

まとめ

長くなったので無理やりまとめる。

勉強<<<<<実務であることは間違いないので、まずは自分が関わっているサービスについて真剣に考えたり、真剣に考える上で必要数字が何かを自分の頭で考えることが、最高の勉強だと思う。教材とか、具体的なHowを期待していた人、ごめんなさい。でも、Howの意味で見ても、実践に勝るものはないと思っている。

2017-11-12

ニジエでは抜けない

広告多すぎ。広告サイドバータグ欄とかの無駄なスペースのせいで画像が下の方に見切れちゃってる。

・そのせいでページ移動するたびに下にスクロールする必要があって冷静になる(せっかくカーソルキーでページ移動できるのに・・・

・そんな中で性癖に合う絵を見つけても、広告の直球エロノイズになってうざい。

エロサイトとしてはPixivのほうが遥かにマシ。

広告の配置とかUXとかもっと改善したほうがいい。アダルトサイトの中でも最底辺だと思う。

2017-11-04

anond:20171104221557

> 突出したものがない人間だと劣化になりかねない。

やはりそうですよね…

仮にUI/UXに関する論文執筆経験がある,としたらそれは果たして「突出したもの」といえるのだろうか…

> しかしそういうポジションはあるにはある

そういったポジションって一般にはどんな役職名なのだろう…

> 他人に任せるとその中で一番人が足りていない部署に回される便利屋になりかねないぞ。

実は,現在いる学校でもそういう立ち位置になっていて困っている.

デザイナーエンジニアの間をもつ役割職種ってあるの?

来年からIT企業Webサービスやらスマホアプリゲームなどを提供)に就職する予定で,エンジニアとして内定をもらいました.

もちろんスキルセットとしてはエンジニアリング的なものサーバサイドからフロントエンドまで)は持っているが,UI/UXを見たり考えたりすることが好きで,

コーディングをするよりもそちらのほうがすきだという側面もある.

実際,ウェブサイトUXに関する論文を書いたりもしている.

そこで,来年から自分がどのようなエンジニアとして生きていくのかが不安になっている.

エンジニアリングは「できる」が,何か突出しているわけではない.

そして,興味はデザイナ寄り.しかし,デザインを専門としているわけではない.

そんな俺はどんな職種に就くんだろうか….

どんな職があるかとか,職種サジェストをしてくれると超嬉しいです.

2017-10-20

UIとかUXって言葉

「それUI(UX)言いたいだけやろ」が多くて辟易する。分かって使ってる人どんだけいるんだ。

2017-09-18

anond:20170507200847

ネットサーフしててmizchiのブログ読んでたらRPG作っててダメージエフェクトない以外は良いじゃんという感じだった

https://mizchi-sandbox.github.io/rpg-prototype/

つかqiitaフロントエンド作ったんだ。qiita記法UX微妙だけどへーすげーじゃんって感じ

2017-09-12

https://anond.hatelabo.jp/20170910184746

元増田だがどんだけ伸ばしてんだw

UIじゃなくUXって書けばよかった

エンジニアは優秀だけどデザイン台無しにしている

技術集団イメージあるけど、サービスがまじでイケてないって会社って結構あるよね。

バックエンドエンジニアが優秀でレスポンスがめちゃくちゃ速くたって、デザインが全てを台無しにするような。

インフラエンジニアが超高負荷に耐えうる環境を構築したところで、ユーザーからすれば知るところではない。

そんなことより、目の前のサービス大事なんだよ。

すなわち使いやすさだ。

楽天

楽天ってエンジニアは優秀な人がたくさん集まっているイメージがある。

でもあの楽天サイトの見栄えの悪さとデザインの酷さ。

絶対エンジニアデザインしてるだろ?

リクルート

リクルートもいろんなサービス持ってるし、エンジニアガチで優秀だ。

でもあのリクルート発のサービスUI/UXの糞っぷり。

クリックで済ませるべきところを7クリックくらい要求される導線、すさまじいユーザー経験だわ。

ヤフー

もうなんかCSSは微塵も使っていないかのような初代HTMLデザイン系。

昭和時代インターネットなんてなかったのは当然理解しているけど、昭和臭すら感じる。


あ、なんかギター侍って消えた芸人を思い出した。

2017-08-31

https://anond.hatelabo.jp/20170831140153

ネタの方に醤油をつけるべきだって主張は俺も聞いたことあるけど

それなのにネタが上に載ってるってことはやっぱ寿司ってUXデザインの時点で問題があるんじゃないの?

2017-08-13

グーグル思想残響室(Google’s Ideological Echo Chamber和訳) 後編

提案

私は多様性が悪いとか、グーグル社会100%公正であるとか、既存バイアス修正されるべきでないとか、あるいはマイノリティマジョリティと同じ経験をしているなどと私が言っていないことは明らかであると願う。私が言いたいのは私たちには特定イデオロギーと一致しない考え方や証拠に対する不寛容があるということだ。私はまた人々を特定ジェンダーロールに縛り付けるべきだとも言っていない。私は全く反対のことを主張している:人々をグループの中の一人(部族主義)としてではなく、個人として扱うことだ。

具体的な提案としては:


----

次で最後

グーグルの思想的残響室(Google’s Ideological Echo Chamber和訳) 脚注

2017-08-05

#builderscon tokyo 2017という体験をしてきた

UXを専門にしているが、これほどなイベントは他に知らなかった。

個人スポンサーの特典無視

恥ずかしながら、buildersconへの理解がなく、特典をみて個人スポンサーへと申し込んでしまった。

しかしながら、行ったところ、個人スポンサー特典で約束されている「別途用意の部屋での充電等が可能」というのはなかった。結局は一般参加者と変わらないし、懇親会まで立ちっぱなしが多いし、充電もできないし、何のために15,000円払ったかよくわからない。

個人スポンサー特典が契約である仮定するなら、全く契約遂行しないという運営にはしびれた。

◯ 会場費は最低単価であるはずなのに経費はどこにいった

私はbuilderscon tokyo 2017に、懇親会のためにいったわけでも、朝食のためにいったわけでもなく、セッションを聞きにいったわけだ。登壇者がコンテンツであり、そのコンテンツを「1. 快適に」「2. 楽しむために」個人スポンサー料金を支払った。

しかしながら、快適に、という部分は、座れる部屋どころか電源がある部屋も案内されなかった。じゃあ、楽しむために、はどうだったかというと、楽しくなかったわけではない。けれど、その登壇者ってゲスト以外は何も支払われていないんでしょ?

簡単に考えて、7,500円と15,000円の間を雑にとって1万円が100人としても100万円。スポンサーの協賛費で100万を切ることはないと思うと最低200万円。

それに対して、カンファレンスで一番お金がかかる部分は「慶應義塾大学大学院メディアデザイン研究科にご協賛いただけることになり」(会場費協賛)でかかったとしても会場費は最低単価なはずなのに200万円はどこに消えた。

そう思うと、懇親会の食事はおいしかった。知りうる限りのカンファレンスで一番おいしかった。フルーツもよかった。

朝食もいろいろでてたし、あれ、ん?ということは、私が受益するはずだった快適さも、コンテンツメーカーであるはずの登壇者にも支払われずに、何となくイベントの格を高めるところに使われたの?

そういえば、何か顔をだして写真撮影するパネルも奥の方にあって、話を聞いたら「このために作った」と言われた。

ん?

主催者ってお金を使い切るために何に使った?

◯ 「知らなかった、を聞く」というコンセプトはどこに

いろいろ聞いたけど、みんな「知らなかった」ってどれぐらいあった?結局はいろいろな分野の登壇者集めてしゃべってもらっただけでコンセプトとかなくない?

スタッフ弁当、今半なの?

スタッフ弁当って、今半の弁当がでたって本当?

別に人件費とるなといわないし、ぜひ日給はとってほしいけど、スタッフって当日そんなに暇だったの?

そんな弁当食べてる時間あるなら、個人スポンサーの特典ちゃんと用意するなりやることあったよね。「すばらしいイベント」をつくりあげるために、スタッフ弁当も懇親会も朝食も最高級のものではないといけないってこと、あるの?

UXから考える

UX時間軸に分けられることが多く、そういう意味では予期的UXはすばらしかった。他のカンファレンスにみられない高額な参加費、ちょっと行きにくい場所、豪華なベストスピーカー賞の用意。すばらしく予期的UXは高かったといっていい。iPhoneを買った時の開封の儀雰囲気は似ている。

けど、実際あけたら、iPhoneどころか、文鎮が入ってた感じしかしなかった。予期的UXが高かったからこそ、「これもだめ」「あれもだめ」というすばらしいUX体験をさせてもらった。

いろいろ書きたかったけど、もう書くのも馬鹿げてるからやめておく。

とりあえず、私は来年いかないし、周りにもやめておけというつもり。箔付けをしたいなら、違うやり方の方がいいと思う。あれはスピーカースポンサーもみんな気の毒だ。

かわいそかわいそ増田

https://anond.hatelabo.jp/20170804223333

パッとみ、同じ人間の主張としては正直いってどっちもどっちだなー、って思う。

どっちが悪いってわけでもなく、「それぞれ流儀哲学もございますよね、生きた人間ですもの」といったところ。

仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

かわいそかわいそ増田

パッとみ、同じ人間の主張としては正直いってどっちもどっちだなー、って思う。

どっちが悪いってわけでもなく、「それぞれ流儀哲学もございますよね、生きた人間ですもの」といったところ。

仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

かわいそかわいそ

人間的には正直いってどっちもどっちだなー、って思う。

まず仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

かわいそかわいそ

人間的には正直いってどっちもどっちだなー、って思う。

ただ、仕事としてみると、PMの職責としては追い出す前に、何度か自分から増田に口頭でコミュニケーションを取りに行くべきなので、PMとしての職責を充分果たしていない点は批判すべきかと思う。

ただ、同じエンジニアとしてみると、PM感性よりも、この増田の「俺は悪くねえ」感あふれるスタンスの方が問題のように感じる。(感情として)

自分は元サーバサイド(データ解析とか)で、今はフロントエンジニア(計測とかUX改善とか)だけど、コードドキュメントベース確認する時はslackを使うし、文章としてトラック必要ものメールかコンフルを使う。

あと、大所帯なんで拠点別奴やフロア別奴とは必然的slackになる。

でも、どっちも必要ないなら口頭でコミュニケーションとった方が話早いと思ってしま人種特に案件意図とか作業の進行度合いの確認

これは、相手の顔色とか反応とか話ぶりを伺ったほうが文章で細かく確認観点を書き出すより効率的情報を得られるし、何より口頭のコミュニケーションのほうが直観的だから

(Web屋としてはより直観的なUXを選ぶべきだろう)

うちはソシャゲじゃないけど、広くWeb業界としてみると、有能なエンジニアより有能なPMのほうが希少なので(増田PMが有能かは別として)、エンジニアPMの求める最低限のコミュニケーション規約に合わせる努力必要だと思う。

あと、新しいチームにいったら規約自分で聞き出して把握するべき。ここばっかりはlint書いて貰える領域じゃないわけだから

今回のPM場合、口頭でおおまかに要望期待値スケジュール感を把握しつつ、FIXさせる必要があるところはメールBacklogで、くらいの温度感コミュニケーションをするべきだった。

これが出来ないとなると、増田のためだけにブリッジSE挟まなきゃいけなくなるわけで、実際新しい上司の元で仕事するってそれに近い状況になってるよね。

こういう1枚挟まなきゃいけないエンジニアって、正直にいって社内に飼っとく必要薄いし、同じ会社昇給しながら働きたいなら今後はやり方考えた方が増田のためだと思うよ。

30超えての自省でもあるけど、「こいつ飼っとく必要ないな」って思われるの、1度目は若気の至りで済むけど、2度目は避けないといけない。

https://anond.hatelabo.jp/20170804223333#tb

2017-08-04

東京海上日動がん保険見積もり

http://www.tmn-anshin.co.jp/kojin/goods_cancer/cancer_r/simulation/

がん保険検討していて、各社の支払いシミュレーションをやってるのだけど、東京海上日動のやつは、こんなの一瞬で計算できるはずなのにわざわざ「計算中」とか表示して2, 3秒またせる意味不明UX

2017-07-23

コンビニ受け取りがウゼエ件について

引き取り番号が13桁に認証番号が8桁も入力させるとかUX最悪だろ。

客としては訳わかんねー数字20桁も入れさせられて間違えたら、またやりなおしとかどうなん?

とっととQRコード対応しろ

2017-06-29

マック楽天も頭つかってないんだな

マック楽天ポイントカード

マックアプリクーポン提示したあと、

レジ前で楽天アプリに切り替えて、

楽天ポイントカードバーコードを見せる動作

設計が明らかにおかしくない?

どっちのアプリもいちいち通信走るゴミアプリから

確実に会計でもたつく。

会計でもたつくと客も店員も気まずい。

一回気まずい思いしたユーザーは確実に楽天ポイントカード提示しないでしょ。

こういうチグハグ販促がうまくいくと思ってるなら、時代遅れもいいとこ。

どっちの会社も、導入前にそういうおかしUXに気付いて改善したりとかしないんだね。

2017-06-27

夢の中でUMIDIGI C NOTEを買った

のでレビューしま

画と音

液晶はわりと綺麗で、妙な画質補正とかをかけている感じはない

スピーカの音はかなりマトモで、妙なDSPとかを通している感じはない

ヘッドフォン端子の音はわりと優秀、あえていうなら解像度は少し低いが、鳴り方にクセがないし、下手なミッドレンジ端末よりよいのでは

ゲーム周り

デレステ3D標準でも描画の処理落ちはない

FGOがだいぶ軽快に動く、FGOバックグラウンドにまわして他のことをいろいろやってもkillされてない、RAM 3GBサイコー

スクフェス普通に動く(普通に動く端末はわりとレア

ガルパがなぜか思い切り処理落ちする

発熱は昨今のSnapdragonより少ない感じ

・6万出しても同時押しが同時に入らないクソ端末だったりするAndroid界隈において、こいつはだいぶ優秀

・でも3つ以上の同時押しは同時には入ってなさげ

微妙なところ

・さすがにカメラ価格相応

・設定項目に微妙和訳されてない部分が残っているw

物理キーはBack/Home/MenuかMenu/Home/Backか選べる、正直バカじゃないのかと思う、なんでRecentじゃなくてMenu置いてあるんだよ

ソフトウェアキーに切り替えれば普通にBack/Home/Recentになる

その他

Android 7.0、セキュリティパッチレベルは2017/04/05

・Antutu v.6.2.7

Total38731
3D5034
UX16301
CPU12655
RAM4741

思い付くまま書いたけど、こういうときって何を書けばいいんですかね

まりにも普通に動く普通に普通の端末で困惑している

2017-06-03

http://anond.hatelabo.jp/20170602180824

pythonWebサーバ側で使われてること知らないのだろうな。

ユーザが使うUX/UIjavascriptだが、バックエンドはすでにpython(根拠なしw)

理由は消去法かな。perlは論外だし、railsは5系を学習しても4系に比べていいことはなく無駄なだけだ。

ついでにrailsrubyじゃない。

python機械学習と相性がいいし、かっちり作るのに向いてるし、可読性が高い。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん