Microsoft Teams 会議中にサインイン不要のURLで会議に招待する

Microsoft Teams の会議中に
外部の人や、取り急ぎ会議に参加させたい人を
サクッと!サインイン不要で!
「ゲスト」として会議に招待する方法。

① 招待URLを取得する。

会議中に「ユーザー」のメニューから、
ハイパーリンクのアイコンをクリックするだけ。

f:id:vemi:20200422003210p:plain:w500

なんて簡単なんだ!
っておもうじゃないですか。

② URLをゲストに共有する。

書式機能付きチャットや、HTMLメール などで直接相手に送ってもよいのですが、
「今すぐこの会議のURLテキストがほしいんだ!」
というときに、初めてだとちょっと手こずります。

とりあえず何も考えずにテキストエディターにペーストしてみます。
するとどうでしょう、URLが無い!

        Join Microsoft Teams Meeting
      Learn more about Teams

これ、 ハイパーリンクが埋め込まれた書式クリップボードに保管されているわけなのだ。。
書式に対応しているアプリ(※)に貼り付けるなどして、URLを取得します。

※ 書式に対応しているアプリの例
- Microsoft Teams
- Office 製品
(Word、ExcelPowerPointOutlookOneNote
- Slack

個人的な好みは OneNote です。

f:id:vemi:20200422000048p:plain:w500

③ ゲストの参加を受け入れる。

ゲストは受け取ったURLを開いて、
自分の名前を入力して参加を申請します。
(この際、サインインは入りません。)

招待者側からは「ロビーで待機中」という状態で見えます。
✔(承認)するまで会議の画面や音声は互いに共有されません。
f:id:vemi:20200422002642p:plain:w400

ためしに、ロビーで待機中のユーザの ×(拒否)を選択すると、ロビーから追い返されます。
f:id:vemi:20200422002452p:plain:w500
「申し訳ございませんが、会議へのアクセスを拒否されました。」
それはそう。

さいごに

そんなもんで、自由に使える組織さえ持っていれば
Microsoft Teams も Web飲み会ができちゃうんだよ!!

組織も Azure Active Directory で誰でも無料で作れちゃうし。
azure.microsoft.com

でも、もうちょっとスマートな、単純な会議URLを取得する方法無いのかなぁ。
まぁ、すぐ慣れるかぁ。


#14 Microsoft Teams 会議中にサインイン不要のURLで会議に招待する

時間を管理する

昔は、会社の業務が無い日はだらだらと空っぽの1日を
過ごしてしまうことが多かったものです。

でも、特にここ数か月は以前からチマチマとやっていた個人開発のほかに、
開業準備やそれに伴うセルフマネジメントの勉強など、
会社の業務以外の時間の有効活用に迫られてきています。

時短術などググればいろいろ出てきますが、
自分はこんな工夫をするようになりました。

まずは記録する

Toggl で時間を記録するようになりました。
toggl.com

効果は大きく2つ。

まず、時間管理をすることで意識が変わります。
会社の業務をしているときと同じ質の時間感覚が持てます。

さらに、何に時間を費やしているかを分析できるので、
ライフワークの改善活動ができるようになります。

Toggl 自体は数年前から登録しているのですが、すぐ途切れてしまいます。 最近、なってようやく染みついてきました。

続けるための注意していること

  • 記録対象を明確に定義する。(睡眠時間以外の全て、など。)
  • 記録は「ざっくり」からはじめよう
    事細かに記録しようとすると、絶対に続きません。
    例えば「洗濯」「料理」ではなく、「家事」。大きく7分類で管理しています。
    • free
    • セルフマネジメント
    • ライティング
    • 開発
    • 勉強
    • 家事
    • 会社
  • ツールに依存する
    継続する・習慣化するには、ツールに依存するのが有効と言われています。
    どうすればツールにちゃんと依存できるかは、自分も正直悩ましいです。。

あとは収集結果から、「free」の時間長すぎたので、来週は勉強の時間を XX時間に増やそう。
とか、「開発」は XX時間かけているのにあまり成果が出ていなかったな、作業効率の上げ方を考えよう。
などなど、改善活動の世界です。

テレビをつけっぱなしにしない

「テレビなんて捨てちまえ!」などというストイックな発想は持ち合わせていないのですが、
やっぱりテレビは気を引かれすぎてしまいます。個人的にラジオをつけておくのが好みです。

見たいテレビ番組は録画して倍速再生

フリータイム枠の中でも、テレビを見る時間ってもったいないんですよね。
レコーダーだと 1.2 倍程度なので、PC 経由で2倍速再生で見るようにしています。

(一部の本当に好きな番組だけはリアルタイムで見ます。)

フリータイムを設ける

ただ寝る、出かける、など free の時間枠を設けましょう。

さいごに

そんな窮屈な生き方しているの?と思われるかもしれませんが、
自分はこう言う管理ができていないと、「1日をムダにした・・・」
というのが逆にストレスになっちゃいます。

性格や仕事の考え方によっても変わってくるとは思いますが、
セルフマネジメント能力が求められる時代なので、
改めてこの辺の意識を持っていこうと思います。


#13 時間を管理する

横文字・カタカナ文字の使いすぎ、ってどこから使いすぎなの??

時折、横文字・カタカナ文字の乱用問題が取り上げられます。
「日本人なら日本語を使え。」わかります。

横文字を多用する奴は意識高い”系” (意識が高いわけではない。)
的ないや~な感覚もよく分かります。

ちょっと横文字が並ぶと自分でもゾッとするときがありますが、
いや、しょうがないよなぁ。と言い聞かせています。

SIerである自分の周りでは、
「クリティカル」「アサイン」「フィックス」あたりは十分馴染んでいますが、
「コンテキスト」「インタラクティブ」「トリアージ」とかは
訳せそうで訳せず、時折補足しながら使うようにしています。

バグっぽい用語は、英語の障害管理システムを使用している
という兼ね合いもあるんですけどね。

「このBug、今のところ Priority は Low なんだけど Severity が不安だから早く Triage して!」

みたい会話は客観的に見ると地獄絵図。。

・・・なんて内心で配慮して生きているなかで、
「ロックダウン」「オーバーシュート」という表現が
丁寧に説明されているにもかかわらず世間から批判を浴びている様子をみて
(世の中こわいなぁ)とおもいましたまる

結論、業界とか界隈にかかわらず、コミュニケーションの常識として、
チームや相手に合わせて自然と翻訳できる人間でありたいと思うものです。


#10 横文字・カタカナ文字の使いすぎ、ってどこから使いすぎなの??

「メソッド xxx は 型 Abc であいまいです」エラーが環境によってでるとかでないとか。

今さら感つよめな内容ですが・・・

EclipseJava開発で、「メソッド xxx は 型 Abc であいまいです」エラーが
出る環境と出ない環境がある、という相談を受けました。

普段ならそんなんチャッチャと直しちゃえ!ですが、
大人の都合ですぐに改訂はできない状態だったんですよね。

JDKバージョンは同じ。Javaのエラー/警告の設定も同じ。
差異があるのは、Eclipseのバージョンでした。

結論から言うと、Eclipse 3.x系 と 4.x系 のコンパイルの差異でした。
ネットの情報も薄かったので簡単に検証した結果を書き残します。

検証結果

Eclipseのバージョン 結果 検証バージョン
4.x系 「あいまい」エラーが出ない 2019-03(4.11)
3.x系 「あいまい」エラーが出る 3.7、3.5

古いバージョンではエラーになる、ということになります。
Javaバージョンは JDK 1.6 を使用しました。

検証コード

ApiA

package samplepj;
public class ApiA {
    public static String getItem() {
        return "a";
    }
}

ApiB

package samplepj;
public class ApiB {
    public static String getItem() {
        return "b";
    }
}

Main

package samplepj;

import static samplepj.ApiA.*; // ←クラスAをすべて static import
import static samplepj.ApiB.*; // ←クラスBをすべて static import
import static samplepj.ApiB.getItem; // ←重複した特定のメソッドを static import

public class Main {
    public static void main(String[] args) {
        System.out.println("ApiA:" + samplepj.ApiA.getItem());
        System.out.println("ApiB:" + samplepj.ApiB.getItem());
        System.out.println("結果:" + getItem());
    }
}

実行結果(4.x系)

ApiA:a
ApiB:b
結果:b

実行結果(3.x系)

Exception in thread "main" java.lang.Error: Unresolved compilation problem: 
    メソッド getItem() は型 Main であいまいです

    at samplepj.Main.main(Main.java:12)

補足1、コンパイル仕様について

f:id:vemi:20200329024402p:plain

トラブル事例として書き残しましたが、
「そんな危なっかしいコード書くな!」
っていう根本的な認識はもっておくようにしましょ。

* による import と メソッド指定による import に優先度がついたものと思われます。
試しに、検証コードの「重複した特定のメソッド」で呼び出すApi
ApiA に変更してみたところ、結果も変わりました。

実行結果(4.x系)

ApiA:a
ApiB:b
結果:a

こんなコードになること自体がめったにないので、勉強になりましたぁ。
import の優先度とかはどこかに出典があっても良さそうだけど、見あたりませんでした。
ご存じの方いらしたら教えてください。

補足2、Eclipseのバージョンの見分け方

Eclipse のバージョン違い、という最初の直感は、
偶然、Eclipse のメニューの背景色によって気になったのでした。

|Eclipse のバージョン| 色合い(?) | | Eclipse 3.x 系 | 灰色っぽい | | Eclipse 4.x 系 | 薄青っぽい |

「これは古い Eclipse ・・・!」って目印にしています。


#9 「メソッド xxx は 型 Abc であいまいです」エラーが環境によってでるとかでないとか。

SIerのウォーターフォール開発が陥る負のスパイラル

ウォーターフォール開発は限界を迎えている、とたまーに言われますが、
しかしウチのご近所にこの流れははなかなか伝わっていません。

「ウチのご近所」は、基幹系システムに代表されるような SoR のあたりです。
ウォーターフォール一択、という風習にいまだ変化の兆しはなく、
これからもしばらくはウォーターフォールが主流のままであり続けると思います。
(終わりの時は近づいているようには感じます。)

もちろん、今すぐウォーターフォールなんか辞めちまえ、
などといった非現実的なことを言いたいわけではありません。

モダン開発からイテレーティブな概念を学んで、
改善活動を回せるようになって欲しいのです。

現状で主立った改善活動が回っていないような組織では、
開発プロセスを見つめ直す」ことすら阻害されています。

ウォーターフォール開発チームにおけるその阻害要因を考えてみます。

目の前の仕事のキャパオーバー。

開発プロセスを考えられる人って、ウォーターフォールに於いても
上流でクリティカルな役割を担っているんですよね。

この状態を放置している組織は、持続性の低い
”一部のメンバー”の苦労に依存し続け、やがて脆く崩壊します。

ステークホルダーのしがらみ。

SoR(System of Record)の開発案件の多くは、
ミッションクリティカルに直結するという性質もあり、
顧客のトップダウンな意思決定が既に進行していることが多いです。

それなりの予算とミッションクリティカルがついてくるので、
ステークホルダーの賛同とアグリメントを得るには
それなりの労力とカリスマ性が求められます。。

逆に、一言返事で「うん」という人はたいてい
何も考えていないので、議論に巻き込んでいきましょう。

そして、ウォーターフォール構造そのものの問題。

何点かあるので、箇条書きで挙げます。

  • 上流で決めるべき要件、仕様、設計を正しく定義するのは困難です。
  • 上流の判断誤りや要件追加や仕様変更が発生すると、
    軒並み工程を辿り直す必要があります。
  • しばしば、プロジェクトの後半で障害が終息しない状況で
    初めて原因分析が機能し、設計がダメダメであることが発覚します。
  • 手戻りがない”前提”(但し、手戻りがないことなどない)で仕事をするので、
    コーディングやテストの自動化への関心が比較的薄いです。
    この、絶対発生するのに、発生しない「前提」で仕事をする馬鹿馬鹿しさ、どうにかしたいわね。。
  • 1つのライフサイクルが直列で長いので、改善活動プロセスが機能しにくいです。

これらは、組織やチームのスキルや体質
そのものの問題を含む、改善活動がやりづらい背景です。
あくまでウォーターフォールだから改善活動ができない、
というわけではもちろんありません。

そんなスキルや体質を踏まえ、改善活動プロセスを
機能した状態に持って行くのが重要です。

じゃぁ、どうするか??

組織のすみっこにいるぼく達は。

既にある構造のなかで改善活動に漸進的に取り組んで、
小さな実績をコツコツと積み上げていきましょう。

実績から関係者の理解を少しずつ得ていくのが組織を強くするのだと思います。

ウチのチームはスクラムの概念を導入しています。
イテレーティブでシンプルな方法論なので、
改善活動プロセスが格段に動かしやすくなります。

スクラムの中途半端な導入は混乱や品質低下の元です。
 やるなら徹底的にやるべし。

さいごに

うまくいっていない開発プロセスを改善したいと考え、
行動する人たちはごくごく一部のように感じます。

SoR は「維持」が重要視されているということもあり、
性格として「変化」を望まない人が多いのもあるかもしれません。

個人が「変化」を望まないのは構いませんが、
それなくして苦労するのは自分たちなんだよ、
という意識を持ちたいものです。

この意識が持てない組織は、日々「変化」する世間のなかで
駆逐されていくんだと思います。

ただし気をつけなければいけないとおもうこと。
「誤った破壊的活動を提案していないか。」
組織である以上、これは慎重に見極めなければなりません。


言いたい事は 1/3 くらいなのに、なかなか言葉がまとまらないなぁ。
読み物書きは難しいですね。。

#8 SIerウォーターフォール開発が陥る負のスパイラル