パネルディスカッション「QAの過去から現在・現在から未来」(前編) #DeNA_QA_Night

タイトルに「パネルディスカッション」と書いておきながら、実際のパネルディスカッションは後編になります。

後編はこちら

目次

イントロダクション(河野さんの発表)

発表資料

www.slideshare.net

※p7まで

今回のパネルディスカッションの狙い

  • 温故知新がイベントのテーマ
    • 前回の松尾谷さんの発表もテーマは同じ

背景

皆さんが困っていること
  • 品質保証をマネジメントする仕組みと仕掛け(大きな話)
  • ワークさせる固有の技術の理解・習得(小さな話)
    • 小さな話だけやれば良いのではなく、大きな話もする必要がある
  • チーム構築
    • チームの仕組み
    • 品質確保の仕組み
QAの仕組み・仕掛けや道具
  • テストのやり方、ドキュメント体系などを習得すればよいのでは?

過去の経験を活用する

  • 奈良さんの講演資料
  • 奈良さんの書籍
  • これらの内容をベースに話し合いを行う
  • そのまま使ってよいのか?
    • コンテキストが違う
  • どちらかというと過去の話がベースになっている
    • サービス要求
      • 昔…信頼性が何よりも重要
      • 今…スピードも大事
    • QAと開発の形
      • 昔…監査・分業の存在
      • 今…協業の形
    • テスト方法
    • 昔…スクリプトテスト
      • 今…探索的テスト

にしさんへの講演リクエス

  • 過去から現在について
  • 現在から未来について

オープニングスピーチ(にしさんの発表)

発表資料

www.slideshare.net

自己紹介

  • いろんなことやってます
    • テスト方面
    • AIプロダクト(ソフトもシステムもデバイスもサービスも含む)のQA

ソフトウェアTQM

  • 1980年代からソフトウェアの品質は行われていた
  • 汎用機の頃のソフトウェア開発ではうまく作用した
    • 日立などは自社で内製していたりした
    • ネオダマの頃になってどうも怪しくなってきた
  • 奈良さんは汎用機の頃にうまくやっていた一人

かなり昔(汎用機時代、アトランティス時代)

特徴
  • 正社員が内製もしくは子会社の人たちで開発していた
  • ほとんどが紙だった
  • 動作環境も自社製で揃えられた
  • エンジニア意識の強い人が集まった
どんな開発・QAだったか
  • マシンパワーが高価のため、人間がガンガン改善した
    • 結果が出てくるまで3日ぐらいかかる時代
    • 紙の上で考えざるを得ない
      • 奈良さん「古すぎる話をしてるよ!」
  • 改善するとみんなが儲かる嬉しい状態
  • 全体としての問題が分かっていた
  • 内製なので、組織能力を積極的に高めていた
    • 教育も積極的に行っていた
  • 人間らしい仕事をしていた
  • 奈良さんなどの人に頼っていた時代

ちょっと昔(プロジェクト時代、奴隷時代)

特徴
  • 多重下請け構造に基づいたプロジェクト制だった
  • コマンドアンドコントロールの徹底を目指していた
  • 電子化をしたが、Excel方眼紙なのでメリットがない
    • 規模は大きいが探せない状態
  • 制約によってなんとかできると思っていた
  • サラリーマンエンジニアが多かった
    • エンジニアが雇用の受け皿になっていた
      • コミュ障の大学生は「それならソフトハウスに行きなさい」と就職課の職員に言われる
  • わずか10年前ぐらいまでこういう状態だった
どんな開発・QAだったか
  • 不具合を直すのにもお金がもらえる
  • 人間を取り替えのきく機械のように扱っていた
  • ソフトウェアのQAについてWebで探すと、この時代のQAの方法がヒットすることが多い
    • 結果として、解決できると勘違いしてしまう恐れがある
  • オープンソースの検証を自分たちで力技でやってしまおう、という時代

現在(クラウド時代)

特徴
  • 内製化が進んできている
  • GAFAMのやり方を学ぼうとする企業が多い
  • ソフトウェアが好きな人を集めやすい
どんな開発・QAなのか
  • アトランティス時代と似ている
    • ただし、ちゃんと考えてできているかは分からない
  • 中身をちゃんと理解して納得して作れている?
  • カイゼンのサイクルを短くすることができている?
  • 「QAはリソースが足りないので対応できません」と言ってないですか?
  • 組織能力を高めることができている?
    • スキルの高い人が流動化しているので組織能力を貯めにくいという側面もある

我々はどこに向かえばよいのか?

ちょっと昔(プロジェクト時代)と同じQAをすると概ね失敗する
  • クソCHAPDコントロールによる形骸化
    • Criteria-based control (基準値に従え!)
    • Human resource-based control (人力でなんとかしろ!)
    • Authorization-based control (誰の責任だ!)
    • Process-based control (マニュアル化しろ!)
    • Document-based control (文書!文書!文書!)
アトランティス時代と同じQAをしても的外れ・時代遅れになるだけ
  • 豊富なマシンパワー
  • 安価でリッチな開発・運用環境
昔ながらの良い考え方は取り入れる
  • 現在の状態に合わせて進化させる

自分たちで進化させよう

優れた組織イニシアティブの創出や醸成
  • 経営トップから品質を考えていける組織にする
    • 以下のような発言を経営陣がしていませんか?
      • 早く作れ!
      • リリースはいつだー!
      • 利益がー!
  • 納得感を共感して進めていく
  • 質の高いアウトプットを出すことを正義にしていく
  • QA部門は全員で品質を高める仕組み・文化を進めるように働きかける
    • SETと違う意味で、みんなで品質を上げていく
  • 品質はバグがなくなるだけでなく、人間らしい仕事にしていくことも大事
品質保証戦略を作る
  • 品質保証のアーキテクチャを作る
  • ありありと改善が分かる部分から行っていく
    • QAは主語がでかくしがち
QMSを構築する
  • 品質を上げることを嬉しくなる、評価されるQMSを作る
    • 「QMS?ISO9000でしょ?」という人は無視しよう
  • QMSによって開発の在り方そのものを進化させていく

よくやりがちなワナに気をつける

  • ラクティスファーストを行わない
  • 品質保証戦略のコピペをしない
    • Agileだから〜
    • 他社でやっていたから〜
  • 局所的で循環しない施策はデザインしない
    • クオリティーゲートを言っている人は奴隷時代の人
  • 深く考えずに協力会社に丸投げをしない

まとめ

  • 品質保証は組織を賢くするために行う仕事
  • ある意味経営と同じようなことを考える必要がある

後編(パネルディスカッション編)はこちら

nihonbuson.hatenadiary.jp