手法の検証
外部Webサービスと連携するサンプルサービスを設計し、外部Webサービスの仕様変更やバグが発生した場合に今回の手法が機能しうるか検証しました。現実のサービスの設計に近づけるため、サンプルサービスのコンセプトを「自分が今食べたいものが食べられる飲食店を教えてくれるサービス」とし、ユーザーのよく使用するチャットアプリから気軽に聞けるレストラン検索チャットサービスとしました。
レストラン検索チャットサービスの仕様
レストラン検索チャットサービスの仕様を図4に示します。
チャットボットサービスは以下の外部Webサービスを使用しています。
- 飲食店検索システムのUI：チャットサービス
- 飲食店管理器：レストラン検索サービス
- 地図管理器：地図表示サービス
チャットボットサービスの代表的なユースケースとしては、以下のような利用法を想定しました。
- 利用者は現在位置をチャットボットに通知する。
- チャットボットが食べたいジャンルを聞く。
- 利用者はジャンルをチャットボットに通知する。
- チャットボットが現在位置に近い順に飲食店の情報を最大5件回答する。
- 表示された飲食店の情報に含まれるウェブサイトURLや地図URLを選択することで、ウェブサイトや飲食店までの経路を確認できる。
表1と表2は、外部Webサービスとして利用するサービスの仕様と、それらのサービスで利用するAPIの仕様です。仕様は実在するサービスを元に定義しましたが、主要な動作だけに絞っています。
検証シナリオ
提案手法を検証するため、表3の5つの検証シナリオを定義しました。定義したシナリオを設計したサービス上でシミュレートし、仕様の変化を検出できるかどうか検証しました。
検証結果
検証結果は表4に示します。シナリオ1、2、3は検出可能でしたが、シナリオ4、5については検出できませんでした。
検証シナリオ1や2や3のような正解が明確な問題は検出が可能でした。しかし、検証シナリオ4や5のような正解が人間にしかわからない（画像など自動判定が困難）場合は検出できませんでした。
仕様とは何が正しいかを定めることであり、正しさを自分たちで決めることのできない事象は検出できないという結論になるかもしれません。しかしながら、シナリオ4や5のようなケースは正しいかどうかを判定するのではなく、変化したかどうかを判定するようにすれば、変化したことを検出できます。どんな変化があってどのように対処するかは人が見て判断すれば、当初のAPIの変化を検出し、対処までの時間を短縮する目的へは十分に寄与できると考えます。
まとめ
外部Webサービスを利用するWebサービスの運用時に、外部Webサービスの問題検出を早期に行い、損失を最小化する手法と検証結果を紹介しました。いくつかのシナリオを想定して有効性を確認し、正解が明確な場合には検出ができるものの、検出できない場合もありました。今後は検出できなかった正解が利用者にしかわからないような問題の検出方法や、問題を検出した時に迅速に対応する方法について検討していきたいと思います。
トップエスイーについて
「トップエスイー」は、国立情報学研究所で実施している、社会人エンジニア向けのソフトウェア工学に関する教育プログラムです。トップエスイーでは講義や制作課題を通して、最先端の研究成果や現場で得られた知見が蓄積されてきました。その「アウトカム」、つまり成果やそこに至る過程を紹介し、現場のエンジニアの方々に活用いただける記事を連載しています。2017年度より、講義を中心に受講し後半にまとめとして「ソフトウェア開発実践演習」を行う「トップエスイーコース」と、指導教員と1対1で受講生が抱える現場の問題を解決する「アドバンストップエスイーコース」の2コースとなりました。今回の成果は「ソフトウェア開発実践演習」での取り組みです。この演習科目では講師が提示した課題に取り組むだけでなく、受講生が課題を設定して進めることも可能で、外部APIの仕様変更検出についての取り組みは筆者が自ら考えて実践した課題でした。
