BIGLOBE鈴木(研)です。 久々の投稿です。 去る2/12にvExpert 2021の受賞の連絡をメールで受けました。 いよいよ3年目に突入となりました。★が3つになりました。 先輩は★10個以上の人もいるので、まだまだひよっこです。 今回の記事では、vExpertとは何か？どのようにすればvExpertになれるのか？について、私なりの理解を記してみたいと思います。 既に先輩方も同様の記事を書かれておりますので、そちらも参考にして頂けると幸いです。 ■vExpertとは vExpertとは、過去1年間でVMwareコミュニティに貢献した個人を、VMware社が表彰するプログラムになります。 ちなみに、2021年の受賞人数は下記になります。日本国内だと、この1年で17%増って感じですね。 全世界で2100人弱　←1年前は2000名弱 日本国内で83名　　←1年前は71名 ※今年の日本国内の人数は、2021/3/19時点でvExpertのポータルサイトのDirectoryで「japan」で絞り込み ■私がvExpertになったきっかけ 私は、2015年からVMUG(VMware User Group)というコミュニティに参加しております。そこで「JAPAN VMUG」というグループに参加をしております。 community.vmug.com そこでは、VMware製品のユーザ企業の方が、VMware製品およびパートナ製品に関する情報交換等を行っております。Japan VMUGの中にいくつか部会があり、そのうちの1つに参加をしております。隔月くらいで部会があり、時々そこでライトニングトーク（LT）をして事例発表を行ったり、年1回の総会（UserCon）に参加して、そこでも時々発表をしたりしております。 2018年くらいにJapan VMUGのリーダの方から、私のこれまでのJapan VMUGにおける情報共有の活動を受けて、「vExpertに申請してみないか？」というお誘いを受けて、やってみようかなと言うことで申請して通ったのが始まりとなります。 ■どういう活動がvExpertとして評価されるのか？ 主な活動としては、下記になります。 ブログ イベントでの発表 本の執筆、英語の本の翻訳 などにより、VMware製品の紹介、上手な使い方、トラブル時の対応についてなどを対外的に紹介をすることでVMwareコミュニティに貢献することになります。 ※vExpertは、資格ではありません ブログですが、年末ギリギリに何本も執筆するよりも、定期的に執筆するほうが良いとされています。 （年末に執筆が偏ると、間に合わせでやっている感が出てしまうようで、評価が下がるみたいです） イベントでの発表は、私の場合は、Japan VMUGのリモートイベントでのLTです。 本と言えば、Japan VMUGのメンバ（今井さん）が、最近下記書籍を出されておりますので、興味のある方は入手してご覧くださいｗ www.amazon.co.jp 注意点としては、次の年のvExpert申請時の実績は、その年に出した本だけが対象になるようですね。 超大作の本を出したと言っても、数年分の実績になるわけではないんですね。 ■私のvExpert2021の申請 vExpert 2021の評価期間は2020年1～12月になります。12月になると事務局から申請に関するお知らせメールが届きました。 申請方法は簡単です。 vExpertのポータルサイトにログインし、Application Formに入力して（英語で）、「Submit Application」ボタンを押して待つだけです。 私自身、それほど英語が得意ではないので、Google翻訳で英訳して、明らかにおかしそうな文を手で直す感じです。 年々Google翻訳の進化を感じています（訳がまともになってきています）。 問題は、Formに書く申請内容の方です。 私の2020年の活動内容を振り返ってみました。 2020年は、2月くらいから新型コロナウイルスの影響もあり、リアルに集合してのイベントが全くありませんでした。 なので、活動がVMware製品に関するブログでの情報共有が主体となりました。 リモートイベントが開催されたので、時々参加したりはしてます。 ただ、会社のチャットが見える中で参加するイベントだと、集中は出来ないですね。リアルで集まってのイベントが良いですね。やっぱ。 それで、2月11日（US時間）でメールで受賞の合否が分かりました。 ■vExpertの特典 「どういう特典があるか？」ですが、いろいろありますが、やっぱ「VMware製品の1年間のライセンスがもらえる」ことが一番ですね。 私は、現状ではホームラボがノートパソコン1台なので大したことはできませんが、そろそろホームラボ拡充に向けて鋭意検討中でありますｗ 製品を触って、ブログで情報共有をすることで、コミュニティへの貢献になる、って流れですかね。 VMware社としても、vExpertが活動するために必要となるリソースとして、ライセンスを提供しているという側面もあります。 ※このライセンスで商用サービスをしてはいけません ■おわりに Japan VMUGで、他社の方と製品の使い方や障害の話をすると、いろいろと意外な側面に気づかせてくれたりもします。障害の話で意気投合すれば、もう同士です。 Japan VMUGにも10名以上のvExpertが在籍しています。中にはスーパーマンのような方もいて、困ったことを相談すると即解決してくれたりする場合もあります（VMware社のサポートより速く）。 また、メンバの皆さんがユニークの方が多く、皆さんそれぞれVMware製品での苦労をしていて、技術やノウハウをたくさんお持ちで、尊敬できる方が多いです。なので、「メンバの皆さんから情報をもらうだけでなく、自分も貢献したい」と思える雰囲気があるのが良いところだと思っています。 是非Japan VMUGに参加いただいて、いろいろと活動をした結果として、vExpertになろうと思う人が増えてくれることを願っています。 私自身は、来年もvExpertになれるよう、今年1年も私が出来るコミュニティへの貢献を頑張ろうと思います。 ※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。 ■お知らせ VMwareユーザ会（VMUG）に興味のある方は、 https://www.vmug.com/membership/membership-benefits から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。 以上です。

Terraformコードの構造化が進み、変更するたびになんども terraform apply を叩くはめになったことはありませんか。 実行する順番を間違えてトラブルになったことはありませんか。 そんな悩みを抱えているときに見つけたAstroというツールを紹介します。 自己紹介 対象の読者 Terraformコードの構造化と直面した課題 Astroとは Astroを使ってみる Astroをインストールする astro.yamlファイルを用意する 1. モジュールを追加する 2. モジュール間の依存を追加する その他 実行計画を確認してみる 実際に構築してみる 環境を破壊（destroy）する Astroを使うときのTips applyしたら即実行 .astroディレクトリのcacheは定期的に消しましょう 実行時のログ Terraformのローカルモジュールを使うとモジュールパスが変わってしまう 2020年1月を最後に開発が止まっている 最後に 自己紹介 基盤本部基盤系システム部に所属している、梶田（かじた）といいます。 現在、基幹システムのクラウド移行プロジェクトに従事しています。 BIGLOBEの基幹システムは10年以上稼働し続けており、独自技術がふんだんに使われているので移行プロジェクトは一筋縄ではいきません。 クラウドに移行する際、将来のさらなる自動化や、動いているシステムとリンクするドキュメントを残す目的でインフラのコード化もすすめています。 自分の関わるシステムではインフラのコード化にTerraformを活用しています。 対象の読者 今回の内容は、Terraformを使ってひととおりシステム構築をすすめてきた経験を持っている人が対象です。 Terraformコードの構造化と直面した課題 Terraformを使うメリットの1つにソースコードを構造化しやすい点が上げられます。 実際に弊社でTerraformを使ってコード化に取り組んでいくと、以下のような段階を踏んで構造化がすすんでいきました。 サンプルコードをコピペするなど、1つのファイルに全部のリソースを定義する（モノリス） 後から読む人が理解しやすいように、モジュール（Web、Database、Networkなどの意味のある塊）毎にファイルを分ける モジュール毎にディレクトリを分け、モジュールを個別に構築できるようにする Terraformコードの構造化が進んでいくと、2つの問題が発生しました。 複数モジュールにまたがって修正した際、1つづつapplyを実行するのは面倒で、実行し忘れることもある モジュール間に依存関係があり、順番を間違えるとエラーになる とくにCI/CDツールで自動化したときいろいろと悩むことになりました。 そのような中、Terraformの情報をいろいろ調べているときに見つけたのが、 Astro です。 Astroとは Astroは、Uberが開発した複数ディレクトリに分割されたTerraformファイルをまとめて実行するユーティリティです。 現在、GitHub上でApache License 2.0ライセンスとして公開されています。 Astroは、実行に関する設定をYAMLフォーマットのファイルで記載します。 この設定ファイルには、ディレクトリで分割されたTerraformファイルの依存関係を記述することができ、依存関係を考慮した順序でTerraformを実行します。 つまり構造化されたTerraformを定義することで、apply漏れや実行順序の間違いを防止できるユーティリティです。 今回は、Astroの基本的な使い方と使っていてはまったことを紹介しようと思います。 Astroを使ってみる Astroをインストールする 本記事の執筆時点の段階で、Astroのインストール方法は2つあります。 1つは GitHub から、自分の環境にあったファイルをダウンロードする方法です。 ダウンロードしたファイルを解答すると、 astro と tvl という2つのコマンドが含まれています。 この2つのファイルをPATHの通ったディレクトリにコピーすればインストールは完了です。 もう1つの方法は、goコマンドを利用する方法です。 具体的には、go 1.12以上をインストールして go get コマンドを実行します。 詳細は、 astroのReadme を参照してください。 Astroは実行時に必要なバージョンのTerraformをダウンロードするので、Terraform単体をダウンロードする必要はありません。 astro.yamlファイルを用意する Astroは、astro.yamlという名のYAMLファイルにTerraformを実行するときの設定を記載します。 次にこんな構成のTerraformファイルを想定して、astro.yamlのフォーマットを説明します。 root/ ├ network/ ... VPCのリソースを定義したTerraformファイル群 │ ├ provider.tf │ └ vpc.tf │ ├ lb/ ... ALBのリソースを定義したTerraformファイル群 │ ├ provider.tf │ ├ security_group.tf │ └ alb.tf │ ├ web/ ... Webサーバのリソースを定義したTerraformファイル群 │ ├ provider.tf │ ├ security_group.tf │ └ ec2.tf │ └ database/ ... Databaseのリソースを定義をしたTerraformファイル群 ├ provider.tf ├ security_group.tf └ rds.tf 1. モジュールを追加する rootディレクトリ直下にastro.yamlという名前のファイルを作ります。 astro.yamlの内容は、こんな感じになります。 --- terraform: version: 0.13.5 modules: - name: network path: network - name: lb path: lb - name: web path: web - name: database path: database 最初の"terraform/version"で実行時に利用するTerraformのバージョンを指定します。 astroは初回実行時に指定されたバージョンのTerraformをダウンロードしてくれます。 modules以下で、実行するTerraformファイルを格納しているディレクトリを指定します。 "modules/name"でディレクトリにユニークなモジュール名をつけます。モジュール名は、あとで依存関係を指定するときに利用します。 "modules/path"でディレクトリのパスを指定します。 そんな感じに、まとめて実行したいTerraformの格納ディレクトリを記載します。 2. モジュール間の依存を追加する ひととおりモジュールの記載が終わったら、モジュールの依存関係を追加します。 依存関係は、"deps"で指定します。 depsを追加したastro.yamlの内容は下記のようになります。 depsキー配下に、"module: <モジュール名>"をリストで追加します。 --- terraform: version: 0.13.5 modules: - name: network path: network - name: lb path: lb deps: - module: network - name: web path: web deps: - module: network - module: lb - module: database - name: database path: database deps: - module: network 今回は、lbモジュールとdatabaseモジュールはnetworkモジュールに、webモジュールは他の3つ（lb、web、database）のモジュールに依存しています。 このように記載してからAstroを実行すると、以下の順序でTerraformが実行されます。 network lb, database web その他 ここで紹介しきれませんでしたが、astro.yamlには他に下記のような設定も記載できます。 詳細は、 astroのReadme を参照してください。 Terraformの実行前に実行するコマンド。事前にロールを切り替えたりする際に利用します Remote Backend の設定 variable にわたすパラメーター。astro実行時に置き換えることもできます 実行計画を確認してみる まずは、実行計画を確認します。Terraformの planコマンド にあたります。 AstroもTerraformと同じく、"plan"コマンドで実行計画が確認できます。 "--config"オプションで指定しなければ、astro.yamlをカレントディレクトリの中で探します。 "-v"オプションを指定すると少し詳細な情報が表示されます。 astro plan -v --config astro.yaml 実行すると、このような実行結果が得られます。 もし、変更箇所があった場合、変更箇所の情報が合わせて表示されます。 [database] Initializing... [network] Initializing... [web] Initializing... [lb] Initializing... [network] Planning... [lb] Planning... [database] Planning... [web] Planning... network: OK No changes (0s) database: OK No changes (0s) lb: OK No changes (0s) web: OK No changes (0s) Done 特定のモジュールに対してだけコマンドを適用したい場合、”--modules”でモジュール名を指定します。 下記は、lbとwebモジュールのみを実行する例です。 astro plan --config astro.yaml --modules lb,web 実際に構築してみる astro.yamlで定義したモジュールに対してapplyを実行します。 注意事項として、AstroにはTerraformと異なり実行前の最終確認はありません。 applyを実行すると直ちに構築が開始されるので必ず先にplanを実行するクセをつけましょう。 astro apply -v --config astro.yaml applyコマンドも”--modules”オプションを使って個別にモジュールを指定して実行できます。 astro apply --config astro.yaml --modules lb,web 環境を破壊（destroy）する Astroには、構築に関するコマンドはplanとapplyしか用意されていません。 それ以外のコマンドを実行したいときは直接Terraformを利用します。 Astroを使うときのTips applyしたら即実行 使い方の説明でも述べましたが、Astroはapplyを実行したときの最終確認は一切行わず直ちに構築を開始します。 必ず、planで変更内容を確認するようにしましょう。 .astroディレクトリのcacheは定期的に消しましょう Astroは plan や apply を実行すると、astro.yamlファイルのあるディレクトリに.astroという名前のディレクトリを作ります。 そして、astro.yamlファイルで定義された全モジュールのTerraformファイルをディレクトリ毎コピーします。 さらにこのコピーをモジュールの数だけ作るので、実行後は思いもがけないほどファイルが作られてしまいます。 使っている開発エディターによっては、ファイルスキャンが走って遅くなることがあるのでまめに削除して掃除しましょう。 また、誤ってGitのレポジトリに登録してしまわないように、.astroディレクトリを.gitignoreに含めたほうがよいでしょう。 実行時のログ Astroは裏でTerraformを実行しています。Astroを使っていると、エラーの調査などでTerraformの出力を確認したくなることがあります。 Terraformの実行結果は、".astro/<ランダム文字列>/<モジュール名>/logs"ディレクトリ配下にログとして保管されています。 Astroを実行するたびにランダム文字列のディレクトリが増えるので、繰り返し実行していると自分の探している実行時ログの場所がわからなくなります。 そういうこともあるので、.astroディレクトリはまめに掃除しましょう。 Terraformのローカルモジュールを使うとモジュールパスが変わってしまう システムが複雑になり、 Terraformのモジュール を活用することがあるかもしれません。 Astroは、 ローカルパス参照のモジュール と相性がよくありません。 実行すると.astroディレクトリにTerraformファイル一式をコピーすると説明しましたが、その影響で実行時ディレクトリが変わってしまうためモジュールのパスも変わってしまいます。 とりあえず動かすだけならAstroに合わせてパスをかえてしまえばよいのですが、Terraformと併用すると都度モジュールのパスを書き換えることになるのであまり良い手ではなさそうです。ここは、別のソース（GitHubとか）で指定するようにするのが良いかもしれません。 2020年1月を最後に開発が止まっている もしかするともっと良いツールが存在するのかもしれません。 でもソース自体が公開されているので、Go言語の勉強がてら色々気になるところに手を加えながら使うといいのかもしれないですね。 最後に というわけで、Astroというツールを足早に紹介しました。 機能を絞りつつ痒いところに手が届くツールだと思います。 ※ GitHub は、GitHub Inc.の商標または登録商標です。 ※ Terraformは、HashiCorp,Inc.の米国およびその他の国における商標または登録商標です。 ※ Uberは、Uber Technologies, Inc.の商標または登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。今回は、第二新卒で文系営業職からエンジニアとして入社した若手社員のインタビューをお送りします。なぜエンジニアの道を選んだのか、当社におけるエンジニアの適性について話を聞いてみました。   松島 拓哉（まつしま たくや） 基盤本部   サービス開発部   モバイル開発グループ 2019年3月第二新卒入社（入社当時24歳） 前職は金融・保険業界の営業職。現在はエンジニアとしてモバイル通信事業に関わるサービス系システム等の開発・運用に携わる。   第二新卒で営業職からエンジニアへキャリアチェンジ エンジニアを目指したきっかけ エンジニアとして大切なのは目標を明確に持ち行動を起こすこと BIGLOBEのエンジニアってどんな人？ 自身の成長をふりかえる 上司からのコメント 第二新卒で営業職からエンジニアへキャリアチェンジ   ────　松島さんは第二新卒で文系出身からエンジニアとして入社しました。学生時代はどんなふうに過ごしていたのですか？   法学部で、ゼミも法律系。ロースクールにも通ったりして、がっつり文系寄りの勉強をしていました。サークルは陸上と、美味しいものを追い求めるグルメサークル。陸上は高校の時に県大会や関東大会に出たりしていましたが、大学では運動の一環として活動していました。といっても実はゲームが趣味のインドア派です（笑）ごく一般的な文系大学生でした。   ────　松島さんは新卒で金融・保険業界の営業職として就職していますが、当時の就活の軸はなんだったのでしょうか。   プライベートが充実している＝人生が充実しているだろうと考えていたので、とにかく安定していてワークライフバランスの良さを軸に就活していました。それこそ公務員や大きい企業で働ければいいかなと考えていたんです。そして、その軸で入社した会社では金融や保険の商品をお客様に提案したり、売り上げを伸ばす施策を企画・実行したりしていました。1年経ったころに一部門のリーダーを任され、自分なりに考えたアプローチの仕方などをメンバーに展開した結果、管轄内で1位の成績を収めることができました。この成果は自分だけの力ではなく、いろんな方の助けがあって実現したものだと思っています。   ────　入社1年でリーダーを任されたんですか？   はい。理由は聞いていませんが、営業成績や人並み以上のやる気という部分で周りを引っ張ってまとめてくれると期待されてのことだったのかなと思います。   エンジニアを目指したきっかけ   ────　営業職で活躍していた松島さんがエンジニアを目指そうと思ったきっかけを教えてください。   きっかけは2つあります。1つ目は、自分の仕事に対する価値観の変化です。先ほど話したとおり、以前は安定していること、プライベートが充実していることを軸としていました。ですが、いざ社会人になって仕事をするうちに、「仕事って意外と人生の中で充実感を得られる場なんだ」と気づいたんです。プライベートだけが充実していればいいわけじゃないと。仕事でもさらなる充実感を得るにはどうするべきかと考えた時に、もう少しチャレンジングな場所で働いてみたいと思いました。2つ目は、時代の流れです。もう終身雇用の時代ではないので、自分の力で戦っていけるスキルを持った人間になりたいと思ったんです。 じゃあなぜエンジニアなのかというと、今はやはりIoTやICTなどIT全盛の時代です。その流れがしばらくは続くだろうと考えた時に、エンジニアという選択肢が出てきました。「エンジニアとしてスキルを伸ばして自分の力で戦っていく」ことを目指して、転職活動を始めました。   ────　未経験なのにエンジニアになりたいと思ったということは、もともとなんとなく興味はあったんですか？   そうですね、ゲームが趣味というのもあって、学生時代にたまたまプログラミングをほんの少しですが触る機会があったんです。こういう風に動いているのか、と興味深かったのを覚えています。   ────　エンジニアになろうと決断したとき、何から取りかかりましたか？   プログラミングをほんの少し触ったことがある程度では履歴書に書けないレベルでした。なので、まずは1つの言語でもいいから勉強して、プログラミングってこういう風に書くのか、こういう風に動くのかと理解するようにしました。その時勉強したのはRubyというプログラミング言語です。それを選んだ理由は単純に、ネットで「初心者におすすめ」「わかりやすい言語だからこれから学ぶといいよ」って書いてあったから（笑）。3カ月位みっちり独学して、エンジニアとしてどういう会社に行きたいか軸を絞っていきました。   ────　会社を選ぶ際に重視したことはありますか。   まず自分のスキルを伸ばせる環境かどうかを重視しました。BIGLOBEを選んだ理由は、自社開発なら新規サービスの開発や自社サービスを保守し続けるので高いスキルを積めるのではということと、昔ついっぷる*を利用していてBIGLOBEを知っていたからです。そして、面接を通して会社の雰囲気を知っていく中で志望度が高くなってきました。社員がのびのびと自由に仕事しているように見えつつも、技術的な勉強を積極的にしている感じが伝わってきて、自分が目指している目的とマッチしていると感じたのが決め手です。 ＊ついっぷる：2017年10月までBIGLOBEが提供していたTwitterクライアントサービス   エンジニアとして大切なのは目標を明確に持ち行動を起こすこと   ────　情報処理やプログラミングの知識がないと難しいと思ってしまいますが、実際にエンジニアになってみてどうですか？   プログラミングの知識の面で、学生時代に勉強をしてきた理系の人と比べるとまずスタートラインが違います。そこに追いつくのは明らかに大変で、もちろん勉強が必要です。 ただ、文系と理系の違いは学生時代にプログラミングを触る機会やプログラミング的な思考を養う機会があったかなかったかの差でしかありません。機会がなかったのなら機会を自分で作ればいいだけの話です。なので、スタートラインに差があることで焦りや不安を持つ必要はなく、大切なのは自分がエンジニアになって何がしたいか、何を実現したいかという目標を明確にもって、そのためには何が必要なのかをきちんと理解することだと思っています。それが理解できたら、ひたすら勉強を頑張る。これはエンジニアに限らず仕事をする上で大事なことですね。 BIGLOBEは未経験の自分を理解して採用してくれたはずなので、頑張って勉強して、焦らず着実にスキルを伸ばしていけるか、へこたれずにチャレンジできるかだと思っています。   ────　実際にスタートラインでの差をどう乗り越えたのでしょうか。   入社は３月だったのですが、未経験だったことから１カ月間は準備期間としてプログラミングの勉強をしながら過ごしていました。４月になり新卒の研修に合流して研修を受けたのですが、理系に比べ在学中の勉強の差はめちゃくちゃ感じました。ですがそれは仕方のないことで、文系未経験としてスタートラインに差がある事実を認め、そこに追いつくために頑張りました。 分からない言葉もその場で聞いてメモしたりしていましたね。特に入社後はプログラミング知識の他に、会社特有のシステムとか単語とか分からない用語だらけですから。そうやって着実に疑問を解消していきながら少しずつ自分の知識の空白を埋めていきました。   ────　スキルを身に着けるために意識していることは？   仕事をしていく中でこのスキルが足りないと感じたら見逃さずに勉強するようにしています。 1つ言語を学ぶと他の言語の体系もなんとなく分かるので、いろんな言語を学ぶのもさほど苦労ではありません。実現したいことにあわせた技術やスキルを身に着けるのは楽しいですね。   ────　注目している技術トレンドと、それに対して取り組んでいることはありますか？   現在、全社的にAWS（Amazon Web Services）を活用していこうという方向性を示していることもあって、AWS等の資格取得に向けて、クラウド関連の知識習得を目指しています。   ────　どんな人が文系でもエンジニアとして活躍できると思いますか。   文系理系関係なく、大切なのは、学生時代に経験した活動や交流を通じて得られたものをどう生かしていくかということ。文系でプログラミングを全く勉強していなくてもこれまでのコミュニケーションの経験を生かして、きちんと相手の言っていることを受け止められる人の方がエンジニアとしても他の職種としてもいい人材になれるポイントだと思っています。 ・相手の言うことをきちんと受け止めて理解できる ・自分の意見を相手にきちんと伝えられる ・前向きに頑張れる ・自分がどうありたいか理想をしっかり持っている ・成長意欲があり、行動に移している このようなベースがあれば、きっとエンジニアとして活躍できると考えています。 私自身も学生時代や前職の営業でコミュニケーション力を養っていたので、それを強みとして日々励んでいます。   BIGLOBEのエンジニアってどんな人？   ────　BIGLOBEのエンジニアにはどういう人が多いのか教えてください。   スキルアップに貪欲で、本当に勉強熱心な人が多いですね。すごくできる人なのにまだ先をいくのか！という感じです。自身のスキルアップのために何が必要でどういうノウハウをためるべきかを常に考えているし、周囲にも共有してくれます。 未経験の自分に対しても、勉強会に招待してくれたり、最新技術やおすすめの書籍、セミナーを教えてくれたり、どういうふうに学んでいけばいいかなど、関心を寄せてくれるエンジニアが多いです。 あとは、ロジカルにものを話す人が多いですね。相手に言われたことを一度自分の中に落とし込んでかみ砕いてから意見を言う。そういうやりとりができる人ばかりなので、自分の言ったことをすぐさま否定されるといったことがありません。   自身の成長をふりかえる   ────　入社直後に比べて、どのような点で自分自身の成長を感じていますか？   入社直後はそれこそプログラミングも頭でっかちでしたが、今ではBIGLOBEのシステムやプログラミングの理解度は格段に違います。自信をもっていろんなことに取り組めるようになったのでそのあたりは進歩したなと思っています。作ったモノが動いているのを見るのが自分の中で一番楽しい瞬間ですね。 多少不安があったのは事実ですが、今思えば杞憂だったなと実感しています。 やはり、成長意欲は大事です。エンジニアとして活躍できるかできないかの線引きはそこだと思っています。その成長意欲は目標があってこそ出てくるもので、目標に向かってどう努力すべきか見えることで、意欲・モチベーションにつながります。エンジニアになったから終わりではなくエンジニアになってからが始まりで、スキルにゴールはないです。今のスキルのままでいいやと思ってしまうと、BIGLOBEでは大変な思いをするのは間違いないので、何を実現したいのかちゃんと目標を持つことが何より大事だと思っています。   上司からのコメント 💡松島さんの上司（部長）に話を聞いてみました💡 松島さんを採用した際、新入社員、第二新卒を受入れて育成するということで、その選考では大学の専攻は条件にしていませんでした。一方でエンジニアは技術の進化をキャッチして自分自身が成長させ続けたり、担当するシステムや開発プロセスを進化させ続けたりしていく必要があります。 松島さんを採用した決め手は、 ・現状に甘んじることなく、成長し変化し続けられる人財であると思えたこと ・それを裏付ける行動と実績があったこと です。 具体的には、前職の営業職での経験からそれが読み取れました。 ・自ら創意工夫した営業ツールを企画・実行し、営業成績として実績をあげたこと ・その実績から上司や周囲に認められ、リーダーとして業務を任されていたこと これらのことから、社会人としてしっかり行動でき、会社へ貢献ができる人財とも思いました。 また、エンジニア職へのキャリアチェンジを決意したのち、転職活動に先立ってすでに情報処理系の勉強を始めていると聞き、ここでも行動力・実行力を確認することができました。 入社後も業務の幅を広げるため、自ら様々な業務にチャレンジし、一定の成果を出しています。 もちろん情報系の大学やそれ以前から学んできた社員に比べれば、知識の幅や深さにおいてまだ追いつききれていないところもありますが、それは想定内です。 一方で営業職経験で身についたと思われるお客様視点を意識した提案力など、他のエンジニアに勝る部分を垣間見ることもあり、今後エンジニア経験を重ねたときには、他のエンジニアを超える活躍をしているであろうことが期待できる存在となっています。今後がますます楽しみです。   最後までお読みいただきありがとうございました。   ※Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc.またはその関連会社の商標です。   BIGLOBEでは未来を担うチャレンジングな若い力を歓迎しています！私たちと一緒にBIGLOBEを盛り上げてみませんか？ご興味のある方は、採用サイトをご覧ください。 新卒採用サイト  中途採用サイト hrmos.co style.biglobe.co.jp style.biglobe.co.jp

社内アドベントカレンダー、2020年も盛り上がりました！ BIGLOBEでは2006年から社内ブログを運用し続けています。社内ブログは社内の誰でも書くことができ、社内ポータルサイトの一番目立つところに最新記事が表示されます。社内のお知らせに利用する人、ただ単に面白かったことを社内に共有する人など、様々な使い方がされています。 そんな社内ブログが一番盛り上がるのは12月です。それは社内アドベントカレンダーというイベントが開催されるからです。 もともとのアドベントカレンダーは、12月1日から25日のクリスマスの日までの専用のカレンダーです。25個の窓の中に、お菓子やおもちゃが隠されていて、一日ずつその窓を開けて、中のものを楽しむ使い方をします。その習わしをもとにしたブログ企画がITエンジニア界隈で定着しているアドベントカレンダーです。25日分のカレンダーを準備し、参加者が持ち回りで1日1記事を公開していきます（BIGLOBEの社内アドベントカレンダーは平日のみのカレンダーでやっています）。 zine.qiita.com 2014年からは開発部門の有志から始まった企画は徐々に参加者が増え、2020年は5つのカレンダーが立ち上がり、開発部門・ビジネス部門関係なくたくさんの記事が集まりました！テーマを決めているカレンダーもあれば、どんな内容でも良いカレンダーもあります。 そんな社内アドベントカレンダーに、外出自粛中の趣味としてハードウェアネタを投稿してくれた始関さんの記事をご紹介します。社内の雰囲気を感じていただければ幸いです！ 自作キーボードの沼を覗いた👀 基盤本部ネットワーク技術部というところにいる、始関（しせき）といいます。 今は主にVirtual Private Network（VPN）の業務を担当しています。 自作キーボードって？ パソコンで文字を打つあのキーボードを自分で作ってしまおうというものです。 自作といってもキットがあって、 遊舎工房さん のようなお店で簡単に手に入れることができるので、はんだ付けと基本的なPC操作ができれば作れます。 基板の設計から始める、いわゆる「ガチ勢」と呼ばれる方々もいて、市販されているキットの多くはそういった人たちが設計したものとなっています。 今回は、作り方には言及せずに特徴とか作ったものとかを初心者なりに紹介してみようかと思います。 （技術的な話を期待されていたかたがいたらゴメンナサイ） おすすめしたい理由 自作といっている通り、自由度が非常に高いです。 市販のキットでもキー配列や押した感触を好きなように変えられますし、ちょっと改造してUSBハブをつけたりすることもできます。 キー配列については、基板や配線をいじることなくソフトウェアだけで簡単に好きなレイアウトを作れます。この点だけでもおすすめできます。 作ってみたもの 初心者なので、いきなりフルサイズのものは作らずに、部品数が少なくキットの値段も手頃なテンキーを作ってみました。 まずは作りたいものを決めます。 場所をとりたくない、PCは左側にある、マウスのレシーバーをつけたい……ということで、要件は以下としました。 クレジットカードくらいのフットプリント 横長で左からケーブルを出す USBハブ機能 探してみたところ、「Shiro」という15キーのキットが一番近そうだったので、これの厚みをかさ増ししてUSBハブを足してみます。 キーボードキット + キー15個 + キー印字シール + USBハブ基板で6000円くらいになりました（シールが意外と高かった……）。 完成したものがこちらです。 数字キー・BackSpace・Enterだけにして省スペースを実現。記号は左上（7の左）と同時押しで入力するようにしました。 左端にある無刻印の列は機能切替です。 上: テンキー 中: マウス操作 下: コピペなどのよく使うキー としています。 普段使っているキーボードの下にちょうど収まるなと思いついて、角材を切ってリストレスト（パームレスト）を作りはめこんでみました。 USキーボードなので日本語切替がめんどくさかったのですが、コピペモードの7を英数に、9をかなにしてMac風の操作ができるようにしてみたら快適になりました。 作った感想 キー配列を自由に作れる、という部分に特に魅力を感じました。 工夫すれば、PCにはJISキーボードとして認識されるUS配列のキーボードとか作れそうです（実際に、そういう作例もあるようです）。 今度作るときは全キーそろったキーボードを作ってみたいですね。 いかがでしたか？ 社内アドベントカレンダーから始関さんの記事をご紹介しました💪 ITエンジニアが一生の中で一番多く触れる道具がキーボードですよね！始関さんによると、CtrlキーやEscキーの位置を変えることはもちろん、打鍵音や押し込みやすさをキーによって変えることも可能とのことで、自作キーボードの趣味がハマると抜けられないほど楽しい「沼」であることが良く伝わってきました！ また、自宅で使う道具への強いこだわりは、仕事においても効率性の向上や知識の深耕につながっているのでは？と感じることができました。いきなりフルキーボードに取り組むのではなく、小さくテンキーからはじめるところも、新しいことに取り組む姿勢として大事だと思いました。 皆さんの愛情やこだわりがあふれる社内アドベントカレンダー、とっても盛り上がっています🙌 こんな風に社内でもワイワイやっているBIGLOBEで働きたい方を大募集しています！カジュアル面談も実施していますので、どうぞ気軽に遊びにいらしてください。 hrmos.co

こんにちは。BIGLOBE Style編集部の吉田です。今回は、SIerからBIGLOBEへ転職したエンジニア社員の対談をお送りします。 （実施日：2021年1月） BIGLOBEにすぐ馴染み、成果を出し続けている座間と櫻井。プログラマーとしてコードを書き続けるエンジニアリングマネージャーのもと、ドメイン駆動設計やAmazon Web Services （AWS）といったチャレンジングな技術を使ったシステム開発にワクワクしながら取り組んでいます。   座間 政紀（ざま まさき） 2019年6月中途入社／社会人6年目 基盤本部   基盤系システム部   基盤横断システム開発グループ 前職は中小企業のSIer。既存システムをリュニューアルするプロジェクトのチームリーダーを経験。   櫻井 耕司（さくらい こうじ） 2019年9月中途入社／社会人8年目 基盤本部   基盤系システム部   基盤横断システム開発グループ　主任 前職は大手企業のSIer。人工衛星の地上局や顔認証のシステム化などに携わる。   💡所属部門の雰囲気を聞いてみました💡 めちゃめちゃ仲が良く、リモートワーク中もGoogle Meetをつなぎっぱなしにしていつでも聞きたいことが聞ける状態で、たまに雑談もしています（笑） グループリーダーの西さん（ 詳しくはこちらの記事をご覧ください ） はマネジメントする立場でありながら完全にエンジニア志向なので、エンジニアとしてとても働きやすい環境を作ってくれています。また、グループメンバーが社内ブログに技術的な記事を書くと、すぐに反応してくれるメンバーや上司がいるので、とても楽しいです。   転職のきっかけ BIGLOBEで学び、アウトプットする楽しさ 自社開発の魅力とは 開発環境について 成長とやりがい 今後について   転職のきっかけ   ────　早速ですが、転職のきっかけを教えてください。 櫻井 ：中堅社員となり役職が主任になってから、プロジェクト管理やお客様との調整がメインの仕事として増えていったんです。それよりは、手を動かして開発をしていたかったので、「自分に合う会社があれば行くか」と比較的緩い気持ちで転職活動を始めました。そこで登録していた転職エージェントから、開発に力を入れているBIGLOBEはどうかと勧められて応募しました。面接の際に、設計や技術のスキルアップに力を入れているという具体的な説明があり、転職後のイメージが描けたのが決め手でした。   座間 ：僕もSIerだったので受託開発が多く、システムリニューアルがメインで一からシステムを作ることがありませんでした。プログラミングをがっつりやれたのは楽しかったのですが、自分自身設計力が弱いと感じていたので「自社のシステムを強くしたい、質をあげたい」という想いから転職活動を始めました。 会社をいろいろ見た中でBIGLOBEに決めたのは、直感です（笑）。採用面接に進む前にカジュアル面談を通じて事業の説明をしてくれたのが印象深く、マッチングを大切にしてくれているのが分かり、入社を決めました。 BIGLOBEで学び、アウトプットする楽しさ   ────　実際にBIGLOBEへ入社して、いかがでしたか。 櫻井 ：まず、企画から開発、運用まで自社で担っているので、何かとコミュニケーションがとりやすくスピード感がありますね。   また、ドメイン駆動設計（Domain Driven Design: DDD）などのモデリングにもかなり力をいれているので、その能力も身に付きますし、得られた知見をアウトプットしているのも魅力だと思います。例えば、「DDDモデリングハンズオン」と題して、 「BIGLOBEの格安SIM料金計算システム」 や、先日テックブログで小野田さんが解説していた 「新幹線料金計算システム」 のワークショップを一般参加型で行ったり。 きちんとモデリングしたコードで保守しやすくしているのは新鮮でした。 BIGLOBEでは全面的にAWSに移行している最中で、そうしたチャレンジングなことに取り組めるのもいいですね。   座間 ：同感です。チャレンジングな空気、社風はありますよね。AWSもDDDも、ボトムアップな感じで自発的に動いているのはかなりいいと思います。 ハンズオンのイベントはYahoo!さんと合同で行ったので、社外との交流もできますし、 技術書典（技術書の即売会） にも参加したりと、自分たちの取り組んでいる開発をアウトプットする活動が盛んなのは非常に楽しいです。   櫻井 ：そうですね。これまでまとまった文章を公開した経験がなかったのですが、技術書典でまるまる1章分を書くのは色々と新鮮でした。デザインや校閲の面では社内のさまざまな方から支援していただき、何とか本として出すことが出来て楽しかったです。 座間 ：この本はBIGLOBEへ転職して間もない中途採用のメンバーが集まって執筆しました。それぞれのスキルが違うのがとても面白かったです。 SIer出身の人が結構いましたが、 ・設計メインであまりプログラミングしたことがない人 ・むしろプログラミングばっかりやってた人 ・技術系志望で管理職になるのがいやできた人 など、多種多様なメンバーと話をしながら一冊の本にまとめました。執筆活動の話から外れますが、話をしてみるとみんな前職での悩みを解決するためにBIGLOBEにきたんだなぁと感じました。それぞれが自分の悩みを解決できるBIGLOBEにしたいなと思っています（笑）。 あと、別の視点では、若手でも裁量が大きい点が魅力です。「こんな技術を使いたい」「こういう風にシステムを作っていきたい」という意見を聞いてくれる風通しの良さがあります。 SIerだと、上のポジションにいる人が決めたアーキテクチャに従って実装するのが常でしたが、自分の意見で設計から最後の実装、テストまでをやれるのもBIGLOBEの大きな特徴の1つですね。今携わっているシステム改善の業務でも、企画段階から関わることができているのでやりがいがあります。   自社開発の魅力とは   ────　BIGLOBEにはスピード感、チャレンジング、裁量が大きい、 得られた知見の公開と社外交流など、さまざまな魅力があるんですね。ちなみに、 元SIerから見る自社開発の魅力とはなんでしょうか。 櫻井 ：SIerだと、限られた期間でシステムを作って納品して終わり、という作りきりが多いんです。自社開発は、作った後に何年も保守していくのは自分たちなので、開発効率に加えて品質や保守性を向上するためにスキルを身に着けようとするなど、チームや自分自身の成長につながる側面が多いところが魅力です。 座間 ：何より楽しいのは、自分の関わっているシステムがどんどんよくなっていくのを感じられることですね。作ってリリースしたら終わり、というドライな開発ではなく、リリース後も長年付き合っていくシステムになるので、愛着がわきます。   ────　お二人とも入社すぐにBIGLOBEの環境になじみ、成果を出し続けてくれています。SIer時代に培ったスキルで、BIGLOBEでも活きていると思うものはありますか？   櫻井 ：開発プロジェクトでチームリーダーをした経験が一番役に立っていると思います。 プロジェクトでは、予想外の要求変更や厄介な不具合などさまざまな問題が発生しますが、 それらを課題として管理し優先順位をつけて取り組んで来た経験はBIGLOBEでも活かせていると感じます。   座間 ：僕の場合は、業務システムへの知見とWebアプリケーションフレームワークの知識ですね。SIer時代は工期が短めのレガシーシステムリニューアル案件を多数やっていたのでさまざまなWebアプリのソースコードに関わることができました。 リニューアルということもあって、アプリを一から作り直す作業を経験しているのでフレームワークへの理解とアプリケーション設計についてもある程度学べていました。 多種多様なシステムに関われるのはSIerの強みかなと思いますね。こういった経験はBIGLOBEでの内製開発においてもアプリ設計する際に役立っています。   開発環境について   ────　ところで、どんな環境で開発しているのですか？メインのプログラミング言語も教えてください。 櫻井 ：チームメンバーが使える言語ということもあって、JavaがメインでGitHub上でやり取りしています。   座間 ：BIGLOBEはDDDの手法をとっているので、型が付けられる言語がメインになっています。「型付き言語」といって、「このプログラムはこういう風にしか呼び出せないよ」という厳しいルールをつける言語です。型がない言語だと、プログラムの呼び出し方がいろいろあって汎用性な分、バグになりやすいという問題があるので、型が付けられる言語をメイン言語としています。 一方「この技術でやりたいんだ」と説得力をもって言えるなら、好きな技術が選べます。実際、AWSへ移行するときに、1つの大きなサービスを小さなサブシステムに分けるマイクロサービスアーキテクチャを採用しつつ、サーバーの管理が不要になるサーバーレスを利用していろんなプログラミング言語で実装してみました。それを保守していくには責任が伴いますし、採用した言語をチーム全員が使えるようにする必要があります。技術者の裁量が大きいのは素晴らしいことですが、高いスキルが要求されるので、成長意欲のあるエンジニアじゃないとかなり辛いかもしれないですね。 環境面では、ほとんどのエンジニアがMacで開発していて、現在は在宅勤務励行中のため、ほぼリモートワークです。 ────　どんな資格や知識を持っているといいですか？ 座間 ：言語の資格を持っているかは関係ないと思います。どちらかといえば、どんなプログラムを書いているかが重要です。 資格をということであれば、AWSの資格を持っているといいと思います。我々も入社してからAWSの資格をとりました。   成長とやりがい   ────　入社後、成長できたところはどんなところだと思いますか？ 櫻井 ：DDDのモデリングはかなり上達しました。また入社後1年程、1つのシステムのAWS移行を任せてもらい、これまで使ったことのなかったAWSのサービスをいろいろ使うこともできました。先ほど座間さんが言っていたように、AWS認定ソリューションアーキテクトアソシエイトの資格も取得できたので、AWSの知識はかなりついたかなと思います。   座間 ：僕もDDDですね。保守性の高いシステムをどう作るかを1年かけてみっちりチームのみんなと取り組んで、考え方を身につけられました。 あと、今メインで触っているシステムはすぐ隣にいる社内の運用チーム向けの業務システムなので、SIerだった時とは比べ物にならないくらい短いスパンで要件定義や要求分析を繰り返しています。そのやり取りを通じてお客様視点での開発もスキルアップしたと思います。   ────　モチベーションを感じたエピソードを教えてください。 座間 ：まさに今がそうです。Adobe Flash Playerのサポートが2020年12月末に終了したので、Flash Playerで動いていたシステムを全面リニューアルしたんです。その時に、既存のシステムよりも、より使いやすい新しい画面を作ろうということで取り組んでいき、この1月にリリースしました。運用チームから「ここが良くなった」「ここはさらに改善していきたい」などいろいろ意見をもらえることが、モチベーションの高まるポイントでした。もっと良くしていこう！という目標にもつながります。 櫻井 ：リリースしてお客様から反応がもらえるのはモチベーションあがりますよね。僕は、最初に担当したシステムの運用も任されていたので、ちゃんと安定稼働しているのを見られた時はやりがいに感じました。   今後について ────　どんなキャリアプランを描いていますか？ 櫻井 ：AWSのスキルをさらに磨いていき、将来的にはチームを超えてシステム全体を見られるアーキテクトのようなポジションにいけたらと思います。   座間 ：キャリアは明確には描けていませんが、全社的な課題を解決したいという想いがあります。意見を言いやすい雰囲気はあるものの、全社で取り組む新規サービスの話になるとまだまだトップダウンで決まることが多く、その際、見積もりや計画が不安定だと開発にしわ寄せがあり、かなり厳しい納期になったりもします。そのような組織全体のマネジメント的な課題を解決したいというビジョンは考えています。   櫻井 ：立派です！そうですね、トップダウンもありますね。組織全体の課題もあると思いますが、部下が上司に信頼されるように、スキルの底上げをしていきたいですね。 ────　エンジニアから見て、今後のBIGLOBEはどうあるべきだと思いますか？ 櫻井 ：BIGLOBEはよく言えば歴史がある、悪く言うとレガシーな仕組みが残ってしまっていて、人の手で何とかしています。2025年の崖で話題になったレガシーなシステムがまだまだあるので、その改善を加速していかなければなりません（ 2025年の崖に備えて ）。お客様に喜んでいただけるサービスを迅速にお届けできるよう、柔軟に改善していける良いシステムにしていかないと、と思っています。 座間 ：おっしゃる通りですね。ビジネス職の社員は、お客様に喜んでいただける新しいサービスを早く提供したいという想いがあります。 「価値の提供」という意味では、我々エンジニアは、自動化すべきものはどんどん自動化して、なるべく人の手を動かさずに、スピーディにサービスを提供できるシステムを作ることが使命です。それを達成するにはスキルアップし続けることに加えて、エンジニア自身がお客様視点に立つことがとても重要だと思っています。 気をつけていないと技術の新しさや面白さにばかり目がいってしまうのがエンジニアですが、ビジネス職とチームになってお客様の価値を追求できるエンジニアになっていきたいな、と思います。 最後までお読みいただきありがとうございました。 DDDやAWSが売りの当部門では中途採用を行っています。 より良いモデリングに興味があり、開発の現場でバリバリコードを書きたいという方、是非BIGLOBEで一緒に取り組んでみませんか？興味のある方はこちらをご覧ください。 （2022年2月追記：本募集は終了しました。） hrmos.co   ※ Adobe、Adobe Flash Playerは、Adobe Systems Incorporated（アドビシステムズ社）の米国およびその他の国における商標または登録商標です。 ※ Amazon Web Services、AWSロゴおよびかかる資料で使用されるその他のAWS商標は、米国その他諸国における、Amazon.com, Inc.またはその関連会社の商標です。 ※ Googleは、Google LLCの商標です。

基盤本部（開発部門）の小野田です。 私は 2019 年に中途採用で BIGLOBE に入社して以来、主に既存システムのリニューアル案件に関わり、その中で、モデリングの経験を多く積んできました。本記事では業務で得たモデリングの知見を基に 鉄道料金計算問題 を再モデリングした結果と 1 年前のモデリング結果とを比較して、1 年間でどれだけスキルアップしたかを紹介したいと思います。ここで紹介する内容は、同じ名前のオブジェクトでも性質が異なれば別の値オブジェクト ( V alue O bject: VO ) としてモデリングしたほうが良いことを示す実例となります。 1 年前のモデリング結果は DDD くらいできるようになりたいよねって話 をご覧ください。 style.biglobe.co.jp なお、この記事の内容やプログラムは教育用に作成した架空のものであり、実在のサービスや団体などとは一切関係ありません。 想定読者 システム構成 スキルアップした点 業務知識を反映したモデルを作成する 3 者の比較 業務知識が反映されていないモデル 業務知識を反映したモデル 業務知識を型で表現するメリット コンテキストの境界を意識してモデルを作成する 2 者の比較 別々の道を歩む コンテキストの境界を意識してモデルを作成するメリット 品質の高い単体テストを作成する 担保するロジック単位で単体テストを作成するメリット まとめ 参考図書 想定読者 本記事は以下のような方を読者として想定しています。 ドメイン駆動設計 ( D omain D riven D esign: DDD ) に興味がある方 BIGLOBE への入社に興味がある方 記事の途中でマイクロサービスに関する話題も出ますが、本記事はあくまで DDD のモデリングや実装に関する話題が主であり、マイクロサービスに関する技術的な話はしません。 システム構成 今回のモデルは下図に示す通り 5 つのマイクロサービスで構成されます ( 右端の catalogue-db は DB なので、マイクロサービスにカウントしていません ) 。各マイクロサービスの責務については GitHub リポジトリ をご覧ください。 システム構成 実を言うと元々はマイクロサービスに興味があり、鉄道料金計算問題を学習用のマイクロサービスとして作ったところ、モデリング結果が 1 年前と大きく変わったので、その知見を記事としてまとめることになりました。 スキルアップした点 本記事ではスキルアップした点として、以下の 3 点を紹介します。 業務知識を反映したモデルを作成できるようになった コンテキストの境界を意識してモデルを作成できるようになった 品質の高い単体テストを作成できるようになった それでは以下で詳細を説明したいと思います。 なお、以降では 1 年前のモデリング・実装結果を Before 、今回のモデリング・実装結果を After と呼びます。 業務知識を反映したモデルを作成する 鉄道料金計算問題において、「大人 1 人が 12/25 に東京から新大阪まで、ひかり ( 指定席 ) で片道移動する」場合の特急料金は 5690 円 です。これは以下の流れで計算できます。 特急料金計算の流れ さて、私たちは「特急料金はいくらですか？」と質問されると上記計算の 3 で得られた 5690 円を回答しますが、では、1, 2 の計算結果である 5490 円と 5690 円は何者でしょうか？ 3 者の比較 3 者は 同じ / 別の ものなのかをはっきりさせるために以下の観点で比較をしてみましょう。 No 季節による変動料金を調整できるか？ 団体割引を適用できるか？ 1 Yes No 2 No Yes 3 No No 季節による変動料金の調整は 1 度のみなので 2, 3 に対して 200 円を加算することは許されません。同じ理由で 3 に対して団体割引を適用することは許されません。 また、季節による変動料金の調整と団体割引を適用する順序を入れ替えると最終的に得られる金額が変更になるため、1 に団体割引を適用することは許されません。 この比較結果から 3 者は許可される操作が異なるため 別者である ことがわかります。 業務知識が反映されていないモデル Before では 1, 2, 3 は全て同じもの ( 特急料金 ) としてモデリング・実装して、以下のような VO を作りました。言語は Kotlin です。 data class SuperExpressSurcharge( private val value: Int ) { fun variedBySeason(season: Season) = SuperExpressSurcharge(value + season.value) fun forChild() = value / 2 fun forAdult() = value fun discounted(discountRate: DiscountRate): SuperExpressSurcharge { val discountedValue = value - (value * discountRate.value / 100 ) return SuperExpressSurcharge((discountedValue / 10 ) * 10 ) } } ご覧の通りこの VO は 季節による変動料金を n 回調整することができる ( n は 0 以上の整数 ) 団体割引を n 回適用することができる ( n は 0 以上の整数 ) 季節による変動料金の調整と団体割引を適用する順序を制御できない という点で業務知識を反映できていません。実装者が業務ルールを把握した上で、適切に実装をする必要があります。 業務知識を反映したモデル After のモデルでは 1, 2, 3 の料金をそれぞれ以下のように別々の VO としてモデリングしました。 No クラス名 1 季節変動料金調整前の指定席特急料金 2 割引適用前の指定席特急料金 3 特急料金 季節変動料金調整前の指定席特急料金 を 割引適用前の指定席特急料金 の factory にすることで、Before のモデルでは表現できていなかった業務知識を表現できるようになりました。 このように VO をたくさん作ると「後で見返した時や途中から参加したメンバが各 VO の違いを把握できず、かえって混乱するのでは？」という意見もあるかと思います。本プロジェクトではこの問題を解決するため、ドメイン層にあるクラスには簡易的な Javadoc コメントを付けてあります。 業務知識を型で表現するメリット After のようなモデルにすることで以下のメリットが得られ、結果として堅牢なサービスを開発することができるようになります。 計算ミスが起こらない 割引回数や計算フローが型レベルで制限されるため、計算ミスが起こらなくなります 「いやいや自分はそんな凡ミスしないから」と思っていても、疲れなどでうっかりミスをしてしまうことは誰の身にも起こり得ます ( 実は私も同じようなミスをしてレビュー指摘された経験があります ) コードレビューの質が上がる 割引回数や計算フローは型で制御されているため設計の良し悪しなど、他の観点にレビューの時間を割くことができるようになります コンテキストの境界を意識してモデルを作成する 特急料金の計算に焦点を当てると、下図のようなコンテキストマップを描くことができます。 コンテキストマップ ご覧の通り目的地や列車区分、座席区分や乗客など、同じ名前の VO が複数コンテキストに存在しますが、これら同名の VO は共通化 すべき / すべきではない のどちらでしょうか？ ここでは赤枠で囲んだ乗客 ( Passenger ) を例に、共通化すべきか否かの判断基準を示したいと思います。 2 者の比較 各コンテキストにおける Passenger の位置付けを整理すると以下のようになります。 料金計算コンテキスト Passenger は料金を計算する際に必要な情報であり、 子供料金 x 子供の乗客数 や 大人料金 x 大人の乗客数 のような形で利用する 誤って 子供料金 x 大人の乗客数 や 大人料金 x 子供の乗客数 のような計算ミスをしないように型で制御したい 特急料金コンテキスト Passenger は割引コンテキストに渡す情報であり、特急料金コンテキストでは使用しない したがって 子供の乗客数 と 大人の乗客数 を型で区別する必要はない この比較結果から 2 者は性質が異なるため 別者である ことがわかります。 別々の道を歩む 今回は上記理由から 2 者は別者であり共通化しない戦略を取りました。最終的に出来上がった 2 者の差分は以下の通りです。言語は Java です。 赤でハイライトした行が特急料金計算コンテキストでの Passenger で、緑でハイライトした行が料金計算コンテキストでの Passenger です。 public class Passenger { - @Getter private final int children; - @Getter private final int adults; + @Getter private final Children children; + @Getter private final Adults adults; + + public ChargedPassenger exclude(ComplimentaryPassenger complimentaryPassenger) { + return new ChargedPassenger( + children.minus(complimentaryPassenger.getChildren()), + adults.minus(complimentaryPassenger.getAdults())); + } } Before のように共通化する戦略をとった場合、無料になる乗客 ( ComplimentaryPassenger ) や 課金対象の乗客 ( ChargedPassenger ) のような特急料金計算コンテキストに不要な概念が入り込み、コンテキスト間の依存関係が強くなってしまいます。 コンテキストの境界を意識してモデルを作成するメリット After のようなモデルにするメリットは「コンテキスト間の依存度を低く保つことで変化に強くなること」です。 1 年経って大きくモデルが変わったように、今後もモデルが変更になる可能性は大いにあります。その際コンテキスト間の依存度が高いと変更範囲が広くなり、モデルの変更は大変な作業になりますが、After のように依存度を下げることで容易にモデルを変更できるようになります。 品質の高い単体テストを作成する 皆さんは単体テストをどの粒度で作成しますか？ 料金計算などミスが許されないロジックは単体テストを書くとか、カバレッジが 100% になるように単体テストを書くとか、様々な考え方があるかと思います。 Before では以下の方針で単体テストを書きました。 ドメイン層のみ単体テストを書く 料金計算の単体テストを書くことで運賃や特急料金を計算するロジックも実行されるため、運賃や特急料金を計算するロジック自体の単体テストは書かない その結果 Before の単体テストは 料金計算ドメインサービス しか書いていません。 一方 After は以下の方針で単体テストを書きました。 ドメイン層のみ単体テストを書く ロジックの妥当性を担保すべき単位で単体テストを書く 例えば 料金計算ドメインサービス の単体テストを書くとそこで使われている運賃や特急料金などの VO のロジックも実行されますが、運賃に特急料金を加算したら適切な金額を持った料金を算出することは運賃が担保すべき責務であるため、運賃の単体テストも書く その結果 After では ご覧の通り ドメインサービスの他、VO の単体テストも書きました。 担保するロジック単位で単体テストを作成するメリット テストが失敗した時に失敗個所を特定しやすくなる 各クラスの責務が明確になる まとめ BIGLOBE で 1 年間 DDD の実務経験を積んだ結果、業務知識を反映した深いモデルや質の高い単体テストを作成するスキルが身につきました。本記事で紹介したスキルの他にも AWS 認定ソリューションアーキテクトアソシエイトの資格を取得するなど、エンジニアとして大きく成長できたと感じています。 最後に、本記事では触れませんでしたが冒頭で述べた通り、元々は学習用のマイクロサービスを作成する目的で鉄道料金計算問題をマイクローサービス化しました。学習用のサービスが完成したので今後は 各サービスを別々の言語で実装して Polyglot 構成にする Apache Kafka のような分散メッセージキューを使って非同期型のシステム構成にする Zipkin のような分散トレーシングシステムを導入してシステムのトレーサビリティを向上させる などを試し、マイクロサービスに関する知見をためていきたいと考えています。 参考図書 エリック・エヴァンスのドメイン駆動設計 実践ドメイン駆動設計 ※ Amazon Web Services、AWSロゴおよびかかる資料で使用されるその他のAWS商標は、米国その他諸国における、Amazon.com, Inc.またはその関連会社の商標です。

開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 基盤本部では2020年度から新人エンジニア向けの研修を実施しています。テクニカルスキルについては、インターネットで公開されているコンテンツを活用しているのが特徴です。決して手を抜いているわけではないですよ！ちゃんとした狙いもあります💪どのコンテンツもすぐに試せるものばかりです。ITエンジニアとしてさらにスキルアップしたい方や、リモート環境での研修に困っている教育担当者のお役に立てば幸いです。 新人エンジニアに好評だった研修と利用したコンテンツ テスト駆動開発（Test Driven Development：TDD） GitHub、Markdown UNIXコマンド、UNIX哲学 リーダブルコード インターネットで公開されているコンテンツを使った学習のメリット 新人エンジニアに好評だった研修と利用したコンテンツ テクニカルスキルを学ぶ順序を次のように定めました。チーム開発演習に必要になるスキルを段階的に学んでいきます。 図1 テクニカルスキルの学習パス インターネットで公開されているコンテンツを使った研修のうち、新人の印象に強く残った順にご紹介していきます！ テスト駆動開発（Test Driven Development：TDD） TDDは、ペアプログラミング・モブプログラミングを実践するために必要なプラクティスです。タスクばらしとリーダブルコードを学んだ後に学びます。 id:t-wada さんがYouTubeに公開されている動画でTDDのポイントを学びました。 TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング 新人「学生の頃はテストを書く機会がありませんでした。この動画のおかげで、そのメリットを良く理解できました。後に続く人の負担を減らせることは、とても大事だと思います。動画を見ながら手元でプログラミングをして、より理解を深めることができました」 スクリーンキャストは見ているだけでも手を動かしたのと同様の効果が得られることがありますが、ここまで分かりやすいものはなかなかありません。質の高いコンテンツを公開してくださっていることに感謝です！ 動画をただ見ているだけでは受け身になってしまうので、Googleフォームのテスト機能を使って理解度クイズも準備しました。理解度クイズでは、TDDの誤解されやすい点について質問しています。どなたでも試せますので、腕試しにぜひどうぞ！ forms.gle GitHub、Markdown Gitについて学ぶ前に、GitHubを使ったプルリクエスト（Pull Request：PR）を体験することで、Gitがチーム開発でどう使われるようになるかを先に理解してもらいます。 この研修では GitHub Learning Lab GitHub Skills で 1 Markdownの書き方や、PRの作り方・取り込み方を学びました。GitHubアカウントとWebブラウザーさえあれば、手を動かしながら学べる素晴らしい教育コンテンツです。 skills.github.com 新人「研修でPRの作り方を学んだ後、早速、とあるオープンソースプロジェクトにPRを出してみました。typoを直すだけの簡単なPRだったのですが、それが取り込まれて、プロジェクトの貢献者として名前が表示されたときは本当に嬉しかったです。その後も、ちょくちょくPRを出しています」 GitはTDDと同様に、学生時代に学ぶ機会の少ない技術のようです。使い方が分かった途端、オープンソースに貢献してしまう行動力にビックリしました！ UNIXコマンド、UNIX哲学 Gitを学ぶ前に、Linux標準教科書（ https://linuc.org/textbooks/linux/ ）※1 を使って基本的なコマンドについて体系的に学びました。教科書と聞くと堅いイメージを持ちますが、Linux標準教科書は「手を動かしながら学べる」点が優れています。実際にコマンドを打ちながら読み進められますし、章末テストで理解度を確認することもできます。 ※1 Linux標準教科書の著作権は特定非営利活動法人エルピーアイジャパンに帰属します。 linuc.org 新人「受講した時は、catコマンドを見て「え？猫？」という状態だったので、基本的なコマンドやUNIXの設計思想まで学べたことはとても良かったです。早速、業務でコマンドを打つことがありとてもドキドキしたのですが、Linux標準教科書を見返したおかげで臆することなく作業できました。もっと慣れたいので2周目に入りました」 Linux標準教科書のおかげで、手を動かしながら本を読む「写経」のやり方を学ぶこともできました。自分のペースで何度でも繰り返せるのは素晴らしい利点です。 リーダブルコード 最後は、コンテンツそのものではなく、無料で公開されている学び方のご紹介です。 TDDを使ってコーディングをはじめる前に、書籍「 リーダブルコード 」を購入して新人に配り、良いソースコードについての共通認識を深めました。 BIGLOBEでは必要な技術書は会社で購入できます。技術書はとてもコストパフォーマンスの高い教育コンテンツです。 ただ、人によって本を読む力にはバラつきがあるため、まずは読書に慣れることが大事になります。そこで、技術書が好きになり、最後まで読み切れるようになることを目指して、アクティブ・ブック・ダイアローグ（Active Book Dialogue：ABD）※2 を使った読書会を開催しました。 ※2 「アクティブ・ブック・ダイアローグ」は開発者・協会代表理事 竹ノ内壮太郎氏の登録商標です。 ABDではチームで一冊の本を読みます。まずメンバーに読む箇所を割り当てます。メンバーは読んだ内容についてサマリーを作り、お互いに共有します。そして、全てのサマリーを共有した後で、もう一度サマリーを眺めながら議論をするのですが、結果的に「その本を全部読んでみたい」という意欲が高まります。 何より楽しい！のも特徴です。詳しいやり方は、アクティブ・ブック・ダイアローグ協会が無料で公開しているマニュアルをご覧ください。とても分かりやすいです。 www.abd-abd.com 新人「チームで開発をする上で、良いコードとはリーダブルなコードであることを良く理解できました。ABDでは、自分が読んだ内容を他の人に説明するのですが、人に説明することで知識が整理されました。他の章の概要も効率良く理解でき、むしろ全部読み直してみたくなりました」 ABDはチームが活性化する素晴らしい読書体験を与えてくれますが、参加者の持っている知識や使う技術書によっては向き・不向きがあると感じています。他の本でABDを試したときには、分担する量を多めにし、かつ、内容が難解だったため、上手くサマリーを作れずに議論が盛り上がらない、という失敗をしました。 その点、リーダブルコードは章ごとの文章量が少なく、分かりやすい内容のためABDに向いています。リーダブルコードでのABDが上手くいったので、現在は書籍「 Webを支える技術 」を使ってHTTP、REST、HTMLについて学んでいます。 インターネットで公開されているコンテンツを使った学習のメリット 基盤本部にはインフラエンジニアと開発エンジニアが所属しています。それぞれのエンジニアが共通して身につけるべきスキルを、文末のコラムのように定義しています。 必要なスキルを定義しているのは、学習の目安を作るためです。世の中には情報があふれかえっていて、目安がないと何を学べばよいか迷子になってしまいます。組織として研修を設計する時は、何を研修のゴールとするのかを決めるところで時間がかかるのが普通ですが、BIGLOBEではそれをスキルとして事前に定義していたおかげで、スムーズにカリキュラム設計に移ることができました。 ただ、この研修で学び取って欲しいことは、スキル以上のものに設定しています。それは「セルフラーニングができるようになること」です。ITエンジニアでい続けるためには、常に学び続けることが求められます。「魚を与えるのではなく、魚の釣り方を教える」ために、手取り足取り教えるよりも、自分たちで興味を持って学んでもらうことを意識しています。様々な学習コンテンツに触れてもらうのもその一環です。「学ぶことは楽しい」「学ぶことはハードルが低い」ことを伝えようとしています。 インターネットで公開されているコンテンツを使った学習は、学習者にとって次のようなメリットがあります。 自分のペースで進められる リモートでの研修は、思いのほか疲れるものです。好きな時に休憩が取れるのは大きなメリットになります。 復習できる 学んだことを実際の業務で活かすタイミングは、人によって違います。 ただ、一度学んでおけば頭の中に「ひっかかり」が残ります。インターネットで公開されているコンテンツであれば、本当に必要になったタイミングで学び直すことができます。 様々な学び方があることに気がつける 人によって適した学び方はそれぞれ違います。しかし、自分が教える側にまわってみると、自分が教わった通りに教えてしまうものです。インターネットには本当に様々な教育コンテンツがあふれています。それらを楽しみながら渡り歩くことで、学ぶ側も、教える側も、様々な学び方があることに気がつけるようになります。 つまり、インターネットのコンテンツを使って学習するメリットは、インターネットそのもののメリットと同じです。すなわち、好きな時に好きなだけ好きなコンテンツを使うこと（学び直すこと）ができる点にあります。 研修を作る側にとっては、コンテンツ作りをサボれるのがメリットです。ただし、会社の研修で使うには地味な準備が必要です。個人利用は無料であっても、商用利用を禁じている場合があるので、利用規約の確認や問合せや、場合によっては契約も必要になります。また動画を見るだけの受け身の研修にしてしまえば、研修を作る側にとっては楽であっても、学習者にとっては張り合いがありません。そこで、TDDやUNIXコマンドの研修のように理解度クイズを準備する、といった工夫も必要です。 この記事でご紹介したコンテンツは社内研修で利用できるかどうか確認をしたものばかりです。素晴らしいコンテンツを提供してくださった皆さんには感謝の思いでいっぱいです。本当にありがとうございます。 コロナ禍という未だかつてない状況の中でも、オンラインで新人研修を継続できているのはインターネットがあるおかげです。 「インターネットは、すごい！」とあらためて感じています。そして、このインターネットをお客様に提供できることは、私たちの誇りです。 私たちと一緒にインターネットで社会を支えていきたいエンジニアを大募集していますので、もしよろしければ採用情報をご覧になっていってください。 hrmos.co 新卒エンジニア職も大募集しています！ www.biglobe.co.jp コラム 「BIGLOBEのスキル定義」 BIGLOBEでは、全社員が備えるべき「パーソナルスキル」と職務ごとに必要となる「テクニカルスキル」をそれぞれ定義しています。 パーソナルスキル（全社共通） 職種に関係なく、ビジネス遂行に必要な能力・スキル テクニカルスキル（部門ごとに定義） 業務遂行に必要な知識・スキル 基盤本部はBIGLOBE全社を支える技術開発部門です。基盤本部では、身につけるべきスキルや、目指すべきキャリアパスを明らかにすることが目的として、テクニカルスキルを3つに分けて定義しています。 インフラ領域のスキル ネットワーク、アプリケーション、サーバー・クラウド、ファシリティ、 アーキテクトの5つの専門領域ごとに、必要なスキルを定義 情報システム領域のスキル ITストラテジスト、ITアーキテクト、プロジェクトマネージャー、業務設計スペシャリスト、ソフトウェアデベロッパー、ITスペシャリスト、ITサービスマネージャー、ITガバナンスマネージャー、データサイエンティストの9つのロールごとに、必要なスキルを定義 共通スキル 上記の2領域に共通するスキルを定義 共通スキルはさらに、共通ビジネススキルと、共通テクニカルスキルに分かれます。いずれも、基礎的なスキルを身につけます。 共通ビジネススキル ★ロジカルシンキング ★事業戦略、ビジネスモデル、マーケティング コミュニケーション、ドキュメンテーション、英語 共通テクニカルスキル ★情報収集・発信 ★プログラミング・自動化 ★統計・データ分析・機械学習 ★品質、セキュリティ 要件定義、システム設計・評価、運用・監視設計 コスト管理、設備管理 プロジェクトマネジメント 新人エンジニア向け研修では、星印★をつけたスキルについて学びます。 ※ Amazon Web Services、AWSロゴおよびかかる資料で使用されるその他のAWS商標は、米国その他諸国における、Amazon.com, Inc.またはその関連会社の商標です。 ※ GitHub は、GitHub Inc.の商標または登録商標です。 ※ Googleは、Google Inc. の商標または登録商標です。 GitHub Learning Labは2022年9月に終了 しました。後継としてGitHub Skillsが使えます。 ↩

　こんにちは。BIGLOBE猪俣です。 BIGLOBEモバイルをはじめ、ネットワークの企画・開発を担当しています。 今回は商用化に成功した仮想化ネットワークの取り組みについてお話ししたいと思います。 2020/11/18プレスリリース www.biglobe.co.jp ネットワークの仮想化とは 仮想化のメリットとは 品質が重要 まとめ ネットワークの仮想化とは 　突然ですが、”仮想化ネットワーク”って聞いてどんなことを想像しますか？ VPN、VLANは馴染みのある方も多いのではないでしょうか。 頭に”Virtual”が付くので仮想のネットワークを意味しますが、BIGLOBEが創るモバイルネットワークの仮想化は違います。 　皆さまが普段お使いになられるスマホのネットワークの裏側では沢山のネットワーク機能が働いています。 これらが密接に連携しあって”どこでも安定してインターネットに繋がる”を実現しているのです。 　具体的に言うと１０種類ぐらいのネットワーク機能や制御システムの集合体なのですが、 従来はそれぞれの特性に応じたメーカー専用のハードウェアで構成していました。 今回お話しするモバイルネットワークの仮想化はこれら機能やシステムを汎用のハードウェア上の仮想マシンとして構成することです。 仮想化のメリットとは 　では、専用のハードウェアではなく汎用のハードウェアで動かすことでどんなメリットがあるのでしょうか？ 　一つは部品を共通化することで得られるコストダウンが挙げられます。 しかしながら、こちらのメリットを享受するには相当の規模があることが求められます。 大手の通信キャリアではとても有効ですが我々の様なMVNO事業者にはすこし厳しい目標です。 　では何故BIGLOBEが仮想化に取り組むのか？ ①故障が発生した時に簡単にコピー（移動）で復旧させることができ、 データセンターに駆けつけてハードウェアの交換作業が不要になること。 ②新しい機能を追加する時にハードウェアの工事が不要になることでスピーディにサービス提供ができること。 ③仮想化×ネットワークスライスで構成し、スライス選択機能（※図中SSF:Slice Selection Function）でニーズに合わせた適切最適なネットワークにルーティングできること。 　特に③のスライス選択はもともと5Gでの要素技術なのですがBIGLOBEではこれを応用し、4G LTEのMVNOモバイルコアネットワークに適用することに成功しました。 お客様のニーズに合わせて最適な構成のネットワークを選択できることが特徴です。将来的に新たなサービスを追加する場合はソフトウェアの更新で実現したり、増設時はスライスで標準化した設計でコピーして増やすことが可能になりました。サービスを提供しながら必要な変更をネットワーク全体に影響することなく素早く、柔軟に行えることがメリットです。 装置（ソフトウェア）の不具合や障害が発生した場合に影響範囲を極小化できることもポイントです。 　BIGLOBEモバイルでは エンタメフリー・オプション をはじめ様々なサービスをご提供していますが、少人数でも工夫を凝らしてバリエーション豊富なサービスをご提供するためにこれらの仮想化やスライシング技術導入に積極的に挑戦しています。 品質が重要 　仮想化をどの様に実現しているのか少し具体的にお話しします。 最近のインテルx86（Xeonプロセッサ）ベースの汎用サーバはCPUコア数が飛躍的に増え、 また、ネットワークカード（NIC）のパケット処理性能も大幅に向上してきました。 加えて、これまでメーカー各社が専用機で提供してきたネットワーク機能について多機能化や開発効率化のためソフトウェア化が進んでおり、中にはLinuxで動いている機種も多く存在します。 　この様な背景でネットワーク機能を汎用サーバ上で遜色なく動かすことが比較的簡単になってきました。ただし、動くことだけでは安定した品質でご提供できるわけではありません。通信品質や性能を引き出すために様々な工夫をしています。 例えば故障に備えて構成を徹底的に冗長化をしています。 CPU、メモリ NIC、スイッチ ディスク 電源 ラック 回線、ケーブル などなど 　また、故障した時に予備のサーバへコピー（移動）で復旧させるために、 どのサーバに移動しても一様に機能・性能を確保するため、すべてのサーバーを共通な設計にしています。 　ちなみに、故障時にコピーや移動を行う動作をヒーリングと呼び、一部では自動でヒーリング操作が行われる様に設定しています（オートヒーリング）。 まとめ 　今日ではネットは空気のように身近な存在になりました。 インターネットに繋がるワクワクを味わえたのも過去のものです。 長年ISPとしてインターネットを支えてきたBIGLOBEですが、 ネットが当たり前の世界で、いつでもどこでもネットを楽しめていること、 これらを支える通信インフラをこれからも安定して運営していくのがBIGLOBEの使命です。 　余談になりますがここ数年で無線機（無線基地局）の仮想化について標準化の議論が進んできました（OpenRAN/O-RAN等）。既存の周波数や基地局設備を持たない新興キャリアなどは積極的に採用している動きもあります。 　近所の電柱やビルの屋上に設置される基地局の中身がサーバーに置き換わるのも目前です。我々の間近(エッジ)でコンピューティングリソースが広く利用可能になると、今までできなかったサービスが実現する可能性を秘めています。5Gと合わせてMEC(Multi-access Edge Computing)から目が離せません。 　今後も新しい技術に積極的に取り組んでワクワクするサービスを作っていきますのでご期待ください。 hrmos.co ※記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは。梅津です。BIGLOBEでインフラエンジニアをしています。 入社から3年半は法人向けサービスの部門でセールスエンジニアとしてBtoBの業務をしていました。そこから開発部門に異動して、サーバ運用管理業務を主として、ロードバランサの管理や色々なハードに触れる業務をしました。 現在はというと、2年前からBIGLOBEのAmazon Web Services （AWS）推進チームの一員となり、以下のような業務をしています。 ・社内AWSガイドラインの作成 ・AWS環境構築のサポート ・AWSのコスト管理と改善 ・物理サーバの運用管理 今回は、BIGLOBEの恵まれた学習環境の中でインフラエンジニアの私がどう学び、BIGLOBEのサービスを支えることに活かしているかをご紹介します。   サービス担当者に自らインフラを構築してもらうことでビジネスを加速 地味なAWSガイドライン作りでビジネスに貢献 手を動かしながら学び、学びを共有するBIGLOBEの文化 新鮮な情報も、深い情報もすぐに得られる恵まれた環境   サービス担当者に自らインフラを構築してもらうことでビジネスを加速   私の主な業務はAWSの環境構築をしているサービス担当者をサポートすることです。 BIGLOBEでは2018年からAWSを本格的に利用しはじめ、2019年下期からはエンジニアだけではなくビジネス職であるサービス担当者にもインフラ環境を直接触ってもらっています。 初めてインフラやAWSという環境に触れる人も多く、 そういったサービス担当者にAWSをうまく使いこなしてもらうために、この人は何に困っているのか細かくヒアリングして、疑問点や問題点をなくせるようにかみ砕いて説明することを心がけています。なお、サービス担当者の皆さんが今後は自分自身でAWSを工夫して使えるようになってほしいので、手取り足取り教えることはせずに手順を説明した後は自分で操作してもらうようにしています。 疑問点や問題点で行き詰まってしまって解決できなかったものを迅速にサポートすると皆さんに喜んでもらえますし、実際にサービスがうまく動いているのを見るのはとても嬉しいです。 似た問題が起こったときに「これでやればいいんですよね？」とか「前回教えてもらったのでもう設定しました！」とサービス担当者が自分で解決していく様子を見ると役に立てた嬉しさに加え、BIGLOBEのAWS利用の推進が一時のものではなく、今後も継続していくことに貢献できたという手ごたえを感じます。 このように相手の立場に立つということは、入社してから3年半BtoB事業の現場で法人のお客様と接して、お客様の問題を解決していた経験が活かせているのだと思っています。   地味なAWSガイドライン作りでビジネスに貢献   また、私はAWS利用のための社内ガイドラインを作成しています。AWSでは自由自在にインフラを構築することができますが、一定の制約を設けることでより頑健で安全なインフラにすることができます。この制約をガイドラインとしてまとめる大切な仕事です。 出来上がったガイドラインは社内の多くの人に参照されますが、ガイドライン自体を作る活動は表には出ない地味な活動です。ですが、私はBIGLOBEのAWS利用を推進するために最も重要なものだと思って取り組んでいます。また、この活動を通じて自分が大きく成長できていると実感もしています。 AWSでは既存の機能が常にアップデートされるだけでなく、新しいサービスもすごいスピードで追加されています。そのスピードにサービス担当者がついていくのはとても大変です。そこで、私はサービス担当者が最新情報をキャッチアップできるよう、先回りしてガイドラインをアップデートし、最新技術の恩恵をサービス担当者が受けられるようにしています。 ガイドラインに最新情報を反映する際には、自分で実際に操作をしてみることで、利用する人がつまづく点を明らかにしています。実際に触れて、操作をして、サービスについて自分の知識を深める。深めた知識によって、先ほど述べたサービス担当者への支援も、より実効的なものになっていると実感しています。 この取り組みの結果は数字にも表れています。サービス担当者から質問される数は2020年4月に比べるとぐっと減ってきている一方、サービス担当者によって構築されたサービスの月間PV数やUU数は毎月堅実に伸びているのです。見えないところでの活動ですが、BIGLOBEのAWS利用の底上げに役立っているな！と思っています。   手を動かしながら学び、学びを共有するBIGLOBEの文化   まだ私もAWSに触れるようになってから日が浅いので、1日1回はAWSのコンソールを触って何かを試すようにしています。試しているのは、セミナーなどで紹介されたサービスや自分が興味のあるサービスです。 こうしたAWSの機能を自由に操作できる環境をPoC環境と呼んでいます。Proof of Concept、コンセプトやアイデアを実際に手を動かしながら検証する環境、の意味です。 そ んな環境を利用できるのは私がAWS推進チームの一員だからと思われるかもしれませんが、サービス担当者にもPoC環境を提供しています。 自分のAWSアカウントを使うとお金が心配だなと思って大胆なことはできませんが、会社が利用料を支払ってくれるので安心です。さらにセキュリティ事故が発生しないような工夫もしてあります。 また、ここTechBlogで紹介した通り、AWSに慣れていない人たち向けのハンズオンも定期的に開催しています。   style.biglobe.co.jp   座学に加えて実際に操作することで知識の吸収は何倍も速くなるので、より多くの人にハンズオンを受講してもらおうと準備しています。ハンズオンの内容はAWS社から提供されたものをベースに、AWS推進チームがガイドラインに沿った形に仕上げています。 こうして手を動かして学んだことを、月1回の勉強会で社内に共有しています。この勉強会では、新しく学んだことだけでなく、開発を通じて得られた知見も発表してもらっています。   新鮮な情報も、深い情報もすぐに得られる恵まれた環境   AWSに関わる人にとって1つの憧れは、AWS世界最大のイベント「re:Invent」に参加することではないでしょうか？BIGLOBEはこのビッグイベントに3年連続で参加しています。かくいう私も自ら「re:Inventに参加したい！」と手を挙げて、去年参加させてもらいました。 ラスベガスで開催されたAWS re:Inventにて。 執行役員常務の鴨川（右上）と若手社員3名で参加しました。 「BIGLOBE」を指しています。 日本を飛び出して世界中のユーザーと一緒に1つのことを学ぶ本当に貴重な機会となりました。去年一緒に行ったメンバー3人全員が同じことを言っていましたが、毎日が刺激的で毎日多くを学ぶことが出来る本当に素晴らしい体験でした。その時の様子は、以前このTechBlogで紹介させていただきました。   style.biglobe.co.jp   re:Invent に参加してきた内容を社内発表しましたが、多くの社内メンバーがとても興味を示してくれて、「参加したいです！」と声を挙げてくれました。 2020年はオンラインでの開催となり、上の記事で書いたTipsが活かせないのがちょっとだけ残念です・・・。 またBIGLOBEは社内にいても、深い情報を気軽に得ることができます。 例えば、AWS社の方を講師に招いてAWSに関する講習を開いてもらって、AWSを学ぶ環境を整えています。また、AWS社のご厚意で気軽に質問が出来る環境もあり、AWSに触れてつまづいてもすぐに解決できるようにしています。 さらに、BIGLOBEでは自前でデータセンターの構築運用を実施しているので、深いインフラ知識を持つエンジニアが多く在籍しています。AWS環境を構築したとしてもインフラ環境のチューニングは必要になります。特にオンプレからの移行案件では、オンプレとの性能差は必ずチェックすることになります。 AWSへの移行を進めるにはOSやストレージ、NWなど多くの知識が必要になります。 もちろん自分でも勉強をするように心がけていますが、どうしても困ったときには近くにスペシャリストがいるのでその人たちに聞けば、解決できるというところはとても心強いです。 BIGLOBEはAWSを利用し始めてまだ日が浅く色々なことにチャレンジしている最中です。 また、AWSに限らず新しいサービスの創出など新しい取り組みにも次々と挑戦をしています。 私も含めて何年もオンプレの仕事を続けてきたメンバーが新しい技術を取り込みながら日々学び成長しています。もちろん、若いメンバーも大活躍しています。今年入社した新入社員エンジニアは「手を動かしながら学ぶ」「困った時はスペシャリストに気軽に聞ける」というBIGLOBEの環境を上手に使って、早速3名が「AWSソリューションアーキテクトアソシエイト」に合格しています。 BIGLOBEで共に成長して、インターネットで社会を支えていきませんか。 ご興味のある方はこちらの採用情報をご覧ください。 hrmos.co ※ Amazon Web Services、AWSロゴおよびかかる資料で使用されるその他のAWS商標は、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。

こんにちは、南といいます。 BIGLOBEでネットワークエンジニアをやっています。 8月に開催されたJANOG46でCONECTに参加するメンバーとともに「COVID-19インターネット最前線と日本の通信事業者連携」というテーマで講演を行いました。 本日は、この講演の内容とその経緯についてご紹介します。   インターネットの運用をより良くするJANOG 増加し続けるインターネットトラヒックに立ち向かうCONECT 世界中のネットワーク運用者が協力して支えるインターネット COVID-19がネットワーク運用に与えた影響とは? 平日昼間のトラヒックにはっきり現れたCOVID-19の影響 COVID-19によるトラヒック増に耐え抜いたBIGLOBEのネットワーク ゲーム配信トラヒックがインターネットに与えるインパクト 協働を通じて成長と楽しさを実感するネットワーク運用の世界   インターネットの運用をより良くするJANOG   本題に入る前にまず、JANOGからご説明しましょう。 https://www.janog.gr.jp/information/ より抜粋 JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。 このようにJANOGでは、様々な事業者・企業・学術団体等、そしてエンジニアだけではなく企画や営業を担当される方等、多種多様なメンバが集まり、インターネットというインフラの運用がより良くなるよう日々議論を行っています。 いわゆる業界コミュニティの一つになるのですが、一種の業界団体と考えていただいた方がイメージしやすいかもしれません。 このJANOGは主にメーリングリスト上で情報交換や議論を行いますが、参加者が一堂に会し議論するJANOG Meetingが年に2回開催されます。 JANOG Meetingも今回が46回目、8月26日から8月28日にかけて沖縄で開催されました。 真夏の沖縄で他組織のネットワークエンジニアと交流する機会を楽しみにしていましたが、残念ながら今回はCOVID-19の影響でウェビナーを中心とする変則開催となりました。 通常であれば講演者全員が現地会場でそろって登壇するところ、今回はウェビナーでの開催となったため、全員が自宅やオフィスからのリモート登壇となりました。 私も自宅から登壇しました。   増加し続けるインターネットトラヒックに立ち向かうCONECT   では次にこのCONECTとは一体なんでしょうか。 CONECTはCOuncil for Network Efficiency by Cross-layer Technical membersの略称で、正式にはインターネットトラヒック流通効率化検討協議会という名称です。 https://www.soumu.go.jp/menu_seisaku/ictseisaku/conect/ 総務省>インターネットトラヒック流通効率化検討協議会 インターネットトラヒックとはインターネット上を流れる様々なデータ(動画やSNS、web閲覧等)の流量を指しています。 コンテンツの高品質化や、新たなコンテンツの普及・拡大等により、インターネットトラヒックは増加の一途をたどっています。 これらトラヒックはたとえばネットワーク事業者とコンテンツ事業者等、様々な事業者間を行き交うわけですが、トラヒックが増えゆく中でインターネットの品質を適切に維持・向上させていくためには、このようなインターネットトラヒックの流通に携わる多くの事業者が業界を超えて連携する必要があります。 CONECTはこの課題を解決するために設立されました。 2020年10月時点で37者が参加しています。 こちらも業界団体の一つとご理解いただいて問題ないでしょう。   世界中のネットワーク運用者が協力して支えるインターネット   さて、このようにコミュニティや業界団体っぽいものが二つ登場しました。 ではなぜ、BIGLOBEがこのような取り組みに参加し、積極的に他組織との連携を進めているのでしょうか。 そこにはインターネットのネットワーク運用独特の考え方もありますので、私の考え方を少し共有しておきましょう。 インターネットは人々の生活を支える重要な社会インフラであると同時に、多くのビジネスを生み出すプラットフォームでもあり、そしてまだまだ多くのイノベーションを生み出す可能性に満ちた全人類の大切な資産です。 このインターネット、世界中の無数のネットワークが相互に接続することで成り立っています。 そこには絶対的な権力を持つ管理者は存在せず、参加者によるボトムアッププロセスで運用ルールが規程され、また各ネットワークは自律・分散・協調の下、運用されています。 絶対的な管理者がいない故にもろい側面もあり、とあるネットワークが不安定になると、その影響がインターネット全体に波及することさえあります。 したがって、インターネットを安定して維持・運用するには、各ネットワーク同士の協力が欠かせません。 仮にビジネス上は競合関係にあっても、インターネットの安定運用には相互協力が不可欠なのです。 そのため、JANOGやCONECTに限らず運用者が集まるコミュニティや業界団体は世界中に数多く存在します。 このような状況の中、私は一人のインターネットエンジニアとして、またインターネット上でビジネスを行い利益を享受している企業の一員として、そしてインターネットの一部を構成するネットワークの運用者として、この世界にただ一つしか存在しない「The Internet」の持続的な成長・発展に貢献していく責任があると常に考えています。 私も会社員ですので、仕事が忙しくて社外活動なんてしている暇がないと感じるときもあります。 ときには、発信する情報が自社の優位性を損ねるのでは、という懸念を抱くときもあります。 しかし、自分・自社のことばかり考えず、可能な限り、インターネットの安定運用と今後の発展に貢献できるよう努めています。 インターネットの発展なくしてBIGLOBEの発展もあり得ません。 今回の活動にはこのような背景が存在します。   COVID-19がネットワーク運用に与えた影響とは?   前置きが長くなりました。 ここからようやく本題です。 前述の通り、CONECTに参加するメンバーとともに私を含めた計8名で、「COVID-19インターネット最前線と日本の通信事業者連携」というテーマで講演を行いました。 私からはISPという立場で、主にインターネットトラヒックの変化、という観点でCOVID-19がネットワーク運用に与えた影響を紹介しました。 ウェビナーの様子(左上が筆者) インターネットは人々の生活に深く浸透しているため、インターネットトラヒックには人々の生活や行動が反映されています。 BIGLOBEは個人や企業のお客さまに対するご自宅・オフィス向けの光インターネット接続サービスの他、BIGLOBEモバイルというモバイルインターネット接続サービスを提供しています。 その中で最も多く利用されているのが、個人のご自宅向け光インターネット接続サービスです。 したがって、BIGLOBEのトラヒックを分析するということは、すなわち自宅における人々の生活の変化を読み解く作業とも言えます。 ではCOVID-19でBIGLOBEにおけるインターネットトラヒック、人々の行動はどのように変化したのでしょうか。 講演で使ったいくつかの資料を使ってご説明します。     平日昼間のトラヒックにはっきり現れたCOVID-19の影響   一番の特徴は平日の昼間におけるトラヒックの増加でした。   COVID-19により外出が制限され、3月以降ご自宅で過ごす人が多くなりました。 上記は平日昼間のトラヒック推移ですが、在宅勤務やオンライン授業の影響で自粛期間中に昼間トラヒックが劇的に増えた様子がご覧いただけます。 緊急事態宣言解除(5月下旬)によりトラヒックの減少が見られますが、8月に入ると再び増加傾向となります。 これは夏休みの影響です。 特に今年のお盆は帰省を自粛する人が多かったと思います。 例年は帰省に伴いご自宅でのインターネット利用が減るのですが、今年はご自宅で過ごされる方が多かったのでしょう、逆に増加傾向となりました。 一方で外出する人が減った分、外出時に利用されるBIGLOBEモバイルのトラヒックは減少傾向となりました。     COVID-19によるトラヒック増に耐え抜いたBIGLOBEのネットワーク   一部の国ではCOVID-19によるロックダウンの影響等でインターネット回線が輻輳し、インターネット利用が制限されたケースもあったと聞いています。 では日本でもそのような問題が発生したのでしょうか。 結論からいうと、幸いにも日本はこのような問題に至りませんでした。 もちろん、インターネットには様々な箇所にボトルネックが存在するので、一概に影響が皆無だったとは言い切れません。 ではなぜ、インターネットが混雑するといった問題が起きなかったのか、BIGLOBEを例にとってご説明します。 一つ目の理由として、BIGLOBEでは設備や回線の故障に備えてネットワークを冗長に構成しており、定常的に発生するトラヒックの倍以上の設備容量を常日頃から準備している、ということがあげられます。 突発的なトラヒック増加にもある程度耐えることができるのです。 二つ目、実をいうとネットワークはトラヒックのピークに合わせて設計されています。 BIGLOBEにおけるトラヒックのピークは夜22時頃です。 人々が帰宅し、就寝前の時間を利用してネットを閲覧したり動画サービスを楽しんだりしているのでしょう。 今回大きなトラヒック増加が見られた平日昼間はピークから外れているため、結果としてネットワークの品質にはそれほど大きな影響を与えませんでした。   ゲーム配信トラヒックがインターネットに与えるインパクト もちろん、ピーク時間帯にも若干の増加が観測されており、当初の増強計画を多少前倒す必要はありました。 以下がピークトラヒックの推移ですが、平日昼間と異なり、自粛による変動がそれほど表れていないことがわかります。 BIGLOBEでは、お客さまのインターネット利用増により、1年間でトラヒックが約1.4倍ほど自然に増加しますので、この右肩上がりの増加傾向は概ね自然増の範囲と見なすことができます。     さて、この図をご覧いただくと、時々トラヒックが突発的に増えている日があることに気づかれるかもしれません。 図に赤丸で印を付けているところです。 実はこれ、人気ゲームがダウンロード配信された日なんです。 最近のゲームはインターネット経由でアップデートデータがダウンロードされるそうです。 ゲームはその特性上、世界中で同時に配信を開始することが多く、このように配信が開始された日にトラヒックが急増します。 COVID-19によるトラヒック変動も気になるのですが、近頃ではISPのネットワーク運用者にとってこのゲーム配信をいかにスムーズに処理するかが課題となっています。 実はこのようなゲーム配信にどう取り組むべきかについても、前述のCONECTの中で議論が行われています。 CONECT参加者にはISPやモバイルキャリア、ゲーム会社、そしてゲーム会社からの配信をお手伝いする配信事業者も含まれており、どのようにすればゲーム配信のトラヒックを効率的に処理できるか、各社協力しながら議論を重ねています。     このように、ネットワークエンジニアはネットワークの状況を詳しくモニタリングし人々の行動を予測しながら、品質維持・向上に日々努めています。 自社で頑張るだけではなく、ときにはインターネットらしく他組織と連携して、様々な課題に立ち向かっています。   協働を通じて成長と楽しさを実感するネットワーク運用の世界   簡単ですが、JANOG46で講演した内容をご紹介しました。 BIGLOBEの事例をご紹介することで他組織のネットワーク運用改善のヒントとなったり、より良い運用に向けた議論に結びついていれば幸いです。 また、CONECTのような事業者間連携の重要性の一端もご紹介できたかと思います。 文化の異なる他組織との連携はときに大きな苦労を伴うことがあります。 しかし、多様な人たちとの協働には多くの学びがあり、結果として自身の成長と楽しさを感じることがほとんどです。 今回は触れませんでしたが、このような対外活動には各社員の技術レベル向上を図る、という目的もあります。 BIGLOBEは今後も自らの技術力を高め、そして自らのネットワーク運用に磨きをかけて、お客さまが快適にインターネットをご利用できる環境を提供して参ります。 それと同時にインターネットのさらなる発展に貢献するため、コミュニティや業界団体活動にも積極的に取り組んでいきます。   以上です。 最後までお付き合いいただきありがとうございました。   私たちと一緒にインターネットで社会を支えていきたいエンジニアを大募集しています。よろしければ採用情報をご覧ください。 hrmos.co

取締役執行役員常務　基盤本部長　鴨川　比呂志 BIGLOBE Styleをご覧頂きありがとうございます。おかげ様で多くの皆様に目を留めて頂き、「あのブログ面白かったよ！」「BIGLOBEってこんな会社だったんだ！」等のお言葉が私のメールBOXにも届き、それだけでコロナ禍の鬱陶しい日々を忘れさせてくれます。 さて、自己紹介が遅れましたが、私はBIGLOBEでネットワークやクラウド等のインフラ設計・構築や情報システム開発を担当している部門である基盤本部の責任者の鴨川です。今日は、BIGLOBEの事業の柱の一つであるモバイル事業（技術）が世の中を変えていくこと、また実際にその過程を私も経験した話をさせて下さい。 本来であれば我社はこんな会社です！と緻密に語ることが期待されているのかもしれませんが、我々が日々研鑽を積んでいる技術はこんなにもたくさんの人の人生を豊かにする可能性がある、BIGLOBEで仕事をするということはその可能性を追求しているんだ、ということを、海外での事例を通じて知って頂きたいと思います。 皆さんはミャンマーをご存知ですか？そうです、インドシナ半島の西側に位置する日本人にも馴染み深い大国です。最大都市ヤンゴンや首都ネピドーを訪問された方もいらっしゃると思います。 実は、2013年当時のミャンマーの携帯電話普及率は10% *1 にも満たないと言われていた国だったのです。まだほんの7年前ですね。日本では4G(LTE)が普及し始め、一人で2台の端末を持ち歩くことも珍しくなくなった時期でした。また、ミャンマーの近隣諸国であるシンガポールやマレーシア等の東南アジア諸国も複数事業者の競争により多くの方がスマートフォンを持ち歩き、インターネットライフを謳歌していました。 ミャンマーの携帯電話普及率が低かった理由の一つに「独占」というワードがあります。ミャンマー政府はこの「独占」を終わらせるため、2013年に「競争政策」を取り入れて、諸外国で実績のある複数の事業者が参入を果たしました。参入した各社は自国での経験により、端末やSIMカードの品揃え・料金戦略・販売チャネル整備・広告宣伝手法の確立等を次々と打ち出していきました。「独占」時代には携帯電話を利用する事を「特別」な事と受け止めていたであろう国民が、わずか１～２年で「当たり前な事」と受け止める事になったのではないでしょうか。当時のミャンマーではFTTH等の固定通信もほとんど普及しておらず、多くの国民にとって初めてのインターネットとの出会いだったのではないでしょうか。 さて、各社が参入当時に力を入れた事がもう一つあります。それは基地局建設やモバイル基盤構築を始めとした「最新技術の投入」でした。既述のとおり、多くの国民に携帯電話（もちろんスマホです）が普及してくると、今度は品質の優劣が事業者選択の重要な基準になってきます。参入当初は「参入したよ！」「我々はこんな事業者です！」を国民に知ってもらうことが優先されますが、通信事業は「いつでもキレイに繋がって当たり前」というサービスを提供し、対価として料金を頂くビジネスなので、結局のところQCDを考慮しつつも *2 この勝負になるのですね。 各社は、腕利きのエンジニアを送り込み、お客様の信頼を勝ち取るための努力を続けていきます。ある意味、何もないところから作り上げるので、まさにエンジニアの腕の見せ所であり、エンジニア冥利に尽きる体験をすることになったでしょう。ミャンマーという国にどのような通信技術が根付いて行くのか、あるいは今後どのように進化していくのか？は全てこの挑戦に取り組んだエンジニアの心意気次第だったのです。 2019年には携帯の普及率も100%を超えた *3 と聞いており、当たり前のようにスマホを持ち、SNS等でのコミュニケーション、動画視聴等の生活の潤いだけではなく、あまり普及していなかった銀行口座やクレジットカードの代わりにモバイル送金が浸透し遠隔地への仕送りが簡便になったり、と生活インフラの拡充にも役立つようになってきました。 会社同士、エンジニア同士の「切磋琢磨」が「革新」を生み、「革新」が「驚き」を生み、「驚き」が「感動」を生み、「感動」が「心の豊かさ」を生み、大げさに言うと、人生をも変えた可能性があると思います。 BIGLOBEでも、MVNO/ISPとして他社と「切磋琢磨」するために、会社が抱える経営課題を打破するために、自分を高めて成長を実感するために、等々の意思を持って多くの社員がCutting-edgeな（最先端の）取り組みを進めています。 BIGLOBE Styleをご覧の方であればお判りかと思いますが、多くの取り組みの中のごく一部の例ですが、以下のようなブログ記事がご覧いただけます。 【ドメイン駆動設計（DDD）の取組み】 style.biglobe.co.jp style.biglobe.co.jp style.biglobe.co.jp 【若手中心チームでのハッカソン優勝】 style.biglobe.co.jp 【GitOpsへの取組み】 style.biglobe.co.jp 【世界初の固定回線へのNAT64/DNS64の商用化】 style.biglobe.co.jp 【所謂「2025年の崖」に備える取組み】 style.biglobe.co.jp BIGLOBE Style（Tech Blog）という媒体が始まったことで、このような取組みを皆様にお知らせすることができ、そのフィードバックを頂くことで、また、新たなチャレンジを始めるエンジンになります。 引き続きBIGLOBEは前に進んでいきます。私が言うのも何ですが（笑）、本当にいろんなプロジェクトが並行して進んでいて、新型コロナウィルス対応には細心の注意を払いながらも、日々研鑽を積んでいます。このCutting-edgeな船に皆さん乗船しません？と、最後は本音が出ましたね、本部長！ hrmos.co *1 : KDDIのホームページ（ https://www.kddi.com/corporate/csr/feature1-02/ ）を参考にしています。 *2 : BIGLOBEのQCDについては以下の記事が参考になります。 　　　　・ https://style.biglobe.co.jp/entry/2020/09/30/130000 *3 : KDDIのホームページ（ https://www.kddi.com/corporate/csr/feature1-02/ ）を参考にしています。

こんにちは。BIGLOBE 永末です。 今回は Amazon Web Services （AWS） の小ネタです。 BIGLOBE では近年、 AWS などクラウドサービスの活用を積極的に進めています。CDN サービス(CloudFront)も AWS では簡単に導入できるため、レスポンスの高速化とオリジンサーバの負荷軽減施策として、積極的に採用しています。 CloudFront は便利ではあるのですが、そのまま使うとログの解析がたいへんです。ログがS3 上にファイルとして出力されるため、S3 からログファイルをダウンロードした後に検索などを行う必要があるからです。 そこで、BIGLOBE では簡単にログ解析できるように Athena を利用しています。数か月前に登場した Athena の新機能「Partition Projection」を使って、検索環境の構築を少しだけ楽にしました、というのが今回のお話です。 Partition Projectionとは CloudFrontのログ検索に使ってみる 1. S3 のログファイルを移動 2. Glue データベースとテーブル作成 3. Athena の初期設定 最後に Partition Projectionとは 2020年6月に実装された Athena の新機能です。 aws.amazon.com 今までは Athena でパーティション検索をするには、あらかじめ Glue Data Catalog にパーティションを作成しておく必要がありました。Partition Projection を使えばこれが不要になります。例えばパーティションのパスが日付(YYYY/MM/DD)の場合、YYYY/MM/DD をパーティション情報として Glue テーブルを作成すれば、パーティションを自動で計算してくれます。パーティションの管理が不要になるだけでなく、検索も高速になります。 CloudFrontのログ検索に使ってみる 以前紹介した記事 では、まだ Partition Projection がなかったので、バッチで Data Catalog にパーティションを追加していました。これでも動作に問題はないのですが、パーティションを作成する Lambda をメンテナンスする必要があるため、今回取っ払いました。 検索環境構築の道のりは以下のとおりです。 1. S3 のログファイルを移動 CloudFront が出力する S3 上のパスは次のようになっています。 S3://<バケット名>/プレフィックス/<Distribution ID>.YYYY-mm-dd-HH.xxxxxxxx.gz まずこれをパーティションのパスに移動させます。こんな感じです。 S3://<バケット名>/プレフィックス/YYYY/mm/dd/HH/<Distribution ID>.yyyy-mm-DD-HH.xxxxxxxx.gz このあたりは 以前紹介した記事 と同じで、Lambda で定期的に移動させます。 2. Glue データベースとテーブル作成 Glue データベースとテーブルを作成します。以下、CloudFormation のテンプレートです。 ▶クリックで展開 AWSTemplateFormatVersion : "2010-09-09" Description : Athena CloudFront Log table Stack Parameters : CFLogBucket : Type : String BucketPrefix : Type : String CFName : Type : String AllowedPattern : ^ [ a - z0 -9_ ] *$ Resources : GlueDatabase : Type : AWS :: Glue :: Database Properties : CatalogId : ! Ref 'AWS::AccountId' DatabaseInput : Description : CloudFront log for athena Name : ! Sub [ '${cfnt}_log_database' , { 'cfnt' : ! Ref CFName } ] GlueTable : Type : AWS :: Glue :: Table Properties : CatalogId : ! Ref 'AWS::AccountId' DatabaseName : ! Ref GlueDatabase TableInput : Description : CloudFront Log Name : ! Sub [ '${cfnt}_log_table' , { 'cfnt' : ! Ref CFName } ] TableType : EXTERNAL_TABLE PartitionKeys : - Name : date Type : string StorageDescriptor : Columns : - Name : log_date Type : string - Name : log_time Type : string - Name : location Type : string - Name : bytes Type : bigint - Name : request_ip Type : string - Name : method Type : string - Name : host Type : string - Name : uri Type : string - Name : status Type : int - Name : referrer Type : string - Name : user_agent Type : string - Name : query_string Type : string - Name : cookie Type : string - Name : result_type Type : string - Name : request_id Type : string - Name : host_header Type : string - Name : request_protocol Type : string - Name : request_bytes Type : bigint - Name : time_taken Type : float - Name : xforwarded_for Type : float - Name : ssl_protocol Type : string - Name : ssl_cipher Type : string - Name : response_result_type Type : string - Name : http_version Type : string - Name : fle_status Type : string - Name : fle_encrypted_fields Type : int - Name : c_port Partition Projection が関係するのはこのあたりです。 projection . enabled : 'true' , projection . date . type : 'date' , projection . date . range : '2018/01/01/00,NOW' , projection . date . format : 'yyyy/MM/dd/HH' , projection . date . interval : '1' , projection . date . interval . unit : 'HOURS' , projection.date.range で 2018/01/01 から現在までを指定しています。このあたりはお好みです。なお、projection.date.range を100年などすごく広い範囲にしても、クエリを投げる際にパーティションを指定すれば検索時間が遅くなることはなさそうです。 テンプレートの入力パラメータは以下のとおりです。 　CFLogBucket：CloudFront がログ出力するバケット 　BucketPrefix：ログバケットのログ出力先プレフィックス 　CFName：CloudFront 名 ※データベース名、テーブル名に利用 CFName の AllowedPattern に -(ハイフン) がないのは、- があるとクエリを投げる際に database、table名を " で囲む必要があり、面倒だからです。 3. Athena の初期設定 Athena 未使用の場合、クエリ結果を出力する S3 バケットを設定しておきます。また、クエリを投げる際にパーティションキーを指定し忘れると、全スキャンが発生して AWS 利用料がすごいことになってしまう可能性があります。対策として、スキャンの上限を入れておきます。 あとはクエリを投げるだけ。このような感じです。 SELECT * FROM <CloudFront名>_log_database.<CloudFront名>_log_table WHERE date = ' 2020/10/05/05 ' ちなみに、パーティション指定をしないでフルスキャンすると検索がすっごい遅いです。 Hourly ではなくDaily で設定すると、フルスキャンでも速くなりました。 2レコードの検索でこれくらいの差が出ます。 　HOURS 指定：1m47s～2m13s 　DAYS 指定：2.33s とはいえ、パーティション指定せずに検索することはあまりないとは思うので、気にしないことにしました。 最後に というわけで、 Glue Data Catalog にパーティションを作成することなく検索できるようになりました。今までのやり方でも特に問題があったわけではないのですが、そこそこの数の AWS アカウントで CloudFront が動いていることもあり、今後のメンテナンス性を考えて Lambda をやめることにしました。 ALB のログ検索も同様に行えてすごく便利なので、どんどん Partition Projection を使っていきましょう! 以上です。 ※　Amazon Web Services、AWSロゴおよびかかる資料で使用されるその他のAWS商標は、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。

基盤本部（開発部門）でエンジニア育成を担当している高玉です。 企業によっては、新型ウィルス対策としてのオンライン対応が難しく、新人研修自体を打ち切ってしまったところもあるそうです。 そんな中、私たち基盤本部では全力で新入社員を育成すべく、様々な工夫を凝らしてオンラインでの研修を継続しています。 この記事では新卒エンジニア向け研修の概要の後に、 「新人がBIGLOBEで生き生きと働けること」を目指した「リーダーインタビュー」について詳しくご紹介します。 コロナ禍という未だかつてない状況にあっても新人が孤独にならず、社内の仲間とつながる喜びを感じられる取り組みです。 どの組織でも実践できるように、ノウハウを惜しみなく公開します。 寂しい思いをしている新入社員が一人でも元気になれば幸いです。 新卒エンジニア向け研修 リーダーインタビューの進め方 1. 事前 狙い 部長用テンプレート グループリーダー用テンプレート 2. 当日 新人からの質問例 3. 事後 新人たちのふりかえり リーダーインタビューへのフィードバック 新人向けアンケート リーダー向けアンケート まとめ 新卒エンジニア向け研修 エンジニア職の新入社員5名のために、次の研修を実施しています： 月～木：OJT（On the Job Training） 現場で実務を担当しながら「タスクばらし」と「ふりかえり」を実践し、セルフマネジメント力を高める 金：共通研修 リーダーインタビュー 現場を牽引するリーダーから、組織のビジョン・ミッション・仕事内容・キャリア形成などを学ぶ 共通スキル ロジカルシンキングやマーケティングといったビジネススキルと、ネットワークからアプリケーション開発まで幅広いテクニカルスキルを、ワークを通じて実践的に学ぶ BIGLOBEノウハウ 現場で活躍するスペシャリストから、BIGLOBE独自のノウハウを学ぶ 毎週金曜日は丸々一日を共通研修に充てています。 「リーダーインタビュー」は新入社員の皆さんがBIGLOBEのリアルを知ることで、 一日も早く、そして、これからもずっと「生き生きと働ける」ようになることを目指した取り組みです。 新入社員の元気な様子に大きな手ごたえを感じています。 リーダーインタビューの進め方 事前、2. 当日、3. 事後、にステップを分けて説明します。 リーダー 新人 事務局 事前 テンプレートを参考に、説明資料を作成 スケジュール調整、資料作成依頼 当日 資料を使って説明（Google Meet） インタビュアーになって深掘り 事後 アンケート回答 社内ブログにインタビュー記事を公開、一巡するごとにふりかえり フィードバックを元に改善 1. 事前 BIGLOBEの組織構造は、本部、部、グループの3階層です。 リーダーインタビューの対象は、部長とグループリーダーにしています。 事務局がリーダーのスケジュールを確保し、リーダーにテンプレートを渡して資料作成を依頼します。 リーダーはテンプレートを参考に、説明資料を作成します。 狙い 従業員が生き生きと働ける環境を作るために、次の3つが大切だと考えています。 お互いを良く知っている 組織が目指す方向性に共感している 挑戦する風土がある そこで、次のようにテンプレートを設計しました。 赤裸々な自己紹介を通じて、少し遠い存在になりがちなリーダーを身近に感じる 普段の業務では埋もれがちなビジョン・ミッションを、部長から聞く ビジョンに向かって挑戦する宣言を、グループリーダーから聞く 部長とグループリーダーでテンプレートを分けているのがポイントです。 役割の違いを反映しています。 その一方、どちらのテンプレートにも「自己紹介」を入れています。 アイスブレイクとして、その人らしさが伝わるエピソードを最初に共有してもらいます。 部長用テンプレート 部長用の資料には、部のミッションとビジョンを記入してもらいます。 自己紹介 好きなこと・得意なこと・実は自慢したいこと、など 部のミッション 企業理念「つながる歓び、つなげる喜び」との関係 お客様や会社に対してどう貢献しているか？ 部のビジョン どんな会社、部、グループにしていきたいか？ 求める人材像 グループリーダー用テンプレート グループリーダー用の資料には、仕事の具体的な内容に加えて、メンバーの育成方針や、挑戦したいことを記入してもらいます。 自己紹介 好きなこと・得意なこと・実は自慢したいこと、など グループの仕事 仕事内容、仕事のやりがい グループの育成方針 メンバーが成長するための工夫や取り組み グループで挑戦したいこと 部のビジョンを実現するために挑戦したいこと 2. 当日 BIGLOBEは新型ウィルス対策のため基本的には在宅勤務となっています。 そのため共通研修はオンラインで実施していて、当日は Google Meet でリーダー、新人が集まります。 リーダーが自己紹介、資料を使った業務紹介をした後、新人からの質問タイムへと移ります。 新人はインタビュアーになったつもりで、リーダー自身のこと、業務のことなどを根掘り葉掘り聞いていきます。 持ち回りで記事担当を決めることで「記事担当の新人が真剣に話を聞く」ことを狙ったのですが、 実際にやってみると記事担当かどうかは関係なく、全ての新人が熱心に質問をしてくれます。嬉しい誤算です！ 回を重ねるごとに質問の内容も高度になっていて、新人の伸びしろに驚くばかりです🚀 最近は司会進行も新人が担当してくれています。頼もしい限りです💪 新人からの質問例 インタビューと記事執筆を重ねていく中で、どんな質問をすると「面白い記事・読まれる記事」になるかが分かってきたそうです。 今までで一番「やらかした」失敗の話を教えてください。そこからどんなことを学ばれましたか？ 失敗談自体から学べることはたくさんあります。 さらに「失敗した時に周囲がどうサポートしてくれたのか」のエピソードから、新人たちはBIGLOBEらしさを学び取ってくれているようです。 記事にするととても人気が出ます。 BIGLOBEが他社と比べて、強いところ、弱いところはどういうところでしょうか？ インターネットは世界中の組織と協調して維持する必要があります。そのため、BIGLOBEは常日頃から社外との連携がとても多い会社です。 リーダーたちは社外との交流が多く「社外からBIGLOBEがどう見えるのか」の視点を持っています。 社外と比較することで、BIGLOBEの特徴が良く分かるそうです。 3. 事後 記事担当の新人はインタビュー内容を記事にまとめ、社内ブログで公開します。 アウトプットするのは、時に苦しいものです。 それを少しでもサポートできるように、と開催した「最後まで読ませる文章作成講座」については、すでに紹介させていただきました。 style.biglobe.co.jp BIGLOBEには優しい人が多いので、社内向けにどんなアウトプットをしても受け入れてくれるのですが、 記事の内容が面白いと社内からの反響も大きいため、それぞれが工夫を凝らして記事を書いていきます。 例えば、固定回線として世界で初めて「NAT64/DNS64」と呼ばれる技術を商用化した（2019年10月28日時点、MM総研調べ）N澤さんへのインタビュー（ 世界初への挑戦！インターネットを快適にするNAT64/DNS64とは？ ）は、社内ブログでは 「 【業務紹介】ホンネを言うと攻めたことだけでなく守ったことも褒めてほしい 」 というタイトルの記事になりました。 非常にチャレンジングな取り組みで、高い評価を受けた仕事ですが、N澤さんのグループは他にも重要なインターネットサービスを運用しています。目立つ仕事だけではなく、目立たない仕事があってこそ、インターネットが快適に使えるようになっていることを「おやっ？」と思わせるタイトルをつけて記事にしてくれました。 新人たちのふりかえり 新人たちがリーダーインタビューを通じて学んだことを言語化し、次のインタビューへと活かすため、記事担当が一周する度にふりかえりを実施しています。 先日のふりかえりでは、新人たちが「チーム」として、お互いをサポートし合いながら工夫を続けていることをお互いに再認識できました。 記事担当でなくてもメモを取って置き、インタビュー後に共有している Aさんの質問に対して回答があった後、Bさんがその回答に対して、さらに深掘りした質問をしている いい質問だったらメモしておき、次回以降も使っている 「記事を通じて基盤本部のことを知ってもらう」という新人だけに与えられたミッションに向かって、力を合わせながら（時に面白おかしく）取り組んでくれています🎉 リーダーインタビューへのフィードバック 共通研修は、特にオンライン環境下で実施していることもあり、まだまだ改善の余地があります。 そこで、新人と、業務紹介を担当してくれたリーダー双方からのフィードバックを回収し、改善を続けています。 新人向けアンケート まずは新人のアンケート結果です。 なんと全員が「次年度以降も継続すべき」を選んでくれています🎊 図1 新人向けアンケート（オススメ度。10がオススメ） さらに「働く意欲が引き出された」という回答も多く、リーダーインタビューの目的を果たせていることが分かります。 図2 新人向けアンケート（働く意欲。10が引き出された） インタビューに加えて記事を書くのは、慣れないうちはなかなかの負担なのですが、前向きに取り組んでくれていてありがたい限りです。 自由記述から、たくさんの「良い面」を見出してくれていることが分かります。 自分がBIGLOBEを理解するだけでなく、社内ブログを通して理解したことを全社に共有できる。コメントを通じて部署を越えた交流が生まれるのが良いと思う その部署でのやりがいや、他の部署とのつながりまで理解できる。その部署のことを知りたい人にとって、とても有益な情報を記録できていると実感している 会議のファシリテーション能力、質問を考える能力、文章を書く能力が鍛えられている 在宅勤務だとチャットで話しかけることになるが、そのハードルが下がった リーダー向けアンケート 続いてリーダーからのフィードバックです。 改善が必要な点はあるものの、この取り組みに賛同する声を多く集めることができました。 図3 リーダー向けアンケート（オススメ度。10がオススメ） リーダーから見た良い点は次の通りです。 幅広い業務・幅広い技術が必要になる基盤本部について、新人が横断的に学べる 新人はもちろん、社内ブログを通じて、全社に部やグループの活動を知ってもらえる 新人だけでなく、キャリア採用入社の方のオンボーディング資料になる 業務を説明する事で、自分たちにも学びがある 新人の真剣な姿勢に刺激を受けた その一方で、改善したい点も挙がっています。 オンラインでの講義だと一体感を出すのが難しい リーダーの準備や、新人の記事作成の負担を軽減したい オンラインでの一体感については、新人からも同様の声がありました。 とても意義ある活動なので、さらに工夫を重ねていきたいと思います。 まとめ BIGLOBEで実施している新卒エンジニア向け研修から、リーダーインタビューについてご紹介しました。 基盤本部の持つ幅広い業務・幅広い技術について、現場のリーダーに直接教えてもらう研修です。 話を聞く新人に責任感を与えるため、聞いた内容を記事にまとめる当番を作ったのですが、 全ての新人が熱心に質問をしてくれる、という嬉しい誤算もありました。 リーダーからの赤裸々なエピソードと、ビジョン・ミッション・挑戦したいことをまじえた話は、 新人から「BIGLOBEで生き生きと働く意欲」を引き出しています。 コロナ禍という未だかつてない状況の中でも、オンラインで新人研修を継続できているのはインターネットがあるおかげです。 「インターネットは、すごい！」とあらためて感じています。そして、このインターネットをお客様に提供できることは、私たちの誇りです。 私たちと一緒にインターネットで社会を支えていきたいエンジニアを大募集していますので、もしよろしければ採用情報をご覧になっていってください。 hrmos.co ※Googleは、Google LLCの商標です。

開発部門（基盤本部）でエンジニア育成を担当している高玉です。 BIGLOBEには登山部、麻雀部、ツーリングクラブなど様々な部活があります。今日はインドア派の部活、プロコン部についてご紹介します。 プロコン部とは ゆるくて多様なプロコン部 みんながいるから続けられる みんなのコードをチラ見せ コードゴルフ感ただようPython v.s. Rust ワンライナー F# JavaScriptで多倍長整数を扱う、だと！？ まとめ プロコン部とは プロコンってご存知ですか？ ここでいうプロコンは、ゲーム機用のProコントローラーでも、良い点（Pros）・悪い点（Cons）を列挙するのでもありません。「競技プログラミングコンテスト」の略です。 プログラミングコンテストとは、プログラミングの技術を競い合うイベントです。参加者にお題が出題されるので、そのお題を解くプログラムを制限時間内に提出します。 プロコン部では、プログラミングコンテストで出題された過去問を各自が解いて持ち寄り、その解法を披露しあうことで、楽しくプログラミング力を高めあっています。 この記事の最後に、部活で書いている実際のコードをご紹介します。JavaScriptで多倍長整数を扱う神コードも飛び出します。どうぞお楽しみください。 ゆるくて多様なプロコン部 プロコン部の最大の特徴は「ゆるさ」と「多様性」にあります。 プログラミングコンテストに挑戦して良い成績を目指すよりは、幅広いアルゴリズムに触れて楽しく実装することが目的のゆるい部活です。 部活は週1回1時間、業務時間内に開催しています。国内最大の競技プログラミングサイト AtCoder で公開されている過去問を1つ取り上げて、各人が業務の合間に自分のペースで挑戦してきます。本番のプログラミングコンテストでは「問題を早く解くスキル」も求められますが、部活ではそのプレッシャーがないのも、ゆるさにつながっています。 約10名のメンバーが使うプログラミング言語は本当に様々です。C++、Python、JavaScript、Java、Scala、Swift、Ruby、Haskell、Rust、Clojure、F#。 みんなが同じ問題を解いてくるのですが、人によってアプローチの仕方が違うことに加え、言語による得意・不得意が分かるのがとても面白いです。問題によって「Haskellだと短く書ける」「Pythonだとシンプル」「C++のライブラリ便利」といった違いがハッキリ分かります。 名著と名高い「 達人プログラマー 」では「毎年少なくともひとつの言語を学習する」というプラクティスを紹介していますが、この部活が新しいプログラミング言語を学ぶ最適な場になっています。私もC++で問題が解けるようになりました。 みんながいるから続けられる メンバーにプロコン部の魅力を聞いたところ、 「一人だとなかなか続かないけど毎週集まることでモチベーションが維持できる」 「他の人と一緒にやることで、やる気が刺激される」 「解いてくる人がいるので辞めるに辞められない環境」 といった声が集まりました。 また、 「自分の解答も人に説明するので思考やコードが整理される」 という声もありました。 仲間がいるのは心強いものです。ゆるく取り組んでいるとはいえ幅広く様々なアルゴリズムを学ぶので 「苦手なアルゴリズムに取り組むのはとてもしんどい」 という正直な声もありました。それでも続けられるのはすごいことです。 その結果 「ちゃんと力量アップした実感がある」 というメンバーもいます。コンピューターのメモリー量や計算量が、利用するデータ構造やアルゴリズムによって大きく異なることを、業務だけで学ぶことはなかなかできません。 「コンピュータや処理系の気持ちになれる」 との声もありました。 BIGLOBEが大切にする価値観・信念（ ビッグローブマインド ）の一つに「継続的に成長する」があります。みんながいるから続けられる、続けられるから成長できる。私たちプロコン部の活動は「とてもBIGLOBEらしい活動だなぁ」と改めて思います。 みんなのコードをチラ見せ 振り返ってみると、週1回・週1問のゆるいペースとはいえ、とてもたくさんの問題を解いてきました。その中から3つほど、問題と解答コードをご紹介します。 コードゴルフ感ただようPython v.s. Rust 問題文 駅の待合室に座っているjoisinoお姉ちゃんは、切符を眺めています。 切符には 4 つの 0 以上 9 以下の整数A,B,C,D が整理番号としてこの順に書かれています。 A op1 B op2 C op3 D = 7 となるように、op1,op2,op3 に + か - を入れて式を作って下さい。 （出典： AtCoder Beginner Contest 079 C - Train Ticket ） 例えば (A, B, C, D) = (3, 2, 4, 2) が与えられた時、3+2+4-2=7 と出力するプログラムが求められています。Pythonで直積を求めるライブラリー itertools.product を活用して、コンパクトに書かれたコードがこちらです。 import sys, itertools [a, b, c, d] = sys.stdin.readline().rstrip() ops = [ '+' , '-' ] for exp in [ '%s%s%s%s%s%s%s' % (a, op1, b, op2, c, op3, d) for op1, op2, op3 in list (itertools.product(ops, ops, ops))]: if eval (exp) == 7 : print '%s=7' % exp break コードの短さを競い合う「コードゴルフ」の雰囲気が漂います。 そういえば、プロコン部で苦手なアルゴリズムに挑戦することが続いたため、その気晴らしにコードゴルフ大会が開催されたという噂があります（笑）。 style.biglobe.co.jp ちなみに、Rust を書いてきたメンバーのコードはこれでした。コンパイルの通ったRustのコードって簡単に見えるから不思議です！ use proconio :: input; use itertools :: * ; fn apply (op: char , x: i32 , y: i32 ) -> i32 { match op { '+' => x + y, '-' => x - y, _ => unreachable! (), } } fn evaluate (a: &Vec < i32 > , ops: &Vec < char > ) -> i32 { ops. iter (). zip (a. iter (). skip ( 1 )) . fold (a[ 0 ], | s, ( & op, & x) | apply (op, s, x)) } fn make_expression (a: &Vec < char > , ops: &Vec < char > ) -> String { a. iter (). cloned (). interleave (ops. iter (). cloned ()). chain ( "=7" . chars ()). collect () } fn operators (n: usize ) -> impl Iterator < Item = Vec < char >> { ( 0 ..n) . map ( | _ | "+-" . chars ()) . multi_cartesian_product () } fn solve (a: String ) -> String { let s = a. chars (). collect :: < Vec < _ >> (); let a = s. iter (). map ( | c | c. to_digit ( 10 ). unwrap () as i32 ). collect :: < Vec < _ >> (); operators ( 3 ) . filter ( | ops | evaluate ( & a, & ops) == 7 ) . map ( | ops | make_expression ( & s, & ops)) . nth ( 0 ) . unwrap () } fn main () { input! { a: String , } let r = solve (a); println! ( "{}" , r); } ワンライナー F# 問題文 ファーストフードチェーン「ピザアット」のメニューは「A ピザ」「B ピザ」「AB ピザ」の 3 種類です。A ピザと B ピザは全く異なるピザで、これらをそれぞれ半分に切って組み合わせたものが AB ピザです。A ピザ、B ピザ、AB ピザ 1 枚あたりの値段はそれぞれ A 円、B 円、C 円です。 中橋くんは、今夜のパーティーのために A ピザ X 枚と B ピザ Y 枚を用意する必要があります。これらのピザを入手する方法は、A ピザや B ピザを直接買うか、AB ピザ 2 枚を買って A ピザ 1 枚と B ピザ 1 枚に組み替える以外にはありません。このためには最小で何円が必要でしょうか？なお、ピザの組み替えにより、必要な量を超えたピザが発生しても構いません。 （出典： AtCoder Beginner Contest 095 C - Half and Half ） 例えば (A, B, C, x, y) = (1500, 2000, 1600, 3, 2) が与えられた時、つまりAピザ 1500円、Bピザ 2000円、ABピザ 1600円で、Aピザが3枚、Bピザが2枚必要な場合、AB ピザを 4 枚買って A ピザと B ピザ 2 枚ずつに組み替え、A ピザを 1 枚買い足すのが最適です。7900円と出力することが求められます。 毎回必ず F# を使って、1行のプログラム（ワンライナー）で提出するメンバーのコードを紹介します。関数型とオブジェクト指向のマルチパラダイムの言語、とのことですが、私は不勉強で理解できないため、いつも雰囲気だけ楽しんでます😇 ループを使った解法では、ABピザ2枚をi枚買って、AピザとBピザに分けつつ、足りないAピザ・Bピザを補充する戦略を取ります。ABピザを買う枚数を変化させながら、最小の金額を総当たりで調べます。 stdin .ReadLine () |> fun x -> x.Split ( ' ' ) |> Array .map int |> fun x -> ( x. [ 0 ] , x. [ 1 ] , x. [ 2 ] , x. [ 3 ] , x. [ 4 ]) |> fun ( a, b, c, x, y ) -> [ 1. . ( max x y )] |> List .fold ( fun ret i -> a * ( max ( x - i ) 0 ) + b * ( max ( y - i ) 0 ) + c * i * 2 |> min ret ) ( a * x + b * y ) |> printfn " %d " 場合分けによる解法では、AピザとBピザを別々に買うのと、ABピザを買って分けるのとで、どちらが安くなるかを調べます。 stdin .ReadLine () |> fun x -> x.Split ( ' ' ) |> Array .map int |> fun x -> ( x. [ 0 ] , x. [ 1 ] , x. [ 2 ] , x. [ 3 ] , x. [ 4 ]) |> fun ( a, b, c, x, y ) -> [ a * x + b * y ; ( if x > y then a * ( x - y ) + c * 2 * y else b * ( y - x ) + c * 2 * x ); c * 2 * ( max x y ) ] |> Seq .min |> printfn " %d " JavaScriptで多倍長整数を扱う、だと！？ 問題文 非負の整数 a, b (a ≤ b) と、正の整数 x が与えられます。 a 以上 b 以下の整数のうち、x で割り切れるものの個数を求めてください。 制約 0 ≤ a ≤ b ≤ 10 18 1 ≤ x ≤ 10 18 （出典： AtCoder Beginner Contest 048 B - Between a and b ... ） 例えば (a, b, x) = (4, 8, 2) が与えられた時、つまり 4 以上 8 以下の整数のうち 2 で割り切れるのは、4, 6, 8 の3つなので、3 と出力するプログラムが求められています。 「0 以上 b 以下の整数のうち x で割り切れるもの」から「0 以上 (a - 1) 以下の整数のうち x で割り切れるもの」を引いた値を計算すればOKです（a が 0 の時を考慮する必要があります）。 ただ、この問題の「制約」が10の18乗で大変大きくなっているのがポイントです。C++であれば、64ビット以上の整数を表す long long を使って次のように簡単に解けます。 #include <iostream> using namespace std ; typedef long long ll; ll f (ll n, ll x) { if (n == - 1 ) return 0 ; return n / x + 1 ; } int main () { ll a, b, x; cin >> a >> b >> x; cout << f (b, x) - f (a - 1 , x) << endl ; return 0 ; } 私は当時 JavaScript で取り組んでいたのですが、JavaScriptで多倍長整数を扱うことができず撃沈していました。そんな時、メンバーの一人が次のコードを提出してきたのです。神か！ 長いので折りたたんで表示します。 ▶クリックで展開 const D = 24; const L = 3; function new64(n) { return [ n % (1<<D), (n / (1<<D)) | 0, 0 ] ; } function mul64s(a, b) { var r = [] ; var x = 0; for ( var i = 0; i < L; i++) { x = a [ i ] * b + x; r [ i ] = x % (1<<D); x = Math.floor(x / (1<<D)); } return r; } function add64s(a, b) { var r = [] ; var x = b; for ( var i = 0; i < L; i++) { x = a [ i ] + x; r [ i ] = x % (1<<D); x = Math.floor(x / (1<<D)); } return r; } function cmp64(a, b) { for ( var i = L-1; i >= 0; i--) { if (a [ i ] < b [ i ] ) return -1; if (a [ i ] > b [ i ] ) return 1; } return 0; } function add64(a, b) { var r = [] ; var x = 0; for ( var i = 0; i < L; i++) { x = a [ i ] + b [ i ] + x; r [ i ] = x % (1<<D); x = Math.floor(x / (1<<D)); } return r; } function sub64(a, b) { var r = [] ; var x = 0; for ( var i = 0; i < L; i++) { x = a [ i ] - b [ i ] - x; var borrow = 0; while (x < 0) { x += (1<<D); borrow++; } r [ i ] = x % (1<<D); x = borrow; } return r; } function div64s(a, b) { var x = 0; for ( var i = L-1; i >= 0; i--) { x = a [ i ] + x * (1<<D); a [ i ] = (x / b) | 0; x = x % b; } return x; } function copy64(a, b) { for ( var i = 0; i < L; i++) { a [ i ] = b [ i ] ; } } function shiftL64(a) { const msb = [ 0, 0, (1<<(D-1)) ] ; var d = a; var r = 0; if (cmp64(a, msb) >= 0) { r = 1; d = sub64(a, msb); } var c = add64(d, d); copy64(a, c); return r; } function div64(a, b) { var d = new64(0); var x = a.slice(); var r = new64(0); for ( var i = 0; i < L*D; i++) { var bit = shiftL64(x); shiftL64(d); d = add64s(d, bit); var y = 0; if (cmp64(d, b) >= 0) { d = sub64(d, b); y = 1; } shiftL64(r); r = add64s(r, y); } return r; } function parse64(s) { const l = s.length; var a = new64(0); for ( var i = 0; i < l; i++) { a = mul64s(a, 10); a = add64s(a, parseInt(s.substr(i, 1), 10)); } return a; } function print64(a) { var s = "" ; var x = a.slice(); while (cmp64(x, new64(0)) !== 0) { s += div64s(x, 10); } if (s === "" ) { s = "0" ; } console.log(s.split( '' ).reverse().join( '' )); } function divisors(a, x) { return add64s(div64(a, x), 1); } function solve(a, b, x) { return sub64(divisors(b, x), (cmp64(a, new64(1)) >= 0 ? divisors(sub64(a, new64(1)), x) : new64(0))); } function main(input) { const args = input.trim().split( ' ' ); const a = parse64(args [ 0 ] ); const b = parse64(args [ 1 ] ); const x = parse64(args [ 2 ] ); const c = solve(a, b, x); print64(c); } main(require( 'fs' ).readFileSync( '/dev/stdin' , 'utf8' )); まとめ ゆるくて多様なプロコン部で、新しいプログラミング言語に触れながら、業務ではなかなか体験できないアルゴリズムの知識を（時にはつらいけど）楽しく学び合っている様子をご紹介しました。 現在、BIGLOBEは在宅勤務が中心となっていますが、もともとインドア派の部活だったプロコン部の活動はインターネットのおかげで問題なく継続できています。インターネット最高！ そんなインターネットを支えるソフトウェアエンジニアを募集しています。プログラミングもインターネットも大好きな方に、ピッタリの職場です。オンラインではありますがカジュアル面談を実施しています。どうぞ気軽に遊びにきてください。 hrmos.co

ビッグローブ株式会社　執行役員　基盤本部　副本部長　高宮　展樹 はじめに 　コロナ禍で急激な在宅勤務やオンライン授業へのシフトなど、生活環境が一変しステイホームが続いておりますが、みなさまいかがお過ごしでしょうか？ 　BIGLOBEも4月より在宅勤務を基本とする勤務体制にシフトしています。 在宅勤務体制に先立って、社員のみなさん全員が在宅勤務できるようにリモート接続のためのVPN装置の緊急増設や、全業務の在宅勤務下での影響の洗い出しなどを準備し、現状9割の業務が在宅で継続実施できている状況です。 　のこり1割も全社プロジェクトを立上げて改善のプロセスを回し始めています。 　このようなステイホームへのシフトにより、ご自宅での快適なインターネット接続環境ニーズの高まりを受け、固定ISP接続サービスもご好評いただいております。 　本日は、「QCDをバランスさせるISPネットワーク基盤運営」と題して、BIGLOBEの固定ISP接続サービスを支えるISPネットワークのお話をさせていただきます。 はじめに BIGLOBEのISPネットワーク運営 1. Quality First：快適なネットワーク品質提供 2. Cost performance：コスパ重視 3. Delivery：内製開発 BizDevOps チームによるQCDバランシング BizDevOpsを支えるネットワークエンジニア まとめ BIGLOBEのISPネットワーク運営 　BIGLOBEは長年ISPとしてネットワークの設計・構築・運営を実施してきました。その中で、お客さまのインターネット・トラフィックは年々増大しています。以下は、総務省の国内トラフィック増加推移のグラフですが、 ①ブロードバンド契約者の総トラフィックは毎年増加傾向にあり、かつ②1契約あたりのトラフィックも同じく毎年増加していることが見て取れます。 図① 我が国のブロードバンド契約者の総トラフィック 図② １契約当たりのトラフィック推移 ※出典：総務省 「我が国のインターネットにおけるトラヒックの集計結果 （2020年5月分）」より抜粋 https://www.soumu.go.jp/main_content/000699741.pdf 　この傾向はISP接続サービスを提供しているBIGLOBEでも同様です。 　これは、インターネットがみなさまの生活のさまざまな場面で活用されている現れであり、ISP事業者としてとても嬉しく思います。しかし、ネットワーク基盤を担当するエンジニアの立場では、この日々増大していくトラフィックへの対応は、とてもとても大変なことなのです。 　私たちは、この増大していくトラフィックに対して、 　　・お客さまにご提供する快適なネットワーク品質を維持しつつ（Quality） 　　・新製品・新技術・新機能をタイムリーに導入することでネットワークを増強し（Delivery） 　　・増加するトラフィックに対して永続的にコスト削減を達成する（Cost） ことを通じて、ISP接続サービスをみなさまにご提供しています。 　BIGLOBEネットワークでは、このQuality、Cost、Delivery をどのようにバランスさせているかを以下にご紹介します。 1. Quality First：快適なネットワーク品質提供 　ISPのお客さまに提供する快適なネットワーク品質を維持することは第一優先（Quality First）です。快適なネットワークをご提供するために、ネットワークシステムの冗長性・対障害性・セキュリティ対応をしっかり実装した上で、日々増加するトラフィックに対して十分なネットワーク容量を確保しています。 2. Cost performance：コスパ重視 　Quality を確保しつつ、毎年増大するトラフィックに対してコストダウンしつづけるには、ISPネットワークを、よりコスパ良く増強する必要があります。企画・設計・構築・運用のすべての観点でコスパ重視を実現する施策を立案して実施するプロセスを回す必要があります。 　具体的には、より帯域単価が安い回線への乗換、よりポート単価が安い製品の導入、さまざまなコンテンツ事業者との接続性の確保などを常に実施しています。 3. Delivery：内製開発 　快適なネットワークをどのようにコスパ良く実現するかは、ネットワーク・エンジニアの腕の見せ所です。コスパが良いルータ・スイッチなどの新製品、お客さまの快適なネットワーク環境を実現する新技術などをエンジニア自ら内製開発で迅速導入し、コストと快適性の両立を図ります。 　一般的には、QCDは相反する傾向にあり、QCDのバランスを取ることが重要になります。 　　・ Qualityの高いネットワークを設計するには高いコストが必要となる 　　・ コストを下げるとDeliveryが遅くなる 　　・ 色々な機能を迅速に導入しようとすると、開発・運用コストが高くなる 図 QCD 　このお互いに相反するQCDをバランスよくネットワークに取り込むために、BIGLOBEでは、BizDevOpsを導入しています。 BizDevOps チームによるQCDバランシング 　BIGLOBEでは、ネットワークチームをBizDevOpsで運営しています。 図 BizDevOpsネットワークチーム体制 　BIGLOBEではネットワーク設計と構築、運用部門を分離せずに1つのチームとしています（BizDevOps）。これによりネットワークのQCDに責任を1つに集約させることで、QCDのバランスをとる権限を集約させています。 　BizDevOpsにより、インフラ企画から設計・構築・運用までカバーすることで、より上位フェーズにフィードバックが効き、QCD効果が最大化します。 　つまり、Qualityを設計フェーズで作りこみ、その設計された構成要素をより高いコスパ（C)を実現する新技術・新製品で構築し（D）、運用します。1つのチームで、BizDevOpsを回すことで、QCDのバランスが自然に取られてきます。 　チーム内のネットワークエンジニアの皆さんは、新製品、新技術を自らの眼で見極め、自ら手を動かして（内製）、評価し、構築し、運用します。少しでも自分の設計・構築に不十分なところがあれば、運用フェーズで障害という形で自分に返ってきます（フィードバック）。このような下流で起きる障害を未然に防ぐために、より上流の設計や構築に改善のフィードバックを自ら実施することで、QCDのバランスが整っていきます。また、Q,Cは全社組織から定量的にしっかりチェックされる体制があり、こちらもBizDevOpsにフィードバックされます。 　このように BizDevOps ネットワークチームが、日々増大するトラフィックに対して新技術によりQCDのバランスを達成し続けています。 BizDevOpsを支えるネットワークエンジニア 　1つのチームでBizもDevもOpsも担う訳ですが、これはエンジニア一人ひとりにも当てはまります。自ら、事業課題をどうすれば改善できるか、日々悩み、アイディアを出し合い、有望な施策をトライし、商用環境に導入し、運営していきます。 　全国規模のネットワークに対して、このような活動を進めていくと、各エンジニアの皆さんはすごい勢いで成長していきます。 　時には難題に行く手を阻まれて出口が見えない様子のエンジニアもいますが、さまざまな技術を駆使しチームで難題を解決していきます。エンジニア個々人もその過程でぐんと成長しています。 　１つの事例としてNAT64/DNS64プロジェクトを以下の記事にてご紹介します。 style.biglobe.co.jp 　本プロジェクトは、若手社員5名のチーム自ら、技術企画・検証（Biz）から商用に向けた設計・構築（Dev）を経て、実運用（Ops）まで内製にて実施しており、固定接続サービスに対して世界で始めてNAT64/DNS64を導入し、お客さまにお手間をかけることなく快適・安価なIPv6アクセスを幅広く提供できた事例になります。 　このようにネットワークエンジニア一人ひとりが、品質とコストのバランスを取りながら最先端の技術を活用し、顧客視点のベネフィットを生み出しています。 まとめ 日々トラフィックが増大していくインターネットですが、BIGLOBEではBizDevOpsによるネットワーク運営により、QCDのバランスが取れた快適なネットワークをお客様に提供し続けています。 BizDevOpsチームでQCDのバランスが取れるのは、運用フェーズから企画・設計フェーズへの迅速なフィードバックが最適化を促すからです。 BizDevOps はエンジニアの成長も加速させます。

はじめまして！ 基盤本部 クラウド技術部 エキスパート の 穂積 裕樹です。 BIGLOBEでは、CoE（Center of Excellence） 1 を組織し、2019年度からクラウド利活用を全社的に推進しています。 私はそのCoEで、今年度からトレーニングを担当しています。 with コロナ時代で働き方がオフィス中心からリモートワーク中心になったように、トレーニングも、対面を前提としないやり方に修正する必要がありました。 BIGLOBEでは、参加者全員がリモート環境で社内ハンズオンを開催しましたので、そのノウハウをご紹介します。 社内ハンズオンの概要 ハンズオンをリモート環境で実施する上での課題 工夫①　参加者が自分のペースでハンズオンできるようにした 工夫②　質問しやすい環境をつくる 最後に 社内ハンズオンの概要 BIGLOBEで開催している社内ハンズオンの概要は下記表にまとめました。 開催頻度 月に1回 時間 2時間～2時間半 内容 毎回いくつかのサービス（EC2やECS,VPCなど）をPickUpしてハンズオン実施 参加人数 20～30人 参加者の技術レベル これからクラウドに触り始める初心者がメイン 費用負担 CoEが予算確保 また、BIGLOBEでは数あるクラウドサービスの中でも、Amazon Web Services（AWS）を選択しています。 ハンズオンに必要なAWSアカウントの払い出しや最低限のセキュリティ設定は、CoEが実施しているので、初心者でも気軽に安心して参加することができます。 ハンズオンをリモート環境で実施する上での課題 リモート環境で社内ハンズオンを開催するにあたって、以下の課題がありました。 １. 参加者の学習ペースが把握できない これまでは目の前に参加者がいたため、学習ペースや様子が一目で把握出来ました。そのため、作業が完了していない参加者が多ければ、作業時間を延長するなどの対応ができました。また、手が止まっている参加者がいればすぐにフォローすることも可能でした。 しかし、リモート環境になると、参加者の学習ペースや様子を把握することが困難になり、参加者に合わせたペース調整やフォローが不足し、結果として内容についていけなくなる参加者を生み出します。 ２. 質問しにくい 質問したくても、他の参加者に聞かれることを恥ずかしく感じたり、自分が質問したせいで他の参加者の時間を奪ってしまうのではないかと思い、質問できない参加者が多いです。これまでであれば、参加者同士で解決したり、作業中にこそっと講師に質問することが可能でしたが、リモート環境ではそれが難しくなりました。 　これもまた、結果として内容についていけなくなる参加者を生み出します。 クラウドのサービスは数多くあり、次々に新たなサービスが生まれるため、一度トレーニングを受ければ十分というものではありません。 クラウドを利活用するためには、継続的なトレーニングが必須です。 社内ハンズオンはクラウド初心者が多く参加し、はじめの一歩に近いトレーニングです。 そのトレーニングで躓くことは、今後のトレーニング意欲にも大きく影響すると考えます。 そこで、是が非でも、多少の労力を投じても、これらの課題を解消するため、いくつかの工夫をしました。 工夫①　参加者が自分のペースでハンズオンできるようにした 通常、講師がいて、その説明を聞きながら参加者がハンズオンを進めます。 しかし、BIGLOBEではハンズオン資料とその解説動画（ハンズオンの実演含む）を準備し、参加者はそれを参照しながら、各自のぺースでハンズオンを実施するようにしました。 つまり学習ぺースのコントロールを講師側がするのでなく、参加者自身に委ねました。 これにより、参加者は分からない箇所を理解できるまで繰り返し動画を視聴するなど、内容理解をより深めてから進めることが可能になりました。 さらに、資料と解説動画があれば、当日に参加出来なくても、各々の空いている時間でハンズオン可能になったのは、良い副次的効果です。 有識者のフォローが不要な人はそれで十分だと思います。 とはいえ、遅れている参加者のフォローは必要です。 そのため、参加者自身にスプレッドシートで進捗状況を共有してもらうことで把握し、そこで遅れがあれば、個別フォローを実施します。 ただし、この工夫の難点としては解説動画の準備が大変であるということです。 資料の説明だけではなく、ハンズオンの実演も撮るのは非常に時間が掛かります。 この点に関して、BIGLOBEで良く使われるAWSでは、AWS公式のハンズオン資料と解説動画ありますので、それを活用しています。 様々なAWSサービスのハンズオン資料が公開されているので、是非一度試してみることをおすすめします。 ハンズオン資料の公開URLは下記になります。 https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/ 工夫②　質問しやすい環境をつくる 質問専用チャットを作成して、他の参加者がいないクローズドな環境で質問できるようにしました。 有識者がハンズオン中ずっとそのチャットに待機して、質問がある参加者はそのチャットに移動して質問し、タイムリーに回答を得ることが出来る環境を整えました。 また、クローズドな環境であることは、参加者だけでなく、有識者側にもメリットがあります。 多くの参加者の前で回答するというのは、有識者側にもプレッシャーを与えています。 クローズドな環境がこのプレッシャーを軽減することで、有識者として参加することへのハードルが下がり、協力してくれる人が増えました。 これにより、当初社内ハンズオンに参加する側だった人が、何度も参加することで経験を積み、有識者として教える側にまわるというサイクルが生まれやすくなっています。 最後に 以上が、社内ハンズオンで実施している工夫の紹介でした。 繰り返しになりますが、クラウドは次々に新たなサービスが生まれ、その進歩についていくためには、継続的なトレーニングが必須です。 そのトレーニングを、各自の努力にだけ任せていると、全社的な技術力向上にはなかなか結びつきません。 ひいては、クラウド利活用推進が進みづらくなります。 そのため、自社内で組織的にトレーニングを提供することが非常に重要と考えています。 今後も、社内ハンズオンだけでなく、システムのトラブルシュートコンテストをするゲームデイや、一日でサービスを作るハッカソンなどの新たなトレーニングメニューを提供し、技術力向上とクラウド利活用推進に貢献していきます。 最後にお知らせをさせてください。 本ブログを見て、BIGLOBEに少しでも興味を持っていただいた方がいらっしゃれば、是非一緒に働いてみませんか？ BIGLOBEでは、最新技術を学び、それを使ってサービスを支えたいエンジニアを大募集しています。 興味のある方はぜひカジュアル面談にいらしてください。 hrmos.co ※ Amazon Web Servicesは、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。 　注力する領域のリーダーシップやサポート、トレーニングを提供する横断組織。ノウハウや人材を横断組織に集約することで、より強力な推進力やコミュニケーション向上が期待できる。 ↩

こんにちは、BIGLOBEモバイルの開発をしている大橋です。普段の業務では、Javaを使って契約管理システムなどの開発をしています。 コロナ禍で大変な時期ですが、一緒に働いてる人たちとオンラインで開発合宿をしました。合宿というと、宿泊施設などに集まって実施することが一般的かと思います。しかし、コロナ禍の現在の状況では、そのような形式で合宿を実施するのは難しいです。そのため、今回はオンラインで集まって丸一日、黙々と開発するような形で実施しました。 オンラインでの合宿は初めての試みでした。まずはやってみることが大事だと思い、こんな風にやってみようと決め実践したところ、上手くいったので紹介したいと思います。コロナ禍で合宿をやってみたいけど、どうやったらいいか困っている人たちのお役に立てたらと思います！ システムを改善したい コロナ禍での開発合宿 朝一集合 各自作業 定期的に全体で集合する 最終集合 オンライン合宿をやってみて システムを改善したい 私が担当しているBIGLOBEモバイルのシステムでは技術的負債が溜まっており、必要ないアラームを上げてしまっていたり、自動復旧できない部分があったりとシステムに課題がたくさんありました。その結果、運用作業に工数がとられて、開発に集中できなくなっていました。 このような状況を変えたいと思っているものの、通常業務の片手間では、時間が取れません。そこで、一気に負債を返すための改善活動を集中してやろう！ということになりました。 コロナ禍での開発合宿 本来であればみんなで同じ場所に集まって開発をしたかったのですが、新型コロナウィルスの感染を避けるため、オンラインで合宿を行いました。 合宿の参加人数などは以下の通りです。 参加人数：7人 全体で使った時間：8時間程度 作業場所：各自の自宅 使用した通話ツール：Google Meet 当日の朝みんなで集まってから流れを考え、合宿を進めました。集中できる個人作業の時間はとりつつ、作業に遅れや困っていることがあったら早めにフォローできるような体制を作ることとし、以下のような流れでやってみました。 朝一集合 各自どんなことをやるか予め決めてから集合し、合宿中に何を終わらせるか宣言する 参加者の経験値にばらつきがあったので、不安な人はペアで進めるか、個人で集中して作業したい場合はソロで進めるなど体制を決める 次回の進捗確認のために集まる時間を決める 困ったときに質問できるGoogle Meetを作る いつでも質問できる状態にしておくために、個人で作業を進めている人は入室しっぱなしにする 各自作業 ペアプロでやる場合は以下のように実施(私はペアプロで進めました) Google Meetを使って画面を共有し、ドライバーがコードを映すことで2人で同じ画面を見る ドライバーとナビゲーターを決め、音声通話で話しながらコーディングを進める 詰まったら適宜、質問用のGoogle Meetで相談する 定期的に全体で集合する 進捗報告、あれば困っていること、次の集まりまでにどこまで進めるかを話す 進捗が遅れてる人は、ヘルプを求める やることや進捗に合わせて、集まりの最後に次回の集合時間を決める 朝決めた開発や評価がある程度終わった時点で、最終集合の時間と合宿終了時間を決める 最終集合 残作業の確認 今日中にどこまでやるか確認 合宿の最初に集まったときに、「対応不要なアラームを上げないように改修する」、「リトライ機能を入れて自動復旧する」等各自でどういった改善を行うかを6つ決めました。 その後は個人またはペアで作業を進め、進捗に遅れがないかを定期的に集まって確認していました。時間を決めて定期的に集まることで、全体として進捗が遅れることなく開発を進めることができました。 また、合宿形式で改善活動だけをやると決めていたので、他の業務の横やりもなく、開発に集中することができました。 その結果、決めていた6つの改善を実現できました。対応不要のアラームが減り、不要な調査の手間も削減されたことで、今よりも少しだけ開発に集中できる時間を増やすことができました。 オンライン合宿をやってみて オンラインでの合宿で成果が出るか不安でしたが、手探りでやってみて、成果を出すこともでき、とても満足のいく結果となりました。 オンライン合宿ならではの工夫は、定期的に集まって進捗報告をする、常に誰かが答えてくれる質問専用のGoogle Meetを設けるといった、コミュニケーションにまつわるものです。 対面であれば、他の人の作業の様子が見えるので、気軽に話しかけられると思います。しかし、リモートだと様子が見えないので、他の人の作業の進み具合が読み取りにくく話しかけていいタイミングが分かりません。 また、直接話しかけることができなく、作業に集中しているとメッセージなどを送っても反応が遅れることがあり、リアルタイムでの返答が難しい状況です。加えて参加者はそれぞれ別の作業をしており、最終的な成果物も違います。そのような状況で、自分の作業で詰まっているところを他の人に質問するのは気が引けてしまうものです。 上記の課題を解決するために、時間を決めて定期的に集まることで他の人の進捗を見える化したり、いつでも質問できる・答えてもらえる環境を整えることで、安心して開発することができました。普段行っているオンライン開発も同様ですが、合宿という特殊な状況であっても、安心して質問できる場は重要であると実感しました。 初めてやったオンライン合宿ですが、効果は十分にあったと思っています。この状況に負けず、これからも楽しく開発をしていきたいと思います！ ※ Googleは、Google LLCの商標です。

基盤本部 副本部長 大縄 陽一です。 在宅勤務が増え、家庭にいる時間が長くなったので、ふと思い立ち、家の庭にきゅうりを植えてみました。きゅうりは芽を出すとグングン育ち、ほとんど知識も無く、世話をしていない私でしたが、大きな実が１つ、すぐに出来ました。 「おぉ、これならば20～30個くらいすぐに収穫出来ちゃうんじゃないか？」と期待。しかしながら、その後さっぱり実がデキません。よく見てみると、花は沢山咲いて、実の赤ちゃんの様なものが沢山できましたが、その実は大きくならずそのまましおれていたのでした。 最初にできたきゅうり 茎や葉が繁茂しすぎで しおれたきゅうり 　YouTube等できゅうりの育て方、収穫方法を確認。自分の庭のきゅうりをよく調べてみると、葉っぱや茎が複雑に重なり合って、枝分かれした先でもたくさんの新しい葉っぱや花が生まれているので、そちらに養分がとられて、きゅうりの実まで栄養が回らないようでした。 「そうか、実を太らせるには、ある程度太い茎に絞って、しっかり太らせる花と実を選択して、余分な茎、葉や花を除いてあげる必要があるのか！」ということに気づきました。 「はっ！」と思い当たりました、「これは2025年の崖問題と似ている！」と。なんのこっちゃと思われるかもしれませんが、たくさんの枝分かれした茎がこれまでのサービス拡大の歴史、そして構成する葉やつるが繁茂し、絡み合って何がなんだかわからない様子は、私には複雑に構成されたシステムと、ブラックボックス化したプログラムコードのカオス状態に似ている！と感じたのでした。 　「2025年の崖」とは、ご存知の方も多い事と思いますが、経産省から2018年9月に発表された以下レポートです。レガシーシステムの維持保守が足かせになり、IT産業の競争力低下による経済損失のリスクに警鐘を鳴らしたものです。 DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省） 　BIGLOBEでは、25年前にインターネットサービスを開始し、お客様が増えてきた2000年あたりから、SOA（Service Oriented Architecture）思想で設計した業務システムを具現化し、開発とサービス運営をしてきました。 当時の論文 。 　このアーキテクチャにより、業務のロジックはC（Controller）層に、画面インターフェースはV（View）層に、共通汎用コンポーネント（会員、契約ほか）はM（Model）層にと、しっかり役割を分離してシステム開発を効率的に行えるようにしました。 　しかしながら、20年の間にBIGLOBE事業の範囲も大きく広がり、商品の多様化、販売チャネルやキャンペーン・手数料の多様化、お客様とのリレーションの多様化（様々な顧客の契約状態で、様々な顧客接点でのインターフェース要件が多様化）していき、C（Controller）層、M（Model）層で多くのAPIが作られ、それらの開発、運用知識を持つ社員、パートナーメンバーの高齢化、離脱によってブラックボックス化が進んでいます。 　よって、ブラックボックス化したAPIを、拡張性があり、メンテナンス性の良い新たなAPIに切り替えていくことが必要です。これによって、独自言語、既存システムノウハウの呪縛から解放され、オープンな言語、クラウド技術の活用による開発へ切り替える事ができます。これを具体的に実行するため、現在行われている業務の洗い出し、システムの棚卸を行う必要があります。業務もブラックボックス化されているからです。ただ、「言うは易く行うは難し」でして、これを実現するために、我々は以下の3点に取り組んでいます。 １．エンジニアの獲得と育成 　何をするにも、人が重要！社員が主導しなければ物事進みませんので、2018年度の中期計画で、情報システム系エンジニアの内製化比率を大幅に増加することを提言し、経営幹部に承認をいただき、現在推進中です。これを加速させるため、システム部門内に人財獲得、育成をミッションとする専門組織を立ち上げ、人事部門と協力しながら、スカウトや社外発信（このTechBlogもその組織で立案、立ち上げました）を進めています。 　また、育成についても日々試行錯誤をしながら取り組んでいます。習うより行動とアウトプットを重視して取り組んでおり、社員の自主的な活動を推奨（開発合宿、リモートワーク、各種勉強会の開催）し、クラウド関連の教育カリキュラムを作って実施をしています。 ２．品質課題の改善 　お客様に対して、サービスが長時間停止したり、誤課金や誤請求を行うような障害は事業継続上のリスクですし、何より技術者として面目ない、という気持ちになります。 また、脱レガシーのパワーを生み出すためにも、障害対応や品質課題に時間を取られないようにしなければならないと考えています。 　BIGLOBEでは2年前より全社横断での品質改善PJ（ゼロPJ：品質事故ゼロを目指す）が発足し、専門組織である業務品質管理部を要とし、全社の兼務メンバーをアサインして、各部門で品質改善の取り組みを強化してきました。結果、昨年度下期から障害件数が大きく減少しております。併せて、業務の見える化が進んだことで、業務の複雑さが品質課題の根底にある事も全社認識されました。今後の改善の方向としては、対症療法ではなく、業務の複雑さを取り除く根本解決を目指しています。 ３．レガシーシステムの改善 　最後に、本丸のシステム改善ですが、基本的にはAmazon Web Services（AWS）やSalesforceといった実績あるクラウドの機能を最大限活用し、システムの再構築を進めています。ただし、現状の機能や業務ロジックをそのまま全て移行するのでは、繁茂して手入れをしていない、きゅうりを植え替えるようなもので、移動先でも多くの実を収穫することは期待できません。よって、業務やサービスの整理を事業サイドのメンバーと一体で行い、APIやシステムの責務の整理、再構築を進めようとしております。現在はキャンペーンの企画から実施までのリードタイムを大幅に短縮することを目指し、営業部門と技術部門でPJを作り、業務プロセスや、実装のパラメーターを整理しています。まさに、不要な枝葉を整理し、大きな実を実らせるための活動です。 　さらに、主力の接続回線やオプションサービスの販売システム、これを支える会員や契約の共通コンポーネントの刷新に手を入れていく計画ですが、このテーマは、システム部門だけで考えてもダメな事なのです。事業の戦略とそれに伴うシステムのアーキテクチャを一体となって検討、共感、合意して進めていく必要があります。現在中期計画で、サービス企画部門も交え、このテーマを真剣に議論中です。BIGLOBEはこういった全社横断テーマを議論できる風通しの良い会社なんです！（長いことかかりましたが）。これができたら、2025年の崖を越えて、2030年への橋が出来上がる、と期待しています！ 今後のBIGLOBEの発展に技術の力で貢献する！組織を目指しています。 あなたも参加してみませんか！ hrmos.co ※ YouTubeは、Google LLCの登録商標です。 ※ その他会社名、各サービス名は、一般に各社の商標または登録商標です。

こんにちは。BIGLOBE 黒川です。 ビッグローブ光、BIGLOBEモバイルをはじめとした、サービスの企画を担当しています。 今回は、BIGLOBEがお客様へサービスをご提供するまでのプロセスと、そのなかでも特に重要と考え、実践している事を紹介させていただきます。 サービス開始までのプロセス概要 サービスプロセスまでも創り上げる お客様視点でのユーザビリティテスト 積極的にドッグフーディングする サービスに活かしたドメイン駆動設計 まとめ サービス開始までのプロセス概要 BIGLOBEでは、サービスを企画して開発しお客様へご提供するまで、以下の流れで進めています。 それぞれのフェーズ毎に判定のポイントで、関係者がしっかりと成果物のチェックを行い、確認しながら次の工程へ進め、サービスをリリースしています。 ＜サービス化プロセス＞ はい、由緒正しき典型的なウォーターフォール型開発プロセスです。 生い立ちが製造業だっただけに、意外とこれがしっくりしていて、各部門が連携してサービスを創りリリースしています。 特徴は、自工程完結型でそれぞれの工程での成果物をしっかりと共有しINとOUTでチェックすることを徹底し、齟齬のない進め方に取り組んでいるところです。 スピードが求められる現在では、仕様を決めたり変更の相談をしたり、方針を決めたり、場合によっては経営判断で方向転換したりと、状況変化に臨機応変に対応しなければなりません。 また、チャットやオンラインミーティングなどのコミュニケーションと伝達手段も様々で、コミュニケーションロスが発生する懸念もあります。 ですが、最終的に決定した事項を、次の工程に渡す時に情報が古かったり、ブレてしまうと、結果的に求められたモノとは異なるサービスになったり、後戻りでリリースのスピードが遅くなったりします。 そこで、各工程で決定したアウトプットは関係者でしっかりとレビューして承認する、というプロセスに重点を置いているのです。 著しく変化する市場変化への追従や、不確実性への対応のためアジャイル開発の有効性も認めており、一部の開発や技術部門が自発的に生み出すクリエイティブなサービスではアジャイル開発も実践しています。 また、新しく作るインフラ周りのデプロイやシステムテストなどは、 継続的インテグレーション / 継続的デリバリー（CI/CD）を積極的に取り入れ 信頼性向上や効率化も推進しています。 光コラボサービスや、移動体通信事業者（MNO）から回線を借用して提供するMVNOサービスなど、サービスリリースの時期と品質の確実性が求められる案件や、品質やリリースのスケジュールが重要とされる新規のサービス開発では、まずは基本に立ち返ってウォーターフォール型でのプロセスにより、事業性においてもブレないように、取り組んでいます。 サービスプロセスまでも創り上げる BIGLOBEでは、こういったサービス企画、開発のプロセスも、社員が過去の経験や大規模プロジェクトなどの実績に基づき、工夫しながら組み立てています。 社外で大規模プロジェクトを通じて標準化されたプロセスを経験し、そのスキルを活かして、 新しいサービスにチャレンジする為に帰ってきた社員 や、 大手キャリアでグローバルのサービスの根底となる国際標準化に携わった経験者 が集結して、このようなプロセスを作り上げるとともに、ワクワクしたサービスが創出できるように、各部門が協力しあって、日々、企画、開発、プロセス改善に取り組んでいます。 お客様視点でのユーザビリティテスト このサービスを創ってご提供するまでのプロセスで、私がもっとも重要と考え、注力しているのは、ユーザビリティテストです。各工程でチェックし品質を保ちながら、企画通りにモノ、サービスができても、本当に要求側の意図している通りに出来ているのか、それがお客様に受け入れられる品質なのか、新しいネットワークサービスの場合は遅延やタイムラグはどうか、QoE（Quality of Experience：体感品質）が想定通りか、社員自らがお客様の視点になって、チェックすることをプロセスに組み込んでいます。 ユーザビリティテストは、単にOK、NGを判断するだけでなく、ネットワーク技術部門へのフィードバックを行うことで、ネットワークのチューニングにも活かし、最終的により良いサービスがご提供できるようになっているのです。 積極的にドッグフーディングする もう一つ、積極的に実践していることに「ドッグフーディング」があります。 ドッグフーディングという語源の由来は諸説ありますが、概ね、 自社のサービスを日ごろから利用して問題の発見や改善を立案する βテストやリリース前のサービスを社員がトライアル的に使用して、品質やユーザビリティの確認を行う ということを目的に実施されています。 このドッグフーディングは、私も重要視していまして、BIGLOBEのサービスを日常的に使っていくことで、細かい改善点を発見したり、新しいサービスの企画やアイデアにも活かせるというメリットを実感しています。 私自身も、普段のスマホだけでなく、週末のドライブにAndroid™ OS搭載のカーナビでBIGLOBEモバイルの エンタメフリー・オプション を楽しむドッグフーディングを実践しています。 ここで、気づいたポイントやアイデアを、 企画担当者 と一緒にディスカッションしてゼロレーティングのユースケースの拡大や新しいアプリケーションを立案したり、よりよいサービスとなるようにフィードバックしています。 ＜私のドッグフーディング環境＞ また、BIGLOBEモバイルのサービスにおいては、新しいネットワークを設計、構築する際にこのドッグフーディングで多く成果を出しています。 単なる検証環境でのシステムテストだけでなく、お客様へご提供するネットワークをリリースする前に社員自ら、お客様と同じ使い方を日常的に利用することで、潜在的な課題、例えばスマホをタップしてからネットワークを介してインターネットコンテンツが表示されるまでのレスポンスタイムが著しく悪化している課題を発見したり、不測の不具合が生じた場合に、エンジニアがネットワーク切り替えを準備していた運用手順に従って、迅速に実施するという、「実践での訓練」というものが実行でき、結果的にサービス開始してからも、品質の維持に貢献できているのです。 サービスに活かしたドメイン駆動設計 サービスを開発するうえで、ソフトウェア開発部門が積極的に取り組んでいる開発手法に ドメイン駆動設計（DDD） があります。 インターネットサービスはもはや生活には不可欠で使われ方もニーズもどんどん変化し、光ブロードバンド、モバイル、WiMAX、WiFiとアクセスの多様化、課金モデルや料金プランの多様化、サービスの組み合わせによる割引特典、様々なオプションパッケージ、様々なキャンペーンと、サービスの追加、オプションの追加、料金施策など企画、開発の案件は複雑であり、システム設計、ソフトウェア開発と、とても時間と労力がかかります。 また、長年作り上げてきたシステムは複雑化し、それぞれの領域に分かれたサブシステムの機能を、これまた新しいサービスや施策実行のたびに、ソフトウェア開発しなければなりません。 お客様のニーズ、要求部門からのオーダーに対応するため、しっかりとアーキテクチャを考え、モデリングし作った設計資産をサービスに活かす、作ったソフトウェアを様々なサービスで貢献し価値を高める、ということにも意識し、コアとなる開発エンジニアが積極的に実践に取り組んでいます。新しく入った仲間が、すぐに実践ができるというサービス開発の環境も、皆で作っています。 まとめ このようにBIGLOBEでのサービスは、各部門の社員が一体となって、よいサービス、面白いサービスを創造するとともに、それを実現するためのプロセスや開発環境までも、皆で創り、お客様の視点で積極的に使って納得できるサービスをご提供しているのです。 ワクワクするようなサービス、ソフトウェア開発の実践、プロセス、環境を一緒に創りませんか！ ご興味がありましたら、是非、以下のリンクをご参照ください。 hrmos.co ※ Android は、Google LLC の商標です。

こんにちは、マーケティングプラットフォーム部のこばやし（eri-twin）です。 みなさんは 技術書典 をご存知でしょうか。 公式ページから引用すると、技術書典とは「新しい技術に出会えるお祭り」。 個人的に人に話す時には「技術書のコミケ」と説明しています。 エンジニアひとりひとりが持つ技術を、出版社を通さず個人で本の形にして、他のエンジニアに頒布するイベントです。 techbookfest.org   2020/9/12(土)の開催で第9回を迎える、技術書典。 今回はBIGLOBEとして技術書典に参加してきたこれまでの話と、これからの話を紹介します。   技術書執筆は心の飛躍！ BIGLOBEは第6回から技術書典に参加しています 技術書典9について   技術書執筆は心の飛躍！   自分自身が技術書典への参加、技術書の執筆活動を経験して、やって良かったな～と感じたことがたくさんありました。   自分の知識を整理・体系化するきっかけになる 勉強したいなら人に教えるのが一番の勉強になる、という言説がありますが、技術書の執筆はまさにこれに当てはまります。 理解していると思っていたことが、文章にしようとした途端に、全然言葉が出てきません。 なんて書いたら良いのかわからなかったり、かろうじて書いてみてもなんだか自信が持てなかったり。自分が理解していない部分を突きつけられます。 それと同時に、苦労してそれを書きあげたとき、その本は自分以外の誰かの役に立つかもしれない貴重な資料となります。 どんなニッチな内容でも（むしろニッチだからこそ）、技術書典で発表する価値があります。商業出版に乗らないような利用者の少ない技術の本を発表する場となる、それも技術書典のおもしろさです。   シンプルに、うれしい！ 例えばブログのようなオンライン上で書くのと最も違うことは、本という形になることです。 私の場合は、表紙のイラストや本文のレイアウトといった本文以外のところを社内のデザイナーさんに作ってもらっていたので、こうしたい！とお願いした通りのものがきれいに仕上がっていく過程は、見ていてワクワクが止まりませんでした。 特に、印刷して製本されたリアルな本を手にとったときの感動！これはきっと、実際に経験した人にこそ一番伝わるものだと思います。苦労して作り上げた本文や表紙が、りっぱな本の形になるのを初めて見るとき。印刷所から届いたダンボールにカッターを入れ、一冊を手に取るそのとき。それは、本当にうれしい瞬間です。 また、実際に技術書を頒布することで、こういう本が欲しかった、この本を読んで勉強します、といったうれしいお声がけをたくさんいただきました。自分の技術が誰かの役に立っている、それをリアルな声として実感できる。これはエンジニアとしての喜びにも重なる思いでした。 直接声を伝えてくれる方だけでなく、感想をTwitterでつぶやいてくれる方も多く、こっそり探してたりもします。感想のツイートを見つけたときは、とっても嬉しい気持ちで読んでいます！   BIGLOBEは第6回から技術書典に参加しています これまでに参加した第6回から第8回まで、BIGLOBEはどんな本を作ってきたのか紹介します！     第6回、最初に技術書典への参加のきっかけになったのは、社内のモデリング勉強会でした。 2年続いていた勉強会の蓄積を上司に見てもらったときに、この成果をまとめてみても良いかもね、という話になりました。 元々、私は個人で一般参加者の立場で技術書典に参加しており、いつかはサークル参加してみたいと淡い憧れを抱いていたところに 「この勉強会の内容を技術書典に出してみたら？」という一言に背中を押されました。 システム設計・モデリングの初歩の考え方をなるべくわかりやすく簡単な言葉で説明するというコンセプトで、モデリングの始め方、実際の成果物、また社内勉強会の進め方まで、モデリング勉強会を通して得た知見をまとめています。 メインの執筆は私が担当していますが、本の装丁デザインや校正に協力してくれた多くの社内有志メンバの力で成り立っている一冊です。   技術書典で本を頒布するのはこれが初めてだったので、社内でどんな手続きが必要かが分からず、いろんな部署に聞きまくることになりました。 社内的には、技術書典なにそれ？というところから始まりましたが、今ではこの活動にかける時間を業務時間として扱ってもらうこと、活動の成果を業績として認めてもらえています。 このあたりは、やりたい！と声をあげたら、活動の内容をしっかり見て判断し、成果になれば正しく認めてくれる、そんなBIGLOBEの寛容な風土のおかげです。     第7回は、メインライターを1年目の若手社員が担当し、 AWSソリューションアーキテクトアソシエイトの取得をテーマに日記風に執筆されています 。 BIGLOBEは古き良き(?)ネットワーク屋のイメージが強いと思いますが、第6回では影に隠れがちなアプリケーション開発の取り組みを、第7回では新技術へのキャッチアップとしてAWSを取り上げており、 BIGLOBEの現場が今どういうことをやっているか、ということも感じていただける並びになっているのではないかと思います！ 執筆担当は無事に資格試験のほうも合格を勝ち取っており、実績もある一冊です！資格勉強のお供にどうぞ！     第8回はオンライン開催となりましたが、新刊を電子版で頒布しました。 こちらはアンソロジー形式で、スクラム開発とDDD（ドメイン駆動設計）をメインテーマに7人のエンジニアが執筆しています。 この7人の執筆者たち、実は全員が中途採用でBIGLOBEに入社、いずれも入社から2年以内のメンバーでした。外から来てBIGLOBEのことを知り、かつこれまでに各々が異なる経験をしているからこそ書ける視点が面白いのではないか、ということで合同誌を作ることにしました。 メインテーマは全員共通としていますが、一方で切り口となるサブテーマは様々。AWS、Spring、ふりかえりや障害対応まで、みなさん前世（前職）の経験を活かした特色あふれる記事になっています。 余談ですが、執筆者が中途採用メンバということを活かし、本のコンセプトを異世界転生風にしています。内容・表紙デザインともにイチオシの本です！   技術書典9について 来たる9/12の技術書典9。BIGLOBEはサークル参加だけでなく、スポンサーとしても技術書典に参加します！ 今回も、これまでに紹介した本の頒布もありますので、ぜひご注目ください！