※Claude Codeを使用して記事を作成しています。
前回の記事では、Claude Codeと一緒にユースケースの粒度と責務を整理する方法を紹介しました。
このシリーズも今回が最終回です。
テーマは、
「ふりかえり」
です。
設計は、一度決めたら終わりではありません。
実装を進める中で、
- 思っていたより複雑になった
- 想定していなかったケースが出てきた
- 別の設計の方が良かったかもしれない
という気づきが必ず出てきます。
このふりかえりをどう言語化し、
次の開発に活かすか、Claude Codeの活用方法を解説します。
なぜふりかえりが必要なのか
ふりかえりをしないまま次の機能に進むと、同じ設計判断で同じ問題を繰り返しやすくなります。
逆に、ふりかえりをきちんと行うことで、
- 何がうまくいったのか
- 何が問題だったのか
- 次はどう改善すべきか
が明確になり、設計の精度が少しずつ上がっていきます。
ふりかえりとは、「経験を再現可能な知識に変える作業」
です。
Claude Codeがふりかえりに向いている理由
ふりかえりは、一人で行うと以下のような偏りが出やすい作業です。
- 良かった点ばかりに目が向く
- 問題点をなんとなく感じているが、言葉にできない
- 感覚的な反省で終わってしまう
Claude Codeを壁打ち相手にすることで、
- 実装内容を客観的に整理できる
- 問題点を具体的な言葉にできる
- 改善案を複数の視点から検討できる
という効果が得られます。
実例：タグ機能の実装をふりかえる
ここでは、このシリーズを通して設計してきた「メモアプリのタグ機能」の実装が完了した想定で、ふりかえりを進めます。
ステップ1：実装内容を整理して伝える
まず、実装した内容をClaude Codeに共有します。
【質問例】
メモアプリにタグ機能を実装しました。
以下の内容でふりかえりをしたいので、
質問形式で深掘りしてもらえますか？
【実装した内容】
- タグの作成・削除・一覧取得
- メモへのタグ付け・取り外し
- タグによるメモの絞り込み（単一タグのみ対応）
【アーキテクチャ】
MVVM + Repository
【実装中に感じたこと】
- タグの絞り込みロジックがViewModelに書かれてしまった
- 複数タグでの絞り込みに対応する設計になっていなかった「質問形式で深掘りしてもらう」と依頼することで、一方的な評価ではなく、対話形式でふりかえりを進められます。
ステップ2：問題点を深掘りしてもらう
Claude Codeが、以下のような質問を返してくれます。
【Claude Codeからの質問例】
- タグの絞り込みロジックは、具体的にどのような処理内容ですか？
- なぜViewModelに書くことになったのか、経緯を教えてください
- 複数タグ対応を見据えていなかった理由は、
設計時に気づかなかったのか、意図的に後回しにしたのか、どちらですか？これに答えていくことで、
問題の本質が見えてきます。
【回答例】
- 絞り込みロジックは、メモ一覧をタグIDでfilterする処理
- ユースケースを呼ぶほどの処理ではないと判断し、ViewModelに直接書いた
- 複数タグ対応は、前回の記事で「後回し」と決めていたが、
設計時にその制約を踏まえたユースケース設計をしていなかったステップ3：問題点を言語化してもらう
回答をもとに、問題点を整理してもらいます。
【質問例】
ここまでの内容をもとに、
今回の実装における問題点を整理してください。Claude Codeが返す整理例です。
【問題点の整理】
1. ロジックの配置判断が場当たり的だった
「処理が簡単だから」という理由でViewModelに書いてしまい、
本来ユースケースに置くべきかどうかの判断軸がなかった。
2. スコープ外とした要件が設計に反映されていなかった
「複数タグ対応は後回し」と決めていたにもかかわらず、
後から拡張しやすい設計にはなっていなかった。
3. ふりかえりのタイミングが実装後になっていた
本来は実装中、もしくは設計段階で
気づけた可能性がある問題だった。こうして言語化することで、「なんとなく気になっていたこと」が、具体的な問題として認識できるようになります。
ステップ4：改善案を一緒に考える
問題点が整理できたら、改善案を相談します。
【質問例】
整理した問題点について、それぞれの改善案を教えてください。Claude Codeが返す回答例です。
【改善案】
1. ロジックの配置判断について
→ 「ViewModelに書いてよい処理」の基準を先に決めておく
（例：単純な表示用の加工はViewModel、
ビジネスルールを含む処理はユースケースに書く）
2. スコープ外の要件について
→ 仕様書に「後回しにした理由」だけでなく、
「将来対応する場合の設計上の注意点」も書き残しておく
3. ふりかえりのタイミングについて
→ 実装完了後だけでなく、
機能の主要な部分ができた時点で一度ふりかえりを行う改善案は、次の機能開発にそのまま活かせる形に整理します。
ステップ5：次に活かすルールとしてまとめる
最後に、ふりかえりの内容を次回以降のプロジェクトに使える形にまとめます。
【質問例】
今回のふりかえりの内容を、
次回の開発で参照できるチェックリスト形式にまとめてください。Claude Codeが返すまとめ例です。
【次回開発用チェックリスト】
□ ロジックをViewModelに書く前に、
「ユースケースに置くべきか」を一度検討したか
□ スコープ外とした要件について、
将来対応するときの設計上の注意点を書き残したか
□ 実装の節目で、一度ふりかえりの時間を取ったかこのチェックリストを、次の機能開発の最初に読み返す運用にすることで、同じ問題を繰り返しにくくなります。
ふりかえりでよくある失敗
良かったことだけで終わる
「うまくいった」で終わらせてしまうと、次に活かせる学びが残りません。
うまくいった場合も、
なぜうまくいったのか、理由を言語化してくださいと質問することで、再現性のある知識になります。
反省だけで終わる
問題点を挙げるだけで、改善案まで落とし込まないケースもよくあります。
「問題点」とセットで「次どうするか」まで整理する
ことを意識してください。
ふりかえり自体をやらない
一番多い失敗は、そもそもふりかえりの時間を取らないことです。
Claude Codeを使えば、実装内容を貼り付けて質問するだけで始められます。
「ふりかえりのハードルを下げること」も、Claude Codeを使う大きなメリットです。
シリーズ全体のまとめ
ここまで、「Claude Codeで設計・思考を整理する」シリーズとして、以下のテーマを扱ってきました。
第1回：要件整理の壁打ち活用術
第2回：仕様書の作り方
第3回：DB設計の壁打ち活用術
第4回：アーキテクチャ選定の決め方
第5回：ユースケースの粒度と責務
第6回：設計の問題点を言語化するふりかえりこのシリーズを通して伝えたかったことは、
Claude Codeは、コードを書くためだけのツールではなく、
「考えを整理するためのパートナー」である
ということです。
要件整理からふりかえりまで、開発のあらゆる段階でClaude Codeと対話しながら進めることで、
- 曖昧な考えが言語化される
- 判断の軸が明確になる
- 経験が次に活かせる知識になる
という効果が得られます。
コードを書く前も、書いた後も。
Claude Codeとの対話を、設計の一部として取り入れてみてください。
