「社会的意義の高い仕事がしたい」 「社会課題の解決に携わりたい」 のようなフレーズを聞いたり使ったりしたことはないでしょうか？ 私は数年前から医療業界の会社に勤めているせいかよく聞きますし、言っていました。 ただ最近は「"社会課題" とはなんだろう？社会的意義の高い低いってどうやって決まるんだろう？」などを考えるようになりました。結構こういったフレーズは多くの人がなんとなく「医療・環境問題など = 社会的意義の高い」と捉えていて、知らず知らずの内に囚われているのではないかと考えています。 ので私自身がこれを考え直してみようと思ったきっかけと、もし「社会的意義の高さ」に囚われている人がいましたら一回自分の好きなように行動してみるのもアリかも、とうっすら思えるようなことを書いていければ思いこの記事をしたためております。 病気の自分を救ってくれたのはエンタメだった考えが変わるようになったきっかけ

「デザイントークン」 最近はよく使われている言葉だと思うのですが、意外と日本語での情報がないのでまとめてみました。 W3C の定義実はデザイントークンには W3C という標準化団体でのワーキンググループがあります。 これが絶対の定義と思う必要はないと思いますが、共通の定義としては便利だと思うので引用するとこの W3C では Design tokens are indivisible pieces of a design system such as colors, spacing, typography scale. 訳: デザイントークンとは、色、スペーシング、タイポグラフィのスケールなど、デザインシステムを構成する不可分なピースのことです。 Design Tokens W3C Community Group https://github.com/design-tokens/commun

先日 Figma Config にて「エンジニアに愛される Figma デザインの作り方」というタイトルで発表をしました。 せっかくなのでもっと多くの人に内容をお届けできればなと思い立ったので文字起こししてみます。 「エンジニアに愛されるデザイン」とは？私は二つ大きい基準があると思っていて、それは デザインの意図を掴みやすい デザインが変わった時の変更が容易 があります。そして前者は Structured Design, 後者はデザインをシステム化していくことによって達成できると考えています。 いきなり Structured Design という耳慣れない単語が出てきたので、まずはそこを解説しますと、これは2021年の Schema という Figma のデザインシステムのカンファレンスのキーノートで紹介された概念なのですがデザインには Freeform と Structured という二

自分は2017年から React と共にキャリアを歩んできたので長らく "フロントエンドエンジニア" としてのアイデンティティを持ちながら仕事をしていたのですが、去年末辺りから仕事で Flutter を使って開発をするようになりました。 始めてビックリ、React とかなり書き味は似ているし、培った経験が活きることが多かったです。 また、詳しくは後述しますが、モバイル開発にも参加できるようになるとキャリアの選択肢も増えるので、今フロントエンドをやっている方が一つの選択肢とし考えられるように「ここは同じだから Web フロントの知見が活かせる、ここは違ってモバイル固有の知識の0からのスタート、モバイルできるようになるとこういうところが嬉しそう」という点を書いていこうかなと思います。 同じところ宣言的 UI な書き方まず React も Flutter も宣言的 UI で作られているというか、

この記事は下記の記事に触発されて、逆方向の「エンジニアの自分がどういうモチベーションでどうデザインの勉強をしていったか」というのを語ってみよう！という内容となっております。 あと最近よく「なんでデザインし始めたの？」「どうやって勉強してるの？」という質問をいただく機会が増えてきたので、それへのアンサーともなればなと思います。 なぜデザインを勉強し始めたのか結論から言うと必要に駆られて勉強し始めました。 前職はスタートアップに勤めていたのですが、当時作り始めていた新規サービスに携わっている人はエンジニア2名 + デザイナー1名という少数のチームでした。 ただデザイナーともう一人のエンジニアは他のプロジェクトにかかりきり…なので一時期この新規サービスの開発は私だけという状況でした。 そこで困ったのがデザインがないこと。大まかなワイヤーフレームは握っていましたが、デザインがないのでフロントの仕事

こちらは「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」1日目の記事です。 昔「フロントエンドエンジニアがデザインできるようになると何が嬉しそうか」という記事を書きました。 これはフロントエンドエンジニアとして働きつつデザインを勉強していた時期のお話なのですが、私は最近業務でデザイン、つまりフロントエンドエンジニアとしてではなく一部デザイナーとしての仕事をするようになりました。 そして、実際に自分が"デザイン"という成果物に責任を持つと、また違った視点で課題が見えるようになりました。なので、この記事ではそんなエンジニアからデザイナーの視点で見るようになって気づいたこと・驚いたことを綴っていこうと思います。 デザインの管理が思ったより難しいまず気づいたのがデザインファイルにも状態があるということです。 大まかに - work in p

海外の事例はいろいろあるので見てきたのですが、国内ではどんな会社が取り組んでいるのか、興味があったので調べてまとめてみました。 「おいおい、この会社が足りないぜ！」というものがあればコメントで教えていただけると喜びます。 Wantedly

やはりデザイナーがアレだとフロントエンドエンジニアの生産性も著しく下がり、逆に良ければ上げることもできると思うので、自分が考えてる「デザインの側面からフロントエンドの生産性を考える」というのは割と筋がいいアプローチなのではという想いが深まった — フロントエンド大好きseyaさん (@sekikazu01) June 15, 2021 思いの外反響があり、もっと具体的に聞いてみたい・ディスカッションしてみたいというお声をいくつかいただきました。 せっかくの機会なので、現状自分が考えるデザインとフロントエンドの接合の最適化、カッコ良くいうと「Design-Frontend Ops論」を語っていこうかなと思います。 ※ 予防線貼っておくと、まだ全然実践できていないので話半分に聞いてください。タイトルに"仮説編"とついているのはそのためです。 ※ 一緒に探求してくれる気概あふれるデザイナーも募集