個人開発で経験できないこととは

Date2026/08/18 Last Modified2026/08/18

概要

現在、私がプロジェクトのリーダーとして携わった案件はほとんど少人数の案件であり、エンジニアが１人というのも珍しくない。
キャリアを調べていくと、大企業でエンジニアとしてスキルを磨くことが重要だというのを感じているのだが、具体的にそれがどんなスキルなのかがよくわからない。
作業量が多くなる、というだけならAI時代は勝手に解消するだろうし、必要な知識が多くなる、というだけでもAI時代がなんとかしてくれる。
小規模プロジェクトで経験できないことは、今の時代どこに存在するのだろうか？

予測と現状

CyberAgent開発者ブログ
少し他社の状況などをのぞかせてもらうと、やはりAIによって人員を削減していけるという見込みが強いことがうかがえる。
ここでは2人+AIによって6人分のアウトプットを目指す例を提示している。
国外でもレイオフ等が起こっている現状を鑑みるに、やはり「作業量が多い」というだけでは大企業に移る価値はほとんどなさそうである。

それを前提に、もっと大企業ならではの事象について調べてみよう。

1. 「他のエンジニアのための技術」という需要

LINEヤフー開発者ブログ
こちらは社内向けの中央認証・許可基盤をプライベートクラウドIAMに集約している例。
広義で言えば誰かのための開発ではあるが、自社のチームを動かすための基盤づくりをするという開発経験は大企業ならではであると思う。
よく耳にしていたエンジニアのキャリアラダーにおいても、他のエンジニアに対する影響力を持っていることが上位に上り詰める条件になっていたので、これは納得がいく。

2. 「レガシーシステムの統合」などの経験

LINEヤフー開発者ブログ
こちらは、LINEとヤフーという巨大企業のデータ基盤を統合するために行った作業の記録。
小規模では人力でどうにかなったり、少し社内フローを変えるだけでデータ構造は何とかなっていたが、巨大システム同士となると制約の厳しさはありえないほど高くなる。
データカラムが違うという些細な問題ではなく、ファイルシステムや権限、基盤全体に影響するというのが大きな違いである。　　 そもそも画一的ではないデータを統合する経験というのも、小規模プロジェクトでは得られにくい経験だと思うし、システムを結合するというのも単にAPIでデータを通すだけではないということを考えると、今の技術力では到底手が届かない領域だとわかった。

3. 「高負荷化でパフォーマンスを出す」という経験

LINEヤフー開発者ブログ
こちらは莫大なデータ量を管理するためのプラットフォームを進化させてきたという記録。
利用者が多いサービスは、それほどログが膨大になり、データは上限突破するし人やAIですら監視できる限界を超えてしまう。
一般的なアプローチでは数の暴力に押し倒されてしまうとき、それをどう持続可能なシステムに作り上げていくかという経験は、利用者数が極端に多いサービスならではである。
これには一般的なアプローチを知った上で今どんな問題があるかを切り分けないといけないし、それが生み出す副次的な問題というのも経験がないと知りえないことばかり。
単純に高負荷であるというだけで、応用問題のように違う対応が求められるという点は小規模プロジェクトではわからないことである。

4. 「社会的な信用を扱うために証明を行う」という経験

Stripe公式
こちらは、Stripeという決済基盤を扱うために社会的な承認を勝ち取るためのセキュリティ基準を示したもの。
受託開発という特徴上、あまり厳密なセキュリティや証明が求められることがなく、最低限の担保があって最安値で最速でできることが求められる案件とは真逆の特性をもった経験である。
単に攻撃を受けなければよいとか、独自のテストに通過したからセキュリティが安全、というわけではなく、普遍的に求められる技術を網羅していてそれを証明するために学ぶ必要があると考えると、これも少人数のプロジェクトではなかなか求められない技術であると感じる。

5.「規模の大きな障害対応」に備える経験

Slack開発者ブログ
こちらは、規模も利用者も大きいプロジェクトを障害復旧させる難しさを解決するため、アーキテクチャを置き換えたというもの。
規模が小さいと、どうしてもログを確認できれば良いとか、即時で対応しなくても大丈夫とか、エンジニアが出ていって有事のときに直せばいいとか、そういった些末な問題ばかりが焦点になってしまう。
それはなぜかと言えば、可用性を上げるための費用対効果が望めなかったり、一人のエンジニアでは直せないほどの重度の障害に陥ることがほとんどないからである。
小規模では「障害は仕方ないものとして対応策を充実させる」のに対し、大規模では「基盤を変えてでも障害の発生率を低下させる」ことが重要になるという点が、規模による大きな違いであると感じる。こういった経験はコストの観点からなかなか実行できない。

まとめ

調べてみて感じたのは「小規模プロジェクトでは知るよしのない問題」がたくさん存在するという事実だった。
データ量、コスト、アクセス数、厳しいサービス品質基準……。どれも、ある閾値を超えて初めて起こる現象であり、これは大規模プロジェクトでないと確実に経験できないと感じた。
もっと知識を付ければ専門家になれるはず、今取り組んでいる問題をより良い方法で解決すればスキルアップが望めるはず、という考えは少し間違えていた。
そもそも経験することができない事象があって、知識ではなく体験として知らないことには理解のしようもないことがある。

将来的に、単独または少人数で活動していこうという思いがあって、ならば小規模のプロジェクトに特化していればよいとなんとなく思っていた。
けれど、仮に大規模プロジェクトの一部メンバーとして活動する場面があったなら……それは全く違う内容になるだろうということがわかる。
Webアプリケーションエンジニアとしてもっと良いスキルを身につけるためには、大プロジェクトに携わる経験が必須だと腑に落ちた。