こんばんは
TEF道メンバーが毎回一人ずつ自分の気になるネタを発表する、
TEF道勉強会の2015年5回目を開催しました！！
お題は上田さんによる「UIテスト自動化の段階的導入」
主にSeleniumのお話しです。さぁ、スタート！！
■はじめに
参加者は上田さん含めて8名で、うち、UIテスト自動化をちょっとでも
試したことのある人は2名。さらにそのうち、うまくいかなかった人は2名。。。
そう、難しいんですよね、UIテストの自動化。
上田さんも過去トライしては失敗してきたそうなんですが、Seleniumを軸にして
段階的にUIテスト自動化の導入を進めることで、手応えを感じているようです。
勉強会では、その経緯や段階についてくわしく説明してくれました！
■背景の確認など
まずは、テスト自動化とは、そしてその問題などの解説から。
そもそも、人間が行うテスト、それもTestingではなくCheckingの
一部を自動化しようというのが目的のはずだけれども、現場を知らない
上司なんかは過度に期待してしまうんですよね。
また、実際にやってみると、スクリプトの保守が大変！といった問題が、
次から次へと出てきて、コストメリットが出ない、と諦めてしまう。。。
そこで、上田さんはテスト自動化を導入していくステップを考えたそうです。
一体どういうことなんでしょうか！？
■Selenium！
で、その説明の前にSeleniumの説明から。詳しくは省略しますが、
当初から現在の二系統に至る歴史や、インストールの方法、使い方などを
デモを交えて詳し～く説明してくれましたので、IDEとWebDriverに対する
敷居はかなり下がりました。思ったより簡単ですね！
■本題へ
そして、段階的に導入のすすめのお話へ。
以下のような段階（上田さんはデザインパターンとも呼んでた）を、
導入目的や状況に応じて選ぶとよいそうです。それぞれの段階の
ポイントや注意点も含めて解説してくれました。
第一段階・・・キャプチャプレイバックツールとしてSelenium IDEを使う。
第二段階・・・簡易テスト自動化ツールとしてSelenium IDEを使う。
ここまでは、今までSeleniumを扱ったことがなくても1～2時間あれば到達できそうです。
Selenium IDEはFirefoxのプラグインで、ブラウザー操作のキャプチャプレイバックと、
簡単なスクリプトの編集機能を持ちます。
単発で、簡単なプロジェクトならこれでも十分使えると思えました。
＃実際に家に帰って試したところ、Firefoxのプラグインをダウンロードして、
＃アドインに登録して、適当にキャプチャ、プレイバックを試すのに10分でできました(^^
第三段階・・・スクリプトの管理を行う。
ここからはWeb Driverが登場。IDEはFirefoxのプラグインのため対象ブラウザーが
Firefoxに限定されてしまうので、プロジェクトがマルチブラウザー対応の場合は
少なくともこの段階の導入が必要になる。
テストコードをガリガリ書く必要があるのでちょっとつらそうに見えたが、
IDEでキャプチャ・編集したケースをスクリプトに出力できるので、それをちょちょいと
調整すればそれなりに動くものが出来上がる。すばらしい。
ただテスト実行してからブラウザーが起動するまでがかなり遅い・・・これは仕方ないですね。
#勉強会でC#/NUnitは？という話が出ましたが、NUnit用にちゃんとエクスポートできました。
第四段階・・・保守運用性を高める。
残念ながらIDEが吐き出すコードは対象や期待値が直接コードに埋め込まれていたりして、
このままでは変更に耐えられません。
上田さんはPageObjectパターンを適用してこの問題に対処しているそうで、
サンプルのコードを紹介してくれました。なるほど、これなら保守する気になります。
第五段階・・・データ・キーワード駆動テスト
テストデータや操作を外部ファイルから読み取るようにして、さらに保守性を高める。
ここまで来れれば、コストメリットが明らかになりそうですね。
これからU/Iテスト自動化を導入しようとする場合の最初の目標にすると良いかな、と感じました。
そしてここから先は上田さんもまだ調査・検証中のようですが、紹介してくれました。
すでに実現に向けて動いているそうです。
第六段階・・・マルチブラウザー・モバイル対応
第七段階・・・Selenium Gridなどで実機テストの分散処理
第八段階・・・JenkinsなどでCI連携
・・・
■最後に＆次回は
U/Iテスト自動化・・・自分も過去導入してうまくいかなかったことがあり、
やっても無駄だという先入観を持ってしまっていました。
でもこうやって、導入目標を明確に分けることで、今できること、
今はまだできなくて良いことがはっきりするので、段階的に進められそうです。
今回感じたのは、ほんとうに、今後はテスト技術者も言語やCIツールの知識が必要になる、
ということ。＃うえださんがJava書いてたのに驚いた(^^;
さらには、良いテストコード書くためには、例えばデザインパターンの知識も必要ですね。
TEF道はプログラマーが多いので、そのうちデザインパターンとかクラス図書く練習とか、勉強しましょうか！！
次回はくっきーさんによる「ペアテスティング」を予定。
では～ by小楠（貴）
情野です。4月の勉強会の内容を報告します。
* 日時 4/27（月）19:00～21:00
* 登壇者 高木さん(@oreshio)
* タイトル リファクタリングとMikadoMethod
* 参加者は１０名弱だったと記憶しています。
* 場所 東京エレクトロン札幌支社 会議室
# 勉強会の内容報告
この日の勉強会のテーマはMikadoMethodでした。
まずはMikadoMethodと関係の深いリファクタリングについて振り返りました。
## リファクタリング
リファクタリングという言葉は開発者の間では一般的な言葉ですが、
開発者は全員リファクタリングをしているかというと、そういうわけではないようです。
まずリファクタリングができない理由について説明がありました。
### リファクタリングができない理由
派生開発の現場にいると「壊れていないものを修理するな」という言葉をよく聞くことがあります。
メンテナンスが困難なコードを下手にリファクタリングし、その結果エンバグしてしまうことを防ぐためです。
この言葉が乱用される現場では、リファクタリングがしにくいこともあるでしょう。
開発プロセスにもリファクタリングができない理由があるということでした。
ウォーターフォール開発は開発工程が最後になりますが、現実にはその後もコードを修正しつづけますよね。
ウォーターフォール開発ではその後の修正のことは考えられてないため、リファクタリングがやりづらいのです。
一方、インクリメンタル開発は開発工程が周期的に行われ、リファクタリングしないと開発がうまくまわらないような仕組みになっています。
高木さんはリファクタリングの動機を
「機能追加しやすい作りである方が、将来の作業のコスト削減になる」
と表現されていました。
将来を見据えたときに、リファクタリングしたほうがよいかどうか考えることになるのですね。
### リファクタリング実施の判断
リファクタリングすべきかどうか、判断するのは簡単ではないですね。
４つの判断要素があるということでした。
* 書き直す規模
* コストとリターン
* 新規か派生か
* 求められる品質
このあと、参加者全員でケーススタディを行いました。
先の４つの条件が異なる３つのケースについてリファクタリングするべきかを全員で議論しました。
リファクタリングすべきかどうか、すぐに全員が合意できるものもあれば、そうでないものもありました。
まとまらないケースがあるのは各参加者の知識と経験が異なるからで、
その知識と経験がリファクタリング実施判断に大きく関わるからだろうと私は考えます。
この議論の中で、プロダクトマネージャに
リファクタリング実施を提案するにはどのようにすべきかという話題が上がりました。
結論はでませんでしたが、
「内部品質がどれだけ悪いかを訴えるのがよい」
「プロダクトマネージャが関心をもつもの（QCDなど）がリファクタリングの前後でどう変化するかを説明するのがよい」
など複数意見があがりました。
これは提案の相手個人によって答えが分かれるところではないかと思います。
## MikadoMethod
前半戦が終わって、後半戦は本題のMikadoMethodです。
MikadoMethodの紹介から話は始まりました。
### 名前の由来
Mikadoという竹ひごを使ったゲームに由来します。
このゲームについてはWikipediaのページがわかりやすいので紹介しておきます。
https://ja.wikipedia.org/wiki/ミカド_(ゲーム)
このゲームのプレイヤーの試行過程に似ていることからその名がついたそうです。
### 本の紹介
MikadoMethodという名前の本が Manning から発売しています。
無料で前半部分が見れるのでそれだけでもおすすめです。
http://www.manning.com/ellnestam/
ペーパーバックがAmazon.co.jpから購入できます。
http://www.amazon.co.jp/Mikado-Method-Ola-Ellnestam/dp/1617291218/ref=sr_1_1?ie=UTF8&qid=1434893181&sr=8-1&keywords=MikadoMethod
このペーパーバックのページ数は２００ページ程度だそうです。
構成は２部構成で、ざっくりいうとMikadoMethodの基本と応用となっています。
前半を読むだけでMikadoMethodの使い方についてはわかるそうです。
### どういうときに用いるか
システムがとても複雑なのに機能追加をしなくてはならない状況(ブラウンフィールドデベロップメント)では
設計・実装を順番にやり遂げることは難しいのでリファクタリングを試行錯誤し、
既存の機能を壊さないように、機能追加できるまでシステムを変形(モーフィング)していきます。
MikadoMethodはこの「モーフィング」を行う方法です。
### 試行する過程を明確にする技術、図法
Mikadomethodの手順をあえて大雑把に説明します。
先ほど紹介した本のChapter1 図1-3 にMikado Methodの手順が正確に書いてありますので
正確な詳細はそちらをご参照ください。その図は無料で読めます。
0. まずはゴールを決め、ミカド図に書き足します。
1. 次にそのゴールを実現するためにコードを書き換えます。
2. ブラウンフィールドデベロップメントであれば、この時点でなんらかのエラーが発生します。
3. このエラーを修正することを次の小ゴールとします。小ゴールをミカド図に追記します。
1-3を繰り返し、全てのゴールが解決したとき、作業が完了します。
例
0. A機能を追加するとか、その作業の終了条件をゴールとします。
1. 次に、A機能を追加するには、Bという既存のI/Fの修正が必要なので、コードを書き換えます。
2. すると既存のBの利用者がエラーを起こすようになります。
3. 先ほどのコード修正内容とエラーの内容を小ゴールとし、ミカド図を更新します。
このあと、1-3の例のような作業を繰り返します。
# 感想
私の感想です。
設計やコードの規模が大きすぎて、デグレの影響範囲が読めないときに有効な手だという印象です。
また、静的型付言語で組まれたシステムに対してMikadoMethodは有効だと思います。
型のない言語で作ったシステムにMikadoMethodを適用する場合は、
既存機能を回帰テストする自動スクリプトの量が、静的型付言語で作ったシステムよりずっと多く必要です。
テストを書く文化のない現場でこの方法を適用するのは現実的ではないですね。
* 日時 4/27（月）19:00～21:00
* 登壇者 高木さん(@oreshio)
* タイトル リファクタリングとMikadoMethod
* 参加者は１０名弱だったと記憶しています。
* 場所 東京エレクトロン札幌支社 会議室
# 勉強会の内容報告
この日の勉強会のテーマはMikadoMethodでした。
まずはMikadoMethodと関係の深いリファクタリングについて振り返りました。
## リファクタリング
リファクタリングという言葉は開発者の間では一般的な言葉ですが、
開発者は全員リファクタリングをしているかというと、そういうわけではないようです。
まずリファクタリングができない理由について説明がありました。
### リファクタリングができない理由
派生開発の現場にいると「壊れていないものを修理するな」という言葉をよく聞くことがあります。
メンテナンスが困難なコードを下手にリファクタリングし、その結果エンバグしてしまうことを防ぐためです。
この言葉が乱用される現場では、リファクタリングがしにくいこともあるでしょう。
開発プロセスにもリファクタリングができない理由があるということでした。
ウォーターフォール開発は開発工程が最後になりますが、現実にはその後もコードを修正しつづけますよね。
ウォーターフォール開発ではその後の修正のことは考えられてないため、リファクタリングがやりづらいのです。
一方、インクリメンタル開発は開発工程が周期的に行われ、リファクタリングしないと開発がうまくまわらないような仕組みになっています。
高木さんはリファクタリングの動機を
「機能追加しやすい作りである方が、将来の作業のコスト削減になる」
と表現されていました。
将来を見据えたときに、リファクタリングしたほうがよいかどうか考えることになるのですね。
### リファクタリング実施の判断
リファクタリングすべきかどうか、判断するのは簡単ではないですね。
４つの判断要素があるということでした。
* 書き直す規模
* コストとリターン
* 新規か派生か
* 求められる品質
このあと、参加者全員でケーススタディを行いました。
先の４つの条件が異なる３つのケースについてリファクタリングするべきかを全員で議論しました。
リファクタリングすべきかどうか、すぐに全員が合意できるものもあれば、そうでないものもありました。
まとまらないケースがあるのは各参加者の知識と経験が異なるからで、
その知識と経験がリファクタリング実施判断に大きく関わるからだろうと私は考えます。
この議論の中で、プロダクトマネージャに
リファクタリング実施を提案するにはどのようにすべきかという話題が上がりました。
結論はでませんでしたが、
「内部品質がどれだけ悪いかを訴えるのがよい」
「プロダクトマネージャが関心をもつもの（QCDなど）がリファクタリングの前後でどう変化するかを説明するのがよい」
など複数意見があがりました。
これは提案の相手個人によって答えが分かれるところではないかと思います。
## MikadoMethod
前半戦が終わって、後半戦は本題のMikadoMethodです。
MikadoMethodの紹介から話は始まりました。
### 名前の由来
Mikadoという竹ひごを使ったゲームに由来します。
このゲームについてはWikipediaのページがわかりやすいので紹介しておきます。
https://ja.wikipedia.org/wiki/ミカド_(ゲーム)
このゲームのプレイヤーの試行過程に似ていることからその名がついたそうです。
### 本の紹介
MikadoMethodという名前の本が Manning から発売しています。
無料で前半部分が見れるのでそれだけでもおすすめです。
http://www.manning.com/ellnestam/
ペーパーバックがAmazon.co.jpから購入できます。
http://www.amazon.co.jp/Mikado-Method-Ola-Ellnestam/dp/1617291218/ref=sr_1_1?ie=UTF8&qid=1434893181&sr=8-1&keywords=MikadoMethod
このペーパーバックのページ数は２００ページ程度だそうです。
構成は２部構成で、ざっくりいうとMikadoMethodの基本と応用となっています。
前半を読むだけでMikadoMethodの使い方についてはわかるそうです。
### どういうときに用いるか
システムがとても複雑なのに機能追加をしなくてはならない状況(ブラウンフィールドデベロップメント)では
設計・実装を順番にやり遂げることは難しいのでリファクタリングを試行錯誤し、
既存の機能を壊さないように、機能追加できるまでシステムを変形(モーフィング)していきます。
MikadoMethodはこの「モーフィング」を行う方法です。
### 試行する過程を明確にする技術、図法
Mikadomethodの手順をあえて大雑把に説明します。
先ほど紹介した本のChapter1 図1-3 にMikado Methodの手順が正確に書いてありますので
正確な詳細はそちらをご参照ください。その図は無料で読めます。
0. まずはゴールを決め、ミカド図に書き足します。
1. 次にそのゴールを実現するためにコードを書き換えます。
2. ブラウンフィールドデベロップメントであれば、この時点でなんらかのエラーが発生します。
3. このエラーを修正することを次の小ゴールとします。小ゴールをミカド図に追記します。
1-3を繰り返し、全てのゴールが解決したとき、作業が完了します。
例
0. A機能を追加するとか、その作業の終了条件をゴールとします。
1. 次に、A機能を追加するには、Bという既存のI/Fの修正が必要なので、コードを書き換えます。
2. すると既存のBの利用者がエラーを起こすようになります。
3. 先ほどのコード修正内容とエラーの内容を小ゴールとし、ミカド図を更新します。
このあと、1-3の例のような作業を繰り返します。
# 感想
私の感想です。
設計やコードの規模が大きすぎて、デグレの影響範囲が読めないときに有効な手だという印象です。
また、静的型付言語で組まれたシステムに対してMikadoMethodは有効だと思います。
型のない言語で作ったシステムにMikadoMethodを適用する場合は、
既存機能を回帰テストする自動スクリプトの量が、静的型付言語で作ったシステムよりずっと多く必要です。
テストを書く文化のない現場でこの方法を適用するのは現実的ではないですね。
おばんです。中岫です。
2015年3回目の勉強会を開催しました！！
藤田さんによる「テストプロセスについて考える」です。
参加者は8名。
内容は「ソフトウェア開発に関係したモデル」と「品質とプロセス」について、
資料を踏まえつつのディスカッションになります。
■アジェンダ
・ウォータフォール・モデルの解説と良い点、悪い点
・Vモデル・Wモデル・VVモデルの解説とWモデル・VVモデルの良い点、悪い点
・品質とプロセス
■ウォータフォール・モデル
特徴
・作業工程（要求仕様、基本設計など）を時系列にトップダウンで分割する
・原則とし前工程が完了しなと次工程に進めない
・並行作業（ex.設計中にプログラミング）を行わない
・前工程の成果物の品質を確保することで手戻りを最小限にする
etc
モデル例）
ウォーターフォールの良い点、悪い点のディスカッション
こんな意見が出ました。
（参加者コメント）
良い点
・順番に出来る
・見た目がわかりやすい、わかった気がする
・間違いないものが確実にできるならば後戻り不要
・スタート時に全体像(スケジュール・予算)が合意できる
・フェーズがしっかりしているので成果物が担保できる
・マネージャーが楽できる
・顧客が初期段階で安心できる
悪い点
・後戻りがしづらい
・スケジュールと予算は想定どおりにならない
・短期開発には向かない
・前工程の遅れが後工程にしわ寄せがくる
（所感）
（意外と）良い点に関する意見が多数でした。
「ウォーターフォール」というと諸悪の根源的な風潮になっている気がします。
開発の流れを「滝」というメタファでモデル化したものであって、その実はトップ・ダウン型のシーケンシャル開発。
純粋なソフトウェアだけで構成されるようなアプリケーションには不向きな点は多いと思いますが、
大規模で、しかもクリティカルなハードウェアを伴うようなソフトウェアには必要な考えでもあると思っています。
向き、不向きがあるというわけですね。
■Vモデル・Wモデル・VVモデルの解説
Vモデル
各作業工程に対するテストのレベルのモデル
モデル例）
Wモデル
テスト工程を上流工程に適用しテストアクティビティを前倒し他状態のモデル
VVモデル
開発でテストの設計を、検証で開発の設計を、双方の観点を取り入れた状態のモデル
Wモデル・VVモデルの良い点、悪い点のディスカッション
こんな意見が出ました。
（参加者コメント）
良い点
・牽制される(開発の独りよがりにならない)ため品質が高くなる
・ものづくりの本質に迫るアプローチ。(QCDオールよし！を実践)
・設計段階からテストを考慮出来るので品質・デリバリが良い
・上位文書でテスタビリティが良くなる
・仕様に関する問題点が早く出やすい
悪い点
・実感がない(ピンとこない)
・わかりやすい手順が示し難い（高いレベルが必要）
・大抵失敗する、テスト屋に開発スキルが必要(逆も然り)費用対効果的に難しい
・開発者はテストに興味がないので、テストの中身がおかしくなる。
・欠陥の発見工程より単純な定量的分析はできない
・実現が難しく、元に戻る(崩壊する)のが早い
・手戻りが発生した場合も開発が遅くなる(ウォーターフォールより線が多いから)
（所感）
Vモデル ＝ ウォータフォール と思われがちです。
Vモデル・Wモデル・VVモデルは作業工程毎にテストのレベルを対比したモノであって
決してプロセス自体を表しているわけではないことに気を付けないといけませんね。
■品質とプロセス
「プロセス」って何ですか？と言う問いから、はじまり、プロセスに関する資料をみながらディスカッション
製品品質に関する定義式について
Ｑpd（製品）
＝Ｑ pc （プロセス（仕掛け、仕組み））
×Ｑ rq （実際の要求仕様）
×Ｑ om（実際の組織、人材、知識、教育）
×Ｑ it （実際の技術、情報、部品、環境）
×Ｑ mt（モチベーション）
(出典：情報処理1995.5 p406)
（参加者コメント）
・成功事例から式の要素を出したように思える。
・製造における品質活動から出てきたのではないか？
プロセスが不具合の原因？いつまで経っても「不具合」が減らないのはなぜ？
「プロセス」が改善されていないから？定義されていないから？
（参加者コメント）
・品質改善を全てプロセス定義に頼らない方がいい。
・定義がなくても出来る改善はある。
・改善はプロセスが定義されていなくても出来ることがある。
ソフトウェア品質とプロセスの関係について
（参加者コメント）
・プロセスは必ずしも不具合の原因ではないでしょ？
・プロセス維持は固定化のことではない、改善も含まれる
・最低限の品質を抑える為の手段としてプロセスを使う
・プロセスとスキル以外に品質を向上させるものはある
・分厚い定義書を何も考えずに取り組むのは良くない
（所感）
プロセスを画一化・固定するのではなく、柔軟性と多様化が大事だなと思いました。
また、一般的に定義されたプロセスを（そのまま）適用するのではなく、そのプロセスを（適切な形で）使いこなすことが大事だと思いました。
2015年3回目の勉強会を開催しました！！
藤田さんによる「テストプロセスについて考える」です。
参加者は8名。
内容は「ソフトウェア開発に関係したモデル」と「品質とプロセス」について、
資料を踏まえつつのディスカッションになります。
■アジェンダ
・ウォータフォール・モデルの解説と良い点、悪い点
・Vモデル・Wモデル・VVモデルの解説とWモデル・VVモデルの良い点、悪い点
・品質とプロセス
■ウォータフォール・モデル
特徴
・作業工程（要求仕様、基本設計など）を時系列にトップダウンで分割する
・原則とし前工程が完了しなと次工程に進めない
・並行作業（ex.設計中にプログラミング）を行わない
・前工程の成果物の品質を確保することで手戻りを最小限にする
etc
モデル例）
ウォーターフォールの良い点、悪い点のディスカッション
こんな意見が出ました。
（参加者コメント）
良い点
・順番に出来る
・見た目がわかりやすい、わかった気がする
・間違いないものが確実にできるならば後戻り不要
・スタート時に全体像(スケジュール・予算)が合意できる
・フェーズがしっかりしているので成果物が担保できる
・マネージャーが楽できる
・顧客が初期段階で安心できる
悪い点
・後戻りがしづらい
・スケジュールと予算は想定どおりにならない
・短期開発には向かない
・前工程の遅れが後工程にしわ寄せがくる
（所感）
（意外と）良い点に関する意見が多数でした。
「ウォーターフォール」というと諸悪の根源的な風潮になっている気がします。
開発の流れを「滝」というメタファでモデル化したものであって、その実はトップ・ダウン型のシーケンシャル開発。
純粋なソフトウェアだけで構成されるようなアプリケーションには不向きな点は多いと思いますが、
大規模で、しかもクリティカルなハードウェアを伴うようなソフトウェアには必要な考えでもあると思っています。
向き、不向きがあるというわけですね。
■Vモデル・Wモデル・VVモデルの解説
Vモデル
各作業工程に対するテストのレベルのモデル
モデル例）
Wモデル
テスト工程を上流工程に適用しテストアクティビティを前倒し他状態のモデル
VVモデル
開発でテストの設計を、検証で開発の設計を、双方の観点を取り入れた状態のモデル
Wモデル・VVモデルの良い点、悪い点のディスカッション
こんな意見が出ました。
（参加者コメント）
良い点
・牽制される(開発の独りよがりにならない)ため品質が高くなる
・ものづくりの本質に迫るアプローチ。(QCDオールよし！を実践)
・設計段階からテストを考慮出来るので品質・デリバリが良い
・上位文書でテスタビリティが良くなる
・仕様に関する問題点が早く出やすい
悪い点
・実感がない(ピンとこない)
・わかりやすい手順が示し難い（高いレベルが必要）
・大抵失敗する、テスト屋に開発スキルが必要(逆も然り)費用対効果的に難しい
・開発者はテストに興味がないので、テストの中身がおかしくなる。
・欠陥の発見工程より単純な定量的分析はできない
・実現が難しく、元に戻る(崩壊する)のが早い
・手戻りが発生した場合も開発が遅くなる(ウォーターフォールより線が多いから)
（所感）
Vモデル ＝ ウォータフォール と思われがちです。
Vモデル・Wモデル・VVモデルは作業工程毎にテストのレベルを対比したモノであって
決してプロセス自体を表しているわけではないことに気を付けないといけませんね。
■品質とプロセス
「プロセス」って何ですか？と言う問いから、はじまり、プロセスに関する資料をみながらディスカッション
製品品質に関する定義式について
Ｑpd（製品）
＝Ｑ pc （プロセス（仕掛け、仕組み））
×Ｑ rq （実際の要求仕様）
×Ｑ om（実際の組織、人材、知識、教育）
×Ｑ it （実際の技術、情報、部品、環境）
×Ｑ mt（モチベーション）
(出典：情報処理1995.5 p406)
（参加者コメント）
・成功事例から式の要素を出したように思える。
・製造における品質活動から出てきたのではないか？
プロセスが不具合の原因？いつまで経っても「不具合」が減らないのはなぜ？
「プロセス」が改善されていないから？定義されていないから？
（参加者コメント）
・品質改善を全てプロセス定義に頼らない方がいい。
・定義がなくても出来る改善はある。
・改善はプロセスが定義されていなくても出来ることがある。
ソフトウェア品質とプロセスの関係について
（参加者コメント）
・プロセスは必ずしも不具合の原因ではないでしょ？
・プロセス維持は固定化のことではない、改善も含まれる
・最低限の品質を抑える為の手段としてプロセスを使う
・プロセスとスキル以外に品質を向上させるものはある
・分厚い定義書を何も考えずに取り組むのは良くない
（所感）
プロセスを画一化・固定するのではなく、柔軟性と多様化が大事だなと思いました。
また、一般的に定義されたプロセスを（そのまま）適用するのではなく、そのプロセスを（適切な形で）使いこなすことが大事だと思いました。