Webエンジニアってどんな仕事するの?個人の経験を踏まえて少し書いてみる

Webエンジニアにこれからなろうとしていたり、エンジニアやってみたいなあ・・・なんて思っている方はどんな仕事内容なのか気になりますよね。せっかく勉強してエンジニアになっても、自分が想像しているものと違っていたらなんか嫌ですからね。

エンジニアとしてフロントエンドやバックエンドをやってきたので、それらの経験を踏まえてどんな作業をすることになるのかをこの記事では書いていきたいと思います。ちなみに自分が関わったことのある企業はWeb系のベンチャーやスタートアップ系が多い気がする。

企業やポジションによってやることは変わってくるはずだから、あくまで一個人の見え方としてこんな感じだよっていう記事だから参考程度にどうぞ。

ではやっていこう。

エンジニアはプロダクト開発に関わるよ

エンジニアと言ってもアプリ開発エンジニアやインフラエンジニア、フロントエンドエンジニア、サーバーサイドエンジニアなど多種多様です。コードを書くだけじゃなくて、コードを書いている人たちをまとめるプロジェクトマネージャーがいたりもする。そして皆企業のサービス・アプリ開発に関わっている。

大まかにやることを書くとこんな感じだろうか。

仕事内容
  • 要件定義
  • 仕様書・設計書作成
  • コード記述
  • テストコード記述
  • ドキュメント記述
  • マイルストーン作成
  • 進捗会議・スプリント会議

色々あるけど、その会社のポジションによって自分のやる作業も変わってくる。例えばフロントエンドエンジニアなら画面の開発に使う技術を選定したりコードを書いたりそれに関するドキュメントを書いたり。ただそのフロントエンドエンジニアの中でもタスクを振る人がいたり、ドキュメントを書く人がいたりといった場合もあります。これはその企業で働いている人によって様々

中にはサービスの管理画面開発を一人でやったりとかもあったりして、そういう場合には自分一人で使用を考えたりドキュメントを書いたりマイルストーンを作ったりとかいうことになったりもする。ただ正直そのプロジェクトに入ってみないとどんなことをやるのかは詳しくは分からない。フリーでエンジニアをやったりすると特にそうだと思うよ。

要件定義

クライアントからどんなことをしたいのかを聞き出し、必要な機能を洗い出す工程です。

今まで数社エンジニアとして関わってきたけど、これが要件定義です!ちゃんと要件定義書書きます!っていうところは珍しい気がする。自分がスタートアップやベンチャー気質の会社と関わることが多かったからっていうのもあるけど、かっちり要件定義書を作って仕様書を作って・・・っていうのはなかったかな。(自分が見れていないだけかもしれない)SIerなら多そうだけどね。

要件をエンジニアじゃなくて事業部の人と話し合ったり、どういう風に作るかといったざっくりした仕様書は書いたりしていたこともあるけど、どの企業でもそういうことをしたわけじゃないです。

要件定義がどういったものかっていうのは他のサイトの記事が参考になります。

Webエンジニアとして働くなら要件は大体決まっているけど、開発時の仕様はエンジニアが考え時にはやりとりして実装していくっていうことが多いんじゃないかな、と思います。タスクがあってそれを実現するにはどういう仕様にしてどういうライブラリを使ってどう実装するのか?といった感じ。PMなら開発には参加しないことが多いからそういうことはしないことが多いけどね。

仕様書・設計書作成

どんな機能でどんな風に開発するのかっていうものを作成する作業。

この辺りもけっこうあやふやな感じが多い気がする。しっかり作っているところは作っているんだろうけど、「これから仕様書や設計書を作って、それから開発します。」っていうのはなかったなあ。この設計書通りに作って!みたいなこともなかったからまあそんな感じだ。SIerやウォーターフォール開発ならありそう。

自分がそれっぽいことを書いたものは以下ぐらい。

  • 画面遷移図の作成・・・このボタンを押したら度の画面に遷移するか等
  • それぞれの機能の処理の概要を記述・・・これを見て開発する人が分かるように記述

(なんか他にも書いたりしたことがある気がするけど思い出せない・・・)

残しておきたいものがあったらesaやdocbaseのようなドキュメントを書けるツールで書いて残すっていうことをしたりもしていました。

コード記述

何かサービス作るためにコードを書く作業です。フロントでもバックエンドでもガリガリとコードを書いていきます。インフラエンジニアなんかはサーバー構築したりインフラ環境をコードに落とし込んだりですね。

大体どこの企業でもそうだと思うけど機能を開発するためのタスクが切られて、その切り分けられたタスクをエンジニアがこなしていくっていうスタイル。

  1. タスクが切られる
  2. タスクを満たすコードを記述する
  3. Github等に上げてレビューしてもらう
  4. レビューが通ったらマージ

タスクを切るのはコードを書くエンジニアやPMだろうけど、開発チームによって違いますよね。レビューもバシバシしてくれるところもあるけど、人数がいないとバシバシ作ってマージという流れもあるでしょう。

多くのエンジニアはこのコードを書くことがメインになるんじゃないかなと思います。もちろん他の業務もあるけど、コードを書いてレビューコメントを見て修正しての繰り返しです。

テストコード記述

機能を作ったら期待通りに動くかっていうテストコードを書く。TDDなんかをやっているところはテストコードを先に書いてその後に機能を作っていくっていうパターンもあるはず。

ただテストコードはすっ飛ばされたり余裕あればやろう・・・みたいなことが多いように感じる。これを見ている人の中にもテストコードが書かれていないプロジェクトを見たことがある人は多いんじゃないだろうか。

テストにも種類があってどれかだけはやろう、みたいな場合もありますよね。

  • 単体テスト
  • 結合テスト
  • 総合テスト
  • 受入テスト

関数レベルでテスト用のコードを書いてテストする単体テストや画面をポチポチしたりするテストなどいくつか種類がある。受入テストなんかだと画面ポチポチして実際に期待する動作になるか?っていうテスト。下に行くほど大きい範囲のテストになるね。

ドキュメント記述

他の開発メンバーに知っておいてもらいたいことなんかは資料として残したりします。例えば使用するライブラリや設計に関してなどなど。記述する場所は企業が擁してくれているツールがあればそれを使ったりですね。

  • esaやDocbaseなどに記述
  • GithubのWikiに記述

ちなみにesa使いやすくて結構好きです。

esa

マイルストーン作成

どれぐらいで開発を終えることができるか?っていう計画です。

タスクを洗い出してこれのタスクはこれぐらい、このタスクはこれぐらいだからプロジェクト全体ではこのぐらいかかるなあ・・・っていうやつです。それをスプレッドシートやBacklogのマイルストーンに落とし込んでいきます。

Backlog

大体どれぐらいで終わるか?っていう見積もりができないと作ることができないから結構難しいですよね。自分はこの作業好きじゃないです・・・

ある程度どんなことをするかが見えていないとできないから、単にコードを書く人っていうよりはその開発チーム(バックエンドならバックエンド、フロントならフロント)でPMに近いような人がやる場合が多いんじゃないかな。

進捗会議・スプリントプランニング

企業であればそりゃあ会議ありますよね。進捗会議や今後のタスクを決めていくスプリントプランニングなどなど。進捗を報告するときには設定したタスクの進み具合を共有し、スプリントプランニングでは今から1・2週間先はどんなタスクをやるのかを決めていく。

スプリントはスクラム開発で行われたりするから、そういった開発手法を取っていない場合はまた別の方法を取ったりするでしょう。

こういう話し合いって疲れますよね。スクラム開発をしているところだと1日の大半を使って振り返りをしたり今後の進め方を話し合うこともあるでしょう、めちゃくちゃ疲れます。まあ頑張りましょう。

レビュー

コードを誰かが書いたらレビューを依頼してくることがほとんどだと思うから、作業の隙間にレビューしよう。プルリクによってはコード量もかなりあるから、入念にチェックだ。

Github

ただレビューする時間って余裕がある時じゃないとあまり取れないですよね。コードの品質ってレビューによっても結構変わってくると思うから、その時間があるかないかっていうのも大事な気がする。

チャット

Slack

基本的にSlackでいつでも連絡が取れるようにつながっているから、そこで何か聞かれたら対応したり、自分が何か聞きたいことがあったら投稿したり共有したりといったことが行われます。大体どこで働くとしてもSlackでのやり取りは頻繁に行われると思うから、おのずとSlackを意識するようになります。

保守・運用

サービスを作ってリリースしたら終わりではありません。そのサービスを運営していれば必ずバグは起きるし、新機能を追加しようっていう話にもなってきます。バグが起きたらそれを修正するタスクをして、新機能を作る際にはまたコードを書いて・・・っていう繰り返しです。

サービスづくりは作っただけでは終わらないんだ。世の中で起きるサービスのバグが起きたっていうニュースは見るけど、あれは氷山の一角で作るサービスにはバグが付きまとう。それらを解消していくのも仕事の一つだ。

主にやることはポジションによって変わるがエンジニアの基本は開発

Webエンジニアの仕事内容を上で書いてみたけど、大体のエンジニアのやることは開発です。コードをガリガリ書いていく作業だ。その作業に付随してコードレビューや実装相談や、タスク整理などいろいろついてくる。

チームのPMや技術顧問、スクラムマスターなど開発をメインとしないポジションにいる人たちは開発をしない場合が多いけど、まあ基本開発だ。フロントエンドもバックエンドも関わるっていう場合もあるけど、分けて少し書いておきます。

バックエンドエンジニア

バックエンドエンジニアはフロントエンドから叩かれるAPIを作ったりDBやサーバー側のことを担ったりします。インフラ寄りのことにも手を出したりするのがバックエンド。例えばAPIを作るにしてもDBは何を使って、Webサーバーは何を使ってデプロイ先はどこにして・・・と色々必要になってきます。画像はどこに保存して、ログはどこに置1いて・・・とか本当に色々。

インフラエンジニアがいる場合は、インフラエンジニアと連携をとって進める場合もあるでしょう。

個人的には目に見える方を開発するのが割と好きだけど、ユーザーの目には見えない画面に関わらない部分をやりたい人にはおすすめです。

フロントエンドエンジニア

フロントエンドエンジニアはユーザーから見える画面の開発に関わります。画面やボタン、アニメーションを作ったり、APIを呼び出す記述をしたりしていく。デザイナーがいる場合はデザイナーの人が作ったものを見つつ画面を作っていったりします。

画面を開発したりCSSの記述が好きな人はフロントエンドエンジニアいいんじゃないでしょうか。フロントエンドでもアクセシビリティを気にする人はCSSを気にする人、処理のコードを気にする人など様々です。

エンジニアとして勉強するなら

このサイトではいくつかプログラミング関連の記事を書いているんだけど、もしエンジニアとしてやっていきたいかもって思ったら学習方法などは以下の記事で紹介しているから良かったら参考にしてみてください。