entry-header-eye-catch.html
entry-title-container.html

entry-header-author-info.html
Article by

継続的な品質改善のための品質プロセスアセスメントを行なってみました

みなさんこんにちは!ピクシブで唯一のテスト専任エンジニアの @shimashima です。

2020年7月から、社内の前プロダクトを対象とした品質プロセスアセスメントというものを行うようにしました。4半期ごとに1回で現在3回目を終えたところです。 今回はこの取り組みについて説明していこうと思います。

品質プロセスアセスメントとは

「品質プロセスアセスメント」と聞いても何を目的として何をしたのかわからないと思います。ここでその説明をしていきます。

目的

品質プロセスアセスメントは、以下のような目的をもって行いました。

チームでいま実施しているテスト・品質関連の作業についての共通認識をもつ。自分たちの現状をシンプルな方法で把握する。

プロダクトチームではそれぞれ独自に品質活動を行っています。ですが、それが明文化されていないため外部からうかがい知る事ができないだけなく、実はチーム内でも認識が揃っていないことがありました。 そのため、チーム内で自身が何を行っているのか共通認識をつくることを目的としました。

改善の際のベースラインを作成する。

ピクシブではポストモーテムによる改善活動も行っています。 しかし、ポストモーテムで出た改善案がプロセスに組み込まれないために、その場限りとなってしまうこともありました。 プロセス改善を行った際に今あるプロセスを書き換える、その場所を作ることも、このアセスメントの目的です。

品質プロセスアセスメントで行ったこと

品質プロセスアセスメントというと何か大それたことの様に思われるかもしれませんが、行ったのはシンプルで以下の様なことです。

プロダクトチーム毎1人、在籍期間が一番短い人にヒアリングする

アセスメントは、各プロダクト毎1名そのチームへの在籍期間が一番短い人にヒアリングする形式で行いました。 ヒアリング内容は後述しますが、1チーム30分程度で終わります。

9つの品質に関する基準を聞く

ヒアリング内容は以下に9項目です。

  1. テスト・品質計画を定めているか
  2. 要件レビューを行っているか
  3. 設計レビューを行っているか
  4. コードレビューを行っているか
  5. ユニットテストを行っているか
  6. 受け入れテストを行っているか
  7. リリース基準が定まっているか
  8. 作業完了基準(DoD)が定まっているか
  9. 障害トラッキング実施有無

これらの事について実施基準となるドキュメントがあるかをYES/NOで答えてもらいます。YESの場合は原則としてそのURLを提示してもらいます。

アセスメント設計の理由

社内で実施した品質プロセスアセスメントについて説明しましたが、内容をきいていくつか疑問に思うこともあるかと思います。それらについてなぜそのような設計をしたのかを説明します。

なぜドキュメントの有無に着目したのか

先ほどの説明で違和感を覚えた方も多いのではないでしょうか。なぜプロセスとして行われているかではなくドキュメントの有無に着目しているのだろうと。 これには以下のような理由があります。

共通認識を作る

今回の施策で重視したことの一つは、目的にも挙げたようにチーム内での認識が揃う状態にするということがありました。 実際社内であった事例では、ユニットテストは全員が作成し実施しているとはいったものの、常に行うのか行わない場合があるのか、何を目的としてどこまで行うのかが定まっていないことがありました。 この状態だとある人の「ユニットテスト完了」と別の人の「ユニットテスト完了」は違うものですし、そもそもの実施目的も共有されていません。 プロセスのムラが大きくなってしまいます。

明文化されていることにより改善が促される

社内ではポストモーテムを含めたふりかえりが日常的に行われています。その中でプロセスに対する改善も行われているでしょう。

ただ、いま行われているプロセスが明文化されていない場合どうなるでしょうか?ふりかえりの場でプロセス改善がみんな納得してやっていこうとなったとしても揮発して忘れ去られてしまうのではないでしょうか。

ではどうすれば良いかというと、プロセスを書き留める場所を作っておくことだと考えました。プログラム修正でパッチをあてる場合もあてる先があってこそ。そのように考えました。

そのため、実際に行っているかどうかよりもそれが明文化されていること、そしてそれが誰でも指し示すことができる。この2点を重視しました。

なぜチーム在籍期間が一番短い人にヒアリングしたのか

もう一つ説明で意外に思うかもしれない点が、このチーム在籍期間が最短の人を対象にヒアリングをすることです。

チームの状況をヒアリングする際に、一番チームに熟知した人を対象にすることは一般的かと思います。今回は敢えてその逆を行いました。なぜでしょうか。 それは、一番チームのルールを知らない人を対象にしたかったからです。

アセスメントはチームにルールが有るかを確認しますが、それは同時に「誰でも知っている・把握しているか」も同時に行います。一部の人しか知らないルール・基準では意味がありません。 チームに長く在籍している人は当然チームの事情を深く理解しているはずです。その逆の一番在籍期間が短い人に確認し、その人が把握していれば多分チーム全員が知っているだろうとみなすことができます。

そのため、ソフトウェアエンジニア歴ではなくチームの在籍歴を基準にし、しかも一番短い人を選ぶようにしました。

アセスメント結果と改善の取り組み

アセスメントを行うことで以下のようなことがわかりました。

  • ユニットテストはほぼ全てのチームで行われているものも、何を・どこまでといった基準が定まっていることはあまりない。
  • コードレビューについてもユニットテストと同様の傾向があった。
  • 総じて各プロセスは実施しているが、必ずではない・どこまで行うかが定められていない。

この結果を責任者を通じてプロダクトチームへフィードバックを行い、その後も含めて現在まで3回ほど実施してきました。その結果、一部のチームでは私に対してプロセス改善の依頼があり、まず現状を自分達が行っていることを明文化するということができてきました。

終わりに

「明文化する」ことを前提としたプロセス改善の事例をご紹介しました。まだ始めたばかりで最終的なプロダクト品質として目に見える結果をだせていませんが、様々な改善のためのベースはできたと考えています。 この事例が皆様の組織での品質プロセス改善の一助になれば幸いです。

また、今後テスト・品質周りの取り組みをチーム化していこうと考えています。もしピクシブでのテスト・品質改善に興味がありましたらWantedlyのコーポレートエンジニア募集にコンタクトをください。カジュアル面談をしていきましょう。

20191219021602
shimashima
2017年11月に中途入社した、ピクシブ随一のQA/テストエンジニアで"品質実質無料"の人。社内の品質向上に東奔西走する日々。 2012年よりJaSST(ソフトウェアテストシンポジウム) Tokyo実行委員。