2015年07月04日

型にはまった「なぜなぜ分析」

同じテーマについていくつかのグループでなぜなぜ分析を行うと、ぜんぜん別の方向に行ってしまうことがあります。
それぞれ別の切り口で分析されていて方向が違うのならば、最後になぜなぜ分析とDAR(決定分析と解決)のやり方で採否の決定を行えばいいのですが、そもそも分析の進め方が迷走してしまっている場合も少なくありません。
慣れるまでは分析の仕方をもっと型にはめた方がバラツキがなくなるんじゃないか?という話もあったのでなぜ1からなぜ3までをスムーズに行うための以下のような型を作ってみました。

なぜ1:誤った行動
なぜ2:誤った判断
なぜ3:判断の根拠

例えばこんな風になります。

なぜ1:誤った行動
担当者は変数に誤ったパラメータを設定した

なぜ2:誤った判断
パラメータにセットする値を前回と同じで良いと判断した

なぜ3:判断の根拠
詳細設計書にパラメータに関する情報の記載がなかった


なぜ3まではこんな感じで型にはまった分析を行って、なぜ4以降で詳細設計でなぜ抜けたかをプロセスの観点で分析すれば良いわけです。
まあ、何でもかんでもこの型にハマるとは思っていないので、迷ったときに覚えておいた方が良いくらいの感覚で頭に入れてもらえれば、そのうちに役に立つことがあると思います。



cmmi_husa at 23:03|PermalinkComments(0)TrackBack(0)なぜなぜ分析 

2015年06月08日

目標未達をなぜなぜ分析する

なぜなぜ分析は基本的に業務上のミスを分析してプロセスの改善策を導き出すものです。
しかし、セミナーの受講者の中には目標未達のような問題をなぜなぜ分析しようとしてハマってしまう人も少なくありません。
では、こういったテーマをなぜなぜ分析するにはどうすれば良いのでしょう?

QCDの目標未達、品質目標やコスト目標、納期の未達といった問題は目標達成を阻害する複数の要因から引き起こされている場合がほとんどと思います。このよう場合にいきなりなぜなぜ分析すると、なぜ1にたくさんの原因が出てきてしまって混乱してしまいます。まずは、どの阻害要因を優先的に対策していくかということを整理してから分析を始めるとうまくいきます。
品質問題であれあ不良要因別の発生数、コスト問題であれば費目ごとの費用といったように分類し、それぞれの定量データについてパレート図を作成し、上位の要因を優先的に対策していくわけです。
目標未達の80%は20%の要因で占められていると言われます。つまり、上位20%の項目を対策すれば80%の要因について対策したことになるのです。
もうちょっと簡単に言うと、10項目の阻害要因があった場合、パレート図を描いた結果上位2項目の要因をなぜなぜ分析して再発防止策を実施すれば効果的であるということです。

この分析手法は開発や製造の現場というより、マネジメント側で使える手法だと思いますので、実践してみて下さい。
重要なことは必ずパレート図を描いて優先度を評価するということです。定量データを示すことで、再発防止策の有効性の裏付けになりますから。。。

cmmi_husa at 21:48|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2015年06月07日

なぜなぜ分析のポイント:開発のバラツキを考える

以前、なぜなぜ分析とQPM(定量的プロジェクト管理)なぜなぜ分析のポイント:スキルや経験にバラツキがあるのは当然でも書いていますが、問題が発生する要因として開発のバラツキというものがあると思います。
開発のバラツキとは、要するにアウトプットの粒度にバラツキがあるということです。よく、「あの人の仕様書は細かいところまできちんと書かれているけど、こっちの人はずいぶんざっくりだな〜」と言うようなことはないでしょうか?これは仕様書を書くにあたって、どれくらいの深さまで書くとかどのように書くかということがきちんと規定されていないため、もしくは規定されていてもそれを守っていない為開発者が自分で好き勝手に書いているということです。
このような状況であれば、スキルのバラツキを埋めるために教育も必要ですが、もう一つ重要なのは仕様書の粒度を揃えていくような改善を実施することです。

改善の例としては仕様書作成のガイドラインを作成し、仕様書のテンプレートを作って型決めするというのも一つの方法ですが、ソフトウエアに限って言えばUMLのような手法やツールを導入するというのも一つの方法です。UMLは私も経験したことがありますが、10年選手と2年目の若手が同じロジックの設計を行った時に、アウトプットが同じになってちょっと驚いたことがあります。その時、この手法はとても有効だと感じました。
回路設計なども似たような考え方で、たとえばタイミングのシーケンスをタイミングチャートを描くとかUMLにもある状態変化をステートマシン図で表現するというようにツールを使うと下流の開発者との意思の疎通が取りやすくなります。意外と回路設計ではタイミングの問題があって、開発者に聞いてみると頭の中で考えて回路に落としました。。。というようなことが多くあるようです。
構造設計だと3Dシミュレーションを行うとか設計変更の時はDRBFMの考え方を導入するといった対策もあると思います。

設計の粒度にバラツキがあるという場合は人に頼った対策になりがちですが、プロセスの改善案として積極的にツールの導入を検討し、安定したプロセスを構築していって下さい。特にCMMIのレベル4以上を目指す組織では必須の活動となります。

cmmi_husa at 02:20|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年06月06日

なぜなぜ分析と特性要因図

いろんな人のなぜなぜ分析を見ていると、事実の部分がよくわからないまま分析しているケースをよく見ます。
例えば、ソフトウエアに潜在バグがあって何らかの条件が重なって障害を引き起こした場合、ソフトウエアを開発してからかなり時間が経っており開発者も既に組織にいなかったりする場合があります。
それでも原因究明し再発防止策を報告しなければならないケースというのはあると思います。
この時、想定されるすべてのケースについてなぜなぜ分析を行うのか、それとも何か一つのケースについてなぜなぜ分析を行うのか迷う所です。

このような場合は、まずは特性要因図を書いてみるというのも一つの方法だと思います。
ところで皆さんは特性要因図というのをご存知でしょうか?
QC7つ道具のひとつで、ある問題に対する要因を挙げて、その要因を引き起こす要因を考えていく分析方法です。
なぜなぜ分析と違うのは、原因分析ではなく要因分析である点です。
つまり、問題を引き起こした誤った行動を深堀するのではなく、引き起こす可能性のある要素をすべて挙げていくという点で違っているわけです。
ここでは特性要因図の書き方の説明はしませんが、分析結果が魚の骨に似ているためそのまま「魚の骨」と呼ぶこともあります。

魚の骨が描けたら、引き起こす可能性の高い要因やリスクの高い要因をピックアップしてそれについてなぜなぜ分析を行っていきます。
つまり、数ある問題を引き起こす要因の中から分析の対象とする要因を選択するのにも、きちんとロジカルに考えて分析の対象を選択しましょうということです。

最初に説明したようなケースでは、なぜなぜ分析の中で特性要因図を作って締まっている場合が良くあります。
なぜなぜ分析と特性要因図の違いをよく理解し、事実確認が困難なときに組み合わせて使えば分析もやりやすくなると思います。



cmmi_husa at 12:39|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年05月31日

なぜなぜ分析のポイント:技術的な課題はなぜなぜ分析の前に解決する

問題が発生した際、その再発防止策を検討するときに、技術的な課題をなぜなぜ分析しているケースがよく見受けられます。
そもそも技術的な課題をなぜなぜ分析で解決することはできるのでしょうか?

例えば、ソフトウエアの障害について技術的な原因を見つけるには、実際のデータを流してみるとか、パラメータを監視しながらソースコードを1ステップずつ実行するとか、そういった対応が必要です。決して机上のなぜなぜ分析で技術的原因がわかるものではありません。ハードウエアでも同様で、オシロスコープで波形を見るとか、顕微鏡で破壊したチップの断面を見てみるとか、なぜなぜ分析とは違うレベルの調査が必要です。

なぜなぜ分析はあくまでもプロセス上の根本原因を見つけて再発防止策を導き出すためのものなので、こういった技術的な原因調査とは違ったアプローチをとる必要があります。

順番から言ったら、技術的な原因調査が先で、なぜなぜ分析があとになります。まずは技術的な原因を調査し、ソフトウエアならパッチを提供するとか、ハードウエアなら対策済みの基板と交換するとかといった処置が必要です。そのあとに、設計の進め方やレビュー、テストのやりかた等の開発プロセスについての根本原因分析を行い、プロセスの改善を実施します。

ここを分かっていないと上手に分析できないので、是非意識して分析を行ってみて下さい。

cmmi_husa at 12:35|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年05月28日

なぜなぜ分析のポイント:スキルや経験にバラツキがあるのは当然

開発者がなぜなぜ分析を行っているのを見ると、根本原因に「スキルに差がある」とか「経験値が人によってバラバラ」というようなことを書いて、再発防止策に「教育を行う」というような分析を行う人がたくさんいます。
確かに教育でカバーできるレベルのものもあるでしょうが、そもそもスキルや経験にバラツキがあることは良くないことなのでしょうか?
入社してからずっと同じプロジェクトで仕事をしている同期ならそれほどスキルや経験にバラツキがでないのかもしれません。しかし、入社年度も違うし、他の部署から移ってきたり中途入社の先輩もいるかもしれません。
要するにそれぞれの開発者が経験してきたことや、いままで経験した仕事が違うわけですから、スキルや経験が違うのはむしろ当たり前のことなのです。そして、このようなスキルの差というものは、何かの教育で簡単に埋まるものではないと考えています。
では、なぜなぜ分析ではこのような場合、分析をどのような方向に持って行けば良いのでしょうか?

考え方のベースはやはりプロセス指向です。つまり、スキルや経験の差を埋めるものがプロセスであると考えるのです。
スキルが高く、経験豊富な先輩のやり方を標準プロセスとして定義し、そのやり方を守って他の人も開発を行っていけば、アウトプットの品質は自ずと安定してくるはずです。
もちろんその中に教育も入ってきますが、改善の中心は手法や開発の粒度を合わせるところに焦点を合わせた方がより効果的です。



cmmi_husa at 21:33|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年05月11日

なぜなぜ分析の前に5ゲン主義で事実を把握

なぜなぜ分析を始める際の最初のステップは事実を把握するということです。ここを疎かにすると、真の原因に辿り着けないばかりでなく、間違った原因に辿り着くこともあります。つまり、なぜなぜ分析のプロセスの中でもっとも重要な部分と言えます。
しかし、意外とこの「事実の把握」が疎かになって、予測した状況をもとになぜなぜ分析を始めているケースをよく見ます。
きちんとミスをした現場でヒアリングを行ったり、仕様書の内容を確認したり、メールのやり取りを確認しながら事実を正確に把握して分析する必要があります。

このようになぜなぜ分析にとって非常に重要な「事実の把握」ですが、実際にはどのように行えば良いのでしょうか?
「事実の把握」のやり方として、5ゲン主義というのがあります。ご存知ですか?
5ゲン主義というのは「現場」「現物」「現実」の3現と「原理」「原則」の2原を足したものです。じゃあ、3現って何で、2原って何ですか?ということですね。真面目な解説はネットを調べれば出てくるのでそちらにお任せするとして、もうちょっと身近なネタで説明をします。

刑事ドラマで考えて下さい。
ジーパン:「矢追町3丁目で殺人事件発生!」
ボス:「ジーパン、デンカは現場に急行してくれ。ヤマさんとチョウさんは聞き込みだ!」

そう。現場検証や聞き込み調査が3現の調査です。

夕方、刑事たちが署に戻ってきて、ホワイトボードに写真を貼って捜査会議をしています。
ボス:「仏さんとその男はどういう関係だ?」
ヤマさん:「男は殺された男に多額の借金をしていて、しつこく取り立てられていたようです。」
ボス:「金銭トラブルは殺人の動機になるな。。。」

これが2原です。つまり「○○ならば△△」のような、世の中の法則です。

このように実際に起こったことを調べて3現をおさえ、2原を使って関連性を結び付けていくというのが5ゲン主義のプロセスです。なぜなぜ分析を行う際は、この刑事ドラマのやり方で事実を把握していくといいですね。

どうでしょうか?わかったような、わからないような。。。?

他にも5W1Hや4Mや3Hのような考え方もありますが、そちらは別の機会に。。。

cmmi_husa at 23:51|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年04月03日

なぜなぜ分析で真の原因が「レビュー不足」となった場合の再発防止策

なぜなぜ分析でソフトの障害を分析していると、しばしば「レビュー不足」が原因となる場合があります。
「レビュー不足」が真の原因か?という議論もありますが、今日はそこの議論は置いといて「レビュー不足」の時の再発防止策を考えてみます。
真の原因が「レビュー不足」となった場合、再発防止策として「レビューチェックシートに漏れていた項目を追加」と書かれているケースを非常に多く見かけます。
レビューチェックシートに項目を追加することで再発は防げるのでしょうか?

レビューチェックシートに項目を追加することにより全く同じ原因による障害は発生しなくなるかもしれません。
しかし、なぜなぜ分析で目指すのはプロセス改善により類似の原因による障害の発生も防止することです。
チェックシートへの項目追加も必要ですが、もっとプロセスの問題も深堀りして対策しなければならないかもしれません。
「レビュー不足」を引き起こす要因としては以下のようなものがあります。

1.レビュー時間が不足している

レビューを行う際は過去の実績をもとに1枚当たりまたは規模当たりのレビュー時間の基準を作っておきます。これに対して実際のレビュー時間がどの程度かい離したかを測定し、ある一定量以上または以下のかい離があった場合はレビューの十分性について評価します。例えば、「画面仕様のレビュー時間は基準より50%下回っていたが、これは共通コンポーネントを利用した開発でレビュー対象の差分は50%以下であったためである」のような感じです。

2.抽出されるバグが少ない

レビュー時間と同様に、仕様書の指摘数やプログラムのバグ数についての基準を作っておき、基準に対して大きくかい離している場合はレビューの十分性について評価します。

3.レビュー観点がもともと足りない

レビュー観点が足りなかった場合は、単に不足していた観点を追加するだけでなく、項目作成時と現在の開発環境の変化等にも着目し、レビュー項目の総点検を行うなどの対策が必要な場合があります。
クラウドの利用やネットワーク環境の変化、オフショアなど様々な環境の変化がレビュー観点に盛り込まれているか、再点検してみて下さい。

上記のような観点で「レビュー不足」に対する分析を行うと、これまでと違った再発防止策がでるのではないでしょうか?

cmmi_husa at 16:04|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年03月22日

製造部門においてC(コスト)とD(納期)を改善するなぜなぜ分析

なぜなぜ分析はQCD(品質、コスト、納期)の中の品質を改善するためのツールとして活用されることが多いと思います。しかし、経営というものはQCDのバランスをとりながら改善を行っていかなければ成り立たないので、コスト、納期の改善にもなぜなぜ分析を活用できないか?ということになります。

製造ラインでは組み立て設備や加工設備、試験設備など様々な設備が稼働しています。これらの設備の稼働率を上げることがコスト、納期の改善につながりますので、ここでなぜなぜ分析を活用することを考えてみます。

設備の稼働を妨げる要因としては、設備故障やチョコ停、段取り替えや部品欠品などがあります。例えば設備故障やチョコ停を考えた場合、現場の設備担当者はいち早く設備をもとの状態に戻してリスタートしようとします。そして、設備が動き出せば一安心。。。ということの繰り返しになっていることが多いようです。
ここで、設備故障やチョコ停を引き起こした原因をなぜなぜ分析で深堀りし、根本原因に対する再発防止を実施することで設備故障やチョコ停を減らし、その結果コスト、納期を改善するという活動につながっていきます。
もちろん、段取り替えや部品欠品にもこの考え方を取り入れることでさらなる稼働率向上を目指すことができます。

なぜなぜ分析はフィールドでの障害など、品質問題を解決するツールとして考えられることが多いですが、見方を変えればコストや納期を改善するツールにも使えますので、是非幅広く活用して欲しいと思います。

cmmi_husa at 11:22|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI

2014年03月21日

なぜなぜ分析によるプロセス改善を成功させるための組織論

発生してしまった問題に対してなぜなぜ分析を実施し、プロセス改善を行う。。。
このような改善のサイクルを回していくには組織の風土というものもとても重要に思います。
では、どのような組織風土が必要なのでしょうか?

1.問題を報告しやすい

問題が発生してなぜなぜ分析を実施する際、またはなぜなぜ分析のレビューの際に、問題を起こした当事者をまるで犯人のように扱う組織があります。ミスがばれると上司に怒られるというような組織ではミスが隠ぺいされ、分析されなくなってしまうので、同じような原因によるさらに影響度の大きい障害につながる可能性もでてきてしまいます。
このような事態になることを避けるには、業務上のミスはプロセスに起因するものであり、改善の対象はプロセスにあることを、上司も含め組織の全員が考えるような風土づくりが必要です。

2.改善をチームで行う

なぜなぜ分析を行いプロセスのルールや仕組みの改善策を提案した時に、「じゃあその改善をだれがやるの?」という話になります。改善は組織の規定改版や開発ガイドラインの改版、各種帳票等のフォーマット作成など手間のかかる作業になってしまうことも少なくありません。このような作業を提案者一人に押し付けてしまうと、次からの提案では面倒な作業を伴わない提案しか出てこなくなります。たとえばチェックシートに項目を追加する、というようなものしか出なくなります。
このようなことを避けるには、改善策を実行する際は提案を出した個人ではなく組織やグループ全体で検討し、改善を実施するようにする風土づくりが必要です。

3.「当たり前」の価値を認める

これはなぜなぜ分析を成功させる風土というより、ミスを起こしにくくするための組織の風土のお話です。
ある作業において、ミスを起こせば怒られてしまいます。また、ファインプレーを出せば褒められます。では、ミスを犯すでも、ファインプレーをするわけでもないひとは?というと、何もないですよね。でも、ノーミスでQCDをきちんと守って作業している人って実はスゴイことだと思うんです。こういう人達の価値を認めるということが必要なんじゃないかって最近思っています。
例えば、労働災害でいうと何万時間労働災害ゼロとかで安全な職場であることをアピールすることがありますが、開発に限らず製造や保守の作業でも、チームごとにノーミスをどのくらい長い時間継続したかを測定し評価する仕組みを作ると、QCDを守ることに対するモチベーションも上がるのではないでしょうか?

組織の風土を変えることは大変ですが、いろいろ工夫して取り組むと効果的な改善が進み、ミスも劇的に少なくなっていくと思います。





cmmi_husa at 17:32|PermalinkComments(0)TrackBack(0)なぜなぜ分析 | CMMI
訪問者数
  • 今日:
  • 昨日:
  • 累計:

Recent Comments