ども!だいす(@dice_motosensei)です!
具体的に知りたいな。
今回はこんな疑問に答えていきます。
本記事の内容
- ITエンジニアの仕事内容(筆者の場合)
- 転職先選びの注意点
ITエンジニアって、リモートワークができたり私服で働けたり、なんかこうキラキラしたイメージがあると思うんですよね。
でも、そのイメージだけで転職すると失敗するかもしれません。
仕事内容が、あなたに合わない可能性があるからです。
そこで本記事では、未経験からエンジニア転職して約1年の新米エンジニアである筆者が、実際どんな仕事をしているのか教えます。
ITエンジニアの仕事内容が、具体的にイメージできるようになりますよ。
記事の信頼性
筆者は、2019年3月に小学校教員を退職。
その後、2019年4月からおよそ10週間プログラミングスクールに通い、同年8月にエンジニア転職を果たしました。
未経験からエンジニア転職、実務経験約1年の新米エンジニアです。
ITエンジニアの仕事内容 まとめ
筆者が働いている会社では、まずはパッケージシステムを顧客に提供しています。
その後、顧客の要望に合わせてシステムをカスタマイズしていきます。
なので、自社サービスを提供しながらも受託開発をしているって感じのちょっと特殊なパターンです。
さて、そんな会社で働く筆者の仕事内容をざっくりまとめると、以下の通り。
- 顧客と仕様の打ち合わせ(要件定義)
- どうやって実現するか考える(設計)
- 実際に作る(開発)
- 作ったプログラムのテスト
- 納品する
- 顧客からの問い合わせ対応
- バグ修正
- 見積もり作成
もう少し詳しく解説していきます。
開発関係
システム開発には、大きく「上流工程」と呼ばれる仕事と「下流工程」と呼ばれる仕事があります。
厳密に言うともう少し工程が細かく分かれていますが、ざっくりこんな流れです。
一般的には、主に上流工程の仕事をするのが「SE(システムエンジニア)」、主に下流工程の仕事をするのが「PG(プログラマー)」と言われていますね。
筆者の場合は、運よく上流工程・下流工程どちらの仕事も経験できています。
ということで、具体的にどんな仕事をしているのか紹介します。
顧客と仕様の打ち合わせ(要件定義)
システム開発において肝になる工程。
顧客と以下のようなことを打ち合わせたり、ヒアリングしたりします。
- 解決したい問題(システム導入の背景)
- システムで実現したいこと
- システムでできることと、できないことの切り分け
ポイントは、顧客の要望を全て実現することが良いわけではないこと。
ゴールは業務の効率化や最適化のはず。
なので、なんでもかんでもシステムで実現することを目指すのではなく、顧客のオペレーションを改善することを提案することもあります。
いずれにせよ、この土台の部分がしっかり固まっていないと、いざ開発する段階になって困ってしまいます。
どうやって実現するか考える(設計)
システムで実現すること(仕様)が決まったら、上長も交え、プログラムレベルでどのように作っていくか考えます。
意識しているのは以下のようなこと。
- 似たような処理で、再利用できるところはないか
- できるだけ処理を軽くするにはどうするか
- 顧客の使用感を良くするにはどうするか
基本線は、できるだけラクに作る。
なおかつ、顧客が使いやすくする。
ここで、ある程度開発の道筋が見えるようになるまでしっかり練っておきます。
実際に作る(開発)
設計ができたらいよいよ作っていきます。
この時間が楽しいんですよね~
この段階では以下のようなことに気を付けて作っています。
- どんな処理をしているのかコメントを残す
- すでに正常に動いているところをむやみにいじらない
- だらだら長いプログラムにならないように知恵をしぼる
要は、保守性を高められるようにするってことですね。
「正しく動くプログラム」に加えて、「メンテナンスしやすいプログラム」を目指します。
ちなみに、開発している途中で「あれ、ここどうすればいいんだ?」ってなることもしばしば。
そんなときは、設計し直したり、場合によっては先方と仕様の確認をもう一度行ったりします。
筆者の職場の場合は、「要件定義」「設計」「開発」はフレキシブルに行ったり来たりしています。
顧客と直接つながっているからこそできることですが。
開発が終わったら、「検証指示書」をEvernote(エバーノート)で作成します。
この指示書と仕様書を元に、テスト担当者が正しく動くかテストします。
作ったプログラムのテスト
当然ですが、開発者とテスト担当者は別です。
テストに必要なデータを入力し、仕様通りに動くかテストします。
開発担当者が作った検証指示書に沿って、一つ一つチェックをしていく感じ。
おかしなところが見つかったら、その旨を検証指示書に追記して開発者に戻します。
開発者は修正して、テスト担当者に再テストしてもらう。
この繰り返しですね。
全てのテストが無事通ったら、晴れて開発完了です。
ちなみに、仕様の打ち合わせから開発完了まで、軽い案件だと2週間程度、重い案件だと2~3ヶ月ほどかかります。
納品する
筆者の会社の場合は、顧客の環境ですでに動いているシステムにアップデートをあてることになります。
とはいえ、全部リモートで行うんですけどね。
- アップデートする前にバックアップをとる
- アップデートをあてる
- 正しくアップデートがあたっているか確認
こんな感じでアップデートをあてて、納品完了。
保守関係
新しいものを開発するだけでなく、一度納品したものの面倒を見る必要もあります。
主に下記のような仕事。
- 顧客からの問い合わせ
- バグ修正
- 見積もり作成
顧客からの問い合わせ対応
「〇〇ができないんですけど、どうすればいいですか?」
「〇〇の値がおかしいんですけど…」
こういった問い合わせに対して、詳しい状況をヒアリングし対応します。
すぐに答えが分からないケースでは、社内にある顧客のシステムのバックアップを使って挙動を調べます。
それでも分からなければ、顧客の環境にリモートでつないで、現地のデータを使って調査。
トラブルの原因はだいたい次のどちらか。
- 顧客の操作ミス
- システムのバグ
顧客の操作ミスの場合は、復旧の仕方や正しい操作を教えます。
システムのバグの場合は、陳謝し速やかに対応します。
バグ修正
顧客からの問い合わせや、別件サポートの最中にシステムのバグに気付くことがあります。
もちろん無償で対応することになりますが、緊急度によって優先度が変わります。
顧客が今すぐ使うとなれば、もちろん即時対応。
該当箇所を使う時期までまだ時間の余裕があるなら、それまでに間に合うよう修正します。
バグの程度にもよりますが、修正から検証、納品まで早ければ1日で終わります。
見積もり作成
顧客のサポートをする中で、新たなカスタマイズの要望を受けることがあります。
そんなときは見積もりも作成します。
手順はだいたい以下の通り。
- 修正箇所の洗い出し
- 修正にかかる工数(時間)を算出
- 工数から見積金額を算出
- 上長のチェックを受ける
- 先方に提示
個人的に大事だと思っているのは工数を算出するところ。
見積もり時に出した工数で開発スケジュールを組むことになります。
つまり、算出した工数がいい加減だと、タイトな開発スケジュールになってしまうことも。
転職先選びの注意点
さて、以上が筆者が実際に行っている業務です。
これを踏まえて、ITエンジニアへの転職を考えているあなたへアドバイス。
どの工程の仕事ができるのか確認する
上流工程と下流工程では、行う業務も感じるやりがいも全く違います。
筆者の場合は、会社の規模が小さいので仕事内容が幅広いですが、こういう会社ばかりではありません。
入社したら実際どんな仕事を任せてもらえるのか、面接のときに必ず確認しましょう。
同じように転職した方が、どのように活躍されているのかを聞いてみるのもいいです。
中小やベンチャーは仕事が幅広くなりやすい
中小やベンチャーは常に人が足りません。
自然と、様々な業務を任されるようになります。
つまり、成長の角度がつくことが比較的多いです。
また、会社全体の動きもとらえやすいので、自分の仕事が会社にどう貢献しているのかも見えやすいです。
それは、「自分が役に立っている」というやりがいにもつながります。
大企業は仕事が限定的になりがち
一方、大企業ではどうしても仕事がきっちり分担されがちな印象。
フレキシブルに様々な業務を経験することはなかなかできないでしょう。
また、会社の規模が大きいと、会社全体の動きというのは当然とらえにくいです。
こんな風に感じてしまうかもしれません。
その代わり、任されている業務のプロフェッショナルになれる可能性はあります。
せまく深くスキルを上げていくイメージでしょうか。
まとめ
おさらいです。
未経験から転職して1年の新米エンジニアが行っている業務は以下の通り。
- 顧客と仕様の打ち合わせ(要件定義)
- どうやって実現するか考える(設計)
- 実際に作る(開発)
- 作ったプログラムのテスト
- 納品する
- 顧客からの問い合わせ対応
- バグ修正
- 見積もり作成
ITエンジニアの仕事内容について、少しでも具体的なイメージがわいたなら幸いです。