こんにちは。基盤戦略グループでエンジニアの育成をしている藤田です。 コードを書くのって、エンジニアにとっては最高に楽しい時間ですよね！ これからプログラミングを楽しみながら学びたい方、在宅勤務のストレスを吹き飛ばしたい方にオススメのイベント「コードゴルフ大会」について紹介します！ ビッグローブでは社内でIT技術の勉強会やLT大会などのイベントが頻繁に開催されています。そういったイベントをフォローして盛り上げるのも私の仕事です。 今日は、先日行われた社内コードゴルフ大会について紹介します。 コードゴルフ大会とはプログラミングをして、そのコードの短さを競う大会です。 大会といってもチャット上での「息抜きにコードゴルフすっぞ」という書き込みから始まったゆるい大会です。 この大会がプログラミング初級者から上級者まで参加できる楽しいイベントだったので、その内容と開催のコツを公開します。 コードゴルフとは コードゴルフはコンピュータプログラミング・コンテストの一種。参加者は与えられたアルゴリズムを、可能な限りもっとも短いソースコードで記述することを競う。バイナリサイズではなく、ソースコードの文字数がスコアとなる。 https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B4%E3%83%AB%E3%83%95 とにかくソースコードを短くした方が勝ちです。 大会のコンセプト とにかく誰もが「やってみよう」と思える敷居の低さにしたかったので、コンセプトは以下の2点にしました。 - 誰でも参加できること - それぞれのレベルにあった楽しみ方ができること このコンセプトに則して大会のルール、お題、進め方を決めました。 大会のルール まず大会のルールを説明します。私たちはこんなルールで競いました。 - お題を2問解き、その合計スコアで競う - 言語は自由 - 標準ライブラリ以外の利用は禁止 - スコアはソースコードに対してwcコマンドを実行して算出する $ wc -c ./a_* 272 ./a_1.py 280 ./a_2.rb 552 total - 大会期間は1週間 - 参加者はお題を解いたらチャットにスコアを貼る - スコアは何度貼ってもok。スコアが伸びるたびに貼ると良い お題のコツ：とにかく簡単に 誰でも参加できるように、できるだけ簡単なお題にします。たとえば私たちが使ったお題はこんな感じです。 引数の 'A' の数と 'B' の数を比べて、'A' のほうが多ければ 'A' を、 'B' のほうが多ければ 'B' を、同じ数なら '=' を返す。 f("Aa") => "A" f("aabbB") => "B" f("Abbac") => "=" 簡単ですね。ifやforなどの基礎を学んだ人なら解けると思います。 お題を簡単にすると初級者は良いが、上級者はつまらないのでは？と思われるかもしれませんが、そこがコードゴルフの良いところ。コードゴルフはスコア（コードの短さ）が勝負なので、簡単なお題でも楽しめるんです。上級者はお題を一瞬で解いた後、「もっと短くするにはどうするか？」という自分との戦いが始まります。そして言語仕様の細かいところまで調べて最短のコードを目指します。また使用する言語を自由にしているので、スコアを上げるために新しい言語に挑戦する人もいます。つまり、お題を簡単にすることで、上級者は最短のコードへの探究心をより刺激されるんです。これぞエンジニア魂。 進め方のコツ1：あえて作ったコードを公開せず、スコアと向き合ってもらう 競技プログラミングは参加者が多いほど、初心者はコードを公開するのが億劫になります。ただコードゴルフはスコアさえ分かれば成立するので、無理にコードを公開する必要はありません。コーディングをみんなで楽しみたいなら、むしろコードを公開して他人と比べるよりも自身のコードと向き合ってもらった方がいい。なので公開するのはスコアのみにします。 進め方のコツ2：途中経過のスコアを公開して盛り上げる 大会の目的が優勝者を決めることなら、大会の最後にみんなのスコアを公開して優勝者を決めれば良いですが、我々の目的はみんなで楽しむことなので、大会途中でもスコアを公開します。 途中のスコアを知ることでお互いに探究心を刺激しあい、盛り上がっていきます。実際やってみると「え？このお題、スコアを100以下にできるの？もう少し考えてみよう」とか思います。 朝からゴルフを始める人々 進め方のコツ3：初心者フォローチャットを作る 上級者のスコアがチャットに投稿され始めると初心者のモチベーションが低下してきます。 「上級者はスコアが100切ってるのに私は500か。。やる意味ないなぁ。。」 大会の目的はみんなで楽しむことなので、そうなったらマズいですね。そのためにチャット上で初心者用の部屋を作ってフォローします。この部屋にスコアの経過を投稿してもらい、スコアが上がるごとにみんなで"いいねボタン"を押して喜びます。ある程度できるようになったら、「次は3項演算子を使ってみよう！」とか普段苦手意識のある書き方に挑戦してもらうのも良いと思います。 最後は、優勝者と笑う 上記のコツをふまえた結果、大会には多くの方がいろんな言語で参加してもらえました。 ちなみに今回優勝した方のコードはこちらです。 sub f{$_=@_[0];qw(= A B)[y/aA//<=>y/bB//]} 何これ。。プログラムというか...呪文ですねw 作者曰く「読みにくいのはオレのせいじゃない。Perlのせい」だそうですw 大会の最後が「勝って嬉しい、負けて悔しい」ではなく、みんなそれぞれに工夫して、その過程を楽しみ、共感して終われるのがコードゴルフの最大の魅力です。 みなさんもぜひ、周りのメンバーを巻き込んで開催してみてください。

開発部門（基盤本部）でエンジニア育成を担当している高玉です。 新入社員研修 の締めくくりとして、オンラインのハッカソンを5月末に開催しました。ハッカソンとは1～2日でアプリを作り上げる、企画から開発、デモまで全部入りのトガったイベントです。オンラインでのハッカソンは初めての取り組みでしたが、過去の経験を活かした事前準備と、新入社員の素晴らしいチームワークで大いに盛り上がる結果となりました。この記事では、ハッカソンの魅力とオンラインで開催するコツ、特にぶつぶつと「ひとり言」をつぶやくことの大切さについて、私たちが学んだことをご紹介します。 ハッカソンとは？ ハッカソンのメリット (1) 誰でも参加できる (2) チームメンバーが仲良くなる (3) 今の自分の実力が分かる ハッカソンのデメリット (1) 世の中を変えるすごいアウトプットはそうそう出てこない (2) 技術力の勝負になりにくい オンラインハッカソンを成功させるには？ (1) 目的と評価基準をはっきりさせる (2) 「ハッカソンあるある」を共有する (3) 強制的に休憩する時間を作る (4) 当日「絶対に迷子にさせない」準備をする (5) チームメンバーがお互いの状況を知る手段を提供する (6) これからやること・やった結果をぶつぶつとつぶやく インターネットは、すごい！ ハッカソンとは？ ハッカソン（Hackathon）とは、コンピューターに対して様々な操作を試みる意味のハック（Hack）と、それを長時間続けるマラソン（Marathon）から作られた造語です。エンジニアが楽しむお祭りとして、チーム対抗のコンテスト形式で開催されるのが一般的です。与えられたテーマに対して動作するデモをチームに分かれて開発し、最後に審査員が順位を決めます。 新入社員研修は人事部が担当していますが、 ソフトウェアエンジニアだった人事部長 からの推薦でハッカソンを新入社員研修に組み込むことになり、基盤本部が企画・運営を担当しました。 ハッカソンで達成したいことは、主催者によって様々です。達成したいことに応じて、ハッカソンのテーマも、使う技術も変わってきます。今回は、次のように狙いを定めました： 目的 新入社員研修で学んだデザイン思考・チームワークを実践する場を提供し、学びを定着させる。 テーマ 社内の課題を解決する。社内の行動指針（ ビッグローブマインド ）を身近に感じるゲームを作り、社内のベクトルを合わせることに貢献する。 使う技術、実施概要 ソフトウェア（HTML、JavaScript）で動作するデモを作る。 利用するJavaScriptゲームエンジンの講義と演習（半日）、アイデア出し（半日）、ソフトウェア開発＋デモ発表（1日）。 先輩社員がデモを審査し、順位をつける。 ハッカソンのメリット ハッカソンには様々なメリットがあります。 (1) 誰でも参加できる ハッカソンで大事なのは、動作するソフトウェアを開発することもさることながら、最後のデモを成功させることです。 やらなければならないことは山ほどあります。そもそものアイデア出し、有効なアイデアかどうかの現地ヒアリング、ソフトウェアの動作テスト、プレゼン資料作りなどなど、猫の手も借りたいほどです。理系・文系問わず誰でも貢献できます。 (2) チームメンバーが仲良くなる 短期間で一緒のゴールに向かって全力で走り切るので、強い連帯感が生まれます。 書籍「 サイロ・エフェクト 高度専門化社会の罠 」によると、Facebook 社では膨大な費用をかけて定期的にハッカソンを開催し、人的交流を促進しているそうです。 (3) 今の自分の実力が分かる ハッカソンを通じてソフトウェア開発にまつわるライフサイクルを全て体験できます。 限られた時間の中、今の自分が持つスキルで勝負するしかありません。実力が分かることで、強みをさらに伸ばすことも、補うべき弱みに気がつくこともできます。 ハッカソンのデメリット その一方、デメリットもあります。いずれも「ハッカソンに期待すること」が関係者の間でズレているときに起きる悲劇です。 (1) 世の中を変えるすごいアウトプットはそうそう出てこない 主催者が過度な期待をした結果、せっかく作った作品が評価されず、そのハッカソンが失敗とみなされてしまうことがあります。 「素晴らしいアイデアが生まれる確率」も「アイデアをデモとして表現できる確率」も決して高くはありません。すごいものが生まれればラッキー！という気持ちで、ハッカソン自体を楽しむのがオススメです。 (2) 技術力の勝負になりにくい 審査基準に依りますが、技術力の高さよりも、デモの上手さが評価されることがほとんどです。 ソースコードがきれいに書けていて、バグが一切なかったとしても、審査員はデモで評価します。そのため、コンセプトが分かりやすく、面白くてインパクトのあるプレゼン（デモ）が高く評価されます。 技術力で競い合うなら、プログラミング作成能力を競い合う競技プログラミング、システムの防御力を競い合うハードニング （Hardening）、セキュリティ知識を競い合うCTF（Capture the flag）といった別の形式のイベントがオススメです。 オンラインハッカソンを成功させるには？ ハッカソンのメリット・デメリットを紹介しましたが、どう感じられたでしょうか？ 「私の考えるハッカソンとは違う」と感じられた方もいらっしゃるかもしれません。 「ハッカソンに期待すること」が主催者、参加者、運営者、審査員でズレていると、どこかに必ずしこりが残ります。ハッカソンを成功させるために最も大事なことは、関係者間の期待値を合わせることです。 またオンラインで開催する場合の怖いところは、チームメンバーの様子が分からないことです。リアルであれば自然と分かることも、オンラインでは意識して行動しないと伝わりません。 これらを踏まえて、オンラインハッカソンを成功させるコツを、以下の6つにまとめました。 ハッカソンを成功させるには？ (1) 目的と評価基準をはっきりさせる (2) 「ハッカソンあるある」を共有する オンラインハッカソンを成功させるには？ (3) 強制的に休憩する時間を作る (4) 当日「絶対に迷子にさせない」準備をする (5) チームメンバーがお互いの状況を知る手段を提供する (6) これからやること・やった結果をぶつぶつとつぶやく (1) 目的と評価基準をはっきりさせる なぜこのハッカソンをやるのか？というWhyや、期待されるアウトプットであるWhatを明らかにし、評価基準（審査基準）をきちんと言語化しました。関係者への事前レクチャーも欠かせません。 今回のハッカソンで定めた目的は次の3つです： プログラミングを題材にして、学び方を学ぶ。 デモ作りを題材にして、チームワークを発揮。 プレゼンテーション評価を通じて、切磋琢磨。 期待するアウトプットは「ビッグローブマインドを身近に感じるゲーム」にしました。 評価基準は次の3点です： 企画構想の魅力度（5点） もし実現したら面白い！と思える企画か？ プレゼンテーションの魅力度（5点） 理解しやすく楽しいプレゼンか？ プログラムの完成度（5点） デモとして開発したプログラムが完成したか？ 今回は企画とプレゼンを高く評価することで、開発スキルがなくてもチームに貢献できることが参加者に伝わるように工夫しました。 適度な制約は、創造性を発揮させるスパイスにもなります。競い合う土俵が整っていると審査も盛り上がります。 (2) 「ハッカソンあるある」を共有する ハッカソンに一度でも参加した人なら良く分かる、落とし穴を共有しました。 結局は経験してみないと分からない落とし穴ですが、先に知っておくことで幾分かダメージを減らすことができます。 (3) 強制的に休憩する時間を作る ここからはオンラインで実施する際のコツになります。 オンラインでの作業は、思った以上にストレスがかかります。本人が気がつかないうちにストレスが蓄積していることもあります。またチーム作業が盛り上がってくると、自分から「休憩しよう」と声をかけるのが難しくなります。 今回は50分作業、10分休憩、でカリキュラムを設計しました。休憩時間になると、全員が気がつけるようチャットで連絡しました。 (4) 当日「絶対に迷子にさせない」準備をする リアルのハッカソンなら会場にたどり着きさえすればたいていは何とかなるのですが、オンラインでは一度迷子になって帰ってこれなくなることがありえます。 参加者のインターネット環境はバラバラで、突然のトラブルでネットにつなげなくなることもあるため、インターネット以外の連絡手段も用意しておくべきです。 新入社員はすでに在宅勤務に慣れていたのですが、念のため以下の情報を事前に共有しておきました。 緊急連絡先（電話番号） 連絡用チャットルーム（Chatwork） お題と評価基準のスライド（Google Slides） スケジュールと、利用するWeb会議のURL（Google Spreadsheet） チーム作業用のタスクボード（Google Jamboard） 上記の情報は、分かりやすい一カ所（チャットルームの概要欄）にまとめて記述し、もし迷子になっても困らないようにしました。 (5) チームメンバーがお互いの状況を知る手段を提供する 新入社員は オンライン飲み会 などで十分仲良くなっていたので、アイスブレイクは省略しました。 ただ、たとえお互いを良く知っていたとしても、オンラインではお互いの状況がすぐに分からなくなってしまいます。暗闇の中でもがき苦しむような感覚に陥ることすらあります。 それを軽減するために、チームごとにタスクボードを準備しました。チームメンバーがどんな作業をしているのかを可視化するためのツールです。 Google Jamboard上で、TODO、DOING、DONEの3つの領域を作り、チームでやることをタスクとしてふせんに書き出しTODOにためていきます。タスクを開始したらふせんをDOINGへ移動し、完了したらDONEへ移動します。 締め切り時間が迫ってくると、状況が分からないことへのいらだちが募ります。迷ったら一度タスクボードに戻り、落ち着いて議論するきっかけにしてもらいました。 (6) これからやること・やった結果をぶつぶつとつぶやく もしもあなたの隣で仕事をしている同僚が、ぶつぶつとひとり言をつぶやいていたらどう感じられますか？ 「ちょっと気持ち悪い」 「気になって自分の仕事に集中できない」 ...そんな意見が出てくるのではないでしょうか。 しかし、この「ひとり言」こそが、今回のオンラインハッカソンを成功させる大事な所作になっていました。 ここまでに述べた1～5の準備をし、当日は余裕をもって運営にあたることができました。各チームをフォローするため会話の様子を聞いていたのですが、最もクリエイティブだったチームは、最後まで会話量が減りませんでした。特に際立っていたのが、プログラミングを主導するメンバーの「ひとり言」です。 「ええと、今から新しいキャラクターを表示しようと思います。キャラクターを表示させる方法は、あのページに書いてあったはずなのでまずはそこを見てみますね」 「ふむふむ。このページによると、キャラクターを表示するにはスプライトっていう機能を使うといいみたいです。ソースコードも載ってるんで、それをそのままコピペして動くかどうか試してみますね。」 「うまくいった！」とつぶやけば、プログラミングが詳しくない他のメンバーも一緒に喜びます。たとえそれが小さな一歩であったとしても、チームの空気が軽くなり、盛り上がる様子が伝わってきます。 逆に、うまくいかなかった時にも、多くのひとり言が聞こえてきます。 「あれ？Aになると思ってたのに、Bになっちゃったなー。もしかして、これがダメったかな？それなら、X案とY案があるんで、ちょっと試してみるか。まずはX案いきますね」 うまくいかなかった原因と、それを解消する仮説が聞こえてきます。うまくいっていないようでも、停滞せずとにかく前進しようとしていることが伝わるので、プログラミングが得意ではない他のメンバーも安心できた様子です。 安心できると提案もしやすいようです。他のメンバーが得意なことはデザインや時間管理などバラバラなのですが、それぞれができることを上手に提案しあって、クリエイティブな成果物を生み出していました。 どのチームから出てきた成果物も素晴らしく、審査は難航しました。そして優勝を勝ち取ったのは、ひとり言を駆使し、最後まで会話が途切れなかったチームでした。 優勝作品の画面。料理ゲームをモチーフに、お客様の「かなえたい想い」に対して「インターネットサービス」を提供するゲームに仕立てました。 オフラインでは「見れば分かる」ことが、オンラインでは見えなくなります。その状況を見えるようにするのが「ひとり言」だと気がつけたのは、運営者としてとても有益でした。 とはいえ、いざひとり言を言おうとしても、なかなか口に出てきません。次回のオンラインハッカソンでは参加者同士でひとり言を言い合う練習を組み込んでみようと思います。 インターネットは、すごい！ 実は、今回利用したJavaScriptゲームエンジンは関連ドキュメントが不十分で、プログラミングに慣れていない参加者には敷居が高いものでした。しかし、新入社員は、時に「ひとり言」という武器も駆使しながら、期待以上のチームワークを発揮してデモを作り上げてくれました。デモを審査した先輩社員たちも、期待していた以上の成果物に驚き、大きな刺激を受けたと興奮気味に語っていました。 緊急事態宣言下ではありましたが、インターネットがあるおかげで新入社員は継続した学びに挑戦でき、大きく成長することができました。「インターネットは、すごい！」とあらためて感じています。そして、そのインターネットをお客様に提供できることは、私たちの誇りです。私たちと一緒にインターネットで社会を支えていきたい方を大募集していますので、もしよろしければ採用情報をご覧になっていってください。 hrmos.co

BIGLOBE鈴木(研)です。 今回は、VMwareの仮想基盤を運用していて、アラーム対応をすることがありますが、その後同じアラームがなるべく出ないように対応するといった改善活動を行った話を紹介いたします。 ■事の発端は休日の運用チームからの電話から ある日、運用チームから休日に電話連絡を受けました。vCenterのディスク使用率が90%を超えたとのことでした。 特に、ディスク使用量が急激に増えている場合は、すぐに使用率100%になってしまう場合があり、とても急ぎで対応が求められるので、 すぐにサーバにログインしてdfコマンドを実行してみました。 vCenterのサーバ名:~ # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 11G 6.5G 3.7G 64% / udev 7.9G 168K 7.9G 1% /dev tmpfs 7.9G 40K 7.9G 1% /dev/shm /dev/sda1 128M 39M 83M 32% /boot /dev/mapper/core_vg-core 50G 281M 47G 1% /storage/core /dev/mapper/log_vg-log 9.9G 8.5G 950M 91% /storage/log /dev/mapper/db_vg-db 9.9G 465M 8.9G 5% /storage/db /dev/mapper/dblog_vg-dblog 5.0G 331M 4.4G 7% /storage/dblog /dev/mapper/seat_vg-seat 25G 2.7G 21G 12% /storage/seat /dev/mapper/netdump_vg-netdump 1001M 18M 932M 2% /storage/netdump /dev/mapper/autodeploy_vg-autodeploy 9.9G 151M 9.2G 2% /storage/autodeploy /dev/mapper/invsvc_vg-invsvc 9.9G 384M 9.0G 5% /storage/invsvc 確かに、 /storage/log が 91% になってました。何回かdfコマンドを実行してみて、/storage/logの使用量の増え方が急激ではないことを確認できたため、緊急性は下がりました。 ■「何が原因か？」調べてみた どのファイルが肥大化しているのか、duコマンドで調べてみました。 vCenterのサーバ名:~ # cd /storage/log vCenterのサーバ名:/storage/log # du -sh * 16K lost+found 4.0K remote 8.3G vmware まずは、 vmware 配下で9.9GBのパーティションのうち、8.3GB使っていることが分かりました。 /storage/log/vmwareでどのディレクトリ/ファイルが肥大化しているのか、さらにduコマンドで調べてみました。 vCenterのサーバ名:/storage/log # cd vmware vCenterのサーバ名:/storage/log/vmware # vCenterのサーバ名:/storage/log/vmware # du -sm * 6 applmgmt 3346 cloudvm 149 cm 4 dnsmasq.log 1 dnsmasq.log.1.bz2 1 dnsmasq.log.2.bz2 1 dnsmasq.log.3.bz2 1 dnsmasq.log.4.bz2 1 dnsmasq.log.5.bz2 120 eam 57 iiad 40 invsvc 0 journal 1 mbcs 1 netdumper 65 perfcharts 1 rbd 44 rhttpproxy 1 rsyslogd 521 sca 10 syslog 168 vapi 1 vapi-endpoint 1 vctop 1823 vdcs 1 vmafd 514 vmafdd 1 vmdir 78 vmware-sps 1 vpostgres 1060 vpxd 13 vsan-health 13 vsm 215 vsphere-client 1 vws 223 workflow cloudvm というディレクトリ配下が怪しいことが分かり、更に掘ってみました。 vCenterのサーバ名:/storage/log/vmware # cd cloudvm vCenterのサーバ名:/storage/log/vmware/cloudvm # du -sm * 1 cloudvm-ram-size-output 1 cloudvm-ram-size-output-20200704.bz2 1 cloudvm-ram-size-output-20200705.bz2 1 cloudvm-ram-size-output-20200706.bz2 1 cloudvm-ram-size-output-20200707.bz2 1 cloudvm-ram-size-output-20200708.bz2 1 cloudvm-ram-size-output-20200709.bz2 1 cloudvm-ram-size-output-20200710.bz2 3308 cloudvm-ram-size.log 1 install-parameter.log 0 service-config.log 37 service-control.log cloudvm-ram-size.log が1つのファイルで3.3GBも使っていることが分かりました。 このファイルは、テキストファイルでした。 vCenterのサーバ名:/storage/log/vmware/cloudvm # file cloudvm-ram-size.log cloudvm-ram-size.log: ASCII text このcloudvm-ram-size.logというファイルが何者かを調べてみようと思い、 Google先生 に聞いてみることにしました。 ©2018 Google LLC ※ GoogleおよびGoogleのロゴは、Google LLC の商標です。 すると、すぐに下記KBにたどり着きました。 kb.vmware.com どうも、 cloudvm-ram-size.log のログローテーションをしていない不具合 に当たったようです。 ■障害対応作業の実施 KBの内容に従い、下記対処を実施しました。 /etc/logrotate.d/cloudvm_ram_size.logを下記内容で作成 /storage/log/vmware/cloudvm/cloudvm-ram-size.log{ missingok notifempty compress size 20k monthly create 0660 root cis } logrotate -f /etc/logrotate.conf logroteteコマンドを実行した後、/etc/logrotate.d/cloudvm-ram-size.logファイルの中に compress というキーワードがあることを思い出しました。 案の定、 bzip2コマンド が動いていました。 top - 17:53:11 up 582 days, 18:14, 2 users, load average: 2.20, 2.53, 2.05 Tasks: 199 total, 2 running, 197 sleeping, 0 stopped, 0 zombie Cpu(s): 3.7%us, 3.1%sy, 12.4%ni, 80.6%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 16081M total, 15915M used, 166M free, 899M buffers Swap: 26619M total, 1802M used, 24817M free, 9124M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4761 root 20 0 13444 6920 460 R 98 0.0 5:33.22 bzip2 22744 root 30 10 834m 86m 12m S 10 0.5 0:10.76 vmware-vws 5704 root 20 0 24588 1044 596 S 2 0.0 3771:01 cgrulesengd 7802 vpostgre 20 0 769m 36m 35m S 2 0.2 21:31.12 postgres 8964 root 20 0 1952m 576m 56m S 2 3.6 22318:48 vpxd 10052 vdcs 20 0 1371m 338m 13m S 2 2.1 5369:51 vmware-vdcs 24490 root 20 0 17136 1352 940 R 2 0.0 0:00.01 top 1 root 20 0 10556 668 636 S 0 0.0 7:34.45 init ・・・ ここで2つの心配をしました。 CPU高負荷でvCenterの動作不具合が起きないか？ 圧縮しているせいで、/storage/logの使用率が100%にならないか？ このvCenterは、休日はほとんど何も処理しない業務のVMしか載せていないし、vSphereAPIでシステム連携とかもないから大丈夫であることはわかってはいたので、とりあえずは一安心することにしました。 結果としては、20分ほどかかって処理は無事完了しました。使用率の下記のとおり 57% まで下がりました。この時点で運用チームに連絡し、アラームが解消していることを確認してもらい、対応完了としました。 vCenterのサーバ名:/storage/log/vmware/cloudvm # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 11G 6.4G 3.8G 63% / udev 7.9G 168K 7.9G 1% /dev tmpfs 7.9G 40K 7.9G 1% /dev/shm /dev/sda1 128M 39M 83M 32% /boot /dev/mapper/core_vg-core 50G 281M 47G 1% /storage/core /dev/mapper/log_vg-log 9.9G 5.3G 4.1G 57% /storage/log /dev/mapper/db_vg-db 9.9G 465M 8.9G 5% /storage/db /dev/mapper/dblog_vg-dblog 5.0G 331M 4.4G 7% /storage/dblog /dev/mapper/seat_vg-seat 25G 2.7G 21G 12% /storage/seat /dev/mapper/netdump_vg-netdump 1001M 18M 932M 2% /storage/netdump /dev/mapper/autodeploy_vg-autodeploy 9.9G 151M 9.2G 2% /storage/autodeploy /dev/mapper/invsvc_vg-invsvc 9.9G 378M 9.0G 4% /storage/invsvc 処理完了後のファイルサイズはこのようになっておりました。 vCenterのサーバ名:/storage/log/vmware/cloudvm # ls -l total 118516 -rw------- 1 root root 7336 Jul 5 23:30 cloudvm-ram-size-output-20200705.bz2 -rw------- 1 root root 7094 Jul 6 23:30 cloudvm-ram-size-output-20200706.bz2 -rw------- 1 root root 7119 Jul 7 23:30 cloudvm-ram-size-output-20200707.bz2 -rw------- 1 root root 7116 Jul 8 23:30 cloudvm-ram-size-output-20200708.bz2 -rw------- 1 root root 7093 Jul 9 23:30 cloudvm-ram-size-output-20200709.bz2 -rw------- 1 root root 6929 Jul 10 23:30 cloudvm-ram-size-output-20200710.bz2 -rw------- 1 root root 6255 Jul 11 18:03 cloudvm-ram-size-output-20200711.bz2 -rw-rw---- 1 root cis 30996 Jul 11 18:03 cloudvm-ram-size.log -rw-rw-r-- 1 root cis 82297341 Jul 11 18:03 cloudvm-ram-size.log-20200711.bz2 -rw-r--r-- 1 root root 248396 Jul 11 06:00 install-parameter.log -rw-r--r-- 1 root root 0 Feb 9 2016 service-config.log -rw------- 1 root root 38581654 Dec 18 2018 service-control.log 3GB越えのファイルが、80MB程度バイトに圧縮されました。 圧縮対象のファイルが テキストファイル であったので、圧縮率が非常に高かったため、パーティションの空き容量が少ない中で、無事処理が完了したと思います。 もし、compressを付けなかったら、私の障害対応作業で/storage/log の使用率は100%になっていただろうと思います。 ■まとめ 何年か運用して、じわじわとcloudvm-ram-size.logのサイズが肥大化していき、やっと/storage/logの使用率がアラーム閾値を超えて気づくという、いわゆる 不発弾 の発見といえるでしょう。こういったものは、製品検証時では見つからないものです。 今回は、運用チームからのアラームコールを対応し、VMware社のKBにすぐたどり着いて対応策が決まったのはラッキーでした。他のvCenterにも後日 横展開 で同じ対応を実施して改善を図ることが出来ました。 ちゃんと、こういった運用での出来事を横展開で改善していくという活動は大切であることを、実際やってみて認識を新たにしました。 こういう活動の積み重ねがインフラの品質を高めるもので、非常に地道ではありますがおろそかにできないことです。 あと、最近はメンバにマシンを触るのを任せっきりで、私自身はあまり触っていない中で、休日に運用チームからアラームコールをもらったので、ドキドキしながらの障害対応作業ではありました。もう少し触って慣れておかないと、いざという時には役に立たないなぁと思いました。普段ちゃんとやってくれているメンバに感謝です。 ※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。 ■お知らせ VMwareユーザ会（VMUG）に興味のある方は、 https://www.vmug.com/membership/membership-benefits から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。 以上です。

はじめまして。BIGLOBEのN澤です。 最近は気軽に外出しづらい世の中ですので、休日はステイホームで動画サイトを楽しむことが増えてきました。お気に入りの動画は、かつて一世を風靡した某冬ソングの女王が最近の流行りの曲をピアノで引き語りながら暴走 (暴奏?) する動画です。 ということで、今はインターネットで誰もが手軽にさまざまなコンテンツを楽しむことができる時代です。特に光ファイバーのような定額の固定回線では、「ギガが減る」ことを気にする必要がないため、動画のような大容量のコンテンツを楽しんでいる方も多いのではないでしょうか。そのような背景もあり、インターネットのトラフィックは毎年、指数関数的に増加する傾向にあります。 増え続けるトラフィック、どうする？ IPv4？IPv6？ IPv4 over IPv6とは？ NAT64/DNS64とは なぜNAT64/DNS64に取り組むのか NAT64/DNS64導入までの道のり 不具合と立ち向かう そしてリリースへ おわりに 増え続けるトラフィック、どうする？ BIGLOBEのようなインターネットサービスプロバイダ (ISP) にとって、トラフィックの増加は非常に悩ましい問題です。定額で使い放題！とはいえ、インターネット回線の設備能力は有限です。そのため、トラフィックが増加すると混雑が発生し、お客様に快適なインターネット接続を提供することが困難になってしまいます。 そこで、限りある資源を有効活用するため、さまざまな技術的な解決策が存在します。そのひとつは、IPv6回線の活用です。 IPv4？IPv6？ インターネットの回線は世の中に2種類存在しています。IPv4の回線とIPv6の回線です。 一般的に、IPv4回線 (PPPoE) は混雑しやすく、IPv6回線 (IPoE) は空いている傾向があります。理由は、ISPとIPv4回線 (PPPoE) を接続する部分に存在する「網終端装置」と呼ばれる設備がボトルネックとなっているケースがあるためです。IPv6回線 (IPoE) にはこの網終端装置が存在しません。まとめると下記のような状況です。 ボトルネック 混雑度 IPv4回線 (PPPoE) あり (網終端装置) 混雑している IPv6回線 (IPoE) なし 空いている であれば、インターネットを快適に楽しむためには、IPv6回線を使って接続すれば無事解決ということですね。めでたしめでたし。 と言えるほど話は単純ではありません。なぜなら、IPv4回線とIPv6回線には互換性がないからです。そのため、インターネット上のサーバにIPv6回線からアクセスしようと思った場合、そのサーバは従来のIPv4アドレスに加えて、IPv6アドレスも持つ必要があります。 例えば BIGLOBEのポータルサイト の場合、下記の2つのIPアドレスを持っています。 IPv4アドレス: 133.208.59.131 IPv6アドレス: 2001:260:401:3df::3 アドレスの桁数も違えば、文字の種類も違いますね。見るからに互換性がなさそうです。 このようにサーバ側がIPv4アドレスに加えてIPv6アドレスも持っていればよいのですが、世の中にはIPv6アドレスを持っていないサーバもまだ数多く存在しています。その場合、IPv6接続を諦めるしかないのでしょうか？いいえ、ここにも技術的な解決策が存在します。それは、「IPv4 over IPv6」と呼ばれる技術です。 IPv4 over IPv6とは？ IPv4 over IPv6にはいくつかの種類があります。いずれの場合も簡単に説明すると、ある特殊な仕組みを利用して、IPv4回線に流れるデータをIPv6回線に流してしまおう、というものです。この仕組み自体は珍しいものではなく、BIGLOBEをはじめとするさまざまなISPで採用されています。BIGLOBEではこれまで、「MAP-E」と呼ばれる方式を採用してきました。長くなってしまうため詳細は省略しますが、興味がある方はぜひ調べてみてください。 前置きが長くなってしまいましたが、ここからがいよいよ本題です。BIGLOBEでは、IPv4 over IPv6方式として、2019年10月に 固定回線としては世界で初めて「NAT64/DNS64」と呼ばれる技術を商用化いたしました (2019年10月28日時点、MM総研調べ)。非常にチャレンジングな取り組みでしたが、いかにして世界初を成し遂げたのかを今回ご紹介させていただこうと思います。 NAT64/DNS64とは まず初めに「NAT64/DNS64って何？」というところからですね。 「エヌエーティーシックスティフォー」というと某アイドル集団のような感じがしますが、一般的に「ナットろくよん・ディーエヌエスろくよん」と読みます。注意したいのは「ろくよん」の部分です。「ろくじゅうよん」ではないのです。これは前述の「IPv4 over IPv6」に由来します。IPv6とIPv4を相互に変換する技術のため、「64 (ろく・よん) 変換」とも呼ばれます。 NAT64/DNS64の場合、「DNS64」と呼ばれる装置と「NAT64」と呼ばれる装置を利用して、このIPv4 over IPv6を実現しています。 例として、IPv4アドレスしか持たないあるサイトに、NAT64/DNS64でIPv6回線を通してアクセスする場合の流れを下記の図に示します。 ※図中のURLやIPアドレスは全てダミーのものです。 各ステップをもう少し詳しく説明すると、下記の通りです。 お客様は「ipv4-only.example.com」に接続したいため、DNSにIPアドレスを問い合わせます。 通常のDNSの場合、「ipv4-only.example.com」が持つ203.0.113.1というIPv4アドレスを回答します。しかしDNS64の場合、対象のサイトがIPv4アドレスしか持たないとき、一定のルールに従ってIPv4アドレスをIPv6アドレスに変換 (DNS64変換) します。 DNS64はDNS64変換したIPv6アドレスをお客様に回答します。 お客様はDNS64変換されたIPv6アドレスにアクセスします。このときのアクセスは全てNAT64装置に向かいます。 NAT64装置はDNS64変換されたIPv6アドレスを元のIPv4アドレスに戻します。 NAT64装置は元のIPv4アドレスである203.0.113.1にアクセスし、お客様が欲しているコンテンツを取得します。 NAT64装置はお客様にコンテンツを返却します。 以上がNAT64/DNS64の仕組みです。仕組みとしては、比較的シンプルだと思います。 なぜNAT64/DNS64に取り組むのか NAT64/DNS64の仕組みはご理解いただけたかと思います。ここでひとつの疑問が生じます。 「なぜMAP-EがあるのにNAT64/DNS64もやるの？」 非常によい質問ですね！ 答えは、NAT64/DNS64はMAP-Eにはない大きなメリットがあるためです。それは、 「NAT64/DNS64はお客様宅内に特別な機器の設置が不要」 であるためです。MAP-Eを使おうと思った場合、宅内にMAP-Eに対応した (無線LAN) ルータが必要になります。最近の国内メーカーさんの無線LANルータであれば対応機種は多いのですが、対応していない機種もまだまだあります。BIGLOBEはお客様の「安心・安全」を第一に考える会社ですので、PCに不慣れなお客様にとっては難しい「ルータの交換」といった作業はなるべく避ける必要があります。そのため、NAT64/DNS64の選択はBIGLOBEにとって最適な選択だったのです。 そのような理由からNAT64/DNS64の導入を決定したBIGLOBEですが、先述の通り、道のりは平たんではありませんでした。ではいったい、何が困難だったのでしょうか？ NAT64/DNS64導入までの道のり NAT64/DNS64導入の検討は2017年に始まりました。若手エンジニア数人の検証チームが発足し、導入に向けた評価を行うことになりました。まずは社内の評価環境でNAT64/DNS64のネットワークを作成して動かしてみたところ、問題なく動作しました。「これならいける！」と思い、次はお客様向けの本番環境にNAT64/DNS64を作成しました。いきなり全てのお客様向けに公開するわけにはいきませんので、先行トライアルとして1000名のお客様にご協力いただき、NAT64/DNS64のテストを行いました。その結果… 不具合の嵐！！ なんということでしょう。社内で検証した際には特にトラブルはなかったのに！ 調査を進めていくうちに、さまざまな問題が明らかになりました。特に大きな問題となったのは、互換性の問題です。 NAT64/DNS64は先述の通り、ISP側でIPアドレスを変換して通信を行います。ほとんどの場合は問題なく通信ができるのですが、一部のサービスやアプリでは不具合が発生することが分かりました。理由はさまざまですが、IPアドレスを変換することがどうやら「不正な通信」とみなされてしまうことがあるようです。特に「オンラインゲームの認証に失敗する」という不具合報告が多く寄せられました。また、特定のOSやアプリ、IoT機器などで通信ができないといった不具合も見られました。 もちろん社内での検証の際には、多くの機器やアプリで評価を行い、問題ないことを確認していました。しかしそれでも社員数人では、検証できるサービスに限りがあります。1000人規模のお客様のさまざまな環境による、さまざまな使い方で、多くの問題点を洗い出すことができました。フィールドテストというものの重要性を思い知らされました。 この「さまざまな環境」というのがNAT64/DNS64にとっては大きな問題なのです。実はNAT64/DNS64は世界中のモバイルキャリアでは採用実績があります。しかし、固定回線では採用実績はありません。これはおそらく、モバイルであれば端末やOSなどの環境や使い方がある程度統一されていることにより、固定回線に比べて不具合が少ないためと考えられます (一部のプラットフォームでは、NAT64/DNS64への対応を必須にしている場合もあります)。 不具合と立ち向かう ではBIGLOBEはこの不具合とどのように戦ったのでしょうか？それは、 「NAT64/DNS64を諦める」 ことです。 「お前は何を言っているんだ」 と思ったでしょうか。NAT64/DNS64を全て諦めるわけではありません。不具合の出るサービスの場合のみ、諦めるのです。どういうことかというと、DNS64側に細工をしました。 通常、DNS64はどのようなURLの問合せであっても、そのURLがIPv6アドレスを持たない場合、IPv4アドレスをDNS64変換して回答します。このDNS64に、NAT64/DNS64環境では不具合が発生するサービスのURLを登録しておきます。BIGLOBE社内ではこの機能を「対象外リスト」と呼んでいます。対象外リストに登録されたURLに対しては、DNS64変換を行わないように制御することで、NAT64/DNS64環境においても問題なく通信が行えるようになりました。 ※図中のURLやIPアドレスは全てダミーのものです。 この対象外リストの機能は、社内のエンジニアによってわずか3日で開発し、リリースされました。お客様の安心・安全を第一に考えるBIGLOBEですので、お客様にご迷惑をおかけしてはならない、という熱い思いで3日間不眠不休で取り組みました (嘘です。ちゃんと寝ました)。さらにこの機能、特許出願中です！ ここでまたひとつ疑問が生じます。 「対象外リストの登録ってどうやってやるの？」 またもよい質問ですね。答えは… 「人力です。」 なんということでしょう。インターネットという最先端の領域において、(固定回線では) 世界初で特許出願中の機能は、社員数人の涙ぐましい人力で支えられていたのです。このあたりの非常に泥臭い運用が必要となるところも、NAT64/DNS64の難しさではないかと思っています。 今後は対象外リスト登録の自動化も検討していく予定です。 そしてリリースへ このように泥臭く汗臭く涙ぐましい努力の結果、2019年10月にはNAT64/DNS64を晴れて本格スタートすることができました！ 「インターネットが速くなった！」という喜びの声がお客様から届いたときには、全てが報われたような気がしました。エンジニアにとって、開発していたサービスを無事リリースできたときの喜びは、何ものにも代えがたいものです。そしてBIGLOBEでは現在、NAT64/DNS64のさらなる拡大に向けて、日々奮闘しています。 おわりに 最後まで読んでいただきどうもありがとうございました。今回ご紹介したNAT64/DNS64導入の奮闘記は、ほんの一部です。ここには書けないような裏話もたくさんあり、全てをまとめると本が1冊書けるのではないかと思います。今回の記事を通して、NAT64/DNS64に少しでも興味を持っていただければ幸いです。それではまたお会いできる日まで。

みなさん、こんにちは。TechBlog編集部です。 BIGLOBEでは未来を意識し、一歩先を見てお客様の期待を超えるようなサービスの開発を目指しています。 今回は、企画部門や技術部門の責任を持つ立場の者が、10年後のBIGLOBEについて社内エンジニアに向けて考えを語りました。 BIGLOBEはどのような会社、チームになるのか、10年後はどんなサービスをみなさまに提供していくのか、目指す方向が見えると思います。 ぜひお読みください。 人物紹介 パネルディスカッション 10年後に価値を生み出す会社、チームとは？ 活躍できるエンジニア像 エンジニアのワクワク感 苦しいけど楽しいと思えるコツ 10年後活躍しているチーム 新しい在り方に踏み出すには 視聴者質問 おわりに BIGLOBE社内に向けて作ったイベント告知ポスター 人物紹介 【パネリスト】 高宮 展樹（基盤本部 副本部長） 大縄 陽一（基盤本部 副本部長） 黒川 英貴（コンシューマ事業本部 副本部長） 【コーディネーター】 杉森 隆行（人事部 部長） パネルディスカッション ＜杉森＞ 10年後の未来を語るパネルディスカッションです。振り返ってみると10年前から2020年までの間もだいぶ変わってると思うんですよね。 そこで、この先2030年に向けてどうなっていくかをみなさんと考えたいと思います。 2010年何があったか考えると、BIGLOBEでアジャイル開発や内製化が始まった年です。また、特徴的なところだと、 Smartia という独自のAndroidタブレットをBIGLOBEが出したり、 IPv6 頑張るぞって言っていたような年でした。 今回、3人の方にパネリストとして登場してもらいますが、偉いからではなく、歴史を知る生き証人として、この10年を知っている人に語ってもらいます。 （※編集部注記：杉森は 以前エンジニア でした。） ＜黒川＞ 10年早いですねー、あっという間です。 10年前は、前職でiPhoneのトラフィックと戦ってました。私はもともとメーカー出身で無線をやったり交換機をやったり、そこからキャリアを経て、2017年にBIGLOBEに入社しました。この10年間、環境の変化が激しかったが、通信とサービス中心にやってきました。 ものづくりが好きで、プライベートでは焚火とかブッシュクラフトやります。高宮さんと一緒によく焚火にいきます（笑） 　 ＜高宮＞ 1992年の4月、28年前にNECに入社しました。インターネット技術研究所に所属後、2000年にBIGLOBEに異動し、ネットワークを始め、クラウドやモバイルや運用など、色々担当させていただきました。 ＜大縄＞ 1990年NECに入社し、（BIGLOBE前身の）VAN技術本部に配属されました。 VAN事業は（良い意味で）はみ出しもんが集まる部署で、いろいろなことをさせてもらいました。10年前というと、メッセンジャーとかプレゼンス系のサービス、ストリーム配信とか認証プラットフォームとかやってましたね。 10年後に価値を生み出す会社、チームとは？ ＜杉森＞ パネリストのみなさんの経歴が分かったところで本題に入っていこうと思います。 10年後に価値を生み出す会社、チームとはなんだろう？ ＜高宮＞ 10年後って、どうなんだろう。 インターネットで未来年表というのを見つけて、10年後の未来が書いてあったので見てみました。 「人間の脳がクラウドとかネットワークに繋がるよ」 「個人の体験を匂い、温度、湿度、心理についても生々しい感触で保存できるようになる」 など、まあいろいろ言われていますが、自分自身が10年後の未来を見通せるかと言われると自信はありません！ 10年後のBIGLOBEは仮に7%ずつ成長すると、今年度の売上・損益は約2倍に成長してますよ。 ＜杉森＞ （10年後の）会社ってどんな感じなんですかね。 ＜大縄＞ BIGLOBEで最初の企業理念を作る委員の一員でしたので思い入れも深いのですが、企業理念 「つながる歓び、つなげる喜び」 がベースのビジョンだと思います。 私は、異文化交流みたいな事がやりたいです。例えばおじいさんと子供、外国人と日本人をつなげていくようなプラットフォームを作ってくような会社になってるんじゃないかと思います。 ＜黒川＞ 我々が現状、事業としているインターネットに関して言うと、24時間365日、脳がインターネットに直結している状況になるのではないでしょうか。 ＜杉森＞ 今とは全く違うことやってる企業になってるかな？ ＜高宮＞ どうですかねー。自動運転が当たり前になっても自転車がなくならないように、ブロードバンド常時接続が当たり前になっても、ダイヤルアップはいまでも継続してご利用いただいてますし、今提供しているサービスは継続していると思います。今までのサービスに加えて、アドオンで何かをやることになると思うんですよ。 ＜杉森＞ 変わるものと変わらないものがあるんですよね。2010年ではBIGLOBEがモバイルやスマホをやるって想像していました？ ＜大縄＞ 新しいことをやろうとしていた時期だね。 ＜杉森＞ 今後の10年間でも、今までにはない、新しく出てくるものはありそうだよね。 ＜黒川＞ 今を10年前に予想ができたか？というのがあります。 10年前にガラケーからスマホになって、スマホが普及し始めた頃のトラフィックを捌く通信は常に炎上状態でした。ガラケーのときは(平均利用帯域が）7Mbps程度でしたがiPhoneで100Mbps程度になっていました。 アプリはフリー（無料）でインストールしますが、あとで課金していく（プランがある）LINEやskypeなど、キャリアビジネスが最初から有料でやっているところに、無料からはじめて有料化していくビジネスモデル（フリーミアム）が出始めていました。 10年前に感心・びっくりした技術やビジネスモデルは、今じゃあたりまえです。10年後どんなことが起きるかもわからないですし正直予想はできません。環境の変化はいつも突然、それに合わせてなにをやっていくか、そういうタイミングにビジネスの機会があると思います。 けれど、それを予想できる人なんていません。ネットの環境が5Gとなって低遅延になってくると、ゲームが好きな人はインターネットに浸ってしまう。 2030年にはインターネットに人間が直結しているのではないでしょうか。 それを予測しながらサービスを作っていく。BIGLOBEは、ずっと昔から接続サービス提供してきましたが、インターネットを生活空間として新しい価値を創造していくというのが目指すべき姿なのかなと思います。 インターネットが脳に直結する生活空間では、BIGLOBEは必要不可欠な存在となっていると思います。 ＜大縄＞ 僕の思っていることは、Amazonの成長ぶりをいいなって思うわけです。 彼らってしっかりしたビジョンとビジネスのメカニズムがあります。BIGLOBEだと つながる歓び、つなげる喜び がビジョンだと思うのですが、価値を生み出すチームとビジネスのメカニズムそれらがBIGLOBEにも必要です。 誰にどんな価値を提供するのか、そのためのシンプルなメカニズムが重要ですよね。Amazonから学ぶべきは、プロダクトを磨き、その売上を値下げに活かしてユーザを増やしていくメカニズムだと思います。 活躍できるエンジニア像 ＜杉森＞ エンジニアの姿勢、人、組織はどうなっていれば将来の会社に活躍できるのか、どういったエンジニアが生き残っていくのかについて考えたいと思います。 ＜黒川＞ さっきの続きになりますが、ありたい環境からですね。 日々の忙しさに忙殺されて、「ワクワクする気持ち」を忘れてしまいがちですが、生き生きとチャレンジ精神を持ち続けるようにしています。 個々が才能を持ち自然にチームを形成して同じビジョンに向かっていきたいです。フラットで、若手だろうが中堅だろうが関係なくアウトカムを出せる組織体にしたいと思います。(BIGLOBEに)ポテンシャルはあります。 会社というものは生活そのもの、仕事とプライベート分けるのも重要だが、会社を生活の一部であると考えたいから、自分の子どもや子孫に携わらせたいと思える企業にしたいです。 計画だけたてて、計画倒れすることもあるので、実践してチューニングしていく環境を実現したいですね。 BIGLOBEの社員を見ていて、勉強熱心だけど実践できていますかー？という点を感じます。計画するだけでなく、実践していく文化を作り上げて、実践した結果を経営に対してフィードバックする文化が必要です。 ＜杉森＞ ありたい姿で言ってた「ワクワクする人でありたい」という話を深堀していきたいと思います。 ＜大縄＞ ワクワクすることは重要だと思います。人間せっかく生きていくからには、ワクワクしないとつまらないじゃないですか（笑） エンジニアのワクワク感 ＜杉森＞ エンジニアが10年後ワクワクしていることは必要ですか？ ＜大縄＞ ワクワクするものを世間に出していくって言うのはすごくモチベーションになると思う。 ＜高宮＞ やってる最中はワクワクよりドキドキの方が大きいのかなぁ。だけど、あとで振り返るときに、”ワクワクしてたんだなぁ”と感じるんだと思います。 ＜杉森＞ ワクワクドキドキしているエンジニアのほうが活躍している？ ＜黒川＞ やっぱり楽しんでますよね。アウトプット出してて。後から見て、必然的にワクワクしてるのかなって感じます。 ＜高宮＞ やっている瞬間にワクワクを感じているかというとなんとも言えないけど、活躍しているエンジニアは振り返ればワクワクしてたな、ってなっているんだと思います。 ＜大縄＞ 会社でインターネットの事業を始めるときインターネットのこと全く知らないからワクワクも何もなかったけど、やっていくうちにワクワクしていきました。 こんなことできるのか、あんなこともできるのかって思いながら自分で作ってるから苦しいけど楽しいみたいな感じです。 苦しいけど楽しいと思えるコツ ＜杉森＞ そういう苦しいけど楽しいって思えるコツは？ ＜黒川＞ ハードル高いともちろん苦しいですよ。 でも過去にハードルを乗り越えた成功体験を持ってるとハードル高くてもチャレンジして、やってやろうという気持ちになる。私はそういう感じですね。自分で追い込んで自分で楽しむというイメージです。 ＜大縄＞ 逆につまらなくなるときは、誰のためにやっているかわからなくなる時だと思います。最終的にはお客様のため、が必然で、会社の中のしがらみのためにやってるとつまらなくなりますね。 10年後活躍しているチーム ＜杉森＞ 10年後活躍している際にチームってどんなチーム？ ＜大縄＞ まさにチーム活動の実践が大事です。 お客様のために価値を提供するチームでないといけないですし、BizDevOpsなんですよ。技術の人、営業の人、企画の人が同じ方向をむいて、サービスを具現化して回し続ける。 (※編集部注記：BizDevOpsとは、開発部門、運用部門、ビジネス部門3者でIT推進を行うことを意図します） ＜高宮＞ 10年後のチームは、お客様に向かって営業と企画と開発とがもっともっと近くにいるチームだと思います。 現状は、組織体も営業・企画・開発レイヤーで分かれていますが、10年後は、すべての機能が一つになってアジャイルチームのようになっていると思います。 お客様への提供価値を軸とすれば変化に強いチームになるんじゃないですかね。 ＜黒川＞ 今のチームって今までの組織体をベースにできているから、組織体関係なく目的のために空気を吸うように動けるようなチームになるべきです。 エンタメフリー は、「こんなこと、できるんじゃないですか」ってエンジニアから提案があって企画が生まれています。技術屋が企画しても良いと思うし、それでこそ新しいチャレンジの精神が生まれると思います。 ＜杉森＞ じゃ、なんで今チームにならないんですかね？（笑） ＜大縄＞ 僕の考えでは、経営層とPO（プロダクトオーナー）、POとチームメンバーそれぞれにギャップがある。当然ですが。 大事なのは、ギャップを埋めるための視点やスキルが不足しているのを埋める活動だと思います。ギャップを埋めるためにそれぞれが成長しなければいけない。 ＜高宮＞ その通りだと思います。 POの役割なのかな、舵取りする能力というか経験も足りないし、 各メンバーとのギャップもあります。新しいことにチャレンジして能力を獲得していくことに関しても、能力なのか、気持ちなのか、他の何かが足りないですね。 新しい在り方に踏み出すには ＜杉森＞ 最後のトピックスいきます。では、どうやってそういう新しい在り方に踏み出していったらいいでしょうか？ ＜大縄＞ 自分の経験からエンジニアって技術を学んだり何かをできたりするのが面白いです。色々アイデアが沸きます。自分もプラットフォームを立ち上げしようとして失敗したということを何回かやっています。言うは易く行うは難しっていうのが身をもってよくわかります。 どのようにギャップを埋めて行くのか、自分もチームも磨き続けることです。 価値をしっかり生み出すために何をしたらいいのか。必要なリソースだったりメンバーだったりを吟味する能力が必要です。 自分のテリトリーをわかるだけでなく、他のテリトリーのことも分かるようになっていく必要がある。これがギャップを埋めていく活動だと思います。 ＜黒川＞ まずやってみることかなと思うんですよね。 できない理由を並べたくなります。できない理由を排除するには過去の経験だったり、頭が良いとケーススタディしてしまいます。 ケーススタディすればするほど先が不安になります。リスクがあるから悩んでしまいますが、課題が分かっているのでしたら、解決するほうに力注いだほうが成功体験に繋がるので、まずは一歩踏み出す癖をつけることです。 そして、やるからには熱意が必要！ ＜高宮＞ 一歩踏み出すって言うと、「今、時間ない」、「スキルが足りない」、「環境が足りない」など、目前の話題がフツフツと湧いてくると思われますが、そのハードルを越えればいいと思います。 「時間」ならそれを捻出するために自動化など自分でできることはないか？を検討してもいいですし、「スキル」なら、自分に足りないスキルを書籍・教育などで獲得することができます。「環境」が足りないなら、自分からより良い環境へ向かうことも可能です。でも、ハードルを越えるために一番足りないのは「熱意」とか「チャレンジする気持ち」です。 周りが整えようとしても整えられないです。 BIGLOBEでは、仕事時間を学びに使っていいよって言っています。書籍も買い放題、研修も受け放題、 TechBlog 書いていいよ、 本つくっていいよ 、実は業界のプロフェッショナルが会社の中にいっぱいいます。会社にはより良い環境が整ってる場所もあります。あとは「熱意！」ですよ。 （※編集部注記：BIGLOBEでは上司の許可を得て、好きな書籍が買えます。） ＜黒川＞ そういう意味では、煩雑な仕事を効率化したり 1時間でも30分でも捻出できるようにするべきです。削減した時間をすべて仕事に費やそうとは言っていません。少しくらいの時間は新しい事のチャレンジに回せるはずと思います。 視聴者質問 ＜杉森＞ 質問したい視聴者のみなさん、マイクをオンにしてどうぞ。 （※編集部注記：BIGLOBEエンジニアが視聴していました。） 【視聴者からの質問】 チームを変えるため、ワクワクするためにしていることは具体的に何かありますか？ ＜高宮＞ チームが同じゴールを共有できていることです。自分たちで目標を立てる、チームのメンバーが定義するべきだと思ってます。今見失っているなってチームがあるなら、語り合ったほうが良いですね。 ＜大縄＞ 未来を語り合いましょう。今回、黒川さん、高宮さん、私でこういうディスカッションできたのはよかった、ありがとうございます。 以前の組織アンケートの結果から、皆が感じている、「変化は起こしたいが、未来へのワクワク感、指針がほしい」という要望に対してまずはトライしてみました。今後も、わたしの立場でやるべきことは考えて行こうと思っているので（この後に行う）アンケートにいろんな意見をください。 ＜黒川＞ 私も3年前にBIGLOBEに転職しましたが、その時、色んな会社にコンタクトして自分のやりたいことについて話をさせていただいたのですが、最終的にBIGLOBEにいこうって思ったのは技術力もあるしチャレンジできる環境もあるし、この先の人生を考えて入社を決めました。 若手もひっぱって行って、これからあるべき姿に向けて頑張っていきたい。定期的にこういう話す機会を設けましょう。 ＜高宮＞ BIGLOBEという会社がすごく好きで、コンシューマの事業が好きで、これから10年もワクワクしていきたいです。このような機会を与えてもらえてうれしいです。 皆さんの意見をおじさんチー ムだけではなく若手のチームもいろいろ声を聴かせてください。 ＜杉森＞ そろそろ、終わりにしたいと思いますが、皆さん一歩踏み出してほしいという話をしてきたのですが、この3人も、みなさんのお手本として、 TechBlog 書いてくれると思います！ 時間がないとか言わないはず。事前に調整してないけど、 TechBlog をきっと書いてくれうと思うので楽しみにしていてください！ おわりに いかがでしたでしょうか。本イベントはBIGLOBEエンジニアに向けて行ったものですがBIGLOBEが目指す方向やチームについて、ぜひみなさまにも知っていただければと思い、公開しました。 パネラーはBIGLOBEエンジニアに向けてこんなことを語っていました。 ワクワクした気持ちを忘れず、チャレンジ精神を持ち続ける お客様のために価値を提供するチームであり続ける まずはやってみることが大切 積極的にエンジニアの声を聴いていきたい 熱意を持とう BIGLOBEは、今後も変化に挑み、お客様の目線に立ち、お客様の期待を超えるサービスの提供を目指していきます。 ※商品名およびサービス名などは、各社の商標または登録商標です。

こんにちは。BIGLOBE 永末です。 BIGLOBE では近年クラウドの活用を積極的に進めています。 この度、独自開発していたレガシーシステムを、Amazon Web Services（AWS）上にサーバレス構成で作り直しました。簡単な構成なのでさくっとAWSへ移行する予定だったのですが、当初思い描いていたようには進まなかったので、失敗の過程を含めて移行の概要を紹介させていただきます。 システムの概要 作り替えを行ったのは、利用者のIPアドレスから国情報を解析し、国内or国外向けの静的コンテンツを表示するWEBサービスとなります。 ※実際のサービス仕様は上記とは異なります(説明のために改変・省略しています) AWS上でのシステム構成 AWSへ移行するにあたり、まずはサービスシステムのAWS上での構成を検討しました。 下記が当初考えていた構成です。 Route53 の位置情報ルーティングを利用して、国内or国外向けの CloudFront に振り分けています。コンテンツデータはS3に格納します。国情報を判定する独自プログラムが不要となり、利用するマネージドサービスも3つだけとシンプルでいい感じです。 念のため AWS に詳しい社外の人にもレビューを受けて「これで行きましょう」となりプロジェクトを進めていました。が、実際に構築してみたところ CloudFront の仕様で同じ名前のCNAME(代替ドメイン)を2つ以上の CloudFront ディストリビューションに設定することができず、本構成は実現できないことが判明。他の構成を検討することになりました。 次に考えたのが下記構成です。 CloudFront でセットされた CloudFront-Viewer-Country ヘッダを Lambda@Edge で解析し、国内or国外のコンテンツに振り分けます。判定プログラムが存在するので、IPアドレスの判定をカスタマイズできるというメリットはあるのですが、判定プログラムの開発と保守が必要になってしまうので、この構成も没になりました。 他にも API Gateway と Lambda を使った構成など色々検討し、最終的に採用した構成が下記となります。 最初の構成案と似ていますが、CloudFront の1つを ALB に変更しています。国外向けのコンテンツは ALB の固定レスポンスで表示します。ALB の固定レスポンスは1024文字以内と制限が厳しいのですが、今回はコンテンツサイズが小さかったため、この構成を採用することができました。 ALB の料金が発生してしまいますが、全てマネージドサービスで運用することができ、判定プログラムも不要であることから、本構成を採用しました。 CloudFront のログ検索機能の実装 サービス部分のシステム構成は決まってうまく動いたので、次に CloudFront のログを検索する機能に取りかかりました。 CloudFront のログは S3 上の複数のオブジェクトに記録されるため、アクセスログを検索しようとすると、該当時間帯のログオブジェクトを全てダウロードして検索をかけることになります。サービスの運用上もっと高速にログ検索を行える必要があったため、Athena を使って検索することにしました。ただ、全ログを Athena で検索すると AWS 利用料が高額になるため、Glue のパーティションを設定することにしました。 上記要件を満たすために考えたのが以下の構成です。 下記のように動作します。 CloudFront が S3 へログを配置する 定期実行型でログ移動用の Lambda が実行される ログオブジェクトを Glue クローラで判断できる S3 パスへ移動する 定期実行されたGlueクローラーが Data Catalog にパーティションを作成する Athenaにてパーティション指定で探索が可能となる 定期実行型でお掃除用の Lambda が実行される 起動された Lambda が不要なパーティションを削除する 上記構成で想定どおり動作して開発が進んでいいたのですが、テストフェーズで問題が発生しました。CloudFront へのユーザアクセスがすごく少なく、S3 上に出力されたログが1行しかなかった場合、Glue クローラーがパーティション作成をスキップしてしまったのです。 調べたところ、Glue クローラーはオブジェクトの行数が少ないと、データの形式を判別するための情報が足りないことにより、処理をスキップすることがあるようです。AWSのドキュメントには書いてなさそうで、テストフェーズまで気付くことができませんでした(見落としている可能性はありますが..)。 実際のサービスでは常時ユーザアクセスがあるので、CloudFront のログが1行になることはないのですが、仕様としてよろしくないため本構成は没となりました。 その後、別の構成を検討して辿り着いたのが次の構成です。パーティション作成を Glue クローラーではなく Lambda で実行するように変更しています。 CloudFront が S3 へログを配置する 定期実行型でログ移動用の Lambda が実行される ログファイルを Glue パーティション用のS3パスに移動する 定期実行型でパーティション作成用の Lambda が実行される 1ヵ月先まで Data Catalog にパーティションを作成する Athenaにてパーティション指定で探索が可能となる Glueクローラを用いてパーティション作成を行うのではなく、1ヵ月先までパーティションを事前に作成するようにしています。これにより、ログの行数に関わらず、確実にパーティションが存在する状態にすることができました。 パーティションを数年後まで事前作成することも可能ですが、作成に時間がかかることと、他システムでも流用することを考え、定期的に数か月先まで作成する方式としました。 別案としてMSCK を定期実行することも考えましたが、実行頻度やパスが固定であることと、先にパーティションを作っておいた方が確実であるため、今回は本方式を採用しました。 ALB のログ検索についてはほぼ構成が同じなため、今回は割愛します。 本プロジェクトで得られた効果(予定) 「AWS上にサーバレス構成で作り直しました」と最初に書きましたが、実は 2020年6月現在、まだサービスインできていません。すみません。 本プロジェクトにより、以下の効果を期待しています。 サーバレスになることにより、サーバ障害から解放される OS、ミドルウェアの脆弱性対応およびEoL対応から解放される 独自プログラムの保守から解放される ログ検索部分の Lambda については、言語ランタイムの EoL対応などの保守が必要ですが、この Lambda は他の CloudFront を使うシステムでも広く流用予定です。 運用業務から解放されることにより、運用に使っていた時間を新しいサービスの開発に回すことができる見込みです。 最後に シンプルな構成なのでさくっと AWS 化できると思ってやってみたら、意外と手間取った例を紹介させていただきました。 AWS のコンポーネントを組み合わせた絵を描いてみるとうまく動くように見えるのですが、実装してみると仕様の制限で動かなかった、ということがよくあります。簡単な検証をしながら本格的にプロジェクトを進めるのがよいかと思います。 以上です。 BIGLOBEではサービスのAWSへの移行に伴い一緒に盛り上げてくれるメンバーを募集しています。 hrmos.co ※ Amazon Web Servicesは、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。

みなさん、こんにちは。TechBlog編集部　堀内です。 4月にBIGLOBEへ新入社員が入社しました。 弊社の技術研修は現場の第一線で活躍しているエンジニアや管理職が自ら企画して、研修を実施しています。 技術研修ではプログラミングや、社内業務の内容を中心に教えていますが、今年はこんな講座を行いました。 「最後まで読ませる文章作成講座」 「最後まで読ませる文章作成講座」の狙い いつもBIGLOBE Styleや TechBlog をお読みいただきましてありがとうございます。 これらのメディアもBIGLOBE内のいくつかの部署の社員が集まって作成、編集しています。 TechBlog は技術部門の社員が編集部を運営しており、社内で活躍するエンジニアが実際に寄稿しています。 　「文章を書くことが苦手なので寄稿を遠慮したい」 　「書き方が分からない」 TechBlog を始めた当初はこのような声があり、寄稿してくれるエンジニアを見つけるのが大変でした。 実際に仕事で行っていることは凄いことなのに、それをアウトプットすることが苦手なエンジニアが多いことがわかりました。 それであればと、ブログ記事作成に役立つテクニックや考え方を教えるために文章作成講座を企画しました。この講座をまずは新入社員に受講してもらい、今後の TechBlog への寄稿時に活用してもらうことにしました。 これから TechBlog を書く機会がある新入社員向けに、「最後まで読ませる文章作成講座」と題して、講座を行いました。 「最後まで読ませる文章作成講座」の概要 主にこんなことをお伝えしました。 読者目線で文章を書く 読者が読みやすい文章を書く 読者が飽きずに最後まで読んでもらえる文章を書く どれも基本的なことですが、いざ執筆を開始すると忘れがちなことですがとても大切なことです。 どのように書けば読者にとって読みやすくなるのか、といった辺りを 事例を交えながら説明しました。 受講者の声 講座を受講してくれた新入社員からこんな声がありました。 文章を書く上でどれだけユーザ目線になれるのかということが、非常に大切であるとわかりました。 書き始めると文章の着地点を忘れがちになってしまった。しかし、書ききる経験ができたのがよかったです。 読み手が読む気がなくすときってどういうことか分かったところが良かったです。 少しでも役に立つ講座が実施できて、私も大変うれしく思いました。 実際に新入社員が執筆した文章を紹介します 講座の最後には、自分でタイトルや内容を考えて、好きなように文章を書いてもらいました。 その中で私が面白いと思った文章を代表して紹介します。 こんな点を面白いと感じました。 人間関係をカレー作りと見立てて読者にわかりやすく記載している 文章が読みやすく、飽きずに最後まで読めた ぜひお読みください。 人間関係はカレー作りだ 佐藤駿 さっそくですがみなさん、「人間関係について考えてみましょう～」 ....。 いま「ウッ...イヤダ...。」って思いましたね？ その気持ち分かります。世の中には色々な人がいるし、人付き合いは意外と面倒だし。 でも、私たちは何かしらのコミュニティに属していて、人間関係について考えることを避けられないでしょう。 どうにかして、面白く考えられないかなあと悩んでいたとき、私が週一でやっているカレー作りがヒントになりました。 作っているときに、人間関係とカレー作りって似ているなあって思って、カレー作りをベースに人間関係についてちょっと考えてみたいです。 「ああ、それならまぁ...。」と思いました？(思ってください) では、さっそく考えてみましょ♪ 具材（性格）にはどんな特徴があるかな？ 具材には色々な特徴がありますよね。 硬い、やわらかい、くさい、重い、軽い、などなど。 例えば、人参は硬くて火が通りにくく、ジャガイモは煮込むと溶けていきます。私はいつのまにか「ジャガイモが消えていた！」なんて経験があります。なので、こういった特徴を理解したうえで、刻んだり炒めたりしないと、出来栄えに大きな影響がでます。 人間にも、控え目な人、怒りっぽい人、ドライな人、おせっかいな人、元気いっぱいな人など、色々なタイプがいます。 人間関係では、相手の性格を理解していないと、何気ない言葉で傷つけたり、不快にさせてしまいますよね。そのため、どういう特徴があるのかを観察したり、仕草や話し方を細かく見てあげなきゃいけないと思います。 自分なりに知ろうとすることが大事ですね。 それがまず、下準備になるでしょう。丁寧にね。 火加減はどう？ 具材を炒めるとき、最初から強火で炒めると、表面だけよく焼けていて中は生なんてことありますよね。逆に、慎重になりすぎて、弱火でいつまでたっても火が通らないことも。 普段、人と接するとき、特に初対面の人と出会ったとき、最初から強火じゃないですか？ 「え？今なんて言った？」「そんなこともわからんの？」 初対面でこんな口調の人、嫌ですよね。 でもたまにいますよ！ 私はおびえたりはしませんが、本当に嫌な思いをしちゃう人もいますよね。 本人は無意識なだけかもしれないけど、言葉、態度の火加減、上手に調整できたらいいと思います。 何かを強く促したいときは強火、そっと寄り添いたいときは弱火など、時と場に応じて火加減を調整してみてほしい。 そしたらきっと、伝えたい思いがしっかり伝わる（火が通る）かな。 煮込み作業は注意してね カレーの煮込み作業、この段階が一番気をつけなきゃいけないですね。 火加減はもちろん、一瞬たりとも目が離せませんよ！ 全体を見渡して、ルウと具材を混ぜ混ぜして、いわゆる乳化（油と水をマッチ）させなきゃいけません。急いで強火にすれば、焦げて美味しくなくなってしまいます。弱火で、時間をかけてじっくりコトコト煮込むことで美味しくなっていきますよね。 人間関係も同じで、ゆっくり時間をかけながら、関係を築いていくことで、お互いに心の底まで理解しあえる関係になると思います。なかなか距離が縮まらなくて、焦ったり落ち込んだりするかもしれませんが、時間と手間隙をかけていい味（関係）にしましょう。 個性を認め合い、主張を理解し、全体が馴染んだ時、きっといい味になるはず。 寝かせることも大事かも みなさん「なんか、二日目のカレーってうまいよなあ」って感じた経験ありませんか？ 「翌日のカレーは美味しさが増す」これ常識ですよね。 (※食中毒が怖いので寝かせ方は要注意です。) 人間関係も、一度寝かせてみません？ 人間関係が嫌になった時、怒りが爆発しそうになったり、悩みをたくさん抱えてしまったときに、「もう嫌だ！（美味しくない！）」と言って、簡単に人間関係をゴミ箱に捨てるのではなく、一晩寝かせてから味を確かめてみてほしい。 寝かすことでうまみ成分が引き出て、「あら、意外といいじゃん」とか、時間が悩みを解決してくれるかも。 少し人間関係の外に出て、悩みを放置したり、振り返ったりする時間も大事だと思いますよ。 さいごに 『人間関係はカレー作り』という題名に相応しい内容か自信がないですが...（笑） 　・他人の個性を大事にすること 　・接し方を気を付けること 　・時間をかけてゆっくり関係をつくっていくこと 　・人間関係が嫌になったら寝かせてみること など、カレー作りと比較？しながら人間関係をつくる上で心がけたいことを書きました。 カレーも人間関係も、自分だけのオリジナルな作り方を見つけられるといいですね～。 みんなでカレーを作って食べたい。 以上。:) おわりに いかがでしたでしょうか。本記事ではこんなことをご紹介しました。 BIGLOBEでは、第一線のエンジニアが、新入社員に対して直接研修を行っている 技術的な研修だけでなく、文章作成講座を今年から行ってみた結果、面白い文章を書く人がいた BIGLOBEでは、ビジネスマナーはもちろんのこと、実際の業務に即したこともエンジニアが企画検討して新入社員へ研修を行っています。 文章作成講座を実施し、読者目線を意識した TechBlog を執筆できるように結び付けていきたいと感じています。

自己紹介と前置き こんにちは、BIGLOBE谷山です。 ここ最近はコロナの影響もあって、2,3か月くらいほぼ出社していないので 出勤経路を忘れかけています。 現在携わっているProjectは、何十台ものサーバから構成されるRADIUSシステムを、オンプレミスからAmazon Web Services（AWS）に移行し、かつ一部機能はサーバレス化するというProjectです。 RADIUSシステムは240万人超の会員様が利用している認証システムなので絶対に落とせません。なので、より安全に運用していくために「GitOps」の仕組みを取り入れようと開発を進めています。 モバイルコア技術部 テクノロジー開発グループ 谷山　大介 (まだ外に出れたころに山に行った時の写真です。) 2021/08/30 追記 ： 続編を書きました！ style.biglobe.co.jp GitOpsとは そもそもGitOpsって何って話ですよね。 コード管理でGitを使うのは一般化しているかと思いますが、GitOpsでは、 Git管理しているコードを中心としてDevOpsを回していく考え方で、私は以下のように理解しています。 Git上のコードを確認すれば過去を含めてAWSに構築した環境の構成がわかる状態にする。 Single source of truthとしてのgit。excelによる管理表からの脱却 gitへのアクション(push, merge, etc...)をトリガーとして、開発・運用作業をgit上で完結させることを目指す 作業品質/開発環境の平準化による属人化の回避 RADIUSシステムでは以下を組み合わせることで、GitOpsの実現を目指しています。 Git repository -> GitLab CI/CD/CT tool -> GitLab Runner Cloud service -> AWS DR(Disaster Recovery)サイトをGCP等別のクラウド環境に移す、といったことを考えたときに楽に移行できるように、コードの管理環境は外部に用意することにしました。 以下のようなイメージでGitOpsを行います。開発者は、AWSの環境を直接操作することはなく、GitLabへのコードのpushのみで開発を行います。.gitlab-ci.ymlで「決められた手順」を「実行する」ため、オペレーションミスなど、人的なミスが抑止できます。運用期間が長くなると、「実績のある手順」を「繰り返し使える」ので、より強固なシステムに育てられると考えています。 GitLab Runnerとは GitLab Runnerとは、GitLab.comが提供しているCI/CDのためのツールです。 GitLabのProjectに配置した.gitlab-ci.ymlに書かれたPipelineの内容をgitlab-runnerが インストールされたサーバが自動で実行し、実行結果をGitLabのProjectに送信します。 gitlab-runnerのインストールされたサーバは、GitLab.comが提供しているものも使用可能ですが、 自分で構築したものを登録することも可能なので、AWS環境に構築したEC2インスタンスを登録しておくこともできます。IAM roleでgitlab-runnerサーバに必要な権限を付与しておけるので、使い勝手も上がります。 .gitlab-ci.ymlの定義はやらないといけないのは手間ですが、 開発者が各自で手元に開発環境を用意する必要が無い Pipelineを常に同じサーバで実行させることができるので、環境差分/手順差分を限りなく減らせる ので、作業品質/開発環境の平準化による属人化の回避をすることができます。 GitLab Runner実行例 イメージが湧きやすいように、サンプルコードを用意しました。 GitLab RunnerでコンパイルするためのC言語のプログラムのサンプルです。(sample_code.c) 見ていただいた感謝の気持ちをプログラムに詰めます。 .gitlab-ci.ymlのサンプルです。 build stageでsample_code.cをコンパイルして、test stageでコンパイルされたコードを実行するPipelineを定義します。 これらのコードを、GitLabに作成したProjectのレポジトリに保存します。 .gitlab-ci.ymlが配置されたらそのまま自動でPipelineが実行されます。 実行されたPipelineの結果は、GitLabのProjectページで確認出来ます。Pipelineのページは以下のような形で表示されます。Pipelineの各Job(build, test)が成功しているのがわかります。 画面で表示されているbuildのボタンを押すと、build jobの実行結果画面が開けます。 Docker executorとして、gcc:latestのDockerコンテナが起動し、makeコマンドでsample_code.cをコンパイルしているのが確認できます。 また、jobで作成した成果物(ここでいうとsample_code.cをコンパイルしたbinary)が、artifactsに保存されているのがわかります。(明示的に設定しないと、jobの成果物は自動で次のjobに引き継がれることは無い) test stageも確認してみましょう。 sample_codeのbinaryを実行して、実行した結果が出力されているのがわかります。 今回は簡単なプログラムだったのでそのまま実行して結果を確認していますが、例えばデータ処理のプログラムであれば、テストケースを事前に用意し、処理を実行してエラーだった場合testをfailさせることもできます。 上記のプログラムを使ったSample Projectです。 ProjectのTOPページ https://gitlab.com/d-taniyama/gitlab_ci_sample GitLab RunnerのPipeline実行結果 https://gitlab.com/d-taniyama/gitlab_ci_sample/-/pipelines .gitlab-ci.ymlのtemplateは、GitLab.comのほうでも提供されているのでこちらも是非参考にすると良いと思います。 https://docs.gitlab.com/ee/ci/examples/#cicd-templates Gitのbranch戦略 Git管理には、いくつか有名なbranch管理フローがあります。 git flow gitlab flow github flow RADIUS開発チームでは、gitlab flowをベースにしたbranch戦略にすることにしました。 以下が、今回取るflowとなります。目下開発進行中なので、運用して行く中で改良して行く予定です master,stg,devは各環境に対応するbranchで、 feature/XX,fix/XXはtopic branchです。 ※masterは商用環境に対応 terraformの場合であれば、branchの種類によって以下のように実行内容を変えます。 【topic branch】 terraform init terraform plan 以下をbranchに対応する環境で実行 terraform init terraform plan terraform apply 展開されたリソースに問題が無ければ、stgへのmergeを行い、同じくstg環境の確認をします。 これも問題なければ、masterへのmergeを行い、商用環境にリソースの展開を行います。 もしどこかのタイミングで問題が起きれば、mergeをrevertし、元に戻ったコードでのPipelineを実行することで環境も元に戻せます。 商用環境で問題なくリリースが完了したらtag打ちをして、バージョン管理できるようにします。 terraformはリソースの変更箇所によってはリソースを削除してから再作成するため、実際の運用ではrevertしても問題が起きないのをstg環境で事前に試験をして確認することも重要です。 Projectの分割単位 システムすべてのリソースを1つのProjectでまとめて開発するのは現実的ではないので、 適切な単位にGitのProjectを分割する必要があります。 RADIUSシステムでは、以下のようにProjectを分割しています。 gitlab-ci 開発対象: .gitlab-ci.ymlのtemplate開発。Project種別に合わせたミニマムなコードを配置しておき、templateに問題がないか試験する。テストに通った時点でtagを作成し、templateを使用するProjectはtagを指定してtemplateを使う。 Pipelineの内容: 開発するProject種別によって変わる。 lambda 開発対象: Lambda向けのCやRuby,Pythonのプログラム開発。プログラム単位でProjectを分割する Pipelineの内容: build(必要なもののみ), test, push(zip化とS3への保存)。このProjectではaws環境へのリリースは行わない terraform 開発対象: terraformのtfファイルそのものの開発。aws系のProjectで作成されたzipファイルを使ったLambdaの展開や、EC2インスタンスのDeployを行う。サブシステム単位でProjectを分割する Pipelineの内容: init, plan, apply(環境branchのみ) container 開発対象: Dockerfileの開発 Pipelineの内容: build, test, push kubernetes 開発対象: Kubernetes Manifest Pipelineの内容: pull, test, deploy(環境branchのみ) プログラム単体であればツールを使った単体テストを実施し、Kubernetesの試験であればDB等も含めた接続テストを実施する等、Projectの種別によって実施するテストのレイヤを変えます。 templateの内容は、includeする側で上書きできるので、完全に共通化できないjobのscriptは各Projectで上書きします。 運用イメージ これまで説明してきた内容を元にしたGitOpsの運用イメージが以下になります イラストからは省略しましたが、topic branchのコードについては、開発環境を使って既存の環境に影響を与えない範囲でテストします。 商用環境のgitlab-runnerは、設定時にaccess-levelをref_protectedに設定して、protectされたbranchのjob以外では動かないようにするなど、セキュリティ対策も必要です。 より安全にしておくのであれば、不要な時間はrunnerのVMを停止しておくことも有効だと思います。 今後の目標 今まさに開発進行中で、「している（Doing）」の状態なので、いつか「した（Done）」記事を公開できればいいなと思っています。 開発においては、各開発Projectの中で試せるUnit testだけでなく、System test用のProjectを作成して、構築済み環境に対してSystem testを自動で実行できる仕組みも作りたいです。 まとめ 今回はGitLab + GitLab Runner + AWS構成でのGitOpsを紹介しました。 今ちょうどCI/CDやろうと思ってた、という方にちょっとでも参考になれば幸いです。 CI/CDについて詳しい方、もっとこういう設計をしたらいいのに、と思う方、 弊社は引き続き採用を進めてます。興味がございましたら以下のリンクを参照してください。 hrmos.co 2021/08/30 追記 ： 続編を書きました！ style.biglobe.co.jp ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc. またはその関連会社の商標です。 ※ GitLabは、GitLab B.V.の米国およびその他の国における登録商標または商標です。 ※ Terraformは、HashiCorp,Inc.の米国およびその他の国における商標または登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。 みなさん、以前ご紹介しましたTechBlog「 地味だけど5G時代に向けて目が離せないGSMAってご存知ですか？ 」はご覧いただけましたか？ 今回はその記事の執筆者、茶園篤（ちゃえんあつし）に話を聞きました。3GPP、GSMAという業界団体での標準化活動の経験や、BIGLOBEはどう変化していくべきなのかなどの展望についても語ってもらいました！ 茶園　篤（ちゃえん　あつし） コンシューマ事業本部　 サービスデザイン２部 シニアエキスパート 2020年3月 中途入社   3GPP、GSMAに参加していました 5Gに向けた取り組み MVNOとしての差別化 一緒に働きたい人   3GPP、GSMAに参加していました   ───　茶園さんは今年の3月にキャリア採用で入社しました。前職ではどんなお仕事をされていたのですか？   前職のソフトバンクでは標準化関係の業務を担当していて、主にGSMAという団体に参加し、そこで決定されたガイドライン/プロファイル（3GPP国際標準化を実用面でカバーするもの）の内容を社内に持ち帰って、展開、レクチャーをしていました。他にも、3GPP、OMAなどの団体の情報展開も実施していました。 そのほか、モバイルFeliCa、DPI（Deep Packet Inspection）や測位技術などの先行技術調査や商用トライアル/導入、標準化の技術に基づいた内製化の仕様策定・商用化、クラウドCoE（Center of Excellence）のリーダーとしてAWS Summitで発表する機会にも恵まれたり、直近ではクラウドゲーミングの商用提供にも関わったりしていました。   ───　3GPP、GSMAといった携帯電話の業界団体が技術の国際的な標準化を決定しているのですね。 はい。携帯電話の技術って普段意識する人は少ないと思いますが、3GPPやGSMAの枠組みを通して、世界中のオペレーターやベンダーがタッグを組んで技術仕様の策定を進めているんです。 3Gから4G/LTEになりますといったときに、技術仕様がいろいろ変わりますが、裏周りのシステムを問題なく動かすにはどう変えていくべきか、ベンダーの端末をつなぐにはどうすべきかなど事前に把握しておく必要があります。導入する際にスムーズにベンダーと話ができる素養をつくるという意味でも、業界団体で決定された標準化の情報を社内に展開していました。   ───　担当者自身が技術仕様を把握しておく必要があるのですか？   そう疑問を持たれる方もいらっしゃるかもしれませんね。 例えば、4G/LTEでお客様が利用されるトラフィックを処理するコアNW（EPC：Evolved Packet Core）の場合、コアNWを販売しているベンダー側が技術仕様を把握し、準拠さえしていればよいのではないかと。 全てベンダーにお任せするという方法もあるでしょうが、構築コストが跳ね上がってお客様への提供価格に悪影響を及ぼしてしまう、障害発生時には担当者自身がなにも分からないため手を出すことが出来ず、復旧時間が長引くことによってお客様へ多大な迷惑をおかけしてしまう、といったことにつながりかねません。 このような事態を避けるためには、担当者自身が技術知識を深めて、ベンダー側と対等に渡り合える必要があるわけです。この素養を磨いていくために、技術仕様の内容を持ち帰って理解・議論を深めておくことが大切だと考えています。   ───　とても重要な役割ですね。   必要だけど地味なところもあるわけですが、社内ではどんなことで困っているんだろう、海外での先行事例があればどんなところに苦労して解決したんだろう・社内のどんなところで役立ちそうだろう、と常にアンテナを張り巡らしてコミュニケーションを続けることで誰がどんな情報を欲しているのか分かりますし、とりあえずなにか困ったら相談してくれるようにもなります。また、社内外問わずにこういう情報なら役に立つんじゃないかと、情報を自発的に提供してもらえたりもします。とにかく相手の立場や求めていることを掘り出すために、コミュニケーションスキルと忍耐力はとても重要です。   ───　国際的な標準化活動というすごい経験をお持ちの茶園さんがBIGLOBEに入社してくれたきっかけを教えてください。   知り合いに声をかけてもらったのがきっかけですが、今となっては遥か昔にNECの研究所にいたことも影響しているかと思います。もともと、MVNOというMNO（大手キャリア）とは異なる立ち位置にも興味を持っていて、モバイル業界をもっと楽しくするためになにか面白いことを仕掛けられるんじゃないかというところに魅力を感じていました。 ただ、MVNOの立ち位置は魅力的ながら危うさを併せ持っているとも思っているんです。 単に格安で薄利多売だけだと疲弊してしまいますので、新規サービスを作ることにフォーカスをあて差別化を図るなど、生き残るためのプランを考えていかないといけない。そういった観点からも、技術情報をいろいろ発信して役立ちたいと思っています。新規サービスや技術について、一緒に考えられるメンバーをどんどん増やしていきたいですね。   ───　現在は、主に新規サービスの検討をしているのですか？   はい。MVNOとして勝ち残るために、お客様に喜んでいただくために、もちろん社員自身も喜びを感じつつ取り組めるように、いろんな方々と検討を深めていきたいです。 そのほかに、標準化に関係しますが各案件のプロセスの改善にも取り組んでいます。 各案件もそうですが、社内ナレッジなども含めて可視化を図っていきたいです。   5Gに向けた取り組み   ───　2020年3月に5Gが商用化されましたが、実際5Gってどうすごいのでしょうか？   まだ、騒いでいるほどすごくはないです。4Gの延長線で5Gが使えるようになっている状態で、ユーザーから見ると速くなったなーくらいの印象だと思います。 現在通信キャリアが提供しているのは、4Gネットワークを拡張するNSA（Non-Stand Alone）と呼ばれる形式です。 ですが、5G本来の進化はSA（Stand Alone）になってからです。そのときお客様のために自分たちになにができるか常に追っておくべきですし、MVNOとしてもSAに対応できるようにしなければなりません。 5Gの良さは単に速くなるだけではなくて、お客様の端末へのレスポンスも格段に良くなりますし、これからのIoT時代に欠かせない大量デバイスの同時接続もできるようになります。エッジコンピューティングといったいろんな技術が実は後ろ側の見えないところで動き始めるのですが、そこの準備が追い付いていないため、今は速いだけというのが現状です。 例えば先述のクラウドゲーミングもそうですが、処理自体がいくら速くてもサーバが遠いところにあれば遅延が大きくなるので、レスポンスが悪くストレスが生じてしまいます。それを改善するひとつとして注目されているのが、よりお客様に近いところで処理をするエッジコンピューティングです。 BIGLOBEではネットワークスライシングといった先進技術にも4Gの今からどんどん取り組んでおくことで、5Gの良さを最大限に引き出せるように準備を進めています。     MVNOとしての差別化   ───　MNOとMVNOの違いを分かりやすく教えてください。格安SIMってなぜ安いのですか？   MNOは自前で全国に基地局を持たないといけないので、設備投資にとてつもない資金がかかります。MVNOはその基地局や帯域などの無線通信インフラを借りているので、MNOのような事業基盤がなくても参入できる業界なんです。これだけで格安SIMの提供ができているわけではないですが、MVNOのひとつの魅力にはなっていると思います。ただ先に少し話したように、今後の競争に打ち勝っていくには格安SIMだけでは武器が少なくてリスクが大きいです。将来的に、MNOのサービスにも使ってもらえるようなプラットフォームを提供したいですね。借りているだけだと面白くないじゃないですか（笑）   ───　そうしたプラットフォームは、他のMVNO企業との差別化になり得るということでしょうか。   垂直統合型サービスといったように、MNOも含め各社それぞれブランディングしているのはひとつの良さですが、BIGLOBEを前面に打ち出す部分と、あえてその姿を消して意識せずに使ってもらうMVNE（Mobile Virtual Network Enabler：MVNO事業の構築を支援する事業者）に加え、さらにプラットフォーマーになっていくことで差別化をしていきたいと考えます 。 意識せずに使っても、裏ではBIGLOBEのIDやサービス基盤が構えている形にしないと今後伸びていきません。ですので、OTT（Over The Top：インターネット上でコンテンツを提供する事業者）がBIGLOBEと組んだら面白いことができそうだと思ってもらえるような差別化をしていきたいです。 単に格安というのではなく、BIGLOBEだったらIDやサービスをうまく連携して新たな世界を創れるんじゃないかとOTTから思ってもらえるように描いていかないと勝てないと感じています。 BIGLOBEがサービス基盤を充実させてていくことで、単に回線提供していたMNOからみても、BIGLOBEのプラットフォームを使えばMNO側自身のサービスもいろいろな広がりが考えられるよねってのはいいことかと。 実際社内では、その差別化というべきものを手掛けているところです。   ───　今後、携帯電話の利用はどのように変わっていくと思いますか？   今もそうかもしれませんが、より生活に欠かせなくなっていくと思っています。いろいろな生活シーンで意識せずに携帯、スマホを使い、ないと困ってしまうパートナーのような存在ですね。もし、そのいろいろなシーンで使えていないところがあれば、それはなぜなのか、もっと使ってもらうためにどうすればよいのか、と掘り起こすことが必要です。提供スタイルもスマホに限らないかもしれません。IoTやFWA（Fixed Wireless Access）など可能性を狭めることなく、お客様のライフスタイルにマッチするものはなにかを探っていきたいです。   一緒に働きたい人   ───　茶園さんの展望をいろいろ聞くことができました！その目標に向かって、どんな人と一緒に働きたいですか？   まず、現状に満足しない人。そして、なんでそれをやっているのか、なんのためにやるのかといった目的を考えられる人とやっていきたいです。それは個々の力を発揮するためにも必要なことですし、スケジュールの立て方ひとつにも関わってくると思っています。 また、コスト意識を身につけることも必要です。お金は決して降ってくるものではありませんよね。はたしてそれは正当な見積もりなのか、以前の案件ではどうだったのか、などコスト意識を高くもつべきだと思います。 あと、転職をお考えの方は、どんな環境でもめげずに逆境に打ち勝てる人、楽しんでやっていける人にぜひ来ていただきたいですね！   BIGLOBEでは、さらなる事業の拡大に向けて一緒に盛り上げてくれる仲間を募集しています。 ご興味のある方はこちらの採用情報をご覧ください。 hrmos.co 最後までお読みいただきありがとうございました。

どうも、IT工事の現場おじです。 5月25日、全国で緊急事態宣言が解除されましたが、弊社は基本的に在宅勤務が続いています。皆様は如何でしょうか。 在宅勤務快適！と思う反面、面倒なこともあります。 それは、サービスに影響が出てしまう可能性がある本番環境での作業をするときです。 弊社では、日本の経済を支えるインフラであるインターネットを提供する企業として、万が一にも利用されているお客様への影響を出さないため、リスクの高い作業はダブルチェックを行っています。 ダブルチェックのイメージ しかし現在は全員在宅勤務の世界。同僚を家に呼ぶわけにもいきません。 Google Meetの画面共有で、といきたい所ですが、弊社では本番環境にアクセスできるPCをセキュアに保つため、NW的に隔離しており、画面共有は使えません。 しかし、環境を言い訳にダブルチェックをしないという選択肢はありません。 テクノロジーで解決しましょう。 ※今回紹介する方法は、作業者、確認者ともにターミナルを開いて作業対象のサーバにログインする必要があります。 使うもの 音声やり取り　→　Google Meet 手順書の共有　→　Spreadsheets コンソールの確認　→　scriptコマンド 音声のやりとりは、Meetでも電話でも話せればなんでも良いです。 Spreadsheetsのように同時編集できるアプリであると結果の共有や指示が楽になります。 scriptコマンドは普段は作業ログを残す時などに使ったりしますが、今回はリアルタイム出力で使います。-f オプションを使うことで変更があるたびにフラッシュされるようになります。 使い方は下記のようにします。 作業者： % script -f /tmp/foo これで /tmp/foo にリアルタイムに画面のコピーが出力されます。 終わる時はexit で抜けます。 % exit 確認者は下記のコマンドで見ていきます。 確認者： % tail -f /tmp/foo 実際の動作は下記のようになります。 左が作業者、右が確認者です。 リアルタイムに確認者側の画面にも反映されていることが確認できます。 確認出来たらヨシ！と声をかけると感じが出て良いかもしれません。 これで普段作業する時と同じようなダブルチェックが出来るようになりました。 普段は相手の液晶を見るので画面のコマンドが見えづらかったりしますので、何ならこっちの方が楽と思うぐらいです。 それはそうと、コンソール作業は極力なくしていきたいものですね。 それでは皆様、ご安全に！

こんにちは、BIGLOBEの茶園（ちゃえん）です。 みなさんが日常的に利用されているモバイル通信は、さまざまな技術の集合体で動いています。 今回はモバイル通信の技術仕様そのものではなく、みなさんにサービスとしてお届けする上でのGSMAの役割について記載してみます。 GSMAって何？ GSMA とは、主にモバイル通信事業者から構成される「GSM Association」の略称です。 GSMとは、「Global System for Mobile Communications」の略です。 日本では利用されていないですが「2G」の通信方式でして、もともとはヨーロッパでのデジタル携帯電話の統一規格/方式として ETSI で標準化されたものです。 略語ばかりでてきますが、ETSIとは「European Telecommunications Standards Institute」の略称です。 ちなみにGSMはそもそも陸続きのヨーロッパで生まれたこともあり、国境を越えて移動することが前提でグローバルローミング機能が充実しているという特長を持っています。 つまり、いま契約している携帯電話事業者が、みなさんの訪問国の携帯電話事業者とローミング契約をしていればそのまま利用できるのは、グローバルローミング機能のおかげなわけです。 GSMAの役割って？ では、GSMAの役割とは何でしょうか？ みなさんが利用されている携帯電話の技術で標準化の大きな役割を担っているのは、GSMAではなく3GPPと呼ばれる団体です。 3GPP は「3rd Generation Partnership Project」の略称で、先ほど記載したGSMの発展形であるW-CDMAのような第3世代携帯電話システム（3G）、その後に続くLTE、LTE-Advanced、5Gなどの標準化を手がけています。 一方、本題であるGSMAの役割は、3GPPで標準化された技術仕様で抜け落ちてしまうカユイところ・溝を埋める作業をしています。 実はこれが非常に重要な作業なんです。 技術の標準化では、例えば、いろいろなフローやパラメータの入る箱を決めますが、単に箱を決めてもどの箱を使えば良いのか、箱の中身はどうすれば良いのかなど本当の詳細部分は少し解釈の余地が残されています。 そのために方言のようなものが生じたり、いざ相互接続してもうまくいかないってことは日常茶飯事だったりします。 GSMA ・W-CDMA、LTE、LTE-Advanced、5Gなど携帯電話システムの標準化を実施 ・ 世界各国の標準化機関で構成されていて、日本からはTTC/ARIBのメンバとして参加 ・事業者間の相互接続や国際ローミングなど事業者間の取り決め、ルール作り ・VoLTEやRCSなどのガイドライン/プロファイル整理も重要な役割 GSMAってあまり目立たない存在かもですが、ないと困ったりします 例えば、VoLTE、SMS、RCS（KDDIさん/ソフトバンクさん/ドコモさんの＋メッセージがそれです）などのサービスって、みなさん自身は特にどんな技術かを意識することなく利用されていると思います。 GSMAでは、みなさんがお使いのサービスを実現するうえで、ベンダや事業者がスムーズに構築できるように以下のようなプロファイルを整備しているわけです。 ・VoLTE： IR.92 IMS Profile for Voice and SMS v13.0 VoLTEプロファイルなんて呼ばれていたりもして、端末ベンダやコアNWベンダと話をする際に欠かせないものです。 IR.92に記載されているデバイスとNW間のプロトコルスタック ・RCS： RCS Univeral Profile ＋メッセージはRCSベースのサービスになりますので、技術的な観点で興味があればプロファイルを覗いてみるのも面白いかも知れません。 BIGLOBEで注目しているところ BIGLOBEとしては、GSMAの取り組みの中でも特に次のような領域に注目しています。 ・ ネットワークスライシング： 5G Network Slicing 5G以降の多様なモバイルユースケースを見据えて、お客様の使い方に応じたネットワーク機能を提供するべく、モバイルコアのCUPS（Control and User Plane Separation：制御信号とデータ信号の分離）は当然のこととして技術革新に取り組んでいきます。 ・ eSIM 最近は物理的なSIMだけではなく、ソフトウェア書き込み/埋め込み式のeSIM（embedded SIM）に対応しているデバイスが増加しています。モバイルライフ/ユースケースの自由度を高めるために注目している領域でして、その観点でもeSIM関連の仕様策定を進めているGSMAの動向には目を光らせておく必要があるわけです。 ・ MEC（Multi-access Edge Computing） 例えば、 MECベースのクラウドゲーム や通信事業者のEdge Cloud Platformに関する取り組みの リリース を出していたりしますので、いろいろな領域に視野を広げてお客様のワクワクを創出していくための動向把握も重要になってくるのです。 BIGLOBEもスライシングなどを活用してモバイルをどんどん楽しくしていきます！ MWCの主催団体でもあるんです 最後になりますが、みなさんはMWC（Mobile World Congress）をご存じでしょうか？ 世界最大のモバイル関連イベントであるMWCは、GSMAが主催しているイベントなのです。 モバイルの世界は日々変化しています。 新たなモバイルの魅力をお届けするべく、BIGLOBEも常に進化を続けていきます。 これからもぜひご期待ください。 3GPP is a trade mark of ETSI

こんにちは。TechBlog編集部 堀内です。 インターネットは生活のインフラとなっていて、私たちは毎日便利に利用しています。 当たり前のように利用ができるインターネットですが、インターネット接続を提供する企業があります。その一つがBIGLOBEです。 BIGLOBEでは安定したインターネット接続を提供できるようにさまざまな作業を行っています。その作業に事故やミスが無いように作業の品質を日々改善検討しているチームがあります。 今回は、BIGLOBEで作業品質を改善検討しているチームを紹介します。 品質改善は地道 品質改善は根気強く検討を重ねていき、大きな事故が発生しないように作業の手順や確認箇所を適切なものにしていくことが求められます。 インターネットは繋がって当たり前です。作業事故や作業ミスで、お客様がインターネットに接続できないことがあってはなりません。 BIGLOBEでは安定したインターネット接続環境を提供できるよう、付随する作業の品質改善を検討しています。 品質の改善は目立って目に見えることが少ない、地道な作業です。 BIGLOBEの品質改善チーム BIGLOBEの開発組織には品質を管理する組織が2つあります。 品質をトップダウンで管理し、施策をスピーディーに実行する品質管理チームと、 ボトムアップで現場作業のヒヤリハットを発見し、障害を未然に防止する品質改善チームです。 今回は品質改善チームに注目しました。 品質改善チームのメインミッションのひとつは運用作業時の障害防止です。 各チームの運用作業に対して品質改善チームが第三者視点で点検、介入し、障害発生を未然に防ぐ活動をしています。 品質改善チームは社内開発チームから担当者を選出して活動を行っています。 各自の考えや背景を出し合い、共有することで品質に関する状況を社内横断的に把握することが できます。 品質改善チームメンバーが常日頃から品質の大切さを認識して作業を行っており、現状に 満足することなく、より良いBIGLOBEサービスの提供を目指しています。 品質改善チームの合宿 品質改善チームがいつもと趣向を変えて都内サテライトオフィスを利用して合宿を行いました。 合宿といっても泊まりがけで行うものではありません。 社屋から離れてまとまった時間をとって議論を行うものです。 今回は都内にあるサテライトオフィス「ZXY」（ジザイ）を利用しました。 BIGLOBEでは複数のサテライトオフィスを法人契約しており、その１つが「ZXY」（ジザイ）です。 会議をサテライトオフィスで行うこともあります。 なぜわざわざ外出して社内メンバーだけで会議を行うのでしょうか。 普段とは違う環境で新鮮な気持ちで議論することで、いつも以上に良い議論ができることを 期待しています。 また、普段の業務から離れて集中して議論を行うことができます。 こういった効果を実際に感じており、サテライトオフィスでの会議を実施しています。 議論 今回は「良い作業手順書とは何か」を議題に議論を行いました。 どのように議論を行っているのでしょうか。 まずは各自で考える時間です。 議論を行う際には、議題に対してまずは各自が考えて意見や回答を付箋に書き出す時間を設けます。 各自の意見や回答をしっかりと表現できるように各自考える時間を設けています。 各自付箋に考えや意見を記載した後はそれぞれの付箋を出し合っていきます。 付箋を順番にホワイトボードシートに出し合っていき、出てきた内容を列挙して他の人と似た意見があれば付箋を重ねていくという作業を行います。 似た意見を同じタイミングで出し合うことにより会議時間の短縮が可能ですし、同じことを考えていたという共感を示すことでより協調性を感じることができます。 出された意見を見て新しい意見を思いついたら都度付箋に書いて追加することも行っています。 新しいアイディアを奨励することで議論をより活発にしています。 一方、自分と違う意見が出てもその場ですぐに否定をしません。議論を盛り下げないためにすぐに否定することは行わず誰々さんとは違う意見ですが、と自分の発表の順番で付箋を出して意見を伝えています。 出てきた意見を整理して、何が問題なのか等を整理してより深く掘り下げていき、取り組んでみる事項や課題を見つけていきます。 課題を明らかにした後に対処方法の検討に結び付けていきます。 このようにBIGLOBEでは1人1人の意見を吸い上げて、チームが活発に議論できる風土があります。 BIGLOBEの議論風土 BIGLOBEではさまざまな議論が活発に行われています。 サテライトオフィスだけではなく、社内の会議スペースや業務チャットでも意見のやり取りが自由に行われています。 また、議論だけで終わるのではなく、まずはやってみよう、試してみようという風土があります。 様々なことを試してみるように、発言したことを積極的に取り入れるという風土もあります。 まとめ 本記事ではBIGLOBEの品質改善チームや議論風土を紹介しました。 BIGLOBEの品質を支える品質改善チームがあり、BIGLOBEのサービス維持や改善、サービス提供しています。 また、普段から活発なBIGLOBE議論風土があり、その風土を生かしながら一見地道に見える 品質改善の検討が活発に行われています。 会議場所も社屋のみにこだわらず、サテライトオフィスを積極的に利用して普段とは違う 新鮮な気持ちを引き出そうとしています。 議論が活発に行われるコツは下記と思いました。 各自が考える時間を設ける 新しい意見を思いついたら都度付箋に書いて追加する　 自分と違う意見が出てもすぐに否定をしない　 順番に意見を出す　 まずは意見を出しつくしてから、整理してより深く掘り下げる 写真ではわかりづらいですが、各自の意見を出す時間と議論する時間は特に盛り上がり、時間が足りないくらいでした。 安定したインターネット接続を提供できるように、BIGLOBEの議論風土を生かして活発に議論して、日々品質の改善を検討しています。

BIGLOBE鈴木(研)です。 無事に申請内容が受理されて、vEXPERT生活2年目に入ることが出来ました。 星が2つになりました。 vExpertのポータルサイトのDirectoryで「japan」で絞り込んでみると、71名が日本のメンバのようです（ワールドワイドで2000名弱）。 本来は、3/5のUserCON2020というイベントのレポートでもしようかと思ってたんですが、 新型コロナウイルスの影響で延期となったため、最近BIGLOBEでの作業でドタバタした技術ネタでも書きたいと思います。 ■突然VMのMACアドレスが変わってしまうことがあるのか？ 事象発生時の状況 通常、電源ON状態で仮想マシンのMACアドレスは変わることはないのですが、なぜか変わってしまった事象がありました。 事象の発端は「突然VMとの通信が出来なくなって、今もその状態が継続中なんだけど」でした。 初動調査 基盤側を調べたら、通信が出来なくなったタイミングでDRSのvMotionで対象VMが別ESXホストに移行されていて、どうもvMotionがトリガで発生した事象であることがおぼろげに見えてきました。 すぐに分かったのは、ポートグループのセキュリティ設定のMACアドレス変更を「拒否」に設定しているのに引っかかり、このVMのポートがブロックされたということです。 VMの設定を確認すると、MACアドレスは、上記とは違うものが設定されていることが分かり、このせいでポートブロックされたことはわかりました。 vCenterのイベント情報を確認すると、実際にVMのMACアドレスが変わっていることが確認できました。 Changed MAC address from 00:50:56:86:67:1a to 00:50:56:86:45:62 for adapter XXXXXXXX_3783 ただし、最初の画面のとおり、ランタイムMACアドレスが"00:50:56:86:67:1a"になっているので、ゲストOSで設定されているMACアドレスは"00:50:56:86:67:1a"のまま（変更前）であるようでした。 しかし、vMotionのタイミングより1か月以上も前だったので、関係無いようもに見えました。 前提 BIGLOBE環境の前提として、下記があります。 vSphereは6.0u3 ポートグループのセキュリティ設定は全て「拒否」 「プロミスキャスモード」を「拒否」することで、宛先にかかわらず全てのパケットを受信することができなくなり，他の送信者や受信者に気付かれずにデータを傍受することができなくなります 「MACアドレス変更」を「拒否」することで、外からVMが受信する通信について、VMに割り振ったMACアドレスと違うMACアドレスをゲストOSで成りすまして使ったら、ESXホストが通信をブロックします 「偽装転送」を「拒否」することで、VMから外に送信する通信について、VMに割り振ったMACアドレスと違うMACアドレスをゲストOSで成りすまして使ったら、ESXホストが通信をブロックします VMのMACアドレス採番は「自動」 抱いた疑問 なぜvMotionがトリガで、このVMは通信できなくなったのか？ なぜvMotion実施前までは、このVMは通信できていたのか？ 電源ON中のVMのMACアドレスが変わることがあるのか？ 調査継続 VMware社に問合せした結果、VMを電源ONの状態でポートグループ変更するとMACアドレスが変わる場合がある（必ずそうなるわけではない）、変更が反映されるのはVMの電源OFF/ONや再起動後であるとのことでした。 このVMの初期設定で、ポートグループを初期→正規のものに切り替えたのですが、その際VMの電源はONのまま実施していました。 ここで、VMのMACアドレスが 00:50:56:86:67:1a → 00:50:56:86:45:62 に変わりました。 MACアドレス変更「拒否」の設定にここで引っかかっても良さそうですが、通信は継続されたままでした。 しばらく経ってある時に、このVMがDRSによるvMotionで別ESXホストに移動したタイミングで、MACアドレスが変更になっていたことにvSphereが気づいて、通信をブロックし出した、ということのようです。 謎解き VMware社にいろいろ確認したところ、「下記の動きをしたのでは？」という結論になりました。 VMが電源ONのままvNICのMACが変わった場合は、 変更前からできていた通信が保持される仕様 とのことで、ポートグループのセキュリティポリシー（MACアドレス変更）には引っかからず、通信できていた vMotionで別ESXホストに移行されたため、仮想スイッチのポートが変更になり、その時点でセキュリティポリシーに違反していることをvSphereが検知し、ポートがブロックされた そんな仕様は想像もしてなかったです。 一連の動作の動きを整理するとこんな感じです。これで一連の動作の説明がついたのでスッキリしましたｗ VMのvNICが接続するポートグループを変更するような場合、vNICに割り振られるMACアドレスが変更になる場合があるようなので、ご注意ください。 特に、MACアドレスでライセンスされるようなソフトウェアを使用している場合は、固定MACにすることをお薦めします。 ※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。 補足 そのほかでMACアドレスが変更になる操作としては、仮想マシンのHWバージョンをアップグレードすることが該当するようです。 https://kb.vmware.com/s/article/1010675 ■お知らせ VMwareユーザ会（VMUG）に興味のある方は、 https://www.vmug.com/membership/membership-benefits から入会していただけると幸いです。 部会でお会いできるのを楽しみにしております。 以上です。

こんにちは BIGLOBE 梅津です。 2019年の12月2日〜6日まで開催された「AWS re:Invent 2019」に参加しました。 私は今回初めての参加でしたが、その際に気づいたことや来年参加する方に役立つ情報を書いていきたいと思います。 セッション予約 出発前の準備として一番比重が高いと思われるのは、現地でのセッション予約です。 セッション情報は開催の2カ月前に発表されます。 この時点では全てのセッションが公開されている訳ではないので、公開された後も逐次チェックが必要です。 セッション情報が発表された時点では予約を行うことが出来ないため、自分で受けたいセッションを探しながらメモを取って予約の準備をすることが大切です。 私的に優先度を高くチェックしたほうがいいセッションのカテゴリを以下に記載したいと思います。 アクティビティセッション GameDayやSecurity Jam ハンズオンセッション チョークトーク 座学セッション １．アクティビティセッション アクティビティセッションは、tatonkaチャレンジ（辛味チキン大食い大会）やboardgame night（ボードゲームで参加者と一緒に遊ぶ）など、当日参加者とコミュニケーションを取れるセッションです。 私の所感ですが、このセッションが一番最初に予約が埋まったと思います。 多くのセッションが用意されているので、予約開始前にチェックを行い、もし参加したいものがあれば、予約開始日に予約を行うことをオススメします。 以下の写真は辛味チキン大食い大会に挑む前の私です。結果は時差ボケが酷くて全然食べれませんでした・・・ ２．GameDayやSecurity Jam GameDayやSecurity Jamはハッカソンを実施するセッションです。 かなりの人気を誇っており、すぐに予約が埋まってしまうセッションになります。 もちろん海外の人と一緒に作業をすることになるので、その点不安が残ると思いますが、後日チャレンジしたいと思っていても予約が取れません。 そのため、予約開始時点で興味があればセッションを取っておくことをオススメします。 ３．ハンズオンセッション ハンズオンセッションは実際にAmazon Web Services（AWS）のサービスに触れることができるセッションです。 日本では触れることが少ないようなサービスもハンズオンセッションとして用意されているので、座学のセッションに参加するよりもハンズオンセッションに参加することをオススメします。座学セッションより絶対に面白いです。 ハンズオンセッションは座学のセッションと比べて座席数が少ないため、早めに満席となってしまいます。 そのため気になっているセッションがあったら初日に予約を取ることをオススメします。 ４．チョークトーク チョークトークは登壇者とセッション受講者がそのセッションのテーマに沿って、意見を言い合いながら進めるトークセッションです。 スライドを使って説明をするのではなくセッション参加者と話をしながら進めます。質問の内容や登壇者の話を理解しなければならないため、英語力が求められます。 ですが、通常のセッションでは聞けないような話が聞けたり、AWSのエンジニアと直接会話ができる貴重な機会なので、英語力に自信がある人は受講することをオススメします。 ５．座学セッション 最後にセッション数がもっとも多い座学セッションです。 座学セッションは色々なテーマが用意されています。AWSサービスについてのセッションや、各企業の事例セッション、AWSのノウハウ共有のセッションなど多種多様です。 他のセッションと比べてリピートセッションが多く、席数が多いため予約が比較的取りやすいので、上記で説明した他セッションで興味があるものがあったら座学セッションよりも優先して取るほうが良いと思います。 現地での過ごし方 現地に到着したらやるべきことがたくさんあります。 セッション受講以外で、現地で何をすると良いかということを中心に記載しようと思います。 レジスト（参加者登録）をすぐにしよう！ レジストと言われる参加者登録をするところからre:Inventは始まります。 今回のメイン会場であるヴェネチアンホテルのレジスト会場では記念品をもらうことができます。 今年はパーカーとオリジナルボトルでした。 このパーカーですが、総数自体は来場予定者数ありますがサイズごとに数が潤沢にあるわけではなく、早めに取りに行かないと「望んでいるサイズがない！」ということがあるようです。私が聞いた話だとre:Invent初日の夕方に取りに行ったらもうMサイズが品切れになってたそうです。 常にセッション情報は確認しよう！ keynoteでは毎回新サービスの発表が必ず実施されます。 新サービスのセッションについては、事前のセッションリストにはもちろん表示されていません。そのため、新サービスのセッションは現地で早い者勝ちの取り合いになります。 発表された新サービスのセッションはKeynoteの裏で続々追加されているので、見逃さないようにした方が良いです。 特にアイテムが貰えるセッション（私たちの時はキーボード）は大人気で一瞬で席が埋まります。 色々なアイテムをゲットしよう！ 参加者登録をすると参加記念品をゲットできますが、それ以外にも色々とアイテムをもらえる機会があります。 例えば、keynoteに早めに入場するとバウチャーチケットを貰えることがあり、記念品をゲットする権利を得られます。 また、re:Invent最終日の前日夜に行われるre:playでもTシャツの配布がされます。 後で取りに行こうとするとなくなってしまうそうなので、欲しければまずTシャツゲットに走ってください。 AWSの資格を持っていると貰えるグッズもあるので、資格所有者の方は是非ともゲットしてください。 また、コレクションアイテムとなるようなピンバッチも所々で配布されているようなので、SNSなどで情報を追って行くことをオススメします。 ラスベガス観光の予約はお早めに！ ラスベガスということですから、せっかくなので観光もしたいですよね！ シルク・ド・ソレイユのショーやアーティストのライブ、グランドキャニオンまでのツアーなど色々楽しむことができます。 re:Inventの参加者がラスベガスに集結するので、当日や現地で予約しようと思ってもショーやツアーは完売していることが多いです。 （私はどれもこれも行けませんでした・・・） 気になるツアーやイベントがあったら早めに予約をしてください！ 有名なラスベガスサインやアウトレットでのお買い物は、Uberやバスを利用すればすぐに行けるので、もしツアー等に参加できなくても楽しめるスポットはたくさんあります。 最後に re:Inventは最高の勉強の機会を得られる場所です。 それと共に世界中のエンジニアにも出会える貴重な場所です。 色々なことにチャレンジできますし、多くのことが出来る場所だと思います。 今回紹介した内容を参考に、re:Inventを楽しんでいただければ幸いです。 ※ Amazon Web Servicesは、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。

こんにちは、 なおしむ です。 私はシステム企画部でシステム全体のアーキテクトとレガシーシステムの改善開発をしています。 弊社ではドメイン駆動設計を使って開発をしています。 ドメイン駆動設計ではクリーンアーキテクチャのようなレイヤー構造でシステムを作ります。このレイヤー構造に従って設計・コーディングをするのですが、コードレビュー時に正しいレイヤー構造で作れているかをチェックするのが地味にめんどくさいです。。 現在のプロジェクトで、この地味で面倒なレイヤー構造のチェックをCheckstyleを使って自動化しているのでその方法を紹介します。 クリーンアーキテクチャのコードレビューはめんどくさい クリーンアーキテクチャとは、図のような円形のレイヤー構造のアーキテクチャです。 The Clean Architecture を参考に筆者が作成 クリーンアーキテクチャにはレイヤー構造の依存関係にルールがあります。 この依存関係のルールでは、外側から内側への依存は許可しますが、内側から外側への依存は禁止です。コードレビューではこのルールに違反してないかをチェックします。具体的には各クラスのimport文を見ながらひとつひとつ確認します。たとえば、ドメイン層のクラスのレビューであればimport文にデータソース層がないかをチェックします。 このレビューが地味にめんどくさくてツライ。。 これをCheckstyleを使って自動化することが今回の本題です。 ドメイン層からデータソース層に依存している例 Checkstyleとは Checkstyleはコードのコーディング規約違反をチェックするツールです。 本家サイト のoverviewを翻訳したものが下記です。 CheckstyleはプログラマーがJavaコードを書くための開発ツールです。コーディング標準に準拠するように支援してくれます。Javaコードをチェックする作業を自動化してくれ、コーディング標準を強制したいプロジェクトに有効です。 クリーンアーキテクチャのチェックもまさにコレ。 今回はCheckstyleを使ってimport文をチェックし、レイヤー構造の依存関係におけるルール違反を検知します。 Checkstyleの導入 checkstyle.xml配置 checkstyleディレクトリを作成しその中にファイルを作成します。 checkstyle/checkstyle.xml <? xml version = "1.0" ?> <! DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN" "http://www.puppycrawl.com/dtds/configuration_1_3.dtd" > <module name = "Checker" > <module name = "TreeWalker" > <module name = "ImportControl" > <!-- importチェックのファイルパスを指定する --> <property name = "file" value = "checkstyle/import-control.xml" /> </module> </module> </module> checkstyle/import-control.xml 最終的にココに設定を追加していきます。 <? xml version = "1.0" ?> <! DOCTYPE import-control SYSTEM "checkstyle/import_control_1_4.dtd" > <!-- チェック対象のパッケージ --> <import-control pkg = "jp.co.biglobe" > </import-control> checkstyle/import_control_1_4.dtd これをDLして配置してください。 import_control_1_4.dtd build.gradle 2行追加します。 buildscript { repositories { mavenCentral() } dependencies { classpath( "org.springframework.boot:spring-boot-gradle-plugin:2.0.5.RELEASE" ) } } apply plugin: ' java ' apply plugin: ' eclipse ' apply plugin: ' idea ' apply plugin: ' org.springframework.boot ' apply plugin: ' io.spring.dependency-management ' apply plugin: ' checkstyle ' // ★追加 checkstyle.configFile = file( ' checkstyle/checkstyle.xml ' ) // ★追加 ... この状態で ./gradlew build を実行して「許可されていないインポート」というエラーがたくさん出ればセットアップは完了です。 クリーンアーキテクチャの規約を設定 ここから先の設定は import-control.xml の import-control タグ内に記述します。 今回のプロジェクトがこんなパッケージ構成になっている想定で説明します。 + jp.co.biglobe.sample + api // API層: コントローラなど + datasource // データソース層: DBへのアクセスなど + service // サービス層 + domain // ドメイン層 使って良いパッケージを設定 まず最初にプロジェクト内で使って良いパッケージを指定します。 クリーンアーキテクチャの話ではないですが、これをしないと全てエラーになってしまうので。。この設定はプロジェクトによって違うので適宜設定してください。 <!-- 使って良いライブラリ --> <allow pkg = "jp.co.biglobe.sample" /> <allow pkg = "lombok" /> <allow pkg = "org.springframework" /> <allow pkg = "java" /> <allow pkg = "javax" /> <allow pkg = "org.mybatis" /> <allow pkg = "org.apache.ibatis" /> クリーンアーキテクチャの規約を設定 本丸です。 正規表現を使いながら設定します。 <!-- ドメイン層 --> <!-- API層/データソース層/サービス層への依存禁止 --> <subpackage name = "domain" > <disallow class = ".*\.api\..*" regex = "true" /> <disallow class = ".*\.datasource\..*" regex = "true" /> <disallow class = ".*\.service\..*" regex = "true" /> <disallow class = "org.springframework.stereotype.Service" /> <!-- domain層に@Serviceは禁止 --> </subpackage> <!-- サービス層 --> <!-- API層/データソース層への依存禁止 --> <subpackage name = "service" > <disallow class = ".*\.api\..*" regex = "true" /> <disallow class = ".*\.datasource\..*" regex = "true" /> </subpackage> ドメイン層では各層の依存に加えて @Service の利用も制限しています。 ドメインサービスとアプリケーションサービスを混同して使ってしまうことがあるので。 全体 import-control.xml 全体としてはこんな感じです。 <? xml version = "1.0" ?> <! DOCTYPE import-control SYSTEM "checkstyle/import_control_1_4.dtd" > <import-control pkg = "jp.co.biglobe.sample" > <!-- 使って良いライブラリ --> <allow pkg = "jp.co.biglobe.sample" /> <allow pkg = "lombok" /> <allow pkg = "org.springframework" /> <allow pkg = "java" /> <allow pkg = "javax" /> <allow pkg = "org.mybatis" /> <allow pkg = "org.apache.ibatis" /> <!-- ドメイン層 --> <subpackage name = "domain" > <disallow class = ".*\.api\..*" regex = "true" /> <disallow class = ".*\.datasource\..*" regex = "true" /> <disallow class = ".*\.service\..*" regex = "true" /> <disallow class = "org.springframework.stereotype.Service" /> <!-- domain層に@Serviceは禁止 --> </subpackage> <!-- サービス層 --> <subpackage name = "service" > <disallow class = ".*\.api\..*" regex = "true" /> <disallow class = ".*\.datasource\..*" regex = "true" /> </subpackage> </import-control> 以上設定完了！ 実行してみる 設定が終わったので ./gradlew build を実行してみます。 お！見事にドメイン層からデータソース層への依存を検知してくれました。 まとめ 今回はCheckstyleを使って、クリーンアーキテクチャのレイヤー構造に従っているかを自動検知する仕組みを作りました。 これで面倒なコードレビューから解放される〜。 それではまたー。

こんにちは、サービス開発部のこばやし(eri-twin)です。 BIGLOBEで働いて5年目のサーバサイドエンジニアです。 私は「やりたい仕事で楽しく成果を出す」をモットーに日々働いています。 そしてこの働き方を実現するために、会社の文化や制度にたくさんお世話になっています。 今回はそんな私が会社で関わっているさまざまな活動を通して、BIGLOBEのエンジニア文化を紹介したいと思います！ BIGLOBEでは、成長の機会がたくさんある！ 勉強できる環境がある！ BIGLOBEは、エンジニアの勉強を奨励してくれる会社です。 ↑このスペースの本棚いっぱいに技術書が並んでいます！ 技術書の本棚があり、ここの本は会社のお金で購入してもらったものです。 購入タイトルの申請も簡単で、技術書の購入には上司も非常に理解があるため承認もスムーズです。 業務時間内にも定時後にも、ここに並ぶ技術書を眺めたり読んでいる人をよく見かけます。 興味があったらすぐ手に取れる場所に本がたくさんあるのはとてもありがたい環境です。 社内では多くの人が本を読む文化を持っているので、社内勉強会として読書会が開催されることも多いです。 自分が読みたい本を読破するために読書会を開催する、ということもあります！　内容が難しかったり分厚くて心がくじけそうになる本は、みんなと一緒に読むことで理解を深め、読み切っています。 社外勉強会の開催・登壇の機会がある！ BIGLOBEではドメイン駆動設計(DDD)を約7年間継続してきたという背景があり、DDDに関する勉強会を積極的に開催しています。 勉強会には、ベテランだけでなく若手にも、前に出る機会がたくさんあります。 実際に入社4年目のとき、以下の勉強会で発表とパネルディスカッションの登壇をさせていただきました。 レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 - connpass また、こちらの勉強会でもBIGLOBE主催のハンズオンにドライバーとして参加しています。 レガシーをぶっつぶせ。現場でDDD！2nd はじめての登壇はとても緊張したので、社内でサポートをしてもらいながら登壇するチャンスをもらえたことは本当に心強い機会でした。 私はシステムの設計が一番楽しい仕事で、非常に面白い領域だと思っています。 組織でDDDという柱を持って設計に取り組めること、それをアウトプットして仲間からフィードバックをもらえること、これもBIGLOBEで働く楽しさのひとつだと感じています。 BIGLOBEでは、自分のやりたいことができる！ LT（ライトニングトーク）大会がある！ 数カ月に1回程度、仕事の進め方・技術ネタなどの話題でLTをする有志のイベントを開催しています。 社内には様々な得意分野を持つエンジニアがいるため、自分の知らない領域のエンジニアとも交流できます。 時には企画担当などエンジニア以外の人にも発表してもらったり、新年度には自己紹介をテーマにした回を開催するなど、いろんな取り組みをしています！ 最近で特に面白かったイベントは、「LTの準備をする時間がない！」という人にもやさしい、その場でLTを作り完成した人から発表する形式の「LTハッカソン」です。 前回は与えられたテーマ「エンジニアリングと○○とわたし」に沿ってLTを即興で作成・発表しました。 技術書典に参加できる！ 技術に関する同人誌を頒布することができる「技術書典」に、BIGLOBEは2019年から参加しています。 これまでに2冊の技術同人誌を発行しました。 また、次回の 技術書典8 (2020/2/29-3/1開催) にも参加 します！ （技術書典の参加に関しては、別途お知らせの記事を書く予定です。新刊を出す予定なのでぜひお立ち寄りください！） 業務時間での執筆活動OK、印刷費も会社で負担、イベントの当日も休日出勤扱いになります。技術書典に関連する活動はすべて業務として取り扱ってもらえるという、大変恵まれた環境で活動させていただいています。 その一方で、これまで学んできた内容をアウトプットすることで、自分のスキルアップや業界への貢献にもつながっていると感じています。 会社で同人誌を書いて褒められる環境、本当にありがたいです！ BIGLOBEでは、楽しく働ける！ 5年目の社員の視点から見たBIGLOBEという会社は、若手がやりたいことを実行できる会社です。 やりたいと声を上げたら任せてもらえる、風通しの良さがあります。 業務時間中に勉強会ができる、平日昼間の展示会や社外イベント参加は業務扱いで参加できる、会社で働きながらスキルアップができる環境があります。 任せてくれる上司と、仲間になってくれる同僚がいます。 これらを作り上げてきたのは、BIGLOBEで働いている一人ひとりです。良い人が良い文化を作ってきた会社なんだな、と感じています。 おわりに BIGLOBE楽しそう、合うかも、と思えた方へ。一緒に働いてみませんか？ ということで、最後にお知らせです。 BIGLOBEでは自社サービスを盛り上げていきたいエンジニアを大募集しています。 興味のある方はぜひカジュアル面談にいらしてください。 hrmos.co

BIGLOBEの西です。 システム企画部 SO基盤開発グループでグループリーダーをしています。 今年度より、昇格してグループリーダーとなったのですが、 コードを書く時間が減ってしまい寂しい日々を送っています。 先月、ついに公開された「BIGLOBE Style」。 多様な働き方やイノベーションを生み出すヒントをピックアップするメディアとして立ち上がりました。 BIGLOBEとしても多様な働き方に挑まない訳にはいけない(という大義名分の)一心で、 秋ごろに新しい働き方のトライアルとして、尾道(広島)に行ってきたので、 今回は、その共有(自慢)をします。 瀬戸田のダイヤモンドヘッド(正式な名称はサンセットビーチ)にて なぜ尾道で？ BIGLOBEの本社は東京で、エンジニアはみんな東京勤務です。 もちろん、尾道に支店はありません。 元々、自分の所属する部では、働き方改革の一貫としてリモートワークの検証をミッションとしていました。 とくに開発業務では、安全にイントラネットへ接続する手段と、 仕事の利便性をどう両立させるべきか？を検証・実験する必要がありました。 そんな折、 元々、自分が広島で働いていた縁で、 「尾道でリモートワークの検証をしてくれる人を探している」 という話を(飲み会で)いただき、あれよあれよという間に実現しました。 拠点にさせていただいたシェアオフィスのONOMICHI SHAREさんには、 私の名前がタイトルに入ったブログまで書いて歓迎していただきました。 onomichi-share.com ワーケーションとは？ ワーク（働く）＋ バケーションを合わせた造語で、 リゾート地でバケーションをしながら働いて、且つ、企業には仕事として認めてもらうという、 理想の働き方です。 リモートワーク も ワーケーション も場所が違うだけ。 むしろ、自宅より環境が整っていない分、環境は過酷なのでリモートワークの検証にはピッタリです！！ と会社と上司を言いくるめて1週間のワーケーションへ出かけました。 今回の検証内容 装備品 装備品 使い方 MacBook Pro 主に最近あまり書いてないコードを書くために使います シンクライアント端末 イントラへ接続するための端末 イントラでしか見れないドキュメントを見るために使います 社用携帯 こいつも社内の情報が見られます 移動中にイントラ接続したい場合は社用携帯が頼りです 検証内容 リモートワークで以下の業務が問題なく遂行できるかを検証します プロダクト開発 (コードを書く) 朝会/夕会 (情報共有のための会議) レビュー (ドキュメントを見ながらの会議) 出荷判定会議 (情報を聞いて出荷の判断をする会議) 1 on 1 (部下の悩みを聞く) 発注業務 (2Q末だったので3Qの発注しなくては・・・) 読書会 検証前日(0日目) 東京から4時間半。ようやく尾道へ到着です。 尾道駅前です 尾道は瀬戸内の街で、穏やかな海と泳いで渡れるほど目の前にある島々が特徴的な地域です。 夕暮れ時の瀬戸内 検証1日目 まずは、今回、拠点として使わせてもらった ONOMICHI SHAREさん へ移動します。 広いスペースとオシャレな内装と眼前の海！最高の環境だ。 リモート接続に少し手こずるも環境構築done！！ 完璧なワーケーション環境がここに完成 検証内容 朝会/夕会 レビュー(会議) × 3個 発注業務 この日は、レビュー以外は海の見える密室で、ほぼ発注業務をしてました。 いつもなら、ストレスのたまる業務もこの環境下ならストレスフリー！！ いつもの2倍の速度で発注した気がします(気持ちだけ) 検証2日目 この日はスケジュールが無駄にタイトで、 島に移動してサイクリングという仕事に全く関係ない予定もこなしつつの業務になります。 2日目のスケジュール。仕事が少ないｗ 午前はミーティングを2本こなして、いざ 生口島 へ 島内は自転車で移動です。 紹介してもらったカフェで場所を借りて念願のコーディングタイム。 但し、チームから与えられたのは、DDD(ドメイン駆動設計)という設計手法を使って、ある部品をPerlで作ってくるというミッション(他のissueがよかったな・・・)。 でも、この環境下であれば何を作っても楽しい♪ 島のカフェの縁側を借りてコーディング そして、ここから夕会をするためだけに自転車でビーチへ移動。 (なぜ、移動が必要なのかは問題ではないのです。ビーチがある。それだけで理由は十分) ビーチへgo! 人気のない場所を探して夕会の準備中 検証内容 プロダクト開発 (コードを書く) 朝会/夕会 レビュー(会議) この日は、午前はミーティング形式のレビュー、午後からはコーディング中心です。 島に渡るとビーチなどはセキュアなネット環境がない(フリーWiFiだけの)場所もありましたが、 その場合は、会社携帯でテザリングしてネットワークを確保しました。 おまけ 夜はなぜか瀬戸田の未来を考える会に参加。 カフェ経営者、れもん農家、シェアオフィスのマスター、某SIerの観光大使、自分 という顔ぶれで生口島の未来について語り合いました。 鍋とレモンサワーをたらふくごちそうになったので、この場を借りてお礼をさせて下さい。 ありがとうございました。おいしかったです。 瀬戸田の未来を考える会 検証3日目 朝にフェリーで生口島から尾道へ帰還。 ただ、朝会が始まるためフェリー乗り場で、そのまま朝会へ突入です。 我々のチームでは、朝会ではみんなでラジオ体操をするルールです。 当然、リモート先でもそのルールは有効です(周りの視線が痛い)。 フェリー乗り場でラジオ体操中 この日は、リモートで読書会を開催。 この読書会は先に決められた章を読んできて感想を付箋に出して共有し合うスタイルです。 対面ではできないので、Googleスライドを使って擬似的に付箋を出し合ってみました。 付箋が残るし、誰が何を書いたか分かるし、意外と良い方法で、 以降、対面でやる時もGoogleスライドで付箋出し合う方式になりました(成果だ！) リモート読書会 検証内容 朝会/夕会 (朝会はフェリー乗り場) 出荷判定会議 発注業務 読書会 検証4日目 この日は午前中は部下と1 on 1です。 KPT形式で、Googleスライドで付箋を出してもらいながら実施しました。 (「上司がワーケーションとか言って、どっか出かけていった」というProblemは却下しましたｗ) 1 on 1もリモートで 無事に発注も全て終わり休憩中 全ての検証も終わり記念撮影。 名残惜しいですが、このワーケーションも終わりです。 (この週は月曜が祝日のため、4日間で終わりです) お世話になりました。 総括 業務視点 出来ない業務はありませんでした。 コーディング中(MacBook Pro)はインターネットにしかアクセス出来ないため、 イントラの資料をシンクライアント端末で参照しなければならず効率が悪かったです。 会議はリモートでも特に支障はありませんでした。 東京のオフィス側がうるさくて発言が聞き取れない事がありましたが、 メンバーも含めて全員リモートで働いてしまえば、逆に解決しそう。 リモートだと直接、声をかけられないため作業を強制的に中断されないのは良かったです。 チャットであればメッセージが届いても自分のタイミングで返信できますが、 直接、話かけられると作業中でも強制的に手を止めないといけないです。 集中していればいるほど、一度、止められると同じ集中力に戻るまで時間かかります。 リモートで働いていると、時間のコントロールをしやすいのはメリットだと感じました。 情報漏洩への注意は必要。 オープンな環境が多いので業務情報を扱う場合、画面や音声から情報漏洩しないように、 会議室のような密室を借りて業務をしてました。 今回は、ONOMICHI SHAREさんの全面的な協力があったため、この課題も無事にクリアできました。 メンタルの話 メンタルにはとても良い環境でした。 発注業務など苦手なお仕事でもストレスをほぼ感じることなくできました。 仕事内容は変わっていないので、ひとえに環境のおかげかと。 リモートだと会議の時間に正確になりました。 日頃だと忘れていても周りが声がけしてくれますが、 リモートだと自分で自分の時間を管理しないといけない分、 時間を意識して仕事できました。 (日頃が不真面目なだけではないかと反省) まとめ 今回は検証という建前でのワーケーションでしたが最高の働き方でした。 自宅は安心感はありますが、ずっと同じ空間で仕事をするという点では会社で働いているのと変わらないと思います。 リモートで働く本当のメリットは、気持ち良く働ける場所を自分で選べることだと実感しました。 私個人としては、働く場所、時間ではなくて、成果で評価されるような働き方が本来あるべきだと思います。 BIGLOBEとしても、会社として新しい働き方やイノベーションを探ると表明していますし、 こういった働き方を業界の中でリードしていく立場を目指して、 ぜひ、正式にワーケーション制度の導入をお願いします(チラリ) 最後に、今回のバケーション(言い切った)でお世話になったみなさま。 ありがとうございました。 近々、また、お伺いできるようにがんばります。 以下、社内からのマサカリ対策。 今回は、検証のために会社より正式に許可をもらって実施しました。 グループリーダーは裁量労働制ですので、勤務時間はその裁量で決めて働きました。 日頃は品川でちゃんと真面目に仕事してます。 尾道でも仕事しました。 以上です。 BIGLOBEでは自社サービスを盛り上げていきたいエンジニアを大募集しています。 興味のある方はぜひカジュアル面談にいらしてください。 hrmos.co style.biglobe.co.jp

こんにちは。BIGLOBE Style編集部の吉田、森山です。 2019年7月24日、神戸で行われたJANOG44ハッカソンにて、BIGLOBEと株式会社ZTVの合同チーム「自動棚卸しチーム」が優勝！ そこで今回は、そのBIGLOBEのメンバーに優勝までの経緯や受賞のコツについてインタビューしました。 チームメンバー紹介 滝口 敏行 ：中途入社でBIGLOBEへ。ネットワークインフラ運用の自動化等を担当。 前野 洋史 ：入社3年目。バックボーンネットワークを担当。 及川 優星 ：入社2年目。MVNO-NW基盤の開発と運用を担当。 船山 歩 　：入社1年目。ネットワークインフラ運用の自動化等を担当。 君塚 遼 　：入社1年目。MVNO新サービス開発とMVNO運用の効率化を担当。 左から及川さん、君塚さん、前野さん、船山さん、滝口さん（チームリーダー） JANOGハッカソンとは？ JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。 （出展：JApan Network Operators' Group　Jeneral Infomation） JANOGハッカソンはJANOG Meeting期間中に実施されるメインイベントの１つ。 「運用改善／自動化」や「最新技術の評価」などをテーマとして、各社エンジニアがチームを結成し、ツールやシステムを半日～１日かけて構築。その成果を発表して競い合うコンテストです。 BIGLOBEが参加した目的 ・開発力向上（運用改善／自動化を進めるきっかけ作り） ・BIGLOBEの技術力を社外にアピールしたい！ ・社外問わずエンジニア仲間を作りたい！ ―――まずは、優勝おめでとうございます！ 滝口 ：ありがとうございます。実は、私と前野さんは前回のJANOG43にも参加していて、その時悔しい思いをしたので反省点を踏まえて今回挑みました。 前野 ：前回はグダグダで反省しまくりました。なので、「次は優勝する！」というモチベーションもあって、今回優勝できました。 優勝を心から喜んでいる前野さん ―――今回、名だたる大手企業も参加する中、優勝できたポイントを教えてください。 前野 ：「ネットワーク機器の資産を自動で棚卸する」というテーマ設定がまず、大きなポイントになったと思います。 滝口 ：インフラを持つ企業ならどの企業でも苦労する問題、辛いところや共感できるところに焦点を当てました。シンプルで伝わりやすい、簡単に作れそうなども念頭にありましたね。 及川 ：そうですね、それに加えて新人社員の教育も兼ねていたところも評価されたと思います。参加チームの中で私たちのチームは最年少の平均年齢でしたし、若手を育てていこう！という業界の空気に合っていたのかなって。 Ansible の nmap inventory plugin を 本来の用途とは違う棚卸に応用できた点も評価されていたようでした！ ―――参加チームの中では最年少のチームということですが、BIGLOBEのメンバーはどうやって集まったのですか？ 船山 ：私は新入社員なんですが、配属直後に教育コーチの滝口さんに「出ないか？」と誘われて。「他に若手もでるんだったら行きたいな…」と思い、同期の君塚さんに声をかけてみたんです。　　　 君塚 ：簡単なハッカソンは参加したことがあったので、面白そうだなと思い参加しました。 滝口 ：及川さんは君塚さんの教育コーチということもあって誘いました。快く「やりましょう！」と言ってくれたよね（笑） 及川 ：業務が多忙だったこともあって上司には渋られましたけど。でも優勝して帰ってきたら「よくやった！」と手のひら返されました（笑） 渋られエピソードをユーモアたっぷりに語る及川さん ―――準備期間はどのくらいかかりましたか？ 滝口 ：テーマを決めてからは１ヵ月。事前準備は辛かったですね。使うツールを統一して、まずはAnsible、PythonやJupyterをみんなに覚えてもらうところから始めました。習うより慣れろで実際手を動かしてもらって。結果、同じコードや問題を共有できました。 及川 ：ざっくり事前準備はみんなでやりつつ、当日環境で動く部分を担当する人・事前準備していた部分を組み立てる人と役割を分担していましたね。 ―――実際、当日はどのように進行したのでしょうか。 滝口 ：当日の環境を調べて、把握して、作りたいものを考えるところからはじめました。開発だけじゃなく発表資料の作成もあったので、本当はやりたいと思っていたものを全部やりたいところでしたが、「ここは捨てよう」といった感じでコントロールしながら進めました。当日の分担も前野さんに途中でスイッチしてもらうなどして全体を見ながら行っていましたね。 船山 ：万が一のために事前に作ったデータを持ち込んでいました。動かなかった時に本当はこうなりますと伝えるために。 及川 ：当日の環境次第でどうなるかと思っていたけど、開発環境もそろい実際に動きましたね。 滝口 ：やはり「カタチ」を見せたいので、及川さんに頑張ってもらいました。 今回のハッカソンでリーダーを務めた滝口さん ―――新入社員の君塚さん、船山さん、苦労した点を教えてください。 君塚 ：まず、自動棚卸って何をするの？と理解するところから苦労しました。Pythonは勉強していたので分かると思っていたんですが、実際やってみたら分からないことが多くて。 教えてもらいながらやりました。 船山 ：同じく、事前に使うツールを勉強するのが大変でした。 ハッカソンでの苦労を思い出しなんともいえない表情の君塚さん(笑) ―――ハッカソンに参加したことで、得られたものをそれぞれ教えてください。 及川 ：普段の業務では、開発要件を決めて、、、などの流れがありますが、ハッカソンでは何にどれだけ時間をかけられるかがタイトに決まってきます。どこまでの品質で何を優先するかなど、プロジェクトと変わらないものをギュッと短期間で体験できたのがよかったです。それに、ハッカソンはいわゆる上流から下流まで関われるので、管理者の立場になった時も良い経験になるんだろうなと思いました。 船山 ：良かったのはモチベーションの部分。当日何もできなかったからこそ、「もっと勉強しなきゃ！」と強く思いました。実際、資格を取得したり、LPICの勉強をしています。それに、コーチの滝口さんとも距離が近くなりました。前までは分からないことを遠慮しながら聞いていましたが、「分かんない！」って素直に言ったほうが滝口さんにとってもいいのかなと（笑） 及川 ：こういう経験をすると、業務で何か行き詰った時に相談しやすくなる関係もできるよね。 滝口 ：極限状態でもやっていけるという力もつくかも（笑） 君塚 ：当初は自動化していくというイメージがなかったんですが、こういうツールはこう利用して繋がっていくんだということが分かりました。今の業務に活かされています。 前野 ：前回のこともあったので、今回は「優勝する！」と目標を決めて普段の時間の中で時間を作れたのが良かったです。時間を作ることには苦労もしましたが。あとは他社との交流によって、技術獲得の意欲があがりました。 滝口 ：みんなでテーマを決めて、システムアーキテクチャは自分で考えたのですが、その考えたものが社外の環境で認められた、評価を得られたという点で自信を持てました。新人や当日JOINした社外の方ともコミュニケーションをとりながら一緒にできたのも良かったです。 ハッカソンからモチベーションが上がり、 「AWSソリューションアーキテクト-アソシエイト」の資格を取得したという船山さん ―――エンジニアにとってBIGLOBEのいいところって？ 滝口 ：下流、運用工程もやっている多様性があるのがいいところかな。 及川 ：伸ばしたい分野に関して障害がないところ。ハッカソンもBIGLOBEの名前を出して参加できるし、上司にもなんでも言える風通しの良さがあります。まぁ、自分はもともとなんでも言えちゃう方だけど（笑）技術力のある人が多いので、まだそこまでの力がない人が声をあげても汲んでくれるし若手の意見に対して「そういう視点もあるんだ」とキャリアが違っても溝を埋めてくれるところもありますね。 ―――若手が多くお世辞にも最強のメンバーとは言えないと思いますが、それでも優勝できた秘訣を３つ挙げてください。 全員 ：準備、開発環境をそろえたこと。目標とするゴール、完成イメージを共有できていたこと。それらに対するモチベーションと、みんなで言い合えるコミュニケーション。これらは若手が集まったからこそなのかも。 滝口 ：新入社員とここまでコミットできたのはスゴイ！とかなり反響があったんですよ。 ―――そうですね、新入社員が大活躍されましたね！ 　　　さて、2020年1月22日からJANOG45が開催されますが、参加されるのでしょうか。 滝口 ：はい、JANOG45ハッカソンでは及川さん、君塚さん、前野さんが参加します。私は後方支援というかたちで応援したいと思ってます。 及川 ：JANOG44ではバックエンドに携わっている面々でしたが、次回は自部門に限らず部をまたいでフロントエンドを含め６－７名で参加します。そうする事で前回より面白いことができるんじゃないかと。今まで２連覇したチームはないので、頑張りたいですね！ ≫JANOG45ミーティングの詳細は こちら 最後までお読みいただき、ありがとうございました！

こんにちは。BIGLOBE Style編集部の中田です。 働き方改革が謳われる昨今、副業の解禁も話題となっています。そして、 BIGLOBEでは副業が制度として認められています 。 今回は、実際にBIGLOBE社員でありながら副業に取り組んでいる梶田朋己にインタビューしました。実際に副業をしている社会人として、副業の本音をたっぷり聞くことができました。 ―――梶田さんは元々どこの部門にいましたか？ NECの、ミドルウェア事業部という部署にいました。そこから10年前くらいに人材公募（人員募集をしている部門に面談により部署異動できる制度）で、当時NECの傘下にあったBIGLOBEに移ってきたんです。 ―――どうしてBIGLOBEに異動希望を出したのですか？ 元々、ネットワーク関係の仕事がしたかったんです。ちょうど良いタイミングだから、異動できるのなら（人材公募制度の面接を）受けてみようと思いました。 ―――ちょうど良いタイミングというのは？ 入社10年目で、そろそろ自分たちで内製開発に手を出したいと考えていました。当時、 BIGLOBEでは内製開発に取り組みはじめていました 。その意味で、ちょうど良いタイミングだったので、話が合って異動しました。 ―― ―NECからBIGLOBEに異動して、印象はどうでしたか？ BIGLOBEは、かなり自由 だなと思いました。通常は、このサイトに行ったらプロキシのフィルタに引っかかってダメとか、アクセス制限がありますが、そういうのが特にないことにびっくりしました（笑）また、以前はお客さんの顔が見えなかったんですけど、 BIGLOBEでは直接お客さんからの声が入ってくるので、そういうことがとても新鮮 に感じました 。 ―――BIGLOBEに来てからはどんな仕事をしているんですか？ 自社サービスの開発や設計をしていますね。最初の頃は画面の開発とか新規案件の立ち上げをやっていました。内製も始まったばかりで、いきなり大きいところじゃなくて小さいところからまずやっていこうという形で進めました。ある程度できるというのがわかったところで、今は基盤系の設計をやっています。 ―――さて、今回のテーマに話を移しますが、副業は何をしているんですか？ 主に開発ですね。BIGLOBEのOBが立ち上げた、北海道にある農業系の情報設計をしている会社なんですけど、そこのお手伝いをしています。今、BIGLOBEではインフラ寄りの仕事をやっていますが、副業でもAWSを使った設計や、それに絡むアプリケーションの開発などをやっています。 ―――最初、副業を始める時、不安はなかったですか？ そうですね。そもそもどういうふうに副業をするのかわからないですし、最初は不安でした。（副業先は）相当能力の高い人が集まってやっている会社なので、自分のスキルは本当に通用するのかなあ、というところはありました。結果、通用することがわかって、これまで培ってきた 自分の能力の現在地を知ることができた と思います。 ―――副業をすることによって、学びはありますか？ ありますね。たとえば、BIGLOBEでやっているAWSの移行などであれば、どうしても古いシステムをちゃんと持っていくことが中心になるので、まだ枯れていない、新しい技術をおいそれとは使えないシーンがあります。しかし、副業では、本当にイチから作っているような案件が多く、新しい技術を使う場になっていて、そういうところが面白いですね。「そう考えるのか」みたいな発見があります。「あ、これってこう使ったらいいんだね」みたいな。そういった刺激を受けています。 ―――副業の学びを本業にフィードバ ックできそうですか？ そうですね。 BIGLOBEとしても現在AWS化を進めており、社内でも活発に勉強会が開催されています 。そういった場面で、副業で得た知識や体験をどんどんBIGLOBEに展開していけたらいいなと思います。 ―――BIGLOBEに「副業します」と申請する時、心理的な抵抗はありました？ そうですね・・・。 若干はありました（笑） ―――副業を始める時、BIGLOBEの周囲の人たちからどういうことを言われましたか？ あ、するの？みたいな。けっこうあっさりと（笑）すでに副業をしている人が自分の周りでは多かったの で。あと、 外部からそういう経験や知見を持って帰ってきて欲しいとか、副業からどんどんノウハウを吸収して社内に広げて欲しいっていう人ばかり でした。（役職が）上の方の人も含めてみんなそんな感じの人なんで。 まあ、副業ばっかりやってて、本業に全然手が回らなかったら誰かが何かを言うと思いますけど（笑）でも、そういう態度じゃなければ、全然OKな雰囲気です。 ―――副業もやると時間を持っていかれるような印象があるのですが、ワークライフバランス的な観点ではどうですか？ ある程度、自分の中で時間を決めて「今日ここからは時間を副業に使おう」というのを決めて集中してやっています。今のところは問題なく回っている感じですね。 ―――「副業」って人にお勧めできますか？ すごくオススメしたい な、と思います。やっぱり会社の中だけだと得られるものは限られているので、会社の外に出て、仕事のできる人や全く違う考えを持っている人と話したり、一緒に仕事をすることで得られる刺激は大切です。それに、ちゃんとした本業があれば、気楽に副業できるのを正直感じています（笑）自分にとって、副業はメリットが大きいですね。 梶田 朋己 ビッグローブ株式会社 基盤本部 システム企画部 システム企画グループ BIGLOBEではドメイン駆動開発を駆使して自社サービスを盛り上げていきたいエンジニアを大募集しています。 興味のある方はぜひカジュアル面談にいらしてください。 hrmos.co

はじめに 基盤本部（開発部門）の小野田です。 私自身、BIGLOBE に 2019 年 7 月に転職したばかりで、ドメイン駆動設計（DDD）の実践歴は浅いのですが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD！2nd のドライバー役をする機会を頂くなど、DDD を広める活動にも少し関わっています。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で本記事を書きました。 なお、この記事の内容やプログラムは、教育用に作成した架空のもので実在のサービスや団体などとは一切関係ありません。 TL;DR（最初に結論） DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングとオブジェクト指向プログラミング（OOP）の理解があれば誰でもできます。 難しいのは DDD 自体ではなくて、モデリングまたは OOP です。特に「良いモデル」を得ることは非常に難しいです。 なので「DDD ムズイ」と感じる人はモデリングと OOP の勉強をすると、DDD ができるようになるかもしれません。 サンプル問題 現場で DDD！2nd の増田氏のハンズオンで題材になった 鉄道料金の計算問題 をサンプル問題として取り上げます。 実業務を扱った問題のためやや複雑で、注意深く設計しないとコードが複雑になってしまいます。 料金計算について 仕様に明記されていない箇所は、以下のルールであるものとして実装しました。 往復割引のほか団体割引でも 10 円未満の端数は切り捨てる仕様としました。 団体割引で 31 人以上の団体も 8 人以上の団体が受ける割引を受ける仕様としました。また大人と子供が混在している場合は、大人を優先して無料にします。 回答 Kotlin でのサンプル問題の回答を GitHub に公開しました。 ただし画面は用意していないので bootRun した後 curl コマンドを実行する必要があります。 curl コマンドのサンプル curl -D - -H "Content-type: application/json" -X GET -d '{"destination":"shinosaka", "trainType":"nozomi", "seatType":"reserved", "adults":2, "children":3, "departureDate":"2020-09-04", "tripType":"round-trip"}' localhost:8080/jr-pricing/apply モデリング まずは鉄道料金を計算する上で必要な情報を洗い出しましょう。例えば「料金」「運賃」「特急料金」「乗車人数」などがあると思います。 一方「申込者」や「申込経路（Web からなのか窓口からなのかなど）」は鉄道の業務には必要な情報だと思いますが、料金計算の業務には不要な情報です。 こんな感じで情報を拾い上げ、情報間の関係を整理すると以下のようなドメインモデルができあがります。 ドメインモデル パッケージごとに責務や設計意図などを説明します。 price 料金を計算するクラス群を集めたパッケージです。 fare 運賃を計算するクラス群を集めたパッケージです。 super_express_surcharge 特急料金を計算するクラス群を集めたパッケージです。先ほど載せたドメインモデルをもう少し詳細化すると以下のようなモデルになります。 特急料金のドメインモデル 列車区分（のぞみ | ひかり）と座席区分（自由 | 指定）の組み合わせごとに特急料金計算サービスを用意し、あとは料金計算サービスの calculate を呼び出すと目的地（新大阪 | 姫路）までの特急料金が返る仕組みです。デザインパターンを知っている人には factory パターンを使ったと言えば伝わると思います。 実装を見るまではイメージが湧かない人もいるかもしれませんが、特急料金を計算するサービスを 1 つ用意して、そいつに列車区分と座席区分と目的地に応じて特急料金を計算させる構成にすると、SuperExpressSurchargeCalculationService が if 文まみれでごちゃごちゃしちゃうので、このような構成にしました。 Evans 氏も以下のようにオブジェクトの組み立て操作自体 1 つの責務として設計すべき（時もある）と言っています。 オブジェクトの生成は、それ自体が主要な操作になり得るが、複雑な組み立て操作は、生成されるオブジェクトの責務には合わない。そういう責務を組み合わせてしまうと、理解しにくく不格好な設計が作り出されるかもしれない。 (エリック・エヴァンスのドメイン駆動設計より） ちなみに Season の置き場所には悩みましたが、私の中で「季節変動」と「割引」は違う概念であり、Season の利用者は SuperExpressSurcharge のみであることから本パッケージに置きました。 discount 割引に関するクラス群を集めたパッケージです。 団体を 8 人以上 30 人以下の少人数グループ 31 人以上の大人数グループ の 2 つにグルーピングしました。理由は前者は「割引率」、後者は「割り引く人数」というように、同じ割引でも扱う対象が少し違うためです。 モデリングのアウトプット Web にある多くの記事がドメインモデルのみを提示して実装に移りますが、モデリングに不慣れな人はモデルからコードにつなげることができないと思います。 その場合は詳細なクラス図、シーケンス図など、各自の理解度に応じて実装に必要な追加情報をアウトプットしましょう。別にモデリングのアウトプットは UML に限定されず、例えば料金計算がよくわからないのであれば以下のような表を作成しても構いません。 目的地 列車 座席 大人 子供 出発日 旅行区分 運賃 特急料金 料金 新大阪 のぞみ 自由 1 0 2019-09-04 片道 8910 5280 14190 新大阪 のぞみ 自由 1 0 2019-09-04 片道 - - 28380 ちなみに私のチームもドメインモデルのみということが多いですが、メンバの理解度に応じて適宜詳細なクラス図やシーケンス図を作成することもあります。 実装 ここまでくると実装を開始できます。 今回は DDD では有名なレイヤー化アーキテクチャを採用します。ただし今回用意するのは presentation 層、application 層、domain 層の 3 層のみです。 domain 層の実装 domain 層の主要なクラスの実装を見ながら、オブジェクト指向プログラミングの考え方を紹介します。 料金計算サービス まずは主要クラスである料金計算サービスの実装を見ましょう。 PriceCalculationService 少し長いですが、実はこのクラス自身は大したことはしていません。入力値をコンストラクタで受け取り、割引やら運賃やら特急料金を計算する責務を持ったクラスを呼び出すだけです。オブジェクト指向ではこれを 委譲 と呼びます。 専門用語を出すと難しく感じるかもしれませんが、多くの人が普段やっている仕事の依頼と同じです。依頼者がある仕事をする責務を他の人に委ねるのと同じく、料金計算サービスは割引やら運賃やら特急料金の計算を専任の計算サービスに委ねています。 特急料金計算サービス 続いて特急料金計算サービスの実装を見ましょう。例えば「のぞみ自由席」の特急料金を計算するサービスの実装は以下のようになっています。単に目的地と特急料金の対応関係（ map ）を持つだけの小さなクラスです。 SuperExpressSurchargeCalculationServiceForNozomiFreeSeat ちなみにこれら特急料金計算サービスを生成する factory の実装は以下の通りです。 SuperExpressSurchargeCalculationServiceFactory モデリングの時はイメージが湧かなかったかもしれませんが、もしこれをクラス分けせず 1 つの特急料金計算サービスに実装していたら if 文まみれの辛いコードになっていました。個人的には if 文が 1 つのクラス/メソッドに集中しないように設計/実装するよう心がけています。 割引 続いて割引に移りましょう。割引については「往復割引を適用するクラス」「団体割引を適用するクラス」の 2 つに分割しました。両者に共通するのは tell-don’t-ask の原則 に従っていることです。つまり 料金計算サービスが割引を適用するクラスに割引可能かを尋ねる。 可能な場合は料金計算サービスが割引を適用するクラスの割引処理を呼び出す。 とはせず、いきなり「割引して！」とお願いしています。これで呼び出し元に if 文を書かなくて済みます。「結局呼び出し先で if 文書くから同じじゃん」と思うかもしれませんが、料金計算サービスに 4 つの if 文が増えるのと、割引の各クラスに if 文が 1 つずつ増えるのと、どちらが見やすい（保守しやすい）でしょうか？ 反復する さて、これで終わりではなくて、実装で得た知見をモデルにフィードバックします。 例えば「601km を超える場合は」の部分をコードでは Destination#isTooFar と微妙な名前にしてあります。これは私がこの部分の業務をよく理解できておらず、適切な表現が浮かばなかったためです。 他にも application 層は不要で presentation 層と domain 層の 2 層で良いのでは？などなど、いくつか修正すべき点があります。 まとめ DDD は単に 業務を学んで 理解したことをモデルで表現して モデルの通りに実装する を繰り返すプロセスです。その際に必要となるのは モデリングスキル オブジェクト指向設計/プログラミングのスキル であり、別に DDD 固有のスキルは必要ありません。なので DDD できない！ムズイ！と感じる人は、1 と 2 のどちらが原因であるかを分析して対策すると、DDD ができるようになるかもしれません。 2020 年こそ、DDD をできるようになりましょう。 参考図書 エリック・エヴァンスのドメイン駆動設計 実践ドメイン駆動設計