日本とイギリスを同じ環境にする。
段階的更改プロジェクト。

Y.I） 今回お話しするのは、半導体メーカー様のイギリス拠点にあるデータセンター基盤を更改するプロジェクトです。5年前に導入した機器が保守期限を迎えるため、サーバ、ストレージ、ネットワークを段階的に置き換えていくことになりました。

T.M） 一度にすべてを止めるわけにはいかないので、何回かに分けて置き換える形でしたね。

Y.I） 私は2026年の1月に仮想基盤の更改で、7月にはネットワーク機器の更改に合わせて渡航しました。実は、日本のお客様向けに構築した基盤とイギリスの基盤は同じ構成なんです。私は日本側環境のサーバリーダーを担当していたので、そのまま担当することになりました。

T.M） 日本での知見がそのまま活きる形だったんですね。私は上司から「こういうプロジェクトがあるんだけど、どう？」と声をかけられ、7月にネットワークのサブ担当として参加しました。

Y.I） 率直にどう思われましたか。海外の案件って、とくに若手のうちは、そう何度もある話ではないですよね。

T.M） 不安4割、楽しみ6割くらいでしたね。もともと、初めての経験にはワクワクするタイプ。海外の案件も初めてだったんです。ただ、海外ならではの難しさはありました。まず時差です。現地では日本の夕方くらいの時間から仕事が始まる感覚なので、慣れない最初の数日は、チーム全員がすごく眠そうで。

Y.I） 現地へ行っているときに何か確認したいことが出てきても、その時間、日本側は誰も働いていないから質問できない。そこは大きな違いでした。

T.M） 言語もそうです。お客様は日本企業の方ですが、現地のベンダー企業とのコミュニケーションは英語です。私は英語が話せないので、他のメンバーに通訳してもらっていました。

Y.I） 私も流暢ではなくて、知っている単語を拾って会話するレベルです。それでも自分から積極的にコミュニケーションをとるよう心掛けてはいました。

想定外の事態でも、日本のメンバーが支えてくれた。

Y.I） T.Mさんにとって、今回いちばん印象に残っているのはどんな場面でしたか。

T.M） 想定外の対応は、勉強になりましたね。限られた時間で進めるので、想定と実際が異なっていた場合、影響が大きい。今回は、ネットワーク機器がメーカーの仕様どおりに動作しない事象がありました。日本のチームとリモートで相談しながら、一緒に動作不良の原因を特定して。結果的には、メーカーからも公開前だった、機器そのもののバグだったことがわかりました。

Y.I） メーカーの公開前だと、自力で調べてもなかなか情報は得られない。目の前で起こっていることから、推察して原因を特定する難しさがありますね。日本のメンバーとは、どういうやりとりを？

T.M） チャットが中心で、必要なときは時差の中でも電話をして。「これを試して、結果を送ってください」「次はこれを試してください」と、提案してもらいながら試行錯誤しました。最終的には、予定していた作業を問題なく完了できました。

Y.I） 現地にいるメンバーだけで抱え込まず、みんなの知識と技術力で解決する。KTSの強みが出た場面だったと思います。

T.M） まさにそう感じました。だからこそ、みなさんとの情報共有は早い方がいいのだと学びました。共有が遅れると、状況がどんどん見えにくくなり、その後の対応の選択肢が狭まってしまう。

Y.I） 多くの学びを得ていますね。

T.M） はい。想定外の事態に対応する力を得られた一方、そもそも想定していなかった事態で慌てないために、起こり得ることをできるだけ先に洗い出しておくことも必要だと学びました。そこは経験によるところも大きいので、現在は作業前に、先輩からレビューをもらっています。

Y.I） 私から見ていても、T.Mさんはタフだなと思っていました。初めての海外なのに、不安そうに見えるどころかワクワクしているように見えて。遅くまでかかる日も、疲れた姿を見せずにやり切っていました。

T.M） ありがとうございます。時差に慣れないうちは、本当に疲れている日もありましたけど（笑）。

技術者自身が、お客様の意思決定までサポートする。

T.M） Y.Iさんは今回、お客様の意思決定をしやすくすることを重視されていた、と聞きました。

Y.I） サーバ担当は環境を包括的に見る立場です。想定外のことが起きればお客様も困る。だからすぐ状況を報告し、そして報告するだけでは終わらず、その後の方針提案まで一緒に意思決定し、やり切ることを心がけていました。

T.M） 海外だからこその難しさもありましたか。

Y.I） 現地の商習慣と言いますか、予定していた納品日に、必ずしも納品が完了するとは限らないんです。今回も、届く予定だったサーバの到着時期が変わりました。その際はすぐにお客様と打ち合わせを設定し、対応を判断。お客様の社内でも議論しやすいよう、取れる選択肢と、それぞれのメリットデメリットまで説明できるよう準備していました。

T.M） そういった力は、どのように身につけたのでしょう。単なる技術者としての力以上に、お客さまと向き合う力が必要になりますよね。

Y.I） 普段から、設定の背景を考えようと意識しているのは大きいかもしれません。こういう要件があるからこの設定なんだ、と背景を理解しておくと、想定外のときにも、どのような影響があるか、何を変えればいいか、考えやすくなります。それから、お客様のチームを把握することも意識しています。お客様側がどのような体制で動いていて、目の前のご担当者様がその体制の中でどのような役割を担っているか。お客様のチーム全体が動きやすい提案をすることにつながると考えています。

T.M） 今回、成果として大きかったと感じるのはどこですか。

Y.I） ネットワークが全面的に置き換わるタイミングで、配下のサーバをすべて停止・起動・動作確認する必要がありました。全システムに触れるということは、仕様を理解し、どうすれば正常性を確認できるかまで分かっていないといけない。おかげで全体像の理解が深まりました。

T.M） 達成感を感じたのは？

Y.I） プロジェクトが進むにつれて、お客様が困ったときにまず私に相談してくださるようになったことです。課題を指摘して終わるのではなく、解決策を一緒に考え、やり切ることで信頼関係が築けたことを感じました。

T.M） ところで、Y.Iさんは文系出身で、元々IT系の知識はなかったと聞いています。この仕事を選んだのはなぜだったんでしょう？

Y.I） 実は、今お話したように、何か事業で価値を生み出したり、お客様の課題を解決したりすることに、元々興味がありました。しかし、それを実現するために、何か自分でもひとつ、使える技術を身に着けたい。就職活動の際にそう考え、技術職を選びました。ですから、現在自分の技術を活かしながらお客様とともに課題解決ができる仕事は、まさにやりたかったことのひとつなのです。

それぞれの現在地から、それぞれの技術力を磨き、次の現場へ。

T.M） 今回、「KTSだからできた」と感じたのはどんなところですか。

Y.I） イギリス現地で、適切な判断できたことだと思います。日本側にすぐ連絡がつかない時間帯もある中で、「現場判断でいいよ」と任せてもらえたのはありがたかったです。お客様からも「予期せぬ事態にも柔軟に対応してもらえた」と評価をいただきました。

T.M） 私は、日本のチームを適切に頼れたことです。ネットワーク、サーバ、ストレージとそれぞれ専門を持つ技術者がいて、インフラ全体を一貫して見られる。しかも保守まで担当しているので、運用や障害対応まで意識した提案ができる。それがKTSの技術力だと思います。

Y.I） T.Mさんは、今後のキャリアをどのように考えていますか。

T.M） 今は小規模案件でメイン担当を任せていただく機会が増えてきたので、そこで経験を積んで、いずれは大きな案件でもメインを担当したいです。技術面だけでなく、事前準備やスケジュール管理、お客様との調整まで含めて、自分で判断して進められるエンジニアになりたいですね。

Y.I） 私も同じでした。経験していないことは予想がつかないんですよね。だからこそ若いうちは現場に出て勘どころを増やしていく。設定ひとつでも「なぜこれを入れるんだろう」と考えながら動いていくと、メイン担当としてすごく活躍できると思います。......少し老婆心ですが（笑）。

T.M） ありがとうございます。Y.Iさんの目標も伺いたいです。

Y.I） お客様が困っていることと技術側が困っていることの間に立って、適切な意思決定をしてプロジェクトを成功させられるリーダーになりたいです。サーバの専門性を深めつつ、環境全体を俯瞰して見る。そこにお客様側の視点を組み合わせられれば、お互いがWin-Winで進められる橋渡しになれるのかなと思っています。

T.M） 私は、起こりうることを先に想定して備えることが、結局はお客様への責任につながるのだと学びました。まずはそこを確実にできるようになりたいです。

Y.I） 技術力という言葉の中身は、立っている場所によって違うのかもしれませんね。私にとってはお客様が判断できる状態をつくること。T.Mさんにとっては想定外に備える体制をつくること。どちらも手を動かすだけでは届かないところにある。そこを目指し続けたいです。