🕒 読了目安：約 5 分
💬 この記事でわかること
- フロントエンドしか経験がない状態から、バックエンド・インフラを含めた全体設計をどう考え始めたか
- 「API・Lambda・インフラ構成」など、最初につまずくポイントとその正体
- 1から開発するときに必要な、“コードを書く前に決めるべきこと”の全体像
💻 実行環境 / 前提条件
- フロントエンドエンジニア1年目
- 現在の使用技術：Vue.js
- 以前の環境：ウォーターフォールでコーダーとしてwebサイト制作
- 現在の環境：スクラム開発
バックエンド・インフラ経験ほぼなし
1. はじめに
事務所の移転が近づいてきたある日。
社長から突然、タブレットを渡されてこう言われました。
「これ、受付で使うから。来客が来たらSlackに通知飛ぶように作ってほしい」
いわゆる、受付に設置したタブレットに来客者が名前や人数を入力すると、担当者に通知が飛ぶような仕組みです。
それを聞いたとき、私はこう思いました。
「面白そう！Vue.jsで入力フォーム作って、送信ボタン押したら終わりでしょ？」
今思えば、この“軽い気持ち”こそが、後に自分の無知さを突きつけられるフラグでした...
2. 疑問すら浮かばない「フロントしか知らない」頭の中
当時の私は、完全に「フロントエンドの世界」だけで完結していました。
- 要件を聞く
- デザインを作る
- コーディングする
- 納品する
「開発ってこういうものだよね」と、本気で思っていました。
しかし、いざ設計の話を先輩に相談した瞬間、空気が一変します。
- 「APIはどうやって叩くの？バックエンドは何で作る？」
- 「リポジトリどうする？構成は？」
- 「Node.jsのバージョン管理とか、環境構築どうする？」
「……なにそれ？」
正直、会話の半分以上が理解できていませんでした。
API？リポジトリ構成？Node.jsのバージョン管理？
聞いたことはあるけど、ちゃんと説明できるレベルではない単語ばかり。
「フォームを作る」ことしか考えていなかった自分に対して、
先輩たちは“別世界”の話をしているような感覚でした。
完全に、会話のスタートラインにすら立てていない状態です。
🔍 なぜ何も考えられなかったのか
理由1：開発の「裏側」を完全にスキップしていた
これまでの業務では、
- 用意されたAPIを叩く
- 用意されたリポジトリにPushする
それだけで仕事が成立していました。
だから私は、「送信ボタンを押したあとに何が起きているのか」を一度も深く考えたことがありませんでした。
データがどこに送られて、どこで処理されて、どうやってSlackに届くのか。
そういった一連の流れはすべて、
「誰かがいい感じにやってくれているもの」
として、完全に思考停止していたんです。
今回初めて、「その“いい感じ”の中身を自分で考えないといけない」状況になり、
何も分からない自分に気づかされました。
🔍 理由2：インフラを“触ったことがあるだけ”だった
AWS自体は、これまでの現場でも触っていました。
ただし実際にやっていたことは、「CloudWatchでログを確認する」、「デプロイされたものの動作をチェックする」
これだけ。
自分の書いたコードがどうやってビルドされるのか、どこにデプロイされているのか、どんな構成で動いているのか。
このあたりはすべてブラックボックスのままでした。
「触ったことがある」と「理解している」は全く別物だったんだと、このとき痛感しました。
🔍 理由3：「開発＝画面を作ること」だと思い込んでいた
そもそも一番の問題はここでした。
私はずっと、「開発＝画面を作ること」
だと思っていました。
でも実際には、
👉 データをどう扱うかを決める
👉 処理の流れを設計する
👉 システム全体を組み立てる
こういった“見えない部分”の方が、はるかに重要でした。フロントエンドは、その一部でしかなかったんです。
3. 1から開発する上で「決めるべきこと」の正体
そんな状態のまま、「とりあえず作ってみます」と言いかけた私に、先輩がこう言いました。
「じゃあ、このシステムどういう構成で作るの？」
ここで初めて、「何をどう組み合わせて作るのか」を考えないといけないことに気づきます。
■ フロントはどこに置くのか
まずはフロントエンド。
Vue.jsで画面を作るのは決まっている。じゃあ、それをどこで公開するのか？
今回は、
👉 S3にファイルを配置（オリジン）
👉 CloudFrontで配信（キャッシュサーバー）
という構成になりました。
これまで「デプロイされたものを使う側」だった自分にとって、
“どこに置いて、どう届けるか”を考えるのは初めての経験でした。
■ APIはどう作るのか
次にぶつかったのが、フロントの“その先”。
「入力された情報、どこに送るの？」
ここで初めて、「APIを自分で用意する必要がある」ことを理解します。
今回の構成は、
👉 Lambda(Python)で処理を書く
👉 API GatewayでHTTP通信できるようにする
👉 エンドポイントを作成して、フロントから叩く
つまり、
「送信ボタンを押す」＝「どこかのURL（エンドポイント）にリクエストを送る」
という当たり前の仕組みすら、このとき初めてちゃんと認識しました。
■ Slackとどう連携するのか
Slack APIを使う必要がある。しかも、アプリ作成にはadmin権限が必要で、権限持ちの人に依頼して環境を作ってもらう必要がある。
「コード書けば終わり」ではなく、
そもそも“使うための準備”が必要な領域があることをここで知りました。
🧩 システム全体の流れ
- フロント（Vue.js）で入力された情報を受け取る
→ タブレットで訪問者が名前などを入力する - API Gateway経由でLambdaにリクエストを送る
→ フロントからURL（エンドポイント）に対してデータを送信する - Lambdaでデータを整形する
→ 受け取った情報を取り出して、Slackに送る形式に整える - Slack APIを使って通知を送る
→ 社内のチャンネルに来客通知が届く
🔐 セキュリティ（追加で考えること）
さらに今回は社内用ツールなので、 誰でもアクセスできる状態はNG
そのため、
WAFを使ってIP制限をかける
社内ネットワーク or VPNからのみアクセス可能にする
といった対応も必要でした。
たったこれだけのシンプルな仕組みのはずなのに、
当時の自分には、すべてがバラバラの要素に見えていました。
4. 今の自分なりの答え
今回の経験を経て、私はこう考えています。
「エンジニアの仕事は、コードを書くこと以上に、データの流れを設計することにある」
以前の「デザイン通りに組めれば正義」という固定観念を捨て、「このデータはどこへ行き、どこで処理され、誰に届くのか」というシステム全体の視点を持つことで、ようやくスタートラインに立てた気がします。
📣 最後に
中編では、実際にCodeCommitのセットアップや、Node.jsの環境構築周りのエピソードをお届けします！
皆さんが初めて「1からプロジェクトを立ち上げた時」の失敗談があれば、ぜひコメントで教えてください！
「自分も最初はそうだったよ！」という励ましもお待ちしております！
🏢 所属会社
日々、Web開発をしながら学んだことを発信しています。
この記事も、実際の業務経験をもとにまとめました！
会社サイトはこちら👇
https://onewedge.co.jp/