読者です 読者をやめる 読者になる 読者になる

七転八倒五里霧中 値千金大勝利

いい感じにうまくやりたい。

「QAアーキテクチャ=ソフトウェア品質保証ライフサイクル」

QA勉強会「ここは苦しいところですが、どうか一つ、QAアーキテクチャを。」に参加してきました。

connpass.com

にしさんの話を聞いて、QAアーキテクチャってなんだろうなーという問いに対して、なんとなくですがモデルっぽいものが見えたので、酒入っているけど書き留めておきます。チラ裏じゃないけどメモ書き。レポートにはしない予定。 (やるなら、講演資料を読み直して自分なりに再整理したものを書こうと思う。)

当日資料

公開されたのでリンク貼っておきます。 リリカルさんの資料はにしさんの資料を整理して図解してある感じなので、個人的にはだいぶ頭に入りやすくなっています。 きちんとした定義は、にしさんの資料で押さえなきゃ。

そんなわけでリリカルさんの講演資料はこちら。

www.slideshare.net

にしさんのラップアップの元ネタ資料はこちら。

www.slideshare.net

QAアーキテクチャ

今日のにしさんの話を一言でまとめると「QAアーキテクチャ=ソフトウェア品質保証ライフサイクル」という具合でしょうか。

まずはQAアーキテクチャの構成要素として、にしさんがいくつかの要素を挙げていました。これを戦略〜兵站に当てはめてみたらこんな感じになりました。カッコのなかは、なぜここに当てはめたかの理由です。

※構成要素の個々の説明については、西先生の資料にあるので省略します。

  • 戦略:QA観点モデル(サービス・プロダクトの品質定義。基本変わらない。)
  • 作戦:アシュアランスパイプライン(ライフサイクルのなかで大きくは変わらない。ただしプロセスが洗練されていくなかで組み換えしていく。)
  • 戦術:テストアーキテクチャ/レビューアーキテクチャ(QAチームの実業務を具体的に定義していくところ)
  • 兵站:技術ロジスティクス・テックシェルフ(採用や教育など、個々人の能力強化になるところ)

テストアーキテクチャ/レビューアーキテクチャ

テストアーキテクチャの話については、リリカルさんの資料が頭に入りやすくなっていますので参照して頂くとして…。

テストアーキテクチャ/レビューアーキテクチャを作っていくときは、分析・設計・実装のフェーズで行う活動と成果物がこんな感じになるのでしょう。

  • テスト分析:テスト観点×テスト対象→テスト条件
  • テスト設計:テスト条件(あるいは高位レベルテストケース?)→(低位レベル)テストケース
  • テスト実装:テストケース→手順・データ・自動化スクリプトetc…

  • レビュー分析(ここだけ独自用語かも):開発工程の各フェーズで設けるレビュー観点の定義

  • レビュー設計:レビュー観点→レビューケース(質問内容)
  • レビュー実装:レビューケース→レビュースクリプト(質問する際の台本)

仕様書コピペはNGだけど、開発・テスト・レビューそれぞれが各フェーズで行う活動と成果物に対して、うまいこと紐付けできるよなぁと思います。(別の意味で)観点の違いなのだろうなぁ。

実践を考えてみる

では、実際にやってみるとなるとどうなるか。という質問が会場から出ていました。 トップダウン型ならば、会社としての目標とQAチームとしての目標をすりあわせて〜という、至極真っ当なやり方。 現場から起こすとなると「ミドルアップダウン」型。課長クラスが余剰工数を作って、意欲ある部下にチャレンジの機会を与える。

この話、野中郁次郎先生の「知識創造企業」を思い出しました。(同じ野中でも、東洋大学の野中誠先生じゃないですよ。)

知識創造企業

知識創造企業

ジョークとして「上司と喧嘩するよりも、上司を持ち上げたほうが幸せになれる」とおっしゃられていましたが、そのあたりも含めて、もう組織論の話だよなぁと感じました。 あ、にしさんの講演で冒頭から出ていた「うまくいっていない組織」の話は、野中郁次郎先生の「失敗の本質」そのものな気がしています。

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)

実際にどう動くかについては「アジャイル」の人が詳しいとおっしゃっていたので「組織パターン」かヤフージャパンの山口鉄平さんが翻訳に参加している「Fearless change」あたりを読むのがいいのかなーと思います。

組織パターン

組織パターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

("寝技"と言ってたけど、個人的には"社内マーケティング"と言うほうがやる気出ます。また、「知識創造企業」と「失敗の本質」は組織運営におけるグッドプラクティスとバッドプラクティスの両極に相当する感じなので、両方知っておくと"寝技"の幅がかなり広がると思います。)

また、Web系企業での実践はどうかという質問に対して「全部一気にやるのではなく、開発チームと歩調を合わせて少しずつ育てていくのがよい」という話だったのですが、アジャイル型…というよりも、プロダクトと育てていくのとあわせて、QAアーキテクチャも育てていくと思うのがよさそうです。(妖精風VSTePと呼んでいるようですが、個人的には「伽藍とバザール」のバザール側な感じがしています。)

そんなわけで、リリカルさん・にしさん、ありがとうございました。ソフトウェア品質保証のプロセス全体を俯瞰するのに、すごくいい会でした。

補足

記事公開後、Twitterでいくつかメンションを頂いたのでこちらで返答しておこうと思います。

"「寝技」って、「かけてハマると絶対勝てる戦術」ってことかな。" 社内政治、と認識しました。(自分が行いたい活動をするために)飲み会で上司を口説くとか、社内政治だよなぁと思うのです。 個人的には、この記事で出てくる「マーケティング」って捉えるようにしています。それで、ようやく調整業ができるようになったので。

gqjapan.jp

"私は、テスト項目の意図は何か?の話が納得でした。上流で防げることも意識してゆきたいと思いました。" なんとなくですが、ステークホルダーごとに持つ品質保証における関心事がテスト要求であり、Whyであり、テスト項目の意図は何かというところになるのかなーと思っています。

また、上流で要求あるいは課題に対するValidationを効かせていくのも大事なのだろうなぁと最近感じています。

ValidationとVerificationの違いは、この本が良さげ。

課題・仕様・設計―不幸なシステム開発を救うシンプルな法則

課題・仕様・設計―不幸なシステム開発を救うシンプルな法則