UUUMエンジニアブログ

UUUMのエンジニアによる技術ブログです

MySQL DBインスタンス バージョンアップの進め方

みなさんこんにちは!UUUMシステムユニットの ぶち です。

桜の季節ですね。4月になり新しい環境に変わった方もいらっしゃるのではないでしょうか。 実はUUUMのサービスの中にも新しいバージョンに生まれ変わっていた DB がいました🌸

はじめに

少し遡り雪解の候、 MySQL のメジャーバージョンアップを実施しました。 具体的なオペレーションについては素晴らしい記事が世の中に多数ありました(大変お世話になりました)。

本記事では、実作業レベルの具体的なバージョンアップ手順については述べません。

サービス提供やステークホルダーとの擦り合わせなどの観点で実施した、周辺業務を主題に記載します。

対象の DB 環境

今回のバージョンアップ対象の環境について軽く触れておきます。

  • AWS RDS に構築している DBインスタンス
  • レプリカ無し
  • MySQL 5.6 から 5.7 へのアップグレード
  • アプリケーションのテストカバレッジは向上途中

事前に準備したもの

バージョンアップ情報ドキュメントの作成

作業全体像の把握と他メンバーへの共有を主目的として、バージョンアップ手順を作成しました。 最終的に把握した項目は以下の通りです。

DB について
  • バージョンアップ後に変更される仕様の概要
  • DB のみで必要なダウンタイム
  • 公式バージョンアップドキュメント等の情報
  • 事前構築すべきリソース( Parameter Group 等)
アプリについて
  • テストの必要な機能
バージョンアップオペレーションについて
  • バージョンアップ作業内容
  • 万一バージョンアップ失敗した場合の切り戻し
バージョンアップ後の注意事項について
  • 不要なリソースの処理(旧DBやオペレーション用に構築したものなど)
  • IaCの修正
  • モニタリング対応

この中で特に、「万一バージョンアップ失敗した場合の切り戻し」は大切だと感じています。 その理由は2点あります。

まず、当然のことですが、メンテ時間の延長はユーザーの予定を狂わせる可能性があります。 サービスの信頼性や継続性は事業を継続する上で非常に重要な要素です。

また、切り戻しが必要な場面に遭遇する時点で、既に想定外の事態と対面していることでしょう。 事前に準備しておけば、想定外の上さらに想定外のオペレーションを重ねず済みます。

勇気ある撤退の判断も視野に入れられるよう、可能な範囲で準備はしておきたいですね。

作業チェックリストの作成

正直手間がかかるため、チェックリストまではやらないケースも多い印象はあります。 ですが作成することで受けた恩恵があったため記載しておきます。

バージョンアップのオペレーションを、実作業レベルでスプレッドシートにリストアップしました。 実際に利用した項目(と作業サンプル)を以下に記載します。

実施チェック 手順No. 概要 予定開始時刻 備考欄
ぶち 1 Terraformからメンテイン 18:00 -
ぶち 2 DBスナップショット取得 18:05 -

特に「実施チェック」と「予定開始時刻」は記載して良かったです。

「実施チェック」は、作業分解することのメリットがありました。 まず各メンバーに分担できるレベルに落とし込むため、作業が明確になります。 また分担の結果全員が作業者として関わることになるため、事前の打ち合わせを同じ目線で細かく議論することができました。

「予定開始時刻」は、タイムマネジメントと実績としてのメリットがありました。 現在の作業が予定時刻に対してどの程度順調か理解できる上、今後類似作業が生じた際の参考値になります。

もし次回があれば、実績の精度を上げるため「作業完了時刻」を追加してもいいかもしれません。

作業内容

開発環境でバージョンアップの実施

準備した内容を踏まえ、実際にオペレーションを行いました。 この時点で、バージョンアップがプロダクトに対してどう影響するのかを判明させました。

実施結果を受けて、ドキュメントに必要事項があれば追記します。

今回は、念のため主要機能を手動テストするようチェックリストに追加することになりました。 全機能の手動テストは現実的に不可能に近いため、事業的なインパクトの大きい部分を重点的に確認するようにしました。

サービスダウンの事前周知

作業チェックリストからバッファを含めた所要時間を見積もり、関係者にダウンタイムをアナウンスしました。

本番環境でバージョンアップの実施

ここまでの流れを踏まえて作業を実施します。 準備の甲斐もあり、予定より早めに完了できました。

バージョンアップ後の残タスク処理

一番気を遣う作業が終わり安心しがちですが、ここでミスすると大変なことになる可能性があります。

例えば DB を Terraform で構築している場合、新しいものに修正しないと差分として認識されます。 バージョンアップのやり方次第では、修正しないまま誤って apply してしまい、、、という状況の発端になりかねません。

また、 DB は比較的コストが大きくなりがちな部分だと思います。 利用しなくなった古いインスタンスなどは折を見てコストのかからない形にしましょう。

そしてもう一つ。一定期間は予期しない挙動をしていないか普段よりモニタリングに気を遣うと良いと思います。

さいごに

今回担当したバージョンアップは、概ね以上のように実施しました。

こうした業務の一部を取り上てげも様々な進め方があると思います。 当然組織やシステム構成に応じて必要な対応は異なりますが、安全性を高める取り組みは大切だと感じています。

また、今回はプロジェクトやチームにとっても良い方法を模索しながらの業務だったため、組織で取り組むという点でも勉強になりました。

本ブログが何かの参考になれば幸いです。

BIツール (AWS QuickSight)の活用紹介

UUUMシステムユニットエンジニアの5n4wasa6です。

先日、実家に帰った際、ふきのとうやタケノコが生えており、春を感じる今日この頃です。 大きなイノシシにも遭遇して戦々恐々としております。

はじめに

UUUMでは現在、中期IT計画というプロジェクトが進行しており、社内の各種サービスの連携や点在しているデータ(Excelやスプレットシートでの管理)を集約しマスタ化して、社員の業務効率化を図ろうとしております。

私が携わっているHerokura(ヘロクラ)というサービスでは、主に、Ruby (Ruby on Rails), JavaScript (Vue.js)を使用しております。

インフラ周りはAWSで構築しており、CI/CDはCircleCI (一部 Github Actions)を活用してます。

Terraform (IaC化)やサーバレスでの実装 (Lamdba)も行っております。

Herokura(ヘロクラ)の一部で、BIツールを活用して会社のKPIを全社員が認識できるような実装があるので、今回そちらをご紹介します。

弊社で活用しているBIツール

弊社では、BIツールとしてTableauやAmazon QuickSightを活用しております。

Tableauは、Youtubeの再生数やトレンドなどさまざまな分析に活用しております。

Amazon QuickSightは、前述の通り、社内のKPIを全社員が認識できるよう、実装/活用しております。

Amazon QuickSight選定の経緯

当初グラフ描画は、JSライブラリで実装することを検討しており、以下3つが候補に上がっておりましたが、単純なグラフ描画をサンプル実装して、事業部側の反応を見るということだったので、chart.jsを採用することになりました(一部Vue-good-table利用)。

  • chart.js
  • Google Charts
  • Highcharts

chart.jsでも描画そのものには大きな問題はなかったのですが、データが増えるにつれストレスなく描画することが辛くなっていきました。 また、今後運用するに当たって簡単に手間なく事業部からの要望や開発側から提案ができる必要があるため、BIツールの検討が始まりました。

弊社内で利用していたTableauと、Amazon QuickSightの比較になりましたが、 価格優位であるAmazon QuickSightで検証することに決まりました。

Amazon QuickSightの設定

QucikSightの各種設定は公式ドキュメントを見るのがベストです。

こちらの動画もわかりやすかったです。

データセットを作成することからスタートするのですが、RDSやS3、Salesforce、ファイルアップロード(csv, tsv, json)、etc...のデータから作成することが可能になっております。

自動更新の頻度は、最短で1時間毎なので準リアルタイムで描画が可能と言ったところでしょうか。

データは、「直接SQLを記述するパターン」と「テーブルを紐づけていくパターン」があるので簡単に作成することが可能です。

直接SQLパターン

f:id:always_protein:20220401113613p:plain
SQL

紐付けパターン

f:id:always_protein:20220401134518p:plain
結合設定

f:id:always_protein:20220401113040p:plain
全体

紐付けパターンの場合、「計算フィールドを追加」ボタンから新しいフィールドを作成することができます。 さまざまな演算子が用意されているので、こちらから欲しいデータ(描画したい項目)を作成することができますが、個人的には直接SQLを書いてしまった方が早いかなと思います。

f:id:always_protein:20220401114021p:plain
計算フィールド

データセットが作成できたら、分析タブから描画したいグラフパターンを選択していきます。

f:id:always_protein:20220401135221p:plain
グラフ描画 (分析)

作成できたらダッシュボードへの公開をして設定は終了です。

アプリケーションからAmazon QuickSightの呼び出し

AWS SDK for Ruby V3を使用して、Amazon QuickSightのダッシュボードを呼び出しています。

RoRの実装

  • 各Controllerからget_dashboard_embed_urlを呼び出す
require "aws-sdk-quicksight"

class Provider::Quicksight
  def initialize
    @client = Aws::QuickSight::Client.new(
      region: Settings.aws[:region],
      access_key_id: Settings.aws[:access_key_id],
      secret_access_key: Settings.aws[:secret_access_key]
    )
  end

  def get_dashboard_embed_url(dashboard_id, user_arn, identity_type = "QUICKSIGHT", namespace = "default", additional_dashboard_ids = nil)
    @client.get_dashboard_embed_url(
      {
        aws_account_id: Settings.aws[:account_id].to_s,
        dashboard_id: dashboard_id,
        identity_type: identity_type, # IAM or QUICKSIGHT or ANONYMOUS
        session_lifetime_in_minutes: 60,
        undo_redo_disabled: false,
        reset_disabled: false,
        state_persistence_enabled: false,
        user_arn: user_arn,
        namespace: namespace,
        additional_dashboard_ids: additional_dashboard_ids
      }
    )
  rescue StandardError => e
    logger.error(e)
  end
end

Vueの実装 (Vue2)

  • クリックするボタン部
<template #graph>
  <div ref="embeddingContainer" />
  <v-button v-if="isDisplayGragh" class="btn btn-success" text="グラフ表示" @action="getQuicksightUrl" />
</template>
  • クリックアクションからの非同期処理
methods: {
    getQuicksightUrl() {
      handleHttp
        .get(this.$appRoute.quicksight_api_v1_report_sales_costs_path())
        .then((ret) => {
          this.embedDashboard(ret.data.url)
        })
        .catch((err) => {
          this.$toasted.error(err)
        })
    },

    embedDashboard(url) {
      const containerDiv = this.$refs.embeddingContainer
      const options = {
        url: url,
        container: containerDiv,
        scrolling: "no",
        height: "800px",
        width: "1000px",
        footerPaddingEnabled: true,
      }
      QuickSightEmbedding.embedDashboard(options)
      this.isDisplayGragh = false
    },
  },

Amazon QuickSightでの悩みポイント

閲覧している人によって、閲覧可能なデータを分けたかったが簡単に保守コスト低く実装ができなかった。 理由としては以下2点です。

  1. 任意のパラメータを渡すことができない

AWS SDK for Ruby V3

システム側にある制御リストを活用できない。

2 行レベルのセキュリティでのアクセス制限

1ができないので、Amazon QuickSightの機能である、行レベルのセキュリティー(RLS)を使用することで

アクセス制限の実現可能ではありました。

docs.aws.amazon.com

f:id:always_protein:20220401144308p:plain
Amazon QuickSight で実現するセキュアなBI環境 資料より抜粋

実際に実装してみると、制限するためのデータの持ち方に少しクセがありました。

f:id:always_protein:20220401143745p:plain
データセット設定画面

また、行レベルのセキュリティー(RLS)を使用するうえで、以下2点が難点でした。

Ⅰ. フィールドの文字数制限 各フィールドには、最大 2,047 文字の Unicode 文字しか含めることができない。 docs.aws.amazon.com

Ⅱ. Amazon QuickSightユーザー作成が必要 自己プロビジョンまたは事前のユーザー招待により Amazon QuickSight にサインインを行うAmazon QuickSight ユーザー(or IAM)を登録する必要がある。 ユーザー登録はこちらの記事が参考になります。

その他、IdP フェデレーションを利用した認証など検討しましたが、ユーザー作成は必須とのことでした。

Amazon QuickSightの活用

以下、元々の実装とAmazon QuickSightでの描画比較になります。(同一データではないのでざっくりでの比較になります)

使用しない(うまく活用できなかった)描画で実装を削除したものもあります。

  • chart.jsでの描画 (テストデータ)

    f:id:always_protein:20220325124822p:plain
    chart.js実装時

  • Amazon QuickSightでの描画 (テストデータ)

    f:id:always_protein:20220325132253p:plain
    quicksight実装時

  • Vue-good-tableでの描画 (テストデータ)

    f:id:always_protein:20220401120304p:plain
    vue-table実装時

  • Amazon QuickSightでの描画 (テストデータ)

    f:id:always_protein:20220401120034p:plain
    quicksight実装時 (table)

終わりに

今回はAmazon QuickSightの活用を紹介させていただきました。 BIツールに限らず業務効率化が図れるよう事業部とコミュニケーションをとりながら実装しております。

最後にUUUMでは、好奇心旺盛なエンジニアを募集しております。 https://www.wantedly.com/projects/861137

チームにScrumを導入してみての振り返り

みなさんこんにちは!

UUUMシステムユニットの sawa__it です。

10ヶ月の子どもが全然離乳食を食べてくれません。どうしたらいいですか?(ガチ)

自己紹介

UUUMには2020年の12月に入社しました。

最初は社内の数値管理システムを担当し、現在ではクリエイター管理システムの担当をしております!

役割はPMです。

PMといってもコンテキストが定まっておらず実態はプロダクトマネジャープロジェクトマネジャーエンジニアリングマネジャーが混ざったようなことをしております。

前職では順番待ちシステムの会社で主に某大手回転寿司チェーン向けにオウンドアプリやアプリ内のスマホオーダー順番待ちタッチパネル配席管理システムの開発及びPMをやっておりました。

2019年にScrumAllienceの「認定スクラムマスター」を取得しており、各種イベントや勉強会にも参加しているので見かけたら声をかけてくれると嬉しいです!

振り返り

上記の通り、役割がいろいろ混ざったようなことをしているためどの立場で何をやってきたかというのは曖昧になりますが参考になれば幸いです。

前提

チームの状態として自分が入る前はこんな感じでした

  • チームは5人(PM含む)
  • なんちゃってアジャイル
  • タスクはアサイン形式
  • 要件が降りてくるだけで自社開発なのに受託開発っぽいという意見があった
  • エンジニアとユーザの関わりが少ない

Scrumの導入

「Scrumは銀の弾丸ではない」とはよくいうもののソフトウェア開発をする部署や人においてアジャイルソフトウェア開発宣言アジャイル宣言の背後にある原則は大事な考え方だと思っており

弊社の経営理念である「セカイにコドモゴコロを」や経営戦略である「もっとアソビナカマを」にもマッチした考え方だと捉えています。

チームにはジュニアエンジニアもいたため今後のキャリアにも備えてフレームワークに則った開発経験がある方がよいと思い、2021年の6月からScrumを導入しました。

導入後にチームとして得て欲しいと期待する点は以下です。

  • フレームワークに則った開発経験
  • 開発の自分ごと化するマインドセット
  • ドメイン知識の吸収
体制について

アンチパターンから入るのも申し訳ないのですが

チームとしてScrumを経験したメンバーが他にいなかったため現在においても自分がプロダクトオーナースクラムマスターを兼務しております。

正直、導入してから半年以上たった今ではチームも成熟し振り返りでチーム自らカイゼンできていると思っているので不都合を感じないのですが、チームのカイゼンにフルコミットできるわけではないのでやはり兼務はしない方が良いです。

特にScrumの導入とチーム異動によってプロダクトを担当したタイミングが近かったこともあり、導入や変更は少しずつと思いつつも「よくわからない奴が急にプロダクトの決定権を持ち開発体制にまで口を出してきた」というような印象を与えたと思います。見え方伝え方にバイアスがかかってしまったのかなと感じているので、やむを得ず似たような状況になってしまう場合には注意が必要です。

スプリントは1週間

最初は「納期に追われるみたいで辛い」「2週間にしたい」という意見もありました。

その都度「1週間の計画が立てられないチームが2週間の計画を立てられるわけがない」と説明し今ではリズムも定着し週ごとに事業の優先度に対応した開発ができていると思います。

これはスクラムマスター研修での江端 一将さんの受け売りでもあります。

スプリントの開始と終了

最初は月曜始まり金曜終わりのスプリントでしたが、祝日でイベントがずれて調整コストが高かったり、月金で休みをとりにくくなってしまったのでおすすめしません。

次に水曜始まり水曜終わりに変更しなるべくオフラインで行うように変更しました。

オフラインはコミュニケーションの観点ではよかったのですが、コロナに阻まれて結局オンラインで1日中MTGとなりました。

水曜日が近づくとプレッシャーがしんどくなってきたという声や、シンプルに座り続けるのがしんどいという理由で曜日を分ける判断をしました。

現在では木曜始まりの水曜終わりのスプリントで回しています。

水曜日に関連プロダクト含めた意思決定の場があるので翌日に計画を反映できるのでちょうどよくやれていると思います。

リファインメント

リファインメントはスプリントプランニングの前に時間をとって行っておりましたが、デイリーでも新しく作った要望に対して説明をするようにしていきました。これによってプランニングの場で改めて説明する必要がなくなりました。

プランニング

プランニングではストーリーポイントを使っていません。

導入時に徐々にScrumに切り替えていこうとする中でストーリーポイントを使った見積もりへの変更を後回しにしてしまったため未だに時間で行っております。

フィボナッチ数を使った時間見積もりって何それ美味しいの

釈明をさせていただくと時間で行っているもののフィボナッチ数で進めているため単位が違うだけで相対的ではあるし、ベロシティの観測にも影響はありません。

そのため、感覚的には長く時間がかかってしまっており結果としてプランニングが時間通りに終わらないことがしばしばあります。

一方で、タスクの見積もりが8以上になると取りかかった際に「朝のデイリーから夕方までに終わらないということになるので分割した方がいいよね、4以下になるようにしよう」という気づきも得られたのでそこはよかったと思います。

タスクはサインアップ方式で行っているため興味のあるタスクについて自ら選択することができます。

旧来のトップダウンのマネジメントには見られない「自分たちで見積もって自分たちでタスクを決定し自分たちで進める」形式はある種逃げ場がないようですが、これまで以上にチームに責任感が生まれたように思えます。

エンジニアとユーザに直接会話してもらう

Scrumではチームが「自己組織化(作業を成し遂げるための 最善の策を、チーム外からの指示ではなく、自分たちで選択する。)」することを目指します。

実はそんな高尚なことを目指しているわけではなく

「大枠はプロダクトマネージャが考えるけど、詳細は手戻りがなるべく発生しないように自分たちでフィードバック受けた方が身になるよね。」であったり「やらされている感」の払拭がメインでそうしていたのですが

実際に行ってもらうと直接話をしてもらうことで以下のような意見が出ました。

  • 要件を落としてもらうだけではわからない課題感や温度感、背景が伝わった
  • ドメイン知識が深まることで既存のコードの意図やおかしい点が分かる

社内とはいえユーザ側と直接会話することでこちらも責任感を高める要因になったのではないかと思います。

ところでスクラムガイドの2020年版に「自己組織化」という言葉が出てこないのはなんでなんでしょうかね。

デイリーは朝と夕方の2回

異動した当初は毎日夕方にデイリーを実施してました。

12月頃からメンバー追加で時間の制限があることから朝に移動しました。

チームの課題としてレビュー待ちの状態のタスクが残ってスプリントバックログを完了できないことが多かったため、バーンダウンチャートをデイリー毎に確認するようにしました。

それはそれで効果があったのですが、朝とったアプローチが上手くいったのか確認するのが24時間後になってしまうため、夕方にも行うようにしました。

また、チームではスプリントに影響を及ぼすような過小見積もりと技術的リスク、不具合、差し込み、体調不良などのリスクを「あばれる君」と称して報告します。「あばれる君」が発動されると、チームは手を止めてリスクを共有し計画を組みなおします。課題が大きければその時点で諦めるタスクを決定します。

Among us の緊急会議みたいな感じですね

「Slackで報告すればいいのでは」という意見もありますが、強制的にコミュニケーションポイントを作ることで報告の流れで課題を報告しやすかったり、アプローチを見直すことができたのでよかったと思います。

スプリントレビュー

スプリントレビューについては特筆するようなこともないのですが、コミュニケーションが増えたことで終わらないものが事前に分かっていることが多いため短い時間で済んでいるように思います。

振り返りはKPT

最初はポジティブに進められそうなYWTを採用しホワイトボードツールで行いました。しかし振り返り慣れをしておらず、課題であれば出しやすいということでKPTをテキストで行うように変更しました。

KPTに切り替えてからもやはり最初は主に自分を主語にした表面的な振り返りばかりでチームに対しての意見は出てきませんでした。

が、「なぜ上手くいかなかったのか」「どうすれば次うまく行くのか」などを半年以上繰り返すことによって徐々にメンバーからもチームに対しての意見が出せるようになってきました。

最後に

このような感じでチームにScrumを導入した流れを振り返ってみましたがいかがでしたでしょうか。参考になるところがあれば幸いです。

最初は一人で頑張っている感じがしましたが、だんだん理解を得られて周りにも評価される実感が得られるのでチームのみならず部署全体に広まれば良いと思ってます。

 

ではでは!

UUUM エンジニア デスクツアー vol.1

みなさんこんにちは!

UUUMシステムユニットエンジニアのendo_tです。

春花粉の猛威にやられて目薬を消費しながら、必死に書かせていただきます🙇‍♂️

はじめに

最近、コロナの影響で在宅での業務が増える中でUUUMではほぼフルリモートの環境に変わり2年弱が経過しました。

2年も経てば在宅での作業環境もそろそろ確立され、充実したエンジニアライフを送っていることと思い、

今回、UUUMエンジニアデスクツアー[vol.1]と題してUUUMシステムユニットメンバーの作業デスクを覗き見ちゃおうと企画しました🥰

この記事は以下のような人におすすめ!

  • 作業環境に満足いってないから改善したい
  • 誰かのデスクを参考にしてもっと充実した環境を整えたい
  • UUUMのエンジニアってどんな人がいるのか気になる

今回は、システムユニットメンバーから3名にインタビューし、 デスク周りはもちろんこだわりポイントや趣味、エンジニア歴・在宅ワーク歴も共に紹介していきたいと思います。

1人目

まず1人目は、社内数値管理システムの開発に携わっているsendo111さん。 Ruby,Rails,Python,Vueをメインに業務で使用しており、使用しているエディタはVS Codeだそうです。

  • エンジニア歴
    • 7年目
  • 在宅ワーク歴
    • 2年目

デスク全体

そんなsendo111さんのデスクがこちら。

デスク全体(sendo111)

綺麗に配置され、ワイドモニターとサウンドバーの存在感があるデスクですね。

ディスプレイ

DELLの34インチワイドモニター
DELLの34インチワイドモニター

以前までは、Macをクラムシェルモードで使用しデュアル・トリプルディスプレイ体制をとっていたそうですが、 最終的にワイドモニター + Macディスプレイの形に落ち着いたそうです。

ワイドモニターほしい...

sendo111さん曰く、ワイドモニターの荷重に耐えられるアームとデスクは気をつけた方が良いとのこと🤔 (彼のデスクは5mmほどたわんでるそうです。)

キーボード/トラックパッド

BAROCCO MD770(クリア軸)/Magic Trackpad
BAROCCO MD770(クリア軸)/Magic Trackpad

キーボードはMISTELの左右分離型、クリア軸のモデル。 クリア軸は、打鍵音が少なく個人的に静かな方が気が散らなくて好みだからだそうです。 トラックパッドを真ん中に配置しているのは、できるだけMacBookと配置を近づけたかったからとのこと。

開発のお供

チキチキボーン/ドルチェグスト(カフェオレ)
チキチキボーン/ドルチェグスト(カフェオレ)

業務中のお供は、どハマりしているというチキチキボーンの鶏かわチップスと最近導入したというドルチェグストでカフェオレだそうです。

2人目

2人目は、UUUMクリエイターのサポートシステムを開発しているmukaiyama_tさん。 業務では、Laravel,Reactを使用しておりプライベートではWeb3(Web3.0)、ブロックチェーンのインプットが多いそうです。

  • エンジニア歴
    • 6年目
  • 在宅ワーク歴
    • 3年目

デスク

そんなmukaiyama_tさんのデスクがこちら。

デスク全体(mukaiyama_t)

L字のデスクを使用しており、業務用PC・プライベートPC・趣味用タブレットを配置しているそうです。

L字デスクであるのは、椅子の回転だけで簡単に別環境に転換できるところがこだわりポイントとのこと✨

真ん中のメインモニターは↓画像のHDMIスイッチャーを使用して、業務用のPCとプライベートPCを切り替えてるそうです。

HDMIスイッチャー
HDMIスイッチャー

液晶タブレット

液晶タブレット(mukaiyama_t)

以前は、仕事でイラストレータをされていたそうで、今では趣味としてデジタルイラストを描くそうです。

開発のお供

そんなmukaiyama_tさんの開発のお供は、ねこちゃんだそうです😻 仕事中には、膝のうえに乗ってきてくれるそうで羨ましい...

cat(mukaiyama_t)

3人目

今回、最後のメンバーはLMNDの開発をされているnoraworldさん。 業務では、Railsをメインに使用していて、プライベートでは最近GithubActionsにハマってるそうです。

  • エンジニア歴
    • 4年目
  • 在宅ワーク歴
    • 2年目

デスク

デスク全体(noraworld) デスクはFlexiSpotのE8。電動昇降デスクを使用していて気分転換にスタンディングで作業しているそうです。 スタンディングでの作業は3割ほどで気分転換にはちょうど良さそうですね☺️

PCはクラムシェルモード、モニターはデュアルで使用しているようです。

キーボード/マウス

BAROCCO MD600v3 RGB/logi MX Ergo
BAROCCO MD600v3 RGB /logicool MX Ergo

キーボードは、MISTELの左右分離型を使用してみたそうですが左右分離型は合わなかったそうで次の相棒を探してるそうです。 マウスは筆者も3年ほど使用しているMX Ergo。角度を二段階に変えられて手首への負担を軽減できて重宝してます。

マイク

SHURE SM7B
SHURE SM7B

趣味でゲーム配信もされるそうでマイクにもこだわったそうです。

このマイクはSHUREのSM7Bと呼ばれるモデルで、これのオリジナルであるSM7は、マイケル・ジャクソンの「スリラー」の録音でも使用されたモデルだそうで、こだわりMAXの一品✨

開発のお供

PCで動画をみることがときどきあるそうで、自身で開発したChrome拡張を使用しているそうです。

Video Commander

僕もインタビュー後に使用させていただいてますが、キーコマンドの操作だけで再生速度の変更や繰り返しみたい部分をLoopしたりととても便利でした。 ウェブストアからインストールでき、Youtube以外の動画のあるサイトで使えるそうなので気になる方はチェックです💁‍♂️

まとめ

今回は3名のシステムユニットメンバーにインタビューさせていただきデスク周りや業務のお供を紹介させていただきました! 在宅ワーク経験が2年目となると自身の環境が確立されていてインタビューしていてとても楽しい時間でした。

UUUMシステムユニットにはまだまだ発掘できていないデスクがあるので、次回も楽しみにしていてください。

個人的興味からはじまった今回の記事でしたが、読んでいただけた方のデスク環境充実の参考になれば嬉しいです。

ハッカソンで優勝を勝ち取ったプレゼンの話

UUUMシステムユニットでPMをやっているエムです。 前々回、前回に続き、今回もハッカソンについての話題を書きたいと思います。

第二回オンラインハッカソンでは私が参加したチームが見事総合優勝をいただき、美味しいご飯を食べることができました。

私は非エンジニアなので開発はしておらず、主に発表資料の作成と当日のプレゼンを担当したのですが、優勝を勝ち取るために工夫したことのお話をつらつら書いていこうと思います。

なお、今回の記事は開発についての内容ではないので、箸休め的にお読みくださいませ。

同じチームのエンジニアendo_shizukaさんが開発の裏話を書いているので、こちらも是非ご覧ください↓ system.blog.uuum.jp

非エンジニアが開発に参加しようとしてみたものの…

私が参加したチームはメンバーが3人いて、発案者と開発者がバラバラだったので、ハッカソンの日を迎える前に事前に何度か集まり打ち合わせを行いました。 作りたいもの、ゴール設定、開発要件のすり合わせ、当日の進行、役割分担など、実業務で行うように結構本格的な話し合いができていたと思います。

当日どのように開発を進めるかの話で、私もエンジニアさんと一緒に画面共有しながらコードいじったりしてみようということになりました。

そして当日。 リポジトリをクローンしたり、 Google Apps Scriptでコード書いてみたり、教えてもらいながら色々やってみたのですが…

意外と時間足りなくね?

ってことに気づき、これじゃ作りたいものすら完成しない=賞金がもらえないので、途中からスピード効率重視で開発を進めることにし、PMエムへの伝授タイムは一旦中止に。

開発に貢献できない私は、発表にパラメータを全振りすることにしました。

どんな発表資料にしようかな

発表資料の作成に時間を確保することができたので、まずは世に溢れているプレゼン資料の記事を読む。 構成、情報量、デザイン…抑えるべきポイントがたくさん出てきます。

それらを意識したうえで、今回の発表では特に大事だと思った下記を重点に資料作りをしようと思いました。

・成果物の必要性をアピール
・ターゲットを意識する
・目を惹く資料、関心を引く発表

成果物の必要性をアピール

私の参加したチームでは、Google Meet上でミーティング招待者の参加状況をひと目で確認できる機能を開発したのですが、これは私が日頃業務で感じている不便さや不満を解消したい思いをぶつけた機能です。 なので、どうしてこの機能が必要か、この機能がないと何故困るのか、のWhyは自分の中ではっきりしていました。

ただ、それをつらつらと文字で説明しても短い発表時間では伝えきれないので、 「機能がないと損すること」「機能があれば得すること」の観点で簡潔に伝え、この機能が必要だと思ってもらう印象付けをしました。

▼この機能がないと時間が無駄になっていると思わせる

↑この時ネットミームになっていた「45秒で何ができる?」という曲が可愛くて好きだったので挿絵的に盛り込みました

▼作業量のbefore afterを並べ、やることが劇的に減ることを分からせる

ターゲットを意識する

今回のターゲットは誰か。 外部向けの発信ではなく、UUUMのシステムユニット内での発表。つまり、内輪ネタが使える範囲です。

UUUMのシステムユニットは、ちょっとボケてもリアクションしてくれる、寛容に受け入れてくれる、いじってくれる素敵な雰囲気のメンバーで構成されています。(※個人の感想です)

なので、発表を流し聞きしていても耳に止まるようなネタ(知っているネタ)を挟むことで、興味が沸き、発表内容にも関心を持ってもらえると思いました。

僭越ながら、特に関心を惹きそうなシステムユニットの偉い方々に勝手に出演していただき、スライド上で今回の成果物を盛り上げていただきました。

▼普段温厚なNさんやTさんをキレさせてみたり…

▼ガッチリなYさん、ワイン好きのNさんの特徴を表してみたり…

▼Iさんがいつも愛用しているヘッドホンの色にもこだわりました

このくだりの時が一番ウケていた気がします。はい。

目を惹く資料、関心を引く発表

当たり前情報ですが、スライドに書く内容は目で見た時に入る情報量に抑え、細かい情報や補足は口頭で伝えるように、発表のシミュレーションをしながら情報を整理して資料を作成していきました。

また、発表の際に心をつかむためには、話し方の強弱や補足の入れ方が大きく影響すると思うので、テンポ良く発表できるように絵を多めに入れて、ストーリーを意識した構成にしました。

非エンジニアの私が作る資料なので開発寄りの詳細な情報は書けない…ということも逆に割り切って、細かい開発過程には触れず、この機能を使った時のことを重点的にアピールして、堅苦しくならない説明にまとめました。

これ大事。発表前のイメトレ

私は緊張しいで、ぶっつけ本番だと絶対に噛んでグダる!と分かっていたので、余った時間でひたすらイメージトレーニングしてました。

各チームでもらえた発表時間が5分ずつだったのですが、オーバーした場合は強制終了になってしまうので、きちんと時間通りに収まるようにタイマーをセットしてイメトレしてましたw

リモートで参加していたので自宅にいたのですが、シーンとした部屋で自分の声だけがブツブツ響いて…すごく恥ずかしい状況でした。 でも、これをやっておいたおかげで、発表の流れがスムーズになり、時間もピッタリでグダることなく思い描いた通りの発表ができたかなと思います。

いざプレゼン!

発表資料は作り込んでいましたが、それをそのまま読み進めても多分聴いている人の心には響かない。 なので、スライドに書いてあること以外にも、自分なりのコメントを挟んだり、文字起こししていない図の解説を口頭で補足したり、少しふざけてみたり…

発表中は緊張してぶっちゃけ頭が真っ白でしたが、笑いやツッコミなどいいリアクションをもらうことができて、手応えを感じることができました。 (でもまさか優勝できるとは思ってませんでした)

振り返り

偉そうにつらつら語りましたが、結局私が難しい開発の話ができなかったり、説得力のある説明が苦手だったりするので、自分ができそうな発表をイメージして資料作成した結果、このようなプレゼンに落ち着きました。

結果論にはなりますが、変に背伸びせず自分が納得した形でプレゼンができたことで、アピールポイントが伝わり最終的に評価いただけて、良かったかなと思います。

それと、今回ここまでプレゼンにこだわれたのは、チーム内でしっかり役割分担ができていたこと、安心して開発を任せられるエンジニアさんがいたこと、そのおかげで時間が確保できたからだと思います。

毎回この状況に恵まれるとは限らないので、どんな時間がない状況でも良いプレゼンができるようになりたいです。

オンラインハッカソンの開催方法・開催に伴う準備について。システムユニットのハッカソン開催の裏側

こんにちは!エンジニアの中村です。 今回は過去に開催したハッカソンを元にハッカソンの運営方法やシステムハッカソンの裏側などを紹介していきたいと思います! コロナ渦でイベント開催が難しい中、ハッカソン開催について興味がある人は是非参考にしてください😃

ハッカソンについて

ハッカソンの目的・開催理由

システムハッカソン開催の目的は、社内のコミュニケーション促進、スキルアップや通常業務ではできなかったチャレンジの機会を設けるためです。 以前まで開発合宿が半期に1回行われていましたが、情勢が変わりコロナ禍において開催が困難になったという背景からオンラインハッカソンを開催しました。

過去のハッカソンの記事

気になる方はこちらから記事を見てください!

【第1回】 https://system.blog.uuum.jp/entry/2021/01/22/110000

【第2回】 https://system.blog.uuum.jp/entry/2021/11/17/110148

開催までの準備

開催までにしたこと一覧

ハッカソンを開催するまでにしたこと一覧です。 第1回と第2回のハッカソンを通して自分が開催するときには必要だよなと思うことを書いたので、ご参考までに。

⚠︎第2回のハッカソンはテーマを参加者に事前に伝えており、ハッカソンでやることやチームを事前に提出してもらいました。

【準備】
[] 運営メンバー集め (司会者・カメラ係・タイムキーパー・情報共有者・ブログ執筆者・評価集計・評価者)
[] 実施計画書を書く(目的・概要・日付・開催場所・予算etc..)
[] 予算の申請
[] ハッカソンの参加者・運営のグループを作成する(運営だけのグループも作成)
[] 参加者集め(シート作成)
[] やることが似ている人たちをチームにまとめる(参加者集めのシートと同じところにまとめる)
[] ハッカソンについての説明会・質問会(複数回)
[] GoogleDrive等に発表資料置き場など資料をまとめる場所を作る
[] 評価基準を決める
[] 賞と景品を決める
[] 実施場所の予約・場所の確認
[] 実施の全社周知
[] 打ち上げの準備

【資料】
[] オープニングの資料
[] 発表前の資料
[] 結果発表の資料
[] ハッカソン参加者アンケート
[] 評価シート
[] 評価コメントシート

準備の詳細

次は開催までにしたこと一覧の詳細です。いくつかピックアップして詳細を書きます。 細かいことが多いですが、実際ここまで決めるとスムーズに行くことが多いので、 めんどくさいですがやるといいかもしれません。

運営メンバー集め

今回のハッカソンは小規模でしたが、運営メンバーは最低でも6人くらいはいるといいと思います。

役割は以下のようにしました。

・責任者 * 1 
・運営メンバー * 2
・司会進行 * 1
・ブログ執筆者 * 1
・評価者 * ?

運営メンバーは基本的にすること一覧の開催までの準備をするのですが、 本番ではカメラ係、Slackなどへの情報共有・タイムキーパーなどを担当しました。 運営メンバーがハッカソンに参加する場合は、タイムキーパーは2人いると1人が発表している時に タイムキーパーがいなくならないのでいいのかなと思います。

発表時間も発表人数から算出して「発表時間+質問タイム+評価入力時間」を出しておいて、全体的に数十分程余裕を持たせてスケジュールを作成しました。 評価集計の人も1人決めておくと、集計が楽です。(今回集計係を決めていなかったので集計が少しもたつきました)

ハッカソンの参加者・運営のグループを作成する

ハッカソン専用のグループを作成して、そこで基本的にハッカソンの話をしていました。 専用のグループを作り、そこでハッカソンについて色々と話すことで、 情報共有が楽なのと、ハッカソン開催への意識を持ってもらうためです。

運営メンバーは当日の動きの確認や、景品についてなどハッカソン参加者に知らせないがいい話をするので別でグループを作成してそこで話していました。

参加者集め・やることが似ている人たちをチームにまとめる

参加者を集める時は、スプレで参加可否・参加者名・テーマ・テーマ内容・テーマ説明を書いてもらい、提示した日までに書いてもらいました。

日を提示しても忙しくて忘れていたりする人がいるので、運営の人は1人参加者を集める担当を決めると期限までにデータが集まりやすかったです。 その日までに担当者が定期的にメンションをつけてリマインドをすることで、参加者自身が忘れないし、 何に悩んでいるのかを運営側が把握することができるからです。

オープニングの資料

オープニングの資料は主に以下の内容を準備しました。

・ハッカソンとは
・タイムテーブル
・発表について(発表日時・一人当たりの発表時間・強制終了時間・発表資料について)
・投票について(Googleフォームなどの投票場所のURLとQRコード・投票基準と各項目の点数)
・賞について(景品の発表・注意点など)
・注意点

注意点では発表前に資料を共有することや、発表中は出来る限り顔出し必須など 書いておくことで発表がスムーズにできるのかなと思います。 オープニング後はオープニングに来れなかった人や資料を見直したい人のために資料をグループに展開するといいかもしれません。

発表前の資料

発表前の前段階の資料は主に以下の内容を準備しました。

・発表について(オープニングと同じスライドでOK)
・注意点
・発表の流れ
・投票について(オープニングと同じスライドでOK)
・発表順番
・集計時間
・アンケート

発表順番に関しては参加人数が多い場合は運営側で先に決めておくとスムーズでした。 第2回は参加者が多かったので先にこちらのサイトで決めました。

順番決め.com: https://xn--ebku91pdvftn1b.com/

参加者が少ない場合は、発表順番を発表が終わるごとに決めても時間的に大丈夫そうだったので、 第1回はこちらのサイトを使わせていただきました。

3Dあみだくじ: https://exe.tanidaiz.com/3D-Amida.php

注意点に関しては、辛辣なコメントを控えるなど書くといいのかなと思います。 発表するだけですごい!と私は思うので、辛辣なコメントがあると次開催するときに参加したくなくなりますし、次発表する人も萎縮してしまうからです。

評価シート

今回はGoogleFormで評価シートを作成しました。 項目はチーム名・個人orチームのよかったところ・テーマごとの得点にしました。 第2回のハッカソンではテーマを3つに絞っており、 それぞれ評価基準が違うのでGoogleFormでチーム名を選択した際に飛ぶページをそのチームのテーマの評価シートになるように設定しました。

f:id:chibiProgrammer:20220228184133p:plain
評価シート

第2回ハッカソンの評価例↓

例:
テーマ:業務効率化
業務効率化  5点
ギーク度    5点
完成度      3点
プレゼン力   2点
総合点 ->   15点

テーマ:通常業務+a
業務効率   5点
ギーク度   5点
完成度     5点
プレゼン力  5点
総合点 ->  20点

テーマ:新規事業
新規・事業性 3点
完成度      3点
ギーク度    5点
プレゼン力   5点
総合点 ->   16点

評価コメントシート

評価コメントシートというのは、評価シートの個人orチームのよかったところを集めたシートです。 評価コメントシートは必須ではないとは思うのですが、作ったものへの評価を聞きたい人 がほとんどかなと思うので作成しています。

⚠︎基本的にはひどいコメントないかもしれませんが、あった場合は弾くなどの配慮が必要なのかなと思います。

f:id:chibiProgrammer:20220303184320p:plain
評価コメントシート

ハッカソン参加者アンケート

ハッカソンの参加者アンケートは 次のハッカソンをもっと良くするために作成しました。 質問内容は以下のようにしました。

・ハッカソンはこれまでに参加経験
・審査基準は妥当か
・審査基準の評価の理由
・開催期間は妥当か
・開催期間の評価の理由
・次やりたいイベントはあるか
・気になったこと、次のハッカソンでは直して欲しいところはあるか
・次のハッカソンへの要望 

ハッカソン参加者アンケートは運営の結果集計時間に共有すると待ち時間にアンケートを書いてくれるのでいいのかなと思います。

第2回ハッカソン開催までの裏話

開催が決定して運営でMTGして話は進んでいましたが、コロナが悪化してきて集まるのが難しいという話になったり 今回のテーマが業務改善だったので何をすればいいのかわからない人が一定数いて、このまま進むとモチベーションも上がらないしいいものも 作れないよねという話になり、9月に行う予定でしたが10月末になりました。 それと、ハッカソンまでに準備しないといけないことが用意ができてなく、 全体的な流れがぼやけていて止まっていたので準備にある程度時間がかかりました。

当日は会場に必要なものがなかったり、最後の集計でGoogleFormのデータスプレに吐き出してデータを確認すると データがバラバラで、集計に時間がかかったり、結果発表の資料が一部できておらず、即席でこんな感じの資料を準備してもらいました笑

f:id:chibiProgrammer:20220303183211p:plain
モンエナ
思った以上に想像が欠けていた部分が色々出てきたので、運営側は色々大変だなと思いました😇

まとめ

今回書いたような準備シートや期限を設定してMTGを都度行なったりすることをやってからスムーズに進んだので ハッカソンを開催する際は準備シートや期限、MTGの頻度をきちんと決めてから作業をすると延期や中止になりにくいのかなと思いました。 ハッカソンを開催するのは意外と準備が必要ですし、「ハッカソン?まぁ司会とかの資料作成くらいしとけばあとはどうにかなるでしょ?」 くらいのテンション感だと当日想定できてないことが起きてスムーズにいかないので、きちんとした計画が大切だと思いました。 第2回ハッカソンは1回目よりテーマの難しさや参加人数の増加により考えることが多かったですが、 いろんな人が協力してくださったのでうまく行きました。 第3回があるかはわかりませんが、開催できたら今以上にいいハッカソンができるようにしたいと思っています。

今回の記事でハッカソンを開催したいけど何をしたらいいのかわからない人や、 開催準備を進めているけどうまくいくか不安な人の何か参考になれば幸いです。 ここまで読んでいただきありがとうございました🙇‍♀️

第2回オンラインハッカソンで作成した拡張機能の裏話

こんにちは。エンジニアのendo_shizukaです。

UUUMに入社して1年半が経ちました。

「入社して1年半経ったとか時間の流れ早すぎん!?」って感じで日々業務に勤しんでいます。

さて、今回ブログを書くにあたりネタをいろいろ探していたのですが、

個人的にかなり大変だけど楽しかった第2回オンラインハッカソンで作成した機能でつまずいたポイントについて書いていきたいと思います。

第2回のオンラインハッカソンについてまだご存じない方は、

弊社の新進気鋭なエンジニア、久保寺君が書いてくれた記事がありますので見てみてください。 system.blog.uuum.jp

それではどうぞ。

 

そもそもGoogle Meetの出欠席確認機能って何?

前提としてGoogle Workspaceを使用している会社・チームが対象になります。

もしかしたら既に経験ある方もいるかと思いますが、会議の開催時刻になると招待されたメンバーは続々とGoogle Meet(以下、Meet)に参加します。

ファシリテーターは招待者の出欠確認を行うのですが、Meetの標準機能だと現在参加中のメンバーしか表示されていないので、Google Calendar(以下、Calendar)とMeetの参加者を照らし合わせながら確認するという手間が発生します。

もし、会議に招待しているメンバーが参加するのか否か、また現在Meetに参加しているか否かがMeet上で一目で分かれば出欠確認の手間が大幅に削減されるのでは?ということを目的に開発されました。

f:id:endo_shizuka:20220225192228p:plain
出欠席確認機能

  さて、ここから本題です。    

つまずきポイント

参加中のMeetからどの会議に参加してるかが判断できない...

会議で使用するMeet URLはCalendar上から確認できますが、

f:id:endo_shizuka:20220225160039p:plain
Calendar画面

Meet上からだとMeetのURLと入室前の会議タイトルしか情報が無く、どの会議に参加してるかが判断できません。

f:id:endo_shizuka:20220225160036p:plain
Meet画面

 

解決策

以下の手順で参加中のMeetの会議情報が取得できました。

  1. JavaScriptのlocation.pathnameを用いてMeet URLのhttps://meet.google.com/以下の文字列を取得

  2. CalendarAPIのEvents.listを用いて本日入っている自分の会議を全て取得

  3. 2で取得した会議の中にconferenceDataオブジェクト *1 があるので、その中のconferenceIdと1の文字列が一致するものを開催中の会議として取得する

参考1 developers.google.com

参考2 conferenceDataオブジェクトのデータ構造(2022/02/25現在)

conferenceData: 
{ entryPoints: [ [Object], [Object], [Object] ],
    signature: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx',
    conferenceSolution: 
    { key: [Object],
    name: 'Google Meet',
    iconUri: 'https://xxxxxxxxxxxx' },
    conferenceId: 'yer-necw-rbs' },

 

会議室もゲスト扱いになって参加者一覧として表示されてしまう...

組織内で会議室もCalendarに作成して管理していた場合、

その会議室を使用した会議を作成するとゲストの1人として会議室も表示されてしまいます。

解決策

会議室のゲストのメールアドレスはドメインが@resource.calendar.google.comで設定される事を発見しました。

会議のゲストリストを取得する際に上記ドメインのゲストを弾くことで解決しました。

 

同じ会議IDで同じ予定が2つ取得されてしまう...

CalendarAPIのEvents.listでその日に開催される会議を取得した際に、同じ会議名で2つのオブジェクトが取得される場合があります。

これは定期的な会議の場合に発生するもので、実際に取得できたオブジェクトをそれぞれ確認してみると、 一方は定期的な会議の初回開催時の情報が入ったオブジェクト、もう一方は本日開催の情報が入ったオブジェクトであることがわかりました。

解決策

オブジェクト内を詳しく見てみると以下のような違いがありました。

  • 初回開催時の情報: recurrence: [ 'RRULE:FREQ=WEEKLY;WKST=SU;BYDAY=FR' ] *2

  • 本日開催の情報: recurringEventId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx',

なぜ、定期的な会議の場合2つオブジェクトが流れてくるかの理由については調べきれていませんが、 実装としては本日開催の会議情報が得られればいいのでrecurringEventIdが含まれるオブジェクトを取得することで解決しました。

 

参加者のフルネームや招待ステータスなど参加者にまつわる情報を取得したいけど...

こちらは自分の完全な見当違いだったのですが、 CalendarAPIのEvents.listで会議情報を取得したら参加者のメールアドレスやフルネーム、招待ステータス *3 などが全て一括で取得できるものだと思っていました。

Events.listはあくまで会議自体の情報しか取得できず、参加者については別途APIを叩く必要がありました。

解決策

画面表示には 参加者のフルネーム メールアドレス 招待ステータス サムネイル画像 の値が必要だったので、

メールアドレス 招待ステータスをCalendarEventのgetGuestListを使用して取得しました。

const guests = event.getGuestList(true)

developers.google.com

参加者のフルネーム サムネイル画像 についてはAdmin SDK Directory Serviceを使用する事で、会議の参加者のフルネームやサムネイル画像を取得することができました。

  do {
    page = AdminDirectory.Users.list({
      domain: DOMAIN,
      viewType: 'domain_public',
      maxResults: 500,
      pageToken: pageToken
    });

developers.google.com

注意点として、AdminDirectory.Users.listを実行する際にviewType: 'domain_publicを書かないとエラーになります。

GoogleJsonResponseException: API call to directory.users.list failed with error: Not Authorized to access this resource/api))

 

まとめ

拡張機能はストアでの公開を目標にアップデートしていますが、頑張って対応中ですので公開までもうしばらくお待ちくださいmm

なお、実装した当時はここまでで紹介した解決策でなんとか乗り切れましたが、

現在や今後の仕様変更でもっと簡易に実装できたり同じやり方では解決できない場合も出てきますので、参考にされる際は自己責任かつその時その時の一番いい方法で実装して頂ければと思います。

*1:conferenceDataオブジェクトはMeet URLが発行されている場合のみ含まれるので、Meet URLを発行していない場合はオブジェクト自体存在しません。

*2:毎週金曜開催の場合このような値が入っています。

*3:はい / いいえ / 未回答