株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) 働いていると、複数のチームを横断したり、会社全体で「これやりたいな」と思うことがあります。 対象の組織規模が大きくなればなるほど難しくなりますが、 自分のやり方は一貫しているので、それを書いてみようと思います。 ザックリとして流れの説明 1. 勝ち筋を見出す 2.ステークホルダーを確認する。 3. やりたいことをドキュメント化する。 4. ステークホルダーにレビューしてもらう。 ポイント1. レビュー期限を決めること ポイント2. レビューしない人は同意したとみなす ポイント3. 決定事項ではないことを明示する ポイント4. 必要に応じて同期的に共有する 5. 自らオーナーシップを持って進める 補足: "Disagree & Commit" を徹底できない組織は "詰み状態" 補足: こーゆー動き自体を部下
この記事は、CYBOZU SUMMER BLOG FES '25 の記事です。 こんにちは、新卒フロントエンドエンジニアの mehm8128（めふも） です。 今回は、サイボウズのフロントエンドエンジニアが普段どのような探究活動をしているか、まとめてみました。 本記事は以下の 3 部構成になっています。 Frontend Weekly フロントエンド探求共有会 探究活動についてインタビュー結果 それでは 1 つずつ紹介していきます。 Frontend Weekly まずは毎週おなじみ Cybozu Frontend Weekly です。 zenn.dev 僕も内定者アルバイト期間に 3 回ほど書かせてもらい、正社員として入社後も定期的に書いています。 毎回記事の最初に書いている通り、毎週火曜日に「一週間の間にあった（実は少し前のものでも可）フロントエンドニュースを共有する会」を 1 時間行
こんにちは。株式会社LayerX バクラク事業部 QAチームのteyamaguです。 私たちはバクラク事業部で、複雑なtoB向けSaaS開発において、品質保証と開発速度の両立を常に追求しています。以前からテストの重要性は認識しつつも、プロダクトや組織の拡大に対し、体系だったテストピラミッドの概念は明確には定義されていませんでした。その結果、現場でのテスト実装時に迷いが生じたり、ツール整備が組織横断で進めにくいという課題がありました。 この状況を改善すべく、私たちはバクラク事業部独自のテストピラミッドを、私のようなQAエンジニアと開発エンジニアが協力して定義しました。具体的な定義の内容については以前書いたブログである「バクラク事業部のテストピラミッド設計」 をご覧ください。また、定義に至るプロセスにご興味のある方は、2025年5月9-10日の「Scrum Fest Niigata 2025」
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書いた動機 なんとなくエンジニアの面接官が求めている情報と面接者の提供する情報にズレを感じることがあるなーと思っているので書こうかなと。 自己PRが上手くなくて損してしまうのはエンジニアとしては本分では無いかなと思うので、そのあたりがうまくない人はしっかり準備が出来たらいいなと。 あなた誰？ 某Web系上場会社に勤務するエンジニアです。 基本は現場で働いていますが、採用面接などは人事と一緒に現場エンジニアの一人として出たりします。 採用面接歴は２年以上。 注意事項 現在の会社の立ち位置から見た場合での限定した方向から見た場合の
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから５年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは？と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた
来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は
Rust 🦀 and WebAssembly 🕸 This small book describes how to use Rust and WebAssembly together. Who is this book for? This book is for anyone interested in compiling Rust to WebAssembly for fast, reliable code on the Web. You should know some Rust, and be familiar with JavaScript, HTML, and CSS. You don't need to be an expert in any of them. Don't know Rust yet? Start with The Rust Programming Lang
これは Kyash Advent Calendar 2024 1日目の記事です。 2022年1月から VP of Engineering という役割でKyashの開発組織全体のマネジメントを始め*1、2024年1月から 執行役員 VP of Engineering になり1年くらい経ちました*2。 当初は「今までどおりいいプロダクトを作っていけるように行動していくだけだし大きくは変わらん」と思っていたのですが、想像以上に変化もあったので備忘として残しておきます。 ここに書ききれないこともたくさんあります。「1年近くやってこんな抽象的なことしか書けないのか」と感じられるかもしれませんが、まああまり背伸びせず反省も込めて今のスナップショットをそのまま書くことにします。 結果として事業はよくなっている Kyash のようなカード発行型の決済サービスというのは、決済単体の収益性で見ればいわゆる "
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
最近、Webエンジニア界隈で、共通項を感じる印象的な出来事があった。具体的には以下の2件。 ゆーすけべーがHonoを作ったこと Hono - ゆーすけべー日記 おぎじゅんさんが職業プログラマーに戻ってきた(きていた)こと 転職してソフトウェアエンジニアをやっている 猫廼舎を閉店しました 共通項はそれぞれ長めのブランクがありながら、ソフトウェアエンジニアリングの世界に戻ってきて一線級以上の活躍をしているということだ。二人とも僕と同世代かそれ以上の年齢でもある。これは勇気と希望をもらえることだ。 もちろん彼らの能力の高さゆえに第一線に戻ってこられたのかもしれない。ただ、どちらにせよ、別のことに興味があれば、職業エンジニアを離れて、フォーカスする期間があっても良いと言うことだ。能力不足ならなおさら中途半端になるよりフォーカスしたほうが良いとも言える。 それに多分戻ってこられる。ゆーすけべーの様に
「TypeScriptではじめる型システム」という記事をn月刊ラムダノートに寄稿しました。 新刊を発売しました "『n月刊ラムダノート』Vol.4 No.3（2024）発行のお知らせ https://t.co/PGppk1aRRA— lambdanote (@lambdanote) 2024年10月4日 どんな内容？ TypeScriptの極小サブセットに対する型検査器を書き、それを通して型システムを体感してみよう、という内容です。 詳しく言うと、boolean型とnumber型と関数型しかないTypeScriptサブセット言語がターゲットです。 型検査器の実装言語にもTypeScript（処理系はDeno）を使います。 TypeScriptづくしの一品です。 わかる人向けに言うと、「型システム入門」という本（通称TAPL）の単純型付きラムダ計算に相当する内容をTypeScriptで説明し
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
これは何4月。人事異動、新卒入社、中途入社など、様々な要因で職場環境を新たにし、新天地で頑張っている社会人の方が1年で最も多くなる季節かと思います。 このnoteでは、今まで新天地に臨む側だった私が、迎え入れる側に立ったときに感じた気持ちを率直に綴ったものです。 新天地で頑張っている人へのメッセージ結果が欲しい、そんな焦る気持ち、とても共感できます。私もそうでした。焦って、空回りをして、結果が出なくてまた焦って。悪循環が引き起こってしまい、自分の能力はなんて低いのだろうと自分に勝手に失望しての繰り返しでした。周りを見れていないことも多々ありました。 ただ、いざ迎え入れる側に回ってみると、焦りながらも頑張っている人をとても好意的に見ていて、力になろうと思う人がなんと多いことでしょうか。周囲は味方だらけです。もし、うまくいっていないと感じる人がいたとしたら、少しだけ周りの人にその気持ちを打ち明
Hey! This is an excerpt from my book Designing Products People Love, which was published by O'Reilly in January 2016. Learn more about the book and the 20+ product designers from Facebook, Twitter, Slack, etc. who were interviewed about how they work. Have you ever experienced a user interface that feels lifeless? Have you created a UI that just seems to be missing...something? If that's the case,
Summary: There are 3 main time limits (which are determined by human perceptual abilities) to keep in mind when optimizing web and application performance. Excerpt from Chapter 5 in my book Usability Engineering, from 1993: The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]: 0.1 second is about the limit for having the user feel that
Summary: From 0.1 seconds to 10 years or more, user interface design has many different timeframes, and each has its own particular usability issues. The user experience field has its own version of "Powers of Ten" (the classic 1968 documentary by Ray and Charles Eames). For us, it's not so much that things get 10 times bigger or smaller; most user interfaces are about the same physical size, as d
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く