hugtech どうも。こんにちは。hugtech.io です。普段はオランダにいて、Shifter のお手伝いをしながら アレクサのコミュニティとかAWSのコミュニティとかの界隈にいます。
先日 AAJUG のミートアップでタイマー特集ハンズオンというものをやりました。資料を作るために、AlexaCookbook のコードを参考に私自身もあまり使ったことのないタイマーの勉強を進めました。そこでふとサンプルコードに感じたことをこのブログで書こうと思いました。ハンズオンのコードを書きながら、サンプルコードのわかりづらさがどこか？という点について、自分なりに答えがでたので、今日はそれをお伝えしたいと思います。
アレクサのコードを書くときの参考になればうれしいです。
長い名前、深いJSON、そして、リクエストを神オブジェクト化する ASK SDK
alexa のリクエストはスキルの全ての機能が表現されたJSONです。比較的属性の名前が長く（これも全ての機能を包含しているので、名前が長くなるのは必然だったりしますが）そのおかげで、メソッドチェイニング がすぐに長くなります。
ASK SDK を使うとき、handle 関数が呼ばれると、Alexaのリクエストを包含するhandlerInput に必要な関数群を全て追加します。オブジェクトはさらに大きくなります。コードをクリーンに保つために、ask-util などでコーディングを簡素化してくれるツールやライブラリを利用することをおすすめします。
インプット、ロジック、アウトプットが一つのオブジェクトとなったコードのわかりづらさ
ASK-SDK は モジュール志向 で設計された ライブラリで、インテントに対するハンドラー関数をアタッチ・デタッチする という構造を持ちます。AlexaCookbook のコードはhandle 関数の中、入力の処理、スキルのビジネスロジック、出力となるレスポンスの構築の全てが含まれています。そして、Alexaの構造上 入力と出力のハンドリングは力技のコードになる傾向が強いと感じます。サービスの振る舞いが隠れやすい特徴があります。そのため、サンプルコードで説明したい機能がコードに埋もれれてしまいます。
Global ゆえのローカリゼーションロジック
Alexa は VUI という特性上 インタラクションはその土地のカルチャーに大きく依存すします。語順やスラング、国民性などだ。ローカリゼーションのコードは本質を説明したい場合は不要なコードです。極端に言えば、英語だけあれば十分なんです。
インターフェースを分けるという考えかた
アレクサのレスポンスは、「発話する」というインターフェースです。発話は変化に富み感情が想起できるような設計が私はよいVUIだと思います。そのようが、より人間的で、使っていて楽しいです。それはつまり、発話させるためのコードを充実させて、豊かな会話設計に注力したいということです。極論だけれど、発話はコミュニケーションデザイナーの領域であって、UXデザイナーや、コミュニケーションデザイナーでも見れるくらいのシンプルさが必要ではないかと思います。そこで、会話部分は別のファイル、モジュールに分けて、デザイナーさんが想起しやすいような配慮が必要と思います。前回のポストでも書いたのですが、発話部分はあくまで「脚本の一部」なのだから。
サンプルコードをへの提案
これらのことから、サンプルコードを読む際には、レスポンスビルダー、canhandle、localisation コードを削除して読むことをオススメしたいです。