『テストプロセス改善技術から探るテストの"改善"とは』参加レポート #jasst

JaSST 勉強会 技術

テストプロセス改善

登壇者の紹介

  • 薮田
    • TPI NEXTの立場から
  • 増田
    • ISO/IEC 33063の立場から
  • 西
    • ノンモデルのプロセス改善の立場から
  • 足立（モデレータ）
    • SaPIDの立場から
  • 池田（モデレータ）
    • TMMIやTPIを導入支援した立場から

テストプロセス改善技術のこれまで

  • まだまだテストプロセス改善は実施されていない
  • ただし、最近発表が増えてきている

TPI NEXT(薮田)

  • 自己評価とそれに基づく自己解決
    • 他人に見せても何も分からない
  • 評価軸はプロセスではない
    • 独自に選定した16個のキーエリア
  • ビジネス主導である

ISO/IEC 33063(増田)

  • 国際標準であること
    • 認証はこれから？
  • アセスメントモデルから…
    • 何のプロセスにあっているの？
      • ISO/IEC/IEEE 29119-2
    • どれくらいあっているの？
      • ISO/IEC 33020

ノンモデルのプロセス改善

  • TQM
  • 品質管理を一生懸命すると頭が良くなる
  • TQMはマニュアルではない
  • 人の数、会社の数だけTQMがある
  • 理解して適用するのではなく、自分の会社なりにTQMを進化させることが大切

ソフトウェアテストの現状（海外の人から言われること）

  • 日本は品質の高い会社があるんだからソフトウェアでもやればいいじゃないか
  • なんで海外のプロセス改善を買ってくるの？

TQMの思想

  • 思想を理解せずにツールボックスとして使っていることが多い
  • 全ての質を上げることがTQMの思想
    • お客様が如何に喜びを感じるか
    • 品質第一
      • 品質をきちんと上げれば、コストが減るはず
      • 最初にコストを下げると、品質が下がるコストが増える
    • 改善
    • 全員参加
    • 「何が嬉しいのか？」を常に問う
    • おかしなことの原因をパターン化して共有する
    • 未然防止
      • まだ出会ったことの無いものを防ぐ
    • 管理は技術である
    • 次工程はお客様
  • 品質管理が「まずはメトリクスを決めよう」という人は信用しなくて良い
  • プロセスを見るな、問題を見ろ

技術を導入する際の注意点や難しさにどう対応して行ったら良い？

薮田

  • TPI NEXTはプロセスだけではない
    • ISO/IEC 33063はプロセスのみだけど
  • TPIは訳がわからなかった
    • ゴルフのキーエリアをやってみたらようやく分かった
  • キーエリアを無手勝流でやってみると、えらく金と工数がかかる
  • 合わない所があったらカスタマイズする
    • カスタマイズした結果、それぞれの会社ごとで別々のプロセスになる
  • プロセス改善モデルと言われると、プロセスを定義して改善するようになっている。プロセスは決められているの？
    • プロセスは定義していない。
      • TPIのPをプロセスと訳しているのは良くないと思う
    • あくまでもテスト改善

増田

  • ISO/IEC 33063はプロセス改善モデル？
    • あくまでもアセスメントモデル（評価モデル）
    • ISO/IEC/IEEE 29119-2を用いている
  • ISO/IEC/IEEE 29119-2以外に追加しているものはあるか？（教育とか）
    • STATIC TEST PROSESSの部分とか…

池田

  • TMMiは？
    • こういったことをやりなさいという話だけはしているが、具体的な進め方は会社ごと
  • ISO/IEC 33063はISO/IEC/IEEE 29119のプロセスを守れと言っている。
    • つまり、ISO/IEC 33063とTPI NEXTは相容れないもの
  • 導入の中はTMMiとTPI NEXTは同じように進んでいく
  • 実際の仕事の進め方は直接的に書かれていない
  • TMMiはISO/IEC 33063よりはTPI NEXTに考え方が近い

アンケート

  • 実際のプロセス改善を行おうとしている
    • 5%ぐらい
  • プロセスに関する業務をしている
    • 半分
  • 自分だけでなんとかしようとしている
    • 少ない

会場内の質問・悩み

難しい

  • 余計なことを考えずに質問に1個1個応えるだけで良い
  • 1時間ぐらいでできる
  • チーム間での違いなどを議論すれば良い
  • それは、俺達困っているかも？と気付きが出るということか？
    • チーム間での違いから議論が湧き上がる。それでも1日ぐらい
    • チェックリストに付けて議論しようよ、と伝えたい

見積もりができない、説得できない

  • 反対派が多い、改善へのモチベーションがない
    • 困ってないんじゃない？ならいいじゃん
    • 押し付けが起きている？
  • 他プロセスへの改善にどう繋げるのか分からない

プロセス改善に至るまでに時間がかかる

  • プロセスを標準化したほうが良いよね？というコンセンサスを取るのが大切
    • それがないと改善のモチベーションが無いことに繋がる
  • 開発のプロセスから考えていって、最後の方にやってテストプロセス改善に繋がる

テストだけ改善しても打開できないことが多い

  • とんがっていてもみんなに同意してもらえない
    • こういうモデルがあるから…というのはだいたい否定される
  • 何に困っているのかまずは出し合ってみるのが大切
    • みんなで話せるようになって初めてモデルや手法の話が出てくる

忙しいし、どーせテストだし、みたいに思っている人にどうやって壇上に上げれば良いのか？

  • 困っていることを見つけてあげる
  • 困っている人だけ？想いが熱い人だけ？熱くない人も入れたほうが良いの？
    • 人格による。
  • 場を作るのがとても大切
  • 人間は環境を与えると勝手に動き始める

テストの改善とは

薮田

  • いつも会場からの質問のようなことに悩まされている
  • 抽象的な話を推進するときに、言葉で説明するのは無理
  • 実物を見せる以外に手は無い
  • まずは自分の頭の中だけでやってみる
  • ふふーんと思った上で、隣の人とかに広げていく

増田

  • 上司への説得の材料をもらいにこのセッションに来たと思う
  • それに答えられたか不安

西

  • 不良品の検査結果から分析して、良いやり方を標準化している
  • ソフトウェアは仕事のやり方さえすれば
  • 役に立たないテストケースの山を見て、どうしてこのテストケースがダメで、ということを分析すべき
  • 本当はテスト漏れを見るべき

  • テストの網羅できる実感が無いよねから始めると良い

  • 現場ではテストを知らない人が多いので、その人達への話をきっかけ

テストプロセス改善技術研究会

  • 現在、設立に向けて準備中