goo blog サービス終了のお知らせ 

ラン

定年後の人生、日々の ”こと” つれづれ思いつくままに・・・

品質保証業務(その1:はじめに)

2015年01月13日 | 品質保証活動のあり方
一般に品質保証の活動は、
テスト/検査を“実施する”ことに重点が置かれていることが多い。

これは「保証」ということをどのように認識するかというところでの問題であるが、
多くは、「バグがないことを保証する」という意味に解釈されている。

結果として、そのような判断も出来るが、その前に、適切にテストが実施される状況にあることを監査し保証する、という考えが重要なのである。

本来の「保証」の意味を正しく認識し、それに沿った活動が求められる。

品質保証(実践的品質保証)で述べたように、

品質保証の実践的な改善作業項目として、

・既存の品質保証手法と、より実用的な品質保証手法との継続的な比較、評価

・プロジェクト全体の適正なテスト体制の構築 及びテスト工程の計画と管理

というように、如何に適切にテストが実施される状況にあることを監査し「保証」するかである。

テスト/検査の実施と言うことで捕らえるのなら、企業によっては、

アウトソーシング化も含めて品質保証を実施する必要がある。

人材育成と人事管理(その3:メンタルヘルス)

2015年01月12日 | 品質保証活動のあり方
ここでは、IT技術者に多く見られる心の病気(精神障害)についてふれてみたい。

世の中の状況としては、

他の業界より一桁患者が多いと言う報告もあり毎年増加傾向にある。


【精神障害】

うつ病:

ー躁うつ病 (200人に一人くらい)

ー軽症うつ病(20人に一人くらい)

ー仮面うつ病(病識がない-自責的-自殺)、叱咤激励はダメな病気。


神経症:

ノイロ-ゼ、心因(ストレス)+性格、神経症的性格(自己中心的、未熟)


精神分裂症:

陽性症状(幻覚妄想)、陰性症状(何もしなくなる)


アルコ-ル依存度:

適度な飲みかたが出来ない、禁断症状がでる。

人材育成と人事管理(その2:適材配置)

2015年01月11日 | 品質保証活動のあり方
「 ソフトウェアは水商売と同じ」と言われているように人に依存する部分が多い、特に、

・具体的に物が目に見えない(ビジュアル化が難しい)

・人が最大の資源である(生産物の計量化が難しい)

・いかにみてくれをよくするか(付加価値)


それ以上に、上長と部下との関係が重要である。

・ 新入社員の人生は、配属先の管理者によって決まってしまうと言われるほど大切なポジションである。

・ 部下は、上長を3日でみる。上長は、部下を知るのに3年かかると言われている。

などである。

このためにも、人材の適正配置は重要である。


日常の作業状況をよく見て、

各人の適正に合った配置をするよう心がけなければならない。

品質保証部門の長は、

部門や自己の利害にとらわれず会社全体の立場で考え経営者の立場で配慮すること。

人材育成と人事管理(その1:品質保証部門の期待する人物像と特徴)

2015年01月10日 | 品質保証活動のあり方
一般的な人物像と特徴に関して下記に述べるが、

これからの品質保証部門の人は、設計・開発のみならずSE・営業も、

出来れば相手企業に出向するなどいろいろな体験をする必要がある。


【人物像】

(1)物事に対し、独自の判断と行動ができ説得力の有る人

   (相手を納得させて、作業を円滑に推進する必要がある)

(2)頭の切り替えが早く、幅広い知識・技術を習得できるマルチジョブ型の人

   (同時に複数のシステムや最新技術に類する製品を担当する)

(3)協調性があり、洞察力を発揮したい人または向上させたい人

   (プログラム、システム、プロジェクトの問題点を的確に捉え対処する必要がある)


【特徴】

(1)設計・製造部門から独立した社長直轄の組織とし、顧客の立場に立って行動する。

(2)所定の品質に適合しないシステム・製品を合格にせず、顧客に納入させない。

   (設計者はどうしても物事を狭く深く見る傾向があるが、品質保証部門では物事を広く見る必要がある。

    この為、幅広い知識、技術、判断力を必要とし、視野が広く、洞察力が必要 )

(3)少数精鋭(設計部門に対して、1%~5%の人員で対応)

   (1人1人が主役であり、全体が見えてやりがいが大きい)

品質保証活動の実践活動(その6:アフターサービス)

2015年01月08日 | 品質保証活動のあり方
アフターサービスは、
製品が出荷された後のフィールドにおける製品の品質保証、クレーム対応等を通じて、
顧客の満足度を向上するために行う。
また、「合格後の製品に対する責任は品質保証部門にある」との自覚を持ってアフターサービスに望むことが肝要である。

クレーム処理
フィールドからの製品に対するクレームは、一般的に営業やSEを経由して品質保証部門に連絡が入ってくる。
品質保証部門は速やかに事故の速報を発行し関連部署に展開する。
この場合「チームワークによるサービス」という基本的な考えに基づいて行動すること。
クレーム処理は、初動調査が重要であり、受付時に現象の把握と資料の採取(製品ごとに的を絞った調査表を作成すると良い)を十分に行う必要がある。

チームワークによるサービス
自分の担当製品でなくても、それに対する顧客の苦情や要望も伺い関連部署に正確に連絡し回答や対策などをフォローする心構えが必要である。
・ 他部署の製品であっても、協力し合って対処する。
・ 他人にかかってきた電話でも要件を聞いて、できる限り対応するよう心がける。
・ 問題解決に当たっては、上長や設計部署、その他関連部署の協力を得ること。
独力で解決しようとして、重要度や緊急度の判断を誤らぬこと。
・ 顧客からの要望事項は、担当外の製品であってもよく伺い、担当部署に連絡をすること。
チームワークで仕事をするときは、良いコミュニケーションにより、情報の流れを良くすることが大切である。

「報告、連絡、相談」→ホウレンソウ

【アフターサービスの品質水準】
社外事故連絡に対する回答日数:原則1日以内、一週間を超える場合は中間回答をする。
社外事故対策版の発行:目標一週間以内、最大でも1ヶ月とする等。
事故の対策は、顧客に及ぼす迷惑(不稼働時間)を最小限にとどめることを主旨として行動する。
また、事故の解決まで顧客が不安感をもって使用することを考えれば、一刻も速く解決するよう努めなければならない。
しかしながら、事故対策の失敗は、事故で失った信用を更に悪化させることになるので、慎重の上にも慎重を期して行わなければならない。
対策の遅れによる同件事故の再発もさることながら、対策失敗による二重事故は顧客の信頼を大きく損なう。
このため回避策がある場合は、十分な時間を頂き修正確認を誤り無く行う方が良い。

一般的には、各企業内で定めた「事故対策について(基本と心得)」と言ったようなマニュアルに従って行動すること。
プロジェクトが順調に進展し、最終の総合試験や運用訓練試験もほぼ予定通りに消化できれば、予定通りめでたく稼動にこぎつくことができるが、混乱プロジェクトでは中々バグ収束にいたらないで、顧客から「予定通り稼動できるのか?」、「何時になったら稼動できるのか?」等の厳しい判断を迫られることになる。

■品質安定状況の見極め
バグの収束状況を見るためにはバグ発見解決曲線が一般的判断資料となるが以下の事項に注意されたい。
・ バグ半減化(1/2)低減経験則(サチッても まだ半分 バグ残る)
多くのプロジェクトを見ると一般に単体テスト、組合せテスト、総合テストとテストの結合性が上昇するにつれて発見されるバグの数は段階的に約1/2(1/3~2/3)に低減する。
従って現在完了したテスト段階でN件のバグが発見されたとしたらまだ0.5N件前後のバグが残っていると推定せざるを得ない。
・ テストをしなければバグは発見されない(サボれば サチる バグ曲線)
バグ曲線の飽和状況を見て安定したと思うのは早計である。
テストをしない日はバグも発見されないから曲線は横ばいになるのである。
チェック項目の消化が進んだのにバグが発見されない時にはじめて安定状態になったと言える。
・ 何をテストしてきたのか(同じこと 何回やっても バグとれず)
この質問に的確に回答できるプロジェクトなら、テスト開始前に、テスト計画の設計がキチンと出来たプロジェクトであり、追加テスト項目として何をすればよいかすぐわかる。
とかく担当任せきりにしていると、追加テストをさせたつもりでも追加にならず、単に過去のテストのやり直しをしているのに過ぎないと言うようなことになってしまう。
バグ分析をして今までのテストでバグの多かった部位を狙ってテストするのは当然としても、網羅性となると怪しくなる。

■稼動開始可能日の判定
正しい判断は所詮無理であるが、品質安定状況、追加テスト日程計画等何時システムが稼動可能状況になるか判断せざるを得ない。
このためにも過去に経験したプロジェクトの実績や似たような他のプロジェクト例の実績データを集めておくことが必要である。

■事故発生時の影響を冷静に判断しよう
事故がおきたときに、迷惑を受ける人、影響を受ける対象範囲、影響を受ける時間など、多面的に分析し、事故の被害を顧客と共によく認識し合って、稼動に突入してよいかどうか判断しなければならない。
いずれにしても、稼動後の品質状況をいかに見通すかが重要である。
事故時に迷惑する人は:ユーザ社内だけ、+取引業者、+取引顧客、+一般顧客、+不特定者
影響を受ける対象、範囲:特定品(特定の口座/銘柄、製品/装置、列車/ホテル等等)か全対象か
影響を受ける時間:分以下、1時間以下、半日以下、全日

予防保守とは、
一度発生した障害を他の顧客で発生させないようにすることである。

一般には、最初の事故が発生した時には一生懸命対策するが、同件事故(同じ原因で二度目以降に発生した事故)には鈍感になる傾向がある。
しかし、顧客にとっては、それは初めての事故であり、重要性に変わりは無い。
かえって、原因が判っている不良を対処せずに放置されたとなると一層不信感を招く結果となる。

同件事故防止は、
品質保証部門の重要な職責であり、稼動品質を管理し社外事故が多発していたり同件事故が多いときは、予防保守を最優先で行う必要がある。
予防保守は、目的によって次のことを行う。

・対策版の作成
新たな顧客に出荷される製品に不良修正を行う物であり、社外事故の発生頻度に応じて発行する。
目標1週間以内、最大でも1ヶ月とする。

・修正情報の作成
重大な不良や同件事故の多発が予想される場合は、1件1件の不良対応にプログラムの暫定的な修正方法(パッチ)を、対象となる全顧客に適用する。

・マニュアル補足版の作成
次に示すような物があり、あくまでもマニュアルを補完する物でありマニュアルと同様に扱うこと。
ーマニュアルの訂正のお知らせ
ー使用上の注意事項のお知らせ
ー一時的制限事項のお知らせ等

品質に関するコンサルテーションは、今後、重要なサービスの一つとなる分野でしょう。

ここで述べる品質コンサルは、これまで述べてきたことを具体的に実践する際の援助である。

現実は、品質保証活動の組織そのものは、企業によって異なり、多くの場合、それは企業文化や歴史に依存する。

品質保証活動の規模や編成は、扱うプロジェクト、実装や関連するビジネスプロセスの複雑さによってさまざまに異なる。
更に、企業によっては、アウトソーシングも含めて品質保証を実施しなければならない。
アウトソーシング(品質保証活動そのものも含めて)に適している分野はどこか、社内に留保すべき領域はどこかを把握し、そうした企業の意思決定をも支援することになる。