手触りのいい UI を Web で実現するために実装者ができることを考える｜seya
「手触りのよさにこだわってます！」 なんてフレーズはよく聞きますが、具体的に "手触りのよさ" とはなんなのか、実装者としてはどんなところにこだわるべきなのか、ふと気になったので自分なりの考えをしたためてみました。 手触りのよさって何？まず言葉の定義がふわふわしているのでここをはっきりさせてみます。 主観的に普段自分がスマホなりを使っていて手触りがいいと感じる要素をあげてみると次のような要素が思い浮かびました。 1. パフォーマンスがいい レンダリングが重くて動作が遅くなったりしないことや、なんらかアクションを起こした時(なにかをタップしたりした時)にそれに呼応した画面の変化がすぐに行われることが望ましいです。 2. 迷わない 画面の変化が起きた時に、自分が求めている情報がどこに表示されているかすぐに分かることを指します。自分が起こしたいアクションがどこにあるかすぐ分かるか、というのも重要
React Server Componentsに感じたフロントエンドの消失
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
フロントエンドの消失 - または戦争が激しくなる話
React Server Components に感じたフロントエンドの消失という記事に端を発する一連の議論だが、実際この記事で書かれていることはそうだろうなと思う。話の流れとして誤ってる部分はないと思うし同意する。 この記事ではフロントエンドエンジニアとして、この件についての僕の見解を書く。もちろんフロントエンド（とは？）の総意ではない。 元記事と重複する部分多いが、そこは同じ問題を取り扱う以上避けて通れないため、ご容赦いただきたい。 同じ領域を取り扱ってる以上、開発戦争は激しくなる 様々な理由によりユニバーサルが求められている ※この記事でいう「戦争」とは、お互いの領域を食い合う開発が、活発化することを「戦争」と称しているだけです。それ以上の意図は全くございません 領域がかぶっている 最近のフロントエンド系ユニバーサルエコシステムは、たしかに PHP や Rails の領分を侵そうとし
毎週10個以上の施策を実現するための主体的開発チーム作り｜敷地 琢也 / Ubie
超高速プロダクト改善に必要な価値の高い施策を作り続ける活動は、プロダクトオーナーだけでやっているとすぐにボトルネックになるので、開発チーム全員でできるようにした話を事例を交えながら話します。 はじめまして。Ubie DiscoveryにてAI受診相談ユビーのプロダクトオーナーをやっている敷地(@shikichee)です。 AI受診相談ユビーの開発では、エンジニアが4人、デザイナーが1人のチームで毎日リリースしており、細かい改善も含めると週に10回以上、年間600回のペースでリリースをしています。(※サービスはアプリではなく、Webのみ) もともと月に20回ぐらいのリリースペースだったけど、ここ3ヶ月ぐらいで2.5倍になって、月に50回はリリースできるようになってきた。 このままいくと、年間600回ぐらいはリリースできる。 もっと仮説検証まわしていくぞー。 — 敷地 琢也 / Ubie Di
ヘッドレスCMSって何？WordPressとの違いや特徴を解説
企業が自社のコーポレートサイトやオウンドメディア上で定期的な情報発信をする際に、コンテンツの運用・管理をどのような方法にするか悩みますよね。インハウスで、かつマーケターなどビジネス側のメンバーだけで、素早くコンテンツを発信できる運用方法を構築したいと考えている企業も多いのではないでしょうか。 そこで登場するのが、世界中で広く使われているCMS（コンテンツ・マネジメント・システム）です。 CMSと言えば、まずはじめに名前が上がるのが、WordPress（ワードプレス）でしょう。WordPressは2003年に誕生したオープンソース型のCMSで、世界中で圧倒的なシェアを誇っています。しかし、最近ではWordPressや既存のCMSから乗り換えて、2018年頃から注目されはじめたヘッドレスCMS（Headless CMS）を導入する企業が増えています。 そこで、今回の記事では、「ヘッドレスCMS
UXデザイナーとして入社して、8ヶ月間でやったことを振り返ってみる｜versionfive
こんにちは、@versionfive です。 SmartHRのプロダクトデザイングループにUXデザイナーとして転職して、10ヶ月ほど経ちました。 昨年年末で入社8ヶ月くらいだったのですが（すでに2ヶ月以上経過…）、自分がどんな仕事してきたか振り返ったほうがいいかなー、とぼんやり考えるようになっていました。 UXデザイナーとして入社後に設定したテーマ（やること）は、常に自分の中にありますが、「SmartHRのUXデザイナーは具体的に何する人なのか」の発信はできていなかったからです。 “ 私のつなぐ・そろえるミッションとして、以下を目標にしたデザインの共通言語をつくっていきます。 ・プロダクトと広告/販促制作物などとの体験の整合をとること ・プロダクト内の体験をそろえ、生産性をあげること ” ということで、入社後の8ヶ月間でやったことを振り返って、 「UXデザイナーと肩書きがついているプロダク
アウトカムにつなげるIssue管理 - OKRとKPI(NSM)とPBL｜小城久美子 / ozyozyo
プロダクトマネージャーが責任を持つのはアウトプットではなく、アウトカムです。機能（アウトプット）を作って終わりではありません。「インタビューでユーザーが言っていたから」という理由だけでプロダクトに機能を付け加えるのもいけません。ユーザーの言いなりになるのではなく、ユーザーの期待を超えていく姿勢を持ちましょう！ このnoteの結論このnoteは、アウトカムとアウトプットの紐付けが難しいのであれば、OKRとNSMを活用してアウトカムを定義して、間にIssue Listを挟んでアウトプットの検討をするのがいかがでしょうか？という提案をするnoteです。 ■ このnoteで解決できるかもしれない課題 ・プロダクトが解決すべきIssueが多すぎて優先順位付がむずかしい ・PBL(=プロダクトバックログ)の優先順位に納得感がない、または、PBLに入っているアイテムに納得感がない ・抽象的なプロダクトの
【TypeScript】React.VFCとは何ぞや - Qiita
はじめに ReactにHooksが導入され、最近ではFunction Componentを採用することがほとんどになってきたように思います。 Function Componentを定義するための型としてReact.FCが提供されているのですが、いくらかのデメリット（というより使う必要のなさ）があり、敢えて使っていないプロジェクトも数多く存在しています。 そんな中、デメリットを少し解消したReact.VFCが生み出されていたため共有します。 React.FCとは 先述したとおりFunction Componentを定義するための型で、以下のように使用します。 interface Props { hoge: string; } const Component: React.FC<Props> = (props) => { return ( <div> <p>{props.hoge}</p> <
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
開発爆速化を支える経営会議や週次定例の方法論 〜LayerXの透明性への取り組みについて〜 - LayerX エンジニアブログ
こんにちは。松本(@y_matsuwitter)です。GWはカレーを沢山作っていました。スパイスから作るカレー、思ったよりも手間が掛からないですね。インド料理にハマる波が数年置きにやってきます。 本日は、最近いくつかのイベントでの議論を通じて感じた、開発組織づくりにおいて見られる共通のパターンについて触れつつ、LayerXが意識している取り組みを書いてみようと思います。 最近toBなスタートアップ各社と会った中で、組織の指向性に色々と共通の傾向が見られる気がする。 ・透明性への狂気的な取り組み、公開だけでなく情報整理とチャネル整備 ・採用は技術力そのものよりもカルチャーフィットと学習意欲（もちろん両立が理想だけども） ・開発では速度を最も意識— 松本 勇気 | LayerXはSaaSとFintechの会社です (@y_matsuwitter) 2021年4月22日 各社で見られる最近の組織
リファラル採用のひみつ〜社員数100名・リファラル率70%のUbieがやっていること〜｜sonopy@Ubie
こんにちは、Ubie Discoveryでカルチャー開発をしている sonopyです。 Ubieではリファラル採用に力を入れており、リファラルでの入社率は現在72％です。 この記事では、100名規模でリファラル70%の組織がリファラル採用を増やすために考えてきたことや施策など、内情をご紹介します。「どうしたらリファラル採用を増やせるか？」と考えている方にとって、参考になったら嬉しいです。 ※Ubieは2つの組織に分かれています。この記事では発見・探索をミッションとする「Ubie Discovery」について紹介しています。 私たちはGoogleではない。「紹介してください」では紹介してもらえない。 私たちUbieは、ほとんど無名の医療系スタートアップです。 こんなことを言うとGoogleの方に怒られるかもしれませんが、もし私たちがGoogleだったら、知人を誘うのにさほど特別な理由は要りま
野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘
システム開発が大幅に遅延し、サービス計画が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。2019年3月の一審東京地裁判決では一部の請求を認め、日本IBMに約16億円の支払いを命じた。 だが、2021年4月21日の控訴審判決で東京高裁（野山宏裁判長）は一審判決を変更し、野村側の請求を棄却した。なぜ一審判決が覆され、野村2社が逆転敗訴となったのか。約90ページに及ぶ判決文から控訴審判決の経緯を読み解く。 プロジェクト遅延の原因は野村側と認定 訴訟の対象となったシステム開発プロジェクトの始まりは2010年。野村2社は、個人が資産運用を証券会社に一任する金融サービス「ラップ口座」向けフロントシステムの開発を日本IBMに委託。スイスの金融系ソフト大手テメノス（Temenos）が開発したパッケージソフト「Wealth Manager」
Serverless Framework & DockerによるローカルフレンドリーなLambda開発・運用
会社のチームメンバーにLambdaの開発・デプロイ方法について共有するために書いた記事ですが、Lambdaを触ったことない人にも有益そうな内容なので、Zennに投稿してみました🙏 今回作りたいLambda 指定したS3バケットに画像がアップロードされたら、リサイズして同じまたは別のS3バケットにアップロードする 完成リポジトリ https://github.com/samuraikun/image-resizer-lambda-serverless Runtime Ruby2.7 前準備 AWSアカウントが作成済み、AWS CLIインストール済み アクセスキーIDとシークレットアクセスキーを事前に設定する必要あり Serverless Framworkについて Lambdaをデプロイするまでに必要な各設定を簡単にできるツールです。 他にも、AWS公式のSAMやTerraformなど他のl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
