shibukkのブックマーク (1,555)

  • 集めるノベルティ「SmartHRの増えてくアクキー」ができるまで|dose

    こんにちは。SmartHRのコミュニケーションデザイナーのdoseです。 この度、SmartHRの新しいノベルティができました! その名も「SmartHRの増えてくアクキー」です! SmartHRの増えてくアクキー(GIF)「増えてくって何?」 となるかもしれませんが、実はこのノベルティ、継続的に集めていけるノベルティなんです。 ロゴとキーホルダーの初期セットをベースに、そこから追加で約20種類(2025年4月時点)のオリジナルアクキーを増やしていくことができます。 今後、エンジニア向けカンファレンスやSmartHRが開催する採用イベントなどで継続的にお配りする予定です。 (まずは4/16-18で開催された、RubyKaigi 2025にてお披露目しました!) 増えてくアクキーの構成今回はこの「SmartHRの増えてくアクキー」がどのようにして生まれたのか、についてお話しさせていただければ

    集めるノベルティ「SmartHRの増えてくアクキー」ができるまで|dose
    shibukk
    shibukk 2025/04/22
    いいアイデアだなぁ
  • 最小コストで始める Slackを活用したお問い合わせ対応 - tebiki_techblog

    はじめに はじめまして。QAエンジニアの佐藤です。 最近、社員数が増え始め、”佐藤”さんが増えてきました。 私が所属している開発チームでユニークなあだ名をつけていただいたものの、日常で呼ばれたことはありません。 あだ名って難しいですよね。 今回は、私が入社して2ヶ月目から取り組み始めたお問い合わせ対応の改善についてお話します。 当初からお問い合わせフローを検討していたのではなく、インシデントフローの改善に着手する中で、別途お問い合わせフローも検討したいと思うようになったことがきっかけでした。 お問い合わせ対応はフローが決まっていない状態だったので、まずは運用に乗せられるか不安もあったため小さく始めることを意識しながら検討を始めました。 課題の整理 まずは現状の把握と課題の整理を行いました。 PdM(プロダクトマネージャー)にヒアリングしてわかったことは以下のとおりです。 ユーザーからのお問

    最小コストで始める Slackを活用したお問い合わせ対応 - tebiki_techblog
    shibukk
    shibukk 2025/04/21
  • 情報は“並べる”のではなく、“構造化”する─B‑H‑Dフレームが組織のリードタイムを短縮する。|nishiba

    はじめに:非同期コミュニケーションの増大と組織課題リモートワークやハイブリッドワークに関係なく、オフィスワークであってもSlack・メール・Notion・Teams など、非同期コミュニケーションに頼る機会が格段に増えている。実際に、オフィスにいたとしても非同期のテキストコミュケーションが多い。 だが、こうした非同期の便利さと引き換えに、いくつかの課題が顕在化するようになった。まず挙げられるのは、メッセージの往復回数の増加だ。オフィスで雑談まじりに「これどうなってる?」と聞けば一瞬で解決したかもしれない問題が、Slack のメッセージを投げても相手が離席していてすぐには返事が来ない――それだけならまだしも、投げかけが曖昧だったり、目的が十分に説明されていなかったりすると、数時間後に「それは何のデータが欲しいんですか?」と追加質問が返り、さらに数時間後にようやく詳細を伝え、やがてまた別の質問

    情報は“並べる”のではなく、“構造化”する─B‑H‑Dフレームが組織のリードタイムを短縮する。|nishiba
  • プロダクト開発の不確実性を下げるために意識している3つのこと - RAKSUL TechBlog

    はじめに こんにちは!ラクスルのエンタープライズ事業部でプロダクトマネージャー(以下、PdM)をしている平光です。 ラクスルアドベントカレンダーの19日目を担当します。 簡単に自己紹介します。 ラクスルに新卒で入社して、現在6年目になります。学生時代に、LPO/CVR改善のSaaSにて営業・マーケティングのインターンを行った後、Edtechの会社でエンジニアとしてインターンをし、ラクスルに入社しています。ラクスルでは、ECやサプライチェーンマネジメント(以下、SCM)など、様々な領域でPdMを行ってきました。 今は、エンタープライズ事業部にて、ラクスルを大企業・中堅企業の方にも利用していただくことを目的に、事業開発およびプロダクト開発をしています。 エンタープライズ事業の紹介 現在、ラクスルでは大企業・中堅企業向けのサービスとして ラクスル エンタープライズ を提供しています。決算説明会資

    プロダクト開発の不確実性を下げるために意識している3つのこと - RAKSUL TechBlog
    shibukk
    shibukk 2025/04/17
  • 悩まないチームのつくりかた - RAKSUL TechBlog

    ラクスル事業部エンタープライズ開発グループの宮田です。 今回はエンタープライズ開発グループの最近のチーム運用についてご紹介したいと思います。 ラクスル エンタープライズ エンタープライズ事業は、ラクスル印刷事業の大企業向けの EC プラットフォームです。 安い・早い・ラクといったラクスルの強みを活かした上で、大企業のユースケースに合わせてデザイン管理・承認ワークフローなど、業務効率化に繋がる機能を提供しています。 近年はラクスル EC サイトの横軸展開を行い、クロスセルの増加を狙うなど、顧客価値にフォーカスした開発が多いのが特徴です。 多様な業界の顧客要望に応えるため、新機能のデリバリーにもスピードが求められるエンタープライズ開発グループですが、発足以来約 3 年間で導入企業 1300 社、事業部として過去 1 年間で 2 度の月次社長賞受賞、1 度の全社四半期社長賞受賞と、幸いなことに事

    悩まないチームのつくりかた - RAKSUL TechBlog
    shibukk
    shibukk 2025/04/17
  • The Best Programmers I Know | Matthias Endler

    I have met a lot of developers in my life. Lately, I asked myself: “What does it take to be one of the best? What do they all have in common?” In the hope that this will be an inspiration to someone out there, I wrote down the traits I observed in the most exceptional people in our craft. I wish I had that list when I was starting out. Had I followed this path, it would have saved me a lot of time

    The Best Programmers I Know | Matthias Endler
  • 「センスがない」と突き放す前に。戦略的にチームで意思決定の質を高めるコミュニケーション術 | レバテックラボ(レバテックLAB)

    「センスがない」と突き放す前に。戦略的にチームで意思決定の質を高めるコミュニケーション術 2025年4月8日 プロダクトマネージャー 小城 久美子 プロダクトづくりの知見の体系化を試みるプロダクトマネージャー。書籍『プロダクトマネジメントのすべて』共著者であり、日最大級のプロダクトづくりコミュニティ「プロダクト筋トレ」の主催者。ソフトウェアエンジニアスクラムマスターなどの開発職を経験後、プロダクトマネージャーに転身し、現在は現場でのプロダクトマネジメントの傍ら、プロダクト戦略の構築や仮説検証の伴走を実施している。 プロダクトマネージャーとして働いていると、相手の提案に対し、「それは絶対に違う!」と反射的に思うことがあります。この、直感的に「ユーザーにとって価値のあるプロダクトはそうではない」と気づき、論理的に説明する能力は、一般的に「プロダクトセンス」と呼ばれています。 keyboar

    「センスがない」と突き放す前に。戦略的にチームで意思決定の質を高めるコミュニケーション術 | レバテックラボ(レバテックLAB)
    shibukk
    shibukk 2025/04/08
  • 悪いのは全部 Eve だと思ってた | blog.jxck.io

    Intro いつもブログを読んで頂いている皆様、そしてセキュリティ関係者の皆様へ。 この度は、筆者による "Eve" に対する不適切な引用、および、原稿内における不名誉な扱いについて、この場を借りて謝罪させていただきます。 Alice と Bob ネットワークやセキュリティ系の解説の中で、プロトコルの送受信を二人の対話構成になぞらえる場合、一方を Alice、もう一方を Bob とする通例があります。 その構成は、業界では長くこの通例が使われており、私的な文書から現場実務まで、あらゆる文書で Alice と Bob は対話を重ねて参りました。 この二人の会話の間で、ひっそりと盗み聞きしている存在が「Eve」です。 C (Charlie), D (Dave) を飛ばしていきなり Eve が登場するのは、盗聴を意味する Eavesdropper に由来していることと、Charlie と Da

    悪いのは全部 Eve だと思ってた | blog.jxck.io
    shibukk
    shibukk 2025/04/01
  • 組織図に対するさまざまな要求と現在地 - LayerX エンジニアブログ

    こんにちはまたはこんばんは、バクラク事業部 Platform Engineering 部でID基盤などを管理するチームに所属してあれこれやっている id:convto といいます。 認可などに関連することからバクラクでも「組織図」と表現されるリソースを弊チームで管理しているのですが、今回はその組織図についてお話しします。 この記事で取り扱う組織図リソースについて この記事で「組織図」と表現されるものは、組織の階層をあらわす木構造と、それぞれのチームの従業員所属情報などを管理するリソース全体を指します。 よくある例を簡易的な図で示します。 組織図の例 各社に合わせた情報統制を実現しようとしたとき、組織図は重要な情報です。この組織図をベースにたとえば「あるチームに所属していたらある申請を承認可能にしたい」や、「上位部門に所属している場合はそれ以下のチームに関連するリソースを閲覧可能にしたい」な

    組織図に対するさまざまな要求と現在地 - LayerX エンジニアブログ
    shibukk
    shibukk 2025/03/31
  • エンタープライズ企業へのPMFの作り方 - SaaSベンチャーで働く社員のブログ

    エンタープライズ市場でPMF(プロダクト・マーケット・フィット)を達成することは、SaaS企業にとって大きな挑戦です。 特に「一定の顧客がいるが、なかなか利用が広がらない」「契約は取れるが、継続利用されない」といった課題を抱えるフェーズでは、顧客がプロダクトを深く活用し、全社導入へとつながるか が成功の鍵になります。 記事では、日のエンタープライズ企業(単体従業員数1000人以上、約4000社) に向けたPMF戦略を解説します。 エンタープライズ市場では、「導入社数」ではなく 「1社あたりの利用拡大」 がPMFの質になります。 売れるだけでなく、使われ続けるプロダクトにするためにはどうすればいいのか を、具体例を交えながら考えていきます。 エンタープライズPMFの定義と「ユースケースの束」 SMBではユースケースが会社ごとに分かれる エンタープライズでは「ユースケースの束」が求められ

    エンタープライズ企業へのPMFの作り方 - SaaSベンチャーで働く社員のブログ
    shibukk
    shibukk 2025/03/31
    すばらしい言語化だ エンタープライズ向けのプロダクト開発に携わるすべての人に読んでほしい
  • PdMの本質的なスキルは「チームをその気にするスキル」(副題: いつも心にナウシカを)|柳川慶太

    PdM質的なスキルは「チームをその気にするスキル」だなと言う言葉を思いついたので、その心を言語化してみます。 抽象化するのが好きなんです。 お付き合いください。 PdM質的なスキルってみんなをその気にするスキルだと思う 出来るよってことを色々な手段で伝えてその気になってもらうスキル 油断すると出来ないって思っちゃうものなのだし、出来ないかもに引っ張っていかれるものなんだよね — 柳川慶太@BASE BANK (@gimupop) March 5, 2025 その気にするとは「出来るということを色々な手段で伝える」と言うこと世の中にはさまざまなプロダクトマネジメントにまつわる手法があります。 どれもこれも役に立つと思います。役に立つんですが、なんのためにその手法があるのかを念頭に置くことは大事です。 今回はあえて言い切ります。 プロダクトマネジメントのさまざまな手法は結局のところはチ

    PdMの本質的なスキルは「チームをその気にするスキル」(副題: いつも心にナウシカを)|柳川慶太
    shibukk
    shibukk 2025/03/27
  • 「走れない優秀な人」にならないためのゾスという考え方|farigyu

    仕事上司から曖昧な指示を受けてモヤモヤしたり、「それって当にうまくいくの?」と不安になった経験はありませんか? 実は自分自身、以前は「もっと具体的に言ってよ!」と心の中で叫んでしまうタイプでした。相手が自分のコミュニケーションの土俵に乗ってくれないと、どうしてもモヤモヤしてしまうんですよね。 イワヤンさんの話を聞いて考えたこと そんな中、最近YOUTRUSTのイワヤンさんのお話を聞く機会があり、「ゾス」というキーワードに出会いました。 イワヤンさんのお話のポイントは、「賢くて走れる人がもちろん良いが、まず重要なのは自ら意思を持って走れる人が強い。一番厄介なのは賢くても走れない人(=シャニカマ)。だからまずは走ろう」というものでした。 自分も割と体育会気質ではあるので「ゾスって大事だよな」と直感的に共感したものの、もし誰かに「ゾスってなぜ大事なの?」と聞かれたら、自分の言葉でうまく説明で

    「走れない優秀な人」にならないためのゾスという考え方|farigyu
    shibukk
    shibukk 2025/03/27
  • そのエンジニアリングで、製造業を変えてほしい - tebiki_techblog

    Tebiki で CTO をしています渋谷(@shibukk)です。 かれこれ 7 年くらい今の事業をしてきて、これまでいろいろな方とお話しをしてきました。 そこで感じてきたのが、製造業の現場は遠い世界だと捉えられているが、実はエンジニアも情熱を注ぐ価値が十分にある分野なのだ、というのが伝えきれていないのではという思いでした。 カジュアル面談などの短い時間では、自分の考えをしっかり話せていないことが多く、テキストでならうまく伝わるんじゃないかなと思っています。 ぜひ最後までお読みいただき、みなさんに未来の働き方を少しでも考えていただければ幸いです。 1. 日の製造業の強みと歴史的背景 2. 製造業が日経済に与える影響力 実績から見る国内への影響力 実績から見る国際的な影響力 3. 日の製造業における労働生産性停滞の要因 「カイゼン」による部分最適の限界 多品種少量生産の複雑性 部署間

    そのエンジニアリングで、製造業を変えてほしい - tebiki_techblog
    shibukk
    shibukk 2025/03/26
    プロダクトを通じて感じている、製造業の未来について書きました!
  • 1on1を劇的に改善!エンジニアの成長を加速する対話のコツ

    まずは自己紹介 ナレッジワークでエンジニア組織の仕組み作りなどを担当しているsedoと申します。 Enablement Groupという部署に所属していて、社内のプロジェクト管理の仕組みを整えたり、社外への情報発信イベントの運営サポートなどをしています! 前職は、ヤフー(現LINEヤフー)に所属しており、そこでEMエンジニアリングマネジャー)を担当していました。 ヤフーといえば1on1に力を入れていて、自分もたくさんの1on1を経験し、そこで学んだことの一部をこの記事に書いていきます。 1. こんな1on1になってませんか? 1on1、ちゃんと活用できていますか? 「とりあえず定例だからやってるけど、結局何を話せばいいのかわからない…」 「仕事の進捗確認だけで終わってるなぁ…」 「雑談してるだけで、成長につながってる気がしない…」 こんな悩み、あるあるですよね。 1on1は貴重な時間なの

    1on1を劇的に改善!エンジニアの成長を加速する対話のコツ
  • プロダクト開発に必要なもの全部繋げたらCursorが最強のプロダクトマネージャーになった|田口 信元

    Ubie株式会社で病気のQ&Aのプロダクトマネージャー(PdM)を務めている、田口(@guchey)です。 Cursorをプロダクトマネジャーが活用する記事を見て、自分もプロダクトマネジメント業務の中心をCursorにしてみることにしました。 威力すごい。各所にあった知識を集約した結果、自分の認知限界を超える相棒になりました。 現在のスプリント、バックログアイテム、OKR、ユーザーストーリー、主要メトリクスを把握したAIは、プロダクトの現在地から未来の姿まで詳細に把握したAIプロダクトマネージャーだった。 ディレクトリ構成今はこんな構成にしています。 cursor_pdm/ ├── .cursor/ # Cursor AI 用の設定ファイル │ ├── mcp.json # MCP設定ファイル │ └── rules/ # Cursor AIルール │ ├── 000_general.md

    プロダクト開発に必要なもの全部繋げたらCursorが最強のプロダクトマネージャーになった|田口 信元
  • 不確実性を抱えた状況でのリリースの難しさ - tebiki_techblog

    ※この記事は 2025年03月12日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 はじめに どれだけテストをしても100%の信頼性は保証できません。であればリリースする前に担保すべき品質って何なんでしょうか。そもそも担保することが難しい場合、リリースをして良いのでしょうか。リリース可否の判断にはなかなか難しいものがあります。 今回私も、入社してひと月も経たぬうちにそんな課題に直面し、いろいろと回り道をしながら学びを得たので、今回はその内容についてお話したいと思います。 最初の業務 Tebiki株式会社の高橋です。2024年9月にQAエンジニアとして入社しました。入社オンボーディングも終わりQAとして格的に活動し始めようとした矢先、動画変換基盤の安全なリリースという課題に直面しました。 件に

    不確実性を抱えた状況でのリリースの難しさ - tebiki_techblog
    shibukk
    shibukk 2025/03/12
  • GMO Flatt Security Top 10 - 2025年版 - GMO Flatt Security Blog

    はじめに こんにちは。GMO Flatt Security株式会社の @toyojuni です。 弊社は "エンジニアの背中を預かる" をミッションにさまざまな開発組織のセキュリティをサポートしていますが、その主たるサービスがWebアプリケーション・Web APIの脆弱性診断です。今回、この脆弱性診断サービスの中でお客様に報告した1000個以上の脆弱性データをもとに、検出数ランキングの形でそのリスクの実態を分析しました。 同様にWebアプリの脆弱性を分析したものとしてはOWASP Top 10が世界的に有名ですが、グローバルでの分析結果となると日企業の実態にそのまま当てはまるとは限りませんし、自分ごととして考えづらい面もあると思います。 そこで今回は、日企業のWebセキュリティのリアルなリスクをお伝えすることを目的に、独自調査レポート「GMO Flatt Security Top 10

    GMO Flatt Security Top 10 - 2025年版 - GMO Flatt Security Blog
    shibukk
    shibukk 2025/03/03
    日本にこういう企業がいてくれてめちゃくちゃありがたい
  • 今、Bill Oneで働く魅力 - Sansan Tech Blog

    VPoE 兼 インボイス管理サービス「Bill One」のプロダクト開発責任者の大西です。Bill Oneには長らくプロダクト開発責任者として関わってきましたが、しばらく別のことをやっていました。今回2年ぶりにBill Oneを担当することになったため、「今、Bill Oneで働く魅力」をお伝えしたいです。 1. 市場を変えるプロダクト 従来の請求書SaaSは、主に「請求書を発行する」サービスが中心でした。しかし、Bill Oneは「請求書を受領する」SaaSの先駆けとして誕生し、市場そのものを創る挑戦でした。 請求書には「送られたものを受け取る」という特性があります。発行側が紙の請求書を送り続ける限り、受領側の企業がデジタル化を進めたくてもなかなか進められないという課題があり、市場全体のデジタル化が進みにくい状況でした。 Bill Oneはこの課題を解決するために、発行企業の手間を変えず

    今、Bill Oneで働く魅力 - Sansan Tech Blog
  • 優秀なエンジニアの定義は曖昧だが、際立って成長する人々に共通する特徴としてあることが挙げられる「その種の思考力は筋力みたいなもの」

    nao1 : 人生ダイエット中‼️92kgからどこまで落ちるか @northpoint77 とっても同意。理解するのってめちゃ疲れる。ただ使うだけなら理解はいらない。でも、ちゃんと理解しないと、変な使い方になっていたり原理わかってないので、ちょっと特殊なケースになると頓珍漢なことを言う人になっちゃう。 x.com/nwiizo/status/… 2025-02-21 00:29:49 T's-Neko(プログラマー) @Ts_Neko これはざっくり言うと、必要条件と負事例的十分条件などをいくつも組み合わせて、概念を適切な範囲に調整すること。 これが分からないと概念を教えるのは難しく、教える相手がバカに見えるが、実は教える側がバカというやつ。 x.com/nwiizo/status/… 2025-02-20 05:39:39

    優秀なエンジニアの定義は曖昧だが、際立って成長する人々に共通する特徴としてあることが挙げられる「その種の思考力は筋力みたいなもの」
    shibukk
    shibukk 2025/02/22
  • アーキテクチャの変更をどうやって完遂するか - 10X Product Blog

    既存のアーキテクチャの問題が見えると、アーキテクチャを変更して解決すると思います。 それ自体は素晴らしいことなのですが、変更が全体に浸透し切らず古いアーキテクチャと新しいアーキテクチャが混在したままになってしまうと、状況はさらに悪化します。そのため、アーキテクチャを変更する時には、「どうやって完遂するか」もセットで考えるべきでしょう。 10Xの現状は? 混在しています。 自然と移行を完遂できる日は来なかったので、完遂する努力をしています。 完遂するための取り組み アーキテクチャの限界を漸進的に押し上げる取り組み で紹介した通り、10Xでは 以下の4ステップのサイクルを回してアーキテクチャを改善しようとしています。 欲しい特性を狙ってアーキテクチャ決定を積み重ねる ADRでアーキテクチャ決定の意図を明確にする linterADRに辿り着けるようにする ADRへの違反状況を可視化して漸進的に

    アーキテクチャの変更をどうやって完遂するか - 10X Product Blog
    shibukk
    shibukk 2025/02/14
    わかりやすい