開催日時 | 開始日: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月19日(金) 9:20~17:00 終了日:2012年10月20日(土) 9:30~17:00 |
会場 | 日本科学技術連盟・東高円寺ビル |
講師名・所属 | 飯塚 悦功講師 ・金子 龍三講師 |
レポーター | 奥尾 佳行 (㈱コスモコンピュータセンター) |
アジェンダ (プログラム骨子) |
|
出席者は、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のケースで説明された。そこでは、問題解決の重要性の認識不足、問題の認識・理解、発生状況の把握不足、問題の発生原因の解明不足、対策の不備にグルーピングされ説明された。印象に残った言葉としては
ただ単に目の前の問題を解決するのではなく、その経験を将来に生かすために本質的な問題に目を向けることが重要。そのためにも、以下2点を今後の業務に役立てたい。
|
② |
原因分析の基本技術
問題解決は、状況把握、原因構造解明、対策検討の3つのフェーズから成り立ち基本的な方法の説明があった。特に原因構造解明においては、問題の事象が発生した直接的な要因のみならず、発生のメカニズムを解明して、組織やマネジメントレベルの構造的な問題へも踏み込みたいと感じた。その解明の方法としては、根本原因分析(RCA)という手法があり、ただの原因究明に終わると再発防止策を立てても除去する原因が狭いため類似の問題が再発する。その為に「根本原因」を解明する必要があるとのことで同感した。RCAについては、ただやみくもに広く深く分析しても時間がかかり無駄な作業が発生するので、モデル(処理フロー、業務フロー)や仮説を持つと良いとされている。また、あまり真面目にやりすぎると本来の趣旨とは異なる方向に進んでしまう等の弊害もあるらしい。根本原因分析のねらいは、「学習する組織」のすすめにある。根本原因分析(RCA)とは、失敗の研究によって、起きた問題の発生構造の全容を知り、現実的な策を講じて類似の問題の再発防止・未然防止を実現する事を通じて、組織のマネジメントレベルを上げる組織的な活動の基盤となる考え方であり方法論であるとの話があり、弊社も同様な趣旨でトラブル部会を毎月開催しているので、あらためてその目的・必要性について認識した。 |
③ |
構造モデル
弊社でも、再発防止・未然防止の原因分析を実施している。 |
⑤ |
プロセスネットワークモデルを用いた原因分析法
私も、問題が発生した時に、なぜなぜと聞かれると、本当に正しく答えられていたのか?その時の原因が、本当の真の原因なのか、悩むことがある。また、今までの原因分析として、QC活動の手法にある特性要因図を用いて解析していたが整理はしやすいが、どうしても多数意見で決定してしまう傾向があり、本来の結果とずれてしまう場合がある。 |
⑦ |
事例研究・質疑応答
受講者からの提出された事例をもとに講師が掛け合いで回答する方式で、とても身近に感じることができた。弊社以上に安全・原因に対する組織がしっかりしていると思った。今回モニタとして出席し、改めて問題・原因について勉強できた。又、構造化モデルをはじめ、分析の大切さを深く実感するとともに、正直、その重要さに驚いた。 |
開催日 | 開始日:2013年11月27日(水) 終了日:2013年11月28日(木) |
会場 | 日本科学技術連盟・東高円寺ビル |
講師名・所属 | 清水吉男 氏(システムクリエイツ 代表取締役) |
レポーター | 柴田 康広(日本プロセス株式会社) |
プログラム |
|
セミナー内容 | |||||||||||
日時 | 科目 | 指導講師 | |||||||||
11月27日(水) | 9:50~10:00 | 事務連絡 | 清水 吉男 | ||||||||
10:00~12:30 |
|
||||||||||
12:30~13:30 | 昼食休憩 | ||||||||||
13:30~17:30 |
|
||||||||||
11月28日(木) | 9:30~12:30 |
|
|||||||||
12:30~13:30 | 昼食休憩 | ||||||||||
13:30~17:00 |
|
はじめに
XDDPについて、殆ど知らない、もしくは完全に誤解している状態であったということを、本セミナーを受講して感じました。 |
|
1. |
混乱する派生開発
XDDPとは、eXtreme Derivative Development Processの略で、派生開発に特化した開発手法です。 |
2. |
プロセス改善の意義と現状
当節では、なぜプロセスを改善するのか?プロセス改善のあり方とは?ということを学習します。 |
3. |
派生開発におけるプロセス改善の意義
当節では、派生開発でのプロセスを改善する重要性とは?XDDPを導入するとどのような効果が出るか?を学習します。 |
4. |
XDDPの復習
当節では、XDDPとは何か?について復習します。当セミナーは、前提として「ソフトウェア品質部門のためのXDDP入門コース」を受講することを推奨しています。そのため、復習となっています。 |
5. |
USDMの効果を実感してみよう
当節では、追加機能要求仕様書と変更要求仕様書のサンプルから、演習として仕様書の不足点の検出などを行います。 |
6. |
派生開発におけるプロセスの保証
当説では、DFDとPFDの違いとは?PFDをどうやって書くか?について学習します。 |
7. |
PFDにおけるプロセスの評価ポイント
当節では、PFDの読み方を学習します。 |
8. |
XDDPプロセスを設計してみよう
当節では、実際に演習課題からPC上でPFDを作成する演習を行います。 |
最後に
本セミナーで最も印象に残ったのは、PFDについての書き方/考え方でした。と言うのは、私はXDDPに関する書籍を読んだことがありましたが、XDDPの重要な点はUSDMであると解釈していました。 |
開催日時 | 開始日:2012年08月22日(水) 09:20~17:30 終了日:2012年08月24日(金) 09:30~17:30 |
会場 | 日本科学技術連盟・東高円寺ビル |
講師名・所属 | 小山 竜治講師 (富士ゼロックスアドバンストテクノロジー株式会社) 山崎 崇講師 (トレンドマイクロ株式会社) 松木 晋祐講師 (株式会社ACCESS) |
レポーター | 浜野 晃久 (株式会社コスモコンピュータセンタ) |
アジェンダ (プログラム骨子) |
|
セミナー内容 | ||||||||
日時 | 科目 | 指導講師 | ||||||
8月22日(水) | 9:20~9:40 | 事務連絡 | 日科技連・事務局 | |||||
9:40~12:25 |
|
小山 竜治 山崎 崇 松木 晋祐 |
||||||
12:25~13:25 | 昼食休憩 | |||||||
13:25~15:25 |
|
|||||||
15:35~17:20 |
|
|||||||
8月23日(木) | 9:30~12:30 |
(1日目の振り返りと2日目の構成)
|
||||||
12:30~13:30 | 昼食休憩 | |||||||
13:30~17:30 |
|
|||||||
8月24日(金) | 9:30~12:15 |
(2日目の振り返りと3日目の構成)
|
||||||
12:15~13:15 | 昼食休憩 | |||||||
13:15~17:20 |
|
JSTQB(JapanSoftwareTestingQualificationBoard)とは、日本での非営利団体のソフトウェア技術者の認定運営を行う団体であることの説明がありました。
以前、海外でシステム関連の仕事をしていた際、名刺に"ISTQB"の肩書が入った名刺(相手は中東の方やインドの方)を数回見たことがあり、何の略称なのかと思っておりました。
コース説明を受けて納得しました。テストについて一通りのナレッジを持っていますという証明で、ISTQBの下部組織がJSTQBがあった事を話を伺い理解しました。世界的にも一般的に認められていて、確かに彼等はテストに関しては色々な"引出し"を持っていて、プロジェクトの組織の一部迄も提案を行って貰ったことを改めて思い出しました。
1. |
テストの基礎 (小山講師)
そもそも、ソフトウェアのテストとは何故必要なのか?から始まり、出荷後のソフトウェアの欠陥・故障がもたらす損失例を上げながら、その原因/要素を少しでも減らす為にテストは不可欠である事を当節では学びます。 |
2. |
ソフトウェアライフサイクルを通じてのテスト (山崎講師)
当節ではソフトウェアの代表的なモデルのV字モデル各過程(工程)をテンプレートとしてテストの各々の活動を管理可能な単位に区切ったテストレベル(コンポーネント、統合、システム、受入等)との関わり合いの解説、及び押えておく必要がある項目(テスト対象、責任割当等)についての学習になります。 |
3. |
静的技法 (松木講師)
通常動的テストはどのようなプロジェクトでも実施されていると思いますが、意外と軽んじられているが為に、下流工程で矛盾が沢山発見されて指戻しになる静的技法(所謂レビュー)について学びます。ソフトウェア成果物の品質を確認する手段としても重要視されています。 |
4. |
テスト設計技法 (山崎講師)
当節では実際どのようなテストケースを作成すれば良いかについての解説と演習になります。 |
5. |
テストのマネジメント (小山講師)
当節は開発と完全に独立したテストチームがある場合のテストの重要性や利点、欠点、同チームの構成、担当者の作業、リーダの役割を学習します。 |
6. |
テスト支援ツール (松木講師)
ウォーターフロー開発(ソフトウェア)において各工程でテストを行いますが、それぞれの工程で必要とされるツールも異なります。テスト設計自体、テストの実行自体、静的テスト(コーディング規約違反等)等を行う際、工数を抑える為にも有益なツールが講師から話されます。全てフリ―ウェアなので要件が合致する場合、明日から直ぐ検証を行いプロジェクト等で有意性が認められれば、メンバが使用することになります。私の勤務先でも享受頂いたテスト実行ツールを社内打合時に紹介したところ有意性が認められ、今では社内で広く使われるようになったものがあります。当節については体制等に全く関係無く社内に直ぐフィードバック可能な内容なので、是非皆様も受講される事を御勧めします。 |
最後に
講義は、「資格試験対応」という側面も併せ持つ為、用語に関しては直訳で日本語に無理矢理直している箇所も見られ、英語の原文では何と記載されているのだろうと思った箇所も少しありました。 |
SQiPとは
セミナー
研究会
シンポジウム
資格試験
国際会議
ニュース
コミュニティ
アーカイブ
調査・研究
SQuBOK®
その他