2025-12-22

バックエンド開発チームを紹介

アドベントカレンダー2025 カルチャー

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

はじめに

最近、バックエンド開発チームのリーダーになった okuno です。

─── BBSakura のソフトウェアエンジニアは、謎に包まれている。

社内外からそんな声をもらうことがありました。

そこで、今回は会社や提供サービスの概要、
またバックエンド開発チームの役割や技術スタックや働き方などを紹介します！

1. 会社概要

1.1. 会社紹介

BBSakuraについて / 会社紹介

1.2. 提供サービス

OCX（Open Connectivity eXchange）という NaaS を提供しています。
- OCX とは データセンター間接続 / ルーティング / クラウド事業者との接続 など、
  ネットワークの様々な機能をクラウド化し、それらを管理するコンソール画面を備えたプラットフォームサービスです。

1.3. ブログ記事（抜粋）

ソフトウェア開発やネットワーク、働き方に関する記事を公開しています

2. 開発チーム

OCX のソフトウェア開発には、
他にも フロントエンド開発チーム や モバイル開発チーム や 仮想基盤開発チーム など、
複数の専門チームが関わっています。

このページでは、その中でも バックエンド開発チーム にフォーカスして紹介します。

2.1. 開発方針

ユーザーに価値を届ける機能を作り、収益を伸ばす
設計やコードの変更容易性を確保し、将来の保守・改修コストを抑える
収益性と費用対効果の両面を意識し、持続的に利益を生み出せる開発を目指す

2.2. 役割と責任

OCX におけるバックエンドの設計・開発
- API / ビジネスロジック / バックグラウンド処理などが中心
- 新サービスや新機能の開発、既存機能の保守・改善を中心に、技術的負債の解消など、ソフトウェア開発に関わる領域全般を担当
OCX の成長に伴い、技術的負債も少なくありません
- 以下のような改善提案も大歓迎で、ステークホルダーと合意を取りながら進めています
  - 「この機能があったほうが便利」
  - 「この部分はリファクタしたい」
  - 「ここを改善すればパフォーマンスが上がりそう」
運用は専任チームが担当していますが、運用に関わる開発タスクを担うこともあります
担当領域はありますが、役割に強く縛られることはありません
- 例：バックエンドエンジニアがフロントエンド開発に関わることも可能です（逆も歓迎）

2.3. 開発体制

開発は、テーマや規模に応じてプロジェクト形式で進めることもあれば、機能追加や改善などをイシュー単位で進めることもあります
- ビジネスサイドからの要望を起点にする場合もあれば、エンジニア自身の問題提起や改善提案から始まることもあります
開発に関わる業務全般（要件定義・設計・実装・テスト・レビュー・リリースなど）をチームで分担しながら進めてます
- 特定の担当者に責任が集中しすぎないよう、レビューや相談を前提とした進め方をしています
リリース予定日は、開発スコープや優先度、ステークホルダーとの相談を踏まえて現実的に決定しています
プロジェクトやイシューはすべて GitHub Projects で一元管理し、チーム内で常に状況を共有しています
- エンジニア自身が興味のあるテーマに手を挙げて、主体的に開発を進めることもあります
明確な正解がないテーマについても、試行錯誤しながら取り組んでます

2.4. 開発・レビューの進め方

GitHub のプルリクエストベースで開発を行っています
ブランチ戦略はシンプルな GitHub Flow です
開発手法はアジャイルを基本としていますが、形式に拘りすぎず、チームや状況に応じて進め方を調整しています
- 「どう進めるのが一番うまくいきそうか」をエンジニア同士で相談しながら決めています
レビューは品質の担保だけでなく、ナレッジ共有や設計のすり合わせも目的としています
レビューの優先度や意図を分かりやすくするため、プルリクエストのレビューコメントには以下の prefix を付けています

[must] - 必須修正。重大な問題がある場合
[imo]  - 任意提案。改善が望ましい場合
[nits] - 細かい指摘。コードスタイルなど
[ask]  - 質問。意図や実装内容の確認
[fyi]  - 参考情報。関連知識の共有

prefix の運用について
- 人間のレビューだけでなく、AIによる自動レビューでも利用しています
- prefix に応じて対応の進め方を分けています
  - [must] については、レビュワーと認識を揃えたうえで対応方針を決めています
  - [imo] 以下については、実装者の判断を尊重しつつ対応しています

3. 技術構成

3.1. 技術スタック

*最終更新：2025年12月

Category	Technology Stack
AI	ChatGPT / Gemini / Codex / Claude Code / GitHub Copilot
業務管理	GitHub Projects
ソース管理	GitHub Enterprise
言語・LIB・FW	フロントエンド：TypeScript / React / Next.js バックエンド：Go / GORM / gRPC
データベース	PostgreSQL
インフラ	さくらのクラウド / Google Cloud / Cloudflare / VMware / Docker
CI/CD	GitHub Actions / Terraform / Ansible
コミュニケーション	Slack (Business) / Google Meet / Google Workspace

3.2. アーキテクチャ

リポジトリ：モノレポ
アプリケーション：現在、明確なアーキテクチャパターンに統一されていません
- OCX の成長に伴い、責務やレイヤが混在している部分もあり、改善の余地が多くあります
- チームで議論しながら、より適したアーキテクチャを段階的に導入していく予定です

4. 働く環境

4.1. チームの特徴

技術の流行に振り回されず、原理原則を重視します
- 技術の流行に左右されない原理原則の思想がある
  - 課題の本質を定義する
  - 複雑な事象を抽象化/構造化し、シンプルなモデルに落とす
- 技術好奇心が高いメンバーが多いです
- HRT(謙虚/尊敬/信頼) を大切にしてます
経営層を含め、エンジニアリングへの理解と関与が高い環境です
- 雑談レベルで設計やコードの話が飛び交うこともあります
- 代表もコードを書くことがあります

4.2. 働き方

リモート勤務
- 基本はリモートワーク
- 必要に応じて竹芝オフィスや WeWork に出社することもあります
フレックス勤務
- スーパーフレックスタイム制を導入しています
コミュニケーション
- 主に Slack でテキストコミュニケーション
- 必要に応じて Slack ハドルや Google Meet を使用します
  - 会話が長くなりそうなときや、テキストでのやりとりに詰まったときは、気軽に声をかけて話すのを推奨してます
業務効率化の工夫
- 可能な限り本質的な業務に集中できるような環境を作っています
  - 例えば...
    - 勤怠連絡は Slack のみ
    - 生成AIをガンガン使う（セキュリティおよび社内規定を前提）
    - テーブル設計書の自動生成、Lint や AI による自動レビュー、デプロイの自動化
    - Slack ステータスで体調を共有（任意参加）

5. 採用情報

エンジニアを中心に中途採用を行っています
興味を持っていただけた方は、以下リンク先よりご応募ください！
- BBIXを通した中途採用
  - ※ BBIX（親会社） の社員としてご入社後、 BBSakura Networks に出向いただきます

さいごに

バックエンド開発チームの雰囲気や考え方が少しでも伝わっていれば幸いです。

「良いサービスやチーム作りに挑戦したい」
「まだ整理されきっていない部分も含めて、一緒に作っていきたい」

そんな方がいれば、ぜひ私たちのチームに来てください！

・・・余談ですが、今後このように各チームの取り組みをまとめて、
Engineer Entrance Book として整理・公開していきたいと考えています。
また進展があれば改めて発信します。

2025-12-19

チームで勉強会を始めてみたらプロジェクト改善につながりました

アドベントカレンダー2025 カルチャー勉強

はじめに

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

BBSakura Networks の鐘ヶ江です。普段は親会社のBBIX側に関わるお客様向けシステムの開発を担当しています。

我々のチーム内では今年の秋ごろから勉強会をはじめ、その結果プロジェクト改善につながるようになりました。

今回は何をきっかけに勉強会を始め、どうプロジェクト改善に繋がったのか。
勉強会を今後も継続していくために意識したいポイントについて書いてみたいと思います。

勉強会を始めたきっかけ

今年度から基幹システム開発のプロジェクトにジョインしました。まずは現状を知るためにと資料を漁ったものの、ふんわり作りたいもののイメージはあるものの、特に現状を知れるものについて形あるものが何もない状態でした。

そこで、元々参加したいた若手メンバーに直接聞いてみると、今の業務や課題について自分の言葉で説明してくれるんですよね。

つまり現状や課題感を咀嚼し理解できる能力はあるものの、アウトプットの仕方やそもそも必要性を知らないのだと考えました。

恥ずかしながら自分もこのとき、具体的な説明がうまくできませんでした。😅
改めて今までやってきたことを言語化して伝えられるようになりたいと思い、勉強会という形で相互に成長できる機会を作れるとイイナと考えました。

勉強会を開催してみた

最初の勉強会は、いきなり「要件定義とはなんたるか」「どんなアウトプットがあると良いか」を資料にまとめて、私が一方的に喋る形で研修ライクにやってみました。

振り返ると勉強会の内容は反省点しかありません。かなり教科書的な内容だし、具体例もない話だったので聞き手はあまりピンときていなかった印象でした。

ただ、ここで「勉強会という文化」をスタートするきっかけは作れたし、また初回からパートナー会社の新卒の方にも参加してもらい、横のつながりも作るきっかけができたのは良かったです。

パートナー会社の新卒の方からはベテランから出るような質問が飛んできて来てアワアワしました。💦
日頃から業務やエンジニアの仕事について俯瞰されていて素晴らしいですね。

その後は、具体例が足りなかった部分を補うために、今のプロジェクトを振り返る場を作りました。資料の話もそうだけど、「今のプロジェクトってぶっちゃけどう？」をみんなで話し合う時間です。

振り返りの中では、若手メンバーから「どんな資料があると良かったか」を気にしてくれるようになりました。

最初の勉強会はピンときてないと思いつつも、結果的に資料づくりの必要性について少しでも考えてもらうフックにはなっていたんだなと感じました。

合わせて、フォルダ管理のルールや課題管理のルールなど、なんとなく進んでいたけど本当は全員が見直したかったところも合わせて見直すことができ、勉強会きっかけではじめたところからプロジェクト改善にまでつながったのは良かったです。

このように１つのきっかけから掘り下げ、どんどん枝を広げていけると地道ながら成長していける実感を得られました。

勉強会を継続するために意識したいこと

まだ始めたばかりですが、継続していくために過去の経験も踏まえ必要だと感じたことが3つあります。

1. テーマの選び方、きっかけを腐らせず、テーマの枝を増やしていく

テーマ選びの１つのやり方として、実務を振り返り「いま我々に何が足りないのか」をみんなで分析して、そこを学びのテーマにすること。さらに１つのきっかけからどんどん枝を増やしていくように、学びを広げていくことが重要と感じました。

今回の例でいうと、資料作りの重要性について説明し、次に実務ではどんな資料があると良かったかをみんなで振り返ってみる。

その後資料１つ１つにフォーカスしてどういった目的でどんな内容で作ると良いかを学ぶ、作ってみる。といった感じで掘り下げていいくイメージです。

2. アウトプット中心の勉強会をメインにする

例えば初回に実施した研修ライクなものや輪読会のように座学だけのインプットは体系的な知識習得には有効です。ただし、一方向的な座学では、特に若手にとって「学んだ知識をどこで活かすのか」という実務との結びつきがつかみにくい傾向があります。その点、アウトプットメインの方が楽しんで参加してもらえ、実務での活かし方のイメージをつけてもらいやすい感触がありました。

例えば我々の開催してきた勉強会では、AIの使い方に関するTipsをLT形式で共有してみたり、コードを書いてみたり、進め方を振り返って「こうすれば良かったよね」を話し合ったり。実体験に沿った「楽しい勉強会」の方がイメージも湧くし、勉強会を継続したいモチベーションに直結すると感じています。

生成AI活用Tips共有のLT会の様子は澁谷さんが記事にしてくれました。 blog.bbsakura.net

3. 定着するまでは旗振りが必要

過去に別の組織で勉強会を主催していた経験では、持ち回りでテーマを決めたこともありましたが、モチベーションに差があって定着しなかった経験があります。今回は自分が始めたことなので、自分が引っ張ってモチベーションをマネジメントする時期だと思っています。参加者が勉強会に前向きに参加してくれる。「こんなことやりたい」を自発的に提案してくれる状態をまずは目指していきたいです。

おわりに

現在はパートナー会社さんと合同の勉強会とチームとしてのPJ振り返りと勉強会を月１ずつゆるく実施しています。

正直勉強会の維持は難しいです。自分も経験ありますし、自然消滅してしまった組織も多いと聞きます。

目標は、参加者が自発的に勉強会に参加してくれるようになること。チームの文化にしていくこと。組織を横断したつながりを勉強会きっかけで増やしていくこと。です。

またどこかでその後を書けるといいなと思ってます。

2025-12-18

SIMカードの中身を読んでみよう！

アドベントカレンダー2025

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

はじめに

こんにちは、BBSakura Networksでモバイルコアの開発・運用をしている清水です。

SIMカードは、モバイル通信においてユーザーの認証などを行う重要な役割を持ち、BBSakuraが提供しているモバイル回線サービス、OCX Mobile AccessにおいてももちろんSIMカードは利用されています。

ところで、皆さんはスマートフォンに入っているSIMカードの実物を見たことはあると思いますが、その中身が実際にどのような構造になっているかについては、あまり意識する機会がないのではないでしょうか。

私はサービス運用の中でSIMカードについて調べる機会があり、その過程でSIMカードの内部構造やデータの構成が思った以上に体系立っていることを知りました。本記事では、その内容を整理しながら、SIMカードのデータ構造について解説していきます。

SIMカードの仕様

そもそも、SIMカードの仕様はどこで決められているのでしょうか。これには2つの側面があります。 1つは、ICカードとしての仕様、もう1つはSIMカードとしての仕様です。

ICカードとしての仕様

SIMカードは、スマートフォンに入れる際には、nanoSIMという小さいサイズに切り出して使用しますが、実態はその他のICカードと同様のチップとなっており、物理的・論理的な構造はICカード共通の仕様としてISO/IEC 7816*1にて定義されています。

ここでは、

カードの形状
金属端子の接点の配置・役割
電気的特性（動作電圧、ノイズ耐性など）
データ構造
ICカードとリーダー間の通信プロトコル(APDU)

などが規定されています。

上記の仕様はICカード全体で同じ、つまりクレジットカードやマイナンバーカードとも共通の仕様になっています

SIMカードとしての仕様

実際にモバイル通信を実現するためには、ICカード共通の仕様に加えて、 SIMカードとしてどのようなファイルやデータが必要なのかを定める必要があります。（例：電話番号は何桁で、どのファイルに格納されるのか、など）

このような SIM カード特有の仕様は、 3GPP*2によって規定されています。 SIMカードに関する仕様は、複数の仕様書に分かれて書かれており、主に以下の Technical Specification（TS）で定義されています。

TS 31.101：SIMカードの物理的・論理的仕様
TS 31.102：USIM と呼ばれるアプリケーションの仕様
TS 31.103：ISIM と呼ばれるアプリケーションの仕様
その他（3G以前のSIMカードの仕様など）

略語が多くて分かりにくいですが、ICカードに、USIM や ISIM といったアプリケーション（加入者の認証情報や識別情報を保持するもの）を搭載することで、一般に「SIMカード」と呼ばれる形になります。

SIMカードのデータ構造

先述の通り、データ構造についてはICカード共通の仕様としてISO/IEC 7816で規定されています。 ICカード内のファイルはMF, DF, EFという3種類のファイルが存在し、階層的な構造を持っています。

MF(Master File)は、ICカード内に1つだけ存在するファイルで、いわゆるルートディレクトリに相当します。
DF(Dedicated File)は、ディレクトリやフォルダに近い概念で、アプリケーションの起点となるDFはADF(Application DF)と呼ばれます。
EF(Elementary File)は、実際にデータを格納するファイルで、電話番号のような具体的な情報はこのEFにバイト列の形式で格納されています。

SIMカードにおけるファイル構造を図示すると、このようになります。

ICCIDのように、カード自体の識別情報を表すファイルは、MFの直下に配置されており、MFの下にぶら下がる形でUSIM・ISIMのようなアプリケーションが配置されています（図中でADFと書かれているものに相当）。図中のEFDIRは、カード内に入っているアプリケーションの一覧が入っている特殊なEFで、このEFDIRの情報を頼りに各アプリケーションへのアクセスを行っています。

EFファイルを見てみる

USIMの中には、100種類以上にわたる様々なEFが存在しています。今回は、EFの中でも、機能・内容的に比較的シンプルなEFSPNというファイルについて、中身を見てみたいと思います。

EFSPN (Service Provider Name)は、名前の通りサービスプロバイダの名称が記録されているファイルで、スマートフォンなどでSIMの情報を開いた際の事業者名の表示などにも利用されています。

EFSPNの仕様については3GPPの TS 31.102 にて記載があり、下図のように仕様が決められています。

この表の各項目の詳細については、またの機会に解説したいと思いますが、ファイルの中身を読むうえで重要なのは、

各バイトがそれぞれどのような意味を持つのか
各コンテンツがどのようにバイト列として設定されているのか

の2点です。

ここからは、EFSPNの中身の一例として、

024F4358FFFFFFFFFFFFFFFFFFFFFFFFFF

上記のようなバイト列と仕様書とを照らし合わせながら、中身を読んでいきたいと思います。

実際に仕様書を見たい方は、こちらから確認出来ます！

ETSI TS 131 102 V18.9.0

各バイトの意味を把握する

まずは、バイト列中の各バイトがそれぞれどんな意味を持つのか把握します。仕様書の表によると、

1バイト目: Display Condition
2 ~ 17バイト目: Service Provider Name

となっており、2種類のコンテンツが存在していることが分かります。

各コンテンツの意味を把握する

Display Condition

まずは、 1バイト目のDisplay Conditionについて見ていきます。このコンテンツは、サービスプロバイダ名の表示に関する設定項目になっており、バイト列を更にビット列に分解したうえで、各bitの値によって、設定の有効 / 無効を決定しています。また、設定項目があるのは下位2ビットのみで上位6ビットはRFU（Reserved for Future Use）と記載されており、現在は使用されていないことが分かります。

実際に1バイト目の 0x02 をビット列に分解すると、下記のようになることが分かります。

つまり下から2ビット目の設定項目だけ有効にしている、ということが分かります。

（設定項目の具体的な内容の解説は省略します）

Service Provider Name

続いて、2バイト目以降のService Provider Nameについて見ていきます。

こちらは、記載内容を見ると、GSM 7-bit 文字コード（ASCII に近い形式）または UCS2 で格納され、使われていないバイトは 0xFF で埋められる、ということが分かります。このルールに従い、バイト列を文字列に変換すると…

Service Provider Nameは、アルファベット3文字で OCX であることが分かりました。

終わりに

本記事では、SIMカードのデータ構造と、実際のファイルの読み方について解説しました。 SIMカードには、その他にも数多くのファイル(EF)が存在していますが、仕様書と照らし合わせながら解読していくことで、同じように各ファイルの中身を把握することが出来ます。

実際にSIMカードに入っている値について調べてみたい方は、sysmocom SIMのような読み書き可能なSIMカードを用意すると様々なファイルについて観察することが出来ます。興味のある方は、sysmocomのSIMのファイルを書き換える方法について、昨日の記事で紹介されているので、ぜひ合わせてご覧ください！

blog.bbsakura.net

*1:ISO（International Organization for Standardization）および IEC（International Electrotechnical Commission）は、国際的な工業規格・電気電子分野の標準を策定する標準化団体で、ISO/IEC 7816 は両者が共同で策定した IC カードに関する国際規格を指す。

*2:3rd Generation Partnership Project：LTE や 5G などの移動体通信システムの国際標準仕様を策定する標準化団体

2025-12-17

sysmoISIM-SJA5 を使って SIM の認証情報を書き換えてみた

アドベントカレンダー2025 SIM

はじめに

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

こんにちは、BBSakura Networks株式会社でエンジニアをしている平山です。

一般的な SIM カードには、加入者識別番号（IMSI）や、認証で利用される Ki や OPc などの情報が保存されています。これらの情報は MNO やフル MVNO といった SIM 発行者によって設定され、通信事業者は HSSを用いて SIM の認証を行い、ネットワークへのアクセス可否を判断します。

通常、市販されている SIM カードの IMSI・Ki・OPc は書き換えることができません。しかし、sysmocom 社が提供する sysmoISIM-SJA5 のような書き換え可能な SIM を利用すると、モバイルネットワークの開発や検証が非常に効率的になります。例えば、ネットワーク側に登録した加入者情報と一致する SIM を自分で作成できるため、テスト用の加入者を好きなだけ用意したり、正常系・異常系の認証動作を自由に検証したりできます。

本記事では、sysmocom 社が提供する SIM カード「sysmoISIM-SJA5」を macOS 上で書き換える方法について紹介します。

用語解説（IMSI / Ki / OPc）

IMSI

契約者を一意に識別する番号。端末がネットワークにアクセスする際に最初に送信され、どの加入者かを特定するために利用される。

Ki

加入者ごとに固有の 128ビットの秘密鍵
SIM 内部と通信事業者側のみが保持
AKA 認証で実行される暗号計算の基盤となり、SIM の正当性を証明する
「ネットワーク接続用の秘密のパスワード」のような役割

OP / OPc

OP：通信事業者が内部的に持つ“演算用の共通キー”
しかし OP をそのまま使うと全 SIM が同じキーで認証されるため、セキュリティ上問題がある
そこで Ki と OP から生成される個別の値が OPc
OPc は AKA 認証で用いられる実際の演算鍵

sysmoISIM-SJA5 について

sysmoISIM-SJA5 は、IMSI や Ki、OPc などの認証情報を書き換えることが可能な検証用 SIM カードです。以下の特徴から、Private LTE/5G の開発・検証に広く利用されています。

ADM keys 付きモデルでは IMSI / Ki / OPc の書き換えが可能
2G / 3G / 4G / 5G の AKA 認証に対応
Private LTE/5G 検証のデファクトスタンダード

sysmocom.de

macOS での環境構築手順

$ python3 -m venv .venv
$ source .venv/bin/activate
$ git clone https://github.com/osmocom/pysim.git
$ cd pysim
$ pip install -r requirements.txt
$ git clone https://github.com/sysmocom/sysmo-usim-tool.git

認証情報の確認

sysmoISIM-SJA5 を購入すると、メールで SIM カードのパラメータが送付されます。そこに記載されている ADM キーを用意しておきます。

/sysmo-usim-tool.sjs1.pyのオプションは以下
- -i　現在のIMSIの出力
- -k　現在のKi値の出力
- -o　現在のOPC値の出力

$  ./sysmo-usim-tool/sysmo-isim-tool.sja5.py --adm1 ******** -k -o
...
* Detected Card IMSI: 00101**********
...
...
Reading Key value... 
* Initializing... 
* Reading... 
* Current Key setting: 
2g: Key: 4140******************************** 
3g: Key: 4140********************************  
4g5g: Key: 44140******************************** 
Reading OP/c value... 
* Initializing... 
* Reading... 
* Current OP/OPc setting: 
2g: OPc: 885c********************************
3g: OPc: 8885c******************************** 
4g5g: OPc: 885c********************************

読み出された認証情報
- IMSI：00101**********
- Ki値：4140********************************
- OPC値：885c********************************

認証情報（IMSI / Ki / OPc）の書き換え

今回は下記の情報に書き換えてみます。

IMSI：00202**********
Ki値：d773********************************
OPC値：af9a********************************

$ NEW_IMSI="00202**********"                 
$ NEW_KI="d773******************************** "               
$ NEW_OPC="af9a********************************"
$ ./pysim/pySim-prog.py -p0 -t sysmoISIM-SJA5 -a "********" \
  -i "$NEW_IMSI" \
  -s "8949***************" \　#ICCIDは変更しないが、設定しないとエラーになるので現在の値を設定
  -k "$NEW_KI" \
  -o "$NEW_OPC"

...
IMSI : 00202********** > 
Ki : d773**************************** > 
OPC : af9a**************************** > 
...
...

書き換え後の確認

$  ./sysmo-usim-tool/sysmo-isim-tool.sja5.py --adm1 ******** -k -o
...
* Detected Card IMSI: 00202**********
...
...
Reading Key value... 
* Initializing... 
* Reading... 
* Current Key setting: 
2g: Key: d773****************************
3g: Key: d773****************************  
4g5g: Key: d773****************************
Reading OP/c value... 
* Initializing... 
* Reading... 
* Current OP/OPc setting: 
2g: OPc: af9a****************************
3g: OPc: af9a****************************
4g5g: OPc: af9a****************************

正しく書き換えられた内容

IMSI：00202**********
Ki値：d773********************************
OPC値：af9a********************************

まとめ

本記事では sysmoISIM-SJA5 を用いた SIM 認証情報の書き換え方法について紹介しました。 Private LTE / 5G ネットワークの開発や検証を行う際に、sysmoISIM は非常に便利なツールです。

皆さんの SIM やモバイルネットワークの研究・検証に役立てば幸いです。

参考文献

sysmoISIM-SJA5 User Manual

2025-12-16

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

アドベントカレンダー2025

この記事は 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の認定資格は、知識の整理と自身のスキルアップに繋がります。皆様もぜひチャレンジしてみてはいかがでしょうか。

2025-12-15

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

アドベントカレンダー2025

はじめに

この記事は 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のリソースのアイコンを使ったマグネットによる展示の提案を企画しました。

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

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

今後についての展望

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

2025-12-15

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

アドベントカレンダー2025 セキュリティ

はじめに

この記事は 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のノウハウがあったからこそ短期間で実現できました。本記事が、ノウハウが少ない中でセキュリティ担当になった方にとって少しでも参考になれば嬉しいですし、今後もセキュリティ組織に関する記事を書いていきたいと思います。

はじめに

目次

1. 会社概要

1.1. 会社紹介

1.2. 提供サービス

1.3. ブログ記事（抜粋）

2. 開発チーム

2.1. 開発方針

2.2. 役割と責任

2.3. 開発体制

2.4. 開発・レビューの進め方

3. 技術構成

3.1. 技術スタック

3.2. アーキテクチャ

4. 働く環境

4.1. チームの特徴

4.2. 働き方

5. 採用情報

さいごに

はじめに

勉強会を始めたきっかけ

勉強会を開催してみた

勉強会を継続するために意識したいこと

1. テーマの選び方、きっかけを腐らせず、テーマの枝を増やしていく

2. アウトプット中心の勉強会をメインにする

3. 定着するまでは旗振りが必要

おわりに

はじめに

SIMカードの仕様

ICカードとしての仕様

SIMカードとしての仕様

SIMカードのデータ構造

EFファイルを見てみる

各バイトの意味を把握する

各コンテンツの意味を把握する

Display Condition

Service Provider Name

終わりに

はじめに

用語解説（IMSI / Ki / OPc）

IMSI

Ki

OP / OPc

sysmoISIM-SJA5 について

macOS での環境構築手順

認証情報の確認

認証情報（IMSI / Ki / OPc）の書き換え

まとめ

参考文献

はじめに

Google Cloudの資格について

合格に至るまで

勉強時間

勉強方法

Udemy

公式模擬試験

Gemini

公式ドキュメント

合格後

感想

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

分からない問題は飛ばす

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

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

挑戦してよかった点

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

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

おわりに

はじめに

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

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

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

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

今後についての展望

はじめに

自己紹介

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

基礎固め

セキュリティ体制とリスクマネジメントの構築

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