ソフトウェアの品質保証の本質 〜技法の変遷から学ぶ〜 #JaSST '17 Tokyo

勉強会 技術 JaSST

はじめに

  • 今日はディスカッションのネタを提供する

品質保証で思い浮かべることは？

  • あんまり良い思いを持っていないはず
  • めちゃくちゃデータを取ってくることを矯正されている

  • 余計な作業を追加するの？

  • 2007年以降は現場にいないので、正直、知るか！

皆さんの組織の現状は？

  • QMSはありますか？
    • 全社もしくは事業部単位にある
    • 部門単位にある
    • 上記いずれもある
    • もしかすると無い

  • QMSの実態は？

    • ほぼその通りに行われている
    • 参考にはしている
    • ほぼ使われていない

  • SQuaRE（東さん）のは小難しく書かれている。

  • ISOはとんでもないことを書いたりもする

品質保証の定義

  • 石川…品質保証は品質管理の真髄。
  • 飯塚…お客様に安心して使っていただけるような製品を提供するためのすべての活動

  • 西…品質保証活動とは、品質リスク(バグがあるかもしれない)を最小にする活動。

    • 西先生の発言で唯一覚えていることです。

  • 品質保証は体系的活動がポイント。

  • 品質保証はworkではなくアクティビティである

80年代のepoc

  • V字モデル。この発明によりテストのやり方を説明・共有できるようになった

  • 日本の品質保証の大発明： 品質管理図 (テスト管理の代表的手法)

    • 45歳以上の人は品質管理図を若い人に教えて書かせてください。いろいろなことがわかるから

  • 開発が8割のバグを出したら、その人の限界が来る

    • そのための第三者検証があったりする

90年代前半

  • ISO9000の台頭。良いところと悪いところがあった。
    • 良いプロセスは良いプロダクトを生み出すが，プロセス重視も普及してしまった (目的と手段の逆転)
    • CMMIではプラクティスも追加され厚くなり，ますますプロセスは専門家の手の中に
      • 「『プロセス改善』っていう言葉は嫌いでしょ？」

  • PMBOKはPM支援ではなくPM監視のために作られた。

  • 人のデータは全く役に立たない、コンテキストが違うから。

  • 欧米は管理と実行で分かれている。

    • 「俺は言われたことをやってるよ」

  • トラブルの時に真っ先に走るのが出来るQA

    • →走りたくないから出荷しない

質問

Q. 話の中で出てきたテストチームと開発は両輪だと行っていましたが、品質保証のチーム内に開発チームをどのように捉えたら良いのか？

  • 開発者の言うことは全部信じたほうが良いのか？全部疑ったほうが良いよ？なのか
    1. 開発は半分ぐらい嘘ついていると思う。
  • しょっちゅう嘘ついてるでしょ。上司にそのまま報告する訳がない。
    • 例えば、水平展開して10件出ます→9件しか出ない→「1件はコーディング規約違反がありました。」と言って10件出たと報告。
      • そんなので品質が上がったりはしない。

Q. 品質保証部門の組織内のあるべき形、パワーバランスについて聞きたい。

  • 新しい会社を作ってQA部門を作ったが、後発なので力が弱かったりする。
  • 一方で品証が偉くなったり…。
  • 本来の品質保証部門のありかたとは何か？
    1. それは私の考えるべきところではない。経営者がしっかり伝えないといけない
  • 上司に、「あなたはなぜこの組織を作ったのですか？」と聞けば良い
  • QAは作業する部門ではない。
  • テストそのものは目的ではなく、それによって評価することが目的。
  • バグを出すことが目的ではない。

Q. 品質保証活動の仕組みについて。

  • 最近もまあまあ変わってないと思う。
  • 奈良さんはどう思っているか？
    1. お気の毒だと思う。意味の分からない仕事をしているのでは？
  • 「なぜこんな仕事をしているのですか？」と聞かないといけない。
  • しかし、最近の企業は成熟しているので声が届きにくいが、技術で語りましょう

Q. 現状を打破するためには？

Q. どういう方法で学べばよいか？

  • 直接聞け！なのか論文を読め！なのか
    1. 何に困ってますか？
    2. ちょっとよく分かってない
      • 困っていることが分かってないと勉強できないはず

Q. 色々なことで失敗してきたからこその金言を伝えていると思うが、バッドノウハウがあれば教えて欲しい。

    1. こっちの思い込みで進んだ場合は絶対失敗している。データを見て、相手に確認しないで（裏を取らないで）進むと失敗する
  • つまり、開発側に押し付けてしまったので、裏付けを取って進めていくことが大事
  • take and give ではなくgive and take で進めていくべき

Q. 品質保証に対するネガティブなイメージは奈良さんのやっている時は無かった？

    1. ネガティブではないことなんて無い！
    2. 無くなることはない？
      • きちんと理解してもらわない限りはネガティブから解消しない

Q. 品質保証部の部長にどのようなアドバイスをするのか？

    1. 組織や自分の仕事がなんのためにあるのか？を伝える。
  • あと、クォリティマネジメントシステムを回すことが重要。

Q. 認証に対しての鍛え方がよく分からない。どのように鍛えれば良いか。認証に対して完全に答えられるようにしたい。

  • A.それは無理じゃないですか。議題に対して質問できることが大事。

Q. 顧客対応を品質保証部門がしてくれるのは、ネガティヴではないと思っている。そういう話をして欲しかった。

    1. 確かにその通り。しかし、それでも酒の場とかで言われることもある。

Q. よく品質のところで話題に出るのがKPI。指標を出せ、決めようとか言われる。しかしコンテキストが違えば意味がない。それによってプロセスを押し付けることにもなっている。これに全く同感であるがどのように組織に理解してもらえばよいか？

    1. 中間管理職の人が若手に教えるしか無い

Q. 奈良さんにとって品質保証とは何か？

    1. 特別な言葉にしたくない。自分の仕事に対して責任を取る。
  • 立ち止まって考える。
  • 振り返る。
  • この癖をつけること。
  • 自分の仕事に対して責任を取る、特別なことではない。
  • 立ち止まるためのメトリクス、振り返るためのメトリクスがある。