hiromitsuuuuu.log();

to see more to see.

Frontend Conference Fukuoka 2018に行ってきたよ

Frontend Conference Fukuoka 2018に行ってきました!(まだ福岡にいます)

福岡に6年ほど住んでいたこともあり、最近の福岡はどんなになってるか気になって遊びにきてみました。貴重な福岡のカンファレンスのチケットを確保した代わりにスケッチノートを描いたので資料と一緒にまとめておきます。

frontend-conf.fukuoka.jp

2019年までに見直しておきたいCSSJavaScriptの手法

speakerdeck.com

memo

特にJSは知らない仕様がたくさんあった...! 配列内の要素チェックするincuseとか、ゼロパディングのpadStartとか。ライブラリ入れたり自分で実装してたやつが仕様になってJSネイティブで使えるの便利。関数合成とかnull値アクセスのチェックは、確かに便利だけど私の知ってるJSじゃない...w

スポンサーセッション ディーゼロ & ヌーラボ 「これからのWebアプリケーションに求められるアクセシビリティの設計と実装」

memo

Backlogのアクセシビリティ実装をどう進められているかのトークセッション。アクセシビリティ対応めっちゃしっかり取り組んでるのが素敵でした!「電話だったらどう伝えるか」という考え方めっちゃいい。

500日のトライエラーから生まれた大規模設計ノウハウ

speakerdeck.com

memo f:id:hiromitsuuuuu:20181211184957j:plain

設計を作り始める前の根本的な設計と、中期の設計と短期の設計に分けて、各段階でどんな視点の設計が重要か語られていてとても参考になりました。最近1週間スプリントで月次リリースを回しているので「ソフトウェアは建築というよりガーデニング」というのが沁みました。。。チームのメンバーが設計してた部分を根本・中期・短期にわけて見れそう。

仕組みを作る仕組みを、作る仕組みを作る

memo

web2.0からの流れの話があったのですが、ふりかえって見るとデバイスとWebの進化が合わさってだいぶ遠くまできたんだなと思いました。ウェブは誰にも所有されない唯一のプラットホームというのがエモかった。

かんそう

福岡勢がとても楽しそうで、よいカンファレンスでした!フリードリンクにパーカーのお土産までいただき、ホスピタリティがすごかったです。SNS班もカメラ班もなんか色々福岡の運営が素敵でした。懇親会チケットが買えなかったのがざんねんだった〜!

10年くらい前に私が学生として福岡をうろついていた頃は、技術系のコミュニティも小さな活動しかなかったイメージがあったのだけど、こんなカンファレンスが開催されるくらい盛り上がってきてるんだな、福岡いいなってなりました。ちょこちょこ様子見に帰ってきたい。

福岡のカンファレンスでフラフラしてたら「ヒロミツさん!?」て大学の仲間に話しかけられたのが今日のハイライト。10年ぶりの再会を産むインターネッツすごい。古い知り合いとも再会できたし、最近オンライン読書会で繋がった福岡勢とも繋がれたし、東京勢とも久々に話せたし、とてもよかった!

ポエムに呼応するポエム、またはわたしのFictions

いつのタイミングでか、どうやら世の中のエンジニアは技術同人誌というのを執筆しているらしいというのを知った。Twitterのタイムラインでもサークル当選の話題で盛り上がっている。はて、それは一体どういうものかと先日技術書典5に行ってみた。 フロントエンドとUI関連の本はないものかとサークルを周り、Web Componentsの冊子を手に取ると「ひろみつ氏にはこっちの方が合ってると思う、とりあえず読んでみて」とサークル主に勧められた。目次に目を通すと「スペシャリストとジェネラリスト」「真のユーザーファースト」など気になる言葉が並んでいた。

「こっちもください」

特に中身を深く読む必要もなく、目次買いした。Fictionsという、エンジニア達が書いた、よりよいプロダクトづくり/開発のための本だった。How toは書かれていない。けれど、不確実性の高いものづくりに向かう上で、折れずに向かってゆくマインドセットのヒントになりそうな本だった。帰り道の電車のなかで夢中で読んだ。

ここでは気になった同テーマに対してわたしが思ったことを書いておく。ポエムに呼応するポエムの真似ごとのようなものである。

スペシャリストとジェネラリスト

デザインとエンジニアリングの双方を仕事にしたいという指向性のなかで、スペシャリストとジェネラリストどちらになるのか向き合った内容だった。結果として、学び続け移動し続ければどこかにたどり着いてそこが正解になるのではないかと締めくくられていた。

わたしもずっと「技術とデザインを繋ぎたい」とフロントエンドのエンジニアリングとUI設計の狭間で生きている。志した新人の頃は「ジェネラリスト」になるのだと意気込んでいたが、領域を越境するにつれ個々の領域の浅さに不安感を感じ、スペシャリストとジェネラリスト問題がでてきた。けれどわたしの網羅領域と同じひとはどれだけいるのか考えたら、それが専門性とも言えそうだと思って両方手放さずにここまでやってきている。(だけどここ1年くらいはコードがかけていない)

エンジニアリングとデザインに限っていえば、ふたつの領域は地続きであると信じている。きっとプロダクト設計のスペシャリストにわたしはなりたいのだ。最近、デザインエンジニアとか、プロダクトマネージャーとか、過去にはあまり聞かなかった言葉を耳にするようになった。本を読んで、きっと好きに駆け回っていたら、名前がついたりどこか近いところにたどり着けるのかもしれないと思えた。

詐欺師症候群

コンピューターサイエンスのバックグラウンドがないことに対する劣等感から、自己肯定感がなく、求める状態と現実の大きなギャップが原動力となるという話だった。

まるで自分のことかと思った。自分には芸術工学修士はある。けれど、学んだ領域の広さと、プロダクトのプロトタイプ発表で卒業したからか、学術的なバックグランドの裏付けをもって深く研究していないのではないかという後ろめたさを感じている。もうひとつは、プロダクトコードやプロダクトUI設計の打席数だ。分野を越境しすぎたせいで同じ年数の実務者に比べて、自分のアウトプットは少なく精度が低いのではないかと思い込んでいる。

まわりのコミュニティの知り合いや同僚はなぜか肯定してくれる。ありがたいことだ、否定しては認めてくれている方々に失礼だと思いつつも、自分はもしかすると周りが思っているよりもずっとレベルが低い詐欺師なんじゃないかと不安が掠める。

同じく、このギャップがわたしの原動力になっている。「自分ができると信じている、自信満々だね」と同期は言う。いつか本物になれると信じて、努力を繰り返す。

真のユーザーファースト

プロダクト開発をするなかで、営業からエンジニアまで様々な専門性・立場の人間の意見をいかに理解し、プロダクトの前進に繋がる判断下せるか、どう正しく意思決定を下すかという問いだった。

ユーザーの利益になると考えられた発言のなかには、承認欲求が混在しているものもあるという視点は頷けるものがあった。最近Twitterでみた『「人間中心設計」が、「欲望中心設計」になってしまっている』というのにも繋がるところがある。ステークホルダーのために妥協しなければならないこともあるが、それを続けているとどんどん自分たち都合の機能が増え、ユーザーの利益になる攻めの開発ができなくなってしまう。

いくら越境していても、どこかの判断軸が強くなってしまう。正しいとは何か。大局的な判断をするにはどうすればいいのだろう、わたしも興味がある。

分割統治リニューアル

UIデザインを一新することで、サービスは成功するのかという話。ユーザーの一人としての視点から見れば「リニューアルしてほしい」と思ったことは一度もないと。フルリニューアルは開発現場の改悪や負債を生み、負荷のかかったエンジニアが磨耗してゆく。分割統治し、きめ細かなリニューアルをしていこうという提案。

これはto Bとto CのUIでちょっと変わってくるかもしれないと思った。to B (or in B)では、道具であるシステムの改善によって効率化されて成功(ここでいう成功は、時間の余剰を産んだり業務のミスを減らすことなどである)に繋がることもあると思う。一方、to Cではコンテンツや売り物が主役のサービスである限り、店の内装や棚だけをいくら綺麗にしたところでお客様に届けるのは難しい。商品企画と売り方を一緒に考えないといけないと思っている。フルリニューアルで得られる価値とはどれくらいなのだろう。

リニューアルが成功に繋がるかどうかは置いておいて、改善の粒度は分割統治された方が良さそうだと思う。プロダクトバックログの側面からみても、UIリニューアルに全力を注いでしまうと新機能開発が止まってしまう。ずっと連絡をよこさないで、ある日突然サポートされるより、きめ細かくケアされた方が心持ちが良いのではないか。

デザイナーのように考え、エンジニアとして実行する

プロダクト開発のために、デザイン/エンジニアリングお互いの視点を持って「なぜこのデザインなのか」を考え専門のやりかたで進めようという話。

たまに思うのだが、なぜデザインが上流で、エンジニアリングが下流なのだろう。というか上流、下流という言葉が苦手だ。川下に流れるにつれ、Whyが薄まり作業になっていく。向かう課題は同じはずだ。エンジニアは扱う情報をモデル化し、システムで効率的に扱えるように、デザイナーはその概念をユーザーが理解しやすいように整理して画面に表現するのではないのか。お互いは対等に話せる立場なのではないのか。だからこそ、わたしが設計する際には背景からゾーニング・要素の意図を伝えたいと思っている。

おわりに

触発されてついエモ散らかしてしまった。人を選ぶ本だとは思うけれど、忙しい開発や苦しい時に読み返したくなる本になっていると思った。3人共同で書いた本のようだが、どれを誰が書いたかわからないようになっており、人や役割に紐づかない純粋な文章として読めてよかった。どこかの現場で同じように考えているエンジニアがいるんだなぁ、意識の高い詐欺師にならないように自分も頑張るか、と思った。技術書典お疲れ様でした。

本書が気になった方たちへ。こちらで電子版を買えるみたいです(AmazonKindle版もあるすごい)。

Fictions

Fictions

1000ch.booth.pm

【スケッチノート】「単発受託WebデザインとインハウスUXデザインの相違点・共通点」を聞いてきたよ

8月9日にあった Rikiya Ihara (@magi1125) | Twitter さんが登壇した勉強会のスケッチノートをあげていなかったので貼り付けておきます。

techtomo.connpass.com

受託か事業側かっていうのはあんまり関係なくて、組織とか文化とか得意先との関係性だよなぁとおもた。あと、自分の価値を高めるために、

を組み合わせるって話があり、それって私のカードは

  • アプリケーション寄りのフロントエンド開発
  • HCDある程度回せる
  • UI設計する(サイトよりWEBアプリ寄り)
  • スケッチノート描ける(ちょっとだけファシグラも?)

だけど、あと何のカードがあれば強い役になる!?ってわくわくした!スキルを5枚揃えて最強のエンジニアになろう!みたいなカードゲームできそう。5年くらい前はフロント×UI設計って強い組み合わせ感あったけど、そろそろ手札が弱くなってきている気もするので新しい何かを追加せねばと思った。

ずっとAbout Face3を買おうか迷ってたけど、そういえばと思って探しに行ったら伊原さんが買い占めたせいかどこにもなかったです笑

【スケッチノート】ノン・デザイナーズ・アカデミアに行ってきたよ

「The Non-Designer's Design Book Missing Pages 2018」の冊子版欲しさに、6/26に開催された『ノン・デザイナーズ・アカデミア 〜Design for the rest of us』に行ってきました。

non-designers-academia.doorkeeper.jp

内容は冊子の内容だったのだけど、口頭だと重要なところがより伝わりやすくてすんなり聞けました(´ω`)

後半拾えなかったところもあるけど、メモはこちら。

デザインはPlanning とStyling だという話がしっくりきた。誰に&何のために伝えるのか、情報の構造化→表現の話もあって、みんな本質は近い部分にあるのかもなぁと思った。

あの幻の(!?)ユーザビリティカルタで遊んできた!

6月のとある日に有志で集まってユーザービリティカルタ会をやってみました!

産技大のOBの集まりで、『授業の中で "教示文"という言葉を知らなかったからワード集が欲しい』という話がでた際に『そういえば昔、ユーザビリティカルタっていうのがあってね...』とユーザーリサーチャーの奥泉さんに紹介いただいたのがきっかけ。市販品ではなく、完全な手作りの世界にひとつしかないユーザビリティカルタ!!どんな経緯で作られたものかは奥泉さんのブログに書かれてます。

ユーザビリティ カルタ会:https://okuizumi.jp/blog/2018/06/usability-karuta.html

経緯を聞くと、関わった方達は今では最前線で活躍されている方ばかり・・・そんな方達が同じ場所にいた頃にできたエモいカルタ!2004年のU'eyes Designのブログでも紹介されてます。

usability.ueyesdesign.co.jp

その貴重なカルタで遊ばせてもらいました。よーし、Fbのイベントを立てるぞーと意気込んでいたら奥泉さんがひとこと。

『あ、ちなみに、英語だから笑』

日本語かと思いきや、英語!!! 笑。AはAffordance、BはBehavior model....のような感じで、アルファベット26文字の頭文字のユーザビリティ用語が!

もちろん、読み札も英語!読みは奥泉さんにやっていただきました。流暢な英語でスラスラと読まれる札・・・

26枚だから余裕でしょ!という期待も虚しく、読み札の英語に「ん!? ん!? もう一回お願いします!! 」と戸惑う英語に不慣れ勢笑。英語が余裕な同期が「自分は(すぐわかっちゃうから)ここにいたらだめな気がする」と遠慮する始末w 「The Model...」で始まるからきっとモデルの話だ!とTOEICのリスニング状態になってましたw

RITEメソッド!これは樽本さんのユーザビリティエンジニアリングで書いてたやつだ!という進研ゼミ的瞬間があったり、奥泉さんのかっこいい英語が聴けて個人的には非常に満足でした。

ちょっと用語が古くなってるから2019年版を作ろうとか、クラファンで募って量産しようとか、HCDに関わる人たちのキャリアを模した人生ゲーム作ろう!(HCDを学んだけど社内でから回るとか、プロダクトオーナーになるとかetc...)とか、スゴロクにしようとか、アジャイルで作ってユーザーテストを重ねていこうとか妄想が広がりました。興味のある人はSNSで捕まえてください笑。

DevLOVEの「Atomic Design ~堅牢で使いやすいUIを効率良く設計する〜」に行ってきた

6/29(金)に開催されたDevLOVEのAtomic Design回に行ってきました。

devlove.doorkeeper.jp

『既存のフローからアップデートする アジャイル・デザインフロー』というタイトルで、アジャイル開発を進めるうえでのUI変更に強いデザインフローについてのお話でした。

Atomic Design本には結構コードが書かれているんだけど、今回はコードの話ではなく、何故Atomic Designの考え方が必要なのか、Atomic Designの構造をどう考えていけばいいか、@ygoto3_ さんが実践してるデザインフローができるまでのステップの話がありました。

内容はスケッチノート置いておきます。

どう分割するかがいまいち理解できていなかったけど、ユーザーの行動と合わせて責務で考えるのがすごく分かりやすかった。スケッチノートに書いてる今までのデザインフローでまだやってるんだけど、構造の情報が抜け落ちていてもなんとなくデザインカンプができたり開発を進められたりして、なんでデザインカンプドリブンで進めてしまったんや・・・ってなることめっちゃある。。。

Atomic Designに限らず、最近どんどん構造とユーザー視点が大事になってきていて、エンジニアとデザイナーが概念で会話する世界になってきてる気がする。フレームワークを真似しただけではどんどん置いてけぼりを食らうんじゃないかと危機感を感じた。どうやってこういう文化が浸透していったのかがきになる。

Atomic Design本はこちら。買って積んでるから7月のでかいリリース終わったら読むんだー

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

顧客が本当に必要だったものゲームをやってみた!

タイムラインで話題になっていた『顧客が本当に必要だったもの』ゲームが再販になっていたので買ってみました。

顧客が本当に必要だったものゲーム | 反社会人サークル | ゲームマーケット

4色の成果物カード(手札になる)と、18枚の要件カードが入っています。要件カードのイラストがみたことありそうな方々に似てる笑

3人でやってみた!説明書を読みながら...ひとまずわからなくてもやってみようかとキックオフしてできたのがこちら。

とりあえずカード繋げりゃいいのねと幹を伸ばしてめちゃくちゃ高い位置に椅子がぶら下がっているものができた...。

大体の流れがわかってきたので第2戦。

『これ、こんな高いところに椅子あったらユーザー座れなくない?』『HCD専門家のいるプロジェクトなのに...』...顧客の要件に従おうとした結果、ユーザーに使いにくいものとなっていることに気づくHCD勢笑。

そういえば、カードは上書きできるらしいとルールに気づき第3戦。

『これ、これまででいちばん美しい形じゃない!?』3戦目やってだいぶ学習が進み、地上からもちょうどいい位置にソファを配置することに成功。

やってみて

変な形の木がもくもくできていく様がシュールすぎた。『やばい、もう工数(手札)がない!』『フィードバックループが回ってる』『やばい、プロジェクトが進まない...』『要望に見合う技術(手札)がない』とか好き勝手言って予想以上に盛り上がりました。

チーム開発なのか、他の開発者を押しのけて特定の顧客の要件を満たせばいいのか迷いました笑。たぶんゲームとしては、要件満たすためにみんなで頑張るというよりは、要件カードをゲットするために隠したりやってる感だすのが大事笑

回ごとに成果物の木の形が違ってて、何度やっても面白かった!またやりたいなー