サービス品質を考える上で、僕が一番大事にしている考え方

事業をする上で、ユーザーに届けたいモノや、作りたい世界があるはず。
それを実現する一つの方法として、ITのToolがある。
既存のサービスをつなぎ合わせて実現した場合でも、ゼロから自前で開発した場合であっても、サービス品質は大事だ。

今回は、自分たちで企画して、自前でTool（プロダクト）を開発し、世に届ける時に行うQA活動にて、僕が大事にしていることを書く。

僕が一番大事にしている考え方として、

この機能（仕様）は何のために存在するのか？
なぜ、この機能（仕様）が必要になったのか？

を考えることだ。

この問いを自分にぶつけながら、プロダクトに向き合うと色々な発見が出来る。
人の多くは、不安になったり、不確かな未来に立ち向かう時、どうしても何かを付け足したくなるものらしい。

そこで、上記の問いを行う。

そうすると、存在理由があまり重要でない機能があることに気づく。
そういった機能は、実際に必要になるまで実装せず、バックログに積んでおくだけでよかったりする。

これは、包丁を研ぐように、丁寧に何度も繰り返すと、本当に実現したい世界に必要な機能だけが残り、シンプルになることが多い。

シンプルになるといいことしか無いと個人的には思っている

• 仕様がシンプルになり誰もが理解しやすくなる

• ユーザーが操作しても迷わず、結果的にリードしていたりする（使いやすい）

• 仕様がシンプルであれば、実装自体もシンプルになる（ことは多い）

• 結果、不具合や障害のリスクも下がる

• 追加開発や保守運用面でも楽になりやすい

• 何より開発工数が抑えられる（ことが多い）

• 機能が減ると、リリース前のQA工数も当然減る

などなど

機能を削る

という意識でスタートすると、なぜか全然機能を削れないが、

存在する意味が無い機能or弱い機能の開発は後回しにする

という意識でスタートすると、バンバン削れる。

この考え方は、僕が一番大事にしている考え方だ。

しかし、一つ歯がゆい問題がある。
この考え方でプロダクト開発に関わるとしても、リリースが近い後半のフェーズだと効果が半減し、なんなら混乱を無駄に生んで終わったり、今更言われてももうどうにもならない空気になる。
いわゆる
「しょーがない」
ってやつだ！

だからこそ、僕は、仕様や実装完了を待つことはしない。
むしろ、仕様や実装が終わっていない時こそ、最大のQA活動チャンスと捉えている。

実装前であれば、開発コストを下げて、実現できるかもしれない。
仕様未確定状態であれば、より神経が通った仕様に仕上げることが出来るかもしれない。
要件レベルまで食い込めたら・・・可能性は無限だ！！！

僕は、QAという言葉は、活動であり文化のようなものだと思っている。
だからこそ、どの役割でもQAは必要だし、プロダクト開発の至るところにQAの意識が散らばっていることが理想。
どんな役割であっても、プロダクトを使うユーザーのこと、運営する人のこと、事業者の想い。
これらを理解しようと努力しつづけることで、本当に担保すべき品質を見つけられる気がしている。

機能的な情報だけに囚われず、視野を広く持って、これからもサービス品質に向き合っていこうと思う。

本当に必要な 品質 に目を向けれる人間になるために。