Contents
どうも、ゆるめのミニマリスト＆へっぽこSEのアシアです。
今日の話は…
アシア
こちらの話の続き、Claudeのカスタマイズのスキル編。
あくまでリポジトリ上の話。
カスタマイズのスキル、つまり、アカウントに紐づいているスキルはまた別の話。
アカウントではなくリポジトリに紐づけるなら「使うのはチーム全員。ただし使っている生成AIエージェントはメンバーによって違ったり、同じメンバーでも変化していく」を意識しています。
どのAIからも参照する共通ルール置き場を作る
doc フォルダーを作成
まずは、共通ドキュメント的なものがまったくないので、docフォルダーを作成。
転職してきてまず最初にビックリしたのが、ドキュメントのなさだよ。
代わりにあるのは「当時、作成した設計書」ばかり。
当然、その当時に開発していた機能の、当時の改修内容しか書いてない。
全体像はどこだよ状態で、最近になってようやく本当に概要だけまとめたところ、なんて有り様。
今後、AIエージェントに実装させるにあたって、まず使いそうなものを最低限リポジトリのdocフォルダーにMarkdown形式でまとめるところから整備。
このまとめ方（フォルダー階層やフォーマット等）も、AIと「今後メンテしやすいか」「更新を忘れないか」等を議論しながら決めました。
例えば、DBのテーブル定義は、AIがymlで編集するけど、PR発行したらMarkdownに変換されるようにしたり。
ただ、機能の説明やどんなテストをしたかは、リポジトリまで参照しないPMやQAと共有が必要なので、難しいところ。
今後の要検討ポイントにして、ひとまず今は導入編と割り切って、必要最低限を整備。
.ai フォルダーを作成
Codexだろうが、Claudeだろうが、Copilotだろうが、全AIが守るべきルールをまとめます。
AIエージェントとしての振る舞いのルールや、コーディングルールなど、目的に応じてファイルを別けていく。
AIエージェントとしての振る舞いには「コーディングルールを参照する。そのコードに指摘をされた場合、指摘が妥当か検討、妥当なら修正。さらにコーディングルールに反映して再発防止も検討する」みたいなルールを書いておく。
あとは「再発防止策はメモリに保存せず、必ず .ai フォルダーに反映して二重管理を許さない」とか。
コーディングルールは、最初はジュニアさんに教えるように丁寧に説明して、ルールに起こしてもらう。
あとはClaudeに書かせたコードをCopilotにレビューさせて、指摘をコピペしたり。
いずれにせよ、何度か小さなタスクを一緒にこなして「じゃ、ルールに書いて」を繰り返して、５回くらいに渡って育てていきました。
特に私は「５年後、10年後もメンテがしやすい設計」と「新規参画者にも当時の判断がわかるコメントがあること」を重要視する保守性大好き人間なので、人間相手じゃ「これでも動くからわざわざ指摘するのもなぁ」と思うこともガンガン指摘していきます。
まぁ、人間相手でも思うだけで、ガンガン言うけどね！！！
ついでに前職では、要件定義からひと通りの開発も、マニュアル作成も、問合せ対応もしていた身。
エンジニアの悪癖 ↓ は見つけ次第、止めるようにルールへ反映させていきました。
- 似たようなことを何度も書く
- 網羅性を重視して、稀で通常起こらないことに文量を割く
- 長ったらしい日本語
単純に↑をやめるように書いても効果は薄いので、見つける度に指摘して、ほどよく抽象化させて反映させる。
抽象化させるときも「そういうことじゃないんだよ」ってことが何度かあったので、最初は多少の時間は初期投資だと思うことにした。
さらに小さな改修タスクを並走したセッションで「今後は、改修したいことが書いてあるJIRAと、ドキュメントの作成場所を指定したら、プルリク発行手前まで行い、手動テストまで完了を指示されたらプルリク発行を行い、レビュー完了を指示されたらQAへの申し送りJIRAを起票できるようフローもまとめて」と指示して、開発フローもまとめておく。
エンジニアの悪癖を許さなかったおかげで、２～３バグの改修でかなり読みやすい設計書を書くようになった！
各AIエージェントの参照ファイル（CLAUDE.md、AGENT.md等）は最低限
.aiフォルダーやdocフォルダーを参照する旨は、全AIの入口に同じルールを書いておく。
もちろんこれも .ai フォルダーのAIエージェントの振る舞いルールに「入口を修正するときは、他のAIの入口も同時に修正すること」を書いてある。
最後に、私はClaudeを中心に使っているので、「これはClaude特有っぽいな」と思った改善ポイントは、CLAUDE.md や setting.jsonに反映。
例えば「既存ファイルはエンコードを変えない」ってルールの追加や、「ファイルを追加したらエンコードをチェックする」Hookを作ったり。
Claude用スキルは今のところ２つだけ
１つはCopilotにレビューさせて、指摘を反映するスキル。
これはClaudeとCopilotが併用できるメンバしか使えないってことだけど、ClaudeとCopilotは同じコードでも見る観点が微妙に違うので、あれば助かる。
とはいえ、私自身が開発担当者になることがめっきり減って、メンバーのマネジメントばっかりなので、あまり使ってない。
メンバーが使ってくれれば良い。
もう１つは、開発フローを開始するだけのラッパーなスキル。
いつまでClaudeが主流の生成AIエージェントでいられるかわからないので、「ルールやフローはすべて .ai フォルダーにある。Claudeのスキルをそれを呼ぶだけ」にしたい。
まだ他のClaudeユーザーに使ってもらってないので、ルールがちゃんと作れているのか、私のClaudeが慣れてうまくやってくれているのか、の切り分けはできてない。
テスト仕様書・証跡のあり方は慎重に
ウォーターフォールもアジャイルも、結局は「人間が開発をする」前提で組まれている。
でも生成AIが一緒に仕事をしてくれる前提になると、今までのフローが最適解だとは限らない。
となると、今の自分がやっていた開発タスクをAIに置き換えるだけではダメ。
特に抜本的に見直せそうな気がしているのが、テスト関連。
テスト設計、仕様書作成、自動テスト消化、手動テスト消化、そして消化したテストの証跡。
- テストしなければいけない観点は、人間もAIも変わらない
- テスト仕様書のあり方が変わっても、AIと人間どちらにも使いやすいことが大事
この２点を念頭に、どうあるべきかをClaudeのFableさん登場から議論し合っている。
良い答えが見つかりそうなんだけど、実際に自分が実装＆テストするタスクをほとんど抱えてないので、試す機会がなかなかないんだよなー！
暇が欲しいけど、毎日グランドラインの航海士気分なので、まだ暇がとれなーい！
というか「暇がない」なんて言い訳だな。
時間は作るものなんだけど、今は「経験則で要件定義ができる、から、標準モデルを理解した上で要件定義ができっる」を目指しているから、そっちの参考書読んだり、実際に要件定義することを優先しちゃっている。
時間は有限なのでね。
ただ、実際に作業すると楽しそうなので、次にやりたいことはテスト工程の抜本的刷新、って感じ。
他にもニッチなIT関連要素をまとめていますので、よければ一覧記事もご覧ください。
