注記: この記事はAI（Claude）と一緒に作成しました。体験・経験はすべて筆者自身のものです。
はじめに
私はSIerでシステムエンジニアをしています。保守プロジェクトのサブリーダーとして、顧客折衝やPJ管理といったPM的な業務を担当してきました。
ただ、ずっと心のどこかに引っかかりがありました。
「やっぱりエンジニアとしてモノづくりがしたい。コードが書きたい。」
コードを書く機会がほとんどなく、トラブルシューティングや、Excel、PowerPointでドキュメントを作る仕事に慣れていく一方で、「ソフトウェアエンジニアになりたい」という気持ちが強くなっていきました。
そこで一念発起して、できる日は毎日1時間・独学でバックエンド開発の学習を始めました。その過程でAIをPMとメンターとして活用するというスタイルをしてみているので、その話を書きます。
使ってる技術
- Java 24 / Spring Boot 4.0.5
- PostgreSQL 17.9
- IntelliJ IDEA Community
- Claude（Anthropic）
なぜAIをPMにしようと思ったのか
独学の一番の壁は「何から手をつければいいかわからない」ことだと思います。
技術書を読んでも、チュートリアルをこなしても、「で、実際に何を作ればいいの？」となりがちです。実務経験がないので、どのタスクをどの順番でやれば良いかの感覚がない。
今まで何度も、「よし今日からプログラミングやるぞ！」と思って挫折してきたことか・・
そこでClaudeに相談したところ、WBSを作ってもらうというアイデアが出ました。
・書籍管理アプリ（ポートフォリオ用）
・Java / Spring Boot / PostgreSQL
・1日1時間・週5日ペース
・転職や異動を見据えた技術選定
この条件を伝えると、フェーズごとに細かいタスクに分解されたWBSが出てきました。またそれに至った実務的な判断の背景まで教えてもらえました。
デイリースタンドアップを始めた
WBSが手に入ったら、次はデイリースタンドアップを提案されました。
毎日3点を報告します。
- 昨日やったこと
- 今日やること
- 詰まっていること
実務のアジャイル開発そのままです。最初は「AIに報告するって何？」と思いましたが、やってみると結構よかったです。
報告することで、自分の理解を言語化するトレーニングになる。
「Controllerとは何か」「なぜ層を分離するのか」「なぜRepositoryをインターフェースで作るのか」など、なんとなくコードを書いているだけでは通り過ぎてしまう概念を、PMに説明するために自分の言葉で整理しなければならない。
これが結構独学する上でよかったです。
「答えは教えない」スタンスが良かった
最初にこうお願いしました。
コードは自分で調べながら書きます。答えは出さないでください。私が理解できているか確認したいときはPMとして深掘りしてください。
これが学習効率に良い影響を与えました。
たとえば、こんなやりとりがありました。
私: @PutMappingのメソッドができました。
Claude（PM）: コードを見せてください。
--コードを貼る--
Claude: 惜しいです。PUTは更新なので、existingBook = bookだと何が起きますか？
私: ……あ、参照が上書きされるだけで、idが消えるかも？
Claude: 正解です。DBから取得したオブジェクトの各フィールドをセットするのが正しいです。どう修正しますか？
答えをもらわずに自分で気づく体験は、何度やっても記憶に残ります。（これは今までの４年間のSE業務経験で知ってた）
一方で「30分調べてわからなければ聞く」というルールも設けました。詰まり続けるのは非効率なので、メリハリをつけています。
実際に詰まったこと・学んだことの紹介
環境変数の管理
パスワードをソースコードに直書きするのは危険と知っていても、.envファイルをどうやって環境変数として読み込むのかわかりませんでした。
IntelliJではEnvFileプラグインを入れて、実行構成（Run Configuration）に.envファイルを紐付ける必要があります。プラグインを入れるだけでは動かない、というのはハマりポイントでした。
JpaRepositoryをインターフェースで作る理由
public interface BookRepository extends JpaRepository<Book, Integer> {
}
「なぜ中身を書かないのに動くの？」という疑問を持ちました。
答えは「SpringがBookRepositoryの実装クラスを起動時に自動生成してくれるから」です。インターフェースにすることで、Springが管理下に置いて実装を注入できるようになります。
これはControllerを実際に作って@Autowiredで使い始めたとき、ちょっとイメージが分かりました。概念の理解は手を動かした後についてくる、という体験でした。
（ただこれはまだ完全に腑に落ちてないので今後進めていく中で理解を深めたい。。）
ユーザー権限の設計
PostgreSQLのテーブルはデフォルトでは作成者（postgresスーパーユーザー）しかアクセスできません。アプリ用ユーザーには明示的にGRANTが必要です。
GRANT SELECT, INSERT, UPDATE, DELETE ON books TO appuser;
GRANT USAGE, SELECT ON SEQUENCE books_id_seq TO appuser;
2行目のSEQUENCEへの権限を忘れると、INSERT時にエラーになります。これも実際に500エラーが出てそこで学びました。
現在の進捗と今後
現在はP2（基本CRUD API）が完了し、P3（API品質向上）に入ったところです。
今後やること：
- Serviceクラスの導入
- バリデーション（@Valid）
- 例外ハンドリングの整備（@RestControllerAdvice）
- テストコード（JUnit / Mockito）
- Docker化
- Spring Security（JWT認証）
- GitHub Actions（CI/CD）
GitHubはこちら（現在進行中）：
やってみてわかったこと
AIをPMにするメリット
- タスクが明確になる（WBSがある）
- 進捗を言語化する習慣がつく（スタンドアップ）
- 詰まったときに壁打ち相手になってくれる
- コードレビューをしてもらえる
- 「なぜ？」を一緒に考えてくれる
気をつけていること
- 答えをもらいすぎない（自分で考える時間を確保する）
- ネットの情報源の日付を必ず確認する（情報として腐ってないか確認する）
- 「なんとなく動いた」で終わらせず、仕組みを理解してから次に進む（ただ端から端まで１つずつ理解するのは無理なのであまり固執しすぎないように）
おわりに
コードを書かないエンジニアとして数年過ごしてきましたが、毎日1時間・AIと一緒に進めることで、良い学習ができるようになってきました。
まだまだ始めたばかりですが、「詰まる → 調べる → 理解する → 次へ」のサイクルが楽しくなってきています。
また、実際にこのバックエンド学習で作ったポートフォリオについても記事にできたらなと思っています。
今回の記事が、同じように「コードを書きたいけど何から始めればいいかわからない」「バイブコーディングばかりではなく、ちゃんと理解するためにAIを使いたい」という方の参考になれば嬉しいです。
今はさらに学習を加速させるため、ClaudeCodeにも同じような役割を担ってもらいながら進めています。
今度は実際にバックエンド学習で作ったポートフォリオについても記事にできたらなと思っています(^^)/