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

スマート工場時代の製造部品表（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）

センスのある人と、「カッコいい」で動く人

• 美意識ということ
  

このとろこしばらく、ガラにもなく「美意識」ということについて考えていた。

きっかけは、システム・モデリングである。モデリングという仕事には、サイエンスの部分とアートの部分がある。対象を分析し、その性質や挙動を定量的に推測する部分には、明らかにサイエンスが必要だ。と同時に、良いモデリングの仕事では、モデルのできばえ＝「美しさ」が大切になる。

美しいモデルを発想する部分は、一種のアートである。ちなみに、英語の”Art"は、日本語のアートよりも広い意味を持つ。Artとは、熟練した感覚を要する「技芸」「方法」といった語感である。だから、芸術を意味するときは、あえて"Fine art"という風に限定する。

ともあれ、アートの基本には美意識があるのは間違いない。発達した美意識は大切だ。だが、発達していない美意識というものもあって、それは危険だ——今回は、そんな話になる予定である。

• 真善美と価値基準
  

「真・善・美」は、人間にとっての最大の価値だ、というギリシャ的観念が、西洋には伝統的にある。あえてこの三つを同格に並べる、というところが、とてもギリシャ的だ。少なくともインドや中東など、他の古典文明では見られないのではないか。

西洋の学問の基礎は、この三つに対応して、

　真理を探究する方法：　哲学

　善を実践する方法：　倫理学

　美を追究する方法：　美学

という風になっていると考えられる。この三つの学問はは、知性・実践・感性という、人間の精神が持つ三つの側面に対応する、ということになっている。

（注:　ただし上記の枠組みが確立したのは、近世以降のドイツ観念哲学から、という説明もある）

もちろん真・善・美の三つが、いつでも重なるとは限らない。というか、しばしば重ならないのだ。たとえば、「真実」はつねに美しいとは限らない。また、真実がつねに善であるとも限らない。人はむしろ、真・善・美のうち、どれを取るか、というジレンマに直面しがちだ。

では、人間の決断や行動を決める価値基準は、上記三つが主なものだろうか？

そんなことはない。まず、「損・得」がある。また、「勝ち・負け」もある。この二つも、しばしば両立しがたい。だから、勝ちを譲ってでも、得を取る人がいる。逆に、損をしてでも、勝ちたい人もいる。つまり、この二つの価値軸は独立である（数学的にいえば軸が直交している）。

そしてもちろん、「好き・嫌い」もある。愛憎は紙一重だ（損得や勝敗だって紙一重ではあるが）。好きな相手なら、負けてやってもいい、あるいは損をしてもいい、という判断は、大いにあり得る。こういう人達は、損得より勝ち負けより、『好き』が大事なのだろう。だから、この価値軸も独立している訳だ。

• ビジネスにおける価値基準の優先順位
  

では、上にあげた6種類の価値軸の中で、どれが一番強いのか？　一番上位に来る価値基準はどれか？　もちろん、一貫性などなく、そのときどきなのかもしれない。だが、ある種の傾向を人は持っているものだ。

そりゃあ一番は損得だ、という人も多いだろう。ビジネス界では、それがトップに来るに違いない。何といっても、利益追求が企業のビジネスの最大の目的だ。

ついで、勝ち負けだろう。勝たなければ、利益は得られない。そういう信念を、皆が持っている。Win-winなどという、美しい言葉もあるが、たいていはゼロサムゲームである、と。

そして、経済合理性を追究するのがビジネスである以上、次は知的であること。つまり知性（＝真）が重要である。頭が良いことは、素晴らしいことだ、と。まあ一応、最近はコンプライアンス（＝善）とか環境SDGsとかあるし、実際にはこんな風になっているかも知れない。

　得＞勝＞真＞・・・善＞・・美その他

だが、わたしはこうした通念に、最近疑問を持つようになった。じつは、多くの人は、美意識を第一にして動いているのではないか？　美意識に従う人の特徴を考えると、そう思えてきたのである。

• 美とセンスと『カッコ良さ」
  

美を体験すると、人は視覚・聴覚など五感による感覚への集中が起きる。脳のリソースは、感覚と思考の両方に同時には向けられない。だから、美は一時的な思考停止を導く。美意識を価値観の中心に置く人は、あまり深く考えなくなる。直感で、ぱっと決める。「迷わない」ことは、カッコよさの一つの条件でもある。

では、スティーブ・ジョブズは「考えない人」だったのか？

そうではあるまい。彼は確かに、製品の「美」にこだわる人だった。直感的に行動した人のようにも思える。だが、彼には少なくとも明確な「センスの良さ」があった。

「センス」とは持って生まれるしかないものなのか。いや、センスは磨くこともできるものである。そのために、アーティストは修業時代を過ごすのだ。

クリエーティブな仕事をする人は、磨き抜かれたセンスと、深く考え続ける能力の両方を持っている。ジョブズ自身はデザイナーでもエンジニアでもなかったが、製品のプロデューサーとしてすぐれて創造的だった。

美のクリエーター達が、美意識を行動基準の中心においているのは間違いない。ところで、クリエーションはしないけれど、美を重視するタイプの人もいる。生産者ではなく、いわば消費者として、美を求める人達だ。この人達が大事にする言葉、たよりにする美の形式＝それが「カッコいい」だ。

カッコ良さは、真でも善でもなく、勝ちでも得でもない。あきらかに美の一形式である。ただ、それは消費形式の一種なのだ。

少なからぬ人びとは、自分にセンスがなくても、誰かや何かを「カッコいい！」と感動して、それにひきつけられる。そして「カッコ良さ」を求めて、いろいろな消費行動を起こす。だから企業は商品をカッコ良くしようとするし、消費者がカッコ良さを求めるよう誘導する。「カッコいい」は、美を、思考ではなく欲望に直結させる働きを持つ。

• カッコいい職場、カッコいい職種
  

先日、ある若者と就職について話していたら、彼は、「誰だってトップで超一流の会社に就職したいと思うはずです」という。そして、トップとは「外資系経営コンサルティング会社だ」、と断定するので驚いた。

別に彼にたいして根拠があるわけではない（それほど社会を知ってはいない）。単にそれが「カッコいい」と思って（周囲に影響されて思い込んで）いるらしい。そりゃあ、何もわたしは、自分の勤務先の方が超一流だとかトップだとかいうつもりはない。だが、どうして外資系なのか。

「受験生なら誰もが東大をめざすのと同じだ」、とも彼はいう。この点でもわたしは異論があった。東大が問答無用に一番だ、という見解にわたしは組みしない。だが、かくも単純な価値観の相手と、それ以上議論してもらちがあかないと思い、会話をやめてしまった。

今の世の中では、「外資系」「MBA」「エリート」がカッコいいらしい。たしかに、メディアでももてはやされるのは、その種の人達であることが多い。「マッキンゼー出身」と書いてあると、それだけで発言にオーラがかかるようだ。

企業なら、経営企画部門で、M&Aに携わったりするのがカッコいいらしい。「M&Aアーキテクト」だとか、「シャーク」だとか「毒薬条項」だとか、使う用語もカッコいいではないか。それから「経営戦略」について語るのもカッコいい。強くて、クールなイメージがある。

• カッコいい技術、カッコいい道具
  

AIエンジニアとか、データ・サイエンティストというのも、ちょっとカッコいい。「ウチの会社も、AIを使っています」と語れるとカッコいい、と思っている経営者も案外いるのではないだろうか。だって、データを蓄積して、そこから意味を汲み取らねば、という問題意識を持っている経営者だったら、AIが華々しく登場する以前から、そういうことに取り組んできたはずだと思うからだ。

「最新の」ITツールが好きな人も多い。こういう人達を見分けるのは難しくない。データを読み解くことに関心があるか、それともITツールを使うことが好きか、という点を見れば良い。前者は頭を使うし、地味だし、カッコ良くない。後者はトレンディだ。

そもそも「トレンド」は、カッコいいのである。人と同じ価値観を目指し、少しだけ先を行く、というのがトレンドである。カッコよさは、だから、人を束ねて動かすのにとても便利だ（余談だが、その一番の例が、ファシスト党とナチ党だったように思う）。

企業としては、消費者がみな「カッコいい」で動く人になってもらいたい。皆が似たような価値観だと、ヒット商品が生まれやすくなる。その方が大量生産ですむので、楽である。

• スター的経営者
  

スターという存在は、大衆社会と共に誕生した。「カッコいい」人に、自分を重ね合わせ、自己を投影する。これが大衆のあり方の一面だ。

最近は、スター経営者という存在もある。カッコいい経営者にあこがれる人達は、その人の会社で働く。あるいはそれよりも、起業して、その人みたいな経営者になることを目指す。既存組織の経営陣だって、カッコいい経営者に無意識に影響されているかも知れない。スター企業の、スター経営者のやり方を、無意識に真似るのである。

現在の所、そうしたスターは主に米国が輩出している。経営学者達も、その経営手腕を並んで賞賛する。かくして、米国式の経営手法が蔓延する結果に相成る。その手法とは、M&Aで業容を拡大し、生産は途上国に外部委託し、従業員や自前のR&D投資は切り捨てて利益を出し、自社株買いで株価を維持する、という奴だ。

この路線の先には、大企業とスタートアップだけで、技術に特化した中堅企業が存在しない、という二極分化した社会産業構造ができあがる。流通もサービス業も、ナショナル・チェーン店だけ、という社会である。米国のどこの都市に行っても、ショッピングモールには似たような店舗しか並んでいない。

市井の普通の人が、パン屋や花屋やクリーニング屋さんとして自営で暮らすことができない社会。フランチャイズ店の店長として、実質的には雇われ人になるしかない社会。そういう方向に、わたし達も進みつつある。どうしてこうなったかというと、皆が自分自身の個性を見つけて、それに会った生き方を探る代わりに、「カッコいい」生き方を真似るようになった結果なのだ。

• センスのある人と、「カッコいい」で動く人
  

では、どうしたらここから抜け出せるのか？

じつは、人が美意識で動くからいけない、のではない。むしろ、美意識（センス）が足りないのだ。それが最近のわたしの仮説である。

センスを磨くには、良い教師や先輩による訓練と、ある種の経験の蓄積がいる。センスを磨くことは、落ち着いてよく考えること、繰り返し試行錯誤することの上に育つ。脊髄反射的に「カッコいい」で動くだけでは、センスは伸びない。

センスがある人は個性的である。発達した美意識は、むしろ個性があり、千差万別だ。美というものは、多様性と自由を認める文化的土壌に育つ。

もっとも、集団的に統一された美というのも存在する。どこかの国のマスゲームのように。それはたった一人の美意識の主宰者のために、千人・万人が従属する社会だ。そこから豊穣な美が育つかどうか、わたし達は良く知っている。

ただし、人びとが消費者レベルで個性的でも、それだけでは十分ではない。ビジネスやマネジメントの局面で、同じようにセンスを持ちうるか、という方が重要だ。いくら身につけるファッションが個性的でも、意思決定や部下への指示が無個性では、豊かな結果は生まれまい。

マネジメントという仕事もまた、人間を相手にしているだけに、サイエンス＋アートの両面をもつ。このサイトの主テーマである『マネジメント・テクノロジー』とは、サイエンスの部分を技術化したものだ。

では、マネジメントのセンスを基礎づける美意識とは何だろうか？　そんなものは存在するのだろうか？

• ある美しい国の話
  

こう考えるうちに、わたしは、美意識が重要で、「カッコいい」が公的に市場価値をもつ国を思い出した。昔、そういう国で、1年近くの間、働いていたのだ。

そこは「見る」「見せる」文化で成り立っている。美しい物が好きで、美術品と美食が有名で、たしかに街もそれなりに美しい。

ただ、その国のビジネス界は、じつは米国流経営法をそうとう真似ているように感じられた。ビジネスに従事する人びとも、「エリート」と「庶民」に完全に二分されている。その国には、スタートアップ企業と大企業しかなく、中堅企業があまり存在しない。そして、ライバルの隣国に比べ、長年不景気に苦しんでいる。

つい先日、その国の首都に立ち寄った。街の中心に、その都市の精神を象徴する大きな聖母教会がある。わたしは、そこに詣でて、ある偉人の絵の前にロウソクを捧げるのが、いつも旅の習慣だった。その偉人の名は、聖トマス・アクィナス。南部イタリア出身のこの人は、まことに「深く考える人」だった。彼は言語による「世界というシステムのモデリング」という問題に挑戦した哲学（神学）者だが、その仕事には明確な美意識があったはずだ。

だが、あいにくその教会に、今回は入れなかった。火災が起きて、尖塔と屋根の大部分が焼失したのだ。痛ましい姿に頭を垂れ、この国の人達の心にぽっかり空いた、空洞を思った。教会自体は多くの人の寄付を得て、再建を急いでいる。だが本当に再建が望まれるのは、人を動かし人を使うことに対する、良きセンスの方ではないのか。

そしてそれは、地球の反対側にある島国においても、同様だと思うのである。

「プロジェクト＆プログラム・アナリシス研究部会」（7月25日）開催のお知らせ

「プロジェクト＆プログラム・アナリシス研究部会」の2019年第3回会合を開催いたします。

「頭は使うべきだが、仕事に心を使ってはいけない。」－－昔、ある業界のベテランのプロジェクトマネージャーから聞いた言葉です。最初に聞いた時は、意味がよく分かりませんでした。プロジェクトは人の集団が行う活動です。頭を使うのは当然としても、他人への気遣い・心づかいを忘れたら、チームは円滑に回らないはず。そう、感じたのです。

しかし、その後しばらくして、この言葉は存外深い意味があるのでは、と感じるようになりました。とくにプロジェクトが火を吹いたような時、顧客との困難な交渉、社内外との調整、そしてストレスやら過剰な心配やらで、心身がへとへとになり、物事に機械的な応対しかできない状態に陥ります。「心がすり減った」としか言いようのない気分になるのです。

そんな時に、社会学者・石川准氏の著書「見えないものと見えるもの」（医学書院）で『感情労働』という概念を知り、衝撃を受けました。世の中の労働は、知的労働と肉体労働に分けられる－－そう信じてきた自分には、全く見えていなかったカテゴリーの労働があり、それが感情労働だというのです。たとえば看護師の仕事がその典型で、感情というリソースを活用・消耗する仕事であり、過剰になると心が「すり減って」しまうのだ、と。たまたま同じ時期、欧州のPM研究で「社会構築主義」が話題になっていたのですが（「知識労働、肉体労働、そして『感情労働』」記事参照）、こちらでも感情の社会学が関心を呼んでいました。

そこで今回は、静岡県立大学教授・兼・東京大学先端科学技術研究センター特任教授である石川准氏をお招きして、感情労働についてお話いただきます。ちなみに石川氏は、目が不自由でありながら初めて東大に入った方で、だから著書のタイトルは非常に象徴的でもあります。

多くの人が感情をすり減らしながら毎日働いているように見える今日、感情のあり方について、社会学の観点から見直す機会になると思います。大勢の皆様のご来聴をお待ちしております。

＜記＞

■日時：2019年7月25日（木）　18：30～20：30

■場所：田町キャンパスイノベーションセンター　

　5F スペース：509AB

　（いつもの慶応大学三田キャンパスとは場所が違いますのでご注意下さい！

　　JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です）

　　http://www.cictokyo.jp/access.html

■講演タイトル：

「感情労働とは何か」

■概要：

　感情を社会学というツールを用いて分析すると、感情規則、感情管理、感情労働といった概念が浮かび上がってくる。

　こうした基本概念を説明しつつ、感情規則の多様化、感情労働の高度化・広範化といった今日的な状況の中で、公的および私的領域における協同作業や他者理解の困難について考えたい。

■講師：石川 准（いしかわ じゅん）

　静岡県立大学教授

　東京大学先端科学技術研究センター特任教授

■講師略歴：

　1981年 - 東京大学文学部 卒業

　1987年 - 東京大学大学院 社会学研究科博士課程 単位取得退学（社会学博士）

　1997年 - 静岡県立大学 国際関係学部 教授

　2012年 - 内閣府障害者政策委員会 委員長

　2015年 - 東京大学先端科学技術研究センター 特任教授

<研究テーマ>

●社会学分野　　存在証明、アイデンティティ・ポリティクス、障害学 (disability studies)、アクセシビリティ、感情労働

●支援工学分野　自動点訳・ スクリーンリーダー・点字携帯端末・移動支援機器の開発

<主な社会活動 >

国連障害者権利委員会 副委員長、内閣府障害者政策委員会 委員長

<著書・訳書>

『見えないものと見えるもの』医学書院　2004

『障害学への招待』明石書店 1999

『アイデンティティ・ゲーム：存在証明の社会学』新評論 1992

『管理される心：感情が商品になるとき』世界思想社 2000 ＝Arlie R. Hochschild, 1983, The Managed Heart, The University of California Press

■参加費用：無料。

　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥1,000）は免除されます。

　参加を希望される方は、確認のため、できましたら前日までに三好副幹事(miyoshi_j@kensetsu-eng.co.jp)までご連絡ください。

　以上、よろしくお願いいたします。

佐藤知一＠日揮（株）

EVMSとアーンド・スケジュール法の弱点 ～ プロジェクト予測のミクロとマクロ

前回の記事から2週間ほど間が空いてしまった。先週から欧州で、製造業系と石油ガス業界系の二つのカンファレンスに立て続けに参加していて、サイトの記事を書く時間がなかなか取れなかったのだ。最初の会議では、わたしの勤務先で最近つくった、2030年の未来を見据えた長期的な「IT Grand Plan 2030」(https://www.jgc.com/jp/news/assets/pdf/20181218_1.pdf)の講演発表もした。それなりに一応、好評だったと思う。

ところで、こういう国際カンファレンスに来るといつも思うのだが、欧米人はハイ・レベルな概念論が大の得意だ（ここでいうHigh levelとは、もちろん「高級品の話」ではなく、視点が高い＝抽象的という意味である）。たとえばDigital transformationだとか、Ecosystemだとか、Sustainabilityとか、彼らの好きな言葉がある。一種の流行言葉でバズ・ワードであるが、彼らは自分のプレゼンで、必ずと言っていいほど、自分なりにその内容を言葉で定義する。その定義が皆と共通であれば、もっと良いと彼らは考えている。だから標準化だとかBOK（知識体系）とかが好きなのだろう。

ところが、そういう講演を聞いていると、どうしてもわたし達のような日本のエンジニアは、「だけど具体的にはどうなの？」という風につっこんで聞きたくなる。ある程度の具体性、現実味がないと、なんだか綿飴を噛んでいるような、歯ごたえのなさを感じてしまう。逆にいえば日本の技術者の発表は、えてしていきなりディテールに入りすぎるきらいがある。

ハイ・レベルで抽象度の高い議論と、ディテールにこだわる議論。その両方が必要なのは言うまでもない。その優先度がどちらにあるべきかで、洋の東西は意見が微妙に分かれている。もっとも、一口に「欧米」といったってアメリカと欧州は違うし、ヨーロッパだって南北でずいぶん違うのは事実だ。でも、日本との隔たりは非常に大きい。西洋人はとにかく、マクロに物事をとらえたがる。

さて、最近注目の「アーンド・スケジュール」という手法は、EVMS（Earned value management system）から派生した新しい手法である。EVMSがもつ、これまでのスケジュール把握における問題点、とくに完了日予測に関する困難を解決しようと工夫した点に、特徴がある。これが前回まで2回続きの記事で書いたことだった。ところが、アーンド・スケジュール法にも弱点がある。それが、スケジュール把握におけるマクロとミクロに関係しているのである。

例を挙げよう（つまり、数式で抽象的に説明するより、具体的なディテールを提示したほうが、読者にもわたし自身にも分かりやすいからだ）。

下の図は、あるプロジェクトの構造を図示したものだ。システム開発系のプロジェクトだが、WBSはかなり簡潔化してあり、わずか6個のActivityから構成している。図はそのActivity間の順序関係を示した「ロジック・ネットワーク」で、いわゆるprecedence diagram形式になっている。この図の見方については、ずいぶん以前に書いた記事「納期が延びる要因を指標化する　－　スケジュールのDRAGとはどんな尺度か」 https://brevis.exblog.jp/20000432/ （2013-03-25）を参照してほしい（ただし、以前の記事の図とは、意図的にいくつか数字を変えているので注意されたい）。

このプロジェクトは基本設計で始まるが、その後、二つの並行する経路に分かれる。それがハードの調達系と、ソフトの開発系である。両者は総合テストで合流する。クリティカル・パスは、下側のソフト開発系にある。上側のハード調達系は、図中の四角の左上に示されるES（Earliest start＝最早開始日）と、左下のLS（Latest start=最遅開始日）の数値に、10日分の差がある。これは、このアクティビティ系列に10日のFloat日数（余裕日数）があることを示している。

Float日数を持つアクティビティは、いつ開始するべきかについて、自由度がある。たとえば「ハード選定」は、最早開始日ES＝20日だが、最遅開始日LS=30日だ。これを見て、プロマネのあなただったらどうするだろうか？　基本設計が終わったら、間髪を入れず、すぐにハード発注作業をする？　だが、この作業は実稼働日で10日（つまりカレンダーでは半月ほど）余裕があるのだ。だったら、基本設計に続く詳細設計をまずちゃんとまとめて、それからハード発注に頭を切り替えても遅くはあるまい。

そういう前提で作業のシーケンスを考えると、それぞれの計画上の予定完了日と、その時点までの出費PVは、下の表1のようになるだろう。全体期間は75日。ちょうど中ごろの35日目に、累積のPVは250万円になる。

[表1　予定の出費(PV)]

さて。実際にプロジェクトを進めていくと、（いつものことだが）設計上の問題が生じてしまった。10日で終わるはずの詳細設計の冒頭に手戻りが発生し、15日くらいかかりそうな状況だ。あなたの上司は（あるいは顧客でもいいが）、プロジェクトの週次レポートで、累積の出来高（EV値）が予定通り上がっていくかを、チェックしている。このままでは遅れが出て、あなたは叱責されかねない。

そこであなたは考えをかえ、詳細設計が終わってからやるつもりだった「ハード発注」を、基本設計後に前倒しして並列に行うことにした。おかげで25日目にハード発注は完了。「詳細設計」は遅れて35日目に完了した（実績を示す表2では、アクティビティの完了日の順序が、上の表と一部逆転しているので注意してほしい）。35日目の時点で、出来高EV値＝250万円だ。PV=EVだから、つまり「アーンド・スケジュール」ES(t)＝35日、ということになる。万歳、プロジェクトは遅れていないのだ！

[表2　実際の出来高(EV)]

本当だろうか？

もちろん、間違っている。「詳細設計」はクリティカル・パス上のアクティビティなのだ。だから、この完了が5日遅れたら、プロジェクト全体の納期が確実に5日遅れてしまう。まあ、あなたがプログラマを余計動員して、ソフト開発の所用期間を5日以上短縮できれば別だが、そのためには余計にコストがかかるはずだ。（詳細設計の工数が増えたのだから、プロジェクトはすでに予定より赤字になっているが、それがさらに増えかねない訳だ）

いかがだろうか。アーンド・スケジュール法による進捗コントロールの、どこがおかしいのだろうか？　アーンド・スケジュール法の論理も計算自体も、間違ってはいない。だが、明らかに、プロジェクトの遅れの検出に失敗しているのだ。

それはもちろん、アーンド・スケジュール法が、マクロなEVやES(t)の値しか見ていないことに原因がある。ロジック・ネットワークが示すように、プロジェクトの完成予定日は、クリティカル・パスの長さで決まる。それは、ネットワークの構造をミクロに見なければ、分からないのだ。この例は簡略化してあるので、6つしかアクティビティが無いから、よく見れば誰でもおかしい点が理解できる。

だがアクティビティが100個も200個もあったら、ネットワークをたどっていくのは大変だ。だからEVやES(t)などのマクロな指標で見よう、という気持ちはわからないでもない。でも、EVやES(t)は、それまでに完了した全てのアクティビティの合計指標だ。この中には、クリティカルな作業もそうでないものも、ともに含まれている。だから、たとえクリティカル・パスの作業が遅れても、フロートのある作業を前倒しで進めることで、見かけ上、進捗率を上げることができるのである。

別の言い方をすると、コスト視点とスケジュール視点では、アクティビティの「重要度」の尺度が異なるから、こういう事が起こる。スケジュールでは、クリティカル・パス上のアクティビティは、たとえ予算が小さくても重要だ。だが、EVMSでは予算（コスト）でしか重みをつけないから、スケジュール差異を正しく検知できないのだ。

ミクロを積み上げても、マクロにならない。マクロに良さそうに見えても、ミクロにはおかしい場合がある。これが『システム』というものの基本的性質だ。

プロジェクトは、アクティビティのネットワークで構成される、典型的なシステムである。そして、人が重要な役割を担い、また外乱的な変動にもさらされる、ひどく複雑なシステムでもある。この複雑さを、まだ適正なレベルで、うまく予測しハンドリングできる理論はできていない、というのが現時点でのわたしの感覚だ。

最初に述べた、わたしの勤務先の「IT Grand Plan 2030」では、プロジェクトという目に見えない対象のデジタル・ツィン＝『Project Digital Twin』という概念の実現を目標にしている。デジタル・ツィンであるから、その上でシミュレーションができる必要がある。

しかし、現状のEVMSも、クリティカル・パス法も、その意味ではまだ、単純にすぎる。何より、決定論的すぎるという限界がある。シミュレーションを行って、プロジェクトの完了日や完成コストの予測をしようにも、一点しか答えが出てこない。台風の進路を予測して、一本しか線が描かれないようなものだ。現実のプロジェクトとは、もっとブレがあって、そのリスクとどう戦うかが一番大事なのに。

そして本物のプロジェクトは時々、崩壊現象を起こす。だからプロジェクトのシミュレーションも、ちゃんと崩壊現象を再現できなければならない。今のPERT/CPMやEVMSの、どこをどうひねくっても、崩壊現象など出てこない。

その意味で、わたしは今のプロジェクト・マネジメント理論にはまだ、『第一原理』が欠けていると思っている。材料物性を研究している人達は、量子力学の波動方程式という第一原理から出発して、マクロな多体問題を解き、物性を推算している。だが、不確実性をはらむプロジェクトの予測をするための基礎方程式は、どんな形をしているのだろうか？　

わたし達の旅路は、まだ始まったばかりである。

＜関連エントリ＞

　→「プロジェクトの進捗を計る『アーンド・スケジュール法』とは何か 〜 その内容と課題」 https://brevis.exblog.jp/28339485/ （2019-05-26）

　→「納期が延びる要因を指標化する　－　スケジュールのDRAGとはどんな尺度か」https://brevis.exblog.jp/20000432/ （2013-03-25）