受託案件のリポジトリを、あとで困らないように分ける

🗂️混ぜると何が辛いのか

自社と受託を同じ場所に置くと、案件が増えた途端に一覧が混ざり、権限まで漏れやすくなります。

最初は自社プロダクトと同じ場所に、受託の成果物も置いていました。 数件のうちは、なんの問題もありません。

ところが案件が並行し始めると、一覧に自社とお客様の資産が混ざります。 「これはどのお客様のだったか」を毎回思い出す――地味ですが、この確認がずっと続きます。

もっと厄介なのが権限です。あるお客様の担当者を招きたいとき、 資産が同じ場所に混在していると、 意図せず他のお客様のコードまで見える状態になりかねません。

受託で守りたいのは「見えてはいけないものは、見えない」。 それを気合いではなく構造で保証したい。 だからこの混在は、早めに返すべき負債でした。

🏢専用 org に private でまとめる

受託専用の org を切って全部 private に置く。それだけで一覧の混在が消え、初期値が安全側に固定されます。

私たちの答えは、受託専用の org（willink-clients）を切ること。 お客様の資産は、すべてそこに private で置きます。

自社プロダクトや OSS とは、器そのものを分ける。 これだけで「一覧に混ざる」問題は消えます。 org 単位で、アクセスの初期値を「関係者以外は見えない」に固定できるからです。

GitHub は org・チーム・リポジトリの三層でアクセス範囲を設計できます （権限モデルの詳細は GitHub 公式ドキュメントにまとまっています）。

専用 org にしておくと、この三層を受託の文脈だけで一貫して回せます。 「誰にどこまで見せるか」を、案件ごとに悩まなくて済むわけです。

🔤命名は「顧客名-種別」で揃える

名前は 顧客名-種別 に統一。顧客名で前方一致すれば、そのお客様の資産がまとめて一覧に出てきます。

器を分けたら、次は名前。私たちは {顧客名}-{種別} というルールに統一しました。

たとえば小川建機様の案件なら、テーマは ogawa-kenki-wp-theme、 自動化スクリプトは ogawa-kenki-automation。 この2つが並ぶ形です。

利点は単純です。顧客名で前方一致検索すれば、そのお客様の資産が全部そろって出てくる。 一覧もアルファベット順なので、同じお客様のリポジトリが自然と隣り合います。

種別を後ろに置くのは、「まず誰の案件か」で束ねたいから。 逆に種別を前にすると、全お客様のテーマがバラバラに散らばって、 束ねたい単位と噛み合いません。

✂️client- 接頭辞をやめた理由

org が「全部受託」と語るなら、client- は重複。先頭は一番の索引だから、顧客名に譲りました。

最初は client-ogawa-kenki-wp-theme のように、 受託だとひと目で分かるよう client- を頭に付けていました。

ところが専用 org に移した時点で、気づいたんです。「ここにあるものは全部受託」だと、org 自体が語ってくれている――と。接頭辞は、ただの重複でした。

しかも client- が付いていると、 検索や補完のたびにこの6文字を通過しないと、肝心の顧客名にたどり着けません。

名前の先頭は、一番よく使う索引です。 そこは意味のある情報――つまり顧客名に譲るべきだった。 器で分類が決まるなら、名前は器が語らない部分だけを担えばいい。 これが接頭辞を落とした判断です。

🔑アクセス権を分離する狙い

器と名前が揃うと権限も素直。担当者にはそのお客様のリポジトリだけ渡せば、他は構造で見えません。

器と名前が揃うと、権限の設計も素直になります。 お客様の担当者を招くときは、そのお客様のリポジトリにだけ read/write を付ければいい。

org を分けているので、他のお客様の資産に触れる余地はそもそも生まれません。 引き継ぎや外部レビューが起きても、共有範囲を最小限に切り出せます。

一人会社では、こういう「境界」を頭の中の注意力で守ろうとすると、いつか必ず取りこぼします。私も、そう。

だから org という物理的な壁と、顧客名で束なる命名規則。 この2つに肩代わりさせる。私が忘れても、構造が守ってくれます。 受託で一番怖いのは技術的な失敗より「見せてはいけないものを見せる」事故なので、 そこを仕組みで潰せる価値は大きいです。

💡まとめ

要点は4つ。器を分ける・名前を揃える・重複を削る・境界は仕組みに守らせる、この順で効いてきます。

• 受託資産は専用 org に private でまとめる。 自社プロダクトと混ぜないだけで、権限の初期値が安全側に固定される。
• 命名は 顧客名-種別 で統一する。 顧客名で前方一致すれば、そのお客様の資産が一括で見える。
• 分類が器で決まるなら、名前から重複情報を落とす。 私たちは client- 接頭辞をやめ、先頭を顧客名に譲った。
• 境界は注意力でなく構造に守らせる。 一人会社ほど、忘れても壊れない仕組みが効く。

派手さはありません。でも、この土台があるだけで、案件が増えても引き継ぎが淡々と回ります。

もし今、受託の資産が自分の個人リポジトリに溜まり始めているなら―― 案件が2〜3件のうちに、器と名前だけ先に整えておくと後がずっと楽です。 i-Willink では、こうした運用の足回りを最初に整えることを大切にしています。