SHOEISHA iD

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

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

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

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

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

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

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

 テストプロセス改善の課題(「効果が出るまでに時間がかかる」「テスト作業が増加する」「ステークホルダーの理解を得難い」)を3つ挙げました。それらに対する筆者なりの低減のヒントを紹介します。もちろん、業種や規模などにより、それぞれ状況は違うと思うので、全て取り入れる必要はありません。必要なところだけ参考にしていただけたらと思います。

1. 「効果が出るまでに時間がかかる」を低減するヒント

 上記で見てきたように、テストプロセス改善の効果が出るまでには、時間がかかります。しかし、テストプロセス改善をする場合、市場バグが多く発生しているなど、切羽詰まっていることが多いです。なるべく最小の労力で、最短で効果を得たいものです。そこで、筆者なりの時間を短縮するためのヒントを3つ挙げます。

  • a. 自前主義をやめる
  • b. 専門家に依頼する
  • c. トレーニングを実施する

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

a. 自前主義をやめる

 「NIH症候群」というものがあります。NIHとはNot Invented Hereの略で、自前主義で他で開発したものを使いたがらないことを指します。確かに、自分たちで試行錯誤しながら開発したほうが学習効果は高いですし、自社の状況に合わせて開発できるので、より自社にフィットしたプロセスを開発することができる可能性があるなどメリットがあります。

 しかし、1から自分で開発していると時間がかかります。また、手法や規格などはその道のエキスパートが開発していることが多いです。そのエキスパートの知恵を取り入れることができないのはもったいないことです。

 効果が出るまでの時間を短縮したい場合は、他から持ってこられないか検討しましょう。具体的には、第1回で紹介したコンテンツベースドモデルの採用を検討します。

 コンテンツベースドモデルには、STEP、CTP、QUINTEE、ISO/IEC/IEEE 29119の4つがありました。どれを採用しても良いですが、なるべく情報量が多いものを選ぶほうが楽だと思います。本連載では、第3回でQUINTEEの導入事例を紹介する予定です。QUINTEEは、年間2100プロジェクト以上のテストを実施するバルテスが、17年以上かけて洗練させてきた知識体系になります。

b. 専門家に依頼する

 こちらも、「NIH症候群」に似ていますが、日本では自社の社員で全てをやろうとする傾向が強いように感じます。自社にテストプロセス改善のエキスパートがいる場合は問題ありませんが、経験が少なかったり、初めてだったりする場合は試行錯誤することになります。ただし、自社でやる場合は、学習効果や自社に最適なプロセスを構築できる可能性があるので、時間に余裕がある場合は自社で実施するのも1つの手です。

 一方、専門家に頼むと、確かに追加コストはかかりますが、専門家はすでに確立した手法やノウハウを持っているので、時間を短縮することができます。また、いろいろな現場に適用した経験があるので、その経験を利用できるのは大きなメリットです。

 なお、弊社の場合は、テストの専門部隊もいるので現場の支援が可能です。つまり、テストプロセスの訓練を受け、経験を積んだメンバーを入れることで、学習の時間をカットして、いきなりパフォーマンスを発揮できます。

 第3回で紹介する事例では、市場バグが頻発しており切羽詰まった状況であったため、テストプロセス改善のコンサルテーションに加えて、テストに関しても弊社のテスト専門部隊で、最初の2年間はテストを実行しました。2年後には、支援先の企業にもテストのノウハウがたまり自走できるようになったため、現場への支援を終了しました。このように、時間を短縮したいときや、自社で足らない部分を補いたいときは、専門家に依頼するのも悪くない戦略だと思います。

c. トレーニングを実施する

 テストプロセス改善では、プロセスの定義、フォーマット、マニュアルなど準備する作業が多く発生します。そのため、ステークホルダー(特に現場)へのトレーニングまで気が回らなかったり、手が回らなかったりしがちです。

 しかし、十分なトレーニングを実施しないと、新しいプロセスが定着しなかったり、きちんとマニュアル通りにやらなかったりと、なかなか効果が出ないことになります。また、トレーニングは、1回で全てを理解してもらえることはまれなので、少しやりすぎと思うくらいがちょうど良いです。加えて、アフターフォローや相談窓口などの仕組みも整えておくと、新しいプロセスへの移行がスムーズになります。

 「最初が肝心」という言葉がありますが、最初にこけるとその後もうまくいきません。人材育成の第一人者である東京大学准教授の中原淳氏が、移行期におけるステークホルダーの精神状態を著書『フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術』内で以下のように述べています。

 仕事における役割が変わることを人材開発の用語で「トランジション (Transition:移行期)」といいます。このトランジションがあった直後というのは精神的に不安定になる一方、外からの声を受け入れて変わりやすいときでもあります。

 つまり、テストプロセス改善を実際に適用した直後は、人材開発におけるトランジションにあたり、ステークホルダーが最も外からの声を受け入れて変わりやすい時期になります。逆に言うと、このトランジション期を逃すと変わりづらくなります。そのため、ステークホルダーにしっかりとトレーニングを実施して、トランジション期に備えましょう。

2. 「テスト作業が増加する」を低減するヒント

 テストプロセス改善をすると、今までやっていなかった作業をすることになるので、どうしてもテスト作業が増加してしまいます。フロントローディングの観点やトレーサビリティの観点などから必要な作業ではありますが、できることなら最小限の増加で済ませたいものです。そこで、筆者なりのテスト作業の増加を最小限にするためのヒントを以下に3つ挙げます。

  • a. 段階的に適用する
  • b. 捨てる覚悟を持つ
  • c. ツールを利用する

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

a. 段階的に適用する

 テストプロセス改善には、「全てを一新するやり方」と「今のプロセスを活かしつつ改善するやり方」の2種類があります。今のプロセスでは期待する成果が上げられないと判断した場合は「プロセスの一新」となり、ある程度のプロセスが確立している企業は後者の「今のプロセスを活かしつつの改善」になることが多くなります。

 「全てを一新」する場合は、現在のプロセスを断ち切るために、一気に全部を変更したほうが良いようです。しかし、「今のプロセスを活かす改善」の場合は、最も費用対効果の高い3つ、多くても5つずつの改善を段階的に適用するやり方が、筆者の経験上、成功確率が上がります。

 なぜ、今のプロセスを活かす場合は、段階的に改善したほうが良いのかと言うと、理由は3つあると考えています。1つ目は、現場の混乱を防ぐためです。あまり多くのことを変えようとすると、覚えることがたくさんあり現場が混乱します。ここで参考になるのが、2001年に、アメリカのミズーリ大学の心理学者ネルソン・コーワン教授が発表した「マジカルナンバー4」という論文です。論文の内容は、「人間が短期記憶で保持できる情報の数は4±1である」というものでした。

 つまり、人間が短期記憶できる情報は、3~5つであるようです(蛇足ですが、2001年以前はマジックナンバー7±2と言われていました)。よって、まず3~5つプロセスを改善します。そして、その新しいプロセスが定着したら、次の3~5つのプロセスを改善することを繰り返すというやり方が、現場の定着の観点で良さそうです。

 2つ目は、プロセス改善の効果を見極めやすいからです。テストプロセス改善をする中で、効果のある改善と効果のない改善が出てきます。効果のない改善は、さらなる改善の対象になります。しかし、あまり多くのことを一度に改善してしまうと、何に効果があり、何に効果がなかったのか分からなくなってしまいます。よって、改善する箇所を絞り、効果を確かめながら進めるのが良いと考えます。

 3つ目は、テストプロセス改善の勢いをつけるためです。テストプロセス改善の効果が実感できれば、ステークホルダーの気持ちが前向きになります。最も費用対効果の高い改善に絞ればスピーディーに適用できますし、成功の確率が上がります。小さくても良いので、まずは成功体験を積むことが重要だと考えます。

b. 捨てる覚悟を持つ

 先に述べましたが、プロセスを追加するのは比較的容易です。しかし、プロセスを減らすには勇気が必要です。ついつい、安全策を取って、「あまり効果がなさそうだけど、何かで使われている可能性もあるし、念のために残しておこう」という判断になりがちです。

 そうなると、どんどんやらなくてはいけない作業が増えていき、効果のあまりないプロセスが増えていきます。また、軽微な保守開発などにも、フルパッケージで適用してしまい過剰プロセスになってしまいます。よって、プロセスは必要最低限になるようにし、常に捨てられるプロセスはないか意識することが大事です。

 「なんだ。意識するだけか!」と思われるかもしれませんが、この意識することが実は非常に重要だったりします。人の脳には網様体賦活系(RAS)というフィルターがあり、意識したものだけを認識するという機能があります(カクテルパーティー効果とも言います)。

 逆をいうと、意識していないものは認識することができません。よって、必要最小限のプロセスを常に意識して、不要なプロセスはないかアンテナを張っておくことが重要になります。経験を積むに従いアンテナの精度も良くなり、不要なプロセスを見ると、そこだけ浮かび上がって見えるようになってきます。

c. ツールを利用する

 テストプロセス改善をすると、どうしても実施しなければいけない作業が増えます。その影響を最小限にするためにも、省力化できるところは省力化したほうが良いです。最近は、省力化を助けるツールが多くあります。よって、省力化の1つの方法として、ツールの利用はとても有効です。

 JSTQB(Japan Software Testing Qualifications Board)が発行している「テスト技術者資格制度 Foundation Level シラバス Version 2018.J03」によると、テスト支援ツールには以下の種類があります(表2)。この中でも、「テストとテストウェアのマネジメントの支援ツール」は、省力化を狙える可能性が高いので、最初に検討するツールになります。

表2:テスト支援ツール (JSTQBのシラバスをもとに筆者が作成)
分類 ツールの種類

テストとテストウェアのマネジメントの支援ツール

  • テストマネジメントツールとアプリケーションライフサイクルマネジメントツール(ALM)
  • 要件マネジメントツール
    (テスト対象へのトレーサビリティなど)
  • 欠陥マネジメントツール
  • 構成管理ツール
  • 継続的インテグレーションツール(D) 
静的テストの支援ツール
  • レビューを支援するツール
  • 静的解析ツール(D) 
テスト設計とテスト実装の
支援ツール
  • テスト設計ツール
  • モデルベースドテストツール
  • テストデータ準備ツール
  • 受け入れテスト駆動開発(ATDD)ツールや
    振る舞い駆動開発(BDD)ツール
  • テスト駆動開発(TDD)ツール(D)
テスト実行と結果記録の
支援ツール
  • テスト実行ツール
    (例えば、リグレッションテストの実行)
  • カバレッジツール
    (例えば、要件カバレッジ、コードカバレッジ(D))
  • テストハーネス(D)
  • ユニットテストフレームワークツール(D)
性能計測と動的解析の
支援ツール
  • 性能テストツール
  • モニタリングツール
  • 動的解析ツール(D)
特定のテストに対する
支援ツール
  • データ品質の評価
  • データのコンバージョンとマイグレーション
  • 使用性テスト
  • アクセシビリティテスト
  • ローカライゼーションテスト
  • セキュリティテスト
  • 移植性テスト
    (例えば、複数のサポート対象プラットフォームにまたがるソフトウェアのテスト)

 ※(D):一般的にテスト担当者より開発担当者に効果の高いツール

3. 「ステークホルダーの理解を得難い」を低減するヒント

 現在、テストプロセス改善の情報や事例は、非常に少なく、一般的にはまだまだ知られていません。よって、ステークホルダーの理解を得難い状況と言えると思います。そこで、筆者なりのステークホルダーの理解を得るためのヒントを3つ挙げます。

  • a. トップダウンで実施する
  • b. 選抜チームで先行実施する
  • c. 地道に説明会を開催する

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

a. トップダウンで実施する

 人の習慣にも、慣性の法則のようなものが働き、今までと同じ行動をし続けようとします(一貫性の法則と言います)。それを変化させるには、大きな力が必要になります。それは、危機感であったり、変わりたいという意思であったりします。内部から自発的に発生するのが一番ですが、そればかりに頼るわけにはいきません。そこで、重要になってくるのが、トップの強いリーダーシップです。

 トップが、「絶対にテストプロセス改善を成功させる」という強い意志を持ち、現場に強いメッセージを発信することで、飛躍的に成功の確率があがります。テストプロセス改善のモデルベースドアプローチをトップダウンアプローチとも言いましたが、テストプロセス改善はトップダウンで実施する必要があります。逆を言うと、トップのコミットメントが弱いと成功確率も低くなってしまいます。

b. 選抜チームで先行実施する

 「百聞は一見に如かず」ということわざがありますが、組織内で成功事例があるのとないのとでは、全く説得力が違ってきます。よって、組織全体に新しいプロセスを適用する前に、選抜チームを編成し、成功事例を作るのは良い方法です。

 組織の中には、「現状に危機感を持ち、変わらないといけない」と思っているメンバーは少なからずいるものです(市場バグが多発しているなど危機的な状態のときは特に)。そのようなメンバーは、テストプロセス改善を前向きに捉えている場合が多いです。よって、選抜チームは、そのようなメンバーから選ぶと良いでしょう。

c. 地道に説明会を開催する

 先にグラハムの法則「あなたが何をしているか知らない人は、何もしていないと思うものだ」を紹介しましたが、ステークホルダー(トップ、テストプロセス改善チーム、開発メンバー、テストメンバーなど)があなたのしていることを知っている状態にしないといけません。

 そのために、計画や現状報告など、逐一報告したり、地道に説明会を開いたりする必要があります。資料の準備などに時間がかかり一見遠回りのように感じますが、急がば回れということわざがあります。地道な説明会が、ステークホルダーの理解につながり、結局は成功の近道になります。

まとめ(次回予告)

 第2回では、テストプロセス改善のメリットと課題を考察した後、テストプロセス改善の課題を低減するためのヒントを説明しました。それらをまとめると、表3と表4になります。テストプロセス改善する際の参考にしていただけたらと思います。

表3:テストプロセス改善のメリットと課題
No メリット 課題
1 市場バグを削減できる 効果が出るまでに時間がかかる
2 相対的にコストが安くなる テスト作業が増加する
3 メンバーのスキルが向上する ステークホルダーの理解を得難い
表4:テストプロセス改善の課題と低減のヒント
No 課題 低減のヒント
1 効果が出るまでに時間がかかる
a. 自前主義をやめる
b. 専門家に依頼する
c. トレーニングを実施する
2 テスト作業が増加する
a. 段階的に適用する
b. 捨てる覚悟を持つ
c. ツールを利用する
3 ステークホルダーの理解を得難い a. トップダウンで実施する
b. 選抜チームで先行実施する
c. 地道に説明会を開催する

 次回は、これからテストプロセス改善を実際にやってみたいと思う読者のために、バルテスで行っているテストプロセス改善のやり方を事例と共に紹介します。

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

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
「テストプロセス改善」をしてバグを削減しよう連載記事一覧

もっと読む

この記事の著者

高木 陽平(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」など、さまざまなカンファレンスを企画・運営しています。

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

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

メールバックナンバー