IoTプロダクト開発においては、デバイスを「つなげる」ための設計と、セキュリティリスクに適切に対処する「守る」視点の両立が不可欠となる。

本イベントでは、ブラザー工業が進めてきたデバイスのIoT化を支えるネットワーク・セキュリティ開発や、IoTデバイスを操作するWebサービス開発でのアジャイル導入の取り組みについて、プロダクト開発チームが詳細に解説した。

アーカイブ動画

海外売上比率80%を超えるグローバル企業のプロダクト開発体制

登壇者プロフィール
ブラザー工業株式会社
P&S事業 SC開発部
グループ・マネジャー
矢吹 智康（やぶき・ともやす）氏

冒頭では、矢吹智康氏がブラザー工業の事業内容と、今回フォーカスするプロダクト開発チームの全体像を紹介した。矢吹氏は2004年に入社し、長年プリンターの組み込みソフト開発やプロジェクトリーダーを歴任してきた。

1908年に創業したブラザー工業はミシン修理から始まり、現在は売上収益の約60%を「プリンティング・アンド・ソリューション（P&S）事業」が占めている。また、海外売上比率が80%を超えるグローバル企業でもあり、世界中で同社のデバイスが稼働している点も大きな特徴だ。

プロダクト開発チームは、大きく3つの層で構成されている。最下層には製品本体のデバイス制御やネットワーク制御を担うチームがあり、その上にデバイス情報の転送や通知を司る「IoTプラットフォーム」チームが位置する。最上層には、サブスクリプションやデバイス管理、ウェブプリントサービスを展開する「サービスプラットフォーム」チームが存在し、モバイルアプリやPCアプリの開発チームと連携している。

今回のセッションでは、デバイスとサービスの各開発領域における取り組みについて紹介していく。

デバイスのIoT化を支えるネットワークとセキュリティ開発

登壇者プロフィール
ブラザー工業株式会社
P&S事業 SC開発部
チーム・マネジャー
柳 哲（やなぎ・さとる）氏

次いで登壇した柳氏は、前半と後半パートに分けて、「つなげる」ネットワーク技術と「守る」セキュリティ技術を説明した。

かつてのデバイス接続はUSBによる一対一が主流であったが、ネットワーク対応が進んだことで、LAN経由での共有や、クラウド連携による自由度の高い利用が可能となった。ブラザー工業は、20年以上にわたる技術開発を通じてIPv4/v6対応や多様なプロトコルの搭載を進めてきた。

しかし、ネットワーク技術の進化により利便性が向上した一方で、「接続の設計ポイントやセキュリティ対策の難易度も増大している」と柳氏は強調した。

ネットワーク接続には「LAN接続」と「クラウド接続」の2つのフェーズがあり、それぞれ異なる課題が存在する。

LAN接続では「スピード」「動作の安定性」「相互接続性・互換性」が主な課題となる。そのため、スピード向上には軽量なプロトコルの採用やハードウェアアクセラレーターの活用といった内部設計の効率化が肝となってくる。

また、動作の安定性を確保するために通信障害時のリトライ制御やリカバリー設計を徹底し、長時間耐久試験で品質を担保することも重要だ。さらに、接続先のOSや利用環境の変化を事前に収集し、実際の接続検証を通じて確認を進めるプロセスも求められる。

一方でクラウド接続ではLAN接続と異なり、デバイスが「サービス提供システムの一部になる」という点に留意しなければならない。ファイアウォール外のサーバーからの制御、世界中からの膨大なアクセス、そしてクラウド側の仕様変更や国・地域の規制といった外的要因の考慮が必要になってくるわけだ。

つまり、デバイス単体ではなく、システム全体を見て設計することが重要になると言えるだろう。

ここから柳氏はクラウド接続における要点を説明した。

1つ目は、ファイアウォールの外にあるサーバーから指示を受け付ける点だ。サービス提供システムの一部として機能するには、印刷やスキャン、情報照会など、サーバーからの指示に対してリアルタイムに応答できることが求められる。この要件に対応するため、ブラザー工業ではMQTTを用いて長期セッションを維持し、クラウドからの指示をプッシュ型で届ける設計を採用。

こうすることで、NAT配下にあるデバイスでも、サーバーからの指示をリアルタイムに受け取ることが可能となる。

また、用途に応じてプロトコルを使い分けており、例えば状態監視にはMQTTを、データ転送にはHTTPを用いるなど、それぞれの特性に合わせた実装を行っている。さらに、AWSの汎用的な機能に対応できるよう、X.509証明書によるクライアント認証や、デバイスシャドウ、ジョブ機能にも対応している。

2つ目のポイントは、サーバーが世界中のデバイスから膨大なアクセスを受け付けるということだ。

世界中の数百万台のデバイスが一斉にクラウドへアクセスする状況を想定すると、「サーバーにかかる負荷が極めて大きくなること」は想像に難くない。当然、これらの処理は費用面での影響も無視できない。

そのため、デバイス側からは情報のアップデートや生存確認といった不可避な通信が発生するものの、送信条件を工夫し、不要なデータを極力送らないように設計することで無駄を削減している。

3つ目は、サーバーの仕様変更により、デバイスが一斉に影響を受ける点だ。

クラウドは高速に進化する一方で、APIや接続手順の変更がそのまま全デバイスに影響してくるゆえに、都度そうしたアップデートに対応していかなければならない。

そこでブラザー工業では、デバイス側に汎用的なインターフェースだけを持たせ、細かな仕様差分は中継サーバーで吸収するという構成にしているとのこと。

さらに、証明書の失効や新規サービスにも対応できるように、必要な証明書をサーバー側から配布できる仕組みを整備。破壊的な変更が生じた場合にはファームウェアの更新が必要となるが、できる限りそのような更新機会を迎えずに済むような設計に落とし込んでいるという。

4つ目は、国・地域を超えたデータの受け渡しには規制があるということだ。

欧州のGDPRをはじめ、各国のデータ規制に準拠するには、デバイスがどの国・地域で使われているかを理解し、その仕向けに合わせて接続先リージョンを正しく選んでいくことが大切になる。

そのため、デバイス内部の仕向け設定と、サーバー側が動的に返すリージョンごとの接続先情報を組み合わせたハイブリッド方式を採用し、「デバイスは環境に応じて適切なリージョンへ接続し、各国コンプライアンスに準拠した形でサービスを提供できるようにしている」と柳氏は話した。

次にクラウド接続におけるリスクと対策について柳氏が説明した。

クラウドに接続すると、デバイスはインターネット上に直接さらされる形になる。

そのため、攻撃者が正規のサーバーのふりをしてデバイスの接続を奪い、情報を抜かれる「サーバーのなりすまし」や、通信の途中でデータを盗聴・改ざんされる「中間者攻撃」、攻撃者が本物のフリをしてサーバーに接続し、不正情報を送ったり、システムに侵入したりする「デバイスのなりすまし」といった3つのリスクが露出する。

こうしたリスクヘッジのために、「デバイス固有のX.509証明書をプリインストールした状態で出荷」「mTLSによる相互認証」「TLSに安全な暗号スイートを適用」という3つの対策を組み合わせることで、正規のサーバーと正規のデバイス間におけるセキュアな通信を確保している。

ただし、ここまでの対策を施したとしても、デバイスそのものを直接標的とする攻撃リスクは拭えない。そこで、後半ではデバイス自体をいかに守るかという総合的なセキュリティ対策を紹介していく。

後半パートでは、まずIoTデバイスを取り巻くセキュリティ動向を柳氏が示した。

情報通信研究機構のグラフによると、昨年観測された攻撃予兆のパケット数は、1IPあたり約250万パケットに達しており、比較的マイナーなアザーポートへの攻撃割合も増加していることから、IoTデバイスを標的とした攻撃が拡大していると推察される。近年は平穏に見える時間帯でも、インターネット上では常時スキャンや偵察が走っているのが実情で、「脆弱な機器は見つかった瞬間に自動化された攻撃の対象になり得る」という。

IoTデバイスが狙われやすい理由は、PCなどのIT機器よりもセキュリティの作り込みが弱いことや、オフィスや家庭以外にも工場、医療、自動車など様々なところに導入されているため、攻撃の対象範囲が広範に及ぶことが挙げられる。

さらに、膨大な数のデバイスが存在することで、DDoS攻撃などを行う際に攻撃者にとって有利に働くことが想定されるほか、セキュリティアップデートなどのメンテナンスが、IoTデバイスにおいては十分に浸透していないのも狙われやすい一因になっている。

こうした現実を受け、各国では規制や認証制度を整備する動きが加速しており、セキュリティ対策は「やるとよい」から「やらねば売れない」という状況に変わってきていると柳氏は強調した。

近年、セキュリティ対策の要件は「製品機能」のみにとどまらず、「製品ライフサイクル」全般にまで及んでいる。そのため、単にセキュアな製品を開発すればよいというわけではなく、セキュアな製品を継続的に開発・運用できる「体制・プロセス」そのものを構築することが求められていると言えるだろう。

そうしたなか、製品ライフサイクルで実施すべきセキュリティ対策で重要なのが、開発プロセスでの「セキュア・バイ・デザイン」の実践だ。開発の上流工程でリスクアセスメントを行い、必要なセキュリティ要件をしっかり定義する。

設計段階では、ベストプラクティスに沿ってセキュアな仕様を作り込み、実装フェーズではセキュアコーディングを実践し、SAST、DASTといったセキュリティツールやペネトレーションテストなど、多面的な検証で品質を確認する。

これらをプロセス化して実践することで、属人化からの脱却やセキュリティ対策が可能になるわけだ。

もうひとつ、製品出荷後のセキュリティ担保も大事な要素だと言える。製品を出して終わりではなく、その後の脆弱性や新たな攻撃手法が見つかることに対してもケアが必要になってくるからだ。

ブラザー工業では、PSIRTを組織的に運用し、脆弱性やインシデントが発生した際には、迅速かつ適切に対応できる体制を整えているという。また、脆弱性情報の収集、監視を継続的に行い、外部からの報告窓口も設置するなど、「お客様が抱える潜在的なリスクを早期に発見できる仕組みを整備している」と柳氏は述べた。

続いて、デバイス自身が持つ製品機能としてのセキュリティ対策で重要なのが、「セキュリティリスクアセスメント」である。

デバイスが取り扱う情報資産や利用環境、ユースケース、データの流れを整理し、想定される攻撃面を洗い出した上で、各所に存在するリスクに対して必要な対策要件を明確化していくプロセスとなっている。

ここでは具体的に5つの対策例を紹介した。

情報資産へのアクセス認証

最も基本的な対策の一つに挙げられる。これは製品パネル、ネットワーク経由の設定ツールなど、製品の情報資産へのアクセスインターフェースに対し、正規なユーザーであることを認証するための機構である。

セキュアな通信とデータ保護

アクセス認証の効かないネットワーク通信路やデバイスストレージ上のデータについても保護が必要なので、ネットワークに関してはTLS、SSH、IPsecなどのセキュアな通信プロトコルを使用し、ストレージに対してはデータを暗号化して保存することが大切になる。加えて、製品破棄・リサイクル時を想定したセキュアな消去手法を用いることも重要だ。

ファームウェアの信頼性確保

適切なセキュリティ対策を実装しても、ファームウェアそのものを不正に改ざんされてしまうと、すべてが崩れてしまう。また、脆弱な古いファームウェアを書き戻すダウングレード攻撃への対策も不可欠だ。そのため、デジタル署名などを用いて不正なファームウェアのインストールや起動を防ぐことが肝になる。

ベストプラクティスな暗号アルゴリズムの搭載

CRYPTRECや各国のガイドラインにベストプラクティスが記載されているので、そちらをしっかり確認した上で採用し、脆弱なアルゴリズムについては無効化していくという対策になっている。

セキュア・バイ・デフォルト

初期状態の製品への攻撃を防ぐため、脆弱なプロトコルの無効化、安全な初期管理者パスワードの割り当てなど、出荷した瞬間から一定の安全性が保たれるように設計をするアプローチだ。

様々なセキュリティ対策があるなか、柳氏はブラザー工業が実際に直面した課題と その解決策を解説した。

1つ目の課題は、「どこまで対策を施せば十分なのかが判断できない」という点である。セキュリティリスクは利用環境やユースケースによって大きく異なるため、あらゆる攻撃に備えることは現実的ではない。想定される攻撃ケースをすべて挙げて いけば、対策は無限に必要となり、それがそのままコスト増につながる。

実際に、開発者から「どこまで対応すればよいのか」という質問を数多く受けてきたと柳氏は言う。この問いに対しては、まず自社と同等製品のベンチマークや業界のベストプラクティスを参考に、対策の水準を把握することから始めた。その上で、製品ごとにリスクアセスメントを実施し、その結果を対策基準に反映させるというプロセスを取ってきたという。

基準を決めるにあたっても、第三者に説明するシーンをイメージしながら、「その対策で安全である」ということを客観的に説明できるか、という点で判断していたそうだ。

2つ目は「セキュリティを高めるほどユーザビリティが犠牲になる」という点であ る。セキュリティとユーザビリティはトレードオフになると言われる。通信をTLSに置き換えるなど、ユーザビリティを変えずに行える対策を未然に行っていても、どうしてもユースケースに影響するものも出てくる場面がある。

その場合は、セキュリティ要件の範囲内で影響を最小限に抑える方策を検討し、それでも妥協できない時には、互換性を考慮した設定を残しつつ、デフォルトでは無効にするという対応を取ってきたとのこと。

関係者の説得は容易ではないが、「このまま使い続ければ、顧客が危険な状態で製品を利用し続けることになる」といった現実を丁寧に説明することで、関係者からの理解を徐々に得られるようになってきたと、柳氏は交渉の工夫を説明した。

3つ目の課題は、「組織全体にセキュリティの意識が浸透しない」という点だ。組織全体で一貫したセキュリティ対策を実施することは非常に難しく、組織間や個人間ではどうしても意識にばらつきが生じてしまう。

そこで、トップダウンとボトムアップの両方のアプローチでセキュリティ対策を進 めてきたという。

トップダウンについては、かつてセキュリティ問題が多発した時期があり、経営層 にもその重要性が認識されていたため、プロセスへの適用はある程度スムーズに進 んだ。

しかし現場への浸透には時間を要したので、個別案件や法規制対応の取り組みを通 じてキーマンを育成し、そこから組織全体へ徐々に波及させるというボトムアップ のアプローチを並行して進めたそうだ。

こうした取り組みに加えて、昨今の法規制強化なども追い風となり、組織全体のセ キュリティ意識は確実に向上しているとのこと

今後のセキュリティ関連の動向では、EUで新たに施行される「サイバーレジリエンス法」、そして「耐量子暗号」への対応が必要になってくるという。

前者は、製品ライフサイクルに対する高い水準のセキュリティ対策が一層求められることが想定されるので、関連規格を十分に読み込んだ上で、各プロセスや脆弱性対応における体制の見直しが必要になるだろう。

後者は、デバイスレベルでの置き換えは容易ではないため、製品内部で暗号を利用している箇所を抽出して影響調査やリプレイスの計画を立てるなど、中長期的な視点を持つことが鍵を握る。

最後に、柳氏はネットワーク・セキュリティ技術開発の難しさとやりがいについて述べた。

ネットワークもセキュリティも単体では成立しないからこそ、構造的な課題に向き合い、多くの開発者と連携して最適解を探していくことに大きなやりがいを感じているという。そして最終的に製品全体としての価値向上を実感できるのは、この仕事の大きな魅力だと強調した。

さらに法規制の更新や、サイバー攻撃手法の進化、脆弱性情報、新しい技術など、変化の激しい領域で常にアンテナを高く持つとともに、自社製品への影響を見極めながら対応方針を作ることが重要になる。

その過程において、業界団体やパートナー企業、社外の専門家や関係者と議論しながら、最新の課題を共有できるのも、この領域ならではの楽しさだと語った。

IoTプロダクトにおけるWebサービスのアジャイル開発導入

登壇者プロフィール
ブラザー工業株式会社
P&S事業 SC開発部
梅本 匠（うめもと・たくみ）氏

次に登壇した梅本氏は、2021年にブラザー工業へ入社以来、Webサービス開発に従事しており、現在は民生プリンター（オフィスや自宅で紙に印字するタイプのプリンター）の遠隔保守サービスの開発をアジャイルチームで実践している。

その「サービスプラットフォーム」は、AWSマルチアカウント環境で開発を進めており、IoTプラットフォーム基盤のAPIを実際に呼び出し、デバイスセキュリティを考慮したテストを日々実施するWebサービスの開発事例となっている。

今回の発表では、IoTプロダクトにおけるWebサービスのアジャイル開発導入における実践的な知見が共有された。

ブラザー工業にはエンタープライズ向け製品の「消耗品自動配送サービス」がある。これは利用中のプリンターから消耗品の使用状況データを自動収集し、トナーやインクの残量が少なくなるタイミングで、必要な分を自動的に顧客のもとへ配送する仕組みとなっている。また、消耗品の継続利用を支えるために、プリンター本体のメンテナンスもあわせて提供している。

冒頭で示したように、ブラザー工業は海外売上比率が80%を超えており、この製品も欧州や米州での売上比率が高くなっている。そんななか、顧客のプリンターにトラブルが発生した場合、従来サポートスタッフが現地に訪問して対応する必要があり、その都度約20,000円のコストが発生していた。

これに対し、遠隔保守サービスを利用することで、ブラザーグループの販売会社に所属するオペレーターが遠隔からデバイスへアクセスし、プリンターの設定変更などの操作を行うことで、サポートスタッフが現地訪問をしなくても、顧客側のデバイスの不具合を解消できるようになった。

この仕組みにより、顧客側は訪問対応のための日程調整が不要となり、ブラザー工業側も現地対応に伴うコストを削減できるため、双方にとってメリットの大きいサービスだと言える。

遠隔保守サービスはAWS上に構築されており、サーバーレスコンピューティングサービスであるLambda上に、フロントエンドフレームワークのRemixを用いたWebアプリケーションとして実装している。

このLambdaから、IoT基盤プラットフォームのAPIにリクエストを送信し、デバイスに対する読み込みおよび書き込み処理を実行する構成となっている。

なお、書き込み処理の結果は同期レスポンスではなく非同期で返却されるため、API管理・公開サービスのAPI Gatewayと、ワークフロー管理サービスのStep Functionsを組み合わせて制御している。

具体的には、書き込み要求の結果をDynamoDBに記録し、そのデータをLambdaが参照することで、販売会社のオペレーターに対し書き込み処理の結果を画面上に表示できるよう実装しているという。

こうしたなか、なぜアジャイル開発を導入したかというと、「ユーザーである販売会社と開発チームが直接コミュニケーションを取ってプロダクトを開発したいと考えたから」だと梅本氏は語った。

従来の開発プロセスにおいては、企画部門がブラザーグループの販売会社の要望を資料として取りまとめ、開発チームがその資料に基づいて仕様を決定・実装するという流れが一般的であった。

しかし、この方法では「販売会社がなぜその機能を求めているのか」という真のニーズや背景が開発チームに十分伝わらないまま、仕様に基づいて開発が進められてしまうという問題があった。その結果、完成したプロダクトを販売会社に提示した際に「実用性が低い」と評価されることがあり、開発チームと販売会社との間にミスマッチが生じやすい状況であった。

そこで目指したのは、企画機能を持つ自己組織化された開発チームが、実際にユーザーの声を直接聞き、作ったものを即座にユーザーに試してもらえる体制である。

プロダクトが意図通りに機能しているかをチームで判断し、必要に応じて即時に改善を図る柔軟な組織の構築を目標としたのである。

遠隔保守サービスチームはプロダクトオーナー1名、スクラムマスター1名のほか、複数の開発者が所属している。週に1回のスプリントレビューでは、ユーザーにスプリント期間で作成したプロダクトを実際に操作してもらい、デモを通じてフィードバックを収集しているという。

必要に応じて週1回の枠にとらわれず、会議やチャットを通じて頻繁にコミュニケーションも実施している。2023年6月のサービス開始以来、これまで70回近いスプリントを実施してきたが、遠隔保守サービスはIoTデバイスを操作するWebサービスであるため、「従来のPCやサーバー間で完結するサービスよりも、アジャイル開発の難易度が高い」と梅本氏は述べた。

アジャイル開発における理想的なチームの状態とは、完全に自己組織化されており、外部からの影響を受けることなく自律的にユーザーへ価値を提供し続けられる状況を指す。具体的には、品質管理やテストに精通した専門人材が、その開発チームに専任で所属している状態である。

しかし、組織体制上の制約から、そうした専門人材をひとつの開発チームに専任として配置することが、リソース面で難しい状況にあったという。

専門人材がチームに在籍していない状態で、どのように自己組織化したのか。

まず、チーム内で品質観点を管理し、チーム外に依存せずにIoTデバイス関連の品質を確保する取り組みを実践したという。

ブラザー工業は製造業企業であり、ソフトウェアのプロダクトリリースにおいても品質保証プロセスが組み込まれている。従来は開発チームが実装・テスト後にQAが審査し、問題なければリリースする方式だった。しかしこの方法では、一週間という短いスプリントサイクルでのリリースには問題があった。というのも、開発チームは早期に設計・実装・テストを完了し、QAレビューを依頼する必要があり、もしQAが品質不十分と判断すれば再設計が求められる。

そのため、QAが最後の門番としてチェックする従来のやり方では、週単位のスプリント継続は現実的ではないからだ。そこで開発チームが取り組んだのが、QAの役割を「門番」から「伴走者」へと転換することだった。具体的には「QAの品質観点をチームでリスト管理すること」「リストに基づいた完了条件の作成」の2つのことを行ったという。

これまでQAが担ってきた品質審査は、暗黙知や個人の経験に依存している部分が多い状態であった。そこで、QA担当者に「どのような観点で品質を確保しているか」を明確に言語化してもらい、その内容を開発チームで「テスト観点リスト」として一元管理することにした。

QAが言語化した観点には「外部システムへの影響」「プリンターハードウェアへのダメージ」「書き込み可能デバイスの制御」といったIoTデバイス特有の項目が含まれる。これらに加え、開発者がソフトウェア開発の特性から重視する「非同期処理」「タイムアウト」「重複リクエスト」などの観点を統合し、IoT特有の観点とソフトウェア開発特有の観点の双方を、開発チームで一括管理できる体制を構築したのである。

テスト観点リストに基づく完了条件の作成では、「各機能が完成とみなせる基準を明確にしたテストケース一覧」を定義している。各ケースには簡単な説明として確認したい項目を記載し、「Given」ではテスト実施の前提条件を、「When」ではプロダクトの具体的な操作手順を、「Then」では操作後に期待されるプロダクトの状態を記述する。

基本的に開発しているプロダクトの状態を書くが、操作によって変化するデバイスの状態を期待値として記載しても差し支えない。

完了条件を考えるときは、実装する機能に対してテスト観点リストの中に「該当する観点が完了条件に含まれているか」を確認する。その際、テスト観点リストには具体事例を紐付けておくことで、完了条件を思いつきやすいようにしておく工夫をしているそうだ。

例えば「外部システムの影響」という観点では、「開発プロダクトに高頻度アクセスが集中し負荷がかかった場合でも、外部システムへの影響を与えない」といった事例を紐付けているという。

チーム内ではリファインメントというスクラムイベントで、実装に入る前に完了条件を作成し、それをQAに共有して品質観点が網羅されているかどうかをチェックしてもらう。追加の指摘があればそれを取り込んで、合意してからスプリントでの実装に入るが、その間に次のスプリントで実装したい内容のリファインメントを実施し、継続的に一週間リリースができる状態の維持を心がけているという。

このように、QAを実装後に審査する「門番」ではなく、実装前に共に品質を考える「伴走者」へと役割を変化させたことで、リリース直前の審査ではなく、開発の前段階に品質基準が組み込まれるようになったわけだ。

だが、これを実現するためには段階的なアプローチが必要であった。最初は、品質観点をもとに開発チーム単独で完了条件をすぐに作成するのではなく、QAと共同で完了条件を策定し、相互の認識を一致させることから始めた。次に、QA担当者に品質観点を明確に言語化してもらい、開発チームがテスト観点リストを一元管理できる体制を構築した。

その後、開発チームがリファインメント後の合意形成を通じて、自律的に完了条件を作成できる能力を証明し、QAからの信頼を獲得するステップを踏んだ。

この取り組みのポイントは、「開発チームが自ら品質を判断できる状態を作り上げること」だと梅本氏は挙げた。品質観点を自分たちのものとして理解し、活用できるようになることで、QAは安心して開発を任せられ、開発チームは自信を持ってリリースを実行できるようになるわけである。

ここからは、実機デバイスを仮想化し、IoTデバイス関連のテスト時間を削減した取り組みを紹介した。

実機デバイスを用いたテストは複数のテストケースを試す必要があり、さらには一つの開発アイテムに数十分、テスト準備には最大15分かかることもある。加えて開発チームは少人数ゆえに、全てのテストを実機で実施して一週間リリースを実現するのは現実的に困難になっている。

そこで、開発チームでは「シミュレーターの活用」と「シミュレーターの共有運用」に取り組んだという。

シミュレーターとは、IoT基盤上に仮想的なデバイスデータを生成するツールであり、社内の別チームが開発したものである。新機能として遠隔保守サービスの書き込み機能を実装するにあたり、既存シミュレーターには必要な内部データが存在しなかったため、アップデートが必要となった。

そこでシミュレーターの開発担当者に利用目的と必要なデータ対応を説明し、指定時期までの対応を調整した。さらに、シミュレーターのコードリポジトリを確認し、必要な変更をプルリクエストして次バージョンへの反映を依頼した。

その結果、書き込み機能のテストに必要なデバイス状態を、シミュレーターで約1分で準備できるようになった。実機デバイスでは最大15分かかっていた準備時間の短縮は、非常に大きな改善につながったと言えるだろう。

ただし、全てのテストケースをシミュレーターに置き換えるわけではなく、各機能・各モデルにおける正常系ハッピーパスの検証については、必ず1回は実機テストを実施し、15分以上かかってもデバイス状態を準備・確認を行っているという。

一方、副次的なケースの検証や、リグレッションテストなどでは、同じ状況をシミュレーターで再現しテストすることで、全体のテスト時間を短縮している。

次にシミュレーターの共有運用について、主に2つの取り組みを実施してきたと梅本氏は説明した。1つ目は「デバイスのシミュレーターのデバイス設定ファイルを共有フォルダで管理する」という運用だ。

従来、シミュレーターは個人のPC上で動作し、作成したシミュレーターデバイスは作成者しか制御できない状況であった。

そこで、デバイスの設定状況を管理する設定ファイルを共有フォルダに格納し、チームメンバー全員が同一設定ファイルを取得してシミュレーターを起動する運用を開始した。

新しいシミュレーターデバイスを追加した場合は、必ずローカル設定ファイルを共有フォルダへアップロードしてバックアップするルールを設け、その手順をドキュメント化して参照可能としたことで、開発チーム全員が同一シミュレーターデバイスを利用できる体制を整備した。

2つ目は「完了条件にテストを利用するデバイスのシリアル番号を明記する」という運用である。

完了条件の記述において、Given/When/ThenのWhenにおいて「検索窓にシリアル番号0123456を入力する」といった形で、具体的なシミュレーターデバイスのシリアル番号を明記するルールを導入した。そうすることで、誰がいつテストを実施しても、どのシミュレーターデバイスを使えば検証できるかが明確となるわけだ。

このように共有運用の仕組みを整えることで、開発チーム全員が同一テストケースを同一シミュレーターデバイスで繰り返し実行できる環境が確立し、チーム全員が必要なテストを自律的に遂行できる体制が実現したのである。

開発チームが自分たちで判断し、行動できる状態を作る。

そのために必要な知識、ツール、関係性を整えていく。

この自己組織化できる環境づくりは、「一週間スプリントという短いサイクルを継続する上で最も重要だった」と梅本氏は振り返った。

【Q&Aセッション】

Q&Aセッションでは、ブラザー工業の登壇者が参加者からの質問に対して回答した。

Q. P&S事業部のセキュリティ知見は他の事業部にも展開されているのか？
柳氏：P&S事業では、セキュリティに関して先行的な検討を進めてきましたが、今後はサイバーレジリエンス法などにより全事業・全製品が対象となるため、全社的な展開が急務であるという課題認識を持っています。そうしたなか、直近ではもともとP&S部門と連携していたメンバーを中心に、全社へ向けた取り組みを推進するセキュリティ部門が新設されました。この部門とP&S部門が相互に情報共有を行い、必要な情報を必要な部署で活用できるような連携体制が整いつつあります。

Q. 開発スケジュールとセキュリティのトレードオフはどのように意思決定しているのか？
柳氏：セキュリティは製品価値に直結する要素ではないため、「生産計画を調整してまで対応すべきか」という議論が生じることがあります。しかし当社では、許容できないリスクを抱えたまま製品を出荷するという意思決定は行いません。そのため、まずはリスクを許容可能な水準まで低減するための暫定的な対策を講じます。それが難しい場合には一度出荷を見送り、十分な対策を講じた上で、バージョンアップなどの形であらためて提供するという判断を行っています。

Q. アップデートを適用しないユーザーへのリスク対処については？
柳氏：当社は脆弱性対策として、ファームウェアの更新をリリースしていますが、その適用においては最終的にお客様の判断に委ねているため、どうしても直接コントロールできない部分があります。そのため、できるだけ多くのお客様にアップデートを適用していただけるように、製品パネルでの通知表示や、最新機種では自動アップデート（OTA）機能を搭載するなど、アップデートの適用を促す設計としています。

Q. シミュレーターは新人でも使えるようなものか？
梅本氏：シミュレーターはデスクトップアプリケーションとして提供されており、新人でも直感的に操作しやすい仕様となっています。ツールの使用方法については詳細なマニュアルも用意しており、マニュアルを参照すれば新人の方でもスムーズに利用可能です。ツールはJavaで実装され、exeファイルを起動するだけでデスクトップアプリとして立ち上がり、GUI上で簡単に操作できる設計になっています。

Q. 開発メンバーのセキュリティ知識に依存せず、安全な実装を促す開発プロセスや仕組みづくりは？
柳氏：当社では「基準」と「レビュー」を軸に、セキュリティ対策を管理しています。まず、セキュリティ対策で考慮すべき観点を、各種ベストプラクティスをもとに基準化したチェックリストとして整備しています。このリストを各要件ごとに確認していく運用としていますが、チェック業務は各部門に配置されたセキュリティ有識者の方々にお願いしており、そのプロセスを明確に規定することで管理を徹底しています。

Q. これまでQAに取り組んできた方が、テストの自律化で開発に関わることはあるのか？
梅本氏：QA担当の役割を「門番」から「伴走者」へ転換したという話をしましたが、リリース直前には「こういう内容でリリースします」という形で簡単なレビューの共有は今も行っています。また、完了条件の作成や品質観点の整理だけでなく、「今後アジャイルでどのように品質保証を行うか」といった内容を、他のチームに展開する際の検討にも一緒に関わっています。そのため、自律化以降も開発チームとの関わりは継続している状況です。

Q. セキュリティ要件のプロセスを、設計チームになじませるまでにかかった時間は？
柳氏：セキュリティ要件のプロセスを実際に運用できる状態まで落とし込むことは、非常に困難であると感じています。私たちのチームも、まだ道半ばの状況ではありますが、プロセスの各ステップで「ここは必ず実施する」といった基準を定めており、その点では一定の縛りを設けています。そうしたなかで、プロセスに直接関わる方々の理解が徐々に深まり、それが周辺のメンバーへ波及していく形で進展しています。どれくらいのスパンで完全に浸透するかは判断が難しいですが、数年単位の規模で進めていく必要があると考えています。