SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

「テストプロセス改善」をしてバグを削減しよう

テストプロセス改善にはどんなメリットが? 課題を低減するためのヒントをテスト専門企業が伝授

「テストプロセス改善」をしてバグを削減しよう 第2回

テストプロセス改善の課題

 今まで見てきた通り、テストプロセス改善には大きなメリットがありますが、もちろん課題もあります。メリット同様に、筆者が考える課題を3つ挙げます。

  1. 効果が出るまでに時間がかかる
  2. テスト作業が増加する
  3. ステークホルダーの理解を得難い

 それぞれについて、詳しく見ていきましょう。

1. 効果が出るまでに時間がかかる

 「人は経験がないことに関して、過小見積りか過大見積りしかできない」という言葉があるように、経験のないことを適切に見積もることは困難です。テストプロセス改善に関していえば、過小見積りをする傾向が多いように感じており、理由は2つあると考えています。

 1つ目は、人は都合の良い情報を選んで信じる傾向があるということです(これを確証バイアスと言います)。テストプロセス改善で言えば、改善を始める前はそのメリットばかりに意識がいき、あたかもそれがすぐに手に入るような錯覚に陥りやすいです。

 2つ目は、テストプロセス改善をしなければいけない状況は、市場バグが多く発生しているなど、切羽詰まっていることが多いからです。すぐに結果を出さないといけない状況のため、すぐに結果が出てほしいという願望から過小見積りへのバイアスが強く働きます。よって、確証バイアスと願望から過小評価をしがちです。

 しかし、テストプロセス改善には時間がかかります。時間のかかる要因は多くありますが、最も大きな要因は、「プロセスを実行するのは『人』だから」です。人は変化を嫌います。今まで慣れ親しんだ方法を変えるには抵抗があります。よって、気持ちを作るまでに時間がかかります。そして気持ちが作れても、新しいプロセスに慣れるまでにも時間がかかります。学習曲線にもある通り、人は新しいことを習熟するまで時間が必要です。また、習熟の速さにも個人差があり、組織全体として一定レベルに達するまでは、さらに時間が必要になります。

 筆者が電機メーカーにTPI Nextを使って、テストプロセス改善をしたときは、効果が出始めるまでに数カ月、コンサルテーションを終了するまで1年半かかりました。これもコンサルテーションの終了であって、改善の終了ではありません。

 つまり、自走できるまで1年半かかりました。また、車載メーカーにCMMiを導入支援したとき(開発プロセス改善を含む)は、コンサルテーションを終了するまで2年半かかりました。そのためテストプロセス改善をするときは、効果が出始めるのにある程度時間がかかることを意識して、やり続ける根気と努力が必要になります。ただし、これを短縮する方法もあります。そのやり方については、次の「テストプロセス改善の課題を低減するためのヒント」の章で紹介します。

2. テスト作業が増加する

 テストプロセス改善をすると、多かれ少なかれテストでやらなければいけない作業が増えます。例えば、今までテスト計画書を作成していなかった企業は、テスト計画書を作成しないといけなくなりますし、テスト設計書を作成していなければ、テスト設計書を作成することになります。

 特に、テストプロセス改善のモデルベースドアプローチでは、達成しないといけない要件が多く発生します。その要件を達成するために、テスト作業が増えがちです。また、テストプロセス改善に慣れていないと、企業や現場にカスタマイズせずにフルパッケージを導入しがちです。

 なぜなら、プロセスや作業を追加(プラス)するのは比較的容易だからです。知識や経験が不足すると、カスタマイズして要件を満たせるか分からないので、念のため入れておくということも多々発生します。逆に、プロセスを削減(マイナス)するのは、プロセスの理解と経験が必要になるので、難易度が高くなります。よって、このマイナスを適切にできるエンジニアが「できるエンジニア」だと思っています。

3. ステークホルダーの理解を得難い

 G・マイケル・キャンベル著『世界一わかりやすいプロジェクトマネジメント』に、グラハムの法則「あなたが何をしているか知らない人は、何もしていないと思うものだ」が紹介されています。

 また、英国の人類学者であるロビン・ダンバー著『友達の数は何人?―ダンバー数とつながりの進化心理学』の中で、3~5人を「クリーク」と定義し、最も親密な友人関係を築ける人数としました。そして12~15人を「シンパシー・グループ」とし、誰かが死んだときに深く嘆き悲しむ友人や家族の人数としています。この考えを企業に当てはめると、お互いの作業を深く理解しあえる人数は3~5名、ある程度何をやっているか把握できる人数は12~15名ということになります。

 つまり、ステークホルダーが、クリークもしくはシンパシー・グループに属していない場合は、あなたが何をしているか分からない人と映ります。その何をしているか分からない人が、自分のやっている作業を変えようとしています(通常はやる作業が増えます)。理解を得難いのは当然です。

 また、ダニング=クルーガー効果が働き、自分のやっていることは価値があり、自分が知らないことは過小評価する心理バイアスが働きます。つまり、テストプロセス改善をしている側は、「今のやり方は間違ったやり方で、それを正そうとしているのに、なぜ協力的じゃないんだ!」となり、現場は「今のやり方でやってきたんだ。それを、現場を知らない人が、よく分からない作業を増やそうとしている。やってられるか!」となることが多かれ少なかれあります。テストプロセス改善をするときは、その心理的傾向を十二分に理解し、対策を取る必要があります。

次のページ
テストプロセス改善の課題を低減するためのヒント

この記事は参考になりましたか?

「テストプロセス改善」をしてバグを削減しよう連載記事一覧

もっと読む

この記事の著者

高木 陽平(VALTES ADVANCED TECHNOLOGY INC.)(タカギ ヨウヘイ)

  東京理科大学大学院 技術経営修士(MOT)卒業。バルテスのフィリピン子会社であるVALTES ADVANCED TECHNOLOGY INC.の取締役。今まで、多数のソフトウェアテストやテストプロセス改善の業務に従事。大学でソフトウェア工学の研究室に入り、プロセス改善を研究。そのこともあり、CM...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/14932 2021/10/05 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー