技術情報 の記事一覧

こんにちは。GMOインターネットの中村です。本エントリーでは、GMOインターネットが福岡にデータセンターを作ることになった件について紹介させていただきます そもそもデータセンターとは？ データセンターについてみなさんご存知でしょうか。データセンターとは、一言で言えば下記のようなものです。 各種のコンピュータやデータ通信などの装置を設置・運用することに特化した施設の総称。wikipediaより これだけではイメージしにくいと思うので、弊社の実際のデータセンターの画像を何枚か掲載します。写真を見ていただけるとサーバー（コンピューター）がぎっしり詰まっていることがお分かりいただけると思います。 このデータセンター施設で弊社のサービスが多く動いています。 not建築 今回のタイトルである【福岡にデータセンターを作ることになった話】ですが、字面で見ると新たに建設したように捉えることも出来ますが、実は新規建設したわけではありません… 正確には、【福岡（で施設を借りて）にデータセンター（の拠点）を作ることになった話】です。 なぜ福岡に？ 大きく分けて下記の３つの理由があります。 １．災害対策 弊社では色々なサービス展開をしています。サービスに共通していることは、大きな災害があろうとも止まってはいけないということです。 たとえばですが、近距離にデータセンター拠点が集中していた場合大きな災害があった際にはサービス継続ができなくなる可能性が高くなります。 具体的には、以下左のように密集した場所に拠点が集中している場合のことを指します。そういった観点で、右のように全国各地にデータセンター拠点を分散させることが、災害対策として望ましいのです。 ※上記拠点は実際のデータセンター所在地ではありません ２．選択肢を広げる 当然ですが、規模や期間、設備など様々な要因でかかるコストは変わってきます。地域やデータセンター運営会社によっても特色があるので、求めている用件に合うデータセンターの選択肢を広げることが大切です。 今回の福岡データセンターでは、他のデータセンターよりも最大電力が多く使えるという特色があります。 昨今は機械学習やマイニングなどの、電力を多く使う高火力なサーバーの需要が上がっており、この特色が求めるものとマッチしています。 ３．北九州拠点でのインフラ開発体制の確立 私が勤務しているのは北九州拠点（以下GMO kitaQ）とよばれるところです。 発足が2018年4月1日とまだまだ新しい組織で、平均年齢が若く、物理的なインフラに携わったことのある人が少ないのが現状ですが、設立においては他拠点の経験豊富なパートナーからレクチャーを受け、拠点としてインフラ方面でも安定した開発運用ができる組織になっていくとう中長期的な目的があります。 ※発足当時の記事https://prtimes.jp/main/html/rd/p/000002393.000000136.html 他にもある福岡データセンターのメリット 主な理由は先程あげた3点になります。 更にいろいろなメリットをお話したいのですが、残念ながら話すことができません…というのもデータセンターは基本的にセキュリティレベルが高く、住所なども非公開となっています。そのため、これ以上の場所が特定できるような情報をお伝えすることが出来ないのです…。 直接お話できればもう少しお話できる内容もあるので、もし会った際はお声掛けください。 DCの現状 現在、いろいろなサービスを動かすため、サーバーの設置作業から開始しています。 福岡で働きたい方募集！ GMO kitaQではエンジニアを募集しています。もし、もっとデータセンターのことを知りたいなと感じた方は、是非下記のページをご覧いただければ幸いです。 https://recruit.gmo.jp/locations/kitakyushu/ さいごに 本エントリーで執筆した内容について、昨年オンラインで開催されたGMO Developers Day2021にて登壇いたしました。お時間がある方はぜひアーカイブもチェックしてくださいね！ https://www.youtube.com/watch?v=y2_jjmQclFQ&list=PL-nSubl7UrR4GYfl4mbwdX7iuY_d-BOV7&index=21

こんにちは、GMOインターネット長谷川です。今回は昨年2021/11/26に開催されたGMO Developers Night CloudNativeLT＆座談会で紹介した、AWX APIの実際の仕様等をより詳しくお伝えしていこうと思います。 https://developers.gmo.jp/12531/ 今回お話する部分 AWX APIではInventory登録、Job登録（playbook登録）、workflow登録など様々な処理を行えるAPIがありますが今回はJob登録の自動化に絞ってお伝えしていきます。 AWXとは AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.引用元 : https://github.com/ansible/awx 簡単に言えば、web画面＆APIの付いたAnsibleの管理、実行環境ということです。 AWXで解決したい課題 実行時のオペレーション登録時の負担 大きく上記の2つです。1つずつ説明していきます。 実行時のオペレーション 業務で実際にAnsibleを使った自動化を行うと、playbookの作成者と実行者が異なる場合があります。 playbookのアップデートが適切に実行者のplaybookに反映されていない。複数のパラメータを付けて実行する必要がある。 このような場合にはオペレーションによって異なった設定が入ってしまう可能性があります。 登録時の負担 業務では年間数百を超えるplaybookをAWXに登録場面があります。その際にいくつもの設定項目を人間が埋めていくのは現実的ではありませんし、ミスも発生する可能性があります。 上記の課題はAPIによる登録の自動化とAWXに統一された実行環境を提供することで解決できます。 AWXのAPIを早速使っていきましょう（準備体操） まずはtokenの取得を行います。取得方法としてはawx-cliでも取れますが、ここはシンプルにcurlで取得していきます。 USER、PASSWORD、IPは適宜変えていきましょう。 curl -ku USER:PASSWORD -H "Content-Type: application/json" \ -X POST -d '{"description":"AWX", "application":null, "scope":"write"}' \ http://IP/api/v2/users/1/personal_tokens/ | jq -r .token API経由でJob登録 ここからはPythonを使って登録作業の自動化を進めていきます。 import requests import pprint import json ENDPOINT = "http://***.***.***.***" TOKEN = "***" def createJobTemplate(endpoint, token): headers = { "User-agent": "python-awx-client", "Content-Type": "application/json", "Authorization": "Bearer {}".format(token) } uri = str(endpoint) + "/api/v2/job_templates/" payloads = { # ここから下のask_*はGUIでJob実行を起動した際に # 起動プロンプトとして起動させるかを設定します "ask_job_type_on_launch": "true", "ask_scm_branch_on_launch": "false", "ask_diff_mode_on_launch": "false", "ask_variables_on_launch": "false", "ask_limit_on_launch": "false", "ask_tags_on_launch": "false", "ask_skip_tags_on_launch": "false", "ask_verbosity_on_launch": "false", "ask_inventory_on_launch": "false", "ask_credential_on_launch": "false", "survey_enabled": "false", # become（権限昇格可能）かどうかを設定します。 "become_enabled": "true", "diff_mode": "false", "allow_simultaneous": "false", # playbookで使用する仮想環境のパスを指定します。 "custom_virtualenv": "/opt/my-envs/custom-venv3/", "description": "VMの構築用playbook", # playbookの実行する際のInventoryをIDで指定します。 "inventory": 15, # 実行時のsliceを指定します。（同時実行数） "job_slice_count": 1, # 起動時のjob_typeの指定 # "run" -> 実行, "check" -> ドライラン "job_type": "check", # オーガナイゼーションのIDを指定します。 # defaultはID=1となります。 "organization": 1, # Jobテンプレートに名前を付けます "name": "[API]_CreateVM", # 登録するplaybookの場所を指定します。 "playbook": "module/playbook_vm_create.yaml", # AWXに同期済みのプロジェクトIDを指定（登録playbookのあるもの） "project": 22, # Git等のSCMでplaybook同期している場合はブランチの指定も出来ます。 "scm_branch": "master", "use_fact_cache": "true", "webhook_service": "", "webhook_credential": None, } requests.post(uri, data=json.dumps(payloads), headers=headers) createJobTemplate(ENDPOINT, TOKEN): 各パラメータについて詳しく説明していきます。 # ここから下のask_*はGUIでJob実行を起動した際に # 起動プロンプトとして起動させるかを設定します "ask_job_type_on_launch": "true", 運用的には人が行っている作業を徐々に自動化していくことも考えられ、人が操作する際に実行時のプロンプト起動は安全性という意味で付けています。実際に指定すると以下のように起動前にパラメータの変更が可能になります。 # playbookで使用する仮想環境のパスを指定します。 "custom_virtualenv": "/opt/my-envs/custom-venv3/", playbookの中には追加でpipによるパッケージのインストールが必要な場合もあり、仮想環境にパッケージを導入してplaybookを実行するよう指定する必要があります。AWXはAnsible Towerと互換性が有るので仮想環境の作成は以下が参考になります。https://docs.ansible.com/ansible-tower/3.4.3/html_ja/upgrade-migration-guide/virtualenv.html # playbookの実行する際のInventoryをIDで指定します。 "inventory": 15, ここではplaybookの実行時に使うInventoryをIDで指定しています。Inventory IDの取得は今回の記事では紹介していませんが、APIでの取得の自動化も可能なので是非お試しください。 # 登録するplaybookの場所を指定します。 "playbook": "module/playbook_vm_create.yaml", # AWXに同期済みのプロジェクトIDを指定（登録playbookのあるもの） "project": 22, # Git等のSCMでplaybook同期している場合はブランチの指定も出来ます。 "scm_branch": "master", "playbook"ではAWXに同期されたplaybookのパスを指定します。実行時に実際動作するplaybookの指定となります。"project"では同期済みのプロジェクトを指定します。プロジェクトが同期されているかどうかは左側のプロジェクトから確認できます。 "scm_branch"ではSCM等を使っている場合に、ブランチ指定ができます。テスト用のブランチにしかplaybookがないといった場合にも、ブランチ切り替えができるので便利な機能となっています。 まとめ AWXには様々なAPIがあり、組み合わせることにより自動化を促進出来るツールとなっています。まだまだAWX APIについての日本語の情報は少ないですが、この記事で興味を持って頂けましたら幸いです。

こんにちは。GMOインターネット新里です。iPhoneにはLiDARを使った3Dスキャンをしたり、フォトグラメトリという複数の写真から3Dを生成するアプリがあったりします。今回は、このアプリを使って遊んでみたいと思います。 とりあえずスキャンしてみる キャプチャー対象 - 東京タワー・外階段・下り・600階段 キャプチャー結果 : クリックするとPolyCamのサイトに飛びます 池袋・サンシャイン通り・ポスト キャプチャー結果 : クリックするとPolyCamのサイトに飛びます とりあえずiPhoneに3Dスキャンアプリ（ここではPolyCam）を入れて、スキャンしてきました。東京タワーのような巨大な物から、道端にあるポストのような物までスキャンすることができました。余談ですが、東京タワーは実際に階段を歩く必要があるので、体力的にかなり大変でした。 スキャンした3Dモデルは、データとしてエキスポートできて、XRのようなアプリケーションに組込んだり、3Dプリンターで印刷したり、メジャーで測定したり...色々と使うことができます。 アプリについては、色々な3Dスキャンアプリを説明されている素晴らしい内容があるので、そちらを参考にした方が良いでしょう。 3Dオブジェクトを配置してみる スキャンしたデータを使って本来は存在しない所に物を配置して、置いてみたときの状態を確認できます。よくあるのは、家具を置いて配置した感触を確かめたりするといった感じですね。 さきほどの池袋にあったポストを配置してみます。 配置前 配置後 何もない弊社オフィスフロアのエントランスに派手なポストを置いてみると、テンションがあがってきますね。僕自身はポストが好きという訳ではないのですが、ほかにも道端にあった赤いポストをスキャンして、GMOインターネットの本社があるセルリアンタワーの入り口に置いてみました。 配置前 配置後 シックな感じの入り口に、これはさすがにマッチしない感じがしますね。このように実際に物を置いてみるまえに確認する意味でも、既存の物を持って来られるというのは便利でおもしろいです。 世界を切り取ってみよう ここ数年で、手軽に3Dスキャンがスマホで出来るようになったのは凄まじい進化だと感じています。従来のようなToF/LiDAR/大量の写真でフォトグラメトリといった事が、手元のスマホだけで簡単に出来るので、いつでも自分のスマホから世界を切り取って使える時代になってきました。 みんキャプ "みんなで今を斬り撮って、保存して、共有して楽しむムーブメントです。" たくさんの人が手持ちのスマホで街や地域・建物を切り取ってデータ化すると、同じ街・世界ができるというのはとてもおもしろいですね。とても簡単に参加できるので、手持ちのスマホで参加してみても楽しいでしょう。 他にも、みんキャプのtoMapでも使える、PLATEAU（国土交通省が行っている、日本全国の3D歳モデルの整備・活用・オープンデータ化プロジェクト）のように、都市の3Dモデル化はデジタルツインを実現するため・おもしろいアプリやシミュレーションを行うといった用途では必要不可欠ですね。 自分の手持ちスマホでお手軽に3Dデータ化できるのは、それだけでも楽しいです。街を歩いていて気になった建物やオブジェを3D化したり、身の回りのありふれた風景に楽しみを発見するきっかけにもなるでしょう。

今回紹介するのは、Microsoftのクラウドネイティブな開発ツール「Power Apps」です。ローコード開発ツールとの位置づけですが、フルスクラッチなアプリケーションに負けず劣らずのアプリケーション開発が可能です。詳しい機能紹介などはひとまずスキップして、Power Appsの魅力を体感してもらうということで、いきなりアプリを開発してみたいと思います。 事前準備 開発するアプリはExcelファイルをデータ保存場所として、Power Appsのウィザード機能を利用して数ステップでデータ管理ができる機能を実装します。まずはOneDrive上にExcelファイルの用意をしておきます。 個人情報ジェネレーター（https://testdata.userlocal.jp/）を利用で、ダミーデータを作成して貼り付けます。 データはダミーです Power Appsで利用するためには、Excelでテーブル設定をしておく必要があります。「テーブルとして書式設定」を選択します。 データはダミーです 「先頭行をテーブルの見出しとして使用する」を選択します。 データはダミーです これでExcelの準備は完了です。 データはダミーです 次に、Power Appsを利用できるようにしておきます。Microsoft365のライセンスでも一部機能制限がありますが、Power Appsを利用することができます。検証用ということであれば、無料で利用できる「Power Apps 開発者向けプラン」（https://powerapps.microsoft.com/ja-jp/developerplan/）がおすすめです。 以上で準備が整いました。 いきなりアプリ では早速アプリを開発してみましょう。 Power Appsにログインしてホームページを開き「データから開始」の中から「Excel Online」を選択します。 「新しい接続」を選択します。 一覧から「OneDrive for Business」を選択してアカウント情報を入力して作成します。 先ほど準備したExcelファイルを指定します。 テーブルを選択して「接続」を選択します。 作成中です。 ウィザードが終了してアプリが作成されました。ウィザードを利用するとスマホレイアウト限定で作成されます。すでにこの状態で動くものとなっています。簡単に操作してみましょう。 画面右上の実行ボタンを選択します。 Webアプリケーションとしてブラウザ内で操作可能です。右上の✕ボタンを選択すると元に戻ります。アプリの上部には更新、並べ替え、新規追加ボタンが配置されています。 新規ボタン（+）を選択すると新しいデータ入力が可能となります。 一覧表示から個々のデータを選択すると詳細表示に切り替わります。ここでは削除と編集が可能です。 編集ボタンを選択すると、個々のデータが修正可能になります。 開発画面に戻って左のツリービューを確認してみましょう。 BrowseScreen1　DetailScreen1　EditScreen1　とそれぞれの画面が作成されています。ウィザーではよく利用されるアプリの画面を一度に3面作成して、各機能のボタンにプログラムを組み込んで配置しています。これだけでもかなりの部分の開発の手間を削減できていることになります。 各ボタンを選択してみると、プロパティーが表示され変更修正が可能です。ボタン自体にはプログラムとしてExcelの関数に似た数式で割り当てられた機能が仕込まれています。 さいごに 以上、Power Appsでいきなりアプリ開発を紹介しました。 Power Appsはローコード開発ツールという位置づけですが、ウィザードを利用すればノーコードで実際に動くアプリがほんの数分、数ステップの操作で完了してしまいます。初めてPower Appsで何か作ろうとした場合などは、このウィザードを利用してほぼ動く状態の物をカスタマイズする方が習得も早くお勧めです。次回は、ウィザードで完成したアプリを実際にカスタマイズしながら基本的な開発方法を紹介する予定です。

こんにちは。デベロッパーリレーションズチームの村上です。今回はチームの目標達成のために効果が高いと言われているマンダラチャートをやってみた話を書いていきます。興味のある方はぜひ読んでみてください。 はじめに 私のチームでは、コミュニケーションを円滑にする施策を各クォーターごとにメンバーに1つやってもらっています。それはゲームだったりワークショップだったりするのですが、そこでマンダラチャートという施策が出ました。通常マンダラチャートは個人の目標達成のためのものかなと思っていましたが、チームビルディングにも活用できるんじゃないかなと考え、チームのマンダラチャートを作成しようという考えに至りました。 マンダラチャートとは そもそもマンダラチャートとは目標達成するのためのフレームワークになります。9×9のマス目で構成され中心のマスに目標を記載し、それに関連する要素を周囲のマスにメモしていきます。野球の大谷選手の話が有名じゃないでしょうか。 出典：スポーツニッポン 目的・効果 必要な要素やアイデアを書き出すことで、目標を達成するための思考を整理することができます。またチームビルディングにおいてはみんなで考えながらやることで、コミュニケーションを取るきっかけにも繋がります。 実施タイミング チームビルディングにおいては、チームのコンディションを見ながら適切なタイミングで実施する必要があります。今回のマンダラチャートはタックマンモデルで言うところの「統一期」に実施するのが望ましいです。チームのメンバーの強みや役割が明確化されて、共通言語や同じ価値観が生まれてくるこの時期に、目標達成の為のフレームワークを用いることでタックマンモデルの次のステージに移行することができるようになります。※タックマンモデルとは、チームは4つの成長段階を経て成果が出せる状態になることを示したフレームワークです。 チームビルディングでマンダラチャートを使うメリット マンダラチャートを活用することで、様々なメリットを得ることができます。 目標達成のプロセスが明確になる 仕事をする上で目標を設定することは当然だと思いますが、目標達成までのプロセスが明確になっていないことが結構多いです。目標に対してどういう行動をすべきか、何を優先して取り組むかという点を考えるのは中々難しいです。マンダラチャートは最初に目標を中心のマスに書き、それを達成するために連想される言葉を書いていくので、目標に対してどういう行動を取ればいいかを適切に把握することができます。 チームメンバーのアイデア・考えを発見できる メインのマスから関連する言葉を記載していく過程で、メンバーから新しいアイデアや考えが出てくることがあります。周辺のマスを埋める際に、特に制約のようなものは作らないので、自分では思いつかないような考えやアイデアがメンバーから出てくることが期待できる点はメリットと言えるのではないでしょうか。 可視化することで後で見直すことが容易にできる マンダラチャートを作成しておけば適宜必要なタイミングで見直し、目標達成のためのアイデアや必要なアクションを取ることができます。また目先の業務に追われて、目標に対しての適切な行動や優先順位を忘れてしまうことがあると思いますが、可視化しておくことで立ち返ることや、行動を見直すきっかけになるので、継続して追いやすくなります。作成する際はシェアポイントや共有ドキュメントとして、いつでも確認しやすく管理しておくことをおすすめします。 マンダラチャートの作成方法 それではマンダラチャートの作成の基本的な流れを説明していきます。 3×3のマス目を作成して中心のマスに目標を記載する 中心マスに達成した目標を記載します。ここが重要な要素になるので、よく考えて設定してください。 目標に関連する言葉を周辺のマスに書き出す 中心マスの目標が決定したら、周辺マスに目標に対して関係しそうな言葉・アクションを書き出していきます。この部分は抽象的なものでも構わないので、しっかりとマスを埋めていきましょう。 周囲の3×3のマス目の中心に記載した言葉を写す 中心の周辺マスに書いた言葉・アクションを、周囲の3×3のマスの中心に書き写し、中心と同じように関係しそうな言葉・アクションを書き出していきます。ただしここに書く内容は達成する為に必要な具体的なものを書くようにしていきましょう。 チームでマンダラチャート では、実際に私のチームでマンダラチャートを作成した時の話です。なぜ今回のタイミングでマンダラチャートを行ったかというと、1年間かけてしっかりとコミュニケーションを取り、メンバーとの心理的安全性を高め、チームとして目指していく目標を立てるタイミングであったので、まさに今やるのに効果的だからと考えたからです。 実施した感想 ちょうど私を含め8人で書いてたので一人1マスずつ埋めていきました。本来であればもう少し悩みながら書くものだとは思いますが、今回は閃いたものを記載してもらうようにしました。真ん中の目標に関しては個人的にはちょっと抽象的かなと思いましたが、初めてやるのでこんな目標にしてみました。参加したメンバーからは以下のような感想・意見をもらいました。 目標達成に対して自分がどのように動けばいいか明確にできた目標に関連する単語は思い浮かぶけど、具体的にどうすればいいかを認識合わせできて良かった考える時間が短かったので、もう少し考える時間がほしかった 私自身もやってみた感じ、想定より効果がありそうな取り組みだと感じたので、この目標に対する言葉・アクションを見返すタイミングを作り、目標達成ができるチームビルディングを行っていきたいと思います。 メインの目標に関しては、複数持っても良いかなと思うので、事業に対しての取り組みのマンダラチャートや、もう少し細かい目標設定に対してもマンダラチャートを活用していければと考えています。 まとめ チームで作るマンダラチャートはタイミングを選ぶかとは思いますが、チーム全員が目標に向かって進んでいく為のフレームワークとしては非常に優れていると感じました。目標は立てるけど中々達成できないなという方は、ぜひチームでマンダラチャート作成してみてはいかがでしょうか？

こんにちは、GMO稲守です。Adam byGMOを8月にβ版リリースしました。多くの皆様のおかげです。改めてお礼申し上げます。現在は毎週いくつかの新機能や改修などをリリースしています。本記事では現在までのまとめをお届けしたいと思います。Adam by GMO：https://adam.jp/ Adam by GMOについて 本プロジェクトは今年の春頃から本格的な開発、実装が一気に進み、8月末にβ版をリリースしました。ブロックチェーンについては5～6年ほど前から実証実験や研究開発を行っており、コントラクトまわりの開発も計画通りに実装が進んだことを記憶しています。 開発コンセプトは『Eコマースのような、いままでのネットと同じインターフェースでNFT体験ができること』。実装においても、NFTのサイトでは一般的な暗号資産での決済だけでなく、既存のECサイトのような決済手段としてクレジットカードと銀行振込に対応しています。 プロダクトの特徴 複数の決済手段（クレカ、暗号資産、銀行振込）言語対応（日本語+多言語）マルチデバイス対応（PC、タブレット、スマホ）Eコマースライクなインターフェース出品審査を行っている安心なNFTマーケット 技術的な要素 ブロックチェーン Ethereum（Solidity） インフラ、構成管理 AWS、docker、GitHub Webアプリケーション、フロントエンド Node.js、React UI Adobe XD Ethereumを用いており、Openseaなどの海外の著名なマーケットプレイスで採用されているERC721に準拠しています。国産では初めて商用利用の実装ではないかと認識しています。またWeb側も上記の通りモダンな作りとなっています。 ERC721については少し古い記事ですが、こちらの記事などが参考になると思いますので、ご興味がある方はご一読ください。 ERC721 トークンとERC20 の交換（次世代システム研究室ブログ）https://recruit.gmo.jp/engineer/jisedai/blog/trade-erc721-erc20/ 現在のプロダクト状況 本プロジェクトは冒頭で書いた通り非常に短い期間で開発実装を行い、早い時期にローンチが出来ました。ローンチ以降はアクセスいただくお客様の増加とともに、日々の商いもありがたいことに活発になっています。直近では著名なアーティストに多く参画いただいており、今後も続々と新作が発表されるようで私自身も非常に楽しみにしています。 一方でまだNFTに関する国内での利活用事例、商慣習、法解釈など、様々な課題がありますが、NFTの可能性を肌で感じながら皆さんと笑顔になるための活動を引き続きできればと思います。これからも多くの方にNFTを身近に体験いただける環境を提供できるようチーム一丸で開発進捗しています。 さいごに 一緒にAdam byGMOを開発いただける仲間を募集しています。ご興味ある方はぜひ気軽にカジュアル面談はじめ、ご連絡いただけると嬉しいです。 https://recruit.gmo.jp/engineer/jisedai/entry/

SASSコンパイラをLibSassからDartSassに移行する経緯と手順について解説します。記事の中で注意点や名前空間の干渉の調整、除算の変更についても詳しく説明しているため、移行を考えている方やエラーに困っている方に参考になる内容です。詳細は下記をご確認ください。 要約 LibSassが公式で非推奨となったためDartSassへ移行名前空間の実装や除算の記法変更などに注意 経緯 Webプロモーション研究室のフロントエンドチームでは今までにSASS(SCSS）のコンパイルにLibSassを使用してきました。しかしLibSassが2020年10月から公式でも非推奨となったため、DartSassへの移行を順次進めることとなりました。 弊社採用サイト（recruit.gmo.jp）でDartSassへの移行作業を行いましたので、変更点や困ったことについてまとめます。 手順 1. gulpfile.jsでSCSSコンパイラをnode-sass(LibSass)からsass(dart-sass)に変更 上記画像の様にgulpfile内の記述を変更します。必要であれば適宜package.jsonの内容も変更し、npmモジュールをダウンロードします。 2. SCSSのディレクトリを整理 リセット用cssやmixinなど、基本的に編集しないファイルをscss/global/ディレクトリに移動します。今回は下記のようなディレクトリ構成にしました。 3. @importを適宜@use、@forwardに変更 @importをDartSassで使用される@useか@forwardに変更します。@useでは読み込み元で定義されているmixinや変数しか使用できないため、他のファイルで読み込まれるscss内では@forwardを使用します。 4. 各種ファイルに共通モジュールの読み込み文を追加 各種scssファイルでglobalディレクトリを読み込みます。今後各編集するscssファイルの中で@use　"../global";のように記述した場合、global内にあるmixinや変数は下記のようにglobal.といった名前区間を指定して使用することになります。 @include global.mixinName(); font-size: global.$font-big; また、 @use "../global" as *; のように記述することにより、特に他の記述を変更せず下記のようにmixinを読み込めるようになります。 font-size: $font-big; 今回はファイルごとの記述変更を最低限にするため、こちらの書き方で移行しました。 (番外)compassのリセット、mixinが使用されている箇所を書き換え 弊部署ではLibSassを使用し始める前、Compassでのコンパイルを行っていました。 LibSassへの移行時に、mixinを維持するためにCompassのスニペット(http://compass-style.org/reference/compass/css3/)を読み込むように変更された商材も多く、採用サイトの中でも一部使用している箇所がありました。Compassは導入当時ベンダープレフィックスの自動挿入等にも使用されていましたが、現在部内ではAutoprefixerを標準で使用しているためCompassに頼らなくても十分快適にコーディング出来るようになっています。 dart-sassで@importが廃止された結果、読み込まれているCompassスニペットすべての読み込み状況を確認する必要が生まれ、全ファイルで読み込みを確認・記述の変更を行うのがあまりに手間だったため今回採用サイト内での読み込み廃止となりました。使用されている箇所を確認したところ、リセットCSSと一部box-shadow、linear-gradientのベンダープレフィックス吸収用mixinしか使用されていなかったため、ライブラリ等の棚卸しは常に意識するべきでした…… 注意点 @useは条件付きネストの中に入れられない 弊部署ではレスポンシブ対応の際、下記画像のようにメディアごとにファイルを分け、style.css内でまとめてメディアクエリごとに読み込みという形式をとっているWebサイトが多くあります。 しかしDartSassでは条件付ネストの中で@useすることはできないため、 @media screen and (max-width: SP画面幅) { @import “sp/style”; } のような記述はエラー( Error: This at-rule is not allowed here. )になります。よって、sp/style内の各ファイルのコードを@media screen…で囲うことになります。 そのため上記画像のような構成に変更しました。手間的にはさほど大きなものではないのですが、もっとスマートな書き方がないか検討中です。 下記のようなmixinを各スタイルで読み込む形の方がDartSassにあっているかも知れません。 @mixin sp { @media (max-width: $maxWidth_sp) { @content; } } 名前空間の干渉の調整 “pc/style”と“sp/style”のように同じ名前のファイルを同時に@useしようとすると、There's already a module with namespace. というエラーになります。 下記のように名前空間を明示的に指定する必要があります。 scss機能の(x / y)除算が廃止 width: (x / y)px; LibSassでは上記のようにカッコとスラッシュで除算が可能でしたが、DartSassではスラッシュ記号が除算なのか・css用の区切り文字なのか(*)をコード上でわかりやすくするため使用できないよう変更されました。 // * 区切り文字としてスラッシュが使用される例： background: no-repeat center/80% url("../img/image.png"); DartSassでは除算にはmath.div(x, y)記法を使うようにとのことです。 mathモジュールを使用する場合使用するファイル先頭に下記の記述が必要です。 @use "sass:math"; css関数の calc(x, y) は変わらず使用可能です。 mash.divがしっくりこない場合、sassではなくcss関数のcalc(x/y)を使用すれば問題ないので、わかりやすい方が使用できればいいと思います。 個人的に移行するときはcalc()のほうが使い勝手が変わらず使用しやすいと感じました（calcがつくため、除算だということも判別しやすいです）。 おわりに DartSassを導入した際の手順・注意についてまとめました。 今回は既に運用されているWebサイトのコンパイラを移行したため、既存の記述ではエラーになるスタイルやmixinが多くありました。 すべてのSCSSファイルでコンパイルが通るか・Webページで表示崩れがないかの確認を行いましたが、常日頃のコードの棚卸しがいかに必要か実感しました。読み込まれていないスニペットファイルが多くあるとそれだけ確認・修正が長時間になります。 DartSassへの移行を考えている方、移行中のエラーで手間取っていらっしゃる方の一助となれば幸いです。

こんにちは、GMOインターネットの國分です。今回は2021年11月17日~20日、27日に実施されたHardeningイベントについて、魅力をお伝えできたらと思います。 はじめに Hardeningとはコンピューティングシステムのセキュリティを強化、堅牢化することの総称として使われ、今回参加のHardening　2021 Active faultでは仮想Webショップを経営側、インフラ側両方をロールプレイを行いながら、堅牢化を疑似体験するイベントが行われました。 実際のWebショップを触って作業するのは開催5日間のうち1日のみで、他日程についてどんなプログラムが展開されたのかなどをレポートいたします。 【参考サイト】https://wasforum.jp/hardening-project/ チームビルディング Hardeningイベントはチーム戦です。応募した人の中から運営側が6人～8人のチーム編成で割り振られます。約1か月前にチーム確定についてのメールが届き、ミッションが開始されました。 チームにもよりますが、大体イベント開催までの1カ月間で週1回～2回のミーティングを実施して、様々なミッションやイベントに向けた事前準備を行います。 TODO チームリーダー、福リーダーの選定チーム名の決定チームフラッグの作成（Zoom背景やロゴマーク）前回資料からの対策案策定経験者からの事前共有会稟議の書き方の勉強スキルマップの作成担当業務の割り振りマーケットプレイス購入品と落札額の決定インシデント対応フローの作成事前シミュレーション 比較的簡単なことから、時間がかかりそうなことまで事前に準備しなければならないものは、多岐にわたりとても1人ではやりきれないタスク量でした。 今回はオンライン開催だったこともあり、学生から社会人までの幅広い年齢層、かつ外国からも参加されている方もいらっしゃいました。そのため、チーム全員がMTGできる時間帯を合わせてミッションを行うのはとても大変でした。 欠席者が出た場合のフォロー、MTGの際の発言しやすい雰囲気づくり、このあたりがチームの一体感を生むために必要になってきたように感じます。 マーケットプレイスの活用 イベントの2日前には、マーケットプレイスの説明がありました。マーケットプレイスでは、オークション形式でセキュリティ製品を購入することができます。各ベンダーの皆さんがセキュリティ製品のプレゼンを行い、どのセキュリティ製品を獲得して、イベント当日に挑むかの参考になりました。 ※一部このプレゼンの前に提供される製品もありました。また、公式のマーケットプレイスには存在しない、ランサムウェア復旧サービスもありました。 FireWallWebAplicationFireWall(WAF)エンドポイントセキュリティセキュリティ情報サービスJPCERT/CC 前日準備 前日になるとサーバー構成図、ネットワーク図、ミッション、ルール等の情報が記載された資料が配られます。この日になって、やっとどんなOSやどんなサーバー構成なのかが判明するので、担当サーバーを決めたり、初動対応に必要な資料作成に入ります。 今回は前回参加者から事前に「こんなFirewallじゃない？」との共有をうけ、事前学習していたのですが、実際は予想のFireWallとは別のものが登場し急遽その対応方法を調査して、ルール投入方法とバックアップ方法を調査したり。また、接続に関しても特定のソフトウェアで接続テストしていたが別のソフトウェアに変更になったりと色々想定と違っていました。 前日にバタバタとせわしなく、多くの対応に追われながらイベント準備を進めていきました。 イベント当日 イベント当日の9時にはチーム全員がZoomに集合し、全員いることが確認されたチームから競技環境に入り、Hardeningが始まります。 サーバー担当 パスワードの変更各種バックアップ不審なファイルの調査、隔離、削除不審なプログラムの調査、停止FireWallの設定セキュリティ製品ベンダー対応インシデント調査、対応 Web担当 マーケットプレイスで購入した商品の稟議処理購買処理Webショップの修正在庫管理発送業務メール対応広報対応 イベント当日のランキングはYoutubeライブで配信されていますが、対応に追われなかなか見れない。 サーバーは24台、WebShopは4種類あり、7人のチームでしたが基本いつも人が足りない状態でした。それぞれのタスクを各人員が行っている中、Webショップは攻撃され、Webショップが止まったり、Webショップのページが改ざんされたりのインシデントが発生し、その対応を行うなか、「Web担当はインシデントの説明」、「サーバー担当は証跡の作成」を求められるので競技時間で与えられた8時間はあっという間に過ぎていきました。 Softening Day Softening Dayでは、Hardening当日に実施した内容発表する場と、攻撃側の種明かしの日になります。今回はオンラインとオフライン混合で行われ、発表の際に変身する人がいたり、独唱する人が居たりと、予想の上を行くおもしろい発表会でした。 各チームの対応を聞くことで自分たちに何が足りなかったのかも分かる場となっているので、自分たちが気が付かなかったり、見つけられなかったインシデントの内容が聴けるので、どのチームの発表も参考になります。 参加証明書も貰えます。※名前付きのものも別途貰えます。 さいごに 止めてはダメなWebShop、どうして増えないサブスクリプションの人数、IP直で来ないでよ攻撃者等々、イベント当日は色々ありましたが、振り返るとあっというまに時が過ぎていき、各人それぞれ何が足りないかを認識できる特別な時間になりました。インシデントの経験がない人は経験が積め、経験がある人はあの時できなかった対応が今回出来るぞと意気込めるそんなイベントです。セキュリティに興味がある人は経営側、システム側両方の対応が体験できるこのイベントは、どんなセキュリティ参考書よりも記憶に残り、これからの糧になるイベントだと思います。ちょっとでも興味を持ってくれたら、ぜひ参加して爪痕を残してくれればと思います。

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第４回のテーマは紙飛行機を使ったスクラムワークショップです。 シリーズ一覧 https://developers.gmo.jp/3750 https://developers.gmo.jp/5571 https://developers.gmo.jp/10479 ▻Vol.04_ｲﾏｺｺ https://developers.gmo.jp/13055 はじめに みなさんこんにちは。成瀬（@nrslib）です。 今回も前回と同様、レゴやマインクラフトを使った重厚なワークショップの前に行った、パイロット的なスクラムワークショップをご紹介します。ワークショップは2020年11月に実施したものです。 このワークショップで取り扱う題材は「紙飛行機」です。 本格的なスクラムワークショップをするために必要なこと スクラムを実践するにあたって、その全貌を把握しておくことはオンボーディングのスムーズさに寄与します。全貌を体験しながら実感に落とし込むのにワークショップはうってつけです。 そこでワークショップを企画するのは自然な流れですが、どういったワークショップを実施するかを考えなくてはいけません。 スクラムのワークショップはおおきくふたつのワークショップに分けられます。半日や１日といった長いスパンで行う本格的なワークショップと、１・２時間程度で終わる簡易的なワークショップです。 スクラムを実感に落とし込むためには、長いスパンで行う本格的なワークショップを実施すべきです。そこでいきなり本格的なワークショップを実施しようとすると、うまくいかない可能性があります。なぜなら本格的なワークショップを実践するためにもある程度の知識が必要だからです。そこで簡易的なワークショップの出番です。スクラムのワークショップは簡易的なものとはいえ、スクラムの重要な要素を部分的にカバーしています。参加者全員が何もわからない状態で本格的なワークショップを行うよりも、ある程度前知識として知っている部分がある状態のほうがスムーズにいくのは想像に難くありません。 今回は本格的なスクラムワークショップの前に実施した、簡易的なスクラムワークショップの紹介です。 気になるワークショップの題材は…… 紙飛行機です。 紙飛行機ワークショップ 今回紹介するワークショップはその名のとおり紙飛行機を使ったワークショップです。 前回のピンポンゲームに比べると、少しワークの内容が複雑で、くり返し改善していく流れが体感できます。 基本的な流れは下記記事を参考に行いました。 https://dev.classmethod.jp/articles/scrum-training-airframe/ ワークショップ概要 ワークショップではA4の紙から紙飛行機を作って飛ばします。そのうち３メートル以上飛んだものをポイントとして加算します。 もちろん、ただ紙飛行機を作って３メートル以上飛ばすだけではなく、いくつかのルールが存在します（まさか紙を丸めて３メートル放り投げるような人はいないでしょうが）。 ルール ワークショップでは紙飛行機を３メートル飛ばすのを目標としますが、いくつかの制限事項が存在します。 A4の紙を４つに切って使う紙飛行機の先端はハサミで丸くする一度折ったらほかのメンバーに渡す（連続で折らない）紙飛行機を飛ばすのは１回につき１機（まとめて飛ばさない）紙飛行機を飛ばすのは１機につき１回（同じ飛行機を何度も投げない）各スプリント終了時に作成物はすべて破棄する これらのうち特にキーとなるのは「一度折ったらほかのメンバーに渡す」といった点です。連続で折り紙を折れないのはあきらかに障害となるため、どのように対処するかはチームごとの色が出ます。 またこれらの制限事項以外に、次の制約があります。 紙飛行機は常識の範囲内の形状をしていること紙飛行機には人が乗っているものと意識すること 要するに、雑な作りで投げまくるのはやめたまえ、ということです。ソフトウェア開発者はすぐバグを見つけたがる……。 禁止事項 基本的には参加者は大人なので不要だとは考えましたが、一応禁止事項を用意しました。 ひとつめは検索の禁止です。開発者の強い味方であるインターネットの力は今回封印させていただきました。最初のスプリントは検索に費やして、残りで巻き返す、みたいなことはできません。 ふたつめは床や机に傷をつけないです。要するにA4を４つ切りにするために、紙を手に持ったまま切ってくれれば問題ありません。これは何らかの作戦を防ぎたいというわけではなく、あとで責任者の自分が怒られないように用意したものです。 準備するもの 紙飛行機を飛ばすことになるので準備物はそれなりにあります。 ハサミ（１チームにつきひとつ）ペン（１チームにつきひとつ）A4用紙（１チームにつき６０枚程度）マスキングテープメジャー マスキングテープやメジャーは飛行試験場を作るのに使います。 設備 設備に関しては基本的な会議室であれば問題ないです。 どちらかといえば、紙飛行機を飛ばす関係上、ある程度の広さが必要です。少なくとも３メートルの飛行場を作成できる広さとチーム数に応じて作業場を確保する必要があります。 私たちがどれくらいの広さを用意したかがわかる写真を載せておきます。 用意した会議室 テーブルはチームごとに用意してあります。椅子に関しては飛行試験の際などに邪魔になったりしそうなので撤去しています。 飛行場は写真の右手側、ジュリアン・オピー氏のアートの前です。写真だと狭く見えますが、別角度でもう一枚。 会議室を別角度から ３メートルの長さに加えて、ふたりが飛行試験をしてもぶつからない程度の広さを確保しています。 参加者 人数に関しては１チームにつき３・４名で、２チーム以上と用意できると競い合いになって盛り上がるでしょう。但し、前述のとおり、チーム数に応じて広さが求められるので、キャパシティには注意してください。 今回も前回と同様デヴェロッパータスクフォースのメンバーとシステム本部の若手に参加してもらいました。実はピンポンゲームを行った直後に紙飛行機ワークショップを実施したので、参加者は継続です。 ワークショップ解説 紙飛行機ワークショップもほかのワークショップと同じように、最初に参加者に趣旨やルールを説明します。 ワークの流れを開設する ワークショップでは次のスプリントを繰り返します。 計画をする（２分）成功機体の予想発表（１分×チーム数）※実行（３分）実績発表（１分×チーム数）※振り返り（２分）振り返り発表（１分×チーム数）※ ※マークのついた項目はチームそれぞれの状況を確認するための時間です。 今回のワークショップではこのスプリントを４回繰り返しました。バランス的にもちょうどいい回数だったと考えます。 各フェーズを詳しく確認していきましょう。 計画をする（２分） まず最初に、このスプリントの計画をします。 ハサミとA4用紙を前に議論 紙飛行機はひとりが連続で折れないという制約があるので、効率的に紙飛行機を作る方法を考える必要があります。また、それと同時に３メートル飛ぶという品質も担保しなくてはいけないので、ここでの計画は重要です。やみくもに作業をしてもうまくいかないのは目に見えています。 とはいえ、計画の時間は２分しかないため、議論が白熱しすぎるとまったく計画が決まらないまま終わってしまうこともあります。タイムボックスは重要な要素なので、たとえ議論が終わらなかったとしても慈悲はありません。次のフェーズに移行します。 成功機体の予想発表（１分×チーム数） 計画にしたがったら、チームごとにどれくらい３メートル飛ぶ飛行機を作れるか予想します。 スコア予測 初回に関しては予想の材料がないため適当になってしまいますが、２回目以降は実績に基づいて予想できます。 ちなみにチームは「NKHT」チームと「Internet for Everyone」チームです。 NKHTチーム NKHTチーム（以下NKHT）の由来はメンバの頭文字だと思います（もう１年以上前なのでうる覚え）。 Internet for Everyoneチーム Internet for Everyoneチーム（以下I4E）は前回からも続投（メンバは何人か違う）のコーポレートキャッチですね。 このタイミングで各チームの作戦についても聞いておきます。ここで作戦を聞いておく理由は、改めて認識させるというよりも、ワークショップ全体の振り返りをする際の材料にするためです。 実行（３分） 各チームが計画したことを実行します。制限時間は３分です。 計画の実行 いくつかの制限事項がありますが、実際のところ、厳密には監視をしていないので紳士協定です。みなさん大人ですからそれぐらいのゆるさでも大丈夫です。 できた紙飛行機は飛行試験場で試験飛行されます。 最高にフォームがきれいなIさん 紙飛行機を飛ばすのにもある程度のスキルが必要なので、チームの戦略によってはパイロット専任が誕生することもあります。 また紙飛行機を作って飛ばす以外にも、チームには重要なタスクがあります。それは、紙飛行機のカウントです。 紙飛行機のカウント このあと実績発表をするので、各チームは紙飛行機を作成した数と３メートル以上飛んだ数をカウントします。実はこのタスクは煩雑になりやすいので、チームごとに戦略が異なります。 実績発表（１分×チーム数） 実行の結果をチームごとに発表します。 実績を発表する 作成した数と試験飛行に成功した数を記録するので、効率に課題があるのか、品質に課題があるのかが一目瞭然です。 振り返り（２分） 実行や実績を受けて、各チームで振り返りをします。とはいえ、２分しかないため、KPTといったフレームワークではなく、今回のスプリントでの良かった点と問題点を共有しあう程度です。 振り返りの様子 振り返り発表（１分×チーム数） 各チームごとに振り返りの内容を発表してもらいます。ここでの発表も、作戦を聞くときと同じく、定点観測の意味を込めたものです。 既定の回数くり返す 規定回数スプリントをくり返します。最初のスプリントに比べると後半は動きやテクニックが洗練されていきます。 イベント ただ同じことを繰り返すのではそれこそルーチンワークのようになってしまいます。スクラム、ひいてはアジャイル開発は不確実なものをいかに御しながら価値を届けるかが主目的です。紙飛行機ワークショップでは不確実性をイベントで演出します。 具体的には３スプリント目で「制限事項をひとつ廃止できる」というイベントを発生させます。つまり、次のうちいずれかを無視できるということです。 A4の紙を４つに切って使う紙飛行機の先端はハサミで丸くする一度折ったらほかのメンバーに渡す（連続で折らない）紙飛行機を飛ばすのは１回につき１機（まとめて飛ばさない）紙飛行機を飛ばすのは１機につき１回（同じ飛行機を何度も投げない）各スプリント終了時に作成物はすべて破棄する どの制限事項を廃止できるのはチームで決めます。チームごとに特色がでて面白い部分ですね。 またこのイベントは１スプリントだけで、次のスプリントではもとに戻すのですが、そのことについては次のスプリントが始まるまで黙っておくとよいです。振り返りした内容が次のスプリントでは使えなくなるといった不確実性を演出できます。 ワークショップ全体の振り返り すべての行程が終わったらワークショップ全体を振り返り、総括します。 総括の様子 スプリントごとに各チームの計画や試行錯誤について振り返ると、改善の片りんを感じたり、このワークショップを通して学べたことを再確認できます。 ワークショップレポート ここからは開催したワークショップのレポートです。 最終スコア まずは結果を見てみましょう。 最終スコア 画像の「予」は予想を表し、「実（成／生）」は実績を表し、そのうち分母が生産機体数、分子が試験飛行成功数になっています。 結果を確認すると、いずれのチームも最初の数値が２回目３回目でだんだんと増加しているのがわかります。これは振り返りを行い、それを受けて計画をしているため、だんだんと改善されて行っている結果です。 同時に４スプリント目では数値が小さくなっているのにも気づきます。これは３スプリント目では制限事項をひとつ解除したのが、４スプリント目で復活した結果です。 生産機体数と試験飛行成功数の比率を見ると、チームごとの作戦が透けて見えますね。人が乗ってるという前提をI4Eはどう捉えていたのかは気になるところです。 各チームの流れ チームごとに各スプリントの計画や振り返り発表のメモがあったので、ここにまとめます。 NKHT まずは優等生が集うNKHTからです。 １スプリント 予測成功数５、実績３／４ ■計画 最初の１分は紙飛行機の作成に集中する役割をわける（切る人１、紙飛行機を折る２人、声出し（？）兼パイロット１）感覚値で５機はいけそう ■振り返り 飛行成功機体が３機だったので作戦はよかった ２スプリント 予測成功数５、実績５／７ ■計画 前回振り返りから基本は継続予定精度をあげたい ■振り返り 飛行成功数が伸びているし、精度も大きく落ちていないのでいい感じ ３スプリント 予測成功数１０、実績６／１３ ■計画 撤廃するルールは「一度折ったらほかのメンバーに渡す（連続で折らない）」 ■振り返り ルールが変わった結果、これまで折ったことがない二人が飛行機を折った初めて紙飛行機を折ったため手間取り、あまり生産数が伸びなかった ４スプリント 予測成功数８、実績９／１１ ■計画 ２スプリント目と同じ作戦に戻る ■振り返り 折り合いが熟練の動きだった熟練二人が折った紙飛行機は９機で失敗ゼロはじめて折り紙を折った二人は両方３メートル飛ばなかった 総評 スプリントを重ねるごとに着実に改善されていったチームでした。 役割分けが功を奏し、はじめから最後まで高品質な紙飛行機を生産し続けていました。特に後半、紙飛行機をずっと折っていた熟練工二人はまったく失敗なしで、時間があまったので初めて折った二人はひとつもテスト飛行が成功しないというエピソードは面白いです。ただ、スクラム的には、スキルレベルにばらつきがあると見積もりが難しくなるので、そういった点では課題はまだ存在します。 I4E 次は問題児独創的なアイデアマンが多いI4Eです。 １スプリント 予測成功数２、実績０／４ ■計画 正攻法で回す手渡し手渡しで紙飛行機を折っていく ■振り返り 毎回毎回回ってくる紙飛行機の状態が違う（折り方が変わる）綺麗に４等分した紙飛行機は３メートル飛ばない説 ２スプリント 予測成功数２、実績１／１４ ■計画 ４つに切って３つ捨てる（←？） ■振り返り コツがつかめたので次からはドライブしそう ３スプリント 予測成功数４、実績６／１１ ■計画 撤廃するルールは「A4の紙を４つに切って使う」 ■振り返り フローが減った結果、飛行機の形が同期できた ４スプリント 予測成功数４、実績５／３３ ■計画 A4用紙の端を縦に切って３つに切る（←？） ■振り返り ごみ捨て係ができた（←？）最後はみんなでごみ捨て 総評 質より量を選んだチームです。２スプリント目からあきらかに飛行機の生産数がおかしなことになっています。 紙飛行機作成風景も独特です。 紙飛行機作成風景？ 極めつけは４スプリント目では４枚に切って、３枚を捨てるという暴挙。作成した機体数３３というのは、８機はちゃんと追って、残りの２５機は紙飛行機の形を成していない切れ端ということです。最後のスプリントは２５機を捨てるテスト飛行するため、全員でぐるぐる机の周りを走り回ってきたのが印象的でした。 ……おかしいなぁ。「人が乗ってるつもりで飛ばしましょう」と伝えたんだけどなぁ……。 所感 このワークショップで学べることは次のとおりです。 タイムボックスベロシティプロセスの改善 各フェーズにおける制限時間を厳密にすることで、タイムボックスを守ることを体験できます。タイムボックスを意識しないと、特にミーティングなどはダラダラしてしまったり、関係のないメンバのリソースを奪うことになるのでとても大事なことです。 ベロシティは紙飛行機の数です。予測と実績を都度確認することで、ベロシティとしますが、本格的なスクラムからすると、ふわっとしたものなので、正直なところワークショップの肝ではありませんでした。 改善に関してはスプリントが進むごとに試行錯誤があってよいです。突発的な制限事項減少イベントにどのように対応するのか、その制限事項が復活したらどのように対応するのか、といった臨機応変な対応はまさに不確実性と向き合うものです。 このワークショップだけでスクラムを始めるには力不足です。本ワークショップの位置づけとして最適なのは本格的なワークショップの準備として実施するのがよいかと考えます。 本格的なワークショップは長時間に及ぶため、失敗したくないものです。本ワークショップでタイムボックスなどの基礎的な部分を経験しておくのは、前準備としてとても有効に働くでしょう。 おわりに 本ワークショップはピンポンゲームと同じく短時間で実施できます。したがって、ピンポンゲームと同じように新たなメンバーが加入した時などにレクリエーションとして実施してみても面白いです。 みなさんもぜひ童心にかえって、紙飛行機を折ってみませんか。 Vol1. スクラムワークショップ Vol.1 レゴ®編Vol2. スクラムワークショップ Vol.2 マインクラフト編Vol3. スクラムワークショップ Vol.3 ピンポンゲーム編Vol4. ｲﾏｺｺ

前回紹介したMicrosoft365の「承認」機能は標準機能としてTeamsから利用できるシンプルで使いやすいものとなっていました。さらに「承認」機能はPower Automateやその他のサービスを組み合わせることによってより複雑で高機能なワークフローを作成するができるようにもなっています。今回はPower Automateを使ったワークフローの開発方法を紹介します。 トリガーを利用して自動でワークフローを実行 　「承認」機能はTeamsで承認要求を作成して承認者に送るといった利用方法でしたが、Power Automateのトリガーと組み合わせて承認要求の作成自体も自動化して効率化することができます。 今回は、SharePointに承認を要するファイルがアップロードされたことをトリガーとして、承認用のワークフローを起動します。承認者が承認したタイミングで、その旨をTeamsで通知してSharePointに履歴として保存するといったワークフローを作成してゆきます。 SharePointの準備 まずは、SharePointの準備を整えましょう。ファイルをアップロードする場所と、承認履歴の保存用リストを作成しておきます。SharePointのサイトから作成しても利用できますが、簡単にTeamsのチーム用のSharePointを利用します。既存チームの「SharePointで開く」を選択します。 トリガーとなる承認を要するファイルはこのチームサイトのドキュメントにアップロードすることにします。 加えて承認の履歴保存用のリストを作成します。「新規」-「リスト」を選択します。 承認ログを保存するために、こちらの内容でリストを作成しておきます。 クラウドフローの作成 次にPower Automateの「自動化したクラウドフロー」から作成してゆきます。 “SharePoint”をキーワードに、「ファイルが作成されたとき（プロパティーのみ）」を選択します。 「サイトのアドレス」をクリックすると利用できるSharePointのサイトの一覧が候補として表示されます。先ほどのSharePointサイトを選択します。「ライブラリ名」と「フォルダー」を指定します。 「フォルダーID」はフォルダー一覧から“/Shared Documents/General”を選択します。これは、Teamsの“一般チャネル”のファイル保存場と同じ場所になります。SharePointにファイルをアップロードすることがトリガーとなりますが、TeamsのバックグランドがSharePointという特性を利用して、ここに承認に必要なファイルをアップロードしても自動的にワークフローを起動させることができます。 後で取得したファイル名を利用するので、動的なコンテンツ「ファイルが作成されたとき（プロパティーのみ）」から「拡張子付きのファイル名」を変数に格納しておきます。 承認のアクションから「開始して承認を待機」を追加します。 「承認/拒否　すべてのユーザーの承認が必要」を選択します。 「タイトル」を入力します。 「担当者」には承認を依頼するメンバーの名前もしくはメールアドレスを入力します。 「アイテムリンク」には動的なコンテンツ「ファイルが作成されたとき（プロパティーのみ）」のプロパティー一覧から「完全パス」を選択します。「要求元」には動的なコンテンツ「ファイルが作成されたとき（プロパティーのみ）」のプロパティー一覧から「登録者 Email」を選択します。 次に承認の可否によって分岐する処理を追加します。「新しいステップ」を選択して、コントロールから「条件」を選択します。 「値の選択」には動的なコンテンツ「開始して処理を待機」から「結果」を選択します。 「次の値に等しい」を選択して、「値の選択」に“Approve”と入力します。これで承認された場合、拒否された場合の分岐となります。 承認された場合、Teamsのアクションから「チャットまたはチャネルでメッセージを投稿する」を追加してメッセージを送ります。メッセージ内容には、先ほど変数に格納したファイル名も表示できるようにしておきます。 拒否された場合のメッセージも同様に作成します。 最後にSharePointのリストに承認履歴のログとして投稿しておきます。SharePointのアクションから「項目の作成」を選択します。 各項目を埋めてゆきます。 サイトのアドレス：SharePointサイトのURLを選択します。リスト名：作成したリスト名“承認ログ”を入力します。Title：動的なコンテンツ「開始して承認を待機」から「タイトル」を選択します。可否：動的なコンテンツ「開始して承認を待機」から「結果」を選択します。作成日：動的なコンテンツ「開始して承認を待機」から「依頼日」を選択します。承認日：動的なコンテンツ「開始して承認を待機」から「完了日」を選択します。申請者：動的なコンテンツ「ファイルが作成されたとき（プロパティーのみ）」から「登録者Display Name」を選択します。承認者：first(outputs（'開始して承認を待機）?['body/responses'])?['responder/displayName']　この式を入力します。 SharePointリストへの投稿内容の設定が完成しました。 テスト 早速テストしてみましょう。Teamsからファイルをアップロードします。 承認要求相手に通知が届きました。添付されたファイルを確認した後、承認します。 申請側にも承認された旨の通知が届きました。 Teamsにも承認されたとの通知が届いています。 SharePointのリストにも承認履歴が保存されました。 フォローの実行結果も問題ありません。　成功です！ フロー全体図 さいごに 以上、Microsoft365の「承認」機能を利用したワーフローの開発方法を紹介しました。簡易ツールとしての承認機能が、Power Automateと組み合わせることによって、高度なワークフローシステムに成長できました。 このように、Microsoft365のサービスはシステム連携が簡単にできるように設計されています。基本的な機能のみのツールから、より高機能なシステムへPower Automateでのローコード開発で短期間に手軽にバージョンアップが可能となっています。システム開発というこれまでの高いハードルをグンと下げることで、実務レベルの担当者でも必要なシステム開発が可能となります。是非お試しください。