IT総合企業の社内SEの男性の体験談

性別
年齢 28歳
社内SE歴 3年半

持っている資格
基本情報技術者、TOEIC 770点

働いている企業の業種
IT総合企業

私はエンジニアとして大学院卒で入社し、今年で4年目になります。会社の業種はIT総合企業で、そこそこ大きな会社です。福利厚生等もそれなりに充実しており、一般的には大企業といっていいでしょう。
配属された先は「サービス開発」を行う部署で、一般的な社内SEとは少し毛色が違うかもしれません。

今回はその「サービス開発」について、そして自社で見る他のSEとの違いについて、自分の体験談をお話したいと思います。

サービス開発のエンジニアとは何か?

一口に「SE」といっても様々な仕事があります。

ここでは、SIerのSE、社内SE、サービス開発のSEの3つを見てみましょう。ざっと特徴を挙げると、以下のようなものに落ち着くかと思います。

  •  SIerのSE:開発の主体はクライアントで、ユーザーはクライアント又はエンドユーザー
  • 社内SE:開発の主体は自社で、ユーザーも自社
  • サービス開発のSE:開発の主体は自社で、ユーザはエンドユーザー

開発の主体というのは、開発に関する意思決定を行う権限がどこにあるかを意味しています。

開発の主体が発注者のクライアントになる場合、クライアントの都合によっては無茶な要件やスケジュールを突きつけられることも多く、私も大学時代にSIerの知人からそういった話はよく耳にしていたので、SIerへの就職というのは最初から考えていませんでした。

一方で、開発の主体が自社にある「社内SE」と「サービス開発SE」は、ある程度自社の都合で開発を進めることができます。
社内SEとサービス開発SEの違いはエンドユーザで、前者が社内に閉じたものであるのに対し、後者は実際のエンドユーザが利用します。

このため、現場ではエンドユーザとのやり取りも当然ながら発生してきます。サービスはエンドユーザの声を聞きながら改善されていくため、そういった意味では「サービス開発」は、SIと社内のちょうど中間に位置するような仕事かもしれません。

IT系の資格は持っておいたほうが就職に有利なのか?

私は大学院で就活を行い、今の会社に新卒で就職しています。とはいえ、持っている資格は基本情報と運転免許程度と、他の人に比べても大したものはありませんでした。

新卒において専門職の資格が重視されることは殆どありません。
私は入社後しばらくしてエンジニアの新卒採用業務(リクルーター)にも携わりましたが、私の会社のエンジニアの新卒採用では、資格よりも論理的思考力や会話力といったポテンシャルを重視していました。

転職でいうと、最近私の隣の島に転職してきた人も、目新しい資格は持っていませんでした。ただし彼には、前職における実績という強力な後ろ盾がありました。

つまり、新卒でSEになる場合にはポテンシャルを見られ、転職でSEになる場合には実績とスキルを見られるわけですから、IT系の資格は(少なくとも私の会社では)必須ではないといえます。

むしろ大切なのは、後述の「語学系の資格」だったりします。

語学力は絶対に持っておくべし

「IT系の資格は入社に影響しない」と言いましたが、一方で語学力は入社前・入社後ともに大きく影響してきます。

私の会社ではグローバル人材育成プログラムというものがあり、海外のパートナー会社において高待遇で仕事をする機会が与えられています。このプログラムを経て帰ってきた人は、ほぼ最速で昇進するため、未来が約束されているといっても過言ではありません。

ただしこのプログラム、私の会社では選抜が非常に難関なことで知られています。基礎的な部分として、TOEICが900点を越えていないと落とされます。
その上で、本人の人柄やCDPなどを考慮して選抜が進んでいきます。

「別に海外興味ない」という人も、語学の波からは逃げられません。私の会社では、海外グループ会社が開発したソフトウェアを引き継いで開発することも多く(その逆で、海外に発注することも)、その際には膨大な量の英語のドキュメントを読むことになります。
これが理解できないと、業績への評価に響いてくることは言うまでもありません。

ちなみに私の英語力は中庸で、システム系のドキュメントであれば何となく読める、程度でした。残念ながらグローバル人材からは外れていると思います……。

入社後の初仕事はマニュアル作りから

さて、そんな感じで4月に入社し、退屈な新人研修を終えた7月頃、私に辞令が下ります。それは、自社サービス開発業務でした。

開発系の仕事は学生時代から個人でやっていたこともあり、「よし!ここは一発腕を見せてやる!」と息巻いていました。しかし実際にアサインされた仕事は「マニュアル作り」

マニュアルなんて派遣さんにでも作らせれば良いじゃないか……なんてことも思いつつ、渋々取り組むことにしました。

しかし、このマニュアル。自社のサービス利用マニュアルなだけあって、マニュアルを作るには、自社サービスをしっかり使い込まないといけないのです。
そして、その自社サービスが非常に使いづらい! そんな奮闘の様子を見ていたのか、先輩が言ってくれたセリフがあります。
「お客さんも同じように感じているんだよ」と。
当時の私には「どうしてこんなに使いにくいものを作ったんだ」という感情しか湧きませんでしたが、後になってこの言葉が実感を伴って身にしみてきました。

使いやすいサービスを作らないと、ユーザーは離れていく。そんな当たり前の事実を、この「マニュアル作り」というプロセスが教えてくれたのです。

保守できないアプリケーションを作ってしまった

そんなわけで、マニュアル作りも落ち着いた頃、上司から新しい指示が下りました。

「既存サービスのサポートに使うWebアプリケーションを、君が主導して作ってほしい」というもの。
作ったマニュアル等の掲載をはじめ、お客様からの問い合わせも受け付けるWebアプリケーションです。

これこそ私の待ち望んでいた瞬間!
そんなわけで、Railsを用いてバリバリコーディングを進め、上司も驚くスピードでアプリケーションが仕上がりました。

ところがこのアプリケーション、致命的な欠点を抱えていることが明らかになりました。

それは、自分の部署でRailsで触れる人間が少なかったということ。
私の会社はもともと通信関係の下請け+SIで成長してきた会社なので、回線系のスキル(VoIPとかスイッチとか)と業務アプリ系(VBとかVC++とか、よくてPHP)のスキルを持った人は多いものの、Webアプリケーション系のスキルを持つ人があまり居なかったのです。

結果的に、Railsで作ったサービスはそのままリリースされたものの、バージョンアップ作業などの改良が施せるのはチーム内で私一人だけ。後に別な人をアサインされるまで、孤独なPDCAを回すことになったのです。

「会社における開発」と「個人での開発」は全く異なるという、当たり前の事実を痛感させられたPJでした。

社内システムとの連携はとても辛い

そんな反省も踏まえつつ日々の業務を続け、気づけば二年目社員に突入した夏。今度は「現行サービスの顧客DBを社内顧客DBと連携させる」という業務をアサインされました。

その頃、社内では共通系システムをなるべく一つに寄せることで、管理コストを削減する施策が行われていました。元々は独立して顧客DBを持っていた私の部署のサービスも、この波によって全社共通の顧客DBを用いることになったのです。

しかしこの「全社共通の顧客DB」は、とんでもないパンドラの箱だったのです。

まず、DBに繋ぐためには閉域接続が必要で、データは一日一回のバッチ処理、APIが無くて特定のデータをPOSTする……挙げればキリがないのですが、びっくりするぐらい使いづらいシステムでした。

結局、運用中のサーバにNICを二つ持たせた上でWeb側、閉域側双方のNWを整え、サーバも何台か増設、プロキシにつぐプロキシで疎通を確保、バッチ処理失敗時のエラーハンドリング等を大量に書く……などなど、色々と遠回りをして要件を満たしていきました。

更に、「現行サービスのDBでは持っていた情報が、社内DBだと持てない」ということも判明。
社内システム側にシステムの改良をお願いし、それだけで2ヶ月弱待たされるなんていうトラブルも発生。このあたりは大企業の悪しき風習が滲み出ている気がしますね。

他システムとの連携・結合は往々にして泥沼といいますが、このPJもご多分に漏れず泥沼だったように思います。「触っちゃいけない社内システム」が私のスローガンになってしまいました。

お客様も社内も喜ぶサービス開発を目指して

そして入社から3年目の春。今度はいよいよ「新規サービスの開発主導」という業務が回ってきました。何かと手動運用が多かったり、使い勝手が悪いと評されていた既存サービスを一新し、同じユーザー層にリーチする新しい自社サービスを立ち上げることになったのです。

このサービスでは、企画、要件定義、基本設計、開発、運用まで一通り携わることができるとのことだったので、ここまでで学んだことを色々と詰め込むことにしました。

まずは「マニュアルの撤廃」です。
新入社員の頃サービスのマニュアル作りをさせられましたが、よくよく考えると「マニュアルを読まないと使えないサービス」は、UX(顧客体験)上好ましくありません。マニュアルを読まなくても使えるサービスこそ良いサービスなので、チュートリアル等を画面内に組み込むことで、初めてでも使えるサービス作りを心がけました。

次に、開発言語。これは、社内でも使える人の多いPHPを中心に採用。今後のアップデートもどんどん回していけるように配慮を行いました。

ユーザー管理については、例の社内システムとの結合は避けられませんでしたが、あまりにも使いづらすぎる社内システムを触らずに済むよう、そのフロントエンドとなるアプリケーションを開発することで、ユーザー情報の参照や管理を簡単に行えるようにしました。

ベータ版としてリリースされたこのサービス(今後正式サービスイン予定)はお客様にも社内にも好評で、お客様からは「UIが分かりやすい」「次に何をすればいいか分かりやすい」、社内からは「管理しやすい、アップデートしやすい」といった声を貰うようになりました。
こうした業績がきっかけとなり、入社4年目の面談では、私の給与グレードが一つ上がることにもなりました。

さいごに

ここまでで色々な開発業務を紹介してきましたが、こういった業務に携わる中でも、実は私の残業時間は月あたり20-30時間程度(1日平均1-2時間残業)と、業界の中ではかなりホワイトな部類に入ると思います。

サービス開発というのはやりがいのある仕事です。

お客様からは直で感想が貰えますし、それを改良していく機会にも恵まれている。開発の主体は自社にあるので、どんどん新しいことにも挑戦していくことができる。

その割には、自社でスケジュールを立てて開発を行えるのでデスマーチにもならない。色々なSEの中でもかなり好条件な仕事なのではないでしょうか。
これからエンジニアを目指したいと思っている方、エンジニアの中で職種転換をしてみたいと思う方は、ぜひ「サービス開発のエンジニア」というものにも、目を向けて頂ければ幸いです。

コメントは受け付けていません。

サブコンテンツ

このページの先頭へ