新着 の記事一覧

先日開催された、セキュリティ・キャンプ 全国大会 2023に、GMOインターネットグループはシルバーメンバーで協賛しました。当日は企業紹介イベントへの参加や、GMOインターネットグループの社員が講師として参加してきましたので、その内容をレポートしていきます！ イベント概要 セキュリティ・キャンプ全国大会とは 「セキュリティ・キャンプ」のメインイベントとして主に夏休み期間中に実施する合宿形式の勉強会です。 毎年テーマ別に集められるエキスパートが講師となり、専門的・実践的な講義が受講できるほか、合宿の中で同じ趣味を持った仲間との交流もあります。全国大会のほか、全国大会修了生の次のステップとなるネクストキャンプ、小中学生を対象としたジュニアキャンプも同時開催いたします。また会期中には、これまでにセキュリティ・キャンプに参加した修了生がチューターとして学習の支援等も行います。 開催日：2023年8月7日（月）～8月11日（金）開催場所：クロス・ウェーブ府中参加費：無料（事前登録制）主催：独立行政法人情報処理推進機構（IPA）、一般社団法人セキュリティ・キャンプ協議会公式HP：https://www.security-camp.or.jp/IPA HP：https://www.ipa.go.jp/jinzai/security-camp/2023/zenkoku/index.html 会場となるクロス・ウェーブ府中は、勉強する部屋、食堂、ホテルがすべて建物内に入っており、学生たちは過ごしやすそうで勉強に集中しやすい環境が整ってました。 「このはちゃんポーチ」使ってくれたかな？！ 参加者には、各協賛企業からのノベルティが事前配布という形で各自宅に郵送されました。 GMOインターネットグループからは、合宿期間中に使用できるようにと、小物類など持ち運びに使える『このはちゃんポーチ』をプレゼントさせていただきました！！ 弊社のホスティングサービス「ConoHa by GMO」のキャラクターである”美雲このは”です。是非たくさん使ってくださいね～！！ 企業紹介イベント 今回は現場で活躍するエンジニアと人事が参加させていただきました。 前半は人事より、会社説明や働く環境について詳しく説明させていただきました。後半はセキュリティに携わるエンジニア2名より、実際に行っている業務内容や働いていくうえでのモチベーションなど、なかなか聞けないリアルな現場の話をお話しました。 最後の質問タイムではたくさんの声をいただき、有意義な時間になったのではないかなと思います。 参加してくれた方にはGMOオリジナルノベルティをプレゼントさせていただきました！ GMO講師 GMOインターネットグループより、講師として複数名参加いたしました。実際に参加してみての感想やインタビューをいただきました！ GMOペパボ株式会社 紫関 麗王 開発コース│Z2『Rust製Linux向けアンチウィルス実装ゼミ』 Q：全国大会の講師を終えての感想 紫関セキュリティ・キャンプ全国大会には2020年に受講生としてオンラインで参加したため、オフライン会場での参加は初めてでした。今回は講師という立場での参加でしたが、受講生と共に、自分も多くの事を学びました。 Q：学生へのメッセージ 紫関セキュリティ・キャンプは恐らく来年も開催されるでしょう。密度の高く、熱量もある濃密な5日間を過ごすことができる貴重なイベントなので、今年参加できなかった方もぜひ来年またチャレンジしてください。 GMOサイバーセキュリティ byイエラエ株式会社 三村 聡志 専門コース│A4『ローレイヤーから見るファイルシステムの理解』 開発コース│X1『リバースエンジニアリングゼミ』 Q：全国大会の講師を終えての感想 三村今年も昨年に引き続き、専門コースで1講義と開発コースのひとつを担当しました。「ローレイヤーから見るファイルシステムの理解」は、昨年や他のミニキャンプでも行っている内容で、xxd コマンドと grep と電卓だけで FAT32 を読み進めるという講義になります。慣れるまでがとてもハードな内容とはなりますが、今年は終わったあとに「とても楽しかった」という感想をもらう事も出来、私の方もとても楽しかったです。また「リバースエンジニアリングゼミ」は本業で行っている IoT ペネトレーションテストをそのまま一週間行うような講義になっています。全国大会の講師は昨年に引き続きとなりますが、参加者の知識や感性が異なるため、毎回新しい発見や刺激があってとても楽しいコースと感じています。来年も機会があれば引き続き担当出来たらと思っています。 Q：学生へのメッセージ 三村ものごとの仕組みを知る、基礎を知るというのはとても大事なことだと考えています。「USB端子に機器を接続すれば繋がる」ということは知っていても、機器が使えるようになるまでにどのような通信が行われているのか、機器が繋がったことをどうやって知るのか、などそこには通常知られていない様々な技術が隠れています。仕組みを深く知るためにはそれなりの時間や手間が掛かりますが、知ることができればそこから新たな世界が見え、新たな活用方法・攻撃手法の発見に繋がっていきます。是非学生のうちに、ものごとの仕組みや基礎の学習・調査を進め、ワクワクがあふれ出るエンジニアに皆さんがなられることを願っています。 GMOサイバーセキュリティ byイエラエ株式会社 緑川 志穂 開発コース│L1『暗号化通信ゼミ』 Q：全国大会の講師を終えての感想 緑川講師を拝命するのも6回目になりますけれども、受講生の方々のバイタリティには毎年驚かされるばかりです。そして久々のオフライン開催はオンライン指導との違いを改めて感じさせてくれました。開発コースではしばしば事前学習期間に極めて高い比重を置きますし、私の担当したゼミも事前学習期間が寧ろメインの指導期間となっていました。それでもオフラインで開催された5日間は事前学習よりもひときわ濃い印象を残したと感じます。叶うなら来年も是非オフラインで参加したいところです。 Q：学生へのメッセージ 緑川閉講式で言われたことを覚えておられるかもしれませんが、キャンプ修了後に重要なのはモチベーションの維持です。でも本記事の投稿の頃にはそろそろ一度息切れする頃かとも思います。五線譜に描かれる休符に無駄なものが無いように、休むこともまたモチベーションへと寄与します。キャンプ以降幾星霜が経過しても能力を発揮し続けられるよう、頭に留めてもらえると幸いです。 GMOサイバーセキュリティ byイエラエ株式会社 西谷 完太 / 山崎 啓太郎 専門コース│B6『ソースコード解析によるWebアプリケーションの脆弱性調査』 Q：全国大会の講師を終えての感想 西谷去年講義を行った「マイクロサービス／分散モノリス的アーキテクチャへの攻撃手法」では、近年普及が進んでいるクラウドサービスやマイクロサービスアーキテクチャを題材にした各サービス連携時に発生する脆弱性を使った攻撃手法を取り扱いました。今年の講義は「ソースコード解析によるWebアプリケーションの脆弱性調査」ということで、よりアプリケーション単体のロジックにフォーカスし、ソースコードの静的解析による脆弱性調査の楽しさや開発者自身が原因の特定などに役立ててもらうための内容を盛り込んだ内容となっています。また、CodeQLなどWebセキュリティの中でも比較的新しいトピックを講義内容に盛り込んでいるので学生だけでなくエンジニアが興味を持って取り込める内容だと思いますので、興味があれば今後公開予定の資料を覗いて取り組んでもらえると幸いです。 山崎講義は手動でのソースコード解析とツールによる自動化という内容で行いましたが、比較的実践的な内容になったかと思います。専門Bコースでは本講義の他にもWebプロダクトのセキュリティーやその周辺に関連した講義から構成されており、どれも社会人にとっても面白い講義だったのが印象的でした。 Q：学生へのメッセージ 西谷各プログラミング言語やソースコードリーディングだけでなく、様々な知識を必要とする講義で取り組むのが非常に大変だったと思います。ただ、その中でソースコードの静的解析による脆弱性調査の楽しさや開発者自身が原因の特定など、あなた自身のやりたいこと、やっていることに少しでも役立てていただければ幸いです。 山崎今回の講義の後半ではソースコード解析ツールを利用してクエリを書いてもらいましたが、実際には開発者の意図や状況を想定して人間がソースコードや設計書を読み、動作を検証しなければ見つかりづらい脆弱性がまだまだ多く存在しますし、今後も必要とされるスキルだと思います。ソースコードを読んでバグを探す時には様々な知識や経験が役に立つので、本講義が自身の興味を広げたり新しい知識を得る一助になっていると嬉しいです。 ▼講義資料はこちらhttps://gmo-cybersecurity.com/news/security_camp_presentation_slide_20230912/ さいごに セキュリティ・キャンプ全国大会2023にご参加された学生の皆さま、5日間の勉強合宿、大変お疲れさまでした！！皆さんの今後の頑張り・活躍を応援し期待しております！

こんにちは！GMOインターネットグループの儀部です。「GMOデジキッズ at GMO kitaQ 2023」は、北九州市教育委員会のご後援、株式会社LAC、DELL株式会社の協賛のもと、株式会社ギラヴァンツ北九州様とのコラボレーションで開催いたしました。ギラヴァンツ北九州様の選手やマスコットのギランくんにも会場にお越しいただき、大盛況となった今年のデジキッズをレポートします！ はじめに GMOデジキッズとは 子ども向けのプログラミング教育を支援するプロジェクトでプログラミング教育カリキュラムの構築や教育現場の支援、子ども向けプログラミングイベントの開催、企業訪問によるIT人材のキャリア教育支援など、次世代を担うIT人材の育成につながる活動に取り組んでいます。 開催目的 小中学校で必修化したプログラミングを基礎から応用まで体験していただき、北九州に住む子どもたちのITスキル向上に貢献したいという思いから開催に至りました。 イベント概要 日時：2023年8月5日(土)、6日(日) 10:00~17:00場所：GMOインターネットグループ 北九州オフィス（GMO kitaQ）対象：小学4~6年生定員：25名/日　※約120名の応募から厳正なる抽選で決定参加：無料イベントページ：https://developers.gmo.jp/kitaq/digikids2023/ コンテンツ概要 Scratchを使ってみんなで基礎的なプログラミングを実践しながら学んでいきます。その後、学んだ基礎知識を活かしてオリジナルゲームの制作に個々で取り組みます。完成したオリジナルゲームは保護者の前で1人ずつ発表します。 レクリエーション プログラミングの基本となる3つの処理「順次・分岐・くり返し」を体を動かして学んでもららう時間です。 上から下へ進んでいくブロックの通りに笛の合図で動いてもらいました。 Scrachのブロックを使用しました！ 続いて実際にScrachを使ってプログラミングの実践へと移ります！ 基礎編　～このはちゃんスイカ割りゲームを作ってみよう～ 基礎編では、弊社の商材「ConoHa」で使われているキャラクターである”美雲このは“がスイカ割りをするゲームを作成してもらいました。 このゲームは、「順次・分岐・くり返し」の考え方を学べる内容になっています。 スイカ割りゲーム 先生たちもサポートしてくれるので安心です！ 応用編 ～自分だけのオリジナルゲームを作ってみよう～ 5つのゲームの中から1つ選んでもらい、基礎編で学んだ内容を応用したゲームの制作に取り組んでもらいました。今年はギラヴァンツ北九州様とのコラボレーションということで、サッカーに関係したゲームを多く用意しました！ 制作時間は、45分×3セットで合計135分です。 たいきゅうドリブルゲームスライドパズルゲームくずせ！サッカーボールタワーゲームPKゲームおいかけっこゲーム ゲームにはユニフォーム姿のこのはちゃんやギランくんが登場します！ 選手やギランくんも応援にかけつけてくれました！ 完成して時間が余った子はゲームにアレンジを加えて、よりオリジナルティのあるものにしてもらいました。 時間いっぱい取り組んでもらい、個性溢れるゲームを完成させることができました！ オリジナルゲーム発表会 最後は、保護者や兄弟の前で完成したゲームをお披露目！ 1人ずつ時間を取り、ゲーム制作で「工夫したところ」、「頑張ったところ」について発表をしてもらいました。 クオリティの高いものやオリジナリティのあるものが多数あり、限られた時間の中で制作したオリジナルゲームについて発表する姿は素晴らしかったです。 どのゲームもオンリーワンで本当に素晴らしかったです！ 発表の後には先生たちからもコメントをもらいました！ 最後に GMOインターネットグループでは、これからも「GMOデジキッズ」などの子供向けのプログラミングイベントを開催することにより、次世代を担うIT人材の育成につながる活動に取り組んでいきます。 以下より本イベントで使われたScratchをご覧いただけます。この機会にぜひご覧ください。 https://scratch.mit.edu/studios/31934878 ご参加ありがとうございました！ おまけ

こんにちは、GMOインターネットグループ株式会社の小林です。今回はセキュリティ対策の一環で導入しました、Yubileyについてご紹介させていただきます。 導入背景 以前よりMicrosoft365を導入していましたが、元々はID/PASSでの認証でした。それでは脆弱な状態であると判断し、全パートナーにスマートフォンを配布して多要素認証を導入しました。しかし、コールセンターや特定の業務のみに従事している場合は多要素認証のためだけにスマートフォンを配布するため一定のリスクが伴います。そのためID/PASSのみの認証にはならずに多要素認証を実装できるYubikeyの導入を決めました。 Yubikeyとは Yubikoという会社が開発したセキュリティキーで、用途に応じて複数の種類が発売されています。今回導入したのは以下画像にあるUSBのような形状のものになります。 種類についての詳しくは日本の公式代理店であるソフト技研のサイトを参考にしてください。 導入方法 Yubikeyが使用できるサービスは様々ありますが、今回は全パートナーに導入済のMicrosoftアカウントの認証に実装してみました（多要素認証を実装するためには事前にMicrosoftのライセンス及びMicrosoftアカウントの設定が必要になりますのでご注意ください） 簡単にユーザーが使用を開始できるまでの方法をご紹介させていただきます。 ①Yubikeyのソフトウエアを使用するPCにインストールします（Yubico Authenticater）②PCにインストールされたYubico Authenticaterを起動します。 ③Yubikeyデバイスをパソコンに接続します。 ④Yubikeyを接続するとアプリが以下の画面に代わります。　「三本リーダー」をクリックします。 ⑤「Add account」をクリックします。 ⑥以下のリンクをクリックし、Microsoft365のセキュリティページにアクセスします。　Microsoft365マイアカウント-セキュリティ確認　「＋サインイン方法の追加」をクリックします。 ⑦「認証アプリ」を選択し、「追加」をクリックします。 ⑧「別の認証アプリを使用します」をクリックします。 ⑨「次へ」をクリックします。 ⑩認証アプリのQRコードが表示されます。　㋐Yubico Authenticaterの「Scan QR code」をクリックします。　㋑Yubico Authenticaterの「Require touch」をクリックします。　㋒Yubico Authenticaterの「Save」をクリックします。　㋓認証アプリの「次へ」をクリックします。 ⑪Yubico Authenticaterにメールアドレスを登録されます。　㋐Yubico Authenticaterに登録されているアカウントの「指マーク」をクリックします。　㋑Touch requiredというメッセージが表示されますので、Yubikeyデバイスの金属部分をタッチします。　㋒認証の番号が表示されますので、認証アプリの「コード入力」場所に入力します。　㋓認証アプリの「次へ」をクリックします。 ⑫認証アプリの登録が完了するとセキュリティ情報に認証アプリが表示されます。 利用方法 次回以降、再認証がMicrosoftのログインページで求められる際はパスワード認証の後に以下の認証が求めらます。表示されたらYubico Authenticatorからコードを取得して入力してログインできれば認証完了となります。 ※Yubico Authenticatorのコードを確認する方法 ①Yubico Authenticatorのアプリを起動します。 ②Yubicoアプリに登録されているアカウントの「指マーク」をクリックします。 ③以下の画面が表示されますので、「Calculate」アイコンをクリックします。 ④「Touch required」のメッセージが表示されます。 ⑤Yubikeyデバイスの指定した場所を「タッチ」します。 ⑥Yubico Authenticatorの認証コードが表示されます。 まとめ Yubikeyの設定自体は簡単で、仕様を理解していれば短時間で導入可能です。 実際の多要素認証の場面では物理的に触れることで認証されるため、業務で利用するパートナーにとっても理解しやすいものとなります。導入によりスマートフォンを使用する多要素認証よりも問い合わせが少なくなり、IT部門と利用者の双方の負担が軽減され、時間とリソースを節約することもできます。ご参考になれば幸いです。

GMOインターネットグループとして、iOSDC Japan 2023にトップスポンサーとして協賛いたします！スポンサーセッション企画や、ブース、ノベルティ情報、チャレンジトークンについてご紹介いたします。 iOSDC Japanとは？ iOSDC Japan 2023はiOSをテーマとした技術者のためのカンファレンスです。リアル会場とオンライン配信のハイブリッド開催にて実施します。 世界中から公募した知的好奇心を刺激するようなトークや、参加型のアンカンファレンスなど、初心者から上級者まで楽しめるコンテンツが幅広く揃うイベントです！ イベント概要 開催日：2023年9月1日（金）〜9月3日（日）場所：早稲田大学理工学部 西早稲田キャンパス+ ニコニコ生放送対象：iOS関連技術およびすべてのソフトウェア技術者主催：iOSDC Japan 2023 実行委員会参加方法：チケット購入制（チケット購入はこちらから）公式HP：https://iosdc.jp/2023/ ［スポンサーセッション］ minneを通じて感じた歴史とその先を見据えた取り組みや挑戦に触れて 2023年9月2日（土）15：05～15：25GMOペパボ株式会社　酒井 文也 弊社GMOペパボが運営するハンドメイドマーケット「minne（ミンネ）」は、今年で11周年を迎え、様々な思い出や歴史の変遷がありました。歴史が長いサービスの開発では「目に見えない複雑さ」や「小さな事が重大である」等、その歴史故の難しさも数多くあります。一方で、その困難を解決した先人の偉大な資産やストーリーも一緒にあります。そして、より良く＆より価値を出すため、その歴史を踏まえ、その先を見据えた取り組みや挑戦が求められます。本セッションでは、minneのiOSアプリ開発を通じた「その先を見据えた取り組み」の具体例を、実務での体験談やチーム内開発での事例と合わせてご紹介できればと思います。【取り組み事例】1.MVVM + SwiftUIへリプレイスする取り組み2.iOSアプリの基盤部分の変化へできる限り追従する挑戦3.施策や調整時のサーバー側との積極的な関わりや共同作業https://fortee.jp/iosdc-japan-2023/proposal/a7b81eb5-3e27-4f73-8fda-b46bf3e0179d ［パンフレット記事］ iOSDC参加者に送られるノベルティの中にパンフレットがあり、その中に下記記事が掲載されております！ 実はそのUI実装や機能はDIYできちゃう！個人的にも活用している実現Tips集 GMOペパボ株式会社　酒井 文也 https://fortee.jp/iosdc-japan-2023/proposal/805ab467-e595-43b4-a6d2-681777644fe0本文リンク：https://github.com/fumiyasac/iosdc2023_pamphlet_manuscript_vol1/blob/main/manuscript.md UIKit＆SwiftUIとCombineを組み合わせた処理で上手にUnitTestを整えていくアイデア解説 GMOペパボ株式会社　酒井 文也 https://fortee.jp/iosdc-japan-2023/proposal/527be76c-336d-448f-9db4-6c2879949c4f本文リンク：https://github.com/fumiyasac/iosdc2023_pamphlet_manuscript_vol2/blob/main/manuscript.md 事前配布ノベルテイボックス GMOペパボ株式会社より2点のノベルティをプレゼント！！創業20周年を記念したデザインになっております。 マジックキューブペパボの「もっとおもしろくできる」物事を様々な角度から見ておもしろさを発見できるという企業理念に沿って作成しました！疲れた時の脳トレ、リフレッシュに是非たくさん使ってください。 しおりGMOペパボのイベントで大好評のしおり！今回新しいデザインで制作しました！ GMOペパボからマジックキューブについて、すでに動かしちゃって正解がわからないというかたに正解の写真を掲載しています！ 是非ブースで一緒にマジックキューブ揃えましょう！ https://tech.pepabo.com/2023/08/25/iosdc/ ブース出展 GMOインターネットグループブース　iOS DE BINGO！ 今回のテーマは、ビンゴゲーム「iOS DE BINGO！」を出展します。 参加者全員に参加賞がもらえるほか、iOSのクイズに正解しビンゴゲームをクリアすると特製ノベルティをプレゼント！全マス開けた方や、GMOブースに毎日遊びに来てくれた方には豪華賞品も用意しています。 会場参加される方はぜひGMOインターネットグループのブースにも足を運んでくださいね！ iOSDCチャレンジ iOSDC2023では、開催期間中の企画として「iOSDCチャレンジ」を実施しています！参加者の方は「iOSDCトークン」を探していただき、見つけたトークンの数で各種企画への参加権を得る企画です。 GMOインターネットグループが設定しているトークンは全3種！ GMOブースのビンゴゲームにも、トークンが隠れているかも…？ さいごに iOSDCは、日本最大規模のiOS開発者向けのカンファレンスです。 ぜひ皆様にもご参加いただき、学びの場として様々な方とコミュニケーションをとっていただければと思います。 当日は皆さまとお会いできることを楽しみにしております！オンラインの方も配信を通してお会いしましょう！

こんにちは、GMOインターネットグループ株式会社の河﨑屋です。今回はOJT（実務研修）の一環で新卒の方々と一緒にイベントストーミングを行った話をご紹介します。 710プログラムとは 現在GMOインターネットグループでは、新卒世代で最高のポテンシャルを秘めた人財に集まってもらうべく『新卒年収710万円プログラム』を実施しております。（初任給・給与ナンバーワン~新卒年収710万プログラム~） 従来の新卒パートナーの倍以上のパフォーマンスを発揮できる優秀な人財に対して年収710万円（2年間）をお約束するものです。将来的にはグループ会社の社長や各事業の責任者など、今後のGMOインターネットグループをリードする「リーダー人財」を目指していただきます。ぜひ興味のある学生の方はご確認ください。 参加者 本OJTには下記メンバーにご参加いただきました。筆者は②の商材システムの開発運用を行うエンジニアとして参加しました。 ①2023年にご入社いただいた710プログラムの新卒パートナー（以下 710新卒と呼称） ②ドメインエキスパート（商材システムの開発運用に従事しているエンジニア） ③ファシリテーター（会議の進行や参加者から質問を引き出す役） 今回のOJTの目的 イベントストーミングの目的としては710新卒の方々にイベントストーミングを通じて商材に関する知識を身に着けてもらうことと、エンジニアと協創するという経験から実際の業務でも円滑に進められるようなリレーションの構築を促すことです。 イベントストーミングとは イベントストーミングは、特定の「ドメイン」、すなわち問題を解決しようとしている特定の領域やビジネスロジックなどを理解し、モデル化するための手法です。ここでの「モデル」とは、現実世界の複雑な部分をシンプルに表現したものです。 今回のイベントストーミングはGMOインターネットグループ内で普段使用しているフォーマットを踏襲して進めていきました。ここでは詳しい説明は省きますが、興味のある方は以下の資料をご確認いただければイメージを掴めるかと思います。 参考資料：イベントストーミング&イベントソーシング入門 イベントストーミングのモデル例 新卒OJT版イベントストーミングの進め方 今回の研修では、主に3つのセグメント（ドメイン事業・ホスティング事業・アクセス事業）の代表的な商材をイベントストーミングの対象として実施しました。 なお、以下に示す例は実際に作成したものとは異なり、今回の執筆に伴い筆者の方で新たに作成したものになっています。ここでは、レンタルサーバーのサービスにフォーカスを当てています。 イベントの洗い出し 最初に想定しうるイベントを洗い出すことを行いました。710新卒の方々はプロダクトの仕様に関してまだ詳しくなかったので、システムの裏側を理解しているドメインエキスパートと対話しながら進めていきました。 洗い出されたイベントの一例 時系列の整理 次に、洗い出したイベントを時系列で整理しました。この段階でイベントが適切なものか、重複はないかなどの精査も併せて進めました。 時系列にまとめられたイベントの一例 懸念点・問題点の洗い出し 時系列で整理していくと、イベント単位で気になることや前後のイベント関係が不十分な箇所が出てきました。その部分をホットスポットとして、メモに記録しておきました。 留意事項をホットスポットで記載 モデルの構造化 イベント以外にも、コマンド、ポリシーなどの概念を加えて、モデルの構築を進めました。この段階で、ホットスポットに対して深掘りし、慎重に解決策を探りました。 構造化されたイベントストーミングの一例 やってみて感じたこと イベントストーミングは特別なスキルセットが必要なく、様々な属性を持つステークホルダーと共通理解を作り上げる手法だと説明されています。確かに今回参加した710新卒の方々はプロダクトの仕様をほとんど知らない状態から始め、自分たちの言葉で仕様を説明できるというレベルにまで到達することができました。 ですが、課題点もいくつか見受けられたので、こちらを共有します。 まず710新卒の方々を苦しめたのはドメインエキスパートが使う言葉でした。システム開発の経験がほとんどない710新卒の方々にとって、サービス、バッチ処理、API、DBなどの用語は混乱の元でした。それを察知して、少しでもイメージしやすいようにという気持ちから、ドメインエキスパートが曖昧な表現をしてしまい、さらなる混乱を生む場面もありました。 仕様を深堀りする、解像度を揃えるという作業には、高いコミュニケーション能力と、物事を構造的に把握する能力がとても重要に感じました。言葉の意味を注意深く察知し、「VMってなんだ？？」「レジストリとレジストラって一緒ですか？？」など積極的に質問している姿はとても印象的でした。 仕様を共有するドメインエキスパート側の姿勢も重要でした。システムの仕様を説明する際、どういった経緯で今の仕様を採用しているのか、身近なエピソードや具体例を交えて説明するなど、抽象と具象のバランス感覚を身につけることで、より深くシステムの概念やプロセスを共有できると感じました。 まとめ 今回筆者はドメインエキスパートとして参加しましたが、710新卒の方々とともに自分たちのサービスを見直す機会はすごく刺激的でした。「どうしてこんな構造なんだろう？」「ここはなぜ共通化できないんですか？」など出来上がったシステムだけを見ている私では気にも留めないようなことが、外から見ると目立ち、改善のヒントになることを新たに発見しました。 イベントストーミングはDDDにおけるモデル設計手法の一つというイメージが強かったのですが、今回のように開発者以外の方ともサービスの現在地点を共有し、新たな視点や知識を創造するための有効な手段になりうると感じました。 ぜひこの記事を読んでいただいた皆さんもイベントストーミングの魅力に触れてみませんか？可能性を探求し、創造の旅へ一歩踏み出しましょう。新たな視点を開拓するチャンスを掴んでください！

GMOインターネットグループは、学生エンジニア向けオンライン勉強会「技育CAMP アカデミア」にて、GMOエキスパートシリーズを開催します！今回はデベロッパーエキスパートの黒瀧 悠太が登壇し、「ブロックチェーンアプリケーション開発入門」について勉強会を実施いたします。学生のみなさん是非ご参加ください！ 技育CAMPとは？ 「自ら考え、自ら創る」ことができる未来のエンジニアを育てるキャリア育成プログラム「技育プロジェクト」の一環で、「未来の技術者を育てる」ことを目的とした、エンジニアを志す学生の皆さんにハッカソンと勉強会を通して継続的なインプットとアウトプットの場を提供するスキルアップ支援プラットフォームです。 GMOインターネットグループはその理念に共感し、スポンサーとして年間協賛しています。 イベント概要 開催日時：2023年8月24日（木）18：00～19：30会　　場：Zoomにてオンライン開催参加費用：無料（事前登録制）公式HP：https://talent.supporterz.jp/events/8d9128c8-d8b8-48be-b75a-31c7dd4c909c/主　　催：株式会社サポーターズ 「ブロックチェーンアプリケーション開発入門」 GMOインターネットグループ デベロッパーエキスパート黒瀧 悠太（@kurotaky） Web3に関連する技術について、これから学び始める方を対象に、Webのこれまでの技術を俯瞰しながらブロックチェーンアプリケーション開発の基本を学びます。主に以下のようなトピックを扱います。- Web3の歴史とその影響- Web3とブロックチェーンの概要- 仮想通貨とブロックチェーンの関連性- スマートコントラクトとは何か- 分散型アプリケーション（DApps）の例とその開発についてブロックチェーンを利用したWebアプリケーション開発に必要な知識を学びたい人にオススメのイベントです。 ＜注意事項＞申し込み人数が予定数に達した場合、申し込み締切日（8/24(木)18：00）より前に受付終了いたします。アーカイブは残しませんので、当日是非ご参加ください！ 参加申し込みはこちら こんな方におすすめ どなたでもOKWeb3やブロックチェーンの概要について学びたいブロックチェーンアプリケーション開発の基本を学びたい 最後に 本セッションは座学だけではなく、皆さんとコミュニケーションをとりながら手を動かして進めることができる体験型の勉強会になります。 学生の皆さまのご参加をお待ちしております！ 参加申し込みはこちら

6月24日（土）に福岡ファッションビルにて開催されたPHPのイベント「PHPカンファレンス福岡2023」にGMOペパボ株式会社 小山健一郎（@k1LoW）が登壇しました。セッションでは、小山が開発するtblsというツールを題材に「Documentation as Code」という考え方について解説していきました。 登壇者 小山 健一郎　＠k1LoWGMOペパボ株式会社 技術部 技術基盤チーム https://speakerdeck.com/k1low/phpconfuk-2023 tblsとは ドキュメント運用の1つのアプローチであるDocumentation as Code（その一部はhttps://speakerdeck.com/k1low でみることができます）。そして、Documentation as Codeを実現したツールがtblsです。 tblsは、データベースからドキュメントを生成するCIフレンドリなツールであり、データベースに接続してER図付きのマークダウン形式のドキュメントを生成します。2018年5月17日より開発がスタートしており、PostgreSQL、MySQLをはじめとするRDBMSのほか、BigQueryやAmazon DynamoDB、Cloud Spannerなど14のデータソースに対応しています。 Documentation as Codeとは ドキュメンテーションについてのコミュニティである「Write the Docs」において、Documentation as Codeとは、「コードと同じツールを使ってドキュメンテーションを書くべきだという哲学」と定義されています。小山はこの定義に対し「システム開発の近くにドキュメント作成の仕組みを置くことで、開発サイクルのなかにドキュメント作成を統合して、システムとドキュメントの乖離を少しでも小さくしようという考え方だと思っている」と、自身の解釈について説明します。 ただし、システムとドキュメントの乖離を小さくするという考え方のみでは、実用に耐えない場合もあると小山はいいます。 「たとえば、システムのアーキテクチャを説明しているドキュメントにはAと書いてあったのに、現場の人に聞いたら『それは先週Bになった』といわれてしまうケースが考えられる。こうして開発時にドキュメントとの乖離があると手戻りが発生するおそれがある。すると、誰もドキュメントを信用しなくなり、読まれなくなる。結果として、ドキュメント更新のモチベーションが低下し、システムとドキュメントの乖離がさらに広がるという負のループに陥る。かといって、システムは日々開発が進むため、機能追加や改修の際、常にドキュメントと一緒にPull Requestを出せるかというとそうではない。ドキュメントをレビューするタイミングがないというのも課題になる」（小山） システムとドキュメントの乖離をゼロにする「Documentation as Code+」 そもそもシステムとドキュメントの乖離はなぜ起こるのでしょうか。小山は、「システムは時間の経過によって変化するが、ドキュメントはその変化に追従しない、もしくは追従するにもタイムラグが発生するため」と説明します。そして、「時間経過に耐えうるには、システムを都度そのままドキュメントに変換できればよい」とします。この結論は、実際に小山がモデル化して導出し、確認したといいます。さらに、システムをそのままドキュメントに変換するには、「システムからドキュメントのもとになる構造化データを抽出できればよい」と指摘する小山。「これにより、システムとドキュメントの乖離をゼロにできると考えた」と述べます。 （参考）「システムの変化に追従可能でかつ理解し易いドキュメントシステムのモデル化」 https://speakerdeck.com/k1low/web-system-architecture-number-8 このように、システムとドキュメントの乖離をゼロにするというアプローチを取るDocumentation as Codeを、本セッションでは便宜上、本来のDocumentation as Codeと区別して「Documentation as Code+」と呼びます。 Documentation as Code+のアプローチは大きく分けて2つあります。1つめは、システムから構造化データを抽出し、その構造化データからドキュメントを生成するというもの。PHPDocやGodocといったソースコードからドキュメントを生成するアプローチがこれに相当します。 2つめは、構造化データからシステムとドキュメントの両方を生成するアプローチです。これは、OpenAPIやProtocol Buffersのprotocなどがそれに相当します。 ドキュメントの活用範囲を広げる「Documentation as Code++」 tblsは、構造化データ（データベース）を抽出してドキュメントを生成するアプローチ、つまりDocumentation as Code+の視点で作成されていると小山は説明します。 tblsでは、データベースとドキュメントのタイムラグをできるだけなくすために、CIで継続的にドキュメントを生成すること=継続的ドキュメンテーションが推奨されています。tblsはワンバイナリで簡単にインストールでき、CIフレンドリであることが特徴です。 （参考） 「CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける」 https://speakerdeck.com/k1low/phpconfuk-rej （参考） 「Continuous Documentation - CI/CDパイプラインを活用した文書化技術」 https://speakerdeck.com/k1low/pepabo-tech-conference-number-16 ただ、運用していくなかでは、Documentation as Code+にも課題があることがわかってきたとする小山。「tblsによって正しいデータベースドキュメントであるという安心感は得られたが、システムの開発ライフサイクルにおいて役に立つタイミングが少なく、作成して満足している状態になってしまっている」と説明し、その理由と対策の方針について次のように考察しました。 「データベースのドキュメントの情報だけでは足りないのかもしれないと考えた。データベースから抽出した情報以外の情報もあったほうがよい。また、ドキュメントの形式がマッチしていない可能性もある。正しいデータベースドキュメントは正しいデータであるため、データ活用の接点を増やしたほうがよいのではと考えた」（小山） このようにドキュメントの活用範囲を広げる方針を、便宜上「Documentation as Code++」とします。 ドキュメントにアノテーションを付与する Documentation as Code++のアプローチとして、まず、情報が足りなければ足していくという考え方について具体的に考えてみます。 小山は、ソフトウェアアーキテクチャの世界にあるビューやビューポイントといった考え方をもとに、ある1つのアーキテクチャをさまざまな切り口で表現することで全体を理解すればよいという考え方を紹介します。 「関心事にあわせてアーキテクチャを1つ以上の側面で表現するという考え方は、設計だけでなくドキュメンテーションにも当てはめることができる。ビューやビューポイントのスコープは、そもそもドキュメントにも入っており、関心事にあわせて必要なシステムの要素だけをまとめてビューとしてドキュメント化してみてはどうかと考えた。実際に、システムアーキテクチャをドキュメントするためのツールを作成するなどして効果を実感している」(小山) （参考）「目的に沿ったDocumentation as Codeをいかにして実現していくか」 https://speakerdeck.com/k1low/phperkaigi-2021 tblsには、スキーマやテーブルのカラムにラベルを付与できるラベルという機能があります。ラベルはそのままドキュメントや構造化データにも反映されます。たとえば、GMOペパボでは、漏洩してはいけない情報に”sensitive”というラベルを付与し、マスクしたり権限を限定したりといった用途で活用しています。 また、最近では、関心事にあわせてテーブルやラベルを絞り込み、その関心事を説明するためのドキュメントを別途作成するviewpointという機能もtblsに追加されました。.tbls.ymlファイルにviewpoointを追記して利用します。小山によると、さらにグルーピングなどによってよりわかりやすくするような機能も作成しているといいます。 中間的な構造化データを活用する ドキュメントの形式がデータベースにマッチしていないかもしれないという課題に対しては、ドキュメント以外のアプローチを考えていきます。 tblsでは、v1.57.0からtbls docでschema.jsonがデフォルトで出力されるようになっています。schema.jsonは、データベーススキーマと.tbls.ymlを利用してドキュメントを生成するために内部で構築される構造化データです。このアプローチについて小山は「デフォルトでschema.jsonが出力されていれば、それがある前提でさまざまな実装ができるという考えが根底にある」としたうえで、詳細について次のように説明します。 「tblsの内部では、MySQLなどのデータベースの情報をそのまま中間データとしてschema.jsonに落としており、実はschema.jsonはデータソースとして使えるような形になっている。つまり、schema.jsonさえ保存しておけば、実データベースに保存していなくてもドキュメントを再生産することが可能となる。この仕組みを活用したのが、tbls ls。データベースのテーブル一覧やカラム一覧を出力するコマンドで、ドキュメントを見に行かなくても、schema.jsonから内容を見ることができるというもの」（小山） LLMの活用可能性 小山は、ドキュメントの適用範囲をさらに広げるためにLLM（大規模言語モデル）を使用している事例についても言及しました。 tblsでは、データベースドキュメントが正しいことがわかっており、コメントやビューポイントなどコンテキストを理解するための情報も多く持っています。この特徴に対しLLMの強みを利用すれば、コメント付きの正しいデータベーススキーマと質問をLLMに与えることで、データベーススキーマとコンテキストに沿ったSQLクエリを生成するといったことが可能となります。小山によると、実験的実装としてtbls askというサブコマンドを作成したといいます。tbls askは、schema.jsonから正しいコンテキストを持ったデータベーススキーマを作成し、内部的にプロンプトに仕様するコマンドです。このようにLLMによって正しいドキュメントを使った推測というアプローチが取れるようになります。 また、小山は、逆のアプローチとして、テーブルのレコードのサンプルを与え、LLMにテーブルとカラムの説明を推測させるということも可能であると紹介しました。 おわりに 小山によると、tblsは、Documentation as Codeについて考えながら継続的に開発してきたツールであるといいます。これを踏まえ、次のようにコメントして講演を締めくくりました。 「Documentation as Codeの原点は、ドキュメントとコードを同じように運用していくという考え方。そして現時点においてDocumentation as Codeは、『正しいドキュメントは正しいデータであり、ドキュメントの範疇を超え良質な入力になる』ものだと私は考えている。ぜひこのアプローチでドキュメントをよりよくしていただければ」（小山） アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=b3TePTDCNgg

GMOインターネットグループは、2023年6月26日（月）～28日（水）に幕張メッセで開催された、日本国内最大のドローン・eVTOL（空飛ぶクルマ）展示会「Japan Drone 2023」にプラチナスポンサーとして協賛しました。国際コンファレンスでは「ドローン・空飛ぶクルマ、国内外の制度整備・技術開発から考える空の安全」と題したパネルディスカッションを開催しました。国内外の制度整備の状況、必要な制度や技術など、幅広い観点でディスカッションが行われました。その模様をお届けします。 登壇者 経済産業省​　製造産業局　航空機武器宇宙産業課　次世代空モビリティ政策室　企画調整官山本 健一　氏国土交通省​　航空局　無人航空機安全課保坂 達也　氏株式会社SClabAir​　代表取締役各務 博之　氏GMOグローバルサイン株式会社　CTO室　室長浅野 昌和GMOサイバーセキュリティ by イエラエ株式会社　代表取締役牧田​ 誠 ドローンと空飛ぶクルマを巡る制度整備の現状 まずは最初に、ドローン・空飛ぶクルマの制度整備の状況について、国土交通省の保坂氏が説明をします。 ドローンに関しては小型無人機に係る環境整備に向けた官民協議会の下にワーキンググループなどを設置して検討が進められています。そこで「空の産業革命に向けたロードマップ2022」と呼ばれる工程表がまとめられ、制度整備としては「有人地帯での補助者なしの目視外飛行、いわゆるレベル4と呼ばれる飛行の実現に向けての制度整備を行ってきました」と言います。 具体的には、機体認証、操縦ライセンス、機体の登録といった制度を整えられてきました。2022年12月5日には、レベル4飛行が可能となる改正航空法も施行されています。 図 1　空の産業革命に向けたロードマップ2022。様々な制度整備、技術開発などの工程表がまとめられています さらに2023年および2024年度以降の制度整備としては、ドローンの運航管理システム（UTM）の検討が重要になってくると保坂氏は指摘。段階的な制度整備で導入していくために検討を進めているそうです。 図 2　UTMは段階的に導入し、ドローンなどが増えて混雑度が上がれば必須になる見込み 現状は空域の混雑度が低い、密度が薄い状態なのでUTMの利用は「推奨」という段階ですが、ステップ2、ステップ3と混雑度が増していく中でUTMの重要性は増していきます。そこで国土交通省が認定したUTMを利用することで、高密度の運航にも耐えられるようになる、と保坂氏は話します。 そもそもレベル4の飛行はリスクが高く、そのためには安全に機体を飛ばして十分な技量を持った人の操縦が必要です。それに加え、重要なのが機体認証制度です。保坂氏は、機体の安全性について、「航空の世界では3つの観点がある」と説明します。 （1）設計段階の安全性（2）製造過程の安全性（3）現状の確認 設計レベルで安全でも飛行させる時点で安全でなければならず、逆に、現状（飛行時点）で、しっかりとしたものが出来上がっていても、設計段階できちんと安全性が確保されていなければならない、という考え方です。 図 3　機体認証制度。図の左側で型式、右側で機体認証に関して説明されています こうした制度整備を踏まえて、今年3月24日にはレベル4の初飛行が行われています。ACSLの第一種認証を受けた機体を使用して、一等の操縦ライセンスを保有する操縦士が操縦し、日本郵便の荷物を配送しました。飛行時間は約9分、距離にして約4.5kmでした。 図 4　レベル4の初飛行は日本郵便が飛行の許可・承認を取得して実施された 現状の課題認識として保坂氏は、「運航規模の拡大が重要になってくる」と指摘。それを実現するUTMも、海外でもどういったシステム、仕組みを構築していけばいいのかも決まっていないそうです。↩欧州とアメリカと行った国や地域でも違いがあるため、日本でどのようなUTMを作るか、民間の意向も取り入れつつ検討していく必要があると保坂氏は話します。 もう一つのテーマである「空飛ぶクルマ」に関しては、2025年の大阪・関西万博に向けて注目が高まっており、国土交通省でもロードマップを作成して検討を進めていると言います。 ドローンと同様に、ロードマップを作成して、道筋を示しながら進められており、大阪万博で飛行を実現させた上で、以降は運航を拡大していきたい考えだとしています。 図 5　空の移動革命に向けたロードマップで、空飛ぶクルマなどの新しい空の移動手段について検討されている 空の移動革命に向けた官民協議会が制度整備や技術開発に関して取りまとめたロードマップがあり、「特に機体の安全基準、技能証明（ライセンス）、運航、事業制度、離着陸場などについて、個別の専門的な検討を進めています」とのこと。 制度整備については、2022年度までに制度整備の方向性が示されています。2023年度はそれを踏まえた具体的な制度改正を行っていく計画で、「順調に進めば、2024年度には事業者の準備が行える」と言います。ターゲットは2025年の大阪万博で、そこで運航が開始できるよう進めていきたい考えです。 技術開発やセキュリティ対策の進捗 技術面に関する現状はどういった状況でしょうか。こうした問いに回答したのは経済産業省の山本氏。経済産業省はロボットやドローンなどの技術開発に関して民間との取り組みを継続しています。 2016年から始まった「ロボット・ドローンが活躍する省エネルギー社会の実現プロジェクト（DRESS）では、4つのテーマで技術開発の推進が行われてきました。 図 6　DRESSにおける4つのプロジェクト。特に安全安心に関わるドローンのセキュリティガイドラインの策定も重要 ここでは例えば機体の性能を統一的に評価できる手法やセキュリティ対策の開発を行っており、特にセキュリティ対策は「見えない部分ですが、ドローンを支える安全安心にはセキュリティも大事なので、ガイドラインも定めました」と山本氏。 運航管理は、ドローンや空飛ぶクルマだけでなく、ヘリコプターや航空機なども空域には存在するようになるため、今後人力で管理するのは難しくなり、自動化、自律化を支える技術が必要になります。「将来的に、ドローンや空飛ぶクルマが飛び回ることを見据えて開発しています」（山本氏）。 こうした取り組みにおける成果もあります。政府機関における警護や監視、インフラ点検でドローンのニーズが拡大したときに、情報漏えいやハッキングなどの攻撃への対応が必要で、さらに災害現場でのドローンの情報をセキュアに届けることも必要になります。 その観点から2019年に16.1億円の予算で開発された成果の1つがACSLのドローン「蒼天」です（21年12月発売）。セキュリティを確保したドローンとして、ISO/IEC 15408のセキュリティ評価基準に準拠しており、海外での販売時もISO取得をアピールできるようにしていました。 図 7　セキュリティ面も重視して開発されたドローン「蒼天」 他の成果としては「性能評価基準」や「無人航空機 サイバーセキュリティガイドライン Ver1.0」も策定されています。 図 8　性能評価基準は、どういった性能でどう証明するかといったスペックの策定に関する研究開発が行われています 図 9　サイバーセキュリティガイドラインはドローン、地上のコントローラー、クラウドなど、幅広い観点でのセキュリティのガイドラインになっています セキュリティガイドラインでは、セキュリティレベルに応じて運用時だけでなく、ドローンの製造時、ドローンの廃棄時も含めて、情報漏えいなどにどこまで配慮すべきか、といった観点でも対策がまとめられています。 運航管理システムの開発では、ドローン向けに2017年から研究開発に取りかかり、2020～21年度には全国13地域での実証実験も行われました。これをさらに進化させるために、2022年度からスタートした「次世代空モビリティの社会実装に向けた実現プロジェクト」（ReAMo）において、ドローンに加えて空飛ぶクルマを含めた運航管理技術の開発に向けた取り組みが行われています。 図 10　DRESSで開発が行われていた運航管理システム このReAMoでは、ドローンや空飛ぶクルマの安全性能を評価する手法の開発や操縦者1人が多数のドローンを操縦するシステムの技術開発なども行われる予定です。 図 11　5カ年計画で実施されるReAMo 海外でも議論の真っ最中 続いて海外の動向について説明したのがSClabAir​の各務氏。各務氏によれば、海外でもドローンや空飛ぶクルマを含めた次世代空モビリティに対する技術的なディスカッションが行われています。 図 12　欧米でドローンなどの安全基準などの標準化を進めている団体は数多い 各務氏は、こうしたグローバルな標準化の取り組みに参加していく必要があると指摘しています。 例えば各務氏が参加しているSAE Internationalの「G-34」。これは航空機へのAIの搭載において、どう安全性を担保するかを議論しているそうです。同じく各務氏が参加するRTCAのSC-240は、空モビリティにソフトウェアの基準をどのように適用するか、安全にソフトウェアを開発するためにはどうしたらいいかといった議論をしているといいます。 各務氏は、「AIは民間航空機よりもドローンや次世代空モビリティに搭載される方が早い」という見込みで、ドローンや空飛ぶクルマにおける先進的な取り組みの必要性があるという認識を示します。 そのAIを扱うG-34ですが、「どちらかというとAIはヨーロッパの方が進んでいる」と各務氏。すでにEASAのコンセプトペーパーと連携して議論が進められているそうです。 図 13　G-34では、W-shapedプロセスを使って安全性を担保する仕組みが検討されているそうです SC-240では、民間航空機にソフトウェアを搭載する際に従わなければならないガイドラインとして「DO-178C」がありますが、民間航空機ほどの厳密さが必要かどうかという議論もあり、グレードを下げたガイドラインの議論が進んでいるといいます。 特に機体のセキュリティに関しては、RTCA DO-326A、DO-356Aというガイドラインがすでにあり、これをドローンや次世代空モビリティについても適用することが良いのではないかと議論されているそうです。 そうした議論を踏まえて各務氏は、「セキュリティアセスメントのプロセスとセキュリティ対策の両輪でやっていく必要がある」と説明します。 GMOインターネットグループのセキュリティに期待することは？ パネルディスカッションにはGMOサイバーセキュリティ by イエラエの牧田とGMOグローバルサインの浅野も参加しており、例えばイエラエではペネトレーションテストを提供し、攻撃者の立場からその技術が安全かを可視化するようなサービスを提供。 GMOグローバルサインは暗号セキュリティや認証サービスを提供しています。「ドローンや空飛ぶクルマはインターネットに繋がるデバイスが空を飛んでいるイメージ」（浅野）であり、そういったデバイスに対しては認証や暗号化が必要になってくるという考えだということです。 こうしたセキュリティを担うGMOインターネットグループの2社に対して、ドローンや空飛ぶクルマの制度整備や技術開発に携わる登壇者の面々から期待感が語られました。 経済産業省の山本氏は、「利便性とセキュリティのトレードオフは必ずついて回る」という認識を示しつつ、リスクをゼロにすることはできず、「リスクがゼロでなければならないならドローンを飛ばさない選択しかない」と指摘。 そこで、いかにリスクを低減させられるかという点が重要で、その点で山本氏は、 ドローンにおけるセキュリティ対策の重要性を強調し、政府、民間が一体となってセキュアで、安心安全な次世代空モビリティの実現に期待を寄せていました。 国土交通省の保坂氏は、現状の空飛ぶクルマでは操縦士の存在が前提となっていますが、将来的には自律的に飛ぶようになるという予測を示し、そうであればさらにセキュリティ対策が重要になってくるとの考え。その点で、民間の知見を取り入れながら国際的な議論作りに取り組んでいきたい考えを示していました。 SClabAir​の各務氏は、海外の議論でもソフトウェアの分野でセキュリティとの連携が大切だという話になっていると指摘。「新しいガイドラインにもセキュリティとソフトウェアのコラボレーションをちゃんと考えなきゃいけないという文言が入る話になっている」そうで、ソフトウェアにおけるセキュリティ対策の重要性が認識されているようです。

こんにちは。GMOインターネットグループ株式会社の新里です。GMOインターネットグループでエキスパート制度というのが今年できました。既にグループ各社からエキスパートが選出されています。第１期のメンバーとして選出されたので、その経緯でも記しておきます。 どういう制度か？ GMOインターネットグループが行っているエキスパート制度についてはHPに記載があります。エキスパート制度 | GMO Developersすでに選出されている皆さんの情報がアップされていますね。どういった役割なのか？などについては書いてある内容を見た方がよいですが、最初に記載している内容が全てかなーと思っています。 この制度は、GMOインターネットグループの技術広報活動など、グループ内における開発者コミュニティの活性化やインターネット業界の発展に貢献する開発者（デベロッパー）を「デベロッパーエキスパート」に任命し、その活動を支援するものです。エキスパートに任命された開発者には、活動費として最大で年間100万円が支給されます。 ざっくりだと、なんか色々やっているひとに活動資金を援助してくれるようです。何がエキスパートなのか？という定義や資金の上限はどこまでか？といった点は置いといて、そういう支援をしてくれるというのは良い取り組みだとは思っていました。 選出フロー エキスパートに選出されるフローは次のような流れになっていました。どうやら立候補すればなれるみたいです。 ■エキスパートの選出方法「デベロッパーエキスパート」は、年に1回の一般公募でメンバーを募り選出します。立候補制で、グループ各社CTOが集まる技術責任者会議での審査・承認を経て、1年間「デベロッパーエキスパート」として活動していただきます。人数は特に指定しておりません。初回の取り組みとして、今回は開発者8名を第0期生メンバーとして選出しました。 ただ、ここには記載が無いですが、立候補時にグループ各社の技術責任者からの推薦が必要とのことでした。 実際の流れ そういう制度があるのね～とは思っていましたが、０期メンバーの選出は既にされていました。そして、第１期生は記載されている選出方法のフローで選ばれるようでした。そして「出してみない？」とお声がけを頂きノリで出してみようかと。実際の流れは次のようになっていました。 ・「出してみない」とお声がけを頂く。・社内の応募フォームを書いてエントリー・経歴・自己アピールみたいなものを書いて同時に提出・技術責任者会議でのプレゼン・合否の連絡 このような流れで応募からプレゼンまで1－2か月といった感じでした。 ちなみに... 今まで外部での展示や制作・海外への渡航費などは会社からの特別な補助は一切ありません。当然ですが全て自費・IPA未踏のサポート・SIProp・OSSのことで、会社の業務とは一切関わりはありません。今後もこのスタンスは変わらないでしょう。記事を書いた執筆料は全て自分の制作や渡航費につぎ込んでいたりして、完全に独立した活動です。自分が好きなモノ・興味のあるモノやコトに何か制限がついたり、好きに出来ないと意味が無いと思っているので、今後もこのスタンスは変わらないでしょう。 専門性とは？ 特定分野に対する専門性とは一体なにか？という定義は難しいですね。僕の場合、得意分野は「IT技術領域全般・プログラマー」とざっくりしたことにしています。 というのも...例えば、僕自身は学術論文は全く書いていません。メンテをしているIoT向けの通信系ライブラリなどは色々な論文でリファレンス＆使われていたり、海外IoTベンチャーのMVP(IoT Expert)になっていたりもしていますが、これが自分の専門だとは自分自身、全く思っていないです。ただ、Ethernet/IPv4,v6/TCP,UDP/ICMP v4,v6/BIND...etc など、いわゆるL2〜L7までスクラッチで一通り書いて実サービスで使ったりしたのもあって、ネットワークは僕のベースになっていたりします。 他にも例えばAndroid物のアプリだと... (エキスパートのプレゼン時の資料から抜粋) 完全にノリで作ったアプリが100万ダウンロードを達成したりもしました。これは個人で広告・プロモーションを一切無しで100万ダウンロードできるか？というのを実現したかったのと、画像処理が楽しかったのもあって、ノリで作ってみたものでした。ただし、これでAndroidアプリが専門か？というと全くそうでも無いです。 (エキスパートのプレゼン時の資料から抜粋) 必ずしも当たるものだけではなく、全く当たらなかったiPhone物アプリとかもあったり。こちらはApple本社・クパチーノに作った物を送って認証を取ったという経験を得ることは出来ましたが、もちろんiPhoneアプリの専門ではないですね。 他にも未踏でのゲート型量子コンピュータ、モノを作るのが好きなのもあってMaker系イベントでの展示や書いてきた様々な内容はありますが、個人での活動の範囲内でやってきたことですね。 (Maker Faire Tokyo での展示の様子) 色々なことをやってきましたが「おまえは何が専門なんだ？」となると、コンピュータ全般・プログラマかなと思っていたりしています。モノに限らず多くのことがプログラマブルになってきていて、プログラムを組むことで作れるものが数多くあります。また業務でもゼロからイチを作るような企画・開発が多いのもあって、「プログラムでなにかを作る」というのがしっくりきます。ただし、既存の言葉で「何が専門か？」となると適切な言葉が見当たらないのが、面倒だな...と感じています。 エキスパートなるもの？ 自分自身のことを偉そうに何かのエキスパートだとかとは思っていないです。日々学びと新しい経験値を得て何かしらの成長が出来ていけたら...みたいな感じですね。プログラムを書かなくなったら開発者・エンジニアとしては終わりと思っていたりもするので、ネット系・サービス・実際のモノや作品に限らず、ちゃんとモノを作っていけるよう日々精進ですね。 https://developers.gmo.jp/developerexperts/

こんにちは、GMOインターネットグループ株式会社の長谷川です。今回は KVM 単体でのライブマイグレーションに関して語っていこうと思います。 KVM でのライブマイグレーションに挑むモチベーション 古い筐体に乗っている KVM の VM を停止せず出来るだけ少ない通信断で新しい筐体に移行したいOpenStack を導入するほどではないが VM をライブマイグレーションできるようにしておきたい 検証用環境 # virsh version Compiled against library: libvirt 4.5.0 Using library: libvirt 4.5.0 Using API: QEMU 4.5.0 Running hypervisor: QEMU 2.12.0 【STEP1】検証用 VM を作成（マイグレーション元） QEMU のバージョンがかなり低い場合には場合によりライブマイグレーション出来ないので事前にテスト VM で検証をしましょう。VLAN 等や IF の設定はマイグレーション先と元は同じ設定に揃えてください 今回はテスト VM を元に KVM でのライブマイグレーションの手順をご紹介します。KVM による VM 作成に関しては今回の主旨から外れるので割愛します。 # virsh list --all |grep tmp 27 tmp-test-mg-hase 【STEP2】ディレクトリ作成（マイグレーション先） ここではマイグレーション先に保存されるイメージファイルの格納先ディレクトリを作成します。 # mkdir /var/lib/kvm/tmp-test-mg-hase マイグレーション先のディレクトリ構造はマイグレーション元のイメージファイルがある場所と同じに揃えてください。 【STEP3】qcow2 のイメージファイル事前作成（マイグレーション先） これを行わない場合にはライブマイグレーションした VM のイメージファイル実容量が拡張限界まで膨れ上がる可能性があります。（イメージファイルの実容量が 50GB なのにマイグレーション後に 500GB の拡張限界まで肥大してしまい転送しきれない等） 決められた容量でイメージファイルを作成し上記の事故防止の対策をします。 # qemu-img create -f qcow2 /var/lib/kvm/tmp-test-mg-hase.img 50G 【STEP4】ストレージプール設定（マイグレーション先） KVM のストレージプールを定義します。 # virsh pool-define-as --name default --type dir --target /var/lib/kvm/tmp-test-mg-hase 定義したストレージプールをスタートさせます。 # virsh pool-start default プールがスタートされているか確認します # virsh pool-list --all Name State Autostart ------------------------------------------- default active no 【STEP5】疎通確認（マイグレーション元から先） ライブマイグレーションするにあたり、FQDN での疎通の確認が必要となります。名前解決できない場合は hosts や DNS 登録をして名前解決出来るようにしましょう。 また、マイグレーション先には SSH 出来るか事前に確認が必要です。 # ping -c 5 [FQDN] ..... 64 bytes from 172.21.20.20 (172.21.20.20): icmp_seq=1 ttl=64 time=0.171 ms ..... --- hogehoge.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4091ms rtt min/avg/max/mdev = 0.087/0.122/0.171/0.028 ms 【STEP6】ライブマイグレーション（マイグレーション元） ここまで来るとライブマイグレーションが出来るようになります。以下コマンドでマイグレーションを行います。 # virsh migrate --live --copy-storage-all tmp-test-mg-hase qemu+ssh://[マイグレーション先のFQDN]/system --verbose --compressed --abort-on-error --persistent virsh コマンドでのマイグレーションは様々なオプションがあるので、それぞれの環境に合わせて調整してください。今回は転送時の圧縮とエラーが起きた際には中止、転送先環境で VM を永続化させるをオプションを付けています。 基本的には --live --copy-storage-all --persistent 上記のオプションがついて入れば最低限ライブマイグレーションを行うことが出来ます。 # virsh migrate --help NAME migrate - migrate domain to another host SYNOPSIS migrate <domain> <desturi> [--live] [--offline] [--p2p] [--direct] [--tunnelled] [--persistent] [--undefinesource] [--suspend] [--copy-storage-all] [--copy-storage-inc] [--change-protection] [--unsafe] [--verbose] [--compressed] [--auto-converge] [--rdma-pin-all] [--abort-on-error] [--postcopy] [--postcopy-after-precopy] [--migrateuri <string>] [--graphicsuri <string>] [--listen-address <string>] [--dname <string>] [--timeout <number>] [--timeout-suspend] [--timeout-postcopy] [--xml <string>] [--migrate-disks <string>] [--disks-port <number>] [--comp-methods <string>] [--comp-mt-level <number>] [--comp-mt-threads <number>] [--comp-mt-dthreads <number>] [--comp-xbzrle-cache <number>] [--auto-converge-initial <number>] [--auto-converge-increment <number>] [--persistent-xml <string>] [--tls] DESCRIPTION Migrate domain to another host. Add --live for live migration. OPTIONS [--domain] <string> domain name, id or uuid [--desturi] <string> connection URI of the destination host as seen from the client(normal migration) or source(p2p migration) --live live migration --offline offline migration --p2p peer-2-peer migration --direct direct migration --tunnelled tunnelled migration --persistent persist VM on destination --undefinesource undefine VM on source --suspend do not restart the domain on the destination host --copy-storage-all migration with non-shared storage with full disk copy --copy-storage-inc migration with non-shared storage with incremental copy (same base image shared between source and destination) --change-protection prevent any configuration changes to domain until migration ends --unsafe force migration even if it may be unsafe --verbose display the progress of migration --compressed compress repeated pages during live migration --auto-converge force convergence during live migration --rdma-pin-all pin all memory before starting RDMA live migration --abort-on-error abort on soft errors during migration --postcopy enable post-copy migration; switch to it using migrate-postcopy command --postcopy-after-precopy automatically switch to post-copy migration after one pass of pre-copy --migrateuri <string> migration URI, usually can be omitted --graphicsuri <string> graphics URI to be used for seamless graphics migration --listen-address <string> listen address that destination should bind to for incoming migration --dname <string> rename to new name during migration (if supported) --timeout <number> run action specified by --timeout-* option (suspend by default) if live migration exceeds timeout (in seconds) --timeout-suspend suspend the guest after timeout --timeout-postcopy switch to post-copy after timeout --xml <string> filename containing updated XML for the target --migrate-disks <string> comma separated list of disks to be migrated --disks-port <number> port to use by target server for incoming disks migration --comp-methods <string> comma separated list of compression methods to be used --comp-mt-level <number> compress level for multithread compression --comp-mt-threads <number> number of compression threads for multithread compression --comp-mt-dthreads <number> number of decompression threads for multithread compression --comp-xbzrle-cache <number> page cache size for xbzrle compression --auto-converge-initial <number> initial CPU throttling rate for auto-convergence --auto-converge-increment <number> CPU throttling rate increment for auto-convergence --persistent-xml <string> filename containing updated persistent XML for the target --tls use TLS for migration 【STEP7】動作のチェック（マイグレーション先） 実際に VM 内に入って確認し、必要があれば筐体の再起動等をして問題がないか確認します。また、事前に対策したイメージファイルが膨張問題が起きていないか確認します。必要に応じて XML やイメージファイルのバックアップも取得しておきましょう。 # ls -lah /var/lib/kvm/tmp-test-mg-hase # virsh list --all # virsh console [INSTANCE_NAME] 【STEP8】マイグレーション後のお掃除（マイグレーション先） マイグレーション後の VM 正常動作確認後には不要になるストレージプール定義を削除します。まずストレージプールを止め、それから undefine していきます。最後にストレージプール停止後も正常に VM が稼働しているかを確認します。 # virsh pool-stop default # virsh pool-undefine default # virsh list --all まとめ 長い道のりお疲れ様でした。出来るだけ無停止で KVM による VM ライブマイグレーションを行う手順を説明しましたがオンプレで VM 管理しなくても ConoHa VPS であれば、上記のような手順は必要なくVM の管理はおまかせ出来るので安心です是非ご活用ください。