Webサービスの歩き方

"京王線 16:27 各停調布 32768両編成" — 京王線 16:27 各停調布 32768両編成

こんにちは。freeeでQAのマネージャをやってるuemuです。freee人事労務とグローバル開発のQAをメインで担当しています。これは、freee QA Advent Calendar2023 23日目の記事になります。

はじめに

みなさん、境界値分析はやってますか？

普段、QA業務を行っている人だったら、やったことがない人はいないでしょう。「そんなの知ってるよ」「いつもやってるよ」という人がほとんどだと思いますが、今回は普段より少し広い視野で境界値分析をやってみたいと思います。

ちょっと話が脱線しますが、私はブラタモリという番組をよく観ます。タモリさんが“ブラブラ”歩きながら知られざる街の歴史や人々の暮らしに迫る番組ですが、その中でタモリさんがよくこんなことを言っています。

　　「へりがおもしろいんですよ、へりが。」

　　「事件はへりで起きてる」

　　「歴史はへりにあり」

www.nhk.jp https://www.nhk.or.jp/faq-corner/4housoubangumi/05/04-05-11.html

「へり」とは、ふちとか端っこの意味で、いわゆる境界の部分ですね。こうした場所では、地震や噴火などの自然災害の影響を受けやすかったり、歴史的にも重要な出来事が発生しやすい傾向があり、地域の歴史や文化形成に深い影響を与える転換地になったりします。興味深いことに、Webサービスにも同じようにさまざまな「へり」が存在します。今回は、ブラタモリになぞって、ぶらぶら歩きながら、Webサービスのへりを探していきたいと思います。

Webサービスの開発では、普段気づきにくいへりが多数存在します。そういったへりを認識した上できちんとリスク分析しないと、思いもよらない不具合や障害に遭遇したりします。Webサービスのへりには、いくつかのパターンがありますので、それらを見ていきたいと思います。

入出力のへり

まずは、入出力のへりです。入出力値の境界に欠陥が潜んでいる可能性が高いため、仕様条件の境界となる値とその隣の値に対してテストすることで、膨大なテストパターンや組み合わせを減らすためのアプローチになります。これについては、今さら説明する必要もないと思いますが、きちんと分析してテストをする必要があります。

7文字以下のパスワードが登録できたが、ログインしようとすると8文字以上を要求されてログインできない
入力可能な文字数以上に入力できてしまい、画面のレイアウトが崩れた
大きなファイルをアップロードしたら、レスポンスが返ってこなくなった
入力範囲外の取引数で株の購入ができた
ファイルをアップロードしたら一部が文字化けした（機種依存文字など、文字コードのへりが原因）
マイナスの値を入力したら表示がおかしくなった

アプリケーションのへり

最近のWebサービスは、すべてをイチから作ることはなく、クラウドサービス、フレームワーク、ライブラリ、データベースといった技術を活用して開発することがほとんどだと思います。短期間で高い品質のサービスを作る上で、とても優れたアプローチにはなるのですが、ここには、「自分たちで開発している部分」と「外部で開発された部分」との間にへりが存在します。

Rubyのバージョンをアップグレードしたら、一部の機能が動かなくなった
PDF表示用のライブラリを更新したら、特定のブラウザで正しく表示されなくなった
データベースを最新バージョンにしたらパフォーマンスが落ちて、サービスの利用に支障がでてきた
Webサーバーの脆弱性対応パッチをあてたら、今まで使っていたAPIが動かなくなった
今まではチェックが緩くても動作していたが、新しいバージョンでチェックが厳しくなって動かなくなった
AWSの設定を変更したら、サービスに繋がらなくなった

Webサービスを構成しているコンポーネントを理解して、それらがアップデートされる場合や設定を変更する場合に、本当に問題がないかを確認する必要があります。

マイクロサービスのへり

最近のWebサービス開発におけるアーキテクチャは、モノリシックからマイクロサービスに変わってきています。それぞれ、メリット/デメリットはあると思いますが、一つ言えるのは、マイクロサービスは、モノリシックに比べて、多くのへりが存在するということです。

サービス側の仕様が変更になり、以前と違う情報が返ってくる
特定のサービスがボトルネックになって、全体のパフォーマンスが低下
サービスとサービスのコネクションが切れている
特定のサービスが応答しない、エラーが返ってくる
特定のサービスだけ、テスト環境につながっている
参照先のAPIが無くなった
メールを配信するサービスがダウンして、通知メールが送信されない

マイクロサービスはメリットも多いですが、上記のように意図しないことが起きがちです。また、テストも難しいので、設計の段階で、以下のような事を考慮した上で、しっかりとテストを実施しておくことが大事になります。自動テストの仕組みを用意しておくことも有効です。

応答時間やリトライ回数をあらかじめ決めておく
常に使える状態になっているか、外形監視の仕組みをいれておく
サービスとの疎通が確認できるシナリオを自動テストとして構築しておく
何か問題があった時にすぐ検知できるようにアラートを設定しておく
アプリケーションを実装する側もマイクロサービスがダウンしていた場合を想定した、FailOverのテストを実施しておく

連携サービスのへり

マイクロサービスの概念には似ていますが、もう少し広い視点で見れば、連携サービスにも課題があります。社内で開発されたマイクロサービスなら、ある程度は仕様や状況を理解できますが、外部サービスとの連携の場合、それがまったく見えない「ブラックボックス」になることがあります。freeeでも多くの外部サービス連携が行われていますが、これに伴って不具合や障害が発生することがあります。

特定の時間帯に、連携しているサービスが利用できない
連携サービスの仕様変更により、エラーが発生するようになった
銀行側のメンテナンスにより同期処理が行えなくなった
連携サービスのRate Limitにひっかかて、連携を切られた
連携していたサービスの運用が終了して、利用できなくなった

連携サービスのへりもマイクロサービスのへりと同様に、問題が発生した時にいかに早く気づけるかが重要なポイントとなります。

組織のへり

次は、アプリケーション開発からちょっと離れて、組織や人に着目してみます。一般的に何かのサービスを顧客に提供しようと考えた場合、営業、マーケティング、開発、QA、サポートといった多くの組織が関与することになると思います。これらのチームは、関係するチームや人とコミュニケーションをとりながら進めていくことになると思いますが、ここに組織のへりが存在します。コミュニケーションや情報共有がうまくできていないと、想定しなかった問題が発生する可能性があります。

別チームが開発している機能と連携する部分に仕様の齟齬があり、意図しない挙動になる
Webの変更を行なったが、モバイルチームへの共有が漏れていて、モバイルアプリでのアクセスができなくなった
インフラチームが何の連絡もなく、サーバーの設定を変更したために、サービスに支障がでた
ユーザにアナウンスした期日までに、開発が終わらない
要件定義が十分に行われておらず、売りにくい・売れないサービスができあがった
新機能がリリースされたが、何の共有がなく、サポートの対応に困った
開発チームの想定と違う使い方をされて、サポートに大量にクレームがきた

各チームとのコミュニケーションや情報共有を強化すると共に、チームで行っていることを透明化することも大事になります。Agile開発を行っているのであれば、スプリントデモを行う際に、ステークホルダーを集めて、全員でレビューする機会を作るのも効果的です。

利用者のへり

freeeの利用者には、ITや会計の専門家もいれば、コンピュータをほとんど使ったことない方、外国籍の方、視覚障害者の方といった、多種多様な人がいます。中には悪意を持って使おうとする人がいるかもしれません。利用する人によっては、使えなかったり、使いづらい、といったことがあるかもしれません。ここにもへりが存在します。全ての利用者が、同じように使えるようにすることは難しいかもしれませんが、まったく使えないという状況だけは避けるべきです。

専門家にとっては、使いたい機能が不足している
専門用語ばかりで、何をしたらいいのかわからない初心者
文字が小さくて読めない年配者
スクリーンリーダーで読み上げてくれない
個人情報をぬきとろうとする悪意あるユーザ

QAはよく顧客目線でテストすることが大事だと言われますが、顧客にもいろんなタイプの人がいます。利用者別にペルソナを設定して、ユーザシナリオテストを実施することをオススメします。

時間のへり

最後は、時間のへりです。時間は常に流れていますので、気づくにくいし、忘れがちです。ただ、これを怠ると、サービスが使えなくなる、といった最悪な自体につながる恐れもあるので、注意が必要です。

証明書の期限が切れて、サイトへアクセスできなくなった
ドメイン名の更新を忘れて、サービスへのアクセスができなくなった
クラウドサービスの決済をしていたカードの期限切れによって、自社サービスが使えなくなった
事前に連絡があったサービス停止の案内を忘れていて、連携処理が動かなくなった
確定申告の最終日にアクセスが集中してシステムがダウンした
利用しているライブラリのサポートが切れて、利用ができなくなった
サーバーのタイムゾーンがUTCになっていて、時間がずれる。夜中に利用すると日付がずれる

期限切れに関しては、何かしらの案内などがあると思いますので、案内を受け取った時点ですぐに対応するか、対応できないのであれば、アラートを設定するなどの対応を行うべきです。

小さなスタートアップ企業の場合、社長のクレジットカードで決済して、誰も期限切れに気づかない、といったこともありえるので、コーポレートカードの利用をオススメします。

www.freee.co.jp

終わりに

ぶらぶらとWebサービスを歩き回ってきましたが、いかがだったでしょうか？

Webサービスにはいろんなへり、境界が存在することが理解いただけたでしょうか。へりではさまざまな出来事が起きていますが、大切なのは、まずへりに気づくことです。へりが見つかれば、そこで発生しそうなリスクに対して対策を考えることができますが、そもそも気付けなければ、それは潜在的なリスクになってしまいます。

では、へりに気づくにはどうしたらよいでしょうか？

それは、Webサービスはどのように作られているのか、どんなユーザが使っているのか、誰が作っているのか、といったWebサービスについての理解を深めることが重要だと思います。仕様書だけをみて、テスト設計やリスク分析だけしてても、へりは見つかりません。今回は、とりあげなかったへりもまだまだあると思います（「データサイズ」のへりとか「性能のへり」とか。。。また、別の機会にまとめてみたいと思います）。

最後に、タモリさんの言葉を再掲しておきます。。。境界値分析、楽しんでください！