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

PMBOK Guideに欠けている、３つの重要事項

春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。

PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにすぎない。よくまとまっているが、あまり書かれていない部分、足りない部分もある。

たとえば、プロジェクトの類型論である。これがないのは、けっこう痛い。古今東西、すべてのプロジェクトが同じ一つの道具立てでマネージできる訳ではない。数ある技法やプロセスの、どれを使うべきか、どれが自分のプロジェクトにあっているのかを、判断する具体的な基準が、PMBOKには書いていない。

最初に読んだときから感じているのだが、PMBOK Guideには、無意識に前提されていることが一つある。それは、プロジェクトが比較的「固い」スコープをもって出発する、との前提である。そこで、SOW（Statement of Work＝作業範囲記述書）を初期インプットとして、プロマネがProject Charter（＝PMBOK日本語版では「プロジェクト憲章」と訳されている）をまず作る、といった作業プロセスが規定される。Charterはさらに、プロジェクト・マネジメント計画書のインプットとなり、その中でWBSが展開される・・と続く。SOWは、まさにプロジェクトの出発点である。

では、そのSOWなるものは、どこから来るのか？　プロマネが受け取るのだから、プロジェクト・チームの外部から、ポンと来るわけだ。解説書などを読むと、プロジェクトの成果を利用する組織が作る、と書いてある。社内利用なら、内部のsponsoring organizationが、また外部顧客の利用なら、顧客から来る、と。だとすると、自動車の新車開発プロジェクトでは、まだ見ぬ顧客からSOWが届くのだろうか？

種明かしをしよう。SOWは、プロジェクトの発注者から来るのである。米国PMIで初期のPMBOK Guideをつくった人たちの多くは、防衛産業・航空宇宙産業やエンジニアリング産業の出身だった。彼らにとって、プロジェクトとは受注型のビジネスであり、「何を作るべきか」は発注者（国防総省とか石油メジャーとか）が決めるものであった。そして（少なくとも米国においては）国の機関や大企業は、自分達の要求事項は事細かに、紙に書いて入札を行うのだ。それは業界によってITBとかRFQとかいろいろな名前で呼ばれるが、抽象化してStatement of Workと呼ぶことにしたのだろう。

初期のPMBOK Guideにおいては、プロジェクトとは受注型であり、かつ明確なスコープから出発するものだ、という無意識の前提があった。だから、エンジニアリング業界に身を置くわたしのような者が読むと、なんだか似たような業種の匂いがぷんぷん感じられた。ただし、プロジェクトには自社が決めて行う、自発型のものもあるし、PMBOK Guideが標準である以上、それにも適用可能な記述でなければならない。だから、「社内利用の場合はsponsoring organizationがSOWをつくる」といった、なんだか無理の多い話になるのである。新車は誰が利用するものだろうか？

PMBOK Guideがもう一つ、無意識に前提したことがあった。それは、プロジェクトは複雑で大型の営為である、という感覚である。これも、防衛宇宙産業やエンジニアリング産業からみれば当然のことであった。大規模プロジェクトの場合、必然的に、「計画」「契約」そして「計数管理」が大切になる。わたしはこれを、プロジェクト・マネージャーの3Kと呼んでいる。この三つが、プロマネの仕事をひどく大変にするのだ。また、受注型プロジェクトではたいてい、コスト制約・スケジュール制約が厳しい。したがってプロマネに、より強い権限を与えるような組織体勢が望まれる。

ところで、世の中には自発型のプロジェクトもある。新製品開発がその典型だ。あるいは、イノベーティブな技術開発とか、自社向けの業務システム開発などもそうだろう。こちらは、ふつうスコープが柔かい。コスト制約よりも、プロジェクト価値の最大化がねらいになる。そこで、品質（とくに設計の品質）が重要になる。このような種類のプロジェクトに、計画・契約・計数管理を持ち込んでプロマネに権限を集中し、ギリギリやっても、あまり楽しい結果が出てきそうにない。別の種類のマネジメント技法が望まれるのだ。

これに関連して思うのは、PMBOK Guideに設計論がない、ということである。なぜ、10個の知識エリアには、『設計のマネジメント』が入っていないのか？　プロジェクトが独自の製品・サービスを生み出すための有期性の業務であるなら、必ずその中には設計業務があるはずではないか。その設計のあり方、良し悪しが、その後のプロジェクトを大きく左右する。ヘマな設計をすると、作りにくく、時間がかかり、コストもかさむ。

設計によって、その後の段取りや作業が全く変わることも多い。3階建ての建物を作るとき、鉄骨造で設計するのと、木造2X4（ツーバイフォー）で考えるのでは、工法や要員や作業手順が全く変わる。それどころか、力学的構造が全く異なるので、建築デザインの見た目も、大きく異なる。それくらい、設計段階の意思決定は重要なのだ。

なのに、PMの知識エリアには品質やコストはあれど、「設計」がない。設計抜きで、構築（製造・実装・建設）だけがプロマネの仕事、という観念は奇妙である。え？　設計は分野ごとに個別性が高いから、Guideに書くのは適当ではない？　だが、そもそも、分野ごとに個別性が高いのがプロジェクトの特性であろう。それでも、共通なプロセスを考えることは十分可能なはずだ。

その一例が、システムズ・エンジニアリング分野から発した「V字モデル」である。これは対象がシステムであれば、人工衛星であろうがワープロソフトだろうが共通に当てはまる。また、「エンジニアリング・マネジメント」という言葉は、日本ではプラント業界くらいしかお目にかからないが、米国にはEngineering Managementを教える専門学科だって存在する。だったらなぜ、PM論の中に、設計マネジメントがないのか？

なお、ここで問題にしているのは「プロジェクトのデザイン」（＝WBSをどう作るか）の話ではない。また、製品デザイン（＝美大を出たデザイナー達が行う仕事）だけの話でもない。エンジニア達の普通の仕事としての「設計論」である。

現在のPMBOKに設計論が欠けている理由は、わたしの想像であるが、おそらく米国における分離発注の商慣習にあったのではないか、と思われる。つまり、

　「基本設計」の段階　→（見積と競争入札）→　「構築プロジェクト」（実装・製造・建設）の段階

の二段階に、発注を分離する、という商慣習である。たとえば建築業界では、20世紀前半から、「建築設計」→「施工」が別々の主体で、別契約になることが一般的だった（少なくとも英米では）。プラント業界でも、80年代頃には、「基本設計」（FEED）→「詳細設計・調達・建設」（EPC）が別になるのが一般化した。防衛宇宙産業のことはよく知らないのだが、米国政府発注なので、似たような分離発注形式をとっていたのではないか。

前段の基本設計において、かなり詳細な（＝コスト見積が可能なレベルの）仕様書を作成しておき、契約書の雛形も用意しておく。競争入札を経て、後段の構築プロジェクトに入る。そしてPMBOK Guideを作った初期の人たちは、構築プロジェクトにもっぱら携わる業界人だった。だから、プロジェクトの最初にSOWがあるのは、彼らにとって当たり前だったのだ。そして、設計の主要な部分はもう終わっているのだから、知識エリアに設計マネジメントは入らなかった、と。

ところで、これが本当だとすると、IT業界にとってはいささか気の毒なことだった。なぜなら、SIプロジェクトの分野で、「要件定義」→「設計・実装」が別フェーズとして分離するのは、もっと遅かったからだ。ソフトウェア開発プロジェクトでは、一般に要件定義が「柔らかい」（固めにくい）ため、設計・実装のスコープも柔らかくなってしまう。そして、IT系プロジェクトの難しさのかなりの部分は、このスコープの曖昧さから生まれるからだ。

おそらく、初期のPMBOKコミュニティには、IT業界の人が少なかったのではないか。そして、少し後になってから、PMが注目されるようになった（日本での普及期は2000年台に入ってからだ）。そして、PMBOK Guideを学ぶことが推奨された。だがPMBOKが無意識に前提するハード型の一括発注契約を、ソフト型であるIT開発プロジェクトに適用したことが、多少の無理を生んだのではないかと想像される。

そして、この不足を補うべく、BA（ビジネス・アナリスト）の実務標準を最近になって付け加えたのだろう。設計（とくに基本設計）が、プロジェクトにおいて重要だと、あらためて皆が痛感したからである。

ちなみに、IIBAの「ビジネスアナリシス知識体系ガイド (BABOKガイド)」https://amzn.to/2OQvnMF などを読んでいると、同じような設計マネジメントのアプローチが、IT以外の分野でも必要だし有効だ、と気づく。ただ、BABOK自体、Version 3.0になってずいぶん良くなったが、まだ発展途上だという印象が強い。デザイン思考がIT分野で注目を集めている今日、もっと設計論は必要だと思う。

さて、PMBOK Guideに書いておいてほしかった第3のポイントは、プロジェクトの評価論（価値論）である。

プロジェクト・マネジメントの最大の仕事は、決断することだ。決断とは、複数の選択肢から、最も良いと信ずるものを選ぶことである。だが、最も良いとは、どういう意味か？

プロジェクト・マネージャーの責務とは、プロジェクトの価値を最大化することだ、とも言える。それがプロマネの査定、成績表になるはずである。では、プロジェクトの価値とはいったい何か？　スコープ・コスト・スケジュールの制約条件（「鉄の三角形」）を守ることだろうか？　それとも、成果物のもたらす顧客満足なりベネフィットを最大化することか？

もし後者だとしたら、じゃあ、「ちゃんと作ったけれど、使われないシステム」の価値はどうなるのだろうか？　わたし自身も過去にそういうものを作った苦い経験があるから書くのだけれど、その場合、プロマネの点数は落第点となるのか。たとえば、ユーザが旧来の仕事のやり方を変えることに抵抗したら？　それはプロマネの責任範囲なのだろうか。

あるいは、逆に、あえて機能とスコープを増やしたおかげで、予算を超過し納期も遅れたが、顧客が喜んで使ってくれるようなシステムを作るのは、是か非か？　つまり、プロジェクトの価値とは、成果物（アウトプット）で評価するのか、アウトカムで評価すべきなのか。これが決まらないと、プロマネは判断できないではないか。だが、こうした価値論が、現在のPMBOK Guideには欠けている。

多くのプロマネは、しばしば二律背反のトレードオフに直面するものだ。外注先は、価格の安さを取るか品質を取るか。計画では、コストを取るか、スケジュールを取るか。目標設定では、リスクを取ってでも、リターン（利益）の最大化を狙うべきか？　こうしたトレードオフについて、ある程度までは、出発時のミッション・プロファイリングとCharterで、判断基準の優先度を事前定義できる。だが、プロジェクトの途上で起きる全ての判断パターンを、事前に定義できる訳もない。

ところで、PMBOK Guideには価値論がないが、モダンPM論の世界に、全く欠けている訳ではないことは、知っておくべきだ。英国の商務省が開発した標準の中には、「Management of Value」（略称MoV）という標準書がある。現在はAXELOSという会社が版権を所有している。内容をざっと知りたければ、たとえば下記のSlideShareをみるといいと思う。

AXELOS - MoV® - Management of Value - Foundation

https://www.slideshare.net/miroslawdabrowski/axelos-mov-management-of-value-foundation-en-instructor-presentation

このMoVでは、Valueという尺度を、次式で定義している。

つまり、単にベネフィット（便益）を最大化しても、それに投入する資源（コスト等）がむやみに増えてしまったら、全体としてはプロジェクトの価値が下がるのだ。この定義式は概念的なもので、必ずしも定量化に向いている訳ではないが、一つのわかりやすい表現ではある。そして、こういう議論は、とても欧州のPM論に特徴的だな、とわたしは感じる。欧州のPM研究では、プロジェクトのスコープを所与のものとして扱わず、より大きな社会的文脈の中で評価しようという視点が強いからだ。

類型論、設計論、価値論－－この三つを、今後のPMBOK Guideはもう少し盛り込んで欲しいと、わたしは思っている。念のためにいっておくが、わたしは別にPMBOK Guideを批判したり否定している訳ではない。ただ、それが完璧な教科書だと信じて、鵜呑みにしないようにしよう、と主張しているだけだ。

前にも書いたが、教科書を暗記しすぎる人は、プロジェクト・マネージャーには向かない。PMBOKというのは、署名にもある通り、Guideである。ガイドなのだから、皆、自分自身で考え、自分の足で山に登っていく必要があるのだ。

＜関連エントリ＞

　→「プロジェクトのスコープには硬軟がある」 https://brevis.exblog.jp/27558796/ （2018-09-20）

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

お知らせ：「化学工学」誌に論文『ディスクリート・ケミカル工場の生産システムを考える 』が掲載されました

「化学工学」誌の2019年4月号に、わたしの論文『ディスクリート・ケミカル工場の生産システムを考える』が掲載されました。

化学工学、という学問名称には馴染みのない方も多いかもしれません。これは化学プラントの設計論を研究する工学で、19世紀の終わり頃から急速に発達した分野です。

英語ではChemical Engineeringと呼び、Mechanical Engineering（機械工学）とか、Electrical Engineering（電気工学）などと並んで、かなりメジャーな技術の一つです。ただ、戦前日本に輸入された際、英語を直訳したため、一つの学問名称の中に「学」が2回登場するという奇妙なことになりました（似たような例は、他に「科学哲学」がありますが）。

「化学工学」誌は、文字どおり化学工学会の学会誌です。以前は紙媒体のみでしたが、現在はWeb化されており、2019年4月号は下記のURLから閲覧ができます。

〔目次〕

http://scej.org/k/83/04/

わたしの「ディスクリート・ケミカル工場の生産システムを考える」は、以下の場所です：

http://scej.org/k/83/04/0222.pdf

なお、わたしの論文にある次の図が、今月号の表紙を飾っています。

ただし本サイトの読者は、学会員でないためアクセスできない方がほとんどだと思いますので、少しだけ説明します。この図は、一般的なシステムにおける二種類のアーキテクチャーを示しています。上が、密結合された「インテグラルなシステム」、下が、疎結合な「モジュラーな集合体」です。

システムとは一般に、「目的を成し遂げるため、相互に作用する要素（element）を組み合わせたもの」と定義されます（国際システム工学協会INCOSEによる定義）。その意味で携帯電話もシステムですし、自動車もコンピュータもシステムです。

そして工場も、システムの一種です。ただ、その要素に、働く人も含まれている点に特徴があります。工場を設計するとは、単に機械や建物の設計図を書くだけではなく、機械と人と建物とITからなる、複雑なシステムを設計することに他なりません。

ところで日本では、化学・石油などいわゆるプロセス産業の生産設備を「プラント」と呼び、自動車や家電製品などを作る場所を「工場」と呼ぶならわしになっています。英語ではどちらもPlantなのですが、日本では別物だと思われています。実際、外見もずいぶん違います。前者は屋外にあって配管が縦横無尽に走っており、後者は建物の中にあって工作機械やコンベヤと人が並んでいる、と。

たしかにその通りなのですが、じつは両者の最大の違いは、システムとしてのアーキテクチャーの違いにあるのです。いわゆるプロセス産業のプラントは、密結合された「インテグラルなシステム」であり、他方、組立加工系産業（ディスクリート型ともいいます）の工場は、「モジュラーな工程の集合体」になっています。

そして、このようなアーキテクチャーの最大の違いは、その運転（操業）のあり方に現れます。いわゆるプラントでは、「中央制御室」があって、そこから工場内の主要な工程は全てモニタリングされ、決定されています。ところが組立加工系の工場にはそうした仕組みが一般になく、現場の各工程が分散的に意思決定をするようになっています。

（なお、正確にはプロセス系とディスクリート系の間には、その混合的な性格を持つ「切替型連続生産」という形態がありますが、ここでは省きます。興味がある方は拙著『革新的生産スケジューリング入門』をごらんください）

わたしの論文では、このようなアーキテクチャーの差異が、じつは扱うマテリアルが流体か固体かという、単純な違いに起因することを明らかにします。この差は、さらに工場の設計方法（手順）にも大きな影響を及ぼします。インテグラルなシステムであるプラントでは、化学工学の一領域である「プロセスシステム工学」が最初に全体を設計し、ついで機械装置や配管・計装など要素の設計に進みます。ところがディスクリート系の工場は、こうした流れが確立しておらず、機械設計と建築設計が独立して平行に進んだりします。

ところで日本の化学産業は、近年、エチレンなどの基礎原料（バルクケミカル）から、機能性素材などの製品に利益の源泉が移っています。機能性素材の多くは個体のハンドリングが要求され、ディスクリート系の性質を強く持っています。したがって最近の化学工場は、両者の特性を併せ持つ「ディスクリート・ケミカル工場」ともいうべき存在になっており、その設計論は新たな進展が要求されている、というのが論文の骨子です。

ここまでなら、たぶん化学産業以外の人には、さほど興味ない話題だと思います。事実、わたしは2006年に『ディスクリート・ケミカル工場』の概念を、化学工学会の展望講演で発表し、このサイトにも関連記事を書いたのですが、ほとんど反応はありませんでした。

ところが最近になって、ここにIoTという注目の技術が登場します。IoTとセンシング技術は、従来モジュラー型でしか設計し得なかった組立加工系の工場を、インテグラルなシステムに変える潜在的可能性を持っています。この可能性に早くから着目したのが、ドイツの「インダストリー4.0」構想でした。

ただ、あいにく日本では、ただ単体の機械にセンサーをつけてデータ解析するだけの、部分的な「スマート化」としか理解されませんでした。そもそも、システムのアーキテクチャー、といったシステム工学の概念が、工場設計（生産技術）の分野で希薄だったのです。それに追い打ちをかけたのは、リーマンショック以来の生産技術部門の弱体化でした。

わたしが昨年来、「次世代スマート工場」のエンジニアリングに関する研究会組織を立ち上げて活動しているのは、そういった背景があるのです。このまま日本の工場作りの弱体化を見過ごすべきではない、という気持ちを、エンジニアリング業界の人間として、強く感じています。

この「化学工学」誌の特集『プロセス産業のスマート化への挑戦』には、他にも東芝（前Siemens）の島田太郎氏による「プロセス業界におけるIndustrie4.0」をはじめ、注目すべき解説論文が並んでいます。ご興味のある方は、ぜひ読まれることをお勧めします。

＜関連エントリ＞

　→「ディスクリート・ケミカル産業」 https://brevis.exblog.jp/3240905/ （2006-04-17）

　→「ディスクリート・ケミカル工場を設計する」 https://brevis.exblog.jp/3304091/ （2006-04-26）

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

　→「『インテグレーター不在』という深い谷間」 https://brevis.exblog.jp/27172645/ （2018-04-01

パン屋問題の解決、または中小製造業の生き残る道

あなたは町のパン屋さんである。以前は都会でエンジニアとして働いていたのだが、やむを得ぬ事情で郷里のパン屋を継ぐことになった。店は昔ながらの商店街にあり、店の奥では職人が小さな工場（こうば）でパンを焼いている。ところで、地域のチェーンストアからサンドイッチ製造の仕事を依頼されたのだが、受けてみたら大変な仕事だった・・という事情までは、前々回の記事「下請け型受注生産という日本的形態を考える」https://brevis.exblog.jp/28051644/ に書いた通りだ。

何が大変かって？　チェーンストアは、コンビニの向こうを張って、いわゆる「JIT納品」（ジャスト・イン・タイム納品）を要求してくる。1日4回、FAXで注文が来て、2時間以内に納品しなければいけない。おまけに製造後6時間以内の品であること、という鮮度指定もついている。ところが注文を受けてからカツを揚げてサンドイッチを作っていては、2時間の納期に間に合わないのだ。

したがって、あなたはやむなく1日のはじめに、見込みで数量を決めてカツを揚げ、食パンやその他の具を用意させることにした。ちなみにFAXの注文は、朝8時・10時・12時・午後2時に来る。納期はそれぞれ2時間後だ。だが朝8時にサンドイッチを作り始めては間に合わない。だからあなたは6時半すぎには店に出て、指示を出すようにしている。パン屋だから、朝早いのは慣れて来た。しかし、朝の見込みと現実とが違って、その日の売れ行きが良すぎると途中で足りなくなり、逆に売れ行きが良くないと売れ残りが生じてしまう。

普通の町のパン屋だって、もちろん売れ残りは頭痛の種なのだ。だから閉店間際になると値下げして、なんとか売り切ろうとする。しかし、チェーン店向けのサンドイッチは、プラスチック包装も専用だし、具の肉や野菜もそのチェーンから仕入れるので、自分の店で勝手に売ってはいけない契約になっている。結局、見込み違いが起きると、結構な数のサンドイッチを捨てることになる（家族やパートが引き取って食べたりするが、量はしれている）。食べ物を捨てるのは胸が痛むし、じつは自分のお金を捨てている訳なので、財布も痛む。

何とか解決できないものかと、あなたは考えてみる。

問題は、サンドイッチの製造に着手してから納品までの生産リードタイムが、納期の2時間より長いことにある。そう気づいたあなたは、リードタイムの内訳、すなわち各工程に必要な時間を、代表的なロット数量である60食分について調べた。結果は次のようになった：

カツの調理（75分）　→サンドイッチに具をはさみ袋に入れる（45分）　→出荷輸送（30分）

リードタイムの合計は、2時間半である。他に、チーズや野菜類の具もあるのだが、やはりカツが一番時間がかかっている。食パンの方は、学校給食用などもあり、もたくさん焼いているのでネックになることはない。

自社の生産能力不足を外注で補うような器用な真似は、この小さな町ではできない。また、人や設備能力を増やして製造のリードタイムを短縮するには限界がある。具をはさむ作業は、人を増やせば短縮できるだろう。人を3倍に増やせば、計算上は45分が15分に縮まって、リードタイムの2時間に収まる勘定だが、そんな短時間だけのパートはありえない。他方、カツの調理は、肉を解凍して衣をつけて揚げる作業なので、解凍時間や揚げる時間にしばられる。人を増やしても短縮効果は小さい。

顧客の要求納期は2時間だ。だとしたら、具（カツ）とパンを、前回の記事で解説した「カップリングポイント」の在庫理論にしたがい、ストック在庫しておけば、いいことになる。製品にまで作ってストックする必要はなかったのだ。そうすれば、受注から納品までのリードタイムは1時間15分に縮まる。注文を受けたら、カツをはさんで出荷する。出荷した分のカツを、並行して揚げて補充する。

では、どれくらいのストック在庫量が必要なのだろうか？

需要が毎日8時間で240食なら、およそ平均2分のポアソン到着になるのだろう。平均値＝60のポアソン分布の標準偏差は、平均値の平方根だから、だいたい8弱だ。形は正規分布に近いはずだし、欠品の危険率を2.5%とすると、安全在庫数量はその1.96倍とればいいから、16食、という計算かな？　元エンジニアのあなたは、昔取った杵柄で、暗算で考えてみる。つまり、60+16=76食の基準在庫量を維持すればいいのか。

いや、これではダメなのだ。そもそもサンドイッチの需要は日中の波が明確にあって、単純なポアソン分布は当てはまるまい。それに夕方、76食が在庫に残っても、それは捨てるしかないのだ。あなたは首を振る。在庫に有効期限がある場合、あまり需要に近い下流に在庫ポイントを置くのは、危険である（それは、前回記事で述べた「はなまるうどん」の事例も、暗示している）。

どうしようか。このままでは、多忙なばかりで、利益は出ない。店の改修もおぼつかない。

いや、待てよ。チェーンストアとの契約では、「サンドイッチは作ってから6時間以内」となっている。別に、「カツを揚げてから6時間」とは、規定していないじゃないか。前日の夕方揚げたカツを、翌朝パンにはさんで出荷して、何がいけないのか。衛生管理はちゃんとしていて、たいして傷む訳でもない。客も気がつくまい。そうだ。そうしよう・・

その時、下の娘が店に来て、目の前で売れ残りのサンドイッチを厨房から持っていった。もう食べ盛りなのだ。そして、あなたは、はっと我に返った。自分の娘に、18時間前に揚げたカツをパンにはさんで、新品だといって食べさせるだろうか？　お弁当に持って行かせるだろうか？　自分なら、しない。だったらなぜ、顧客なら構わないと思ったのか。

危ないところだった。あやうく、パン屋の魂を失うところだった。ちゃんとしたものを売る−−そこが作り手の最低限の誇りじゃないか。あなたは前職の会社で、ある大手サプライヤーの品質問題で迷惑を被ったことを思い出していた。自分の会社よりもずっと大企業のサプライヤーだったが、品質記録を偽装していたのだ。おかげで膨大な出荷マスタを、端から全部チェックさせられるはめになった。

品質欠陥で、顧客に実質的な損害はあたえていない、とその会社は弁解していた。そうかもしれない。だが、このところ何年間も、似たようなニュースが繰り返し報じられている。そのほとんどは、「納期のために品質を犠牲にした」ケースだったのを、あなたは思い出した。今は、その裏にある事情を、少しだけ理解できたような気がする。だが、その結果、失ったものは何だったか。

それは「学び」の能力なのだ。品質の記録は、PDCAの基礎である。品質データが事実でなければ、改善のサイクルなど回せるはずがない。すると、日本企業が一番得意としたはずの、現場改善が回らなくなり、現場が事実から学んで成長することができなくなる。それは、会社が成長を放棄することなのだ。だったら、パン屋の経営者のあなたは、別の方策を考えなければいけない。

カツの形での在庫は無理だ。だが、パン粉をつけて、揚げる直前の形で冷凍しておくのだったら、品質劣化の心配は、はるかに少ないと思いついた。揚げ物の時間は、鍋の大きさ（面積）がネックだ。そこであなたは、ガス台と鍋をもう一台ずつ増やし、倍の量を一気に揚げさせることにした。油きりのバットも増やした。かかる時間は、45分。こうして、かろうじて注文から2時間で納品できるようになった。野菜の在庫ロスのリスクは残るが、目をつぶろう。

もっとも、いったん解凍した肉を再度冷凍すると、香りや歯ごたえが少しだけ失われる。だがそこはもう、客の判断に委ねるしかない。これで売れ行きが落ちたら、この仕事からは撤退しよう。そう覚悟しながら、でも、あなたは売れ行きを見届けたくて、納入先のチェーンストアをそっと訪れてみた。一番近い店舗は、歩いて10分のところにある。

昼前から夕方まで、サンドイッチ売り場の棚を行きつ戻りつ、客のふりをしながら横目でじっと観察した。そして、そのうち気づいたことがあった。お昼のピーク需要は短期的で、11時半過ぎから1時ごろまである。だが夕方は、4時（これが最後の納品だった）から、7時ごろまで、少しずつダラダラと売れて行くのだった。そして最後にストアは値引きして、サンドイッチを売り切ってしまう。

だとしたら、4時の納品は、分納させてもらってもいいのではないか。これがあなたの思いついたことだった。たとえば50個の注文が来たとする。それを、4時に25個、5時に25個、分けて納入させてもらう。それでもストアの商品が欠品することはないはずだ。もしこれが可能なら、最後のロットだけは、3時間のリードタイムがあるから、確定受注生産が可能になる。それにより、ストック在庫量のレベルをギリギリまで下げられるはずだ。

あなたはチェーンストアの仕入れ係に、ダメ元で交渉してみることにした・・

＊　＊　＊

今回のシリーズの記事で、読者諸賢に、パン屋問題の解決方法を募集したところ、大勢の方からご意見を頂戴しました。まずは何より、深く感謝いたします。そして、似たようなシチュエーションにある方が結構いらっしゃることにも、あらためて驚きました。

もとより、この問題にきちんとした正解があるわけではありません。上に述べたストーリーは、単に一つの例です。そもそも、工程別の時間などの詳細なデータを書かなかったので、具体的に考えようがないじゃないか、と憤然とした方もおられたでしょう。その点についてはお詫び申し上げます。

いただいた案のすべてはスペースの制約上記載できませんが、素晴らしいと感じた指摘のいくつかをご紹介します。

「カツを、あらかじめ揚げる直前の状態まで作って冷凍で持っておく」というアイデアをご提示いただいたのは、中小製造業経営者の庄司さんです。また匿名の方（「素人パン屋」さん）からも、同じく「揚げる前までまとめて加工し、冷凍保管」とのコメントをいただきました。これは、上述のわたしの案と同じです。

前回のうどん屋の事例をご教示いただいた愛知県の江藤様からは、「2段階のストック在庫を設置する」、すなわち「日々の需要変動に追従するのは難しいが，週・数日単位では平準化される」という視点から、在庫ポイントの活用策があるはずとというメールを頂戴しました。加えて、「保存技術に投資することで，カップリングポイントをよりゴール付近に持っていくなどが将来の打ち手」とされています。これはわたしの思いつかなかった、優れたアイデアだと思います。

これらはいずれも、在庫の持ち方の工夫による問題解決です。

先ほどの庄司さんは、さらに、「スーパーの要求種類をそのまま作るのでなく、特別メニューを開発して、そればっかり注文が入るようになれば、生産や廃棄量も自社で調節できるようになる」とも書かれています。これは、匿名の方（「素人権限なしマネージャー」さん）の「チェーンストアとの間で、味を最終的に決める調味料とパッケージ以外を、店頭販売で使用できるよう交渉します。」という提案にも通じますね。特定顧客仕様という前提をはずせば、たしかに『下請け型受注生産』から卒業できるようになります。

チェーンストアとの交渉という点では、井上様（製造業勤務）から「早期に納期と数量の確定注文を出してもらった場合、何％OFFにするといった『早割』サービスを提案」との面白い案をいただきました。関連しますが、製造業OBの西牟田様からは、「小さな約束ごとを積み重ねるているうちに、発注元がこけたり

ミスしたりします。その時に、短い自社のリードタイムを活かして（もしくは、短納期飛び込み）で、相手を助けてあげると、以降はこちらの希望もある程度聞き入れられるようになります。」とのアドバイスも頂戴しました。

ちなみに上に引用した庄司さんは、自社では「一人を多能工化して、終段の追加工は全部できるようにし、メインの製造を撹乱しないようにします」と書かれています。これは一種のATOによる短納期化の工夫です。

知人の経営コンサルタント・本間さんからは、（下請け型受注生産という）「日本型ATOに追い込まれている背景には、内示という商慣習問題があるように思います。コンサル先には、必ず内示精度を分析するように伝えます」という指摘をいただきました。トヨタ式の内示については、記事「Pushで計画し、Pullで調整する」 https://brevis.exblog.jp/21721306/ にも書きましたが、精度と計画に対するコミットメントが重要です。

予測精度については、片本様（製造業）から、「需要予測をストア側と二重で行うのではなく、パン屋側に取込み一本化したい。精度向上のためPOSデータをもらい、2時間のオーダーロットを可能な限りリアルタイム化する」との案をいただきました。さらに、匿名の方（「Y.U」さん）は、「チェーン内での需要見込みの共有を提案」とコメントされています。

わたし自身は、この指摘は非常に重要と考えています。というのも、結局この問題は、需要予測の精度の低さを、JIT納品という形で、サプライヤーにおしつけた点から発生しているのです。である以上、パン屋の主人がやったように、店頭の売れ行きを実際に共有した上で、次の予測を立てていく方が合理的だと思うからです。

すでに米国では30年も前に、小売のウォールマートと製造のP&G社が、在庫のかさばる紙おむつ「パンパース」の販売データを共有することで、合計10週間分あった流通在庫を、3週間分まで削減することに成功しました。これがQuick Response運動として、SCM改革の原型となったのです。このエピソードは20年前に共著で発刊した『サプライチェーン・マネジメントがわかる本』 でも、中村実氏が紹介しましたが、残念ながらバブル崩壊後の日本では、馬の耳に念仏だったように感じます。

JIT納品に関しては、先の本間峰一氏が、「むしろ発注元の企業の方が在庫を持って変動をカバーし、発注先の中小企業には平準化した量を作らせる方が、サプライチェーン全体ではコストが安くなるはず」と、かねてから提案されています。卓見だと思います。安定した計画生産ならばサプライヤーの品質も保てるし、実需要に近く財務体質の強い側がストック在庫を持つというのは、理にかなっています。

しかし、元の問いに戻りましょう。それは、「このことに気づいた貴方は、どうすべきなのか？」でした。

＊　＊　＊

それで、もしも貴方が、この国の製造産業政策の根幹を担う立場の方だとしたら、ぜひともこの問題を是正するために、どういった施策が有効なのか考えて欲しい。すでにこの国の中小製造業が疲弊していることは、周知の通りだ。そして大企業のメーカー達も、近年とみに不祥事が頻出し、経営がおかしくなってきている。大企業は従来、下請けに寄りかかって身を支えてきたのだが、下請けの納期問題や廃業等で、もはやそれが通用しにくくなっているのだ。早く手を打たないと、危ない。

あるいは、かりに貴方が生産工学や経営学の研究者だったら、このような生産形態がどれほど広く行われているのか、ぜひとも実態調査を行って欲しい。こうした調査は、わたしのような会社勤めの人間が、片手間でできることではない。明らかにアカデミアの仕事である。そして、それを政策立案者と共有していただきたい。正確な統計調査と事実把握こそ、良い政策立案の基礎だからだ。

実は昨年から政府は、EBPM（Evidence-based Policymaking＝「証拠に基づく政策立案」を、中央省庁の全ての歳出分野に適用することを決めている。逆にいうならば、事実と証拠がなければ、政策は変わらないのだ。

（https://www.cao.go.jp/others/kichou/ebpm/pdf/ebpm_houshin.pdf　参照）

こうした生産形態の調査研究が、科研費を取りやすいかどうか、また論文誌にのりやすいかどうかは知らないが、この国の急務であろう。ぜひ、よろしくお願いしたい。

あるいは、貴方が多くの下請けを使う製造業の経営者だったら。まあ、そんな方がこのサイトを読んでいる可能性は微塵もないと思うが（笑）、その場合、ぜひとも自社がJIT納品の旗印のもとに、需給リスクを下請け企業にヘッジしていないか、調べて欲しい。そして、むやみにトヨタの真似をしてJIT生産を導入しても、自社のサプライチェーン特性に合わない場合が多いばかりか、むしろ製造現場が混乱疲弊するばかりだ、という認識を持っていただきたい。そして、それを財界の中で広めてほしい。

さて。産業政策の枢要を担う訳でもなく、アカデミアの俊英でもなく、経済界の重鎮でもない、読者諸賢は、どうしたらいいのか。つまり、筆者のこのわたしと同様、世に号令をかける立場でない人間は、どうすべきなのか？　

なかなか難問だ。この問題の解決は、アメリカの経営書を探しても載っていない。ただ、一つ言えることがある。それは、「このパン屋の問題は、パン屋だけでは解決できないし、するべきでもない」という認識を、世に広めることだろう。そうなのだ。無理な生産形態は、無理な大手のリスクヘッジが生み出したものだ。そして、一つだけ確かなことがある。

世の中で、無理は決して長くは続かないのだ。

戦略としての生産形態 － リードタイムを設計する

前回の記事 https://brevis.exblog.jp/28051644/ では、「下請け型受注生産」とも呼ぶべき生産形態が存在し、それは特定顧客仕様の製品を、需要を見込んで生産する形態だ、と書いた。このような生産形態は普通の生産管理の教科書には出てこないが、わたし達の社会では、案外広く見られる。特に、大手セットメーカーが、「JIT納品」をサプライヤーに要求する場合、部品メーカー側はこの形態を強いられることが多い。

そして、このような生産形態は、サプライチェーンの需給ミスマッチのリスクを、経営基盤の弱い中小下請けに背負わせるうようなやり方であり、この国の産業構造の見えない弱点になっている、とも述べた。この指摘は、なぜか意外と多くの読者の注意を引いたようで、驚いている（というのも、似たようなことは10年以上前から、書いてきたつもりだからだ）。

では、どうしたらよいのか？

そもそも「下請け型受注生産」の形態が生じる最大の理由は、「顧客の要求する納期が、自社の生産リードタイムよりも明らかに短い」ことに起因する。

だったら答えは明瞭だ。生産リードタイムを短縮すればいいのだ。

前回の記事で、パン屋の主人であるあなたの悩みは、FAXで注文を受けてから2時間後に納品しなければならないのに、サンドイッチを作るのに2時間以上かかることだった。もし、これが2時間以内だったら、悩みは基本的に解決する。

でも、どうやってリードタイムを短くすればいいのか？

えーと、その前にここで注意を一点ほど。「リードタイム」という言葉は、しばしば漫然と使われている。だが、リードタイムにはいくつもの種類があり、どれを指しているのか明確にしないと、誤解が生じる。生産リードタイムと、納入リードタイムは違う。そのことについて、すでに書いたはずだ。と思って探したら、やっぱり解説があるじゃないか。なんて役に立つサイトだろう（笑）

　「リードタイムとは何か」 https://brevis.exblog.jp/7376582/ （2008-02-27）

ついでにこちらの記事も読んでおいてほしい。こちらは12年前に書いたものだ。

　「購買リードタイムとは何か？」 https://brevis.exblog.jp/6006346/　（2007-07-01）

さて、生産のリードタイムを短縮する方策として、たいていの場合思いつくのは、以下の4つだろう。

(1) 能力オーバーの分を外注に出す

(2) 機械化を進めて生産性を上げる

(3) 人を増やす

(4) あらかじめ作りだめしておく

では、これらを一つ一つ検討してみよう。

ただしこの先は、論点を分かりやすくするため、6時間の鮮度指定の制約を、いったん外して考えよう。つまり機械部品などのように、作ったら1週間でも1ヶ月でも、置いておけるとするのである。

納期対策として、まず誰もが思いつくのは、(1)外注化である。需要のピーク時に、自社の生産能力が追いつかない場合、外注化して量をさばくやり方は、従来から多くの製造業で行われてきた。外注するかどうかを生産管理部門が決める場合もあるが、製造現場が自分たちの判断で、一部を外注化してしまうケースも、実際には見かける。あるいは飲料業界のように、季節性が高いため、製造委託業が広く行われてきたところもある。

しかし、外注化はじつは両刃の剣である。社内で作れる製品を外注化すれば、当然ながら自社の粗付加価値（つまり利幅）は薄くなる。それに昨今、どこも空雑巾を絞るような人減らしと設備廃棄をしてきた後の、降って湧いたような人手不足状態である。製造能力を持て余している工場など、それほどない。おまけに、あなたのパン屋のケースについていうと、日中わずかの時間帯だけサンドイッチ製造を引き受けて欲しい、という要望だ。小さな町で引受け手を見つけるのは無理だろう。

余談だが、工場の余剰能力を、UberやAir B&Bみたいに気軽に取引できるようにするべきだ、という議論もある。可能ならば、それはそれで結構であろう。だが、小口の製造委託を受けるとは、言いかえれば納期を確約することを意味する。そうでなければ、誰が頼むだろうか？　だが、自分の工場でさえ受注オーダーの正確な納期回答が難しいのに、よその工場では確約できるはずだと考える根拠は、一体何か。

昨今、結構大手の企業においても、納期問題や品質問題が多発しているが、その多くの部分が、サプライヤーや外注先に由来しているようだ。大手企業が従来のように、下請けの納期をコントロールできなくなっているのだ。いや、もっとはっきり言おう。従来は大手の無理難題を聞き入れてくれた下請けが、もう応えられません、という状況になってきている。そのあおりを受けて、大手の社内でも生産スケジュールが混乱する。混乱すれば、結果は品質にはね返る。

かつてのような、能力ピークをしのぐための外注化は、簡単にできなくなった。では、自社内でどこまで作れるか、どう判断すべきか。製造の実態は、ITシステムを見てもわからず、実は現場の班長と毎日書き換えるExcelだより、という状況下では、適切な外注判断はとても難しい。

この問題は結局、自社の生産能力を正確に把握することが困難である、という根本原因から生じている。これ以上は話が長くなるから深入りしないが、多品種を扱っている工場では、どこも納期確約は難しいのだ。タクシーやホテルみたいな調子では、工場の能力はなかなかB2B取引できないことを知っておいてほしい。

では、二番目の方策はどうか。すなわち機械化である。もっと大きなパン屋なら、それもあるだろうな、とあなたは思う。しかしサンドイッチに具をはさむ機械とか、ビニール袋でラップして段ボール箱にしまうロボットとか、本当にあるのだろうか？　たとえあったとしても、品目が増えたり、レシピが変わったりしたら、自分で設定を直せるだろうか。

店のパン焼き職人は、もっと大型の食パン専用焼き窯が欲しい、とも言っていた。だが、パンを焼く速度が全体を律しているとは思えない。それに、学校給食が減っているのに、食パンだけ能力増強するのも、アンバランスではないか。機械化による生産性向上は、量産型のところでないと、なかなか功を奏さない気がする。

それなら、(3)人を増やす、という古典的な対策は？　まあこれは人手不足の昨今、容易でないことはご承知の通りだ。それに、いったん人を雇ったら、すぐに首は切れない。でも、景気も需要も変動しがちである。人を増やせばリードタイムを短縮して、余計な製品在庫を抱えるリスクを減らせるが、その代わり不稼働な余剰人員（リソース）を抱えるリスクを増やすことになる。実はリスクが姿を変えただけである。

この問題があるから、過去25年間の不況の間、企業は正規従業員数を増やしたがらず、パートや季節工など、人数の増減がしやすい雇用形態へシフトしてきた。特に今世紀に入ってからはその傾向が加速し、派遣労働に頼る割合が増えた。つまりリソースを変動費扱いできるような状況を、企業経営者は求めてきたのである。

だがその結果、今度は労働者の側に、いつ仕事を失うか分からない、というリスクとなった現れた。「メーカーの在庫リスク」→「下請けの余剰人員リスク」→「労働者の雇用リスク」、という風に、リスクが姿を変えながら、より弱い立場に転嫁されてきたことが分かる。そればかりか、低賃金で不安定な雇用条件の人口が千万人単位で増加し、総需要が減って、ものの売れない状況が、ますますが固定化してしまった。

まあそれはさておき、今時、パートでさえ確保は困難だ。おまけにあなたのパン屋さんの場合、1日の中でも昼前が一番忙しく、午後は暇になって、ピーク人数だけでは考えにくい。家族を手伝わせるのも限界がある。

ということで、どうも答えは、(4)「需要を見込んであらかじめ作りだめしておく」、しかないように思えてくる。実際、下請け型受注生産を強いられている部品材料メーカーの中には、顧客納入先の近くに倉庫を借りて、作りだめした製品をストックして置く企業も、それなりに存在する。注文を受けたら、そこから出荷する。中には、サプライヤー同士で共同倉庫を運営しているところさえある。

だが、そんな非効率な形態はやめたいから、解決策を考えているのだ。とはいえ、何を、どこまで作りだめしておいたらいいのか？　いろんな段階の部品も製品も、全部作りだめしておくのか？

ここに、『カップリングポイント』という重要な概念が登場する。

図を見てほしい（この図は2015年に書いた記事「「すべての製造業は受注生産かつ見込生産である」 https://brevis.exblog.jp/23904094/ の再掲である）。生産を始めてから終わるまでの工程が、一列に並んでいる。ところで、各生産工程に要する時間を合計した総リードタイムは、顧客の要求するリードタイムよりも長い。これが問題の根源なのだ。

問題を解決するためには、出荷からさかのぼって、要求リードタイムよりも長い上流側（図の左側）の部分を、あらかじめ計画的に作っておくしかない。そして、途中まで製造した中間部品ないしサブアッシーを、在庫としてストックしておくのである。顧客から確定注文が入ったら、そのストック在庫から出発して、残る右側の工程を粛々と進めていく。このような在庫点を、カップリングポイントと呼ぶ（APICSの用語ではCODP = Customer order decoupling point）。

カップリングポイントの左側、上流側は需要予測に基づく計画生産になる。そして右側、下流側は、確定受注にひもづいた受注生産である。つまり、このような生産形態は、見込み生産と繰返し受注生産を、カップリングポイントで接合した形である。いわばハイブリッド型の生産形態といえよう。カップリングポイント以外の在庫は、できれば減らすほうがいい。

もちろん、上の図は直鎖的な工程だけを描いたが、実際には複数部品を組み合わせるケースも多いだろう。また多品種で共通する資材もあるだろうから、カップリングポイントの設定は、それなりに複雑である。また、カップリングポイントのストック在庫量の適正値はどう決めるか、という問題もある。ただ、こうした細部については、今回は割愛しよう。

なお、カップリングポイントを持つハイブリッド型生産形態とは、全体としてATO（Assemble-to-order）ではないかという疑問をお持ちの方もあるだろう。確かに似ているが、厳密には少し違う。米国生産・在庫管理協会APICSは、ONBOK第3版でATOをこう定義している：

（拙訳）「ATOの形態では、製品は、顧客の注文を受けた後に、部品から組み立てられる。組立工程ないし最終工程に使うキー部品類は、あらかじめ顧客の注文を想定して計画生産し在庫しておく。注文を受けたら、組立を開始する。オプション選択の組合せによって製品に多くのバリエーションがあり得るが、共通部品の組立てで製造可能な場合に、この戦略は有効である。」

（参考）APICS Operations Management Body of Knowledge Framework, Third Edition 4.2節

http://www.apics.org/ebusiness/apics-for-individuals/apics-magazine-home/resources/ombok/apics-ombok-framework-table-of-contents/apics-ombok-framework-4.2

つまり、ATOとは、カップリングポイントをできるだけ下流側に引きつけて、注文を受けたら一気呵成に組立出荷する形態であり、かつ、多数の製品バリエーションを実現する工夫でもある。

ところで、逆に考えると、カップリングポイントをどこに置くかによって、あなたの会社は納入リードタイムを設計できる、ということだ。ポイントを極力、下流側（図の右側）に置いて、注文から出荷までを短くし、短納期を競争力にすることもできる。ただしその場合、最終需要に近い中間部品をストックすることになるから、在庫の陳腐化リスクも高まる。

逆に、カップリングポイントを上流側（左側）に置けば、注文から納入までのリードタイムは長くなるが、より共通性の高い基礎的な部品材料をストックするだけで済むため、おそらく在庫リスクは小さくなる。また、在庫ポイントは普通、自社で持つから、それ以降は内製が基本だ。内製する部分が多くなれば、それだけ利益も、粗付加価値額も高まるだろう。

このように、自社の強み・訴求点をどこに持つかに応じて、どのような納期を設計し、どこまでを内製化するかが決まる。つまり、自社の生産形態というのは、すぐれて戦略的な決定事項なのである。

この概念を説明するのに、わたしは以前からうなぎ屋のたとえを使ってきた。しかし最近、愛知県の江藤様という読者の方から、大変素晴らしい事例を教えていただいたので、簡単にご紹介させていただきたい。それは、うどん屋チェーンのケースである。

うどん屋は、顧客の注文を受けてから作る、繰返し受注生産である。そのチェーンの代表が、「丸亀製麺」と「はなまるうどん」だ。ところでこの両社は、実は異なる戦略を取っている、というのである。

（写真は江藤様の資料より引用）

「丸亀製麺」は、小麦、野菜などはすべて素材形状のままで在庫し、店内で麺打ちから調理し販売する。他方、「はなまるうどん」では、麺や揚げ物はすべて別の工場（セントラルキッチン）で調理したものを使い、店舗では最終の茹で、揚げを行うのみである。

「丸亀製麺」は、麺や汁を計画生産してカップリングポイントとし、揚げ物や茹でなどは受注生産する、ハイブリッド型形態である。ただ、注文を受けてから具を作るので、リードタイムが長い。それをカバーするため、大勢のリソースを厨房に使う。顧客に手作りかつ出来立てのうどんを提供できるのが特徴だ。

逆に「はなまるうどん」は下流側にストック在庫持つことで、短い納品リードタイムを実現している。つまり受注組立生産(ATO)に近い。そして少ないリソース、狭い店内で顧客要求に対応できる。このように、両者には一長一短がある。肝心の味に関しては、両派ともに言い分があろう。

うどんは多品種的な商品だし、それを組み合わせで実現できるから、はなまるのATOは一応、理にかなっているように見える。しかし、よく考えてみると、カップリングポイントが最終需要に近いため、需要の読みが正確でないと、在庫ロスが生じやすい。またセントラルキッチンからの輸送時間・コストもかかる。出店はセントラルキッチンと一緒に計画する必要があるため、面で出店計画を考えざるを得ない。丸亀製麺なら、店舗を個別に増やすことが可能だ。

では、両者の業績はどうなのか。その比較は、以下の通りだ。

丸亀製麺　　　　2018年3月期：　904億円、利益140億円（利益率15.5%）　792店舗

はなまるうどん　2018年2月期：　306億円、利益　6.7億円（利益率2.2%）　458店舗

この二つの会社は、ほぼ同じ時期（2000年）に一号店を出店した。だが、今や差は歴然としている。この差がすべて、上記の生産形態に関する違いから生まれたかどうかは、定かではない。ただ、現時点までを見ると、丸亀製麺の方が上をいっている。おそらく、より的確な戦略を繰り出せたのだろう。

生産形態というのは、製造業にとって、非常に重要な戦略なのである。それは、よくよく考えてデザインすべきだ。それなのに、過去の経緯に引きずられて、漫然と決めている企業が多すぎるように思う。それは単純に「もったいない」のである。わたし達の社会には、技術も現場も、優秀な人には事欠かない。しかし、会社全体・サプライチェーン全体を見た戦略が、足りないのだ。戦略の欠落を、なんとか戦術で補おうと、真面目な人たちが苦心惨憺している。それは本当に、人の使い方が「もったいない」のである。

＜関連エントリ＞

カップリング・ポイント

　→「工場計画論(5)　ＢＴＯと製品アーキテクチャー」 https://brevis.exblog.jp/12306818/ （2010-03-14）

デリバリーの設計とCODP

　→「すべての製造業は受注生産かつ見込生産である」 https://brevis.exblog.jp/23904094/ （2015-11-25）

（追記）

あなたのパン屋の場合も、うどん屋のように、在庫の賞味期限（鮮度指定）の問題がある。だからサンドイッチという製品で在庫するのは、もちろん得策ではない。でも、部品であるカツやパンだって、期限がある。こちらはさらに難問である。読者の皆さんだったら、どうアドバイスされるだろうか？　たまには双方向で、議論して見みたいと思うので、メールでもコメント欄でもいいから、解決策を書いてみていただけると幸いである。

下請け型受注生産という日本的形態を考える

あなたは、小さなパン屋の社長さんだ。町の商店街に店をかまえ、店の奥には小さいながらパン焼き工場（こうば）に職人も抱えている。店の売り場は、親族が受け持つ。実はあなたは少し前まで、都会でエンジニアをしていたのだが、やむを得ない事情で、郷里のパン屋を引き継ぐことになったのだ。

店を引き継いだ時は、赤字経営だと税理士さんから聞かされた。御多分に洩れず、地方都市の商店街は地盤沈下で客足が遠のき、売上の柱だった小中学校の給食パンも、少子化で減っていた。パン作りについては素人で何の知識もないが、ただ、あなたは一応、会社勤めで得たビジネス・センスを、多少は持っている。何とか頑張って、店や雇い人たちを盛り立て、まだ経営は低空飛行ながら、ようやく収支トントンのところまで持ち直した。

そんなあなたのところに、面白そうな商談が舞い込んできた。その地方のチェーンストアの店舗に、サンドイッチを納めないか、というのだ。あなたが人脈づくりのために顔を出した商工会で、昔の同窓生を経由して、そんな話が来たのだ。早速、先方と会って話を聞いてみる。

そのストアでは、コンビニに対抗してお弁当お惣菜コーナーをもうけ、そこにサンドイッチも置く計画だ。サンドイッチは、毎日250食以上が見込める、という。そのかわり、コンビニ並みに、JIT納品の方針である、と伝えられた（JITはジャスト・イン・タイムの略）。１日４回、２時間おきの納入である。注文の数量は、２時間前にFAXで送られてくる。

忙しそうだが、業容拡大のチャンスだ、とあなたは思う。うまくいけば、月商100万円近い売上増になる。パートを雇っても、何とかペイするだろうと、ソロバン勘定をしてみた。利益が出れば、古くなった店の設備も新しくリニューアルできるかもしれない。

ところで、生産管理の用語でいうと、あなたの店は今まで、顧客の需要を予測して商品を作る、見込生産（MTS = Make-to-stock）の生産形態だった。しかしチェーンストアの注文を受けてサンドイッチを作るビジネスは、繰返し受注生産（MTO = Make-to-order）の形態になる。

一つの会社が、商品種別ごとに、異なる生産形態を持つこともありうるのだから、これは格別おかしなことではない。だが、このような生産形態の変更は、あなたのパン屋ビジネスに、どのような変化をもたらすだろうか？

（注：前回の記事ではMTS = "Make to Stock"と書いたが、つい最近入手したAPICS Dictionary日本版を見たら、間にハイフンを入れている。そこで今後は、"Make-to-order”のように表記することにする）

さて。１ヶ月も経つと、あなたは次第に大変な仕事を引き受けたと感じ始める。

注文（納入指示）は２時間前にFAXでくる。しかし、カツサンドなどの調理をしていると、２時間のリードタイムには、間に合わないのだ。しかたなく、あなたは一日のはじめに、出荷量を想定してカツ調理の指示を出すことにした。注文の分だけ、パンにはさんで出荷する。

だが、見込がちがうと売れ残る可能性がある。しかも、チェーンストアの仕入れには、鮮度指定があり、製造後６時間以内のものでなければ受け取ってくれない。これはライバルであるコンビニなどとも同様だ。

何よりも困るのは、材料仕入れだった。毎日の出荷変動が激しいため、余裕を多目にとって発注するしかない。だが、どれだけ在庫量を持つのが適正だろうか？　それに肉などは、賞味期限がある。たくさん買えば安くなるのはわかっているが、あまり大量に買い込んでおくわけにもいかぬ。

おまけに、もう一つ、誤算があった。月末になると、出荷数量に応じて請求書を作り、チェーンストアに請求する。ところが、この時点でさらに、単価のネゴをうけるのだ。その月に、たくさん売れれば、値引きを要求される。でも逆に、売れなければ、自分が廃棄ロスを背負うことになる。

注文を受け納品した後で、単価値引きの要求をされるなんて、不合理な商習慣だ、とあなたは憤慨する。だがストアの仕入れ担当者は、商売なんてこういうものだ、と平然としている。自分がかつて勤めた企業でも、購買部門ではこんなことをしていたのだろうか？

前回 https://brevis.exblog.jp/28031713/ の記事で、生産形態は4種類に大別できると、わたしは書いた。だが、あなたのサンドイッチの生産形態は、本当に繰返し受注生産（MTO）なのだろうか？　MTOは、注文を受けたら、資材購買をかけて、製造する形態のはずである。だが、あなたのサンドイッチ・ビジネスは、どう見ても先に資材購買しておき、さらにカツにまで調理している。

だとしたら受注組立生産（ATO = Assemble-to-order）なのだろうか？　確かに、食パンの間にハムやカツをはさむ作業は、「組立」工程だと言えなくもない。するとあなたは、常備品としてのカツを、いわば機械系工場におけるサブアッシー（Sub-assemblyの略称で、あるまとまりまで組み上げた部品のこと）として、常備在庫でストックしているのだろうか？　そして注文が入るたびに、組立てて出荷しているのだ、と？

だが、顧客であるチェーンストアは、「製造後6時間以内」との鮮度指定をしていることを、忘れないでほしい。ATOにおける常備品在庫とは、性質が違うのだ。ATOは需要変動を、常備品在庫で吸収する点が最大の特徴だ。注文が少なかったら捨てるしかないような在庫は、常備品とは言えない。

おまけに、あなたのケースでは、チェーンストア向けのサンドイッチは、ハムもパンも調味料も同社特有の仕様になっており、他の客に売ることはできない契約になっている。そもそも専用のラッピングで包装しているから、作りすぎた製品を、自分のパン屋の店頭には置けない。

しかもATOは、ある程度バラエティのある顧客の注文を、常備品在庫した部品やサブアッシーを使って、モジュール的に組み合わせて実現できる点に長所がある。特定顧客の固定した仕様だけを実現するなら、別にモジュラー型の製品アーキテクチャは必要ない。サンドイッチは組立製造にも見えるが、これがアンパンやデニッシュだったら、誰も受注組立製造だとは思わないだろう。

明らかに、あなたのチェーンストア向けビジネスは、ATOではない。少なくとも、アメリカの教科書に定義してあるATOとは、はっきりと異なる。だが、ATOではないとしたら、一体どんな生産形態なのか？

わたしはこれを、「下請け型受注生産」と呼ぶことにしている。下請け型受注生産の定義は、次の三つの条件を満たすことだ：

(1) 特定顧客向け仕様の製品を作っている

(2) 需要は変動しやすい

(3) 受注から納品までのリードタイムが、必要な製造リードタイムよりも明らかに短い

あなたが困っている根本の理由は、FAXで注文を受けてからサンドイッチを作り始めても、2時間の納品リードタイムに間に合わないからだ。だから、あらかじめカツを作り置きしておいて、ちゃんと6時間以内に出荷（消費）されるかどうか、心配していなければならない。もしこれが、十分に間に合うような納期（例えば12時間）だったら、あなたは冷凍庫に材料の肉を常備在庫しておいて、注文に応じて作ればいい。

あるいは、たとえ納期が2時間だったとしても、毎日の出荷量がいつも時刻毎に正確に同じだったら、全然困らない。予定を立てて、計画生産できるからだ。需要が読めない。それなのに、注文を受けてから製造したら間に合わない。だから、あなたの自己責任で、廃棄のリスク込みで、途中まで製造に着手していなければならないのだ。

それでも、その製品が汎用的で、いろいろな顧客に売れるようなものだったら、まだしも救いがある。チェーン店向けに作りすぎて残っても、店頭で売りさばくことができる。仮に通常の部品類だって、A社がダメでも、B社が買うかもしれない。たとえ個別には需要の変動が大きくても、複数顧客の需要を足し算すると、プラスの変動とマイナスの変動が打ち消しあって、相対的にリスクは小さくなる。これは数学的にも明らかだ。

上記(1)(2)(3)の条件を満たすような生産形態では、明らかに受注側は、需要を先読みして購買と製造に着手しておかなくてはならない。機械や電子部品のように賞味期限がない製品は、最後まで作っておいて、製品在庫として抱えておくことになるだろう。あるいは、あなたと同じように途中まで作っておいて、中間在庫とするかもしれない。いずれにせよ、発注者側はその在庫リスクを取ってくれない。つまり、契約上は受注生産のように見えるが、実態は形を変えた「見込生産」なのだ。

わたしが見てきた多くの事例では、一般に、発注側が受注側（中小部品メーカー）に対し、製造に十分なリードタイムを与えず、かつ、直前に数量を確定してくるケースが大半だ。特に発注者（大手セットメーカー）がJIT生産・JIT納品を標榜している場合がそうだ。まあ業種によっては、発注者側が大枠の先行内示を出してくるケースはあるが、それでも数量が２，３割ずれるのもざらである。

こういう商慣行が通用している場合には、生産管理の教科書にあるような「繰返し受注生産」は、成り立たない。

以前も指摘したことだが、JISの定義によると、受注生産とは

　「顧客が定めた仕様の製品を生産者が生産する形態」

ということになっている。他方、見込生産とは

　「生産者が市場の需要を見越して企画・設計した製品を生産し，不特定な顧客を対象として市場に出荷する形態」

である、という。（JIS Z 8141 「生産管理用語」https://kikakurui.com/z8/Z8141-2001-01.html ）

だが、あなたのサンドイッチ生産は、明らかに顧客が定めた仕様の製品を、需要を見越して生産している訳だから、JISの定義のどちらにも当てはまらない。このような矛盾が生じるのは、JISの規定が、考え足りないからだ。仕様が特定顧客向けかどうかと、生産の起点が需要見込か確定受注か、というのは独立した問題である。

したがって、生産形態とは、本当は次の図のような二次元の表になっていなくてはならないはずだ。

この図は、わたしが『“JIT生産”を卒業するための本―トヨタの真似だけでは儲からない』（日刊工業新聞社・2011年）で、初めて導入したものだ。そしてここには、5番目の生産形態として、「下請型受注生産」を入れてある。そして、このよう奇妙な生産形態があることは、以前からこのサイトでも繰り返し指摘してきた。だが残念ながら、未だに生産管理の常識にまではなっていない。

顧客仕様品の見込生産

「受注生産という名前の見込生産」 https://brevis.exblog.jp/8271502/ （2008-07-08）

受注生産と見込み生産の混合

「受注生産企業に生産計画は必要か？」 https://brevis.exblog.jp/23882328/ （2015-11-18）

日本の製造業における生産管理が混乱しがちなのは、このように、その基礎であるはずの生産形態の概念自体が歪んでいて、実態を反映していないからだ。

ちなみに、日本には下請法という法律があり、発注者（「親事業者」）による「優越的地位の濫用」を抑制する建前になっている。例えば、内示書を出したのに、下請け業者がその通り納品しても、全品を受け取らない、といった行為は法律で禁じられている。

（参考）　下請法　−　対象となる4つの取引と11の禁止事項　

https://www.home-one.jp/kigyouhoumu/compliance/shitaukehou.html

ただ、この法律には、資本金による制約がついている。受注側の資本金が3億円以上だったら適用されないし、それ以下でも、発注者側の資本金が1千万円以下だったら対象にならない。それに、あなたのサンドイッチ・ビジネスの場合、発注者は先行内示を出さずに、FAXによる注文で全品受け取る訳だから、禁止事項には該当しなさそうだ。明らかに在庫リスクを下請け側に押し付けているのだが、法律は守ってくれない。（ただ月末の値引き再交渉は、「下請代金の減額」に該当する可能性があるかもしれないが）

なお、日本の自動車業界では、先行内示を前々月から出しておいて、かんばん等で実需を調整するやり方が広く行われている。そして、中には内示と実需がかなり食い違う会社があって、部品メーカー泣かせとなっている。ところが、わたしが業界の人から聞いた限りでは、同じ日本の自動車会社が、北米ではこのようなやり方をせず、部品メーカーには確定注文を出し、その通りに引き取るという。

なぜこのような違いが生じているのか、詳しい事情は分からない。でも（ここから先は想像だが）、北米の部品メーカーはそれなりの企業規模であり、かつ法律知識も権利意識も高いので、在庫リスクを押し付けるような発注契約が難しいのではないか。そして、その事情は、おそらく欧州や他の新興国でも似ているのであろう（新興国のマネージャー層は、しばしば欧米のビジネススクールで高度な教育を受けているものだ）。

結果として、JIT納品の旗印のもとに、需要変動のリスクを下請け側に押し付ける「下請け型受注生産」は、極東のガラパゴス的な島国だけに残るような気がする。経営基盤の弱い中小下請けが、サプライチェーンの需給ミスマッチのリスクを背負うような生産形態が蔓延していることこそ、この国の産業構造の弱点であることに、より多くの人が気がついてほしいと願う。

で、気がついた人は、どうすべきか？　それについては、項を改めて、もう一度書こう。

自社の生産形態をデザインする

ときおり頼まれて、生産スケジューリングの話を人前でする。生産計画やスケジューリングについて困っている方が、製造業には多いのだろう。中堅中小の工場はいうに及ばず、結構な大企業の工場に行っても、Excelの生産日程表を現場に配って、現場のリーダーたちが個別に指示采配しているケースを、よく見かける。

Excelだから悪いと決めつけるのは早計かもしれないが、現場の状況に応じて臨機応変に修正するには、どうしたって時間がかかる。だから納期や機械稼働に変動の多い工場では、機動的に指示変更が出せない。出せないと、需給のタイミングがずれて、欠品や在庫が増えることになる。かくて納期遅れが多いのに、無駄な在庫も多い、という現場ができ上がる。

そこで、何か良い知恵はないかとお集まりの皆さんに、わたしが必ず最初にする話が、『生産形態』の種別の説明だ。なんだか肩透かしを食らったような気がすると思う。生産方式と生産形態というテーマは、生産管理の教科書なら、最初に出てくる概念だ。だが、セミナーに集まる多くの方は、あまり生産管理の理論をキチンと学んだ経験がないようにも、見受けられる。奇妙なことだが、これが日本の製造業の実態らしい。

生産方式とは、モノの作り方と工程のあり方に関する分類だ。たとえばプロセス型生産とか、組立加工型生産といった類型がある（後者はディスクリート型ともいう）。組立加工型はさらに、フローショップ型とかジョブショップ型などに分かれる。作る製品の量と質によって、生産方式はおのずと制約される。牛乳は旋盤で削らないし、豪華客船は反応釜では作れない。だから生産方式は、主に生産技術部門が考え、結果は工場レイアウトなどに現れてくる。

他方、生産形態とは、需要（顧客注文）に対してどのように応じるかを分類した概念である。たとえば見込み生産とか、個別受注生産といったタイプがある。生産形態は生産方式がどうであるかにかかわらず、独立して決まる事柄で、むしろ生産管理（とくに生産計画）と関係する。だからスケジューリングの話の最初に説明するのだ。生産形態をどう選ぶかによって、リードタイム・在庫量が大きく変わる。

では、生産形態はどこの部門の誰が決めるのか？ そう。ここが問題なのだ。

多くの企業では、自社の製品の生産形態を、主体的に決める人がいない。なんとなく、従来の行きがかり上、現在の形態に落ち着いているだけで、それがベストかどうかを吟味する人もおらず、責任部門も存在しない。少なくとも日本では。これがたとえばアメリカの先進的企業なら「サプライチェーン・マネージャー」あたりが決めるのだろう。だが、そうした職位は、わたし達の社会では希少だ。

自社の生産形態は、日本人お得意の全員コンセンサスで決める？ わたしは違うと思う。そういう問いを、誰も立てた事がないのではないか。

もっとも先ほど、「生産管理の教科書なら最初の方に書いてあるはず」といったが、そもそも率直に言って、生産管理には良い参考書があまりないようだ。この国では現在、生産管理関連の本は、超初心者向けの易しいものしか、出版社が出さない状況になっている。数式が出たら売れない、「××学」はダメ、とにかく（IT本を除けば）エンジニアは専門書を買って読まない・・これが出版界で信じられている常識のようである。

話を戻すが、それでは、生産形態にはどのような種類があるのか。

これについては、わたしはこのサイトで何回も、もう10年以上前から書いている。でも、未だにネット上に情報源は限られているようだから、もう一度書く。

わたしは生産形態を、基本的に4種類に分類している。学問的にはもっと細かく5〜7種類に分ける流儀もあるのだが、分かりやすさが大事なので、4つとしている。以下の図は、2007年に書いた記事の図を少し手直ししたものだ。

4つの生産形態の図

「ＡＴＯ、ＢＴＯ、ＣＴＯ」（2007-11-09）

４つの生産形態

「工場計画論(4)　４つの生産形態」 （2010-02-09）

ものづくりはどんな分野でも、最初にモノを「設計」し、それから部品材料を「調達」して、加工・組立・検査などを通して「製造」し、最後に「出荷」して客に届ける必要がある。すなわち、生産とは

　(1)設計　→　(2)資材調達　→　(3)製造　→　(4)出荷

の4つのステップからなるプロセスを必ず通る。これは乳製品だろうが、豪華客船だろうが同じことだ。

この、設計→資材調達→製造→物流、という4ステップのうち、どこまでを先に準備しておき、どこからを需要情報（顧客注文）に合わせるか、によって、生産形態は大きく4種類に分かれる。

わたし達の社会で、皆が一番イメージしやすいのは、「見込生産」だろう。英語ではMTSと呼ぶ。MTSはMake to stockの略語で、ストックするために作る（＝生産して在庫しておく）形態をいう。英語の表現の方が、実質をわかりやすく示している。「見込み」という日本語には、何を見込むのかという曖昧性が残るので、わたしの所属する中小企業診断士協会「生産革新フォーラム」（略称MIF研究会）は、「需要予測生産」と呼ぶことを提案し、共著『“JIT生産”を卒業するための本』 でも、そう書いた。

MTS（見込生産）という生産形態は、この(1)設計から(3)製造までを、自分たちの需要予測に基づいて事前に行っておき、出来上がった製品をストック在庫の形にしておき、実需に応じて流通経路に配する。いわば、顧客の需要（注文）と、生産による供給が、(3)と(4)の間にある製品在庫でマッチする（調整される）形になっている。

顧客から見ると、注文したらあとは出荷のみだから、入手までのリードタイムが短いし、メーカーの立場から見ると、予測に基づく計画生産で工場を動かせるから、すごく生産性もコスト効率も良い、ということになるはずである。ただ、その代償として、陳腐化リスクの高い製品在庫を、たくさん用意しなければならない。

このMTS（見込生産）の代表的業種は、家電・自動車・食品・日用品などの製造メーカーである。これらの業界はほとんどがBtoC（消費者向けビジネス）の企業だから、盛んに広告宣伝をするので目立つし、特に自動車と家電業界は長らく、日本の製造業をリードしてきた業界だった。だから、なんとなく「ものづくり産業」というと、このMTS（見込生産）形態が日本の主流のように、皆が思い込む時代が長く続いた。

しかし日本の電機メーカーは、知っている人は周知の通り、海外市場では見る影もなく落魄し、日本はむしろ電子材料・部品メーカーとしての面だけが生き残っている。部品が強いというのは、航空宇宙業界などでも似ていて、日本製旅客機はいつまでたっても空に雄飛しないが、航空機部品メーカーは海外でもそれなりに存在感を示している。

こうした電子材料・部品や機械部品メーカーの業界は、ほとんどが「繰返し受注生産」（MTO = Make to Order）の形態をとっている。英語のOrderは注文を意味し、MTOとはつまり、注文に応じて作る、の意味である。ものづくりのプロセスでいうと、(1)設計だけは事前に行っておく。注文が来たら、(2)資材調達→(3)製造→(4)出荷、というステップを進める。

MTO（繰返し受注生産）の形態では、MTSと違って、製品在庫という形のリスクを負う必要はない。注文を受けてから資材を手配すれば良いからだ。まあ、正確にいうと、注文に応じて調達する資材（引当品）の他に、注文がなくても常備しておく資材（常備品）も抱えている場合が多いが、在庫リスクはMTSに比べて小さい。

その代わり、MTO（繰返し受注生産）では、注文してから手に入るまでのリードタイムが長くなる。仮にあなたが年末ジャンボ宝くじの特等にあたって、海外メーカーのディーラーに行き、念願通りカタログにある最上等の豪華なスポーツカーを注文したとしよう。もちろんカタログに載っているからには、設計は済んでいる。だが、店頭に在庫はあるまい。十中八九、注文生産になる。そして何ヶ月も待たされることになろう。在庫リスクは小さいが、リードタイムの長さが、この種の生産形態のネックだ。それでも、先に述べたように、今日の日本の製造業のかなりの数が、この生産形態をとっている。

ところで自動車のケースについていうと、あなたが冬のボーナスで普通の乗用車を買うためにディーラーに行った場合、仮に車種はすでに決まっていたとしても、エンジンの排気量や外装・シートの色から、エアバッグ装備、カーナビ等電装品の配置等まで、相当数のオプションを選べるはずである。あなたが選んだオプションは、隣のテーブルで同じ車種を買おうとしている客とは、きっと全然違う。これもまた、注文生産ではないのか？　では、自動車メーカーは何ヶ月も待たせる代わりに、どうやって数週間で配車してくれるのか？

それは、国産車メーカーの多くが、自社の主力商品について、じつはATOという生産形態をとっているから可能になるのだ。ATOはAssemble to Orderの略で、日本語では「受注組立生産」と呼ぶ。

ATOでは、受注したら詳細な仕様やオプションに従って、組立に必要な部品やサブアッシーを選び出す。そうした各種部品やサブアッシーは、すでに(1)設計し(2)資材調達して、常備在庫としてストックを持っている。だから工場では組立てして検査するだけで、すぐ(4)出荷できる。MTS（見込生産）ほどではないが、注文から出荷までのリードタイムはかなり短い。そしてMTS（見込生産）に比べて、在庫リスクも小さい。

こうした業態は、PCのようにオプションが多数ある製品に向いている。早くから、この生産形態を徹底化したのがデル・コンピュータ社だ。彼らは自分たちの生産形態をBTO（Build to Order）と呼んで、普通のATOより進化したものと主張している。

事実、デル・コンピュータ社は、工場に常備品を多数ストックするようなことはしていない。そもそもPC用の電子部品（特にチップ系）は数ヶ月単位に値段が下がっていくので、常備すると陳腐化リスクが大きい。だから、彼らは現物として工場にストックする代わりに、部品市場で価格と需要を先読みしながら、先行手配をして、実需ニーズにほぼ合致するようにしている。実物在庫ではなく、サプライチェーン全体の供給予定（一種のエシェロン在庫）で、正確にコントロールする能力が、彼らの強みである。

ここまでに、MTS（見込生産）、MTO（繰返し受注生産）、ATO（受注組立生産）の3種類を説明した。では、残りの1種、図の一番上にあるETO（受注設計生産）とは何なのか？

あなたが仮に、豪華客船を手に入れるべく、造船所に注文に行ったとしよう。豪華客船の購入は、年末ジャンボ宝くじ程度では無理だが、まあ、遠縁の叔父の遺産のおかげで、クルーズ会社の経営者の立場を引き継いだことにしようか。いや、何だったらあなたは投資会社の辣腕役員で、これからは特殊なLNGタンカーの需要が高まると睨んで、造船所に掛け合うのでもいい。

豪華客船であれ特殊タンカーであれ、こうした船は通常、注文を受けてから(1)設計し、(2)資材調達し、(3)製造して、(4)出航（出荷）する、という4ステップを踏むことになる。これをETO = Engineer to Order（受注設計生産）と呼ぶ。特殊な船だけでなく、航空機や産業機械といったものも、この範疇に入る。顧客の仕様があまりにも個別ないし特殊なので、設計が都度必要になるのである。

このETO（受注設計生産）形態は、したがって、注文から出荷までのリードタイムが最長となる。その代わり、ETO企業はふつう、一切ストック在庫を持たない。毎回、個別に必要な資材だけを調達する。工場内にある在庫は全て、仕掛り中のフロー在庫である。

お分かりだろうか。生産形態の選択は、その製品に関して抱えるストック在庫の量と、リードタイムの長さを規定する。一般にリードタイムの短さと在庫量の少なさは、相反の関係にある。短納期を武器にするのか、それとも低在庫リスクのコストメリットを追求するのか？　自社の強みと競争力を、どこに置くのか。したがって、どの生産形態をとるべきかは、製造業における戦略の重要なポイントになるのである。

そして戦略である以上、それは一種の仮説、ないし賭けである。戦略が適切であるかどうか、継続して検証していかなければならない。検証するためには、しかるべきKPIを設定して、測定していく必要がある。とるべき生産形態（戦略）によって、重視すべきKPIも異なるはずである。

ちなみに、上の説明を読むと、何だかATOが一番良さそう（リードタイムと在庫のバランスが取れている）との印象を受けたかもしれない。だが、ATOを実現するためには、

(1)顧客がバラエティ豊かなニーズを持ち、それを受け付けられれば営業上の優位となること、

(2)バラエティを、モジュール化したサブアッシーや部品の組み合わせで実現できる製品アーキテクチャになっていること、

の2条件を満たせる必要がある。つまり、生産形態の選択には、設計部門や営業部門を巻き込んだ検討が必要なのである。

営業、設計、製造の3部門がそれぞれ分権化（あるいは分社化）し、「分業病」の高い壁で隔てられているような企業では、どのような生産形態が望ましいか、といった問題設定を立てること自体が難しくなっている。結果として、「なりゆき」思考で生産形態が決まってしまう。だが競争力を取り戻したかったら、生産形態に関する適切な戦略が必要なのだ。

もっとも、このサイトを読んでくださる読者諸賢の多くは、おそらく3部門を統括する社長でも事業部長でも、ないだろう。でも、そのような問題意識にあふれた貴方こそは、会社の将来、あるいは日本の産業の将来を担うはずの人材なのだと思う。だったらまずは、こうした分業病の限界に気づいて、一人一人が「なりゆき思考」から、脱却するべき時なのである。

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

前回から少し間が空いてしまいましたが、「プロジェクト＆プログラム・アナリシス研究部会」の2019年第1回会合を開催いたします。

皆さんは、自分や人の『感情』がマネジメント可能だと考えたことがおありでしょうか？　あるいは、プロジェクトにも感情があるのでは、と思うことはありませんか？

プロジェクト・マネージャーの仕事の半分以上は、コミュニケーションにあてられています。チーム員や顧客・外部のステークホルダーとのやりとりに時間が割かれ、しかもその多くは、単なる情報伝達以上の、説得や交渉や動機付けといった難しい仕事です。難しい理由は、自分や他人が内心抱えている「感情」が、伝えるべき「理路」を左右してしまうからでしょう。おまけに、感情には一種の共鳴性ないし伝染性があり、チームの中でどんどん広がっていきます。

では、そもそも、感情にはどんな種類があるのか。自分や他者が抱えている感情に気づくには、どうしたら良いか。そして感情はどんなダイナミクスに従って動くのか。こうした感情に関する教育やトレーニングは、ほとんど受けたことがない人ばかりだと思います。

今回はPM関係の教育・コンサルティングに従事しておられるアイシンク（株）の丸山奈緒子様に、感情マネジメントのスキルについて、入門編をお話いただきます。目からウロコの話題がたくさん出ること、請け合いです。プロマネの仕事は技術をリードすることだ、だから優秀な技術者がやればいい、と信じている組織が世間ではほとんどでしょうが、本当は感情とリスクのマネジメントがその8割以上なのではないかと、皆さんもきっと思われるようになるはずです。

大勢の皆様のご来聴をお待ちしております。

＜記＞

■日時：2019年3月13日（水）　18：30～20：30

■場所：慶応大学三田キャンパス　研究室棟B

https://www.keio.ac.jp/ja/maps/mita.html

※キャンパスマップの【10】

■講演タイトル：

「プロジェクトマネジャーが高めたい『感情マネジメント』スキル」

■概要：

　感情の取り扱い能力は、個人やチームのパフォーマンスを高めるうえで大変重要です。

　一方で、ネガティブな感情に振り回されたり、むやみに抑え込もうとしたりと、

　どのように扱うべきか学ぶ機会がなかった方が少なくありません。

　本講演ではプロジェクトマネジャーなどチームを率いる方に知ってほしい、

　感情とのつき合い方についてお伝えします。

■講師：アイシンク（株）

丸山奈緒子（まるやま・なおこ）

■講師略歴：

　お茶の水女子大学　生活科学部　発達臨床心理学卒

　桜美林大学大学院　心理学研究科　修士課程修了

　日本健康心理学会認定　専門健康心理士

　米国PMI®認定PMP®

　東京大学特別講師

　心理学をベースにしたヒューマンスキル系講座の開発・講師担当。ストレスマネジメント、

　アサーション、コーチング、交流分析、ファシリテーションなど、PMのニーズに即した講座を提供。

■参加費用：無料。

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

　参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

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

佐藤知一＠日揮（株）

書評：「菊と刀」 ルース・ベネディクト著

平凡社ライブラリー「菊と刀」 （Amazon.com）

昨年読んだ中で、インパクトのあった本のTOP 3を挙げろ、と言われたら真っ先に挙がるのが本書「菊と刀」であろう。1946年に刊行された日本文化の研究書であるが、未だにその輝きを失っていない。むしろ今日、現在の日本の姿を念頭に置いて読むと、いよいよその切り口の鋭さと洞察の見事さに驚き、感動さえ覚える。

「合衆国がこれまで総力をあげて戦ってきた敵のなかでは、日本はいちばん異質な相手だった。」−−本書は、こう始まる（p.9）。文化人類学者である著者ルース・ベネディクトは、1944年6月に、米国戦時情報局（OWI）からの依頼で、日本文化について研究する任務を与えられた。

'44年（昭和19年）6月といえば、日米開戦後2年半が経ち、すでに戦局は大きく米国側に傾いていた時期である。米国はすでに戦争の最終段階と、その後の占領政策について考え始めていた。（日本は）「本土に侵攻しないでも降伏に応じるだろうか？　皇居空爆は断行すべきだろうか？・・日本人はいつまでも軍政下に置いておかないと大人しくできない民族なのか？　わが軍は、山岳地帯のありとあらゆる天然の要害に閉じ籠り、捨て鉢な徹底抗戦を繰り広げる日本兵を相手に、戦闘をする覚悟をしなければならないのか？」（p.12）・・これが、彼らの直面した問いだった。

この問題に取り組むにあたり、文化人類学者に研究を依頼する、というのがアメリカ人らしいアプローチであった。異質な相手と取り組むには、その思考と感情の習慣を、科学的・客観的に理解しなければならない。これが西洋流の合理思考だ。

しかし、当然ながらルース・ベネディクトの仕事は困難を極めた。何より、文化人類学の基本は、フィールドワーク調査にある。戦争中の相手だから、当然それはできない。彼女は代わりに、米国内にいる日本人・日系人へのおびただしいインタビューと、先行研究の徹底サーベイによって乗り切った。現地・現場・現物に接することなく、知性はどこまで異文化を理解できるのか。本書はその精髄である。

『菊と刀』とは、「日本文化＝恥の文化、西洋文化＝罪の文化」という二項対立的な図式で日本を論じる本だ−−そう信じている論者は、今も多い。恥の文化とは、他者の目を意識して自分の行動規範とする、いわば他律的な文化であり、一方キリスト教を背景とした西洋文化は、絶対的な善悪の基準によって行動規範を持っている。だから西洋は日本よりも優れている。そういう主張の本だ・・という風に誤解しているようだ。

いや、正直に言おう。わたし自身、そう思い込んでいた。だが、そういう人は、この本をちゃんと読んでいないのだと、思い知った。「恥の文化」という有名な言葉は、分厚い本書の後半になって、それも日本人論ではなく一般的概念として、初めて出てくる。それまではもっぱら、「忠」「孝」「義理」などが日本人の人生観を支配している、という話が続く。特に重要な要素として、「恩」の感覚が詳しく記述される。

「日本人にとっては、恩の返済こそ徳目なのだ」（p.143）。これは、無償の愛で他者に恩を与えることが徳目とされる米国の倫理とは、随分異なっている。また中国では最高の徳目である「仁」（親や支配者が示す博愛）は、日本では無法者の道義に堕ちている。ベネディクトは、日本人における恩を、一種の貸し借りとして、いわば貸借対照表のように理解できる、と説明する。そして恩の返済に関連して、「義理」が登場する。

恥の文化という概念が登場するのは、汚名をすすぐ、そして自重する、といった徳目に続く章においてだ。「西洋人は、因習への反逆や障害を乗り越えて幸せをつかむことを、強さの表れと考える傾向がある。しかし日本人の見解では、強者とは個人的な幸福を顧みず自らの義務を全うする者のことである。」（p.254）

このような強い自制心への方向づけは、いわゆる罪と罰の概念による行動規制とは別物だ。それゆえ、日本人は、「この世は善悪の闘争の場」などではないと考え、「人間の生活では肉体と精神という二つの力が互いに相手を凌駕しようと絶え間無く争っているという西洋の人生観」（＝非常にピューリタン的な人生観）とは無縁だ（p.232）と、著者は驚く。

ただし、彼女は単純に米国と日本を対比して比較評価している訳ではない。あくまで文化人類学的な相対主義の立場に立って、日本文化を多面的に理解しようとしている。例えば中国文化との相違点もいろいろと書かれている。忠孝の概念は中国から来た。だが、中国の祖先崇拝と大家族主義の元では、伯父や伯母への関係も「孝」であるが、日本では普通「義理」にすぎない。日本人の祖先との結びつきは、せいぜい3世代さかのぼる程度であり、むしろフランスの家族制度に近いという。

もう一つ、ルース・ベネディクトが日本の重要な価値観として指摘するのは、階級序列の感覚である。個人は誰もが社会における（あるいは家族内における）序列のいずれかに位置し、その場所に応じて、果たすべき役割と義務、享受すべき権利と責任を与えられる。彼女はこれを、教育勅語の中にある「各々其ノ所ヲ得」という言葉で象徴させている。

「日本人を理解しようとするならばまず、彼らのいう「各々其ノ所ヲ得」ということが何を意味するかを考えてみないといけない」（p.60）。日本では、上位者に対して下位の者は礼儀に従ってお辞儀をし頭を下げる。「頭を下げる方は、相手が自らやりたいことを好きなようにやる権利を認め、その代わり頭を下げられた方は自分の『其ノ所』にともなう責任を受け入れる」（p.67）。この秩序を守ることが、日本人にとって安全の重要な要件なのだ。

そして日本人は、「国内ばかりか、国際関係における諸問題まで、彼らなりの階級序列との関わりで見てきた」（p.60）。かくて、八紘一宇というスローガンのもと、日本を頂点とした東アジア秩序概念を輸出しようとしたことが、日本の破滅のきっかけとなったのだ。真珠湾奇襲の当日にも、日本は米国のハル国務長官に、同じ言葉遣いで「惟フニ万邦ヲシテ各々其ノ所ヲ得シメ」るのだと伝えた。その無礼な主張に、多くの国は憤慨した。国々は互いに対等であるべしというのが、世界的な常識・通念だからだ。

ところが「日本の将兵は、占領した国家で住民に歓迎されないといっては、その都度いつまでも驚愕を繰り返した」（p.118）。其ノ所の感覚が、日本以外では通用しないことを知らなかったのだ。

さて、ルース・ベネディクト達にとって特に問題となったのは、日本人の戦争の勝敗に対する感情である。日本の軍隊は、簡単に降伏しない。「西洋国家の軍隊では、兵力の四分の一から三分の一が戦死すれば、軍隊が降伏するのはほとんど自明の理となっている」のに対して、「ホランディアで初めて相当数の日本兵が降伏した時、投降の割合はおよそ戦死5に対して降伏1だった」（p.55）。

これほどまでに頑強に抵抗し、しかも、赤穂四十七士による主君の仇討ちの物語を大切にする日本人たちは、たとえ戦場で米国に敗北しても、その後ずっと怨念を抱き復讐を誓う存在であるように思われた。

ところが驚いたことに、一旦降伏を受け入れるや否や、日本軍の「古参兵や長年の国粋主義者が、味方の弾薬集積地の場所を探し出し、日本軍の配置を念入りに説明し、わが軍の宣伝文を書き、わが軍のパイロットと爆撃機に同乗して軍事目標まで導いたりした」（p.58）のである。こうした「敗北した日本人の180度の方向転換は、アメリカ人には額面通り受け取ることが難しい。私たちにはそんなまねはできないからである」（p.213）。彼ら日本兵は、「鬼畜米英」を放逐し、「東亜新秩序」を打ち立てるという大義のために、命を懸けて戦ったのではなかったのか？

だが、そうではなかったのだ。そして、このような敗北後の180度方向転換は、別に太平洋戦争の特殊事情ではなかった。同じことは幕末時代にも起きた。薩英戦争に負けた薩摩藩、下関戦争に負けた長州藩は、いずれも「英国に永遠の復讐を誓う代わりに、英国との友好を求めたのである。その相手から学ぼうとしたのだ」（p.215）。もっとも先鋭的な尊皇攘夷の藩だったはずの薩長の、この変貌は、現代のわたし達自身にさえ、なんだか奇妙に思える。

しかし、それこそまさに「各々其ノ所ヲ得」という日本人の序列感覚が生んだ現象だと、ベネディクトは説明する。太平洋戦争に負けて、日本人は「アメリカ当局を自分たちの国における階級序列の最高位として受け入れた」のだった。「日本人は、持てるすべてを一つの行動方針に投入し、それに挫折すると、別の行動方針を採用する。・・それはあたかも、人生のページを真新しくめくったかのようだった。」（p.58-59）。

逆にいうと、日本人は何かの絶対的な観念や哲学に従って行動するのではなく、常に相対的な序列に応じて、実利的に行動するのだ。それこそまさに、善悪の絶対基準による罪の文化ではなく、名誉を基準にした恥の文化のパターンが示す行動規範である。

なお、翻訳について一言いっておきたい。訳者の越智敏之・越智道雄（どちらも大学教授で、父子と思われる）は、丁寧かつ手厚い翻訳を行なっているが、しかし同時に本書が「数多くの事実誤認を含む」として、詳細な、ほとんど教師が学生のレポートを添削するがごとき訳注を付している。一例を挙げると、生麦事件が薩摩藩内で起こったかのように書いているのは、確かにベネディクトの誤りに違いない。しかし、生麦という小さな町が神奈川県にある、と知っている日本人は何割いるだろうか。また、「ビルマ」に訳注をつけて「今日のミャンマーをさす」と書かないと、読者は分からないと考えているらしい。いささかお節介にすぎると思われるのだが。

ともあれ、それなりに読みやすい新訳で出されている本書は、日本人が日本を理解する上で、必須の文献であると改めて思った。ルース・ベネディクトは、決して勝者米国の人間として、日本文化を裁いて見下すような書き方はしない。彼女はプロの文化人類学者であり、文化の相対論者である。だがそれ以上に、本書を通して感じられるのは、研究対象である日本への、率直な驚嘆と愛情である。

そして驚きと愛こそ、異文化理解の最大の原動力なのだ。

ITシステムのオーナーシップとは何か

男が道を歩いていたら、「言葉を話せる犬、売ります」という看板を見つけた。興味を惹かれて門をくぐり、中にいた犬にたずねた。「お前さんがその犬か。これまで、どんなことをしてきたんだい？」

すると犬は答えた。「自分はとても充実した生活を送ってきました。まず、アルプスで雪崩の犠牲者救助をしてました。その後は、イラクで米軍の補助犬として働き、今は近くの老人ホームの人たちに本を朗読してあげているんです。」

感心した男は、オーナーに向かってたずねた。「こんな立派な犬を、何であなたは手放すんです？」

オーナーは答えた。「大嘘つきだからだよ。そいつが言ったことなんて、実は何一つやってないんだ！」

・・アメリカのジョークである。犬はまあ、それなりに知的な生き物だが、人間の所有物だ。オーナーの役に立つことをするから、飼ってもらえる。役に立たなければ、オーナーは手放したり売ったりするだろう。特に、それが「できる」と称している機能と、現実とにギャップがあれば。おまけに、米国の商品には（ソフトを含め）案外その手の品質ギャップが多いのだ。

前回の記事『プロジェクトのオーナーシップとは何か』https://brevis.exblog.jp/27925736/ で、わたしは「プロジェクト」という目に見えない活動のオーナーについて考えた。今回は、ITシステムという、同じく目に見えない道具について検討してみよう。

そもそも、オーナーシップとは何か。それは、端的に言って、何らかの対象を「自由にできること」を意味する。自由とは、例えば、利用したり、譲渡したり、変更したり、破棄したり、といったことだ。

もちろん、そのためには、自分がその対象を、正当に取得した（ないし自分で作成した）のでなければならない。そして、自分はその対象の価値を知っているし、はかることができる能力を持つ。

法律的には、いろいろなモノに対し、所有権とは区別して「利用権」を設定でき、他者に譲れる。土地がその良い例だ。所有しているということと、現在使っているということは、別なのである。

オーナーは、所有する対象から直接生じる便益や損失についても、対外的に責任を持つ。経済的な利益も損害も、そしてそれに伴う栄誉も、不名誉も、オーナーに帰せられる。犬を飼う人は、犬が他人に迷惑をかけたら、賠償したり詫びたりしなければならない。

また、その対象に依存して何かを行う他者がいる場合、オーナーはその維持にも責任を持つ。自動車の場合、特定他者とは、例えば家族の場合もあるだろう。あるいはレンタカー業で、ユーザと個別に契約を結ぶ場合もあろう。さらに、利用者が不特定な場合だって、何らかの社会的な責任というものは生じる。

要約すると、何らかの対象について、お金を出して取得し、その価値を活用し、さらに改善し、無価値になったら破棄することを、責任を持って行うのがオーナーシップである。つまり、

　PDCAサイクルを回す主体 ＝ オーナーシップ

だと考えていい。

さて。読者諸賢の職場では、IT予算は誰が決めて、誰が払うのだろうか。情シス部門？　ユーザ部門？　それともケースバイケース？

IT予算に関する調査レポートは、日本情報システムユーザ協会（JUAS）をはじめ、いくつかの調査機関が出しているが、あまり予算の出所や管理権の所在について、書いたものを読んだ記憶がない。わたしが気づいていないだけかもしれないが。

じゃあ、別の聞き方をしよう。IT開発プロジェクトのオーナーは、誰か。IT開発チームのプロマネの上司である、情シス部長やCIOか。

ここで問題にしたいのは、社内の業務で使うタイプの業務系ITシステムのことだ。外部顧客向けのソリューション商品とかの話ではない（その場合は、プロダクト・オーナーが当然いるはずだ）。

実は、そのシステムを使って実現する「業務プロセス」のオーナーが、オーナーシップを発揮すべきだ、というのが今回の話だ。それが販売系プロセスであれば営業部門、製造系であれば生産、設計系であれば技術、物流系であれば物流部門がオーナーであるはずだ。

業務ユーザ側の部門が、開発予算の実質的スポンサーであり、IT投資からその価値を引き出す任務に当たる。である以上、開発投資（予算）の決断も、その内容とスコープ（範囲）も、その主たる業務機能も、業務ユーザ側部門が最終的な判断権を持つ。（なお、サーバやネットワークといったITの基幹インフラ系システムは、情シス部門がオーナーで構わない）

そして、業務ユーザ側が、IT投資に見合う価値があるかどうかを、判断する。これが、あるべき姿ではないか。

こう書くと、早速反論が寄せられそうだ。「ITのことなんか何にもわかんないユーザ側が、決められる訳ないだろ。第一、開発工数のことも、運用保守の負担も、テクニカルなアーキテクチャーの良否も、判断できないじゃないか？　だから、俺たちが一番良いように、ちゃんと考えて決めてやるさ。俺たちが作って与えた通り、ユーザは使ってればいいんだ・・」

あえて嫌味な書き方をしたが、こういう感覚を内心持ったことのあるITエンジニアは、案外多いのではないか。

だが、これは危険な、官僚主義への道だ。その昔、汎用計算機しか世の中になくて、1台なん億円もした時代の感覚だろう。高価なリソースを管理し、使わせてやっている、という時代は、「専門家判断」に全てを依拠するのが主流だった。

だが、こうしたあり方は、かつての鉄道事業や電気通信事業のあり方を思い出す。あの当時、10円玉と100円玉の両方を使う公衆電話で、技術的にはできるくせに100円玉にお釣りを出さなかった電電公社のことを、覚えている人はまだ多い。こうした官僚主義のサービス事業は、みんな民営化されてしまった。

同じように、社内の情シス部門が聞く耳を持ってくれないと感じるユーザ部門は、しまいには自分たちで外部に直接アウトソースし始める。つまりITサービスが社内で「自由化」され、外部との競争にさらされることになる。今はそれが、十分可能な時代だ。昔の汎用機の時代とは違うのだ。そうして、社内バラバラなシステムが横行したら、最後に困るのは自分たちITエンジニアではないか。

「いえいえ、わたしは言われた通りのものを作るだけです・・」そういう受け身のITエンジニアたちも、もちろんいる。ただ、その姿勢はどうかというと、ユーザ部門の要望に従って作った結果、どうなっても、それは知りません、という印象をしばしば与える。つまり、オーナーシップを忌避ししてる訳だ。だが、ユーザ側にオーナーシップを求めている訳でもない。

結果として、「オーナー不在」なまま宙に浮いた業務システムが、社内に多数存在することになる。そうした業務システムは、PDCAサイクルを誰も回さない。いずれ、アーキテクチャ的にも機能的にも、温泉旅館的つぎはぎ構造になっていき、誰もまともに保守できなくなる。それもありがたくない話だ。

一番望ましいのは、ユーザ側が企画構想と実業務適用と評価・改善のPDCA責任を持ち、IT部門が開発と運用についてプロの専門家として委託される形だろう。

そして、IT機能の実現方法について、複数の案が存在するときは（たいていの場合はそうだが）、IT側が比較表を作成してユーザ側に提示する。比較表に記載すべき項目は、以下のようなものだ：

• 実現手法
  
• 実現できる機能要件
  
• 想定される非機能要件（レスポンスタイム、スケーラビリティ、オペラビリティ等）
  
• 初期コスト及び運用コスト
  
• 長所
  
• 短所
  

そして、ユーザ側が総合的な観点から、比較評価して決める、という手順を取るべきである。この時、開発予算や運用予算は、ユーザ部門側がオーナーシップを持って起案することになる。

ただ、ユーザ側がITにまるきり無知なままでは、ちゃんとしたオーナーシップを持てないのも、事実だ。結局、これは社内一般ユーザのIT的な育成という課題にたどり着く。

無論これは、かつてのような社内OA講座みたいな「コンピュータ・リテラシー教育」の問題ではない。ITとは何で、ITシステムとはどういうもので、開発プロジェクトはどう進められ、運用保守は何が大切か、といった研修が必要なのだ。業務をITに合わせるべき点はどこで、逆にITシステムにはどういう機能要件を持たせるべきか、という最適バランスを、ちゃんと議論できるようになってもらわなければ、良いITシステムは作れない。

ところで、単独の部門の業務に関わるシステムの場合はいい。複数の部門にまたがるような、複雑広範な業務プロセスのITシステムは、誰がオーナーシップを持つべきなのか？

これがまた、現実には厄介な問題なのである。ここでも、前回と同様、「ステアリング・コミッティ」方式を取るしかない。関係する部門からメンバーを出してもらい、委員会方式でコンセンサスをとっていくのだ。

ただ、その場合でも、リーダーとなる部門は明確に決めるほうがいい。そうしないと、意思決定の責任所在が不明の、いつもの「日本型無責任体制」になりかねない。

なお、米国などのグローバル企業には、「業務プロセスのオーナーシップ」という考え方がある。例えばマイクロソフトには、数名のエグゼクティブがいて、彼らがそれぞれ業務プロセスについてグローバルに責任を持っている体制だと、数年前に聞いた。しかし日本企業では、こうした体制になっている例は、寡聞にして聞いたことがない。目に見える「モノ」には非常にこだわるが、無形の「プロセス」には興味がない人が多いから、だろうか。

だが、ITシステムというのは、より競争力の高い業務プロセスを実現するための、ツールなのだ。だから、本当はITシステムではなく、『業務プロセスのオーナーシップ』を考えるのが、より適切なのだろう。ただ、これまた、確立するには、随分と道のりの遠い話だ。だが、そうしないと、言葉はペラペラ喋るが、内実は全く伴わない犬を飼っているのと同じで、カッコいいけれど出費だけが虚しく続く生活に陥るのである。

プロジェクトのオーナーシップとは何か

オーナー（Ower）とは、所有者であり、オーナーシップ（Ownership）とは所有権を意味する。ただ英語の語尾 -shipは、名詞について、それを持つ人の志や、性質や「らしさ」をも示す（例えばリーダーとリーダーシップのように）。だから、オーナーシップとは、所有者らしいふるまい、ということにもなる。

有形のもの、車とか家などのオーナーシップの意味は、誰にも明らかだ。そのものを所有して、自分の意のままにすることができる。無形のもの、例えばライセンスといったものにも、オーナーシップを考えることができる。自分がお金を払い、そこから得られる便益を自分の自由にすることができる。何であれ、それを維持する労力や費用負担し、そこから主たる価値を得るものは、それに対するオーナーシップを持つと言えるだろう。

それでは、プロジェクトのオーナーシップとは、何なのか?

X社のプロマネP氏は、困惑していた。大型プロジェクトを受注して数ヶ月。このままでは、かなりの赤字になることが明白だ。現時点での詳細設計から、全体コストを見積もり直してみると、当初想定していた金額を大幅に上回ってしまう。

顧客のA社に窮状を訴えて、追加費用を出してもらうことも考え、実際内々に打診してみた。だが顧客の反応は冷たかった。そもそも基本設計も、X社が有償で行なったのではないか。その基本設計書の内容をもとに、両者が合意して一括請負契約を結んだのだから、その通り実行してもらいたい。それが向こう側の言い分だった。

確かにその通りだ。要件定義は前任者のプロマネが行い、P氏はそれを引き継いだまでだ。ただ、顧客の業務要件は思ったよりはるかに複雑で、例外が多く、新しく入ったメンバーが理解するまでの時間も、かなり必要だった。

おまけにもっとまずい事に、プロジェクトで中心的に使うつもりでいた自社製の新型装置を、隣のチームが並行して開発中だったのだが、予定された期日からかなり遅れていた。基本設計レベルに問題があったらしく、期待したパフォーマンスがさっぱり出ないのだ。そのおかげで、上司の命令により、自分のチームから優秀なメンバーを数名、隣に回さなければいけなくなった。

仕様は思ったより膨らんでいる。優秀なメンバーもとられてしまった。あてにしていた中核装置も出来上がってこない。顧客は頑固な態度である。このままでは赤字は必至だ。一体どうしたらいいのか？

世の中ではしばしば、大赤字を生みデスマーチが見えているプロジェクトが、延々と続けられている。なぜだろうか。受注したからには完成させるのが受注者の義務？　だが、たとえ違約金を払ってでも、プロジェクトから降りてしまう方が、ビジネス的には傷が小さく済む場合だってあるではないか。

だが、一般にプロジェクト・マネージャーには、プロジェクトを中止・撤退する権限はないのである。プロマネとは、プロジェクトを遂行するように命じられた存在である。遂行の義務と責任を負っている。仕事のパフォーマンスがまずくて、プロマネの職を解かれることはある。だが、プロジェクトの価値が下がったからといって、自分からプロジェクトの遂行をやめる権利は無い（会社自体を辞めてしまうなら別だが）。

そこで改めて考えてみよう。プロマネを任命するのは、一体誰か。プロマネの成果を認定し、評価するのは誰なのか？

それが、「プロジェクト・オーナー」なのである（オーナーは、業界によっては「スポンサー」と呼ばれる場合もある）。プロジェクトの価値を考え、プロジェクトを発進させ、プロマネを任命し、予算を与えるのがオーナーの仕事である。なお、プロジェクトが上位の「プログラム」の一部である場合は、プログラム・マネージャーがオーナーシップをとる。だが、日本ではプログラム・マネジメントをまともに実施している企業がほとんど無いため、そのケースは無視していい。

さて、苦境に陥ったP氏は、上司である事業部長K氏に、状況を正直に報告し、対策を相談した。事業部長が、このプロジェクトのオーナーだったからだ。そこでK事業部長も、自ら顧客に追加交渉にいってみた。だが、相変わらず相手の態度は硬い。このまま続ければ、この開発プロジェクトと、自社の新型装置開発の、二つのプロジェクトがともに道連れで沈没しかねない。

K氏はさらに上の役員と相談の上、苦渋の決断を下した。顧客A社に対し、違約金を払って、このプロジェクトから降りると宣言したのだ。

発注者A社側のプロジェクト責任者は、X社の撤退に驚き、大いに怒った。たとえ違約金をもらったからといって、費やした時間も労力もかなり無駄になったからだ。しかしA社の担当役員は、X社の決断に舌を巻き、内心、敬意を評したという。X社が受注者としてのスポンサーシップを発揮し、痛みは伴うが適切な決断を下したからだ。「確かにウチは迷惑した。だが、あの決断は大したものだ。なかなかできる決断ではない。」

撤退の判断は、つねに難しい。特に受注型プロジェクトの場合は、なおさらだ。お金も労力も失われるが、自分のメンツや顧客からの評判は丸潰れになる。業績評定にだって、大いに影響が出るだろう。

プロジェクトが完遂できないのは、明らかにプロジェクト・マネジメントの失敗である。だが、失敗したプロジェクトから、適切なタイミングで撤退する事は、正しいオーナーシップの発揮なのだ。この点を世間の人は誤解しがちなので、あえて繰り返し強調しておく。失敗したプロジェクトから思い切りよく撤退する事は、オーナーシップの失敗ではない。

オーナーシップの失敗とは、価値のなくなったプロジェクトを、延々と続ける事なのだ。プロジェクトにおいて最も恐ろしい事とは、プロジェクト自体が自己目的化してしまう事だ。ゴールに到達したが、結果は無価値で、労力と金と時間の無駄だった、という事ほど、人心を荒廃させる事はない。それはオーナーシップの不在を意味する。

わたしは授業でよく、公共事業のケースを例にあげる。有名な公共事業の中には、すでに半世紀以上にわたって遂行中で、予算規模も千億円クラスのものがある。だが、終戦直後に計画されたその事業の完成を、もはや誰も待ち望んでいない。それでも続いているのはなぜか。役人という人種が、いったん始めた事は絶対に失敗を認めないし、撤回もしないからだ。だが、繰り返す。失敗を認めず、意味のなくなった事業を続けることこそ、より大いなる失敗なのだ。

もちろん、オーナーの仕事はプロジェクトを中止し撤退することだけではない。むしろそれは最後の選択肢だ。オーナーは、プロマネを助けて、プロジェクトが意味ある仕事として完遂することを支援するのが、本来の仕事である。

以前、米国のPMコンサルタントであるNeal Whittenの主張を紹介した（「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/）。彼によると、米国におけるプロジェクトの問題の1/3は、オーナーシップの不全にある、という（彼は「スポンサー」という用語を使っている）。

それでは、プロジェクト・オーナーの仕事とは何か。それは、

• プロジェクトを起動し
  
• プロマネを任命し
  
• Project Charterを承認し
  
• 予算枠と期限を与え
  
• プロジェクトの状態と価値を定期的にウォッチし、
  
• プロマネの相談に乗り、助ける
  
• プロジェクトの終結を承認し
  
• あるいは、無価値となったプロジェクトを中止する
  

こうした、プロマネに対する「上からの支援」が、プロジェクトの成功のためには、非常に重要なのである。だからあえて、以前も掲げた図をここに再掲しておこう。

プロジェクト・オーナー（スポンサー）は、プロマネの相談相手として機能しなければならない。そして、プロマネの悩みはたいてい決まっている。それは、お金が足りません、か、人が足りません、なのだ。オーナーというのは上級職の仕事で、普通はプロジェクトにフルタイムで関わることはない。だが、プロマネに対しては、いつでも悩みを聞いてあげる存在でなければならない。

ところが、わたし達の社会では、これが弱いのだ。あるいは、オーナーという役割が存在しない場合も多い。その必要性さえ、認識されていない。だが、プロマネを助けないプロマネの上司とは、一体何のためにいるのか？

とはいえ、多くの読者諸賢の職場では、実際問題、オーナーというポジションは存在しないかもしれない。だったら、どうすべきか。居ないものは居ないとして、それでもプロジェクトが倒れないようにするための、現実解を考えなければならない。

わたしがお勧めする方法は、三つである。

第一に、きちんとProject Charterを作ることだ。Charterというのは、日本では「憲章」と誤訳されているが、「趣意書・許可書」のことだ。もともと英国で、国王が特に出す勅許状のことを、Charterと呼んだ。特別仕立ての飛行機のことをチャーター便と呼ぶのは、その名残だ。また英国では、公式に認定された技術者をChartered Engineerと呼ぶ。

Project Charterという文書は、組織が、そのプロジェクトを公式に認めて、その発進を許す書状である。そこにはプロジェクトの目的や目標などを書く。そして本来は、このCharterはプロジェクト・オーナー（スポンサー）が作って、プロマネに与える、という建前になっている。少なくとも、PMPの試験では、そう書かないと正解にならない、と教わったはずだ。

だが現実には、プロマネがCharterを作っている企業が大半である（だってオーナーはいないのだから）。そこでCharterを作ったら、それをしかるべき上司に、承認してもらおう。表紙にハンコの承認欄を作るのもいい。判子をもらってしまえば、それは上司が公式に認めたことになる。そして上司にも責任（命令責任）が生じる。

あるいは、もう少しモダンなやり方としては、皆で集まってチームビルディングを行う。そして、最後に皆で「コミットメント・シート」を作る。そこにサインを寄せ書きする。無論、上司には中央にサインをしてもらおう。そのシートは、プロジェクト・ルームの壁に掲げて、いつでも見えるようにしておく。こうして、オーナーたるべき人物を、責任と面子のループに取り込んでおくことが重要である。わたし達の社会は、面子とコンセンサスの社会なのだから。

第二に、プロジェクトのJournalを頻繁に発信することである。Journalというのがまた、適切な訳語がない言葉なのだが、元々は日誌のことで、転じて定期刊行物や雑誌を意味するようになった。プロマネにとって、日誌をつけるのは非常に良い習慣である。それはいざという時の法的根拠にさえなる。だが、もっとソフトな意味で、定期的な情報発信のことを、ここでは言っている。

つまり「プロジェクト週報」だとか「プロジェクト新聞」といった簡単なニュースメールを発信し、関係者皆に送りつけるのである。関係者の中には、もちろん「オーナーたるべき人」も、さらにその上司をも、送付先に含めておく。

こうして、プロジェクトの状況を、定期的に、かつできる限り頻繁に、皆に知らせておき、上層部にも関心を持ってもらう。「そんなの多分、メルーボックスの肥やしになるだけだ」などと、最初から悲観してはいけない。捨てる神あれば拾う神ありで、世の中にはたまに、ちゃんと見ている人もいるのだ。プロマネはなるべく、いろんな人に味方になってもらう必要がある。

三番目の方法は、ちょっと大技だが、プロジェクトのために「ステアリング・コミッティー」を設置してしまう（設置してもらう）やり方だ。これは、拙著『世界を動かすプロジェクトマネジメントの教科書』 （最近増刷が決まった）に書いた方法でもある。

この本では、製造業の若手エンジニア・小川君が突然、海外企業とのジョイント・プロジェクトに巻き込まれるのだが、このプロジェクトたるや、誰がプロマネなのかも判然としない。そんな中、大学の先輩だった広田氏のアドバイスをもらいながら奮闘していく物語だ。その際、プロマネもオーナーも不明ながら、なんとか仕事を前に進めるために、あえて複数部門の管理職の層でステアリング・コミッティーを設置してもらうよう、小川君が上に提案する（広田氏がそう勧めたのだ）。

その顛末は本を読んでいただくとして、いったんコミッティーを作ると、なにせ面子とコンセンサスの国だから、なんとかサポートは得られる。そして、プロジェクト・ガバナンスの点からいうと、これはこれで立派な方策なのである。

もちろん、上記の三つの方法が、いつも功を奏するとは限らない。忙しい中、権限もないのに、実行するのはかなり大変だろう。でも、本当にプロジェクトが傾いてきたら、一番こまるのはプロマネの自分なのだ。だとしたら、少しでも会社にオーナーシップを自覚してもらうべきである。

それにしても、研究会などで多くのプロジェクト事例を聞くにつけ、感じることがある。日本の多くの組織で見られる、現場リーダークラスの共通の悩み、共通の問題があるのだ。

それは、ビジョンの不在や戦略の失敗を、戦術レベルでなんとかカバーしようと努力して苦労している、という事実だ。これが、中堅若手のプロマネや、サブリーダー・クラスの疲弊感を生んでいる。たとえば、営業部門が売上目標のために無理な価格、納期で受注してきた案件を、技術部門が苦心惨憺、遂行する。そして、プロジェクトをなんとか黒字にできないか、悩んでいる。あるいは、ヘンテコな製品戦略のために、新製品開発プロジェクトが迷走し、BOMや基準情報までが混乱する。こうした例は、枚挙にいとまがない。

なぜ、そんなことに努力を費やすのか。それは、現場リーダーに与えられた権限範囲と、リーダーの責任（評価・賞罰）とが、あっていないからだ。プロマネ自身ではどうしようもない環境条件において、結果だけを評価される。ここでプロジェクトの「環境」とは、プロマネが短期的な努力では左右し得ない条件をいう。

プロジェクトのオーナーシップは、プロマネを任命する権限を持つ者にある。したがって、プロジェクトの最終的な損益やアウトカムに対する最終的責任・評価もオーナー側にあるのだ。プロマネは与えられた条件下で、どこまで良くやったか（計画し遂行したか）を評価されるべきである。プロマネは、自分では途中でやめられないのだ。プロマネには実行責任がある。だが、命令責任は、オーナーは負うべきなのである。

＜関連エントリ＞

　→「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/ （2015-07-08）

　→「アカウンタビリティとは『命令責任』である」 https://brevis.exblog.jp/24837740/ （2016-11-05）