第5期レポート

第6回ソフトウェア品質保証部長の会 レポート

開催日:2014年4月9日(水)
新年度が始まり、部署移動や新入社員の入社など、新しい風がどの会社にも吹くと共に、バタバタと忙しい時期がやってまいりました。そのような中ですが、部長の会はほとんどメンバーに変更もなく、和やかな雰囲気のもと開催されました。
今回も前回と同様、前半は講演、後半には講演者にもご参加いただき、グループ討論を行いました。皆さん、遅い時間にもかかわらず、熱い議論を交わせたようです。

では、まずは講演について、ご紹介したいと思います。
『「品質にしっかり取り組めば、組織は賢く、強く、幸せになれる」のために』をテーマに、東洋大学経営学部教授であり、SQiP運営委員会委員長でもある野中 誠(のなか まこと)先生にご講演いただきました。
講演いただいた野中先生

概要

今回は、野中先生から「品質にしっかり取り組めば、組織は賢く、強く、幸せになれる」というフレーズに込めた思いについての話がありました。
はじめに、製造業における品質保証システムの事例と、そこでの「品質保証」の捉え方が紹介されました。市場シェアが低下して業績が低迷していた企業が、品質情報を一元化する品質保証システムを構築し、それが元となって、他社が容易に追随できないような画期的な商品が発売されたエピソードが紹介されました。そこでの「品質保証」とは、安心・安全を満たすこと、対価以上の価値を提供すること、潜在ニーズを満たすことと捉えられており、徹底した顧客志向を意味しています。ソフトウェアの品質保証においては、しばしば、仕様を満たすことや、必要な工数を十分確保してレビューやテストを行うことなどに焦点が当てられますが、それをベースとした上で、組織の活動を真の顧客志向へとより一層振り向けることの必要性を、他産業の事例を通じて再確認しました。
顧客志向で品質保証を捉える上で、顧客満足がどのような要因で構成されるのかを考えておく必要があります。講演ではACSI顧客満足モデルが紹介され、顧客満足に影響を及ぼす要素として、顧客期待、知覚品質、知覚価値の3要素が説明されました。ソフトウェアの品質保証においては「知覚品質」に目が向けられますが、顧客の事前期待を表す「顧客期待」や、価格に対する品質評価を表す「知覚価値」がなおざりになってしまいがちであり、顧客満足を追求する上での必要な視点を改めて確認しました。
一方で、顧客満足をもたらす製品やサービスを継続的に生み出すためには、組織能力の向上が不可欠です。講演では、東京大学の藤本隆宏先生が示されている組織能力、裏の競争力、表の競争力、収益力という4つの要素の関係を表す図を用いながら、これらの4要素に対してソフトウェア品質保証活動を関連づけることの必要性が主張されました。冒頭の製造業の事例は、まさに、この4要素がそろった品質保証活動であったと言えます。 品質は、顧客の満足で決まり、それを確実にすることが品質保証です。そして、品質のよい製品やサービスを継続的に生み出せる組織能力を涵養し、向上させるための活動をデザインするのが、品質保証部に課せられたミッションです。品質保証のあり方に一層の奥深さを感じることのできる、興味深い1時間となりました。

後半は、「経営視点」「品質保証の肝」「超上流からの品質保証」「人材育成」「アジャイルと品質」の5つのテーマ別グループに分かれ、討論が行われました。
それでは、各グループの討論内容を紹介いたします。

グループ1「経営視点から品質向上を考える」

野中先生に講演いただいた『品質にしっかり取り組めば組織は賢く、強く、幸せになれる』を経営視点から見て討議しました。
  • 藤本隆弘氏の「能力構築競争」の考え方から、品質部門の業務内容を見てみると、表の競争力や裏の競争力向上の活動はされているが、ものづくりの組織能力向上の活動にも着目する必要がある。
  • まずは、後戻りをなくすなどのコスト低減の活動が必要だが、品質重視の結果としての顧客からの信用・信頼が継続的な注文につながり、売上向上につながる。このことで利益の再投資で競争力をあげる。
  • 信頼性要求が高く、お客様も理解いただけているものには品質担保のコストをかけることはできるが、お客様要求がない(暗黙)ものの品質担保については、強弱をつけて対応はしているものの、手を抜いて良いのだろうか。
が品質部門のスタンスだ。 信用/信頼といっても、現場では
  • 市場の厳しさからコストが抑えられている
  • 納期優先/コスト優先で品質後追い
この悪循環で、ますます現場が疲労し競争力向上ができていない。
ここに品質部門が勇気をもって、踏み込むことも必要である。

グループ2「ソフトウェア品質保証の肝」

グループ2では、SW品質保証の肝を3期連続して継続検討していますが、今期の目玉として、“サービス品質について考える”、“SQuBOK体系図を網羅する品質保証の肝を考える”ことに取り組んでいます。

4/9のグループ検討では、特にサービス品質に関する現場の悩みを共有し、どんな肝があるかを検討しました。
具体的には、“サービスのSLAについてお客様が納得のいく設定ができない”という悩みについて議論し、SLAを契約で厳密に合意することが日本の習慣では難しい、しかしながら、お客様にSLAの理解を深めていただくためにも、サービス内容の見える化やルール化が必要で、各社が苦労しながらも実践しているノウハウを紹介し合いました。

これらについて整理した上で、さらに来月も継続して検討を深めていきたいと思います。

グループ3「超上流からの品質保証」

  • 各社で発生している超上流の不良の事例を確認すると見積り・受注時の条件定義、プロジェクト管理の問題等半数程度はプロセスで防げそうな問題であることが分かりました。
  • 品証として超上流にかかわっているグループ内事例を確認しました。要件定義、日程/リスク/品質/リソース管理等の側面から品証が上流設計の中間段階で現物を確認するプロセスを整備して、実施状況とその効果を評価している会社がありました。「Cooleye」「不良水平展開」を生かした取組みとなっています。
  • 一方、実際に超上流に深くかかわっている品質保証部門は少ないため、次回品質保証部長の会の中から具体的な事例をヒアリングすることとしました。
  • 今後各社の事例を参考に「顧客視点」、更には「魅力的品質の提案」、「顧客の為のリスク低減」のための超上流は何かを検討していきます。

グループ4「人材育成」

今回はまず人材育成の検討対象を前回から見直し、開発部門および品質保証部門とすることにしました。
議論があった業態については依存しない事にして、普遍的な品質意識を抽出、人材の質を上げる施策を探ることにしました。
進め方として、部長の会のメンバーにアンケートを実施します。
アンケート結果から自分たちが実施している育成策の不足の有無、施策自体の正しさを振返り、これから育成を考える方々への提言にまとめていきます。

グループ5「アジャイル」

今回は、アジャイルについての事例を各メンバーから紹介いただきました。

Aさん 受託系

  • 小規模な開発(半年位の開発)で、ST工程でお客様の思いと違うシステムになり、問題が発生するケースがあります。
    → 早く動くものを見せながら、このような問題が発生しないようにしたいです。
  • WF(ウォーターフォール)でも実際は工程完了していないのに、次工程を開始する。
    ex.要件定義ができたところから開発など。
    それなら、アジャイル式にどんどん作っていくこともできるのではないでしょうか?
  • WFでも、バグ票をちゃんと書いていない事実があります。バグ票云々より、テストケースの追加が重要です。
    そもそも、きっちりバグ票書で傾向分析をするより、テストケースで残したほうが効果があります。

Bさん 受託系

  • 要件定義と開発が別のメンバーで行われるが、要件定義をするメンバーが開発工数をうまく見積もれず、無理な予算での開発になることがあります。
    → アジャイルで、アジャイルチームの特性である「メンバーの多能工化」を利用し、要件定義ばかりやっていたSEに、実際に開発やテストをやってもらい体で覚えてもらうことで、この問題は解消できないでしょうか。
  • WF(ウォーターフォール)でも実際は工程完了していないのに、次工程を開始する。
    ex.要件定義ができたところから開発など。
    それなら、アジャイル式にどんどん作っていくこともできるのではないでしょうか?
  • WFでも、バグ票をちゃんと書いていない事実があります。バグ票云々より、テストケースの追加が重要です。
    そもそも、きっちりバグ票書で傾向分析をするより、テストケースで残したほうが効果があります。

Cさん 製品系

仕様を自分で決められる製品ですが、UXの向上をめざし、動くものを早く繰り返して作る反復開発に取り組んでいます。
  • 大きな要件定義から、ユースケースを作り、重要なユースケース単位に開発。
  • 開発部隊にQE(クオリティーエンジニア)を設置し、ユースケース検証を実施。
  • 品質保証部門(QA)は製品サポートノウハウを活かし、顧客視点で反復ごとに検査。
  • QAノウハウはどんどんQEに伝授し、QEで自動化。
これで品質を確保しています。

Dさん 製品系

  • アジャイルの上流工程から品質保証≒テスターが入り早い時点で問題を摘出、テストは自動化を進めます。
  • 内部品質を強化します。そのためにTDD、品証も内部品質をみます。
  • TDDを一歩すすめAcceptanceTDDへ
    要は、QAがチームの中に入り、利用者視点の知識を直接動くテストとして作り込みます。
以上の話から、結局のところ
「知識は文書に書いても読まれないが、体に覚え込ませれば自然に使う」
「知識は文書に書いても読まれないが、動くモノとして作れば皆が使う」
ということではないでしょうか。(A氏)

今回は、各自の思うアジャイルの事例や活用のアイデアの説明に終始しました。理解は深まりましたが、今後どうするかの議論は、メールベースですすめます。
グループ討論後の報告風景
次回はGW後の5月14日(水)です。
新緑の季節、過ごしやすい時期となり、より一層充実した討論ができるのではないでしょうか。

次回のレポートもお楽しみに!