「ユーザーテスト」を含む日記 RSS

はてなキーワード: ユーザーテストとは

2019-10-02

ウェブマスター オフィスアワー 2019 年 10 月 02 日

ウェブマスター オフィスアワー 2019 年 10 月 02 日 メモ(※所々抜け漏れあり)

https://www.youtube.com/watch?v=bBurTQBqhS0

11/25 Webmaster Conference Tokyo:今週か来週の早い段階で情報を公開する予定

コアアップデート順位が下がった場合

金谷さんコメント

コアアップデートスパム対策としてのアップデートではなく、

最新情報への対応や常に変動するランキング対応させるためのもの

「何かまずいところがないだろうか?」という視点サイトに着手するのは不要

サイトコンテンツを見直すきっかけ程度にしてくれれば

客観的にいいのか悪いのかを知るために定期的なユーザーテスト実施とか、

お互いにレビューし合う習慣を付けるとか

品質評価ガイドラインとかE-A-Tとかは個人的には見なくても良いと思うが、

ユーザーの思う良し悪しの定義に迷った際の参考としてくれればと思う

そもそも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/

↑これら記事とか?


Q.評価や手動対策評価点を知る方法はないか

A.Googleアルゴリズム完璧ではないので、アップデートで再評価される可能性はある。

メインのクエリユーザー自身サービスが頭に浮かぶような存在になれるかどうか。

Q.robots.txtブロックしていないURLなのに、カバレッジrobots.txtブロックされていますというエラーが出る

A.色々確認中ではありますが、私が調べた範疇では問題ありません。Search Consoleフィードバックも送ってください。その際、スクリーンショットだけではなく、テキスト問題点も添えてください。

Q.サイト画像サムネイルとして表示したい。Googleが推奨する方法がありませんか?

A.特にそのやり方については公開はしておりません。Googleが良いと思った画像だけを採用します。

強いて対策を言えば、画像ヘルプを参考に画像情報Googleに伝えるようにしてください。

Q.サイトマップを送信したものカバレッジに反映されない

A.確認しましたが、Search Consoleに表示されています

タイムラグがあるかもしれませんがDisallowされていませんか?確認してみてください。

Q.HTTPSのSearch Consoleは追加した方が良い?重複コンテンツになりますか??

A.追加した方が良いです。

重複コンテンツによって、起こるのはどちらかのコンテンツ上位表示される可能性があるということ。

共倒れになるということはありません。

そのクエリで頭に浮かぶくらいの存在になっているかどうかです。

Q.セパレートURLにおいてMFI後のcanonicalURLの設定について

A.やはり動的orレスポンシブをおすすめします。

正規化とは同等のページ内容のURL複数あるからこそ行うもの

canonicalよりも、リダイレクトでやってみてはどうでしょうか?

Q.検索パフォーマンスデータ収集開始タイミングはいから??

A.基本的には登録前のデータも取れるはずですが、違うケースもあればフィードバックで教えて下さい。

Q.Search Consoleプロパティへの表示について、所有者として確認されてから日経ってもプロパティに表示されていません

A.何らかの判断時間がかかったのだと思います。通常は数日ですが、遅れたのは新規サイトであることが要因である可能性があることです。なにか不具合ありましたらSearch Consoleフィードバックをぜひお願いします。

Q.サイト個人情報を削除してほしい

A.かなり困っているご様子ですので取り上げましたが、当フォーラムでは対象外話題ですのでウェブ検索フォーラム送信願います

Q.max-image-preview robots meta の値を確認するには?

A.まだ反映されていないのでもうちょっと待てば反映されます

Q.Search ConsoleタイムゾーンについてPTからPSTPDTに切り替わりますか?

A.切り替わります!!

Q.ドメインを変えずにサイト名だけを変えると検索順位はどう変わる?

A.サイト名ほど大きな要素を変えてしまうのは影響すると思います

どういうサイト名に変えるのかも重要ユーザーにとってわかりやすくなるとかであれば、長期的には有効になるかもしれません。

Q.max-image-preview でlargeを設定するとDiscoverに表示されやすいと聞きましたがAMP対応しているだけでDiscoverに表示されやすくなりますか?

A.AMPでもmax-image-previewでlargeでもどっちでも対応可能です。

Q.自演対策に関する手動対策リクエスト

A.スパム対策担当者に送って適切な対応を行う予定です。

Q.クロールエラー特定できない件について、1月のオフィスアワーにてホスティング会社相談してみては?との回答で、のち、6月に検証中とのことでしたがあれからいかがでしょうか?

A.あまり気にされなくても良いです。ただ、間違ったエラーが表示されないようにするためにエンジニアも調整中ではあります

こういうエラーに気づかれましたらSearch Consoleフィードバックをぜひお願いします。

次回は10月後半か11月前半の予定です

2019-08-12

設計書を読んでプログラムを書くにも、その設計の前提知識理解がないと進まない

なので業務仕様説明理解のための時間は予め取られていた

しかにその期間で業務仕様はある程度頭に入った、けれど理解には程遠い

その後は自分担当機能実装必要知識を、その場その場で掻き集めるといった感じ、全体の仕様理解なんてカケラもできない

その後の結合テストシステムテストユーザーテストの補佐、そしてリリース後の運用フォローときて、ようやく何を使っていたか業務仕様全体像想像する程度にはなった

1年と少しかかった

振り返って思う

近々の自分仕事に関わらない情報説明されても頭にとどめて置くのは難しい

業務仕様についての2週間のトレーニングを1カ月、3カ月と増やしてもたぶん理解が大きく増えることはなかった

すぐに必要でない知識を大量に与えられても一定以上のものは受け取れないのだ

得た知識からなんらかのアクションを起こし(詳細設計実装テスト)、そのフィードバックがあることで、業務仕様理解が進むんだと感じている

2018-04-27

ロジカルからといってうまくいく訳ではないのが現実

 忙しい方向けに結論を先出しすると、

・「『正しい前提』でないと、いくらそこから説明ロジカルでも誤った結論しかでないのが上手くいかない原因」

人間論理の誤りを検出するのは得意だが、自分の見てきたものしか世界を把握できないために前提の正しさの検証が苦手

場合によっては、論理整合性を保つために現実バイアスをかけたり自分に嘘をついたりして前提をでっちあげてしまうこともある。

いくらロジカルで筋がよくても、なんかもやっとするときは前提を疑おうね。

という話です。

数学論理学をベースとした理論では論理的であれば必ず正しくなります。そこで、世間では理論に限らず様々な場所論理性を活用して物事を上手く回しているように見受けられます

しかしながら私は、とりわけBtoCの現場では論理であるからといって必ずしもうまくいくわけではないことに気付きました。そして何かを考えたり作ったりする上でロジックに全幅の信頼を置くのをやめました。

最初はこの気づきを上手く言語化出来ず、ロジックを信奉している方々になぜそうなのか説明してもなかなかうなずいてもらえなかったのですが

この度何故自分がそう考えるかの「ロジカルな」説明がおおよそ形になりました。

(尚、ここで言うロジカルとは、AでA⇒BならBだよねとかAでBだからA∧Bは真だよねなど、何かしらの真なる前提の元にそこから言えることを組み立てるという方法論をさします)

理論では、究極的な大元になる前提(公理)が存在し、それを前提に論理を組み立てることで様々なことを言っていきます

要するに「前提が正しい、論理が正しい、だからそこから言えることは正しい」なわけです。

逆にいえば、論理が正しくとも前提が誤っていればその結果は誤りうるわけで、標題の主張の根本はここにあります

現実で何か提案問題解決を行う際にも、何か前提があり、そこに論理を入れることで、結論を出すわけですが、ここで正しい前提を設定しないといくら論理の筋がよくても結論が誤ったものになります

 では正しい前提とは何でしょうか。多くの場合、主張する当人が正しいと思い、その場で意思決定をする人間がそれを否定することが出来ないことが正しい前提として扱われるのではないでしょうか。

論理学や数学における公理のようにそれ自体地球上の何億人という人間によって否定できないならまだしも、実際の現場ではたかだか数人が否定出来ないことによってそれが正しいように扱われます

言ってしまえば、その場で意思決定する人間全員が否定できなければいくら誤った前提でも通ってしまうのです。

 じゃあもっと広い人にその前提を検証するためにユーザーテスト市場調査を十分に行えば問題いかと言えばそういうわけでもありません。現実問題として潜在的ユーザー全員を調査することは困難でありますし、例え全員を調査できたからといっても、調査した人それぞれが自分感覚を正直に言葉にできるわけではありません。時には真逆のことを言ってしまうこともあります

 そういった制約のなかで、本当にその前提が正しいのかを検証することは困難です。説明論理的かどうかは多少勉強をすればわかります論理的でないことを捉えるのも簡単ですが、自分が立った前提が正しいかどうかは「少なくとも自分世界や調べた範囲では当てはまらないものがない」ということでしか検証できないため、広い世界で本当に現実に即しているかを把握することは非常に困難になります

 また、これは仕事で成果を出さなければならないという状況下で顕著ですが、筋が通っていなければ提案否定されるということを理解している人が、筋の通った説明をするために自分バイアスをかけて真実を歪める場合があります。たちが悪いのが、成果を出すこと=意見を通すこととなってしまった場合自分自身そのバイアスに本当に気づかない、または気づかないフリをすることがあるのです。

 要するに、前提が間違ってていいならロジカルであることなんて簡単で何にでもロジックをつけてしまえるということでして、本当に難しいのは正しい前提を見つけることなんです。

 だからこそ、本当に成功したいのであれば他人の「ロジカルな」説明を聞いて「ロジカルから大丈夫だろう」などと考えてはいけません。貴方が話を聞いて正しそうに感じるけど何か引っかかるのであれば、それはおそらくこねくり回された理屈の都合の悪い部分が前提に隠されているのを感覚で感じているからです。前提を疑いましょう。きっとなにか隙があります

2016-11-28

金融SIer仕事について書きたい

今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田投稿するので少し緊張している。

自分は誰かというと、金融ユーザー子会社に勤めているSEだ。いわゆる1次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。

SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの1つにすぎないものとして読んでほしいと思う。

【私の仕事について】

まず初めに、自分仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、

1.ユーザーベンダー宛てにひたすらメールを返信する

2.エクセルで作ったスケジュールWBS(タスクリストみたいなもの)を広げて眺めている

3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く

4.上司ユーザー宛へ説明する資料作成する。そして実際に説明する

これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルール作成ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。

エンジニアとしての知識について】

同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの3割が情報系、3割が情報系以外の理系、残りが文系といった印象を受ける。

はてなを見ていてWeb業界アプリ業界さらーっとIT系用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。

会社の中のほとんどの人がGitGitHubを知らないだろうし、DockerJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術貪欲でないし、それを使える環境はないし、ユーザー投資しない。

新しい技術基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら?という問いに回答できないケースばかりだからだ。だから、今動いているシステムスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。

誰も、どうしていいかからない、どこから手をつけたらいいかからないのだ。

要件定義について】

じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。

ユーザーユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチもっと金かけてやれよと思うのだが、ユーザーパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。

また、業務内容によってはミスった時のリスクがでかい特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。


やりがいについて】

毎日メールエクセルパワポとにらめっこして、ユーザーベンダーとおしゃべりして、何かやりがいはありますか?と問われると、少しだけあるにはある。

案件規模が億越え、10億とか普通な世界なので、官公庁連携したりと大きな仕事が多い。勝手ゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、

例えば「スカイツリー建設プロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな?と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。


からエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行飲み会写真ばかりだ。

一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキル必要仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的スキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有スキルを身につけてしまって、他社に転職できない状態になるのだが。)

私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。

ただ、私にはミスの許されない超絶大規模プロジェクト精神をヒリヒリさせながら、数百人月プロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。

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