  |
はてなキーワード: uxとは
親にパソコンを買ってくれってねだって買ってくれたPC-98は、
今思うとドン引きしてしまうんだけど、トータル80万円ぐらいだったかな？
で、高校入ってパソコンは使うんだけど家では、ほぼゲームのみ。
その時は流行っていた、ぷよぷよとかファルコムとかアートディンクのゲームに夢中になった。
家でそうやって課題に使ったことも覚えてないぐらい、たぶん使ってない。
要は高校で必要なパソコンの用事は学校で学校のもので事足りたってことで、
わざわざ高価なPC-98なんて買わなくても良かったのでは？と今になって思う。
あと学校と家のパソコンでは互換性が無かったFM-TOWNS。
今でこそ分かるけど
今思うと本当にMSXでも良かったと思う。
もちろんインターネットはそんときなかったし、パソコン通信とかもするわけがなく、
今になって思うと、それ自分の実になって役にたったのかな？と思う、
あと覚えてるのはそのPC-98で
それ以外のまともなUXはなかったから、せいぜいそれらのUIに慣れて触れたぐらい。
あと本当に今思うとなんでそのソフト買ったんだろう？って思うんだけど、
NECの音声合成出力ソフトを2万5000円ぐらいで買ったのは今でも謎。
インストールしてサンプルをしゃべらせて飽きたような気がする。
とにかく今思ったら、
キーボードやマウスとかパソコンを物理的に使いこなせるようになったってスキルしか得られてない。
親もよく買ってくれたなと思うし、
あの時PC-98を買わなくてもMSXで良かったのではと今でも思う。
でもその時MSXを買っていたら今どんな道を歩んでいるのかは知る由もないけど。
とにかく今思うとあのPC-98は自分にとってもったいなかったなーと同時にそれで何をしたかったんだろうって思う。
ただそれだけ。
蓋を開ける工程が増えているだけであり、全く不条理な改変である。
新しい蓋は明け口が2つあるが、これはUX上問題があると思う。
増田としては次の3点が複合的にその使いづらさを生み出すと考える。これらのほかにも要因はあるかもしれないが、十分に説明のつく範囲の項目であろう。
従来の開け口はガイドに対して垂直に開ければよくその動作に非合理性はない。開け口をつまんで真っすぐ引けばよいだけである。
ところが、新デザインにおいては斜め方向となっていて開け口のつまみ部分とガイド左右端の距離が異なるため、微調整が必要となる。
この蓋に不慣れな私のような若輩者の場合、念のためにパッケージに記載される説明に目を通して少しでも事前のミスをなくすように努めることが好ましい。
なるほど蓋には「お好きなタブ(開け口)からはがして、両方でとめる」と丁寧で簡潔な説明がある。
ところが、この指示に従うと1点目に挙げた問題と直交する現象が起きる。
ガイドは2つの開け口の中心から垂線を下した形の位置にのみ存在しているため、「お好きなタブ(開け口)」から開いてしまうと選択しなかった開け口にスムーズな開封を阻害されてしまうのである。
私が不器用なことは否めないが、このために旧パッケージでは起きえなかった蓋の裂傷が起きてしまった。
また、これは結局のところ次両方の開け口から開かねばならないことを意味する。
上記2点を総合したところ、どうやら両方の開け口から慎重にガイドまで開けることを想定したインターフェースであることが分かった。
この時点で明確に食べる準備の手順が増えているのだが、ここで述べたい問題としてはパッケージ変更の主目的の一つである「フタ止め感」である。
カップ麺の蓋不要論も存在するようだがそれは今回の話からは除外するとして、止めるためのトリガーが2点増えたとて特に「前よりも蓋をちゃんと止めているぞ！」とは微塵も思わなかった。
日清は苦心してこのデザインを設計したのであろうが、明確な失敗である。そうでないなら押し付けがましい定性的な改善というものではなく、定量的な効果を示してほしい。
以上、むかついたので書きなぐった
これは控えめに言って最高
DrupalはWPより自由度が高いから、高い技術力のあるベンダーだと運用しやすいと思う
内閣官房IT総合戦略室（IT室）は8月26日、中央省庁の情報を集約した「政府統一Webサイト」の構築に向けた実証事業の受託事業者が決定したと発表した。落札したのは、官公庁を中心にWebシステム開発を手掛けるANNAI（東京都千代田区）で、落札額は7000万円。実証事業では、サイトデザインのルールや基盤作りといった方針を固め、暫定版サイトを12月末までに公開する予定。
落札したANNAIはCMS（コンテンツ管理システム）「Drupal」（ドルーパル）を使ったWebシステム開発を手掛ける。内閣府や東京大学、京都市などのWeb開発に携わった実績を持つという。
ANNAIの受注実績
これまでは各省庁が個別にWebサイトを整備したり、運用したりしていたため、各サイトのUI／UXに一貫性がない上、類似する内容が複数のサイトに散在しているなどの課題があった。このため、政府統一のWebサイトのフォーマットを決め、UI／UXの標準化・統一化を図る。実証期間中にデザイン統一のルールを整備し、9月に発足するデジタル庁の公式Webサイトを使って検証する。統一サイトへの移行時期についてIT室は「各省庁が契約するシステムのライフサイクルなども見ながら、段階的に検討する」としている。
UI／UXの統一化に加え、英国の政府統一サイト「GOV.UK」を参考に、日本政府全体のトップページのようなサイトも構築し、各省庁のサイトをリンク付けすることで、少ない手順で国民が必要な情報を得られる環境も整備する。これまでは一つの情報を得るために、複数の省庁のWebサイトを横断して閲覧しなければならないケースもあったという。数年かけて統一サイトに集約する方針。
総務省が運営し、行政機関へのオンライン申請や法令検索機能などを提供するポータルサイト「e-GOV」とも機能が重複する可能性があることから、政府統一Webサイトとの役割分担などについても今後検討するという。https://www.itmedia.co.jp/news/articles/2108/27/news108.html
富士通がオラクルと組むのは SUN 関連だと思うけど、富岳で SPARC をやめて袂を切ろうとしていて、少しずつ距離間出てきたね。
オラクルと富士通は銀行と役所、あと巨大病院のシステムをクラウド化したいのじゃないかな？ただ、AWS はソニー銀と三菱UFJ銀行が利用しているみたいで、ソニー銀行は Oracle のサービスを AWS で動かすことで、コストダウンしたみたいで満足感あるっぽいよ。
富士通のクラウドは触ったことないけど、UX は酷いみたいね。個人的には AWS と Azure も今ひとつで、GCP のが良いと思っているけど。
単純に触るなら AWS、熱意があるのが GCP、ビジネスがわかっているのは Azure、って印象かな。僕はさくらインターネットに頑張って欲しいけど。
その点でデスクトップLinuxとAndroidは、WindowsやmacOSやiOSと比べてダメすぎ。
まず、デスクトップLinuxとAndroidは、UIをディストリビューターやスマホメーカーがカスタマイズ可能だけど、それがUXの向上に全く寄与していないどころか、質の低さから抜け出せない原因になってるわけで。
せめてどれか1つのUIだけを認めるようにして、そこに開発リソースを集中させろっての。
とはいえUI系のソフトは、未だにLinuxカーネルのようなバザールモデルの大々的成功例がない分野だから、そもそもオープンソースで、プロプライエタリとシェアを二分するほどイケてる代物ができるかどうかすら怪しい。
(強いて言うならChromeと、あとは最近やっとVSCodeが頭角を現してきたくらいで、今なおMS OfficeやAdobe Creativeに対抗するようなオープンソースソフトなんて皆無だし)
あと、うまく動かないときの対処法がディストロやスマホの機種ごとにバラバラなのも、ユーザにとっては苦痛以外の何物でもない。
これもLinuxディストリビューションというものが出来た頃から散々言われているけど全く改善しない。
それどころか、それがそのままAndroidの機種別対応に引き継がれたんだから、その時点でAndroidスマホは価格以外でiPhoneに勝てないエビデンスの1つになってしまった。
どうも最近のテクノロジーの進化が、将来的によくなるという希望につながらない。
少なくとも自分はそう見える。
「機械に仕事を代わりにやってもらう」ということについては、モーターを使った制御にブレイクスルーがない。
機械に合わせて家が作られるかというと、そういう流れもない。
Webはかなり発達したが、コンピュータの進化が引っ張られ過ぎている感がある。
なんでもネットワークで繋がるべきという流行によって、セキュリティアップデートがされなくなった時点で廃棄しなければならなくなった。
セキュリティ対策もかなりの労力が必要となり、サブスクリプションなどで稼がないといけない。
維持費は増加する一方だし、中間マージンをとって稼がないといけない。
日本は人口が多い方だが、その程度では維持できず、グローバルでチャリンチャリンと稼がないといけない。
ネットがもたらすメリットよりデメリットの方が多くなってきたと感じている。
広告は徐々に酷いものを強制的に見せるようになっていっている。
その割に役に立たず、信頼できる人の感想やらなんやらがないと購入につながらない。
自動化は、セキュリティ観点や、仮想通貨マイニングに使われるなどで制限がかかる。
家電がクラウドに接続されるとクラウド側で問題が起こると使えなくなる。
クラウド側が問題があっても、バックアップが働き、家庭内で閉じて維持し続けるというようにはできてない。
端末の種類が増え、その対応が多く、複雑な機能は追加が難しくなっている。
どれでも動くソフトはできたが、単純なことしかできないままだ。
むしろ初心者向けに単純なことしかできないUI/UXの方が推奨される。
学習し、次第に複雑なことが使えるようになるユーザーは置いてけぼりで、人力で解決するしかない。
AIは話題になってからそれなりに経ったが、単純なパソコンでは全く結果が出ない。
行く場所、日時と時間を入力しなければその時間に列車が動いてるのか確認することができない。
「熱海行くかー何時の列車があるんやろーなー」こういう甘い考えを一刀両断するのがJRだ
例え予約をする前だとしても、日程を一度決めたら、変更ができない。
「やっぱ別の日にするかー」こういうやつにその『別の日』が絶対来ないことを知っているJRはそんな甘ちゃんを逃さない。
例え夜間メンテナンスがあろうと、そのことはサイトにも記載しないし、座席を決めて支払い画面の直前まで一切教えない。
社会は理不尽の連続だということをJRは惜しみなく教えてくれる。
夏様最強
俺はITエンジニアをしていて、ベンチャーやSIerなどで自社、顧客企業を問わず今まで多くのWebシステムを作る案件に関わってきた。
プロダクトが上手くいくもいかないも、プロダクトオーナーが全てだ。
特にWebサービスの場合、ビジネスサイド、ITエンジニア、デザイナーという3つの職種がチームを作ってプロダクトを開発していくことになる。
その場合はプロダクトオーナーはビジネスサイドが務め、テックリードがPdM補佐のような形になるだろう。
SIerの場合は、顧客企業の窓口となる人がPOを努め、開発会社のマネージャーがテクノロジーを統括することになる。
そして大抵の場合、ビジネスサイドの人間がPOを務めると、「声のデカいステークホルダー」となり、チームを引っ掻き回し、プロダクトを迷走させ、モチベーションを下げさせるのだ。
だってそうでしょう！？プログラミングも、DBでのデータの持ち方も、他社のAPIの使い方も、UIデザインも、いくつかあるUIの選択肢とそれを実現する工数も、何も分かってないんだから。そんな人間が最終意思決定者をやるんだから、上手くいくはずない。
だいたいMVPにはふさわしくないリッチなUIを要求してきたり、難しい実装や工数のかかる機能を要求してくるのだ。そしてその実装に工数がかかるのは、エンジニアの怠慢、スキル不足だと考えている。
本来であれば、機能の過不足については、ユーザーがやりたいこと、こちらがやらせたいことが実現できているかどうかだけを考えるべきなのだ。それがどういう形のUIで提供されているか。別ページなのか、モーダルなのか。ボタン押下で動作するのか、JavaScriptでインタラクティブな操作ができるようにするのか、ビジネスサイドがこだわり主張するべき所ではない。
そもそもエンジニアは1+1=2になる世界で生きているが、営業というのは顧客を口説いて意思変容させるのがミッションだ。現実を歪めるのが職務なのである。エンジニアはエンジニアの工数は変えられないものだと理解しているが、営業はそれも「なんとかできるはず」と考えてしまうのだ。
仕事には内部に向けるエネルギーと、外部に向けるエネルギーの2つがある。そして、外部に向けるエネルギーをどれだけ大きく出来るかがビジネスの成功に繋がる。
ビジネスサイドの何もシステムの専門知識の無い人間がPOをやると、思いつきで「あれはどうなの」「こうしたらどうなの」って言って、エンジニアやデザイナーという専門家が「それは難しいです。なぜなら技術的に…工数的に…タイミング的に…」という話をして、仕事に使えるエネルギーもモチベーションも時間も、POを説得するという「内部に向けるエネルギー」に消費してしまうことになるのだ。
色んな専門家が集まって、それぞれの専門領域を発揮し、お客様に価値を与えるプロダクトを作り、金を稼ぎたい。だからこの仕事をやっているのに、なんで何も分かってないPOが自分の存在意義を発揮するためのだけのオ◯ニープレイを説得することに毎日忙殺されているんだろう。馬鹿じゃないかしら。
そういうPOを補佐するために有能なPO補佐がいるんですよという話もあるが、どうせ人の話を聞かないんだからPO補佐がいたって意味ないです。
そしてそれができるバランス感覚と説得力を持った有能なPO補佐がいるんだったら、その人がPOをすべきだ。お前じゃない。
過去会ったことのあるPOには、エンジニア出身のダメなやつもいた。この現代において生PHPやStrutsの時代で止まった知識を振りかざし、自分は知識があると勘違いした痛いやつが。もっとも彼は元エンジニアであって、エンジニア辞めた後はかなりの年数を営業としてやっている人間だったが。
だから俺は、POは現役エンジニアがやるべきだと思う。技術オタクのCTOというよりは、VPoEの立場の人がやるのが一番いいかな。顧客を無視したエンジニアリングオ◯ニープレイをしない、ちゃんとカスタマーサクセスとUXへの費用対効果を考えられるエンジニアだ。
そして営業/マーケターはサービスを売りつつ、顧客の声を聞き、顧客の抱えてる課題を発見し、それをチームに伝えてくれたら良い。ソリューションはエンジニアとデザイナーが考えるので。
ある程度会社が大きければ、エンジニアをプロダクト開発のトップに据える、そういう責任移譲もできるだろう。
今日の名言飛び出しました
「プロダクトオーナーがしっかりとしないと、エンジニアがいても能力がある人がいても意味ない」
「ビジネスモデルは考えられるけどプロダクトモデルを考えられない人が増えてきている」#DxMiraiKaigi https://t.co/6VHrh1Ut3z— あれっくす@一番下手っぴでいい (@MHTcode_Alex) May 20, 2021
ベンチャーのあるあるとして、ビジネスモデルは考えられるけどプロダクトモデルを考えられない営業人間が起業して、「俺の考えたビジネスモデルを実現するに協力してくれるエンジニア募集！」とか言ってチームを作り、社長がPOを務めることが多い。
でもその社長に、POとしての職責が果たせるかどうか、スキルがあるかは別な話である。というか大抵の場合、無い。
声のデカいワンマン社長の言うことを聞いて、クソなものをクソだと思いながら作り、社長がVCにプレゼンして調達したお金を啜って生きていくのがベンチャーでのエンジニアライフである。オワリです。
ベンチャーで上手くいくのは、エンジニアでありながら希なプレゼン能力とコミュ力を持った、エンジニア社長がいる会社しか見込みがない。
これを読んでるあなたがもしビジネスサイド出身の社長さんであれば、あなたの仕事はプロダクト開発にズカズカと踏み込んでいって、思いつきで喋って、自分のこだわりを入れるように怒鳴り散らすことではありません。
課題は無いか耳を傾け、解決できそうな人を連れてきて、お金を出すだけに徹するように下さい。
それができないのであれば、あなたはWebシステムという無限の拡張性があるものからお金を得ることはできません。愚直な営業と手作業でバリューを出すという、労働集約型の仕事を一生全うしてください。
そしてこれを読んでるあなたがもしエンジニアであれば、ビジネスサイドにプロダクトの決定権を握られている状況ではエンジニアが幸せになれることは決して無いので、ビジネスの作り方やマーケティングを学んで、エンジニアがビジネスを握っていこう。プログラミングを修得するのに費やした時間と努力をビジネスサイドにも発揮すれば同じように身につけられるはずである。ビジネスサイドに顎で使われる存在から抜け出していこう。
星野リゾートではどのようにして旅館現場出身者をIT人材へ育成したのか？【デブサミ2021】 (1/3)：CodeZine（コードジン） https://codezine.jp/article/detail/14017
これはすごいですね。非エンジニア出身のPOでありながら、ちゃんとプロダクトを成功へ導いている。
ここでの例では2例あって、社内システムと、社外のお客様向けのシステムだ。
社内システムはノーコードを活用して、自分たちで作って自分たちで運用するようにした。いいですね。非エンジニアの思いつきをエンジニアに作らせる、という動きにはなっていない。自分の思いつきのケツはちゃんと自分で拭け、他人に迷惑をかけて対処しようとするな、ということだ。
社外向けのシステムを作るに当たっては、ちゃんと自分たちをIT人材に変化させていくための勉強をちゃんとしている。エンジニアと同じ目線に立って同じレベルで話ができるようになっている。これだといいですね。
やっぱり、Webシステムを作るPOは、営業出身ならめっちゃITのこと勉強すべきだし、それが嫌ならITで金儲けしようということからは降りるべき。
当方、機械学習や深層学習に乗り遅れた（自称）フルスタックエンジニアである。プログラム言語は Java, PHP, Python, Ruby, C, Swift, Kotlin, JS, Rust 何でも好きだ。HTML/CSS や SQL も大好きだ。ところが、計算機科学という領域で次に何が来るかわからないので、増田の集合知に教えてもらいたい。最近のワードは、以下の感じ。
この手の分散型データベースは好きになれない。遅いし。それに、反社会的勢力が暗躍する領域は嫌い。
どうせ、ICT やユビキタスとかと一緒で経産省のオママゴトになるのは見えているので、反吐が出る。
計算機の演算機能が未だに不足しているので、汎用 AI なんて無理なのがわかっているはずだが、何故に人の出入りが激しい。統計的機械学習といったアルゴリズムとして利用する分には、現実的だと思うが。
良いと思うが、既存の RDB なんかで十分という気持ちがしないわけではない。
デザイン領域以外は、既存のプログラマ延長でしょう？デザインはちょっとやる気ない。
デザイナーに頑張ってもらいたい。というか、デザイナーはここは責任持ってくれ。仕事なくなるぞ。
いつもお世話になってます。
世の中の問題に全て答えがあると思っている大馬鹿者の集まり。悪趣味。
いきなりセキュリティとかテストとか運用系に行くやつの末路は暗いと思っている。プログラマが後々コンバートするので十分だろ。
俺は好きやけどね。
高齢者向けのワクチン予約サイトがなかなか混雑して苦労するらしい。高齢親に頼まれたので、予約開始前に操作手順を確認してみた。
接種券番号と氏名が印字された接種券が郵送で届くので、予約サイトにアクセスしてみる。URLはこんなかんじ。
ttps://vaccines.sciseed.jp/(自治体名)/
フローはだいたいこんなかんじ。UIはまあ普通の予約サイトなかんじ。
3.初期パスワードを変更
5.接種会場検索→希望日時を選択→予約完了(予約開始前なので未確認)
そしていくつかトラップがあるようだ。
1.初期パスワードは生年月日(西暦)の数字8文字。誕生日を和暦でしか覚えてないと詰む。
2.メールアドレスの認証処理がなく、どのメールアドレスでも登録可能な模様。ここだけガバガバな理由は不明。
3.パスワードリマインダーが実装されていないようなので、失念したら詰む。多分電話しないとダメ。
そしてどうやら1.から3.までは予約当日より前に設定可能で、当日はログインして4.マイページで待機していれば進めるようだ。そんなのどこにも書いてない。
推測だけど、各自治体のサイトが混雑でつながらないっての、1.2.3.を当日朝によーいドンでやってるからではないかと。そりゃ混雑するのでは。
選挙投票所方式で「mmddのHHmm-HHmmの間にXX会場に来てね、予定が合わない場合は連絡してね」で十分で、混雑したら空間をとって一人ずつ入場させればすむだろうに。
必要なところにリソースが投入されてなくて、コネとしがらみでどうでもいいところにカネが動いてるのだろうなと想像させる作りだった。
ドメイン駆動設計ってあくまで設計手法っていうかビジネスロジックのモデリングまでが本分だから
システムドメイン（領域）にビジネスドメインで履いていた土足のまま踏み入ってはいけない
※補足追記：基本設計したら詳細設計するけども、そこでビジネスロジックをシステムロジックに翻訳するからコードレベルでは一対一にはならないということ
概念の次元が違うのだから現実に漫画の理屈を持ち込むなっていうレベルの話（ビジネスが漫画レベルという意味ではない）
モデリングによって現行のビジネスの問題を洗い出し、それを課題として解決（仕事を楽に）するのがシステム
それも一回で終わりじゃなくてシステム化したビジネスを再びドメインモデル化して分析、課題をシステムで解決ってサイクルを回していかなくちゃいけない
システム側も細かいこと言えば領域が分かれてるからそれぞれの領域に合わせて駆動方法は変えなきゃうまく回らない。
データレイク周りならデータ駆動型の方が適しているし、逆にアプリケーション側でビジネスやUXを無視してデータ主体で走るのは阿呆の所業だし、
馬鹿の一つ覚えで〇〇駆動設計だの開発だの一本槍でパワープレイするやつが多すぎなんだよ！ 適材適所って理解しろよ！
ちゃんと各分野のスペシャリストを雇って意思決定層に組み込んだ方が結果的に時間や金なんかのコストが少なくなるよって話が通じないよね
