テストピラミッド定義がもたらした LayerX バクラク開発チームの変化と効能 - LayerX エンジニアブログ
こんにちは。株式会社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系上場会社に勤務するエンジニアです。 基本は現場で働いていますが、採用面接などは人事と一緒に現場エンジニアの一人として出たりします。 採用面接歴は２年以上。 注意事項 現在の会社の立ち位置から見た場合での限定した方向から見た場合の
見たいエンジニアの職務経歴書の書き方 - Qiita
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代でやってよかったことをまとめた - そーだいなるらくがき帳
来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は
Introduction - Rust and WebAssembly
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
執行役員になって1年くらい経ちました - Konifar's WIP
これは Kyash Advent Calendar 2024 1日目の記事です。 2022年1月から VP of Engineering という役割でKyashの開発組織全体のマネジメントを始め*1、2024年1月から 執行役員 VP of Engineering になり1年くらい経ちました*2。 当初は「今までどおりいいプロダクトを作っていけるように行動していくだけだし大きくは変わらん」と思っていたのですが、想像以上に変化もあったので備忘として残しておきます。 ここに書ききれないこともたくさんあります。「1年近くやってこんな抽象的なことしか書けないのか」と感じられるかもしれませんが、まああまり背伸びせず反省も込めて今のスナップショットをそのまま書くことにします。 結果として事業はよくなっている Kyash のようなカード発行型の決済サービスというのは、決済単体の収益性で見ればいわゆる "
意思決定できる人の手順の型 - Konifar's ZATSU
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
ソフトウェアエンジニアという人生の選択肢 | おそらくはそれさえも平凡な日々
最近、Webエンジニア界隈で、共通項を感じる印象的な出来事があった。具体的には以下の2件。 ゆーすけべーがHonoを作ったこと Hono - ゆーすけべー日記 おぎじゅんさんが職業プログラマーに戻ってきた(きていた)こと 転職してソフトウェアエンジニアをやっている 猫廼舎を閉店しました 共通項はそれぞれ長めのブランクがありながら、ソフトウェアエンジニアリングの世界に戻ってきて一線級以上の活躍をしているということだ。二人とも僕と同世代かそれ以上の年齢でもある。これは勇気と希望をもらえることだ。 もちろん彼らの能力の高さゆえに第一線に戻ってこられたのかもしれない。ただ、どちらにせよ、別のことに興味があれば、職業エンジニアを離れて、フォーカスする期間があっても良いと言うことだ。能力不足ならなおさら中途半端になるよりフォーカスしたほうが良いとも言える。 それに多分戻ってこられる。ゆーすけべーの様に
TypeScriptは型安全じゃないからすばらしい - まめめも
「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で説明し
抽象度の高い仕事の進め方 - Konifar's ZATSU
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
新天地で頑張っているけれど、なにかうまくいっていないと感じる人へ。｜numashi/LayerX バクラクVPoP
これは何4月。人事異動、新卒入社、中途入社など、様々な要因で職場環境を新たにし、新天地で頑張っている社会人の方が1年で最も多くなる季節かと思います。 このnoteでは、今まで新天地に臨む側だった私が、迎え入れる側に立ったときに感じた気持ちを率直に綴ったものです。 新天地で頑張っている人へのメッセージ結果が欲しい、そんな焦る気持ち、とても共感できます。私もそうでした。焦って、空回りをして、結果が出なくてまた焦って。悪循環が引き起こってしまい、自分の能力はなんて低いのだろうと自分に勝手に失望しての繰り返しでした。周りを見れていないことも多々ありました。 ただ、いざ迎え入れる側に回ってみると、焦りながらも頑張っている人をとても好意的に見ていて、力になろうと思う人がなんと多いことでしょうか。周囲は味方だらけです。もし、うまくいっていないと感じる人がいたとしたら、少しだけ周りの人にその気持ちを打ち明
How to fix a bad user interface
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,
Response Times: The 3 Important Limits Article by Jakob Nielsen
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
Powers of 10: Time Scales in User Experience
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
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダイジェスト
今考えているエンジニアの生存戦略について | F's Garage
BASE社のオフィスが最近増床しましてイベントスペース的な余裕がある今のうちにイベントをやろうということで、転職エージェントのアイムファクトリーさんとの共催でこんな話をさせていただきました。 この話を思い出したのは、まつもとゆきひろさんの素敵なお話の記事を読んだからでありまして、Ruby書いたことないけどRuby書いた人の講演に行った – みたぬメモ、おお、そういえば、俺も同じタイトルでしゃべってたなと、お恥ずかしながら共有させていただければと。 僕の場合は、どっちかというと普通の会社員として生きていくための生存戦略かもしれないですね。 スライドだけでどこまでご理解いただけるかは不明ですが。 むしろ、会場で質問をしていただける方々が多数いらっしゃいまして、そっちでの受け答えのほうが全然面白かったかなって個人的には思っています。 （あと、今思い出した。元Klab CTOの仙石さんのFaceb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.mhlw.go.jp/content/12200000/000799077.pdf
フロントエンドリアーキテクトの話
Using `var` in limited contexts to avoid runtime TDZ checks · Issue #52924 · microsoft/TypeScript
Agile Development Leadership
