How We Should Design a Safety System

 

ビジネス・ゲームを変える

ルールを変え、ゲームを変える。 ゲームは5つ要素のパーツからできている。 １. プレイヤー、2.付加価値、３.ルール、４.戦術、５.範囲 少なくとも一つの要素を変えればゲームはまったくあたらしいものとなる。

『パイ』を作り出すときには協力し、その『パイ』を分けるときには競争する。これがビジネス、ビジネスは『戦いと休戦』の繰り返し、際限のない繰り返し。戦いと休戦は社内のあっちこっちでおきている。そして、『競争と同時に協力しなければならない』ことがあちこちでおきている。競争（コンペティション）と協調（コーペレーション）が同時進行する時、ダイナミックな動きが作り出される。 「このような様子は見えていますか？」「見えるか見えないかは、何とも言えない。」

プロジェクト憲章を作成、見える化を図る

１．NYU project charter template は、ニューヨーク大学のテンプレート。

２. アメリカCDCのプロジェクト憲章作成に役立つ資料: これは、プロジェクト憲章作成要領。  

憲章作成に、知っておいた方がいい一般的な知識の紹介

１．本田宗一郎による有名な三現主義があります。机上の空論ではなく、“現場”で、“現物”を観察し、“現実(現象）”を認識し、問題解決を図る。 “現場”“現物”“現実(現象）”の3つの“現”に焦点をあて、現場で、現物を観察して、現実(現象）を認識し、問題を解決する。 さて、「3現だけで十分でしょうか？」 答えは「十分ではありません、追加のゲンが必要です」、それは二つのゲン、「原理と原則」です。 原理(principle)は 基本法則です。例は、”てこの原理”、”アルキメデスの原理”などです。原則（fundamental rule )は共通のルール、決まりごとです。プロジェクトを進めるときは、３現プラス2原の『5げん』を使うことが一般的です。

２．現実に起きていることを5ゲンを使い調査する。 調査で注意すべきことは、過去の出来事、さらにそれより過去の出来事、さらにさらに過去の出来事と過去にどっぷり身を置いてしまうこと。 ３．過去にはものだけでなく人が含まれることを忘れない。また過去に戻り過ぎて、将来に眼が向かなくなる、さらに将来を見る時間が見つからない、無くなってしまう。結果として将来を見ることができない。大事なことは未来をみて、その未来を作り出すこと。  

知っているようで知らない

さて、ここで私の経験です、それは知っているようで知らない自分に説明できるほどの知識はなかったこと。 現象を理解するときに原理・原則をつかうことをしています。識別能力、判断能力の使い方は見えたものの内容によって違います。見る程度が深いか浅いかの違いはありますが、三現の現場は見えます、現物は見えます、現象も見えます。

原理・原則は見えるか、見えないか

  ルール、決まり事の原則は周りの人に聞けばわかります。原理は見えません。 近くの公園で、シーソーをみました、その時、このシーソーはどんな原理かな、と、ふと考えました。でも頭の中から出てきません。そこでグーグル検索しました、すぐ答えが出ました、簡単でした。　「シーソーの原理」でした。 「シーソーの原理」とは、それは物体の重心が支点の両側にある場合、支点を中心に物体が回転するとき、重心が下がる方向に力が働くの原理です。 その後、機械加工ラインで旋盤をみました、旋盤の原理は何なのか？　これもシーソーの原理だった。 シーソーの原理の補足をします。 物体の重心が支点の両側にある場合、支点を中心に物体が回転するとき、重心が下がる方向に力が働くことを利用した原理です。例えば、シーソーの場合、片方に乗った人が重い場合、その人が下に下がります。上下直線運動に見えるが直線運動ではない、回転運動は思いつかなかった。旋盤は、切削工具を支点とし、被切削物を回転させることで、「シーソー原理」の切削加工をしています。

事務作業中にソフトウェアにプログラム・エラー

「Robotic Process Automation」RPAは人のマウス操作、キーボード入力、操作の順番からプログラミングされている。事務作業中、ソフトウェア・プログラム・エラーが起きた。そこで業務の手順書を引っ張り出して業務に支障が出ないように暫定対処をした。でも手打ちタイピングによる暫定的処置入力は効率というには程遠い、事務の生産性が低下した。このようなことは日常起きている。その不具合解消のため、改善にチャレンジしている。 さて、RPAプロジェクトに憲章を採用し原理・原則を採用していますか？さらに5つの要素、１. プレイヤー、2.付加価値、３.ルール、４.戦術、５.範囲　を採用していますか？

注記：Principleは数学原理、自然科学原理、哲学原理など。 Fundamental Ruleは人が決める、複数の人間が決めるルール、規則、決まり事

知っておいた方がよい、原則として採用すべき事例：

１． 専門化の原則 各部門は分業し特定の業務に専門的に特化し、知識・能力の集中し、効率的に業務を遂行し、ノウハウを蓄積する。そしてプロジェクトを遂行する。 ２． 権限責任一致の原則 チーム構成員に与えらえる権限は担当に見合った権限である必要があり、その権限に見合った責任を負う必要がある。 ３． 統制範囲の原則 「ビジネスコントロールスパン」、一人のプロジェクトマネージャーが直接管理できる部下の人数、プロジェクト範囲に限界があります。それを考えた階層管理体制を考える必要があります。 ４． 命令統一性の原則 プロジェクト組織内の上下、横の関連部門の関係では、常に特定の一人から指示・命令となる命令系統を構築し、プロジェクト組織の秩序を維持する必要があります。 ５． 権限委譲の原則 トップマネジメント(経営幹部）は反復的な業務は部下に権限委譲し、緊急事態への業務対応、関連するプロジェクトに専念すべき。経営幹部はProject Charter (プロジェクト憲章）のExecutive SponsorやDepartment Sponsor記入欄に記入し、resourcesへの支援役割を果たします。

経営環境の変化をプロジェクト憲章に随時反映させる

プロジェクト憲章を使いプロジェクトを運営している時、それが長いプロジェクト期間、短いプロジェクト期間でも経営環境の早い変化が起きます。 将来に、眼を向ける時間が不足してしまわないようにプロジェクト憲章の見直しが必要です。

プロジェクト： 計画が粗いプロジェクトはムダ、ムラのある、いいかげんな計画です。隅から隅まで詰めることがされていません。その結果、あちこちに使われていないスペースが残ります。このスペースを、ゆるみやたるみを意味する「スラック」と呼びます。詰め方が粗いので何も入らずに残る部分です。そして、スラックがあることは雑な粗い計画に特有です。スラックは資源があまっているときに起きる結果です。 粗いプロジェクト計画のあと、活動アイテムをひとつ追加したい時、あなはそのアイテムをただ放り込めばいい、何かを取り出す必要は？とは考えません。粗いプロジェクト計画には、そもそも余分なスペースとしてスラックがあったから、中身を見直し、整理し直す必要はない。しかし詰められたプロジェクト計画の場合には、何かを追加するには何かを出さなくてはならない。 あなたの組織が裕福なら何かを犠牲にしたトレードオフはしなくてもプロジェクトは回ると考える。貯金からResoucesを引き出しプロジェクトを回すのだ。スラックがあるから、トレードオフをせずに済むとして、経営資源のムダ、ムラ、3ムダラリの改善について何も考えない。 Resoucesのスラックは……見えるかな、何とも言えないかな