「作って終わり」をやめたくて、要件定義からテストのレビューまで、9つのスキルを自作した話

チャットで作るたびに、品質がぶれていた

前回、請求書自動化ツールやクレカ明細ダッシュボードを作ったとき、要件定義書と設計書を先に作ってから実装する、というやり方を試しました。これが思った以上によくて、「なぜこの機能があるのか」を自分でちゃんと説明できるものができました。

ただ、チャットでClaudeと会話しながら要件定義書や設計書を作っていくと、その時々のやり取りの流れによって、できあがるものの品質が毎回微妙に違ってくるという課題もありました。ある回は項目が細かく詰められているのに、別の回は同じように聞いたつもりでも粒度が粗くなっていたり。会話ベースで作る以上はある程度仕方ない部分ではあるものの、いつも同じ水準のアウトプットになってほしい、という思いがありました。

Claude Codeに「スキル」を持たせる

この「毎回同じ品質にならない」という課題を解決してくれたのが、Claude Codeの「スキル」という仕組みでした。あらかじめ決まった手順や観点をまとめたお作法集のようなもので、これを読み込ませておくと、毎回同じクオリティ・同じフォーマットで作業をしてくれるようになります。

このスキルを自作するための「skill-creator」という仕組みを使って、開発の一連の流れをカバーするスキルを1つずつ作っていきました。最終的にできあがったのは、次の9つです。

• 要件定義書を作る

• その要件定義書をレビューする

• 設計書を作る

• その設計書をレビューする

• 設計書をもとに実装する

• テスト設計書を作る

• そのテスト設計書をレビューする

• 実際にテストコードを書いて実行する

• そのテスト実行結果をレビューする

「作る」の後に必ず「確認する」が対になっているのがポイントです。要件定義書を作ったら要件定義書をレビューし、設計書を作ったら設計書をレビューし、テストを実行したらその実行結果までレビューする。ひとつ作業が終わるたびに、もう一人の自分がチェックを入れる形にしています。

それぞれのスキルが見ている場所

要件定義のスキルは、「なぜ」「何を」作るのかを対話形式で言葉にしていき、機能要件・非機能要件・スコープなどを決まった型で書き出します。対になる要件レビューのスキルは、その要件定義書「だけ」を読んで、抜け漏れや曖昧な表現、矛盾がないかをチェックしてきます。

設計書のスキルは、要件定義書を受け取って、データベース設計やAPI設計、画面遷移などを詳細に詰めていきます。対になる設計レビューのスキルは、設計書単体ではなく要件定義書とセットで読み比べて、「要件がちゃんと設計に反映されているか」まで見てくれるのが特徴です。実装のしやすさを優先して、いつの間にか要件からズレた設計になっていないか、というところまで気にしてくれる感覚です。

実装のスキルは、設計書と要件定義書を読み込んで、Claude Code上でタスクを一つずつ管理しながらコードを書き進めていくものです。ここだけ、対になるレビュースキルを作っていません。コードそのものの正しさを検証するのは、次のテストの工程の役目だと考えたからです。
(後々、Claudeが公式で実装のレビュースキルを出していることを知ったのは内緒の話。。ｗ)

テスト設計のスキルは、要件定義書・設計書に加えて、実際に動いているコードまで読みにいきます。書類だけを見ていては気づけない、コードの実際の挙動に起因する問題にここで気づけるのがポイントですが、何か見つかったからといって勝手に直しにいくことはしません。ここは一旦作業を止めて必ず私に確認する、というルールにしています。テスト設計レビューのスキルは、そのテストケースが要件を漏れなくカバーできているか、境界値や異常系までちゃんと考えられているかをチェックします。

そして最後のテスト実行のスキルが、実際にテストコードを書いて動かし、結果をテスト設計書に記録します。テスト実行レビューのスキルは、その結果とテストコード自体を見て、検証が形だけになっていないかを常に疑ってかかる役目です。テストが甘いと、いくら「テストOK」と書いてあっても意味がないので、ここは特に気をつけて作ったところです。

勤務先ニュース通知ボットで、実際に一気通貫させてみた

このスキル一式を最初にフルで試したのが、自分の勤務先のニュースをLINEに毎朝通知してくれる、個人用の小さなボットでした。子供が産まれ育休に入ったので会社との接点が薄くなり、このままだと帰属意識がどんどん薄れてしまいそうだと感じたのがきっかけです。

要件定義から設計、実装、テスト設計、テスト実行まで、9つのスキルを順番に呼び出しながら進めていったところ、思っていた以上にすんなり最後まで辿り着けました。会話の流れでその場しのぎに機能が増えたり減ったりすることがなく、各工程で作ったものがそのまま次の工程に引き継がれていく感覚があり、途中で迷う場面がほとんどありませんでした。

実際、スキルを使ったことでバグを検出できた例もあります。テストの工程では、設定ファイルの読み込みに失敗したときにデータベースが正しく初期化されず、エラーで止まってしまうという実害のあるバグが見つかりました。要件定義や設計のレビューだけでは気づけなかったタイプの不具合で、「実際に動かして確かめる」工程まで含めてスキル化しておいてよかったと思った瞬間です。

バグだけでなく、要件レビュー・設計レビュー・テスト設計レビュー・テスト実行レビューといったレビュー系のスキルでも、それぞれの段階で細かい指摘をいくつか拾って直しています。派手な指摘ではありませんが、「一人で書いて一人で読み返す」だけでは見逃していたであろう箇所です。

そうして最終的に、毎朝会社のニュースをLINEに届けてくれる小さなツールが、要件定義から実装、テストまでの流れをひと通り踏んだ状態で完成しました。

9つのスキルは、次のプロジェクトでもそのまま使い回せる

要件定義から実装、テスト、そしてそのレビューまで。9つのスキルは、一度作ってしまえば次にどんなプロジェクトを始めるときも、同じ型をそのまま持ち込めます。今回は勤務先のニュース通知ボットで試しましたが、同じ流れはこの先の個人開発にもそのまま使い回せるはずです。

一つずつは地味な工程の積み重ねですが、9つ揃って初めて、要件定義から実装・テストまでを一気通貫でカバーできる仕組みになりました。次に何かを作るときも、まずはこの9つのスキルを順番に呼び出すところから始めようと思っています。

実際、以前作ったLINEからOutlookカレンダーへのbotツールをバージョンアップした際にも、このスキル一式を使いました。そのときの話は、また別の記事でまとめる予定です。