日科技連ホームページへ
SQiP研究会
SQiP研究会とはサイトマップお問い合わせ
ホーム > セミナー-セミナー受講レポート
セミナー受講レポート
(順不同、社名は参加時のものを記載)

実践!ソフトウェア品質向上のための原因分析セミナー

レポート執筆者:株式会社コスモコンピュータセンター 奥尾 佳行 様

JSTQB認定ソフトウェアテスト技術者-Foundation Levelトレーニングコース

レポート執筆者:株式会社コスモコンピュータセンタ 浜野 晃久 様


ソフトウェア品質技術者初級セミナー
― 「ソフトウェア品質技術者資格認定制度(JCSQE)」対応 ―
作成日:2012年10月18日
開催日時 開始日:2012年10月9日(火) 9:20~17:30
終了日:2012年10月10日(水) 9:20~17:30
会場 日本科学技術連盟・東高円寺ビル
セミナー名 ソフトウェア品質技術者初級セミナー
レポーター 中井しおり (NTTデータソフィア株式会社)
アジェンダ
(プログラム骨子)
*SQuBOKガイドに基づいたソフトウェア品質技術を、
概論 ⇒ レビュー技法 ⇒ テスト技法 ⇒ メトリクス・品質分析・評価 ⇒ 再発防止
の順に、演習を交えながら学習する。
セミナーレポート

10月9~10日の2日間、「ソフトウェア品質技術者 初級セミナー」に参加させて頂きました。
セミナーは、以下のような構成になっており、概論から始まって、システム開発作業の流れに沿ったものでしたので、順を追って無理なく理解することができました。

セミナー内容
日時 科目 指導講師
10月9日(火) 9:20~9:30 事務連絡 日科技連・事務局
9:30~10:45 ソフトウェア品質マネジメント概論 保田 勝通
10:55~14:25
(昼食休憩 12:10~13:10)
レビュー技法 (演習含む) 野中 誠
14:35~17:25 テスト技法 (演習含む) 鈴木 三紀夫
10月10日(水) 9:30~12:10 品質メトリクス、品質分析・評価 (演習含む) 鷲崎 弘宜
12:10~13:10 昼食休憩
13:10~16:20 再発防止 (演習含む) 香村 求
16:30~17:30 ステップアップのために
質疑応答、まとめ
香村 求

1日目は、品質とは?という入口から、品質に関する様々な考え方、品質マネジメントや、「欠陥」、その除去について、基本的な定義や分類をご説明頂いたあと、誰もがギクッとするような「絶対に避けたい」欠陥の事例をもとにレビューの技法を、演習も交えて学んでゆきます。事例の選び方が素晴らしく、レビュー経験が豊富な人でも思わず引き込まれる内容です。

テスト技法は、盛り沢山な内容から、はずせないポイントと技法を、要領よく説明して下さいました。
仕事の現場でもテストの洗い出しや検証は、時間もマンパワーも最も必要なところですので、技法を知り、ポイントを押さえてテストケースを作成できれば少しでも効率的なテストができると思います。

2日目の、品質の分析・評価では、何を欠陥とし、どの単位でカウントするか という問題から入り、品質評価の手がかりとなる色々な数値、データを図表化した資料の読み取り方や解釈の仕方を学びました。
一方向からの見方では見落としがちな問題を、複数の指標や図表を用いて炙り出す技法は、品質「保証」に欠かせないものであると感じました。続いての再発防止では、バグやトラブルの真の原因を徹底的に分析し記録して次に生かす技法、その分析をもとにプロセスそのものを改善する技法について学びました。その後の、ステップアップのための講義と併せて、講師の先生ご自身の豊富な経験から来る事例がちりばめられた、興味深い内容です。

ソフトウェアに関係した仕事をする者にとって、ソフトウェアという目に見えないものの品質を いかにして高め、維持してゆくかは、最大の課題であり、ほとんど全てのシステム担当者はこの課題と日々戦い続けていると言っても過言ではないと思います。
講義の中でも何度か引用された「銀の弾丸はない」「王道はない。しかし道はある。」という言葉。
…この険しい「道」のガイドブックとなり、道標ともなるのが、今回のセミナーであったと思います。
「道」を歩くのは自分自身ですが、何も持たずに勘と経験だけで進むのと、正確なガイドブックを持って道標のある道を進むのとでは、危険の度合いも進める距離も全然違って来るはずです。

今回のセミナーは「初級」のコースですので、最も基本的なポイントを、判りやすい事例を交えて、教えて頂きました。講義の中で紹介されたインターネットから参照できる資料も、セミナー終了後に検索してみたところ、講義では取り上げ切れなかった各社の事例など、とても具体的で、仕事の現場に役立つ内容が数多く含まれていました。

今回教わった内容から、「この部分はさらに深く学んでみたい」、「この部分に初めて知る内容が多かった」とか、「この本を読んでみたい」という思いも湧いてきて、このセミナーに参加しただけで終わらせず、興味を持ったところだけでも更に関連図書を読み進むとか、せっかくの「資格対応コース」であることを生かして、「ソフトウェア品質技術者」試験で自分の理解度を確認したい といった欲が湧いてくるセミナーでもありました。そこまでフルコース味わう(?)ことで、セミナー参加の効果は飛躍的に広がると思います。

もうひとつ、このような社外のセミナーが役立つのは、知識を体系化することの他に、「普段とは違う同業者に会える」という点です。システムに関係する仕事をする、同じプロフェッショナルでありながら、自分とは異なる経験や知識を持った人と共に演習課題を解いてゆく、その過程での意見交換や思いがけない視点を知ることで、目からうろこが落ちるような経験をすることができます。
今回のセミナーでも、品質技術というテーマがソフトウェア全体に関わるものであるため、組込み系ソフトを開発しておられる方、様々な企業のシステムを担当しておられる方、現場で開発に従事する方、管理部門で品質保証を仕事にする方など、さまざまな立場からの意見が聞け、よい刺激となりました。

私自身は、かなり長い間、開発現場におり、最近 品質や生産性を扱う管理部門に異動したため、現場の苦しみ・大変さを知りつつ、本来ならこうすべき といった理論面もこのごろ漸く見えて来たところです。
今まさに開発現場のまっ只中で品質向上を模索している方には、険しき「道」のガイドとして、また、管理部門で組織単位の品質管理や品質保証を担当する方には経験や知識の体系化のために、いずれの立場の方にも、このセミナーをお勧めします。

実践!ソフトウェア品質向上のための原因分析セミナー
作成日:2012年10月30日
開催日時 開始日:2012年10月19日(金) 9:20~17:00
終了日:2012年10月20日(土) 9:30~17:00
会場 日本科学技術連盟・東高円寺ビル
講師名・所属 飯塚 悦功講師 ・金子 龍三講師
レポーター 奥尾 佳行 (㈱コスモコンピュータセンター)
アジェンダ
(プログラム骨子)
  1. 問題解決の反面教師
  2. 原因分析の基本技術
  3. 構造モデル
  4. 構造モデルを用いた原因分析法の事例
  5. プロセスネットワークモデルを用いた原因分析法(PNA法) 6.原因分析のQ&A
セミナーレポート

出席者は、30代~40代の男女26名であり、マネジャクラスと将来マネジャになるだろうと思われる人が参加していた。数名は、品質保証管理の部署に在籍しているように見えた。品質管理学,経営学,心理学,社会学,文化人類学,行動科学,機械学,制御工学,電子工学,電気工学,ソフトウエア工学,システム工学等を熟読している2名の講師による原因分析セミナーであった。”構造化モデル” と マネジメントは知識ではなく ”技術” が基本コンセプト。

資料

  • 原因分析 ~構造モデルベース分析術~ (書籍)
  • 実践!ソフトウエア品質向上のための原因分析セミナー 構造モデル補足説明資料
セミナー内容
日時 科目 指導講師
10月19日(金) 9:20~9:30 事務連絡 日科技連・事務局
9:30~12:00 ①問題解決の反面教師
②原因分析の基本技術
飯塚 悦功
12:00~13:00 昼食休憩
13:00~17:00 ②原因分析の基本技術
③構造モデル
金子 龍三
10月20日(土) 9:30~12:00 ④構造モデルを用いた原因分析法の事例
⑤プロセスネットワークモデルを用いた原因分析法(PNA法)
⑥原因分析のQ&A
金子 龍三
12:00~13:00 昼食休憩
13:00~16:30 ⑦事例研究・質疑応答 金子 龍三
飯塚 悦功
16:30~17:00 ⑧実践例を用いてセミナー終了後のフォローアップ 飯塚 悦功

問題解決の反面教師

これまで広範囲にわたって問題解決の相談に乗ってきた講師の経験から、問題解決の落とし穴にはまっていると感じ続けてきていると言い、その例を挙げて症状を説明し、なぜそれがよいことではないのか。どのような対処法があるのかを17のケースで説明された。そこでは、問題解決の重要性の認識不足、問題の認識・理解、発生状況の把握不足、問題の発生原因の解明不足、対策の不備にグルーピングされ説明された。印象に残った言葉としては

  • 我々は様々な企画・計画をし目的を達成しようと行動する。そして、その時事件が発生する。
  • 事件は多くの場合、起こるべくして起きている。
  • 1件の事件は、運が悪くたまたま起きたと思われがちだが、多くはそうでない。「仕事に対する考え方」、「仕事の進め方」、「目的達成に必要な固有の知識・技術・技能」など、本質に係わるところに何らかの問題があって、その結果として事件が起きる。1つの事件が起きるということのかげには何件もの起きずに済んでいた事件が潜在していると考えるべきである。

ただ単に目の前の問題を解決するのではなく、その経験を将来に生かすために本質的な問題に目を向けることが重要。そのためにも、以下2点を今後の業務に役立てたい。

  1. 問題を問題として感じる感受性・意識を持つこと
  2. 問題発生の構造を明らかにすること
 
原因分析の基本技術

問題解決は、状況把握、原因構造解明、対策検討の3つのフェーズから成り立ち基本的な方法の説明があった。特に原因構造解明においては、問題の事象が発生した直接的な要因のみならず、発生のメカニズムを解明して、組織やマネジメントレベルの構造的な問題へも踏み込みたいと感じた。その解明の方法としては、根本原因分析(RCA)という手法があり、ただの原因究明に終わると再発防止策を立てても除去する原因が狭いため類似の問題が再発する。その為に「根本原因」を解明する必要があるとのことで同感した。RCAについては、ただやみくもに広く深く分析しても時間がかかり無駄な作業が発生するので、モデル(処理フロー、業務フロー)や仮説を持つと良いとされている。また、あまり真面目にやりすぎると本来の趣旨とは異なる方向に進んでしまう等の弊害もあるらしい。根本原因分析のねらいは、「学習する組織」のすすめにある。根本原因分析(RCA)とは、失敗の研究によって、起きた問題の発生構造の全容を知り、現実的な策を講じて類似の問題の再発防止・未然防止を実現する事を通じて、組織のマネジメントレベルを上げる組織的な活動の基盤となる考え方であり方法論であるとの話があり、弊社も同様な趣旨でトラブル部会を毎月開催しているので、あらためてその目的・必要性について認識した。

 
構造モデル

弊社でも、再発防止・未然防止の原因分析を実施している。
しかし、ノウハウはシステムを熟知した経験者(技術管理者)によって、蓄積しているだけの情報収集BOXを活用する単純化した仕組みである。しかし、この構造モデルは、業務遂行を行う経験で得られたプロセスごとの経験値を組織の知的財産として、蓄積し活用するだけでなく、その型に無理やり合わせず、ニーズや期待に適合しない場合は、構造仮設を立てて、科学・工学的に検証していく、ある意味まだよくわからない事実を合理的に分析するため、経験者(技術管理者)に頼るだけでない。弊社も適用しやすく、今後の課題として取り上げていきたい。

 
プロセスネットワークモデルを用いた原因分析法

私も、問題が発生した時に、なぜなぜと聞かれると、本当に正しく答えられていたのか?その時の原因が、本当の真の原因なのか、悩むことがある。また、今までの原因分析として、QC活動の手法にある特性要因図を用いて解析していたが整理はしやすいが、どうしても多数意見で決定してしまう傾向があり、本来の結果とずれてしまう場合がある。
しかし、PNA法は、Step毎に順序よくながれよく実施するだけでなく、Stepごとに原因分析を行い、どの部分に原因があるのかを知れる。分析全体像の把握が容易にできるため、どの段階からの対応策も見つけやすい。正しくその手法を理解するとともにトレーニングすることにより、本来の真の原因が解析できる。

 
事例研究・質疑応答

受講者からの提出された事例をもとに講師が掛け合いで回答する方式で、とても身近に感じることができた。弊社以上に安全・原因に対する組織がしっかりしていると思った。今回モニタとして出席し、改めて問題・原因について勉強できた。又、構造化モデルをはじめ、分析の大切さを深く実感するとともに、正直、その重要さに驚いた。
実現する為には、広い視野をもって、問題・原因についての高い認識や、身につける為のトレーニングが必要であり、中途半端な気持ちでは、難しいと感じた。弊社にとっての、問題・原因意識について、ある一定のレベルは必要であり、今後につなげていきたい。
私の思い込みかもしれないが、飯塚講師,金子講師とも、若い世代に何かを伝えたいという強い気持ちを感じた。それは、現代にとって、あるいは今の日本にとって、欠けている原因分析や品質保証の重要性をもっと構造化し、技術力を身につける必要であるという”メッセージ”であり、私自身、もう一度考えていきたいと思った。
本当に充実した2日間だった。ありがとうございました。また多くのマネージャに受講をおすすめしたい。

清水吉男のXDDPの導入、活用による開発プロセスの改善セミナー
-XDDPを活用した品質と生産性の劇的改善のノウハウ-
作成日:2013年11月28日
開催日 開始日:2013年11月27日(水)
終了日:2013年11月28日(木)
会場 日本科学技術連盟・東高円寺ビル
講師名・所属 清水吉男 氏(システムクリエイツ 代表取締役)
レポーター 柴田 康広(日本プロセス株式会社)
プログラム
  1. 混乱する派生開発
  2. プロセス改善の意味と現状
  3. 派生開発におけるプロセス改善の意義
  4. XDDPの復習
  5. USDMの効果を実感してみよう(演習)
  6. 派生開発におけるプロセスの保証
  7. PFDによるプロセスの評価ポイント
  8. PDFとDFDの見比べ(演習)
  9. XDDPプロセスを設計してみよう(演習1、演習2)
セミナーレポート
セミナー内容
日時 科目 指導講師
11月27日(水) 9:50~10:00 事務連絡 清水 吉男
10:00~12:30
1. 混乱する派生開発
派生開発の特徴とプロセスの実態
2. プロセス改善の意味と現状
3. 派生開発におけるプロセス改善の意義
組織標準のあり方/派生開発プロセス改善の効果
12:30~13:30 昼食休憩
13:30~17:30
4. XDDP の復習
標準的派生開発アプローチ/追加機能要求仕様/変更要求仕様を含む3点セット
5. USDM の効果を実感してみよう(演習)
11月28日(木) 9:30~12:30
6. 派生開発におけるプロセスの保証
7. PFD によるプロセスの保証
PFDで何がわかるのか?
12:30~13:30 昼食休憩
13:30~17:00
8. PFD と DFD の見比べ(演習)
改善点?代案は?
9. XDDP プロセスを設計してみよう(演習1、演習2)
PFD を使って XDDP によるプロセスを設計する

はじめに

XDDPについて、殆ど知らない、もしくは完全に誤解している状態であったということを、本セミナーを受講して感じました。
当社は、業務システムから組み込みシステムまで、様々な規模、制約の中で仕事を行っています。その中で、は製品開発も求められていますが、うまく行っている現場が少ないのが現実です。
私のプロジェクトでも派生品の開発が求められ、そのための開発手法としてXDDPを選択しプロジェクトを進めてきました。しかし、どうしても上手くいかない。そこで、XDDPの発案者である清水さんから直接話を聞く機会を持てればと思い、本セミナーを受講しました。

 
1.
混乱する派生開発

XDDPとは、eXtreme Derivative Development Processの略で、派生開発に特化した開発手法です。
当節では、派生開発とは何か?保守開発との違いは?ということを学習します。
派生開発では、機能の違う様々な製品に対して機能の変更(保守開発の範囲)と新規機能の追加(新規開発の範囲)を同時に行っていく必要があります。その中で、派生開発にはどのような問題があり、制約を受けながら作業を進めなければならないのかということを学習しました。
特に印象に残ったのが、「派生開発は部分理解の制約を受ける」という点です。私も不具合の分析や、プロジェクトの反省会の時に、「全体を理解せず進めてしまった」ということが多々あります。しかし、「全体を理解」するために必要な時間を捻出できるほど、プロジェクトの期間/予算に余裕はありません。であれば、その制約の中で、どのようにすれば開発を進めることができるのかということを考える必要があります。

 
2.
プロセス改善の意義と現状

当節では、なぜプロセスを改善するのか?プロセス改善のあり方とは?ということを学習します。
多くの企業は、標準プロセスを策定し運用しています。そして、標準プロセスは過去の経験が反映され、あらゆる不測の事態を防ぐ万能のプロセスになっています。しかし、本来あるべき標準プロセスとはどうあるべきか。それを、どうやって改善していくのかということを学習しました。

 
3.
派生開発におけるプロセス改善の意義

当節では、派生開発でのプロセスを改善する重要性とは?XDDPを導入するとどのような効果が出るか?を学習します。
前節でのプロセス改善の意義から、派生開発でプロセス改善を行う意義についてさらに深く学習しました。特に、プロセス改善を行う上で、どのような障壁があり、どのように克服すべきかについて学習しました。

 
4.
XDDPの復習

当節では、XDDPとは何か?について復習します。当セミナーは、前提として「ソフトウェア品質部門のためのXDDP入門コース」を受講することを推奨しています。そのため、復習となっています。
しかし、今回は前セミナーの受講者が少なかったため、多くの時間を割いて丁寧に学習しました。
XDDPは、USDMとPFDという2つの支援の上で成り立っています。ここでは、特にUSDMに重きをおいて学習しました。
私がプロジェクトで適用していた時は、追加機能要求仕様書と変更要求仕様書の違いをうまく理解できず、結果として無理矢理同じような書き方で適用しようとしていました。しかし、なぜ仕様書が分かれているのかという説明を受け、そもそもプロセスが違うのだから、仕様書も違うのだと納得することが出来ました。

 
5.
USDMの効果を実感してみよう

当節では、追加機能要求仕様書と変更要求仕様書のサンプルから、演習として仕様書の不足点の検出などを行います。
比較的理解しやすい、「配送システム」に関するサンプルで演習を行いました。
この演習では、追加機能要求仕様書と変更要求仕様書の書き方よりも、それをどのように読み取るかということを学習しました。すなわち、作成するという観点よりも、作成できることを前提としていかにそれをレビューするかという演習でした。
前提となるプロジェクトやシステムに関する情報がない状態で、情報を読み取る必要が有るため、最初は非常に難しく感じました。しかし、USDMでは変更要求と仕様が明確に記載されているため、記載されている変更内容だけで要求を満たすことができるのか?仕様の見落としがないか?などの観点から見ることが出来ました。

 
6.
派生開発におけるプロセスの保証

当説では、DFDとPFDの違いとは?PFDをどうやって書くか?について学習します。
PFDとは、自分のこれからやろうとしている作業(プロセス)を如何に表現し、設計するかということを学習しました。
特に印象に残った点は、「PFDとは自分のプロセスを自分で設計し、シミュレーションするための道具である」ということでした。ソフトウェアの開発というのは、決してルーチンワークにはなりません。今までは標準作業という枠の中で、無理矢理作業を進めてきました。しかし、PFDを使うことによって自分でプロセスを設計し、シミュレートすることができるということを学習しました。

 
7.
PFDにおけるプロセスの評価ポイント

当節では、PFDの読み方を学習します。
設計したプロセスできちんと実行できるか?無駄な作業が存在しないか?など、PFDから情報をどのように読み取るかについて学習しました。

 
8.
XDDPプロセスを設計してみよう

当節では、実際に演習課題からPC上でPFDを作成する演習を行います。
演習では、「事前調査のプロセス」と「派生開発のプロセス」をPFDで表現する演習を行いました。
実際にPFDを書いてみると、思いの外難しく感じました。また、作成したPFDについてグループディスカッションを行いましたが、各自それぞれの経験の違いから全然違ったPFDが出来上がり、よい学習となりました。

 
最後に

本セミナーで最も印象に残ったのは、PFDについての書き方/考え方でした。と言うのは、私はXDDPに関する書籍を読んだことがありましたが、XDDPの重要な点はUSDMであると解釈していました。
なぜかといえば、USDMに関する書籍は存在しているため情報を入手することができていましたが、PFDについては書籍が存在せず深く理解していなかったためです。
本セミナーを通じて、XDDPとはUSDMとPFDの両方が必要であるということを、学習することが出来ました。また、派生開発以外においても、ソフトウェア開発以外においてもUSDMとPFDを使うことによって、もっと良くしていけることがあるのではないかと感じました。

最後に、本セミナーは品質部門の担当者だけではなく、1名でも部下を持つ人は全員受講すべきセミナーだと思います。開発プロセスの改善は、1名だけが理解していても達成できるものではありません。組織として生き残っていくために、全員が理解し協力して進めていく必要があると感じました。

JSTQB認定ソフトウェアテスト技術者-Foundation Levelトレーニングコース
作成日:2012年11月22日
開催日時 開始日:2012年08月22日(水) 09:20~17:30
終了日:2012年08月24日(金) 09:30~17:30
会場 日本科学技術連盟・東高円寺ビル
講師名・所属 小山 竜治講師 (富士ゼロックスアドバンストテクノロジー株式会社)
山崎 崇講師 (トレンドマイクロ株式会社)
松木 晋祐講師 (株式会社ACCESS)
レポーター 浜野 晃久 (株式会社コスモコンピュータセンタ)
アジェンダ
(プログラム骨子)
  1. テストの基礎
  2. ソフトウェアライフサイクルを通じてのテスト
  3. 静的技法
  4. テスト設計技法
  5. テストのマネジメント
  6. テスト支援ツール
セミナーレポート
セミナー内容
日時 科目 指導講師
8月22日(水) 9:20~9:40 事務連絡 日科技連・事務局
9:40~12:25
1. テストの基礎
小山 竜治
山崎 崇
松木 晋祐
12:25~13:25 昼食休憩
13:25~15:25
2. ソフトウェアライフサイクルを通じてのテスト
15:35~17:20
3. 静的技法
8月23日(木) 9:30~12:30

(1日目の振り返りと2日目の構成)

4. テスト設計技法
12:30~13:30 昼食休憩
13:30~17:30
4. テスト設計技法
8月24日(金) 9:30~12:15

(2日目の振り返りと3日目の構成)

4. テスト設計技法
5. テストのマネジメント
12:15~13:15 昼食休憩
13:15~17:20
5. テストのマネジメント
6. テスト支援ツール

JSTQB(JapanSoftwareTestingQualificationBoard)とは、日本での非営利団体のソフトウェア技術者の認定運営を行う団体であることの説明がありました。

以前、海外でシステム関連の仕事をしていた際、名刺に"ISTQB"の肩書が入った名刺(相手は中東の方やインドの方)を数回見たことがあり、何の略称なのかと思っておりました。
コース説明を受けて納得しました。テストについて一通りのナレッジを持っていますという証明で、ISTQBの下部組織がJSTQBがあった事を話を伺い理解しました。世界的にも一般的に認められていて、確かに彼等はテストに関しては色々な"引出し"を持っていて、プロジェクトの組織の一部迄も提案を行って貰ったことを改めて思い出しました。

1.
テストの基礎 (小山講師)

そもそも、ソフトウェアのテストとは何故必要なのか?から始まり、出荷後のソフトウェアの欠陥・故障がもたらす損失例を上げながら、その原因/要素を少しでも減らす為にテストは不可欠である事を当節では学びます。
ソフトウェアライフサイクルフェーズの各工程でのテストの大きな目的、システムが誕生してから約40年、それに伴いテストの原則も編み出され、あらゆるテストで共通に使えるガイドライン(7つの原則)やテストを実施する際のマインドセットはソフトウェア開発と大きく異なる事、テスト担当者の行動規範について学習します。
特に、講義中の"テストの心理学"については、専門のテスト担当者がいない環境でシステム開発/保守を行う部署で仕事をしている為、イメージ的に掴み辛い内容だったのですが、開発側の立場に立つと"自身の誤り"(プログラム等のロジック誤り)は確かに他メンバから指摘される迄、中々見つける事は難しく、どうしても"破壊的な作業"と思ってしまう(折角作成したのに…)と思ってしまうのも事実です。若し今後、同じような場面に遭遇した場合は"建設的な作業"と捉えるように心掛けたいです。

 
2.
ソフトウェアライフサイクルを通じてのテスト (山崎講師)

当節ではソフトウェアの代表的なモデルのV字モデル各過程(工程)をテンプレートとしてテストの各々の活動を管理可能な単位に区切ったテストレベル(コンポーネント、統合、システム、受入等)との関わり合いの解説、及び押えておく必要がある項目(テスト対象、責任割当等)についての学習になります。
また、特定のテスト目的に焦点を当てる機能・非機能・構造テスト及び変更箇所のテスト(テストタイプ)はどの工程でも使用可能だという事も併せて学びます。
ソフトウェアのバージョンというキーワードでも皆様とも関わりがある保守テストはセキュリティホールの修正パッチ等をシステム変更作業時に実施した方が賢明という事も併せて学びます。
元々当社では会社の端末PCは修正パッチ毎にシステム部門が先に生け贄になっていました。社内公認ソフトの動作確認を行わない限り、セキュリティパッチは渡さない規定になっていた為です。不具合が発生した場合は、関連するソフトウェアを管理する部署が全責任を負うルールになっており、責任部署がセキュリティパッチ配布毎に担当ソフトウェアのテストを行い、セキュリティパッチの水平展開が数週間遅れた事でコンピュータウィルスに侵されるという失敗の後、最新のセキュリティパッチをインストールする事が出来ないという弊害は無くなりました。

 
3.
静的技法 (松木講師)

通常動的テストはどのようなプロジェクトでも実施されていると思いますが、意外と軽んじられているが為に、下流工程で矛盾が沢山発見されて指戻しになる静的技法(所謂レビュー)について学びます。ソフトウェア成果物の品質を確認する手段としても重要視されています。
また、色々なレビューの種類が存在し、特に公式レビューに関しては参加者の役割(モデレータ等)や名称も決まっており、成功させる迄のプロセスも講義では説明があります。
上流の要件定義で曖昧な表現、機能を付加した為、いざコーディングする段階になると"プログラマ"が実現不可、要確認の烙印を押されてプロジェクト遅延を引き起こす代物ですが、出戻工数増加を抑えるためにも時間数は少ないのですが、是非参加頂くと、経験豊富な講師の体験談を交えた講義は静的技法の重要性を再認識出来ると思います。

 
4.
テスト設計技法 (山崎講師)

当節では実際どのようなテストケースを作成すれば良いかについての解説と演習になります。
テスト開発プロセスに於けるテスト分析、テスト設計、テスト実装について流れを掴み、テストベース、テスト条件、テストケース、テスト手順の各ドキュメント(IEEEでも内容の規定がありガイドラインも定められています)テンプレートを各々学習します。また、演習を通し、実際の場面で作成されたドキュメントの抜け(不具合)を考えることで実戦的な場面に応用出来るようにカリキュラムが構成されています。
併せてドキュメントに必要なソフトウェアテストを行うにあたり与える変数等の決定を行う際、必要となるブラックボックス(仕様ベース)に属する同値分割法、境界値分析、デシジョンテーブル、状態遷移テスト等の例を学びます。私は経理システムの開発なので状態遷移テストは全く経験無でしたが、演習と解説により良く理解することが出来ます。(試験勉強をされている方は経験が無い部分も勉強する必要があるので是非受講されることを御勧めします)
また、ソースコードで分岐等を強く意識した構造ベース(ホワイトボックス)テスト技法も続けて学習します。コードカバレッジ、ステートメントカバレッジ等の例が出ておりテストを行う際、どの局面で用いると効果があるか、又ドキュメントに落す際の武器として必要となるナレッジを習得することが出来ます。

 
5.
テストのマネジメント (小山講師)

当節は開発と完全に独立したテストチームがある場合のテストの重要性や利点、欠点、同チームの構成、担当者の作業、リーダの役割を学習します。
また、PMが同チームの守備範囲に入る場合には必須となるテスト計画作業と同見積、進捗モニタリング手法について併せて学習します。
当節のテストチームですが、勤務先では開発を行う際には存在しておらず、開発者がデバッグを行った後 開発メンバを自分が担当した(作成した)以外のプログラムをテストする事で代替したりしたのですが、講義を受けてからは、予算が許すのであれば、納期短縮と出戻工数削減の観点から存在していれば、カットオーバを間に合せる為に無茶をせずに済んだと思い起こしております。

 
6.
テスト支援ツール (松木講師)

ウォーターフロー開発(ソフトウェア)において各工程でテストを行いますが、それぞれの工程で必要とされるツールも異なります。テスト設計自体、テストの実行自体、静的テスト(コーディング規約違反等)等を行う際、工数を抑える為にも有益なツールが講師から話されます。全てフリ―ウェアなので要件が合致する場合、明日から直ぐ検証を行いプロジェクト等で有意性が認められれば、メンバが使用することになります。私の勤務先でも享受頂いたテスト実行ツールを社内打合時に紹介したところ有意性が認められ、今では社内で広く使われるようになったものがあります。当節については体制等に全く関係無く社内に直ぐフィードバック可能な内容なので、是非皆様も受講される事を御勧めします。

 
最後に

講義は、「資格試験対応」という側面も併せ持つ為、用語に関しては直訳で日本語に無理矢理直している箇所も見られ、英語の原文では何と記載されているのだろうと思った箇所も少しありました。
講師の方もシステム開発経験を10年以上お持ちで、システム開発の陥りがちな弱点等"痛い経験"も沢山持っておられると講義中も感じる事が多く、質問をすると的確に返されておられました。また、受験対策という観点からは、講師の方の経験を踏まえて説明頂ける場面もあり、書籍だけに頼って勉強した場合にありがちな"思い込み"を解消して受験することが出来る利点もあります。

戻る
セミナー
ソフトウェア品質管理研究会
ソフトウェア品質知識体系ガイド
 
 
日本科学技術連盟

SQiPは、ソフトウェア品質管理技術・施策の調査・研究・教育を通じて、実践的・実証的な
ソフトウェア品質方法論を確立・普及することにより、ソフトウェア品質の継続的な向上を目指します。

 
 
Copyright© 2015 Union of Japanese Scientists and Engineers. All Rights Reserved.