DeNA品質管理部が語る、テストプロセスの標準化 - Part2

標準化における課題

河野哲也氏（以下、河野）：では、標準化の話に移っていきます。まずどんな背景があったかというところです。背景としては、「プロセスないですよ」と言っていながらも、実際仕事をしているからプロセスはあるんですよね。ただ、「プロセスはあるんだけど、それが見える化できてないです」というのが1つ目の課題です。「見える化したプロセスが共通化してないよ」というのが2つ目の課題です。

1つ目が、プロセスが暗黙的になっている。各チームでテストはやってるんだけど、「実際どんなやり方してるのか」というのはヒアリングしなきゃわからないという状況になっていました。

なので、それをチームで見える化できているところもあったんですが、周知できていなかったということです。なんとなくテストをやってるけど、プロセスってあんまり意識してないよというのが1つ目です。

2つ目が「プロセスにバラつきがありますよ」ということです。各QAチームがいるんですけど、例えば「テスト設計やりますよ」と言った時に、「テスト観点を出して項目を作ります」という人たちもいれば、「いきなり項目を作っちゃうよ」という人たちもいます。

そういったところのばらつきがあるので、そこも少し共通化していきましょうと。テスト業務の基本動作を定義して、各チームで最適化をしていきましょうというのが2つ目です。

1つ目は見える化しましょう、2つ目はそれを共通化していきましょうという背景がありました。

目的としてはプロセスの標準化をやると言ったら、「なんのためにやるの？」みたいな話ですね。プロセス上の作業の漏れや致命的なミスを防止していきますよということです。

例えば、テスト計画書がないときに、「じゃあはじめにテストのスコープって開発者と握ったの？」という話をすると、「握ってないですよ」となって、「それはちょっとまずいよね」という話になります。そういう致命的なミスを防止していきましょうというところが、1つ目です。

2つ目が「新規サービスのQAを立ち上げます」と言ったときに、テストプロセスのベースがないとけっこう大変なんです。「ゼロから考えなきゃいけない」となったときに、例えば本を買ってきて「プロセスって世の中一般ではどうなってるの？」みたいな感じで初めから考えるのは難しい。

普通は「今までやってるようなやり方でやってますよ」というところがあるんでしょうけど、それだと新しいサービスとかに対応できないというところで、最低限のたたき台になるようなプロセスの標準があったほうがいいよねというのが、2つ目の目的になります。

最後に、各チームをメンバーが移動することがたくさんあります。移動したときに「となりのチームへ移ったらぜんぜん仕事のやり方が違います」とかだと、やっぱり困るわけです。なので、となりのチームに行ったとしても、最低限やってる仕事の内容が統一化されているようなことが必要だよねというのが、3つ目の目的になります。

暗黙的なプロセスを見える化する

テストプロセス標準化の取り組みで、ここで少し演習をしたいなと思います。「プロセスの標準化」と言っても、まず見える化のところです。意外と見える化って難しいんですよね。「どうやってプロセスを見える化していくか」を、みなさんに肌で感じてもらいたいので演習をやりたいと思います。

まず、暗黙的なプロセスを見える化してみましょうということで、カレーライスを作るためのプロセスをみなさんに書いてもらいたいなと思います。プロセスって言うとちょっと難しいんですけど、例えば紅茶を入れるプロセスで言ったら、お湯を沸かします。ティーポットにティーバッグを入れます。ポットにお湯を入れる。ポットに蓋をして3分蒸らして、カップに紅茶を注ぎます。みたいな。紅茶を入れるとしたらこんなプロセスになります。

みなさんにはカレーライスを作ってみましょうということで、箇条書きで構いませんので書いてみてください。2分くらいで書けると思います。おいしくなくてもいいです。カレーができればいいです。

（会場笑）

カレーができればいいので、カレーライスを作るというのを、PCがある人はPCでメモ帳を立ち上げてもいいですし、紙で書く人は絵を描いてもいいかもしれません。時間を計りますので、2分くらいで始めてみてください。

（ワーク中）

このあともう1つ演習があるので、ぜひ手を動かしてください。これをやらないとつまんなくなってきますので、ぜひやりましょう。

残り1分です。

残り30秒です。

（ワーク終了）

では時間になりましたので、1回手を止めてください。みなさんカレーを作るプロセスが書けてると思うので、それをとなりの人と「どんなプロセスになりましたか？」というのを共有してみてください。

（ワーク中）

（ワーク終了）

では時間になりましたので一旦止めてください。

抜けてるポイントとか、たぶんいろいろあると思います。まず「カレーライスは作れてますか？」とか、「共通する作業や材料というのが各自ありますか？」「抜けてる作業がとなりの人と比べてありますか？」とか、「材料が抜けてますよね？」とか、「カレーライスを作るというスコープがたぶんずれてる」とか、おそらくとなりの人と比べてみたらいろいろあったと思います。

カレーライスを作るだけでも書いてみればいろいろ出てくるわけです。抜け漏れとか、スコープの違いとか、そういったものが見えてきます。

カレーライスを作れているか？

少し演習をまとめます。カレーライスはみなさん日常的によく作るものだとは思うんですけど、それを見える化するメリットはいろいろあります。

「そもそも最終成果物が作れていますか？」というところの見通しが立ちます。プロセスを書いてみると、「あ、俺カレーライス作れないわ」というのがまずわかりますよね。

次に全体作業のスコープが明らかになります。「買い出しに行く」って書いた人いますか？

（会場挙手）

あ、いますね。ただ、材料が揃っている場合もあるわけですよね。なのでそれは書いておけばいいわけです。カレーライスを盛り付けるところまで書いた人っていますか？

（会場挙手）

はい。「カレーライスを作れ」としか言ってないので、盛り付けるのが実はやりすぎかもしれないですよね。そういったところのスコープが明らかになってきます。

あと、作業とか成果物の過不足がわかってきます。「お米を研いでないじゃない」とか、「油なしで炒めてるよね」とか。そういったところがわかってきます。

「効率的に作業を進められているか」とか、作業のボトルネックがわかってきます。「カレーを作ってからお米を炊いたらちょっと効率悪いよね」「炊いた米がなければ盛り付けできないよね」ということで、米を炊くというところがボトルネックになるかもしれないことが見えてきます。

あと副次的な効果で、プロセスを書き出してみると作業の見通しが立ってくるので、場当たり的な作業がなくなってきます。

PFDを用いてプロセスを構築

実はマネージャーさんとかが「これやっといて」と言うだけじゃなくて、少し作業の見通しを立てて「こんなプロセスでやってみて」とか、「作業やってみて」と言ったあとに、「プロセスもちょっと考えてみて」という感じでプロセスで少し議論をすると、担当者のモチベーションが上がってくるんじゃないのかなと思います。なので、ちょっと書き出してみればだいたいわかります。

書き出すときに箇条書きで書くよりは、少しモデルを使ったほうがいいですよということで、今回プロセスの標準化をしていくときにPFD（Process Flow Diagram）という技法を使ってプロセスを表現しました。箇条書きよりは少しモデル……モデルと言ってもそんなにリッチなモデルじゃないですけど、こういう成果物と処理を少し絵で描いていきましょう。

カレーライスを作るときに（絵で）表現するとこんな感じになりますよというのを……ここを議論するだけでも30分くらいかかるので割愛するんですけど、モデルを書いてみればいろいろと見えてきますよというところで、絵で表現したほうがいいです。

（スライドを指して）今回も標準化するときにこの絵を作りました。ここからは標準化の進め方に移っていきたいと思います。

「どんなやり方をしましたか？」ということで、ボトムアップなアプローチで進めました。世の中一般の標準を追ってきたわけじゃないです。各自目の前でテストをやっているわけなので、そこにプロセスがあるはずです。なので、そのプロセスをまず見える化していきましょうというのが1つ目。

その見える化したものをリーダー陣で議論しながら共有していきましょうというところが大きな1つ目です。

プロセスを見える化

2つ目が「プロセスを書きました」というところで、共通的な作業とか共通的な成果物を見ていきましょうというのをやりました。そこを具体例で見ていきたいと思います。

（スライドを指して）これはヘルスケアのサービスのテストプロセスを計画からテスト設計まで見たところです。別のヘルスケア系のサービスもこういうふうに絵を描きました。絵はぜんぜん違うんですけど、ちゃんと見ると共通化しています。

（スライドを切り替えて）これはゲーム系です。ゲーム系のテストプロセスはこんな感じです。ゲーム系だと絵が多くなってきて、やることがけっこうあります。

次がオートモーティブ系のサービスで、いろいろ特徴的なものが出てきます。リーダーはどういう着眼点を持っているかと言うと、テスト計画のところでマネジメント要素がいっぱい出てきています。

ただ、今回標準化するところはマネジメント要素はあまり着目せずに、「テストの成果物はどうやって作れますか？」というところです。（スライドを指して）ここの中間成果物とかテスト項目書とか、こういったところを今回は共通的に見ていきます。

各リーダーに絵を描いてもらって、その絵を説明してもらう。説明すると、ほかのチームがどんなテストプロセスでやってるのかがわかってきます。この絵は各リーダーに事前に承諾を得ずに出しているので、ちょっとびっくりしているかもしれないです。

共通化の効果

次は絵を出したあとに共通化していきます。共通化するときに注意しなきゃいけないことがあります。あくまでも共通なので集合部分、要は集まっているところの、積の集合です。積の集合にしてください。

和の集合には絶対しないほうがいいです。要は全部のプロセスをまとめちゃうというパターンは絶対にうまくいかないです。なので積の集合にして、各チームが共通的にやっているところを集めましょう。

「（共通化を）やるとどうなりますか？」というのが、（スライドを指して）これです。さっきの議論をしたときに、共通的にやってるのはこれだよねというのを僕がホワイトボードに書きました。ちょっと字が汚いんですけど、やってることは簡単です。

あるQAの案件が出ましたとなったら開発者とキックオフをします。議事録を作って、そのあとにテスト計画書を作ります。テスト計画書からテストの見積もりをしたり、テストの設計をします。

そのあとにテスト項目についてです。だいたい2段階やってるのがわかります。まず、テストの観点を出しています。そのあとに項目を作っています。そのあとにテスト項目書でテストを実行していきます。見積もりのところはまた別で進んでいます。

この絵で見ていくと（やっていることが）ぜんぜん違うように見えるんですけど、だいたい同じようなやり方をしています。積の集合で取っていくとだいたいこんな感じになります。世間一般のやり方とほとんど変わりません。ただ「世間一般のやり方を周知していきましょう」というのが、今回のテストプロセスの標準化の考え方になっています。

これは僕が入社してたぶん2ヶ月くらいなので、昨年の12月くらいから（この取り組みに）着手して、だいたい1年くらい経っています。

標準化のところはまだ全部終わってるわけではなく、今も導入をずっと進めている段階です。

先ほどのように共通的なところを出していくんですが、成果物の名前が決まっていません。各チームぜんぜん違う名前で呼んでいます。ここ（スライド）には名前が決まってないので、テスト概要設計書と書いてます。

テスト概要設計書の「概要」って何だよって話になったので、これらをまとめてテスト仕様書という名前に決めました。みんなが共通的に認識できるような成果物にしなきゃいけないわけです。なので、ここは決めの問題になるんですけど、ここは成果物を決めていきましょうとなりました。

成果物を決める

そのあとに成果物の内容です。「どういう内容にしていきますか？」とか、「作業は具体的にどういうことをやりますか？」というところで、基本的には「計画書はこの項目くらいは用意してね」とか、「テスト設計書はこのテンプレートを使ってください」とか、「テストの報告書にはこういう内容を書いてください」みたいなところまでガチっと決めるわけではないんですけど、項目レベルは決めていきましょうという作業です。

だいたい大変さで見ると、このテストのプロセスを共通化するところはけっこう大変です。（共通化をする前に）読み解かなきゃいけないんです。「各チームリーダーがどんな頭の中身になっているのか」というのを読み解くのに、けっこう時間がかかります。でも、ほかのチームが何をやってるのかが見えてくるので、ここは逆にけっこう楽しいです。

共通化するのはけっこう大変です。名称を決めるのは決めの問題なので世の中の文献とか、例えばJSTQBの用語集とか見て適切な名称を決めていったほうがいいかと思います。項目レベルは「各チームでテスト計画書ってどういうのを書いてますか？」というのを共通的に見ていけば見えてくるので、そういったところを見て決めていきました。

テストプロセスのメリット

最後にテストプロセスのメリットと言うか、決めたことによって何が起こったかを話します。

まずキックオフというか案件……例えば「エンハンスが走ります」とか、「あるサービスを立ち上げて小さな機能をリリースします」とか、そういったところの単位で1つ案件が出てきたときに、キックオフのミーティングをやって議事録を作ります。

テスト計画書を作って、テストの見積もりが走って、その見積もりと並行して、もしくは別に見積もりが終わったあとにテストの仕様書を作る。ここはテスト観点を出すところです。そのあとにテスト項目書を作って、あとは実行して報告していきます。

基本オーソドックスな流れで、そんなに違和感はないと思います。なぜかと言うと、各々やってるテストのプロセスの積の集合を取ってるので、ぜんぜん違和感はないです。「共通的にみんなこれをやっていこうよ」「ここから付け足しはいろいろやってもいいよ」「やらなければやらないなりの理由を書いていきましょう」というアプローチにしています。

基本的には標準があるんですけど、「標準から追加でいろいろやらなきゃいけないのは各チームでやってください」「各サービスでやってください」というアプローチにしています。

標準を作りましたが、作っただけで置いていてもなにもうまくいきません。1つ目がドキュメンテーションをちゃんとしていかなきゃいけないということで、社内Wikiでドキュメンテーションしています。今ざっくりは書けてるんですが、詳細のところはまだ書けてないので、ハンドブック的に使えるような位置付けで、そういうものを今作ろうとしています。これはずっと僕が書いてます。

あと導入教育です。プロセスを作りましたと言っても、そのへんに置いといて、「あとはWiki見てください」だとうまくいかないので、1時間程度のセミナー形式で教育を3ヶ月やりました。今、非ゲーム系のQAメンバーには、ほぼ全員やってます。

だいたい（セミナーの）コンテンツとしては、「プロセスとは何ですか？」という話から始めます。対象者はテスト業務経験1年目の人から数十年の人を対象にしているので、下のレベルに合わせるということでプロセスって何ですか？　ということでカレーライスの作り方を書いてもらいます。

次にテストプロセスの話をして、標準テストプロセスの必要性、あとはテストプロセスの話に移っていきますというかたちです。

現在ちょっとメンバーに入れ替わりがありますので、全員が受けてるというわけではなくて、だいたい8割くらいが受講済みです。これは9割くらいを維持しようとしていて、毎月開催、もしくはクオーター単位で開催するようなアプローチを取っています。

おそらく標準化しましょうとかなにか決めたとしても、このへんをちゃんとやらないと、おそらくみなさんの現場でもうまくワークしないんじゃないかなと思います。

不具合が起きた時に議論のベースになる

このあとメリットの話を少しします。「標準化したことによって何ができるようになったんですか？」というところです。先ほど目的を言ったんですが、目的にプラスアルファでどんなことですか？　というところをここで整理しています。

まず大きなところから見ていきます。市場不具合が出ました。そのときにテストにどういう問題がありましたか？　という感じで逆戻りできるようになります。

テスト実行のところで見落としているのか、もしくは項目そのものに漏れがあるのか、そもそもテスト観点がなかったり、テスト計画のスコープがずれてるとか、そういうところは成果物があったら議論できます。なんとなくやってたらそれを議論できないので、まず議論できるベースができましたというところが1つ目です。

標準化と言っても、おそらく効果はそんなに出ないです。標準化したあとの次の施策で、けっこう効果が出ると僕は思っています。プロセスが見えるようになって、「テスト設計のところってどうやってやってますか？」と言うと、成果物ってほとんど入ってないんです。開発のドキュメントしか入ってないです。

すなわち何をやっているのかと言ったら、テスト設計者のノウハウで作っているということです。なので、そのノウハウを極力減らす。もしくはノウハウに頼るのもいいんだけど、標準的に観点として補強していきましょうということで、標準テスト観点の一覧を作って、このテスト設計のところに入れる。もしくはレビューのところで使いましょうというアプローチを取っています。

あと、標準的な仕事の手続きが決まってくるとデータが収集しやすくなります。テスト設計とか、テスト項目書設計とか、もしくはそのテストの実行というところのだいたいの工数が見えてきます。

工数が見えてくると、「テスト設計でこれくらいの時間がかかったら、項目はだいたいこれくらいの時間だよね」とか、「そしたらテスト実行の時間はこれくらいになるよね」というのが、だいたい広範的に見れば割合的に見えてくるかと思います。

「テスト設計の工数が3割だったら、実行もだいたい同じように3割くらいかかるよね」みたいなところが見えてくれば、だいたい先の見積もりのところに使えるようになってきます。実績の値とか参考値みたいなところで支援できると思います。

あとは改善活動全体ができるようになってきます。「何がまずいの？」というところをこれを見ながら議論できるので、そういうところにも使うことができます。