  |
はてなキーワード: uxとは
なんせ全体像がわからない、検索ワードを知らないとたどり着けない。
UI/UXはずっと変わっているのだけど、デザイナーやアーキテクトの人は、その場その場で見て感じて判断しかしないのかと思ってしまう。
はてなスターは、ある程度気の利いたことが言えて、タイミングよくブックマークできれば、スターは簡単に集まる。
逆に言うと、時間を外しても、コメントがわかりにくい文体になっていると全然スターはつかない。
人気コメ常連であることが、更にスターが付きやすくなる条件にもなるが、それも最初の条件を守っていればクリアできる。
人気コメは人気コメになるだけの気づきを与えてくれることももちろん多いが、
それよりも、人気コメになりにくい時間にブックマークをしている冷静な意見を書いている人をお気に入りに入れた方が、何倍も気づきを与えてくれる。
はてな社は、人気コメのアルゴリズムをいじるより、もっとお気に入り機能を使おうと思えるUXにするなりなんなりした方がいいと思う。
はてブは頭のおかしな人も多いが、昔は無駄に相手の人格だけを攻撃して喜んでいるような、下種はそんなにいなかった。
サービスというものは、UI次第でどうしても居つくユーザが変わってしまう。
ここ数年の対立煽りの加速は、通報機能が面倒くさくなってから一気に加速したと思っている。
追記＞
RRD はてななんて、運転手が心肺停止して歩く程度の速さで中央線を越えるような車を見かけても平気でスルーするような、人でなしの集まりなんだから、そこでどう見られたからってなんの意味もない。
そんな話してない。
さすがに全然関係なさすぎる。人でなし以前に、人と会話する能力を得た方がいい。
追記２
「途中でブクマしてごぼう抜きするのが気持ちいいんじゃないか」（系の意見）
わかる。し、個人的にもそういうのは好きだ。
Slackのドヤ顔上から目線の広告もそうだけど、当時は全世界的にそういう空気だった。
モバイルOSやらarm向けOSやらで他社の模倣が大失敗していたこともあり、Teamsを有望視する声はあまり大きくなかったと記憶している。
結果論で言えば、TeamsがO365に含まれている時点で決まり切っていた未来だと言うことも出来るだろうが、同じ立場のYammerが今に至ってもうだつが上がらない以上Teamsの成功を説明するには不十分だ。
製品単独の機能比較で「Slackの方がUI/UXが優れている」というエンジニアから上がった声とは思えないようなふわっとした優位性が語られることは多い。
しかし、Teamsの優位性は「わざわざ別のサービスを買ってインテグレーションをしなくても様々なサービスがはじめから連携している」事にある。
コレの重要なポイントは「サービスを作った会社自身がインテグレーション部分も含めて正常動作を保証することが契約に含まれている」ということだ。
Slackと各種サービスを組み合わせて同等の価格で同等のサービスを提供するベンダーがいたとしてもその点だけはTeamsに太刀打ちできない。
企業の収益の観点からすればMicrosoftにとっては顧客がO365を買ってくれていればチャットツールにTeamsを使おうがSlackを使おうが収益の観点から損はない。
しかし、SlackにとってはSlackの代わりにTeamsを採用されたらその分の収益が見込めない。
そもそもが競合というにはあまりにも一方的な関係であるわけだ。
Microsoft社内のTeams開発チームにとってみれば確かに最有力の競合ではあるんだろうが。
ここ最近Slackは「TeamsがO365に無料でついてるなんて卑怯だ」と主張するようになった。
Teams発表当初のSlackユーザーにタイムトラベルしてこの状況を伝えても鼻で笑われること必至な状況だ。
しかし、TeamsはO365の各種サービスのパーツを寄せ集めて上っ面を整えただけのサービスなのでホントにO365のおまけ程度のサービスなのだ。
チャットメッセージはExchangeの各ユーザーのメールボックスの隠し領域に保存されてるし、チーム用のストレージはsharepointサイトだ。
クラウドPBXなどの有償オプションはあるが、Teams利用に必須ではないし、むしろ存在すら知らない組織の方が多いだろう。
専用のリソースがないわけではないが、それもAzure向けに大量確保しているリソースを流用するだけだ。
チャットツールに関するリソースをすべてそのためだけに調達しなければならないSlackが太刀打ちできるわけがない。
調達の共通化によるボリュームメリットを否定するならそれは資本主義の否定だ。
同一分野のツールである以上、完全に無視するのは愚策であるとはいえ、今のように必要以上にTeamsを意識した戦略はコストの浪費に他ならない。
Teamsの牙城は元々O365の牙城だっただけで、Slackから奪ったわけではない。
既に従業員一人あたりでSlackと同額かそれ以上のコストをかけてる企業に「優れたチャット専用ツールのためにもっと金出してください」と呼びかけたところで、それに応じる企業はそんなに多くない。
PV乞食がSlackとTeamsを並べて囃し立てるから「つかめたはずの客を奪われた」ように錯覚させられるかも知れないが、Teamsが囲った客にSlackがつかめたはずの客はホントにいたのか？
Slackは元々「チャット専用ツールのために金を出す」というブルジョワ企業のためのサービスとして成長してきた。
フリーミアムで客を囲ってはいても最終目的はチャット専用ツールで収益を上げることだった。
だったらTeamsに対しては競合の一つ以上に注意を払わず数少ないブルジョワ企業のために動くべきではなかったのか。
そう思っていたら、SlackはSalesforceに身売りしてTeams対抗路線により明確にフォーカスしていくようだ。
SalesforceがGithubに対するMSのように「太っ腹で放任主義なパトロン」のような立ち位置に納まってくれれば良いが、既にチャットツールとして組み込むとかそういう話も出てるのであまり楽観視は出来ない。
next.js が vercel を提供して CDN からサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。
それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。「とにかくフロントエンド領域しか絶対にやりたくない」という人が沢山いるが、しかし一方フロントエンドで無理しないでサーバーを書くだけで楽になるようなタスクはいくらでもある(典型的には API たくさんアクセスするとか)。
そうしたときに、フロントエンドメインだがバックエンドも書けるみたいな人がそういうサーバー忌避患者を介護する層として BFF の需要があり(無論それだけが BFF に求められるのではなく認証などの要素も大きいが)、サーバーサイドレンダリングというタスクもあるため node.js で何らかのサーバーが書かれていった。
アイソモーフィックな JS によりフロントエンドとサーバーサイドを統合する、という試みはこれまであまり成功しなかったので(結局どっちにも詳しくないといけないから正しく書ける人がすくない)、 next.js の getStaticProps や React Server Component は「サーバーサイドだけで動くコードを見た目上フロントエンドのコードの中に含める」という解決策を提示した。
ここまでしないとフロントの人がサーバー側を書いてくれないという現実は、あるわけですよ。「そんな奴言って聞かせりゃいいじゃねえか」とか思うかもしれないけど、これが現実。これが全てという話でもないけど、わりとこんな話が大きいように僕には見える。
起きていることはそういう話なのだけど、これはけして JSP 時代への先祖帰りではなく、この進歩の先にはサーバーとクライアントを跨いで快適な UX を誰でも簡単に実現するという未来が、もしかしたら今回こそ実現できるかもしれない、と僕は思ってます。
Apple M1の高性能の理由について、ネットはクソみたいな解説記事に溢れている。
技術に明るいはずのはてなーですら某AVライターの間違いだらけの記事に釣られて、300ブクマ超が集まっていて嘆かわしい。
それもこれも後藤センセーがいつまでたっても解説記事を書いてくれないせいではあるが、公開情報が少なすぎるせいでまともなライターほど記事を書けないのも理解できる。
違います。
そもそもM1はDRAMをSoC化／ワンチップ化していません。M1がやっているのはSiP(System in Package、複数チップをワンパッケージに組み込む）であって、eDRAMによるSoCとは全く異なるものです。
SiPとSoCはJavaとJavascriptくらいには違います。
違います。
HBM系のメモリを採用していたらメモリ帯域は大幅に向上しますが、M1は標準DDR系メモリをワンパッケージ化しているだけなので、帯域もレイテンシも変わりません。
帯域はM1 MBPとIntel MBP(Ice Lake)でチャネル数同じ、前者はLPDDR4X-4266、後者はLPDDR4X-3733なのでメモリ帯域は14%しか向上していません。また、x86／x64最新世代のTiger Lake／ReniorはLPDDR4X-4266に対応しています。レイテンシはM1が96.8ns、Tiger Lakeが98.4nsでほぼ同等です。
Apple M1の実力を最新世代のIntel/AMD CPUと比較。M1が両者を大きく上回る結果ににあるように、SiP化によって消費電力の削減は期待できます。
違います。
SoC-DRAM間がマザーボード上で30cmあったとしても、電気信号の伝送にかかる時間は片道1nsです。仮にSiP化で物理的距離が1/100になったとしてもレイテンシ100usが98.02usになるだけで、CPUにとってDRAMが絶望的に遠いことに変わりありません。
違います。
まず、同一チップ上のCPUとGPUが同一のメモリーコントローラ／DRAMを共有するという意味では、Intelは2011年のSandy Bridge、AMDも2011年のLlanoからUMAです。一歩進んだメモリ空間の共有、コヒーレンシの確保という意味でも、AMDは2014年のKaveriから対応していて、この点においてM1に革新性はありません。
違います。
上記のSandy Bridge、Llanoの世代からかつてのノースブリッジがCPUに取り込まれたため、2011年以降のモバイルPC向け”CPU”のほぼ全てにはGPU／メモリーコントローラが含まれています。
かつてのサウスブリッジはIntelは今でもワンチップ化こそしていませんが、2013年のHaswellからMCMでワンパッケージ内には収められています。AMDは2014年のCarrizoからサウスブリッジ機能もCPUに取り込まれています。
この意味で、x86／x64のモバイルPC向け”CPU”は、かなり以前からSoCです。
違います。
NPUを活かせるアプリケーションは2020年現在では未だ限定的です。もしNPUの有無によってUXが決定的に改善されるなら、NPUありのSnapdargon 8cxを積むSurface Pro Xは同世代のSurface Pro 7よりずっと快適でなければなりませんが、そのような事実はありません。
違います。
CISC／RISCの論争は20年以上前に終わった話です。その後CISCはRISCの美点、RISCはCISCの美点を取り入れたので、現代のCPUはISAがCISCか／RISCかだけで性能が決定されることはありません。
歴史的経緯からx86／x64のデコーダが複雑になりがちなのは事実ですが、5W以下のローパワープロセッサの開発へ向かうIntelにあるように、ISAの差による消費電力増は10～20%のレンジで、さらに性能増によって相殺される分、電力効率の差としてはわずかです。
頑張って最適化してIPC上げたのと、スマホ由来の積極的なDVFS・クロックゲーティング・パワーゲーティングで浮いた消費電力を回しているからです。
気が向いたら書きます。
12月3日に出たライザのアトリエ2 〜失われた伝承と秘密の妖精〜を遊んだ。
しょうがないとは思っている。
1年で納得するようなクオリティの続編を出せと言われたら無理だろうと思う。
その意味では時間が全くないのによくやったと褒めるべきだろう。
・また結局異界とフィルフィサのお話、ラスボスはまたちょっと違う大物個体のフィルフィサ
→新しく見つかった別の異界の門を封じてストーリーエンド（前作と一緒）
→ストーリー途中で魔獣に乗れるようになるのだが、魔獣に乗ってるとフィールドを掘れるようになりそこから重要な素材がランダムで出て来る（素材は各ダンジョンで変わる）、逆にフィールドに配置されている採集場所は序盤中盤とほぼ一緒で採集する価値がない飾りになる
・魔獣で素材を掘り起こすため、あの素材どこで取れるっけ？を忘れやすい
・仲間が人生の目的を見つけて将来の行動や夢を持って進んでいるのに、主人公であるライザが前作で錬金術師になったと変化があってから進めてない
→自分の将来の夢や目的を見つけてないので2の舞台でやることを達成したら故郷の島に帰る、周りの仲間と比べてこいつ何にも成長してないなという感じが強い、主人公のくせに停滞している
・ストーリークリア後の裏ダンジョンがない、クリア後のやりこみがしょぼい
→裏ボスは解禁される、またクリアデータで最初から周回できる（装備など引き継ぎ可能、高難易度が解禁される）
・ストーリーは謎の石（実は卵）から生まれた謎の生物フィー（正体は異界の精霊）の調査からはじまってフィーが異界の生き物であるためライザたちの世界では摂取できるモノが乏しく生きていけずどうにか元気にするためにフィーが食べられるものを頑張って探す話だ。結局フィーのために食べるものを探してたら誤って、古代人の工夫によって封鎖されていた異界の門を解放させてしまった。そこから出てきた大物個体フィルフィサをやっつける。フィーの食べ物の問題は解決できなかったので門から異界に行かせて、そこでならフィーの食べるものがあるので異界で生きていけとお別れして門を封鎖する。それで終わり。
→普通はストーリークリア後のやりこみとして異界に行ったフィーに会いに行けるように錬金術でチョメチョメするために頑張るとかそういう展開になるのだが、とにかくフィーがいなくなってそれで終わり。ライザもやることがなくなったので故郷に帰ると言って閉幕。
ガッカリポイントを言うだけだとフェアではないのでグッドポイントも言っておく。
・バトルがさらに派手になっている（数少ない改善改良ポイント）
・前作よりワンランク上の素材が出てる
→前作はゴルドテリオンが最上級の鉱物系素材だった。今作はさらにワンランク上のグランツオルゲンが出ている。
→細かい差異は変わってるが本質的には前作のやりこみと同じことをやってる
Switchのヒューマンリソースマシーンっていうゲーム知ってる？
https://note.com/keigox68000/n/nb3b536465f00
わたしはUI/UXデザイナーなんだけど、大学のとににプログラミングの授業があったりしたのでちょっとだけわかる(ほんとにほんとにほんとにちょっとだけ)
最近デートしてるエンジニアと家でゲームして遊んでたんだけど、ヒューマンリソースマシーンを買ったままやってないことに気づいて一緒にやった。
中盤まで自力で解いて、2.3個教えてもらいながら解いて(ここは、最高だったな。その人がいつもの何億倍も知的に見えた)、そのあとはその人が一人で問いてた。
わたしからしたら全てのエンジニアはわたしにできないことをよくわからない感じでやってるすごい人！みたいなイメージだったんだけど、中盤ちょっと行ったところで、その人がクリアできなくなったのを見て、全然できないじゃん！！！！ってなった。
クリアできてなかったのは、
二つの数字を比べて、どちらも正or負の数字の場合0を、異なる数字の場合1をアウトプットに出すっていう問題。
ソートのアルゴリズム思いつかないから解けないとかならわかるけどさぁ
あとは、普段は問題に出てくるようなアルゴリズムがあらかじめ言語ごとに用意されてるとかもあるだろうけどさ、
でもこの上に書いた問題解けないってエンジニアに重要な考える力弱くない？って思った
すなわち仕事の能力低い人なのかなって思って、めちゃくちゃ優しいけど、めちゃくちゃ萎えた🤷♀️
追加
戸籍の考え方は家族の考え方であり姓というのは家族をまとめた記号である。男女が結婚した際に新たな家族が誕生するため新たな戸籍の作成が必要となるのだがこの戸籍の名前として姓を統一するというのが旧来ある考え方だ。
ここに男女の不平等は存在せずこの新たな戸籍の姓として夫妻どちらのものを使用しても構わない。妻が夫の姓にすることが多いという実態を指して女性差別であるとする論は基本的に筋が悪い。離婚時に親権が母親に行きがちなのは裁判官の判断に依るので、これは司法の男性差別であると言える。しかし結婚時の改姓に関してはこの離婚時の親権問題のように他の誰かが勝手に決めたりそれを強制させられるということはなく夫妻となる男女双方の一致する意志により行われるのであり法的にもそうなっているのであるから、差別であるという主張は無意味である。女性が姓を変えがちだというのは文化的なものであり、悪いのは文化の方である。夫婦同姓が女性差別であると主張する人達は男性側の改姓を促す運動をすれば良い。
改姓時に改姓する側がほぼ全ての書類の名前を書き直す必要があり大変に手間がかかるという問題もよく夫婦別姓が解消するものとして例示されることがある。これに関しては夫婦同姓が悪いというよりも姓の変更を要求する機関が悪いと言える。社会のUXが悪いのが問題である。このUXの悪さに関して声を上げる人は少ないように見受けられる。
姓の変更によるアイデンティティーの喪失を問題とする人達もいるが、これも姓で相手を呼ぶ文化が悪いと言える。先述した通り姓は家族の記号であるのであるから、これを個人特定の記号として使うことがそもそもの間違いであり、姓にアイデンティティーを見出すのがそもそもの間違いである。姓ではなく名があなたのアイデンティティーである。
姓の変更により家族を移る感じなのが嫌だという意見もあるが、この主張も筋が悪い。姓はそもそも家族の記号であるのであり、新たな家族が誕生するのであるから新たな家族の記号が嫌であるというのはただのワガママでしかない。夫婦別姓よりも夫婦が同意した自由に新姓をつくることができるようにするとした方が戸籍の考えに合っているのではないだろうか。
戸籍の考え方がそもそも古いしおかしいという主張がある。これには一理ある。本籍地などといった完全に形骸化したものが未だに使われているのはIT全盛の時代にそぐわないだろう。夫婦別姓論を唱える人々は現在の戸籍の拡充ではなく、戸籍の基本となる日本における家族そのものの考え方にチャレンジしなければならない。夫婦別姓反対派が夫婦別姓は家族の破壊であるとし反対しているのに対し、改姓後の書類の手続きの面倒さのみでこの制度の改修を要求するのは筋が悪いと言わざるを得ない。なぜ夫婦新姓でもなくなぜ夫婦別姓にこだわるのか。なぜ改姓時に手間を要求する社会を責めないのか。
夫婦別姓に関しては日本の立法制度に起因する問題もある。例えば自民党は夫婦別姓に反対であり、自民党を負かしたい野党は国民に人気のある法案を用意する。私達の党は夫婦別姓を支持しますという宣伝をして票を集める。問題なのは日本にはまともな野党が一つもないことだ。仮に夫婦別姓を支持するからと野党に投票して野党が勝ってしまうととんでもないことになる。自民党が危険な左派の考え方であるとして夫婦別姓を切り捨てるのにはこのような背景もある。夫婦別姓は進めたいが野党には勝ってほしくないといった人達は野党に投票しないため、結果夫婦別姓の実現はいつまで経っても実現しない。アメリカではpropositionに投票することが可能であり、法案ごとに住民投票で可否決することがあるが、日本でもそれをやれば良いのではないか。こちらからの攻め方もあろうになぜ手続きの面倒臭さや多様な家族観などといった点で攻めるのか。夫婦別姓に反対する人を古いとか頭が悪いとか決めつけたところで争いが起きるだけで何も変わらない。
努力不足でSESにしか行けなかったというツイートが話題になっていますね。
件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。
業界に入って十数年、メガベンチャーで働きGAFAの関連企業から1X00万円のオファーを貰うくらいのスキルと経験はある。もちろん開発のスペシャリストとして。
新宿の雑居ビルにオフィスのある中国人が経営するSES会社からキャリアをスタート。最初の会社は雇用保険も払ってなかった。
新卒または第二新卒、文系または数学が苦手、プログラミング未経験者でスクールやサロンに入ってプログラミングを身につけて働きたいと思ってるひと。
理系やプログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いからスクリプトで業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。
ふたこぶラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)
要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。
学び始めてすぐに判断を下す必要はないですが、スクールのカリキュラムを終える頃には周りとの成長スピードの差で自然に理解できるかと思います。
しかし、もし適正がなかったとしても悲観するのはまだ早いです。
プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjM、UIデザイナー、UXデザイナー、カスタマーサクセス、営業、採用、などなどいろいろあります。
なにはともあれ3割くらいは可能性があって外れても選択肢があるんですからポジティブに受け止めましょう。
エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。
さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。
あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？
ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。
そろそろ本題に近づいてきました。
ここまでの話を踏まえてどうするべきだと思いますか？
特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。
あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。
ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。
初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。
ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。
デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ (https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。
様々な点で両者は異なります。
真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。
なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。
また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。
デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。
そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。
翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。
ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？
ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。
現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。
Yahooカーナビも、食べログも捨てて愛用していたGoogle Mapだが、最近の体制に疑問を感じるので元に戻るつもりだ。
そもそもGoogle マップを愛用するようになったきっかけは、細い路地裏でも一方通行の道はきちんと判別してそれを元に経路案内をしていたことと、ローカルガイドによる口コミの信憑性の高さだった。
それが昨年、マップデータをアップデートし、今までのマップ精度の高さは単にゼンリンがすごかっただけと判明した上に、2020年からはローカルガイドによる口コミもかなり恣意的になってきたことが私をGoogleマップから卒業させる決定打となった。
以前までの口コミはポジティブでもネガティブでもすべて表示をされていた。写真も特に制限はなかったように思う。
そこが、否定的なレビューは消されてしまう食べログやホットペッパーとは異なっており、好感を持っていた。
もちろん否定的なレビューを書かれた物件所有者としては納得できないところもあるだろうが、それはオーナーからの返信で説明をすればユーザーはそのレビューの真偽を自分で判断できるので問題ではない。
しかし、最近ではGoogle マイビジネスの拡販を進めたいことからどうにも店側が一方的に有利になってしまっている。マイビジネスオーナーは、低評価の口コミを「ガイド違反だ」という理由をつけて非表示要求をする。Googleとしてはそのオーナーが担当付きであればあるほど優遇をし、明確なガイド違反でなくとも非表示をするし、レビューや写真の表示を承認制にしているようだ。
オーナーは気に食わないレビューに対して、「お店からの返信」として散々罵倒をしても、その後すぐに非表示申請をすれば他の客には見られることなく、いい評価だけを保つことができるのだ。
ローカルガイドが他のユーザーの検討材料のためにわざわざ時間をかけてアップロードした写真や投稿を削除あるいは非表示にするというのはあまりに失礼な話でもある。
何より、「悪意のある情報をユーザーは信じ込んでしまうからこのレビューは削除しよう」という考えは全ユーザーをバカにしすぎではないだろうか。
いつだかのアップデートから、検索エンジンでもGoogleが一部の検索ワードを勝手に除外した上での検索結果を見せるようになった。
これには少なくない数の人々が不満と悲鳴をあげているが、まさにこれこそが近年のGoogleの姿勢を示す代表例なのだろう。
「ユーザーに素晴らしいUXを」ではなく、「ユーザーは馬鹿だからこちらが適切な情報を与えないと」という考えにシフトしつつある昨今のGoogleは到底好きになれない。
自分がかつて熱意を持って働いていたころのGoogleはもうそこにはいない。仕事を変えたことに間違いはないと改めて思うのであった。
自分はプログラマをやっている。もしかしたらプログラマとは呼べないレベルの幼稚な仕事かもしれないが、職業を聞かれたときはいつもプログラマを名乗っている。
未経験からプログラマになったので3年間はプログラミングに関わることをひたすら寝る間も惜しんで勉強をした。プログラミングに元々興味があったのと、一緒に働く人は学校などで勉強してきているのでその人たちに追いつけるようにだ。
勉強したことはセキュリティ、プログラミングの基礎の基礎で誰もが知っていることだと思っていた。だからこそ、それが出来ていない物、人、それを放置しておく自分にも腹が立つようになっていた。
無性に腹が立ったとき、例えばそれが赤の他人・企業のWEBサイト/サーバであれば報告し、OSSであればPRを送り、仕事であればそのままコードをコピペできるレベルで丁寧にsuggestionをした。
しかし次第に腹が立つ物が増えていき、誰も何も頼んでいないのに勝手に忙しくなり、ときには倒れ、最終的にうつ病になってしまった。
彼女（？）のWEBサイトはとても読み込みが遅い。大きいサイズの自分で描いた絵をほとんど圧縮しないままトップページに表示しているからだ。コメント欄があるにも関わらずSSL化もされていない。また、WEBページ自体の順位もかなり低い。UX的にもあまりよくない。それでも彼女（？）は今日も楽しそうに絵を描いたりプログラミングをしたりWEBサイトを作成したりしている。
不思議と腹は立たなかった。彼女（？）は自分がやりたいことを楽しくやっているだけなのだ。サイトの状態こそが彼女（？）の個性なのだ。
そう思うと、今まで何に腹が立っていたのかわからなくなった。
証明書の期限切れ、ドメインの期限切れ、XSS対策不備、ゾンビコンピュータ、全部個性じゃないか。
自分が腹を立てる必要などなかったのだ。逆に腹を立てること自体が失礼だった気もしてくる。
そう思うと、なんだか心が軽くなった気がした。
なんだこのクソ使いづらいUIは。
ピザが食いたいときは我慢して使ってきたけどよ、パスワード変更のUXまでクソなのは擁護しきれん
マイページという概念が存在しないせいで、パスワード変更するにはログイン前画面の「パスワードを忘れた方は」こちらからしけいけないらしい。この時点で大分カス仕様なんだが、百歩譲っていったん目をつぶろう。
パスワード変更申請画面にメールアドレスを入力するとパスワード変更用URLがメールで送られてくるんだが、ここはまあいいとして。
それになんの意味があるんんだ？？？？？一要素認証を何度やってもマルチ要素認証にはならないだり？？？？？第一いつ設定したかもわからない出生地なんかたった３回のチャンスで入力できるわけねーだろ！！！！！！！都道府県は含めるのか？合併する前の市名か？後の市名か？自由記述の欄なんかいろいろ考慮したら10回でも足りねーよボケ
webサイトを見たことも使ったことも作ったこともないど素人が作ってるのか？
