読者です 読者をやめる 読者になる 読者になる

品質の作りこみへのモチベーション

ソフトウェアは品質が高いことに越したことはないですし、そのための努力は怠るべきではないとは思うのですが、基本的に品質を評価するのは開発者以外です。開発者から見た品質要求というのは与えられるものであり、自発的に品質レベルを掲げることはなく、どちらかというと監視されているような位置づけが多いのではないでしょうか。

品質管理にしろ、リリース後のバグにしろ、起こってしまったことに対して反省やふりかえりや修正はしても、それがどのようなマイナス的な価値をもったのかを評価するのは開発者では無い場合が多いと思います。我々は、その評価を与えられて驚き落ち込むか、想像して反省するという形で、精神的なダメージは大きくなります(笑)。

最近仕事で、スクラム開発とXPの合わせ技ということで、TDD、自動テスト、リファクタリングなどを開発中に行い、品質を上げていくという意味での「品質の作りこみ」をやっています。スクラムは「自己組織化」が大きなキーワードになっており、それもこれもスクラムマスター(リーダのようなロール)が(できるだけ)指示するのではなく、メンバー自身が考えてやろうとしています。

当然、品質に関しての懸念は出てきており、「何を持って品質を担保するか」という話題になるわけですが、どうも私としては、第三者だけが品質を評価するのがスクラムの意義と離れるような気がして違和感があります。そこにチームが介在していない上、そもそも、品質とはなんなのか、何をもってOKとするのかが曖昧だからです。

ソフトウェアはそれだけで価値があるわけではなく、誰かに使ってもらったり役に立ったりして初めて価値が発生するわけですが、その価値に対応した品質があるわけで、品質を多少おろそかにしても早く出すことに価値がある場合や、品質を99.9%まで上げたうえででないと価値が発揮できない場合もあると思います。それはプロジェクトによってまちまちであるはずです。

そのような品質の定義と目標を、裏付けとチームの同意を持って掲げ、それをモチベーションの一つとして自己組織化していくのが、スクラムとしての意義につながるような気がしています。そのサービス(システム)のために、ここまでの品質で出したい、だからしっかり品質の作りこみをしたいんだ、という一人ひとりの想いとモチベーションで、チーム全体が品質の作りこみをしていく。そんなチームができたらいいな、と思っています。

開発者自身も、作ることばかりに意識が行って品質の意識が低いとか、そのソフトウェアの何が価値を発揮できるのかという意識が低い部分があるのは反省するところではあります。それをチームとして改善していくと同時に、品質が高いのは当たり前ではなく、それを価値の一つとして認識し、その価値が実現できた場合は、何かしらの対価(それは褒め言葉のようなものなのかもしれませんが)を与えられるような環境ができると、それがモチベーションにもつながるのではないか、と最近思います。バグが出た時に怒られるだけではなくて(笑)。

まぁ、難しい命題ですがw。んなことは理想にすぎないのかもしれませんが、プレッシャーがエネルギーになるのではなく、もっとポジティブな事がエネルギーになるようになると、楽しく仕事ができるんですけどねん。ことに品質のことに大しては周りが厳しいだけでorz。楽しくやって、厳しくやったときと同じ結果が出る方法は無いか考え中です(笑)。