技術情報 の記事一覧

PHPerKaigi 2021にGMOインターネットグループはダイヤモンドスポンサーとして協賛いたしました。本エントリーでは、登壇の概要やセッション動画撮影の裏側をレポートいたします。 イベント概要 PHPerKaigiとは PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 概要 日　程：2021年3月26日(金)～28(日)会　場：ニコニコ生放送対　象：PHPエンジニアおよびWeb技術のエンジニア主　催： PHPerKaigi 2021 実行委員会 （実行委員長 長谷川智希（@tomzoh）公式HP：https://phperkaigi.jp/2021/ 登壇セッション 今年はGMOインターネットグループからは、GMOインターネット、GMOメディア、GMOペパボの3社から計4名が登壇いたしました。登壇詳細につきましては、以下記事にて掲載しておりますので、是非ご覧ください。 https://developers.gmo.jp/3137/ GMOメディア株式会社　＠yoku0825 GMOインターネット株式会社　成瀬　允宣 ニコニコ生放送にて放映されました。ニコ生おなじみのコメントが映像の上にどんどんと流れていました！オンライン上でも一体感があり、イベント参加者全員で話題を共有しているという感覚を強く感じることができました。 PHPerKaigiセッションについては、1か月限定でニコニコプレミアム会員の方はご視聴いただけます。※チケット購入者限定GMOインターネットグループのスポンサーセッションは以下からもフルバージョンでご覧いただけます。当日ご覧になった方はもう1度！まだ見ていない方も是非ご確認ください。 スポンサーセッション：なるせ先生のPHP学～PHP8新機能スペシャル～ ノベルティBOX 今年はオンライン開催ということでしたが、主催から事前登録者にノベルティボックスなるものがご自宅までお届けされ、イベント前からSNSもとても盛り上がていましたね！！！ ノベルティボックスの中身 マスクや温泉のもと、エコバックなど豪華なラインナップでとても嬉しかったです。当社からは【辛口】カレーをお送りさせていただきました！ パッケージに関しても多くのコメントをいただきありがとうございました！スポンサーセッションに登壇したGMOインターネット成瀬(@nrslib)をモチーフに当社デザイナーがイベントオリジナルで制作いたしました。 みなさまのイベント中のお供になったのであれば幸いです。 スポンサーセッション視聴者企画＼ みんなの ／#PHP学 今回はオンラインイベントということで、直接お会いすることはかないませんでしたが、GMOインターネットグループのセッションを視聴いただいた方に感謝をお伝えしたいということで、持ち込みの独自企画も実施いたしました！ 企画詳細はこちら 投稿いただいた方の中から、抽選で10名様にイベント限定グッズをプレゼントいたしました！セッションを視聴くださったみなさま、みんなの #PHP学 にご参加いただいたみなさま、ありがとうございました。 PHPerKaigi初だし新CM PHPerKaigi 2021の幕間にて、新CMをお披露目させていただきました。スポンサーセッション企画のオリジナルCM『なるせ先生のPHP学～1人4役なるせ先生編～』です。 https://youtu.be/lmg_ZstiV74 みなさんから耳に残る・・・とコメントをいただいた、『フレームワークは敵じゃない、味方なんだ』をはじめとする決め台詞は、成瀬オリジナルです。 講師の特徴や個性に合わせて衣装やヘアだけでなく、背景の黒板の文字や色づかい、消し方にまでこだわって撮影を進めました。 撮影風景 メイン講師なるせ先生役準備中 カジュアル講師にビジュアルチェンジ中 講師によって異なる背景の黒板にもご注目ください 今回はスポンサーセッションの告知も兼ねて制作したので、番宣ありなしの2ver.あります！なるせが1人何役の講師に扮しているのか、確認してみてくださいね。 https://twitter.com/GMOdev/status/1375370161750872067 さいごに 最後までお読みいただきありがとうございました。また来年のPHPerKaigiでお会いできることをたのしみにしております！

今回の記事では、自組織向けのサービス提供を想定し、一般的な4G回線とVPSの組み合わせと、ローカル5G環境とローカルサーバーの組み合わせを比較しています。詳しくは下記内容をご確認ください。 はじめに こんにちは、GMOインターネットの梅崎です。今回は GMO Developers Night#21 ローカル5G基礎 〜ローカル5Gの技術担当がスピーカー登壇〜 にて行ったデモのご紹介をしていきたいと思います。 本エントリーの概要 自組織用にモバイル回線を使ってサービスを提供する場合を想定して、「一般的な4G回線とVPSの組み合わせ」「ローカル5G環境とローカルサーバーの組み合わせ」を比較し、ざっくりとどういった差があるのかをまとめたものです。 構成 以下に検証を行った際の各回線のDEMO用の構成図を紹介いたします。 ローカル5G＋ローカルサーバー ローカル5G環境のコアに直結したサーバーにコンテンツを載せ、クライアントPCはUE(CPE、置くだけWi-Fiのようなもの)に有線で接続しました。 4Gデザリング＋VPS 4G環境はVPSへコンテンツを載せ、クライアントPCはテザリング→Wifiで接続しました。 ローカル5G・4Gの比較 上記構成で各回線の速度を比較していきます。 帯域と遅延の測定 ローカル5G側 帯域については約500Mbpsと100MHz幅での設備側の上限近く出ており、遅延についても4msと規格内に収まる値となりました。限界は実測で497Mbpsほどでした。 トラフィック負荷試験、iperfにて測定 ローカルサーバーに載せたツールにて測定 遅延はおおよそ4ms以下でした。 pingコマンドにて測定 4G側 帯域については約100Mbpsと私の想像よりは早かったのですが、遅延については60ms弱と5Gに比べ最大12倍ほど遅いという結果になりました。 VPS側の帯域に上限があったため、Googleさんが提供しているツールにて測定 遅延も30ｍs~64msと比較的長いことが確認できます。 pingコマンドにて測定 所感 ローカル5G側 速度については4Gの実測値の約5倍とかなり高速となっていました。また、今後利用可能な電波帯が広がるにつれ、更に速くなっていく余地を残している点も期待できます。遅延についても現時点でPPPoEでの有線接続より速くなっています。(PPPoEは簡単にネットで調べたぐらいですが、10～20msほどのようでした)また、プロファイルを調整すれば遅延はさらに4分の1以下に短縮でき、端末側で実施していたことをサーバー側にオフロードするなど、様々なサービスが発展していくのはと感じました。 4G側 速度については思いの外速いなというのが正直な感想でしたが、遅延は大きくっローカル5Gとは10倍以上の差となってしまっていました。4G側も他の一般利用者と共用となっていることなど不利な点はあり、純粋な規格自体の比較にはならない状態ではありますが、ある意味、"ローカル"5Gの自組織以外の影響を受けづらいという、旨味が見えたのではと思います。 動画ダウンロードを試す ローカル5G側 https://www.youtube.com/watch?v=Eb0q4Iz4t8U&list=PL-nSubl7UrR54IRbUcW5leXPWavjTSPzY 4G側 https://www.youtube.com/watch?v=uM3EruVOK_A&list=PL-nSubl7UrR54IRbUcW5leXPWavjTSPzY 所感 かなり重めにした動画を使ったのですが、4Gはガクガクでまともに再生できない状態にもかかわらず、ローカル5Gでは再生時間よりも目に見えて速く読み込みが完了している状態でした。さらにいい点として、ローカル5Gの方はそもそも外と通信が発生しないので、通信量の削減など効率的にネットワーク資源を利用できると思います。 4Gだと30Mbps以下で動画時間の3倍以上の時間で落とし終わるのに対して、5Gだと250Mbps以上で動画時間の半分以下で落とし終わりました。 ※ちなみに、YouTube推奨だと4k, 60fpsで約50Mbps以上だそうなので100Mbpsの動画でも30Mbps出せていない、4G回線では4k動画は視聴は難しそうですね。 動画MTGを試す ローカル5G側 https://www.youtube.com/watch?v=PqUt6xifmZc&list=PL-nSubl7UrR54IRbUcW5leXPWavjTSPzY 4G側 https://www.youtube.com/watch?v=vTmo7lKYPSw&list=PL-nSubl7UrR54IRbUcW5leXPWavjTSPzY 所感 個人的には予想外なぐらいに差が出てしまっていました。特に↓のぐーぱーのところは下のカメラ(録画PCのもの)と左のカメラ(別のPC)で4Gと5Gで目に見えた差が出てしまっていました。 ローカル5側 4G側 下記画像のようにトラフィックについては大した量ではないため、カメラ映像の遅延の原因はおそらく帯域の問題というよりは通信遅延ではないかと思います。 3台のクライアントで上り8Mbps下り3Mbpsほど、帯域より通信の遅延が映像の遅れに影響していることがわかりました。 サーバーから見たトラフィック この状態でもローカル5Gの方が遅延は少なくなったとは言えるのですが、正直なところ、今回は一般的なWebカメラを利用していることもありローカル側のカメラ映像も200msほど遅延が発生しておりまして、ざっくりの単純計算でも1.3倍以下の差しか無い状態です。・4G : 200 + 60(udpならこの半分？) = 260ms・5G : 200 + 4(udpならこの半分？) = 204ms とは言うものの、逆に前処理が短いものですと、以下のように10倍以上の差の恩恵を受けられるようになっています。・4G : 60ms・5G : 4msその点はサービス側をカリカリにチューニングして行ける腕の見せどころかなと思います?。 まとめ ローカル5G(+ローカルサーバー)にすると ・帯域幅の増加と低遅延で高速化　(まだまだ、増速の余地あり)・自組織以外の通信の影響をうけない・外部接続の通信が減る　(ランニングコストの削減が見込める) 今後必要かなと思うところ ・低遅延のポテンシャルを活かすためには、ソフト/ハードウェアの工夫が必要 余談 あと、個人的には多数接続も試したいのですが、数が数千～数十万といったオーダーなのでどうやって試すか……?。

春ですね。今年もたくさんの新人エンジニアが誕生しました。本エントリーは新人エンジニアに向けた情報を共有していきます。これを読んで成長していってもらえたらと思います。 はじめに こんにちは。デベロッパーリレーションズチームの村上です。今年からエンジニアになった方たちは、大体1週間程経過しましたがそろそろ会社には慣れてきたでしょうか？そろそろ周りが見えてきて、先輩エンジニアたちが開発している姿に刺激を受ける毎日でしょう。ただ、今はバリバリ開発をこなす先輩エンジニアたちも、昔はあなたたちと同じ新人エンジニアだった時期があります。そんな先輩エンジニアたちのようにエンジニアとして一人前になるためには、たくさんの経験を積んでいく必要があります。また経験を積むと同時に、良い習慣を身に着けていくことがとても大切だと私は考えます。今回は私の経験から得た、エンジニアとして身につけておくべき習慣を3つお伝えしていきます。 新人エンジニアが身につけるべき3つの習慣 アサインされたプロジェクトの既存コードを読む 新人エンジニアの場合、プロジェクトにアサインされたらまずは簡単な改修から依頼されるはずです。とりあえず1箇所修正すれば終わり、というような依頼も多々あるんじゃないでしょうか。そんなときそこだけを改修して終わり、とするのではなくその修正した機能に関わる部分の既存コードをしっかりと読んでおきましょう。既存コードを読むことでプロジェクトのコーディングルールや採用しているアーキテクチャを確認することができます。そうすることで、先程自分の修正した箇所がルールやアーキテクチャに則って改修できているかわかるようになります。また修正箇所をテストするためにも理解しておくべきです。一度確認しておけば次の依頼が来たときにスムーズにこなせるようになります。 わからないところは調べる・質問する コードを書く際のテクニック まずはコードを書く上でのテクニックな部分はgoogleで検索してみましょう。検索したときにまず見るべきサイトは、公式ドキュメントです。公式ドキュメント以外はバージョン違いや間違った情報、古い情報が載っていたりすることがあるので、最初に見るべきではありません。公式ドキュメントを読む癖をつけ、正しい知識を身に着けましょう。また調べた情報に倣って改修したけど、エラーが出たりする場合もあります。そんなときは、まずエラーログを確認する癖をつけましょう。エラーログに全ての情報が載っています。トライアンドエラーでチャレンジした結果、解決できない問題については、素直に先輩エンジニアを頼りましょう。テクニカルなことも、エラーの原因も、きっとなんとかしてくれます。 ビジネスロジック ビジネスロジックとは、アプリケーションにおける事業のビジネスルールやフローが反映され、システムごとに固有性が高いものを指します。ですのでアサインされたばかりの新人エンジニアでは直ぐに理解することが難しいです。ビジネスロジックの仕様に関してわからないところは先輩エンジニアを頼りましょう。どんどん質問して、プロジェクトへの理解を深めていきましょう。 学んだことをアウトプットする 調べたテクニックな部分はブログにアウトプットしていきましょう。理由は前回の記事にも書きましたが、知識を定着させる上で非常に有効です。 https://developers.gmo.jp/4048/ ノートにメモを取ってるだけでは勿体ないです。ブログにアウトプットするのと合わせて有効なのが、実際にアプリケーションを組んでみることです。業務で得たテクニックを利用し、アプリケーションを組んでGitHubにアップしておくと、他のエンジニアからより良い方法を指摘してもらえるかもしれません。勿論業務のアプリケーションをそのままアップするのは絶対にやってはダメですよ。また、ビジネスロジックに関して学んだことは、他の新人エンジニアに先輩エンジニアから教わったように教えてみましょう。新人エンジニアが自分一人なら、チームの先輩エンジニア達に説明してみて理解したことがあっているか確認してもらいましょう。他の人に説明できてはじめて自分が理解できていることになります。 私の新人時代の失敗話 今やチームのマネージャーを務め様々なアプリケーションを作ってきた私にも、当たり前ですが新人時代がありました。アサインされたプロジェクトで、1か月ぐらい細かな修正ばかりの時期がありました。言われた改修箇所をぱっと修正して終わりという日々を繰り返していました。ある日、1機能まるごと作成する案件をもらったとき、今まで簡単に書いてたコードがまったく書けないことに気づきました。先輩にいきなり無理ですよ、と相談したところ1か月も時間があったのにコード見ていないのか、と怒られてしまいました。確かに割り振られていた修正は思い返すと、その1機能まるごと作成するのに必要な情報が揃っていました。先輩エンジニアというのはそういうところも配慮してくれて仕事を割り振ってくれてるんだなと実感しました。それから私は細かい修正でも、必ずその処理の前後の確認して理解するようにしています。ただそうするつもりだったら、事前に言っといてくれてもよかったのにと思ったのは内緒です。 まとめ 最初は思うようにコードを書いたり、わからないことを理解して質問をすることも難しいかもしれません。上記で記した3つの習慣を定着させることができれば、直ぐに立派なエンジニアになれます。今回書いたこと以外にも、身に着けると良い習慣はたくさんあります。業務内容や環境に合わせた”良い習慣”も模索し、身に着け、あなたのエンジニア力を上げていきましょう。

こんにちは、GMOインターネット株式会社の斉藤です。本エントリーでは、Goを書くときに便利な"err"という文字列をハイライトする方法について紹介します。 はじめに 僕は普段EmacsでGoを書いているのですが、最近他の言語を書くときはVisual Studio Code(以下VS Code)を利用することが増えてきています。Emacsは最近は老害などと言われがちではありますが、長く使っていてカスタマイズも完全に馴染んでいるのでなかなか乗り換えが難しいんですよね。 そんなEmacsでGoを書くときに私が便利に使っている設定が、"err"という文字列をハイライトするというものです。 go-modeでerrをハイライトしておくと捗る - Qiita もともとは下記のブログを参考にしたものです。"err"という文字列をHighlightしておくとGolangのコードリーディングが捗る Goは例外などの機構が存在せず、エラーはerrやerrをプレフィックスとした名前の変数で受けて処理するのが慣例となっています。そして、以下のようなコードブロックが頻繁に登場します。 if err != nil {return err} なのでerrをハイライトしておくとエラーの箇所が明確になりコードリーディングが便利になるんですね。私はこれを入れないとよくエラーを見落とすので、生産性に直結する大事な設定だったりします。 VS Codeのシンタックスハイライト この設定、残念ながらVS Codeでは設定できません。VS Code正規表現などを使ったコードハイライトをする仕組みを持たないからです。ただVS Codeは拡張機能を簡単に作れるので、それを利用して自前で作りました。 Go err highlighting - Visual Studio Marketplacehttps://marketplace.visualstudio.com/items?itemName=hiro.go-err-highlighting。 これを使うと上の画像のようになります。いかにも見やすそうでしょう。VS CodeでGoを書いている方はぜひ使ってみてください。 自分で拡張機能を作る さて以下はVS Codeのシンタックスハイライトをカスタマイズしたい人向けの情報です。 Language Extensions Overviewhttps://code.visualstudio.com/api/language-extensions/overview VS Codeのシンタックスハイライトは、実際にはLanguage Extensionと言う名前の拡張機能の一種として実現されています。これにはシンタックスハイライト以外にもインテリセンスによる補完、括弧の対応、コメントの扱いなどが含まれています。 このLanguage Extensionは予約語の管理もしていて、VS Codeがそれに応じて色を付けるようになっています。たとえばifやforなどですね。逆に言うと予約されていない語に色づけするのは無理です。今回の"err"はGoのLanguage Extensionでは予約されていないので、自前で拡張を作る必要があります。 今回は追加したいキーワードがerrでしたので、既存のGoのLanguage Extensionに設定をInjectionするアプローチを取ります。これはオフィシャルガイドにやり方が書いてあります。 Injection grammarshttps://code.visualstudio.com/api/language-extensions/syntax-highlight-guide#injection-grammars 実際の手順は、まずガイドにあるとおり拡張機能のスケルトンを作成します。 Your First Extension | Visual Studio Code Extension APIhttps://code.visualstudio.com/api/get-started/your-first-extension あとはInjection grammarsにあるとおりにハイライトしたい設定を書くだけです。Go err highlightingの場合は以下になります。 vscode-go-err-highlight/injection.json at main · hironobu-s/vscode-go-err-highlighthttps://github.com/hironobu-s/vscode-go-err-highlight/blob/main/syntaxes/injection.json おわりに ちょうどMTGが延期になったりタスクが延期になったりで業務時間の空きができ、これはブログネタにもなりそうだと言うことでエイヤで一気に作り上げてしまいました。 ともかく、これでGoを書くのにもVS Codeを使っていくことができます。EmacsはCUI環境でも使えるのでまだまだ捨てることありませんが、しばらくはVS Codeも併用で開発を進めていくことになりそうです。 それではまた次回お目にかかりましょう。

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第一回のテーマはレゴ®によるスクラムワークショップです。 この記事は約20分で読めます。 はじめに みなさんこんにちは。成瀬（@nrslib）です。 GMOインターネットにはデヴェロッパータスクフォース（以下DTF）というチームがあります。 DTFは端的に表現すると技術研究チームです。開発者が互いに切磋琢磨する仕組み・環境の整備・開発技術や開発手法のキャッチアップをして、そこで得た知見を他の開発者や製品・サービスにフィードバックするのが目的です。 DTFが手がける活動は多岐にわたります。世の中のトレンドや最新の技術のキャッチアップは当然のこととして、既知の技術でありながらノウハウのないものや、技術以外に開発手法なども対象範囲です。 今回、DTFではスクラムのワークショップをいくつか実施しました。本連載では、ワークショップで得られた知見や様子をお話いたします。 変化を余儀なくされた開発現場 ある日突然リモートに──。 もう一年以上も前のことですが、突如出社が禁止され、私たちはフルリモートで業務を行うことになりました。当初は戸惑いがありましたが、一年以上もリモートワークをしていると、もはや日常風景です。カレンダーがめくられるにつれて、ノウハウもどんどん溜まり、今となっては不都合を感じることはほとんどありません。しかしながら、そのリモートワークが最適化されたものかというと疑問が残ります。 この度リモートワークにスムーズに移行できた理由のひとつとして挙げられるのは、毎年の災害対策用リモートワーク訓練です。環境が整備され、パートナーに経験が蓄積されていたからこそ、私たちはリモートワークに移行できたのですが、その訓練はあくまでも災害対策用なのです。あくまでも短期的なリモートワークを想定したもので、長期的な運用を目指したものではありませんでした。そのため、すべてが効率的で効果的なやり方であるとも言い切れません。長期的なリモートワークを前提とした、もっと良いやり方があるに違いありません。 そこで、私たちはリモート環境下の開発における「私たちの」ベストプラクティスを探ることにしました。具体的にはリモート環境下におけるアジャイル開発の探求です。 もちろん、私たちがリモートに移行する以前よりフルリモートを実践している先達は多く、リモート環境下における開発手法の知見は既に多く存在しています。それらの多くはそのまま採用できるほど洗練された知見ですが、必ずしも私たちのスタイルに合致するとは限りません。 私たちならではのスタイルを探ってみる価値はあるでしょう。いいものが見つかれば最高ですし、見つからなければ「見つからなかった」という成果を得られます。 さて、すでに知られているとおり、アジャイル開発のトピックは多岐に渡ります。どのトピックから始めるかは迷うところですが、まずはアジャイルの中でも特に有名なスクラムの見直しから始めることにしました。つまり、リモート環境下におけるスクラムです。 リモート環境下のスクラムをこすろう リモート環境下におけるスクラムを深堀りするにあたって、ひとつ問題がありました。それはスクラム未経験者がDTFに存在するということです。 DTFは兼務を前提としており、各種チームからメンバーが集められています。チームが為すべきことはチームによって異なり、当然ながらその開発手法もチームによって異なります。スクラムを経験していないメンバーがいるのも致し方ありません。 しかし、スクラムを深掘りしていくにあたって、スクラムを経験していないのは、守破離の破から始めるようなものです。到底上手くいくとも思えません。 なにはなくとも、まずは基本から。ということで、まずはスクラムを体験することから始めることにしました。 スクラムを体験する方法 スクラムを体験するには実際にスクラムで開発をするのがもっともよいでしょう。しかしながら、DTFは兼務から成る混成チームです。集まりは週１回。がっぷり四つにスクラムで何かを開発するのは難しいです。 そこで、スクラムを完全に体験するのは先送りにして、疑似体験する方法を調査しはじめました。つまり、ワークショップです。 調べてみるとスクラムを体験するワークショップは色々な種類があるようでした。ピンポンゲームや紙飛行機ワークショップ、そしてレゴ®スクラム。いずれもスクラムを疑似体験するものといった点で共通していますが、ワークショップごとにカバーする範囲は異なるようです。 そこで私たちはいくつかのワークショップをやってみることにしました。今回はその中のひとつ、去年実施したレゴ®スクラムについてお話します。 レゴ®スクラム みなさん、レゴ®はご存知でしょうか。 そう、こちらです。 幼い頃、夢中になって遊んだ方もいるでしょうか。マキビシのようにブロックを踏んづけて痛い思いをした方もいらっしゃるのではないでしょうか。今回お話するワークショップは、このレゴ®を使ったワークショップです。 レゴ®を使ったスクラムワークショップは古くからメジャーなようで、たとえば「#lego4scrum」というレゴ®スクラムを取り扱ったサイトでは2015年時点の動画が存在します。 https://www.lego4scrum.com ちなみにこちらのサイトでは、レゴ®スクラムのファシリテーションガイドを入手できたりします。今回は、こちらのファシリテーションガイドを参考にしながら、アレンジを加えて実施したスクラムワークショップの内容をお届けします。 ワークショップ概要 レゴ®スクラムはレゴ®ブロックを使って、スクラムの手法を実践しながら建物を作るワークショップです。 ワークショップでは参加者同士数名でチームを組んで、テーマにしたがった建物を作ります。多くの場合は、ひとつの建物を作るのではなく、街などをテーマにして複数の建物を作るようです。 所要時間は少なくとも半日かかります。スクラムの解説から始める場合は１日かかると考えてよいでしょう。準備物もそれなりに多く、なによりブロックのコストがかかります。 まとめると、レゴ®スクラムは所要時間が長く、準備にコストがかかる重厚なワークショップです。その分得られるものは軽量なワークショップに比べて段違いです。 準備するもの まずはワークショップを実施するにあたって準備するものを確認していきます。 小道具 ワークショップで使う小道具 必要なものは次のとおりです。 レゴ®サインペンカラーマジック付箋（正方形）プランニングポーカー模造紙 ひとつのチームにつき、こちらのセットをひとつ用意します。 どのブロックを用意するかは悩みどころです。私たちは次の『黄色のアイデアボックス＜スペシャル＞』と『想像力の窓』を２チーム分購入しました。大の大人が集まって、どのレゴがいいか吟味するミーティングは乙なものです。 黄色のアイデアボックス＜スペシャル＞：https://www.lego.com/ja-jp/product/lego-large-creative-brick-box-10698想像力の窓：https://www.lego.com/ja-jp/product/windows-of-creativity-11004 ワークショップを実施した経験からいえば、５名程度のチームであれば、ボックスがひとつあれば、大抵の場合はことたりるでしょう。それ以上の人数をひとつのチームにしたいときには、『想像力の窓』などのセットを買い足しておくと安心です。 プランニングポーカーは購入してもよいですが、自作でも問題ありません。マルチカード（名刺など）用紙を使ってプランニングポーカーを作ることもできます。今回は次のリンク先のプランニングポーカー作成用PDFを利用いたしました。 https://www.surviveplus.net/ja/archives/137 設備 設備はいずれも一般的な会議室であれば揃うものです。 テーブル椅子ホワイトボードプロジェクタ（任意） テーブルは模造紙を広げられる程度の広さが必要です。また、それ以外にもブロックをあらかじめ広げておくためのテーブルも用意できるとよいでしょう。 ブロックを広げておくテーブル ホワイトボードはこのあと解説するプロダクトバックログとタスクボードを作れる程度の大きさが必要です。一般的なホワイトボードであれば、問題ない大きさです。 ホワイトボードが用意できない場合は、模造紙を壁に貼り付けるのがおすすめです。 ホワイトボード代わりの模造紙 プロジェクタは任意ですが、用意しておくとスクラムについての導入や、今何をするタイミングなのかを示すのに便利です。昨今のリモートワークの流れであれば、事前にオンライン会議で講義する形でもよいでしょう。 ワークショップの流れ ワークショップは次の順序で進んでいきます。 スクラム入門講義チーム分け題目発表ペルソナの決定ユーザーストーリーの作成プロダクトオーナーの選出タスクボードの作成プランニングポーカーによる見積もりプロダクトバックログの作成スプリント（４回）振り返りする 実際に私たちが実施した内容を元に、それぞれ確認していきましょう。 スクラム入門の講義をする レゴ®スクラムは半日以上かけてスクラムを体験するワークショップです。体験の質を向上させるためには、スクラムに関する概要的な知識が必要です。さもなければ、ワークショップ中の作業やイベントの意図や位置づけが不明になってしまい、まったく意味のないものになってしまいます。 スクラム未経験者や知識のない参加者がいる場合には、ワークショップ開始前に彼らに向けた入門用の講義を行います。講義内容はワークショップで実際に体験する事物を中心に説明します。とはいえ、一般的なスクラムを網羅的に体験するワークショップですので、スクラムを構成するロールや作成物、イベントを網羅的に解説することになります。 ここでは実際に私が解説した内容を確認していきます。 スクラムの概要説明 最初にスクラムがどういったものかを解説します。アジャイルにおけるスクラム開発の位置づけや構成要素の確認です。 ロールの説明 ロールに関しては、数も多くないのですべて解説します。 開発者プロダクトオーナースクラムマスター 今回計画したワークショップでは、参加者は開発者を必ず経験します。また１チームにつき１名がプロダクトオーナーを経験することになります。 スクラムマスターはスクラムに関する理解と意欲がある参加者が存在する場合には立てられます。これに関しては「プロダクトオーナーを選出する」の項で説明します。 作成物の説明 スクラムにおける作成物を説明します。ここで解説した作成物は次の３つです。 プロダクトバックログスプリントバックログインクリメント ユーザーストーリーやタスクボード、完成の定義など、それぞれの作成物を作るにあたり必要になる事物や概念の解説もしておきます。 イベントの説明 ここで解説するイベントは次のとおりです。 バックログリファインメントスプリントプランニングデイリースクラムスプリントレビュースプリントレトロスペクティブ タイムボックスやベロシティといった重要な概念も出てくるので、手厚く解説をしましょう。とくにタイムボックスはおろそかになりがちなので、重点的に解説します。 チームを分ける 今回のワークショップでは、チームの規模は５名で実施しました。スクラムを取り入れたいチームが対象であればチームごと参加いただくのがいいでしょう。 参加者にスクラム経験者が少なかったので、経験年数で均等になるようにチーム分けを行いました。 チーム分けの様子 ちなみに今回はDTFのメンバー以外に、新卒二年目の若手とデベロッパーリレーションズチームのリーダーにご協力いただいて、総勢１０名の参加です。５名ずつに分かれて２チームが作られました。 各チームごとにチーム名を考案してもらって、チーム分けは完了です。 Team Japan チームサラマンダー チーム名は「Team Japan」と「サラマンダー」です。日出ずる国vs火の精霊ですね。神話かな。 題目を発表する ワークショップでチームが開発するテーマを発表します。テーマはブロックで表現できればなんでもよいです。私がワークショップを組み立てる際に候補にしていたのは次の３つです。 街職場遊園地 街づくりは誰でもイメージしやすいオーソドックスなテーマです。職場づくりはブロックで表現するには狭すぎる印象があります。遊園地はペルソナがお客様なのかパートナーなのかによって、考えることが様変わりするので面白いテーマです。 最終的に「最初はオーソドックスにしたい」と考え、「街」をテーマにしました。「遊園地」も面白そうなのですが、著作権に関わりそうな建物が建てられそうなので今回は見送りです。 ペルソナを決める 参加者はそれぞれテーマに沿って自分のペルソナを決めます。「街」がテーマであればそこに住む家族、「職場」がテーマであればいくつかの職種、「遊園地」であれば来園者やそこで働くパートナーがペルソナの候補になります。 今回のワークショップでは「街」をテーマにしたので、ペルソナの候補は次のとおりにしました。 祖父祖母父母息子娘ペット 参加者はいずれかを選択し、年齢はいくつなのか、職業は何なのか、趣味はなにか、種族はなにか、といったようにペルソナを深掘りしていきます。 ペルソナを深掘りする ユーザーストーリーを作成する 参加者それぞれが自身のペルソナを決めたら、ペルソナにしたがってユーザーストーリーを作ります。 ユーザーストーリーというと難しく構えてしまいますが、要するに自分が欲しい何かを列挙するだけです。たとえば「街」がテーマであれば、「家の近くにコンビニが欲しい」とか「運動したいのでジムが欲しい」といった要領で、自分が住む町に欲しい施設を挙げるのです。 ユーザーストーリーは付箋に記述しますが、その記法は次のテンプレートにしたがいます。 「＜どういった立場＞として、＜どういったもの＞が欲しい。それは＜どんなことが達成したい＞からだ」 このテンプレートでは太字の部分を記入します。たとえば「散歩が好きな犬として、大きな公園が欲しい。それは走り回る場所が欲しいからだ」といった具合にです。 サイクリングが好きな娘は海が欲しい 簡単そうに見えますが、慣れないうちは欲しい施設だけを付箋に書いてしまって終わってしまうことがあります。欲しいものそれ自体はもちろん重要ですが、立場や動機はそのユーザーストーリーの背景を知るのに重要です。まずはテンプレートを守るようにしましょう。 ユーザーストーリーが書けたら模造紙を地図に見立てて配置します。中央に自分たち家族の家を配置して、施設の位置関係や道路などをカラーマジックなどで書き込んでいきます。 ユーザーストーリーが配置された地図 こちらの作業は最初はみんな戸惑っていましたが、乗ってくると楽しくて、終わり時を逃しやすいです。トレーナーには冷徹に時間を区切って次に進める胆力が必要です。 プロダクトオーナーを選出する 各チームごとにプロダクトオーナーとなるメンバーを選出します。#lego4scrumでは、トレーナーがプロダクトオーナーをやることになっていますが、せっかくなので参加者にプロダクトオーナーをしてもらって、トレーナーがそれをサポートすることにしました。 プロダクトオーナーのやることは、このあと作るプロダクトバックログの管理を主体的に行うことです。開発チームと相談しながら、プロダクトバックログの優先順位を変え、必要に応じてステークホルダーとのやり取りを行います。もちろん開発者も兼務することになるので、ブロックで建物を作ります。 この際、スクラムマスターを立てることも可能ですが、注意すべき事柄があります。スクラムマスターを担うにはスクラムに関する理解と意欲が必要です。さもなければタイムボックスを意識して守れなかったり、イベントで他のことをやってしまい、うまくスクラムを回せない結果に繋がります。 スクラム未経験者や初心者ばかりの場合にはスクラムマスターを立てない方が無難でしょう。今回の私たちのワークショップでも、スクラムマスターは立てない方向で進めました。 要求を交換する プロジェクトの多くは、自分以外の誰かが欲しいものを作ることが多いです。そこで、今回のワークショップでもそれを再現すべく、地図の交換をしました。つまり、参加者の眼前には他のチームのユーザーストーリーが貼られた街が広がることになります。参加者が開発するのは、目の前の街です。 以降、参加者は一人二役になります。目の前の街に対しては開発チームとして振舞い、もう一方のそれまで自分たちの要求を張り付けてきた街に対してはステークホルダーとして振舞うことになります。 タスクボードを作成する チームごとにタスクボードを作成します。タスクボードはユーザーストーリーを貼るスペースとTODO, DOING, DONEのフェーズを用意したシンプルなものです。 シンプルなタスクボード スプリント自体は短いので、これくらいの粗い粒度で十分です。むしろ、これ以上粒度を細かくしても、扱いきれないでしょう。 プランニングポーカーで見積もる ユーザーストーリーをプランニングポーカーを使って見積もりします。 プランニングポーカーを知らない方向けに説明すると、数字の書かれたカードを一斉に出し合う見積もり方法です。メンバーは任意のユーザーストーリーに対してプランニングポーカーを使って、自分が思うポイントをあてはめます。 プランニングポーカーによる見積もり プランニングポーカーで使われる数値は工数を直接表すものではなく、重みを表すポイントです。基準となる数値を決めて、そこから相対評価でポイントを見積もります。人間は相対評価が得意なので、スムーズに見積もりができます。 カードの数値はフィボナッチ数列が使われることが多いようです。フィボナッチ数列は1, 2, 3, 5, 8, 13, 21, ……といったように、直近２つの数値を足し合わせた数列です。「平均値より小さい」や「平均値より大きい」、「平均値よりとても大きい」、「想像もつかないほど大きい」といった表現がしやすいのがこの数列です。 場に出たカードのポイントが一致すれば、合意が取れたことになります。数値が大きい、あるいは小さいときは、なぜその見積もりになったのかをインタビューして、そこに潜む問題点やハックを深掘りします。このような手順を取ることで、見積もりが公正で透明性と納得感のある数値に近づきます。 なお、相対評価を行うためには基準を最初に決める必要があります。通常は開発チームで合意が取れるもっとも平均的なユーザーストーリーを選んで、それを３とします。 しかしながら、レゴ®に関しては一体どれくらいかければどれくらいのものができるのか、という知見がほとんどの場合ありません。そこで、事前に私のほうで試作をしました。試作品をご紹介しましょう。 試作品 スプリントは７分の予定なので、７分で作った建物です。色をそろえると７分ではなかなか厳しそうという印象がありました。あとオフィスでレゴ®をするのはなかなかの胆力が必要でした。 建物以外に、もうひとつ作品を作りました。 お分かりですね これは見ればわかりますね。弊社のホスティングサービス「ConoHa」の応援団長である美雲このは（@MikumoConoHa）です。 これらの作品を３ポイントとして参加者は見積もりをしていきます。 ３ポイントの基準を提示 見積もったポイントはユーザーストーリーの付箋に書いておきます。 見積もりをユーザーストーリーに記入する 見積もりをしていると、疑問や確認したいことが発生することがあります。その際には、プロダクトオーナーがステークホルダーにヒアリングを行い、開発チームに共有します。 疑問点や確認事項をヒアリングする プロダクトバックログを作成する ユーザーストーリーの優先順位を決めて、プロダクトバックログを作ります。 プロダクトバックログを作る ユーザーストーリーを模造紙から剥がして、ホワイトボードに貼り、優先順位に並べ替えます。模造紙から剥がすとき、それが地図のどこにあったか分かるように識別子を振って、地図に書いておくといいでしょう。 スプリントを実行する ここからはスプリントの開始です。スプリントは次の流れで行います。 スプリントプランニング実行スプリントレビュースプリントレトロスペクティブバックログリファインメント 実際のスクラムでは、実行の際にデイリースクラムが実施されます。 スプリントプランニングの実施 スプリントの最初にはスプリントの計画をします。 まず最初に次のスプリントで消化できそうなポイントの予測をします。消化とはステークホルダーに検収してもらえることをいいます。この予測はスプリントを何度かこなすことで正確性が強まるものなので、チームの誰も類似の作業をしたことがない場合には、初回に関しては勘によるところも多いです（予測のために研究期間を設けることもあります）。 見積もった数値によって、ユーザーストーリーを入れ替えた方が綺麗に収まる場合があります。たとえば、消化予測ポイントが２０のとき、８＋８＋３＝１９よりも８＋８＋２＋２＝２０の方が消化率はよいです。そういったときは順序を並べ替えます。 また、巨大すぎるユーザーストーリーは取り扱いづらいものです。その場合にはプロダクトオーナーと相談しながら、ユーザーストーリーの分割をします。 今回のスプリントで着手するユーザーストーリーが決まったら、次はタスク分けを行います。 タスク分けのイメージ共有に使ったスライド ひとつのユーザーストーリーでひとつのタスクになることもあれば、複数のタスクが必要な場合もあります。ここでタスクを洗い出しておくことで、開発チームはユーザーストーリーを分業できます。 実行 いよいよ開発のはじまりです。７分のタイムボックスでタスクをこなしていきます。 タスクにサインアップする タスクボードでタスクにサインアップして、ブロックを組み立てます。 ブロックを組み立てる 実際にやってみると７分はあっという間です。 スプリントレビューの実施 ７分の楽しい時間を終えたら、いよいよお披露目の時間です。 スプリントレビューの様子 開発チームは着手したユーザーストーリーと成果物をステークホルダーにデモします。成果物が完成していれば、ステークホルダーは完成を伝えます。 ステークホルダーの合意 ここで重要なのは、スプリントレビューはプレゼンテーションではなくワーキングセッションであるということです。ステークホルダーと一体になって、成果物が完成しているかどうか、完成していないのであれば何が必要か、フィードバックします。 スプリントレトロスペクティブの実施 レビューを終えたらスプリントのふりかえりを行います。 今回はKPTを使って振り返りをしました。KPTはKeep, Problem, Tryの頭文字をとった振り返り方法で、「今後も続けること」「問題や課題」「次に挑戦すること」をそれぞれ考えて振り返る方法です。 KPTを実施するとPに囚われがちなので、Tを重視するように言い渡しておくとよいでしょう。 振り返りの様子 スプリントレトロスペクティブでありがちなのが、ここで次のスプリントの計画をはじめてしまうことです。次のスプリントを計画するための時間として、スプリントプランニングがあります。ここで行う計画は次のスプリントで行う改善の計画にとどめておきます。 バックログリファインメントの実施 スプリントが終わったら、次のスプリントにむけて、バックログリファインメントを行います。 バックログリファインメントはプロダクトバックログのお手入れをします。優先順位の変更や優先順位上位のユーザーストーリーを着手可能にするために情報収集します。 優先順位の変更をチームと共有する様子 次のスプリントへ リファインメントが終わったら、またスプリントをはじめます。 今回私たちは４回スプリントを実行しました。スプリント１回につき、だいたい３０分程度かかり、全体では半日程度の所要時間になります。 ワークショップレポート ワークショップを実施した様子や感想を確認します。 できあがった街 まずはTeam Japanが開発した街です。 Team Japanが開発した街 全体的にしっかりした建物が多い印象です。途中で色については合わせなくても問題ないと判断したのか、色の統一はしなくなったようです。 次はチームサラマンダーの開発した街です。 チームサラマンダーが開発した街 特徴的な形をした建物が多いです。私は温泉が好きです。 今回のワークショップはかなり上手く建物を作れたのではないかなと考えます。恐らく、普段から交流のあるメンバーが多かったので、連携が取れていたのが要因でしょう。 建物のハイライトは最後にしますのでお楽しみに。 ベロシティの変化 １回のスプリントで消化できる要求の総量をベロシティといいます。今回のワークショップでいえば、１スプリントで消化するユーザーストーリーの見積もりポイントの総和がベロシティです。 ベロシティは初回は小さく、スプリントが進むうちに安定するようになります。特にはじめて実践するものだと完成にこぎつけないことも多く、最初のスプリントはベロシティが０になることもしばしばあります。 今回のワークショップでのベロシティの推移は次の画像のとおりです。 ベロシティの推移（丸数字が回数で、その横の数値は「完了／予測」を表す） 画像ではスラッシュの右側が予測値で左側が実際に消化できたポイントの総和です。「＋１９」といった表記は、直前のスプリントで完成できなかったユーザーストーリーが完成になったことを表しています。 いずれのチームも最初はベロシティが低かったのですが、３回目から高い値で安定しはじめています。また予測との乖離も少なく、ベロシティが信頼たる数値になりつつあるのが分かります。 参加者の感想 参加者には感想を書いてもらったので、ここにいくつかピックアップします。 スプリントをこなすにつれてベロシティのズレが減ってきたのはリアルだと感じた１周目あたりは、ルールが飲み込めず戸惑ったことがあった誰が今何をやってるかの共有をして、タスクのバッティングの危険を防ぐといった経験から、コミュニケーションの重要性を改めて認識したたとえば犬小屋の大きさについてなどで、ユーザーストーリーで認識の齟齬があったので、仕様確認の重要性を改めて認識したTryで試みた「コンパクトに作る」や「建物の特徴を出す」を実践し、レビューでOKをもらえたのは達成感があったレゴ®だから楽しくできたのであって、実際に開発になると全然違う印象になるんだろうなと思った普段コミュニケーションを取る機会がない人とも距離を詰めることができた新卒の人たちにもスクラムを体験してもらいたい 事前にほかの軽量なスクラムワークショップをいくつか実施していたこともあり、このワークショップの効果をまじまじと感じたようで、スクラムに関して深く体験できたと感じた方が多かったようです。 またコミュニケーションを取るという意味でも、ワークショップは役立ったようです。 成瀬の感想 得るものや楽しさがもちろんあるのですが、それらを差し置いてとにもかくにも疲れました。トレーナーとして、ファシリテーションしながら、同時に各チームのスクラムマスターをしてるような動き方をしていたので、かなり集中力を使いました。 DTF主管の部長が「スクラムはやっている最中はハイになっているけど、終わるとどっと疲れる」と言っていたのですが、その意味がよくわかるワークショップです。逆に言えばこれほどの労力をかけないと、スクラムの本当のところを感じたり、学ぶのが難しいのではないかなという印象があります。 もちろん、実務で実践的にスクラムを学ぶこともできます。その場合は１週間や２週間といった長いスパンでスクラムイベントを体験することになります。そのため、なかなかそれぞれのイベントの趣旨やルールを覚えづらいです。 このワークショップであれば、スクラムで実施するイベントをその日のうちに何度も体験するので、趣旨やルールを確実に理解できます。スクラムをこれから取り入れたいといったチームにとって、半日を費やす価値はあるのではないでしょうか。 作成物のハイライト 折角ですので、ワークショップで作られた建物のうち、いくつかをピックアップしてここで紹介します。 まずはどちらのチームも作ったものです。テーマが同じであるので、意図せずして同じものが作成物にありました。チームごとの特色が見えたりするので、まずは比べながら見てみましょう。 最初に紹介するのは「駅」です。 チームサラマンダーの駅 Team Japanの駅 同じ駅でも何を重視するかというのはチームによって異なるのが面白いですね。 駅以外に、両方のチームで作られた建物としては公園がありました。 Team Japanの公園 チームサラマンダーの公園 いずれも滑り台や植物は同じブロックを使っていて、最適解にたどり着いた印象がありますね。 次は私が個人的に好きな建物です。 左手前の建物 この左手前の建物が、何かわかるでしょうか。　──そう、温泉です。センスが光りますね。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 さて、次は誰が見ても分かる建物です。 誰が見てもわかる建物 どうみても１００円ショップですね。参加者全員がひと目でわかりました。 最後は誰が見ても分からない建物です。 誰が見てもわからない建物 お分かりでしょうか。 そうです。コスメです。「建物じゃないじゃないか」と思った方、そのとおりです。 本来は「コスメショップ」が欲しかったようですが、ユーザーストーリーに「コスメ」と書いてあったので、「コスメ」になってしまいました。これはユーザーストーリーの書き方が悪かったのとステークホルダーとコミュニケーションエラーが発生した結果です。実際のプロジェクトでもこういったことはよくありますよね。 おわりに これはよく言われることですが、スクラムはフレームワークです。どれか一部を切り取ってみても、あまりうまくいかないことが多いです。 ではフレームワークとしての効果を発揮するために、スクラムをいきなり実践で始めるのはどうでしょうか。チームに意欲があっても、知識や理解がない状態では上手くまわらないでしょう。 「スクラムを始めるためにスクラムの知識や経験がほしい」そんな要求に応えられるのがこのレゴ®スクラムです。スクラムを実践したい方々にはぜひおすすめします。 また単純にコミュニケーション目的で実施するのもおすすめです。スクラムをやったことがないチームには勉強目的で、既にスクラムを実践しているチームは新メンバーが増えたときなどに行うと自然とコミュニケーションを促せます。 童心に帰ってレゴ®をするのは立場も年齢も関係ありませんからね。 部長が本気でブロックを組み立てる様子 以上で今回の記事は終わりです。長大な文章をここまでご覧いただきありがとうございました。 お気に入りの建物をもって記念撮影 次回は、レゴ®スクラムの問題点であるオフライン環境必須という条件を打破すべく実施した、リモート環境下におけるスクラムワークショップのレポートを予定しています。 おまけ レゴ®は置く場所がなかったので部長の席が保管場所になりました。 シリーズ一覧 https://developers.gmo.jp/5571/ https://developers.gmo.jp/10479/ https://developers.gmo.jp/13055/

GMOインターネット新里です。よくIoT向けにはMQTT/CoAPと話が出ますが、本エントリーでは、色々と実装してきた中で感じたことを綴ってみます。 IoT向けとは？ "IoT = Internet of Things"という言葉もわりと浸透してきましたね。僕が最初にIoTなるワードを見た時は、"これ=IoT"は一体何の顔文字なのか？と思ったりしましたが。WoT(Web of Things)、AIoT(AI of Things)といった、「とりあえずThings付けてみるか？」みたいな感じの言葉も出てきています。 IoT =「モノのインターネット」というのは、モノがインターネットに繋がって何かサービスをすると考えられますね。インターネットに繋がるには、一体どうすれば？という事があります。 モノが使う通信 僕が触ったり使ってきたモノにはIPを使うモノ以外もたくさんあります。ザックリと通信で大別するとこんな感じでしょうね。 ■ 非IPモノBluetooth、BLE、Zigbee、920MHz/420MHz帯域モノ（Lazurite、RoLA、Sigfox、Wi-SUN、ELTERS...etc） ■ IPモノWi-Fi、セルラー（3G、LTEモノ）、有線（Ethernet） すべてのIoT的なモノがIPを使えれば良いですが、必ずしもそうではありませんね。そこで、非IP物はインターネットに接続するGatewayを介して制御することになります。 たとえば、僕はBluetoothの体重計を使っています。この体重計がIoT端末としても考えることが出来て、スマホから体重のデータを通信して保存したり傾向を分析したり、、、といった感じですね。 このように、必ずしも直接インターネットに接続しなくても良いIoT的な端末と、Wi-Fi等を使用したIPで直接通信をする端末があります。後者については、たとえばAmazonスマートプラグは直接Wi-Fiに接続しています。そして、リモートでスマートプラグのON/OFFをすることが出来ます。 このインターネットにIPで接続するようなIoT的な端末において、よく話に上がるプロトコルにMQTTとCoAPがあります。なぜこの２つが？がというと、後述するTCP/UDPで対応している、気づいたら流行っていた、大手クラウドベンダーがプラットフォームとして対応した(GCP、Azure，AWSなどはMQTTに対応している)といった理由がありそうです。ただ、僕的にはHTTP(S)の方が、IoT的な環境でよく利用される物ではあると考えています。HTTPでAPIを叩くような感じで、IoT的な端末で実装した方が、「使い慣れた環境」として便利なのかなーと。他にも将来的にはQUIC、HTTP/3がIoTの世界にも入ってくるのは容易に想像できるでしょう。 MQTT MQTTはIBMで仕様が作られたPub/Subメッセージプロトコルです。仕様はこちらで公開されていますね。仕組みは簡単、メッセージブローカーにSubscribeして、Publishでメッセージが配送されるといったシンプルな物ですね。 この例だとSubscriberにPublisherが配送された、{"temperature": "10"}が配送されます。ここでBroker部分がクラウド化されて、AWS IoT Core, Google Cloud IoT Core, Azure Hub...etc と主なクラウドサービスでは使うことができますね。同時にこれらのサービスだと、端末の管理も行ってくれて便利だったりもします。 以下はMQTTサーバに接続してPub/SubするParticle向けの簡単なコードです。 #include "MQTT.h" // 受信用のコールバック void callback(char* topic, byte* payload, unsigned int length); // MQTTにコールバックを設定 MQTT client("server_dns_or_ip", 1883, callback); // コールバック void callback(char* topic, byte* payload, unsigned int length) { char p[length + 1]; memcpy(p, payload, length); p[length] = NULL; if (!strcmp(p, "RED")) RGB.color(255, 0, 0); else if (!strcmp(p, "GREEN")) RGB.color(0, 255, 0); else if (!strcmp(p, "BLUE")) RGB.color(0, 0, 255); else RGB.color(255, 255, 255); delay(1000); } void setup() { RGB.control(true); // MQTTサーバに接続 client.connect("sparkclient"); // publish/subscribeの登録 if (client.isConnected()) { client.publish("outTopic/message","hello world"); client.subscribe("inTopic/message"); } } void loop() { if (client.isConnected()) client.loop(); } MQTTは基本はTCPを使っていて、セキュリティを考えると下回りはTLSを使う方が良いでしょう。UDPを使うMQTT-SN(Sensor Network)という物もありますが、まだこれからといった感じがしています。 CoAP CoAPはRFC 7252で上がっている、UDPを使ったM2M向けのプロトコルです。マイコンのような低消費電力、ROM/RAMの容量をターゲットにしています。CoAPの特徴的なのはUDPを使ってHTTPを実装しているような仕組みになっている点です。 MQTTのようにPub/Subではなく、Web（HTTP）を意識して動作します。センサー端末同士をCoAPで通信する他、CoAP Proxyを通すことでHTTPとの通信も可能にしている所がおもしろいですね。動作的にはCoAPサーバのエンドポイントに対してPUT/POST/GET/DELETE メソッドでアクセスしてデータの登録・取得をします。足回りにDTLSを使ってセキュリティに配慮したオプションも用意されています。 以下はESP32向けのCoAPの簡単な実装です。"/light" をエンドポイントとしたCoAPサーバとして動作します。 #include <WiFi.h> #include <WiFiUdp.h> #include <coap-simple.h> const char* ssid = "your-ssid"; const char* password = "your-password"; // コールバック用関数 void callback_response(CoapPacket &packet, IPAddress ip, int port); void callback_light(CoapPacket &packet, IPAddress ip, int port); // UDP and CoAP class WiFiUDP udp; Coap coap(udp); // LED STATE bool LEDSTATE; // CoAPサーバとして動作するコードバック void callback_light(CoapPacket &packet, IPAddress ip, int port) { Serial.println("[Light] ON/OFF"); // send response char p[packet.payloadlen + 1]; memcpy(p, packet.payload, packet.payloadlen); p[packet.payloadlen] = NULL; String message(p); if (message.equals("0")) LEDSTATE = false; else if(message.equals("1")) LEDSTATE = true; if (LEDSTATE) { digitalWrite(9, HIGH) ; coap.sendResponse(ip, port, packet.messageid, "1"); } else { digitalWrite(9, LOW) ; coap.sendResponse(ip, port, packet.messageid, "0"); } } // クライアント用コールバック void callback_response(CoapPacket &packet, IPAddress ip, int port) { Serial.println("[Coap Response got]"); char p[packet.payloadlen + 1]; memcpy(p, packet.payload, packet.payloadlen); p[packet.payloadlen] = NULL; Serial.println(p); } void setup() { Serial.begin(9600); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } // LEDの状態 pinMode(9, OUTPUT); digitalWrite(9, HIGH); LEDSTATE = true; // サーバーのエンドポイント "/light" とコールバック定義 coap.server(callback_light, "light"); // クライアント動作する時のコールバックを定義 coap.response(callback_response); // CoAPサーバとして起動 coap.start(); } void loop() { delay(1000); coap.loop(); } なーんとなくMQTTと似たような感じで実装できそうですが、TCP/UDPという大きな違い、プロトコルの中身も全然異なっていますね。 セキュリティ 上で触れたコードは個人的にCoAP/MQTTの実装をして、GitHubで公開をしています。MQTT、MQTT-TLS、Simple CoAP LibraryMQTTはParticleといデバイス向けで、CoAPについてはArduinoを始めとした一般的なマイコン環境での動作を想定した物です。両方ともIoT的な用途では色々に実装やIoT的な論文とかでも使われていますね。MQTTの方は数十万端末上でコンパイル&動作していたり、色々な会社さんでも実際に使われていたりしています。CoAPの方も探してみると、PlatformIOの方に展開されていたり、それなりに使って貰えているようです。TLSに対応したのは、組込み端末にTLSを実装してみたかったというのもあるものの、この手のマイコンにTLS組込みの大変さはあったりもします。もちろんOpenSSLのような超巨大な物は使えない。組込み向けのサイズが小さいmbedTLSを使うことになりますね。 ■ 容量との果てしない戦い■ アルゴリズム何を使う？■ MPUのスペック大丈夫か？■ 存在しない関数群の補完■ verify、時刻同期どうする？ ざっと面倒な点はこれらになるでしょう。そもそもマイコンのアプリ領域で使えるサイズは限られていて、Particle Photonの場合は96Kbyteだけです。mbedTLSをギリギリに切り詰めても50-60Kbyteになってしまうため、アプリ領域で使えるサイズを圧迫して、アプリが実装する領域を削ってしまうことになっちゃいます。 TLSのアルゴリズムはセキュリティや接続先のサーバの接続性で色々なアルゴリズムを使いたいものの、また容量との戦いを繰り返すことに。そして、MPUのスペックは120MHz ARM Cortex-M3で大丈夫か？　と心配だったものの、わりとこれはすんなり動作しました。ただ、メモリ容量も圧迫するので、常にサイズは意識する必要があるのがキツイですね。そして組込み向けなので、存在しない関数も当然出てきます。それらを補完して、次は時刻同期をどうするか？というのは1つ問題として出てきました。もちろんRTCの電池なんか付いている物はないです。ただ証明書のverify/expireで日時を確認するのは基本ということもあって、ネットワークに接続後時刻同期を行ってからverifyを行うようにしています。 実際にmbedTLSを組込むのにかかった時間は2日程度でした。というくらいmbedTLSを組込むのは容易な反面、マイコン・IoT端末にの環境に依存して「実際にTLSで通信できるもの」にするには工夫が必要になってきますね。 結局何が良いのか？ 率直には、「好きなモノを使えばOK」とは思っています。MQTT・CoAP共にライブラリや実装が公開されて使えるものが多数あるため、実際に自分が使う環境で組込む分には問題ないでしょう。どちらもプロトコルはシンプルなので、自作しても良いでしょうし。将来的にQUIC、HTTP/3が主流になってくれば、IoT的なプロトコルでも同じような流れになるような予想はしています。 現在のところ、多くのクラウドサービスがMQTTに対応しているのもあって、クラウドとIoT的な連携を考慮すると、MQTTのほうが使いやすいでしょう。逆にモノ同士の通信を行う時や、UDPの軽量さを使いたい場合はCoAPを使うという選択に自然となってくる、ケースバイケースで用途が決まってくる流れですね。 もちろん、MQTT/CoAPにこだわる必要もなく、HTTPSで通信しても良いでしょう。最近のマイコンや端末は非常にスペックが強力になってきて、TLSに限らず大抵のプロトコルはすんなり使えるようになってきました。つまり、IoT向けだからMQTT/CoAPということもなく、どのプラットフォームで端末の環境に依存して、その上で動くアプリ・通信手段を考慮して、利用するプロトコルを選択した方が良いでしょう。

こんにちは。GMOインターネットの村上です。本エントリーはエンジニアのブログ執筆に関して書いていきます。 エンジニアになったからには、誰もが一度はアウトプットとしてブログを書くことを考えたことがあるはずです。 情報発信だったり、学んだことを再確認する為だったり。 たくさんのエンジニアに読んでもらい、成長する為のショートカットとして使っていただけたら幸いです。 はじめに はじめまして。デベロッパーリレーションズチームの村上です。2021年の1月にジョインしました。デベロッパーリレーションズチームは兼務で、普段はアクセス系商材の開発やマネジメントをやっています。 たくさんのエンジニアを見てきた経験から、「なぜエンジニアはブログを書いた方がよいのか」「ブログ執筆に際してのポイント」をテーマに執筆していきます。 なぜエンジニアはブログを書いたほうがいいのか これまでエンジニアとして仕事をしてきた経験、マネジメント業を任されて見えてきた視点を踏まえ、エンジニアがブログを書いた方がいいと思う理由が3つあります。ひとつずつ紹介していきます。 エンジニアがブログを書いた方がいい理由 エンジニアがブログを書いた方がいい理由①知識の定着 プログラミングしていて、とある箇所が全く解決できずに堂々巡りに陥ったことないですか？ネットで調べ、周りの人に聞いてみて、漸く解決できたとします。その瞬間はすごく達成感に満ち溢れていて、一つレベルアップしたように感じるのではないでしょうか。 それから数カ月後、他の人から同じようなところで躓いて質問されたとします。果たしてあなたはそれをサッと回答できるでしょうか？ドキュメント化していなければ、恐らく多くの方は同じ工程を繰り返したり、思い出すまでに時間を要すると思います。 知識は1度調べただけでは定着させることは難しいです。悩んで調べたことをしっかりと思い返して学んだことを自分の言葉でブログに書くことによって、自分の知識となり、解決するまでの時間や過程も含めて財産となります。 エンジニアがブログを書いた方がいい理由②周りへのアピール 私は中途採用にも関わっています。採用活動の中で、未経験でIT業界に転職したいという方は結構多くいらっしゃいます。中にはネットで勉強しています、とか、プログラミングスクールに通ってますという方もいます。自己学習するのは非常に素晴らしいと思います！ですが、勉強しているという言葉だけでどこまで信用性がありますか？ ブログに日々の学びや得た知識をアウトプットしていく自分がこれだけのことをやっている、こんなスキルを学んでいるというアピールなります。もちろん手段はブログだけではありませんが、少なくともアピールの1つのチャネルとして活用できます。内容次第では面接官にもしっかりと響くはずです。 アピールが大切な理由は、未来のキャリアのためだけではありません。現職においてもプラスの要素があります。インプットアウトプットを繰り返し、スキルを自分のものにしているエンジニアはとても信頼できますし、当然新しい仕事を任たいと思います。周りの仲間から頼られる場面も出てくるはずです。エンジニアとして働くために、新しい技術動向やスキルをインプットし続けることは皆同じように努力しています。では、周囲とどこで差をつけるのかという点において、ブログを通したアウトプットはとても有益であると言えます。 エンジニアがブログを書いた方がいい理由③コミュニケーション力の向上 これは頭ではわかっているけど、説明するのが難しく感じているエンジニアにとって非常に効果があります。文章に書くことで筋道立てて説明するように書くようになってきます。もちろん最初からは難しいと思いますが、継続して記事を書くことで理論的に整理することの練習になります。ドキュメントを整理して書く練習を重ねることで伝える力が上達していき、実際のコミュニケーションの場でも頭の中を整理して話することができるようになります。またうまくコミュニケーションを取れると自信にも繋がっていきます。コミュニケーションの練習には相手が必要かもしれませんが、ブログならその必要はありません。どんどんブログに自分の学んだことや考えをアウトプットしていき、コミュニケーション力を向上させましょう。 ブログの執筆する際のポイント 次にアウトプットする際に、気にしておくべきポイントを3つ上げます。はじめて記事を書く、もしくは書いたことはあるけどどんなことに気を付けて書いたらよいのかわからないという方の助けになれば幸いです。 ブログ執筆のポイント①1記事1テーマ まずは「一つの記事に一つの内容」を書くことです。 例えばC#のLinqに対しての記事を書いてるのに、その中に別の言語やテクニックの話を書いてると見づらくないですか？オブジェクト指向設計の単一責任の原則と同じです。大きくテーマが2つや3つになっていないかを確認し、もしテーマが複数になってしまった場合、1記事を1テーマとし複数記事に分けたほうがよいです。解決方法を探して検索してきた人からしても、そのような記事の方が見やすく非常に助かることが多いはずです。 ブログ執筆のポイント②自分の難易度で記事内容を狭めない 次に「これぐらいのことは簡単なことだから書かなくてもいいや」はやめましょう。自分にとっては簡単なことかもしれませんが、読み手にとってはとても需要のある内容かもしれません。過去に私は、Windows版のNode.jsをアンインストールするという話を短く書いたことがあります。アンインストールするだけなんですが、cacheフォルダが残ってると再インストールがうまくいかないことがありました。なのでアンインストールと合わせてフォルダを消す、といった簡単な内容で記事を書いたことがあるのですが、結構いろんな人が見てくれていました。私と同じように躓いた人の役に立てたということです。 得た知識が簡単だから無駄、なんてことはありません。 どんな些細なことでも恥ずかしがらずにどんどんアウトプットしていきましょう。 ブログ執筆のポイント③プラットフォームの選定 後は「どこに書くか」というのもポイントです。プラットフォームにはそれぞれの属性や特性があります。まずは自分の目的に沿って、書きやすい場所を選定し始めてみてください。 私ははじめて書いたのはQiitaでした。まだブログを書いたことがなくて足踏みしてるエンジニアにおすすめします。エディターも軽いしMarkdownも使えるので非常に書きやすいです。LGTM（いいね機能）やストックといった機能で読んでくれた人の反応がわかるのもモチベーションに繋げやすいです。 ブログを書くことが習慣化できたら、WordPressに挑戦してみてください。WordPressはCMS（コンテンツ・マネジメント・システム）と呼ばれるWebサイトを構築、管理、更新できるシステムです。自分で好きなように構築できるので、自分の色を出すことができます。サイト構築する際にHTMLやCSSなどWebの知識が少し必要になってくるので、勉強にもなって一石二鳥です。Markdownを使って書くこともできるので、Qiitaから移行するときのストレスも少ないです。 一方で、WordPressは手軽に利用できるシステムであるがゆえに、ハッカーなど悪意を持った攻撃者の対象になることも少なくありません。拡張性や自由度などの使いやすさに加えて、セキュリティ対策が手厚いWordPressを選択することをおすすめします。 では、どこで始めればいいんだろう、、、というそこのあなた。手前味噌で恐縮ですが、ConoHa WINGを使って始めてみてはいかがでしょうか。初心者でも10分で開設準備ができる機能があったり、先にお伝えしたセキュリティ対策も手厚く、安心して始められます。 最後に ブログ執筆習慣化してアウトプットする癖を付けていきましょう。 そうすることで、アウトプットする為に勉強したり試してみたりという良いサイクルが生まれます。エンジニアとして周囲と差をつけるために、是非ブログを活用してみてください。

2021年3月11日~12日にオンラインで開催された、日本最大級のクラウドネイティブ・テックカンファレンス。GMOインターネットグループはダイヤモンドスポンサーとして協賛しました！当日の様子と登壇セッションについて、そして例の幕間CMについてもお届けします。 イベント概要 日　　程：2021年3月11日（木）～12日（金）＋アーカイブ1か月間会　　場：オンライン主　　催：CloudNative Days Spring Committee参加費用：無料（事前登録制）公式ＨＰ：https://event.cloudnativedays.jp/cndo2021/ 登壇セッション 『決済システムにおけるクラウドネイティブへの挑戦』GMOペイメントゲートウェイ株式会社　三谷隆 GMOペイメントゲートウェイでは、24/365・高トラフィック・高セキュリティ・低レイテンシーが求められる決済システムにおいて、ここ数年でクラウドネイティブへ挑戦してきました。何を目指し、どんなことに気をかけて、何がキモであったのか。このセッションではそのアプローチ過程から得た教訓を紹介しました。▼ご視聴はこちらhttps://event.cloudnativedays.jp/cndo2021/talks/591 ▼スライドはこちら https://www.slideshare.net/GMODevelopers/cndo2021spring 『Docker/Kubernetes開発・運用のためにテスト駆動開発入門』GMOインターネット株式会社　元内柊也 DockerやKubernetesには、さまざまな方法でテストを行い最小のコストで各種設定や開発者が行う設定を抑える仕組みがいくつも存在しています。しかしながらこれらの仕組みを最大限活用するには知識が必要です。本セッションではDocker/Kubernetesの中でもプロダクトや個人で利用しているツールやその周辺知識について説明しました。 ▼ご視聴はこちらhttps://event.cloudnativedays.jp/cndo2021/talks/481 『マインド：計画と統制の文化にクラウドネイティブの種をまく』GMOペイメントゲートウェイ株式会社　駒井直 年間6兆円の決済を扱うGMOペイメントゲートウェイは20年以上成長し続けてきました。決済を取り巻く状況は急速に変化が進み、より広範囲な柔軟性が求められています。問題解決のアプローチとしてクラウドネイティブアーキテクチャに可能性を感じながらも現状の責任とリスクを考え、転換できていないという企業も多いのではないでしょうか。20年以上の成功体験を持つシステム組織の中に、クラウドネイティブな思想をどう種まきしたのか、経験を基にお話しました。 ▼ご視聴はこちらhttps://event.cloudnativedays.jp/cndo2021/talks/471 ▼GMOペイメントゲートウェイの登壇レポートはこちらhttps://www.gmo-pg.com/blog/article-016/ 『PGマルチペイメントサービス」のマイクロサービス移行計画』GMOペイメントゲートウェイ株式会社　佐久間洋明 GMOペイメントゲートウェイはクレジットカード決済やコンビニ決済など、さまざまな決済手段を通販・ECサイトなどに提供する「PGマルチペイメントサービス」を運営しています。開発スピードと安定性を求められる決済サービスで取り組んでいるモノリシックなレガシーアプリケーションのマイクロサービス移行計画についてお話しました。▼ご視聴はこちらhttps://event.cloudnativedays.jp/cndo2021/talks/541 『インフラ目線でみた、初めてコンテナでサービスをリリースする時のセキュリティポイント』GMOペイメントゲートウェイ株式会社　山崎牧彦 はじめてコンテナやクラウドサービスを使ったリリースをする方なら、誰もが「コンテナ×クラウドの利便性は分かったけど、いざ本番サービスで利用しようとするとセキュリティ面が不安…」と思うことでしょう。このセッションでは、初めてのコンテナ×クラウド技術を使った本番環境構築や外部機関の監査を受けた経験から、インフラ目線で事前に認識しておきたいセキュリティのポイントについて解説しました。▼ご視聴はこちらhttps://event.cloudnativedays.jp/cndo2021/talks/441▼GMOペイメントゲートウェイの登壇者レポートはこちらhttps://www.gmo-pg.com/blog/article-015/ 新CM初公開 GMO DevelopersのイメージWeb CM「まじめにベンチャー。まじめにギーク。」シリーズの最新作、『～まじめに語りすぎて筋トレしながら語る人編～』をCloudNative Days Spring 2021 ONLINE（CNDO）で初公開させていただきました。 https://youtu.be/NH3BB5PhR5A 今回、CNDOで幕間CMを放映するにあたり、クラウドネイティブ技術について多々登壇し、今回のイベントにも登壇しているGMOインターネットのインフラエンジニア、元内が主演を務めました。 本幕間CMはクリエイティブチームと協力し、企画・撮影・編集まですべて内製で制作しています。コロナ禍ではございますが、会社近くのスタジオで十分な距離を保ち、撮影に臨みました。 Twitterでも驚きのお声をいただきましたが、元内のジャンプ力は本物です。きちんと、事前にストレッチを行ってから望んでおりますので安心してご視聴ください。 ストレッチの様子 まだ見ていない方はこの機会にぜひご覧ください。リツイート・いいね大変喜びます！よろしくお願いします。 https://twitter.com/GMOdev/status/1369853084059410435?s=20 さいごに この度はCloudNative Days Spring 2021 ONLINEをご視聴いただき、またレポートをお読みいただきありがとうございました。 またみなさまと次のイベントでお会いできるのを楽しみにしております！

　Microsoft365で利用可能なRPA「Power Automate」と、デスクトップの操作を自動化することのできるRPA「Power Automate Desktop」をこれまで紹介してきました。どちらも自動化を担うロボットを「フロー」と言います。「Power Automate」は数多くのクラウドサービスを組み合わせて自動化を実現するので“クラウドフロー”と呼ばれます。「Power Automate Desktop」はデスクトップ上の操作の自動化を実現するので“デスクトップフロー”と呼ばれます。さらに、Microsoft365では“クラウドフロー”と“デスクトップフロー”を組み合わせた“ハイブリッドフロー”の作成も可能です。これら3種類のフローの開発方法を順次紹介してゆきます。 クラウドフロー まずはクラウドフローを開発してみましょう。フローの内容は以下のステップになります。 Microsoft365のメールに添付ファイルがあった場合↓添付ファイルをGoogleドライブに保存↓ファイル名をTwitterにツイートする Microsoft365のクラウドサービスだけではなく、外部のクラウドサービスとも連携できるのがポイントです。それでは始めましょう。 Microsoft365のポータルサイトにログインし、「Power Automate」を選択します。 「作成」を選択します。 フローの実行タイミングは“メール受信したとき”となるので、「自動化したクラウドフロー」を選択します。 フロー名やトリガーは後程設定するので、ここでは「スキップ」を選択します。 フロー実行のきっかけとなる「トリガー」を選択します。 “メールが届いたとき”をトリガーとするので、「Office 365 Outlook」を選択して、関連するトリガー一覧を表示します。 トリガー一覧から「新しいメールが届いたとき」を選択します。 最初のステップがフローに追加されました。 「新しいメールが届いたとき」というすべてのイベントに対してフローを実行してもよいのですが、今回は添付ファイルがあったメールのみに限定するので、「詳細オプションを表示する」を選択します。 「添付ファイル付きのみ」で“はい”を選択します。 次のステップを追加します。「新しいステップ」を選択します。 アクション一覧から「コントロール」を選択します。 コントロール一覧から「Apply to each」を選択します。 「Apply to each」コントロールは、届いた添付ファイル付きメールすべてに対してアクションを実行するためのコントロールになります。 「以前の手順から出力を選択」をクリックすると、直前のステップに追加した「新しいメールが届いたとき」から受け取れる情報一覧が表示されます。今回はメールの添付ファイルを操作するので一番最後に表示されている「添付ファイル」を選択します。 次に「アクションの追加」を選択します。 アクションとして追加したいのは「Googleドライブにファイルを保存する」となるので、まずはgoogleで検索して絞り込みます。ファイルの保存＝ファイルの作成となるのでアクションから「ファイルの作成」を選択します。 「サインイン」を選択してGoogleドライブの認証情報を入力します。一度登録した接続情報は左メニューの「データ」-「接続」に保存され、以後再利用できるようになっています。 「サインイン」を選択してGoogleドライブの認証情報を入力します。一度登録した接続情報は左メニューの「データ」-「接続」に保存され、以後再利用できるようになっています。 「フォルダーパス」にはGoogleドライブ内にフォルダーを作成して保存する場合にフォルダー名を設定します。 「ファイルコンテンツ」はGoogleドライブに保存するファイルの中身となるので、「添付ファイルコンテンツ」を選択して添付ファイルそのものを指定します。 次にTwitterにメッセージを投稿するステップを追加します。 「アクションの追加」を選択して、Twitterの検索一覧から、「ツイートの投稿」アクションを選択します。 Twitterの認証情報を入力します。 ツイートする内容は添付ファイル名とします。 ここまで作成できたら「保存」を選択してフローを保存しておきます。 “新しいメールが届いたとき (V3) -> Apply to each,ファイルの作成,ツイートの投稿”という名前で保存されますので、こちらを選択するとフローの名前が変更できます。今回は“CloudFlow01”としておきます。 以上でクラウドフローの開発が完了しました。 クラウドフローのテスト さっそくテストをしてみましょう。画面右上の「テスト」を選択します。 手動でテストを実行します。 テスト実行中は待機状態となります。 フローのトリガーは「受信したメールに添付ファイルがあるとき」となっているので、テストでMicrosoft365のアカウント宛てに添付ファイル付きのメールを送信します。 Web版のOutlookで自分宛てにファイル“memo.txt”を添付したメールを送信します。 メールを受信しました。 待機状態のフローが起動して問題なく実行されました。 Googleドライブを確認すると、CloudFlow01というフォルダーが作成されその中に添付ファイル“memo.txt”が保存されています。 Twitterに添付ファイル名がツイートされています。 マイフローから作成したフローの詳細や実行履歴が確認できます。 今回作成したフローは、トリガーとして添付ファイル付きメールを受信したときに起動します。手動でテストする以外にも、開発が完了した段階でこのフローは自動的に起動されるようになっています。 以上、Power Automateによるクラウドフローの開発方法を紹介しました。Microsoft365で提供されているサービスだけではなく、他のクラウドサービスとも簡単に連携できるRPAが開発可能ということが確認できたかと思います。 次回はPower Automate Desktopによるデスクトップフローの開発方法を紹介します。

部門のWeb制作に関わるメンバー向けの勉強会でコンテナ技術について解説しました。コンテナはDockerを含めポピュラーな技術ですが、参加者はほぼ未経験者でした。未経験者向けの説明が必要で話が発散しやすく時間配分も重要でした。詳細をこちらでご紹介します。 はじめに こんにちは、GMOインターネット株式会社の斉藤です。 先日、部門内のWeb制作に関わるメンバー向けのコンテナ技術の勉強会を主催しました。コンテナ技術というとDockerを始めとしてとてもポピュラーな技術ですし、社内/社外問わず参加したことのあるエンジニアの方も多いのではないでしょうか。 今回、社内で開催した勉強会では、コンテナについてほぼ未経験のメンバーが多く参加しました。勉強会の中でも「未経験者向け」と言うのは難しいものです。参加者に前提知識が少ないので、本来説明したい内容に加えてそれを補足する説明が必要になるからです。通常の勉強会に加えて話が発散しやすいですし、時間の配分にも気を配る必要があります。 この記事では、 勉強会開催に当たってどんなことを考慮に入れたのか私が実施したプレゼン資料の解説その後のメンバーとのディスカッション内容今回の勉強会のポイント を皆様に共有します。そしてこの記事が社内勉強会の1つのユースケースとして、エンジニアの方やプレゼンターの方の参考になることを期待しています。 勉強会開催に当たって 私が所属している事業統括本部 Webプロモーション研究室は、GMOインターネットグループの商材のコンテンツを制作している部門です。コンテンツというのはWebサイトはもちろん、動画の撮影や編集、印刷物のデザインなどで、すべて部門内のクリエイターが制作しています。商材というのはいくつかありますが、お名前.com、GMOとくとくBB、ConoHaなどのサービスは、ご存じの方もいらっしゃるかもしれませんね。 ここ最近、こういった社内のWebサイトの運用環境をコンテナベースに移行するプロジェクトが進んでいました。当然我々もコンテナを運用していくことになります。そこで、勉強会を開催することでメンバーの知識のベースアップを計ろうと考えたのです。参加者は主にWeb制作に関わるメンバーで、いわゆるWebデザイナー、Webディレクター、フロントエンドエンジニアと言った役割を担っているメンバーを対象としました。 このWeb制作系のメンバーはそれぞれが異なるスキルセットを持っており、それもなかなかに幅広いのです。HTML、CSS、PHP、JavaScriptあたりは当たり前に書きますし、PHPが得意な人、JavaScriptならまかせろな人、HTML+CSSでデザインをすぐ起こせる人、CSSだけでカッコイイアニメーションを作れる人など得意分野もさまざまです。多くの人は複数のスキルを持っていますが、一方ですべてにおいてその仕組みまで理解でしているわけではありません。たとえばPHPに関して、自分で一からLinuxにWebサーバとphp-fpmをインストールして環境構築ができる人もいれば、PHPは書けるけど環境構築はできないメンバーもいます。 さまざまな商材の色々な種類のコンテンツを作るので、メンバーのスキルも多様なんですね。多様性は素晴らしいことです。しかしコンテナを理解するに当たって、環境構築ができる人とそうでない人の差は大きいです。これは一言で言うとDockerfileを書くための前提知識の有無で、コンテナを作るに当たってなぜ実行環境まで知っておく必要があるのか、勉強会ではそこから説明をする必要があります。 そしてLinuxスキルについても触れておきます。LinuxについてOSレベルで理解できているメンバー（=rootで作業して問題ない人）は限られていて、いわゆるインフラエンジニアのようなコマンドライン操作の経験を持つメンバーは少ないです。普段は決まったコマンドしか叩かないというメンバーもいます。ここの理解はコンテナの仕組みや動作の話をする際に重要になります。前者の人は仮想マシンとコンテナの違いを理解できますが、後者のメンバーにはコンテナの説明の前にOSとミドルウェアがどう動いているのか、そこから解説をする必要があるでしょう。 さて、勉強会の時間は1時間半程度でした。なので、 ・プレゼンテーションパート（私） ・ディスカッションパート（全員） という2パートに分けることにしました。勉強会の趣旨は「コンテナに関する知識のベースアップを図る」なので、それをプレゼンテーションパートで行います。次のディスカッションパートでは、コンテナの導入について懸念や不安点、ほかにプレゼンテーションパートの内容を皆で話し合うこととしました。これにより疑問点をその場で共有、解決し理解を深めることが期待できます。 私が作ったプレゼンパートの資料は以下です(社内向け資料なので、一部機密事項に該当する部分は削除してあります)。見出しごとにポイント解説していきます。 プレゼン資料の概要 https://speakerdeck.com/hironobu/kontenafalseji-chu プレゼン資料(タイトルをクリックするとSpeakerdeckで開きます) プレゼンテーションパートのゴールとして、参加者が「コンテナ」と聞いたときに、どんなものか、何ができるのかイメージが付くようになってもらいたいと考えました。時間も限られていますし、未経験者の人がイメージできることろまでいければ十分な成果でしょう。その後は参加者各位の技術レベルに応じて、コンテナの技術的な仕組みについて理解してくれれば良いと考えました。 イメージを持ってもらうためには、より具体的な話をした方がイメージが付きやすいです。なので社内のコンテナ環境では今のところDockerしか使わないので、Dockerを前提に話すこととしました。技術者としてはコンテナの低レイヤーから説明するアプローチをとりたいのですが、それは避けようと考えました。よくある「同じOSカーネルの上で特定のプロセスが隔離されコンテナとして動いている」のような話は、カーネルやプロセスなどの用語を理解していないと伝わらないからです。 「コンテナとは何ぞや」 まず「コンテナとは何ぞや」を話しますが、参加者が具体的にイメージが付きやすいものを出して説明するのが良さそうです。つまりコンテナは何でできているのか、コンテナの中には何が含まれているのかです。今回の参加者はWebサイト制作に関わっているので、WebサイトがHTMLファイルやPHPファイル、アセットファイル（画像・JavaScript・ フォントetc）で構成されていることは知っています。なので「Webサイトを構成しているファイルとそれを動かすPHPとかの環境をまとめたものが（結果として）コンテナの実体にある」という説明になりました。 そして次にコンテナは環境を変えても動作することを説明します。パッケージ化されていると言う説明をすでにしたので、そのまま他の環境に移しても同じ動きをするのは理解しやすいところです。これでコンテナのポータビリティを説明したことになります。 最後にメンバーは普段から仮想マシンに触れているため、これとコンテナは別物であることを強調しておきました。技術的な差異も説明しましたが、この後詳しく話すのでひとまず「ベツモノである」ということを押さえておいてもらいました。 メリット1 メリット2 メリット3 コンテナのイメージが付いたところでメリットの解説をしますが、参加者の属性を考えWeb開発者側から見たメリットにポイントを絞りました。ポイントを絞るのも話を具体的にしてイメージを付きやすくするためです。 メリット2のスライドは弊社の元内が作成したスライドからの引用ですが、「アプリケーションを正しく配置する」というのは理解しやすい良いフレーズです。Web開発者であれば外部ライブラリのバージョン依存やプロジェクトの環境違い（Production/Development）で失敗したことは必ずありますからね。コンテナはそれらを解決する1つの方法であると言うシナリオは理解しやすいはずです。 1ページ目で参加者にコンテナについてのイメージを持ってもらいましたが、それをより掘り下げるパートです。ここでアプリケーション、ミドルウェア/ライブラリ、コンテナランタイム、OSカーネルの関係を説明します。ここでも実際のWebサイトを例に使うことで参加者にイメージを持ってもらいやすくしました。 ここまで来るとようやくコンテナの技術的な仕組みや仮想マシンとコンテナの違いが説明できるようになります。そしてWebサーバー、データベース、キャッシュなどの役割毎にコンテナを分ける運用についても理解してもらえるようになります。ただ、それらは次回以降の勉強会に持ち越しとしました。 ディスカッションパート プレゼンテーションの後のディスカッションパートでは、事前にヒヤリングするなどして作った想定質問をスライドに載せておきました。単純に質問を募るより、より話し合いがしやすくなります。 ディスカッション項目 残念ながら社内の業務に関わるConfidentialな内容が多くなってしまい紹介できる部分が少なくなってしまいましたが、一部抜き出してご紹介しましょう。 「そもそもコンテナは必要なのか？今までの環境で問題なかった」という本質的な疑問を持っているメンバーは多い ・複雑になるしそれだけの費用対効果はあるの？ 全員がPHPのバージョンを気にしたりやモジュールをインストールするところから始めるの？ 新しいことをやるに当たってどこにモチベーションを持てば良いのかはっきりさせるべき 最初は不便な状態かもしれないけど、それが将来的に続かない(改善していく)ことが保証されていることは大事 開発にはどんなメリットがあるかな？ コンテナを戻すだけなのでロールバックしやすいのは良かった いま社内でセキュリティ監査や脆弱性の診断の重要性が上がっていてコンテナ化すればやりやすくなる(らしい) でもデプロイ遅いよね 検証環境を作りながらいろいろ試したら既存の環境よりデプロイに時間がかかることが分かった。 デプロイ速度が落ちる→障害対応などで対応が遅れる→プロダクトの品質に関わってくる→まずいよね コンテナ化するならそういうもの？ ちがう。コンテナの作り方に工夫が必要 「コンテナのサイズが大きいと時間がかかる」のように漠然と問題を捉えがち ちゃんと問題の本質を理解していこう Dockerfileのセオリーなどを勉強しよう。 コンテンツの開発側とコンテナ基板の開発運用側でそれぞれ考えていることも違う 意識は合わせていこう 「開発環境から全てコンテナにしてシームレスにデプロイまで」みたいになれば理想 未経験者向け勉強会のポイント 未経験者向けの勉強会では、参加者がトピックに対して前提となる知識や基本的な理解が足りていないケースがままあります。この状態で専門的な話をしてもまず伝わりません。今回の場合はいきなりコンテナの技術的な説明や概念を説明するのは良くないアプローチになります。Dockerの公式サイトにあるような解説は、よく見かけますがある程度の技術レベルが無いと読めないのです。 こういうときには「参加者がすでに持っている知識」を利用するのが1つの良いアイデアです。参加者がすでに知っていることを利用し、新しいトピックに対して頭の中で具体的なイメージを作ってもらうのです。そうすることで解説がとてもやりやすくなります。 どういうことかというと、今回の勉強会では参加者はWeb開発者なので、現場のWebサイトを利用した説明をし、「Webサイトを構成しているファイルと、それを動かすPHPとかの環境をまとめたものがコンテナの実体である」と参加者にまずコンテナの具体的なイメージを作ってもらいました。技術的に多少荒い説明ですが、この「イメージを作ってもらう」ことが大切です。一度イメージができてしまえば、あとはそのイメージを膨らませていく方向で解説をすすめられます。実際の勉強会ではここから「アプリケーションを正しく配置することの重要性」を説明しました。開発者の多くはデプロイに失敗してトラブルになった経験を持っているでしょうから、理解しやすいと考えられます。その次に「コンテナが環境を変えても動作すること」などの説明につなげました。開発者は環境依存の問題についても経験を持っていることが多いと思います。そして最終的に「コンテナ技術とは何か」「コンテナを導入するメリット」というテーマにつなげることができました。 ディスカッションパートで事前にヒヤリングをかけて想定質問を用意したのも同じ理由です。ヒヤリングするということは「参加者が持っている知識」を事前に把握することです。それらをスライド1枚にまとめ、表示しながらディスカッションを実施します。「今日はじめて聞いたトピックでのディスカッション」となると普通参加者は緊張しますが、自分の知っていることが画面に出ているだけで参加者の緊張を大分和らげることができます。 と色々ポイントを書いてみましたが、「参加者がすでに持っている知識を利用する」というのはそんなに難しい話ではないのです。初対面のまったく面識のない人といきなり話すのは結構大変ですよね。でもたまたま共通の話題があったりするだけで、ずいぶん話しやすくなるじゃないですか。あれと同じです。 終わりに 現在は本番環境でのコンテナ運用を開始していて安定的に運用ができています。勉強会で出たデプロイに時間がかかるなどの問題についても、その後改善案も出て解消される見通しです。参加者もコンテナの運用に徐々に慣れて行っているようです。 最後までお読みいただきありがとうございました。