SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規SaaSの企画検討からリリースまで! freeeの事例に学ぶプロダクト開発

プロダクトの品質はテストだけでは測れない――新規プロダクト開発における品質管理の考え方

新規SaaSの企画検討からリリースまで! freeeの事例に学ぶプロダクト開発 第5回

プロダクト開発における品質とは

 「QA=テスト」と考えられがちですが、テストはあくまでもQA業務の一部ととらえ、サービス全体の品質を担保することが最も大事です。「木を見て、森を見ず」という言葉がありますが、開発フェーズでは、全ての機能が要件通りに動作することばかりにとらわれ、「顧客満足度の高いサービス」になっているのかという、本来目指すべき部分を見失ってしまうことが往々にしてあります。

 筆者は、品質の高いサービス=顧客満足度の高いサービスと位置付けており、サービス全体が顧客の期待通りに使えることが最も大切だと考えています。品質には、顧客の期待通りの使いやすさやアクセシビリティ、パフォーマンスやセキュリティといった非機能要件、困った時のヘルプやサポート体制なども含まれると考えます。

木だけでなく、森を見る

木だけでなく、森を見る

 どんなに素晴らしい機能があっても、画面を表示するのに何秒も待たされるようなサービスは使ってもらえませんし、情報が漏洩してしまうようなサービスだと、顧客からの信頼を得られるはずはありません。こういった部分もきちんと品質を担保する必要が出てきます。ところが、それらを全てQAだけで確認するのは、スキル的にも工数的にも難しい場合があります。

理想の品質を実現するために

 freeeの価値基準に「理想ドリブンで考える」というのものがあります。まず、顧客にとって必要なものはなにかを理想ありきで考えることが大事で、どうやってやるかは後から考えます。

 先ほど説明した、本来追求すべきサービス全体の品質を担保するためには、性能テストや脆弱性テストが必要となります。では、どうやってやるのか。「この部分はQAで実施して、この部分は開発エンジニアで実施する」「この部分については、SREに協力してもらうとスムーズにできるよね」「脆弱性テストは社内でやるのは難しいので、外部のベンダーにお願いしよう」といった感じで、理想を実現するための手段を1つずつ見つけていきます。

 また、サービスはリリースしたら終わりではありません。リリース後の運用についても考える必要があり、それも品質の一部だと考えます。サポート業務のことをわかっているメンバーに事前に協力してもらい、「顧客はこう思う」「この表現は顧客に誤解を与える可能性がある」といった、顧客目線での評価を開発サイクルの中に取り入れたり、わかりにくい点を予めヘルプに記載したりといった、顧客からの問い合わせを減らす取り組みも行っています。

だれでも使えるということ

 品質を考える時によく使われるモデルとして「狩野モデル」といものがあり、このモデルでは、主に「魅力的品質」「一元的品質」「当たり前品質」の3つによって顧客満足度に与える影響を定義しています。

 freeeには「アイデアやパッションやスキルがあればだれでも、 ビジネスを強くスマートに育てられるプラットフォーム」というビジョンから、狩野モデルにおける「当たり前品質」を全てのユーザーに提供したいという思いがあります。

 プロジェクト管理freeeも全てのユーザーが当たり前に使えることを大事な品質として、アクセシビリティの評価を行っています。当初は、実装した機能に対して、随時、アクセシビリティの評価を行っていたのですが、頻繁にUIの追加や修正が行われるため効率が悪く、ある程度できたタイミングでまとめて評価する方向に変えました。プロジェクト管理freeeでは、機能実装を行わず、リファクタリングや改善を中心に行う改善スプリント(通称551スプリント)を月に1回実施しており、そのタイミングで全体のアクセシビリティ評価を行っています。

点字ディスプレイを利用している様子
アクセシビリティ担保のため、点字ディスプレイも用意

リリースの分かれ目はどこか

 全ての開発が終了すると、遂にリリースの時を迎えます。プロジェクト管理freeeでは、最後にリリースの可否を判断するための「リリース判定会議」を行いました。

 リリース判定では、大事なことが2つあります。1つはプロジェクト管理freeeに関わる全てのステークホルダーが参加すること。もう1つは予めリリースの条件を決めておき、全員がその内容に納得しておくことです。開発チーム主導で行った場合、どうしても開発寄りになってしまいがちなので、全てのステークホルダーが参加したうえで、第三者の視点をいれた判断が重要になります。

 プロジェクト管理freeeのリリース日はコロナ禍における緊急事態宣言の発令後の4月20日。そのため全員がリモートという状況でしたが、元々、このプロジェクトは東京と大阪との連合チームで、当初からリモートで進めてきたので、この点は何の問題もなく、無事リリースを迎えることができました。

 下記は、リリース判定会議でリリースOKが決まった瞬間の写真です。みんないい顔しています。1人を除いて。実は、1点だけ懸念点が残った状態での条件付きリリースとなってしまい、それが気になってしょうがないPMの宮田だけは浮かない顔をしています。その後、すぐに懸念点も払拭されて、PM宮田の顔にもようやく笑みがこぼれました。

リリースOKとなった瞬間のみんなの表情

リリースOKとなった瞬間のみんなの表情

 構想から1年、遂にプロジェクト管理freeeのリリースまでこぎつけました。ようやく産声をあげたこのサービスをいかにして、顧客へ届けていくのか、まだスタート地点に立ったばかりです。次回は、この新しいサービスを、どのようにして顧客へ届けていくのか、プロダクトマーケティングマネージャー(PMM)の伊関に詳しく紹介してもらいます。ご期待ください。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
新規SaaSの企画検討からリリースまで! freeeの事例に学ぶプロダクト開発連載記事一覧

もっと読む

この記事の著者

上村功一(freee株式会社)(ウエムラコウイチ)

 freee株式会社 プロダクト基盤 QAエンジニア 約7年間の開発経験の後、Microsoft、Yahoo! JAPAN、株式会社ACCESS及びエムスリーにて、テスティング/QA業務を担当し、ハードウェアから、Web、メディカル領域まで、さまざまなサービスの品質保証を経験。株式会社ACCESSで...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/13742 2021/03/26 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー