00:06
8月6日、朝9時を回りました。
今日は、僕の地元、広島の原爆投下の日ですね。
なので、ちょっともが行なんですが、
多少の黙祷団にお祈りを捧げるかなと思ってますけど、はい。
天気はちょっと曇りですけど、まあまあ晴れそうですね。
はい、おはようございます。ひめめんのけいつくんのくがはなです。
では本日も、朝活を始めていきたいかなと思います。
えーとですね、本日のね、タイトルにある通りですけど、
Weekly Frontend Roundup from Tokyoさんという記事ですね、のサイトから、
えー、Volume 372ですね、今回の記事。
10個あるんで、その10個のうちから何かを一つ読んでいこうかなと思っております。
はい。えー、視聴者さんですね、おはようございます。朝からご参加ありがとうございます。
じゃあ、えっと早速10個の記事のタイトルと概要だけピックアップしてあるのを
ざらっと読んでいこうかなと思います。
はい、えー、一つ目の記事はですね、えー、プロトタイピングTo Learnという図ですね。
はい、プロトタイピングの威力というところで、
プロトタイピングではアイディアに対して複数のバージョンを構築し、
それが有効かどうかというのを確かめます。
で、これは一見2倍3倍の労力をかけているように感じるかもしれませんけど、
異なるアイディアを試すことで既存のパスがどれほど強力であるかというのを明確に示すことができます。
で、これはチーム全体の決意を強めることにつながります。
私たちが知らないことを明らかにし、目前の問題に対して最善の方法を見つける方法として、
プロトタイピングは非常に有効でありますよというふうに言っています。
はい、これは一つ目ですね。
えー、次、二つ目の記事ですけど、
The Demo、デモループですね。
なるほど、デモが生み出すものですね。
はい、デモの重要性について。
デモっていうのはクリエイティブな製品を成功させる秘訣ではあります。
デモは会議、ワークフロー、プロジェクトスコープを改善させていく力があります。
頻繁に、例えば毎日こうなってもいいと考えていますと。
すべての会議が素晴らしいデモである必要はありません。
重要なのはデモを行う組織的な観光というのを確立し、
デモを提供する際のスキルと自信を抱くことでありますというふうに言っています。
はい。
で、三つ目の記事ですね。
三つ目は、Governance is a Design System Friendsって書いてあります。
デザインシステムにおけるガバナンスです。
はい、デザインシステムにおいてガバナンスっていうのは、
意思決定に対する役割、責任及び権限を明確にするためのフレームワークであると考えることができます。
これにより意思決定がスムーズになり、
コンポーネントに関するもの、チームがどのようにワークするかについて
二つの領域に関しての恩恵もあります。
ガバナンスを確保するというのが重要なことは何でしょうかみたいなところを話していく感じですね。
はい、では続いての記事ですね。
続いては、Building Tabs in Web Componentsですね。
はい、タブのウェブコンポーネントを作ってみましょうと。
セマンティックスアクセシビリティを考慮するような書き方をします。
また、スクロールが可能であることを示すシャドウを動的に適用するテクニックというのを紹介していますと。
03:00
はい、これは気になるけど、この記事はさすがにちょっとコードが出てきたりとか、
かなりテクニックな感じですね、の内容なので今回は音読はやめましょうかというところですね。
では続いて、5個目ですね。
5個目は、The Unlocked Processibilityですね。
いや、ポシビリティでした。失礼。
Possibilities of the Haz Selectorですね。
CSSのコロン・ハズセレクターってやつがありますけど、
によってドムツリー内の他の場所の状態に基づいて他の要素を指定することが非常に簡単になりますと。
これによってJavaScriptの仕様が必要だったスタイリングの多くをCSSのみで実装できるようになることを紹介していますと。
はい、これもTipsですね、CSSの。
ですけども、スキルを磨く意味では結構面白そうな感じはしますね。
記事をざっと見てますけど、ひたすらCSSとHTMLのソースコードだらけって感じです。
ただ、途中でドムツリーの図が出てきたりして、
コンセプト的な解説があったりするので、悪くないと思いますね。
こちらも後ほどTwitterで記事のリンクをシェアしますね。
では続いて、残りインブリーフで5個ですね。
いきましょう。6つ目の記事です。
The Bold of Text Overflowってやつですね。
テキストフローのオーバー、ん?テキスト、
違う、テキストフロー、テキスト-オーバーフローですね。
のアクセシビリティの観点からの問題を指摘しながら、
どのようにその問題に対応すればよいかというのを考えましょうと。
はい。で、7つ目ですね。
7つ目は、アボイディングレイアウトシフト、
アスペクトレギュアバーサス、ウィッズ&ハイトアトリビュートですね。
イメージタグのレイアウトシフトを防ぐためには、
どのような方法があるかというのを解説しましょうと。
タイトルはある通りですけど、
アスペクト比バーサス、ウィッズ、ハイトなので、
横幅高さの指定ですね。
どっちがいいのかみたいな話ですけど。
これは、何回前か忘れましたけど、朝カツで常に読んでますので、
今回はこれを活用させていただきたいと思います。
結構でも、学びというか、
こういうことを考えればいいのかというのは結構面白かったですね、これは。
画像の扱いについての勉強にもなりますしね。
はい、というところでした。
はい、続いて8つ目ですね。
8つ目の記事は、ザ・CSS・ビハインド・フィグマですね。
フィグマが生成するCSSはどんなロジックになっているかを探りましょうというところですけど、
これもどこかで読んだ気がしますので、拡大します。
フィグマですね、ウェブアプリのフィグマだと思うんですけど、
それがCSSでどのように構築されているかというのを見ていくんですね。
グリッドとフレックスボックスのうまいこと組み合わせをしていて、
いろんなもののアイコンであったりとか、レイアウトというのを構成していて、
割と学びになったというか、盗めるチップスがたくさんあったので面白かったですね。
単純にグリッドとフレックスボックスの勉強にもなるし、
応用の仕方というのもフィグマをベースにやっているので、
思いっきり実践的で良かったと思います。
06:01
では続いていきましょう。
続いてここの2つ目ですね。
フロントエンドウェブプラットフォーム。
The Essentials。
フロントエンドのパフォーマンスを理解するために必要な知識を学ぶ。
これはホットなワードなのでかなり気になりましたね。
あとで記事を見て、そんなにソースコードがなかった量を見たいと思います。
ラスト10個目ですね。
10個目はUse Legend and Field Setですね。
フィールドセットとレジェンドタグがあります。
それについて具体的な例を解説していきたいと思います。
フィールドセットはたまに使いますが、
実はレジェンドタグはほとんど使わないんですよね。
なので実はあんまり詳しくないというか。
勉強しないといけないなと思いながらずっとやってないんですけど。
ひたすらソースコードだらけのオンパレードです。
ただコードペンとかのリンクがばーっと貼ってて、
使い方とかが見えるので、
勉強する上ではわかりやすそうなので、
ちょっと途中でバッと見てみて、
そうだったらまたTwitterでツイートしますね。
というところで、
今日この10個の記事があったんですけど、
一番気になったのはさっきのこのフロントエンドウェブパフォーマンスですね。
この前はTechBitさんの勉強会で
ウェブシステムパフォーマンス改善の
ほげほげみたいな勉強会があって、
そこに登壇させていただいたんですよね。
そこでいろいろ学びだったり、
知見が得られたので、
最近僕はパフォーマンス周りにかなり注目を置いてるんですよ。
記事内の本文をたらっと今見てるんですけど、
ソースコードはないんですけど、
コードペンによってどれくらい
chips的なことのパフォーマンスが変わったかっていうのが出てくるんですよね。
コードペンとその下に、
これ多分Chromeかな?
開発者ツールでパフォーマンスタブがあるじゃないですか。
あの辺で多分プロファイリング撮ったやつのキャプチャーが貼られてるので、
ちょっとさすがに読むだけだとしんどいのがあるんで、
これも今回の朝活は割愛します。
ちょっと読みたかったんですけど、これは仕方ないですね。
なので、どれにしようかな。
結局一番上のプロトタイピングの威力かデモが生み出すもの、
この2つどっちかを読んでいこうかなと思いますね。
両方とも記事短いですね。
なので軽く読んでいきましょうかね。
最初はプロトタイプ2ランですね。
の方から読んでいこうかなと思います。
はい、では今翻訳待ちですね。
では行きましょう。
ボブとグレッグっていう方が出てくるんですね。
09:01
が出演したサーキットブレイカーの最新ポッドキャストでは、
サーキットブレイカーっていうポッドキャストをこの2人がやられてるそうですね。
サーキャスト.fmっていうプラットフォームがあるらしいです。
ではですね。
学ぶためのプロトタイピングについて驚くほど深く掘り下げている配信があります。
ボブが初めてプロトタイピングのアプローチについて話してくれたとき、私は躊躇しました。
何かを何バージョンも作り上げるという考えは、
前進する代わりに後進したり横に進んだりするような無駄なことのように最初私は思えたからですと言っています。
プロトタイピングそのものの複数バージョンを作ってたんですね。
引きたくなかったんですよ。正直にそれが無駄だと思ってたから。
しかし長い時間をかけて彼は私に2倍3倍の仕事をしろと言ってるではなく、
私が意思決定するために使っている方法について言ってるんだよっていう風にやっと気づくことができましたと。
なるほどですね。単純労力をかけてるだけではないっていう話ですね。
製品開発の道筋っていうのはたくさんの意思決定のステップがあります。
ケント・ベックラーの影響を受けたソフトウェア業界の人たちはスパイクについて話をしています。
これはそうしなければ見逃してしまうような未知の部分を明らかにするために、
十分な量の何かを作ろうとすることを意味します。
同じ問題に対して2つの異なるアプローチをスパイクし、
その特性の違いを見ることは珍しいことではありません。
もう一つの例ですね。
これはシェーピングルームでのことです。
壁に良いアイディアが貼ってあって、
誰もがうなずきながらコミットする準備ができていますが、
興奮に包まれているわけではありません。
その時誰かが、もっと別のやり方あるんじゃないのかなっていうみたいな、
というわけですよね。
それは疑問を希望にするためでもありますけど、その逆の場合もあります。
全く違うアイディアをちょっと試してみることで、
既存の道がいかに強いかを対比的に示すことができ、
その決意を固めることができるとも言いますね。
なるほどね。そういうことにも使えると。
もちろんグラフィックデザイナーの肩越しに、
プロトタイピングがどういうものかを見ることもできます。
ノートに描かれた1枚のスケッチと、
それに対応する1枚のベクターイメージをスクリーンで見ることはあまりないですよ。
スケッチブックにも、イラストレーターのキャンバスの画面にも、
次から次へとバリエーションがあり、
時には全く異なるアイディアってのも実はありますよと。
これらの例はあくまで表面的なものにすぎません。
プロトタイピングを1つの推測を構築し、
検証するためのコストのかかる作業と考えるのではなく、
学習するための方法、わからないことを明らかにするための方法、
目の前の未解決の問題に対する最善の方法を見つけるための方法として考えることが
大きなアイディアとなりますよというふうに言っております。
はいはいはい。なかなかいい感じの。
これで終了なんですね。というところでした。
かなり短かったですね。
かつ、このボブとグレッグという方がやられている
12:03
サーキットブレーカーというポッドキャストを聞いて、
その感想ブログをこの方が書いた感じですね。
ライアンシンガーさんという方でした。今回の方ですね。
もしあれだったらこのポッドキャスト自体も
後ほどリンク共有しようかなと思います。
一応Appleポッドキャストとかも聞けますし、
RSSフィードとかいろんなところでもプラットフォーム聞けるそうですね。
スポーティファイでは聞けないそうですね。
ここだけちょっと残念なと思いますけど。
という感じでした。以上プロトタイピングの
捉え方というか考え方みたいなところの記事でしたね。
すごく短いんですけど簡潔にまとまってて、
メッセージ性もあってよかったと思いますね。
プロトタイピングは何バージョンも作るって確かにちょっとびっくりしますけど、
でも実際デザイナーさんとかグラフィックデザイナーの方って
それぐらいいろんなパターンとかバリエーションを書いた上で
一つのものに絞ったり削り落としていってるっていうのはよく聞きますので。
別にそれは悪いことというか普通に行われてることだったりします。
エンジニアがそういうことをしないからちょっと違和感だったり
ちょっと嫌悪感を感じるかもしれないですけど、
でもそれを作っておくことって別に悪いことではないですし、
その他のものを比較して僕らが選んだものっていうのが
よりやっぱり良かったねっていう強固な確信が持ってたりするので、
それはそれで確かにいい話だなと思いました。
はい、以上ですね。ではプロトタイピングToLearnですね。
プロトタイプから学べるものっていうところの記事は一旦終了しようかなと思います。
では続いてですね、The Demo Demo Loopですね。
なんだろうなっていう感じの記事ですけど、読んでいきたいと思います。
どこ行った?ここですね。
はい、The DemoからDemo Loopっていうような感じですね。
いきましょう。翻訳するので少々お待ちください。
これもちょっと短いので、多分20分に減らしたら終わってしまう可能性があるので、
他の記事また何を読もうかっていうのはまた探そうかなと思います。
ではいきましょう。
私はDemoからDemoへの取り組みがクリエイティブな製品を成功させるための秘密の公式であると100%確信しています。
ビデオゲームではプロトタイプの作成、プレイテスト、面白さの追求を儀式化してきたという歴史があります。
プロトタイプが成功の可能性を高めるというデータもあるぐらいですと。
ほう、なるほどですね。
クリエイティブリンクっていうものがあって、そこで言及されているものがあるんですけど、
Frozen2というもののドキュメンタリー、Into the Unknownで例示されているように、
Pixarとディズニーアニメーションでは進行調の作品のデモにデイリーを使用しています。
各アニメーターは自分が担当する5秒間のフィルムの進捗を毎日共有しています。
5秒間、すごいな。5秒間のフィルムの進捗を毎日共有してるんですね。
アニメを作っているんだから、それをずっとくっつけてくっつけて一つの作品になるんでしょうけど。
15:02
エンジニアも言ってしまえば、結構小さな細かなコミットだったり、プルリクをどんどん交じりしていくというので、
やっていることは一緒なんですけど、5秒間なんですね。そこは面白いですね。
あとはクリエイティブリンク、クリエイティビティーインクっていう企業も僕は全然わかってないのと、
あとFrozen2っていうドキュメンタリーも全然知らないので、いろんなリンクが貼られてますけど、
僕が知らないことだらけで、ふーんってなってます。
続けていきますね。
続いて、ケン・コシェンダー氏の著書にあるクリエイティブセレクションっていう著書があるんですけど、
この著書によるとiPhoneを開発したAppleの極秘プロジェクト、プロジェクトパープルっていうものを、
そういう名前でAppleの極秘プロジェクトがあったんですね。
プロジェクトパープルではiOSの開発時に頻繁にデモが行われましたが、
彼らの作業スピードでは前のデモの数時間後や数分後にオールウェイデモっていうのが行われたそうです。
はーすごいね。
前のデモの数時間後や数分後にオールウェイデモっていうのが行われた。
すげースピード感ですね。
続いて、デザインスプリントの核となるのは、機能するプロトタイプをユーザーの前に出すことですと。
そうすればチームは数ヶ月後ではなく、1週間で相手を証明し吟味することができるようになりますと。
えー、なるほどね。
いやいや、言うは安いですけど、それは簡単じゃないですよね。
プロトタイプをユーザーの前に出すと、それを1ヶ月じゃなくていい、1週間で相手を証明できるようになると。
そうなんですけど、デザインスプリントの核となる機能するプロトタイプをユーザーの前に出すこと。
これは本当にデザインチームとエンジニアとか、実装するメンバーのチームがしっかり連携して、バリバリパフォーマンスを高く出さないと、これはきついんじゃないかな。
まあとはいえ、1週間単位でそれができるようになったというのはかなりいい話ですし。
逆に言うと、プロトタイプでどこまで実装するかというところですよね。
簡単な紙芝居とかであれば、それは簡単にできるかもしれないですし。
とにかく目で見て、早く確認するという吟味できるというのはすごくいい話だと思いましたね。
とにかく何か作り上げないとデモしなきゃいけないみたいな感じに思わされはいないんですけど、そういうわけでもないですしね。
別にリンクであったらリンク飛ばせばいいだけですし、APIのデータをコールしなきゃいけないようになっても、
APIができてなくてもデモデータだけで、Mockのデータだけで受け取ればいいので、
フロント側とすればそれぐらいできると思ったらやれなくはないですからね。
はい、というところでした。
あとですね、IDEOってよく出るんですけど、ちょっと僕が知らないですけど何ですかね。
どういう団体かなんかわかんないですけど、IDEOっていうところですね。
ググってますけど、アイディオって読むんですか。
はい。
ああ、なるほど。アメリカ合衆国カリフォルニシュのパロアルトに本拠地を置いているデザインコンサルト会社のことなんですね。
18:04
アイディオっていう会社があるんですね。
すみません、ちょっと僕が不勉強で申し訳ないですけど。
はい、そのアイディオっていう企業の有名な言葉があるんですけど、
その言葉をちょっと引用しますと、
プロトタイプは1000回のミーティングの価値があるっていう風にアイディオは言ってるそうですね。
なるほど。
一つのプロトタイプが1000回のミーティングの価値があるっていうのはかなりパワフルなワードですけど、
でもそれぐらいプロトタイプにアイディオっていう会社は重きを置いてるってことですね。
戻ります。
デモは会議を向上させるっていうところですね。
私はそのデモファーストミーティングが生命力を持つことを発見しました。
それは何か具体的なものから始めるからであり、
時間がなくなるまで将来の仮想シナリオを議論し、
さらにミーティングの予定を入れなければならないのとは対照的だからであります。
会議は進捗状況を示すことから始めましょう。
さらにデモは必ずしも電話や会議である必要はなく、
30秒のスクリーンキャストでも大丈夫ですと言ってます。
デモはワークフローを改善します。
大きなタスクを次に何をデモできるかに分割することは
エキサイティングな仕事の方法になりますと。
頻繁に戦術的なフィードバックを得られるような
デモ可能なチェックポイントを見つけることが
私にとって常に当面の目標であります。
手戻りが少なくて済みますし、
悪い方向に進んでいるのを早期に発見することもできます。
デモはプロジェクトのスコーピングを改善します。
デモやプロトタイプは基礎トタルシステムにおいて
何が簡単で何が難しいかについて
良いアイデアを与えてくれますと。
デモを行うことで自分や他の人間が
問題を遠く離れた場所で発見したり、
飛行中に高速なパスを見つけたりすることがよくなります。
品質やユーザーエクスペリエンスを犠牲にすることなく
設計のわずかな修正や調整で
数週間から数ヶ月の作業を短縮することも
よくありますよと言っています。
本当に実体験においてプロトタイプの方が
良いよという話をしているわけですね。
デモですね。
正直に言えばデイリーはやりすぎかもしれませんが
私はそれを嫌いではないですよと言っています。
曖昧で儀礼的な立ち話よりも
デイリーデモの方が良いのは確かですと。
ここで注目すべきは
全ての日や週が晩御飯になるわけではないことですと。
重要なのは組織的にデモを行う習慣というのが
確立しておいて
デモを提供するスキルと自信を磨くことですと。
はい、ここが多分
コアなところだと思いますね。
デモすること自体を目的にするわけでは
もちろんないし
何のためにデモをするかというところも
すごく大事ですし
そのデモの恩恵であったりとか
メリットっていうのを
しっかり自覚しておくことも大事なんですけど
そこに立脚した
やっぱそのデモを習慣化する
っていうところがやっぱり大事なんだろうなと。
それをさらに提供できるスキルと自信っていうのが
かなりメンバーに対してのコアなコンセプトなんだろうなと
21:00
ちょっと思いました。
これができている組織ってかなり強そうですよね。
かつそれができていれば
ステークホルダーだったり
クライアントとかに
今どれぐらいのプロジェクトできてますか
っていうのを出せるので
よりその企業としての信頼感っていうのも
プラスアルファでついてくる気がしましたね。
はい、ラストですね。
ポイントは
あなたの組織のための適合であるものは何でもするが
デモに長すぎる待機っていうのはないですよと言ってます。
アドホックな老化のデモが起こるためのスペースを許可しましょうと。
そして毎日短い針を移動していきましょうと言ってます。
最後の例え話はちょっと難しいですけど
これあれですね。
単純にガントチャート的なものに
針をどんどん刺していくってところだと思いますね。
かつちゃんとデモをやるための余白というか
余裕っていうのを常に組織の中に持っておくことが
すごく大事だよということですね。
はい、という話でした。
さっきの4度記事ですね。
プロトタイミングトゥーランと結局似たような話だったんですけど
同じようにプロタイムとデモっていうところの
大切さっていうのを語られたので
割と僕は考えが固まったというか
より深まったなという感じはしましたね。
でもデモファーストミーティングっていうのは結構面白いですね。
確かにやったことないですね。
会議、確かにやるんですけど。
いろんな会議は。
会議の中でデモファーストでやるっていうのは
あんまりやったことないですね。
一応開発フェーズに入るとデイリーミーティングとかして
チケットの管理だったり
どこまで進捗がありましたっていうのを
やることは確かにあるんですけど
なかなかデモから始めるっていうミーティングを
やることはあんまなくて
だいたいある程度できたりとか
テスト段階に入って初めてデモを結構やるって
よくやるんですけど
スプリント単位でやるのもいいですし
この人の組織ではデイリーでやってるらしいですけど
確かにデイリーはちょっとやりすぎ感はありますけど
少なくともスプリント単位とか
1週間なし2週間でデモをしっかりやって
今どこまでできたかっていうのと
できたものに対してアイディアを見たりとか
改善点を追求するっていうのはすごくいい話だと思うので
そこの習慣化っていうのと
それを用意するための技術力をどんどん身につけていく
っていうところが確立できるっていうのが
組織としてはかなりいい話だなっていうところですね。
これができるといわゆるクリエイターチームですよね
エンジニアとかデザイナーとか
クリエイティブなチームたちも
よりビジネスに実は貢献できてるっていうことを
可視化しやすくなりますし
より彼らがすごい会社に貢献できてるよ
っていうことの証明にもなるわけですよね。
しかもプロトタイミングとかデモツールっていうのを
しっかり履歴に残しておけば
他でも使ったりとか
過去の履歴からも学びがあったりするだろうし
より大きな知見が得られると思うので
これやっぱ大事だし
そういうところを求めていきたいな
というふうには僕も思いましたね。
はい、という感じで
以上デモループでしたね。
はい、という記事でした。
良かったですね。
はい、今読んでた2つの記事
両方とも後ほどTwitterでリンク共有しようかなと思います。
はい、というわけで
24:00
今もう26分くらい来てたので
ちょっと短いですけど
今日の朝活動はこちらで以上にしようかなと思います。
はい、ではですね
また明日も何か適当に記事見つくろって
読んでいこうと思いますけど
最近また何か技術的じゃない
ちょっと俯瞰した目線のところが多いので
なるべく技術的な記事も探して読んでいきたいな
と思ったりはしていますけども
はい、というところです。
じゃあ朝活動はこちらで以上にしたいと思います。
本日は土曜日ですね。
はい、皆さんゆるりと過ごしていただければと思います。
また明日も日曜日なので
羽目を外していただいてもいいんじゃないかなと思いますので
良い休日を過ごしていただければなと思います。
では以上で終了します。
お疲れ様でした。
