  |
はてなキーワード: ユーザーテストとは
本当のことは載せられないので
仮に嘘っぱちな適当な例を出すと
■入力がこれだと
■出力はこれになる
私は飲食店の予約システムの新規構築を担当し、要件定義から製造まで関わってきました。設計にも携わり、チームリーダーとして進捗管理を行いました。また、UI/UXデザインも担当し、ユーザビリティの向上に努めました。
要件定義の段階では、飲食店にとって必要な機能や予約の流れなどを考慮し、基本設計書を作成しました。次に、画面遷移図やER図を作成するなどして、詳細設計に取り組みました。製造フェーズでは、チームリーダーとして進捗管理を行い、納期や品質に配慮しながら開発を進めました。
UI/UXについては、シンプルでわかりやすいUIを実現するために、ユーザビリティに関する情報を収集し、ユーザーテストを実施しました。その結果、より使いやすく、直感的なUI/UXを提供することができました。
私は、開発プロジェクト全体を通して、チームと協力し、品質の高いシステムを提供することに注力してきました。今後も、開発に携わることでスキルアップを図り、より良いシステムの実現に貢献したいと考えています。
こんな感じ。
ウマ娘のイベント不具合、ユーザーにはデメリットとなるようなものじゃないけど、プログラマーから見たら凄くお粗末でそこは正直、草。
例えば、友情トレーニングの回数を数える場合について、トレーニング後に友情トレの閾値を超える場合(ステータスの色が緑からオレンジ色になる場合)、本来はカウントしてはいけないけどカウントしてました～って話、
これ、要するに境界値テストや実装後のユーザーテストちゃんとやってなかったってことだよね。実装者に要件がうまく伝わってなかった場合も考えられなくはないけど、いずれにしてもこんなのすぐ見つかるでしょレベル。
イベントを想定して作りこんでテストも済ませていたつもりだったけど、いざ忘れたごろに本番で動かしてみたらバグでしたー！！みたいな話だと思う。
残念だけど、ゲームプランニングやレース展開へのパラメータ実装の設計を考えた人たちと、こういう細部を支えた人たちはまた違うんだろうな。
逆に言えば、しょぼい問題、該当するユーザーが少ないケースしかとりまなくて、進行止まったり、本来出られないはずのレースに出ちゃったりできるような炎上必須のインシデントがないのは奇跡だわ。
あ、ユーザー集中で鯖が止まったけどあれはインフラだから別の話だと思ってる。
ウェブマスター オフィスアワー 2019 年 10 月 02 日 メモ（※所々抜け漏れあり）
https://www.youtube.com/watch?v=bBurTQBqhS0
11/25 Webmaster Conference Tokyo：今週か来週の早い段階で情報を公開する予定
最新情報への対応や常に変動するランキングに対応させるためのもの
「何かまずいところがないだろうか？」という視点でサイトに着手するのは不要
客観的にいいのか悪いのかを知るために定期的なユーザーテストの実施とか、
お互いにレビューし合う習慣を付けるとか
品質評価ガイドラインとかE-A-Tとかは個人的には見なくても良いと思うが、
Q.RankBrainにおける更新性や更新の有無による効果はあるのか？
A.オフィスアワーでランキング要素の可能性について言及するのは難しい。言えることはコンテンツの内容を改善してくださいということだけ。もし、更新性が影響すると言ってしまうとみんながそっちに走ってしまうので。
Q.被リンクではページランクとドメインランクのどちらを重要視していますか？
A.ショートアンサーとしてはどちらでもありません。
仮にドメインランクが重要ですと言ったら何が起こるでしょうか？オールドドメインの買い占めが発生してしまうでしょう。
例えばコンテンツの質を見るに、Wikipediaに関連リンクを貼られるとかそのくらいの影響力があるのかなどを見てみると良いでしょう。
筆者注：
【図解】グーグルのリンク評価20の原則【2019年版】（前編#1～#10） | Moz - SEOとインバウンドマーケティングの実践情報 | Web担当者Forum
https://webtan.impress.co.jp/e/2019/09/30/34042
初心者必見!SEO対策の基本を5分で完全解説【2019年最新版】
https://emma.tools/magazine/seo-basics/
↑これら記事とか？
A.Googleのアルゴリズムも完璧ではないので、アップデートで再評価される可能性はある。
メインのクエリでユーザーが自身のサービスが頭に浮かぶような存在になれるかどうか。
Q.robots.txtでブロックしていないURLなのに、カバレッジでrobots.txtでブロックされていますというエラーが出る
A.色々確認中ではありますが、私が調べた範疇では問題ありません。Search Consoleのフィードバックも送ってください。その際、スクリーンショットだけではなく、テキストで問題点も添えてください。
Q.サイト内画像をサムネイルとして表示したい。Googleが推奨する方法がありませんか？
A.特にそのやり方については公開はしておりません。Googleが良いと思った画像だけを採用します。
強いて対策を言えば、画像のヘルプを参考に画像の情報をGoogleに伝えるようにしてください。
A.確認しましたが、Search Consoleに表示されています。
タイムラグがあるかもしれませんがDisallowされていませんか？確認してみてください。
Q.HTTPSのSearch Consoleは追加した方が良い？重複コンテンツになりますか？？
A.追加した方が良いです。
重複コンテンツによって、起こるのはどちらかのコンテンツが上位表示される可能性があるということ。
共倒れになるということはありません。
そのクエリで頭に浮かぶくらいの存在になっているかどうかです。
Q.セパレートURLにおいてMFI後のcanonicalURLの設定について
正規化とは同等のページ内容のURLが複数あるからこそ行うもの。
canonicalよりも、リダイレクトでやってみてはどうでしょうか？
Q.検索パフォーマンスのデータの収集開始タイミングはいつから？？
A.基本的には登録前のデータも取れるはずですが、違うケースもあればフィードバックで教えて下さい。
Q.Search Consoleのプロパティへの表示について、所有者として確認されてから６日経ってもプロパティに表示されていません
A.何らかの判断で時間がかかったのだと思います。通常は数日ですが、遅れたのは新規サイトであることが要因である可能性があることです。なにか不具合ありましたらSearch Consoleへフィードバックをぜひお願いします。
A.かなり困っているご様子ですので取り上げましたが、当フォーラムでは対象外の話題ですのでウェブ検索フォーラムへ送信願います。
Q.max-image-preview robots meta の値を確認するには？
A.まだ反映されていないのでもうちょっと待てば反映されます。
Q.Search ConsoleのタイムゾーンについてPTからPSTとPDTに切り替わりますか？
A.切り替わります！！
Q.ドメインを変えずにサイト名だけを変えると検索順位はどう変わる？
A.サイト名ほど大きな要素を変えてしまうのは影響すると思います。
どういうサイト名に変えるのかも重要。ユーザーにとってわかりやすくなるとかであれば、長期的には有効になるかもしれません。
Q.max-image-preview でlargeを設定するとDiscoverに表示されやすいと聞きましたがAMP対応しているだけでDiscoverに表示されやすくなりますか？
A.AMPでもmax-image-previewでlargeでもどっちでも対応可能です。
Q.クロールエラーが特定できない件について、１月のオフィスアワーにてホスティング会社に相談してみては？との回答で、のち、６月に検証中とのことでしたがあれからいかがでしょうか？
A.あまり気にされなくても良いです。ただ、間違ったエラーが表示されないようにするためにエンジニアも調整中ではあります。
こういうエラーに気づかれましたらSearch Consoleのフィードバックをぜひお願いします。
次回は１０月後半か１１月前半の予定です
設計書を読んでプログラムを書くにも、その設計の前提知識の理解がないと進まない
たしかにその期間で業務仕様はある程度頭に入った、けれど理解には程遠い
その後は自分の担当機能の実装に必要な知識を、その場その場で掻き集めるといった感じ、全体の仕様理解なんてカケラもできない
その後の結合テスト、システムテスト、ユーザーテストの補佐、そしてリリース後の運用フォローときて、ようやく何を使っていたか、業務仕様の全体像を想像する程度にはなった
1年と少しかかった
振り返って思う
近々の自分の仕事に関わらない情報は説明されても頭にとどめて置くのは難しい
業務仕様についての2週間のトレーニングを1カ月、3カ月と増やしてもたぶん理解が大きく増えることはなかった
すぐに必要でない知識を大量に与えられても一定以上のものは受け取れないのだ
得た知識からなんらかのアクションを起こし（詳細設計、実装、テスト）、そのフィードバックがあることで、業務仕様理解が進むんだと感じている
忙しい方向けに結論を先出しすると、
・「『正しい前提』でないと、いくらそこからの説明がロジカルでも誤った結論しかでないのが上手くいかない原因」
・人間は論理の誤りを検出するのは得意だが、自分の見てきたものでしか世界を把握できないために前提の正しさの検証が苦手
・場合によっては、論理的整合性を保つために現実にバイアスをかけたり自分に嘘をついたりして前提をでっちあげてしまうこともある。
・いくらロジカルで筋がよくても、なんかもやっとするときは前提を疑おうね。
という話です。
数学や論理学をベースとした理論では論理的であれば必ず正しくなります。そこで、世間では理論に限らず様々な場所で論理性を活用して物事を上手く回しているように見受けられます。
しかしながら私は、とりわけBtoCの現場では論理的であるからといって必ずしもうまくいくわけではないことに気付きました。そして何かを考えたり作ったりする上でロジックに全幅の信頼を置くのをやめました。
最初はこの気づきを上手く言語化出来ず、ロジックを信奉している方々になぜそうなのか説明してもなかなかうなずいてもらえなかったのですが
この度何故自分がそう考えるかの「ロジカルな」説明がおおよそ形になりました。
（尚、ここで言うロジカルとは、AでA⇒BならBだよねとかAでBだからA∧Bは真だよねなど、何かしらの真なる前提の元にそこから言えることを組み立てるという方法論をさします）
理論では、究極的な大元になる前提（公理）が存在し、それを前提に論理を組み立てることで様々なことを言っていきます。
要するに「前提が正しい、論理が正しい、だからそこから言えることは正しい」なわけです。
逆にいえば、論理が正しくとも前提が誤っていればその結果は誤りうるわけで、標題の主張の根本はここにあります。
現実で何か提案や問題解決を行う際にも、何か前提があり、そこに論理を入れることで、結論を出すわけですが、ここで正しい前提を設定しないといくら論理の筋がよくても結論が誤ったものになります。
では正しい前提とは何でしょうか。多くの場合、主張する当人が正しいと思い、その場で意思決定をする人間がそれを否定することが出来ないことが正しい前提として扱われるのではないでしょうか。
論理学や数学における公理のようにそれ自体が地球上の何億人という人間によって否定できないならまだしも、実際の現場ではたかだか数人が否定出来ないことによってそれが正しいように扱われます。
言ってしまえば、その場で意思決定する人間全員が否定できなければいくら誤った前提でも通ってしまうのです。
じゃあもっと広い人にその前提を検証するためにユーザーテストや市場調査を十分に行えば問題ないかと言えばそういうわけでもありません。現実問題として潜在的なユーザー全員を調査することは困難でありますし、例え全員を調査できたからといっても、調査した人それぞれが自分の感覚を正直に言葉にできるわけではありません。時には真逆のことを言ってしまうこともあります。
そういった制約のなかで、本当にその前提が正しいのかを検証することは困難です。説明が論理的かどうかは多少勉強をすればわかりますし論理的でないことを捉えるのも簡単ですが、自分が立った前提が正しいかどうかは「少なくとも自分の世界や調べた範囲では当てはまらないものがない」ということでしか検証できないため、広い世界で本当に現実に即しているかを把握することは非常に困難になります。
また、これは仕事で成果を出さなければならないという状況下で顕著ですが、筋が通っていなければ提案が否定されるということを理解している人が、筋の通った説明をするために自分にバイアスをかけて真実を歪める場合があります。たちが悪いのが、成果を出すこと＝意見を通すこととなってしまった場合に自分自身そのバイアスに本当に気づかない、または気づかないフリをすることがあるのです。
要するに、前提が間違ってていいならロジカルであることなんて簡単で何にでもロジックをつけてしまえるということでして、本当に難しいのは正しい前提を見つけることなんです。
だからこそ、本当に成功したいのであれば他人の「ロジカルな」説明を聞いて「ロジカルだから大丈夫だろう」などと考えてはいけません。貴方が話を聞いて正しそうに感じるけど何か引っかかるのであれば、それはおそらくこねくり回された理屈の都合の悪い部分が前提に隠されているのを感覚で感じているからです。前提を疑いましょう。きっとなにか隙があります。
今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田に投稿するので少し緊張している。
自分は誰かというと、金融系ユーザー子会社に勤めているSEだ。いわゆる１次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。
SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの１つにすぎないものとして読んでほしいと思う。
【私の仕事について】
まず初めに、自分の仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、
2.エクセルで作ったスケジュールやWBS(タスクリストみたいなもの)を広げて眺めている
3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く
4.上司やユーザー宛へ説明する資料を作成する。そして実際に説明する
これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事で専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルールの作成、ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。
同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの３割が情報系、３割が情報系以外の理系、残りが文系といった印象を受ける。
はてなを見ていてWeb業界やアプリ業界をさらーっとIT系の用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。
会社の中のほとんどの人がGit、GitHubを知らないだろうし、DockerやJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術に貪欲でないし、それを使える環境はないし、ユーザーも投資しない。
新しい技術は基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら？という問いに回答できないケースばかりだからだ。だから、今動いているシステムにスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。
誰も、どうしていいか分からない、どこから手をつけたらいいか分からないのだ。
じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務に精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。
ユーザーもユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチでもっと金かけてやれよと思うのだが、ユーザーはパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。
また、業務内容によってはミスった時のリスクがでかい。特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。
【やりがいについて】
毎日メールとエクセルとパワポとにらめっこして、ユーザーとベンダーとおしゃべりして、何かやりがいはありますか？と問われると、少しだけあるにはある。
案件規模が億越え、10億とか普通な世界なので、官公庁と連携したりと大きな仕事が多い。勝手にゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、
例えば「スカイツリー建設のプロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな？と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。
だからエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行や飲み会の写真ばかりだ。
一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキルの必要な仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的なスキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有のスキルを身につけてしまって、他社に転職できない状態になるのだが。)
私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。
ただ、私にはミスの許されない超絶大規模プロジェクトに精神をヒリヒリさせながら、数百人月のプロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。
