「合意」が品質をつくる

スクラムで開発しているチームのQAを担当することになった。
アジャイル開発やスクラムについては書籍などで多少理解していたつもりだったが、実際の現場に触れると勉強不足を痛感してしまう。

そういったわけで改めてスクラム開発のプロセスを学び直しているわけだが、その中で感じたことがある。

品質のキモはデベロッパーのスキルで決まるわけではなく、
テストの技術力で決まるわけでもなく、
アーキテクトの構成でも、
プロジェクト管理の上手さでもない。

合意だ。

「どのようなものを、どこまで、どのようにつくるか」について、
プロダクトマネージャーとデベロッパー、
デベロッパーとQAエンジニア、
QAエンジニアとプロダクトマネージャー、
それぞれで合意をとることが品質の要となるのではないか。

JSTQB FL シラバスの「テストの7原則」に「テストは状況次第」という原則があることを思い出したい。ソフトウェアの特質によって求められる品質のレベルは変わるだろう。それぞれの品質特性を上げられるだけ上げればいいというものではないのだ。

以前、ソフトウェアテスト界隈でQAエンジニアを 医者 に例える話が盛り上がった。

おそらく「チェックする」という側面から医者の例えが出たのだろうけれど、QA活動を「合意」という切り口で捉え直すと医者というよりは 裁判官 に近いのではないだろうか。

開発に関わる人たちそれぞれの言い分を聞き、合意形成に導いていく。
それは診察というより調停の形に近く、
そういった役割がきっとこれからのQAには求められるだろう。

さて、ここで新たな疑問が生まれる。
合意形成のためにはどのような場をどのタイミングで設けるべきか、それは経験による直感に頼らなければならないのか、それとも明文化できるものなのか。
プロジェクトの進行とともに答えを探っていきたい。