はじめに
前回の記事では、Web制作からWeb開発へキャリアチェンジし、
「1週目は開発環境の構築と、Gitでブランチを切ったところまで進んだ」と書きました。
あれからさらに3週間が経ち、トータルで1ヶ月が経過し、今はまた少し違った景色が見えてきています。
たとえば、「自分が書いたコードがどのようにレビューされ、どうやって開発環境にデプロイされるのか」。
そうした一連の流れを、実際に手を動かしながら体験できるようになってきました。
今回は、この1ヶ月の実務経験を通して学んだことや感じたことを、振り返ってみたいと思います。
この1ヶ月でやったこと
この1ヶ月は、開発の基本的なプロセスを実務の中でひと通り経験できた期間でした。
最初のタスクから、Vue.jsを使って「テキストの修正」や「CSSの調整」といった作業ではなく、
ロジックを書く仕事に取り組ませてもらいました。
チケットも数枚を並行して担当していて、
「仕事が早くないと、どんどんタスクがたまっていくんだな」ということを実感する日々です。
ただ逆に言えば、早い段階からある程度の量を経験できている分、慣れるのも早くなるはずです。
そういう意味では、本当にありがたい環境だと感じています。
もちろん、コードは最初からうまく書けるわけではないので、
先輩にレビューしてもらいながら、少しずつ改善を重ねているところです。
というより、これまで「レビューを受ける」という経験自体がなかったので、
フィードバックをもらえることそのものが、非常に貴重な学びになっています。
実際に経験した開発フロー
- Gitでブランチを切る
- コードを書く
- プルリクエストを作成し、コードレビューを受ける
- 指摘をもとに修正し、再レビューを依頼
- マージ後、AWS CodePipeline を使ってデプロイ
マージ後は、AWS CodePipeline を使って自動でデプロイされる仕組みになっているのですが、
自分で何か操作をしなくても、マージするだけでデプロイが始まるというのはとても新鮮でした。
それ以外にも、
- AWS CloudWatch でログを調べたり
- テストケースの作成・実行をしたり
といった経験もしました。
どちらもこれまで全く触れたことのない領域だったので、最初は戸惑うことも多かったです。
特にテストに関しては、「そもそも何をどう確認すればいいのか？」というレベルで、完全に手探りの状態でした。
それでも少しずつ、流れや考え方を掴みながら、着実に前進しているという実感があります。
Web開発の全体像を少しずつ整理してみる
この1ヶ月、実務を通して開発に携わる中で、
Web開発の全体像についても、少しずつ解像度が上がってきたと感じています。
最後に、Web制作とWeb開発で求められるシステム構成やアーキテクチャの考え方の違いについて、自分なりに整理し、このブログを締めくくりたいと思います。
Web制作でよくある構成
まずは Web制作の構成について振り返ります。
Web制作の現場では、アプリケーションや静的ページのすべての機能が
1つのサーバー内で動作する構成が一般的です。
調べたところ、このような構成は「モノリス構成」と呼ばれるそうです。
たとえば以下のような機能が、すべて1つのソースコードに含まれている状態です：
- ログイン機能
- 商品管理
- カート機能
- 注文処理 など
この構成は小規模なサイトや、WordPressのようなCMSにとても適しており、実際に私自身もWeb制作をしていた頃は、WordPress や phpMyAdmin などを日常的に使っていました。
典型的なディレクトリ構成の例：
/home/username/public_html/
├── index.php
├── contact.php
├── assets/
│ └── style.css
└── db（MySQLなど）当時は、データベースから情報を取得し、それをPHPでHTMLとして描画するという構成が基本でした。
このような背景からも、モノリス構成はシンプルで扱いやすく、小〜中規模のWebサイトに最適だと実感しています。
Web開発での主流：マイクロサービスアーキテクチャ
現在のWeb開発では、「マイクロサービスアーキテクチャ」が主流だと言われています。
私はまだ業界歴1ヶ月で学習中の身ですが、調べたり実務を通して少しずつ理解が深まってきました。
マイクロサービスとは、アプリケーションの機能を細かく分割し、それぞれを独立したサービスとして構築するアーキテクチャのことを指します。
たとえば、以下のような構成が考えられます：
- 認証API
- 商品API
- 通知API
- ユーザー管理API など
マイクロサービス構成のイメージ：
/frontend/（VueやReactで構築）
└── fetch → 各API
/api/（機能ごとに分割されたバックエンドAPI）
├── auth-service/ ← 認証
├── product-service/ ← 商品データ
├── notification-service/ ← 通知処理
└── user-service/ ← ユーザー管理
/db/（各サービス専用のDB）
├── auth-db
├── product-db
├── notification-db
└── user-dbこのように、各サービスが独立して開発・デプロイ・スケーリングできるのが、マイクロサービスの大きな特徴です。
一部の機能を変更しても、他の機能に影響が出にくいという点が、マイクロサービスの強みだと感じました。
また、こうした複数のAPIからデータを取得し、それを画面に反映させる役割を担うのが、VueやReactといったフロントエンドフレームワークです。
かつては、PHPがデータ取得からHTMLの描画までを一手に担っていた時代もありましたが、
現在のWeb開発では、フロントエンドが自らAPIを叩いてデータを取得し、画面を描画するというスタイルへと移行しているようです。
BFF（Backend For Frontend）とは？
マイクロサービス化が進むと、フロントエンドが複数のAPIを直接叩く必要が出てくるようになります。
その結果、通信処理が煩雑になり、コードの複雑化や保守性の低下といった課題が生じやすくなるようです。
私自身はまだこのあたりの実務経験はありませんが、調べてみるとこうした背景があるからこそ、
「BFF（Backend For Frontend）」という仕組みが登場したとのことでした。
BFFは、フロントエンドとバックエンドAPIの間に立ち、必要なデータをまとめて取得し、整形して返す役割を担います。
具体的な流れ：
【Vue】
↓ fetch（1回）
【BFF】
↓（裏側で3つのAPI呼び出し）
・認証API
・商品API
・通知API
↓
【BFFが統合したJSONをVueへ返却】このようにBFFを挟むことで、フロント側のコードがシンプルになり、
開発効率や保守性が大きく向上するというメリットがあります。
この1ヶ月の実務を通して、こうした構成の考え方や仕組みを少しずつ理解できるようになってきました。
もちろんまだまだ分からないことは多いですが、「全体像が見えてきた」という感覚が持てるようになったことは、今後の学びにもつながる大きな一歩だと感じています。
最後に
まだ業界に入って1ヶ月。右も左も分からない状態からのスタートでしたが、
実務を通して「Web開発とはどういう世界なのか」を少しずつ実感できるようになってきました。
日々の業務の中で感じたことは、「知っている」と「やってみた」は全く違うということ。
技術的にも、構成的にも、Web制作とWeb開発の違いを肌で感じながら、
まだ断片的ではあるものの、少しずつ全体像を掴めるようになってきた気がします。
これからも目の前の業務に丁寧に取り組みながら、
自分自身の「できること」を少しずつ広げていけたらと思います。
最後まで読んでいただき、ありがとうございました！