エンジニアという仕事

• React/Next.jsやVue.jsなどを用いたプロダクト画面の設計・実装
• デザイナーが作成したデザインカンプ(完成見本)をもとにしたコンポーネント(画面を構成するボタンやカード等の部品)実装。例えば、同じデザインのボタンを何度も使い回せるように部品化する
• サーバーとデータをやり取りする仕組み(API連携)の実装、画面の状態(ログイン中かどうか、選択中の項目など)を管理する設計
• 表示速度や操作性を改善するための調整(例: 画面の読み込みを速くする、ボタンを押した時の反応をなめらかにする)
• 2パターンを比較して効果を確かめるA/Bテストや、利用状況を計測する仕組みの実装

多くのチームでは1〜2週間のスプリント(開発の区切り)単位でタスクを進め、朝会(デイリースタンドアップ)で進捗を共有しながら開発します。実装したコードはプルリクエスト(変更内容をチームに確認してもらう仕組み)としてまとめ、他のエンジニアによるコードレビューを経てから本番に反映するのが一般的な流れです。1つの機能追加につき、設計・実装・レビュー対応を含めて数日〜1週間程度かかることが多く、新機能のリリース直前は複数のプルリクエストが並行して動き、確認作業に追われることもあります。

• 決まった仕様通りに黙々と実装する方が落ち着く人
• デザインや仕様の変更が度々発生することにストレスを感じやすい人
• バックエンドやインフラなど他レイヤーへの興味が薄い人

• フロントエンドのテックリード(チームの技術方針を主導する立場)・アーキテクト(システム全体の設計方針を決める立場)へ
• プロダクト全体を見るフルスタックエンジニア(フロント・バックエンド両方を担える人)へ

• クライアントから支給されたデザインカンプのコーディング(HTML/CSS/JS実装)
• コーポレートサイト・LP(ランディングページ)・ECサイトの新規制作・改修
• 常駐先のプロダクトチームに入り、既存画面の機能追加・改修を担当
• レスポンシブ対応(画面サイズごとの表示調整)、ブラウザ互換性の確認
• クライアントとの仕様確認・進捗報告

1つの案件は数週間〜数ヶ月単位で進み、案件によっては複数を並行して抱えることもあります。デザインカンプ(完成見本)をもとにコーディングを進め、納期直前は複数ページを一気に仕上げる作業が集中します。SESで客先常駐する場合は、常駐先ごとに使用するフレームワークやコーディング規約が異なるため、新しい現場に入るたびに開発環境のキャッチアップが必要になります。クライアントとの仕様確認は、制作会社の営業やディレクターを介することが多く、直接やり取りする機会は案件によって差があります。

• 一つのプロダクトに腰を据えて長く関わりたい人
• 案件やクライアントが変わり続ける働き方に落ち着かなさを感じる人
• 上流の企画・設計から携わりたい気持ちが強い人

• 自社開発企業のフロントエンドエンジニアへ転身
• 制作会社内でディレクター・PM(プロジェクトマネージャー)へ

• Ruby on Rails/Django/Node.js等を用いた、アプリの裏側でデータをやり取りする仕組み(API)や処理ロジックの設計・実装
• データを保存する仕組み(データベース)の設計と、処理を速くするための調整
• 外部サービス・決済システムとの連携実装
• アクセス集中時のパフォーマンス改善、セキュリティ対応
• 障害発生時の原因調査・復旧対応

新機能の開発では、まず設計方針をドキュメント(設計書)にまとめてチームでレビューしてから実装に入る流れが一般的です。実装後はプルリクエスト(変更内容の確認依頼)を出し、他のエンジニアによるコードレビューを経て本番反映します。障害対応の当番(オンコール)をローテーションで担当するチームもあり、担当週は夜間・休日でも緊急のアラートに対応する可能性があります。データベースの設計変更やパフォーマンス改善は、影響範囲の調査だけで数日かかることもあり、慎重な検証が求められます。

• 目に見えるUIの変化にやりがいを感じたい人
• 一つの技術に長く向き合うより、幅広い技術を短期間で試したい人
• 障害対応など緊急の呼び出しに強い抵抗がある人

• テックリード・アーキテクトへ
• SRE/インフラ領域も担うフルスタックエンジニアへ

• クライアントの業務システム・Webシステムの要件定義(何を作るかを決める工程)・基本設計(全体の仕組みを決める工程)への参画。例えば、クライアントへのヒアリングをもとに画面や機能の仕様をまとめる
• Java/C#等を用いたプログラム設計・実装
• 単体テスト(部品ごとの動作確認)・結合テスト(複数の部品を組み合わせた際の動作確認)の実施、テスト仕様書の作成
• 客先常駐先での既存システムの保守・改修対応
• 仕様書・設計書等のドキュメント作成

プロジェクトは要件定義→設計→実装→テストという工程(ウォーターフォール型)で進むことが多く、自分がどの工程から参画するかは案件・商流(元請けか下請けか)によって変わります。設計書やテスト仕様書の作成にはExcelのテンプレートが使われることが多く、単体テスト・結合テストでは想定される入力パターンを網羅的に洗い出してテスト項目表を作る地道な作業が発生します。SESで客先常駐する場合は、常駐先ごとに開発ルールやドキュメントの書式が異なるため、現場が変わるたびに一から慣れていく必要があります。

• 自分の裁量で技術選定や設計方針を決めたい人
• 常駐先次第で担当業務や裁量が変わることに不安を感じやすい人
• 最新技術より安定した既存技術を使う開発に物足りなさを感じる人

• 自社開発企業のバックエンドエンジニアへ転身
• SIer内でPM(プロジェクトマネージャー)・PL(プロジェクトリーダー)へ

• AWS/GCP等のクラウドサービス(インターネット経由で借りるサーバー環境)を使ったインフラの設計・構築・運用
• Terraform等を用いたIaC(インフラのコード化)の推進
• コードの変更を自動でテスト・公開する仕組み(CI/CDパイプライン)の構築・運用
• 監視・オブザーバビリティ(システムの状態を可視化する仕組み)基盤の整備
• 障害対応・インシデント対応プロセスの整備、ポストモーテム(障害の振り返り)の実施

オンコール(障害当番)をチームでローテーションし、担当週は夜間・休日でもアラートが鳴れば対応するのが一般的な体制です。SLO(サービスがどの程度安定稼働すべきかの目標値)の達成状況を定期的に確認し、未達が続く領域があれば優先的に改善に取り組みます。インフラ構成の変更はTerraformなどのコードで管理(IaC)し、変更内容はコードレビューを経てから適用するため、手作業でサーバーを直接いじることはほとんどありません。大きな障害が起きた後はポストモーテム(振り返り)を実施し、原因と再発防止策をドキュメントにまとめます。

• 目に見えるユーザー向け機能を作ることにやりがいを感じたい人
• 障害対応での緊急呼び出しに強い抵抗がある人
• 地道な監視改善やドキュメント整備よりも新機能開発を優先したい人

• SREのテックリード・プラットフォームアーキテクトへ
• セキュリティ・基盤全体を見るエンジニアリングマネージャーへ

• サーバー・ネットワーク機器の監視、障害一次対応
• 定期的なメンテナンス作業(データのバックアップ確認、ソフトウェアの更新プログラム(パッチ)を適用する作業等)
• サーバーラックの構築・配線作業、機器の設置・撤去
• 運用手順書・作業報告書の作成
• クライアントからの問い合わせ対応、エスカレーション対応(自分で解決できない問題を上位の担当者に引き継ぐこと)

多くの現場でシフト制(日勤・夜勤の交代制)を組んでおり、監視画面(モニタリングツール)でアラートが出た際に一次対応し、自分で解決できない場合は上位の担当者にエスカレーション(引き継ぎ)します。定期メンテナンスの作業報告書や運用手順書の作成にはExcelやWordのテンプレートが使われることが多く、深夜・早朝のメンテナンス作業(機器の入れ替えやバックアップ確認)を担当することもあります。経験を積むと、監視・一次対応中心の業務から、サーバーラックの構築や設定変更といった手を動かす作業に関わる機会が増えていきます。

• 上流の設計・構築から早く携わりたい気持ちが強い人
• 単調な監視業務にモチベーションを保ちにくい人
• 決まった手順から外れた自由な裁量を求める人

• 構築・設計を担当するインフラエンジニアへ
• クラウドインフラエンジニア・SREへ転身

• BigQuery/Snowflake等、大量のデータをまとめて保管・分析するための基盤(データウェアハウス)の設計・構築
• ETL/ELT(データの抽出・変換・格納)パイプラインの構築・運用
• ログ収集基盤・データ連携基盤の設計
• データ品質のチェック・監視の仕組みづくり
• 社内のデータ活用部門(マーケティング、事業企画等)からの要望対応

社内のマーケティングや事業企画部門から「このデータをこういう形で見たい」という依頼が日常的に届き、それに応じてETL/ELT(データの抽出・変換・格納)パイプラインを新規構築・改修します。パイプラインは複数本を並行して運用することが多く、データ量の増加や仕様変更で処理が遅くなった際は原因調査・チューニングに時間を使います。SQLでのデータ加工に加え、パイプラインの自動化にはPythonが使われることが多く、データ品質の異常を検知する監視の仕組みも自分たちで整備します。

• 分析結果からインサイトを導く方に関心が強い人(データサイエンティスト志向)
• ユーザー向けの目に見える機能開発にやりがいを感じたい人
• ドキュメント整備やデータ品質管理を後回しにしたくなる人

• データエンジニアリングのテックリードへ
• 機械学習基盤(MLOps)エンジニアへ

• クライアントの業務データを、SQL(データベースを操作する言語)で抽出・集計
• Tableau/Power BI等を用いた、数字の傾向をグラフで見える化する画面(BIダッシュボード)の設計・構築
• クライアントへのヒアリングをもとにした分析要件の整理
• クラウド上のデータ分析基盤の構築支援
• 分析結果・ダッシュボードのクライアントへの説明・報告

1つの案件はヒアリング→分析要件の整理→ダッシュボード構築→納品という流れで、数週間〜数ヶ月かけて進みます。クライアントの業務データはExcelやCSVで受け取ることも多く、SQLでの抽出・集計と組み合わせてExcelで下準備をしてからTableau/Power BIに取り込む、という手順が一般的です。完成したダッシュボードの説明・報告にはPowerPointの資料も使われ、クライアントへのヒアリングで「本当に知りたいこと」を的確に引き出す力が、成果物の質を大きく左右します。

• 一つのプロダクトのデータ基盤に腰を据えて関わりたい人
• クライアントとの折衝より手を動かす作業に専念したい人
• 案件が変わるたびに一からのキャッチアップを負担に感じやすい人

• 自社サービスを持つ企業のデータエンジニアへ転身
• データアナリスト・データサイエンティストへ

• 仕様書・要件定義書のレビューによる不具合の早期発見
• テスト計画・テストケース(『どんな操作をして何が起きれば正しいか』をまとめた確認項目リスト)の設計
• 手動テストの実施、E2Eテスト(実際のユーザー操作を再現するテスト)の自動化推進
• バグ管理・優先度の判断、開発チームへのフィードバック
• リリース判定に関わる品質指標のモニタリング

新機能のテストケース(確認項目)は1機能あたり数十〜100項目規模になることもあり、テストケースの管理にはExcelや専用のテスト管理ツールが使われます。見つけたバグはバグ管理ツール(JIRA等)に起票し、再現手順・重要度を整理した上で開発チームに報告します。E2Eテスト(実際のユーザー操作を再現するテスト)の自動化にはコードを書く必要があり、手動テストと自動化コードの作成を並行して進めるのが一般的です。リリース直前は、限られた時間で優先度の高い項目からテストを終わらせる判断力が求められます。

• 新機能を作る側に回りたい気持ちが強い人
• 細かい確認作業の繰り返しにモチベーションを保ちにくい人
• 不具合の指摘で開発者との摩擦が生じることにストレスを感じやすい人

• QAのテックリード・品質保証責任者へ
• SET(Software Engineer in Test、テスト基盤を開発するエンジニア)へ

• テスト仕様書に基づいたテストケースの実行・結果記録
• 不具合(バグ)の発見・起票(管理システムに記録し開発チームへ報告すること)、再現手順の整理
• ゲーム・Webシステム・スマホアプリ等、案件に応じたテスト対象への習熟
• 経験を積んだ場合のテスト設計書・テスト計画書の作成
• クライアントへのテスト進捗・結果報告

1日に消化するテストケース数は案件やテスト対象によって幅がありますが、数十〜100項目程度をこなすことも珍しくありません。テスト結果の記録にはExcelのテスト仕様書が使われることが多く、見つけた不具合は管理システムに起票して、再現手順・発生条件を具体的に書き起こします。案件が変わるたびにゲーム・Webシステム・スマホアプリなど対象が変わるため、その都度、仕様の理解から始める必要があります。経験を積むとテスト実行だけでなく、テストケース自体を設計する上流工程を任されるようになります。

• 決められたテストケースを消化する作業に単調さを感じやすい人
• 上流の設計・企画に早く関わりたい気持ちが強い人
• 常駐先やプロジェクトが変わる働き方が落ち着かない人

• テスト設計・計画を担当する上流のテストエンジニアへ
• 自社プロダクトを持つ企業のQAエンジニアへ転身

• 製品要件をもとにした組み込みソフトウェアの基本設計(全体の大枠を決める工程)・詳細設計(それを実現する処理の中身を決める工程)。例えば「ボタンを押したらどう反応するか」の大枠を決めた後、実際の処理手順に落とし込んでいく
• C/C++を用いた、家電などに内蔵された小型コンピューター(マイコン)を制御するプログラムの実装
• センサーやモーター等のハードウェアと、ソフトウェアをつなぐプログラム(ドライバ)の開発
• 実機での動作検証・デバッグ(不具合の原因を見つけて修正する作業)、消費電力やメモリ使用量の最適化
• ハードウェア設計担当者との仕様すり合わせ

1つの製品の開発サイクルは1〜2年に及ぶこともあり、Web開発のような短いリリースサイクルとは時間軸が大きく異なります。基本設計・詳細設計の段階ではドキュメント(仕様書)を作り込み、実装後は実機での動作検証に多くの時間を使います。不具合の原因特定にはオシロスコープ等の計測器を使ってハードウェアの信号を確認することもあり、ソフトウェアの視点だけでなく電気的な視点からのデバッグ力も求められます。量産直前の検証フェーズでは、様々な使用環境を想定したテストを網羅的に行うため、業務が集中しやすくなります。

• Webサービスのような短いサイクルでのリリース・改善を好む人
• ハードウェアの制約を意識せず自由にソフトウェアを組みたい人
• 実機での検証やデバッグといった地道な作業を負担に感じやすい人

• 組み込みソフトウェアのアーキテクト・テックリードへ
• IoTシステム全体(クラウド連携含む)を見るエンジニアへ

• クライアントから依頼された機器の組み込みソフトウェア設計・実装
• 小型機器向けのLinux上で、ハードウェアを制御するプログラム(ドライバ)やアプリケーションの開発
• 案件によっては要件定義・基本設計等、実装より前に何をどう作るか決める「上流工程」への参画
• 実機や、開発中のソフトを試すための試作用の基板(評価ボード)での動作検証、不具合修正
• 開発ドキュメント(設計書・仕様書)の作成

1つの案件は数ヶ月〜1年程度の期間で進み、評価ボード(試作用の基板)を使って実機に近い環境で動作検証を重ねます。案件によって開発対象(車載・医療機器・産業機器等)や使用する言語・環境が変わるため、新しい案件に入るたびに、そのハードウェアの仕様書を読み込むところから始まります。設計書・仕様書の作成にはWordやExcelのテンプレートが使われることが多く、量産直前の検証フェーズでは、様々な使用条件を想定したテスト項目を一つずつ潰していく地道な作業が続きます。

• 一つの製品・ハードウェアに腰を据えて長く関わりたい人
• 案件が変わるたびに開発環境を学び直す負担を大きく感じる人
• 上流の企画段階から一貫して携わりたい気持ちが強い人

• 自社製品を持つメーカーの組み込みエンジニアへ転身
• 受託開発会社内でPM・テックリードへ