【未経験からエンジニア転職】これからは設計や要件定義を勉強すればOK？実装はオワコン？

まんじです〜

今回は未経験からエンジニア転職で、これからは設計とか要件定義を勉強すればOKなのか、実装はAIでオワコンなんじゃないか、っぽい話でも書こうかと思います。

この話をしようと思った理由が、僕自身LVLPATHっていう個人のしょぼいプログラミングスクールをやってて、他のプログラミングスクールのLPを参考にさせてもらってるんすよね。

そしたら「AIで実装とかプログラミングは簡単になって誰でもできる。なのでこれからは設計とか要件定義の時代。だからそこをうちは学べます」みたいなのを見たんですよ。

結論から言ってしまうと、それは嘘っていうか、結局、設計とか要件定義って実装レベルの理解ができてないとできないんですよね。

もちろん個人で使うレベルのバイブコーディングアプリとか、そういう規模感なら行けるんですけど、そのレベルだとAIになすがままにされてるだけの、なんちゃって要件定義となんちゃって設計なんですよ。

技術的にトレードオフを踏まえて「これはこうだからこっちの方がいい」っていう視点では、絶対にやってないです。

モダン自社開発とかの一定の規模になると、マイクロサービスみたいに複数のサーバーが分散して1つのアプリケーションをなす、分散アプリケーションみたいな感じになってきます。

ポートフォリオレベルの、リポジトリ1つでみたいな感じだと基本的に無理ゲーになるんで、複雑さを簡単にするために、結果的に素人が扱いにくい複雑なアーキテクチャになるんすよね。

で、何話してんのか忘れちゃったんですけど、これがモダン自社開発の実務レベルで、それを扱うのが普通のエンジニアなんですけど、設計とか要件定義ができるのは、結局そこで実装レベルが普通にできる人なんですよね。

ちょっと前置きが長くて疲れちゃったんですけど、3つぐらい話して終わろうかなと思います。

1. そもそも実装レベルができないと要件定義や設計は無理

1個目が、そもそも実装レベルができないと要件定義とか設計は無理っていう話で、冒頭で話したやつですね。

例: いいねボタンをリアルタイムで同期したいと言われたら

例えば、ビジネスサイドの人から、自社のSaaSのSNSアプリのいいねボタンを、非同期的にリアルタイムでシンクロしたいです、って言われたとするじゃないですか。

そういう時、普通にエンジニアをやってると、何パターンか浮かんでくるんですね。

• Socket.IOでやる
• 定期的にポーリングでフェッチする

そんな感じでなんとなくイメージができたら、あとはそれを実装するにあたって、

• APIは既存のエンドポイントが使えるのか、新しく立てた方がいいのか
• フロントエンドは大体このコンポーネントのここら辺にある

みたいにイメージするわけですよね。

実装の大枠のイメージがなんとなくできてるので、要件を聞いて、それを設計レベルに落とし込んで、実装はAIにやってもらうのか分かんないですけど、そういう風にやる。

僕が軽く話しただけでも、Socket.IOとポーリングの2つが出てくるんですよね。

現状の実装を踏まえて他のところがどうなってるのかも、AIに読み込ませればなんとなくできるんですけど、そこで「こっちの方がいいっぽいな」っていう人間的な意思決定が入るわけです。

今のは設計にもならない、タスクを1つ作ってやるぐらいの小さな話なんですけど、Xみたいな本当に大規模なシステムになると、データ更新がやばいんで、データレベルとかバックエンド側のキャッシュとかも意識することになります。

結局これって、ある程度技術力がないとできなくね？ってなりますし、仕事で扱うレベルになればなるほど、ポートフォリオとか個人の簡単なバイブコーディングアプリを作るレベルとは全然変わってくるんですよね。

機能要件だけじゃなく非機能要件も絡んでくる

AI使って適当にアプリを作りますみたいな感じだと、機能要件しか分かってない人が割と多いっていうか、それが普通だと思うんですけど、ある程度のデータ量とか規模になってくると、非機能要件も絡んできます。

例えば、どっかのテーブルにめちゃくちゃデータがあって、それをフロントエンドから高頻度で更新しまくったり、サーバーサイドで同期的に処理するとバックエンドが死ぬ、みたいな時ですね。

そういう時は、AWSのSQSとかKafkaみたいな感じで、非同期的な処理という、普通の実装とはまた違った扱い方が必要になります。

あとはバッチジョブとか、そういうのも結構出てくるんですよね。

データ量とかリクエスト数を考慮した上で設計するっていうのは、実装レベルをちゃんとやった人じゃないとできないんですよね。

パターンを暗記してやるものではなくて、経験に基づく慣れみたいなところが結構あります。

Googleとか、AirBNBはあんま使わないんで、Booking.comとか、AWSもエンジニアじゃないと使わないか。そんな感じの一般的にメジャーに使われてる大規模なサービスはもちろん、そこまで大規模じゃなくてもモダン自社開発で扱ってるようなシステムになると、実装レベルの理解がないと要件定義も設計も無理ゲーです。

浅く適当にペロッとやったところで、そんな簡単にできるようになるもんじゃないんですよ。

普通に優秀な人が2、3年実務をやって、ちょっとずつできるようになるっていう感じなんで、そんな簡単な方法でなんとかなるもんじゃないんですよ。

2. どんな方法を取っても近道はない、普通にやるのが一番早い

2つ目が、どんな方法を取っても近道はなくて、普通にやるのがなんだかんだ一番早いっていう話ですね。

大学受験の例

余談になっちゃうんですけど、大学受験とかがすごく典型的で、効率がいい勉強法とか、最強の勉強法とか、この参考書が最強とか、受験生の頃に僕もいろいろ学ぶわけですよね。

もちろんある程度いい感じのものもあるんですけど、手法ベースで、いかに楽して結果を出すかっていうのは、理想を言うとやりたいんです。

でも人間はダメな生き物なんで、真正面からやるんじゃなくて、楽してうまくいく方法に本能的に引かれてしまうんですよね。

「こっちの方がいいかもしれない」「あっちの方がいいかもしれない」って天秤にかけまくった結果、1年2年経った時に何も身についてなくて、オーソドックスな勉強の仕方で普通に真正面からやってた人の方が、結局早いやんけ、一番結果出てるやんけ、みたいになる。

それは僕が大学受験してる頃も思いましたし、エンジニアになってからもすごい思いましたね。

もちろん資本主義ワールドになると、誰もまだやってないけどここはワンチャンある、みたいなのに張る人もいるんですけど、エンジニアの技術を上げるとか、わりかし再現性が高くて努力ゲーなものって、基本的には近道があんまなくて、普通にやるのが結果的に一番めちゃくちゃ早いっていう。

それは普通に多分事実だと僕は思います。

スクールの小手先テクニックは嘘

プログラミングスクールとか、スクールじゃないところにしても、何かしらの小手先のノウハウとかテクニックとか、他と違うことを訴求しないと埋もれてしまうっていうのがあります。

なので「AIで実装は簡単だから、うちなら要件定義とか設計も学びます。そうするとエンジニアの市場価値が爆上がりします」みたいに言うわけなんですけど、それは普通に嘘ですね。

最近だとアフターAIで、FDEとか、GTMエンジニアとか、いろいろ言われるんですけど、意味がないっす。普通に僕はほぼ意味がないと思ってます。

元々のベースの技術力をちゃんと伸ばすっていうのが、エンジニアの労働っていう形態ではすごい大事なんですよね。

個人で稼いでいくってなっても、技術力を最低限のところまで高めて、あとはマーケットとちゃんと向き合うとか、そういう本質的なことの方が大事なんじゃないかなと思います。

小手先を追求してうまくいってる人を、僕はほぼ見たことがないです。

あとモダン自社開発界隈のエンジニアリングマネージャーとか、テックリードとかCTOの人で、「僕は要件定義とか設計を学んだからここまで来れたんです」って言ってる人は、誰1人見たことがないんですよね。

ちゃんと勉強して、ちゃんと実装して、メガベンチャーとかGAFAMに入って、その出身だから市場でちゃんと評価されてて、今も現在進行形で難しいことを扱ってるから上のポジションにいる、みたいな。

結局つまんない話なんですけど、世の中はそういう風に回ってます。

だから変なテクニックに翻弄されるよりも、真正面からやる方が、エンジニアの労働で市場価値を高めるっていう点では、2周3周回ってやっぱ早いと僕は思います。

25歳の僕が設計から学んでたら

方向性は大事なんですけど、25歳の社会底辺駆け出しクソ雑魚エンジニアで実家暮らしだった僕が、設計とか要件定義から学んだとしても、何年後かの自分とは経験の差がすごいあるんで、どんな手法を取っても逆立ちしても勝てないんですよね。

なんで、普通にやるのがやっぱ1周、2周、3周、4周回って早いです。

3. 実装レベルからジュニアで入って、ステップアップしていけばいい

3つ目が、実装レベルからジュニアレベルで入って、そこからステップアップしていけばいいっていう話ですね。

最初から上流工程だの要件定義だの設計だのをやればいい、みたいな小賢しいことはどうでもよくて、モダン自社開発に、ちゃんとポートフォリオを作って6ヶ月とか勉強して、ジュニアレベルで入って、そこからちょっとずつステップアップしていけばいいです。

ステップアップっていうのは、例えばこんな感じです。

• まずはコーディングエージェント(Claude Code、CodeX、Cursorとか何でもいい)で、実装レベルを日々こなしていく
• 上司から「これぐらいの実装は任せてもオッケーだね」ってなってくる
• ビジネスから「こういうことをやってほしい」って言われた機能を、要件定義書みたいなものをNotionとかに書いて、上司にレビューしてもらって、それから実装する

そういう小さな設計から始めて、ちょっとずつ繰り返していくと、もうちょっと規模のでかい設計ができるようになってきます。

これを何回も何回も繰り返してると、ビジネスサイドから来たものを直で受けて、「現在のシステムを踏まえて、こういう風にします。いつまでにやります」って言えるようになるっていう感じですね。

そんな感じで、結局ステップアップしていけばいいっていう話です。

まんじからの感想

まとめると、設計とか要件定義から勉強すればいいとか、AIで実装はオワコンになってるからとか、そういうのは普通にどうでもいいです。

もちろん昔は実装が難しくて、今はAIを使って割と楽になったっていうのは否定できないんですけど、結局実装レベルができることによって、要件定義とか設計とか、システムとビジネスサイドをつなぐみたいな上流のレイヤーに、ちょっとずつ近づいていけるっていう感じですね。

LVLPATHの未経験からの講座買ってもらって手順通りやってもらって自分に壁打ちやら質問してもらえれば、小手先のテクニックは全然推奨しないんですけど、真正面から方向性を整えてやるっていうことをやっとるんで、方向性は多分定まるような気がします。

ってことで終わりです。