Hi

2月からClaude Codeを使い始めた。ターミナルから使えるAIコーディングエージェントで、コードの読み書きから実行まで自律的にこなしてくれるツールだ。前回のAgentic Codingの記事でも触れたように、仕様から実装まで任せられるようになってきている。使い始めて数週間、うまくいくパターンが見えてきた。一言でいうなら、Claudeをチームメンバーとして動かす意識を持つかどうかで、結果が大きく変わる。 バックログとドキュメントで共通認識を作る 思いついたことはとにかく起票する。実装中に別対応が必要になったものも、その場でチケットに起こしておく。これを徹底したことで、作業中に「あれもこれも」と頭が散らからなくなった。積み上がったチケットは重要度と前後関係で並べ直し、優先順位を明確にしながら進める。バックログの整理は、チームの足並みをそろえる作業とまったく同じだ。 CLAUDE.md に意図を、SPEC.md に仕様を書くようにした。これで人間もClaudeも迷う場面が明確に減った。「このプロジェクトでは何を大事にするか」「この機能の仕様はどうなっているか」が参照できる状態にあると、指示を出すたびに説明し直す必要がなくなる。新しいメンバーにプロジェクトの背景を渡すドキュメントを書く、という感覚に近い。 アプリの処理フローが複雑になってきたタイミングで状態遷移図を作ったのも同様の効果があった。どこが複雑なのかが一目でわかる。コードを直す前に「そもそもこの状態遷移をシンプルにできないか」という観点で考えられるようになった。 テスト・計測で品質の基準を揃える TDDを取り入れると、Claudeが実装中に不具合を自発的に見つけて対応してくれることが増えた。「このテストパターンだとこのケースが漏れていないか」と指摘もしやすくなる。共通のテスト基盤があることで、品質の議論が「感覚」から「事実」になる。 E2Eテストも同じ文脈で導入した。UIの挙動を変えたときの品質が担保できるし、エラーが出たときに「E2Eの何番がこけている、エラーメッセージはこれ」と伝えるだけで話が早い。再現手順を言葉で説明する手間が省けて、対話のテンポが上がった。 計測を徹底したことも大きかった。処理速度やレスポンスタイムを実測するようにしたことで、人間は「体感遅い」、Claudeは「理論上はやい」と違う基準で話していたのが、実測値で一本につながった。共通の基準があると、議論の質もコードの質も変わる。 振り返りとコミュニケーションで精度を上げる RETROSPECTIVE.md を作り、作業ごとに「良かったこと・伸びしろ・ネクストアクション」をまとめるようにした。振り返り用のスキルをClaude Codeに登録しておき、まずClaudeに下書きを書かせる。それを読んでフィードバックを出す、という流れだ。ネクストアクションのうちドキュメントで対応できるものはその場で更新、実装が必要なものはissueを立てて次に回す。振り返りを回すほどドキュメントが育ち、Claudeへの指示精度も上がっていく。 着手前に「作業手順や仕様で質問はある？」と聞くようにしたのも効果があった。実際に仕様の確認が返ってきて、自分の考慮が足りていない部分だったこともある。「着手したら実は仕様が曖昧だった」を事前につぶせる。チームでいえば、タスクに取り掛かる前のちょっとした確認と同じだ。 言葉の選び方も変わった。「根治」「徹底的」「念入りに」という言葉を使うと、ソースコードを探索するときの精度が上がった気がする。「根治」は特に効いた。不具合に遭遇したとき、その場しのぎで終わらせずに原因を取り除きにいってくれた。強い命令口調より、方針を示す言葉のほうが意図が伝わりやすい。 チームでのコードレビューと同様に、実装が一段落したら必ずレビューを挟む。Claude Code の /review コマンドはいい感じに不具合を拾ってくれる。/simplify は冗長なコードを整理してくれるが、コードを壊す可能性もあるので慎重に使っている。 雑感 振り返ってみると、ツールの方向性を示し続けるプロダクトオーナーとしての比重が大きかったと思う。一通り実装してPRを作ったら振り返り、次に何をしたらよくなるかを考える。そして次の振り返りで試した結果を確認する。Claudeが爆速で走れる状態を作ることがとにかく楽しかった。 この感覚は、スクラムマスターとしての経験が活きていると感じた。障害を取り除いてチームが動きやすい状態を作る、という役割がそのまま当てはまる。Claude Codeとうまくやるコツは、開発チームをうまく動かすコツと根っこが同じかもしれない。 今回はRust + Tauriという自分にとって未知の領域で試したが、知らない言語でも計測手段とゴールが揃っていれば任せられることがわかったのは収穫だった。ただし未検証の部分も残っているので、引き続き使いながら確かめていくつもりだ。 結局のところ、AIとうまくやるコツは、チームとうまくやるコツと同じだった。共通認識を作り、基準を揃え、振り返りで改善する。その繰り返しだと思う。

Vibe Codingを試してみた 「いい感じにして」とプロンプトを投げたら、数分で動くものが返ってくる。最近話題のVibe Coding、そしてその先にあるAgentic Codingを試している。 Vibe Codingはプロトタイピングにちょうどいい。簡単なプロンプトでサクッと作れるし、動かしてみて初めて機能の過不足に気づくこともある。思いついたアイデアを雑にでも形にできて、フィードバックループが短い。この速さが最大の魅力だと思う。 実際、ちょっとしたツールやスクリプトなら、プロンプトを1つ2つ投げるだけで動くものができあがる。「とりあえず触れるもの」が数分で手に入る体験は強力だった。 ただし、勢いで作っている分、どんな機能があるかは触ってみないとわからない。条件分岐の詳細を知ろうとすればコードを読むしかなく、そうなると作り直したほうが早い。裏側はAIがよしなに決めた構成になっているから、後から手を入れると、数年前に書かれたコードを読み解くような労力が生まれる。ここがVibe Codingの限界だった。 規模が大きくなると何が起きるか では、もっと大きなものを作ろうとするとどうなるか。プロンプトだけで指定しても、収拾がつかなくなる。長いプロンプトは解釈がブレやすいし、コンテクストウィンドウから溢れやすい。 そこで必要なのがドキュメントだ。仕様書や実装計画の叩き台を作り、フィードバックを出し、ブラッシュアップを繰り返す。 仕様書といっても「このような機能がほしい」を SPEC.md というファイルに列挙し、Claudeに根掘り葉掘り聞いてもらい、ブラッシュアップする。その SPEC.md に書かれた機能をいくつかの段階に分けて、最初にこれを作り、次にあれを作り、とわける。ドキュメントとしてはかなりライトだと思う。 ノリと勢いで投げるのがVibe Codingだとすれば、人間とAIがそれぞれ担当を決めてAIも自律して動けるのがAgentic Codingといったところだろうか。 Agentic Coding の始め方・ツール選び 自分が試しているのはClaude CodeとCodex CLI。どちらもターミナルから使うCLIツールで、エディタを選ばないのが気に入っている。 両方とも個人向けの一番安い有料プランでコーディングエージェントが利用できるので採用した。 今のところ、仕様作成から実装はClaude Code、細かい修正やコードレビューはCodex CLIの棲み分けになっている。 ここで重要なのがAIにプロジェクトの文脈を渡す仕組みだ。Claude Codeなら CLAUDE.md にプロジェクトのルールや構成を書いておくと、AIがそれを踏まえて動いてくれる。Codex CLIにも同様の仕組みがある。「このプロジェクトではこういう方針で」という申し送りをファイルに残しておく感覚だ。 小さく始めるなら、まずは既存プロジェクトのちょっとしたリファクタや、テストコードの生成あたりがおすすめ。いきなり大きな機能をまるっと任せると、期待と出力のギャップに戸惑う。小さいタスクで「AIとのやり取りの勘所」を掴んでから、徐々にスコープを広げていくのが無難だろう。勝手がわかれば、ベストプラクティスが参考にできるようになる、と期待している。 人間の役割はどう変わるか Agentic Codingを続けていると、自分の役割が明らかに変わってきた。 コードを書く時間が減り、代わりに増えたのは「何を作るか決める」「どう作るか設計する」「出てきたものをレビューする」時間。書く人から、考えて確かめる人へのシフトが起きている。 「何を作るか」「なぜ作るか」は、今のところ人間にしかできない。ドメイン知識や価値の判断はAIに丸投げできない領域で、ここの解像度が低いとAIの出力もぼんやりする。逆に、ここがしっかりしていればAIはかなり良い仕事をしてくれる。 品質の最終責任も人間にある。コードが正しいか、セキュリティに問題はないか、パフォーマンスは大丈夫か。こうした判断はレビューする側の力量次第だ。今回はあえて実装はAIに任せることにした。なので自分が担当するのは最初の実装のプランと成果物を使ってのフィードバックが主、それとAIに必要な情報が伝えられるようドキュメントの整備。 面白いのは、AIに指示を出すには要件を言語化しなければならないこと。「なんとなくこうしたい」では伝わらないから、自然と思考が整理される。副次的な効果だけれど、設計力を鍛える訓練にもなっている。 まとめ Agentic Codingは「使える」段階に入っている。ただし、魔法の杖ではない。雑に投げれば雑な結果が返ってくるし、的確に指示すればかなり良いものが出てくる。道具としての性質は、従来の開発ツールと変わらない。 自分としては、今後もAgentic Codingの比重を増やしていくつもりだ。何が作りたいのか考えることにもっと時間を使えるようになるのは、ありがたい方向性だと思っている。 興味がある人は、まず手元の小さなタスクで試してみてほしい。使ってみて初めてわかることが多いから。

ゆるっとSsalesforce co-meeting社のエンジニアが運営するオンライン勉強会、隔週でお昼の時間帯に30分枠で開催されている。 今回はその第50回目。 ゆるっとSalesforceトーク #50 Coral Cloud Resorts を触ってみた - connpass 開発者向けAgentforceはじめの一歩？ Coral Cloud Resorts を触ってみた これから触る人向けに軽くやっていきたい 去年の12月に公開されたデベロッパー向けのブログで存在を知った Salesforce、Data Cloud、Amazon S3を組み合わせたサンプルアプリケーション プロンプトのサンプルも提供されている。また、ページに Agent が組み込まれているので、すぐに試せる 実際に試してわかったこと 基本は Trailhead に従って環境を構築すれば良い 手順に関してはかなりざっくりと書いてある GitHub のリポジトリを参照しながら構築作業を行うが、高頻度で更新されているため、リポジトリ内の導入手順書通りにやってもエラーが出ることがある 別に公開されている記事を参考にすると、素早く環境構築がしやすい Agentforce と Data Cloud を使用した Salesforce組織が必要。Trailhead を利用すると、必要な機能が使えるSalesforce組織が無料で作成可能、5日間の利用期限あり インストールするパッケージのバージョンがドキュメントによって異なる。GitHubのドキュメントを確認した方が良い モデルは手作業で作る必要あり Amazon S3 から取り込む方法がどうも記述に間違いがあるらしい Agentforce の Workshop に沿ってやると理解が捗る ノート 無料で試せる環境が構築できるのはとても良さそう 他の会も含めて賑やか和やかに進行しているのがまたよき

全社キックオフに参加するため、出張することが確定したので荷物の整理をば。 今回はPC不要なので最小構成は、 会社のスマートフォン 1泊2日分の着替え 薬 私物のスマートフォン 充電器とケーブル こんなところ。 流石に心もとない、と増やしていた結果 会社のスマートフォン 1泊2日分の着替え 薬 ウィンドブレーカー 折り畳み傘 私物のスマートフォンx2 Apple Watch 充電器とケーブル Apple Watch充電器 MagSafe対応充電器 ワイヤレスイヤホン3つ となった。 最後のほうのワイヤレスイヤホン3つはやりすぎた。1つは耳栓代わりにしていたから、それは耳栓に置き換えようと思う。 充電器はケーブル付きバッテリー内蔵の3役兼ねるタイプで、USB-Cポートもあり、2台同時に充電できる。が、最大30W出力はスマートフォン2台だと出力不足のようで交代交代で充電した。たぶん、スマートフォン、ワイヤレスイヤホン、スマートウォッチの組み合わせなら、ばたばたせずに充電できたのだろう。 まだまだ削りようはありそうだから、いい塩梅の落としどころを見つけたい。削った結果、不便になったり現地調達する必要が出てくるのではちょっと困るのでして。

要約 仕事に忙殺されていた年だった。 以下、メモ プロジェクト進行 もっと良い進め方があったのでは、と思うがやるべき順に並べるとああいう優先順位になるのだろうか。 この納得をすると自分に過労の診断が出るのも既定路線になるので少しだけ複雑なものがある。少しだけ。 スクラムマスター兼プロジェクトリーダーもどき スクラムマスター兼プロジェクトのリーダーっぽいことをやっていたのがまず、負荷のかかりやすい働き方だったと思う。人より自分の抱えているタスク量には気を使って、場合によっては周りに任せたり、やらない判断を積極的にしていきたい。理想は、判断の流れと結果が可視化されていること。 スプリントが止まっていても、スクラムチームのメンバーを見て、何か躓いてそうなら話を聞きに行ったり、何でも質問を受け付けるようにしていた。これは単純に自分がシステムの全体を通しで知っていたからだろう。 意外だったのは、コードやドキュメントを読まない点。人に聞くよりまずはドキュメントが不十分だろうが何だろうがまずはコードとドキュメント、チャットのログを漁る癖があったのと、参画してそこそこ長かったという経験の賜物だと思う。 雑務 やめた人の引継ぎでコードとドキュメントを見て、実際どうだったのかを調べたり。 人の受け入れであーでもないこーでもないやったり。 情報がまわってこないので同じ部署の他チームに話を聞きに行ったり。 最終的にはどうなったのか 2023年の後半は過労で頭回らなくなってきて凡ミスも増えてきた。これは潮時だと思って休職の申請を出して、休みに入ったのが2023年の最後の動き。 2024年は? 会社規定の休職期間の上限に到達したので退職、様子見ながら新天地を目指すイメージ。 もう少し平和に働きたいもので。

コンスタントに更新するネタがないと、生存報告になるのはブログのお約束なのだと思う。 久しぶりすぎて、まず更新する仕組みが死んでいたので復活させることにした。 このブログは静的サイトジェネレータのHugo、ホスティングサービスのNetlifyで動いている。 Hugoはローカルでサーバーを動かして、サイトがどのように見えるか確認できるのだけれど、まずここで躓いた。エラーメッセージを見ると、どうやら使っていたデザインテンプレートが最新のHugoに未対応らしい。さくっと別のテンプレートに切り替え。 では、さっそくデプロイを……と思ったら、なかなか終わらない。 コンソールを見に行くとやっぱりエラーが出ている。ログを眺めてみると、デプロイ時のコマンドに旧テーマが指定されていた。 初期設定はNetlifyのウィザードにお任せしていたから、どこからどう設定すればいいのかわからない。変に楽をすると後から覚えるのが大変だ、と思いつつ、Netlifyの設定画面を片っ端から目を通す。が、見つからない。しばらく考えてから、エラーログを見ると、設定ファイルに記述されているらしい。 netlify.toml にあったのでよしなに変更して、再度デプロイ。無事に完了して、記事の公開にいたる、と。

意図しない全角スペースに振り回されたので、プログラミング向けのフォントで解決することにした。 今回はmiiton/Cica: プログラミング用日本語等幅フォント Cica(シカ)を採用。 プログラミング向けフォントで調べるとほかにも色々出てくるので試すのもまた一興かと。

救援部隊として参加する場合はこのような流れだと聞いた。 メンバーレベルで助っ人参加して似たような動きをしたし、おおよそ正しい方法だと思う。 これらの方法を実践するには、プロジェクト関係者全員の協力が必要不可欠なのが厄介な点。 既存メンバーの休養、ケア やる気が溢れすぎているので、1週間ほど定時退社してクールダウンしてもらう プロジェクトの要件把握 当初の要件 現在の要件 プロジェクトの進捗の把握 何を作ったのか 何が出来ていないのか テスト状況の把握 どこまでテストしたのか どれぐらいのテストをしたのか バグの出方などから、テストの甘い箇所の洗い出しを行う バグ密度から割り出すが今回は割愛 増援の場合は既存メンバーとの関係構築 これから何を作っていくのかの再定義 優先順位の高い機能から実装し、低い機能は二次開発に回す 何ができていたのか、できていないのかなどの洗い出しには模造紙に付箋を活用していると聞いた。 一目でわかりやすく、メンバー全員で状況把握や意見を出し合いやすくなるのだそうだ。 一言でいうならば 仕切り直しが大事

前回の更新から1か月ほど空いてしまった。 まだ生きてますとも。

要約 深夜のノリで軽い気持ちでドメインを契約したら1年間で43万円だった さすがに支払えない、と震えながらサポートセンターにキャンセルの依頼をして助かった 細かい話 このブログはNetlifyで運用している。標準のドメインだとやや恰好が悪いので新しく契約することにした。 ドメインの取得は過去に何回かやっていて、どのドメインも年数千円で維持している。その金額である程度の信用、移転してもURLが資産として活用できるのだから、コスパのいい投資だと思っている。 そんな金額にはならない、とどこかで油断していたのだろう。軽い気持ちでドメインを契約したらどうも、支払金額の桁数が多い気がする。 おかしいと思ってよくよく確認してみたら日本円にして43万円。 さすがにこれは重たい、と慌ててダッシュボードにキャンセルのボタンがないかを探す。しかし、見当たらない。 しばらく考えて、もう、サポートに直で頼み込むしかない、とチャットを開いて、間違って契約してしまったのでキャンセルしたい、とストレートに打ち明ける。 確認のやり取りのあと、希望する返金の方法の確認があり、滞りなくキャンセルされた。 契約するときはちゃんと、金額を確認しましょう、というお話でした。