iOS版BLEアプリの作り方【第3回：アプリの仕様書作成】
こんにちは。連載企画「iOS版BLEアプリをゼロから作ってみました（企画〜開発〜審査まで）」を担当させていただきました株式会社ERiの澤村です。
企画の趣旨や概要説明はこちらの記事をご覧ください。
前回の「企画書作成」に続き、第3回目は「アプリの仕様書作成」についてご説明していきたいと思います。
仕様書は「実現したいこと」の「実現方法」を具体的に決めるもの
企画書が完成したら、次は仕様書を作成していきます。
（※受託開発の場合は、これ以降の作業は全て「正式ご発注後」となります。）
ここでは、企画書で定義した「アプリで実現したいこと」に対して、「アプリでどう実現するのか？」「アプリがどのような機能を持つのか？」「具体的にどのような挙動をするのか？」などの具体的な実現方法を決めていきます。
例えば、「収容アプリでの接続先のコントロールはどう実現するのか？」に対して、「リストUIで実現します」とだけ決めるのではなく、「リストが更新されるタイミングはいつか？」「リストの表示順は何を基準にソートするか？」といった細かい部分まで仕様を詰めます。
BLE通信周りの仕様で決めるべきことは？
BLE通信周りの仕様については、
- 接続/切断のタイミングは具体的にいつか？
- 接続/切断や通信に失敗したときの処理はどうするか？
- 受信したデータはどのように処理するか？
- バックグラウンドでの動作はどうするか？
といった内容に着目しながら仕様を詰めていきます。
特に、そもそもBluetooth接続できないときや、何らかの原因により望まないタイミングで切断されてしまったときなど、Bluetooth通信が失敗したときの処理を考えておくことがとても重要です。
BLE通信は障害物があったり、物理的に距離が離れると通信が不安定になることがあるため、常に安定した通信状態を維持できるとは限りません。また、ユーザが適切な切断手順を踏まずにいきなりデバイスの電源をOFFしてしまうようなケースも少なくないため、通信に失敗したときの処理をどうするのか、仕様としてあらかじめ明確にしておきます。
今回は状態遷移図を書くことで洗い出しを行い、抜け漏れが無いようにしました。
「LINBLE Keyboard」におけるBLE通信の仕様作成のポイント
「LINBLE Keyboard」の仕様決めで一番時間をかけたのが「切断のタイミングをいつにするか？」でした。
「接続すること」や「ちゃんとデータ通信すること」に比べるとあまり意識が向かないかもしれませんが、「切断すること」についてもしっかり考えておくことは大事です。
例えば、
「ユーザがアプリを操作していない間もずっと接続は維持した方が良いのか？」
「アプリがスマホ画面に表示されていない間（バックグラウンド）も接続を維持するのか？」
「何かのタイミングで自動的に切断した方が良いのか？」
「切断したいユーザはどのように操作すれば良いのか？」
など、操作や処理の「終わり」となる切断についても考えることがたくさんあります。
今回のLINBLE Keyboardでは「キーボード表示で接続/キーボード非表示で切断」とする案がありましたが、そうした場合、以下のような懸念点がありました。
- 一時的に別のキーボードで入力を行いたい場合や誤操作でキーボードが切り替わってしまった場合に、その都度接続⇔切断が起きるため、タイムラグが生じたり、操作感が損なわれる恐れがある。
- LINBLE Keyboardを複数のアプリで使用することを考えたとき、状態遷移が複雑になり管理が難しくなる。
そのため、「切断ボタンを設置してユーザがボタンから切断タイミングをコントロールできるようにし、それ以外は接続を維持する」ことでこれらの懸念点を解消しました。
電波は目に見えないからこそ「今の状態」がわかる工夫を
また、キーボードのユーザインターフェースについてもアドバイスを頂きながら仕様を修正しました。
本アプリでは、キーボードの上部にBLE通信のステータスメッセージを表示するようにしています。
これは「BLE通信状態が今どうなっているか」をユーザへ伝えることを目的としています。
BLE通信というのは目に見えないものなので、今はBluetoothでつながっているのか、切れているのか、データが送られているのか、ユーザはそれを目で見て判断することができません。だからこそアプリを通して、ユーザにできるだけ「今どういった状態なのか」を伝える工夫が大切です。つまり「状態の可視化」です。
一例をご紹介します。
本アプリでは、キーボードから接続を試み続けますが、仮にLINBLEがアドバタイズしていなかった場合、永遠に接続が確立されず、キーボードから接続を仕掛け続けることになります。当初は、接続を試みてから接続が確立するまでの間、ずっと「接続を試みています」というステータスメッセージを表示し続けるようにしていましたが、そうするとユーザーはずっと接続を試みているのに、なぜ接続が確立されないのかが分からないままになってしまいます。
そこで、10秒経っても接続できなかった場合は、「LINBLEと接続できませんでした アドバタイズしているか確認して下さい」とメッセージを表示するように変更しました。
こうすることでユーザーにより詳しい「今の状態」を伝えることができ、ユーザーも次のアクションが取りやすくなります。
「ユーザーに今の状態を把握してもらう工夫」は、ユーザビリティのためだけではなく、「自分たちがサポートしやすくするための工夫」でもあります。
長年、無線モジュールを販売、サポートしていると通信トラブルに関するお問い合わせをいただくことがありますが、ユーザーからのお問い合わせというのは得てして「つながりません」「切れちゃいます」「通信できません」といったような漠然としたご報告であることが多いため、原因を探ろうにも、手がかりがほとんどない状況だったりします。そこでまずは「現状を把握する」ことになるのですが、その際のヒアリングでこのような「工夫」が活きることになります。
エラーコードなども同様です。メーカー側はユーザーに対して「今どんなメッセージが表示されていますか？」とシンプルな質問で聞けるようになりますし、ユーザー側としても一目瞭然で答えやすいです。
ユーザーにとっても、エラーの原因と解決のためのアクションがその場でわかれば、わざわざ問い合わせをして聞く手間が省けますし、メーカー側もサポートの負担を軽減することができます。「見えないものを可視化する工夫」は、まさに両者にとってメリットがある工夫です。
アプリの仕様書作成まとめ
以上、第3回「アプリの仕様書作成」について解説しました。
- 仕様書は「実現したいこと」の「実現方法」を決める。
- BLE通信周りの仕様を決める際はあらゆる「状態遷移」を想定する。「接続」「データ通信」だけではなく「切断」することも意識する。また、通信できなかったり、意図せず切断してしまった場合の処理も考えておく。
- 無線通信は「目に見えない」からこそ、ユーザーが「今の状態」を容易に把握できる工夫が必要。トラブルの理由と解決方法が可視化できれば、ユーザー自身にとっても、メーカー側にとってもメリットがある。
完成した仕様書はこちらです。
第4回目は「アプリの設計」についてお届けします。