OS-X Yosemite でプリントできない！

　　OSをYosemite(10.10)に更新してから、NEC MultiWrite 8250N での印刷ができなくなっていた。調べてみると、CUPS(**nix/**bsd系の印刷システム)でSandBoxになっているのが影響するらしいとのこと。以下をターミナルから実行してみた。

sudo sh -c 'echo "Sandboxing Off" >> /etc/cups/cups-files.conf'
sudo launchctl stop org.cups.cupsd

　書いてあったのは、こちら　＝＞　MacOS1010YosemiteKnownIssues

　結果としては、印刷できるようになったので、良しとしよう。

iPhoneのホームボタントリプルクリックではまる

iPhoneの画面操作がおかしくなって焦った。これは修理か交換かな？と思って調べてみると、どうもトリプルクリックが原因だったようだ。

症状：
１）アイコンを押すと黒い枠がでるだけで、ダブルクリックしないと押した事にならない
２）ドラッグが効かない：メッセージなどのインフォが見れない
　＝＞　実は、ダプルクリックして指を置いたままにするとドラッグできた

原因：
　ホームボタンをトリプルクリックしてしまったこと。

　トリプルクリックには、特定の機能が割り振られており、アクセシビリティの設定になっていると、通常のタップやドラッグができなくなってしまう！

当初は、パスコードの入力もできなくなったと思い、相当焦った！！
液晶保護シートを外したり、掃除したり色々やったが、無関係でした、、、orz

Gradle での他プロジェクトへの依存性

Gradleが便利なので利用するようになった。利点は以下のもの。

1)Mavenのリポジトリが利用できる
2)Groovyなので、小回りがきく

Eclipseでplungin  をいれて利用していたが、２つ作成したGradleプロジェクトに依存関係を入れる時にちょっとはまる。
Eclipseのビルドパスで、他のプロジェクトを指定すると、Eclipseではコンパイルも実行も問題ないのだた、GradleのInstallAppなどを指定すると、とたんにコンパイルエラーとなる。
G が E の依存関係を理解していないのが原因。ググってみても簡単な解決策なし。最初から親子プロジェクトにしておけば、以下の形式でOK。

 compile project(':projectA')

結局、maven プラグインを追加して、ローカルリポジトリを利用した。

■参照される側の build.gradle => install タスクにてローカルリポジトリに作成される。

apply plugin: 'maven'

version = '1.0'
group = 'net.korabo.app'
//archivesBaseName = 'UmlGenerator'
version = '1.0'

■参照する側の build.gradle => mavenLocalの指定が必要

repositories {
mavenLocal()
    mavenCentral()
}

dependencies {
    compile group: 'net.korabo.app', name: 'UmlGenerator', version: '1.0'
    ....
}

VirtualBox in MacOS-X: VMの移行ではまる

電源が入らなくなったMacMiniからVMのファイルだけが救出できたので、新しいMacMiniに移行しようとした。

１）必要なファイルをコピーして、VMの追加 ＝＞ xxx.xml を指定すると、以下のような
メッセージが出てしまって追加できない

?????"/opt/VirtualBox/Machines/VM4Daicho/VM4Daicho.xml"??????????
A differencing image of snapshot {773bf732-3682-42d8-9d77-d64287538436} could not be found. Could not find an open hard disk with UUID {3a85ec8d-b6ab-4292-879e-3701f8febab3}.
????? :
NS_ERROR_FAILURE (0x80004005)
???????:
SnapshotMachine
????????:
IMachine {5eaa9319-62fc-4b0a-843c-0cb1940f8a91}
?????:
IVirtualBox {c28be65f-1a8f-43b4-81f1-eb60cb516e66}

色々調べて、UUIDを以下のコマンドで確認したり変更できることが分かった。

VBoxManage internalcommands dumphdinfo HDDファイルへパス
VBoxManage internalcommands sethduuid HDDファイルへパス

該当するUUIDのファイルを読めそうな場所に置いて、何度かチャレンジするも一向にうまく行かず、これは定義ファイル(xx.xml)を自力で編集かなと思ってちょっと手を加えたがやはりだめ。

それならと、メッセージにあるようにOpenしてみようと別のVMを新規に作成してHDDとして当該UUIDのファイルを追加してみた。するとメッセージが変化した。

うまくいった方法

VirtualBoxの仮想DiskManagerを開いて、登録してあげればいい！
　ただし、＋ボタンがないので登録の仕方で難儀したが、D＆Dするだけだった
　さらに、SnapshotsのファイルもD＆Dすると正しい順序で連結された！！

JMXに関する覚書

org.jboss.system.ServiceMBeanSupport を使用した場合の注意点：

JMXで使用するMBeanに対して、javax.management.MBeanRegistration を実装すると以下のメソッドが自動的に呼ばれることになっている；

 void postDeregister() 
 void postRegister(Boolean registrationDone) 
 void preDeregister() 
 ObjectName preRegister(MBeanServer server, ObjectName name) 

上記メソッドでは、JBossサービスに依存した初期化をおこなうことができない。
JBoss特有の初期が必要な場合は以下のライフサイクルメソッドを実装する；

 void create() throws Exception
 void destroy()
 void start() throws Exception
 void stop()

または、上記が定義された 「org.jboss.util.Service」インタフェースか、String getStateString()などが追加された「org.jboss.util.ServiceMBean」インタフェースを実装することでJBoss特有の初期化ができる。

JBossでのMBean作成上の注意
　抽象クラス「org.jboss.util.ServiceMBeanSupport」を継承して作成することが一般的だが、start(), stop() などのライフサイクルメソッドをOverrideしても子クラスのものが呼び出されずに親クラス(ServiceMBeanSupport)のメソッドが呼ばれる仕様になっている。
　子クラスでOverrideすべき専用メソッドを実装すること！！

 void startService() throws Exception
 void stopService()

＊詳しくはServiceMBeanSupportのJavaDocなどや、JBossマニュアルを参照すること。

トラブル対処の原則考

修正したヘルスチェックスクリプトがうまく動作しないというので、調査していた。
本来ならNGとなるべき出力がOKのままだという。その時実施した対応は、

１）状況の聞き取り
２）ログなどのエビデンス収集　＝＞ ログなどが０バイト
３）部分的な実行による切り分け

結局のところ、部分的に実行していった段階でミスに気付いたのだが、これをもっと早く確実に発見する方策がないだろうか？

３－１）主要スクリプトを単独実行　＝＞ 出力空
３－２）上記スクリプトを手で実行(SQLPLUS) ＝＞ 空
３－３）確実に出力があるように変更して実行 ＝＞ no rows selected

ここにいたって、Oracleのつなぎ先が違うのでは？という疑いが発生し、調べたらまさにそうであった。

教訓１：調査開始時点での前提を明らかにして疑ってみる
　＝＞ 原因の上流の確認は作業が容易で効果が大
教訓２：前提を明確にできるような工夫をスクリプトに入れておけばよかった
　＝＞ または、文書としてコメントに入れておくか、前提確認用スクリプトなど
　例)前提：Oracleとの接続、スクリプトの配置場所、XXファイルの書き込も権限
　　 前提違反時の振舞：エラーメッセージ、空文字出力、、、

優先順位マトリックスを考えてみた：
　作業の困難性　　＝＞ 当該部分に問題があるかどうかの確認作業の時間やスキル
　影響範囲の大小　＝＞ 当該部分の障害から本件が発生しうる確率
　優先順位　＝＞ 容易で影響大 -> 困難だが影響大 -> 容易で影響小 -> 困難で影響小
　　＊中央の２，３番目の部分は時間配分やメンバースキルによって反対にした方がよいか
　　　または、メンバーに余裕があれば並行して作業するといい

今回の件だと、Oracleの接続先のような前提条件は
「作業が容易で影響範囲が大」となり、優先順位が高いものといえる。
環境変数の設定も、同じ範疇だ。しかし、個別スクリプトの問題となると
「容易で影響小」となる。

なぜなぜ分析セミナー

== なぜなぜ分析に関しての考察 ==
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:焦点の移動)]
     [対策が正しくても、事象(これから実行されるものも含む)と離れすぎていると判断がつかないし、やったことの効果が分かりにく]
     [どのような仕組みや(業務プロセス)や体制(組織と制度)があれば防止できたか？]
・トラブルは会社を強くするチャンス
     [分析により弱点を認識でき、対策がとれるレベルにまで詳細化できる]

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