エンジニアの仕事内容が分からない人へ｜未経験転職後の実装・要件定義を紹介

パソコンの前にいるのは分かります。でも、その画面の向こうで何をしているのかは、なかなか見えてきませんよね。

私も、実際の開発現場で働くまでは、エンジニアの仕事を全くもってイメージできませんでした。

この記事では、私が経験した「プログラムを実装する仕事」と、現在担当している「システムの要件を決める仕事」を紹介します。工程名だけで説明されてもピンとこないと思うので、Google Chromeやお掃除ロボットを例に、仕事の流れをたどっていきますね。

この記事は、ま・だ・エンジニアとして働いたことがない方や、これから現場へ出る方に向けた内容です。

そんな方が、働く姿をイメージする手がかりになれば幸いです。

まずは、私が経験した2つの仕事について

私は技術派遣会社で働いています。この記事は、あくまで私が経験した現場のお話です。エンジニア全員が同じ仕事をするわけではなく、会社や開発するシステムによって、進め方も作成する書類も異なります。

今回紹介する仕事を、先に並べてみます。

仕事	私・私たちが担当する範囲	忙しさの目安
① 社内システムの保守・追加機能開発	私はプログラム設計〜結合テストを担当。要件定義〜詳細設計は先輩エンジニアが担当	★★☆☆☆
② 現職のBtoB向けシステム開発	委託元の私たちは要件定義・総合テストを担当。ソフトウェア開発はSIerへ委託	★★★☆☆

① プログラムを実装する仕事｜忙しさ★★☆☆☆

いわゆるプログラマーのお仕事です。朝から晩までソースコードを眺めては、うんうん唸っていました。

転職後、初めて従事したのは、コンサルティング会社が開発した社内システムの導入支援と開発業務でした。

システムの移管後は、そのツールを保守・運用しながら、追加機能を開発する日々でした。私が主に担当したのはプログラム設計〜結合テストで、その前の要件定義〜詳細設計は先輩エンジニアが行っていました。

追加機能は、どうやって作るのか

ここからは、先輩が担当する工程も含めた、チーム全体の流れを紹介します。

実際の社内システムは例に出せないので、身近なGoogle Chromeを題材にしてみましょう。以下は説明のための架空の開発例であり、実際のChromeの開発方法や内部の仕組みを説明するものではありません。

1. 何に困っているのかを整理する｜要件定義

というわけで、ブックマーク機能の実装が決まりました。

何となく「便利な機能を作ろう」で終わらせず、何ができればよいのかを要件定義書へ記載します。

要件ID	実現したいこと	優先度
REQ-F-001	現在閲覧中のページをブックマークとして登録できること	高
REQ-F-002	保存されたブックマークをクリックすると、該当のページを開けること	高

2. どう実現するのかを考える｜基本設計・詳細設計

次は、画面やデータ、処理をどう作るかを考える段階です。

• 登録ボタンはどこに置く？ アイコンは☆？ それとも♡？
• 登録したページはどこで見る？ トップページに一覧を置く？
• どんなデータを保存する？
• 画面と、その裏側の処理をどうつなぐ？

「ブックマークを作る」という一言から、考えることが次々と出てきます。☆を置けば完成、とはいかないわけですね。

決めた内容は、画面設計書や基本設計書・詳細設計書へまとめます。

3. ソースコードを書く｜プログラム設計・実装

ここからが、私も主に担当していた範囲です。

既存の機能にどう組み込むかを考え、画面とバックエンドの両方に必要な変更を加えます。バックエンドは、画面の裏側で動く処理のことです。

既存のソースコードやインターネットの情報を参考にして、時にはコピペも多用しながら、何とか実装していました。

4. 手元で動かして確かめる｜単体テスト・結合テスト

コードを書いたら、自分のパソコン上でアプリを起動し、実際に操作してみます。

• ☆を押したら登録されるか？
• 登録したページが一覧に表示されるか？
• 一覧から正しいページへ移動できるか？

期待した動きにならなければ修正して、もう一度確認します。書いて、動かして、直して。また動かして。試行錯誤の繰り返しです。

5. チームで確認して、使う環境へ出す｜総合テスト・リリース

Gitは、ソースコードの変更履歴を記録するためのツールです。Gitや課題管理ツールで変更内容を共有し、テスト環境で確認してもらいます。問題があれば直し、問題がなければ本番環境へリリースしてもらう、という流れです。

私が一番緊張したのは、手元のローカル環境からテスト環境へ出すときでした。

そこで初めて、自分が実装した機能が人目に触れます。

「うまく動かなかったらどうしよう……」

手元で確認していても、毎回不安になる瞬間でした。

不具合が出たら、原因を探す｜デバッグ

追加機能の開発だけでなく、日常的にデバッグも行っていました。デバッグは、不具合の原因を調べて直していく作業です。

社内からの問い合わせや、同じチームのメンバーから不具合の報告を受けたら、まずは自分の手元でも同じ現象が起きるかを確認します。

ここでも、Chromeを題材にした架空の不具合で説明します。実際にChromeで起きた不具合ではありません。

そんな報告を受けた、という想定です。「（え？ ほんまかいな？）」と自分でも操作してみます。

試す入力	結果
日本語	検索成功
半角英数字	検索成功
記号（＠や「（」など）	サーバーエラー

ここで、「記号を入れるとだめなんだ」という条件が見えてきます。

ただし、条件が分かったところで修理完了、とはなりません。次は、なぜ記号を入れるとだめなのか、どこで処理がつまずくのかを、ソースコードを見ながら追っていきます。

原因が分かったら、どのように修正するかを報告し、修正作業に取り掛かります。

コードを見る。試す。またコードを見る。この往復で丸一日が過ぎていた、なんて日はしょっちゅうでした。

読みやすいコードを書くために、頼った本

この仕事で意識していたのは、いかにして読みやすいコードを書くかでした。

お世話になったのが、『リーダブルコード』と『良いコード悪いコードで学ぶ設計入門』です。『リーダブルコード』は付箋まみれになっています。

② 要件を決め、設計を確かめる仕事｜忙しさ★★★☆☆

現在は、企業向けのBtoBシステムの開発に携わっています。ソフトウェア開発自体はSIerという開発会社に委託し、委託元の私たちは「要件定義」と「総合テスト」を担当しています。開発はウォーターフォール型で進めています。

ここでは、そのうちの要件定義から、設計書を確認するまでの仕事を紹介します。

実際のシステムは例に出せないため、今度はお掃除ロボット「ルンバ」を題材にしてみます。こちらも説明のための架空の例です。実際のルンバの製品仕様や開発方法を示すものではありません。

まず、「何を作るか」を決めます

要件定義とは、「何を作るか」を決めることです。料理に例えると、まず「何を食べたいか」を食べる人に聞くところですね。

そこをすっ飛ばして激辛カレーを完成させても、「いやこんな辛いの食えるか！！」の一言で終了してしまいます。

システムでも、何が必要なのかを整理し、開発する人と共有できる形にする必要があります。

私が作成した書類は、主に次の3つです。ここからは、まとめて「要件定義書類」と呼びます。

書類	記載する内容
要件定義書	システムの全体構成、実現したい機能、セキュリティや保守性などの要求
画面要求書	必要な画面、表示項目、ボタンやリンクを押したときの処理概要。ワイヤーフレーム程度の画像も添える
業務フロー図	システムを使う業務の流れ。「業務」の流れを示すもので、システム内の細かい処理までは追わない

ルンバの例なら、本体とスマホアプリの両方について考えます。

• 本体：スタートボタンで掃除を始める。障害物を検知して回避する。
• スマホアプリ：遠隔で掃除を始める。お掃除スケジュールを作る。掃除した範囲を記憶し、マップを作る。

こうした要求を要件定義書へまとめ、スマホアプリの画面に何を配置するかも、画面要求として整理していきます。

設計が始まってからも、質問への回答が続きます

要件定義書類をもとに、SIerが基本設計書・詳細設計書を作成します。

書類を渡したら次の工程へバトンタッチ……と、そこで終わるわけではありません。

設計を具体化するなかで、不明確な仕様や、認識が合っているか確認したい部分が出てくるためです。SIerから質問が届き、私たちはそれに回答します。

たとえば、お掃除スケジュールの機能なら、こんな質問です。

スケジュールは上限何個まで設定できますか？

正常に実行されなかった場合、画面にエラーを表示しますか？

「スケジュールを作れる」と書くだけでは、まだ決めることが残っているわけですね。

仕様の不足が分かったら、要件定義書類を修正します。この例では、次のように要求を追記します。

• スケジュールは上限10個まで設定できること。
• 正常に実行されなかった場合、スマホアプリにエラーと「実行されなかった理由」を表示すること。

この「10個」は、あくまで今回の架空の例での設定です。

私が携わっている開発では、スケジュールがキツキツだったこともあり、要件定義と基本設計がほぼ並行して進んでいました。設計が始まった後にも、質問に答え、仕様を詰め、書類を直す。そのやり取りが続きます。

設計書を受け取ったら、要求と食い違っていないかを確認します

設計書というと、「基本設計書！」「詳細設計書！」と大きなファイルが一つずつあるように思えるかもしれません。しかし私の現場では、これらの設計書は複数のファイルに分けて作成されます。

どんな内容を書くのか、ルンバの例で見てみましょう。

• インフラ構成：システムを動かす土台をどう用意するか。どのクラウドサービスを使い、どんなネットワークでつなぎ、マップをどこへ保存するかなどを決めます。
• データベース構成：どのような構造でデータを保存するか。
• 画面設計：お掃除スケジュールを登録する画面をどう作るか。
• API設計：スマホアプリと裏側の処理が、どんな情報をやり取りするか。お掃除スケジュールの登録時に渡す情報や、登録結果として返す情報を決めます。

私たちが確認するのは、主に次の3点です。

1. 要件定義書類の仕様が、正しく設計書に反映されているか。
2. 複数の設計書の間で、内容に食い違いがないか。
3. 誤字脱字がないか。

本体とスマホアプリの例で話してきたように、関係する部分が複数あれば、それぞれを見比べる必要があります。書類を一つ読んで終わり、という仕事ではありません。

仕様を考えるのは大変でも、形になると少し感動します

以前の社内システムの仕事では、厳密に決められたスケジュールはありませんでした。一方、現在は外部の開発会社に委託し、契約期間も決まっています。つまり、ケツが決まっています。

設計書を作成するのはSIerでも、仕様を決めきれていない部分はこちらの責任でもあります。こちらの対応が遅れれば、その分、全体のスケジュールも遅れていきます。

私が主に担当しているのは、UIやクラウドアプリ周りです。要件定義書の内容に沿って仕様を考えながら、「不整合は起きないか」「書かれていない内容をどこまで決めるのか」「この仕様でよいのか」と、かなり悩みました。

要件定義書類の作成には、非常に時間がかかりました。ほぼ一人で仕様を考えていたこともあり、責任の重さを少し感じる部分もありました。

それでも、自分が考えた仕様が設計書となって出てくると、少し感動します。

考えていたことが、形になっている。

この仕事を「やりがい」と思うのか、「しんどい」と嘆くのかは、自分次第です。今のところ私は、しんどさよりもやりがいが上回っているので、仕事を続けられています。

仕事中は、どんなふうに過ごしているのか

私の実勤務時間は7時間45分。そのうち9割弱は、パソコンの画面と睨めっこしています。

残りの1割強は、小休憩、お花を摘みに行く時間、同僚との雑談などです。

対面の会議がある日は別ですが、私の場合、対面で打ち合わせをする機会は週に2〜3回程度。基本的には、一日の大半をブルーライトを浴びて過ごしています。

雑談やコーヒーブレイクもあります

仕事中ずっと、無言でパソコンに向かっているわけではありません。息抜きも大事です。

雑談が仕事につながることもありますし、コミュニケーションも業務の一環です。

おわりに｜現場で、少しずつ仕事の進め方をつかんできました

最初は右も左も分からず、勉強したはずの知識もうまく活用できませんでした。それでも、月日が経つにつれて、次第にやるべきことをつかめるようになってきました。

実際の現場で学んだのは、同じウォーターフォール型の開発でも、仕事の進め方は同じではない、ということです。

1社目と2社目では、作成する書類も、その作り方も全く異なっていました。社内向けと外販向けのBtoBシステムという違い、会社の違い、関わる人の違いがあったからです。

会社ごとに書類のフォーマットがありますし、担当するエンジニアによっても記載する内容は異なります。その現場のやり方に適応する必要があるのです。

勉強は、もちろん大事です。そこに加えて、現場で学びながら、その場の仕事の進め方を少しずつつかんでいくことも大事だと、私は考えています。

事前にゴリゴリに知識武装していなくても、現場で徐々に学んでいけばよい。私は、そうやって仕事を覚えてきました。

大丈夫です。私でも何とかやれてます。

ここまで読んでくださり、ありがとうございました。
転職前の準備については「転職前に勉強した内容と学習時間」、転職活動については「ポートフォリオなしで挑んだ書類選考・面接」も参考にしてください。