タイム・コンサルタントの日誌から

マネジメント・テクノロジーの技術地図を見渡す

前回の記事では、技術（Technology）とは2種類あり、固有技術と管理技術に分類できる、と書いた。わたし達が大学の工学部などで習う技術のほとんどは、固有技術である。これは対象分野に固有の科学法則に基づくテクノロジーだ。これに対し、管理技術（Management Technology）とは、仕事の仕組みそれ自体に関する技術で、たとえば、プロジェクト・マネジメントの分野では、CPM（Critical Path Method）やEVMS（Earned Value Management System）などがこれに相当する。

わたしは大学でプロジェクト・マネジメントを教える際に、いつも「この講義で教える内容は、ほぼすべて社会人になってから学んだことで、わたし自身は大学ではほとんど教わった記憶がありません。だけれど、それでは非効率なので、こうやって大学に来て皆さんに講義をしているのです」と説明している。

実際のところをいうと、大学の学部生レベルでは、プロジェクト・マネジメントの講義をしても、あまり響かない。人と一緒に仕事をして苦労した経験が乏しいからだ。これが大学院の修士課程くらいになると、一度は「卒論」というチャレンジを経験した後なので、少しは話を聞く態度に身が入る。そしてもちろん、一番皆がちゃんと学ぶ姿勢になるのは、社会人大学院生や、企業相手の講義のときだ。

まあ、だからといって大学での講義が全くムダだとは、思っていない。アーンド・バリューだのクリティカル・パスといった概念の意味は忘れても、いざ自分が卒業して、仕事で問題に直面したときに、「そういえば、昔なんだかこれに関連する話を聞いたよな」と思い出せれば、あとは自分で探して調べることができる。

自分が本当にニーズを感じているときほど、良い学びの機会はない。このとき、頭の中に、たとえぼんやりとでも「技術の地図」のイメージが残っていれば、（ああ、あっちの方に探しに行けばいいんだな）と、希望を持つことができる。技術者という人種は、「技術的に可能だ」という希望を持てることが、いちばん大切だからだ。そして優秀な人なら、自分で調べて勉強していく。

しかし、わたし達の社会では、管理技術をほとんど大学で教えないため、そうした技術の地図を知らないまま、世の中に出てしまう。つまり、そもそも「仕事の仕組み」には技術があること、人・モノ・情報などの配置と流し方に、ちゃんと先人たちの叡智と工夫があることを、知らないのだ。その結果、各人がゼロから車輪を再発明することになる。いや、それどころか、「リーダーシップ」「気合と根性」でなんとか乗り切れ、という話がまかり通る。

これに関して、わたしがよく使うたとえは、オーケストラの指揮者である。指揮者という仕事は、ちょっと見たところ、リズムに合わせて棒を振っているだけで、誰でも（楽譜さえ読めれば）できそうに思える。自分では笛を吹くわけでもなければ弦をこするわけでもなく、何の音も出さない。そもそも、管楽器や弦楽器の演奏技術も持っているまい。ただ、オケに指揮棒で指示を出すだけである。

では、指揮にはとくに技術はないのか。指揮者は、どのように育成するのか？

日本の組織では、幹部やリーダーの地位に登っていく人を、「ジェネラリスト」として育てるところが多い。その典型は官庁で、「キャリア職種」と呼ばれるエリート候補生たちは、２〜３年ごとに部署を変わっていく。しかも前職とろくに引き継ぎもしないことが多いので、役人と付き合う民間人たちは、相手が変わるたびに一から説明し直しになる、という。

技術者の場合、専門的な仕事を覚えて一人前のプロとして通用するには、ふつう10年くらいかかる。それがスペシャリストというものだし、医師や弁護士だってそうだ。それなのにキャリアと呼ばれる人たちは、わずか２〜３年の間で、その領域の仕事を概略理解し、何らかの成果を上げて次のポジションに進んでいく。だから、こうした制度は、彼らエリート層の優秀さの証左なのだ、という説明も聞いたことがある。優秀かどうかはともかく、スペシャリストを束ねて指揮するのは、ジェネラリストだ、という思想がそこにある。

こういう話を聞くたびに、じゃあ日本社会では、オーケストラの指揮者もジェネラリストとして育てることになりそうだな、と思う。指揮者のキャリアパスは、まずビオラで3年、次にフルートで2年、さらに打楽器とトランペットなどを経験し、最後に第一ヴァイオリンでコンサートマスターを5年ほど務めた後、めでたく指揮者の地位になる、と。

こんなバカなやり方で指揮者を育てる音楽界は、世界中どこにもない。指揮者は、専門家であり、指揮は専門技術だ。音大には指揮科があり、そこで指揮の理論や技術を学ぶ。それから指揮者の見習いとして、先輩について指揮法の実際的なスキルを学んでいく。たしかに、ときにはピアニスト出身の指揮者やヴァイオリニスト出身の指揮者もいる。だが、彼らだって、ちゃんと指揮法を学んで棒を振っているのだ。ただやみくもに棒を振ればついてくるほど、オーケストラという集団は甘くない。

人が集団で仕事をするとき、とくにその専門分野が多岐にわたり、規模が大きくなればなるほど、専門的なマネジメントの技術が必要になる。そして、そこには理論もあるし、学ぶことも、伝えることも可能だ。

では、そうしたマネジメント・テクノロジーを学ぶとしたら、それはどのような範囲をカバーすべきか。いいかえると、「技術の地図」は全体として、どのようになっているのか。

もちろん、それはかなり広い領域にまたがることになる。プロジェクト・マネジメント（PM）はその一部分にすぎないが、それだけでもPMBOK GuideやP2Mなど、分厚い教科書的な本がいくつも存在する。

そこで、ここでは一般的な製造業における物づくり分野について、その全貌を考えよう。また、マネジメント・テクノロジーを考える際には、隣接する固有技術との関係で理解したほうが分かりやすい。わたしの考える、物づくりに関わるマネジメント・テクノロジーの領域と、隣接する固有技術との関係マップを示しておく。

隣接する3つの固有技術とは、以下の3つだ：

IT（Information Technology）

OT（Operational Technology）

ET（Engineering Technology）

それぞれが具体的に、どのような種類の技術領域を表すかについては、長くなりそうなので、次回書くことにしよう。

（この項続く）

＜関連エントリ＞

　→「マネジメント・テクノロジーの領域を知ろう」（2019-10-05） https://brevis.exblog.jp/28610522/

　→「オーケストラの指揮者かジャズ・バンドのリーダーか　－　プロジェクト・マネジメントの４つの類型を知る」（2014-02-02） https://brevis.exblog.jp/21641066/

マネジメント・テクノロジーの領域を知ろう

本サイトの主要なテーマは、（知らなかった人もいるかもしれないが）『マネジメント・テクノロジー』である。マネジメントと言う仕事には技術があって、学ぶこともできるし、蓄積したり磨いたり、人に伝えることもできる。決して気合とか根性とか、生まれつきのセンスとかだけで能力の決まる仕事ではない。そういうことを多くの人と共有したくて、ずっとこのサイトを運営してきた。

そもそもTechnology（技術）には2種類ある。固有技術と管理技術（マネジメント・テクノロジー）だ。固有技術とは、対象固有の科学法則に縛られる領域におけるTechnologyである。たとえば、機械設計、材料開発、システム設計、といった技術がそれに当たる。ちなみに、わたし自身の大学の専門は化学工学（Chemical Engineering）だった。これは化学プラントの設計に関わる工学だが、やはり固有技術である。

これに対して、管理技術とは、仕事の仕組みそれ自体に対して適用すべきTechnologyをいう。「仕事の仕組み」では分かりにくければ、人・モノ・情報などの配置と流し方、と言い換えても良い。たとえば、プロジェクト・マネジメントの分野では、CPM（Critical Path Method）やWBS（Work Breakdown Structure）、生産マネジメントの分野なら、在庫理論とか生産スケジューリングといった技術だ。

こうした管理技術（Management Technology）には業種・分野固有の部分がない。製品開発プロジェクトだろうが橋梁建設プロジェクトだろうが、CPMは当てはまるし、在庫品がダイヤモンドでもトイレットペーパーでも、在庫理論は使える。このため、マネジメント・テクノロジーは業種分野を超えて、汎用的である。だから、まったく畑違いの分野の知恵も、学んでうまく応用すれば、自分の仕事を楽にするために使える。

ところが残念なことに、日本の大学教育では、この『管理技術』の教育・研究を、伝統的に軽視してきた。その1番の証拠は、東大と京大に、学部レベルで経営工学や管理工学の学科が存在しないことである。この2つの大学は、日本の文科省の高等教育政策を映し出す鏡のようなものだ。つまり国の側にも、管理技術という意識が欠けているのだ。

ちなみにかなり以前から、慶応には管理工学科が、早稲田には経営システム工学科があり、東工大にも経営工学科があった。だが、肝心の東大と京大には、ずっと存在しなかった。さすがに、今世紀に入ってからようやく、大学院レベルで、東大に技術経営戦略学専攻が、京大に経営管理専攻が設置された。

だが学部レベルでは、相変わらず存在しない。だからこの二つのエリート大学を卒業してくる人たちは、基本的に、「仕事の仕組みにはテクノロジーがある」ということを理解せぬまま、社会に出て働くわけだ。

なぜ、国の側に管理技術＝「マネジメント・テクノロジー」への認識が欠けているのか、わたし自身はよく知らない。ただ、もしかすると、わたし達の国の上の方の人たちは、「管理とは法学部出身者の仕事である」、と考えているのかもしれない。そう疑わせる兆候は多分にある。そうでなければ、なぜこの2つの大学の法学部出の人たちばかりが、中央官庁や政界財界のトップの座をあれほど席巻しているのか。

だが、話を元に戻そう。わたし達の社会では、残念ながら、「マネジメントにも技術がある」という概念が希薄である。だから、マネジメントの上手下手は、まったく属人的なものだ、という思想が強い。その結果、マネージャーの地位は、学歴・年功序列・出身等により選ばれることが多い。マネジメントは「地位に付随する権力・権能」 であって、前もって研修・訓練が必要な技術とは考えられていないのである。

なおここでもう一つ注意しておきたいことがある。それは、『経営』という言葉とマネジメントとの違いだ。本サイトは、「ビジネス・経営」のカテゴリーに分類されている。他に適切なカテゴリーがないから、そうしているだけだが、あまり本意では無い。なぜなら、このサイトでは、ほとんど経営について語ったことがないからだ。わたし自身、経営者ではないし、経営の仕事もしたことがない。

普通、日本語で経営と言うと、会社レベルの組織をまとめて運営する仕事を指す。しかし、私がここでマネジメント・テクノロジーと呼ぶ技術は、もう少し中間層のレベル、言い換えると経営者層と現場をつなぐレベルの技術である。クリティカルパス法だとか、在庫理論だとかいった技術知識は、会社経営のレベルではあまり必要がない（無論、知っているに越した事はないが）。

少し具体的な例で考えてみよう。今、ある所にカレー屋さんが開業した。ご主人はもともとエンジニアだったが、長引く不況と、先の見えない業界にうんざりして、心機一転、脱サラを決意したのだ。昔からカレーが得意料理で、親戚知人に披露すると結構評判が良かったので、自分で店を開こうと思いたったわけだ。

愛想の良い奥さんと二人三脚で、幸い、店は順調に滑り出した。ご主人が料理を作り、奥さんが客の応対をする。1年経つと、ピーク時には店の前に行列が並ぶほどになった。今のスペースは手狭なので、近くに3倍位の広さを持つ店舗の空き家を見つけ、そこに移転することにした。そうなると夫婦2人では手が足りない。厨房とフロアの手伝いに、2人ずつ人を入れた。

ご主人はこれに加えて、持ち帰りのカレー弁当も売ることにした。長年のオフィス勤めで、昼食に皆が苦労していることを知っているからだ。オフィス街に小さな机を並べ、昼の間だけそこでお弁当を見ることにした。当然そこにも人が必要だ。

だが、こうして店の業容を広げていくうちに、少しずつ問題が起きてきた。例えば、お弁当の仕込みの数をどう決めるべきか。作り過ぎれば売れ残るし、数を絞れば利益が出ない。それに、仕込んだカレーだって、賞味期限がある。3日も4日も前に煮込んだカレーをお客様に出すわけにはいかない。

店を広げた際に、カレーのメニューの種類を増やしたことも問題だった。厨房の中で、洗い場と、調理台と、冷蔵庫との導線が錯綜して、3人の人がぶつかりやすくなった。しかもメニューの数を増やしたために、フロアからの注文の聞き取りミスも増えてしまった。注文してから料理を出すまでの時間が長くなったとなじみの客にクレームされたこともある。

おまけに甚だ厄介な、今回の消費税対応。朝から晩まで寝る間も惜しんで忙しく働いているのに、利益は上がらない上に、客足も少しずつ鈍ってきている。カレーの味自体は変わっていない。むしろ腕は上がっている自信がある。だが商売の利益につながらないのだ。ご主人は深夜、自分の席で、ため息をつくことが多くなった。

これが典型的な「仕事の仕組み」の問題だ。今のご主人に必要なのは、カレー作りの品質向上ではない（それは固有技術に属する）。大事なのは、人と物と情報の配置・流し方の工夫である。つまりマネジメント・テクノロジーが足りないのだ。

夫婦2人で小さな店をやっているときには、それはほとんど必要なかった。だが品種を増やし、人を増やし、売り上げと生産量を増やしたときに、次第に目に見えない非効率が生まれてきたのだ。適切な厨房のレイアウト、適切な在庫量の設定と発注、需要の読みと臨機応変な対応、店舗から弁当売り場への搬送、注文と会計のシステムの導入・・こうしたことが必要になるのだ。だがそれを実現するテクノロジーを、どこで学べばいいのか?

これと同様の問題が、おそらく最初は東京オリンピックの翌年の「昭和40年不況」のときに、多くの中堅中小企業で噴出した。そして、より大規模な形では、高度成長期を終えて、消費者ニーズの多様化と輸出拡大に直面した80年代以降に、日本企業を襲ったのだった。

ただ残念ながら、マネジメント・テクノロジーは、目に見えない領域に属している。そして、目に見える物の品質やディテールには大変こだわるが、目に見えない事には至って無頓着な傾向を、わたし達の文化は持っている。加えて、国家レベルでの認識不足。こうして、バブル崩壊以降の90年代から、長らく不況を出せずにきたのだ。

わたしのこの、ささやかなサイトが、国家レベルの問題を解決できると夢想しているわけではない。ただ、たまたまここを訪れた方のうち、たとえわずか数人でも、問題解決のヒントを提供できればいいと思っている。ネットの世界では、マネジメント・テクノロジーの情報源は、あまりに少ない。話題のほとんどは、固有技術か、さもなくば経営論に行ってしまう。それでは、問題に悩むカレー屋の店主の助けにはならないのだ。

それと同時に、わたし達は、マネジメント・テクノロジーについて、フェース・ツー・フェースで情報交換し、議論する場を必要としているように思う。ネットでの匿名による意見交換は、限界がある。工場作りに関しては、互いに勉強でき議論できる場を、（財）エンジニアリング協会で、立ち上げているところだ。そちらもいずれ近いうちに、より広くアナウンスできるようにしたいと考えている。そうやって、かつての東京オリンピック後と同じ状況に、日本の製造業が今度は陥らないよう、今から準備しようと思っているのである。

＜関連エントリ＞

　→「マネジメントのテクニックと技術論について」 https://brevis.exblog.jp/22951856/ （2015-04-22）

エンジニアにとって全体最適とは何か？

中学校の修学旅行は、京都・奈良だった。清水寺では、その舞台の高さに驚き、「清水の舞台から飛び降りる」の意味を改めて知った。ところで清水寺の参道には、旅人が喉をうるおす3つの湧水の滝口があった。引率のガイドさんによると、3種類の水はそれぞれ、飲むと「恋愛」「長寿」「賢さ」の願いを成就できるのだと言う。わたし達は喜んで、3つの口からそれぞれ水を飲んで、参道を登った。

ところが帰り道、ガイドさんが思いもかけぬことを言い始めた。「あら私、大切なこと言い忘れたかしら。お水を飲むなら2種類までなの。欲張って3種類を全部飲むと、効き目がなくなっちゃうのよ。」 これを聞いた私たちは、そんな大切なことなら、なぜはじめに言ってくれなかったんだ、と、いたく憤慨した。

もっともそれを聞いて、中学生のわたしは思った。恋愛と長寿と賢さと、どれが2つを選ぶとしたら、どれになるだろうか？　難しい問いだ。それはある意味で、どれか一つを犠牲にしなくてはならないことを、意味している。頭が良くて女の子にモテても、短命ではなんにもならない。かといって健康でハンサムでも、頭が悪くては人生台無しだ。じゃぁ頭が良くて健康でも、異性が誰も寄り付かない人生に、どんな意味があるだろう？

このエピソードを久しぶりに思い出したのは、最近ある方から、アメリカにおけるオペレーションズ・マネジメント（OM）や生産管理の教育の充実ぶりについて、聞いたときだった。日本では、生産管理を専門的に勉強する大学院レベルのコースはほとんどないし、実務家のための勉強の機会も限られている。しかし米国では、ジョージア工科大学を始め、この種の研究と教育のメッカと言うべき大学が複数存在するし、米国生産在庫管理協会（APICS）という、実務家のための大きな組織もある。アメリカの製造業はもう廃れた、と思い込んでいる人が多いが、こうした科目を学ぶならば、日本よりもアメリカの方がずっと進んでいるのだ。

その人は、アメリカでの生産管理教育のメッセージをわかりやすく伝える、1枚のチラシを見たと言う。それは宅配ピザのチラシを、模している。

「あなたのお好みのピザを届けます。

　ただし、以下の3つのオプションから、2つまでを選びください」

　そしてチェックボックス付きで、Q:品質、C:コスト、D:納期、の3つのオプションが並んでいる。

安いピザを早く持ってきてもらいたかったら、品質（おいしさ）は多少犠牲になる。おいしいピザを早く持ってきてもらいたかったら、それなりの値段を払わなければならない。そして、おいしいピザを安く届けてもらいたかったら、（そのためには同じ種類のピザをある程度のロット数量まとめて焼く必要があるのだから）納期が遅くなるのは、覚悟しなければならない。

製造業においては、顧客好みにカスタマイズされた商品を、QCD全て満たした形で生産するのは、ほぼ不可能である。なぜならばこの3つの尺度の間には、あちらを立てればこちらが立たず、1つを完璧にしようとすると、他の2つのいずれかが犠牲になる、『トレードオフ』の関係が成り立つからだ。それは、生産システムというものが持つ、基本的な性質である。このチラシは、それをごくわかりやすい簡潔な形で、教えている。

いったい全体最適とは、何だろうか？　品質・コスト・納期の、3つの尺度を全て最大化することだとしたら、それは本当に可能なのだろうか？　全体最適と言う言葉は、しばしば縦割り組織で、いろいろな行動がサイロ化されているとき、「それは局所最適だ」という批判とともに、用いられる。つまり局所最適の反対概念として、『全体最適』と言う言葉が使われる。

しかし、少しでも最適化理論やオペレーションズ・リサーチ（OR）をかじったことがある人は、最適と言う言葉を、もう少し正確に、ないし慎重に使う。それは何らかの評価関数（尺度）を、最大化することを意味する。では製造業における評価関数とは、何なのだろうか。評価尺度が複数あるときは、どうしたら「全体最適」が達成できるのだろうか？

別の言い方をしてみよう。今、工場で生産に問題が生じているとする。そこで工場長は、品質の徹底的に向上するため品質管理マネージャーを任命し、コスト削減のためにコスト管理マネージャーを任命。さらに納期短縮のために、スケジュール管理マネージャーを置いた。この3人が、それぞれ自分の持ち場で最大限努力すれば、QCDの全てが最大化されるだろうか？　この3人はそれぞれ、他の2人と相談せずに、独立に活躍できるのだろうか。

これは制度設計の問いである。つまり一種のデザイン問題なのだ。そこでエンジニアにわかりやすいように、製品設計の例に置き換えて考えてみよう。

あなたの会社は今、これから新しい電気自動車を開発しようとしている。あなたはそのプロジェクトの、主任技師に選ばれた。あなたに与えられたミッションは、「世界最高の電気自動車を設計すること」である。

世界最高の電気自動車とは、どういう意味か。それは、どんな尺度を持ってきても、他のライバルに勝っていると言うことである。では、電気自動車を評価する性能尺度には、一体どのようなものがあるか。

自動車はまず第一に、移動手段だ。A地点からB地点に、乗っている人が移動することができる。これが一番主要な機能である。見るからに精悍でかっこいいが、1kmも走れない電気自動車に、金を出す人はいるまい。である以上、最大航続距離が、第一の性能尺度になりそうだ。

それと並んで、最高速度も大事な性能だ。最高時速20キロで、高速道路にも乗れないような自動車では、役に立つまい。

加速性能は？　それも大事な尺度だ。では、回転性能についてはどうか。思う方向に向かってキビキビと進路を変えられることも、車にとって大事な性能だ。加速と逆に、減速も重要である。回生制動であれメカニカル・ブレーキであれ、必要な時にきちんと止まれることも、とても大切だ。そして移動手段である以上、かりにセダンのタイプとしても、可載重量も使い手は気になるだろう。

それだけで良いだろうか？　いや、車の走行には、安定性や安全性も求められる。例えば高速走行時の安定性。路面のゴツゴツした凹凸に、いちいち進路がぶれるのではたまったものではない。そして衝突時の安全性。これも非常に大切だ。そして、製品の寿命が長く、壊れにくいことも、ユーザの視点からは、大きなポイントになる。それに隣接して、自動車の場合、スペース的な余裕、つまり居住性も考慮がいる。

こうしてみると、移動という基本的な機能の性能のほかに、まだ様々な評価尺度があることがわかる。ITエンジニアだったら、航続距離や最高速度を「機能要求」と呼び、回転性能や高速安定性や衝突安全性等は、「非機能要求」と呼びたくなるかもしれない。

それで、これだけで十分だろうか？　いや、まだ大切なことを忘れていた。それは効率性である。「コスト・パフォーマンス」と言い換えてもいいかもしれない。例えば、移動性能に対しては、どれだけ燃費がかかるかが、効率性の尺度になる。これも自動車を選ぶ際には、とても重要な物差しであろう。

また製品の寿命に対しては、保守維持費の安さも大事だ。そして何よりも、製造コスト。販売価格は、製造コストに依存する。自動車全体のコスト・パフォーマンスとは、何よりその販売価格で測られるものだ。

さて、あなたの手元には、すでに1ダースもの評価尺度が集まった。図を見てほしい。ここでは、12個の評価尺度を、あえて抽象化した表現で表してある。これらすべてを、どんなライバルも追いつけないほど、最大化（ものによっては最小化）することが、主任技術者たるあなたに与えられた使命＝ミッションである。

このミッションは、本当に実現可能なのだろうか。CAD画面に向かって設計図を描き始める前に、あなたは落ち着いて考えてみるべきだろう。

さて、先ほどの図をじっくり眺めていくうちに、あなたは、これらの尺度が大きく、4つに分類できるのではないかと気がついた。

まず、図の上辺にある、主性能Effectiveness (最高速度)と、使用価値Usefulness(航続距離)。これらはシステムとしての電気自動車の有用性に関わっている。つまり、ユーザの主たる期待への合致である。

円の左側に位置する、俊敏性Agility(加速性能)、柔軟性Flexibility(回転半径)、許容性Capacity(可載重量)などは、広い意味での御しやすさ＝制御性 Controlabilityに属している。逆に右側にある、安定性Stability(高速安定)、頑健性Robustness(衝突剛性)、居住性Comfortability(スペース余裕)、耐久性Durability(機械寿命)などは、広い意味での持続性 Sustainabilityの範疇と考えられる。

最後に、円の下部に位置する、製造コストInitial cost、保守コストMaintenance costは燃費と共に、コスト・パフォーマンスの分母側＝負荷尺度に相当する。分子に相当するのが他の3カテゴリー、つまり有用性・制御性・持続性である。だから分母を小さく、3つの分子を大きくしていけば良い。

だが、個別に考え始めてみると、あなたは次第に思考のループにとらわれているような気がしてきた。例えば頑健性を高めるために、剛性の高い車体を使うとする。すると車の重量が重くなって、俊敏性や最高速度が損なわれる。重くしないためには、軽くて強い特殊素材が必要だ。そうすると製造コストが高くなってしまう。

回転性能を高めることと、高速安定性を両立させることも、決して容易ではない。安定性を素材の重量や形状など、メカニカルな方法で確保しにくい場合、何らかの制御システムで担保するしかない。かつ、安全性を考えると、制御システムは冗長化・多重化が必要だ。そうなると仕組みが複雑になって、保守コストが上がるだろう。

こうして、あちらを立てるとこちらが立たず、トレードオフの網の目にトラップされたような気になってくる。

それも当然なのだ。よく考えてみて欲しい。制御しやすさ＝「制御性」とは、一体何か。それは、使い手の意図した変化への追随性である。他方、持続性とは何か。それは使い手の意図せざる変化への耐性である。片方は変化に追随し、片方は変化にあらがう。その境目は、ユーザの意図にある。だが、電気自動車と言う機械システムの側から見て、どれがユーザの意図で、どれが意図せざるものなのか、判別できるだろうか？

ハンドルやアクセルやブレーキ、フロントパネルなど、ユーザインターフェースからの入力が、意図した変化であって、それ以外の外界からの入力が、意図せざる入力である。そう考える方法もあるかもしれない。

だがユーザは人間なのだ。そして人間だから、思わぬ行動をとることがあり、間違えることさえある。くしゃみをして握ったハンドルがブレたら、それは意図した入力なのだろうか。車庫入れでブレーキを踏むべき時にアクセルを踏んだら、それは意図した行動なのか。

電気自動車は、機械・電気・制御が統合されたメカニカルなシステムである。だが、それを設計するときには、電気自動車＋ユーザ（人間）という、複雑な系を対象として考えなければいけない。

法政大学の西岡教授は以前、機械学会の報告の中で、「自動車や携帯電話など、人がその外側にいるシステムを第一種のシステムと呼び、人がシステムの内部にいて、その構成要素となっているものを第二種のシステムと呼ぶことにしましょう。」と提案された。これはとても良い分類だと思う。

しかし、わたし達が何らかの道具を設計する場合、必ず、その道具と、使う人間との組み合わせを考慮する必要がある。つまり設計においては、常に第二種のシステムが相手となるのだ。

そして第二種のシステムでは、意図した変化への追随性と、意図せざる変化への耐性は、常にトレードオフの関係になる。言い換えるならば、すべての評価尺度を同時に最適化することができないのである。

もちろん実際には、相反する2つを両立する工夫も、しばしば可能である。例えば車のハンドルのブレを例にとると、周知の通り、ハンドルにはわずかな遊びがある。これによって、手元が多少増えても、車の方向が急に大きく変化したりしないようにできている。

しかしこれは部分的な問題解決であって、第二種のシステムに内在する本質的なトレードオフが全部解消できるわけではない。

では、どうしたら良いのか。答えははっきりしている。清水寺の前に立った中学生のように、重要な尺度と、そうでない尺度を選り分けるのだ。どういうときには、誰とどの尺度が重要になるのか。その際、どれを犠牲にせざるをえないのか。上に述べたのは電気自動車の例だが、これが自社工場という生産システムだったら、どういう評価尺度群になるか、一度考えて見てほしい。

このような判断基準の体系を、「設計思想」と呼ぶ。何かをデザインする際には、それが電気自動車であれ生産システムであれ、必ず設計思想が必要である。できればそれは、明文化されていることが望ましい。

設計思想のはっきりした製品には、たいてい明確な個性がある。それはいわば、作り手の価値観の表明だからである。

もちろん価値観は多様だから、どうしても製品への好き嫌いが生じるだろう。嫌われるのがいやなら、あらゆる物差しをまんべんなく適度に満たした、八方美人的な製品を作ることになる。私たちはそうした、無個性な工業製品に囲まれて暮らしている。無思想な設計に囲まれて、と言い直しても良い。

それもこれもわたし達が、システムに内在するトレードオフを理解せずに生きているからなのだ。そしてあらゆる尺度を満たす、全体最適を無自覚に求めすぎる。恋愛と長寿と賢さを同時に求めた中学生たちのように。それは人間の欲深い業であると、お寺の僧侶たちなら言うかもしれない。

だが、わたしなら別の言い方をする。それはシステムというものへの、基本的な無自覚から来るのである。

＜関連エントリ＞

　→「生産システム、そのパラダイム・シフト」 （2018-04-28）

スマート工場時代の製造部品表（M-BOM）を考える

当サイトの記事アクセスランキングを見ていると、2016年に書いた「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」がしばしば上位に顔を出す。E-BOMとM-BOMの関係に悩む人が少なくないのだろう。

『設計部品表』（Engineering Bill of Materials、略称E-BOM）とは、簡単に言うと、自社の製品の構造をその構成要素（部品・モジュール等）から示したものである。他方、『製造部品表』（Manufacturing Bill of Materials、略称M-BOM）とは、外部から購入した素材・部品を、製品に作り込む製造の道筋を示す道標だ、といえる。E-BOMは製品という「結果」を示し、M-BOMは工順データ（工程表）とともに、それを作る「方法」を表現したものである。

設計部品表E-BOMは製品の構造を示し、少なくとも自社で製品を設計する企業なら、必ず持っている（データベース化されているかどうか、はともかく）。では、製造業にとって、M-BOMは何のために必要か。

それは製品の需要を、具体的な製造の作業指示に展開するために使われる。M-BOMを基準にして、生産オーダーを工程展開し、各工程・作業区ごとの製造オーダーや購買オーダーを作成するためである。つまり、製造日程計画のベースとなる、個別オーダーの工程表を作成するために必要なのだ。

さらに、製造の標準原価を計算し、価格を見積るためにも役立つ。そして、進捗管理や負荷予測や変更管理の基準とするためにも有用だ。

このように重要な基準情報であるにもかかわらず、なぜM-BOMに悩む人や企業が多いのか。そして「M-BOMクライシス」ともいうべき状態に陥りやすいのか。理由は、三つほど考えられる。

一つには、そもそも製造部品表の概念がない企業が、しばしば見受けられるからだ。それも結構な大手企業であっても、である。そんな馬鹿な、というなかれ。理由は後ほど説明する。

二つ目の理由は、日本企業における生産技術部門の弱体化に関係している。それに追い打ちをかけるのが、製品品種数の増加現象だ。そして三つ目が（そして多分、将来的には一番重要になるのが）自動化・スマート工場化の動きである。だが、これらを見ていく前に、基本的な概念と用語について、一応確認しておこう。

図を見て欲しい。部品Aは、サブ部品（子部品）aとbからなっている。Aとa・bを結びつけるのは、工順Xである。工順Xは、作業1・作業2・作業3からなっている。各作業は、一つ以上のリソース（作業者・機械・工具・金型など）を必要とする。そして、製品を製造するための工順の集合をBOP＝「工程表」と呼ぶ。これが当サイトにおける用語とモデルである。

もっとも、もしかすると、あなたの会社の使っている用語とは異なるかもしれない（たとえば「工順」ではなく「工程」と呼ぶとか）。だが、日本には米国における「APICS Dictionary」のような生産管理分野の標準辞書が存在せず、業界各社バラバラなままなので、そこは我慢していただきたい。

さて、多くの企業において、設計部門は工場の生産部門とは別の拠点で、異なるITプラットフォームを使っている場合が多い。そのため、E-BOMからM-BOMへの展開が、整合性をとって行われにくくなる。整合性のキーとなるのは、品目マスタ（部品マスタ）の共通化である。設計部門と生産部門は、同じ材料を同じ品目コードで呼ぶ必要がある－－ここまでは、以前の記事でも書いたことだ。

ところで、先ほど述べた、製造部品表のない会社とは、どのようなケースか。それは、最終組立工程と検査・出荷輸送ぐらいしか、自社内でやらないメーカーだ。部品材料は全て、外部の下請けから購入する。こうした企業では、設計部品表と購買部品表は存在する（それがないと最終検査や資材調達ができない）。しかし、製造部品表は、設計部品表と構造が同一なので、あえて別に作る必要がなかった。

ただし、E-BOMでは同種の部品が複数箇所に使われている場合がある。購買用のP-BOMでは、同一品目は数量をまとめてサマリー化する（その方が価格ネゴがやりやすいので）。このため、E-BOMから材料ごとの数量をサマリーする作業が生じる。これをエンジニアリング業界などでは、Material Take-off（MTO）と呼ぶ。もちろん、CADで設計しているならば、MTOはCADシステムの機能を使う。

それにしてもなぜ、最終組立しか自社工場でやらないメーカーが存在するのか。それには歴史的背景がある。高度成長期には、ちょっとした工作機械や製造設備を持てば、下請け企業としてビジネスが成り立つ環境があった。このために、多数の零細な下請け部品加工業者が存在する、独特の産業構造ができた。最終消費財を作る大手メーカーは、部品はすべて下請けに作らせ、自社では設計と組立てだけを行う業態になっていったのだ。

最終製品のメーカーが、M-BOMを持たぬことで、何か不都合はあるのか？　昔は、なかった。しかし、時代の変化はこの状況をかえてしまった。

長い平成不況の時代を経て、単に製造設備だけで食っている下請けは淘汰された。現代に残っているのは、筋肉質な部品メーカーばかりである。彼らは中小企業とはいえ、技術開発力も磨いているし、取引先を一社に依存しないよう、販路も拡大している。

M-BOMは製造の「方法」に関する情報だ。部品レベルの詳細な製造方法を知らないと言う事は、品質や納期問題に対して、前向きな技術的対策が打てないと言う事でもある。最終製品メーカーに課題が生じたら、下請けに命じたり、競わせたりするしか手がない。だが今や、複数の取引先を開拓した部品メーカーからは、そっぽを向かれる結果に終わる。

また最終組立しかしないメーカーでは、製品競争力の中核になるコアの部品についても、外部サプライヤーに製造を依存している。それが入手困難になったり、他社に同等製品を売られる事態になったらどうするのか？　さらに、部品加工以前の製造現場を持たないので、製造好みの設計、つまり作りやすく品質が保ちやすい設計を、自社ですることができない。競争力の重要な源泉を握っていない、と言うことになる。こうしたメーカーが外注を内製に取り込もうとすると、とたんにM-BOM不在の問題に突き当たるのだ。

さて、M-BOMにまつわる二番目の問題として、生産技術部門の弱体化は、どう関係するのか？　それは、誰が製造部品表を作るのかを考えてみれば、わかる。M-BOMは工程展開の基準情報だ。製品から工程展開を行えるのは、製造工程を熟知している生産技術ないし生産管理部門である。

既に作ったことのある製品を、繰返し生産する場合は、マスタから自動的に展開できる。だから普通は生産管理部門の仕事になる。ところが、新製品や、仕様の変更を含む場合は、どうしたって生産技術部門の仕事になる。その結果は、次回以降も繰返し可能とするために、マスターに登録することが望ましい。

問題は、リーマンショック以来、多くの製造業で生産技術部の人員削減・弱体化が進んでいることだ。にもかかわらず、差別化を求めて、次々と新製品は繰り出され、試作品が工場に充満する。そんな状況下で、製造部品表の登録維持といった地味な仕事を、誰が魂を込めてやれるだろうか？　そういう仕事をちゃんと評価できる会社だったら、そもそも生産技術者を無理に削減したりはするまい。かくて、E-BOM/M-BOM乖離の問題が発生していく。

そして製造部品表を取り巻く第3の、そして多分一番重要な課題は、昨今の人手不足に起因した自動化やスマート工場への期待だろう。スマート工場においては、より精密で新しい製造部品表の概念が要求される。生産管理業務と製造実行システムでは、部品表の粒度が異なる場合が多いからだ。だが、このことに気がついている人はまだ少ないように感じられる。

ちなみに、ここで言っている「スマート工場」とは、藤野直明氏らが近著「小説・第4次産業革命」で皮肉っぽく指摘しているような、単に製造機械にセンサーをつけてAIで分析し、チョコ停を防止したりする試みのことではない。それはごく局所的なスマート化でしかない。

わたしが課題と考えるているのは、あくまでも工場全体の知能化を目指す、スマート化である。それは工場の中の機械・人・物の状態を、全体として把握することをねらう。また、非人間的な作業は極力、機械化・自動化する工場である。それによって、より生産性の高い操業状態を目指せるし、様々な変更やトラブルに、俊敏に対応できる能力を持つだろう。

そのような次世代のスマート工場の中核には、現在の製造実行システム(MES)をさらに発展させた、中央管制のための仕組みが登場するだろうと、わたしは予測している。そこでは、複数の製造機械や搬送機械を束ねて、協調制御するシステムが機能しているだろう。

ここで改めて、先ほどの図を見てほしい。1つの工順Xの中に3つの作業1・2・3が並んでいる。それぞれの作業は、異なる機械や人などのリソースを必要としている。

そして、各作業の加工それ自体も、作業間の搬送も、自動化されてるとしよう。機械だったら、賢い人間とは違って、それぞれにプログラムを作り、指示を与えなければいけない。搬送指示だって、どの物を、どこからどこにに搬送しろ、と言う命令を機械に下すことになる。

という事は、工場内を動くモノには全て、識別のためのIDが必要になるわけだ。IDを与えたら、それが具体的に何であるかも、認識できる必要がある。こうなると、1つの工順の中に3つの作業がある場合、対応する3つの品目が必要になる訳だ。

ところで、以前別の記事に書いたように、部品表と品目マスターへの登録は、在庫管理が必要かどうか、がカギになる。1つの工順の中で、作業1で作られて次の作業2にすぐ受け渡しされる品目は、通常は在庫管理の対象にならない（こうしたものをファントムと呼ぶ）。だから生産管理システムにおいては、工順内に作業が3つあっても、品目は1つ登録すればいい訳で、製造部品表は簡潔で済んだ。

そして、わたしが見たところ、多くの製造現場では、生産管理システムの中の工順のくくりは、比較的大きな単位でまとめられている。それは、製造工程のリードタイムを、時間や分単位ではなく、「日単位」で与えているところが多いからだ。これによって、製造の順序を決める権限を、製造現場にある程度委譲しているのである。

こうした工場では、製造現場は毎朝、その日にやるべき製造オーダーのリストを眺めて、着手順位を決める。変更やトラブルがあった際にも、現場側が製造オーダーの順番を見直して解決する。それによって、製造現場に自主性と責任感を与え、また、起こりがちな予定からの変更に柔軟に適応できる能力をつけるためだ。

これは特に繰り返し性の薄い個別受注生産や、仕様変更品が多い現場には有効である。また生産計画の精度が低く、リードタイムの見積が信頼できない場合にも必要だろう。

しかし、このやり方にも弱点がある。正味1時間で済むはずの作業も、最小リードタイムの設定が1日になる。だから、工程表を構成する工順の数が多くなると、全体の生産リードタイムが有意に長くなってしまう。これを避けるためには、できた端から次工程に運搬していく必要がある。ところが、次工程に部品材料が到着しても、製造オーダーは翌日の着手予定のままだ。だから製造日程表を、生産管理システムの外側で、人手で変更するか、あるいは運んでいった人間が、自分で次工程の作業もするか、いずれかである。かくて、特級品は担当者が自分で複数の作業区を渡り歩いて、加工していくような工場も存在する。いずれにせよ人間系依存で、ちっともスマートでない。

これに対し、自動化・機械化の進んだスマート工場では、より粒度の細かな製造部品表が要求されることがおわかりいただけると思う。

しかし、そんな細かなデータを、すでに限られた人員の中で、どうやって作れるだろうか?　もし設計部品表から製造部品表への自動展開の仕組みがあれば、便利だろう。ただし、それが実現するには、製品設計において、機能別モジュール化など、いくつかの前提条件が満たされなければならない。

もう一つの方法は、製造部品表にBOD（Bill of Distribution）の概念を応用することだ。つまり品種に位置の概念を取り込むのである。長くなったのでこれ以上の説明は省くが、いずれにせよスマート工場化は、製造部品表に対し、新しい挑戦的な課題を突きつけることになるだろう。

わたし達も、それに対応するための準備や研究を怠ってはいけないと思うのである。

＜関連エントリ＞

　→「スマート工場はスマートか? 」 https://brevis.exblog.jp/27295851/ （2018-05-26）

　→「広域サプライチェーンのためのPSI（生産・販売・在庫）計画と、その立案手法DRPとは」 https://brevis.exblog.jp/23466870/ （2015-07-25）

BOMデータのマスタと履歴を区別する

どんな会社にも、従業員台帳というのがある。従業員の氏名・誰それ、その住所、生年月日、入社年度、職種といった情報が記されている台帳だ。同姓同名の場合もありうるから、普通は従業員番号も振られているはずである。

同じようにどんな会社にも、給与台帳と言うものがあるはずだ。従業員誰それに支払うべき月給はいくらいくら、といった金額が書いてある。

もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから2019年8月には、誰それに給料をいくらいくら支払った、という履歴も、台帳に残しているはずだ。

月々支払うべき基準としての給与と、毎月実際に支払うべき金額のリスト。どんな会社もこの2つを持っている。

それだけではない。会社によっては、実際にいくら支払ったかの履歴を、さらに別に持っている場合もある。例えば手当の一部が外貨建てである場合は、給与計算をした日と、実際に支払う日では、換算レートが違ったりする。だから、支払おうと決めた金額と、実際に支払った金額に若干の差が出るのである。外貨建て以外にも、現物支給などがあると、やはり実際の支払額が変わりうる。

標準としての給与額。支払おうと決めた決済の金額。そして、実際に支払った金額。この3種類は別のデータだ。だからコンピュータでこのデータを管理したいときには、3種類の別々のテーブルに、記録することになるだろう。

ITエンジニアは、標準としての給与額を記載したケーブルを、「マスタデータ」と呼ぶ。そして月々の支払い金額を消した2種類のテーブルは、あまり聞き慣れない名前かもしれないが、「トランザクション・データ」と呼ぶ。

マスタデータとトランザクションデータの違いは何か? マスタデータは、基準値だから、一旦登録するとそう頻繁には変わらない。給与台帳を更新するのは普通、年に1回位だ。

トランザクションデータの目的は、取引履歴の記録であることが多い。したがって取引が発生するごとに、頻繁に追記される。そのかわり、一旦記録したデータは、基本的には更新されない（例外はあるが）。「取引」と言う言葉を使ったが、これは商取引の意味には限らない。社内的な指示や報告は、データのやり取りであって、データ論的には取引にあたる。

それでは、部品表（BOM）データは、マスタだろうか、トランザクションだろうか？

ある種の人々にとっては自明なこの問いが、しばしば別の人々にとっては混乱の元となる。今回はこの問題を考えてみたい。

「生産とは、設計情報をモノ（媒体）に転写する活動である」、という言い方がある。ちょうど、生物の細胞の中で、DNAに書かれた遺伝情報が、分裂増殖のたびに転写され、新しい細胞が作られていくように。これは、元は東大のものづくり研究で著名な、藤本教授の発言である（たとえば、「ものづくり経営の今後」https://www.panasonic.com/jp/corporate/technology-design/ptj/pdf/v5503/p0202.pdf参照）。

そして、製造業にとってDNAにあたる「設計情報」の、中核にあるのがBOMデータだ。

である以上、BOMデータは製品の「あるべき姿」を示す基準であって、そうそう頻繁に変更されるものではない。だから、マスタデータに他ならない・・こう考える人が多いだろう。

果たして、そうだろうか？

ためしに、個別受注生産（受注設計生産）の場合を考えてみてほしい。造船だとか、産業機械だとか、宇宙ロケットといった、もの作りの分野だ。金型とか鉄骨建材なども、この部類に入る。こうした業種では、正式に受注してから、詳細な設計作業が始まる。顧客の要求する仕様は、毎回、個別だから、それに合わせて、機能や構造や制御方式を考え、決めていく。当然ながら個別受注生産では、受注時点でBOMが確定しておらず、設計が進むにつれてBOMが出来上がっていく。

このような業種のBOMは、マスタデータだろうか。もちろん、この設計情報が、工場でモノに転写され製品と化していく訳だから、一種の「基準情報」であることは間違いない。しかし、このBOMをデータベースに登録するとして、これはマスタだろうか。

マスタデータの条件は、頻繁に内容が更新されない事、だった。さて、この条件はどうか。いったん設計が確定し、出図されたら、そう簡単には変更されるべきではないし、変更されたら皆が困る。購買部門は注文したものを変更しなければならないし、製造部門は作りかけたものを手直ししなければならない。うん。だから、変更は少ないはず、と。

実際にこの業種に従事する人がここを読んだら、苦笑いするだろう。そんなことはない、現実には、ありがたくない変更が次から次に起こって、そこから発生する問題をどうボクメツするかが、生産管理の仕事の中心にあるのだ、と。

この事情は、ITエンジニアの読者の方には、受託開発のSIの仕事に類似している、といえば分かっていただけるだろう。SIプロジェクトでは、個別の要件に従って、毎回、要件定義と基本設計を行う。だが、上流工程で固まったはずの仕様が、しばしば実装テスト段階になっても変更を余儀なくされ、それとの闘いが仕事の後半戦の中心になるのだ。SIerの人達に、あなた方の設計図（たとえばモジュール構成図）は、マスタデータですか、と問うたら、どういう答えが返ってくるだろうか。

それに、上記の説明では、まるでBOMデータが設計の完了とともに、一気にワンセット出力されてくるようなイメージで書いた。しかし、現実はそうではないのだ。個別受注生産ではしばしば、コアとなる長納期部品があって、その周囲の部分から先に設計を固めていく。そして中核部分のBOMデータから順次、アウトプットされていく。そうしないと、購買手配が間に合わないからだ。

ある部分はすでに調達が走っているのに、別の部分はまだ設計作業を続けている。そういう並進フェーズがしばらく続く。その間は、BOMデータは順次、追加されていく。既存部分の変更も起きる。

しかも、こうした業種では、部品・材料自体、毎回、個別仕様で購買することが多い。さすがに汎用の材料を使う部分もあるが（とくにケーブルやパイプ・継手など）、こちらは長さ・個数など数量が、毎回、まちまちである。

したがって、こうした個別受注生産の業種では、BOMデータはマスタとして登録しがたいことが分かる。この分野のBOMデータは、購買や製造部門に対する指示であって、いわばトランザクションデータなのである。

しかも個別受注生産では、製造段階で思わぬ問題が生じ（主に設計変更に起因する）、その対応のために、最初の設計図とは違う形で、製造がおこなわれることも、しばしばある。そこで、出荷納品時に、あらためて設計図や設計情報を更新することも多い。これを「As-built」データと呼ぶ。世の中は「As-Is」と「To-Be」の2種類のモデルで割り切れる、と信じている類の人には、驚きだろうが。

As-builtのBOMデータは、「こう作りました」という製造実績を記録する履歴データ＝トランザクションである。これは、「こう作ってほしい」という設計のBOMデータと対になっている。個別受注生産の業種では、基本的に、

「製造指示のBOMデータ」

「製造実績のBOMデータ」

の2種類のトランザクション・データが存在し、もしもITシステムでデータベース化する際には、この2種類のテーブルを構築する必要がある。

では、マスタデータはないのか？　BOMのマスタデータは、ない。毎回異なるのだから。毎日違う人を雇って、実働時間に合わせて日給を支払う、日雇い労働の会社に、給与台帳など存在しないのと同じだ。

ただし、個別受注生産の業種でも、品目マスタ（部品材料マスタ）は作れるし、作るべきだとわたしは考えている。それは、調達業務や原価（＝見積）業務のコントロール水準を向上するために、役に立つからだ。もちろん、設計基準情報の共有・再利用という面でも、省力化に利するだろう。

しかし現実には、たとえそれなりの大企業であっても、品目マスタを持っていないケースを、しばしば見かける。毎回、個別仕様でまちまちの部品・材料の数量表を作って、調達やコスト見積を追いかけていくが、出荷して仕事が終わったら、誰かの机の中にファイルされて朽ちていく。データの使い捨てである。余談だが、個別性に生きるこの業界では、データの再利用とか、標準化の意識が低いように感じられる。過去の設計結果（履歴）のコピペで、もう十分「省力化」ができてると思っていたりする。

・・以上のような話を読んでも、「それは特殊な業界の話だろ」と思う読者は多いかもしれない。日本の製造業の花形は、自動車と家電、その周辺業界だ。こうした業界では、あらかじめきちんと設計された製品を、繰り返し量産していく。だからBOMデータはまさにDNAであり、マスタであるはずだ。一部の特殊な業種の病的な事例を挙げても、参考になるのか、と。

たしかに、繰返し生産型の工場では、ふつう、BOMデータはマスタとして保持している。それを元に、資材購買の手配や、部品在庫からのピッキングや、各工程への製造オーダーが発行される。個別の数量やタイミングは、需要（受注数）と在庫や進捗に応じて変わるだろうが、本来、製品が必要とする部品材料の員数は、不変である。

そしてBOMマスタは、設計に変更生じた時にのみ、更新される。設計は、何らかの仕様に変更が生じた時（ふつうは製品開発に伴って）に起きるだけのはずだ。これが正常なBOMデータの姿である、と。そう思われるかもしれない。

では、お伺いしたい。貴方が新品の自動車を買うとき、いろいろなオプションを指定し注文しなかっただろうか。新しいPCをネットで注文した時、ストレージやCPUやメモリを選ばなかっただろうか。これはすべて、個別仕様ではないか？

そう。個別仕様だ。だが、そのために、自動車メーカーやPCメーカーが、いちいち設計図を起こすようなことはしない。塗装の色もエアバッグもミッション部分も、すべて標準モジュール化され、組立て段階で選んで組みつければ良いようになっている。これを受注組立生産（ATO=Assemble to Order）による「マス・カスタマイゼーション」と呼び、先進的な業界の姿である、と。きっと新進気鋭のコンサルタントなら、そう反論するだろうなあ。

それで、個別仕様への対応を、オプションとモジュール構成で実現するATOの工場では、BOMデータはどうなっているのか。オーダー番号ABC0987の、佐藤氏の注文したPCは、どの部品とどの部品を組み合わせて作るのか。当然ながら受注システムから製造システムに対して、オーダー番号に紐づいて、データが受け渡される。内容は、使用すべき部品のリストである。これは、BOMのトランザクションそのものではないか。

見込生産・繰返し型受注生産で量産型なら、たしかに生産活動はBOMマスタの単純な転写と言っていい。しかしATO（受注組立生産）では、明らかに、個別のBOM指示が必要で、その履歴はトランザクションデータになる。（ついでに言うと、ATOでは、月度生産計画や部品調達計画のために、モジュラー型BOMも必要になるのだが、この話をすると長くなるので、興味がある方は拙著『BOM/部品表入門』 第8章を参照してほしい）

そして、さらに言うならば、単純な繰返し型の生産形態は、今日の日本では少なくなった。単純な量産は、海外に出てしまって、日本国内に生き残っている工場の多くは、個別仕様だとか、試作品だとか小ロット特級品だとか、ちょっと厄介な仕事に対応することで稼いでいる。

そして、個別仕様を受け入れ始めるやいなや、必要とされるBOMデータは、マスタに登録されている標準品からずれていく。それを、個別のオーダーに紐づけて、記録していく必要が生じる。だから、BOMはマスタ以外に、製造オーダーに紐づくトランザクションデータも、持っておかねばならない。

BOMがマスタであるべき、という一種の思い込みは、現在の構造型BOMが、MRPという生産管理方式と一緒に生まれたことから生じているらしい。だが、本家欧米のMRPさえ、個別仕様に対応せざるを得なくなってきているし、実際、SAPの生産管理モジュールでさえ、ずいぶん以前（R/3の時代）から、生産オーダーにBOMを添付して発行する機能を持っていたと記憶する。

それだけではない。実際には、生産オーダーを受け取った製造現場側が、さまざまな理由から、その通り作れずに、部品材料を変更することがある。よくあるのは、サプライヤーの変更に伴い、部品材料が変わってしまうとか、部品のストック切れを待って、新しい仕様の部品に切り替えていくとかいった状況である。ほかにも、リソース（生産資源）の変更（加工機械を変える、など）もありうるし、工順の変更（外注に出す、など）もある。

こうしたことは、すべて、指示されたBOMデータからの変更であり、実績として別途、記録しておく必要がある。そうしないと、出荷後に品質問題が見つかったり、保守サービスの要求をもらった際に、実際に何と何でどう作っていたかを、追えなくなってしまうからである。

かくして、いわゆる繰返し受注生産型の業種であっても、結局、

・設計の姿としてのBOMのマスタデータ

・製造指示としてのBOMの履歴（トランザクション）データ

・製造実績としてのBOMの履歴（トランザクション）データ

の3種類のBOMデータベースが必要になる訳である。

そして、これこそが、いわゆる「E-BOMとM-BOMの乖離問題」を防ぐ、予防線の一つなのだ。E-BOM/M-BOMの乖離が生じる原因はいくつかあるが、その重要な一つが、設計図と、実際の製造にズレが生じることにある。ズレの原因は、上述のように、個別仕様への対応の場合もあれば、部品在庫の都合もあるし、様々だ。だが、ズレが生じるのが、現実だ。その現実を、BOMマスタ一つだと、救いきれなくなる。

だから、BOMデータベースには、原則として、3種類が必要になる、と最初から考えてDB設計する方がいい。これは、落ち着いて考えれば当たり前の話であって、だからわたしは『BOM/部品表入門』の冒頭、プロローグにこの図を入れたのである。

だが、BOMデータのマスタとトランザクションの区別（併用）という考え方は、未だに必ずしも普及していないようだ。つい最近も、ある大手IT企業の資料の中に、「E-BOMとM-BOMの乖離問題は、見込生産や繰返し受注生産に起きやすい。個別受注生産ではこの問題は生じない」という見解が書いてあって、驚いた。わたしの誤解かもしれないけれど、この会社は、E-BOM/M-BOM問題と、マスタ/トランザクションの区別を、なんだか一緒くたに論じているのではないかと思えたのである。

こうした議論の混乱が生じる一因は、マスタデータというものが、「再利用可能なデータの格納場所である」という理解が不足していることにもあるのではないか。マスタデータは、単に更新頻度が少ないデータの置き場所ではないのだ。データを「再利用可能」な姿にブラッシュアップして、それを皆が共有し参照できるようにするため、台帳としてのマスタを作るのである。

マネジメントとは、PDCAサイクルを回すことだけではない。個別性の高い仕事を、繰り返し可能にし、再利用可能にし、標準化することもマネジメントなのだ。もちろん、そのためのデータのマネジメントだって含まれる。

マネジメントとは、結果（製品）だけ出せば良いのではない。仕事を個人に依存しない、インパーソナルな仕組みに作り上げることである。仕事を、個人の知識や経験値に依存した、属人的なものに留める段階にとどまっているならば、その組織は、いつまでたっても、新しい能力を共有することができないだろう。

では、製品種別が増え、個別仕様が増え、受注設計生産を余儀なくされている現代の製造業にとって、BOMデータのマネジメントはどうあるべきか。それを考えるための有償セミナーを、12月にもう一度、アンコールで実施することになった。長い記事の最後に、宣伝めいた終わり方で恐縮だが、もしこの主題に関心がおありになる方がいたら、下記のURLをのぞいて、ご検討いただきたい。

2019年12月17日(火) 10:30 ~ 17:30

ＢＯＭ／部品表の基礎と効果的な活用ノウハウ

https://www.j-techno.co.jp/seminar/seminar-31675/

もちろん、佐藤の考え方には賛成できない、反論を述べたい、という方も大歓迎である（笑）。ちゃんと議論して、わたし達の社会の製造業のレベルアップに、ぜひ一緒に寄与しようではないか。

＜関連エントリ＞

　→「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」 https://brevis.exblog.jp/24157732/ （2016-02-21）

　→「オプションが多数ある製品のBOMは、どう構成すべきか」 https://brevis.exblog.jp/21404200/ （2013-12-02）

BOMデータのマスタと履歴を区別する

どんな会社にも、従業員台帳というのがある。従業員の氏名・誰それ、その住所、生年月日、入社年度、職種といった情報が記されている台帳だ。同姓同名の場合もありうるから、普通は従業員番号も振られているはずである。

同じようにどんな会社にも、給与台帳と言うものがあるはずだ。従業員誰それに支払うべき月給はいくらいくら、といった金額が書いてある。

もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから2019年8月には、誰それに給料をいくらいくら支払った、という履歴も、台帳に残しているはずだ。

月々支払うべき基準としての給与と、毎月実際に支払うべき金額のリスト。どんな会社もこの2つを持っている。

それだけではない。会社によっては、実際にいくら支払ったかの履歴を、さらに別に持っている場合もある。例えば手当の一部が外貨建てである場合は、給与計算をした日と、実際に支払う日では、換算レートが違ったりする。だから、支払おうと決めた金額と、実際に支払った金額に若干の差が出るのである。外貨建て以外にも、現物支給などがあると、やはり実際の支払額が変わりうる。

標準としての給与額。支払おうと決めた決済の金額。そして、実際に支払った金額。この3種類は別のデータだ。だからコンピュータでこのデータを管理したいときには、3種類の別々のテーブルに、記録することになるだろう。

ITエンジニアは、標準としての給与額を記載したケーブルを、「マスタデータ」と呼ぶ。そして月々の支払い金額を消した2種類のテーブルは、あまり聞き慣れない名前かもしれないが、「トランザクション・データ」と呼ぶ。

マスタデータとトランザクションデータの違いは何か? マスタデータは、基準値だから、一旦登録するとそう頻繁には変わらない。給与台帳を更新するのは普通、年に1回位だ。

トランザクションデータの目的は、取引履歴の記録であることが多い。したがって取引が発生するごとに、頻繁に追記される。そのかわり、一旦記録したデータは、基本的には更新されない（例外はあるが）。「取引」と言う言葉を使ったが、これは商取引の意味には限らない。社内的な指示や報告は、データのやり取りであって、データ論的には取引にあたる。

それでは、部品表（BOM）データは、マスタだろうか、トランザクションだろうか？

ある種の人々にとっては自明なこの問いが、しばしば別の人々にとっては混乱の元となる。今回はこの問題を考えてみたい。

「生産とは、設計情報をモノ（媒体）に転写する活動である」、という言い方がある。ちょうど、生物の細胞の中で、DNAに書かれた遺伝情報が、分裂増殖のたびに転写され、新しい細胞が作られていくように。これは、元は東大のものづくり研究で著名な、藤本教授の発言である（たとえば、「ものづくり経営の今後」https://www.panasonic.com/jp/corporate/technology-design/ptj/pdf/v5503/p0202.pdf参照）。

そして、製造業にとってDNAにあたる「設計情報」の、中核にあるのがBOMデータだ。

である以上、BOMデータは製品の「あるべき姿」を示す基準であって、そうそう頻繁に変更されるものではない。だから、マスタデータに他ならない・・こう考える人が多いだろう。

果たして、そうだろうか？

ためしに、個別受注生産（受注設計生産）の場合を考えてみてほしい。造船だとか、産業機械だとか、宇宙ロケットといった、もの作りの分野だ。金型とか鉄骨建材なども、この部類に入る。こうした業種では、正式に受注してから、詳細な設計作業が始まる。顧客の要求する仕様は、毎回、個別だから、それに合わせて、機能や構造や制御方式を考え、決めていく。当然ながら個別受注生産では、受注時点でBOMが確定しておらず、設計が進むにつれてBOMが出来上がっていく。

このような業種のBOMは、マスタデータだろうか。もちろん、この設計情報が、工場でモノに転写され製品と化していく訳だから、一種の「基準情報」であることは間違いない。しかし、このBOMをデータベースに登録するとして、これはマスタだろうか。

マスタデータの条件は、頻繁に内容が更新されない事、だった。さて、この条件はどうか。いったん設計が確定し、出図されたら、そう簡単には変更されるべきではないし、変更されたら皆が困る。購買部門は注文したものを変更しなければならないし、製造部門は作りかけたものを手直ししなければならない。うん。だから、変更は少ないはず、と。

実際にこの業種に従事する人がここを読んだら、苦笑いするだろう。そんなことはない、現実には、ありがたくない変更が次から次に起こって、そこから発生する問題をどうボクメツするかが、生産管理の仕事の中心にあるのだ、と。

この事情は、ITエンジニアの読者の方には、受託開発のSIの仕事に類似している、といえば分かっていただけるだろう。SIプロジェクトでは、個別の要件に従って、毎回、要件定義と基本設計を行う。だが、上流工程で固まったはずの仕様が、しばしば実装テスト段階になっても変更を余儀なくされ、それとの闘いが仕事の後半戦の中心になるのだ。SIerの人達に、あなた方の設計図（たとえばモジュール構成図）は、マスタデータですか、と問うたら、どういう答えが返ってくるだろうか。

それに、上記の説明では、まるでBOMデータが設計の完了とともに、一気にワンセット出力されてくるようなイメージで書いた。しかし、現実はそうではないのだ。個別受注生産ではしばしば、コアとなる長納期部品があって、その周囲の部分から先に設計を固めていく。そして中核部分のBOMデータから順次、アウトプットされていく。そうしないと、購買手配が間に合わないからだ。

ある部分はすでに調達が走っているのに、別の部分はまだ設計作業を続けている。そういう並進フェーズがしばらく続く。その間は、BOMデータは順次、追加されていく。既存部分の変更も起きる。

しかも、こうした業種では、部品・材料自体、毎回、個別仕様で購買することが多い。さすがに汎用の材料を使う部分もあるが（とくにケーブルやパイプ・継手など）、こちらは長さ・個数など数量が、毎回、まちまちである。

したがって、こうした個別受注生産の業種では、BOMデータはマスタとして登録しがたいことが分かる。この分野のBOMデータは、購買や製造部門に対する指示であって、いわばトランザクションデータなのである。

しかも個別受注生産では、製造段階で思わぬ問題が生じ（主に設計変更に起因する）、その対応のために、最初の設計図とは違う形で、製造がおこなわれることも、しばしばある。そこで、出荷納品時に、あらためて設計図や設計情報を更新することも多い。これを「As-built」データと呼ぶ。世の中は「As-Is」と「To-Be」の2種類のモデルで割り切れる、と信じている類の人には、驚きだろうが。

As-builtのBOMデータは、「こう作りました」という製造実績を記録する履歴データ＝トランザクションである。これは、「こう作ってほしい」という設計のBOMデータと対になっている。個別受注生産の業種では、基本的に、

「製造指示のBOMデータ」

「製造実績のBOMデータ」

の2種類のトランザクション・データが存在し、もしもITシステムでデータベース化する際には、この2種類のテーブルを構築する必要がある。

では、マスタデータはないのか？　BOMのマスタデータは、ない。毎回異なるのだから。毎日違う人を雇って、実働時間に合わせて日給を支払う、日雇い労働の会社に、給与台帳など存在しないのと同じだ。

ただし、個別受注生産の業種でも、品目マスタ（部品材料マスタ）は作れるし、作るべきだとわたしは考えている。それは、調達業務や原価（＝見積）業務のコントロール水準を向上するために、役に立つからだ。もちろん、設計基準情報の共有・再利用という面でも、省力化に利するだろう。

しかし現実には、たとえそれなりの大企業であっても、品目マスタを持っていないケースを、しばしば見かける。毎回、個別仕様でまちまちの部品・材料の数量表を作って、調達やコスト見積を追いかけていくが、出荷して仕事が終わったら、誰かの机の中にファイルされて朽ちていく。データの使い捨てである。余談だが、個別性に生きるこの業界では、データの再利用とか、標準化の意識が低いように感じられる。過去の設計結果（履歴）のコピペで、もう十分「省力化」ができてると思っていたりする。

・・以上のような話を読んでも、「それは特殊な業界の話だろ」と思う読者は多いかもしれない。日本の製造業の花形は、自動車と家電、その周辺業界だ。こうした業界では、あらかじめきちんと設計された製品を、繰り返し量産していく。だからBOMデータはまさにDNAであり、マスタであるはずだ。一部の特殊な業種の病的な事例を挙げても、参考になるのか、と。

たしかに、繰返し生産型の工場では、ふつう、BOMデータはマスタとして保持している。それを元に、資材購買の手配や、部品在庫からのピッキングや、各工程への製造オーダーが発行される。個別の数量やタイミングは、需要（受注数）と在庫や進捗に応じて変わるだろうが、本来、製品が必要とする部品材料の員数は、不変である。

そしてBOMマスタは、設計に変更生じた時にのみ、更新される。設計は、何らかの仕様に変更が生じた時（ふつうは製品開発に伴って）に起きるだけのはずだ。これが正常なBOMデータの姿である、と。そう思われるかもしれない。

では、お伺いしたい。貴方が新品の自動車を買うとき、いろいろなオプションを指定し注文しなかっただろうか。新しいPCをネットで注文した時、ストレージやCPUやメモリを選ばなかっただろうか。これはすべて、個別仕様ではないか？

そう。個別仕様だ。だが、そのために、自動車メーカーやPCメーカーが、いちいち設計図を起こすようなことはしない。塗装の色もエアバッグもミッション部分も、すべて標準モジュール化され、組立て段階で選んで組みつければ良いようになっている。これを受注組立生産（ATO=Assemble to Order）による「マス・カスタマイゼーション」と呼び、先進的な業界の姿である、と。きっと新進気鋭のコンサルタントなら、そう反論するだろうなあ。

それで、個別仕様への対応を、オプションとモジュール構成で実現するATOの工場では、BOMデータはどうなっているのか。オーダー番号ABC0987の、佐藤氏の注文したPCは、どの部品とどの部品を組み合わせて作るのか。当然ながら受注システムから製造システムに対して、オーダー番号に紐づいて、データが受け渡される。内容は、使用すべき部品のリストである。これは、BOMのトランザクションそのものではないか。

見込生産・繰返し型受注生産で量産型なら、たしかに生産活動はBOMマスタの単純な転写と言っていい。しかしATO（受注組立生産）では、明らかに、個別のBOM指示が必要で、その履歴はトランザクションデータになる。（ついでに言うと、ATOでは、月度生産計画や部品調達計画のために、モジュラー型BOMも必要になるのだが、この話をすると長くなるので、興味がある方は拙著『BOM/部品表入門』 第8章を参照してほしい）

そして、さらに言うならば、単純な繰返し型の生産形態は、今日の日本では少なくなった。単純な量産は、海外に出てしまって、日本国内に生き残っている工場の多くは、個別仕様だとか、試作品だとか小ロット特級品だとか、ちょっと厄介な仕事に対応することで稼いでいる。

そして、個別仕様を受け入れ始めるやいなや、必要とされるBOMデータは、マスタに登録されている標準品からずれていく。それを、個別のオーダーに紐づけて、記録していく必要が生じる。だから、BOMはマスタ以外に、製造オーダーに紐づくトランザクションデータも、持っておかねばならない。

BOMがマスタであるべき、という一種の思い込みは、現在の構造型BOMが、MRPという生産管理方式と一緒に生まれたことから生じているらしい。だが、本家欧米のMRPさえ、個別仕様に対応せざるを得なくなってきているし、実際、SAPの生産管理モジュールでさえ、ずいぶん以前（R/3の時代）から、生産オーダーにBOMを添付して発行する機能を持っていたと記憶する。

それだけではない。実際には、生産オーダーを受け取った製造現場側が、さまざまな理由から、その通り作れずに、部品材料を変更することがある。よくあるのは、サプライヤーの変更に伴い、部品材料が変わってしまうとか、部品のストック切れを待って、新しい仕様の部品に切り替えていくとかいった状況である。ほかにも、リソース（生産資源）の変更（加工機械を変える、など）もありうるし、工順の変更（外注に出す、など）もある。

こうしたことは、すべて、指示されたBOMデータからの変更であり、実績として別途、記録しておく必要がある。そうしないと、出荷後に品質問題が見つかったり、保守サービスの要求をもらった際に、実際に何と何でどう作っていたかを、追えなくなってしまうからである。

かくして、いわゆる繰返し受注生産型の業種であっても、結局、

・設計の姿としてのBOMのマスタデータ

・製造指示としてのBOMの履歴（トランザクション）データ

・製造実績としてのBOMの履歴（トランザクション）データ

の3種類のBOMデータベースが必要になる訳である。

そして、これこそが、いわゆる「E-BOMとM-BOMの乖離問題」を防ぐ、予防線の一つなのだ。E-BOM/M-BOMの乖離が生じる原因はいくつかあるが、その重要な一つが、設計図と、実際の製造にズレが生じることにある。ズレの原因は、上述のように、個別仕様への対応の場合もあれば、部品在庫の都合もあるし、様々だ。だが、ズレが生じるのが、現実だ。その現実を、BOMマスタ一つだと、救いきれなくなる。

だから、BOMデータベースには、原則として、3種類が必要になる、と最初から考えてDB設計する方がいい。これは、落ち着いて考えれば当たり前の話であって、だからわたしは『BOM/部品表入門』の冒頭、プロローグにこの図を入れたのである。

だが、BOMデータのマスタとトランザクションの区別（併用）という考え方は、未だに必ずしも普及していないようだ。つい最近も、ある大手IT企業の資料の中に、「E-BOMとM-BOMの乖離問題は、見込生産や繰返し受注生産に起きやすい。個別受注生産ではこの問題は生じない」という見解が書いてあって、驚いた。わたしの誤解かもしれないけれど、この会社は、E-BOM/M-BOM問題と、マスタ/トランザクションの区別を、なんだか一緒くたに論じているのではないかと思えたのである。

こうした議論の混乱が生じる一因は、マスタデータというものが、「再利用可能なデータの格納場所である」という理解が不足していることにもあるのではないか。マスタデータは、単に更新頻度が少ないデータの置き場所ではないのだ。データを「再利用可能」な姿にブラッシュアップして、それを皆が共有し参照できるようにするため、台帳としてのマスタを作るのである。

マネジメントとは、PDCAサイクルを回すことだけではない。個別性の高い仕事を、繰り返し可能にし、再利用可能にし、標準化することもマネジメントなのだ。もちろん、そのためのデータのマネジメントだって含まれる。

マネジメントとは、結果（製品）だけ出せば良いのではない。仕事を個人に依存しない、インパーソナルな仕組みに作り上げることである。仕事を、個人の知識や経験値に依存した、属人的なものに留める段階にとどまっているならば、その組織は、いつまでたっても、新しい能力を共有することができないだろう。

では、製品種別が増え、個別仕様が増え、受注設計生産を余儀なくされている現代の製造業にとって、BOMデータのマネジメントはどうあるべきか。それを考えるための有償セミナーを、12月にもう一度、アンコールで実施することになった。長い記事の最後に、宣伝めいた終わり方で恐縮だが、もしこの主題に関心がおありになる方がいたら、下記のURLをのぞいて、ご検討いただきたい。

2019年12月17日(火) 10:30 ~ 17:30

ＢＯＭ／部品表の基礎と効果的な活用ノウハウ

https://www.j-techno.co.jp/seminar/seminar-31675/

もちろん、佐藤の考え方には賛成できない、反論を述べたい、という方も大歓迎である（笑）。ちゃんと議論して、わたし達の社会の製造業のレベルアップに、ぜひ一緒に寄与しようではないか。

ミニレビュー：ポータブル・オルクハンガー

ポータブル・オルクハンガー （Amazon.com）

以前も書いたことだが、冷房が苦手である。若い頃に、南国に1年ほど暮らしたことがあったが、その時に冷房病にかかってしまった。それ以来、体温調節の機能が低下したらしい。もともと汗かきの方だったが、冷房の効いた場所に入っても、しばらく首から背中にかけての汗が止まらず、それが冷えて風邪をひく原因になりやすい。

自衛のために、夏は、替えの下着を持って歩くのが常である。おまけに、冷風による「冷え」から体を守るために、薄手のベストや上着を持って歩くことも多い。まして客先を訪問する時ともなれば、なおさらだ。かくして、夏場はかえって荷物が増える、という奇妙なことになる。

ことに面倒なのは、上着の扱いである。サラリーマンなので、上着を持って歩かなければいけないことが、結構ある。上着というやつは、畳んでバックに入れるとしわくちゃになるし、かといって、腕にかけて持ち運ぶのはけっこう面倒な上に、腕にも汗をかいてしまって、汚れやすい。

どうしたものかと悩んでいた時に、携帯型の小さなハンガーを、知人が見せてくれた。伸縮可能なステンレス製のポールに、ストラップのついただけの簡単なハンガーだが、小さいし、持ち歩きやすい。たたむと20センチ以下だが、伸ばすと40センチ位になる。小さな袋が付属していて、使わないときにはたたんで、バッグの中で邪魔にならないように、しまうこともできる。

上着を持って歩くときは、ボールを伸ばし、上着を2つ折りにし、そこにかけて、外側のストラップを引っ張る。すると、内側のストラップがボールに密着して、上着がずれて落ちないようになっている。簡単だが巧妙な仕掛けだ。

このままストラップを肩にかけて、持ち歩くのでもいい。だが、わたしはあえて、トートバッグの口に、このハンガーの両端を引っ掛けて、上着が外から見えないような形で持ち歩くことにしている。

新幹線の中などでも、上着をこのハンガーにかけて、自分の座席の前にかけておくと、シワになりにくく、扱いが楽である。上に述べた小さな袋を使うと、リュックやバッグの外側に、このハンガーを固定して、一体で持ち運ぶこともできる。なかなか小技が効いているのは、ユーザのことをよく考えている証拠だろう。

この頃は毎年、暑い夏が続いている。本当は、日本のような高温多湿な地域で、夏も冷涼な英国発のスーツ・ワイシャツ・ネクタイの風俗に従っていることに、無理があるのだ。近年はお上の主導で、ようやく夏場のネクタイをしなくて済むようになり、少しは助かった。

しかし、米国ハワイ州のように、気候風土に適した服装（＝半袖のアロハシャツ、女性ならムームー）が『正装』の地位を占めるようになるまでは、まだ時間がかかるのだろう。あそこの島では、知事だろうが州議会議員だろうが、アロハ姿で仕事をしえいるのだが。そして、冷房抜きで過ごせる気持ちの良い夏は、日本の大都会には望みようもないらしい。だとしたら、しばらくは、こうして上着を持ち歩く道具に、少しばかりの知恵を注ぐのが賢明なのだろう。

敗北から何を学ぶか 〜 その2・結果よりもプロセスに学べ

－－敗北から学ぶために必要な方法にも、いくつかある。ここでは4つぐらいあげようか。

まず第一に、勝敗の結果だけではなく、プロセスと中間目標を設定しておく。本当はこれは、戦う前に、やっておく必要がある。その上で、個別の戦局や、あるいは全体における達成度を吟味する。

「どういうことですか？」

－－つまりさ、ローマは1日にしてならず、というだろう。たとえば何でもいいけど、大学受験を例に取ろうか。難関の名門校に入りたい、と。そうしたら、受験科目のどれが得意か、どう勉強するのか、予備校には行くのか、考えるだろう？　また、模試を複数回受けるとして、現役1回目は何点くらい、2回目は何点、と想定して、直前模試でA判定になればいいはずだ。

こう言う風に、単なる勝ち負けだけでなく、プロセスと中間目標を設定する。そして、途中途中で、目指した通りに進んでいるか検証する。うまくなければ軌道修正する。仮に現役では合格できなくても、もう一度チャレンジするべきか、考え直す。そして反省点を翌年の試験に生かそうとするだろう・・それなのに、受験生のときにはできていたことが、ビジネスマンになるとすっかり忘れてしまうとしたら、奇妙なことだ。

「確かにそうですね。でも、その中間目標というのは、実際にはどう立てたらいいんでしょう。ビジネス上の戦いは、受験ほど単純じゃありません。偏差値の表もなければ、予備校の模擬試験もありませんし。」

－－もちろんだ。だから2番目に大切なことは、適切な戦略を選んでから、中間目標に落とし込むと言うことだ。

「戦略を選ぶ、ですか？　戦略って、毎回個別に考えるものかと思っていました。」

－－もちろん、そうさ。そうだけれども、戦略にはある種の定石ないしパターンがある。まあ、戦略論は多岐に渡るから、ざっくり簡単なパターンに絞って説明することにしようか。

たとえば市場における競争戦略は、その会社の立場によって異なる。チャンピオンの戦略と、挑戦者にとっての戦略と、ニッチプレイヤーの戦略は異なる。あなたのところの会社は、チャンピオンかな、それとも挑戦者か、ニッチプレイヤーなのかな？

「えーと・・あまり考えたことがありませんでした。今回の戦いに限って言うと、トップ企業じゃないから、チャレンジャーかなぁ。」

－－なるほど。どんな業界も大体、少数のトップ企業と、それに次ぐチャレンジャーたちと、多数の小さなニッチプレーヤーからなる、いわばピラミッド構造になっている。

業界のトップ企業は、その規模を生かして、製品もフルラインナップを揃えているし、営業ネットワークもあるし、物量を生かしてローコストで大量生産ができる。だから最終的には価格競争に持ち込んで、顧客を囲い込む。これを『コストリーダーシップ戦略』という。戦争に例えるならば、正面攻撃の戦術といってもいい。

「はい。」

－－一方、チャレンジャーたちは、正面から価格競争を挑んでも、勝てそうもない。そこで普通は、『差別化戦略』を考える。大手が販売する製品とは、かなり異なった特徴のある製品を売り出して、価格とは別の面で顧客に訴求する。側面攻撃の戦術と言っていいだろう。

「確かにある意味で、僕らが戦う上でとっていた方策は、差別化を志向したと言ってもいいかもしれません。意識してやったわけではありませんが。」

－－なるほど。そして大多数の、中小零細規模のプレイヤーたちは、ある狭い局地的範囲内のみに、自分たちの持てる経営資源を集中して、そのニッチなマーケットだけは死守しようとする。例えば顧客との長いつながりで商売を続けている、地方の老舗の商店を考えればわかるかな。あるいはごく特殊な製品のみを扱う、その分野でのみ全国的に名の知られている企業なんかも、これに近い。いわば局地戦、ないしゲリラ攻撃の戦術だ。これを『集中戦略』という。

そしてこの3つの戦略ごとに、立てるべき方策も、中間目標も異なっている。

「なるほど、そういう風にロジックを持って考えると、中間的な目標も立てやすいですね。」

－－ただしね、ここに挙げたのはパターンに過ぎないから、実際には具体的に何をどうするかを考えないと、戦略の名に値しない。戦略とは、固有名詞が入って初めて、役に立つものだ。

たとえば第二次大戦中、ドイツ軍に占領されたフランスを奪還するために、連合軍が作戦を考えるとしよう。その時、側面攻撃しよう、フランスの大西洋岸から上陸だ、だけでは戦略とは呼べない。具体的に、カレーを攻めるのか、ノルマンディーから上がるのか、それとも別の攻略ポイントを探すのか。具体的な地名と、時期と、兵力と、方法がなければ、戦略にならないし、準備もできない。わかるだろう？

「たしかに。」

－－もしも、あなたの会社がチャレンジャーで、差別化戦略を志向するなら、どのような訴求点を持つべきか。どの程度他社を引き離すべきか。それによって得られる金銭的なアドバンテージはいくらぐらいか・・といったことについて仮説を立て、目標設定して、検証していくんだ。

戦略とは仮説だ。「こう戦えば、きっと勝てるはずだ」という仮説だ。だがしばしば、仮説には間違いがある。だから途中途中で検証しながら進む必要がある。人間は誰だって、自分たちが有利であると言う思い込みにとらわれやすく、そこから間違った仮説が生まれやすい。したがって、仮説を文字に残しておくことがとても重要だ。

「でも、方針というのは、いったん書面にすると、仮説どころか、絶対化されやすいですが。」

－－そうだね。だから、3番目に大事なのは、戦いを始める前に、状況を客観的・数値的に分析しておくことになる。たとえばマーケットの戦いならば、敵は誰と誰で、どういった商品を揃えていて、どんな販売チャンネルを抱えているのか。これまでの売上高や、受注確率はどれくらいなのか。顧客はどんなセグメントからなっており、どういう好みを持っているのか。こうしたことを事前に分析しておかなければいけない。

「具体的には、例えばどんなことですか?」

－－そうね。例えば営業における受注競争なら、過去の勝率はどうだったのかという事さ。もしも自社の平均的な勝率が約3割で、今期の受注目標が10億円だったら、最低でも合計33億円以上の可能性のある競争案件を、営業リストに載せなければ、目標は達成できない。また、既存顧客には強いのか、大型の案件には弱いのか、といったことも分析の対象だ。

「それってでも、案件ごとに条件が違うと思います。確率なんか言われても、個別の現場担当として役に立ちません。問題はむしろ、勝敗の質じゃないか、って感じるのですが。」

－－勝敗の質ね。そう言いたい気持ちはわかるよ。でも、あなたは製造業の人だから、あえて尋ねるけれども、じゃあ不良品はモノの質が低く、良品はモノの質が高い、と言えるだろうか。むしろ、検査結果にデコボコがあって、予測し難い点に、問題があるのではないか。つまりモノの質ではなく、プロセスの質を上げるべきではないか。

同じように、個別の戦いの勝ち負けだけが問題なのではなく、勝敗が予見し難いことが問題ではないのか？　そうなると、自社の体制や人材も、前もって適切に準備できないだろう。それはやはり、プロセスの問題なのではないか？

「つまり、事前にもっと計画しておけ、ってことですね。でも、ウチのボスは、『どうせ計画した通りには現実なんか運ばないんだから、計画を立てるなんて時間の無駄だ。現場を見て状況に応じて考えればいい』と、つねに言っています。」

－－もちろん現場を見て考えるのは、いつでも大切だ。しかし、計画抜き・現場判断、というやり方が通用するのは、ごく小さな戦局か、あるいは自社がリーダーで、戦い全体を自分たちの思惑通りに運んでいるときに限る。連合軍がノルマンディーに上陸するか、カレーに上陸するかを、現地を見て決められると思うかい?　上陸する兵士や機材を動員するのに、数カ月はかかる。上陸地点によって、必要な装備も違うだろう。数字に基づいた計画がいるんだ。

第二次大戦の英雄だった米国のアイゼンハワー大統領は、「計画通りに現実は動かない。しかし計画を立てるプロセスは絶対に必要だ」と言っている。君の上司との違いがわかるよね。

「たしかに、違いはありますね。」

－－計画のための情報収集と分析は、分担を分けた方が良い。なぜなら分析は、総合的な情報を集めて行うべき仕事だからね。個別の情報入手した時点で、勝手にローカルな分析を行って解釈した結果を、中央に集めたりするのはあまり良いやり方ではない。データ収集には、必要ならば第三者の知恵を借りることも、するべきだろう。市場調査会社とか、コンサルタント、エージェントといった人たちだ。

そして、戦いの中間の要所要所で、データを集めて状況を分析し、戦略を補正する。ターゲットとすべきセグメントが間違っていることもある。あるいは顧客の要求を読み間違えることだってある。それを一つ一つ、データによって検証する。ときには、撤退を考えなくてはならない場面もある。

前に「マジックナンバー＝5」という話をしたのを覚えているかなあ。対等だと思った勝負に5連敗したら、もう対等だという仮説は捨てたほうがいい、という数学的法則だ。こういう判断は、データを積み上げないと出てこない。

「データを集め、数字から学ぶ、ってことですか。確かに、ウチに一番欠けていたのはそこかもしれません。」

－－そして最後の4番目は、戦いが終わったら、根本原因（Root cause）の分析を行うことだ。Root causeの定義とは、「論理的に見つけられる基本的原因で、かつ、マネジメントによって解決可能であるもの」だ。

表面的に、客が悪いんだとか、運がなかったとか、不況や円高などの環境のせいにしては、いけない。それは自分たちには解決可能でない。だから根本原因に選んではならない。選ぶなら、なぜ客筋をきちんとアセスしなかったのか、なぜ為替リスクのヘッジを怠ったのか、運不運で決まるような案件に、なぜ大きな勝負を賭けたのか、を問題にすべきだ。

「リーダーの責任というのは、どうなるんです？」

－－根本原因分析をするときに気をつけるべき点は、「責任追及の場にしない」ことだよ。もし責任追及が主目的だったら、誰もが自分をかばって、本当のことを言わなくなる。本当のことがわからなかったら、根本原因分析なんて、どんな意味がある？　

根本原因分析の最大の目的は、同じ種類の間違いを繰り返さないこと、つまり再発防止にある。そのために、自分たちの仮説や行動に足りなかった点は、どこかを明らかにする。そして教訓を文字に残す。

敗北などのトラブル事象を、リーダーとか誰かの責任、で説明してしまうと、対策はその人間をポストからはずす、しかなくなる。じゃあ、他の人間をそのポストに据えたら、同種の間違いは決して起きない、と言えるのか？　それに、失敗したら責められる、という組織では、だれが新しい創造的な仕事に挑戦するだろうか。

「ふー。結構大変ですね。とくに、勝負の前にやっておくことが多いですし。・・これ、ウチでやりきれるかなあ。」

－－まあ、わたし自身だって、正直言って、いつも全部はできていなかったさ。ただ、こうすべきだったと思うから、偉そうに聞こえたかもしれないけれど、あえて喋らせてもらった次第だ。

「でも、自分のところは、計画立案能力も弱いし、データ活用も、からきしダメです。片方だけでも大変なのに、両方なんて到底無理かな。」

－－でもないさ。計画とデータ活用は、じつはワンセットの能力だから。

「そうなんですか？」

－－うん。計画を立てない組織には、ちゃんとした「ふり返り」もない。客観的なふり返りを知らない組織は、後で活用するためにデータを蓄積する、と言う姿勢もない。最初に用意しないまま、あとになってからデータを分析しようとするのは、予算も立てずに決算だけするようなものだ。

「その財務の喩えは、よく分かります。計画とふり返りが、データ蓄積の基本なんですね。」

－－計画とは、いいかえれば具体的なアクションの塊だ。そして計画を立てられないようなビジョンは、夢と言う。夢を見ているだけでは、現実は近づかない。

夢に近づきたかったら、まず事実と経験から学ばなければ。たとえそれが、痛い経験であってもね。昔の人も言ったじゃないか、「過ちて学ばざる、これを過ちと言う」ってね。

＜関連エントリ＞

　「失敗の無限ループから抜け出すマジックナンバー『5』」 https://brevis.exblog.jp/15454723/ （2011-09-15）

敗北から何を学ぶか 〜 その1・学ばないための5つの方法

久しぶりに会った年下の知人が、なんだか元気のない顔している。理由を尋ねてみると、数カ月間打ち込んで懸命にやった仕事が、見事にライバル会社にかっさらわれたのだそうだ。勝負に打って出たが、負けてしまった。疲れて意気消沈し、他の事にもあまり手がつかない。気がつくと、失った仕事のあれこれを考え、頭の中が堂々巡りの状態だという。

「まったく参りました。早く忘れて気分を切り替え、次の仕事に取り掛からなければと思うのですが、何か良い方法は無いでしょうか? 」

－－どうだろう。本当に早く忘れるのが一番良いことなのかな。必ずしもそうではないと思うけど。

「なぜですか? 同じところで足踏みしてたって、先には進めません。職場の先輩にもそう言われましたが。」

彼の言葉を聞くまでもなく、職場の皆がそう言いたい気持ちは、もちろんわかる。敗北は早く忘れて、次の一歩を考えろ。Don’t cry over spilt milk. 英語にもそんな感じの諺があるではないか。過去をいつまで振り返っていても仕方がない・・。

だが、それなりの年数、受注ビジネスに従事し、入札にも何回も関わってきた（そして、残念ながら負けた経験も少なくない）わたしは、少しだけ違う意見を持っている。敗北を忘れるためには、その前に、失敗経験からの「学び」を、ちゃんと記録しておく方が有用だ。そんなふうに、最近は考えている。

もっともわたし自身は、この何年間かプロジェクトの現場を離れて、企画部門に働いているので、必ずしも自分があるべきと思う通りに、仕事ができているわけではない。だが、自戒と反省を込めつつ、わたしは彼に答えた。

－－だって、将来、全く同じでは無いかもしれないけれど、似たようなビジネスにまた君の会社がチャレンジしたくなる可能性もあるだろう?　だとしたら、今回の教訓をちゃんと記録して、共有しておいた方が良いはずだ。

「・・うーん、まあそうかもしれません。ただ、自分ではもう二度と御免だ、と言う気持ちですが。」

－－もちろんわかるよ。何も今日すぐに、とは言わない。少し気持ちが落ち着いて、でも具体的なディテールを忘れない内に、早めに取り組むことをお勧めする。

「といっても、一体何を学ぶんですか?　ビジネスは結果が全て。今回は、武運拙く負けた。でも結局、負けは負けじゃないですか。」

（ビジネスは結果が全て。よく聞く言葉だ。勝ちか、負けか。1か0か。確かにそこからは、何も学びようがない。だが本当にそうなのだろうか?）

－－もしもビジネスが、サイコロを転がして、出る目を当てるだけのようなゲームだったら、前回「1」が出ても、今回は何の目が出るか全くわからないのだから、結果からは学びようがないね。じゃあ君も、今回はサイコロのようにまったくの偶然で、勝敗が決まったと言うのかい?

「いや、そうは言いませんよ。ですが、偶然の要素は大きいんじゃないかな。偶然というか、自分ではどうしようもない環境要因ですかね。」

－－なるほど。自分も受注競争に負けた後は、よくそう考えていたものだ。だけどね、ひと月経ち、三月経ち、頭も冷静になってから振り返ると、やはり負けた時は、『負けるべくして負けたのだ』と、考え直すことが多かった。よく、ラッキーによる勝利はあるが、偶然のアンラッキーによる敗北はない、と言われるのは、根拠のないことじゃない。

「でもそれって、論理的に矛盾していませんか?　偶然による+100があるのなら、偶然による− 100もある。そういう風に思えるのですが。」

－－じゃあ、野球の世界で言う『 1点差の負けは、監督の責任』って諺は聞いたことがあるかな。大差で負けた時は、戦力自体に大きな差があるか、あるいは勝敗の大きな流れみたいなものに左右されて、抗いがたい。明らかに自分たちのリソースや、技術や体制に問題がある訳だ。だが、僅差での負けは、ちがう。マネジメントの判断ミスによるものなのだ。

「そうかなぁ。どうしてですか？」

－－どんな勝負事やスポーツでも、チャンスが巡ってくる時というのが、あるだろう?　それも、2つ3つ、続けてやってきたりするものだ。なぜだか知らないけどね、まるでエレベーターみたいに団子になってやってくることが多いのさ。（「なぜエレベーターは（そして仕事も）、一度にまとまって来るのか」 https://brevis.exblog.jp/27699308/ 参照のこと）

「そういうことは、あるかもしれません。」

－－その時に、良い判断ができる監督は、最初のチャンスでうまくアドバンテージを掴んだら、それをさらに次のチャンスで増幅する。ちょうど、賭け金を増やしていくようなものかな。ところが判断の悪い監督は、賭け金を増やすことを怠る。逆に、チャンスを失うと、次の賭け金を増やしたりする。君は、連続するチャンスに上手く乗ることのできる判断能力を持つ人と、一つ一つをバラバラにしか判断しない人と、どちらが、より信頼できる監督だと思う?

「それは、ちゃんと賭け金を増やす判断のできる監督でしょう。」

－－だよね。しかし、負けた直後には、自分ではなかなかわからないものだ。自分自身がその渦中にいて、事態を客観的に見る余裕がないからだ。とくに貴方みたいにリーダーの立場だったら、なおさらだね。しばらく経ってから、ようやく振り返って、やはり負けるべくして負けたのだと悟ることになる。

「うーん。では、どうしたら良いのですか？」

－－そうだね、まず敗北したときの振り返りで、やってはいけないことをあげよう。5つ位あるかな。

• 失敗に学ばない5つの方法
  

まず第一。誰かのせいにしてはいけない。顧客のせいにしてはいけない。上司のせいにしてはいけない。無能な部下や同僚や、勝手な営業のせいにしてはいけない。誰かのせいにした途端、思考がそこで止まってしまう。それでは学びにつながらない。

顧客が馬鹿だった、は禁句にする。賢い顧客なら、貴方の会社が勝ち、馬鹿な顧客だったら、あなた以外の会社が勝つ。もし本当にそうなのだったら、あなたのビジネスモデル自体が、根本から間違っていることになる。

「どうしてですか?」

－－世の中にはね、会社の門前に、いわば見えない行列ができて、その中から自分の好ましい顧客の仕事だけを、選び取って受注していくような会社だって存在するんだよ。貴方がもし、馬鹿な顧客の仕事を取ろうと、ライバル会社と競争しているのだったとしたら、賢い顧客からのみ選ばれるようなビジネスモデルをめざさなければいけない。そうだろう?

「・・反論しにくいですね。」

－－ちなみに、敗北は誰かの責任だと考えて、悪者探しを始める代わりに、全員の気合が足りなかった責任だと考えて、総懺悔するというのも、もちろん学びには通じない。だって、負けるたびに総懺悔しているのであれば、毎回、全く同じ反省内容になってしまうわけだからね。

2番目。敗北に別の名前をつけてはいけない。たとえば、一番極端な例をあげると、戦前の大本営発表のように、敗退を「転戦である」と 言い換えたりする。これも良くない。ひどいときには、戦いなどそもそもなかった、と強弁する。

「もしも負けていないのなら、学ぶ必要など全然ないですものね。」

－－その通りだ。人間は、だれでも心の中に、見てはいけない・触れてはいけないアンタッチャブルな思考停止の領域を持つと、全体として思考能力が低下する状態に陥りやすい。これは断じて避けなければいけない。

3番目は、競争の制度やルールが悪いと批判することだ。

「だめですか。僕は今回、そこのところにけっこう不満があるんですけれども。」

－－競争のルールやあり方そのものに、問題がある場合は結構多いし、それは改善していかないと世の中全体が良くなっていかないよね。しかし不公平なのは、相手側にも同様なんじゃないか。それとも、完全にフェアで公正な競争だったらば、君の会社が必ず勝って、不公平なルールだったら君のライバルが必ず勝つ、と言うようなゲームなのかな？　だとしたら、そんな勝負の土俵に上がらないとビジネスが続けていけないこと自体に、問題があると言えるだろう。

「うーん・・」

－－4番目は、『結果が全てだ』と考えて、途中のプロセスを考えないことだ。勝敗の結果は、すべてプロセスの積み上げによって決まる。野球だってサッカーだって、序盤、中盤、終盤戦があって、それぞれ布陣や作戦を変えるものだ。いや、試合が始まる前から、様々な準備や情報収集がある。ビジネスだって同じだろう?

「そうかもしれません。」

－－これが競争入札なら、顧客の案件察知という準備段階から始まって、顧客要求の理解と読み込み、見積設計、サプライヤーへの引き合い、納期とスケジュールの計画、コスト積算、リスクのレビュー、提案書の作成、魅力あるプレゼンテーション…と言う具合に、様々なステップからなっているプロセスだ。

こうした作業一つ一つを、万全に積み上げてこそ、ようやく勝利が手に入る。このプロセスのどこまでがうまく進んだのか。どこでつまずいたのか。どこら辺から、戦況がおかしくなったのか。それを知ることこそ、次の学びにつながるんじゃないか。

「戦況の変化かあ。潮の変わり目は、たしかにあの辺りだったかもしれないなあ・・」

そして5番目は、敗北後の総括や情報収集を怠ること。客観的で正確な情報把握ができなくては、どんな反省をしても、意味のない無駄なものになってしまうからだ。たとえば入札だったら、技術面と価格面と納期と、どこで負けたのか。競争相手とどんなに開きがあったのか。こうした情報を取ってこなければならない。

ただ現実には、ここが1番難しい。ここは組織の行動習慣（いわばOS）が、問われる部分だ。特に顧客や競合相手の情報収集に対しては、営業部門の力が必要にある。だが、負けた仕事はすぐに忘れて次の仕事にかかるべし、と言う部門方針だと、ここが機能しなくなってしまう。

それと、上位マネジメントの姿勢も大切だね。現場に対して十分な支援をしなかったくせに、末端のリーダーだけ責任を負わせて査定を下げる、みたいな状態で、うまく『学び』が働くわけがない。最初に言ったように、誰かのせいにして終わり、だったら何も学ぶ必要はないのだから。

「・・なるほど。やっちゃいけない、『べからず集』みたいなものは、多少わかりました。じゃぁ具体的に、敗北から学ぶには、何をどうしたらいいのでしょうか?」

（この項つづく）

＜関連エントリ＞

　「トラブル原因分析を、責任追及の場にしてはいけない」 https://brevis.exblog.jp/22555315/ （2014-11-09）

　「なぜエレベーターは（そして仕事も）、一度にまとまって来るのか」 https://brevis.exblog.jp/27699308/ （2018-12-05）

モチベーション重視という名の危険思想

息子がまだ小さかった頃、幼稚園でお泊まり会というのがあった。みんなで先生と一緒に、一晩、幼稚園でお泊まりをする。それだけの行事だ。だが、親元を離れたことがない幼児たちにとっては、一大試練だった。

息子もその日は朝から緊張して、ああだこうだといろんなことを母親に要求していた。でも何とか夕方幼稚園に送り出した。翌朝、夫婦で迎えに行ったら、機嫌よく幼稚園の門から出てきたから、どうやら何とか楽しく過ごせたらしい。

その日の午後には、遠くに引っ越した仲の良い友達・ツーちゃんが、遊びに来てくれた。ひとしきり一緒に遊んであげて、友達を送ってから、わたしは息子に言った。

「ツーちゃんが遊びに来てくれて、よかったね。昨夜お泊まり会で頑張ったからだよ。がんばるとね、きっといいことがあるんだ。」

『頑張れば、必ず良いことがある』－－これは子供が小さいうちに、親が伝えるべき大事な教訓だ。だから、わたしもそうした。

ところで、わたし自身は、この教訓を信じているだろうか?　実は、あまり信じていない。特に「必ず」と言う部分については。世の中には「無駄な頑張り、役に立たない努力」というものもある。今はそう考えている。

例をあげよう。

一番端的な例は、上司や先輩よりも先に帰りにくいために生じる、長時間残業やサービス残業と言うやつだろう。実質的な成果につながらない時間の使い方をしているおかげで、能率は下がるし、疲れは溜まるし、会社は余計なコストを払うことになる。良いことなど一つもない。

まぁもしかすると、上司の覚えめでたく、次の人事評定で少しは良い点を稼げる、という副次的効果があるのかもしれない。でも、部下に無駄な残業を強いるタイプの上司は、人事評価においては、だいたい減点主義者なので、あまり大きな効果は望めないだろうが。

あるいは、競争見積における過剰なコストダウン努力も、見かけることがある。これは見積設計を必要とするような、個別仕様の案件で生じやすい。なるべく安い値段で見積もって、受注競争に勝とうとするあまり、顧客の示した技術条件を、無理に都合よく解釈して、少しでも安く設計しようと努力する。

見積期間は大抵短いから、通常の見積設計だけだって大変なのに、その上さらに無理なコストダウンの工夫をしなければならない。この社会では、お見積は全て無料サービスだから、受注できなければ努力は全て水の泡である。

仮にめでたく受注できたとしても、今度は仕様条件上の解釈をめぐって、発注者との厄介な交渉が待っている。こうしたネゴシエーションは、発注者の言い分の方が、ずっと強い。結局安値で受注したのに、赤字が増える結果に終わる。

競争相手が3社も4社もあったら、自社の受注確率は3割以下だろう。また顧客との関係から見て、有利な競争も不利な競争もある。顧客サイドの情報を収集し、的確な案件の分析を行って、無駄な競争を避けるのが良い営業戦略のはずだ。だが、どんな案件にも等しく「頑張りズム」だけで応じよう、と言う営業部門の態度が、この問題に拍車をかける。

最初に挙げた過剰残業の例は、頑張る行動が、仕事の目的に対してずれているケースである。また、2番目にあげた見積における無理なコストダウンは、大きな見通しや戦略もないまま、現場の頑張りだけで目的を達成しようとするケースを示している。

ところで、払う努力の方向性が、仕事の目的と合っており、かつ、仕事の見通しも立てているのに、努力が報われない場合もあるのだ。それはいわば、仕事における科学法則を知らない、ないし無視した場合に生じる。

次の図は、少し前に書いた記事「EVMSとアーンド・スケジュール法の弱点　～　プロジェクト予測のミクロとマクロ」https://brevis.exblog.jp/28381225/（2019-06-09）で使った、非常にシンプルなプロジェクトのスケジュールの例だ。

例えばこのプロジェクトで、納期を短くするために、サプライヤーと交渉の努力を重ね、25日間かかるハードウェアの納品を、5日短縮して20日間にしたら、どういう結果が生じるだろうか?　もちろん言うまでもない。プロジェクト全体の納期は1日経って短くはならない。なぜならば、ハードウェアの納品は、クリティカル・パス上にないからだ。

もしもプロジェクト全体の納期を短くしたければ、ソフトウェア開発の方をなんとか短縮しなければならない。例えば30日間かかると見積もられているソフト開発のアクティビティーに、人を増員して、期間を短縮する。これが正しい方向の努力だ。無論、それに伴って、余計なコストがかかるかもしれないが。

ただし、この時も考えなければいけないことがある。例えば、ソフト開発の要員を、倍に増員して、30日間かかる作業を半分の15日間に短縮できたとしよう。もちろん人数を倍にしたからといって、単純に期間が半分になるわけは無いのだが、仮にそれが実現したとして、ではプロジェクトの全体期間は15日分減るだろうか。

実は、減らない。なぜならば、その時にはハードの選定と納品の方に、クリティカルパスが移動してしまうからだ。こちらのパスは、現在10日間のフロートをもっている。という事は、ソフト開発の方法を11日以上短縮しても、プロジェクト全体の納期は10日間までしか減らないのだ（これを、「ハード納品のCritical Path Drag値＝10日間である」、と表現する）。

仕事の個別の局面に払う努力と、仕事全体の成果やパフォーマンスの間には、ある種の科学法則が成り立つ。そして、その法則に従って、最も効果的な方策を立てるべきである。ところが、わたし達の社会は、あらゆる局面において、過剰な努力を要求することが、あまりに多い。

わたし達は「報われない努力」というものに、もはや疲れている。長い不況の時代を通じて、疲れきっていると言っても過言では無い。

それはわたし達の社会が、仕事のマネジメントにおける科学法則やテクノロジーを、理解していない、ないし軽視していることから生じている。でも、それを軽視しているのだとしたら、一体何を重視しているのだろうか?

答えは「モチベーション」だ。仕事の成果を上げる最大の方策は、働く人のモチベーションである。－－これが平成の30年間を通じて、日本社会が信じてきた最大の信念であり、イデオロギーではないかと、最近考えるようになった。

この信念は、冒頭に挙げた、「頑張ればきっといいことがある」と言う教訓と、密接にリンクしている。

モチベーションを第一の信条としている人たちの会話はこんなふうに始まる。

「あの仕事だがねえ、どうしたら成果が上がると思うかね？」

「それはやはり、やっている人間のモチベーションから生まれるものでしょう。」

「ふうむ。つまり、責任感をもって取り組んでもらう、という事だね。」

「はい。やはり、ある程度、現場に任せる必要があると思います。」

ここまではまあ、ノーマルな会話である。ただし、この人たちが言っている仕事の成果とは、つまり売上と利益であることが多い。損益計算書の「ボトムライン」である。

それと、「任せる」といっても、現実の企業では、権限移譲は簡単ではない。重要な決定権限（たとえば予算や人事権など）は、ラインの部門長は譲りたくないし、譲れないものである。したがって、仕事を任せるとは、実は「やり方（プロセス）を任せる」と言うケースがほとんどになる。

「まぁ、やり方は自分で考えてもらいましょう。やり方にまで、こちらが口をはさむと、結果に責任感がもてなくなる可能性もありますし。」

「その通りだね。何もかも指示してしまうと、言われたことしかしない、指示待ち人間をつくることになりかねない。」

ということで、責任感を持つことでモチベーションを上げるといっても、そこで言う責任とは、『結果責任』と言うことになる。言い換えれば、

「甘えるな！　結果が全てだ！」

と言う、よく聞くセリフと同じことを言っているのである。

ところで仕事の成果がモチベーション、つまり個人の主観的な頑張りに依存するのだとすると、成果は予見が難しい、ということになる。誰だって、他人の先々の気分までは読み切れないからだ。

したがって、このようなマネジメントスタイルをとっている組織では、売上目標や利益目標は立てるが、その確度は高くないことになる。当然、生産計画や要員計画のベースラインには使えない。そうなると、なるべく固定費になるものは（人も設備も）抱えない。急な変動のリスクは、外注先にヘッジする、という方策をとるしかなくなるだろう。

また、従業員のモチベーションを鼓舞するためには、当然、成果主義の報酬体系を組み入れることになる。頑張れば、その分報われる。逆に頑張らなければ、首切りリストラによる脅威にさらされる。アメとムチである。そして同期や同僚たちの間で競争させる。

かくして、平成を通じて進んできた、三つのトレンド：

・成果主義

・非正規雇用化

・競争原理の導入・強化

は、モチベーション重視という信念からも正当化される。すなわち、年功序列主義からの脱却であり、これを別名、構造改革ともいう。

またモチベーション重視は、主観主義に結びつきやすい。物事の状況判断において、客観的な事実やデータを積み上げる代わりに、自分の側の主観的な解釈や希望によって、対策を考える。何かを試みて、うまくいかなったとしても、それは頑張りが足りなかったのであり、もう一度がんばり直せば今度はきっと成功する。こういう信念が強いと、結局、失敗した経験からレッスンを学ぶことができなくなる。

・・それにしても、ここまでの説明は、日本企業におけるカイゼン文化とPDCAサイクル重視と矛盾していないだろうか？　作業プロセスを標準化し、PDCAサイクルを回して改善を重ねていくことが、マネジメントであると多くの製造業で考えられている。プロセスを標準化することで、誰でも一定の成果を出せるようにする。これがカイゼン文化の思想であった。

そうしたやり方は、とくに繰り返し性の高い業務（量産型工場）にフィットする。だから高度成長期から、昭和の終わり頃までの日本の製造業では、TQCとカイゼン活動が、とてもよく機能したのだ。

しかし、平成の時代に入って増えてきた、個別性の高い業務、クリエーティブな仕事はその限りではない。だって毎回個別なのだから、改善しようがないではないか。そうした状況においては、仕事の成果はモチベーションから生まれる。こう考えるのが自然な成り行きだったろう。そして、総員がその持ち場で全力を尽くせば、良い成果が生まれるはずである・・

わたし達は一体、どこで間違えたのか？

仕事の成果は、関数系で表すと、

　f（人の能力、業務プロセス、モチベーション、環境条件）

といった形になるだろう。仕事の成果は、人の能力と、仕事のやり方(業務プロセス)と、人のモチベーションと、そしてその仕事を取り巻く環境条件の、いずれにも左右される。

関数ｆ(x) は、仕事と成果を結ぶ科学法則だ。それは単なる足し算にはならない事も、しばしばである。

カイゼン文化の思想では、PDCAを回すことがマネジメントであると考える。4つの中では、業務プロセスを重視するといえるだろう。ただし、それは繰り返し性の高い業務でないとあてはめにくい。また、A（改善アクション）は、個人の創意によるものだ。TQC七つ道具などの技法はあれども、肝心の部分は、じつはモチベーションに頼っていたのかもしれない。

では、個別性の高い業務のマネジメントとは、どういう意味なのか？　それは、まず、結果を予見できるように（計画可能に）することである。次に、その業務を、繰り返し可能にすることであるはずだ。そうすれば、皆がお手の物であるPDCAサイクルに接続することができるようになる。そのための技術、マネジメント・テクノロジーの知恵を、皆が共有していく必要がある。

わたし達の社会は、どうやらこちらの視点を、忘れていたように思える。かわりに、モチベーション重視と、科学法則を無視した足し算の論理が闊歩している。モチベーション重視という思想においては、上記の式の4つの項の中で、モチベーションだけが異常にに肥大化している。あとはこれに従属する、と考える。

当たり前だが、モチベーションは仕事において、とても大切な要素である。だれだって、ロボットのように、やりたくもない仕事を無理やり、やらされたくはない。ここで今さらマズローやダニエル・ピンクの議論を紹介するまでもないだろう。だが、それなりに長い平成の時代を通して、成果に結びつかない無駄な頑張りによって、わたし達は大切なモチベーションの感情を浪費してきたように思う。

平成の最初の数年間は、バブル経済の時代だった。あの頃は、環境条件が最大の項目で、相場が上がるかどうか、あるいは東京で家付きの家庭に生まれるかどうかで、人生が決まると皆が信じていた。それが崩壊した後の長い年月、人々が頼るのは、やる気・頑張り・モチベーションだった。

平成が終わって新時代に入った今、できればもう一度、仕事の成果の方程式を眺め直すべきだろう。そして何が一番肝心なのか、全体を一番支配する律速段階は、どこにあるのかを探るべき時が来たように思う。それを理解した時、初めて、わたし達は安心して、子どもに「適切に頑張れば、きっと良いことがある」と教えることができるようになるはずである。

＜関連エントリ＞

　→「EVMSとアーンド・スケジュール法の弱点　～　プロジェクト予測のミクロとマクロ」https://brevis.exblog.jp/28381225/（2019-06-09）

　→「新しい決意と、『今のお気持ち』主義」 https://brevis.exblog.jp/21798589/ （2014-03-18）