はてなブックマーク

RSGTに参加してテンションが上がったところでtoshiotmさんに京アジャ開催しませんかと打診したところ、快く開催していただけたので、京都アジャイル勉強会LT大会 #125 - connpass に参加してきました。今回はLT大会だったので、僕も発表しようと思い「顧客との商談議事録をみんなで読んで顧客解像度を上げよう」という発表をしました。 speakerdeck.com こんな感じの発表です。興味が持てた人は発表資料をご覧ください。 作っているサービスは一般ユーザーと法人顧客がいるが、一般ユーザーだけでなく法人顧客の声も開発に活かしたい機運が高まった まずは自分で営業メンバーへのヒアリング/商談録画閲覧/展示会参加での顧客との直接対話を試した 自分の参加を見せて他の興味のあるメンバーにも展示会に行ってもらえた しかし、全員へ広げるには時間がかかるし、顧客との会話が苦手な人もいる。そうい

最近、AI駆動開発にSDD（Spec Driven Development、仕様駆動開発）を取り入れるアプローチがある。Kiro式やその方式をClaude Codeなどでも使えるようにしたcc-sdd、spec-kitなど色々なツールが出ている。 自分もcc-sddを個人開発で試してみたのだが、生成される仕様の文章量が膨大で、実装を始めるまで時間がかかる割に仕様のレビューもしきれなかった。diff 1000行のPullRequestが来たらレビューできず「よく分からないけどOK」となるのと同じで、仕様も膨大だとレビューできないという気持ちになった。 一方で、SDDの考え方の中でも、実装を始める前にちゃんと要件や仕様を固めたいなど、自分の中で取り入れたいものはあった。そこで、自分の得意不得意に合わせてスラッシュコマンドを自作して運用している。個人的にこのやり方がハマっているので紹介する。 自

最近、Claude Codeの以下の問題で非常に困っていた。 今の所 - 起動した直後は問題ない - C-rの履歴検索やC-gのエディタ起動で100%確定で動かなくなる - 一旦claudeを落とし、claude -cで復帰すると直る って感じですね〜— 柴崎優季 (@shibayu36) 2026年2月1日 x.com Claude Codeはコードを書かせるだけじゃなくて壁打ち役に使わせるのも便利だなと感じていた。そこでClaude Codeに手伝ってもらったらバグ報告も簡単にできるのではないかと試したところ https://github.com/anthropics/claude-code/issues/22315 のようにいい感じにissueを作れた。非常に体験が良かったので、参考のために今回はどんな感じに壁打ちしていったかを記録しておく。 まずClaude Codeはバグレポート

子どもへの注意がだんだん怒りっぽくなってきてしまい、もっと良い注意の仕方を学びたいと思って「どならない練習」を読んだ。 子どもも自分もラクになる「どならない練習」【電子限定特典付】 作者:伊藤徳馬ディスカヴァー・トゥエンティワンAmazon この本では、子どもへの注意の仕方を「青カード（やるべき行動）」と「赤カード（やらない方がいい行動）」の2種類に分けて整理している。たとえば青カードには「代わりの行動を教える」「一緒にやってみる」「気持ちに理解を示す」「ほめる」などがある。赤カードには「あいまいな指示」「否定形（禁止）」「脅す」「質問風の攻撃」「長い説明」などがある。完璧を目指すのではなく、赤カードが出そうと気づいたら余裕がある時はちょっとずつ青カードに変更すると良いよと書かれている。 この本で良かったなと思うのは、ひたすら注意する状況の練習題が出されて、それに対して青カードを使ったらど

RSGTに参加したら色んな人がプレーリーカードを持っていて、スマホをかざしただけで本人の自己紹介が見れるのが便利すぎて、自分も作りたいな〜となった。 prairie.cards というわけで作った。アイコンをカードに印刷している人も見かけて良いな〜と思ったので、僕もアイコンやヘッダー画像を使って独自デザインにしてみた。結構いい感じになって大満足。

開発フローを改善したいとき、目的や目指したい姿を明確にするのは大前提だが、さらに開発フロー全体の変更しやすい・変更しにくいところを理解してから設計と改善を実施した方がいいと考えている。 開発フローには、事業の特性上もしくは組織の歴史的経緯でその組織特有の変更しにくい部分が存在している。状況によって様々だが、例えば、リリースの曜日、レビューやリリース承認プロセス、ミーティングの頻度などがあり得るだろう。 そして改善を実施するときのよくある失敗は、いきなり理想のフローを設計し、変更しにくい部分も含めてたくさん変えてしまうことだ。変更しにくい部分を同時に一気に変えようとすると、その変更の関係者が増え、反発が起きやすくなる。反発が起きると、良い方向に向かうはずの変更まで含めて「全部失敗だった」となってしまい、何も変えられずに失敗するケースが多い。 そこで次の2つを意識すると良い。 まず、変更しにく

ブログを書くまでがカンファレンスということで、RSGT2026に参加しました記事です。 今回参加したのは、「開発フロー改善がうまくいって知見も溜まったし、どこかで発表したいな」と思った時にたまたまRSGT2026のプロポーザル応募をしているのを見て、勢いでプロポーザル応募したのがきっかけ。結果的にプロポーザルも通り、初参加 & QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化するという発表をしてきた。 初参加で、しかもこれまでスクラムやアジャイル系のイベントにはほぼ参加したことがなかったため、ほとんど知り合いがいないという状況だった。けれど今回の機会で色んな人と廊下や懇親会で話せて、興味深い議論をしたり知り合いを増やせたりしたなと思う。 セッションもレベルが高いものばかりで、特に以下の2つのセッションが参考になった。両方とも深い知見であると同時に、会社でまず一歩目を踏

RSGT2026に参加して発表してきました。スクラム系のイベント初参加・初発表・かなり大きなホールでの発表ということで緊張した〜。 発表資料はこちら。QAフローの最適化とタイトルに入っていますが、QAチームの立場からというより、開発チームのソフトウェアエンジニアの立場から開発フローを改善していく話です。 speakerdeck.com 資料を作っていて、「うーん自分は結局この発表で何が伝えたいんだろう？」と迷っていたのですが、作っていく中で言語化できたように思います。それは今回のフロー変更がうまくいったのは2つの成功要因があり、さらにこの成功要因はQAだけでなく開発フロー改善全体に言えることだなということです。 簡単にこの部分で話したことを要約するとこんな感じ。 QAフローや開発フローの改善をするとき、最初からフロー設計をするのではなく、必ず事業やサービス理解から始める方が良い よくある罠

社内でAI活用を推進するにあたって、どのようなコツがあるかの知識を付けたいと思い、生成AI「戦力化」の教科書を読んだ。 生成AI「戦力化」の教科書 作者:松本 勇気日経BPAmazon この本は、LLMを自社業務に組み込むための実践的な方法論がまとまっていた。ナレッジベースの構築、転記・抽出、文書作成、レビューといった具体的な業務への適用方法が整理されていて参考になった。 印象に残ったのは以下のポイント。 LLMの仕事は常にレビューするべき。そのためLLMに任せるべきかの軸として、ワークフローの入力と出力を人が正解かどうかを判断しやすいかという視点も大切 ナレッジベース構築をするための具体的なステップが解説されていたのが良かった。特に(5)のステップは大事だなと思う (1) そもそもナレッジベースをどのようなアウトカムに繋げたいのかから考える (2) 目的にあった文書・情報をリストアップ

Ghosttyが速くて良いという意見を最近よく見かけるので、導入してみた。 まずインストール brew install --cask ghostty ghostty CLIがうまく動かなかったので、PATHを明示的に指定した。 https://github.com/ghostty-org/ghostty/discussions/8921 あたりの話のようで、何らか上手い設定がありそうだが、とりあえずPATH明示の方が速かった。 export PATH="/Applications/Ghostty.app/Contents/MacOS:$PATH" 最低限の設定を加える。 # 好みのフォントを使いつつ、日本語フォールバックも指定 font-family = "Hack Nerd Font Mono" font-family = "Hiragino Kaku Gothic ProN" font

最近CursorやWindsurfといったVSCodeフォークのエディターが使われるようになっているが、これらからはVisual Studio Marketplaceに公開された拡張を探すことができない。Open VSX Registryから拡張を検索するようになっている。 自分もVSCode拡張を作っているが、CursorやWindsurfなどからも簡単に使えるようにしたい。そこで自分の作ったものをOpen VSXにリリースした。 Search in Current File インクリメンタルサーチ中に、ファイル内のヒットした箇所を一覧しやすくする拡張 Open to Other Editor Group Explorer Viewにいる時にファイルをActiveなEditor Groupの隣に開く拡張 どうぞご利用ください。そしてVSCode拡張作っている人いたら、どんどんOpen V

AIエージェント作りの学習をしたく、「現場で活用するためのAIエージェント実践入門」を読んでいる。この本はいろんな事例でAIエージェントの具体的な実装を教えてくれる。サンプルコードが多く、実践でどう作るといいのかを学ぶことができる。かなり面白いのでAIエージェント作りに興味がある人は買いましょう。 現場で活用するためのＡＩエージェント実践入門 (ＫＳ情報科学専門書) 作者:太田真人,宮脇峻平,西見公宏,後藤勇輝,阿田木勇八講談社Amazon 一方で、AIエージェント作りをやったことない身としては、具体事例を実装していく章を読んでも完成系のコードしかないため、実装ステップが大きすぎて理解しきれなかった。一歩ずつ理解するために、自分で手を動かしながら段階的に学んでいきたい。 そこでAIにハンズオンを作ってもらって、まずは「4章 ヘルプデスク担当者を支援する」の内容を学ぶことにした。 ハンズオン

Claude CodeやClaude Code Actionを用いて、AIに自律的にPull Requestのレビューを行なってもらうとき、いくつかの課題があった。その解決のためにPull Requestのレビュー操作に特化したgithub-pr-review-operationというClaude Skillsを作ったので紹介します。 課題 次の3つの課題があった。 インラインコメントを付ける時に、コメントする行を間違える Claude Code ActionにはインラインコメントをつけるMCPが同梱されているが、ある行に対する指摘内容を別の行にコメントを付けることが多かった そのPull Requestに過去ついたコメントを考慮してと指定しても、うまくコメント一覧を取得できない 通常のコメントは取得できてもインラインコメントは取得せずに進めてしまうなど そのPull Requestについ

AIが進歩して、ドキュメントやブログ記事などを非常に作りやすくなった。一方でAIは文章の足し算に偏重しているため、伝えたいことに対して非常に多くの文章を吐き出す。その結果、何が伝えたいか分からないドキュメントや記事が増えていると感じる。 こう感じたとき、僕は自分が好きな「圕の大魔術師」の、とあるセリフを思い出す。5巻 p141の「本が優れているかどうかの判断に厚みは直接的な関係がないと思います。言葉を削ぎ落とし簡潔に真実を述べた冊子のような姿もありうれば、いたずらに文字だけ増やした辞典のような姿もありうるからです」というセリフだ。 圕の大魔術師 5巻 p141から引用 AIによって文章を作りやすくなった時代だからこそ、「何を伝えたいか」を徹底的に意識し、「伝えたいこと以外を徹底的に引き算」した文章を作るように心がけたいと思う。 図書館の大魔術師（５） (アフタヌーンコミックス) 作者:泉光

エージェント実装の理解を深めたいなと思い、「Goで作る自作コーディングエージェント nebula 開発入門」を読みながらコーディングエージェント実装の写経をしてみた。学びが多く、非常に良かった。 zenn.dev 実際に作ったコードは https://github.com/shibayu36/nebula にある。資料と違って、ちょっとだけ設計を変えてみたり、セッション一覧表示を作ったり、編集時のdiff表示を作ってみたりなどもしてみた。 この実践では、エージェントを作る時の基本構成や設計パターンについて概要を学ぶことができた。たとえばツールコール、システムプロンプト設計、メモリ機能設計など。この辺りはAIエージェントを作る上でコーディングエージェント作り以外にも役立つ知識なので、手を動かして深めに理解できたのは良かった。 Goを普段書いていて、AIエージェント作りに挑戦してみたい人にとっ

最近AIを使って仕事をしていると、特定分野の仕事をする時、その分野の基礎知識があればAIをうまく活用できるが、そうでないと全く活用できないということが多々ある。そのためいろんな分野の基礎知識を付けられると良さそうだと思い、経営系のことを学ぶため「世界標準の経営理論」を読んだ。 世界標準の経営理論 作者:入山 章栄ダイヤモンド社Amazon 経営理論の基礎を知る部分としても非常に面白かったのだけど、最初に読み始めた意図とは異なり、Engineering Managerの仕事で参考にできることが多かった。たとえば面白かったなと思ったのは 理論には必ず適用範囲がある。適用範囲が大手企業の限定の場合に、スタートアップには役立たない可能性がある。そのため適用範囲を理解することが大切 気づき：エンジニアリングをしていると、いろいろな手法・フレームワーク・ツールが出てくる。この時に「適用範囲」を理解して

表題のとおり、Claude Codeが4~5並列にSubAgentを起動した時に自宅ネットワークが死ぬ問題が起きていた。その状況になると次のような現象が起きていた。 pingなども含めて一切外部との通信ができなくなる Claude Codeを一旦止めて数分待つと復活する この現象について知人に相談しながら対応を進めたところ解消できたので、ログとしてブログに残しておく。ただしネットワークについて専門分野ではないため、かなり間違ったことを書くかもしれない。その場合は指摘してもらえると嬉しい。 自宅ネットワークの構成 ISP: enひかり + v6プラスオプション ルーター: Aterm 2600HP4 再現させる まず再現はかなり簡単に取れた。Claudeを起動し、「どういう内容でもいいので、10並列で何かの調査を行なってみて」と指示を出すと、Explore SubAgentが一斉に起動する。

京都アジャイル勉強会LT大会 #118 - connpassに参加してきました。LT発表の内容の密度が高く非常に楽しめました。特にコンフリクトの話が面白かったので、ぜひ資料を公開してほしいと思いました。また懇親会でも深掘りした話が出来て良かったです。また忘年会があるらしいので行ってみようと思います。 僕はせっかくの勉強会ということで「EMこそClaude Codeでコード調査しよう」という発表をしました。資料はこちら。 speakerdeck.com 以下書き起こしです。 EMこそClaude Codeでコード調査しよう 開発チームを持つEMは、他チーム・他職種から質問を受けることが多い 回答する時どうする？ 詳しそうなエンジニアに聞く 自分でコードを読んでみる Claude Codeやcodexを活用して調査する 質問が来たら、EMこそClaude Codeでコード調査することをおすすめ

RAGでのデータ整形(改行・インデント)がLLMの回答精度に与える影響を検証したでは、ダミーのテストデータやテストケースを色々作っている。実はこのデータはAIと壁打ちしながら作ったので、やり方を共有する。 ダミーのテストデータを作る まずslack-explorer-mcpのメッセージ検索のレスポンスを模したダミーデータを用意したかった。流れとしては、slack-explorer-mcpで適当にメッセージ検索してJSONをゲット => そのJSONをClaude Codeに与えてダミーデータに変えてもらう、ということをした。 下記の会話内容が壁打ち&データ生成の流れ。最初からはうまくいかないので、データを作りながら修正していった。 > Slack Explorer MCPの挙動を色々試すため、ダミーのMessageのJSONを用意したい。以下のJSONをフォーマット例として、スレッド内メッ

slack-explorer-mcpでは、該当メッセージのpermalink URLをレスポンスで返さずに、利用側のAI Agentで組み立ててもらっている。なぜなら、permalinkをメッセージごとに返してしまうとトークン消費量が非常に多くなってしまうからだ。permalinkは他で返しているデータで再構築できるため省略し、利用側で組み立ててもらうことでトークン節約をしている。しかし、この方法だとうまくいったりうまくいかなかったりという現象が起きていた。 slack-explorer-mcpは現状はonelineのJSON形式で巨大なレスポンスを返している。これを人間にも読みやすい改行・インデントありのJSON形式にすることでLLMにとっても精度が上がるのかを知りたくなった。 そこで今回は、データの整形方法（改行・インデントの有無）がLLMの回答精度に与える影響を検証した。検証のテスト

最近Claude Codeのスラッシュコマンドなど、AIによるコード生成をさせる時、ドキュメントを参照するだけより、ドキュメントを参照した後に類似を自動検索させた方が生成の精度が上がると感じた。今回はその方法を紹介する。 ドキュメントだけで生成すると細かいニュアンスで気になることが多い コード生成をさせる時、何も無しでいきなり生成するよりも、コーディング規約やデータベース設計ガイドラインなど、チームで決めたルールを読み込ませてから生成する方が精度が上がると言われている。LLMの特性上、何もルールがないよりチームルールを明示することで、それに近いものが生成されるのは自明だ。 一方それだけだと「だいたい合ってるんだけど、細かいところで気になるなあ」と感じることが多かった。たとえば書き方がプロジェクト内の他の場所と少し違うなど。 ドキュメントを参照した後に類似を自動検索させる 「だいたい合ってる

AIコーディング関連で知見も溜まってきたので、「詳しくない分野でのVibe Codingで困ったことと学び」という発表をしてきました。発表資料を共有します。 speakerdeck.com オンラインで3年ぶり、オフラインで6年ぶりの発表だったっぽい...久々で緊張しましたが、良い発表の機会を作ってくれた運営の皆さまありがとうございました！ 以下、スライドを文字起こししたものです。 スライド文字起こし 今日話すこと Vibe Codingで、サーバーサイドエンジニアが経験のないiOSアプリを作った その中で困ったことと学びを紹介 初iOSアプリ開発のきっかけ その日やる気を出すためだけのシンプルなTODOアプリが欲しかった Vibe Codingによって、開発経験のないiOSアプリも簡単に高速に開発できるのでは？ 実際に作ってリリースした！ Daily Do AIをフル活用し、Vibe C

【2025/10/02補足追記】書き方が悪かったため対応関係が曖昧になっていたので追記。対応関係としては、変換層としてのLLM・コンパイラ・SaaS事業主で、SaaS事業主によるSaaS提供では内部の詳細仕様はブラックボックスのまま信頼するので確率的と捉えられるという話でした。以下対応関係のイメージ 自然言語 => LLM（もしくはAIエージェント） => コード 高級言語 => コンパイラ => アセンブリ 何らかの社会課題 => SaaS事業主 => SaaS 最近「高級言語 => コンパイラ => アセンブリのように、自然言語 => AI => コードもそのうちコードを見なくて済むようになる」のような話題を見かけることがある。しかしAIによるコード生成は、コンパイラじゃなく、むしろSaaSと比較するべきなのではないかと思った。 まずコンパイラとAIによるコード生成の決定的な違いは、決

この記事で紹介したSlack Explorer MCPをStreamable HTTPに対応した。どこかでホストしておけばChatGPTなどからRemote MCP経由で簡単に接続できるようになったので、その使い方を紹介する。 起動方法は以下の通り。 # Streamable HTTPモードで起動（デフォルトポート: 8080） docker run -i --rm --pull always \ -e TRANSPORT=http \ -p 8080:8080 \ ghcr.io/shibayu36/slack-explorer-mcp:latest # カスタムポートで起動 docker run -i --rm --pull always \ -e TRANSPORT=http \ -e HTTP_PORT=9090 \ -p 9090:9090 \ ghcr.io/shibayu36

自分がブログ記事を書いている理由の1つは、ブログを書くことで自分の理解が深まるからだ。そのため理解を深めたい内容だったら、AIにブログ記事を書かせるより、自分ですべて書いた方が良いと考えていた。 しかし最近、Claude Codeによる執筆環境を整えた結果、AIにブログを書かせた方が、むしろ自分の理解が深まっているのではと思い始めた。たとえば「経験を積むほどインプット出来ていない感覚になりやすいのではないか」という記事を書いたとき、このような感覚になった。 なぜこのように感じたのか、理由は大きく3つありそうだ。 AIがインタビュワーとして機能する。「それってどういうこと？」「具体例は？」といった問いかけによって、自分の中の暗黙知が引き出される 細かい文章表現に気を取られずに、「何を伝えたいか」「話題の繋がりは何か」という構造レベルの思考に集中できる AIがたまに自分の全く想像していなかった

あらたまさんの「なんとなく最近インプットできていない気がする」というポッドキャストを聞いて、自分も似た感覚を持っていることに気づいた。5年、10年とエンジニアを続けていると、こういう感覚になる人は多いんじゃないかと思う。このことについて自分の考えをXに書いたが、もう少し整理してブログにしてみる。 ある程度経験を積むと、一つの本から得られる新しい発見がどんどん減ってきて、結果としてインプットした気になれない、という感覚を僕は持ってしまってる 箸休め：インプット・アウトプット、もう疲れちゃって 全然動けなくてェ… #あらたまいくお https://t.co/ATNlcUr89n— 柴崎優季 (@shibayu36) 2025年9月16日 インプットが薄く感じる理由 そもそもインプットできた感覚ってなんだろうと考えてみると、新しい知識を多く学べた時に強く感じるものなのかなと思う。 エンジニアにな

Claude Codeを使って開発していると、生成されるcommit messageが冗長すぎるという問題に直面する。最近リリースされたサブエージェント機能を使うとこの問題を解決できたので、その方法を共有する。 Claude Codeのcommit messageの課題 Claude Codeのセッションで実装が終わったときに git commit を実行させると、以下のようなめちゃくちゃ冗長なcommit messageが生成される。 Add describe_tables e2e test and refactor MCP initialization - Add comprehensive e2e test for describe_tables tool - Refactor MCP server initialization into reusable functions - s

大吉祥寺.pm 2025に行ってきた。今回は前夜祭&懇親会、本編&懇親会&ナイトパーティと、すべてに参加して楽しみ切ってきた！ 発表として印象に残ったのは、yoku0825さん、sotarokさん、nrsさんの3人の発表だった。 まずyoku0825さんの「2025年になってもまだMySQLが好き」は、MariaDBとMySQLって単にforkされた似たものだと自分が思っていた無知を打ち砕かれる発表だった。logfileがMariaDBだと一本になってしまってあまりにも追記が早いとクラッシュするというのも面白すぎる。発表から「本当にMySQLが好きなんだな」という熱量を感じられてとても良かった。 sotarokさんの「大個人開発サービス時代にプラットフォームはどう生きるか」も印象に残った。Vibe Codingが出始めてから、自分もめちゃくちゃ個人開発が楽しいのでとても共感した。個人サービ