EP.01 では離任時の整理を扱いました。この回は逆に、受任時に何をしておくと後が楽かを扱います。
結論を先に書くと、最初に分離しておけば、離任は一瞬で終わります。逆に混ざったまま進めると、離任時に何時間もかけて掘り起こすことになります。
同じ端末で複数の案件を扱う前提で書いています。案件ごとに端末が分かれているなら、多くは自動的に解決します。ただし業務委託や受託では、1台で複数を扱うほうが一般的です。
1. 分離しないと何が起きるか
混ざることで起きる事故は、だいたい決まっています。どれも「気づかないうちに」起きるのが共通点です。
| 混ざるもの | 起きる事故 |
|---|---|
| クラウドの認証情報 | 別の案件の環境に対して操作してしまう |
| git の設定 | 前職や別案件のメールアドレスでコミットが残る |
| どの鍵をどこに登録したか分からなくなる | |
| ブラウザのログイン状態 | 別案件の管理画面に入ったまま作業する |
| 手元のメモや設定ファイル | 離任時にどれを消すべきか判断できない |
2行目は実際によく起きます。コミット履歴は後から書き換えにくく、公開リポジトリなら取り返しがつきません。しかも指摘されるまで気づかないことが多い。
1行目は最も危険です。本番環境を取り違えて操作するという事故は、認証情報が混ざっている状態で起こります。手元では区別がつかないため、コマンドを打つ瞬間まで気づけません。しかも権限が強いほど被害が大きく、取り違えた先で削除や更新まで通ってしまうことがあります。 が守られていれば被害は限定されますが、それも設計次第です。
2. 最初の30分でやること
受任が決まったら、作業を始める前に分離の準備をします。後回しにすると、混ざってから分けることになります。
- 1案件用のディレクトリを1つ決める — 関連するものは全部この下に置く
- 2git の設定をそのディレクトリ配下だけに効かせる — メールアドレスの取り違えを防ぐ
- 3クラウドの認証情報に案件名を付ける — 既定のまま使わない
- 4SSH鍵 を案件専用に作る — 使い回さない
- 5ブラウザの領域を分ける — 別プロファイルか、別のブラウザ
# ~/.gitconfig に「この配下ならこの設定を使う」と書いておくcat >> ~/.gitconfig <<'EOF'
[includeIf "gitdir:~/work/client-a/"] path = ~/.gitconfig-client-a
[includeIf "gitdir:~/work/client-b/"] path = ~/.gitconfig-client-bEOF
# 案件ごとの設定ファイルを用意するcat > ~/.gitconfig-client-a <<'EOF'[user] name = Your Name email = you@example-a.co.jp[core] sshCommand = ssh -i ~/.ssh/client-a_ed25519 -o IdentitiesOnly=yesEOF
# 確認: そのディレクトリで実際に何が使われるかcd ~/work/client-a/some-repo && git config user.email`includeIf` を使うと、そのディレクトリ配下でだけ設定が有効になります。案件ディレクトリの外に出れば元の設定に戻るので、取り違えが構造的に起きなくなります。
設定した直後に `git config user.email` で実際に何が使われるかを確認してください。書いたつもりで効いていない、というのはよくあります。最初のコミット前に1回確認するだけで防げます。
3. クラウドの認証情報を分ける
最も事故が重いのがここです。既定のプロファイルを使わない、というのが基本方針になります。
# 案件名を付けたプロファイルとして設定するaws configure --profile client-a
# 使うときは必ずプロファイルを明示するaws s3 ls --profile client-a
# あるいは、そのシェルでだけ有効にするexport AWS_PROFILE=client-a
# 確認: いま自分が誰として操作しているかaws sts get-caller-identity --profile client-a既定のプロファイルを設定しないことが要点です。既定があると、プロファイルの指定を忘れたときに気づかないまま別の環境へ接続します。既定を空にしておけば、指定を忘れればエラーになる ── 失敗が失敗として現れるようになります。
さらに踏み込むなら、長期の認証情報を手元に置かない方法があります。 や一時的な認証情報を使う形で、これなら期限が来れば自動的に無効になります。 の考え方を手元にも適用する、ということです。
| 方式 | 離任時の作業 | 漏れたときの被害 |
|---|---|---|
| 長期のアクセスキーを手元に置く | 手動で無効化が必要 | 期限がないので永続的 |
| SSO 経由で一時的な認証を取る | 元を止めれば終わり | 期限切れで自然に無効 |
| 専用の保管庫から都度取得 | 権限を外せば終わり | 取得記録が残る |
4. 権限は「足りない状態」から始める
受任時に「必要そうな権限を一括で」もらうと、何が本当に必要だったか分からなくなります。 の観点では、足りない状態から始めて、詰まったら足すほうが結果的に正確です。
この進め方には副次的な効果もあります。何にどの権限が要るかが記録として残るため、次に同じ役割の人が入るときの参考になります。逆に一括で渡してしまうと、その情報は永久に得られません。
立ち上がりは速くなりますが、その後ずっと下げられません。下げようとすると「何が壊れるか分からない」からです。EP.5 で扱う棚卸しの困難さは、多くがこの初期判断に起因します。
5. 記録を1か所にまとめる
分離と同じくらい重要なのが、何をどこに登録したかの記録です。これがないと、離任時に掘り起こす作業が発生します。
- どのサービスにアカウントを作ったか — 後から一覧できないものが多い
- どこに SSH鍵 を登録したか — サーバ、リポジトリ、踏み台
- をどの端末に登録したか — 端末を替えるときにも要る
- 誰に何を依頼して権限をもらったか — 返すときの相手が分かる
- 案件専用に作ったファイルの置き場 — 消す対象が明確になる
この記録は、受任した日から書き始めるのが唯一の現実的な方法です。後からまとめて思い出すのは不可能に近い。案件ディレクトリの直下に1ファイル置いて、その都度1行追記するだけで十分です。
この記録がそのまま、EP.01 で扱った離任時のチェックリストになります。受任時の記録が、離任時の作業を決めるという関係です。逆に言えば、記録が無い状態での は、手元を掘り返して思い出す作業になります。何時間かけても「全部消した」と確信できないのが辛いところです。
6. 立ち上げの型を持つ
案件が変わるたびに毎回考えるのは無駄です。自分用の立ち上げ手順を1つ持っておくと、30分が10分になります。
#!/usr/bin/env bash# usage: new-client.sh <client-name> <email>set -euo pipefail
CLIENT="$1"EMAIL="$2"BASE="$HOME/work/$CLIENT"
mkdir -p "$BASE"
# 案件専用の鍵を作る（使い回さない）ssh-keygen -t ed25519 -f "$HOME/.ssh/${CLIENT}_ed25519" \ -C "$EMAIL" -N ""
# 案件用の git 設定cat > "$HOME/.gitconfig-$CLIENT" <<EOF[user] email = $EMAIL[core] sshCommand = ssh -i ~/.ssh/${CLIENT}_ed25519 -o IdentitiesOnly=yesEOF
# 記録用のファイルを最初に作っておくcat > "$BASE/HANDOVER.md" <<EOF# $CLIENT 受任記録開始日: $(date +%Y-%m-%d)
## 作成したもの- SSH鍵: ~/.ssh/${CLIENT}_ed25519- git設定: ~/.gitconfig-$CLIENT
## 登録した先（都度追記する）
## もらった権限（都度追記する）EOF
echo "作成しました: $BASE"echo "~/.gitconfig に includeIf の設定を追加してください"要点は、記録用のファイルを最初に作ることです。空のファイルが1つあるだけで、追記する習慣がつきます。何もなければ、記録は始まりません。この雛形は各自の環境に合わせて調整してください。重要なのは中身より、毎回同じ手順で始められるという点です。案件のたびに違う構成にすると、離任時にどこを見ればよいか分からなくなります。
最初に分けておけば、離任は一瞬で終わる。git は `includeIf` でディレクトリ配下だけに効かせる。クラウドは既定のプロファイルを作らない（忘れたらエラーになる状態にする）。権限は足りない状態から始める。そして記録用のファイルを受任初日に作る。次回は複数案件を並行するときの分離を扱います。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。