【後編】「もっち」のプロフィール（関西大阪〜東京転勤編）

2026年1月1日2026年2月8日

今回、このブログの作者である「もっち」のプロフィールを紹介したいと思います。

私は現在、関東の大手SIer企業でITサービスマネージャとしてサーバの運用管理を担っていますが、もともとは中部での採用でした。

そこで、私の幼少期から現在までのプロフィールをまとめましたので、お時間のある時にでもテキトーに斜め読みしたり、興味のある部分だけを読むなどしていただければ幸いです。

長いので前編（学生時代編）、中編（新人研修〜中部配属編）、後編（関西大阪〜東京転勤編）に分けています。今回は後編（関西大阪〜東京転勤編）となります。

関西で経験した基盤移行とサービス提供

大規模移行プロジェクト

私は、大手製造メーカーのオンプレミス環境をデータセンターの仮想化基盤（VMware）へと集約する「P2V（Physical to Virtual）移行プロジェクト」への誘いを受け、中部地方から関西・大阪へ異動となりました。

ここでの業務は、全国に存在する大手製造メーカーの工場を管理するサーバを自社のデータセンターへ移行することです。

もともと、このメーカーは工場ごとに、その工場内のオンプレミスサーバとして管理システムが存在していました。その各システムをすべて自社のデータセンターへ集約して、管理業務の一元化を目的としています。

私は顧客の拠点を一つひとつ巡り、長年その場所で稼働し続けてきた物理サーバーたちを仮想サーバーへと生まれ変わらせる役割を担いました。

チームで挑んだ約100台の移行計画

移行プロジェクトの中で、特に忘れられない出来事は、3日間という極めてタイトなスケジュールの中で100台近くのサーバーを移行させた移行計画です。十分な準備期間をかけ、手順書、設定シートを整備し、リハーサルも行いながら迎えた移行本番、順調に進むと思われた矢先、特定の古いサーバーでP2V処理中にエラーが発生したのです。計画通り進捗しない事態で、ここまま計画が失敗に終われば、移行計画全体に影響が出てしまいます。

移行チームは移行手法を何度も組み替え、パラメーターを微調整し、トライ＆エラーを繰り返しました結果、最終的にすべてのサーバーをP2V移行することができました。

しかし、問題はそれだけではありませんでした。データセンターの仮想環境へ移したサーバー群を、監視システムがどうしても認識してくれない状態が発生したのです。設定は正しいはずなのに、画面上にはエラーが出力されてしまいます。「原因は必ずどこかにある」チーム全員でデータセンターに籠もり、徹夜で膨大な設定ファイルを一行ずつ洗い出しました。

極限状態の中、ようやく、わずか一行の設定不備を見つけ出しました。その不備を修正し、すべての監視ランプが正常な緑色に点灯した瞬間、窓の外には朝日が昇っていました。技術は時に冷徹ですが、それを動かすのは人間の泥臭い執念なのだと、この大阪の現場で叩き込まれました。

サービス提供型の基盤運用の挑戦

移行プロジェクト完了後は、データセンター勤務のインフラ運用メンバーとして、数百台規模の仮想化基盤をIaaS（Infrastructure as a Service）としてサービス提供する業務に従事しました。

物理サーバーが十数台、その上で動く仮想サーバーは数百台。提供するリソース容量に応じたサービス提供型の課金体制という、よりビジネスに近い視点でのインフラ管理を経験しました。

業務内容としては、日々のリソース管理や仮想化基盤のOSバージョンアップ、物理メモリの増設といったメンテナンスに加え、この時期に私は「自動化」の魅力に取り憑かれます。

スポット案件として対応した、AWSを用いた小規模システムの構築や、仮想サーバー作成や監視設定を自動化するシステムの実装など「昨日まで手動で30分かかっていた作業が、プログラム一行で数秒に終わる」そのような経験によって、私のエンジニアとしての視座は、より上位の「仕組み作り」へと向かっていきました。

より大きな成長機会を求めて

初めて中部から大阪駅に降り立った際、駅を行き交う圧倒的な人の流れに翻弄された記憶を今でも鮮明に覚えています。中部から関西、特に大阪で経験した業務・体制における規模の違いに驚かされました。しかし一方、同時にこうも考えていました。

「日本のIT需要の半数以上は関東に集中している」

現在、日本を代表する大手ITベンダー（富士通、NEC、NTTデータ、日立等）や外資系企業（Google、AWS等）の本社はほとんど東京に存在しており、それに伴いIT企業や人材、その需要は関東一帯に一極集中している状況です。

私が初めて中部から大阪へ来た時に感じた圧倒的な規模感を、さらに大きな規模を誇る東京で間近で感じたいと考えるようになりました。

より大規模な市場、より大規模な体制。そこで自分を試したいという強い思いと単に用意された基盤を運用するだけでなく、その基盤そのものをどう定義するかという「運用設計」の領域に踏み込みたい。その一心で、私は自ら東京転勤を志願しました。

運用リーダーとしての挑戦

基幹系システムの仮想化基盤への統合

東京で待っていたのは、大手通信サービス企業の基幹系システムという、かつてない規模のシステムでした。

私が配属されたのは、オンプレミスで稼働する複数の基幹システムを一つの仮想化基盤上に統合するというプロジェクトです。移行後の基盤上で稼働する仮想サーバーは約200台、システム数は10システムほどです。その中で私は「非機能要件」を策定するというチームに入ることになりました。

関西で培った「現場での経験」を運用基盤の整備に注ぎ込み、システムひとつひとつの要件の洗い出しとフロント部署とのすり合わせを行いながら、プロジェクトを完遂させることができました。

初めて構築部隊のメンバーと業務をする中で見えてきたことは、大規模システムにおける管理ドキュメントの重要性でした。システムの規模が大きくなればなるほど、全体を俯瞰してみることが困難になるため、システム全体を統一的な設計方針によって一貫性をもたせた設計とすることが非常に大切だと感じました。

サービスマネージャーとしてのインフラ運用

基盤が完成し安定稼働に入ると、私の役割は「インフラ運用部隊のリーダー」へと大きく舵を切りました。ここで求められたのは、単なる技術力だけではありません。自社内のフロント部署との調整、保守ベンダーへの指示、チームマネジメント、さらにはエンドユーザーである大手通信企業の担当者とのフロント対応も含む、いわゆるサービスマネージャとしての役割です。

その日以来、毎月の月次報告、突発的な障害発生時の緊急報告が発生し、フロント部署とともに直接顧客の元へ出向き、インフラの現状と対策を説明する日々が続きました。

また、スポット対応として、仮想化基盤のOSバージョンアップや全サーバーへのセキュリティパッチ適用といった大規模作業では、エンドユーザ企業に対して、計画・体制の説明と進捗報告が求められました。「技術のことは分からない」という相手にも、いかにして「安心」を届けるか。専門用語を日常の言葉に翻訳し、リスクとメリットを誠実に伝える。顧客の担当者と一対一で向き合い、信頼を勝ち得ていくプロセスは、コードを書くこと以上にスリリングで、やりがいのある仕事でした。

リーダーとして感じたこと

現在、私はチームを率いるリーダーとして、「常に主体的であってほしい」伝えています。作業の背後にある「意図」と「背景」を理解し、主体的に動くこと。それが結果として、個人の成長を加速させ、システムの品質を高めると信じているからです。

そして、私が最も強く意識しているのは、「ミスを個人の責任にしない」という姿勢です。中部時代に自分自身がミスを犯し、震えるような恐怖を味わった経験。大阪で徹夜して不具合を探した苦労。それらがあるからこそ、失敗が起きた時には「なぜその人がミスをしたか」ではなく「なぜそのミスが起きる仕組みになっていたか」を組織として徹底的に考えるようにしています。

いくら個人の責任を追及しても、そのチーム自体は良くなりません。仕組みを改善し、対策をチーム全体で共有することで、組織として品質を向上させることができるのです。

「組織としてどう対応するか」という考え方こそが、大規模インフラ運用を預かるサービスマネージャとして、私が日頃から大切にしていることです。