起業系の本を読んでた
2019年になるわけなので、英語とかエンジニアリング以外のお勉強も年末からしてました。
以下の本たちを読んでました。
僕は起業経験がないので、あくまで読んだ感想のメモです。
１．サクッと起業してサクッと売却する 就職でもなく自営業でもない新しい働き方
３．社員ゼロ! 会社は「1人」で経営しなさい (アスカビジネス)
あとは去年、退職前の会社員時代に買っていたのが以下。
６．ゼロからいくらでも生み出せる! 起業1年目のお金の教科書
他にも合同会社系の本は結構読んでました。
なんで読んだの？
会社員を辞めた時に、起業はありえると思って当時は読んでいました。
年末年始で読んだのは、2019年どうするかということで再勉強が必要でした。
フリーランスでも良いですけど、今後の働き方の1つとして考えたためです。
とはいえ、どこかの企業に属する可能性もある状態です。
関心が高い企業も数社ありますし。。
※入れるかはもちろん別
読んでみてざっくり
合同会社と株式会社の違いは結構わかりました。
個人単位なら出資金そのままの合同会社でいい気もしますけど、
エンジェル投資家とかVCが絡むなら株式会社じゃないと話にならないわけですね。
株の3分の1持ってる人は拒否権とか行使できるんですね。。
とはいえ、VCとかに株をお買い上げいただくとなると、何割の株をお渡しするのかとか駆け引きになりそう。。
1．Exitをどうするか
サクッと起業してサクッと売却する 就職でもなく自営業でもない新しい働き方
に、強く書いてありますが、
会社は最終的には売却するか畳むかの2択になります。
自分が亡くなったら別でしょうけども。
個人ではなくて「法人」で「法」の「人」なので。
個人で起業して、それを死ぬまで続けるか、Exitするかということになりますが、
Exitする場合はM&AかIPOかになりそうですけど
そもそもタイミングわからなくないですかね？
これは会計知識があるのは前提として、連続起業家とか、とにかく経験を繰り返していくことでタイミングはようやくつかめていくような気がします。
なので、サクッと売却は簡単にはできない気が、、
2．家計簿書いておいて良かった
どの本を読んでも、
「お金管理は重要ですが、家計簿をつけてないような人は失敗しやすい」
という旨が書いてあります。
家計簿を書いておく習慣は僕にはあるんですけども、それをやっておいてことは結構プラスに働きそうです。
3．本によって事業計画のとらえ方が違う
会社をやるなら、事業計画が必須ですが（当たり前かもですけど）
本によって扱いがかなり異なりました。
特に銀行融資を受けるなら、それなりに綿密な事業計画書が必要になります。
なので「しっかりやりましょう」という本もあれば
個人が生きていくレベルで起業するんだから、会社を大きくはむしろしない。
その場合は、必ずしも民間や投資の融資がなくても、自分や家族・友人のお金でどうにかするので、
えいやで事業計画を作ってしまって、「やりながら変えていけばいいじゃない」。
という本もあります。
※
知人類からお金を借りるのを前提ってどうなんだろうか。。
「上場めざしてイケイケでいくぜー」
みたいな場合でなければ、こじんまりでも個人的には良いと感じました。
4．役員報酬を決めるのが大変な印象
1人で株式会社をやるなら融通が利くんですけども、役員報酬の金額設定が結構大変そう。
株式会社の手続きとか、流れとかを調べていると
役員報酬
が厄介だと思いました。
法人税とか住民税とかもありますし、社会保険料とかも計算が大変なんですけど、
その基準の数値として役員報酬が計算単位になる流れに見えます。
けどこれ、個人の会社だったら役員報酬はゼロ円で、役員賞与だけでも良くね？
って気もしました。
適正価格がわからない上に、変更もしにくい。
5．自分軸と市場軸
自分でビジネスモデルを考えるわけですけど、その際に
自分のやりたいことを自分軸、市場感を市場軸とした場合、
市場軸を重視しすぎるとたいていダメらしいです。
やりたいことありきで起業しているのに、市場感にひっぱられると
一時的には儲かるかもですけど、続かないことが多いとか。
たしかにそうなると、なんのために起業したの？となるのもわかる気がします。
起業してやりたくないことやるとか、メンタル的にも折れそうです。
6．一番大事なのは「何をやりたいか」
アイデアがゼロでも起業できますー
知識がゼロでも起業できますー
お金がゼロでも起業できますー
とかは、うたい文句にあるんですけども、結局のところ
何をやりたいの？
に集約されるという印象です。
アイデアも知識もお金も「どうやるの？」の話であって
「何をやるの？」
がないと何にもならないです。
そりゃそうだ。
気づいたところ
上記以外にも、もろもろあるんですけども
「何をやりたいか」
を考えた際に、僕はやりたいことがありまくるタイプなので、事業が1つは逆にしんどそうだなと気づきました。
経営者になると、エンジニアリングも含めて、お金回す時間や書類関係がどうしても増えてしまいます。
それが嫌で、会社員を辞めた後に起業ではなくて、しばらく無職してフリーランスになったわけですが
とはいえ、社会的に大きいことをやりたいとかになると、やっぱり会社じゃないとできないと2018年でまざまざと感じたので
さて、どうしたもんかなと。
それに、VUIでフリーランスはやっぱり限界ありますね。
そもそも企業レベルでも投資どころか、下手したら投機レベルなのが2018年でした。
他の仕事も併用すればいいんですけども。
どこかの企業に属しながら、自分で株式会社やるってのもできなくはないでしょうけど、圧倒的に時間と体力が足りない気もします。
まとめ
株式会社起業のだいたいの流れの知識はつきました。
とはいえ、経営しながら
「やりたいこと」
を取捨選択するのが僕には現状、しんどそうだなぁとも感じた次第です。
余談
ちなみに僕の中で
会社員：マネージドサービス（RDSとか）
個人事業主：EC2
起業して社長とか会社役員：物理サーバー
みたいだなとは思いました。
僕は2019年はこうして生きていく
2017年末に以下の記事を書いていたので、今年もやろうかと。
ですます調にはしない。
2018年に重視することを決めてたので、その結果
1．健康第一
2．QAエンジニアとしてのインプット、アウトプット
3．自社組織のシステムやサービス類の品質を高めていく
4．サービス志向であり、技術志向であり続ける
5．視野を広げる活動をしていく
それぞれの結果を振り返る。
■1．健康第一
運動はジム契約したけど、あんまりいけてない。。
食事のバランスはCOMPとかBASE PASTAとかで攻めた。
結果的にBASE PASTAが一番長続きしているのと、間食はボトルガムを噛んでる。
睡眠時間は確保できてた。
けど追い込んでた時はそうでもなかったなー。。。
■2．QAとしてのインプット、アウトプット
QAエンジニアとしては働くなるんだけど、1月から3月は本当にJSTQBの認定を受けたり、SeleniumとAppiumをごりごりやってた。
それ以降はVUIで結構インプット、アウトプットしたと思う。
けど、アウトプットの数は多かったし、特に登壇後に録画映像は毎回何度か見直した。
とはいえPDCAが足りてないし、アウトプットしっぱなしの傾向が強いと今は思う。
これは来年の課題。
■3．自社組織のシステムやサービス類の品質を高めていく
会社辞めちゃいましたね。
とはいえ、請け負ったシステムやサービスはそれなりにやったと思う。
■4．サービス志向であり、技術志向であり続ける
サービス志向ではあり続けたとは思う。
エンジニアは技術志向、サービス志向、マネジメント志向は分類できると思ってるけど
僕は技術を貫く技術志向ではなくて、サービスやプロダクトを作るために技術を学ぶスタイル。
VUIに関しては、Node.jsそのもの初体験から入って、Lambda、Dynamoから入り、AWSをそこそこやった。
それは結局、VUIのスキル・アプリを作るために必要だったから、僕はサービス志向なんだろうなぁ。
とはいえ、AWSがいじれるようになってくると面白くなってるところ。
入門なクラウドプラクティショナーは受かったけど、あのレベルで止まることはない。
もっと上に行きたい。
■5．視野を広げる活動をしていく
これは、相当やったんじゃないかな。
ガンガン登壇して、いろんな会社回って、本もゴリゴリ読んで、技術書典で本を出した。
もちろんブログも書いた。
けど他業種へのアクションが足りてないなー。
2019年はどうしますかね
このブログを書く予定だった12月30日、の前日。
「2018年良かったなー」
というのが、大どんでん返しすることに。
というわけで2019年は、働き方が大きく変わることは確か。
やることとして明確なのは
１．英語
２．VUI
３．AWS等のクラウド
４．イベント、ブログ、本などのアウトプット
なんだけども、アウトプットもしっぱなしではなくて、見直して改善していくことを目指す。
当たり前っちゃ当たり前だけどこれが満足にできてなかった。
2018年は組織に属さない状態で自分をフルフルに活用して、どういうところで自分が活かせるかがわかったのが一番大きいのでそれをどう活かすかが課題。
とはいえ個人でできる範囲は2018年結構やったと思ってるので、組織でどうするかになっていくのが2019年かなー。
勢いで無職になり、駆け抜けた2018年を振り返る
2018年が終わりそうです。
なので振り返るブログを書きまする。
まとめ
「駆け抜けた」
という言葉がふさわしい気がします。
あるイベントで、ある人が僕に言ってくれました。
「しょーさん、どこまでいくんだ！もういけるところまでいってくれ！！」
ありがたいですね。
継続的なアウトプットは本当に大事、そしてコミュニティ最高です。
4末で無職になって1人だった僕が、今では多くの人達と関わらせていただいております。
もう感謝しかない。
2018年のVUIイベントに一般参加以外で参加したイベント
一般参加のイベントも記載するとものすごいので、connpassにある中で、かつ、
運営スタッフ、登壇、主催したイベントを以下に列挙します。
1.【運営】4月27日 VUI LT vol.1
2.【登壇】5月31日 VUI LT vol.2
3.【主催】6月26日 スマートスピーカーを遊びたおす会 vol.2
4.【運営】7月29日 スマートスピーカー勉強会 LINE Clovaスキル開発ハンズオン&人気アプリのスピーカー登壇
5.【登壇】8月9日 VoiceUIﾗｲﾄﾆﾝｸﾞﾄｰｸ!/VUILT vol.4 @SoftBank
6.【運営】8月21日 スマートスピーカーハンズオン＆もくもく会 ～LINE Clovaスキル開発～
7.【主催】9月3日 スマートスピーカーを遊びたおす会 vol.3
8.【登壇】9月27日 VUILT vol.6 @LINE
9.【登壇】11月12日 VUI LT vol.7 @サイボウズ
10.【登壇】11月15日 Alexa Salon SP @東京 秋のNLT（Not LT）大会
11.【審査】11月23日 #ma_2018 プロが選ぶヒーロー賞 決勝審査会 VUI部門
12.【登壇】12月2日 FESTA 2018 by MA #festa_2018
13.【登壇】12月12日 【東京】LINE Bot & Clova CEK開発者2018大忘年会
14.【急に振られた】12月15日 AlexaDevSummitTokyo
15.【主催】12月17日 スマートスピーカーを遊びたおす会 vol.4
16．【登壇？】すまのみ
1月
まだ会社員
QAエンジニアというか、SETというか、要するにソフトウェアテストのエンジニアをしていました。
ともかくSeleniumとAppiumで当時所属企業のスマホアプリのE2Eテストをガンガン自動化していました。
また、ソフトウェアテストエンジニアになったので、それに該当する資格としてJSTQB Foundationの勉強をしていた模様です。
2月
相変わらずE2Eテストを自動化していました。
このころは、休日出勤や深夜残業が当たり前でした。
JSTQB Foundationを2月10日に受験しており、結果的に合格していたわけですが、当時簡単すぎて逆に不安になったことを覚えています。
あと急性気管支炎になって、1週間仕事を休んだ時期でもあります。
常時、咳がでていて夜も眠れずつらかったなぁ。。
3月
この時、ソフトウェアテストに関するSlackが日本に存在しないので、Slackのワークスペースを作ったりしてました。
VUIやスマートスピーカーをやりたいのに、デスマ状態になっていて会社を辞める決意をした時期です。
前職を悪く言っても仕方がないけれど、「合わない」と結論付けました。
どんだけ試験しても、それらが改修される見込みがなかったし、明らかに違法なこともやられました。
4月
4月からVUI界隈に顔を積極的に出していきます。
勉強会やもくもく会にでたり、VUI LT初回のスタッフをやらせてもらったりしました。
4末でスパッと退職して無職になります。
5月
5月1日0時0分に以下のツイート。
無職になったなう
— show@NOID公認アンバサダー (@surumegohan) 2018年4月30日
ガチ無職になったので退職エントリーを書きました。
ありがたいことに、この退職エントリーを読んでくれた企業から具体的なスカウトの話があり数社遊びに行かせてもらいました。
Gatebox社も遊びに行きました。
まさか2018年末に、Gateboxの着弾を待つことになるとは思ってなかったです。
そして、5月7日にAlexaスキル1つ目、「大阪弁相槌」が公開されます。
当時は審査がゴールデンウイーク中は実施されなくて、やきもきしていた記憶があります。
また、5月31日にVUIイベント初登壇となるVUI LTを迎えます。
6月
スキルに対して音声でフィードバックをするという試みを始めて実施して、AmazonJ社とものすごくやりとりしました。
そして、6月26日、スマートスピーカーを遊びたおす会でduelをします。
当時、ガチ無職だったので時間があり、かつ、GoogleHomeを遊びたおす会の動画をみたら登壇者のクヲリティがめちゃ高く、ここで誰よりも本気でやらないとダメだと思って、2週間強、ずーーーっとduelするためだけの日が続きます。
1日15時間くらいコーディングした日もありましたし、もう本当に本気出した感じです。
加えて、プレゼンスタイルも2018年はとにかく楽しく、ふざけていこうと決めることになります。
真面目にプレゼンするのはもちろん重要ですが、企業に属していないので特に失うものもないわけです。
じゃあ、人に魅力的なプレゼンってなんだ？
VUI、スマートスピーカー面白いぜと伝えるにはどうする？
と考えた結果、当人が楽しんでる姿を見せるのが一番いいだろうという結論に至った次第です。
それにより、遊びたおす会の参加者からは
・技術の無駄遣い最高
・馬鹿な天才
・やべぇやつがでてきた
みたいなことになり、ひとまず2018年はVUIでつっきることにします。
7月
7月はVUI系のイベントがほとんどなくて、周囲の人達が平和だと言っていた時期です。
けど、僕は7月に2つ、人生を変えるアクションをします。
※まだ無職でしたけど
■1．VUIで募金させてほしいとプラットフォーマーに連絡をしまくる
7月は大阪などの関西方面で豪雨がありました。
とはいえ僕ができるのはせいぜい募金程度です。
となった時に、例えば災害情報のニュースとかをテレビで流しているときに、声でその場で募金できたら良いんじゃないかと考えます。
なので、VUI界隈の人達にそれを伝えて協力してもらうことになり、日本のプラットフォーム3社の正面玄関と、エバンジェリストの方々に声で募金させてくださいとお願いして回ることになります。
この時は、どこも「日本では今はお金を扱うのは難しい」という回答でしたが、Amazonさんが日本赤十字社さんと実は動いていて、今では日本赤十字さんのスキルによって声で募金できるようになっています。
■２．長村ひろさんと出会う
技術書典4？で「子どもと育てるスマートスピーカー」を執筆なさった、長村ひろさんと出会います。
詳しくは以下にありますが、当時（今も）市販されているVUI・スマートスピーカーの本は入門レベルであふれています。
そんな中で以下に記載のツイートを発見して、Kindleでポチったら衝撃を受けます。
めっちゃテクニカルな本がでていて感動するわけです。
そして、ここから、僕自身も技術書典で本の執筆・編集とJAWS-UGについて知っていくことになります。
8月
技術書典で本を出すことが決まったことと、仕事振りたいから事業主申請してくれというお話があり、個人事業主申請をしてフリーランスになります。
そして6日に、ヒロインの告白がリリースされます。
duelは本気出してもちろんやりましたけど、公開スキルにするには難しいと判断してました。
なので、音声でのレビューとフィードバックを入れつつ、本腰をいれたスキルとして結城琴葉が生まれます。
これはこれで、めっちゃ大変でした。
なぜかというと
9日にVUI LTがあって、これについて話す予定だったからギリギリでした。
そして、BOOKS FOR JAPANという取り組みを知ります。
これにより本を捨てることはなくなりました。
後でダンボール7箱分の本を寄贈することになります。
9月
技術書典の執筆と、請け負った仕事でめっちゃ真剣にAWSと向き合うことになる月です。
そして、スマートスピーカーを遊びたおす会のvol.3が開催されます。
この時、ちょまどさんが会場に来てくれていたのと、長村ひろさんもいらしたので、技術書典の本にちょまどさんが参戦できないか直談判することになり、お声がけしたらご快諾いただけました。
長村ひろさんも、ちょまどさんもありがとうございます。
そして、Alexaスキルアワードは落ちていたので一般参加となります。
ちきしょーなんであの場に自分がいないんだ・・・
と思ってましたが、最後に畠中さんがめちゃくちゃ泣いていたのと、たまたま近い席にいた僕に対して、両手で握手なさっていただきながら
「長い付き合いになると思いますが・・・
あ゛り゛か゛と゛う゛こ゛さ゛い゛ま゛す゛ー」
と号泣なさっていたので、本当にスキルアワードは大変だったんだなと感じましたし
それだけ畠中さんが日本のAlexaに対して本気なんだなとも感じました。
単なる仕事だったら、あんなに泣いたりしないですよ。
10月
AWS Loft Tokyoが一般開放されます。
2日に体験して、ソッコーで定期券を買って3日から通うことになります。
もはや職場。
塚田さんをはじめ、多くのAWSの中の人に支えていただきました。
本当にありがとうございます。
このあたりで、特許出願が本気で動いており、特許というモノの特性上、アウトプットが禁止されます。
なのでブログとかTwitterとかは自由に書けなくなります。
すんごいつらかった時期です。
そして技術書典5が開催されます。
人生初、同人誌即売会がこれになり、買う側ではなく執筆および編集側になりました。
技術書典は、めっちゃしんどかったけど、めっちゃ楽しかったです。
委託した本は特にZINさんは入ってすぐのド正面ド真ん中に配置してくれたりました。
自分が書いた本が本屋さんに並ぶというのはエンジニア人生で一度は体験したかったわけですが、これ以上ない好待遇をしていただけました。
ありがとうございます。
「スマートスピーカーを遊びたおす本」
— show@NOID公認アンバサダー (@surumegohan) October 11, 2018
ZIN様、とらのあな様、BOOTH様に委託しております！
ZIN様、とらのあな様ではポストカード付与です
ZIN様は秋葉原店2階正面のド真ん中に秋の新刊として平積みです！
※写真撮影は著者のため特別に許可を頂きました#スマートスピーカー #技術書典 #技術書典5 pic.twitter.com/bVUcv2zkMI
そして、この本を読んでくれた方から、商業誌の執筆依頼がくることになります。
11月
AWSとの向き合いがある程度終わり、QuickSightのセミナーを受けて感動します。
また、特許出願が10月中に終わっていたのでアウトプット規制がなくなったので、ガンガン登壇します。
VUI LTは4回目の登壇なので慣れてましたが、まさかのクラスメソッド社のAlexaSalonにご招待されて25分も枠をくれました。
当初、せーのさんから
「技術的な話をしてくださいー」
くらいしか、本当に言われてなくてconnpassでてきたと思ったら、なんだこれ！？ってメンバーでした。
そして、NOIDに出会います。
VUI LTでアイリッジ社のNOID責任者の岩屋さんが大変紳士的でして、NOIDやろうと思った次第です。
正確に言うと存在は知っていましたが、ハンズオンともくもく会に参加しました。
そこで
「これ（いい意味で）やべーな」
となって、NOIDでスキルを作りつつ
不可解な動きをしたら岩屋さんをはじめ、アイリッジ社に共有していくことになります。
また、アイリッジ社のNOID担当の方々が、
ユーザーがAlexaの審査に落ちた場合のフォローまでなさっている
ということで僕自身がNOIDで作成したスキルを申請し、リジェクトされた場合の考えられる理由と対応策の提示、そして再申請をしていきます。
Amazon社からのフィードバックはすべて共有し、いろいろ今までAlexa担当の方々とやりとりした経験から対応策をどんどんアイリッジ社と共有しました。
そうしたら、NOIDの公認アンバサダー1号として任命され、引き受けた次第です。
それと、マッシュアップアワードに新設されてVUI部門の審査員をやらせていただきました。
Amazon社、LINE社の公のアワード類には、まずでてこないような音声サービスがわんさかでてきて、大変楽しませて頂きました。
12月
■AlexaDevSummit
Alexaチャンピオンの岡本さん、伊東さんや、各社のVUIに積極的な人、Amazon社の中の人達と深く交流できました。
そして、Alexaチャンピオンのセッションで僕はLTには選ばれなかったですけど話を振ってもらい
コミュニティとアウトプットについて語らせて頂きました。
■アドベントカレンダー祭り
2018年中に収めるシステムはある程度できていて、仕事量のコントロールができると踏んで、アドベントカレンダー全日程やりきることに挑戦します。
加えて自分以外の（これが普通）アドベントカレンダーにも数記事投稿します。
QiiaとADVENTARは別の記事を書いていく予定でしたが、さすがにほとんど無理でした。。。
アドベントカレンダーの最終日である25日にAWS認定資格とるかーとか書いちゃったので、28日の昨日取得しました。
■AAJUG関東支部立ち上げ
Amazon Alexa Japan User Group (AAJUG)の関東支部立ち上げに関わらせていただくことになりました。
初回から登壇させてもらいます。
関係者と色々話しましたが、1回目のAAJUGは勉強会そのものが初という方にも来ていただけるような構成にさせていただきました。
年明けの1月ということもありますし、会場もAmazonJ社の目黒です。
気になる方は、せっかくなので新年に勉強会デビューもなさってください。
■英語チャレンジ開始
英語のブログを書き始めた件と、海外のVUIの動きをおいかけていくことにします。
逆にこれはものすごく後悔をしていて、なんで日本に縮こまっていたんだと本気で反省しました。
2019年
既に5つくらいのイベントに関わることが決まっていますが、2019年どうしていくかは記事をわけることにします。
圧倒的感謝
多くの人に支えられ2018年が終わりそうです。 本当にありがとうございました。
AWS認定クラウドプラクティショナーに合格したので学習法を書いておく
※29日の朝起きたらスコアが公開されてましたので追記しました
掲題の通り、先ほどAWS認定クラウドプラクティショナーに合格しましたので
その学習方法を記載しておきます。
それに
の中で以下のこと言ってしまいましたし。
問題の中身に触れるとNDA引っ掛かるんで、そこはお察しです。
かつ、試験のスコア結果がくるまで時間がかかる&年末年始なので合格したことしかわかってないです。
※29日の朝起きたらスコアがきてました
スコア 2019年12月29日追記
700点が合格ラインで855点らしいです。 けど問題によって得点が異なるTOEICみたいな採点っぽいです。
どの分野も十分だったらしい。
これは、各分野が7割超えていたということだろうか？
本気出した時間
12月25日の午後から、26日終わるまで。
27日は模擬試験と復習のみ。
そもそもなぜ受けたか
ある程度、AWSを触ってきていたので、そろそろ何かしら受験するかとは思っていたのと、
11月27日のBlack Beltの内容がクラウドプラクティショナーで、これを視聴していて
「いけんじゃね？しかも1000円アマギフくれるらしいし」
となっていたからです。
なんでクラウドプラクティショナーを選んだのか
ビッグデータから受けようと思ったらアソシエイトの何かしらか、クラウドプラクティショナーが事前に必要だったらしいのと直接的な技術面以外の知識も欲しかったからです。
コスト計算とかサポートとか。
そして年内の試験会場的に選べるのがこれしかなかったからです。
前提、僕のスペック
情報系の工学部大学学部、修士卒。
IT系のエンジニアを9年くらい。
AWS利用歴はDBAだった時のRDSと最近のAlexaがらみが中心でした。
が、以下の本は今年の夏で読破済みです。
・Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
・Amazon Web Services パターン別構築・運用ガイド 改訂第2版
・Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく
・AWSによるサーバーレスアーキテクチャ
・Amazon Web Services実践入門
・合格対策 AWS認定ソリューションアーキテクト - アソシエイト
かつ、フリーランスとして以下を作りました。
今回の試験対策で具体的にやったこと
モットー：資格試験は舐めプしない
■1．以下の動画をみて、試験の存在と自分に足りない部分に気づく
■2．公式サイトをみる
■3．クラウドプラクティショナーとソリューションアーキテクトアソシエイトの受験記、合格体験記のブログを読む
クラウドプラクティショナーの試験はできたてであり、ノウハウが少ないので、 ソリューションアーキテクトのブログ類もめぐります。
AWS実務経験の無いシニアエンジニアがAWS認定試験に合格するまで - Qiita
３日くらいの対策でAWS認定ソリューションアーキテクト アソシエイトに合格したので、対策内容をまとめてみた - Qiita
AWSソリューションアーキテクト-アソシエイトに合格したので、合格するために必要と思われる感想をスライドモードで公開 - Qiita
AWS認定ソリューションアーキテクト(アソシエイト)の合格に重要かもしれないことをまとめてみた | MMMブログ
新卒入社4ヶ月でAWS 認定ソリューションアーキテクトに合格した話 | MMMブログ
AWS 認定 Associate level を大体一ヶ月で取った話 - Qiita
「AWS 認定クラウドプラクティショナー」資格のサンプル問題を解いてみよう | トレノケート公式ブログ
【合格体験記】AWS 認定クラウドプラクティショナーの効率的な勉強方法
AWS認定クラウドプラクティショナー取得しました - Qiita
AWS認定クラウドプラクティショナー受検してきました！ | AWSコスト削減・IaaSインフラ構築のシンプライン株式会社
【合格体験記】AWS 認定クラウドプラクティショナー試験（AWS Certified Cloud Practitioner） | 最強SEの仕事術
■4．AWS Cloud Practitioner Essentialsの動画を一周する
7時間半くらいかかります。
しかも、口調が単調でしんどいです。
知っている箇所も復習をかねて僕はすべて視聴しました。
確認問題が最後に出るのはチェックしておくと良いと思います。
AWS Cloud Practitioner Essentials
ぶっ続けで動画をみていると、以下のようにメールボックスが素敵なことになります。
■5．ドキュメント類を読む
以下のクラウドプラクティショナーのサイトから直接リンクされているホワイトペーパーを読む。
特にサポート系とAWS Trusted Advisorの動画は要チェック。
ここらへんが技術面以外で試験範囲に思いっきりあるからです。
その後に
の、ソリューション別資料のSlideShareやPDFを流していく。
■6．「合格対策 AWS認定ソリューションアーキテクト - アソシエイト」を読む
日本語でAWSの試験対策本は2018年12月28日時点でこれしかないので、再読します。
2016年時点ですが、要点は書いてあります。
しかし、この本にない部分も試験にはわんさかでます。
ちなみに、2019年1月18にはSAAの新試験対応の別の本が出るみたいですね。
■7．Webの問題集を無料の範囲で解く
公式サイトや以下のような箇所です。
AWS WEB問題集で学習しよう | 赤本ではなく黒本の問題集から学習する方向け
■8．模擬試験を受ける
模擬試験を受けます。
2問間違えたらしく92点でした。
気になった単語等はメモしておきます。
■9．模擬試験で気になった箇所を今までの資料や本で見直す
今までの資料のうち、模擬試験で気になった箇所を読み直します。
サポート体系と、「合格対策 AWS認定ソリューションアーキテクト - アソシエイト」
を再チェックします。
■10．ちゃんと寝る
試験前夜はちゃんと睡眠をとります。
たぶん最重要です。
■11．受験30分前には会場について受験
15分前から入室なので、30分程度前について、トイレに行き、注意事項等を確認して受験
■12．ブログを書く
いまここ
所感
・ブログ類
・ソリューションアーキテクト本
・クラウドプラクティショナーの動画
以外の観点も数問出題されました。
過去のソリューションアーキテクトレベルの問題も一部でてきたように感じます。
他の方の受験記にもありますが
模擬試験が本試験より簡単すぎますので、
模擬試験で調子に乗ると危険だと思われます。
模擬試験がギリギリ合格以下だと本番は厳しいと思われるので、その場合は勉強時間を確保した方がいいです。
クラウドプラクティショナーは対象がエンジニア以外も含まれますが、IT用語なのかAWS用語なのか区別がつかない人が受けるなら、それなりにお勉強しないと厳しいだろうと感じました。
さて、次にいこう。
特許出願したVUIのログ収集・分析およびレビュー・フィードバックシステムの話
この記事は
ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」
の25日目の記事です。
さて、アドベントカレンダー最終日。
思いっきり、技術の話をしようと思います。
2018年4月末に会社をスパッと辞めて
「VUI・スマートスピーカーに専念するぜ！」
となってましたが、半年もしないで自分単独が発明者となって特許出願するとは思ってませんでした。
しかも、API Gatewayってなんですか？のレベルからAWSをガッツリ勉強・検証することにもなったわけです。
そんなシステムの話。
対外的に一番語っている資料はAlexaSalon
25分間、このシステムについて語っているのは
クラスメソッド社、清野さん（せーのさん）からご招待があった、AlexaSalonにて語っていて、すでにそこでスライドは共有済みです。
ご関心ある方はそちらをどうぞ。
■Alexa Salon SP @東京 〜秋のNLT（Not LT）大会〜 AlexaエバンジェリストにAlexa Championも！
特許出願したSH Analytics（通称SHA）
上記の通り、SmartHacks社に納品したシステムです。
このシステムには以下のような目的があります。
平たく言えば、VUIのスキル・アクションの品質を高めるための仕組みです。
・VUIの各プラットフォームのログデータを一元管理して分析する
・自分および他社のスキル・アクションを様々な角度で比較してKPI等の具体的数値を出す補助をする
・人気のスキル・アクションが他の人からも見てわかる
・開発者と開発を依頼したい人のマッチングにつなげる
・スキル・アクションの利用頻度が落ちてきた場合等もグラフで一目でわかる
・音声サービスに対するレビューを音声で行う
・音声サービスに対するフィードバックコメントを音声で行う
などなど、様々な使い方を想定しています。
AWS構成図
動き出した時点の構成図は公開されているので、ここで語ることができます。
わかる人には、「ん？ここおかしくね？」というポイントがあると思いますが、そこらへんはこの後にある程度進化させているつもりです。
この構成にはいくつかのポイントがあります。
1.VUIのスキル、アクションとしてスキル・アクションそのもののユーザーに負担をかけない
Lambda等でHTTPSで本システムのAPI GatewayにPOSTで必要事項を送付すると、DynamoDBに、SHA登録済みであるか確認を行い、即時スキル側にHTTPのレスポンスを返しています。
基本的に200か、それ以外を返しますが、先日202を追加しました。
本来、Amazon Cognito等と使ってしっかり認証・認可をすべきですが、VUIの応答速度およびアカウントリンク等の負担を鑑みて、それはやらないことにしました。
2.データ収集はそれ用のLambdaをinvokeさせてバックで行う
1に関することですが、DynamoDBでSHAの正規ユーザーだとわかり、かつ、想定通りのJSON形式だと200を即時スキル側に返答しています。
その際に新しいLambdaをinvokeで起動させて、Amazon Kinesis Data Firehoseに投げています。
FirehoseからS3等にアウトプットする際にデータ形式を変更することが可能ですが、お金が若干かかるのと、データ格納先がRedShiftであるため、CSV形式にあらかじめ変換しています。
めっちゃバズったらAmazon Kinesis Data Streamsを間に挟んだ方が良いと考えています。
もともとは、AuroraかRDS PostgreSQLで行う予定でしたが、やはりLambdaと相性が悪すぎました。
CSV形式なのはそのなごりでもありますが、クライアントさんがエンジニアではないことも考慮するとCSV形式の方が読みやすいと判断しました。
ちなみに、新卒3年目くらいの時に、同じようなロジックをJavaのマルチスレッドで実装して怒られました。
「DBに格納されているか不透明なのにOKを返すことは何事か」
と。
そこは最低限、この図にない部分のS3にも格納しています。
3.Athenaを選ばずに初めからRedShift
VUIが流行るかどうかすら正直不透明であり、そんな中でいきなりRedShiftを選択します。
安価にシステムをまわすことを考慮するとS3に格納してAmazon AthenaでSQLライクに呼んだ方が良いと思われます。
が、今回の場合、僕はあくまでフリーランスでの単発受注だった点と、RedShiftはFirehoseから容易につなぐことができる点、そして後からRedShiftにいれるようにいじるのはかなりしんどいと判断して、コスト計算をした上でクライアントのOKをもらってRedShiftにしました。
Athenaもそこそこいじりましたが、VUIのログデータがガンガン飛んでくるとログファイルもガンガン増えていくことになり、ファイルをまたがりまくるとAthenaの性能がつらぽよでした。
僕のAWS力が高ければうまいことやれたんだろうとは思います。
RedShiftでのテーブル分散もそれなりに考えています。
例えば、スキル・アクションに関するデータ（カテゴリとか）を管理するテーブルはデータ量が少ないがJOINする頻度が高いのでALL分散でJOINの負荷を下げたつもりです。
ログデータに関してはさすがにALL分散は選ばないようにしています。
4.分析画面はQuickSight
BIツールは他にも経験がありましたが、QuickSightに落ち着きました。
以下のような画面になっています。
Alexaのカスタムスキルの、スキル毎のユニークセッション数や、カテゴリごとの利用頻度、音声でのレビューの星の数やユーザーからの音声からのフィードバック等を表示しています。
提供しているダッシュボードは複数ありますが、開発中のスキルの場合は基本的に、SHAから割り振られた匿名の開発者名とスキル名が表示されます。
流行ってきたと思ったら、公開する旨をSHAの中の人に連絡すると、開発者名とスキル名を伏せずに公開しているダッシュボードにデータを公開することができます。
平たく言えばアピールできます。
※
スマートスピーカーを遊びたおす会で表示したスライドです。
一部、テスト用のスキルのデータも含みます
QuickSightに落ち着いた理由は主に以下です。
・サーバレス最高
・MetabaseとかのためにEC2やElastic Beanstalkを使うのは嫌だ
・料金プランが非常に良い
・E-mailで分析画面を送付できる
・登録して、閲覧するためのユーザーはメールアドレスをもらえばよい
QuickSightは操作に慣れれば非常に扱いやすく、また、分析画面のダッシュボードの閲覧権限を与えたユーザーが、どんなに使い倒しても1ユーザー（1アカウント）あたり月5ドルです。
使わなければ0ドルというか0円です。
なのでダッシュボードをばら撒くことがやりやすいので大変良いです。
QuickSightは機械学習対応をするらしく、グラフの傾向から今後のグラフがどうなるかまで分析してくれるみたいです。
となると、SHAに登録したスキル・アクションの今後の利用頻度が予想されることになります。
神か。
E-mailで分析画面のレポートを送付できるのも強いです。
分析画面をBIツールでいかにかっこよくしようとも、見られないのは意味がないです。
そこにE-mailで分析画面のキャプチャを送付できるのはPUSH型であり、かなり強いと考えています。
※
ただし、Oracle DBとはつなぐことができません。
たぶんライセンスがうんぬん・・
5.僕が作った「ノリノリのサンタ」へのフィードバック
「ノリノリのサンタ」というスキルを本システムに対応させています。
すると上記のようなユーザーからのコメントが寄せられていることがわかります。
・何やってるんですかね
・ノリノリの具合がすごい
等のユーザーからのコメントがもらえるのは開発者として非常に嬉しいことです。
6.検討したが辞めた技術類
1.Glue
バグを猛烈に踏みました。
そして、本システムにはお金かかりすぎだと判断しました。
2.AWS Batch
RDS PostgreSQLにデータを格納しようとして、AWS Batchでがんばろうとしましたが、断念しました。
Firehoseから直にRedShiftに入れた方がシステムが安定するのと、Batchに現実的にどれだけの時間がかかるのか未知数だったためです。
3.AWS Step Functions
Lambdaを組み合わせて、RDSとうまいこと連携できないかと模索しましたが辞めました。
CSVをRDSに格納する際に使用するこを検討しましたが、やりたいことに対して複雑すぎると踏んだからです。
そこまでして、RDSではないといけないのかということになりまして、クライアントと話した結果、
「firehoseから直にRedShiftに格納できるならそれでいいじゃん」
となった次第です。
もちろん間にS3を挟みますが、努力が減って、やりたいことが実現できるならその方が良いです。
4.RedShiftのクエリエディタ
■RedShiftのQuery editorの注意
意図していないタイミングでSQLが発行される可能性がありました。
怖すぎる。
結局これをつくるのにどれだけの時間がかかったか
本格的に着手してから2か月ちょいくらいです。
「API Gatewayってなんですか？」
の状態から、市販本を買いあさり、AWS Well-Architected フレームワークを読んで、AWS Loftに通ってエキスパートさんに随時質問して、QuickSight等のハンズオンに参加したらこうなりました。
VUIに関する知識と、今までのエンジニアとしての経験をフルフルに注ぎました。
このシステムを創って得たモノ
1.AWSの知識と経験
AWSの知識類は飛躍的に上昇しました。
re:Invent2018の内容をみて、
「え、まじか。あれこうなったのか」
とかがわかるようになりました。
2.AWSの中の人と仲良くなれた
AWSの中の人達と、結構仲良くなれました。
今ではほとんど顔見知りです。
AWS Loftを使って、VUIで特許出願システムが生まれたという事例はたぶん初だと思います。
AWS LoftやQuickSightの活用事例の話として、登壇お声がけになるかもです。
3.がっつりエンジニアリングした
VUIのスキルを創る際に利用するのはせいぜいLambda、DynamoDB、S3くらいです。
今回、他のサービス類をめっちゃ検討して、めっちゃ使って、エンジニアリングしたなーと思えてるのは、やはり大きな収穫です。
4.技術的に話せる機会が増えた
フリーランスなので、お仕事の依頼を受けることはちょくちょくあります。
僕の場合は基本的には「VUIの人」なのですが、「AIスピーカーを使ったシステムを創りたい」みたいな話が来た時に、同時にオンプレ環境をクラウド化したいという潜在課題がある場合もあります。
その際に、自分でその場でAWSへのマイグレーション案がだせるようになれたのは非常に大きいです。
もちろん、イベント類でも話すことができるようになりました。
あとは認定資格でもとって名刺に記載しようかな。
5.特許出願のやりかたを知った
めっちゃ大変でした。
想像以上でした。
大学の論文を書いてる感覚でした。
大学院時代を思い出しました。。。
弁理士さんと随時相談していくわけですが、そもそもIT業界のエンジニアだってVUIに詳しくない状態で、
弁理士さんにVUIやスマートスピーカーを語り、クラウドの仕組みを語り、法的な文面に落としていくのがめっちゃ大変です。
アドベントカレンダーやりきった
25記事を書き続けてきたわけですが、当初の予定と大幅に変わりました。
「情報は水物」って本当ですね。
僕が1人で25記事（Qiitaを含めると50記事）+他のアドベントカレンダーへの数記事を合わせると結構な量になります。
あとMediumで英語ブログも始めました。
そもそも1人アドベントカレンダーを勧めてくれた人が何名かいましたし、
VUIやってきた2018年で、仕事の時間をコントロールできる今年が25記事やりきるタイミングとしてBESTだと踏みました。
PostgreSQL界隈の積極的な方々が1人アドベントカレンダーをやっているのを目にしていましたし、やりきることで得るものはたしかにたくさんありました。
やってみて本当に良かったと思っている点は
何かをやるときに、どうアウトプットするかを考えながら行動できるようになってきたことです。
アウトプットを前提としてインプットすることができると、吸収量が半端なく上がります。
そして、ブログの閲覧数が大変多くなりました。
みなさん、ありがとうございます。
来年も調子にのってやるかもしれないですが、もうちょい計画的にやりたいですね。。
以上です。
Alexaで位置情報を取得するReal-Time Location Services for Alexa Skillsの設定と流れるJSON
この記事は
ADVENTARの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」
の24日目の記事です。
AlexaDevSummitの1日目で会場をふらふらしてたら、岡本さんから
「showさんやばいっす！これみてくださいよ！！」
と、ノートPCを開きながらめっちゃ興奮されてたので、そのPCをみたらAlexaが位置情報に対応してた画面でした。
岡本さんありがとうございました。
僕もその日の夜に「おおおー」となってました。
で、既に試されてる方々がブログに上がっているわけですが、僕は僕で改めて試して、流れるJSONがたしかに変わったなーと思ったのでここに記載します。
Real-Time Location Services for Alexa Skills
これについては公式のサイトをみてください。
Enhance Your Customer Experience with Real-Time Location Services for Alexa Skills : Alexa Blogs
先に確認できた記事類
これらをみればわかると思います。
■情報提供元、岡本さんの記事
・Alexaから位置情報を取得可能になったので試してみた
■さっそくためした @MYamate_jp さんの記事
・Alexa Real Time Location Serviceを使う
■ @MYamate_jp さんの他の記事
・Alexa Skill開発でよく使いそうな関数をまとめたnpmモジュールを作った
僕も試してみた
まず、APL対応した画面を、スマートスピーカーを遊びたおす会で録画したかったがためのスキル
「ヒロインのテスト」
で、試します。
が、別に何でもいいです。SDK v2であるだけです。
1.Alexa Developer Consoleのアクセス権限を押す
いつもの左下箇所です。
2.位置情報のトグルをONにする
いつの間にか、しれっとでてきていた、位置情報サービスのトグルをONにします。
3.LambdaでJSONを確認してみる
単純にJSONの中身を出力します。
console.log(JSON.stringify(handlerInput));
LaunchRequestのHandlerにでも入れてみてください。
4.スマホからスキルを起動する
スマホからスキルを起動してみたら "alexa::devices:all:geolocation:read" が追記されていました。
が、アクセス権を許可していないのでDENIEDになっています。
"requestEnvelope": {
"version": "1.0",
"session": {
"new": true,
"sessionId": "amzn1.echo-api.session.fad41c95-9292-XXXXXXXXXXXXXXX",
"application": {
"applicationId": "amzn1.ask.skill.fd6f4522-518c-XXXXXXXXXXXXXX"
},
"user": {
"userId": "amzn1.ask.account.XXXXXXXXXXXXXXXX",
"permissions": {
"scopes": {
"alexa::devices:all:geolocation:read": {
"status": "DENIED"
}
}
}
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.fd6f4522-518c-40b3-8508-71e6d205ed1e"
},
"user": {
"userId": "amzn1.ask.account.XXXXXXXXXXXXXX",
"permissions": {
"scopes": {
"alexa::devices:all:geolocation:read": {
"status": "DENIED"
}
}
}
},
"device": {
"deviceId": "amzn1.ask.device.XXXXXXXXXXXXXXXXXX",
"supportedInterfaces": {
"Geolocation": {}
}
},
"apiEndpoint": "https://api.fe.amazonalexa.com",
"apiAccessToken": "XXXXXXXXXXXXXXXXXXXXXXXXX"
}
},
5.スマホのAlexaで位置情報を許可してみる
スマホ（僕はAndroid）のAlexaスキルアプリを呼び出して、スキルへの位置情報提供を許可します。
一応、スクリーンショットをとってみました。
まずは起動してメニューを表示しましょう。
上記で「スキル・ゲーム」を選びます。
はい。いつもの画面です。
ここでいつも通り、有効なスキルを選びましょう。
今回の「ヒロインのテスト」は開発中のスキルなので
開発スキル を選びます。
そして、画面をスクロールして目的のスキルを選びましょう。
目的のスキルを選んだら、グレーになっている「設定」をタップ。
※個人的に選べなさそうな色にみえる。
Alexa Developer Consoleで位置情報サービスのトグルをONにしているので、権限を聞かれます。
ここで位置情報サービスの権限を許可して保存します。
スマホで位置情報が取得できているなら、位置情報サービスのアクセス権に許可がされたことが確認できます。
6.もう1回、スマホからスキルを呼び出してみる
再度スマホから、「ヒロインのテスト」を起動します。
するとJSONが変化しています。
"alexa::devices:all:geolocation:read"がGRANTEDに変化して、位置情報のJSONとしてGeolocationが追記されています。
※位置情報の有効桁数はそのままで、適当な数字をいれてます。
"requestEnvelope": {
"version": "1.0",
"session": {
"new": true,
"sessionId": "amzn1.echo-api.session.0c9XXXXXXXXXXXXXXXX",
"application": {
"applicationId": "amzn1.ask.skill.XXXXXXXXXXX"
},
"user": {
"userId": "amzn1.ask.accounXXXXXXXXXXXXXXXXXXXXXX",
"permissions": {
"consentToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"scopes": {
"alexa::devices:all:geolocation:read": {
"status": "GRANTED"
}
}
}
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.asXXXXXXXXXXXXXXXXXXXXXXXX"
},
"user": {
"userId": "amzn1.ask.account.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"permissions": {
"consentToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"scopes": {
"alexa::devices:all:geolocation:read": {
"status": "GRANTED"
}
}
}
},
"device": {
"deviceId": "amzn1.ask.device.AXXXXXXXXXXXXXXXXXXXXXXXXX",
"supportedInterfaces": {
"Geolocation": {}
}
},
"apiEndpoint": "https://api.fe.amazonalexa.com",
"apiAccessToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
},
"Geolocation": {
"timestamp": "2018-12-24T10:12:06Z",
"coordinate": {
"latitudeInDegrees": 79.1235586,
"longitudeInDegrees": 283.1111355,
"accuracyInMeters": 33.1111104196167
},
"altitude": {
"altitudeInMeters": 40.111111525878906,
"accuracyInMeters": 29.23455004196167
},
"heading": {
"directionInDegrees": 0
},
"speed": {
"speedInMetersPerSecond": 0
}
}
},
"request": {
"type": "LaunchRequest",
"requestId": "amzn1.echo-api.request.XXXXXXXXXXXXXXXXXXX",
"timestamp": "2018-12-24T10:13:44Z",
"locale": "ja-JP",
"shouldLinkResultBeReturned": false
}
},
位置情報っぽいような数値がたくさんでてきましたが、個人的にアツいと思っているのが
speedInMetersPerSecond です。
まだドキュメントを読んでいないので正確なことはわからないのですが、そのまま解釈すると1秒当たりの移動速度がメートル単位ででてくる・・・？？マジで？
となると、例えば車などの乗り物に搭載されたAlexaデバイスとかも想定してるのだろうかと個人的には考えています。
というわけで
位置情報を使ったスキルを組み込むことが可能になったと思われます。
もちろん日本語版で。
となるとエラーハンドリングとかも大変そうですが、IoTやりたい勢としては実世界との融和性が高まるので・・オラ、わくわくしてきたぞ！
以上です。
技術書典5で買ったスマートスピーカー系の本を読み直した
この記事は ADVENTERの「するめごはんのVUI・スマートスピーカー Advent Calendar 2018」 の23日目の記事です。
技術書典6に向けて、次にやるならアレをやろうみたいな話がそろそろ僕の周囲でも具体的な話がでてきています。
技術書典5では、「スマートスピーカーを遊びたおす本」を出させて頂きましたが、他にもスマスピ・VUI系の本は技術書典5にて購入していました。
もちろん、1度読みましたが、今回改めて読み直したので、それぞれの内容等にざっくり触れたいと思います。
書評するような立場ではないですし、100％個人の感想です。
そもそも技術書典って何？
今の時期ならコミケが着目される時期で、要するに同人誌即売会です。 それの技術書のみが集まるイベントです。
僕が参加した技術書典5は1万人の来場者がいらっしゃいました。
以下では、その場で買ったスマートスピーカー・VUI本に触れていきます。
1.GoogleHomeプチハック
入ってすぐのサイボウズさんのブースでまさかの200円。
サイボウズさんなので、kintoneの話なのですが、Google Homeアプリのインストール設定からActions on GoogleやDialogflowの設定までがフルカラーでめっちゃ丁寧に書いてあります。
VUI LT7で会場がサイボウズ社であったこともあり、著者のミケさんの登壇をその場で観させていただきましたし、サイボウズ社の森みたいな会場もすごかったわけです。
が、この本の内容、これ絶対200円じゃない。
プチハックと言いつつも、設定類はできますし、kintoneとの連携はもちろん記載されてます。
Google Homeの設定を知りたい、kintoneと連携したい等のモチベーションがあればイチオシです。
2.Raspberry PiではじめるDIYスマートホーム
表紙これ、怒られないのかと思うんですけども、それはさておいて。
この本はAlexaを使ったスマートホームについて触れています。 そして、タイトル通り、Raspberry Piを使ったスマートホームの話です。
Alexaについても記載がされてますが、スキル作成はNode-REDです。 プログラミングに関する記述はむしろ bash しかないです。
Node-REDの使い方や、Raspberry Piで動かすコード、物理的な環境について語っている本です。
Node-REDでAlexaスキルを扱い方、Raspberry Piなどを使ってセンサー類を扱いたい方にはオススメです。
3.スマートスピーカーアプリのお品書き
サインもらってますが、温泉BBAの方々の本です。
内容は大きく分けてVUIデザインの話と、Clovaのスキルの作り方の二部構成です。
VUIのデザイナーをなさっている元木さん記述部分はさすがデザイナーです。 音声アプリの企画の話から対話設計の話まで、大変濃密です。
特筆すべき点は 音声アシスタント3プラットフォームの機能別比較表 だと思います。 これの何が良いかというと、本当にこれからVUIをやろうとしたときに、どのプラットフォームで何ができるの？という壁に最初に当たるからです。 それが一目でわかります。
執筆時点での日本とアメリカの比較と、Clovaで何ができるかがまとまっています。
スキルの履歴書という発想も僕にはまったくなかったので大変参考になります。
第二部のClovaスキルの作成方法は画面キャプチャが丁寧なのですが、npmのエラー時の対応方法まで記載されているVUI本は他に観たことがないです。
Clovaの画面は変化が激しい状態にありますので、現状とは若干ことなりますが、この本を読んでおけば、スキル作成時に気を付けることが濃縮されている上に、本当に初心者向けに書いてありますので、これからVUIを始めたい方にはオススメです。
巻末の用語集も嬉しい記載です。
4.俺たちが知りたかったAlexaの話
この本は、とんでもないです。 なんで2000円なんだ。安すぎる。
技術書典5で、この本だけは絶対に手に入れるつもりでいました。
Alexaチャンピオンの方々が関わっているというのもありますが、書いた人うんぬんよりも 内容がガチだから です。
例えば、一般的なVUIのデザインや設計だと「ハッピーパスを作りましょう」という感じですが、そんなレベルではないです。
代替パス、シーンの前提、ヘルプなどのパスについても書いてあります。 Experience flowの話は大変勉強になる上に、他にもダメな例、良い例など非常に具体的です。
デザイン面だけでも濃厚ですが、開発面はより一層深いところまで踏み込んでいます。
・ASK CLI
・SSMLの効果的な使い方
・DynamoDBを扱う場合にask-sdkとaws-sdkのメリデメの比較
・開発手法
・粒度ごとのテスト
・ツール類の紹介
などなど極めて実践的です。
そして、最後にコミュニティの話と、アウトプットの話になっています。
Alexaでスキルを複数個リリースしてきて、市販本等に物足りなくなってきたら、この本は必読だと思います。
VUIのデザイン部分は他のプラットフォームでも考え方は同様になると思います。
極めて良書です。
読んでみて思ったことは
技術書典5は、そもそも僕自身の人生経験として「同人誌即売会」が初でした。
そしていきなり執筆＆編集をやらせてもらい、リアルお仕事にもつながりました。
技術者にとって、本を書くというのは一つの目標だと僕はずっと思っていたわけですが、上記4冊のように様々な人たちが様々な視点で本を書いています。
アウトプットというと、ブログやイベント登壇などが個人的には思いがちなのですが、技術書典に1回本をだしてみると得られることがありますし、自分が経験したからこそ上記の本の「すごさ」がわかる面もあると思います。
というわけで、Qiitaなどのブログ類以外にも、本という形でアウトプットしてみてはいかがでしょうか。
以上。
