Kent C. Dodds 氏による Avoid Nesting when you're Testing という記事を翻訳させていただきました。 以下、本文。 これからご紹介するのは、React コンポーネントのテストに適用される一般的なテスト原則です。例に React を使用していますが、この概念正しく理解するのに役立つことを願っています。

株式会社インテグリティス代表の木村です。（Twitterではけいと呼ばれています。） 最近は受託開発の他、クライアント企業様への内製エンジニアリングチームの立ち上げとコーチングを事業として取り組み始めました。 アジャイル開発における「ストーリーポイントとベロシティ」について考える機会があったので、色々調べてみました。 スクラムの文脈で見積もりの単位としてよく使われる「ストーリーポイント」ですが、元々はXPが起源でした。 XPの創始者の一人であるRon Jeffries氏は2019年5月23日、自身のサイトにて「Story Points Revisited（ストーリーポイントの再考）」と題し、ストーリーポイントに対する考えを述べています。 なにかと誤解があったり、スクラム開発の現場で疑問が生まれることも多い「ストーリーポイント」や「ベロシティ」という概念ですが、Ron Jeffries氏の記

プロダクト開発をしていると、ユーザーや社内から改善要望をもらうことがよくある。でも、その要望の多くが「How」しか書かれていなくて、本当に必要な「Why」が書かれていない。 例えば、よくあるものだと 「ユーザー一覧をCSVでダウンロードできるようにしてほしい」 「検索結果を50件ずつ表示してほしい」 「削除ボタンを赤色にしてほしい」 といったものだったりします。 社内の人には「HowはあってもなくてもいいのでWhyを書いてください」と言っているんだけど、実際にWhyが書かれているケースは少ない。 テンプレートみたいなものを用意してもひどいケースだと「◯◯機能がほしいので◯◯機能を作ってください」みたいなことが書かれている。 どうしてWhyが重要かというと、"最適な解決策を見つけつつ、将来の拡張性も考慮した設計にしたい"からです。 このnoteではなぜ、要望にはWhyが重要でHowが重要では

・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら

プロジェクトの関係者全員が納得する「業務フロー図」。それはプロジェクトを円滑に進めるための"共通言語"であり、重要な存在です。 しかし、その作成は本当に骨が折れる作業です。一つ一つの箱を作り、線でつなぎ、色を分け…。手戻りが発生するたびに、あのコネクタを一本一本修正する虚しさ。初期のたたき台を作るだけで半日が終わってしまい、肝心の"中身の議論"に時間を使えないなんてこともザラです。 「この作る手間さえなければ、もっと本質的な議論に集中できるのに…！」 そう思っていた矢先、ある方法を試したところ、この長年の悩みが劇的に改善しました。それは、AIコーディングツール「Cursor」を使って、業務フロー図の作成を自動化するというアプローチです。 実際にCursorで実行して出力された業務フローはこちらです。 スイムレーンがあり、業務間の接続も記載されている。また、業務間で使用するファイルやデータも

この記事について会社・チームで人と一緒に働いたり、コミュニティで他人のアウトプットなどを観察したりすると、「この人頭いいなー」とか、「センスいいなー」と思ったりすることもあれば、逆のこともあったりするだろう。 最近、「デザインセンス」をチームに期待するにあたり、そもそもデザインの構成要素とはどういったもので、どのようにしたらデザインという営みの精度が上がるのか、という疑問に行き着いた。 個人のデザインセンスというところでは、先天的なものとまではいわずとも長く蓄積された思考習慣による才能・素養のようにも思えるが、後天的に、例えば成人後でも訓練可能なのかという観点で考えてみたので自分なりの整理として書き出してみる。 組織レベルで考えると「チームとしてどう成熟していくか、その経験をどうスケールさせていくか」というナレッジマネジメントの問題にも行き当たるが、ここではあくまで個人としてのデザインセン

ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削

» 【京都】JR東海「常寂光寺に苔を見に行きましょう」 → 苔どころじゃねぇ…！ / ガチ勢すぎる住職 特集 いやぁ、さすがに渋すぎるのではないか……？　今年の夏の「そうだ 京都、行こう。」のプレスツアーで、テーマが苔だと聞かされた時の第一印象はそんな感じ。 しかしJR東海は自信ありげだ。これから苔スポットを代表して、嵯峨嵐山にある常寂光寺に連れて行くという。まあ、とりあえず行ってからだな。 この時の私は、まだ把握していなかった。常寂光寺の境内が、ある分野にガチ勢な現住職の手で、苔どころではない状態にあることを……。 ・常寂光寺 常寂光寺は、JR嵯峨嵐山駅から西に徒歩20分ほどのところにある日蓮宗のお寺。現在の境内地およびその周辺には、かつて藤原定家の山荘があったと伝えられている。小倉百人一首ゆかりの地だ。 そしてこちらが、案内して下さった長尾住職。 まずは簡単な説明を受ける我々プレス陣。

はじめに Reactのフォルダ構成は難しい Reactは、フォルダ構成に"意見を持ちません"。 この柔軟性が、フォルダ構成の難しさに繋がっていると思います。 また、フォルダ構成について体系的に書かれている情報が少なく、特に用語の説明がなかったりするため、理解が難しいと感じました。 そこで、フォルダ構成を体系的に理解し、作成できるようになるため、フォルダ構成の考え方についてまとめました。 この記事の目的 フォルダ構成について： 意見を持てるようになる 調べやすくなる そして、リポジトリを見た時に構造化して見えるようになる ことを目的としています。 フォルダ構成の種類 フォルダ構成の種類は、大きく分けて３つに分類できます： type-based feature-based layer-based 「by 〇〇」という呼び方も存在しますが、意味は同じです。 詳細は、〇〇-based以外の呼ばれ方

この記事は、以下のモダンCSSに関する記事のHTML版です。 せっかくならHTMLもちゃんと学んでみようと思い、最近のHTMLの新機能を改めて学び直したので、アウトプットついでにこの記事を書いています。 HTML Living Standardの時代へ 2019年5月28日、W3CとWHATWGは、HTMLとDOM標準の開発をWHATWGが主導することで合意しました。これにより、HTMLは「HTML5」のようなバージョン番号を持つ仕様から、継続的に更新される「HTML Living Standard」へと移行しました。 この変化は単なる管理体制の変更ではなく、HTMLの進化の方向性を示しています。この記事で紹介する2019年以降の新機能を見ると、以下のような傾向が明確に現れています： 宣言的UI構築への移行 - JavaScript実装から、HTML属性による宣言的な記述へ ブラウザネイテ

チームで仕事を進めるうえで、仕事を任せるというのはとても重要だ。 そうしないと事業はスケールしないし、マネージャやリーダーはチームのボトルネックになってしまう。 そこで自分が仕事を任せるうえで大事にしていることを書く。 1タスク単位の話からプロジェクト単位の話まで共通する汎用的なことを紹介する。 裁量の範囲を決め、明確にする 任せる範囲を決めるということでもあるし、任せる範囲が複数の人の場合は役割分担なども明確にする必要がある。 特にプロジェクトの場合はボールのお見合いになることも多い。 そこで チームで仕事をする上で大事なフレームワークを2つ紹介する。 RACIチャート RACIチャートとは以下の4つの頭文字で、それぞれのポジションの役割をまとめるためのフレームワークだ。 Responsible 実行責任者 Accountable 説明責任者 Consulted 協業先、相談先 Info

誰かから方針を共有された時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう 一見して不合理な方針だと感じたとしても、その裏にはそれなりに込み入った背景がありタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかって

Kiro(kiro.dev)は、AWSが開発したIDE型のコーディングエージェントです。CursorやWindsurfのようなVS Codeフォークエディタに分類されます。現在はパブリックプレビュー中で、サインアップするとKiroでClaude Sonnet 3.7 とClaude 4 Sonnetを利用できます。 KiroThe AI IDE for prototype to productionKiroKiroの特徴は、スペック駆動開発、エージェントフック、ステアリングファイルといった独自の機能を通じて、ソフトウェア開発のライフサイクル全体を支援します。それぞれ見ていきましょう。 スペック (Specs)駆動開発Kiroの中核をなすのが「スペック＝仕様書」機能です。これは、ユーザーが入力した大まかな指示（例：「ユーザー認証機能を追加して」）をもとに、AIが「要件定義」「設計」「タスクリ

1秒でわかる｢ChatGPTエージェント｣：ChatGPTがこれになり、パワポを作ってくれる2025.07.18 18:3017,343 かみやまたくみ 2025年7月17日、OpenAIが｢ChatGPTエージェント｣を発表しました。ChatGPTに新しい機能をつけたよ、という話で、以下のように説明されています。 ChatGPTは今や、自分のコンピュータを使ってあなたのために働けるようになりました。複雑なタスクも最初から最後までこなします。 実際に使ってみたのですが、誇張なしで↑の画像のような機能です。 ChatGPTエージェントの使い方＆その強みChatGPTエージェントは既に実装されており、ChatGPT Plus/Pro/Teamユーザーであれば利用可能です。自分の環境ではWeb版のみ、実装が確認できています（アプリ版はラグがありそうです）。 シンプルな機能ではあるので試すのがいち

AIの暴走を防ぐ4段階フロープロセス AIの過剰な機能実装、エラーハンドリング、要件を無視したコーディング。これらによる手戻りの発生や新たなバグに日々悩まされている方も多いと思います。 そんな中、AmazonのAIエディタ「kiro」には単純明快で効率的なAI Codingが可能になるプロセスが実装されていたので、これを参考にCLAUDE.mdを作成しました。 そのプロセスは下記のとおり、シンプルで当たり前な内容です。 このプロセスが未導入だった場合 実際に「売上データを分析して」と指示した場合、AIは以下のような過剰な実装を行いがちです。 20種類以上のグラフを生成（棒グラフ、折れ線、散布図、ヒートマップ...） 全項目間の相関分析を実行 機械学習による売上予測モデルまで構築 データクレンジング、外れ値除去、正規化を勝手に適用 エラーが出ても別の手法で強引に続行 このプロセスを導入した場

複雑なタスクをやるときにKiroは便利だけど、モデルが限定されてたりなんかちょっと馬鹿だったりしてめんどくさい。 同僚の @tonkotsuboy_com はKiroに計画を立てさせて、それをClaude Codeに実行させるというワークフローを試していた。 自分もこれをやってみて、確かに便利だと思ったけど、これやるならもうClaude Codeだけでやってしまいたい。 ということでClaude CodeだけでKiro風のワークフローをやるためのカスタムスラッシュコマンドを書いた。これを /kiro とかで起動するようにしておけばまあまあ動く。 --- description: "spec-driven development" --- Claude Codeを用いたspec-driven developmentを行います。 ## spec-driven development とは sp

こんにちは👋 2025年7月15日、AWSからS3 Vectorsと呼ばれる機能がプレビュー公開されました。 Amazon S3 Vectors は、ベクトルの保存とクエリをネイティブにサポートする初のクラウドオブジェクトストアです。Amazon S3 に保存されたコンテンツの AI エージェント、AI 推論、セマンティック検索のために、コストに最適化された専用のベクトルストレージを提供します。 元々AWSでRAGシステムを構築する場合は、KendraやOpenSearch Service、Aurora(pgvector)などの高コストなベクトルDBを用意する必要がありました。OpenSearch Serverlessなどはサーバレス...と謳っているものの、実態は起動時間によるOCU単位での従量課金であり、個人でRAGシステムを構築する際の大きな障壁となっていました。 今回発表されたS

Kiroは対話形式で詳細な要件書・設計書を作れるが、実装速度が遅い Claude Codeは爆速開発ができるが、正確な指示出しが難しい 2つの長所を組み合わせることで、質と速度の両取りができました。 Kiroで作った仕様書をClaude Codeに読み込ませたら、Claude Codeがタスクを理解して最後まで実装してくれました。 Kiroとは Kiroとは2025年7月15日にAmazonがリリースした統合開発環境で、要件定義・設計からコードの開発までを行ってくれます。対話形式で詳細なrequirements（機能要件）・design（設計）・tasks（タスクリスト）を作成できます。作られたタスクを実行することで、開発が完了します。 詳しくは次の記事がわかりやすいです。 Kiroは設計は得意だが、実装速度が遅い Kiroは高機能な要件定義・設計機能は持っていますが、現時点では実装速度が

Copy as Markdown ▽ Copy as Markdown View as Markdown Copy Markdown URL 最近の開発はほとんど Claude Code で行っているが、使い始めた 3 月から比べると利用スタイルも結構変わったなとふと思ったので、あとで懐かしむために今やっているスタイルを書き残すことにした。個人的な開発に使っているもので、業務にこのフローを適用しているわけではないのと、Claude Code でうまくコードを書く方法ではなくその周辺の話。 全体感 開発は Dev Containers もしくは GitHub Codespaces ローカル開発では VSCode でメインの Claude Code + git worktree でいくつかの並列作業 GitHub Copilot もたまに使う Claude Code Actions でレビュー