UXエンジニアになりたい人のブログ エッチだってしたのにふざけんなよ! 2023-11-13T20:40:00+09:00 uxlayman Hatena::Blog hatenablog://blog/6435922169448554944 iPhone15Proのアクションボタン、ボタンなのにアクションがひとつしか設定できないのなぁぜなぁぜ? hatenablog://entry/6801883189057755872 2023-11-13T20:40:00+09:00 2023-11-13T23:13:08+09:00 いや、ほんとになんでなんだよ。意味わからんよ 普通、クリック、ダブルクリック、長押しくらいはあるろ。ていうかスイッチをボタンに変えるってほぼそれが狙いなんじゃないんか。Proモデルのみの差別化要素なのに機能性変わらんやんか そして各メディアは、カスタマイズ可能なアクションボタンが搭載ッ!クール!とかしか言わないのはなぁぜなぁぜ <p>いや、ほんとになんでなんだよ。意味わからんよ</p> <p>普通、クリック、ダブルクリック、長押しくらいはあるろ。ていうかスイッチをボタンに変えるってほぼそれが狙いなんじゃないんか。Proモデルのみの差別化要素なのに機能性変わらんやんか</p> <p>そして各メディアは、カスタマイズ可能なアクションボタンが搭載ッ!クール!とかしか言わないのはなぁぜなぁぜ</p> uxlayman デザインは論理である。絵あわせゲームではない hatenablog://entry/820878482954003460 2023-07-30T21:10:00+09:00 2023-07-30T21:10:00+09:00 ちょうど良い話があったので。見かけたので少し言及するけど、よく「イ」のパターンでアラートダイアログないしモーダルビューを作る人がいるのだけど、クローズボタンとキャンセル/OKボタンを設計としてきちんと区別するべきだし、特に深い考えがないなら、クローズボタンはこの場合無くした方が良いです。 pic.twitter.com/O62XOPpt2U— usagimaru ⌘ (@usagimaruma) 2023年7月29日 これ、自分の引用ツイで書いたけど、正解はロなんですよね。 このダイアログの目的はユーザーに進むかやめるか選ばせること。 進む/やめるが同列に扱われてるロが圧倒的正解。ハは進む/や… <p>ちょうど良い話があったので。</p><p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">見かけたので少し言及するけど、よく「イ」のパターンでアラートダイアログないしモーダルビューを作る人がいるのだけど、クローズボタンとキャンセル/OKボタンを設計としてきちんと区別するべきだし、特に深い考えがないなら、クローズボタンはこの場合無くした方が良いです。 <a href="https://t.co/O62XOPpt2U">pic.twitter.com/O62XOPpt2U</a></p>&mdash; usagimaru ⌘ (@usagimaruma) <a href="https://twitter.com/usagimaruma/status/1685178817810456576?ref_src=twsrc%5Etfw">2023年7月29日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p><p>これ、自分の引用ツイで書いたけど、正解はロなんですよね。</p> <blockquote> <p>このダイアログの目的はユーザーに進むかやめるか選ばせること。<br /> 進む/やめるが同列に扱われてるロが圧倒的正解。ハは進む/やめるが同質のUIでないのでデザイン意図が伝わりにくく不適。イはやめるボタンが2つあり混乱を招き、かつロハに対する利点が全くなくNG。二は進むやめるの選択ではないので別物</p> </blockquote> <p>異論はほとんどないくらいシンプルな話ですが、実開発でこれいうと反論されることが結構あります。<br /> 曰く</p> <ul> <li>他の画面ではハである</li> <li>モーダルウインドウはイであり、windowsやMacのウインドウも似たような物が多いのだからこれが正しい</li> <li>余計な画面要素が少なく、適当に押してても操作継続できるという点で二が一番良いのでは</li> </ul><p>などなど。ひどいのになると競合他社はどうだとかNetflixはどうだ(なのでそれが正しい)とか言い出す人もいる。</p><br /> <p>こういうことを言い出す人はデザイン成果物を絵と捉えているフシがあるようで。<br /> 絵が似ている、絵として統一感がある・ないという発想。自分が好きだ、嫌いだ、みんなこれが好きに違いない、流行ってる、美的感覚でいうとどうだ、などなど。</p><p>しかし、言うまでもなくダイアログとモーダルウインドウはその存在目的が異なる。Yes/Noを選択させるUIと単に情報を提示するだけのUIも別物である。<br /> UIはシステム上の目的を達成させるための手段であり、最大多数が最も認知しやすい形態を取るべきだ。<br /> 〇〇な目的なので、XXで有ることを認知しやすいこういう形やレイアウトにして、〇〇の目的を間違いなく達成できるようにする、と論理展開できるはずだし、出来ないのは間違いである。その展開に「より穴がない」のが良いUIということになる。</p><p>冒頭に上げた例はロ以外は妥当な論理を構築しにくい/ロを上回る論理展開ができないから、正解はロと言い切れる。</p><p>この、ちゃんと論理展開できるというのは基本中の基本であるし、最低レベルのルールである。われわれは芸術品を作っているのではないのだから。<br /> どうしてそれが良いのですか?と聞かれて明確に答えることができない人間はデザインを語る資格がない。<br /> でもどういうわけかそれができない人は一定数いて<a href="#f-1cacdb2e" name="fn-1cacdb2e" title="冒頭のTweet界隈ではあんまり変なこと言ってる人いなかった。Twitter民はまあ優秀なのかな?">*1</a><a href="#f-fdf6d94e" name="fn-fdf6d94e" title="こういう傾向があるのは、世の中のデザイナー職は絵合わせ・美的センスが問われるもののほうが圧倒的に多いからなのだろうと思う。情報システムのデザイナーだけかなり特殊であるとも言える">*2</a>、正直話す価値すらないので、情報デザイン技師みたいな資格なりなんなりで弾いてほしいという今日このごろである。</p> <div class="footnote"> <p class="footnote"><a href="#fn-1cacdb2e" name="f-1cacdb2e" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">冒頭のTweet界隈ではあんまり変なこと言ってる人いなかった。Twitter民はまあ優秀なのかな?</span></p> <p class="footnote"><a href="#fn-fdf6d94e" name="f-fdf6d94e" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">こういう傾向があるのは、世の中のデザイナー職は絵合わせ・美的センスが問われるもののほうが圧倒的に多いからなのだろうと思う。情報システムのデザイナーだけかなり特殊であるとも言える</span></p> </div> uxlayman Gitは人類には早すぎる hatenablog://entry/26006613800328605 2022-05-19T20:30:00+09:00 2022-05-19T20:30:04+09:00 3行まとめ Gitは、思慮浅い下々のわれわれがしょうもないシステムの変更とリリースを管理する、というシンプルな目的に対しては難しすぎる。 特に妥当なマージ戦略がひとつに定められないことが致命的すぎる。 PullRequestのメリットだけを享受できるシンプルなSCMが出てきてほしいな。 ローカルリポジトリがファイルシステムで表現されるというわかりにくさ えっそんなところから?という声が聞こえてきそうだが、そんなところからなのだ*1。 この基本的なとこでつまづくひとはかなり多いし、その場合の説明が超面倒くさい。 PCを理解しているほとんどの人にとってファイルシステム上のファイルこそが永続的なもの… <h4>3行まとめ</h4> <p>Gitは、思慮浅い下々のわれわれがしょうもないシステムの変更とリリースを管理する、というシンプルな目的に対しては難しすぎる。</p> <p>特に妥当なマージ戦略がひとつに定められないことが致命的すぎる。</p> <p>PullRequestのメリットだけを享受できるシンプルなSCMが出てきてほしいな。</p> <p> </p> <h4>ローカルリポジトリがファイルシステムで表現されるというわかりにくさ</h4> <p>えっそんなところから?という声が聞こえてきそうだが、そんなところからなのだ<a href="#f-e9130815" name="fn-e9130815" title="厳密にはローカルリポジトリとワーキングツリーは別物だが素人視点の話なのでそんなところに突っ込むなかれ">*1</a>。</p> <p> </p> <p>この基本的なとこでつまづくひとはかなり多いし、その場合の説明が超面倒くさい。</p> <p>PCを理解しているほとんどの人にとってファイルシステム上のファイルこそが永続的なもので「裏に謎の仕組みが潜んでいて永続的であるはずのファイルがコロコロ切り替わる」というモデルには馴染まないのだ。天才たちはすぐに新概念を理解できるかもしれないが、凡人は既成概念に囚われるのだ。ファイルは虚像で、本体は.gitの中にしかない、なんていうまどマギみたいな話はビビるのだ。</p> <p>zipファイルをダウンロードしてフォルダに解凍するように、リポジトリをcloneしてフォルダにcheckoutできるようにすればよかった。フォルダとブランチが1対1のほうが全然よかった。フォルダの数=ローカルリポジトリでの展開ブランチ数となったほうが全然わかりやすかった。</p> <p>しかも、ワーキングフォルダ内のファイル群が完全に切り替わるならまだしも、git add前のファイルは継続配置され続けるところが更に誤解を生みやすい。ローカルで保存しといたはずのファイルが消えちゃいましたとかって悲劇が生まれる。</p> <p>最初のつまづきだけならまだしも、この辺の仕組みが実は理解できてなくてなんか起こるたびにcloneからやり直す、みたいな人も一定数いるように思う。</p> <p> </p> <p>もちろん、現状のモデルもデフォルトでディスク利用量が少なくなるなどのメリットはある。毎日数十もの新ブランチを確認しなければならないなら速度的メリットも大きい。しかし、そういうのはオプション化してマニアックな人だけが使えば良いとおもうのですよ。 </p> <p> </p> <h4>ツリーが見れねえ</h4> <figure class="figure-image figure-image-fotolife mceNonEditable" title="https://www.atlassian.com/ja/git/tutorials/using-branches"> <p><img class="hatena-fotolife" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20210823/20210823152035.png" border="0" alt="f:id:uxlayman:20210823152035p:plain" title="" loading="lazy" /></p> <figcaption class="mceEditable"><a href="https://www.atlassian.com/ja/git/tutorials/using-branches">https://www.atlassian.com/ja/git/tutorials/using-branches</a></figcaption> </figure> <p>Gitブランチの解説文にはたいてい上のような図が載っているが、こういうきれいなツリーを表示するツールがない。</p> <p>ほとんどの開発者はメインブランチdevelopから分岐したfeatureの担当であり、developとfeatureの状況を同時に見たいはずだ。developを幹として、featureを枝として。大抵の場合たくさんのブランチが並行しているのでブランチを絞りたい。大抵の場合たくさんのコミットがメインブランチに行われているので分岐近辺以外は省略してみたい。</p> <p>できない。なんでや。</p> <p> </p> <p>いまんとこ一番理想に近いのはVS Code拡張のGit graphかな?ほとんどのツールはなぜか2つのブランチだけに絞って表示することすらできない。</p> <p>Gitはややこしいのでさまざまな状況でツリーを表示させて自分の意図通りの構造かを確認したくなるはずだ。あまり理解していないならなおさら実地で確認すべきだ。でもその構造をいい感じに確認するツールが少ない。</p> <p>かくしてGitのブランチ構造を深く理解する術は失われ、いつまで経っても、〜なんとなくコミット・プルリク・競合で大慌て〜の状況は繰り返される。</p> <p> </p> <h4>マージするまでどれが競合するかわからなくて(※)競合状態をとりあえずもとに戻すのが大変(※)</h4> <ul> <li>マージしてみないと競合するかわからないので(※)、とりあえずマージする</li> <li>マージして競合モードになるけど直せない(※)</li> <li>なんとか競合を解除して、いざpushしようとすると↑18とかでてて、ええ?18回もコミットしてないのに大丈夫か?と不安になる</li> <li>なんとか競合を解消したつもりでいても、GitHubでマージできる状態になってるかローカルでは確認できない(※)</li> </ul> <p>こんなふうにして大混乱する。実際は※ついてるところは間違いなんだけど、詳しい知識がないと対応できない。</p> <p>で、一番ヤバいのは、マージ作業自体はほぼほぼコード作成者本人しかできない、ってとこ。誰かがヘルプしたとしても、ここ変えた?変えてない?って考えてどっち採用するか決めるのは本人しかできない。詳しい人が巻き取ることはできない。マージの競合なんてしょっちゅう起こる作業のたびにこういうことで混乱する。</p> <p>どうにかならんものか。競合を起こさないような運用<a href="#f-16fdd2e7" name="fn-16fdd2e7" title="〇〇は私が更新するまでだれもコミットしないで、と宣言するとか">*2</a>みたいな意味不明なルールを決めることとかもある。うそぉ?と思うかもしれないけど、マジです。</p> <h4> </h4> <h4>解説がコマンドばかり/いいGUIツールがない</h4> <p>こう書くとマウント野郎がCLI使えないやつは素人、とか言いだしそうだが素人だしこんなもののプロになりたくないので放っておいてください。ていうかGitをCLIだけでやるって実用上可能なの?diffとかつらくない?</p> <p> </p> <p>で、決定版のツールが全然ない。一番まともでマルチプラットフォームなのはSourceTreeか?でもまだ不十分。</p> <p>ツールによって翻訳が入ったりコマンドとの対比内容が違ったりで同じことが違う表現になっててわかりにくいことこの上ない。</p> <p>結局求められるのはツリーの見やすさと競合解消のしやすさだが、決定版がない。Windows民はトータスGitしか使えないこともおおい。ググればコマンドばかりで自力で成長できない。</p> <p>そもそも、もとはといえばgitコマンドの構成がわかりづらいのが原因の部分も多いので将来にわたって改善しなさそうなとこがつらい。</p> <p> </p> <h4>(重要)マージ戦略問題</h4> <p>今までの話は、単に勉強不足だと言って切り捨てることができるだろう。</p> <p>しかしこれは違う。宗教論争だ。一般にmerge vs rebase論争と言われている?のかな?知らんけど。ただしこれはmergeとrebaseだけの話ではなくて多くの問題を含んでいる。</p> <ul> <li>squashをすべきか</li> <li>push -fを許すべきか。許す場合はどのようなブランチや状況に対して許すべきか</li> <li>歴史改変をどこまで許すべきか。特にコードレビューへの対応記録など。また、改変後の粒度はどうあるべきか</li> <li>マージの反映はgithubなど中央リポジトリの機能で行うのか自力で行うのか</li> </ul> <p>merge派の極みは、一切のrebaseをせずmergeのみで競合を解決するというもの。rebase派の極みは、ブランチでのすべての変更をsquashしてマージ直前のコミットからrebaseするというもの(すべてが下記のようなコミットツリーになる)</p> <pre>* Merge branch 'branch3' into 'develop' @user1 |\ | * Fix zzz |/ * Merge branch 'branch2' into 'develop' @user1 |\ | * Fix yyy |/ * Merge branch 'branch1' into 'develop' @user1 |\ | * Fix xxx |/ * </pre> <p> </p> <p>前者はコミットツリーが汚くなりすぎて何がなんだかわからなくなりがち。後者はあらゆる履歴が1つにまとめられるので経緯情報が失われる。</p> <p>結局のところ、起こったことはすべてそのまま記録すべき(経緯が大事)派と、なにをもとになにを修正したかを明快にすべき(結果が大事)派の争いであり、どちらも正しい。だからタチが悪い。</p> <p> </p> <p>大抵はrebase派のほうがGitに詳しくてmerge派はrebase派の言っていることが理解できてないことも多い。しかし、rebase派は当然のようにpush -fの使用を強制するためmerge派からすると「ただでさえ難しいGitのさらによくわからない手順を覚えた上で禁忌とされる『他人のコミットを壊す』恐怖に怯えなければならない」ため受け入れ難い。</p> <p>これでさらに、rebase派が煽り気味にマウントとったりすることもまれによくあるのでろくなことにならない。そして根本的にどちらの言ってることも正しいので全然落とし所がみつからない。嗚呼なぜこんな苦労をせねばならんのか。</p> <p> </p> <h4>分散リポジトリなんて誰もつかってねーじゃねーか問題</h4> <p>gitは分散リポジトリなので、中央集権サーバーを持たずにお互いpull pushをして同期し合うモデルが可能だったはずだ。</p> <p>こういう運用をしてたことがあったのかは知らないが、2022年現在、ほぼ全ての人がサーバークライアントで使ってるだろう。githubみたいな「originたるサーバー」と、自分だけのローカル。</p> <p> </p> <h4>結局GitじゃなくてGithubの機能じゃねーか問題</h4> <p>Git管理で最も役に立つ機能はプルリクエストだろう。安心安全なシステム開発にあたって変更をコントロールしレビューの強制を実現できる仕組みは素晴らしい。ほとんどの人はプルリクレビューのためにGitを使っているのではないかとすら思う。</p> <p>先に示した運用ルールに則したマージ戦略の徹底やPRを介さない直接pushの禁止、歴史改変の禁止などをブランチ単位でコントロールできる機能は、開発現場の秩序維持にとても役に立つ。</p> <p> </p> <p>素晴らしい。しかしこれらは全部GitHubの機能じゃねえか!GitHubなかったら分散という名のただのややこしくて理解しづらい仕組みじゃねえか!</p> <p> </p> <h4>ブランチのメンタルモデルからの乖離</h4> <p>Gitをよく知ってる人ならご存知なように、ブランチは「枝」という名前ではあるが、実際には全然枝じゃ無い。コミットである。</p> <p>ほとんどの人がメンタルモデルとして枝分かれの樹形図をイメージするが、実際はコミットをたどることによって「結果的に」ツリーが構築されてるにすぎない。</p> <p>樹形図表示ツールの決定版が出てこないのも、樹形図を分岐や結合に絞ってうまく意図とあうように表示しにくいのも、根本的にはこれが影響している。このモデルはGitの核であるため一生解決しないことがほぼ確定である。つらい。</p> <p> </p> <h4>コミットIDがハッシュ</h4> <p>いやわかるよ。Gitにとってハッシュこそが肝なのはさ。</p> <p>でもあえて言わせてもらおう、ブランチ名+連番とかでコミットが一意に表せてほしい。rev123まで戻して再デプロイして!とか言いたいのだ。df87aj2まで戻して!とかなんやねん伝えにくいわ</p> <p> </p> <h3>まとめ/結局なにがしたいのか</h3> <p>原点に立ち返って考えてみよう。</p> <p>多くの人にとってGitは手段である。安全安心なソフトウェアを作ることが目的で、そのために変更管理が必要だ。変更管理(とそれにまつわるレビューや承認や修正の管理)をしやすくしたいのである。</p> <p>その目的に対して、Gitは難しすぎる。メンタルモデルと実体は合わないし、メンタルモデルを正確に反映するGUIツールはないし、どちらも正しいが相反する2つのマージ戦略がある。</p> <p>われわれは、Gitについて詳しくなりたいわけではない。さいきょうのGitFlowを作りたいわけでもない。Gitが開発者の嗜みの一つとして当然のように存在することでシステム開発の間口が狭くなることを憂慮している。</p> <p>どうしてたかがソース管理のためにこんな難しいものを理解しなければならないのか。欲しい機能はプルリクレビューだけだ。ブランチ作るのが早いsvnがあればそれでも全然いい。</p> <p>Gitは神が戯れにつくったツールで、人類に広く普及するには早すぎる。</p><div class="footnote"> <p class="footnote"><a href="#fn-e9130815" name="f-e9130815" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">厳密にはローカルリポジトリとワーキングツリーは別物だが素人視点の話なのでそんなところに突っ込むなかれ</span></p> <p class="footnote"><a href="#fn-16fdd2e7" name="f-16fdd2e7" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">〇〇は私が更新するまでだれもコミットしないで、と宣言するとか</span></p> </div> uxlayman redmine使えないヤーツ hatenablog://entry/17680117127171454999 2021-07-19T20:30:00+09:00 2022-02-28T21:13:52+09:00 最近、猫も杓子もredmineじゃないですか。そうでもないですか。そうですか。redmine使い始めると現れる困った人についてまとめます。*1 利用者編 ステータス変えない とても多い。コメントは書くが、ずっとステータスを新規(初期状態)のままにしておくヤーツ。 なぜそんなことになるか理解できない。どれが終わってるのか自分でわからなくて困らないのか。 進捗率変えない ステータスは完了にするが、進捗率は100%にしないヤーツ。 これはシンプルにredmineの設計が悪い。完了したら100%になるのは当たり前だ。プラグインで解決できる問題なので導入すべし。 なんでもチケットに書いちゃう 明日打ち合… <p>最近、猫も杓子もredmineじゃないですか。そうでもないですか。そうですか。redmine使い始めると現れる困った人についてまとめます。<a href="#f-f3dd587a" name="fn-f3dd587a" title="「出、出〜redmine使いこなせな奴〜」というタイトルにしようと思ったが、このフォーマット自体がかなり死語なのでやめた。最近とんと聞かないな">*1</a></p> <p> </p> <h3><span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif;">利用者編</span></h3> <h4>ステータス変えない</h4> <p>とても多い。コメントは書くが、ずっとステータスを新規(初期状態)のままにしておくヤーツ。</p> <p>なぜそんなことになるか理解できない。どれが終わってるのか自分でわからなくて困らないのか。</p> <p> </p> <h4>進捗率変えない</h4> <p>ステータスは完了にするが、進捗率は100%にしないヤーツ。</p> <p>これはシンプルにredmineの設計が悪い。完了したら100%になるのは当たり前だ。プラグインで解決できる問題なので導入すべし。</p> <p> </p> <h4>なんでもチケットに書いちゃう</h4> <p>明日打ち合わせしましょう、とか、後で電話します、とかまで書いちゃうヤーツ。いやチケットの事象がどうなるかだけ書いてよ。</p> <p> </p> <h4>結論書かない</h4> <p>なんでもチケットに書いちゃうヤーツと同類であることが多い。</p> <p>結局対面の打ち合わせで自分は納得して満足して、結果を書かない。外から見るとチケットの事象がどうなってるかわからない</p> <p> </p> <h4>話コロコロ変える</h4> <p>redmineは1事象1チケットが基本であるが、コメントの途中で「そういえば〇〇はどうなんです?」などと違う話を始める。</p> <p>別件としてチケットを切ってください、と何度言われても繰り返すのが特徴。受け手は話変えられたとしてもチケットで返答するしかないのでタチが悪い。</p> <p>この手のヤーツはツールによらずその傾向がある。メールでも話をまぜこぜにして今いくつ話が進んでるかわからんことになりがち。</p> <p> </p> <h4>コメントが死ぬほど長くなる</h4> <p>100とか超えちゃう。常識で考えて、1つの事象に対して100回もやりとりが発生する可能性は薄く、なにかをまちがえている。基本的に話コロコロ変えるヤーツが違う話を延々と続けてるパターンが多い。</p> <p> </p> <h4>別管理してしまう</h4> <p>メールにTODOフラグつけるとか、印刷した紙に付箋つけて管理するとか、自分用Excelをローカルに持ったりとかしてそっちでステータス管理してしまう。</p> <p>ので、redmine側ではステータス変更しないヤーツになってしまう。</p> <p>文明の利器をつかいこなして!</p> <p> </p> <h3>管理者編</h3> <h4>ライフが長いチケットを作ってしまう</h4> <p>バグが発生してから、直して、レビューして、修正確認して、QA確認して、リリース決めて、、、、という流れを1つのチケットでやろうとしちゃうヤーツ。高機能なバグトラッカーから移行した人がやりがち。redmineはチケット設計にかなり自由度があるので、こういう設計も間違いではないが、チケットのライフが短いことを前提に終わった終わらないを管理するプラグインが多いため、プラグインエコシステムをフルに享受できない可能性が高い。</p> <p>ライフが長くなると当然フェーズごとに担当者が設定されるため、〇〇担当者というカスタムフィールドが増えて一覧性検索性も悪くなりがち。</p> <p> </p> <h4>超複雑なステータス遷移ルールにしてしまう</h4> <p>ライフが長いチケット作るヤーツにありがち。newからいきなりcloseに行けないように、などのルールを厳密に作りすぎる。</p> <p>大抵例外系をすべて網羅できずに死ぬ。</p> <p>しかし作り手的には「ぼくがつくったさいきょうのフロー」という自負があるため面倒なことになりがち。</p> <p>ちなみに、利用者にとって「問題は解決してるのにわけのわからんシステムのせいで自分の手から離せない」というは非常に大きなストレスである。</p> <p> </p> <h4>管理Excelを自前で作って抱え込む</h4> <p>redmineのデータをエクスポートして色分けしたりグラフ化したりする便利ツールを作ってしまう。</p> <p>そこには情報が集まっているので書き漏れや納期遅れなどは<strong>その人には</strong>わかる。だから毎日毎日みなの不備を指摘するredmineおじさんとなる。</p> <p>本人は開発プロセスを下支えするスーパーパーソンのつもりだが、利用者側としては毎日毎日ちまちま指摘されてウザい。状況を改善したとしても、本当に改善されたかはちまちまおじさんしかわからないのでストレスが溜まる。</p> <p>もちろん改善されたはずのものが実は改善されてないとちまちまおじさんは怒り出すので、さらに厄介なことになる。</p> <p>ツールは共有して誰もが恩恵を享受できるようにしましょう(ただしやっつけで作ったツールで本人以外にはまともに使えないというパターンは大いにある)</p> <p> </p> <h4>自分が思うredmineの使われ方がされないと、文句を言い出してしまう</h4> <p>おっと最後に特大のブーメランが。redmineはこう使うに決まってるでしょ、とか、そんなこともわからないんですか?などと上から言ってしまう。</p> <p>どんな利用者であっても、そもそもプロジェクトの関与者は敵ではなく協力者である。それぞれの関与者にはそれぞれの仕事がある。ツールを使いこなすのが仕事ではない。だれもが進捗管理ばかりしているわけではない。</p> <p>くだらない上から目線のせいで心象を概して、どれがマスターなのかもわからないExcel地獄に戻りたいのか? リスペクトを忘れるな!</p><div class="footnote"> <p class="footnote"><a href="#fn-f3dd587a" name="f-f3dd587a" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">「出、出〜redmine使いこなせな奴〜」というタイトルにしようと思ったが、このフォーマット自体がかなり死語なのでやめた。最近とんと聞かないな</span></p> </div> uxlayman みずほの障害報告書が面白い件 hatenablog://entry/26006613776906773 2021-06-22T08:00:00+09:00 2022-02-28T21:13:52+09:00 6/15に今年2月から3月に連続して起きたみずほのシステム障害調査報告書が発表されました。部外者からすると結構読み物として面白く、また示唆に富んでいるので感想を書きます。 自分がアプリエンジニアなのでその方面の観点が多め。 www.mizuho-fg.co.jp あらすじ(P.36) 2/28 9:50に大量データ登録によって定期性預金システムにおける取消情報管理テーブルがDiskFull(実際はオンメモリのINDEX格納領域の不足)になって全死 → 取消情報管理テーブルが全死なので、定期性預金トランザクションの取消そのものができなくなる(2重エラー) → この2重エラー状況を検知した上位シス… <p>6/15に今年2月から3月に連続して起きたみずほのシステム障害調査報告書が発表されました。部外者からすると結構読み物として面白く、また示唆に富んでいるので感想を書きます。</p> <p>自分がアプリエンジニアなのでその方面の観点が多め。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.mizuho-fg.co.jp%2Frelease%2F20210615release_jp.html" title="みずほFG:システム障害特別調査委員会の調査報告書の受領について" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.mizuho-fg.co.jp/release/20210615release_jp.html">www.mizuho-fg.co.jp</a></cite></p> <h4>あらすじ(P.36)</h4> <p>2/28 9:50に大量データ登録によって定期性預金システムにおける取消情報管理テーブルがDiskFull(実際はオンメモリのINDEX格納領域の不足)になって全死</p> <p><span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif;">→ 取消情報管理テーブルが全死なので、定期性預金トランザクションの取消そのものができなくなる(2重エラー)</span></p> <p><span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif;">→ この2重エラー状況を検知した上位システムにより防御機構が作動し、ATMやダイレクトチャネルの流量制限が行われる</span></p> <p><span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif;">→ 流量制限されたATMでカード飲込みが発生</span></p> <figure class="figure-image figure-image-fotolife mceNonEditable" title="障害の概要"> <p><img class="hatena-fotolife" title="" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20210619/20210619195222.png" alt="f:id:uxlayman:20210619195222p:plain" width="570" height="337" /></p> <figcaption class="mceEditable"></figcaption> </figure> <p> </p> <h4>おもしろポイント1:初動の暫定対応を完全にミスっている</h4> <p>システムには2種類の防御機構があったようである。</p> <p>1つ目は、1系統で同じサービスが30回エラーになったら、そのサービスそのものが使用できなくなるようにメニューから自動で消す「取引サービス禁止機能」(P.51)。今回だと、定期性預金サービスが全死なので、ATMのメニューから定期預金関連のメニューが消えていった。なんかちゃんと動いてないサービスあるからそれ使えないようにしといたろ、的なヤツ。</p> <p>2つ目は、2重エラー(≒パーコレートエラー)が5回発生したときに、そのきっかけとなった処理区画を自動で閉じる機能(P.46) 。なんかシステム全体ヤバそうだから入り口を閉めて全体に負荷かからないようにしたろ、的なヤツ。</p> <p>なお、システム全体は3系統あり、1系統ごとにATM処理用に20区画が用意されているとのこと。多分1区画ごとに複数個のトランザクションを走らせることができると思われる。「系統」は全く同じシステム構成が3個ある(負荷分散と可用性確保用)と思われる。そのへん詳しく書いてなかったのでわからんが。</p> <p> </p> <p>で、今回は前述のように定期性預金サービスが全死だったので、もしなにかするなら、前者の防御機構を強めてなるべく皆が定期預金系サービスを使えないようにする必要があった。</p> <p>が、あろうことかこの制限を30回→999回に緩めてしまった。この結果、皆が(抑制されていた)定期預金系サービスをつかえるようになって、それが全部エラーになって、後者の防御機構発動→ATMの停止祭り、となってしまった。</p> <p>障害の真っ只中で混乱はあったのだろうが、それを差し引いても無能な対応だったと言わざるを得ない。なお、作業の指示と実行は11:37-12:08の期間で行われているが、11:30の時点で(定期性預金サービス内の)DBのDiskFullという根本事象が常務に報告されているので、この時点で常務に整然と報告できるほどに根幹は見えていたと思われる(P.38)。</p> <p>なのになぜw この失敗が致命的である旨が報告書で数パターンのグラフwで示されており(P.41,53)、そのあと結局定期性預金サービスは完全に切り離したので、この措置矛盾しすぎだとか、昔うまく行った記憶をもとにノリでやりました的なこともバラされていて(P.76)もはやフルボッコ状態ww この指示者の行く末が気になるところである。</p> <p><img class="hatena-fotolife" title="" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20210619/20210619195352.png" alt="f:id:uxlayman:20210619195352p:plain" width="584" height="367" /></p> <h4>おもしろポイント2:根本事象解決後、ATMが回復しなくて大混乱</h4> <p>本件、先に述べたとおり根本事象はDBのDisk(オンメモリ格納領域)Fullである。領域拡張が終わったのが14:54、これを利用する定期性預金性サービスを16:22に再開完了している(←起動に1時間半もかかるのな)。</p> <p>どうもここで一旦障害対応が終わったと思ってたフシがある。16:37から障害の過程でロックされた顧客ファイルの解除を試みており、つまり事後処理を始めてることが見て取れる。</p> <p>一方、ようやく防御機構2によってATM処理区画が閉塞がされてたことを認知したのは17:10である。この間、だいぶ混乱したんだろうなあと。「ダメです!ATM回復しません!」「そんなバカな」みたいな。エヴァかな?ぜひ再現ドラマを作って欲しい。</p> <p>こういう安堵からの再混乱みたいな話好きなんですよね。完全に他人事だから言えますが。</p> <p> </p> <p>思うに、対応担当者は防御機構2(パーコレートエラー検知によるATM閉塞)を知らなかったのではないかな?定期性預金でのエラー→ATMの閉塞と直接的に考えたのではないだろうか。なので、定期性預金のエラーが検知されないようにするために、おもしろポイント1の対応を行ったのではないかと。</p> <p>まあ実際にはエラーが検知されないようにする対応ですらなかったわけで、やっぱり草生える対応なわけですがw</p> <h3>原因と"現実的な"再発防止対応を</h3> <p>報告書にはさまざまな側面における原因が記載されている。</p> <p>原因DiskFullだったわけなので、当然「DiskFullになる可能性を予期してレビューや事前確認を行うべきだった」てのは出ると思うんです。が、これ現実的じゃないと思うんですよね。インポート対象のテーブルがDiskFullになったのならともかく、「定期性預金サービスの、共通処理を担う取消情報テーブルの、INDEX領域がオンメモリに格納されかつそれが当日の処理量に応じて増加する性質に基づき、さらにメモリ利用量の監視警告が見逃される可能性」を予期できるか?という。</p> <p>ひとはいつでも間違いを犯す、という観点に立つとあらゆる内容をルール化するとか運用体制をガチガチにしばるのもあまりイケてないなあと思います。間違いを犯しても大丈夫な仕組みを構築することが大事と思うのです。</p> <p>なのでその観点でこれはできたやろという"現実的"な対策を2つ上げたいと思う。</p> <h4>1.カード飲み込み条件の変更</h4> <p>ま、これよね。P.69の原因(オ)として記載がある。前述の通り防御機構は2種類あって、定期サービスやばいから定期サービス止めとこ、と、なんかわからんがやばいから全部止めとこ、の2つ。</p> <p>その内訳が↓(P.47) </p> <p><img class="hatena-fotolife" title="" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20210619/20210619195457.png" alt="f:id:uxlayman:20210619195457p:plain" width="569" height="312" /></p> <p>要は、「なんかやばいから全部止めとこ」の方で引っかかって飲み込まれた人が4915件と大多数。</p> <p>この後者のほうがカード戻す仕様であれば、障害数が5244→329件に抑えられた上に、「定期預金サービスでエラーが発生したので、定期預金サービスを使おうとしたお客様の資産保護のためにカードをお預かりしました」と一応辻褄がある説明ができたはずなのだ。</p> <p>最もあかんのは、過去3回も同様のトラブルを起こしていた(P.69)のになにもしてなかったこと。この大障害の発生後に速攻直した(P.133)らしいけど、なんだ速攻直せるんだな、最初からやっとけやそういうとこやぞと思わなくもない</p> <p>人間だから、悪い仕様に気づけないことは多々あるだろう。でも同じトラブル3回も起こしたら、さすがになんかおかしいと気づけよ、と思う。</p> <h4>2. フェイルセーフ機能のテスト不足</h4> <p>P.67(イ)として記載あり。</p> <p>原因は定期性預金サービスの取消情報テーブルがDiskFullになったことである。明確に記載がないが、おそらくなにか処理を実行する前、最初に実行前情報をコピーしておく(そして戻せるようにする)情報テーブル/機能だと思われる。(DBのロールバックが効かなかったときの保険的機能である旨の記載がある)</p> <p>それで、この最初の処理が死んでたので事実上なにもできない状態だったと。処理エラー時に整合性が失われたか否かを返す機能があり、それを元に取消を行うか否かを判断しているのだが、それがバグってて常に取消処理を要求するようになってたとのこと。そしてその取消処理もコケるので2重エラー≒パーコレートエラーとなって、ATM閉塞を招いたと。</p> <p>ここも、うまく動いていれば、障害数が329件で定期預金サービスを使おうとしたお客様のみへの影響で抑えられたはずなのだ。</p> <p>取消情報テーブルの名のごとく、これはシステムがなんかやらかしちゃったときの最後の防御機能なので、特に重点的にテストすべきだったし、SPOFとなりえる点も踏まえるとオンメモリINDEX保持への設計変更も慎重にすべきだったように思う。</p> <p> </p> <p>ここが原因だったから云々じゃなくフェールセーフ機構だからという観点が大事。</p> <p>人間はいつでも間違える、だからフェールセーフがある。そのフェールセーフがさらに間違えないように狙いを絞って慎重にレビューとテストをすべきだった、と思う。</p> <p>---</p> <p>人はいつでも間違える。締め付けて管理すれば何でもできるわけではない。未来をすべて予測できるわけでもない。だから、間違いに気づいたら改善しよう。間違いが起こっても大丈夫なような仕組みだけはしっかり作ってみんなで保証しよう。</p> <p>この辺がうまくできてなかったんだろうなあと思うし、これがうまく回るような"現実的"でシンプルなルールができれば良いと思う。間違ってもチェックリストが何十枚にもなるとかそういう無理ゲーな対応になりませんように。</p> <p> </p> <h3>ネット上の指摘への対応</h3> <p>みずほの話になるとなぜかネット上で知ったかして適当なこという人が増えるのでそこへのコメントを。</p> <h5>20万人月のあのシステムがまだ未完成なんだろ/バグだらけなんだろetc</h5> <p>あらすじ部分にも書いたように、特定サービスのDB DiskFullが原因であり20万人月システムことMINORIのバグではない。</p> <p>報告書要旨版の原因欄の一番上にも「MINORIの構造、仕組み自体に欠陥があったのではなく、これを運用する人為的側面に障害発生の要因があった」とはっきり書かれている。</p> <h5>2週間で4回も障害を発生させるとか無能の極みすぎる</h5> <p>実は最初の1回以外、残り3回のうち2回はハードウェア故障を検知して自動切り替えしたという事象で、どちらかというとうまく動いた事象である。</p> <p>残り一回は初歩的なプログラムミスだが、まあ正直よくある話で、全部一緒にして4連続障害として叩かれたのはかわいそうに思う。</p> <h5>藤原頭取の責任問題</h5> <p>めちゃくちゃある。</p> <p>リーダーシップのリの時もみえない。公式な緊急対応体制が構築されたのが事象発生から7時間以上経ったあとという1点のみで辞任はやむなしである。全く危機管理体制が機能していない。就任から3年以上こんな感じだったのに、再発防止策の徹底のために続投とか片腹痛い。この報告書書いた人に頭取になってもらえ</p> <h5>当日の対応内容(誰も個人として組織横断的アクションを取らない)がありえない</h5> <p>まあ、わかるよ。言いたいことは。</p> <p>でも有事に断片情報を元に本当に正しい行動を取れるだろうかと。顧客に情報を伝えるにしても、それが間違っていた場合どうすれば、などまで考えるとなかなか動き出すのはつらそうなのもわかる。</p> <p>個人的にはこれ系のアプローチよりも問題そのものが起こらなくできたり局所化できたりできるように仕組み作ってくべきなんだろうなと思う。</p> <h5>DBがバラバラで運用が大変そう</h5> <blockquote class="twitter-tweet" data-conversation="none" data-lang="ja"> <p dir="ltr" lang="ja">みずほ銀行のシステム障害、データベースの運用ミスが障害の発端だったんですが、これだけDBがバラバラだと、そりゃあ運用も大変かと。詳細は記事をご覧下さい <a href="https://t.co/WRUEd5JN54">https://t.co/WRUEd5JN54</a> <a href="https://t.co/GE984QR1F0">pic.twitter.com/GE984QR1F0</a></p> — Atsushi Nakada (@Nakada_itpro) <a href="https://twitter.com/Nakada_itpro/status/1404935352263970816?ref_src=twsrc%5Etfw">2021年6月15日</a></blockquote> <p> <script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p> たしかにDBがバラバラで運用が大変そうだが、今回の直接の事象とDBの多様性は関係ないように見える。</p> <p>が、そもそもの根本事象である取消情報管理テーブルのINDEX FILE容量超過。報告書内に何度も書かれているように、テーブル本体ではなくてINDEXだけがメモリ上に常駐しているらしい。そして、前日分のINDEX容量は退避されて、当日の処理量に応じてINDEX容量が増えるらしい。これって普通のDBMSでできる話なんですかね?いまいち直感に反する話なのですが、前日分までが退避領域(HDD,SSDなど)にあって当日分だけがメモリにあって、それらが透過に扱えるってこと?そういうの、今は普通なの?</p> <p>そもそも取消情報管理テーブルの名前からして一時テーブル(グローバルトランザクションの生存期間でのみ有用な一時データ)みたいなイメージですが、それが日をまたぐ事があるってこと?いまいちよくわからない。このへんの「わからなさ」がDBMS固有の機能だったり固有の設計制限であったりするなら、多様なDBMSを運用している副作用かもしれない、とは思いました。</p> <p><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20210621/20210621221311.png" alt="f:id:uxlayman:20210621221311p:plain" width="842" height="423" loading="lazy" title="" class="hatena-fotolife" itemprop="image" /></p> <h3>その他</h3> <p>パーコレートエラーってなに?</p> <p>どうみても専門用語(IBM用語?)なのになんの解説もない。最初は2重エラーのことかと思ったけど、2重エラーのようなシステム全体の非安定稼働を想起させるような重大なエラー/イベントのことっぽい</p> <p> </p> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="「みずほ銀行システム統合、苦闘の19年史」が普通に称賛案件だった件について - UXエンジニアになりたい人のブログ" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fuxlayman.hatenablog.com%2Fentry%2F2020%2F02%2F28%2Fmizuho" frameborder="0" scrolling="no"></iframe><cite class="hatena-citation"><a href="https://uxlayman.hatenablog.com/entry/2020/02/28/mizuho">uxlayman.hatenablog.com</a></cite></p> <p> </p> <p> </p> <p> </p> uxlayman COCOAに望むたった一つの追加機能 hatenablog://entry/26006613718436794 2021-05-03T21:14:09+09:00 2022-02-28T21:13:53+09:00 少し前にCOCOAの報告書でてました。 一番びっくりしたのはテストを効率化するためにパラメーターを調整(Minimum Risk Score を「1」に設定)してたという記述で、それもうテストじゃないし、何を作って何をテストした認識なんだよ、と*1。 そんなCOCOAに望む追加機能があります。 *1:個人的には、これでPM会社とか発注主が責められるのはどうなんだろうなあと思います。開発者の資質が圧倒的に足りない。よく言われるような多重下請けが云々という話とは関係なく、仕様に対してなにを確認したのか説明できないのは最低限の義務を果たしていないのではないかと思うのですよね <p>少し前に<a href="https://www.mhlw.go.jp/stf/shingi/other-soumu_030416.html">COCOAの報告書</a>でてました。</p> <p>一番びっくりしたのはテストを効率化するためにパラメーターを調整(Minimum Risk Score を「1」に設定)してたという記述で、それもうテストじゃないし、何を作って何をテストした認識なんだよ、と<a href="#f-41682bdb" name="fn-41682bdb" title="個人的には、これでPM会社とか発注主が責められるのはどうなんだろうなあと思います。開発者の資質が圧倒的に足りない。よく言われるような多重下請けが云々という話とは関係なく、仕様に対してなにを確認したのか説明できないのは最低限の義務を果たしていないのではないかと思うのですよね">*1</a>。</p> <p>そんなCOCOAに望む追加機能があります。</p> <p> </p> <p> </p> <h3>陽性者との接触記録があった時間に、どこでなにをしていたのか入力できる機能</h3> <p>表題の通り。</p> <p>COCOAの仕組みをざっとおさらいすると、陽性者が処理番号を入力することで、全COCOAアプリがその陽性者と濃厚接触していないか、(自分の)スマホ上の履歴を探ります。濃厚接触履歴があれば、通知が来ます。今の機能はそれだけです。PCR検査や陽性判定はシステム外で行われます。</p> <p> </p> <p>さて、スマホの中にはその陽性者と何日の何時何分に接触したかの記録があるので、それに対して、その時どこで何をしていたのかを入力できるようにしてほしいのです。あと、結局自分(被通知者)が陽性だったか陰性だったかも。手入力で構わないし、任意協力でも良い<a href="#f-bed46866" name="fn-bed46866" title="本当は位置情報も自動で取りたいけど、電池食いまくるだろうし、プライバシーの問題もあるからまあ無理だろうなと思う">*2</a>。</p> <h4>事実に基づいた分析と対策を</h4> <p>これがあるだけで、「陽性者といつどこで濃厚接触した人が、結果どうだったか」のデータが大量に集まります<a href="#f-8d4e110c" name="fn-8d4e110c" title="もちろん嘘ついたりする人もいるでしょうが、統計的に見れば誤差の範囲に収まるはず">*3</a>。</p> <p>本当はなにが危険なのか、事実に基づいた分析が可能になります。例えば、通勤電車は本当に安全なのか、映画館は本当に休業すべきなのか、トラベルは本当に悪なのか。感染経路不明は結局どこなのか。</p> <p>事実をもとにしたデータによって、効果的な対策が立てられるようになりますし、無駄な対策を強いられることもなくなります。国民に対策の根拠を説明できるようになります。</p> <p> </p> <p>思えば今までの対策は全然科学的でないように思います。専門家の方は頑張ってるとは思いますが、結果から事象を推測しているようにしか見えないのです。〇〇でクラスタがいくつか発見されてるから、原因は××なんじゃないかとか。専門家かもしれないけど、それ、ほんとに本当なのか?確固たるエビデンスはあるのか?っていう。これを「専門家の方がこうおっしゃってるので」とかいって政府自治体が推進するような事が起きている。</p> <p>たまにシミュレーションが出てきたと思ったら実効再生産数を仮置きしたシミュレーションだったり、他国との比較による推測だったりと、事実を前提としないものばかりです。実効再生産数が1未満になったら収束するのはあたり前だけど、それを減らす因子はなんなんだよ?っていう。黙食の徹底で実行再生産数が0.25減ると仮定すると、ってその数字の根拠は?っていう。</p> <p>結局、分析のもととなる詳細な事実ベースのデータがないから推論でやるしかない。全国民の詳細な移動履歴、行動データを分析するなんてできるわけないので、この流れは正しい。けど、COCOAなら(ていうかEN APIなら)それにかなり近いことがもうすでにできてるのです!活用しなきゃ!</p> <p> </p> <p>分析を別分野の担当者に任せられるのもメリットです。いまは、保健所?の聞き取り調査の内容を断片的につなぎ合わせて説を立てているようにみえますが、この仕組みがあればビッグデータ解析の専門家的なひとに丸投げできて、保健所や専門医の負担も軽減されるでしょう。</p> <p>もちろん成果物も、仮説より実データのほうが強いのは明らかですからWin-winてやつですな。</p> <p> </p> <h4>COCOAインストール率向上の施策も必要</h4> <p>これができたとしても、そもそも皆がCOCOAをインストールしてくれないとうまく仕組みが働きません。それこそもう1回10万円配って、その配布条件をCOCOAインストールにしてもよいのではないでしょうか。</p> <p>まあスマホ持ってない人はどうすんだとか言われるかもしれませんが、買えば?としか。10万もらえるんだから2万くらいの格安スマホと楽天モバイルかOCNモバイルあたり契約すればOKなのでは?という。若干不公平感は出るけどまあしょうがない緊急時だしトータルプラスだしってことで。</p> <p>あとコロナなった時に優先対応してもらえるとかそういうメリットもつくって訴求していかないと<a href="#f-a92cf3c3" name="fn-a92cf3c3" title="それこそ「遊びまわってもいいけど、もしコロナなったらちゃんと行動履歴入れろよ?」ってもありなのかもしれない">*4</a>。</p> <p>初版とそこから始まるなにやらがあまりにゴミだったのであれですが、アプリ(というかEN API)自体はものすごい可能性があると思うのです。でもインストールしなきゃ始まらない。ゼロベースで作り直すのはもちろん、なんなら名前すら変えてもいいから普及に努めてほしいなあと思います。</p> <p> </p> <h3>まとめ</h3> <p>いまの対策は馬鹿げてます。誰かが思いつきであれは危ないんじゃないかとか言って、それで全部が禁止になったり。</p> <p>馬鹿げてますが、確固たるデータがないのでだれもそれを否定できない。そんなことを1年もやっている。データを、事実をもとにした分析ができるようにしていきましょう。</p> <p>まずは1つの機能追加から。よろしく!</p> <p> </p><div class="footnote"> <p class="footnote"><a href="#fn-41682bdb" name="f-41682bdb" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">個人的には、これでPM会社とか発注主が責められるのはどうなんだろうなあと思います。開発者の資質が圧倒的に足りない。よく言われるような多重下請けが云々という話とは関係なく、仕様に対してなにを確認したのか説明できないのは最低限の義務を果たしていないのではないかと思うのですよね</span></p> <p class="footnote"><a href="#fn-bed46866" name="f-bed46866" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">本当は位置情報も自動で取りたいけど、電池食いまくるだろうし、プライバシーの問題もあるからまあ無理だろうなと思う</span></p> <p class="footnote"><a href="#fn-8d4e110c" name="f-8d4e110c" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text">もちろん嘘ついたりする人もいるでしょうが、統計的に見れば誤差の範囲に収まるはず</span></p> <p class="footnote"><a href="#fn-a92cf3c3" name="f-a92cf3c3" class="footnote-number">*4</a><span class="footnote-delimiter">:</span><span class="footnote-text">それこそ「遊びまわってもいいけど、もしコロナなったらちゃんと行動履歴入れろよ?」ってもありなのかもしれない</span></p> </div> uxlayman オンラインホワイトボードコーディングテストの心得 hatenablog://entry/26006613646038169 2020-10-28T21:52:01+09:00 2022-02-28T21:13:53+09:00 転職活動でオンラインホワイトボードコーディングテスト(zoomでつなぎながらテキストエディタ共有サイトでコードを共有するパターン)をやったので、その心得を書いていきます。 ちなみに結果は、超簡単な問題だったにもかかわらず、テンパってしまい面接官の言われるがままコードを書いてなんとか完成させるもののもちろん落選というもので。 結構行きたかった企業の1次面接だったので、だいぶ落ち込みました。ということなので、心得というか、失敗談ですね。 いきなりコードを書き始めない あとになって思い返すと、これが全てだったかな。お題が与えられたときに、どういう雰囲気で解こうとしているか、どういう処理をして、結果が… <p>転職活動でオンラインホワイトボードコーディングテスト(zoomでつなぎながらテキストエディタ共有サイトでコードを共有するパターン)をやったので、その心得を書いていきます。</p> <p>ちなみに結果は、超簡単な問題だったにもかかわらず、テンパってしまい面接官の言われるがままコードを書いてなんとか完成させるもののもちろん落選というもので。</p> <p>結構行きたかった企業の1次面接だったので、だいぶ落ち込みました。ということなので、心得というか、失敗談ですね。</p> <p> </p> <h3>いきなりコードを書き始めない</h3> <p>あとになって思い返すと、これが全てだったかな。お題が与えられたときに、どういう雰囲気で解こうとしているか、どういう処理をして、結果がどう変化していくと想定しているのか、説明すべきだったと思う。</p> <p>多分ホワイトボードがあれば、配列とか集合とかの絵を描いて雰囲気説明するんだろうけど。</p> <p> </p> <p>これをしないと面接官となにをどうやろうとしてるかの意思共有ができなくて、(自分からすると)的外れなツッコミを受けて混乱することになります。</p> <p>あと、多分「物事を論理的にとらえてるか」とか、「人にわかりやすく説明できてるか」とかの採点指標になってる気がします。知らんけど。</p> <p>最悪、説明がうまくできてれば多少コードがあれでも通るのではないかとかも思ったり。ま、面接官じゃないんで知らないですけど。</p> <p> </p> <h3>面接官のプレッシャーに慣れておく</h3> <p>コーディング中は、面接官がかなりサポートしてくれます。あれ?そこ〇〇が抜けてない?とかそういうことを言ってくれる。すごく親切。</p> <p> </p> <p>親切…なんですが、これは<strong>めちゃくちゃプレッシャーになります</strong>。特にどうコーディングするかをうまく共有できてない状況だと、「あれ?なんか言われてるけどなんのこと?どこのこと?よくわからない。スルーするのもおかしいし。とりあえず直すけど、あれ?ここをこうすると全体はどうなるわけ?なんだ?なんだ?」となります。</p> <p> </p> <p>そもそも、相手方だけが一方的に「答え」を知っていて、即座に口出しはしてくるけれども正解を教えるわけでもない、という状況はわりと特殊です。実務上、経験したことがない人もおおいとおもいます。</p> <p>ペアプロだったら「一緒に考える」が出発点だし、わかんなかったらわかる方が書いてから解説しますからね。そもそも、コーディング複数人でやったことある人自体も少ないですよね。</p> <p> </p> <p>このシチュエーション、練習しようがないのが特にアレなんですが、ともかくそういうことが起こるという心構えは必要でしょう。これ、面接官本人が親切のつもりでやってるのがさらにたちが悪い。正直、だまっててほしかったです。</p> <p> </p> <h3>競技プログラミングサイトで練習すべきかどうかは微妙</h3> <p>就職転職の面接だと、AtCoderやLeetCodeみたいな競技プログラミングサイト(以下競プロ)チックな実技試験もあります。この手のサイトで練習しといた方がいいという意見もよくみますが、ちょっと微妙です。</p> <p> </p> <p>理由の1つ目は、ホワイトボードテストの問題は競プロの問題と比べて多分かなり簡単であろうということ<a href="#f-fd4a8c37" name="fn-fd4a8c37" title="n数1であれですが">*1</a></p> <p>その場でロジック考えて説明して、話しながら改良して、という性質から考えると、広がりはあるものの書ききること自体は簡単な問題が出ると考えるのが妥当でしょう。</p> <p>なので、競プロで練習しまくっても本番が簡単すぎて練習の意味がなくなる可能性があります。</p> <p> </p> <p>2つ目は、競プロとホワイトボードテストは作業手順が異なること。競プロは、コンパイルもテストも通す必要があるけども、1人で黙々進めることができます。ググることもできるし、とりあえず書いてみてからテスト通すことを目的にバグつぶししていくこともできます。</p> <p>わたしも今回初めて気付いたのですがこのタイプのコーディングをしてます。ザクっと雰囲気で書いてからリファクタしていく、という。</p> <p> </p> <p>対して、ホワイトボードでは、まず概要を説明してからツッコミに耐えながら描き続けなければなりません。コンパイルが通る必要は全くないですが、コードで正しく意図を表現できる必要がありますし、要点だけをコード化しなければなりません。</p> <p>AtCoderで難しい問題が解けるようになっても、それより遥かに簡単な問題の、要点部分だけを書いて、それをわかりやすく説明しなければならないですし、そもそも書き始める前に概要を言わなければなりません。</p> <p>その辺意識して競プロで(たとえばコード書く前に口で説明してみるとかそういう手順を入れて)練習するなら良いのですが、ただ単にドリル的にサイトの問題を解きまくると本番で思わぬ落とし穴が来るかもしれません。</p> <p> </p> <h3>結局どうすればよいか</h3> <p>あまり答えは出てないですが、面接時の状況としてはペアプロがいちばん近いのかなあと。スーパープログラマーに簡単な問題出してもらって、横でつっこまれながら書いていって慣れる、とか?</p> <p>まあ、あとはホワイトボードテストを依頼された時点でその会社はご縁がなかったとして諦めるとか。自分はいまはこの気持ちですね。あまりに出来が酷かったので、面接直後に落ち着いて書き直したら5分で完成できましたし。いまだになぜできなかったのかよくわかっていない。ただただ苦手意識だけが植え付けられてトラウマです。</p> <p>参考になれば。</p> <p> </p> <p> </p><div class="footnote"> <p class="footnote"><a href="#fn-fd4a8c37" name="f-fd4a8c37" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">n数1であれですが</span></p> </div> uxlayman スクラム開発批評 hatenablog://entry/26006613628686760 2020-09-16T21:05:00+09:00 2022-02-28T21:13:56+09:00 最近スクラム開発をやってみてるのでその感想を。スクラム開発って何?って方は以下の図をごらんください。 via スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com …すこし本題とは逸れるのですが、この絵は実際に社内のスクラム推進派の人に見せられた絵です。なんですが、、、あのさ、、、これでなんなのかわかんなくね? この絵に限らず、スクラム開発 - Google画像検索で出てくる画像はほとんど、スクラムの構成要素をただ書いていて、結局何が良くなるのか、つまり効果がわからないのです。この時点ですでに割と不信感ありますよね。良さをわかってもらおうという気があんまりみえない。… <p>最近スクラム開発をやってみてるのでその感想を。スクラム開発って何?って方は以下の図をごらんください。</p> <p> </p> <p><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20200916/20200916190500.png" alt="f:id:uxlayman:20200916190500p:plain" title="f:id:uxlayman:20200916190500p:plain" class="hatena-fotolife" itemprop="image" /></p> <p class="photo-caption">via <a href="https://www.ryuzee.com/contents/blog/7124">スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com</a></p> <p> </p> <p>…すこし本題とは逸れるのですが、この絵は実際に社内のスクラム推進派の人に見せられた絵です。なんですが、、、あのさ、、、<strong>これでなんなのかわかんなくね?</strong></p> <p>この絵に限らず、<a href="https://www.google.com/search?q=%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E9%96%8B%E7%99%BA&amp;amp;tbm=isch&amp;amp;source=iu&amp;amp;ictx=1&amp;amp;fir=5X-6Prxc5lYESM%252C0Kr53fJ-AOfa7M%252C_&amp;amp;vet=1&amp;amp;usg=AI4_-kRmrqgiRNxXn0F9z4aCPIap7GZbVg&amp;amp;sa=X&amp;amp;ved=2ahUKEwjWyL7hq-3rAhWKdXAKHQxlCg4Q_h16BAgKEAc#imgrc=OaaWwFi4_TsL5M">スクラム開発 - Google画像検索</a>で出てくる画像はほとんど、スクラムの構成要素をただ書いていて、結局何が良くなるのか、つまり効果がわからないのです。この時点ですでに割と不信感ありますよね。良さをわかってもらおうという気があんまりみえない。わかってる人がわかってる人のために書く図。</p> <p>閑話休題。</p> <p>ま、単純に言ってしまうと、スクラムはバックログという要望集を、スプリントと呼ばれる固定時間(1〜4週間程度で選択)内で、リリース可能なレベルの成果物として実現することで、素早い価値提供を可能にするための方法論です。</p> <p> </p> <h4>エピックの実現を確認できる仕組みがない</h4> <p>一番違和感があるのがここ。エピックはスクラム用語でいう「おおきな要望」</p> <p>スクラムの最大の特徴はスプリントが固定時間であること。開発単位が常に固定されてることで、固定時間中にどれくらいのストーリーポイント(工数規模とか要望規模を表すスクラム用語)を実現できたか(=ベロシティ≒チームの開発力)も測れるし定期的なリリースも担保できる。バーンダウンチャート他、状況の見える化のためのツールもたくさんある。そこまでは良い。</p> <p> </p> <p>じゃあ大きな要望で、スプリントに入り切らなかったらどうするのか?要望を細かく分解して複数スプリントに分けます。スプリントが最大の特徴で、スプリントが絶対です。</p> <p>〇〇を実現したいというおおきな要望(スクラム用語で言うエピック)に対して、スプリント1ではデータモデルとAPIを、2では管理系UIを、3でユーザー用UIをといった具合に。それぞれのスプリントは効率的に遂行されるし、改善点を良くしていくような仕組みも備わってるし、スプリント単位でデモ会や受け入れ条件の確認といったプロセスがあるので間違いも起こりにくい、というロジック。</p> <p> </p> <p>でも、おおきな要望(エピック)が実現できたかどうかはどうやって判断する?</p> <p>ほとんどの商業ソフトウェアには、実現したいおおきな要望があるはず。たとえば、大きな機能改修を入れて、より広い顧客にアプローチできるようにするとか、KPIを達成させて利益確保できるようにするとか。ま、商売なんで基本は金ですよね。</p> <p>ビジネスサイドが求めるのはエピックの確実な実現であって、開発チームの効率運用は副次的要素に過ぎない。でも、スクラムにはそのエピック実現確認の仕組みがない。一義的には、プロダクトオーナーが各スプリントレビューにおいて受け入れ条件を満たしているかを確認する、という事になってるが、全体のことを考えながらそんな事できる人は少ない。APIの実装内容をPostmanでデモしてもらって、それがエピックに対して適切かどうかどうやって判断できる?</p> <p> </p> <p>素晴らしい方法論で過去最高効率で作られたコンポーネントであっても、エピックが実現できなければ意味がない。</p> <p>ほとんどのソフトウェアにとって最も大事なのはエピックの実現だ。しかし、スクラム開発は開発方法論のためにそれをスプリントという単位に砕いて見えにくくすることを是としている。とても違和感がある。</p> <p> </p> <h4>アジャイルの利点をつぶしている</h4> <p>アジャイル開発で解決できる一番の課題はなんだろう。</p> <p>「ひとは、解決手段が提示されたあとでないとその解決手段の問題点を認識できない」ではないだろうか。スティーブジョブズ風に言うと「多くの場合、人は形にして見せてもらうまで、自分は何が欲しいのかわからないものだ」か。</p> <p>だから「あんなに要件定義したのに出来上がったあとに要望が山程くる」という事態が頻発する。</p> <p> </p> <p>アジャイルはこれに対応するための考え方で、だからアジャイルフレームワークの一つであるXPなどは顧客自身をチームに加えるべきと提唱している。スパイラルアップやプロトタイピングも有効な対策だ。ともかく「もうできちゃったよ、文句あるんならもっと早く言ってよ」を何とかするためにアジャイルはある。</p> <p>翻ってスクラムはどうだろうか。スクラム開発者は、スプリント中は顧客やステークホルダーの干渉を受けない。だから、「始まる前」にバックログをよく整備しておく必要があるし、チーム皆が目指すところを正しく理解していなければならない。スプリントの成果物はリリース可能な状態にしなければならないので、やり直しは効きにくい。(もちろんプロダクトオーナーがそのへんハンドリングすべきなのだが、毎回それやってると進まなくなってしまう)</p> <p>スプリントでQAまでしっかり作り込むのもスクラムの特徴なので、まず仮で作って、正しいかどうか確認してもらう。だめならすぐ直す。そういうことができるように工夫する、というアジャイルの理念をつぶしている。</p> <p>対話によって整備されたバックログは間違えることなどありえない、ということなのだろうか。</p> <p> </p> <h4>スプリントの遂行のみに注力しているように見える</h4> <p>スクラムのプラクティスはほとんどスプリントの中のものだ。スプリントを高効率で実現し、自己改善していくことに重きが置かれている。</p> <p>スプリント外の要素もあるにはあるのだが、たいていの場合あいまいに書かれている。</p> <p>「プロダクトオーナーは常にバックログを精査し、優先度や粒度を最新の状態にしなければならない」とか。いやいや大仕事すぎるだろそれ。プロダクトオーナーやスクラムマスターの仕事はかなり「対話」という言葉で適当にまとめられてる感もある。なにかあれば対話、対話で具体性がない。一方、スプリント内の作業は会議時間まできっちり決められてたりする。</p> <p>良くいえば開発者の開発力を100%引き出す仕組みに見えるが、悪く言えばただコードを書いて喜びたい開発者が都合よくでっち上げた方法論のようにも見えてくる。</p> <p> </p> <h4>まとめ</h4> <p>問題点があるなら改良すればいいじゃないか、という意見もあるだろう。わたしが勉強不足で、改善するフレームもすでにあるのかもしれない。</p> <p>でも、ここに上げた2つ「ソフトウェア開発の最重要指標であるエピックの実現をさしおいて開発効率化の仕組みを優先している」「アジャイル開発の最重要目的である要望元への確認プロセスを欠いている」ことはスクラム最重要特徴であるスプリントに起因する問題であり、致命的ではないだろうか。</p> <p> </p> <p>スクラムが適用可能な領域はたくさんある。たとえばOSSなど、純粋に開発者力=プロダクト力となるプロダクトにはいいだろう。FacebookやNetflixのように大規模で安定しており、山のようなバックログがあって、直せば直すほどよい結果になると皆が共有認識があるプロダクト(10000を10100にするような開発)ではよいだろう。開発チーム内のタスクマネジメントツールとしてつかうのも非常に良いと思う。</p> <p>しかし、ソフトウェア開発方法論として全面的に採用するのは間違っているとおもう。繰り返しになるが、理由は2つで、「ソフトウェア開発の最重要指標であるエピックの実現をさしおいて開発効率化の仕組みを優先している」「アジャイル開発の最重要目的である要望元への確認プロセスを欠いている」から。</p> <p> </p> <p><a href="https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/about-agile-03.html">アジャイル開発とは(後編)スクラムとXPの調和 : 富士通ソフトウェアテクノロジーズ</a>によくまとまっていたが、スクラムはその本来の特徴を生かして機能の効率開発に注力し、要求の確認や分解はプロトタイピングなどを重視するその他の方法論と協調していくのが良いのではないかと思う。</p> <p>ウォーターフォールを置き換えてスクラムを始める、というよくあるやり方には賛成できないし、スクラム開発方法論はそこまでうまく出来上がっていない。</p> uxlayman AWSはOracleみたいだから嫌い hatenablog://entry/26006613585521347 2020-06-16T19:54:00+09:00 2022-02-28T21:13:56+09:00 そもそもAWSがOracleみたい、って感覚伝わるのかな。 どんどん新しいサービスがでてきてよくわからないとか ベストプラクティスが日進月歩で新しくなるとか なのに古いベストプラクティスに囚われてるマンがいたりとか 古いプラクティスを経緯や根拠を取っ払って〇〇は使うなっていうルールにして形骸化させちゃったりとか 資格がパスポートのような役割を果たしてるとことか そのくせ資格ホルダーが使えなかったりとか 使いこなすこと(手段)と目的を混同してるマンが大量発生するとか 一般概念とベンダー固有概念の区別がつかないマンが大量発生するとか サービスについて公式文書を見るとすごくフレンドリーそうな文面なの… <p>そもそもAWSがOracleみたい、って感覚伝わるのかな。</p> <p> </p> <p>どんどん新しいサービスがでてきてよくわからないとか</p> <p>ベストプラクティスが日進月歩で新しくなるとか</p> <p>なのに古いベストプラクティスに囚われてるマンがいたりとか</p> <p>古いプラクティスを経緯や根拠を取っ払って〇〇は使うなっていうルールにして形骸化させちゃったりとか</p> <p>資格がパスポートのような役割を果たしてるとことか</p> <p>そのくせ資格ホルダーが使えなかったりとか</p> <p>使いこなすこと(手段)と目的を混同してるマンが大量発生するとか</p> <p>一般概念とベンダー固有概念の区別がつかないマンが大量発生するとか</p> <p>サービスについて公式文書を見るとすごくフレンドリーそうな文面なのに結局なんだかわかんないとことか</p> <p>すっごい簡単です、とか今すぐ始められますとかいう話がちゃんとできた試しがないとか</p> <p>なんだかんだエバンジェリストのブログとか講演とかで超重要情報が明かされたりとか</p> <p>特に性能面とか肝心なとこがブラックボックスなとことか</p> <p>サポートに問い合わせると、原理上は正しく動作するはずですがあなた方で十分にテストしてください、とか平気で言われることとか</p> <p>おま国とか</p> <p>GUIがあるのに結局最後はCUIになったり、GUIとCUIのできることの差が激しかったりとか</p> <p>胡散臭いパートナーが多いとことか</p> <p> </p> <p>伝わります?まあ伝わらなくてもいいですけど。</p> <p> </p> <p>それで、何が嫌いかって、一番象徴的なのは資格。</p> <p>彼らから見え隠れする「すごいものをつくってやったぜ。だからお前、その仕組みを勉強して当然だよな?」っていう意識。すごいんだから難しいのは当たり前だろ?と。デファクトな資格取れたらそれだけでステータスになるから逆に有り難いだろ?と。わざわざややこしく作り上げて(というと言い過ぎかもだが、あまり整理するつもりがないように見える)、そのややこしさをバイパスするためにクラウドインテグレーターなる新業種ができたりして。その状況を恥じるどころか、新たなエコシステムを作って雇用を創出してるなどと誇りにすら思ってそう。</p> <p>この点、事実上ほぼほぼ同じサービスを提供してるにも関わらず、GCPからはそういう雰囲気がしないのが興味深い。彼らは本気で直接エンドユーザーにコンピューティングパワーを使えるようにしたいと思っていて、いまはその過渡期、という雰囲気を強く感じる<a href="#f-8bca9842" name="fn-8bca9842" title="なぜなんだろう。AWSからはいろいろなサービスをみていてもそこかしこにEC2の影を感じる。マシンとインフラを忘れるな、というメッセージを。一方のGCPはPaaSであるAppEngineが礎であることが関係しているのだろうか。マネージドマネージドお前は本来価値に集中せいというプレッシャーがある">*1</a>。MSのクラウドは使ったことないが、社是(Empower every person and every organization on the planet to achieve more.)からしても、Windows Serverの過剰なまでのGUIでのもてなしからしても、どちらかというとGoogle寄りなんだと思う。</p> <p> </p> <p>かつて、Oracleはアプリケーションの中心だった。データを保持して、検索して、読み出すという基本機能と性能に関わる中心を担っていたし、一意性制約や外部キー制約といったデータの整合性を確保するためのアプリケーションにとって重要な機能性も保持していて、それはOracleにしかできなかった(らしい<a href="#f-f94d2028" name="fn-f94d2028" title="実は物心ついた頃からMySQLやPostgreSQLもそれらの機能を持ってたのでどうもOracle信頼性神話みたいのがピンとこない">*2</a>)</p> <p>その中心たるOracleが高いハードウェアスペックを要求していて、しかも状況に応じて性能に大きな違いが出る"よくわからない複雑さ"を備えていたので、SIerほか"よくわからないところをよくわかっている人"を間に挟まざるを得なかった。</p> <p>AWSはハードウェアを仮想化させてスケールさせるモデルによって、よくわからない高価なハードウェア、高価な人たちとの付き合いから開放させた。NoSQLをマネージドして、アプリケーション側に整合性確保の責務を負わせるような、本来あるべきモデルも推進している。</p> <p>そんな英雄たるAWS自らがまた新しい"よくわからないもの"になっているのは皮肉なことだ。</p> <p> </p> <p>わたしはアプリケーションエンジニアなので、やりたいことをダイレクトに実現したい。どういうアプリだからどこにどんな機能性が必要かは考えるが、なんとかサービスはスケーリングに癖があって、とか、なんとかサービスはアンチプラクティスが存在して、とか、そのアンチプラクティスは昨年12月のブログ記事によって解消された、とか、そういう"よくわからないこと"は考えたくない。</p> <p>ユーザー企業もそうだろう。ユーザー企業のビジネス上の課題なんて、自分で解決すべきだ。当たり前だ。自分たちのビジネスなんだから、それが当然だと思う。なのに間に"よくわからないもの"が入り込んでくるおかげで、目標を異にする人と絡まなければならなくなる。やっとOracleとSIerから開放されたと思ったら次はAWSとクラウド屋かと。コミュニケーションロスも数多発生する。いつまでこんなことを続けるのだろうか。これは人類の損失だ。そういう世界を是とする、AWSやOracleのようなプロダクトの姿勢が嫌いだ。AWSはOracleみたいだから嫌いだ</p> <p> </p> <h5>補足</h5> <p>AWSの名誉のために言っておく。ある側面において似てる、という点でこの記事を書いたけど、AWSはOracleの1000倍くらいマシだ、ということは一応念の為書いておく。</p> <p>ま、どのサービスも金額がいくらかわかるからね。それだけでもう。</p><div class="footnote"> <p class="footnote"><a href="#fn-8bca9842" name="f-8bca9842" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">なぜなんだろう。AWSからはいろいろなサービスをみていてもそこかしこにEC2の影を感じる。マシンとインフラを忘れるな、というメッセージを。一方のGCPはPaaSであるAppEngineが礎であることが関係しているのだろうか。マネージドマネージドお前は本来価値に集中せいというプレッシャーがある</span></p> <p class="footnote"><a href="#fn-f94d2028" name="f-f94d2028" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">実は物心ついた頃からMySQLやPostgreSQLもそれらの機能を持ってたのでどうもOracle信頼性神話みたいのがピンとこない</span></p> </div> uxlayman 「みずほ銀行システム統合、苦闘の19年史」が普通に称賛案件だった件について hatenablog://entry/26006613526874480 2020-02-28T07:30:38+09:00 2022-02-28T21:13:53+09:00 各所で話題になってたみずほの本の話。 みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 作者:日経コンピュータ,山端 宏実,岡部 一詩,中田 敦,大和田 尚孝,谷島 宣之 発売日: 2020/02/14 メディア: 単行本 現システムは「大成功」 この本は3部構成になっていて、1部は稼働中の新勘定系システムMINORIの説明です。 本件、直接は知りませんでしたがネット上では「関わったら負け」と言われるほど悪評高く、また延期も2度行っていたので、勝手に「既存システムに〇〇を追加せよ、的な"阿吽の呼吸"の要求を元に開発して、レビューの名の下にしょっちゅう要件が追加… <p>各所で話題になってたみずほの本の話。</p> <div class="freezed"> <div class="hatena-asin-detail"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4296105353/uxlayman-22/"><img class="hatena-asin-detail-image" title="みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」" src="https://m.media-amazon.com/images/I/51kcMMmX+SL._SL160_.jpg" alt="みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」" /></a> <div class="hatena-asin-detail-info"> <p class="hatena-asin-detail-title"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4296105353/uxlayman-22/">みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」</a></p> <ul> <li><span class="hatena-asin-detail-label">作者:</span><a class="keyword" href="http://d.hatena.ne.jp/keyword/%C6%FC%B7%D0%A5%B3%A5%F3%A5%D4%A5%E5%A1%BC%A5%BF">日経コンピュータ</a>,<a class="keyword" href="http://d.hatena.ne.jp/keyword/%BB%B3%C3%BC%20%B9%A8%BC%C2">山端 宏実</a>,<a class="keyword" href="http://d.hatena.ne.jp/keyword/%B2%AC%C9%F4%20%B0%EC%BB%ED">岡部 一詩</a>,<a class="keyword" href="http://d.hatena.ne.jp/keyword/%C3%E6%C5%C4%20%C6%D8">中田 敦</a>,<a class="keyword" href="http://d.hatena.ne.jp/keyword/%C2%E7%CF%C2%C5%C4%20%BE%B0%B9%A7">大和田 尚孝</a>,<a class="keyword" href="http://d.hatena.ne.jp/keyword/%C3%AB%C5%E7%20%C0%EB%C7%B7">谷島 宣之</a></li> <li><span class="hatena-asin-detail-label">発売日:</span> 2020/02/14</li> <li><span class="hatena-asin-detail-label">メディア:</span> 単行本</li> </ul> </div> <div class="hatena-asin-detail-foot"> </div> </div> </div> <p> </p> <h3>現システムは「大成功」</h3> <p>この本は3部構成になっていて、1部は稼働中の新勘定系システムMINORIの説明です。</p> <p> </p> <p>本件、直接は知りませんでしたがネット上では「関わったら負け」と言われるほど悪評高く、また延期も2度行っていたので、勝手に「既存システムに〇〇を追加せよ、的な"阿吽の呼吸"の要求を元に開発して、レビューの名の下にしょっちゅう要件が追加されて、テストに入っても『運用が回らないから』とか言って要件が追加されて、出来上がったものはなんとか動いてはいるものの柔軟性のないそびえたつクソ」っていうよくあるパターン、銀行っぽいパターンなんだろうなと思ってました。</p> <p>この本にもきっと「動き出しはしたものの3回目の大規模障害は時間の問題」的な裏事情が書かれているのだと思っていました。</p> <p> </p> <p>しかし、第1部は予想に反してMINORIは「大成功」という体で話が進みます。</p> <p>ハハッわろすと読み進めていたのですが、どうやらSOAの思想で構築された疎結合のシステムで、それゆえ機能追加時のテスト工数が減少でき、従来システムに比べて(そして競合他社に比べても)圧倒的に柔軟であるとのこと。実際たしかに本の記載を見るととても"良さそうなもの"が出来上がった感じがします<a href="#f-9c79d59b" name="fn-9c79d59b" title="というか旧来システムレガシーすぎるだろとビビる">*1</a>。</p> <p> </p> <p>そして、読むにつれてプロジェクトの様々なことが「正しく」行われてるのがひしひしと感じられてくるのです。</p> <p>驚きだったのは、要件定義にあたってasis(従来どおり・従来システムを踏襲)を全面禁止して、ユーザー部門に本来あるべき本質的な業務フローを1から考えさせてツールで表現させたというところ。</p> <p>SOAはサービスやコンポーネントをいかに独立性/再利用性高く切り出せるかが鍵なので、正攻法ではあるのですが、本当に驚きでした。だってそんなことできた試しがないですから。</p> <p>受託システム開発は「自分の業務すら正しく把握できない要求元が、システムを通じて浮かび上がってきた業務上の不整合を誰のせいだと揉める時間が大半を占める」というお約束で進むものであって、要求元の責務を果たそうとすること自体が珍しいのです。そして、よしんば本腰をいれてやる気があったとしても、そもそも現状と切り離して本来論を検討するというのはなかなかスキルが必要で、底力がないとできないことなのです。</p> <p>しかもこれ、ちゃんと粒度や記載にばらつきがないようにみずほ側がガバナンスとってやってたらしいです。マジか。</p> <p>考えてもみてください。「今の業務とはべつに自業務のあるべき姿を考えて謎のツールで表現してください。監査役からもろもろコメント入るかも知れないので対応してください。現行の業務システムから処理を書き起こすのは禁止です。」などというめんどくさい依頼を飲ませるだけでも相当大変ですよ?どれほどの苦労があったことか…</p> <p>そしてSOAのサービス粒度はこの「あるべき業務」によって適切に決められたはずで、その事実だけでかなり"強い"システムが構築されたことがうかがい知れます。</p> <p> </p> <p>その他プロジェクト運営に際しても痒いところに手が届くような施策をことごとくやっていて、圧倒的に「正しいこと」を頑張ってやったのが伝わってきます。またもや称賛。</p> <p>例をあげるなら「最初に用語を統一する」話。さらっと書いてありますが、大企業で様々な部署がひしめく中、統一した辞書を作るだけでも超大仕事です。でもそれをしないとそのあとあらゆるところで困るので「正しい」です。そういう細かいことの積み重ね、間違った方向に行かないようにする施策がすごくたくさん出てきてだいぶスタンディングオベーションしたい気持ちになってきてました。</p> <p> </p> <p>2回の延期も場当たり的に延期したのではなくて適切な時期に適切に見積もりを再評価した結果の延期で、うまくガバナンスが効かせられてたことが伺えます。</p> <p> </p> <p>ひとつだけ、大丈夫か?と思ったのは「コードはすべてツールから自動作成」という記述。バグ修正などで正しい挙動を実現するコードはわかってるのに、それを自動生成させる手段がわからない、なんてことにならないかなあと。でもまあきっとそれを上回るメリットがあったのでしょう<a href="#f-76cb81d7" name="fn-76cb81d7" title="生コードは様々なスタイルで記載できるので、データとその扱い、異常時のポリシーのようなコーディングルールで縛れないような設計上の制約を均質化できるのはメリットかなと。">*2</a>。</p> <p> </p> <p>ともかく、第1部を読み終わる頃にはなんか想像と違ったけどすごく良い本だな、という気持ちでした。</p> <p> </p> <p>余談ですけど、第1部には新システムの操作教官として一般職から有志を募って教育にあたらせた話が出てきます(ちなみにこの人達が困らないようにバッチリフォロー体制もあった旨も記載あり)。その人達の現在の肩書がなんかすごいんです。出世した感が肩書きからもわかって、サクセスストーリー感がわくわくします。</p> <p>みずほ経営陣は「人が育った」ことを大きな成果として認識してるとの記載がありましたが、さもありなんといったところ。</p> <p> </p> <h3>圧倒的クソな過去事案のせいで今がより輝く</h3> <p>第2部と3部は2011年の東日本大震災直後に起きた2回目の大規模障害と、2002年の合併直後に発生した1回目の大規模障害に至る軌跡の解説。</p> <p>これはね、まごうことなきクソです。</p> <p> </p> <p>2011年は(合併後のごたごたがあったにせよ)ずっとなあなあで動かしてきて、異常発生時のリハーサルしてないどころか異常発生時の例外フローすらない、なんならデータフロー図さえないシステムで障害起きて、非常時にもかかわらず全くリーダーシップを発揮できなくて解決まで10日もかかったという、想定以上のクソ事案。</p> <p> </p> <p>2002年は、IT投資増加のために合併するというふれこみだったのに、CIOも配置せず担当レベルに検討を丸投げして、ベンダーと組みながら新銀行の主導権争いに奔走し、システム統合方針さえ二転三転した挙げ句、システム開発会社のできますやれますを鵜呑みにして見切り発車で大障害を起こすという、半沢直樹みたいな話ってほんとにあるんだな、と謎の感動すら覚えるほどの救いようのないクソ事案。</p> <p> </p> <p>でもこれ、最終的に成功に終わることがわかってるので、これらの事案がマイナスに働くより、こんな文化の会社でようやったよな、という気持ちが止まらなくなるんですよ。</p> <p>ほんの一年前までデータフロー図すらなくて平気だったような文化背景で、ゼロベースで本質フローを書き起こさせるだなんて、ようやったよなと。</p> <p>合併先の片方にシステムを寄せる「片寄せ」すらまともにできず右往左往する文化背景だったのに、SOAで疎結合なシステムをスクラッチ開発とか、ほんとにようやったよなと。</p> <p>よくこんなマイナスからのスタートでやりきったなと。</p> <p> </p> <p>やっぱり合併前後くらいで入社して10年間くらいずっと「みずぽ(笑)」とか言われてた人たちが心を一つにしたのだろうか。</p> <p>ぐうたらな社員でも「3度目やらかしたらマジでやばい」という危機感が共有できて一体感が醸成されたのだろうか。</p> <p>いろんな想像をかきたてつつ、クソな過去が今をより輝かせるという胸熱な展開です。</p> <p> </p> <h3>でもホントのところも知りたい</h3> <p>まあでもちょっと出来すぎてるとも思うわけですよ。ホントのところはどうなんだと。実はみずほ主体じゃなくて裏でコンサルが暗躍してたんじゃないかとかさ。SOAなんて掛け声だけで実は従来通りのスパゲティ・モノリシックなんだとかさ。ただSOAは話半分だとしてもレガシーシステムと比べれば雲泥の進化だからなあ。</p> <p>そもそもネット上の超悪評はいったいなんだったのかと。すくなくとも2011年以降は「正しい」ことを根気よくやってるようにみえて、ではなにをもってどんな視点でそこまでdisられてたのかと。</p> <p>まああと最近できてるネット専業銀行とかに比べてアドバンテージはどうなんだろうな、とかは気になる。</p> <p> </p> <p>なにはともあれ、とても良い本でしたし、無事やり遂げられたこと、心の底から称賛いたします。こういう話は元気が出るし、たしかに2025年の崖を乗り越えるヒントになるね。</p> <p>ブラボー!</p><div class="footnote"> <p class="footnote"><a href="#fn-9c79d59b" name="f-9c79d59b" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">というか旧来システムレガシーすぎるだろとビビる</span></p> <p class="footnote"><a href="#fn-76cb81d7" name="f-76cb81d7" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">生コードは様々なスタイルで記載できるので、データとその扱い、異常時のポリシーのようなコーディングルールで縛れないような設計上の制約を均質化できるのはメリットかなと。</span></p> </div> uxlayman 手段の目的化がなぜ起こるのかいまだに理解できない hatenablog://entry/26006613390301048 2019-08-09T07:28:54+09:00 2022-02-28T21:13:55+09:00 はてぶにコメントした。 提案が通らない人が抑えるべきビジネスパーソンの思考パターン3つ | BtoCマーケティング支援の株式会社ホジョセン 普通これ全部考えるもんじゃないの??例えば承認者にあわせてWHYを最重視しました、なんて提案が通るわけがない 2019/08/09 06:16 あとまあ、一般的にはWHY&WHAT→HOWだよな。なんのためになにを、という目的が了承されてからから手段を考える。しかし一般的な「下の人」はまずHOWから考える人が多いのでWHY&WHATでダメ出しされる。いわゆる手段の目的化— りんご4個分 (@uxlayman) 2019年8月8日 こんなツイートもした。 コ… <p> </p> <p>はてぶにコメントした。 </p> <blockquote class="hatena-bookmark-comment"><a class="comment-info" href="https://b.hatena.ne.jp/entry/4672662343891641954/comment/uxlayman" data-user-id="uxlayman" data-entry-url="https://b.hatena.ne.jp/entry/s/www.hojosen.co.jp/blog/6293/" data-original-href="https://www.hojosen.co.jp/blog/6293/" data-entry-favicon="https://cdn-ak2.favicon.st-hatena.com/?url=https%3A%2F%2Fwww.hojosen.co.jp%2Fblog%2F6293%2F" data-user-icon="/users/uxlayman/profile.png">提案が通らない人が抑えるべきビジネスパーソンの思考パターン3つ | BtoCマーケティング支援の株式会社ホジョセン</a><br /> <p style="clear: left;">普通これ全部考えるもんじゃないの??例えば承認者にあわせてWHYを最重視しました、なんて提案が通るわけがない</p> <a class="datetime" href="https://b.hatena.ne.jp/uxlayman/20190809#bookmark-4672662343891641954"><span class="datetime-body">2019/08/09 06:16</span></a></blockquote> <p> <script src="https://b.st-hatena.com/js/comment-widget.js" charset="utf-8" async=""></script> </p> <p> </p> <p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">あとまあ、一般的にはWHY&amp;WHAT→HOWだよな。なんのためになにを、という目的が了承されてからから手段を考える。<br>しかし一般的な「下の人」はまずHOWから考える人が多いのでWHY&amp;WHATでダメ出しされる。いわゆる手段の目的化</p>&mdash; りんご4個分 (@uxlayman) <a href="https://twitter.com/uxlayman/status/1159583188647211008?ref_src=twsrc%5Etfw">2019年8月8日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p>こんなツイートもした。</p> <p> </p> <p>コメントやツイートはしたものの、しかしよくわからない。</p> <p>そもそも元記事がよくわからない。どうして3つ全部必要なものを「〇〇の人」などとセグメンテーションしたのか。WHY&amp;WHAT→HOWのことをなぜ書かないのか。</p> <p> </p> <p>ツイートで書いた「手段の目的化」はもっとよくわからない。事例は多い。とても多い。ものすごく多い。たとえば、ちょっと前なら「クラウド化」とか。いまなら「IoT対応」とか「機械学習活用」とか。手段(HOW)にのみ着目する事例はとても多い。「いや、それでなにを解決するための機械学習がなんで必要なんですか?」と毎回突っ込む。</p> <p> </p> <p>事例は多いが、でも全然わからない。<span style="text-decoration: underline;"><strong>どういう思考ロジックだといきなりHOWを考えるようになるのだろうか。</strong></span></p> <p>そして「いや、それでなにを解決するための機械学習がなんで必要なんですか?」て聞くと答えられないひともかなり多い。意味がわからない。なぜ答えられないのか。目的もなくいきなり手段を考えるなんてことあるのだろうか。</p> <p>世の中の流れをみて、まず手段を抽出して、そこから目的を逆算することはあるだろう。しかし「ご提案」してる段階なのに目的を言えないなんてことがどうして起こるのだろうか。</p> <p>客にこんな提案しても話伝わらないな、とか思わないのだろうか??</p> <p> </p> <p>社会人なりたてのときは、なにかのギャグなのかなと思うようにしていたが、そこそこ社会人生活が長くなってもいまだにわからない。そして見聞きする事例だけには事欠かない。</p> <p>どういうことなんでしょうか。だれか教えてください。 </p> uxlayman 3D Touchを採用すべきだったたった1つの領域 hatenablog://entry/10257846132641715889 2018-09-29T20:00:00+09:00 2022-02-28T21:13:52+09:00 概ね同意だけれども、3D Touchにはもっとふさわしい使いどころがあったと今でも思っている。 3D Touchが導入されたのはiPhone 6s/6s Plusからで、その前機種である6/6 plusの世代から画面が大型化された。 6/6 plus時点ですでに画面の左上に配置されたiOS伝統の「戻る」ボタンに手が届かないという操作不整合が発生しており、さらに「ホーム」と「戻る」を別々に備えるAndroid陣営に対して操作感で遅れを取っていた(そして今でもそれは解消されていない) この時点で、3D Touchをシステム操作として導入すべきだったのではなかろうか。例えば、画面の左下を強く押し込む… <p><iframe class="embed-card embed-webcard" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" title="Appleは、iPhone XRで3D Touchが失敗であることを認めた | TechCrunch Japan" src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fjp.techcrunch.com%2F2018%2F09%2F17%2F2018-09-14-the-iphone-xr-shows-apple-admitting-3d-touch-is-a-failure%2F" frameborder="0" scrolling="no"></iframe></p> <p> </p> <p>概ね同意だけれども、3D Touchにはもっとふさわしい使いどころがあったと今でも思っている。</p> <p>3D Touchが導入されたのはiPhone 6s/6s Plusからで、その前機種である6/6 plusの世代から画面が大型化された。</p> <p>6/6 plus時点ですでに画面の左上に配置されたiOS伝統の「戻る」ボタンに手が届かないという操作不整合が発生しており、さらに「ホーム」と「戻る」を別々に備えるAndroid陣営に対して操作感で遅れを取っていた(そして今でもそれは解消されていない)</p> <p> </p> <p>この時点で、3D Touchを<strong><span style="text-decoration: underline;">システム操作</span></strong>として導入すべきだったのではなかろうか。例えば、画面の左下を強く押し込むと「戻る」になる、画面の下1/3を強く押し込むとホームに戻る、とかそういうやつ。「強く押し込む」機能はアプリでコントロールできず、全アプリ共通のシステム操作としてだけ利用できると制約すべきだったのではないだろうか。</p> <p> </p> <h4>ますます複雑化するシステム操作</h4> <p>3D Touchの導入から時は流れ、iPhoneXs系列でディスプレイは全面表示が主流となった。その結果、ますます「戻る」に手が届かなくなり、上端から下に下ろす通知センターやコントロールセンターにももちろん届かず、ホームボタンはなくなって画面下端での不安定な操作を強いられている。少なくとも片手操作は破綻していると言ってよい。</p> <p>Android陣営が指紋センサーへのジェスチャーという新発明で通知アクセスなどのシステム操作を改善しているのに対し、iPhoneはシステム操作に関しては使いにくくなる一方である。</p> <p> </p> <p>もし、システムとして3D Touchを管理していれば、これらの状況にもかなり対応できたのではないか。機能が増えてもプレス感知領域を増やせば良いだけなのだから。もちろん、ユーザーはそんなプレス領域に気付くべくもないが、そこはお得意の広告戦略で「iOSの革新的操作」とか吹聴すればそれで良い。</p> <p>しかし、実際にAppleが行ったのは、この知覚性が無に等しい機能をアプリに自由に開放するという愚策だった<a href="#f-e2160ecd" name="fn-e2160ecd" title="iOS初期のころに「直感的操作」として導入したフリック操作が非常に知覚性が低く、気の利いた誰かがフリックインジケータを発明するまで「どこでつかえるかわからない」機能だったことを忘れたのだろうか">*1</a>。結局ほとんどのユーザーはアプリ毎に「どこで3D Touchが有効なのか」を発見できなかった。それに加え、3D Touchで実現できる機能はほとんどがどうでもいい機能で苦労して発見する価値もないようなものばかりだった<a href="#f-6d3a1c35" name="fn-6d3a1c35" title="唯一に近い例外は、キーボードをプレスすると文字カーソルを自由に移動できる機能。あれ、超便利。ただしあの機能があることをよく忘れてしまう。それほどまでに3D Touchは知覚性が低い機能である">*2</a>。廃れるのも当然だ。</p> <p> </p> <p>3D Touchはハードウェア機能なので、それを使ってシステムを制御できれば、ソフト部分のみを提供するAndroid陣営が一律的に模倣するのは難しい。</p> <p>そのような可能性があって、実際にハードウェア開発して量産にまでこぎつけたのに、愚策によってすべて台無しにしてしまったという印象が強い。</p> <p>なにはともあれ、RIP,3D Touch<a href="#f-098ea1d7" name="fn-098ea1d7" title="実際はiPhoneXRにないだけで、その他現行ラインナップにはすべて実装されているので全然廃止ではないけれど、縮小傾向にあることは間違いないだろう。。。">*3</a></p> <p> </p> <h4>関連エントリー</h4> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="iPhone6が露呈させるかもしれないiOSのデザインリスク - UXエンジニアになりたい人のブログ" src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fuxlayman.hatenablog.com%2Fentry%2F2014%2F08%2F30%2F205919" frameborder="0" scrolling="no"></iframe><cite class="hatena-citation"></cite></p> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="革新と大コケの両方の可能性を感じる3D Touch - UXエンジニアになりたい人のブログ" src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fuxlayman.hatenablog.com%2Fentry%2F2015%2F09%2F11%2F063500" frameborder="0" scrolling="no"></iframe><cite class="hatena-citation"><br /></cite></p> <p><cite class="hatena-citation"> </cite></p><div class="footnote"> <p class="footnote"><a href="#fn-e2160ecd" name="f-e2160ecd" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">iOS初期のころに「直感的操作」として導入したフリック操作が非常に知覚性が低く、気の利いた誰かがフリックインジケータを発明するまで「どこでつかえるかわからない」機能だったことを忘れたのだろうか</span></p> <p class="footnote"><a href="#fn-6d3a1c35" name="f-6d3a1c35" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">唯一に近い例外は、キーボードをプレスすると文字カーソルを自由に移動できる機能。あれ、超便利。ただしあの機能があることをよく忘れてしまう。それほどまでに3D Touchは知覚性が低い機能である</span></p> <p class="footnote"><a href="#fn-098ea1d7" name="f-098ea1d7" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text">実際はiPhoneXRにないだけで、その他現行ラインナップにはすべて実装されているので全然廃止ではないけれど、縮小傾向にあることは間違いないだろう。。。</span></p> </div> uxlayman サマータイムを導入しないにしても日時をすぐ文字列にする悪習をやめるべきではないか hatenablog://entry/10257846132612507684 2018-08-19T21:19:21+09:00 2022-02-28T21:13:52+09:00 「サマータイム導入はコンピュータシステム的に難あり」は本当か (1/2) サマータイムは簡単、という記事があまりにあれな件 - novtanの日常 タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ サマータイムの話。 結局のところ「データ」としてローカル日時を持ってしまっているシステムが多数あり、それらがどれくらい影響するかわからない、ということが皆が反対する理由。 対策としては結局3つ目のブログに書いてあることがすべてで、システムの内部では一貫してオフセット付きの日時またはUTCでデータを持つべきで、システム境界を超える場合も可能な限り(ユーザーに不要な手間が… <p><a href="http://blogos.com/article/317015/">「サマータイム導入はコンピュータシステム的に難あり」は本当か (1/2)</a></p> <p><a href="http://novtan.hatenablog.com/entry/2018/08/10/201046">サマータイムは簡単、という記事があまりにあれな件 - novtanの日常</a></p> <p><a href="https://www.m3tech.blog/entry/timezone-handling">タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ</a></p> <p>サマータイムの話。</p> <p>結局のところ「データ」としてローカル日時を持ってしまっているシステムが多数あり、それらがどれくらい影響するかわからない、ということが皆が反対する理由。</p> <p>対策としては結局3つ目のブログに書いてあることがすべてで、システムの内部では一貫してオフセット付きの日時またはUTCでデータを持つべきで、システム境界を超える場合も可能な限り(ユーザーに不要な手間が増えるといった例外を除き)オフセット付きで時刻を扱いましょう、というだけの話。</p> <p> </p> <p>それで、「ローカル日時を持っているデータ」って十中八九文字列ですよね?2018/08/19 23:00とか、201808192300みたいな文字列ですよね。それをDBに入れたりファイルに書き出したりしてるってことですよね?そういうの、もうやめませんか?そもそもなんのためにそんな事するの?っていうお話です。</p> <p> </p> <h4>なぜわざわざローカル日時でデータをもつのか </h4> <p>java:<a href="https://docs.oracle.com/javase/jp/8/docs/api/java/time/OffsetDateTime.html">OffsetDateTime (Java Platform SE 8)</a></p> <p>.NET:<a href="https://msdn.microsoft.com/ja-jp/library/system.datetimeoffset(v=vs.110).aspx">DateTimeOffset 構造体 (System)</a></p> <p>db:<a href="https://www.postgresql.jp/document/9.1/html/datatype-datetime.html">timestamp with timezone</a></p> <p>文字列書式:<a href="https://ja.wikipedia.org/wiki/ISO_8601">ISO 8601 - Wikipedia</a></p> <p> </p> <p>上記あげた<a href="#f-8856880b" name="fn-8856880b" title="ここにあげた仕様は比較的新しいものが多いが、しかしコンピューターの日時表現の基本は絶対日時であるUNIX timeであり、伝統的なプログラミング言語の日時型はそのラッパーなので、古い言語であっても絶対的な日時を保持するのはそれほど難しくない">*1</a>ように、各プログラム言語でも絶対日時を持って便利に使える型が用意されているし、文字列書式も国際規格があります(もちろん文字列⇔オブジェクトの変換も一意的に行える)。にもかかわらずどうしてオレオレ文字列書式を考案してシステムに組み込んでしまうのでしょうか。</p> <p> </p> <blockquote> <p>違いまーす。コンピューターが用いているのは、「データ」と「システム時刻」です。データには時刻の関連項目がありますね。みなさんに一番身近なのはファイルの更新時刻とかですね。ブログの更新時間なんてのもデータで持ってますよね。表示されるでしょ。まさかこれをずっと「内部時間で刻んている」わけないよね。X時間前、という更新時刻は当然XX:XX時というデータと今の時刻の比較をしているので、システム時間をバーンと変えたらX時間前との相対関係が変わって表示変わっちゃいますよね。</p> <p class="photo-caption"><a href="http://novtan.hatenablog.com/entry/2018/08/10/201046">サマータイムは簡単、という記事があまりにあれな件 - novtanの日常</a></p> </blockquote> <p>説明のためかもしれませんが、さも当然のようにブログの更新時刻をXX:XXデータでもってると言い切ってるあたり、サマータイム云々関係なく、またレガシーシステム云々も関係なく、日時を文字列で持つのが当然という意識が蔓延してることを示してますよね・・・(というかこの説明に関してはいろいろ・・・)</p> <p> </p> <p>日本国内限定のシステムだから201808192300って書式のほうが誰が見てもわかりやすいから?</p> <p>とはいえ連携するシステムやクラウドサービスなど、まともなシステムは絶対日時で日時表現してくるのであっちこっちでオレオレ書式に変換しなければいけませんよね?それに、文字列書式のままでは時刻演算(n日足すとかn時間足すとか)が困難なので、その度にParse/Serializeしなきゃなりませんよね。</p> <p>正直これまわりでプログラマーもどきが「なんだかわからないけど9時間ずれるんです」とか言われたの1度や2度ではないのです。いったいなんのために確立した形式があるのにオレオレ方式を考案してバグや混乱を生み出すのでしょうか。</p> <p>諸悪の根源は「ともかくわかりやすいから文字列にする」という風潮や単なる昔からの流れであると思われ、そういうわけのわからない悪習はもうやめてほしいと思うのですがいかがでしょうか。</p> <p> </p> <h4>おまけ </h4> <blockquote> <p>中小企業向けの会計ソフトを手がけるITベンチャー「freee(フリー)」(東京)の社内SNSでは、政府のサマータイム検討方針が報じられた6日、エンジニアや営業担当者らから疑問を投げかける投稿が相次いだ。</p> <p>(中略)</p> <p> エンジニアの浅越光一さんは「対応に1カ月かかるのか、半年かかるのか、やってみないとわからない。その対応にかける時間があれば、新サービスの開発がどれほどできるかと思うと、もったいない……」とため息をつく。</p> <p class="photo-caption"><a href="https://www.asahi.com/articles/ASL8B4RG9L8BULFA01B.html">サマータイム、IT業界に拒絶反応 よみがえる苦い記憶:朝日新聞デジタル</a></p> </blockquote> <p>レガシーシステムを多数抱える会社ならともかく、さすがに2012年創業の会社で、海外進出をめざしてるクラウドサービスの会社がこの感じはかなりイメージダウンだとおもうのですがいかがでしょうか(好意的にみれば自社サービスは大丈夫で連携システムのつなぎを心配していると取れなくもないですが)</p> <p> </p><div class="footnote"> <p class="footnote"><a href="#fn-8856880b" name="f-8856880b" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">ここにあげた仕様は比較的新しいものが多いが、しかしコンピューターの日時表現の基本は絶対日時であるUNIX timeであり、伝統的なプログラミング言語の日時型はそのラッパーなので、古い言語であっても絶対的な日時を保持するのはそれほど難しくない</span></p> </div> uxlayman ウォーターフォール型開発を教科書通りやると失敗する hatenablog://entry/17391345971644014123 2018-05-13T18:55:00+09:00 2022-02-28T21:13:53+09:00 常識かと思ってましたが、業界人であっても開発経験のない人には伝わらないことが多いので、書きます。 なお、ウォーターフォール型といっても明確な定義があるわけではないので、ありがちな以下のモデルを題材にします。 via 開発プロセスの基本を学ぶ | 日経 xTECH(クロステック) なぜ失敗するか ウォーターフォールの各フェーズの作業内容や成果物を上記のように定義すると、非常にわかりやすいです。が、失敗します*1。 要件定義/外部設計は、客がこう言っていた/客が言ってることを実現する画面はこんなのだ、という形で簡単に進んで、内部設計段階で詰まります。なぜなら、外部設計成果の実現可能性を検証していな… <p>常識かと思ってましたが、業界人であっても開発経験のない人には伝わらないことが多いので、書きます。</p> <p>なお、ウォーターフォール型といっても明確な定義があるわけではないので、ありがちな以下のモデルを題材にします。</p> <p><a class="http-image" href="http://tech.nikkeibp.co.jp/it/article/lecture/20061130/255501/zu02.jpg" target="_blank" rel="noopener"><img class="http-image" src="http://tech.nikkeibp.co.jp/it/article/lecture/20061130/255501/zu02.jpg" alt="http://tech.nikkeibp.co.jp/it/article/lecture/20061130/255501/zu02.jpg" /></a></p> <p class="photo-caption">via <a href="http://tech.nikkeibp.co.jp/it/article/lecture/20061130/255501/">開発プロセスの基本を学ぶ | 日経 xTECH(クロステック)</a></p> <p> </p> <h3>なぜ失敗するか</h3> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20180513113904p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20180513/20180513113904.png" alt="f:id:uxlayman:20180513113904p:plain" /></p> <p>ウォーターフォールの各フェーズの作業内容や成果物を上記のように定義すると、非常にわかりやすいです。が、失敗します<a href="#f-e6bbc6dc" name="fn-e6bbc6dc" title="外部設計や内部設計は母数を要員数で割って、1日あたりの記載数かなんかを成果指標にしてスケジューリングする、といったプロジェクト管理をしているとこの時点で即炎上です">*1</a>。</p> <p>要件定義/外部設計は、客がこう言っていた/客が言ってることを実現する画面はこんなのだ、という形で簡単に進んで、内部設計段階で詰まります。なぜなら、外部設計成果の実現可能性を検証していないから。</p> <ul> <li>ある画面と別の画面との処理内容がどうやっても競合する</li> <li>画面表示に必要なデータを抽出できない</li> </ul> <p>こういう問題が噴出します。そしてそもそもどういう前提で外部仕様作ったんだよ上流は、というネットでよく聞く上流対下請けの構図になります。</p> <p>単純な話です。</p> <p> </p> <p> </p> <h3>どうすればよいか</h3> <p>本来の意味での設計(デザイン)が必要です。<span style="text-decoration: underline;"><strong>設計とは矛盾なく整合した実現方式・方針(≒アーキテクチャ)の検討</strong></span>です。</p> <p>外部設計書や内部設計書の作成はその共通方針に基づいた個別項目の詳細記載で、<span style="text-decoration: underline;"><strong>外部設計や内部設計より前に「アーキテクチャ設計」は終わっているべき</strong></span>なのです。</p> <p>設計を単に別の人が書いたものを変換する単純作業ととらえるから失敗するのです。</p> <p>うちのプロジェクトにはそんなフェーズ全くないよ?という方。設計開始時に「なんでも相談できる人」が配置されて仕様を相談できるようになってたりしないですか?そうであるなら、アーキテクチャ設計結果は彼の頭のなかにあります。</p> <p> </p> <p>システム開発経験がない人の勘違いは、「システム開発手法」のような普遍的な方法があって、それにそって文書を整備していけば自動的にシステムは出来上がる、というのが一番多い印象です。</p> <p>こういう先入観で入ると、アーキテクチャがなにを意味しているかわからなくなってしまいます。プログラミングのこと?プログラミングのスキルはないしなあ、といった具合に。</p> <p>かくして設計書のレビュー率を上げるとか、そういう頓珍漢な施策に走って更に事態を悪化させることになります<a href="#f-788aa161" name="fn-788aa161" title="定義したアーキテクチャによって表現する内容は変わるので、うまくいっていないのであれば普通は設計書の体系が足りない">*2</a>。</p> <p> </p> <h3>成功することもあるのはなぜか</h3> <p>これだけ見ると、ウォーターフォールプ型開発は教科書通りやると毎回失敗するように見え、プロセスとして致命的な欠陥があるように見えます。しかし、現実には毎度毎度すべてのプロジェクトが炎上するわけではありません。なぜでしょうか。</p> <h4>理由1:アーキテクチャが固定化している</h4> <ul> <li>既に実現したことのあるプロジェクトのパターン違い</li> <li>既存の納品物の改修・改訂</li> <li>パッケージアプリケーションを中心としたSI開発</li> </ul> <p>などは教科書どおりのウォーターフォールでも失敗しないことが多いです。なぜならアーキテクチャ=矛盾なく整合した実現方式・方針が関係者間で既に共有できているからです。</p> <p> </p> <p>結局のところ、アーキテクチャが皆で共有されていれば、そのレビューを行うこともでき、問題をコントロールできるのです。</p> <p>ところで、外部設計の成果物セットとして、「画面設計書」「論理DB設計書」「ファイル設計書」などが定義されることが多いですが、外部設計という外から見える機能を定義するフェーズにも関わらず、「DB」「ファイル」のような物理名称が用いられることに違和感を感じないでしょうか。</p> <p>あれは、実質的にはクライアント・サーバー(クラサバ)型アーキテクチャの成果物文書なのです。クライアント・サーバー型アーキテクチャでは、基本はDBの内容を読み書きするための画面があって、データの定義やデータの整合性の確認といった満たすべき制約はDBの制約として表現されるので、アーキテクチャ成果物資料として画面一覧、DB定義(CRUD付き)という定義がされるのは理にかなっているのです。</p> <p>昨今、環境の変化や複雑化する要件に対応してさまざまなアーキテクチャが考案されており、そのいずれもクラサバモデルのようにシンプルではありません。Web3層アプリのようにビジネスロジック層の役割が強かったり、SPAのようにUI層の役割が強い場合は、それに即した設計資料が必要になるのは必然です。どうでしょうか?アーキテクチャが変わったにもかかわらず、昔ながらの設計書を使っているならほぼ炎上確実<a href="#f-c155e55c" name="fn-c155e55c" title="SIerなんかはさまざまな要求に対応したさまざまなシステム実現方式を経験しているはずなので、どういうアーキテクチャに対してどういう設計成果物を定義すればよいかというノウハウが溜まっていそうです。しかし、(観測範囲内では)クラサバ時代の成功体験に引きづられて(?)昔の設計書フォーマットをずっと使い続けたりして事態を悪化させることが多いように見えて嘆かわしいです。">*3</a>でしょう。</p> <h4>理由2:スーパーアーキテクトがいる</h4> <p>上でも少し書きましたが、要求と実現方式を完璧にイメージし、外部設計も内部設計も「なんでも相談できる人」がいれば失敗しません。</p> <p>新しいこと(アーキテクチャが固定化されてないこと)をやろうとして、プロセス的なサポートがない場合は、プロジェクトの成功如何は結局この個人の能力に依存することになります。</p> <h5>アジャイル</h5> <p>スーパーアーキテクトがいたとして、個人の能力には限界があります。</p> <p>実現方式がすべての機能をカバーできるとどうやって証明すればよいでしょうか。そもそも、すべての機能をカバーできる実現方式を、 机上で考えることができるのでしょうか。</p> <p>アジャイルはこういう事態に対して「矛盾なく整合した実現方式・方針」を確立するために必然な方式なのです。</p> <p> </p> <h3>外部設計/内部設計 vs 基本設計/詳細設計</h3> <p><a class="http-image" href="https://thinkit.co.jp/sites/default/files/articles/225503.png" target="_blank" rel="noopener"><img class="http-image" src="https://thinkit.co.jp/sites/default/files/articles/225503.png" alt="https://thinkit.co.jp/sites/default/files/articles/225503.png" /></a></p> <p class="photo-caption">via <a href="https://thinkit.co.jp/story/2011/10/04/2255">いろいろなプロセス ~V字モデルとスクラム~ | Think IT(シンクイット)</a></p> <p>今まで、外部設計/内部設計という用語と使ってきましたが、基本設計/詳細設計という用語が使われることも同じくらい多いようです。<cite class="hatena-citation"></cite></p> <p>基本設計がアーキテクチャ設計を指していて、詳細設計の中に外部的側面と内部的側面(ユーザー操作によってテスト可能か否か)があるという意味合いだと、わたしのイメージと近いです。が、アーキテクチャ設計はテストによって検証できないので上の絵は間違っています。</p> <p>なんでもよいですが難しい話ではないので、ISOだかIPAだかが定義して統一してほしいです。</p> <ul> <li>アーキテクチャ設計:矛盾なく整合した実現方式・方針の検討。テストで検証できない</li> <li>外部設計:アーキテクチャ設計に基づく、外部(人・他システム)との入出力の定義。システムに対する入力を実行することでテスト可能</li> <li>内部設計:アーキテクチャ設計に基づく、内部処理の定義。プログラムモジュール内の動作テスト(ユニットテスト)でテスト可能</li> </ul> <p> </p> <h4>まとめ</h4> <p>ウォーターフォール型開発を教科書通りやると失敗する。なぜなら、本来の設計=<span style="text-decoration: underline;"><strong>アーキテクチャ設計=矛盾なく整合した実現方式・方針の検討 が必要であることが教科書に記載されていないから</strong></span>。</p> <p>となります。ポイントとしては</p> <ul> <li>アーキテクチャという単語が理解できない</li> <li>対象とするシステムがどんなアーキテクチャで実現されるのかわからない</li> <li>基本設計・外部設計・内部設計という用語がぐちゃぐちゃ</li> <li>設計書体系が固定化されている</li> <li>固定化された設計書体型に対するプロセス管理も固定化されている</li> </ul> <p>といった環境で、新しいことをやろうとするときが失敗への黄色信号でしょうか。</p> <p>もっとシンプルに言えば、「設計=流れ作業の単純文書化作業」という誤った価値観滅びよ、ということです。</p> <p>ご査収ください。</p><div class="footnote"> <p class="footnote"><a href="#fn-e6bbc6dc" name="f-e6bbc6dc" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">外部設計や内部設計は母数を要員数で割って、1日あたりの記載数かなんかを成果指標にしてスケジューリングする、といったプロジェクト管理をしているとこの時点で即炎上です</span></p> <p class="footnote"><a href="#fn-788aa161" name="f-788aa161" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">定義したアーキテクチャによって表現する内容は変わるので、うまくいっていないのであれば普通は設計書の体系が足りない</span></p> <p class="footnote"><a href="#fn-c155e55c" name="f-c155e55c" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text">SIerなんかはさまざまな要求に対応したさまざまなシステム実現方式を経験しているはずなので、どういうアーキテクチャに対してどういう設計成果物を定義すればよいかというノウハウが溜まっていそうです。しかし、(観測範囲内では)クラサバ時代の成功体験に引きづられて(?)昔の設計書フォーマットをずっと使い続けたりして事態を悪化させることが多いように見えて嘆かわしいです。</span></p> </div> uxlayman FaceIDに対する情緒的なクレーム hatenablog://entry/8599973812322538227 2017-11-30T22:46:46+09:00 2022-02-28T21:13:56+09:00 iPhone Xをゲットして約一ヶ月が経ちます。 ウリの一つであったFaceID(顔認証)も、前評判や各所でのレビューにもある通り、爆速で認証できていてすごいなと感じています。見たときにはもうすでに認証されている、っていう話もまさにそんな感じ。メガネをしてても大丈夫だし、暗くても大丈夫だし、概ね認識率はかなり高いという印象を持っています。 ただ、寝起きとかは認証がされにくいんです。まあ考えてみれば当たり前のことなんですけど、布団で顔の一部が隠れてたり、頬に腕を当ててたりするのでフェイスラインが見えないんで認証できないんでしょうね。マスクをしてると認証通りにくいともいうし、妥当なのかなと思います… <p>iPhone Xをゲットして約一ヶ月が経ちます。</p> <p>ウリの一つであったFaceID(顔認証)も、前評判や各所でのレビューにもある通り、爆速で認証できていてすごいなと感じています。見たときにはもうすでに認証されている、っていう話もまさにそんな感じ。メガネをしてても大丈夫だし、暗くても大丈夫だし、概ね認識率はかなり高いという印象を持っています。</p> <p> </p> <p>ただ、寝起きとかは認証がされにくいんです。まあ考えてみれば当たり前のことなんですけど、布団で顔の一部が隠れてたり、頬に腕を当ててたりするのでフェイスラインが見えないんで認証できないんでしょうね。マスクをしてると認証通りにくいともいうし、妥当なのかなと思います。</p> <p>そんなふうに、理屈はよく分かるし理解もして納得もしているのですが、でも、それでもですね、顔認証に失敗すると<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。ものすごく<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。</p> <p> </p> <p>おい、<strong>昼間はあんな爆速で見た瞬間に認証OKだったのに、たかが布団のせいでだめになるのかよ。そんな程度の気持ちだったのかよ!</strong>的な気分になって<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。</p> <p>まあでも、布団のせいだよなとおもって、ちゃんと顔をしっかり見えるようにして、iPhoneと向き合います。でもやっぱり顔認証に失敗します。</p> <p>FaceIDもTouchID(指紋認証)も、何度か認証に失敗すると安全のためパスコード入力モードに移行するという仕様が発動するからです。よからぬことを企むひとを排除するという意図で、理にかなった仕様だと思います。とても良く理解しています。</p> <p>でもめっちゃ<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。<strong>わざわざ顔を見えるようにしてやったのに見もしないで不審人物扱いかよ!</strong>的な気分になって<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。</p> <p> </p> <p>TouchIDのときも認証失敗してパスコード認証モードに移行することはありましたが、そこまで気になりませんでした。ホームボタンに指を当てるという行為と画面をタップしてパスコード入力するという行為が近いからでしょうか。</p> <p>一方、FaceIDの場合はとても<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。<strong>わざわざ見てやったのに、結局押させるのかよ。見るのと押すのじゃ大違いじゃねーか!</strong>的な気分になって<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。結局見てロックを解除したあとはタップするなり何なりして画面を触ることになるので、冷静に考えるとたいして手間や操作感は変わらないのですが、それでも<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。理屈ではないのです。</p> <p> </p> <p>連続で認証失敗→パスコード認証モードに移行、の話は他にも腹が立つ話があります。</p> <p>iPhoneを手に持って歩いてるときなど、なにかの拍子(傾けてロック解除機能とかの影響が大きいのかな?)に画面がONになって、いつの間にか認証失敗を繰り返した影響で、画面を見た瞬間にパスコード認証モードになっていることがまあまああるのです。</p> <p>理屈としては今書いたとおりなのでしょう。挙動としては正しいのでしょう。それはよくわかっているのですが<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。<strong>お前は一体、街の雑踏のどの部分をオレと認識したのか!オレはそんな雑踏と見間違えるような顔なのか?</strong>的な気分になって<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。</p> <p> </p> <p>iPhone Xはまだもの珍しいので「ちょっと見せて」的な感じでよく触られます。で、なんか画面をこっちに向けて認証させて中身を見ようとしてくる輩も現れるのです。余談ですが、こういう人ほんとウザいですよね。</p> <p>ただ、FaceIDには「注視が必要」というオプションがあります。顔を認識しただけでなくて、ちゃんとカメラの方を見ているかどうかを判定して、見てるときだけロックを解除する、って機能です。</p> <p>このことをよく知っているわたくしは、そのウザい輩に画面を向けられたときも目を伏して決してカメラを見ないように気をつけます。</p> <p>なのに、認証されるのです!とても<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。<span style="text-decoration: underline;"><strong>見てねえじゃねえか!絶対見てねえじゃねえか!なんでわかってくれねえんだ!</strong></span>的な気分になって、とても<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。</p> <p> </p> <p>この注視機能もまた腹立ちの種で、iPhoneを机においてる段階で画面オンにして見つめると、結構失敗します。でも、なんで失敗したのかわからないのです。FaceIDの視野角を確認するすべがないので一部しか顔が映ってないから失敗したのか、注視してないと判断されたのか、よくわからなくて<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。</p> <p>持ち上げるのがめんどくさいので机においたまま認証させようとしてるのに、なにが悪いのかわからず認証に失敗するので<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。そして、しょうがないなあと持ち上げたころにはまたパスコード認証モードになっていて、さらに<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。</p> <p> </p> <p>そうそう、視野角といえば、画面が横向きのときに顔認証が行えないことも<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。<strong>いやいや、オレ、横になったくらいで誰だかわかんないような顔なの?</strong>的な気分になって<strong><span style="text-decoration: underline;">腹が立つ</span></strong>のです。</p> <p> </p> <h3>まとめ</h3> <p>腹が立つシリーズをいくつかお伝えしましが、いかがでしょうか。理屈はわかっているのに腹が立つ、という意味で「情緒的」というタイトルをつけさせていただきました。</p> <p>興味深いのは、TouchID(指紋認証)とFaceIDはほぼおなじ挙動であるのに、TouchIDではこのような気持ちにはならないことです。それと、FaceIDが失敗すると「お前なあ!」的な、相手が人であるかのように感情を揺さぶられます。</p> <p> </p> <p>思うに、顔がパーソナリティの代表であることが大きく関係してるのでしょう。</p> <p>アイドルの追っかけじゃないですけど、顔を認識してもらえるのは嬉しいことです。顔を覚えてもらえることは自分を認めてもらえてるという実感の第一歩です。顔を突き合わせることはコミュニケーションの基本です。このへんが、人生生きてきても他人との違いなんて全く意識しないし、人と見せ合うこともないような指紋との違いです。</p> <p>そういうパーソナリティの代表である「顔」を使って認証するだのしないだのって機能をつけるにあたっては、もう少しセンシティブに考えるべきではなかったのでしょうか。</p> <p>ご査収くださいませ。</p> <p> </p> <h5>おまけ</h5> <p>スマートスピーカーがブームですが、Siriを始めとして、音声認識が自分を汲み取ってくれないときも<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。</p> <p>ヘイ!シリ!</p> <p>ヘイ!!!ヘイ!!!シリ!!!</p> <p>ヘイ!ヘイ!ヘイ!バーカ!</p> <p>というようにキーワードなんて忘れるくらい<span style="text-decoration: underline;"><strong>腹が立つ</strong></span>のです。機会があればこのシリーズも是非ご査収いただければとおもいます。</p> <p> </p> uxlayman aiboベーシックプランという名称には風情がない hatenablog://entry/8599973812313592107 2017-11-01T22:38:48+09:00 2022-02-28T21:13:56+09:00 新aiboが発表されました。本体が20万弱で、月額料金(要はクラウド運営費)が3000円弱。そうなんですか。高いかなーとも思うけどクラウド側に主体があるPS Nowが2500円だから、まあそういうもんなのかなあとも思います。 で、問題なのはその月額料金の名称が「aiboベーシックプラン」であること。 新型aiboをソニーが発表。自ら好奇心を持った、生活のパートナーとなる犬型ロボット - Engadget 日本版 名称は「ご飯代」とかにしてほしい。“aiboベーシックプラン” 2017/11/01 13:06 新型aiboをソニーが発表。自ら好奇心を持った、生活のパートナーとなる犬型ロボット -… <p>新aiboが発表されました。本体が20万弱で、月額料金(要はクラウド運営費)が3000円弱。そうなんですか。高いかなーとも思うけどクラウド側に主体があるPS Nowが2500円だから、まあそういうもんなのかなあとも思います。</p> <p> </p> <p>で、問題なのはその月額料金の名称が「aiboベーシックプラン」であること。</p> <blockquote class="hatena-bookmark-comment"><a class="comment-info" href="http://b.hatena.ne.jp/entry/347514518/comment/GENS" data-user-id="GENS" data-entry-url="http://b.hatena.ne.jp/entry/japanese.engadget.com/2017/10/31/aibo/" data-original-href="http://japanese.engadget.com/2017/10/31/aibo/" data-entry-favicon="http://cdn-ak.favicon.st-hatena.com/?url=http%3A%2F%2Fjapanese.engadget.com%2F2017%2F10%2F31%2Faibo%2F" data-user-icon="/users/GE/GENS/profile.gif">新型aiboをソニーが発表。自ら好奇心を持った、生活のパートナーとなる犬型ロボット - Engadget 日本版</a><br /> <p style="clear: left;">名称は「ご飯代」とかにしてほしい。“aiboベーシックプラン”</p> <a class="datetime" href="http://b.hatena.ne.jp/GENS/20171101#bookmark-347514518"><span class="datetime-body">2017/11/01 13:06</span></a></blockquote> <p> <script src="https://b.st-hatena.com/js/comment-widget.js" charset="utf-8" async=""></script> <cite class="hatena-citation"></cite></p> <blockquote class="hatena-bookmark-comment"><a class="comment-info" href="http://b.hatena.ne.jp/entry/347514518/comment/umiusi45" data-user-id="umiusi45" data-entry-url="http://b.hatena.ne.jp/entry/japanese.engadget.com/2017/10/31/aibo/" data-original-href="http://japanese.engadget.com/2017/10/31/aibo/" data-entry-favicon="http://cdn-ak.favicon.st-hatena.com/?url=http%3A%2F%2Fjapanese.engadget.com%2F2017%2F10%2F31%2Faibo%2F" data-user-icon="/users/um/umiusi45/profile.gif">新型aiboをソニーが発表。自ら好奇心を持った、生活のパートナーとなる犬型ロボット - Engadget 日本版</a> <ul class="comment-tag" style="list-style: none; margin: 0px;"> <li style="float: left;">[<a href="http://b.hatena.ne.jp/search/tag?q=%E8%B6%A3%E5%91%B3">趣味</a>]</li> <li style="float: left;">[<a href="http://b.hatena.ne.jp/search/tag?q=%E3%81%8A%E3%81%A3%E3%81%95%E3%82%93%E3%81%BB%E3%81%84%E3%81%BB%E3%81%84">おっさんほいほい</a>]</li> <li style="float: left;">[<a href="http://b.hatena.ne.jp/search/tag?q=%E3%82%BD%E3%83%8B%E3%83%BC">ソニー</a>]</li> </ul> <br /> <p style="clear: left;">吹きあがるコレジャナイ感&「ただし使用には別途「aiboベーシックプラン」への加入が必要」っていうまるでスマホ感覚。今も続く熱烈なアイボ信者のほとんどが高齢者だと分かっていての鬼畜の所業かしら</p> <a class="datetime" href="http://b.hatena.ne.jp/umiusi45/20171101#bookmark-347514518"><span class="datetime-body">2017/11/01 12:19</span></a> </blockquote> <blockquote class="twitter-tweet" data-lang="ja"> <p dir="ltr" lang="ja">AIBOベーシックプランとか言われると携帯電話感が出てしまうのでドッグフードの缶詰(フタを開けるとQRコードがプリントしてある)を毎月買ってくるみたいな方が風情があるのではないか</p> — 柞刈湯葉(イスカリユバ) (@yubais) <a href="https://twitter.com/yubais/status/925569243415842816?ref_src=twsrc%5Etfw">2017年11月1日</a></blockquote> <p> <script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p> </p> <p> <script src="https://b.st-hatena.com/js/comment-widget.js" charset="utf-8" async=""></script> </p> <p>それな。ほんとそれ。まさにそれ。</p> <p>どうしてこんなスマホプランみたいな名称にしてしまったのか。どうして「生き物のお世話」を感じさせる名称にできなかったのか。ハード面ではメカメカしい外観から本物の犬のような外観に変更したのに、ソフト面でなぜ電化製品のようなプラン名をつけてしまったのか。ちぐはぐの見本のようなお話です。</p> <p> </p> <blockquote> <p> スマートスピーカーが注目される中で、人との対話という点にも質問が及んだが、「企画段階で揉めたが、aiboは犬型のロボット。実は先代は犬型と呼んでなかったのですが……。今回は明確に犬を想定して作ったので、人の言葉は話さない。ただ音声は認識している。また、別の製品では、話すというインタラクションもありえる」とした。なお、“鳴く”機能は備えている。</p> <p class="photo-caption">via <a href="https://av.watch.impress.co.jp/docs/news/1089275.html">ソニーのロボット犬「aibo」が復活! 心のつながりをもつエンタメロボ。19.8万円 - AV Watch</a></p> </blockquote> <p>スマートスピーカーじゃないんでしょ?犬なんでしょ?犬であることが大事なんでしょ?そこわかってて、わざわざ人の言葉を話さないようにするってとこまで考慮して丁寧に企画を進めてたはずなのになぜ・・・。</p> <p> </p> <p>プラン名なんて単に言葉尻だけの問題なのですが、世界観というものは作り上げるのは苦労するのに、言葉尻だけで簡単に壊れてしまうものなのです。</p> <p>犬っぽい外観に似せて、なんちゃらアクチュエーターで犬っぽい動きを再現させて、演出のために人間の言葉は話さないようにして、クラウドと連携して“人に寄り添う”を実現して、っていう苦労をしてやっと作り上げた世界観がプラン名の言葉尻1つでぶっ飛んでしまう。</p> <p> </p> <p>結局、プロダクトに対してどういうイメージを持つかは、どういう世界観を提供しているかによるところが大きいですよね。世界観が、風情とか情緒とかそういう言葉で表現できる。良いプロダクトには良い世界観があって、すなわち風情がある。aiboベーシックプランという名称は世界観をぶち壊していて、すなわち風情がない。プロダクトの良し悪しを風情のあるなしで語るっていうのは面白いのではないかと思います。そこに風情はあるのかい?ってね。</p> <p>先の引用文章からすると、製品が完成して、周辺整える段階まではちゃんと気をつけていたことが伺えますが、最後の詰めでなにか行き違いがあったのでしょうか。11/1にワンワンワンで発表です、なんてことを考える前にやることがあったのではないかな、と悲しい気分になりました。</p> <p> </p> <h5>おまけ</h5> <blockquote> <p>「ユーザーが使っている環境をバックアップできる。買い替えた場合は、新しいaiboにそれまでのデータをダウンロードして引き継ぐこともできる」という。</p> <p class="photo-caption">via <a href="https://av.watch.impress.co.jp/docs/news/1089275.html">ソニーのロボット犬「aibo」が復活! 心のつながりをもつエンタメロボ。19.8万円 - AV Watch</a></p> </blockquote> <p>いやだから。ダウンロードて。風情を大事にしてほしいです。 </p> uxlayman はてなブックマークiOSアプリはマテリアルデザインの悪い見本 hatenablog://entry/10328749687223598939 2017-03-05T19:30:00+09:00 2022-02-28T21:13:52+09:00 はてなブックマークのiOSアプリを真面目に使ってみたらひどい出来だったので書きます。 基本構造 まずはアプリの基本構造をおさらいします。このアプリは大きな画面構成として メイン(様々なエントリー一覧) フィード マイページ の3つからなっています。 <p>はてなブックマークのiOSアプリを真面目に使ってみたらひどい出来だったので書きます。</p> <p> </p> <h3>基本構造</h3> <p>まずはアプリの基本構造をおさらいします。このアプリは大きな画面構成として</p> <ul> <li>メイン(様々なエントリー一覧)</li> <li>フィード</li> <li>マイページ</li> </ul> <p>の3つからなっています。</p> <p> </p> <p> </p> <p>それぞれの画面と親子関係、各画面を呼び出すための操作をまとめると以下のようになります。<span style="color: #0000cc;">[ ]で囲まれた青文字がUI表現</span>で、<span style="color: #ff0000;">赤文字部分が最終操作画面</span>とその説明です。★が初期画面です。</p> <p>まとめたつもりなんですが読みにくいし主題とあまり関係がないので、面倒な人は下の画像まで読み飛ばしてください</p> <ul> <li><span style="color: #0000cc;">[フローティング操作ボタン]</span></li> <ul> <li>メイン(様々なエントリー一覧) <ul> <li><span style="color: #0000cc;">[ツールバー横のナビゲーションドロワーボタンから左部ナビゲーション:タイトルは「話題を探す」]</span> <ul> <li>[仕切り線:カテゴリー]</li> <li>ホーム <ul> <li><span style="color: #0000cc;">[タブ]</span> <ul> <li><span style="color: #ff0000;">人気エントリー(いわゆるホッテントリ)★</span></li> <li><span style="color: #ff0000;">新着エントリー(いわゆる全体新着)</span></li> <li><span style="color: #ff0000;">まわりの話題</span></li> </ul> </li> </ul> </li> <li>世の中 <ul> <li><span style="color: #0000cc;">[タブ]</span> <ul> <li><span style="color: #ff0000;">人気エントリー(世の中カテゴリのホッテントリ)</span></li> <li><span style="color: #ff0000;">新着エントリー(世の中カテゴリの新着)</span></li> <li><span style="color: #ff0000;">まわりの話題</span></li> </ul> </li> </ul> </li> <li>以下ブックマークのカテゴリーごとにタブ切り替えでの同構成</li> <li>[仕切り線:ピックアップ]</li> <li><span style="color: #ff0000;">なんらかのロジックによってキーワードが3つ並ぶ。選択時は全面マテリアルが下からせりあがり、エントリー一覧</span></li> <li>[仕切り線:コレクション]</li> <li><span style="color: #ff0000;">トピック(各日の話題キーワードのリスト、タップするとそのキーワードに関係したエントリーリスト)</span></li> <li><span style="color: #ff0000;">日めくり(日毎のホッテントリリスト、全ジャンルがタブで表現されている)</span></li> <li><span style="color: #ff0000;">動画・画像(よくわからない。エントリーのリストだがタイル状にならべてある)</span></li> </ul> </li> </ul> <ul> <li><span style="color: #0000cc;">[フローティングボタン下:後で読む]</span></li> </ul> <ul> <li><span style="color: #0000cc;">[ツールバー横ボタン:マイホットエントリー]</span> <ul> <li><span style="color: #ff0000;">マイホットエントリー(何が並んでるか不明だが、エントリーのリスト)</span></li> </ul> </li> </ul> <ul> <li><span style="color: #0000cc;">[ツールバー横ボタン:検索]</span> <ul> <li><span style="color: #0000cc;">[非マテリアルデザインのタブ]</span> <ul> <li><span style="color: #ff0000;">タグ(恐らく検索キーワード=タグのエントリーリスト)</span></li> <li><span style="color: #ff0000;">キーワード(恐らく検索キーワードが 含まれるエントリーリスト)</span></li> </ul> </li> </ul> </li> </ul> </li> <li>フィード <ul> <li><span style="color: #0000cc;">[非マテリアルデザインのタブ]</span> <ul> <li>関心ワード(よくわからないがエントリーリスト)</li> <li>お気に入り(たぶんお気に入りはてブユーザーのエントリーリスト)</li> </ul> </li> </ul> </li> <li>マイページ <ul> <li><span style="color: #0000cc;">[非マテリアルデザインのタブ]</span> <ul> <li><span style="color: #ff0000;">ブックマーク(自分のブクマ)</span></li> <li><span style="color: #ff0000;">最近見た(ロジック不明だが見たことのあるブクマ?)</span></li> <li><span style="color: #ff0000;">後で読む(後で読むエントリー)</span></li> </ul> </li> <li><span style="color: #0000cc;">[フローティングボタン下:ブックマーク追加(+)ボタン]</span> <ul> <li><span style="color: #ff0000;">iOS標準ダイアログ。ブックマークURL入力用</span></li> </ul> </li> <li><span style="color: #0000cc;">[ツールバー左:通知アイコン(ベルのような絵)]</span> <ul> <li><span style="color: #ff0000;">はてなサービス全般の通知リスト</span></li> </ul> </li> <li><span style="color: #0000cc;">[ツールバー右:検索アイコン(書類の上に虫眼鏡)]</span> <ul> <li><span style="color: #ff0000;">自ブックマークのみの検索マテリアル</span></li> </ul> </li> </ul> </li> </ul> </ul> <p> </p> <p>このツリー作るのすごい苦労したんですが、全然読みにくいですね。以下に3画面構成の概要を示すので、なんとなく察してください </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305161240p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305161240.png" alt="f:id:uxlayman:20170305161240p:plain" /></p> <p class="photo-caption">はてなブックマークアプリ主要3画面の構成</p> <p class="photo-caption"> </p> <h3>マテリアルデザインとは</h3> <p>マテリアルデザインはGoogleが2014年にAndroid Lと同時に発表した新しいデザイン言語です。</p> <p>画面上の要素を薄さ1pxのマテリアル(公式には紙のメタファーであるとのこと)として定義して、その重なりによって画面や画面を形作る世界観を定義した、デバイス/プラットフォーム非依存の言語です。</p> <p> </p> <p>どういうのがマテリアルデザインか、ということですが、以下の左画面の例にあるような左からリッチなハンバーガーメニュー(ナビゲーションドロワー)が出て、同じく画面例の画面右下にあるような丸いボタンがあれば、そうだと判断して良いのではないでしょうか。<a href="#f-9c1f427a" name="fn-9c1f427a" title="ググったらフラットデザインと関係あるか、という話題が結構ありましたが、あるといえばありますね。マテリアル自体は常に1pxで、盛り上がったりへこんだりしません(フラット)。しかし、マテリアルは宙に浮いた状態で定義される(=高度を持つ)ので、影は存在します">*1</a></p> <p class="photo-caption"><a class="http-image" href="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B8v7jImPsDi-eV81TDFrR2ZPU1E/whatismaterial_3d_elevation4.png" target="_blank"><img class="http-image" src="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B8v7jImPsDi-eV81TDFrR2ZPU1E/whatismaterial_3d_elevation4.png" alt="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B8v7jImPsDi-eV81TDFrR2ZPU1E/whatismaterial_3d_elevation4.png" /></a></p> <p class="photo-caption">via <a href="https://material.io/guidelines/material-design/elevation-shadows.html#elevation-shadows-elevation-android">Elevation &amp; shadows - Material design - Material design guidelines</a></p> <p> </p> <p>はてブアプリは丸いボタンが利用されていて、また恐らくマテリアルデザイン対応のライブラリを利用してマテリアルデザイン風のタブを出していると推察されるので「対応している」とみなしています。</p> <p> </p> <h5>マテリアルデザインのガイドライン</h5> <p><a href="https://material.io/guidelines/">Introduction - Material design - Material design guidelines</a></p> <p><a href="https://material.io/jp/guidelines/">マテリアル – 日本語</a></p> <p>かなりわかりやすい英語版と、日本語版もあります。日本語版はなぜかPDFでみにくいです。本記事の引用は、基本は日本語のガイドラインPDFからの引用です。</p> <p> </p> <p> </p> <h3>何が間違っているか</h3> <h4>フローティング操作ボタンの扱い</h4> <p><a class="http-image" href="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B7WCemMG6e0VN20tOXJoUjVxQjg/components_buttons_fab.png" target="_blank"><img class="http-image" src="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B7WCemMG6e0VN20tOXJoUjVxQjg/components_buttons_fab.png" alt="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B7WCemMG6e0VN20tOXJoUjVxQjg/components_buttons_fab.png" /></a></p> <p class="photo-caption"><a href="https://material.io/guidelines/components/buttons-floating-action-button.html#">Buttons: Floating Action Button - Components - Material design guidelines</a></p> <p>完全におかしいのは、マテリアルデザインを象徴する、右下の方にあってスクローリングに追従しない丸いボタン、フローティング操作ボタンの使い方です。</p> <p> </p> <h5>ナビゲーションにフローティング操作ボタンを使っている</h5> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305180918p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305180918.png" alt="f:id:uxlayman:20170305180918p:plain" /></p> <p>はてなブックマークアプリは全画面で常に上下に2つフローティングボタンが配置されており、上側のボタンを押すと、横に3つのボタンが広がります。</p> <p>この3ボタンを「マイページ・フィード・メイン」という主要な3画面を移動するためのナビゲーションに利用しています。</p> <p>しかし、ガイドに以下に記載されているように、フローティング操作ボタンはこのような目的で利用するものではありません。</p> <blockquote> <p>フローティング操作ボタンは特定の操作を促す目的で使用します。</p> <p>(中略)</p> <p>フローティング操作ボタンはすべての画面で必要なわけではありません。フローティング操作ボタンはアプリ内のメインの操作に相当します。<br />フローティング操作ボタンは、1画面に1つだけ配置することをおすすめします。これは、その存在を目立たせるためであり、最もよく使う操作のみを表すものにする必要があります。</p> <p class="photo-caption"><a href="https://www.gstatic.com/material/spec/jp/components.pdf">マテリアル デザインのガイドライン(日本語版):コンポーネント(62ページ)</a>,<a href="https://material.io/guidelines/components/buttons-floating-action-button.html#buttons-floating-action-button-floating-action-button">Buttons: Floating Action Button - Components</a></p> </blockquote> <p> </p> <p>画面構成の切り替え(ナビゲーション)がアプリのメインの機能でないなら、利用するのはおかしい、ということです。</p> <p> </p> <p>そもそもナビゲーションなら大多数のアプリで使っている下部ナビゲーション(もちろんマテリアルデザインにも用意されている)を使えばいいはずで、なぜフローティング操作ボタンを使うことになったのか理解できません。</p> <p><a class="http-image" href="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B3321sZLoP_HZjN1eld5MjRXb2s/components_bottomnavigation_usage1.png" target="_blank"><img class="http-image" src="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B3321sZLoP_HZjN1eld5MjRXb2s/components_bottomnavigation_usage1.png" alt="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0B3321sZLoP_HZjN1eld5MjRXb2s/components_bottomnavigation_usage1.png" /></a></p> <p class="photo-caption"><a href="https://material.io/guidelines/components/bottom-navigation.html#">Bottom navigation - Components - Material design guidelines</a></p> <p> </p> <h5>フローティング操作ボタンサブメニューの扱い</h5> <p>さらに、ボタンをタップすると横にメニューが伸びるという挙動ですが、この使い方も間違っています。</p> <blockquote> <p>フローティング操作ボタンを押した時に、<strong>関連する操作メニュー</strong>がボタンの<strong>上部</strong>に表示されるようにすることができます。</p> <p>(中略)</p> <p>ファイル形式を追加するタイプのアプリの場合、フローティング操作ボタンがタップされた後に関連する操作メニューに変化させることができます。表示される操作メニューがボタンと関係ない場合、その操作メニューはオーバーフローメニューとして配置する必要があります。</p> <p class="photo-caption"><a href="https://www.gstatic.com/material/spec/jp/components.pdf">マテリアル デザインのガイドライン(日本語版):コンポーネント(71ページ)</a>,<a href="https://material.io/guidelines/components/buttons-floating-action-button.html#buttons-floating-action-button-transitions">Buttons: Floating Action Button - Components - Material design guidelines</a></p> </blockquote> <p> </p> <p>つまり、その操作に関係したサブメニュー(メール新規作成ボタンであれば誰に送るか、ブクマ追加ボタンであれば直接入力かクリップボードURLを追加か、とかですかね)を出すものだということです。</p> <p>ちなみにガイドをみても横に表示する例はありませんでした。</p> <p> </p> <h5>いつのまにか「設定」に化ける2つ目のフローティングボタン </h5> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305180918p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305180918.png" alt="f:id:uxlayman:20170305180918p:plain" /></p> <p>さて、もう一度上記画像を見てみましょう。上下2つのボタンで、上のボタンを押したとあるのに下のボタンも変わっています。これはキャプチャミスではありません。上のボタンを押すと、下のボタンがくるっと回って設定ボタンになるのです。</p> <p>もちろんガイドにはないですが、そもそもこれはどういう意味なのでしょうか。このUIだと、ボタンを押すまで設定がどこにあるかわかりません。そして、わからなかった設定がどうしてナビゲーションをするタイミングで突然あらわれるのでしょうか?全くわかりません。</p> <p> </p> <p>なお、設定についてはナビゲーションドロワーに押し込むことが「パターン」という資料では推奨されています。ツールバーのオーバーフローメニューに押し込んだり、設定がかなり重要なアプリなのであれば、ツールバーに直接歯車アイコンを表示したり、フローティング操作ボタンに設定ボタンを表示したりというのはアリかもしれません。</p> <p>はてブアプリがそうであるとは思いませんし、いずれにせよよくわからないタイミングですり替わるボタンなんてのは論外です。</p> <blockquote> <p>設定とサポートは、スクロールするリストの最下部に、リストの他のコンテンツと並べて配置します。これには、どのようなアプリを提供するかに応じて、「ヘルプ」、「フィードバック」、「ヘルプとフィードバック」のいずれかを使用します。</p> <p><a class="http-image" href="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0Bzhp5Z4wHba3cUg5ak9acFFjUFU/patterns_navdrawer_settings1.png" target="_blank"><img class="http-image" src="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0Bzhp5Z4wHba3cUg5ak9acFFjUFU/patterns_navdrawer_settings1.png" alt="https://storage.googleapis.com/material-design/publish/material_v_10/assets/0Bzhp5Z4wHba3cUg5ak9acFFjUFU/patterns_navdrawer_settings1.png" /></a></p> <p class="photo-caption"><a href="https://www.gstatic.com/material/spec/jp/patterns.pdf">マテリアル デザインのガイドライン(日本語版):パターン(86ページ)</a>,<a href="https://material.io/guidelines/patterns/navigation-drawer.html#navigation-drawer-content">Navigation drawer - Patterns - Material design guidelines</a></p> </blockquote> <p> </p> <h5>その他フローティング操作ボタン関連の扱い・あるいはアイコン全般</h5> <p>フローティング操作ボタンは原則アイコンしか表示できないので、当然ユーザーにわかりやすいアイコンを選ぶ必要があります。または、ガイドにもあったように、そのアプリと聞いて誰もが思い浮かべる操作を配置する、というのが大原則です。</p> <p>ここで、はてブアプリのフローティング操作ボタンアイコンとその意味をみてみましょう。</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305164643p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305164643.png" alt="f:id:uxlayman:20170305164643p:plain" /></p> <p>どうですか。わかりますか。特にひどいのはやはりメイン3画面構成を表すアイコンなのではないでしょうか。どうして方位磁針(?)がメインのエントリー一覧なのでしょうか。Wi-Fiみたいなアイコンがなぜフィードなのでしょうか(せめてRSSアイコンに。それ以前の問題としてフィードが何を表してるかユーザーにわかるのでしょうか)。人を表す画面がマイページなのはまだわからなくもないですが、でも「My」などにしてほしいです。また、フィードの中にはお気に入りユーザー(他人)のブクマも入ってるから人のアイコンから「自分だけを示す」と連想するのは難しいように思います。</p> <p>本来ナビゲーションが置かれないようなところに、なにを表すのかわかりにくいアイコンが配置されることでさらにわかりづらくなっているのが現状でしょう。</p> <p>普通の下部ナビにしておけばラベルとアイコン両方表示できてすくなくとも迷わないのに、という思いも強いです。</p> <p> </p> <p>他のツールバーアイコンも</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305183422p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305183422.png" alt="f:id:uxlayman:20170305183422p:plain" /></p> <p>どうなんでしょうかこれ。そりゃ、言われればわかりますけれども。マイホットエントリーのようにアイコンもわからなければ機能そのものもわからないものもあります。あと、方位磁針=メイン画面という決め事だったはずなのに、画面によっては同じアイコンで意味が変わってしまうのも罪深いです。</p> <p> </p> <h4>ナビゲーションの構成がおかしい</h4> <p>そもそもにしてナビゲーションの構成もおかしいです。もし、フローティング操作ボタンが本来あるべき下部ナビゲーションに置き換わったとしても、下部ナビゲーション、ナビゲーションドロワー、タブ、という3種類の切り替え階層が存在することになります。</p> <p>それに加えて、各画面ごとにツールバーの横のスペースに2つ3つのボタンが配置されて全画面のマテリアルがせりあがる画面がいくつもあります。</p> <p>ナビゲーションドロワーはネストが可能なので、原則的にはこのナビゲーションだけですべてまかなえるはずです。現にGmailなどはこれで実現できてますし、多くのGoogle謹製アプリもナビゲーションドロワーだけで主要機能を実現できています。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305192119p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305192119.png" alt="f:id:uxlayman:20170305192119p:plain" /></p> <p class="photo-caption">gmail iOSアプリのメイン画面と、ナビゲーションドロワー</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170305192140p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170305/20170305192140.png" alt="f:id:uxlayman:20170305192140p:plain" /></p> <p class="photo-caption">Google Map iOSアプリのメイン画面と、ナビゲーションドロワー</p> <p> </p> <p>はてぶアプリはそこまで大規模な機能を持つアプリなのでしょうか。</p> <p>直接マテリアルデザインと関係がないので言及していませんが、タイトルと中身をみても何が表現されているかわからない画面や、他に似た画面があってなにが違うのかよくわからない画面がたくさんあります。</p> <p>ナビゲーションの構成がまともでないのはデザイン以前の問題で、ぶっちゃけていえばまともにディレクションできていないのだと思います。特にみんなが文句言わないのは、超超メイン動線(ホッテントリを見る、URLスキームで飛んできた時にブックマークコメントを残す)以外は使われていないからではないかと。</p> <p> </p> <h3>おわりに</h3> <p>UIをみて、なにができそうか把握するまでの認知ロジックは個人による違いがかなり大きいです。</p> <p>AppleがiPhoneとともにリリースしたヒューマンインターフェイスガイドライン(<a href="https://developer.apple.com/jp/documentation/UserExperience/Conceptual/MobileHIG/BasicsPart/BasicsPart.html">iOSヒューマンインターフェイスガイドライン: UI設計の基本事項</a>)はかなり良い出来ではあったけれども、統一的な表現を使いましょうという範囲に止まっていて、結局スクリーンの中に映っている世界はどんなもので、どうしてそれがタッチで動作できるのか、という世界観までは踏み込めていなかったように思います<a href="#f-b85e0833" name="fn-b85e0833" title="そして、その「統一的な表現」が開発ツールと密に連携しているため、新しい概念や複雑なアプリへの対応が遅れがち">*2</a></p> <p>マテリアルデザインの革新的なところはその世界を「マテリアルの重なり」という概念で物理的法則が効く世界として再定義したことにあると思います。さらっと言ったけれど、未来にさまざまな変更があったとしても整合性を保てる世界を作ることはとても大変なことで、並々ならぬ努力が必要であったことは容易に想像できます。それに加えて、皆が間違いを犯さないようにかなりの量の例示を含む膨大なガイドラインを公開していることは素晴らしいと思います。</p> <p> </p> <p>それにもかかわらず、はてなブックマークアプリはこういう「悪い見本」を作り上げてみなが必死に作り上げてきた努力を簡単に踏みにじってしまっています。今後、はてぶアプリを見た別のアプリ開発者がガイドなんて見ずにはてブを真似る、なんてことが起こるかもしれません。</p> <p>日本最大のブックマークサービスの公式アプリがこのレベルにあることをとても残念に思います。</p><div class="footnote"> <p class="footnote"><a href="#fn-9c1f427a" name="f-9c1f427a" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">ググったらフラットデザインと関係あるか、という話題が結構ありましたが、あるといえばありますね。マテリアル自体は常に1pxで、盛り上がったりへこんだりしません(フラット)。しかし、マテリアルは宙に浮いた状態で定義される(=高度を持つ)ので、影は存在します</span></p> <p class="footnote"><a href="#fn-b85e0833" name="f-b85e0833" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">そして、その「統一的な表現」が開発ツールと密に連携しているため、新しい概念や複雑なアプリへの対応が遅れがち</span></p> </div> uxlayman はてなブログのコメント承認制が許されるのは小学生までだよねーキャハハ hatenablog://entry/10328749687216962315 2017-02-15T21:12:35+09:00 2022-02-28T21:13:52+09:00 つい1日くらい前からブログのコメントを承認制にしたので思うことを書きます。 わたしがブログをやる大きな動機として、主張に対して世の中の意見、反応を広く募りたいというのがありまして。そんなわけでコメント欄は匿名可かつ管理者承認不要、つまり誰でもかけて書いたらすぐ反映されるモードで運用してきました。 過去に大炎上してコメントが何百件もついてコメント欄で争いが起きる事態wでもそのままだったのですが、でもよくよく考えるとコメント欄って自分の運営ポリシーとあんまあってないなあと思い始めまして、それについて書きます。 なお、コメントに対する基本ポリシーは以下の感じで。 コメントで知りたいのはご意見なんです… <p><img class="hatena-fotolife" title="f:id:uxlayman:20170215210635p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170215/20170215210635.png" alt="f:id:uxlayman:20170215210635p:plain" /></p> <p>つい1日くらい前からブログのコメントを承認制にしたので思うことを書きます。</p> <p> </p> <p>わたしがブログをやる大きな動機として、主張に対して世の中の意見、反応を広く募りたいというのがありまして。そんなわけでコメント欄は匿名可かつ管理者承認不要、つまり誰でもかけて書いたらすぐ反映されるモードで運用してきました。 </p> <p>過去に大炎上してコメントが何百件もついてコメント欄で争いが起きる事態wでもそのままだったのですが、でもよくよく考えるとコメント欄って自分の運営ポリシーとあんまあってないなあと思い始めまして、それについて書きます。</p> <p>なお、コメントに対する基本ポリシーは以下の感じで。</p> <p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">コメントで知りたいのはご意見なんですかってことと、考えの相違点がどこなんですかってことだけなんだな。<br>それがわかれば終わりというか、そういう考えなんだ自分とは違うけど面白いな。お互い違うことがわかってよかったですねと。</p>&mdash; りんご4個分 (@uxlayman) <a href="https://twitter.com/uxlayman/status/831491097457152000?ref_src=twsrc%5Etfw">2017年2月14日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p> </p> <h5>特に返答することがない</h5> <p>だいたいこれなんですけどね。とても有意義で、意図がよくわかって、記事とともにみんなの目に触れるべきご意見だ、本当にありがとうございますとは思うけど、それ故にこちらから特に返答することがない、という。</p> <p>いいね!だけつけたい感じのやつ。</p> <p> </p> <h5>終わらない/始まらない</h5> <p>基本ポリシーに書いたように、「つまりなんなの?」「どこが相違点なの?」がわかればわたしとしては終わりなんですが、書いてる方はもちろん一家言あって書きこんでるわけなんで、終わってからが長いのです。</p> <p>それからまあ、なにを主張してるのかわからないとか、記事と関係なさすぎて困るとかで、はじまらないパターンもあります。</p> <p>そのあたりのやりとりに興味がなくて飽きちゃうんですよね。</p> <p> </p> <h5>熱量が違う</h5> <p>わたしは賛否はともかくだいたい記事の中で話を完結できるように書いてるつもりなので、コメントに書く内容も本文に書いてある内容をかいつまんで繰り返す、となりがちで。それでも納得いただけないなら本文の書き方が悪かったのかなー、と思うくらいで。</p> <p>「議論したい」「意見を認めさせてやる」的なコメントと熱量が釣り合わないのです。</p> <p> </p> <h5>せまい</h5> <p>単純にせまいですよね、はてなブログのコメント記入欄。それにあそこに長文書くの嫌いなんですよね。長く書いてもみにくいし。かといって説明しきるには足りないし。そもそも長文なら新規記事書けばいいわけだし。</p> <p>それとなにげにあそこの欄、はてな記法が有効になっちゃうんですよ。2回改行入れないと大きく改行されないとか。めんどくさいよねえ。</p> <p> </p> <p> </p> <p>承認制にした結果ですけど、とりあえずすこぶる快調です。「通りすがり」みたいな名前で延々と粘着し続けるマン(何回通りすがるんだよw)とかは完全ブロックできますし。</p> <p>でもそもそもコメント欄自体いらないかなあとも思いはじめてます。ブコメもツイッターもあるし。長い反論あるんならブログでも増田でも書いた方がお互い幸せなんじゃないかなあと。でもよくある揉め事みたいにブログ記事合戦みたくなるのもどうかと思いますがw</p> <p> </p> <h4>他の人々</h4> <p>読者登録してるブログをざっとみてみたら</p> <p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">5 承認制<br>13 制限なし<br>3 コメント欄なし<br><br>読者ブログ新しい順にみてみたらこんなんだった。ノーガードがおおいや</p>&mdash; りんご4個分 (@uxlayman) <a href="https://twitter.com/uxlayman/status/831504547029741569?ref_src=twsrc%5Etfw">2017年2月14日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p>こんなんでした。あんまりジャンルによる傾向の違いは見られなかったですね。好き好きというか。</p> <p> </p> <p>とても印象的だったのが、一部で炎上ブロガーとして称されてるチルドさん。</p> <p><iframe class="embed-card embed-webcard" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" title="散るろぐ" src="//hatenablog-parts.com/embed?url=http%3A%2F%2Fcild.hatenablog.com" frameborder="0" scrolling="no"></iframe></p> <p>承認制だったんだけど、チルドさんほとんどコメントに返信してないの<a href="#f-6abac409" name="fn-6abac409" title="ほんとは&quot;一切&quot;って書きたかったけどしてるのもあったw">*1</a>。これはこれでいいよなあと。興味もないのに返信するから余計火に油をそそぐってのもあるだろうし。ご自由に書いてくださいませというのはポリシーとしていいかも。</p> <p> </p> <p>まあしばらくはスルーしたり★だけつけたりいろいろ試行錯誤するかもですが、書いていただいて感謝の気持ちは忘れていませんのであたたかく見守ってくださいませ。</p> <p> </p><div class="footnote"> <p class="footnote"><a href="#fn-6abac409" name="f-6abac409" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">ほんとは"一切"って書きたかったけどしてるのもあったw</span></p> </div> uxlayman SIerの下請け開発者ってレベル低すぎない? hatenablog://entry/10328749687215943774 2017-02-12T18:00:00+09:00 2022-02-28T21:13:54+09:00 ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造… <p>ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。</p> <p>自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。</p> <p><br/></p> <p>なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。</p> <p>対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態で、それを満たすそれぞれのモジュールを、必要であれば詳細化した上で実装して単体テストする、っていう。</p> <p><br/></p> <h4>自分の作ったものの仕様を説明できない</h4> <p>言ってみれば問題は全てはこれに尽きるのですが。</p> <p><br/></p> <p>自分の作ったもの、たとえばメソッドなりクラスなりなんなりを作ったとして、その仕様を説明できないという人がかなりいます。</p> <p>代わりに、延々と自分がコーディングした記述の説明をしてきます。</p> <p>どんなプログラムであれ、特定の入力状態においてなんらかの処理を実行させて出力状態を得る、という構造は変わらないはずです。それは純粋関数なら引数と戻り値だし、オブジェクトならメッセージとオブジェクト状態だし、WebURL呼び出しならURL+パラメータとHTML(テキスト)だし、といった具合に、ジャンルによって表現はかわりますがその本質は変わりません。</p> <p><br/></p> <p>こういう風な出力を得ることを目的としてプログラムを書きました、こういう条件で入力のパターンをテストして全部出力が想定通りであることを確認しました、だからこのプログラムは(ある範囲で)正しいです。</p> <p>これを説明するのが当たり前の基本だし、やるべき唯一のことであるのだけれども、そもそもプログラムが完成したのに「何をどうしてどうするプログラムなのか」が説明できないケースが多々あるのです。</p> <p>意味がわからないとおもったあなたは常識的であると思います。わたしも、それがわからなくてどうやってプログラムを書いてテストするのか、わけがわかりません。</p> <p><br/></p> <p>しかし、現実には以下のような会話が頻発します。</p> <blockquote><p>「この引数にマイナスの値を設定すると、NullPointerになりますね」</p> <p>「そうですね」</p> <p>「?そうですねってどういうこと?この動きは正しいの?」</p> <p>「XXライブラリがnullを返してくるからですね」</p> <p>「??XXライブラリが返したnullにアクセスしてるのはあなたが書いたコードですよね?どういうこと?このメソッドは負の値で呼ばない、というのが制約なの?」</p> <p>(なにを聞かれているのかわからないという顔)</p></blockquote> <p><br/></p> <p>これ「テスト終わった」後のモジュールの話ですよ?</p> <p>いったい何をテストしたんでしょうか。こんな話がしょっちゅうです。「そもそもこれは何をする関数なの?」とか「え?自分で書いたコードですよね?」とかそういうセリフを何度も言わなければなりません。</p> <p>どういうことなのでしょうか。</p> <p><br/></p> <h4>フレームワークやライブラリとの主従関係が逆転している</h4> <p>仕様がわからないものをどうやってテストするのか。強い味方はカバレッジ確認ツールです。</p> <p>彼らからするとテストとは、</p> <p>× プログラムが仕様/想定通りにうごいてることを確認する作業</p> <p>○ カバレッジが通るようにテストコードをこねくり回す作業</p> <p>であるようです。カバレッジが100%に近くなると、テストコードに結果的に「仕様らしきもの」が浮かび上がってくる、と。うん、逆ですしそれ漏れますよね。</p> <p>テスト終わりました!カバレッジ100%です、と言われて見てみたら、たしかにカバレッジは100%だけど返り値の確認を一切していないというコードを見た時が一番度肝を抜かれました。</p> <p><br/></p> <p>これに限らず、プログラミングとはものを作る作業じゃなくて、なにか巨大なすばらしいものの「設定」をする作業みたいに捉えてる人が多いようです。 "カバレッジツールというすごいもの"がエラーを出さない設定値を探る、とか"Railsというすごいなにか"に設定用のコードを書くとよきに計らって動いてくれる、とかとか。</p> <p>だからRailsやったことある=RailsのControllerを書いたことがある、であると信じて疑わない。もちろん、一からURL設計をしてください、といったことは全くできません。 それどころか、動かないのは自分の責任じゃないのに、といったことをいう人までいてびっくりです。</p> <p><br/></p> <h4>フレームワークやライブラリのやっていることを理解しない</h4> <p>そんなわけでフレームワークやらライブラリの名前は詳しいのに、本質的なことは全く理解してません。</p> <p>あるURLに任意の数のパラメータが来る、と聞いて、うわあFormオブジェクト(リクエストパラメータをオブジェクトにマップしてくれる便利な仕組み)が作れないどうしようどうしようなどと意味不明な混乱をした挙句、自分が考えつく全てのキーワードをプロパティとしてFormをつくる、などというバカみたいなコードを埋め込むことになるのです。(そしてもちろんそれ以外のパラメータも来る可能性があるので、そのFormは実用に耐えない)</p> <p><br/></p> <p>こういうひとたちは典型として「例外」を全く理解できません。なんのためにあるのかわからず、自分のコーディング作業を邪魔するもの程度の認識しかありません。</p> <pre class="code" data-lang="" data-unlink>try { ... }catch(Exception e) { return false; }</pre> <p>こういうコードを書いてせっかくのエラー情報を握りつぶしたりするのです。catch節を書いたのは静的解析ツールに怒られるからで、それがなかったら読み捨てるんでしょう。 それで、ずっと後になって「エラーが出たはずなのにどこにも記録されない」なんて事態が起こります。</p> <p>一応念のため言っておきますが、プロジェクトに例外は最上層で処理するというルールがある状態での話です。</p> <p><br/></p> <p>自分たちが役割や機能を意識したプログラムを書かないから、他人のプログラムが役割や機能を提供してるということが把握できないのでしょう。</p> <p>何百行もある謎のユーティリティが全部ライブラリ機能1行呼び出しで置き換わる、なんてこともありました<a href="#f-bd5ef1dd" name="fn-bd5ef1dd" title="jQueryオブジェクトの配下を条件付きで呼び出すユーティリティ。全部jQueryセレクタで表現できる範囲だった。そもそもDOMから目的のエレメントを探し出すがjQueryの主機能なのだから、こんなユーティリティを作ろうと考えること自体おかしい">*1</a></p> <p>結局、開発効率化のためのライブラリやフレームワークがあるにもかかわらず、なぜか無意味なコードが大量に生み出されたりするのですが、どうすれば良いのでしょうか。</p> <p><br/></p> <h4>FizzBuzzレベルのプログラムがかけない</h4> <p>こんなひと本当にいるんだなあと。正確に言うなら、一応動くけど何を書いてあるかさっぱりわからないコードを作り出す、なんですけどね。</p> <p><br/></p> <blockquote><p>文字列Aと文字列Bがあたえられた時、文字列Aが3文字以内なら文字列Bの先頭に付加し、プロパティXに設定する。</p></blockquote> <p>英語にすればそのままプログラムになりそうな要件ですが、これがifと3項演算子がぐちゃぐちゃに入り混じったコードになりました。本人曰く、普通に+で結合するとnullの時"null"って文字列になっちゃうからとかいう話を延々としてました。なにが難しいのか全く意味がわかりませんでしたが。</p> <p><br/></p> <p>それとか、これ。コードから先にみてください。</p> <pre class="code" data-lang="" data-unlink>String[] bigArray =.... for (int i = 0; i &lt; (int) ((bigArray.length + 99) /100); i++) { .... }</pre> <p>なんのコードかわかりますか?</p> <p>配列を100個ずつに分割するコードなんですよ。えええええ。なんだこれ。99っていったいどこから出てきた?しかもこのコード、コメントなしなんですよ?このコードがコメントなしで伝わるコードなわけないだろと。</p> <p>これは心の底から疑問なんですが、彼らは外部仕様書もないような謎モジュールの改修作業や保守作業とかを引き継いで、他人の意味不明なコードを読んでわけがわからなくて悩んで怒る、って経験、たくさんしてるんですよね。われわれなんかよりそういう経験豊富なんですよね?なのに自分のコードにはどうしてコメント書かないの?</p> <p>ちなみに、このコードは↓をコピペしろといって、なおしてもらいました。最初からこう書いて欲しいというか、これしか書きようないだろ・・・</p> <pre class="code" data-lang="" data-unlink>String[] bigArray =.... for (int i = 0; i &lt; bigArray.length; i+=100) { .... }</pre> <p>スパゲッティコードって、長い紆余曲折を経て作り出されるものだと思っていたのですが、頭がスパゲティな人がいきなりスバゲティを茹でることがあるんですねえ。</p> <p><br/></p> <h4>平気で嘘をつく</h4> <p>特に技術的な調査事項など。自分が調べた限りはわかりませんでした、と言えばいいものを「ライブラリの仕様上でできません」というような嘘をすぐつく。〇〇のライブラリなのにXXができないなんてありえないだろ、と思って調べると案の定できるとかね。</p> <p>その間「〇〇さんが調査した結果できないことが判明した」という情報に振り回されていろんな人の時間が浪費されるなんてことはしょっちゅう。</p> <p><br/></p> <p>実装完了しました、とか、テストカバレッジX%でした、みたいな試せばすぐわかるような嘘もすぐつく。</p> <p>特にテストについては本当によくごかます。よく、SIerのExcelスクリーンショットによるテストエビデンスの非効率さが槍玉に上がるが、それはあなたたちがいい加減なごまかしをしてきた歴史の結果じゃないの?と問い詰めたいところではある。</p> <p>というか、すぐ嘘をつくとか、もう開発者どうこうというより、人としてダメなんじゃないのか。</p> <p><br/></p> <h4>奇妙なプログラミングスタイルに固執する</h4> <p>たとえば、関数を書くとなると、なにをするにしても、</p> <pre class="code" data-lang="" data-unlink>int process() { String str; int i, j; ・・・ return 0; }</pre> <p>という書式で書きたがる。まるでそういう決まりがあるかのように。</p> <p>ここで、変数str、i、jは処理の最中にどんどん意味合いが変わる。intでは表現できない情報を返す必要がある場合は戻り値はStringになる。複数の情報を返す場合は、Stringの中にカンマ区切りで情報を記載すし、呼び出し側でカンマ分割して復元する、なんてことを平気でやる。構造体ってなんのためにあるか知ってますか。</p> <p><br/></p> <pre class="code" data-lang="" data-unlink>for (int i =0; i &lt; length; i++) { }</pre> <p>繰り返しもこう書かなくてはいけないという明確な意思があるようだ。</p> <p>ちなみに、iやjを用いると添え字の取違いが発生する可能性があるし、コード量可読性ともに悪化するので、each的機能がある言語はそれを使うよう明確にルール付けされている。もちろん読まないし恐らく意味がわかっていない。</p> <p><br/></p> <p>結局のところ、なんの合理性もないわけのわからないプログラミングスタイルによって可読性は悪化し、ますます保守性が下がることになる。いったい何がしたいのだろうか。</p> <p>ちなみに、急にモダンなスタイルのコードが出現した場合、それはどっかからのコピペである。コピペコードと自己コードのスタイルを合わせようという努力がなされることはない。</p> <p><br/></p> <h4>コメントがかけない・ネーミングセンスがない</h4> <p>仕様が説明できない人間がメソッドコメントをかけるかというそりゃ無理なんだけども、それにしたってあまりにもひどいネーミングをしすぎる。</p> <p><br/></p> <pre class="code" data-lang="" data-unlink>/** * 要素に対して加工処理を実行します * @param element 処理対象 * @return 処理結果(int) */ function elementProcess(elm) { }</pre> <p>こんなの、しょっちゅうある。なんにも伝える気がないだろと。加工処理って具体的には何をどう加工するんだ、処理結果ってどういう数字なんだ、加工数か成功失敗のビットかどっちやねん、とか、ともかく「お前以外絶対理解できないだろ」って内容の名前やコメントをつける。なんど指摘してもくりかえす。</p> <p>ちなみにメソッド名は動詞にするというコーディング規約があるが、それにも違反している。そんなもの一切見ないし、そもそも動詞とはなんなのかわかってないのではないか。</p> <p><br/></p> <pre class="code" data-lang="" data-unlink>List executeQuery(String sql, Object[] params, int limit10); void writeToFile(String filePath, String text,String encodingShiftJis);</pre> <p>それぞれ最大取得数を指定してSQLクエリを実行する、指定エンコードでテキストをファイル出力する、っていうありがちなメソッドだが、なぜかパラメータ名に10とかShiftJisとかの値が入ってる。この、パラメータ名とそこに入れる値が区別ついてないっていうパターンは驚くことにかなり頻発する。なんでそんなところを間違えるか理解不能だ。</p> <p>一番ファンキーなやつだと、メソッドの中でencodingShiftJis変数が"shiftJis"かどうか確認して、違ったらエラーにするとかいう実装もみたことがある。頭がおかしいんだろうな。</p> <p><br/></p> <pre class="code" data-lang="" data-unlink>Element searchElement(String name, boolean isEnabledFalse);</pre> <p>究極最終形はこうなる。DOMエレメントを探す関数で、有効状態のものだけを取得するようフィルタできるようだ。</p> <p>さて「有効状態のものだけを取得」したい場合、isEnabledFalseにはなにを指定すれば良いのだろうか。だれにもわからない。多分本人ですらわからないんじゃないか。繰り返して言うけど、頭がおかしいんだとおもいます。</p> <p><br/></p> <pre class="code" data-lang="" data-unlink>/** * データアクセッサを利用して、指定された条件でXXXテーブルを検索するSQLを組み立てた後 * 検索を実行し、取得レコードをステータスごとに分類してマップに格納します * * @param nameFilter 名前フィルタ * @param statuses 対象ステータス */ Map&lt;String, List&lt;Xxx&gt;&gt; searchXxx(String nameFilter, StatusFilter... statuses);</pre> <p>これは一応ギリギリ許せる範囲。コメントを見れば何をやればやってるかはわかるからね。でも、ここに書くべきは「結局呼び出し側が何を得られるか」なんだよ。自分のコーディング処理内容を書く奴が多すぎる。見た人はそれを逆算して自分で考えてねって。</p> <p>Javaでも.NETでもなんでもいいけどさ、中の処理の順番が事細かに書いてあって、結局なにが得られるかはそこから類推してください、なんてドキュメント見たことあるか?っていうね。</p> <p>最高に「デキる」人間でもこの程度なんです。そして皆がこれを真似てコピペする、と・・・</p> <p><br/></p> <p>コードのネーミングやコメントは保守において重要であるにもかかわらず、全くケアする意思がないのは驚きである。ネーミングやコメントはコードじゃないと思ってるのかな。</p> <p><br/></p> <h4>SQLしかできないマン</h4> <p>能力の全てをSQLを書くことだけに費やしていて、申し訳程度に各言語のコレクションフレームワークとか繰り返し構文とかを把握している、という人材が一定数いる。 これはどうなんだろ。業界の伝統なのかな?とはいえ、そんなニッチな能力でアプリケーション開発者とか言われても困る。</p> <p>SQLに詳しいと言っても実行計画を見て効率化するといったことはしないし、DBアクセス層の設計を依頼してもまともにつくることはできない。単に複雑な処理を巨大な1SQLで書くことに喜びを見出しているだけ。</p> <p>このタイプはかなり自己評価が高い場合が多いけど、プログラミングスキルとしてはFizzBuzzレベルのことも多く、だれにも読めないSQLを(これまたコメントなしで)作ってそのままいなくなったりするので禍根を残すようなこともあってぶっちゃけていえば使えない。</p> <p><br/></p> <h3>まとめ</h3> <p>どうでしたでしょうか。断っておくけれども、これ、最底辺の人間を面白おかしく紹介してるわけじゃなくて、極々平均的な「SIerの下請け」のレベルだから(最底辺レベルはマジで度肝を抜かれる)。何個かの案件で何社かと関わったが、どれもこんな感じ。</p> <p>興味深いのは同じ会社に頼んでも内製ソフトウェアの業務委託ですって場合と、SIer案件ですって場合とでは、派遣される技術者のレベルに何段も差があること(後者の方が圧倒的に低い)</p> <p>それはそれとして、個人的には上にあげたようなこと、一個でも引っかかるようなやつは一発でクビにしてよいと思っているが、そんなことしてたらうちからはもう紹介できる人がいませんとか言われるくらいこういうのが「普通」なのです。</p> <p><br/></p> <h4>結論</h4> <p>総じて言えば、ただコードを書いて動かすのが楽しいという学生みたいなレベルで、仕事として金をもらう状態にないと思う。</p> <p>しかも30代とか40代とか何10年もキャリアがあるような人でこれ。むしろ若手の方がまだまとも。ずっとコード書く仕事ばかりしてたんですよね?今まで何してたんですか?と問いただしたい。</p> <p>雇った側としてはどうしてこんな奴らに金を払ってゴミみたいなコードを書いてもらわなければならないのかという気持ちがつよい。</p> <p><br/></p> <p>そもそも、こちらとしては難しいことを言っているつもりが全くない。バグをゼロにしろとか、伝えてもいない仕様を実装しろとか、エスパーのように要件を把握して実装に適用させろとか言ってるわけではない。普通にプログラミングして、その妥当性を説明し、重要な情報を未来の他人にわかる状態で記録に残せと言っているだけだ。おかしいですか?</p> <p><br/></p> <p>英語の文章書いて欲しいと依頼したら、単語は正しいけど文章として成り立っていない原稿が完成してるようなものだと思ってる。スペルチェッカーはオールクリアだけど、文の意味も分からなければ何を伝えたかったかも説明できませんって。</p> <p>文章として成り立ってるけどそれは欲しい種類の原稿と違う、ってんなら書き手に第一義的責任はなくて、それをちゃんと伝えなかった要求主の問題だ。何10ページのもの文書を書くのに雀の涙ほどの金額しかもらえないのであれば、それは雇用条件の問題で、ひいては業界の問題なのかもしれない。</p> <p>でも、文章を書く仕事で意味の通る文章が書けないのは明らかに書き手の問題だ。要求ガーとか業界ガーとか以前の問題だ。</p> <p><br/></p> <p>もちろんこんな人たちは開発者とは呼べないし、IT土方とすら呼べないのではないだろうか。だって自分の仕事の内容を自分で説明できないんだよ?そんな仕事人いる?!</p> <p><br/></p> <div class="footnote"> <p class="footnote"><a href="#fn-bd5ef1dd" name="f-bd5ef1dd" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">jQueryオブジェクトの配下を条件付きで呼び出すユーティリティ。全部jQueryセレクタで表現できる範囲だった。そもそもDOMから目的のエレメントを探し出すがjQueryの主機能なのだから、こんなユーティリティを作ろうと考えること自体おかしい</span></p> </div> uxlayman 俺が欲しい細身でホリゾンタルでロゴが少なめの自転車2017 hatenablog://entry/10328749687198242748 2017-02-02T21:00:00+09:00 2022-02-28T21:13:54+09:00 ゆえあって定例化することにしました。2017モデルを中心に紹介していきます。 第1回は以下より。 FUJI BALLAD Ω BALLAD Ω|FUJI BIKE ¥105000 クロモリ 9.8kg FUJIの"こういう系"は前回紹介したBALLAD Rというラインが以前からあったのですが、シフト操作が若干大変なダブルレバーで、ギア数8段しかないCRARISというコンポーネントという点が若干難点でした。 2017モデルから追加されたこのBALLAD Ωは、なんと手元でシフトできるSTIにランクアップされ、ギア数も9段のSORAとなり、難点が一気に解消されました。 それよりなにより、どうですか… <p>ゆえあって定例化することにしました。2017モデルを中心に紹介していきます。</p> <p>第1回は以下より。</p> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="俺が欲しい細身でホリゾンタルでロゴが少なめの自転車 - UXエンジニアになりたい人のブログ" src="http://uxlayman.hatenablog.com/embed/2016/06/05/horizontal" frameborder="0" scrolling="no"></iframe></p> <p> </p> <p> </p> <h4>FUJI  BALLAD Ω</h4> <p><a class="http-image" href="http://www.fujibikes.jp/2017/products/ballad_omega/img/item/1.jpg" target="_blank" rel="noopener noreferrer"><img class="http-image" src="http://www.fujibikes.jp/2017/products/ballad_omega/img/item/1.jpg" alt="http://www.fujibikes.jp/2017/products/ballad_omega/img/item/1.jpg" /></a></p> <p class="photo−caption"><a href="http://www.fujibikes.jp/2017/products/ballad_omega/">BALLAD Ω|FUJI BIKE</a> ¥105000 クロモリ 9.8kg</p> <p>FUJIの"こういう系"は前回紹介したBALLAD Rというラインが以前からあったのですが、シフト操作が若干大変なダブルレバーで、ギア数8段しかないCRARISというコンポーネントという点が若干難点でした。</p> <p>2017モデルから追加されたこのBALLAD Ωは、なんと手元でシフトできるSTIにランクアップされ、ギア数も9段のSORAとなり、難点が一気に解消されました。</p> <p>それよりなにより、どうですかこのデザイン。全てのパーツ(スポークも!)がブラックで統一されたことにより、クラシカルになりすぎておらず、まさに黒い鉄の構成物という感じ。かっこいい!</p> <p>お値段も手が届きやすく、軽さもそれなりで、非の打ち所がありません。ライトやサイコンなども黒で揃えてオールブラックでいくもよし、カラーパーツやアイテムを挿し色につかうもよし、カスタマイズの幅も広がります!</p> <p> </p> <h4>NEOCOT</h4> <h5>Chrome Plated Editon</h5> <p><a class="http-image" href="http://ratio-c.jp/wp-content/uploads/2016/12/Chrome-Plated-N7-roadstyle.jpg" target="_blank" rel="noopener noreferrer"><img class="http-image" src="http://ratio-c.jp/wp-content/uploads/2016/12/Chrome-Plated-N7-roadstyle.jpg" alt="http://ratio-c.jp/wp-content/uploads/2016/12/Chrome-Plated-N7-roadstyle.jpg" /></a></p> <p class="photo−caption"><a href="http://www.bscycle.co.jp/news/release/2016/3691">Chrome Plated edition(メッキエディション)を追加発売</a> ¥355000− クロモリ</p> <p>ブリジストンの往年の名フレームをカスタムオーダーで注文できるNEOCOTという自転車があるのですが、それのメッキエディションが出たようです。上の写真はそこまでメッキ感ありませんが、<a href="http://ratio-c.jp/article/201612015975">こちらのサイトの写真</a>をみるとかなりピカピカでかっこいいです。</p> <p>NEOCOTはこのメッキエディションのみならず、<a href="http://ratio-c.jp/neocot">ハンドル形状や2トーンカラーなど、さまざまなカスタム</a>が可能で、148000からオーダーできるようなので見てみると良いではないでしょうか。2トーンにするとぐっとオシャレ感が増します。</p> <p> </p> <h5>CHARI&amp;COコラボモデル</h5> <p><a class="http-image" href="http://www.bscycle.co.jp/news-cms/wp-content/uploads/2016/04/6.jpg" target="_blank" rel="noopener noreferrer"><img class="http-image" src="http://www.bscycle.co.jp/news-cms/wp-content/uploads/2016/04/6.jpg" alt="http://www.bscycle.co.jp/news-cms/wp-content/uploads/2016/04/6.jpg" /></a></p> <p class="photo−caption"><a href="http://www.bscycle.co.jp/news/release/2016/2822">BRIDGESTONE NEOCOT CHARI&amp;COコラボモデル</a> ¥260000</p> <p>同じNEOCOTで、「マジョーラマゼラン」のカラーのCHARI&amp;COのコラボモデル。こっちはこっちで唯一無二の塗装で、とても興味をそそられます。</p> <p> </p> <h4>ROCKBIKES</h4> <h5>FORTUNE</h5> <p> </p> <p><a class="http-image" href="http://rockbikes.jp/upload/save_image/0723125628_5792eaec44094.jpg" target="_blank" rel="noopener noreferrer"><img class="http-image" src="http://rockbikes.jp/upload/save_image/0723125628_5792eaec44094.jpg" alt="http://rockbikes.jp/upload/save_image/0723125628_5792eaec44094.jpg" /></a></p> <p>細身でホリゾンタルというと、クラシックよりになりがちなのですが、かなりストリートテイストが強く出てて良いですね。こういう感じで、ルックスはピスト風で、でもスペックはロード的なのがもっと出てきて欲しいところです。</p> <p>ROCKBIKESはかなり個性的なモデルが多く、気にはなっているのですがロゴが少なめという条件を満たすものが少ないところだけが残念(このモデルもバッチリロゴは書いてあるけど、色の都合で目立ちにくくなってる)</p> <p>ロゴが目立ためというと、以下の2モデルあたりもかなり捨て難い。MASIとかを超えて「これ系」の2番手に踊り出た感がありますな。</p> <p><a href="http://rockbikes.jp/products/detail/2343">Rockbikes / PRIDE phase3 / Nato Green</a></p> <p><a href="http://rockbikes.jp/products/detail/1541">Rockbikes / GREED phase2 / Black'N'Blue</a></p> <p> </p> <h4>Bianchi</h4> <h5>LUPO</h5> <p><a class="http-image" href="http://www.japan.bianchi.com/images/bike_list/17-LUPO-GREY.jpg" target="_blank" rel="noopener noreferrer"><img class="http-image" src="http://www.japan.bianchi.com/images/bike_list/17-LUPO-GREY.jpg" alt="http://www.japan.bianchi.com/images/bike_list/17-LUPO-GREY.jpg" /></a></p> <p class="photo−caption"><a href="http://www.japan.bianchi.com/category.cgi?mode=category_detail&amp;bik_Code_prm=17-LUPO">Bianchi | ROAD | LUPO</a> ¥143000 クロモリ 11.73kg</p> <p>全然ホリゾンタルじゃないけどw</p> <p>LUPOって前からあったモデルだと思うんですが、2017でジャンルが変わったような。前はガチクラシカルでしたが、カラーパーツとかディスクブレーキとかになってでも革サドルで、不思議な雰囲気になりました。ちょっと気になる。 </p> <p> </p> <h4>RITEWAY</h4> <h5>SHEPHERD IRON F</h5> <p><img class="http-image" src="https://www.riteway-jp.com/bicycle/newriteway/wp-content/uploads/2016/06/ironf_color1.png" alt="https://www.riteway-jp.com/bicycle/newriteway/wp-content/uploads/2016/06/ironf_color1.png" /></p> <p class="photo−caption"><a href="https://www.riteway-jp.com/bicycle/riteway/lineup-2017/shepherd-iron-f">SHEPHERD IRON F</a>  61,800 12.1kg 軽量スチール</p> <p>このライトウェイってブランド、どうなんですかね。かなり魅力的なラインナップを提供してるし、リーズナブルなので前から気になっているのですが、あまりこれに言及している話もすくなく。</p> <p>結構良いと思うんですけどねえ。</p> <p>  </p> <h4>SCHWINN</h4> <h5>SLICKER</h5> <p><img class="http-image" src="http://www.schwinn-jpn.com/images/2017/bike/lbike_slicker_wh.jpg" alt="" /></p> <p class="photo−caption"><a href="http://www.schwinn-jpn.com/17bikes/slicker.html">SCHWINN シュウィン [SLICKER™] スリッカー™</a> ¥58000 アルミ 11.9kg</p> <p>これもきいたことないブランドですがロゴの表示の仕方が結構好き。</p> <p> </p> <p> </p> <p>ちょっと少なめですがいかがでしたでしょうか。クラシカルに寄りすぎないアーバン系が増えてきたイメージがあります。ROCKBIKESは要注目ですね。</p> <p>ただ、個人的にはBALLAD Ωのかっこよさにかなりやられています。ぶっちゃけクロモリバイクは持ってるのですが、買い換えようかとも思ってる所存。</p> <p>なにかの参考になれば! </p> uxlayman 【本当にコピペ一発!】はてなブログで「文中にアドセンス広告を入れる」を自動化する方法 hatenablog://entry/10328749687209962471 2017-01-26T21:30:00+09:00 2022-02-28T21:13:57+09:00 はてなブログで広告の本文中への自動挿入を実現できるこの記事、いろんな方に言及していただいて、コメント等をいただいて応用例を随時増やしてたりしております。 でもですね、ずっと心配してたんですよ。みなさま、実はこんなことを思ってるんじゃないのかなって。 コピペで簡単って!全然コピペで簡単じゃねえよ!scriptをscripにするというわけわからん手順はあるし、なかなかうまく動かねえし! 応用例追加するのはいいんだけど、どの部分がどこのコードに対応してるのかよくわかんねえからカスタマイズできねんだよ。だれもがプログラマだと思ってんじゃねえ ってね。いや、みんなくちには出さないけどそう思ってるはずだ、… <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="【改良版】コピペで簡単!はてなブログで「文中にアドセンス広告を入れる」を自動化する方法 - UXエンジニアになりたい人のブログ" src="http://uxlayman.hatenablog.com/embed/2016/07/28/insentense" frameborder="0" scrolling="no"></iframe></p> <p>はてなブログで広告の本文中への自動挿入を実現できるこの記事、いろんな方に言及していただいて、コメント等をいただいて応用例を随時増やしてたりしております。</p> <p>でもですね、ずっと心配してたんですよ。みなさま、実はこんなことを思ってるんじゃないのかなって。</p> <ul> <li>コピペで簡単って!全然コピペで簡単じゃねえよ!scriptをscripにするというわけわからん手順はあるし、なかなかうまく動かねえし!</li> <li>応用例追加するのはいいんだけど、どの部分がどこのコードに対応してるのかよくわかんねえからカスタマイズできねんだよ。だれもがプログラマだと思ってんじゃねえ</li> </ul> <p>ってね。いや、みんなくちには出さないけどそう思ってるはずだ、と。そんな被害妄想で夜も眠れない日々を過ごしていたわけです。</p> <p> </p> <p>そんなわけで!</p> <p>つくりましたよ!</p> <p>マジでコピペで簡単なやつを!</p> <p>あなたがやるのは、アドセンスのコードをはっつけて、作成!ボタンを押すだけです。ほんとにほんとに!</p> <p>上1/3の箇所と上2/3の箇所に2カ所挿入するとか、見出しが見つからなかったらともかく真ん中に入れるとか、特定のカテゴリーの記事には挿入しないとか、そういうありがちなやつもUI操作だけで実現できるようにしました!</p> <p>どうぞおためしあれ!なお、 当ブログの文中挿入広告コードも、このフォームで生成(真ん中挿入)しなおしましたので、内容等確認いただければ幸いです。</p> <p> </p> <h3>【重要】ご注意</h3> <p>大事なことですが、本スクリプトは自己責任でご利用ください。</p> <p>スクリプトが突然動作しなくなったり、またポリシー違反状態になった場合等も、当ブログならびにブログ主は責任を負いません。 一応、ポリシーに違反したという話は聞きませんし、Adsenseコードをほとんどそのまま利用(ただscriptをscripに変換してるので、厳密にいえば改変は改変なのですが…)しているので、あまり問題にはならないかと思います。</p> <p>なお、お応えできかねる場合もありますが、機能追加依頼や正常動作しない場合の相談も受け付けておりますので、ブログコメントやメール等でお問い合わせくださいませ。その際、コピペコードの一番上に出力される</p> <blockquote> <p>START v1.0 params=[insentense-adsense,1,2,before,p,1,2,true,広告禁止] </p> </blockquote> <p>こういうやつを現象発生中のブログURLとあわせて提示いただけると、とても助かります。</p> <p> </p> <p> </p> <h3>手順とフォーム</h3> <p><span style="color: #ff0000;">2017/1/29追記 手順がわからないとのコメントがありましたので追記します。</span></p> <ol> <li>アドセンスの管理画面で、出力したいアドセンス広告ユニットの「コードを表示」してコードを取得します<img class="hatena-fotolife" title="f:id:uxlayman:20170129123343p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170129/20170129123343.png" alt="f:id:uxlayman:20170129123343p:plain" /></li> <li>取得したコードを、以下のフォームの「自動配置用広告コード」に貼りつけます。広告の周りに「広告」という文字や、上下スペースを入れたい場合は、それも一緒に「自動配置用広告コード」内に記載します。</li> <li> <p>挿入場所(真ん中の大見出しの後、とか)やアドセスンスコードが何個目か(文中に複数広告を別の位置に挿入したい場合)や、広告禁止カテゴリなどの設定をUIで選びます。</p> </li> <li> <p>「作成!」ボタンを押します</p> </li> <li> <p>「コピペ用完成コード」に出力されたコードを、記事上または記事下(はてなブログ管理ツール→記事→記事上下の記事上下のカスタマイズの「記事上」か「記事下」)にコピペします。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20170129124534p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20170129/20170129124534.png" alt="f:id:uxlayman:20170129124534p:plain" /></p> </li> <li>「記事ページをプレビュー」ボタンが押されていれば、その場で文中自動配置が反応してるはずですので、出来栄えを確認してください。</li> </ol> <h4>フォーム</h4> <div>自動配置用広告コード:</div> <div style="font-size: x-small; color: #707070;">アドセンスのコードと、「広告」という文字や上下のスペースなどを含む自動配置するHTMLを指定します</div> <div><textarea id="adsSrc" style="width: 90%; font-size: xx-small;" rows="14">&lt;p&gt;広告&lt;/p&gt; &lt;script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"&gt;&lt;/script&gt; &lt;!-- theTest --&gt; &lt;ins class="adsbygoogle" style="display:inline-block;width:300px;height:250px" data-ad-client="ca-pub-xxxxxxxxxxxxxxxx" data-ad-slot="xxxxxxxxxx"&gt;&lt;/ins&gt; &lt;script&gt; (adsbygoogle = window.adsbygoogle || []).push({}); &lt;/script&gt; &lt;p&gt; &lt;/p&gt; </textarea></div> <p> </p> <div>挿入箇所:</div> <div style="font-size: x-small; color: #707070;">自動挿入する場所を指定します</div> <div style="padding-left: 12px;"> <div><input id="adsBaseMC" checked="checked" name="adsBase" type="radio" value="MC" />全体の <input id="adsHCountMother" size="5" type="text" value="2" />分の <input id="adsHCountChild" size="5" type="text" value="1" />の箇所(真ん中なら2分の1)にある</div> <div><input id="adsBaseU" name="adsBase" type="radio" value="U" />上から <input id="adsUCount" size="5" type="text" value="1" />個目の</div> <div><input id="adsBaseD" name="adsBase" type="radio" value="D" />下から <input id="adsDCount" size="5" type="text" value="1" />個目の</div> <div> </div> <div><input id="adsH3" checked="checked" type="checkbox" />大見出し(h3)</div> <div><input id="adsH4" checked="checked" type="checkbox" />中見出し(h4)</div> <div><input id="adsH5" checked="checked" type="checkbox" />小見出し(h5)</div> <div><input id="adsOtherTag" type="checkbox" />その他タグ<input id="otherTags" type="text" value="h1,h2" /></div> <div>の</div> <input id="adsBefore" checked="checked" name="adsBeforeAfter" type="radio" value="before" />前 <input id="adsAfter" name="adsBeforeAfter" type="radio" value="after" />後</div> <p> </p> <div>アドセンスコード個数:</div> <div style="font-size: x-small; color: #707070;">複数個のアドセンスを文中に自動配置する場合、何個目のコードを生成するか指定します。</div> <div style="padding-left: 12px;"><input id="adsCount1" checked="checked" name="adsCount" type="radio" value="" />1つ目 <input id="adsCount2" name="adsCount" type="radio" value="2" />2つ目 <input id="adsCount3" name="adsCount" type="radio" value="3" />3つ目 <input id="adsCountN" name="adsCount" type="radio" value="N" /><input id="adsCountTh" size="5" type="text" value="4" />つ目</div> <p> </p> <div>挿入箇所がなかったら:</div> <div style="font-size: x-small; color: #707070;">大見出しがない記事など、挿入場所が見つからない場合の処理を指定します。</div> <div style="padding-left: 12px;"> <div><input id="adsFallbackStay" checked="checked" name="adsFallback" type="radio" value="stay" />なにもしない</div> <div><input id="adsFallbackHide" name="adsFallback" type="radio" value="hide" />表示しない</div> <div><input id="adsFallbackP" name="adsFallback" type="radio" value="p" />段落ベースで挿入場所を計算し直す</div> <div id="adsPArea" style="padding-left: 12px;">段落(pまたはdiv)の全体の <input id="adsPCountMother" size="5" type="text" value="2" />分の <input id="adsPCountChild" size="5" type="text" value="1" />の箇所(真ん中なら2分の1)に挿入</div> </div> <p> </p> <div>カテゴリーによる制限</div> <div style="font-size: x-small; color: #707070;">特定のカテゴリーが設定された記事の場合、広告そのものを表示しないモードの設定です。</div> <div style="padding-left: 12px;"> <div><input id="adsProhibited" checked="checked" type="checkbox" />カテゴリーによる制限を有効にする <div id="adsCatArea" style="padding-left: 12px;"><input id="adsProhibitedCategory" type="text" value="広告禁止" />カテゴリーではこのadsenseを表示しない</div> </div> <p> </p> <input id="adsCreate" type="button" value="作成!" /> <p> </p> <div> <div>コピペ用完成コード(このまま記事上や記事下にコピペください)</div> <div><textarea id="adsDest" style="width: 90%; font-size: xx-small;" rows="14">(作成!ボタンをおしてください)</textarea></div> </div> </div> <script>// <![CDATA[ var DIGITS = /^[0-9]+$/; addEventListener("DOMContentLoaded", function () { $('#adsPArea').hide(); $('input[name="adsFallback"]').change(function () { console.log($(this).attr('id')); if ($(this).attr('id') == 'adsFallbackP') { $('#adsPArea').show(); } else { $('#adsPArea').hide(); } }); $('#adsProhibited').change(function () { if ($(this).prop('checked')) { $('#adsCatArea').show(); } else { $('#adsCatArea').hide(); } }); $('#adsCreate').click(function () { var validateResult = validate(); if (validateResult) { alert(validateResult); return; } var scriptCodeInner = $('#adsSrc').val().replace(/\/script>/g, '/scrip>'); var targets = []; if ($('#adsH3').prop('checked')) { targets.push('h3'); } if ($('#adsH4').prop('checked')) { targets.push('h4'); } if ($('#adsH5').prop('checked')) { targets.push('h5'); } if ($('#adsOtherTag').prop('checked')) { if ($('#otherTags').val()) { targets = targets.concat($('#otherTags').val().split(',')); } } var qTargets = []; $.each(targets, function(i, v) { qTargets.push('.entry-content ' + v); }); var target = qTargets.join(','); var className = 'insentense-adsense' + $('input[name="adsCount"]:checked').val(); var varName = 'adsenseCode' + $('input[name="adsCount"]:checked').val(); if ($('input[name="adsCount"]:checked').val() == 'N') { className = 'insentense-adsense' + $('#adsCountTh').val(); varName = 'adsenseCode' + $('#adsCountTh').val(); } var position = $('#adsBefore').prop('checked') ? 'before' : 'after'; var indexStr; var adsBase = $('input[name="adsBase"]:checked').val(); if (adsBase == 'MC') { var hChild = $('#adsHCountChild').val(); var hMother = $('#adsHCountMother').val(); indexStr = 'Math.floor($targetElements.size() * ' + hChild + ' / ' + hMother + ')'; } else if (adsBase == 'U') { var uCount = $('#adsUCount').val(); indexStr = uCount - 1; } else if (adsBase == 'D') { var dCount = $('#adsDCount').val(); indexStr = '$targetElements.size() - ' + dCount; } var adsFallback = $('input[name="adsFallback"]:checked').val(); var pChild = ''; var pMother = ''; if (adsFallback == 'p') { pChild = $('#adsPCountChild').val(); pMother = $('#adsPCountMother').val(); } var prohibited = $('#adsProhibited').prop('checked'); var prohibitedCategory = ''; if (prohibited) { prohibitedCategory = $('#adsProhibitedCategory').val(); } var stat = [className, adsBase, hChild, hMother, uCount, dCount, position, adsFallback, pChild, pMother, prohibited, prohibitedCategory].join(','); var result = ""; result += '<!-- START v1.04 params=[' + stat + '] from http://uxlayman.hatenablog.com/entry/2017/01/26/insentenseform -->\n'; result += "<script>\n"; result += "var " + varName + " = (function () {/*\n"; result += "\n"; result += scriptCodeInner; result += "\n"; result += "\n"; result += "*/}).toString().match(/\\/\\*([^]*)\\*\\//)[1].replace(/scrip>/g, 'script>');\n"; result += "\n"; result += 'addEventListener("DOMContentLoaded", function() {\n'; result += "\n"; if (prohibited) { result += " if ($('" + 'meta[property="article:tag"][content="' + prohibitedCategory + '"]' + "').size() > 0) {\n"; result += " return;\n"; result += " }\n"; result += "\n"; } result += " var $targetElements = $('" + target + "');\n"; result += " var $target = $targetElements.eq(" + indexStr + ");\n"; if (adsFallback == 'stay') { result += " $target." + position + "($('." + className + "'));\n"; result += " $('." + className + "').html(" + varName + ");\n"; } else if (adsFallback == 'hide') { result += " if ($target.size() > 0) {\n"; result += " $target." + position + "($('." + className + "'));\n"; result += " $('." + className + "').html(" + varName + ");\n"; result += " }\n"; } else if (adsFallback == 'p') { result += " if ($target.size() > 0) {\n"; result += " $target." + position + "($('." + className + "'));\n"; result += " } else {\n"; result += " $targetElements = $('.entry-content>p, .entry-content>div');\n"; result += " $targetElements.eq(Math.floor($targetElements.size() * " + pChild + " / " + pMother + ")).before($('." + className + "'));\n"; result += " }\n"; result += " $('." + className + "').html(" + varName + ");\n"; } result += "\n"; result += "}, false);\n"; result += "<" + "/script" + ">\n"; result += '<div class="' + className + '"></div>\n'; result += '<!-- END v1.04 from http://uxlayman.hatenablog.com/entry/2017/01/26/insentenseform -->\n'; $('#adsDest').val(result); }); }, false); function validate() { if (!$('#adsSrc').val() || $('#adsSrc').val().length == 0) { return '自動配置用広告コードが空だよ'; } var adsBase = $('input[name="adsBase"]:checked').val(); if (adsBase == 'MC') { if (!DIGITS.test($('#adsHCountMother').val()) || !DIGITS.test($('#adsHCountChild').val())) { return '挿入箇所の◯分の◯のところが数字じゃないよ。半角になってる?'; } if (parseInt($('#adsHCountMother').val(), 10) <= parseInt($('#adsHCountChild').val(), 10)) { return '挿入箇所の◯分の◯のところ、分子>=分母になってるよ'; } } else if (adsBase == 'U') { if (!DIGITS.test($('#adsUCount').val())) { return '挿入箇所の上から◯個目のところが数字じゃないよ。半角になってる?'; } if (parseInt($('#adsUCount').val(), 10) <= 0) { return '挿入箇所の上から◯個目のところが1より小さいよ'; } } else if (adsBase == 'D') { if (!DIGITS.test($('#adsDCount').val())) { return '挿入箇所の下から◯個目のところが数字じゃないよ。半角になってる?'; } if (parseInt($('#adsDCount').val(), 10) <= 0) { return '挿入箇所の下から◯個目のところが1より小さいよ'; } } if (!$('#adsH3').prop('checked') && !$('#adsH4').prop('checked') && !$('#adsH5').prop('checked') && !$('#adsOtherTag').prop('checked')) { return '挿入箇所の見出しが一つも選ばれてないよ'; } var adsFallback = $('input[name="adsFallback"]:checked').val(); if (adsFallback == 'p') { var pChild = $('#adsPCountChild').val(); var pMother = $('#adsPCountMother').val(); if (!DIGITS.test(pChild) || !DIGITS.test(pMother)) { return '段落ベースで挿入場所を計算し直す◯分の◯のところが数字じゃないよ。半角になってる?'; } if (parseInt(pMother, 10) <= parseInt(pChild, 10)) { return '段落ベースで挿入場所を計算し直すの◯分の◯のところ、分子>=分母になってるよ'; } } if ($('#adsProhibited').prop('checked')) { if (!$('#adsProhibitedCategory').val() || $('#adsProhibitedCategory').val().length == 0) { return '禁止カテゴリー名が空だよ'; } } return null; } // ]]></script> <h4>更新履歴</h4> <div>v1.01(2017/5/20)</div> <ul> <li>挿入場所に絶対指定(上から○個目、下から○個目)を追加</li> <li>挿入場所判定に、任意のタグ名を指定可能に変更(カスタマイズなどで大見出しのタグを変更している人用)</li> <li>3つ以上の自動挿入コード生成に対応(個数制限撤廃したらしいので)</li> </ul> <div>v1.02(2017/9/18)</div> <ul> <li>「挿入箇所がなかったらなにもしない」が正しく動作していなかった問題を修正</li> </ul> <div>v1.03(2018/6/24)</div> <ul> <li>Adsense個数を5個以上にした際に、表示がされない問題を修正</li> </ul> <div>v1.04(2019/6/23)</div> <ul> <li>最初のひとつ以外の挿入場所タグが、記事エリア内だけでなくページ全体から探索されていた問題を修正。「段落」の検出範囲を本文直下のみに修正</li> </ul> uxlayman LINEのタイムラインってなんなの?昔のに戻せないの? hatenablog://entry/10328749687194522757 2016-11-15T22:53:00+09:00 2022-02-28T21:13:53+09:00 つうかLINEのタイムラインにいつからかニュースが入り込むようになってあれ出ないようにできないの?— りんご4個分 (@uxlayman) 2016年11月15日 LINEのタイムライン、昔(半年前くらいまで?)は友だちが書いた近況とか、一言メッセージ変えましたとか写真変えましたとかの通知が表示される場所だったと思うんだけど、いつからか急にニュースとかが表示されるようになったんだよね。 で、いま改めてよく見てみたらニュースっていうか、↓みたいなLINEの謎サービスが毎日通知されたり、楽天カードの広告が出てきたりする場所になってたんだわ。 LINEのタイムライン表示例 これってなんなの?1日に2… <p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">つうかLINEのタイムラインにいつからかニュースが入り込むようになってあれ出ないようにできないの?</p>&mdash; りんご4個分 (@uxlayman) <a href="https://twitter.com/uxlayman/status/798512326848585728?ref_src=twsrc%5Etfw">2016年11月15日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p>LINEのタイムライン、昔(半年前くらいまで?)は友だちが書いた近況とか、一言メッセージ変えましたとか写真変えましたとかの通知が表示される場所だったと思うんだけど、いつからか急にニュースとかが表示されるようになったんだよね。</p> <p>で、いま改めてよく見てみたらニュースっていうか、↓みたいなLINEの謎サービスが毎日通知されたり、楽天カードの広告が出てきたりする場所になってたんだわ。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161115222544p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161115/20161115222544.png" alt="f:id:uxlayman:20161115222544p:plain" /></p> <p class="photo-caption">LINEのタイムライン表示例</p> <p> </p> <p>これってなんなの?1日に2つも3つもこんなのがタイムラインにプッシュされるから友だちの共有情報みるのがすごい手間になってるんだけど。</p> <p>いちおう非表示にはできるけど、「RECIPE by LINE」を全ブロックとかはできなくて、1投稿単位でしか非表示にできないんだよね。意味ねえ。</p> <p> </p> <p>それで話戻すけど、これ、ほんとどういうことなの?以前のタイムライン機能を見たければこの謎広告の山をずっとスルーしながら友だちの情報探せってこと?さすがにひどくない?</p> <p>でもそれにしてはあんまりこれに文句言ってる人見たことない。もしかしてこっそり非表示にする設定があるとかなんだろうか?教えてクレメンス!</p> <p> </p> <div class="itunes-embed freezed itunes-kind-software"><a href="https://itunes.apple.com/jp/app/line/id443904275?mt=8&amp;uo=4&amp;at=10lKZL" target="_blank" rel="nofollow"><img class="itunes-embed-image" title="LINE" src="http://cdn.image.st-hatena.com/image/scale/4031f044a4c7317aa322fed86ac4c324ee4745c7/enlarge=0;height=200;version=1;width=200/http://is5.mzstatic.com/image/thumb/Purple71/v4/0f/c6/c7/0fc6c73e-072f-e06b-a2b4-cc45e6f3fc35/source/100x100bb.jpg" alt="LINE" /></a> <div class="itunes-embed-info"> <p class="itunes-embed-title"><a href="https://itunes.apple.com/jp/app/line/id443904275?mt=8&amp;uo=4&amp;at=10lKZL" target="_blank" rel="nofollow">LINE</a></p> <ul> <li class="itunes-embed-artist">LINE Corporation</li> <li class="itunes-embed-genre">ソーシャルネットワーキング</li> <li class="itunes-embed-price">無料</li> <li class="itunes-embed-badge"><a href="https://itunes.apple.com/jp/app/line/id443904275?mt=8&amp;uo=4&amp;at=10lKZL" target="_blank" rel="nofollow"><img src="https://cdn.blog.st-hatena.com/images/theme/itunes/itunes-badge-appstore@2x.png" alt="" width="60px" height="15px" /></a></li> </ul> </div> </div> <p> </p> <p> </p> uxlayman AppleはiOS10のメールアプリの戻る/進む表示をいますぐ元に戻せ hatenablog://entry/10328749687194219957 2016-11-13T21:00:00+09:00 2022-02-28T21:13:52+09:00 史上最大の変更があったと言われるiOS10ですが、リリースノートに載ってない範囲でも地味に変更があるようです。 今回はそれ系の話です。 純正のメールアプリ、一覧から1つメールをタップすると、右上に戻る/進むボタンが出てきます。以下の画面です。 メールアプリの戻る/進む(iOS10) さて、この<と>の表記、一覧でいう下のメール(古いもの)を表示させたい時、どっちがどっちかわかりますか? 正解は<が下へなんです。 どうでしょう。イメージと逆の人も多かったかもしれません。先に進む=読み進むと判断して、>だと思った人も多いでしょう*1。ここにもひとしきり文句言いたいところですが、とりあえず置いておい… <p>史上最大の変更があったと言われるiOS10ですが、リリースノートに載ってない範囲でも地味に変更があるようです。</p> <p>今回はそれ系の話です。</p> <p> </p> <p>純正のメールアプリ、一覧から1つメールをタップすると、右上に戻る/進むボタンが出てきます。以下の画面です。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161113192448p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161113/20161113192448.png" alt="f:id:uxlayman:20161113192448p:plain" /></p> <p class="photo-caption">メールアプリの戻る/進む(iOS10)</p> <p>さて、この&lt;と&gt;の表記、一覧でいう下のメール(古いもの)を表示させたい時、どっちがどっちかわかりますか?</p> <p>正解は&lt;が下へなんです。</p> <p>どうでしょう。イメージと逆の人も多かったかもしれません。先に進む=読み進むと判断して、&gt;だと思った人も多いでしょう<a href="#f-8338fc8e" name="fn-8338fc8e" title="伝統的には時間軸降順のリストに対する「戻る」「進む」問題というのは存在する。ページは進むけど時間は戻る、どっちのことを指してるねん、と。ソート条件が時間とは限らない場合は諦めて「ページを進める=進む」とすることが多い。ソート条件が時間軸降順しかない場合は、&amp;lt;新しい記事 古い記事> みたいな表現にして誤解を招かないようにすることが多い。ブログ記事でもそうだよね。">*1</a>。ここにもひとしきり文句言いたいところですが、とりあえず置いておいて、同じ純正メールアプリのiOS9版を見てみましょう</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161113193406p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161113/20161113193406.png" alt="f:id:uxlayman:20161113193406p:plain" /></p> <p class="photo-caption">メールアプリの戻る/進む(iOS9)</p> <p>いや、おい・・・なんで変えたん。いままででなんの問題もなかったじゃんか。上ボタンで上のメール、下ボタンで下のメール。これ以上ないほどシンプルかつ明確で、間違えようがない。</p> <p> </p> <p>話はさらに続きます。iOS10では、メールのスレッド表示が改善されて、1画面でスレッドメッセージが全部みれるようになりました。ここにも戻る/進むボタンがあって、「次のメッセージの冒頭」「前のメッセージの冒頭」へジャンプできます。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161113190537p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161113/20161113190537.png" alt="f:id:uxlayman:20161113190537p:plain" /></p> <p class="photo-caption">メールのスレッド表示(iOS10)</p> <p>さて、この&lt;と&gt;、どちらが下へで、どちらが上へでしょう?そんなの非スレッドモードと同じに決まってるだとと思ったみなさん。違います。</p> <p>スレッドモードでは「&gt;が下へ」で「&lt;が上へ」なんです。非スレッドモードでは「&gt;が上へ」で「&lt;が下へ」なんです。わかるかっつーの!頭おかしいんじゃないの?<a href="#f-96312a46" name="fn-96312a46" title="一応フォローしておくと、この挙動に一貫性がないわけではない。一貫して、時間を戻す方が戻る(&amp;lt;)で、時間を進める方が進む(&amp;gt;)なのである。一覧ではメッセージが受信日時の降順に並んでいて、スレッドは起点メッセージから返信メッセージが順に、つまり昇順に並ぶからこうなる">*2</a></p> <p> </p> <p> </p> <p>いったいなぜこんなことが起きるのか。</p> <ul> <li>iOS9の時点でなんの問題もなかったものを「わざわざ」変更した</li> <li>変更して明らかに改悪になったものにだれも気づかない</li> <li>機能間で不整合を起こしていることにだれも気づかない</li> </ul> <p>こういう意味不明なことをする会社はやばいと思う。UCDだとかUX中心ではないなんらかのプロセスや意図が幅を利かせて、デザインプロセスが崩壊しかけていることを予見させる。Apple本格的にやばいんでないか。</p> <p>ていうかなんでもいいけど早くもどせよ。毎日ストレスなんだよ。</p> <p> </p> <p><span style="color: #d32f2f;">2017/4追記</span></p> <p><span style="color: #d32f2f;">iOS10.3で元の上下移動に戻ったようです。いったいなんだったんだろ、、、</span></p> <p> </p><div class="footnote"> <p class="footnote"><a href="#fn-8338fc8e" name="f-8338fc8e" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">伝統的には時間軸降順のリストに対する「戻る」「進む」問題というのは存在する。ページは進むけど時間は戻る、どっちのことを指してるねん、と。ソート条件が時間とは限らない場合は諦めて「ページを進める=進む」とすることが多い。ソート条件が時間軸降順しかない場合は、&lt;新しい記事 古い記事></p> <p>みたいな表現にして誤解を招かないようにすることが多い。ブログ記事でもそうだよね。</span></p> <p class="footnote"><a href="#fn-96312a46" name="f-96312a46" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">一応フォローしておくと、この挙動に一貫性がないわけではない。一貫して、時間を戻す方が戻る(&lt;)で、時間を進める方が進む(&gt;)なのである。一覧ではメッセージが受信日時の降順に並んでいて、スレッドは起点メッセージから返信メッセージが順に、つまり昇順に並ぶからこうなる</span></p> </div> uxlayman 【ポケモンGO】図鑑につっこむ hatenablog://entry/10328749687188979635 2016-10-16T08:42:00+09:00 2022-02-28T21:13:52+09:00 ポケモンやるのはポケモンGOが初めてなんですけど、図鑑って結構つっこみどころ多くないですか、という内容を徒然に書いていきます。 一応、まだ捕まえてない図鑑が見えてしまうかもという意味でネタバレ注意。 ヤドン 図鑑に目覚めたきっかけがこれ。ポケモンたちにはほのおポケモンとかでんきポケモンとかって愛称(?)があるのですが まぬけポケモンってひどすぎるwww とおもったが 尻尾を川に入れてエサを釣っているが、そのうちなにをしているのか忘れてしまい川べりに寝そべったまま1日を終える。 いやあ。。。これは確かにまぬけかな。。。 ヤドラン そんなヤドンの進化系がヤドラン シェルダーがかみついているので尻尾… <p>ポケモンやるのはポケモンGOが初めてなんですけど、図鑑って結構つっこみどころ多くないですか、という内容を徒然に書いていきます。</p> <p>一応、まだ捕まえてない図鑑が見えてしまうかもという意味でネタバレ注意。</p> <p> </p> <h4>ヤドン</h4> <p>図鑑に目覚めたきっかけがこれ。ポケモンたちにはほのおポケモンとかでんきポケモンとかって愛称(?)があるのですが</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220303j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220303.jpg" alt="f:id:uxlayman:20161005220303j:plain" /></p> <p>まぬけポケモンってひどすぎるwww</p> <p>とおもったが</p> <blockquote> <p>尻尾を川に入れてエサを釣っているが、そのうちなにをしているのか忘れてしまい川べりに寝そべったまま1日を終える。</p> </blockquote> <p>いやあ。。。これは確かにまぬけかな。。。</p> <p> </p> <h4>ヤドラン</h4> <p>そんなヤドンの進化系がヤドラン</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220306j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220306.jpg" alt="f:id:uxlayman:20161005220306j:plain" /></p> <blockquote> <p>シェルダーがかみついているので尻尾でエサを釣れなくなったヤドランは渋々水中を泳いでエサを捕まえている。</p> </blockquote> <p>いや渋々て。進化したのが残念みたいな言い草わろす。</p> <p>それはそうと、ヤドランの尻尾についているの、シェルダーなんですね。ここでちょっっとシェルダーを見てみましょう。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220340j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220340.jpg" alt="f:id:uxlayman:20161005220340j:plain" /></p> <p> </p> <p>・・・?!</p> <p>いや、ヤドランの尻尾に食いついてる奴と違くない?シェルダーは2枚貝、ヤドランの尻尾は巻貝じゃない?!</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161011225357j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161011/20161011225357.jpg" alt="f:id:uxlayman:20161011225357j:plain" /></p> <p>どうみても別物です本当にありがとうございました。進化とは一体・・・・</p> <p> </p> <p> </p> <h3>進化の不思議</h3> <h4>ワンリキー→ゴーリキー→カイリキー</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220157j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220157.jpg" alt="f:id:uxlayman:20161005220157j:plain" /></p> <blockquote> <p>どんなに運動をしても痛くならない特別な筋肉を持つポケモン。大人100人を投げ飛ばすパワー</p> </blockquote> <p>大人100人を投げ飛ばす!すごい!</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220159j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220159.jpg" alt="f:id:uxlayman:20161005220159j:plain" /></p> <blockquote> <p>鍛えあげた筋肉は鋼の硬さ。相撲取りの体も指一本で楽々持ちあげてしまう怪力のポケモンだ。</p> </blockquote> <p>相撲取りを指一本。</p> <p>いや、すごいけど・・・?進化前は100人を投げ飛ばせてたんだよね。成人男子が60kgだとすると、6tを投げ飛ばせてたわけだ。相撲取りは200kgくらいだから、指一本とはいえ、進化・・・してるのか?</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220203j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220203.jpg" alt="f:id:uxlayman:20161005220203j:plain" /></p> <blockquote> <p>なんでも投げ飛ばすパワーを持つが細かい作業をすると腕が絡まってしまう。考えるよりも先に体が動く。</p> </blockquote> <p>あ、れ・・・?なんかすごいやつというより単なる馬鹿になってない?!進化の過程で脳筋になったというオチやめれ。</p> <p> </p> <h4>マンキー→オコリザル</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220116j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220116.jpg" alt="f:id:uxlayman:20161005220116j:plain" /></p> <blockquote> <p>激しく怒ることで血行が良くなり筋肉の力を強くするのだ。ただし頭の回転は遅くなるぞ。</p> </blockquote> <p>いやだから進化の過程で脳筋(略)</p> <p>ていうか血行てw</p> <p> </p> <h4>クラブ→キングラー</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220453j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220453.jpg" alt="f:id:uxlayman:20161005220453j:plain" /></p> <blockquote> <p>キングラーは巨大なハサミを振って仲間同士で合図を送りあっているがハサミが重すぎてすぐに疲れてしまう。</p> </blockquote> <p>いやだからw</p> <p> </p> <h4>イシツブテ→ゴローン→ゴローニャ</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220248j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220248.jpg" alt="f:id:uxlayman:20161005220248j:plain" /></p> <blockquote> <p>長生きのイシツブテほど体の角は削れ丸くなっていくが気持ちはいつまでもごつごつとがって荒々しいのだ。</p> </blockquote> <p>ふむ。長年かけて石が意志をもつ的な感じなのかな?素敵やん。</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220251j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220251.jpg" alt="f:id:uxlayman:20161005220251j:plain" /></p> <blockquote> <p>岩を食べて成長するポケモンだ。コケのついた岩のほうが好きらしい。1日に1トンの岩を食べてしまうぞ。</p> </blockquote> <p>え?岩を・・・食べるの?そんな設定だったっけ?もしかして、食べてる岩って・・・ゴクリ。進化とはおそろしい。</p> <p>そして1日に1トンも岩を食べるのに、重さは105kg(0.105トン)である謎。</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220254j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220254.jpg" alt="f:id:uxlayman:20161005220254j:plain" /></p> <blockquote> <p>大きな地震が起こると山にすんでいるゴローニャが何匹もふもとまでごろごろ転がり落ちてくることがあるよ。</p> </blockquote> <p>進化の謎は放り出して突然のあるあるTips。というか地震で転がり落ちるとか間抜けである。ここだけ見るとやはり進化の過程で馬鹿になっている?!</p> <p> </p> <h4>カラカラ→ガラガラ</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220513j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220513.jpg" alt="f:id:uxlayman:20161005220513j:plain" /></p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220515j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220515.jpg" alt="f:id:uxlayman:20161005220515j:plain" /></p> <blockquote> <p>2度と会えない母親の面影を満月にみつけて泣き声をあげる。被っているホネの染みは涙のあと。</p> <p>母親に会えない哀しみを乗り越えたカラカラがたくましく進化した姿。鍛えられた心は簡単にくじけない。</p> </blockquote> <p>いい話風ではあるが、結局このホネは誰のなのか。母親なのか?むしろ進化してホネと顔が一体化してるようにみえるがそっちは大丈夫なのだろうか。</p> <p> </p> <h4>タマタマ→ナッシー</h4> <p>ポケモン初体験だったのでこの進化は衝撃でしたね。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220503j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220503.jpg" alt="f:id:uxlayman:20161005220503j:plain" /></p> <blockquote> <p>仲間思いの6個の卵はお互いに引きつけ合いくるくる回転している。カラのヒビが増えると進化は間近だ。</p> </blockquote> <p>ふむ。そもそも6個イチはありなのかというのが純粋な疑問。</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220508j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220508.jpg" alt="f:id:uxlayman:20161005220508j:plain" /></p> <blockquote> <p>南国生まれのナッシーの頭は強い日差しをいっぱい浴びてどんどん育ち地面に落ちるとタマタマになるという。</p> </blockquote> <p>6個が進化の過程で3個に・・・。そして残った3個が満足そうな見下したような顔をしている。これは・・・意味深。</p> <p>そしてこいつが地面に落ちてタマタマになるということは・・・退化?</p> <p>地面に落ちて、いつの間にかカラがついて、6個組になって、そして進化の過程でまた3個が謎の失踪を遂げる?怖い・・・</p> <p> </p> <h4>ディグダ→ダグトリオ</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220028j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220028.jpg" alt="f:id:uxlayman:20161005220028j:plain" /></p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220031j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220031.jpg" alt="f:id:uxlayman:20161005220031j:plain" /></p> <p><span style="line-height: 1.5;">進化だけじゃなくて数が増えただけだろ。</span></p> <p> </p> <h4><span style="line-height: 1.5;">コイル→レアコイル </span></h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220310j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220310.jpg" alt="f:id:uxlayman:20161005220310j:plain" /></p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220313j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220313.jpg" alt="f:id:uxlayman:20161005220313j:plain" /></p> <p>きみもだな</p> <p> </p> <h3>妙に庶民的</h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005215553j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005215553.jpg" alt="f:id:uxlayman:20161005215553j:plain" /></p> <blockquote> <p>水の弾丸を50メートル離れた空き缶に命中させることができるぞ。</p> </blockquote> <p>空き缶・・・?w</p> <p>いやなんかわかるけどさ、試し撃ちが空き缶ってはさ。でもモンスターもやっぱり空き缶で試射とかするわけ?</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005215729j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005215729.jpg" alt="f:id:uxlayman:20161005215729j:plain" /></p> <blockquote> <p>締めつける力はとても強力。ドラム缶もぺしゃんこにしてしまうぞ。</p> </blockquote> <p>ドラム缶・・・?w</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220047j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220047.jpg" alt="f:id:uxlayman:20161005220047j:plain" /></p> <p>金メダリストw</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220137j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220137.jpg" alt="f:id:uxlayman:20161005220137j:plain" /></p> <p>太平洋w</p> <p> </p> <h3>そのたいろいろ </h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220130j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220130.jpg" alt="f:id:uxlayman:20161005220130j:plain" /></p> <blockquote> <p>渦巻き模様の内臓が透けてしまうほど薄い皮膚だが鋭いキバをはね返す弾力を持っているのだ。</p> </blockquote> <p>え?その渦巻き内臓だったの?内臓という事は、つまり透けて見えているのは・・・うn・・・</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220154j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220154.jpg" alt="f:id:uxlayman:20161005220154j:plain" /></p> <blockquote> <p>脳がどんどん大きくなったので首では支えきれないほど頭が重くなった。超能力で頭を支えているのだ</p> </blockquote> <p>なんかさらっとこわいこというなよ</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220349j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220349.jpg" alt="f:id:uxlayman:20161005220349j:plain" /></p> <blockquote> <p>闇に浮かぶゴーストが手招きしても絶対に近寄ってはいけないよ。ペロリとなめられ命を吸われてしまうぞ。</p> </blockquote> <p>突然こわいこというなよ</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220352j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220352.jpg" alt="f:id:uxlayman:20161005220352j:plain" /></p> <blockquote> <p>真夜中街灯の灯りでできた影が自分を追い越していくのはゲンガーが影に成りすまして走っていくからだ。</p> </blockquote> <p>ありそうな具体的なシチュエーションでこわいこというなよ</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220427j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220427.jpg" alt="f:id:uxlayman:20161005220427j:plain" /></p> <blockquote> <p>眠っているときキミの鼻がムズムズしたらまくら元に立ったスリープが鼻の穴から夢を食べようとしている合図。</p> </blockquote> <p>具体的なシチュエーションで微妙に結果がどうなるかよくわからなくてこわいこというなよ</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220317j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220317.jpg" alt="f:id:uxlayman:20161005220317j:plain" /></p> <blockquote> <p>持っている植物のクキにも良いものとそうでないものがあるらしくカモネギ同士がクキを巡って戦うことがある。</p> </blockquote> <p>いや、別にいいんだけどなぜネギのことをクキとぼかすのか。</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220457j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220457.jpg" alt="f:id:uxlayman:20161005220457j:plain" /></p> <blockquote> <p>モンスターボールをつくっている会社で初めて発見されたことと姿形が似ていることの関係はまだナゾである。</p> </blockquote> <p>ナゾて。状況証拠から明らかだろwww</p> <p>規格外の不正なモンスターボールが流出したんだろwww</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220547j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220547.jpg" alt="f:id:uxlayman:20161005220547j:plain" /></p> <blockquote> <p>敵につかまれるとツルはブチっと切れる。全然痛くないのでそのスキに逃げる。翌日には新しいツルが生えそろうぞ。</p> </blockquote> <p>ツルがトカゲの尻尾的なのはわかったけど、ツルのなかのこの目がついてる黒い部分はなんなのか。銀河鉄道999の車掌的なやつか</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220615j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220615.jpg" alt="f:id:uxlayman:20161005220615j:plain" /></p> <blockquote> <p>避雷針代わりにする街もある</p> </blockquote> <p>おや?ブラックな香りが・・・</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220652j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220652.jpg" alt="f:id:uxlayman:20161005220652j:plain" /></p> <blockquote> <p>コイキングからギャラドスに進化するとき脳細胞の構造が組み換わるために性格が凶暴になるといわれている。</p> </blockquote> <p>こわいこというなよ。きょうあくポケモンという言い草もひどいw</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220701j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220701.jpg" alt="f:id:uxlayman:20161005220701j:plain" /></p> <blockquote> <p>暮らしている環境で突然変異する不安定な遺伝子を持つポケモン。石の放射線が進化を引き起こす。</p> </blockquote> <p>こわいこというなよ2</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220656j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220656.jpg" alt="f:id:uxlayman:20161005220656j:plain" /></p> <blockquote> <p>人が絶滅の危機に追い込んでしまった。夕暮どきになると少なくなった仲間を探して悲しそうな声で歌うという。</p> </blockquote> <p>最強といわれるラプラスだけど、これだけみるとかわいそうな子。ていうかこれみると戦闘用というよりむしろ乗り物。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220720j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220720.jpg" alt="f:id:uxlayman:20161005220720j:plain" /></p> <blockquote> <p>全身をプログラムデータに戻して電子空間に入ることができる。コピーガードされているのでコピーできない。</p> </blockquote> <p>急に世界観どした</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220738j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220738.jpg" alt="f:id:uxlayman:20161005220738j:plain" /></p> <blockquote> <p>大きなお腹の上を遊び場にしている子どもたちもいるほどおとなしいポケモンだ</p> </blockquote> <p>トトロ乙</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220337j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220337.jpg" alt="f:id:uxlayman:20161005220337j:plain" /></p> <blockquote> <p>1滴でプールの水が濁り臭いだす。</p> </blockquote> <p>リオデジャネイロのシンクロプールかな?</p> <p> </p> <h4>速すぎるやつら</h4> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220300j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220300.jpg" alt="f:id:uxlayman:20161005220300j:plain" /></p> <blockquote> <p>いつもはのんびり野原を駆けまわっているが一度本気を出すとたてがみの炎が燃えあがり時速240キロで走りだす。</p> </blockquote> <p>240km!!!チーターと同じ!</p> <p>  </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220127j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220127.jpg" alt="f:id:uxlayman:20161005220127j:plain" /></p> <blockquote> <p>10000キロの距離を一昼夜で走るといわれている快速のポケモン。</p> </blockquote> <p>一昼夜が24時間だとすると、時速416km。快速とかいうレベルじゃないだろ。リニアか。</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20161005220751j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20161005/20161005220751.jpg" alt="f:id:uxlayman:20161005220751j:plain" /></p> <blockquote> <p>16時間で地球を1周できる。嵐で難破しかけた船を見つけると陸地まで誘導する優しいポケモン。</p> </blockquote> <p>地球一周は約40000kmなので、時速に直すと2500km。マッハ2.5</p> <p>戦闘機じゃねーか。船がどうとかそういう問題じゃないだろ</p> <p> </p> <p> </p> <p>オチもまとめもありません。金銀ポケモン追加が楽しみです。かしこ</p> uxlayman 日本未発売(?)のスマート体組成計Withings Body CardioをApple Storeでゲット! hatenablog://entry/10328749687177941144 2016-08-07T18:30:00+09:00 2022-02-28T21:13:53+09:00 iPhoneで体重が記録できるWithingsの体重計を使っていたのですが、今年1月くらいから体脂肪が測れなくなってしまって、どうしようかと思っていたのです。 そんな中、今年(2016年)6月に、体脂肪に加えて、体⽔分率、⾻量、筋⾁量、⼼拍が測定できる新型が発売されて、こいつが日本で発売されたら速攻で買おうと決めて日々を過ごしていました。 しかし、ひょんなことから実はApple Storeですでに発売が開始されていたことが判明!!「限定」ってあるから日本ではApple Store限定発売なのかな? というわけで公約通り速攻で購入しましたのでレビューしていきます。(文末に詳しく書きましたが、Ap… <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807123345j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807123345.jpg" alt="f:id:uxlayman:20160807123345j:plain" /></p> <p>iPhoneで体重が記録できるWithingsの体重計を使っていたのですが、今年1月くらいから体脂肪が測れなくなってしまって、どうしようかと思っていたのです。</p> <p>そんな中、今年(2016年)6月に、体脂肪に加えて、体⽔分率、⾻量、筋⾁量、⼼拍が測定できる新型が発売されて、こいつが日本で発売されたら速攻で買おうと決めて日々を過ごしていました。</p> <p><iframe class="embed-card embed-webcard" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" title="Withingsが⼼⾎管の状態が測定できるスマート体組成計『Body Cardio』を発売" src="//hatenablog-parts.com/embed?url=http%3A%2F%2Fdime.jp%2Fgenre%2F262750%2F1%2F" frameborder="0" scrolling="no"></iframe></p> <p> </p> <p>しかし、ひょんなことから実はApple Storeですでに発売が開始されていたことが判明!!「限定」ってあるから日本ではApple Store限定発売なのかな?</p> <p>というわけで公約通り速攻で購入しましたのでレビューしていきます。(文末に詳しく書きましたが、Apple Store経由で買って、保証関係がどうなるかだけはちょっと気になります)</p> <p><iframe class="embed-card embed-webcard" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" title="Withings Body Cardio Scale - ホワイト" src="//hatenablog-parts.com/embed?url=http%3A%2F%2Fwww.apple.com%2Fjp%2Fshop%2Fproduct%2FHK3T2PA%2FA%2Fwithings-body-cardio-scale-%25E3%2583%259B%25E3%2583%25AF%25E3%2582%25A4%25E3%2583%2588%3Ffnode%3D4a" frameborder="0" scrolling="no"></iframe></p> <p> </p> <p><cite class="hatena-citation"> </cite></p> <h3>箱とか</h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121202j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121202.jpg" alt="f:id:uxlayman:20160807121202j:plain" /></p> <p>はこどーん。この箱とほぼ同サイズの配送用ダンボール箱に入ってきました。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121239j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121239.jpg" alt="f:id:uxlayman:20160807121239j:plain" /></p> <p>箱裏の注意書き一部。あらゆる表記が英語、中国語、日本語の3ヶ国語表示。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121449j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121449.jpg" alt="f:id:uxlayman:20160807121449j:plain" /></p> <p> 箱の中にもう一個内箱が入っていて、これが上に開くようになっている</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121510j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121510.jpg" alt="f:id:uxlayman:20160807121510j:plain" /></p> <p>こんな感じ</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121528j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121528.jpg" alt="f:id:uxlayman:20160807121528j:plain" /></p> <p>取り出すと裏に薄いマニュアル。上の方に見えるロゴ入りのちっちゃい箱の中に充電用USBケーブル(ただし充電済みなのでしばらくは使わない)</p> <p> </p> <p> </p> <h3>電源ON〜初期設定</h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121736j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121736.jpg" alt="f:id:uxlayman:20160807121736j:plain" /></p> <p>このかっこいい電源を長押しすると</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121750j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121750.jpg" alt="f:id:uxlayman:20160807121750j:plain" /></p> <p>Helloって出てくる!(写真とるの遅れて次の表示とダブってますが)</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121800j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121800.jpg" alt="f:id:uxlayman:20160807121800j:plain" /></p> <p>そんでこの表記になる。この後はうんともすんとも言わなくなるので、表記の通りこのURLにいってアプリをダウンロードします。私はすでに持っていたので、起動させるだけ。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121554j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121554.jpg" alt="f:id:uxlayman:20160807121554j:plain" /></p> <p> 起動時点ですでに認識されているので、選ぶだけ!この魔法感!</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121626j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121626.jpg" alt="f:id:uxlayman:20160807121626j:plain" /></p> <p>選ぶとこんな感じになる。次へ</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121632j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121632.jpg" alt="f:id:uxlayman:20160807121632j:plain" /></p> <p>いきなりアップデートが始まる。スマホみたいw</p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122134j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122134.jpg" alt="f:id:uxlayman:20160807122134j:plain" /></p> <p>アップデート中、本体の画面はこんな感じに。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121714j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121714.jpg" alt="f:id:uxlayman:20160807121714j:plain" /></p> <p>結構時間かかったかな。2,3分くらい。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807121858j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807121858.jpg" alt="f:id:uxlayman:20160807121858j:plain" /></p> <p>ここで、(体重計に設定する)Wi-Fiを選ぶ。iPhoneが接続しているWi-Fiを選ぶだけなので簡単。ですが!<strong>体重計は2.4GHz帯のWi-Fi(802.11b/g/nとか)にしか対応していません。</strong>普段は5GHz帯(802.11a)を使っていたのでエラーになってしまいました。</p> <p>2.4GHzのWi-Fiを設定し直して事なきをえました。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122056j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122056.jpg" alt="f:id:uxlayman:20160807122056j:plain" /></p> <p>そんでこうなる。次へ</p> <p> </p> <p> </p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122109j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122109.jpg" alt="f:id:uxlayman:20160807122109j:plain" /></p> <p>唐突に英語で友達に紹介しないかと言われるw</p> <p>ご愛嬌。スキップして、セットアップは終わりです。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122346j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122346.jpg" alt="f:id:uxlayman:20160807122346j:plain" /></p> <p>本体も無事Ready表記に!</p> <p> </p> <p> </p> <h3>体重測定</h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122648j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122648.jpg" alt="f:id:uxlayman:20160807122648j:plain" /></p> <p>簡易的(一週間分?)なグラフと、前回測定時からの差分が出る。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122437j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122437.jpg" alt="f:id:uxlayman:20160807122437j:plain" /></p> <p>体脂肪率。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122441j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122441.jpg" alt="f:id:uxlayman:20160807122441j:plain" /></p> <p>水分量</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122658j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122658.jpg" alt="f:id:uxlayman:20160807122658j:plain" /></p> <p>天気</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122702j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122702.jpg" alt="f:id:uxlayman:20160807122702j:plain" /></p> <p>脈拍測定中</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807122707j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807122707.jpg" alt="f:id:uxlayman:20160807122707j:plain" /></p> <p>測定完了。なお、脈拍測定完了まで上に乗ってないといけません。10-20秒かな?</p> <p> </p> <h3>アプリ側</h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807124714j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807124714.jpg" alt="f:id:uxlayman:20160807124714j:plain" /></p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807124719j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807124719.jpg" alt="f:id:uxlayman:20160807124719j:plain" /></p> <p>アプリ側で測定後に出てた表示。</p> <p><span style="color: #ff5252;">8/10追加修正</span></p> <p><span style="text-decoration: line-through;">要するに、5回測定するまではパルスウェーブ速度が精緻化されていないので心拍数の精度は悪いよって事なのかな?</span></p> <p>パルスウェーブ=脈波伝搬速度で、心臓の鼓動が動脈を伝わる速度だそうです。</p> <blockquote> <p>動脈が硬化しているほど伝搬速度が速くなることが立証されています</p> </blockquote> <p>とのことで、要は遅ければ遅いほどよいという事かな?この測定が安定するまでに、5回の測定が必要ってことのようです。心拍数とは別ですね。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160811001728j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160811/20160811001728.jpg" alt="f:id:uxlayman:20160811001728j:plain" /></p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160811002208j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160811/20160811002208.jpg" alt="f:id:uxlayman:20160811002208j:plain" /></p> <p> </p> <p> </p> <h3>旧型機の比較</h3> <p>いままで使っていた同じくWithings製の体重計(型番WS−30かなあ?5年以上まえのやつです)との比較。なお、ほとんどデザイン同じの現行機WS−50は以下。</p> <div class="freezed"> <div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B00V35HEIC/uxlayman-22/"><img class="hatena-asin-detail-image" title="Withings Bluetooth・Wi-Fi対応 体重計 Smart Body Analyzer WS-50 体脂肪/心拍数/室内環境分析 ホワイト 70046001【日本正規代理店品】" src="https://images-fe.ssl-images-amazon.com/images/I/31Mu7bSxI1L._SL160_.jpg" alt="Withings Bluetooth・Wi-Fi対応 体重計 Smart Body Analyzer WS-50 体脂肪/心拍数/室内環境分析 ホワイト 70046001【日本正規代理店品】" /></a> <div class="hatena-asin-detail-info"> <p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B00V35HEIC/uxlayman-22/">Withings Bluetooth・Wi-Fi対応 体重計 Smart Body Analyzer WS-50 体脂肪/心拍数/室内環境分析 ホワイト 70046001【日本正規代理店品】</a></p> <ul> <li><span class="hatena-asin-detail-label">出版社/メーカー:</span> Withings</li> <li><span class="hatena-asin-detail-label">発売日:</span> 2015/04/16</li> <li><span class="hatena-asin-detail-label">メディア:</span> エレクトロニクス</li> <li><a href="http://d.hatena.ne.jp/asin/B00V35HEIC/uxlayman-22" target="_blank">この商品を含むブログ (1件) を見る</a></li> </ul> </div> <div class="hatena-asin-detail-foot"> </div> </div> </div> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807123112j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807123112.jpg" alt="f:id:uxlayman:20160807123112j:plain" /></p> <p>並べてみた図。 現行機が327x327x23mm、Body Cardioが327x327x18mmだから、大きさは一緒なんですね。心持ち現行機が小さめな印象がありましたが、角のRの違いによる錯覚ですかね。</p> <p> </p> <p> </p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160807123303j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160807/20160807123303.jpg" alt="f:id:uxlayman:20160807123303j:plain" /></p> <p>横から見た図。上が現行機。これはかなり薄くなった感がある。「足」もなくなったし。あと、横がフラットになって自立するようになりました。元から薄かったからあんまり恩恵はありませんが。</p> <p> </p> <p> </p> <h3>感想</h3> <h5>その1</h5> <p>セットアップ簡単すぎる!!!やったことは電源入れて、アプリ起動して指示に従っただけ。すばらしいUXです!</p> <p>Activitéの時も思ったけど、このWithingsという会社はほんと「体験」をスマートに作り上げるのが上手くて好きです。ファンです。</p> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="Withings Activitéを1週間ほど使った感想など - UXエンジニアになりたい人のブログ" src="http://uxlayman.hatenablog.com/embed/2015/04/28/073100" frameborder="0" scrolling="no"></iframe><cite class="hatena-citation"> </cite></p> <h5>その2</h5> <p>心拍測定が入ったので、体重測定の時間が長くなりました。数秒なんで別に不都合はないですが。</p> <p>旧型機:5,6秒で体重が確定して終わり</p> <p>Body Cardio:5,6秒で体重確定した後、心拍が確定するまで乗り続ける(10-20秒)</p> <p> </p> <h5>その3 </h5> <p>これは旧型機から共通ですが、体重測定とアプリ連携に何の手間もないことが素晴らしい!普通に乗るだけで、いつのまにか連携される。これが大事!</p> <p>他社のモデルはよくわかりませんが、これはWi-Fiなので、スマホが手元にあろうがなかろうがBluetoothの設定がどうなっていようが関係なく連携されます。こういうのって地味に大事なんですよね。</p> <p> </p> <p> </p> <h4>保証の話</h4> <p>ちょっとだけ気になるのは保証の話。いや、実は保証書とかなにも入ってなかったんですよね。Apple Storeが一時窓口になると思いきや、</p> <blockquote> <p>保証およびサポート情報</p> <p>注意 : このサイトで販売されるApple製以外の製品については、製品に同梱された使用許諾条件に従って、それらの製品の製造メーカーのサービスおよびサポートが提供されます。尚、Apple製品と一緒にパッケージされ販売されるAppleブランド以外の製品においても弊社からの製品保証は一切行われません。テクニカルサポートやカスタマーサポートについては、製造メーカーへ直接ご連絡ください。</p> </blockquote> <p>とか書いてあるし。 </p> <p> </p> <p>公式には1年保証ってあるんでどうにか保証はされるんだろうけど最初どこに問い合わせるんだろうとちょっと迷う。日本Withingsかな?ハイテク製品は結構壊れやすいので保証考えると並行品はあんまりお勧めしないですね。</p> <p><iframe class="embed-card embed-webcard" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" title="Withings" src="//hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.withings.com%2Fus%2Fen%2Fstore%2Fdetails%2Fbody-cardio" frameborder="0" scrolling="no"></iframe></p> <p> </p> <p> </p> <p>セットアップは簡単だし、利用感は旧型機と変わらないので満足です。ま、体重測ってなにに使うわけでもないんですけどね。いまは時計も同じWithings社のActivitéなので健康関連をこの企業に牛耳られつつありますw</p> <div class="freezed"> <div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B01JZ0Q25C/uxlayman-22/"><img class="hatena-asin-detail-image" title="Withings スマート体重計 Body Cardio ホワイト Wi-Fi/Bluetooth対応【日本正規代理店品】" src="https://images-fe.ssl-images-amazon.com/images/I/31WJPgqe%2BLL._SL160_.jpg" alt="Withings スマート体重計 Body Cardio ホワイト Wi-Fi/Bluetooth対応【日本正規代理店品】" /></a> <div class="hatena-asin-detail-info"> <p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B01JZ0Q25C/uxlayman-22/">Withings スマート体重計 Body Cardio ホワイト Wi-Fi/Bluetooth対応【日本正規代理店品】</a></p> <ul> <li><span class="hatena-asin-detail-label">出版社/メーカー:</span> Withings</li> <li><span class="hatena-asin-detail-label">発売日:</span> 2016/09/02</li> <li><span class="hatena-asin-detail-label">メディア:</span> エレクトロニクス</li> <li><a href="http://d.hatena.ne.jp/asin/B01JZ0Q25C/uxlayman-22" target="_blank">この商品を含むブログを見る</a></li> </ul> </div> <div class="hatena-asin-detail-foot"> </div> </div> </div> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="Withings Activitéを1週間ほど使った感想など - UXエンジニアになりたい人のブログ" src="http://uxlayman.hatenablog.com/embed/2015/04/28/073100" frameborder="0" scrolling="no"></iframe><cite class="hatena-citation"> <br /></cite></p> uxlayman 【ポケモンGO】画面を見ずにポケモンをゲットする方法 hatenablog://entry/10328749687176695694 2016-07-30T11:33:19+09:00 2022-02-28T21:13:55+09:00 7/31のアップデートでできなくなったようです。 ボールが投げられずに消費した音だけ聞こえるか、投げられるけど先制攻撃っぽくない普通の軌道で投げるだけ、となってしまうようです。残念! ポケモンGO、やってますか。 このゲーム、モンスターボールの操作が割とシビアなので、ポケモンを捕まえるときはちゃんと立ち止まって画面を見ざるをえないと思っている人が大半でしょう*1。 が、実は画面を見ずにポケモンをゲットする方法が発見されたのでそれを紹介します。 *1:ていうか立ち止まらないで画面を凝視しながら歩くのやめれ <p><strong><span style="color: #ff0000;">7/31のアップデートでできなくなったようです。</span></strong></p> <p><strong><span style="color: #ff0000;">ボールが投げられずに消費した音だけ聞こえるか、投げられるけど先制攻撃っぽくない普通の軌道で投げるだけ、となってしまうようです。残念!</span></strong></p> <p> </p> <p>ポケモンGO、やってますか。</p> <p>このゲーム、モンスターボールの操作が割とシビアなので、ポケモンを捕まえるときはちゃんと立ち止まって画面を見ざるをえないと思っている人が大半でしょう<a href="#f-83cccd79" name="fn-83cccd79" title="ていうか立ち止まらないで画面を凝視しながら歩くのやめれ">*1</a>。</p> <p>が、実は画面を見ずにポケモンをゲットする方法が発見されたのでそれを紹介します。</p> <p> </p> <p> </p> <h3>やりかた</h3> <p>とても簡単で、捕獲モード最初のポケモンがドアップになっている状態で、画面の中心あたりを下から上にスワイプしまくるだけです。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160730111351p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160730/20160730111351.png" alt="f:id:uxlayman:20160730111351p:plain" /></p> <p> </p> <p>こうすると、立ち合い直後の、ポケモンが遠ざかった瞬間の的が大きいところにボールが投げられるのでほぼほぼ当たります。まあともかく動画をご覧ください。</p> <p><iframe src="https://www.youtube.com/embed/QdpCQuZ5Yfw?feature=oembed" width="480" height="270" frameborder="0" allowfullscreen=""></iframe></p> <p> </p> <p>ね。なんか先制攻撃っぽいですよね。</p> <p>この方法ならポケモンタップしたあとは画面を見なくてもOKです。音が聞けてるんであれば、ゲット出来たかできてないかも音で判断できます。とっても捗るね!</p> <p> </p> <h4>諸注意</h4> <ul> <li><span style="line-height: 1.5;">もちろんARモードはオフにしないとだめですw</span></li> <li><span style="line-height: 1.5;">ポケモンの弾き動作が発動するとボールが弾かれることがあります。体感では2〜3割位?この場合、フリックしまくってると短距離の投球を繰り返してモンスターボールが減りまくるので注意しましょうw</span></li> <li>一応iPadでも5インチAndroidでもできたので機種依存はないと思いますが、おっきい端末であればストローク量が必要になります</li> <li><span style="line-height: 1.5;">弾き案件が発生した場合は自分から退却すれば、もう一度立ち合いからやり直せる(自分から退却した場合はポケモンは消えない)ので、ズバッとみたいな捕らえづらいポケモンの場合はそれも検討すると良いかもしれません</span></li> </ul> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160730112426p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160730/20160730112426.png" alt="f:id:uxlayman:20160730112426p:plain" /></p> <p> </p> <p>それでは、安全で快適なポケモンライフをお楽しみください!</p><div class="footnote"> <p class="footnote"><a href="#fn-83cccd79" name="f-83cccd79" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">ていうか立ち止まらないで画面を凝視しながら歩くのやめれ</span></p> </div> uxlayman 【改良版】コピペで簡単!はてなブログで「文中にアドセンス広告を入れる」を自動化する方法 hatenablog://entry/10328749687176405420 2016-07-28T22:59:49+09:00 2022-02-28T21:13:53+09:00 2017/1/26追記 さらに楽をしたい方は以下の記事をご覧ください uxlayman.hatenablog.com uxlayman.hatenablog.com 上記記事は当ブログの密かな人気記事なのですが、どうも最近問題が発見されたようです。 http://www.toma-g.net/entry/kijinaka_yasuiwww.toma-g.net okanewofuyaso.hateblo.jp要は記事上下の広告を移動するスクリプト使う →(2重、もしくは多重カウントされて)アクティブビュー視認可能率が下がる →(みんなが見ない場所に貼られた広告だと判断されて)広告単価が下がると… <p><span style="color: #ff0000"><b>2017/1/26追記<br /> さらに楽をしたい方は以下の記事をご覧ください</b></span><br /> <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fuxlayman.hatenablog.com%2Fentry%2F2017%2F01%2F26%2Finsentenseform" title="【本当にコピペ一発!】はてなブログで「文中にアドセンス広告を入れる」を自動化する方法 - UXエンジニアになりたい人のブログ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://uxlayman.hatenablog.com/entry/2017/01/26/insentenseform">uxlayman.hatenablog.com</a></cite></p><br /> <br /> <br /> <p><hr/></p><p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fuxlayman.hatenablog.com%2Fentry%2F2014%2F09%2F23%2F092256" title="はてなブログで「文中にアドセンス広告を入れる」を自動化する方法 - UXエンジニアになりたい人のブログ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://uxlayman.hatenablog.com/entry/2014/09/23/092256">uxlayman.hatenablog.com</a></cite><br /> 上記記事は当ブログの密かな人気記事なのですが、どうも最近問題が発見されたようです。</p><br /> <br /> <p><a href="http://www.toma-g.net/entry/kijinaka_yasui">http://www.toma-g.net/entry/kijinaka_yasui</a><cite class="hatena-citation"><a href="http://www.toma-g.net/entry/kijinaka_yasui">www.toma-g.net</a></cite><br /> <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fokanewofuyaso.hateblo.jp%2Fentry%2F2015%2F12%2F18%2F015628" title="記事中のアドセンス挿入でアクティブビュー視認可能率が低下する? - お金をふやそう" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://okanewofuyaso.hateblo.jp/entry/2015/12/18/015628">okanewofuyaso.hateblo.jp</a></cite></p><p>要は</p><p>記事上下の広告を移動するスクリプト使う<br /> →(2重、もしくは多重カウントされて)アクティブビュー視認可能率が下がる<br /> →(みんなが見ない場所に貼られた広告だと判断されて)広告単価が下がる</p><p>という話であるようです。<br /> ということで改良版をつくりました。<br /> 今回も、コピペで簡単やで!(けど、ちょっとだけ注意点があるので気をつけてや!あと、いつでも元の状態に戻せるようにメモ帳にでもなんにでもバックアップはとっとっきましょう^^)</p><p> <br /> <br /> </p> <div class="section"> <h3>設定方法</h3> <p>ダッシュボード→デザイン→カスタマイズ→記事上下のカスタマイズ→「記事ページのプレビュー」を設定→「記事下」または「記事上」</p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3,h4,h5'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> / </span>2))<span class="synSpecial">.before</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre><p> </p> <div class="section"> <h5>諸注意など</h5> <ul> <li>超重要:上にも書きましたが、アドセンスコードをコピペしたあと、<span style="color: #ff0000">2箇所ある「/script」を「/scrip」に修正してください!</span>これをしないと広告そのものが表示されなかったり、画面がおかしなことになると思います。変えるのは2箇所だけで、4箇所ではないです。ちゃんと出来てない場合ははてなブログのダッシュボードで設定した時点で「緑色の領域」が下の画像のようになってないはずのなので、うまくいかない場合はまずこれを確認してください。</li> </ul><p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160728/20160728225540.png" alt="f:id:uxlayman:20160728225540p:plain" width="565" height="414" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><br /> </p> <ul> <li>本文中で大見出し、中見出し、小見出しの数を数えていって、真ん中に当たる部分の見出しの前に挿入します。</li> </ul><p> </p> <ul> <li>大見出し、中見出し、小見出しのどれもない場合は何もしません(そのまま記事下に表示される)</li> </ul><p> </p> <ul> <li>挿入対象は以下の3〜7行目の部分なので、アドセンスコードの周りのスタイル等適宜調整してください。上記例では、コードの上に「広告」という文字、下に空行を入れています。</li> </ul><pre class="code lang-html" data-lang="html" data-unlink> <span class="synIdentifier">&lt;</span><span class="synStatement">p</span><span class="synIdentifier">&gt;</span>広告<span class="synIdentifier">&lt;/</span><span class="synStatement">p</span><span class="synIdentifier">&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">p</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">p</span><span class="synIdentifier">&gt;</span> </pre><p> </p> <ul> <li>「もっと読む」の下に広告入れている例が多いようなのですが、はてなブログは「もっと読む」の位置がソース的に記載されていないようなのでできませんでした。</li> </ul><p> <br /> <br /> </p> </div> </div> <div class="section"> <h3>挿入位置のカスタマイズ</h3> <p>基本的には</p> <pre class="code lang-html" data-lang="html" data-unlink> var $target = $('.entry-content h3,h4,h5'); $target.eq(Math.floor($target.size() / 2)).before($('.insentense-adsense')); </pre><p>このコードがカスタマイズ位置を特定しているので、ここの部分を変えることになります。<br /> <br /> <br /> </p> <div class="section"> <h4>応用例1:「真ん中」の大見出しの直後に広告を入れる</h4> <p>対象を大見出し(h3)だけに絞り、「直後」を表すafterに変える</p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> / </span>2))<span class="synSpecial">.after</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre><p> </p> </div> <div class="section"> <h4>応用例2:最初の大見出しの直後に広告を入れる</h4> <p>応用例1に加え、追加対象見出しの条件を「最初」を表すeq(0)にする。eq(0)の部分をeq(1)とかeq(10)とかにすれば、「n番目の」という意味になる</p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(0)<span class="synSpecial">.after</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre> </div> <div class="section"> <h4>応用例3:2つのアドセンスコードを別の位置に入れる</h4> <p>ポイントはそれぞれのアドセンスコードの名前を変える(下記insentence-adsenseとinsentence-adsense2)ことと、変数名を変える(下記adsenseCodeとadsenseCode2)ことと、挿入位置を変える(「$target.eq(Math.floor($target.size() *1/ 3))」のところ)です。<br /> 下記例は、上から1/3にある見出しの上と、上から2/3にある見出しの上にコードを入れる例。<br /> 最初と最後であれば、$target.eq(0)と$target.eq($target.size()-1)でokです。</p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3,h4,h5'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> * </span>1<span class="synSpecial"> / </span>3))<span class="synSpecial">.before</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre><pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode2 = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコード(2つ目)の2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3,h4,h5'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> * </span>2<span class="synSpecial"> / </span>3))<span class="synSpecial">.before</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense2'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense2'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode2</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense2&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre> </div> <div class="section"> <h4>応用例4:フッターの先頭(ブログパーツの前)に入れる</h4> <p><span style="color: #ff0000">2016/8/6追記</span><br /> 通常、フッタに指定したアドセンスやその他ブログパーツは、はてなが提供するブログパーツの後ろになりますが、これを前(本文の直後)に持ってくるコードです。<br /> フッター部分はPC、スマホとも共通でentry-footerなので、ここの先頭にコードを入れる"prepend"を利用します。</p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCodeF = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のフッタ用アドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.entry-footer'</span>)<span class="synSpecial">.prepend</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.footer-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.footer-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCodeF</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;footer-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre> </div> <div class="section"> <h4>応用例5:場所が見つからなかったらともかく文中に入れる</h4> <p><span style="color: #ff0000">2016/8/6追記</span><br /> このコードは挿入場所が見つからなかったら、記事上または記事下にそのまま表示します。ただし、特にスマホの場合、フッタ用のアドセンスと文中用のアドセンスを両方「記事下」に設定して、文中用アドセンスが挿入できないと、アドセンスが2つ並ぶことになり、ポリシー違反になる可能性があります。<br /> これを防ぐため、「見つからなかったらともかく真ん中に」を実現するコードが以下です。$target.size() > 0が挿入場所が見つかったことをさします。</p><p>実行例は以下の記事などをご覧ください。この記事は見出しが1つもありませんが、レクタングル(大)がちょうど真ん中に挿入されています。<br /> <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fuxlayman.hatenablog.com%2Fentry%2F2014%2F09%2F25%2F223037" title="本日、PlayStation Vita+nasneの組み合わせは史上最高のごろ寝TVビューアーになりました!!! - UXエンジニアになりたい人のブログ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://uxlayman.hatenablog.com/entry/2014/09/25/223037">uxlayman.hatenablog.com</a></cite></p><p></p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3,h4'</span>)<span class="synSpecial">; </span><span class="synComment">// 大見出しと中見出し</span> <span class="synSpecial"> </span><span class="synStatement">if</span><span class="synSpecial"> </span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> &gt; </span>0)<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synComment">// 「真ん中」の大見出しと中見出しの直後に入れる</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> / </span>2))<span class="synSpecial">.after</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> </span><span class="synIdentifier">}</span><span class="synSpecial"> </span><span class="synStatement">else</span><span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synComment">// 大見出しと中見出しがなかったら、ともかく真ん中の段落に入れる</span> <span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content p, .entry-content div'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> / </span>2))<span class="synSpecial">.before</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> </span><span class="synIdentifier">}</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre> </div> <div class="section"> <h4>応用例6:特定のカテゴリーが付与されている記事だけ、Adsenseを貼り付けないようにする</h4> <p><span style="color: #ff0000">2017/1/21追記</span></p><p>Adsenseは成人向けコンテンツなどを含むページに貼り付けると規約違反になってしまうので、そういうページにだけカテゴリーをつけておいて、広告そのものを表示しないようにするコードです。</p> <pre class="code lang-html" data-lang="html" data-unlink><span class="synIdentifier">&lt;</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">var</span><span class="synSpecial"> adsenseCode = </span>(<span class="synIdentifier">function</span><span class="synSpecial"> </span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span><span class="synComment">/*</span> <span class="synComment">&lt;p&gt;広告&lt;/p&gt;</span> <span class="synComment">&lt;!-- 自分のアドセンスコードの2箇所の「/script」を「/scrip」に修正してここにコピペ --&gt;</span> <span class="synComment">&lt;p&gt; &lt;/p&gt;</span> <span class="synComment">*/</span><span class="synIdentifier">}</span>)<span class="synSpecial">.toString</span>()<span class="synSpecial">.match</span>(<span class="synConstant">/\/\*([^]*)\*\//</span>)<span class="synIdentifier">[</span>1<span class="synIdentifier">]</span><span class="synSpecial">.replace</span>(<span class="synConstant">/scrip&gt;/g</span><span class="synSpecial">, </span><span class="synConstant">'script&gt;'</span>)<span class="synSpecial">;</span> <span class="synSpecial">addEventListener</span>(<span class="synConstant">&quot;DOMContentLoaded&quot;</span><span class="synSpecial">, </span><span class="synIdentifier">function</span>()<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synStatement">if</span><span class="synSpecial"> </span>(<span class="synSpecial">$</span>(<span class="synConstant">'meta[property=&quot;article:tag&quot;][content=&quot;広告禁止&quot;]'</span>)<span class="synSpecial">.size</span>()<span class="synSpecial"> &gt; </span>0)<span class="synSpecial"> </span><span class="synIdentifier">{</span> <span class="synSpecial"> </span><span class="synStatement">return</span><span class="synSpecial">;</span> <span class="synSpecial"> </span><span class="synIdentifier">}</span> <span class="synSpecial"> </span><span class="synIdentifier">var</span><span class="synSpecial"> $target = $</span>(<span class="synConstant">'.entry-content h3,h4,h5'</span>)<span class="synSpecial">;</span> <span class="synSpecial"> $target.eq</span>(<span class="synSpecial">Math.floor</span>(<span class="synSpecial">$target.size</span>()<span class="synSpecial"> / </span>2))<span class="synSpecial">.before</span>(<span class="synSpecial">$</span>(<span class="synConstant">'.insentense-adsense'</span>))<span class="synSpecial">;</span> <span class="synSpecial"> $</span>(<span class="synConstant">'.insentense-adsense'</span>)<span class="synSpecial">.html</span>(<span class="synSpecial">adsenseCode</span>)<span class="synSpecial">;</span> <span class="synIdentifier">}</span><span class="synSpecial">, </span><span class="synConstant">false</span>)<span class="synSpecial">;</span> <span class="synIdentifier">&lt;/</span><span class="synStatement">script</span><span class="synIdentifier">&gt;</span> <span class="synIdentifier">&lt;</span><span class="synStatement">div</span><span class="synIdentifier"> </span><span class="synType">class</span><span class="synIdentifier">=</span><span class="synConstant">&quot;insentense-adsense&quot;</span><span class="synIdentifier">&gt;&lt;/</span><span class="synStatement">div</span><span class="synIdentifier">&gt;</span> </pre><p></p><p>追加されたのは</p> <pre class="code lang-html" data-lang="html" data-unlink> if ($('meta[property=&quot;article:tag&quot;][content=&quot;広告禁止&quot;]').size() <span class="synError">&gt;</span> 0) { return; } </pre><p>のところだけで、これが「『広告禁止』というタグがついていたら、なにも処理をしない」という意味になります。<br /> これを冒頭に追加しさえすれば、挿入位置のカスタマイズやその他応用例と併存させることもできます。<br /> <br /> </p> </div> </div> <div class="section"> <h3>技術的なお話</h3> <p>基本的にはadsenseコードをjavascriptの文字列として持っておいて、文中に直接書き出す、という流れになります。前回のコードと違い、移動させていないので、多重カウントされません。</p><br /> <p>コピペを簡単にするための仕掛けとして、以下のjavascript版ヒアドキュメントの仕組みを使っています。<br /> <iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fqiita.com%2Fampersand%2Fitems%2Fc6c773ba7ae9115856d0" title="SafariでもエラーにならないJavascriptのヒアドキュメントの書き方 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://qiita.com/ampersand/items/c6c773ba7ae9115856d0">qiita.com</a></cite></p><br /> <p>これがないと延々アドセンスコードのタグをjsの文字列に書きなおさなければならなくなります。<br /> ただ、これを使ってもなお、&lt;/script&gt;がスクリプトの終わりだとブラウザに判定されてしまうため、苦肉の策で&lt;/scrip&gt;に置換するようにしています。<br /> <br /> <br /> </p> </div> <div class="section"> <h3>おわりに</h3> <p>さて、大事なことですが、本スクリプトは自己責任でご利用ください。<br /> スクリプトが突然動作しなくなったり、今回のように単価減の状態になったり、またポリシー違反状態になった場合等も、当ブログならびにブログ主は責任を負いません。</p><p>一応、ポリシーに違反したという話は聞きませんし、Adsenseコードをほとんどそのまま利用(ただscriptをscripに変換してるので、厳密にいえば改変は改変なのですが…)しているので、あまり問題にはならないかと思います。javascriptコメントを利用する方法は別記事「<a href="http://uxlayman.hatenablog.com/entry/2015/01/17/202404">&#x306F;&#x3066;&#x306A;&#x30D6;&#x30ED;&#x30B0;&#x3067;&#x7279;&#x5B9A;&#x306E;&#x30AD;&#x30FC;&#x30EF;&#x30FC;&#x30C9;&#x3092;&#x542B;&#x3080;&#x8A18;&#x4E8B;&#x306B;&#x306F;Adsense&#x304C;&#x8CBC;&#x3089;&#x308C;&#x306A;&#x3044;&#x3088;&#x3046;&#x306B;&#x3059;&#x308B;&#x65B9;&#x6CD5; - UX&#x30A8;&#x30F3;&#x30B8;&#x30CB;&#x30A2;&#x306B;&#x306A;&#x308A;&#x305F;&#x3044;&#x4EBA;&#x306E;&#x30D6;&#x30ED;&#x30B0;</a>」で紹介して、実際に運用されている方もいるようなので、ある程度枯れてきているとは思います。</p><p>とはいえ今回の話もありましたので、とりあえずしばらくは自分でも運用してみようと思います(機会損失してしまった方々ごめんなさい)<a href="#f-ce2adb2e" name="fn-ce2adb2e" title="自分で運用してればすぐ気づいて改良版を出せたんですけどね">*1</a><br /> この記事にも、真ん中の大見出しの直後にレクダングル大が表示されてると思いますので、見た目を確認してみてくださいませ。<br /> 問題があった場合はコメントなり引用なりをしていただければ幸いです。</p> </div><div class="footnote"> <p class="footnote"><a href="#fn-ce2adb2e" name="f-ce2adb2e" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">自分で運用してればすぐ気づいて改良版を出せたんですけどね</span></p> </div> uxlayman 「支持政党なし」が犯した2つの戦略ミス hatenablog://entry/6653812171404860602 2016-07-10T22:19:51+09:00 2022-02-28T21:13:54+09:00 支持政党なし、結局議席取れるんですかね。比例票は特に遅くまで確定しないので、なかなか大変かと思います。 ともあれ、今回の選挙で支持政党なし党は大きな戦略ミスを犯したと思っているので、それについて書いていきます。 非拘束名簿式比例代表に立候補した まあ、これやね。 via 支持政党なし このバナー見てちょっと勘違いしちゃったんだけど。 予言。参院選で支持政党なしは議席を獲得する。そんで、そのあと死ぬほど揉める— りんご4個分 (@uxlayman) 2016年7月4日 こんな事言ったけども、これ言った時は投票用紙のところが だと思ってたんですね。これは行けるだろ、と。普通に「新しい"公的な棄権"… <p>支持政党なし、結局議席取れるんですかね。比例票は特に遅くまで確定しないので、なかなか大変かと思います。</p> <p>ともあれ、今回の選挙で支持政党なし党は大きな戦略ミスを犯したと思っているので、それについて書いていきます。</p> <h3> </h3> <h3>非拘束名簿式比例代表に立候補した</h3> <p>まあ、これやね。</p> <blockquote> <p><a class="http-image" href="http://xn--68jubz91pp0oypc1c.com/top/menu-1s.jpg" target="_blank"><img class="http-image" src="http://xn--68jubz91pp0oypc1c.com/top/menu-1s.jpg" alt="http://xn--68jubz91pp0oypc1c.com/top/menu-1s.jpg" /></a></p> <p class="photo-caption">via <a href="http://xn--68jubz91pp0oypc1c.com/">支持政党なし</a></p> </blockquote> <p>このバナー見てちょっと勘違いしちゃったんだけど。 </p> <p> </p> <p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">予言。参院選で支持政党なしは議席を獲得する。そんで、そのあと死ぬほど揉める</p>&mdash; りんご4個分 (@uxlayman) <a href="https://twitter.com/uxlayman/status/749959303260364805?ref_src=twsrc%5Etfw">2016年7月4日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p>こんな事言ったけども、これ言った時は投票用紙のところが</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160710203936p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160710/20160710203936.png" alt="f:id:uxlayman:20160710203936p:plain" /></p> <p>だと思ってたんですね。これは行けるだろ、と。普通に「新しい"公的な棄権"的な選択肢」ができたと勘違いするひと出てくるだろ、と。</p> <p> </p> <p>で、実際に選挙いって、投票用紙のところ見たら</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160710203948p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160710/20160710203948.png" alt="f:id:uxlayman:20160710203948p:plain" /></p> <p>こうなってた。</p> <p> </p> <p>オワタ\(^o^)/</p> <p> </p> <p>まあ参議院比例代表は非拘束名簿(政党名でも候補者個人名どちらを書いても良い)だから、こうなるのは最初からわかってたとは思うんですが、でもこう書いてあったら、よっぽど勘が悪くない限り「支持政党なし」が「棄権の別名」ではなくて、政党の名前だってわかっちゃうよね。</p> <p> </p> <p>当人たちはもちろん否定するだろうけど、この政党が「勘違い票」も狙ってることは明らかで、その戦略は非拘束名簿方式と相性がとても悪い。</p> <p> </p> <p> </p> <h3>東京選挙区に4人立候補</h3> <p>比例代表が分が悪いことは(わたしは勘違いしてたが)当人たちははじめからわかっていただろう。一方で、この政党の理念そのものを支持するという人も少なからず存在する。かくいうわたしも支持者とまでは行かないが、そこまで嫌いでもない。</p> <p><iframe class="embed-card embed-blogcard" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" title="私は「支持政党なし」党に投票します - 分裂勘違い君劇場の別館" src="http://fromdusktildawn.hatenablog.com/embed/2016/07/09/145106" frameborder="0" scrolling="no"></iframe><cite class="hatena-citation"><br /></cite></p> <p>そういう人たちにとっては比例、選挙区ともに「支持政党なし」に投票したいところではある。</p> <blockquote> <p><a class="http-image" href="http://swinginthinkin.com/wp-content/uploads/160627_saninsen_senkyo_poster_2016_shijiseitounashi-700x700.jpg" target="_blank"><img class="http-image" src="http://swinginthinkin.com/wp-content/uploads/160627_saninsen_senkyo_poster_2016_shijiseitounashi-700x700.jpg" alt="http://swinginthinkin.com/wp-content/uploads/160627_saninsen_senkyo_poster_2016_shijiseitounashi-700x700.jpg" /></a></p> <p class="photo-caption">via <a href="http://swinginthinkin.com/column/shiji-nashi-poster-senkyo-2016/">支持政党なし、選挙ポスターのデザインがひどい! 伝え方が悪すぎて理解ができず、猛暑の中イライラする…… | SwinginThinkin</a></p> </blockquote> <p> </p> <p>そもそも、この政党は議員個人は単なる使者なので、個人名に全く意味が無い。だから、選挙ポスターに候補者名がないことも納得できる。支持者は「誰でもいいから支持なし党に」というモチベーションで投票に行く。</p> <p> </p> <p>がしかし、実際には東京には候補者が4人もいて、誰に入れていいのかわからない状態になってしまう。公式サイトの「<a href="http://xn--68jubz91pp0oypc1c.com/election.html">選挙情報</a>」ページにも、候補者は誰が最優先なのかの情報がない。地区ごとに候補者が分散しているが、まさか地区ごとに支持者の票を分散させて4人全員当選するつもりだったわけでもあるまい<a href="#f-b22ab118" name="fn-b22ab118" title="ちなみに選挙区で党名書いたらどうなるの?ぐぐってみたところ無効票という説が濃厚だけど">*1</a>。</p> <p> </p> <p>このような政策を掲げる以上、当然選挙区ごとに候補者は1人にすべきだし、擁立は当選人数が複数人の「棚ぼたが狙えそうな」選挙区に送るべきである。東京なんかははじめから6議席のうち4議席がほぼ確定で、残り2議席は混戦というまさに“ワンチャン狙える”選挙区であったのに、自らそのチャンスを潰したように見える。</p> <p> </p> <p> </p> <p>この政党については、よく「本気で政治をやる気があるのか、それとも道楽とかパフォーマンスの類のものなのか」という話が議論に上がる。</p> <p>選挙ハックがしたいならせっかくの素敵な党名を活かすべく、非拘束名簿方式は避けるべきだし、本気で理念を実現したいのであれば、選挙区重複立候補のような凡ミスを犯すべきではない。</p> <p>今回の選挙戦ではそういう単純な戦略をミスってるように見えて、その結果「道楽でなにも考えずにやってるうさんくさいやつ」という印象を与えてしまったのが最大の戦略ミスであるのではないかと思う。</p> <p> </p><div class="footnote"> <p class="footnote"><a href="#fn-b22ab118" name="f-b22ab118" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">ちなみに選挙区で党名書いたらどうなるの?ぐぐってみたところ無効票という説が濃厚だけど</span></p> </div> uxlayman iPhoneは4Sまでは裸で使いやすかった hatenablog://entry/6653812171402796733 2016-06-27T21:00:00+09:00 2022-02-28T21:13:54+09:00 スティーブ・ジョブズがiPodやiPadにケースをつけることに否定的だったことはよく知られている。「傷がついたステンレスは美しい」という名言もあり、ケースを付けずに「裸」で使うべきという考えを持っていたことは明らかだろう。 そして、こちらは俗説ではあるが、iPhone 4Sの"4S"は、開発当時闘病中で4S発売の翌日に亡くなったスティーブ・ジョブズに向けた"for Steve"の略であるとの話もある。これを持ってして、真にジョブズが手がけたiPhoneは4Sまでで、それ以降は別であるという論調も根強い。 だからというわけではないのでだが、iPhoneは4Sまでは裸で使いやすくて、5以降急激に裸… <p>スティーブ・ジョブズがiPodやiPadにケースをつけることに否定的だったことはよく知られている。「傷がついたステンレスは美しい」という名言もあり、ケースを付けずに「裸」で使うべきという考えを持っていたことは明らかだろう。</p> <p>そして、こちらは俗説ではあるが、iPhone 4Sの"4S"は、開発当時闘病中で4S発売の翌日に亡くなったスティーブ・ジョブズに向けた"for Steve"の略であるとの話もある。これを持ってして、真にジョブズが手がけたiPhoneは4Sまでで、それ以降は別であるという論調も根強い。</p> <p> </p> <p>だからというわけではないのでだが、iPhoneは4Sまでは裸で使いやすくて、5以降急激に裸で使いにくくなったという話をしたい。</p> <p>ちなみに、3・3GS・4S・5s・SEのユーザーです。</p> <p> </p> <p> </p> <h3>4S以前(iPhone3G・3GS・4・4S)</h3> <p>初代iPhoneは日本で発売しなかったのでよく知らん。</p> <p>3Gと3GSは前面がゴリラガラス、背面がプラスチックで、前面を囲む鏡面のフレームが印象的なデザインだった。背面はプラスチックなので傷そのものが目立たず、裸で使いやすい端末だったと思う。</p> <p><a title="3GS by A_minor, on Flickr" href="https://www.flickr.com/photos/fotogiraffee/3641652893/" data-flickr-embed="true"><img src="https://farm4.staticflickr.com/3364/3641652893_0ec3b98907_z.jpg?zz=1" alt="3GS" width="480" /></a></p> <p class="photo-caption">via flickr by <a href="https://www.flickr.com/photos/fotogiraffee">yung</a></p> <p> <script src="https://embedr.flickr.com/assets/client-code.js" async="" charset="utf-8"></script> </p> <p><a title="iPhone 3GS by fabianpimminger, on Flickr" href="https://www.flickr.com/photos/fabs_pim/3757985439/" data-flickr-embed="true"><img src="https://farm3.staticflickr.com/2434/3757985439_ed0f3931dc_b.jpg" alt="iPhone 3GS" width="1024" /></a></p> <p class="photo-caption">via flickr by <a href="https://www.flickr.com/photos/fabs_pim">fabianpimminger</a> </p> <p> </p> <p>iPhone4になって表面と裏面のガラスに囲まれたステンレスフレーム、という構造にデザインがリニューアルされたが、背面はガラスであるので傷そのものが目立たず、側面も傷がつきにくく、(自分は傷つかなかったのでわからないが)ついても目立ちにくい素材だったと思う。</p> <p><a title="iPhone4 by Cooky Yoon, on Flickr" href="https://www.flickr.com/photos/designrecipe/5534275270/" data-flickr-embed="true"><img src="https://farm6.staticflickr.com/5095/5534275270_447632144f_z.jpg" alt="iPhone4" width="550" /></a></p> <p class="photo-caption">via flickr by <a href="https://www.flickr.com/photos/designrecipe">vji young Yoon</a></p> <p> </p> <h3>iPhone5以降</h3> <p>転換点となったのはiPhone5だろう。4・4Sと同様のデザインイメージを踏襲しているが、背面がガラスとアルミのコンビネーションとなり、<strong>側面に塗装</strong>が施されるようになった。</p> <p>ブラック&スレートという色はまさにモノリスを思わせるかっこよさだったが、同時に塗装した側面や背面が傷つきやすく、また傷ついた場合は地肌が見えることによって醜さが目立ち、「裸派」がケースを付けるきっかけになったように思う。</p> <p><a title="iPhone 5 Black &amp; Slate 64GB by Yutaka Tsutano, on Flickr" href="https://www.flickr.com/photos/ivyfield/8038564164/" data-flickr-embed="true"><img src="https://farm9.staticflickr.com/8454/8038564164_1997d60ebb_b.jpg" alt="iPhone 5 Black &amp; Slate 64GB" width="1024" /></a> <script src="https://embedr.flickr.com/assets/client-code.js" async="" charset="utf-8"></script> </p> <p class="photo-caption">via Flickr by <a href="https://www.flickr.com/photos/ivyfield">Yutaka Tsutano</a></p> <p> </p> <p><a class="http-image" href="http://image.itmedia.co.jp/mobile/articles/1406/11/l_os_oldiphone5_01.jpg" target="_blank"><img class="http-image" src="http://image.itmedia.co.jp/mobile/articles/1406/11/l_os_oldiphone5_01.jpg" alt="http://image.itmedia.co.jp/mobile/articles/1406/11/l_os_oldiphone5_01.jpg" /></a></p> <p class="photo-caption">iPhone5の塗装剥げ via <a href="http://www.itmedia.co.jp/mobile/spv/1406/11/news056.html">そう、AppleCare+ならね:続・1年半落ちの「iPhone 5」が(ほぼ)新品になっちゃったぜ!! - ITmedia Mobile</a></p> <p> </p> <p>これに懲りたのか、 5sになってブラック&スレートは廃止され、黒系の色はスペースグレイという"ボケた"色になってしまった。</p> <p><a title="iPhone 5S by Janitors, on Flickr" href="https://www.flickr.com/photos/janitors/10575776124/" data-flickr-embed="true"><img src="https://farm4.staticflickr.com/3775/10575776124_d288635e0a_b.jpg" alt="iPhone 5S" width="1024" /></a> <script src="https://embedr.flickr.com/assets/client-code.js" async="" charset="utf-8"></script> </p> <p class="photo-caption"> via Flickr by <a href="https://www.flickr.com/photos/janitors">Kārlis Dambrāns</a></p> <p> </p> <p>そしてiPhone6系。</p> <p>前面は曲面ガラスによる美しさや高級感を追求したにもかかわらず、背面はあの醜いDライン。側面背面の全てに傷が目立ちやすいアルミを塗装を採用し、背面カメラもでっぱったことによりケース無しにはフラットな面に安定して置けないという状態になってしまった。もはや「どうせケースつけるんだから注力すべきは前面だけ」という姿勢を隠さなくなったように見え、「裸派」のことは忘れ去ってしまったように思える。</p> <p><a class="http-image" href="https://wayohoo.net/images/2015/20151230131350.jpg" target="_blank"><img class="http-image" src="https://wayohoo.net/images/2015/20151230131350.jpg" alt="https://wayohoo.net/images/2015/20151230131350.jpg" /></a></p> <p class="photo-caption">Dライン via <a href="https://wayohoo.com/ios/news/iphone-7-is-d-line-is-eliminated.html">iPhone 7はDラインがなくなる!?</a></p> <p> </p> <p>6系は買ってないが、自分で使った端末を見てみてもその印象を強くする。</p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160626193331j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160626/20160626193331.jpg" alt="f:id:uxlayman:20160626193331j:plain" /></p> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160626193438j:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160626/20160626193438.jpg" alt="f:id:uxlayman:20160626193438j:plain" /></p> <p>上から2年使ったiPhone4S・2年使ったiPhone5s・2ヶ月使ったiPhone SE。iPhone5sの上部分は落としたことによる傷であるので除外するにしても、4Sは5sに比べてとても傷つきづらい。というか傷一つないようにさえ見える。対して、5sは細かい傷が無数についてしまう。</p> <p> </p> <p>ということで、Appleさんにはぜひ「裸派」のことを、ケースのことを嫌いだったスティーブのことを思い出して、裸での使いやすさ(特に耐久性)のことを考えて欲しいと思います。</p> <p>それに、iPhoneは仕上げの良さは未だにダントツだと思うので手抜きをしないでまじめにやってほしいなあと思います。</p> <p>よろしくおねがいします!</p> <p> <script src="https://embedr.flickr.com/assets/client-code.js" async="" charset="utf-8"></script> </p> uxlayman 書籍「キャズム」が想像より遥かに良い内容だった件 hatenablog://entry/6653812171400397856 2016-06-10T07:15:00+09:00 2022-02-28T21:13:55+09:00 キャズム。本を読むまでもなく、わりと一般的な用語になっており、ご存知の方も多いのではないかと思います。 via 情報システム用語事典:キャズム(きゃずむ) - ITmedia エンタープライズ 多くのひとが思い浮かべるのが上の図でしょう。 顧客層をイノベーター・アーリーアダプター・アーリーマジョリティ・レイトマジョリティ・ラガードに分けた時の比率と、アーリーアダプターに受け入れられてからアーリーマジョリティに受け入れられるまでにあるギャップのことだよね。キャズムって溝って意味で、そこを渡るのが大変っていう比喩なんだよね。 うん、たしかにこういう区分けって実体験からしても納得できるし、多数派にア… <p><a class="asin" href="http://d.hatena.ne.jp/asin/4798137790/uxlayman-22"><img class="asin" title="キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論" src="https://images-fe.ssl-images-amazon.com/images/I/51WpZ49xHJL.jpg" alt="キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論" /></a></p> <p>キャズム。本を読むまでもなく、わりと一般的な用語になっており、ご存知の方も多いのではないかと思います。</p> <p> </p> <p><a class="http-image" href="http://image.itmedia.co.jp/im/articles/0706/01/chasm.gif" target="_blank"><img class="http-image" src="http://image.itmedia.co.jp/im/articles/0706/01/chasm.gif" alt="http://image.itmedia.co.jp/im/articles/0706/01/chasm.gif" /></a></p> <p class="photo-caption">via <a href="http://www.itmedia.co.jp/im/articles/0706/01/news142.html">情報システム用語事典:キャズム(きゃずむ) - ITmedia エンタープライズ</a></p> <p>多くのひとが思い浮かべるのが上の図でしょう。</p> <p>顧客層をイノベーター・アーリーアダプター・アーリーマジョリティ・レイトマジョリティ・ラガードに分けた時の比率と、アーリーアダプターに受け入れられてからアーリーマジョリティに受け入れられるまでにあるギャップのことだよね。キャズムって溝って意味で、そこを渡るのが大変っていう比喩なんだよね。</p> <p>うん、たしかにこういう区分けって実体験からしても納得できるし、多数派にアピールするためにはマスに向けたマーケティングとか、戦略を転換する必要があるのもイメージつきやすいな。わかりやすいセグメントだね。</p> <p>と、こんな感じでしょうか。わたしもそんな感じの認識でした。<strong>こういう認識だった人は、この本、読んだほうがいいです。そういう話じゃないんです。</strong></p> <p> </p> <h3>キャズムを体現する本当の図</h3> <p><img class="hatena-fotolife" title="f:id:uxlayman:20160610004525p:plain" src="https://cdn-ak.f.st-hatena.com/images/fotolife/u/uxlayman/20160610/20160610004525.png" alt="f:id:uxlayman:20160610004525p:plain" /></p> <p>キャズムを体現しているのは上の4元図であると思っています。</p> <p>縦軸は成熟度を表しています。横軸は2つのカテゴリを表していて、左半分が製品で、右半分が市場です。</p> <p>ここで成熟度が下から上に洗練される様は一般的な「よくある話」であり、かなりイメージしやすいでしょう。</p> <p> </p> <p>左半分の「製品」カテゴリにおける成熟は、イノベーターに技術をアピールしていたような状態、つまり"今までにない"ことはわかるけどなにに使えるのかはっきりしない(今でいうとブロックチェーン技術とかそういうのですかね)そういう状態から、特定分野におけるユースケースが見つかって、「製品」としてのパッケージングが成熟していく過程です。</p> <p>ブロックチェーンで言うなら、独自の技術を持つベンダーが、例えばオークションとかコンテンツプロバイダーのようなオンライン事業者の目に止まって、彼らビジョナリー(アーリーアダプター)の厳しい実務要求に応えることによって、"個人間商取引向けパッケージ"が成熟していって、次々と同業他社に採用される事実上のデファクトスタンダード製品になる、というような状態がゴールですね。</p> <p> </p> <p>右半分の「市場」でも同様で、またブロックチェーンで例えると、取引手数料の安さを武器に企業間電子商取引市場に参入した企業が、実利主義者(アーリーアダプター)の支持を得て徐々に市場における信頼を獲得し、ブランドを武器にして保守層(レイトマジョリティ)の利益を獲得する、市場に深く浸透した状態がゴールです。</p> <p> </p> <p>そして、特定分野で圧倒的な機能性をもった「製品」が、巨大な「市場」に参入して地位を獲得するまでの、深い深い溝がキャズムであるわけです。</p> <p>え?何いってんの?特定市場で成功した素晴らしい製品を足がかりに巨大市場で地盤を作るんでしょ?「個人間商取引を変えた革新的技術を基にした全く新しい商取引パッケージ」みたいな売り文句で。普通の連続的な変化じゃない?と思いました?</p> <p>いやもう、二回目ですが<strong>そう思ってる人こそ、ほんと読んだほうがいいと思います</strong>。</p> <p> </p> <p> </p> <h3>キャズムの正体 </h3> <p>一言で言えば、4元図で左と右に分けて書いた「製品」を求める層と、「市場」を求める層は求めるものややりたいことが全く別なのです。</p> <p>技術を元にした「製品」を求める層の目的は 「革新」で、「市場」での受け入れ度合いを求める層の目的は「改善」なのです。</p> <p> </p> <p>ビジョナリーの目的は、新しい成長領域を作ること。もしくは、変化の速い業界で常に生き残る術を模索すること。実利主義者の目的は成熟した領域で「うまくやっていく」こと。</p> <p>圧倒的な成功を求めるビジョナリーに対して、リスクを嫌い「程々の改善」を求める実利主義者。ビジョナリーが今までにないやり方で前期の10倍の利益を求めるのに対して、実利主義者が求めるのは年10%くらいの改善が5年続くこと。</p> <p>ブロックチェーンの例でも、製品を求めていたのは参入障壁が低く競争が激しいオンライン事業者なのに対し、電子商取引領域は多かれ少なかれどの企業も関係しているが本業からは外れた付随事業の"市場"ですね。</p> <p> </p> <p>実利主義者は対象の業務領域が確立していて、メジャーな企業がすでに実務に使っていた実績があって、単純な機能であっても改善効果が明確で、ポシャるリスクが少ないことを望み、機能とか性能とかよりサポートとか補償とかそういうのを求めている人たちです。</p> <p>その人たちに、「特定の分野で成功を収めた、かゆいところにも手が届く高機能で応用が効くが、使い手に知恵と工夫とカスタマイズを求める新世代の製品」なんていう売り文句は全く響かないどころかマイナスでしかないのです。</p> <p>だから、キャズムを越えるのなら、そういう人達に向けて「安心感のある製品」に変えていかなければならないのです。</p> <p> </p> <p> </p> <p>しかし、実際これはかなり難しいことでしょう。</p> <p>ベンダーは技術をベースに成長してきて、その技術力と製品力をベースにライバルを圧倒し、一分野のデファクトスタンダードにまでのし上がった成功体験を持つのです。「技術を起点にお客様要求に応えて製品を発展させる」が社是となっているようなベンダーが、もっと平凡でシンプルな機能に傾倒させ、周辺技術やらサポートやらに力を入れて、顧客の安心感のためにライバルと抜きつ抜かれつの程よい市場を作ろうなんて発想になるのはかなり難しいだろうと。</p> <p>虚業ではなく、実際に過去に輝かしい実績があるからこそなおさら。「製品」から「市場」へ<strong>基準をシフトすると同時に、ずっと突き詰めてきた成熟度を「戻す」ことをしなければならない</strong>。この難しさがキャズムに落ち込む企業が続出する理由なのです。</p> <p> </p> <h4>キャズムを越えたあと</h4> <p>そして、さらに興味深いのは書籍の終章でも触れられている"運良くキャズムを越えたあとの社内の様相"です。</p> <p>黎明期からの技術者は、技術を基に素晴らしい製品を作り上げて社の礎を築いたという自負があるでしょう。営業だって、ビジョナリーの厳しい要求に応えつつ二人三脚で素晴らしい成果を上げた経験を誇りに思っているのでしょう。</p> <p>それがキャズムを越えたとたん、技術者は機能拡張や新技術導入よりサポートや漸進的改善等の作業に追われることになり、営業は機能をフル活用して成果をあげることに協力的な「意識高い」客の相手から、不都合が起きたらどう補償するんだとか自分の仕事をもっと楽にさせろとかが第一優先事項の「くだらない」客を相手にしなければならなくなります。</p> <p> </p> <p>仕事の内容が変わることで、やりがいもかなり変わるでしょう。</p> <p>さらに世間からはつまらない会社になったとの批評を受け、そして成長期にジョインした(黎明期からの社員から見れば)つまらない意識低い系の凡百の社員に囲まれることにもなります。</p> <p> </p> <p>一方、成長期にジョインした社員から見れば、くだらなかろうがつまらなかろうがより多くの利益を支えている自分たちを蔑ろにする黎明期社員への反発が生み出されることでしょう。</p> <p>理屈から言えばこの対立は避けられない事態であり、せっかくキャズムを越えても社内がガタガタになることは避けられないのではないでしょうか。</p> <p> </p> <h3>まとめ</h3> <p>結局キャズムの話というのはマーケティングの話ではなくて、企業経営の話なんです。</p> <p>特に、ベンチャー企業なんかはキャズムの縁まで到達したタイミングが、重要な分水嶺になるんだろうと思います。</p> <p>つまり、もっとうまく市場に迎合できる人たちに会社を売っぱらうか、それともIPOして大量に資金を調達して大量に人々を雇い入れて「つまらない」けれども立派で持続的な会社を目指すかの。</p> <p>そういう意味では起業家をめざすひとにも良書かと思います。</p> <p> </p> <p>わたしは技術者なので、技術が「連続的に」人々に受け入れられるストーリーを漠然と信じていたのですが、この本は事例を交えて一つ一つその「誤解」を解いていってくれました。事例はアメリカのものでありますが、3Dプリンタやクラウドなど昨今の流行りにあわせてアップデートされており、BtoBビジネスに造詣がないわたしでも、よくわからない記述は少なかったように思います。</p> <p>そんなわけで、とても思慮深い本なのでおすすめですというお話でした。</p> <p> </p> <h4>おさらい </h4> <p>そしてここで最初の図をもう一度見てみましょう。 </p> <p><a class="http-image" style="color: #8bc8e1;" href="http://image.itmedia.co.jp/im/articles/0706/01/chasm.gif" target="_blank"><img class="http-image" style="border: 0px; max-width: 100%;" src="http://image.itmedia.co.jp/im/articles/0706/01/chasm.gif" alt="http://image.itmedia.co.jp/im/articles/0706/01/chasm.gif" /></a></p> <p class="photo-caption">via <a style="color: #8bc8e1;" href="http://www.itmedia.co.jp/im/articles/0706/01/news142.html">情報システム用語事典:キャズム(きゃずむ) - ITmedia エンタープライズ</a></p> <p>これはつまり、キャズムの左と右で大きさが違うのは、世の中は(少なくともビジネスの分野においては)リスクをかけた「革新」より「安定」を求める人が圧倒的に多いという世の中の常識を表しているように見えます。</p> <p>キャズムとはそんな世の中の「まあ現状維持でいいや」という思いと、「よりよい技術でもっとずっと世の中を良くしたい」という技術者の思いとのギャップを示しているようにみえるのではないでしょうか。</p> <p> </p> <div class="booklink-box" style="text-align: left; padding-bottom: 20px; font-size: small; /zoom: 1; overflow: hidden;"> <div class="booklink-image" style="float: left; margin: 0 15px 10px 0;"><a href="http://www.amazon.co.jp/exec/obidos/asin/4798137790/uxlayman-22/" target="_blank"><img style="border: none;" src="https://images-fe.ssl-images-amazon.com/images/I/51WpZ49xHJL._SL320_.jpg" alt="" /></a></div> <div class="booklink-info" style="line-height: 120%; /zoom: 1; overflow: hidden;"> <div class="booklink-name" style="margin-bottom: 10px; line-height: 120%;"><a href="http://www.amazon.co.jp/exec/obidos/asin/4798137790/uxlayman-22/" target="_blank">キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論</a> <div class="booklink-powered-date" style="font-size: 8pt; margin-top: 5px; font-family: verdana; line-height: 120%;">posted with <a href="http://yomereba.com" target="_blank" rel="nofollow">ヨメレバ</a></div> </div> <div class="booklink-detail" style="margin-bottom: 5px;">ジェフリー・ムーア 翔泳社 2014-10-04</div> <div class="booklink-link2" style="margin-top: 10px;"> <div class="shoplinkamazon" style="display: inline; margin-right: 5px; background: url('http://img.yomereba.com/yl.gif') 0 0 no-repeat; padding: 2px 0 2px 18px; white-space: nowrap;"><a href="http://www.amazon.co.jp/exec/obidos/asin/4798137790/uxlayman-22/" target="_blank">Amazon</a></div> <div class="shoplinkkindle" style="display: inline; margin-right: 5px; background: url('http://img.yomereba.com/yl.gif') 0 0 no-repeat; padding: 2px 0 2px 18px; white-space: nowrap;"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B00OCGT0HM/uxlayman-22/" target="_blank">Kindle</a></div> </div> </div> <div class="booklink-footer" style="clear: left;"> </div> </div> uxlayman