（これは Livesense Advent Calendar 2024 DAY 12 の記事です。）
はじめに
リブセンスでエンジニアリングマネージャーをしている佐藤です。
4年ぶりの投稿で、前回暗めの話を書いて終わっていたので、今回はその後のお話です。
タイトルの通りソフトウェアエンジニアから情シスに社内職種変更したのですが、その経緯ややったこと、所感が話題の中心となります。
他職種からソフトウェアエンジニアになる話はよく見かけるのですが、逆は意外と見ないので、一例として面白いのではないでしょうか。
職種変更の経緯
前回投稿時、つまり4年前は転職ナビというサービスの開発をやっていたんですが、そちらが2021年末でサ終となり、それが転機となりました。
転職ナビには6年程度携わっていましたので、当時はなかなかの虚脱感がありましたね。
ソフトウェアエンジニア自体も15年くらいやっていましたので、一回違うことがやりたいなーと考え、転職も視野に入れつつ情シスの路線を探っていました。
そこにちょうど情シスリーダーのポストが空いたという話が来たのが、端的な経緯です。
ちなみになぜ情シスだったのかというと、事業部でエンジニアをやっていると、どうしても全社レベルでよくしたいところに手が届かないという思いがあったからです。
リブセンスには事業部所属のまま全社の改善をやっている人も在籍していますが、私はあんまり器用なタイプではないので。
情シスになって実際にやったこと
大まかには以下の5つです。
- 情シスという仕事を知る
- チームプレイ文化の醸成
- 業務の定型化とサービス可用性の向上
- エンジニア文化との接続
- 社内プレゼンスの向上
それぞれ以下で詳述します。
情シスという仕事を知る
何を当たり前のことを書いているんだと思われるかもしれませんが、真剣な話です。
私は転職ナビ時代からエンジニアリングマネージャーですし、前任のリーダーも現場で手を動かすというよりは指導者という感じだったようです。
職種変更しても、最初から方針策定や対外折衝、チーム構築といった仕事を主軸にしていくこともできたと思います。
ただ、現場を知らずに先に進むことはしたくなかった（し、そもそも当時人も足りてなかった）ので、最初の1年ちょっとは積極的に現場仕事に携わりました。
そして情シスになって最初に面白かったのがここで、笑っちゃうくらいに何もできませんでした。
まず、会社の資材を使ってPCを梱包・発送するのってどうやるんだろうとなりましたね。
他メンバーにとってあまりに当たり前のこと過ぎたので特段マニュアルもなく、エンジニアの中でも特にもやしっ子なソフトウェアエンジニア（偏見）は段ボールの扱いからして下手くそでしたｗ
また、情シスの中でもややレアな部類に入ると思いますが、リブセンスでは全社イベントの配信周りは情シスが担当しています。
情シスになって最初の全社会では、企画から機材オペレーションまでどっぷりとイベント運営に携わらせていただき、とてもよい人生経験になりました。
チームプレイ文化の醸成
「ひとり情シス」なんて言葉が頻出するだけあって、私が入った当時の情シスはアウトソースと少数精鋭メンバーによる個人プレイが基本になっていました。
そこにチームプレイ文化を醸成し、安定的で成長する組織を作っていくのが、エンジニアリングマネージャーとしての私の最初の仕事でした。
具体的には以下のようなことをしました。
- チーム内の情報の流通を見直して、全員が全員の仕事をある程度知っている状態を作った
- 各種ドキュメントのフォーマットを定めたり、チーム勉強会を発足させてノウハウ共有の基盤を作った
- チームとしてやりたいこと、個人に期待することを明言し、方向性を示した
- チームの状況やチームに必要な人物像を言語化し、チームにフィットする人材の採用を行った
この辺りはエンジニアリングマネージャーをやってらっしゃる方からすれば普通のことで、ソフトウェアエンジニアでも情シスでも大して変わらないところかと思います。
業務の定型化とサービス可用性の向上
チームプレイ文化と近しいところにはなりますが、情シスの仕事をサービスととらえたときの外向きの改善です。
前述したような改善によって属人化していた業務は定型化され、メンバーの休暇取得ハードルがぐっと下がりました。
これはチーム外から見ると
before: いつもの情シスメンバーがいつものように対応してくれる
after: 情シス内の誰かが大体同じように対応してくれる
という変化になったと思います。
当然before時点では"いつもの情シスメンバー"が休めばサービスの提供が止まっていましたので、サービス可用性の向上です。
また、監視やインシデント対応フローを整備したり（今は新規採用した人がさらによくしてくれています）、忘れがちな業務のちょっとした自動化や年中行事化によって、運用の安定性を高めることもできたと思います。
エンジニア文化との接続
情シスという仕事の難しいところの一つは、エンジニア的側面とコーポレート的側面の両方を併せ持つことだと思います。
実際私が入った当時の情シスメンバーは、（私含む）エンジニア出身者とそれ以外の出身者が半々でした。
結果、エンジニアリング業務が特定の人に偏ったり、社内の他エンジニア職とのコネクションが弱かったりしました。
先ほどのチームプレイ文化からすると業務の偏りが大きい状態は解消したいですし、ITという共通分野を持つ他エンジニア職からも刺激をもらいたかったです。
ここで行ったのは前述の勉強会発足ともう一つ、組織統合でした。
元々情シスは部門レベルで独立していたのですが、それを横断エンジニア組織の配下に編入させてもらった形です。
そのうえで積極的にイベント参加等を推進することで、他エンジニア職とのコネクションがかなり強化されました。
この点編入を許可してくださった現上長や、恐れずエンジニア文化に飛び込んで行ってくれた情シスメンバーには感謝しかありません。
社内プレゼンスの向上
toCのWebエンジニアなんかをやっていると、率改善をやることも多いと思います。
同じように、各種施策実施時にどのくらいその声が全社に届けられるか、どのくらいスムーズに動いてもらえるかが情シスにとって大事です。
基幹系のシステムであれば使わざるを得ないのでそこまででもないのですが、+αなツール導入のときなどは死活問題になりえます。
そのため、情シスジョイン時から一貫して社内プレゼンスの向上には一定の力を割いてきました。
ここの詳細は企業秘密なので語れないのですが、全社イベントでオモシロ発表をしたり、全社Slackにショート動画を投稿したりとか大体そんな感じです。
おかげさまで今では私以外のメンバーも率先して社内外への露出を増やしてくれています。
情シスになって楽しかったことの一つは、間違いなくこれです。
ソフトウェアエンジニア時代はユーザーの生の反応は得難いものでしたが、情シスは良くも悪くも生の反応を得られます。
情シスの採用をしていたときお会いした方々の中にも、（数字ではなく）ユーザーの生の反応が欲しくてジョブチェンジしたいという方が複数いらっしゃいました。
所感
現在ソフトウェアエンジニアをやっているみなさん、ましてエンジニアリングマネージャーをやっている人にとっては、見たことのあるような話が多かったのではないでしょうか？
実際、私自身が情シスに職種変更をしてみて、ソフトウェアを書かなくても（ほぼまったく書いてません）ソフトウェアエンジニア時代のスキルが生きることが多いと感じます。
特に私の場合、新卒から15年間ソフトウェア開発一筋でしたので、それ以外の分野でも生きていけるという自信につながったことでQoLに良い影響がありました。
また、全社イベント配信やオモシロ発表など、何でも屋な分飽きがきづらく、新鮮な気持ちでできる仕事が多いことも発見でした。
一つの技術を極めてその腕で生きていきたい、というストイックな人には向かないかもしれませんが、飽きっぽい人にはよい職種だと感じています。（※情シス組織のミッションにもよります）
まだ情シスになる際抱いていた全社レベルでの改善という初志が果たせたとはいいがたいですが、ソフトウェアエンジニアをやめてまる3年、私は楽しくやれています。