はじめに
本記事では新卒プログラマーとして現場に配属されてから、初めてフルスタック開発に挑戦した際の経験を振り返ります。
Vue3、FastAPI、PostgreSQLを使って、Webアプリケーションを一から構築した過程で
得られた学びや、苦労とその乗り越え方を中心にまとめました。
具体的には製造～テストまでの工程を担当しました。
これから同様の技術に触れる新卒エンジニアの方々にとって、少しでも参考になれば幸いです。
自己紹介
はじめまして!セカンドセレクションへ2025年4月に新卒入社した坂口と申します。
学生時代は生成AIに注力しておりハッカソンなどのモノづくりイベントに参加していました。
今回の記事ではAIについて書いていませんが、今後機会があれば書きたいと考えています。
🧑想定読者
- 2025年入社で研修を終えて、実務に入りたての新卒プログラマー
- Vue.jsやFastAPIなど、これからフルスタック技術に触れる人
2025年入社の方は研修を経て、いよいよ現場に入り始めた時期かと思われます。
新人の時期は覚えることが山積みで、不安や戸惑いがあります。
本記事が、同じ立場の方のヒントになればと考えています。
システム構成
実際に作ったアプリの詳細はまだ公開できませんが、以下のような機能を含んだWebシステムを
1ヶ月で構築しました。
- Vue3 + Vue RouterによるSPA
- FastAPI + PostgreSQLによるAPI連携とCRUD操作
- 全体は3画面構成で、「追加・表示・編集」が可能な2画面と、処理結果を表示するための1画面で構成
SPA（Single Page Application）とは
ページ遷移時に毎回HTMLをサーバーから取得するのではなく、最初にHTMLを読み込みます。
後はJavaScriptでページを動的に切り替える仕組みです。
操作体験の向上やページ間の遷移が高速といったメリットがあります。
採用技術の紹介
FastAPI
Python製のWeb APIフレームワークです。型ヒントによるバリデーションやSwaggerによる
ドキュメント生成が特徴です。
シンプルで簡単にエンドポイントが作成できます。
# エンドポイントの例
@app.get("/test")
def test():
return "test"
参考にした以下の書籍はとても分かりやすかったです。
Vue3
JavaScriptのフレームワークで、「コンポーネント」という部品単位でUIを構築できるのが特徴です。ヘッダーやフッターといった部品ごとに開発ができ、再利用性が高いです。
また、Vue Routerを使ったSPAに対応しておりページ全体を再読み込みせずに必要な部分だけを
動的に描画できます。
上図のように、各UI要素を部品として管理します。例えば画面遷移時にヘッダーやフッターを
固定表示しメインコンテンツ部分のみを更新することで、高速な描画が実現されます
（仕組みは後述）。
PostgreSQL
データベースとしてPostgreSQLを使用しました。
Pythonからの操作には、SQLAlchemyを利用しました。
今回は先輩に環境構築をしていただいたため、次は自分で構築に挑戦していきたいです。
振り返り
Web開発やソース管理、チーム内コミュニケーションまで、幅広く学びのある1ヶ月でした。
ここでは学んだこと・苦労したことを、まずは表形式で整理します。
| ジャンル | 主な内容 |
|---|---|
| Web技術の基礎理解 | SSR / CSR、Vue.js、FastAPI |
| 開発ツール・プロセス | Git、SwaggerUI、テスト（pytest,TestClient） |
| コーディングの基本 | 命名、可読性、設計 |
| 働き方・学び方の姿勢 | 質問する力、AI活用、情報整理 |
| つまずきと対応力 | 情報過多、混乱、考える力 |
それでは詳細を見ていきましょう。
📝学んだこと
1.レンダリングの違い
サーバーサイドレンダリング(SSR)
サーバー側でHTMLを生成し、ブラウザに送信するレンダリング方式です。
CSRに比べて初期表示は高速ですが、ページ遷移のたびに毎回HTML全体をサーバーから取り直す必要があります。
そのため遷移はCSRに比べて遅くなりやすく、画面遷移時に一瞬画面が真っ白になるなどUX上の課題もあります。
クライアントサイドレンダリング(CSR)
ブラウザ側でWebページのレンダリングを行います。
初回アクセス時には、サーバーからは最小限のHTMLとJavaScriptファイルが返されます。
ブラウザがJavaScriptを実行して必要なデータをAPI経由で取得し、HTMLを動的に生成・描画
します。
シングルページアプリケーション（SPA）
CSRを用いたWebアプリの構成手法のひとつです。
ページ遷移時にサーバーへリクエストを行わずに、JavaScriptでコンポーネントを切り替えることで表示を更新します。そのため、高速なページ遷移が可能です。
| 観点 | CSR(SPAの場合) | SSR |
|---|---|---|
| HTMLの生成場所 | ブラウザ側のJavaScriptによる動的生成 | サーバー側でリクエストごとにHTMLを生成 |
| 初期表示速度 | アプリ全体のJavaScriptを取得・実行するため遅くなりがち | サーバーからHTMLが直接返るため速い |
| ページ遷移時の挙動 | 画面構成(ソース)は取得済みのため再度のHTML取得が不要。必要なデータのみをAPI経由で取得し描画するため速い | 各ページ遷移時にHTMLを再生成・再取得する必要があるため遅い |
2.FastAPIのSwaggerUI
FastAPIには、API仕様を自動でドキュメント化するSwagger UIの機能があります。
この機能を利用することでどのAPIを叩くと、どんなレスポンスが返されるのかが一目で分かり、開発の効率化に繋がります。
ドキュメントはdocsとredocの2種類が生成されます。
- Docs
APIを実行することが出来て便利
- Redoc
読みやすい
3.テストケースの作成
今回FastAPIのTestClientを用いて自動テストを作成したのですが、テスト手法や観点が複数あり戸惑いました。
以前、テストは正常系、異常系を網羅するべきだと考えており、作成に時間がかかりました。
学んだのは以下の3点です。
・ユニットテスト
・結合テスト
・正常系／異常系の判定
「何を、どこまで、どのような観点でテストするか」はテスト前に考慮する必要があると学びました。
4.Gitを利用したチーム開発
GitLabを用いたコード管理を通じて、Gitの利便性を実感しました。
機能ごとにブランチを分けて開発することや、コードの差分が見られることで効率的に
開発がすすめられます。
また、レビュー依頼をする際には、以下2点を徹底する必要があると学びました。
- コミット前のセルフチェック
- レビュー依頼前の2重チェック
レビューは他人の時間を使う行為であるため、特に慎重になる必要があります。
5.聞くことの重要性
私は1時間試行錯誤して分からない場合は周りの人に聞くことを心掛けていました。
熱中するあまり聞く時間が無くなったということもありました😅
皆さんの周りには知の巨人がいます。自分では数時間かかるものが、質問しておけば
数分で終わるということもあります。
効率の面でも周囲に頼るという選択肢は常に持っておくべきだと学びました。
🧠苦労したことと乗り越え方
1.Vue2とVue3の記法の違い
Vue.jsにはOptions API(Vue2)とComposition API（Vue3）があり、記法が異なるため最初は
混乱しました。
Vue2（Options API）
<script>
export default {
data() {
return {
count: 0
}
},
methods: {
increment() {
this.count++
}
}
}
</script>
Vue3(Composition API)
<script setup>
import { ref } from 'vue'
const count = ref(0)
function increment() {
count.value++
}
</script>
上記のように書き方が複数存在し、どちらでも動くケースが多いため、情報が散在していて混乱しました。
ですが基本的にはVue3のComposition APIを利用するよう割り切って、迷いを減らしました。
採用した主な理由は以下の2点です。
-
<script setup>を使えばdataやmethodsに分けて記述する必要がなく、1つのスコープで
完結するため構造がシンプルで見易い。 - 変数定義や関数の書き方がPythonに似ていて親しみやすかった。
2.命名の難しさ
コードを書いていくうえで名前をどう付けるかは避けられない問題でした。
私が可読性を実感した例を挙げます。
# 悪い例
employee = ["田中太郎", 30, "エンジニア"]
print(f"{employee[0]}（{employee[2]}）は在籍中です。")
😟レビュア：従業員の要素0と要素2が出力されるのかな？
悪い例では自身が書いている時は理解しやすいですが、日数がたつと読みにくくなります。
他人が読んだ時には更に読みにくいです。
# 良い例
employee = {
"name": "田中太郎",
"age": 30,
"position": "エンジニア",
"active": True
}
print(f"{employee['name']}（{employee['position']}）は在籍中です。")
😎レビュア：従業員の名前と職種が出力されるのだな
良い例では文章を読んでいる感覚で理解が出来ます。
私はコードからどんな処理がされるのか理解できるようになると可読性が高いと考えます。
コードを評価する際に、自分が書いたコードを他人の目線で見るというテクニックもあると
学びました。また最も成長につながったのは、先輩からレビューを受けることでした。
Pythonのコーディング規約を参考に記述するのが練習になると考えられます。
3.何が分からないのか分からない
最初は新しい概念や用語が多く、頭がパンクしそうになりました。
また、そもそも「何が分かっていないのかが分からない」状態に陥ることもありました。
私は特にVue.jsに苦手意識を持っていたのですが、1行ずつ読むと理解できたことがありました。
その他にも以下の工夫で乗り越えました。
- 分からない用語は単語帳を作って検索する
- 苦手意識を持たずに、まずは手を動かす
- 処理のINとOUTを意識する
分からないで思考停止してしまうと、それより前に進むことが出来なくなってしまいます。
1行ずつ処理を追うことで、どんな入力がされてどんな出力がされるのかを、把握できました。
全ての関数は「入力→何らかの処理→出力」の3ステップだと考えると気が楽になります。
4.生成AIのバランス
ChatGPTを使って開発を進める中で、生成AIに依存しすぎるリスクを感じました。
今は理解していなくても動くものが作れてしまう時代です。
開発中に感じた課題は以下の2点です。
- 問題を考える前に頼ってしまうと「自力で考える力」が育たない
- 理解していなくても動くコードができてしまう
大半の新卒プログラマーに求められていることは、実装力はもちろん、成長だと考えます。
生成AIを利用することで頼り癖がついてしまい、自分で考える前に生成AIを頼ってしまう事態が発生します。
そうすると自身で考えるという成長機会が失われてしまいますので、まずは自分の頭で考えて、効率化ができる箇所は生成AIに頼る意識で開発を進めました。
🙇♂️おわりに
実務に入って1ヶ月程度ですが、とても多くの学びがありました。システム開発といっても
プログラミングだけでなく、設計やテスト、コミュニケーションなど幅広い知識とスキルが
必要だと実感しています。
学ぶほど未熟さを自覚しますが、その分深めがいがある仕事だと考えます。
また今回のように振り返りを行うことで、知識がどれだけ定着しているのかを自覚できるので、今後も続けたいと考えています。
皆さんも一度振り返りの時間を設けても良いのではないでしょうか。
今後も目の前の課題に向き合いながら、自分のやり方や考え方を構築できるように
努めていきます！
Discussion