はてなブックマーク

はじめに テクノロジー戦略本部 デザイナーの白井と申します。 私の所属しているプロジェクトでは新規社内システムを開発していて、 私はUIデザインをメインに担当しています。 幅広い年代の方に利用して頂くことを想定しているシステムなので、 世代ならではの特性に対する考慮や配慮がとても重要となります。 UX/UIの観点からターゲットユーザーにどう向き合って行くべきかを社内LTで発表する機会がありました。今回はそちらの資料を紹介させて頂きたいと思います。 発表内容 タイトルは「UX/UIデザイン ターゲットユーザーと発達心理学」として発表しました。 目次 UX/UIとは ⇒UXとUIの違い ターゲットユーザーとは ⇒設計するサービスのユーザー層を定義する 発達心理学について ⇒年代別特性の変化と対処法 まとめ 発表資料は下記となります。 speakerdeck.com 最後に 「加齢に伴う変化」は

はじめに テクノロジー戦略本部の酒井です。前回デザインシステムの導入に関して話しましたが、今回は運用についてどういった取り組みをしてきたのか紹介していこうと思います。前回の記事をまだ読んでいない方は読んで頂けると幸いです。 デザインシステム導入してみて(導入編) はじめに 概要 デザインの質を保つ取り組み デザイン定例について デザインQA Figmaの管理 Figmaのデザインにステータスを持たせてみた ステータス ステータスを使ったFigmaの運用 メモの活用 おわりに 概要 前回の記事でも少し触れましたが、今までエンジニアがよしなにコンポーネントを実装していたことで、いつの間にかフロントの開発がしづらい状態になっていました。ですが、デザインシステムを導入したことでコンポーネントが整理されていきました。しかし、導入しただけでは再び開発しづらい状態になる可能性がありました。そこで、いかに

テクノロジー戦略本部データサイエンス部の近藤です。 バイセルはリユース事業を営む会社で急激な成長を遂げていますが、どちらかというと今まではテクノロジーにあまり頼ることなく成長してきました。 そんな中、テクノロジーをちゃんと導入していけばどこまで成長するのか試してみたく、2022年7月にバイセルに入社しました。 バイセルではSSOTの実現のために、RDBのデータをBigQueryにニアリアルタイムで同期する実装を進めていますが、 新たにDatabricksの導入を決めました。 バイセルにどういう課題があり、なぜDatabricksを導入するのかをお話しします。 SSOTとは バイセルの今の課題と未来 どうやって課題を解決するのか なぜApache Sparkなのか Databricksの利点 Databricks導入後の世界 データサイエンス部の野望 SSOTとは データマネジメントでは「S

はじめに テクノロジー戦略本部の酒井です。 私が現在携わっているプロダクトに「デザインシステム」を導入したため、今回はそのことについて話していきたいと思います。ですが、全て触れると長くなってしまうため、今回は導入について話していきます。 はじめに デザインシステムとは 参考記事 背景 導入について スタイルガイドの作成 使用するカラーコードの選定 Typographyのコンポーネント化 使用するアイコンをFigmaで管理 UIコンポーネントの整理 Figmaのマスタコンポーネントの作成・管理 コンポーネントに切り出す基準を定義 まとめ デザインシステムとは 本題に入る前にデザインシステムについてですが、記事がたくさんあるため、ここでは深くは触れません。簡単に言うとUIコンポーネントやスタイルガイドなど「デザインを定義する」ための仕組みのことを指してます。 参考記事 デザインシステムとは何か

はじめに こちらはバイセルテクノロジーズ Advent Calendar 2021 の24日目の記事になります！ 前回の記事は杉田さんの「過去一やらかしにやらかしを重ねた話を供養する」でした。 こんにちは、情報システム部の天野です。 バイセルテクノロジーズでは今期コミュニケーションツールとして全社でSlackを導入しました。導入の旗振りは情報システム部（私含め4人）で担当しました。設定からガイドラインの策定、各部との調整などかなりいい経験を積ませていただいたと思うのでみなさんにシェアできればと思います。ぜひこれから、Slackを導入する方の参考になればと思います。 はじめに なぜコミュニケーションツールとしてSlackを導入したのか 導入までの大まかなTodoと流れ Slackの設定＆運用決め 具体的に行ったこと 設定・運用決めで悩んだ点、重要なところ 検証 Welcomeメッセージの設定

はじめに こちらは バイセルテクノロジーズ Advent Calendar 2021 の 9 日目の記事です。 前日の記事は 飯島さん の「新規プロジェクトにインフラ監視ツールを導入した話」でした。 こんにちは。2021 年に新卒で入社した開発 2 部の小松山です。 私は今年の 6 月末までバックエンドは Ruby on Rails がメインのプロダクトの保守開発業務を行っていたのですが、7 月から新しいプロジェクトへ配属され、新規プロダクトの開発に携わることになりました。そこではバックエンドに Hasura を採用しています。この記事では、その Hasura を実際にプロダクト開発に利用して見えてきた、メリット・デメリットを紹介できればと思います 目次 はじめに 目次 前提 Hasura の概要 プロジェクトでの運用 良かったところ テーブル作成が完了すればフロントエンドの開発を始めるこ

はじめに テクノロジー戦略本部の早瀬です。 RESTful な API の仕様の定義する時に OpenAPI を使用することはよくあると思います。 ですがある程度の規模のプロジェクトになってくるとopenapi.yamlが肥大化して数千、数万行になってしまい下記のようなつらみが出てきます。 複数人での開発でコンフリクトが発生しやすい 目的の API の定義箇所が見つけにくい 記載方法が統一されておらず秩序がなくなる $refがネストしてると探すのが大変 エディタによっては重すぎて開けない ずらずら書きましたが要は、とにかく開発しずらいということです笑 そこで今回は治安がよく、できるだけストレスフリーな OpenAPI の開発環境を作っていこうと思います！ 最終的なコードはこちらにプッシュしてあります。 はじめに openapi.yaml の分割 paths schemas paramete

梅雨の季節と思いきや、清々しい天候の続くこの頃、皆様いかがお過ごしでしょうか？ Tech開発部アーキテクチャグループで色々やっております塚本と申します。普段はスクラムマスターやったりしています。 もうひと月以上経ってますが、先日参加してきたRubyKaigiのセッションの内容を掘り下げて記事にしてみます。 Kaigiの概要は村上さんの記事をご参照ください。 tl;dr; Rubyはよい 個人的にはコミッターがよい（失礼） 発表もよい 記事にしたいセッションが絞りきれず執筆が大変なことに Rubyコアの速度改善の話に絞りました 他はまた別途 Rubyist world map Rubyに対して 私のRuby歴は全部足して3年くらいで、関わってきたコミュニティの皆さんほど言語に対する思い入れもなく、Railsなんかツラい思い出が9割くらいなんですが、Rubyはいい言語だと思います。 端的にいう