【第5回】Claude Codeでユースケースを整理する｜機能の粒度と責務の考え方

社員ブログ

※Claude Codeを使用して記事を作成しています。

前回の記事では、アーキテクチャ選定をClaude Codeと一緒に進める方法を紹介しました。

今回のテーマは、

「ユースケースの整理」

です。

設計を進めていくと、

  • この処理はどこに書くべきか
  • 機能をどこまで細かく分けるべきか
  • 責務が重なってきた

という悩みが出てきます。

Claude Codeを使いながら、ユースケースの粒度と責務を整理する方法を実例で解説します。

ユースケースとは何か

ユースケースとは、

「アプリがユーザーのために行う、ひとつの操作」

です。

たとえばメモアプリであれば、

  • メモを作成する
  • メモを取得する
  • メモを削除する
  • タグでメモを絞り込む

それぞれが、ひとつのユースケースに対応します。

アーキテクチャの文脈では、ユースケースはDomain層に置かれることが多く、

  • ViewModelからの呼び出しを受け取る
  • Repositoryを呼び出してデータを操作する
  • ビジネスロジックを担う

という役割を持ちます。

なぜユースケースの整理が重要なのか

ユースケースを整理しないまま開発を進めると、以下のような問題が起きやすくなります。

  • ViewModelにビジネスロジックが溢れ、肥大化する
  • 同じ処理が複数の場所に重複して書かれる
  • 機能追加のたびに既存コードへの影響範囲が広がる

ユースケースを整理することで、

「この処理はここに書く」

という判断軸が生まれ、コードの置き場所に迷わなくなります。

Claude Codeはユースケース整理の何を助けるのか

ユースケースの整理は、正解がひとつではない領域です。

Claude Codeは、

  • ユースケースの候補を洗い出す
  • 粒度が適切かを確認する
  • 責務が重なっていないかを整理する
  • 分割・統合の判断軸を提示する

という形で、思考を整理するパートナーになります。

実例：メモアプリのユースケースを整理する

ここでは、タグ機能が加わったメモアプリを例に、ユースケースを整理する流れを紹介します。

ステップ1：ユースケースの候補を洗い出す

まず、このアプリで必要なユースケースの候補をClaude Codeに洗い出してもらいます。

【質問例】
メモアプリにタグ機能を追加します。
以下の機能一覧をもとに、ユースケースの候補を洗い出してください。

【機能一覧】
- メモの作成・編集・削除・一覧取得・詳細取得
- タグの作成・削除・一覧取得
- メモへのタグ付け・取り外し
- タグによるメモの絞り込み

各ユースケースの名前と、何をする処理なのかも合わせて整理してください。

Claude Codeが返す候補例です。

【ユースケース候補】

■ メモ関連
- CreateMemoUseCase：新しいメモを作成する
- UpdateMemoUseCase：既存のメモを編集する
- DeleteMemoUseCase：メモを削除する
- GetMemoListUseCase：メモの一覧を取得する
- GetMemoDetailUseCase：メモの詳細を取得する

■ タグ関連
- CreateTagUseCase：新しいタグを作成する
- DeleteTagUseCase：タグを削除する
- GetTagListUseCase：タグの一覧を取得する

■ メモとタグの関連
- AddTagToMemoUseCase：メモにタグを付与する
- RemoveTagFromMemoUseCase：メモからタグを取り外す
- GetMemoListByTagUseCase：タグでメモを絞り込んで取得する

この一覧をベースに、粒度が適切かを確認していきます。

ステップ2：粒度が適切かを確認する

洗い出したユースケースに対して、粒度の観点から確認します。

【質問例】
AddTagToMemoUseCaseとRemoveTagFromMemoUseCaseは
別々のユースケースにすべきか、ひとつにまとめるべきか、判断軸を教えてください。

Claude Codeが返す回答例です。

【回答例】

別々にすることを推奨します。

理由：
- 付与と取り外しは、呼び出されるタイミングが異なる
- 処理の内容（INSERT と DELETE）が明確に違う
- 片方だけのテストが書きやすくなる

まとめてよいケース：
- 両方が常にセットで呼ばれる場合
- 処理が非常にシンプルで、分けることで逆に複雑になる場合

このように、

「なぜ分けるのか・なぜまとめるのか」

の判断軸を理解することが大切です。

ステップ3：責務が重なっていないかを確認する

ユースケースが増えてくると、処理が重なる部分が出てくることがあります。

【質問例】
GetMemoListUseCaseとGetMemoListByTagUseCaseは
処理が似ているように思います。
ひとつのユースケースにまとめる選択肢はありますか？
メリット・デメリットも教えてください。

Claude Codeが返す回答例です。

【回答例】

■ まとめる場合
設計：GetMemoListUseCase(tagId: String? = null)のように
     引数でタグ指定の有無を切り替える

メリット：
- ユースケースの数が減り、管理しやすくなる
- ViewModelからの呼び出しがひとつで済む

デメリット：
- 引数の有無で処理が分岐するため、テストケースが増える
- ユースケースの責務が「一覧取得全般」と曖昧になる

■ 分ける場合
メリット：
- それぞれの処理が明確で、テストが書きやすい
- 片方を変更しても、もう片方に影響しない

デメリット：
- ユースケースの数が増える

推奨：
機能が今後増える予定がある場合は分けておく方が安全です。
シンプルさを優先したい場合はまとめる選択肢もあります。

どちらが正解というわけではなく、プロジェクトの方針に合わせて判断します。

ステップ4：ユースケースの責務を言語化する

整理ができたら、各ユースケースの責務を一文で言語化しておきます。

【質問例】
以下のユースケースについて、「このユースケースが担う責務」を一文で表現してください。

- GetMemoListUseCase
- GetMemoListByTagUseCase
- AddTagToMemoUseCase

Claude Codeが返す例です。

【責務の言語化例】

- GetMemoListUseCase
  → 保存されているすべてのメモを一覧で取得する

- GetMemoListByTagUseCase
  → 指定したタグが付いているメモだけを絞り込んで取得する

- AddTagToMemoUseCase
  → 指定したメモに、指定したタグを付与する

責務を一文で言語化できるかどうかが、ユースケースの粒度が適切かを判断するひとつの目安になります。

一文で表現できない場合は、責務が多すぎるサインかもしれません。

ステップ5：ViewModelとの関係を整理する

ユースケースが整理できたら、ViewModelからどう呼び出すかを確認します。

【質問例】
メモ一覧画面のViewModelでは、どのユースケースを使いますか？
また、ViewModelがユースケースを呼び出す責務と、ユースケース自身の責務の違いを整理してください。

Claude Codeが返す回答例です。

【回答例】

■ メモ一覧画面のViewModelで使うユースケース
- GetMemoListUseCase：画面表示用のメモ一覧を取得する
- GetMemoListByTagUseCase：タグ絞り込み時のメモ一覧を取得する
- DeleteMemoUseCase：一覧画面からメモを削除する

■ ViewModelの責務
- UIの状態（uiState）を管理する
- ユーザー操作を受け取り、適切なユースケースを呼び出す
- ユースケースの結果をUIの状態に変換する

■ ユースケースの責務
- データの操作をRepositoryに委譲する
- ビジネスルールに基づいた処理を行う
- ViewModelやUIの都合を知らない

【重要な考え方】
ユースケースはViewModelの都合を知る必要はありません。
「誰が呼んでも同じ結果を返す」ことが、ユースケースの独立性を保つポイントです。

この整理を理解することで、「どこに何を書くか」の判断が明確になります。

ユースケース整理でよくある悩み

「UseCase層は本当に必要？」

小規模なプロジェクトでは、ViewModelから直接Repositoryを呼び出す構成でも問題ありません。

UseCase層が必要になるのは、

  • 複数のRepositoryをまたぐ処理が出てきた
  • ViewModelに同じロジックが重複し始めた
  • テストを書くためにロジックを分離したい

といったタイミングです。

最初から無理に導入せず、必要になったときに追加する

という判断も有効です。

「ユースケースが多くなりすぎた」

ユースケースを細かく分けすぎると、ファイルが増えすぎて管理しにくくなることがあります。

Claude Codeに整理を依頼できます。

【質問例】
現在のユースケース一覧を見て、
統合できるものや整理できるものがあれば提案してください。

まとめ

Claude Codeを使ったユースケース整理のポイントをまとめます。

  • まず機能一覧からユースケースの候補を洗い出す
  • 「一文で責務を表現できるか」を粒度の判断基準にする
  • 分ける・まとめるの判断軸をClaude Codeに確認する
  • ViewModelとユースケースの責務の違いを明確にする
  • 最初から完璧にせず、必要になったタイミングで整理する

ユースケースの整理は、コードを書く前に一度立ち止まって考える価値があります。

「この処理はどこに書くべきか」

という迷いをなくすことが、設計を整理する一番の目的です。

タイトルとURLをコピーしました