【ITニュース解説】Never installable

このニュース記事は、医療現場の課題解決のために開発された、ある試作アプリの事例を通じて、システム開発における重要な教訓を教えてくれる。これは、英国の国民保健サービス（NHS）の栄養士チームが直面していた業務効率の問題を解決するための概念実証（PoC）プロジェクトの話だ。栄養士たちは、患者から送られてくる食事の写真を元に、手作業で製品を特定し、既存の栄養分析ソフトウェア「Nutritics」に入力していた。Nutriticsには患者向けのアプリ「Libro」があったが、この地域ではまだ利用できず、導入までには時間がかかる見込みだった。そこで、Libroが使えるようになるまでの「一時的な回避策」として、手入力作業をできるだけ速く、間違いなく行うための小さなアプリが開発された。このアプリのもう一つの目的は、Libroの導入が本当に業務改善につながるのか、その証拠を集めることでもあった。つまり、このアプリは完成品を目指したものではなく、あくまで限られた期間で特定の目的を達成するためのツールだったのだ。

開発にあたって、まず重要な設計判断が下された。それは「栄養情報を直接扱わない」という方針だ。当初、バーコードを読み取って自動的に栄養情報を表示する既存の消費者向けアプリ（Cronometerなど）の利用も検討されたが、これらのアプリのデータは不正確であったり、有料機能になっていたりして、信頼性が低いことが判明した。唯一、無料のデータベース「Open Food Facts」は製品名を特定できたが、栄養情報までは提供しなかった。バーコードの数字自体は正確に読み取れるが、それが正しい栄養情報に結びつくかは、信頼性の低いデータソースに依存してしまう。そこで、開発チームは思い切って、このアプリが栄養数値（カロリーなど）を一切主張しないと決めた。バーコードを読み取るだけに徹し、栄養情報は、約160万件もの認証済み食品データを持つNutriticsに任せることで、情報の正確性を確保したのだ。もしアプリが誤った栄養情報を表示すれば、後で訂正する手間が発生するが、最初から「確実な情報だけを提示する」ことで、このリスクを回避したのである。バーコードの検証においても同様で、数字の誤読を防ぐためのチェックデジットは有効だが、それが製品の正確性を完全に保証するわけではないという限界も認識し、「自己検証可能」という過剰な表現は避けた。

次に、このアプリの設計を大きく左右したのは、栄養士がNutriticsをどのように使っているかを観察した結果だった。一般的な食生活では、1週間で120回食事をしても、実際に食べる食品の種類は35種類程度に絞られることが多い。つまり、毎日同じような食品を繰り返し食べる傾向があるのだ。既存のNutriticsでは、同じ食品であっても食事のたびに検索して入力していたため、多くの手間がかかっていた。この洞察に基づき、アプリのデータモデルは「食品ライブラリ」と「日次ログ」の二つに分けられた。食品ライブラリには、各食品が固有のショートコードとともに一度だけ登録され、日次ログでは、そのショートコードと食べた量を記録するだけにした。これにより、栄養士は新しい食品を最初に登録すれば、それ以降は繰り返し同じ食品を検索することなく、コードを入力するだけで済むようになり、入力作業が劇的に効率化された。これは、利用者側の視点だけでなく、既存のシステムがどのように機能しているかを深く理解することから生まれた、小さな工夫だが大きな効果をもたらす改善点だった。

しかし、これらの設計上の工夫も、実際のスマートフォンにアプリをデプロイすると、多くの予期せぬ問題に直面した。このアプリは、Web技術を使ってネイティブアプリのように動作する「プログレッシブ・ウェブ・アプリ（PWA）」として、意図的にビルドツールを使わずに開発された。一時的な解決策として開発されたため、複雑な開発環境の維持は避けたかったからだ。特にエクスポート機能は多くのバグを抱えていた。例えば、AndroidのDuckDuckGoブラウザで「ダウンロード」をタップしても何も起きないという問題があった。これは、Webサイトのコンテンツを高速に配信する「CDN」上のスクリプトが、オフラインでの動作を可能にする「サービスワーカー」によってキャッシュされていなかったため、ダウンロード処理が裏でサイレントに失敗していたのが原因だった。また、ダウンロードされたファイルが本来のExcel形式ではなく、謎の「.bin」ファイルとして保存されてしまう問題も発生した。これは、ファイルの種類を識別する「MIMEタイプ」がブラウザに正しく設定されていなかったためだ。さらに厄介だったのは、アプリは「ダウンロード済み」と表示するのに、実際にはファイルが存在しないというバグだった。これは、ブラウザ内部のデータベース「IndexedDB」への処理に時間がかかりすぎたため、ダウンロードをトリガーするタップの権限が電話側で静かに失効してしまっていたのだ。これらのバグは、机上でのテストやPCでの検証では見つけることができず、実際のスマートフォン環境で初めて表面化したものばかりだった。

これらのバグの中でも、最も時間を費やしたのは、なんとアプリが「インストール可能」ではなかったという問題だった。PWAとして開発されたアプリは、通常、ホーム画面に追加するだけでなく、ネイティブアプリのように「インストール」することもできる。しかし、このアプリでは「ホーム画面に追加」はできたものの、それは単なるブックマークショートカットであり、オフライン動作もできない、本当の意味でのインストール済みアプリにはならなかった。この原因は、PWAの設定情報が記述された「マニフェストファイル」で、アプリのアイコンをフルサイズで宣言していたにもかかわらず、実際に用意されていたアイコンファイルが、たった1ピクセル×1ピクセルの、わずか68バイトの「ダミーファイル」だったことだった。Google Chromeなどのブラウザは、マニフェストで宣言されたアイコンが実際にそのサイズで存在するかを確認するが、もし存在しなくても、コンソールに警告を表示したり、エラーを発生させたりすることはなかった。ただ静かに「アプリをインストール」するオプションが表示されなくなるだけだったのだ。開発チームは当初、ブラウザのPWAサポートが不完全なのではないか、あるいはホスティングサービスの違いが原因ではないかと疑い、多くの時間を費やして調査した。しかし、これらは全て誤った仮説だった。以前の開発環境では、サービスワーカーのキャッシュが何ヶ月も稼働しており、それがこのアイコンのバグと他の二つのバグを静かに隠蔽していたのだ。新しい環境でキャッシュがクリアされ、すべてのコードパスが実際に実行されたことで、ようやくこれらのバグが一度に表面化した。たった68バイトの小さなファイルが、多くの時間を無駄にする大きな原因となることは、開発における思わぬ落とし穴を教えてくれる。

開発中のデバッグでは、誤った仮説を立ててしまうこともある。例えば、バーコードの写真を横向きで撮る習慣があったため、縦向きで撮ると読み取りに失敗しやすいように見えたことがあった。開発者は、スキャナーが横方向の線を読み取るため、回転したバーコードが認識しにくいのではないかと考えた。しかし、直接テストしてみると、明るい場所であれば、縦向きのバーコードでも横向きと同じくらい問題なく読み取れることがわかった。結局、横向きで撮る習慣と良い照明条件が偶然一致していただけで、バーコードの向き自体は問題ではなかったのだ。このように、私たちは思い込みで原因を特定しようとしがちだが、常に具体的なテストを通じて仮説を検証することの重要性が示されている。

このアプリは、最終的に完成品となることは意図されていない。Libroが地域で利用可能になれば、その役目を終え、維持されることなく引退する予定だ。もし、この試作アプリを使った手入力作業が、工夫を凝らしたにもかかわらず本当に負担が大きいと判明すれば、それはLibroを導入すべきだという強力な証拠となるだろう。いずれにせよ、このプロジェクトは、確実なことだけを主張するシンプルなバーコードリーダーと、複雑に見えた問題が、実は単純な原因にたどり着くまでの多くのデバッグの記録を残した。これは、システム開発の現実と、問題解決のプロセスがいかに奥深く、多くの学びに満ちているかを示す好事例と言えるだろう。