2ヶ月かけてGoogle Cloud Professional Cloud Architectを取得した話

この記事は BBSakura Networksアドベントカレンダー2025 の16日目の記事です

はじめに

こんにちは、BBSakura Networks株式会社(以降BBSakura)にてエンジニアをしている太田です。

この度、2025年11月末にGoogle Cloudの認定資格「Professional Cloud Architect(PCA)」に合格しました!

本記事では、合格に至るまでの道のり、具体的な勉強方法、そして挑戦して得られた学びについてお話ししようと思います。

Google Cloudの資格について

cloud.google.com

資格の種類は全部で13種類あり、3つのレベルに分類されています。

  • Foundational
  • Associate
  • Professional

私が取得したProfessional Cloud ArchitectはProfessionalレベルの資格の中で、特にGoogle Cloud のサービス全般に関する知識が広く問われるアーキテクトの役割に焦点を当てたものです。同レベルの他資格を取得する前に合格することが推奨されています。

合格に至るまで

勉強時間

約2ヶ月間、平日朝1時間+ 土日にやれる時はやる、くらいのペースで勉強をしました。 おそらく合計で50~60時間程度だと思います。

勉強方法

Udemy

以下の二つのコースに取り組みました。

  • Google Cloud認定 Professional Cloud Architect(PCA) トレーニング

    • Google Cloudのサービス全般をざっくり学んだ後、小テストセクションを繰り返し解きました。
  • [最短攻略] Google Cloud 認定 Professional Cloud Architect 模擬問題集

    • 実践的な問題に数多く触れる機会として活用しました。(一部問題の古さも感じましたが、傾向把握に役立ちました。)

公式模擬試験

cloud.google.com

資格の公式説明ページにある模擬試験は3~4回解きました。

Gemini

解説を読んでもわからないので解説してもらう、または理解を確認する相手として活用していました。Googleが作ったAIですし,,(関係あるかは不明)

公式ドキュメント

模擬試験系でわからない部分やGeminiの回答に納得感がない時、より正確に知りたいときに公式ドキュメントを検索していました。

アップデートが多いので最後に頼りになるのは公式ドキュメントです。最悪の場合、サービスが終了していることがあります。

合格後

感想

模擬試験(Udemy,公式)が最重要

模擬試験から1/3~1/2はほぼ同じ問題が出ているような気がしたので、確実な得点源を確保する上で重要かと思います。

分からない問題は飛ばす

とはいえ残りは初見の問題です。ある程度パターンはありますが、普通に難しい問題もあります。スキップして後で戻って来られるので、ぱっと見でわからない場合、飛ばして後で解くのがいいかと思いました。

ある程度のサービスの理解も大事

初見の問題に対応するためには、やはりサービスの構造的な理解が不可欠です。

特にCompute、Storage、Databaseといった主要カテゴリのサービスについては、「どのサービスを」「いつ」「どのような要件で」選ぶべきかという「決定木(Decision Tree)」を事前に整理し、頭に叩き込んでおくことを強くお勧めします。

点数が公開されないのは悲しい

自分が何点取ったのか、どこを間違ったのかが公開されないのは悲しかったです。復習もできないし、ただ結果だけが出て中身は闇の中に消えている...

挑戦してよかった点

Google Cloud以外の知識の整理にも繋がる

結構Google Cloudに関係ない一般的な用語の勉強にもなります。(ex. ブルーグリーンデプロイメント)

今までの仕事を振り返る時間にもなる

日々の業務に追われていると、よくわからない単語などもあまり深く理解しないまま突き進むこともあるかと思います(意外とそれでどうにかなってしまうため)。

しかし、今回強制的に勉強の時間を取ったことでそのモヤが晴れる感覚を少し得ることができました。定期的にこのような時間を取ることの重要さを知りました。

おわりに

色々と書きましたが、Professional Cloud Architectは全て4択問題で構成されており、世の中に数多あるProfessionalレベルの資格に比べれば挑戦しやすいと言えます。

BBSakuraが運営するサービス「OCX」の接続先としてGoogle Cloudを扱う立場として、今回の資格取得はサービスの全体像を深く理解する良い機会となりました。この学びを活かし、今後の業務に役立てていきたいと思います。

Google Cloudの認定資格は、知識の整理と自身のスキルアップに繋がります。皆様もぜひチャレンジしてみてはいかがでしょうか。

Interop Tokyoで来場者の目を引くために試した施策についてのお話

はじめに

この記事は BBSakura Networksアドベントカレンダー2025 の15日目の記事です。

こんにちは、BBSakura NetworksでOCX開発室に所属している渡邉です。

これまではNW未経験エンジニアの苦労話など、技術的な視点にフォーカスした記事を書かせていただきましたが、 今回は少し趣向を変えてOCXが出展しているイベントでのお話について記事にしたいと思います。

Interop Tokyo におけるOCXの取り組み

OCX(サービスを提供している BBIX)が出展しているイベントの中でも、特に大規模なものの一つが「Interop Tokyo」です。 毎年6月ごろに幕張メッセで3日間行われるイベントで、数多くのネットワーク技術や製品などの展示会です。 (詳細は公式ホームページをご確認ください)

OCXとしては2年前の2023年から出展しており、今年で3年目となりました。 OCXを認知していただき、集客し、より広く展開していくという3か年計画で取り組まれました。

私自身との関わりと3年目での変化

私自身は1年目から出展企画に一部携わらせて頂いており、ブース設営などにも少しではありますが関わりがありました。

とはいえ本職は技術職であるため専門の企画職の方々にOCXの開発者目線で「こういった展示はどうか?」と軽く提案する程度でした。

ただ、今年は企画開始時にいつも一緒にInteropの企画を主導している方から「最初の段階から展示の企画提案に入ってくれないか」と要望があり、 これまでは軽く手を出すレベルだったのですが、今年に関してはガッツリと企画にも関わることとなりました。

過去、2年の展示でOCXの認知度は徐々に広がってきているものの、まだまだ伸び代はたくさんあると思います。 そして今年に関しては大通りに面したブースで人通りも多く、数多くの来場者の目に触れるため、足を止めてもらい、良い印象を持ってもらうにはどうすればよいかという観点で、OCX をどのように見せるかを考えました。

2年間での展示で課題に感じたこと

昨年までのOCXの展示ブースに足りなかったのが、わかりやすさでした。 ブースに立ち寄っていただく方にOCXについて口頭で説明しても、中々イメージがつきにくい、どういった利用シーンがあるのかわからない、類似のサービスと比べてどういう違いがあるのか、など多くの方々がOCXとはそもそもどういったものか理解されにくい、という点は非常に感じていました。

私自身NWの世界に触れて感じたのは、NWは物理的なハードウェアは当然存在しますが、その構成というのは論理的なものであることが多いです。 展示会において機器の展示などはできても実際のNW構成の展示というのは中々難しく、NW業務に従事されている方には口頭の説明で伝わってもInterop Tokyoというイベントに情報収集に来られるような方々(非技術職の方など)には伝わりにくかったのです。

課題解決のための取り組み

なので、多くの展示会はどうなのかと、私もプライベートで趣味の分野の展示会に行ったり、Interopで他社様のブースに行ってみました。 そこで実際に見て、場合によっては触るなど、言葉だけでなく体験できる展示がとても印象的でした。

これらの体験からOCXのNWというものを視覚的にわかりやすくする展示はどうかということで、OCXのリソースのアイコンを使ったマグネットによる展示の提案を企画しました。

実際のInterop Tokyoのブースに設置されたOCXマグネット
実際のInterop Tokyoのブースに設置されたOCXマグネット

写真は開始直後の写真のため、見た目がシンプルですが、展示会が進むにつれ内容を変更し、より実際の構成の形などを見せていくことができ、多くの来場者の目を引くことができました。

結果、このマグネット展示は社内外から非常に好評で、「うちの会社でもやってみようかな」という感想や、 弊社の営業からも「営業で使いたいのでより小さいのを作ってほしい」といったお言葉をいただき、 OCXというものをより身近にわかりやすいものにできたのではないかなと思いました。

今後についての展望

これからも展示会などにおいてOCXをより多くの方にわかりやすく知っていただくために、様々な目で見て、(可能であれば)体感もできる展示を考えていきたいと思います。

情報セキュリティ委員会(ISC)の立ち上げと今後

はじめに

この記事は BBSakura Networksアドベントカレンダー2025 の14日目の記事です。 本記事では、社内のOAおよびセキュリティに関する業務を担うITシステム室の情報セキュリティ委員会(以下、ISC)について紹介します。

自己紹介

はじめまして。BBSakura Networks株式会社(以下、BBS)の河本です。

2017年からBBIX株式会社(以下、BBIX)に所属し、BBSには2019年の設立時から兼務しています。

当初はBBIXのInternet Exchangeのシステムの開発・運用が主たる業務でしたが、BBSの成長に伴いセキュリティの重要性が高まり、2022年よりOAセキュリティ関連の業務にも従事しています。

情報セキュリティ委員会の立ち上げ

2022年は、BBSの主軸となるサービスOpen Connectivity eXchangeを提供開始した年です。

これ以降は、サービスに関連するシステムやお客様の情報など重要な資産の増加が容易に想像できていました。

しかし当時は、

  • サイバー攻撃や情報漏洩などのセキュリティ事故から守る仕組み
  • セキュリティ事故が起きてしまったときに「誰が」「何を」行うかという役割や手順

が十分には準備されておらず、事業を守るための仕組みが整っていませんでした。

そこで親会社BBIXのセキュリティ担当者を中心にBBSにも専門のチーム「情報セキュリティ委員会(ISC)」を立ち上げ現在も活動を続けています。

www.bbsakura.net

基礎固め

ISCの業務は多岐に渡りますが、立ち上げ当初から現在にいたるまで事業を守るための基礎固めに注力しています。

セキュリティ体制とリスクマネジメントの構築
  • セキュリティ事故発生時の対応手順の策定
  • BBSが持つ情報資産の目録の作成
  • セキュリティリスクの把握と軽減策の検討・実施

など、セキュリティ体制の基礎固めを行いました。

ITシステムの設定見直しとアカウント管理の徹底

意図しない情報漏洩から社員を守るために、

  • SlackなどのITシステムの設定・権限の見直し
  • OA端末を管理するためのMDMの導入・管理手順の策定

も行いました。

また、BBSに入社される方が安心して迅速に業務を開始できるように、

  • OAシステムのアカウント手配
  • PCなどのOA端末の手配

を行う一方、残念ながらBBSを離れる社員のOA端末回収やアカウント停止を徹底する仕組みも整備しました。

システム開発時や外部サービス導入時の審査

BBSはソフトウェアエンジニアも多く新しいシステムの開発と外部クラウドサービスの利用も活発です。

システムリリースやサービス利用開始前にセキュリティ要件の確認やリスクの洗い出しを実施し、適切なセキュリティ水準を維持できるようにしました。

啓発活動

社員全員のセキュリティ意識を高めるための教育を入社時だけでなく定期的に実施し、人による「守り」の強化にも取り組んでいます。

コンプライアンスへの対応

などもISCの業務です。

また、先日発表したように海外展開が進む中で、今後は現地の法律や規制にも対応することが求められています。

www.bbsakura.net

今後

今までは守る仕組み作りに集中してきましたが、今後は社員の生産性向上を加速させるための攻めの仕組み作りにも取り組んでいきたいと考えています。

AI活用に関する指針の整備を進め、社員が迷わずにAIを使えるようにすることに加え、開発とセキュリティを一体として進めるDevSecOps の考え方も強化していきます。その取り組みとして、SAST によるセキュアコーディング支援や、SBOM を活用したライブラリの脆弱性検知、システムの脆弱性をリアルタイムに監視する仕組みなどの導入を進め、社員が安心して業務に専念できる環境づくりを目指します。

さいごに

こうした取り組みを進めていくためには、情報セキュリティ委員会(ISC)の強化も欠かせません。興味を持っていただけた方は、ぜひカジュアル面談からご応募ください。

また、BBSのISCの立ち上げは、BBIXのノウハウがあったからこそ短期間で実現できました。本記事が、ノウハウが少ない中でセキュリティ担当になった方にとって少しでも参考になれば嬉しいですし、今後もセキュリティ組織に関する記事を書いていきたいと思います。

XaaS Connection で実現する Cato SASE Cloud Platform へのかんたんVPN接続

BBSakura Networks Advent Calendar 2025 12日目の投稿です。

はじめに

こんにちは!BBSakura Networks株式会社(以下、BBSakura)でクラウド接続を担当している赤羽です。今回は、BBIX の Open Connectivity eXchange(以下、OCX)で提供している XaaS Connection について紹介します。XaaS Connectionとは、従来のSaaS Connectionをアップデートしたプロダクトです。SaaSサービスに加え、さまざまな “as a Service” への接続に対応できるようになり、現在は SASE やクラウドストレージサービスにも接続可能になりました。

(2025年12月時点でのXaaS Connection対応サービス一覧) XaaSConnectionサービス一覧

2025年11月のリリースでは新しい接続先としてCato SASE Cloud Platform(以下、Cato)が追加されました。Cato との接続では IPsec Parameter という設定項目が導入され、OCX から直接 Cato へ IPsec VPN を設定できるようになりました。さらに BGP ルーティング設定も合わせて OCX ポータルで完結します。 www.bbix.net

この記事では、XaaS Connection の IPsec Parameter の特徴やメリット、実際の設定手順について紹介します。

XaaS Connection IPsec Parameter の特徴と利点

SASE サービスの接続では、VPN 設定の複雑さが大きな負担になります。ルーターごとに設定方法が異なり、IPsec パラメータも多様です。加えて、SASE サービスごとの仕様差異がトラブルを招くこともあります。さらに、運用中にはルーターコンフィグの理解が必要となるため、設計から運用まで属人化しやすい点も課題です。

XaaS Connection IPsec Parameter の特徴と利点

そこで役立つのが XaaS Connection の IPsec Parameter です。これにより次のようなメリットが得られます。

  • IPsec VPN の設定が圧倒的に簡単
  • 導入後も VPN 設定をポータル上で視覚的に確認可能
  • GUI ベースのため、深いネットワークスキルがなくても設定できる

IPsec 接続を OCX 側で吸収する仕組みにより、導入から運用までの負荷を大きく軽減できます。

ここからは、実際に OCX から Cato に接続するための設定手順を紹介します。

IPsec,BGP接続までの手順

今回は、以下のネットワーク構成を前提に説明します。

ネットワーク構成

1-1 (OCX) XaaS Connectionの作成

OCXポータルで XaaS Connection > 作成 をクリックし、カテゴリで セキュリティサービス/SASE → Cato SASE Cloud Platform を選択します。

OCXポータル設定画面1

続けて、各項目を入力します。

OCXポータル設定画面2

名称:任意の名称

リージョン:Tokyo または Osaka(OCX 側 PoP)

プライベートIPアドレス:拠点から XaaS 宛てのゲートウェイ・・・図(1)

ローカルASN:OCX 側の BGP 用 AS 番号・・・図(2)

注意事項にチェックを入れて作成ボタンをクリック

作成後、一覧にリソースが表示されます。 OCXポータル設定画面3 XaaS Connection 詳細タブより、割り当てられたグローバルIPを確認できます。

1-2 (OCX) XaaS Connection IPsec Paramereの作成

IPsec Parametersタブから IPsec Parameter 作成ボタンをクリック OCXポータル設定画面4 OCXポータル設定画面5

共通

事前共有キー:IPsec 用 PSK

リモートASN:Cato 側 ASN・・・図(3)

プライマリ IPsec Parameter

トンネルエンドポイントアドレス:Cato 側 IPsec 用グローバルIP・・・図(4)

※ Cato 指定のIPアドレスになります。Cato のポータル画面で事前にご確認ください。

ローカルアドレス:OCX 側 BGP IP・・・図(5)

リモートアドレス:Cato 側 BGP IP・・・図(6)

セカンダリ IPsec Parameter

トンネルエンドポイントアドレス:Cato 側 IPsec 用グローバル IP・・・図(7)

※ Cato 指定のIPアドレスになります。Cato のポータル画面で事前にご確認ください。

ローカルアドレス:OCX 側 BGP IP・・・図(8)

リモートアドレス:Cato 側 BGP IP・・・図(9)

入力後、作成ボタンをクリック

1-3(OCX)XaaS Connection BGP Parametersの作成

続いて自拠点ルーター向けのBGP設定です(CatoとのBGPではありません)

作成したXaaS Connectionを選択し、ウィンドウ下部のBGP Parametersタブを選択し、BGP Parameterの作成ボタンをクリック。

OCXポータル画面6

OCXポータル画面7 リモートアドレス:拠点ルーターの BGP Peer IP・・・図(10)

リモートASN:拠点ルーターの ASN・・・図(11)

以上でOCX側の設定は完了になります。

2-1 Cato SASE Cloud Platform ポータルにてIPsec接続の設定

次はCato 側の設定です。 ※site登録は割愛します

Catoポータル画面1 IPsec 接続を設定する Site を選択し、 Network > IPsec を開きます。

General >

Connection Mode:Bidirectionalを選択

Primary >

Destination Type:IPv4

Cato IP (Egress):IPsec 接続をする Cato 側の PoP をプルダウンより選択。

NewをクリックしてAdd Tunnel 画面で各種パラメータを入力

Catoポータル画面2

Role:任意のものを選択

Name:任意の名称

Remote Peer Authentication Identifier >

Public IP:・・・図(12)

PSK:IPsec 用 PSK

Secondary > Primary と同様に設定。Public IP:・・・図(13)

2-2 Diffie-Hellman Group は「20」を選択

Catoポータル画面3 Int / Auth Message ParametersDiffie-Hellman Groupは20を選択してください。 設定後は上部にあるSaveをクリックしてください。

2-3 BGP設定もおこなう

Catoポータル画面4

Network > BGP > New から設定します。

Name:任意

ASN Settings >

Peer:OCX XaaS Connection の ASN・・・図(2)

Cato:Cato 側の ASN・・・図(3)

IP >

Peer:OCX 側 の BGP IP・・・図(5)

※IPsec設定画面で設定したローカルIPアドレスしか設定できません。

※入力時にエラーが出る場合は、IPsec 側のローカル IP を再確認してください。

Secondary > Primary と同様に設定。Peer:OCX 側 の BGP IP・・・図(8)

2-4 接続状態の確認

以上で設定は完了になります。 IPsec / BGP の状態確認画面から、接続状況を確認できます。

IPsec 接続の確認画面 Catoポータル画面5 BGPの確認画面 Catoポータル画面6

まとめ

今回は、XaaS Connection を使った Cato SASE Cloud Platform への接続について、サービス概要から利点、設定手順まで紹介しました。XaaS Connection は、名称が SaaS Connection から変わっただけでなく、今後さらに多様なサービスへ柔軟に接続できる基盤へと進化していきます。従来の SaaS サービスに加え、セキュリティサービスとして Zscaler、Cisco Umbrella、Cato SASE Cloud Platform、 クラウドストレージとして Wasabi Hot Cloud Storage、など多くのサービスに対応し、利用シーンも大きく広がりました。特に Cato SASE Cloud Platform 向けに追加された IPsec Parameter は、従来の IPsec VPN 運用で避けて通れなかった「複雑な設定」「ブラックボックス化」「属人化」といった課題をまとめて解消し、設定の簡素化と可視化をサポートします。今後も XaaS Connection は、さまざまな “as a Service” との閉域接続を拡大していきます。ぜひ、今後のアップデートにもご期待ください。

以上です。

新卒2年目からのキャリアアドバイス

はじめに

はじめまして。BBSakura Networks株式会社(以下、BBS)のチョです。

私は2024年度にBBSに新卒入社し、そろそろ丸2年を経過しようとしています。 正確には、原籍はソフトバンク株式会社で、初期からBBSおよびBBIX株式会社には出向(本務)でやってきております。

私は自ら手を挙げ、事業本部から技術本部に異動させていただいた経歴があります。 最初には事業本部に配属され企画推進の仕事をして、2025年4月からは技術本部に所属してクラウド接続の仕事をしております。 本記事では、異動の経緯とこの2年間の感想をお伝えしたいと思います。

想定する読者は、これから就活をする学生の方・若手社員でありながらキャリアパスを悩んでいる方です。 答えになるものは書けていませんが、参考にしていただければ嬉しいです。

初期配属

実は私は入社時点では技術職を志望しておりました。 ですので、配属先が事業本部であると聞いたときには結構驚きました。

ではその配属に不満があり異動を申し出たのか?というとそうではなく、 逆に事業本部の仕事も面白い、今後もやっていくのもありかもしれない、と名残惜しみを持ちつつの異動でした。 (理由は後で説明します。)

異動はしたものの、自分の適性や日頃の興味は実は事業本部に向いていると思います。 企業のIR資料や経済ニュースを読むのが趣味だったり、 学生時代の研究テーマがゲーム理論だったりして、 自分の背景はなんやかんやビジネスに寄っているためです。 (一方、お恥ずかしいことに、ネットワークやプログラミングには力を入れてきませんでした。)

ではなぜ最初に技術職志望だったかというと、「ビジネスも技術も両方分かるといいよね」という考えがあったためです。 ビジネス領域は普段興味を持っているから自分一人で賄えるけど、 手を動かす必要のある技術力は自らは磨かないよね、という自己分析がありました。

この点を研修の間に見抜かれてしまったのかもしれませんね。(苦笑)

異動

ビジネスチームでの仕事は大変だったものの色々勉強になりました。 学びも多く、実績も多い。目立ちやすいといいましょうか。 やる気さえあれば、成長機会が社内で最も多い環境だと思われました。 ですので、異動したいと手を挙げたのは、別に初期配属に不満があったからではありません。 初期配属がビジネス職で逆に良かったとさえ思っています。

ならなぜ異動したいと決めたのかというと以下のような要因があります。

  1. 技術の中身を十分理解せず、次の仕事に進まなければならない
  2. 何かを提案して動かすには、技術をもっと理解しなければいけない
  3. 熱くなれるのか?に対する確信が持てない

では一つずつ見ていきましょう。

1. 技術の中身を十分理解せず、次の仕事に進まなければならない

ビジネス職なら仕方のないことですが、新たなサービスや機能を作る際には技術選定や実装等は技術職の仲間に任せることになります。 徐々に中身は見えなくなり、そのまま次のタスクに移るしかありません。

もうちょっと頑張って、もうちょっと上手くテキパキとできる人なら、 この辺の勉強も隙間時間を利用してしっかりできて、諸々全部追いつけながらできたかもしれませんが、 私にはキャパを超えることでした。 (この後話す「熱くなれるのか?」という話にも繋がります。)

「どこかで聞いたことはあるな〜」の状態で何となく仕事を進めるのは良くないと感じました。 しっかり中身を見て何がどうやって動くのか理解しながら、自分の触っているプロダクト・サービスに向き合いたいと思ったわけです。 そのためには異動が必要だと思い始めたのです。

2. 何かを提案して動かすには、技術をもっと理解しなければいけない

ビジネス職の強みはお客様と会うことで肌から市場の理解が進むということです。 自然と何らかの新しい提案をする機会も多くなります。 ここが個人的にはビジネス職の醍醐味といいますか、面白いと感じたところです。

しかし、この提案というのは (1)お客様/マーケットのニーズ (2)新機能開発 のどちらかから生まれるというもので、 そのどちらもある程度の技術の理解が必要なものです。

もちろん時間が経ちそれなりの経験が付くと(特に(1)に関しては)何らかの提案ができるようになってたかもしれませんが、 どの道、より深い技術の理解が必要なら、まずは100%技術に時間を割いたほうが提案できるレベルに到達する近道だと思いました。

そういった意味では、初期配属が技術職で、ある程度分かってきてからビジネス職に異動するのがベストだったかもしれないな、とは思ったりします。

3. 熱くなれるのか?に対する確信が持てない

本記事最後の「BBS/社会人の2年間で感じたこと」でも述べる内容ですが、2年間の社会人生活を通して自分なりに見えてきた一つの答え的なものは、 結局、自分の携わっているサービスやプロダクトへの思い、その熱量がその人のパフォーマンスを決めるということです。 誤解を恐れずに書きますと、知識が豊富だとか、経験が豊富だとか、そういうのは二の次だと思います。

その考えの上で、ビジネス職が技術職よりもそのモチベーションの高さが問われるポジションだと思いました。 なぜならビジネス職は自身の(熱い)思いを持って、自ら何らかの提案をしてこそ意味のあるポジションだと思うためです。 (もちろん技術職だからこそ、技術面で熱い心で色んな提案をされる方々もたくさんいらっしゃいます。)

ここまで聞くと「あなたは自ら熱くなれないというのですか?」という質問が飛んできそうですが、 正直に答えると「はい、そうです」が答えになります。

まず上でも述べたように、ビジネス職は自ら提案するからこそ価値があると思いますが、 自分の知識と経験の足りなさで、それはすぐには叶えないと思っています。

「なら早く提案できるようにもっと頑張れば?」というご指摘はごもっともなご指摘ではありますが、 その足りない努力の分も含めて自分は十分には熱くなれないと思ったわけです。 (そう判断した細かな理由はいくつかありますが、長くなりますので割愛いたします。端的に言うと単なる個人のモチベの問題です。)

熱量のないまま技術職に異動して"そこそこ頑張る"って言われても周りの仲間達は困るかもしれませんが、 それでもなお、技術職への異動が自分なりにこの会社に最大限貢献できる選択肢だと思いました。 少なくとも周りの仲間に迷惑にならないぐらいには頑張っているつもりです。

熱くなれる仕事を探しに転職する、という手もあるかと思いますが、 現時点では熱くなれる仕事をこの会社の中でもう少し探してみたいと思ってます。 技術がもっと分かれば何か変わってくるかもしれないこと、 何よりも周りの人々が皆んないい人であることから、 今の状況に至りました。

続いて、各ポジションや社会人になってから感じたことを述べたいと思います。

ビジネス職で学んだこと

B2Bサービスはお客様ごとに仕様を変えることが多い=技術仕様を理解する必要がある

一番驚いたことは、B2Bサービスはお客様ごとにサービスの仕様を変えることがあるということです。 それは契約書だったり、料金だったり、担当する部署だったりしますが、ともかく広範囲に柔軟に対応することになります。 普段目にするB2C商品はそんなことが起きませんので、この点はとても驚いたところです。

そうなると自然と営業や企画などビジネス職の人も、それなりに技術用語や仕様を理解しないと仕事ができません。 もちろん細かなところは社内技術職メンバーと連携しますが、技術に詳しい営業ほど、お客様ともスムーズに話ができるだろうなと感じました。 営業は提示価格もコントロールできますし、まさに腕の見せ所ですね。

社内外の色んな人と会うことになる=ミーティングが多い

社内では調整役として、社外では営業や相談役として、ともかく話し合いが多いです。 ですので自然と時間が費やされ、何となく常に忙しい気持ちになります。

これらが無駄なミーティングだったら削減すれば良いだけの話だったんですが、 仕事は想像以上にとても多岐に渡るものなので、誰が何をやっているかが分からなくなります。 ですので、週1は集まりお互いの進捗を確認することをしないと、どこかのタスクが永遠に進まないこともあるため、 こういったミーティングは必要だなと私は感じました。

売ることはとても難しい

当たり前のような話ですが、お客様にお金を出してもらうのは難しいです。 既存の商材でお金を出してもらうのも難しいですし、 新たな何かを作り「これは絶対売れます」とはとても一言では言い切れないものです。

この辺で何か良い提案がしたかったのですが、今の自分には到底無理なことだと理解しました。 振り返ってみると、異動の決め手はこれですね。

技術職で学んだこと

日頃の運用や今後の拡張を踏まえて作る必要がある

学生の頃も授業や研究でコードを書くことはありましたが、 拡張性や冗長性、可読性などを考慮しての作業はやったことがありませんでした。

仕事となるとその辺もとても大事になってきますので、 最初のルール作りやアーキテクチャ・機器の選定等が如何に大事か、 日々の業務でそれらを感じています。

コスト面の管理が大事=妥協案を練ることになる

ビジネス職はお客様と近いので自分の貢献が比較的分かりやすいですが、 技術職は自分の作業がどれぐらい会社の役に立ったのか分かりにくいところがあります。 そこで、技術の工夫でコストを削減することができるのは、定量評価ができて嬉しいところですね。

しかし、コストがあるからこそ色々妥協していくことになります。 「もう少しだけお金をかければ手間なく簡単に解決できるのに」という悩みはエンジニアにはいつも付きまとうものでしょう。

技術といって幅広い

BBSは主にネットワークを扱う会社ですが、 ネットワークだけとっても物理・論理・仮想化・モバイル・クラウドなど、技術領域は多岐に渡ります。

自分が何に興味を持っているか、何がやりたいか、できるのかを、 仕事を続けていく上で常に模索しながら、微調整していくのがエンジニアとしてとても大事だと感じています。

BBS/社会人の2年間で感じたこと

やりたいもの・上手くなりたいものを早く決めた方が良い

今の時代はますます専門性や特別な経験を問われるようになっています。 BBSだけでなくほとんどの会社の人事評価でも、基本的には専門性に重きを置いて評価されるでしょう。

もし自分の中にこれがやりたい、上手くなりたいと思えるものがあれば、 早めにそれにフォーカスし極めていくことをお勧めします。 それで何かしらの難しいタスクを任され、その経験がまた評価され、より早く成長できる。 そういったスパイラルで、勢いをつけていくのが社会人として成功する道だと思います。

そういった意味では私はだいぶ失速していますが、まあ、これはこれで必要な時間かと判断しております。 でもあまりお勧めはしません。(笑)

まだ迷っているなら今後の余地を残す

正に今の私のことですが、「熱くなれないな」と感じたり「これだ!」ってなるものがないなと思った人は、 まずは今後の選択肢を狭めないようにすることを意識したら良いでしょう。

若手社員の方は転職までは無理でも、社内で手を挙げて本部を異動してみたり、課を異動してみたりするのはどうでしょうか。 そういった意味ではBBSは若手の意見を尊重してくれて、本部移動までとても柔軟に対応してくれるありがたい職場だと思います。

ビジネス職として色々模索してみるという意味では、 「一旦コンサル」は多くの経験ができることから、 正に今後の余地を残し選択肢を広げるという選択肢になると思います。 まだ学生の方で技術に大きな興味のない方なら「一旦コンサル」は悪くないと思います。

ITなど技術系の会社なら、ビジネス職より技術職の方が今後の選択肢は多く残せると思います。 特にBBSのような、ネットワーク会社は物理から開発まで幅広く経験できるのでIT系ではお勧めしたいです。 IT系を目指しながら「コーディングはちょっと自信ないな」という方は「一旦ネットワーク」でいいと思います。 ただ、専門性はこれからもっと問われることになり、特に技術職はさらなる専門性が問われる分、 中途半端で評価されなくなる恐れがあることには気をつけたいところです。

仕事はたくさんの人が集まってやるもの

学生の頃と違って、仕事はともかくタスクの量が多いです。 誰が何をやっているか見えなくなるし、分からないことがあった時に誰に聞けばいいのかも分からなくなります。 とても一人で全部を覚えてやりきるわけにはいきません。色んな人との話し合いと調整、頼み事が発生します。

技術職だとしても、お客様と仲がいいとか、社内で顔が広い、顔が効くというのはとても大きい強みになると感じています。 コミュ障だから技術職を目指すという方もいらっしゃると思いますが、仕事ではほぼ間違いなく誰かに何かを頼むことになります。 (もちろん技術職は対面の仕事は比較的に少なく、会うとしても社内の人がメインになるので、人を相手にするストレスは相対的に低いです。)

ですので皆んなと仲良くする、頼れる人になることはポジションを問わずとても大事だと思います。 そうすることで自分も他の人に頼みやすくなり、どんなタスクでももっと捗るでしょう。

もちろんとても高い技術力のお持ちの方は、厚顔無恥でも孤高にやっていけます。

結局はやる気次第

人は、人のパフォーマンスは、結局やる気次第なのです。2年間を通して学んだことを一言で言うならこれです。

もちろん才能や経験、背景知識も大きく関わるとは思いますが、 人は成長するものですし、世の中は変化が激しいのでそれに追随するには結局新たなインプットが必要になります。 それらを長期的かつ継続的に上手くできるかどうかは、結局その人のやる気にかかっていると思います。

経験や知識は本当に頑張れば何とかなると思います。 才能が問われるほどのタスクは実はそう多くありません。 本当にどうしても無理なら、できる人を探してお願いすればいいです。 それもまた熱い心を持って説得すればできると思います。

精神論は嫌いですが、世の中こんなふうにできていると感じています。ですので、

  • できれば熱くなりましょう。
  • 熱くなれなかったら、熱くなる方法を探しましょう。
  • それでも熱くられないなら、熱くなれずとも皆んなに役に立つポジションを探しましょう。

おわりに

この記事を読んだ皆さんはどう思われるのでしょうか。 まだ自身のキャリアに迷いのある方に参考になれたら本望です。

一方で、当記事を書くことの最終目標は優秀な人材の採用に繋げることだと思います。 この記事がその目標に合致しているか疑問ではありますが、逆にこういう微妙なことも発信できる、風通しの良い環境であることはアピールできたのではないでしょうか。

最後に、熱量はあるが知識や経験が足りないと感じて弊社への志願を迷っている方ならぜひチャレンジしてみてほしいです。 私は採用担当者でも何でもないのですが、個人的にはそういう熱い人が来てほしいです。 私が社長ならそういう人を取ります。 ただ、その熱量を持ってなぜ今まで勉強して来なかったんですか?という指摘には、それなりの理由が必要かもしれません。

ソフトウェアエンジニアがシステムNW冗長化を実現するまで

はじめに

この記事は BBSakura Networksアドベントカレンダー2025 の9日目の記事です。

本記事は、今までソフトウェアエンジニアとして、システム開発を主に担当してきた私が、オンプレミスサーバのNW冗長化を行った時の実体験を紹介します!

自己紹介

はじめまして、BBSakura Networks株式会社の姜(カン)です。

2023年4月にBBIX株式会社に中途入社し、BBSakura Networksに兼務で勤めています。 普段の業務ではBBIXのカスタマーポータルと、共通認証部分の開発、BBIX HPのサーバ管理を担当しています。

BBIX、BBSakuraに中途入社するまでは、前職としてWEBアプリケーション開発をAWS等既存のクラウドサービスを利用して、システム開発を行っていました。 そのため、オンプレミスサーバの運用とVMのNWに関する知識はほとんど無い状態でした。

システムのNW冗長化を実現するまでの流れ

そもそも、冗長化とは

基礎的な知識かもしれませんが、各役割(WEBサーバ、APPサーバ、DBサーバ等)ごとに1台の構成だと、VM故障、アプリの停止等なにか障害が起きた際にシステムの継続利用ができません。それを防ぎ、システムの耐久性を向上させるため、予備の機器や機能などをあらかじめ多重に組み込んでおいて可用性と信頼性を高めるための重要な設計のことです。

なぜソフトウェアエンジニアがNW冗長化に挑むことになったか

ネットワークの会社であることもあり、システム開発メンバーとしても、単純にアプリケーションの開発補修だけではなく、そのアプリケーションとDBが動いているVMの運用全般を担当することになっています。

既存NWの問題点

既存のシステム構成でも一般的なオンプレミスネットワーク内のNW冗長化を行っていましたが、全てのサーバが同じネットワーク内である場合、ネットワーク網の障害時にシステムが利用できないことから、別のネットワーク網との冗長化を計画することになりました。

一般的なシステムNW構成図
一般的なシステムNW構成図

今回のNW冗長化構成の変更案

さくらのクラウド上にサーバを増設してインターネット経由でのNW冗長化を実現することに決めました。 これによって、BBIXのネットワーク網に障害が発生しても、さくらのクラウドにあるバックアップサーバでシステムが継続利用できるようになります。

NW冗長化対応後イメージ
NW冗長化対応後イメージ

工夫した部分

通信の方法

異なるネットワーク間の通信を連携させるためには一般的にインターネット経由でのGlobal IP解放でも良いですが、セキュリティ的にリスクがあるため、今回の冗長化対応としてはVPNを構築しての通信にすることにしました。 そこで採用したのが WireGuardです。その理由としては以下が挙げられます。

  • 「速い!」: カーネル内部で動作し、他のプロトコル(IPsec/OpenVPNなど)と比較してオーバーヘッドが極めて少ないため、体感できるほどの通信速度の向上が期待できる。
  • 「安全!」: 採用している暗号技術が最新かつ強固であり、セキュリティを専門としないユーザーでも安全性が担保されていること。
  • 「簡単!」: 設定ファイルが非常に短く、数行でセットアップが完了するため、従来のプロトコルよりも大幅に容易。
データベースのデータ同期の方法

さくらのクラウド側とのデータ同期のため、オンプレミス側のネットワークにMySQL Router(クライアントからのDB接続を仲介・ルーティングするミドルウェア)のVMを増設し、構築したVPN経由でレプリケーションを張ることにしました。

また、データの同期整合性を確保するため、DBの構成を大きく変更しました。

  • マルチプライマリーからシングルプライマリーへ: 以前の構成では書き込み競合(コンフリクト)のリスクがあったため、MySQL InnoDB Clusterを構築し、オンプレミス側をシングルプライマリー構成に一本化しました。

  • レプリケーション:オンプレミスのPrimary DBサーバと、さくらのクラウド側のDBサーバ間に非同期レプリケーションを構築。これにより、アプリケーションは常にオンプレミスのPrimaryを参照し、データはさくらのクラウド側へ流れ続ける状態を実現しました。

NW障害復旧時のデータ同期の方法

BBIX網でNW障害が発生し、さくらのクラウド側へ切り替わった(フェールオーバー)場合、さくらのクラウド側のDBが一時的にMasterとなり最新データが書き込まれます。しかし、NW復旧時にそのままオンプレミス側に戻すと、オンプレミス側のDBが最新データを持っていない(さくら側がMasterになっているため)という問題がありました。

BBIX網でNW障害時にが発生した際にはさくらのクラウド内でシステムが完結して問題ありませんが、復旧時にオンプレミス側のDBサーバがさくらのクラウド側の最新データの情報を取得していないことがわかりました。(障害時にさくら側にフェールオーバーしてDBのMasterになってるため) そのためオンプレミスのAPPサーバ内部に通信の障害&復旧を監視する仕組みを導入し、NW障害が発生した際にオンプレミス側のシステムからさくら側にあるDBサーバを参照するように向き先自動変更のツールを導入しました。

NW冗長化を実現してからのふりかえり

システムは開発フェーズも重要ですが、運用フェーズ、特に障害時の挙動こそがサービスの継続性を支えると痛感しました。今回の経験から、特に以下の2点を強く意識するようになりました。

  • 自動復旧の追求: 障害発生時、人手を介する手順を極力減らし、復旧までのスピードを意識した自動化の重要性。

  • IaaSの裏側を知る: 普段、AWSやGCPといったクラウドサービスで「当たり前」に提供されているロードバランサやマネージドDBの自動フェールオーバー機能が、裏側でどのような仕組み(監視、レプリケーション、Master切り替えなど)で動いているのかを、オンプレミス環境で自ら構築することで深く理解することができました。

これからも、お客様が支障なく継続利用できるような「止めないシステム」の仕組みを追求し、この貴重な経験を活かして開発・運用に取り組んでいきたいです。

おわり

ここまで読んでいただきありがとうございます。

初のBBSakura Networksアドベントカレンダー投稿で、読み返すと未熟なところもありますが、自分の経験を共有しつつ、改めて整理したことも良い経験になりました。 こういった互いの経験や情報、さまざまな場面を共有する場に積極的に参加していきたいと思います! これからもBBIX、BBSakuraの一員として社会のインフラを支えていくエンジニアとして成長していきます。よろしくお願いします!

エンジニア初心者がOCX-Router(v1)の仕様に関する検証をした話

この記事は BBSakura Networksアドベントカレンダー2025 の8日目の記事です

はじめに

こんにちは!営業の技術支援や個別案件のPMOなどをやっている青木です。BBIXではクラウドSE課というところにいます。

本記事では、エンジニア初心者である私が行ったOCX-Router(v1)の仕様に関する検証について、ここで得た知識や経験を紹介します。 この検証のおかげで、NWエンジニアのスタートラインにも立てていなかった自分が、スタートラインから一歩出るくらいのところまでいけたと思っています。 当時の私にとってはかなり難易度が高く感じましたが、エンジニアの経験値という意味でとても充実していました。

この検証は3ヶ月くらいやっていたので(もちろんずっとというわけではないですが)、いろいろなことを試していましたが、今回は掻い摘んで簡単にまとめています。

また、検証内容の詳細は記載していません。この検証で得られた知識や、新たな視点にフォーカスして書いていきます。

なお、本検証はベテランのNWエンジニアの方だったらおそらく2~3日で片付けられる検証内容だと思います。 「初心者がこの検証でエンジニアとしてのスタートを切ったんだー、へぇー」くらいの軽いノリで見ていただけると幸いです。

検証について

BFDとGraceful Restart

本検証で大きく関わってくるのが、BFDとGraceful Restartという2つのプロトコルです。それぞれのプロトコルはネットワークの可用性向上やネイバー関係の維持を目指すという意味では似ていますが、相反する効果を持ちます。検証でも大きく関わっていたので、以下で簡単に説明します。

※2025年12月8日の情報です。

BFD

データプレーンの通信経路に障害が発生していないかを、非常に高速 (ミリ秒単位)に検出するためのプロトコルです。 ルーター間でBFD専用のパケットを送り合い、それが途絶えることで「相手との通信経路に問題がある」と判断します。

OCX-Router(v1)ではRouter InterfaceのBGP Paramaterで設定でき、クラウド側も、本検証においては全ての場合でBFDが有効になっていました。

Graceful Restart(以降GR)

ルーターのコントロールプレーン(ルーティングプロセスのソフトウェアなど)が再起動する際に、通信の転送(フォワーディング)を止めずに処理を継続させるための仕組みです。 再起動中、隣接ルーターに「少し待ってほしい」と伝え、その間は既存の経路情報を使って通信を続けてもらいます。

GRが働く際は、役割によって、再起動するためにGRのオファーをするルーターと、再起動中ルートを保持して待つヘルパーモードのルーターに分けられますが、ヘルパーモードでしか働けない(helper mode onlyの)ルーターもあります。

OCX-Router(v1)はヘルパーモードでしか働けないルーターであることがCLI上やパケットキャプチャから確認できており、クラウド側ではGoogle CloudのCloud RouterのみGRのオファー機能が設定されていることが、Google Cloudの公式のドキュメントより確認できています。このGoogle Cloudの仕様が、本検証に大きく関わっていました。

このようにBFDとGRには、「即座に切り替える」か「ルートを保持して待つか」の点で、相反する効果を持っています。

検証の構成と経験

本検証の構成はこちらになります。

OCX-Router(v1)を自由に触れるような環境で用意する必要があったため、構成は商用環境と検証用環境を跨ぐようになっています。
本検証の構成図

本検証では、OCX-Router(v1)を自由に触れるような環境で用意する必要があったため、構成は商用環境と検証用環境を跨ぐようになっていました。この構成上、商用のVCIと検証用のRouter Connectionを繋げる必要があり、この際に通常ポータルでVC作成→アタッチでできる設定を手動で行う必要がありました。

この検証をするまでの私は、VC作成やアタッチの際に、システム・技術的に何が行われているのかは全く知りませんでした。

「ポータルでポチポチ操作したら何かしらの魔法がかかって繋がるんだ!」

本当にこのレベルの理解です。

そのため、まずは社内の技術に関する資料をひたすら読み込みました。 ここで、VC以外の他リソースも含め、システム上でどのような設定が投入されているかを初めて知ることになります。

その後は、実際に手を動かすフェーズです。

CLIでの設定投入の経験値が乏しかったこともあり、設定しても簡単にはPingが通らなかったり、VCの手動設定の部分で資料を読み込んでいても理解できていないところがあったり、一つ一つの工程で課題が出てくるような状況でした。

しかし、ルーティングテーブルやARPテーブルを見ながら切り分けを行い、トライ&エラーを繰り返しながらラボの機器に設定を投入しました。その結果、今まで理解できていなかったSWの設定や、ネットワークにおける存在意義など、挙げ始めたらキリがないほど多くの仕組みを学ぶことができました。

副産物

検証の構成や機器への設定の話に焦点を絞って書いてきましたが、これら以外にもこの検証で初めてやってことを超初歩的なことも含めて羅列していくと、ざっと以下のようになります。

  • ラボ環境の把握
  • 商用環境のCLI操作
  • 実機へのBGP設定
  • パケットチャプチャ          etc…

細かいところまで含めようとすると書き切れないですが、この全てがメインテーマになれるくらい貴重な経験でした。

(逆にこの検証をしていなかったらと思うと何も知らなさすぎて怖い...)

まとめ

初めてのブログなのでうまく書けていたかわかりませんが、少しでも伝わっていたら嬉しいです。

さまざまな経験を一度にできる初心者にはもってこいの検証でした。

自分から技術をやりたいと希望を出してやらせていただいているので、これからも頑張っていきます!