2017年12月 1日 (金)

PDCAはサイクルではなく同時進行させるべきもの

PDCAをサイクルにしようとすると、おかしくなる。

PDCAは4本同時進行させるべきものだ。

 

Plan, Do, Check, Actではなく、Planning, Doing, Checking, Actingとして同時に-ingさせるもの。

 

Pdca_3

 

そのようにすれば、PDCAのAがActなのかActionなのかとか、PDCAよりOODA(Observe, Orient, Decide, Act)の方がいいとかは、大したことではなく、むしろ、組織ごとに気になることがあれば、5本以上走らせたっていい。

アイゼンハワー大統領がノルマンディ上陸作戦の計画段階で言ったとされる言葉がある。

"Plans are nothing, planning is everything."

PlanではなくPlansと複数形なこと、planではなく日本語にしにくいplanningであることの意味を十分にくみ取った邦訳が見当たらなかったので、自分なりに訳すとこんなかんじ。

「計画(書)に熟慮を重ねることが重要なのではない,計画(作業)を継続することが重要なのである.」

だから、PDCA Cycleと言わずに、PDCA Threadsと呼ぶ方がよい。

12月 1, 2017 | | コメント (0) | トラックバック (0)

2007年5月25日 (金)

リスクは細部に宿りたもう

「リスクの集中管理」と言った場合に、リスクを集中的に管理するというのは、リスク管理作業を集中化するということを意味するのではないと思っている。
そのように集中化できることを否定はしないが、そのようにするには、リスク管理のスーパーマンを想定しなければならない。

すべての企業にそんなスーパーマンはいるのだろうか?
いたら頼めばよいが、いなかったら育成するのだろうか?
育成できないならあきらめるしかないのだろうか?

そんなことについての考えを、翔泳社の IT Compliance Web が取材でまとめてくださったので、よかったらどうぞ。
もとは雑誌の記事だったけれど、Webにも掲載されたのでお読みください。

IT Compliance Web

 「リスクは集中管理できるのか~企業における法対応とITのバランス

5月 25, 2007 | | コメント (3) | トラックバック (0)

2006年1月 4日 (水)

人材育成策を誤るとその分野は衰退する

ひとつの産業分野が発展するライフタイムは、概ね50年という目安があるようだ。
IT産業分野の開始をどこから計るのかは難しい。
コンピュータが実務で使われたのは、アメリカ軍の大砲の弾道計算のシミュレーションが最初だと聞く。

 

そこから計ると、そろそろ終末の時期を迎えている。
ここで注意しなければならないのは、産業分野のライフサイクルではなく、発展のライフサイクルということである。
IT産業で言えば、ITが社会からなくなることはないだろう。
そのため、IT産業に従事する者は、自分の分野だけは過去の分野とは異なり、永遠に存在する分野なのだと楽観する。
それは間違っていないが、ただ、存在するのと、発展を継続するのは異なるのだ。
過去の分野も消滅したものはなく、発展しなくなっただけだ。

 

IT産業はどうだろうか。
過去のものと同じく存在し続けるが、発展については、よく考えた方がよいかもしれない。
なぜ、産業分野の発展はライフサイクルを持つのだろうか。
そして、それが50年間という数字は何を意味するのだろうか。

 

50年間という数字は、50年に一度、華やかな分野が出現するということではない。
ひとつの分野の発展が生まれて消えていく波のようなものだとすると、ひとつの分野の波は、次の分野の波に直列的につながってはいない。
ひとつの波と重なるようにして、次の波が現れ、波から波に移っていくようにして、発展する分野は交代していくのだろう。
波の重なり具合によって、華やかな分野の出現は50年よりも短い時間で訪れることになる。

 

分野の発展のライフサイクルは、分野を支える人材と関係することのように思えてきた。

 

※この記事は書きかけです。○○○○○の箇所に何かもう少し書こうと思っています。

 

【失敗は成功のもと】

 

失敗の経験なくして成功はしがたい。
ビジネスが確立していない分野、言い換えれば、企業が収益の柱としていない新興分野については、企業は失敗を許容する。
悪く言えば、失敗しようが成功しようが、どうでもいいと思っているかもしれない。
そのような期待されていない環境で、人は小さな失敗の経験を積み重ねて成長することができる。
かれらにとっての成功は、常に、以前に経験した小さな失敗と同程度か、それよりもほんの一回り大きな成功だ。成功を高くは期待されていない中で、人は様々な試行錯誤を経験することができる。ある意味、ダメもとの精神が冒険的な試みを躊躇することなく、経験の幅を大きくする。たとえば、失敗についての心配が皆無ではないような試みも、実際にやってみて本当に失敗するかを検証するなどということも大胆に行なうことができる。そのような失敗がまったくの無駄ではなく、その経験から、成功のヒントや、失敗の再発防止のヒントが得られることもある。必ずしも成功の経験だけが有益なのではなく、多種多様の経験からは必ず何かを得られるものだ。
それに対して、ビジネスとして確立した分野については、企業は成功だけを奨励し、失敗を未然に防ぐように仕向ける。ベストプラクティス、成功事例などという言葉が現れてくれば、その兆候だ。
その結果、その分野に後から入ってくる者は、失敗の経験を得る機会を減らすことになってしまう。失敗の経験を減らすことは組織としては一見有益だが、個人にとっては必ずしも有益ばかりとは限らない。個人に有益でないことは、中長期に見て、組織にとっても実は有益ではなくなる。

 

失敗は成功のもと。という実に基本的なことを企業は見失うことがある。
失敗を単に不要なものと決めたとき、成功のもとがなくなりはしないかを、その事業分野で慎重に考察する必要がある。
事業分野によっては、成功のもとの多くが失敗であるかもしれないということがないとは言い切れない。

 

ここでいう失敗には、既知のものと、未知だったものがある。
○○○○○

 

例外的なことの発生しない分野については、それでよいかもしれない。しかし、例外的なことが発生しない分野とは、その分野の成長が見込まれていないと考えることもできる。
どんな分野でも、多かれ少なかれ、例外は発生し、それに対処することは求められていると考えるのが妥当だろう。
例外に対処することを含む分野では、・・・
失敗を未然に防いであるような環境の中では、人は失敗を自らの経験としては体現せずに、失敗は知識としてだけ蓄積していくことになる。
経験から知識は生まれるが、知識から経験は生まれない。
その結果、予め想定された失敗以外についての対処は、・・・

 

失敗に対処する能力というのは、小さな規模から大きな規模に、経験を段階的に積んでいくことでしか、人は身につけることができない。
スポーツで言えば、まったくの初心者が上級者向けのことだけをしていれば、失敗の経験をいくら繰り返しても、基礎を身につけることができないことに似ている。(ここでイメージするスポーツとは、初級者と上級者によって、与えられる条件は同じで達成難易度だけが上がるものよりも、与えられる条件そのものが変わるようなものをイメージするとよい。たとえば、スキーなどは、初級者コースと上級者コースで条件が異なる。)
初心者は、初級者向けの訓練をして、その後、段階的に中級者、上級者コースに進む方が、初級者コースを経験せずに上級者コースでの失敗だけを繰り返している者よりも、早く、上級者コースを習得できるのである。(もちろん、最終的に上級者コースを習得できるかは、本人の資質などにも依存するが。)

 

段階的に経験させるときに重要なことは、小さな規模のうちには、ある程度の失敗を経験させることが、例外対処能力の獲得に役立つということだ。
小さな失敗を克服しているだけでは、大きな規模になってからも、最低1回は同じ規模の失敗を許容するしかないかというと実はそうではない。
小さい規模の例外対処能力を着実に身につけていることで、その後、大きな規模の仕事を任されるようになっても、失敗が小さい規模のうちに、それを改善できるようになり、結果的に大きな失敗には到らなくなると考えることができる。
逆に、小さい規模での失敗の経験がない者は、大きな規模でいきなり大きな失敗をして、それに対処できないということが考えられる。
先のスポーツの例で言えば、初級者コースから始めていれば、上級者コースでいきなり大怪我になりにくいのと同じだ。

 

しかし、企業ではビジネスが成長するとともに、そこでは、大きな規模の仕事だけを取り扱うようになる。
後進の者は、小さな規模のビジネスを任されるという機会は減り、大きな規模のビジネスの一要員となって仕事するようになってしまう。そのような環境では、失敗は未然に防止され、防止のための知識を得ることはできても、実際の失敗を経験することはできない。
そのような一要員が、やがて就業年数を積んで、仕事を任せなければコストの採算が見合わないような年齢に達したとき、任せられる仕事は、いきなり大きな規模の仕事しかないということについて注意しなければならない。
かれらは、予め想定された既知の失敗を、予め先人が定めた手順どおりに対処することには、相当の経験を持っているはずだ。
しかし、失敗の未経験者が、未知の失敗を見つけ出したり、それに対処することができたりするかは未知数だからだ。
大きな規模での未知の失敗が発生したときには、ただ幸運を祈るしかない。
運に頼りたくなければ、大きな規模のビジネスも取り扱うようになった企業は、新人に小さな失敗を経験させるための環境をどのように与えるのかを考えなければならない。

 

ただ、IT産業界においては、大きな失敗の際に不運が起こる頻度がいまのところ多くないように思われる。
むしろ幸運にも、なんとか乗り切ってしまう。
不運の発生頻度が少ないために、それらの失敗は温存されやすくなり、例外対処能力の重要性が見落とされやすい。
不運の頻度が少ないことは不運だと言える。

 

【人は育てるものではない】

 

人は育つものであって、育てるものではない。

 

適正のある者には、何も指導しなくても、自分で育っていくものだ。
逆に適正のない者には、どんなに労力をさいて指導をしても育たないはずだ。
人が人を育てる。ということは、成り上がった想いなのかもしれない。
その成り上がり精神は、些細な配慮を欠くだけで、戒められることになる。

 

職場は教育の場ではない。
学校では、自分の適性を知るために分野を眺めるべきだ。
そして自分の適性に合ったと思う職場を選択して就職すべきだ。
職場で、自分の適正を引き出してもらおうとするのは筋違いだ。
と言ってしまうと、みもふたもないだろう。が、少なくともその考え方を基本とすべきだろう。
とはいえ、自分の適性を見誤った者が職場に入ってくることは避けられない。
そのときに、その人それぞれに見合った仕事の内容や進め方を指導するのは、直属上司の責務ではある。
しかしながら、適材者がほとんどいない職場を現場上司だけでなんとかするのは無理だ。
基本を貫くためには、事業の運営が重要だということになる。

 

【○○○○○】

 

人材育成の方策を整備すれば、その分野には秀逸な人材は訪れなくなる。

 

人材育成の方策を整備するということは、レールを敷くようなものだ。
そこには、敷かれたレールを走りたいと思う人が多くくることになるだろう。
そこには、物事は教えてもらうのが、当たり前と思う人が多くくることになるだろう。
そこからは、自分でレールを敷きたい、新しい道を開拓したいという人は敬遠するようになる。
レールの敷かれたその分野には、長老がはびこり後進の失敗に、舌打ちをするからだ。
ころばぬ先の杖。という言葉があるが、その杖は自分で探してつかむからこそ、その有難みがわかるというものだ。
ころびそうな後進に、ころばぬ先から杖を渡すのは、先輩の自己満足に他ならない。
渡された者は、実際にまだつまずいたことすらなければ、その有難みを本当にはわかり得ないものだ。

 

○○○○○

 

ロードマップなどというものを作成した時点で、その産業の成長は減速し、停止する。
ロードマップの意味からも、それは当然だ。
分野におけるロードマップを作成したいという想いは、その分野に先に入った者が、自分を頂点にするためのレールだ。
そこには自分よりも劣る者しか立ち入るな。と書いているのに等しい。
自分の道を開拓したいという者は別のところに行け。と書いているのに等しい。
ところが実は、その分野を実際に立ち上げた有能な者は、そういう想いはないように思う。
かれらは自分が歩んだのと同じように、後進にも好きなように歩ませるのでよいと思っているに違いない。
そうではなくて、実際にロードマップを作りたがるのは、その分野に先に足を踏み入れてはいるが、実際には無能である者や評論家的立場である者が多い。
無能である者の中には、後から来る有能な者にその分野で活躍させ、そこからの搾取で自分の利益を獲得しようと思う輩もいる。
そのため、ロードマップ作成を先導する者は、自らでは作成できず、人のいい有能な者達から情報を抜き出して作成するという手法を取りたがる。
そのような無能な者が、分野にはびこったときに、その分野の成長は止まるのだろう。

 

ロードマップを作ると、次は人材育成のカリキュラムを作ろうとする。
そういう無能な者に育成される程度の者しか集まらなくなるのであるから、その分野の行く先は知れている。

 

ロードマップやカリキュラムなどの人材育成の方策の整備ではなく、人材育成の環境だけを漠然と提供する方がよい。
すなわち、後進が必要とするときに、先輩が後進に知識を与えることができるコミュニティの形成だ。
ほんの少し、先輩が口を出すのを許すとするならば、先輩が自らの行なっている仕事の内容についてを、どのようにその内容を立案し、決定し、何を注意しながら行なっているかの解説をする。ということはあってもよいだろう。
情報共有という観点では、成功例よりも、むしろ失敗例の勉強を好むようにすることもよい。
成功例だけを取り上げ、こういう状況ではこうすればよい的な、成功を一般論化して体系整備するのも、やめた方がよい。
ロードマップやカリキュラムのような定型の整備ではなく、試行錯誤の連続を意識した上で、分野内における既知の失敗の再発防止についての情報共有の仕組み作りに専念することが有益だ。

 

ころばぬ先の杖で喩えるならば、杖を渡すのではなく、杖は単に使っているだけでよい。
杖を意図的に見せることすらしない方がよい。
「杖の存在にまだ気づいていない後進がつまずいたときに、なぜあの先輩はころばなかったのだろうか?」と考え、「そうか!あのとき先輩は杖を使っていたからだ。」ということを自問自答した者から、杖について聞かれたときに、「杖の説明をする」というのが理想的だ。理想的と言っているのは、これをどこまで現実的なところで手を打つかの妥協の範囲はあるということだ。
つまずくのと、ころぶのとは異なる。ころばなくても、つまずいただけで、ころぶことを予測し、それについて考える能力を持っている人がいる。つまずく経験すらさせなければ、その能力の違いを知ることはできないし、その能力が伸びないかもしれない。
つまずくことで、ころばぬためのことについて意識をして、物事を考える能力を培うような環境が重要だ。
そのような者が集まる環境で、分野は成長し続けるはずだ。

 

逆に、この環境では、実務として無能な者は生き残ることができない。なぜなら、後進に指導をできない者は、存在価値がなくなるからだ。
実務能力のない者が、先に居るという理由だけで、他者からの搾取によって生きながらえるという環境になることは、その分野を発展させる人材の獲得をやがて失うことになる。
ロードマップ作成や、カリキュラム作成、人材育成などでは、そのことに十分に注意して、そのような環境にならないように PDCA を持続しなければならない。それができないのであれば、むしろ、しない方がましである。

 

【大御所の現れはその分野衰退の警告】

 

新しい分野を開拓した者は、次にその分野に入植してくる者に対して、変な期待をすることがある。

○○○○○

 

【IT産業に開拓精神のある人材を確保し続けることはできない】

 

発展のライフタイムが、分野を変えて波のように繰り返すことの原因がここにあるように思う。
50年間という期間が、その分野を開拓した者達が社会から引退するまでの期間としてみるとわかったような気にもなる。

 

産業そのものが進化するためには、新しい分野が発展する必要がある。
ところが、新しい分野を開拓できる人材の数は、世代が変わってもそんなには変わらないのであろう。
そうであれば、新しい分野を立ち上げて発展させる者達は、移り行く波を乗り継いで行くことになる。
何かの発展がさびれ、何かの発展がたち生まれていくことの繰り返しだ。
そう考えれば、仮に、IT産業が最善の人材環境を構築できたとしても、そこに開拓精神のある人材は獲得し続けられないと考えてみるべきかもしれない。
そこにいつまでもとどまらせてしまっては、次の分野の開拓が進まないということになる。
次の分野の開拓にかれらを回し、残された分野はその維持に務めるような人材が支えるのである。
そのとき、その分野は発展産業ではなくなるのかもしれない。

 

IT産業にとって、いつまでが発展期なのかは誰にもわからない。結果的にわかるだけのことだ。
ただ、開拓精神のある人材が訪れない環境を作ることは、IT産業発展のライフタイムをみずから縮めることになってしまうことは確かだろう。
寿命をまっとうするためには、人材育成のあり方が鍵であり、少なくともそれは延命策ではなく、どれだけ短くせずに済ませられるかということだけなのだろう。

 

※2023年追記

【リスク管理できる人材の育成】

リスク管理スキルを向上させるための日々の鍛錬に役立つのはSWOT分析だと思う。
極端に言えば、SWOT分析のWTをしっかり書けていない人は、他のことでよい結果を出していても幹部にしないくらいのことが必要なのかもしれない。
運がよくて成功したのか、リスクを管理しながら成功したのかを見極めることは重要だからだ。
これをちゃんとやらないと、正直者がバカをみるキャリアパスになりかねない。

組織全体としては、本来は情報セキュリティに限らない包括的なリスクマネージャが必要で、日本企業には「ご意見番」として存在していたのが、どんぶり勘定経営が縦割り経営になる過程で減った印象がある。
日本企業の経営会議では、ご意見番を輪番制にするとよい。当番の人は、議題について反対意見を意識して述べるという役割にする。普段なら賛成する議案であっても、とにかく重箱の隅をつついて無理やりでも反対理由を探して意見するという役割だ。
輪番制にするのは、反対意見に禍根を残さずに、当番になったときのお互い様で済ませられるようにするために有効だ。

 

1月 4, 2006 | | コメント (0) | トラックバック (0)

2005年12月 9日 (金)

みずほ証券発注ミス

まるちゃんの情報セキュリティ気まぐれ日記にも出てますが、小さな事故をこまめに対処しない組織では大きな事故が発生するというHRO対策の基本そのままの事例ですね。

推察ですが・・・

・株価と株数の取り違い

入力画面でそれぞれを区別する工夫が、画面設計上足りなかったのではないかと推察します。
東証での同じ、株価、株数取り違えによる億単位のミスは、今回で3件目のようですから。
そう考えれば、より少額のミスは常態化していたかもしれません。
その他には、ITではなく業務処理手続きに落とし穴があったかもしれませんね。
たとえば、ほとんどの指示が、「10万円で10株を売り」というように、「金額、株数」という順番の様式なのに、その中に、「10株を10万円で売り」という指示が混在すれば、それを「10円で10万株を売り」と入力してしまうでしょう。

・警告画面を無視した

警告画面の出現頻度が高い設計だったのではないかと推察します。
しょうもないことまで、常に警告画面を表示させるようなシステムでは、人は、それを無視しはじめるでしょう。
極めて稀にしか表示されないような、警告画面を、即座に無視するとは思えません。
あるいは、グローバライズ気取りで、意味もなく警告文を英語で作っていたり。
日本人には、「WARN や ALERT」と表示するより「警告」と表示した方が直感的なはずです。でも、かっこつけて英語で表示するものが意外に多いですよね。
少なくとも、警告画面の頻度が少なくなるように、警告条件を考慮するのは、設計上の問題です。そして、警告条件が取り引き条件に依存するなら、警告条件を変更できるような設計がなければ、「人」はそれを正しく使えません。
最後は「人」なんだという配慮に欠けた設計のシステムが最近多い気がしています。

などと勝手に推察してみましたが、そんなことは揚げ足取りの邪推でしかありません。
まぁ、いろいろな事情があったのでしょう。
しかし・・・

・再発防止のためには

一般的に考えて、これまで株数と株価を入れ間違えるミスがまったくなかったところに、いきなり数百億円のミスが発生したとは思えません。
日々の小さなミスを軽視して、設計変更をしなかった責任は重いはずです。

まさに、HRO対策を怠ったということですね。

HROとは、 高信頼組織(High Reliability Organization)の略で以下の書籍で解説されています。

 不確実性のマネジメント(Managing Unexpected)
 出版:ダイヤモンド社

良書なので、amazon に書評を書いたことがありますし、佐藤の講演では、ちょくちょく紹介してます。

バカな行政、バカな報道、バカな国民では再発は防げない」で書いたとおり、今回のような事件を他山の石として失敗から教訓を学び、自身についても同種の潜在的な問題点を改善をしないといけませんね。

12月 9, 2005 | | コメント (0) | トラックバック (0)

2005年7月14日 (木)

PDCA 本家の陥落

NASA はアポロ月面着陸プロジェクトのときにプロジェクト管理手法を確立させた。その後、その手法は「プロジェクト」と呼ばれるものすべてに採用された。いわば、NASA はプロジェクト管理手法のご本家だ。しかし、いまやその本家の威厳は地に落ちてしまった。


いまや工程管理の常識である、PDCA, WBS, PERT図などのプロジェクト管理手法やツールのほとんどは、米国 NASA がアポロ計画の中で生み出したものだ。
情報公開制度により、アポロ計画における当時の手書きの議事メモなども含めて見れるようになっている。
それらを目の当たりにすると、アメリカの先進性に驚かずにはいられない。

そんな NASA が今やプロジェクト計画本家の見る影もない。


毎日新聞 2005年7月14日 3時26分 (最終更新時間 7月14日 10時56分)を参照

発射直前の TBS ニュース23 で取材が放映されていたが、プロジェクト指揮官が長官に品質改善のためにプロジェクトの見直しを要請するも、当初計画日程遵守を偏重し却下されたため、指揮官が辞任している。
指揮官は取材の中で、「いまや現場は悪いことは上に報告できない環境にある。上も良い報告しか受付けない。」と言っていた。

HRO としてあってはならない環境だ。

いくら WBS と PERT 図を厳密に準備しても、PDCA がちゃんと機能しなければ意味がない。

最近ときどき、PDCA を PDC としているのを見かける。
Plan, Do, Check したら、Action を適切に取らなければならない。
Check しっぱなしでは意味がない。
Plan, Do, Check が手続き的に実施できるのに対して、もっとも重要な Action は、人の判断によることになる。
PDCA を P|D|CA と分けるのは、あまりに危険だ。
本質的なところでは、PDC|A で分けてもよいくらいだと思っている。
PDCA を PDC にする人達は、C+A をまとめて C にするということがあってはならない。
A が異質だから PDC についてまずは考える・・・というのはナンセンスだろう。

PDC については、より多くの人間の意見を求め、上位までの承認プロセスを持つのがよいだろう。
しかし、A については、現場にもっとも近い少数の人間の意見を十分に尊重する必要がある。
fail safe の観点からすれば、Go サインについては、現場全員の同意を必須とする必要があるだろう。
ひとりでも、No Go がいるならば、No Go をまずは決定すべきだ。

現場指揮官が No Go を要請し職を辞してまで訴えたものを、その長たる者が、Go を強行するような NASA には、もはや、アポロ計画の頃のようなプロジェクト遂行は期待できないのだろうと思った。

納期という圧力に人が負けたとき、現在のプロジェクト管理手法のすべてが機能しないことは、図らずもそれを生み出した NASA が証明したことの意味を考えるべきだろう。

アポロ計画の遺産である WBS や PM 手法を使った、昨今のIT構築であるが、ちゃんと PDCA ができているのだろうか・・・
似たような話しを見聞きするのは気のせいだろうか・・・

NASA は発射延期により、最後の最後でぎりぎり No Go のブレーキが残っていたわけだが、はたしてIT構築の現場はいかに?

7月 14, 2005 | | コメント (4) | トラックバック (0)