第二回：SEって実際どんな仕事？という話

こんにちは！

さて、二回目の今回は「SEはどんな仕事？」っていうお話をやっていきたいなと思います。
とは言っても「実際にはプログラミングよりドキュメント作成の方が多い」とか、そういった具体的な話は他の就活サイトにお任せするとして……
もうちょっとふわっとしたお話を。

まず、SEはなんだかんだでデスクワークです。
自分のデスクでパソコンに向かって仕事をしている時間が非常に多いです。
マスコミ系に就職した大学の同期の話とか聞いてると「色々なところに動けて羨ましいな―」と思う一方、「なんか……落ち着かなさそう……」と思うこともあります。
「なんだかんだで」と言ったのは、私の上司にあたる人たちを見ているとその限りではないからです。
ウチのマネージャーは先日アメリカに出張してましたし、部門長はもはやいつどこに行ってるのかよくわからないくらい色んな所に行ってる印象があります。
私は落ち着いて自分の作業 (開発・保守作業等) に取り組めています。
が、現在上司から「一年目はあまりお客さんと直接お話することはなかったけど、今後はどんどんお客さんとも話してもらうからね☆」と宣告されております。知識をモロに問われるので怖いと言えば怖いですが、その日のために勉強してる毎日です。

だから「とにかくお客さんと最初から(一年目から)話したい！！それをメインの仕事にしたい！！」っていうのであれば、SEは違うのかなと思います。

じゃあどういう人がSEに向いてるのか？
それは僕にも分かりませんが……ひとつ、確実に言えることがあります。

やっぱり、SEはモノを作る仕事なんだなってことです。

実際のトコロ、システムが動き出してもほとんど不安しかなくて、いくら入念にテストを行ったところで「見落としたところがあるんじゃないか」という懸念は消えてくれません。
だから「システムができました！やったー！」っていう単純な喜びっていうのはあまり無いのです。

そして、業務は地味なことが非常に多いです。
初めてプロジェクトに配属され、プログラミング経験が浅い段階で現実のソースコードを読んだ時の絶望感……凄まじいものでした。
一言で言って、「なんやねんこれ」です。
その後、私はかなり長い期間そのソースコードを解読することに時間を貰ってました。
まぁ、無茶振りはされなかったってことですね。

勉強すべきことはソースコードのことだけではなく、設計書の書き方やシステム全体の構造、データベースの構造など多岐にわたります。
それらをしっかり把握しないと、何も出来ないのです。

「SEって地味なだけで何も報われない仕事やん……」そう思った方がいらっしゃるかもしれません。
私もそう思ったことが何度かありました。

でも、それは間違いなんですよね。

どういう設計をすれば最適なのか。どういうプログラムならこの要求を実現できるのか。そういったことを考え、実際に組み立て、地道に積み上げてきたものが思惑通りの形になったとき……
やっぱり、少しは「報われる」んですよね。
ただの知識だったプログラミング技術や顧客の業務の知識が、顧客に直接使われるシステムの形で結実する。
無邪気にははしゃげないけれど、それでも確かな自負が生まれる。
その「自負」さえあれば、やっていける仕事だと思うんですよ。

と、まあカッコつけたことを言いましたが……
結局のところ、ものづくりは楽しいし、嬉しいのです。

企業によってはマネジメント業務が中心で、「ものづくりの実感よりも人をまとめている実感のほうが強い」というSEの方が多いような企業もあると思います。
でも、ピーアンドアイでは結構幅広く「SEの魅力」を味わえるんじゃないかな―と思ってます。
熱苦しい社員も多いですし。
……あ、これオフレコでお願いします(笑)

「熱苦しい」とはいえ、理屈抜きの精神論で無理難題をねじ伏せるようなタイプの方はいないのでご安心を。僕の印象ですが、やっぱり理路整然とした方が多いと思います。職業病ですね。

話がそれました。
今回の記事はこれくらいにしておきます。

それではまた次の記事で。
お読みいただき、ありがとうございました。