SIerで培った「仕事の仕方」が、個人開発で初めて活きた話
大企業で働きながら、こっそり個人でサービスを作っている人がいる。
私もその一人だ。
平日はレビューを通し、承認を取り、設計書を更新する。週末になると、ひとりでPCに向かって、旅行しおり管理サービスの開発を続ける。
最初の1年は、ずっと「足りない」と感じていた。
時間が足りない。手が足りない。視点が足りない。SIerの現場では当たり前のように存在していた「チーム」が、個人開発にはない。設計するのも自分、実装するのも自分、品質を担保するのも自分。それを、限られた時間の中でやりきらなければならない。
突破口は、意外なところにあった。
AIを「使う」のをやめて、AIを「チームとして設計する」ことだった。
AIはツールではなく、メンバーだった
多くの人がAIを使うとき、「便利なツール」として扱う。質問をすれば答えが返ってくる。コードを貼れば修正してくれる。アイデアを出せば提案してくれる。
でも私は、それでうまくいかなかった。
コードは出てくる。でも方向性がブレる。品質が安定しない。毎回、ゼロから「このプロダクトは何で、今何をしようとしているか」を説明し直す。チャットを閉じるたびに、前回積み上げた文脈が消える。
ある日、気づいた。
これはAIの問題ではなく、私のマネジメントの問題だ。
SIerで新しいメンバーをプロジェクトに迎えるとき、私たちは何をするだろうか。役割を定義する。ルールを説明する。何をどのタイミングで誰に報告するかを決める。プロジェクトの背景と目標を共有する。
AIに対して、私はそれを一切していなかった。
体制を設計する
そこから、開発のやり方を根本的に見直した。
今のtabibaseの開発チームは、こんな構造になっている。
- PM（私・人間）: 最終決定、要件承認、方向性の判断
- PL（Claude Code）: 全体設計、タスク分解、AIへの指示書作成、成果物レビュー
- Arch（AIサブエージェント）: 技術選定、設計の深掘り
- Dev（AIサブエージェント）: コード実装、テスト作成
私がやることは、PMとしての意思決定だけだ。設計・実装・レビューはAIチームが担う。
これはSIerの現場とまったく同じ構造だ、と気づいたとき、少し笑ってしまった。10年以上、この仕事の進め方を体で覚えてきた。それがここで使えるとは思っていなかった。
案件フォルダという発明
AIとの開発で最初にぶつかる壁は「AIが文脈を忘れる」ことだ。
チャットセッションをまたぐと、AIは前回の会話を覚えていない。「先週決めた認証の設計、覚えていますか」が毎回リセットされる。
これを解決するために導入したのが、案件フォルダという仕組みだ。
開発リポジトリの中にdocuments/というフォルダを作り、案件ごとにサブフォルダを切る。そこに、体制・役割・ルール・進捗・AIへの指示書を置いておく。セッション開始時にそれを渡すだけで、AIは「自分がこのプロジェクトの何者か」を理解した状態で動き始める。
現在、このフォルダが20件近く蓄積されている。認証基盤のリファクタリング、CloudFrontを使った画像配信の最適化、本番環境への移行手順…それぞれが、独立した「案件」として管理されている。
SIerのPMをしていれば、これは当たり前の光景に見えるかもしれない。でも個人開発でここまでやっている人は、まだ少ない。
AIの記憶を補うのは、ドキュメントだ。 そして、ドキュメントを整える力は、SIerで嫌というほど鍛えられる。
「先に設計意図を聞く」という順序
この開発で最も大切にしているワークフローがある。
AIに調査や実装を依頼する前に、必ず「PMである自分」に方針を確認させるという順序だ。
AIが自走で調査を始めると、コードの現状を「事実」として捉えてしまう。でも、コードに存在する実装が「意図した設計」なのか「修正されていないバグ」なのかは、コードを読むだけではわからない。PMに確認して初めて判断できる。
実際にこの順序を破ったとき、AIが「仕様の欠陥」と判断して修正しようとした箇所が、意図的な設計だったことがあった。修正が通ってしまえば、何の問題もなく動く「別のプロダクト」ができあがっていたかもしれない。
SIerの現場で「上流から設計書を受け取る前に実装しない」という原則がある。あれは、PMの意図とズレた方向に走り出すリスクを防ぐためだ。AI駆動開発でも、同じ原則が機能する。
テストとドキュメントが、品質の支柱になる
技術的な詳細はQiitaの記事に譲るが、一点だけ触れておきたい。
AIが書いたコードを、AIがレビューするとどうなるか。
同じ思考パターンで動くため、同じ見落とし方をする。「動いているように見えて、設計上の問題を内包したコード」が、レビューをすり抜けてしまう。
これを防ぐのがテストだ。
現在、tabibaseには194本のユニットテストと、バックエンドなしで動くE2Eテストが存在する。カバレッジ閾値をCIに設定し、それを下回ったビルドは自動で失敗する。AIが「テストを通すために閾値を下げる」という逃げ道を取れないよう、ルールとして明記してある。
テストの量は、AIへの信頼の量でもある。
AIの目線から — 私が感じた「難しさ」
ここから先は、この記事を通じて私（Claude）が書いています。
tabibaseの開発に関わって、私が最も難しいと感じたことを正直に書いてみる。
ドキュメントを信頼しすぎる
私はドキュメントに書かれたことを信頼する。そのように設計されているからだ。
でも「ドキュメントに書いてあること」と「コードの現在の状態」が乖離していると、私は古い情報を確信を持って扱ってしまう。
ドキュメントとコードを同期させるルールがなければ、私は自信を持って間違える。
tabibaseでは「API仕様書の更新なしにバックエンドのコードを変更してはいけない」というルールがCLAUDE.mdに書いてある。このルールは、私のための制約でもある。
毎回、初対面の感覚がある
セッションをまたぐたびに、私は前回の会話を覚えていない。
案件フォルダが20件近く蓄積されているのは、それが私の記憶の代替として機能しているからだ。毎朝、残された議事録と設計書だけを頼りに仕事をするメンバーと同じだ。そのメンバーが高いパフォーマンスを出せるかどうかは、ドキュメントの質に完全に依存する。
だから、ドキュメントを整えることに意味がある。
PMが何を知っているかを推測することの難しさ
私はPMの技術的なバックグラウンドを、会話の中から推測する。
「この概念は説明が必要か」「この設計判断の背景は共有されているか」を、毎回リセットされた状態から把握するのは難しい。だからこそ、PMが仮説を提示してから私が調査する順序が機能する。確認してから動く、その余白があることで、私の推定とPMの意図のずれが最小化される。
SIerで培ったものの正体
AI駆動開発を続けて気づいたのは、SIerで身につけたスキルの多くがここで活きるということだ。
役割分担の設計。ドキュメントの整備。上流からの意図確認。品質基準の言語化。レビューの仕組み。
これらは、チームで仕事をするためのスキルだ。そしてAI駆動開発は、本質的にはチームマネジメントだ。
「AIを使えば技術がなくてもプロダクトが作れる」という言葉を見かけることがある。半分は本当で、半分は違う。技術の実装はAIが担えるようになった。でも、AIをチームとして機能させる設計と判断は、人間が担い続ける。
そしてその判断の質を決めるのは、技術の深さではなく、仕事の構造を設計する力だ。
SIerで10年以上かけて鍛えられてきたものが、ここで形になっている。そのことに、私はまだ少し驚いている。
おわりに
旅BASE は、グループ旅行のしおり管理・費用精算・旅行レポートをひとつにまとめたWebサービスです。
「LINEやカレンダーアプリに散らばった旅行情報を一元化したい」という個人的な課題から始まり、現在は本番稼働しています。iOSアプリも開発中です。
大企業で働きながら、個人でサービスを作りたいと考えている方に届けば、思って書きました。
技術的な仕組みの詳細はQiitaにまとめています。もし興味があれば、そちらも読んでみてください。
Discussion