KOTSULY（コツリー） という自己研鑽SNSを個人で作っています。勉強や朝活、筋トレのような毎日の積み上げを、Vlog のワンシーンのようなカードにして、仲間と応援し合うアプリです。
2026年10月1日にリポジトリを作って、9日目の時点で main に入ったコミットは217件、マージしたプルリクエストは38本になりました。書いているのはほぼ Claude Code です。
ただ、1つの会話に全部を頼んでいるわけではありません。Claude Code のセッションを「部署」に見立てて、役割ごとに分けています。 この記事は、その分け方と、やってみて分かったことの記録です。
部署の一覧
いまある部署はこの5つです。どれも Claude Code（デスクトップアプリ）のセッションで、それぞれが自分の git worktree とブランチを持っています。
| 部署 | 担当 |
|---|---|
| モバイルアプリ開発部 | アプリ本体（Expo / React Native）、Supabase との接続、プッシュ通知、課金 |
| Web開発部 | 公式サイト（kotsuly.com）と Web 版 |
| デザイン部 | 作業場所の景色やお店のイラスト、画面の見た目 |
| 経営企画室 | 似たアプリの調査、ロードマップ、機能の言葉づかいや優先順位 |
| SNS戦略部 | X の投稿の下書きと、ユーザーを増やす作戦 |
わたしの役目は「オーナー」です。部署から上がってきた案を見て、決めて、マージする。コードはほとんど書いていません。
なぜ部署に分けたのか
最初はひとつのセッションで全部やっていました。それで困ったのは、会話が長くなるほど、前の話題の判断が次の話題に混ざることでした。
たとえば、公式サイトの見出しを詰めている途中でアプリのバグの話をすると、そのあとサイトに戻ったときに、アプリの都合を前提にした提案が出てくる。どちらも間違いではないけれど、判断の軸がぶれます。
部署に分けると、セッションごとに「何のために、何を基準に考えるか」が固定されます。デザイン部は見た目の気持ちよさで考えるし、経営企画室は「それはユーザーにとって何か」で考える。同じモデルでも、置く場所を変えると考え方が変わる、というのが分けてみての実感です。
worktree を分けているので、同時に動かしても作業場所がぶつかりません。モバイルアプリ開発部がサーバーまわりを直している間に、デザイン部が絵を描き直している、ということが普通にできます。
部署どうしは、直接メッセージを送り合う
部署はばらばらに動いているわけではありません。Claude Code には、同じ Mac で動いているほかのセッションにメッセージを送る機能（SendMessage）があります。これを使って、部署どうしが依頼・報告・相談をしょっちゅう送り合っています。
送り先はセッションの名前です。「モバイルアプリ開発部」宛てに送ると、向こうのセッションには「経営企画室から、こういうメッセージが来ました」という形で届き、向こうはそれを読んで動きます。
実際に飛んでいるのは、たとえばこんなやりとりです。
| 送る部署 | 受ける部署 | 中身 |
|---|---|---|
| 経営企画室 | モバイルアプリ開発部 | 【依頼】取り組みの名前とジャンルのばらつきを減らす修正を4つ |
| 経営企画室 | デザイン部 | 【依頼】運動のタイマー中に出す「運動用の場所」の背景を作ってほしい |
| Web開発部 | モバイルアプリ開発部 | 作業BGMを「無料でも全曲」にする変更を Web 側で入れたので共有 |
| Web開発部 | デザイン部 | 新しいアイコン「芽ときらり」を公式サイトに組み込んだので確認してほしい |
| モバイルアプリ開発部 | デザイン部 | アプリアイコンの画像ファイルの場所を教えてほしい |
| デザイン部 | モバイルアプリ開発部 | ワークラウンジの席のノートパソコンの向きを直したので取り込んでほしい |
依頼には「（経営企画室より・オーナーの依頼）」のように、誰から来て、もとは誰の意思かを必ず書くようにしています。受けた部署が、それを自分の判断で変えてよいのか、オーナーに確かめるべきなのかを見分けるためです。
わたしが「この2つのセッションで連携して進めて」と言っておくと、あとは部署どうしで話を進めてくれます。デザイン部が「決めてほしいことは、こちらにメッセージで送ってください」と返事の宛先を伝えて、Web開発部がそこに相談を送る、という具合です。
ひとつの依頼が、部署をまたいで行って帰ってくる
取り組み（「簿記2級」「毎朝ラン」のような目標）を作るフォームの話が分かりやすい例です。
- 経営企画室が、似たアプリを調べたうえで「名前とジャンルのばらつきを減らす修正」を4つまとめ、モバイルアプリ開発部に依頼
- モバイルアプリ開発部が実装してプルリクエストを作り、経営企画室に報告
- 経営企画室が一番に勧めていた「名前を先に入れる」並びも、相談のうえで追加
- わたしが触ってみて、やっぱり「ジャンル → 名前」のほうがいいと判断。モバイルアプリ開発部が元に戻し、経営企画室に「取り消しの報告です」と送る
- わたしがマージを決め、モバイルアプリ開発部が
mainから作ったアプリをわたしの iPhone に入れて、経営企画室に「入れました」と報告
この間、わたしがしたのは「並びを戻して」と「マージして」の2回だけです。部署どうしの細かい確認は、全部メッセージの中で済んでいます。
それでも、決まったことはファイルに残す
メッセージは速くて便利ですが、そのセッションの会話の中にしか残りません。あとから来た部署や、数日後の自分は読めません。だから、決まったことは必ずリポジトリに書くようにしています。
docs/roadmap.mdが掲示板：残っている作業、済んだこと、わたしが決めることを、どの部署も同じ表に書き込みます。✅ 済み／⬜ これから／🙋 本人の作業／🔶 決めること、の記号もそろえています- 設計書を先に書く：大きな機能は
docs/design-○○.mdを先に作り、「検討中」→「決まったこと」→「実装済み」と書き換えていきます - ほかの部署の成果はコミットで取り込む：デザイン部が作った絵を別の部署が使うときは、コミットのメッセージに「デザイン部の d954b3a」と元を書いて取り込みます
話すのはメッセージで、残すのはファイルで。 人間のチームで、チャットとドキュメントを使い分けるのと同じ形になりました。
決めるのはオーナー
コミットのメッセージには、ときどき「（オーナーの判断）」「（経営企画室・オーナーの依頼）」と書いてあります。誰が決めたのかを残すためです。
さっきのフォームの並びも、AI は頼めば両方の案をすぐ作ってくれます。でも、どちらが良いかは触ってみないと分からないし、決めるのはわたしです。作るのが速くなったぶん、決める回数が増えた、というのが正直なところです。
部署から上がってくる報告も、多くは「マージしてよければ、こちらでマージします」で終わります。main に入れるかどうかは、わたしが決める。ここは全部署で同じです。
ほかにも、作業スペースの席の配置図を「地図」と呼んでいたのを「フロア」に変えたのは、経営企画室から上がってきた案をわたしが決めたものです。決めたあとは、アプリと公式サイトの両方の言い方を、同じコミットでそろえています。
やってみて分かったこと
1. 部署の名前が、そのまま指示になる
「あなたはデザイン部です」と一言あるだけで、返ってくる提案の向きが変わります。長いプロンプトで役割を説明するより、名前のほうが伝わるのは、人間の組織と同じ形を借りているからだと思います。
2. 人がやるのは「決める」と「確かめる」
部署が増えるほど、わたしのところには「どちらにしますか」が集まってきます。ロードマップの 🔶（決めること）はそのための欄です。
もうひとつは実機で確かめること。シミュレーター2台で応援やコメントが相手に届くかを見る、作業スペースに2台で座ってみる。AI がテストを書いて通しても、触ったときの気持ちよさは、触らないと分からないので、ここは自分でやっています。
3. 書き残す量が増える
部署どうしのメッセージは会話の中にしか残らないので、決まったことをファイルに書く習慣が自然とつきます。おかげで設計書やロードマップが育ちます。数日たって自分で見返したときにも助かっています。個人開発だと、数日前の自分はもう他人なので。
おわりに
フリーランスで受託の仕事をしていて思うのは、評価されるのは技術力そのものより「安心して任せられるか」だということです。進捗を聞かれる前に伝える、仕様の穴に気づいたら手を動かす前に確かめる。
AI の部署を回していると、立場が逆になります。わたしが「任せる側」になって、任せやすい形を作る側に回る。 役割を決める、誰からの依頼かを書く、決めたことを残す。結局、人間のチームでやってきたことと同じでした。
KOTSULY はいまベータテストの準備中です。開発のようすは X（@kaede3eng） でときどき書いているので、よければのぞいてみてください。