目次
はじめに
コードを書き終えてからレビューをして、「設計的にまずいですね」と言われ、大量の修正に追われる──そんな経験、ありませんか？
AIにコードを書かせるのは簡単になりましたが、"設計のズレ"まで自動で気づけるわけではありません。
レビューに出す頃には、手戻りにかかるコストが高すぎます。全体を見直す余裕なんてないし、そもそもレビューする側も見る範囲が多すぎて大変です。
以前の課題
- 修正が間に合わない
- 想定していた工数を超える
- 本来やるべきことに時間が使えない
レビューで詰まると、現場全体が"高負荷状態"になってしまいます。
現状の課題
コードレビューを"最後にやるもの"と決めつけた結果、現場は悪循環に陥った
「まずはコードを全部書いて、あとでレビューする」──これは一見、自然な開発の流れに見えます。
しかし、以下のような設計的な問題が見つかったとき、大きな改修が必要になります：
- 責務が混ざっていて、処理を分けないと再利用できない
- UIに状態ロジックが入り込みすぎていて、テストしづらい
- 本来の役割が分からない、読みづらい構造になっている
- 下位モジュールとの依存関係が崩れていて、共通化も再利用も難しくなっていた
- インターフェースの設計が曖昧で、何を渡して何が返るか判断しづらい
スケルトンレビューという考え方
スケルトンコードとは
スケルトンコードとは、「処理の中身」は書かずに、クラスやメソッド、責任の流れだけを記述した構造コードです。引数や戻り値、コメントで"何を受け取り、何を返すか"を表現し、役割やつながりが明確に見えることを重視します。
記載例
// ユースケース層の例
class UserRegistrationUseCase {
constructor(
private readonly userRegistrationService: UserRegistrationService,
private readonly userRepository: UserRepository,
private readonly notificationService: NotificationService
) {}
public async execute(request: UserRegistrationRequest): Promise<UserRegistrationResponse> {
// TODO: ユーザー登録のユースケース
// - 入力値の変換（DTOへのマッピング）
// - ビジネスルールの適用
// - サービスの呼び出し
// - 結果の変換
}
}
// コントローラー層の例
class UserController {
constructor(
private readonly userRegistrationUseCase: UserRegistrationUseCase
) {}
public async registerUser(req: Request, res: Response): Promise<void> {
// TODO: HTTPリクエストの処理
// - リクエストのバリデーション
// - ユースケースの呼び出し
// - レスポンスの生成
// - エラーハンドリング
}
}
// サービスの実装例
class UserRegistrationService {
public async register(userDto: UserDto): Promise<void> {
await this.validate(userDto);
await this.save(userDto);
await this.notify(userDto);
}
private async validate(userDto: UserDto): Promise<void> {
// TODO: 入力バリデーション
// - メールアドレスの形式チェック
// - パスワードの強度チェック
// - 必須項目の存在チェック
}
private async save(userDto: UserDto): Promise<void> {
// TODO: 永続化処理
// - ユーザー情報のDB保存
// - トランザクション管理
}
private async notify(userDto: UserDto): Promise<void> {
// TODO: 通知送信
// - 登録完了メールの送信
// - 管理者への通知
}
}
このように、各レイヤーの責任と役割が明確に分かれた構造になっています：
- コントローラー層：HTTPリクエスト/レスポンスの処理
- ユースケース層：アプリケーションのビジネスロジックの調整
- サービス層：ドメインロジックの実装
AIでレビューの精度とスピードが変わる
効果的な質問例
ChatGPTなどに、スケルトンコードを提示して以下のような質問をしてみましょう：
責務と構造に関する質問
- この構造は、責務が適切に分かれていますか？
- このファイル配置で、テストしやすい構造になっていますか？
- STS（Source Tranfer Sink)構造の観点から、判断ロジックは適切な位置にありますか？
- 採用しているアーキテクチャと整合が取れていますか？
- レイヤー構成と責任の切り分けは一致していますか？
- メソッドの中のビジネスロジックの責任範囲は明確ですか？
依存関係に関する質問
- この依存関係の方向は、クリーンアーキテクチャの原則に従っていますか？
- 内側のレイヤーが外側のレイヤーに依存していないか確認できますか？
- インターフェースを通じた疎結合が実現できていますか？
- インフラ層の依存が適切に分離されていますか？
- 新しい機能を追加する際の影響範囲は最小限に抑えられていますか？
- モックやスタブを使ったテストが容易な構造になっていますか？
実践的な導入ステップ
-
スケルトンコードの作成
- クラスとメソッドの構造を定義
- 責任の流れを明確化
- コメントで意図を記述
-
AIレビューの実施
- 構造的な質問を投げかける
- 指摘された点を検討
- 必要に応じて構造を改善
-
実装の開始
- レビュー済みの構造に基づいて実装
- テストの作成
- コードレビューの実施
成功事例と効果
実際にスケルトン×AIレビューを導入してみて、驚くほどの効果を実感しました。
私には、設計技術の師匠がいます。師匠との出会いがなければ、このレビュー手法を身につけていませんでした。師匠に出会う前は、1つのコードレビューに30分以上もかかっていました。「このコードは動くのか」「このフラグの使い方は大丈夫か？」「引き数を追加されたけど、その使ってるクラスは・・・」── あれこれ気になり、一行一行を丁寧に追いかけていました。
しかし、師匠は言いました。「コードを上から一行一行なぞってレビューするのは、時間の無駄だよ」。その言葉に衝撃を受けました。レビューとは「全部を見ること」ではなく、「見るべき場所を決められる構造をつくること」だと気づいたのです。
そして今、スケルトン×AIレビューを実践することで、コードレビューは数分で完了するようになりました。レビュー時間は平均で50%削減され、実装からテスト完了までの工数も約半分になりました。これだけでも十分な効果ですが、それ以上に大きな変化がありました。
設計技術力の向上を実感
最初は「AIに設計レビューを任せて大丈夫だろうか」という不安もありました。しかし、実際に試してみると、AIとの対話を通じて、自分自身の設計の考え方がどんどん整理されていったのです。
特に印象的だったのは、設計の「なぜ」を説明する力がついたことです。AIに「この構造は適切ですか？」と問いかけると、必ず「なぜその構造にしたのか」という理由を求められます。この繰り返しの中で、設計の判断基準が自然と言語化され、チーム内での共有も容易になっていきました。
師匠から学んだ「見るべき場所を決められる構造をつくる」という考え方と、AIとの対話が組み合わさることで、レビューの質と速度が劇的に向上したのです。
チーム全体の変化
この変化は個人の成長にとどまりませんでした。設計レビューの基準が明確になったことで、チーム全体の設計力が向上していったのです。
以前は「この設計は良くない」と言われても、なぜ良くないのか、どう改善すべきかが曖昧でした。しかし、スケルトン×AIレビューを導入してからは、設計の是非を具体的に説明できるようになり、新人メンバーへの指導も格段にしやすくなりました。
実感した効果
- レビュー時間が半分になり、チームの負担が大幅に軽減
- 設計の判断基準が明確になり、チーム内の議論が活発に
- 新人メンバーへの設計指導が具体的になり、教育効果が向上
- コードの品質が向上し、バグの発生率も30%程度減少
- 設計の「なぜ」を説明する力がつき、チームの技術力向上につながった
特に大きな効果を実感したのは、アーキテクチャの一貫性が保たれることです。数十年にわたって運用されているプロダクトでは、新機能の追加や変更のたびに、アーキテクチャが徐々に崩れていくことが課題でした。
師匠から聞いた話ですが、一般的なプロダクトでは、3年ほど機能追加を続けると、必ずどこかでアーキテクチャが崩れ始めるそうです。これは、機能追加のたびに「今回は特別」「この機能だけは例外で」という判断が積み重なり、設計の一貫性が失われていくためです。
「この変更は既存の設計原則に合っているか」
「この実装は将来の拡張性を損なわないか」
「この修正は他の機能に影響を与えないか」
── スケルトン×AIレビューを導入してからは、こうした重要な判断が、実装の前段階で明確になりました。その結果、長期的なプロダクトの品質維持が格段に容易になったのです。
おわりに
ChatGPTなどのAIは、正解を出す存在ではありません。しかし、"問いかける相手"としてはとても優秀です。
設計レビューに悩んでいたら、スケルトン×AIというアプローチ、ぜひ一度試してみてください。きっと、あなたの設計技術力も、チームの開発効率も、想像以上に向上するはずです。
あわせて学びたいコンテンツ
また、今回紹介した内容をより実践的に学びたい方には、以下のUdemy講座もおすすめです。
🎓 Udemyコース（8,800円 → クーポンで割引中）
▶️ AIとC#で極める！クリーンコードの技法（限定クーポン付き）
- C#でクリーンコードと設計力を身につける実践講座
- ChatGPTの活用方法や、伝わるコードの考え方を解説
📘 出版書籍『あきらめない者たち』
▶️ Amazonで見る
- 技術の基礎からやり直すために、なぜ一歩勇気を振り絞れたのか
- 自身の成長と再出発を描いたノンフィクション作品