AWSもデプロイも知らなかった自分が、6ヶ月でリリースまでやった話

はじめに

正直に言うと、「デプロイって何？」って状態でこの案件に入りました。

……と言うと、完全未経験みたいに見えるんですが、
C#やJavaでの開発経験は5年(オンプレのみ)ずつほどありました。

ただ、WebやAWS、Docker、デプロイまわりはかなり初心者でした。

AWSも、「なんかクラウドのすごいやつでしょ？ストレージがいっぱい？」くらい。

で、気づいたら6ヶ月後にリリースしてました。

今回はそのときの話をありの〜ままに〜書きます。

プロジェクトざっくり

• 新規サービス + 改修案件
• 既存サービスのアップデート
• 自分はプロジェクトの佳境から参加し、設計の通り新規サービス開発（たまにデバッグ係）

技術はこんな感じ

• Nuxt3 / Vue3 / Bootstrap
• Node.js / TypeScript
• MySQL
• AWS（ECS(Fargate)×2 / S3）
• Docker

入ったときの自分

C#やJavaでの開発経験はありましたが、
インフラやデプロイの知識がないと、ここまで詰まるのかと痛感しました。

• AWS → 触ったことない
• デプロイ → 用語として知らない
• インフラ → みんなやりたがらないからなんとなく怖い
• Web → いつもお世話になっております

今思うと、だいぶ無茶っすね。

あと、このとき分かってなかったのが、
コードを書くことと、Webサービスとして動かして届けることは、かなり別物だったってことです。

C#やJavaをやってたので、「コードを書く」こと自体は普通にやってきましたが、
Webはその先にある

• どこに置くのか
• どう公開するのか
• どの環境で動くのか
• 何がどこにつながってるのか

まで含めて理解が必要で、ここが想像以上に別世界でした。

WEB初心者の乱

デプロイってどこに行くの？

これ、最初ほんとに意味わからなかったです。

ローカルで動く
→ OK

でも「デプロイして」って言われる
→ どこに？？？

本番は分かるけどSTG環境？（シューティング環境？なんそれ）
物理サーバーどこ？
誰が持ってんの？
Dockerってなんでクジラなん？
海ってなんで青いの？
宇宙ってどこまで続いてるん？

頭の中ずっと「？？？」でした。

環境ってなに（dev / stg / prod）

朝会での会話がまず理解できない

• 「STGに上げといて」
• 「それは大丈夫、本番じゃないよ」

いや、同じじゃないの？怖いんだけどって思ってました。

ここは正直、触るまで理解できなかったです。

CORSエラーで普通に詰む

これ、かなりハマりました。

• APIは動いてる
• でもフロントから叩けない

エラー出る
→ 読んでも意味わからない

「CORS policy」

いいいいや誰やねん。

設定見ても合ってる気がするし、でもダメ。
ここで一回ちゃんと詰みかけました。

最終的に思ったのは

👉「CORS、概念としては分かるけど、気持ちは一生わからん」

です。

後から思うと、フロントだけ見てもダメだし、
バックだけ見てもダメだし、
インフラとか環境差分も絡んでたんですよね。

そりゃ詰まる。

初めて“つながった”瞬間

ある日、ようやく開発環境が整い、初めてちゃんとWebページ（まだHelloSuzukiレベル）が表示されたとき。

普通にちょっと感動しました。

で、そのままの勢いで
夜遅いのにCTOとCAIOに直接通話お願いして、

👉「WEB童○、卒業しました！！！」

って報告しました。

今思うと何言ってるんだって感じなんですが、
夜の変なテンションだったことを加味しても、そのくらい「つながる」って嬉しかったんです本当に。
お二人方とも鈴木の熱に侵され、「おお！卒業おめでとう！！やったな！！www」と自分のことのようにハイテンションで喜んでいただきました。
そのせつは夜遅くに大変失礼いたしました。

※ ただし、ローカルで動くのと、実際に公開されるのって、全然別物でした。

途中で気づいたこと

デプロイって最後にやるもんじゃない

最初は完全にそう思ってました。

でも違う。

後からやろうとすると、
👉 普通に破綻する

これは一回やらかして気づいたやつです。

デプロイって最後にやる作業というより、
最初から

• どういう構成にするか
• どこで動かすか
• 何を環境差分として持つか
• どこまでをローカルで吸収して、どこからを環境側で見るか

このへんを決めておかないと、後半で全部しわ寄せが来るんだなと思いました。

フォルダ構成、なめたらダメ

途中から「あれ？」ってなって

👉 これ、そのまま設計じゃん

って気づきました。

最初はほんとに、フォルダ構成って
「ファイル探しやすいようにしとくもの」くらいに思ってたんですよね。

C#やJavaでは業務ロジック中心で書くことが多かったので、
正直このときは
「多少散らかっても後で直せるでしょ」くらいの感覚もありました。

でも、途中から違和感が出てきました。

• どこを直せばいいか迷う
• 似たような処理がいろんな場所に散る
• 1か所直すと別画面や別環境でズレる
• ローカルでは動くのにSTGだとなんか違う
• 直したはずなのに別のところで同じようなことが起きる

で、そのへんが出始めたときに、ようやく思いました。

👉 あ、これフォルダ構成って整理整頓じゃなくて、責務の分け方そのものじゃん

って。

つまり、

• 画面の責務
• API通信の責務
• 共通処理の責務
• 環境差分の責務

この分け方が曖昧なまま進めると、
後半でコードを書くほど苦しくなる。

後半、自分の書いた構成に普通に苦しめられます。

コードが書けないわけじゃなくて、
最初の分け方の甘さが、後から効いてきた感じでした。

CTOが言ってた「まず理想の設計について話そうか、話はそれからだ」って、まさにここでした。

AWSわからんまま進めると無理

これ一番大きいです。

• ECSで何してるのか
• S3って何なのか
• ALBなんでいるのか

ここ分かってないと、

👉 エラー全部「意味不明な現象」になる

今回しんどかったのって、
知識がないから全部解けない、というより
どこから見ればいいか分からないことでした。
※知識あるっぽく書いていますが、ほぼないです。

アプリの問題なのか
コンテナの問題なのか
配信経路の問題なのか
設定の問題なのか

この切り分けができないと、全部ノイズに見えるんですよね。

今回うまくいった理由

今回リリースまでいけたのは、
正直、自分一人の力では無理でした。

• CTOによる設計方針の整理
• CAIOと進めたAI駆動での開発

この2つがかなり大きかったです。

特に、CTOの整理で大きかったのは

• どういう構成にするのか
• どこに何の責務を置くのか
• どこまでを切り分けるのか
• どう進めると詰まないか

このへんを言語化してもらえたことでした。

当時の自分は、問題が起きるたびに
「なんかうまくいかない」で受けていたんですが、
CTOはそれを

• 画面側で持つ責務
• API側で持つ責務
• インフラ側で吸収する責務
• 環境差分として切り分けるべきもの

みたいに整理して見ていたんですよね。

それが入ってから、
フォルダ構成で苦しんだことも、CORSで詰まったことも、

👉 ああ、全部つながってたのか

って少しずつ見えるようになりました。

つまり、
フォルダ構成で苦しんだ話と、CTOの整理は別の話じゃなかった
ということです。

AI駆動開発とのつながり

AIを使うと、

• 実装の初速は上がる
• 調べ物も早い
• たたき台もすぐ出る

これは本当にそうでした。

ただ、やってみて思ったのは、
AIって設計の代わりにはならないということでした。

むしろ逆で、

• どこに責務を置くのか
• 何を共通化するのか
• どの粒度で分けるのか
• どこまでをその場で解決して、どこからを構成で解決するのか

このへんが曖昧だと、AIで書くコードも普通にブレます。
乗るだけで痩せるブルブルマシンぐらいブレます。

それっぽく動くものは出てくる。
でも、後半でちゃんと効いてくる。

ここ、フォルダ構成で苦しんだ話とほぼ同じでした。

なので、AI駆動開発って「設計がなくても何とかなる方法」じゃなくて、
設計をしっかり固めてからする進め方なんですよね。

たぶん今回うまくいったのは、AI Agentが万能だったからじゃなくて、

• CTOが構成や責務を整理してくれていた
• CAIOが進め方(基本となるプロンプト)を作ってくれていた

この土台があったからでした。

学び（ここだけ読んでもいい）

デプロイは設計

最後にやるもんじゃないです。マジで。

手順の話というより、
責務分離とか、フォルダ構成とか、環境の切り分けまで含めて設計
なんだなと思いました。

早めにSTG触った方がいい

ローカルだけでやってると、
👉 後で知らない挙動に殴られる

インフラ避けると普通に詰む

避けた結果がCORSでした。

CORSは総合格闘技

• フロントだけ見てもダメ
• バックだけ見てもダメ
• インフラも絡む

全部理解してないと解けないやつでした。

「書ける」と「届けられる」は違う

C#やJavaの経験があったので、
ロジックを組むとか、処理を追うとか、そういう部分は土台になりました。

でも、Webサービスとして動かして届けるには別の視点が要る。

ここを知らないと、コードが書けても最後で詰まる。
これはかなり学びでした。

AIを使うほど設計が大事になる

AIを使うと速くはなる。
でも、設計が曖昧だと、曖昧なものを高速で増やす感じになる。

逆に、

• 責務が分かれてる
• 置き場が決まってる
• 何をどこで担保するか整理されてる

この状態だと、AIはかなり強いです。

まとめ

今回で思ったのは、

「Webってコード書くだけじゃない」

です。

もし過去の自分に一言言うなら

• とりあえずデプロイしてみろ
• インフラから逃げるな

あともう一つだけ言うなら

👉 「“なんとなく動いてる”は、だいたい動いてない」

これです。

おわり

同じように

• AWSよくわからん
• デプロイ怖い

って人は、たぶん大丈夫です。

自分もそこからでしたので。
（今も完全に分かってるわけではない）