先日、スクラムフェス福岡でこういう話をしてきました。 speakerdeck.com 特に国内ではここ1, 2年界隈を騒がせている "Four Keys" と呼ばれる4つの指標についての話で、乱暴に内容を一言でまとめるなら、「Four Keysをちゃんと使いたかったらまず出典の本を読もうぜ」というものでした。 元々、Four Keysとか、それを包含する「開発生産性」と呼ばれる分野の世間での使われ方に妙な違和感をずっと感じていたのでこういう話をしに行ったのですが、講演後に現地で議論したりとか、あとこの資料を公開した後の反響を見たりしていて、1つ気づいたことがありました。 それは、世の中でいう "Four Keys" に実は2つの意味があって、その2つがひたすら混同され続けているのでは ということでした。 その2つというのはこれ↓です。 デリバリのパフォーマンスを測る指標 組織のパフォーマン

TypeScript で DI (依存性注入) するためのライブラリを作ったんですが, それを紹介する前に既存手法をまとめておいた方が説明が楽だなと思ったのでまとめておきます. そもそも DI の目的とは, みたいなところは詳しく説明しないのであしからず. 手法の比較 DI なし Service Locator エフェクト Constructor Injection Setter Injection デコレータ typed-inject 次回予告 手法の比較 DI なし まずは DI を使わない場合を見ていきましょう. ここでは例として, 以下のような時刻と乱数を必要とするコンポーネント MyService が, 時刻と乱数を扱う機能をそれぞれ提供するコンポーネント Clock と Random に依存するような場合を考えます. type Clock = { getTime: () =>

2022年3月30日（水）に、 Hatena Engineer Seminar #19 をオンライン開催しました。ご参加いただいたみなさま、ありがとうございました。 このエントリーでは、当日のアーカイブ動画や公開資料をご紹介します。 Hatena Engineer Seminar #19 について 発表概要と資料 カクヨムの10年を見据えた技術 - by id:koudenpa インフラ編──AWSアカウントとIaaSの段階的移行── - by id:koudenpa グルーミングしながら進めるプロダクト開発 - by id:onk プロトタイプ編 - by id:k-murakami0609 フロントエンド編 - by id:mfzy デザイン編 - by id:takuwolog さいごに Hatena Engineer Seminar #19 について Hatena Engineer

Design thinking was supposed to fix the world. Where did it go wrong? When Kyle Cornforth first walked into IDEO’s San Francisco offices in 2011, she felt she had entered a whole new world. At the time, Cornforth was a director at the Edible Schoolyard Project, a nonprofit that uses gardening and cooking in schools to teach and to provide nutritious food. She was there to meet with IDEO.org, a new

RSGT2023での登壇資料です。 一つ前のWomen Developers Summit2022でお話した内容もまるっと含んだ改良版です。 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17445/2-is-there-chemistry-between-operation-work-and-scrum-path-of-trial-and-error-in-our-team-

※この記事は 開発生産性 Advent Calendar 2022 のカレンダー2の13日目の記事になります。 前回は1日目は hiroshinishio さんの 『より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標』 で、個人的には指標それぞれの分析や改善の方法が書かれていて勉強になりました。 こんにちは。 モノタロウで主に DevOps エンジニアとして活動している伊藤です。 休日はジムに節制した食事、サウナと健康を意識するおじさんとしても活動しています。 （最近だと渋谷の改良湯さんのサウナと外気浴スペースの具合が最高でととのいました） 今回は DevOps Four Keys*1 （以降 4keys と呼称） というソフトウェア開発チームのパフォーマンスを示す4つの指標を導入し、部門の目標として掲げたここ1年の取り組みを紹介できればと思います。 背景

わたしは未だに自分が「仕事ができない」感がある。いや、たぶん思い込みじゃなくて、本当にそうだと思う。周りと比べても意味はないのだが、明らかにプログラミングのスピードが遅いし、ソリューションや思考の精緻さに欠ける。アメリカのテックカンパニーの人員削減が盛んだしいつ首になってもおかしくないと思う。 「向いていない」エンジニアへのあこがれアメリカで自分がしたかったことは、今度こそ胸を張って「エンジニアです」といえるようになること。何かを作れる人間になること。これは今までの人生で一度もかなっていないことだ。だから、正直なところ「向いていない」と自覚している。 だから、自分と一緒に働いているVincentに聞いてみた。彼は私よりずっと若いけど仕事をしっかりできる。私よりずっとプログラミングも素早いしロジックをよく覚えているし、複雑なリファクタリングもこなせる。 同僚の要領を得ない回答　彼にどうしたら

弊社では React で CSS を書くための手法として CSS Modules を全面的に採用しています。そこで CSS Modules を使った開発をより快適にするために、「happy-css-modules」というツールを作りました。 happy-css-modules のデモ。 この記事ではこのツールが必要になった背景、導入方法、そしてツールの技術的な仕組みについて紹介します。 CSS Modules の問題点と、typed-css-modules による解決 CSS Modules では、デフォルトでは存在しないクラス名を使用しても、(プロジェクトの設定次第ですが) TypeScript のコンパイルエラーが出ることはありません。 import styles from './Button.module.css'; function Button() { return ( <but

July 12, 2022 How Google SRE and Developers Collaborate This post was adapted from the paper “How Google SRE and Developers Collaborate by Christof Leng, Tracy Ferrell, Alex Bligh, Michal Gefen, Betsy Beyer with help from Salim Virji from the Spring 2022 DevOps Enterprise Journal. Google’s Site Reliability Engineering (SRE) team is a specialist engineering organization focused on designing, buildi

みなさんこんにちは。kintone フロントエンドリアーキテクチャプロジェクト（フロリア）で、エンジニア兼スクラムマスターとして活動している村田（@kuroppe1819）です。 現在、フロリアには兼務も含めて約 30 人のメンバーが参加しています。フロリアは小さな 4 つのクロスファンクショナルチーム体制で、それぞれが独立したスクラムチームとして活動しています。 今回はその中のひとつのチームである、サイレントリリースを部分的に試みているチーム（Mira チーム）で取り組んだ、ソロプログラミング（以下、ソロプロ）とモブプログラミング（以下、モブプロ）を両立したスウォーミングの実践事例を紹介します。 スウォーミングとは？ まずはスウォーミングという言葉について説明します。 Swarming を直訳すると「群れる」です。ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するとい

こんにちは、アルプでQAエンジニアをしている nametake です。 アルプでは最近QAチームが発足し、QAエンジニアを募集しています。 QAエンジニアの業務範囲は広く、単純にQAエンジニアとだけ募集をしても外部から見てどういう働き方ができるのかイメージしづらいと思います。 そこで、JaSST等で紹介されていた QMファンネル をベースにしつつ、3ヶ月間専任でやってきて見えたQA業務を細分化し、それぞれ別の役職として整理してみました。 イメージが付きやすいように整理をしただけなので、これに完全に当てはまって欲しいというわけではないですが、もし転職を考えた際に自分のスキルや、やりたいことと合致する部分がありましたら候補に入れていただければと思います。 目指すチーム体制と、QAエンジニアの3つの働き方アルプでイメージできるQAエンジニアの働き方は3つあり、それぞれ以下のように名前をつけてみま

○郎系ラーメンを注文したつりだったのにトールバニラノン ファットアドリストレットショットチョコレートソースエクス トラホイップコーヒージェリーアンドクリーミーバニラフラペ チーノが出てきた話 〜ミスコミュニケーションが起こした悲劇〜

この記事の初出は、Software Design2022年3月号「設計方針から変えていく、モノリシックなアプリの過去と未来（最終回）」で、加筆修正されています。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog 第3回 Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog 第4回 Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Te

こんにちは。2022年1月に入社した1人目の社員QAエンジニアの須賀(@kawabeaver)です。なぜか息子に「かわちーばー（ビーバーのこと）」や「アマビエ様」と呼ばれています。 1人目のQAエンジニアとして入社したりQAエンジニアのいない開発チームに配属されたりすると、最初は何をやって良いか悩む方が多いのではないかと思います。私もその一人でした。そこで、私が1人目のQAエンジニアとして入社してから最初に行う品質向上施策を決めるまでのプロセスを紹介したいと思います。 現状の分析 既存メンバーへのヒアリング 現状のプロセスの把握 本番障害（市場バグ）の分析 施策の決定 パレート図 短期的に成果を出す 開発スピードを落とさない 成果と今後の展望 We are Hiring! 現状の分析 まずは課題の把握や施策の優先順位を決めるために現状を分析します。 既存メンバーへのヒアリング 何も仮説を持

Code improves with multiple reviews and revisions, and this process isn’t something that can be done alone. Spotting errors in code design is difficult at the best of times — and the closer you are to the work, the harder it can be to critique. That’s where code reviews come in. The beginning: introducing code reviewsWhat is a code review? Code improves with multiple reviews and revisions, and thi

ゲーマーならば、思い出に残るゲーム作品がいくつかあるだろう。なかには、自らの人生に影響を与えるほど深く感銘を受けた作品があるという人もいるかもしれない。北欧アドベンチャーゲーム『Röki（ロキ）』で知られるPolygon TreehouseのクリエイティブディレクターAlex Kanaris-Sotiriou氏は4月12日、ゲーム開発者としての自身の今の姿を形作ったという4本の作品を投稿。ほかの開発者にも、そうした作品を挙げるよう呼びかけた。 Kanaris-Sotiriou氏自身が示したのは、『Another World（アウターワールド）』『ICO』『トゥームレイダー』『The Secret of Monkey Island』だ。まだ見ぬ世界を冒険するという点で、同氏が手がけた『Röki』を含め、どことなく通じるものがあるチョイスである。 呼びかけに応じた開発者たちの投稿もいくつか見て

本記事は React best practices and patterns to reduce code - Part2 を提供元の事前許可を得たうえで翻訳したものです。 元の記事に従いタイトルに「ベストプラクティス」と含んでいますが、実際にはベストプラクティスは規模や状況によって大きく異なります。 チームの状況にあわせて参考にしていただければと思います。 ===== これは全3パート中の第2パートとなる記事です。 パート1パート2（この記事）パート3 時間を無駄にしないために早速Reactのベストプラクティスとコード削減についてみていきましょう。まずは最も一般的な内容から始めます。 コンポーネントが子要素を持たない場合はself-closing tagするよくないコード： return <Component></Component>よいコード： return <Component />

本記事は React best practices and patterns to reduce code を提供元の事前許可を得たうえで翻訳したものです。 元の記事に従いタイトルに「ベストプラクティス」と含んでいますが、実際にはベストプラクティスは規模や状況によって大きく異なります。 チームの状況にあわせて参考にしていただければと思います。 ===== これは全3パート中の第1パートとなる記事です。 パート1（この記事）パート2パート3 私は数年に渡っていくつかのプロジェクトで、React.jsを使った取り組みに参加してきました。様々なプロジェクトに取り組む中でいくつかの共通するパターンを見出したため本ブログでご紹介いたします。それではいきましょう。 1. reduxのactionsとdispatcherのためにカスタムフックを作成する私はreduxを使うことを好んではいませんが、いくつ

freee人事労務の品質改善を専任で活動している keik です。 freee人事労務ではアプリケーション開発の自動テスト環境として CircleCI を利用しています。すべてのコードの変更は GitHub 上の Pull Request を経由して行われますが、Pull Request のマージ条件の一つとして自動テストをパスすることを求めるようにしています。 つまり、どんな些細な変更であっても、急ぎの変更であっても、リリースするためには基本的には自動テストの結果を待つ必要があります。一方で、コードベースは日々成長しており、それに比例して自動テストの実行時間も長くなっています。 ここに、ゆっくりと、ジレンマが生じはじめます。 品質を高める目的の自動テストだが、実行時間が長いと品質のボトルネックになりうる。 具体的には以下のようなシナリオが考えられます。 些細な改善が億劫になる（自動テスト

はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上です。セキュリティ・キャンプ卒業後、新卒入社組としてFlatt Securityでセキュリティエンジニアをしています。 本稿では、Webアプリケーション上で実装される「ファイルアップロード機能」の実装パターンをいくつか示し、「開発者が設計をする上で気をつけるべき脆弱性」とその対策について解説していきます。 「ファイルアップロード機能」の脆弱性は特定の言語やサービスによって発生する脆弱性だけでなく、特定の拡張子のファイルでのみ発生する脆弱性など非常に多岐にわたります。そのため、本稿では全ての脆弱性を網羅する事は目的としておりません。しかし、「ファイルアップロード機能」のセキュリティについて考えるための基本となる知識と対策観点を本記事で知って、今後の開発に応用していただければ幸いです。 はじめに ファイルアッ