ホーム > ブログ > 工藤 武久の記事一覧 > 【第71回】個別障害からの「一本釣り」品質マネジメントプロセス改善

【第71回】個別障害からの「一本釣り」品質マネジメントプロセス改善

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回は、開発ベンダーの開発部門と品質保証部門、発注側の3者の役割分担について考察しました。多面性を持つ品質の全体をうまくカバーするために、品質マネジメントプロセスを効率的に回していく必要があります。

今回は、本番稼働後に発覚した個別障害などを深掘りすることで、品質マネジメントプロセスの改善につなげるアプローチについて考察したいと思います。

 

【 「地引網」と「一本釣り」の営業戦略 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
今回のブログタイトルに「一本釣り」という言葉を使いましたが、これは顧客獲得のための営業戦略のメタファーとしてよく使われる「地引網」と「一本釣り」から転用しています。言葉のイメージから直感的にわかるように、「地引網」営業は、たとえばテレビのコマーシャルなどを通じた不特定多数の見込み客へのアプローチであり、「一本釣り」営業は、たとえば店頭のショーケースを覗き見している特定の見込み客に声をかけて、商品の売り込みをするようなアプローチです。

少し脱線しますが、「地引網」と「一本釣り」について調べていたら、NMB48の渡辺美優紀(みるきー)さんがファン獲得のテクニックとして使っているらしく、「釣り師」と呼ばれていることを知りました。

そのテクニックは、ブログやSNSなどで不特定多数の人を一気に引き寄せる方法(底引き網)と、握手会に参加したファンひとりひとりに対し、印象に残るような対応をすることで確実に釣り上げる(一本釣り)というものです。みるきーさんの「一本釣り+底引き網=大漁」という方程式は、営業戦略の本質をついているような気もして、勉強させられました。
ご興味を持たれた方は、「みるきー」+「一本釣り」などで検索してみてください!(※1)

これと同じように、システム開発プロジェクトにおける品質マネジメントプロセスの継続的改善も、「地引網」と「一本釣り」のアプローチがあります。

レビューやテストを通じて摘出された不具合すべてを対象として、定量的・定性的に分析するのが「地引網」のアプローチであり、本番稼働後に発生した個別障害の原因を深掘りすることで、品質マネジメントプロセスの弱点をあぶりだして改善していくのが「一本釣り」のアプローチです。

前回のブログで考察したように、開発ベンダーの開発部門と品質保証部門、発注側が役割分担して、それぞれのPDCAサイクルを回して品質保証活動を行っても、現実のプロジェクトにおいては、なかなか本番障害がゼロになることはありません。

逆に言うと、それだけがっちりとした品質マネジメントプロセスをすり抜けて本番障害につながったということは、どこかに落とし穴が潜んでいたということを示しています。その落とし穴を個別障害の深掘りによって見つけ出そうとするのが、「一本釣り」による品質マネジメントプロセス改善のアプローチということです。

 

【 「一本釣り」による品質マネジメントプロセス改善の手順 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
では、個別障害をもとにした「一本釣り」による品質マネジメントプロセス改善の手順を具体的に見ていきましょう。

図1に本番障害が発生した際の対応の流れを示します。障害発生時には、当該事象への対応(右側)だけでなく、同じような障害が他にも無いかの確認(類似見直し)、および、同じような障害をまた作り込まないようにするための対策(再発防止策)(左側)も同時に進める必要があります。

簡単に流れを説明すると、障害が発生した際に最初に行うことは、その障害によって業務にどんな影響が出るかを調査の上、その影響を最小限に食い止めるための暫定対策を実施します。システムを構築した開発ベンダーの立場からすると、早く障害を改修したいという思いが先立つかもしれませんが、既に本番業務が始まっている場合には、システム改修よりも本番業務への影響を食い止めることを優先して考える必要があります。

その上で、障害発生経緯などの情報を収集し、障害が発生した箇所を特定した上で、再現テストなどを行って直接原因をはっきりさせます。直接原因とは、プログラムのバグやオペレータの操作ミスなど、障害をひき起こした直接的な原因であり、技術的原因と言い換えてもかまいません。

直接原因が特定できれば、それを改修することで当該事象に関する本対策を実施することになります。また、直接原因をもとに、他にも同じ技術的原因による障害が潜んでないかを横展開(類似見直し)して、同種障害顕在化の未然防止を図ります。

さらに、そもそもその直接原因がなぜ作り込まれてしまったか、なぜレビューやテストで摘出できなかったのかをさらに追及(根本原因分析)していくことで、何重ものPDCAサイクルを回すことで万全だったはずの品質マネジネントプロセスの弱点をあぶりだし、再発防止策を検討するという流れになります。

以前私が開発ベンダー側にいたときは、本番障害が発生した際には上記のプロセスを全て踏んだうえで、これを障害報告書としてまとめ、発注側であるお客様の担当者の方に報告するということを何度も経験したものです。

障害発生から暫定対策実施まではできるだけ速やかに報告(速報)、本対策実施までは翌日ぐらいまでに報告(中間報告)、そして再発防止実施までは組織的な対策が必要なこともあるので少し時間をかけさせてもらう(1週間ぐらい)感じです。報告書をまとめるために短時間で調査し、何回もレビュー指摘を受けて書き直すことにより、何度も徹夜したことを思い出しました。。。

 

【 障害発生の問題構造と根本原因追究 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
さて、図1で示す根本原因分析を行うときの深堀りに使うのが、「なぜなぜ分析」などの問題解決テクニックです。「なぜなぜ分析」の手法については、さまざまなバリエーションがあり、直接原因の特定までに使うこともあると思いますが、私のこれまでの経験でいうと、直接原因特定までが一つ目の「なぜ」であり、そこを出発点にして「なぜなぜ」を繰り返して根本原因にたどりつくまで五回ぐらいの「なぜ」を繰り返すことが多かったと思います。(※2)

「なぜなぜ分析」などで根本原因を追究するのは、直接原因やその類似見直しによる対策だけでは、障害が作り込まれ、レビューやテストなどの品質マネジメントプロセスをすり抜けてしまった原因まで解消しているわけではないので、また同じような障害が再発する可能性が残されているからです。対策が「モグラたたき」にならないようにするために、根本原因を追究し、抜本的な再発防止策を検討する必要があるのです。

ここで注意しなければならないのは、根本原因にたどりつくためには、障害の原因を直線的にたどっても答えがでないことが多いということです。図2で示すイメージのように、本番障害の発生原因はいくつもの問題が重なっていることも多く、ひとつのルートをたどるだけは根本原因を的確にとらえられない可能性があります。

根本原因も複数ある場合も考えられるので、そう簡単に関連するステークフォルダー全員が納得するような「なぜなぜ分析」の結果が得られないのです。「なぜなぜ分析」を実際に経験した方ならわかると思いますが、正解は一つではなく、最終的にはCIOなど重要なステークフォルダーによる鶴の一声で根本原因と再発防止策が決まってしまうことも起きたりします。

また、せっかく「なぜなぜ分析」を行っても、横道にそれたり、なんとなく思い浮かべている再発防止策の裏返しを根本原因に誘導したり、結局は直接原因を作り込まないように要件定義や外部設計などの上流工程のレビューチェックリストに障害事例を盛り込むだけでお茶を濁すという再発防止策になってしまうケースも見てきました。そうなると、当ブログの 【第61回】レビューチェックリスト地獄からの脱出大作戦! で示した「レビューチェックリスト地獄」に陥ってしまいます。

したがって、個別障害をもとに「なぜなぜ分析」を行う場合の心構えとしては、深堀りを行う段階では「もともとの個別障害の原因を深掘りする」というよりも、「もともとの個別障害をきっかけにして品質マネジメントプロセスの弱点をあぶりだす」ぐらいの感覚で、分析を進めた方が、実のある結果に結びつくと思います。

ただし、やり方を間違えれば分析結果が発散してしまうリスクもあるので、最終的にたどりついた根本原因に対する再発防止策が、もともとの個別障害の再発防止になっているかという検証作業は必ず行う必要があります。

今回は、個別障害を深掘りして品質マネジメントプロセスの改善に結びつけるアプローチを考察してきましたが、「地引網」と「一本釣り」により厚みのある継続的改善につながることは確かだと思います。そして、このことは、当ブログ 【第68回】私の履歴書~3次元逆T字型人間の作り方 でご紹介した「幅の広さ」と「専門性」に加え「経験」という3つの軸による「3次元逆T字型人間」像と類似性があると思います。どんなことでも、縦と横の2つの軸で面積を広げ、さらにそれを継続する(経験を積む)ことで安定した立方体になり、結果に結びつけることができるのではないかと思います。

「地引網+一本釣りのアプローチで、品質マネジメントプロセスの継続的改善につなげよう!」

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 「渡辺美優紀」『フリー百科事典 ウィキペディア日本語版』
2016年2月23日 (火) 05:00 utc https://ja.wikipedia.org/wiki/渡辺美優紀

※2 「なぜなぜ分析」『フリー百科事典 ウィキペディア日本語版』
2014年5月17日 (土) 21:37 utc https://ja.wikipedia.org/wiki/なぜなぜ分析

Pocket

目次

Profileプロフィール

工藤 武久
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事

PMI®公認教育プロバイダー(R.E.P:Registered Education Provider) 株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。
PMI Registered Education ProviderロゴおよびPMBOK®Guideは、PMI®(Project Management Institute, Inc.)の登録商標です。
IIBA®認定教育プロバイダー(E.E.P:Endorsed Education Provider) 株式会社アイ・ティ・イノベーションは、IIBA®(International Institute of Business Analysis)の認定教育プロバイダー(E.E.P:Endorsed Education Provider)です。
IIBA®BABOK®およびBusiness Analysis Body of Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。