こんにちは。BIGLOBE Style編集部の吉田です。 BIGLOBEでは9月に約3週間のインターンシップを行いました！ 参加したのは、2名の学生（大学3年生と、大学院1年生）。どんな取り組みをして何を学んだのかインタビューをしましたので、インターンシップ最終日の成果発表会の様子と共にご紹介します。 最後には弊社受入側のインタビューもありますので、よろしければご覧ください。 インターン　大学3年　末續さん 末續さんが取り組んだカリキュラム BIGLOBEをインターン先に選んだ理由 インターンシップでの目標 インターンシップのカリキュラムについて ISPの基礎知識を習得、疑似ISP網の構築 BGPにおける経路制御の演習 IRRを活用した業務の体験 データセンターでのPNI接続と離線作業 ギャップに感じたこと インターンシップを終えて 発表を受けて幹部からひとこと インターン　大学院1年　真崎さん 真崎さんが取り組んだカリキュラム BIGLOBEをインターン先に選んだ理由 インターンシップでの目標 ネットワークエンジニアへの志望動機 インターンシップのカリキュラムについて DDoS攻撃の防御を効率化するBGP Flowspec技術を導入するための検証 データセンターでのPNI接続と離線作業 BIGLOBEならではの魅力 ギャップに感じたこと BIGLOBEの働く環境 インターンシップを終えて 今後に向けて 発表を受けて幹部からひとこと 受け入れ部門インタビュー ※撮影時のみマスクを外しています。 インターン　大学3年　末續さん 末續 時希（すえつぐ いつき）さん 長崎県立大学　情報セキュリティ学科　3年 末續さんが取り組んだカリキュラム ・ISP（ Internet Service Provider ）の基礎知識を習得、疑似ISP網の構築 ・ BGP（ Border Gateway Protocol） における経路制御の演習 ・ IRR（Internet Routing Registry）を活用した業務の体験 ・ データセンターでのPNI（ Private Network Interconnect ）接続と離線作業 BIGLOBEをインターン先に選んだ理由 大学のカリキュラムの一環です。ネットワーク基盤のセキュリティを研究していて、プロバイダーに興味があったので、いくつかある候補の中からBIGLOBEを選びました。せっかくの機会なので、東京で経験してみたいという気持ちもありました(笑)   インターンシップでの目標 1つ目は、この業界の具体的な仕事のイメージをつかんで取り組み方を学ぶこと。2つ目は技術的なレベルアップです。   インターンシップのカリキュラムについて ISPの基礎知識を習得、疑似ISP網の構築 オペレーションセンターへ出向いて ルーター を物理的に構築し、遠隔操作できるように設定を行いました。ホスト名の設定、AS番号の設定、インターフェースの有効化などです。 ルーターを触ったことがなかったので、全てが新鮮で楽しかったです。   BGPにおける経路制御の演習 通信経路を制御するBGPの特性を活かして、意図した経路制御を実現するのですが、ここはかなり苦戦しました。一緒にインターンを受けていた院生の真崎さんに助けてもらいました。   IRRを活用した業務の体験 IRRに関する業務の補助ツールをGAS（Google Apps Script）で開発しました。当初は登録情報を自動メンテナンスするツールの開発を予定していましたが、時間とスキルの兼ね合いでテキスト比較ツールの開発へ軌道修正しました。 GASと連携して結果ファイルをGoogle Chatに送信させる機能をつけることを目標として、自分で調べたり社員の方にアドバイスをもらったりして、やり遂げることができました。本当ならスプレッドシートで自動実行したり、結果を直接Google Chat上に出したりしたかったので、その点が少し悔やまれます。 良かったことは、IRRでの情報収集時に登録漏れを発見して修正できたことです。お役に立てて嬉しかったです。   データセンターでのPNI接続と離線作業 光ケーブルを差したり、不要となった光ケーブルをルーターから抜いたりと、実際に触れることができて貴重な体験となりました。 幹部の前で行った成果発表会の様子 ギャップに感じたこと ネットワークエンジニアは業界横断でのつながりが強く、 JANOG の場でもピアリング交渉をするなど、その能力やコミュニケーションスキルが必要だと知りました。僕が考えていたエンジニアのイメージとはギャップがあり、興味深かったです。 また、BIGLOBEは大きな企業というイメージでしたが、社員数も約550名と会社全体が見渡せるちょうどいいバランスの規模感だと感じました。   インターンシップを終えて 最初は緊張していましたが、温かく迎えてくれて嬉しかったです。どれも初めての体験で大変でしたが、とても楽しく取り組むことができ、掲げていた目標を達成することができました。 BGPや、苦戦した経路制御の仕組みも少しですが理解できるようになりましたし、データセンターで何を行っているかも知ることができました。ルーターを触ったことがなく、ツールの開発も未経験でしたが、今回のインターンシップを通じて技術的な成長を実感しています。 カリキュラムの中には、リーダーインタビューや新入社員研修に参加したり、BIGLOBEが参加している沖縄オープンラボラトリの話を伺ったりする機会もあり、多くの学びがありました。 新入社員から「やりたいことがあれば手を挙げれば可能だよ」などリアルな声を聞けたことや、沖縄オープンラボラトリの Model Driven Network DevOpsプロジェクト（ BIGLOBEと他企業が協業 ） の 話では、ネットワークの設計から運用自動化する仕組みを作るという、難しいけれど目標のために地道にすすんでいる過程を聞けたことが面白かったです。この経験は就職活動の大きな指標になりましたし、大学での研究テーマにも活かしたいと思います。 僕たちが普段あたりまえのように利用しているネットワーク。その裏側で働く人の取り組みや苦労を体験したことで、より多くの人にBIGLOBEのことを知って欲しいと思いました。 発表を受けて幹部からひとこと 今回のカリキュラムは、ネットワークチームの日々の業務が網羅されています。 まずインフラを企画して、手を動かして検証をし、それが動いたら設計構築をして、お客さまのトラフィックを乗せていきます。実際にデータセンターに出向いての検証作業、商用ピア回線の物理的な作業も実際に手を動かして構築していただきました。 運用フェーズの効率化のためのツール開発では、うまくいったこと、いかなかったことを洗い出して、では次はどうしようかと、常にPDCAをまわすという体験もされました。 この3週間の経験は、まさしくネットワークチームの日々の業務の縮図ですので、非常に経験値があがったのではと思います。自信をもって大学へ帰ってアピールしてください。 インターン　大学院1年　真崎さん 真崎 かれん（まざき かれん）さん 長崎県立大学大学院　地域創生研究科　情報工学専攻　情報セキュリティコース　1年 BGPのセキュリティに関する研究を行う。 真崎さんが取り組んだカリキュラム ・ISPの基礎知識を習得、疑似ISP網の構築 ・ BGP における経路制御の演習 ・ DDoS対策のための新しい技術 の検証、導入に向けた動作確認、実装課題抽出 ・ データセンターでのPNI接続と離線作業 BIGLOBEをインターン先に選んだ理由 ゼミの教授がBIGLOBEの方と知り合いだったことから、インターンへ参加できないかお願いし、実現に至りました。ちょうど3年の末續さんのインターン参加もあったので、タイミングよく一緒に参加させていただきました。 教授から、BIGLOBEは成長できるいい環境だと聞いていたことに加え、大学に訪問してくださった社員の方々から会社の紹介や、 NAT64/DNS64 などの話を聞いて、さらに興味を持ちました。それに、 びっぷる も可愛いですよね(笑)   インターンシップでの目標 1つ目は、ネットワークエンジニアとして将来働きたいと考えているため、具体的に働くイメージを知り、さらにはネットワーク構築、開発、運用に必要な技術を知ること。 2つ目は、BIGLOBEの企業理念や大事にしているマインド、働き方を知ることです。   ネットワークエンジニアへの志望動機 私は以前から「人の役に立ちたい」という思いが根底にありました。研究室配属で教授からゼミの紹介を聞いた時に、当たり前に使っているインターネットは生活に欠かせないインフラなのだという考えを知って、「そこに従事できたら多くの人の役に立てるのでは」と思ったんです。それをきっかけに、インターネット基盤セキュリティを学び、ネットワークエンジニアになりたいと思いました。   インターンシップのカリキュラムについて DDoS攻撃の防御を効率化するBGP Flowspec技術を導入するための検証 私が取り組むメインテーマは「DDoS対策をより良くしよう」です。 DDoS攻撃を検知したあと、攻撃対象ホストのトラフィック全てを遮断するのではなく、悪意のないパケットは遮断しないというきめ細やかなフィルタリングを実現するという BGP Flowspec の検証に取り組みました。まずは、商用ルーターをケーブルで接続し、OSPF （Open Shortest Path First） ・BGPの設定を行うなど環 境構築からはじめ、動作確認を行いました。 初めて触る ルーター や時間の都合もあり、結果的に確認項目全てをインターン中に検証することができなかったのが心残りですが、今後、疑似DDoS攻撃トラフィックを用意してフィルタリングを確認したいと考えています。 新しい技術の導入で、より快適につながる未来があるという手応えを感じると同時に、その先のお客さまを想像し、BIGLOBEの企業理念「つなげる喜び」を実感することができました。   データセンターでのPNI接続と離線作業 データセンターでの作業体験として、ケーブルの差し込み、光ケーブル端面清掃、タグ付け、誤接続防止のためのコンソールケーブル抜き差しによる作業対象機器の確認などを複数人での確認のもと行いました。 データセンターの概要や装置、運用についても教えていただき、その特徴や配線の違いを知ることができて大変面白かったです。 幹部の前で行った成果発表会の様子   BIGLOBEならではの魅力 外からでは分からなかったことですが、徹底した冗長化がBIGLOBEならではの特徴だと思います。1つのベンダでルーターを複数台用意するのではなく、ベンダ特有の不具合にも対応できるようにベンダ違いで用意しています。人数が多い会社だとマンパワーで復旧できると思いますが、BIGLOBEの規模だとそれが難しくなるので、対処に時間をかけずにお客さまに安心してご利用いただくための、最適な方法なのだと知りました。   ギャップに感じたこと 機器の設定だけではなく、機器の発注などの事務処理や、他の企業とのピアリング交渉もすること。また、モクモク作業だけではなく、複数の人とコミュニケーションをとりながら進めていくんだという発見もありました。そのため、教える、教わるという人とうまく情報を共有するスキルも必要になります。 また、ネットワーク業界は横のつながりを大事にしているので、技術的なスキルだけではなく、コミュニケーション能力や交渉力も重要なのだと知りました。   BIGLOBEの働く環境 今は在宅勤務の社員が多いためか、最初は職場が真っ暗で驚きました(笑) ISPは規模が大きいと想像していましたが、BIGLOBEはちょうどいい規模感ですね。隣の人が何をしているのかなど、全体が見渡せる中で働けるところがいいなと思います。 また、社員の方々は「質問があったら聞いてね」と声をかけてくれ、とても話しやすい環境です。新入社員との懇談では「自ら新しい技術を習得する姿勢が求められている」と聞き、やりとりの端々から挑戦を後押ししてもらえる雰囲気も感じました。   インターンシップを終えて 掲げていた目標は達成できました！ 一番の収穫は、インターンを通じてISPの魅力に気づけたことです。使うトラフィックの量が増えてもインフラコストを一定にするという「ID単価1.0倍」の方針、NAT64/DNS64、冗長化。それらの話から「絶対に止めない」という強い思いでお客さまの利点を追い求め、お客さまに寄り添ったネットワークをつくろうとしていることを知りました。私たちが携わるネットワークのその先にお客さまがいらっしゃるんだと実感する貴重な体験となりました。 新しい技術の導入やピアリング交渉によって高品質で快適な通信環境を目指し、安心してインターネットをご利用いただけるようにする。それが、ISPで働くネットワークエンジニアの魅力だと感じました。   今後に向けて 大学の共同研修の一環で、今回使った同じタイプの商用ルーターで規模の大きいネットワークの構築、運用を行う予定です。インターンの経験を100％活かせると思います！ ネットワークエンジニアに求められる姿勢やスキルを学ぶことができたので、その多くを身に着けて高品質で安心して使えるインターネットを提供できるネットワークエンジニアを目指したいです。 発表を受けて幹部からひとこと まさに、真崎さんが気づかれたとおり、ルーター同士をつなぐのが仕事ではなく、お客さまに快適にご利用いただけるようにすることが一番大切です。ネットワークのその先にお客さまがいらっしゃるという事に気づいていただけたことはとても意味のあることだったと思います。 そして、末續さんにも伝えましたが、このカリキュラムはネットワークチームの業務を凝縮したものです。新しい技術の導入を考えて、実際に実機で自分たちで検証してそれを本番に導入するという取り組みをしていただきました。今回検証しきれなかった内容も是非評価してみてください。導入できたら、さらなるお客さまとのつながりや喜びを実現できると思っています。   受け入れ部門インタビュー 今回の長期インターンシップを牽引した、受け入れ部門である基盤本部の今村洋文に話を聞きました。 基盤本部 ネットワーク技術部 ISPネットワークグループ グループリーダー 今村 洋文（いまむら ひろふみ） ―――　長期インターンを受け入れるにあたって、何か工夫したことはありますか？   外から迎えるということでお客さま的になってしまわないように、インターンとして実務を経験してもらうことを念頭におきました。そのため、取り組んでいただくテーマも実際のネットワーク運用において私たちが課題としている事項を設定し、実施しました。   ―――　お2人の最初の印象や、働きぶりはいかがでしたか？   末續さんは良い意味で学生らしい方だな、と思いました。 真崎さんはインターン前に函館で開催されたJANOGで一度お会いしましたが、落ち着いたしっかりした方という印象です。インターン初日の前夜は緊張でなかなか眠れなかった、と言っていたのを覚えています。 お2人とも、とても真面目に取り組んでくれました。 末續さんはツールの開発が思い通りに進まず、頭を抱えながらも懸命にPCに向き合っている様子が印象に残っています。その努力が報われ、ゴールの再設定を行いながらなんとか形となり、安心しました。 真崎さんは、既に大学院でネットワークやセキュリティに関して研究されているため、ネットワーク装置での検証にもすんなり取り組まれていました。インターン前半に実施した疑似環境の構築や検証・演習では、末續さんをフォローしながら進めてくれ、受入側としても心強かったです。 Flowspecの検証過程で不明点が発生した時は、自身で RFC（Request for Comments ）を確認した上で質問する姿勢に感心しました。   ―――　インターンを通して今村さんご自身への気づきはありましたか？   外から見るネットワークエンジニアの業務内容とギャップがあったというお2人の言葉が印象に残っています。会社によってエンジニアが行う業務範囲には違いがあると思いますが、比較的弊社はエンジニアの業務守備範囲が広く、やることも多いのでそのように映ったのかもしれません。 そして、1番の気づきは、2人の成果発表会を聞く中で、ネットワークエンジニアとして働くことの意義について再認識させられたことです。ネットワークの先にいらっしゃるお客さまに心地よく安心してご利用いただけるよう、今後も身を引き締めて取り組んでいきたいと思います。   以上、長期インターンシップレポートでした！   現在、BIGLOBEでは2024卒向けの新卒採用活動を実施中です。BIGLOBEに少しでも興味をもっていただけたらぜひ下記URLよりマイページ登録をお願いいたします。 ご登録いただいた方にはメールで採用活動についてお知らせいたします★ https://mypage.3050.i-webs.jp/biglobe2024/applicant/login/baitai-entry/entrycd/Style ※右下にございます「初めての方はこちら」より、新規登録をしてください。 www.biglobe.co.jp ※ Google、Google Chatは、Google LLCの商標です。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 BIGLOBEではスタッフ部門とエンジニアが協力して、社内業務を改善しています。試行錯誤を繰り返しながら何とか成功させた例として、QRコード、GoogleフォームとApps Scriptを活用して、備品の補充を簡単に依頼できる仕組みをご紹介します。Google Workspaceを利用している会社や学校ならすぐに取り込める仕組みですので、ぜひご活用ください。 新人エンジニアのスキルアップを狙ってはじめたこの取り組みですが、数々の失敗もありました。そこから得られたノウハウや、Apps Scriptを使いこなすための細かいテクニックまでご紹介していきます。 QRコードを使った備品の補充依頼 失敗からの学び 機能を絞ってとりあえずリリース 要求者との会話のキャッチボールを大切に 業務改善で仕事を楽しく Google Workspace / Apps Script のTips集 GoogleスプレッドシートでQRコードを作る Googleフォームの事前入力でフォームの数を減らす 回答に応じたセクション移動を再帰させ一度に複数の申請をする Googleフォームからの通知はやり方が2種類ある Googleフォームの項目と回答スプレッドシートの列をあわせる メールアドレスから氏名を取得して入力項目を減らす Apps Scriptでユニットテスト その他、Apps Scriptの便利なテクニック QRコードを使った備品の補充依頼 まず、完成した仕組みをご紹介します。文房具棚や複合機のそばにQRコードを掲示しています。 BIGLOBEでは社員にGoogle Workspaceが利用できるAndroid™のスマートフォンを配布しています。封筒やコピー用紙など備品が不足している場合にスマホでQRコードを読み取ります。するとスマホにGoogleフォームが表示され、備品の補充を依頼できます。 フォームが送信されるとその内容が即座にスタッフ部門のGoogle Chatへ通知され、スタッフが在庫から物品を補充します。 使ってみた方からは、嬉しい感想をたくさんいただきました。 備品の担当者をわざわざ探す手間が省けた 備品がすぐに補充されるようになった QRコードを読む体験が楽しい😊 ただ、一番のハードルはQRコードを読めるかどうかです。スマホの機種によって読み取り方が違うため、つまづいている人も多くいました。そこで、社内イントラブログで「普段、どうやってQRコードを読んでいますか？」と質問し、情報を集めて共有しました。 カメラアプリでQRコードを読むのが一番直感的 それができない機種では、Googleレンズを起動する カメラアプリから起動 ホーム画面のGoogleウィジェットから起動 ホームボタンを長押しして「QRコードをスキャンして」と話しかける Googleレンズを起動する方法 社内で「困ったらQRコードを読んでみる」という新しい体験が受け入れられてホッとしています。そして何より嬉しかったのが、スタッフ部門の喜びの声です。 不足品の巡回が不要になった 備品の使用頻度が記録されるので、文具棚に入れておくべき「標準品」を工夫できるようになった アイデアが形となり、仕事が楽になる経験を通じて、仕事をするのが楽しくなった🎉 デジタル化によって、無駄な巡回を減らせただけでなく、漠然としていた使用頻度がハッキリと分かるようになりました。その結果、効果の高い工夫ができるようになったのは大きな収穫です。 失敗からの学び この業務改善の取り組みは、新人エンジニアのプログラミングスキル向上を目的にはじめました。社内で改善したいことを募集して、意気揚々と開始したのですが、当初はことごとく失敗してしまいました…。失敗の理由と対策は次の通りです。 試作品はできたが、設定が面倒で結局使われなかった ⇒ 機能を絞ってとりあえずリリース 自動化するには元の業務を変更しなければいけないが、変えたくなかった ⇒ 要求者との会話のキャッチボールを大切に 機能を絞ってとりあえずリリース 動くものを素早く作り、体験してもらうことを優先しました。当初は、文房具ごとにQRコードを発行し、それを連続で読み取らせるアイデアも出たのですが、Apps Scriptで実装するのは少し大変です。そこで「QRコードを読んだら、フォームを表示するだけ」にあえて機能を絞り込みました。 フォームの項目も必要最小限にしてサクッと作り、実際に「QRコードを読む」ことが体験できるように実装し、その行為が受け入れられるかを検証しました。 要求者との会話のキャッチボールを大切に コミュニケーションに気をつけて、真の要求を一緒に探しました。業務に詳しいスタッフ部門は、改善のアイデアもたくさん持っています。一方、エンジニアはそうしたアイデアを聞くと「実装しやすいか？難しいか？」という観点で反射的に回答しがちです。その結果、実際の業務からかけ離れた実装になってしまうこともあります。 アイデアに対して「できる・できない」と回答する前に、「そもそも、どうしてその要望を叶えたいのか？」を引き出すよう、会話のキャッチボールを心掛けました。 業務改善で仕事を楽しく 業務改善は失敗するのが当たり前、と思いながら、工夫を続けている様子をお伝えしました。 アイデアが形となるのは楽しいものです。また、仕事が楽になれば、次のチャレンジに使える余裕も生み出せます。デジタル化したい業務はまだまだありますので、楽しみながら取り組んでいくつもりです。 なお、新人エンジニア研修の最後に実施するチーム開発演習でも、Apps Scriptを使った社内システムを作っています。今回ご紹介したボトムアップのアプローチと違い、アジャイル開発（スクラム）のプロセスに則って、中規模のウェブアプリを開発しています。ご興味があればぜひご覧ください。 style.biglobe.co.jp style.biglobe.co.jp Google Workspace / Apps Script のTips集 ここからは、実際に使っている技術を詳しく紹介していきます。ちなみに、新人エンジニアには「使える武器を普段から増やしておく」ことの大切さを訴えています。使える手段が多ければ、課題解決が楽になるからです（その反面、ハンマーを持つと何でも釘に見えてしまうもので、どう適用するかは十分に気をつける必要がありますが）。かなり細かい話になりますが、参考になれば幸いです。 GoogleスプレッドシートでQRコードを作る GoogleフォームのURLをQRコードに変換するのに、スプレッドシートを使うことができます。 スプレッドシートのIMAGE関数とENCODEURL関数、そして（Deprecatedされた）Google Chats APIを使います（いつGoogle Chats APIが使えなくなってもおかしくありません。ご注意ください）。 support.google.com support.google.com developers.google.com 例えば、A1セルにURLを入力し、B1セルにQRコードを表示する次の関数を入力します。 =IMAGE( "https://chart.googleapis.com/chart?chs=450x450&cht=qr&chl=" &ENCODEURL(A1)) すると、B1セルにQRコードが表示されます。 Googleフォームの事前入力でフォームの数を減らす Googleフォームの「事前入力したURLを取得」を使うと、フォームを1つ準備して、そのフォームに予め値を設定した状態のURLを別々に払い出すことができます。 support.google.com 複合機のコピー用紙補充フォームは1つだけ準備しました。プルダウンでどの複合機かを指定します。 複合機を選択した状態で「リンクを取得」ボタンを押せば、その複合機用のURLを取得できます。上述した方法で、そのURLをQRコードに変換します。 回答に応じたセクション移動を再帰させ一度に複数の申請をする QRコードを読んだ後に開いた申請画面で、複数の物品を申請するテクニックです。「回答に応じてセクションに移動」を再帰的に利用します。 support.google.com 文房具棚は、文房具、封筒、紙袋、といった異なる分類の物品を扱っています。扱う物品全てを一つの画面に表示すると、数が多すぎて選択するのが大変です。そこで、分類ごとにセクションを分けつつ、最初に「何を補充しますか？」と質問して、分類を選んでもらうことで、一画面で表示する物品を絞ります。 各セクションでは、その分類に含まれる物品をチェックボックスで選択させます。そして最後に「他に補充するものはありますか？」と質問して、必要であれば別の分類も選べるようにします。 こうすることで、QRコードを読んだ後、一度の申請で複数の分類から物品を選べるようになります。逆にこうしておかないと何度もQRコードを読んでもらう必要が出てきます。 Googleフォームからの通知はやり方が2種類ある Apps Script を使って、フォームが送信されるとGoogle ChatやGMailに通知をしています。そのスクリプトを記述する場所は、Googleフォームのスクリプトエディタか、回答のスプレッドシートのスクリプトエディタになりますが、イベントのデータ形式がそれぞれ異なるので要注意です。 Googleフォームのエディタを使う場合は こちら です。FormResponseオブジェクトが渡されるのですが、若干使いづらいので、 Googleフォームで送信されたデータを使いやすいJSONに変換する にあるコードでJSONに変換して使います。 一方、スプレッドシートのエディタを使う場合は こちら です。namedValuesの値が配列になっていることに注意が必要ですが、これで十分なことがほとんどです。 なおフォームで受信した情報をGoogle Chatで通知するには、Webhookを使います。 developers.google.com function notify(text) { const webhookUrl = 'https://chat.googleapis.com/v1/spaces/xxx/messages?key=xxx&token=xxx' ; const response = UrlFetchApp.fetch(url, { method: 'post' , headers: { contentType: "application/json; charset=UTF-8" } , payload: JSON.stringify( { text } ) } ; console.log(response); } もちろん、メールで通知することも可能です。 developers.google.com メールの送信元は、そのApps Scriptを作った人になりますが、options に {noReply: true} を指定しておくと、送信元がnoreplyになるので便利です。 Googleフォームの項目と回答スプレッドシートの列をあわせる Googleフォームの項目を試行錯誤しながら作っていると、回答のスプレッドシートの列の並びが、フォームの項目の順序とはずれてきます。そんな時は、フォームとスプレッドシートのリンクを一度解除して、再びリンクします。回答データはフォーム側がModelとして持っていて、スプレッドシートはそのView / Controllerでしかないので、簡単にリンクし直すことができます。 まず、フォーム、もしくは、スプレッドシートで「フォームのリンクを解除」します。フォームから解除するには、回答タブのケバブメニュー（縦に並んだ三つの点）から、スプレッドシートからならシートのタイトルから、それぞれ選びます。 次に、スプレッドシートの回答タブで「回答先を選択」します。既存のスプレッドシートを選んだ場合でも、新しいシートが追加されて、古い回答シートは残されます。 メールアドレスから氏名を取得して入力項目を減らす Googleフォームの項目数はできる限り減らしたいものです。Google Workspaceだと、フォームに入力した人のメールアドレスを自動的に取得できるので、そこからAdmin Directory SDK Serviceの Users.get() を利用して氏名を取得できます。 なお、Google Workspace の設定によっては、 Users.get() のオプションに {viewType: 'domain_public'} が必要になるので注意してください。 developers.google.com Apps Script から Admin Directory を利用するには、次のドキュメントが役に立ちます。 developers.google.com Apps Scriptでユニットテスト 少し複雑なロジックを書く時にユニットテストが欲しくなります。特に、Googleフォームからの通知など、わざわざフォームを操作しないと動作を確認できないコードは調整が面倒です。CLIを使ってApps Scriptを開発できる clasp を使うほどでもない場合は、自作のassert関数を使ってテストケースを書き、スクリプトエディタ上で実行しています。 /** * 与えられた条件が true であることを表明する。 * @param {boolean} cond 条件 * @throws もし条件が true でないなら NG */ function assert( cond ) { if (cond !== true ) throw 'NG' } /** * 与えられた値が期待値と同じ(===)ことを表明する。 * @param {string} actual 値 * @param {string} expected 期待値 * @throws もし値が期待値と同じでないなら NG */ function assertEquals( actual, expected ) { if (actual !== expected) throw `NG: ${actual} !== ${expected} ` } /** * 与えられた関数を実行した結果、例外が発生することを表明する。 * @param {function} func 関数 * @throws もし関数を実行した結果、例外が発生しないなら NG */ function assertThrows(func) { try { func(); } catch (e) { Logger.log(e); return ; } // Exception が発生して、ここは実行されないはず throw 'NG: 例外が発生しませんでした。' ; } その他、Apps Scriptの便利なテクニック とても便利なGoogle Workspace / Apps Scriptですが、何が制限になるかは最初に調べておく必要があります。 Google サービスの割り当て developers.google.com なお、Apps Script でコーディングする時に、知っていると便利なのが、関数名の末尾にアンダースコア（_）をつけるとプライベートになることや、関数の説明をJSDocで書けること、です。 developers.google.com 実行速度を上げるためのベストプラクティスもあるので、参考にしてみてください。 developers.google.com ※ QRコードは、株式会社デンソーウェーブの登録商標です。 ※ Google、Google Chat、GMail、Google Workspace、Androidは、Google LLCの商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。 BIGLOBEは今、基幹事業で培ったノウハウを新規事業に活かしていく「二軸運営」を目指しており、アイデアを形にできる面白いフェーズにいます。 そのための施策として、開発部門である基盤本部と、事業プラットフォーム部門が合同で企画し、立ち上げたのが「新サービス創出推進プログラム」です。この活動の背景には「自己成長を後押しする職場環境、サービスプロセスの整備」を掲げており、以下のような狙いがあります。 基盤本部 ・ 顧客／ビジネス目線で考えることのできるエンジニアの育成 ・ 新しいことに取り組みたいという創出意識の高い人の要望に応える 事業プラットフォーム部門 ・日常的にプロダクト志向によるサービス改善や新規サービス創出が行われ、メンバー一人ひとりが「自己成長につながり、やりがいがある」と感じられる職場へ ・実戦経験を通じてデザインシンキングやビジネスデベロップメント等のスキルを強化し、市場で通用する人材に成長   2021年下期から開始された「新サービス創出プログラム」では、これまでに以下の活動を行ってまいりました。 ・ 多摩美術大学との産学共同研究 で作られた学生の作品を題材に、 新しいサービスを考えるワークショップ（2022.1） ・ユーザー調査プログラム（2022.2） ・新サービスアイデア発表会（2022.3） 2022年3月に行われた「新サービスアイデア発表会」（半期に1度開催）で評価されたアイデアについては、事業化に向け組織の枠を超えてプロジェクトとして活動が継続されています。しかも、その中には新入社員のアイデアも！素晴らしいですね💪 このようなさまざまな活動がある中、2022年7月に行われたのが「Stage0アイデアマーケット」。今回はその様子をご紹介します。 Stage0アイデアマーケットとは Stage0 アイデアマーケットに潜入してきました！ 主催者インタビュー Stage0アイデアマーケットとは ・思いついたアイデアを気軽にアウトプットする場がない ・アイデアを自由に持ち寄って議論するタイミングがない ・アイデアを成長させる場がない ・アイデア発表会前にアイデアをブラッシュアップしたい ・持っているアイデアを推進するための仲間を集める場がない Stage0アイデアマーケットは、上記のような社員の声を吸い上げて企画され、 それぞれが持っているアイデアを気軽に発表し、みんなでブラッシュアップしていこうという初の試み。 新しいことに挑戦できる活動の場は、社員のモチベーション向上にもつながっているといいます。 Stage0 ア イデアマーケットに潜入してきました！ 今回はオフライン＋オンラインのハイブリッドでの開催です。合わせて約180名（社員数の1/3程）の参加となりました！ 会場全体の様子。本社のコミュニティスペースを利用しています。 好きなタイミングで気になる展示スペースを見学できるようになっています。 出展方法は以下の3パターン。 ①アイデア掲示板 　アイデアの企画書をボードに掲示します。匿名でもOKで、ちょっとしたアイデアでも気軽に参加が可能です。 ②アイデア展示スペース 　展示者同士や見学者とのディスカッションの場。一緒にサービスを考える仲間も募れるかも？ ③アイデア発表スペース 　LT（ Lightning Talk ）形式で発表！ 申請されたアイデアの数は、全部で44件！気軽に出展できる方法もあるのがいいですね。アイデアは全てカタログにして閲覧できるようになっています。社会課題をテーマにしたものが多く、防災やリサイクルの活用などがアイデアとして挙がっていました。 アイデア掲示板には見学者からの意見や感想が書かれた付箋が貼られています。 アイデア展示スペースで意見交換しながらブラッシュアップを図っています。 有泉社長（左手前）の姿も。 中継班が各ブースを回りインタビューをしています。 アイデアLTの様子。オンラインでも中継されました。 出展者、見学者共に、新入社員、中途社員からベテラン社員までとても幅広い顔ぶれ。LTでは入社して間もない新入社員も挑戦していました👏 各展示スペースで質問を投げかけると、自身のアイデアを意気揚々と説明してくださりこちらも刺激を受けました！さまざまなアイデアが発表されているので、見学者もワクワクしながら巡ることができ、とてもユニークなイベントでした。 今回出展されたアイデアは、今後行われる「新サービスアイデア発表会」に向けてさらに良いモノに仕上がると思います！ 最後に、開催を手掛けた基盤本部の梅津に話を聞いてみました。 主催者インタビュー ―――　「Stage0アイデアマーケット」を実施してみていかがでしたか？ 梅津： コロナ感染拡大という状況のなか、対策のもとオフライン＋オンラインのハイブリッド開催としました。在宅勤務率が高いため、オフライン見学者数はそれほど期待していませんでしたが、幹部の方々をはじめ、30名程来場いただけました。オンラインは150名程の参加がありこちらも予想をはるかに超え多くの社員に参加していただけて良かったです。 掲示、展示、LTとそれぞれ出展枠を設けたのですが、アイデアの数も期待以上に集まり、今後継続に向けての手応えを得ることができました。 その一方で、アイデアを出展する部門に若干偏りがあるので、今後の課題として改善していきたいです。   ―――　開催にあたって工夫したことはありますか？ 梅津： ①コミュニケーション活性 まず、展示者同士、そして展示者と現地見学者間のコミュニケーションを密にできるように意識しました。アイデアをブラッシュアップする目的はもちろんですが、他部門の方や職位の違う方などと、コミュニケーションを図れる機会にしたいという意図もあります。 そのために、全社に対して開催の告知をし、主催部門だけではなく組織の垣根を超えて参加できるようにしました。告知したことで幹部の方にも興味を持っていただき現地に足を運んでもらえたので、参加者は直接話すことができて良かったのではと思います。 現場に来られない人（オンライン）にも臨場感を感じてもらいたかったので、展示者に突撃インタビューをするなど現地の様子を共有できる工夫もしました。 梅津： ②小さなアイデアでも掬い上げる 最初から、新サービスとして成り立つようなアイデアは少なく、たいていは個人個人の内にある、 発表するまでもないと思われているような、ごく小さなものだと思っています。 しかし、そうした小さなアイデアも、組み合わせればよいアイデアになったり、他人の意見を加えることによって思いもよらない発展があるかもしれません。 また、違った立場の人が見れば、別のアイデアを生み出すきっかけになったりもします。 そのため、普通なら表に出てこないような小さなアイデアも漏らさず掬い上げることが必要だろうと考えました。 具体的には、少しでも参加の敷居を下げるために、アイデア掲示板のみの参加や、匿名での参加も歓迎するようにしました。 将来的には社員が持っているアイデアを簡単に投稿や提出ができ、それらを貯めていける仕組みができればいいなと思ってます。 梅津： ③その他の工夫 その他、掲示のみのアイデアへは見学者が意見や感想を付箋に書いて掲示物へ貼って表明できるようにしたり、LT＆展示インタビューを1ターンとしてそれを2ターン繰り返すことでメリハリのあるタイムスケジュールにしたりしました。   ―――　出展者や見学者からはどのような感想がありましたか？ 梅津： 出展側、見学側ともにおおむね高評価をいただきました。特にオフラインでのディスカッションに対する評価が高かったですね。オンラインについては現場からの一方通行な中継だったため、発表内容に対して何かしらリアクションしたかったという意見がありました。今後は双方のコミュニケーションがより取れるような仕組みを考えていきたいと思っています。   ―――　「新サービス創出推進プログラム」の今後の展望を教えてください。 梅津： コロナの影響で全社横断でコミュニケーションを取れる機会が少ないからこそ、このプログラムを定期開催できるようにしたいです。さらには、コロナが収束して、オフライン参加者が増えることで、さらに活発なディスカッションが行えるようになることを期待しています。 アイデアを軸にしたコミュニケーションを基本として、今回の経験を糧に開催方法の見直しや拡大を図り、新サービス創出を全社で盛り上げていきたいと思います！   ―――ありがとうございました。今後の活動も期待しています！   最後までお読みいただきありがとうございました。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

こんにちは、基盤本部マーケティングプラットフォーム部の横山です。 今回は現在私が所属するグループで開発・運用中の自動GUIテストシステムについてご紹介します。 テストコードのメンテナンスコストを下げる画像回帰テスト スクリーンショットを比較し、差異を検出する 向いている使い方 過去のシステム構成 サーバーレス構成への移行 工夫した点 おわりに テストコードのメンテナンスコストを下げる画像回帰テスト ソフトウェア開発における自動テストには、関数やAPIの動作を確認するJUnitによる単体テストから、ユーザーの操作をシミュレートするSeleniumによるエンド・ツー・エンドテストまで、様々な種類があります。そして、どの自動テストでも問題になるのはテストコードのメンテナンスです。 私のグループは画面の開発を担当していますが、画面は改修の頻度が多く、テストコードのメンテナンスに莫大な工数がかかってしまうことが問題でした。 できるだけテストコードのメンテナンスをしなくても実現できる自動テストがないか検討した結果、今回ご紹介する自動GUIテストシステムの形にたどり着きました。いわゆる画像回帰テスト（Visual Regression Testing）ツールです。 スクリーンショットを比較し、差異を検出する 私たちが開発・運用中の自動テストシステムでは、スクリーンショットを比較することによってアプリケーションをテストします。 例えば、アプリケーションを改修した場合、その改修をデプロイする前に撮ったスクリーンショットと、デプロイした後に撮ったスクリーンショットの差異を自動的に検知して 変わるべきところが変わっていること 変わるべきでないところが変わっていないこと を視覚的に確認できるように表現します。 具体的な仕組みとしては、テスト対象ページのURLを指定してテストを実行すると、そのページのスクリーンショットを取得します。そのスクリーンショットが残っている状態で再度同じURLを指定して実行すると、同じようにスクリーンショットを取得して前回撮ったスクリーンショットと比較し、差異を検出します。 実際にBIGLOBE個人会員向けのマイページに対してテスト実行した結果が下図になります。 ↓１回目の実行で取得したスクリーンショット（差異部分） ↓２回目の実行で取得したスクリーンショット（差異部分） 差異がある部分は赤くマークされ、一目で差分を確認できます。 上記の例で差異が検出された箇所は、実はページを表示するたびにランダムで変わる部分であり、差異が出るのは想定内でした。 こういった想定内の差異については比較対象外にしておかないと、本来検出すべき他の差異の通知が埋もれてしまうかもしれません。 そこで、要素を指定して比較対象外とするマスキング機能も開発しています。 マイページの例をマスキングして比較した結果が下図になります。 指定した要素が黒く塗りつぶされ、差異として検出されないことがわかるかと思います。 向いている使い方 この自動GUIテストシステムの最大の強みはタイトルにもある通り、テストコードを書く必要がほぼないことです。 行っているのは「指定のURLにアクセス→スクリーンショットを撮る→前回の結果と比較する」だけなので、動作がテスト対象の画面に依存しません。 POSTで遷移するページなど、URLを指定するだけではたどり着けないページについてはテストコードを追加で書く必要がありますが、遷移の操作のみの最小限のコードで済ますことができます。 そのためメンテナンス工数を大幅に削減できるほか、様々なアプリケーションに対し汎用的に使用できます。 よって下記のようなケースに向いています。 何度も細かい改修が入りその度に回帰テスト（別の箇所で不具合が発生していないかを確認）をするアプリケーション 影響範囲が広く、多数のページへの影響を確認する必要がある改修 定期的に実行し、予定外の変更やシステムダウンを検知する、監視目的としての使用 スクリーンショットを使うので、データベースやログなど、画面を対象としない（視覚的変化がない）テストには向いていません。画面以外のテストは別のツールで補います。 過去のシステム構成 この自動GUIテストシステムは様々なアプリケーションに対して汎用的に使用できることが利点であるため、開発環境に同居させてローカルで実行するのではなく、サーバー上でサービスとして実行することでより効果を発揮します。 そのため、最初は下記のようにJenkinsを使った構成で運用していました。 Amazon EC2インスタンス上でJenkinsを動作 各テストケースはJenkinsのジョブで管理 ジョブを手動で実行するか、定期実行することでテストを実施 差異が検出されたらメールとGoogle Chatへ通知 しかし、利用するアプリケーションが増えるにつれて 複数のジョブを並列実行すると性能不足でJenkinsが動かなくなってしまう テスト対象ページやブラウザが多くなると、テスト完了まで30分以上かかる ジョブの数が多くなり、それぞれで設定が異なったりなど、管理が難しい といった性能面、運用面の問題があることがわかってきました。 性能面についてはEC2で実行しているので、性能の良いインスタンスタイプに変えるかオートスケーリングを使用すれば解決できたかもしれません。 ただ、そもそもストレージなども含めたインフラ面の管理をしたくなかったため、なんとか管理をしなくても済む構成を作れないか考えました。 サーバーレス構成への移行 Jenkinsで発生した問題を解決し、かつインフラ面の管理をしなくても済む構成を考えた結果、Amazon Web Services（AWS）のマネージドサービスを使ったサーバーレス構成を構築することにしました。 試行錯誤の結果、たどり着いた構成が下図になります。 使用したサービスは下記のとおりです。 AWS CodeBuild 自動テストシステムを実行するメインのサービスです。 テストを実施するブラウザとWebDriverをインストールし、ヘッドレス実行でテストします。 CodeBuildの実行環境はビルドごとにそれぞれ別の環境が構築されるため、他のテストに影響を与えることはなく実質無制限の同時実行が可能になりました。 Amazon S3 テスト結果を格納するために使用しています。 テスト結果はバケットポリシーで社内向けに公開し、社内であればどこからでもテストレポートを確認できるようにしました。 EC2 Image Builder CodeBuildで使用するDockerイメージを作成します。 自動テスト実行時、ブラウザに新しいバージョンがあった場合はイメージを自動で作り直すようにし、常に最新バージョンのブラウザでテストが実行されるようにしています。 Amazon ECR Image Builderで作成したイメージを格納するために使用します。 Amazon SES 画面の差異が検出された際に、通知メールを送信します。 Amazon EventBridge テストを定期実行するために使用します。 AWS Systems Manager Parameter Store テストで使用する設定項目の管理に使用するほか、アプリケーションごとのテストケースを名前を付けて管理することで、Step Functions実行時にテストケース名を指定するだけで実施するテストを切り替えられるようにしました。 AWS Lambda 細かいテスト結果の取りまとめのほか、差異検出の通知をGoogle Chatにも飛ばすために使用しています。 AWS Step Functions それぞれのサービスを結合し、一連の流れとして実行するワークフローを構成するために使用しています。 AWS CloudFormation 上記構成を設定ファイルで管理するために使用しました。 工夫した点 Jenkinsからサーバーレス構成に移行するにあたって解決すべき課題として下記がありました。 Jenkinsで発生した性能面、運用面の問題を解決できること インフラ管理の手間をできるだけ減らすこと 1.についてはCodeBuildでテストを実行することで解決できました。並列実行が可能になったことにより、マルチブラウザテストを並列で行えるようになり、テストにかかる時間も短縮できました。 2.についてもスケーリングの設定や評価も含めてAWSに丸投げすることができ、インフラ管理の手間をほぼ０にできました。 それ以外に工夫した点が2点あります。 1つはテストレポートに誰でもアクセスできるようにしたことです。 Jenkins構成の時はJenkinsの中に結果が出力されるため、閲覧するためにはJenkinsにログインする必要があり、不便で何とかしたいと思っていました。 S3に置くことで、バケットポリシーで許可されていればブラウザで簡単に閲覧できるようにしました。 もう１つはAWSサービス構成や各設定項目などを、CloudFormationテンプレートファイルで管理できるようにしたことです。 別途ドキュメントで管理してもいいのですが、ちゃんと継続してメンテナンスできるか不安でした。CloudFormationを使用すると、リソースを更新する時にはテンプレートファイルも更新が必要になります。その結果、意識しなくてもテンプレートファイルには必ず最新のリソース状態が反映されるようになります。更にGitでバージョンを管理できるようになりました。 おわりに スクリーンショット比較テストはいろんなアプリケーションに対して応用が利き、なかなか可能性を秘めた自動テストシステムなのではと自分のグループのことながら思っています。 サーバーレス構成についても、いろんな課題をきれいに解決できてよかったと思います。個人的には直近で合格したAWS認定デベロッパーアソシエイトの知識を活かすことができて楽しかったです。 今回は実際の業務で開発・運用しているシステムについてご紹介しました。いろんなアプリケーションに汎用的に使える自動テストシステムですので、自グループに留まらず他グループでも利用できるよう、運用方法も含めてブラッシュアップしていきたいと思います。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

ISPの要であるRADIUSシステムのDevOps環境整備とクラウドネイティブ化を3年がかりで実現したことについて、技術検証で頓挫しかけた苦労話から、クラウド化のコツまで詳しくインタビューしました。 技術的負債を一気に返却するはずが存続の危機に 得意なことで補い合いながら課題をクリア フルリモートでも無事故のリプレースを実現したGitOps エンジニアが働く環境としてのBIGLOBEとは ISPの接続認証機能を担うRADIUSシステムを、コンテナやサーバーレス技術を活用して3年がかりでクラウドネイティブ化し、2022年6月から正式にサービスを開始しました。 それにあわせて、開発から運用までをスムーズに連携するDevOps環境を実現し、150台のオンプレミス・サーバーにかけていたシステム運用・保守工数を半減し、インフラ費用を従来の3分の2に圧縮することができました。 DevOps環境の特徴は次の通りです。 複数のクラウドサービス・リージョンを利用することで耐障害性を高めるマルチクラウド インフラをコードで記述するInfrastructure as Code（IaC） ソフトウェア開発におけるテストからデプロイまでを自動化する継続的インテグレーション/継続的デプロイ（CI/CD） バージョン管理システム GitLab を活用してCI/CDを実現するGitOps クラウドネイティブ化の背景やメリット、苦労した点や工夫について、RADIUSを担当しているお二人にインタビューしていきます。 技術的負債を一気に返却するはずが存続の危機に Q. RADIUSシステムについて教えてください。 石井： RADIUSシステムは、ISP（Internet Service Provider）の接続認証機能を実現する重要なシステムです。インターネット接続における認証（Authentication）、認可（Authorization）、利用実績の記録（Accounting）を担います。インターネットに接続したいお客様は、宅内装置からアクセス回線を経由してBIGLOBEのインターネット設備に接続します。その際、アクセス回線事業者のRADIUSクライアントがBIGLOBEのRADIUSサーバーを呼び出します。 お客様の数が増えるに従って、我々が運用するRADIUSサーバーも大規模化し、世代交代を繰り返してきました。第1世代はアプライアンス製品に付属してきたRADIUSサーバーを改造したものです。これを内製化するため、オープンソースのRADIUSに複数のモジュールを追加したのが第2世代、コンテナ化してKubernetesで実行する今の形が第3世代になります。 石井 賢二 （いしい けんじ） 基盤本部 モバイルコア技術部 エキスパート 1994年 日本電気株式会社 入社 2001年 NECビッグローブ株式会社（当時）異動 アクセス網の高度化にまつわる業務を経て、2010年よりRADIUSシステムを担当 谷山： 第3世代のシステム構成はRADIUSが出力したログがデータ処理パイプラインを通過することで加工・振り分けされ、監視システムやバックオフィスのシステムに流れるようになっています。このパイプラインは Amazon Kinesis や AWS Lambda を組み合わせたサーバレスな構成とすることで、クラウドネイティブ化を図っています。 Q. 今回、クラウドネイティブ化に挑戦したのはなぜでしょうか？ 石井： RADIUSシステムはインフラ部門で運用してきました。インフラ部門は、ネットワーク装置を買ってきてデータセンターで組み合わせ、BIGLOBE固有の接続認証が必要な際にRADIUSを組み込みます。ただ、事業拡大に伴い、第1世代の改修は限界を迎えていました。そこで、第2世代でオープンソースを使ったサービス内製化に取り組みました。 内製化によってできることが増えたのは良かったのですが、オンプレミスのサーバー150台を運用する工数が大きな負担となっていました。また ISPの接続認証機能ですから、作業によるサービス影響は避けなければなりません。当時は表計算ソフトで作った手配書で作業をしていたのですが、精神的な負担もとても大きかったです。 そんな中、2018年にクラウド化を全社的に推進することになりました。オンプレミスのサーバーをクラウドにそのまま移行するLift & Shift戦略が採られることが多いのですが、私は開発と運用が一体となって改善を続けるDevOpsと、それを支えるクラウドネイティブ技術に強い魅力を感じました。 そこで、クラウドネイティブ化を前提に技術検証を開始したのですが、思ったような成果を出すのは難しく、あっという間に1年半が経過してしまいました。 うまくいかなかった原因の一つは、クラウド技術を習得するにも既存業務に忙殺されてしまい、時間が取れなかったことにあります。オンプレミスサーバーで稼働させているRADIUSの保守作業、機能追加に伴うソースコードの調査や改修作業、他部門からの調査依頼の対応などをやりきり、残った時間でクラウド化に取り組んでいました。特に、他部門からの依頼はこちらの都合に関係なく発生し、かつ、優先順位も高いため、その対応で燃え尽きてしまうこともしばしばでした。 そんな時に、中途入社でチームに参加してくれたのが谷山さんでした。試行錯誤でぐちゃぐちゃになっていた検証環境をきれいに整えつつ、セキュリティ基準に準拠したシステム構成を Terraform と Ansible を使ってさっと実現してくれました。また、GitLabを導入してCI/CDパイプラインを構築し、安全にインフラを構築するGitOpsの道を切り開いてくれました。 谷山： 私はエンジニアとして先進的なことに取り組みたくてBIGLOBEに転職してきました。石井さんが「世界標準のやり方でやろう」と声をかけてくれ、自由にやらせてくれたのがとても嬉かったです。 得意なことで補い合いながら課題をクリア Q. クラウドネイティブ化に挑戦するためにどんな準備をしましたか？ 石井： 研修に参加したり、ベストプラクティスを徹底的に調査しました。技術検証が頓挫しかけてからは、Amazon Web Services（AWS）が得意なパートナー会社に参画してもらい、技術力を底上げしています。 また社内システムとの連携インターフェースをクラウドネイティブ化するにあたり、多くの関係者に協力してもらいました。ストレージは Amazon S3 、ファイル転送は AWS Transfer for SFTP 、REST APIは Amazon API Gateway にそれぞれ置き換えています。 谷山： 石井さんと私でそれぞれ得意なことが違います。良いところを上手く組み合わせて課題を突破してきました。石井さんは幅広い情報収集が得意です。世界標準のやり方をチームにどんどんインプットしてくれます。 私は深く潜るのが得意です。必要になれば、どんな複雑なネットワーク構成であっても現状を整理しながら理解を深めます。逆に言うと、必要になるまで調べません。プログラマーの三大美徳の一つである「怠惰」な人間なんだと思います（笑）。深く潜りすぎて、世の中のやり方が見えなくなることもあるので、石井さんの情報には感謝しています。 谷山 大介 （たにやま だいすけ） 基盤本部 モバイルコア技術部 エキスパート 2020年1月中途入社／社会人8年目 前職大手キャリアのインフラ開発を経て、現在はBIGLOBE RADIUSシステムのマルチクラウド化、モバイル通信サービスdonedoneのアプリケーション向けインフラ開発等のプロジェクトに従事している。 Q. やってみて想定外だったことはありますか？ 谷山： 「クラウドなら最初はラフに作って、後から変更すればよい」と考えていたところがあるのですが、設計段階から考えておくべきことがたくさんありました。 石井： そうですね。例えば、個人的に力を入れたのはリソースの命名規則です。パートナー会社が作ってくれた案をベースに、BIGLOBEの業務でよく使われる共通言語（例えば、サービスIDといった用語）を取り入れつつ、devやprdといった一意にならない表現を避けて曖昧さを排除しました。 特に気を使ったのが、出来上がる名前の長さです。長ければ入力ミスやコード量の増加につながりますし、コンソールでの一覧性も低下します。そこで必要最小限に留めたかったのですが、マルチリージョン、マルチクラウドについても考える必要があって苦慮しました。 Tagについても工夫しました。CI/CDの実行プロジェクト名をTerraform Tagに入れることで、そのリソースがCI/CDで作ったものなのか？どのプロセスで作ったのか？が一目瞭然となり、CI/CDの操作も楽になります。後からTagを追加するのはそれなりに大変なので、最初から入れておいて良かったです。 谷山： 命名規則は石井さんも苦しんでましたが、最初に作ったのはとても良かったと思います。Terraformで新しいモジュールを作るときには、その指針に沿うだけでそのリソースが何者か一意に特定できるようになっていたためとても楽でした。AWSでは作成後に変更できないパラメータがあるため、命名規則に限らず最初にポリシーを明確に決めておくことは非常に重要でした。 他にも初期に検討しておくことはたくさんあります。ログを処理するためにストリーミングデータをリアルタイムで扱うAmazon Kinesisを使っていますが、エラーを起こした場合にどう対処するのか？アラームはどう作るのか？といった異常系の対処を予め考えておく必要があります。 AWSのソリューション・アーキテクトからは、設計上考えておくべきことをリストとして提供していただきました。そのリストを見た時は、こんなに考えておくことがあるのか！と驚きましたが、最終的にはそのほとんどをクリアすることができています。 Q. 他にも、気をつけるべきポイントはありますか？ 石井： オンプレミスでの常識は通用しないですね。定期的に処理をさせるバッチとして AWS Lambdaを動作させる時は、起動時刻も同時起動数も保証されません。 Amazon DynamoDB を使ってロックの仕組みを導入するなど、きめ細やかな対応が必要でした。 また、AWS Lambdaは処理中のデータに問題があった時の扱いが難しく、アプリ側でAmazon S3に格納しています。Amazon S3の品質レベルはとても高いのですが、障害が全くないとは言い切れません。そこで、東京リージョンのAmazon S3が使えなくなったら大阪リージョンにフォールバックする仕掛けが必要になります。複数のリージョン上にシステムを構築しただけでは耐障害性は獲得できません。 ちなみに、今回のプロジェクトはベストプラクティスを参考に、最初からアベイラビリティ・ゾーンを3つ使うトリプルAZ構成を採用し、クラウドもオンプレと変わらず単一障害点のない24時間365日サービスの稼働に耐える構成を実現しています。 石井： 社内システムとの連携では、連携先システムへの考慮が不足していて迷惑をかけてしまいました。例えば、Amazon S3のオブジェクト数は事実上無制限ですが、オブジェクト数が多すぎて連携先で処理しきれなくなってしまったり、負荷試験の前後に評価環境の Amazon Aurora をAmazon KinesisやAWS Lambdaと共にスケールアップ・スケールダウンしたところ、連携先のアラーム発報を引き起こしてしまったり。いくらクラウドにスケーラビリティや伸縮自在性があっても、連携先にどのような影響を及ぼすかはよくよく考慮しなければいけません。一緒に解決してくれた関係者にはとても感謝しています。 フルリモートでも無事故のリプレースを実現したGitOps Q. 今回の取り組みによって、どんなメリットが生まれましたか？ 石井： コスト削減はもちろん、他社のベストプラクティスを参考にしながら、世界で議論されているようなDevOps環境に近づけた実感があります。インフラからアプリケーションまで全てのレイヤーをGitで管理するGitOpsを導入したことで、情報共有も、Issue管理も見える化が格段に進みました。 谷山： 実は、コロナ禍になってから私はほとんど出社することなく、このプロジェクトを成功させることができました。GitOpsを導入したことによる恩恵です。 以前は口頭でやり取りしていることが多かったのですが、在宅勤務になったタイミングで GitLabのIssueを中心としたコミュニケーションが実現できていたため、作業のヌケモレを圧倒的に減らせています。 以前はとても長かった朝会も、見るべきIssueだけを確認すればよくなったのでグッと短縮できました。 Amazon VPC の削除といった「やるべきタスク」をいちいち「あの件どうなりました？」と確認しなくて済んでいます。 技術検証中にインフラ環境が不安定になっても、GitLabでその原因をすぐに把握できるようになりましたし、各自の作業がどこまで進んでいるかを追いかけられるのも助かります。 RADIUSのGitOpsについては過去に2つの記事を書いています。よろしければご覧ください。 style.biglobe.co.jp style.biglobe.co.jp 石井： クラウドは情報を集約できるのが良いですね。 Amazon CloudWatch を見れば、何が起きているのかすぐに分かります。調査がとても楽になりました。 エンジニアが働く環境としてのBIGLOBEとは Q. 中途入社された谷山さんから見て、BIGLOBEはどんな組織だと思われますか？ 谷山： BIGLOBEには勉強好きな人が多いです。社内でハンズオンやライトニングトーク大会などを活発に開催していて、CI/CDやIaCなどの自動化についても知っている人も多いです。 しかし、社会インフラである通信を提供する立場ですから、お客様が使うサービスで障害を起こすことはできません。今回は不具合を洗い出すために、移行元のオンプレミス環境に流れているトラフィックをクラウド環境にミラーリングする並行稼働期間を作り、本番データ相当のデータで試験を重ねました。さらに、サービス開始間際には、旧環境に切り戻しをする判断をいつでも下せるよう、利用者の認証でトラブルが発生していないかをリアルタイムで監視するシステムを Amazon OpenSearch Service を使って組み上げていました。こうした入念な準備によって、障害を一切出すことなく、リプレースを完遂することができました。 クラウドは故障することを前提にシステムを構築します。きちんと備えれば、高い品質を実現することができ、品質以上の価値を享受することができます。 安全にやる限り、新しい取り組みに反対する人はいません。私が入社してからすぐに、部門として初めてGitLabを利用する申請をしましたが、上位上司も社外サービスの活用を高く評価してくれました。 世の中の潮流を知っている人も多く、幹部も反対しないので、本人のやる気次第で変えられる会社だと思います。私は、上司が自由にやってよい、と声をかけてくれたので幸運でした。 インフラ系でここまで自動化を実践している組織はまだまだ少ないと思います。インフラに関する知識を持ち、内製化が好きで、TerraformやAnsibleなどでIaCを全力でやっていきたい人にはピッタリだと思います。 Q. 歴史あるRADIUSシステムを支えてきた石井さんにとって、今回の取り組みはどんな意義があるでしょうか？ 石井： 谷山さんという心強い味方が増えたおかげで、三度目の正直である真の内製化に大きく近づくことができました。また、世界標準の仕組みに近づけたことで、メンバーが楽になり、かつ、今後の改修もやりやすくなったと思います。私が引き継いだ時はとても大変な思いをしたのですが、あんな思いは次の人にさせたくないですね。 ただ、今回はあまりにたくさんのことに取り組んでしまい、正直詰め込み過ぎだったと反省もしています。AWS化、クラウドネイティブ化に加えて、GitによるコードレビューからCI/CDを自動化するGitOpsまで幅広く挑戦しました。システム構築後、関係部門と調整しながらサービスに影響を出すことなく移行するのも非常に大変でした。 取り組んだもの一つひとつが奥深いもので、試行錯誤を加えているうちに、当初のやり方から変わっていったものもあります。Gitは柔軟性が高い分、その使いこなし方はよく議論になります。例えば、有名な開発フロー（ブランチ戦略）にGit Flow、GitHub Flow、GitLab Flowがあります。当初はGitHub Flow一本で進めていたのですが、少し適用が難しいケースもありました。今ではリリースブランチと環境ブランチをそれぞれ準備するGitLab Flowも取り入れ、向き不向きを試行錯誤しながら管理しています。 新しいことに挑戦して学びが深まった結果、過去の自分にはツッコミを入れたくなることもしばしばです。GitOpsとCI/CDに挑戦した結果、ブランチ構成を丸ごと組み替える羽目になったり、自分の過去のコードに日々打ちのめされています。 ただ、自分の未熟さを感じこそすれ、目の前の動くコード、動くインフラから目を背ける訳にはいきません。外部環境もサービスも日々変化しています。触らなければインフラもサービスも緩やかに死んでいきます。 機械学習を活用した監視の高度化など、やりたいことは尽きません。CI/CDの自動化により、改修に伴うリリースを安全かつ頻繁に実現できるようになったので、高い品質を保ちながら、新しいことに挑戦し続けていこうと思います。 BIGLOBEはインフラ構築からアプリ開発まで幅広く取り組んでいる会社です。手作業が得意な人もいれば、自動化が好きな人もいます。インターネットは複数の組織で支えられていることから、交渉力が重宝される場面も多いです。たくさんのお客様に末永く使っていただくサービスを提供するためには、コスト計算やマネジメントスキルも重要になります。ぜひ、いろんな方に来ていただき、一緒になって企業理念である「つながる歓び、つなげる喜び」を生み出していきたいですね。 ※ Amazon、Amazon Web Services、Amazon Aurora、Amazon CloudWatch、Amazon DynamoDB、Amazon Kinesis、Amazon S3、Amazon VPC、OpenSearch、AWS Lambdaは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ Ansibleは、米国Red Hat, Inc. の米国およびその他の国における登録商標もしくは商標です。 ※ fluentd、および、Kubernetesは、米国及びその他の国における The Linux Foundation の商標または登録商標です。 ※ GitLabは、GitLab B.V.の米国およびその他の国における登録商標または商標です。 ※ Terraformは、HashiCorp ,Inc.の米国およびその他の国における商標または登録商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。 今回は、2021年に新卒で入社したエンジニアのインタビューをお届けします。入社2年目となりどのように成長したのでしょうか。1年目をふりかえると共に、今後の抱負についても聞いてみました。 新人エンジニア研修をふりかえって 入社時の不安を乗り越えて、幅広く活躍 エンジニアのコミュニティに参加（Peering Personal／プルリクエスト） エンジニア起点での新規サービス創出を目指して 新人の1年間でどのような成長をしたか 今後の抱負と就活生へのメッセージ ※撮影時のみマスクを外しています。   新人エンジニア研修をふりかえって ―――　今日はよろしくお願いします！島袋さん、白井さんも2年目となりましたね。まずは1年間のエンジニア研修お疲れ様でした！いかがでしたか？   白井 ：2、3カ月でエンジニア研修を終える企業も多いなか、BIGLOBEは週1日の研修を1年間続けるという珍しいスタイルの研修でした。週1日だと、翌週までに復習ができますし、研修で学んだことを実務の中で実践する機会も見つけやすかったので、短期間で詰め込むよりも継続して学べて良かったと思います。   島袋 ：カリキュラムが最初から最後まで全部つながっているので、練りに練った研修なんだなと感謝の気持ちでいっぱいです。 テクニカルスキルの学習パス （ セルフラーニングを後押しするBIGLOBEの新人エンジニア研修 より） 白井 ：研修の締めくくりとなる開発演習では、社内で利用するスキル診断ツールをエンジニアの同期メンバー4人で作りましたね。人事部から依頼されたもので、企画の段階から実現までの全ての工程を経験できました。同期メンバーはそれぞれ個性豊かですが、それぞれの強みをバランスよく発揮しながら楽しく取り組むことができました。   チーム開発演習で開発したスキル診断ツール 島袋 ：そうですね、白井さんの言うとおり誰かに決められた要件のものを作るのではなく、自分たちでアイデアを出しながら進められたのが良かったです。開発部門の方針も、エンジニア組織から提案してモノを作る方向に変わろうとしているので、これからも楽しみですね。   白井 ：8月の1カ月間は「夏の自由研究」ということで、それぞれがペアになって自由に題材を選び、モノ作りに挑戦しました。私はFlutter（モバイルアプリ用フレームワーク）でアプリを制作してとても楽しかったです。 技術以外にも、ロジカルシンキング、事業戦略、ビジネスモデルやマーケティングといったビジネススキルについても学ぶことができ、とても手厚い研修でした。   入社時の不安を乗り越えて、幅広く活躍 ―――　遡ってお聞きしたいのですが、お2人はどうしてBIGLOBEへの入社を決めたのですか？まずは、白井さんからお願いします。   白井 ：実は学生時代は生命医科学という、今の業務からはかけ離れた分野について学んでいたんです。ですが、趣味でしていたプログラミングに興味のベクトルが向いて(笑)、それを活かせる企業を軸に就活しました。 そのなかで、お客さまからの受託開発が多いSIerではなく、自分たちでモノづくりができそうな自社開発寄りの企業を志望し、BIGLOBEへの入社を決めました。   ―――　入社時に不安はありましたか？   白井 ：私は、エンジニアとして採用されたものの情報系出身ではないので、基本的な技術やネットワーク系のこともまっさらな状態だったのが不安でした。 白井 春香（しらい はるか） 基盤本部　マーケティングプラットフォーム部　ビジネスプラットフォームグループ 2021年4月新卒入社 ―――　自ら学び続けているところも選考で評価されたのかと思います！白井さんは入社後どのような仕事をされたのですか？   白井 ：上司から内製開発も経験してほしいということで、 ジー・プラン社 （BIGLOBE関連会社）の内製開発に携わりました。 Gポイント のシステムを改修するため、現場のプログラマーと一緒にテストコードを書いたりしました。 一方BIGLOBEでは、お客さまに安全にご利用いただくための電話認証を改善するプロジェクトの上流工程を担当しました。主に、要件定義書をまとめて依頼を出したり、工程ごとにマイルストンを策定するという作業です。要件定義書の作成は最初は全く分からなかったので苦労しましたが、先輩に聞いたり、過去の定義書を参考にしながら進めることができました。 最初は右も左も分からない状態だったので、2つの異なる仕事を同時並行で進めるのは無理じゃないかと思ったのが本音です。曜日で業務を分けていたのですが、BIGLOBEの業務は止まることがないのでジー・プランの業務日と重なりやりくりが大変な時もありました。 ですが、上流工程だけでは分からなかった現場感を知ることができて良かったです。現場のコードは1つのファイルがとても長かったり、読みづらかったり...。やっていることが複雑で、しかも綺麗にしている最中だったのがその理由ですが、取り組みがいがありました(笑)   ―――　それが見られたのは今後に向けて貴重な経験ですね。自分で書いたコードがそのまま動くわけですが、Javaのキャッチアップはどのように？   白井 ：5月に配属されてから約2カ月間は勉強に充てる時間をもらいました。また、研修で綺麗なコードの書き方を学んでいたのと、配属先の先輩から現場で通用する書き方をレビューしてもらえたので、なんとか戦うことができました。 同期メンバーがJavaの学び方を記事にしていますのでこちらもご覧ください。 style.biglobe.co.jp ジー・プランとBIGLOBEでは、細かい進め方の違いはありましたが、どちらも聞けば丁寧に教えてくれるので、問題なく取り組むことができました。ジー・プランでは、一通りやり方を教わった後、ペアプログラミングも織り交ぜながら伴走してもらい、BIGLOBEでは、まず与えられたものを自分でやってみてから、分からないところを質問しました。進め方の違いも学びになりました。   ―――　異なる仕事の同時並行にさらに週1の研修を乗り越えたとは素晴らしいですね！ 次に、島袋さんにお聞きします。入社動機や、入社時の不安について教えていただけますか？   島袋 ：僕は、情報科学科ではコンピュータのアーキテクチャーやプログラミングを学び、研究室ではマイコンの研究をしていました。無線機を使った分散システムを開発していたこともあって、ネットワークでさまざまな機器をつなげたいという思いからこの業界を志望し、BIGLOBEへ入社しました。 情報系の勉強はしていましたが、情報通信の基礎知識がありませんでした。ネットワークというと機器同士がつながるというざっくりとした理解はありましたし、インターネット自体は普段からよく使っていたものの、どういう仕組みなのか知識がなかったんです。そのような状態でネットワークの部署に配属になったので、ゼロからのスタートでした。   ―――　なるほど。ネットワークにはいろいろな種類があることを入社してから知ったのですね。では、島袋さんの業務についても教えてください。   島袋 ：ISPネットワークグループの所属でバックボーンや対外接続、ルーターの管理をしています。基本的に与えられた仕事は全部任せてもらい、分からないところを先輩に聞きながら進めています。 まずは覚えることが沢山あって驚きましたね(笑)　BIGLOBEではあえて複数種類の機器を導入しているのですが、機器ごとの設定方法だけでなく、機器同士の相性がかなり異なります。理論としてBGP（Border Gateway Protocol：経路制御プロトコル）を理解するだけでは足りないので、実際に現場に出て機器を触りながら覚えるようにしています。   ―――　コロナ禍によってトラヒックが増えていますが、お客さまの料金があがらないようにとコストダウンをミッションとしている部署ですよね。1つの機器に統一すればメンテナンスコストも安くなると思うのですが、なぜいろいろな機器を導入しているのですか？   島袋 ： 特定の装置やソフトウェアに統一すると、装置やソフトウェアに起因する障害が起きた時に、最悪、全ての装置が障害に巻き込まれてしまいます。安定してサービス提供を継続できるようにマルチメーカー構成で冗長構成を組んでいます。 結果的に、多くの種類の機器を管理する必要があるので、それぞれの細かい仕様の違いを理解した上で、やりたいことをどう実現するかを日々考えています。 チームメンバー全員が経験のない新機種の場合は、ベンダーに問い合わせ、どう設定すれば安定して高性能を出せるかレクチャーしていただいたり、別のルータでも使える機能なのかを確認したりしながら進めています。 学生時代は保守切れになった20年前の装置をそのまま使っていたので、こういう現実は会社に入ってから知ることができましたね。 島袋 健司（しまぶくろ けんじ） 基盤本部 ネットワーク技術部 ISPネットワークグループ 2021年4月新卒入社 エンジニアのコミュニティに参加（Peering Personal ／プルリクエスト） ―――　入社してから知ったというなかに、Peering Personalへの参加もありますよね。   島袋 ：そうですね、Peering Personalはネットワークエンジニアのコミュニティならではのイベントです。IX（インターネットエクスチェンジ）事業者が主催しているネットワーク業界の交流イベントで、他社に対して自分をアピールする場でもあります。会社としてではなく、個人としてコミュニティに参加するというのが面白いですよね。実際参加してみて自分の世界がとても広がりましたし、ネットワーク業界の人脈も増えました。そのように他社と協働するのはネットワーク技術部の特徴かもしれません。 競合同士なのに？と不思議に思うかもしれませんが、インターネットはこっちが切れたらこっちに流してと、ネットワーク事業者同士の助け合いがあってはじめて運用できているので、競合同士でも情報交換しているんです。ですので、DDos攻撃による障害なども常に共有したり、 インターネットの課題をどう解決していくか、会社を超えてエンジニアらが議論しています。   白井 ：他社との交流いいですよね、私は社外の人と話すことがほぼないので、そういうイベントも行ってみたいです！   ―――　白井さんはプルリクエストでオープンソースに参加したと聞いています。   白井 ：GitHubが公開しているGitを勉強する学習コンテンツを使って研修を進めていたところ、修正した方が理解しやすい箇所があったのでプルリクエストを出しました。オープンソースの世界では公開したコンテンツをみんなで育てていくのが当たり前なのですが、実際プルリクエストを出してみたらすぐに取り込んでくれました。最初は緊張しましたが、感謝の言葉をいただけて嬉しかったです。   エンジニア起点での新規サービス創出を目指して ―――　すごいですね！ところで、BIGLOBEでは新サービス創出プロジェクトが盛んですが、参加されましたか？   白井 ：開発部門主催の創出プロジェクトに参加して、Amazon Web Services（AWS）のAmazon Comprehend を使用して感情分析掲示板のプロトコルを作り、社内発表しました。投稿した文字から感情を分析して表情の画像を表示するもので、オンライン会議で使えるのではと思い立って作りました。アイデアを出すだけでなく、プロトタイプを作ることもできてとても楽しかったです。 参加する前はニーズから作るものだという固定概念がありましたが、上司から「BIGLOBEの技術的な強みを生かしてシーズから作ってもいいよ」とアドバイスがあり、そういう考え方もあるんだなと非常に参考になりました。   島袋 ：僕は人事部主催のデザインシンキング研修とビジネスアイデアコンテストに参加しました。エンジニア職やビジネス職の同期メンバーと取り組んで、アイデアを発散するフェーズでは非常に盛り上がりました。ですが、まとめるのが下手で(笑)、夜まで議論することもありましたね。議論を尽くすことでかなり仲良くなれたのも良かったです(笑) 新人の1年間でどのような成長をしたか ―――　新人の1年間を通じて成長したと思うところはありますか？   白井 ：内製開発と上流工程に携わったことで成長を感じています。内製開発では毎週プロダクトコードの一部分を取り上げ、もっときれいなコードにするにはどう修正したら良いかをチームメンバーで議論し、たくさんのことを学ばせていただきました。コードがきれいな状態だと世の中の需要に合わせ、素早く機能修正することができます。今後は主に上流工程である設計に携わりますが、現場から出てくるエンジニア視点ならではの意見とお客さま視点の意見を上手く取り入れられるようになりたいと考えています。 マインド的なところでは、以前は何かをする前に考えすぎるところがあったのですが、気にしなくなりました(笑)　手を動かしながら反応を見つつ、進められるようになって良かったと思います。小さく失敗することが重要だと学びました。   島袋 ：技術的に覚えることが多いので必然的に成長につながっています。内製でやろうという方針に加え、新しい技術に触れる機会も多いので、自社だけでなく社外で通じる技術が身につくこと間違いありません。実際のところ、この環境で技術を磨いたネットワークエンジニアの先輩方の中には、BIGLOBEを卒業して活躍されている方も多くいらっしゃいます。 ビッグローブマインド では、「継続的に成長する」を心がけていると同時に、社会を支えるインフラを24時間365日動かしている部隊なので、「みんなを支える存在になる」という意識も常に持っています。部署のメンバーみんなが同じ意思と誇りをもって働いています。   今後の抱負と就活生へのメッセージ ―――　今後の抱負を教えてください。   白井 ：技術的なスキルをもっと高めて、それを活かしてお客さまに喜んでいただける新しいサービスを提案していきたいと思います。エンジニアであってもビッグローブマインドの「お客さま目線にたって、期待を超える」という意識は大事だと思っています。あわせて「継続的に成長する」も日頃意識しているマインドです。 また、「夏の自由研究」が楽しかったので、次は自作アプリを作りたいなと思っています。   島袋 ：まずは、技術者としてもっとスキルを身に着けたいです。今まではルータ単体の管理を任されていましたが、それだけでも、ベンダーさんや他のネットワークエンジニアの方々とのつながりが大きく広がりました。身につけたスキルや人脈を活かしながら、もっと広い視野で、ネットワーク・アーキテクチャー全体の設計なども経験してみたいです。   ―――　さいごに、就活生に一言お願いします！   白井 ：BIGLOBEは優しい人が多く、質問したらそれ以上のことを教えてくれるので成長につながります。就職活動のアドバイスとしては、面接では飾らずに素の自分を出して欲しいということをお伝えしたいです。それがお互いにとって良いことだと思っています。   島袋 ：同感です。BIGLOBEの面接は、話を真摯に聞いてくれて自分を引き出してくれるので、飾る必要は全くありません。そういう社風なので素直に臨まれたほうがいいです。 また、BIGLOBEは少数精鋭で仕事に取り組むので、さまざまな経験ができます。エンジニアとしての市場価値を高める環境がありますし、絶対成長できると思います。   ―――　ありがとうございました。ますますのご活躍を楽しみにしています！   BIGLOBEでは2024年新卒採用のマイページ登録を開始しています！ 少しでもBIGLOBEに興味をもっていただけたらぜひ下記URLよりマイページ登録をお願いいたします。 https://mypage.3050.i-webs.jp/biglobe2024/applicant/login/baitai-entry/entrycd/Style ※右下にございます「初めての方はこちら」より、新規登録をしてください。 www.biglobe.co.jp   style.biglobe.co.jp ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ FlutterはGoogle LLCの商標または登録商標です。 ※ GitHub は、GitHub Inc.の商標または登録商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

JANOGの会場ネットワークはボランティアが構築します。次世代育成の側面もあるこの活動に、学生や新人エンジニアを支援する大人枠として参加しました。 はじめに JANOGとは？ 参加のきっかけ 参加の目的 JANOG49 会場ネットワークの構成 実際の活動内容 リモートでの事前準備（〜1/18まで） ホットステージ ホットステージ1日目 ホットステージ2日目 ホットステージ3日目 会場設営（1/25）、会期（1/26〜1/28） おわりに はじめに 基盤本部 ネットワーク技術部 前野です。 2022/1/26〜28に開催されたJANOG49 Meetingで会場ネットワークの構築ボランティアスタッフとして活動した内容をご紹介いたします。 社外の方々にも共有したいと思い立ったのは、先日開催された JANOG50 Meeting に参加したのがきっかけです。 次回のJANOG51でスタッフに応募される方の参考になれば幸いです。 JANOGとは？ 大まかに説明すると、 国内のインターネットに関わる方々が集まってインターネットをより良くするために活動していこう、というコミュニティです。 ※以下、 JANOG | General Information より抜粋 JANOGとはJApan Network Operators' Groupを意味し、 インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより 日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。 年に2回開催されているJANOGのMeetingでは、様々な業界のエンジニアや営業担当の方、学生など多種多様なメンバーが集まって、インターネットをより良くしていくための議論が行われています。 JANOG Meetingでは来場者が利用するネットワーク（会場Wi-Fi）が毎回提供されており、JANOGの運営スタッフと公募で集まったボランティアスタッフによって、Meetingの度に設計/構築/運用されています。 参加のきっかけ 国内にはJANOGとは別に、以下のような地域ごとのオペレーターグループがあります。 QUNOG（九州沖縄ネットワークオペレーターズグループ） ENOG（越後ネットワーク・オペレーターズ・グループ）、など JANOG49は鹿児島での開催であり、QUNOG運営委員の方の「ネットワーク構築の体験を九州の学⽣や若⼿技術者に提供したい」という思いから、若手のメンバーが多数集められました。 また、若手をサポートする役割として中堅エンジニアも募集されていました。 ※ 詳細な経緯は JANOG49会場ネットワーク解説（PDF: 1.37MB） をご覧ください。 私は大学時代に九州に住んでおり、上記の発表にあるカンファレンスネットワーク構築のボランティアにて大人の方々に大変お世話になっていたため、少しでも恩を返せればと上司に相談して参加することにしました。 参加の目的 ネットワーク構築ボランティアには、主に以下2つの目的を持って参加しました。 ネットワークエンジニアとしてのスキル向上 学生や新人エンジニアの育成支援による業界への貢献 普段の業務では、BIGLOBEの基盤ネットワークの設計/構築/運用をしていますが、 イベントの会場ネットワークのような小規模LANはあまり構築することがないため、 知識の体系化ができる良い機会だと考えました。 また、普段利用していないネットワーク装置に触れられるというのも魅力的でした。 「参加のきっかけ」に書いている通り、スタッフを募集されていたQUNOGの方には学生時代に大変お世話になっていました。 インターネット業界には、「学生時代にお世話になった分は次の世代や若手に返す」というマインドがある（と研究室の教授や私の知っているエンジニアの方は仰っていた）ので、 学生がインターネットに興味を持つきっかけになればと思ったのも動機となります。 ちなみに私がBIGLOBEを志望したのは、上記発表資料に記載のカンファレンスネットワーク構築ボランティアにて、BIGLOBE社員に出会ってその方の人柄に惹かれたのがきっかけです。 JANOG49 会場ネットワークの構成 以下の図は、実際に構築したJANOG49 会場ネットワークの構成図です。 JANOG49 会場ネットワーク構成 JANOG49のホストであるシナプス様のバックボーンネットワークをお借りし、会場で構築したネットワークとVPN接続することで、来場者はシナプス様のネットワークを経由してインターネットへ接続する構成になっています。 また、会場ネットワーク監視用のサーバをKADOKAWA Connected様のネットワーク上に構築し、会期中の通信量や異常を検知してスタッフが対応できるようになっています。 会場ネットワーク構築の際には、ホットステージと呼ばれる準備期間を用意して、 事前に本番と同様のネットワーク構築や試験を済ませておき、設定済みの装置を使って前日や当日までに会場ネットワークを構築することが多いです。 今回のJANOG49 会場ネットワーク構築でもホットステージを実施し、 以下のような役割ごとのチームに分かれて、それぞれの装置の設定や試験を済ませて本番を迎えました。 Aチーム：監視システム、可視化ツール構築 Bチーム：シナプス様のバックボーン〜会場ネットワーク間のVPN開通 C〜Fチーム：会場ネットワーク機器の設定（スイッチやアクセスポイントなど） ※ 実際に使った装置などの情報は JANOG49ネットワーク構成（PDF: 1.62MB ） に記載があるので興味がある人はご覧ください 実際の活動内容 私の場合は2021年12月下旬に大人枠（学生や新人エンジニアの教育兼チームの取りまとめ役）としての参加が決定し、 会場内に設置するスイッチをメインで設定するCチームのリーダーに任命されました。 今回のネットワークチームは、次世代の教育も兼ねていたことから人数が多く、 A〜Fの6チームと上位のファシリテータを含めて合計40人程度の大規模な組織となりました。 チームへのアサイン後は、大きく分けて以下の4つのステップで構築を進めて行きました。 リモートでの事前準備（〜1/18まで） ホットステージ（1/19〜1/21） 会場設営（1/25） 会期（1/26〜1/28） リモートでの事前準備（〜1/18まで） ホットステージや会期に向けて事前準備をするフェーズです。 装置や回線などの設備調達や基本的なネットワーク設計は、ホストであるシナプス様やJANOG運営スタッフの方々が進めていたため、 A〜Fのネットワークチームのメンバーは主に以下のような準備を進めていきました。 ドキュメントの読み込み ネットワーク要件、簡易構成図、会場フロア図などを確認して構築するネットワークのイメージを掴む 事前勉強 構築機器のマニュアルやホストのシナプス様が用意してくださったリモートアクセス環境を使って事前に勉強 リモートミーティング 顔合わせや準備状況の共有などを実施 12月下旬頃から2〜3回程度（約1時間/回） 詳細設計 担当分の機器へのホスト名割り当てやアドレス割り当てなど ホットステージ 本番と同じ装置を使ってネットワークを構築し、試験をして実際にネットワークが正常に動作するかを確認するフェーズです。 自チームの担当だったスイッチでは、主に以下のような設定をしていきました。 アクセス設定（ローカル、リモート接続の許可） 管理系設定（NTP、SNMP、Syslogなどの管理系プロトコルの設定) ポート設定（ポートVLAN/タグVLAN 、LLDPの設定 、STPの設定、アクセスポイント向けPoE設定など） なお、ホットステージ開始時点では、上記のような何を設定するかといった項目と簡易的なネットワーク構成図、使用するアドレスなどの最低限の情報しかありませんでした。 そのため、実際の装置への設定については、以下の方法を組み合わせて進めて行きました。 実機のコマンドを見ながら勘で設定 マニュアルを見る Webで検索 詳しい人に相談 基本的には上記のように自力で考えながら設定していき、問題や不具合があった際には他チームや上位スタッフに共有・相談する形でホットステージは進んでいきます。 商用環境の構築とは違って、その場で設計や設定を考えながら進めていけるところがホットステージの魅力の一つだと思います。 私は大人枠として参加したため、チームメンバーの学生が自力で設定しているのを見守りながら、何のために設定をしているのか、設定する機能や装置が実際にはどういう使われ方をするのかなどを説明していました。 ホットステージ期間は3日間でしたが、その内訳は以下の通りでした。 ホットステージ1日目 足りない設計を補完したり設定内容を説明したりしながら、学生メインでスイッチの単体設定を実施 ホットステージ2日目 スイッチの設定の続きや無線LANコントローラの設定 他チームの装置との結合試験 スイッチ間やPC〜スイッチ〜PCの接続によるEnd-to-Endの試験 他チームのお手伝い ホットステージ3日目 アクセスポイントの接続試験、電波測定 アクセスポイントへのクライアント接続試験 スマホやPCをアクセスポイントにつなげて、インターネット接続ができるか、接続クライアントの認証状態が見れるか、などを確認していく 他チームのお手伝い 事前設営時のチェックリスト作成 撤収作業 予定よりも早く設定が終わって空いてしまった時間には、 学生向けの説明やUTP（LAN）ケーブルの作成などもしていました。 参考までに、ホットステージの様子を載せておきます。 会場の様子 終了ミーティングの様子 前野（左下）が学生に指導しているところ 会場設営（1/25）、会期（1/26〜1/28） 実際に本会場のネットワークを構築・運用していくフェーズです。 会期中はモニタリングシステムを使って異常を検知し、問題が発生した際には原因を切り分けて対処していきます。 プログラム終了後には構築したネットワークを解体し、梱包・配送手配といった後片付けをしてネットワーク構築ボランティアとしての活動は終了します。 残念ながらこの時期にはコロナの波が来ており、私は参加できなかったため、和気あいあいとしているネットワーク構築スタッフのSlackを眺めていました。 途中で障害もあったようですが、適切に対応して無事3日間の運用を終え、3日目の20時頃には撤収作業が終わったようです。 参考までに、以下に設営/会期中の様子を載せておきます。 設営の様子 会期中のモニタリングの様子 おわりに 今回、以下の目的を持って会場ネットワーク構築ボランティアに大人枠として参加してきました。 ネットワークエンジニアとしてのスキル向上 学生や新人エンジニアの育成支援による業界への貢献 チームリーダーとしての参加を通じて、主体的に動く力や人に教える力が向上したり、触ったことのない装置を使ってネットワークを構築することでエンジニアとしてのスキルが向上したりと、普段の業務とは違った成果が得られたと思います。 ただ、事前設営/会期に参加できなかったため、構築時や運用時の教育や自身の働きを見せることができなかったことが心残りではあります。 またコロナ禍ということで、夜の懇親会がなかったり、ランチも大人数で行けなかったりと、醍醐味である人との交流があまりできなかったのも残念ではありました。 コロナ禍であっても、工夫しながらわいわい交流できるといいですね。交流を通じて、若い世代に業界の楽しさをもっと伝えていきたいと思います。 今回のように大規模なネットワークを教育目的で構築するボランティアはなかなかありません。しかし、JANOG Meetingでは毎回ネットワーク構築チームを募集しているので、興味がある方はぜひ参加してみると良いと思います。 他社のエンジニアと一緒にネットワークを構築することで、自身のスキル向上だけでなく、モチベーションやコミュニケーションスキルの向上、今後業界を支えていく仲間ができたりと、得られるものがたくさんあるからです。 JANOG49ネットワークチーム活動については、以下のYouTubeでも話されているので、興味がある方はぜひご覧ください。 www.youtube.com 以上です。 最後までお読みいただきありがとうございました。 ※ YouTubeは、Google LLC の商標です。 ※ Slackは、Slack Technologies, Inc.の登録商標です。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

基盤本部（開発部門）の木下です。前回、Java 17 の新機能を使ってドメイン駆動設計（Domain Driven Design: DDD）のモデリングの表現力を高める例をご紹介しました。 style.biglobe.co.jp 代数的データ型（Algebraic Data Types）を導入するのがポイントなのですが、馴染みのないメンバーも多かったので、実例を使って詳しく解説してみました。関数型プログラミング由来のとても便利な道具です。ぜひ活用してみてください。 代数的データ型とは 直積型 直和型 直和型の Java での実装 ベタに class で表現してみる 2つのクラスと interface で実現 安全に利用できるメソッドを提供する おわりに 代数的データ型とは 代数的データ型とは、基本となる型を組み合わせて作られる型のことです。 代数的データ型は直和型と直積型の2つからなります。 直積型 直積型のほうが馴染み深い概念なのでこちらから説明します。 直積型というのは、いくつかの型を同時に保持するような型を言います。 Java では、 class が直積型です。 class Person { String name int age } Person は name と age を両方保持しています。 特に新しい概念はないと思いますが、こういうものが直積型と呼ばれるもの（の一つ）です。 言語によってはペアとかタプルという機能があるものもありますが、これも直積型の一種です。 直和型 直和型というのは、いくつかの型のうちの一つだけを保持するような型です。 例えば何かの処理の結果を表すために、成功したときは処理結果を保持し、失敗したとき は失敗理由を保持したいとします。 直和型を使うと、以下の情報を一つの型で保持することができます。 成功したのか失敗したのかどちらなのか 成功した場合は処理結果 失敗した場合は失敗理由 場合によって異なる型を持つような型がほしい、というのが直和型の要求です。 直和型は直積型と違って Java に直接対応する機能はありません。 なので Java でわざわざ代数的データ型と言う場合は直和型について議論したい場合が多いです。 直和型の Java での実装 Java でがんばって直和型を実装するにはどうしたら良いか説明していきます。 ベタに class で表現してみる 先ほどの成功失敗の例をもう少し具体的にして、整数除算の結果を表現したいとしましょう。 除算の仕様は以下とします。 負の数を習っていない小学生のために、除数・被除数ともに負でない整数とし負の数が来たらエラー まだ余りを習っていない（略）、ちょうど割り切れない場合はエラー 除数が0の場合はエラー 成功か失敗かを示すタグを持たせて (isSuccess) 、答えとエラー Optional で並べる実装例です。 enum DivError { NEGATIVE_DIVISOR_OR_DIVIDEND, NOT_DIVISIBLE, DIVISION_BY_ZERO, } record DivResult( boolean isSuccess, // 成功か失敗か Optional<Integer> quotient, // 成功した場合の商 Optional<DivError> divError) { // 失敗した場合の理由 static DivResult success( int quotient) { return new DivResult( true , Optional.of(quotient), Optional.empty()); } static DivResult failure(DivError divError) { return new DivResult( false , Optional.empty(), Optional.of(divError)); } } 除算の実装は次のように書けます。 DivResult div( int dividend, int divisor) { if (divisor == 0 ) { return DivResult.failure(DivError.DIVISION_BY_ZERO); } if (dividend < 0 || divisor < 0 ) { return DivResult.failure(DivError.NEGATIVE_DIVISOR_OR_DIVIDEND); } if (dividend % divisor != 0 ) { return DivResult.failure(DivError.NOT_DIVISIBLE); } return DivResult.success(dividend / divisor); } div メソッドを使う側は次のように書けるでしょう。 String testDiv( int dividend, int divisor) { DivResult result = div(dividend, divisor); if (result.isSuccess()) { return "答え: %d" .formatted(result.quotient().get()); } else { return switch (result.divError().get()) { case NEGATIVE_DIVISOR_OR_DIVIDEND -> "除数または被除数が負" ; case NOT_DIVISIBLE -> "割り切れない" ; case DIVISION_BY_ZERO -> "0による除算" ; }; } } 機能は実装できていますが、以下のような点に課題があります。 DivResult 型がドメインが取るべき以外の状態もとれる Optional のどちらか一方にしか値が入っていないということが表現できていない すなわち、quotient と divError の両方に値を入れることもできるし、両方 none にすることもできてしまう 利用側が気を付けないと不正なアクセスができてしまう success/failure にかかわらず quotient, divError が Optional でしか取れないので、 間違ったほうを Optional.get() すると例外発生 2つのクラスと interface で実現 最初の課題 DivResult 型がドメインが取るべき以外の状態も取れてしまう問題に対処します。 成功・失敗の2つの状態があるので、その2つでクラスを作ります。 record DivResultSuccess( int quotient) {} record DivResultFailure(DivError divError) {} 2つのクラスに分かれていると使うときに困るので、共通の interface を作って1つの型として扱えるようにします。 前節と同じように success() と failure() でインスタンスを作れるようにします。 interface DivResult { static DivResult success( int quotient) { return new DivResultSuccess(quotient); } static DivResult failure(DivError divError) { return new DivResultFailure(divError); } } record DivResultSuccess( int quotient) implements DivResult {} record DivResultFailure(DivError divError) implements DivResult {} 2つの record 型は内部的なものなので interface の inner class にするとわかりやすくなります。 また、この interface を継承して別の状態を作られたりすると困るので、 sealed を付けてこの2つの状態以外を実装できないようにします。 内部クラスなので冗長な名前は短くしました。 sealed interface DivResult permits DivResult.Success, DivResult.Failure { static DivResult success( int quotient) { return new Success(quotient); } static DivResult failure(DivError divError) { return new Failure(divError); } record Success( int quotient) implements DivResult {} record Failure(DivError divError) implements DivResult {} } これで、2つの状態のどちらかだけを持つクラスが実現できました。 安全に利用できるメソッドを提供する 2つ目の課題であった、利用側が気を付けないと不正なアクセスができてしまう問題ですが、前節の sealed 版 DivResult 利用すると次のようになります。 String testDiv( int dividend, int divisor) { DivResult result = div(dividend, divisor); if (result instanceof DivResult.Success success) { return "答え: %d" .formatted(success.quotient()); } else if (result instanceof DivResult.Failure failure) { return switch (failure.divError()) { case NEGATIVE_DIVISOR_OR_DIVIDEND -> "除数または被除数が負" ; case NOT_DIVISIBLE -> "割り切れない" ; case DIVISION_BY_ZERO -> "0による除算" ; }; } else { throw new RuntimeException( "状態不明" ); } } Java 16 以降で使える instanceof のパターンマッチング機能を使っているので Optional のときのように例外が起こるようなことはありません。 しかし網羅性検証ができていないので、余計な else 節を書かなければなりません。 また片方の状態の分岐を書き忘れてもエラーにはなってくれません。 このような場合、社内では mapEither というメソッドを作ることがよく行われています。 DivResult に mapEither を追加します。 関数を2つ渡すと今の状態に合致したほうの関数だけが呼ばれる、というメソッドです。 sealed interface DivResult permits DivResult.Success, DivResult.Failure { <T, R> R mapEither( Function<Success, ? extends R> successMapper, // 状態が成功のときに呼ばれる関数 Function<Failure, ? extends R> failureMapper // 状態が失敗のときに呼ばれる関数 ); static DivResult success( int quotient) { return new Success(quotient); } static DivResult failure(DivError divError) { return new Failure(divError); } record Success( int quotient) implements DivResult { @Override public <T, R> R mapEither( Function<Success, ? extends R> successMapper, Function<Failure, ? extends R> failureMapper) { return successMapper.apply( this ); } } record Failure(DivError divError) implements DivResult { @Override public <T, R> R mapEither( Function<Success, ? extends R> successMapper, Function<Failure, ? extends R> failureMapper) { return failureMapper.apply( this ); } } } 典型的な使い方は、ラムダで成功時の関数と失敗時の関数を渡します。 String testDiv( int dividend, int divisor) { DivResult result = div(dividend, divisor); return result.mapEither( success -> "答え: %d" .formatted(success.quotient()), failure -> switch (failure.divError()) { case NEGATIVE_DIVISOR_OR_DIVIDEND -> "除数または被除数が負" ; case NOT_DIVISIBLE -> "割り切れない" ; case DIVISION_BY_ZERO -> "0による除算" ; } ); } success と failure に書き忘れがないかはコンパイラがチェックしてくれるようになりました。 ちなみに switch のパターンマッチング という Java のプレビュー機能を使うと mapEither のようなものを用意しなくてもきれいに書けるようになります。 次の LTS である Java 21 に入ってくれると嬉しいですね。 String testDiv( int dividend, int divisor) { DivResult result = div(dividend, divisor); return switch (result) { case DivResult.Success success -> "答え: %d" .formatted(success.quotient()); case DivResult.Failure failure -> switch (failure.divError()) { case NEGATIVE_DIVISOR_OR_DIVIDEND -> "除数または被除数が負" ; case NOT_DIVISIBLE -> "割り切れない" ; case DIVISION_BY_ZERO -> "0による除算" ; }; }; } ここまで紹介した代数的データ型 / 直和型を使うことで、モデリングの精度を上げることができます。DDDのドメインサービスとアプリケーションサービスをきれいに分離する例について以前書いたので、ぜひ読んでみてください。 style.biglobe.co.jp おわりに BIGLOBE では、DDD を活用したサービス・アーキテクチャの設計・開発に取り組んでいます。この記事を読んで、より良いDDDについて考えてみたい方、DDD に興味を持ち挑戦したいと思った方、BIGLOBE で一緒に取り組んでみませんか？ぜひカジュアル面談にいらしてください。 hrmos.co ※ Javaは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。 BIGLOBEの開発部門（基盤本部）では、新卒入社社員向けに「新人エンジニア育成プログラム」を1年かけて実施しています💪 先日、プログラムを終え2年目を迎えた4名のエンジニアが成果発表を行うというので参加してきました！今回はそのレポートをお届けします♪ 21年卒エンジニア、22年卒エンジニア、育成関係者と記念写真 （前列左から4名が今回の発表者、21年卒エンジニア／ 後列中央5名が22卒エンジニア） はじめに 新人エンジニア育成プログラム この1年で何を経験し、どう成長したか 基盤本部長と社長から、今後に向けて おわりに   はじめに この発表会は、入社から1年かけて育成に関わり見守ってくれた上司や先輩、またエンジニア育成担当者へ、これまでに得られた学びや成長度合いを一人ひとりプレゼンする節目のイベント。思い切りアピールするとともに、感謝の気持ちを伝え、一人前のエンジニアとしてスタートラインに立ちます。 聴衆には後輩となる今年度の新入社員の姿も。1つ上の先輩からヒントを得ようと真剣な表情で発表を聞いていました。 ここで、発表会後の感想を、アンケートから一部抜粋してご紹介します。幹部や上司が見守る中、緊張しつつも和やかな雰囲気で発表できたみたいですね！   発表後のアンケートより抜粋 発表者の感想（21卒エンジニア） ・1年間何をやって、何ができるようになったか、どうチームや会社に貢献できたかを振り返るきっかけになった。 ・発表後、上位上司からねぎらいの言葉を掛けてもらえたのが非常に嬉しかった。 ・フィードバックも貰えたので、ここを区切りに新たに頑張っていこうという気持ちになった。 ・幹部に対面で発表するのはとても緊張したが、始終和やかな雰囲気で、話しやすかった。   先輩の発表を受けての感想（22卒エンジニア） ・技術的にどのように成長していけるのかが分かり、モチベーションの向上に繋がった。 ・1年後の自分がイメージでき、今足りていないこと、この先必要になってくることを知ることができた。 ・先輩たちの1年間の具体的な取り組みを知り、配属先での業務イメージがより固まった。 ・同じプログラムを受けているにもかかわらず、全員が個性を出しながら成長しているのが分かり、励みになった。 ・先輩たちのbefore afterを知り、自分でも頑張れば活躍できる可能性を感じられた。 新人エンジニア育成プログラム まずは、新人エンジニア育成プログラムについてご紹介します。 月曜日から木曜日までの週4日間は配属先でOJTを実施し、実際の業務の中で経験学習をします。そして、毎週金曜日はエンジニア育成担当が実施する共通研修で学びます。 共通研修には、ビジネススキル・テクニカルスキル研修やリーダーインタビュー、チーム開発演習などが含まれます。 ビジネススキル・テクニカルスキル研修、リーダーインタビューについては、エンジニア育成担当の高玉が書いたこちらの記事にまとめていますのでご覧ください。 style.biglobe.co.jp style.biglobe.co.jp また、チーム開発演習は社内の「こんなのがあったらいいな」を内製で作っちゃおうという面白い取り組みです。会社に貢献できると共に、成功体験を得ることもできます。 今回は、人事部からの依頼で「従業員スキル診断ツール」の開発に取り組みました。人事部の人材開発担当がプロダクトオーナーとなり、新人エンジニアのみなさんによって開発され、先日無事リリースとなりました！ ビッグローブマインド   にあるように「継続的に成長し続ける」ため、またその成長を加速させていくために、自身のスキルの現在地を正確に測り、次に目指す目標を作る必要があります。新人エンジニアが作ってくれたこのツールを運用することで、それが実現できると同時に社員の適材適所や今後やりたいことなどが可視化され、社内ローテーションなどにも活用できるようになるんです😃 昨年度のチーム開発演習についてはこちらをご覧ください。 style.biglobe.co.jp これまで全く知識がなかったというAmazon Web Services（AWS）についても、実際に触れながら知識を吸収していき、結果的にSAA（Solutions Architect – Associate）やDVA（Developer - Associate）の資格を取得したメンバーもいます。なかには配属1カ月という最速で取得したツワモノも...！   ここからは、少しですが、本人たちの発表内容と上長からのフィードバックをご紹介していきたいと思います。   この1年で何を経験し、どう成長したか 事業プラットフォーム部門 ホームインターネットサービス部　小泉 入社時はPython、C++の技術経験しかなかったものの、今ではドメイン駆動設計 ( Domain Driven Design: DDD ) などの設計手法を用いたり、幅広い技術に触れたりしながら手を動かしていると話す小泉。 「設計って？テストって何するの？」という状態から、開発の一連の流れを経験することで理解を深めていき、サービスをリリースできたといいます。 当社のエンジニアは、頻繁に 「勉強会」 を行っています。小泉も、毎日の夕会で行われる勉強会で学ぶ習慣がつき、今では身に着けた知識を武器に自ら手を挙げ率先して業務に励んでいるそうです。 「開発はとにかく楽しいので、今後もモノを作り続けていきたいです。幅広い知識と自分だけの強みを持って、会社だけではなく外の世界にもインパクトを与えられるモノを作れるエンジニアを目指します。そして継続的に成長して会社に貢献したいです！」 小泉はJavaの勉強方法をTechBlogで公開しています。よろしければこちらもご覧ください。 style.biglobe.co.jp 事業部プラットフォーム部門　CDO（最高デジタル責任者）　黒川 黒川 「1年ですごく成長しましたね。今後は事業貢献をしながら是非先輩として後輩たちを育成していって欲しいです。 チーム開発演習で開発した従業員スキル診断ツールは、試作段階でのフィードバックを見事に反映してくれました。新しいプロジェクトに必要なスキルを持つ人がどこにいるか可視化されて使いやすいものになっています。さらに品質を高めて全社で広く使ってもらえるよう、アジャイル開発でブラッシュアップしていって欲しいですね」 基盤本部 ネットワーク技術部　島袋 学生時代はマイナーかつ特定機器向けのネットワークを使っていたため、入社当時はほぼゼロからのスタートだったという島袋。TCP/IPの知識もなかったものの、この1年でさまざまな業務を経験し、対外接続、バックボーンネットワーク、ルータ・スイッチの知見を習得したと語りました。 「入社前はBIGLOBEが対外接続しているのを知らなかった」という島袋ですが、IX（インターネットエクスチェンジ）事業者などが主催するネットワークエンジニアの勉強会に参加し、対外接続のためにエンジニア同士が自己紹介をするPeering Personalでの発表にも挑戦しました。 「品質や通信速度を一定に保つ必要があるというインフラエンジニアの難しさも知りましたが、AS2518*の運用や、大変高額なルータの検証をしたりなど、貴重な経験をさせてもらっています。今後はネットワークエンジニアとして交渉術、調整術、周囲を巻き込む力も習得していきたいです！」 ＊ AS(Autonomous System：自律システム)は、各組織が運用するIPネットワークに与えられる固有の番号であり、AS2518はBIGLOBEが運用するIPネットワークを指す。 執行役員 基盤本部　高宮 高宮 「島袋さんの言うとおりで、ネットワークエンジニアは他のインターネット事業者と協働するための術が必要です。今回Peering Personal での発表を経験して、その能力を高めていっているのはとてもいいことだと思いました。今後も その気づきを活かして成長につなげていってください」 基盤本部 マーケティングプラットフォーム部　白井 学生時代は情報系の出身ではなく、趣味でプログラミングをしていた程度、と入社時は不安もあったという白井。そんななか、入社間もなくBIGLOBE関連会社であるジー・プラン社も兼務することになります。BIGLOBEでは認証システムの上流工程を、兼務先では内製開発の開発およびテスト工程を担当し、知識を吸収していきました。 システム開発の一連の流れを習得するなかで、技術的スキルはもちろんのこと、お客さま目線でのシステム設計の考え方や、綺麗なコードの書き方、他チームとの関わり方も学んだといいます。 「この1年でいろいろな言語でアプリも作りました。これからもアイデアをプロトタイプ開発して、提案していきたいと思います。そして、システム設計と内製開発、両方の経験を活かして貢献し、お客さま目線バリバリのエンジニアになるのを目標に頑張っていきます！」 基盤本部 副本部長　水守 水守 「内製開発も経験してもらいたくて、兼務してもらいました。その分2倍の苦労があったと思いますが、結果として違う視点で物事を把握できるようになったと思います。それは必ず後から生きてくるので、二刀流の経験を糧にどんどん貢献していただきたいです」 リアライズ事業本部 第3室　森田 入社時は、基盤本部でインフラ運用、自動化、社内システム開発を担当し、現在は新規事業に携わる部門で、空調制御AIの技術サポートや、社内スマホアプリの開発、 新サービス創出活動 を担う森田。幅広い技術や知識に触れ、面白い１年だったと語りました。 森田は、B IGLOBEで管理するサービス・システムの運用に必要な情報（システム 構成仕様書、連絡先情報等）を管理する社内システムを開発し、今期無事リリースまでこぎつけました。企画、設計、開発、デザイン、テストまで全てやりきったといいます。 現在は、新サービス創出活動で特許を2件出願し、実現に向けて取り組んでいるそうです！ 「 この先数年はサービス企画とサーバサイドエンジニアとして極めたいです。そして、お客さまの困りごとに基づいて多くの人を助け、喜んでいただけるサービスを世に出したいです！」 最後に「BIGLOBEのエンジニア育成は世界一手厚い！」と感謝の気持ちを述べてくれました。 高宮 「森田さんが中心となって開発に携わったシステムは、BIGLOBEのサービスを24/365で運用できるようにするための監視、構成情報を管理するとても重要なシステムです。あり物で運用しがちなところを、新人の森田さんが入ったおかげで内製開発しようとなったのかと思っています。 この4月に新サービス創出部門へ自ら手を挙げて異動し、”エンジニアが直接サービス創出に貢献する”という目指すべき姿を、熱意をもって早々に体現しているのは頼もしいです」 基盤本部長と社長から、今後に向けて 取締役執行役員常務／基盤本部長　鴨川 鴨川 「発表お疲れさまでした。そして、育成に関わった関係者のみなさん、ありがとうございます。我が子を世に出す思いですね。2年目以降は、研修という敷かれたレールを脱し、自燃型（じねんがた－積極的に自ら行動する－）を意識してください。また、BIGLOBEエンジニアの中では遜色ないとしても、社外の他のエンジニア、つまり自己のマーケットバリューを常に意識することも大切です。期待しています！」 代表取締役社長　有泉 有泉 「内製でモノを作れるのは良い経験です。みなさんの発表のなかで、たびたび”お客さま目線のエンジニア”と話がでました。是非今度、オペレーションセンターやコールセンターを見てくるといいですよ。お客さま目線を身につけるヒントや気づきが得られるはずです」   おわりに 今後のヒントとなるフィードバックをいただき、発表会は無事終了しました。 一人ひとりがとてもたくましく成長し、プレゼンも堂々と立派にこなしていて感動しきりです！ 本人同士もお互いの成長ぶりを知って、刺激にもなったのかなと思います。 それぞれの個性と強み、そしてこの育成プログラムで得た学びを業務に活かして成長を続けてくれることと思います。今後の活躍も期待しています！   以上、「新人エンジニア育成プログラム」成果発表会レポートでした！   ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。   www.biglobe.co.jp

開発部門（基盤本部）でエンジニアの育成を担当している高玉です。 BIGLOBEでは週に1日、集合型の新人エンジニア研修を開催しています。インターネットに公開された教育コンテンツを活用しながら、手を動かして学ぶ（Learn by doing）が特長です。 style.biglobe.co.jp 研修の後に必ずアンケートに回答してもらっているのですが、新人ならではの質問をもらえるのがいつも楽しみです。 さて、テスト駆動開発（Test Driven Development：TDD）について学んだ後にもらったのが、次の質問です。 Q 仕様がコロコロ変わるケースや、コードを触りながらわかっていくような非機能要件などには適用できなさそうだと思いました。どういったケースにTDDが用いられるのでしょうか。逆にどういったケースには向かないのでしょうか？ 研修の様子をお伝えするために、この質問にどう回答したのかをご紹介していきます。 質問の背景を理解し、質問を分解する Q1. どういった場合にテストコードが必要になるのか？ Q1a. 仕様がコロコロ変わる場合にテストコードは必要か？ Q1b. コードを触りながら分かっていく技術検証にテストコードは必要か？ Q1c. 非機能要件の検証にテストコードは必要か？ Q2. テストコードをTDDを使って作るべきか？ 「けど『TDD』で検索すると、否定的な意見も多いですよね？」 「質とスピードはトレードオフの関係にある」は大きな誤解 まとめ 質問の背景を理解し、質問を分解する 若いメンバーからもらったせっかくの質問です。ただ反射的に答えるのではなく、一呼吸おいて、その質問が生まれた背景についても思いをはせつつ、質問を分解していきます。 留意すべき背景は、新人エンジニアたちは学生時代にテストコードを書く機会が無かった点です。経験が少なければ、異なった概念も同じものに見えてしまいます。そこで、TDDの質問ではあるものの、自動テストやテストコードの必要性について聞かれているかもしれない、と判断しました 1 。 そこで、Q を次の2つの質問に分解してみます。 Q1. どういった場合にテストコードが必要になるのか？ Q2. テストコードをTDDを使って作るべきか？ ここで、Q1の「どういった場合に」ですが、元のQには「仕様がコロコロ変わるケース」と「コードを触りながら分かっていく非機能要件」の2つの状況が問われています。後者は、非機能要件といいつつ「技術検証」が埋もれているようです。そこで、Q1を、以下の3つの質問に分解してみました。 Q1a. 仕様がコロコロ変わる場合にテストコードは必要か？ Q1b. コードを触りながら分かっていく技術検証にテストコードは必要か？ Q1c. 非機能要件の検証にテストコードは必要か？ 分析の結果、5つの質問に分解することができました。それぞれについて回答していきます。 Q1. どういった場合にテストコードが必要になるのか？ 今後メンテナンスする必要のあるプロダクトコードには、テストコードが必要です。反対に、使い捨てのコードならテストコードも不要です。 ただし、使い捨てのコードであってもテストコードを書くことで作業が効率化される場合があります。例えば、ゴールを達成できたかどうかを何度も繰り返し目視で確認するような場合です。テストコードを書いて楽になるなら、ぜひ書いてくださいね。 Q1a. 仕様がコロコロ変わる場合にテストコードは必要か？ プロダクトコードをメンテナンスするなら必要です。 とはいえ、仕様が変わるたびにテストコードも書き直すのは、コストがとてもかかってしまいます。であれば、そもそも「仕様がコロコロ変わる」ことをどうやったら防げるかを考えてみてください。 どうして仕様が変わるのでしょうか？もしかすると、顧客のニーズを把握することなく、出たとこ勝負でプロダクトを開発しているのかもしれません。全社の新人研修で学んだ デザイン思考 を活かし、できるだけコストをかけずに（わざわざコーディングせずに）プロトタイピングをして、顧客のニーズを検証できないか工夫してみましょう。 なお「プロトタイピング」について、エンジニアがよくよく心がけたいことがあります。それは「捨てるつもりで書いたプロトタイプのコードが、そのままプロダクトコードになる悲劇が生まれやすい」という経験則です。 プロトタイプのコードは絶対に捨てても良いこと、プロダクトを開発するタイミングで新しくコードを作り直して良いことを、必ず確認してください。もしその約束が取り付けられないのであれば、色々と覚悟を決めてください。 Q1b. コードを触りながら分かっていく技術検証にテストコードは必要か？ 技術検証に使ったコードを捨てても良いのなら、テストコードは不要です。 なお、技術検証が合格か、不合格かの確認に手間がかかるなら、自動化しましょう。その自動化に自動テストが役立つなら、テストコードを書きましょう。 Q1c. 非機能要件の検証にテストコードは必要か？ 非機能要件（例えば、性能やセキュリティ）が満たされていることをどうやって確認していますか？その確認作業を自動化したほうが効率が良いのなら、自動化しましょう。 サービスを運用しはじめた後も、非機能要件を満たしているかどうかを常時確認する必要がありますか？もしその確認に自動テストが役立つなら、テストコードを書きましょう。 Q2. テストコードをTDDを使って作るべきか？ これは、その人の技術レベルや好みに依存します。 TDDは、達成したいことを小さなゴールに分解し（タスクばらし）、それら小さなゴールを達成するテストを書き（テストファースト）、そのテストをなんとかクリアできるプロダクトコードを書き、テストに守られた状態を作ってからプロダクトコードをキレイにします（リファクタリング）。このようにタスクばらし→テストファースト→リファクタリング、の順番でプロダクトコードとテストコードを書くのがTDDです。 BIGLOBEでは「プロダクトコードとテストコードを一緒に書いて、1つのプルリクエストにまとめて提出すること」をルールとして決めているチームが多いです。CI/CDのためにも自動テストが必須だからです。ただし、そのテストコードをTDDで作ることは強制していません。人によっては、リファクタリングする必要のないキレイなコードを一発で書けるからです。 とはいえ、コードを書いたり、レビューでもまれる経験が少なければ、そんなキレイなコードをいきなり書くことは難しいでしょう。TDDを（自転車の練習で使った）補助輪として活用してください。 なお、ペアプログラミングをする時だけ、テストファーストで書くという人もいます。ペア同士がこれからやるタスクをハッキリさせる効果があるためです。 ちなみに「TDDは好みではない」のと「TDDすら実践する技能がない」は大きく違います。脚力がなければ、自転車をこげないのと同じで、基本的なコーディングスキルがなければ、何をしても、いつまでたっても苦しいものです。時には codewars.com などのプログラミング学習サイトでもくもくとお題に取り組み、コーディングスキルを地道に鍛えることも必要です。 「けど『TDD』で検索すると、否定的な意見も多いですよね？」 そうなんです。けれど、その根底にあるのは「品質を落とせば開発スピードが上がるのでは？」という幻想にある、と私は学びました。TDDの伝道師である @t_wada さんのスライドからです。 「質とスピードはトレードオフの関係にある」は大きな誤解 質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition - Speaker Deck speakerdeck.com スピードを求めると、ソフトウェアの内部品質が犠牲になる。システムの中がどれだけ整理整頓されているか？の指標であり、外からは分からない。 具体的には、保守性が犠牲になる（さらに保守性とは、テスト容易性、理解容易性、変更容易性のことを指す）。 内部品質が悪化すると、すこし時間をおいてから、外部品質（ソフトウェアの外から分かる機能や使い勝手など）が悪化し、結果的にビジネスが失敗する。 逆に開発スピードを落とし、時間的余裕を与えたとしても、上手くいかない場合がある。それは、エンジニアの技術力が低い場合。技術力が低ければ、内部品質を担保できない。 正しい因果関係は「内部品質を高く保てば、リリースが早くなる」という事実。 では、どうやって内部品質を高く保てばいいのでしょう。同じく和田さんの講演「組織にテストを書く文化を根付かせる戦略と戦術」では、次のように述べています。 組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition - Speaker Deck speakerdeck.com いくらテストをしたところで、内部品質は良くならない。結局はエンジニアの技術力と、できあがるプロダクトコード次第。 とはいえ、テストがあることで品質の劣化に気が付くことができる。体重計を使うことでダイエットしやすくなるのと同じ。 だから、テストがある組織は、開発スピードを劣化させる前に、品質の劣化に気が付き対処することができる。 逆に言うと「テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです」 一般的には「質とスピードはトレードオフの関係にある」ことが信じられていますが、それが実は誤っているという事実はなかなか受け入れられないものです。さらに「エンジニアの技術レベルを高めなければ、開発スピードは上がらない」という身もふたもない現実も、同様に受け入れがたいものでしょう。 ただ、この事実を真摯に見つめ、精進する覚悟を決めるしかない、と私は思います。 以前、リファクタリングを通じて内部品質（保守性・変更容易性）を高めるコードの例を示したことがあります。この例は、内部品質を高めると、開発スピードが上がる例にもなっています。 style.biglobe.co.jp リファクタリングにより内部品質を高めたコードの方が行数は多くなります。しかし、機能追加の際に読む必要のある行数をわずかながら抑えることができているのです。一般的に、コードを書く時間より読む時間の方が10倍多いと言われているので、このわずかの差が大きな効果を生み出します。 まとめ 新人エンジニア研修でもらった質問に、回答していく過程をご紹介しました。新人に「質の高いコードをスピーディーに書けるようになることを目指そう」「TDDのような道具を上手く活用して、自分の実力をつけていこう」と提案しました。もし、それさえもきついようなら、キーボードのタイピングスピードや、基礎的なコーディング力が不足しているかもしれません。 codewars.com のような学習サイトで地道に鍛えていくことも必要です。 質問をしてくれた新人も、この回答に納得してくれた様子です。自動テストの重要性と、TDDの補助輪としての価値を分けて解説したこと、および、TDDを強要ではなく提案として示した点が好評でした。こうした質疑応答がきっかけとなり、研修をブラッシュアップできるのはとてもありがたいです。 新人エンジニア研修では「『分かる』と『できる』は違う」ことを常に気をつけています。よっぽどの天才でない限り、学んですぐに実践できるようにはなりません。特にコーディングに関しては、これまでの人生で書いてきたコードの量と、書いたコードに対するフィードバックの質が、大きく影響していると考えています。 時には地道な訓練も必要になることを忘れずに、Learn by doing で経験を積みながら、高品質なコードを書けるエンジニアを目指して一緒に成長していこうと思います。 この質問を受けた当時は @t_wada さんの雑誌記事 「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」Software Design 2022年3月号｜技術評論社 がまだ世に出ていませんでした。自動テスト、テストファースト、TDDの関係性をとても分かりやすく整理した素晴らしい記事です。 ↩

こんにちは。BIGLOBE Style編集部の吉田です。 早いもので、明日から4月ですね。当社でも新入社員を迎え、入社式を行います！ さて、連載でお届けしております先輩社員紹介。第2弾は、入社後に Amazon Web Services（AWS）の認定資格を7つ取得した新卒2年目開発エンジニアの紹介です。 【開発エンジニア職】 大谷 優多（おおたに ゆうた） 基盤本部 マーケティングプラットフォーム部 CCシステム開発グループ 入社：2020年4月新卒 専攻：情報系 担当業務：コールセンターの方が利用するシステムの開発に携わっています。 趣味： 最近ハムスターをお迎えしたので、今の趣味はその子のお世話です。 おやつをチラつかせると嬉しそうに近づいてくるのが可愛いですね。 ※撮影時のみマスクを外しています。   現在の仕事について BIGLOBEを選んだ理由 仕事のやりがいと成功体験 仕事をする上で大切にしていること、成長、仲間 ある日のスケジュール 今後の目標   現在の仕事について   —— 現在のお仕事について教えてください。   主に、コールセンターや関連部門の方が手作業で行っている業務をシステム化して、利便性や操作性を改善する開発・改修に取り組んでいます。運用部門の方と共にシステムに必要な要件を定めるところからシステムのリリースまで一貫して携わっています。   —— 学生時代はどんな勉強をしていましたか？   深層学習を活用した画像認識や画像から文章を出力する研究を行っていました。 深層学習は1回の実験時間が長いので、夕方動かして翌朝確認するというようなことをよく行っていました。   —— 企業選びの軸は何でしたか？   常に新しい情報技術を追いかけていたいと思っていたので、IT業界というところで企業を探していました。就職活動の軸としては、「多くの人に使っていただけるサービスや製品を提供しているか」、「モノづくりのさまざまな工程に参画できるか」ということを中心に考えていました。   BIGLOBEを選んだ理由   —— その中で、BIGLOBEに興味をもったきっかけは？   インターネット接続サービスを始めとして非常に多く人々に利用されているサービスを展開していたり、説明会で聞いた際にシステム内製への取り組みにも積極的であるというところで興味を持ちました。   —— 就職先にBIGLOBEを選んだ理由、決め手を教えてください。   軸に合うことはもちろんですが、少数精鋭でありながら会社としてのさまざまな制度も整っていて、自分自身も気を張りすぎず着実に成長できそうと感じたことです。   —— 入社後のBIGLOBEの印象は？   有休も取得しやすく仕事とプライベートのバランスも取りやすいなと感じました。 また、仕事面では少数精鋭なので若手でも幅広い業務をやらせてもらえるのがいいところですね。   仕事のやりがいと成功体験   —— 現在のお仕事でモチベーションややりがいにつながるのはどんなところですか？   仕様書を書くだけ、実装をするだけというのではなく、一貫した開発を行える点にとてもやりがいを感じています。保守性や運用性なども考えて、クラウドを全面的に活用したサーバレスな構成も検討して実際に取り組めるところも面白いですね。   —— これまでに達成感を感じたエピソードを教えてください。   初めて自分が携わったシステムをリリースできた時は嬉しかったです。最初は開発といっても実装工程のイメージしかついていなかったので、常に「これってどういうことですか？」と先輩社員にヘルプを求めていました。それでも少しずつ自分の中での疑問を解消して進めることで無事にリリースできました。 一通りのプロセスを経験して多くを吸収できたことで、ついにエンジニアとしての一歩が踏み出せたんだという気持ちになり、達成感を感じました。   —— 業務の中で、大変だと思うところは？   既存のシステムやその上で行われる業務を理解することが大変だなと感じています。 既存システムの開発の場合には、そもそも今がどうなっているのかということが大まかに理解できないとスタートラインにすら立てないので、その点が苦労しました。理解するのにドキュメントを読むことはもちろんですが、文字だけだと誤認識することもあるので、積極的にコミュニケーションを取って自分の中に落とし込むようにしています。また、自身がドキュメントで理解できなかった部分については追記していくことで更なる定着にも努めています。   仕事をする上で大切にしていること、成長、仲間   —— 仕事をする上で意識していること、大切にしていることは何ですか？   ビッグローブマインド で言えば、「継続的に成長する」「世の中をみて、世の中から学ぶ」あたりは特に意識しています。エンジニアとして仕事するからには、技術ひとつとっても一度身に着けておしまいではどんどん時代の流れに取り残されてしまいます。また、自分の引き出しが少ないとやれることがパターン化して仕事のハリもなくなってしまうのではとも思っています。エンジニアとして前線に立っていたいからこそ、絶えずさまざまな情報を吸収し、要件が合えば新しい技術も積極的に取り入れるように意識しています。   —— BIGLOBEへ入社してどんな成長ができましたか？   業務でさまざまAWSサービスに触らせていただいたり、社外の研修を受けることでクラウドへの理解が圧倒的に深まったなと思っています。 AWSについては知識ゼロだったのですが、先輩社員に教えてもらったり自身でも積極的に触れることで、現在ではAWS認定資格を7つ保持するまでになりました。 設計をする際にも要件に合わせて複数のパターンを検討できるようなった点が自身としても成長したなと感じています。   —— どんな人と一緒に働いているか教えてください。   BIGLOBEの社員はそれぞれトガったところが多いなという印象です。技術に突き抜けた人もいれば、全体をうまくまとめることに長けていたりと日々勉強になりますね。フォロー体制としても、開発の実装作業で詰まったところがあったときもオンラインミーティングでサポートいただけたので安心でした。   —— どんな後輩と一緒に働きたいですか？   現状に満足せずにどんどん自分を高めていける人と働いてみたいですね。 自分も負けてられないぞという気持ちで一緒に成長していけたら最高ですね。   ある日のスケジュール   —— 一日のスケジュールを教えてください。   9:00 在宅勤務開始   9:00 チーム内朝会、メール・チャットチェック 朝会では、その日のタスクを共有します 10:00 資料作成、開発作業（コーディング） ・設計でまとめたものを実際にコードに落とし込みます ・PoC（技術検証）でシステムがちゃんと作れるか確認します 12:00 お昼休憩 ランチタイムです 13:00 打合せ   14:00 資料作成、開発作業、問い合わせ対応   17:00 チーム内夕会 一日の作業報告やちょっとした雑談をします 17:30 資料作成、開発作業、問い合わせ対応   18:30 業務終了   今後の目標   —— 今後のキャリアプランや目標を教えてください。   まずは、AWS認定資格を取りきってクラウドエンジニアとしてのスキルを伸ばしていきたいです。数年後には各種クラウドの特徴を理解した設計ができるエンジニアになることを目指しています。更にその先では、開発もできるし新技術の開拓を行い価値を創造するR&Dエンジニアとなることを目指しています。   —— 就活生、学生に向けてメッセージやアドバイスをお願いします。   自分がどんなことに興味を持ったり、ワクワクしたか一度振り返ってみてください。それか自分がつまらないと思うことの反対を考えてみてください。そうすると、就職において自分は何を大切に考えているのか見えてくると思います。ぜひ皆さんも自分の中で譲れないものを見つけて、納得がいく会社選びができるよう頑張ってください。   当社新卒採用サイトでは、事業内容や職種別の社員インタビューなどさまざまな情報を掲載しています。ご興味のある方はぜひご覧ください！ ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

本番ネットワーク環境を安全に設定するため、BIGLOBE、NTTコミュニケーションズ、TISの3社が合同で取り組んでいる研究のご紹介です。既存環境から自動抽出したモデル上で、設定を事前に検証します。 1. はじめに プロジェクトの背景 プロジェクトのねらい システム構成と動作フロー この記事で紹介する内容 2. 運用対象ネットワークの検証環境構築方法 検証環境のネットワーク構成 vrnetlabによる検証環境の構築 vrnetlabのマルチノード構成 検証環境のまとめと今後の課題 3. NW装置のコンフィグとステータスの自動定期取得 実際のワークフロー 今後の課題 次回：L1-L3トポロジのモデルデータの作成 最後に 1. はじめに 基盤本部ネットワーク技術部の滝口と、同じくネットワーク技術部の川口です。 BIGLOBEは2021年8月から 沖縄オープンラボラトリ （Okinawa Open Laboratory: OOL）の「Model Driven Network DevOps Project」に参加しています。このPJはBIGLOBE、NTTコミュニケーションズ、TIS（アルファベット順）の3社が会社を横断してネットワーク（NW）自動化の研究に取り組んでおり、2022年2月25日にはOOLの成果発表会 ※1 にて活動の概要を報告しました。 今回は全体を3パートに分けて各社持ち回りで紹介するブログリレー形式で、より詳しい内容をお届けしていきます。 前編（本記事） BIGLOBE「検証環境の構築、NW装置のコンフィグ自動定期取得」 中編 NTTコミュニケーションズ「 コンフィグからL1/L2/L3に分けてモデルデータを作成するステップ 」 後編 TIS「 モデルデータを評価するステップ 」 ※1 下記Project紹介ページの 「2021年度活動紹介」 に成果発表資料を掲載: www.okinawaopenlabs.org プロジェクトの背景 ネットワーク運用の現場では、人力での運用は限界を迎えつつあります。設備増強により操作対象ノードが増加し、仮想化・オーバーレイなどの技術の導入によりネットワーク構成が複雑さを増しているためです。そのためAnsible などを活用したネットワーク運用の自動化が一般的になりつつあります。 しかし、Ansible が対象にするのはノード単体に対する操作の自動化です。ノード単体では正しい操作をしているつもりでもシステム全体では不整合になる場合があります。 このような背景から、現場のオペレーションはますます複雑になっています。「操作してみないとわからない」「本番環境で操作して初めて設定ミスに気がついた」といった、ヒヤリとする経験をお持ちの方もいらっしゃるのではないでしょうか。 プロジェクトのねらい 本PJは、障害につながりかねない「本番環境で初めて気づく」リスクを撲滅することを目指しています。 それを実現するために、 仮想検証環境を使った安全な動作検証を可能にすること 既存のNW環境を忠実に模した仮想検証環境を自動的に構築すること をねらっています。これらのねらいを実現するために、具体的には次の機能を実装していきます。 既存環境の構成情報を抽出し、モデルデータを構築 モデルデータを基にした、 システムの構成や状態の可視化、時間変化のトラッキング（構成変化差分の取得） これまで人が見ていたレビューやチェック、設計ポリシーとの適合性検査などの実装 仮想の検証環境を自動構築、検証環境内での機能検証、リハーサルやトレーニング、自動テストの実行 これらの機能により、事前にモデルベースでシステムの整合性やポリシーをチェックし、さらに仮想検証環境で動作検証を自動化することが可能になります。その結果、テスト・検証を効率的に繰り返せるようになり、安全に本番環境でオペレーションできるようになると考えています。 システム構成と動作フロー 上記のねらいを達成するため、OOLでは3社合同で次のシステムを開発・検証しています。 開発中のシステムは、運用対象ネットワークの検証環境を構築後、以下の流れで動作します。 NW装置のコンフィグを自動定期取得するステップ コンフィグからLayer1(物理層)/Layer2(データリンク層)/Layer3(ネットワーク層)に分けてモデルデータを作成するステップ モデルデータを評価するステップ この記事で紹介する内容 本記事ではBIGLOBEが、初回に実施する検証環境の構築と、システム動作の最初のステップで実行するコンフィグ自動取得について、2章に分けて紹介します： 運用対象ネットワークの検証環境構築 検証環境を本番模擬環境としてvrnetlabを使った効率的なVirtual Network Function（VNF）の構築方法 NW装置のコンフィグとステータスの自動定期取得 ansible-runnerとGitHub Actionsを使って装置のコンフィグを定期取得する実装方法 2. 運用対象ネットワークの検証環境構築方法 この検証環境は、本番環境で使われている基本的なNW機能を盛り込みつつ、仮想化技術を活用したマルチノードのスケールアウトを実現し、スモールスタートでの構築を可能にしました。 検証環境のネットワーク構成 このPJでは検証環境として、シンプルながらもLAG、 BGP、 OSPF、 VLAN、 VRRPなど本番環境でも使われる基本機能を含んだ以下のNW構成を設計しました。 この構成は物理環境ではなく、OOLのテストベッド環境上にベンダーVNF等を延べ15台用意して実現しました。 vrnetlabによる検証環境の構築 検証環境を構築するにあたり、中心的な役割を果たしたツールが vrnetlab です。 vrnetlab とはdockerコンテナ上でqemu/kvmのネットワークOSの仮想マシンをデプロイするラボ・評価目的のオープンソースソフトウェア（OSS）になります。 vrnetlabにて起動するVNFのコンテナ内にはlaunch.pyと呼ばれる起動スクリプトが入っており、コンテナが起動する際にこのスクリプトが実行されます。起動スクリプトでVNFの作成～ゼロタッチコンフィグが行われ、自動でVNFが利用できるようになります。 下図がVNFのJuniper vMXとArista vEOSの構成例です。 vMXとvEOSのvrnetlab単一ノードでの構成 VNF間にvr-xconと呼ばれるコンテナを入れることでVNF間のP2Pリンクが作成でき、 お互いに通信できるようになります。このP2Pリンクのおかげで、VNF間でTrunk VLANやLACP構成を（物理機器の時と同じ使用感で）使うことができます。 参考ブログ： www.brianlinkletter.com vrnetlabのマルチノード構成 このPJの検証構成では11台のVNFと4台の仮想マシン（VM）を用いており、ベアメタルサーバ1台ではスペックが不足していたため、複数台並べたマルチノードの構成を採用しました。 vrnetlabはノードを跨いだVNF間の通信も簡単に設定できます。具体的には、docker swarmモードを有効にして、dockerのoverlayネットワーク上にvrnetlabのVNFのコンテナおよびvr-xconコンテナをアタッチすれば実現できます（TrunkVLANやLACPもマルチノード上で機能します）。 マルチノード前提でvrnetlabを使う際は、VNFコンテナ全てにoverlayネットワークをアタッチさせておけば、どのノード上のどのVNFコンテナにおいてもvr-xconで繫げることができるので、物理ノードのスケールアウトも簡単にできます。 vMXとvEOSのvrnetlabマルチノードでの構成 検証環境のまとめと今後の課題 マルチノードのvrnetlabを使って検証環境を効率的に構築することができました。この環境でデモコンフィグの作成、デモ構成のNW動作確認を実施します。さらに、デモ環境のコンフィグおよびステータスをデータソースとして、モデルデータおよび経路情報の解析にも活用しています。 今後の課題は、本番環境の理想(あるべき姿)の構成を検証環境で再現することです。ブログリレーの後編では、モデルデータをもとに静的・動的テストについて解説します。このテストによって発見した問題箇所を検証環境上で修正し、さらに別の問題を発見して修正する、といったサイクルを繰り返すことで、理想の本番環境のNWモデルを構築できると考えています。 今回は、本番構成もデモ用に作った仮想環境だったため、テストしたあとに修正した構成を再現・検証することは簡単にできました。しかし、世間一般のどの企業でも実運用している基盤には数十台〜数百台以上のNW装置があります。この規模になると、今回使用したVMベースのvrnetlabではうまくスケールさせられません。より短時間で大量に起動できるコンテナ型の仮想ルータ(以後CNFと略称します)で経路シミュレーションを実現する必要が出てきます。 具体的には、vrnetlabは以下の2つの問題点があります。 VNFのみ対応のため、大規模構成に不向き 最近のベンダー提供のVNFは最低メモリ容量が16GB以上も消費する傾向があり、一台VNFを起動するだけでも、かなりのサーバリソースを消費します。CNFの動作については、vrnetlabは対応していません。 外部機器や非vrnetlabのVMと通信できない vrnetlabはVNF間の通信はTCPソケットのオーバレイネットワーク上で行われているため、オーバレイを終端するツールが必要になりますが、公式では提供されていないので他の非vrnetlabのVMや外部の物理ノードとの疎通はできません。 この問題点の対応が厳しいため、新たに containerlab というOSSも導入することにしました。containerlabではCNFを前提としたOSSでvrnetlabとの統合もできるため、本番環境の理想(あるべき)の構成を検証環境で再現しやすくなりました（forkされたvrnetlabのため、originのvrnetlabとの互換性はない点にはご注意ください）。 今後はcontainerlabも組み込んだ検証環境でさらに本システムを拡張していこうと計画しています。 3. NW装置のコンフィグとステータスの自動定期取得 クラウドサービスを活用して小さく始められるように、コード管理やCI/CD、コンテナレジストリの機能を備えるGitHubを採用しました。GitHub Actions の ワークフロー で ansible-runner を実行して NW装置のコンフィグやインターフェース、Link Layer Discovery Protocol（LLDP）のステータスを定期的に取得しています。 取得したコンフィグ・ステータスをスナップショットとして記録し、このシステムの後続のステップでトポロジなどのモデル・テスト解析に使います。 本番環境ではNW装置のコンフィグやステータスは日々変更されています。そこで、定期取得したスナップショットをバージョン管理することで、時間経過による構成変更を把握することができるようになります。 実際のワークフロー GitHub Actionsのワークフローでは self-hosted runner を使用しAnsible 実行サーバ を ホストランナーとしています。 ワークフローの処理の流れは以下のようになっています。 NetBoxから対象ルーターの認証情報を取得 ルーターの show run config を取得 サーバーのnetplanの情報取得 各ルーターのステータスを取得 show interfaces show lldp コンフィグ・ステータスを共有ディレクトリにコピー 更新・差分があればGitHubにpush ワークフローの処理の1番目で使用する NetBox というのは OSSの IPAM/DCIM（IPアドレス管理 / データセンターインフラ管理） ツールです。Ansibleとの相性もよく、あらかじめ装置のアクセス情報をNetboxに登録しておくことで、Ansible実行時にinventoryとして装置の認証情報を取得しています。 Netboxのデバイスに登録したAnsibleのインベントリ情報 こうすることで、Netboxに装置のアクセス情報を一元管理したまま、Ansibleのinventory上に装置情報を取得することが可能となります。 ワークフローの処理の2〜4ではワークフロー上で ansible-runnerを実行して、各ルーターの コンフィグの情報・ステータスやサーバーのnetplan情報を取得し、ファイルとして保存しています。これらのコンフィグ・ステータスのデータがスナップショットとなります。 ワークフローの起動設定はcronで定期的に実行されるように設定し、定期的に取得したコンフィグ情報やステータスに変更があれば、自動でGitHubにpushすることで、スナップショットの更新を実現しています。 現状の検証環境の規模ではワークフローの実行時間は90秒程度です。パブリックレポジトリのためGitHub Actionsは無料で制限なく利用できますが、プライベートレポジトリでも2000分/月まで無料で利用できるため、1時間に1回程度の実行であっても十分余裕があります。 今後の課題 この後に続くモデルデータを評価するステップでは、テスト・検証の網羅性が重要になります。網羅性を向上させるために必要なのが、ステータス情報の解析機能です。例えば、LLDPのステータス情報から物理リンクの対向インターフェースの状態を自動で生成するなどの解析を可能にします。しかし現時点のワークフローではこの解析機能は実装できていません。今後はワークフローを拡充して対応する予定です。 作成したAnsibleのPlaybookやGitHub Actionsワークフローは、次のリポジトリーで公開しています。ご参考になれば幸いです。 使用したPlaybookの内容： github.com コンフィグおよびステータスと GitHub Actions ワークフロー： github.com 次回：L1-L3トポロジのモデルデータの作成 「Model Driven Network DevOps Project」のシステムのうち、 運用対象ネットワークの検証環境構築方法 装置のコンフィグとステータスを取得する方法 についてBIGLOBEが解説しました。 中編 では、自動取得したコンフィグのスナップショットからトポロジのモデルデータをどのようにして生成するかをNTTコミュニケーションズ 田島さんから解説していただきます。 次回も楽しみにしてください。 最後に 沖縄オープンラボのModel Driven Network Projectでは一緒に活動してくれる会員を募集しています。 ご興味のある方は以下のURLにてお問い合わせ・ご応募よろしくお願いいたします。 www.okinawaopenlabs.org ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

ドメインモデルを図で理解するのに便利なPlantUML。レイアウト調整のノウハウと合わせてその魅力を紹介します。 はじめに 対象読者 PlantUMLとは メリット デメリット レイアウトを調整するためのテクニック まとめ はじめに 基盤本部（開発部門）の宮下です。 BIGLOBEではドメイン駆動設計（Domain Driven Design：DDD）を実践しています。 DDDではドメインモデルを育てていき、継続的にソフトウェアの価値を高めていくことが重要となります。 ドメインモデルとは、業務的な関心ごと(=ドメイン)の問題を解決するために表現するものです。そんなドメインモデルをみんなで設計するときに、BIGLOBEではPlantUMLというツールを使っています。キーボードだけでサクッと図を描けてしまう優れものです。 この記事では、PlantUMLに詳しくない方はもちろん、PlantUMLでもっと見やすい図を描きたいな！と思っている方向けのノウハウを紹介したいと思います。 対象読者 PlantUMLに詳しくない方 PlantUMLでもっと見やすい図を描きたいと思っている方 PlantUMLとは PlantUMLはUML(Unified Modeling Language)をはじめとした図を作成するのに便利で商用利用可能なフリーツールです。 以下のような複雑な図も作成できます。 コンポーネント図 ▶ソースコード（クリックで展開） @startuml interface "注文画面" as OrderWeb actor "顧客" as Customer package "販売管理" { [受注管理] as OrderReceivingManagement [在庫管理] as StockManagement interface "在庫管理API" as StockManagementAPI database "在庫DB" as StockDB [出荷管理] as ShipmentManagement interface "出荷管理API" as ShippingManagementAPI } Customer .> OrderWeb : 在庫確認, 注文 OrderWeb -- OrderReceivingManagement OrderReceivingManagement ..> StockManagementAPI : 在庫確認 OrderReceivingManagement .left.> ShippingManagementAPI : 出荷指示 StockManagement --> StockDB : 在庫確認, 在庫更新 StockManagement -up- StockManagementAPI ShipmentManagement ..> StockManagementAPI : 在庫更新 ShipmentManagement - ShippingManagementAPI @enduml シーケンス図 ▶ソースコード（クリックで展開） @startuml hide footbox actor "顧客" as Customer participant "受注管理" as OrderManagement queue "注文キュー" as OrderReceptionQueue participant "在庫管理" as StockManagement #Plum participant "出荷管理" as ShipmentManagement Customer -> OrderManagement: 在庫確認 activate OrderManagement OrderManagement -> StockManagement: 在庫確認API activate StockManagement StockManagement -> StockManagement: 在庫確認 StockManagement --> OrderManagement: Response deactivate StockManagement OrderManagement -> Customer: 在庫情報 deactivate OrderManagement Customer -> OrderManagement: 注文 activate OrderManagement OrderManagement -> OrderManagement: 注文受付 activate OrderManagement OrderManagement -> OrderReceptionQueue: 注文キュー登録 deactivate OrderManagement OrderManagement -> Customer: 注文情報 OrderManagement --> OrderReceptionQueue: Polling OrderReceptionQueue --> OrderManagement: 注文キュー OrderManagement -> ShipmentManagement: 出荷指示API activate ShipmentManagement ShipmentManagement -> ShipmentManagement: 出荷受付 activate ShipmentManagement ShipmentManagement -> StockManagement: 在庫更新API activate StockManagement StockManagement -> StockManagement: 在庫更新 StockManagement --> ShipmentManagement: Response deactivate StockManagement deactivate ShipmentManagement ShipmentManagement --> OrderManagement: Response deactivate OrderManagement @enduml クラス図 ▶ソースコード（クリックで展開） @startuml package "在庫" { class "在庫" as Stock { - List<商品ロット> - 商品在庫数 - 在庫ステータス + 商品の在庫数を更新する() + 商品の在庫数を確認する() - 商品在庫ステータスを更新する() } class "入出庫" as IncomingAndOutComing { - 在庫 + 商品を保管する() + 商品を取り出す() } enum "在庫ステータス" as ProductStatus { 在庫あり 在庫わずか 売り切れ 入荷待ち } } package "商品" { class "商品" as Product { - 商品番号 - 商品名 } class "商品ロット" as ProductLot { - List<商品> - ロット } class "ロット" as Lot { - ロット番号 - 製造日付 - 消費期限 } } package "倉庫" { class "倉庫" as Warehouse { - 倉庫番号 - 住所 } class "倉庫棚リスト" as WarehouseShelfList { - 倉庫 - 棚リスト + 空いている棚を探す() - 棚の空き状況を更新する() } class "棚リスト" as ShelfList { - List<空き棚> - List<使用中の棚> } class "空き棚" as EmptyShelf { - 棚 } class "使用中の棚" as UsingShelf { - 棚 - 商品ロット } class "棚" as Shelf { - 棚番号 - 位置 } } IncomingAndOutComing "1" *--> "1" Stock IncomingAndOutComing ..> WarehouseShelfList Stock "1" *--> "1.." ProductLot Stock "1" *--> "1" ProductStatus WarehouseShelfList "1" *--> "1" Warehouse WarehouseShelfList "1" *--> "1" ShelfList ShelfList "1" *--> "0.." EmptyShelf ShelfList "1" *--> "0.." UsingShelf EmptyShelf "1" *--> "1" Shelf UsingShelf "1" *--> "1" Shelf UsingShelf "1" *--> "1" ProductLot ProductLot "1" *--> "1.." Product ProductLot "1" *--> "1" Lot @enduml 状態遷移図 ▶ソースコード（クリックで展開） @startuml state "在庫ステータス" as StockStatus { [*] --> 入荷待ち 入荷待ち -> 在庫あり: 入荷 在庫あり -> 在庫わずか: 在庫が10個以下 在庫わずか --> 売り切れ: 在庫が0個 売り切れ --> 入荷待ち: 入荷日が決定 } @enduml 上記の図以外にも様々な図が作成できます。 PlantUMLの日本語ページ に例があるので、参考にしてください。 次に、個人的に感じるPlantUMLのメリットとデメリットを挙げます。 メリット テキストベースで記述できる これがPlantUMLを利用するモチベーションとなる一番大きなメリットかと思います。バージョン管理システムで変更履歴を管理でき、メンテナンスがしやすいです。ドメインモデルを継続的に育てていくDDDと相性が良いのかなと思います。 プラグインを入れると編集しながらリアルタイムで図をプレビューできる IntelliJ IDEA 、 Visual Studio Code 等、主要なIDEやテキストエディタでプラグインが公開されています。プレビューに即時編集内容が反映されるので、効率的に編集作業ができます。プレビューを見せながら議論をして修正するという使い方もできるので、コミュニケーションを取る際にも有用です。 ※業務利用の場合はPlantUMLのオンラインサーバーを使用しないようにしています。 デメリット レイアウト調整に工夫が必要 PlantUMLでは図のレイアウトを自動で行ってくれますが、思うようにいかないことが多々あります。後述するテクニックを使えばある程度きれいに配置できますが、細かな調整をしたい場合には向かないです。 レイアウトを調整するためのテクニック デメリットとして、レイアウト調整に工夫が必要と挙げましたが、ここでレイアウト調整するためのちょっとしたテクニックを紹介します。 - や . の数で調整 @startuml package Horizontal { class A {} class B {} class C {} class D {} C . D A - B } package Vertical { class G {} class H {} class E {} class F {} E -- F G .. H } package LongDependencyLine { class I {} class J {} class K {} class L {} I --- J I ---- K I ..... L } @enduml - や . が1つの場合 水平方向に依存関係の線が伸びます。 - や . 2つの場合 垂直方向に依存関係の線が伸びます。 それ以上増やした場合 線を長さを変えられます。 要素や依存関係を定義する順番を変える 1.のソースコードを見て違和感を持った方がいるかと思いますが、要素や依存関係を定義した順番で配置が変わることがあります。 ソースコードを自然な順番で定義するよう修正してみましょう。 @startuml package Horizontal { class A {} class B {} class C {} class D {} A . B C - D } package Vertical { class E {} class F {} class G {} class H {} E -- F G .. H } @enduml すると、図はこのようになります。 配置が左から (C - D), (A - B), (G - H), (E - F)となり、違和感がありますよね。 このように配置に納得がいかない場合は、要素や依存関係の定義順を見直すのもありなのかもしれません。 依存関係がある要素を左右入れ替える 以下の例を見てください。 ソースコードはこちらです。 @startuml class Fruit {} class Orange {} class Banana {} class Apple {} Fruit <|-- Orange Fruit <|-- Banana Apple --|> Fruit @enduml 図の配置とソースコードの関係を見ると以下のようになっています。 Banana, Orange 図の配置：Fruitよりも下 ソースコード：Fruitが左、Banana, Orangeが右 Apple 図の配置：Fruitよりも上 ソースコード：Appleが左、 Fruitが右 要素を左右入れ替えるだけで、配置が変わったことが分かります。 また、1.と関連しますが、 - , . の数にも関係していて以下のようになります。 - , . の数が1つの場合 左側に定義した要素：左側に配置 右側に定義した要素：右側に配置 - , . の数が2つの場合 左側に定義した要素：上側に配置 右側に定義した要素：下側に配置 依存関係の方向を明示的に指定する 依存関係を結ぶ線の間に up , down , left , right のような指定が可能です。 ※ u , d , l , r のように省略も可能です。 @startuml class Center {} class Up {} class Left {} class Right {} class Down {} Center -up- Up ' 垂直方向の場合、線を伸ばすことも可能 Center -down--- Down Center -left- Left Center -right- Right @enduml [hidden] の使用 依存関係はないけれど、配置上どうにかしたい場合は [hidden] が使えます。 まずは以下の例を見てください。 昆虫類(Insects)、 カブトムシ(Beatle) がAnimalと同階層に並んでいて気持ち悪いですね... 適切な配置にしたいため、 [hidden] を使うように修正します。 @startuml class Animal {} ' 哺乳類 class Mammalian {} note left of Mammalian: 哺乳類 ' 昆虫類 class Insects {} class Dog {} class Cat {} class Monkey {} class Beatle {} Animal <|-- Mammalian Mammalian <|-- Dog Mammalian <|-- Cat Mammalian <|-- Monkey Animal <|-[hidden]- Insects Insects <|-[hidden]- Beatle @enduml いかがでしょうか？今度は昆虫類(Insects)、 カブトムシ(Beatle)が適切な階層に配置されました。 階層構造になっているようなものを図示したいときに有効なテクニックです。 ...昆虫類も動物の一種だし、カブトムシは昆虫類でしょうが！依存関係を定義していないなんて！というツッコミはやめてください(笑) さて、5つほどレイアウトのテクニックを紹介しましたが、ここで元も子もないことを言います。 レイアウト調整はほどほどにしてください(笑) なぜならば、きれいな図を作ることが目的ではなく、図を使って議論したり、頭を整理したりすることが本来の目的となるはずだからです。 また、PlantUMLでレイアウトを細かく制御するのは難しいですし、あまりおすすめしません。ある程度のところで割り切るのが良いかと思います。 まとめ PlantUMLの概要とちょっとしたテクニックを紹介しました。繰り返しになりますが、DDDを実践するには非常に有用なツールですし、ちょっとした図を作りたい場合でも便利なツールです。 ぜひPlantUMLを活用してみてください。 BIGLOBEでは、DDDを活用したサービス・アーキテクチャの設計・開発に取り組んでいます。DDDを実践してドメインモデルを継続的に成長させるために、ツールにもこだわりながら色々な工夫をしています。 興味のある方はぜひカジュアル面談にいらしてください。 hrmos.co ※ UML、Unified Modeling Languageは、Object Management Group, Inc.の米国及びその他の国における登録商標または商標です。 ※ IntelliJ、IntelliJ IDEAは、JetBrains s.r.o.の商標または登録商標です。 ※ Visual Studioは、Microsoft Corporation の、米国およびその他の国における商標または登録商標です。

BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の間で出社した日は11日のみという、ほぼフルリモート！ 「リモートで仕事していて、どう…？」と色んな方からお声がけいただきますが、正直あまり困っていません。 分からない点は時間を取ってGoogle Meetで教えていただけますし、 IntelliJ IDEA のCode with meを使ったペアプロ・モブプロなども多く実践しています。 週に1度、上司との 1on1 で不安なことや困っていることはざっくばらんに話せていますし、 オンラインランチ会で他チームの方とお話したりすることもあります。 今年2022年の1月には今のチームで「Scala/Akkaのモブプロを酒の肴にリモート飲み会」という居酒屋では出来ないようなこともやりました。 それもこれも、リモートでも困らないよう開発環境をスピーディーに改善していただいたり、チームメンバーのサポートがあってこそだと思っています。 色んな会社があると思いますが、BIGLOBEは開発環境の改善という点では色々対応頂けているように思います！ GitHubを中心に仕事がまわる開発現場 今、私は契約管理に関するチーム（6名体制）でスクラム開発をしています。 前職で経験してきたウォーターフォール型の開発とは違い、 細かい仕様変更や、利用しているライブラリーや言語のバージョンアップ・アップデートにも素早く対応しリリースするスピード感にとても衝撃を受けています。 契約管理の開発チームで使っているツールは以下のような感じです。 ソース管理：GitHub インフラ：Amazon Web Service（AWS） 開発言語：Java、JavaScript、Groovy ビルドツール：Gradle 割と見覚えのある言語/ツールではないでしょうか。 GitHub上ではソースコードだけでなく、業務上の課題もIssueで管理しています。 チャットではどうしても流れて追えなくなったりすることもあるので、問題や議論に上がった内容で新しいIssueを作成し、議事録などはIssueにコメントしていくことで作業漏れを防いでいます。 スプレッドシートでの管理と違い、PR（Pull Request）や他Issueとの紐づけが簡単なのも良い点ですね。 ソース管理は、 A Successful Git branching model で紹介されているGit-flowというブランチ管理/マージ法を実践しています。 ブランチ管理が複雑という声もありますが、 （私自身もGitに触れてこなかったため、最初見た時は複雑！と思いました） 定期的なリリースかつリリースタイミングを自由に変更できる点で今のチームにあっていると感じています。 以下はGitをあまり触ってこなかった私が、今のチームで色々教えてもらいつつ、勉強しつつで 今やGitコマンドであまり困らなくなった事を共有させてください。 Git logが綺麗だとバグが起こりにくい？ ここからは、feature ブランチで新機能を追加していくときのlogの話です（develop にマージされた後の操作まではやりません）。 契約管理チームはGit logにも綺麗さを求めます。 契約管理チームのGit logはdevelopブランチ（黒線）に対してfeatureブランチ（青線・緑線）が綺麗に並んでいます。 Git logを綺麗にするなんて最初は趣味の問題だと思っていましたが、 開発を進めるにあたって利点が分かってきました。 1. バグが発生しにくい 「どんな開発現場でもこのGit logを実現すればバグが発生しない！」とは言っていません。 …ですが、マージした前後関係などが洗い出しやすいです。 マージする際も不毛なコンフリクトが発生しないため、修正作業による手作業が減り、結果としてバグが起こりにくいと言えるのではないでしょうか。 2. ブランチ迷子にならない 作業中のfeatureブランチは最新のdevelop付近に集まるため、今どのブランチで何が起こっているのかを把握するのが容易です。 以下の例はすこし大袈裟ですが、Git logを俯瞰したとき、スクロールしてそれぞれのfeatureブランチで何が起こっているかを頭で整理する必要もありません。 契約管理チームのGit logをどうやって実現しているかを、図解しながら説明していきます。 developブランチを綺麗に保つGit操作（マージ編） 今のGit logは以下のとおりで、別のチームメンバーが新機能A（feature/A）を担当しています。 ここで、読者の皆さんが新機能B（feature/B）を実装することになりました。 早速、developから新機能B（feature/B）のブランチを作成して、ソースをcommitします。 しかし、チームメンバーにレビュー依頼をしている間に新機能Aのレビューが終わり、developにマージされてしまいました。 feature/Bは、この後どのようにdevelopブランチへマージすると良さそうでしょうか。 皆さんならどのようにマージしますか？ そのまま気にせずdevelopにマージする 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 最新のdevelopにrebaseしてからマージする では実例を見ていきましょう。 1. そのまま気にせずdevelopにマージする。 結論から言ってしまうと、1. の対応はあまりオススメできません。 なぜなら、最新のdevelopの内容がわからないままfeature/Bをマージすることになるからです。 もしfeature/Aで同じファイルを編集していた場合、コンフリクトが発生したり、 「最新のdevelopとfeature/Bが合わさることでビルドが通らない」なんてことも起こる可能性は大いにあります。 実際の操作だけ見ておきましょう。 GitHub上では以下のようにPRのMerge pull requestを押下してマージができます。 Merge pull requestを押下して実際にマージするとブランチは以下のような形になります。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 実際の操作としては以下のコマンドを叩くことで最新のdevelopの内容をfeature/Bブランチに取り込めます。 feature/Bブランチにいます。 > git branch develop * feature/B developブランチの最新コミットをローカルに取得します。 > git fetch 最新のdevelopの内容をfeature/Bブランチに取り込み、 > git merge origin/develop origin/feature/Bブランチに反映します。 > git push この操作では、1では対応していなかった「最新の内容を取り込む」という操作をするため、 コンフリクトやビルドの可能性を事前にfeature/Bブランチで確認できるようになります。 上記コマンドを実施後PRをマージするとGit logは以下のようになります。 git merge origin/develop のコマンドでfeature/Bブランチにマージコミット（Ⓜ）が作成されます。 ブランチ作成時の分岐も変わらないため、featureブランチを長く使うほどGit logは平行線が長く、developを取り込むほどマージコミットが増え続けます。 2.はチーム開発としての最低限はしておきたい操作ですが、 Git logを綺麗にしたいチームにはオススメできない対応です。 3. 最新のdevelopにrebaseしてからマージする 今のチームではこの手法が推奨されています。 チームに参画したての頃は『リベースしてからマージしてね』という言葉をよく聞きました。 「リベースって、あの、歴史改変の禁断のコマンドじゃないですか！？えぇ、そんなことやって許されるのですか！？」 ま、先輩が言うならやるんでしょう。やるしかありません！ ちょうどGitHubのPR上にRebase and mergeってあるので...、 「コレですね！？」 『それじゃない。ローカルで叩くリベース』 今のチームで飛び交う『リベース』は GitHubのRebase and mergeではなく、-iオプションや--ontoオプションを付けない、git rebaseコマンドを意味します。 👈( 'ω' )コレですね！？（違う） 茶番はさておき、コマンド操作から見て行きましょう。 feature/Bブランチにいます。 > git branch develop * feature/B developブランチの最新コミットをローカルに取得します。 > git fetch feature/B作成時の分岐点をdevelopに移動（再定義）します。 > git rebase develop origin/feature/Bブランチに反映します。 > git push -f origin feature/B git rebase develop では最新のdevelopからfeature/Bブランチを分岐させる形に変更できます。 rebaseはコミットをもう一度作り直す操作になります。言わば歴史改変のコマンドです。 そのため、git pushは、より強力にした呪文（-f : force push）を唱えないとリモートに反映できません。 これらのコマンドを実行後、PRをマージしたものが以下のGit logになります。 1.では対応できていなかった「最新の内容を取り込む」という点でもクリアでき、 2.でネックとなっていた「ブランチの平行線が長くなる」「マージコミットが出来てしまう」という問題も、rebaseで解決できます。 もちろん、意味単位でコミットしておくことで、単なる作業ログにしないように気をつけています。 ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 慣れてしまえばなんて事はないですが、最初はドキドキしながら作業してました。何せ歴史改h… 確かにCONFLICT の文字が並ぶと一瞬思考停止してしまいますが、 「コミットを作り直そうとしてコンフリクトが発生したんだな」という理解と1回の深呼吸があれば大丈夫です。 競合しているファイルを修正して再度コミットを作り直した後、 git rebase –-continue を叩いてSuccessfully rebased and updatedというゴールが見えるまでrebaseの旅を続けましょう。 git rebase –-continue を叩いては競合を解消してコミットして、を繰り返すのは骨が折れるかもしれませんが git log を見ることで自分がどこまで進んだのかが解りますし、 単純な競合であれば1クリックするだけで解消してくれる最近のIDEも助けになってくれたりします。 また今回は紹介できませんでしたが、 -iオプションを付けてコミットを整理したり、--ontoオプションでブランチごと付け替える手法もあります。 -iオプションで複数コミットを1つ纏めた後、「やっぱり纏める前に戻したい」という歴史改変はできないので、悩むようであればrebase前にバックアップブランチの取得をお忘れなく！！ 最後に プロジェクトによってブランチやGit運用ルールがあると思うので、今回紹介したブランチ運用が全ての正解とは言えないのですが、同様のブランチ管理をしている方や、このGit log見やすくて良いな！と思ってくださった方、今は個人開発だけど今後Gitを使ったチーム開発に携わる方に、この記事が参考になれば幸いです。 なおBIGLOBEには複数の開発チームがあり、開発言語やツールも様々です。 今回紹介した開発現場は、あくまで一例ということだけご認識ください。 BIGLOBEでは新しい技術を積極的に取り入れた開発に挑戦しています。興味のある方は、カジュアル面談でお話してみませんか？ hrmos.co ※ Google Meetは、Google LLCの商標です。 ※ IntelliJ、IntelliJ IDEA は、JetBrains s.r.o.の商標または登録商標です。 ※ GitHub は、GitHub Inc.の商標または登録商標です。 ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com, Inc.またはその関連会社の商標です。 ※ Java、JavaScriptは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。 ※ Gradleは、Gradle Inc.の商標または登録商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部です。 今回の記事でご紹介するのは、2018年3月に中途で入社し、現在は基盤本部 マーケティングプラットフォーム部 CCシステム開発グループ 主任を勤める松崎 剛史（まつざき まさし）。 社内のレガシーシステムをクラウド活用で先進的なシステムへ刷新するプロジェクトなどに携わり、20年度下期には「統合UI基盤リニューアル」で社内MVP賞(*)を受賞するなど、BIGLOBEの開発体制の変革に大きく貢献しています。 そんな松崎が普段どのような仕事のやりがいや課題を感じていて、今後どんなことを目指しているのかなどをインタビューにて聞きました。 *社内MVP賞とは、特別な功績を出した「個人」の仕事ぶりと培われた功績に対して敬意を表すための表彰制度で、半期に一度行われます。 ※撮影時のみマスクを外しています。 100％受託開発SIerから、自社システムの開発へ 困難を乗り越えた先に、成長の手応えを感じる SalesforceやAWSを一から学んで身につけた経験を活かす 技術もマネジメントもわかるプレイングマネージャーへ 100％受託開発SIerから、自社システムの開発へ 松崎 剛史（まつざき まさし） 基盤本部 マーケティングプラットフォーム部 CCシステム開発グループ 2018年3月中途入社／社会人7年目。 前職の大手IT企業SIerから中途入社し、現在は Amazon Web Services（AWS） やSalesforce等のクラウドサービスを活用したコンタクトセンターシステムのシステム開発業務に従事している。   —— まずは松崎さんがBIGLOBEに入社したきっかけから教えてください。   前職は、新卒で入社したSIerでシステム開発に3年程携わっていました。100％受託開発でいろいろな案件を経験できましたが、自分でコーディングすることが全くなかったので「エンジニアとして、それはどうなんだろう？」と疑問に思い転職活動を始めたのがきっかけです。インフラネットワークを扱う企業で、アプリケーションエンジニア的な開発をしたかったことから転職サイトで対象企業を探し、その中でもここならフロントとバック両面の技術を身につけられるのではないかと思ったのがBIGLOBEでした。   —— BIGLOBEに入社してみて、実際はいかがでしたか？   まず組織のことで言うと、いい意味でギャップに感じたのがいろいろな部門の人と話す機会が予想以上に多い会社だったこと。このBIGLOBE Styleに登場している他の社員インタビュー記事でも触れられていますが、部門間の垣根が低いので風通しがよく、新しいサービスを立ち上げる時などもたくさんの人の意見を出しつつ一丸となって進めていく雰囲気があります。そこが会社としての「らしさ」であり、良いところではないでしょうか。   仕事については、2016年ごろから既存のレガシーシステムをSalesforceに機能集約したり、オンプレミスサーバをAWS化したりなど、先進的なシステムへと刷新するプロジェクトが動いています。私もこのプロジェクトに3年程携わっています。   部として掲げているミッションは、コンタクトセンターの方々が安心安全で効率的かつ快適に使えるシステムを開発すること。自社システムなので、とても幅広い経験を積めていると感じています。   困難を乗り越えた先に、成長の手応えを感じる —— 具体的にはどんな仕事内容なのかを教えてください。   例えば、コンタクトセンターやカスタマーサポートの運用部門の人は、今まで手作業でExcel管理をするなど非効率な業務が多くありました。しかし、ずっとその運用を行っていたので、ある意味安定的に稼働はできていましたが、IEのサポート切れや社内的なDX推進の流れもあり、新たなシステムへの刷新に踏み切ることになったのです。   私が担当しているのは、その業務を移行するにあたって利便性を向上させたり、手作業でやっているところを自動化したりと効率的に進めていくための開発フェーズです。   割と素案が粗いところからプロジェクトが始まったので「こうすれば改善がうまくいくのでは？」といった企画のところから話して、「この機能だったら作れる」「いや、これはどう作ったらいいのか」などを検討していきます。自ら提案などもできるため、新しいものを作りたい人にはとても楽しいと感じられる環境があると思います。   逆に言うと、何をすればいいかが決まっていない状況だったので成果が出なければ仕事をした意味がなくなってしまうのが難しいところです。上司からこのシステムを作ってくれと強く言われることはないので、より良くしていくために自分たちで何を作ったらいいかを考え、発信していく必要があります。   —— 主体性が求められる環境ですね。大変なところ、逆にそこを乗り越えたやりがいなどもあったかと思いますがいかがでしたか？   大変だったことは、今まで蓄えたノウハウを共有した上でクラウドへ移行していくことですね。既存のコンタクトセンターシステムが何故その仕様になったのかがわからず、設計書もなく、把握している人もいない状態だったので、ずっとシステム保守を担当してきた人に確認しながら、困難を乗り越えていきました。   その結果、うまく移行できて実際にシステムを使うオペレーターや運用部門の方々から、「業務の改善ができました」と言っていただけたのが一番嬉しく、やりがいを感じたシーンでもあります。   —— 20年度下期に「統合UI基盤リニューアル」でMVP賞を受賞したり、KDDIの業務品質向上賞「努力賞」受賞にも貢献されていますね。   努力賞は戦略投資プロジェクトで、センターコストの大幅削減（年間5.7億）を達成したことからいただきました。業務設計部門、運用部門、開発部門などのメンバーで取り組んだプロジェクトなので、チームでいただけた賞です。また、統合UI基盤リニューアルのプロジェクトはまさにSalesforceへ移行し機能実装したプロジェクトで、品質を保ちながら納期に間に合わせた点が評価されたのかもしれませんが、期限がある中でどこまでやるかの調整が一番大変でしたね。開発目線になりますが、そういった難易度の高いプロジェクトを通じて自身も成長できたと感じています。   SalesforceやAWSを一から学んで身につけた経験を活かす —— 基盤本部ではどんな人材が活躍できる部署だと思いますか？   今回のプロジェクトに関してはSalesforceの利用経験があるとベストですが、システム開発の経験があってユーザー目線で仕事に取り組める方なら大丈夫だと思います。それより、営業や他の開発部署などいろいろなところから意見を集めたり調整することが多いので、コミュニケーション力があるといいですね。システム開発では外部のパートナー企業さまと連携することも多いので、BIGLOBE側がプロジェクトリーダーとなり取りまとめを行います。私が所属するグループでは月単位で10人くらいは委託先パートナーを抱えて開発しているので、バックボーンが違う人たちと意見を出し合って良い結果になるように進めていける人は活躍できると思います。   —— 松崎さんは普段の業務でどんなことを意識されていますか？   BIGLOBEの行動指針であるビッグローブマインドの中から選ぶと「継続的に成長する」を一番意識しています。SalesforceやAWSを使って開発すると、案件ごとに今まで使ったことのない機能があるので、その場その場で学んでいかないとうまく作れません。私自身がもともとSalesforceやAWSの経験がない状態でBIGLOBEに入社し、一から身につけていったので、案件ごとに必要なことをひたすら学んできました。だからこそ、普段の業務でも「継続的に成長する」を意識できるシーンが必然的に多くなり、エンジニアとしても大事なことだと思っているマインドです。 style.biglobe.co.jp   技術もマネジメントもわかるプレイングマネージャーへ —— これから手がけたいプロジェクトや部署のミッションなどがあれば教えてください。   開発チームの今後の展望としては、もともとあった機能の移行はある程度終わってきたので、今までのシステムにはなかったAIや自動化機能を取り入れたり、属人化を極力減らしたりできるような運用にしていくことです。その結果として、未来のコンタクトセンターのシステムを作り上げていくことが今後のミッションになります。   —— 松崎さんご自身は今後どのようなビジョンをお持ちですか？   私自身は今使っているシステムに縛られずいろいろな技術範囲の知識を身につけ、幅広い開発案件を担えるエンジニアになっていきたいですね。その意味では、プレイングマネージャーがベストなポジションかなと思っています。自分で開発を行いつつ、プロジェクトのマネジメントもしていくようなキャリアを歩みたいですね。   —— 本日はありがとうございました！ www.biglobe.co.jp ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ Salesforceは、Salesforce.com, Inc.の米国およびその他の国における登録商標または商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部です。 BIGLOBEの自社サービスである個人・法人向け会員ページは日々改善を重ね、より良いサービス運用を心がけています。今回はそんなサービスを支える基盤本部  マーケティングプラットフォーム部 の水守、松村に、プロジェクトを動かすリーダー像についてお聞きしました。 レガシーシステムから脱却し、Amazon Web Services（AWS）クラウド環境への移行など最先端技術領域へのチャレンジだけではなく、コミュニケーション力を駆使し、関係各所やチームをまとめる活躍ができるポジションをご紹介します。 個人で成果を出すより、チームのことを考えて動けるリーダーとして 自社サービスだからこそ、誰の課題をどう解決するかが大事 次期リーダーが育つ環境づくり 自分の得意分野を発揮して、システム部門を盛り上げて欲しい ※撮影時のみマスクを外しています。   個人で成果を出すより、チームのことを考えて動けるリーダーとして   —— 今回は法人会員向けページ開発に関わるプロジェクトリーダーのポジションを紹介したいと思います。まずは、どんな方に向いてる仕事なのかを教えてください。   水守 ：この部署は、BIGLOBE会員ページの開発・運用において、社内の関係各所とコミュニケーションをとりながら課題を解決していくことが求められるポジションです。そのため、必要条件や仕組みを理解した上で、こんなことができるよと提案できる人が向いていますね。 水守 良幸 (みずもり よしゆき) 基盤本部 マーケティングプラットフォーム部　部長   松村 ：新しく入る方には、コミュニケーションが苦手で内にこもってプログラムをガリガリ書きたいというより、社内の人を巻き込みリーダーシップを発揮していただきたいですね。 コミュニケーションを取る場面ですが、今回の募集は主に法人向けなのでまずはお客さま会員企業の窓口となっている社内の営業担当とのやりとりがあります。また、サービス企画部門、カスタマーサポート部門、社内のシステム開発チームや社外のパートナー企業さまとのやりとりも。いろいろな人の多様な課題に日々取り組むので、個人で成果を出すより、チームのことを考えて動けるリーダーを求めたいですね。 松村 憲和 (まつむら のりかず) 基盤本部 マーケティングプラットフォーム部　グループリーダー 水守 ：会員サービスの仕様変更や契約変更などがしっかりお客さまに伝わる仕組みづくりや、技術的な品質や作業効率などの課題をクリアしていくことも重要です。そのため、優先順位を付けながら自分の頭で考えて行動できる人でないと難しいかもしれませんね。逆に、自律的な人であれば主張や提案が通りやすい環境なので、そこにやりがいを感じられると思います。   松村 ：「チームビッグローブ」や「みんなに感謝し伝える」など、当社には ビッグローブマインド という行動指針があるので、横の繋がりを作ったり、信頼のおけるコミュニケーションをとりやすい会社だと思います。心理的安全性の高い組織としての土台ができています。   水守 ：風通しは良いよね。ただ、この部門のウィークポイントは、もともと情報システム部門が母体なので、社内から要求されてから作るというスタイルがDNAに刻み込まれているところ。私や松村は、事業部門にいたので、なんで言われた通りにやらないといけないのかと逆に思ってしまうタイプですが（笑）。   松村 ：新しく入った人も組織の固定概念に染まっていないからこそ、気になったことはどんどん言って欲しいですね。   自社サービスだからこそ、誰の課題をどう解決するかが大事 —— このポジションに加わると、どんな成長ややりがいを味わえると思いますか？   水守 ：物事の優先順位や課題解決手法を見極めるスキルは格段に上がりますね。このポジションは日々いろいろな課題に取り組みますが、相手となる各担当者は自分の課題を一番早く解決して欲しいと思っています。   松村 ：社内の営業担当は、BIGLOBEモバイルやIoTのサービスなど多岐にわたる自社ソリューションをお客さま企業に提案していますからね。それぞれ事情が違います。   水守 ：だから、プロジェクトリーダーは、その中でも本当に優先度が高いものは何かを見極めないといけません。Webの技術を使って課題をクリアする方法は1つではなく、たくさんの手法があるので、どれをどのように使って解決していくかというスキルや経験を磨いていく必要があるのです。   松村 ：余裕のないスケジュールで無理のある施策が実行されたり、大量のトラフィックが流れると後ろの基盤が耐えられなくなるリスクがあるなど、事前にトラブルの根を摘まないといけません。そういった意味でも、プロジェクトリーダーは技術的視点で課題をクリアしたりリスクヘッジを行う重要なポジションであり、課題を取りまとめてスケジュール通りやりきったときの達成感が味わえる仕事です。   水守 ：お客さま相手の自社事業なので、実際に使いやすくなったり、満足度が上がると、良いフィードバックも得られるので、そういった点は自身のやりがいにも繋がるよね。   松村 ：そうですね。あと、サイト企画から設計、開発まで、全プロセスを担当することもできるので、Webサービス全般の知識も身につくと思います。   次期リーダーが育つ環境づくり —— お二人が考えるBIGLOBEの会社としての魅力とはどんなところでしょうか？   水守 ：誰かのいいなりでやる仕事はつまらないよね。BIGLOBEの良いところは、自分の考えをサービスや仕事、働き方に反映させやすいところかな。もちろん部門によっては違うかもしれませんが、全体で見ると考え方が柔軟な組織だと思います。   松村 ：毎回上司にお伺いを立てたりせず、自主的に提案ができる環境がありますよね。そこに新人だろうとベテランだろうと関係ありません。先ほど横のつながりの話をしましたが、縦の関係もだいぶ近くて、新しいことを提案したら皆聞いてくれる姿勢があります。もちろん、それが進むかどうかは別ですが、聞こうとしてくれる。私も聞くのが好きなタイプなので、どんどんコミュニケーションをとっていこうと思っています。   水守 ：私は今、2つのグループを見ていて、その1つが松村さんがリーダーをしているこの部署です。普段から私たち自身もコミュニケーションをとれているので、こういった場で改めて話すのは何だか不思議ですが（笑）、松村さんはプレーヤーとしても優秀なので、何でも自分で対応してしまうことが今までは多かったんです。そうすると部下がなかなか成長しないし、困ったときは松村さんに頼ればいいやとなりがちでした。でも、最近は上手く効率よく回るようになっていて、非常にいい感じですよね。   松村 ：次期リーダーを成長させていかなければと思って、できる限り任せられそうな内容や、自分で考えさせられる内容をまずはやらせてみることを大事にしています。教科書を読むより、実際に経験を積むことが一番成長できるので、やらせてみた上で直接答えは与えず自分で考えて行動させるよう心がけています。そうしたら、上手く回るようになりました。   —— そんなお二人が考える理想のチーム像はありますか？   松村 ：ある程度本音ベースで語れること。隠し事なくやれることは大事かなと思っていて、それがすべてではありませんが、そんなチームを目指しています。不満に思ったらチーム内で相談して、納得のいかない点をとことん会話をするような関係性ですね。   水守 ：システム部門内や他部署と意思疎通ができているといいよね。それができるからこそ効率的に動けるチームになっていくイメージがあります。会社としても、この組織規模で大きな自社サービスを動かしているので、いかに少ない力で良いアウトプットを出せるかがポイントとなります。そういったことができるチームを作りたいですね。   自分の得意分野を発揮して、システム部門を盛り上げて欲しい —— 最後に、この記事を読んでいる方にメッセージがあればお願いします。   水守 ：私たちはシステム部門なので、仕組みをどんどん新しくして、会社の強みや、よりよいサービス作りを支えていきたい。この想いを実現する過程を一緒に担っていける人と働きたいですね。   松村 ：今回のポジションはプログラミング言語のプロフェッショナルを求めているわけではありません。自分の得意なところで力を発揮しながら、不得意なところはできる相手にお願いするなど、チームとしての活動を期待しています。   —— 本日はありがとうございました！   hrmos.co   ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは。石下です。BIGLOBEでインフラエンジニアのグループリーダーを務めています。 私はNEC（BIGLOBEは元々NECの一部門でした）からBIGLOBEに移籍後、サーバ構築/Apache/Mail/DNSを経て、DB/APサーバ/Storageとオンプレのインフラ中心にやってきました。 現在は、Amazon Web Services（AWS）ファーストを推進すべく、自身の、そしてチームのクラウド化を推進しています。 石下 隆一（いしげ りゅういち） 基盤本部 クラウド技術部 クラウドプラットフォームグループ グループリーダー ※撮影時のみマスクを外しています。 クラウド技術部について クラウド化の一例 オンプレミスの制約 クラウドのメリット 目指すところ 働く環境 まとめ   クラウド技術部について   今回は、私が所属する基盤本部 クラウド技術部とその仕事内容についてご紹介します。この部のミッションはAWSファーストによる持たざる経営の実現、そしてクラウドを活用して開発スピードを向上させ、事業課題解決に取り組むこと。そして、私がグループリーダーを担うグループのミッションは、オンプレ・AWSに関わらず、「速い、安い、旨い」をBIGLOBE内部に実感させることです。 そんななかで、オンプレのシステム設計、サーバ構築、設定変更、サーバ・ストレージの維持・管理に加えて、AWS関連の予算・移行管理、オンプレ・AWSのノウハウ蓄積と展開を行っています。 BIGLOBEではインフラ起点でクラウド活用を広めてきました。そのため、サービス開発やシステム開発といった視点がまだ弱いかなという感じですが、中にはサーバレスでサービス・システム開発を行っているチームもあります。このようなチームからもノウハウを蓄積し、展開を図っています。 そして、特に困っているのがクラウドの利用費管理です。日々リリースされる新サービスや新機能、我々では管理できないさまざまな割引プラン。これらをどう活用すれば最適な利用費になり、かつ将来の予測精度をどこまで上げられるか。システムアーキテクチャーの変更を伴う場合、どうすれば安価で安全なのかなどなど悩みどころはいっぱいです。 当グループでは、このような課題を一緒に解決に向けてチャレンジしてくれる仲間を募集しています。クラウドがどういうものかを理解した上で、従来のさまざまな制約にどう合わせるか、どう変えるべきかを自ら考え、チームとして実行していける方、他チームを導いてあげられる方と一緒に働くことができればと思っています。   クラウド化の一例   クラウド化を推進するなか、ストレージ管理者として最大の驚きだったのが、オンプレNASのバックアップをクラウド化したことで、保守切れ対応、相見積、発注、検収、構築、障害対応と言った、ビジネスに直結しない仕事から解放されたこと。さらに、需要増だけでなく、需要減にも対応できるようになったことです。 実は、このおかげで某ベンダーから「国内最大のクラウド〇〇利用者はBIGLOBEさんです」と言われたのもちょこっと嬉しかったです。 クラウドなので、やってみてダメだったら消して、何度でも最初からやり直せる、誰かにお願いせず自分でできるというのが大きなポイントです。 この経験を活かして、オンプレDBのバックアップもクラウド化しています。 オンプレ時代にはコスト重視によるサービス方針の転換で、膨大な在庫を抱え、処理に困ったことがありました。クラウドだったら、消して使わないようにしてしまえば何も困りませんが、オンプレではそうはいきません。また、消してしまってやり直せないという状況も経験しました。これもリソースの制限によって、バックアップが取れないとか、既存環境に手をいれなければいけないというオンプレの制約にも一因がありました。クラウドなら、同じものを作ってから試してみる、バックアップしてから、別の環境で試してみるということが簡単に、安価にできます。 ただ、どちらも組織間、メンバー間の意識や認識のズレも一因だと考えています。このようなズレがないことを確認することで、一歩ずつ改善を図っています。これはクラウドでも同じで、こういうことをやりたいという想いが、一緒にやっている人に正しく伝わっているか確認することが必要だと考えています。   オンプレミスの制約   BIGLOBEでは数千台のサーバ、PBクラスのストレージのほか、各種ネットワーク機器、外部と接続するバックボーンネットワークの機器などがデータセンタに存在しています。 このようなオンプレを支えるにあたって、どうしても必要になることは大きく以下の5点です。誰しも経験し、誰もがこれって会社の利益にどう繋がっているのだろうと疑問に思っている点かもしれません。 ・新装置の導入(選定、検証、相見積、稟議、発注) ・維持業務(保守契約、更新、金額交渉、保守切れ対応) ・キャパシティ管理(性能、容量、使用率など) ・在庫管理(所要確認、保守部材確保、不良在庫削減) ・故障対応 オンプレでは一度モノを買うと、償却期間は5年間。その間、無事に稼働させつつ、需要増減に対応、3～5年でHWやSWの保守切れがあるので入替の準備、そして実際の入替作業が発生し続けます。 どれ一つとっても、1日で終わるレベルの業務ではなく、1人でこなせるレベルでもありません。また、既存サービスの維持でしかなく、ビジネスへの貢献をなかなか実感できません。その代わり、個人・チームで沢山のノウハウを蓄積できて、専門性はどんどん高まります。   クラウドのメリット   オンプレで蓄えたノウハウや専門性はクラウドでもかなり活かせる部分があります。 例えば、どんな評価をすれば安全に使えるのか、こんな機能を組み合わせたらもっと楽に運用できるかも、などです。 今までは自分たちで作らないといけなかったものが、時間単位の利用費で簡単に使えます。 オンプレからクラウドに移行してみると上記の業務がどうなるかと言いますと、 ・新装置の導入 　検証すれば新機能を即利用可能 ・維持 　保守はクラウドベンダーが実施するので検証のみ実施 ・キャパシティ管理 　使うなら増やせば良い、使わないなら減らせばいい、オンプレでは減らせなかった ・在庫管理 　そもそも在庫を抱える必要なし ・故障対応 　クラウドベンダーが実施するので、完全に開放 このように今まで、1つの装置の導入だけで6人/月位かかっていたところ、1人で、しかも2,3日でできるようになります。そして、維持にかけていた膨大な工数を、システムの変更による品質向上やコスト削減、もしくは新しいサービスの創出に振り向けることが可能になります。 ちょっとしたアイデアやクラウドベンダーが提供しているサービスを活用して、自身の業務を楽にすることがクラウドエンジニア化への最初の一歩になると考えています。 現在、AWSとはエンタープライズサポート契約を締結しており、AWSの優秀なソリューションアーキテクトと月1で利用状況や新しい技術情報の共有をしています。また、サービス単位でソリューションアーキテクトとシステムアーキテクチャーの検討をしたり、プロフェッショナルサポートサービスから移行の支援を受けたりして、新しい技術に触れる機会に満ちています。   目指すところ   オンプレからクラウドへの移行で持たざる経営を実現します。これで需要変動に柔軟に対応できるようになりますが、ゴールではありません。クラウドへの移行はアーキテクチャーをほとんど変更しない、いわゆるLiftで行っています。次にやるべきはネイティブ化です。アーキテクチャーを見直し、クラウドのメリットをフル活用できるようにしていきます。更にその先として、クラウドベンダーが提供するサービスやシステムの組み合わせを考えて、将来維持しなければならない開発を最小限に抑えた上で、誰が作っても同じ、何度でもやり直しできる、どこにでも展開できるサービス・システムを構築していけるようになっていきたいです。 最終的なゴールは、エンジニアが自分の、チームの、他チームのスキルを活用して、エンジニア視点でお客さまが便利だ、快適だと感じられるサービスそのものを産み出している姿です。   働く環境   まずは、品質・セキュリティ面について。良 い点なのか悪い点なのかは意見が割れるところですが、品質・セキュリティに非常に重きが置かれています。作業工程でいろいろな審査をクリアする必要があり大変ですが、品質を保つために避けては通れません。 また、どんな働き方をしているのかについても触れておきます。 今もなおコロナ禍ということもあり、リモートワーク継続中です。そんななか、出社していたときには感じていなかった不便さがいろいろ見えてきました。 なかでも、コミュニケーションロスは大きな問題です。Web会議ツールを使っても、直接顔を合わせていた時と比べると、やはり不便さを感じてしまいます。 そのため、まん延防止等重点措置や緊急事態宣言が解除されている期間は週1日以上出社し、以前のようなコミュニケーションの場を確保しています。 当グループは社員が少ないこともあり、派遣社員や委託先パートナーの方々の協力を得て、共にどう前に進んで行こうかということを常に考えています。特に、社員しか知りえない社内組織の関係性をメンバーと共有し、メンバーが動きやすくする点にこだわっているためコミュニケーションは不可欠なのです。 リモートワークでも、出社でもコミュニケーション良く、チーム、部、他部門と連携を取って業務を進められるところを目指していますが、2年経った今でも100%ではありません。 それでも、仮想デスクトップを導入するなど、改善を図ってくれているメンバーもいます。 また、社員の行動指針である ビッグローブマインド についてもご紹介します。技術屋なのでその中でも「トガる」、「すばやく判断する」の2つが具現化されており、非常に大事なマインドだと考えています。 一方、基盤を預かる身としては「プロフェッショナルになる」、「変化に挑む」、「幸せを支える存在になる」とのバランスを取ることも大切です。ひたすら安全に重きをおき、変化に取り残されてしまえば、プロとしては失格ですし、幸せもやってきません。しかし、危険 を顧みずトガって、エイヤで新しいものを使い始めても、やっぱり不幸を呼び込みます。 どう両立させていくか、どう目利きとしての力を活かしていくかがポイントだと考えています。 BIGLOBEは常に新しいものに触れることができます。当然チャレンジして失敗したケースも多々あります。ですが、次の成功に繋げられるチャンスを与えてくれる会社なので、ビッグローブマインドを体現する機会がたくさんあるのも魅力のひとつです。 そのため、「やりがい」は自分次第でいくらでも広げられます。 私自身はというと、障害が起きてしまった時にとにかく解決しようと必死に向き合うのですが、姿を見て周りからは障害ジャンキーと呼ばれることがあります。誤解がないように言うと、そこには「これまでに培った自分の技術を生かせる場だ」という認識があるからです。誰にも負けない技術を身につけて、障害対応に限らず仕事に活かしていくことにとてもやりがいを感じています。   まとめ   クラウドを活用して、お客さまに直接提供するサービスをエンジニアが創っていく。そんな世界を目指しています。 オンプレとは比べ物にならない幅の広さ、変化の速さに対応しなければなりません。日々勉強し、スキルを磨き続けていきたいという希望を持った方と是非一緒に仕事をさせていただきたいと思います。   www.biglobe.co.jp   ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部です。 今回は、BIGLOBEが大切にしている行動指針「ビッグローブマインド」を体現しながら、エンジニアとして日々成長中の座間 政紀（ざま まさき）のストーリーをご紹介します。 「仕事を選ぶ基準は、成長できるか、新しいことに挑戦できるか」と語る彼は、大企業を辞めエンジニア未経験で技術職の道に飛び込み、現在は社内システムをリニューアルするプロジェクトのチームリーダーとして活躍しています。 転職を通じて組織の規模感やキャリアを大胆に変えながら挑戦してきた彼だからこそ感じる、BIGLOBEの良さや課題などを聞きました。   ※撮影時のみマスクを外しています。 座間 政紀（ざま まさき） 基盤本部 基盤系システム部 基盤横断システム開発グループ 2019年6月中途入社／社会人6年目。 前職の大手IT企業、中小企業のSIerを経て、現在はビッグローブ光のシステム開発、既存システムのクラウド化、業務画面Salesforce移行などのプロジェクトに従事している。 エンジニア未経験から大企業を辞め、技術職の道へ 仕事を選ぶ基準は、成長できるか、新しいことに挑戦できるか 人間関係が良い会社だからこそ、「トガる」意味 エンジニアとして継続的に成長していくマインドを持っていてほしい エンジニア未経験から大企業を辞め、技術職の道へ —— まずは座間さんの前職の経験について教えてください。   現在、私はBIGLOBEの社内システムのクラウド化や業務画面のSalesforce移行などのプロジェクトをエンジニアとして担っています。しかし、大学は文系、卒業後は大手IT企業の営業職に就いていたので、もともと技術職が志望だったわけではありません。当時、携わっていた官公庁向けのプロジェクトで、エンジニアの方が技術的な説明をしている姿を見て、純粋にかっこいいなと思ったのがこの道を志すきっかけになりました。営業職はお客さまに提案をする仕事ではありますが、これからの時代は技術的なことがわからないとお客さまの役に立つ本質的な提案はできないと考え、「よしエンジニアになろう！」と決断したのです。   とはいえ転職先の目処があったわけではありません。大手企業を辞めるのは思い切った行動ではありましたが、動くなら今しかないという強い想いでプログラミングスクールに通い技術を身につけました。それも、仕事をやりながらの片手間ではなく、時間的リソースは全て勉強にあてました。   —— まさに全力投球ですね！   はい。その後も、エンジニアとして雇ってくれるところならどこでもいいから修行したいとの思いから、受託開発をメインとする100名規模のSIerに入社しました。いろいろな案件を短いスパンでたくさんできる会社で、基本言語はJavaで運用保守ではなくシステムや機能のバージョンアップなどを主に手がけていました。   —— 営業職からの大胆なキャリアチェンジを行い、その後BIGLOBEに転職された理由とは？   SIerで受託開発案件に3年程携わったので、今後は自社開発のサービスを持っている企業で働きたいと思ったのです。エンジニアとしてプロダクトを育てたり、自社のシステムを構築したりしてみたいなと。その想いで何社か受けたうちの1社がBIGLOBEでした。   そして、ここを最終的に選んだ理由は“直感”です。と、言ったらまた大胆に聞こえるかもしれませんが、BIGLOBEの社風や人が自分の好ましい雰囲気だなと感覚的に思えたんですよね。例えば、面接は堅苦しくなく、後半は自社システムの話をたくさん聞かせてもらい、雑談からも面接官の人となりが伝わり「僕らの会社にも課題はたくさんあるけど、一緒に取り組んで欲しい」と言われた言葉も心に響きました。   また、技術的なところで言うと、前職では関われなかった設計手法のDDD（domain-driven design）が学べることに興味を持ちました。DDDの本を出している著名な方を会社に招いてコーチしてもらえる環境があるのは勉強になると思いました。   仕事を選ぶ基準は、成長できるか、新しいことに挑戦できるか —— BIGLOBEに入社してみて、どんな会社だと感じましたか？   これまでの私自身の経験から、BIGLOBEの組織の規模感は大きすぎず小さすぎずで意見を言いやすい環境なのではと感じていました。実際にも本当にそうで、自分がやりたいこと、改善したいことを説得力を持って伝えればやらせてもらえますし、上司もそういうことを言ってほしいと思っている気もします。   その反面、入社してからギャップに感じたのは、想像以上にレガシーなシステムが社内に残っていたことです。長年外注していたことが要因で、内製化が進んできたのは最近の話。古いシステムの管理の仕方がわからない、仕様がわからないということに、当時はかなり戸惑いましたね。今もその課題は残っていますが、新しい人を入れて体制やシステムも少しずつ新しいものへと移行しているので、今は転換期です。   —— 座間さんが入社されたのが2019年6月ですが、その頃に比べると具体的にはどのように変化していると感じますか？   例えば、2021年末に組織体制を大きく変更しました。それ以前は、エンジニアが企画フェーズの話を聞くことがほとんどなかったのですが、自社プロダクトのサービス開発ではアジャイルを意識したチームになり、今はこういう案件があるという話が早くから耳に入るようになりました。 style.biglobe.co.jp 私の所属しているチームはプロダクトではなくシステム寄りのプロジェクトを任されているので、品質を確保することがより重要でアジャイルな開発体制とは違う点もありますが、コミュニケーションのしやすさなどの風通しの良さは同様に感じています。   —— 座間さんがBIGLOBEに入って「成長したな」「やりがいを感じたな」と感じた瞬間があれば教えてください。   私は仕事において自分が成長できるか、やったことがないことをやれるかを重視しています。逆に言うと、納得できない仕事は受けないという気持ちでいますが、その点BIGLOBEは常に成長できる環境があると感じています。   例えば2年ほど前、Adobe Flash Playerサポート終了に伴い 、皆で必死に改修に取り組んだことがありました。任せてくれる上司だったこともあり、それまで関わったことのない画面デザインを一から勉強して、自分たちでシステムを選定して完成まで持っていくことができたのはとても良い経験になりました。さらには、今まで改修ができないシステムだったのが、自分たちで作り直したことによりユーザーの意見を取り入れて都度変更できるシステムにできたこともこの仕事の醍醐味だと感じました。レガシーなシステムがあることで困っている人がたくさんいることがわかり、システムを改修することでユーザーの運用の負担が少しでも減ったり通信がしやすくなったりすることにやりがいを感じるようになりました。   —— 仕事を通じて成長し、誰かに貢献できるのはやりがいに繋がりますよね。   そうですね。あと、入社してからDDDはずっとやっていて、非エンジニアの人とのコミュニケーションを考えながら設計できるのがとても便利だと感じています。私自身がもともと企画営業職だったこともあり、社内のそういった部署の人が技術の専門用語を知らなくても一緒にプロジェクトを動かしていける仕様にするのはとても良いことだと感じています。まだ何でもかんでも上手くいくわけではないのですが、常に考え続けることで働きやすい環境を作っていきたいと思っています。   人間関係が良い会社だからこそ、「トガる」意味 —— 座間さんの仕事の価値観などを聞いているとBIGLOBEの行動指針である 「ビッグローブマインド」 を体現しているなとも感じます。実際、このビッグローブマインドについてはどう感じていますか？   BIGLOBEらしさがまとまっていると思います。この中で特にうちの会社らしいと感じる言葉は「みんなに感謝し伝える」ですね。社内の人間関係が密接なので直に感謝の言葉を聞けるのは嬉しいことです。基本的に温厚な方が多いのでコミュニケーションは取りやすい会社だと思います。   逆にいうと、人間関係が良いからこそ強く意見を言えなかったり、優しすぎてリーダーシップをとるのが苦手だったりする面もあるかもしれません。 そういう意味では、ビッグローブマインドの中に「トガる」があり、他社の追随を許さないオリジナリティ・意外性を持つという意味なんですが、社内の職場環境にも言えることかもしれません。 自分はトガっていると言われることがあるのですが、皆が思っていることを口に出して言っているだけなんです。思っていることを素直に言うこと、そしてくじけないことなど、社内でもトガることは大事だと個人的には思います。   —— 座間さんご自身は、ビッグローブマインドの中で気に入っているものはありますか？   私が一番好きなのは「継続的に成長する」ですね。そして、必要だと感じるのは「未来起点で動く」と「お客さま目線にたって、期待を超える」です。目先のことばかり考えて簡単なシステム改修ばかりしていては誰も保守できなくなってしまう。そうではなく、3年、5年後のことを考えてシステムを作っていきたいというのが私の考えです。   現在、BIGLOBEはシステムをクラウド化し「25年DXの壁」を乗り越えようとしています。自分が気になるのはそれが終わった先、お客さまのために新しいサービスを生み出すなど、そうした動きが会社としてできるかどうかです。アジャイルを意識した新しい組織体制になったことで、これからはお客さまの要望がエンジニアにもより伝わりやすくなるので、会社としてもエンジニアとしても「未来を意識して」「お客さま目線」の柔軟な動きができるような環境づくりを期待しています。そしてもちろん、私も力になりたいですし、そのためにも常に成長していきたいですね。    —— これからBIGLOBEに必要な人材（中途・新卒採用）はどんな方だと思いますか？座間さんが一緒に働きたい人、刺激を受けるような人について教えてください。　   私は、どの会社に入ろうと市場の価値に置いていかれないエンジニアになるのが一番大切だと思っています。言い方は悪いかもしれませんが、BIGLOBEでしか働けないエンジニアには絶対ならないように、常に世の中の新しい技術を学ぶことを心がけています。これから入って来て下さる方にもBIGLOBEから学ぶ、というよりもBIGLOBEに知識を与えるくらいの気持ちでいてほしいですね。中途の方であれば特に。   あとは、楽しく働くこと。技術力向上と楽しく働くことは相乗効果があります。 だから、私個人の意見では、新しく加わる人は技術力に対する向上心と併せて、とにかく楽しそうに働ける人がいいですね。明るく、チームの雰囲気を良くしてくれる人です。エンジニアの中には、たとえ技術力はあってもそれを活かしきれていなかったり、チームとしてやった方がパフォーマンスが上がるのに1人で悩んだりする人も多いと思います。なので、チームのモチベーションを上げてくれる人がいるともっと良い職場になると思っていて、元お笑い芸人さんなんかがいたら大歓迎です（笑）。 エンジニア として継続的に成長していくマインドを持っていてほしい —— 座間さんご自身は今後どのようなビジョンをお持ちですか？   新しいことをやりたいなと思っています。AIにも関われたら嬉しいのですが、部署が全然違うので、やるとなればがっつり勉強しないといけない分野ですね。私は自分が成長できるか、やったことのないことを経験できるかを仕事を選ぶ基準にしていると先ほど触れましたが、改めて考えると、BIGLOBEに入社してからは常に成長できることをやらせてもらっているなと感じています。   —— 最後に、この記事を読んでいただいた方にメッセージがあればお願いします。   エンジニア として継続的に成長していきたいというマインドを持っている人にBIGLOBEに来てほしいし、一緒に働きたい。もちろん、エンジニア以外の職種でも同様です。   BIGLOBEの名前を知っているから、企業として安定してそうだからではなく（もちろん、その理由で来る優秀な方もいます）、BIGLOBEを一つのステップにしてやるというくらいの気持ちを持っていて欲しいと思います。   逆に私たちも、そういった人が来てくれたり、1度転職した人でもまた戻ってきて活躍できる会社にするために、組織の改善するところは改善し働きやすい会社にしていきたいですね。   —— 本日は貴重なお話ありがとうございました！   当社では一緒に働く仲間を募集しています。ご興味のある方はこちらの採用情報をご覧ください。 www.biglobe.co.jp hrmos.co   ※ Salesforceは、Salesforce.com, Inc.の米国およびその他の国における登録商標または商標です。 ※ Javaは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。 ※ Flashは、Adobe Inc.の米国およびその他の国における商標または登録商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

2022年2月25日（金）に開催される「沖縄オープンラボラトリ（OOL）2021年度活動報告会」にて当社基盤本部 ネットワーク技術部の滝口 敏行と川口 永一郎が登壇いたします。 BIGLOBEは昨年10月からOOLのModel Driven Network DevOpsプロジェクトにプロジェクト会員として参加。「NW構成情報（トポロジ）データを中心にした設計・構築・運用プロセスの検討と PoC の実施・評価」をテーマに、プロジェクト参加企業であるTIS株式会社・NTTコミュニケーションズ株式会社の方々と会社の枠を超えて活動してまいりました。 Model Driven Network DevOpsのプロジェクトとしての活動期間はまだ半年となりますが、この活動での成果を報告いたします。 オンライン開催ですので、お気軽にご参加ください。   ■イベント名 沖縄オープンラボラトリ 2021年度活動報告会／OOLフォーラム   ■主催 一般社団法人 沖縄オープンラボラトリ   ■開催日時 2022年2月25日（金）9:30-17:00 ・2021年度活動報告会（どなたでも参加可）9:30-15:00 ・OOLフォーラム（OOL会員所属の方、関係者限定）15:15-17:00 3社共同プロジェクト「Model Driven NW DevOps」活動報告　13:25-13:50 （TIS株式会社・NTTコミュニケーションズ株式会社・ビッグローブ株式会社）   ■ 開催方法 オンラインZoom（無料） お申し込みはこちら： https://ool.connpass.com/event/237538/   ■ 登壇者 滝口 敏行 (たきぐち としゆき) ビッグローブ株式会社 基盤本部 ネットワーク技術部 開発グループ 2018年12月中途入社。Prometheusを利用した監視システムの導入・運用に従事。2021年4月からはDNS、IPv4 over IPv6、NAT64/DNS64 インフラ基盤のクラウド移行・コンテナ刷新に従事。 川口 永一郎 (かわぐち えいいちろう) ビッグローブ株式会社 基盤本部 ネットワーク技術部 開発グループ 2020年入社。DNSサーバの運用、IPv4 over IPv6 基盤の開発・運用に従事。   ■ 内容 Model Driven Network DevOpsのプロジェクトは「NW構成情報（トポロジ）データを中心にした設計・構築・運用プロセスの検討と PoC の実施・評価」をテーマに、 ・構成情報を中核とした将来的なネットワークシステムの運用ライフサイクルをデモとして提示できるようになること ・その際に必要な技術・考え方・ツール等を取りまとめて公開し、オープンに応用検討ができるようになること を目標として活動しています。 この半年間の活動としては 「既存のネットワークシステムを対象に、ネットワークインフラの静的な構成情報に着目してデータ抽出とL1-L3トポロジのモデル化、その情報の応用を検討・実装」 にフォーカスして、自分たちで使えるもの（OSS）を組み合わせたシステムを実装しました。 今回の成果報告では実運用上で起こりえるユースケースデモを用意して、いったいどういったことが実現できて、どのようなメリットが得られるのかを発表いたします。   使用したOSS/ツール ・Netbox ・Batfish ・Ansible ・vrnetlab ・GitHub Actions ・Netomox/Netoviz   ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。  

基盤系システム部の梶田です。 BIGLOBEではAmazon Web Services（AWS）の活用を推進しています。AWSマネージドサービスの活用機会が増えると、イベントハンドラやフィルターとしてLambda Functionを書く機会も増えてきます。 数をこなしているうちに、Lambda Functionのイベントハンドラにはマネージドサービス毎におきまりのパターン化（お作法）があることに気づきました。 何度も現れるパターンを再利用するには、 Pythonのデコレータ機能 がうってつけです。このBlogではAWS CodeDeployを題材にして、Lambda Functionを簡素化していった過程をご紹介します。 最後のコードは驚くほど読みやすくなりますので、少々お付き合いください。 CodeDeployのイベントハンドラ デコレータを使ってお作法を隠蔽する おわりに pre.code { position: relative; padding: .25em 0 0 3em; white-space: pre; overflow-x: scroll; } pre.code::before { content: "1\a 2\a 3\a 4\a 5\a 6\a 7\a 8\a 9\a 10\a 11\a 12\a 13\a 14\a 15\a 16\a 17\a 18\a 19\a 20\a 21\a 22\a 23\a 24\a 25\a 26\a 27\a 28\a 29\a 30\a 31\a 32\a 33\a 34\a 35\a 36\a 37\a 38\a 39\a 40\a 41\a 42\a 43\a 44\a 45\a 46\a 47\a 48\a 49\a 50\a"; position: absolute; left: 0; display: block; width: 1.75em; padding-left: .25em; color: #c0c0c0; text-align: center; border-right: 1px solid #c0c0c0; } CodeDeployのイベントハンドラ AWS CodeDeployは、Amazon EC2やAmazon ECSに対する新しいサービスのリリース作業を自動化するマネージドサービスです。このサービスはリリース作業の各ステップ毎にイベントハンドラを呼び出すことができます。EC2にリリースするときはリリース媒体に同封されたスクリプトファイルを実行しますが、ECSにリリースするときはLambda Functionを実行します。 今回はECSサービスのBlue/Green Deploymentを利用します。Blue/Green Deploymentでは、リリースする（古いサービスと新しいサービスを入れ替える）直前にイベントハンドラを呼び出して新しいサービスに対してテストを流す事ができます。このテストで問題なければリリースを実行し、駄目ならリリースを停止して元のサービスを継続します。 これを実現するためのLambda Functionをざっくり書くとこんな感じになります。 これはAWS CodeDeployのAfterAllowTestTrafficイベントで呼び出すことを想定したイベントハンドラです。ファイル名は handler.py とします。 実際のテストコードは21行目から24行目までで、残りはAWS CodeDeployと対話するためのお作法のようなものです。 # -*- coding: utf-8 -*- import logging import boto3 logger = logging.getLogger() logger.setLevel(logging.INFO) def invoke (event, context): """Lambda Functionのハンドラ""" # CodeDeploy Event Hookの情報を取得 deployment_id = event[ 'DeploymentId' ] if 'DeploymentId' in event else None lifecycle_event_hook_execution_id = event[ 'LifecycleEventHookExecutionId' ] if 'LifecycleEventHookExecutionId' in event else None # CodeDeploy Eventでなければ、何もせずに終了 if deployment_id == None or lifecycle_event_hook_execution_id == None : logger.error( "CodeDeployのLifeCycle Eventではありません。" ) return codedeploy = boto3.client( 'codedeploy' ) try : # テストの実行 logger.info( "テスト実行開始" ) logger.info( "o.k." ) logger.info( "テスト実行完了" ) # (1) CodeDeploy Event Hookのステータスを「成功」にする codedeploy.put_lifecycle_event_hook_execution_status( deploymentId=deployment_id, lifecycleEventHookExecutionId=lifecycle_event_hook_execution_id, status= 'Succeeded' ) except : logger.exception( "エラーが発生しました" ) # (2) CodeDeploy Event Hookのステータスを「失敗」にする codedeploy.put_lifecycle_event_hook_execution_status( deploymentId=deployment_id, lifecycleEventHookExecutionId=lifecycle_event_hook_execution_id, status= 'Failed' ) AWS CodeDeployはLambda Functionを非同期で呼び出します。そのため、Lambda Functionの処理結果をAWS CodeDeployに伝える必要があります。27行目（コメント1）、36行目（コメント2）で呼び出している put_lifecycle_event_hook_execution_status() メソッドがそれになります。 特にデータ不正や通信エラーといった例外は正しく拾って失敗したことを伝えてあげないと、AWS CodeDeployはLambda Functionの完了を永遠に待つことになります。そういうことも考慮してプログラムしていくと、結果的に「8割がお作法のコード」ができあがります。 このようなLambda Functionが一つだけならなんとか理解できますが、増えてくると書く人も読む人もかなり苦痛になってきます。 デコレータを使ってお作法を隠蔽する というわけでお作法を簡素化する方法を考えてみます。 BIGLOBEの基幹システムはJavaとSpring Frameworkを使って開発を進めています。Spring FrameworkにはDIやAOPなど、DBトランザクション処理のようなお作法を隠蔽する機能が豊富に用意されています。 Pythonでもデコレータという機能を使えば同じようなことができそうです。デコレータとは @デコレータ名 の形で関数を装飾するだけでその関数に機能追加できるPythonの機能です。 というわけで、まずはCodeDeployのお作法を付与するlifecycle_event_hookという新しいデコレータを作ってみます。ファイル名は codedeploy.py とします。 # -*- coding: utf-8 -*- import logging import boto3 logger = logging.getLogger() logger.setLevel(logging.INFO) def lifecycle_event_hook (func): # (3) def wrapper (*args, **kwargs): """Lambda Functionのハンドラ""" # CodeDeploy Event Hookの情報を取得 event = args[ 0 ] deployment_id = event[ 'DeploymentId' ] if 'DeploymentId' in event else None lifecycle_event_hook_execution_id = event[ 'LifecycleEventHookExecutionId' ] if 'LifecycleEventHookExecutionId' in event else None # CodeDeploy Eventでなければ、何もせずに終了 if deployment_id == None or lifecycle_event_hook_execution_id == None : logger.error( "CodeDeployのLifeCycle Eventではありません。" ) return codedeploy = boto3.client( 'codedeploy' ) try : func(*args, **kwargs) # CodeDeploy Event Hookのステータスを「成功」にする codedeploy.put_lifecycle_event_hook_execution_status( deploymentId=deployment_id, lifecycleEventHookExecutionId=lifecycle_event_hook_execution_id, status= 'Succeeded' ) except : logger.exception( "エラーが発生しました" ) # CodeDeploy Event Hookのステータスを「失敗」にする codedeploy.put_lifecycle_event_hook_execution_status( deploymentId=deployment_id, lifecycleEventHookExecutionId=lifecycle_event_hook_execution_id, status= 'Failed' ) return wrapper デコレータの正体は、関数を引数に受け取り関数を返す関数です。 一見さっきのコードと同じように見えますがいくつか違うところがあります。 8行目（コメント3）のlifecycle_event_hook関数がデコレータ定義です。lifecycle_event_hook関数は関数（func）を引数に受け取り、関数オブジェクト（wrapper）を返しています。 lifecycle_event_hookの中で定義されているwrapper関数が実際にデコレータの処理を実行します。wrapper関数は最初のコードとほぼ同じですが、テストコードを実行していた部分が引数で受け取った関数の実行に変わっています。 次に最初のコード handler.py をデコレータを使うように修正してみます。 # -*- coding: utf-8 -*- import logging from codedeploy import lifecycle_event_hook logger = logging.getLogger() logger.setLevel(logging.INFO) @ lifecycle_event_hook def invoke (event, context): """Lambda Functionのハンドラ""" # テストの実行 logger.info( "テスト実行開始" ) logger.info( "o.k." ) logger.info( "テスト実行完了" ) テストコード以外がなくなって非常にすっきりしました。ついでになにもテストしていないことが白日の下に晒されました。明日のリリースはいろいろと荒れそうです。 @デコレータ名 で修飾すると、修飾された関数を引数にデコレータの関数が実行され、返された関数で元の関数を上書きします。 実際にinvoke関数を実行すると、lifecycle_event_hook関数で定義したwrapper関数が実行されます。そして、lifecycle_event_hook関数の引数funcにはinvoke関数が入っているのでwrapper関数の22行目でオリジナルのinvoke関数が実行されます。 おわりに こうしてLambda Functionのハンドラ関数側（handler.py）にはやりたいこと（テストをしてるふり）だけが記載され、デコレータ名からAWS CodeDeployのLifecycle Event Hookであることが推測できるようになりました。あとから知らない人が見ても理解しやすくなったと思います。 AWS Lambdaには、Lambda Layersという機能があります。これは、複数のLambda Functionでモジュールを共有する機能です。作ったデコレータをLambda Layersに入れておけば他のLambda Functionからも再利用ができるようになります。 BIGLOBEではAWS、Spring Framework / Java、DDDを活用した開発に注力しています。一緒に働きたいエンジニアを募集していますので、このBlogで興味を持った方はカジュアル面談でぜひ現場の様子を紹介させてください。 hrmos.co ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com, Inc.またはその関連会社の商標です。 ※ Javaは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。 ※ Pythonは、Python Software Foundationの商標または登録商標です。 ※ Spring Framework は、米国Pivotal Software, Inc. の米国またはその他の国における商標または登録商標です。