NOT A HOTEL のスマートホームをつくってみた話
こんにちは。NOT A HOTEL でソフトウェアエンジニアをしているきんちゃん。(@wa_kinchan) です。
今回、この note では、2021年頭から徐々に設計・開発、2022年10月に初めてリリースをした、NOT A HOTEL のスマートホームの過程と開発における裏側のについて、より深く掘り下げ、エンジニア目線での立ち上げ話から、設計と運用で出てきた様々の課題、システム設計のやや技術的な話も含め、ありのままのお話したいと思います。エンジニアのみならず、NOT A HOTELのスマートホームについて理解ができるかと思います。
また、スマートホームを一緒につくってくれる仲間を募集しており、この記事を通して、ワクワクが届けば嬉しいです。
スマートホームのより踏み込んだシステム開発の話（バックエンド・インフラの設計寄り）は、次の note に投稿予定です。エンジニアの方は、事前にこちらを読んだあと、次回記事を読むと NOT A HOTEL のスマートホームと開発を理解できて、より深く楽しめると予定です。いきなり次回記事の内容を書きたかったのですが、前提のコンテキストが多すぎるので別記事にします。
さて、NOT A HOTEL では、各ハウスのスマートホーム化を推し進めています。
なぜスマートホーム化をするのか？
NOT A HOTEL には相互利用という、自身が保有しているハウス以外のハウスに宿泊できる仕組みが存在します。根底には、世界中に自分のハウスがあることで、自由な暮らしができることを NOT A HOTEL は VISSION として掲げており、それを支えるために考えられたのが NOT A HOTEL のスマートホームの発祥です。
NOT A HOTEL の建築は、場所によって、有名建築家や、デザイナーと協業し、または自社で設計して、それぞれの個性があるハウスになっています。その個性を尊重するあまり、本来、自分のハウスで普段迷うことがない当たり前ができないと、「ベッドルームの電気のスイッチ何処？」「リビングの床暖房どうやってつけるの？」等々が発生すると、いくら建築が良くても、元も子もありません。
部屋にあるすべてスイッチとパネルを廃止して、一つのコントローラーにまとめることにより、払拭できると考えました。NOT A HOTELでは、そのコントローラーを「ホームコントローラー」と呼称しています。
また、玄関エントランスにも「エントランスアプリ」と呼ばれる、別のアプリも開発しました（追って説明します）。そのようなアプリだけでなく、建築含めすべての設備やシステム込みで、「スマートホーム」です。
スマートホームの実現にあたって
2021年初頭、実現方法について模索しました。各種エアコンのメーカーが出しているソフトウェアレベルでのAPIの仕組みを使って、各種ベンダーが出している機器とつなげていくことを考えましたが、対応デバイスごとに結合し、テストしていくのはかなりハードルが高いものであると容易に想像ができました。また、ソフトウェアレベルの API が公開されていないハードウェアに関しては連携が難しく、よりハードウェアレベルでの結合が必要でした。
実現にあたっては、国際規格の KNX と呼ばれるホームオートメーションを実現するためのプロトコルでありエコシステムを利用することで、自宅にあるような家庭用エアコンから業務用エアコン等の空調機器、電気錠・自動ドア、ブラインド・カーテン、床暖房等の制御が可能になりました。似たエコシステムの例で、Loxone があります。私はどちらのエコシステムを使っても幅の広さは似た感じと認識しています。ただ、日本には、日本 KNX 協会があり、KNX のほうが優位に感じます。
KNX での制御は、リレースイッチでの接点、JEM-A 規格を使った接点、無電圧接点、シリアル通信での接点等を扱い、そのような物理的接点を以って KNX モジュールと機器や機器のコントローラー等を物理的なケーブルで結合し、制御するケースが多いです。もう一点、物理的なケーブルで結合を行う理由として、KNX RF と呼ばれる KNX テレグラムを高周波での無線伝送する通信が、日本では利用できないことも、関係しています。
KNX エコシステムを使うことにより、日本問わず、海外のメーカーの設備・機器でも制御が可能でした。NOT A HOTEL では、導入している設備も機能性・意匠ともに重視し、こだわり抜いた海外製品を選定しているケースも多い点もあり、非常に相性が良かったと感じています。また、設計・実装レベルでは、その柔軟性から、KNX 層でメーカー差分を極力吸収することも可能でした。
この仕組が採用できたのもの、建築が完成してから設備に後付でシステムを入れるのではなく、スマートホーム化を着工前の設計時から考慮して、0ベースで建築を立てるため、このような大胆なシステムを作ることが出来ました。
建物内の配線ミスなどは早期発見が重要です。
スマートホームの横断的な開発体制について
スマートホーム開発では、複数のチームが関わるため、体制を紹介します。
合計 10 名ほどの職種様々、横断的にメンバーが関わっています。
スマートホームチーム 7名
API とインフラ両軸で高い設計・実装力のある バックエンドエンジニア
TCA への深い理解と設計・実装力のある iOS エンジニアコンビ (2名)
複雑な機器仕様と、実現にあたる仕様を決め、膨大なシードデータを作った フロントエンドエンジニア
2023年4月入社の第一号新卒 PdM
圧倒的な UIと体験を仕様を落とし込む CXO
ソフトウェアとハードウェア連携が大好きなソフトウェアエンジニアの私
建築部 3名
大手設備設計会社で多様な経験を積んできた建築メンバーで、圧倒的な熱量でプロジェクトをハンドリングする力が方。
NOT A HOTEL のプロダクトデザインのちからと建築で体現化するプロジェクトマネジメントの方。
ライフサイクルマネジメントで設備側のトラブルや課題を一緒に解決してくれる方。
KNX パートナー 3名
実現にあたって必要不可欠な KNX モジュールを利用して、機器をつなぐ制御盤の設計から弊社の API との接点にあたるゲートウェイサーバーのソフトウェアの実装を、協業しているパートナー会社であるエンジニア。
うち2名は、KNX モジュールを機器を自身で作るレベルで、KNX への深い知識、ハードウェア設計とソフトウェアの2軸で設計・実装力があり、あらゆる機器連携を実現できています。
最近、日本メンバーの3人目の電気に詳しいメンバーが入り、より強固な体制へ進んでることが感じます。
スマートホームの開発の流れ
スマートホームの開発の流れは、建築の構造設計・設備設計にも依存し、建築部と KNX パートナーを中心に、ハードウェアの選定と設置場所について、ゼネコン・サブコン・設備会社・メーカーとともに設計を行います。その際に KNX の全体の設計や、制御盤の設計も、KNX パートナーに行っていただきます。
スマートホーム開発において、設備・機器を選定する上で、意匠や、ハードウェア的接点の取り合いはもちろんですが、ほかにも重要な軸が2つあります。KNX における、制御(コマンド)と状態(フィードバック)の2軸あり、制御は機器を操作可能であれば MUST でできる必要があるが、状態も非常に重要です。状態は、ホームコントローラー上に、現在状態の表示で利用し、たとえば、ブラインドの開閉中、停止中か、状態を返すことができれば、ホームコントローラー側での文言や表現がより豊かになります。より体験を良くするためには、適切な状態が末端のホームコントローラーに返却されることが重要な指標になってきます。
それは設備・機器の選定に依存するものであり、設計段階から考慮して、制約を見極めていく必要がありました。センサーやメータリングのように、状態しか取れないような機器もあります。
ソフトウェアチーム、KNX パートナー会社が連携して、必要最低限「これは必要」「これは不要」を着工前の設計時に判断してきます。
アプリの体験上、どういうルーム区分にするかも重要で、この後決めました。
現地での疎通、そして、立ちはだかる数々の問題
建築の竣工の2ヶ月ほど手前から、KNX パートナーと、ソフトウェアチームが現地に入り、ソフトウェア、ハードウェア、ネットワーク等の実動作の確認が可能になり、ヘルメットを被って、疎通から結合テストをおこなっていきます。
2022年10月に展開を開始したプレイス・青島では、10種類ほどの機器種別があり、序盤に一発で QA が通ったのはシーリングファンだけでした。それ以外の機器種別には、何かしらの問題があり、ホームコントローラー、API、膨大な DB のシードデータのミス、ハードウェアの設定、KNX レベルの設定、 KNX ゲートウェイサーバーの設定、ネットワーク設定等、問題発生ポイントは多岐にわたり、リリースが迫る中、CTO、CXO も QA 助っ人で駆けつけて、シーリングファンをたまに操作して動くことを心の依り何処にしつつ、問題特定をみんな専門性が違う社内のエンジニア4人で、ひたむきに1つずつ解消していきました。
なかなか倒せない根深い問題が解決したときは、みんなで喜び、よくハイタッチしたりと、常にアドレナリンが出ていたように感じます。お風呂が実装完了しお湯はりが出来たときには、足湯をして、元気を取り戻しました。
また、開発時には、100万円ほど掛けて、実想定に備え、照明やスイッチなどサンプル機器と実際のKNXモジュールを載せた持ち歩き型アタッシュケースを作りました。しかしながら、想定と違い、実際には思う以上に役に立ちませんでした。スマートホーム開発は、本当に使う機器もそうですが、建築という大きな環境依存に左右されるものがあり、現地での疎通で行うことでしか発生しない問題だらけだったためです。
その際に一緒に作成した、モバイル型 VPN ルーターは非常にあとで役に立ちました。本来はその VPN ルーターと、アタッシュケースで、持ち歩き可能な NOT A HOTEL を作れたと確信したのですが、前述の通り、そううまい話には、ならなかったです。
リリース後の設備レベルの課題と想定外の挙動
私自身、ハードウェアとソフトウェアが連携するシステム開発を好きで、二度他のプロダクトで、経験をしてきました。作っているシステムの種類は全く違えど、課題発生時の、勘所は少しはある予測が付きます。そんな中、どのプロダクトでも一緒ですが、ハードウェアは、作ったあと修正が効きづらく、ソフトウェア側でなんとか対応するのはよくあるケースです。建築も一種の巨大なハードウェアであり、更にハウス内に設備というハードウェアがたくさん乗っており、例外ではありません。
運営の中で課題が出ては、解決を繰り返してきて、現在はだいぶ落ち着きました。数ある機器種別の中でも、水回り（お風呂・温泉源泉かけ流し・水風呂）は、特に問題が発生しました。
例えば、お風呂は昇温機能を外したため、冬場寒くなることを考慮して、ソフト的に解決を試みる。
温泉であれば組み上げポンプの位置が高く、ぬるい温度が出てしまうので、設備でポンプの位置を低くする。
水風呂であれば、チラーにモノがつまり故障して原因特定に時間がかかった。
等々、他にも言い出したらきりながないくらい課題がありました。
必要に応じて、建築部、施工者、ソフトウェアチーム、KNX パートナーで、連携して原因特定を毎度行います。
ソフトウェアな話では、リリース当初、起床時、就寝時にホームコントローラーから一括で部屋を操作する機能がありませんでした。リリースしてまもなく、必須であると分かり、早急にソフトウェア側で開発しました。NOT A HOTEL のスマートホームは、継続的なアップデートが可能言えます。
このような課題については、継続的に、お客様からのユーザーフィードバックを受け止め改善し、社内メンバーが試泊し、問題点を洗い出し改善し、運営をしてみて非効率であると判断すれば、運用の負担が減るように、エンジニア・建築部主導で改善していくことが、スマートホームチームの日常です。
iPad アプリのアップデートの継続的配信の改善
アプリの配信方法と取り組みについてです。
すべての iPad は Mobile Device Management (MDM) のサービスの一つである、Jamf Pro を利用してデバイスの管理をしており、Jamf の機能を最大限に引き出して運用を行っています。
ホームコントローラーの iPad アプリは、Custom App Store と呼ばれる、一般的な ToC 向けアプリ配信基盤の App Store とは別物です。
Custom App Store は、App Store Connect で Apple Business Manager (ABM) 上で配信するように設定し、ABM から Volume Purchase Program で自社アプリを必要個数分のライセンス購入、その後、Jamf などの MDM から配信する形になります。ToC 向けアプリと違い、ユーザーがアップデート操作してくれるわけではありません。そのため、運営メンバーに協力をお願いし、手動で Jamf の Self Service と呼ばれるアプリ配信基盤のアプリを操作してアップデートをする必要がありました。
昨今、Apple Developer Enterprise Program の審査が厳しくなったため、In-House 配信ができないことも背景にあります。
過去に数種類の MDM で運用をしてきた私の所感では、Jamf の良いところであり、悪いところではあるのですが、コマンドベースではなく、スコープベースでのアプリアップデートしか出来ません。そのため、特定の iPad を指定して、アプリのアップデートリクエストが投げることが通常ワークフローでは出来ないことを意味します。
結果として、アプリのアップデート頻度が落ち、今後のプレイス展開をしていくと、明らかにボトルネックになることが想定されます。
この課題に対しては、お客様が滞在していない、ホテル清掃時に自動アップデートできるソリューションを、Jamf のスコープベースと自前のスクリプトでなんとか自動化できそうなところまで、検証が完了しました。
また、MDM の機能で、App Config という仕組みがあり、アプリがインストールすると同時に値が確定し、アプリ側は自身がどのハウスに属しているどのルームの iPad であるかを判断が可能となり、ゼロタッチで、アプリ起動時にそれぞれルームにあった画面を表示するような仕組みなっています。
安心・安全なスマートホームにおける堅牢なネットワーク設計の重要性
スマートホームでは、実プレイスで利用する、ネットワークの設計もかなり重要なポイントでした。
サウナを例に挙げると、外部の悪意のある攻撃により110℃に昇温するなど、人的被害が出ないよう、物理的安全で堅牢なスマートホームを実現することが必要でした。宿泊される方以外が、外から制御できない仕組みを作りました。
実現にあたっては、現地のネットワーク構成、スマートホーム API の設計、認証情報の受け渡しと制御、iPad の運用方法等を、セキュリティエンジニアと何度も一緒に設計しました。
前提に、NOT A HOTEL では、GCP を利用しています。ISP は IPoE の固定グローバル IP アドレスで契約、現地に設定したルーターと GCP は、Cloud VPN で接続し、同一 VPC 内でイントラネットで解決できるようにしています。そのため、現地のネットワークインフラと、Cloud Run で走らせているスマートホーム API は、外部に公開されていない、閉域網で疎通が可能になっています。
利用者目線でのインターネット接続性
ハウス内のホームコントローラー iPad はすべて無線LANで通信します。一部壁に埋め込みのホームコントローラー iPad は、USB-C to Ethernet アダプタを使って、有線LAN接続をしています。滞在されるお客様は、無線 LAN だけを利用することを前提に設計されているため、部屋・屋外の隅々まで接続が可能になるようなアクセスポイントの位置、インターネット接続スピード、などがポイントになってきます。
アクセスポイントの配置を含めたネットワーク設計は、当初、社内ITチームも、建築部が存在しなかったため、ソフトウェアエンジニアの私とネットワーク設計・施工会社と進めてきました。私自身が、小さめのオフィスのネットワーク設計しかやったことがなく、NOT A HOTEL のような複数棟あり広い敷地のネットワーク設計がしてきたことがなく、かなり苦戦しました。あとから建築部が立ち上がり、援護していただき、なんとか形にできました。
ハウス内の意匠の問題からアクセスポイントの露出は出来ず、棚や天井の点検口の中に格納します。また、建築で遮音・密閉性を考慮して、かなり電波を遮断する素材のものが多い中、かなり苦戦しました。既存ハウスは、よりよいインターネットライフを実現できるべく、現時点も改善を継続中です。
VPN でハードウェア連携開発の民主化
NOT A HOTEL 自体オフィスが存在せず、特にスマートホームのソフトウェアエンジニアが、東京、大阪、福岡に点在しており、開発しているハードウェアの民主化が必要でした。
前述のKNXモジュール先にある設備・機器の制御 (GCP → 現地) と状態監視 (現地 → GCP) も、それぞれ REST ベース(他では gRPC だが、ここでは生の REST)の API を通して行っています。
ヤマハのモバイル型 VPN ルーター (NVR700W) は、実プレイスが稼働前に開発環境とCloud VPNの疎通が可能かの実験で大いに役に立ちました。即日固定IPアドレスの払い出しができるSIMカードを提供する、Interlink SIM を VPN ルーターに挿して、どこでも電源がついている間は、Cloud VPN とピアリングを行うようになっています。
最近の例では、インターフォンの開発です。先程の VPN ルーターを使い GCP の開発環境の VPC に接続。Google Nest Cam で現地の状態が確認と、会話。Alexa に話しかけることで現地で無人の会話。SwitchBot でリモートボタンの PIN コードの入力と室内呼び出しの制御可能にしました。GCE で VPN サーバーを建てて、macOS から直接 VPN で VPC 内に接続し、各種ハードウェアを気軽に curl で検証することも可能になりました。
玄関エントランスの iPad 化の挑戦と現実
冒頭にも記載しましたが、玄関エントランスの壁にiPadを埋め込み、専用のエントランスiPadアプリを作成しました。機能は3点です。
お困りの際のスタッフ呼び出し
室内のチャイムを鳴らすインターフォン
滞在中に予約アプリに表示されている PIN コードで玄関扉の解錠
エントランスに設置することもあり、建築上の意匠上、直射日光を避けられないケースがあります。10月にローンチした青島では、リリース当初は問題があまり顕在化しなかったのですが、しばらくして、日中の直射日光が iPad へ突き刺さる場合に、熱暴走が発生し、ディスプレイに「高温注意」が表示され、利用できないトラブルが発生しました。エントランスアプリにできる機能は、原則予約アプリで代替が効くが、インターフォンが使えないなど運用に支障がでました。
iPad の選定当初から、直射日光と、冬場のリチウムイオンバッテリーの性能低下が発生するケースは、想像していたのですが、想定以上に早く再現し、かつ、頻度高く発生しました。急ぎ何らかの対応をする必要がありました。
建築部の協力あって、野外で利用可能な壁埋め込み用の防水防塵の特注の専用の iPad ケースを開発、近未来感を作れていたので、辞めることは辛い決断ではありました。
そして、全社的な風潮でもあるのですが、ときにはサンクコストを鑑みません。代替となる良いソリューションへの切り替えのため、前述のインターフォンの開発を進めました。
音声送受信の開発が当初想定より大幅に工数がかかってしまいましたが、 DoorBird の検証を初めて半年かかりましたが、4月半ばで青島に設置・リリースができました。コーキングも職人さんに設置時に行って頂き、防水もばっちりそうです。
リリースを経て Home Controller 含めた体験も非常に良くなりました。またインターフォン開発の裏話と大変さは、弊社メンバーが別途記事にします。
NOT A HOTEL のネットワークインフラを深掘りした話は別記事にしております！
ぜひ、こちらもご一読いただけると嬉しいです！
暮らしをつくるために、スマートホームは進化し続けます。
スマートホームを一緒につくっていく仲間を募集していて、興味を持っていただけたらぜひお話・ご応募お願いします。
NOT A HOTEL では、スマートホーム領域も、それ以外でも、広く採用活動をしています。ご興味のある方は、ぜひ採用ページや Wantedly をチェックしてみてください。