古野電気グループの試験機関、ラボテック・インターナショナル株式会社。舶用電子機器の総合メーカーが長年培ってきたEMC試験や環境試験、対策のノウハウを受け継ぎ、電波の影響や温度・振動への耐性を公正中立な立場から確かめています。国際規格ISO/IEC 17025にもとづく試験所として認定を受けており、同社が発行する試験報告書や校正証明書は、国境を越えてそのまま通用します。
同社のシステムを長く支えてきたのは、親会社である古野電気のIT部門でした。しかし古野電気との相談を経て、社外向けのシステムの管理は自社で担うことになります。その最初の対象として選んだのが、取引先が日々利用するWeb閲覧システム。オンプレミスからAWSへの移行を決めました。ただし、社内にクラウド専任部署はないものの、従来より社内IT基盤やネットワーク管理に携わっていた事業企画部の村川さんを中心に、関係部門と連携しながら移行プロジェクトを進めることになりました。
クラスメソッドが引き受けたのは、AWS環境の設計と移行後の運用監視です。構築は村川さんが自ら手を動かし、その過程で生じる疑問にクラスメソッドが答え続ける。専任の部署を持たない企業が、外部の専門家と役割を分け合いながら、自社でクラウドを運用する体制をつくる。その過程の記録です。事業企画部の村川さんにお話をうかがいます。
インフラを引き受けた試験部門の担当者
きっかけは、Web閲覧システムを支えるOSが、サポート終了を迎えることでした。この状況を伝えたのが、フルノソフテックです。古野電気グループで組み込みソフトウェアの開発を手がけ、ラボテック・インターナショナルのシステムについては、長く保守を担ってきたパートナーにあたります。
当初は、OSを新しいものへ入れ替えれば済むと考えられていました。しかし検討の結果、その方法は見送られます。そこで村川さんは、親会社である古野電気のIT部門に相談を持ちかけました。返ってきたのは、想定とは異なる方針です。社外向けのシステムは、ラボテック・インターナショナルで管理してほしい。あわせて、クラウドサービスの活用を検討してはどうか。こうして、システムの管理を自社で担うことになりました。
その担い手となったのが、村川さんでした。本来の担当は、試験部門の業務です。ただ、社内のネットワークやIT機器の管理にもかねてから携わり、運用面で中心的な役割を担ってきました。こうした領域に社内で最も明るいのは、村川さんだったのです。
とはいえ、インフラの専門家ではありません。実際に手を動かして基盤を築くのは、初めての経験です。試験部門の担当者が、取引先の使うシステムの移行を担う。ここから、プロジェクトが動き出します。
セキュリティを起点にした選択
クラウドへの移行は、村川さん自身にとっても急ぐべき課題でした。背景にあったのは、セキュリティへの強い危機感です。
「AIの普及やサイバー攻撃の高度化を背景に、継続的なセキュリティ対策と迅速なアップデートが求められる時代になっています。そうした時代を見据えると、より柔軟にセキュリティ対策を強化できるクラウド環境への移行を検討しました。」（村川さん）
さらに、村川さんには具体的な懸念がありました。近年、セキュリティの手薄な子会社や取引先を入口に、その先の大企業を狙う攻撃が目立ちます。ランサムウェアの被害も後を絶ちません。
「当社はグループ会社の一員として、取引先やグループ全体の信頼を支える立場にあります。そのため、より高い水準でセキュリティリスクを備える必要があると考えました。セキュリティを最優先に据えた理由は、そこにあります」（村川さん）
親会社を含むグループ全体の安全を考えたとき、今後も継続的にセキュリティ対策を強化できる環境が必要でした。その実現手段としてAWSへの移行を選択しました。
クラウドの中でAWSを選んだ理由は、明快です。親会社の古野電気が、すでにAWSを採用していました。実績のある基盤であることは、何よりの安心材料です。そして、この移行をともに進める相手が、クラスメソッドでした。古野電気を通じた紹介がきっかけです。
ここで、村川さんには気がかりなことがありました。構築したシステムを、この先どう見守っていくか。運用の経験がない村川さんにとって、移行後の監視は不安の残る領域です。その懸念に応えるように、クラスメソッドは設計だけでなく、移行後の監視・運用を担うクラスメソッドマネージドサービス（MSP）もあわせて提案しました。
「設計から関わってくれた相手が、そのまま監視まで引き受けてくれれば、いざというときの対応も速い。案件ごとに依頼先が分かれていては、その調整だけで手一杯になります」（村川さん）
社内の中心担当者として運用を推進する村川さんにとって、設計から監視までを一社に任せられることは、大きな意味を持ちました。
設計を託し、構築は自らの手で
プロジェクトの役割は、明確に分かれていました。AWS環境の設計を担うのがクラスメソッド。その設計をもとに実際に構築するのが、村川さんです。アプリケーションについては、保守を担ってきたフルノソフテックが引き続き受け持ちました。
構築に取りかかった村川さんを、最初に待っていたのは、AWSという未知の領域でした。
「CloudFrontやWAF、S3は、名前と役割をある程度把握していました。しかし、そこから先は馴染みのないサービスばかりです。まずは、それぞれが何を担うのかを理解するところから始めました」（村川さん）
その1つひとつの意味を確かめながら、村川さんは構築を進めていきます。この時、設計内容を確認する進め方にも工夫がありました。
「設計書を渡されても、AWSに不慣れな私には、その内容が妥当かどうかを判断できません。そこで、先に自分で構築して動作を確かめ、仕組みを理解できた段階で完了とする進め方を提案しました。手を動かしながら確認することで、設計の意図まで腹落ちさせることができました」（村川さん）
クラスメソッドは、この申し出を受け入れます。図面の段階で判断を求めるのではなく、実際に動くところまで見届けて納得してもらう。村川さんの理解の歩みに寄り添う対応でした。
やり取りの多くは、Backlog上で交わされました。村川さんが高く評価したのは、その反応の速さです。
「早い時には、1時間ほどで回答が届きます。まず『確認します』と一報があり、その後に届く内容も、こちらが知りたかった要点が的確に整理されていました」（村川さん）
こうして構築は進んでいきます。ところが移行を目前に控えたある日、予期せぬ事態が持ち上がりました。
その場しのぎで終わらせない
移行の準備が大詰めを迎えた頃、導入作業中だったMSPの監視がCloudFrontで特定のエラーが繰り返し発生していることを検知します。運用開始前で自動通知はまだ稼働していませんでしたが、クラスメソッドは状況を整理し、想定通りの挙動かどうかの確認を村川さんへ連絡しました。
当時、村川さんは構築作業に追われ、この通知をいったん脇に置いていました。しかし、放置できる問題ではありません。自ら原因を調べ始め、対処の見当をつけていきます。
「自分で調べ、『通信のタイムアウトの設定に原因があるのではないか』と見当をつけて、クラスメソッドに相談しました」（村川さん）
自分の見立てどおりに設定を変えれば、解決する。村川さんには、そんな手応えがありました。ところが、クラスメソッドの反応は違います。提示された案をすぐに採用するのではなく、まず原因を正確に切り分けるべきだ、と伝えたのです。
移行の期日は、刻一刻と迫っていました。
「すぐに設定を変えるのではなく、待つように言われるとは思ってもみませんでした。期日が迫るなかで『間に合うのだろうか』と焦りを覚えました」（村川さん）
クラスメソッドが性急な変更を避けたのには、明確な理由があります。設定を変えれば、表面上の不具合は収まるかもしれない。しかし、なぜ直るのかを理解しないままでは、ラボテック・インターナショナルが今後、自社で同じような事態に対応できなくなる。支援できる期間のうちに、根本の原因を突き止め、その追い方ごと村川さんに手渡しておく。それが、クラスメソッドの狙いでした。
「目先の事象が解決しても、根本を理解していなければ、この先で必ず苦労します。技術者の視点からそう指摘を受け、原因の切り分けから取り組むよう勧められました。この助言は、私にとって大きな意味を持ちました」（村川さん）
村川さんは、クラスメソッドとともに原因を追い、対処へとたどり着きます。そして、この過程そのものが、村川さんに確かな財産を残しました。
「一連の対応は、貴重な経験になりました。ログを解析する手法まで教わり、身につけることができたのです」（村川さん）
移行は、予定どおりに完了します。目先の答えではなく、自分自身で原因を追う力。村川さんがこの時に手にしたものは、このあと大きな意味を持つことになります。
監視と二人三脚で築く運用体制
移行を終えると、24時間365日の監視体制が動き出しました。稼働して間もない頃は、エラーの通知が頻繁に届きます。村川さんは、まずその内容を1つずつ確認するところから始めました。
「動き始めた当初は、エラーが頻繁に届きました。まず内容を確認し、次第にその中身がわかり、対処の方法も見えてきたのです」（村川さん）
エラーの多くは、外部からのボットによるアクセスでした。旧環境に向けられていた古いアクセスが、新環境には該当する場所がないため、エラーとして次々に記録されていたのです。村川さんは、それらが悪意のあるものか、検索エンジンなどの正規のものかを、1つずつ切り分けていきました。この切り分けを行ったのは、クラスメソッドとの契約期間を終えたあと。村川さんが、自ら調べて対応したものでした。
移行直前に、原因の追い方ごと手渡された経験が、ここで生きています。今では、自らの手で新たな仕組みも整えました。
「AWS上にダッシュボードを構築し、どのIPからアクセスが来ているのか、どのパスが狙われやすいのかを、日々確認しています」（村川さん）
もっとも、村川さんがすべてを1人で抱えているわけではありません。異変を最初に捉えるのは、24時間の監視です。監視が検知し、村川さんがその意味を読み解く。この分担があるからこそ、専任の部署を持たない体制でも、システムは安定して動き続けています。移行後も大きな利用者への影響やサービス障害は発生しておらず、安定した運用を継続しています。
セキュリティの水準も、大きく高まりました。安心して顧客にサービスを提供できる基盤が整ったのです。
支援は、次のステージへ
試験部門の業務と兼務しながらの構築には、相応の難しさがありました。その中で村川さんが支えと感じたのが、要所を確認しながら進める、丁寧な進捗管理だったといいます。記録を残す余裕のない事情まで汲んだ対応も含め、一連の関わりを村川さんはこう表現します。
「伴走支援という言葉が、まさにふさわしい進め方でした」（村川さん）
移行を終えた今、村川さんの視線は先へ向いています。AWSという基盤を得たことで、対応できることは大きく広がりました。
「AWSへ移行したことで、実現できる選択肢が一気に増えました。現在は、その可能性をどう生かしていくかを考えている段階です」（村川さん）
同時に村川さんが見据えているのは、自分1人に依存しない体制づくりです。
「いずれ、私が中心となって対応する体制から変わる時が来ます。その時に備え、後任がスムーズに引き継げるよう、今のうちから土台を整えているところです。私が積み上げてきたものをそのまま渡すのは難しいため、まずは着手しやすい形に整理しておきたいと考えています」（村川さん）
その先を見据えた時、村川さんは改めてクラスメソッドの支援を思い描いています。
「今後、今回よりも大規模なシステムを整えていく際には、その基盤づくりからお任せしたいと考えています。専門家に支えていただけることの心強さを、今回の移行で実感しました」（村川さん）
ラボテック・インターナショナルは外部の専門家の知見も活用しながら、自社でクラウドを運用・発展させる基盤づくりを進めてきました。今回のプロジェクトは、その第一歩となる取り組みでした。その歩みは、これからも続いていきます。クラスメソッドはこれからも、ラボテック・インターナショナルの挑戦を支援してまいります。
