あなたが想像する「AWSでの開発」は、どんな仕事でしょうか？
この記事では、AWSのSIerだからこそ実現できる、コード実装からインフラ構築までを含めた「モノづくり」の実態を、現場のリアルな視点からご紹介します。
はじめに
入社4年目エンジニアの垣見です。
最近、入社したばかりの新卒1年目のメンバーとお話ししていると、「開発に興味があります！ 先輩の部門について教えてください！」と熱意をもって質問されることがあります。
新卒の皆さんは優秀な方ばかりで、ニコニコが止まりません。早く一緒に仕事がしたいですね。
ところで私は、『開発』という言葉はズレが生まれやすいと思っています。
文系未経験出身だった私は「いろいろなものを作りたい」と入社しました。開発といえば「Webサイトのきれいな画面（フロントエンド）を作ったり、プログラミングコードをひたすら書いたりすること」だと考えており、それ以外の仕事をあまり想像できていませんでした。同じようなイメージを持つ方は多いのではないでしょうか。
しかし、AWS専業のクラウドインテグレーター（SIerのクラウド版）であるサーバーワークスにおける「開発」は、実はもっと広いです。
今回は、就活生の皆さんやAWS未経験の皆さんに向け、「サーバーワークスにおける『AWSで開発』って、結局どんな仕事？」という疑問を、現場のリアルな実態をもとに解説したいと思います。
本記事ではできるだけ初心者向けにAWS関連の用語説明を入れるように心がけていますが、それでも理解が難しかったり、またIT関連やビジネス用語でわからないものがあったりするかもしれません。
もし記事のなかで「この言葉、どういう意味だろう？」と思うワードが出てきたら、ぜひ検索したり、生成AI（ChatGPTやClaudeなど）に「〇〇についてIT初心者にわかるように3行で教えて！」と聞いてみたりしてください！
ITの世界は新しい言葉がどんどん生まれるので、「わからないことはAIや検索をフル活用して調べる」というのはとても重要なスキルだなあと、私も日々実感しています。
ちなみに、AWSやクラウドとは何か？については説明しません。「そもそもIT業界の構造やクラウドって何？」という基礎から知りたい方は、こちらのブログもぜひ読んでみてください。
sabawaku.serverworks.co.jp【最初にまとめ】「開発」比較表
この記事の後半で解説する6つの開発領域を、技術的な特徴や関わるビジネスの軸で1つの表にまとめてみました。
ぜひ、後から見返すのにもご利用ください！
| 種別 | キーワード | 最終成果物例 | エンドユーザー | 一般的な職種名 |
|---|---|---|---|---|
| ① フロントエンド | UI/UX, デザイン | 自社サービスの画面 | 社外ユーザー | Webエンジニア |
| ② バックエンド | サーバーレス, ロジック | 自動化プログラム | 社内・業務担当者 | バックエンドエンジニア |
| ③ インフラ構築 | クラウド基盤, IaC, ネットワーク, サーバー, データベース | ネットワーク+サーバー基盤 | サービス利用者 | インフラエンジニア(ネットワークエンジニア・サーバーエンジニア) |
| ④ ガバナンス統制 | セキュリティ, コスト, Organizations | 全社統制の仕組み | 全社員 | クラウドアーキテクト |
| ⑤ データ分析 | BIツール, データ基盤 | ダッシュボード | 経営層・マーケティング担当 | データエンジニア |
| ⑥ Amazon Connect | コールセンター基盤 | 通話分岐フロー | オペレーター | クラウドコンタクトセンターエンジニア |
まずはこの比較表を全体像として頭の片隅に置いていただき、ここから各スタイルのリアルな実態を詳しく解説していきます。
イメージがずれやすいポイント
サーバーワークスの「開発」を知る上で、まずはこのブログ内での「開発」の定義や、勘違いしやすいポイントを明らかにしましょう。
1. 【前提】システムの基本「3層構造」
「開発」の領域・用語を理解するために、前提としてシステムがどう構成されているかをご紹介します。
一般的なシステムは、役割ごとに大きく3つの層（フロントエンド・バックエンド・インフラ）に分かれています。
- フロントエンド（画面・顔）：
Webブラウザやスマホアプリなど、ユーザーが直接見て操作する「画面」を作ります。HTML/CSSやJavaScriptなどでボタンの配置や見た目を整えます。 - バックエンド（裏側の処理・脳みそ）：
ユーザーが入力したデータを計算したり、データベースに保存・検索したりする「裏側の仕組み（ビジネスロジック）」を作ります。ユーザーからは見えませんが、システムの中核を担う重要なプログラムです。 - インフラ（土台・箱）：
サーバー（コンピュータそのもの）やネットワーク、データベースなど、上の2つ（アプリケーション）が動くための「環境・土台」を作ります。
弊社の扱うAWSでは、インフラ（ネットワーク）を構築するためのサービスも、バックエンド処理のためのサービスも、フロントエンドのためのサービスも同居しています。
例えば、「インフラとしてAmazon VPC（ネットワークのAWSサービス）やその一機能のSubnetを作り、その上にAmazon EC2（仮想サーバーのAWSサービス）とAmazon RDS（データベースのAWSサービス）を1台ずつ構築してつなぎ合わせ、そのサーバー上にフロントエンド画面・バックエンドのビジネスロジックを作りこむ」というようなこともできます。
VPCやsubnetと書かれた枠は、自分専用に区切られた安全なネットワークのエリアを示します。
その中にあるEC2とRDSは、それぞれ独立したコンピューターです。
「EC2」というコンピューターの上で作り込んだプログラム（画面や仕組み）を動かし、大切なデータは「RDS」というデータベースのコンピューターに保存して、お互いに連携させて動かします。
2. 「開発」の定義
私は以前「モノづくり＝開発」と捉えていたのですが、これは正確ではありません。
IT業界において「開発（Development）」という言葉は、文脈によって指す範囲が大きく異なります。大きく分けて以下の2つの視点を混同しないことが、キャリアを考える上で重要です。
① 広い意味の「開発」
システム工学やプロジェクト管理の視点での「開発」は、要件定義からリリースまで、システムを作り上げる「プロジェクト全体」を指します。
この視点では、プログラミング（コードを書くこと）は、開発のライフサイクル（要件定義 ➔ 設計 ➔ 実装 ➔ テスト ➔ リリース）の「実装」と呼ばれる工程の一部に過ぎません。
たとえば、「小売系のシステムの開発案件にアサインされました」のように言ったりします。
- 開発（Development）：要件定義から運用まで、プロジェクトのライフサイクル全体。
- 実装（Implementation）：その中の「コードを書く作業」のこと。
- 構築（Construction）：サーバーやネットワークなど、システムが動くインフラを作る作業。
開発（デベロップメント）とは - IT用語辞典 e-Words
② 狭い意味の「開発」
一方で、個人のスキルセットや職種の話になると、「コードを書いてアプリケーションの機能を作る」という特定の作業や役割を指すことが一般的です。
かつては「アプリケーションエンジニア」と「インフラエンジニア」で、役割も仕事内容もはっきり分かれていました。
- アプリケーションエンジニア（狭義の「開発エンジニア」）：
- 役割： プログラミングをメインで行う人。
- 業務： ユーザーが操作する「機能」や、裏側の「ビジネスロジック」そのものを作る。主にフロントエンド、バックエンド領域を指す。
- インフラエンジニア：
- 役割： サーバーやネットワークの環境構築をメインで行う人。
- 業務： アプリケーションが安全・快適に動くための「土台（サーバーやネットワーク）」を作る。）
ただし、私個人がAWSを使う現場で働いていて感じるのは、『「アプリケーションエンジニア（特にバックエンド領域）」と「インフラエンジニア」が、同じエンジニアのスキルセットの中で溶け合っている・境界が曖昧になっている』という印象です。
AWSは、インフラを構築するためのサービスもアプリケーションを動かすためのサービス※も、どちらも提供しています。
まとめてシステム開発をしてしまうことが比較的容易なため（むしろ、それらの領域を理解する必要が出てきたとも言えますが）、AWSエンジニアはどちらにも造詣が深くなりやすい……と言えるかもしれません。
実際、サーバーワークスのプロジェクトでは、インフラ構築とバックエンドの実装を同じエンジニアが横断的に担当することも珍しくありません。
そもそもクラウドは、「物理的なサーバーの所有から解放され、必要なリソースを必要な分だけ（超重要）利用する」という考え方が基本です。
そのため、エンジニアがデータセンターへ出向いて物理サーバーに触れるようなことはほとんどなく、WebコンソールやCLI（コマンドラインインターフェース）を介した設定や操作が中心となります。
さらに、IaC（Infrastructure as Code）といって、一般的なプログラミング言語や専用の言語を使って、インフラ環境構築をコード化する手法が一般的になっているのも、境界が曖昧になってきた一因かと思います。
結論として、AWSエンジニアにとって「インフラ」と「アプリケーション」は完全に分断されたものではなく、お互いの領域を理解し合いながら、より密に連携してモノづくり（システム開発）を行う時代になっています。
※折りたたみ：AWSに色んな領域のサービスがあるという説明です
本ブログでの扱い方について
未経験の方は、「モノづくりが好き」「何か役立つものを作りたい」のような軸で、使う技術をあまり意識しない方も多いかと思います。
だからこそ、本記事では【モノづくり=広義の「開発」】に関わるサーバーワークスにおける仕事について、インフラ領域も含めて改めて整理します。
フロントエンド・バックエンド・インフラは専門領域としては異なりますが、弊社では、どれも「システムという一つのものを作り上げる不可欠な要素」として、責任をもって業務を行っています。
3. 「誰が使うシステムか？」の違い
皆さんが想像するシステムは、スマホアプリやウェブサイトのような、一般の消費者向け（BtoC）のものが多いかもしれません。
しかし、私たちが作るのはお客様企業の「社内の人」が使うためのシステム（BtoB, もしくはBusiness to EmployeeでBtoEということもある）や、工場のシステムなどビジネスの基盤となるものも多いです。「大量のアクセスを捌けるか」「絶対に止まらないか」「社内業務がどれだけ楽になるか」が問われます。
案件によって、技術的な要素（インフラ構築の有無やコーディング量）が変わるだけでなく、私たちが向き合うお客様（一緒にプロジェクトを進める部門）や、実際にシステムを使うエンドユーザーもガラッと変わります。
開発を進める上でお客様との対話は必須ですが、「どんな視点を持ったお客様なのか」によって、気にすべきポイントが変わってくるのが面白いところです。
これらを踏まえて、サーバーワークスで実際に行われている職種・技術領域を見ていきましょう！
サーバーワークスが手掛ける「開発」
では、具体的にどんなことをしているのか？ 分野別にご紹介します。
扱う技術なども記載するので、もし興味があれば、そのワードを調べてみてください！
【基本編】システムを構成する3領域の開発
まずは、先ほど紹介した「3層構造（フロントエンド・バックエンド・インフラ）」それぞれの中心となる開発領域について見ていきましょう。
① 目に見える画面を作る「フロントエンド開発」
ユーザーが直接操作する、Webサイトのきれいな画面（UI）を作ります。
一番フロントエンド開発を多く手掛けているのは、自社サービス開発部門です。
代表例として、AWSの運用を自動化する「Cloud Automator」や、お客様向けの「マイスターズポータル（請求代行用のマイページ）」などを提供しています。
※弊社においては、「お客様から依頼をもらって行う開発」としてフロントエンドを扱っている案件は少ないです。
- 扱う技術・特徴：
TypeScriptなどのフロントエンド技術を中心に扱います。場合によっては、「それがAWS上で動く」というインフラ部分を意識しないこともあります。 - コーディング以外の重要な要素：
作って終わりではなく、「ユーザーがどう使っているか」のフィードバックを収集し、次にどの機能を開発するかの優先順位付け（ロードマップ策定）を行います。UI/UXを考慮する視点も欠かせません。 - こんな人に向いている！：
「ユーザーの反応をダイレクトに見ながら画面（UI）を改善したい」「目で見えるプロダクトをデザインしたい」というプロダクト・デザイナー志向の人。
実際の事例
Cloud AutomatorはAWSの運用を簡単にするノーコード自動化システム（SaaSサービス）です。2014年リリースのサービスですが、2026年現在もAWSのアップデートやユーザーのご要望に合わせて進化を続けています。
例：プレスリリース
② データの処理や連携を担う「バックエンド開発」
システムの中核となる、裏側の計算処理やデータベース操作のロジックを作ります。
例えば、「ユーザーがWebサイトから問い合わせをした瞬間に、自動で担当者のチャットツールへ通知を飛ばし、同時にデータベースへ内容を記録する」といった仕組みが該当します。
主観ですが、弊社でバックエンド構築を担当する場合、サーバーレスサービスを採用することが多い印象です。
※折りたたみ：サーバーレスについて
AWS環境における最近のバックエンド開発では、「サーバーレス」と呼ばれるモダンなアーキテクチャを採用することが増えています。
「サーバーレス」とは、その名の通り「（昔ながらの方法と比べて）サーバーの存在をあまり意識することなくコードを実行できる」という概念です。
AWSサービスをパズルのように組み合わせるサーバーレス開発については、以前詳しく解説したブログも参考にしてみてください。
サーバーレスとは？
【ハンズオン後編】初心者がAmazon Q Devと1から進めるサーバレスApp開発（バックエンド編） - サーバーワークスエンジニアブログ
また最近では、システムの中に生成AI（Amazon Bedrockなど）を組み込む案件が急増しています。そのため、期待通りの回答を引き出すための「プロンプトエンジニアリング（プロンプト調整）」や出力結果の精度検証といった新しいスキルも、これらの開発現場で求められるようになっています。
画像引用元：【初心者向け】Amazon Bedrock + Lambda でのシンプルなQAシステム
- 扱う技術・特徴：
言語はPython・TypeScript、AWS技術としてはAWS LambdaやAmazon EventBridge、AWS Step Functionsなどをよく使います。サーバーレスの場合、特にイベント駆動型（何かが起きたら処理を実行する）のコードを書くことが多い気がします。「この部分はサーバーレスで軽く動かし、この部分には大きなサーバーを置く」といったように、適材適所で使い分けるアーキテクチャ設計も行います。 - コーディング以外の重要な要素：
「そもそもこの業務、なぜこんなに時間がかかっているの？」という現場の課題の深掘りが必要です。 - こんな人に向いている！：
「現場の困りごとを、パズルのように技術でサクッと解決するのが好き」「とにかくいろいろな種類のシステムを作りたい」という人。
実際の事例
株式会社東日本計算センター様では、生成AIサービスにAmazon Bedrockを採用し、セキュアでスピーディーなシステム構築を実現しました。
導入事例：株式会社東日本計算センター様
③ システムの強固な土台を作る「インフラ構築」
システムが安全かつ快適に動くための、ネットワークやサーバーといった環境の土台を作ります。
「ここにネットワークを作る」「こういう設定のサーバーを置く」「このセキュリティサービスも導入する」といった、細かなパラメータ設定がシステムの安全性やパフォーマンスを大きく左右します。
サーバーの上に乗るフロントエンド・バックエンド（アプリケーション側）の開発は行わないことが多く、他のベンダー企業やお客様のアプリケーション開発部門と協力して進めます。
画像引用元：Amazon EC2インスタンスの起動・停止手順 - サーバーワークスエンジニアブログ
また、大規模なシステムや同じ構成を何度も作る場合は、先述のIaC（Infrastructure as Code）という技術も活用します。
以下のブログでは、「既存EC2の設定をコピーするためのPythonコード」を利用して、YAML形式のCloudFormationテンプレート（AWSでのIaCのためのサービス「AWS CloudFormation」で使うファイル）を自動生成しています。
- 扱う技術・特徴：
AWSの各種インフラサービス（Amazon EC2、Amazon VPC、Amazon RDSなど）の深い知識。ネットワーク領域の場合、IPアドレス設計や不正アクセスを防ぐ構成、ドメインなどの知識も使います。また、TerraformやAWS CloudFormationなどのIaCツール、AWSサービスの構築からテスト、デプロイメントまでのプロセスを自動化（CI/CD）する技術も扱います。 - コーディング以外の重要な要素：
ただ動くものを作るのではなく、AWSのベストプラクティス（Well-Architected）に沿ったセキュアで可用性の高いアーキテクチャ設計が必要です。「将来データが増えたらどうするか？」といった未来予測の視点や、無数にある設定項目から最適なパラメータを見極める力が求められます。 - こんな人に向いている！：
「絶対に落ちない頑丈な基盤を作りたい」「パラメータ設定を突き詰めて最適な環境を作るのが好き」「お客様によって違う要件を反映し、ネットワークやサーバーのプロと呼ばれたい」という職人気質の人。
実際の事例
株式会社琉球銀行様における、カードアクワイアリングシステムの構築事例です。コンサルティングやアプリケーション開発など複数のベンダーと協力し、弊社はインフラ領域の開発（要件定義や設計、実装）に加えて、運用の設計や運用後の監視まで担当しています。
導入事例：株式会社琉球銀行様
【応用・特化編】特定の課題を解決する3つの特殊領域
ここから紹介する3つは、これまで説明した「インフラ・バックエンド・フロントエンド」の技術要素を組み合わせたものですが、解決するビジネス課題や扱う専門技術が少し特殊な領域です。
※あくまで筆者が説明のために分類した基準です
④ CCoE支援！組織のルールを自動化する「ガバナンス統制の開発」
企業全体でクラウドを安全に活用するための、セキュリティルールや自動化の仕組みを作ります。
大企業を中心に、情報システム部門やCCoE（Cloud Center of Excellence。社内のクラウド推進組織のこと）など、社内のAWS活用をリードするチームの支援を行う中で発生する仕事です。例えば、社員がセキュリティ事故を起こさないためのガードレール（安全装置）をシステムとして組み込むなどがあります。
我々のお客様はAWSを使ってBtoCシステムや社内システムをたくさん作っており、その内容によって環境（アカウント）を分けていることがほとんどです（マルチアカウント）。それぞれの個別システムを作るのではなく、その複数アカウント全体を統制したり、セキュリティやコストの改善を全社レベルで行ったりするのが特徴です。
以下はマルチアカウントの構造例です。未経験の方にはイメージが難しいかもしれませんが、もし気になる部分があったら、引用元ブログ内容を生成AIにかみ砕いてもらうなどしてみてください。
- 扱う技術・特徴：
AWS Organizations、AWS Configなどの統制やセキュリティのサービス。また、コスト最適化を狙う「AWS Savings Plans」などの仕組み。開発の実態としては、一般的なプログラミング言語で書くというよりは、JSON形式のポリシー定義や、違反を検知した際の自動修復スクリプト（主にサーバレスバックエンド構成）、また組織全体に統制システムを配布するためのIaCのスクリプトなどをよく扱う印象です。 - コーディング以外の重要な要素：
お客様企業の「社内ルールやセキュリティポリシー」を深くヒアリングし、それをAWSのシステム上の制約（ポリシー）に翻訳する力が必要です。時には他部署との調整や交渉のサポートを行ったり、組織のルール自体にアドバイスしたりするなど、コンサルティング的な要素が入ってくることもあります。 - こんな人に向いている！：
「ひとつのシステムだけでなく、企業全体のシステム統制というスケールの大きな課題に取り組みたい」「お客様の環境をベストプラクティスに近づける、ITコンサルティングのような動きがしたい」という人。
実際の事例
東宝株式会社様における、AWS Organizationsを活用した統合管理基盤の構築事例です。セキュリティとガバナンスを強力に補佐する仕組みを作りました。
導入事例：東宝株式会社様
⑤ 埋もれた情報を価値に変える「データ分析基盤開発」
膨大なデータを使える形に変える分析基盤や、経営や現場がビジネスの状況を一目で把握できる可視化ダッシュボードを作ります。
企業に溜まった膨大なデータをビジネスに活かすための開発です。
BIダッシュボードのイメージ：
引用元：Salesforceの商談データをAmazon Quickでダッシュボード化＆自然言語Q&Aまでやってみた - サーバーワークスエンジニアブログ
ダッシュボード化まではいかなくても、「データをいつでも検索できるように収集・整形したい」というようなご要望も多いです。
特に生成AI全盛期の今は、AIが読み込むためのデータとして、より需要が高まっている印象を受けます。
- 扱う技術・特徴：
Amazon Quick（BIツール）や、データを整えたり検索したりするためのAWS Glue、Amazon AthenaなどのAWSサービス。言語としてはSQLなど。データクレンジング（データのゴミを取り除く処理）の知見も求められます。データ加工のためにPythonを使ったり、集めたデータをダッシュボードとは別にAIに活用させたりすることもよくあります。お客様の持つ、AWS以外のデータ基盤とのつなぎこみを実施する場合もあります。 - コーディング以外の重要な要素：
「経営陣はどの数字（KPI）を見たいのか？」というビジネス指標のヒアリングが最重要です。また、見やすく直感的な画面を作るためのダッシュボードのデザイン力も問われます。 - こんな人に向いている！：
「データを分析してビジネスの意思決定を助けたい」「複雑な情報を整理して、わかりやすく見せる（可視化する）のが得意」という人。
実際の事例
株式会社アデランス様において、Amazon Quick（旧 Amazon QuickSight）で新たなBI環境を構築した事例です。データドリブンな経営を支えるダッシュボードを開発しました。
導入事例：株式会社アデランス様
⑥ コミュニケーションをデザインする「Amazon Connect 開発」
電話の応答フローやオペレーターへの接続ルートなど、クラウド型のコンタクトセンター（コールセンター）の仕組みを作ります。
「電話がかかってきたら、どういう分岐で、誰に繋ぐか」という仕組みを設計・構築します。
Amazon Connectとは？： blog.serverworks.co.jp
設計のイメージ： blog.serverworks.co.jp
弊社ではこちら専門の課があり、AWSの「Amazon Connect」という特有のサービスを必ず使うので、この領域に非常に詳しいスペシャリストになれます。
フロー作成画面のイメージ：
引用元：Amazon Connectのフロー挙動に関する検証結果 - サーバーワークスエンジニアブログ
実際にはほかのAWSサービスと連携することが多いため、先述した②のバックエンド開発の技術もフルに活用する奥が深い領域です。
- 扱う技術・特徴：
Amazon Connectのビジュアルビルダーを使ったフロー構築がメイン。CRM（Salesforceなど）との連携や、自動応答のためにAWS Lambdaでコードを書くこともあります。 - コーディング以外の重要な要素：
電話をかけてくるお客様と、電話を受けるオペレーター、双方の業務フロー（行動の導線）を整理・設計する力が必要です。音声ガイダンスのスクリプト（台本）作成など、人間心理に寄り添う部分も大きいです。 - こんな人に向いている！：
「プログラミング言語にこだわりすぎず、業務の仕組みそのものをデザインしたい」「自分が作ったシステムが、人のコミュニケーションをどう改善したか実感したい」という人。
実際の事例
株式会社ヤオコー様では、Amazon Connectと生成AIを組み合わせることで、受電後の処理時間を9分から2分へと大幅に短縮する仕組みを構築しました。生成AIによる文字起こし・要約機能も組み合わせています。
導入事例：株式会社ヤオコー様
【番外編】社内システムを育てる「SaaSカスタマイズ・社内ツール開発」
ここまでお客様向けのAWS開発を中心にご紹介してきましたが、実は自社内で利用するシステム（Questetraなど）をカスタマイズ・連携する部門もあります。
AWSが関わらないこともありますが、これもコーポレートIT領域における社内「開発」です。
弊社で契約している様々なSaaS（Software as a Service。サブスクリプション型でオンラインから使えるアプリケーション）の機能を組み合わせて、社員の業務プロセスをシステム化・自動化していきます。
以下ブログの例では、SaaSサービスであるQuestetra BPM SuiteというBPM（Business Process Management、業務プロセス管理）ツールを使いやすくするために、AWSを組み合わせた開発を行っています。
- 扱う技術・特徴：
先述のQuestetraでの複雑な承認経路の設計などが該当します。必要に応じて、各ツールをAPIで連携させるためのスクリプトを書くこともあります。 - コーディング以外の重要な要素：
「営業部門やバックオフィスのメンバーがどんな業務で困っているか？」という、社内の業務フローに対する深い理解と業務改善の提案力が求められます。自社の社員が「お客様」になるため、使ってみたフィードバックが最も早く、ダイレクトにもらえる環境です。 - こんな人に向いている！：
「自社のビジネス基盤を裏側から支えたい」「身近な社員からの『ありがとう』という声を直接聞きながら、業務改善の仕組みをパズルのように組み立てるのが好き」という人。
おわりに
「開発」と一口に言っても、サーバーワークスには本当に色々な形があることが伝わったでしょうか。
実際の事例や「コーディング以外の要素」を見ていただくと、単にパソコンに向かってカタカタとコードを打つだけの仕事ではないことがイメージできたと思います。
「画面を作るコードを書きたい！」と思って入社した方も、実際に働いてみると、AIを使ったサーバーレス開発の面白さに目覚めたり、お客様と直接話してビジネス要件を定義するダッシュボード構築にやりがいを感じたりすることがよくあります。
（私も入社時はあまり違いが分かっていませんでしたが、1年かけたOJTでいろいろな現場を回り、理解を深めていきました。）
私たちエンジニアの目的は、コードを書くことそのものではなく、「技術を使ってお客様の課題を解決し、ビジネスを良くすること」です。
「モノづくりがしたい！」という皆さんの熱い気持ちがどの分野で一番輝くのか、これから一緒に見つけていきましょう！
少しでもこのブログが、「自分がやりたい開発ってどれだろう？」「どう違うんだろう？」と迷っている皆さんの助けになれば幸いです。
