-
masaru_b_cl
- 2479
- 6
- 0
- 0
-
- いいね！0
Yasuharu NISHI
@YasuharuNishi
えーと、QAアーキテクチャはプロセスアーキテクチャではないかという質問があったのでお答えします。答えはNo & Yesです。 #QAアーキ
2016-12-23 11:20:28
Yasuharu NISHI
@YasuharuNishi
原則的にQAアーキテクチャはプロセスアーキテクチャもしくはプロセスそのものではありません。QAアーキテクチャの第一目的は「どんなQA観点を作り込んで保証できているのか」を記述するものだからです。 #QAアーキ
2016-12-23 11:23:09
Yasuharu NISHI
@YasuharuNishi
プロセスには様々な解釈がありますが「何をどういう手順でどの順序で行うか」もしくは「入力と出力はそれぞれ何か」という解釈だとすると、QAアーキテクチャはそうではありませんね。ですので、答えはNoです。 #QAアーキ
2016-12-23 11:24:26
Yasuharu NISHI
@YasuharuNishi
しかしQAアーキテクチャを作成する際に、QA観点をいつどの工程で作り込んで保証するのか、ということを明らかにします。ですので、プロセスを記述しているか、と聞かれるとYesとも答えられます。これが、答えがNo & Yesになる理由です。 #QAアーキ
2016-12-23 11:26:37
Yasuharu NISHI
@YasuharuNishi
QAアーキテクチャでは別に、各工程で行われる作業を記述する必要はありませんし、各工程の入力成果物や出力成果物を定義する必要もありません。それらは、プロセス定義で行われるべきものです。 #QAアーキ
2016-12-23 11:28:00
Yasuharu NISHI
@YasuharuNishi
ただしQAアーキテクチャが主張するのは、各工程で作り込みまたは保証されるQA観点を明示せずにプロセスのみを定義するのは、形骸化や重量化を招くよ、ということです。したがってプロセスを定義する前に/しながらQAアーキテクチャを形作っていきます。 #QAアーキ
2016-12-23 11:29:31
Yasuharu NISHI
@YasuharuNishi
そうすると、QAアーキテクチャの設計はプロセスの設計と同義だよね、と言いたくなる気持ちも分かります。そのように開発支援業務を定義しても構わないと思います。ただ情報の種類や構造としては異なることを頭に入れておいた方がよいでしょう。 #QAアーキ
2016-12-23 11:30:51
Yasuharu NISHI
@YasuharuNishi
また、うまく伝わっていなかったかもしれなかったので、テックシェルフについて補足します。 #QAアーキ
2016-12-23 11:31:14
Yasuharu NISHI
@YasuharuNishi
現状の（ダメな）ソフトウェア品質保証組織の問題点は、「保証」という言葉に引きずられて、「何かを確認すること」によってのみ品質保証活動を行うと誤解している点です。 #QAアーキ
2016-12-23 11:33:12
Yasuharu NISHI
@YasuharuNishi
しかし、それは間違いです。SQuBOKを思い出してみましょう。（日本的）品質保証とは「お客様に安心して使って頂けるような製品を提供するためのすべての活動」です。確認系の作業に閉じた活動ではありません。 #QAアーキ
2016-12-23 11:34:11
Yasuharu NISHI
@YasuharuNishi
もともと日本ではQAのことをQC、すなわち「品質管理」活動と呼んでいました。歴史ある企業で昔から品質に責任を持つ責任がある場合、80年代前半より前は「品質保証部」と呼称されていたと思います。後は検査部や実験部ね。 #QAアーキ
2016-12-23 11:36:10
Yasuharu NISHI
@YasuharuNishi
1980年代にISO9000が渡来した際にどうも品質管理という呼称をやめて品質保証という呼称に変えた組織が多いようです。私が生まれる遙か前なのでよく知りませんが（笑）。 #QAアーキ
2016-12-23 11:37:05
Yasuharu NISHI
@YasuharuNishi
ここで変わったのは呼称だけのはずです。そもそもISO9000sの取得というのは、認証を取得するために品質保証プロセスを構築するのではなく、既に十分な品質を達成している組織がそのありようを規格とマッピングすればよかったからです。だとすれば、変える必要はありません。 #QAアーキ
2016-12-23 11:38:32
Yasuharu NISHI
@YasuharuNishi
しかし2つの理由により、日本のソフトウェア組織では確認系の作業がQAの主流であるという誤解が広まります。一つは、品質「保証」という言葉に引きずられて、変える必要の無い自分たちの作業を変えてしまったこと。外圧に弱い感じですね。 #QAアーキ
2016-12-23 11:40:05
Yasuharu NISHI
@YasuharuNishi
もう一つは、そもそも自分たちの組織で十分な（というか全く）品質を獲得する作業を行っていなかったのにISO9000sブームによって認証を取得せねばみたいな流れになって、やってもいないことのハリボテを規格にしたがって作ってしまったことですね。 #QAアーキ
2016-12-23 11:41:47
Yasuharu NISHI
@YasuharuNishi
後者のクソみたいな推進方法は、ISO9000sの後くらい（かな？）に流行したCMMブームの時にも起きますし、A-SPICEでもISO26262でも起きます。もうなんというか、我が国のエセ知的層に特有の、中途半端な植民地的思考様式に毒された他者追従思考の賜物ですね。 #QAアーキ
2016-12-23 11:43:59
Yasuharu NISHI
@YasuharuNishi
そもそも日本的な品質管理活動というのは、確認系の作業に閉じたものではありませんでした。それを象徴するのが「上流からの品質の作り込み」です。 #QAアーキ
2016-12-23 11:47:35
Yasuharu NISHI
@YasuharuNishi
確認系の作業だけで品質保証をするというのは、もう既に1960年代に出口検査主義からプロセス中心主義に日本の工場が移行した際に、間違いだと実証されています。 #QAアーキ
2016-12-23 11:48:07
Yasuharu NISHI
@YasuharuNishi
ただしこの「プロセス中心主義」というのは、ソフトウェアのQA関係者には曲者なので注意が必要です。出口検査主義の延長線上にプロセス中心主義は存在します。すなわち、出口できちんと不良品がはねられることが前提となっているのです。 #QAアーキ
2016-12-23 11:49:31
Yasuharu NISHI
@YasuharuNishi
もちろんこの出口検査というのは、単なる無秩序な絨毯爆撃的検査ではありません。概ねどの辺りで欠陥があるのかが十分分かって効率的な検査ができているレベルです。 #QAアーキ
2016-12-23 11:50:41
Yasuharu NISHI
@YasuharuNishi
どの辺りでどんな欠陥が作り込まれているのが分かっているから出口検査で効率的に不良品を抑えられる。それでもコストかかっちゃうから、最初から不良品を作らないようにしよう、という発想です。品質管理というのが、作り込みと確認の両方で行っているのが、ここからも分かります。 #QAアーキ
2016-12-23 11:52:49
Yasuharu NISHI
@YasuharuNishi
とすると、出口検査主義を発展させたプロセス中心主義というのは、どこでどんな欠陥が作り込まれ、どこで検出すれば最も効率的なのか、ということが分かった上で、それをプロセスに埋め込むことだというのが分かります。 #QAアーキ
2016-12-23 11:54:08
Yasuharu NISHI
@YasuharuNishi
やれ形骸化するとかやれ重量化するとか言っている組織で行っているプロセス「定義」のように、ただ単にそれっぽく作業と作業成果物と手順を決めて線でつなげる作業とは、本質的に異なっているのです。 #QAアーキ
2016-12-23 11:55:17