はじめに

品質管理部の河野です。 開催レポートが遅くなってしまってしまったのですが、「おわりに」で遅くなった言い訳を書かせて頂きます。
すでに第一部の松尾谷さんの講演は こちら でレポートさせて頂きました。
こちらの第二部では、DeNAパートの中でも事例のところにフォーカスを当ててレポートいたします。 今回、DeNA QA の事例として、テストプロセス標準化の取り組みを発表させて頂きました。以降、発表の背景と概要をレポートいたします。

発表の背景

ちょうど１年前の１２月くらいから部門横断の改善活動を開始したのですが、そのとき真っ先に着手したのがテストプロセスの標準化でした。各チームでバラバラだったテストの進め方をまずは全体的に共通化しようと言うのが本発表の取り組みです。
その後、標準テストプロセスが概ね出来上がった段階でその導入を進めつつ、TPI NEXTを使ったテストプロセスのアセスメントや標準テスト観点の整備などの取り組みを進めてきました。また、テストプロセスが標準化されたことで、今後はテスト活動のメトリクスの収集を行っていく予定です。
ということで、まずはテストプロセスを標準化していくことで、その後の活動がスムーズに進んだように思います。 それでは、当日の発表概要に移ります。その前に、当日のスライドはこちらになります。

発表の概要

当日の発表では、上記のような背景を初段に説明して、その後は、具体的にどのようにテストプロセスを標準化していったのかという事例を紹介しました。
テストプロセスの標準化というと難易度が高そうに見えますが、我々が取ったアプローチは以下になります。
１．各チームのテストプロセスの見える化する
２．上記テストプロセスの共通化する（積の共通とする）
３．成果物や処理の名称を決める
それで、当日は１．の見える化を「カレーライスを作る」演習を交えて、皆さんで少しワークをしてもらいました。思いの外、盛り上がってよかったです。
その後は、２．と３．を具体例を交えながら解説していき、最後の方で標準化のメリットなどを示しました。

後日談１：プロセスに関しての松尾谷さんの発表について

松尾谷さんの発表で、品質関連のアプローチとして「プロセスや技法」は負け犬の遠吠え、
のような解説がありました。 それに関して、後日というよりは発表後の話になるんですが、
松尾谷さんから以下のような意図のコメントを頂きました。

私が言ったのは河野さんの発表のようなプロセスではなくて スタッフ部門や管理部門が押し付ける規範的なプロセスを指しているので 逆にこのようなプロセスを標準化するのは良いことだ

後日談２：PFDってそんなに簡単なだっけ？

本イベントに参加した私の知り合いに、とあるイベントであったのですが、こんなことを言われました。

PFDでプロセスを書くのを簡単に発表してたけど、 そもそも目の前の業務をPFDに書くことは結構難易度高いんじゃない

• 最終成果物から戻るようにプロセスを書いていく
  　最終成果物からその前の処理、その処理の入力成果物といった感じで考えるほうが
  　経験的に知的ハードルが低くなるように感じます
• 最初はメタに捉えて、作業の粒度を荒くする
  　細かく考えるとキリがないです。まずはメタに捉えて、細かくしていきましょう。
  　細かくしていくところは参考資料を見てみてください。
• ホワイトボード / 紙と鉛筆で書く
  　いきなりpptで清書すると挫折します。挫折というより、時間切れになると思います。
  　なので、まずはラフにスケッチしましょう。
  　スケッチできなければ、よくわかっていないことなので、次の工夫です。
• 一人で考えすぎずに、他の人を巻き込む
  　実態がわからなくて、PFDで表現できないところが出てきます。
  　なので、そういうところは知っている人に聞くのが早いです。
• 成果物と処理の名前付けに気をつける
  　これは重要です。周りのメンバが共感できるような実態にあった名前をつけましょう。
  　それと、成果物と処理にふさわしい名前、特に処理は動作を表す名前をつけましょう。

おわりに

今回の第一回、DeNA QA Night は参加者・講演者の皆さんのおかげで成功だったと思います。ただ、これは終わりではなくて始まりです。
次回もやります。日程は３月６日（水）で決まっております。次回も業界の一線級の識者にお声がけしてます。是非、期待して下さい。
ということで、次回日程が決まってから開催レポートを書きたいと思っておりましてこんな遅い開催レポートとなってしまいました。という、言い訳でした。
皆様、良いお年を！