BBSakura 公開社内勉強会を開催します! #bbsakura_open_study

公開社内勉強会を開催します

2月16日(木)、BBSakura Networksの「四半期会議」で行う拡大版社内勉強会を社外のみなさまにも公開します!

bbsakura.connpass.com

この記事を書いているのは公開社内勉強会発起人のid:n0mzkです。

公開社内勉強会をやりたい想いを書きます。

公開社内勉強会概要

まずは会の概要からお伝えします。

  • 2023年2月16日(木)14:00~17:30
  • 場所: オンライン(YouTube Liveの予定)
  • 参加方法: 上記connpassからお申し込みください。
    • 感想や質問は、ハッシュタグ #bbsakura_open_study をつけてツイートしてください!

開催までの背景

BBSakuraでは四半期に一度全社会議を開催しています。

設立当初から全国各地でリモート勤務するのが前提の会社ですが、だからこそ四半期に一度ぐらいは顔を合わせて、部署を越えて会話して、業務をブーストしよう、というイベントです。四半期会議のときは(感染症などの状況が許せば)オフライン会場にも社員が集まります。

午前中は全社方針の説明や、各部署からの報告があります。午後は、日々の業務からは離れて全員でひとつの課題に取り組むような企画が、社員からの持ち込みで行われます。前回は「良いウェブサイト/サービスってなんだろう?」を考えるワークショップが行われました。

この四半期会議、最近まではCMOの山口が毎回企画をしてくれていましたが、前回からはグループ(≒ チーム)ごとの持ち回りで企画を担当することになりました。

今回は私が所属するモバイル開発グループの担当です。

午後の時間の企画も考えてよいということで、ぜひやりたい!と思ったのが、公開社内勉強会でした。

やりたい想い

知識やノウハウを社内で共有したい

BBSakuraでは週に1時間、自由参加の社内勉強会の時間があります。

時間枠はあるのですが、実際に開催されるのはそれほど高頻度ではありません。時期によりますが、数か月開催されないことも……。

会社設立当初に「それぞれの持っている知識を社内に共有したい」「アウトプットすることで自身の知識を整理する機会として利用してほしい」という意図で始まった会ですが、3年半経ち、それぞれの業務もだんだんと忙しくなってきて、勉強会に話すネタを考える余裕がなくなってきているのかもしれません。

社内勉強会の頻度が下がるのにつられて、知識が部署内・チーム内に閉じがちになってきていると感じていました。エンジニアも非エンジニアもそれぞれ貴重な知識を持っていたり、いろんな技術を使っていたり、おもしろいことを考えていたりするのに、もったいない状態です。

あらためてそれらの知識などを社内で共有する機会を作りたいというのが、いちばんの企画理由でした。

アウトプットしてほしい

上の項に書いた社内勉強会の意図のもうひとつ、「アウトプットすることで自身の知識を整理する機会として利用してほしい」も、企画理由としてありました。

知識の整理にもなるし、アウトプットすればフィードバックをもらえます。アウトプットするところに情報が集まってきます。そうして新たなインプットにもつながります。仕事にも還元されていきます。

社外に出てほしい

せっかくやっていることを整理して話をするなら、社外にも届いたほうがいいじゃん!というのが、「公開」の勉強会とした理由です。

聞いてくれる人が多いほど、いろんな視点からフィードバックをもらえます。

なにより、社外で仕事の話をするのって、楽しいですよね。

解決したい問題に向かう仲間が見つかるきっかけになるかもしれません。

自分を世の中にアピールできる機会にもなります。

BBSakuraを知ってもらいたい

BBSakuraという会社、最近はOCXをリリースしたり、OSSにコントリビュートしたり、アドベントカレンダーをやったりして、すこしずつ知っていただけてきているでしょうか。

でも、まだまだ知名度のない会社だと思います。

もっと知ってほしいです。

作っているもの・使っている技術・取り組んでいる課題を積極的に発信して、メンバーが楽しく働いている様子を知ってもらいたい。あわよくば一緒にBBSakuraで働きたいと思ってもらえたらいいな、という下心もありました。

こんな話ができそう

そんな想いで開催する公開社内勉強会、以下のような話題についてお話しする予定で準備を進めています。

※ 内容が変更になる可能性もあります。ご了承くださいませ。

BBSakuraのメンバーがどのような技術を扱い、なにに興味を持って、どんな雰囲気で働いているのかを感じていただけたら嬉しいです。 ぜひご参加ください!

はてなブログ for DevBlogに引っ越しました

こんにちは。BBSakura Networksでテックリードをしている日下部(@higebu)です。

先ほど、「はてなブログ for DevBlog」への引っ越しが完了したため、なぜ引っ越しをしたのか、引っ越し作業はどうだったかとこのブログの今後について書きたいと思います。

なぜ引っ越しをしたのか

昨年の12/20に 企業技術ブログ: エンジニアの技術ブログコミュニティ のリリースを知り、大変良い取り組みなので、ここに弊社のブログも載せたいと思いました。

また、恥ずかしながら、それまで「はてなブログ for DevBlog」を知らなかったのですが、「はてなブログ for DevBlog」についても調べたところ、これでいいじゃんとなったため、引っ越しすることにしました。

それだけではよくわからないと思いますので、簡単に背景を説明したいと思います。

以前のブログはGitHubで記事を管理し、Cloudflare Pagesで公開していたのですが、エンジニアしかGitHubアカウントを持っておらず、アカウントを持っていてもGitに慣れていない人もいるという課題がありました。

普通の技術ブログではGitHubに慣れたエンジニアだけが書いていけば良いかもしれませんが、BBSakura Networksでは社長を始め、普段GitHubを触ることがないメンバーにも記事を書いていって欲しいと思っています。

そのため、GitHubでの管理ではなく普通にWebブラウザで記事を書けるブログプラットフォームで、良い感じのサービスを探していました。

はてなブログ for DevBlog」は複数アカウントで記事を管理でき、非常に安いことと、利用するだけで 企業技術ブログ: エンジニアの技術ブログコミュニティ への掲載も完了することから、引っ越しを決めました。

(簡単に決めたように見えますが、実際には内部で相談したり稟議したりしています。)

企業技術ブログ: エンジニアの技術ブログコミュニティ については下記の公式の記事を読むと良さがよくわかると思います。

developer.hatenastaff.com

引っ越し作業はどうだったか

基本的には記事を移してドメインの設定などを行うだけで完了でした。

ただ、以前のブログが Hugo ベースだったため、 はてなブログのインポート機能 が使えず、手動で記事を移行することになり、少し手間がかかりました。

特に画像が多い記事はアップロードの回数も多く大変でした。。。

また、以前のブログのパスがはてなブログ標準の /entry ではなく /posts だったため、 記事を配信するディレクトリを変更 をやりたかったのですが、上記のインポート機能を使わないとディレクトリ変更ができない点に苦労しました。

これは、空のMovableType形式のデータをインポートすることでディレクトリ変更を行うことができ、解決しました。

このブログの今後について

以前のブログは、 2019年にアドベントカレンダー をやるために立てたブログですが、その後、 2022年のアドベントカレンダー をやるまで、全く記事が書かれることがありませんでした。

今後はそのようなことがないように、また、外から見たら何をやっている会社かよくわからないと言われなくなるように、記事を書いていきたいと思っています。

すばやく体験しフィードバックループを回す大切さを身をもって実感した

こんにちは。モバイルコア開発チームでエンジニアをしている日下部(み)です。

12/27の記事「ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話」で紹介されているラボ構築プロジェクトに私も参加しています。このプロジェクトについて、@voice726さんとは別の視点でふりかえり記事を書いてみます。

ラボ構築プロジェクトを通して、高速にフィードバックループを回すことの大切さを実感した体験記です。

デスクに置かれたRTX1300の写真
検証中のRTX1300

ラボ構築ふりかえり会

voice726さんが書いているとおり、ラボの初回構築では目標としていた状態にたどりつけませんでした。構築後、メンバー内でふりかえり会を行いました。

このプロジェクトの目的は物理機器で実験できるラボ環境を作ることですが、教育的な目的もありました。つまり、ネットワーク初心者や物理作業の経験が少ないメンバーが構築を行うことで知識・経験を得るという目的です。

これについては、初期構築未完成ではありますが機器選定・調達・設計・構築と一通り経験したことによってメンバーそれぞれ構築というものに対する解像度が上がり、ふりかえり会では、次回作業に向けた具体的な改善策を話し合うことができました。このことから、一定の成果は得られていると感じています。

技術的・知識的な観点でのコメントとおなじくらい、プロジェクトの進め方についても反省点が挙がりました。このことから、構築経験を積むという目的よりひとつ抽象度を上げて、プロジェクトを推進するということも、体験として得られたことがわかりました。 以下、構築の観点、プロジェクト推進の観点それぞれの反省点について考察しながら紹介します。

構築の観点

  • 最初は最小限の構成(ルータ、スイッチ、サーバ各1台など)で構築し、動くことを確認してから拡張していけばよかった
    • 小さい単位に区切って完成させ、意図通りに動くかどうか確認したり、利用者からの声を聞いたりというフィードバックを得ることを行えばよかったというコメントです。実際には「あれもこれもやってみたい」とルータを2台冗長化しOSPFでルーティングしたり、LAGを組んだりと、最小限ではない作り込みをしようとし、結果として成功せず、ラボとしての機能を社内に提供できないという状態になってしまいました。
  • 検証機の相談など早めに機材に触れられないか働きかければよかった
    • 早く機材に触れられればその分早く手を動かして検証することができました。実際にはスケジュールの見積の甘さもあり、機材が手元に届いてから構築まで時間がなく、充分に検証できないまま構築作業を行うことになってしまいました。
  • 仮想環境で同様の構成を作って試せばよかった
    • 物理機器がなくても構築より前に手を動かし検証する方法を取ることはできました。一部CML2を利用して検証できたこともありましたが、構築しようとしているものと同様の構成を試すことはしていませんでした。同様の構成で試すことをしていれば、構築の日に起きた問題にもう少し早く気付けていたはずです。
  • 構築当日の作業手順に、段階ごとの検証項目を充実させておけばよかった
    • 細かい段階に区切って意図通りの状態になっているかどうか確認するべきでした。ルータ・スイッチ・サーバ・RaspberryPiすべての機器にconfigを入れてパケットを流そうとしてみてからデバッグを始めたので、疑うべき箇所が多くなっていました。

プロジェクト推進の観点

  • チームビルディングの場を初期から作ればよかった
    • 構築を終えてからふりかえり会を実施しましたが、プロジェクト開始からそのときまで約半年、互いの困りごとや良かったと感じていることを話し合う場を設けていませんでした。もっと早い段階でそのような場を設けていれば、チームとして強みを補強し合い弱みをカバーし合いながら進むことができたはずです。
  • メンバーそれぞれの得意分野を知って互いに相談できる状態にしてよけばよかった
    • それぞれの得意分野を互いに知っていればその分野についてその人に相談したり、質問したりすることができました。チームとして補強し合う状態になるために必要なことでした。
  • わからないことが多いタスクを2, 3人で組んで早めに相談できる状態を作りたかった
    • 1つのタスクは1人で担当することがほとんどで、わからないことにも担当者1人で手探りで調べながら取り組んでいました。複数人で担当していれば、相談し、知識やアイディアを提供し合い、コミュニケーションの中からより高速に解決策にたどりつくことができていたかもしれません。
  • 構築の観点の反省点も見方を変えればプロジェクト推進の問題だった
    • 最小構成から背伸び構成までのスコープ・ステップを整理すること、適切なリスク判断をすること、各ステップで早期に検証することは、構築に限らず他のプロジェクトにも適用できる反省でした。

得たこと

構築、プロジェクト運営、どちらの経験からも共通して得られたのは「短い期間・小さい単位で手を動かしてみてフィードバックを得ること、そのフィードバックを次の行動に活かすことが大事」という教訓でした。
こう書いてみると、あたりまえのことです。 ですが、実際に自分たちが行動し経験したことで、このあたりまえのことが実感を伴って理解できるようになりました。失敗経験を通して実感することで、ラボ構築以外のプロジェクトでも、これまでよりもより自信を持って「すばやく体験しフィードバックループを回す」やりかたを推進できると感じています。

ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話

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

こんにちは。@voice726 です。またもや遅刻しました……今回は「ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話」と題しまして、私がリーダーをしていたラボ構築のプロジェクト(通称石狩ラボプロジェクト)のお話をしたいと思います。

石狩ラボプロジェクトが始まるまで

このプロジェクトの話はある日突然降ってきました。そうそれは6月のできごと。 テックリードからSlackにこんな投稿が。

"ラボ構築募集のSlack投稿のスクリーンショット"

上の概要で語られていたことを大雑把にまとめると

  • 雑に触ることができる物理環境によって、さくらのクラウドのようなサービスが生まれたり、その後新機能が追加されたりしている
  • BBSakuraではBBIXの物理インフラをうまく使い、ソフトウェア技術によってOCXのような新しいサービスを作っていくことが求められているため、物理インフラがわかっていないことは新しいサービスを作っていくときに足かせになる
  • 最近では動画学習などもあるけど、実際の経験に勝るものはない
  • 要は社内で下のスライドのようなことをやりたい(PDF注意)

ということが語られていました。

それに対しての弊社CEO佐々木からの返答がこちら。

"CEO佐々木からの返答:「けしからんことをするのは良いことだと思います!」"

(補足しておくと、「けしからん」とは上記の登氏のスライドの中に頻繁に登場する用語です。氏は技術者が自由に触って試せるラボ環境の重要性を説いており、そのような環境を構築することを「けしからんこと」と表現しています。詳しくは上記の氏のスライドをご一読ください。)

ということで、一瞬で始まりました。チャンネルが作成され、早速初期構築にむけてメンバーとリーダーの募集が始まりました。

リーダーに関しては当初「自分はネットワーク何もわからないマンだし、少しでもわかる人のほうが良いのかな?」と思って様子を見ていたのですが、 テックリード曰く「教育を兼ねているので、若者か未経験者にリーダーをしていただきたい」とのことだったので、 若者かどうかは別として未経験だったので手をあげてみました。

突然ですがここで簡単に私の自己紹介をしてみようと思います。

  • エンジニア歴4年目
    • かなりのアプリ寄り。前半2年のキャリアはほぼアプリケーションエンジニアとしての業務中心
    • BBSakuraに入ってきたタイミングでネットワーク機器も触り始める、DCでの構築作業はお手伝いでついていったことが数回あり
    • プロジェクトリーダー的なポジションもアプリ開発系の業務では任されたことが数回あったので、なんとなく回し方はわかっているものの、リーダーとしての経験が豊富とかリーダーとしての技術まわり(ファシリテーションとか、組織論とか)の勉強をめっちゃやってるわけではないので、まだまだひよっこ

こんな感じで、ネットワークエンジニアとしてもリーダーとしても超初心者な状態。 それでも思い切って立候補してみた理由としては、失敗していい環境でリーダーをやるという経験ができるチャンスってなかなかないのでは?と思ったからです。 自分の中での課題として、失敗に対する耐性がないなと思っていて、失敗を恐れながらディフェンシブに動くことが多いなと思っていました。 そんな中で、未経験の人に是非やってほしいというのはかなり後押しになりました。 かくしてネットワークやマネジメントに関しては全くの初心者だった私が、石狩ラボプロジェクトのリーダーとして動くことになりました。

"「未経験の人がやんちゃしてOKなのがラボだと思ってます!!」という社長の発言のスクリーンショット"

メンバーもそれぞれ立候補式で参加。 チーム横断で全社から様々なバックグラウンドのメンバーが集まりました。 例えば入社2年目の若手メンバーからモバイルコア開発チームの歴10年以上ベテランなエンジニア、DCでの運用経験のあるメンバーまで、総勢10名ほど集まってスタートしました。

その他数名の有識者がアドバイザーとしてつくことになりましたが、基本的には「見守る」というスタンスで、基本的に構築に関してはメンバーだけで進め、疑問点や相談したいことがあったらアドバイザーに相談という形で進めることになりました。

プロジェクト、始動

さて、こうしてプロジェクトが無事に始動したわけですが、プロジェクト開始時点ではっきり決まっていたことは

  • 年内くらいに初回構築できればうれしい
  • 構成はサーバ4、スイッチ1、ルータ1くらい

というくらいで、最終的にどういう構成でいつまでにやるかもメンバー内で検討して良いとのこと。 前述のDC勤務経験のあるメンバーに全体の工程の叩きを作ってもらって大まかなフェーズ分けはしたものの、それ以外は全員はっきりとした知識がない状態でのスタートでした。 なのでみんなで手分けして調査をしながら、悩みながらも徐々に話が進んでいきました。

具体的にやったことをリストすると

  • 構成の検討
  • 機器の選定・調達
    • 調達窓口の選定・やりとり・価格交渉
  • 小物周りの選定・調達
  • 予算管理・稟議
  • ハウジング契約
    • 電源・ハウジング回線スペックの検討
  • ネットワーク設計(論理・物理)
  • config検証

という感じで、内容としてはDCでの構築作業の標準的な内容かと思いますが、それぞれを実際に体験したことがないメンバーがほとんどで、解像度も低かったため、 道中は課題だらけ・わからないことだらけ。挙げるときりがないので、具体例をいくつか抜粋します。

何を選んだら良いかがわからない

「サーバ4、スイッチ1、ルータ1」と一口にいっても、スペックはかなり幅広いと思います。 サーバ1台選ぶだけでも、CPU・メモリ・NIC・OS・保守・諸々のライセンスなどなど、様々なオプションがあり選択に苦労しました。 特に大きかったのは、ラボでやりたいことがメンバー内できちんと定まっておらず、必要スペックが割り出せなかったという点かなと思っていますが、それについては後述します。

他にも調達に関連してのハマりごととしては、値段の相場観がわからないので、予算をレビューしてもらうときに、これはちょっと高いのでは?というツッコミを受けたりもしました。

ラボでなにがしたい?の具体例が出てこない

上で「ラボでやりたいことがきちんと定まっていない」という話をしましたが、じゃあ「ラボでやりたいことを考えよう!」となったときに、 そもそもネットワーク機器やラボで何ができるのかがわからない・イメージがつかない、という状態が発生しました。 結局選定としてはそれぞれ別業務で使ったことがあるからなんとなくスペックがわかる・汎用性がありそう、といった消極的選択に近い物が多く、そういった意味でラボとしての面白みには少し欠ける選択が多かったかなと思っています。 今回は初期構築ということで初心者メンバー中心での構築でしたが、今後ネットワークに詳しいメンバーがどういった点に面白みを感じてどういう機器を入れていくのかを楽しみにしたいと思っています。

他の優先度が高い業務に時間を取られてしまう

このプロジェクトのメンバーは様々なチームから横断でメンバーが集ったと上で述べましたが、基本的にメンバー全員それぞれ自チームでそれぞれのプロダクトに関する業務を持っています。 会社の事業と強く紐付いているプロダクトに関連するタスクと比較して、ラボ構築のような教育的側面の強いプロジェクトのタスクはどうしても優先度が低くなってしまうもの。 特にプロダクト側のタスクが忙しくなってくると、なかなかラボ構築プロジェクト側にはコミットできず、タスクが消化されなかったりというような状態も発生していました。

リーダーとして何をしていいかがわからない

これはリーダーとしての課題です。 まずリーダーとして手を上げてみたものの、実際リーダーって何したらいいんだっけ……?となりました。 一応気をつけていたこととしては

  • プロジェクト全体に気を配ること
    • 全体の進捗からマイルストーンに対して現在地がどれくらいなのかを把握し、スケジュール的に問題なさそうかを判断
    • それぞれの課題(予算・発注・技術的なところなど)の状態を説明できるようにしておきたい

などがありますが、そもそも構築自体に対しての解像度も低い状態だったので、何にどれくらいかかるかが読めなかったり、 実際にどういう状態になったら構築に行っても大丈夫かという状態の判断が甘くなってしまったりと、進捗管理するだけでもかなりお腹いっぱいの状態でした。

いざ現地へ

そんなこんなでなんとか話を前に進めて、やっと現地での初回構築にまで到達。 プロジェクトがスタートしたのが6月で、実際に構築は12月中旬で行ったので、ここまで来るのに半年間かかりました。 しかし構築も一筋縄ではもちろん行かなかったのです。

当初は「ハウジング回線に接続したルーター経由でリモートからサーバ等に入れるようにして、現地に行かなくても機器の設定を触れるようにしよう」という点を目標の一つとしていました。 しかし、現地で実際に作業してみると、想定より時間がかかったり、検証ではOKでも実際はうまく動かないということがありました。 特にスイッチはCML2を使って検証を行っていたのですが、 ルータ周りの設定はスケジュール等の見積もりの甘さもあってあまり検証の時間が取れず、現地で検証しながら構築しているという感じになってしまいました。 現地でのリカバリがうまく行った部分もあったのですが、間に合わない部分も多く、最終的にはルーター経由ではリモートからサーバに入れないまま終了という結果になりました。

一応バックアップ策は機能していて、「RaspberryPiとモバイル回線(さくらのセキュアモバイルコネクト)」を使って遠隔ログインはできるようにはなっていたのですが、 やはりハウジング回線 → ルーターを経由してのリモートログインまでは達成したかったなー……

朝10時集合で、終わってみるともう22時を超えており、みんな疲労困憊。 タイムマネジメントや、焦っても休憩を入れることの大切さを身をもって味わいました。

おわってみて

「失敗していい」といいつつ、やっぱり凹みますね。 悔しい!って思いました。 振り返ってみると課題も山積で、ああしたらよかった、こうしたらよかったばかりで整理しきれていません。 実際いまこの記事を書いている間も反省会が進行中で、いろいろな意見が出ている中から次のアクションアイテムに落とす作業が進行しています。

"反省会の様子"

でもこうして課題がいっぱい出てくるということは、それだけ構築に関する解像度が高くなったと前向きに捉えています。

他にもやってよかったなと思ったことは多くありました。 なんでもそうですが、やっぱり知識はインプットしたあとに実際に使うことが大切で、今回ネットワークの勉強をしながら実際に機器を触ることで、理解が更に深まったメンバーも多かったようです。 また、業務に還元できているといった手応えを早速感じているメンバーもいて、やはり手を動かすことは大切なんだなと感じています。

"弊社Slackの「手を動かそう」「足を動かそう」スタンプスクリーンショット"

それ以外にも、わからないなりに社内有識者からのアドバイスは借りながら、でも手を動かすのはほぼ自分たちの力だけで構築までを一度通したことも良かった点だと思っています。 反省の中ではもっとアドバイザー方に積極的にレビュー等をお願いしたらスムーズに行ったのではないかというコメントもあったのですが、その一方であまりそれをせずにやろうとしたことのメリットも感じています。 経験者が見たら当然気づきそうな地雷なのかもしれないですが、それを実際に自分たちで踏み抜いていったことに価値があったのかなと感じています。

あとは大変なことも多かったけど、やっぱり「楽しかった!」の一言に尽きます。 初めてサーバをラックに乗せられて楽しかったという声や、pingが通ったときの「おお〜!」という歓声を聞くと、頑張った甲斐があったんだなーと思うと同時に、 もっと勉強していろいろなことができるようになったら、もっと楽しいんだろうな!と感じています。

初心者リーダーとしてこのプロジェクトに携わった視点で言うと、まず当該フィールド(=DCにおける構築)の知識が乏しい状態でもなんとか前に進めて、(内容はどうあれ)構築までこぎつけたという点は少し自信になったなという気がしています。 一方で、前述の通り、リーダーとしてもネットワーク技術者としても解像度が低かったゆえの課題は多くありました。 進捗管理だけではなくチームビルディングなどもっと気を配ったほうがよかったなと思うことも多く、今回リーダーの立場として経験したことを踏まえて,更に知識面でもインプットを増やせて行けたらと思っています。

今回プロジェクトを進めていく中で様々な迷いがありました。それはリーダーとしての経験・知識の少なさと技術的な知識・経験の少なさの両方から来るものでした。 プロジェクトを進めていく中では様々な判断をする箇所が出てくると思いますが、いろいろな自信のなさから判断に迷ったり、メンバーにお願いをしたりというところがうまくできなかったのが大きかったなと思っています。 それ以外にも、リーダーというポジションとして何をすべきか、どういう目線から関わるべきなのか、やってみないとわからないことって多いなーと思いました。

まとめ

今回の初回構築は当初立てた目標という観点から見ると決して成功とは言えず、そこまでに至る過程も経験者から見たらボロボロだったかもしれません。 でも今回失敗することで得られたものは大きかったし、貴重な経験ができました。 今後の業務でも今回得た学びを活かしてさらにいろいろな楽しいことができるようになっていけたらと思っています。リベンジしたい!!

最後にテックリードからラボ構築メンバーへのひとことを紹介したいと思います。

石狩ラボも初期構築のリベンジに留まらず、もっともっと発展していく予定です。 AS取得してみたいね!とか、オレオレISP運用したいね!とか、100G環境つくりたいね!とか、いろいろな夢が広がっています。 このようにBBSakuraはチャレンジできる環境が整っています。「私もラボで色々けしからんことをしたい!」と思った方は、 ぜひこちらのカジュアル面談からお話ができたら嬉しいです!

IGFが日本にやってくる!

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

先日のInternet week 2022でのIP Meetingにて

少し前までは「本当に怖い怖いIP Meeting」と思っていたのですが、自分も年を取り気がついたらオーディエンスの方が若い人が多くなっている昨今、自分がしっかり伝える立場になったのだなと改めて思った次第です。
ここに「IGF2023を睨み、情報社会のいろんなことを語ろう」というタイトルで私もパネリストとして出演しました。メンバーは

江崎 浩さん(JPNIC理事長)
小林 茉莉子さん(株式会社メルカリ mercari R4D リサーチャー)
西潟 暢央さん(総務省総合通信基盤局電気通信事業部データ通信課長)
加藤 幹之さん(IGF2023に向けた国内IGF活動活発化チーム チェア)
前村 昌紀さん(一般社団法人日本ネットワークインフォメーションセンター 政策主幹)
福智 道一(BBIX専務取締役)

とても豪華なメンバーで「何で福智さんここにおるんや?」とおもった人も多かったと思います。
自分でも何でだろう??と思ったぐらいですので。
呼ばれた理由を推測しますと、最近ウクライナ事情などでインターネット周りでいろんなことが起こったことやスプリンターネットなどの話題が盛り上がってる中、IX事業者としての視野角でインターネットがどう見えるのか何か話してほしいという感じかと思います。

そもそもインターネット・ガバナンスって何やねん

https://www.nic.ad.jp/ja/governance/about.html
このJPNICの解説に詳しくのっていますが、要は

  1. 「ガバナンス」と聞くと企業統治とかを思い出すけど
  2. インターネットはマルチステークホルダーによって構成されているし
  3. 単一の管理機構がなく中央集権的にルールを決めていない
  4. それゆえインターネットが健全に運営されるためには、 通信プロトコルの標準化、 統一された識別子の管理分配方法をはじめとした、 インターネット全体で共有されるルール策定が重要

ということなんですよね。

インガバを語る上で私が大好きな言葉と絵

We reject kings, presidents and voting.
We believe in rough consensus and running code.
(Internet Engineering Task Forceより)
この言葉と

この絵 (https://www.icann.org/en/system/files/files/ecosystem-06feb13-en.pdf)

本当、これに尽きるよねー

んで、IGF(Internet Governance Forum)ってなに?

ここは、IW2022でのあおちゃんのプレゼンをそのまま貼り付けますね。

総務省のある方に言わせるとIGFは、
「もちろん格式高い議論もありますが、いろんな人がいろんなテーマで話をしているのでもっと気軽に参加してもいいと思うよ」だそうです。

本当に日本で開催されます!!

https://www.soumu.go.jp/menu_news/s-news/01tsushin06_02000261.html
総務省の報道資料にもあります通り
令和5年10月8日(日)から12日(木)の5日間
場所は京都市にあります国立京都国際会館にて

せっかく日本で開催されるのだから

日本初開催となるIGF2023ですが、正直盛り上がりも準備もイマイチな感じがします。
IW2022のパネルディスカッションでもどうやって様々な人々を巻き込むかが課題だと。
特に若者の関心を集めることが次世代につながるので重要かと。
私が提案したのは日本最大のインターネットコミュニティであるJANOG
若者を交えて議論する場を用意すればいいのではないか?ということです。

2023年1月25日からJANOG 51が富士吉田で開催されます。
どなたか野良BoFで議論してみませんか?
少なくともJANOG若者支援プログラムに参加している学生さんには
必ず参加してもらいたいものです。

ご参考までに同じく先日行われた
『Day 2 特別セッション「IGF2023日本開催へ向けて」@日本インターネットガバナンスフォーラム2022 ~ IGF2023日本開催を見据えて』の録画を貼り付けておきますね。
時間のある方は参考までにご覧ください。


www.youtube.com

あとがき

すみません、投稿が超ギリギリになってしまいました。
もう来年は書かないかも
もし、書いてほしい!ということであればライターさんを募集します。
お礼は。。。晩ご飯、奢ります!^^

BBSakura Networksの今後について

BBSakura Networksの佐々木です。この記事はBBSakura Networkのアドベントカレンダー 最終日として投稿致します。 2019年に BBSakura Networksについて ということで、Blog投稿をさせていただきました。 当時は会社設立したばかりで、開発が完了しているサービスが何もございませんでしたが、今はいろんなソフトウェアを開発しております。本日はそれらのうちいくつかの紹介と、今後やりたいことについて少し紹介をさせて頂きます。

BBSで開発している物

BBSではさくらインターネット、BBIXを通じて開発しているソフトウェアを出しております。 特にBBIXでソフトウェアを使って実現しているサービス、システムはほとんど全てBBSのメンバーで開発されています。

BBSで開発しているシステムをいくつか紹介させていただきます。

さくらのクラウドのショートメッセージサービス

さくらのクラウドのショートメッセージサービス のバックエンドシステムはBBSにて開発しております。さくらインターネットとBBIXで一緒にBBSを作りましたので、両社のシナジーも込めて最初に商品化しました。

さくらのセキュアモバイルコネクト

さくらのセキュアモバイルコネクト は私がBBSを作りたいと思ったきっかけとなるプロダクトでしたが、今はBBSのメンバーでソフトウェアの保守・改良を行っています。 通信事業者で長らく働いていた私には、かなりエポックメイキングな商品だと思ってます。

BBIXのシステム

BBIX ウェブサイト もデザインは一部外に出しておりますが、BBSのメンバーで作成されてます!

BBIXお客様向けポータル

BBIXのお客様向けポータルではユーザーの情報などとともに、xflowを使ったトラフィックの可視化などを行ってます。 先日、advent calendarに投稿 してくれた蟹江もこちらの開発に従事しております。 トラフィックが目に見えるようになるのはネットワークエンジニアにとって楽しいですよね!

OCX (Open Connectivity eXchange)

OCX はBBSメンバーが主導となり開発したサービスとなります。 元々はCloudIX研究会でInter-Cloudというコンセプトを議論していたのですが、そのときにクラウド間のみならずマルチに簡単に接続出来るPlatformについて妄想を膨らませており、そのときのコンセプトをプロダクトにしました。蛇足ですが、 CloudIX研究会 は業界の様々なエンジニアが集まり、インターネット業界に入ったばかりの私にとっては大変刺激的な会でした。 あの出会いが無ければ今のOCXは無かったと思います。

OCXで実現したいこと

現在、ネットワークは当たり前ですが人間が使ってます。Webを見たり、動画を見たり、検索をしたり。なのでインターネットのサーバーとユーザー間の通信をeyeballトラフィックと呼んだりしておりました。 しかし、昨今、サーバー間・コンピューター同士の通信が増えており、通信の利用者の割合が「人間」から「ソフトウェア」へ、わかりやすく言えばAIへ急速に置き換わっていっていると感じてます。 現在の通信ネットワークは人間が利用するのを前提として設計がされてます。「人間」が申込みをしなければ使えませんし、「人間」が設定を入れなければつながりません。これから通信の利用者の中心がコンピューターとなるため、コンピューターに適したネットワークを用意しなければいけないのです。つまり、ネットワークをプログラマブルにし、ソフトウェアから扱いやすいものにしていきたいと思ってます。 これからデジタルツインと呼ばれる世界を作る中で、プログラマブルなネットワークは必須になってくると信じており、これを実現していきたいと考えております。世の中の様々なデータとサーバー基盤を連携させるための通信基盤。これを実現することで、デジタルツインを実現出来ると思っております。

理想と現実

一方で世の中が人間中心である中、いきなりコンピューターのみをターゲットにしたサービスは事業として成立しないなと思います。そこで、まずは人間にとって便利なネットワークを目指してOCXのサービスを開始しております。 今現在、OCXで出来ることは、データセンター間接続、マルチクラウド接続、ルーター機能となっておりますが、次々に「出来ること」を増やしていきたいと考えてます。このとき、いろいろなソリューションを簡単に組み合わせできるようなプラットフォームにしていきたいと考えており、Openに外部のソリューションを取り込めるような仕組みも取り込んで行きたいと思っております。 また、全国規模のアクセスポイントや様々なアクセス種別のインフラを地域地域のみなさんと一緒に構築し、ひとつの大きなネットワークプラットフォームを作ることで、ネットワーク効果を作って行きたいと考えております。

BBSakura Networksの今後

BBSakura Networksではソフトウェアをベースに世界に羽ばたくプラットフォームを作りたいと考えておりました。 まずは直近の2-3年で、国内の企業向けのネットワークサービスとして、ほとんどの方が「OCX」について認知を出来ているという状態まで広げていきたいと思ってます。並行して、海外にもサービスを展開していきたいと考えてます。OCXでは様々な技術が使われることになりますので、都度必要なソリューションをBBSとして拡充していきたいと思っております。 全ての「モノ」がつながる社会を支えるテクノロジーカンパニーを目指して、いろいろな種類の回線、クラウドサービスと接続し、こんなところにまでBBSがという状態に出来ればと思ってます!

CNTOM2022で発表したモバイルコア運用引き継ぎのお話

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

こんにちは。BBSakura Networks 株式会社開発本部の佐藤です。 気が付いたら 23 日でした。12 月もそろそろ終わりですね。

今年の 11 月に開催された CNTOM2022 にスポンサー枠で登壇しましたので、発表準備の過程で考えていたこと・発表後に改めて思い返したことを書きます。発表時の資料はこちらになります。

発表時に伝えたかったこと

クラウド基盤×自作EPCによるフルMVNOの運用とその実態

当日は「クラウド基盤×自作EPCによるフルMVNOの運用とその実態」というタイトルで発表しました。

タイトル中の「その実態」がポイントで自作 EPC システムの開発初期を支えたメンバーが徐々に離脱するなか、知識・経験が不足している自分が何に悩み、どんな道筋を立てて運用を引き継いだかを伝えたいと思いました。以下ではその中身を述べていきます。

運用参加初期に思ったこと

親会社であるさくらインターネットから BBSakura Networks に出向してすぐに「さくらのセキュアモバイルコネクト」のモバイルコア部分の運用開発メンバーに加わりました。 そして参加して間もない頃に発生した通信障害の対応を通してモバイルシステム特有の運用の難しさを実感しました。

  • 何らかのトラブルにより通信断が継続した場合にはシグナリングストームが発生すること
  • 外的要因(基地局〜モバイルコア間のネットワークのどこかで発生する通信断など)が解消された後でもシグナリングストームによる大量の通信要求を処理しきれないケースがあること

また、フルスクラッチで内製されたシステムであるため運用担当者には以下の認識が必要と感じました。

  • 自力で解決するしかないこと(トラブル発生時に保守業者にお任せといった対応はできない・エスカレーション先は無い)
  • そのため、通信障害を速やかに収束させるにはシステムに対する深い理解(システム全体を俯瞰して障害原因を特定・各コンポーネントソースコード把握)が要求される

出向前に在籍していたさくらインターネットの DC 業務および前職のシステム管理業務では、不具合発生時には予め定められた作業手順書に従って対応すること、復旧が困難な場合にはサポート先へエスカレーションすることが原則だったため、自分がこの水準を満たすには相応の時間が必要と判断しました。

そして何ヶ月か経過した後、開発初期からこのシステムを担当しているメンバーが社内異動等により徐々にチームから離れていくことが決定していきました。

自分が主担当として運用していくために何をすべきか

初期メンバーがチームを離脱するまでにある程度の期間が設けられていたため気持ちの準備はできていたものの、各メンバーが通常の業務に追われる日々が続いたため引き継ぎのための時間を十分に確保することは困難な状況でした。 そのため、開発初期メンバーと同等の知識経験が無い自分がこれまで実現されていた運用水準を維持向上してくためにはある程度の方針・計画を立てて進めていく必要があると感じました。それをふまえて実践したことが以下になります。

障害発生時の原因絞り込み & 認識の共有ができるための準備

システムを構成するサーバ・ルータの詳細なネットワーク図を作成しました。 意識した点として障害箇所とその影響箇所がひと目でわかるよう、すべての構成要素が一枚の図に納まるようにしました。加えて要素間での疎通確認・リモートアクセスが即座にできるよう各要素には IP アドレスの明記を必須としました。

ミドルウェアの統合化 & さらなる整理

開発初期のメンバーといっしょに進めてきたミドルウェアの統合化作業をメンバー離脱後も継続しました。 多少の修正を加えれば必要が無くなるミドルウェアは基本外す方向で積極的に置き換えていき、システム全体の構成をシンプルにすることに努め、障害発生時に疑うべき点を減らしていきました。

自動デプロイの導入はあえて採用しなかった

自動デプロイの導入が当初より検討されていましたが、理解が必要な技術が増えること、中途半端な状態で導入した場合の運用リスク(障害発生時、デプロイツールの動作に問題が無かったかを検討する時間が発生するなど)を懸念し、枯れた手段であるコマンドが列挙された手順書によるメンテナンス作業をあえて採用するようにしました。

サービス提供主体側との密な連携

サービス提供主体であるさくらインターネット側のメンバーと役割分担を推進して通信障害が発生した際に原因究明に注力できる体制を設けました。また、障害対応後の振り返りができるよう各役割の連携フローをまとめ、実際に障害が発生した際に用意したフローに従ってお互いが連携できるよう合同の運用訓練を定期開催するようにしました。

取り組んだ結果

稼働率(通信断の状態だった時間の合計割合)が前年度比で改善できたことは素直に嬉しかったです。 これまでのメンバーと行ってきた運用のあり方を変えていくことには正直不安がありました。もし開発初期メンバーが継続して運用する体制が維持されていれば、より良い体制になっていたのではないか?と常に感じていたためです。 今回の経験を通して自分が主担当として運用するシステムは自信を持って運用できる体制に思い切って切り替えていくことは、システムを引き継ぐ上での有効な手段であると強く感じました。

現在の取り組み

初期の頃を不安を乗り越えてたくさんの知識と経験を得ることができました。ソースコードの修正も抵抗なく行えるようになりました。現在はこれまで採用を見送っていた CD 環境の構築に挑戦しています。システムの更なる安定化と改善頻度の向上が両立できるよう精進していきたいと思います。