おはようございます。
freee develpers Advent Calendar 2017、4日目担当で UserSecurityチームの id:teitei_tk です。
趣味は平日23時~24時にやっているニュース番組、WBS(ワールドビジネスサテライト)の応援実況です。
現在はUserSecurityチームに所属していますが、以前はQAチームに所属しておりました。
その際に品質について調べることがあったので、自分はプロダクトの品質について書こうと思います。
そもそも品質とは？
Wikipediaにはこのように記述されています。
品質（ひんしつ、クオリティ = Quality）は、工場で生産された製品や、サービス業が提供するサービスの有する特性、もしくは属性をいう。
弊社はWebサービスを提供しているので、サービスの特性という事になると思います。
Webサービスの品質とは何があるのか？というのを考えてみるといろいろあるかと思います。
- バグが存在するのか。
- UXの体験はどうか。
- ページの表示は高速か。
- プログラムのソースコードは修正が容易か。
などなど、様々な「品質」という言葉があるかと思いますが、品質をモデル化した考え方として「狩野モデル」があります。
狩野モデルとは？
詳しくは下記を参考にしました。 https://www.juse.or.jp/departmental/point02/08.html
この狩野モデルでは、顧客の求める品質について「魅力品質」「一元的品質」「当たり前品質」の３つに分けています。
魅力品質
- 不充足でも仕方がない（不満には思わない）が、充足されれば満足
- 例: ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など
いわゆる新機能の追加に当たるのかなと思います。
弊社の例で表すと、
- OCRによる請求書の抽出機能
- アプリから勤怠打刻をすることが出来る
- freeeカードの作成することによる自動で同期や、優待特典の利用。
プロダクトを開発している方はこの魅力品質を向上させるために普段から開発を行っていると思います。
一元的品質
- 不充足だと不満、充足されると満足
- 例: バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など
プロダクトの機能改修、UIの改修、ページのレンダリング速度等が当てはまるかなと思います。
弊社の例で表すと、
- サービスを利用するために使用するView(画面)の表示の速さ。
- お客様からのフィードバックを受け、UIを改修。
- 人事労務freeeでの勤怠打刻・会計freeeでの取引登録機能のアップグレード。
当たり前品質
- 不充足だと不満、充足されて当たり前
- 例: 通話音声（音が良くて当たり前、聞き取りづらいと不満）
ここはバグが無い、サーバが落ちていない、セキュリティとして問題がない。というところでしょうか。
- バグが発生しておらず、人事労務freeeでの勤怠打刻・会計freeeでの取引が正常に行える。
- サーバがダウンしておらず、通常通りにサービスを利用することが出来る。
- お客様がサービスを扱っていて、入力した情報のセキュリティが担保されている。
というところでしょうか。
当たり前品質の具体的な向上
現在私はユーザセキュリティチームというチームに所属しており、ここでいうところの当たり前品質のセキュリティ面の向上を行っていっています。
行ったことはいくつかありますが、リスクベース認証をアップグレードしたことについて書こうと思います。
リスクベース認証についてはWikipediaに記載があるのでそちらを転載させてもらいます。
Risk-based authentication - Wikipedia
In Authentication, risk-based authentication is a non-static authentication system which takes into account the profile of the agent requesting access to the system to determine the risk profile associated with that transaction. The risk profile is then used to determine the complexity of the challenge. Higher risk profiles leads to stronger challenges, whereas a static username/password may suffice for lower-risk profiles. Risk-based implementation allows the application to challenge the user for additional credentials only when the risk level is appropriate.
実際に行ったこととしては、
- 認証前のログイン画面にプロファイラを仕込む
- 弊社サービスのログイン画面にJavaScriptのタグ(プロファイラ)を埋め込み、ブラウザ上の情報(JavaScriptが有効・画像の描画が有効)をサーバへ送信。
- ID・パスワード認証を行った後、1.の項目を参照し、登録したルールに基づきログインリクエストが不正かどうかの判断を行う。
- 例
- 1時間前にログインした国が日本であるが、今回ログインを試みたブラウザの通信元の国がイギリスである。(物理的に1時間での移動は不可能)
- 前回ログインしたブラウザではJavaScriptが有効だが、今回ログインを試みているブラウザではJavaScriptが無効で、画像の描画も無効になっている(プログラムによるログインの可能性大)
- Torなどを利用してのリクエスト
- 例
- 登録したルールに基づき、問題がなければそのままサービスのページへ、不正なリクエストの可能性があれば認証リクエストの中止を行います。
登録ルールに一つでも引っかかればログインリクエストが不正というわけではなく、
ここは弊社のルールにて加点方式にしており、一定の閾値を超えると、アカウントを一時的に凍結し、お客様のメールアドレスに凍結解除用のURLを送信します。
エンジニアの方であれば、2段階認証の設定・実装を行えば良いのでは？と思うかとしれませんが、
お客様に2段階認証の設定をして頂かないといけない点、リスクベース認証であればお客様が意識することなく(手を煩わせる事なく)品質を向上させる事が出来ると判断し、
今回はリスクベース認証のアップグレードを行いました。
というわけでプロダクト品質について書いてみました。
freeeでは品質を向上して、お客様に本質的な価値を届けるためにやっていく人を募集しております。
5日目は人事労務freeeのヌシの ryosukeYamazaki さんです！
