構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

Amazon Echo Dotがやってきた&次の日曜日はAlexa Day 2018

いつになっても招待されないので諦めかけていたら、先週後半になって不意に招待されたので購入しました。

定番のブラック…ではなくてホワイトです。

実は、同じホワイトのGoogle Homeのほうを先に購入したのですが、大量パケット送出問題(スリープからの復帰時)などがあってしばらく様子を見ているうちに(加えて、週末が忙しかった)Amazon Echo Dotもやってきた、というわけで。

 

で、Google Homeより先に開封し、初期セットアップを行い、これからスキルの開発テストを始めるところ、です。

とりあえず、この本を読みながら進めていますが、執筆時に https://alexa.amazon.jp/ が存在しなかったせいか、記述通りにセットアップを進めると設定や日本語スキルのインストール等、多くのことができなくなるので要注意です(もっとも、この登録先サイトと言語選択の話はWeb上でも良く言及されているので、結構知れ渡っていると思います)。

www.shuwasystem.co.jp

最初は記事をなぞりつつ、入出力するワード/文章だけ別のものに入れ替え、SSMLで喋り方を調整するところから始める予定です。

…ちょっとAlexa Dayまでには間に合わないかな?

alexaday2018.jaws-ug.jp

一緒にAlexa Dayに参加する後輩の1人が、前日に大阪のハンズオントレーニングに参加するらしいので、どんな内容だったかを聞いてみる予定です。

developer.amazon.com

「選択肢を3つ用意しろ」「比較表を出せ」とかいうの、いい加減やめにしない?

ブツの購入やサービスの契約の話ですが、

「偉い人に決めてもらうから、競合商品を最低3つアイミツ取っといて」

「判断しやすいように比較表を用意しといて」

ということを言う人、そろそろ絶滅するかと思いきや、未だに健在なようです。

もちろん、すべての場面でこれがいけない、というわけではないのですが、

  • すでに要件を満たした商品・サービスの存在がわかっている
  • それを選んでも特に問題はない(金額的にも許容範囲)

にも関わらず「比較検討も価格交渉もせずに指名買いするのはけしからん」というクチです。

 

「競合させれば安くなるのにそれをしないのは職務怠慢」だそうですが、

  • 今はスピードの時代。「時間」の価値が以前より相対的に高くなってるけど?
  • 短期~中期的には人手不足の時代。果たして「(すでに1つある)選択肢を複数に水増しする」業務が、貴重な労働力を投入すべき対象なの?
  • 人の「モチベーション」と「判断力」には限りがあるのに?
  • 目先のコスト削減のために、かえって最適解を逃す結果にならないの?

であってもなお、それが必要なことなのか?一度よく考えてみるのが良いかと。

 

複数商品やサービス、あるいは販売業者を競合させると、大体、

  • 価格競争できない先と、しない先が脱落する
  • 残った先は、大体価格や(表面上の)条件が同レベルになる

という結果になり、それを示された「偉い人」は、

  • 根拠のない「勘」やイメージ、雰囲気(「ふいんき」)で選ぶ
  • 「選びにくい」と不機嫌になる(酷いと「やり直し」までさせる)
  • ときには「お前らが使いやすいのを選んどけ」と言って選択の責務を「放棄」する(「お前らを信用してるから」という脅し文句を添えて)

というアクションをおこしがちです。

「判断」という行為は大変消耗するから、それをできるだけ避けようとするのはある意味当然ですね。

で、残った先のいずれかを選択すればハッピー、かというと…そうでもない。

先に「価格競争をしない先」が脱落する、と書きましたが、信念や明確な根拠をもって価格設定をしている事業者が「本来なら最適解だった」ということがよくあるからです。

ああ、もったいない。

そうでなくても、価格競争に引きずり込まれた「選択肢」のすべての事業者が、何らかの「モチベーション低下」を起こしてます。

 

さらにそれ以前に、特にエンジニアなどの専門能力を持つ人が業務にあたる場合、

「すでに確実性の高い選択肢が1つあるのだから、余計なインターバルを挟まずにさっさとそれを選んで業務を進めさせてほしい」

と思っていることが多いはず。

そこで余計な時間を使って気分良く業務を進めさせないということは、その人のモチベーションを大きく下げる=アウトプットの品質を大きく下げるリスクを孕むことになります。

 

「ゆっくり確実に判断してコトを進めるのが良かった時代」は過去のこと。今は「ベストよりベター」でサイクルを速く回す時代です。

確固たる信念を持って時代や流行に乗らないのは良いと思いますが、自分や「偉い人」の判断の正しさに自信が持てないからといって、部下に「入念なお膳立て」をさせるのは、いい加減やめましょう。

 

研修や勉強会で説明するときのこと

私自身は社内や部内の勉強会、研修会などで何かを説明する機会はめっきり減ったのですが、色々見ていると勉強になります。

 

 多分、先に「停止(シャットダウン)=閉店ガラガラ」を思いついたのだと勝手に想像していますが(書いてないけど)、こういう例えをいくつか持っていると話が通じやすいです(特に、相手の趣味や知識に合わせてチョイスできるとベター)。

RTで、

 と書きましたが、当時何に例えたかというと、一番スタンダード(多分)な

  • ID=キャッシュカード
  • パスワード=暗証番号

でした。

で、当時はなかなか理解してもらえませんでした。

何がまずかったのかというと、

  • パスワードと暗証番号はいずれも知識情報だが、キャッシュカードは「モノ」なので、ID(知識情報)との対応がイメージしにくい
  • キャッシュカードはクレジットカードと混同しやすい。クレジットカードは「カード(物体)」「カード番号」「セキュリティコード」「氏名」「サイン」「暗証番号」「有効期限」など、ID・パスワードに対応しそうな要素がたくさんあるし、使う場面によってIDとパスワードに対応する要素が変わることがある

あたりが原因だと思います。

 

また、別の話ですが、

 というネタも、説明する相手を選びますが(このネタがウケる相手が身の回りに1人しか思い浮かばない)複合(ユニーク)キーを覚えてもらうついでに

  • 同一人物が別の名前を襲名する度にレコードをUPDATEすべきか、それとも元のレコードを残して新しいレコードをINSERTすべきか
  • ただの複合ユニークキーではなく主キーだったらどうか(特にMySQLを使う場合)
  • CHECK制約を付けるべきか付けないべきか。付けるとしたらどう付けるか

などの「発展テーマ」につなげることができます。

 

先のMySQLの例では、(普通のMySQLには存在しませんが)MySQL Cluster(NDB Cluster)のシングルユーザーモードの説明を「シャッターは途中まで上がっているけれどお客さんは入れない状態」(店員さんが開店準備中)とでも表現すると分かりやすいかもしれません(ワンオペか?と突っ込まれそうですが)。

※その他、アニメネタやアイドルネタで説明できるとすんなり分かる受講者が多そうですが、生憎私はそこの分野が弱いです。

 

「何かと関連を持たせると覚えやすい」というごく当たり前の話なのですが、教える側になるとついテキストやレジュメに書いた必要事項をすべて説明しなければ…という方向に行ってしまい、受講者の理解度を上げる工夫がおろそかになりますね。

※理解してもらったら、今度は「すぐに実践してもらう」のが重要ですね。

 

あと、「MySQL サーバの起動と接続の違いがわからない」なんて、普段当たり前にMySQLを使っている身からすると思いもよらない視点からの質問で、こういう質問を臆することなくできる受講者もなかなか良いと思いました。