検証の重要性

 主要なシステム開発はだいたい終わり，あとはデザインの修正や優先度の低い機能の実装，そしてヘルプ機能の実現などを残すだけとなりました。

そこで，これから力を入れて行かないといけないのは検証です。機能は作ったけれど，動かない，あるいは動いても使い勝手が悪くてはそのうち利用されなくなるのは明らかです。今回の目玉はスマートスピーカーを利用した音声入力です。これは複雑極まりない多機能スマホアプリに比べたら，お年寄りでも簡単に操作できると考えたから導入したものです。でも，本当にそうでしょうか？

音声の方が操作しやすいというのは我々の思い込みかもしれません。思い込みかそうではないかは実際にテストをしてみなければわかりません。いきなりお年寄りにスマートスピーカーの相手を頼むのは無謀です。まずは，開発した我々がテストすべきです。毎日，血圧を測定して「OKグーグル，＊＊＊につないで」と呼びかけます。どのくらいの割合で応答するでしょうか？

応答したら「血圧」を記録することを告げ，上下の血圧を伝えます。「OKグーグル」と話しかけて，血圧の入力を終えるまでに何秒くらいかかるかを計測します。スマートスピーカーが音声認識に失敗したら，たった今入力した記録を取り消して，もう一度入力しなければいけません。これにはどのくらいの時間がかかるでしょうか。もしかしたら「かったるくてやってられない」と思うかもしれませんね。そうした場合は，どうやったらもっと簡単に入力できるようになるか工夫が必要かもしれません。

このようにやるべきことはいくらでもあります。特に高齢者が操作する部分は入念に検証する必要があります。学会で報告する際もそれがメインになるでしょう。どのくらいの精度で認識するのか，どのくらいの時間をかけて入力するのか，もし，認識間違いをしたらどのくらいの時間で修正できるのか，具体的な数値を示して報告しなければなりません。

これをやる上でチェックシートを作りましょう（Amazonに血圧手帳が出品されていたので４冊購入しました！）。毎日，スマートスピーカーに向かってテストし，その結果を記録するチェックシートです。認識の成否だけでなく入力に要した時間，認識に失敗した場合，修正に要した時間，そういったものを記録するためのシートです。