SwitchBotで物理スイッチをIoT化

手軽におうちハック

2020/12/07 設置写真を追加しました

スマートホームだ、コネクテッドだ、とは言うものの、ネットワーク非対応な（コネクテッドでない）機器を全て入れ替えるのはハードルが高いですよね。

そんなとき使えそうなのが、以前紹介したNature RemoのようなWiFi経由でコントロールできる赤外線リモコンです。赤外線リモコンで操作可能な機器はこいつでなんとかなります。

それでもまだ、物理スイッチの操作が必要な機器はお手上げでした。

ですが、クラウドファンディングのIndiegogoでそんなお悩みを解決してくれそうなプロダクトを発見したので、さっそく入手してみました。

Switch Botという、物理スイッチを押してくれるガジェットです。

※この記事を書いたのは2年ほど前で、今ではAmazonで普通に買えるようです。

SwitchBot - Your simple switch to a smart home | Indiegogo

小さい箱がswitch botで、大きい箱にはスイッチリンクというハブが入っています。

switch bot はスマホアプリからBluetooth経由で操作しますので、単体ではリモート操作ができません。リモート操作を可能にするには、オプションのハブが必要です。ハブを設置すると、アプリからリモート操作できますし、IFTTT連携なども行えるようになります。

使ってみて

長年、買うだけ買って使い道を見つけられずにいたのですが（じゃあなぜ買ったというツッコミは無しで）我が家では、今では白と黒の2つのswitch bot君が活躍しております。

一つ目は、玄関灯のONOFF。夜になると点灯して、朝に消灯するようにタイマー設定しています。旅行や外出時の治安の面と、夜に仕事から帰ってきたとき、自転車のカギや家のカギが見やすいので、ここに使うことに決めました。

もう一つは、お風呂のお湯張りボタンを押す用途。事前にお風呂のセンをしておく必要はありますが、外出していて思いのほか帰りが遅くなったときなどに、帰ってすぐに子供をお風呂に入れることが出来るようになりました。このありがたさ、子育て世帯なら分かっていただけるのでは無いでしょうか。

お風呂のほうかはなかなか設置が難しく試行錯誤しました。お湯はりスイッチの左右は別のスイッチがあるのでダメ。上は液晶が見えなくなるのでダメ。となると残るは下側しか無いのですが、ここは開閉するフタになっているので、単に貼り付けるとスイッチオンのタイミングでフタがパカっとあいてしまい、スイッチを押し込むことができませんでした。そこで、子どものレゴブロックで土台を製作してなんとかなりました。

設置の仕方に工夫が必要な場合もありますが、ハマればとても便利ですよ。

Terraformコマンド備忘録

AWS環境のIaCのために、terraformを初めて導入してみたので、コマンドなどを忘れないようにメモ。ちなみに、CloudFormationとどちらを今後使い込んでいくか迷っているのですが、CloudFormationは数年間に少し触ってすごく面倒だった(当時)ので、遠ざかっていましたが、あれからだいぶたってYAMLにも対応したので使いやすくなっているかも、、。

基本のセット

terraform init
terraform plan
terraform apply
terraform destroy

initは本当の最初に一度だけ実行すると思っていたのだが、新たなproviderを使う構成にしたときなど、ときどき必要になる。

planで現在の状態とtfファイルとを比較して、実行計画を立てる。どこに差分があって、追加するのか変更で良いのか、削除するのか、といったことが計画される。 applyでも内部的にはplan相当のことをやったのちに、本当に実行するかを確認してくれるので、plan→applyの流れが必須というわけではない。 destroyで環境を削除する。

-targetオプションを使用することで、特定のリソースだけを構築したり削除することができる。 terraform destroy -target=aws_instance.web

terraform fmt # tfファイルのフォーマット整形
terraform console

terraform graph | dot -Tsvg > graph.svg
# 依存関係の可視化

便利関数

サブネットのCIDR

cidrsubnet("10.0.0.0/16", 8, 0)
# → 10.0.0.0/24

cidrsubnet("10.0.0.0/16", 8, 1)
# → 10.0.1.0/24

cidrsubnet("10.0.0.0/16", 8, 100)
# → 10.0.100.0/24

ホストのIPアドレス(のCIDR表現)

cidrhost("10.0.100.0/24", 3)
# → 10.0.100.3/32

実際の使いどころとしては、CIDRをベタ書きしたくないときに便利。 VPCのCIDRを基準にして、サブネットCIDRとその中に配置するホストのIPアドレスを表現することが出来る。

# VPC CIDRが10.1.0.0./16とする
cidrsubnet(aws_vpc.vpc.cidr_block, 8, 1)
# →10.1.1.0/24
cidrhost(aws_subnet.public_subnet, 25)
# →10.1.1.25/32

VPCのCIDRを変更したときにサブネットやホストのCIDRを書き換えなくても良いので、IaCが捗ります。

既存の構成のterraformへの取り込み

terraform import

しかし、importコマンドを使うやり方は、手順が多くて、やや面倒くさい。 そこで、terraformingがおすすめ。 全てのリソースには対応していないが、対応しているものはterraformingのほうが使いやすい

SVN信者をGitに改宗させる話

はじめに

最近、社内のバージョン管理ツールを（ようやく）SVNからGitに切り替えたのでその話。

新しいモノに触れようとしない、古い技術にしがみつく層が多く、そんなメンバーに改宗してGitを採用してもらうべくエヴァンジェリストな活動をしました。

やったこと

1. 座学による概念理解
2. ハンズオンによる体験と、Gitクライアント環境の個人PCへの導入
3. アフターフォロー

座学による概念理解

私自身が初めてGitを使い出したときに、SVNとは概念や用語の違いがあって、スッキリ理解するまでに時間がかかったので、メンバーにはそこを一気に飛び越えてもらえるように講義形式でレクチャーしました。 また、今のSVNから移行するにはスイッチングコストがかかるし、Gitは学習コストもそこそこ高いので、慎重派を動かすためには、SVNでのお困りごとがGitなら解決できますよ、という例示が効果的でした。

Gitのメリット

個人単位で任意にローカルコミットできる。

SVNだと、コミットしたコードは全体で共有されるので、ビルドが通らない、開発途中などの中途半端なものをコミットすると、他のメンバーの作業にも影響を与えてしまう。 Gitは個人単位でローカルリポジトリを持っており、そこに対してコミットしていき、ある程度まとめて共有リポジトリ（リモート）に対してプッシュという操作で反映する。 なので、「ライブラリを試してみてダメだったら戻す」とか、「リファクタリング前にいったんコミット」なんかが圧倒的にやりやすい。

（GitLab）コードレビューのための仕組みがある。

マージリクエストという仕組みを使うことで、ソースコードレビューをブラウザ上でできて、指摘コメントなどの記録も残せる。これまではレビュー記録票というExcelシートを使っていました。 マージのコンフリクト時も、ブラウザ上でコンフリクト解消してマージ作業を完結することができる。

並行開発がやりやすい

段階リリースだったり、アジャイルとかイテレーティブな開発スタイルを採用している場合に相性がよい。どのようなブランチモデルで運用するかにも寄りますが、本番稼動しているバージョンのコードには手を付けずに、開発ブランチであれやこれや機能追加して、テストして、ということができる。これの何が便利かというと、開発途中に本番系で緊急対応が必要になったとき、緊急対応部分だけをリリースすることが出来る。ほかにも、並行開発ありきで作られているので、便利なコマンドがたくさんある。

ハンズオン

座学だけでは、いざ使おうというときに、環境構築やらなんやらで結局つまづいたり時間が取られてしまうので、ハンズオン形式で環境構築とGit操作体験まで一気に立ち上げることにしました。 これにより、自分のPCにGitクライアント環境が整うので、いつでも使い始められる状態になり、使い始めるときのハードルを下げることができると思います。

アフターフォロー

困ったときにいつでも気軽に質問してくれていいですよ、というアナウンスと、そのためのチャネル（Slackなど）を用意しました。 さらに、初めて導入するというプロジェクトでは、近くに座るなどして、何か困ったときにすぐフォローしてあげられるようにするのが良いですね。現場コーチっていうんですかね。

最後に

技術のアンテナ張っている人たちは、布教活動はしなくても、ハンズオンだけでも効果ありと思います。しかし、慎重派、現状維持派の人をスイッチさせる（説得する）には、彼らが理解できるレベルで何かしらのメリットを提示する必要があります。 これって、実は普段の仕事でも必要なスキルだと思います。 技術者の興味だけではなかなか新しい技術の採用は難しく、その技術によって何を変えることができるのか、を説明できることって大事だと思います。

シーズベースの新規事業開発について考えてみた

新規事業やサービスのアイデアを考えるとき、ニーズベースとシーズベースに大別できると考えているが、シーズベースにも、種類があると考えている。

パターン１ 技術シーズをベースとする場合

例えばIoTで何か、とか、この新しい技術を使って何か、といった技術シーズの場合は、そのシーズをもとに、アイデアを考える。アイデアの発想のやり方はいろいろある。

で、よさそうなアイデアが出たら、そのアイデアで、誰のどんな課題が解決できるだろうかということを具体的にことば化する。これで顧客仮説と課題仮説ができあがるので、あとはリーンスタートアップの手法で課題仮説検証をしていけばよい。課題の存在が確認できれば、解決策(ソリューション)は先に考えてあるので、そのソリューション仮説検証をする。

パターン２ すでに世にある製品やサービスをシーズとする場合

テレビに関する新規事業、新サービスみたいな文脈のとき。テレビというプロダクトにこだわるか、こだわらなくても良いかによって分岐すると思う。

デザインシンキング、エスノグラフィといったアプローチが使える。ジャーニーマップを書いたりインタビューしたりして、顕在ニーズや潜在ニーズを考えていく。そのあと、そのニーズ(課題)を持つ顧客セグメントを絞り込んで、課題仮説文を作れば、あとはリーンスタートアップに沿えばよい。

ただし、課題仮説が検証されたとして、最適なソリューションを自分たちが提供できるのか、ということが問題になる。例えば、自社がテレビを売っている場合だと、テレビが要らなくなるようなソリューションは採用されにくいだろう(でも、深い顧客課題がそこに存在するなら、遅かれ早かれ他のプレイヤーが現れてテレビを駆逐するでしょう)。

パターン３ シーズ無しで行く場合

テーマ領域を決めて、あとはインタビューや観察を先にするもよし、社内でアイデアを出してから課題仮説を検証するもよし。

こちらの場合も、発見した課題に対しての最適なソリューションを提供出来るかどうかは別問題となる。でも、自前でなんとかしようしなければ、たいがいは提供できるだろう。

まとめ

・デザイン思考をシーズベースに適用するのは要注意。すでにシーズの利用ユーザがいればなんとかなる。シーズ周辺の現状のユーザー体験をとっかかりとして、そのユーザにインタビューしたり観察したりして、インサイトを得る。

・ニーズベース、シーズベース、いずれにせよ、ユーザー×課題×解決策（+価値提案）が出そろうところまで行けばあとはリーンスタートアップの手法は適用できる

面白かった話

Takramの田川さん

・サブスクリプションビジネスは、結婚のようなモノ。離婚しないために頑張る。つまり、"離脱させないこと" が大事なので、相手からのフィードバックを得て打ち手を変えていく。

・イノベーションは新結合で生まれる。複数コミュニティに所属することで、新結合が起こりやすくなる。

・イノベーションは新結合と社会浸透。浸透していないのはイノベーティブなモノどまり。

2018度の収穫（完全に自分メモ）

ふと振り返ってみた。この１年で何か成長できたか。

自身のスキルアップとしては豊作でした

・スクラム導入

・swagger

・初めてのフロントエンド開発。SPA

・Vue.js

・Buefy(Bulma)

・Highcharts.js

・リーンスタートアップ

・AWS S3とCloud Frontでhttps静的サイト

・Docker

・Dockerハンズオン企画

・ピクト図解ハンズオン企画

・Node.js交流会企画

・グロースハック手法導入(ga gtm MixPanel)

・ファネル分析

・顧客開発、インタビュー

スクラムの進め方補足

認定スクラムマスターになり、社内でも実践したり勉強会を開催したりするなかで気になって調べたこと、勘違いしていたことなどを整理して備忘録として残しておくことにした。

スプリントレビューについて

プロダクトオーナーにお披露目するのではない。プロダクトオーナーがステークホルダーにお披露目する場。

受入条件（Acceptance Criteria）の確認はすでに終わっていて、Doneの定義を満たしているものをお披露目することになる。

プロダクトオーナーによる確認は、スクラムチームの一員として、随時行っているべきもの。

（スクラムガイドにちゃんと書いてありました。よく読まないといけないですね、、）

品質について

社内でよく聞かれるのが、｢品質はどう確保するのか？」ということです。

アジャイル開発は品質が悪くて、ウォーターフォールなどの重量プロセスは品質が良いモノができる、というのは誤りです。これは、Doneの定義を明確にして、ちゃんと運用しておけばよい。

とりあえず動くレベルのものをスプリントのインクリメンタル（成果物）としてしまうと、この問題が起こる。もちろん、プロダクトのフェーズや特性によっては、とりあえず動くレベルをスプリントのインクリメンタルとすることもあり得るが。

受入条件と完成（Done）の定義について

受入条件は、個々のバックログアイテムの満たすべき要件（主に仕様面）。完成の定義は、プロダクトバックログやインクリメンタルが、何を持って「完成」とするかプロジェクトルールとして定めたもの。つまり、バックログに関していうと、“受入条件を満たしていること”とか、“受入条件を満たしていることをプロダクトオーナーが確認済みであること”とかが含まれる。それに加えて、“ソースコードと、対になるテストコードがコミットされていること”だったり、“〇〇仕様書に仕様が反映されていること”なんかを完成の定義に含めることもある。

つまり、完成の定義をどう定めるか、がスプリントのインクリメンタル（および付帯するドキュメントなど）の品質に大きく影響する。

単に作るだけ、を考えたときと、完成の定義を満たすレベルを考えたときとでは、スプリントで実装できるバックログの量が大きく違ってくるので注意が必要。

スクラムのはじめ方

プロジェクトでスクラムを採用した場合、実はいきなりスプリントが開始することはない。なぜかというと、初期のプロダクトバックログがまだ無いはずだし、完成の定義も定まっていないから。

まずは、準備期間やスプリントゼロ、という位置づけで、これらを整える必要がある。

こちらのブログエントリでも少し触れました。アジャイル開発における初期設計について - jiigのREDOブログ

最低限やっておくべきことには、以下のようなものがある。

• プロジェクトの目的の明確化
• 開発言語や開発環境の選定
• プロダクトバックログ作成
• 完成の定義を決める
• ステークホルダーの洗い出しやスプリントレビューへの参加要請
• システム全体のアーキテクチャの設計
• 使用するミドルウェアやライブラリ選定
• 概念データモデリング
• スクラム未経験メンバーの教育

他にも出てきたら書き足していきたいと思います。