開発した人がいなくなったら、システムはどうなる?
個人開発者に仕事を依頼するとき、なんとなく不安に思う。
「もしこの人がいなくなったら、どうなる？」
これを面と向かって聞くことも聞かれることもあまりない。
でも、意思決定の裏では考えられている。
このことを考えずに「大丈夫です、任せてください」と答える人は、多分自分がいなくなる時のことは考えていない。
それか、「わからなかったら聞いてください」のスタンスでいて、「わからない」の範囲が広い。
この心配について、具体的に対処できる部分とそうじゃない部分を、整理したくなった。
1人だけで開発することのリスクって何？
「個人に任せるのはリスク」っていうなんとなくの感覚はある。
実際に何がどうか？って聞かれると、「その人が飛んだらどうする？」がまず思いつく。
誰かが急にいなくなった時に、システムのことをわかっている人がいなくて、何かあった時に対処できなくなる。これが一番に思いつく心配事。
もう少し具体的に考えると、開発した後の保守・運用もやってくれるのか、って心配もある。最初の開発が終わったら別の人に引き継ぐ必要があるなら、その手間もある。
保守運用も開発した人がやってくれる方が、引き継ぎとかコミュニケーションのコストが低くて助かる。
かといえば、その人が関わることがなくなった時に、その人が作ったものを理解するのが大変になるのも困る。ゼロから説明が必要になる手間もある。
技術や運用のこと以外にも、法人でないと発注先としての信用チェックに通らない、みたいなビジネス上の制約もありうる。どうしようもないレベルの問題。
一言で不安・心配といっても、状況によって内容は変わる。
反対に具体的にどの部分がリスクに思うかがはっきりしていれば、それに適した対策がある気がする。
漠然と「不安」のままだと、個人なのかチームなのか法人なのかで闇雲に区切ることになりそう。
工夫で対処できる部分
リスクのうち、工夫で対処できる部分はあると思う。完全に消せるわけではないけど、軽減はできる。
1. 判断ログと、コード内のwhyコメント
一番気をつけたいのは、なぜその選択をしたかを記録すること。
判断の背景を残す仕組み（ADRやDesign Docと呼ばれたりする）。
できればコードとひとまとめにしておくと、これはあっちを見て、詳細はここに、みたいに、ドキュメントは残っているけど、どこにあるかを特定の人しか知らない状態を避けられる。（モノリポの一つの背景はこういうのがあるかも）
コードレベルだと、コメントは「何をしているか」ではなく「なぜそうしているか」を書く。
「何をしているか」はコードからわかる。
何をしたいかがわからないと、どんな挙動は意図していないかがわからない。
なぜそうするかがわからないと、どの部分はどういう理由があれば変えられるか把握できない。なんとなくで既存のものを残しつづける。
書いておかないと、数ヶ月経って、「なんでこうなってたんだっけ？」という話をまた一からすることになる。自分が書いたコードでも、意外と忘れる。
これがあると、将来の保守・運用する人（自分も含めて）は理由を把握できるので、状況が変わったときに判断や実装を変えられる。
特に新しい技術が出たり、ユーザーのニーズが変わると、設計も実装も変更される。数ヶ月後にはこっちの方がいいよねっていうことがざらにある。
背景が残っていないと、そこの変更の意思決定のための確認事項が増えたりして遅れる。
2. 知識なしを前提にしたREADME
READMEは、そのプロジェクトをはじめて見る人が内容を把握するために書く。
そもそものプロジェクトの目的、開発環境のセットアップ手順、システムの構成や必要な認証情報の置き場所みたいな概要を書いておく。
開発環境の作り方や本番環境のデプロイの手順は、誰がやっても同じ実行内容になることが理想で、コマンドがあると統一される。
それがないと、なんとなく降ってきたタスクをその範囲でこなすだけ、みたいなことになりやすい。
その環境の前提が曖昧だったりすることがよくある。事前にインストールしておく必要なものが書かれていなかったり、WindowsとかどのOSで動く前提かが抜けていたりすることもある。
人の入れ替わりがないと、コマンドが古くなったいていざという時に動かないこともある。
こういうところに先に書いた判断のログの場所とか、事業判断をする人と、コードの判断をする人が誰なのか、どんなメンバーが関わっているのかとかもあるといいと思う。
これがあると別の人が引き継ぐ時に必要な情報を得やすいし、オンボーディングとかで、本質的ではないところにかかる時間も短くなる。
3. ありふれたツールと簡潔な構造
Postgres、FastAPI、Reactとか、広く使われているツール。新しさや尖った機能もいいけど、「他の人が引き継いだときに扱えるか」を気にしておくと、触れる人を見つけやすい。新しいものを色々触りたい人にとっては退屈になるかもしれないけれど。
同じようにコードのディレクトリ構造も複雑にしすぎない。
クラウドサービスを安く使えるなら使う。無ければライブラリとかで大体できないかを調べる。
それでもなければどんなライブラリがあれば1行で完結するかを考えて、それを必要なら作る。
何か1つの機能を追加するのに、詳細な実装をディレクトリ構造を理解した上で、あちこちに散らばると、結局理解するための時間が作った構造で省ける時間より長くなることもある。
4. コマンドで動く
開発環境のセットアップ、テストの実行、本番へのデプロイ、ロールバック。
すべて1つのドキュメント化されたコマンドで実行できると良いっていう話。
技術者ならそうするべきとかではなく、手順とかチェック項目が普通の言葉で書かれていると、人によってやり方や見るところがずれるから。
そんなずれが起こらないように細かく書こうとすると長くなる。それを作って実行・確認する手間と、1回のコマンドで誰でも同じことを行えるようにする手間を考えると、後者の方が簡単で楽になると思った。
インフラもコードで管理されていると、誤った設定や手順の漏れ減らせる。手動設定したものは、その人の頭の中にしか残らない。コードで定義できていれば、それ自体がドキュメントにもなる。
作成・設定しているリソースのスペックの理由もあると、さらに後から柔軟に変える判断がしやすい。
作ったコマンドは作って終わりではなく、再実行できるかとかまっさらな環境で動くかとかは定期的に確認しておいて、動かなければ優先して直す。
本番のデプロイとか頻繁に使われるものは、何かあった時にすぐに更新されると思う。
けれど、自動テストを作ったけどエラーが出て修正が必要になるとか、DBや処理のロールバックが必要になった時に動かない状態だと、作った意味がなくなるので。
5. アクセス権と所有権の明示
READMEの注意点とほとんど同じだけど、大事なことなので。
コード以外の資産、ドメイン、クラウドやSaaSのアカウント、決済サービスの連絡先とか、誰が所有・管理していて、どうアクセスし、どう移管するかを明記すること。
クラウドサービスの支払いが止まってサービスが停止するみたいなことを避けるためにも、できれば複数人で共有していたい。
チームだと聞いて確認した方が早いから、ここまでかかれないかもしれない。事業として紛失すると痛いから、個人や少人数なら誰かがわかるようにしておくと良い。
コードはリポジトリにあっても、ドメインの更新やサービスからのアクションが必要な警告とかも、誰が把握しているかを明示しておくと、関わる人が変わる時に当人の記憶を頼りにするのが危険。
組織やチームにもある同じ問題
こういうことがきちんとされないと、個人の開発者はリスクに見える。
でも実際は、発注先の会社や社内のチームでも頻繁に起きる。
退職した人の引き継ぎが不十分なことに後から気づいたり、特定の1人しか把握していないシステムの要件、何年の背景が記録されていない決定。
組織でも、「チームのシステム」と言いつつ、実際には特定の1人だけがその仕組みを本当に理解している、ってことが普通にあり得る。ただ、見えにくいだけで。
個人開発だからこの問題が起こる、というより、いずれにせよ起きていることが、目に見えたか見えていないか。
例えばスタートアップで最初の1人か2人で作ったシステムが、退職や異動で別の人が運用することになる。システムがどうなっていれば正しいかとか、なんでこの要件・構成になっているのか、をいちいちその人に確認しないと、変更の判断ができなくなる。
その間は機能を作ったり内部的な改善をすることもなく、ただただ時間やその人の工数がかかる。
個人開発の利点はある？
リスクを承知した上で、個人が開発することのメリットについて。
仲介がない直接のやり取り
システムを作る人が直接、何をなぜ作るかを把握できること。
意外と行われていない。内製で開発していても。
要件を整理する人と実装する人が別だと、実装の複雑さが要件に反映されづらくなる。ちょっとした違いで、実装が何倍も難しかったり。
作る側で詳細を把握できていないと、そういうコストの高い実装になり得る。
例えば何をしたいか考える時に、技術的にどれくらい難しいかや、別のこの方法なら簡単にできる、みたいなことをリアルタイムで詰められない。
一度聞いて持ち帰って、エンジニアに相談して、難しいのでこれならどうですか？、となってまた課題を抱えている人に相談して…。みたいな期間が短くなる。
他にも実際に課題を抱えている人のニュアンスも、仲介したりドキュメント越しだと伝わりづらい。かなり。
それでも、大きなシステムを一人で作りきるのは無理があったり、営業やビジネス側の人だからこそ気づける課題もある。直接やり取りすることが、いつでも正解ってわけではない。
長期的なインセンティブ
契約範囲で完結させるか、長期的にリピートする前提かの話。
個人ならではというよりも、契約の単位が短いか長いかも関わる話だと思う。
一定の期間ごとに契約の範囲を決めてその対応をする。その繰り返しだと、範囲内の工数と利益に目がいく。それ以降のことはまた相談して契約してくださいってなる。
長期で運用や保守まで同じ人がやる前提だと、目先の契約範囲より、その後の拡張や撤退も含めて最適化するほうが、結果的に自分が楽になる。目先で「動けばOK」を選ぶと、半年後の自分が困るだけ。
個人かチームか、受託か自社かという話ではなく、信用の積み重ねが直接の利益になる構造かどうかだと思う。複数人が関わっていたり、会社の皮があると、その構造が薄まる。納品物や社内の評価のために動けてしまうから。
個人でも契約範囲で済まそうとする人もいれば、受託会社でも長期的な関係づくりに注力するところもある。
バスファクターへの意識
真逆に聞こえるけれど、個人開発は引き継ぎ可能なコードを書きやすい。
特に後から自分のコードを見返したことがある人は。
チームだとその人に聞けばいいで済んでも、個人だとできない。
個人開発者は、意識して客観的な物を残さないと他に誰も理解できないことがわかる。
長期的に関わり続ける前提だと、後から見返すのが自分なので、記憶を辿るか記録に頼るかになる。
記憶は時間と共に薄れて、記録は残る。数ヶ月後は、書いた時の自分とはほとんど他人になるし。
前のセクションで挙げた判断ログや README は、バスファクター対策として書いたけれど、実は自分のためにもなる。数ヶ月後に自分が作ったものを見返した時、判断ログがなければ、自分も他の人と同じ状態になっているから。
それでも個人開発で、単発の契約みたいにやって終わりみたいな形を前提にすると、その場しのぎの対応をされやすい。技術的な提案をしてもらえなかったりする懸念もある。
つまり、個人開発が自動的に良い、ってことでもない。
エンジニアリングでは消せないリスク
こういう対処をしていても、リスクは残る。
判断の背景にある文脈
ADRやDesign Docを作っても、書かれない理由は出てくると思う。
検討して却下したこと、その時の会話、「なんとなくこっちが良さそう」みたいな直感。
いちいちドキュメントに書くと手間が膨大になるような細かいこと。
作り始めた段階で時間の制約の中で更新されない。
結局、後から見て間違っていたり、足りていない状態になる。
引き継ぎにかかる時間
ドキュメントを残したり工夫しても、引き継ぎの手間が完全になくなることはない。
ドキュメントにできること以外にも、お客さんやユーザーとの暗黙の合意。
機能的には動くけど、実際の使われ方とは少し違うこと。「この挙動は意図的にそうしている」みたいな、コードを読んでも分からないもの。
単純に時間がなくて、システムの背景を聞かないとわからないこともある。
ドキュメントを作っているから簡単に引き継げるけど、それでも確認したい点は出る。
個人開発に固有の問題でもない
こういう気をつけても残るリスクは、個人開発者に固有のものではなく、組織やチームの引き継ぎでも起きる。
組織でも責任が曖昧になることはある。
数年経って要件を誰も把握していない状態でも、声を上げる人は少なかったり。
契約ごとの開発を続けたりしていると特にそうなる。
複雑になったシステムのキャッチアップ、仕様を決めた理由の把握。こういう引き継ぎの手間は、個人だと契約終了のタイミングで実感する。
組織だとそれがなくなるわけではない。目に見えずに期日や価格、成果物の品質に響く。自社開発の組織なら他の開発がその分遅れる。
組織は、チーム継続性の裏で、こういうリスクを隠せる。個人の場合は隠せないだけ。だから、個人だとリスクがあるように見えやすいのかも。
最後に、内容をもとに、誰にどんな形で開発を依頼するかを考えるときのまとめ。
そのシステムは、いなくなった時に即座に引き継げる状態か？
要件はすでに固まっているか？作りながら詰めたいか？
開発後の運用は、同じ人にやってもらいたいか？それとも別の人や体制でもいいか？
システムの規模や重要度が、冗長性の対策コストに見合うか？
個人がいいか組織がいいか、どんな契約の仕方がいいか、合わせて考えると少しクリアになる。
どれもリスクは残るけれど、自分にとって扱いやすいリスクを選びやすくなると思う。
リスクがないように見える選択肢ではなく、見えているリスクを引き受ける選択肢。
※この記事は Medium に 2026年6月15日 に公開したものを転載しています。
作った人がいなくなったら動かせなくなりそうなとき：
https://yoshiakihayashida.com/consulting/
