目次
最終更新日：2026年7月9日
システム開発を内製している会社は世の中にたくさんあります。我々は顧客から受託開発でシステム開発の仕事を請け負う開発会社という立場ではありますが、私は企業が自社のシステムを社内で内製することに関しては賛成であり、内製が開発体制の理想形だと考えています。
しかし内製するからには企業としてシステムの保守メンテナンスを永続的に続けられる体制が必要であり、会社の規模や予算を考慮して必要な体制を継続して維持できない場合に、我々のような外部の開発会社が顧客の力になることができて存在意義が出てきます。
こちらの記事でも書いていますが、システム開発を内製化する時の一番のポイントは「複数人体制にすること」です。それも将来に渡って継続して複数人の体制を維持していくことが必要です。
社内で複数人体制を維持できないのであれば、その仕事は専門の会社に外注することが望ましいです。そうしないと企業として必要な体制を継続して維持することができなくなり、それによって様々なトラブルが将来的に起きるリスクを抱え込むことになるからです。
継続的に複数人体制を維持できるのであれば内製化を検討する
それができないのであれば外注する
これが内製化するかどうかを見極める際の大きなポイントです。
アクシアには日々様々な問題を抱えた顧客から相談のお問い合わせをいただきます。その中には「システム開発を内製していたがうまくいかない」というものがあります。そして内製化のトラブルのほとんどが、複数人体制を作っておらず、エンジニアが１人体制となっていることによって起きるトラブルです。
エンジニアが１人体制であることを軽く見ている企業さんが正直結構あるのですが、後々のトラブルの元です。システム内製化の失敗パターンを、今までアクシアに寄せられた相談内容をベースに6つご紹介します。
失敗パターン①：エンジニアが業務のボトルネックになる
業務を１人体制にしてはならず複数人体制にしなければならないということは、エンジニア業務に限った話ではなくどんな業務にも当てはまる話です。
アクシアでは2012年から今日まで残業ゼロを継続しているのですが、残業削減を行う上で大きなネックになることの１つに「属人化された仕事」があります。属人化された仕事とは、仕事が人に張り付いてしまい、その人しかできなくなってしまった仕事のことを言います。そして仕事の属人化は、業務が１人体制となっている場合に発生します。
エンジニア１人体制だとエンジニア業務が属人化します。属人化しているのでエンジニアの仕事が遅れていても、エンジニアが病気等で突然休んだとしても、そのエンジニアの業務を代わりに進行できる人が誰もいない状態となります。
そうするとそのエンジニアの仕事がストップしても遅延をリカバリーできる人が他に誰もいなくなりますから、１人のエンジニアの仕事が遅れることによって、そこに関連する業務に就いている全ての人に影響が及ぶということです。
だから仕事の属人化は業務効率化の大敵であり、それは業務のボトルネックとなります。
なおこの属人化は、近年増えている「非エンジニアが生成AIで作った社内ツール」でも同じように起きます。作った本人がコードを説明できないぶん、むしろ深刻になりやすい点はAIで非エンジニアの会社はどこまでシステム開発できるかで解説しています。
失敗パターン②：必要なドキュメントが残らない
システム開発では通常は設計書やソースコード内のコメントなど、業務を進める上で必要なドキュメントを残すことが通常です。しかし１人エンジニア体制の会社では、エンジニアが必要なドキュメントを全く残していないということが当たり前のように発生します。（１人体制でなくても設計書が無いという話はよく聞きます）
ではなぜ１人体制のエンジニアが必要なドキュメントを残さないことが多くなるのかと言うと、１人体制なので他のチームメンバーと情報共有を行う必要が少なくともその時はないからです。
もし１人体制だったとしても、そのエンジニアが将来に渡ってずっと退職もせずに休みもせずに働いてくれるのなら問題ないかもしれません。しかし企業経営を考える上でそんなお花畑的な思考であってよいはずはなく、退職するリスクや病気になるリスクも考えておく必要があります。だからこその複数人体制です。
どんな業務でも「自分以外の誰かがこの業務を引き継ぐ可能性がある」ことを視野に入れておく必要があり、だからこそドキュメントを残しておくことは継続的なシステムの保守を行っていく上で重要です。
失敗パターン③：何をしているか誰にもわからない
１人体制だったとしても、エンジニアの業務を多少なりとも理解できる人間が社内にいるのであれば、エンジニアが行っている業務が妥当であるかどうかを客観的に判断することもできます。
しかしエンジニア１人体制によくあるケースとして、エンジニア以外にITのことを理解できる人間が社内に誰もいないということが結構あります。そうするとエンジニアが何か業務を行っているっぽい感じはするけど、何をやっているのか実際のところはよくわからないという事案が発生します。
実際にはエンジニアが業務に関係ないことをやっていたり仕事をサボっていたりしても、他にそれを正当に評価できる人間が社内に誰もいないのでどうしようもないわけです。
アクシアにご相談に来られた過去の顧客事例で言いますと、素人が見ると一見もっともらしいことをやっているように見える結構なボリュームのサーバーメンテナンスの手順書に従って、定期的にルーチンワークとしてある業務が組み込まれていたのですが、その手順書の中身を１つ１つアクシアで見ていくと、何の目的もなく、何の意味もなく、各種アプリケーションの再起動を延々と行っているだけだったという事例がありました。
専門知識を持ったエンジニアがそれを無意味なこととして理解できていないわけがなく、周りの人間がそれを無意味なことだと理解できないことを良いことに、一見すると何か仕事をしているかのように見せかけて単にサボっていただけでした。
何か仕事をしているようには見えるけど、実際のところ何しているのかさっぱりわからないという状態を放置してきたがために、その顧客はこんな無駄なことに延々と人件費を払い続けてきたわけです。
失敗パターン④：エンジニアの趣味で業務が進む
このあたりから段々と香ばしい感じがしてまいりましたが、アクシアにご相談に来られた顧客で過去実際に起きた事例をベースに生々しくご紹介したいと思います。
エンジニアの趣味で業務が進むとは具体的にはどういうことかと言うと、業務のことを考えたら本当は必要ないアプリのライセンスやサーバーを、エンジニアが「使ってみたい」と思っただけで会社の経費で導入してしまうということがあるということです。
もちろんエンジニアは自分の趣味のために経費を使うとは上司に報告なんかしません。必要だから導入すると言います。でも実際にそれが必要であるかどうかを判断することすらエンジニア以外はできないため、無駄なライセンス費用や無駄なサーバー費用が知らないところで発生してしまっていたわけです。
エンジニアが趣味で作った、業務とは全く関係ないアプリケーションが、業務には全く必要ないサーバーを会社のお金でレンタルして運用されていたようなケースもあります。顧客から依頼されてアクシアで顧客の保有するサーバーを全部調査したことによって発覚しました。
よくわからないアプリケーションが動作しているサーバーがあったので「これ何ですか？」と顧客に確認したら会社とは全く関係のないエンジニアの趣味で作られたアプリケーションだったという笑えない話です。
エンジニアは知的好奇心旺盛な人が多いですし、その知的好奇心を満たして成長するためにエンジニアが会社のお金を使ってはいけないということではありません。しかしそれをやりたいのであれば会社に話は通して許可をもらうべきですし、こっそりやったらそれは泥棒と同じですね。
失敗パターン⑤：エンジニアに誰も逆らえなくなる
社内にエンジニアが１人しかいない会社だと、エンジニアに誰も逆らえなくなっているようなこともあります。エンジニアが「これどうせ俺にしかできないだろ」という高飛車な態度になっていて、周りの人に対しても偉そうな態度を取っているようなケースです。
こういう事態は、エンジニア１人体制、エンジニアのスキルがそこそこある、エンジニアの性格が悪い等のいくつかの条件が重なった時に発生します。
こういう状況に陥った場合に事態を打開していくことは簡単ではありません。スキルの低いエンジニアであればまだ対処のしようもありますが、そこそこスキルのあるエンジニアであれば、自分の今の地位をキープするためには「この情報は出さない方が良い」というポイントがわかっています。
そのような場合に、まともな保守体制を構築するために必要な情報を引き出すことは苦戦することがほとんどです。色々と理由をつけて肝心な情報はエンジニアが１人で握ったままにしようとするからです。
それでも苦労して情報を開示させていき、ようやく調査できる状態になって細かく中身を調査していくと、絶対に社外からアクセスできない前提となっているはずのシステムなのに、１つだけ外部からアクセス可能なIPアドレスの穴が発見されたことがありました。
そのIPアドレスが何かをエンジニアに問い詰めたところ、そのIPアドレスはそのエンジニアの自宅の固定IPアドレスでした。外部からアクセスできないように構築したはずなのに、そのエンジニアだけは自宅からアクセスできるようにこっそりと穴を開けていたわけですね。
情報を抜き取ろうとしたと言うよりは、緊急事態が発生した時に自宅からでも調査できるように穴を開けていたのだと思われますが、いずれにしても会社に無断で行った行為であり、こんなものは普通にセキュリティ的に問題があります。
社内にエンジニアが１人しかおらず、エンジニアがやりたい放題の状態となってしまうと、エンジニアに対して誰も何も言えなくなってしまうことがあります。
失敗パターン⑥：休職・退職で業務がストップする
１人エンジニア体制の一番の問題点はこれです。そのエンジニアが休んだり退職したりしてしまうと、業務がストップしてしまうリスクがあります。場合によっては致命的な事態に陥ります。
その人が抜けてもすぐに代替要員を補充できる業務であったり、一時的に対応できる人がいなくなっても大きな問題にならない業務であれば、１人体制も許容できます。
しかし企業のITシステムは業務の根幹に関わっていることがほとんどであり、システムの保守対応がストップするということはその企業のビジネスそのものがストップするリスクを抱えているということを理解していない人が多すぎるように思います。
エンジニア１人体制で今その時は業務がうまく回っているように見えるかもしれませんが、ある日突然そのエンジニアが退職してしまうことだってあるかもしれませんし、急病や事故でしばらく業務に入れなくなるようなことも考えなければなりません。
今まで対応してくれていたエンジニアがいなくなってしまったという段階になって相談に来られる会社さんが本当に多いです。この段階になってからだと被害も大きくなりますので、できればもっと早い段階で相談に来てもらいたいです。実際にエンジニアが退職してしまった後、何をどう引き継げばよいかはシステム引き継ぎの進め方で解説しています。
１人エンジニア体制は常にこのようなリスクに晒されているということになりますので、できるだけ早い段階での対処が必要です。１人エンジニア体制になってしまった時点でできれば相談にきていただきたいです。
社外にシステムの保守を依頼している場合でも、依頼先が１人体制になってしまっているようでは意味がありません。フリーランスか会社かに関わらず、特定の個人1人に企業システムの保守を依存する体制は、社内の1人体制と同じリスクを抱えているということです。
生成AI時代、1人体制のリスクは消えたか
この記事の初出は2018年ですが、生成AIが当たり前になった今、状況は変わったのでしょうか。私の答えは「むしろリスクは大きくなった」です。
生成AIによって、エンジニア1人が作れるものの範囲とスピードは劇的に広がりました。しかし体制が1人のままなら、それは属人化する資産が従来より速く・大きく積み上がるということでもあります。作るスピードが上がるほど、「その人しか触れないシステム」が加速度的に増えていく。1人体制のリスク構造は、AIでは何も解決されていません。AIが書いたコードの検証も、障害が起きたときに責任を持って対応することも、結局は人間の体制の問題だからです。
一方で、AIによって緩和された面もあります。ドキュメントが無い・作った本人がもういないシステムでも、AIを活用したソース解析で引き継ぎを効率化できるようになりました。アクシアでもこの方法で他社開発システムの保守引き継ぎを行っており、開発言語も問いません。「もう手遅れかもしれない」という状態からでも打つ手はあります。
まとめ──1人体制は「問題あり」のサイン
企業のビジネスの根幹を担うシステムに対応するエンジニアの業務は、原則として１人体制にしてはいけない業務です。１人エンジニア体制になってしまっている時点で「問題あり」の状態ですので、その場合はできるだけ早い段階で、複数人体制に改善するなり、我々のような専門の開発会社にご相談されることをお勧めいたします。
なお、この記事では「1人体制」という最大の失敗要因に絞って紹介しました。採用・育成・マネジメントを含めた内製化の成功条件の全体像はシステム開発の内製化に必要な4つの条件をご覧ください。
すぐに複数人の開発体制を用意できない場合は、開発リソースを月額予算で確保し、社内に開発チームがあるような感覚で継続的に開発・保守を任せられる月額制開発もご検討ください。担当エンジニアの退職などで開発が止まってしまったケースの受け皿としてもご活用いただけます。