shiba 🐑

自分の中のデザイナーとエンジニアの境界を無くして物事を見ることを目標としている紫色の人…

shiba 🐑

自分の中のデザイナーとエンジニアの境界を無くして物事を見ることを目標としている紫色の人です。

マガジン

  • Zaim トレンド 総研

    • 18本

    家計簿データで生活者を観る。様々なトレンドデータ、コンテンツをおみせします。

最近の記事

  • 固定された記事

AIとUIとデザイン

株式会社Da Vinci Studio フロントエンドテクノロジストのshibaです。 ChatGPTを皮切りに、一気にテキスト生成系のサービスに注目が集まってやっと落ち着き始めたな〜と感じている今日このごろです。 僕はデザインとエンジニアリングの両方を扱いながら仕事をしているからこそ、GPTを始めとするAIに対するUIの影響の大きさとデザイナーによる体験提案のポテンシャルを強く感じています。 この記事ではそのポテンシャルを感じさせてくれたいくつかの事例を紹介しながら、A

    • ひとつのあたりまえの話

      shibaです。 最近AIをいじるのが楽しくてAI利用料金がヤバイことになって焦っている、デザインもエンジニアリングもする人です。 突然ですが、あたりまえの話をします。 ほめられて嬉しかったです(わーい)。 多分これはあたりまえ。 ほめてもらえること、特に忖度などが感じられず純粋に予想外のタイミングでほめてもらえることは嬉しいことだと思います。 嬉しかった勢いでこの記事を書き始めました。 多分これはあたりまえじゃない。 問題は予想外のタイミングだったことーーほめても

      • 無印良品の食品の人気商品、20歳未満と20歳以上で全く違った話

        家計簿データ分析チームメンバーから突如、興味深い疑問が投げかけられた。 「無印良品の食品の人気は、年代ごとにどのように変わるのだろうか?」 地味に興味が湧くテーマに、家計簿データ分析ユニット(shiba&maiyan)は Zaim 家計簿ビッグデータの奥地に赴いた。 この記事は、家計簿データ分析チームが無印良品の食品の人気を探る冒険譚である。 ……まあ、奥地に赴く前に作戦会議。 いきなり結果だけを見るのは味気ないので、まずは人気シリーズ(ぶっちゃけ自分たちが好きなシリーズ

        • 家計簿ビックデータで見る 「きのこたけのこ論争」

          定期的に話題となる株式会社明治の「きのこの山」と「たけのこの里」どっちが人気なのか論争に一石を投じるべく、国内最大規模の家計簿データを用いて分析しました。 ※集計仕様 期間:2019年4月~2023年3月 該当ブランド:「きのこの山」「たけのこの里」 サマリ全体の傾向では「たけのこの里」に軍配が上がった 「きのこの山」「たけのこの里」とも共に、 30 代~ 40 代女性の購入者が多い エリア別で見ると、一部の地域では「きのこの山」が勢力を拡大している 「きのこの山」

        • 固定された記事

        AIとUIとデザイン

        マガジン

        • Zaim トレンド 総研
          18本

        記事

          早く大きく進めるためのプロジェクトとメンバーについての認識

          株式会社Da Vinci Studio デザイン部 フロントエンドテクノロジストのshibaです。 メンバーのパフォーマンスを担保しつつプロジェクトを早く大きく進めるには何ができるだろう?と考えるのが最近のテーマです。 きっかけについては以前の記事にかるーく書いています。 「うまくやれば」ってなんやねん、ということでそれに活かせそうなことを色々勉強しています。 というわけで、「プロジェクト」と「メンバー」についての知識をまとめてみました。 今回はプロジェクトとは複数人で

          早く大きく進めるためのプロジェクトとメンバーについての認識

          規則や法律はしっかり意図をもってデザインされたものだなあと思った話

          株式会社Da Vinci Studio デザイン部 フロントエンドテクノロジストのshibaです。 僕は日常的にデザインとエンジニアリングの両方を業務で行っており、だいたい1:1くらいの割合で活動しています。 いいなと思うWebサービスを見るとそのデザインと使用技術に興味を持って観察したりWappalyzerを確認したりしながら「これはなぜこうデザインしたんだろう?」「ここでの技術選定はどうしてこれなんだろう?」と無意識のうちに確認と考察をしていたりします。 そんな僕は最

          規則や法律はしっかり意図をもってデザインされたものだなあと思った話

          「全部自分でやりたい」から「複数人で物事をすすめる」を理解しようとする話

          どうせつくるなら理想のものを作りたい。 自分のできることを広げたい。 そのために必要な技術や知識は自分で勉強しながら試行錯誤する。 これは学生時代の自分のスタンスで、最近までこのスタンスが仕事にも若干影響していました。 例えば学生時代に「できないからやらない」と発言している同期がいて理解できなかったり、社会人になってからは「実装されたインタラクションがデザインしていた想定の挙動じゃないからぼくが実装し直します」と実装に関与したりしていました。 幅広いスキルを習得して柔軟な

          「全部自分でやりたい」から「複数人で物事をすすめる」を理解しようとする話

          連絡躊躇病を治す2つの質問

          株式会社Da Vinci Studio デザイン部 フロントエンドテクノロジストのshibaです。 数週間前まで、重度の「連絡躊躇病」にかかってました。 いくつかの要点を掴んでほぼ完治出来た気がするので、今回はそれについて書きます。 連絡躊躇病についてMTG中に発言する分にはできるけど、Slackなどテキストコミュニケーションで発言しようとしたときに「これ今送ったら迷惑になるかな?」「これ今送って問題にならないかな?」など躊躇してしまう病です。 相手が忙しいひとやポジショ

          連絡躊躇病を治す2つの質問

          「フロントエンドテクノロジスト」について

          shibaです。 ぼくは 株式会社Da Vinci Studio デザイン部 で 「フロントエンドテクノロジスト」 を名乗って仕事をしています。 聞いたことないと思った方、ぼくが勝手に定義した言葉なので当然です。 この記事ではぼくが何を見て何をしているのかについてかんたんに紹介しようと思います。 「フロントエンドテクノロジスト」の由来「フロントエンドテクノロジスト」は一言でいうと「デザインとエンジニアリングの両視点からユーザーにとってのわかりやすさのためにプロジェクトに貢献

          「フロントエンドテクノロジスト」について

          package-lock.json についてわかりやすく言語化する

          shibaです。 突然ですが、デザイナーからこんな質問をいただきました。 package-lock.json が勝手に変更されるんだけど Ignore していいの? Gemfile.lock が勝手に変更されたから消しちゃっていい? なんか起動しなくなったから package-lock.json と node_modules 消して npm i しようかな? 結論だけ言うと「ダメです」で終わってしまうんですが、どうしてダメなのかを非エンジニアに説明するのは地味に難し

          package-lock.json についてわかりやすく言語化する

          Google Mapの表示をカスタマイズしてサービスに最適化した話

          株式会社Da Vinci Studio のフロントエンドテクノロジストの shiba です。 「ユーザーの働き方の選択肢を増やす」をコンセプトとした「リモートワークのくふう」プロジェクトにてデザインや一部フロントエンドの実装を行っています。 このサービスではGoogle Mapの埋め込みを活用したマップの上にコワーキングスペースの情報を表示する機能を提供しています。 マップ周辺の表示についてデザイン部にデザインレビューを依頼していたときに「Google Mapの情報が多

          Google Mapの表示をカスタマイズしてサービスに最適化した話

          「失敗」との向き合い方のヒントをゲームから学んだ話

          DVSのフロントエンドテクノロジスト、shibaです。 失敗とは成功のもと とか、失敗したということは「こうするとうまく行かない」ということを発見したということだから前向きに捉えよう とか、 次に行動をどう変えるかが重要 とか。 言葉の上では理解できるけど、でも落ち込むんだよなあ… とクソザコナメクジ全開でちょくちょく凹みながら仕事をしていて、直近の悩みでもあります。 ところで、皆さんはSOUND VOLTEXというアーケードゲームを知っているでしょうか。 僕が愛してや

          「失敗」との向き合い方のヒントをゲームから学んだ話

          デザインと言語化

          言語化、してますか? と聞かれて全くしてない人はまず居ないと思います。 日記、LINE、ツイートなど、意図を言語化した結果のアウトプットは少なからず誰もがしているはずです。 仕事面に関して言えば報告・連絡・相談のような基本的なコミュニケーション、目標設定のような自分を見つめ直すような言語化もあります。 もしTODOリストを管理しているとすればタスクを言語化しているし、議事録は議論内容を言語化したドキュメントです。 他にも、エンジニアの実装という作業はロジック(思考)をプ

          デザインと言語化

          書籍「SPRINT」より、普段の仕事にも使えそうなメソッドの紹介

          株式会社Da Vinci Studio のフロントエンドテクノロジスト、shibaです。 先日、「となりのデザインスプリント」というオンラインイベントのLTを聞きました。 デザインスプリントは名前だけ聞いたことがありましたが詳しく調べたことがなかったので色々と良いインプットになりました。 デザインスプリントはプロジェクトメンバーが月曜から金曜までの5日間1つのプロジェクトに集中してコミットし、5日間で課題の洗い出し・解決策の提案・提案の検証まで行ってしまうえげつない手法で

          書籍「SPRINT」より、普段の仕事にも使えそうなメソッドの紹介

          GitHubの通知をSlackでリアルタイムに得たい!

          ぼく「GitHubの通知をSlackでリアルタイムにいい感じに得たい!」 メンバーZ「Slackに通知送る設定、」バッ メンバーA「簡単にできるで!」ババッ ぼく「ぎょえ!」ドカーン メンバーZ「まずGitHubにログインするじゃろ」 ぼく「はい」 メンバーA「このリンク開いて設定したいチーム(Organization)開くやん」 ぼく「はい」 メンバーZ「だいたいこんな感じで設定するねん」 ぼく「関西弁うつった?」 ぼく「あーこれは色々微調整できるな

          GitHubの通知をSlackでリアルタイムに得たい!