#426 システムエンジニアという仕事
いかがお過ごしでしょうか。林でございます。
私はIT業界で、システムエンジニアとして15年間仕事をしてきています。
この「システムエンジニア」という仕事、やったことある人は当然「こういう仕事ね」と理解できる仕事なのですが、やったことない人や普段システムエンジニアと関わることが少ない人からみると、具体的に何をやっているかイメージができない、と評価される仕事です。
実際に、私の両親は、おそらく私が何の仕事をしているか、未だによく分かっていませんし、説明しても「難しいからよう分からん」と言われて終わります。
また、ITシステムのメンテナンスというのは、基本的にシステムが稼働していない時間帯や、システム利用が少ないタイミングで行うので、夜間帯や正月、ゴールデンウィークなどを使って行われます。
日中帯であっても、ハードウェアが故障したり、想定していないシステムの使われ方をして不具合が生じると、復旧のために緊急の作業が入る仕事でもあり、復旧優先でいきなり残業、復旧に時間がかかるとタクシー帰り・・みたいなこともありうる仕事です。
だから、業界内でよく言われるのは、「結婚するパートナーも、システムエンジニアの仕事に理解が得られる必要があるので、同じ業界同士で結婚するパターンが多い」みたいな話です。
システムトラブルでいきなり帰れなくなったり、長期休暇に仕事が入る、みたいな生活スタイルなんて理解できない！みたいな方もいらっしゃいますからね。このような話は業界内では、あるあるの話です。
今日は、私の本業である「システムエンジニア」に関するリアルな特徴について、私なりの視点でご紹介してみたいと思います。
システムエンジニア＝理系の仕事、ではない
システムエンジニアの仕事と言えば、どうしても「プログラミング」のイメージが先行する方が多いのではないでしょうか。
いわゆる「情報系」の学部を卒業して、黒いPCの画面に、記号のような英文をカタカタとタイプしている・・という印象が強いかもしれません。
もちろん、いわゆる「コーディング」や「製造」と呼ばれるプロセスにおいては、実際にそのシステムで採用しているプログラミング言語をソースコードを書いて、それをコンパイルして（機械が理解できる命令文に変換してあげて）、ロードモジュールをデプロイして（コンパイルしたファイルを配置して、サービスとして動くようにする）、ということを行いますが、それは全体の一部に過ぎません。
下図は「V字モデル」と呼ばれる従来型の「ウォーターフォール開発」と呼ばれる開発手法を示したものとなりますが、見てわかる通り、「プログラミング」という工程は一番下の箱のところにしか出てきませんよね。
https://www.ipa.go.jp/archive/files/000004771.pdf
ちなみに「ウォーターフォール開発」とは、水が上から下に落ちるように、基本的に後戻りはせずに、要件定義→システム要件定義（基本設計）→・・・と工程を一つずつキチッと固めて終えていく開発手法です。最近では、対比されるアジャイル開発も一般的になっていますが、「プログラミング」が全体のシステム開発の中における一部である、ということには変わりません。
システム開発、特にウォーターフォール開発では、以前はよく家作りに例えられていました。どのような間取りにして、どこをキッチンにして、壁の色は何にして・・・というように、基本的には外側から設計して、徐々にドアノブはどこに付けようか、とか詳細化していきますよね。
従来からのシステムエンジニアの仕事は、このどんな家を建てるか？という構想のところから入っていくため、全体でみると「コーディング」している時間よりも、「全体の構想作り」や「必要なプロジェクト予算の策定」、一社だけで作りきれない場合の方が多いので、「別の業者と発注調整」をして、「作ったシステムが想定通り動くかの確認」など、その他の要素が大きいのです。
そこで求められるスキルは、当然コミュニケーションスキルもありますし、数字にも強くないといけないし、お客さんがふんわり持っているイメージをドキュメンテーションするスキルも必要で、プログラミングの知識以外にも色々と求められるのです。
だから、よく新入社員や就職活動をしている方からは、「私は理系でないので不安です」という声を聞きますが、それは全く問題ありません。私自身も経営学部出身の文系ですが、15年間は楽しみながらやって来れています。プログラミング＝理系、という考え方が、もはや過去のイメージの話だと理解しています。
プロジェクトベースの仕事である
もう一つの軸が、「ルーティンワークかプロジェクトワークか？」という視点で、基本的にシステム開発では、同じプロジェクトは一つもありません。
私はルーティンよりもプロジェクトワークの方が向いているのですが、それは「時限がある」ことと、「毎回違うことが起こる」からです。
私は飽き性なので、同じことを繰り返すとか、一つのものを繰り返しながら改善を図っていく、というよりも、一度ワッと力を入れてプロジェクトを完遂したら、ピークを落として休みに入り、また少し時間を置いてワッとみんなで盛り上がる、みたいな仕事の仕方が好きなのです。
もちろん、システムエンジニアの中でも、運用系の仕事など、ルーティンに近い仕事もあります。ただ、毎回異なるメンバーと集中的にあーだこーだ言いながら何かを作って、明確に始まりと終わりが区切られているプロジェクトベースの仕事が基本、というのも、システムエンジニアの特徴の一つです。
なぜシステムエンジニアになったのか？
私がなぜシステムエンジニアの仕事を選んだのかというと、「文系でありながら、プロジェクトベースのモノづくりができる」と考えたからです。
それこそ、例えば食品メーカーのR&D部隊のイメージは、理系的な専門性が求められるイメージが当時あったのですが（これも、SEと同じで実態は違うのかもしれません）、システム開発であれば、文系出身でも「モノづくり」が出来る！と感じていました。
私が新入社員研修の最終日に、「システム開発は、ピラミッド作りに似ていてワクワクします」と話したのを未だに覚えていますが（ピラミッド作りなんてやったことがないのに笑）、チームのみんなで石を積み上げて、「いや、遠目でみると、この石歪んでないか？」みたいにあーだこーだ言いながら、大きなものを作り上げる、みたいな仕事なんですね。
私は高校時代の学校祭の時に、「作り物班」のリーダーとして1〜3年生の50人近いメンバーと一緒に巨大カメレオンを作ったのですが、みんなであーだこーだ言いながら、一つの良いものを作り上げる、みたいなことが好きだったのです。
システム開発の仕事はそれに近いものがあり、それは今でも感じています。
また、大学時代に専攻していた「人的資源管理」の分野では、人のモチベーションやリーダーシップ、マネジメントに関する研究でした。本質的には「どうしたらHappyに仕事ができるのか？」というのがゼミの先生の研究テーマで、システム開発は、分かりやすい「チームで何かを作る」仕事なので、このチームメンバーが楽しく仕事するには？という自分の好奇心にも合致した仕事でした。
今日はライトに、私の本業であるシステムエンジニアの仕事についてご紹介しました。どなたかのご参考になれば幸いです！
いいなと思ったら応援しよう！
