ソフトウエアの品質目標って何ですか？ 2
【組織的な品質目標設定のために】
前回はソフトウエア開発においてそもそも品質とは何かについて検討しました。その結果、品質とはバグの少なさや障害対応力の高さではなく、顧客が製品・サービスを使用した結果が、期待していた通りかどうか、つまりはUser Experience が得られるかどうか、という点にある、とし、開発プロセスにおいて品質に影響を与える障害の６つのパターンについて言及しました。
そして、その要因は案件ごとの内容の特殊性ではなく、主としてヒューマンエラーにより各フェーズで期待された役割が果たせず、十分なアウトプットが得られなかった為であることに触れました。例えば、要求検討フェーズできっちり要求の正当性を確認出来ていれば、後になって仕様が実現不可能な内容だった事が判明して、大幅な仕様改訂が発生して製品の完成や品質、コストに大きなインパクトを与えた、といった事を防止する事は可能だったのではないか、と考えられるのです。
障害は運や偶然で発生するものではなく、人が作り込む物である、という認識の上に立ってその主な原因であるヒューマンエラーを今一度見直してみましょう。
この様に見れば、案件の内容が何であったかに関係なく、開発プロセスのどの工程でどんな人的要因が障害に結びついたのか、どうすれば防止出来得たのか、という発想で対策を検討していく事はそれ程難しい事ではないと思います。
例えば、設計の段階である重要部分の見落としが仕様落ちを誘発し、出荷直前になって未実装が発覚した、という流れが想定出来ますが、これは、案件の内容に特定される流れではなく、なぜ設計段階で仕様落ちが誰も指摘出来なかったのか、という事が真の課題であり、それを解決する様々な対策やしくみ作りの活動こそが同種の問題発生を防止する、という意味で、品質改善活動であると言えるのではないでしょうか。
逆にどの様な案件が来て、どんなプロジェクトを立ち上げる場合でも、応用が効く原則的ノウハウとして活用していけるものになるはずです。少なくとも、プロジェクトをチェックする視点のひとつとして「これはどうなってるの？」という具合に応用する事は可能です。プロジェクトを立ち上げる度に「さて、何から手をつけようか」と考えるよりはずっと現実的で効率的でもあります。
この防止策は、試験工程で効率よく不具合を見つけ出し、解決する事で「品質が上がった」と安心するためではなく、どんなジャンル、どんな規模の案件であっても、プロジェクトが、ある程度以上のヒューマンエラーに対するコントロールが可能なしくみとして部門が開発プロセスをコントロールする事が出来る様にする為に策定します。
【ヒューマンエラーとのつきあい】
もういちど前回見た６つの人的要因を見てみましょう。但し前回とは並びを逆にしました。前は「障害の原因：対策」でしたが今回は「実施した対策：結果」になります。
左側の各項目は部門共通のしくみやノウハウとして用意すべきものと、それをどれだけプロジェクトに対して適用するかを示し、右側は、各項目として挙げられた障害の作り込みを何件に抑えるかを示します。
【部門の役目】
具体的に何を実施するかは部門により違います。上図の「顧客から正しい要求を引き出す」を例に取ると、これは右側で見る様に要求の誤りを防止するアクション項目です。要求検討の段階で、実際に何をしてそれを達成するかは部門やその部門が属する組織の事情により違ってくるのは当然の事です。例えば、
①営業の力を借りてコミュニケーションをとる、
②アンケートのような調査をこまめに行う、
③ターゲット関連の事情に詳しい人にレビューに入ってもらう、
④同様な開発経験のあるエキスパートの意見を聴く、
⑤過去の開発事例の社内外のナレッジを調べる
などがあり、そのどれをいくつ選択するかは企業や部門の事情と予算によるのです。あと、出来ればこれはプロジェクトの定常ルーチンが始動する前にやっておいた方が良いアクションになります。PRINCE2で言うところのビジネスの正当性に係わるからです。場合によっては最悪仕切り直しになる可能性も捨てきれない程のインパクトが予想されます。プロジェクトが本格開始する前に、
①何の案件か
②何を作るのか
③ふさわしい人材は誰か
④逆に、用意出来る人材で対応する為にはどんなフォローが必要か
といった事について検討するのは部門の役目です。営業が取ってきたから、その時手が空いている人を適当に割り振る、ではどんなプロジェクトにおいても安定した品質を保つ事は困難です。
プロジェクトが気兼ねなく支援を求める事が出来る様にするには、組織風土、つまり半ば精度的な枠組みで上記の様な体制をプロジェクトを組織する度に適用し、各メンバの努力を方向づけ、無駄な事で悩んだり肝心な事から逸脱したりしない様にコントロールするのは部門の役目です。
当然、そういった機能を果たす為に、部門には部門のノウハウや情報の蓄積、学習する組織としての運営が求められます。一見人やコストを割くのは痛手のようにも思えますが、プロジェクトを炎上させて多大な工数とコストを追加投入するよりはずっとましなのではないか、と考えられます。
【プロセス改善に向けて】
ここで前回ラストで紹介したDMAICの詳細を説明します。簡単に言うと、
顧客の声(Voice Of Customers)をベースにして現在行われているビジネス活動を分析してプロセス改善を進めていくための手法のことです。何故定番のPDCAではないのかについても書いてあります。
DMACとは、
①達成目標が何であるかを明確にする
・何を対象にするべきか：プロジェクト、障害状況など
・どうなっている事を可視化したいか：各種KPIの定義
②プロセス稼働とともに測定を実施する
・プロセスを実際に動かす
・決められた測定を実施
③そのデータを分析しながら、傾向を把握し、原因を解明
・測定結果を分析。①のKPI定義で何のための測定かを定義しているはず
・値そのものの大小、傾向、他のKPIとの関係が鍵
・課題を明確にする
④改善策を講じて結果を検証
・③で明確にした課題の対応策を立案、実施
⑤最終的な結果をまとめて後続に引き継ぐ
・ビジネスプロセスとして定着させる
という一連の流れによるビジネスプロセス改善手法です。⑤つのフェーズのどこで何をすれば良いかと、そこで主にどんなツール類を使うとよいかが検索すれば見つかると思います。
【人的な因子(ファクター)の扱い】
組織の体制が整ったところで改めてプロジェクトのパラメータとしての人的因子の扱いも触れておきましょう。例えば、ネットワークシステム構築の案件なのにネットワーク開発経験者がひとりもいないチーム、だとすんなり開発出来ると思えるでしょうか。誰でも最初は初めてなので、挑戦的な人員構成で臨む事もありといえばありですが、問題はそこではなく、メンバが因子的にどのような状態かを把握する事にあります。
この状態を今まで見てきたヒューマンエラーの６つのパターンと関連づければ、後のプロジェクトで人を選定する段階で、このプロジェクトではどんな形で問題が出やすいのかを予測し、最悪を想定した上で、部門からサポートやフォローを入れる体制を予め作っておく事が出来ます。方法は様々で、ある時期監修として加わる、とか、ピンポイントでアドバイザーとして有識者を入れる、とか、特殊な専門書をいついつまでに読ませる、とか、プロジェクトが本格稼働する前に、有効な手を打っておけるのです。こうした積み重ねが以降のプロジェクトで因子情報の信頼性を高めていく事になります。
因子の例としては以下の様なものが考えられます。
もちろんこれが全てではなく、こんな感じで現状に合った因子とその因子がとり得るレベルを設定しておきます。レベルは「0:知らない、1:知っている」とか「0:経験なし、1:経験あり」の様な程度で構いません。深く掘り下げ過ぎても持て余してしまうだけだからです。ただ、技術力や開発経験は３段階(0:未経験、1:５年未満、2:5年以上)位あった方が運用しやすいかもしれません。
このように、プロジェクトメンバの人的因子のレベルの分布状況と、部門が持つノウハウを適用した回数と、結果として発生を許してしまった障害の件数は、相関するデータとして活用可能なはずです。つまり、人的因子のレベル分布が分かればそのプロジェクトの障害発生件数がある程度予測可能という事になります。それであれば、それを更に低減する為に目標を設定し、それを実現する為に改善策を立てる、といった事も可能でしょう。
データを記録していく事の本当の意味は、このように将来の予測と対策に向けて活用し、部門の組織ノウハウのサポートを重ねる事により、重大な不具合を出さない様に導く事が可能になる事にあります。経験値が積まれてくれば同様のケースでどの位の因子の人員が揃えば対応可能かが測れる様になってきます。それこそ組織のノウハウで、障害/改修の報告だけを見ていてはいつまで経っても見えてこない部分でもあります。
【目標の数値化をどう考える？】
ここまで見てきたのは、主としてヒューマンエラーの主な原因への対策を組織的に実施する事により、問題発生を予測よりも削減した、という事により品質が改善された事を結論づけたい、という流れになります。
優秀な試験により問題を摘出し、改善に貢献する事も品質が改善された事の裏付けのひとつにはなりますが、あくまでも発券された問題の解決が主軸であって、問題発生プロセス事態への改善策を講じた分けではない分、品質の改善としては根拠に弱いと考えられます。つまり、プロジェクトが変わればまた同じ様に問題を引き起こし、対処し続ける可能性が高いのです。この
様な状況では次回は障害発生を◯件に抑える、という目標を立てたところでそれを実現する為に何をするのかも分からず、結局障害の発生を許してしまう事になりかねません。
つまり、因子と結果の関係づけがなければ、いくら目標数値を立ててもそれを実現する手立てに結びつかないのです。ソフトウエア試験のNG結果は、単に技術や経験不足による誤解や誤りのあるコードを書いてしまったからではなく、その不具合の発動を事前に防ぐ手立てが立てられなかった事が大きな原因となって引き起こされた、と考えます。
品質を本当に管理したいのなら、その発生を予測し、予測値よりも低い頻度に抑える為に必要な処置を実施するという流れを伴う必要があります。下図は目標設定の考え方を示していますが黄色背景の部分が目標になります。
目指す品質目標は、部門がプロジェクトに対してどの位の支援を行い、ヒューマンエラーの削減に寄与して、結果としてどの位顧客満足に貢献したか、という視点で捉える事が出来ます。
本稿で取り上げたヒューマンエラーのパターンは６つ。どんな対策が必要かも紹介しました。現実に部門でどのような施策としてそれを実行するかは部門次第です。
しかし、ここまで来てもまだ最終目標である「顧客満足度UP」までの道筋は見えていません。開発プロセスにおける問題削減までの道筋は見えましたが、それがどう顧客満足に結びつくかが不明瞭なためです。
色々と述べてきましたが、前にも述べた様に、これは筆者の拙い開発経験を振り返って、あのときああすればよかった、こうすればよかった、と思える事柄を元に組み立てている話です。
次回、顧客満足を高める為にどうしたら良いかについて検討します。いわゆるVOC(Voice Of Customers)分析と言われているものに言及します。筆者が見たところ、品質というよりは企業戦略を検討する為のツールのように見えますが、顧客の声を知るところまでなら流用出来そうなので扱います。