VUI の未来

smarthacks.connpass.com

今回はこちらに参加


オープニング・VUIの市場感 (SmartHacks 山本さん)

  • スマスピ用にアプリを作ってもスマホで使う人が圧倒的に多い現実・・・
  • Google Home よりも Amazon Alexa の方が利用されている。
  • Hey Siri は中々使わなかったけど、一度音声入力に慣れると VUI を色々なところで使うようになる

まとめ

開発して感じたVUIとGUIの未来 (MAMORIO 松本さん)

  • なくすをなくす
    • 最近半額だったような?
    • MAMORIO は 5プラットフォーム(FB Messenger/LINE/Google Home/Alexa/Web Chat)で利用可能
  • 受付システムを Slack からスマスピで喋らす方式へ変更
    • Slack は気付かない場合がある
    • 音なら気付く
  • VUI でしか出来ないものは無い!?
    • GUI より VUI の方が便利な場合はある!
  • VUI が便利な場合の共通点
    • 単目的である(今日の予定など): VUI
      • アラームをかけたい
      • 家電を操作したい
      • 持ち物を確認したい
      • 音楽を聴きたい
      • 今日の予定を知りたい
    • 多目的である(今月の予定など): GUI
      • SNS を確認したい
      • 今月の予定を確認したい
      • メールを確認したい
      • 新聞を読みたい

まとめ

  • 開発して感じた VUI の近い未来 == 単目的のタスクは全て VUI に置き換えられる

スマートスピーカーのアプリ・スキルを作ってみた(仮) 〜エンジニア編&デザイナー編〜 (オプト 久保田さん・平岩さん)

VUI は何故こんなにも魅力的なのか (久保田さん)

  • ジェシー・ジェームズ・ギャレットの UX 五階層モデル
  • 2つのメンタルモデル
    • システムモデル
    • インタラクションモデル
  • キャズム
  • スマスピで何をしているか?
    • デフォルトで出来ること
    • ゲーム・トリビア

Alexa スキルを作ってみた (平岩さん)

  • サンプルから変更したところ(サンプルから変更してくれているのでわかりやすい!)
    • スキル起動時に待機状態になるように変更
    • アドテク用語に反応するスロットを追加
    • Intent を2つにした
      • アドテク用語を説明する Intent
      • アドテク用語をランダムに説明する Intent
まとめ
  • 作ってみた感想
    • シンプルなスキルを動かすまではめっちゃ簡単
    • 色々やろうとするとデバッグしんどい

音声要素技術が利用されているデバイス・サービスのVUIとその取組 (ニュアンス・コミュニケーション・ジャパン 近井さん)

  • 声紋認証は日々学習していくので風邪をひいても大丈夫
    • でも何故かアルコールによる声変わりはダメらしい

LINEが描くVoice UIがある世界 & Clova×IFTTT連携ライブデモ (LINE 立花さん)

  • 登壇中の説明で Clova が動きまくる!
  • LINE のミッション
    • 世界中の人と人、人と情報・サービスとの距離を縮めること
  • IFTTT デモ
    • This: Todoist
    • That: Clova
  • Bot Awards2(仮) が準備中!

まとめ

  • LINE: SMART PORTAL
  • AI: バーチャルアシスタント
  • 日常に溶け込んで人々をサポート
  • IFTTTを使えば今日からあなたのバーチャルアシスタント
おまけ
  • Mash & Room のミッション
    • 一億総キノコ

Google Home で遊ぼう

kotodama.connpass.com

久々に勉強会に参加。
記事を書くことをサボっているのでちゃんと書こうかなと。


Google Homeでつくるスマートホーム (田中みそさん)

  • スマートホーム構成
    • Firebase を起点にラズパイ等で各種制御
      • Firebase へは IFTTT の Webhook
      • もしくは、Firebase Hosting
  • Google Home で何かやるには主に 2 通り
    • IFTTT を使う
    • Google Assistant アプリを作る
  • Firebase -> ラズパイ
    • Firebase への書き込みをラズパイ上の Node.js で監視
    • 家のポートを開ける必要がないので安全
    • ラズパイまで来ちゃえばなんでも出来るぜ!
  • 朝起きたらテレビがついてた
    • マイアクティビティを確認するとちゃんと発言している
    • 寝言に注意
  • ラズパイ -> 家電

まとめ

  • 独自音声コマンドを作るにはとりあえず IFTTT
  • 自宅サーバ (ラズパイ等) で正業を行うにはインターネットからローカルへのトンネリングが必要
  • ラズパイまで辿り着けば大体いなんでもできる

Google Home 用のお遊びアプリを Microsoft Azure 使って作ってみた (ちょまどさん)

  • ちょまどさん PC がお亡くなりに。。。

太田さん

ちょまどさん

  • まっちょまど の実演は懇親会にて!

まとめ

Actions on Googleでできること (山口能迪さん)

  • Google アシスタント
  • 拡張については一部限定公開もある
  • 一般公開は IFTTT / AoG
  • 拡張の流れとても見やすい
  • AoG の特徴
    • 呼び出すデバイス本体へのインストールは不要
    • 音声認識音声合成Google Assistant が担当
    • RPC 形式で JSON over HTTP での通信
    • Dialogflow などを利用することで会話を GUI で作成可能
    • 開発版は非公開のまま稼働し続けられる
      • 前は1週間くらいしか稼働してなかった気がするが・・・
      • 最近は1ヵ月かどうしているとの噂
      • 今はもっと稼働し続けられるのか?
    • 16 ロケールに対応
  • SSML でもっとレスポンスを拡張することができる

Dialogflow tips (fishさん)

  • Dialogflow のすごいところ
    • コードを書かずに自然言語処理が実装できる
    • 対応言語が豊富
    • あらゆるチャットボットサービスに対応
    • SDK が豊富
    • アナリティクス機能(設定不要)
  • できること
    • 会話分析や静的な処理
      • 発言からユーザーが何をしたいのかを分析
        • 挨拶をしたいのか
        • 航空券を検索したいのか
        • 音楽を聴きたいのか
      • ユーザーの発言にどんなパラメータが入っているかを分析
        • 身長、体重、日時、通貨...
      • BOT に必須パラメータがあれば発言するまで聞き返す
        • BMI を計算する場合、身長と体重が揃うまで聞き返す
      • 答えが決まってる会話
        • 「こんにちは」と言われたら「こんにちは」と返す
  • できないこと
    • 動的な処理
      • BMI の計算
      • 航空券の検索や予約
  • Dialogflow を使うと Slack や LINE の BOT としても使える
  • GCP プロジェクト数の上限に注意
    • AoG プロジェクトの新規作成 = GCP プロジェクトの新規作成
    • AoG プロジェクトの削除 = GCP プロジェクトの削除
    • Dialogflow プロジェクトの新規作成 = GCP プロジェクトの新規作成
    • Dialogflow プロジェクトの削除 != GCP プロジェクトの削除

まとめ

  • Dialogflow 便利!!

MAとチビキノコ

ハッカソンに参加するようになってこんなものも作れるようになった!〜

この記事について

この記事は MashupAwards Advend Calender 2017 の 9日目の記事です。
qiita.com

はじめに

ちびキノコとは

ちび × マッシュ&ルーム

ちび

「ちび」とは、ネコの名前であり、
私のハンドルネームやアカウントです。

chibi はほとんど取れないので chibi929 が主です。
chibi929 も取れない場合があるんですけどね。。。

マッシュ&ルーム

http://mashandroom.org
想像せよ!頭にキノコが生えるまで
一億総キノコ

つまり

f:id:chibi929:20171208125953p:plain

キノコに耳と手とヒゲを生やしてネコ化です。

MA とちびキノコ

初参戦は 2016 年の MIZUHO.HACK

この時は、
ペッパー触れない!サーバーサイド触れない!クラウド触れない!IoTできない!
何も出来ません。Android アプリがメインです!
そんな感じです。

その後

  • NTTドコモ×TBS TV HACK DAY
  • 特大ペッパソン2016
  • ペッパソン2017東の陣

と参加し、
気付けば、初めて触ったクラウドAWS ではなく Bluemix という。
Watson 君楽しい!

そして、こんなものも作れるようになった!

Youtube

www.youtube.com
www.youtube.com

Qiita

qiita.com

ちなみにドラゴンボールシリーズ

負債と共には生きたくない

speee.connpass.com

これに参加しました!!

すごく勉強になる良いイベントでした。

執筆が遅くなりましたが、引っ越し後まだインターネットが繋がっていないんです。

という言い訳です。


負債とは

  • 読むのが辛い/時間がかかる
  • 修正するのが辛い/危ない

過去の自分を含めて全てを疑え

こんな時は負債を背負っているはず

  • そんな複雑なわけがない
  • 1分以上読んでもわからないわけがない
  • 一連の処理で行ったり来たり繰り替えすわけがない

負債返済の下準備のタイミング

  • 調査やリファクタをしたとき
    • コードを読み解きながら感じたこと疑問に思ったことはそのままコメントにしろ
    • WikiやConfに書くのではなくソースコードに書け
      • 常に目に入るところに書くという意味
  • 変更を入れるとき

負債の種類を見極める

  • 負債の払い戻し: 返済するべき負債
  • 負債の転換: ベストではないけどベターに返済
  • 利息のみ支払う: コードと共に生きる

なぜ負債を返済する必要があるのか、返済することで何が変わるのか

まとめ

負債があるのは何故か??

  • 時間的な制約、実装者の技術力の限界。など色々ある。
  • ポジティブに考えると「自分たちの技術力が高いので負債と感じる」
  • 「負債vs人」ではなく「負債vsチーム」とする

負債は少しずつ日々返済していくもの

  • 貯まってしまった負債は現実世界同様、すぐに返すことはできない。
  • 負債を返済する時間がないなら不吉な匂いのするコードにコメントを入れる。
  • コメントを入れる仲間(連帯保証人)を増やす

文化を作ろう

  • 「低品質のコードを書くのが悪い」のではなく「低品質のコードをマージする文化が悪い」
  • 技術的負債を混入しない環境・文化作りが大事。
  • 自分がメンテできないコードは Approve するな!

実装よりもリファクタが大変

  • 技術的負債を返済するときは、とにかく幅広い知識が必要。
  • 遅くなれば遅くなるほど、依存関係が増えるため依存モジュールへの知識も必要であり、
  • 後でリファクタしようとすると死ぬことになる。

Qiitaのお話を聞いてキータ

increments.connpass.com

これに参加させていただきました!

なんとも今更感な記事。。。 忙しくて家でPC開く時間が全然なかったんです。。。

貴重なQiita誕生秘話!!

当初は、3名ほどの開発メンバーで、 時間も合わないのでオンラインでアイデア出し、 そして、合宿のような形で原型作り、 そして、またオンラインで作業。という形だったそうだ。

しかも、途中でサービスの方向性を変更しているとのこと。 Q/Aサービスから情報共有サービスへ。

あの使いやすいMarkdown形式も最初から導入されていたわけではなく、 リリース後にユーザーからの要望でプレーンテキストからMarkdown形式へ変更されたとのこと。 確かにプレーンテキストではとても辛い・・・

投稿してもらわないと始まらない!

Qiitaは情報共有サービスとして、記事を投稿してもらわないと始まらない。 そこで、Kobitoなどの投稿のための機能作りを開始。 プロトタイプを試してもらって、フィードバックを貰う。 リリース後のUI変更はあまりできないので、UIの検討・テストは入念に行う。

UIの大規模変更は、大抵の場合は文句しか言われない。だから検討・テストは入念に。 慣れてるものから変わってしまえば最初は使いづらいからだろう・・・。

個人的には「いいね」機能が出来たときに若干使いづらさを覚えた。 今まであった「ストック」機能が小さく残ったので、ストックが逆に使いづらくなってしまった。 とはいえ、人によっては元々Pocket等に入れていてストックをしてない人も多いと思う。

ガイドライン

色々あったガイドライン。 これは、開発者の思想や想いが伝わりきっていなかったとのこと。 「プログラミング」という言葉の定義が曖昧なのも問題があるとは思うが・・・

実際、当初ガイドラインに記載がなかっただけで、 「プログラミング知識を共有しよう。」などQiitaには至るところに書いてある。 思想としてはプログラミングの記事を書いて欲しかったそうな。

個人的にはいわゆるプログラミングの記事だけでなくて、 IT技術系の記事ならなんでも良いと思うんですけどね・・・。

「いいね」と「編集リクエスト」

恐らくこれには開発者の想いが詰まっている。 「ストック」はどちらかというと「後で見る」。後で見るためのストックではなくて、 とにかく良い記事に対して「いいね」を気軽に付けて記事を評価したい。 そんなところから「いいね」が誕生。

:+1: ができれば :-1: は?という話になる。 しかし、Qiitaには「編集リクエスト」という機能が存在する。 つまり、良くなかった記事が「投稿者の編集」もしくは「利用者の編集リクエスト」によって良い記事に変わるかもしれない。 だから :-1: は用意していないのだ。

ブログの記事は、執筆者が責任を持って内容を最新化しない限りは古いままだが、 Qiitaは編集リクエストによって、古い記事を新しいものへと変えることができる。 記事をみんなで育てていくのがQiita。

まとめ

yaotti さん、takoratta さん のお話を聞けてよかったです。 中の人の想いが伝わる良い会でした。 開発者の想いを利用者に伝えるのは大変ですね・・・。

私もQiitaを活用させていただいておりますが、最近も編集リクエストをいただきました。 「こっちのタグのほうがフォロー数多いですよ!」という編集リクエストでしたが、 どんなに小さくても編集リクエストをもらえるととても嬉しいですね。 むしろ小さい方がマージしやすくて良いかも!と思っています。

自分でも何回か編集リクエストを出したことがありますが、 ただ、編集リクエストをいただいた方へはマージという形でしかお礼ができないのが若干寂しく感じてます。 もうちょっとだけ編集リクエストを活発的に活用して行こうと思います!