インフラを管理する側から、作る側へ

この記事では、IT管理の仕事からバックエンド・インフラエンジニアに転向してみて意外だったこと、そして思っていた以上に役に立ったスキルについて書いてみます。

数年間、私はIT管理の仕事をしていました。毎日コードを書くわけではなく、会社がスムーズに回るようにするのが役割でした。ユーザーアカウントや権限の管理、海外のITチームとの調整、そして組織全体が使うツールの選定などです。

新しいEDR（エンドポイント検知・対応）やMDM（モバイルデバイス管理）を導入するときは、製品の比較検討からPoCの実施、全拠点への展開のリードまで担当していました。

今は、バックエンド・インフラエンジニアとして働いています。

技術的に馴染みのある部分もありますが、仕事の中身はまったくの別物です。振り返って一番意外だったのは、学ばくてはいけないことの多さ……ではなく、これまでの経験が今も毎日のように役立っていることでした。

同じツールを、違う立場から見る

個人的に一番面白いと感じているのが、かつて自分が管理していたツールを、今度は使う側で触っていることです。

IT管理者だった頃は、JiraやConfluence、Miroをはじめ、いくつものSaaSを管理していました。プロジェクトの設定や権限の管理、ライセンスの割り当て、それに「このボードにアクセスできない」「このスペースに追加してほしい」といった依頼への対応もしていました。ツールのことは隅々まで分かっているつもりでしたが、それはあくまで"管理者としての視点"でした。

でも今は、ただの一ユーザーです。

スプリントプランニングでJiraのチケットを動かし、Miroで設計のアイデアを出し合い、チームのみんなが実際に読んでくれるドキュメントを書く。管理していたときと使っているときとで、同じツールなのに感じ方がこんなに違うのか、とちょっと面白くなります。

この立場の変化は、新しい視点もくれました。裏側の仕組みが分かっているので、なぜ権限が足りないのか、なぜワークフローがこう動くのか、だいたい見当がつきます。その一方で、使う側になってみて、昔の自分が下していた管理上の判断が、毎日ツールを使う人たちにとっては地味にストレスだったんだろうな、とも気づきました。

小さなことですが、大事な学びでした。両方の立場を経験すると、関わる人みんなの気持ちが自然と分かるようになる、ということです。

IT管理から持ち込めたもの

ITからソフトウェアエンジニアへの転向は「ゼロからのやり直し」だと思われがちです。でも、私の場合はそうではありませんでした。ITで身につけたスキルの多くが、思った以上にそのまま活きています。

EDRやMDMの導入は、ソフトを入れて終わり、ではありませんでした。要件をまとめ、ベンダーを比較し、試験導入をして、展開を計画し、ユーザーとやり取りし、導入後のサポートまでやる。これは、機能をアイデアから本番まで届けるソフトウェア開発と、そんなに変わりません。

海外のITチームと働いた経験も、分かりやすく伝えること、決めたことを記録に残すこと、非同期で仕事を進めること、文化や時差を越えて協力することを教えてくれました。こうしたスキルは、エンジニアリングでもITのときと同じくらい大事です。

セキュリティも一つの例です。ID・権限・アクセス権を何年も管理してきたおかげで、最小権限、認証、認可といった考え方は体に染みついています。違うのは、今はそういう仕組みを"設定する"側ではなく、"作る"側にいることです。

仕事の向きが変わったんですね。以前は誰かが作ったツールを運用する立場でしたが、今は自分でシステムを作れる立場になりました。

AI時代にエンジニアになるということ

一つ、予想していなかったことがあります。AIが驚くほど良いコードを書けるようになった、まさにそのタイミングで、私はエンジニアになりました。

少し前まで、開発者はまず「書いたコードの質」で評価されるものでした。でも今は、AIがきれいに動くコードを数秒で書いてしまうこともあります。

そこで自然と、こんな疑問が浮かびます。コードをAIが書くなら、エンジニアはどこで価値を出すのか？

これについてはずいぶん考えました。そして、シンプルな結論にたどり着きました。価値は、もうコードを書くことだけにはない。その"まわり"すべてにある、ということです。

機能を最初から最後まで自分ごととして持つことは大事です。AIは関数を生成できても、ビジネスの背景を理解したり、チームと連携したり、本番にデプロイしたり、リリース後にその機能を支えたりはできません。

チームを助けることも、同じくらい大事です。ソフトウェアはみんなで作るものです。コードをレビューしたり、知識を共有したり、ドキュメントを良くしたり、詰まっている人を助けたり。そういうことが、チーム全体の力を底上げします。

そして、たぶん一番大事なのがクライアントを理解することです。クライアントが本当に必要としているものをそのまま言葉にしてくれることは、めったにありません。これはエンジニアになるずっと前、会社全体のツールを選んでいた頃に学びました。最初の要望の裏にある"本当の課題"をつかみ、前提を疑い、ビジネスのゴールを技術的な判断に落とし込む。ここはまだ、人の判断が必要な部分です。

AIはとてつもなく便利な道具ですが、こういう"理解"の部分までは代わってくれません。

むしろAIは、「良いエンジニアとは何か」の意味を変えたのだと思います。コードを書くことは今も大事ですが、それだけでは足りなくなりました。

おわりに

インフラを管理する側から作る側へ移ったことは、これまでのキャリアで特に良かった決断の一つです。

これまでの経歴は、足かせになるどころか、しっかりした土台になってくれました。プロジェクトを自分ごととして進める姿勢、海外チームとの協働、セキュリティの感覚、そして自分たちが作るシステムを使う人への理解です。

AIの台頭と同じ時期にエンジニアのキャリアを始めたことは、思いがけない形で強みになりました。最初から、コードを書くこと以外のスキルに向き合わざるを得なかったからです。課題を理解すること、機能を最初から最後まで見届けること、そして周りの人がうまくいくように手を貸すこと。

もし今ITの仕事をしていて、次はエンジニアかな……と迷っているなら、こう言いたいです。あなたはたぶん、自分で思っている以上に"活かせるスキル"を、もう持っていますよ。

Article Photo by Brett Sayles on Pexels