今年を振り返る

この記事はmohikanz Advent Calendar 2025の4日目の記事です。

adventar.org

1年に2回もアドベントカレンダー用のブログを書くなんて何年ぶりだろう…

本題

ということで2025年どうだったかというのを振り返っていく。

お仕事のこと

昨年のこの時期に書いた記事では主務が平社員、兼務で実質マネージャー業みたいなことをしていると書いた記憶がある。
3月までで抱えていたNW機器のリプレースを片付け、インフラチームの平社員は終了。4月からは人事等級は平社員のままで昨年から抱えていたSMS配信システムのチームに加えて新設されたデータ基盤のチームも担当することになった。なんということだ、また兼務だ。

SMS配信システムのチームはまあ去年とあんまり変わらず。
システムがグチャグチャなのを直したいという話になっていたが、あまりにグチャグチャすぎるのでリプレースしたほうが早いという結論になったので、あと1年後くらいには終わってるといいなという状況。

本当は今年度中に終わらせたかったところだが、システムがグチャグチャなことが原因でインシデントを起こしてしまったり、他にも細かいバグで運用に迷惑をかけてしまった。
開発メンバーにいわゆる上流工程の知見がなく、ないなりに任せてみたものの遅れていることを検知するのが遅れてしまって巻き返すのが不可能になってしまったという話もある。
色々と反省はあるが、朝会への参加が形式的になってしまっていて、何かしらの進捗はある旨が報告されていたのでヨシして聞き流していたのが大きいかと考えている。
後から聞いてみたらなんかうまくやれてない気がするという感覚はあったらしく、リモートワークだとどうしてもそういう雰囲気が感じ取れないなとも思った。（それはそれとして兼務では見きれないし、そういう感覚があったならさっさと相談してほしいというのはワガママなのだろうか。）

データ基盤のチームはなんか色々あり、本来チームを設立して作ろうとしていたデータ基盤が何やかんやあって計画が凍結されることになり、四半期ほどチームで何しようか…という状態になっていた。
そんな中で社内のGoogle DriveとかNotionとかを漁って、どうやらビジネス部門がデータ分析っぽいことをスプレッドシートでやっていたのだが、人力で物凄く大変なことを頑張っていそうだというのが見えてきた。
サンプルとして一部をLooker Studioでダッシュボード化して「こんなのあったら使います？」というのを飲み会の席で何度か一緒になったビジネス部門のリーダーに聞いてみたら非常にウケがよく、ちょうどビジネス部門でもデータ分析とかデータ利活用をもっとやっていかないといけないという話になっていたこともあり、渡りに船とばかりに草の根活動が始まった。

まだ途上ではあるが有用そうなものはできたということで、今月頭にビジネス部門で正式に利用開始となりまずはひとつ成果を作れた。ほぼ独力で色々と手を動かしてくれたメンバーの成果だ。

他にも仕事では本当に色々とあったが、ここに書くような内容ではないので興味があれば直接会ったときに聞いてほしい。

お仕事以外のこと

なによりも特大トピックとして家を買った。
築30年くらいの中古マンションなので「憧れのマイホーム！」みたいなものではないのだけれど。

もともと「35年ローン」みたいな話を耳にする度、もし組むなら年齢的にはギリギリだなと考えていたこともあったし、諸々の事情で浅草の1Kから引っ越す必要が出てきた。
引っ越したいエリアで希望条件に合致する物件を探してみても家賃がまあまあいい値段になってしまうしそもそも選択肢が少なく、そんな中でなんとなく中古マンションを眺めていると希望のエリアにいくつか良さげな物件があったので中古マンションの購入に路線を切り替えた、という感じ。

戸建ても候補になくはなかったのだが、マンションと比べると駅から遠くなってしまうため、完全フルリモートではないため通勤が面倒になるのがイヤだったことと、浅草での2年間である程度高い階層に住むことによる虫との別れが生活を快適にしすぎた。
とはいえ新しく通勤に使うことになった横須賀・総武快速線は10時過ぎにオフィスに着くような時間帯の電車に乗ってもまあまあ人が多く、通勤はかなり面倒に感じている。

6月くらいに資料請求してから8月の終わりに引き渡されたので全体的にはスムーズに終わったと思うが、スムーズに進みすぎて9月のクソ暑い時期にエアコン工事の立ち会いをやる羽目になってしまったのでスムーズに進みすぎるのも時期によってはよくないなと思ったものだ。
契約日の前日に売買契約の際に売主に渡す手付金を現ナマで用意してほしいと言われてしまったので焦って銀行の窓口にダッシュしたし、浅草の人混みを大金を持って歩く羽目になったのでかなりビビっていた。これだけは一連のプロセスの中で大きい不満だった。
初めての帯封は競馬の払戻金がよかったのだが。

しかし引っ越しはとにかく金と時間がかかる。
引き渡されてから引っ越すまでに1ヶ月くらい間を空けたが、毎週末のように工事や家電搬入の立ち会いなどで新居と旧居を往復していた。それだけで2,3回分の飲み代にはなっているし、仕事じゃないのに往復2.5時間はとにかく面倒だった。
引っ越しにかこつけて一気に財布の紐を緩めたのでこのタイミングじゃなくてもよさそうな出費も色々とあった。

他の細かい話では競馬とゲームくらいしかないが、Google TVを導入してグリチャQoLがバク上がりしたり本命トップナイフで脳から汁を出したり秋G1でタコ負けし続けたり、夜を渡ったりポケモンバトルをしたりサッカーゲームの遅延にブチギレたりしているくらい。

また福島行きたい。

締め

ということで今年は大きいトピックもあったりなかったりしたが、ドデカ借金してしまったので引き続きやっていき。

蛇足

引っ越し祝いお待ちしています。

間違えて顧客の本番webサーバーを止めちゃった話

この記事は本番環境などでやらかしちゃった人 Advent Calendar 2025 3日目の記事です。

qiita.com

10年くらい前、わたしがIT業界に来て初めてアサインされた現場での話なのでもう時効だろうということで供養します。

前提知識

• 当時のわたしは24/365でITインフラの監視・保守を行うオペレーターでした。
• 事件があったのは夜勤シフトで一緒になった先輩と2人で当番だった日です。

本題

経緯

その日は夜勤だったため、日勤のメンバーから「どの時間にどのような対応があるか」引き継ぎを受けます。
同じような仕事をしたことがある人はイメージできるかと思いますが、インフラ機器のメンテナンスは夜間に行われることが多く、該当時間帯は非監視とする対応を行ったりメンテナンス終了後の動作確認などをよく依頼されるのです。
ちょうどその日も1ヶ月ほど前から計画されていたとある案件の作業予定がありました。

作業予定リストを一通り引き継ぎを受けたあと、引き継ぎを担当したメンバーと以下のようなコミュニケーションがありました。

日勤「そういえばあの案件の作業って聞いてます？」
ぼく「はい、聞いてますよ。」
日勤「そうですか、じゃあよろしくお願いします。」
ぼく「うっすうっす。」

そうです。わたしは前日のシフトのうちに次回出勤した際に計画されている対応を事前にチェックしていたのです。なんて仕事に真摯なのでしょう。
あの案件の作業とは、監視している顧客webサーバーの連携システムがメンテナンスされるため、メンテナンス作業開始前にwebサーバーを停止させ、終了後に再びwebサーバーを起動して動作確認を行うという内容でした。

そうしてシフトに入り、突発的な保守作業の対応などを無難にこなし、交互に仮眠をとり、また別の監視アラート対応がひと段落しかけた頃です。時刻は朝の4時。そして事件は起こりました。

---

ぼく「先輩、もう4時ですね。」
先輩「あ、やべっ、もうそんな時間か。あの案件の作業は俺がやるから再鑑よろしく。」
ぼく「おかのした」

～作業中～

先輩「ヨシ！」
ぼく「ヨシ！」
先輩「じゃあ完了連絡するわ～」
ぼく「ぞすぞす」

そうしてメールを送ってしばらく後、一本の電話が来ます。

先輩「もしもし、ほげほげオペレーションセンターです。」
先輩「えっ、あ、えーっと、、、ああっ、本当ですね、大変申し訳ありません。はい、すぐに起動します。はい、失礼します。」
先輩「あの案件の作業延期になってたらしい。たしかにリストにないな…」
ぼく「アイエェェ…」

なんということでしょう。インシデントを起こしてしまいました。

---

その後即座にwebサーバーを起動させ動作確認をし、顛末書のドラフトを作成し、事の経緯と顛末書のドラフトを日勤の責任者にSHAZAIとともに引き継いでその日の勤務を終えました。

振り返り

そもそもなぜこのようなインシデントを起こしてしまったのでしょうか。
答えを先に書くと「うっかりしていた」ということになります。

先述の通り、当時は以下のようなコミュニケーションがありました。

日勤「そういえばあの案件の作業って聞いてます？」
ぼく「はい、聞いてますよ」
日勤「そうですか、じゃあよろしくお願いします」
ぼく「うっすうっす。」

すごく端的なコミュニケーションですね。お互いが伝えたかったことを補完すると以下のようになります。

日勤「そういえばあの案件の作業（がリスケになったの）って聞いてます？」
ぼく「はい、（今夜作業があることは）聞いてますよ。」
日勤「そうですか、じゃあよろしくお願いします。」
ぼく「うっすうっす。」

なんということでしょう。これでは何も伝わりません。それなのにお互いに共通認識が持てたかのような口振りです。
また、事前に作業があったことは確認していたので、日勤のメンバーから引き継ぎを受けたときに「あの案件の作業があるんですよね？」と一言確認をしておけば回避できたインシデントです。

さらに、責任者に引き継いだ後に作業予定リストを確認したところ、その作業の計画が確かにリスケとなっていることが確認できました。

つまり、このインシデントの原因は「うっかりしていた」ことで、対策は「しっかりする」ことになります。

…なんて言ったらアホ丸出しになってしまうので、もう少しちゃんと書きましょう。

1つ目の原因は「引継ぎ時のディスコミュニケーション」で、対策は「計画作業が直前にリスケになった場合、その旨を明確に引き継ぐ」ことです。
2つ目の原因は「直前にバタバタしていて作業予定リストを確認せずに作業に着手してしまったこと」で、対策は「計画作業はリストに存在することを確認してから着手する」ことになります。

終わりに

2つ目の原因はアホすぎて同じようなやらかしは以降やっていませんが、1つ目についてはそうでもありません。
というよりも、ちょっとしたディスコミュニケーションで発生するヒヤリハットはそこらへんにいくらでも転がっているかと思います。

このケースのようなディスコミュニケーションは「自分が認識していることは相手も同じ認識だろう」という思い込みから発生します。
仕事だけではなく日常でも茶飯事かもしれません。昔よくテレビで放送されていたアンジャッシュのコントもこのような芸風でしたね。

もしここまで読んでいただけたのであれば他山の石としていただき、「自分の認識や理解していることは、話し相手や文章の読み手も同様とは限らない」ということを頭の片隅に入れていただき、正しく伝えないといけない場合は1から10まで丁寧に説明することを心掛けていただければ幸いです。

なお、この件は現場の偉い人からめちゃくちゃ怒られるかと思ってドキドキしていましたが、全く関係ない別の連携先がたまたま大障害を起こしていて、顧客の関心が全てそちらに向き「そんなのどうでもいいよ！」となったおかげで全く大事にならずに済みました。

マスタリング目標設定

いい季節なので普遍的な目標設定について、どのように設定すると捗るのかを書く。

前提として、nagashiは数名のメンバーがいるチームを担当しているマネージャーであるため、上司の立場からしてメンバーに意識してほしいポイントを書いている。

もともとは前職で色々と仕込まれた目標設定のテクニックで、現職では知らないが多かったため社内向けに書いたドキュメントを公開可能な形で書き直したものになる。
前職でも現職でも、このテクニックを身に着けているかどうかで個々人の目標設定のクオリティがかなり違っていた。

目標設定テクニック

何を目標にしたいか＝何を達成したら高い評価をもらいたいか表明する

nagashiはITエンジニア畑の人間なのでそれをベースに書くが、要するに以下のような「自分がどうなりたいか？」を表明しようということだ。

• IC(Individual Contributor)としてのキャリアを形成したい。そのために高い課題解決能力を身に着けたいので、課題解決をするための技術力を評価してほしい。
• エンジニアリングマネージャーになりたい。そのために実践する機会がほしいので、まずは小規模なプロジェクトを任せてもらい、その結果を評価してほしい。

なぜ表明しなくてはいけないかというと、これが表明されないと望んだ方向へのキャリア形成に支障が出るから。
例えば、将来はマネージャーをやりたいけど表明してないので現場でもりもりコードを書くことが評価指標になる。など。

自分がどのようなキャリアを形成したいのかを整理してから目標設定に臨むというのが大事なのだ。

表明したものを上司とすり合わせる

会社に所属している以上は自分が望むキャリアに直接関係がない仕事もやらなくてはいけない。

いわゆるWill / Can / Mustという枠の中で、基本的に会社から指示される仕事はCanでありMustな領域だけになる。
（Willなどの）それ以外の領域は、会社や組織の方向性と自分のキャリアの方向性が一致しない限り、仕事を任させることは基本的にない。

一方で、会社から指示される仕事というのは、会社からあなたが処理することを期待されている仕事だったり、あなたに成長してほしいと考えている方向性に沿った仕事になる。

つまり、あなたに設定したい目標があるのと同時に、会社（≒上司）にもあなたにやってほしいことや成長してほしい方向性というのが存在する。

それらを加味して、すり合わせた上で目標設定は完了する。

「めちゃくちゃ成果出したのに評価は微妙だった」という経験がある人もいるかと思う。
そのような評価への不満が発生する場合、これができていない可能性が高い。

上司は超能力者でも学校の先生でもない。何をどうやって評価してほしいのかを表明し、上司からの期待値とすり合わせよう。

なぜこの目標を設定するのかを明確にする

これはやってくれると非常に嬉しい。

明確にすることで、すり合わせる際に上司も納得しやすい。
また、「そういう理由ならこんな感じの目標の方がいいんじゃないか」とか「（任せても大丈夫だと思える仕事ぶりをしている前提で）ああいうこと言ってたしこの仕事は成長のためにお願いしようかな」とか考えやすくなる。

つまり目指したい方向性に近づける可能性が増す。

達成基準は定量的なものにする。

OKRで言えばKey Resultは定量的なものにしよう。

目標が「半年後までに開発中のサービスをリリースする」のように定量的なものであればあまり困らない。
が、例えば、エンジニアの目標設定でありがちな「技術力を伸ばす」という目標を設定した場合、どうやって評価してほしいのか？

これは定性的な目標なので、単に技術力を伸ばす！だけだと、何をもって伸ばすことができたと言えるのかが不明なので評価者の主観でしか評価がされなくなる。

そもそも「技術力」という言葉が抽象的すぎるので、もう少し具体化して「ここでいう技術力とはAWSのマネージドサービスに対する習熟度合いのことである」「よってAWSのマネージドサービスに習熟する」といった目標にするのがよいだろう。
同時に、評価の時期に何を以て「AWSのマネージドサービスに習熟した」と言えるのか？を説得力がある形でアウトプットしないといけない。

それを解消するためには資格を取って証明する、伸ばした技術力を基に何かを作ったり何かの課題解決をする、といった目標になるだろう。
いずれも共通するのは「定量的に測定可能なものである」ということ。

ITエンジニアの目標は定性的なものになりがちだが、定性的なもの（技術力を伸ばす等）を目標にしたい場合、それを定量的（っぽいもの）にしてしまうのがよい。

例

• ❌：技術力を伸ばす
• 🔺：AWSマネージドサービスに関する技術を学び、資格を取得する
• ⭕：AWSマネージドサービスに関する技術を習得し、社内にあるEC2インスタンスを全てマネージドサービスに置き換える

また、定量的に測定可能であれば、上司（評価者）との期待とのすり合わせもやりやすい。

単に「できた or できなかった」の基準しか設けていない場合、できなかった瞬間に高い評価ができなくなる。
「ここまでやったら50%」みたいな段階を設けておくとなおよい。

適度に抽象化する

---

【目標】
フルマネージドなKubernetesクラスタを開発環境として構築する。
featureブランチごとに環境が自動でデプロイされるようにすることで環境の取り合いを無くし、開発者の生産性を向上させる。

• 基準1：IaCでEKSクラスタを管理する
• 基準2：PRの作成をフックにしてhelmチャートから環境をデプロイする

---

この目標を見てどう思うだろうか。
やることが明確でいい。と思った人はちょっと待ってほしい。

これでは具体的すぎてむしろ良くない。
そもそも本当に実現したいことは「開発者の生産性を向上させる」ことだ。*1
また、検証した結果Kubernetesを使わないほうがよいという結論になったらどうか？AWSではなくGoogle Cloudで実現することになったら？
別の手法で実現できても「でもこの方法だとダメだったよね」と評価にケチがつく可能性がある。

それ以外にも、具体的すぎるので「それ目標じゃなくてタスクじゃん、あとはやるだけなら目標にする意味ないよね」という指摘され目標設定をやり直しになる可能性もあるだろう。*2

さらに、直属の上司など直接の評価者には伝わるかもしれないが、その上の評価者に前提知識がなく理解できず、圧倒的な成果を出しても「よくわからんのでほどほどで」みたいな評価になる可能性もある。 *3
手段を具体化せず、かつ前提知識がない人でもわかるように記述すると以下のようになるだろう。

---

【目標】
開発環境を取り合ったりすることで発生するリードタイムをなくし、開発者の生産性を向上させる。

• 基準1：新しい開発基盤を構築する
• 基準2：新しい基盤に自動で環境が用意されるようにする

---

余談だが、抽象的なことを具体化して考えることができる人は多いけど、このように具体的なことを抽象化することには慣れていない人が多い印象がある。鍛えよう。

上司をうまく使う

まず覚えておいてほしい大事なこととして、上司はあなたの敵ではない。

あなたがちゃんとした目標を設定したいと思っているのと同時に、上司もあなたによい目標を設定して、それを追っていってほしいと思っている。
上司としてもあなたに成長してほしい。

目標設定が難しいと感じることもあると思うが、そういうときこそ上司をうまく使おう。

壁打ちや相談をいくらでも持っていってよいし、適度にコミュニケーションしながら目標を作り上げていくべきだ。
というかこのようなサポートは上司がやるべき仕事の1つだと考えている。

この話をすると、半分くらいの確率で「上司が忙しそうなので相談しにくい」ということを言われるが、部下を持っていて忙しくない人はいない。気にしないで打診してみるとよい。リスケはあっても断られることはあまりないだろう。

なお「上司が忙しそうだから」と気を使い目標設定ができなくても困るのはあなたであり、上司はそこまで困らない。
なぜなら上司が忙しいかどうかは、あなたの評価に反映されないからだ。

仮に気を使って相談できなかった結果として目標の提出が遅れた場合、ただ単にあなたが「目標設定が期限通りにできなかったヤツ」という扱いをされて終わる。

また、自分の中で整理がついてないからと相談しにくいことがあるかもしれない。
そういうときでも「そもそも整理がついてない状態である」ということを表明しつつ相談（壁打ち）しにいくのがよいだろう。

ラバーダッキングと同じで、喋っているうちに整理されてくるかもしれないし、他者の視点からアドバイスをもらえたりするかもしれない。

そうでなくても、上司と一緒に悩めば大抵の場合は力になってくれるはずだ。

---

ということで、前職の上司*4に仕込まれたものに自身の経験を混ぜ込んで、社内向けに書いたものをベースに目標設定に関するブログを書いた。
こういう話を真剣にする相手がいなくなってしまったので、「こうするともっと捗る」みたいなのがあれば教えてほしい。

本当は「自己評価の作り方編」もあるのだけど、それはまた別の機会に気が向いたら書こうかと思う。

そろそろ目標設定という人もいるだろうし、誰かの役に立ったのなら素敵だ…

*1:生産性向上を目的とした施策がイケてないとか、そういう話は置いておく

*2:自分なら同様の指摘をする

*3:これは上司の政治力次第かもしれないが

*4:彼には転職後も世話になり続けていて、先日の麻雀でもチップをたくさんいただいた

ITベンダーではない会社がITエンジニアを自社で雇う意味 #とは

この記事はmohikanz Advent Calendar 2024の24日目です。

adventar.org

前回の記事はasny23さんの「2024年に趣味で開発してたこと」についてでした。

asny23.medium.com

---

前回のブログに書いた通り、自分の今の主な仕事はマネジメント業だ。
ちょうど2年くらい前に考えていたことについて最近改めて思いを馳せることが多く、アドベントカレンダーの枠も余ってるし言語化しておくかとおもむろに書いてみる。

「ITエンジニアを自前で雇う意味」についてだ。

今年の6月に出ていたIPAの資料*1によると、回答した約1000件のうちだいたい4割ちょっとが必要な全部あるいは一部を内製化しているらしい。
要するにITエンジニアを自前で雇っているということだ。

この4割のうち、SaaSやなんとかテックみたいなテクノロジーの力で${任意の領域}の課題を解決するようなサービスをやっている会社はどれくらいあるのだろうか。
言い換えるとITエンジニアが価値の源泉に関わるものを作っている会社なのだろうか。ということだ。

例えば、「自社でバックオフィスのツールを内製していること」が価値の源泉になる会社はどれくらいあるだろう。全く無いと言い切ってもいいのではないかと思う。
だからこそ労務管理や勤怠管理、経費精算なんかのバックオフィス系SaaSは売れるのだ。

自分の前職はB2BでAIソリューションを受託開発する会社だった。
そこでは「AI開発がコアバリューである＝データサイエンティスト*2が価値の源泉にいる会社でITエンジニアを雇う意味はなんなのか？」という問いに、マネージャー陣みんなで頭を悩ませていた。

当時はAIに関して一番うまく使える or 活用できるようになることで価値を出していくぞ！みたいな方向性だったような気がするが、それに沿ってやっていく途中で組織は解体されてしまった。
組織が解体された後に居酒屋で「なぜ我々の組織が解体されてしまったのか」という話をしていたが、そこで出てきた話に強く膝を打った。それをやるべきだったんだな、と今でも思っている。

タイトルに「ITベンダーではない」という枕詞を置いたが、ITベンダーの価値の源泉は技術力そのものであるため、このような存在証明みたいな何かはそもそも必要ないというのが自分の理解だ。*3

今の会社はどうかというと、入社してデータ分析とクライアントワークがコアバリューだと気付いた。
つまり、データサイエンティストと顧客担当者が価値の源泉にいる会社だと気付いた。

同じだと思った。

前回のブログに組織に色々と課題がある、というようなことを書いた。
けど、それは表面的なことで、「この会社が自前でITエンジニアを雇っている意味はあるのか？」「この会社のITエンジニアは全員外注に代替可能なのではないか？」と思った。

受託じゃないほうがいい思い、内定が出た中から選んだのが今の会社だけど、今にして思えば他の2社はITエンジニアが作るものが価値の源泉だったように思う。
自分では気付かないうちに、またしても同じような問いに向かっていっていたわけだ。

幸運にして、今回は初めてではないのでもっとうまくやるしかない。
存在意義は与えられるものではないのだ。少なくとも今の環境では。

---

枠あいてるなーというのを見かけて勢いで書いたのでだいぶポエットになってしまったけど、このあたりにしておきます。
mohikanz Advent Calendar 2024のラストを飾るのはモヒカン系VTuber(予定)のmorinさんです。

*1:https://www.ipa.go.jp/digital/chousa/dx-trend/eid2eo0000002cs5-att/dx-trend-2024.pdf

*2:世間には「AIエンジニア」という職種もあるかと思うが、より探索的なことをやっていたのでエンジニアとは区別する

*3:技術力ってなんだよという話もあるが、ここでは置いておく

今年1年を振り返る

この記事はmohikanz Advent Calendar 2024の14日目です。予約投稿してたつもりが下書き保存していてうっかりしてやや遅刻しました。

adventar.org

前回はmochiさんの振り返りブログでした。

mochi331.livedoor.blog

昔はもっと活発にアドベントカレンダーの準備とかエントリーがされていた記憶があるけど、すっかり落ち着いた感じ。
人のこと言えないけど。

ということで、アドベントカレンダーにかこつけて今年も1年の振り返りをやっていく。

今年のサマリ

仕事

• 転職した
• 火中の栗と落ち穂を拾い続けて文句を言い続けている

ほか

• 福島旅行
• 日常生活

細かく

転職した

転職エントリーも転職後半年エントリーも書いたけど、4月から新しい職場で働いている。
前職とは異なり、地方自治体向けのビジネスをやっている会社だ。

転職の直前は退職時期で揉めたり、デカい案件の承認された予算が知らないところで減額されていて、執行役員氏にも「理由は知らないけど」とか言われたのをなんとかしたり、そのデカい案件でトラブルがあって偉い人たちに頭を下げたりしていた。
正直なところ予算がサイレント減額されたのは未だに根に持っている。

転職するにあたり内定をもらった会社が3つあって、結果的に一番早いタイミングからコンタクトを取っていて一番給料が高い会社を選んだ。

他の2社については、1つはひとりインフラエンジニアとして入社するのに管理監督者扱いとなることに懸念があったのと年収は上がるけど月収が10万近く下がるので見送り、もう1社はすごく面白そうだったんだけど、前職のボスがわたしの選考プロセス中にその会社に転職していってしまい、「もう何年もこの人の下で仕事してるし、やりやすいんだけど他の環境を経験したほうがいいな」と思って選ばなかった。

前職ボスがnoteを書いているので貼っておく。いろんなポジションを積極的に採用中らしいので興味がある人はエントリーしてみてはどうだろうか。

note.com

で、自分が転職してからというと、前職ではエンジニアチームのマネージャー兼情シスのリーダーだったが、新しい職場では現場のインフラエンジニアとして入社した。

基盤はAWSと聞いていて、前職ではほとんどGoogle Cloudだったので「キャッチアップし直さないとな〜」と思っていたが、実は転職してから約9ヶ月、AWS上に何かを構築したりTerraformを書くようなタスクは一切持っていない。

最初にやっていたのは、社内の一部で使われているがガバナンスが効いていないGoogle Cloudの現状調査で、その次には別チームで運用しているシステムのシステム構成を眺めていたところたまたま発見した、サーバー証明書の更新対応だ。

一般的なサーバー証明書は今では有効期限が1年以内になっているが、その証明書は閉域網でhttps通信をするためだけに使用されているオレオレ証明書であり、5年前に作成されたものだった。そしてそのサーバーはシステムのSPoF。
スケジュール的にはギリギリなんとかなりそうだと胸を撫で下ろしたところ、また別の場所でSPoFになっているネットワーク機器がEoLになりそうなのを見つけ、証明書更新とネットワーク機器のリプレースそれぞれの対応をプロマネしていた。

証明書更新なんて簡単でしょう。と思いつつも、このシステムには検証環境がないため検証環境の構築からスタートし、その環境構築も当時のドキュメントが全然残っていないしTerraformのコードを持ってきて別環境にapplyするだけでは動かないしで非常に難航した。

本来であればアーキテクチャ自体をもっとモダンなものに変えるつもりだったのだが、検証環境構築がスケジュールを圧迫してしまったため偉い人に頭を下げてスコープを縮小し、証明書を入れ替えて延命させるだけの対応になった。
以降の対応はそのシステムを運用しているチームに任せて終わりにした。

ちなみにネットワーク機器の方はまだ終わっておらず、ベンダーとの調整と発生する費用について社内で頭を下げたりしている。

プロマネという肩書きを持ってプロマネ業をちゃんとやるのは初めてだったが、適切に頭を下げることができれば意外となんとかなるのかもしれない。

他にはインフラチームのマネージャーがマネジメント業が初めてということもありチームビルディングの手伝いをしたり、初めてのマネジメント業でぶち当たる課題に頭を悩ませているのを見て「去年とか一昨年の俺もこうだったな〜」と懐かしがったりしていた。

今の仕事はというと、前回のブログでも触れていたが実質マネージャー業が主な仕事だ。
実質といいつつ、「責務だけあって権限が無いのは面倒なので本当は給料もセットにしてほしいけどとりあえず権限だけくれ」とリクエストをし続けていたら権限はもらったので「実質」というのはなくなったけど。

インフラチームの平社員が主務、先述したのとはまた別の開発チームのマネージャーが兼務という、ややよくわからない状態になっている。

そのチームでは古参が退職してシステムの知識がある人がいなくなり、昔在籍したロースキルなエンジニア（エンジニア未満かもしれないがエンジニアとしておく）が作ったグチャグチャなソフトウェアのバグ対応や、グチャグチャなことによる追加開発が発生した際のデカい工数に疲弊していた。
そちらのチームを見ているハイレイヤーのマネージャーに「ヤバいからそっちのチームなんとかして」という話をしていたのだが、進捗がまったくなかったのでテコ入れに入ったのが実質マネージャー業のスタートだった。

優秀な人が業務委託で来てくれることになった幸運も重なり、チームを立て直して軌道に乗ってきたところだ。

個人的にはいい経験になっていると思っている。業務でソフトウェア開発を一切してこなかった自分がソフトウェア開発チームのマネージャーとしてバリューを出すことができればまた成長できるのではないだろうか。

ただし軌道に乗ってきたのはあくまでチームで仕事を進めるという部分だけで、グチャグチャなソフトウェアの改善はこれからで、どうやって改善していくかというのが次のチームの大きな課題。

この課題を倒すことができたらチームとしても成長できるはずなのでやっていきたい。

チーム内のマネジメント業についてしばらく書いてきたが、現職のエンジニア組織はどうにもマネジメント層があまり機能していない。
全体のことを考えるとこちらのほうが大きい問題ではあるが、機能させるためにはどうしたらいいのかというのは考えられておらず、イケてない部分を見つけたら個別に文句を言っている程度しかできていない。

もっとドラスティックにやっていかないと解決しないとは思っているけど、エンジニア部門のボスが最近変わったので、課題感だけ伝えて一旦は静観していてもう少し様子を見るつもりではある。

思うところとしては、「マネージャー経験の浅さ」を至らない理由にする人が数名いるけど、これは別の場所に書いた通りで、そのロールを任されているのであれば経験不足を理由にしてやるべきことができなくてもいいわけではなく、それを理由にしているということはなぜ至らないのかという本当の理由がわかっていないんだろうなというもの。
というのを業務委託で来ている（マネージャー陣の相談に色々乗ってそうな感じだがロールがよくわからない）人との1on1で文句を言ったら「1年目は多めに見てたけど今年はね…」という話をしていて、自分だけが思っているわけではないことが知れて良かった。

結果的に現場のエンジニアとしてはほとんど働いていないが、これはこれで良かったかなと思っている。
日本のサラリーマンはマネジメントやりたがらないし、人がやりたがらない仕事は給料がいいのだ。

長々と書いてしまったが、まあ、そんな感じで火中の栗や落ち穂を拾って給料をもらっている。
転職当初と比較すると仕事のレイヤーが上がって権限と責任が増えているので、評価のタイミングで給料も上げてほしいところだ。

福島旅行

競馬カス仲間で11月の開幕最終週を狙って福島旅行に行った。
多くは語らないが福島はいい。メシは安くてうまい。何より競馬場がある。

一緒に旅行に行った競馬カスは全員タコ負けしていたが、わたしはホテル代と新幹線代を稼ぐことに成功した。最高に気持ちがいい。

競馬カス仲間での福島旅打ちは2回目だが、まだ福島を楽しみ尽くしてないのでまた行きたいと思っている。
でも次の旅打ちは別の場所かな。金沢競馬場行きたい。

日常生活

転職エントリーに貼ったほしいものリストから皆さんが送ってくれた酒がなくならない。
この酒を消費したら近所にいっぱいある居酒屋を回ろうと思っていたのだが、引っ越して1年間全くできていない。

今の部屋は観光地とカスの街の間の子にあり、平日の昼間から外国人観光客の集団やワンカップを片手にウロウロしてるジジイがいる。平日の朝に駅まで歩いていると道中で立ち飲み屋が営業しているような街だ。
世間一般では観光地という側面がフォーカスされているため、ちゃんとした服を着た人がほとんどなのだが、わたしはそんな人混みの中をサンダルにスゥエットな格好でうろつくのにすっかり慣れてしまった。

もはやスニーカーですら交通機関を使わない外出では履かなくなった。このまま20年も経てばワンカップを片手に観光地をウロウロするジジイの仲間入りかもしれない。

締め

書き出してみたら仕事の話に対してプライベートの話が少なすぎて若干何とも言えない気持ちになったが、一旦はここまでにしておく。

アドベントカレンダーの次回はgimKondoさんが柔術の話を書くらしい。
靭帯を伸ばされたくなければ納期を伸ばそう。

転職して半年経った

nagashi-ma-w.hatenablog.com

あっという間に春が終わり夏が終わり、夏の終わりとともに馬券の調子もどんどん悪くなっている。
転職してからブログ書いてないなと思ったので、三連休の終わりに書くことにした。

前職で感じていたモヤモヤは今どうなのか

そんなことをしながら、「アレ、エンジニアとしての自分はどこいったんだ」とか、
「なんか会社のビジネスに関わりにくい組織になっちゃった」とか
「自社サービスやってるところでもう一回働きたいなあ」とか
なんやらモヤモヤするというかなんというか、まあそんな感じ。
マネジメントを続けるにしても、N=1では「ぼくのかんがえたさいきょうの」にしかならんやろという感覚もあった。

とか、前回のブログに書いているけど、このあたりのモヤモヤはある程度は解消された。
受託の仕事をやっているだけでは満たせないものに対する飢えがあったんだな、と今では思っている。

あとは自分の仕事が会社のビジネスに近いとやっぱりやる気出るな、となっている。
実際はエンジニア側とビジネス側はまだまだ遠くて、そこをもっと近づけるために色々やっているのだけど、色々やれる、というのが大事なのだ。

マネジメントについては今のところマネージャーではないのだけど、なぜか実質マネージャーみたいなことをやっていて、別に構わないんだけど権限と責任と昇給はセットにしてほしいなあと思っているところ。

今のお仕事

転職してからしばらくはIT考古学とかGoogle Cloud関連の作業をやっていたけど、それは5月くらいまで。
今は何をしていのるかという話だが、端的に言うと火中の栗拾いをしている。

よく見てみたら時限爆弾だった拾った栗をなんとかするプロマネ業と、なぜかやっている実質マネージャー業が今の業務内容のほぼ全てだ。

インフラエンジニアとして内定をもらっていたことを考えると思っていたのとは違うけど、嫌いな仕事ではないし、組織で必要だと思うことは何でもやればいいと思っているので特に気にしていない。
とはいえ、実質マネージャー業の方では権限がほしいなとは思うことはそこそこある。
定義されている組織体制と比べると歪な状態であることは間違いないので、組織をどうしていくかも含めて偉い人が頭を悩ませているのだろうとは思う。

組織もシステムも色々な課題がたくさんあって、コッカラッス！と言いながら*1仕事をしているような状態なので、整った環境でキラキラITエンジニア()をしたい人には全く向かない。
観測範囲内の大きい問題の1つはエンジニア組織になんちゃってアジャイルが浸透していることで、自分の手が届く範囲ではなんとかしつつあるけど、それより遠い範囲では何もできていない。それを何とかするためにも権限が欲しかったりしている。
過去在籍していたEMが作ったという社内のアジャイル開発ガイドがそんな感じだったので、初めて見たときは「悪しき文化が受け継がれているなあ」という感想を持った。

会社の業績自体は好調だし、給料もいいし、社会的意義がある事業をしている会社だけど、他にも組織の課題は本当にいっぱいあるので、コッカラッス！と言いながら仕事をしたい人は声をかけてほしい。リファラル報酬もある。

herp.careers

終わりに

雑多になってしまったけど、今回はここらへんまでにしておこうと思う。

選考に出した経歴書にこのブログのリンクも貼っているし、ちょっと前に同僚から𝕏(旧Twitter)でフォローされた気もするけど、あまり気にしないで色々書いた。
怒られたら消すなり編集するなりしようと思う。

*1:言っているのはnagashiくらいしかいない

4年半働いたAIベンチャーを退職しました

今回もタイトル通り。
前回転職してからちょうど4年半が経過する03/31付けで今働いているAIベンチャーを退職します。

nagashi-ma-w.hatenablog.com

03/19が最終出社で、現在は有給消化中。

やっていたこと

入社してから色々やった。
最初は前任のインフラエンジニアもいたのでテキトーにやってればいいやと思っていたけど、全然テキトーでは済まされず。
入社してすぐの時期からよく知らないものを色々調べながら作っていく、最近では忘れかけていたこともずーっとやっていた。
GCPとかGPUドライバーとかTerraformとか。

このブログにも何回か書いている通り、その後インフラエンジニアが自分だけになって採用とかチーム作りに奔走したりマネジメントの真似事をしたり。
ここ2年くらいはマネジメントっぽいことがメインの仕事になっていてターミナルやVSCodeよりもスプレッドシートやスライドを開いている時間が多かった。

それっぽい書き方でキャリアの変遷を書くと、シニア→テックリード→マネージャー、というキャリアを積ませてもらった。
最後の方はインフラだけではなく情シスの現場をリードしながらプラットフォームエンジニアリングやらエンジニアリングオフィス的なことをやる組織のマネージャーとなり、多様なメンバーのマネジメントをを任された。
経営陣と直接コミュニケーションを取りながら仕事を進める機会もあり、本当に幅広い経験をさせてもらったと思う。

働いていたほとんどの期間で上司だったid:hidesuke には本当にお世話になった。前回はそうでもなかったが麻雀を打つときには引き続き世話になりたい。
給料も入社当時から比べてとんでもなく上げてもらった。

ただまあ、幅広い経験をさせてもらったがゆえになのか、最終出社日まで引き継ぎに関する打ち合わせが入るのは勘弁願いたかったところだ。

そんなことをしながら、「アレ、エンジニアとしての自分はどこいったんだ」とか、
「なんか会社のビジネスに関わりにくい組織になっちゃった」とか
「自社サービスやってるところでもう一回働きたいなあ」とか
なんやらモヤモヤするというかなんというか、まあそんな感じ。
マネジメントを続けるにしても、N=1では「ぼくのかんがえたさいきょうの」にしかならんやろという感覚もあった。

主な引き継ぎ先が前職と同じ人だけど、まあ許してほしい。

次の会社でやること

次は04/01から働き始めます。
予防医療が抱える課題を解決するぜ！みたいなサービスを提供している会社でインフラエンジニアをやる予定。
主にGCPを使っていたところで次の会社では主にAWSと聞いているし、一旦マネジメントからは離れそうだけど、すぐにバリューを出せそうなのはそのあたりなのかなあと思うこともあり。
ぼんやりとアップデートは追ってたけど、2年ぶりくらいにAWS再入門となる予定。

ちなみに今回の転職では主にFindyを使った。
ユーザーサクセスの役割が一般的な転職エージェントとは一味違う感じなので、転職するかどうかはさておきキャリアの壁打ちがしたいときでも面談を申し込むのを推奨しておく。

終わりに

ということで、転職が多いわたしのキャリアでは最長の4年半を記録したAIベンチャーを退職して次の仕事をします。

お約束のリストは貼っておきます。
https://www.amazon.jp/hz/wishlist/ls/33DWQCGP2W9IC?ref_=wl_share