あんたの仕事はどんな仕事なんだろうね？

俺の仕事はシステムエンジニアなんだよ。
そう言うと、あんたはどんな印象を持つかね？

パソコンに向かってゴチャゴチャ色々するヒト？
なんかシステムを作るヒト？

まあ、あっている。
じゃあ、具体的にどうやってシステムってこさえているんだと思う？

なに？そんなのプログラムを組むに決まっているでしょって？
そいつはたしかにその通りなんだが、システムエンジニアはほとんどプログラムを組むことが無い。

ふへ？
なにそれ。そんなの漁師が釣り竿を使わないって言うようなもんじゃないって？

そうだよなぁ。
ってことで、今回はシステムエンジニアって仕事の実態を改めて整理してみようって回だ。

まあ、世の中のすべてのシステムエンジニアがそうだってわけじゃあないんだけれど、ちっと付き合ってくれよな。

システムエンジニアの仕事の流れ

まあ、会社に新入社員として入ってきた頃の俺も同じようなイメージを持っていた。
システムエンジニアってのはパソコンだのサーバーだのを駆使してお客様が便利に仕事するための仕組みをプログラムする仕事なんだってね。

確かにプログラムを組む経験ってやつは必要なんだ。
実際問題、この仕組でこう動くわけだからこの処理があれば成立するって確証を持つためにはプログラムを組んだ経験ってのが不可欠だからね。

なので、新人時代はプログラムを組む経験を徹底的に積まされるんだよね。

設計工程をこなす

ところが、実際にプロジェクトを小規模でも任されると、実際のプログラムは協力会社のヒトたちにお願いすることになる。
じゃあ、オマイは何をやっとんのじゃって？

俺たちシステムエンジニア、特に俺のようなフィールドエンジニアと呼ばれる種類のシステムエンジニアはお客様と「どういう仕組にするか」を考えて設計に落とすって作業をする。

つまり、お客様がどういう様に仕事をしていて、その仕事のどこに不満があって、その不満をどうやったら効率化出来るかって考えるわけだ。

まあ、最近では不満を効率化だけでは仕事にならないから、場合によってはお客様の業務の無駄を逆に探したりもする。
それくらい、すでに多くのお客様ではITが浸透していて効率化はすでに成されている状態だったりするんだよね。

で、そんな風にお客様とのコミュニケーションを図りまくって、その求められている仕組みを設計という形で具体化するってのがフィールドエンジニアの主な仕事なんだ。

テストに向き合う

で、設計を実際にプログラムを組んでくれる協力会社さんに渡した後は、今度はテスト計画づくりがフィールドエンジニアのお仕事だ。

その設計がキッチリプログラムで出来ていることをどうやって確かめるのかっていう、計画。
コイツがちっとわかりにくいかもしれないな。

テストってのは出来上がってきたプログラムにどういう値を入力するかってのを具体的に示したテスト仕様書ってのを作るんだけれど、その前にそのテスト仕様書がどういう観点で作られるべきかっていうテスト計画ってやつを練り込むんだよね。

そうすることでテストをどういう観点でやるかっていう網羅性を担保しつつ、具体的なテスト仕様書がその観点を網羅しているかってことをチェックするためのバイブルになったりもする。

後はテストは様々な環境を使い分けて行っていくんだけれども、その環境をいつどこで用意しなければならないかっていうようなスケジュールも調整するんだよね。

で、テスト計画書とテスト仕様書が出来たらそれを協力会社さんに説明して実際のテストをやってもらうってわけだ。

で、テストの結果が出始めたら今度は品質分析。
実際にそのテスト結果は「キチンと間違いを検出できているか」を確認する。

この辺もピンとこないかもしれないな。
テスト結果で「プログラムのバグ(間違い)が0でした」って結果が出たとするじゃんか。
そうすると俺たちシステムエンジニアは「ではテストの品質に問題があったんじゃないか？」って疑いを持つんだよ。
ヒトは必ず間違いを一定確率で起こすって前提でテスト結果を眺めるんだよね。

展開作業で四苦八苦する

でようやくシステムが出来上がって今度はそのシステムの展開作業だ。

いわゆる業務システムがWEBベースの場合はこの展開ってのはあまり検討する要素が無いんだけれど、クラサバだったりPOSのような特別な機械を現場に配置する必要があったりすると、途端にこの展開作業は複雑怪奇なものになる。

全国に3000台のPOSレジを展開して、そこに最新のプログラムを導入するってだけでも、「ネットワークの帯域は大丈夫か？」とか「そのプログラムを提供する前にこのプログラムが適用されていないとマズイ」とか、もうパズルみたいなことが起きる。

保守で新たな要件を引き出す

で、いよいよ本稼働した後は、今度は保守だ。

稼働後にもバグが発見されたり、考慮していない使われ方をしてシステムが異常になったり、新しい業務に対するヒアリングをしたり、一言で保守といっても、その内容は多岐にわたる。

中でも、お客様の業務と向き合ってさらなる提案要素を引っこ抜くってのが一番大事なことかもしれないね。

新人時代に教わったこと

ここまで見てきて、システムエンジニアって考えてばっかだなってあんたは思うかい？

まあ、そうなんだよ。
で、その考えるベースにあるもの。
それがコミュニケーションなんなんだよね。

お客様とのコミュニケーション。
協力会社さんとのコミュニケーション。
上司とのコミュニケーション。
同僚とのコミュニケーション。

新人時代に先輩に言われたんだよ。

「システムエンジニアは文系の仕事だから」

確かに、これだけのコミュニケーションを成立させるのは文系の方が得意かもしれないなってマジで思ったりもするんだよね。

なあ、あんたはどうだい？

あんたの仕事、俺たちの想像と違うところがあったりするかい？