基調講演 ICT応用S&S製品の品質不良のリスクとSQuaREシリーズ 国際標準(及び翻訳JIS)-その歴史と概要 #JaSST '17 Tokyo

講演者

  • 東 基樹

標準化について

  • ソフトウェアの標準化には皆さんの生まれる前からやっている。
  • 経営工学の基本は作業の標準化。重要なのは品質

NECでの思い出

  • NECでは、コンピュータの添付品としてお客さんのところへ行ったりした。
  • 私が入った年に倍々ゲーム。
    • 教育なんてできない。
    • ひどいサポートになっていた。
    • 仲間を集めて勝手に作業標準を作った。
  • 色んな様式、紙に埋めていく形式、本にしたらいっぱい売れた。マシンも売れるようになった。
  • PC8000が出てきたら、コンピュータを使うのはみんなになった。
  • 全社的な品質を野放しにすると全社的にひどいことになるよ。
    • →上の人がサポートして、全社的にバックアップしてもらった。
  • 全社会議で品質が大事と訴えた
  • それまでのテストは「動けばいい」という考えだった。
  • 品質展開、品質モデルを通じ、品質研究会を開いて、体験論文発表会を開いたりしていた。
  • 国際的にも論文発表していたら、早稲田大学に呼ばれた。
  • ずっと製品の品質というのは気になっている。

製品の利害関係者について

  • 以前はせいぜい数千ステップだったが、今ではメガ単位
  • 1ページの文章を書いたら1,2個のミスがあるのは当たり前。なので、誤りが無い製品というのはあり得ない。
  • SQueREでは利害関係者を重視していて、直接ユーザーに対する部分だけではない。
  • 直接ユーザーと間接ユーザーがいる。
    • 発表スライドでいえば、スライドを作る人が直接ユーザーに対して、そのスライドを見た人やこのスライドを広める人は間接ユーザーとなる。
  • ユーザーに対する品質も、どれも一緒とは言えない。
    • 中心ラインを踏むとアラームが鳴るのは良い面と悪い面がある
      • 良い面…中心線を超える
      • 悪い面…駐車中の車を抜かす
  • UNIXでプログラムを作るプログラマはカーソルキーが使えなかった。しかし、その状態が良いんです。実際、能率的に作業していた。しかし一般人は同じようにはできない。

SQueREの話

  • 国際的なユーザビリティのコミュニティがあるが、何にでも適用できると言い張る
    • 信頼性の低いものは…応答速度の遅いものは…どれもユーザビリティに直結する。拡大解釈して品質を飲み込もうとする。
  • SQueREは違う。エンドユーザーだけでなく、様々なステークホルダーのことを考えている。
  • SQuaREは「要求を満足する」だけでなく、暗黙的なニーズも範疇にしている。後は「当たり前品質」とか。例えば、寿司・刺し身には醤油が当たり前のように出てくる。サラダを頼むとドレッシングを聞かれる。「とりあえずビール」というと、銘柄を聞かれる。ステーキを頼むと焼き方を聞かれる。(フランスの場合はシェフに失礼。なんでも要求すれば良いわけではない。)

  • 良いものは設計から始まる。機能要求は書いてあることがあるが、品質要求が書いていないことが多い。

  • プルダウンの方が、ポップアップの方が…というのは品質ではあるが、最終的にはソフトウェアの機能要求に返ってくる。

  • 最初の品質モデルはKJ法。会議室の壁一面に「とりあえず品質の用語を張り出せ」「それをグループ化しろ」で出来た。

  • 「メトリクス」という言葉は今では使えない。カナダのオタワが猛反発した。メートル法ではないのでやめて欲しいという要求があった。

質問

なぜセキュリティは出てきたがセーフティは出てこないのか?

  • セキュリティはシステムの特性だが、セーフティは特性ではない。システムの結果として出て来るだけであり、利用時の品質で「リスク回避」にまとめている。

利用時の品質のところで混乱した。テストレベルの受け入れテストの部分と被っている部分がある。どういう段階で誰が使えば良いのか。出荷前の品質に携わっていた自分は使おうと思っていたが、出荷後の話も出ていた。

  • 利用時の品質特性と製品の品質特性の関連図を作っている。
  • 例えば、機能が不十分、使いづらい、保守性が悪い、これらを副特性のどれに関連するかというところから紐付けている。
  • しかし製品によって異なるので、一般的なものとしては出せない。
  • 実際にこれは今回のJaSSTのワークショップで体験してもらう。
  • 最終的には、製品に関わる人が体験してもらわないと難しい。