はじめに
2026年4月にLayerXへ入社し、三井物産デジタル・アセットマネジメント（以下、MDM）に出向している hi-se です。
今回初めての転職を経験し、新しい環境で仕事を始めて数か月が経ちました。環境が変わる中で、自分の仕事の進め方も変わってきていると感じたので、その変化を振り返ってみます。
自己紹介
前職は、少人数のFinTechスタートアップでした。
学生時代にコーポレートエンジニアとしてアルバイトをしていた会社に新卒で入社し、約4年間コーポレートIT全般を担いました。社内業務を効率化するツール開発をはじめ、ヘルプデスク、デバイス管理、ID管理、SaaS管理、入退社対応など、いわゆる情シス業務を一通り経験しました。
また、業務の幅が広がる中で、監査対応やセキュリティ体制の整備にも関わるようになりました。
新卒から一人情シスとして働くという、少し珍しいキャリアだったと思います。
LayerX・MDMを選んだ理由
LayerXは、前職時代から気になっていた会社の一つでした。
noteやテックブログなどの発信を通じて、技術的な取り組みだけでなく、組織や仕事の進め方についても継続的に改善しながら挑戦している会社なのだと感じていました。
一人情シスとして働く中で、少人数の組織で幅広い業務を担うことには面白さがある一方で、一人で仕事を進めることが多く、自分の判断や仕事の進め方について客観的なフィードバックを得る機会は限られていました。
だからこそ、自分とは異なる視点を持つ人たちと議論しながら仕事を進められる環境で働いてみたいという思いが、少しずつ強くなっていきました。
そんなタイミングで、現在の上長であるken5さんとカジュアル面談をする中で、LayerXは自分が求めていた環境だと感じたため、LayerX・MDMへの入社を決めました。
MDMでの役割とチーム
LayerXにはFintech事業部があり、所属するメンバーは三井物産デジタル・アセットマネジメント株式会社（MDM）に出向して業務にあたっています。
MDMは、三井物産やLayerXなどが関わる合弁会社で、不動産・インフラなどの実物資産を対象としたアセットマネジメント事業を展開しています。また、個人向け資産運用サービス「ALTERNA（オルタナ）」の開発・運営も手掛けています。
私はそのMDMのコーポレートシステム部に所属しています。
コーポレートシステム部では、ヘルプデスクや端末管理、入退社対応、社内システムの運用といったコーポレートITに加え、プロダクトのインフラやセキュリティ、ガバナンスといった領域も担当しています。
プロダクトのインフラはTerraformによるIaCで管理され、開発にはGoが標準的な言語として使われることが多いです。
チームは現在4人体制ですが、それぞれ担当する領域が異なるため、日々取り組む仕事もさまざまです。
そのため、朝会や日報、週次定例を通じて進捗や作業内容を共有し、チーム全体でお互いの状況を把握できるようにしています。
入社してからの失敗と学び
入社してから最初に取り組んだ仕事の一つが、Amazon GuardDuty Malware Protection for S3 の有効化と、マルウェア検知時にファイルを制御する仕組みの実装でした。 スキャン機能と必要な AWS リソースを Terraform で構成し、検知後のファイル制御を Go で実装しました。
Terraform や Go を本格的に扱うのは今回が初めてで、技術的に未知の部分も多い仕事でした。
今振り返ってみると、実装そのものよりも仕事の進め方について多くの気づきを得た経験でもありました。
そのきっかけになったのが、実装中に経験した二つの手戻りです。
実装を進めてから生じた手戻り
一つ目は、マルウェア判定されたファイルを削除する運用設計における手戻りです。
マルウェア判定されたファイルは通常の経路から読み取れないようにした上で、検知後は通常の利用経路から切り離し、必要に応じて担当者が所定の手順で対応する運用としていました。
当初は、その削除操作を Lambda を介して行う構成を考えていました。コンソールから手動で削除するよりも、必要な操作を仕組みに寄せた方がオペミスを減らせると思ったからです。
その方針で実装を進めていましたが、レビューの中で運用方法について改めて議論する機会がありました。
Lambda を追加すると、実装だけでなく運用や保守のコストも増えます。一方で、削除操作は日常的に発生するものではなく、あくまで例外対応です。
そのため、オペミスを防ぐ効果と追加で発生するコストを比較した結果、このケースでは新たな仕組みを追加せず、既存の運用手順で対応する方が現実的だと判断しました。結果として、実装途中で Lambda を追加する案を取りやめることになりました。
もう一つは、検知後の制御、つまり自動化すると決めていた部分の実装における手戻りです。
AI と対話しながら実装を進めると、冪等性や誤削除を防ぐための対策が提案されます。「このケースも起こり得るなら対応しておこう」と考え、提案された対策を取り入れていった結果、コードは当初の目的に対して必要以上に複雑になってしまいました。
コードレビューで「本当にそこまで必要なのか」と問いかけられたことで立ち止まり、運用上本当に必要な処理と、将来起こるかもしれないリスクへの過剰な備えを切り分けました。
発生頻度や影響、実装・保守コストを整理し直し、最終的な実装はかなりシンプルになりました。
手戻りを減らすために必要だと感じたこと
今回の二つの手戻りは、技術的な難しさによるものではありませんでした。
原因はいずれも、実装前に決めておくべき事項の整理不足と、その判断を適切なタイミングで共有できていなかった点にあります。
実装前の設計・判断に時間を使う
Lambda を追加しようと考えたとき、私が見ていたのは主に「オペミスを減らせるか」という観点でした。
しかし、今回の運用を考えるにあたっては、削除が発生する頻度、誤った操作による影響、手動で対応する場合の手順、Lambda を実装・維持するコストなどを踏まえて、総合的に判断する必要がありました。
同じことは、冪等性や誤削除への対策にも当てはまります。リスクがあるからといって、すべてに対策を講じるのは現実的ではありません。
今回のスコープでどのリスクに対処し、どのリスクは受容するのか。その線引きを、コードを書く前に決めておくべきでした。
ちょうどこの手戻りを経験していた頃に、LayerX バクラク事業部 CPOの mosa さんによるスライド 「機能を作るな。楽して作るな。」 を読みました。
作ったコードや仕組みは、実装した時点で終わりではなく、動作確認や運用、将来の変更まで含めて、長く保守コストを払い続けることになります。
低頻度な運用のために Lambda を追加しようとしたことも、過剰なリスク対策でコードを複雑にしてしまったことも、「作れるから作る」方向に判断が寄ってしまっていたのだと振り返っています。
AI の活用によって、多くのリスクや対策の候補を知ることができるようになりましたが、その一方で、提案された対策を深く検討しないまま取り入れてしまうこともあります。
今回も、それらを十分に比較する前に取り入れてしまった結果、必要以上に実装を複雑にしてしまいました。
AI は多くの選択肢を示してくれますが、それらが今回の目的に照らして本当に必要かどうかは、自分で判断しなければなりません。
ただ、その判断は決して簡単ではありません。未知の領域ほど、その提案が今回の目的や運用に適しているかを見極めること自体が難しいからです。
AI を活用していく上では、自分自身も技術への理解を深め、判断の質を高めていくことが欠かせないと実感しました。
判断を早めに共有する
もう一つの反省は、方針を見直すタイミングが遅かった点です。
今回の手戻りも、実装を進めてから運用や方針について認識を合わせることになったことが、一因だったと感じています。
要件定義や設計の段階で、想定する運用、選択肢、未確定の点を、関係者が判断できる粒度で共有していれば、より小さいコストで方針をそろえられたはずです。
前職でも関係者と相談しながら仕事を進めていましたが、一人情シスだったことや組織規模が今より小さかったこともあり、自分である程度の範囲まで進めることが多くありました。
一方で、現在はチームで働き、関わるステークホルダーも増えています。
成果物だけではなく、判断の途中段階から共有し、早いタイミングで認識を合わせることが、結果として手戻りを減らし、目的に見合う実装につながると実感しました。
おわりに
入社して数ヶ月、技術そのもの以上に、仕事をどう進めるかを学ぶ毎日です。
今回の経験を通じて、「何を作るべきか」だけでなく、「何を作らないか」を考え、早い段階でチームと認識を合わせることの重要性を実感しました。
前職で身につけた仕事の進め方がそのまま通用する場面もあれば、環境が変わることで見直す必要がある場面もあります。
これからも新しい技術に挑戦しながら、チームで価値を出す仕事の進め方へ、自分自身も更新し続けていきたいと思います。
一緒に働く仲間を募集しています！
MDMでは、コーポレートITを起点に、プロダクトコードやAWS基盤へ手を動かしながら、SRE、セキュリティ、金融業務まで領域を広げられます。
情シスのみならずセキュリティ・ITガバナンスの領域で、課題を解決することに興味がある方がいらっしゃれば、ぜひご連絡ください！
