センシンロボティクス Advent Calendar の8日目の記事です。

はじめに

ベンチャー企業であるセンシンロボティクスのプロダクト開発は、日々新しいサービスが新しく生まれたり昔のプロダクトをリニューアルしたりと、いろいろなものを新しく作っていくことがまだまだ多いフェーズです。

私は中途で入社して１年と半年弱になりますがプロダクトマネージャーやプロダクトオーナーとしての役割として、またお客様の個別PJの中で開発プロセスに入ったりと様々な視点で開発プロセスを見てきました。そんな状況の中で日々感じてきたこと、デリバリーするサービスの品質を守るために心がけている事を整理もかねて、確率というキーワードで書いてみようと思います。

大前提/条件

原則は、いろいろなお客様と進めるPJのお約束を守るということ、利用してもらうユーザーに信頼をもって利用していただく、等という点をゴールとして品質面で問題ないことを確実に保証してデリバリーを行う事を目指します。
当然、スケジュールとコストというものはビジネスの中で必ず発生する条件になります。限られた時間と費用の中で目標を達成する必要があります。
センシンロボティクスが提供しているBtoBのサービスは利用方法やシーンを限定しやすい傾向にあります。
センシンロボティクスの主でもあるクラウドサービスとしてシステムを提供する事を前提として考えます。

こういった状況でどうやって品質を担保するかを考えます。

「確率」というキーワードで観点を挙げてみる

①利用シーンでどれくらい発生する？

利用者側が慣れた状態であれば一定の業務フローがあり、いつもきまって行う作業・オペレーションの順番があり、この利用導線にある部分は必ず担保したいところです。特に業務のメインフローの部分、毎回利用するようなところは必ずおさえておきたいところです。ここに何かのバグがあれば必ず発覚し問題になります。

いっぽうで、年に数回しか利用しないマスタ管理画面の中で、さらに複雑な発生条件下の組み合わせのシーンみたいなところは発生確率を考えるとぐっと低くなります。

この性質をもとにきちんとコストをかけてでも保障しないといけない部分と、簡単でいい部分という選択肢を持ち戦略を練ることができます。

②開発プロセスの中で何層ものフィルターをかける

プログラムが組みあがった後に潜在バグが仮に100個あったとした場合、エンジニアのローカルでの単体テストや動作確認で多くを拾える事が期待できますが、当然完全ではありません。
そのうち10個が残った場合（10%）、後続にもいくつかテストを行う事で残りの10個を検知して減らすようなことを通常考えますが、この10個を探すのはかなりの労力を要します。
QAやPDMによってのべつまくなしにテストするのでなく、エンジニア側のテストでは見つけづらいような性質バグをターゲットに、さまざまなテストを用意してカバーすることで、10個のうちクリティカルなバグはきちんと拾って解消することができるはずです。

エンジニア視点ではこの100個をいかに小さい数にできるかを考えたく、ここにもさまざまなアプローチを重ねてより減じていくことも重要です。（今回は割愛）

全体的な視点としては、それぞれのプロセスを観察することによって、どれくらいの量と内容のバグが潜在的に眠っていそうかのあたりをつける事ができチームﾔPJに応じた最適なソリューションを組み立てる事もできます。
最初から100%を目指すのではなく、90%の品質から95%の品質、目指すは99％、みたいな形で多層的に積み上げすものとして捉えていくと、柔軟な戦略が取れるようになると考えています。

③パターンを切り落とす

母数自体が少なくなれば潜在バグの発生確率は下がります。なるべく無駄な作業は発生させたくないです。シンプルであればあるほど全体量が減ります。組み合わせでのパターンがあるような場合や、非常に複雑なレアケースを考える場合にはそのフローをなくすことを選択できる場合もあります。

仕様設計段階で利用シーン的に意味があまりないパターンは作れないような仕組みにしてしまう。
複雑なシーンへの対応は諦めて、別の形に誘導する。

④発生確率と長期的な期間で考える

クラウドサービスの場合、受注開発のようにシステムを提供して終わりではなく価値向上のために機能開発を長く続けていくことになるので、長期間にわたって品質をより高めていくような戦略も選択肢の一つです。
状況が著しくない場合には、このようなリカバリープランを発動しないといけない場合もあります。

発生確率の低いものは後回しにするという選択が取れますが、見誤ると問題を簡単に発生させてしまう事になるので、利用シーンや状況をきちんと理解して適切に見極めて優先順位をつける事が必要です。本質的ではないのと無駄にコストもかかるので、取らないで済むといい選択肢ではあります。

③で落とした部分は長期的なマイルストーンの中で優先順位をつけて対応を予定していくような形も。

⑤バグがない事の証明はむずかしい。

誰もが身に染みている事ですが、バグがない事の証明は難しいです。100%完璧であることの証明は難しいので、世の中にある規格に準じたり独自に用意したりしてそれに準ずる事でより近づけたり、一般的なテスト設計にきちんと則ったり、プロセスの品質を見たり、「品質保証」としてとらえて、問題なく利用してもらえることを担保します。
どうしても拾えないものが発覚してしまった場合には、すぐに対応できる体制がある、問合せに適切に対応する、などサービスまで運用まで含めてカバーするととらえる事もできます。

⑥みんなで見て触ろう

そうしても一人だけで考えた場合に100%網羅できているわけではなく気づけない事がある、品質状態が低い状態になっていると考える事がスタートです。小さいチームは難しいですが、QAメンバーやデザイナーに少しでも参画してもらって触ってもらったり、できるだけ多くの人に触ってもらうといろいろな視点や気づきがありカバー率を増やす事ができます。コードベースで様々な人にレビューしてもらうのも同じ観点。自分の仕事に閉じずに、最終的な成果物の視点でよりたくさんの人が自分ごととして触れる機会があれば、その重ね合わせで担保率があがっていきます。

私も、現場から遠くなってしまっても可能な限り自分で使って触っているように心がけています。

とはいえ

小手先のことで本来達成すべき基準から外れてはいけません。
他にもたくさんさまざまな観点があります。教科書もたくさんあります。

時にはスケジュールを調整する、デリバリーを劣後して品質を保つことも必要。どうやっても対応できない場合や、その時の状況や長期的視点でも許容できる範囲であればこの条件を動かす事も十分な選択肢になります。バランスをうまくとるのは腕の見せ所。
確率的に低くても、事象が起きたらクリティカルなものは絶対に起こしてはいけません。当然インパクトや影響を考える必要があります。ドローンなどを扱う性質上センシンロボティクスとしては最重要事項です。
100%大丈夫です、と宣言できる状態が常に達成したい基準です。
リグレッションテストは問題ないことを確認するテストであり、問題をキャッチするためには利用したくありません。そこまでに抑えられるような設計をしたいですね。

まとめ

以上、観点として書きましたが、品質に問題を抱えていて、どうしようと困った時などに何か小さなヒントにでもなればと思います。ちょっとした引き出しのネタにもなれば。
私も今回記事にまとめる事で次のアクションに一つ繋げられそうです。
ユーザーに価値を与えられるように引き続き邁進していこうと思います。