開発チームやQAエンジニアは品質意識だけではなくビジネス的視点も持つべき

最近「開発チームも品質意識を持つべき」「開発チームに品質文化の醸成が必要」といった発言が多くみられるようになりました。 品質は確かに重要ですが、品質向上はビジネスを成功させるための手段であり目的ではありません。 本記事では、私の事業会社での経験を基に、ビジネス的視点を考慮しないで高品質なプロダクトを目指すことの弊害を取り上げたいと思います。 事業会社で勤務している方、事業会社への転職を検討している方などの参考になれば幸いです。

目次

話の前提

本記事では以下の前提で話を進めます。

  • 本記事における 品質
    • プロダクトのUXの良さ(バグの有無だけでなく、機能の有無やユーザビリティなども含む)
    • コードの品質といった内部品質はスコープ外
  • 品質意識
    • 品質を積極的に改善していこうとする意識
  • 本記事における 開発チーム または QAエンジニア
    • 自社のサービスや製品を提供する事業会社に所属
    • 開発者やQAエンジニアは開発する機能の仕様に関して意見を出すことができる
    • 所属会社が顧客に良いサービスを提供して報酬をいただくという社風である

顧客満足度向上に寄与しない品質にこだわったテスト

  • 悪いパターン
    • 可能な限り多くのバグを検出しようとする姿勢
  • 良いパターン
    • 顧客満足度に影響する障害が発生しないようにしようとする姿勢

顧客満足度に影響を与える品質要素を分類したものとして狩野モデルがあります。

顧客が必要としていない機能(無関心品質や逆品質に該当するもの)をリリースしても会社の利益に繋がらないことはよく言われていることだと思いますが*1、これはバグについても同じことが言えると思います。

バグには顧客満足度(魅力品質、一元的品質、当たり前品質)を低下させるバグとそうでないバグがあります。 例えば、プロダクトの想定ユーザーが殆ど行わないような操作*2をしてエラーページに遷移するバグがあっても、運用上そのエラーが発生してユーザーが困ることは殆どありません。

顧客満足度に影響しないバグを検出して修正しても会社の利益には結びつきません。 たまにバグの検出数だけを評価する方やプロダクトに対して細か過ぎるところまでテストする方がいますが、顧客満足度に影響しないバグの検出にリソースを割くよりも次のリリースのためにリソースを割く方が顧客満足度向上や会社の利益に貢献できます。

プロダクトや機能が仮説検証の段階でも高品質を目指したテスト

  • 悪いパターン
    • 常に高品質を目指したテストを実施する姿勢
  • 良いパターン
    • プロダクトや機能の仮説検証に影響する障害を防ぐ姿勢

リリースするプロダクトや機能(以下、プロダクト等)が仮説検証段階*3の場合、プロダクト等に対する顧客の反応が悪くてプロダクト等を削除する可能性も高いです。 削除される可能性が高いプロダクト等に対して大量にリソースを投入するのは、会社にとってリスクの高い行為となります。 したがって、仮説検証段階のプロダクト等の品質は仮説検証に必要な最低限の品質を担保し、それ以上の品質については仮説検証が終わった後でリソースをかけた方が良い場合があります。

例えば、顧客が社内の人など障害をある程度許容してもらえる状況であれば、障害発生時のワークアラウンドを顧客に周知してプロダクトや機能をリリースしてしまうなど。

会社の利益に寄与しない品質にこだわった仕様の提案

  • 悪いパターン
  • 良いパターン
    • 顧客満足度向上と会社の利益双方のことを考えた仕様の提案

顧客満足度向上が必ずしも会社の利益に貢献するとは限りません。 例えば、ECサイトで注文する際に注文内容や配送先を確認する画面はよくあると思います。 確認画面は注文時の誤った入力に気づく機会があるので、顧客の安心感が増します。 しかし、確認画面を挟むと注文者が注文手続きを思いとどまってサイトを離脱する可能性が高くなり、会社の利益を損ないます。

会社の利益は顧客満足度を向上させる新しい施策のための原資なので、会社が利益を上げることは顧客にとってもメリットがあります。 したがって、なるべく顧客と会社がWin-Winになるような仕様を考えるべきだと思います。

上記のECサイトの例だと 誤った入力のまま注文をするという不安を解消する方法 として以下のようなものが考えられます。

  • 一度利用した正しい入力内容を再利用できるようにすることで、入力ミスが発生しない仕組みにする
  • 注文した後に入力内容を簡単に修正できるようにすることで、入力ミスをしてもリカバリができるという安心感を持たせる

開発の費用対効果を考えないで高品質な機能を目指す

  • 悪いパターン
    • 新機能を開発する際に100点の仕様を目指して工数をかけすぎる
  • 良いパターン
    • 新機能を開発する際に費用対効果を考えて80点の仕様を目指すことも考慮する

会社のリソースは限られていますので、顧客満足度向上に対する費用対効果を考えて開発する内容を決めた方が、結果的に顧客満足度をより高くすることができます。 例えば、ある機能を顧客満足度100点の仕様で開発すると1人月かかり、80点の仕様で開発すると0.5人月かかるのであれば、80点の仕様で開発した方が1人月当たりの効果が1.6倍高くなります。

したがって、常にベストの仕様だけ考えるのではなく、費用対効果を考えたベターな仕様も同時に考えたほうが良いと思います。*4

例としては、以下のようなものが挙げられます。

  • 凝った問い合わせフォームを開発した場合とGoogle フォームを利用した場合で顧客満足度の差が大きくないのであれば、Google フォームを利用した方が良い場合がある
  • 入力フォームでバリデーションをリッチに開発しなくても、注意書きを記載するだけで入力ミスを防ぐという目的が達成できる可能性がある

リリース前の品質だけ確認する

  • 悪いパターン
    • リリース前の品質だけ確認してリリースした機能が顧客に与えた影響を確認しない
  • 良いパターン
    • リリースした機能が顧客や会社の利益に与えた影響を計測する

リリースする機能には、顧客の何らかのニーズを満たして会社の利益に結び付けたいという思惑があるはずです。 リリースする機能に対してリリース前にどんなテストを実施しても、リリースする機能が本当に顧客のニーズを満たすものか否かはリリースしてみないとわかりません。 顧客の言う通りの仕様で開発した場合も同様です。*5 したがって、リリースした機能が本当に顧客のニーズを満たしているか、会社の利益に結び付いたのかをなるべく計測すべきです。*6

例えば、以下のような数値などの計測が考えられます。

  • リリースした機能の利用頻度
  • リリースした機能を利用することによって改善したい数値
  • リリースした機能を利用した顧客の感想

まとめ

本記事では、ビジネス的視点を考慮しないで高品質なプロダクトを目指すことの弊害を取り上げました。 事業会社の開発チームに求められるのは、指示通りに開発を完遂することではなく、開発チームがもたらす事業的な成果です。 開発チームがもたらす事業的な成果を最大化するには、技術的なスキルだけでなくビジネス的な視点も欠かせません。 また、ビジネス的な貢献を考えるようになると、仕事に対する目的意識が変化して仕事がより楽しくなるかもしれません。 本記事の内容に興味を持った方は、是非普段の業務にビジネス的な視点も盛り込んでみてください。

*1:余談ですが、無駄な機能を作らせないことは生産性の高い品質保証活動の1つだと考えています。

*2:社内向け管理画面で絵文字を入力するなど

*3:誤解を恐れず平たく言うと、プロダクトや機能が顧客のニーズにマッチするか確定していない状態なので、実際にリリースして顧客の反応を確かめる段階。リーンスタートアップにおけるMVPなど

*4:特に仕様策定者が開発者バックグラウンドのない方だと開発時の負担感がわからないので、開発者が積極的に提案した方が良いと思います。

*5:顧客が自分のニーズに対して最適な解決策を知っているとは限りません

*6:計測にも工数がかかるので、計測対象は取捨選択すると良いと思います。例えば、ニーズが自明で仕様の選択肢が殆どないものは計測しないなど。