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

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

connpass.com

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

当日資料

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

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

Qaアーキテクチャの話 from Kosuke Fujisawa

www.slideshare.net

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

QAアーキテクチャの設計による説明責任の高いテスト・品質保証 from Yasuharu Nishi

www.slideshare.net

QAアーキテクチャ

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

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

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

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

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

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

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

• テスト分析：テスト観点×テスト対象→テスト条件
• テスト設計：テスト条件（あるいは高位レベルテストケース？）→（低位レベル）テストケース

• テスト実装：テストケース→手順・データ・自動化スクリプトetc…

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

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

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

実践を考えてみる

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

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

知識創造企業

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

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

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

組織パターン

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

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

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

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

補足

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

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

gqjapan.jp

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

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

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

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

エンドユーザーを知るきっかけとしての「お隣のコミュニティ」

※このネタはアイティメディアさんの@ITエンジニアライフ

What a wonderful world：エンジニアライフ

で書こうと思っていたネタです。 明日 2016/11/19から始まるCode for Japan Summit 2016への集客を兼ねたPRブログでした。 ただ、PR100%はつまらないので、PR色薄めにしていました。 そのうちリテイクして@ITエンジニアライフに書くかもです。

そんなわけで、Code for Japan Summit 2016をよろしくお願いします。

summit2016.code4japan.org

前回、"「顧客が本当に必要だったもの」は顧客にしかわからない"ということで、「エンジニアにウケる話は、エンジニアにしかわからない」という例を挙げてみました。

その一方で対象顧客を知るために、その方々がいそうなイベントなどに足を運ぶのが、初手としてよいかもしれないと書きました。

ですが、イベントによっては全く別次元の場所もあれば「お隣のコミュニティ」な場合もあります。

ということで、最近首を突っ込んでしまったイベントの告知が目的の半分を占める話題です。

■カタカナ語が通じない世界はつらい 非IT業界な方々からすると、技術周りのキーワードは暗号でしかない。というのは、ある意味そうでしかないです。 エンジニアが、全く関わったことのない他業種の専門用語を聞いてもわからない。という話です。

ですが、一般化しつつあるようなキーワードでも、全く関わっていない方々からすると、やはり暗号でしかないようです。 「アイデアソン」「ハッカソン」「ワークショップ」「クラウドファンディング」etc...

どの言葉も、わからないひとはわからない。正直な話、その界隈ではカタカナ語を禁止して会話したほうがいいのではないかと思います。 下手に意識高くカタカナ語を連発すると、周囲の理解が得られないまま詰むことになります。

■カタカナ語が通じる世界は、まだ救いがある こうしたカタカナ語が普通に通用する世界であるならば、まだ救いはあります。

エンジニアでなくても、WebデザイナーやITが絡むイベントや事業を企画される方ならば当たり前のカタカナ語。 そうしたイベントや事業に興味を持たれ参加される方ならば「ワークショップ」くらいは普通に通じます。 「ユーザーストーリー」などのプロダクトオーナー向けキーワードも、概念をきちんと伝えれば理解していただけることでしょう。 なにせ、普段の業務でこうしたことは考えているはずなので。

■「お隣のコミュニティ」でゆるく相談するくらいはいいのではないか さて、こうした話と近いところで聞くのは「技術の無償提供はNG」という話です。 相応の時間と金額をかけて磨いてきた技術です。無償で見返りなしに提供するのはNGということは至極当然ですし、私も同意見です。

ですが、「こうするといいのではないか」という相談くらいは乗ることもできるのではないでしょうか。 私たちも、「このサービスどうだろう」という相談をしたい機会がありますので。

そして、こういう相談をゆるくできそうな場としてカタカナ語が通じる「お隣のコミュニティ」がよいのではないかと思います。

3.11以降、一部のエンジニアがこうした領域で活動をはじめました。 Qiitaのプロダクトマネージャーである及川卓也さんなどが有名ですね。

同じような想いから立ち上がった団体の一つにCode for Japanがあります。 「シビックテック」をキーワードに、自分たちが住む地域の課題をテクノロジーを用いて解決する活動をしているところですね。

普段の業務ではなかなか関わらない団体でもあります。また、こういう場こそ「無償」というキーワードを気にしてしまう場所でもあります。 ですが、お互いに「これどうだろう」と懇親会の場で話をするくらいであれば、エンドユーザーを知るための機会としても有益なのかもしれません。

11月19日〜20日にかけて神奈川県横浜市金沢区総合庁舎で行われます。 個人的には、前夜祭のTokyo MotionControl Networkさんとのコラボイベントのほうが楽しみなんですけどね。テクノロジーとエンジニアリングおいしいですもの。

　　技術論や方法論が共通言語にできるところは、

だいぶご無沙汰となりました。たのっちです。 少し思うところがあり、久々に筆を執りました。（筆ではなくキーボードですが）

■エンジニアにウケる話は、エンジニアにしかわからない 数ヶ月前に、某カンファレンスの実行委員会に顔を出したとき、こんな会話がありました。

「開催地の行政から後援を得たいねぇ」 「いいね！それでこちらは何か用意しなきゃいけない？」 「講演枠とかあると良さげな感じみたいですよ」 「それはいいのだけど、エンジニアにウケる話でないと、聴講者少ないよねぇ」 「あー、わかる。エンジニアにウケる話で、行政も関わる話って何があるかなぁ」 （以降、雑談的にディスカッション）

■エンドユーザーが欲しいものは、エンドユーザーに近いところにいる人のほうがわかる 以前お仕事をしていた現場で、こんなやり取りがありました。

「先日お話した件、今回はプロトタイプを作ってきました」 「おお、ありがとうございます。どういうものでしょうか。」 「はい、今回は...」 「なるほど、いいですね。ところで、こういう製品があるのだけど組み合わせられる？」 「おっ、それはこちらも気にしていたやつです。面白そうですね。そちらの方向で検討してみますね。」

■「顧客が本当に必要だったもの」を知るために 新規事業や新規プロジェクトが失敗した話としてよく聞くもののなかに「顧客が求めていないものを作ってしまった」があります。 ブランコの絵でおなじみのやつですね。 では「顧客が本当に必要だったもの」は、どうやって探せばよいのでしょう。

サービスデザイン、カスタマージャーニーマップ、ユーザーインタビューetc... いろいろと方法論が挙がってきますね。 どの方法論も、先人たちの知識が凝縮されたものです。適切なタイミングで適切に使えば、絶大な効果を発揮することでしょう。

その一方で、最近感じることとして「対象顧客を代表するようなひとが、チームのなかにいるのが一番早いのではないか」というのがあります。 「エンジニアにウケる話は、エンジニアにしかわからない」という話です。

では「理想はそうなのだけど...」という方は、どうすればいいのでしょうか。 対象顧客がいるイベントなどに足を運ぶのが、初手としていいのかもしれません。

「顧客が本当に必要だったもの」は顧客にしかわからない

※このネタはアイティメディアさんの@ITエンジニアライフ

What a wonderful world：エンジニアライフ

で書こうと思っていたネタです。 明日 2016/11/19から始まるCode for Japan Summit 2016への集客を兼ねたPRブログでした。 ただ、PR100%はつまらないので、PR色薄めにしていました。 そのうちリテイクして@ITエンジニアライフに書くかもです。

そんなわけで、Code for Japan Summit 2016をよろしくお願いします。

summit2016.code4japan.org

だいぶご無沙汰となりました。たのっちです。 少し思うところがあり、久々に筆を執りました。（筆ではなくキーボードですが）

■エンジニアにウケる話は、エンジニアにしかわからない 数ヶ月前に、某カンファレンスの実行委員会に顔を出したとき、こんな会話がありました。

「開催地の行政から後援を得たいねぇ」 「いいね！それでこちらは何か用意しなきゃいけない？」 「講演枠とかあると良さげな感じみたいですよ」 「それはいいのだけど、エンジニアにウケる話でないと、聴講者少ないよねぇ」 「あー、わかる。エンジニアにウケる話で、行政も関わる話って何があるかなぁ」 （以降、雑談的にディスカッション）

■エンドユーザーが欲しいものは、エンドユーザーに近いところにいる人のほうがわかる 以前お仕事をしていた現場で、こんなやり取りがありました。

「先日お話した件、今回はプロトタイプを作ってきました」 「おお、ありがとうございます。どういうものでしょうか。」 「はい、今回は...」 「なるほど、いいですね。ところで、こういう製品があるのだけど組み合わせられる？」 「おっ、それはこちらも気にしていたやつです。面白そうですね。そちらの方向で検討してみますね。」

■「顧客が本当に必要だったもの」を知るために 新規事業や新規プロジェクトが失敗した話としてよく聞くもののなかに「顧客が求めていないものを作ってしまった」があります。 ブランコの絵でおなじみのやつですね。 では「顧客が本当に必要だったもの」は、どうやって探せばよいのでしょう。

サービスデザイン、カスタマージャーニーマップ、ユーザーインタビューetc... いろいろと方法論が挙がってきますね。 どの方法論も、先人たちの知識が凝縮されたものです。適切なタイミングで適切に使えば、絶大な効果を発揮することでしょう。

その一方で、最近感じることとして「対象顧客を代表するようなひとが、チームのなかにいるのが一番早いのではないか」というのがあります。 「エンジニアにウケる話は、エンジニアにしかわからない」という話です。

では「理想はそうなのだけど...」という方は、どうすればいいのでしょうか。 対象顧客がいるイベントなどに足を運ぶのが、初手としていいのかもしれません。

改めてブログ作る。

前のブログは一旦更新終了して、こちらで新調します。

なんかだいぶ考え方変わったので。