ソフトウエアの品質目標って何ですか 3
【全社視点を持とう】
前回までは、主として開発部門を中心に品質目標をどう捉えたら良いかについてお話してきました。顧客満足から始まり、障害の主な原因はヒューマンエラーにある、として、その削減の為の方策を部門が用意し、適用する事を述べ、更に、ヒューマンエラーの原因となる人的因子(ファクター)に注目し、その相関関係を使って障害（ヒューマンエラーを目標とするためにどう考えるかを示しました。
今回、次に目を向けたい事は、「全社視点で考える」という事です。企業では開発プロセスに直接係わる部門だけが品質に影響を持つ訳ではありません。そこで次に考えるのが全社視点です。
話を進めていく前に、企業がどのように利益を得ているか、言い換えれば付加価値を創出しているかを考えてみます。先ず下図を御覧ください。
はい、お馴染み「バリューチェーン」の概念図です。但し、主業務をソフトウエア受託開発のメンテまで含めた点と、ゴールである「利益」に「→顧客満足」をつけた点が異なります。利益を生み出すと同時に顧客満足も得る、位の意味です。ご覧の通り、直接、製品・サービスの提供に係わるのは主業務ですが、支援業務はそれを支援する事で間接的に貢献しています。その様子を示すのが次の図です。
【支援業務はどのように主業務に関与するか】
これを見て、例えば「企業インフラ」は主業務全般にわたって活動拠点となる設備や環境の土台を作り、「人的資源」はどのプロセスに対しても人材の育成で貢献する事が用意に分かるでしょう。製品を作っているのは主業務だけではないのです。
同様に、「研究開発」は「開発」や「試験・検証」プロセスにノウハウを提供し、「購買・調達」は開発や営業に必要な機材を調達します。品質として製品に創り込む為には、それが「ここでこうすれば更に良い結果につながるのではないか」という視点で計画的に行われ、実現していく事が必要です。例えば営業と顧客の打ち合わせの中で技術的な話題が出た時に、研究開発からマッチする情報を得て顧客に提供し、結果として要求や仕様の決定に貢献する事があるかもしれません。逆にこのフェーズのやりとりが不十分なせいで、試験工程になってから仕様変更の憂き目を見るかもしれません。
このようにして全社的コラボ、という見方をしていけば、一部門、あるいはチームだけでは解決が困難な問題も、外部の支援や協力を得る事で容易に解決して結果として高い付加価値を創出し、顧客満足実現に貢献する、という流れを見つける事が出来ると考えられます。
【部門間協力は顧客満足のために】
いずれの場合も最終目的は顧客満足の創出にあるので、現状満たされない条件があるのならば、組織横断的な視点から、新しいしくみを検討してみるのも手ではないかと思います。
いきなりそれが無理なら、「支援業務の◯◯は主業務関連の□□の支援を△件は実施する」のようなスポット的な活動目標を立ててみる、という方法もあります。あるいは主業務の方から支援業務の◯◯にこんな事を手伝って欲しい、という意見が出るかもしれません。このように、主業務でなくても支援目標を設定する事は可能です。このように、全社が顧客満足獲得に関わっているという視点に立つなら、それぞれの立場からどういう形でその為の活動に参画出来るかを考えていく事が、企業全体の競争力強化にもつながってくると思います。当然ですが、一部門だけの閉じた空間内でどうにかなるものではなく、マネジメント主導の組織横断的な取り組みが必要です。
【顧客満足はどうやって知るの？】
1970年代にCS(Customer Satisfaction=顧客満足) というのが流行りました。営業畑で流行ったCRM(Customer Relation Management)のベースになる概念で、CSを維持する為に顧客との良好な関係性を構築し、維持する事を目指しました。
2000年代以降は同じCSでもCustomer Success という概念が打ち出され、おもにIT業界、クラウド分野で用いられる事が多くなっています。従来の、結果としての製品やサービスを売り、その利用により顧客満足を得るやり方ではなく、（クラウド）サービスそのものが顧客の行うビジネスモデルを支援し、その成功を約束する事で顧客満足を得る、というプロセス重視のコンセプトになっている点が違います。
【VOC(Voice Of Customer)分析】
それはさておき、最近では顧客満足を調査するサービスが多数見受けられます。そしてその多くは「VOC分析」という呼ばれ方をしています。
名前のままの意味ですが、VOC分析にはVOCの採集と採集した情報の分析という２つのステップがあります。
こうして見てくれば、VOC分析には大きく３つの要素がある事が分かります。即ち、以下の３つです。
①顧客とは誰か
②どうやって集めるか
③何を分析するか
世の中のVOC分析関連の情報も、この３つの観点から読んでいけばそれぞれの特徴が理解しやすいと思われます。
【①顧客とは誰のこと？】
本稿ではソフトウエア開発受託業務をメインに考察しているので、顧客の第一義はその発注者という事になります。但し、それで全てとは限りません。発注内容の製品・サービスが、更に一定の利用者を前提としていれば、その顧客にも顧客、ここではエンドユーザーがいて、そのエンドユーザーの満足が得られる事が顧客の満足に直接影響するからです。
【②どうやって声を聴く？ 発注者編】
では、発注者としての顧客から。
下図は「ソフトウエアの品質目標って何ですか？ 1」で掲載した図に似ていますが、下部が顧客満足の内容ではなく顧客の声を採取する方法になっています。考えれば色々あるでしょうが、ここでは３つ、考えます。
一番手っ取り早いのは直接訊く事ですが、プロジェクトを完了するまでは不用意な表現で波風を立てたくないのが現場の思いでもあると思うので、常にこれがベストな方法だとは限りません。
むしろ、[2]のように、プロジェクト外部（社内であっても）の窓口経由で色々と聞き出してもらう方が言い難い事も言ってもらえそうです。但し、色々聞いたのに改善されなかったりすると、顧客に失望感を植え付けてしまうので、こういう体制を作る場合はアフターケアをどうするかまで十分に検討しておく必要があります。
[2]の別パターンとしては、自社との開発経験がある別な担当者からその時の事を話してもらう、というのもあります。眼の前の相手の事ではなく、過去の話ともなれば、言い難さは薄れますが、余り時間が経過してしまっていたりすると、良くも悪くも臨場感が希薄になるかもしれません。
[3]はプロジェクト終盤で相手にお願いして開発プロセス全般を振り返ってもらう形で回答していただく類のものです。これでおしまい、というタイミングで行うのでお願いはしたけれど回答が無いまま終わってしまう可能性が高いです。
【②どうやって声を聴く？ エンドユーザー編】
次はエンドユーザーの場合です。基本、これも情報の集め方は似た様な感じになりますが、相手は不特定多数になるのでスケール感が違います。エンドユーザーの場合は開発プロセスには関与せず、開発完了したものを購入、使用した結果がどうだったかに焦点が移ります。
VOC調査の主要な大まかには手段は直接訊く、ソーシャルメディア経由、アンケートの３つが一般的の様です。本質的には発注者の場合と大きくは違わないのですが、調査対象のスケールが大きくなる点、開発プロセスではなく製品・サービスのライフサイクル中が声の収集時期に当たる点が大きく違います。いずれの場合においても何を知りたいのかをしっかり決めてから情報を集めないと、単なる徒労と自己満足に終わってしまう恐れがあります。
【③何を分析するか 四象限分析】
いよいよ本稿最後のクライマックス、集まったデータをどう活躍するか、に入ります。結論から言いますと、この分析はビジネスプロセスの継続的な改善のために行います。その改善の為にDMAICを使います。
では、分析がどうDMAICにつながっていくのかを見ていきます。本稿で使う分析方法は「四象限分析」、「四象限マトリクス分析」、「BCGマトリクス分析」、「ポートフォリオ分析」などと呼ばれる手法です。これは、縦軸と横軸にそれぞれ相反する基準を中心で交差させる形で置いて、その座標上に集めたデータがどのように分布させます。何をどう配置するかは分析したい内容に依りますが、やり方は同じです。
最初の事例は値段と機能、お気に入りの製品・サービスの価格と機能のバランス分布を例にとります。コストパフォーマンスが優秀なのは第四象限で黄色背景になっています。逆に機能の割りに割高感を感じる、という評価は第一象限で、赤背景にしています。
二番目は、典型的な例として、CS(Customer Satisfuction)ポートフォリオ分析を挙げておきます。満足度と評価項目の重要度によるマトリクスです。商品・サービスの利用結果に関しても、開発プロジェクト発注者から見た業者評価としても応用する事が出来ます。ここでは第一象限は「要改善」として赤背景にしています。第四象限は現状維持、第二象限は特に重点的な現状維持の対象として認識されます。この改善と現状維持はそのまま品質目標になり得ます。何度も言いますが、品質とは障害をやっつけた数ではなく、顧客が不満足だと指摘されない事だとすると、品質目標は第一、第三象限の指摘を削減もしくは出さない様にする事が最優先である事が分かります。第一象限の項目は、優先的にDMAICに引き継がれます。
【企業の競争力の要、ES】
最後にもうひとつ四象限分析の事例を挙げておきます。CSポートフォリオ分析と同じ視点をEmployee、つまり従業員に向けて適用すれば、従業員満足度分析が出来ます。
近年の研究では競争力の高い企業はESも高い事が知られています。ESが高いと生産性も高い事も知られています。従って、上図でいう第二、第四象限を増やし、第一、第三象限を削減する様な組織作りを進めていく事は、従業員にとっての働き甲斐だけでなく、企業の生存にとっても重要であると言えます。
【DMAICへ】
では、どのように引き継ぐのかをこれから示します。
例えばこんな感じです。流れを示す為に概略のみの記載になりますが、CSポートフォリオ分析図の第四象限の項目に着目し、問題としての定義、計測、原因究明、対策立案と実施へと流れていきます。その対策が、現行版でアプリの更新やホスト側のメンテ等で対応可能ならその対応が走り、それ以上の規模になるなら次バージョンや新製品の開発プロジェクトに引き継ぐ、という流れになるでしょう。
この様に、不具合の有無に関係なくCSで不満足を指摘される事は「低品質」と評価された事を意味するので、改善していかなければ、製品・サービスに不具合が無かったとしても、エンドユーザーが離れて最悪競合他社に負けてその製品・サービスは成り立たなくなってしまうかもしれません。
上記の改善プロセスにおいて④のImproveについて補足します。例えば、CSポートフォリオ分析からの指摘事項が発注者からの「書いたコードに不具合が多い」といったものだった場合、コードレビューの指摘数、指摘率を上げて、レビュー（即ち静的試験）の生産性を改善する事が直接的な品質目標となり得ますが、ここでも何もせずに目標数字だけ挙げるのではなく、レビュー方法の改善、静的コード解析ツールの使用、など、具体的な実行プランを決める事で目標値が品質改善プロセスとしての意味を持つ様になります。
この時最もリスキーなのは、それまでやってきた延長線上で改善策を実施しようと考える事です。むしろ、例えばPRINCE2で言う様に、いったんプロジェクトを停止し、最終的にビジネス正当性を満たすのに必要な条件を明確にして、それを満たした上で「例外により変更されたステージ」への移行を果たす方が現実的です。多くのプロジェクトはこれをやらない為に、炎上し、破綻への道を転がり落ちていくのではないか、と思います。
ここでいう「ビジネス正当性」とは、プロジェクトを継続していき、成果物納品まで行う事にビジネス上の価値がある、という意味です。これを評価するにはいくつかの指標があり、プロジェクトが健全に動いているかを知る為には各種モニタリング手法がありますが、それはまた別な話。興味を持たれた方はPRINCE2を調べてみてください。
本稿は、３回にわたってソフトウエアの品質目標という難しい問題に対するアプローチ方法のひとつとして、こんな考え方もあるのではなかろうか、という事を示してきました。無論、考え方は色々あり、現実に適合する手段も色々あってしかるべきです。このシリーズで述べてきた事のいくらかでも何らかのヒントにでもなれば幸いに存じます。
ソフトウエアの品質目標って何ですか？ 1
ソフトウエアの品質目標って何ですか？ 2