PR

システムエンジニアの仕事内容と繁忙期のリアルな1日

広告

みなさま、こんにちは。当記事ではシステムエンジニアを7年(8年目)経験した私が繁忙期の作業量と1日のスケジュール感をご紹介いたします。なお、当記事で紹介するシステムエンジニアとはwebアプリケーションの開発業務のことになります。

「SEとして働けるかな?」「SEはブラックって聞くけどどうなの?」

この疑問に対して、今回は黒い部分にだけフォーカスを当ててご紹介いたします。

SE(webアプリ開発)ってどんな仕事?

はじめに、SE(開発系)の仕事内容を簡単にご紹介いたします。ご存じの方は目次リンクより次の章まで飛ばしてください。まず、開発業務ですが主に以下2種類の開発手法があります。

  • ウォーターフォール開発
  • アジャイル開発

ウォーターフォール開発とは

プロジェクトによっては省略したり逆に細かく詰め込んだりと様々ですので、あくまで一例です。

ウォーターフォールの開発手順
  • 要件定義
    • システム化の目的
    • システムの概要
    • 実装すべき機能(画面/帳票/バッチなど)
    • 求める性能(処理速度/セキュリティレベルなど)
    • スケジュール(期限)
    • 開発人員の人数
    • 使用するプロダクト(ワードプレスで言うテーマ決め)
    • スペック(サーバの容量等)
    • 予算

    あくまで一例ですが上記の事項をお客様と打ち合わせ、決定する

  • 設計
    設計の詳細
    • 基本設計

      プロジェクトにより記載レベルが異なる。簡単に言うと、浅く広い設計書を作成する

    • 詳細設計

      基本設計で作成した内容をより細かく細分化し、プログラミングに落とし込むにはどうすれば良いかをベースに作成する

  • 製造

    詳細設計書を基にプログラミング

  • 試験
    試験の詳細
    • 単体試験

      製造工程をベースに試験

      プログラミングで作成したソースコード1行(ステップ)に対し1つの試験を実施。すべてのコード(分岐/繰り返し)が想定通りに動作するか確認をする。

    • 結合試験

      設計工程をベースに試験

      異なるソースコードのファイルや異なる機能を同時に確認する。主に変数の受け渡し(インターフェース)に関する確認をする。

    • 総合試験

      要件定義工程をベースに試験

      要件定義工程で定めた項目すべてが満たされているか確認する。要はそもそもの確認。

  • 商用環境へのリリース

    試験結果をお客様にご確認頂き、承認を得られれば商用環境(お客様が使用する環境)に作り上げたソースコードをリリース。同時に要件定義書・設計書などの資料も納品する。

  • 運用・保守

    バグ(不具合)が発生した際や、仕様変更の依頼があった際は各種設計書とソースを修正し商用環境へリリースする。

ウォーターフォール開発は、最初の要件定義で取り決めたこと全てを初回のリリースで納品する。

LINEで言うと「チャット」「通話」「ビデオ電話」など全ての機能を初回リリース時に提供する。

アジャイル開発とは

プロジェクトによっては省略したり逆に細かく詰め込んだりと様々ですので、あくまで一例です。

アジャイルの開発手順(初回のみ)
  • 要件定義
    • 各フェーズで開発すべきことを決める

    残りはウォーターフォールと同様

アジャイルの開発手順(フェーズ)
  • 設計
  • 製造

  • 試験
  • 商用環境へのリリース
  • 運用・保守

アジャイル開発は、上表の「アジャイル(フェーズ)」を複数回繰り返し完成へと近づける。

LINEで言うと

  • 初回リリース時には「チャット」だけをリリース
  • 次回のアップデートで「通話」をリリース
  • 次回のアップデートで「ビデオ電話」をリリース

などのように段階的に提供する。

システムエンジニアの繁忙期の1日

まず、7年間勤めてきた中で最も忙しかった日の1日をご紹介。

繁忙期の1日(在宅勤務)
  • 08:00
    起床
  • 08:30
    業務開始準備
  • 09:00
    午前業務開始

    お客様よりトラブルの相談を受け付ける
    確認の結果バグであることを認め原因究明のため調査開始

  • 12:00
    昼休憩
  • 13:00
    午後業務開始

    20時頃にバグの原因が発覚し解決案を模索

  • 22:00
    休憩

    晩飯/シャワー/歯磨きを済ませる

  • 22:30
    深夜業務開始

    休憩前に考えた解決案を基にソースの改修を行う

  • 32:00
    (翌08:00)
    休憩

    朝食や軽い運動(体操)を行う

  • 32:30
    (翌08:30)
    午前業務開始

    休憩前に実施したソース改修に対する試験を実施

  • 36:00
    (翌12:00)
    昼休憩

  • 37:00
    (翌13:00)
    午後業務開始

    引き続き試験の実施
    20時頃に試験を終えお客様に確認頂いた後、商用環境へリリース

  • 46:00
    (翌22:00)
    業務終了

    晩飯/シャワー/歯磨きを済ませる

  • 48:00
    (翌々00:00)
    就寝

  • 62:00
    (翌々14:00)
    起床

    14時間ほど寝てました

はい、こんな感じです。この日は本当に疲れました。そして、繁忙期は1日で済む事はなく一度トラブルの沼にハマると数ヶ月から1年程度続きます。上記の最も忙しい日の1ヶ月は地獄なもので、12連勤も行いました。

ここだけを切り取ると「ブラック」と思われるかもしれません。ただ、システムエンジニアは仕方ない事なんです。

Q
なぜ、SEはここまで働かなければならないのか
A

システムは業務の根幹を担っているため、システムエラーが発生するとシステムを利用している人の仕事が完全に止まってしまう。

仕事を止めてしまうと、会社の信用問題に直結する可能性があるため是が非でも対応しなければならない。

私が新卒で働き始めた直後くらいからは36さぶろく協定が存在したので、正直マシにはなりました。36協定がない時代は残業だけで100時間や200時間を軽く超えていたそうなので令和の今は改善されました。

しかし、マシになったとはいえ残業100時間を超える昭和/平成初期の労働環境を知らないZ世代の人はどう思うでしょう。多分「地獄だ」と思われるのでは?

正直、1日24時間以上の勤務は「地獄」という表現で間違いないと思いますが月30時間〜40時間レベルの残業を「地獄」と思われる方はシステムエンジニアには向かないかもしれないです。

もちろん、現場(お客様)によっては残業を全く行わない場合もあるかもしれません。しかし月残業が10時間未満の現場は稀であると思います。月の残業時間が10時間未満だった月は、新人の頃の4ヶ月だけでした。月の平均残業時間は25時間〜30時間ほどです。

逆に言えば、「これでブラックと言われるのか」「1番忙しい日でこんなもんか」と思える人はSEとして働く為の体力は持ち合わせていると思います。あとは最低限の知識さえ付ければいつからでも働けます。

最低限の知識は、学習効率(勉強の得意/不得意)によりますが約1年程本気で取り組めば身につきます

今回の記事が1人でも多くの方の参考になれば幸いです。
ここまでお読み頂きありがとうございました。

タイトルとURLをコピーしました