はてぶ・Qiita・Zennのトレンド記事を紹介
はじめにドメインモデル3部作の最終回です。前回記事「業務概念を型として表現する」では業務概念をプログラミング言語の型として表現する判断軸を、前々回記事「ビジネスルールを発見する」では業務ドメインの中からビジネスルールを発見する作業を、それぞれ体系化してきました。本記事はその統合
はじめに前回記事「業務概念を型として表現する」では、業務概念をプログラミング言語の型として表現する判断軸を整理しました。本記事はその前段にあたります。型として表現する対象となる業務概念には、その内側にビジネスルールが宿っています。これらのルールをどう発見し、どう整理するか、とい
はじめにドメインモデリングという言葉に触れると、エヴァンス氏の『エリック・エヴァンスのドメイン駆動設計』や増田亨氏の『現場で役立つシステム設計の原則』といった書籍が頭に浮かびます。私自身、過去のプロジェクトでドメインモデリングを実践してきたものの、その判断軸を体系的に言語化した
はじめにここ毎日、テスト設計を起点にエンジニアリングのいくつかのトピックを巡りながら記事を書き続けてきました。本記事はその連投の最終日にあたります。シリーズを通じて私が伝えたかったことは、結論から書くと一つです。エンジニアにとって問いを持つことは、AI時代だから重要になったの
はじめにSLO(Service Level Objective)、という言葉を聞いたとき、明確な像を持って語れるでしょうか。私はSREやインフラの文脈で何度か耳にしてきましたが、概念として知っている程度で、自分の現場で深く実践してきたわけではありませんでした。そのSLOを学び
防御的プログラミングを学ぶ — 契約による設計とTDDの間にある語彙 🔖 3
はじめにAIエージェントにコードを書かせていて、過剰にnullチェックや例外処理が埋め込まれた経験はないでしょうか。私はこの場面に何度か遭遇したとき、「これは防御的プログラミングというものなのだろうか」と気になり始めました。ところが防御的プログラミングという言葉自体に、自分は
CI/CDパイプラインの高速化・整備 — 30分から10分未満に削減した実践記 🔖 1
CI/CDパイプラインの高速化・整備 — 30分から10分未満に削減した実践記 はじめに私の現場ではCI/CDパイプラインの実行時間が30分かかっていました。コードをpushしてからデプロイが完了するまで、毎回30分待たされる状況です。この実行時間を削減する取り組みを進め
リファクタリングはAIに任せられるか？Claudeに聞いてみた
はじめに先日、t_wada(和田卓人)さんが出演されている動画を視聴しました。(2026年1月公開、収録2025年10月)https://www.youtube.com/watch?v=MoP5-emix9E動画の中でt_wadaさんが語っていた論点は、TDDのやり方でA
はじめに今回取り上げたいのはQAメンバーとの観点共有についてです。新機能をどんな観点でテストするか、テストデータや環境をどう揃えるか、探索的テストで見つかった観点をどう活かすか。こうした問いは開発チームとQAチームが言葉を交わす中で答えが立ち上がってくるものです。本記事ではそ
V字モデルを語彙として持つ — AI時代のジュニアエンジニアに伝えたいこと 🔖 1
はじめに本記事は、テストコードとAIをめぐるシリーズの10本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはV字モデル。要件・基本設計・詳細設計・実装と進む左側の流れと、単体テスト・結合テスト・受入テストと進む右側の流れを、Vの字に対応
ピラミッドの形に捕らわれず、何を守るかを問う — テスト戦略の見直し 🔖 1
はじめに本記事は、テストコードとAIをめぐるシリーズの9本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはテストピラミッド。Mike Cohn が提唱したことで知られる「ユニットを多く、統合を中ぐらい、E2Eを少なく」という階層構造の話
カバレッジ100%の先にある問い — ミューテーションテストを学ぶ 🔖 1
はじめに本記事は、テストコードとAIをめぐるシリーズの8本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはミューテーションテスト。1作目「AI時代にバックエンドエンジニアが磨くべきテスト設計力」の第4章で、私は次のように書きました。
フレーキーテストの正体と向き合い方 — ReRunで凌いでいた自分がいま考えていること
はじめに本記事は、テストコードとAIをめぐるシリーズの7本目です。前作「テスト名は仕様の1行 — AIに命名を任せられる環境を作るまで」と同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはフレーキーテスト(flaky test)、同じコードに対して、CIで
テスト名は仕様の1行 — AIに命名を任せられる環境を作るまで
はじめに本記事は、テストコードとAIをめぐるシリーズの6本目です。1〜5本目では「AI時代に、エンジニアの設計判断はどこに残るか」という問いを軸に、テスト設計力、ドキュメントとしてのテスト、人間が先に仕様を設計する作法、QA技法、フロントエンドテスト実践記まで扱ってきました。
【第2部】AIが書いたフロントエンドのテスト、抜け漏れは誰が拾うのか
はじめに本記事は3部構成の第2部です。第1部では、フロントエンドにテストを導入することになった経緯、Vitestの選定とスコープ定義、そして「テストを入れる、とはどういうことか」への暫定的な答えとして、観点を持つこととコードの外側の情報を内側に畳み込むことという二つの側面を書き
【第3部】AIが書いたテスト、どう評価するか — カバレッジ70%とQA技法で測る
はじめに本記事は3部構成の最終回、第3部です。第1部では、フロントエンドにテストを導入した経緯とVitestの選定、そして「テストを入れる、とはどういうことか」への暫定的な答え(観点を持つこと、コードの外側の情報を内側に畳み込むこと)を書きました。第2部では、AIエージェン
【第1部】フロントエンドにテストを入れる、とはどういうことか 🔖 2
はじめに本記事は、バックエンドエンジニアとして9年目を迎えた私が、フロントエンドのテスト導入をチームでリードすることになってからの1ヶ月間を振り返る実践記です。VitestとAIエージェント(Cursor、Claude Code)を組み合わせてテストを書き進めるなかで、何がうま
【後編】そのテスト、どう設計した? — カバレッジ100%問題への応答 🔖 2
はじめに本記事は前後編の後編です。前編では、開発者が知っているとテスト設計の思考が変わる5つのQA技法を紹介しました。同値分割と境界値分析、状態遷移テスト、デシジョンテーブル、ペアワイズ法、そして探索的テスト。それぞれが「そのテスト、どう設計した?」という問いに具体的な答え方
【前編】そのテスト、どう設計した? — 開発者が学び始めた5つの武器
はじめにテストコードは書けるけれど、「そのテスト、どう設計したの?」と問われると言葉に詰まる。「なんとなく網羅しました」以上の答えが出てこない。そんなもどかしさを感じたことはないでしょうか。本記事は、そのもどかしさに向き合うためのQA技法を、開発者の視点から5つ取り上げて紹介
"このテストが落ちたら何のバグを検出したことになる?" AI時代にバックエンドエンジニアが磨くべきテスト設計力
はじめに本記事は、テストコードとAIをめぐるシリーズの1作目です。AIエージェントによるコード生成が当たり前になった今、テストコードもAIに任せる場面が増えました。便利で助かる一方、その出力に対して漠然とした違和感を抱いたことがある方も多いのではないでしょうか。本記事ではその
"このテストが落ちたら何を検出したことになる?" — テストを"仕様の実行可能なドキュメント"として読み直す 🔖 1
はじめに前作「"このテストが落ちたら何のバグを検出したことになる?" AI時代にバックエンドエンジニアが磨くべきテスト設計力」では、AI生成テストの質を底上げするための問いを紹介しました。本記事はその問いをより開いた形に拡張し、テストコードの別の顔に光を当てます。前作の問いが
AIにテストコードを書かせる前に、人間が仕様を設計する — TDDとDDDの原則をAI時代に活かす
はじめに本記事は、テストコードとAIをめぐるシリーズの3本目です。前々作「"このテストが落ちたら何のバグを検出したことになる?" AI時代にバックエンドエンジニアが磨くべきテスト設計力」では、AI生成テストの質を評価する問いを紹介しました。前作「"このテストが落ちたら何を検出
はじめに設計がうまくできない全体像がぼやける局所的な対応ばかりになるこうした悩みの背景には、「抽象化」の技術や姿勢が未整理なまま設計に向き合っていることがあります。本記事では、設計の本質を理解する鍵となる概念「抽象の梯子（ladder of abstraction）
軽量＆高速なCSV処理！csv-parserのNode.js/Next.jsでの活用法まとめ
csv-parserとはNode.jsでCSVファイルを読み込むときに使用するNode.jsライブラリです。軽量でストリームベースで動作するのでファイルの容量が大きいものでもメモリ効率良く処理できます。通常、Node.jsでCSVを処理する際はJSONに変換する処理が必要に