はてなブックマーク

はじめに こんにちは！TOKIUMでQAチームのリーダーをしている西田です。 「シフトレフト」「ATDD（受け入れテスト駆動開発）」「BDD（振る舞い駆動開発）」 — テストを上流に持っていこうという考え方は、ソフトウェア開発の世界で10年以上前から提唱されてきました。概念としては広く知られているのに、実際に徹底できている現場は少ない。「理想はわかるけど、やるのが大変」というのが正直なところだったと思います。 ところが今、生成AIの急速な進化によって前提が変わりつつあります。Claude CodeやGitHub Copilotによるコーディング自動化、Playwright Agentsによるテスト自動化。かつて「理想論」だったプラクティスの実現コストが、AIによって劇的に下がっているのです。 この記事では、これらの概念が生成AI時代に再び現実的な選択肢として浮上する先に、開発プロセスとQA

対象読者 同人誌出版に興味があるけど一歩踏み出せないという方 技術書典へのサークル参加・出展を検討している方 組版技術に興味がある方 はじめに TOKIUMは技術書典20のシルバースポンサーとして協賛しました。 それに合わせて、TOKIUMから有志7名で全6章の技術同人誌を制作しました（1章のみ共著）。 オフラインイベントが2026/4/12に池袋・サンシャインシティで開催され、来場者は3100人に及び大盛況となりました。 TOKIUMのサークルスペースにお越しいただいた皆様にこの場を借りてお礼を申し上げます。無事、発行した紙書籍500部を全て頒布することができました。 私共が書き上げた書籍について、各章のテーマは、AWSコスト削減、エンジニアからPdMへのキャリア転換、AIによる個社対応の自動化、レガシーシステム×AIの保守戦略、Goのエラー処理哲学、開発生産性計測と多岐にわたります。

数千のテストパターンがあってもClaude Codeがあれば、テストコードは現実的に書けるようになりました。 しかし、仕様が未定義だったり、振る舞いが不定だったりすると、流石のClaude Code師匠でもテストは書けません。テストをスキップしたり、TODOつけてくれたりと、師匠なりに弟子を路頭に迷わせまいという親心を見せてくれるわけでありますが、結局のところ、お前たちヒューマンが仕様を意思決定せよ、と師匠は仰せなわけです。 私は、ヒューマンとAIが仲良く開発していくことを切に望んでおります。であれば、「AIがテストを書く」と「人間が仕様を決める」という責任を別々のタイミングで全うできる方法がないか、ということで、rspec-undefined を作ってみました。 この rspec-undefined は、仕様の未定義や不定値を明示的にテストコードに書くことができます。この未定義は集計され

はじめに こんにちは！TOKIUMでQAチームのリーダーをしている西田です。 最近、開発コミュニティで「ハーネスエンジニアリング」という言葉を耳にする機会が増えました。 Xや各種技術系ブログでは特に顕著で、AIコーディングツールの普及に伴い、プロンプトを書くだけでなく、AIが動作する「環境」そのものを設計するという考え方が注目されています。 ハーネスエンジニアリングとは、LLMを特定の業務に最適化するために、指示ファイル・ナレッジベース・バリデーション・ワークフロー定義などの「外部構造」を設計・整備するエンジニアリング手法のことです。プロンプトエンジニアリングが「何を聞くか」に注目するのに対し、ハーネスエンジニアリングは「どういう環境で動かすか」に注目します。CI/CDパイプラインを設計するように、AIの動作環境を設計する — そんなイメージです。 私たちQAチームでは、Claude Co

この記事では、生成AIでレガシーシステムのドキュメントを体系的に整備、管理する方法を解説します。 ドキュメント体系の設計から、具体的な要件、Claude Codeでの進め方、品質管理、そして現実的な始め方まで、一連の流れを扱います。 はじめに なぜドキュメントは整備されないのか システム開発はチームで行うものです。そしてチームには、コードを読む人だけがいるわけではありません。 PdMはビジネスロジックを把握する必要があります。運用チームはバッチ処理や監視の仕組みを理解しなければなりません。新しく参画したエンジニアは、全体像を掴むところから始まります。社外のパートナーと連携することもあるでしょう。 こうした人たちにとって、システムを理解する手段はドキュメントしかありません。コードを読めばわかる、は通用しない場面の方が多いのです。 それでもドキュメントが整備されないのは、3つの壁があるからです

はじめに こんにちは！TOKIUMでQAチームに所属している富田です。 この度、弊社QAチームとして新しいテスト自動化の取り組みを行ったのでその紹介をさせていただきたく思います。 TOKIUMでは、E2Eテストの自動化は以前から進めていました。しかし、新機能開発に対するシステムテストの自動化には手をつけられていませんでした。 ここでいう「システムテスト」とは、E2Eテストや受入テストの前段階で行われる、開発から渡された新機能が要件どおりに動くかを確認するテストを指します。リグレッションテストのように既存機能を広く通すのではなく、新たに実装された機能に対して、テストケース単位で細かく検証するものです。 これまでQA界隈では、E2Eテストのように既存機能を横断的に通す自動化は着実に進んできました。しかし、新たに開発された機能に対する粒度の細かいテストは、毎回テスト対象の画面構造が異なり、カスタ

Claude Codeを毎日使っていると、ふと「こいつ、俺のことわかってきたな」と感じる瞬間があります。 先日、DB分析の相談をしたとき、Claude Codeが黙ってソースコードを開いてフラグの意味を確認し始めました。以前は何度もスキーマだけで推測して間違えていたのに、今回は何も言わなくても自分から確認している。 あるいは、テックブログの下書きで「不可欠です」みたいなAI臭い表現が一切出てこなくなった。以前は毎回指摘していたのに。 しれっと変わっている。メモリに保存しただけでは、ここまで行動は変わりません。裏側には、ちょっとした仕組みがあります。 ここでいう「学習」は、知識を覚えさせる話ではありません。Claude Codeの思考パターンや判断の癖を、どう進化させるかという話です。 この記事では、Claude Codeを「使うたびに賢くなるAI」にするために実装した3層の学習構造について

PLだけ見ていると、目の前の数字は作れても、将来的に大きな資産になる機能を見落としてしまうかもしれません。BSだけ見ていると、壮大なビジョンはあるけど、今期の数字がついてこない。 会社の経営にPLとBSの両方が必要なように、プロダクト開発にもPjMとPdMの両方が必要です。これ、会計やってる人にはすごく自然な話だと思います。片方だけじゃ決算書は完成しませんからね。 そしてもうひとつ大事なのは、PLとBSは別々の人が見なければいけないわけではない、ということです。プロジェクトマネジメントもプロダクトマネジメントも、あくまで手法です。PdMがプロジェクトマネジメントをしてはいけない理由はどこにもありません。PLの視点でコストとスケジュールを見ながら、BSの視点で何を資産として積むかを考える。この2つの視点を行ったり来たりできることが、実はいちばん強いのかもしれません。 おわりに 経理AIエージ

SOLID原則、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャ――。 設計について学ぼうとすると、いきなり抽象度の高い概念が押し寄せてきます。依存性逆転の原則って何だろう。ポートとアダプターって具体的にどうやるんだろう。そう途方に暮れた経験は、多くの人にあるのではないでしょうか。 この記事では、もっとシンプルな原則を提案します。 入力・処理・出力を分ける たったこれだけです。 IPOモデル(Input-Process-Output model)と呼ばれるこの考え方は、プログラミングの教科書で最初に学ぶ概念のひとつです。しかし、実際のコードでこれを意識して守れている人は意外と少ないかもしれません。 この記事では、申請書を承認するという実務でよくあるユースケースを題材に、テストをグリーンに保ちながら、一手ずつIPOの境界に沿ってリファクタリングしていきます。各ステップでコードの品質を fl

こんにちは、TOKIUMでエンジニアをしている西本です。 現在、エンジニア3人のチームでClaude Codeをフル活用した開発をしています。実装の効率化によって週30本以上のPRがマージされる環境になったのですが、巷でよく言われる通り今度はレビューというボトルネックにぶち当たりました。レビューをしてもしても終わらない、まさにPRの海に溺れている状態です。ただ、実装の出力を落とすのは絶対にやりたくなかったので、レビュー側を効率化する方向でClaude Codeのスキルとワークフローを整備していきました。今回は特に効果の大きかった3つの仕組みを紹介します。 レビューに関わるスキルとワークフロー Claude Codeのスキル（.claude/skills/にSKILL.mdを置いて/スキル名で呼び出す機能）と、GitHub Actionsのワークフローを組み合わせて、レビューに関わる仕組みを

はじめに こんにちは、Lapi（@dragoneena12）です。 Goではtry-catch型のエラー処理（いわゆる例外処理）ではなくエラーを関数の戻り値として扱うようになっています。他の言語に慣れている人からするとこの書き方は冗長に見えるようです。 なぜGoではこのようなエラーの扱い方をしているのか。冗長に書かざるを得ないように見えるのはなぜなのか。自分なりに調べてみた内容を社内LT会で発表したので、ブログ記事に再編してみました。 Cのエラー処理 Goがこのようなエラー処理方法を採用した背景を知るため、まずはCのエラー処理について振り返ってみます。 まず重要な点として、Cの言語仕様では値を1つしか返すことができません。そのためエラーの場合は -1 を返すといったエラー処理がよくみられるパターンです。 int main() { pid_t pid = fork(); if (pid ==

列が横にどこまでも伸び、大半のセルが空白。 右端の方には「育休開始日・2回目」という列がひっそりと佇んでいる。現在の状況という列には、在籍中・入社前・育休中・退職済みが混在している。 誰かが更新したらしいが、誰がいつ何を変えたのかわからない。 引継ぎのたびに繰り返される会話がある。 ——前任者が作ったやつで、自分もよくわからなくて…… これは、あなたがズボラだからでも、前任者が悪かったからでもありません。 管理表のつくり方に、構造的な問題があります。 この記事では、管理表がなぜ崩壊するのかをストーリーで追い、どう考えれば崩壊を防げるのかを解説します。 ＜第1章＞ 管理表崩壊ストーリー はじまりは名簿から 上司「従業員の名簿を作りたいんだ。社員番号、氏名、メアドがあって、在籍中か退職済みかわかるようにしたいな。」 担当者「わかりました。さっそく作ります。」 こうして最初の名簿が完成しました。

この記事は、フロントエンドの状態管理のお話ではありません。リレーショナルデータベースにおけるテーブル設計のお話です。 また、この記事に出現するSQLは PostgreSQL をベースにしています。 状態管理はアプリケーションの要です。 この記事では、従業員管理システムを開発、保守しながら、状態管理への理解を深めていきます。 上司からの要望を部下が受け付けます。 部下はAIをつかって開発していきます。 今回は、機能追加や変更でテーブル構造が崩壊していく様子を見ていきましょう。 第1章 テーブル崩壊ストーリー 『嗚呼、我らのDX』 はじまりはいつも表計算ソフト 上司「従業員管理システムをつくりたいんだ。コード、氏名、メアドがあって在籍中か退職済みかわかるようにしたいんだ。ここに表計算ソフトでつくった従業員のファイルがあるから、参考にして。」 部下「御意。」 AI「従業員のファイルを解析しました

はじめに こんにちは！TOKIUMでQAチームのリーダーをしている西田です。 私たちのチームでは、テスト業務の自動化に取り組んでいます。プロダクトへのE2Eテスト導入にあたってツールの選定を行ったのですが、その過程で Playwright と Vibium という2つのツールを比較検討しました。 Playwrightは2020年の登場以来、E2Eテスト自動化のデファクトスタンダードの一つとして広く使われています。 Chat GPT公開以降、コーディングの壁がほぼなくなったこともあってE2EテストといえばまずPlaywright！が定番のように思います。 一方、Vibiumは、Seleniumの共同開発者（co-creator）であるJason Huggins氏が2025年後半に発表した新しいブラウザ自動化ツールです。テスト自動化するぞ！Seleniumだ！という流れを経験してきた私はなんと

はじめに 先日、SlackがついにMCPサーバーを公式にリリースしました。 「これでAIからSlackを操作できる！」と話題になっている一方で、「MCP不要論」も耳にします。 そんな混沌とした状況の中、私が細々と開発してきたurugus/slack-cliが社内でじわじわ流行ってきているため、紹介したいと思います。 slack-cliとは 私が個人で開発している、ターミナルからSlackを操作するためのCLIツールです。 こんな感じで、Claude Codeに利用させています。 情報収集させて 要約させて 返信させる 導入

はじめに — あれから1カ月 TOKIUMプロダクト本部の芦田です。 先日、こんな記事を書きました。 私の仕事を毎日後押ししてくれるAIたち——"相方"——との日常の話。 社内外でいくらか反応もいただき、「私もやってみたい！」という声もいただきました。 あれから1カ月。 そんな相方は今日も私のために（？）尽力してくれているわけですが、 今回は、この1カ月の、相方の進化を、続きとして書いてみます。 新しいMCPを繋いでみた！新しい公式Skillsを試してみた！と、 新機能・新しいユースケースを語りたいところでもありますが、 今回の内容は、あえて 「私のClaude Code環境全体・仕組みそのものの進化」 にフォーカスしてみたいと思います。 Claude Codeを、より高度に「使いこなす」ために。 是非一読いただければと思います。 ※新たなユースケースについては、弊社PdMの @ヨウヘイ

[追記] 「本質を理解した！」と自信満々に書いたにも関わらず、DDDについてまだ理解が浅かったようです...。素晴らしい解説コメントをいただいたので、DDDの本質を理解したい方はぜひコメント欄もご覧ください！ 「なんか良いらしいぞ」 新卒で入社して配属されたのは、新規事業の立ち上げチームでした。Web開発の経験はほぼゼロ。開発を始めて少し経った頃に、社内の他のチームがDDDという手法を使っていると知りました。 調べてみると、「有名な手法」「価値あるソフトウェアが作れる」らしい。 なんか良いらしい。じゃあうちもやろう、と。 これが失敗の始まりでした。 表面的な理解が招いた勘違い 開発していたのはRAGチャットボットです。 DDD導入にあたり、DDDの本や記事をたくさん読みました。個人的に一番分かりやすかったのはこれ（それでも難しかったけど）。 出典: ドメイン駆動設計入門 - 翔泳社 ドメイ

この記事の対象読者 Docker Composeで開発環境を構築しており、複数ブランチを同時に動かしたい開発者 この記事で得られること git worktreeでブランチごとに独立した作業ディレクトリを持つ方法 Docker Composeの動的ポート割り当てでポート競合を回避する方法 本記事では Docker Composeを使った開発環境を前提としています。 開発中、複数のブランチを同時に動かしたくなる場面があります。 コードレビュー: レビュー対象のブランチを実際に動かしながら確認したい 比較検証: 修正前後の挙動を並べて比較したい 緊急対応: 機能開発中に本番バグ修正が入り、すぐ切り替えたい git stashや git checkoutで都度切り替える方法もありますが、環境の再構築が発生したり、コンテキストスイッチのコストが高くなります。 本記事では、git worktreeとD

はじめに こんにちは、TOKIUMの重村です。25卒として入社した後、新卒未経験でエンジニアになり、現在はAI出張手配プロダクトの開発チームリーダーをしています。 若手エンジニアの皆さん、Claude Code Skills使っていますでしょうか？ 少し前からSkillsが登場し、できることの幅がすごく広がりましたよね。自分も早くからキャッチアップしていきたかったのですが、なかなか手をつけられずズルズルと学習しないまま来てしまいました。気づけばどんどん進化していき、Xの人達の投稿をみると「ここまで使いこなしているのか...」と焦りを感じています。 今回の記事では、そもそもなぜ革新的な技術に手をつけられなかったのか？実際にSkillsを設定してみて感じたこと、そして 失敗から学んだ「目的を明確にすることの重要性」 を書きました。同じように技術トレンドに対しての焦りを抱えている若手エンジニアの

はじめに 私はこれまで、プロジェクトマネージャー（以下、PjM）として受託開発の現場などで、「プロジェクトをどう成功させるか」に心血を注いできました。 そして現在は、プロダクトマネージャー（以下、PdM）として、「何を創るべきか」という問いに向き合っています。 このキャリアの変遷の中で、「同じくPMと呼ばれることのあるPjMとPdMの違いとは何か？」という問いを自分なりに噛み砕いてきましたが、その過程は決してスマートなものではありませんでした。 特に受託開発出身の私にとって、この役割の転換は「過去の成功体験」との戦いでもありました。 今回は、そんな個人的な葛藤も含めた、私なりの定義について書いてみたいと思います。 PjMの本質：見えない「事実」を見えるようにする人 PjMとして現場を指揮していた頃、私が最も意識していたのは「見えないものを見えるようにする」ことでした。 プロジェクトにおいて

この記事では、複数のAIエージェントを組み合わせた開発フローと、それを支える環境構築のTipsを紹介します。 私はClaude CodeやCodexといったAIエージェントを毎日使っています。ただ単体で使っているとどうしても「このAIの判断、本当に正しいのかな？」と不安になることがあります。 そんな課題を解決するために試している「Claude CodeからCodexを呼び出してクロスチェックする」というフローを紹介します。 Claude Codeは非常に優秀で、実装からレビューまでこなしてくれます。ただ同じセッションで繰り返し確認を求めても、同じ視点からの回答になることはありませんか。 ここに課題があります。 毎回、何回聞いても同じ視点からの回答になる 局所解に落ちても気づけない 違う視点が欲しくなる 人間の開発でも、自分で書いたコードを自分でレビューするより、別の人にレビューしてもらった

AnthropicのCEOであるダリオ・アモデイは、ダボス会議で「6〜12か月でAIがソフトウェアエンジニアの仕事の“ほとんど、もしかすると全部”をできるようになるかもしれない」という趣旨の発言をし、大きな話題になりました。 この予測が当たるかどうかはさておき、少なくとも「ソフトウェア開発が強烈に自動化されていく未来」に向き合う必要がある、という点は確実に現実味を増しています。 そして、その未来に向けて今いちばん厄介なのが、現在のAIコーディングのプロセスが HITL（Human-in-the-Loop：AIの生成物に人が介入して品質を担保する） 前提で作られていることです。人間によるコードレビューは「AI任せにせず人間が監督・介入して品質や安全性を担保する」仕組みとして重要です。 一方で、AIの能力が上がるほど「人がループから外れる（Human out of the Loop）」領域が増

最初はバイブコーディングでいいと思っていた 2025年4月、私は株式会社TOKIUMに新卒エンジニアとして入社しました。 当時はバイブコーディング全盛期だったため、「もうAIが書いた方が圧倒的に速いし、全部バイブコーディングでいいんじゃないか?」と思っていました。 でも同時に、「本当に自力でコードを書かなくて良いのか?」という不安も抱えていました。 このような思いを抱きながら半年間開発してきて、経験を経て学んだことがあります。 確かにコードは書かなくていいかもしれない。でも、理解だけはやめてはならない。 その理由をお伝えします。 実務で気づいた『理解』の重み 私が入社して配属されたのは、AIヘルプデスク事業のバックエンド開発チームでした。8月のサービスローンチに向けて、PoCフェーズの開発が進んでいました。 このPoCフェーズでは、「ひとまず動くものを作る」ことが最優先でした。AIを使って

こんにちは、TOKIUMでembedded SREをしております對馬です。 現在構築中の新規サービスにSLOを導入するにあたり、metricsベースSLOとtime slice SLOの比較検討をしたところ、非常に興味深く、学びが深かったので記事にします。 概ねはDatadogの公式ページに書いてありますが、この記事では特に注意が必要と思われる、以下について深掘りします。 時間ベースとカウントベースの違い メトリクスにグループをしかけた時の挙動 この記事が誰かの助けになれば幸いです。 想定読者 SLOを概要レベルで知っている方 Datadog SLOの導入を考えておられる方 測定対象の違い Datadogに比較ページがあるので、まずはこちらを確認します。 メトリクス ベースの SLO: SLI の計算をカウント ベースにしたい場合に使用できます。SLI は、良いイベントの合計を全イベントの

イネーブリングチームの東です。 先日、RubyKaigi2024に参加してきました。家庭の都合もあり2日目のみの参加でしたが、興味深いセッションをいくつか聞くことができました。 Embedding it into Ruby codeもその一つで、soutaroさんが開発したrbs-inlineについてのセッションです。これは、Rubyの型情報をコメントに埋め込むことで、rbsファイルを別途作成せずに型情報を記述できるツールです。 Rubyの型チェックはTOKIUMではまだ扱えていないのですが、静的型付けを扱った身としてはやはりrbsファイルのように実装と型定義が分かれてしまうのは厳しいなと思っています。rbs-inlineが発展していくと、Rubyの型チェックがいよいよ実用的になっていくかもしれません。 rbs-inline自体の使い方はシンプルでgithubのREADMEやwikiをみれ

株式会社TOKIUMでAndroidエンジニアをしている渡邊(@error96num)です。ここ数年は"injection"というとワクチン注射が思い浮かびますが、本記事ではアプリ開発において欠かせないinjection、依存性注入（Dependency Injection: DI）という概念について解説します。 対象読者 以下のような方を想定しています。 依存性注入（Dependency Injection: DI）に馴染みがなく、ざっくり理解したい DIフレームワークを使ったアプリ開発をしているが、基礎にたちかえってDIの目的やメリットについて今一度理解したい 依存性注入 (Dependency Injection: DI) Android公式のドキュメント[1]にも登場するCar, Engineクラスを使った例で、Kotlinでの実装を交えてDIについて解説します。 多くの場合、クラ