はじめに
この記事は BBSakura Networksアドベントカレンダー2025 の2日目の記事です。
はじめまして。BBSakura Networks株式会社の篠田です。
2025年4月に入社し、6月に現在のチームへ配属されてから半年が経ちました。
入社前は「大規模ネットワークに携わる」という大まかなイメージしか持っていませんでしたが、 実際に配属されてみると、想像していたよりも遥かに奥深く、複数の技術レイヤーが密接に絡み合う世界でした。
本記事では、半年間で関わった業務、そこで得た技術的な気づき、そして働く中で見えてきた組織の文化についてまとめます。
BBSakura Networks と自分の立ち位置
私が所属するチームは、IX（Internet Exchange）を支えるネットワーク基盤や仮想基盤の設計・運用、内部向けシステム開発を横断的に担当しています。
私はこの半年間で、
- 現在のサービスを新しいバージョンへアップデートする移行業務
- 大規模L2ドメイン特有の課題（ARPブロードキャスト関連）の検証
- 内部向けWebアプリケーションの改修（Next.js / Go / Nginx）
- データセンタでの仮想基盤構築（ネットワーク設定・ラッキング）
といった、ネットワークとソフトウェアの境界線をまたぐような業務に携わってきました。
インフラの物理層からアプリケーション層までを行き来する経験は、この会社だから得られたものだと強く感じています。
半年間で取り組んだ業務と、そこにあった学び
サービスのバージョン移行
現在のサービスを新しいバージョンへ移行するプロジェクトに参加しました。 対象となった環境はバージョン差が大きく、そのまま流用できる手順がほとんど存在しないため、 既存の手順書を比較しながら依存関係を推測し、先輩と相談しつつ手順の原案を組み立てていく必要がありました。
バージョンが飛んでいる場合、動作や設定の前提条件が異なる箇所が多くなるため、 一つひとつ理由を確認しながら手順化していくことが重要でした。 そのプロセスを通して、「どこを見ればヒントがあるか」を掴む力が身につきました。
ARPブロードキャストを抑える仕組みの検証（挙動理解の重要性）
大規模なL2ドメインではARPが一気に増え、ネットワーク負荷が跳ね上がることがあります。 これを抑えるための仕組みの検証に関わりました。
検証が難しかった理由は次のとおりです：
- 抑制処理に関連するパラメータが多く、ドキュメントだけでは「どの条件でどの応答が発生するか」が把握しにくい。
- 「負荷状態での動的挙動」があり、設定値を変えたときにどう振る舞うかは実際に動かしてみないと分からない。
- 検証は商用に近いトラフィック構成をラボで再現する必要があり、設計を誤ると周辺に影響を与えるリスクがある。
実際にラボで意図的にARPトラフィックを発生させて挙動を観察しながら理解を深めました。 検証中に停止手順の抜けが原因でラボ環境のネットワークに負荷をかけてしまった失敗もありましたが、 その後、事象を時系列で整理して安全停止手順とチェックリストを作成し、手順に組み込みました。
この経験から学んだのは、検証設計は「動かすこと」だけでなく、壊さずに確実に止められる設計と安全策が不可欠だということです。
内部向け可視化ツールの改修（構成と優先順位の学び）
Next.jsとGoを使い、内部向けの可視化ツールの改修とデプロイを担当しました。 このツールは定期的にキャッシュサーバの情報を取得し、一覧で閲覧・検索できるものです。
アーキテクチャ（概要）
- cronで定期実行するシェルスクリプトがcurlでデータを取得
- Go側でデータを整形してキャッシュに書き込み
- Next.js側がそのキャッシュを読み込んで描画（手動実行も可能）
この仕組み自体はインターン時代に自分が作った土台があり、新卒として任されたのは「拡張・整理・運用へ落とし込む」部分でした。
当初は「利用者に便利な機能は多いほど良い」と考え、 検索条件の細分化、リアルタイム進捗表示、CSV/JSONエクスポートなどを実装しましたが、 実際の運用観点から次の問題点が見えてきました：
- 機能が多すぎると操作が複雑になり、誤操作や迷いが発生する。
- 内部ツールに求められる価値は「豊富な機能」ではなく「確実・迅速に必要な情報が得られること」である。
そこで設計の優先順位を見直し、最小限で確実に動くこと、運用者が必要とする情報に絞ること、UIの複雑さを抑えることを方針として改修を進めました。 Webの常識（リッチに作る）と運用現場の常識（シンプルで確実）との差に気づけたのは、非常に価値のある学びでした。
データセンタでの仮想基盤構築
仮想基盤の構築作業にも参加し、VLAN・STP の設定だけでなく、サーバのラッキングやケーブリングといった物理作業も経験しました。
データセンタでの作業を通じて、光ファイバの曲げ半径を守ること、コネクタの清掃、ケーブルのタグ付けと配線整理といった物理的な手入れの重要性を実感しました。 これらは一見単純ですが、雑に扱えば信号劣化やトラブルの温床になり、結果として機器の導入・交換時に検証や切替が難航します。 仮想化や自動化は便利ですが、その土台はこうした物理作業が支えているという現場感覚が身につきました。
半年で得た最大の学び
半年を通して最も変わったのは、技術を扱う「視点」そのものでした。
入社初期は「動かす」「作る」といった実装寄りの関心が強かったのですが、実務では以下のような観点が圧倒的に重要だとわかりました：
- 影響範囲（壊れたときに誰に、どこに影響するか）を想定すること
- 障害前提の設計・冗長化・停止手順の用意
- 検証設計における安全策（壊したときに確実に止められること）
- 運用者が迷わず扱えるインターフェースと手順化
ネットワークとソフトウェアの境界をまたぐ仕事では、技術そのものの「作り方」よりも、 どう判断して優先順位を決めるか が問われる場面が多く、この判断基準を身につけることが今後の核心的課題だと感じています。
BBS の文化
BBSの良さは、議論とナレッジへのアクセスがしやすいことだと感じています。 Slack上で日常的に技術議論が流れ、新卒でも議論に参加しやすい環境があります。 ラボ環境も比較的自由で、自分で再現・検証し、それを基に改善を提案する文化が根付いています。
また「やりたい」と言えば任せてもらえる文化が実際に機能しており、若手が手を動かして学べる機会が多い点も大きな魅力です。
おわりに
最後まで読んでいただき、ありがとうございました。
まだまだ未熟ですが、学んだことを価値として還元できるエンジニアを目指していきます。
