こんにちは。BIGLOBE Style編集部です。 今回は、インターネット接続サービス・システムの開発を担う、プロダクト技術本部 サービス開発部の藤田直（ふじた なお）と、佐々木 明（ささきあきら）によるグループリーダー対談をお届けします。 2人が感じるリーダーとして働くやりがいから、どのような組織を目指し、そのためにどのような人と働きたいかなど、いろいろと話を聞いてみました。 伸びしろあるチームと、共に成長していくことを楽しめる人へ やれることがたくさんあるからこそ、大切にしていること チームビッグローブとして、健全で本質的な仕事を 伸びしろあるチームと、共に成長していくことを楽しめる人へ   —— お二人はどんな方と一緒に働きたいですか？まずは、この部署で求める人物像について教えてください。   藤田： 自社サービスや開発プロセスをより良く改善していくことにやりがいを感じる方と働きたいですね。 弊社にはSIer出身者が多くいますが、よく聞く前職の特徴として、受託案件で上から降りてきた仕様に対応することが仕事で工夫の余地や余裕がなかったり、そもそも業務を改善することで仕事を増やしたくないという雰囲気があったという声を聞きます。私自身も、前職はSIerで働いていたので温度感はよくわかるんですよね。 その点、私たちは自社サービスを運営している会社だからこそ、リリースした後も自らが長く携わることが多く、サービスを磨き上げることや開発環境をより良くしていくことが大切なのです。そういったところにやりがいを感じる人と一緒に働きたいですね。 藤田 直（ふじた なお） プロダクト技術本部 サービス開発部 デベロップメント3グループ グループリーダー BIGLOBEと関わりのあるNECグループ企業へ新卒で入社後、2012年にBIGLOBEへ転職。VAS（付加価値サービス）/IPv6に関わるシステムの開発/運用とその改善、「ビッグローブ光」の全体アーキテクト、内/外製開発、アジャイル開発の強化などに携わる。 佐々木 ：この環境は自ら変えられることが多いですよね。誤解を恐れずに言うと、まだ決まりきっていないことが多いので発展途上であり、組織として伸びしろだらけなんです。そのため、リーダーやPMとしてこの環境を楽しめる人に来て欲しいし、私たちと一緒に成長できる人がいいですよね。すでにでき上がった完璧な人ではなく、時には弱みを見せてくれたり人間味がある人の方があっているんじゃないかと思います。   藤田 ：そうですね。BIGLOBEはKDDIグループであり、インターネット回線などのITインフラも担う安定した事業基盤があるため、会社として敷居の高さを感じる方がいるかもしれません。でも、働いている中の人はチームワークを意識し柔軟に動ける雰囲気があります。 佐々木 ：外から見ると堅い感じの会社に思われるかもしれないですが、いい意味で驚くほどまだやれることがありますよね。 佐々木 明 (ささき あきら) プロダクト技術本部 サービス開発部 デベロップメント1グループ グループリーダー 2004年4月NECへ入社後BIGLOBE事業を担い、後に会社化したBIGLOBEへ転籍。固定回線サービス（ビッグローブ光、auひかり、ドコモ光、eo光、IPv6）に関わるシステムの開発/運用とその改善、内/外製開発、アジャイル開発の強化などに携わる。 藤田 ：社員が550名程なので、大きな中学校くらいの規模感の組織です。何か動かそうと思えば動かせますし、実際に 自社内で裁量権を持って働けて、プロジェクトでは今まで培った経験や調整力なども発揮できます。   佐々木 ：ちょうどいい規模感の組織ですが、システムの規模は大きく、一人ではやり切れないことが大半です。そのため、周りの人を巻き込みながら、効率良く物事を進めていく力がある方なら、面白い仕事ができるはずです。伸びしろだらけのこの環境をやりがいに感じるか否かで、弊社との相性がわかるかもしれません。   やれることがたくさんあるからこそ、大切にしていること —— このポジションの仕事内容ややりがいを教えてください。   佐々木 ：現在はインターネット接続サービス・システム開発におけるプロジェクトマネジャーと、設計・プログラム開発・保守などを担うエンジニアを募集しています。 特に内／外製開発のPMとして、各部署のリーダーや外注企業の担当者と連携し、上流工程からプロジェクトをリードしていく役割を担える人を求めています。   藤田 ：BIGLOBEは自社内に開発エンジニアだけでなく、運用・保守担当や企画、営業までいる会社なので、各関係部門と物事を円滑に進める力が求められるポジションなんです。   佐々木 ：その分、企画や営業に開発サイドの声が届く距離感のため、自分の想いを仕様に反映できることはやりがいに繋がるのではないでしょうか。   藤田 ：自社サービスなので、リリースした後もより良いサービスにするために改善を繰り返します。冒頭で、改善にやりがいを感じる人に来てほしいと伝えたのもそのためで、その意識があれば経験が浅くてもチャレンジできる社風があります。 例えば、ビッグローブ光回線以外にも、もう1つ回線を作るというプロジェクトが立ち上がった際に、私自身初めてPMの役割を任されました。会議室に、各チームのリーダー的な存在の人たちが集まり、何億円規模のプロジェクトを数時間で話し合って詰めていく経験ができたのは面白かったですね。作って終わりではなく、中長期的な視野を持って、自身が関わったサービスを磨き上げていくので、そういった働き方に興味がある方に来て欲しいですね。 （2024年11月追記：本募集は終了しました。） —— 自社サービスだからこそのやりがいがありますね。あえて課題感もあれば教えてください。   藤田 ：リーダーのポジションにいる人は、新卒入社のプロパー社員や社歴が長い人が多いので、外から新しい風も入れたいという想いがあります。   佐々木 ：私も新卒で NEC入社後からBIGLOBEの事業に携わり、後にBIGLOBEが会社化して今に至るので新卒からずっとこの会社にいます。働きやすい環境なので、古くから在籍しているメンバーが多く、PMなどを外部から募集した経験はほとんどありません。   藤田 ：心理的安全性があるので、たとえ行動して失敗しても、またチャンスはありますし応援してくれるカルチャーです。 もちろん、自社内開発だからといって何でもかんでも許されるわけではありませんが、 変えられることが多いので 中途入社の方も働きやすい会社だと思いますよ。   佐々木 ：例えば、以前はウォーターフォールで開発が進んでいましたが、プロジェクトの進みを早めるためにアジャイル開発を採り入れたり、他社さんの組織モデルを組み込んでみたり……結果、うまくいかず元に戻ったりと試行錯誤しながらも、常により良いところを目指そうとしています。 私自身も、社内で声を出して変えていける環境があるのはいいなと思っていますし、今はメンバーから上がってきた声を受け止める立場なので、リーダーへの期待に応えていけるように意識しています。 —— この環境でやれることがまだたくさんありそうですね。   藤田 ：そうだと思います。最近、SIerに勤める友人たちと飲みに行ったんです。どちらが良い悪いではないのですが、ワークライフバランスのために仕事は仕事と割り切っていて、ワークの方は淡々とこなしている印象でした。 もちろん、BIGLOBEもワークライフバランスを充実させている社員が多く、仕事とプライベートのメリハリを大切にできますが、ワークの部分でもやりがいや充実感を得られることが多くあります。チームビルディングも、新しい開発手法の導入も、企画も……例えば、BIGLOBEモバイルの エンタメフリー・オプション というサービスはエンジニアサイドから出てきた企画として実現していたりと、職種や役職にとらわれない挑戦ができる会社です。   佐々木 ：やれることがたくさんあるからこそ、私はメンバーの声を聞くことを大切にしています。チーム内でのコミュニケーションはもちろん、 1on1ミーティングもかなりの頻度で行っています。 コロナ禍でオフィスに出社しづらい時期も続いたので、最近は対面で対話することが大切だなと感じています。   チームビッグローブとして、健全で本質的な仕事を —— お二人の仕事における価値観を聞かせてください。   佐々木 ：私たちの行動規範である ビッグローブマインド に絡めると、「お客さま目線にたって、期待を超える」という言葉をずっと意識しています。 自社のシステムを使ってサービスを契約していただくなどお客さまの声や反応を直接把握できるので、お客さまがどうしたらもっと便利に利用できるのかを常に考えて開発するようにしています。 藤田 ：私もお客さま目線に立った上で、「チームビッグローブ」を意識しています。例えば、お客さまが求めているこの機能は優先的にリリースして、その上でもう少し作り込んでここは第2弾でリリースしましょうなどの柔軟な調整ができるのも、プロジェクトメンバー同士の目線が合っているからだと思います。 佐々木 ：発注元が社外のシステム会社だったりすると、実際に利用するお客さまが見えないので、難しいところかもしれません。発注元に言われたことだけをやるのではなく、チームメンバーみんながお客さまの立場になって、おかしいところはおかしいよねと言い合えるので、とても健全で本質的な仕事ができる環境です。   藤田 ：リーダーとして、メンバーや関係者みんなの視点を合わせるように意識していますが、もちろん大変なこともあります。例えば営業サイドが無理難題を要求してきた時に、そのまま引き受けて しまったりとか（笑）。 だからこそ、いつも「私たちはチームビッグローブだよね」という視点を持って仕事をしています。   —— 最後に、この記事を読んでいただいた方に伝えたいことがあれば教えてください。   佐々木 ：人として距離が近い人に来てほしいですね。まだ未完成なチームなので、組織の「これから」を一緒に作っていく仲間を募集しています。 藤田 ：失敗を恐れず、面白そうな仕事やプロジェクトには自ら手を挙げて挑戦して欲しいと思います。そういった選択肢がBIGLOBEにあるということを伝えたいですね。   —— 本日はありがとうございました！   BIGLOBEでは、一緒に働く仲間を募集しています。ご興味のある方はこちらの採用情報をご覧ください。 www.biglobe.co.jp   ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部の森山です。 BIGLOBEでは、今年もAmazon Web Services（AWS）に触れることができるエンジニア向けインターンシップを開催します！ 本インターンシップの特徴は、実際にAWSに触れてインフラの構築やトラブルシューティングなどの実務的な体験ができること。少人数かつ若手社員と一緒に取り組むため、アドバイスをもらいながら効果的に学べます。 インフラからアプリまで幅広い興味のある方や、クラウド（AWS）に興味はあるけれど使った経験がないといった方におすすめのインターンシップですので、是非ご参加ください。 AWSは個人で利用するには費用の発生などもありハードルも高いと言われますが、BIGLOBEのインターンシップではそのハードルもゼロ！ 毎年参加者から大変好評なインターンシップとなっております。 インターンシップの概要 内容 参加にあたって 日程 応募方法 インターンシップの魅力 おすすめポイント 昨年度開催のインターンシップ参加者の声 インターンシップへ参加するとこんなことができるようになります ファシリテーターからひとこと   インターンシップの概要 内容 2日間を通してAWSの基礎についてと、システムに問題が発生した際の解決方法について学んでいただきます。 1日目はハンズオン形式でAWSの基本を学んでいただき、基本的なWebシステムを構築します。 2日目は1日目で学習した知識を活かして、実践的なトラブルシューティング(問題解決)に挑戦します。 参加にあたって 本インターンシップへの参加は、基礎知識確認のクイズを受けていただいた後に、事前学習の同意を得たうえで「抽選」となります。 抽選に当選し、参加いただけることになった場合、事前学習としてAWSの基礎知識を資料と動画（BIGLOBE社員が作成したもの！）で学んでいただくことを推奨しています。事前学習の理解度チェックのために、知識確認のクイズも実施いただけます。 ※筆記用具、インターネット環境、カメラオンでWeb会議可能なPCが必要です。 ※クイズの回答結果並びにインターンシップへの参加可否が今後の採用選考に関係することはございません。 日程 ①8/29(火)10:00-17:00（お昼休憩1時間）、8/30(水)13:00-16:00 ②9/13(水)10:00-17:00（お昼休憩1時間）、9/14(木)13:00-16:00 ※1.5日通してご参加ください。 ※抽選結果発表後、当選された方は希望の日程を選択しご予約いただけます。各日程ごとに定員数が決まっており、先着順でのご予約となります。 応募方法 下記URLよりエントリー後、マイページにログインしていただき、Step Navi「エンジニア職向けインターンシップ申し込み」へアクセスし、お申し込みください。 https://mypage.3050.i-webs.jp/biglobe2025/applicant/login/baitai-entry/entrycd/Style ※右下にございます「初めての方はこちら」より、新規登録をしてください。     インターンシップの魅力 おすすめポイント ・AWS未経験でも安心して参加できる 1日目のハンズオンは少人数のグループに分かれて社員が常時サポートを行うため、AWS未経験の方でも安心して参加いただけます。 ・業務の疑似体験ができる 2日目は2〜3人のチームでシステム不具合への対応に取り組んでもらいます。実際の業務でも問題発生時には複数人で取り組むため、業務を疑似体験することができます。 ・社員と接する時間が多く、BIGLOBEの雰囲気がわかる 2日間を通して5名以上のBIGLOBE社員と話したり、ハンズオンやトラブルシューティングに取り組んでいただけます。ラフな座談会も行うので、社風や実際の働き方を知っていただけると好評です。   インターンシップで構築するWebシステムの構成図 昨年度開催のインターンシップ参加者の声 業務で使われるAWSの環境で、本番でも使われる構成を構築できとてもよかったです。研究室の後輩におすすめしたいです。 AWSを触ったことがありませんでしたが分かりやすく説明していただけました。 インターネットサービスを提供する事業者がどのようにしてサービス環境を構築しているのかを知ることができました。 1日目の個人ワークでは、じっくりと取り組むことができ、2日目のグループワークでは、楽しく取り組むことができました。大変勉強になる2日間でした。 AWSの簡単な使い方を1日で学び、翌日にトラブルシューティング対応するというのを初めて経験し、実際にどのように業務を行うのかを知ることができました。   インターンシップへ参加するとこんなことができるようになります ・AWS上での基本的なWebシステム構築 ・BIGLOBE流のふりかえり（仕事以外でもあらゆる場面で役立ちます！） ファシリテーターからひとこと 荒川 晴哉 (あらかわ せいや) プロダクト技術本部 クラウド技術部 クラウドストラテジー・コンサルグループ 2022年4月新卒入社 私が就活中に初めて参加したインターンシップがBIGLOBEのインターンシップでした。 元々サーバーを触ったことがあったため、「最近流行りのクラウドを使用したサーバー構築ができる」と研究室の先輩からすすめられたのがきっかけで参加しました。 インターンシップでは、社員の方々も気さくで、緊張しやすい性格の私でものびのびと参加できました。座学だけではなく、障害復旧などの実践的な内容も体験できたため、手を動かすインターンシップに参加してみたい人には特におすすめの内容となっています。 私はこのインターンシップに参加し、BIGLOBEの雰囲気が私に合っていると思い入社を決めました。BIGLOBEでは人材育成に力を入れており、その中でも資格取得に対するサポートが手厚く、私は入社してから3カ月後の7月にAWSソリューションアーキテクト・アソシエイトの資格を取得しました！ 最初の一歩を踏み出すのは緊張するかもしれませんが、少しでも興味がありましたら弊社のインターンシップにご応募ください！ 当日私も参加するので、みなさんにお会いできることを楽しみにしています！   坂川 巧将 (さかがわ こうすけ) プロダクト技術本部 サービス運用部 運用グループ 2022年4月新卒入社 僕がBIGLOBEのインターンシップを知ったのはネットでたまたま目に付いたことがきっかけです。AWSの知識は全くありませんでしたが、クラウド技術に興味があり、初心者でも参加可能だったため応募してみました。実際に参加してみるとわからないことだらけでしたが、社員のみなさんが丁寧に教えてくれたため問題ありませんでした。 インターンシップ中には先輩社員と話をすることで BIGLOBEでの仕事の具体的なイメージができ、入社のきっかけになりました。 入社後もAWS教育が充実しており、講義やハンズオンで実務的な内容を学ぶことができます。おかげで入社後半年でAWSソリューションアーキテクト・アソシエイトの資格を取得できました。 参加してみないとわからないこともあるので、迷っている方も気軽に応募してみてください！ インターンシップで、みなさんとお会いできるのを今から楽しみにしています！   白井 春香 (しらい はるか） プロダクト技術本部 マーケティングプラットフォーム部 ビジネスプラットフォームグループ 2021年4月新卒入社 BIGLOBEのインターンシップでは、実際に手を動かしながらAWSでのシステムの構築とトラブルシューティングを体験できます。先輩社員に質問しながら取り組めるため、未経験の方も大歓迎です！ また、2日目にある先輩社員との座談会では、BIGLOBEでの働き方など気になることを気軽に質問していただけます。私も入社前座談会に参加しましたが、先輩社員の方がとても優しく、BIGLOBEの雰囲気をイメージすることができました。 入社後はエンジニア新人研修が充実しており、チーム開発演習やAWS研修が行われています。1年を通して週に1〜2日あるエンジニア新人研修は、研修の日が楽しみになるようなカリキュラムとなっており、実務的な内容をじっくり学べます。 少しでも興味をお持ちいただけましたら、まずはインターンシップにぜひ応募してみてください！みなさんとお会いできることを楽しみにしています！   ご参加お待ちしています！   www.biglobe.co.jp ※ Amazon Web Servicesは、米国その他の諸国における、 Amazon.com ,Inc.またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

Google Chatをより便利に使うChatアプリをGoogle Apps Scriptで作ります。オウム返しからメンバーのシャッフルへと段階的に機能を追加していきます。 Google Apps Scriptを使ってChatアプリを自作する Step0: 始める前の準備 Step1: 公式チュートリアルでオウム返しアプリを作る 作業1. Google Cloudプロジェクトの作成 作業2. Chat APIの有効化 作業3. OAuth同意画面の構成 作業4. Google Apps Script をテンプレートから作成 スクリプトエディターにGoogle Cloudのプロジェクト番号を設定 スクリプトエディターでテスト用デプロイIDを確認 作業5. Google Chat APIの設定 オウム返しするか試してみる Step2: 機能を追加してランダムボットを作る Google Chat APIの利用とユーザー認証、サービスアカウント認証 作業6. OAuth2 for Apps Scriptライブラリーをインポート 作業7. サービスアカウントと秘密鍵を作成しスクリプトプロパティに保存 作業8. 高度なチャットサービスをスクリプトエディターで追加 メンバー一覧を取得できるか試してみる トラブルシューティング: displayName が表示されない メンバーを並び替えて返信する Step3: 読みやすくするために既存のスレッドに返信する まとめ 開発部門（プロダクト技術本部）の高玉です。 BIGLOBEはオフィス生産性ツールにGoogle Workspaceを使っています。メインとなるコミュニケーションツールはGoogle Chatで、リアルタイムでの情報共有をスムーズに進行してくれます。リリース当初と比べて機能改善が進み、使い勝手が良くなってきました。 Google Chatは人間とだけでなく、 Google Chatアプリ 1 とコミュニケーションをすることも可能です。Chatアプリからリアルタイムな通知を受け取るだけでなく、Chatアプリに話しかけることで人間の代わりにコマンドを実行させることもできます。 Googleが提供するChatアプリ を使うことも、自作することも可能です。 私が自作したChatアプリの中でも最もよく使われているのが「ランダムボット」です。例えば、朝会で発表する順番をランダムに決める時に利用します。@をつけてChatアプリをメンションすると、そのスペースにいるメンバーをランダムに並び替えてくれます。 Chatアプリを作る手段はいくつかあります。ここでは最も手軽で、初心者でも取り組みやすいGoogle Apps Scriptを使った方法を紹介します。一方、より高度な技術を用いたい場合には、Cloud Functionsを使ってPythonやNode.jsで実装することも可能です 2 。 なお、続編としてGoogle Chat APIの新機能を使ってダイレクトメッセージを送信するアプリの作り方も記事にしています。次のステップとしてぜひご活用ください。 style.biglobe.co.jp Google Apps Scriptを使ってChatアプリを自作する この記事では、Google WorkspaceでApps Scriptを使った開発経験がある方を対象に、Chatアプリを自作する方法を解説していきます。 初めてChatアプリの開発に取り組む方にとっては、見慣れない設定がいくつかありますが、設定に必要になる情報を先に考えておくと、スムーズに作業を進められます。そこで、「始める前の準備」を先にご紹介します。 また題材にはランダムボットを使います。まずは Googleが提供するChatアプリのチュートリアル に従って、ごく単純な「オウム返し」アプリを作ります。それをベースに段階的に機能を追加していきます。 Step0: 始める前の準備 Chatアプリの実装に向けて、まずはいくつかの設定作業をこなしていきましょう。設定を一気に進めるために、予め準備しておくべきことを紹介します。 使う画面はGoogle CloudのコンソールとApps Scriptのスクリプトエディターです。これらの2つのインターフェースを使いながら進めていきます。片方の画面の情報を、もう片方の画面に入力することもあります。 事前に準備しておくべきなのは次の4点です。これらを決めておくことで、よりスムーズに作業を進めることができます。 Google Cloud のプロジェクト名（英語） アルファベット。ハイフン可。 今回は random-bot にします。 アプリ名（日本語） 「Google」という単語が使えないことに注意してください。 OAuth 同意画面を保存する時に「アプリの保存中にエラーが発生しました」と表示され、保存できなくなります。 今回は ランダムボット にします。 アプリの説明（日本語） 今回は メンバーをランダムに並び替えます。 にします。 アプリのアバター画像 著作権を侵害しないように気をつけましょう。 今回はチュートリアルでも使う https://developers.google.com/static/workspace/chat/images/chat-product-icon.png を使います。 組織内の全員がChatアプリをインストールできるようにするには、追加で画像を準備する必要があります。これらの画像は（URL指定ではなく）アップロードする必要があります。後で必要になることだけ、頭に入れておいてください。 アプリのアイコン（32x32pxと128x128pxの2つ） ただし同じ画像を使い回せました 説明カード画像（220x140px） スクリーンショット（640x400、1280x800、2560x1600のいずれか） Step1: 公式チュートリアルでオウム返しアプリを作る まずは Google公式のチュートリアル に従って話しかけたことをそのまま返す「オウム返し」アプリを作ります。このアプリはGoogle Chatのスペースに追加でき、話しかけると反応してくれます。 準備が整ったら、次の5つの作業を一気に片付けてしまいましょう！ 作業1. Google Cloudプロジェクトの作成 作業2. Chat APIの有効化 作業3. OAuth同意画面の構成 作業4. Google Apps Script をテンプレートから作成 作業5. Google Chat APIの設定 作業1. Google Cloudプロジェクトの作成 Cloud プロジェクトの選択 にアクセスし「プロジェクトを作成」を押して新しくプロジェクトを作成します 3 。 準備しておいたプロジェクト名 random-bot を入力します。組織と場所はあなたが使用しているGoogle Workspaceのものを選択してください。 作成ボタンを押します。少々時間がかかります。新しいプロジェクトが作成できると通知が届きます。 プロジェクト番号（プロジェクトIDではありません）は後で使うのでメモします。 作業2. Chat APIの有効化 APIの有効化 を押して、CloudコンソールでGoogle Chat API を有効にします。 作業3. OAuth同意画面の構成 OAuth同意画面に移動 を押して、CloudコンソールでOAuth同意画面を開きます。 OAuth同意画面に、次の情報を入力していきます。 User Type 社内用なので「内部」を選びます。 アプリ情報 アプリ名 準備しておいた ランダムボット を入力します。 Google という単語を含めないでください。アプリの保存に失敗します。 ユーザーサポートメール 自分のメールアドレスを入力してください。自分が所属するメーリングリストのメールアドレスを入力することもできます。 アプリのロゴ 空欄でOKです。 もし設定するなら、著作権に注意しましょう。サイズは 120 x 120 px の正方形が推奨です。 アプリのドメイン 空欄でOKです。 承認済みドメイン 空欄でOKです。 デベロッパーの連絡先情報 自分のメールアドレスを入力してください。 スコープ 空欄でOKです。 以上で OAuth同意画面の設定は終わりです。(2) スコープ、(3) 概要、は何も入力する必要はありません。保存して次へ、を押して、ダッシュボードへ戻る、を押してください。 作業4. Google Apps Script をテンプレートから作成 https://script.google.com/home/projects/create?template=hangoutsChat&hl=ja にアクセスして、Chat テンプレートから Apps Script を作成します。 もしくは、 https://script.google.com/home/start にアクセスして、ページの一番下にある chat bot を選びます。 もし、テンプレートから作らない場合は、手作業でappsscript.jsonファイルを設定する必要があります。プロジェクトの設定の「全般設定」で「「appsscript.json」マニフェスト ファイルをエディタで表示する」にチェックをし、appscript.jsonファイルの中に "chat": {} と記載する必要があります。 スクリプトエディターにGoogle Cloudのプロジェクト番号を設定 スクリプトエディターの左ペイン「ギア」マーク（プロジェクトの設定）を選択します。一番下にある Google Cloud Platform（GCP）プロジェクトで「プロジェクトを変更」を押して、プロジェクト番号を入力し「プロジェクトを設定」ボタンを押します。 なお、プロジェクト番号は Cloud Consoleにアクセス することで確認できます。 なお、この作業の前にOAuth同意画面を設定していない場合、「プロジェクトを変更するために、OAuth 同意画面を設定する必要があります」というエラーが表示されます。ステップ3を済ませてから「プロジェクトを設定」ボタンを押しましょう。 スクリプトエディターでテスト用デプロイIDを確認 次に、スクリプトエディターの右上にある「デプロイ」ボタンを押し、「デプロイをテスト」を選択し、ヘッドデプロイIDをメモします。 なお、ヘッドデプロイは、テスト用にしか使えません。組織内の他の人がインストールできるようにするためには、別途デプロイを実施し、正式なデプロイIDを使う必要があります。 作業5. Google Chat APIの設定 Google Chat APIの管理画面 に戻ります。 画面中央のタブから「構成」を選びます。 次の情報を設定していきます。 アプリケーション情報 アプリ名 準備しておいた ランダムボット を入力します。 アバターの URL 準備しておいた https://developers.google.com/static/workspace/chat/images/chat-product-icon.png を入力します。 説明 準備しておいた メンバーをランダムに並び替えます。 を入力します。 インタラクティブ機能 有効にします。 機能 1:1のメッセージを受信する は無効にします。 アプリ にメッセージを直接送信できます。 ランダムボットでは使用しません（複数のメンバーを並び変えるため）。 スペースとグループの会話に参加する は有効にします。 アプリ は複数のユーザーが存在するスペースで動作します。 接続設定 Apps script project を選んで、先程メモしたデプロイIDを入力してください（「デプロイを管理」から確認できます。スクリプトIDではありません）。 スラッシュコマンド 何も設定しなくてOKです。 リンクプレビュー 何も設定しなくてOKです。 公開設定 このチャットアプリを＜あなたの組織名＞の特定のユーザーとグループが使用できるようにします、をチェックします。 「ドメイン内の個人とグループを追加します」に公開する対象者のメールアドレス、もしくは、グループのメールアドレスをカンマ区切りで入力します。 なお、このチェックを外すことで組織内の全てのユーザーが使用できるようにできますが、別途、Google Workspace Market SDKの設定と、Google Workspace管理者の承認が必要です。 ログ エラーをLoggingに保存する、をチェックしておきます。 保存ボタンを押します。 オウム返しするか試してみる お疲れ様でした！ここまでのステップで、話しかけたことをオウム返ししてくれるChatアプリが動くようになりました。 https://chat.google.com/ にアクセスして、アプリをインストールしてみます。 Google Chatのスペースにアプリを追加するには、スペース名をクリックして「アプリの統合」を選択し、さらに、アプリを追加ボタンを押します。 @を押して、Chatアプリ宛にメンションをします。 Step2: 機能を追加してランダムボットを作る いよいよ楽しいコーディングの始まりです。オウム返しアプリをベースに、スペースにいるメンバー一覧を取得して、ランダムに並び替える機能を追加します。そのために、メンバー一覧を取得するのに必要なGoogle Chat APIの使い方を確認していきます。 Google Chat APIの利用とユーザー認証、サービスアカウント認証 公式チュートリアルで作ったオウム返しアプリですが、そのままメッセージを返信するだけなら、認証は不要です。しかし、 Google Chat API を利用してGoogle Chatの情報にアクセスしたり、Chat機能を使ってメッセージを発信する場合には認証が必要になります。詳しくは公式ドキュメント Chat アプリと Google Chat API リクエストの認証と認可 をご覧ください。ここではかいつまんで説明します。 Google Chat APIを利用するのに必要な認証には アプリ認証（サービスアカウント認証） と、 ユーザー認証 の2つがあります。APIによって必要な認証は異なります。また、どちらの認証を利用してAPIを実行したかで、実行結果も異なります。 実行結果の違いを指定したスペースに、指定したメッセージを発信するAPI、 spaces.messages.create メソッドを使って説明します。サービスアカウント認証を使う場合、Chatボットが実行の主体となります。よって、送信元はChatアプリになります。一方、ユーザー認証を使う場合、Chatボットに権限を付与したユーザーが実行の主体となるため、Chatアプリではなくあたかもユーザーが発信したかのように見えます。 ほとんどのAPIで、サービスアカウント認証とユーザー認証の両方が使えます。しかし、ユーザー認証だけが許可されているAPIも存在します。例えば、ランダムボットはそのスペースにいるメンバー一覧を取得する必要があります。 spaces.members.list メソッドで実現できますが、このAPIはサービスアカウント認証でも、ユーザー認証でも利用できることがわかります。しかし、メッセージ一覧を取得する spaces.messages.list メソッドでは、ユーザー認証だけが許可されています。 サービスアカウント認証をする場合、事前に サービスアカウントを作成する 必要があります。また、 OAuth2 ライブラリーを使ってAPIを呼び出す必要があります。 今回、ランダムボットで必要になるAPIは、メンバー一覧取得（spaces.members.list）とメッセージ発信（spaces.messages.create）です。どちらもサービスアカウント認証を使って実行します 4 。 そこで、追加の作業として、OAuth2 for Apps Scriptライブラリーをインポートし、サービスアカウントを作成します。 作業6. OAuth2 for Apps Scriptライブラリーをインポート サービスアカウント認証を使ってGoogleのAPIを呼び出すには、Apache Licence 2.0のオープンソース OAuth2 for Apps Script を利用します。 Apps Scriptのスクリプトエディターを開き、左ペイン「ライブラリ」の右横にあるプラスボタンを押して、ライブラリーを追加します。公開されているOAuth2のスクリプトIDは 1B7FSrk5Zi6L1rSxxTDgDEUsPzlukDsi4KGuTMorsTQHhGBzBkMun4iDF です。 ただし、スクリプトIDを検索した場合に「ライブラリを検索できませんでした。IDとアクセス権限を確認して、もう一度お試しください」というエラーが表示されるかもしれません。安全のため、組織外のライブラリーを追加できないようGoogle Workspaceを設定しているのかもしれません。 組織外のApps Scriptライブラリーを参照できない場合、組織内にソースコードをコピーして使う必要があります。Apache Licence 2.0は商用利用可能なライセンスですが、ライセンス条項と一緒に再配布する必要があります。まず新規でApps Scriptのプロジェクトを作り、ソースコード https://github.com/googleworkspace/apps-script-oauth2/blob/master/dist/OAuth2.gs のうち、コメント /* code begin */ から /* code end */ までの間のコードをコピーして保存します。その際、Apache Licence 2.0 ライセンスのソフトウェアであることがハッキリ分かるよう、以下のコメントをつけておきます。 // このソフトウェアは https://github.com/googleworkspace/apps-script-oauth2/blob/master/dist/OAuth2.gs で公開されているOAuth2 for Apps Scriptをそのままコピーしたものです。 // Apache Lisence 2.0 で配布されています。 // https://github.com/googleworkspace/apps-script-oauth2/blob/master/LICENSE その後、画面右上にある共有ボタンで、組織内に共有します。閲覧権限のみ共有すればOKです。スクリプトに対して閲覧権限を与えるだけなら、次の作業で使うスクリプトプロパティまでは閲覧できません。もしスクリプトの編集権限まで付与してしまうと、スクリプトプロパティを閲覧し、秘密鍵の中身まで見えるようになってしまうため、気をつけてください。 共有が終わったら、プロジェクトの設定からスクリプトIDを確認し、ランダムボットのスクリプトエディターのライブラリとして追加します。 作業7. サービスアカウントと秘密鍵を作成しスクリプトプロパティに保存 公式ドキュメントの手順 に従ってサービスアカウントを作成し、秘密鍵を作成します。 注意！ 秘密鍵の管理は非常に重要です。この秘密鍵が漏洩すると、そのサービスアカウントの権限を持つ人物やシステムが、あなたの名前で行動することが可能になります。これは、データの不正アクセス、改ざん、削除といった深刻なセキュリティ上のリスクを生じます。秘密鍵を決してそのままソースコードに掲載しないでください。 次に、秘密鍵をテキストエディター等で開き、中身をまるごと、ランダムボットのプロパティの値として保存します。スクリプトエディターの左ペインにあるギアアイコンから、プロジェクトの設定を開き、画面下にあるスクリプトプロパティを追加します。 プロパティは JSON_SECRET_KEY 値は秘密鍵の内容をそのままペースト スクリプトプロパティを保存します。保存したら、安全のため、ダウンロードした秘密鍵ファイルを完全に削除してもOKです。しかし、削除する前に必ずスクリプトプロパティへの保存が成功していることを確認してください。また、秘密鍵をコピーする間に、他人が見えないようにするための措置も行ってください。例えば、公共の場所での作業を避ける、他人が画面を覗き見られないような場所で作業をするなどの工夫が必要です。 作業8. 高度なチャットサービスをスクリプトエディターで追加 Apps ScriptからGoogle Chat APIを使うために、スクリプトエディターから 高度なチャットサービス を追加します。 スクリプトエディターの左ペイン「サービス」でプラスの追加アイコン（＋）を押し、Google Chat API を選択します。バージョンは v1 、IDは Chat のままにします。 メンバー一覧を取得できるか試してみる ここまでの作業ができたら、サービスアカウント認証を使ってOAuth2ライブラリーが動作することを確認します。ランダムボットのスクリプトエディターに、以下のコードを追記して、指定したスペースのメンバー一覧が取得できるか確認します。 function getJsonSecretKey_ ( key = 'JSON_SECRET_KEY' ) { const file = PropertiesService . getScriptProperties () . getProperty ( key ) ; if ( ! file ) throw `スクリプトプロパティにキー「 ${ key } 」で、JSON形式の秘密鍵を追加してください。` ; return JSON . parse ( file ) ; } function createChatService_ ( key = 'JSON_SECRET_KEY' ) { const jsonSecretKey = getJsonSecretKey_ ( key ) ; const service = OAuth2 . createService ( 'chat' ) . setTokenUrl ( 'https://accounts.google.com/o/oauth2/token' ) . setPrivateKey ( jsonSecretKey . private_key ) . setClientId ( jsonSecretKey . client_email ) . setPropertyStore ( PropertiesService . getUserProperties ()) . setScope ( 'https://www.googleapis.com/auth/chat.bot' ) ; if ( ! service . hasAccess ()) throw 'Authentication error: %s' , service . getLastError () ; return service ; } function listMembers_ ( spaceName ) { const service = createChatService_ () ; const resultKey = 'memberships' ; const results = [] ; const filter = 'member.type = "HUMAN"' ; let pageToken ; do { const json = Chat . Spaces . Members . list ( spaceName , { filter : filter , pageSize : 1000 , pageToken } , { 'Authorization' : `Bearer ${ service . getAccessToken ()} ` }) ; results . push ( ... json [ resultKey ]) ; pageToken = json . nextPageToken ; } while ( pageToken ) ; return results ; } function testListMembers () { const spaceName = '<メンバー一覧を取得するスペース名>' ; console . log ( listMembers_ ( spaceName )) ; } なお listMembers_() では、ページング処理をしています。APIが一度に返すことのできる結果数には限界があり、一度のリクエストで全てのメンバーを取得することができません。1000件より大きな結果になる場合、レスポンスにnextPageTokenが返却されるので、URLの pageToken パラメーターにその値を渡して次の結果を取得しています。 testListMembers() を実行するために、メンバー一覧を取得するスペース名を確認します。Google Chatでスペースを選択すると、URLは https://mail.google.com/chat/u/0/#chat/space/XXXXXXXXXXX の形式になっています。最後のID部分から、スペース名は spaces/XXXXXXXXXXX として作ります。spaces と s がついている点が異なりますので注意してください。 testListMembers() を実行した時に、実行ログに <h1>Not Found</h1> <h2>Error 404</h2> と表示される場合は、スペース名の指定方法が間違っています。 また、 { "error": { "code": 403, "message": "This Chat app is not a member of this space", "status": "PERMISSION_DENIED" } } と表示される場合は、ランダムボットをそのスペースに追加してから実行してください。 成功すると実行ログに [ { name: 'spaces/XXXXXXXXXXX/members/nnnnnnnnnnnnnnnnnnnnn', state: 'JOINED', member: { name: 'users/nnnnnnnnnnnnnnnnnnnnn', displayName: '高玉広和', type: 'HUMAN', domainId: 'YYYYYYY' }, createTime: '2023-02-24T01:41:51.365049Z', role: 'ROLE_MANAGER' } ] のように表示されます。 トラブルシューティング: displayName が表示されない Chat.Spaces.Members.list() の第3引数にAuthorizationヘッダーとOAuth2ライブラリーで作成したアクセストークンを設定していることを確認してください。もし、第3引数がないと（サービスアカウント認証ではなく）ユーザー認証によるメッセージ取得になります。ユーザー認証でのメッセージ取得では member.displayName を取得できません。 なお、ユーザー認証で取得したメッセージの member.name から名前を取得する方法は 次の記事 で解説しています。 メンバーを並び替えて返信する メンバー一覧が取得できるようになったら、ランダムボットの onMessage(event) を次のように書き換えます 5 。 function shuffle_ ( a ) { for ( let i = a . length - 1 ; i > 0 ; i -- ) { const j = Math . floor ( Math . random () * ( i + 1 )) ; [ a [ i ] , a [ j ]] = [ a [ j ] , a [ i ]] ; } return a ; } function shuffleMembers_ ( spaceName ) { const names = listMembers_ ( spaceName ) . map ( membership => membership . member . displayName + 'さん' ) ; return shuffle_ ( names ) ; } /** * Responds to a MESSAGE event in Google Chat. * * @param {Object} event the event object from Google Chat */ function onMessage ( event ) { const text = [ ` ${ shuffle_ ([ 'がんばって' , '気合を入れて' , 'いい感じに' ])[ 0 ]} 並び替えたよ！` , ... shuffleMembers_ ( event . space . name ) ] . join ( '\n' ) ; return { text } ; } スクリプトを保存したら、スペースに追加したランダムボットに何でも良いので話しかけてみましょう。次のように返信されます。 もしランダムボットから返信がない場合は、スクリプトエディターの左ペイン「実行数」で実行ログを確認できます。次のエラーが出ている場合、スペースのメンバーの中に、ランダムボットの実行が許可されていないメンバーがいるかもしれません。 { "error": { "code": 403, "message": "This organization's administrator must allow users to install this Chat app", "status": "PERMISSION_DENIED" } } Google Chat APIの管理画面 の「ドメイン内の個人とグループを追加します」には5名まで、Chatアプリを実行できる人を記載できます。それよりも多くのメンバーにChatアプリを使わせる場合、 Google Workspace Marketplace SDK でアプリを設定する を実施した上で、Google Workspaceの管理者にChatアプリを承認してもらいます。 Step3: 読みやすくするために既存のスレッドに返信する Step2までで、ランダムボットの機能面はすべて実現できました。最後は細かな修正です。Step2では、利用者が新しいスレッドでランダムボットに呼びかけた場合、その返信のために別の新しいスレッドを作っています。これを、利用者が作ったスレッドに返信する形にしてみます。 これを実現するために、onMessage(event)では、 { text } オブジェクトをreturnするのをやめて、Chat APIを使って返信するスレッドを指定したメッセージを送信します。 function createMessage_ ( text , spaceName , threadName ) { const message = { text } ; const options = {} ; if ( threadName ) { message . thread = { name : threadName } ; options . messageReplyOption = 'REPLY_MESSAGE_FALLBACK_TO_NEW_THREAD' ; } const headers = { 'Authorization' : `Bearer ${ createChatService_ () . getAccessToken ()} ` } ; Chat . Spaces . Messages . create ( message , spaceName , options , headers ) } function onMessage ( event ) { const text = [ ` ${ shuffle_ ([ 'がんばって' , '気合を入れて' , 'いい感じに' ])[ 0 ]} 並び替えたよ！` , ... shuffleMembers_ ( event . space . name ) ] . join ( '\n' ) ; // return { text }; createMessage_ ( text , event . space . name , event . message . thread . name ) ; } 既存のスレッドに返信をするために、 spaces.messages.create メソッドのQueryパラメーター messageReplyOption を指定し、 message に返信するスレッド { thread.name } を指定しています。 まとめ 以上がGoogle ChatのChatアプリをApps Scriptで自作するための一連の手順です。今回は、「始める前の準備」から始めて、「オウム返し」アプリを作り、その後、機能追加で「ランダムボット」を作成しました。さらに利便性を向上させるために、「既存のスレッドに返信する」機能も追加しました。このように、一歩一歩進めていくことで、より複雑なChatアプリを自作することも可能になります。 最初は複雑に感じるかもしれませんが、必要な機能を順次追加し、理解を深めていけば、独自のChatアプリを開発することができるでしょう。 この記事では「とりあえず動く」Chatアプリを開発するまでの過程をご紹介しました。Chatアプリとしてあるべき振る舞いは ユーザーを喜ばせるチャットアプリを作成する にまとまっていますので、ぜひご一読いただき、機能を追加してみてください。 スペースに追加された時に、このChatアプリでできることを簡潔に紹介する スラッシュコマンドを実装 し、 /help で使い方を紹介したり、 /random や /shuffle でメンバー一覧を並び替える この記事が、あなたのChatアプリ作成の第一歩となることを願っています。 なお、続編としてGoogle Chat APIの新機能を使ってダイレクトメッセージを送信するアプリの作り方も記事にしています。次のステップとしてぜひご活用ください。 style.biglobe.co.jp ※ Google 、Google Chat 、Google Workspace 、GCP は、Google LLC の商標であり、このブログはGoogle によって承認されたり、Google と提携したりするものではありません。 ※ Apache は、The Apache Software Foundationの商標または登録商標です。 ※記載しているシステム名、製品名、サービス名は、それぞれ各社の商標または登録商標です。 一般的には、チャット画面で人間とやりとりするソフトウェアを チャットボット（chatbot） と呼びます。しかし、GoogleはあえてChatアプリと呼んでいます。 Chat アプリはチャット画面から呼び出せるWebアプリケーションであり「単なる bot」以上のものと見なせる から、だそうです。 ↩ Chatアプリには多くの種類があります。Webhookを使って通知だけをするアプリや、Node.jsなどApps Script以外の環境で動かすアプリ、チャット画面上でフォームを使い入力を受け付けるアプリなどです。そうしたアプリの作り方は、動画付きの公式ドキュメント Google Chatアプリを作成する で学ぶことができます。 ↩ プロジェクト数の上限は最初は10個です。それ以上作りたいときはMANAGE QUOTASのリンクをクリックして、Googleに申請しましょう。 ↩ 今回は利用しませんが、ユーザー認証の場合は OAuth2ライブラリーを使用する必要はありません 。また、1. Apps Scriptのスクリプトエディターでappsscript.jsonを表示し、oauthScopesを記載する必要があります。2. APIを呼び出す場合は、AuthorizationヘッダーにBearerとしてScriptApp.getOAuthToken()で取得した値を設定します。 ↩ onMessage(event) に渡される Eventの定義はこちら です。 ↩

こんにちは。BIGLOBE Style編集部です。 今回紹介するのは、プロダクト技術本部 マーケティングプラットフォーム部 メディアシステム開発グループの小林 映里奈。 2015年に新卒で入社後、サーバーサイドエンジニアとして さまざま なプロジェクトを手がけてきました。現在は社内の新サービス創出活動にも参加し、活躍の幅を広げています。 女性エンジニアものびのび働ける環境があると話す彼女の声から、BIGLOBEのカルチャーや人の魅力を感じてみてください。 人の雰囲気の良さで会社を選んで、間違いなかった 成果を出すために、自分の得意分野でパフォーマンスを発揮する 挑戦を後押しする仲間がいる、カルチャーがある 人の雰囲気の良さで会社を選んで、間違いなかった —— まずは小林さんのプロフィールをお聞きしたいと思います。   私は学生時代から本とパソコンが好きだったことから、大学で図書館情報学を専攻していました。多くの人にはあまり馴染みのない分野かもしれませんが、主に図書館で使われるシステムなどを勉強する学部で、卒論の課題では本に関わるアプリ開発を行いました。 就活では、NECが図書館系のシステムを開発していると知って、NEC本体やグループ会社にエントリーしました。最終的に「NECビッグローブ」から内定をいただき入社を決めました。ところが その年のタイミングでBIGLOBEがNECグループから独立したため、2015年4月の入社時はBIGLOBEに新卒で入ったという流れになります。   —— ちょうどNECからBIGLOBE と して独立したタイミングだったのですね。NECで働く選択肢もあったかと思いますが、BIGLOBEを選んだ理由とは？   当社に興味をもった要因としては、会社説明会などでBIGLOBEの社員と話したときに雰囲気がいいチームだなぁと感じたことです。エンジニアがのびのびと開発を行っている印象で、座談会で相手をしてくれた若手社員がしっかり自分の意見を持っていたんですよね。本人の口から「この会社はいいよ」と言ってくれたことが入社の決め手になりました。実際に中で働いている人が良い会社だと言っているのは、心強いですよね。   —— 実際に入社してから、会社の印象に変化はありましたか？   本当にこの会社に入って良かったなと今でも思っています。私が抱いた第一印象に間違いはなかった、と。 具体的には、入社前から思っていた人の雰囲気が良いところは変わらず、 配属となった 開発部署で も 頻繁に話しかけてくれたり、困ったときには気にかけてくれ たりしました。OJT担当の 先輩もとても親身になってくれて、新人ながら良い会社に入ったなぁと感じていました。 雰囲気は良くても決してゆるいわけではなく、仕事内容はチャレンジングなプロジェクトが多くありました。学生時代はWeb系のアプリ開発などを勉強して いましたが 、1年目に携わったのは全く経験のなかった販売管理システムのサーバーサイドのアプリケーション開発。2年目以降も ビッグローブ 光の販売管理システムを中心にサーバーサイドエンジニアとして関わり、部署異動してからはメディアシステム開発のための情報分析業務を担っています。 初めて関わる仕事やプログラミング言語がほとんどで、勉強することがとても多かったのが正直なところです。   —— 人に恵まれた環境で、チャレンジングな仕事ができることは成長にもつながりますよね。それを一番感じたタイミングはいつですか？   入社してから3年目を過ぎた頃ですね。自社サービスであるビッグローブ光の追加機能の開発プロジェクトを1つ任せていただきました。設計からテスト、リリースまでメインで担当させてもらい、外部の協力会社などとも連携して進めていくリーダー的なポジションを担ったのです。 しかし、当時の私はリーダーを任されるのに抵抗がありました。学生時代にうまくいかなかった経験があり、上司から頼まれたときも「本当に私がやるの？」と物おじする気持ちになったのが正直なところです。 このときの成長ポイントは、その上司が失敗してもいいからチャレンジしてみようと背中を押してくれたこと。自分で考えて行動し、困ったらいつでも相談することができ、他のメンバーもフォローしてくれる体制が用意されていました。 他にも、プロジェクトの進行スケジュールを自分で立てたときは、勤務時間外も稼働しないと納期に間に合わなそうで悩んでいたのですが、打開策を自分で考え改善してみようと言われました。それまで上司の指示通りに動いていれば良かったのでそのときは大変でしたが、結果今では当たり前のように自分の頭で考えて全体を組み立てることができるようになりました。 そうやって本人の成長を促してくれる上司だったので次第に自信がつき、リーダー業務も苦手意識がなくなりました。   成果を出すために、自分の得意分野でパフォーマンスを発揮する —— 小林さんは部署異動も経験されています。そのきっかけは何だったのでしょうか？   BIGLOBEに入社し5年が過ぎ、以前1度は経験したことがある業務が増え、そろそろ違うことを経験したいなと思ったことがきっかけです。上司と席が近かったので、ラフに相談に乗ってもらったり、面談のタイミングで今後のキャリアについて話し合ったりしました。 転職して違う会社で働くという選択肢を検討する方もいると思いますが、私の場合はBIGLOBEの会社自体も働いている人も好きだったので、その選択肢はありませんでした。何かが嫌だということがなかったので、部署異動であれば、好きな会社でまた新たな仕事ができると思い、あとは上司に任せて次の部署が決まりました。   —— 実際に異動してみていかがでしたか？   同じ会社でも部署が変われば雰囲気も開発手法も違うんだなという新鮮さがありました。例えば、 ビッグローブ 光の部署はチームで密になって課題解決にあたっています。一方、メディアシステム開発グループは個々人のスキルに任せるところは権限を委ねながら社内の関係者と仕事を進める傾向にあります。いろいろな仕事の仕方を勉強でき、異動しないとわからないこと、経験できないこともたくさんあるなと思ったのが感想です。 また、仕事内容もだいぶ変わりました。現在はビッグローブ光などのサービスのデータを集計し、社内のシステムに連携して流し込んだりレポートを提出するような業務を主に担当しています。社内の担当者が日次でデータを確認したいといった要望に応えたり、システムトラブルが起きてもデータ集計を継続できるようにしたりと、サービスが円滑に稼働するように支えている縁の下の力持ち的存在です。   —— サーバーサイドエンジニアはサービスのインフラを担う、お客さまからは一見分かりづらい仕事ですよね。小林さんは仕事のやりがいをどこに感じていますか？   そうですね。直接お客さまとつながるような仕事ではないので、システムを正しく問題なく動かすことを常に考えています。その中で私の場合は、設計から携わったシステムや機能がリリースできて問題なく動いたときがやはり嬉しいですね。自分で考えたことの答え合わせをしている気分で、もしトラブルが起きたときでも何がダメだったのかを探し、次は気をつけて作るように意識しています。そういった仕事のスタイルが自分にはあっているなと感じています。 また、最近はチームで開発することが多いので、リーダーとして一人ひとりの得意なことややりたいことを任せることで成果を出していくことが楽しいです。自分の苦手なことも、人によっては得意なケースはありますよね。例えば、 資料作成の場合、 私は80点レベル のものなら時間をかけずに 作れ るの ですが、最後の100点まで持っていくには細かいミスをしてしまうこともあ ります。そんな時は 、 最終 チェックが得意な人に任せて います 。このように、チームで動くことで成果を出すことは働きがいにも繋がっています。   挑戦を後押しする仲間がいる、カルチャーがある ——働く環境面も気にされる方がいます。小林さんはBIGLOBEのそういった面についてはどのように感じていますか？   BIGLOBEは協力的な人が多い会社だと思います。新卒入社のため他社と比較はできませんが、話を聞いてくれたり、自分 に 何ができるかを考えてくれたり、一緒に悩んでくれる人が多く、それが問題解決にもつながる職場なのでとても気に入っています。女性だから、男性だからと気を遣うことなく接してくれるのもありがたいですね。   —— やっぱり“人”がポイントですね。   そうですね。誰かに言われた仕事をただやるだけだと不満が生まれますが、BIGLOBEは自分なりに考えて行動する人が多いことが、こういった環境の良さを作っているのではないでしょうか。私も上司からの指導で、自分で考えて仕事をする方法を教わったので意識できるようになりました。みんな優しいので、違う部署の人や役職の高い人にも気軽に自分の悩みを聞いてもらったりと頼ることも多いのですが、そのバランスが心地いいですね。 あとは、やりたいことにチャレンジしやすい制度やカルチャーがあることも魅力です。   —— どういった点でそのように感じていますか？   例えば、私は本業とは別に社内の「新サービス創出活動」に参加しています。新しい事業を考え社内で発表した後に事業化に向けて動いていくプログラムで、自分の部署では本業と並行して取り組むことを奨励されています。 私は医療現場のインターネット関連サービスを検討しており、これは自分自身が病院に入院したときの実体験から、こんなサービスがあったらいいなと思ったアイデアです。今まではエンジニアとして技術のことばかり考えてきましたが、事業化するなら誰が必要としていて、お金なども含めたビジネスモデルはどうする？といった普段の業務とは違う点に頭を使うので刺激が多いですね。 社内には企画や営業担当など、この分野に詳しい人がたくさんいるので、社内ブログで呼びかけたら実際に声をかけていただき打ち合わせを 重ねています。部署を超えて 助けていただ ける のも、このプロジェクトの面白いところです。結果、BIGLOBEならやりたいことができるという実感にもつながっています。   —— それはいいですね！ 最後にBIGLOBEに興味を持っている方に向けてメッセージがあればお願いします。   当社には ビッグローブマインド という社員が作ったフィロソフィーがあります。現在、11個あり、その全て大切な価値観ですが、中でも「変化に挑む」が私の気に入っているキーワードです。 自分が何かやりたいと思いついたとき、それがやったことがないことでも挑戦させてくれる社風なので、変化に挑みたい方はぜひBIGLOBEに来て欲しいですね。 あと、個人的には女性のエンジニアにもっと加わって欲しいと思っています。BIGLOBEには、部署やグループを越えたエンジニア女子のコミュニティがあり、女子会なども開催し横のつながりができています。女性エンジニアは業界内でまだ少ない分、このつながりはとても貴重なので、ぜひ仲間に加わっていただけると嬉しいですね。   —— 本日はありがとうございました！   現在、BIGLOBEでは2025卒向けの新卒採用活動を実施中です！ エンジニア職 / 職種不問向けのサマーインターンシップもそれぞれ募集開始 していますので、少しでもBIGLOBEに興味をもっていただけた方は、ぜひ下記URLよりマイページ登録をお願いいたします。   https://mypage.3050.i-webs.jp/biglobe2025/applicant/login/baitai-entry/entrycd/Style ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

GitHub Actionsで「自分の困りごとを解決」するハッカソン形式の社内研修を開催しました。過去に3度GitHub Actionsの研修を実施しましたが、最も高い評価となりました。 この記事では、研修の内容はもちろん、研修の準備を通じて得た学びについてお話しします。 研修の内容 第一部 事例共有 第二部 アイデア出し 第三部 実装 研修の結果 研修の準備で得た学び まとめ BIGLOBEの網干です。 GitHub Actionsを活用できる人を増やそうとGitHub Japan様とBIGLOBEでミニハッカソン形式の社内研修を開催しました。実はこのイベントの前にも2回の研修を実施してきました。1回目は講義形式、2回目はサンプルプログラムを動かすハンズオンでした。1回目では「知識はついたが実装をイメージしにくい」、2回目では「実装はイメージできたのでなにか作りたいが、実際の業務で何を作ればいいかは思い浮かばない」というアンケート結果となりました。 そこで3回目はハッカソン形式とし、参加者自身が課題を持ちより、その解決策を考えてもらうワークショップとして設計しました。GitHub Japan様のプロフェッショナルサービスを利用して、GitHub社員の方（社員をHubberと呼んでいるそうなので以降Hubberと表記）にも参加していただいています。その結果、満足度を測る指標であるNPS（ネットプロモータースコア）は100となり、受講者から非常に高い評価が得られました。 研修の内容 今回の研修は次の3ステップで実施しました。 第一部 事例共有 まず最初に社内の有志やHubberが普段GitHub Actionsをどう使っているか、具体的な事例を紹介してもらいました。CI/CDに使われるのが当たり前のGitHub Actionsですが、あえてCI/CD以外の事例を中心に取り上げ、この後に続くアイデア出しでの視野を広げるのが目的です。 例えば、GitHub IssuesやGitHub Projectsと連携してタスク管理や議事録作成を半自動化する事例、GitHub APIを使って自分たちの開発パフォーマンスを把握するFour Keysを計算する事例、音楽のプレイリストを作成する事例などが紹介されました。 今回の研修は、バリバリ自動化を進めている人だけでなく、どうやって自動化すればよいかイメージしづらいメンバーも対象にしています。具体的な事例を知ることで、参加したメンバーは大きな刺激を受けたようです。 第二部 アイデア出し アイデア出しでは、参加者を3〜4名に分け、そこにメンター役のHubberを一人ずつ加えたグループを作りました。次に参加者それぞれに仕事やプライベート問わず、身近な困りごとをふせんに書き出してもらいます。書き終わったらグループ内で共有し、それぞれの困りごとに対してGitHub Actionsを使った解決策をグループ全員で考えていきます。 解決策が実現可能かといった技術的な疑問についてはメンターに相談できるようにしました。Hubberの皆さんはとてもフレンドリーで、ときに和やかに、ときに議論を活性化しながら、アイデアを膨らませてくれました。 第三部 実装 最後に第二部で出た解決策をグループで一つ選んで実装をします。「ゴミ出し日をタスク化」といった日常的なものから「監視アラートの通知先をプルリクエストで追加・削除」といった業務に関する高度なものまで幅広いアイデアが選出されました。 実装の進め方はグループごとに様々です。メンバーそれぞれに役割を振って実装するグループもいれば、コーディングする様子を大きなモニターに写してモブプログラミングするグループもいました。最後に各チームが成果を発表し、研修は終了しました。 研修の結果 第1回の研修から取っていた受講者アンケートでは、10点満点の研修のオススメ度の結果が大きく改善し、NPSは-20→44.44→100と大幅に向上しました。 研修で良かったことについては「実際に手を動かすと分からないことも多く出てくるが、その場でHubberに聞けてすぐに解決できた」「GitHub Actionsを実際に使った事例を聞けてアイデアを思いついた。その後すぐにハンズオンに入ったので、そのアイデアをすぐに実装できた」といった意見がありました。 また嬉しいことに研修開催後、仕事の課題を解決するためにGitHub Actionsを活用する人もでてきました。 その一方で、改善すべき点もあげられました。例えば、GitHub Actionsの経験有無によらずバラバラなメンバーでグループを作成したため「研修で分けられたグループに知識がある人が多く、質問するのが自分だけの状態になってしまったため、質問しにくかった」という意見がありました。研修の目的に「GitHub Actionsを活用できる人を増やす」ことを置いていたのですが、質問しづらい状況を作ってしまったことについて反省しています。次の研修にぜひ活かしていこうと思います。 また、研修に参加しやすくなるよう研修時間をできる限り短く設計したのですが「実装の時間が足りなかった」といった意見がありました。弊社は温泉地でワーケーションを実施するONSEN WORKを事業として推進していますが、思いっきり開発に専念できる開発合宿も企画していこうと思いました。 研修の準備で得た学び 私は今回、初めて社内研修を主催しました。そこで得た最も大きな学びは「経験主義」についてです。というのも、研修の準備段階で「ああでもない、こうでもない」と不安を抱えていた時、考えていた研修内容を一度小さく試してみたことでその不安が簡単に解消したためです。 研修の企画段階では、「自身の困りごとをGitHub Actionsで解決するハンズオン」という内容がすぐに決まり、アジェンダまで順調に考えることができました。しかしその後「参加者に出してもらった困りごとに対し、受講者がその場で都合よくGitHub Actionsを使った解決策を思いつくことができるのだろうか？」と不安がよぎり、手が止まってしまいました。結局一週間ほど頭の中で考えましたが結論が出ず、周囲の先輩社員に相談することにしました。 「この内容で研修が上手くいくと思いますか？」 すると一人の先輩社員から 「まず周囲の人を集めて一回試してみたら？」 とアドバイスを頂きました。そこで早速身近な人を集めて「解決策のアイデア出し」の部分をやってみることにしました。その結果、参加者はほとんどの困りごとに対して解決策を出すことができました。この時分かったことは「案外多くの困りごとに対してプログラミングを使った解決策が思いつく。GitHub Actionsは定期実行、手動実行、様々なGitHub上のイベントをトリガーとすることができたり、他のサービスと連携できるため様々なアイデアに応用しやすい。」ということでした。これに気がついて以降企画内容に自信を持てるようになり、周囲の助けを借りながら最後までやり切ることができました。 普段の開発業務ではスクラム開発をしていて経験主義については知っていましたが、恥ずかしながらこのような形でそれを実践することは思いつきませんでした。日頃「ああでもない、こうでもない」と悩んだら小さい規模で試してみることで不安を解消し、自信を持ってものごとに取り組んでいこうと思います。 まとめ 講義形式の研修と比較して、とても高いオススメ度になった「自身の困りごとを解決するハンズオン研修」、ぜひ試してみてはいかがでしょうか。組織全体で開催するのが難しくても、身近なメンバーとやってみるだけで、様々な学びがあると思います。 企画内容に悩んだら一度小さく試してみるのがオススメです。私の場合「うまくいきそう」「うまくいかなそう」といったことが分かり、次に何をすべきか見えてきました。この「経験主義」の考え方を、研修や業務に限らず、色々なことに応用してみようと思います。 ※ GitHubは、GitHub, Inc.の商標または登録商標です。

こんにちは。BIGLOBE Style編集部の吉田です。 BIGLOBEの開発部門（プロダクト技術本部）では、新卒入社社員向けに「新人エンジニア育成プログラム」を1年かけて実施しています。 今回の記事では、プログラムを終え2年目を迎えた5名のエンジニア（2022年4月入社）による成果発表会の様子をお届けします。 2022年度新卒入社エンジニア はじめに BIGLOBEのエンジニア新人育成とは 成果発表。何を経験し、どのような学びを得たか プロダクト技術本部長と社長から総評 最後に 2025年卒向け新卒採用について はじめに この成果発表会は、1 年間お世話になったコーチや上司に感謝を伝えるとともに、幹部にその成長ぶりをアピールする節目のイベントです。 今年度の新入社員も聴衆として参加し、一人前のエンジニアとしてスタートラインに立った先輩たちの姿をしっかり目に焼き付けます。 この会に対して発表者からポジティブな感想が多く寄せられましたので、その一部をご紹介します。 「1年間の取り組みを振り返ることで確実に成長していることが実感でき、自信につながった」 「振り返ることで、どのような経験値を得ることができたのかを整理することができた」 「あの時こうすればよかった、という反省点も見つけられる機会となった」 「自分の経験を言語化することでアウトプットの学習にもなった」 「1年間お世話になった方達への感謝を伝える良い機会となった」 「多くの方に発表を聴いていただき、フィードバックを得られる貴重な機会になった」 「幹部の方々を前にしての発表は、プレゼンに慣れるとてもいい経験になった」 BIGLOBEのエンジニア新人育成とは ここで、新人エンジニア育成プログラムについてご紹介します。 2022年度の新人育成プログラムは「 企画・開発メンバーが一体となってやりたいことをすぐ形にするチーム体制へ 」というビジョンのもと作成しました。 週4日は所属グループでのOJT（On the Job Training）です。セルフマネジメントの基礎を体得するため、実務を通じてタスク管理ふりかえりを実践します。週1日は集合型の研修です。研修プログラムに従って技術を磨いたり、育成担当のメンターと課題に感じていることを共有してつまずきを早期に発見し対処します。 どのような研修プログラムかといいますと… BIGLOBEを良く知りエンゲージメントを強めるための「リーダーインタビュー」と「BIGLOBEノウハウ講義」。そして、自らやりたいことをすぐ形にする内製開発スキルを磨く「AWS（ Amazon Web Services ）の資格取得」「共通スキル研修」「チーム開発演習」に取り組みます。 詳しい内容はこちらで紹介しています。 style.biglobe.co.jp style.biglobe.co.jp プログラムにある「チーム開発演習」は毎年目玉のひとつ。新人エンジニアが一丸となり、研修で学んできた 要件定義、設計、開発、テストなどの工程を アジャイルに繰り返します。 2020年度は社員同士で感謝の気持ちを送り合うツール「 まいぽ 」、2021年度は「 スキル診断ツール 」を作ってもらいました。 そして2022年度に作ったのは 「学び続けるのが当たり前」という雰囲気づくりに貢献する「勉強会カレンダー」 。社外の魅力的な勉強会を見つけた仲間が「勉強会カレンダー」へ投稿することで、興味のある勉強会に出会い、参加し、学び合うことを目的とした社内サービスです。 『ビッグローブマインド』 の「継続的に成長する」にぴったりですね！ さて、ここからは、成果発表の内容と上長からのフィードバックを少しですがレポート形式でご紹介していきたいと思います。   成果発表。何を経験し、どのような学びを得たか 荒川 晴哉 (あらかわ せいや) プロダクト技術本部 クラウド技術部 クラウドストラテジー・コンサルグループ 担当業務：DC基盤のAWS推進、DB運用 社内のクラウド化を推進する組織横断組織CoE（Center of Excellence）のメンバーである荒川は、主にAWSの社内教育を主催。日程調整から告知、司会まで回数をこなすうちに、苦手だった「人前で話すこと」にも抵抗がなくなったそうです。 「社内アンケートをとり、希望の多かった内容でAWSさまにご協力いただき、これまでにない勉強会を新しく企画しました。講師のAWSさまと自分とで掛け合いをするという新しい形式で、好評を得ることができました」 入社後の７月にはAWS Certified Solutions Architect - Associate（ソリューションアーキテクト／SAA）を取得。勉強会でAWSを教える際に説得力が増したといいます。 最後に「この1年のプログラムを経て自発的に勉強するようになった」、「一人前のエンジニアとして自信を持てるよう、今後もスキルを磨いていきたい」と語りました。 執行役員常務　プロダクト技術本部 副本部長　高宮 高宮　「クラウド化の推進役であるCoEの教育担当として、自らがAWSの知識を身に着けつつ、その知識を社内メンバーに提供するという役割を果たしてくれました。教える立場は難しい場面もあったかと思いますが、グレードの高い勉強会を企画したことでAWSの知識はかなりついたと思います。これからはさらに加速して自ら成長すると同時に、後輩たちに成長の場を与えていただきたいと思っています」 坂川 巧将 (さかがわ こうすけ) プロダクト技術本部 サービス運用部 運用グループ 担当業務：24h/365dシステム運用周りの業務改善、グループの広報活動 入社時はAWSやシステム運用については未知だったという坂川。今では研修や実際の仕事を通じてさまざまな知識を得ることができたといいます。 「障害情報を迅速に収集するため不要なアラームを大幅に削減しました。結果的に、月40hのホワイトスペースを作るという副次的な効果も得られました。その他、社内体制にマッチした運用監視を設計したり、オペレーションセンターの見学会を数多く開催し、運用業務への理解を促進することができました。これらの実現にあたっては関係部門の協力が不可欠です。今後もサービスの安定運用に貢献するために、交渉、調整、説明能力を高め、よりよい運用環境の構築に努めたいと思います」 AWS（SAA）やLinuxの資格も取得し、日々の業務に役立てていると語りました。 高宮　「運用グループは、ネットワークの運用、AWSの運用、その上で動いているサービスの理解も必要となるので非常に難しく、幅広い知識が求められます。今後、ぜひネットワークの資格にも挑戦してください。今回経験した24h/365dチームは重責を担っています。その業務について、これからも社内中に宣伝していただきたいと思います。今後の活躍にも期待しています」 濱島 聡一郎 (はまじま そういちろう) プロダクト技術本部　基盤系システム部 ＢＰＲ・会計システム開発グループ 担当業務：会計システムの開発、保守、運用 濱島は面白い経歴の持ち主で、文系学部から理系大学院へ理転しています。 配属当時は会計についての知識がなく不安があったものの、会計システムのインボイス対応、業務自動化ツールの保守運用、サーバの管理・運用改善など、ひとつの分野に絞ることなくさまざまな経験をしました。 「金銭が関係する責任のある業務であり、品質を担保することが重要です。高い品質を実現するためには、業務を理解した上で、視座を高くしさまざまな側面から検討する必要があると学びました。 今後は、 上流工程から下流工程までを一気通貫で行える人材を目指します。現状の業務はもちろんのこと、多岐にわたる分野の知識を獲得し続け、幅広い視点から課題の発見、解決ができるようになりたいと思います」 AWS資格はSAAを取得。また、上司の勧めで通常業務以外に「新サービス創出プログラム」へも参加し、日頃の業務では経験のできない サービス企画やユーザーヒアリング、外部企業との情報交換なども行っています。 プロダクト技術本部 副本部長　水守 水守　「新人の1年間は非常に大切な期間で、この時期をどう過ごしたかが今後のビジネスキャリアを左右すると思っています。濱島さんはエンジニアの知識だけではなく会計という非常に難しい概念も吸収しつつ、会計システムの開発・運用業務にしっかり取り組んでいただきました。 また、ツールを自動化して工数を大幅に削減するなど、会社に貢献して活躍しています。エンジニアのスキルは指数的に成長していくものです。先輩の立場になっても安心せず、どんどん知識を吸収してBIGLOBEを支える人材になってください」 津田 英明 (つだ ひであき) プロダクト技術本部 サービスデザイン部 サービスデザイン1グループ 担当業務：ビッグローブ光に関わる業務設計、運用 学生時代はネットワークの研究をしていたという津田。しかし、入社後配属となったのはサービス要件を整理する「業務設計」という全くの未経験の部門。手探り状態の なか、OJTを通してサービスの仕様や構成するシステムの動作、関係各所の役割や責務を頭に叩きこんだといいます。 結果として、エンジニアの知識を活かして運用で用いるマクロの改修を実現しただけでなく、サービス仕様への深い理解が認められ、新しいプロジェクトの主担当を担当するまでに成長しました。 「重要なプロジェクトにも参画させていただき、特に興味があったIPv6オプション改善はネットワーク分野の知識を活かしながら楽しく取り組むことができました。その他多くのプロジェクトに関わらせていただきましたが、全てにおいて関係者との密なコミュニケーションが重要だということを学びました」 業務の幅を広げるためにAWSの資格も取得。 目指すところは、自分ができる範囲を企画から運用まで全ての工程に広げ、先輩たちのようにコミュニケーションのとれる開発者になりたいと語りました。 リアライズ事業本部 副本部長　黒川 黒川　「サービスを提供するためのプロセスの中で一番重要なワークフロー設計を経験してもらいました。”さまざまなステークホルダーの意図をくみ取りながら、お客さまにサービスをお届けするにはどうしたらいいか”を学べたのではないかと思います。 これから幅広い工程に携わって成長を重ねると宣言がありましたが、この1年間の経験に基づいて、多方面とコミュニケーションを取りながら実践して欲しいと思います」 山根 壮一朗 (やまね そういちろう) プロダクト技術本部 サービスオペレーション部　開発グループ 担当業務：コンタクトセンターシステムの設計、開発、品質維持 現在、開発グループに所属する山根ですが、入社時の配属はビッグローブ光の開通センターの運用を担当する部門でした。当初は運用についての知識もなく本当にエンジニアとしてキャリアを積めるのか不安だったそうですが、今となっては運用という業務を通じて現場目線・お客さま目線を理解し、コミュニケーション能力が養われたといいます。 「お客さまにお申し込みいただいてから開通するまでをサポートさせていただくのが開通センターです。配属3カ月で委託先販路をメインで担当し、毎日のように運用についてやりとりをしたり、センターの方々との交流やお客さまからのエスカレーションに対応したり、さまざまな経験を通じて”現場目線”を持つことができました。それを強みに、現場との認識の齟齬をなくしていける開発者を目指していきます」 社外大手企業との合同研修にも積極的に参加し、広くアンテナを張って取り組んだこの1年。AWSの資格習得でも勉強開始後3カ月でSAAを取得し、社外ハンズオンイベントに参加するなど、自主学習の成果をアウトプットしました。 黒川　「配属当初はエンジニアなのに何故センター運用業務なのかと迷いがあったのかと思います。開通センターはBIGLOBEを選んでくださったお客さまが一番最初にコンタクトをとるところです。その業務の改善をいかにしっかりやらなくてはならないか、十分理解できたのではないでしょうか。開通センターでの運用業務の経験は得るものがたくさんあったと思いますので、開発部門でも現場目線を強みに、実践し、成長を続けてください」 プロダクト技術本部長と社長から総評 取締役執行役員常務　プロダクト技術本部長　鴨川 鴨川　「1年間お疲れさまでした。そして、育成に携わったみなさま、本当にありがとうございました。この会を毎年主催していますが、毎回気にしているのが配属のミスマッチという言葉です。我々は、この1年間で最も成長できる部署はどこかを考えて配属を決めているので、あえて希望ではない部署になることもあります。「どうしてこの部署なのか」と思わないでいてくれたらいいと内心思いながら送り出していますが、今回のプレゼンを拝見した限りでは、配属は間違っていなかったのだと安心しました。 2年目以降は、成長するための手段を自分で選んでいく必要があります。これからはお世話になった育成担当者に恩返しする気持ちで業務にあたってください。また、今年の新入社員は今日の先輩の姿をみて、1年後にどうなっていたいか思うところがあったと思います。ぜひ後輩の相談に乗るなどして『チームビッグローブ』で頑張ってください」 代表取締役社長　山田 山田　「みなさん、発表お疲れさまでした。この1年でずいぶん成長したかと思います。水守さんが言っていた通り、エンジニアの能力は指数的にあがっていきます。重要なのはこれからどこまで伸ばせるかということ。ぜひ目標に向かって引き続き頑張っていただきたいです。 彼らの周りのみなさんも、どのようなところに変化があったのか、気づきがあれば本人たちへフィードバックしてあげてください。それが彼らのモチベーションにつながるはずです。 今回社長に就任して初めて成果発表会に参加しましたが、とても良い機会だと思いました。今後もぜひ続けてください」 最後に 最後に2023年度新人エンジニアと記念撮影をして、発表会は無事終了しました。同期同士切磋琢磨した濃密な研修期間、本当にお疲れさまでした！育成プログラムや目の前の業務一つひとつに前向きに取り組んだ経験が、今後のキャリアの糧となります。この1年で得た学びを業務に活かして成長を続けてくれることと思います。今後の活躍も期待しています！ 以上、2022年度入社新人エンジニア成果発表会のレポートでした！ 2023年度新卒入社エンジニアと記念撮影 2025年卒向け新卒採用について 現在、BIGLOBEでは2025卒向けの新卒採用活動を実施中です。 エンジニア職 / 職種不問向けのサマーインターンシップもそれぞれ募集開始していますので、少しでもBIGLOBEに興味をもっていただけた方は、ぜひ下記URLよりマイページ登録をお願いいたします。   https://mypage.3050.i-webs.jp/biglobe2025/applicant/login/baitai-entry/entrycd/Style ※右下にございます「初めての方はこちら」より、新規登録をしてください。   ※ Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

AWS Fargate コンテナの Graviton2 移行について実例を交えてご紹介します。 こん**は。 新型コロナウイルス感染症は5類感染症に移行となりましたが、読者の皆様はお変わりなくお過ごしでしょうか。お久しぶりの投稿となります、プロダクト技術本部の江角です。 前回執筆させていただきました Gitログの記事 では「ほぼフルリモート！」とお伝えしていましたが、近況に変化がありましたので少しお話できれば、と思います。 BIGLOBEは４月より組織改編等もあり、「リアルでの会話、議論を重視したい」という流れのもと、今までは疎らだったオフィスに人が戻って来つつあります。 私が今所属しているグループでは「会議が被る曜日はメンバーで出社を揃えよう」という試みも実施していたりします。 『ほぼフルリモートだと聞いていたのに全然違った！😡』ということが無いよう、あくまで直近のご報告とさせていただきます。 さて本題ですが、 以前のチーム内で試行錯誤し、AWS Fargate コンテナを Graviton2 へ移行したノウハウを記事として公開します。 Graviton2 がわかった気になる基本から、ちょっと凝った応用まで、どどーーーん！とボリューミーな内容でお届けします。 目的に応じて実践できそうな箇所がありましたら是非やってみてください！ 想定読者 AWS Fargate コンテナを Graviton2 へ移行させてみた Graviton2 とは Graviton2 のメリット 実運用で判明したコスト削減効果 実践編 【初級】タスク定義 を AArch64 対応させる 【中級】AWS Codebuild で AArch64 イメージをビルドする 【上級】AArch64 の Corretto17 イメージ でビルドする 全体の流れ 1. AArch64 の イメージを作成する 2. Corretto 17 対応させて、再度イメージを作る 3. AWS CodeBuild の設定を変更する 【応用】マルチアーキテクチャイメージを AWS CodeBuild (バッチビルド) で作る マルチアーキテクチャイメージと作り方 全体の流れ 1. buildspec-image.yml の作成 2. buildspec-manifest.yml の作成 3. buildspec-batch.yml の作成 4. AWS CodeBuild の設定 【Appendix】Java17 のマルチアーキテクチャイメージをビルド 1. codebuild-runtime の Corretto 17 をマルチアーキテクチャイメージにする 2. buildspec-image.yml を修正する 3. AWS CodeBuild の環境設定 最後に @counter-style circled-decimal { system: numeric; symbols: '0' '\2460' '\2461' '\2462' '\2463' '\2464' '\2465' '\2466' '\2467' '\2468'; suffix: ' '; } ol.circled-decimal-marker { list-style-type: circled-decimal; } 想定読者 AWS Fargate の料金を安くしたい方 AWS CodeBuild を用いてビルドしている方 Java17 プロジェクトで、まだ Graviton2 へ移行していない方 AWS Fargate コンテナを Graviton2 へ移行させてみた 本セクションでは、Graviton2 へ移行するにあたっての前知識やメリットについて記載します。実践編は後ほど。 Graviton2 とは AWS が独自開発した ARM ベース、第二世代のプロセッサです。 ARM に聞き馴染みの無い方も、お持ちのスマートフォンやタブレットに利用されている CPU は ARM ベースで、小型であるにもかかわらず高性能で省電力なことが特徴とされています。 ちなみに、最近価格高騰でなかなか手が出せない Apple 社の M2 チップ搭載 MacBook も、Apple 社が独自開発した ARM ベースのプロセッサです。 本文にて用語が混在するため、 以下ざっくりとした理解でお読みください。 従来型の CPU x86_64 ≒ AMD64 ≒ Intel64 コスト効率が良い CPU (例: AWS Graviton2, Apple M2) AArch64 ≒ ARM64 Graviton2 のメリット ズバリ「コスパが良い」ということです。 具体的な数字としては 20% 低費用で、コストパフォーマンスが最大 40% 向上 するとのことです。 aws.amazon.com コンテナ化などのサーバーレス化が主流となっている中、AWS Fargate は継続して動かすユースケースが多いので、お財布に優しいだけでなく性能まで向上してくれるのであれば今すぐ導入しない手はありませんね。 実運用で判明したコスト削減効果 私達のチームでは 2022年9月に AWS Fargate コンテナを Graviton2 へ移行しました。 月ごとの Amazon ECS 利用料金 をまとめたものは以下のグラフの通りです。 一部飛びぬけている月もありますが、平均約25%のコスト削減が出来ているように見えます。 円安の影響で 110円/$ から 137円/$ へ上がったとしても、 Graviton2 へ移行することで、今まで通りのコストで運用できますね。 ※私達のチームにおける費用軽減効果であり、その効能を保証するものではありません！ 実践編 ここからは実践編です。 実際に動かすまでを目的としていますので、ソースコードや画像が多くなります。 一部、公式イメージを利用することで対応が不要になったセクションも敢えて記載しています。Corretto 21 に応用できる可能性もあるため、是非目を通して頂けると嬉しいです。 【初級】タスク定義 を AArch64 対応させる まずは、Amazon ECS で使用するタスク定義を AArch64 対応させましょう。 マネジメントコンソールから操作する場合、 Linux/ARM64 を選択するだけで完了です。 terraformでタスク定義を管理されている場合は、 aws_ecs_task_definition に 以下 runtime_platform を追加して terraform applyしてください。 resource "aws_ecs_task_definition" "graviton2_test" { runtime_platform { operating_system_family = "LINUX" cpu_architecture = "ARM64" } } registry.terraform.io AWS Fargateの設定としては以上で、一応動きます。 でも、AArch64 に対応したコンテナイメージを用意しないといけないのでそれは【中級】で記載します。 【中級】AWS Codebuild で AArch64 イメージをビルドする 続いて、上記作成した AArch64 対応したタスク定義で動かす AArch64 対応のイメージを AWS Codebuild で作れるようにしましょう。 新規、及び既存のビルドプロジェクトより、 イメージを aws/codebuild/amazonlinux2-aarch64-standard:3.0 に設定すれば完了です。 ⚠️最新のイメージとバージョンについては以下の AWS ドキュメントを参照してください。 docs.aws.amazon.com マネジメントコンソールから操作するとこんな感じです。 terraformでビルド設定を管理されている場合は、 aws_codebuild_project の environment . image を AArch64 対応イメージに、 type を ARM_CONTAINER に変更し、 terraform applyしてください。 resource "aws_codebuild_project" "aarch64_build" { ・・・ environment { compute_type = "BUILD_GENERAL1_SMALL" image = "aws/codebuild/amazonlinux2-aarch64-standard:3.0" type = "ARM_CONTAINER" } ・・・ } registry.terraform.io 【中級】の内容は以上です。 Amazon ECS で動かすためのコンテナイメージが作れたので、これで一通りの運用は可能となります。 【上級】AArch64 の Corretto17 イメージ でビルドする 2023年5月現在、AWS CodeBuild ランタイムで AArch64 の Corretto 17 イメージが使えるようになりました。 docs.aws.amazon.com 2022年9月時点で、Corretto 17 は x86_64 対応イメージしか利用できなかったため、 Java17 を開発で使っていた私達のチームでは AArch64 対応 Corretto 17 を自作し、Amazon ECR に登録。作成した AArch64 対応 Corretto 17 をランタイムに用いて AWS CodeBuild で Java17 のプロジェクトをビルド、デプロイしていました。 ⚠️ここでは当時の手法をお伝えしますが、公式イメージが利用可能な場合は、AWS CodeBuild の設定からマネージド型イメージで Amazon Linux 2 AArch64 standard:3.0 を設定すれば問題ありません。 【上級】の以降で説明する、イメージを自作したりカスタムイメージを設定したりという手順は不要となります。 全体の流れ 私達のチームで行っているデプロイ構成はこんな感じです。 事前準備として AArch64 の Corretto 17 を作成し、Amazon ECR (runtime) に push しておきます。 AWS CodeBuild ではカスタムイメージ機能を用い、①で作成した AArch64 Corretto 17 を用いて Java17 の AArch64 イメージをビルド。イメージを Amazon ECR (application) に pushします。イメージの definition.json を Amazon S3 に格納します。 Amazon S3 に definition.json が格納されたことを契機として AWS CodePipeline が走り、Amazon ECR (application) から 先ほど push したイメージを Amazon ECS の コンテナに デプロイして完了です。 ここでは AArch64 対応 Corretto 17 でビルドをするにあたって修正が必要な、①と②に絞って当時の内容をそのまま記載します。 1. AArch64 の イメージを作成する ①の前準備です。 AWS 公式の aws/aws-codebuild-docker-images より aws/codebuild/amazonlinux2-aarch64-standard:2.0 のイメージを作成します。 aws/aws-codebuild-docker-images リポジトリをクローン、 x86_64 の PC で AArch64 イメージ を作成するために docker buildx build コマンドでビルドしていきます。 ## リポジトリをクローン $ git clone git@github.com:aws/aws-codebuild-docker-images.git ## ビルド $ docker buildx build --platform linux/arm64 al2/aarch64/standard/ 2 . 0 -t codebuild-runtime:al2-aarch64-standard-2. 0 --load ⚠️PC スペックにも依存しますが、私達のチームではイメージ完成まで16時間程要し、 システムと Docker が使用するディスクに 20GB 程度の空きが必要でした。 続いて、作成したイメージを ECR に push しておきます。 詳細は省きますが、 ************ という AWS アカウントID に対して、事前に codebuild-runtime という Amzon ECR リポジトリを作成しておき、ビルドしたイメージを push する形となります。 ## Amazon ECR login $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ************.dkr.ecr.ap-northeast-1.amazonaws.com ## tagging $ docker tag codebuild-runtime:al2-aarch64-standard-2. 0 \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:al2-aarch64-standard-2. 0 ## push $ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:al2-aarch64-standard-2. 0 2. Corretto 17 対応させて、再度イメージを作る 1. で作成したイメージは Corretto 11 までしか入っていません。 そのため、1. で作成したイメージに、Corretto 17 を入れて再度イメージを作成するというのがここでやりたいことです。 まずは、任意のディレクトリ配下に Dockerfileと runtimes.yml を作成します。 今回は etc/docker ディレクトリ配下に作成するものとして記載します。 etc/docker/Dockerfile(クリックで展開) FROM ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:al2-aarch64-standard-2.0 ENV JAVA_17_HOME= "/usr/lib/jvm/java-17-amazon-corretto.aarch64" \ JDK_17_HOME= "/usr/lib/jvm/java-17-amazon-corretto.aarch64" \ JRE_17_HOME= "/usr/lib/jvm/java-17-amazon-corretto.aarch64" RUN set -x \ # Install Amazon Corretto 17 # Note: We will use update-alternatives to make sure JDK11 has higher priority for all the tools && export GNUPGHOME= "$(mktemp -d)" \ && curl -fL -o corretto.key https://yum.corretto.aws/corretto.key \ && gpg --batch --import corretto.key \ && gpg --batch --export --armor '6DC3636DAE534049C8B94623A122542AB04F24E3' > corretto.key \ && rpm --import corretto.key \ && rm -r "$GNUPGHOME" corretto.key \ && curl -fL -o /etc/yum.repos.d/corretto.repo https://yum.corretto.aws/corretto.repo \ && grep -q '^gpgcheck=1' /etc/yum.repos.d/corretto.repo \ && yum update -y \ && yum install -y java-17-amazon-corretto-devel \ && (find /usr/lib/jvm/java-17-amazon-corretto.x86_64 -name src.zip -delete || true) \ && yum install -y fontconfig \ && yum clean all \ && for tool_path in $JAVA_HOME/bin/*; do \ tool=`basename $tool_path`; \ update-alternatives --install /usr/bin/$tool $tool $tool_path 10000; \ update-alternatives --set $tool $tool_path; \ done COPY runtimes.yml /codebuild/image/config/runtimes.yml ENTRYPOINT [ "dockerd-entrypoint.sh" ] etc/docker/runtimes.yml(クリックで展開) version : 0.1 runtimes : android : versions : 28 : requires : java : [ "corretto8" ] commands : - echo "Installing Android version 28 ..." 29 : requires : java : [ "corretto8" ] commands : - echo "Installing Android version 29 ..." java : versions : corretto17 : commands : - echo "Installing corretto(OpenJDK) version 17 ..." - export JAVA_HOME="$JAVA_17_HOME" - export JRE_HOME="$JRE_17_HOME" - export JDK_HOME="$JDK_17_HOME" - |- for tool_path in "$JAVA_HOME" /bin/*; do tool=`basename "$tool_path" `; if [ $tool != 'java-rmi.cgi' ] ; then rm -f /usr/bin/$tool /var/lib/alternatives/$tool \ && update-alternatives --install /usr/bin/$tool $tool $tool_path 20000; fi; done corretto11 : commands : - echo "Installing corretto(OpenJDK) version 11 ..." - export JAVA_HOME="$JAVA_11_HOME" - export JRE_HOME="$JRE_11_HOME" - export JDK_HOME="$JDK_11_HOME" - |- for tool_path in "$JAVA_HOME" /bin/*; do tool=`basename "$tool_path" `; if [ $tool != 'java-rmi.cgi' ] ; then rm -f /usr/bin/$tool /var/lib/alternatives/$tool \ && update-alternatives --install /usr/bin/$tool $tool $tool_path 20000; fi; done corretto8 : commands : - echo "Installing corretto(OpenJDK) version 8 ..." - export JAVA_HOME="$JAVA_8_HOME" - export JRE_HOME="$JRE_8_HOME" - export JDK_HOME="$JDK_8_HOME" - |- for tool_path in "$JAVA_8_HOME" /bin/* "$JRE_8_HOME" /bin/*; do tool=`basename "$tool_path" `; if [ $tool != 'java-rmi.cgi' ] ; then rm -f /usr/bin/$tool /var/lib/alternatives/$tool \ && update-alternatives --install /usr/bin/$tool $tool $tool_path 20000; fi; done golang : versions : 1.12 : commands : - echo "Installing Go version 1.12 ..." - goenv global $GOLANG_12_VERSION 1.13 : commands : - echo "Installing Go version 1.13 ..." - goenv global $GOLANG_13_VERSION 1.14 : commands : - echo "Installing Go version 1.14 ..." - goenv global $GOLANG_14_VERSION python : versions : 3.9 : commands : - echo "Installing Python version 3.9 ..." - pyenv global $PYTHON_39_VERSION 3.8 : commands : - echo "Installing Python version 3.8 ..." - pyenv global $PYTHON_38_VERSION 3.7 : commands : - echo "Installing Python version 3.7 ..." - pyenv global $PYTHON_37_VERSION php : versions : 7.4 : commands : - echo "Installing PHP version 7.4 ..." - phpenv global $PHP_74_VERSION 7.3 : commands : - echo "Installing PHP version 7.3 ..." - phpenv global $PHP_73_VERSION ruby : versions : 2.6 : commands : - echo "Installing Ruby version 2.6 ..." - rbenv global $RUBY_26_VERSION 2.7 : commands : - echo "Installing Ruby version 2.7 ..." - rbenv global $RUBY_27_VERSION nodejs : versions : 10 : commands : - echo "Installing Node.js version 10 ..." - n $NODE_10_VERSION 12 : commands : - echo "Installing Node.js version 12 ..." - n $NODE_12_VERSION docker : versions : 18 : commands : - echo "Using Docker 19" 19 : commands : - echo "Using Docker 19" dotnet : versions : 3.1 : commands : - echo "Installing .NET version 3.1 ..." 尚、上記２ファイルは https://github.com/aws/aws-codebuild-docker-images のソースを参考に作成したもので、ライセンスは https://github.com/aws/aws-codebuild-docker-images/blob/master/LICENSE.txt に従います。 こちらの環境での動作確認はしておりますが、動作を保証するものではないことをご了承ください。 これで再度イメージをビルドします。 $ docker buildx build --platform linux/arm64 etc/docker -t codebuild-runtime:aarch64 --load Amazon ECR に push して完了です。 ## Amazon ECR login $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ************.dkr.ecr.ap-northeast-1.amazonaws.com ## tagging $ docker tag codebuild-runtime:aarch64 ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:aarch64 ## push $ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:aarch64 これで （自作の）AArch64 対応 Corretto 17 が Amazon ECR から利用可能になりました。 3. AWS CodeBuild の設定を変更する ②の設定として、AWS CodeBuild の環境設定を変更します。 カスタムイメージを選択し、2. で作成したイメージを使用します。 マネジメントコンソールからの場合、以下の設定にします。 terraformで管理されている場合は、 aws_codebuild_project の environment . image を 2. で作成したイメージに、 type を”ARM_CONTAINER”に書き換えて terraform applyしてください。 resource "aws_codebuild_project" "aarch64_build" { ・・・ environment { compute_type = "BUILD_GENERAL1_SMALL" image = "************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:aarch64" type = "ARM_CONTAINER" } ・・・ } registry.terraform.io もし AWS CodeBuild で初めて Corretto 17 を使うのであれば、AWS CodeBuild で使用している buildspec.yml も Corretto 17 に変更しておきましょう。 buildspec.yml(クリックで展開) ・・・ phases : install : runtime-versions : java : corretto17 ・・・ そのほかの設定について、特別な対応は不要なので、省略します。 繰り返しにはなりますが、公式の AArch64 対応 Corretto 17 を使えば、Amazon ECR に登録したりカスタムイメージを使ったりということは不要です。マネージド型イメージから公式イメージを設定することで使えるようになります。 以上、【上級】の内容でした。 本セクションの内容は既に古い内容ですが、将来的に AArch64 対応 Corretto 21 イメージがなかなか提供されずに困っている際などには使えるかもしれないですね。 【応用】マルチアーキテクチャイメージを AWS CodeBuild (バッチビルド) で作る 続いて応用編です。 例えば、多くのシステムで共通的に使う、サイドカーのようなコンテナイメージが存在しており、 メインのアプリケーションだけでなく、サイドカーのイメージも AArch64 に対応させないといけないケースがあるかもしれません。 サイドカーのコンテナイメージ は 共通部品のため、x86_64 を使いたいチームも、AArch64 を使いたいチームもいます。 そこで、スマートに解決してくれるのがマルチアーキテクチャイメージです。 マルチアーキテクチャイメージと作り方 マルチアーキテクチャイメージである【単一の Docker イメージ:タグ】 を指定すると、使われる環境（OS・CPUアーキテクチャ）を判別し、自動で最適なイメージを使ってくれるという便利なイメージです。 マルチアーキテクチャイメージは簡単に作成できます。 仮に、x86_64 と AArch64 の2種類のイメージがあるケースでは manifest 作成時に 2種類のイメージを指定して作成するだけで完成です。 更にAmazon ECR から利用したい場合は、x86_64 イメージと AArch64 イメージ、あと manifest を Amazon ECR に push するだけです。 👇手でやるとこんな感じ。割と簡単です！ ## aarch64 と x86_64 のイメージが存在する状態でスタート $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage aarch64 bf2578f2e983 7 weeks ago 8 .4GB ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage x86_64 74df2af5cae2 7 weeks ago 8 .4GB ## manifest を作成 $ docker manifest create ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:latest \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:aarch64 \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:x86_64 ## Amazon ECR へ push $ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:aarch64 $ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:x86_64 $ docker manifest push ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:latest 利用者側はマルチアーキテクチャイメージという点を意識せず、 ************.dkr.ecr.ap-northeast-1.amazonaws.com/dockerImage:latest を利用するだけで、 あとは、x86_64 環境では x86_64 のイメージを、AArch64 環境では AArch64 のイメージを 自動判別して使ってくれます。 全体の流れ さて、本題のマルチアーキテクチャイメージを作成する流れです。 AWS CodeBuild（バッチビルド）を用いて、x86_64、AArch64 を並列でイメージのビルドと Amazon ECR への push を実施。 双方が完了後、manifest を作成し manifest も Amazon ECR に push することで、マルチアーキテクチャイメージを Amazon ECR 上から利用可能としています。 上図において、 x86_64 build と AArch64 build は buildspec-image.yml で、 manifest create と manifest push は buildspec-manifest.yml で、 全てを取りまとめる バッチビルドは buildspec-batch.yml で実装します。 尚、AWS DevOps Blog では AWS CodePipeline を用いて AWS CodeBuild を 3つ 個別に設定し、マルチアーキテクチャイメージを作成する方法も紹介されていましたので別例としてリンクのみのご紹介とさせていただきます。 aws.amazon.com 1. buildspec-image.yml の作成 1. については、あくまで一例程度のご紹介です。 docker build をして push するだけの操作を想定して記載しています。 REPO_NAME 等の変数は 3. で作成する buildspec-batch.yml にて設定しますので「あ～、なんか入れてるな～🧐」程度の飛ばし読みでお願いします。 buildspec-image.yml(クリックで展開) version : 0.2 phases : install : commands : - echo Starting the Docker daemon... - /usr/local/bin/dockerd-entrypoint.sh pre_build : commands : - ECR_REPO_NAME=$(aws ecr describe-repositories --repository-names $REPO_NAME --output text --query "repositories[0].repositoryUri" ) - IMAGE_SIDECAR_WITH_TAG=$ECR_REPO_NAME:$DEPLOY_IMAGE_TAG_SIDECAR$DEPLOY_IMAGE_TAG_POSTFIX build : commands : # Dockerイメージの作成 - docker build -t $IMAGE_SIDECAR_WITH_TAG etc/docker/sidecar/ post_build : commands : # Amazon ECRへログイン - aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $ECR_REPO_NAME # Dockerイメージをデプロイ用のイメージタグでpush - docker push $IMAGE_SIDECAR_WITH_TAG 3. で後述しますが、ランタイムイメージを x86_64 と AArch64 で 個別に設定するため、 AArch64 イメージのビルド時も docker buildx build コマンドを使わず docker build コマンドで問題ありません。 2. buildspec-manifest.yml の作成 ここでは docker manifest create コマンドを実行し、Amazon ECR に push する処理を記載します。 変数については1. 同様、3. で作成する buildspec-batch.yml にて設定します。 buildspec-manifest.yml(クリックで展開) version : 0.2 phases : install : commands : - echo Starting the Docker daemon... - /usr/local/bin/dockerd-entrypoint.sh pre_build : commands : - ECR_REPO_NAME=$(aws ecr describe-repositories --repository-names $REPO_NAME --output text --query "repositories[0].repositoryUri" ) - IMAGE_SIDECAR=$ECR_REPO_NAME:$DEPLOY_IMAGE_TAG_SIDECAR post_build : commands : # Amazon ECRへログイン - aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $ECR_REPO_NAME # Dockerイメージを取得 - for postfix in $DEPLOY_IMAGE_TAG_POSTFIXES; do docker pull $IMAGE_SIDECAR$postfix; done # マルチアーキテクチャのためのマニフェストを作成 - for postfix in $DEPLOY_IMAGE_TAG_POSTFIXES; do echo $postfix; done | sed "s,^,$IMAGE_SIDECAR," | xargs docker manifest create $IMAGE_SIDECAR # マニフェストをpush - docker manifest push $IMAGE_SIDECAR 内容はコメントで記載の通りですので、説明は省きます。 3. buildspec-batch.yml の作成 ここではバッチビルドの設定を記載します。 identifier: x86_64 では x86_64 の、 aarch64 では AArch64 のイメージで実行する設定となっています。 identifier: multiarch_manifest は、x86_64、AArch64 どちらのイメージで実行しても問題ありませんが、以下例では AArch64 のイメージで実施しています。 depend-on: で identifier を指定し、 x86_64 と aarch64 が完了した後、buildspec-manifest.yml が実行されるような設定としています。 buildspec-batch.yml(クリックで展開) version : 0.2 env : variables : REPO_NAME : "sidecar" DEPLOY_IMAGE_TAG_SIDECAR : "release-1.0.0" DEPLOY_IMAGE_TAG_POSTFIXES : ".x86_64 .aarch64" BUILD_IMAGE_X86_64 : "aws/codebuild/amazonlinux2-x86_64-standard:3.0" BUILD_IMAGE_AARCH64 : "aws/codebuild/amazonlinux2-aarch64-standard:2.0" batch : build-graph : - identifier : x86_64 buildspec : buildspec/buildspec-image.yml env : image : $BUILD_IMAGE_X86_64 type : LINUX_CONTAINER variables : DEPLOY_IMAGE_TAG_POSTFIX : ".x86_64" privileged-mode : true - identifier : aarch64 buildspec : buildspec/buildspec-image.yml env : image : $BUILD_IMAGE_AARCH64 type : ARM_CONTAINER variables : DEPLOY_IMAGE_TAG_POSTFIX : ".aarch64" privileged-mode : true - identifier : multiarch_manifest buildspec : buildspec/buildspec-manifest.yml env : image : "aws/codebuild/amazonlinux2-aarch64-standard:2.0" type : ARM_CONTAINER depend-on : - x86_64 - aarch64 4. AWS CodeBuild の設定 最後にAWS CodeBuild の設定です。 環境は AArch64 の公式イメージを指定しておきます。 buildspecは 3. で作成した buildspec-batch.yml を指定します。 バッチ設定はチェックしておきます。 terraform で管理されている場合は、 aws_codebuild_project リソースに build_batch_config の設定を追記してください。 resource "aws_codebuild_project" "sidecar_build" { ・・・ build_batch_config { timeout_in_mins = 60 service_role = aws_iam_role.codebuild_for_build_image_sidecar.arn restrictions { compute_types_allowed = [] maximum_builds_allowed = 100 } } ・・・ } registry.terraform.io また、バッチビルドにする場合、AWS CodeBuild を実行する IAM ポリシーにも権限の追加が必要です。 docs.aws.amazon.com マネジメントコンソールから編集される場合は、バッチ設定で設定したサービスロールに対して、IAM の ポリシー から3つ（ StopBuild , StartBuild , RetryBuild ）の設定を追記します。 { " Statement ": [ ・・・ { " Action ": [ " codebuild:StopBuild ", " codebuild:StartBuild ", " codebuild:RetryBuild " ] , " Effect ": " Allow ", " Resource ": " * ", " Sid ": "" } , ・・・ ] , " Version ": " 2012-10-17 " } terraform で管理されている場合、 aws_iam_policy_document に対して、上記JSON同様の設定を追記して terraform apply すれば完了です。 data "aws_iam_policy_document" "codebuild_for_build_image_sidecar" { ・・・ statement { effect = "Allow" actions = [ "codebuild:StartBuild" , "codebuild:StopBuild" , "codebuild:RetryBuild" , ] resources = [ "*" ] } ・・・ } 大変お疲れ様でした！ これで、マルチアーキテクチャイメージを AWS CodeBuild (バッチビルド) で作成できますね！ 【Appendix】Java17 のマルチアーキテクチャイメージをビルド えっ、「マルチアーキテクチャイメージを Java17 でビルドしたい」ですって！？ 「集大成みたいなのｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!（古」って感じでしょうか。 ほとんど【応用】と同じですが、3点ほど修正を加えることで可能です。 codebuild-runtime の Corretto 17 をマルチアーキテクチャイメージにする buildspec-image.yml を修正する AWS CodeBuild の環境設定 1. codebuild-runtime の Corretto 17 をマルチアーキテクチャイメージにする 【上級】の 2. Corretto 17 対応させて、再度イメージを作る 方法で作成した AArch64 の Corretto 17 イメージでも利用可能ですが、今回は公式のイメージを用いてCorretto 17 のマルチアーキテクチャイメージを作成します。 ## AArch64 イメージビルド $ docker buildx build --platform linux/arm64 al2/aarch64/standard/ 3 . 0 -t codebuild-runtime:aarch64 --load ## x86_64 イメージビルド $ docker build al2/x86_64/standard/ 4 . 0 -t codebuild-runtime:x86_64 --load 完了後、manifest ファイルを作成し、AWS ECR へ push します。 ## tagging $ docker tag codebuild-runtime:aarch64 \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:aarch64 $ docker tag codebuild-runtime:x86_64 \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:x86_64 ## manifest を作成 $ docker manifest create ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:latest \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:aarch64 \ > ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:x86_64 ## Amazon ECR login $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ************.dkr.ecr.ap-northeast-1.amazonaws.com ## Amazon ECR へ push $ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:aarch64 $ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:x86_64 $ docker manifest push ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:latest 2. buildspec-image.yml を修正する 【応用】で3種類作成した、buildspec-●●.yml ですが、1種類の修正が必要です。 buildspec-image.yml は jar ファイルの作成を実施していませんでしたが、今回 Java のビルドが入るため、 install phase では runtime-versions に corretto17 を、 build phase では jar ファイル作成と cp の 2コマンドを追記しました。 buildspec-image.yml(クリックで展開) version : 0.2 phases : install : runtime-versions : java : corretto17 commands : - echo Starting the Docker daemon... - /usr/local/bin/dockerd-entrypoint.sh pre_build : commands : - ECR_REPO_NAME=$(aws ecr describe-repositories --repository-names $REPO_NAME --output text --query "repositories[0].repositoryUri" ) - IMAGE_SIDECAR_WITH_TAG=$ECR_REPO_NAME:$DEPLOY_IMAGE_TAG_SIDECAR$DEPLOY_IMAGE_TAG_POSTFIX build : commands : # jarファイル作成 & cp - ./gradlew --no-daemon clean build - cp build/libs/sidecar.jar etc/docker/sidecar/ # Dockerイメージの作成 - docker build -t $IMAGE_SIDECAR_WITH_TAG etc/docker/sidecar/ post_build : commands : # Amazon ECRへログイン - aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $ECR_REPO_NAME # Dockerイメージをデプロイ用のイメージタグでpush - docker push $IMAGE_SIDECAR_WITH_TAG 3. AWS CodeBuild の環境設定 buildspec-batch.yml では公式イメージを使用していましたが、今回 Corretto 17 でビルドする必要があるため、環境イメージをマルチアーキテクチャイメージに変更。 buildspec-batch.yml の変数は、AWS CodeBuild の環境変数で上書きします。 マネジメントコンソールからは、AWS CodeBuild の「環境を編集」から書き換えます。 カスタムイメージで、 1. で作成した マルチアーキテクチャイメージを設定します。 buildspec-batch.yml で使う2つの環境変数にも、1. で作成したマルチアーキテクチャイメージ( ************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:latest )を設定します。 terraform 管理の場合、 aws_codebuild_project の environment の中身を書き換えてください。 resource "aws_codebuild_project" "sidecar_build" { ・・・ environment { compute_type = "BUILD_GENERAL1_SMALL" image = "************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:latest" type = "LINUX_CONTAINER" ・・・ environment_variable { name = "BUILD_IMAGE_X86_64" value = "************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:latest" } environment_variable { name = "BUILD_IMAGE_AARCH64" value = "************.dkr.ecr.ap-northeast-1.amazonaws.com/codebuild-runtime:latest" } } ・・・ } 大変大変お疲れ様でしたー！ これで、Java17 プロジェクトにおいて マルチアーキテクチャイメージのビルドも、1つの AWS CodeBulild(バッチビルド)で実装できますね！ 最後に 本記事は AS IS で公開されます。 内部事情をぶっちゃけますと、執筆途中で、AWS公式より AArch64 対応 Corretto 17 が利用可能となり、内容を急遽修正しました。 AWS公式より AWS Fargate の Graviton2 対応が発表されてから暫く経過しており、且つ 公開当初から OUTDATED な内容も記載している掟破りなTechBlogとなってしまい、読みにくい箇所もあったと思いますが、ご容赦いただけますと幸いです。 いやはや、執筆した当人が言うのもナンですが、長すぎて読む気が失せry…(´∀｀;) 当時の対応方法もご紹介しましたが、最後まで読んでいただいた皆様に何かしら新しい発見があれば良いなーと思っております。 長文お読みいただきお疲れ様でした、そしてありがとうございました🙇 ご感想などありましたら、はてなブックマークや Twitter シェア時にコメントいただけると執筆者がエゴサして一喜一憂しますっ👀！！ｗ BIGLOBEでは、新しい技術を積極的に取り入れて開発を行っています。 記事を読んで「一緒に働いてみたい」と思われた方、「私ならもっと良い方法が出来る」と思われた方、ぜひカジュアル面談にお越しください！ hrmos.co ※ Amazon Web Services、AWS、AWS Fargate、Correttoは、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ Apple 及び MacBook は、Apple Inc.の商標です。 ※Java は、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。 ※ Twitter は、Twitter,Inc.の米国およびその他の国における登録商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

新刊「BIGLOBEテックアンソロジー」を技術書典14オンラインマーケットで販売します。様々な技術ネタを詰め込みました。記事では技術同人誌作りの楽しさもご紹介します。 BIGLOBEは2023/5/20から開催される「技術書典14」オンラインマーケットに参加します！ BIGLOBEテックアンソロジー BIGLOBEの技術書典への取り組み 既刊のご紹介 すくらむ＋デーデーデー AWSひよっこダイアリー もくもくモデリングの森を旅するチビドラゴンの軌跡 技術書典14 開催概要 こんにちは、マーケティングプラットフォーム部のこばやし（eri-twin）です。 みなさんは「技術書典」というイベントをご存知でしょうか。 技術書典は「新しい技術に出会えるお祭り」であり、誰かに説明する際には「技術書のコミケ」と喩えることが多いです。 これは個人や組織のエンジニア一人ひとりが持つ技術を、各々で執筆・印刷することで技術書の形にし、他のエンジニアに頒布するイベントです。 techbookfest.org BIGLOBEは2023/5/20から開催される「技術書典14」オンラインマーケットに参加します！ そんな技術書の祭典に、BIGLOBEもサークル参加します。 これまでに作成した既刊3冊に加え、今回の参加に合わせて制作した新刊を頒布します！ BIGLOBEテックアンソロジー 今回の新刊「BIGLOBEテックアンソロジー」は、営業から開発まで、所属を問わず集まった6名の執筆者による、技術ネタを集めたアンソロジーです。 GitHub Projectsを用いた作業時間の自動記録ツールの作成、オブジェクト指向プログラミングでは頻出のインターフェースの使い方に関する考察、スクラム開発をチームで実践した工夫と数々の失敗談など、各々が業務や自らの学習を通して得た知見についてまとめた合同誌となっています。 この一冊で、興味があるトピックだけでなく、新しい分野にも出会えるかもしれません。 オンラインマーケットでは電子版の販売に加えて、電子＋書籍のセット販売も行っています。かわいらしいキャラクターとスタイリッシュな装丁のデザインにも力の入った一冊、ぜひお手にとってご覧ください！ 目次 GAS+React+TypeScriptで作る簡単Webアプリ GitHub Projects上のカード移動を検知して、Googleカレンダー上で作業時間の記録をつけてみた 同僚の質問から紐解く「インターフェース」の使い所 15年目のエンジニアはGoogleフォームとピボットテーブルが最高だと思った 運用チームにおけるスクラムの工夫 スクラムで運用やってみた BIGLOBEの技術書典への取り組み BIGLOBEとして、初めて技術書典に参加したのは、2019年開催の技術書典6でした。 技術書典にプライベートで参加していた社員が「参加したい」と言ったことがきっかけでした。 初参加の前年にあたる2018年に、技術同人誌制作のために社内サークル「BIGLOBE INSIGHT GUILD」を立ち上げました。 社内に呼びかけて集まった有志メンバーにより、本文執筆、表紙、ページレイアウト、キャラクターデザインなど、同人誌を作り上げるために必要なものは、すべてこのサークルメンバーが作成しています。 しかし、技術書典に参加して辺りのサークルを見渡せば、私たちのような会社名義での参加はそれほど多いわけではありません。むしろ、個人で技術同人誌を執筆しイベントに参加する人の方が大変多いことがわかります。 個人での同人誌制作は負荷が大きく労力がかかるという一面もありますが、とても自由で、時に面倒で手間だと感じるような社内申請や手続きも必要ありません。 その中で、私たちが社内サークルという立場で参加する理由はどこにあるのだろうかと考えたとき、やはりBIGLOBE社内における、技術書典に参加する意義への理解と手厚いサポートの存在が挙げられます。 会社名義で技術書典に参加するにあたり、社内での技術的な取り組みを外部に発信する機会として理解してもらったことで、会社から与えられた予算と業務時間を利用して同人誌の製作・イベント参加に挑戦することが可能になりました。 同人誌の製作というものは、どこかシステム開発にも似ているのではないでしょうか。 ひとたびイベントに参加することを決めたなら、入稿締切という納期に向け、原稿執筆の進捗に追われる日々を送ることになります。それはシステム開発と同様に、非常に厳しく過酷なものになることも往々にしてあります。 そして、BIGLOBEでの同人誌製作は業務として取り扱われる一方、当然ですが同人誌を作らなかったとしても会社は問題なく回ります。それでも私たちは同人誌を作っています。それはなぜでしょうか。 私は、そこに本の形になった瞬間の達成感、イベントで本を手にとってもらえる喜び、そして時には読者から寄せられる本への感想やねぎらいなど、普段の業務では決して得られない体験があるからだと考えています。 こんなに楽しいことを業務時間でやれるんだから、やるしかない。 その思いが続いて、広がって、私たちは今回もまた本を作るのです。 既刊のご紹介 技術書典へは継続して参加しており、これまで3冊を制作、頒布しました。 こちらの書籍も、技術書典オンラインマーケットで引き続き頒布しています。 まだ読んだことがないもの、興味を惹かれるものがありましたら、ぜひチェックしてみてください！ すくらむ＋デーデーデー 異世界転生(転職)したらそこは……ビッグローブだった！？ BIGLOBEに中途入社した7名の社員が、それぞれの前職で得た経験をもとに、BIGLOBEの開発現場で実践したことを紹介する合同誌です。 タイトルのスクラム・DDD（ドメイン駆動設計）をメインテーマとして、Spring・AWS・ふりかえりや障害対応プロセスまで。様々なバックグラウンドを持つ社員たちが、個性豊かな切り口からスクラム+DDDを紹介していくオムニバス形式の一冊です。 目次 Re:DDDくらいできるようになりたいよねって話 ふりかえりのマイ・ベストプラクティス BIGLOBEのらーじすけーるすくらむ 障害対応 AWS Lamdaで実践する 12 factor app エンジニアとして成長したいならコーディングすると良い DDDで扱うWebフレームワークの勘所 すくらむ＋デーデーデー　詳細はこちら AWSひよっこダイアリー ネットワーク未経験の新卒エンジニアがネットワークの部署に配属され、 新時代のクラウドネイティブなエンジニアを目指してAWSを勉強する成長日記です。 この本を執筆後、著者はAWSソリューションアーキテクトアソシエイトの試験に無事合格しました！ AWSを勉強するときの勉強方法やコツ、詰まりやすいポイント、考え方などを、 新入社員の目線から、初心者にもわかりやすく解説していきます。 AWSひよっこダイアリー　詳細はこちら もくもくモデリングの森を旅するチビドラゴンの軌跡 モデリング技術向上に悩む新米エンジニアたちが一念発起。 「もくもくモデリング勉強会」という自分たちだけの勉強会を始めました。 みんなで学び議論しあうこの勉強会は、モデリングの楽しみを教えてくれました。 これからモデリングを始めるすべての人へ、私たちの2年間の軌跡を捧げます。 勉強会の進め方、モデリングの観点と考え方、ドキュメントの作り方と解説、よくある失敗モデルの事例などをまとめました。『モデリング初心者が読めるモデリング本』というコンセプトで書いた、最初の一歩を踏み出すための力になりたい一冊です。 もくもくモデリングの森を旅するちびドラゴンの軌跡　詳細はこちら 技術書典14 開催概要 技術書典は、Web上で開催されるオンラインマーケット（5/20 - 6/4）とオフラインイベント（5/21）の二本立てです。BIGLOBEはオンラインマーケットにのみ参加しますが、オフラインイベントへの参加もおすすめです！池袋サンシャインシティで開催され、たくさんの技術同人誌たちと出会えます。 会場に入場するには、事前に無料の入場券を申し込む必要があります。数に限りがあるのでご注意ください。イベントの詳細は公式ページからご確認ください。 それでは、皆さんにたくさんの素晴らしい本との出会いがありますように！ 技術書典オンラインマーケット： techbookfest.org BIGLOBEの社内サークル「BIGLOBE INSIGHT GUILD」のページ： techbookfest.org ※ Google、Googleカレンダー、Google Workspace 、Googleスプレッドシート、Googleスプレッドシートのロゴ、Googleドライブ、Googleドライブのロゴ、Google Apps ScriptおよびGoogleフォームは Google LLC の商標です。この記事で紹介した本はGoogleによって承認されたり、Googleと提携したりするものではありません。 ※GitHubは、GitHub, Inc.の商標または登録商標です。 ※記載しているシステム名、製品名は、それぞれ各社の商標または登録商標です。

BIGLOBEではGoogle Apps Scriptを活用して、エンジニア部門とビジネス部門が一緒になって業務改善に取り組んでいます。管理職向け研修など活性化の取り組みを、2023年3月23～24日に開催されたGoogle Workspace Summit 2023でご紹介しました。 きっかけになったのは、昨年10月に公開したTechBlogの記事でした。 style.biglobe.co.jp 実は、昨年12月に開催されたGoogle Workspace Review 2022に登壇する予定だったのですが、発表の直前に新型コロナウイルスに感染していることが発覚。無念の欠場となりました。しかしGoogle Cloud様の粋な計らいで、より規模の大きな今回のイベントに登壇させていただくことになりました。ありがたすぎます...。 事前に何度も練習して万全の態勢でのぞみました。当日はたくさんの質問もいただき、とても良い経験になりました。 Google Workspace Summit 2023 のサイトでフォームに登録していただくと、動画をご覧いただけます。以下、発表の内容をご紹介いたします。 .table-of-contents ul { display: none; } 文房具だなの上にQRコードが置いてある？ 「QR コードでフォーム表示」を導入するステップ 1. フォーム作成 2. QRコード作成 3. メールで通知 3'. Google Chatへ ローコード開発プラット フォーム Apps Script Apps Scriptを使った業務改善に新人と取り組んでみた結果... 失敗から学んだ 2 つの教訓 1. 機能を絞ってとりあえずリリース 2. 要求者との会話のキャッチボールを大切に ボトムアップによる現場 DX 管理職向け Apps Script 研修から社内事例のご紹介 事例1: 議事録の日付を自動挿入 事例2: Google Chatのボットたち 事例3: 社内ウェブアプリ 事例4: AppSheetを活用しGmail上で承認 Apps Script で困った時、どう解決する？ 1. 社内コミュニティに質問する。 2. 一度は体系的に学ぶ 業務部門とDXを育てる試み 文房具だなの上にQRコードが置いてある？ BIGLOBEの高玉です。早速ですが、皆さんにクイズがあります。この写真は、私のオフィスの様子です。文房具棚の上にQRコードが置かれています。このQRコード、何に使うと思いますか？ 文房具棚に足りない物品があるときに、社有のスマートフォンでQRコードを読み取ります。すると、皆様おなじみ、Googleフォームがスマホに表示されます。補充品の申請画面です。フォームで不足品をチェックして送信すれば、文房具の担当者に連絡がいく仕組みです。 QRコードを読んだら、Googleフォームが表示される、とても単純な仕組みです。社内でも、地味だけど便利だよね、と評判になったので、昨年、 TechBlogの記事として公開 しました。すると、社外からの反応も好評で、SNSでの話題性の指標となる「はてなブックマーク」では、テクノロジーカテゴリーでホットエントリー入り、ブックマーク数は85、我々のTechBlogで 歴代3位 になりました。そして、Google Cloudさんの目にも留まり、本日の登壇となりました。 気がついてみれば、何ということはないアイデアなのですが、実は、このアイデアを実現するまでには色々な試行錯誤がありました。本日は、このアイデアが生まれるまでの背景を中心に、Google Workspaceを使った業務改善の取り組みについて紹介していきます。 Google Workspaceは2017年に導入しました。ちょうどKDDIグループの一員となって、働き方を見直すタイミングでした。競合製品と比較しながら様々な検討を重ねましたが、決め手になったのはGmailとCalendarです。ちょうど社内のメールシステムをリプレースする必要があり、Gmailが第一の候補にあがりました。Gmailによってメールデータはクラウドに保存されるようになり、もしセキュリティインシデントによってPCをクリアインストールする必要が出た時も、スムーズに代替PCに乗り換えられるようになりました。また、Calendarを導入する前は、日程を調整するために平均で7往復ものメッセージをやり取りしていましたが、Calendarによって、調整の手間を一気に無くすことができ、とても助かっています。Web会議サービスのGoogle Meetとの相性の良さも抜群で、コロナ禍にあっても、社内コミュニケーションを継続することができました。 2021年からはChromebookを全社に導入しています。Windowsでないとできない業務は、Microsoft社のAzure Virtual Desktopにリモートデスクトップして解決しています。 「QR コードでフォーム表示」を導入するステップ 最初にご紹介した、QRコードを読むとフォームを表示する仕組みですが、Google Workspaceを導入されている企業さん、学校さんなら、すぐにお使いいただけます。ここに示す3ステップで導入できますので、ぜひご活用いただければと思います。 1. フォーム作成 補充品を申請する Google フォームを作成 2. QRコード作成 Google スプレッドシートで フォームの URL を QR コードに変換 念のため QR コードを印刷して、スマホで正しく読み取れるか検証 3. メールで通知 フォームの回答タブで、その他アイコン から「新しい回答についてメール通知を受け取る」を選択 ただし「新しい回答があります」とだけ表示される ここにApps Scriptを使うことで、より便利で効率的になります。 3'. Google Chatへ Apps Script で Google Chat に通知も可能 工夫すれば申請内容＋所属も一緒に通知できる Googleフォームは、回答をメールで通知できるのですが、メールの文面はただ単に「新しい回答がある」ことしか書いてありません。Apps Scriptを使えば Google Chatにすぐに通知されますし、通知されるメッセージには、誰が何を補充してほしいのかも表示できます。 ここから先の話は、このApps Scriptがとても重要な役割を担います。少し詳しく説明していきます。 ローコード開発プラット フォーム Apps Script Apps Script はプログラミングでGoogle Workspaceを自動化できるローコード開発プラットフォームです。プログラミング言語のJavaScriptを使い、Google Workspaceで扱うデータを操作するプログラムを作れます。 私は新人エンジニアの育成を担当しています。プログラミングも教えているのですが、プログラミング初心者にとってApps Scriptはとても優れた道具です。Apps Scriptがプログラミング初心者にとって優れているのは、次の4つの点です。 安全性 。これが最も大切です。Googleアカウントを使った認証で、Google Workspaceのドメイン外への情報漏洩を防いでくれます。セキュリティ ガードレールの役目を果たし、ガードレールの中であればいくらでも試行錯誤することができます。 簡便さ 。Webブラウザーだけあれば、Apps Script を使ったプログラミングを始められます。さらに、デバッグも、デプロイも、ブラウザーだけで完結します。プログラミング初心者がつまづく最初の壁は、自分のPCでプログラミングができるように開発環境を構築することですが、それを楽々と乗り越えることができます。 業務リソースの活用 。オフィス業務で使う、スプレッドシート、スライド、ドキュメント、カレンダーといったデータだけでなく、Google Workspaceのドメイン内にいる人の情報を取得できるディレクトリーへのアクセスなど、様々なデータソースにアクセスできます。それらを組み合わせることで、業務を効率化することが可能です。プログラミング初心者は「せっかく学んだプログラミングを何に活かすか？」を見失いがちです。オフィスで働く人なら誰しもが「業務を効率化したい。面倒な手作業をなくしたい」と思われていることでしょう。業務効率化に使えるApps Scriptなら、プログラミングを活用する実戦の場がいつでも見つかります。 柔軟性、拡張性 。Apps Scriptを使えばウェブアプリを作ることもできます。Google Workspaceのドメイン内で安全に公開できるのが特長です。工夫すればVue.jsなどのモダンなフロントエンド技術も使えます。新人エンジニア研修では、研修で学んだことの総まとめとして、本格的な社内システムをApps Scriptで作り、実業務で活用しています。 Apps Scriptを使った業務改善に新人と取り組んでみた結果... プログラミングは、知識としてただ学ぶだけでなく、実践を通じて使いこなせるようになることがとても重要です。自転車の乗り方を座学で学んでも、乗りこなせるようにはなりません。分かる、を、できる、に変える必要があります。そこで、実践の場を作るため、社内のイントラブログで業務上の困りごと、自動化したいことを募集しました。ありがたいことに、すぐさま18個ものアイデアが集まったので、そのうちの3つについて新人と一緒にヒアリングに行き、Apps Scriptでプログラミングをしていきました。しかし、新人が作成したコードは、どれ一つとして実業務で使われることはありませんでした。 新人のプログラミング能力が未熟だった訳ではありません。それぞれ別の理由がありました。「試作品はできたが、設定が面倒で結局使われなかった」「自動化するには元の業務を変更しなければいけないが、変えたくなかった」。試作品を作る過程で、新人のプログラミング能力を向上させる目的は達成できたものの、せっかく作ったものが使われなかったのはとても残念でした。 そんな中、QRコードを使うアイデアが社内のあるコミュニティから持ち込まれました。Apps Scriptを業務で活用している人が集まるコミュニティです。ちょうどフリーアドレス制を導入したタイミングで、その日に座る座席をシステムに登録するために、座席に貼ったQRコードを読み取ってチェックインする仕組みです。 フリーアドレス制を推進しているスタッフ部門に座席チェックインのアイデアを持ち込んでみたところ、そのアイデアよりも、「社内の業務にQRコードが使える」ところのインパクトが強く、結果的に、冒頭に紹介した文房具補充にQRコードを使ってみよう、ということになりました。 失敗から学んだ 2 つの教訓 今度は失敗させないぞ！と、先の失敗から学んだ2つのことを心がけながら、検証を進めました。 1. 機能を絞ってとりあえずリリース 動くものを素早く作り、体験してもらうことを優先しました。当初は、文房具ごとにQRコードをたくさん発行し、それを連続で読み取らせるアイデアも出たのですが、実装するのは少し大変です。そこで「QRコードを読んだら、フォームを表示するだけ」にあえて機能を絞り込みました。 2. 要求者との会話のキャッチボールを大切に コミュニケーションに気をつけて、真の要求を一緒に探しました。業務に詳しいスタッフ部門は、改善のアイデアもたくさん持っています。一方、エンジニアはそうしたアイデアを聞くと「実装できるか？できないか？」という観点で反射的に回答しがちです。その結果、実際の業務からかけ離れた使いづらい実装になってしまうこともあります。アイデアに対して「できる・できない」と回答する前に、「そもそも、どうしてその要望を叶えたいのか？」を引き出すよう、会話のキャッチボールを心掛けました。 こうしてできたのが、補充品の申請システムです。 ボトムアップによる現場 DX 実際に申請してみた人からは、「備品の担当者をわざわざ探す手間が省けた」「備品がすぐに補充されるようになった」「QRコードを読む体験が楽しい」といった声を頂いています。利用する上での一番のハードルは、社有スマホでQRコードを読み取るところなのですが、Googleレンズアプリを使えば解決できます。スタッフ部門からは「不足品の巡回が不要になった」「備品の使用頻度が記録されるので、文房具棚に入れておくべき「標準品」を工夫できるようになった」という嬉しい反応がありました。何より嬉しかったのは「アイデアが形となり、仕事が楽になる経験を通じて、仕事をするのが楽しくなった」という声です。 実は、TechBlogに対するSNSの反応でも、「いい話」「良いDX！」という好意的な評価を頂いています。このように好意的に受け入れられたのは、ボトムアップ型の現場 DX だったからなのでは？と考えています。 経済産業省のDXレポート2 では、デジタル化をdigitization、digitalization、digital transformationの3つに分けて解説しています。 digitizationはアナログのデジタルデータ化。従来の補充依頼は、そもそもデジタルデータとして残らなかったり、チャット上にしか残っておらず、構造化されてませんでした。これが、Googleフォームを使って後々活用しやすい形で記録されるようになりました。QRコードも併用することで、フォームを検索する手間まで省いています。digitalizationはデジタルデータの活用です。補充依頼のデジタルデータから標準品を工夫できるようになったことに相当します。digital transformationは、ビジネスモデルの変革。もし、私たちがこの補充品の申請システムをSaaS化して外販すれば、新しいビジネスモデルを実現することになるのでDXに相当するでしょう。今回は、digitizationからdigitalizationへと進む、ボトムアップのアプローチでした。こうしたボトムアップを多く経験することで、ビジネスモデルを変革するアイデアも出やすくなるのでは、と期待しています。 経済産業省はDXを推進する企業の成熟度を測定するために、DX推進指標も発表しています。その中に、望ましいマインドセット、企業文化として「挑戦を促し失敗から学ぶプロセスをスピーディーに実行し、継続できる仕組みが構築できているか」という項目があります。Apps Scriptを使ってせっかく作った試作品が無駄になったこともありましたが、その失敗からの学びを活かしながら、間髪を入れずに次のチャレンジができたことは幸運でした。 冒頭で、Apps Scriptをプログラミング初心者に適した道具としてご紹介しましたが、試行錯誤を繰り返すボトムアップ型の現場 DX においても、Apps Scriptは優れた価値を発揮することが伝われば幸いです。 管理職向け Apps Script 研修から社内事例のご紹介 Apps Scriptを活用できる人が増えれば、現場 DX はますます加速します。そこで、Apps Script を学ぶ場として、管理職向けの研修も開始しました。狙いは、管理職クラスのリテラシーを向上することで、自身の業務を効率化できるようになること。さらにその経験を通じて、効率化の対象を組織全体に広げることです。広い視野を持つ管理職だからこそ期待は高まります。研修は、いわゆる反転学習のスタイルで開催します。事前に動画を使って基礎知識を学び、集合して実際に手を動かしてApps Scriptのプログラミングを体験します。動画教材には、株式会社ストリートスマート様の Master Program を使っています。とても良くできているのでオススメです。ハンズオンの題材は、普段の仕事でも良く使うGoogle Chatに、メッセージを送るだけの簡単なプログラムです。題材は簡単ですが、APIの使い方からタイマーを使った定期実行まで、基本的なことを一通り体験できます。 また、Apps Scriptを使いこなすコツは、Apps Scriptでどんなデータを操作できるのか、その事例を数多く知ることです。 そこで、研修では社内の事例も紹介します。皆さんにも Apps Scriptでできることのイメージを膨らませていただきたく、ここからは社内事例を4つほど紹介していきます。 事例1: 議事録の日付を自動挿入 最初はとても地味な事例です。タイマー起動で、定例ミーティングの議事録ドキュメントに日付を追加します。これだけです。定例ミーティングの議事録は、新しい日付の分を上に書いています。もし下に追記してしまうと、最新情報を確認するために、一番下までスクロールをする必要が出てしまうからです。日付の追加ですが、会社が休みの日には追加しないように制御しています。Googleカレンダーに会社の休みが登録されているので、それを参照しています。 事例2: Google Chatのボットたち 次はGoogle Chatを使った事例です。Apps Scriptを使えばチャットボットを作ることができます。左は、ドル円の推移をグラフ化して通知してくれるボットです。右は、会話型のボットです。ミーティングでの発表順番を決めるときなどに、シャッフルボットを使います。話しかけると、順番をランダムに決めて、返信してくれます。 事例3: 社内ウェブアプリ 新人エンジニア研修で作った社内システムの事例です。どちらも、人事部がプロダクトオーナーになり、アジャイル開発で作りました。左は、感謝の気持ちをポイントとしておくりあうシステムです。右はスキル診断ツールです。どちらもVue.jsを使い、Single Page Applicationとして作っています。 事例4: AppSheetを活用しGmail上で承認 最後の事例は、ノーコード開発ツールAppSheetの活用です。AppSheetを使うと、Gmail上で操作できる社内システムを作れます。2月に記事を公開したところ、我々のTechBlog 歴代2位 のブックマーク数となり、世間からAppSheetが注目されていることを実感しました。 Apps Script で困った時、どう解決する？ 最後に、Apps Scriptについて困った時にどうやって解決するか、社内に伝えていることをご紹介します。 1. 社内コミュニティに質問する。 まず、困ったら、社内コミュニティに相談するよう伝えています。 困った内容を検索エンジンで調べることも可能なのですが、初心者の場合、どんな検索ワードで調べれば良いかがわからなかったり、見つかった情報が古い場合もあり、むしろ課題の解決に時間がかかってしまうこともあります。ですので、困ったら社内で相談、としています。尋ねられた人は、Googleの公式ドキュメントを参照して回答することが多いです。 2. 一度は体系的に学ぶ また、初心者の方へは、手当たり次第に検索エンジンで探すよりも、一度は体系的に学ぶことをオススメしています。動画で学びたい方には、先程もご紹介したMaster Programを、本で学びたい方には、高橋宣成さんが書かれた、 詳解! Google Apps Script完全入門 をオススメしています。最新は第3版ですのでご注意ください。一度、体系的に学んでおくと、検索の仕方も洗練されます。 業務部門とDXを育てる試み この発表では、BIGLOBEがApps Scriptでボトムアップ型の現場DXを推進している様子をご紹介してきました。試行錯誤にぴったりの道具であるApps Scriptを活用し、失敗から学びつつ試行錯誤を続けています。その挑戦を支える社内コミュニティも重要です。こうしたボトムアップの取り組みで社員が digitization、digitalizationに慣れていくことで、ビジネス変革を起こす digital transformation を生み出しやすくなると期待しています。私たちの取り組みが、少しでも皆様のお役に立てば光栄です。 発表は、質疑応答含めて25分です。 Google Workspace Summit 2023 のサイトでフォームに登録すると録画、登壇資料、質疑応答の内容をご覧いただけます。業務改善はどの会社でも悩まれていることと思います。会社の壁を超えて、ぜひノウハウを共有していきたいですね！これからも情報を発信していきますので、どうぞよろしくお願いします。 ※ Google 、Google Workspace 、Gmail 、Google Meet 、Google Chat は、Google LLC の商標であり、このブログはGoogle によって承認されたり、Google と提携したりするものではありません。 ※ Microsoft 、Windows、Azureは、米国 Microsoft Corporation の米国およびその他の国における商標または登録商標です。 ※ ＱＲコードは、株式会社デンソーウェーブの登録商標です。 ※ KDDIは、KDDI株式会社の商標または登録商標です。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

組織間を直接接続するピアリングは通信品質を向上しコストを低減します。日本・アジア・世界のインターネットをより良くするため、粘り強くピアリング交渉に取り組む様子をお伝えします。 .table-of-contents ul { display: none; } ピアリングとは？ 1. インターネットの仕組み 2. トランジット 3. ピアリング ピアリングの目的 コストの削減 通信品質の向上 トラフィックコントロールを容易に ピアリングの交渉の必要性 世界と繋がるBIGLOBEのネットワーク ピアリングコーディネーターの仕事 BIGLOBEのピアリングの目標 戦略立案 新規接続交渉と開通作業 運用と接続の見直し 社外との窓口 Peering Asia とは？ 対面で話す意義 Peering Asia 4.0 で具体的にどんな話をしたの？ とある組織との帯域増強の話 トランジットを経由するトラフィック問題の解決 調達の交渉 その他 おわりに 〜この仕事の楽しさ〜 基盤本部ネットワーク技術部の山口です。 2022年の11月初頭にタイ王国のバンコクで開催された、 Peering Asia 。その内容をレポートすると共に、あまり表に出ることのない、ピアリングコーディネーター 1 の仕事について紹介したいと思います。 ピアリングとは？ ここから先を理解するには、まずインターネットの仕組みとピアリングについて理解をしておく必要があります。既にご存知の方はこの章は飛ばして次の章にお進み下さい。 ピアリングと聞いて何のことかご存知ではない方は同じネットワーク技術部の前野さんが解説される動画「AS運用ことはじめ」をご覧頂くと良いかと思います（パートI 1時間、パートII 23分）。 www.nic.ad.jp 長い動画ですので、すべてを見る時間の無い方向けに、最低限知っておいて欲しいポイントを3点ご紹介します。 1. インターネットの仕組み インターネットは、各組織が持っているネットワークが、インターネットプロトコルとBGP（Border Gateway Protocol）という仕組みによって、相互に接続されることで成り立っている、地球規模の情報通信網です。今このブログを見ている貴方のパソコンなどでどこかのWebサイトを表示すると、世界中のどこかにあるWebサイトのサーバと、あなたのパソコン（WiFiを使っている場合はブロードバンドルータなど）は、必ず物理的にケーブルで繋がっています。 このBGPという仕組みによる相互接続にはAS（Autonomous System）という世界中で一意の番号が使われます。BIGLOBEはAS2518、KDDIはAS2516、AmazonはAS16509、GoogleはAS15169といったように番号が割り当てられています。 このAS同士の接続関係は大きく「トランジット」と「ピアリング」に分けられます。 図：トランジットとピアリング 2. トランジット トランジットはあるASが、他のASに料金を支払い、インターネット全体への到達性を提供してもらうことです。インターネット接続を提供する側を「トランジットAS」、インターネット接続の提供を受ける側を「顧客AS」と呼びます。 顧客ASは契約に従い基本料金と、実際にトラフィックを流した分だけの従量料金を毎月支払うのが一般的です。 3. ピアリング 一方、ピアリングは通常は無償で行われ接続に対する対価は発生しないことが一般的である、対等な関係です。無償と言っても、接続に必要なデータセンター内の光ケーブルを敷設する費用などの実費は発生し、これらは双方が負担します。 このピアリングにはプライベートピアリングとパブリックピアリングの2種類があります。 プライベートピアリングは双方のASが入居している同じデータセンター内などで、個別に回線を用意して1:1で接続することです。 図：プライベートピアリング パブリックピアリングは、ピアリングをするための専用のネットワーク（巨大なスイッチングハブのようなもの）を用意している、インターネットエクスチェンジ（IX）という場所に接続し、そのIXに集まるAS同士がピアリングすることです。お互いのトラフィック量が専用回線を用意してプライベートピアリングをする程でもないような場合もIXを利用すれば気軽にピアリングをすることができる上、1本の回線で複数のASとピアリングすることができるため、帯域を有効に活用することができます。IXを利用するにはIX事業者と契約して料金を支払い、ポートとIPアドレスの割り当てを受ける必要があります。 図：インターネットエクスチェンジでのピアリング なおピアリングでの接続はインターネット全体への到達性をどちらかが提供する訳ではなく、お互いの経路情報の交換のみとなります。 ピアリングの目的 ではピアリングはどのような目的で行われるのでしょうか。ここまで読まれた方は何となくお気づきかもしれませんが、改めて説明します。 コストの削減 前述の通りトランジットは従量制であることの多い有償の契約であり、これを利用して通信をすればするほどコストが掛かります。当たり前の話ですが、安価にお客さまにサービスを提供し、会社の利益も確保するには、原価を削減する必要があり、トランジットに依存する必要がある通信をできるだけ減らす必要があります。 通信品質の向上 全てのトランジットがそうでは無いのですが、トランジットを経由するということは、 単純にトラフィックが通過するASが増えることでもあり、時に通信が遠回りとなってしまうことがあります。また、経由するASのどこかで回線の混雑など通信品質の悪化が発生しているかもしれません。 直接接続することでこのような問題が発生するリスクを最小限に抑えることができます。 トラフィックコントロールを容易に 上記の2つと比較すると少し分かり辛いですが、直接接続することでより、トラフィックのコントロールを容易に行うことができます。例えば自分のASと、コンテンツ事業者ASの間に別のASが入っている場合、どの接続ポイントでコンテンツ事業者のASに自分のASの経路が渡されるかは、間に入っているAS次第になってしまうことがあり、自らの意思でコントロールすることが難しくなります。これにより通信が遠回りになったり、品質が悪化するリスクが生まれることもあります。 直接ピアリングすることで、トラフィックをどこで受け取るかのコントロールが容易になります。BGPのパラメータを設定したり、ピアリング先のASと交渉することで、容易にトラフィックのコントロールが可能になります。 ピアリングの交渉の必要性 では、メリットが大きいのでどの組織もお願いすればピアリングをしてくれるかというと、そうではありません。例えば、トランジットを販売することを主なビジネスとしている会社は、無償で接続をしていたらビジネスが成り立たなくなってしまいます。そのような会社はピアリングをしてくれないことがほとんどです。 トランジット販売をしていない会社であってもさまざまな理由でピアリングを断られる事があります。例えば、ネットワークの帯域やルータのポートが不足しているなどの設備的な理由、そのASとのトラフィック量が少ないためピアリングをする価値がないという判断をされることは良くあります。 その他にもネットワークの設計ポリシー上の理由、会社間の力関係、国と国の関係など政治的な理由、地理的な位置関係、お互いのビジネスや思惑もあり、その理由はさまざまです。自分がどんなにピアリングをしたい相手であっても相手のビジネスにとってメリットが無ければドライに断られることも日常茶飯事です。 だからこそ、戦略を立てて、ピアリングしたい組織と粘り強く交渉をしてピアリングを実現していくことが必要になります。 BIGLOBEも誰とでもピアリングをする訳ではなくピアリングポリシーという一定のルールを設けています。このピアリングポリシーはWeb上で公開していますので、興味のある方はご覧いただければと思います。 BIGLOBEピアリングポリシー https://biz.biglobe.ne.jp/transit/pdf/peering_policy2022_global.pdf 世界と繋がるBIGLOBEのネットワーク BIGLOBEは日本でサービスを提供している企業ですが、実は世界中にネットワークを伸ばしています。西はヨーロッパ、オランダのアムステルダム、東はアメリカ西海岸のロサンゼルス 2 とシリコンバレー、南はシンガポールや香港にネットワークがあります。これら海外拠点ではインターネットエクスチェンジに接続を行っており、世界中の組織とピアリングをしています。 図：BIGLOBEの海外ネットワークの接続状況 ピアリングコーディネーターの仕事 BIGLOBEでのピアリングに関する業務は、基盤本部ネットワーク技術部のISPネットワークグループが担っています。なお、チームとしてはさまざまな業務があり、ピアリングに関する業務はこの一部分でピアリングの専任者が居る訳ではありません。ちなみに、海外の大手コンテンツ事業者などはピアリング専門のチームが居るそうですよ…規模が違いますね。 ではピアリングコーディネーターがどのようなことをしているのか少し紹介したいと思います。 BIGLOBEのピアリングの目標 基盤本部ネットワーク技術部では「ID単価1.0倍」「品質スリーゼロ」というスローガンを掲げて業務に取り組んでいます。インターネット利用量は毎年1.4倍ずつ増えていて維持コストもそれにつられて上がります。しかし、利用量が増えてもお客さまへの請求額を増やさず1.0倍にするのが「ID単価1.0倍」です。また、お金・セキュリティ・人為ミスにまつわる3つの障害を毎月ゼロ件に抑えるのが「品質スリーゼロ」です。 これを達成するための一つの手段として「トラフィック量の100％をピアリングでカバーできるようにする」という目標を持って業務にあたっています。ピアリングでのトラフィック交換を増やすことで、トランジットトラフィックを削減し原価を改善するとともに、意図せず通信が遠回りになったり、品質の悪い経路を通過してしまうことを防ぎ、品質問題が発生するリスクを低減するという意味です。 ピアリングを受けてくれないASもある中でなかなか難しい目標ではありますが、高い目標をもって業務に取り組んでいます。ちなみに、先人の方々の努力もあり、トランジットに依存しているトラフィックは、全体トラフィックの5％程度と非常に少なくなっています。 戦略立案 まずはトラフィックを注意深く観察することが基本中の基本となります。日にもよりますが、私は勤務を開始すると、前日のトラフィック動向をチェックすることから始めることが多いです。 インターネットのトラフィックは人々の生活によって日々変化します。例えば先日開催されたサッカーのワールドカップの時は試合を視聴するトラフィックが増加しました。また、天候が悪い日は外出を控え自宅でインターネットを使う人が多くなるためか、トラフィックが増えることがあります。 このようなトラフィックの状況、ネットワークに関するコスト、品質などを日々分析し、どのASとピアリングする必要があるか、トラフィックを交換する場所はどこが最も効率的か、トラフィックの伸び率を考えていつまでに帯域を増強した方が良いか、などさまざまな情報を検討して戦略を立てます。特にトラフィック全体のバランスを考え、そのトラフィックをどこで受け取った方が、もっともコスト効率が良く品質が向上するかを考えることは重要です。 その結果、どのASとどこで接続したいかが具体的になったら、先方と交渉に臨むことになります。 新規接続交渉と開通作業 メールで接続のお願いをすることが一般的ですが、今回参加したようなイベントで直接接続の交渉をすることもあります。「そもそも接続できるか、接続の場所、予測されるトラフィック量、経路の量と内容、どのようなトラフィック制御をするか、プライベートピアの場合は必要なケーブル費用の負担と接続帯域」などが主な交渉内容となります。 接続交渉がまとまったら、プライベートピアリングの場合は接続に必要なケーブルの手配、その後手順書を作成してルータに設定を投入、開通作業を行います。 運用と接続の見直し 接続が完了してもそれで終わりではありません。トラフィックの変化などをキャッチアップして、帯域の増強や接続場所の追加などの交渉を必要に応じて行います。総務省の公開している「我が国のインターネットにおけるトラヒックの集計試算」というデータを見れば分かりますが、日本のインターネットラフィックは伸び続けており、トラフィックの伸びに合わせてピアリングの帯域を増速していく必要があります。 増速には部材の準備や作業者の手配など時間が掛かりますので、今後のトラフィック量をある程度予測し、先手を打って帯域を増やしていくというのも大切な運用の一つです。 接続場所の追加の交渉もよくある話です。例えば日本ではピアリングすることのできない、あるコンテンツ事業者とシンガポールでピアリングをしたとします。これは、シンガポールでそのコンテンツ事業者からBIGLOBEがトラフィックを受け取り、我々の費用で日本まで運んでいることになります。ピアリングをすることで直接トラフィックの交換ができ品質は向上しますが、高額な海外回線を使って日本にトラフィックを運ぶので、コスト削減効果は十分ではないかもしれません。そのコンテンツ事業者と日本でピアリングができるようになった場合、日本でピアリングしてトラフィックを受け取った方が、我々が負担してトラフィックを運ぶ距離(コスト)が少なくなります。海外のコンテンツ事業者だと海外でサービスがヒットしその後日本にも進出するようなパターンはよくある話です。 社外との窓口 バックボーンルーティングや品質に関する窓口的な仕事も大切です。お客さまからサポートセンターに「このゲームとの間の通信が遅い」といったお問い合わせがあった際にも最終的には我々のチームに調査依頼が回ってきますし、他社のISPやコンテンツ事業者から我々の通信経路について、コネクションを通じて問い合わせを受けることがあります。 BIGLOBEとBIGLOBEのお客さまにとってベストな状態を目指すことはもちろん、日本のインターネット全体にとってベストな状態を考えていくのも大切な仕事です。そのため、いろいろな所で人と人のつながりを作っておくことが大切です。 Peering Asia とは？ Peering Asia はアジア太平洋地域を中心とした組織のピアリングコーディネーターが集まるピアリング交渉のためのイベントです。ピアリング担当者以外にも通信キャリアの人なども参加し、インターネットに関するさまざまな交渉や商談が行われます。2017年に1回目が京都で開催され、2018年に2回目が香港で、2019年に3回目がマレーシアで開催されました。似たようなイベントは世界中で開催されており、北米を中心としたGlobalPeeringForumやAsiaPeeringForumなどがあります。COVID-19の影響で2年程開催が止まっていましたが、2022年11月に4回目が開催され、約100を超えるASと250人近い人が参加しました。 インターネットに関するイベントやカンファレンスというと、例えばJANOGなどがそうですが、プレゼンテーションを聞くことが多いかと思います。しかしPeering Asiaをはじめピアリング交渉のためのイベントでは個別のピアリング交渉に多くの時間が割かれています。 写真のように会場のホテルには4人程が座れる机が並び、１社につき1回30分のミーティングを繰り返します。 海外出張と言うと華やかなイメージがありますが、ピアリング交渉を目的としたイベントはかなりハードです。今回は朝の8時頃から夕方まで、ほぼ休みなくミーティングの予定が入っていました。ミーティングは基本的に英語で行われ、30分という限られた時間の中で希望を伝え交渉をまとめる必要があります。そのため、あらかじめ交渉先ごとにトラフィック量などの説明する資料を用意したり、交渉のポイントを英語で整理しておくなど、十分な準備を重ねて交渉に臨みました。 終了後は他の組織のピアリングコーディネーターの方などとの懇親会に参加し、ホテルで翌日の交渉に向けての戦略を練るなど、かなり忙しいのが実情でした。 対面で話す意義 昨今、世界中の人々とのコミュニケーションはオンラインミーティングやメールなどで日本に居ながら実現できるのは皆様もご存知の通りかと思います。そのような時代にあって、なぜ旅費を掛けて海外までミーティングをしに行く必要があるのでしょうか。 重要なことは、各組織のピアリング担当者同士で実際に会って、交流を深め、仲良くなることです。知り合いになり、仲良くなることで、細かい部分の意思疎通がしやすくなり交渉がスムーズに進むようになります。 時にはメールなどの記録に残る形で書くことが難しいオフレコの有益な情報を交換することもあり、これが双方のネットワーク戦略の立案に大きく役立つこともあります。万一ネットワークに障害が発生した際にも、お互い顔を知っている仲であるが故に、助け合って問題の解決に取り組むことができるなどのメリットがあります。 また、本来であればピアリングすることが難しい組織であっても、直接会って仲良くなるとピアリングをしてくれるようなケースもあります。意外に思われるかもしれませんが、人と人の繋がりで成り立っているのが、インターネットであったりします。 そのような事情から各社のピアリング担当者とは親密な関係を築けることも多く、私も一部の方とはFacebookやWhatsAppなどのSNSで繋がりもあり、業務外で一緒にお酒を飲みに行くこともあります。 交渉がまとまったら記念撮影しようぜ！なんてことも（APNIC理事のVincent ”Achie” Atienza氏と） Peering Asia 4.0 で具体的にどんな話をしたの？ 前述の通り、オフレコの会話があることもあり関係者外秘の事項も多く、残念ながら具体的な交渉の内容についてはこの場でお話することはできませんが、差し支えない範囲でご紹介したいと思います。 とある組織との帯域増強の話 とある組織とのピアリングの接続帯域を増速しようと以前からメールでお願いをしていました。しかし先方の運用ポリシーを満たさない部分があり、お断りされ続けていました。 担当者と直接お会いして弊社の事情を丁寧に説明したところ、「我々の運用ポリシーから外れる部分があるが、そのような事情ならピアリングの接続帯域を特別に増やしましょう」ということで接続帯域の増強の合意に至りました。 トランジットを経由するトラフィック問題の解決 以前からピアリングをしていたとある組織とは、ピアリングをしているにも関わらず、 一部の通信がトランジットを経由してしまうことに悩まされていました。メールで改善できないか何度か問い合わせをしていましたが、改善しない状況が続いていました。 担当者と直接お会いして会話をしたところ、先方のネットワークの設計上、追加で別の場所でピアリングをすることで問題が解消することが判明しました。帰国後に追加のピアリングの設定を行い、トランジットを経由する通信は大幅に減少しました。 調達の交渉 ネットワーク技術部では専用線などのネットワークサービス、トランジット、ネットワーク機器などのハードウエアを他社から調達してネットワークを作っています。そのため、この調達に関する交渉を行うことはピアリングと同じくらい重要な業務で、「固定ID単価1.0倍」の達成にも大きくかかわってきます。 多くのサービスやハードウエアの調達交渉は日本の担当営業が居て日本で行えるのですが、イベント会場には「各社の営業（特に外資は本国の人）、実際にサービスを利用している同業他社、調達先のライバルとなる会社」などの関係者が揃っており、交渉を進めるには絶好の条件が整っています。 特に国際回線などは本国の担当者と話した方が良い条件が引き出せることがありますし、オンライン会議ではなく異国の地で顔を合わせて交渉した方が話が進みやすいような気がします。 ネットワーク技術部では主要なネットワークサービスやトランジットについて毎年契約更改による価格の見直しを行っています。Peering Asia 4.0が開催された2022年11月もこの契約更改を直前に控えており、会場で希望の条件などについて各社と交渉を行いました。 その他 ピアリングの交渉の他にも、経済発展が著しい東南アジアの海底ケーブルやネットワーク事情、大手コンテンツ事業者の今後の通信量の増加についての予測や設備増強計画についての情報（これはBIGLOBEの設備計画を考える上でも役立ちます）、昨今発生している国家間の政治的な対立がインターネットに与える影響についてなど、貴重なディスカッションをすることができました。 また、会期中にとあるゲームのアップデートがあり、大きなトラフィックが発生する事象がありました。それによりとある回線の帯域が逼迫しそうになったため、そのゲームのアップデートを配信しているコンテンツ事業者の担当者とリアルタイムにトラフィック量を見ながら問題の解決のためディスカッションをするということもありました。 おわりに 〜この仕事の楽しさ〜 人それぞれかと思いますが、私は「BIGLOBEはもちろん、日本、そしてアジアのインターネットをよくしたい」という強い思いを持ってこの仕事をしています。その中でもピアリングの仕事の楽しさは以下のような点にあるのかと思います。 さまざまなデータを集め、情報をキャッチアップし、BGPやインターネットプロトコルという決められたルールの中で、戦略を組み立てる楽しさ 自分の立てた戦略がうまくいった際に、実際に数字で成果が見られる楽しさと、達成感。 （少々大げさですが）自分の仕事が数百万のBIGLOBE会員に影響を与え、さらには世の中を動かせるというスケールの大きさ 世界中の人と話し、さまざまな考え方や文化に触れる楽しさ 実際にピアリングの設定作業をする時、手順書に従いルータのインタフェースのパケット数のカウンタを確認しますが、双方でルータがルーティングの情報を学習し、トラフィックが流れ、パケット数のカウンタの数字が回り始める瞬間はドキドキしますし、うまくいったときは達成感があります。 一方で、仕事の成果はトラフィック量という形で具体的な数字で見えてきますし、ある意味で会社の顔として世界の人々の前に出ることになるので、慎重な発言が求められます。 作業で何かミスをすれば数百万のお客さまに迷惑を掛けることにもなります。交渉をしても具体的に成果が上がらなければ意味が無く、誤魔化しの効かないことがこの仕事の厳しいところです。 お客さまに快適にサービスをご利用いただけるよう、そして日本のインターネットが良くなるよう、BIGLOBEが日本のインターネットを引っ張っていく！位の心意気で、今後もバックボーン運営に取り組んでいきます。 長くなりましたが、最後までお読み頂きありがとうございました。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。 BIGLOBEの正式な役職ではない。ピアリング交渉を担当する人について大手の外資系IT企業などでは「ピアリングコーディネーター」と呼ぶ事がある。BIGLOBEではこの役割を基盤本部ネットワーク技術部が担っている。 ↩ アメリカのロサンゼルスではトランジットの購入もしています。 ↩

2022/11/28-12/1にラスベガスで開催された世界規模のカンファレンスイベント「Amazon Web Service (AWS) re:Invent 2022」に弊社社員が参加してきました。 前回の「AWS re:Invent 2022～社内参加報告会」前編に続いて、今回は後編をお届けします。 ＜「AWS re:Invent 2022～参加報告」（前編）はこちら＞ re:Inventは、経験の宝庫。AWSの最前線を体感（佐藤） 英語の心配について どんな経験ができるか AWSの最前線を体感できる 発表された新サービスをすぐにキャッチアップできる 手を動かしながら、AWSへの理解を深められる 他企業のノウハウを知ることができる 「世の中をみて、世の中から学ぶ」。参加企業のエンジニアとフランクな意見交換（宮下） 「世の中を見て、世の中から学ぶ」 エンジニアとの交流 世の中のトレンドを感じ取れる 「継続して成長する」 Workshopで手を動かしまくる BIGLOBE社員からAWSさまへの質問タイム re:Inventは、経験の宝庫。AWSの最前線を体感（佐藤） 佐藤 竣介 (さとう しゅんすけ) 基盤本部 システム戦略部 システム戦略グループ 新卒入社3年目 佐藤：re:Inventの感想は、一言でいうと「最高」に尽きます。一番感動したのはそこにいる全ての人がAWSを利用しているエンジニアだという事実です。私もそのうち一人であることにとても興奮しました。 上司からre:Inventの話があったとき、すぐに手を挙げたのですが、その理由は3つあります。 ・以前からこのイベントの凄さを聞いていた（行くと顔つきが変わるらしい） ・AWSの資格をいくつか持っていたので、最前線の場所に行ってみたい ・海外に行ったことがないので、ただただ行きたい！ そのような参加の期待が膨らむ中で、不安もありました。 ・初海外で英語が心配 ・3年目社員がBIGLOBEの代表としてどんな経験を持ち帰ることができるのか、責任重大 しかし、そのように不安に思う必要は全くなかったと思える程、最高の経験をしました。今回は、私が感じた不安を掘り下げながら、どのような経験をしたのかご報告します。 英語の心配について 経由地のシアトルで、ガチガチになりながら有名コーヒーチェーンで注文したところ、僕だけなぜか名前を聞かれたんです(笑)　今思うと英語が苦手そうな人に対して、注文を取り違えないように名前で管理してくれたのだと思うのですが、僕だけ名前で呼ばれるのは恥ずかしかったですね。しかも「SATO」がうまく通じず「SANTO～」と呼ばれてしまったのでなおさらです(笑) そのような状態の英語力だったのですが、1週間ラスベガスにいると英語の環境にも慣れてきて、拙い英語でも臆せずコミュニケーションを取ることができました。完璧な英語を話せなくても心配無用です！ どんな経験ができるか AWSの最前線を体感できる KeyNote（基調講演）の規模と熱気を体感できるのは現地だからこそ。AWSの新サービスが発表されるたびに大歓声が起き、「最前線に居合わせているんだ」という感覚で気持ちが高ぶりました。 発表された新サービスをすぐにキャッチアップできる 新サービス発表の翌日には早速セッションが用意されているので、僕もすぐさま予約して参加しました。この情報収集のスピード感も現地でしか体験できないことだと思っています。 ここで、参加したセッション「AWS Clean Rooms」というサービスについて、少しご紹介します。 「AWS Clean Rooms」は、分散している情報をひとまとめにして他の基盤に連携できるサービスです。連携情報に権限の制限をかけられるので、共有や制御の情報ガバナンスも容易にできるというわけです。BIGLOBEの分析系の基盤にも活かせるのではという期待をもちながら聴講しました。 手を動かしながら、AWSへの理解を深められる 私は6つのWorkshop（ハンズオン）に参加したのですが、そのうち印象に残った「SageMaker canvas」という機械学習のハンズオンについてご紹介します。 「SageMaker canvas」はノーコードの機械学習のサービスです。従来の環境構築やモデルの調整は不要で、収集した情報を「SageMaker canvas」に登録し、使いたいモデルを選択して学習させるだけで簡単に機械学習を実践できます。 学習の前にプレビューで予測の精度を確認できるので、機械学習に関する深い知識がなくてもすぐに実践できます。どの情報が予測に役立っているかを確認できるので、学習させるデータを簡単にブラッシュアップできるところが印象的でした。BIGLOBEでも多くのデータを保有しているので、機械学習を導入する最初のステップとしては非常に良いのではと思います。 他企業のノウハウを知ることができる 参加企業の方々とのコミュニケーションの中で、大変興味深い話を聞くことができました。特に、AWS利用を推進しているBIGLOBEとしては、社員のみんながAWSを理解することが業務の効率化や次期基盤検討において非常に有効なのだということを改めて実感しました。 以上、当初の不安を吹き飛ばしてくれるくらい、1週間でたくさんの経験ができました。 re:Inventはまさに経験の宝庫です。英語が分からなくてもAWSの用語が分かればなんとかなりますし、Workshopではもくもく作業できるものもあります。 AWSの知識があればあるほど楽しいので、若手の方は勉強のモチベーションもあがると思います。 忙しくて参加をためらう方もいるかもしれませんが、きっとチームメンバーがフォローしてくれるので、次回はぜひ手を挙げてこの熱量や非日常を体験してください。   ――以上、佐藤さんの報告でした！次は中途入社2年目の宮下さんの報告です。   「世の中をみて、世の中から学ぶ」。参加企業のエンジニアとフランクな意見交換（宮下） 宮下 秀太 (みやした しゅうた) 基盤本部 システム戦略部 基盤横断システムグループ 2021年中途入社（社会人7年目） 宮下：re:Inventへの参加は、 ビッグローブマインド にある「世の中をみて、世の中から学ぶ」「継続的に成長する」という観点でとても有益なものでした。この2つのマインドから掘り下げて報告します。 「世の中を見て、世の中から学ぶ」 エンジニアとの交流 多数参加している日本人エンジニアとの懇親会で、意見交換できたのはとても有益でした。たとえば、どんなAWSサービスを使っているか、どのセッションが良かったか、こんな課題をどう解決しているかなど、フランクに話が聞けたので貴重な機会となりました。 世の中のトレンドを感じ取れる インターネットで調べたり、基調講演の動画を見たりしてトレンドをキャッチアップすることもできますが、現地に行くことで実際にどんなことに関心が集まっているのかを肌で感じられたのが非常に良かったです。その中で印象に残った基調講演がこの2つです。 ①CEOによる基調講演 いくつかあったトピックスの中からデータ活用についてご紹介します。データの活用は収集だけではなく、その価値を見出すために戦略的に分析をしていかないといけないという内容です。莫大なデータの分析において「適切なツール、統合、ガバナンス、可視化」の4つの要素が大事だとおっしゃっていました。 ②CTOによる基調講演 私たちが現在改修しようとしている基幹システムは現在同期的に処理を行っており、密結合になっています。よって、どこかで処理が失敗するとそれが全体に波及しますし、機能の追加や改修が大変です。一方、「イベントドリブン」、「メッセージング」、「分散システム」といった要素を取り入れて非同期処理を行うことで、システムを疎結合に保つことができます。非同期処理で疎結合にすることで責務ごとにシステムを分けやすくなります。その結果、処理失敗の影響が最小限に済んだり、機能追加や改修をリリースできるサイクルが早くなったりといった恩恵が得られるかと思います。世の中の変化に柔軟に対応するシステムづくりをするためには必要なことだと感じました。 データ分析（AI/ML）とイベントドリブン分散システムのセッションは非常に人気で長蛇の列ができていました。基調講演で発表があったこともあり、参加者が関心を示したのかなと思います。 BIGLOBEにおけるAWSへの移行フェーズはリフトの終盤ですが、シフトこそが重要だと個人的には思っています。そしてその先、ビジネスに直結できることを目指していきたいと思いました。 「継続して成長する」 Workshopで手を動かしまくる 8割方手を動かすWorkshopを意図的に選びました。機械学習、サーバーレスアプリケーション作成、データアナリティクス、イベントドリブンなアーキテクチャの作成など計8つです。 その中でも一番印象に残ったのが、ネットワークのトラブルシューティングです。 お題が与えられていて、アプリケーションの中で発生したトラブルを解決するというものですが、登場するサービスやリソースが非常に多く、AWSのネットワーク知識の集合体といった感じで非常に骨の折れるWorkshopでした。 ヒントを使った問題もありますが、6問中4問正解しました。このWorkshopは知らなかったサービスやリソース、疎かったネットワークへの知識についてもキャッチアップできたので、大変勉強になりました。 おまけですが、re:Inventでは面白いセッションもあって、「5K RUN」というチャリティ早朝ランニングに参加しました。朝6時からのスタートで、広い道路を封鎖して片道2.5Kのコースです。5Kは意外と長く、想像していたより疲れました。結果は…良いとも悪いとも言えない微妙な順位で…(笑) ですが、早朝のラスベガスを走るという体験は滅多にできないことなので、参加して良かったです！ 4:30起床、大きなアレーナでストレッチをしてからRUN 最後に、参加メンバーが口をそろえて言っていますが、re:Inventは英語が話せるとより一層楽しいです。現地での1週間でも、英語に多く接することでスキルは上がったように思います。また、自社だけではなく、日本各社や世界からの参加者と交流することで視野が広くなり、知識も増えました。そういう意味でも、みなさんに参加してほしいと思います。   ――以上、宮下さんの報告でした！ BIGLOBE社員からAWSさまへの質問タイム BIGLOBEの参加メンバーによる報告の後は、AWS千葉さまから最新技術の解説と、AWSがどのような方向に向かっているのかについてポイントを絞って共有いただきました。その内容は割愛し、社員との質疑応答についてご紹介します。 Ｑ：多くの企業を担当されていると思いますが、他の会社と比べてBIGLOBEの特徴は何だと思いますか？ Ａ：アカウントやセキュリティの統制やCoEチームの役割や責務が良くデザインされています。社内へノウハウを展開するためのナレッジがよくできていて、ベストプラクティスだと思います。BIGLOBEのナレッジをもっと世の中に発信してほしいのでAWSへの移行が一段落つきましたらAWSのイベントにぜひ出てください(笑)   Ｑ：BIGLOBEのビジネスを成功させるためにAWSとして提案したいことは？ Ａ：BIGLOBEがAWSを活用されている方向性は正しいです。あえて提案させていただくなら、ひとつは、AWSにリフトしたサービスをクラウドの活用できる形に最適化しメリットをうまく享受していただくこと。もうひとつはデータや機械学習を活用したビジネスを生み出し広げていくためにAWSの基盤を使っていただくこと。それらに注力して今後もご支援していきたいと思っています。   報告会の締めはAWS中野さまが早押しクイズをしてくださり、大盛りあがりで終了しました🎉 以上、AWS re:Invent 2022参加報告会の様子をお届けしました。 報告会に対するアンケートには、若手メンバーから「熱量が感じられモチベーションにつながる！」「機会があれば、re:Inventに参加したい！」などの声があがりました。   現在BIGLOBEでは24卒向け新卒採用活動を行っています。BIGLOBEではこのように若手メンバーも外にでて成長する機会がありますので、少しでも興味をお持ちいただけましたら、こちらの新卒サイトをご覧ください。 www.biglobe.co.jp 最後までお読みいただきありがとうございました！   ※ Amazon Web Services、 re:Invent は、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

  ラスベガスで開催されたカンファレンスイベント「Amazon Web Service (AWS) re:Invent 2022」に弊社社員が参加してきました。今回は、社内で行われた「re:Invent参加報告会」の様子をお届けします。 この報告会ではAWSさまにもお越しいただき、新機能を解説していただいたり、AWSにまつわるクイズ大会で大いに盛りあがりました。 AWS re:Invent 2022 とは 毎年ラスベガスで開催されるAWSの世界最大の「学習型」カンファレンスイベント。 新サービス発表のほか、基調講演やワークショップ、世界中のエンジニアと情報交換する機会が提供されるなど、大変学びのあるイベントです。 ・2022年11月28日〜12月2日（3年ぶりの現地開催） ・全世界から50,000人以上が参加（日本から1,000人以上） ・セッション数は2,700以上 3年前に参加した際の様子はこちらでも紹介しています。 style.biglobe.co.jp 今回BIGLOBEでは、役員1名とベテラン、中堅、若手のエンジニア3名が2022/11/28-12/1にラスベガスへ行ってまいりました！ 参加して得られたものや、現地での様子はどのようなものだったのか。是非ご覧ください。   参加の最大の目的は、前に進む原動力を得ること（鴨川） 約5万人の世界中のエンジニアが切磋琢磨する光景に大きな刺激（永末） Keynote（基調講演） AWS現地エンジニアとのエグゼクティブセッション 参加企業とのネットワーキング Gamified learning 参加の最大の目的は、前に進む原動力を得ること（鴨川） ――まずはじめに、同行した役員（基盤本部 本部長）からひとこと。 鴨川 比呂志 (かもがわ ひろし) 執行役員常務 兼 基盤本部 本部長 鴨川： 3年ぶりの現地開催となりましたね。AWSだけで5万人以上のエンジニアを集客する大規模イベント「re:invent」は、コロナ禍前に参加した時よりもさらにエネルギッシュになっていて、すごい熱量を感じました。最新技術の知識を吸収してもらうことももちろん大事ですが、最大の目的は前に進む原動力を得ること。そういう意味でも今回参加したメンバーは良い経験ができたのではないでしょうか。 ビッグローブマインド に「世の中をみて、世の中から学ぶ」があるように、外に出て初めて分かることがあります。社員のみなさんは、外に出る機会があればぜひ積極的にチャレンジしてほしいと思います。   ――それでは参加メンバーの報告へ続きます。グループリーダーの永末さんの報告です。   約5万人の世界中のエンジニアが切磋琢磨する光景に大きな刺激（永末） 永末 喜己（ながすえ よしき） 基盤本部 クラウド技術部 クラウド共有エンジニアリンググループ グループリーダー 永末：ラスベガスの6つのホテルが会場になっていて、端から端まで歩いたら1時間もあるという、とにかく大規模なイベントでしたね。アメリカらしく、バスケットやゲームコーナーもあって、お祭り騒ぎでした(笑) これだけ聞くと遊んできたように思われるかもしれませんが、実際は、朝からAWSエンジニアとミーティングをして、それから会場へ移動しセッションや講演に参加、夜は会社の業務をこなしてから寝るという、かなり忙しい毎日でした。 現地での活動内容はこちらです。 ●セッション受講 　・Keynote（基調講演） 　・breakout session 　・workshop（ハンズオン） 　・gamified learning（ゲーム形式の学習イベント） ●AWS現地エンジニアとのエグゼクティブセッション ●参加企業とのネットワーキング ●参加者同士の交流イベント ●EXPO（各社展示会、ディスカッションブース） このなかから、印象に残ったものをピックアップしてご紹介します。 Keynote（基調講演） 多数のサービスが発表された基調講演では、データ分析やAI/ML(人工知能 / 機械学習)に関するものが印象に残りました。業界特化のサービス「Amazon Supply Chain」は、Amazon.comの経験を元に、各拠点の在庫可視化や潜在リスクを通知するといった機械学習を提供しています。 これらの基調講演を通じて、インフラだけにクラウドを使うのは時代遅れだということを感じました。 AWS現地エンジニアとのエグゼクティブセッション AWSさまにセッティングいただき、AWSトップエンジニア2名（北米/アジア通信事業者担当者）と、AI/MLをワールドワイドでどう活用しているのかについて議論しました。 北米各社はAWSを活用してお客さまの感情分析に取り組んだり、お客さまが必要になりそうなタイミングで事業者から電話をかけることで電話対応にかかる時間を短縮しているそうです。これはBIGLOBEのコールセンターにも適用できそうだと大きなヒントになりました。 参加企業とのネットワーキング 参加企業の方々と、連日情報交換をしました。BIGLOBEよりも規模の大きな企業の方々とも話しましたが、BIGLOBEの技術は世界でも通用すること、また、進んでいる方向は間違っていないと感じました。このままさらに技術力を磨いていこうと思いました。 また、技術的な話だけではなく、素早い開発のための組織体制や権限統制などの話も聞けたので、ぜひ取り入れていきたいです。 Gamified learning ゲームを通じてAWSを学ぶというイベントで、前後に座っていた外国人の方々と3、4人のチームになって、システム構築の課題に取り組みました。チームの中では自分だけが英語を話せなかったのですが気合で乗り切りました(笑)　英語ができたほうがもっと楽しめたと思うので、勉強意欲が湧きましたね。 このコンテンツは、演習形式なので新たな気づきを得られましたし、なにより外国人との共同作業はとても刺激的でした。私が主導する場面もあったので世界に負けていないという自信になりましたし、成績も途中までは約60〜70チーム中1位だったんです！結果的には中間位で終了しましたが(笑)、もう少し頑張りたかったですね。 まとめです。圧倒的な規模と熱量の中、約5万人の世界中のエンジニアが切磋琢磨する光景に大きな刺激を受けた1週間でした。 このイベントを通じてBIGLOBEのエンジニアは世界でも通用するという自信もついたので、さらにレベルアップして進んでいきたいです。欲を言えば、一緒に働くエンジニアの数がもっと増えたら最高ですね。 BIGLOBEでのクラウド活用はまだはじまったばかりです。営業や企画がもつ課題をAWSのユニークなサービスで解決できるよう、活動していきたいと思います。 最後にみなさんに伝えたいのは、「勇気を出して世界に飛び出そう！」ということです。日本では得られない経験から大きな刺激を受けるチャンスです。 ラスベガス行きの飛行機は満席でした。世界に取り残されないように、行きたい人は手を挙げてください！若手エンジニアだけではなく、グループリーダーにも参加をお薦めします。技術的な話だけではなく、組織づくりの面でも得るものがあるからです。   ――　以上、永末さんの報告でした。後編では新卒入社3年目の佐藤さん、中途入社2年目の宮下さんの報告へ続きます！   ＜「AWS re:Invent 2022～参加報告」（後編）はこちら＞   ※ Amazon Web Servicesは、米国その他諸国における、Amazon.com, Inc. またはその関連会社の商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

ビジネスはスピードが命！承認だって、内容に問題がなければササッと終わらせたいですよね。そこでGoogleのノーコード開発ツールAppSheetを活用し、Gmail上で承認・却下の操作ができる承認アプリを作ってみました。 開発部門（基盤本部）の高玉です。BIGLOBEは業務にGoogle Workspaceを利用していて、メールはGmailを使っています。Gmailを使っていると分かるのですが、GoogleドライブやGoogleドキュメントから届くメールは動的メール（Dynamic Email）になっています。メールの文面にボタンやテキスト入力欄が埋め込まれていて、そのまま操作できます。 AppSheetを使えば、この動的メールを使った社内システムを作ることができます。この記事では簡易的な承認アプリを題材に、その作り方を丁寧に解説していきます。この記事で基本を押さえれば、AppSheetが提供するより高機能な承認アプリのテンプレートを理解するのにも役立ちます。現場に導入するには、慣れないAppSheetを使って申請してもらうより、従来のGoogleフォームを使う方がスムーズでしょう。そこで、Googleフォーム経由でAppSheetにデータを登録する方法も解説しています。 AppSheet上の画面操作を丁寧に解説した分、記事が長くなってしまいました。しかし、実際に手を動かしてみると、それほど時間はかかりません。ぜひお試しください。 .table-of-contents ul { display: none; } 動的メール、AppSheetで作れるってよ AppSheetを試して分かったデータモデリングの重要さ ここから先は自分で作りたい方向け まずはデータモデリングから スプレッドシートからアプリを作る モデリング結果に従ってスプレッドシートを作る データ型を設定する 自動でデータ項目を入力する 承認者だけが承認する Gmail上で承認する Automationでbotを追加する Quick edit columnsを追加する Googleフォームから申請する モデリング結果に従ってフォームを作る フォームのイベントをApps Scriptで受け取る Apps ScriptからAppsSheetのAPIを呼び出す まとめ 動的メール、AppSheetで作れるってよ 動的メールはAMP for Emailという技術で実現されています。 developers.google.com 社内システムから届くメールも動的メールになっていると便利ですよね。ただ、動的メールを送信するには、Googleの事前審査を受けてセキュリティ的に問題がないことを確認してもらうなど、色々と手間がかかります。 しかし、 Google Workspace Review 2022 を視聴した時に、AppSheetを使えば動的メールを送信できることを知りました（ちなみに、2023年3月23～24日に さらに大規模なGoogle Workspaceのイベント を開催されるそうです）。Googleのブログでその様子を紹介しています。 （ Gmail の受信トレイでノーコード アプリを利用する方法 | Google Cloud 公式ブログ より引用） AppSheetで社内システムを作れることは前から知っていたのですが、動的メールを送信できることを知り、俄然興味が湧きました。早速試作に取り掛かり、承認者がGmail上で承認・却下ボタンを押せるところまで、何とか作ることができました。 私がやりたかったことはあくまで「動的メールを使うこと」で、AppSheetを使うことではありません。そこで、申請者には使い慣れたGoogleフォームから申請できるよう工夫しました。GoogleフォームとAppSheetを連携させるところにはGoogle Apps Scriptを使っているのでノーコードにはなりませんが、利用者にとっては違和感なく導入できると思います。 AppSheetを試して分かったデータモデリングの重要さ 先に、AppSheetを初めて使って感じたことをご紹介します。 AppSheetはコードを書かずに、色々なアプリを作ることができます。では、そうして生まれたたくさんのアプリを比較すると、何が違ってくるのでしょうか？デザインの違いなどもありますが、本質的にはデータ構造が違ってきます。データ構造の違いが、ビジネスロジックの違いになって現れます。 なので、AppSheetでアプリを作るには、アプリ使うデータを設計するデータモデリングが必須になります。特に、AppSheetはリレーショナルデータベースを使ってアプリを動かします。なので、リレーショナルモデルの理解が必須です。行・レコードを一意に特定するためのキーについても良く理解する必要があります。 これから紹介する承認アプリは簡易的なもののため、リレーショナルモデルの説明は省略しますが、キーについては事あるごとに気をつけるようお伝えしていきます。 より複雑なビジネスロジックを実装したくなったら、ぜひリレーショナルモデルについて調べてみてください。コードを書く時間を減らせる分、データモデリングの時間を意識的に増やす必要があると強く思いました。 ここから先は自分で作りたい方向け ここからは、承認アプリを作っていく過程を全てご紹介していきます。簡単なロジックなのですが、画面を多用することもあり、かなり長い記事になってしまいました。ただ、データ構造もシンプルにして、AppSheetに慣れていない方にも工夫したつもりです。もしよろしければ最後までお付き合いください。 AppSheetやリレーショナルモデルに慣れている方は、公開されているテンプレートを実際にお試しいただくのがよいでしょう。AppSheetはアプリの雛形となる テンプレートを多数公開 しています。その中に Approvals や Manager Approvals があります。動的メールの送信も設定済みです。Copy and Customizeボタンを押して自分の環境にコピーして試すことができます。 「テンプレートを試してみたけれど、中身を読み解くのはちょっと難しそう」と感じられた方は、どうぞ続きをお楽しみください。 まずはデータモデリングから ここからは、 申請者がGoogleフォームで申請し 承認者がGmail上で承認する 承認アプリを作る過程をご紹介していきます。開発するステップは次の通りです。 データモデリング GoogleスプレッドシートからAppSheetのアプリを作成 Gmailにメールを送信してメール上で承認 Googleフォームから申請してAppSheetにデータ連携 では早速、データモデリングに取り組んでいきます。アプリで使うデータを設計します。コードを書かずに開発できるのがAppSheetの特長ですが、コードを書かずに済む時間をぜひデータモデリングに充てていただければと思います。 登場人物は、申請者と承認者です。 申請者は申請画面で、申請内容と承認者のメールアドレスを入力します。 承認者は承認画面で、申請を承認、もしくは、却下します。 承認アプリで必要になる申請データには次の6つの項目が必要です。 申請 申請時刻 申請者のメールアドレス 申請内容 承認者のメールアドレス 承認結果（承認 or 却下） 承認時刻 データベースに保存する時に重要なのが、どの項目をKey（キー）として扱うか？です。もしキーが同じデータが複数あると、それらデータは同じデータとして扱われてしまいます。違うデータには、必ず違うキーを設定する必要があります。 もし申請時刻をキーにしてしまうと、同時に申請があった場合にそれぞれを識別することができなくなります。そこで、キーになる項目として申請IDを新しく追加することにしました。申請は次の7つのデータ項目で表現します。 申請 申請ID （追加） 申請時刻 申請者のメールアドレス 申請内容 承認者のメールアドレス 承認結果（承認 or 却下） 承認時刻 試行錯誤を繰り返すうちに、もしも期待どおりに動かなくなったら、キーとなる項目を正しく作れているかを確認してみてください。 スプレッドシートからアプリを作る データモデリングが完了したらGoogleスプレッドシートを新しく作り、そのスプレッドシートを元にAppSheetでアプリを作ります。 モデリング結果に従ってスプレッドシートを作る スプレッドシートにシートを追加し、シートの名前を 申請 にします。そして、モデリング結果の項目を列にして入力します。 このスプレッドシートを元に、AppSheetで承認アプリを作ります。スプレッドシート上部のメニュー「拡張機能」> 「AppSheet」> 「アプリを作成」を選択します。 AppSheetがスプレッドシートを読み取り、自動的にアプリを作ってくれます。 スマホ画面のプラス（＋）アイコンを押すと、新しい申請を追加することができます。 承認結果、承認時刻以外の申請項目を入力して、Saveボタンを押してみます。 すると、申請が保存されます。表示がおかしいですが今は気にせず、リストの一番上をタップします。 すると、先ほど入力した申請が表示されます。 えんぴつアイコンを押せば、追加した申請を編集できます。また、画面下部の「申請」を押せば、リスト表示になります。 申請シートにも、申請した内容が表示されています。 スプレッドシートからAppSheetを起動しただけで、ごく簡単な承認アプリを作ることができました👏 このアプリをカスタマイズして、さらに使いやすくしていきます。Customize your app（あなたのアプリをカスタマイズする）ボタンを押して先に進むと、以下の画面に変わります。 この画面は古い開発画面（レガシーエディター）です。ここから先はレガシーエディターで説明をしていきます。お使いの環境によっては画面レイアウトが異なっているかもしれません。画面の見栄えを変更するには、画面上部の アイコンを押してください。 データ型を設定する 見栄えを修正したい気持ちを抑えて、まずはデータ型（データ項目のTYPE）を設定していきます。AppSheetはデータ型に応じて入力画面を自動的に作り直してくれるので入力が楽になりますし、不正なデータを保存しなくて済むようになります。 まずはデータ項目が並ぶテーブルを確認します。左ペインでDataを選択し、Tablesタブで「申請」テーブルを選択します。 そして申請テーブルの上部View Columns（列を見る）ボタンを押します。上部にあるColumnsタブを選択し、申請テーブルを選択するのと同じ操作になります。 TYPE列を見ると、どの項目もTextになっています 1 。適切なものを選択していきます。 NAME（項目名） TYPE（タイプ） _RowNumber Number 申請ID Text 申請時刻 DateTime 申請者のメールアドレス Email 申請内容 Text 承認者のメールアドレス Email 承認結果 Enum 承認時刻 DateTime 承認結果は Enum にします。Enumeration（列挙）の略です。入力する時に 承認 と 却下 の2つから選択できるように設定します。承認結果の左横にあるえんぴつアイコンをクリックします。 Typeを Enum に設定し、Type DetailsのValuesにあるAddボタンを2回押して、2つの項目 承認 、 却下 を入力します。最後に右上にあるDoneボタンを押して終了です。 これで申請テーブルのTYPEの設定が終了しました。 テーブルの設定が終わったら、AppSheetの画面右上にあるSAVEボタンを押しましょう。SAVEボタンが押されるまで、アプリに変更は反映されません。そしてもう一度、申請を追加してみます。右ペインに画面のプレビューが表示されます（もし表示されていなければ、右端にある三角形のアイコンを押してください）。＋（プラス）アイコンを押すと、申請の入力画面が表示されます。 TYPEを変更した項目は、先ほどから表示が変わっています。申請時刻はカレンダーを使って入力できるようになり、メールアドレスはアットマーク（@）を使った正しい形式でなければ、This entry is invalidと赤字で警告されてSaveできなくなりました。 データ項目のTYPEを正しく指定したおかげで入力が楽になり、不正なデータを保存せずに済むようになりました。 自動でデータ項目を入力する 新しい申請を追加する時に、申請IDの項目には最初からランダムな文字列が入力されていました。このように、自動で入力される項目を増やしていきます。先ほどと同様に、左ペインDataから、Columnsタブで申請テーブルを選択します。自動入力の設定は、テーブルの設定を右にスクロールすると出てくるINITIAL VALUE（初期値）を使います。上から2つ目の申請IDにはすでに UNIQUEID() と入力されています。 さらに、申請時刻に UTCNOW() + "009:00:00" 、申請者のメールアドレスに USEREMAIL() と入力していきます。 UTCNOW() はUTC時間の現在時刻で、そこに日本のタイムゾーン+9時間を反映します。 USEREMAIL() はアクセスした人のメールアドレスを入力します。 NAME（項目名） INITIAL VALUE _RowNumber 申請ID =UNIQUEID() 申請時刻 =UTCNOW() + "009:00:00" 申請者のメールアドレス =USEREMAIL() 申請内容 承認者のメールアドレス 承認結果 承認時刻 承認時刻はINITIAL VALUEではなく、FOMULAに UTCNOW() + "009:00:00" を入力します。少し左にスクロールして戻ります。これは App fomula という機能で値が変化した時に関数を実行します 2 NAME（項目名） TYPE FOMULA INITIAL VALUE _RowNumber Number 申請ID Text =UNIQUEID() 申請時刻 DateTime =UTCNOW() + "009:00:00" 申請者のメールアドレス Email =USEREMAIL() 申請内容 Text 承認者のメールアドレス Email 承認結果 Enum 承認時刻 DateTime =UTCNOW() + "009:00:00" AppSheetの画面右上にあるSAVEボタンを押して、設定を反映します。先ほどと同じように申請を作成します。＋（プラス）アイコンを押して申請画面を表示すると、申請時刻と申請者のメールアドレスが最初から入力されています。ここで申請をSaveしておきます。 今度は、先ほどの申請で承認結果を選択してみます。プレビュー画面下の申請アイコンを押し、新しい方の申請（2行目）を選択し、えんぴつアイコンをクリックします。すると承認時刻が現在時刻になっています。承認者が申請を編集し、承認結果を入力すると承認時刻が更新されるようになりました。 さて、この状態だと申請者が自分で承認結果を入力できてしまいますね。次のステップで修正していきます。 承認者だけが承認する 承認者だけが承認結果を編集できるようにしましょう。Columnsタブで申請テーブルを開き、右側にあるEDITABLE?（編集できるか？）に編集を可能にする条件を設定します。 承認者がアクセスしている時にだけ、承認結果を編集可能にします。そこで、承認結果のEDITABLE?に、 [承認者のメールアドレス]=USEREMAIL() と入力します。ただ、この条件を入力するために、ちょっとした操作が必要になります。承認結果の左にあるえんぴつアイコンをクリックし、Update Behavior（データを更新するときの振る舞い）の下にあるEditableの更に右にあるフラスコアイコンをクリックします。 条件 [承認者のメールアドレス]=USEREMAIL() を入力し、右上のDoneボタンを押します。 では、正しく設定できたか画面で確認します。まず画面右上のSaveボタンを押して変更を反映します。次に、画面プレビューから一番最初の申請を選択してみます。すると、承認・却下のボタンが表示されなくなりました。新しい申請を追加する時も同様です。 次に利用者のメールアドレスを承認者のメールアドレスに変更してみます。プレビュー画面の下にあるPreview app asで承認者のメールアドレスを入力しApplyボタンを押します。すると承認・却下のボタンが表示されるようになりました。承認・却下ボタンを押してSaveすと、承認時刻が更新されます。 EDITABLE?のチェックを外せば、編集できないようになります。申請時刻、申請者のメールアドレスはEDITABLE?のチェックを外しても、INITIAL VALUEが設定されているので自動入力されます。 また、申請者しか申請内容を編集できないように、申請内容のEDITABLE?に [申請者のメールアドレス]=USEREMAIL() と入力しておきましょう。 NAME（項目名） EDITABLE? _RowNumber 申請ID ✔ 申請時刻 申請者のメールアドレス 申請内容 [申請者のメールアドレス]=USEREMAIL() 承認者のメールアドレス ✔ 承認結果 [承認者のメールアドレス]=USEREMAIL() 承認時刻 ✔ これで簡易版の承認アプリ 3 の完成です👏。いよいよ、この記事の目玉である、Gmail上での承認操作を実現していきます。 おまけで、申請一覧の表示を整えておきます（この先の説明には関係ありませんが、見栄えを良くしたい方もいらっしゃると思うので）。左ペインUXを選択し、Primary Viewで申請を選びます。View typeでdeckを選び、View Options では、 Primary header: 申請内容 Secondary header: 申請者のメールアドレス Summary column: 申請時刻 をそれぞれ選択すると、見栄えが良くなります。 Gmail上で承認する 新しい申請が登録されると承認者にメールを自動送信し、承認者がGmail上で承認結果を入力できるようにします。 Automationでbotを追加する Automation（自動化）でbot（ロボット）を作ることで、データの追加や変更に応じた自動処理を実行できるようになります。左ペインAutomationを選択すると、New Botの左に、オススメの自動処理が表示されます。Email on new recordを選択します。 すると、申請テーブルに新しいrecord（行）が追加されると、メールを送信するbotが作成されます。ここからは、送信する内容を調整していきます。真ん中のペインにある「Send an email」を選択します。もし、右ペインの画面プレビューに設定情報が表示されない場合、画面プレビュー上にあるギアアイコン（Settings）を選択します。 右ペイン Settings Email TypeはEmbedded app view（アプリの画面を埋め込む） Table nameは申請 ToはAddボタンを押して [承認者のメールアドレス] と入力してEnter Email subjectとEmail bodyは後で変更するので、とりあえずこのまま App view to embed in mail body（メール文面に埋め込むアプリ画面）は 申請_Detail を選択 App view to embed in mail bodyの下にあるPreview email body（メール文面のプレビュー）ボタンを押すと、別タブが開きメールのプレビューが表示されます。 画面の細かい調整は後回しにして、新しい申請に対してメールが送信されるかをテストしてみます。AppSheetはアプリの状態をPrototype（試作）とDeploy（公開）で切り替えられます。まずはPrototypeのまま開発すると影響範囲が狭くて安全なのですが、アプリの開発者にしかメールを送信できません。そこで、テストのために承認者に自分のメールアドレスを追加して、自分宛てに承認を依頼してみます。 忘れずにSaveをしてから続けます。画面プレビューで申請を追加し、承認者に自分のメールアドレスを入力します。もし画面プレビューにSettingsが表示されているままの場合、プレビュー上部でスマホアイコンを選択してください。申請一覧が表示されるので、右下のプラス（＋）ボタンを押して申請を追加します。 うまく動作すれば、プレビューでみたのと同様な文面のメールが自分のところに届きます。 もしbotが期待どおりに動作しない場合は、エラーが発生していないかAudit Historyで確認します。左ペインManageを選択し、MonitorタブからAudit Historyを選択します。Launch log analyzerボタンを押すと別タブが開き、実行ログを確認できます。 ここまでで、承認依頼のメールが届くことが確認できました。いよいよ、Gmail上で承認の操作ができるようにします。 Quick edit columnsを追加する Gmail上で承認できるようにするために、Quick edit columns（列をサクッと編集）を追加します。設定したデータ項目を画面上で素早く変更できるようになります。 左ペインUXを選択し、Primary Viewsから申請を選択します。画面を下にスクロールするとRef Viewsが出てきます。出てこない場合は、Show system views（システム画面を表示）ボタンを押してください。 Ref Viewsの下にある、 申請_Detail を選択します。View Optionsの下にあるQuick edit columnsでAddボタンを押して枠を追加し 承認結果 を選択します。すると 申請_Detail 画面上に承認・却下ボタンが表示され、操作できるようになります。ボタンが表示されない場合は、画面プレビュー下のPreview app asが承認者のメールアドレスになっているか確認してください。 忘れずにSaveしてから、再び自分を承認者にして申請を追加します。メールの本文には、先ほど設定した 申請_Detail 画面が表示され、Gmail上で承認・却下ボタンを操作できるようになりました👏 承認ボタンを押すと、画面に小さく Saving...と表示され、それが終わると、承認時刻が更新されます。 Googleフォームから申請する ここまでで承認者がGmail上で承認できるアプリが完成しました。しかし、新しく申請をするためにAppSheetを起動してもらう必要があります。AppSheetに馴染みのない方でも申請できるよう、Googleフォームから申請できるようにしてみます。 Googleフォームから入力したデータをAppSheetに連携する方法は、 Googleフォーム用のAppSheetアドオン を使うやり方 4 と、AppSheetのAPIを呼び出すやり方があります。どちらもApps Scriptによるコーディングが必要になります。組織によってはアドオンが有効化されていない場合もあるので、今回は後者のAPIによる連携をご紹介します。 先にデータの流れを紹介しておくと、(1) Googleフォームへ入力、(2) 回答用のGoogleスプレッドシートに追記、(3) Apps Scriptを起動しAppSheet API呼び出し、(4) AppSheetのbotを起動し承認者に承認依頼のメールを送信、となります。(3) でコーディングが必要になります。 モデリング結果に従ってフォームを作る Googleフォームを新しく作成し、最初に実施したデータモデリングの結果に従って、入力する項目を決めていきます。 申請ID、申請時刻、申請者のメールアドレス 5 はApps Scriptで生成し、申請に必要なその他の項目をフォームに作っていきます。 申請 申請ID（ Apps Script で生成） 申請時刻（ Apps Script で生成） 申請者のメールアドレス（ Apps Script で生成） 申請内容（フォームで入力） 承認者のメールアドレス（フォームで選択） 承認結果（申請時は不要） 承認時刻（申請時は不要） 次は、フォームに入力された申請を処理するApps Scriptを準備します。 フォームのイベントをApps Scriptで受け取る Googleフォームへの入力をトリガーにしてApps Scriptを実行する方法は 2つあります が、フォームの回答に対してスプレッドシートを作る方がスクリプトの記述量を少なくできます。 フォームの回答タブから、スプレッドシートをリンクし、新しいスプレッドシートを作成します。 回答のスプレッドシートの上部メニュー「拡張機能」> 「Apps Script」でスクリプトエディターを開きます。 フォームからスプレッドシートに連携される送信イベントの仕様はこちらです。 developers.google.com まずは、フォームからApps Scriptにイベントが連携されるかを確認します。次のスクリプトをスクリプトエディターに入力して保存します。実行ログにフォームから受け取った情報を表示するスクリプトです。なお、保存する時にプロジェクト名を決めるように促されます。どんな名前でも良いですが、今回はApplicationFormと入力しました。 function onFormSubmit(e) { console.log(e.namedValues); } 次に、フォームからイベントを受信するためにトリガーを設定します。スクリプトエディターの左ペインでタイマーアイコンのトリガーを選択します。 少し分かりづらいのですが、画面右下にあるトリガーを追加ボタンを押します。 実行する関数を選択 onFormSubmit 実行するデプロイを選択 Head イベントのソースを選択 スプレッドシートから イベントの種類を選択 フォーム送信時 エラー通知設定 今すぐ通知を受け取る トリガーの設定ができたら、忘れずに画面右下にある保存ボタンを押します。実行権限について聞かれたら、付与を許可します。 ここまで設定できたら、フォームからApps Scriptにイベントが渡っているかを確認します。フォームに値を入力し送信ボタンを押します。 回答シートに戻って、フォームに入力した値が記録されているかを確認します。 スクリプトエディターに戻って、実行ログを確認します。左ペインの実行数を選択します。 フォームとApps Scriptの連携を確認できました。次は、Apps ScriptからAppSheetにデータを連携します。 Apps ScriptからAppsSheetのAPIを呼び出す Apps ScriptからAppSheet APIを呼び出してデータを連携します。AppSheet APIの利用方法はこちらをご覧ください。ポイントは、HTTPリクエストヘッダーにApplicationAccessKeyを、URLにApp Idとテーブル名を入れることです。 support.google.com ApplicationAccessKeyとApp Idは、AppSheetの開発画面で調べます。左ペインManageを選択し、Integrationタブを開きます。IN: from cloud services to your appにApp Idが表示されます。Enableをチェックすると、Create Application Access Keyボタンが表示されます。ボタンを押すと、Show Access Keyボタンが表示されるので押すと確認できます。これらの値が漏洩すると不正アクセスが可能になります。ご注意ください。 確認したApp IdとAccess Keyはスクリプトに記述したくないので、スクリプトプロパティに保存します。スクリプトエディターに戻って、左ペイン設定のギアアイコンを選択し、下の方にあるスクリプトプロパティで、スクリプトプロパティを編集ボタン、スクリプトプロパティを追加ボタンを押します。 APP_ID APPLICATION_ACCESS_KEY をそれぞれ追加して、AppSheetで確認した値をそれぞれ記入し保存します。 その上で、スクリプトエディターに次のスクリプトを追記します。 apply() はフォームから連携されたnamedValuesをAppSheetに追加します。 toRowObj() はフォームから連携されたnamedValuesをAppSheetのデータ形式に変換します。 appendRow() はAppSheetのAPIを呼び出して、データを追加します。追加が成功すると、追加したデータがJSON形式で返却され、失敗すると空文字が返却されます。 function apply(namedValues) { const tableName = '申請' ; return appendRow(tableName, toRowObj(namedValues)); } function toRowObj(namedValues) { const obj = { '申請ID' : Utilities.getUuid() } ; Object .keys(namedValues).forEach(key => { const value = namedValues [ key ][ 0 ] ; if (key === 'タイムスタンプ' ) { obj [ '申請時刻' ] = value; } else if (key === 'メールアドレス' ) { obj [ '申請者のメールアドレス' ] = value; } else { obj [ key ] = value; } } ) return obj; } function appendRow(tableName, rowObj) { if (!tableName) throw `テーブル名がありません。` ; if (!rowObj) throw `追加するデータがありません。` ; const props = PropertiesService.getScriptProperties().getProperties(); const appId = props [ 'APP_ID' ] ; if (!appId) throw `スクリプトプロパティにAPP_IDがありません。` ; const ApplicationAccessKey = props [ 'APPLICATION_ACCESS_KEY' ] ; if (!ApplicationAccessKey) throw `スクリプトプロパティにAPPLICATION_ACCESS_KEYがありません。` ; const url = `https://api.appsheet.com/api/v2/apps/ ${appId} /tables/ ${tableName} /Action` ; const options = { method: 'post' , headers: { ApplicationAccessKey } , contentType: 'application/json' , payload: JSON.stringify( { 'Action' : 'Add' , 'Properties' : {} , 'Rows' : [ rowObj ] } ), muteHttpExceptions: true } ; // console.log(UrlFetchApp.getRequest(url, options)); const res = UrlFetchApp.fetch(url, options); const result = { responseCode: res.getResponseCode(), contentText: res.getContentText() } console.log(result); return result; } では追記したスクリプトが正しく動作するか確認します。まずは、Apps ScriptからダミーのデータをAppSheetに追加できるかを確認します。確認のためのテストコードをスクリプトエディターに追記します。 function test_申請が成功すると_200_レスポンスと追加結果が返却される() { const namedValues = { '申請内容' : [ 'Apps Scriptの書籍を購入します。' ] , 'メールアドレス' : [ 'staff1@example.com' ] , '承認者のメールアドレス' : [ Session.getActiveUser().getEmail() ] , 'タイムスタンプ' : [ '2023/02/03 7:23:21' ] } ; const result = apply(namedValues); if (result.responseCode !== 200 || result.contentText === '' ) throw 'NG' ; } テストでは appy() の返却値を確認して、失敗していればNGの例外を出します。スクリプトエディターの実行ログに何も表示されなければ正常です。このテストをスクリプトエディターで実行すると、AppSheetにデータが追加され、スプレッドシートに新しい申請が追加され、承認依頼のメールが自分宛てに届きます。 スクリプトエディターにNGのログが表示される場合は、スクリプトエディターの実行ログや、前述したAppSheetのAudit Historyを確認して失敗の原因を探ります。 ここまで確認できたら、スクリプトエディターで、 onFormSubmit() を書き換えて、フォームから受け取ったイベントをAppSheetにそのまま連携します。 function onFormSubmit(e) { apply(e.namedValues); } 最後に、Googleフォームで承認者のメールを自分にして申請すると、承認依頼メールが自分に届くことを確認します。 最後に、AppSheet上で Deploy （公開）すれば、他の人も使えるようになります。AppSheetの左ペインManagerを選択し、Deployタブを選択します。先に、deployment checkを実行して公開可能かを確認し、大丈夫ならMove app to deployed stateボタンを押して公開します。お疲れ様でした👏 まとめ この記事では、業務で動的メールを使うためにAppSheetを使うプロセスをご紹介しました。プロセスを説明するために、かなり長い記事になってしまいましたが、最後まで読んでくださりどうもありがとうございます。 Apps ScriptとGoogleフォームを併用して、AppSheetを使っていることを利用者から隠蔽する方法もご紹介しました。ノーコードにはなりませんが、AppSheetを業務に導入する際のハードルを下げる一つの手段になると思います。応用していただければ幸いです。 AppSheetを使いこなすにはリレーショナルモデルの理解が重要です。今回はじめてAppSheetを使ってみて、「あれ？なんで動かないの？」と頭を悩ませた結果、やっとそのことに気がつきました。 BIGLOBEの新人エンジニア研修 でも、データモデリング（リレーショナルモデル）は基礎から学んでもらっています。データ構造の違いがアプリの振る舞いの違いになって現れるAppSheetは、データモデリングを学ぶ教材としても優れていると思います。 AppSheetはたくさんのテンプレートを公開しています。気になるアプリが見つかったら、ぜひ中を覗いてみてください。うまく流用すれば、すぐに業務改善に役立つかもしれません。ぜひご活用ください💪 Apps Scriptを活用して業務を改善した話はこちらでもご紹介しています。よろしければご覧ください。 style.biglobe.co.jp ※ Google、Gmail、Google Workspace、Google Apps、AppSheet は Google LLC の商標であり、このブログはGoogle によって承認されたり、Googleと提携するものではありません。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。 AppSheetはまだ日本語が不得意なようで、項目名からTYPEを類推してくれませんでした。 ↩ 当初は承認時刻のTYPEをChangeTimestampにし、承認結果の変更をWatchする実装にしていました。しかしGmailから承認結果を操作した時の時刻にタイムゾーンが反映されませんでした。そこで仕方なく、FOMULAにUTC時間とタイムゾーンを手入力して設定しています。 ↩ 実際の業務では様々な承認フローが存在します。例えば、申請の種類に応じて承認者が変わるケースや、複数の承認者が必要なケースなど。異なる承認フローを実現するには、データモデリングから設計し直す必要があります。 ↩ Googleフォーム用のAppSheetアドオン を使うとAppSheet APIを呼び出さなくても、回答用のスプレッドシートに入力されたデータをAppSheetに連携できます。そこで、回答用シートに追加で申請ID、申請結果、申請時刻の3つの列を追加すればOKです。ただしAppSheet側で申請IDを自動入力できないため、回答用シートにデータが入力されたことをトリガーにしてApps Scriptで申請IDを付与する必要があります。 こちらのスクリプト を参考にしてください。 ↩ Google Workspaceを使っている場合、フォームに登録した人のメールアドレスを自動的に収集できます。 ↩

あいさつ 平澤です。スプラトゥーン大好きエンジニアです。スプラトゥーン３のプレイ時間は500時間です🦑 今回は、 『世界初への挑戦！インターネットを快適にするNAT64/DNS64とは？』 をやったときに開発した技術をご紹介します。 style.biglobe.co.jp あいさつ NAT64/DNS64とは DNS64をどうやって使ってもらうか 実現したいこと 特許の概要 送信元IPアドレスを見てDNSサーバーを振り分け 実現できた もしもユーザーのDNSサーバーを自由に振り分けできたら BIGLOBEの特許出願事情 おわりに NAT64/DNS64とは BIGLOBEは快適な IPv6 でのインターネット接続をおすすめしています。既存技術では、MAP-E機能付きのブロードバンドルーターがユーザーの負担となっていました。 ユーザーの負担が無いIPv6接続「NAT64/DNS64」で多くのユーザーが快適になりました😊 DNS64をどうやって使ってもらうか NAT64/DNS64のユーザーはその名の通り「DNS64」用のDNSサーバーを使います。 ユーザーに「DNS64」用のDNSサーバーを使ってもらうには課題がありました。 実現したいこと ユーザーはDNSの設定をしない ユーザーに払い出すDNSのIPアドレスは同じ NAT64/DNS64のユーザーだけ「DNS64」用のDNSサーバーを使う 難しいです、私はギブアップしました😅 DNSが得意なN澤さんと雑談していると「ロードバランサーがあるからユーザーのIPアドレスでDNSを分けられるよ」という現実的かつ画期的なアイデアが出てきました。 これは面白いと思い、N澤さんと一緒に特許として出願し、無事に登録されました。 特許の概要 『ロードバランサーがユーザーの送信元IPアドレスでDNSサーバーを振り分ける機能』です。 NAT64/DNS64の他でもいろいろと応用できそうな機能です。 送信元IPアドレスを見てDNSサーバーを振り分け ユーザーが「NAT64/DNS64」を契約すると、契約情報がロードバランサーに連携されて自動で「DNS64」用のDNSサーバーに切り替わります。ユーザーの設定変更や、専用のブロードバンドルーターなどはいりません。 実現できた NAT64/DNS64を契約したユーザーは、設定不要でNAT64/DNS64が使えます。 もしもユーザーのDNSサーバーを自由に振り分けできたら さまざまなDNSサーバーを用意して、自由に割り振りできたら、どんなことができるでしょうか？ DNSSECなどのセキュリティ機能が付いたDNSサーバーや、何か便利な機能が付いたDNSサーバーなどを用意して、ユーザーはWebで申し込みするだけで、いろいろな機能を持ったDNSをサーバーへ切り替えられます。 NAT64/DNS64以外でもいろいろなことができそうですね。 BIGLOBEの特許出願事情 BIGLOBEには、新事業創出や特許出願に誰もが挑戦できる環境があります。たとえばこの「Stage0アイデアマーケット」もそのひとつです。 style.biglobe.co.jp 頭の中にあるアイデアや考察をアウトプットし、特許として継承していくことは名誉なことですし、会社としても知的財産が蓄積されていくのは喜ばしいことですよね。 おわりに 最後まで読んでいただきありがとうございます。 今回の特許は特許情報プラットフォームで見られますので、興味のある方は見てください。 https://www.j-platpat.inpit.go.jp/?uri=/c1800/PU/JP-2020-096273/4A18DD20FBB06EEE29EFD31FABA099BF76DAB4C5B702C1C67A1A832D99919A0F/11/ja   ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。

こんにちは。BIGLOBE Style編集部です。 今回登場するのは、1986年にNECへ新卒入社して以来ネットワークインフラに携わってきた遠藤由妃夫。パソコン通信の時代からインフラ技術に取り組み、BIGLOBEを創ってきたインフラエンジニア界のレジェンドです。インフラ技術が様変わりした現在もなお、クラウドやAIなどの先端技術を積極的にキャッチアップしつつ、社内インフラの改革に挑戦中。40年近くにわたり第一線で活躍し続けるモチベーションの源泉とは。そして未来のBIGLOBEを支える次世代のエンジニアたちに伝えたいメッセージとは、いったいどのようなものでしょうか。 遠藤 由妃夫（えんどう ゆきお） 事業プラットフォーム部門 DX推進部 IT戦略グループ エグゼクティブエキスパート 1986年NECへ新卒入社。 入社時からISPのネットワークに携わり、BIGLOBEを創ってきたベテランエンジニア。現在は、AVD（クラウドを用いた仮想デスクトップ環境）展開の対応をはじめ、最新のテクノロジーを駆使したワークスタイルの移行に携わる。 ※撮影時のみマスクを外しています。 インターネットの黎明期からインフラエンジニアとして活躍 クラウドを駆使したテレワーク環境を実現 「ITとユーザーニーズのギャップを埋めるエンジニア」として成長してほしい インターネットの黎明期からインフラエンジニアとして活躍 ――まずは改めて、遠藤さんのご経歴についてお話しいただけますか。   私がNECに入社したのは1986年のことです。ちょうどその年に日本で通信の自由化がスタートし、NECでは「PC-VAN」というパソコン通信サービスを開始しました。私はこのPC-VANのインフラ開発にエンジニアとして参加したのを皮切りに、NEC／BIGLOBEの通信インフラサービスの構築・運用に携わりました。NECから分社した2013年にネットワークサービス本部長に就任、格安スマホ事業を立ち上げました。その後役職定年を迎え、2018年からは社内インフラの構築・運用に携わるようになり、現在に至ります。   ――パソコン通信サービスが生まれた1986年は、日本インターネット史のプロローグともいえるタイミングです。入社当初から通信技術に関心があったのですか？   いえいえ。私は大学時代に半導体に関する勉強をしていたので、当時半導体で世界トップシェアだったNECに入ろうと思ったのです。当然半導体の仕事を任されると思っていたら、配属先はなんとVAN（パソコン通信で使うネットワーク技術）の技術部隊。VANなんて言葉を聞いたこともなかったので、あわてて本屋に行って調べたのを覚えています。当時はGoogle検索もありませんでしたからね（笑）。   ――それは大変でしたね。当時、コンピューターに関する知識はどの程度お持ちだったのですか？   大学時代に少し学んでいたのは幸いでしたが、実務レベルの知識ではありません。そこで、NECが当時手がけていたメインフレーム（大型汎用コンピューター）のOS開発の現場で一年ほど経験を積んで、それから本格的にVANの開発に従事しました。その後、日本でも商用インターネット事業が開始され、1994年にNECでもISPサービスを始めることになりました。当時は部内にUNIXを扱える人材が少なかったため、私がリーダーとなって立ち上げたのがNECで初のインターネットサービスです。以来、30年近くインターネットサービスのインフラ開発を続けることになりました。   ――BIGLOBEの、というより日本のインターネットサービスの礎を築いたエンジニアの一人としてご活躍されたわけですね。   クラウドを駆使したテレワーク環境を実現 ――遠藤さんが長年にわたってインターネットサービスのインフラを開発し続けてきた中で、エンジニアとして特に大切にしていたテーマはどのようなことだったのでしょうか。   一言でいえば、「ITとユーザーニーズのギャップを埋めること」です。わかりやすい例でいうと、インターネット回線やWebサービスの応答速度が遅かったり、止まってしまったりすると、ユーザーはクレームを挙げますよね。しかし、そもそも世の中で提供されている既存のハード・ソフトが、そうした運用面の課題に十分応え切れていない場合もある。ここに「ギャップ」が生まれます。そこで我々エンジニアが、技術の組み合わせや設定を工夫し、ユーザーのニーズに応えていくわけです。インフラエンジニアとして働いていた間、私が最も苦心したのは「とにかく通信を止めないこと」でした。中でも苦労したのは Webサービス の可用性確保ですね。サーバーが1000台を超える規模になった頃、Web応答速度を維持するのに大変苦労する中で、 標準化や仮想化、自動化といったアイデアがどんどん生まれ実装していきました 。   ――サーバーの仮想化というのは、現在のクラウド技術にも通じるものがありますね。   その通りです。我々がインフラ開発を通じて手がけてきた技術の中には、現在のインフラのベースとなって息づいているものがたくさんあります。   ――現在はクラウドやAIといった先端技術も登場し、パソコン通信の時代と比べるとはるかにITが進歩しています。ITとニーズのギャップはかなり解消されたのではないでしょうか？   いえ、まだまだギャップはありますよ。国や地域によってもユーザーのニーズは違いますし、そのすべてに応えるには技術が足りない。たとえば日本人は「サービスを受けるとき、人として大切に接してもらうこと」について評価が厳しく、その点でクレームが出やすい。高精度なAIチャットボットを取り入れた弊社のカスタマーサポートなどは、それに応える技術の一つといえるかもしれません。   ――インフラエンジニアとして大切にされてきたことが、よくわかりました。続いて現在取り組まれている仕事についても詳しく教えていただきたいのですが。   今は社内のOA環境をテレワークに対応できるよう、改善を進めているところです。テレワークでは自宅から会社のサーバーにアクセスする必要がありますが、従来使われていた「VPNにつなげて社内ネットワークに入る」という方法では、トラフィックがVPNでボトルネックになってしまう。そこで私が注目したのは、 場所によらずIDに加えデバイスとその状態も判断して認証を行うことで 、どこからでも接続できるゼロトラストネットワークです。 私は2016年 頃、会社のPCを自宅に持ち帰らなくてもリモートワークできるUSB起動型シンクライアントシステムを導入しました。 しかしコロナ禍においてテレワークを加速するためには、VPNサーバーに負荷のかかるUSBシンクラよりも、 セキュアな PCをゼロトラスト方式で認証し、 社内OA業務が可能なクラウド上の仮想デスクトップを利用する「仮想OAPC」 の構想が優れています。そこで私は仮想OAPC構想を実現すべく、 セキュアなPCにはGoogleのChromebookを、仮想デスクトップには マイクロソフト社のクラウドサービスAVDを導入。しかしAVDでは Chromebook をゼロトラスト認証する技術がデフォルトで搭載されておらず、 複数の認証技術を組み合わせてなんとか実現させましたが、これは大変苦戦しました。 トライ＆エラーを繰り返した結果、ようやく成功させることができたのです。   ――今ではBIGLOBE社内の誰もが、当たり前のようにクラウド仮想OAPCによるテレワークを利用していますね。社内インフラの構築にあたっては、どのようなことを大切にしているのでしょうか？   お客さま向けのインフラを手がけていたときと同じで、「サービスを止めない」ことですね。たとえばパソコンを使っていると、OSのアップデートのために10分ぐらい止まってしまうことがあるでしょう。私はあれが嫌なんです。人間のためにコンピューターがあるはずなのに、コンピューターのために人間が時間を使うのはおかしい。ユーザーにコンピューターの世話をさせてはいけない。コンピューターの世話をするのは我々インフラエンジニアだけでいいのです。事実、 クラウド仮想OAPC では、OSやアプリケーションの 大量更新でも 、ユーザーは 利用が妨げられるようなことが全く無い 仕組みになっています。   ――つまり、ユーザーにとってコンピューターが使えることが「当たり前」の状態にする、と。   そう、まさにそれがインフラエンジニアの役割だと思っています。空気というのは吸えて当たり前のもので、誰もそのことに感謝したりはしません。嫌な臭いがしたときにだけ苦情を言う。ITインフラもそれと同じで、匂いのない空気のような存在が理想なのです。もちろん「ITとユーザーニーズのギャップを埋める」という私の目標は今も変わっていません。一つのプロジェクトが完了したからといって手放しで喜ぶことはなく、ユーザーの満足を追求し続けていく。「まだまだ、序の口だよね」というのが、私の口癖なんです（笑）。   「ITとユーザーニーズのギャップを埋めるエンジニア」として成長してほしい ――遠藤さんが入社してから30年以上が経ち、ITインフラを取り巻く環境も、BIGLOBEも大きく変化しました。これからBIGLOBEに入社する若いエンジニアにとっては、どのようなやりがいがある環境だと思われますか？   繰り返しになりますが、ITとユーザーニーズとのギャップが消えない限り、エンジニアがやるべきことはいくらでもあります。そのギャップを技術で埋めていくことは、エンジニアにとってかけがえのない喜びだと思います。いくらAIが発達してきたといっても、まだまだ人間にしかできない仕事は多い。2045年にはAIが人間の知能を超えるシンギュラリティが起こるとも言われていますが、それまでまだ23年もありますからね。   ――遠藤さんご自身は今、どのような技術に注目していますか？   一つはやはりAIですね。最近は契約書の内容をチェックするAIなどもありますが、インフラ分野でもAIは役立つと思います。たとえばユーザーが安定的にモバイル通信を利用できる環境を保つには帯域制御が欠かせませんが、手動では限界があります。どの回線の通信量をどの程度制限するかという判断をAIが判断してくれれば、非常に効果的です。あとは、先ほどお話ししたゼロトラストのモバイル認証は、より完全なかたちで実現できれば画期的な技術となるでしょう。   ――インフラエンジニアにとっては、まだまだ学ぶべき技術がたくさんあるわけですね。ところで30年以上当社を見てきた中で、BIGLOBEの社風はどのように変化したと思われますか？   私が入社した頃は、時代からしてもThe昭和の企業という感じでしたが（笑）、今は年齢問わず皆さん自由に働けるようになって、うらやましいです。とはいえ、私の場合は入社早々、VANという社内でも前例のない技術に取り組むことになったため、技術面ではかなり自由にさせてもらえました。技術者が新しいことに挑戦できる風土というのは、昔から変わらずあったのかもしれません。 「ビッグローブマインド」 は最近できたものですが、私が見ても違和感はないですね。   ――これから入社するエンジニアや、今働いている若手のエンジニアに向けて、どのような姿勢で仕事に取り組めば良いか、アドバイスをいただけますか？   視点は高く、視野は広く持つことでしょうか。目の前の仕事だけ見るのではなくて、もっと先の未来を見据えて新しい技術に取り組んでいくと、インフラ構築の仕事はとても面白くなります。誰も試したことがない技術の組み合わせでソリューションを見つけたときの感覚は、本当に楽しいものです。最近はコロナ禍のため行けていませんが、以前は国内はもちろん、アメリカの展示会にも足を運んで最先端の技術や製品をチェックし、良いものはすぐ業務に取り入れるようにしていました。そういう、技術の習得を楽しむ気持ちや、ユーザーのニーズに応える目的意識が、エンジニアとして成長するためには大切だと思います。   ――そのように意欲的な若手エンジニアにとって、BIGLOBEは成長できる環境だと思われますか？   もちろんです。BIGLOBEはNECからスタートした純日本企業でありながら、グローバルレベルの先進的な価値観を作り上げてきた会社。なかなかここまでオープンで、若手の活躍しやすいIT企業はないのではないでしょうか。それに加えて、AIをはじめとした新技術が登場している今、ITという分野自体の変化も速い。まだまだ面白いことがたくさん起こると思いますし、若いエンジニアにとって未来は明るいと思いますよ。新しい技術をキャッチアップし続けながら、ITとユーザーニーズのギャップを埋める仕事を楽しんでほしいな、と思います。   ――本日はありがとうございました！   当社では一緒に働く仲間を募集しています。ご興味のある方はこちらの採用情報をご覧ください。 www.biglobe.co.jp ※ Googleは、Google LLCの商標です。 ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

2023年1月25日(水)〜 27日(金)に開催される「JANOG51 Meeting」にて、当社基盤本部 ネットワーク技術部の滝口 敏行が登壇いたします。 BIGLOBEは2021年10月からOOLのModel Driven Network DevOpsプロジェクトにプロジェクト会員として参加。「NW構成情報（トポロジ）データを中心にした設計・構築・運用プロセスの検討と PoC の実施・評価」をテーマに、プロジェクト参加企業であるTIS株式会社・NTTコミュニケーションズ株式会社の方々と会社の枠を超えて活動してまいりました。 Model Driven Network DevOpsのプロジェクトとしての活動期間は一年半を迎え、実装の進んだ活動成果をご報告いたします。 現地およびオンラインのハイブリッド開催となりますので、お気軽にご参加ください。   本イベントは終了しました。 アーカイブはこちら： https://www.janog.gr.jp/meeting/janog51/copy/   ■イベント名 JANOG51 Meeting www.janog.gr.jp   ■主催 日本ネットワーク・オペレーターズ・グループ   ■開催日時 2023年1月25日(水)〜 27日(金) 登壇プログラム Day2 2023年1月26日(木) 14:45～15:45 「もし本番ネットワークをまるごと仮想環境に"コピー"できたらうれしいですか?」   ■開催方法 現地およびオンラインZoom（参加無料） ふじさんホール（富士五湖文化センター・富士吉田市民会館）3F会議室 山梨県富士吉田市緑ケ丘２丁目５−２３   ■参加お申し込み方法 www.janog.gr.jp   ■当社登壇者 滝口 敏行 (たきぐち としゆき) ビッグローブ株式会社 基盤本部 ネットワーク技術部 開発グループ 2018年12月中途入社。Prometheusを利用した監視システムの導入・運用に従事。2021年4月からはDNS、IPv4 over IPv6、NAT64/DNS64インフラ基盤のクラウド移行・コンテナ刷新に従事。   ■共同登壇者 TIS株式会社 萩原 学 氏 NTTコミュニケーションズ株式会社　田島 照久 氏   ■内容 このプログラムでは、OSSのツールや自製のソフトウェアを組み合わせて、本番NWの設定ファイルをもとに、L3/OSPFレイヤでの「同等のNW」をコンテナベースに再現した取り組みについて共有します。 この取り組みはNW全体のレイヤやトポロジをモデルとして表現することで実現していて、そのモデル表現に基づいた検査(verification)やシミュレーション、自動化への応用を検討しています。 今現在の各ツールでの対応状況や、実際に試してみてわかった課題を共有することで、そうしたモデル中心の考え方に基づいたときの運用の変化や、将来像への期待、導入へのハードルなどについて議論できればと考えています。   Model Driven Network DevOpsのプロジェクトは「NW構成情報（トポロジ）データを中心にした設計・構築・運用プロセスの検討と PoC の実施・評価」をテーマに、 ・構成情報を中核とした将来的なネットワークシステムの運用ライフサイクルをデモとして提示できるようになること ・その際に必要な技術・考え方・ツール等を取りまとめて公開し、オープンに応用検討ができるようになること を目標として活動しています。   ■ 使用したOSS/ツール ・Netbox ・Batfish ・Ansible ・Containerlab ・Netomox/Netoviz   ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。  

Okinawa Open Days 2022でネットワーク自動化の研究をポスター発表し、来場者との対話を通じてより良い研究にするヒントをいただきました。おまけで沖縄の美味しいものもご紹介します。 はじめに なにやってたの？ ブース説明の様子 感想 おまけ 先日映画館で『THE FIRST SLAM DUNK』を見て、感動しました。基盤本部の川口です。 はじめに BIGLOBEは2021年8月から沖縄オープンラボラトリ（Okinawa Open Laboratory: OOL）の「Model Driven Network DevOps Project」に参加しています。このプロジェクトにはBIGLOBE、NTTコミュニケーションズ、TIS（アルファベット順）が参加し、会社を横断してネットワーク自動化の研究に取り組んでいます。2021年度の活動内容はこちらで紹介しています。 style.biglobe.co.jp 2022年12月にOOLが主催するOkinawa Open Days 2022（OOD）でポスター発表をしてきたので、その様子を（沖縄の魅力と合わせて）ご紹介します。 日時 2022/12/13 - 12/15 会場 沖縄県市町村自治会館（沖縄県那覇市旭町116-37） 会場の外からの様子 会場入り口 セッション会場の様子 MDDO PJについて発表している様子 割と広めで100人近く入る会場でした OODは沖縄発・沖縄開催のICTイベントです。JANOGと比較すると、インターネットやネットワークに限らず、オープンソースソフトウェア、ICT教育、DXなど広い分野を対象にしています。 去年はオンライン開催のみだったのですが、今年はハイブリッド開催ということもあり参加登録数も2倍の450人ほど登録があったようです。実際参加してみて、思っていたより人が来てるなという印象でした。　 なにやってたの？ OODでは、スポンサー企業を中心にブース展示があり、OOLのプロジェクトごとに簡単な展示が用意されています。私たちはModel Driven network DevOps（MDDO）Projectの取り組みをブース展示で紹介していました。前述した通り、思ったより人が来ていたのでブースも大盛況。セッションで発表するよりも時間を気にすることなく、ポスターやスライドの資料を持ち込んで丁寧に説明できるので、より深い議論ができました。 ブースに来ていただいた方から、「どういう実装なの？」「こういうのできたらいいよね」といったフィードバックをたくさんいただくことができました。自動化に強いエーピーコミュニケーションズさんのブースに行った際にもプロジェクトのことを聞かれたので、お互いの製品やプロジェクトについて情報交換をするという交流も生まれました。 ブース説明の様子 発表ポスター ポスター説明の様子1 ポスター説明の様子2 ポスター説明の様子3 2日目にはkubernetes（k8s）アップストリームトレーニングというハンズオンに参加しました。k8sのハンズオンではあるのですが、k8sの開発コミュニティの紹介やコントリビュートについての解説が中心で、k8sのGitHubレポジトリに実際にPull Requestを発行する実践的な内容でした。 特に良かったのは、k8sのコミュニティ活動をしているSlackのワークスペースに招待してもらえたことです。チャンネル数が100を超えた大規模なもので、世界中の人がk8sの機能追加やカンファレンスについてチャットしている様子を目の当たりにすることで、良い刺激になりました。申請すれば誰でも参加できるみたいで、たくさんコントリビュートすればGitHubのレビュワーにもなれるそうです。k8sのカンファレンスも行ってみたいなと思いました。 最終日にはOOLのプロジェクトごとに発表があり、MDDO PJのリーダーのTIS萩原さんが発表しました。 発表資料 デモ動画もYouTubeにUPしてます（音声なしです）。 www.youtube.com OODが終了した16日には、勢理客（じっちゃく）にあるNTTコミュニケーションズのビルにあるOOLのラボに行ってきました。プロジェクトの開発や評価で使っているサーバの本体を見たり、OOLの事務所を見たりしました。最終日は天気が悪く土砂降りだったので、NTTビルや空港に向かうまでが大変でした。 PJメンバーの集合写真 BIGLOBE 滝口、前野、TIS萩原さん、BIGLOBE 川口、NTTコミュニケーションズ田島さん （左下から時計回り） 感想 私個人としては、ポスターや資料を使いながら対面で説明・議論するのが学生時代以来で、良い経験になりました。また、その対話を通じて、このプロジェクトの取り組みについて理解が曖昧な点を確認できる機会にもなりました。 1月のJANOG51では滝口が発表します。 style.biglobe.co.jp OODが終わった16日には、もらったフィードバックを早速まとめて、発表内容に反映するためのふりかえりをやりました。JANOG51でもたくさんの意見をもらって、よりよいシステムができるよう頑張ります。 おまけ 沖縄は初めてだったので、ご当地のものをたくさん食べました。 「ジャッキーステーキハウス」 芸能人のサインがたくさん飾ってありました おいしかったです 「ハブ酒」 暗くてわかりづらいですが、お酒に漬けられたハブくんです ハブハイボールをいただきました 「沖縄そば」 チャーシューがおいしかった ボリュームもあります

Internet Weekは実務に役立つインターネット基盤技術を学べる非営利の技術カンファレンスです。イベントを裏方で支えるプログラム委員について、その苦労と魅力を紹介します。 はじめに Internet Weekについて プログラム委員について 私とプログラム委員 プログラム委員の決まり方 ここが面白い！プログラムの作り方 Internet Weekならではの難しさ 発表者との調整 全体のバランスを考えて 集客の大切さ 今年のテーマとプログラム作りの舞台裏 当日の話 終わりに はじめに みなさん、こんにちは、ネットワーク技術部の山口です。 2022年11月末に開催されたJPNIC主催のイベント「 Internet Week 」にプログラム委員として参加してきました。プログラム委員は激務ですが、その活動を通じて大変多くのことを学んでいます。この場をお借りしてその醍醐味を紹介させてください。 Internet Weekについて Internet Week （以下IW）は日本のIPアドレスやAS番号などの資源を管理するJPNICが主催し年に1回開催しているイベントです（前年に開催したIWから選りすぐりのプログラムをいくつか厳選し、 2日間に再構成したものを「Internet Week ショーケース」として年1回の開催とは別に開催しています）。 JPNIC公式サイト の記述を引用すると以下のような目的で開催されています。 インターネットに関する技術の研究・開発、 構築・運用・サービスに関わる人々が一堂に会し、主にインターネットの基盤技術の基礎知識や最新動向を学び、 議論し、理解と交流を深めるためのイベントです。 また、IWで得られたものをご自分のフィールドで役立てていただくことにより、インターネットの普及・促進・発展に貢献する（繋げる）ことを当イベントの目的としています。 IWの歴史は長く、1997年を最初に約25年の歴史があります。1997年以前はその原型として「IP Meeting」というイベントがあり、1990年から続いています（IP meeting は形を変え、現在もIWの一つのプログラムとして残っています）。 プログラム委員について 私とプログラム委員 IWにプログラム委員として参加することになったのは、2015年のIWからになります。 当時、30歳以下の若手エンジニアのコミュニティであった「 wakamonog 」の運営委員をしていました。wakamonogからもIWのプログラム委員を2人ほど毎年出しており、お誘いが来るようになったのがスタートです。 その後、2020年を除き、毎年プログラム委員を務めることになり、今年で7年目となりました（2020年はCOVID-19の影響で完全オンライン開催になってしまい、オンラインのコミュニケーションに不安があったこともあり、参加を辞退しました）。 wakamonogはその名の通り若者のコミュニティですので、30歳を超えたら運営委員を引退するというルールがありました。そのため、私もwakamonogを卒業したあとは、所属するコミュニティや団体がなく、プログラム委員は引退かなと思っていました。 ただ、当時から私はwakamonogとは別に、自宅に設置した機材でグローバルASを運用し、若手エンジニアの検証環境などを支援する Home NOC Operators' Group という活動をしていました。JPNICの方から、その活動での知見もIWで活かして欲しいというお声掛けがあり、以降はHome NOC Operators' Groupの団体名で参加しています。 昨年からは同じ団体に所属する若手エンジニアであるIIJの人と2名でプログラム委員に参加するようにして、若手プログラム委員の育成にも務めています。 プログラム委員の決まり方 前項で所属団体のお話をしたのは、IWならではのルールがあるためです。IWではプログラム委員は広く公募されていません。JPNICからインターネットの発展に貢献している団体や技術コミュニティからプログラム委員を推薦する形です。その団体やコミュニティの中でIWに参加するかどうかや、誰が参加するかを決めて、プログラム委員を出すことになっています。 これはIWが非営利かつ中立的な技術カンファレンスであり、特定の企業のビジネスカラーを出さないようにするためでもあります。そのため、インターネット関連のどこかの団体に所属していることが必要であり、「BIGLOBEの誰々です！」と企業に所属しているだけでは基本的にはプログラム委員に参加することはできません。 ここが面白い！プログラムの作り方 ネットワーク系のコミュニティやカンファレンスだと JANOG や APNIC などがありますが、多くのカンファレンスにおいてCFP（Call For Presentations）が運営サイドから出され、それに応募してきたプログラムを審査して採否を決定することが多いと思います。 IWではこの部分が大きく異なり、最近は以下のようなプロセスでプログラムを作っています。 プログラム委員と実行委員が今年のテーマを決める テーマに沿って or 今年のホットトピックから具体的なプログラムを決める 決めたプログラムについて発表してくれそうな人を探す 自分たちであれこれ考えて、プログラムを作っていくプロセスは簡単ではありません。専門知識はもちろんのこと、その分野で最近どのようなことがホットトピックであるか、社会的にどのような課題があるか、などについても分かっていることが求められるからです。しかし、自分の考えたことが、一つのプログラムとして仕上がり、多くの人に見て頂き、インターネットに貢献できるというのはエンジニアとしてとても楽しく充実した時間であると思います。 正直プログラム委員の活動はかなり大変なのですが、毎年続けている理由はここにあったりします。 Internet Weekならではの難しさ このようなプログラムの作り方をしているゆえの難しさもあります。 発表者との調整 テーマやプログラムを決めたら、その内容について話して頂ける方を探して発表の交渉を進めることになります。発表者の方は業界の有名人やその分野のスペシャリストですから、当然ながらしっかりとしたご意見や考え方をお持ちです。それがプログラム委員とピッタリ合えば良いのですが、若干のずれがあり、交渉や議論を重ねることもあります。 また、発表をお願いしても断られてしまうことがあり、発表してくれる方を探し回ったり、プログラムの内容を見直すこともあったり。もちろん、毎年常連で発表をして頂いており、今年もお願い！と一言伝えるだけで、うまく発表してくれる方もいらっしゃったりします。 全体のバランスを考えて 「今年のホットトピックから具体的なプログラムを決める」と前項に書きましたが、話題のプログラムだけをやっていれば良いわけではありません。例えば、あまりアップデートは無いけどインターネットにとっては必要なことや、基礎的なことだけど若手エンジニアのためにやった方が良いテーマってありますよね。この辺りをバランスよく考えていくのも大切です。昨年は基礎的なプログラムとしてAS運用の基礎知識についてネットワーク技術部の前野さんにお話し頂いたりしました。 【Internet Week Basicオンデマンド】 AS運用ことはじめ パートI AS運用ことはじめ パートII www.nic.ad.jp 集客の大切さ プログラム委員としてプログラムを作るからには、多くの方がそれを見て、業務などに役立てていただきたいと思っています。また、ここ数年はオンライン開催メインであり、それほどでもなくなりましたが、Internet Week の開催には多くの費用が掛かっています。そのため、多くのお客さんにプログラムを見て頂くため、プログラム委員はある程度集客も意識し、決まったプログラムは様々なメディアで宣伝をしていたりします。 最近はJPNICのブログとYouTubeチャンネルでの集客が中心です。 JPNICのYouTubeチャンネル： www.youtube.com 私も担当したプログラムの宣伝でひっそりとYouTubeデビューしてたりします。 www.youtube.com 今年のテーマとプログラム作りの舞台裏 今年のテーマは、「インターネットの羅針盤 ～ 針路を未来に」でした。昨今のインターネットはサイバー攻撃やスプリンターネット（政治などを理由に、自由なはずのサイバー空間が国や地域間で分断されてしまう状態）など穏やかでない話が多いかと思います。そんな中で、改めて「自立分散協調」のインターネットの考え方を思い出し、IWに関わる方が、どう進むべきか議論をしたいという思いが込められています。 会期中のプログラムの数は約40以上、プログラム委員は30名近くになるため、具体的な検討は専門分野ごとのチームに分かれておこないます。今年は「ネットワーク運用管理」「セキュリティ」「社会派」「IPv6」「基盤サービス」「新テーマ」「ハンズオン」の7チームに分かれました（配信やIP Meetingは別枠でチームがあります）。 私はBIGLOBEでバックボーンネットワークや対外接続を担当しているネットワークエンジニアなので、「ネットワーク運用管理チーム」に毎年入っています。最近は、インターネットガバナンスなどに興味があり、機会があれば「社会派チーム」にも関わってみたいと思っています。 ネットワーク運用管理チームで作り上げた今年のプログラムは次の5つで、私は「C15 インターネットセキュリティ」「C54 Peering入門」の2つを中心にプログラム作りを担当しました。ルーティングセキュリティのプログラムへの思いは、上にリンクを張ったYouTubeでお話していますのでよろしければぜひご覧ください。 C15 ルーティングセキュリティ - インターネット運用の羅針盤 - https://www.nic.ad.jp/iw2022/program/c15/ C54 Peering入門 https://www.nic.ad.jp/iw2022/program/c54/ C12 5Gモバイルネットワーク入門 https://www.nic.ad.jp/iw2022/program/c12/ C14 Wi-Fi航海図　～みえない電波を理解する～ https://www.nic.ad.jp/iw2022/program/c14/ C11 独法でダークファイバを使ってみた話 https://www.nic.ad.jp/iw2022/program/c11/ 多数あるプログラムの候補の中から議論を重ねて上記の5つが決まりました。候補から外れた理由は様々です。例えば「400Gネットワーク」は話題性はあるものの時期尚早と判断しました。IWはどちらかというと、有料のカンファレンスに来てもらって、業務に使える知識を持ちかえってもらう的な側面もあるためで、今年は見送りになりました。 その他にも良いところまで検討が進みましたが、様々な事情により立ち消えになってしまったプログラムもありました。可能なものについては来年ご提供できるようにチャレンジしたいと思います。 こんな議論を繰り返しながらプログラムを作っています。 当日の話 様々な準備を重ねて迎えた開催当日、プログラム委員は担当セッションの司会の仕事があります。 オンラインセッションの場合、自宅やオフィスから出てもいいのですが、私はJPNICのスタジオに行って司会をしました。機材の整った立派なスタジオで司会をするのは少し緊張してしまいますね。これだけ設備が揃っていると、質疑応答のハンドリングなどもとてもやりやすいです。 筆者が司会をしている様子 終わりに IWのプログラム委員は激務ではありますが、毎年学べることがとても多い場になっています。来年はお声掛けがあるか分かりませんが、あった際には続けていきたいと思っています。日本を代表するインターネット接続事業者であるBIGLOBEのエンジニアとして、このようなイベント作りに関わることに価値があると思いますし、今後も何らかの形でIWには貢献していきたいと強く感じます。 BIGLOBE社員が大事にする価値観である ビッグローブマインド に「世の中をみて、世の中から学ぶ」があります。 イベントに参加するだけでも学びはあります。さらに「イベントを作る側や発表する側」にまわれば、より大きな学びがあります。一歩踏み出して、世の中から学んでみてはいかがでしょうか。 例えば、JANOGのプログラム委員など、公募のあるプログラム委員もあります。以前、前野さんが取り組んだJANOGのネットワーク構築ボランティアについても次の記事で紹介しています。よろしければご覧ください。 style.biglobe.co.jp 以上です。最後まで読んでいただきありがとうございました。 ※ YouTubeは、Google LLC の商標です。 ※ 記載している企業、団体、製品、サービス等の名称は各社またはその関連会社の商標または登録商標です。

BIGLOBE Style編集部の吉田です。 BIGLOBE Styleは2022年12月、オープンから3周年を迎えました🎉 手探り状態で始まり今日まで駆け抜けてきたこの3年間を、編集部メンバーでふりかえってみました。今回はその様子をお届けします。 BIGLOBE Styleとは ビッグローブ株式会社ではたらく人の想いから、インターネットを支える技術まで、社内の雰囲気を多面的に紹介する採用オウンドメディアです。 技術をテーマにした記事は「TechBlog」のカテゴリで掲載中。 開設当初は広報グループが担当するSDGs関連記事も同居していましたが、BIGLOBE Styleを発射台に 「あしたメディア by BIGLOBE」 として2021年7月に独立。新たなオープンを果たしています。 BIGLOBE Style開設日：2019年12月13日 記事数：246本（削除した記事を含む） 登場社員ユニーク数：143人／社員数約550人中 （2022年12月現在） 編集部メンバー BIGLOBE Style編集部 コーポレート本部 人事部 採用グループ 編集長　塚本 恭英（つかもと やすひで） 編集者　森山 いずみ（もりやま いずみ） 編集者　吉田 朋子（よしだ ともこ） TechBlog編集部 基盤本部 基盤統括部 基盤戦略グループ 編集長　吉川 雅之（よしかわ まさゆき） 編集者　高玉 広和（たかたま ひろかず） 吉田 ：今日は、BIGLOBE Style編集部とTechBlog編集部のメンバーでこの3年間をふりかえりたいと思います！ 一同 ：3年経ちましたね、あっという間でした！（拍手👏！） お題１：BIGLOBE Styleを立ち上げて良かったこと お題２：これまでの苦労について お題３：これまでにどんな効果があったか お題４：オウンドメディアを続けるコツとは お題５：課題に感じていること お題６：印象に残っている記事 お題７：今後の展望 お題１：BIGLOBE Styleを立ち上げて良かったこと 高玉 ：記事のネタを探そうと社内をくまなく探すうちに、 改めていい会社だな と思うようになりました。記事作成を通して知り合いも増えていくので、心の距離がぐっと近くなり仕事を頼みやすくなったことも利点です。 森山 ：私が担当する新卒採用では、就活生が情報源として利用してくれていて、BIGLOBE Styleを読んでBIGLOBEのことをよく理解できましたという声をいただいています。 社内の情報に対してオープンな会社 だという良い印象をもってもらえているようです。 吉田 ：就活の判断材料にしてくれて嬉しいですね。私の場合は、個人的なことですけど、文章を書いたり取材したりという経験が全くなかったので、携わってみて意外と好きかも、という発見がありました。メディア運営という新しいチャレンジをさせてくれたことに感謝しています。 BIGLOBE Styleの記事は会社の資産 だと思っているので、とてもやりがいがあります💪 BIGLOBE Style編集部　吉田 朋子 塚本 ：私はBIGLOBE Styleがはじまった後に人事部へ異動してきましたが、毎週内製で記事を更新しているのがすごいと思いました。それだけ BIGLOBEには多様な人がいて、さまざまなネタがある ということですよね。中途採用面接でも、コンテンツが充実しているとお褒めの言葉をいただいています。 吉川 ：そうですね、 運営を内製化してノウハウとして溜めている のはすごいことですよね。たいていは外注で丸投げしたくなるじゃないですか。みんな他の業務があるし。でも、頑張って自分たちで企画して記事を作っているので、ノウハウとスキルがついてきましたね。 高玉 ： RADIUSの記事 は私がインタビューをして記事を書いたのですが、 「まさか中の人が書いているとは思わなかった」 と驚かれて嬉しかったです(笑) 私は開発経験者です。だからこそ現場のことを正しく書ける し、評価されるのだと思います。これは今後も続けていきたいですね。 TechBlog編集部　高玉 広和 お題２：これまでの苦労について 吉田 ：私は当初、メディアの知識が全くなかったので本当に手探り状態でした。前編集長に「PVって何ですか？」と聞いて驚かれたほど(笑) 高玉 ：今ではHTMLやCSSのコーディングもできるようになりましたね(笑) 森山 ： プラットフォームの選定からデザインまで全て内製 だったので、技術面やアセスメントは開発経験のあるTechBlogメンバーのおかげでなんとか乗り越えましたよね。そういえば、立ち上げ当初の画面デザインは超初心者が作ったような簡素な見た目でした…(笑) 立ち上げ当初のトップ画面 吉田 ：カラーコードも知らなかったから…(笑)　あと、 PV数をKPIにしていた時は辛かった …！ 高玉 ：それはキツい。目的と手段が入れ替わるという、まさに一番やってはいけないことかもしれません。メディアの種類にもよりますが、BIGLOBEに興味を持った人が社内の様子を知るためにアクセスする採用オウンドメディアという意味では検索による自然流入がとても大事です。そのためには、これまでに書いてきた記事のストックが大事になります。 ネタ探しはどうしてます？ 吉田 ：イントラブログ（社内ブログ）での発信とか、社内で感謝の気持ちを送りあうシステム「 まいぽ 」のタイムラインで誰かを賞賛しているのを見ています。 高玉 ：なるほど、「まいぽ」は社内のコミュニケーションが可視化できる仕組みなので、ネタ探しにも活用できますね。 しかし、ほんとに奥ゆかしい人が多い。記事の執筆や取材はお願いすれば引き受けてくれるんですけど、もっと BIGLOBE Styleを利用して自分を売り込んでほしい です。 吉田 ：いいところを伝えたい！と思うと、 どうしてもキラキラ部分だけが目立ってしまう という問題もありました。入社後のミスマッチを起こさず、読者の方の共感を得るために、 泥臭いところや課題をもっと出すような工夫 もしましたよね。 塚本 ：そうですね。中途採用の面接でも 「課題が書かれていたので自分が入社後、何をすべきか理解できた」 と言われるようになりました。 BIGLOBE Style編集長　塚本 恭英 吉田 ：良かったです！社外の認知でいうと、TechBlogは最近はてなブックマーク（はてブ）の数が増えるようになりましたよね。 高玉 ：数が伸びるとやはり嬉しいです！実は立ち上げ当初は、はてブのコメント欄（ブコメ）は非公開にしていたんです。少しでも炎上リスクを抑えたい、との判断がされた結果なんですが…。でも、 エンジニアに認知されるにはブコメ公開は不可欠 だと思っていたので、当時の編集長に説明してなんとか公開許可をもらいました。エンジニア文化が通じないもどかしさがありましたが、今では 数字が伸びてホットエントリーに入ることも増えた ので、あの時頑張って説得して良かったと思っています。はてブの数字が伸びてホットエントリー入りすると、エンジニアの読者がSNSでさらに拡散するという良い循環が生まれ、認知にもつながります。とはいえ、ホットエントリー入りするかどうかは時の運なので、いつ注目されてもおかしくないよう、記事の質を上げることに集中しています！ 吉田 ：TechBlogは本人が執筆するケースが多いですが、依頼するときの苦労はありますか？ 高玉 ： 忙しくて書けないという状況 はよくあります。ただ、 そもそも書くのが苦手、不安ということの裏返し の場合もあります。どちらにしろ遠慮なく編集部を頼って欲しいと伝えています。私は アウトプットに慣れる人が増えれば、もっと記事が出てくる と考えています。そこで、まずはイントラブログを書く人を増やそうと「ブログウィーク」という企画を社内ではじめました。 塚本 ：「ブログウィーク」はテーマを決めて執筆者を募る企画で面白いですよね。「私の崖っぷち体験」がテーマの時に私も書いてみました。不慣れなことも多かったのですが、編集部が伴走してくれたので 書くまでのハードルを乗り越えることができました。 イントラブログの「ブログウィーク告知記事」から抜粋 森山 ：立ち上げ当初は現在の 「あしたメディア」 もBIGLOBE Styleに同居していたのですが、当時はなかなか企画が通らないという困難もありました。サイト全体のコンセプトとしてイノベーションを伝えるという要素を強調していたんですが、社内の様子を伝えるにもイノベーティブな一面を求めてしまい、記事がコンセプトとぶつかる状況になっていたのが原因です。 高玉 ：そうですね。イノベーションやSDGsを発信して若者に訴求するという目的と同居していたので、ごった煮感がありました。 塚本 ： 目的が違うメディア同士が同居していると、共通のゴールや大義が曖昧 になりますね。その後 「あしたメディア」 は独立し、そのコンセプトにしたがって記事を拡充し読者数を大きく伸ばしています。一方、BIGLOBE Styleはイノベーティブにこだわらず「ありのままの社内を伝える」という方向転換ができたので、双方にとって良かったと思います。 お題３：これまでにどんな効果があったか 塚本 ：採用の観点では、 志望度を高めてもらったり、会社自体を知っていただくきっかけ になっています。 森山 ：そうですね。オウンドメディアを見る見ないはその人に委ねられますが、BIGLOBE Styleがあることによって情報をキャッチアップする行動をしているかという判断ができます。採用サイトだけでは伝えきれないことを定期的に発信しているので、 見に来てくれる人はトレンドをキャッチできる人 だと思いますし、志望している会社に対してちゃんと 情報収集できるんだなという見極め にもなります。 BIGLOBE Styleから採用マイページ登録してくれる人や、記事をきっかけに共感し、興味を持ってくれた学生もいますよ。 BIGLOBE Style編集部　森山 いずみ 吉田 ：採用につながる記事が出せているのは嬉しいですね。 高玉 ： 記事 を執筆したことがきっかけで イベント登壇 のお声がけをいただいた のも効果のひとつです。取り組みを記事にしたおかげで発表の機会が得られるという、新しいルートを開拓できたと思います。これがさらにビジネスにつながるといいですよね。 他企業や社内で一緒に何かしたい人とのつながりを作る手段としても有効 かもしれません。 吉川 ：あと、 入社後すぐに辞めてしまうケース、つまりミスマッチで入ってしまうエンジニアがいなくなりました。 TechBlogをコンスタントに公開して、どんなこと取り組みをしているのか？どんな人がいるのか？といった、社内の状況をちゃんと見せていることが、そうしたミスマッチを防いでいる側面があると思います。 TechBlog編集長　吉川 雅之 高玉 ：入社後に活躍していただくのが一番大事なので、正直に書いていきたいですよね。 森山 ：そうですね、いいところだけ記憶に残ってしまわないように、 会社として未熟な部分や泥臭いところは引き続き出していきたい ですね。 お題４：オウンドメディアを続けるコツとは 高玉 ：先ほど塚本さんの話にもあったように、採用数や広告換算値など、目指すものが違う性質のメディアを同居させないのも長く続ける秘訣だと思います。 一番大事なのは、編集部という運営体制を作って、役割や工数を割り当てていること ですね。私と吉川さんは開発部門の人材組織で、横断的にさまざまな部署と交流しておりネタの収集も可能です。もし運営体制を作らずに持ち回りでやっていると、ネタが枯れたりモチベーションに繋がらなかったりで継続が難しく、失敗につながるのではないでしょうか。 吉田 ：人事部のBIGLOBE Style編集部と、開発部門のTechBlog編集部双方の連携が上手くいっているのも長く続ける秘訣として外せません。エンジニアを取材するときは、技術的な用語が難しいのでいつも高玉さんに助けてもらっています。 塚本 ：記事のネタになりそうなものを互いに出し合って共有できていますしね。 吉田 ：あとは、たとえ小さい記事でも決めた日付に 地道に出し続ける執念 も必要かと(笑) 当初は広く読んでもらおうとしていましたが、途中から ターゲットに届けばいい と思うようになったことも効率よく続けられるようになったと思います。 高玉 ：めちゃくちゃ正しい。そこを間違えると苦しいです。 塚本 ： 企画書のテンプレートを活用 しているのも便利ですね。ターゲットや目的、インタビュイーへの質問まで細かく書かれているので、それを使って編集部で議論できています。 高玉 ：テンプレートでいうと、 あらかじめ決まった文章の型 に沿って書けるようになりました。書籍『6分間文章術 / 中野 巧[著]（ダイヤモンド社）』 で紹介されている型なのですが、書くことに慣れていても観点の抜け漏れがあったり読者に響かなかったりするので、その防止になっています。 ポジティブな意見、ネガティブな意見を事前に考えることで読者目線になれますし、ネガティブなことは先回りして炎上防止の工夫ができるようになります。 高玉 ：これを使い続けていたらはてブの数も伸びてきたので、効果は出ていると思います。 その他には 法務部と苦労して作成したチェックリスト があります。何がダメで何が許されるのかの境界が分かるリストで、執筆者の上司はそれを確認して校了するというフローです。 商標や著作権に関する確認はもちろんですが、「この記事を読んだ人がBIGLOBEを応援したい、働きたいと思えるか？」を一番最初に確認しています。 お題５：課題に感じていること 吉川 ：次の 編集部人材の育成（ノウハウの継承） も課題ですね。 高玉 ：そうですね。私の場合、コンテンツスケジュールが逼迫してくると自分で書けばなんとかなると思ってしまうのが悪いところ。新しい血を入れることで、 効率よく記事を生産できる仕組み作りに挑戦 してくれるんじゃないかと思います。記事を書くための型やチェックリストもあり引き継ぐ準備はできています(笑) あとは、 自主的に書きたいという人が増えると嬉しい です。 吉田 ：同感です。こちらがアクションしなくても、書きたい！載せたい！と言ってもらいたいです。 高玉 ：社内を元気にするために讃える場所としてBIGLOBE Styleを使い倒して欲しいです。いい仕事をしたから社外に知らせようよ、そのために記事を書く時間を使っていいから！といった感じでリーダーがメンバーにかけあってくれるようになるといいですよね。 塚本 ：この先のネタが枯れてこないかという心配はどうですか。 高玉 ：「TechBlogで社外に成果を公表する」ために新しいことに挑戦しようよ！と、逆転の発想で使ってもらえるようになれば、ネタは安泰なんですが。社会に影響を与えたり、自分たちの市場価値を高めるために新しいことに挑戦する流れを、もっと作っていきたいです。 塚本 ：そうですね、新しいことを始めるときや事業拡大していくときの宣伝という発想で使って欲しいですね。 お題６：印象に残っている記事 吉川 ：私は2021年1月にBIGLOBEへ中途入社しました。「エンジニア部門における新サービス創出活動の推進」という業務内容で、自分自身はエンジニアではないので多少不安があったんですよね。そんな時この記事を読んで、こんなに新しい活動にポジティブな人たちが上にいるなら大丈夫だと思えたことを覚えています。船が向かう方向が分かると安心しますから、 トップや部門長のマインドは大事 ですよね。 2020/07/01 BIGLOBEエンジニアはどんな未来を目指す？「10年後の未来を語るパネルディスカッション」レポート style.biglobe.co.jp 高玉 ：たくさんあるのですが、ブコメを有効にした効果か、初ホットエントリー入りした記事が嬉しかったですね。 2020/02/05 BIGLOBEという、自分にぴったりの会社で楽しく働いている話 style.biglobe.co.jp   森山 ：立ち上げ当初の記事はどれも印象深いですが…強いて挙げるとしたら私が担当していたこの記事。カメラが得意なわけではないのですが、私が撮った写真をアイコンにしてくれていたので思い出深いです。 2020/06/17 人事部長はジンジニア★～強い”チームBIGLOBE”を目指して～ style.biglobe.co.jp   吉田 ：どれも印象深いので悩ましいですが…。コロナウイルス感染対策で、いち早く在宅勤務を導入した様子を伝える記事です。旬だったので検索流入が多かったですね。 2020/03/09 緊急レポート第１弾「在宅勤務はじめました」（人事部門編） style.biglobe.co.jp   塚本 ：私はこの2つの記事です。 まずは、BIGLOBEのDNAを知ってもらいたいことから企画した、BIGLOBEの歴史を知るレジェンドの記事です。これをきっかけに中途入社オンボーディングでもサービスの歴史を紹介するようになり、好評を得ています。 2022/09/14 パソコン通信「PC-VAN」を育て上げたレジェンドが語る新サービス創出の秘訣！ style.biglobe.co.jp 次は、新卒担当森山さんがどんな思いで学生に寄り添っているのかを語った記事です。就活生のことを考えると、採用担当者の顔や思いが見えたほうが安心しますからね。 2022/01/19 学生目線で不安に寄り添い、期待を超えていく！皆が、自分らしさを出し挑戦していくためのサポーターでありたい style.biglobe.co.jp   お題７：今後の展望 高玉 ：TechBlogが独り立ちできるくらい強いメディアになったらすごいですね。ITエンジニア向けのオススメに、TechBlogが取り上げられるくらい記事を充実させたいです。そうなるには、社外に自慢できる仕事をする（そうなるようにリーダーがメンバーをその気にさせる）、たとえ成功しなかったとしてもいい挑戦にはスポットライトを当てて評価したりみんなに紹介する、といったことをさらに強化していく必要がありそうです。昼礼でもTechBlogを話題にしてもうことは多いのですが、もっともっと盛り上げていきたいです💪 吉田 ：TechBlogからの回遊がなくなると思うと心細いです…！ 採用向けのメディアではありますが、社内の人にももっと読んでもらえたら嬉しいです。社内の出来事や仲間の思いを横断的に知って、 チームビッグローブ となって前に進んでいきたいです。   以上、BIGLOBE Style編集部座談会の様子でした！最後までお読みいただきありがとうございました。 www.biglobe.co.jp   ※ 記載している団体、製品名、サービス名称は各社の商標または登録商標です。

※（追記） 登壇者の諸般の事情により、2023年3月24日に開催された「Google Workspace Summit 2023」にて「 事業部門とDXを育てるBIGLOBEの試み 」として発表させていただきました。登録フォームにご記入いただくことで、オンデマンド配信をご覧いただけます。 大変申し訳ございません。 詳しくは「 主催者HP 」をご覧ください。 ・・・・・・・・・・ 2022年12月9日(金)に開催される「 Google Workspace Review 2022 」に当社 基盤本部の高玉広和が登壇いたします。 BIGLOBEでは2017年より Google Workspace を導入し、ローコード開発プラットフォーム Apps Script を活用しながら、内製開発で業務を効率化してきました。先日 TechBlog で公開した記事「 QRコードとApps Scriptで社内業務を楽しくデジタル化 」がご縁となり、BIGLOBEがGoogle WorkspaceやApps Scriptを活用しながらどうやって業務改善を進めているのか、具体例をご紹介させていただくことになりました。 次々と新しい機能が追加され、ますます便利になるGoogle Workspace。当イベントはその最新動向についても学ぶことができます。オンライン視聴が可能ですので、ぜひご参加ください。 イベント名 Google Workspace Review 2022 主催 グーグル・クラウド・ジャパン合同会社 開催日時 12月9日（金）16:00 - 18:00 プログラム 時間 内容 16:00-16:05 開会 16:05-16:25 Google Workspace注目アップデートのおさらい 16:25-16:45 Google Workspace活用事例1 BIGLOBE社員がGoogle Workspaceの活用事例をご紹介 16:45-17:05 Google Workspace活用事例2 株式会社明治クッカー様 17:05-17:25 AppSheet 最新活用情報まとめ！ データ活用を推進するノーコードツールの基礎編から活用事例まで 17:25-17:50 特別対談：Google Workspace YouTuber 西原様 × Google Cloud Customer Engineer 川嶋様 17:50-18:00 閉会 お申し込み（オンライン開催） cloudonair.withgoogle.com 当社登壇者プロフィール 高玉 広和（たかたま ひろかず） ビッグローブ株式会社 基盤本部 基盤統括部 基盤戦略グループ エキスパート 2008年よりビッグローブ株式会社でサービス企画、マーケティング、開発などさまざまな業務を経験。2019年よりエンジニア採用・育成を担当。 関連記事 style.biglobe.co.jp ※ Google Workspaceは、Google LLCの商標です。 ※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。