35歳以下お断りのＳＥ業務というのがある
»
世の中、35歳以下お断りのＳＥ業務というのがあると思います。
え！？エンジニアは35歳で定年じゃないの！？
などと思った方はきっと若い。
それはどんな業務かというと、ズバリ「保守系業務」です。
『なんだ、保守か。つまんねー。』
と思うなかれ。保守にもいろいろあります。
よくエンジニアの求人情報サイトとかに載っている保守エンジニアというと、だいたいこんなお仕事です。
障害が滅多に起きない大きなシステムについて、まず3ヶ月間ほど仕様書をしっかり読み解いて、次の半年間で先輩と一緒にサポートをし、次第にシステムの思想やクセなどを知り、2年、3年経ってやっと一人でなんでも対応できるようになる、というか誰に何を聞けばその正解が聞けるか、が分かるようになる...。
基本的に常に暇。緊迫感とはほぼ無縁。自分が売上に貢献しているかどうかも分からない。
しかし、私が今回取り上げたいのは、そういう本物の保守エンジニアの話ではなく。
■攻めのSEに足りないもの
うちのようなフルスクラッチの受託開発をやっていると、攻めのＳＥはみんな、営業やって仕様詰めやって設計やって製造やって、、という業務をやってます。
ここにもベテランＳＥはいますが、若いＳＥ向きの仕事も多く、業界一般的にはこのフィールドで働きたい方が多いようです。
しかし、彼ら攻めのＳＥに足りないものがあります。
それが保守系業務への意欲・モチベーションです。
たとえば、あるシステムが完成して、もう何年も運用フェーズに入っているとします。
普段は何の音沙汰もないのですが、時折来る質問メールに対応したり、データがおかしくなったので裏から直して欲しいと言われたり、ハードディスクが壊れてサーバが完全にダウンしてしまい、タクシーに代替機を積んでデータセンターまで急行したり。。
こういう地味な仕事を嫌がる人がかなりいます。
でも一定の数で、この保守系業務を厭わないＳＥというのが必要です。これは本当に痛切に感じます。
実はあまり知られていませんが、開発会社の中には、保守を受けない会社も多いです。
・もう俺たちは前に進むしかない
・申し訳ないですが古いシステムは面倒見切れないので頑張って工夫して使っていってください
・お電話いただいたときに、分かる人間が居れば答えられるかも知れませんが期待しないでください
みたいな。
「この案件は手離れがいいかどうか」
こんなテーマが営業会議の中で語られるような会社は珍しくありませんし、それも一つの経営戦略だとは思います。
ただ、弊社はそうではなく、保守を受けながら信頼関係を積み重ねて次の開発案件をもらおう、あるいは別のお客さんを紹介していただこうというスタンスです。
その時に保守を受けられるＳＥがいないというのが、地味にかなり困ります。
専門の営業職を抱えていない弊社にとっては、保守こそが大きな営業力だったりするのです。
■なんでこんなんなってるのよ...！？
かくいう私も人が作ったシステムというのはあまり好きではありません。
システムのリプレースのお仕事を頂いたりしますと、古いシステムのＤＢ設計や挙動を解析しますが、頭が痛くなることがあります。
「なんでこんなんなってるのよ...ｲﾀﾀ」
と。
でも、この場合は、リプレースのための解析なのでまだいいです。
そのシステムを今後も使い続けていく前提の、他人が作ったシステムの解析はかなり辛いです。
そういうことができるＳＥというのは、ある意味相当のタレントです。ただ残念ながら巷ではあまり評価されていませんね。
そういえば「なんでこんなんなってるのよ」と最近思ったシステムにこんなのがあります。
それは企業の納品から請求、入金までを管理するシステムでした。
ちょっとマニアックな話になりますので、興味の無い方は、
GoTo Esc_Line
としておきますので、そこまでジャンプしてください。(と若いWEB系プログラマには馴染みの薄い話を織り交ぜておきますｗ 今回は35オーバーの保守系SE向けの記事なのでどうぞよろしく。)
まず、その会社がお客様に商品を納品すると納品伝票というのを立てます。
その段階ではいわゆる掛け売りの状態で、それを月一回のタイミングで締めて、請求書を発行します。請求書を発行すると対象となった納品伝票に「請求済フラグ：1」が立つという仕組みです。
ここまでは、問題ないというかよくある仕様なのですが、このシステムの問題はその納品伝票レコードに請求書のIDを持っていないことです。
無くても業務は回ります。
ただし、請求書を何らかの理由で削除しようと思うと、それに関連づけられた納品書の「請求済フラグ」を0に戻すのが非常に困難です。
そこでどうやっているかというと、過去に発行した請求書の削除ボタンが押されると、その請求書発行日より前に入力された納品伝票を探して、日付の新しいものから金額を合計していき、請求書の金額と合致したらそれらが対象となった納品伝票と推測し、フラグを0に戻すということをやっています。
合致しないまま金額がオーバーすると「対象となる納品伝票が特定できないので請求書が削除できません」というエラーになってます。
相当にクソな仕様です。
「どこの会社がこんなシステムを組んだんだよ！」
と思いますが、そのシステムの設計者は実は私でした（爆）
10年くらい前に設計したシステムで、確かにこれは酷い仕様です。
ただ、絶対におかしいかというと、ほんの一抹の苦しい理由がありました。それは、その会社では請求に対する入金がないときに次の月の請求に未入金項目として、すでに請求した納品書をつけることがあるので、納品書：請求書がＮ：Ｎになることがあるからです。
なので、納品伝票テーブルに一意の請求書IDがつけられない。。。ような気がしたのだと思います。たぶん。。
もちろん今ならそんなことはしないのですが。
Esc_Line:
■年齢を重ねて、開く能力がある
と、こういう先人の残した負の遺産を「なんでこんなことになってるんだよ」と思いつつも引き継いで、保守サポートをしていく、というありがたくもプロフェッショナルな仕事というのが、世の中にはある、ということです。
これがですね。
ぶっちゃけ、若いエンジニアには難しいのではないかと思うのです。
オーバー35くらいからではないでしょうか。システムの酸いも甘いも嗅ぎ分けて
「こういう変な仕様もあるよね...」
と、悟りを開いて対応できる能力は、10年くらい業界でやっていないと無理ではないか、と思われます。
実際のところは、ここまで変な仕様はあまり無いですが、すべてのシステムはなんらかのおかしな箇所があるものです。
システムは完璧な美を求めるものではないです。
システムはアートではなく、限られた予算と納期と能力の中で作られる妥協の産物である！
と、こんなことを聞いて、すとんと腹に落ちる方。
そう、あなたなどはもしかすると、保守系エンジニアに向いた類い希なる逸材かも知れません。
なんだか最近求人の話かベトナムの話しかしていませんが、以下の10個の項目中、5個以上にYESと答えてしまう人は、是非プラムザへの転職を検討されたし、です。
[1] 人の話は基本的にリスペクトして聞くことができる。
[2] わりと退屈な時間が苦にならない。
[3] 一方で24(トゥエンティフォー)が好き。あの一分一秒を争う緊迫感に痺れる。
[4] 問題の根本原因に鼻がきく。
[5] 鼻と言えば、自分の得意分野のことを説明するとき、つい鼻の穴が膨らむ。
[6] ダメな定食屋に入るとどこが拙いのかつい分析してしまう。
[7] どちらかというと技術よりも業務に興味がある。
[8] DBチューニングやシステムリファクタリングに萌えを感じる。
[9] どんな言語でも、作ることはできなくても、読むことはできそう。
[10] 今、残念なことに会社からリスペクトを受けてない。
株式会社plumsa(プラムザ)では、AWSの運用保守サービスも提供しています↓