はじめに
今から2年ほど前、社内でQCサークルを立ち上げることになりました。
個人的にソフトウェア品質を考える上で良い活動ができているなーと感じているので、活動内容について紹介しようと思います。
QCサークルって何？
私も立ち上げるまで知りませんでしたが、Wikipediaには
同じ職場内で品質管理活動を自発的に小グループで行う活動
と書かれています。…なんとなく良い活動に聞こえますね。
しかし、こんなことも書かれています。問題点より一部抜粋
- 「予防よりは、失敗して起こしたトラブルの後始末の活動」を担当することになり、「予防なしのもぐら叩き」に陥った
- 「自主的」（Independent）活動として出発したが、このことが給料の対象とならない非正規業務として過労死などの人間性の尊重に反する事態を導いた
- 本来、相互啓蒙のために他のサークルを聴衆とし行うべきなのに、審査員に対して発表するという習慣が出来上がり、審査員の評価を高くする競走を招き、ほとんどがデータの改ざんや虚偽した発表が多く見られる
…なんとなく維持するのが難しい、つまらなそうな活動に聞こえますね。
これを読んでいると、私たちの活動はQCサークルではないのかも知れない…と感じつつも、「同じ職場内で品質管理活動を自発的に小グループで行う活動」であることに間違いはないので、自信を持って良いQCサークルが維持継続できていると考えます。
メンバ紹介
活動内容を紹介していこうと思いますが、メンバプロファイルがあった方が良いかなと思うので簡単に紹介します。
※立ち上げ当初は10名ほどいましたが、現在は6名で活動しています。QCサークル専門の方はもちろんいません。
・開発エンジニア、ラインマネージャ
・開発エンジニア、若手
・QA（Quality Assurance）エンジニア、ベテラン
・製品検査エンジニア、中堅
・カスタマーサポートエンジニア、中堅
全員開発には携わっているものの、役割、ポジション、年齢はバラバラです。
（最初は意図的に複数部門から集めましたが、今はみんな自発的に活動しています）
QCサークルって何するの？
特に決まりはないと思うので、私たちの活動を紹介していきます。
まず、活動は毎週金曜の午後30分間と決めています（週末の午後はテンションも上がりやすい）。
障害共有会
「障害を共有し、原因を追究して知見を得る」活動
通常、本番環境で障害が起きると、経緯・経過報告、原因分析、再発防止など大変な緊張感の中、相応の役職者が出てきて、堅苦しくなりますよね。
※障害でご迷惑をかけているので当たり前ですが…（誤解のないように先にお伝えしますが、もちろん本気の障害分析や再発防止は本業の方でしっかりとやっています）
QCサークルでは、何かしらの障害を取り上げ、「障害あるある」や「どうやれば防げたか」などを気楽に話していきます。
障害は過去発生したものならなんでも良く、中には15年以上前の障害を対象にすることもあります。ベテランの方からこんなのが昔あったんだけど…という感じで出されます。
フランクな雰囲気を作り、自由な発言を行うことから障害に対する意識を変えることを目的としています。なぜなぜ分析など体系だった分析はしません。
・障害は「誰かのせい」ではなく、「誰しも起こしうるもの」「誰もが見落としていたもの」
・対策は「誰かがする」ではなく、「自分が防ぐにはどうするか」
プロジェクト振り返りシェア
これはその名の通り「プロジェクトの振り返り結果を、全体へシェアする活動」で、QCサークルは運営側という感じです。
シェアは担当プロジェクトリーダーの方にお願いします。
振り返り形式は主にKPTを採用していますが、シェア会では下記のことをQCサークル外の方にも考えてもらうようにしています。最後に聞いてもらった方からランダムで指名して感想を述べてもらうようにすることで、相互に意見交換ができるような仕組みも取り込んでいます。(「指名されるかも知れないから考えなきゃ…」みたいな仕掛けにもなります)
- Problem（悪かったこと）やTry（次に挑戦すること）を聞いて自分ならどうするか
- Keep（良かったこと）を聞いて自分のプロジェクトで取り入れるにはどうするか
有識者マッピング
多くの会社や開発で、プロセスってありますよね。市場調査、分析、企画、要件定義、開発、テスト、リリース…
プロセスってその会社の重要なナレッジだと思うんですが、「何をするか」が継承され「なぜ必要なのか」が継承されないために、形骸化しちゃったってあるあるだと思います（個人的所感）。
じゃあナレッジとして残そう！と頑張っても、手順書があるだけで経緯は薄い…みたいな。
ということで、「困った時誰に聞けば分かるんだっけ？」というのをマッピング＆可視化して、新しく入った方や分からなくなった時にはこの人に聞いてみようとすることで、そのナレッジをしっかりと継承していこう！という活動です。これまたQCサークルは運営的な立ち位置です。
品質の日
年に2回（半年に1回）、品質の日を設けて、過去起きた重大障害などを思い出す機会にしています。新入社員の方も、品質の日ってなんだ？過去そんなことがあったのかと知る機会にもなりますし、全員が定期的にリマインドするための日です。
しかし、これをイベントとして運営するのは結構大変だったりするので、社内記事書いたり、半年間のQCサークルの活動を共有をしたりしています。（運営大変になると負荷かかっちゃいますからね）
やってみて
2年間やってきました。成果は？と聞かれても定量的なものはありません。強いて挙げるとすれば何回障害共有会をやったかとか。しかし、ここに定量的な目標や成果、報告を求めてしまうと辛くなっていきます。自由に、気軽にやっていくことで、継続性を持たせ、参加した本人や周りの人が「タメになっている！」「良い気付きを得られた！」って感じてくれていることがこのような活動には最重要だと思います。
さいごに
ソフトウェアのバグは人が作りこみます。品質向上のためにテストはもちろん必要ですが、極論バグを埋め込まなければ品質は良くなります。
- 「どうやったらバグを検出できるようになるのか」を考えることも必要ですが、
- 「どうやったらバグを作りこまなくなるのか」という視点から、エンジニアの失敗を共有して、疑似的に経験値を爆増させて、ナレッジを強化する
ということに対して、QCサークルの活動は非常に効果的なんじゃないかなと感じます。
ソフトウェア品質で悩まれている方の、何かしらのお役に立てたら幸いです。