なぜなぜ分析セミナー

== なぜなぜ分析に関しての考察 ==
2012/03/01 ST(KRB) NEW.
2012/03/15 ST(KRB) REV.

セミナーに参加して気付いたことのメモ
------------------------------- セミナー概要 -------------------------------
日経情報ストラテジーセミナー
     改善・改革活動の基礎スキル「なぜなぜ分析」演習付きセミナー
     講師：小倉仁志 (マネジメント・ダイナミクス社長)
     日時：2012年2月28日（火）
     場所：品川フロントビル会議室
     参加者：目測で120名程度

     講義編：なぜなぜ分析を考える時の定石
          ●ヒューマンエラーを分析する際のよくある失敗例
          ●「なぜ？」を考える前に、原因追究の勝負は決まる
          ・漏れの無い課題の摘出で、会社として抜けの無い仕組みの構築を目指す
          ・見たまま、かつ的確に事象を表現する
          ・分析対象を正確、かつ詳細に把握・理解する
          ・前提条件を整理し、分析上の除外要件を明確にする
          ●「なぜ？」を考える時の定石
          ・論理的に展開するための定石
          ・漏れなく展開するための定石
          ・狙い通りに展開するための定石
          ・展開された「なぜ」を正しく検証する
          ・導き出された対策の展開の仕方
          ●なぜなぜ分析の進め方
          ●ヒューマンエラー防止に向けた、なぜなぜ分析の運用のしかた
          ●なぜなぜ分析事例
          ●なぜなぜ分析の様々な用途例

     個人ワーク：なぜなぜ分析の間違いを見抜けるか
          よくあるヒューマンエラーの「なぜなぜ分析」を、自分なりに修正することで、
          「なぜなぜ分析」の定石を再確認しよう
          ●講義で学んだことを基に、分析上の間違いを指摘し、自分なりに修正する
          ●回答例と比較し、なぜなぜ分析で陥りやすい間違いや注意点に対する理解を深める

     グループワーク：トラブル事例をグループで解き明かそう
          品質クレームへの適切な対策を、「なぜなぜ分析」の進め方に沿って導き出してみよう
          ●グループで事例を分析し、論理的に漏れなく要因を洗い出し、
          再発防止策を１つ以上導き出す
          ●グループでの分析作業を通じて、数人で分析するメリットを実感する

     質疑応答
          今回の講義・演習内容や、なぜなぜ分析を行う上での疑問点などに講師がお答えします
-----------------------------------------------------------------------------

以下は筆者の受け取った内容(通常の文書)、および感想や心情([角カッコ内の文書])。
(順序は講義の通りではない)
参考書籍：
小倉仁志：なぜなぜ分析徹底活用術
小倉仁志：なぜなぜ分析実践編

・「なぜなぜ分析」とは、実務家が利用する改善のための道具にすぎない
     [問題を深く問い直すことで具体的で即応可能な原因を追究してその対策をたてる、業務改善活動の１つ]

・目的は何か ＝＞ 職場、作業、業務、、を変えるため
     誰の為にするか ＝＞ 3人(顧客のキーマン、自分、同僚)
・失敗は仕事に不完全な部分があるから ＝＞ 完全を目指すのが人の役割
     トラブルの原因追究ができる人は少数 ＝＞ ベテラン中のベテラン
・何故の回数より狙いにこだわるべき
     再発防止につなげるのが大切；現場と管理では策が異なる
・知ったかぶりはやめる
     (謙虚に事実と向き合う)
     事象は、先入観をいれずにありのままで表現する：忘れた ＝＞ していない(忘れたかどうかは本人の確認が必要)
・分析を始める前の過程が重要     [直感として8割方の成否を握る]
     刑事ドラマに例えると、事件(発生事象)の把握(証拠物と登場人物などのアクティビティ調査)をすること
     脇役の刑事のように早合点してはいけない
・事象の洗い出しは紋切り型にしない
     発端の事象と処置ミスの事象、、[収集して関連明らかにする]
・証拠とアリバイから不要な選択肢を減らしておいて、深く調査してゆく
     [情報システムでの証拠(エビデンス)は、操作記録やログ、複数の証人が同じ認識をしていることがらなど]
・事象抽出(事象を認識して表現する)で、焦点を当てるよりどころは、担うべき使命
     [現場のチームか、マネージメント側かによって導き出す対策の焦点が異なってくる為]
     チームでトラブルを考えさせる ＝＞ 使命感を共有し深化させるチャンス
・慢性トラブルでは、事象を1件だけ選択する
     へたに統計や類型分類などしないほうがよい
     １つを明確にできなければまとめたり類別したりはできない
・事象明確化の作業方法
     事実の収集、順序・つながり の確認
     的確、論理的、もれなく、狙いよく
・事象の状態(頻度、傾向)を具体的に表現すること；曖昧なものは避け、比較で記述する場合は対象を明示する
     例)Cが表示されていない ＝＞ 100個中1個の割合でCが表示されない
     [相対的な表現より計量的な表現にする]
・前提(証拠、アリバイ)を固めれば不要な選択肢を分析から排除できる
     [原理・原則からアプローチをすると選択肢が増えてしまうので、どう絞るかを知りたいとう質問への回答]
・分析上の注意
     文中の言葉に着目してなぜを出す：泣いた ＝＞ それってどういうこと？[泣くとはどういう行為？]
     前提によってなぜの選択肢が変わってくる：いつから泣いていたか、10分前はどこで何をしていたか、、、
     現場の現状だからと予断してはいけない、ミスリードすることが多い
     [前提(付帯情報)によって、何故の爆発を防止でき、焦点を絞れる]
     [選択肢が増えすぎるようなら、～～かどうか知るためには何が必要か、と考えて前提を増やしてゆくとよいかも]
     １つのなぜに要因を２つ以上入れてはだめ：「～せずに～したから」のような複合分にしないで、分解する
     意味はっきり、ストレート表現：主語述語、時点や傾向、図などで補う
          例）温度の設定が悪い ＝＞ 担当者Aさんが温度設定を誤った
               温度が低下した ＝＞ 10:30から22:30にかけて1時間に2℃の割合で温度が低下した
               上にずれてしまった ＝＞ 図を使用して、ずれた長さや方向を実数で表示
     時間、場所、内容を細かく分け、時間の早い順、場所の近い順に並べる
     後ろのなぜが解消されたら前のなぜが解消するかをチェック
          これを判断できる人をチームに入れておく
     基準を発揮とさせる、反対から見る
          例）～が多すぎる ＝＞ 通常の材料の割合に対して、今回は水が15%多すぎる；[～が多くない限り～～は発生しないか？]
     逆に読み返して筋が通るか
     背景を加えた表現で筋道を正す
          ～じゃしょうがない、、は言い訳になってしまう ＝＞ ～にもかかわらず、～～した
          心情を考えるのではなく、「掘り下げるべき弱点」を見出す[クールに評価するのは対応策を見出す為]
     狙いは再発防止
          火急の問題では暫定処置を出す
          １）発生しない、しにくい状態にする
          ２）発生しても、気付きやすくする[工夫とルール化]、気づけるようにする[努力とトレーニング]
・分析には、発生した問題を解決することを主眼とするものと、トラブルチェックシート的に使うためのものがある
     [発生事象を元にすると前提が限定されるため選択肢を絞り込みやすい]
     [事象からのなぜは、現にある問題を解決するためのなぜであり、AND関係にあるものを見つける：XXX以外に何があろうと問題が発生していたか？]
     [チェックリストのなぜは、将来発生する問題の可能性を見つけるためのなぜであり、OR関係を見つける：XXX以外に原因となる場合はないか？]
・対象の事物のつながりを正確、詳細に把握するためには、登場人物の活動をフロー図にしてみるとよい
     [BPMNのBP図やUMLのアクティビティ図にそっくりのレーン分けされた図で登場人物の活動とその関連を表記]
     [発生事実の連携の中で直接的な原因は素直に見通せるようになる]
・人為ミス(ヒューマンエラー)は「やらなかった」と「間違えた」に分ける
     やらなかった：やることを知らなかった、知っていたができなかった、、、
     間違えた：4段階で考える
     忘れた、の追及は途中で切る、そうしないと言い訳ばかりで分析にならない
     間違いの発生には４つの局面(情報、受容、判断、動作)があるので、どこで問題が発生したかを分析し対策へつなげる
          例）情報[刺激]：材料のラベル自体が間違っていた ＝＞ ラベルがなくても識別できるような知識や訓練、明確な違いを持つ材料を利用する
               判断：別工程と間違えて不要な材料を入れてしまった ＝＞ 開始前に再確認できる仕組みを作る
               動作：となりのビンと取り違えてしまった ＝＞ となりのビンの形や色を変えておく
     個人的な話は避ける(プライバシー)
     ミスの要因例の想定：紛らわしさ、～ずらさ[不適切]、作業時のノイズ、役割分担の不備[責任の所在]
・「XXに気付かなかった」のような「なぜ」は、対象や期間を明確にする
     [考えると、これは「しなかった」ことが原因となるケース：意識にないものを見つけだすのは難しいが、本質的な対策の糸口になりそうだ]
     [つまり、なぜを考えるときに、「した」ことによるなぜと、「しなかった」ことによるなぜを想定する必要がある]
     [直前に原因発生から、次の事象発生までの間に、もしXXXしていれば防止できた：という観点で点検してみてはどうか？]
     [上記に期間に活動できる人はだれで、どんか活動が可能だったかを考えてみる]
     [単純に「XXXXすればよい」を対応策には(十分に細かくないので)できないと思うが、対応策に直結するなぜを導く一里塚になる]
     [目安ができれば、そこに立って考えることで新しい視野が開けると思う(Vision:焦点の移動)]
     [対策が正しくても、事象(これから実行されるものも含む)と離れすぎていると判断がつかないし、やったことの効果が分かりにく]
     [どのような仕組みや(業務プロセス)や体制(組織と制度)があれば防止できたか？]
・トラブルは会社を強くするチャンス
     [分析により弱点を認識でき、対策がとれるレベルにまで詳細化できる]

[余談だが、講師のしゃべりがみのさんを連想させる感じがあり、面白かった]

文章の濃度

文章には濃度がある。濃厚なものは味わいが深いが解釈に予備知識を必要とし読み下すのに手間がかかる。一方薄いものはさらさらと読めるが、本質には影響を与えないような枝葉が数多く含まれる。

小説として楽しむなら薄い方がよい。ちょうど主食として常食する材料がどれも薄味であるのと同じだ。
一方、記録や智恵の書の場合は、濃い記述になっている。これは言葉を凝縮していることによる。

例：
濃い文章
　法王アレッサンドラ６世の死後、ジュリオ２世により囚われの身となったチェーザレ・ボルジアが逃亡した先はシャルロットの兄であるナヴァーラ国王の元であり、パンプローナから自由宣言が発せられた。

薄い文章
　チェーザレ・ボルジアの父である法王アレッサンドラ６世(ロドリーゴ・ボルジア)がローマにおいて死去したまさにその時、チェーザレ自身も生死をさまよう重病であった。続く法王ピオ３世はチェーザレに同情的であったが即位から１ヶ月もたたずに世を去ってしまう。その後、チェーザレは最大の誤りを犯すことになる。ボルジアに煮え湯を飲まされてきたローヴェレ枢機卿の法王就任に対して手を貸してしまったのだ。ジュリオ２世として即位した新法王は、チェーザレを破滅されることを画策し、ボルジア家の故郷でもあるスペインへの軍務を餌にして誘い出し、幽閉することにも成功する。しかし、スペイン王家の内紛に乗じて逃亡したチェーザレは、フランスに残してある妻シャルロット・ダルブレの兄であるナヴァーラ国王の元へとたどり着き、自由の身となることができた。ナヴァーラ王国はフランスとスペインの国境近くにあり、その首都パンプローナからイタリアの各地へとチェーザレの自由宣言の手紙が発せられた。

オブジェクト指向の光と影

ソフトウェアの構成物をオブジェクトという単位で捉えるオブジェクト指向は、ブームからコモディティへとこなれてきたと思う。しかし、そこには指摘する人が少ない影の部分が存在していると感じたので、それを記しておく。

１）開発プロセスの変遷からの類推

　ウォーターフォールからアジャイルへの変化や分化などは最適化の結果と捉えている。
　地図を例にとると、平面の四角い紙に表す地図(メルカトル図法)は、一定の狭い範囲での表現としては最適であるが、地球全体にまで領域を広げると形が歪んでしまう欠点がある。逆に地球儀のアイデアを狭い範囲で忠実に実現しようとしても精度的に無意味になってしまう。
　つまり、対象とする事物や扱う方式によって最適なものは変化するということだ。
　ユニファイドプロセスなどは、ウォーターフォールのやり方を部分最適な方式として捉えており、ソフトウェア開発をモジュール化してその一部を実行する時のプロセスとして採用し、これをイテラティブ・インクリメンタルに行うこととした。
　一方アジャイル開発では、ウォーターフォール的な手法を採用する場面はもっと限定的になる。

　開発方法論は、統一(Unified)のかけ声よりも、現実に即した進展をしたと思う。それは、１つの手法ですべてを統一するのではく、状況に合わせて最適なものを採用するという方式だ。

２）分析・設計手法におけるオブジェクト指向

　ソフトウェアの世界をデータと振舞を内包した要素とその関連として捉えるオブジェクト指向は、ある領域では最適だと言えるが、無制限に一般のソフトウェアを対象に出来る訳ではない。
　オブジェクトは仮想的なモジュールとして捉え、それがデータを内包し、他のオブジェクトと関連を持つと捉えるのがOOの基本であるが、この考えはある程度の固まりとしてのソフトウェアコンポーネントやサブシステムという単位ならとてもしっくりするのであるが、細かくなってくると現実と整合しずらい部分が出てくる。
　たとえば、機能や振舞を細分化し抽象化していくと、特定のオブジェクトやそのクラスに属する限定をしないほうが扱いやすい、純粋に抽象的な機能というものも見つかり、無理やりにオブジェクトと捉えると何のデータも持たない要素となってくる。また、データの方も同様にまったく何の機能を持たせる必要性がない固まりというのも存在する。さらに、振舞に関する関連とデータに関する関連では、構造を定義しているという点では同じだが、意味合いは全く異なっており、データ同士の関連は状態を意味する一種のデータとして使われるが、振舞同士の関連が状態を意味することは通常ない。
　通常と言ったのは、振舞同士の関連に状態を持たせようと思えば出来るからであり、この「やろうと思えばできる」的な曖昧さが、OOでの分析・設計をぶれの大きなものにしてしまっているように感じる。
　異なっているのに、共通的に取扱えるから同じ用語やコンセプトで押し通されてしまうと、本当に重要な”違い”が見過ごされてしまうような気がする。

ではどうするかは、これからの検討課題とする。

OSGI:felix:bundleIDの戻し方(GFv3)

uninstallしても、bundleIDがインクリメントされてしまう。同じIDを再利用できなかと調べてみたら、以下のファイルに保存されているようだ。

osgi-cache/felix/bundle0/bundle.id

このファイルを編集して番号を戻し、以前と同じIDを使用できるようにしようと思ったのだが、単に変更しただけではだめだった。

refresh かけた ＝＞ だめ
update 0 ＝＞ GlassFish自体が落ちてしまった
再起動 ＝＞ うまくいった

結果オーライだが、くれぐれも既存のbundleを上書きしないように注意しよう。

OSGI:bundleの不思議な挙動

OSGIのbundle(モジュール)をインストールしたところ、新しく追加したリソースが見えていないような症状となった。

[#|2012-01-11T14:49:15.740+0900|WARNING|glassfishv3.0|net.korabo.cmt.spord.svc.msg.plugin.FireSubscriberPluginWRpldChk|_ThreadID=187;_ThreadName=Thread-1;|ErrorInCheckOF:[net.korabo.cmt.spord.svc.msg.CommonMsg@152886a]
com.ibatis.sqlmap.client.SqlMapException: There is no statement named MSGACCEPTANCE_ALT.selectTsRpldByPrimaryKey in this SqlMap.
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.getMappedStatement(SqlMapExecutorDelegate.java:231)

実際のパッケージ(jar)やGlassFishV3 の domains/domain1/osgi-cache/felix/を見てもファイルは更新されているはず、、、

telnet localhost 6666 (felixの場合)でOSGIのコンソールに入って様子を見ると、、、

ps
[ 219] [Active ] [ 1] spord-controll-osgi (1.0)
[ 223] [Active ] [ 1] spord-appstarter-osgi (1.0)

inspect package requirement 223
spord-appstarter-osgi [223] imports packages:
---------------------------------------------
ibatis; version=0.0.0 -> spord-appstarter-osgi [220]
org.osgi.framework; version=1.5.0 -> org.apache.felix.framework [0]
..........

となっており、PSでは見つからない220番を参照していることになっている！？

ちなみに osgi-cache/felix/bundle220 は存在しており、MANIFESTでの定義は、

Import-Package: ibatis;resolution:=optional

となっていた。

手順としては　220番が存在していた時に unistall して、同じパッケージを新たなbundleとして install しただけ。

じつは、これだけだと変更がコミットされていなかった！ 変更後に refresh をかけることが必須である。

参考：http://d.hatena.ne.jp/IkeT/20090325/1237945826

んで、推奨手順：

# 新規のみ
# install xxxxx.jar
# 更新時
stop
update file:///xxxxx.jar
# 共通
refresh
start

Windws7 に SSHサーバ(Copssh)ではまる

サービスでの起動で問題発生
最初は、FreeSSHDをインストールしたが、サービスから接続すると"cannot create child desktop" だの、"入力不可" などで断念。
次に、Copsshを入れてみたが、これはCygwinのサブセットみたいなのでコマンドの少ないbashが使用できる。これもサービス起動だとうまく動かず、、、ググっていると、「サービスで使う場合はインストール時手で管理者アカウントでやるべし」みたいなのを発見し、その通りしてみると何とか動いた。ちなみに、コントロールパネルも管理者アカウントで起動してユーザを追加しないと効果ないようだ。また、インストール後に再起動も必須の模様。

　なお、ユーザ追加の時に変なドメイン「.」を指定してしまうと、エラーが発生して２度とコンパネが起動しなくなるのは困ったものだ、、、

参考：http://www.sevenforums.com/customization/19864-ssh-windows-7-a.html

Once you download this run it as administrator and accept the default settings. It will than prompt you to all the settings you would like to use.

Once done you will need to manual setup users through the Copssh folder in the Start menu. (hint if you want to add an account that is not YOURS) just type in in over the drop down.


途中までやりかけたFreeSSHDのサービスアカウントのポリシー変更に関してはこちら、
参考：http://linlog.skepticats.com/entries/2010/10/Got_freeSSHd_mostly_working.php

I believe you have to grant the freesshd service access to create system tokens.

Run gpedit.msc (or apply group policy from the directory)

replace "sshd" with whatever account the process is running as, the default is SYSTEM

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment

Access this computer from the network -> add sshd
Act as part of the operating system -> add sshd
Adjust memory quotas for a process -> add sshd
Allow log on locally -> add sshd
Create a token object -> add sshd
Create global objects -> add sshd
Log on as a service -> add sshd
Replace a process level token -> add sshd

Comment posted on Tuesday 29 Mar 2011 at 5:54pm
By W. Strucke

開発方法

大きな流れとしては「要件定義、分析、設計、製造、テスト、配備、運用」となるのだが、
構造化にしろ、OOにしろ、DOにしろ、いまいちしっくり来ない感じがしていた。

ベストプラクティスとしての方法を紹介するというスタンスであって、
論理的でない部分が多かったように思う。
今にして思えば、論理的に説明するための基礎が不足していたからではないだろうか？

そこで、いくつかの素案をメモしておく；

・要件定義：実現したいシステムを表現したもの(単なる要望でなく、実現基準を持つ)
・分析：モヤモヤしている要件を複数の次元に分解して詳細を明らかにしたもの
　　例）業務機能、基盤機能、性能、システム把握、運用性、操作性、、、
・設計：上記の複数次元からなら定義を１つのシステムとして実現(実装、運用)できるような要素に分解し、その作成の筋道を明らかにしたもの
・製造：設計指示をもとに実行できるコードを生成し、単体レベルテストを実施する
・テスト：システム全体の要求を満たすかのテスト
・配備：実際の運用環境に適用する
・運用：

■トレーサビリティ

システム開発で分析や設計に力をいれるのは、トレーサビリティを確保するためだと思うようになった。
というのは、実際のシステム運用において、障害が発生したり拡張要求が発生した場合に大元の要件と対応する実現物(コードなど)の対応がとれないことが多く、これがシステムの理解を悪化させているのではないかと思えたからだ。トレーサブルでないシステム(これが大半だと思うが)では、システムの現状に関して信頼できる資料は実際に動作しているコードのみとなる。要件とコードの対応がつかないのでは当然である。

しかし、トレーサブルでないことがデファクトとなっているシステムをトレーサブルなものにすることができるのであろうか？これに対する構想を以下に述べる；

■現在使用可能なトレーサブル

たとえば、DBのテーブルやOOのEntity定義などはほぼ完全にトレーサブルと言える。要件として、「これ、これ、これ」と指定された項目をまとめて管理するという枠組みは非常にシンプルであり、正規化などで形式が変わってみていても上流の定義に戻すことは容易である。つまり、下記のような双方向変換が容易にできる。

データ定義　＜＝＞ モデル ＜＝＞ コード

■モデリングの限界

UMLなどのモデリングでは、なんでも出来そうに思われるが、それは上記のデータ構造に関してであり、動的な側面の記述という観点からは、基本的に用意された定義だけを使っている限り意外と表現力が乏しいと感じる；

例えば、簡単は電卓の動作をUMLだけで記述することが出来るであろうか？ 特にNキーロールオーバのような複数同時実行する場合の挙動を記述するのは簡単ではない；さらに、それが出来たとしても、そこから何らかの言語への変換が出来るであろうか？ 既存の変換ツールは状態変化(ステート図)を対応するクラスの挙動に変換するという極めて狭い領域をカバーするものが多いと感じる(すべてを見たわけではないのだが、、、)

■代替えとしてのDSL

では、UML以外のモデリングとして何が考えられるであろうか？ それはDSLだと考えている。
UMLで特定のDSLを記述することができれば間接的にUMLで表記したことにはなるが、そこにこだわる必要性を今は感じない。

例えば、機能表現に特化したDSLでシステム要件の機能部分を分析し、性能に特化したDSLでシステム性能要件と記述するという形にすれば、分析作業とは「システム要件をM次元の直交要素に分解しそれを固有のDSLで記述すること」と考えることができる。

さらに、設計は記述されたDSL要素から実現コードへのコンバータの生成(定義)と捉えることができる；
DSLをテストフレンドリにしておけば、生成されたコードをDSLを使用してそのままテストすることができ、要件が変わってDSLを書き換えたらテストまで自動で流すことができるようになる。

要件 ＜＝＞ M次のDSL記述 ＜＝＞ 実行コード

■開発作業の変化

DSLを中心に捉えてみると、システム開発作業は以下のような形にすることができる；

１）要件定義：聞き取りと文書化
２）DSL作成
３）コンバータ開発
４）生成、テスト
５）システムテスト

DSL作成の中でもUI部分やデータ定義などで分業できる要素があり、コンバータ部分は開発会社の強みとして自社で抱え、システムテストは人件費の安いところに外注するという工程も成り立つと思う。

そのためには、DSL ＝＞システムテスト という生成ツールが欲しいところである。