ソフトウエアの品質目標って何ですか？ 1
【品質ってそもそも何だろう】
品質（ひんしつ）とは何の事を言うのでしょう？
その定義についてはあちこちで言われているので今更くどくど述べる事はしませんが、本稿では顧客が開発結果のみを待ち受けている場合なら「サービスやプロダクトが持つ特性が、顧客の期待通りに機能している度合い」とします。言い換えれば、品質目標とは顧客満足度を高める、もしくは高いまま維持することを言います。筆者がそう考えるのは、本稿ではPRINCE2や品質工学の視点を取り入れようと目論んでいるからです。
品質は、運や偶然浮かび上がる物ではなく、プロジェクトが開発プロセスの中で作り込んでいくものです。そして、プロジェクトとは、ひとつとして同じものが存在しない、極めて独自性の強い、不特定な問題解決のための一時的な活動様式として知られています。このため、開発現場においてはプロジェクトごとに品質管理が行われはするものの、部門としての目標設定や実践が疎かになっている例が見受けられます。
【顧客は何に満足するか】
次に、ソフトウエア受託業務における顧客満足は、そもそもどように形成されるものなのかについて考えてみましょう。開発者はそこに品質目標を設定し、達成を目指す事が出来るのでしょうか。こういった問題について、これから検討していきたいと思います。開発プロセスのどこに顧客が満足するのか、ざっと記載してみました。あくまでもこんな風に考えていけば、という事例として書いているので細かい所を突っ込まないでください。
顧客満足という観点から見て最も重要なのは、やはり⑤の製品です。それが発注目的でもあるので、他が問題なくても製品がボロボロだったのではとうてい承服できない事は容易に理解出来ますね。
【「仕様書通り」は顧客満足か】
ここでもうひとつ、製品・サービスの結果に顧客の満足が得られる要因としての、「仕様通りに作った」、「リリースまでにバグは解決した」といった場合について言及しましょう。品質工学では品質とは顧客を満足させる事を意味するので、顧客満足が得られなければ仕様書通りに作ったからといって高品質とは言いません。結果として顧客が満足しなかったのであれば、その仕様がそれまでの品質ではなかった、という事になります。これは、確かにそういう一面はありますが、仕様書通りに作れば顧客はその結果出来た製品・サービスに満足するとは限りません。
一所懸命に開発し、問題解決もしたのに「こんなものを作って欲しかったわけじゃない」的なクレーム、エンドユーザーがいる場合、「ユーザーからこんな意見が来た」、「エンドユーザーには不評で見向きもされない」みたいなネガティブなフィードバックがあると、理不尽に感じる事があるかもしれません。
それは本当に理不尽なのでしょうか。後にならなければ判らない事もありますし、意図した機能は実装出来たが受けが良くなかった、なんて結果に終わるのも珍しい事ではありません。
製品に問題があった訳でもないのにクレームの種は山ほどあります。このようなケースは品質としてはどのように認識し、解決していけば良いのでしょうか。
単純に考えればこまめに承認を取れば良いじゃないか、と思えなくもないのですが、そもそも顧客が仕様を承認したからこそ開発したので、顧客満足度を高めるには結局のところ仕様策定の段階で、これ以上ない位に顧客と仕様の検討を進めて、期待外れな仕様を作らない様にする以外に解決方法はないのです。そこではコミュニケーションはもとより、顧客要求の視覚化や例えば、仕様がなかなか出てこないなら、何が原因で出せないのかを一緒に解決していく様なアプローチが必要です。顧客の決断を促す様な選択肢の提示や提案が有効な場合もあるでしょう。場合に依ってはこのまま時間だけが経過した場合のりカバー方法（制限事項の設定など）を協議する事もあるかもしれません。
こうして製品・サービスいずれの場合においても、顧客満足とはプロジェクトと共に存在する事は間違いない様に見えます。では、それは部門や企業にとってはどんな意味を持つのでしょうか。仮に、プロジェクトの運用管理が非常にうまくいって、高い顧客満足が得られたとしましょう。ここで最初に述べた事を思い出してください。プロジェクトはひとつとして同じ物は存在しないのでしたね。
つまり、あるプロジェクトの品質管理がうまくいって、高い顧客満足を得られたとしても、その結果を別のプロジェクトで活かす事は難しいのです。逆に、もしそれが容易であるなら、部門標準を設けて部門としてどんなプロジェクトにも適用する様な品質管理体系が構築出来るはずですが、現実にはそういう話は聞いた事がありません。結局は案件次第、プロジェクト次第、担当者次第の域を出る事はないように見えます。
【バグの無さよりUser Experience】
成功プロジェクトがある時、次にやるべき事は、そのプロジェクトが実施している開発手法、プロジェクトマネジメント、試験手法などを真似る事ではなく、開発フェーズにおいて、顧客満足度を上げる、または下げない為に、いつ、どんな事をしなければならないかを学びとる事です。
顧客満足とはどのようなものか、見直してみましょう。まず、最大の満足といえば、出来上がった物が期待通りだったという事になります。
それは、顧客の思いを開発が見事実現した、つまりは期待を満たすのに十分なUser Experienceを提供したという事でもあります。つまり、満足の本質は「良い物が出来た」事以上に、「それによってもたらされるものに満足する、という経験が出来た」事に焦点が当てられます。あくまでも、何が開発されたか、あるいはどうやって開発されたかではなく、顧客の意図を組み、目的を満たす機能を持つ物が出来た事に満足するのです。技術的な素養がある顧客なら、そこに使われたテクノロジーや開発手法に感嘆する場合もありますが、それが評価のメインになる事はありません。あくまでも期待されたUser experienceを実現するかしないかが満足を決めるのです。
では、そのUser Experienceはどのようにして提供する事が出来るのかについて考えてみましょう。
上図の「意図通りの」というところがミソです。これを実現するには、「これを実現したいならこのように動く事が必要だ」という事を理解していなければなりません。つまり、何を作ったら期待が実現出来るかが分かっている事が必要です。例えばこんな具合です。
顧客の要求は結局のところ機能や動作よりもUser Experienceに集約されます。「◯◯が出来ること」ではなく、「◯◯を実行した結果～になること」が真の目的である事が多いのです。
開発者目線はとかく「これを作ればいいんだろ」的発想に陥ってしまい、ターゲットを作る事を目的としがちですが、顧客はそうではありません。それを作り上げた所から真の目的へのアプローチが始まるのです。
こうなると、顧客満足を高める為にする事も見えてきます。例えばこんな感じではどうでしょうか。
そんなに何もかもいきなり上手くいくはずがない、とは思いますが、これで目指すべき目標はどんな風に考えれば良いかというと、例えば以下の様になります。筆者は案件の内容がどうであっても無視できない内容になっていると思いますがいかがでしょうか。
ここに来てようやく「仕様不理解」「仕様不備」「仕様変更」による問題発生や遅延、「技量不足」による誤実装や遅延、といった、開発者や品質管理者が通常ソフトウエアの品質を口にする時に、障害の原因として意識される課題項目が登場しました。注目すべきは解決したバグの件数や反応の早さではなく、その要因となった事象が何故起きたかを明らかにして、どうすればそれを削減し、結果として引き起こされる障害発生を減らせるのか、という事です。
【品質の天敵ヒューマンエラー】
ソフトウエア開発における不具合の原因は、ほとんどが人的要因によるものと言われています。人的要因以外、ここでは外部要因としておきますが、これには使用する外部モジュールのバージョン不整合、劣悪な作業環境、必要な機材不足などが考えられますが、先ずはヒューマンエラーから。
ヒューマンエラーは人知れず作り込まれ、多くの場合、創り込まれた後の工程で発覚します。後になる程遡っての修正コストは高くなり、影響範囲も大きくなります。
【６つの例から】
では、思考を進める為に、６つの例を挙げてみます。要求⇒設計⇒製造⇒試験と続く開発プロセスの中、試験プロセスで発見された障害の原因６つと、防止策として考えられる有効な技術と経験を対比させたものになります。これで全てというわけではありませんが、いずれもよくあるパターンだと思います。①～④は主としてテクニカルな要因で、⑤と⑥は時間、即ち納期、締切へのインパクトが大きな要因になります。
この６項目に対して問題を起こさない様にするのに役立つか必要になるスキルを対比させました。しかし、真の問題は、試験工程になるまでわからない、ではなく、もっと早い段階でなぜ指摘出来なかったか、という点にあります。では、ひとつずつ説明していきます。
では、詳しく見ていきましょう。
【①要求に問題があった の場合】
試験工程の後半になって、そもそも要求自体が実現不可能だった、なんて事が判明したらプロジェクトには大きなダメージになります。要求、設計、製造の各工程で承認を得てるのに、出来た物が不適合だったのですから当然です。理不尽に感じる人も多いでしょう。
しかし、本当に理不尽なのでしょうか。そこに到達する前に、もっと出来る事はなかったのでしょうか。要求そのものが適正である様に導くスキルがあれば、と考えられます。顧客が実現出来そうもない前提で要求をまとめようとした時に「それは現実的ではありません」とはっきり言える見識と発言力と代替案を出せる能力が求められます。自分の手に負えない問題がある時は、分かる人や情報源を捜す努力を惜しまないのもスキルのうちです。根拠を示す為には経験も役に立つでしょう。
【②仕様に問題があった の場合】
仕様通りにコードを書いたのに最終的に期待通りに動かなかった、というケースです。ソフトウエア自体は仕様通りなので、仕様に基づいた試験項目だけでは発見するのが困難な問題です。仕様の改変が必要になるため、それ以降の開発プロセスはやり直しになります。PRINCE2だったら異常を見つけた時点でプロジェクトの通常運転は停止し、そこまでして改修する価値があるのかを判断して例外や変更管理の管理フェーズに入るところです。その結果、改修した仕様を満たす方向で開発を続けたり、条件つき、つまり、制限事項つきで仕様を再決定して後続のプロセスを続ける、などの選択肢もあります。
こうした事態を防ぐ為に、仕様書のレビューは重大な責任を持ちます。誰がレビューするのかで問題点の指摘効率は随分変わってくるはずなので、要求事項のジャンル、使用技術の専門家、テストエンジニアなど、各カテゴリの専門的な観点から仕様の検証が出来る体制を作っておく必要があります。
そうはいっても投入出来る人材には限りがあるので、現チームには何がどの程度不足しているのか、あるいは全般に十分なのかを予め把握しておき、必要な所でチーム外に支援を求めるルートを確保しておけば安心です。
【③コードに問題があった の場合】
要求も仕様も問題ないが不具合が出た。調べてみたらコードが問題を抱えていた、というケースです。原因はコードを書いた人の仕様理解不足、またはコーディング力不足が考えられます。但し、開発経験はあっても全くのジャンル違いであったり、未知のフレームワークやライブラリを使わなければならなかったりする場合でも、誤解や思い込みによる間違いは発生します。
そういうケースに備えて、有識者からのアドバイスや注意点などが得られるしくみがあれば、コードを書く前に疑問点を解決して不具合の作り込みを防止する事は可能です。
【④試験に問題があった の場合】
試験仕様または試験方法に問題があって実施した試験が意味を成さなかった場合です。防止する為には要求や仕様を見て、何を試験すれば良いのか、どう試験すれば良いのかを判断出来る人の助言や参画が必要です。
【⑤仕様が決まらない の場合】
仕様が決まらない原因として、ここでは採用したい選択肢はあるが実現に向けて裏付けとなる詳細情報がいつ出てくるか未定（新しいライブラリやフレームワークが出る、とのみ言われてリリースが遅れている等）な場合と、そもそも選択肢が多過ぎてどれに決めたら良いか分からないケースを挙げています。
仕様未確定のまま開発を進めると、未定箇所を後でやろうとして忘れたり結局決定後のプロセスで間に合わなかったりして、未実装や不具合として残ってしまった、といった結果になりがちですが、これも防止方法としては「期日までに仕様を決める」「期日までに仕様を決めさせる」事が一番で、決められない原因を解決もしくは排除するにはどうするかを見通せるスキルや見識を持つ人の力が必要です。
②で述べた様に、PRINCE2なら、常時プロジェクトの存在意義を監視しながらプロセスを進めているので、このようなもたつきの結果。プロジェクトの正常な進行が停滞するのであれば、いったん通常のプロセスを停止して、それでも最後までプロセスを走らせて製品・サービスを完成させる事がビジネス的に価値があるのか、という判断を下す事になります。納入するのに足る価値が認められる仕様である事が、プロジェクト継続の絶対条件です。
【⑥仕様がよく変わる の場合】
これもドタバタを引き起こして気がついたら納期間近、という事になり慌てて実装したら障害続出、という時間圧迫パターンです。仕様がよく変わるのは、前工程でしっかり仕様を詰めていないからで、防止のためには後で変更の必要がない程検討しておく事が必要ですが、仕様の正当性をしっかり確保する程の技術力も欠かせません。
それと共に、後で変更する場合にどの様なリスクを伴うかをしっかり認識する事も必須で、変更内容、規模が及ぼす影響が現在のフェーズに与えるインパクト次第では、即時対応は諦めて、次世代以降のバージョンで実現する事にするか、関連する仕様に蓋をしてそもそも対象範囲の部分が実行される事がない様にして制限事項として申し送りする、といった対策を打つ必要があります。
いずれにしても、早く決断してプロセスを先に進める事が肝要です。
【品質管理の前に】
ここで述べた事は、ひとつとして特殊なものではなく、通常の開発プロセスにおいてよく見られる事象ではないか、と思います。というより、筆者自身の開発経験からくるものです。あのときああしていれば、という経験が山ほどあるので。。。
ヒューマンエラーを完全に防止する事は出来ませんが、発生しにくくなる様なしくみや体制を作って備える事は可能です。
【DMAIC(でぃーまいく)な試み】
品質管理を行い、品質目標を設定し、継続的な改善プロセスを走らせる、なんて事はあちこちで書かれていると思いますが、本稿ではよく言われるPDCAサイクルではなくシックスシグマ等で有名なDMAIC的視点からの改善プロセスを考えてみたいと思います。
以上はあらましなので詳しくはまた別な機会に述べたいと思います。ここではこんなアプローチ方法で品質の向上に取り組む事が出来る、という事を知っておいてください。
シックスシグマはもともとソフトウエア開発というよりも工業製品の生産現場で用いられてきた、米国モトローラ社発の管理手法です。
本稿は品質も障害も作り込むもの、という視点で述べています。作ってしまった物の問題を検出し、解決する流れではなく、最初から問題を作り込まない様にするにはどうすれば良いかに焦点を当てていくのでソフトウエア試験やデバッグ等に技法に興味をお持ちの方は、そちら方面の資料をご覧ください。
次回は、今回検討してきたヒューマンエラーと対応策や技術を、どのようにソフトウエアの品質に結びつけ、どのように部門目標として設定すれば良いか、についての検討を進めていきます。