編み物とClovaでクリスマスをわいわい迎える ~ スマートスピーカーAdvent Calendar 2018 19日目
こんにちは、スマートスピーカー Advent Calendar 2018 - Qiita の19日目の記事です。
わいわいクリスマスをしていこうと思います。
とりあえず成果物見てください!
編み物とClovaでクリスマスをわいわい迎える ~ スマートスピーカーAdvent Calendar 2018 19日目
Clovaに話しかけると、クリスマスツリーがチカチカして、クリスマスまでの日数を教えてくれます。
スキルを使わずに、呼びかけた時からチカチカするのが頑張りポイントです。
全体の構成
「ねぇClova」って言う
↓
Clova Friendsの下のライトが光る
↓
センサーで検知して、ツリーをチカチカ
↓
「クリスマスカウントダウンを開いて」って言う
↓
スキルで、シャンシャン音を流して残り日数を発話しつつ、ロゴがくるくる
制作の流れ
クリスマスツリーの土台をつくる
まずは、全体の基盤となるクリスマスツリーを実装します。
毛糸は8号、かぎ針編みです。
- 1段目: 輪を作り5目の細編み
- 2段目: 立ち上がりの鎖編みのあとに、そのまま5目の細編み
- 3段目: 立ち上がりの鎖編み2回のあとに、目を増やして8目の長編み
- 4段目: 立ち上がりの鎖編み2回のあとに、目を減らして4目の長編み
- 5段目: 立ち上がりの鎖編みのあとに、4目の細編みで蓋をします
// バランスを見てLEDを飾り付けて、綿を詰めます
- 6段目: 立ち上がりの鎖編み2回のあとに、8目の長編み
- 7段目: 立ち上がりの鎖編み2回のあとに、16目の長編み
- 8段目: 立ち上がりの鎖編み2回のあとに、24目の長編み
- 9段目: 立ち上がりの鎖編み2回のあとに、12目の長編み
- 10段目: 立ち上がりの鎖編み2回のあとに、6目の長編み
- 11段目: 立ち上がりの鎖編みのあとに、6目の細編みで蓋をします
// バランスを見てLEDを飾り付けて、綿を詰めます
- 12段目: 立ち上がりの鎖編み2回のあとに、12目の長編み
- 13段目: 立ち上がりの鎖編み2回のあとに、24目の長編み
- 14段目: 立ち上がりの鎖編み2回のあとに、36目の長編み
- 15段目: 立ち上がりの鎖編み2回のあとに、54目の長編み
- 16段目: 立ち上がりの鎖編み2回のあとに、18目の長編み
- 17段目: 立ち上がりの鎖編み2回のあとに、9目の長編み
// バランスを見てLEDを飾り付けて、綿を詰めます
蓋閉め前に、LEDをつけて綿を詰めておかないと、後々厄介なのでLEDごと編み込んでいきましょう。
これで、ツリーの土台が出来上がりです٩(๑❛ᴗ❛๑)۶!
( ( 新しい生命体かな・・・? ) )
Clova Friendsが光ったことをカラーセンターで検知して、ツリーをチカチカさせる
Clovaが起動したことの検知のベストプラクティスがまだ無いのですが、今回はカラーセンサーで検知することにしました。
from CsCntlr import * from time import sleep import RPi.GPIO as GPIO def pika(): GPIO.setmode(GPIO.BCM) #ツリーは25に刺さってます GPIO.setup(25, GPIO.OUT) GPIO.output(25, GPIO.HIGH) def pikapika(n): for i in range(n): pika() sleep(0.3) GPIO.cleanup() sleep(0.3) if __name__ == "__main__": cs = CsCntlr() cs.useFixedPeriodMode() invocated = False while True: cs.cntlr.auto(gain='low', tint=2) print (cs.cntlr.getData()) # みどり色が50以上になったらピカピカ if cs.cntlr.getData()['green'] > 50: if invocated: continue invocated = True pikapika(10) else: invocated = False GPIO.cleanup() sleep(1)
こちらの記事を拝見してライブラリをお借りしました。ありがとうございます。
S11059-02DT モジュールをラズベリーパイで使用する - Qiita
クリスマスカウントダウンスキルを実装
Clovaのスキルを作ります!Clovaのスキルはとっても簡単に作れちゃいます。
スキルの作り方のドキュメントは幸せなことにたくさんあるので今回は割愛します!
ここに私史上最高に丁寧に書いたClovaのスキルの作り方ドキュメントはございますので、ご参考ください。
初めてのClovaスキル開発 | ClovaスキルからMessaging APIでのLINE送信、LIFFまで
今回はAWS Lambdaを利用しました。Layerが便利すぎて最高!
クリスマスカウントダウンスキルのコードはこちらです。
const clova = require('@line/clova-cek-sdk-nodejs'); exports.handler = clova.Client .configureSkill() .onLaunchRequest(async responseHelper => { let speechList = []; speechList.push(clova.SpeechBuilder.createSpeechUrl('シャンシャンサウンドのURL')); speechList.push(clova.SpeechBuilder.createSpeechText('サンタさんが来るまで、あと' + calculateRemainingDate() + '日。素敵なクリスマスを。')); responseHelper.setSpeechList(speechList); responseHelper.endSession(); }) .onIntentRequest() .onSessionEndedRequest() .lambda() function calculateRemainingDate() { var nowDate = new Date(); var nowTime = nowDate.getTime(); var xmasDate = new Date(nowDate.getUTCFullYear(), 12 - 1, 25); var xmasTime = xmasDate.getTime(); var diff = Math.ceil((xmasDate - nowTime) / (1000 * 60 * 60 * 24)); return diff > 0 ? diff : 0; }
Extension IDの検証をSkipしてしまっているので、実際に使うときはこちらのImajoさんの記事を参考にして検証してください!
Clovaの公式SDKがLambdaで使えるようになっていたので試してみた。 - Qiita
Clovaロゴをくるくるさせる
せっかくなので、Clovaロゴをくるくる回しておきます。
ロゴはシンプルなお花モチーフの花びらを減らして4つで編めばできます!
お花モチーフ例: https://atelier.woman.excite.co.jp/creation/5222.html
サーボモーターを残った毛糸で固定して糸の処理をします。
obnizを遠隔で叩いてみたかったばっかりに、くるくるは唐突にobnizで実装しました。
ちなみにクリスマスカウントダウンはスキルストア公開済みのスキルなので、誰かが使ってくれると私の部屋でClovaロゴがくるくるしています。使ってみてね😍
完成ー!
Clovaにクリスマスツリーを実装してわいわいする ~ スマートスピーカーAdvent Calendar 2018 19日目
( ( どうしよう、なんか新しい生命体たちがうごめいてる、かわいくない・・・ ) )
可愛くする
ブラウンの頭にクリスマスツリーを載せていきます。
サリーには耳がないのですが、ブラウンには耳があるので、帽子をかぶせることができます!
帽子をかぶせるには耳に輪ゴムを巻き付けておいて、ペットボトルを小さく切り取ったものの中心に穴を開けて、耳を差し込みます。
線を絶縁テープでまとめて見栄え良くしたり、ブレッドボードからどんどん抜けていくので、むしゃくしゃしてはんだで固めてしまったり。
小さいブレッドボードに置き換えたり、固定したりして...
できあがりです٩(๑❛ᴗ❛๑)۶
最後に
モノづくりが好きな人、編み物するとハード実装の幅が広がると思います。釣れるし。
キッチンでよくclova使うけど置き場に困るから釣ってみる。シュール。 pic.twitter.com/ZPAhBn8Kci
— 546 935 (@ozyozyo) March 24, 2018
今年もお世話になりました。みなさま、わいわいなクリスマスとお正月をお過ごしください٩(๑❛ᴗ❛๑)۶
年末年始のお休みにClovaスキルを作ってくださったら、私はとってもうれしいです!
( ( 可愛いより、これはシュールだったのではという反省・・・ ) )
今期のガシェット編み物まとめ
aiboの靴下
会社で飼ってると足音がうるさいと言われたので靴下編んであげた。ちょっとだけましになったけど、どう見てもボクシングのグローブ。 #aibo pic.twitter.com/11MSfYU3IJ
— 17 (@ozyozyo) 2018年1月18日
aiboがお手玉するんだけど可愛すぎない?反則すぎない? pic.twitter.com/VLRDjbtfQA
— 17 (@ozyozyo) 2018年3月26日
この後公式でも足裏パッドが発売されました
pur.store.sony.jp
Google Home mini カバー
深夜のテンションでスマートスピーカー吊り師になってるけど、結構可愛くできたと思う。せっかくだからAlexaさんにも何か編もうかしら。 pic.twitter.com/XSSxdEA4aI
— 17 (@ozyozyo) 2018年3月27日
Clova Friends を吊る
キッチンでよくclova使うけど置き場に困るから釣ってみる。シュール。 pic.twitter.com/ZPAhBn8Kci
— 17 (@ozyozyo) 2018年3月24日
Xperia Ear Duo ストラップ
Xperia Ear Duo 専用ストラップ レッド!周りの人がストラップ買ってて羨ましかったから編んだ!つけたまま充電できる! pic.twitter.com/MgjeqJx9AC
— 17 (@ozyozyo) 2018年4月20日
公式のストラップは着脱式らしいので追加開発が必要。
pur.store.sony.jp
大学院に合格した
仕事が滅茶苦茶に忙しいのですが、2017年の反省として、仕事のために色んなことを我慢したなと言うのがありまして、2018年度はMBA取るぞ!と思って大学院を受けました。
月金は仕事、土日は学校。
合格しとるやん!!!!! pic.twitter.com/FLjl0WMz7k
— 17 (@ozyozyo) 2018年3月6日
しかしながら、合格通知を受け取ってルンルンで会社行って、皆におめでとう!って言ってもらえて嬉しいなあって思っていたその日の退勤後、体調を崩しました。
やっと好きなことができる!というタイミングだったのでしょんぼりです。
すぐ病院行って、一通り検査して、結果的に全然重篤な病ではないので全然大丈夫なんですが、さすがに平日バリバリ働いて土日にガリガリ勉強できる体調では無さそうです。
入学金払う前に気付けてよかったと思って、今回の入学は諦めようと思います。
おめでとうって言ってくださった皆様に大変申し訳無い〜〜!!
また万全の体調でチャレンジしようと思います。
本音を言うとめっっっちゃ悔しいですwが、大学院には行けなくても、これからはやりたい事もやっていきたいなー。
まずは明日無事に4日ぶりの出社をして、取り戻せるように頑張ろう〜
エンジニアを辞めて1年が経ちました ~ ex-mixi Advent Calendar 15日目
ミクシィ退職者によるex-mixi Advent Calendar 2017 - Qiita 15日目のozyozyoです。
参加されている方がすごい方ばかりですし、ミクシィの会長にも見てるよ!と言われたので、そわそわしちゃいますが、有難くエモく参加させて頂きます٩(๑❛ᴗ❛๑)۶
ミクシィ時代の話
@yoichiro sanに面接していただいて、2012年にミクシィに入社し、内製だったり外注だったりで広告関連の開発をしながら、開発とスクラムを勉強させていただきました。
未だに、自分が出したバグのせいで、mixiを止めてしまったあの日の夢を見ることがあります。(その節はご対応ありがとうございました🐻🍤)
その後、所属していた部署ごと分社化したり、アレコレがありましたが、スッとミクシィに戻って、家族アルバム みてねにAndroidメインで参加させて頂きました。
みてねが私にとっては、初めての新規事業で、皆でワイワイとインセプションデッキを作ったり、ユーザーストーリーマッピングをしたりして、とても楽しかった思い出があります。
今の会社の話
@yoichiro sanに面接していただいて(2回目)、今の会社に入社しました。
社内異動を繰り返して、社会人5年目、私にとっては4つ目の新規事業として、今は最近話題のお喋りプロダクトをやっています。
エンジニアを辞めました
ミクシィのときも、退職するときも、もっとずっとバリバリとエンジニアをやっていくぞ!と思っていたのですが、ちょうど1年前の今日辞めてしまいました。
Agile生まれScrum育ちなので「コード書かない人とかチームに要るの?」とか言っちゃうタイプだったのに自分でもびっくりしています。
辞めたのは、もちろん諸般の事情や環境要因もありますが、根本的には、言ってしまうと、私がゆるふわエンジニアだったからです\(^o^)/
サービス作るのは楽しかったし、コード書くのも楽しかったし、androidのコード読むのとかほんとに楽しかったんですが、才能のある人達(@yprestoとか@ainameとか)を見ていたら、人生一回だけだし、エンジニアに拘らずに別の仕事をしてみるのも良いんじゃないかなと思いました。
あと、レッドブルも辞めました。
この1年でやった仕事
この1年は新規事業立ち上げだったので、目の前にあるできる仕事は全部取っていきました。
企画
企画職は、企画脳とエンジニア脳を自分の中で切り替えて一人二役するのが楽しいです。自由に発散してから実装方法に戻ってくると企画の新しい面が見えてきます。
やっていくうちに、私には何もない所から面白い何かを考える能力が乏しいぞ!という致命的な問題に気が付きましたが、0->1が得意な人も居れば、その後の膨らましや現実ラインに落とし込んでいくところが得意な人もいるので、これはこれでいいかなという所です。
Scrum Master
今までエンジニア兼ScrumMasterばかりだったので、単体のScrumMasterは初めてでした。
単体のScrumMasterをするまでは、ScrumMasterの仕事って会議進行くらいで少ないし、詳細な実装を理解したほうがやりやすいし、兼任するほうがいい!くらいに思っていました。
ところが、やってみたところ、エンジニアの視点から見えなかったものが見えるようになって、ステークホルダーや外部とのコミュニケーションがやりやすく感じました。仕事量についても、プロダクトによっては巻き取れる仕事はたくさんあるので、単体でもメリットはそれなりにあるという学びがありました。
技術営業
新しいものをどんどん作れる楽しいお仕事。自社のサービスを他の会社とどう繋ぎこんでいくのかの提案をするポジションをやっています。
自社の技術だけでできないことを他社を巻き込んでやれたり、掛け合わせることで新しい価値が生まれたりするのは楽しいので、営業さんが開発の確認も取らずに無理な案件を取ってきてしまう気持ちがちょっとだけ分かりましたw
知らない人と喋るのとか、社会人としての振る舞い、会社間の文化の違いを埋めることや、開発に遅延が許されないことなど、厳しいこともありますが、お互いの決まったAPIをつなぎ合わせてデータフローを書いていくのはパズルみたいでなかなか楽しいです。
PM
色んな階層のPMをやりました。全体のPM、案件郡のPM、案件ごとのPMなどなど。
主な仕事は、PM間の調整、他のチームとの調整、スケジュール調整、調整、調整と、ホントに全部が調整ですが、学びとしてはPMは階層によって見る範囲が全然違うということが身にしみて分かりました。
一番現場のPMは、もう自分の持っている機能が1日でも早く、めっちゃ使いやすく作り込むことを考えるべきです。どんどんアクセルを踏んで欲しい。
それに対して中間管理職PMは事業の方向を考えながら渋滞が起きないように各案件の速度を調整してほしい。
上流PMは、皆ちゃんと働いてるな♡ってニコニコして眺めるのが理想です٩(๑❛ᴗ❛๑)۶現実には、大半が٩(๑`^´๑)۶です。
理想と現実のギャップを埋めるために今はたくさん本を読んでいます。
これまでAgileについては勉強してきましたが、ウォーターフォール開発自体はマネジメント手法としては大学の授業以来で意外と学びがあります。
来年4月に、プロジェクトマネージャー試験受けるぞ٩(๑❛ᴗ❛๑)۶
色んな仕事をやってみて
エンジニアからのキャリアパスは本当に色々あって選び放題です!(ちなみに↑は私が現職で募集しているポジション一覧ですので、興味のある職種があればご連絡下さい)
がっつりコードを書かなくなるのはちょっとした決心が必要でしたが、たまに趣味で書くのはやっぱり楽しいです。
やっぱりコード書くのは楽しいですし、Tech PMや技術企画を担当するための技術的バックグラウンドがちょっと足りてないなと思うので、もう少しエンジニアをやってからでもよかったかな、という後悔がないかと言われたら嘘かもです。でも今も楽しいです。
これから
1年間色んな仕事をやってきました。
これからについては、初期メンバーあるあるで、関わっている機能をどんどん新しく入ってきた人に任せてしまい、リリースまで携われた機能が1年やって1つもなくて、今手元にあるのがリリースできそうなので、とりあえずこれを頑張ります!
その後は、自分が上手くできない事ができるようになるのは楽しいので、このままPMとしてある程度まで頑張ってみるのか、修行のためにエンジニアに戻るのかとか、まだ決めては居ませんが、新規事業やるときに1人いると便利な人レベルを上げてきてるので、何か新しいことをするときは是非お声がけ頂けたら嬉しいです٩(๑❛ᴗ❛๑)۶
長い自分語りでしたが、読んでくださった方、ありがとうございます!
明日は、私の選択肢を広げてくださった@yoichiro先生が執筆のお話を書いてくださるとのことです。乞うご期待〜!
LINE Beaconで家に帰ったらテレビをつける(部屋も温めておく)
急に秋めいてきましたね。寒いですね。
寒い日に、暗くて静かで寒い家に帰りたくないですよね。
暖かくて明るくて賑やかな家だと最高ですね。
そこで、本日は、LINE Beacon を使って最高にしたいと思います٩(๑❛ᴗ❛๑)۶
使うもの
- LINE Beacon
- IR Kit
IRKit - Open Source WiFi Connected Infrared Remote Controller
- hue
フィリップスが提供するワイヤレスでスマートな照明 | Hue の紹介
LINE Beacon
LINE beaconの受信をきっかけに、LINEのbotアカウントに紐付いたwebhookをたたけるすごいやつです!
本当にいま近くにいる人だけに何かをしたい!だとか、今近くにいる友達は誰かを知りたい!だとかに使えます。
市販はしていないのですが、LINE Developer Day 2016というイベントで配っていました。もし、市販されたら10個くらいセットで欲しいですね!
linedevday.linecorp.com
LINEの設定
ポチポチをいくつかしなきゃいけませんが、getting-startedに書いてあるとおりポチポチしていけばtokenをもらうことができました。
Getting started with the Messaging API
SSLのサーバーが必要なので一瞬心が折れかけましたが、AWS certificate manager で最高でした。
Beaconとbotアカウントの紐付けはbeaconにbeaconのidとsecretのシールが貼ってあるので、それを管理ツールから入力してください。
developerとしてご利用頂く限りは、1つのbotにつき1つのbeaconと紐付けることができます。
LINE Beaconで帰宅したらテレビを付ける
beaconを受信すると、beaconに紐付けているwebhookを叩いてくれるので、そこでIR Kitを叩きます。
IR Kitとは、リモコンの赤外線をコピーして、API call で赤外線を出すことができる便利デバイスです。
beaconの起動に30秒かかるので、beaconの受信テストをするにはLINEアプリのプロセスを1度落とすか、端末のBluetooth設定をOFF/ONにするとdebugが捗ります。
逆に、Beaconの受信圏内でLINEを再起動すると意図せずテレビがついてびっくりするので、beaconは部屋の中ではなく玄関において、玄関を通ったときだけ受信するようにしました。
テレビをつける赤外線とテレビを消す赤外線のrawデータが同じなので、意図せず家についたらテレビがついて、家から出ればテレビが消えるようになりました。
ブラウンのぬいぐるみがあったので、せっかくですし、この子につめました٩(๑❛ᴗ❛๑)۶
LINE Beaconは結構な距離飛ぶのですが、電波を玄関までしか飛ばしたくないので、電波を弱めるためにbeaconをアルミホイルで巻こうかと思いましたが、ピンが一部露出しているデザインなので直接金属で巻くのは自重したほうが良さそうです。(過去に会社のbeaconを一個溶かしたのは内緒です。)
電波の強さを調整するには電気を通さないもので包んだ上で、アルミホイルで包むなどで調整しましょう。
外出先から暖房をつける
暖房、部屋に着くまでに温めておきたいので、beaconではなく外から"暖房つけて”とLINEでメッセージを送ってつけることにしました。
これもMessaging APIのwebhookを受け取って、IR Kitを叩きます。IR Kitは外部から叩きやすくて捗ります。
一応、知らない人にうちの暖房をつけられても困るので、userIdで自分かどうか判定してから暖房つけてます。
暖房、テレビを操作しつつ、適当に会話が続くようにロジックを書く
家に帰るとおかえりってメッセージがきます。ちょっとうれしいです。
beaconを受信したのをトリガーにbeacon受信者にメッセージ送るの、10行くらいでかけちゃうので簡単に遊べます。
public function reply($replyToken, $token, $messageText) { $curl = \Request::forge('https://api.line.me/v2/bot/message/reply', 'curl'); $curl->set_params(array( 'replyToken' => $replyToken, 'messages' => array( array( 'type' => 'text', 'text' => $messageText ), ) )); $curl->set_header('Authorization', 'Bearer {'.$token.'}'); $curl->set_header('Content-Type', 'application/json'); $curl->set_method('post'); $curl->execute(); }
まとめ
BLE最高٩(๑❛ᴗ❛๑)۶Beacon楽しい٩(๑❛ᴗ❛๑)۶
あと、家帰ったらhueが電気つけてくれるのでhue最高٩(๑❛ᴗ❛๑)۶
女子高生にプログラマになってほしい話
先日、Googleさん主催の Woman Tech makers というイベントに参加してきました。#WTM2016 です。
www.womentechmakers.com
広く、所謂IT系の女性が多く集まるイベントで、色んな方とお話することができて、ごはんもおいしくて最高٩(๑❛ᴗ❛๑)۶
イベントの中でGoogleの方が、女性プログラマを増やすための試みの1つとして、学生を集めてプログラミングに触れてもらっているという話を聞きました。
その試みに参加した方でITに進む方も多く、良い結果を出しているとのことです。
非常に感銘を受けたのですが、まだまだ女性でエンジニアという人が少なすぎて、職業選択時にプログラマになることに抵抗があるのではないかと思ったので、存在アピールのために普通の凡人プログラマとしての楽しさでも書いてみようかと思います。
業務
プログラマといえば、映画で黒い画面に緑の文字でハッカーがカタカタしてる怖いやつ!または、激務でピザ食べてるチェックシャツ!のどちらかのイメージが先行してしまうのですが、BeautyPlusとか、LINEとか、ねこあつめとか、instagramを作っている人もプログラマです。
プログラミング自体は初めは難しいし、今も難しいことは多いですが、プログラミングそのものが楽しいと思っています。
また、作ったものを使ってもらえることも楽しいです。
自分で作れる、というのは、本当に楽しいです。こういう仕事につけてよかったと思っています。
スーツでバリバリ働くキャリアウーマンに憧れてる方はプログラマではないかもしれません。ものを作るのが楽しい方は是非やってみて欲しいです。
業務以外
服装自由。ネイル自由。勤務時間が自由なところもあります。アットホームな職場です。
昔はもっともっと働きたかったのでたくさん働いていましたが、最近は思う所があり一旦仕事以外のことも多めにしています。
勉強会に参加したり、会社のフリースペースで勉強してから帰ることもあります。
私は勤務時間が自由なので、働きたいときはたくさん仕事をして、それ以外のことをしたい時期は仕事は控えめに、というように自由なのが良いところです。
また、若いうちから他の職業に比べてそれなりにお金が貰えます。(DeNAさんは新卒で500万+賞与 2017年度新卒採用 | 株式会社ディー・エヌ・エー【DeNA】)
プログラマはどこでも人手不足なので、何かあれば転職してやっていける気持ちでいます。
不安なことは一生勉強し続けなければいけないことで、それが楽しくもありますが、子供ができた時にそういう時間が取れるかな、と思うことはあります。
でも、きっとそれは他の職業でも一緒なので、プログラマだからどうこう、ということではないのではないかと思っています。
俺が考える最強の新規サービス開発フロー
インターネットサービスを想定した理想を書いてます。
エンジニアリングに特化した話ではなく、アイディアを思いついてからリリースするくらいまでの浅く広い話で、個人的な趣向であり、組織や環境によっては合わないかもしれません。
とりあえず、リーン・スタートアップとアジャイルサムライ−達人開発者への道−は、すごくいい本で勉強させていただきました。
アイディアを整理します
実現したいアイディアが解決するユーザプロブレム、提供する価値を整理します。
例えば、
● ユーザプロブレム: お腹いっぱい美味しいものを食べたい!
● 提供する価値 : 安くて美味しくて腹持ち良い食べ物屋さん
アイディアの簡単なペルソナを想像します
ペルソナとは提供するサービスの一番の顧客になってくれる人の人物像です。
例えば、
G太、小学1年生男児。体重40kg。 頭はおにぎりのような形をしており、10円ハゲがある。 小学校では少年探偵団を結成しており、食べることが大好き。 他人の家でつまみ食いしたことが功を奏して事件を解決したことがある。
ペルソナの人を探してきて話を聞きます
聞きたいことは、主に以下の4つです。
● 本当にそのペルソナの人は、想像しているユーザプロブレムを持っているか
● そのユーザプロブレムを持っている人は、その提供する価値を価値だと考えてくれるか
● もし、他のサービスでそのプロブレムが解消されている場合は、その競合サービスや満足していないところ
● 似たペルソナの人にはどこで会うことができるか
この時点でイケてないと言われるサービスは、残念ながらイケてないです。
回答によっては、早期に、初めからやり直す決断をしましょう。
G太 < 昼ごはん食べても2時位にはお腹がすいちゃうんだ…
リーンキャンバスを書きます
【リーンキャンバス テンプレート】とかでググると雛形が出てくるかと思いますので埋めましょう。
ここで初めてソリューションについて深く考えます。
例えば、
● ユーザプロブレム: お腹いっぱい美味しいものを食べたい!
● 提供する価値 : 安くて美味しくて腹持ち良い食べ物屋さん
であった場合、ソリューションはお好み焼き屋さんでも、ハンバーガ屋さんでも、大学の近くによくある600円くらいでお腹いっぱいになる定食屋でもいいわけです。
まず初めの一手としてどの分野でやっていくかを、コストだとか、ユーザの母数だとか、競合についてだとかを考えて、決めていきます。
開発者 < 若者に人気のハンバーガー屋さんを開こう!小学校低学年に大人気のおもちゃもつけよう!
余談ですが、tinycanvasというリーンキャンバスを書くためのwebサービスが神だと思っていたのですが、無くなってしまったので悲しいです。
競合について詳しくなります
どんなサービスでも必ず競合になりうるものがあります。国内外問わず競合を探して詳しくなりましょう。
そして競合のイケてるところと、イケてないところを探して、どういう理由でそうなっているのか観察します。
イケてないところには理由があって、その課題には自分たちも直面することになる可能性が高いです。
また、UI面で、ユーザの学習コストがかからないというメリットがあるので、いい意味で、競合の真似をしちゃうのも良いと思います。
プロトタイプを作ります
自分自身がソリューションについて考えるために、そして、人にどんなソリューションであるか伝えやすくするために、プロトタイプを作ります。
この時に作るものは、ペーパープロトタイプでもなんでも構いません。
とにかく手を動かすことで気づきがたくさんあります。
アプリ開発の場合、非エンジニアへのおすすめはProttというアプリで動くプロトタイプが誰でも作れちゃうツールです。prottapp.com
エンジニアなら、実機ビルドが無料でできるようになりましたし、storyboardでポチポチすればいいと思います。
そこまで手をかけなくても、例えば簡単なLPのような印刷物を作ったり、チラシを作ったりしても、人に伝えやすくなります。
ユーザインタビューします
カスタマーセグメントに書いた人を呼んできて、プロトタイプを見せて、ソリューションについてどう思うか話を聞きます。
その他、リーンキャンバスを書いた時に、分からなかったことや、仮説立てたことを質問します。
ユーザインタビューは、やり方からして色々あり、人の話を引き出す方法は奥が深いです。
実りあるインタビューにするためには、専業の方にお任せできるならした方がいいです。
自分自身がインタビューをすることのメリットが
● 録画や、別室で見るより、些細な表情などの温度感やニュアンスを理解できる
● 聞きたいことを間違いなく、聞きたい通りに聞ける
であり、デメリットが、
● 主観が入りすぎてしまう。対象者が意見を言いづらくなってしまう。
● 会話をつなげることをを頭の片隅で常に考えなければいけないので、集中できない
かと思っています。
G太 < おもちゃとハンバーガー?そんなのよりうな重食いてぇ
しょんぼりして、何回か繰り返します
初めのインタビューはだいたいしょんぼりします。
特に専門的な分野だと、一般人ってこういうリテラシーなのか…と思ったり、
自分的には価値をすごく感じることに、価値を全く感じてもらえなかったりします。
しかし、インタビューしていなかったら、たくさんのコストをかけてから、売れない現実を突きつけられるわけです。
先に分かってよかった、と思って、気を取り直してもう一度、リーンキャンバスを書き直しましょう。
そろそろ行けるかなって思います
何度かインタビューを繰り返して、自分の中でも詳細に作りたいもののイメージが出来てきて、
それに対する良いフィードバックをもらえるようになり、何が解決しなければいけない課題なのかも分かるようになります。
そうなったら、満を持して、次に進みましょう。
インセプションデッキを作ります
インセプションデッキとは?この本に詳しく書いてあります。
アジャイルサムライ−達人開発者への道−
【インセプションデッキ ppt】とかでググるとパワポが出てくると思いますので、わいわい埋めましょう。
また、このタイミングでサービス名とロゴも決めると良いと思います。
リリース日と目標を決めます
インセプションデッキとリーンキャンバスができていれば自ずと決まってくるかと思いますが、リリース日の目安と、目標を決めます。
目標は、リリース後1ヶ月で1万ダウンロード、5週目アクティブ率50%、みたいなものです。
目標は1つじゃなくてもいいですが、1回目のリリースはざっくりでいいと思います。
これを達成できなければどうするのかだとか、何を持ってサービス継続不可と判断するかも考えておくとシャキっとします。
ユーザーストーリーマッピングをします
インタビュー用のプロトタイプのことは忘れて、イチからユーザーストーリーマッピングをしましょう。
リーンキャンバスとかインセプションデッキは何度も書き直すんですが、ユーザーストーリーマッピングって私はほんとに最初の最初しかしないので、いつも忘れて、いつもこのブログさんを読み直してやってます。
ユーザーストーリーマッピングで地図を書き、ソフトウェア開発の旅に出よう! | 世界はどこまでもシンプルである
バックログを作ります
バックログ、見積もり、優先度付当たりは、先述のアジャイルサムライが勉強になります。
アジャイルサムライ−達人開発者への道−
バックログ(≒ ストーリーのリスト)を作ります。色々ツールが有りますが、私はまだ良いものに出会えておらず、GoogleSpreadSheet派です。
何がいいかと言いますと、一意の順位付けができて、並び替えが用意で、修正がチーム全体にすぐ反映されることと、
いろんな目線で見たいときに列の非表示機能やフィルターが便利です。
見積もります
各ストーリーがどれくらいの難易度でできるかを見積もります。
プランニングポーカー、なんてものもありますが、私はSML方式くらいのざっくり三段階が好きです。SMLで始めたつもりが、だいたい終わる頃にはLLとかが出てきてますが。
大まかな設計は、インセプションデッキで終わらせておくと話がスムーズです。
本当は難易度見積りに言語などは関係ないと思うのですが、難易度見積もりに慣れてない人はある程度具体的に想像できる環境にしてあげないと、見積もるのが難しいようなので、言語やAWS使うのかとかもインセプションデッキで話しておくと、良いかと思います。
この時、開発環境の構築などはじめに必要なものはできている前提で見積もります。
見積もれたらリリース日から逆算して、どれくらいのペースでタスクをこなしていかなければいけないのかを知りましょう。
優先度付をします
開発のしやすさや、ユーザからの意見を早く聞きたいもの、最悪なくても必要な機能などを考えて、開発する順番を付けます。
下の方まできちんと順番を付ける必要はありません。上からこなしていって、近くなったら考えましょう。
準備期間を経て、上から開発します
開発をはじめます!見積もりの時に計算したペースより、おそらくはるかに遅いペースでの開発となると思います。
しかし、1週目は遅いものです。あまりあせらずに、みんなで効率よい仕事の仕方を模索していきましょう。
必要なら開発開始までに準備するための時間を作って、micro serviceにするのかとか、ドキュメント何で書くかとか、ライブラリとかフレームワークを相談するなどしても良いと思います。スクラムでいうスプリント0です。
適宜インタビューをします
見れるものができたらインタビューをします。実際に触ってもらってどう感じるのかを聞きましょう。
開発が始まってからのインタビューでは、主にソリューションからアウトプットが大きくズレていないかや、本当にユーザにとって使いやすいのがそのUXなのかを聞きます。
この時期のインタビューで、提供しようとしている価値からして全く刺さらないユーザさんが出てくると、不安になってしまいますが、あまり気にしてはいけません。
逆に、この時期に不安にならないくらいには、開発前に調査をして、提供しようとしている価値には確信を持っておく派です。
もし、開発前は刺さったのに、この時期に刺さらないのであれば、
過去のインタビューで話したソリューションと実際に出来ていているアウトプットに差異があることを疑いましょう。
ただ、全く刺さらない人がある程度いるようなら、市場が変化した可能性もあるため、一度開発を止めて練り直すのも必要かもしれません。
スコープ?リリース日を守る?と、迷いながらリリースします
インセプションデッキのトレードオフスライダーで、順番は決めているかと思いますが、再確認します。
この時期になると企画はあれもこれも入れたい気持ちになり、開発はリリース日を考えて動いているのでスコープの追加には不安になりがちです。
正しい判断をして、リリースを迎えて、チームで銅鑼を鳴らすなり、くす球を割るなり、お寿司をたべるなどしてお祝いしましょう٩(๑❛ᴗ❛๑)۶
数字を検証します
まずは、立てた目標を検証します。
そして、コホートとかファンネルとかを見て改善点を思いつきます。GoogleAnalytics超便利。
また、このままユーザ数が増えて問題ないか、コスト上の課題などを計算します。
実際に使ってくれた人からインタビューします
自然流入して使ってくれた人の話が聞ければ、話を聞きまくります。
たとえ、離脱して使わなくなったとしても、どういう期待を持ってサービスを使い始め、どういう理由で使わなくなったのか根堀り葉堀り聞きます。
プロダクトを我が子のように感じてしまい、一喜一憂します。
聞いては作り、聞いては作り、を繰り返します
ユーザの欲しいものを作るという意味ではなく、作りたいものが伝わっているか、進んでいる方向性があっているか、実現したいものの一番使いやすいUXはどれかを聞きます。
定性調査だけではなく、定量調査や、ログを仕込んでユーザの動きを追うなども大変ためになります。
あとは繰り返しです。きっと本当はもっとお金の話とか、政治の話が絡んでくると思いますが、ユーザーのことを一番に考えます。
プロモーションします
カスタマーセグメントや、ユーザインタビューを通して知った流入経路から、最適だと思う方法でプロモーションします。
どんどんユーザが増えて、新しいサービスが成功しますように。