Cloud Penguins

Flying penguins in the cloud.

MiroにExcelやSpreadSheetをコピペしたときに付箋にならないようにする

Miro Advent Calendar 2021の10日目! 今回は小ネタ。

7日目のYasumaさんが紹介してくれている便利なTipsと機能はとても参考になるのでぜひ読んでほしい。付箋の整理整頓の機能は知らなかった。便利。

note.com

その中でひとつ気になったのが

第8位「スプレッドシートのカラムをコピーしてボード上でペーストするとカラムが付箋で生成されて便利」

これ、Miroをしばらく使ってみた人が経験するサプライズの中でもトップ3に入る機能だと思っている。それは、いい意味でも悪い意味でも。自分もMiro使い始めたころにこれを経験して、めっちゃ驚いた記憶がある。

スプレッドシートをコピペすると何が起こる?

改めて解説しよう。たとえば以下のようなスプレッドシートがあったとする。

f:id:jaco-m:20211210010753p:plain:w300

これをMiroにコピペすると何が起こるか。

f:id:jaco-m:20211210010931p:plain:w300

うわぁ

事前情報なしにこの挙動を目の当たりにすると、結構びっくりする。 Tipsで挙げられているように、確かに便利なケースもあるといえばあるのだが…スプレッドシートをコピペする人は、どっちかというと表をそのまま貼ってくれることを期待しているほうが多いんじゃなかろうか。

こんな感じで。

f:id:jaco-m:20211210011606p:plain:w300

Spreadsheetをテーブルとして貼り付けるには

上に貼ったイメージ図のように、テーブルとしてMiroに貼り付けたい場合。 先に空のテーブルを作っておきに、そこにコピペすると良い。

左のメニューからTablesを選択して

f:id:jaco-m:20211210011820p:plain:w300

空のテーブルを作成。行や列の数をコピペ元と合わせておく必要はない。デフォルトの3x3とかでいい。

f:id:jaco-m:20211210011848p:plain:w300

セルを選択して…

f:id:jaco-m:20211210011956p:plain:w300

スプシからコピペ。このように、ちゃんとテーブルとして貼り付けされる。

f:id:jaco-m:20211210012023p:plain:w300

行や列の高さは調整されないので、そこは手でいい感じに修正しよう。

f:id:jaco-m:20211210012223p:plain:w300

なんでもかんでも付箋紙だけじゃなくて、たまには表を使ってビジネスっぽいディスカッションもしたいんじゃい、という場合にはぜひ活用してほしい。

Vimeoで200万円請求話はミスリードなので騙されない方が良い

こういうツイートが話題になっていた。千葉県佐倉市のSound Stream sakuraというライブハウスのようだ。

要約すると、Vimeoから突然200万円請求され支払わざるを得なくなったということだ。

この文面だけ見ると、『なんていう酷いサービスなんだ、許せない!』と感じてしまうだろう。 しかしこれはフェアではない。自分の視点から見ると、Vimeo側に非は殆ど無く、むしろこのツイート主が宣伝目的で炎上させているように感じる。

何故そう言い切れるかというと、自分も全く同じ通知を受け取っているからだ。

TL;DR

  • 使いすぎてもVimeoから突然200万円追加請求されることはない。段階を踏んだ警告が行われる
  • 件のツイートは嘘を言っているわけではないが、恣意的な編集が行われている
  • ビジネスモデルが異なるYouTube Liveと比べるのは無意味
  • Vimeoの価格は決して高い部類ではなく、むしろ安い

Vimeoから使いすぎメールが来る

自分がCo-Chairとして関わっている技術カンファレンスでも、つい先日まで配信プラットフォームとしてVimeoを利用していた。しかし直近のイベントではAWS IVSに切り替えた。何故そうしたかというと、以下のようなメールがVimeoから届いたからだ。

To Whom It May Concern,

I'm reaching out as your account was flagged for heavy bandwidth usage in which consumption was within the Top 1% of bandwidth-consuming accounts and is subject to Vimeo's Fair Use Policy. I have included the term below.

Unlimited Bandwidth Fair Use Policy: Generally, we do not limit or impose additional fees for bandwidth consumption on Self-Serve accounts (i.e. the data used in order to deliver your videos to viewers). However, this policy is subject to fair use: If your aggregate bandwidth usage (across all accounts you control) is higher than 99% of Self-Serve users on our platform in any calendar month, we may, in our discretion, charge fees for excessive usage, require you to upgrade to a more suitable plan, or terminate your account(s) upon advance written notice. For more information on bandwidth and our fair use policy, please see our Bandwidth on Vimeo article.

If you would like to continue streaming at your current levels you would be required to upgrade to an Enterprise or Custom plan which is priced based on the amount of bandwidth needed.

your account was flagged for heavy bandwidth usage in which consumption was within the Top 1% of bandwidth-consuming accounts ということで、上位1%に入りましたよと。件のツイートと一緒。ただ、 おめでとうございます! なんて表記は一言もない。この時点で脚色されている・・・

めんどくさいので以下DeepL翻訳そのままぶっ込み

一般的に、当社はセルフサービスアカウントの帯域幅消費(お客様のビデオを視聴者に配信するために使用されるデータ)を制限したり、追加料金を課したりしません。ただし、このポリシーはフェアユースの対象となります。お客様が管理するすべてのアカウントの帯域幅使用量の合計が、いずれかの暦月において、当社プラットフォーム上のセルフサービスユーザーの99%を超えた場合、当社は、当社の裁量により、事前に書面で通知した上で、過剰使用に対する料金を請求し、より適切なプランへのアップグレードを要求し、またはお客様のアカウントを解約することができます。 帯域幅とフェアユースポリシーの詳細については、「Bandwidth on Vimeo」の記事をご覧ください。

現在のレベルでストリーミングを継続する場合は、必要な帯域幅に応じて料金が設定されているエンタープライズプランまたはカスタムプランにアップグレードする必要があります。

はい。 追加料金を課したりはしない が、過剰に利用が行われた場合は 事前に書面で通知した上で 、 過剰使用に対する料金を請求し、より適切なプランへのアップグレードを要求し、またはお客様のアカウントを解約することができる。

とある。随分受ける印象が違うんじゃなかろうか。 確かに 上位1%に入ったので過剰利用分を請求する という捉え方が出来ないとは言わないが、かなり恣意的と言えるんじゃないか。 警告を無視して使い続けるユーザーに対する牽制の意味合いが強いと思われる。 いずれにせよ、いきなり請求されることはない。

ちなみにどのくらい使うとこれが来るかというと、FAQに具体的な記載があり、 月あたり2TBから3TBの転送量で上位1%になる。

警告を無視して使い続けると何が起こるの?

数回の警告後、アカウントが凍結される

自分も初回の警告受けてからすぐに返答が出来なかったが、1週間にわたり細かく返事の催促が来るので返答した結果、凍結はされなかった。

数回の催促メールには、"何月何日までに返事しないと、申し訳ないがアカウントを凍結する" と期日まで書かれていたので、Twitterのように突然凍結されるような理不尽さは全く無く、丁寧にフォローアップしてるんだなと感じたほどだ。

実際に凍結されてしまった例をみるとこうある。

Vimeoアカウントが停止されて焦った話 -この動画は存在しません- – オレンジの国

この例だと、1ヶ月ほど警告が続き、その後アカウント凍結に至ったよう。しかし

ちょうど1か月前にこのようなメールが届いていましたが、普段英語のメールは全てスパムなので読まずに削除していました。

うーん。これはVimeoに非はなく、利用者側の問題だよね・・・。

Vimeo Enterpriseの見積額も年間200万とのことで、件のツイートと同じ。 つまり、同レベルの利用量でもアカウント停止には至ったが、それまでの利用料を遡って請求されたということはない。

同様の事例を十数件聞いているが、やはりいきなり請求されたり、過去の分まで遡及された例は一例もなかった。

で、お前の場合はどうなったの?

自分たちの場合は、年に数回のテクノロジーカンファレンスの利用だったので、そのときだけ転送量がスパイクする。しかし今後しばらくはイベントやらないから大きな負荷はかけないよと返したところ、以下のような返事があり事なきを得た。

First off, a pleasure to meet you via email and I appreciate your feedback! With that being said, I just re-ran your daily bandwidth report and can confirm that your traffic has ceased.

このあとLookerによるサマリーが送られてくるようになり、毎日の正確な転送量が分かるようになった。出来ればこれがサイトから見られれば良かったなとは思うが。

この間、特に不快になるような対応はなく、極めて真っ当なやり取りが行われたと思っている。

じゃあ何故AWS IVSに乗り換えたかというと、金額ではなくAPIの充実度合いや低遅延配信の品質を理由に決めた。見直したきっかけはこの通知だったが、決め手は金額ではない。AWS IVSはこれ単体では解決出来ず、MediaLiveやMediaPackage、S3、CloudFrontを組み合わせてようやくVimeoに近い機能が実現出来るので、それらのコストや開発コストを加味するとむしろ高くなった。

上位1%になるってことはスゴいんじゃないの?

件のメールでは、上位1%に入ったことをむしろ誇るかのような展開になっているが、実はこの上位1%には簡単に達してしまう。

3TBの転送量で上位1%になると書いたが、例えば動画を平均4Mbpsで、月に延べ32時間配信したとすると、平均同時接続数50人 程度で達してしまう。これが誇れる数字かというと・・・? 物は言いよう ってことだね。

たぶん、自分がこれから毎日1時間、技術トークをするソロライブ配信を行ったとしてもそのくらいは行っちゃいそうだ。

Vimeo Entepriseは転送量や人数などを加味した料金体系になっているようで、年間200万程度の見積もりが来るということは、それよりは多い人数だと思われるが、平均同時接続数で500は下回る規模かなと思われる。

まあ、ピンチをチャンスに変えようという強かさは見習うべきところがあるかもしれないが、他人を下げて自分を上げるやり方はアンフェアではないか。

たったそれだけで200万!? やはりVimeoは悪、YouTube Live最高!

と思うかもしれないが、まあ落ち着け。

まず、動画配信はとてもお金がかかる という認識を持つべきだ。たとえば先ほど3TBの転送量はたった50人で達してしまうと書いたが、たとえばAWSを使って、動画配信関係なく単にインターネットへデータを転送するだけで、 $0.114/GBかかる。3TBだと4万円弱かかる。これに配信システムを動かす金額やCDN(Content Delivery Network)の金額がかかるわけで、動画配信の仕組みを自分で作ったとしても結構お金がかかるのだ。

一方でYouTube Liveは無料で配信が出来る。超人気の配信者だと同時接続数万人になるわけで、この差はなんなの?と思うかもしれない。

しかしこれはVimeoが暴利を貪っているのではなく、YouTubeが慈善事業をやっているのでもなく、単にビジネスモデルの違いだ。

YouTubeは配信者には課金をしていないが、企業からの広告やYouTube Premiumの有料課金、メンバーシップ、スーパーチャットの手数料など、主に視聴者からお金を稼ぐモデルになっている。 スーパーチャットで2億円稼ぐVTuberなどが記事になっているが、そのうち6000万円はYouTubeの取り分になっている。ちなみにスマホでスパチャした場合、さらに3割がAppleやGoogleの取り分で持って行かれる。そりゃぁ、配信者には課金しなくてもいけるよね。 Twitchも同じようなビジネスモデルだ。

3割どころか半分以上持って行くメガプラットフォームのやり方のほうがよっぽどエグいなと感じるが、プラットフォームビジネスとはこういうもの。世の中そういうふうに出来ているので不当だとは思わない。

ともかく、もしも無料でライブ配信をやりたい場合、配信者目線ではYouTube LiveやTwitchを活用するのが最善手だろう。メガプラットフォームのおこぼれに預かれる。

しかし件のツイートに対するリプライを見ると、『YouTube Liveにしましょう、無料ですよ!』なんて意見が沢山付いているが、それは無理だろう。なぜなら、YouTube Liveで有料配信を行うことは規約で禁止されており、BAN対象となるからだ。件のライブハウスはライブを有料配信しており、そういう場合は、Vimeoのような有料の動画配信サービスを使わざるを得ない。 まあ、無料のプラットフォームを使い倒して稼ぐなんていう虫の良い話があるはずもないので、当然だろう。

有料だとしても200万は高い! Vimeoは暴利を貪っている!

と言いたくなるかもしれないが、その場合はこの言葉を口に出して読んでみよう。高いと思ったら使わなければいい。 他にも有料配信可能なプラットフォームは沢山あるので、探して引っ越せば良いだろう。

では、Vimeoの200万という数字は高いのだろうか。

例えば、ニコニコの有料生放送は、売上代金の14%が手数料としてかかる。 SPWNの場合は8%+220円のようだ(代理店によって異なるかもしれない)

仮に 3000円のライブを、300人に対して、 年間100回開催したと仮定する。すると、年間の売上高は9,000万円だ。 この売上高から、以下の金額をプラットフォームに支払うことになる。Vimeoには課金機能がないため、Tiget Liveというチケット販売サービスを組み合わせて計算してみる。また、Vimeo Enterpriseは利用量に応じて課金額が変わるようなので、今回は仮に200万円としよう。

プラットフォーム 手数料 PFへの支払い
Vimeo + Tiget Live 200万円 + 5% 650万円
ニコニコ生放送 14% 1,260万円
SPWN 8% + 220円 1,380万円

・・・これでもVimeoが高いと言えるだろうか。むしろ圧倒的に安い。自分がこの中で選べと言われたら、Vimeoが第一選択肢になるだろうというほどの価格差だ。件のライブハウスが他に乗り換えずVimeo Enterpriseへの移行をしたということは、このあたりの価格感が分かっていたからではないかと推察されるが、にもかかわらず後ろ足で砂をかける行為は全く感心できない。

なぜこの記事を書こうと思ったか

自分はもうVimeoから乗り換えてしまったので、これを書くことによって得られるメリットというのは特にない。

にも関わらず何故これを纏めたか。それは、コロナ禍により通常のイベントが行えずオンラインによる試行錯誤を余儀なくされた身として、動画配信の業界が健全に育っていくことを強く願っている。

しかし今回のように、自身の宣伝を目的として非のないプラットフォームが不当に貶められる、しかもそれが誤解を含んだまま拡散している様子は、業界の発展に間違いなく悪影響を及ぼしてしまうと考える。

自分のこの記事によって、拡散した誤った情報が訂正されること、そして動画配信サービスに対する公平な認識が広がることを願っている。

あと。

自分を宣伝するんだったら、フェアにやろうや。

おまけ

他の動画配信プラットフォームとの比較

Vimeo (Premium)

Pricing plans | Vimeo Pro, Plus, Business, Premium, Enterprise & OTT

  • ¥7,500/月 (年払いの場合。月ごと払いの場合¥13,500/月)
  • 無制限のライブイベント、ウェビナー。ただしFair use policyのため3TB/月程度で警告が来る
  • これ以上使う場合はEnterprise版。価格はお問い合わせ (今回の場合、それが200万という話だった)

IBM Video Streaming (Platinum)

IBM Video Streaming - 料金体系 - 日本 | IBM

  • かつてのUSTREAM
  • ¥138,500/月
  • HD(720p)まで
  • 20チャンネルまで
  • 総視聴時間合計5,000時間 (同時接続数300, 1回当たり2h, 月8回の配信でこのくらい)
  • これ以上はカスタムプラン。価格はお問い合わせ

た、たか・・・

dacast (Scale)

https://www.dacast.com/live-streaming-pricing-plans/

  • $188/月(年払いの場合。月ごと払いの場合$250/月)
  • 無制限のチャンネル
  • 転送量 年間24TBまで(月あたり2TB)
  • それ以上はカスタムプラン、価格はお問い合わせ

同種のサービスで比較すると、やっぱりVimeoのお得さが際立つ。でも、VimeoがPremiumプランのことをUnlimited live streamingと書いているのは分かりづらいし、実際のところの制限は存在するわけで、FAQだけでなく価格表にも明記して欲しいな。。

しかしかつてのUSTREAMさん、高いな・・・。これには驚いた。

追記

ツイートによると、50TBで50万円程度のプランが提案されることもある様子。3TBで10万円⇒50TBで50万円 と提案されるのであれば、極めて真っ当なんじゃないかな。それが200万円という提案になったということは、それだけ帯域を使っているということだと思うので、それはちゃんと払おうよ

追記の追記

ツイート主から返信があったので一連のやりとりをまとめてみた。結局真相は謎のまま…

togetter.com

追記の追記の追記

Vimeoからの公式回答が得られました。

jaco.udcp.info

2022/3/27 さらに追記

分かりづらかった「上位1%」という基準を「2TB以上消費時」に変更することや、使用帯域についてのアラートが実装されるなどの改善が発表された様子

vimeo.com

gigazine.net

Miroの操作が直感的じゃないと感じた時はNavigation設定を見直そう

Miro Advent Calendar 2021の5日目。このブログだとMiroネタ2回目。

前回: jaco.udcp.info

「Miro、触ってみたけどなんかクセがあるというか、直感的に操作できない」 という意見を聞くことがある。そんなときは、一度設定を見直してみようという話。

Miroは直感的に操作できない?

最初同僚から「Miroの操作が直感的じゃない」と聞いたときは戸惑った。個人的には群を抜いて直感的に操作できる便利なツールだと感じていたので、「え、どこが?」 と。

が、ある時所有している他のPCから使ってみたところ、どうもいつものように操作ができない。マウスホイールを使うと拡大縮小じゃなくて上下に動くし、マウスのドラッグでボードの移動を行うこともできない。なんだなんだ、突然仕様変更されたのか? と慌てたが、結論としてはNavigation modeに問題があった。

Navigation modeを見直そう

画面左上のタイトル横にある設定マーク(新UIの場合。旧UIだと右側) をクリックし、Preferences -> Navigation modeをクリックする。 あるいは何もないところで右クリックしたときに出てくるメニューにもNavigation mode設定がある。

f:id:jaco-m:20211205024247p:plain

これを選択すると、このようにNavigation modeをどうするかという設定が出てくる。

f:id:jaco-m:20211205024257p:plain

もしマウスを使っているのであればMouse、トラックパッドを使っているのであればTrackpadを選択したほうが良い。

前述した操作の違和感は、マウスを使っているのにも関わらずTrackpadにモードが設定されていたのが原因だった。 ここの初期値がどのように決定されるのかはまだよく分からない…。

ちなみにマウス派?トラックパッド派?

ところで他の人はどちらを使っているのだろう。 個人的にはどのWindows機もトラックパッドの出来が悪いので、Windowsであればマウス一択かなと思っている。 Macであればトラックパッドが秀逸のため普段はマウスを使わないことも多いが、Miroを使うときはマウス欲しいなと感じることが多い。 特にオブジェクト間でラインをつなぐなどの細かな操作をやるときはマウスのほうが快適に出来る気がする。

追記

最近このナビゲーション設定が機能変更され、Auto switchというものが導入された。また、マウス操作時のボタンが変更になっている。

以下のエントリーも参考に

jaco.udcp.info

人類はWeb会議に向いていないので、もっとMiroを活用すべき

Miro大好きjacopenです。エンタープライズなIT界隈ではおそらく日本でトップクラスにMiroを愛している自信がある。

さて今日はMiro Advent Calendar 2021の3日目。

今日は、人類がいかにWeb会議に不向きかという話と、そのギャップをMiroで埋めようという話。あとは自分が関わっているカンファレンスでMiroを使いまくっている話をする。

Web会議の8割はXX

コロナ禍でだいぶ定着したWeb会議。でも、個人的には世の中のWeb会議の8割は上手くいっていないと思っている。数字に根拠はないけど。 何を持って上手くいっていないとするかだが、「対面の会議と比較して伝えられる度合いが低下している」とすると、8割くらいはそれに該当すると言っても過言ではないだろう。

何故そうなるかというと、基本的に人は言葉だけで物事を正確に伝えることはできないからだ。

人間の会話において、話し手は頭の中に構造化された情報があり、「今何について話しているか」という位置情報をもった状態で話す。まあ中には位置情報を持たず思い浮かんだことを喋っちゃう人や、脳内の位置情報がどんどんズレていく人もいるがそれはまた別の話。

一方聞き手は必ずしも同じ構造化された情報を持っているとは限らない。そのため、聞き取った内容から情報を組み立てて行く必要がある。また、話し手が持っている位置情報は共有されないため、話の流れから位置情報を推測し、継続的に更新していかなくてはいけない。

しかし、声というのは単位時間当たりに伝えられる情報が少ない手段だ。日本語だと1秒当たり十数文字分しか伝えられない。データ通信に置き換えるとわずか数十byte/sec。声のトーンなど付加情報を加味しても、とてもとても少ないわけだ。必然的に、伝える情報は断片的なものになってしまう。

f:id:jaco-m:20211203000057p:plain

これらは対面でも同じことが言えるのだが、人間というものは五感を働かせることによってある程度のエラー訂正が可能だ。声による情報の他にボディランゲージや表情によって情報の補完が可能なほか、聞き手の表情などから正しく伝わっていないことを読み取れれば、追加の情報を付加したり、分からないところはどこか聞き出すことも可能だ。対面の会議が好まれる理由はこのあたりにある。

これがWeb会議になってしまうと、声以外の情報がばっさり切り落とされてしまう。人間が備えているエラー訂正機能が働かなくなってしまうのだ。 そのため、聞き手の脳内で情報の構造化ができないまま話が進み、位置情報もズレてしまう。

他にも問題がある。対面のミーティングと違い、Web会議では聞き手の環境をコントロールしづらい。聞いている間に宅急便がくるかもしれないし、猫が来ることもあるし、横で開いているTwitterに面白画像が流れてきて注意が逸れることもある。対面の会議でTwitterを開いている人は比較的少数だろうが、Web会議では相手がどういう状況か知ることは難しいわけだ。たとえその注意が逸れている時間が十数秒であっても、先ほどから書いている会話の位置情報をズラすには十分な時間だ。

この話し手と聞き手の位置情報がある一定以上ズレてしまうと、聞き手はその段階で一切の情報を受け取れなくなってしまう。

例えば、車に乗って見ず知らずの場所に出かけても、移動した経路を覚えていればおおよその位置は分かる。しかし、しばらく目隠しをされていたらどうなるか。どこに居るか全く分からなくなってしまうだろう。この状態でいくらその土地の説明をされたところで、要領の得ないものとなってしまうだろう。

「開催したはいいが効果が得られないWeb会議」はこうやって生まれていく。

f:id:jaco-m:20211203000130p:plain:h300

コンテキストを揃えるべし

コミュニケーションにおける、この位置情報のことをコンテキストと言う。 正確には、コンテキストの一部と言った方が良いか。元々持ち合わせている知識や文化的な背景、会話の文脈などを総じてコンテキストと表すことが多い。

コミュニケーションで最も大事なことは、このコンテキストを共有し、各人の立ち位置を揃えることにある。

コンテキストの共有には様々な手段があるが、コストが低く効率よく行えるのは 図解をすることだ。

f:id:jaco-m:20211203002447p:plain:h200

あらかじめ図で構造化した情報をダンプし、共有することで聞き手は声から情報を構造化する手間が省け、より重要なことに脳のリソースを割くことができる。

また、声で説明しながら同時に図に起こしていくのも良い。これにより、話し手と聞き手の位置情報を細かく同期させることが可能となる。

そして、少なくとも自分が知っている限り、最もこの取り組みを効率よく、気持ちよく行えるのがMiroだ。

Miroだとこんなに良い

情報をダンプして共有するだけであれば、別にMiroでなくても可能だ。既に多くの人が、Google Docsで議事録を書いたり、PowerPointやGoogle Slidesでスライドを共有しながらWeb会議をしているだろう。

しかしこれらが最適な手段かというとそうではない。

  • WordやGoogle Docsの欠点
    • 文字が主体。文字を読んで理解していくのは脳の負担が大きく、時間がかかる。
    • 構造化した表現が難しい
  • PowerPointやGoogle Slidesの欠点
    • スライド1枚あたりの情報量が限られてしまう。
    • 1枚当たりの情報量を増やすと読みづらい。
    • 情報量を減らすと、スライドを見逃してしまったときのリカバリーが難しい。
    • リアルタイムな追加がやりづらい

Miroだとこれらの欠点を良い感じにカバーできる。

まず会議前に、あらかじめ共有しておくべき情報を書き込んでおく。文字で書いてもいいし、図にしてもいい。 情報量も、冗長でない限りは多少多くなっても構わない。見る人が拡大縮小して合わせられるからだ。

f:id:jaco-m:20211203005003p:plain

会話しながらリアルタイムに図解していくのも可能だ。以下の例は実際に会話しながら起こしたアーキテクチャ図だ。

f:id:jaco-m:20211203005715p:plain

画像を貼るのも容易だし、アイコンのライブラリが充実しているので検索するとだいたい欲しいアイコンが出てくる。

また、話し手だけでなくて聞き手側にも積極的に書き込んでもらうと良い。付箋紙を初めとした使いやすいツールが充実しているので、ブレインストーミングや振り返りにも最適だ。

聞き手側にも参加して貰うことで、少なくともYouTubeやTwitterを見ていて会議に集中していないという状況を減らしやすい。声ではなかなか質問しづらかった事項も、「気になったことがあれば付箋紙に書き出してください」と言っておけば、聞き手側も心理的な障壁が下がる。心理的障壁を下げることはコンテキストのズレを無くしていくにはとても重要だ。

f:id:jaco-m:20211203010330p:plain

組織におけるMiroの活用事例

Miroめっちゃ便利という話をしたところで、自分のMiroの活用について紹介。

自分がCo-Chairとして関わっているCloudNative Daysというクラウドネイティブ技術のカンファレンスがある。先日ちょうどCloudNative Days Tokyo 2021(CNDT2021) を開催したところだ。

event.cloudnativedays.jp

このカンファレンスの実行委員会では、昨年からMiroを積極的に活用している。上記Miroの解説にも、実際にCNDTで使ったMiroボードのスクショを使っている。

使い始めたきっかけ

もともとMiroは自分が前職(Pivotal / VMware)の時から仕事で使い倒していた。

VMwareには VMware Tanzu Labsというサービスがあり、Leanプロダクト開発とXPを組み合わせたLean XPという手法でアプリケーション開発やモダナイゼーション、プラットフォームの支援を行っている。前身のPivotal Labsの体験談をみてもらうと分かるが、ホワイトボードや付箋紙をガッツリ活用してコミュニケーションを取るスタイルを取っている。

コロナ禍以降このサービスもオンライン化を余儀なくされたが、ホワイトボードと付箋紙無しにには仕事ができない。そこでMiroを活用することで、従来と同じようなスタイルで継続することができた。

同じくオンライン化を余儀なくされたのが前述したCloudNative Days。イベント自体もそうだし、実行委員会も直接集まるのが難しくなった。Google DocsとZoomを使ってオンラインミーティングに切り替えたものの、直接会うのと比べるとどうしても意思疎通が難しい。些細な認識違いを発端とするすれ違いも多く発生した。

じゃあどうするか。ここは本業で使っているのと同じく、Miroを活用するのが最善策だろうと。そう思って導入を決めた。

CloudNative DaysにおけるMiroの活用

f:id:jaco-m:20211203011603p:plain

CloudNative Daysの実行委員会では、MiroのTeamプランを利用。

コミュニティ主体のイベントであり予算が潤沢にあるわけではないので、アカウントを所持しているのはアクティブ率の高いメンバーに限っているが、持っていないメンバーに対してもボードのリンク共有を活用して参加してもらっている。

チームに分かれタスクを分担しているが、主に以下のような用途で使われている

イベント企画

f:id:jaco-m:20211203012249p:plain:h400

どんなテーマにするか、どんなコンテンツをやるかといったイベント企画やアイディア出しに利用するパターン。マインドマップや付箋紙を使ってどんどん書き出していく。

前述したWeb会議を効率化する目的もあるが、もう一つ大きな目的としては非同期のコミュニケーションがある。

実行委員はそれぞれ本業を抱えた上でボランティアで参加しているため、ミーティングの時間を潤沢に取るのは難しい。スケジュールを合わせるのもなかなか困難だ。そこで、MiroとSlackを活用して出来る限り非同期でコミュニケーションを行うことで、負担を軽減するよう努めている。

技術的なディスカッション

f:id:jaco-m:20211203013104p:plain:h400

CloudNative Daysでは、オンラインイベントのプラットフォームを内製している。 また、配信についても技術を持った実行委員会メンバーが主体となって行っている。

インフラからコンテナを初めとしたミドルウェア、そしてアプリや配信技術まで、上から下まで幅広いレイヤーのディスカッションを行う必要があり、図を使ったディスカッションは必要不可欠だ。

振り返り

f:id:jaco-m:20211203013306p:plain:h400

より良いカンファレンスにしていくためには、カンファレンス開催後の振り返りは絶対に必要な取り組みだ。実行委員会全体、そして各チームごとに振り返り(KPTを利用) を行い、次への改善へとつなげている。

振り返りでは付箋とタイマー機能を利用している。

コンテンツとしてのMiro

CloudNative Daysでは、実行委員だけでなく一般参加者も参加できるコンテンツとして、Discussion BoardやJob BoardをMiroの埋め込みをを活用して行っている。

f:id:jaco-m:20211203014432p:plain:h400

テーマごとに参加者が質問を付箋で書き込み、それに対して知見を持っている人が付箋で返信していく。同期ないしは非同期のオンラインコミュニケーションを参加者も一体となって行うための取り組みだ。

オフライン開催していたCloudNative Days Tokyo 2019で開催し盛り上がった、ホワイトボードを使って自由にディスカッションをするCloud Native Deep Diveという取り組みが元となっている。

f:id:jaco-m:20190723134414j:plain:h200 f:id:jaco-m:20190723144146j:plain:h200

デブサミでの活用例

別イベントだが、Developers Summit 2021でやったパネルディスカッションでもMiroを活用して大変盛り上がった。

アーカイブは見られないようだが、Togetterのまとめを見ると盛り上がりの様子が分かる。

togetter.com

まとめ

Miroほんと最高なので是非活用して欲しい

HashiCorpに入社しました

本日Senior Solutions Engineerとして、HashiCorpに入社しました。

f:id:jaco-m:20210812121022j:plain

元々前職、前々職からHashiCorpのOSSプロダクトを利用していたことや、The Tao of HashiCorpという明確なプロダクトのビジョンを持っている点に魅力を感じて決めました。

HashiCorpもソフトウェアベンダーではあるのですが、競合するというよりは、どのベンダーのプロダクトとも上手く組み合わせてワークフローを作っていけるというプロダクト作りをしている点(Simple, Modular, Composable) も、CloudNative Daysをはじめとしたコミュニティ活動を行っている身としてはとても合っているなと感じています。

手始めに自宅のvSphere環境をTerraform管理に移行していくところから始めています。VaultもConsul使う形に作り替えていこうかな。

まずはHashiCorpプロダクトについて深く学んでいくオンボーディングの期間に入りますが、これまで以上に発信していければなと思っていますので、今後ともみなさまよろしくお願いします!

Tanzu Kubernetes Grid 1.4を新規構築した

先日Tanzu Kubernetes Grid 1.4が登場

tanzu.vmware.com

TKG1.3.1からのアップグレード方法はmaking先生が書いているのでそちらを見てもらうとして、自分は環境作り直しをしたかったので新規構築してみた。

CLIのセットアップ

まずは tanzu CLI等必要なものをセットアップ。基本的には以下のドキュメントを参照。

Install the Tanzu CLI and Other Tools

Customer connectからVMware Tanzu CLI 1.4.0 CLIをダウンロード(環境に応じてダウンロードするものは変わる)

https://customerconnect.vmware.com/en/downloads/info/slug/infrastructure_operations_management/vmware_tanzu_kubernetes_grid/1_x

そして tanzu のインストールとtanzu pluginのセットアップ、ytt などのCarvel toolを入れる流れ。

OVAテンプレートのダウンロードとアップロード

次にCustomer connectからOVAテンプレートを持ってくる。UbuntuもしくはPhoton、あるいはその両方をダウンロードしておく。

f:id:jaco-m:20210912175126p:plain

ダウンロードし終わったら、 vCenterからOVFテンプレートのデプロイ でデプロイ。その後テンプレートに変換 を行う。

f:id:jaco-m:20210912175426p:plain

このダウンロード&アップロード&変換は govc コマンドを使ってCLIで行うことも可能。そのあたりはmaking先生の記事を参照

Management Clusterのデプロイ

まずはManagement Clusterをデプロイする。CLIを使う方法とUIを使う方法の2つあるが、今回は初回インストールということもありUIを利用する。以下のコマンドを実行すると、 localhost:8080でUIが立ち上がるのでブラウザでアクセスする。もしも踏み台サーバ等で実行している場合は、sshのポートフォワード 例: ssh <踏み台サーバーIP> -L 8008:localhost:8080 を活用するなどしてブラウザから繋ぐと良い。

tanzu management-cluster create --ui -v 9

このような画面になるので、今回はvSphereを選択。ちなみにAWSとAzureを選ぶこともできる。

f:id:jaco-m:20210912175957p:plain

設定画面に入るので、必要項目を入れていく。まずはvCenterの設定。SSH PUBLIC KEYには、今後メンテナンス等でVMに繋ぐためのSSH公開鍵を入れる。

f:id:jaco-m:20210912180232p:plain

次にManagement Clusterの設定。インスタンスタイプはmedium以上が推奨。

f:id:jaco-m:20210912180316p:plain

どうやらTKG1.4から、Control planeのLBにNSX ALBが利用可能になった様子? (これまではkube-vipのみだった)

f:id:jaco-m:20210912180419p:plain

  1. VMware NSX Advanced Load Balancer のところは、NSX ALB利用者向けの設定なので今回は空欄

  2. MetadataもOptionalなので空欄で行ける。

RsourcesのところではvCenter上のリソースを指定。VMフォルダ、リソースプールは予めTKG向けに作っておくのがおすすめ。

f:id:jaco-m:20210912180908p:plain

次にネットワークの設定。作られたManagement ClusterのVMがぶら下がるvCenter上のネットワークを指定する。Cluster service CIDRやCluster pod CIDRは特に理由がなければそのままで良い

f:id:jaco-m:20210912181014p:plain

7 Identity Managementは、認証を外部のプロバイダーにしたい場合に設定する。この過去記事等を参照。

Auth0でTKGのクラスタを認証できるようにする - Cloud Penguins

OS Imageは先ほどアップロードしたOVAを指定。ubuntuもしくはphotonが選択出来る。

f:id:jaco-m:20210912181206p:plain

Register TMCはTanzu Mission Controlが利用可能な方は設定。

一通り設定が終わったら次に進める。すると設定の確認画面が出るので、下の方にある CLI Command Equivalent の内容をメモっておく。これは後々、CLIでのインストールを行う際に有用になる。

DEPLOY MANAGEMENT CLUSTERをクリックしてセットアップを開始。デプロイが終わったら以下のようにVMが作られていることが分かる。

f:id:jaco-m:20210912181505p:plain

Tanzu Kubernetes Cluster(Workload cluster)のセットアップ

次に、実際のワークロードを載せていくKubernetesクラスタを作る。参考にするドキュメントは以下。

docs.vmware.com

クラスタを作成するには、コンフィグファイルを作成してtanzuコマンドでデプロイする形になる。コンフィグテンプレートはドキュメントに記載されているのでコピーし、ファイルとして作成しておく。 今回自分は以下のような設定にした。環境に応じて適宜変更すること。

# CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none

#! Node configuration
#! ---------------------------------------------------------------------

VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 8000
CONTROL_PLANE_MACHINE_COUNT: 1
WORKER_MACHINE_COUNT: 2

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_NETWORK: TKG
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClNV5DBMYmOo5pYMpYE0PzXAFlLbYT46s6a7sGZdr9FIecJakrTtPVm6Po3uFL6qURi6uRQ8VsgeZGzZWWft8yJs1JdTcem8+KIiCenisTT7m9dRaX3EMdvhHyDtFGPSdGSq+blvgKo+HaHUem+Sx8R1lZAESzlZHjCwDxpZc5F/BkB4Jn+WiRgTeMwavOp0FJedNraLwZIHJ9h4kKV5uxIt3VgD5pHMotzjGJXDd2+jrcX6I/gQ/Cq1mXtvIMRoy72vpwF0r2knt1DrOOGi/Z029ZiPbQJl8HjbQSx/7kYPlw+ZI5W5afMSlwcs8qb3SR5ofF06gUftb3Uq/ziD2j                                                               VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_PASSWORD: <PASSWORD>
VSPHERE_SERVER: vcenter.udcp.run
VSPHERE_DATACENTER: Datacenter
VSPHERE_RESOURCE_POOL: tkg
VSPHERE_DATASTORE: vsanDatastore
VSPHERE_FOLDER: tkg
VSPHERE_INSECURE: true
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.9.11.101

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------

ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------

ENABLE_AUTOSCALER: false

コンフィグファイルの編集が終わったら以下のコマンドでデプロイを開始

tanzu cluster create workload -f workload.yaml

Management clusterに加え、workload clusterも構築されたことが分かる。

f:id:jaco-m:20210912182219p:plain

動作確認

終わったら以下のコマンドでkubeconfigを取得し、k8sに接続を確認。

tanzu cluster kubeconfig get workload --admin
kubectl config use-context workload-admin@workload
 kubectl get pods -A
NAMESPACE                           NAME                                                             READY   STATUS      RESTARTS   AGE
avi-system                          ako-0                                                            1/1     Running     0          67m
capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-6494884869-8r5v7       2/2     Running     0          72m
capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-857d687b9d-fxx75   2/2     Running     0          72m
capi-system                         capi-controller-manager-778bd4dfb9-tskmh                         2/2     Running     0          72m
capi-webhook-system                 capi-controller-manager-9995bdc94-7sj5n                          2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-bootstrap-controller-manager-68845b65f8-d7zs5       2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-control-plane-controller-manager-9847c6747-8fzkp    2/2     Running     0          72m
capi-webhook-system                 capv-controller-manager-55bf67fbd5-5shl8                         2/2     Running     0          72m
以下略

無事にKubernetesとして機能していることが確認できた。

その他1.4に関すること

基本的にデプロイの流れはTKG 1.3と変わるところはない。

TKG1.3にはadd-onという概念があったが、1.4からはpackageという仕組みに変更が行われた。そのため1.3からのアップデートの場合はadd-onをpackageに更新する作業が必要となる。extensionsを利用している場合も同様。

アップデート方法は例によってこちらの記事と、あとは公式ドキュメントを参考にするとよい。

VMUG Advantageに登録した

退職にともない、これまで自宅で検証用に使っていたライセンスたちが使えなくなってしまう。

jaco.udcp.info

しかし次の仕事もVMware製品と完全に無縁というわけではなく、やっぱり検証用途に環境は残しておきたい。

ということで、VMUG (VMware Users Group) に参加して、有料のAdvantageに登録することにした。

www.vmug.com

Advantageに登録すると、トレーニングのディスカウントやVMworld参加へのディスカウントがついてくるほか、365日の検証用ライセンスが利用可能になる。

検証可能なライセンスはこんな感じ。

f:id:jaco-m:20210910235505p:plain

Advantageへの登録方法はこのあたりの記事を参考にした

zokibayashi.hatenablog.com

1年、2年、3年と選べるのだけど、思い切って3年のプランにしてみた。

f:id:jaco-m:20210910234757p:plain

(ノ´∀`)ノ