品質という言葉について考える(続き)

前回書いた 品質という言葉について考える  のつづき

なんとなく品質についてどうにかしなきゃと考えている人から、良く聞くセリフを並べてみる。

「品質に不安がある」
「品質を安定させたい」
「品質をもっと良くしたい」
「品質は特に問題ない」

これを言っている人の立場である程度は想像出来る。
開発のマネージャー的なポジションの人が言っている場合は、プロダクト品質や、リリース品質とか。
POの場合、もっと意味が広いことがあって、サービス品質だったりする。例えば、クレームが多いとか。
品質は特に問題ないと認識している場合、実はかなりレガシーなシステムであったり、開発や運用側が頑張ってなんとかしていることだってある。
QAマネージャーとかだと、QA開始時の初期品質や、障害を未然に防げなかったことに対するQAスコープの話だったりする(ソフトウェア品質とかリリース品質的なやつ)

問題なのは品質なのではなく、現状にある課題であるはず。
その課題がもたらす結果として、「品質なんとかしたいわー」と表現しているだけかもしれない。

1点だけ補足。
障害が起きている時の話では無い。
障害が起きている時の頭の使い方や、アクションの優先順位は少し違う。
その話はまた別の機会に。


何が言いたいかというと、 品質 というキーワードだけで会話を進めることは、危険すぎるということ。
品質という言葉に囚われすぎて、事業自体にコミット出来なくなるのは避けたいということ。

結局は、品質とコストとスピードのバランスが重要なのだ。
※QCDというのが有名だが、僕はデイバリーよりバランスを重視しているので。。。QCBか。
そのバランスというのは、業界や、事業のフェーズ、チームによっても異なる。


じゃあ何からするか?

品質という言葉を使わずに、現状の問題や課題を言葉にすること
僕はそこから始めている。

そもそもシステムで解決すべき問題や課題なのか?
開発サイドだけで解決出来るような問題や課題なのか?
解像度高く物事を捉えている人(部署)はどこなのか?

できれば、実際に起きている問題や課題などを、実際に起こった事象ベースで考えられるとよりよい。
「なんとなくこの辺に問題があると思う。。。しらんけど。。。」
っという状態では、多分解決しない。

必要なら、部署や、会社間すら飛び越えて、情報を掴みに行く必要だってある。
一見、めっちゃ遠回りかもしれないが、実は一番大事(だと信じて生きている)

僕は
急がば回れ
とか
後の先を取る
という言葉がスキだ。




僕自身の過去の経験の中であった本質的な課題たちを並べてみる。

  • 企画、要件の詰めが甘いがゆえに、実装後に改修することが多くなり、開発工数が跳ね上がっていく(結果、複雑になり、更にリリースが遅れる)

  • 最初から機能詰め込み過ぎて、複雑になり、全体を把握出来ず、結果的に仕様不明確箇所が増え、いわゆるポロリしまくる

  • 何を実現できていればよいのかのリリースの基準が作れていないため、リリース判断がふわっとした状態でリリースしてしまう

  • ユースケースやユーザーシナリオをイメージ出来ておらず、考慮漏れによる障害が頻発する

  • 運営サイドのオペレーションを考慮せず、リリース後のサービス運営側でヒューマンエラーが発生しやすくなる

  • 改修コスト(実装工数)を軸に考えた結果、影響が出る箇所へのケアが足りていなかったことで障害が発生する

などなど。

当たり前だが、上記で書いた課題それぞれへのアクションは異なる。
それを見つけ出し、解決に向けて行動に起こして、改善していくのが僕の仕事。
正直、部署間の垣根がほぼ無いような組織だと、めちゃめちゃハマる。
シンプルに意思決定が早かったりするので、トライ・アンド・エラーもしやすい。
結果、動きやすい。


更に僕の手の内を晒すと、以下のことを軸に物事を整理している。

  1. サービサーが実現したい/作りたい/ユーザーに届けたいモノ(ミッションやコンセプトとか)

  2. そのサービスに関わる登場人物(ユーザー、運営など)

  3. 登場人物それぞれシナリオ(購入とか返金とか)

  4. 現在、システムがシステム利用者に届けている価値と、ノックアウトポイントの把握(業務まわらないポイントや、ユーザーが困ることなど)

  5. コストバランス(今に適してそうな方法の模索。これまた当たり前だが、時間とお金と人は無限では無いので。)

ざっくり5つのことを考え、最終的にステップやゴールを決める。


もはやテスト専任でもなんでもない。
向き合うのはテストスコープや仕様ではない。


品質 という言葉について、自分なりに色々考えてきた結果、現時点での僕の品質保証へのアプローチはこんな形になった。

この考えが、どの業界のサービスにも通用するとは思っていない。
しかし、どの業界であっても、きっとこの考えをベースに、応用したり、時には考え方を180度変えてみたりして、またゼロから作り上げていけるような気がしている。

どの業界であっても、向き合う相手が、システムを利用する人 であれば、あとはその人たちを理解し、想像出来るようになればよいからだ。

これらを楽しんでやれているのは、たぶん好きなんだと思う。
僕が真剣に品質に向き合うことで、誰かが豊かになるなら、こんなにやりがいある仕事は無い。

これが、品質について考えてみた、現時点で僕の中で整理された内容。

この記事が気に入ったらサポートをしてみませんか?