スクラム関連書籍の簡単な書評とオレオレ読書術の紹介
8月はスクラム関連の書籍を3冊読んだ。
この記事ではそれぞれの簡単な書評と、3冊を読みながら編み出したオレオレ読書術を紹介したい。
簡単な書評
エッセンシャル スクラム
- スクラムガイドには載っていないスクラム開発の具体的なノウハウが載っている書籍
- スクラムガイドが将棋のルールについて述べた本だとするなら、この本は将棋の定石について述べた本というイメージ
- この書籍を初めて手に取ったのはAgileJapan2019に設置してあった旅するアジャイル本箱だった。当時は計画会議の具体的な進め方(1部制?2部制?)や見積の単位(ストーリーポイント?時間?)について、人に説明できるほどの理解がなくて困っていたので、旅するアジャイル本箱の書籍を読みまくったのだが、そのあたりの具体的なノウハウが載っているのは、この書籍だけだったように思う。
- スクラムマスターなど、スクラムを推進するような立場の人は手元に置いておいて損はないと思う。私はスクラム関連の書籍で一番のおすすめは?と聞かれたら、この本を挙げる。
スクラム現場ガイド
- 3冊の中だと一番おすすめしない
- 各章の構成が、冒頭でよくある失敗事例を紹介し、その後失敗を回避するための教訓を紹介する構成になっているのだが、この失敗事例に出てくる登場人物が毎回違うので、まずそこを理解しなければいけないのがだるい。読書の量に対する学びが少なく、コスパが悪いと感じた。
- 取り上げられている教訓も、他の書籍で述べられているものが多い印象だった。「28 章アウトソースとオフショア」、「30章 契約の記述」あたりのトピックは初見だったので勉強になった。
- この書籍を読むよりは、カイゼン・ジャーニーを読んだ方がいいと思った。スクラムのノウハウを、江島さん主人公の物語形式で学ぶことができて、一貫性もあって、感情移入もできるため。
アジャイルコーチング
- スクラムマスターやアジャイルコーチの立場の人は、読んでおくと良いと思った。私はコーチングの経験がほとんどないままスクラムマスターになったため、自身がアンチパターンに当たるコーチングをしていないか若干の不安があったが、この書籍を読む限りそういったことはなさそうだと思え、自信に繋がった。
- ただスクラムの経験、コーチングの経験の両方を有している人であれば、それほど目新しいトピックはないはずなので、読まなくても良いかと思った。
オレオレ読書術
簡単に言うと、電子書籍をスマホの音声読み上げで聞きつつ読書するという読書術。
昔から音声読み上げ機能を使った勉強はしていたが、今回はその音声読み上げ機能を、読書の補助ツールとしてがっつり使ったという感じ。
ちなみに音声読み上げ機能を使った勉強方法についてはこちらで詳しく述べました。
必要なもの
スマートフォンだけでもいいが、個人的には電子書籍リーダーがあった方が、以下の点が良い
- スマートフォンのKindleアプリより電子書籍リーダーの方がハイライトしやすい(端末が大きい&慣れている)
- スマートフォンのKindleアプリの方は音声読み上げ機能が勝手にページ送りしてくれるが、電子書籍リーダーの方は(当たり前だが)ページ送りしてくれず、ボタン押してページ送りする必要があるので、少しだけ寝落ち防止になる気がする笑
メリット
- ただ読むより集中できるので、書籍を早く読むことができる
具体的にどれくらいの速さで書籍を読むことができるか定量的に示したかったので、アジャイルコーチングの各章を読むのにかかった時間を計測してみた。
- 1章 23分
- 2章 17分
- 3章 24分
- 4章 20分
- 5章 24分
- 6章 18分
- 7章 25分
- 8章 15分
- 9章 18分
- 10章 21分
- 11章 24分
- 12章 16分
- 13章 18分
- 14章 15分
ということで、4時間38分(278分)で物理の本だと236ページの書籍を読み切れたらしい。
個人的な感覚だが、書籍一冊をこの時間で読み切れるのってだいぶ早い気がするので、今後もこのオレオレ読書術を使って、スクラム関係中心に様々な書籍を読みたいと思う。
第25回 Scrum Masters Night!参加レポート
はじめに
第25回 Scrum Masters Night!に参加してきたので、簡単にレポートします。初参加でしたが、めちゃめちゃ勉強になった&楽しかったです。
イベントの流れ
まず参加者は、事前に考えてきたディスカッションテーマを紙に書きました。次にディスカッションテーマを集めて投票し、テーマを9つに絞りました。その後は話したいテーマ毎に席に分かれて、途中参加・途中退席OKの形式でディスカッションを1時間行いました。(こういったディスカッション形式をオープンスペーステクノロジー(OST)というそうです。)
取り組んだディスカッションテーマ
私は、希望した「スクラムチームの状態を可視化するためのメトリクスと、その取り方」というテーマが9つのテーマの1つに選んでいただけたので、このテーマについてディスカッションしました。人数の増減ありつつ、5〜10名くらいの方でディスカッションしました。ディスカッションテーマ記載用紙は以下のような感じです。
メトリクスについての6つの学び
みんなが見ているメトリクス、見てないメトリクス
- ベロシティはみんな見ていた。ストーリーポイントで見る方、時間見積で見る方、両方見る方と様々でしたが、みんなベロシティは見ているということでした。見る観点としては、予実の乖離、スプリント毎のブレなど。
- サイクルタイムはみんな見ていなかった。これは少し意外だった。収集&評価が面倒という声があり、そうですよねぇと思った。
目標あってこそのメトリクス
私がこのディスカッションテーマを選んだ背景としては、「外部のステークホルダにスクラムチームの(改善の)状態を数値として見せるためにはどうすればいいか?」というのが念頭にあったので、最初はその方向で話をしていました。ですが参加者の方の「メトリクスを取る際は、今のスクラムチームの目標がないと、意味のあるメトリクスは取れないと思う。それなしでメトリクスを取っても、メトリクスに踊らされることになりかねない。」というコメントにはッとさせられました。その方は具体的に以下のように目標に対するメトリクスを設定して、目標を達成できたらメトリクスは捨てていたそうです。
- 目標:スクラムイベントを極力減らして、価値を届ける時間に回したい
- メトリクス:スクラムイベントにかかる時間を計測
- 目標:使われる機能だけを作りたい(+メンテしたい?)
- メトリクス:ロギング機能を仕込んでログから各機能の使用率を算出
自己組織化のメトリクス
- この話題になってディスカッションがカオスになった。自己組織化おそるべし笑
- ちょっと違うけど、クロスファンクショナルのメトリクスとしてはスキルマップが有効という話になった。
品質のメトリクス
- これが品質のメトリクスだ!というのはなくて、むしろスクラムには動く成果物があるのだから、それをスプリントレビューでしっかり見るのが第一、という話になった。
- 周りがウォーターフォールでリリース時に承認スタンプラリーやっている環境でも、スプリントレビューでお客様がOKを出してくれているのであれば、リリース承認時のスタンプラリーをスキップできる、という整理をしているスクラムチームもあるとのことだった。
メトリクスの取り方
「メトリクスを手動で取るのは辛くなってやらなくなるからアンチパターン、メトリクスを取るなら自動で取れる仕組みを入れよ!」みたいな話を聞いたことがあったので、その辺りを聞いてみたところ、皆さんその辺りにこだわりはないようでした。特に目標に沿ったメトリクスを取得するという文脈でいうと、チームの目標にぴったり合ったメトリクスが自動で取れることなんてそうそうないから、最初は全然手動でやるという話だった。それで目標が達成できた段階で、もう不要だとねといって捨てるメトリクスもあるし、継続的に必要なら自動化を考えればいいということだった。
カラーコードドット
チームの状態を可視化する方法のひとつとしてカラーコードドットというものもあるよ、と教えてもらったので、こちらについても調べてみようと思います。
ディスカッション時に作成した模造紙は以下のような感じです。
おわりに
ただただ学びしかないイベントでした。主催者の皆さま、参加者の皆さまありがとうございました。今日の学びをうまく消化して、明日からの業務に役立てたいと思います。
Design Research Tokyo: Season 1 Episode 6参加レポート
[6/22 追記]
- 雰囲気がわかるよう、Design Research TokyoのTwitterに載っていた写真を追加
- 登壇者の方の資料・ブログへのリンクを追加
6/17に六本木のDMMで開催されたDesign Research Tokyo: Season 1 Episode 6に事業会社枠で参加したので、簡単にレポートする。 今回の勉強会は、参加者同士のワークショップあり、「リサーチチームの組織力」がテーマのトークあり、たっぷり時間をとったQAタイムありと盛りだくさんでとても楽しかった。
ワーク
「私」「自分の所属する部署」「顧客と接点のある部署」およびその繋がりを簡単に図示して、近くの席の人と共有した。私のグループは事業会社の人が多かった。経営者の方もいた。
トーク
リサーチチームの組織力(DMM) 伊藤さん
- UXリサーチャー
- 2009年頃 UXとの出会い
- 産業技術大学院大学人間中心デザイン履修証明取得
- どんどんサービス作る会社ならリサーチが必要になるだろうと思って2017年にジョインした
リサーチの組織
- 専門組織はない、なくなった。
- どうやってリサーチの業務をやっているのか?
- 個別に来た話をきっかけにやっている。
- もともとUX部があったけど、なくなって、メンバーはちりぢりに。
- ただ逆にUXリサーチが認知されやすくなった
- UXリサーチ相談の例
- 競輪のUXリサーチに行った。その場でかけてみて、チームで使いやすい、使いにくいの評価をした。これは良かった。
リサーチチームの組織力(メルペイ) 松薗さん
- 資料:メルペイ リサーチチームの組織力
- ブログ:リサーチチームの組織力
- 登壇時点で資料公開されてたので、特にメモは取らなかった。
リサーチチームの組織力(LIFULL) 小川さん
- 資料:リサーチチームの組織力 評価からデザインリサーチヘ
- ブログ:リサーチチームの組織力
- 人間中心デザイン受講
- UXリサーチではなく、組織横断で定性評価をメインにやっている。
- 以下の通り、下流工程から徐々に上流工程に食い込んでいっている
- 運用前の評価:操作性を評価 使えるかの評価
- 設計・開発の評価:仕様を評価 伝わるかの評価
- 要件定義の評価:コンセプトを評価 魅力的かの評価
- 人がデータベース化してしまって、スケールしないところが問題点
- メルペイの松薗さんの話と共通するところ多い
- これから試したいことは、プロジェクトチームに「すこしできる人・すこしわかる人」を増やすこと
ディスカッション
- 3名の方のトークを聞いて、グループでディスカッションした。トークの中で以下の話題はスピーカーの中で共通するところあって、印象に残ったという話をした。
- 組織にこだわらずUXリサーチを(勝手に?うまいこと?)やって、社内で信頼を得る
- 「成果物の検証」工程からUXリサーチとしてチームに協力して、徐々に信頼を得て上流工程にも入り込む
- 人が少なくてスケールできない点に課題感を持っている
- 私は、下流工程から始めて徐々に上流工程に行くという話と、3名中2名の方が産業技術大学院大学の人間中心デザインを受講したという話が印象に残った。産技大の授業いいのかな。受講したいな。
- あとディスカッションの中で「肩書大事」って話をした。私はそれまで肩書を自由に決められちゃったら、肩書の意味がなくなるのでは?と思っていたが、従来の肩書に加えて、自分が名乗りたい肩書を設定することで覚悟を決めたり、情報を集めやすくするのは大事かもな、と考え直した。よく考えると、肩書以前の部署の名前についても、その部署の現在の姿(AsIs)というより、その部署のなりたい姿(ToBe)を表している、ということはざらにある気もするし。(今の私の所属組織がそうだとは言う訳ではない)なので、肩書だってある程度自由度持たせてもいいのかもなと思った。
QA
MacのVSCodeでSpringプロジェクトを動かす
Spring BootのプロジェクトはSpring Boot Extension Packをインストールしたら簡単に動かせたのだが、Springのプロジェクトは動かすのに苦労したので、記録を残しておく。
前提としてSpring BootはTomcatを内包しているが、Springはそうではないので、Tomcatを準備して動かす必要がある。
ざっくりとした手順は以下の通り。
- VSCodeにTomcat for Javaをインストールする
- MacにTomcatをインストールする
- Tomcat for JavaでTomcatのインストール先ディレクトリを選択する
- Springプロジェクトをビルドする
- Tomcatを起動する
- ブラウザアクセスする
ビルドツールはmavenを想定している。
1. VSCodeにTomcat for Javaをインストールする
特筆事項なし
2. MacにTomcatをインストールする
以下の通りインストールする
MacBook-Air-3:report anhirayuuta$ brew install tomcat Updating Homebrew... ==> Auto-updated Homebrew! Updated 1 tap (homebrew/core). ==> New Formulae gcc@8 ==> Updated Formulae abyss fastme kahip octave r armadillo fftw lapack open-mpi reprepro arpack gcc libxc openblas root bazel gjs lysp packmol scalapack binwalk grib-api mmseqs2 petsc scipy cp2k hdf5 mpich petsc-complex spades dungeon hdf5@1.8 mvnvm pgplot dynare imake netcdf plplot eccodes json-fortran nwchem qrupdate ==> Deleted Formulae minisat ==> Downloading https://www.apache.org/dyn/closer.cgi?path=/tomcat/tomcat-9/v9.0 ==> Downloading from http://ftp.jaist.ac.jp/pub/apache/tomcat/tomcat-9/v9.0.19/b ######################################################################## 100.0% ==> Caveats To have launchd start tomcat now and restart at login: brew services start tomcat Or, if you don't want/need a background service you can just run: catalina run ==> Summary 🍺 /usr/local/Cellar/tomcat/9.0.19: 638 files, 14.6MB, built in 7 seconds MacBook-Air-3:report anhirayuuta$ which tomcat MacBook-Air-3:report anhirayuuta$ cd /usr/ bin/ libexec/ sbin/ standalone/ lib/ local/ share/
インストール先ディレクトリは「/usr/local/Cellar/tomcat/9.0.19」となった。
3. Tomcat for JavaでTomcatのインストール先ディレクトリを選択する
- 「⬆️ + command + p」でAdd Tomcat Serverと打つ。
- Tomcatのインストール先ディレクトリの選択画面になるが、「/usr/local」みたいなパスが指定できない。
- 「⬆️ + command + g」で「フォルダの場所を入力:」という覧が表示されるので、先ほどの「/usr/local/Cellar/tomcat/9.0.19」を入力する。
- ここをTomcatのインストール先ディレクトリとして指定すると「Please make sure you select a valid Tomcat Directory.」というエラーが出るので、「/usr/local/Cellar/tomcat/9.0.19/libexec」を指定する。するとエラーは出ない。(問題なく設定できた旨のメッセージは表示されないっぽい。)
4. Springプロジェクトをビルドする
mvn package
BUILD SUCCESSのメッセージを確認する。
5. Tomcatを起動する
6. ブラウザアクセスする
- localhost:8080にアクセスすると「Tomcat for Visual Studio Code」というページが表示されるので、「War Packages Deployed on this Tomcat Server:」からアプリを選択する。
かなりざっくりですが、こんな感じでできました。
こちらのQiitaを大いに参考にさせていただきました。
Design Research Tokyo: Season 1 Episode 5参加レポート
4/17に六本木のGoogle Japanで開催されたDesign Research Tokyo: Season 1 Episode 5に参加したので、その時のメモを掲載します。間違っているところや不足しているところも多々あるかと思いますがご了承ください。
3名の登壇者の発表はどれもとても勉強になりました。特に皆さんがおっしゃっていた「リサーチをプロダクトにどう活かすかを常に意識する必要がある」という話が印象に残りました。
タイトル見逃した(Yumi Koyama)
What's research for?
- 体験談として聞いてほしい。
- Google入ってから「どうやってユーザは使っているのか?」を疑問に思いリサーチを始めた。
- 私にとってのリサーチは、ユーザにいいもの届けたいってだけ。研究ではなくて、もっとデザインよりに捉えて、どうやったらリサーチをデザインに活かせるかを常に意識している。
- Googleには20%ルールがある。
- Information Architect。やっていたことはUXリサーチとかぶるところある。
- マーケティングはウォーターフォールというか一発きりのイベントが多かった。
- プロダクトはアジャイル。改善。リサーチャーのもとで実践を学んだ。
Online Masters of HCI program IOWA
- HCI = Human Computer Interaction
- Googleにいる間に学んだことを形にしたかったので受講した。
- 長所:いつでもどこでも。働いていたので、習ったことがすぐ活かせた。
- 短所:知り合いできない。コース全体のうちの30%くらいしかオンラインで受講できなかった。
Farmnote
- 牛の首にセンサつけて繁殖サイクルとか病気とかを可視化するプロダクト。
- 人間と一緒で、牛乳は仔牛産まないと出ない。いかに妊娠させるかが農家にとって重要。
- 健康じゃないと繁殖しない。いかに牛の健康状態を可視化するかがプロダクトのミッション。
- 営業についていって農家のリサーチした。
- 病気の牛のミルクはタンクを分ける。
- カードソーティングで何が農家にとって重要かをソーティングしてもらったりした。
GoogleとFarmnote
- やってみて
- 知り合いづてないと農家に会うのは難しい。知り合いいないところに飛び込みで行くのは相当厳しい。今回は会社の営業がリレーションを作ってくれていた。
- 農家の方が報酬なしに色々話してくれて、最初は驚いた。あっちにとって見返りないのに。来てくれるだけで嬉しいみたい。
- 小さい会社の方がリサーチ結果をデザインに反映しやすいので、それが良い。
QA
- リサーチをするために、農家訪問前に何を準備した?
- 何回かはついていくしかない。それで農家みんなが課題と思っていそうなところを深掘りしていく。基本は手探り。
- 転職した理由は?
- リサーチが好きな理由ってなんだろうと思った時に、全く知らないことを知るのが好きだったから。Googleには素晴らしいリサーチャたくさんいるので後ろ髪引かれる思いだったけど。
- 他のチームを巻き込んだ経験は?
- 転職したばかりなので、まだあまりない。営業と回っていて、営業は私のリサーチの手法(カードソーティングとか)を見ているので、やりたいと言われることはある。
定性調査を通じてエンパシー(共感力)を高めるには(Dara Gruber)
UXリサーチの歴史@Google Japan
インパクトのある定性調査の特徴
- 反復可能性、透明性、楽しさ
理想的なプロセス
- デスクリサーチ
- エキスパートレビュー
- プロトコル作成
- 調査実施
- リクルーティング
- シンセシス
- 知見の伝達
- ???
- 主要ステークホルダーにノートテイカーとしてセッションに参加したいかを聞きましょう
- ステークホルダーがデータをどう解釈するのかを理解するために、シンセシスのワークショップ開催などグループでのアクティビティを行いましょう
- 気に入っているアイスブレイクは、ペアになって、片方が2分間「〜〜だから熊はすごい」と言い続けて、片方が数を数えるアイスブレイク。競争っぽくなってたくさん言葉が出てくるのがいい。ステークホルダとの信頼関係が厚いほどクレイジーなアイスブレイクができる。
繰り返しのユーザリサーチがなぜいいプロダクトを生むか(坂田 一倫)
- Pivotal Labsでは、お客様のチームにPivotal Labsのオフィスに来てもらってコーチングして、チームが自走できる状態にして返す、という事業をやっている。
- プロダクトマネージャやっている
- いいユーザリサーチってなんだろう。ユーザが欲しいものを作れて初めていいユーザリサーチと言える
- Experiment-Driven Product Development
- リーンスタートアップ
- BUILD, MEASURE, LEARN
- Learn: 思いこみから始まる
- Build: 作る
- Measure: 検証する
- 自分たちの思い込みを信頼性あるものにする
- "Experiments never fail." 実験は失敗しない。実験はし続けるものだから。
- 早く失敗すると成功は近くなる
- 紙に書いて壁に貼ると、人は見る。
- JRはプロダクトへのフィードバックをGoogle Formで得ようとしている。JRが。それくらいフィードバックもらおうとしている。
- ザッポスは事業性を調査するために、表のWebサイトだけ作って、裏の流通は作らずにサービスをユーザに使ってもらった。裏では社員が靴屋に靴買いに行って、梱包して送る、というのをやった。ユーザにとって裏の仕組みなんて関係ないから、これで問題ない。
- 調査したことをどうプロダクトに活かすかを考えるのが大事。
isaax勉強会#27でLTしてきた
2019年4月1日追記:YouTubeへのリンクを追加
isaax勉強会#27でLTをしてきました。
LT風景はこんな感じです。
発表資料はこちらです。
LTの際はデモの準備ができていなくて、実際にGoogle Homeが動作するところをお見せできなかったので、遅ればせながら動画を撮りました。
Google Homeに部屋の温度を教えてもらう
こんな感じで、Google Homeに部屋の温度を教えてもらうことができるようになりました。
懇親会ではgoogle-home-notifierを使って、部屋が暑すぎる/寒すぎる時にGoogle Homeから教えてもらうのもいいのではないかとコメントもらったので、今後はそのあたりの改良を進めたいと思います。
オムロン絶対圧センサ2SMPB-02Eを使ってみた
はじめに
2月8日(金)にGroveコネクタ付きオムロンセンサとラズパイハンズオン (isaax勉強会#25)に参加しました。isaaxUGには初参加です。
これまでobnizを使ったIoTは経験がありましたが、Raspberry Piを使ったIoTは経験がなかったので、ちょうどいい機会だと思い、引き出しの奥で眠っていたRaspberry Pi持参で参加しました。
オムロン様のご厚意で、ブログの執筆を条件に絶対圧センサをいただいてきたので、この記事では家での復習(ハンズオンの再現)を中心に記載します。
ハンズオンの内容
ハンズオンの内容はこちらの資料に記載されています。
わかりやすい資料で、困ることなくハンズオンを進められました。(やったのは課題2まで)
家での復習(ハンズオンの再現)
ハンズオンの際は以下2点が特殊でした。
- GrovePi+をレンタルしていただき利用した
- ハンズオン向けSDカードをレンタルしていただき利用した
そこでまずはハンズオンと同じ環境を準備しました。
1のGrovePi+については、必要性がいまいち理解できていないのですが、必要ないと判断できるほど知識がないので、素直に買いました。秋月電子で3100円でした。
2のSDカードについては、ハンズオン資料のここを参照して、GrovePi+向けの設定をしました。
これで設定完了かと思い確認コマンドを打ったところ、期待する結果が得られませんでした。
pi@raspberrypi:~ $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- 56 -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- pi@raspberrypi:~
ハンズオン資料では00の4のところに04が出力されるとありますが、--になっています。
そこでこちらを参照しGrovePi+の初期化コマンドを打ったところ、期待する結果が得られました。
なお期待する結果が得られなかった時はGrovePi+のRSTライトが赤く光っており、初期化コマンドを打って期待する結果が得られた時にはRSTライトが消えたので、このライトを目印に正常性確認をすれば良いように思いました。
pi@raspberrypi:~ $ avrdude -c gpio -p m328p avrdude: AVR device initialized and ready to accept instructions Reading | | 0% 0.00 Reading | ################# | 33% 0.0 Reading | ################################# | 66% 0.0 Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e950f avrdude: safemode: Fuses OK avrdude done. Thank you. pi@raspberrypi:~ $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- 04 -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- 56 -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- pi@raspberrypi:~
この後は特につまづくことなく、ハンズオンの内容を再現できました。
isaaxのダッシュボードのログを見て、curlで叩いてセンサの出力を取得することもできそうと思ってやったところ、すんなりできました。
$ curl 192.168.11.2:5000/sensor { "pressure": 1023.78, "temperature": 14.12 }
上記はローカルIPなので、エンドポイントを叩いてセンサの出力を取得できるか調べたところ、ビジネスプランに登録する必要とこちらに記載されていました。なるほど。
今後やりたいこと
スマートスピーカーと連携して、音声で部屋の温度を出力できるよう設定したいと考えています。
そのためにはエンドポイントの設定が必要ですが、下記の通りいくつか設定方法があると思っているので、どれか選んで実装したいと思います。
(とはいえよくわかっていないので、理解に誤りがあればご教示願いたいです。。。)
ハンズオン資料には2のAmbientとの連携が記載されていたので、まずはそこから試してみようと思います。
おわりに
ハンズオンを主催してくださったisaaxUGの皆さま、オムロンの皆さま、このようなハンズオンの機会を設けて下さり、誠にありがとうございました。
ハンズオン後の懇親会でも、参加者の皆さまとIoTについて色々お話しさせていただき、大変有意義な時間を過ごせました。