サーバーワークスの社内SEが、自分の部署についてワークスタイルとかキャリア選択的な魅力とか雑多に語ろうと思う - サバワク

f:id:sabawaku:20201010174858j:plain

　こんにちは。サーバーワークスのPE (Process Engineering) 部 PE (Process Engineering) 課という部署で社内SEをしています橋本と言います。

AWSのパートナー企業としてSIer稼業やMSP（いわゆる運用サービス）を中心事業として展開している当社ですが、PE課はそのメインストリームから少しだけ外れて社内の業務改善やそれに関わる機能開発等を主業務としています。私もその例に漏れずよろず業務改善を軸にやってます。あとMSP基盤サービスの保守や新規開発なんかも手掛けてます。

なにかと目立たないし、華がないイメージ（※偏見です）の社内SEですが、私は自分のキャリア選択としてはサーバーワークスのPE課に所属していることにそれなりに満足しています。

　今回の記事ではサーバーワークスの社内SEって結構いいところなんだぜ、ということをアピールしてみようと思います。脚色は好みませんので、できるだけ正直に今の心境や見解を述べていきたいと思います。

もし興味が湧いたらぜひ当社の採用説明会にお越しください。お話しましょう。

はじめに
サーバーワークス社内SEの魅力
サーバーワークス社内SEのイケてないと思うこと
業務内容
おわりに
- p.s. 社内のエンジニアメンバーへ

はじめに

　魅力に感じている点を説明する前に、最初に私のキャリア観を簡単に書いておこうと思います。その方が魅力とするポイントの背景が伝わりやすいと思いますので。少々ポエミーですがどうかお付き合いください。

エンジニアとしての市場価値を高めようと考えたとき、色々武器になりそうなものは思い浮かぶと思います。特定の技術スタックへの強みでも良いですし、運用や開発の経験値、マネジメント、特定ドメインの専門知識、などなど色々とあるでしょう。

ただ、これだけ変化が激しい時代ですし、ひとつの武器だけで生き残っていくのはかなり厳しいように思います。AWSを始めとするクラウドの分野は少なくとも当面の需要が減ることはないと思いますが、クラウド自体がこれだけ普及してしまった今では「AWS知ってます！」だけでは少々市場価値に乏しいだろうとも考えています。

私個人は、AWSがある程度わかることを前提として、運用を軸足にしつつ開発もやれるエンジニアでありたいと思っています。ただ、それでもまだ自分の市場価値としては不足があるとも感じています。

　1つのキーワードは「お客様の言葉で喋れる」ことだと考えています。システムは利用者がいて初めて価値を生み出すモノなので、社外だろうと社内だろうと、利用者たる相手の言葉で話せないエンジニアが活躍できる場はそう広くないだろうと。作業ができるだけならオフショアのような安い選択肢がありますしね。

今後どのようなキャリア選択をするとしても、価値あるエンジニアを目指す上ではソフトスキルを鍛えていくことが極めて重要だろうと思ってます。その先のプラスアルファとして、特定ドメインへの知見などがミックスされると良い塩梅なんじゃないでしょうか。

あと、お金はたくさんほしいですが、同じくらい会社の文化やその会社に勤務するライフスタイルが自分にフィットしていることは重要だと考えています。生活上、肌が合わない場所にいても消耗していくだけだと思うので、ちゃんと仕事してる時間も含めて人生コントロールしていける生活が幸せやと思います。

...さて、もったいつけましたが、上記のような前置きを前提にサーバーワークスの社内SEの魅力を説明しようと思います。

サーバーワークス社内SEの魅力

　端的に言えば、サーバーワークスの社内SEというポジションの魅力は

自分の考えるキャリア選択の方向性にかなりマッチする経験ができる
サーバーワークスならではの「働き方」の柔軟性が自分のライフスタイルにマッチしている

これらの2点に集約されます。

様々な業務ドメインで、エンドユーザーと深く関われる

SI事業は基本的にモノを構築して商売する稼業ですので、お客様のエンドユーザーや、彼らの実業務の中身にまで密接に関われる機会はそうありません。MSP...運用サービスにしても同じで、基本的にはお客様の保守担当者がカウンターになることが多いです。なので、利用者側のリアルな世界まではなかなか見えづらいことが多いでしょう。

サーバーワークスの社内SEは、基本的に案件のほぼすべての工程にコアメンバーとして関与することが求められます。コアスキルとなる開発だけでなく、その前段の要件ヒアリングなど裁量を期待されるシーンはたくさんあります。当然、エンドユーザーにあたる他部署の方とも会話する機会が多くあります。

　業務改善プロジェクトの失敗例として、

「とりあえずで自動化を導入してみたものの、実際には現場の業務フローにフィットせず、かえって負担が増えた・業務の柔軟性が失われた」

みたいなことが、割とよくあるのではないでしょうか？（私も運用サービスの現場オペレーターをやっていたことがあるので、この類のフラストレーションは痛いほどわかります）

これって結局、かけた労力に対して価値が見合ってないんですよね。開発すること自体が高度で労力も要する業務なので、開発だけに非があるとはとても言えませんが...いち技術者としては、ただただもったいないなと思うのです。

そういうことを避けるためには、どうしても利用者である他部署の業務をできるだけ深く理解する必要が出てきます。プロジェクトスコープになっている業務の現行作業手順は通読しますし、関連する既存業務システムの仕様把握もやります。業務を硬直化させずに、かつできるだけメリットと労力が釣り合うように、改善プロジェクトのスコープやアプローチを決めていくことになります。

また、着地点を探すためにどうしても対話が必要になります。今の私のコミュニケーションスキルではなかなかうまくいかないことも多いですが、相手の世界の言葉でしゃべる、という必要性を意識させられることが多いです。

まとめると、「利用者の立場に深く立ち入ってエンジニアリングを遂行する」という経験ができる部分に魅力を感じています。

ちゃんとAWSの最新情報もキャッチアップできる

　たとえ社内システムであろうと、何かしらシステムを実装する場合はインフラは全部AWSです。

※もちろん、例外もあります。サードパーティ製品が絡むこともありますし、案件によってはサードパーティのみである場合もあります。Salesforceとか。まあ、要はケースバイケースなのですが、作り込みが発生する場合のインフラは基本AWSを使っています。

システム構成に自由度がある場合、そこの決定はほぼほぼエンジニア側の裁量なので、案件内容によってはサーバーレス構成の設計・開発なんかもやれたりします。基本は保守まで含めて私の仕事ですので、運用の世界もちゃんと見られるのがいいですね。

また、当社は社内コミュニケーションツールとして Slack を使っています。基本的に当社の Slack は「オープンなコミュニケーションを」というモットーで運用しています。そのため、他部署（特にインプリチーム）の会話が見られるのも良い点だと感じています。

"#tech" というエンジニアのためのQ&Aチャンネルがあるのですが、このチャンネルをよくウォッチしています。個人ではどうしてもキャッチアップ可能な範囲に限界があるので、こうしたオープンなチャンネルの存在は自身の知識を蓄える上で非常に有用です。

私の業務はインプリチームの人ほど広くAWSサービスを触る機会はないですが、それでも AWS 認定試験の DevOps Pro を更新できる程度には AWS のことはキャッチアップしています。それは Slack のやりとりなどで日常的に AWS の知識を吸収できているからだと断言できます。このあたりは当社の事業性質や、文化の性質からかなりいい影響をもらっている気がします。

働き方の柔軟性が高い

　もともとリモートワークは積極的に推進していた当社ですが、コロナ禍の影響により原則在宅勤務のお達しが出ています。

sabawaku.serverworks.co.jp

　私は基本的に出社派だったのですが、在宅勤務に切り替えても業務的な支障はほぼありませんでした。業務内容的に絶対出社が必要なものがなかった、というのを前提にした話ではありますが...

最近は在宅勤務の環境をできるだけより良いものにすべく工夫するようになりました。仕事とプライベートがうまく共存して、以前よりもむしろ快適に生活できているという実感があります。

私の平日の過ごし方の一例を紹介してみます。なお、当社は 10:00 - 19:00 定時で基本裁量労働の勤務形態です。

09:30 - 10:00 起床、朝の身支度

10:00 - 13:00 業務

13:00 - 15:00 昼食、散歩、シャワー、昼寝

15:00 - 19:00 業務

19:00 - 20:00 夕食など

20:00 - 21:00 業務

21:00 - 読書、プライベートの開発タスクなど
（計 8h 勤務）

昼休憩でがっつり 2h とってるのがわかると思います。これくらいがっつり休憩するとだいぶリフレッシュできますね。出社しているとなかなかこうはできません。どうしても集中が続かない日もあるので、そんなときはちょっと席を外して仮眠したり、最近始めた趣味のギターを掻き鳴らしてみたりします。

こういうことが気軽にできるのも、在宅勤務 × 裁量労働の良さだと思います（やることはやってます）

もともと私は規則正しい生活が極度に苦手な人間なので、こういう生活スタイルが性に合っているんだろうと思います。勤怠の規律が厳しい会社だとたぶん許されないだろうなとも自覚していますが、、、働き方を柔軟に選択できる今の当社はとても気に入ってますし、生きやすく感じます。

感覚としては、仕事とプライベートの境界がなくなってきたように思います。私生活と仕事をハッキリ区別したい方もいらっしゃるでしょうからそこは各人の好み次第でアレンジしてもらえれば良いのですが、私としては仕事も生活の一部だと捉えているので今のところはこのスタイルが快適かなぁ、と感じています。

このような生活が（今のところ）成立しているのは、顧客のフロントに立つことが少なく、ミーティングもある程度時間をコントロールできる立場だからこそ、という側面もあります。そのへんの時間が自由に組み立てやすいので、そこは社内SEでよかったなーなどと思ったりもします。

サーバーワークス社内SEのイケてないと思うこと

良いところばかりじゃフェアじゃないのでこのへんも正直に書きます。とはいえネガティブな内容をつらつら書きたくもないのでさらっといきます。

スキル向上はほぼ自助努力

　メンバー少ないし手掛ける案件の種類も人によって本当に色々なので、インテグレーションの部署と比べて相互扶助的なスキルアップがやりづらい感じはします。

「下手なプログラマを100人雇うより、腕のいいプログラマを少数雇ったほうが生産性が高い」みたいな話はよく聞くと思いますが、私も全く同じ考えです。組織だててスキルアップに投資する時間を確保して、みんなで「腕のいいプログラマ」になればいいじゃん！と個人的には思うのですが、自分たちの開発スキルに投資する時間をチームとして確保しづらいのがフラストレーションに感じることはあります。

成果を出すために「生産能力の向上」に投資するのってごく自然に効率的な判断やと思うので、そのへんチーム全体としてできることがあればいいよなぁと思ってます。

まあ、許容できないレベルで不満が募れば出ていくだけですし、自助努力するための時間は確保しやすいポジションなので深刻には捉えていません。それに、大前提として私＝会社員は成果を出すために雇われてるわけなので、そこに過剰に期待する気もないです（だいじ）。

守備範囲広い、人少ない

　個人のアサインレベルではある程度的が絞られるように調整してもらってますが、それでも守備範囲は広いです。

サードパーティを含めた社内システムについて、システム自体の理解はもちろん、業務上の運用ルールとかも当然に理解の範疇として求められます。システムの仕組みだけじゃなく運用している現場の業務理解も要求されますので、覚えること・考えることは多いんじゃないかと思います。

社内ツールの運用ルールなんかはドキュメントされているものもそれなりにありますが、口伝で引き継がれたりするものもあります。そして、単純に一発で理解しきれるほど内容が浅くない。。。

このようなトピックが複数あるので、キャッチアップコストはかかります。複数テーマで案件を受け持つので、一度離れたら戻ってくるのが大変に感じることはよくあります。人が増えて部分的に専任制が導入されたりすれば変わるのかもしれませんが...まあ、そういう日は当分来ないでしょう。会社が発展してるうちはいつだって人手不足が続くものだと思います。

守備範囲の広さはそのぶん自分の裁量が広がるということでもありますので、この点に関してマイナス感情はありません。今のところ、業務の合間を縫って社内勉強会を開いたり、プライベートの時間で勉強したりといった心身の余裕を確保できる範囲で働けていますので（だいじ）、今ぐらいが丁度良い具合なんだろうと思います。

社外のお客様との対面がない

　機会がないわけではないんですが、よっぽど意識的に作りにいく必要があります。受け持つ案件によってはノーチャンスです。社内SEなのでしょうがないですね。

とはいえ、たまには矢面に立ちたいですね。中ばかり見ていると世界が狭くなるので、定期的に外を向いていたいなというのは感じます。

業務内容

　参考までに私が関与した／している案件をご紹介します。詳しくは書けないので概要だけ。

関心を持ってもらえると嬉しいです。

MSPサービスの基盤システムの改修、機能開発

主力事業であるMSPの基盤システムとして、アラート通知等をチケット管理システムに連携したりする内製プロダクトがあります。それの保守やサービスの機能開発を最近手掛けています。まだ引き継いで日が浅いので、全容は掌握しきれてません・・・。

　ごく最近ではコールセンターのサービスである「Amazon Connect 」を組み込んだ機能開発をやりました。

運用サービス (Lite版) のサービス企画とプロト実装

経緯がレアなので業務内容の参考にはならないかもですが、MSP事業の発展のために既存のMSPとは別軸のコンセプトで新規の運用サービスを企画して、サービスオーナー兼開発をやってたことがありました。

この企画がぶち上がったのは当時の流れとしか言いようがないのですが、基本的には自分で「こういうのやりたいです」と上に提案し、了承と裁量をもらった上で動いてました。

見込み顧客とも会話してプロト版試験導入の交渉もやってました。最終的にはコンセプトの需要に広がりがないと結論付けました。

正直、当時の自分には身の丈を超える挑戦だったと思うのですが、提案して有用性が認められればこういう挑戦もできるよということで紹介してみました。もっとやれることはたくさんあったよなぁ、とも思いますが、自分でサービス企画しながら開発を兼務する生活はそれなりに充実していました。

Salesforce の保守

Salesforce のプラットフォームには自社カスタマイズのコードを拡張機能として動かすための仕組みが存在します。 "Apex" と呼ばれる、Javaのスーパーセットみたいな文法を持つ独自言語を使います。

このプロジェクトには当社の先人が積み上げてきたコードが大量にあります。基本的には既存コードの保守改修をすることになります。余力があればついでにリファクタリングなんかもやってます。

独自言語というものはどうも好きになれないのですが、その中でも Salesforce は割とクセが少ない部類だと個人的には感じています。Salesforce自体が成熟したプロダクトですし、デプロイまでサポートできる開発エコシステムが一応は整備されているプロダクトなので、（辛みを味わうことも多いですが）それなりにやりごたえは感じてます。文法がほぼ Java なのがとてもありがたいです。

Salesforceの仕組みとして面白いのが、ちゃんとテスト書かないと本番デプロイが通らないようになってることです。なので、既存コードの保守や、強制的にテストを書ける訓練の場として、自分は捉えています。

　保守業務の一貫として、当社カスタマイズな独自スキーマの管理業務などもやったりします。

請求書送付業務の効率化

進行形で要件定義の会話しているところなので、具体的な技術トピックはまだないです。

バックオフィスの業務として手作業の部分がかなり残っており、とりわけ請求書送付の業務に手間がかかっているということでウチの部署に話が来ました。今は業務内容の理解をしつつ、システム化がうまくいきそうかつ業務の硬直化が起きづらいスコープの見極め、現実的な進め方なんかを模索しているところです。

　EOLするサードパーティのプロダクトを一部使っているので、そのへんの見送りもやることになるかもしれません。

おわりに

　上で紹介した業務内容に関しては、あくまで私の場合はこうだった、という程度に受け取ってください。社内の業務改善なんて腐るほどネタがあるので、他の人はまったく違うことをやっていたりもします。あくまでご参考程度に。

個人的には、当社独自の環境要因（事業や文化の側面）も加味したうえで、今のポジションは概ね気に入っています。当社に応募してくる方の大半はおそらくクラウドインテグレーションに興味があって採用面接に臨まれると思いますが、本人にその気があればインテグレーション以外の部署でもかなりAWSのことは学べます。

私の部署ではインフラ構築からコードの開発、保守まで全部やるので、個々のサービス単位で見ればインテグレーション案件よりディープに触れる機会があると思います（AWS以外のサービスもそこそこウェイトを占めているので、案件全部がそうとは言いませんが）。

サードパーティ製品も必要なら使って連携させますし、よりユーザーの実業務に近いところでAWSサービスを使いこなす機会にはありつけるじゃないかと思います。総合して、良くも悪くもなんでも屋という感じはしますね。関与できる範囲が広いのはひとつの魅力だと思います。

　どうでしょう。サーバーワークスの裏方エンジニア、PE課のやっていることについて、イメージが湧きましたでしょうか？また、サーバーワークスの社内SEというキャリア選択について、少しでも魅力が伝われば幸いです。

p.s. 社内のエンジニアメンバーへ

　最後まで見てくれたんですね？ありがとう。ウチの部署はまぁ〜〜〜地味な部署ですけども、私は割と充実してるし、所属するメリットがあると判断して自分の意志で今PE課にいてます。楽しいことばかりでもないけど、やりたいことはやってるしそれなりにいい場所だと思いますよ。あと、社内転職も絶賛募集中ですよ。