弊社ビットキーはConnect Everythingというミッションを掲げています。ありとあらゆるものを安全で便利につなげる。そうしたときに我々社会人の1日の大半を捧げるワークスペースたるビルのデジタル融合はConnectする先としては大きなパイです。 弊社のプロダクトは”後付け”が基本。旧来のローカル制御なビルをスマート化するにはたくさんの壁があります。もちろん単純な設計開発のみならず、それらのシステムを品質を担保し、継続的に価値提供し続けるための運用保守があります。 そういった”物理”が絡む世界では開発は大変です。エレベーターを開発現場に置いておくことはできませんよね？ 特にテストは大変です。ほんの数行のコード変更だったとしても、可能な限りE2Eテストや回帰テストは回しておきたい。そうしたほうが安心できる。しかしながら大変厳しい。現物がないことは珍しくなく、あったとしてもテスト工数は膨大です。 そんな厳しい中でも、私たちは1週間スプリントで開発 → テスト → リリースを行うことも日常茶飯事です。 そんなビットキーのConnectEverythingを体現するスマートビルディングの開発現場におけるテスト戦略についてお話します

1. 〜デジタルとアナログのはざまに〜
スマートビルディング爆速開発を支える
自動化テスト戦略
株式会社ビットキー 佐々木 了
© 2024 Bitkey Inc.

2. Outline
1. 制御盤連携とは？
2. 開発シーンにおける課題
3. アプローチ
4. 自動テストへの応用
5. 宵越しのxxはしない
2
© 2024 Bitkey Inc.

3. 佐々木 了
Ryo Sasaki
2012/04
2017/07
某 通信系SIer 入社
・元々はNWエンジニアだったので BGP使った他拠点 NW作ったりとか
・自治体とか官公庁系システムに携わったりすることが多かったかな
・橋梁点検ロボット開発やったりとか
フリーランスに転向
・ペネトレーションテストやったりとか
・OpenStatkとOpenShift結構やってたりとか
・ハイブリッドクラウド作ったりとか
・工事現場DXのサービス作って運営したりとか
・HWスタートアップのプロトタイピングやったりとか
2021/11 ビットキーにジョイン
公の場で人に説明できるような輝かしい経歴は持ってないので
サクッと流します！！！
Job
・IoT Tech Lead
・R&D

4. ビットキーの
プロダクト/サービス
4

6. CONFIDENTIAL © Bitkey Inc. All rights reserved. 6
Connect everything
through the power of technology, securely and conveniently in a way, that simply feels good
テクノロジーの力で、あらゆるものを
安全で 便利で 気持ちよく
「つなげる」
Our Mission

10. 10

11. 11

13. 今日の話

14. 制御盤とは？制御盤連携とは？
14

15. 制御盤とは？制御盤連携とは？
15
ビルやマンションの中に組み込まれている
そのビルの中の空調や照明、
ドアの開閉やエレベーター制御などを
取り仕切る中央集権的なデバイスのこと

16. 制御盤とは？制御盤連携とは？
16
多くのビルの竣工時の制御盤では、
コネクテッド機能を持っていない。
様々なSaaSが普及し、
ビルテナントそれぞれのニーズが、
多様化していっている。
ビットキーでは、様々な制御盤を
”後付デバイス”によってコネクトし
workhubによるスマートビルディング化を
可能にしている。

17. 制御盤とは？制御盤連携とは？
17
その連携部分を司るIoT部分の開発と
ビットキーSaaSプロダクトである
workhubとのインテグレーション部分が
今回言及している制御盤連携の話

18. 制御盤とは？制御盤連携とは？
18
単なるIoTとしての中間レイヤーのみならず、デバイスそのものも作ったり、連携先であ
るworkhubにおけるフロントエンド/バックエンドの実装も担う
Frontend
Backend
IoT Platform
External Adapter
制御盤連携デバイス

19. 開発シーンにおける課題
19

20. 開発シーンにおける課題
20
● 当然、制御盤は一種類ではなく、各メーカー毎に複数種ある
● メーカー毎や機種毎に連携するためのプロトコルも異なる
○ ニッチな世界なので、それを捌くためのライブラリなどは世の中になく、
フルスクラッチで色々作る必要があるケースがほとんど
メーカーA
モデルA モデルB
メーカーB
モデルA モデルB モデルC
メーカーC
モデルA

21. 開発シーンにおける課題
21
● 開発シーンにおいては、それぞれのフェーズで実機が必要不可欠
1. 検証 そもそも新しい機能が実現可能なのか？どう実現するの
か？を様々な組み合わせを模索するために実機で検証
2. 設計 検証結果に基づいて基本設計 -> 詳細設計
大体は机上で終わるが、一部の設計内容を確かめるた
めに実機を触る
3. 実装 実装しながら実機で動作確認 etc
4. テスト 実機を用いてQA

22. 開発シーンにおける課題
22
しかし・・・制御盤の実機をなかなか手に入れられない・・・
● 1台しか実機を用意できない
● 実機をnヶ月しか借りられない
● 実機がなく仕様書しかない
これがザラにある

23. 開発シーンにおける課題
23
● 仮に1台あったとしても、それだとシーケンシャルにしか進められない
● 複数人での開発ができないし、QAと取り合いになったりもする
● 本来なら、実装をしている間に、次の機能に向けた検証や設計をやりたい
● QAやってる間に別の実装などもしたい
● 1台しかないとそれができない
検証 設計 実装 QA
制御盤
実機

24. ● これが開発スピードの遅延につながる
● もっと素早くやりたい！！
開発シーンにおける課題
24
検証 設計 実装 QA
制御盤
実機

25. 開発シーンにおける課題
25
● QAをシフトレフトしようにも、モノがないんだから物理的にやれない
検証 設計 実装 QA
制御盤
実機
QA
モノがない 🥲

26. 開発シーンにおける課題
26
● さらに、制御盤の機能によっては、異常系を引き起こすのが非常に大変
● あるいは、1時間に1回しか動かない機能とかもあったり・・・
それをずっと待ってるの！！？？
● hogeのエラーを引き起こすためには、fugaの機能を実
行中にfooのタイミングでbarの配線を物理的に引っこ抜
く
● piyoの機能は”0 * * * *”でしか実行されません

27. 開発シーンにおける課題
27
● という実状がある中でも、
2週間スプリントの中で複数の機能開発や不具合解消しながらリリース
● 実際にはもっと短い期間で開発とQAを終わらせて
リリースまでやったりする日も全然ある
● むしろそういうふうに1-3日で全部終わらせてリリース！
というほうが頻度としては多い

28. 開発シーンにおける課題
28
純粋なソフトウェアオンリーの開発と遜色ないレベルでやってるよ
どうやって？

29. アプローチ
29

30. アプローチ
30
● どうするか？
● まず、連携対象たる制御盤がなければ話にならない・・・

31. アプローチ
31
● どうするか？
● まず、連携対象たる制御盤がなければ話にならない・・・
実機の制御盤と同じ振る舞いをする”モックデバイス”の開発
モックデバイス
実機
同等の振る舞い

32. アプローチ
32
● モックデバイス = 制御盤の振る舞いをソフトウェア的に再現した存在
● 仕様書からおこす形でフルスクラッチ実装
● コンテナ化してどこでも動かせる

33. アプローチ
33
● そのモックデバイスを使って普段の開発や動作検証を行う
● QAシーンにおいても、新機能に直接影響しないようなテストケースならモックデ
バイスを使いまくる
検証 設計 実装 QA

34. アプローチ
34
え？でも、そのモックデバイスが完璧じゃなければ、
不具合を見逃したりしない？ 品質を担保しきれなくない？
≠

35. アプローチ
35
● YES
● モックデバイスと制御盤連携アプリケーションは対になる
≠
制御盤連携App

36. アプローチ
36
機能A: OK
機能A: OK
機能A: 問題なし
● 制御盤連携App自体の開発や
QAや実機を使ってもやってる
● モックデバイスの妥当性は
制御盤連携で担保される
● お互いがお互いを支え合って
品質担保する形
≠

37. アプローチ
37
● モックデバイス側への改修と
制御盤連携App側への改修が随時入る
実機だと問題ない機能 Aが
モックデバイスだと
不具合発生
不具合修正

38. アプローチ
38
● 現物に縛られないので複数人開発も可能だし
何か制約のある機能開発もかなり楽ちん！
機能BのQA
既存機能Aの
不具合検証
機能Cの新規開発
モックデバイス
モックデバイス
実機

39. アプローチ
39
とはいえさ、
常にモックデバイスも作ってメンテして・・・
それだと、単純に開発工数めっちゃかからない？

40. アプローチ
40
とはいえさ、
常にモックデバイスも作ってメンテして・・・
それだと、単純に開発工数めっちゃかからない？
かかるっちゃかかるけど、ぶっちゃけすぐにペイできる。
償却期間は短い。

41. 41
● むしろ開発は難しくない -> 工数は大きくない
● なぜなら、制御盤連携Appと対になる存在なので
片方の開発ナレッジは片方に活かせる
● 原則クリーンアーキテクチャに則って
開発しているのだが、
そのほとんどの層の実装を共通化できる
アプローチ
引用元: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

42. アプローチ
42
● その制御盤を操るためのコア部分は
Entityとして実装
○ なぜなら同じ制御盤連携だから
● Controller層も大きな差は生まれない
○ 同じ連携方法であるが故に
その中の具体に迫る分岐は似る
○ ただし微修正は必要... 工数は小さめ
● ゼロから開発するのはUsecaseの部分
● RepositoryやExternal Interfaceは
大きく変わるが規模自体は小さい
開発が必要だがモックデバイスの
種類毎に作る必要はなく横断的に流用可
ある程度
流用可
同じ
ここだけ明確に
開発が必要
引用元: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

43. アプローチ
43
独自TCP/IPプロトコル
Entity: 同じプロトコルだか
ら双方で変わらない
Controller:
どんなときに何のユースケース？っていうのは変わ
るけど、その分岐自体のベースになる条件は双方
で大差ないので微修正で済む
Usecase: どのようなワーク
ロードが発生するか？それ
を如何に捌くか？は全然
違って然るべき
Repository / External Interface:
外部にどう振る舞うか？はさすがに変
わるのが、モックデバイス全体では大
差ないので流用可
例えば...

44. アプローチ
44
● どちらかというと、そういった変更容易性を最初から意識して
ソフトウェアアーキテクチャも設計すべき
Entity
Usecase Usecase
Controller
Repository
それぞれの要件
に応じて、
増やすか、隠蔽
された内部を変
えるだけ
モノ次第だけどStrategyを組み
合わせてUsecaseを構成する。
こうすることで、Usecase内部で
の何かしらの変更のときに
Strategyの切り替えや修正だけ
で済む。

45. アプローチ
45
● 結果的にこれはテスタビリティの向上にもつながる
○ 通常の開発シーンでは“モックデバイス”を使わずとも、
そもそも各層に”モック”を注入することで単体テストが書きやすくなる
○ IoTレイヤー〜制御盤連携としてのE2Eテストならモックデバイスで
テストが簡単にできる
○ SaaS側の画面操作なども含めたユースケーステストでは
モックデバイス + 自動テストツールの併用で
高速かつ手軽に全数テストが可能になる

46. 自動テストへの応用
46

47. 自動テストへの応用
47
● ビットキーではmablを利用中
● メインプロダクトたるSaaS領域の自動テストソリューションを見繕う中で
mablが採用された
● 我々はフロント側も作ったりするし、その画面操作契機で
制御盤連携を走らせたりもするのでmablは都合が良い
https://www.mabl.com

48. 自動テストへの応用
48
● そもそも本来なら制御盤連携は自動テストが難しい
● なぜなら物理操作が必要になったりするし、数十分に一回しか動かな
い機能とかを自動テストするというのはツラい
● そこでモックデバイスが使える

49. 自動テストへの応用
49
● モックデバイスでは、REST APIを用意し、
任意の機能を任意タイミングで発動させたり、
エラー状態を意図的に引き起こさせたり出来るようにしておく
● 開発シーンにも非常に有用だが、自動テストにもめちゃくちゃ効く
POST /path/to/something

50. 自動テストへの応用
50
● mablはテストケースを構築する中で、任意のJSスニペットを起動したり、外部
APIを実行する機能がある
● その機能をフル活用することで、自動テスト化なんて本来は出来なかった部
分を可能にし、人間が関与せずともガンガンテストできるようにしてある
POST /path/to/something

51. 自動テストへの応用
51
● これで、手動でやったテストケースはどんどん自動テスト化し、
次回以降は基本的に手動でやらなくてもよい状態を作り出す
モックデバイス
1回目
2回目以降
実機

52. 自動テストへの応用
52
● モックデバイスかつmablによる自動テストによって高速にテストを回す
● リリース内容毎に重要度や影響度の高さによって、
人間が実機を使って手動で確認するテストケースももちろんある
○ しかし、それらは極少量のテストケースに限られるのでQA時間は短い
モックデバイス
大事なテストケース
は人間が実機で
それ以外のテスト
ケースは自動実行
実機

53. 自動テストへの応用
53
● 本来なら全量テストケースを回すには莫大な時間が必要になる
● 回帰テストもかなり大変
○ 往々にして過去不具合はシビアな条件によって引き起こされたりするので、
その状況を物理的に作り出すのも大変
● しかし、mablによる自動テストならば、ほったらかし状態でOK！
● 以前なら工数の問題で削るテストも躊躇なく全部やれる
1テストケースを捌くのに
20分かかっちゃう...
人間が関与せず勝手に
やるよ！
夜の間にやるよ！

54. 自動テストへの応用
54
● “万が一”も考えて、不定期に実機でのテストも再度やったりもしている
● 今までそういう例はないが、モックデバイスによるテストならOKだけど実機だとNG
みたいなケースが不具合が実は潜んでいる・・・というケースがあるかもしれないの
で
モックデバイス
機能Aの
テストケース1
mablでの自動テストはずっと回してるけど、実
機のテストはn週間やってない...
実機で確認しよう。

55. 自動テストへの応用
55
デモ

56. 宵越しのxxはしない
56

57. 宵越しのxxはしない
57
1. 宵越しのタスクは持たない
2. 宵越しのPRは残さない
3. 宵越しのリリース待ちコミットは置かない

58. 宵越しのxxはしない
58
1. 宵越しのタスクは持たない
2. 宵越しのPRは残さない
3. 宵越しのリリース待ちコミットは置かない
1日で終われる程度の粒度に予め分解。
むしろその粒度でマージできるように予めコー
ドが構成されている必要がある
タスクに則ったPRなら小さなPRのは
ず。
何かしらレビュー対応などがあった
としても小さいはずで、
夜を跨ぐようなPRは出さない
QAはすぐ終わる。終わったらならす
ぐ出す。明日やろうと思うな！今す
ぐリリースだ！

59. 宵越しのxxはしない
59
1. 宵越しのタスクは持たない
2. 宵越しのPRは残さない
3. 宵越しのリリース待ちコミットは置かない
1日で終われる程度の粒度に予め分解。
むしろその粒度でマージできるように予めコー
ドが構成されている必要がある
タスクに則ったPRなら小さなPRのは
ず。
何かしらレビュー対応などがあった
としても小さいはずで、
夜を跨ぐようなPRは出さない
QAはすぐ終わる。終わったらならす
ぐ出す。明日やろうと思うな！今す
ぐリリースだ！
“あれもこれも”と欲張らない！

60. 宵越しのxxはしない
60
● 1つや2つの修正内容であってもどんどんリリースする
● 開発工数もQA工数も小さく、どんどん出していく
● すぐ作って、すぐ検証して、すぐリリースしていく
● これをどんどんイテラブルに回してく
● モックデバイスと自動テストがあるからこそ、この戦略が取れる
リリース
リリース
✕
夜は跨がない

61. 宵越しのxxはしない
61
● 意図的に狭いスコープでのリリースにすることで、
“予期せぬ不具合” -> “実はあのコード、ここにも関係あったじゃん！”
みたいなことを可能な限り抑制していく

62. まとめ
62
● 制約の大きい”物理が絡む開発”において、モックを作るのは結果的に生産
性向上につながる
● 欲張らず、小さく細かく、さっさとリリース
● それが出来るように、変更も追加も容易になるようなアーキテクチャを予め設
計しておくことがとても大事

63. 63
おわり