wafrelkaのブックマーク (137)

  • "提案"のレベルを上げる - Konifar's ZATSU

    組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」

    "提案"のレベルを上げる - Konifar's ZATSU
  • 権限委譲しきれていない時に意識すべきこと - Konifar's ZATSU

    権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい

    権限委譲しきれていない時に意識すべきこと - Konifar's ZATSU
  • 意思決定できる人の手順の型 - Konifar's ZATSU

    意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

    意思決定できる人の手順の型 - Konifar's ZATSU
  • About - Rust API Guidelines

    This is a set of recommendations on how to design and present APIs for the Rust programming language. They are authored largely by the Rust library team, based on experiences building the Rust standard library and other crates in the Rust ecosystem. These are only guidelines, some more firm than others. In some cases they are vague and still in development. Rust crate authors should consider them

  • Lessons from Writing a Compiler

    The prototypical compilers textbook is: 600 pages on parsing theory. Three pages of type-checking a first-order type system like C. Zero pages on storing and checking the correctness of declarations (the “symbol table”). Zero pages on the compilation model, and efficiently implementing separate compilation. 450 pages on optimization and code generation. The standard academic literature is most use

  • おい、辞めるな - じゃあ、おうちで学べる

    はじめに かつての私は、深夜2時にベッドの中で転職サイトを開いていた。 開いて、求人を眺めて、閉じて、また開く。そういうことを繰り返していた。辞めたいのか、と聞かれると困った。会社の限界が見えたのか。自分の天井が見えたのか。それとも、隣の芝生の青さに目が眩んでいただけなのか。たぶん、全部だった。たぶん、どれでもなかった。 今は、転職を考えていない。 これは「今の会社が最高だから」という話ではない。どんな会社にも良い面と悪い面がある。不満がゼロになることはない。ただ、深夜に転職サイトを開く衝動は、いつの間にか消えた。何が変わったのか。環境が変わったのか、自分が変わったのか。たぶん、両方だ。 「エンジニア転職年収が上がる」「成長できる環境に身を置け」——そんな言葉がタイムラインに流れてくる。転職エージェントからのスカウトメールは週に何通も届く。カジュアル面談のお誘い。年収アップの可能性。も

    おい、辞めるな - じゃあ、おうちで学べる
  • 1Password と遺言保管制度を用いたデジタル終活 | blog.jxck.io

    Intro 筆者のように、インターネット上での生活が長く、かつエンジニアとして生きてきた人間には、一般の人には伝わりにくいデジタルの遺品が多く存在する。 仮に自分が死んだ場合に、これらをどのように遺族に処分してもらうかは、なかなか難しい問題だ。筆者はこの「デジタル終活」をどうするかを、長いこと模索してきた。 今回は、「1Password」と法務局が行う「自筆証書遺言保管制度」を用いた方法を思いついたため、検証を試みる。 注意 筆者はエンジニアであり、法律の専門家ではない。 方式は、法的に有効な遺言の作成については範囲外である。 方式の目的は、「遺族の負担を減らす」ことである。 ここで「デジタル 遺品」とは以下のようなものを指す。 自分が使ってきたメールアドレスや SNS のアカウント 取得しているドメイン 登録しているサブスク 管理しているコミュニティや OSS etc. 以下のような

    1Password と遺言保管制度を用いたデジタル終活 | blog.jxck.io
  • How I estimate work as a staff software engineer

    There’s a kind of polite fiction at the heart of the software industry. It goes something like this: Estimating how long software projects will take is very hard, but not impossible. A skilled engineering team can, with time and effort, learn how long it will take for them to deliver work, which will in turn allow their organization to make good business plans. This is, of course, false. As every

    How I estimate work as a staff software engineer
  • おい、辞めないなら頑張れ - じゃあ、おうちで学べる

    はじめに 先週、「おい、辞めるな」という記事を書きました。 syu-m-5151.hatenablog.com 思った以上に反響がありました。何人かから連絡をもらいました。辞めないことにしました、考えるきっかけになりました、と。ありがたかったです。嬉しかった、と言っていいです。たぶん。 ただ、何か落ち着きませんでした。辞めないと決めた。それは分かった。で、その次は。辞めないと決めただけで、何かが変わるわけではありません。私がそうだったからです。 辞めないと決めた後も、何も変わりませんでした。評価は上がらない。漠然としたモヤモヤは消えない。夜遅くまでコードを書いた。勉強会に参加した。資格を取った。ブログを書いた。技術力を上げれば認められる。そう信じていました。 評価は上がりませんでした。 振り返ると、私は頑張り方を間違えていたのです。もっと正確に言えば、評価の構造を理解していませんでした。良

    おい、辞めないなら頑張れ - じゃあ、おうちで学べる
  • Differences Between American and Japanese User Experience Design freshtrax - btrax blog

    User Experience (UX) Design is a design process used to make products, services, or systems easy for people to use. An important part of the UX design of a website is the user interface (UI) design, which helps the user interact with the site. UI is the look and feel of the product, service, or system. As the realm of digital experiences continues to grow, aesthetically pleasing user interfaces (U

    Differences Between American and Japanese User Experience Design freshtrax - btrax blog
  • 株式会社リクルート エンジニアコース新人研修の内容を公開します!(2025年度版) | リクルート テックブログ

    これらの目的の通り、配属先に関わる技術以外にも幅広いエンジニアリング技術を体系的に学ぶほか、事業理解やロジカルシンキング・活躍されている先輩方のナレッジ共有などヒューマンスキルについて学ぶ講義も用意されていました。 エンジニアリング研修については特に、入社前に行われたスキルアセスメントテストの結果を踏まえ、受講者の習熟度・理解度に合わせたクラス分けが行われていたため、アプリケーション開発の経験がない人でもレベルに合わせた講義を受けられる形となっていました。 また、各研修では講義でのゴールを明示的に共有いただくと共に「将来必要となった時のインデックスを貼り地図を作ることが重要」ということをお話がありました。 これは、学び続ける必要のあるエンジニア技術をキャッチアップし続けることにも通じると感じており、社会人としてのキャリアの早い段階でこの考えに触れられたのは、非常によい経験でした。 加えて

    株式会社リクルート エンジニアコース新人研修の内容を公開します!(2025年度版) | リクルート テックブログ
  • 日本で一番わかりやすくてためになる小さな飲食店の始め方 300万円でお店をやろう|林伸次

    たまにお客様から「お店でお酒を出すのって、何か免許はいるんですか?」とか「夜の12時をこえてお酒を出すのって風営法はどう関係しているんですか?」とか「お店を出すのに調理師免許がいるんですよね」とかって質問をされることがあるのですが、実は、日では、「品衛生責任者」という資格を持っているだけで小さい飲店は始められます。この「小さい」ですが、店内で店員の数とお客様を足してその数が30人までのことです。 ちなみに、僕がやっているbar bossaは席数は18席で、働いているのは僕1人だけなので、品衛生責任者の資格だけで大丈夫です。これで24時間、お酒も出せますし、焼き肉も刺身も出せます。 店内での店員数とお客様の数が30人以上の場合は防火管理者というのが必要です。 どちらも講習を受けるだけです。テストもないです。 品衛生責任者というのは、保健所に連絡して、「今度、飲店を渋谷でやろうと思

    日本で一番わかりやすくてためになる小さな飲食店の始め方 300万円でお店をやろう|林伸次
  • リクルートにおける Platform Engineering / SRE の事例共有

    2023/12/06に、 Platform Engineering Meetup で発表した菅沼の資料です。

    リクルートにおける Platform Engineering / SRE の事例共有
  • AWS Innovate にて内製データ基盤 Crois のプラットフォームエンジニアリングの取り組みを発表しました

    はじめに こんにちは。データエンジニアとして社内横断で使われるデータ基盤 Crois の開発を担当している青木です。 2024 年 9 月に開催された AWS Innovate - Migrate. Modernize. Build. にて、「リクルートのデータ基盤 Crois - 年 3 倍成長! 1 日 40,000 コンテナの実行を支える AWS 活用とプラットフォームエンジニアリング」というタイトルで発表を行いました。 汎用的なワークフローエンジン・ジョブスケジューラとして開発された Crois は、リクルートのデータ利活用の進化に伴い急速に利用が拡大しています。 その急成長を支えている要因として、AWS の活用・プラットフォームエンジニアリングの実践という 2 つの観点に着目しお話しさせていただきました。 記事では、その内容をご紹介します。 記事は、データ推進室 Advent

    AWS Innovate にて内製データ基盤 Crois のプラットフォームエンジニアリングの取り組みを発表しました
  • Selection controls — UI component series

    The word “toggle” is a reference to a switch with a short handle that alternates between two states each time it is activated. You encounter it every time you “switch” on the lights. As for “Radio Buttons” the word comes from the car radios that as common practice had a set of buttons under the dial that could mechanically store station presets, so the user switch between stations faster. Pressing

    Selection controls — UI component series
  • The anatomy of a button — UI component series

    In order to design the right interactions, we need to look back at the history and origins of physical pushbuttons, a direct predecessor of the UI component so heavily used in all digital products today. Buttons are amazing. The touch of a finger setting an appliance, a car, or a system in motion, even if the user doesn’t understand the underlying mechanisms or algorithms. In Power Button, Rachel

    The anatomy of a button — UI component series
  • Loading & progress indicators — UI Components series

    Loading and progress indicators are essential elements of UX/UI design that help users stay informed and engaged during waiting periods. Whether it’s loading a webpage, processing a transaction, or downloading content, well-designed indicators can significantly improve user experience. Among Jakob Nielsen’s ten heuristics, the visibility of system status takes precedence as the foremost and essent

    Loading & progress indicators — UI Components series
  • Text fields & Forms design — UI components series

    Forms have existed for a significant amount of time, greatly simplifying the task of drafting complaints and various other legal pleadings. With the advance of information and its processing, means to gather the data are also evolving. As printed forms were here for years we can learn a few tips from their design.

    Text fields & Forms design — UI components series
  • What do executives do, anyway?

  • Design doc所感

    Design Docsのいけすかなさから始まる一連の記事を読んで、やっぱりみんなDesign docで苦労しているんだなぁと思った。自分も仕事でDesign docを書いたり他の人が書いたものをレビューしたりするけど、文書を書いたり読んだりする面倒くささの割に得られるものが想像し辛かったり、読んでも結局何が言いたいのか分からなかったりして、当に意味があるのかどうか疑問に思うことが多かった。 Design docに関する自分の肌感覚はjmukさんの返信で言及されているものがかなり近い。抽象度の高いところほど後戻りし辛かったり、すれ違いが起きた時の手戻りが大きかったりして間違いが起きた時のダメージが大きいので、そういった箇所での認識をすり合わせできたり、自分の認識が甘かったところにツッコミを入れてもらえたりするとDesign docを書いた意味があったなと思う。逆に、細かい実装の詳細に関して