この記事は株式会社ビットキー Advent Calendar 2022 18日目の記事です．
Connect Firmware所属の @NaotoFujihiro が担当します．
自己紹介
大学には，物理学専攻で入学し，途中で社会学専攻に転入学しました．大学卒業後，IoT関連の会社を経て，ビットキーに転職しました．
アニメは，攻殻機動隊が好きで，いつかタチコマの実物と会話してみたいです．
ビットキーでは，ファームウェアエンジニア[注1]として，いわゆるIoTサービス開発を担当しております．本記事では，私がこれまでに経験してきたIoTサービス開発より，（当たり前かもしれませんが）大切だと考えている『テスト・品質』のこだわりを3つほどお話しします．
IoTサービスとは
IoTサービスは，大まかに『デバイス』『クラウド』『アプリケーション』で構成されます[注1][注2]．ファームウェアは『デバイス』に書き込まれ，物理世界の制御や『クラウド』とのデータ送受信を行います．
詳しい説明は，『AWS IoT の仕組み』[注2]や『IoTとは？ 重要な4つの構成要素と活用事例、自作のための知識を紹介』[注3]という素敵な記事に譲ります．
ポイント1『IoTサービスを網羅したテスト設計』
一番大切な観点は，『IoTサービスを網羅したテスト設計』を行うことです．ファームウェアエンジニアだからといって，『デバイス』だけを考慮してテストしても，品質はなかなか向上しません．
私はIoTサービス開発において，いくら異常系テスト[注4]を実施しても再現できなかった『デバイス』の故障[注5]に遭遇したことがあります．動作中にデバイスの電源を切断したり，デバイスとクラウドの通信を悪化させたりしましたが，なかなか再現できません．発生確率が 0.01 % オーダの故障と疑い，ひらすらテストしても再現できませんでした．
一度頭を整理するために，ホワイトボードに『デバイス』だけではなく『クラウド』や『アプリケーション』も含めた全体像を書き出しました．『デバイス』では想定していない，『クラウド』の動作が原因であることを疑い，あえて『クラウド』を誤動作させてみました．すると，『デバイス』の故障を再現できました．
『デバイス』の故障として顕在化しましたが，実はその原因は『クラウド』の欠陥[注6]でした．これでは，いくら『デバイス』を調査しても，その原因は発見できませんね．
IoTサービス全体を考える重要性は述べてきましたが，一体どのようにIoTサービスを網羅すれば良いのでしょうか？ユーザがどのようにその製品を使用するか，開発者も想像し体験することが大切だと，私は考えております．ユーザの使用方法をイメージできれば，「ここで，このような操作を加えても，デバイスを問題なく使用し続けられるかな？」ということを考えられるようになります．
とはいえ，無限に時間があるわけではないため，詳しい方法は先人の叡智に頼りましょう．テストについて調べていると，ISO/IEC 25010[注7][注8] や ISO/IEC/IEEE 29119[注9] にたどり着きました． ISO/IEC 25010 に記載されたテスト観点を取り入れることで，観点の抜け漏れがないテストを実施することができます．ISO/IEC/IEEE 29119 に記載されたプロセスを取り入れ，プロダクトリスクを考慮したテストを実施することで，製品のQCDを最大化させることができます．注意点としては，「テストは欠陥があることは示せるが，欠陥がないことは示せない」[注10]ことです．どんな活動にも銀の弾丸はありませんね．
ポイント2『テスト設計を踏まえた仕様レビュー』
別の観点は，『テスト設計を踏まえた仕様レビュー』を行うことです．初めて設計した段階では，その時点でベストな仕様が完成しているはずです．通常であれば，そのまま設計・開発が行われることでしょう．
ユーザは得てして開発者の想定通りには，サービスを使ってくれません．また，『デバイス』は開発者が想定しているような快適な環境に設置されるとは限りません．『クラウド』との通信品質が悪い環境に設置される可能性も十分に考えられます．クオリティの高い仕様を設計するためには，そのような『開発者にとっては想定外』の使用方法も考慮しておく必要があります．さらに，ポイント1で述べたように，もしかしたら『クラウド』に潜んでいた欠陥が原因で，『デバイス』で故障が発生するかもしれません．
『初めて設計した仕様』では，開発者にとっては想定外な使用方法やデバイス以外の領域に存在する欠陥によって，引き起こされる故障を想定できているでしょうか？私はその想定が漏れていることが非常に怖いです．IoTサービスにおける『デバイス』は，天井裏や海上のような，人が普段立ち入らない場所に設置されることがあります．そのような場合，故障が発生したからといって，気軽にファームウェアを更新することは難しいです（厳密には可能ですが，費用対効果を考慮すると，割に合いません）．ということは，IoTサービスにおけるファームウェアは，『開発者にとっては想定外』である事象も考慮した仕様を検討する必要があると，私は考えております．
仕様をブラッシュアップするときに活躍するのが，『IoTサービスを網羅したテスト設計』です．IoTサービスを網羅しつつテスト観点を抽出すると，仕様の抜け漏れや仕様同士の矛盾点に気づくことができます．仕様の抜け漏れに気づくことで，開発者の想定外の使用方法であっても，ユーザの体験性を損なう可能性はグッと低下します．『想定外の使用方法だと，このデバイスは動作不能に陥ってしまいます！』なんて製品は，使いたくないですよね．仕様同士の矛盾点に気づくことで，実際の使用方法に適した製品になります．『ある機能Aとある機能Bをほぼ同時に使用すると，結果は毎回ランダムで変わります！』なんて製品は，使いたくないです．
ポイント3『IoTサービス特有の難しさを考慮した不具合分析』
最後の観点は，『IoTサービス特有の難しさ』を考慮して不具合分析を行うことです．IoTサービス開発における不具合分析には，特有の難しさが2点あると私は考えております．
- 設置環境起因の不具合を再現する難しさ
- 原因の切り分けの難しさ
『設置環境起因の不具合を再現する難しさ』とは，開発者が意図的に，『デバイス』が設置された環境に起因する不具合を再現することは難しいということです．環境起因の不具合とは，例えば，天井裏に設置された『デバイス』だと発生しやすいが，その他の場所に設置された『デバイス』ではなかなか発生しないような不具合です．
環境の差分を考えてみると，例えば，温度湿度や『クラウド』との通信品質などがあります．このうち，どれが原因でこの不具合が発生しているのでしょうか？開発者の手元で，怪しいものから順に検証してみたくなります．簡単に準備できるものから，準備に骨が折れるものまであります．
この難しさを克服するためには，設置環境起因の不具合を想定して，その不具合に影響を与える可能性のある情報を，『デバイス』にログとして残すことです．一例を挙げると，『クラウド』との通信が意図しないタイミングで切断されてしまう不具合では，切断時に『クラウド』との通信品質を『デバイス』に記録し，復旧時に『クラウド』へその情報を送信することです．異常時だけではなく，正常時も定期的に『クラウド』との通信品質を記録していれば，正常時・異常時の差分を比較検討することができます．そうすれば，望ましくない切断と『クラウド』との通信品質の関係性を分析することが可能となり，早期に不具合分析を前進させることができます．
『原因の切り分けの難しさ』は，既に『ポイント1』でIoTサービス網羅の重要性にて述べました．『デバイス』『クラウド』『アプリケーション』それぞれの仕様を把握することで，その不具合がどの領域で発生しているか見当をつけられるようになります．見当をつけられれば，原因である可能性の高い領域から詳細調査を行えるため，工数の削減に繋がります．また，不具合をなかなか再現できない状況は精神的にも辛いため，その辛さを比較的早急に取り除くことができます．
まとめ
私のこれまでの経験より，IoTサービス開発には
- ポイント1『IoTサービスを網羅したテスト設計』
- ポイント2『テスト設計を踏まえた仕様レビュー』
- ポイント3『IoTサービス特有の難しさを考慮した不具合分析』
の3点が大切であると説明しました．これらを意識するだけでも，品質は大幅に向上できると信じております．これからも，品質にはこだわりながら，IoTサービス開発を行いたいです．
参考文献
[注1] ウィキペディア，2021，「ファームウェア」，（2022年12月16日取得，https://ja.wikipedia.org/wiki/ファームウェア）
[注2] Amazon Web Services, Inc.，2022，「AWS IoT の仕組み」，（2022年12月16日取得，https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/aws-iot-how-it-works.html）
[注3] ローム株式会社，2019，「IoTとは？ 重要な4つの構成要素と活用事例、自作のための知識を紹介」，（2022年12月16日取得，https://www.rohm.co.jp/blog/-/blog/id/7405417）
[注4] Kouichi Akiyama，2021，「第102回： 正常系と異常系」，（2022年12月16日取得，https://note.com/akiyama924/n/nb1133b40941f）
[注5] JSTQB，2018，「ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03」: 17-18，（2022年12月16日取得，https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf）
[注6] JSTQB，2018，「ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03」: 17-18，（2022年12月16日取得，https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf）
[注7] JASST，2021，「ISO/IEC 25010の品質モデルを使って市場不具合を減らす
テスト設計戦略～品質を「見える化」する～」，（2022年12月16日取得，https://www.jasst.jp/symposium/jasst21tokyo/pdf/A4.pdf）
[注8] kikakurui.com，2013，「システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル」，（2022年12月16日取得，https://kikakurui.com/x25/X25010-2013-01.html）
[注9] Qbook，2022，「ソフトウェアテストの国際規格 ISO/IEC/IEEE 29119 とは？」，（2022年12月16日取得，https://www.qbook.jp/column/20200521_897.html）
[注10] JSTQB，2018，「ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03」: 17-18，シラバス（学習事項）・用語集，（2022年12月16日取得，https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf）
明日 12月19日（月）の株式会社ビットキー Advent Calendar 2022は，Workspace & Experience Product Circle所属の @mball が担当します．