事故やエラーは続いて起きる

第21話：ＯＲの話（1）ランダム到着の場合の到着間隔の分布

ＯＲ（オペレーション・リサーチ）は数学的手法を使った仕事のためのツールである。
有名なのは、古い話であるが、第2次大戦でベルリンに包囲されたアメリカなどの軍隊に対するリニアプログラミング応用の補給計画。などが有名である。

企業では、予測誤差の理論の基づく在庫管理や、待ち行列理論の応用で、受付窓口の計画など各方面で使われている。専門的に使うには、少しばかり勉強が必要だが、おおよその事を知っていれば、通常の算術的な考えから抜け出して、新しい視点から仕事の合理化を考えることができ、思いがけない成果を得ることが出来る場合もある。

アサヒ芸能という雑誌からのスクラップである。「黒い報告書」「美人ママの別れ話に逆上した中年男の不覚」思わず読んで見たくなる表題である。書き出しは、「飛行機が一機落ちると、次から次に落ちるし、警官の不祥事が一つ起きると、続けて起きる。どういう訳でこう同じような事件が続いて起きるんだろうな。航空機事故も警官の非行も滅多にないことなのになあ。この記事を読んでみろよ」と私は後輩のＹ刑事にその日配られた6月12日付のＡ新聞の記事を指で示した。云々・・・と続く。美人ママのことは気になるが、ここでは、ここにある「たまに起きることは続いて起きる」ことに焦点を合わせよう。

ＯＲ的には同じ問題を提起しているもう一つの記事を見てみよう。これもアサヒ芸能のコラム記事からである。
表題は「エラー偶発論は疑問」とある。内容を紹介してみる。
「エラーは偶発的現象だから仕方が無い。問題はエラーしたあと、どう処理するかだ」プロ野球のどの監督もこういう。しかし、エラーは本当に偶発的現象なのか。私はエラー偶発論に疑問を持つ。




吉田（阪神）は昭和28年入団以来、39年までの12年間に1481試合に出場、その間、288個のエラーを記録している。つまり502試合に1個のエラーの割合である。
広岡（巨人）は同じ要領で昭和29年以来、やはり39年までに1213試合に出場。227エラー、5.3試合に1個のエラーである。

この数字を比較すると、吉田、広岡の技術は全く互角といっていい。ところが、エラー内容を分析してみると、実は両者に大変な差があることに気がつく。
吉田は一度エラーをすると、やたらにポロポロはじく。逆に広岡は安定したベースでエラーを繰り返している。次の表を見ていただきたい。吉田は2試合連続エラーが57回広岡は25回。だが吉田は10試合以上間隔が空くと殆どエラーしていないのに、広岡は着実に（？）
繰り返している。このことは、精神的に動揺しやすい神経質な吉田は、1個のエラーでガクット参る。見かけは神経質だが実際はタフな広岡は、くよくよしないで気分転換が上手いから、エラーしても翌日の試合ではケロッとしているからではないだろうか。吉田、広岡だけの話ではない。このことは誰にでも通じる話ではないのか。エラーにはだから偶然的現象そのものよりも、選手個人の性格によってひょこひょこと顔を出してくるものだと思うのだが。


さて、雑誌からの引用ばかり並べたが、最後に私が乱数表から作成した「ランダム到着の場合の到着間隔の分布」のグラフを掲げる。この図は前掲の野球の図と殆ど同じ性格の表であることがわかると思う。
表の作り方について補足をしておくと。乱数表というのは0から9までの数字がランダムに並んだ数表であり、そのランダム性が検証されている表である。図の平均0.2の時の実線は、その乱数表の始点から数字を読んでいって、「0と1」が出る間隔をその間隔の頻度別にプロットしたものである。（例えば3・5・9・6・2・1・0・7・4・1・8・0・）の間隔は先ず1と0が続くので間隔0が1回。次いで0から7と4を超えて1となるので間隔2が1回。次ぎは1から8を超えて0が来るので間隔1が1回・・・のように数える。

図の平均0.4の時の実線は「0,1,2,3」の4つの数字が表われる間隔を同じように数えた間隔の数字の出現頻度をプロットした物である。
なお、図の0.4の時と0.2の時の点線で書いてあるものは、このような作業を無限にやったときの理論線である。
例えば1分間に平均4回エラーが発生する場合と、1分間に平均2回エラーが発生する場合のエラー発生間隔の分布はこの図のようになるということなのである。

この図のように到着間隔ゼロ。即ち続いて起きる確率が一番高いことが理解できることと思う。

長くなったが、要するに事故などは続いて起きる確率がいちばん大きいと言うことであり、その傾向は平均発生率が多いときは勿論だが、たまに起きる時でも続いて起きることが一番多いのである。

またこのことが分かれば、野球のエラーの話はグラフの間隔12回以後の部分で吉田の線が低くなり、広岡の線が高くなている部分的なところに目を注いで誤った判断をしており。また筆者の言うこととは矛盾して、このグラフは、エラー偶発論（ランダム発生）が概ね正しいことを証明しているものだと言うことが分かる。

算術的な数字に捉われず、グラフを理論的な目で見れば、明らかに広岡がエラーの少ない選手であり、吉田が広岡に及ばない実力の差は明らかだと判断できるのである。

革新を進める１０か条

　　　　　　　　第20話：革新を進める１０か条

色々な仕事を見る目とか仕事を革新して行ったケースについて、順不同に述べてきた。仕事について、こんな見方考え方をすれば、辛そうに見える仕事にも、面白さが見えてくるのではないかと思うのですが如何でしょうか。

さて、今回は色々ないい考えが浮かんできても、組織の中では頭の固い上司に潰されたり、無視されたりで、折角の楽しくなるべき仕事が壁にぶち当たって、憂鬱になったり、もう止めたい。と言う気持ちになることが、少なくありません。

そんな時どうすればよいのでしょうか。これは私が昭和46年に書いた「事務革新入門」という本からコピーしたものです。私がコンサルタント暦24年で、生産管理、事務管理、コンピュータ導入などのコンサルテングを手がけていた頃です。

私達のコンサルテングは、提案書を作ってさよならと言うのでなく提案の実施までお手伝いするのが特徴でした。しかし提案の実施にはクライアントのトップや関係幹部そして関係担当者を仲間にしなければやれません。

高額のフィーを頂いているため、提案を実施しなければクライアント側もロスになるので、会社の従業員の提案に比べ、やりやすいのは当然ですが、やはり実施に持ち込むには、改善案を作り出すことに匹敵する困難さがありました。

そんな苦労話をまとめたお話です。では以下本文になります。


革新をすすめる十力条

世界が進歩し、そして経営が革新されることについては、だれもが全く賛成である。しかし、その革新に当面する個人にとっては急激な変化は不安であり、その結果大局的には賛成であっても、反対の立場に立つ場合が普通である。たとえば、EDPの普及に対するホワイトカラーの不安とコソプレツクスについてのNICBの調査によれば米国のホワイトカラーは、

1）自分の現在の地位を失うであろぅか。
2）自分の収入は減るであろうか。
3）昇進の機会が減るのではないか。
4）今までに自分が習得した仕事上の技術知識が、ムダになるのではないか。
5）新しい技術を習得しなければならないのであろうか。もしそうなら新しい仕事をうまくやれるであろうか。　　　　　　　　
6）EDPの導入により、自分の仕事の重要性や威信が減りはしないか。　　
7）自分が熟知している仕事上の様式や記録が必要なくなった場合、自分の責任をはたし て満足に遂行していけるだろうか。

　　　などの恐怖をもっていることが明らかにされ、その対策として、

1）仕事に対する保障
2）現行給与の維持
3）ＥＤＰと並ぶ従業員の重要性
4）新しい仕事に対する機会
5）再訓練を受ける機会の保障
6）ＥＤＰが単調な仕事から従業員を解放しうる能力を備えているものであることを理解させる。


などのことをPRすることの重要性が報告されている。
そして、これらの恐怖と不安は、ＥＤＰ以外の革新においても同様おこるものであり米国に限らず、わが国でも同様な現象が予想される。

　したがって、革新をすすめるに当たって計画者は、あらかじめそれらの個人的な不安を予見し、必要な手を打っておかなくてはならない。さて、これらの前提的な各種の対策を行なったとしても、革新はそれだけですすむというような性質のものでなく、計画者の人間的な説得とリーダーシップが、また加えていくらかのテクニックが必要とされる。

以下それらを十力条の戦法として、紹介する。これらは筆者のコンサルティソグの経験から典型的なタイプにまとめたもので、実戦に当たっては適宜組み合わせ、または新しい方法をつくり出して適用しなくてはならない。

「まごころ戦法」

人を説得する場合、巧みな話術やアピールが重要であることは、いぅまでもない。しかし一番大切なものは、提案者の〃まごころ〃であると思ぅ。表現をかえれば、誠実といぅことにもなる。その人のために、その会社のために、そして社会のために、ほんとに役立つために信念をもってすすめ、またその提案に関係ある不利な情報もすなおに開き、弱点は率直に認め、謙虚に修正する態度は、反対者を動かさずにおかないものである。

戦法というより、むしろ提案者が常に保持すべき心のうちの態度とでもいぅべきものとして、基礎的な必要条件である。

　　“至誠天に通ず”“一心岩をも通す”

「波状攻撃法」

　一回の説得でだめなら、二回三回・・・・そして、手をかえ品をかえて説得する。相手が提案者の顔を見たら、「大塚さんがきたからまた例の話だな」と思うぐらい回数を重ねる。根気よく説得するわけである。

　短気をおこして、一きょに押し切ろうとすると、コジれてしまうかケンカになる可能性が大きい（まれには雨降って地固まる場合もあるが、期待すべきではない）。
相手が提案を理解し、答を出すまで、帰るときのアイサツは、いつでも「またきますからよくお考えになっておいていただきたい」形で後日を約束する。

　　〃雨だれ石をもうがつ〃


「ほととぎす戦法」

　〃鳴くまで待とうほととぎす〃いろいろと手をつくしても、なかなか説得できない場合、（こんなときは相手が過去に同種の案に苦い経験をもっているか提案自体に致命的な欠陥があるにちがいない）こんな場合は、案の締密な再検討がもちろん必要であるが、案に問題がなくても一応その全面的な実濾をアキラメて、OKがとれる部分だけでも実施する。または案の一部を修正して実施可髄なものとする
。
　要するにアキラメもまた肝心である。
　しかし、ほんとにあきらめるのでなくて、アキラメタ部分や修正部分は決して忘れず、時節を待って（反対者が移動するとか、業界の環境がかわるとか）日の目をみせてやることである。三年ぐらいの間に、おそらくチャソスは訪れると考える。

「からめ手作戦」

提案に反対する原因が提案者との親近感がないために起こっているいるような場合、この方法は有効である。提案者は、むしろ提案前に必要と認めたら、この作戦を実施すべきである。方法は、仕事以外のことで相手と親しくなることで、マージャンとか一ばいやるとか、ゴルフにいくとかで、趣味からはいるのが一番自然である。

　他の方法では、先輩、知人等の人間関係を通じて関係をつけるようにする。最後の手段は家庭訪問である。とにかく、どこか相手との間に一本のパイプを通ずることに成功すれば、そのパイプを利用して。次第に仕事のことについても理解し会えるようになるものである。ただしこの方法は間違うと馴れ合いに成りいい加減な妥協にもなりかねないので注意を要する。

「売れのこし作戦」

女性にとっても男性にとっても、売れのこりはさびしいものである。その心理的な弱味を利用する点で、この方法は大変危険である。しかし確たる根拠なしに反対している人に対しては、効果的な方法である。

　方法としては、提案対象者を各個にわが陣営に入れ、反対の一人または二人をのこす。その後反対者に「あなたのところは相当むずかしい様子なので、この際提案は一応引っこめます。しかし、ほかの皆さんは案に賛成なので、ほかでは試験的に実施することにします。と伝える。
場合によっては、「テスト計画を常務会に提出することになりました」とつけ加えてもよい。

　たいていは、この段階で反対を徹回してくれるはずである。しかし、ヘタをするとかえってソッポを向かれるので、十分注意が必要であると同時に、ソッポを向かれた場合でも、他の賛成者との協力で何とかやっていける自信がなければならない。もし不安な場合は、この方法をとるべきではない。

　売れのこし作戦の他の応用は、提案事項を実施し成功している他社の見学である。これは会社単位の売れのこし作戦として幹部級にしばしば適用されている方法である。

「引きずりこみ作戦」

　その案に反対するであろう人は、大よそ事前に予想できるものである。この作戦は、そのような人を特にマークして、参加意識をもたせることがねらいである。方法としては、立案過程に特別に参加してもらうこと、また提案に関して、その人に特別多くの情報を事前に与えておくのである。そのためには、その人だけ他社見学にいっしょにいってもらつたりするのも効果的である。

　要するに、その提案について、その人が一番よく知っている状態にし、可能ならば立案に参加してもらうことである。


「かつぎ上げ作戦」

　この方法は、従来も実際に広く利用されてきた方法である。やり方は、反対を予想される人に、提案項目に対する委員長とか幹事とかになってもらうのである。

こうすれば、その人は、たとえ自分自身は多少反対の気持があっても、肩書の手前表立った反対はできなくなってしまう（実際には、その仕事をすすめているうちに、自然と得られる情報により、自分の考え方の片寄りに気づき、自然と賛成の立場になっていく場合が多い）。

　ただし、この場合、有能な副委員長やアシスタントがいないと話が遅々としてすすまず、といって無視するわけにもいかず、かえって案の審議が遅れてしまうことにもなりかねない。運用に当たって、十分な注意が必要である。


「潜航つき上げ作戦」

長に提案して反対された場合、「実際仕事をしている人たちと、もう少し打ち合わせて案を練り直します」というように、案の決定を保留し、その部下に案を売りこみ検討してもらう。案は必要あれば修正するが、たいてい提案の前に、実際の担当者の意見は検討してあるのが普通であるから、ほとんど修正の必要はないはずである。

　とにかく、部下の人たち全員の賛意を得てあらためて提案する。長は、部下の総意にはたいてい従うものである。直ちに賛成を得られなくても、少なくとも案の試行は許可されるだろう。

「集　団　圧　力　法」

　反対者に圧力をかけて、無理に賛成させるなど絶対によくない。しかし、反対者が反対のための反対をガンコにしているような場合は、やむを得ず圧力をかけなければならないこともある。この場合、圧力をかけるにしても、その人の面子が立つよう、なるべく自発的に賛成した形にもっていってやることが必要である。

　それには、集団で圧力をかけるのが割合自然でよい。たとえば、課長会議で提案を行ない賛成者多数の発言を求める（若干事前運動をしておく）。そのようなふんい気をつくれば、一般には少数反対者は妥協せざるを得なくなるのが普通である。
　この方法では、少数反対者が正しい場合、誤った決定が行なわれる場合もあるので、十分注意を要する。


　「上　長　圧　力　法」

　いよいよ最後の手段は、上長からの命令である。しかし、すでに知られているように、命令は命令どおり行なわれないのが普通であり、命令どおり行なわせるためには部下を納得させ、その面子も立ててやらなければならない。

上長であっても、いろいろの方法で部下を説得するのが民主的経営のやり方であり、また実質的に部下を動かすコツでもある。
　したがって、やむを得ない場合でも、集団圧力法との混合形態で行なうのがよい。たとえば、課長会議に部長が出席して討議の様子を開き、最後に、部長がその案を実施する決意を示す方法など有効である。

積算電力計は何故うなるのか

　　　　第19話：積算電力計は何故うなるのか：雑学の応用

キャッユレジスターなどを作っている会社の工場の生産管理システム（といってもコンピューターなき時代のシステムで、推進区式工程管理）の改善を御手伝いしていたときのことである。

「実は困っている問題があるのですが暇を見て知恵を貸してくれませんか」と品質担当の課長さんから頼まれた。契約以外の仕事だから断ってもいいのだが、話を聞いて見ると、この工場で作っている積算電力計が「うなっているが止める方法が分からない」これを直す方法を見つけようと色々やっているのだがわからない。

なんとか対策を考えてくれませんか。とのこと、何となく面白そうな話である。謎解きの面白さに引かれて「何とかやってみましょう」と引き受けてしまった。

さて、以下問題解決にどう取り組んだかを述べるのであるが、その前に積算電力計の構造を簡単にのべておく、といっても皆さんの家庭にも必ず一軒に一台は取り付けられているので、チョット外に出てもらって見ていただけば、分かりますのでこの話がわかり難い人は、見てきてください。

積算電力計の仕組みは、簡単にいえば、小さなモーターが主体で、電力が使用されると、モーターの磁石（鉄板を積み重ね、これに電線を巻いた電磁石）が働き、その磁石のＮとＳ極の間にセットされているアルミの回転子（ローターという）が回転する。

通過した電力量に比例してそのローターが回る。中にセットしてある回転数を累積計算するカウンターによって、消費した電力量が把握出来るようになっている。

問題解決には、問題発生の原因を知らなければならない。私は会社から担当として組んだ生産技術課の「秋山さん」と相談して、発生している「唸り」の場所を確認するために聴診器（医者の使うアレ）と音をシッカリ聞くための静かな部屋（金庫室を使わせてもらった）を調達してもらった。

さて、最初の取り組みは？？？見事失敗。聴診器というのは、人間の肌に密着して、その内部の音を聞くように出来ているので、相手が人間ならば体のあちこちに当てて音の種類と大きさ、また音の出る場所を知ることが出来る。

ところが積算電力計は、硬い物体で、聴診器は密着出来ない。考えれば馬鹿なことであった。秋山さんと大笑い。他に音を確かめられる道具はないか考えたり、聞いたりしたが、手近にそういう道具はなかった。

仕方がないので、あとは考えを，めぐらすしかない。
こんな風に考えていった。

（1）積算電力計は、電磁石部分：ローター：カウンターの3つの部分に分けられる。

（2）電磁石部分は交流の50サイクルの電流が流れる。交互に電流の方向が変わるので
　　　50サイクルの音を出す可能性がある。音は出さなくても50サイクルの振動は出ている。この振動があることは、触ってみることで全ての電磁石部分で確認できた。・・・・・・・・しかし、振動はあっても電磁石から音は出ていない。・・・・しかし音の原因はこの50サイクルの振動と関係がありそうだ。この振動と他の部分との関係に注意だ。

（3）カウンター部分は、これ自身が音を出すことは考えられない。しかし振動との関係で音が出る可能性はある。

（4）ローター部分は、アルミの回転盤の中心に軸が通っているだけの「コマ」のような形の単 純な形の部品である。いかにも50サイクルの電磁石の振動で音をを出しそうな感じである。

結局、カウンターとローターがどうなると音が出るかを確認すれば、どうすれば音はなくなるかがわかるはずだ。

そこで、この後どんな調査をして行くかを考えていたとき、フッと「共振」という言葉が頭に浮かんだ。これは学校で何かの講義で聞いた物だ。たった一回だけ聞いた話である。いや何の科目で何先生の講義であったかも思い出せない。

怪しいけれども、たしか物体には固有振動というものがあって、同じ固有振動とかその整数倍の固有振動をもつもの同士が近くにあると「共振」という現象で、振動の発生物体により、固有振動の相性のいい近くの物体に強い振動を発生させるというような講義であった。（まちがっていたら、教えてくれた先生御免なさい）

上の（1）～（4）までの考えは問題追及ということで、進めてきたのだが、この「共振」を思い出したため、その後の進め方と関係者への報告の筋書きがとても楽になってきた。

この後は、確か固有振動というのは、そのものの重量（学問的にいうと質量というのかな？？）と関係がある筈だったと思い実験を次のようにすすめた。

（1）サンプルとして、「唸りのある」積算電力計と「唸りのない」積算電力計を数十個準備した。

（2）これを電磁部分：ローター部分：カウンター部分の3ッつに分解した。

（3）これら全て個々の重量を測定した。

（4）測定データから各部分別に平均、標準偏差、などの値を算出、「唸りのある」積算電力計の分と「唸りのない」積算電力計の分と比較した。

（5）データの検討から、はっきり差が出たのはローター部分で、重量が多目のものが「唸る」ことが明らかになった。

以上で、ローター部分の共振で「唸り」が出ることがハッキリしたので、私と秋山さんの仕事は完了した。

その後は、更に多くのデータによりローターが共振する重量の範囲が把握され、ローターの設計がチェックされ、重量の許容誤差などが更新された。

さて、この件はこれで1件落着であるが、このとき感じたことは、あまり詳しくなくてもよいが、いろいろなことつまり雑学という範囲であろうが、知っていることは役に立つことがある、一生で一回しか使われない知識でも出来るだけ掴んで置こうということであった。

何事にも無関心でなく、好奇心を持って情報を捕まえておこう。これはコンピュータに蓄積するのでなくまだ沢山使われていない脳の部分があるとのことだから・・・・・

エンジニアリングとは何か

　　　　　　　　　第18話：エンジニアリングとは何か

　　　　　　　 ：システムエンジニアリングの名著に学ぶ


私は、工科系学校の精密機械科で学んだ。写真機だとか魚雷などの精密機械のエンジニアになるのが夢であった。

第２次大戦、学徒動員などで十分に学んだとはいえない。幸いなことに卒業後、コンサルタントということで、生産工場の現場で作業改善などのコンサルを行い、チョット向きは違うようだが、現場の技術者の仕事らしいこともしている。これぞエンジニアだ。と思って、夢に近いのだと満足して仕事に励んだ。

やがて、時間が過ぎオフィスの改善を対象にするコンサルタントになり、間もなくコンピュータのシステム設計関連のコンサル担当になった。今度はどうやらシステムエンジニアという技術者になったらしい。

ところでこの頃、世の中にはエンジニアとか「エンジニアリング」とか日本訳で「工学」という言葉が盛んに使われだした。

でも大変不勉強で恥ずかしいが実は工学という言葉の意味を私は良く知らなかったし、辞書で「エンジニアリング」で引くと「工学：工学技術」・・・・・・・・「工学」で引くと「工学的生産を合理的かつ経済的に行うための技術を体系的に研究する学問領域」なんて具合でスッキリ分かったという気にならなかった。

ところが、確か50歳くらいのとき書店で、ソーテック社刊：エドワード・V・クリック著：渡辺真一他訳の「エンジニアリング入門」という本を見つけて、やっと「工学」の意味とか内容がわかった。

この本は工学の内容を素直に説明、その進め方についても丁寧に説明がある。工学に関係する技術者はハードの技術者でもソフトの技術者でもぜひ一読をお勧めしたい名著である。・・・・前置きが長くなったが以下要点を紹介しておくこととする。

このようなテーマは他のコンサルタントのお話のように読みやすく纏めるのは困難である。しかし、読みたい人だけ読めばいいと割り切って薦めることにする。

一番のハイライトの文章はこうである。

***************************************************************************
エンジニアの主たる仕事は、何が望まれているかに関する漠然とした表明を、その望まれている目的が満足に果たせるような手段に関する詳しい明細書に変換することである。

明確にされた目的を達成する方法は、殆ど例外なく、数多く存在する。そして、殆どの場合、プロジェクトの開始時点で、エンジニアは、これらの方法について何も知らない。多くの可能性について、その覆いを取り去って探求していくことがエンジニアの義務となる　。
***************************************************************************

学生への講義で私はこんな風に説明した。（大筋はこの本に書いてあるものをやや分かりやすく話したもの）

例えば、ここに川がある。この川のＡ岸からＢ岸へ何かを運びたいという漠然とした要求がある。その具体的方法に関する設計書を作るのがエンジニアの仕事であり。その仕事がエンジニアリングだ。日本語ではこれを工学という。

さて、ここで具体的な設計に入ろうとすると、先ず漠然とした要求をもっと具体的な形に確定してゆくことをやらなければならない。

第一に、川の幅と深さ、川底の地盤と構造などを明らかにしなければならない。その他に「何か」を運びたいというがそれがどんなものか、例えば重量、個数、大きさ、柔らかさ、などなど、他にこの要求は今回だけなのか、それとも10年間続くものか？などである。エンジニアリングの仕事のスタートはこんなところから始まる。

これは簡単な問題であるが、実際の企業で直面する問題は何十倍も複雑である。例えば運ぶものといってもはっきり決められない場合が多いはずである。

それにハードなシステムならばまだいいが、情報システム等については、漠然たる要求をハッキリさせることが、人間の要素などが入ってくるので、もっと難しくなる。情報システムでは他の関連システムとの関係もあるし、情報システムの基礎のなっている。事業のシステムや業界のシステムも影響してくる。

こうなると、エンジニアりングの元になる要求の定義をすることが先ず第一に大切になり。ここで誤った定義をすれば、莫大な資金をかけたシステムが出来た途端に死んでしまうこともありうるし。仕方がないので非効率を知りながら使い続けなくてはならない破目に陥ってしまうことになる。

さて、問題の定義とか要件の定義がすめば、具体的な解決策の立案を行うわけであるが、この本ではこんなことが書いてある。

***************************************************************************
エンジニアが、教育や経験を通じて得た知識は重要である。しかし、知識は問題を解決する際の唯一の拠りどころではない。

というのは同時に自分に備わっている創意工夫の才能を使わねばならない。多くの解決策を考え出すために必要となる創造力と代替案の評価に使われる判断力とは、一般に考えられている以上にエンジニアリングの実務がアートであることを物語っている。
***************************************************************************

前掲の川の対岸に何かを運ぶ例でいえば、

「AからＢへ投げる」「持って泳いで渡る」「船で運ぶ」「橋を架けて渡る」「ヘリコプターで運ぶ」などが私たちの経験や知識として持っている解決策である。でも今までの知識の活用だけでは常識的な解決策で、確実ではあるが競争会社を引き離すような解決策にはならない。

例えば、向こうの岸から調達するのでなく、「こちら岸で作ってしまう作ってしまう」とか「すでに作られている公共の橋を使う」とか「競争相手がすでに作っている橋を使う」「運ぶ物の代替物を考えて」、運ぶこと自体が要らないようにする」などの思いがけない案を考えて、常識的なやりかたから飛躍することも必要である。

この場合には、すでに行った要件の定義自身を再検討しなければならない。この本の著者が「アート」であるといっているのはこの辺のことであろう。このように考えるとシステム設計の場合、要件定義とシステム設計者は同一人格であることが望ましい、もし出来なければ、要件定義者はシステム設計者に要件定義の内容やそのように決めた背景などを十分説明しなくてはならない。

情報システムの設計などでは、要件定義をユーザー部門が決め、システム設計をソフトウエアメーカーなどが行う場合が多く、そのために革新的な（例えば事業そのもののプロセスも変わるような）システムが出来にくい。

さて、「工学」という言葉、の定義や意味がわかったので、「エンジニアリング入門」で述べられていること、および「要件定義」と「システム設計」との統合とか連携についての問題についての私の考えなどについて述べたが、この項の話で「工学」と「エンジニアリング」をある程度理解していただければ幸いである。

13桁コードを誰が書くのか

　　　第１7話：簡単に見えた部品コードの切り替え（失敗は油断から来る）


コンサルティングのテーマは「販売店での新サービス部品コードへの切り替え」
このお話集はどうしても自慢話ばかりで申し訳ない。たまには本当の失敗話も書きましょう。お恥ずかしい話ですが、失敗はとても勉強になります。

これはある作業機械のメーカーで初期のコンピュータシステム(パンチカードシステムからコンピュータにようやく移行した頃)実施に関連したお話です。

コンサルティングのテーマは、サービス部品の在庫管理とそれに伴う補充発注のシステムを数年前にお手伝いした会社で、今回は前回のシステムの改善と併せて、サービス部品のシステムを各販売店からの受注システムまで展開する。というものである。

（と言っても当座は販売店が、当社の社内部品コードを新たに販売店の現行部品コードに切り替えるというもの。オンラインとかで結合するなどまだ当時は考えられない時代であった。）

会社の在庫管理とその補充システムが出来ているので、このコンサルの規模は小さなものであった。・・・・・・・こんな風に考えたところが私の油断であって、今まではそのシステムを運用するのが、その会社の社員だったのに今度のシステムの運用者は顔も見たこともない、日本中に広がる沢山の別企業で、しかも小企業である販売店、そこの事務職が相手のシステムであることの認識が甘かった。コンサルタントにあるまじき油断があった。

まあ、トラブルはあったが、システム自身は何とか運用され、苦情が殺到したが数年後には落ち着き、それなりの成果を生んだシステムであるから、許していただくとして、本題に入ることにする。

前回コンサルのシステム状況と残されたテーマ：当社サービス部品コードによる注文

前回お手伝いした在庫とその補充発注のシステムは、相当な成果を納め、３０人位居た部品部の要員はもはや１０人を切る。在庫金額減および要員減の効果を生み、私はクライアント会社から評価されていた。

ところで、前回のシステムでは折角コンピュータ化したシステムなのに、販売店からの注文書の部品番号を社内用の部品コードに人間が書き換えてから入力するようになってたのである。

こんな手のかかるシステムにしたのは、販売店で使い慣れたサービス部品番号を社内用に設定した、新しいコード切り替えると、トラブル発生は避けられない。従って、これは当分人間が書き換えをすることでトラブル発生を避けることにしたのである。

最初は社内システムとして成功して、危ないところは後で、と考えたわけで、当時のコンピュータシステム実施としては当然のやり方であったと思う。

今回は社内システムとして安定し、効果も得られたので予定通り、販売店から社内システムと同じ部品番号すなわちサービス部品番号を使って発注してもらうようにシステムを進歩させる。また将来販売店自身のコンピュータ導入も視野にいれたシステム設計を行うというわけである。（こんなことは２００６年現在では当たり前のことであるが・・・）

本項では販売店のコンピュータシステム設計の件は除外し、販売店から直接「社内システムと」同じサービス部品コードを使った注文という、狭い分野に焦点を合わせて話を進めることとする。

当社社員でない販売店事務担当による13桁コードの記入が問題

端的に言えば、販売店から新しいサービス部品コード（社内システムで使っているコードと同じもの）で注文してもらうやり方への変更。ということで、コンピュータシステムには全く関係ない人間のやり方の変更というわけ。（現在ならコンサルタントが入り込んでお手伝いするようなテーマではない。）

しかし、コンピュータが導入が初めてという会社が、各所に恐る恐る展開し始めた頃であるから、やはり専門家のお手伝いが必要だったのである。その他にもこの会社の社内システムのサービス部品コードの桁数が13桁という超長いコードだったという特殊事情もあった。

前回私がお手伝いして作ったシステムでは技術部門が普通に使っている部品番号をそのまま生かすやり方で、あらためて部品コードを作る必要がないように決めている。

13桁部品コードの説明
第1図を見ていただきたい。これはその時技術部門が作っていた品名リストである。表の中は最初の2桁は製品を表し、次の4桁はサブ機能を表す。などである。これは、技術部門が日常使っている部品番号表とか品名リストと呼んでいるものである。

前回のシステム設計時に技術部門はじめ各部門と打ち合わせて決めたもので、技術部門にも若干歩み寄ってもらったがこの会社の部品コードはイコール技術部門の部品表なのである。この部品表に管理上必要な材料区分と在庫区分を付け加えれば部品の管理のための部品コード表になる。

改めて部品コードを設定する必要のない仕組みとなる。
第２図の社内部品コード表が前回お手伝いした時に設定した物である。この表の各欄のアルハベットが桁数を表している。このままでコード表なのであるが、敢て他社がコード表と言っている物に合わせれば、部品コードは「「nnaabbbbbccdd」で、これだけ見ると一般的には確かに部品コード13桁である。

部品コードが13桁と言うのは以てのほか、という声もあったが、第1図と第2図を見ていただきたい。第1図でみれば分かるように13桁と言うのは品名を除くと、1番大きいのがサブ機能区分の5桁であとは殆ど2桁である。

なるほどひとつの部品を認識するには13桁必要だがコードの桁と言う考え方では1番大きいコードは5桁と言ってよいのである。だから社内システムの関係者は何の苦もなく新しい部品13桁の部品コードを受け入れたのである。

これは、特別な部品コードを作る必要のないシステムであり、私としてはいい仕事をした。と自負しているものである。






　　　
さて、ここまでは社内のシステムでの品名コードの説明で前回のシステム作りとコードについて述べた。ここまでは例によって自慢話になってしまって御免なさい。

販売店での13桁コード記入の迷いと油断


ここからが今回のお手伝いのミスで、大騒ぎなるわけなんです。私も、会社の関係者も油断してしまって、これから話す大きな問題を起こすことになったのだ。

いよいよ今回のテーマに入ります。すでに述べたように、今回のテーマは、全国に展開している販売店から来るサービス部品の注文書の品名コード欄に社内の部品コードを直接書いてもらうようにすることである。

いづれ販売店にもコンピュータが導入された時端末から直接本社のサービス部品システムに直結する時のために・・・・ということも視野に入れた将来のための布石でもあった。

この時点では、販売店では、従来から使っていた品名リストがあり、このリストにある部品番号で注文をしていた。その時の部品番号は7桁で社内のコードとは全く別に作られ、ズット前からこのやり方でやってきたのである。

というわけで、今回のコンサルは、もっぱら「新しいサービス部品のコード設計」と、「販売店用サービス部品表」を作成し、配布し、この部品表によって注文書を作ってもらうことである。

問題は、13桁もあるコードで、社内では何の問題もなかったが、販売店ではトラブル必至ということであった。最初は、販売店用の品名リストと会社の品名コードの対応表をコンピュータに持たせ、変換させようとの案が最有力であった。これは当然のことであった。

しかし、これではハードもソフトも準備が必要で、あるし、もともとこの時期にはコンピュータにそれだけのことをさせるには能力不足でもあった。またこれをやれるような販売店でなければ将来のパートナーとして組んでゆけない。などの事務システム以外のあるべき論も出てきて結局、多少トラブルは起きても、販売店にも苦労してもらうべきだ。との声にまとまってきた。

理屈はそうだが、システム部門も私も実践出来て、ミスの少ない方法を考えなければならない。私は社内で13桁を問題なくこなしたのだから同じようにすれば、結局長いコードと言っても5止まりとの考え方で通せると思っていたが、販売店の事務担当では、
最初の2桁は製品を、次の4桁はサブ機能を、次の2桁は材料を、あと2桁は在庫管理区分を表す。合計13桁だけれど分けて考えると長いことはない。

という説明で説得しても無理かな。というためらいがモヤモヤしていた。何しろ製品名と部品名だけしか関心がないだろうと思われる販売店の事務職である。まして99％が女性事務担当で平均在職期間は当時約3年と言われていた頃である。

この状態で、盛んに討議を行った。販売店の事務体制が対応できるかどうかなどの調査も行った。しかしなかなか結論は出ない。要するに13桁コードでは販売店の事務職ではミスが頻発する可能性ある。とのことであった。

販売店に配布する部品表と注文を書く注文書について、会社の皆さんが考えていたのは、よその会社でやっているように品名と13桁のコードの部品表を配布してそれを使わせる案であった。

しかし、私としては今7桁のコードでやっているのだから、いきなり13桁ではやはり問題だ。社内と同じ区分別コードの集合体としての部品コード表。すなわち第2図の形態をそのまま使うことにしたいと考えていた（多欄式）。

そうすればよかったのだが、今回の販売店用の部品コード表は、第３図のように部品名のあとに第２図各欄の記号を纏めて１３桁をコードとして使おうと言うものであった。何故この形式にこだわったかと言うと、今までの部品表がこの形式だったと言うことに過ぎない。

第２図のようにすると却って抵抗感がある。と言うのが論拠であった。この辺をよく考えて駄目を出すのがコンサルタントの任務なのだが、たしかに女子事務員に第２図のようなコード表を見させるのが良いのかどうかについて迷ってしまっていたのだ。

会社の皆さんの中には途中に線があるかどうかだけの違いだ。日本の教育水準は高いのだから13桁コードも出来るはず。という意見も多かった。私も迷っていた。では13桁の途中に幾つかの区切りを作る（区分式部品表：電話番号のように3桁とか4桁で区切る）。という提案もした。


これらの案色々を抱きかかえて、もう一歩が踏み切れずにいた。
迷って迷って最後は自動車業界のサービス部品コード参考で決心

迷って迷って・・・・・・結局決め手になったのは、自動車会社のサービス部品の管理について調べた結果であった。自動車会社のシステムは勿論先進的であり。サービス部品のコードは、13桁どころか15桁のものさえあった。

私もこれを見て「そうか自動車のサービス部品でやっているならこれで行けるかと13桁そのままのコードでやる決心した。」これならばたとえトラブルが起きても、自動車業界でやっているのだから出来ないとはいえないわけである。

そこで自動車のサービス部品の部品表を武器に関係幹部とシステム部門の幹部を口説き、将来のことを考えて、多少のトラブルはあっても13桁の社内のコードをそのまま使わせましょう。ということでＯＫをもらった。

やがて、会社の方針は多少のトラブル覚悟で販売店への13桁コード実施がスタートした。

さて、新しい部品表を作成して全販売店に配布して、いよいよ販売店からの新サービス部品コードにより。販売店から新コードによる発注がスタートした。


記入ミスは惨憺たる結果：兎に角一生懸命指導に努力。弱みをみせるな頑張ろうね。

果たしてその結果はどうだったかと言うと、実に惨憺たるものであった。
新コードスタート第1日は、コード記入ミスの大発生。コード書き換えの態勢のままの人員ががそのまま居たので、残業徹夜態勢でようやくこなしたものの、これでは駄目、少なくとも数日中に半減以下にしなくては、コンサルとしての私も、責任者のシステム部長も首が飛ぶ。

その夜のうちにシステム部長と相談して、集められるだけの機動部隊を編成し、翌日からミスの多い販売店に出張指導に向かわせた。全く新しいコード表に変わったのだから、ミス発生は数日間は大目に見てもらえる。と踏んだが、その数日間はシステム部長も私も「薄氷を踏む思いであった」


数日間が過ぎた。幸いミス記入の発生者は氏名がはきり分かるので、狙い撃ちの訪問指導や電話による指導の効果があがりやすかった。まだまだ満足できる程ではなかったが、ミス発生の件数とそ減少傾向を示すグラフでトップ層の心配を抑えることが出来た。

この間、しまったやっぱり多欄式コード表か区分式コード表にすべきだったと後悔の臍を噛みながらも、これはもう言えないことと胸にしまい込んで、「兎に角自動車業界でやっているのだから必ず出来ることですよ大丈夫、もうしばらくの我慢」と周りの皆さんには、説明していた。

システム部長とその周りの人にもそう言って励ましていた。検討段階で、販売店でそんな面倒なこと、13桁のコード記入など無理と叫んでいた人たちも居たので、その人たちに弱みを見せたら駄目ですよ。ゴチャゴチャになりかねませんからね。と注意もしておいた。

我慢だ：3年間たてば13桁コードに違和感はなくなる。

私は心の中では、これは数ヶ月続く、場合によっては3年続くかな。兎に角粘り強くミス記入との戦いだな。と思った。

その理由は2っつあった。その1は販売店に渡したコード表が小さすぎたことである。これは私も原稿時点でチェックさせてもらったのだが、そのあとで印刷発注を担当したものが、費用があまり高いので一回り小さくして200万円ばかり浮かせたとのことで、とても見にくくなってしまったのである。

コードが13桁もあるとき、小さくしたために、コードの頭から読み出して終わりに行くまでにとなりのコードに脱線してしまうことが多いのである。

このコード表は多分3年後くらいまで印刷できないので、この原因から発生するミスは避けられない。なお、今回の13桁コードは13桁がベタベタにくッついて印刷されているので、これは読み違いが起き易い。次回印刷でこれらの点を修正すればコード表自体から発生するミスは
相当減るはずである。

3年間我慢すれば格段に改善されると思った理由は、何人かの営業店の事務担当と話して考えたことである、この人たちは今まで慣れ親しんできた7桁のサービス部品番号に替わって登場する13桁コードにしばらくは敵意を持つ、たとえば「こんな長いコードにしゃがって間違っても私のせいではないね。・・・・心の底にこんな思いがあればあやはりミスは発生しやすいのである。

もう一つの理由があった。それはこの頃は、女子事務担当は、平均3年で退職し、新人に替わってゆくのである。全くの新人はまえの7桁コードのことは知らない、始めから13桁コードを使うものだとなれば、古くからの事務員と違ってこの13桁コードに違和感はないのである。


反省したこと：いろいろ
コンピュータ化の進展は予想をはるかに越え、この時点では販売店とのネットワークなどそんなに早く出来ないと思っていたが、意外に早く、販売店での13桁コード化は役に立った。

しかし、このコンサルは、コンピュータの利用ということが誰もそして私も全くの初めてと言うことで、私としては大いに迷ってしまった。だけれどこのときの問題は、コンピュータへの未知という要素より、販売店の事務員の能力と士気が一番の問題であったのに、この点に食いついていない。結果からみればコンサルの結果は悪くはなかったと思っているが、調査方法においてはすでに述べたようにポイントが外れていた。

また、。自分でいいと思いながら、多欄式部品コード表や4～5桁くらいで区切る区分部品コード表をシッカリ検討して、このどちらかを推進すべきだった。結局ただ13桁を並べただけのコード表で実施されたが、人間工学的にはあまりよい方法ではない。べた書きの13桁を間違えずに読んだり書いたりするのは非常に間違いやすいのである。この点でも反省している。

コード設計についてはいずれこの第○○話で書こうと思っている。