🕒 読了目安：約 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/