MOL

Zwift 環境 2024

Tue, 03 Dec 2024 00:00:00 UTC

ちょっと前まで、暑くて、こんな暑かったら外でランニングできないやと思ってたら、今度は寒くてランニングできない。ましてや、最近また太ったので走るとちょっと膝が痛い。こんな俺にはランニングよりサイクリングだ！ということで、また室内サイクリング環境を整えたいと思った(2024年2度目)。

ちょうど、1年前にもZwift環境という記事を書いてて、久しぶりに記事書いたと思ったらまたZwiftで、この人ずっとZwiftしてたのかと思われるかもしれないが、安心してほしい。なにもやってない。前年の環境は春の引っ越しとともに全て売却したので、また最近Zwiftやりたくなって、買い直した話。

ZWIFT RIDE

Zwiftやりたいなーと公式サイト訪れたら、ナニやら物欲を刺激する新製品がでてるじゃないかということで、ZWIFT RIDEが爆誕していた。

オールインワン（正確にはKICKR CORE + Zwift Ride Smart Frame）でこれを買えば、すぐにZwiftをできる優れものである。オールインワンといえば、既にKICKR BIKEというのが出ている。これもすごくカッコ良いのではあるが、なにぶんにも高い。54万円。趣味でやるには高すぎる。しかも、飽き性の自分であるから、すぐ売っちゃうし、ということで、泣く泣く断念していたのである。

そこへ来ての、ZWIFT RIDEである。22.4万円。安い！いや安くはないが54万円と比べれば、30万円も安くなってる！買いである。いや買えないのだが、すごく心が迷ってしまう。とはいえ、少し冷静になって考えれば、私は飽き性である。どうせ飽きて売るのだから、もっと安いの買えよ！って話である。なんか、こう、もっと手軽にZwiftできないもんかと探していたら、ちょうどよいフィットネスバイクがあった。

MERACH：フィットネスバイク

前回のFITBOX LITEを購入して思ったけど、ちゃんとZwiftやるためにはケイデンスセンサーをつけたり、パワーペダルとかつけたりしないといけないのだと思っていたけど、デフォルトのままでZwift完全(？)対応しているフィットネスバイクがあるらしい。【自動負荷調整】と書いてあるフィットネスバイクはそうらしい。

フィットネスバイク MERACH（メリック）フィットネスバイク自己発電式アプリ連動可能自動負荷調整スピンバイクマグネット式家庭用極静音室内バイク組立簡単トレーニングバイク日本語取扱自宅用オフィス用

MERACH

Amazon.co.jpで詳細を見る

中国製のちょっと怪しいブランドだが、3.7万円でZwiftを楽しめるのなら安いもんだ。そんで、前の時のようにロードバイク＋スマートトレイナーのように複数の構成ではないので、フィットネスバイク単品だけで良いので粗大ゴミとして捨てるときも楽だ（既に飽きた時の撤退戦略も考えいてる）

ので、買ってみたら、本当にパワーソースとして認識している。素晴らしい(MRK-S13っての)。

Zwift 環境 2024

というわけで、できたZwift環境 2024!!

AIR SHELFを使うことで自由にタブレットの高さを調整することができた。

念願のiPad 12.9インチサイズの大画面で見やすい。

ちょっとバーテープ貼ってみた。

サドルにクッションつけて、ペダルも変えてみた。

閑話休題：続けるためには

去年は、なんかダラダラとやってしまい、めんどくさくなって乗らなくなってしまった。その敗因を分析してみると、ジムをちゃんと行ってた時代は予約した時間前にシャワーを浴びて、コンタクトレンズをつけて、ジムウェアに着替えて〜という切り替えがちゃんとできていたのだと気づいた。

室内バイクのいいところは、朝起きたらすぐそのまま乗れるということだ。だが、それはデメリットでもある。寝巻きのまま、メガネのまま、乗ったところでダラダラとなんだか不快なまま、不完全燃焼で終わってしまって、運動の体験が良くないまま終わっていたから続かなかったのだと理解した。

ちゃんと切り替えを意識してからは（最低限コンタクトつける）、先月から週２でZwiftを続けれらている。よかった。しらんけど。

とはいえ、また春になったら飽きて売ってるんだろうなと思うけども頑張って続けたい。

Zwift 環境 2023

Sun, 03 Dec 2023 00:00:00 UTC

ちょっと前まで、暑くて、こんな暑かったら外でランニングできないやと思ってたら、今度は寒くてランニングできない。ましてや、最近また太ったので走るとちょっと膝が痛い。こんな俺にはランニングよりサイクリングだ！ということで、また室内サイクリング環境を整えたいと思った。

FITBOX LITE

まずはフィットネスバイクで一番有名そうなやつを購入した。最近のはマグネット負荷システムというのらしく、負荷を上げてもぜんぜん静かで、セールとかで3万円くらいで買えたのでモノとしては満足している。しかし、単純にこいでてもおもしろくない。ということで、Zwiftをまたやりたいと思うようになった。

【公式】FITBOX ケイデンスセンサー Zwift/Kinomap 対応

フィットボックス(FITBOX)

Amazon.co.jpで詳細を見る

調べてみると、どうやらFITBOX公式のケイデンスセンサーがあるようなので、これでFITBOX LITEの漕いでる回転数をZwiftに送信できる。つまりZwift上でサイクリングできる。

COROS（カロス）PACE 3 ランニングウォッチスポーツウォッチ 30g

COROS

Amazon.co.jpで詳細を見る

ちなみに、心拍数もZwiftに送信する必要があるが、こちらはランニング用に買ったCOROS PASE 3から心拍数を送信できる。

ということで、ケイデンスと心拍数が計測可能になったのでZwiftをプレイしたのだが、パワーメーターがないので、FITBOXで一番軽い負荷も一番重い負荷にしても回転数が同じであれば、当たり前っちゃ当たり前だが、同じパワーしか出ないのだ。今度はパワーメーターが欲しいなと思い始めた。調べてみるとどうやらクランク（ペダルのところ）型のパワーメーターがあるので、それをFITBOXに装着すると計測可能になるらしいのだが、5~6万円するらしい。FITBOX本体が3万くらいで買ったのに、なんでセンサーにその倍払わなきゃいけないんだと思い、こうなれば普通にロードバイクとサイクルトレーナー買ってやればいいんじゃないかと考えた。

Wahoo KICKR CORE

サイクルトレーナーは最近だと国内ブランドのも出たりして、前より選択肢は増えていると思う。しかし、まぁ信頼性とうことでWahoo製品にした。前回はKICKRを購入したが、今回はKICKRの廉価版であるKICKR COREを購入した。KICKRが最大パワー2200Wに対して、KICKR COREは1800Wが最大パワーになっている。初心者の自分がやる分には瞬間的に立ちこぎしても300、400Wくらいがせいぜい限界なのでぜんぜん許容レベルである。ということでフリマサイトで安く購入できた。

シマノ(SHIMANO) CS-R7000 11S 11-28T 12345791358 スプロケット ICSR700011128

SHIMANO

Amazon.co.jpで詳細を見る

廉価版ということで標準でスプロケットがついてこないので。シマノのCS-R7000 11S 11-28Tを購入して装着。

TERN SURGE

サイクルトレーナーは購入できたので、今度はロードバイクを購入しなければならない。前回はなぜか初心者のくせにGIANTのエアロカーボンフレームを買ってしまい、Zwiftを辞めたときに、こんなガチな車体で外走るのは初心者としてちょっと恥ずかしいと思い、Zwiftを辞めた同時にロードバイクも売却したのだった。

今回はZwift辞めた後でも、ちゃんと（？）街乗りにできるような車体がいいなと思い、ミニベロのTERN SURGEを購入した。かっこいい。

Zwift 環境 2023

というわけで、できたZwift環境 2023!!

扇風機と空気清浄機もあるぜ！

ミニベロだとサイクルトレーナーをつけると前輪が低くなるので、フラットにするために踏み台を置いている。

SENUN 踏み台低踏み台高さ9.5cm

SENUN

Amazon.co.jpで詳細を見る

普通に漕いでてもチェーンの音しかしないが、ここはマンションの4階のため念のため防振パッドをかましている。

GROWTAC(グロータック) ブルカット3（2個セット）ローラー台専用防振パッド

GROWTAC

Amazon.co.jpで詳細を見る

あとお尻痛いのでクッションと汗カバー。

Magi's Gift自転車サドルカバー超肉厚お尻痛くないロードバイクサドルカバー

Magi's Gift

Amazon.co.jpで詳細を見る

こんな感じでiPad Air 10.9インチを見ながらしている（欲を言えば、もうちょっと大きいタブレットほしいけど、ZwiftしたいがためにiPad Pro 12.9インチを買うのは流石にオーバースペックすぎる）。

というわけで、また春になったら飽きて売ってるんだろうなと思うけども頑張って続けたい。

プロダクトビジョン

Thu, 13 Oct 2022 00:00:00 UTC

プロダクトビジョン

安藤昌也 (監修, 翻訳)

Amazon.co.jpで詳細を見る

読書の秋なんで、山積みになってるのを読もうと思う。

タイトルからデザイナーの組織論っぽいのかなと思ったけど、手っ取り早く言えば、デザイナー向けのプロダクトマネージャーへの指南書みたいなかんじ。

別にプロダクトマネージャーになるためにデザイナーになる必要もないと思うが、デザインとは広義では設計の意味なので、プロダクトのビジョンを設計すると考えれば自然の流れなのかもしれない。そういったデザイナーを本書では戦略デザイナーと呼び、いわゆるデザイナーと言われて想像するUIやインタラクションをデザインするデザイナーを戦術デザイナーと呼称している。

戦術デザイナーから戦略デザイナーになろうって話だけど、まぁ普通のデザイナーとしての作業をしているだけでは足りなくて、コミュニケーション能力であったり、データ分析能力であったり、そういったものも身につけていかなければならないよとのこと。

興味深かったのは、ビジョンを考えて実行していく組織・チーム編成の段階だ。BEDRC（ベッドロック）（ビジネス・エンジニアリング・デザイン・リサーチ・コンテンツ）と呼ばれる５つの専門分野に長けた人たちが必要と述べている。5つの分野だからといって最低5人必要というわけでなく、だれか兼務したりしてもいいし、10人ぐらいのチームで担当を分けたりすることもできる。

最初の３つはよく言われてることなので、ふむふむと思うけど、リサーチ・コンテンツも重要なんだなぁと理解したので、この辺も勉強していかなければならないなぁと思った。

とはいえ、個人的にはUIをこねくりましているほうが好きなので、戦略デザイナーになりたいというモチベーションが足らず、本書全体として、あまりピンとこない印象を持った。

Visual Studio Code完全入門

Thu, 06 Oct 2022 00:00:00 UTC

Visual Studio Code完全入門

リブロワークス (著)

Amazon.co.jpで詳細を見る

読書の秋なんで、山積みになってるのを読もうと思う。

Visual Studio Codeは、リリースされたときから割と使っているが、ファッション的になんか良さげ！と波に乗っただけで、使いこなしてるわけではなかった。我流と言ったらなんだが、とりあえず仕事してて必要そうなところからかいつまんで、身につけていったかんじだ。

というわけで、基本から学ぶには本書はうってつけの本だった。VSCの各UIがなんという名前なのか（アクティビティバーとかパネルとか）とか、ドロップダウンメニューの奥に隠れてたいたZenモードを見つけたとか、いろいろ発見があった。

内容的には拡張機能の種類からいってもWeb系をターゲットしているみたいなので、駆け出しフロントエンドエンジニアの方などに良いかもしれない。しらんけど。

文字レイアウトの法則

Fri, 30 Sep 2022 00:00:00 UTC

1ページずつ学ぶ文字レイアウトの法則

ソフィー・バイヤー (著)

Amazon.co.jpで詳細を見る

読書の秋なんで、山積みになってるのを読もうと思う。

タイポグラフィというと小林章さんの欧文書体が有名だけど、本書はもっと初心者向けというか基本をまとめたもの。200くらいのルールがあるという。まぁ最初の方のルールは、当たり前やろ！みたいなことも多いが、非常にためになる一冊である。

レディング活版印刷では、文字と文字の間には金属製や木製の板を、行と行の間には薄い鉛板を入れて余白を作っていました。そのため、英語では行送り（行間）のことは、いまでも鉛（lead）に由来する『レディング』（leading）と呼ばれています。

へーと思った。

最後の方にちょっとだけだけど、（Web）インタフェースのお約束についても触れてあったのが、今どきに合わせてきたなという印象。

UXデザインの法則

Wed, 14 Jul 2021 00:00:00 UTC

UXデザインの法則

Jon Yablonski (著)

Amazon.co.jpで詳細を見る

心理学と聞くと、ちょっと仰々しい感じがするが、中身は一度は聞いたことがある法則だたったり、デザイナーなら無意識でやってるようなテクニックであったり、そんなに小難しくない。中には知らない法則もあったりして、自分が作成したデザインを説明するときに、これらの引用を添えて説明すると説得力も増すだろう。

ヤコブの法則：慣れ的なアレ
フィッツの法則：ターゲットの大きさと近さのアレ
ヒックの法則：選択肢の多さについてのアレ
ミラーの法則：マジックナンバーのアレ
ポステルの法則：寛容な入力に対応しよう
ピークエンドの法則：ピークとエンドが大事
美的ユーザビリティ効果：ふつくしい is よい
フォン・レストルフ効果：リズムを変える的なアレ
テスラーの法則：a.k.a. 複雑性保存の法則
ドハティのしきい値：応答が0.4秒以内にしろ！

中でも良かったのは第11章の『力には責任が伴う』だ。上記のような法則をうまく使えば、自身のサービスを使いやすいものとすることができる反面、中毒性のあるものにしてしまうかもしれない。FacebookのようなSNSサービスで承認欲求を満たしたいなど。

デザイナーはなにも悪いものを作ろうとしているわけではないが、結果としてそうなってしまう可能性があるということに意識を向けないといけない。スタートアップでは、早く作って、早く出すというようなマインドがあるが、本書ではその歩みを緩め、倫理観を持ってプロダクトを作ろうと提言しているのが、個人的に印象深かった。

デジタルサービスはますます私たちの生活に深く入り込んできているので、それをデザインし、ユーザーの行動に良くも悪くも影響を与える私たちの役割は大きくもあり責任重大だ。

株式会社プレイドにジョインしました！

Tue, 01 Jun 2021 00:00:00 UTC

気づいたら、入社してました。社内を見渡すとツヨツヨなエンジニアばかりでガクブルですが、自分はデザイナー職での採用でした。といってもWebフロントエンドのコード(front-of-the-front-end)も書くのですが、いわゆるデザインエンジニアって感じです。最近は、デザインエンジニアって何するんだろう？と思いながら、下記の記事を訳してました。

【翻訳】私ってデザインエンジニアかも... - MOL

といってもこれはクライアントワークを主とするClearleft社のデザインエンジニアの話なわけで、KARTEを提供するSaaS会社のデザインエンジニアにはまた違った側面があったりするんだろうなと思ったり、難しい。

自分でデザインしてコーディングするぶんには問題ないわけですが、バックエンドも書くエンジニア（ややこしい）の皆さんも不慣れなUIコードを書くわけで、そこでいかに負担をかけずにデザイナーの意図したUIをちゃんと再現できるかを考えると、デザインシステムみたいな仕組みも必要になってくるわけで、いろいろとやることは多いです…

SaaSのブラッシュアップに高速で挑むデザイナー - 株式会社プレイドの求人 - Wantedly

そういうわけで、プレイドではデザインエンジニア絶賛募集中なので応募してね！

【翻訳】私ってデザインエンジニアかも...

Tue, 27 Apr 2021 00:00:00 UTC

Original：I think I might be a design engineer…（2021-02-17）by Trys Mudford

この記事はデザインエンジニアリングについてのシリーズの一部です。Web開発者の役割の変化やデザインとエンジニアリングの違いについて議論していきたいと思います。長くなりそうだったので、この記事を補足するために Prototyping、Systemised design foundationsとThe designer & developer relationshipに記事を分けました。それでは始めましょう。

数年前から、自分がWeb開発のどの領域に当てはまるのか考えてきました。自分のキャリアを振り返れば、ある種の仕事に収束しているのを感じていましたが、それが何という名前なのか、今までは分かりませんでした。

Web開発者はWebサイトを構築するのか？

「Web開発者」として最初の数年間、実際のところ、その役割はWebサイトを構築することを意味しなかったのです。Webサイトをコピーして更新したり、ファイルをFTPでアップロードしたり、お茶を入れたり、何か問題が起きたときにサーバー管理者に連絡したりしていました。

しだいに責任ある仕事を任されるようになり、実際にWebサイトを構築するようになりました。しかし、それだけではなく、インフラの管理、メールテンプレートの作成、企画の立案、マーケティングキャンペーンの手伝いなども行っていました。それはただWebサイトを構築するだけではありません。

とあるスタートアップに入社したことで、2人の新しいデザイナーと、プロダクトのヘッドレスAPIを開発するバックエンド・エンジニアリング・チームと初めて出会いました。フロントエンドチームは、「フロント」と「バックオブフロントエンド」の両方を担当しました。ボタンを作り、それをつなぎ込んでいく。今でもWebサイトを開発していますが、エンジニアリングチームとの共同作業です。

Clearleftのようなデザイン力の高い会社の一員になったことで、デザイナーとエンジニアのより良いコラボレーションの方法に目を向けるようになったり、デザインプロセス全体をより深く理解するようになりました。すべてのプロジェクトとは言いませんが、「フロント・オブ・フロントエンド」に注力するようになり、実際のWebサイトを完成するために「バック・オブ・フロントエンド」をエンジニアリング・チームに引き継ぐようになっています。

デザインの意図を理解しリリースする

これはWeb開発者の仕事の中でも非常に大きな部分を占めています。しかも、ビジュアルデザインだけではなく、リサーチ、UX、プロダクト、コンテンツ、それまでのプロセス全体が対象となります。プロジェクトに参加する前の良いアイデアをすべて取り入れ、それらをエレガントにまとめ上げ、ユーザーに適切に提供するにはどうすればよいでしょうか。

あなたが「Webサイトを構築する」Web開発者であるならば、それはあなたの責任です。しかし、もしあなたが開発工程の末端ではないとしたらどうでしょう？もしあなたが自分のコードをエンジニアに渡せるとしたら…

WebのためのWeb開発者

大規模な代理店やほとんどのプロダクトチームには、「エンジニアリング」チームがあり、それは2つの領域に分かれています。

バックエンド
バック・オブ・フロントエンド

一般論ですが、これらの分野の開発者は「システムを考える人」であり、プログラミング > デザインという考え方で物事に取り組む傾向があります。私の経験では、彼らの脳はそのように働く傾向があるのです。彼らのスキルは、エレガントで堅牢、かつスケーラブルなコードを書くことで、何か問題が起きたときにプロダクトが破綻しないようにすることです。彼らのスキルは、プロダクト全体を合理的なチャンクに分解し、データを効率的に保存して、簡単にクエリを投げるようににすることです。また、データの漏洩を防ぎ、ユーザーが不正なデータを保存するのを阻止し、ハッカーの攻撃を阻止することにあります。

彼らのスキルは（繰り返しますが、あくまで一般論です）、デザインのニュアンスを理解することではありません。誤解しないでください、それは素晴らしいことです。このようなチームで働く機会を持っているなら、自分が得意なことに集中して、本当のプロに専門分野を任せることができるのは、とても良いことです。このチームでは、（これまで説明してきた）Web開発者は、より大きな開発工程の一部です。彼らはWebサイトを構築するというよりもWebのために構築しているのです。

デザイン→エンジニアリングの溝

しかし、最近では「デザイン」から「エンジニアリング」へと直進し、フロント・オブ・フロントエンドを完全に見落としている組織が増えています、結局、デザインの次の段階がコードなのだから、エンジニアにUIを作らせればいいのではないか。ちょっと待って下さい、この2つの機能の間にある巨大な溝に飛び込むことは、素晴らしいデザインの意図を失う可能性があります。

Natalya Shelburne氏のBeyond Tellerrandでの講演から引用したスライドが、このギャップを説明するのにうってつけなので、私は大好きです。

ソフトウェアエンジニアの帽子をかぶってデザイナーと仕事をしていると、まるで、ただの丸を渡されて、美しいフクロウを作らなければならないような気分になります。彼らはコードや品質、私がアーキテクチャでやらなければならないことを理解も評価もせず、Webサイトの写真を見てばかり、私が自分がヒーローのように感じます。

一方で、私がデザイナーとしてプロジェクトに参加しているとき、どのデザインでも細部まで完璧に仕上げたフクロウを誰かに渡すと、彼らはdivを渡してきます。ごめん、それはただの丸です。

上記の引用と画像は、Natalyaのトークから抜粋したものです。スクリプト・講演には一見の価値があります。

どちらの領域でも、期待が満たされないことに失望することがあります。しかし、このように2つの役割が異なる考え方を持っている場合、効率的に引き継ぎを成功させるためにはどうすればよいのでしょうか？

私たちのアプローチ

Design foundations
デザインやコーディングの段階に入る前に、私たちはプロジェクトを管理するための基本的な指示や計算、つまりタイポグラフィ、スペース、カラー、グリッドを作成します。
Prototyping
デザインが表示される場所は最終的にはブラウザなので、デザインを早く実際のデバイスで動かすことができれば、仮定をより早く検証することができます。

デザインの翻訳

大規模な開発工程の中でWeb開発者としての私たちの目標は可能な限り最善の方法でデザインを「翻訳」することだと思います。経験上、スクラップからシステムを構築するよりも、開発とデザインの両方がシステムを使って構築されていれば、それはかなり簡単なことです。だからこそ私たちは、デザイン段階からコーディング入り、連携して一緒に意思決定するようにしています。つまり、フロントエンドのコードはデザインの延長線上にあります。

あるいは、Jamesがこう言っています：

プロダクトのコードバージョンの忠実性は、デザインの後ではなく、デザイン段階で構築されます。開発者は、デザイナーのマイクが床に落ちる前にキャッチするのを待つのではなく、デザインチームに組み込まれます。 ― James Gilyead

この役割はなんですか？

このような方法はとても効果的であり、私の興味を非常にかき立てました。私は、迅速なビルド、システム設計、エレガントでスケーラブルなコードを書くことが好きです。

しかし、もはやWebサイトを構築しているとは思えませんし、Webのための構築しているとも思えないこともあります。たとえファンデーションがプロダクトに組み込まれたとしても、プロトタイプは、ほとんどが捨てられてしまいます。デザインをエンジニアリングに翻訳するためや、プロジェクトの前提条件を検証するという目的を果たした後、消えてしまうのです。ある意味で、これはエンジニアのためのビルドです。

このささいな気持ちからこの役割には名前があるのではないかと考えました。そしたらあったのです。

✨ デザインエンジニアリング ✨

デザインエンジニアリング・ハンドブックを読んでいて、第1章の最後にある段落が私の心を捉えました。

デザインエンジニアリングとは、デザインとエンジニアリングの重複部分を精査し、納品やアイデアの検証を迅速に行うための分野の名称です。プロトタイピングからプロダクションレディなコードの作成まで、デザイン決定を迅速に行い、リスクを軽減し、UIコードの品質を確立する職能です。デザインエンジニアの仕事は、プロダクト開発とイノベーションを最適化するために、デザイナーとエンジニアが最も効果的にコラボレーションできるようなシステム、ワークフロー、テクノロジーを包括しています。 ― Natalya Shelburne

それ、私

この段落は、私が気づかないうちに押し進めようとしていた役割を完全に言い当てています。

アイデア検証
ラピッドプロトタイピング
プロダクションコード
UIコードの品質
便利なツールの作成
システムのカプセル化
プロジェクトの土台作り
効果的なコラボレーション

イエス！これは非常にエキサイティングな発見でした。

デザインエンジニアの居場所

デザインエンジニアは、先に述べた2つの分野の間の溝に位置し、2つの分野をスムーズに翻訳する方法を見つけ出します。

片方で、デザイナーはピクセルパーフェクトなモックアップと美しいインターフェイスを目指します。もう片方でエンジニアはシステムの設計やパターンの最適化に努めます。その中間には、この2つのアプローチがどのように交わるかを考えるデザイナーとエンジニアがいます。 ― Adekunle Oduye | デザインエンジニアリング・ハンドブック

デザインエンジニアが書くもの

CSSは、デザインエンジニアの主要言語です。

CSSはプログラミングデザインのために作られたもの。デザイナーとエンジニアの両方に役立つツールであるがゆえに、このような議論がなされることが多いのです。異なるメンタルモデルを持つ人たちが一緒に仕事をしなければならない交差点では、声が大きくなりがちで、時には敵対的になることもありますが、そこにこそ学びがあるのです。 ― Natalya Shelburne | デザインエンジニアリング・ハンドブック

どのようにコードを書こうとも、最終的にはHTML、CSS、JSに集約されます。デザインエンジニアは、ユーザーエクスペリエンスとデベロッパーエクスペリエンスのバランスを取る必要があります。チームが自分たちに合った方法で優れたコードを書けるようにすると同時に、ユーザーエクスペリエンスに悪影響を与えないようにしなければなりません。

そのためには、通常は選択しないような技術を学び、使用することもありますが、それがチームに最高の製品を生み出す力を与えることは間違いありません。

言葉もツールのひとつです。

デザインとエンジニアリングが直面する課題を議論する
デザインエンジニアが提案するソリューションを説明する
ファンデーション、プロトタイプ、システムをドキュメント化する

本質的には、デザインエンジニアの目標は役に立つことです。UXが適切な判断を下すのを助け、リサーチがテストから最も有用なインサイトを得るのを助け、デザイナーが健全で実現可能なアイデアを生み出すのを助け、エンジニアがデザインの意図を理解するのを助ける。しかし、最も重要なのは、エンジニアリングチームのためにデザインを翻訳するためにできることをすることです。

私たちは「クリエイター」と「メンテナー」という言葉を使います。それは、仕事をする人と、うまく維持する人です。しかし、私はこれはスペクトルだと考えています。デザインエンジニアは、クリエイター陣営の中でも最も「創造的」な部分に位置しており、素早く開発し、素早く失敗し、他のクリエイターが後に続くことができるように、悪いアイデアの道を切り開きます。

まとめ

そうですね、私は実際のところデザインエンジニアかもしれません。今までやってきたことを大きく変えるわけではありません。私がこれまでに手がけてきたファンデーション、プロトタイプ、デザインシステムはすべてこの職能に該当します。そして、そこにいるのが昔の私ではないということに、とても安心感を覚えています。もっとこのコミュニティを掘り下げていきたいと思っています。

さて、ここで最後の質問ですが…

すべてのプロジェクトでデザインエンジニアが必要でしょうか？

あえて言えば、プロジェクトをまとめるエンジニアリングの職能があれば、イエスと言えるでしょう。さらに、私はすべてのプロジェクトのデザインプロセスに開発者が関わるべきだと確信しています。開発をウォーターフォールの下流に置くのは簡単なことですが、デザイン＆エンジニアリングの「フクロウの嘆き」からもわかるように、デザイン・エンジニアリングの関与が早ければ早いほど、プロセスはスムーズに進みます。

【翻訳】デザインエンジニアリング - MOL

2015年にも同様な話題についての記事を訳したが、最近、フロントエンドエンジニアの職域が広がりすぎていているのを感じている。自分はWebデザイナー上がりのフロントエンドエンジニアなので、やっぱりUIを作り込みたいという気持ちがあるし、その領域で自分のスキルが発揮できると思っている。フロント・オブ・フロントエンドとバック・オブ・フロントエンドを分けるの良いと思う一方で、小さなスタートアップでそこまでフロントエンドにリソースを割くことも難しいと思うので、まぁ適材適所で頑張りましょうとしか言えない。とりあえず、もう少しこのデザインエンジニアリングというものを今後探っていきたいと思う。

Webフォント読み込み戦略（2021年）

Wed, 21 Apr 2021 00:00:00 UTC

Preload web fonts

前回、といっても2年前だが、display=swapとはなにかで、Google Fontsを読み込むときはURLパラメータに display=swap をつけるといいよと言った。というわけで、それ以降、『目標をセンターに入れて、display=swap…』と盲目的に考えるようになってた。

おさらいとして display=swap では、まず代替フォントを表示し、Webフォントをダウンロードしたら、随時スワップするという挙動になる。この場合、代替フォントからWebフォントへ切り替わる FOUT (flash of unstyled text) が起こってしまう。こんな感じ↓

出典：font-face descriptor playground

まぁ何も表示されないよりかは良いかと思うわけだが、時は流れ、最近ではWebの指標として、Web Vitalsというものがある。その中のCLS（Cumulative Layout Shift）では、レイアウトの安定性というのも評価する。つまり、代替フォントからWebフォントへ切り替わる際のレイアウトのズレ・ちらつきが、このCLSを下げてしまう原因になる。

出典：Fontastic web performance - Speaker Deck

ということで、今回紹介する font-display: optional の場合はどうなるかだが、100msのブロック期までにWebフォントを取得できたらWebフォントを表示する、できなかったら代替フォントを表示するという分かりやすい挙動。

この場合、FOUTはないが、最初に100msのブロック期があるので不可視テキストが表示される FOIT(Flash of Invisible Text) が起こってしまう。

出典：Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fonts

と思っていたら、Chrome 83で改善が行われ、<link rel="preload"> と一緒に使うことで、ブロック期に不可視テキストを表示せず、というかレンダリング自体をブロックして、100ms後に一気に表示することでレイアウトのカタツキを無くすことにしているようだ。

 <!-- HTML -->
 <link rel="preload" href="NotoSansJP-Regular.woff2" as="font" type="font/woff2" crossorigin />

/* CSS */
@font-face {
  font-family: 'Noto Sans JP';
  font-style: normal;
  font-weight: 400;
  src: local('Noto Sans JP'), url(NotoSansJP-Regular.woff2) format('woff2');
  font-display: optional;
}

こんな感じに、fontファイルをpreloadして、optional設定すれば、レイアウトジャンクなしにWebフォントを読み込める。

Google Fonts

Google Fontsから読み込む場合の最善手については、CSS Wizardryさんが詳解な説明をしているので下記を読んでほしい。

The Fastest Google Fonts – CSS Wizardry – Web Performance Optimisation

<link rel="preconnect"
  href="https://fonts.gstatic.com"
  crossorigin />

<link rel="preload"
  as="style"
  href="$CSS&display=swap" />

<link rel="stylesheet"
  href="$CSS&display=swap"
  media="print" onload="this.media='all'" />

長いので要点は上のように設定すればよい。$CSS のところに自分の読み込みたいフォントのURLが当たる。まず最初に、woffファイルなどの配信元であるfonts.gstatic.comに事前に接続しておく。

そいで、 display=swapでスタイルシートをpreloadしておく。

そいで、最後にGoogle Fontsのスタイルシートを設定するのだが、見慣れない記述がある。

media="print" onload="this.media='all'"

ちょっまっ！印刷用CSSになってんじゃん！と思うじゃん。それでいい。ブラウザはこのCSSを印刷メディアのCSSだと理解して、現在のレンダリングと無関係に読み込み始める。これが狙いだ。そして読み込み終わったら現在のメディアに適用するといったことをしている。

The Simplest Way to Load CSS Asynchronously | Filament Group, Inc.

これが一番簡単に非同期でCSSを読み込めるハックっぽい。display=optionalではないのは、この読み込み方と相性が悪いためだそうだ。

というわけで、本ブログでもNoto Sans JPを読み込んでいたので、CSS Wizardryさんのやり方で読み込んだら大幅にPeformanceが改善した。これはCLS改善というよりCSSの非同期読み込みによる改善が大きな要因だ。CLS自体は0.004 -> 0になったので、まぁ、うん。。。

結局、色々調べた結果、t32kにはWebフォントは早すぎると感じたので、本ブログでのNoto Sans JPの読み込みを辞めた。うん、スッキリ。お後がよろしいようで。

参考資料

ユーザーインタビューをはじめよう

Mon, 12 Apr 2021 00:00:00 UTC

ユーザーインタビューをはじめよう

スティーブ・ポーチガル (著), 安藤貴子 (翻訳)

Amazon.co.jpで詳細を見る

サブタイトルにあるように「聞くこと」入門の本だなぁという小並感。UXリサーチのためのユーザーインタビューと聞くと小難しいテクニック満載なのかなと思ったのだけど、読んでみると、信頼関係（ラポール）構築とか静かな環境を準備するとか当たり前だけど大事なことについて解説している。

ユーザーインタビューする機会なんて、まぁそうそうにはないが「聞くこと」に関しては、日常的にしている行為であるので、聞き上手になりたければ本書を手にとってみるのもありだろう。

最近では、エンジニアがポッドキャストを配信したりYoutuberになったりしてるから、そうゆうケースで、ゲストから面白い話を聞く術を身につけるという点でも良いかもしれない。

そいうゆうわけで当たり前をちゃんとやっていくために必要な本だと思った。

100Wの急速充電器を購入した

Sun, 28 Mar 2021 00:00:00 UTC

最近、16インチMacBook Proを持ち歩くようになった。これが重いこと重いこと…せめてものあらがいで、充電器だけでも軽量化しようと思った。

Hyppr PD 充電器 100W E-MARK線付き急速充電器 GaN (窒化ガリウム)採用タイプC 2USB-Cポート【PD3.0対応/PSE認証済/折畳式/】最新のMacBook Pro 16"対応 (ブラック)

ブランド: Hyppr

Amazon.co.jpで詳細を見る

Hyppr PD 100W GaN 急速充電器というのものを購入した。流行りのGaNだ！ MacBook Pro標準の充電器と比べて、まぁ少し、ひとまわり小さいが、厚さは本製品のほうが厚いので、そこまで感動がない。

黒色が好きなので、黒を買ったが白色のほうが安い。（どうゆうことよ）

重さが89g軽い！（うん微妙…）

充電器だけではMacBook Proを充電できないので、USB-Cケーブルも軽量化が図れるぞ！

標準でついてくるケーブルは2mもあるので、もっと短いほうがいいということで、Ankerの100W充電できる0.9mのUSB-Cケーブルを購入した。17.9g軽い！（ちなみに、Hyppr PD充電器に付属のUSB-Cケーブルがついてくるの買う必要はない）

Anker PowerLine II USB-C & USB-C 3.1(Gen2) ケーブル(0.9m ブラック)【Power Delivery対応/USB-IF認証取得/超高耐久】

ブランド: Hyppr

Amazon.co.jpで詳細を見る

ということで、106.9gの軽量化に成功した！

約100gなんて、ちょっと文庫本でも同じリュックサックに入れたら帳消しになるくらいだけど、両手で持って比べてみるとやっぱ軽いなぁと思うので、精神的に軽くなったんだと強く思い込もうと思ったのであった。

NETFLIXの最強人事戦略

Mon, 15 Mar 2021 00:00:00 UTC

NETFLIXの最強人事戦略

パティ・マッコード (著), 櫻井祐子 (翻訳)

Amazon.co.jpで詳細を見る

ちょっと前の本。この本を読む前まではネットフリックスと聞くと強いエンジニアたちが集まって、ハイパフォーマンスを出さなくなったエンジニアは、バッサバッサ解雇するようなイメージだったが、この本を読む限り、ちょっと違うようだ。

プロスポーツチームのように考えれば分かりやすいのかもしれない。プロスポーツ選手は多額の報酬をもらえるかわりに、報酬に見合った活躍をしなければ契約を解除される。エンジニアも（ネットフリックスのエンジニアは特に）またプロスポーツ選手並かそれに近い報酬を得ていることだろうから、この考えをエンジニアにあてはめるのは間違ってないのかもしれない。

またプロスポーツ選手は加齢によるパフォーマンス低下というあらがいようがない事実はあるが、エンジニアはまぁそこまで極端に落ちることがない分、よいかもしれない。本書でもエンジニアのパフォーマンス不足による解雇例はあるが、それよりも事業フェーズの変化によるエンジニアとの価値観のミスマッチが多いみたいだ。

例えば、できたてのほやほやスタートアップであれば、従業員数もまだ少ないので、みんなファミリーみたいに感じで仕事ができるが、会社が大きくなるにつれて、そういった感覚が希薄になってくる。ネットフリックスもまたそういった成長をし、『昔はよかった〜』と思うような従業員に関してはどんどん辞めてもらってるそうだ。プロスポーツチームも監督が変われば、監督の方針にあわない選手は解雇され、方針にあう選手を他のチームから招き入れたりしている。

解雇と聞くと、やはりとんでもない不安なイメージがあるのは日本人だからだろうか。もっと気楽にとらえても良いのかもしれない。会社と向かう方向が違うと感じたのなら、さっさとお互い別れて、同じ方向に向かう人・会社のところに行ったほうが結果的にはよいのかもしれない。この辺は、ALLIANCE アライアンスでも同じことが言われていた。

あと、従業員エンゲージメントを高めるためにやたらパーティなりいろんな福利厚生をつける会社があるが、ネットフリックスはこれに懐疑的である。成功に貢献することが最大のモチベーションと述べてあるように、確かに、適切な目標設定をし、それに向かって問題解決してるときこそ、仕事している感があってモチベーションが高いような気がする。いつかはネットフリックスでエンジニアをしてみたいと思わせる一冊だった。

一人から始めるユーザーエクスペリエンス

Mon, 15 Mar 2021 00:00:00 UTC

一人から始めるユーザーエクスペリエンス

長谷川敦士(監修), 深澤大気(翻訳), 森本恭平 (翻訳)　他

Amazon.co.jpで詳細を見る

昔、購入して積ん読してあったのをようやく読了。デザイナー向けの本かなと思ったらそうでもなかった。どちらかというと、企業のWeb担当者などがUXデザインやるぞ！と思ったときに、どうやって一人で始めていくかを解説してある。なので、UXデザインで使う各手法について軽く説明してある程度である。自分で実践してもっと知りたいと思ったら、ペルソナなり、ユーザービリティテストなりの専門書を手にとって見るのもよいだろう。

個人的にUX関連の手法というかワードがいっぱいあって、ごっちゃになっていたので、各ポイントを簡潔に説明してあったのは良かった。またUXデザイナーはいわゆるデザイナーだけのキャリアアップの職種ではなく、エンジニアからUXデザイナーになることもあれば、コンテンツ担当者からUXデザイナーになるこもとある。

そういうわけで、デザイナーだけでなく、エンジニアなどの方も本書を手に取るとよいかもしれない。

現状把握と計画立案
- UXセルフチェック
- UXプロジェクト計画
- リスニングツアー
- 機会探索ワークショップ
- プロジェクトブリーフ
- UX戦略ワークショップ
ユーザーリサーチ
- ユーザーリサーチ計画
- ゲリラユーザーリサーチ
- プロトペルソナ
- ヒューリスティックマークアップ
- 相対評価
- コンテンツパターン
デザイン
- デザインブリーフ
- デザイン原則
- スケッチ
- スケッチボード
- タスクフロー
- ワイヤーフレーム
テストと検証
- ペーパープロトタイプ・インタラクティブプロトタイプ
- ブラックハットセッション
- クイックアンドダーティユーザービリティテスト
- ５秒間テスト
- UXヘルスチェック

最後に各フェーズにおけるUX手法の目次を置いておく。

デザインの伝え方

Sun, 14 Mar 2021 00:00:00 UTC

デザインの伝え方

Tom Greever, 坂田一倫他

Amazon.co.jpで詳細を見る

エンジニアもコードレビューのときにいろいろ気をつけることはあるが、こちらの本はデザイナーがデザインレビューするときではなくて、デザイナーがデザインの決定権を持つステークホルダーなどに自分のデザインを説明する方法について解説している。

デザインとは見た目に起因するところが多いので、デザイナー以外から、いろいろ言われやすい職種である。エンジニアをしていて、ディレクターなりPMなりに、そこは三項演算子使わないほうがいいんじゃない？みたいなことはヒャクパー言われたことないのにも関わらず、デザイナーはデザイナーからはもちろん、すべてのステークホルダーからなんやかんや言われる。

偉大なデザイナーは偉大なコミュニーケーターであるように、本書もまたデザインの本というより、コミュニケーションの本に近い。それは目次をかいつまんでもながめてみると『親しい間柄になる努力を』、『良好な関係を築く・ものを贈る』などと、まぁなんとウェットなコミュニケーションであろうか。

もちろんデータに基づく決定や、論理的な説明でわかってもらえればそれにこしたことはないが、そうもいかないのが現実で、事前の根回しだったり、そのデザイナーの信頼残高がものを言ったりするのも事実。

とはいえ、やはり自分はこうゆうのが苦手だったりするので、偉大なデザイナーさんに同情するとともに敬意を持って相対していきたいと思う一冊だった。

SegmentedPickerによるビュー切り替えトランジション

Wed, 24 Feb 2021 00:00:00 UTC

まぁ題名の通り。

struct ContentView: View {
    @State private var selection = 0
    var body: some View {
        VStack(spacing:0) {
            Picker("画面切替", selection: self.$selection) {
                Text("A").tag(0)
                Text("B").tag(1)
            }.pickerStyle(SegmentedPickerStyle()).padding()
            
            if selection == 0 {
                viewA
            } else {
                viewB
            }
        }
    }
    private var viewA: some View {
        ZStack {
            Color(.blue).edgesIgnoringSafeArea(.all)
            Text("A").foregroundColor(.white)
        }
    }
    private var viewB: some View {
        ZStack {
            Color(.red).edgesIgnoringSafeArea(.all)
            Text("B").foregroundColor(.white)
        }
    }
}

よくあるタブ切り替えのような感じのものをPickerのSegmentedPickerStyleで＠Stateを切り替えることでビューも変わる。

普通に作ったらこんなかんじで、パッパッと切り替わる。当たり前だ。transitionを指定してないから。

どう動かしたら、ビュー遷移のメンタルモデルが自然にできあがるのだろうか。こうゆう感じの。

セグメントコントロールを右にスライドしているのだから（A->B）、それに対応するビューも左から右に出てきてほしいものだ。イメージ的に。なんとなく。たぶん。その逆（A<-B）は右から出て左にいってほしいもの。イメージ的に。なんとなく。たぶん。

VStack {
    Picker
    if selection == 0 {
        viewAlpha
            .transition(
	            .asymmetric(
		            insertion: .move(edge: .trailing),
		            removal: .move(edge: .leading)
		        ))
    } else {
        viewBeta
            .transition(
	            .asymmetric(
		            insertion: .move(edge: .leading),
		            removal: .move(edge: .trailing)
		        ))
    }
}.animation(.default)

最初はGeometryReaderでビューの幅サイズを求めて、オフセット値をいじって画面外まで移動させればいいのかな？めんどくさいなーいやだなーと思ったけど、

trainsitionを設定するだけでよかった。そう、SwiftUIならね！

.transition(.move(edge: .leading))

普通はこんな感じでtransitionを指定すると思うのだけど、これだと一方方向にしか動かない。

.transition(
	.asymmetric(
		insertion: .move(edge: .trailing),
		removal: .move(edge: .leading)
))

asymmetricを利用することで、transitionのinsertionとremovalを個別に指定することができる。

うん、なんかそれっぽくなった🤗