Hi

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万円。 さすがにこれは重たい、と慌ててダッシュボードにキャンセルのボタンがないかを探す。しかし、見当たらない。 しばらく考えて、もう、サポートに直で頼み込むしかない、とチャットを開いて、間違って契約してしまったのでキャンセルしたい、とストレートに打ち明ける。 確認のやり取りのあと、希望する返金の方法の確認があり、滞りなくキャンセルされた。 契約するときはちゃんと、金額を確認しましょう、というお話でした。

結論から言うと、 「詳細設計は必要、詳細設計書も必要」 と考えている。 ただ、コスパの良い詳細設計書の書き方は見つかっていない。 作る上では考えているのにアウトプットができないとはこれいかに。 詳細設計書とは ウォーターフォール型の開発だとこのようなドキュメントが作られる。 要件定義書 クライアントと話して何が必要なのかをまとめたもの 基本（外部）設計書 要件定義書をもとに画面や機能を詳細化したもの 詳細（内部）設計書 基本設計書をもとに各画面、各機能を具体化したもの これをもとにコードが書かれる 単体試験仕様書 実装した各画面、各機能単位のテストのための仕様書 単体試験エビデンス 単体試験の結果をまとめたもの 結合試験仕様書 システム全体のテストのための仕様書 結合試験エビデンス 結合試験の行った結果をまとめたもの 詳細設計書をもとにコードを書いたり、単体試験仕様書を考えるので、ないと困る代物である。 不要といわれる理由 Excel方眼紙を使った詳細設計書のメンテナンスを経験するといらない、と言いたくもなる。 ただでさえ、セルの結合と解除でぐずぐずになりやすいのに 手動で版管理する 共同編集ができない（新しいExcelではできる） あたりが組み合わさると、編集コストがかさんで気軽に直せなくなる。あるいは、修正するファイルを間違えたりする。 仕様書とコードの乖離が激しくなると、仕様書を見る機会は減り、仕様を考えている人と実装する人が直接やり取りして完結するようになる。 そして、納品物として必要だから書いているそれらしい仕様書、という本質を見失ったドキュメントが誕生する。 そういう背景はあるものの システムを作る上の共通の言語として、詳細設計書は必要だと思う。 ごりごりのフォーマットに落とし込んだ何かではなくてもいい。詳細設計を考えた時のアウトプットをすることで、自身の理解が深まるし、まとまっていればのちの改修作業で重要な情報になる。 ほかの人の読みやすさを少し意識すれば、自分はこのように考えています、と説明もしやすい。 案 詳細設計書 Excelかスプレッドシート 図式を使えるのは表計算系ソフトなので、セル結合は避けるなどルールを作って編集コストを下げられるのでは? Markdown対応のWiki 簡単な表組ならできるし、表現力は十分にあるように思う MkDocsなどのドキュメント生成ツール Markdownで書いてさっとアップできる テーブル仕様書 テーブル定義ファイルから自動生成 丁寧にコメント入っているなら定義ファイルを読めば事足りそう 関数・API仕様書 コードから自動生成 自動生成前提でコメントが入っているなら、コードを読めば事足りそう ざっと思いつくのはこんなところ。 改めて調べてみると、様々なやり方、ツールがあるので、コスパよくドキュメントにできるかもしれない。 雑感 今のところはMarkdown対応のWikiにまとめている。Excel方眼紙でないだけでやる気でるのだから面白い。