<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>日々の考察</title>
<link>https://ameblo.jp/zisuka/</link>
<atom:link href="https://rssblog.ameba.jp/zisuka/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>日々の出来事、不思議に思った事、頭に浮かんだ事、世界での出来事など、当初は書評が中心でしたが、今後は書評はほどほどに有益な情報も含め、日々の考察を綴りたいと思います。</description>
<language>ja</language>
<item>
<title>Reスタート</title>
<description>
<![CDATA[ 今年から、改めて色々と綴って行きたいと思います。<br><br>ちなみに、今年の目標（仕事以外）は、<br><br>1. 飲みすぎない事<br>2. TOEIC　800点を取ること<br>3. チェロでバッハ無伴奏を弾けるようになること<br><br>I'm gonna start on Blog in this year.<br>So, My target without work is 1.Cut down on alchol, 2.Take 800 point of TOEIC TEST, 3.Play Suiten für Violoncello solo　by a cello.
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11971773236.html</link>
<pubDate>Thu, 01 Jan 2015 11:38:16 +0900</pubDate>
</item>
<item>
<title>仕事の意味</title>
<description>
<![CDATA[ 最近、企業再生の案件に関わることが多くあるため、掲題の事をぼんやりと考える事が<br>増えました。さらには、自分がコンサルを目指した理由、その先の目的についても。<br><br>目指した理由は、今でも忘れてはいませんが、果たしてそれでいいのかどうか。<br>働く意味は色々とあるとは思いますが、自分がブレないためにもちゃんと腹落ちを<br>させないといけないなと最近特に思います。<br>
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11287173091.html</link>
<pubDate>Tue, 26 Jun 2012 07:56:43 +0900</pubDate>
</item>
<item>
<title>全く更新出来ない日々</title>
<description>
<![CDATA[ 最近全く更新出来ていません。<br>いくつか理由はあると思いますが、最も大きな原因は、自分の軸の無さ（優先順位がぶれる）事だと<br>思います。<br><br>なんとか、がんばって再開させていきたい。<br>
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11262404748.html</link>
<pubDate>Sun, 27 May 2012 23:45:01 +0900</pubDate>
</item>
<item>
<title>シックスシグマ　Ｍフェーズ　プロセス能力</title>
<description>
<![CDATA[ Measureフェーズの「プロセス能力」を今回は説明します。<br>ここは、やや統計的な話が多いので、まぁさくっと簡単に<br>概要だけ説明します。<br><br>そもそもプロセス能力とは、<br>・現状の悪さ具合を示す数値です。<br>つまりは、顧客の規格を満たさないものが現状どの程度あるのか？<br><br>具体的に示す数値は、<br><br>【離散データ】<br>・ＤＰＭＯ、ＤＰＵ、歩留まり・・・等<br>【連続データ】<br>・Cp、Cpk、シグマレベル、ＤＰＭO・・・等<br><br>ＤＰＵ＝Defect Per Unit<br>　－1ユニットあたりの平均欠陥数<br><br>ＤＰＯ＝Defect Per Opportunithy<br>　－1機会あたりの欠陥発生数<br><br>シグマレベル＝別名「ありえない度」<br>正規分布の話で、標準偏差何個分？って事ですが、そもそも標準偏差って何？<br>という話は、また別途機会があれば（笑）<br>一応備忘のため下記に記載しますが、<br><br>【参考】<br>範囲　　その中に入るデータの割合<br>μ±σ　0.06827（約2/3）<br>μ±2σ 0.9545(約19/20）<br>μ±3σ 0.9973（ほぼ100%）<br><br>ちょっと分かりにくいですね。<br><br>まぁ、なんらかの形で悪さ具合を示す事が重要です。<br><br>以上、次回からはDMAICのAnalyzeフェーズを説明していきます。<br>いよいよ、真骨頂と言いたいとこですが、ここはアートの世界になりますので<br>そこまで方法論は発展してません。。。<br><br>
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11175486611.html</link>
<pubDate>Thu, 01 Mar 2012 00:39:37 +0900</pubDate>
</item>
<item>
<title>シックスシグマ　Ｍフェーズ　データ収集</title>
<description>
<![CDATA[ Measureフェーズの「データの収集」ですが、これは下記のステップ<br>に分ける事が出来、それぞれ説明していきます。<br><br>①第1、第2メトリック<br>第１というのは、改善したいプロジェクトＹで基本的には1つです。<br>第2というのは、第1を改善しようとすると悪くなる可能性があるがあるもので、<br>これは押えておく必要があります。<br>例えば、コストをカットしたら品質が悪化するとか。その逆もしかり。<br>また、メトリックが決まったら、規格限界を明確にします。<br>これは、いわゆるどこまでだったら大丈夫なのか、どこが最低ラインなのかって事です。<br><br>②データの定義<br>これは、連続値と離散値があり、それぞれしっかり定義して<br>分けて取り扱う必要があります。<br>連続値というのは、数えようと思えば無限に数えられるもので、離散値は性別とか5段階評価や<br>ＯＫ/ＮＧとかそういったものです。<br><br>③データ収集計画<br>既存のデータを使う場合は、特に問題は起こりませんが、新しく測定してデータを得る場合は、<br>もちろん当たり前ですが、収集計画を作る必要があります。<br><br>④サンプリング<br>ここは、その名の通りサプンリングを行うってことですね。<br><br>⑤測定系の検証<br>名前が少しなじみのないものですが、簡単言えばちゃんと正しく測定できるのか？を確認するという事です。<br>つまり、そもそも体重計が壊れてたらちゃんと測れないので、ちゃんと測れるか調べるという事ですね。<br>また、観点は以下の3つです。<br>　－繰り返し性；1人の測定者が同じように何回も測定できるか？<br>　－再現性；複数の測定者が同じように測定できるか？<br>　－正確性；決められた基準と同じように測定できるか？<br><br>以上が、データ収集です。<br>次回は、データ表示について説明します。
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11175484539.html</link>
<pubDate>Wed, 29 Feb 2012 00:38:04 +0900</pubDate>
</item>
<item>
<title>シックスシグマ　Ｍフェーズ　詳細プロセスマップ</title>
<description>
<![CDATA[ Measureフェーズの目的は簡単に言うと「現状の悪さ具合を測定する」事。これに尽きます。<br>専門用語だと、Ｙ＝ｆ（ｘ）のＹを先ず測定することです。<br><br>なぜＹ、つまり現状を先に特定させるのか。それは、<br>・本当に悪いのか？実は良かったり？普通だったりしないか？<br>・ちゃんと測定することで人を説得する材料を得る。<br>この2点を得る？事です。<br><br>具体的な進め方は、下記の3つのステップで構成されます。<br>1．プロセスを視覚化する<br>　－詳細なプロセスマップを構築する<br>2．データを収集する<br>　－第1、第2メトリック<br>　－データの定義<br>　－データ収集計画<br>　－サンプリング<br>　－測定系の検証<br>3．データを表示する<br>　－グラフの作り方、見方<br>　－プロセス能力<br><br>今日は、１のプロセスマップの視覚化を説明します。<br>基本的な作成方法は、関係者を集めてポストイットと模造紙を用意し、<br>みんなで話し合いながら決めていく感じで、ＢＰＲ等をやった事が<br>ある方にとってはそこまで難しい内容ではないです。<br><br>ただ、粒度はあらかじめ決めるか、話し合いながら調整していく事が<br>必要ですね。どこまで１つの項目として出すのか。<br>それ以外注意点としては、当たり前かもしれませんが、下記の通り<br>・○○をＸＸすると動詞と目的語を記載する<br>・左から右へ、時間の流れにそって作る<br>・事実を記載する<br>　－クライアントに確認すると「意外にこうなってない」ってことが<br>　　あります。<br><br>大体、右軸にプロセスがあって、縦軸に担当者が並ぶ感じになります。<br><br>以上、次回はMeasureフェーズの「データを収集する」について<br>説明します。
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11175482800.html</link>
<pubDate>Tue, 28 Feb 2012 00:36:32 +0900</pubDate>
</item>
<item>
<title>シックスシグマ　Ｄフェーズ　チームチャーター</title>
<description>
<![CDATA[ 今回は、シックスシグマチームチャーターについて説明します。<br><br>チームチャーターとは、良くＡ４、1枚に示されるプロジェクト設計書<br>みたいなもので、プロジェクトリーダーからすれば自分を守るための<br>契約書的な意味合いもあります。<br><br>それは、チームチャーターには下記の要素を上司の合意を得た上で<br>書面化するためです。<br><br>1．問題点とゴール<br>2．プロジェクトの必要性<br>3．プロジェクトのスコープ（ＰＪ範囲）<br>4．プロジェクトのスケジュール<br>5．役割分担（人のアサイン）<br><br>つまり、ちゃんと問題点とゴール、それを解決する必要性、<br>そのための人のアサイン、ＰＪの範囲とスケジュールをきちっと<br>上司と握る。それがとても重要という事です。<br><br>また、チャーターを作成するときは、一般的に言われている<br>S=Specific（具体的な）<br>M=MEasurable（測定可能な）<br>A=Attainable（達成出来る）<br>R=Relevant（適切な）<br>T=Time Bound（期限付き）<br>を意識して作成に取り組みます。<br><br>チームチャーターを作成するときに、色々と細かいルールみたいな<br>ものがありますが、最も重要なのは、チャーターを都度見直して<br>いくという事です。もちろん、上司や関連部署と調整しながら。<br><br>また、ゴールを０にはしないという事でしょうか。<br>結構はっきりとゴールを置く事が重要です。<br>（中途半端な目標ではだめって事です）<br><br>ここまでが、ＤＭＡＩＣのＤフェーズ（問題定義）です。<br>次回は、Ｍフェーズを説明します。<br><br>以上
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11175480124.html</link>
<pubDate>Mon, 27 Feb 2012 00:35:01 +0900</pubDate>
</item>
<item>
<title>シックスシグマ　Ｄフェーズ　ＳＩＰＯＣ</title>
<description>
<![CDATA[ 今回は、シックスシグマＤＭＡＩＣのＤフェーズ、ＳＩＰＯＣに<br>ついて、説明します。<br><br>ＳＩＰＯＣは「ハイレベルプロセスマップ」を作成し、<br>業務の全体像を把握することを目的としています。<br>ちなみに、”ハイレベル”というのは抽象度が高いって感じです。<br><br>具体的には、以下の4つの具体的作業があります。<br>1．プロセスマップの範囲を決める<br>2．インプット、サプライヤーを特定する<br>3．アウトプット、カスタマーを特定する<br>4．ハイレベルプロセスマップを作成する<br><br>そのため、下記の頭文字をとってＳＩＰＯＣ<br>S=Supplier（入力資源、情報の供給者）<br>I=Input（プロセス入力資源、情報）<br>P=Process（Outputを創り出すプロセス）<br>O=Output（カスタマーに提供されるもの）<br>C=Customer（最終的な使用者）<br><br>製造業のとある工場を例にとって説明しますと、<br>1は、簡単に言うとどこまで今回のプロジェクトのスコープと<br>するか。という事です。例えば、工場から実際に商品をお客様に<br>届けるまで、つまり物流まで範囲とするのか、それとも出荷まで<br>を範囲とするのか。そのような事を決めます。<br>（まぁ、普通はお客様志向というかＣＴＱにそって決めます）<br><br>2は、製造業なので製品を作るために必要な全てとなります。<br>それは、原材料だけでなく、電力やガス、さらにはそもそも顧客が<br>いなければ提供も出来ないので顧客も必要となります。<br><br>3は、まぁこれは顧客ですね。この場合。<br><br>4は、大体全体を４～６のステップに分けたもので、ある程度関わって<br>いる関係者やプロジェクトの範囲が分かればＯＫです。<br><br>以上、次回は「チームチャーターを決める」を説明します。<br><br><br>
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11175479171.html</link>
<pubDate>Sun, 26 Feb 2012 00:33:20 +0900</pubDate>
</item>
<item>
<title>ちょっと気になったことの備忘</title>
<description>
<![CDATA[ 少し資料を整理したいと思い、備忘録として断片的に<br>心に引っかかったことを下記の通り残しておきます。<br><br>【イメトレだけでは失敗する】<br>何かを成し遂げる、成功するには下記が有効との事。<br>1．大きな目標だけでなく、それを実現する小さな目標を具体的に<br>　　立てる<br>2．自分の目標を友人、家族、同僚などに具体的に話すことで、<br>　　これまでの習慣を変える動機付けをする<br>3．目標を達成したとき、人生に起きる事を数えあげる<br>4．小さな目標を達成したら、ご褒美をあげる<br>5．目標達成までの過程をパソコンなどで書きとめる<br><br>【若くして出世した人の勘違い】<br>1．自分自身が成果をだせばいいと思っていること<br>2．正しい指示さえすれば、人が動くと思っている事<br>　－人は論理や理屈では動かない。「あなたを認めている」<br>　　という姿勢を示すこと。この人は自分の事をきちんと見て、<br>　　評価してくれてると思わせることが重要。その上で、<br>　　脅して、すかして、褒めて、あの手この手で説得する。<br><br>【人から信頼される】<br>人から信頼されるためには、<br>1．傾聴する<br>2．支援する<br>3．励ます<br>4．尊敬する<br>5．信頼する<br>6．受容する<br>7．意見の違いを交渉する<br><br>逆に嫌われるなら<br>1．批判する<br>2．責める<br>3．罰する<br>4．脅す<br>5．文句を言う<br>6．がみがみ言う<br>7．目先の褒美で釣る<br><br>以上<br>
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11166939492.html</link>
<pubDate>Fri, 17 Feb 2012 00:11:54 +0900</pubDate>
</item>
<item>
<title>今年のテーマ！？</title>
<description>
<![CDATA[ 今年に入ってふと思った事がありました。<br><br>それは、何かを消費することで喜びだったり、満足感だったりを得てきた事が<br>去年は多かったなー、という事です。<br><br>今年は、消費ではなく、生産する事で喜びだったり、満足感を得たいなと思いました。<br><br>けど、具体的にはどのような事なのか、<br>（単純に生産って言っても色々あると思いますので）<br><br>モノ<br>・料理を作って、誰かに振舞う事<br>・絵や写真、陶器などを作ること。できればそれを発表すること<br>・ブログを続け、情報を発信すること<br>・手紙などの文字が形としてのこるようなもので、メッセージを伝える事？<br><br>コト<br>・楽しそうなイベントを開催すること（鍋パ、花見、旅行、ＢＢＱ、登山などなど）<br>・何かタメになりそうな会を開くこと（大学生向け論理思考？就職活動方法？経済の勉強会？などなど）<br>・ボランティアに参加？<br><br>けど、仕事以外で自分が生産出来る事って限られているような気がします。<br>ちょっと、周りの人に何が提供できるのか。聞いてみた方がいいかもしれません。<br><br>以上<br>
]]>
</description>
<link>https://ameblo.jp/zisuka/entry-11151494174.html</link>
<pubDate>Wed, 01 Feb 2012 00:33:09 +0900</pubDate>
</item>
</channel>
</rss>
