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

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）

プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 その内容と課題

EVMS（Earned value management sysytem）とは、プロジェクトのコストと進捗を、「アーンドバリュー」（出来高）と呼ばれるメトリクスを使って測定し、コントロールする手法であって、モダンPMの技術の三本柱の一つになっていると前回の記事で書いた。ところがEVMSには、ある弱点があった。「アーンド・スケジュール法」は、この問題を克服するために、2003年ごろから考案され発展して、ついにはPMBOK Guide第6版やPMI Practice Standard for Schedulingにも正式に採用されるようになってきた。

それでは、EVMSの進捗管理における問題点とは何なのか？　これを論じるためには、そもそも『進捗管理』（スケジュール・コントロール）という仕事の目的を、きちんと理解する必要がある。

進捗コントロールの目的とは、大きく次の4点にあると考えることができる。

(1) 現状の正確な把握：

プロジェクトの進行状況が、現時点でどうなっているかを、正確につかむ。プロジェクトを航海に例えるならば、自分の船は今、どこの位置にいるのか。そして、どれくらいの速力で移動中なのか。それを正確に知ることが、まず第一の目的である。船ならば現在はGPSで正確にわかるが、昔は北極星の位置や六分儀から割り出す必要があった。プロジェクトという目に見えない航行も、色々な手がかりから現在位置や速度を求めることが行われる。

(2) リスクと問題点の検知

船の航海のたとえを続けるならば、出発時に海図の上に線を引き、航行計画を立てたはずである。その予定線と現状は、どれくらい一致しているか。予定より進んでいるのか遅れているのか。積み荷の量は予定通りか。航行に要する燃費は想定通りか。こうした点をチェックして、問題があるなら、対策の手立てを取る必要がある。たとえ現状に問題がなくても、台風の発生や航路上の想定外の障害など、この先のリスクについて、定期的にウォッチしておかなければならない。

(3) 完了日時の予測

今のままのペースで行くと、船が目的地に着くのは（つまりプロジェクトが完了するのは）何月何日になりそうかを予測する。これは案外見過ごされがちだが、進捗コントロールの重要な仕事である。完了日時の予測がないと、プロマネが適正に判断できないばかりか、プロジェクトに人を出している関係部門も先の予定が立てられない。だから完了予測のない進捗報告は、単に虚しいレポート作成に過ぎない。なお、完了時点でのコスト予測（完成予想額：Cost EAC = Cost estimate at completion）も当然ながら重要で、完了日時とコストを合わせて「着地点予測」と呼ぶ場合もある。

(4) 次への学びをまとめる

プロジェクトが完了したり、あるいは大きなマイルストーンを超えて別のフェーズに入ったら、それまでの教訓（LL = Lessons Learned）をまとめ、次の航海に備える。これも忘れてはならない進捗コントロールの職務である。

さて、このような見地から、とくに(3)の目的に照らしてみると、EVMSによる進捗コントロールにはいささか不便な点があった。EVMSでは、計画と実績の予実比較のために、コストとスケジュールで二組の指標を計算する。

コスト差異：

　CV (Cost variance) = EV - AC

　CPI (Cost performance index) = EV / AC

スケジュール差異：

　SV (Schedule variance) = EV - PV

　SPI (Schedule performance index) = EV / PV

いずれも差をとるか比をとるかで、合計四種類の指標が出てくる。これらの指標は、どれも、数値が大きければパフォーマンスが高く、プロジェクトがうまく行っていることを示す。

さて、完了時の着地点予測を考えてみよう。コストの場合、通常は次のような計算をする。

Cost EAC = 現時点までの実績コスト（AC） + （今後行うアクティビティの予算額）/ （今後のCPI）

たとえば、予算総額1億円のプロジェクトを考えよう。現時点までに、およそ6割程度のアクティビティが完了しており、それに費やした実績費用ACは7500万円だった。ただ、元の予算は6000万円で済むはずだった（EV = 6000万円）。この場合、CPI = EV / AC = 6000/7500 = 80%である。

そして、残りのアクティビティに必要な費用は、4000万円と当初の計画では想定していた。現状すでに7500万円使っているから、7500 + 4000 = 1億1500万円、と見ていいか？　そうはいくまい。これまで、7500万円かけて、6000万円分の仕事しかできなかったのだ（CPI = 80%）。この先も同じペースで行くと想定すると、

Cost EAC = 7500 + 4000/0.8 = 1億2500万円

が完成予想額だ。2500万円も赤字になる、ということになる。

では、完了日時の予測は、同じようにできるだろうか？　たとえば、上の例で、全体期間は10ヶ月だが、今は7ヶ月経った現時点であり、SPI（=EV/PV）は、CPIと同じく80%だったとしよう。つまり、開始後7ヶ月時点でのPV＝7500のはずだった。だったら、次のように計算していいか？

Time EAC = 現在までの経過時間 + （残りの予定時間）/ （今後のSPI）

　＝ 7ヶ月 + (10 - 7)/0.8 = 10.8ヶ月

そうはいかないのだ。なぜなら、まず、SPIというのはEV/PVという金額の比率指標であって、時間あたりの進捗指標ではないからだ。それにもう一点。今後のSPIは、現在の80%よりも必ず大きくなることが予想されるからだ。というのも、定義からいって、プロジェクト完了時点でのSPIは、100%に戻るためである。

これは、スケジュール差異SVに置き換えても同じである。SVは完了時点で必ずゼロに収束する。図を見て欲しい。CVは、完了時点で、一定の値が残るのが普通だ。だがSVは0に戻ってしまう。

かならずゼロに漸近するような数値が、いつゼロになるかを予測するのは、とても難しい。だから、SVやSPIだけを用いて、完了日時の予測をするのは困難なのである。これがEVMSの持っている弱点だった。

さて、ようやくアーンド・スケジュールの登場である。ES (Earned schedule）の定義は、シンプルである。それは、"Earned Schedule (ES) is the point in time when the current Earned Value was to be accomplished" と定義される(Stratton 2005による)。日本語に訳せば、

「アーンド・スケジュール（ES）とは、現時点での出来高（EV）が達成されるはずだった日付をいう」

となる。図を見てもらえば一目瞭然だろう。そして、ここから二種類の指標が導出される。

　SV(t) (Schedule variance on time) = ES - AT

　SPI(t) (Schedule performance index on time) = (ES - AT) / ES

ここでATとはActual time、すなわち実際日付（現在日付）のことである。そして完了日時予測は、

Time EAC = 現在日付(AT) + （全体工期 − ES）/ SPI(t)

で計算する。上記の例でいうと、かりにEV=6000となる日時が開始後6ヶ月の予定だったとすると、

　ES = 6 - 7 = -1ヶ月

　SPI(t) = 6 / 7 = 86%

　Time EAC = 7 + (10 - 6) / 0.86 = 11.7ヶ月

という計算になる（無論ここでは、現時点までのSPI(t)の値が、今後もあまり変わらないという想定が入っている）。

Earned scheduleの概念と計算式は、米国のWalt Lipkeという人が2003年頃から提案したものだ。なお、アーンド・スケジュール法の各種指標については、次のサイトにまとまっている：

http://www.earnedschedule.com/Terminology.shtml

ただ念のために書いておくと、EVの値から横に線を引いて、PVカーブの日付を求めるアイデア自体は、Lipkeよりも前からあった（たとえばFleming and Koppelman、Anbariなど）。また実務でも、以前からわたし達は進捗率カーブを引いて、何日分進んでいる・遅れていると表現してきた 。そういう意味では、アーンド・スケジュール単体では、それほど独創的とは言えない。

ただ、わたしが注目したのは、このESを使った進捗コントロール手法が、米国防省に広まることで、かなり膨大なデータが蓄積されるだろう、という点だった。なぜなら、EVMS手法の進歩には、米国の防衛宇宙産業での膨大なデータの蓄積が役立ったからだ。

ちなみに、上の完成予想額の計算で、「この先も同じペースで行くと想定すると」と書いたが、これは、今後のCPIも同様な値が続くと、という意味だ。そして、米国におけるEVMSに関連する膨大なデータから、

「プロジェクトのCPI値は、全体期間の最初の2〜3割を過ぎると、良くも悪しくも安定する」

という経験値の集積があったから、使えたのである。そしてSPIは、途中でいったん1から離れても、また1に漸近するという性質のために、このようなデータ傾向が得られないのだ。

ちなみにわたしの記憶が正しければ、米国では50万ドル以上の公共事業では、EVMSを適用することが法律で義務付けられている。そして公共事業のデータだから、それは政府自治体だけでなく、社会全体がエッセンスを共有して使える。こうした各種プロジェクトデータの集積と、経験知の共有は、ある意味オープンな米国社会の強みでもある。

ひるがえって、たとえばわたし達の社会では現在、東京オリンピックを目指して多数の公共プロジェクトが進められているが、そうしたデータは誰がどう蓄積しているのだろうか。たしかに個別案件の予算などは取引上の秘密で、受託企業の競争領域に属するだろう。だが、CPIやSPI(t)などに関する統計分析は、強調領域として、皆の共有すべき知識となるはずであろう。

ともあれ、アーンド・スケジュール法に話を戻すと、この手法の登場によってEVMSの弱点は補強され、プロジェクトの進捗把握と完了日時の予測は、より高い精度でできるようになった −− のだろうか？

そうはいかないのだ。実は、ES法にはまだ、深刻な落とし穴が、一つある。だが、またしても長くなり過ぎたようだ。その問題について説明するのは、また次の機会に譲ることにしよう。

プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 (1)その基本

「アーンド・スケジュール」の概念を初めて知ったのは、2006年のことだった。オーストラリアのシドニーで開かれた、プロジェクト・マネジメントの国際大会ProMAC 2006でのことである。わたしは、後に自分の学位論文のコアになる『RPV（Risk-based Project Value＝リスク基準プロジェクト価値）』の考え方を発表するため、そこに参加していた。

豪州はPM研究の盛んな国であり、この大会も日米豪アジアから様々な講演発表があって、非常に面白かった。その一つが、米国海軍のコンサルタントWalter H. Lipke氏による、「アーンド・スケジュール」の発表だった。それまでのEVMS（Earned value management system）の弱点を、うまく補った手法だと、聞いていて感心した。

そこで、日本に帰ってから、すぐこのサイトでも、新しい方法論の提案があったと記した。

　→「プロジェクト・マネジメントの世界は変わりつつある」（2006-10-11） https://brevis.exblog.jp/4313708/

面白い考え方だから、すぐに日本の学会などでも盛んに紹介されるだろう、と思っていた。だが、これはいささか見込み違いだったようだ。あれほど日本人が大勢参加した大会だったのに、日本で一部の先進的な人がこの手法を研究し始めたのは、さらに数年後のことだった。

それが、10年以上経った今、急にネットなどでもこの用語を見かけるようになった。なぜか？　その理由は、PMBOK Guide第6版に、アーンド・スケジュール法が正式に載ったからである。PMBOK Guideに載ると、PMP資格試験に出るから、勉強の対象になる。試験に出なければ、あまり研究しない。わたし達の社会の、外部からの知恵の学び方には、多少の歪みがあるのではないか？

まあ、そんな皮肉はさておいて、具体的にどう言う方法なのか、説明しよう。

ただ、アーンド・スケジュール手法を理解するためには、まず従来のEVMSにおける考え方をおさらいしておく必要がある。EVMSでのスケジュール・コントロールは、どのような指標を用いてきたのか。

いや、その前に、そもそも進捗コントロールとは、何のためにあるのか？

図を見てほしい。横軸にプロジェクトの開始から終了までの時間を取り、縦軸に使う費用の累積をプロットした、よくある図だ。一般にプロジェクトの開始時期はゆっくり立ち上がり、やがて活況に入るが、最後はまたスローダウンする。関わる人も同じ様に、少数→大人数→少数、という風に変化する。だから普通、このグラフはアルファベットのS字のような形になるため、「Sカーブ」と呼ばれる。

さて、計画段階で予想したSカーブは、図の黒い点線のようだった（計画線＝Planned Valueと呼ぶ）。これに対して、現実の累積出費の線を、現在日付まで引いたら、青い実線のようになった（実績出費＝Actual Cost）。この図から、どんなことが言えるだろうか。

一見してわかる通り、計画時点での出費予定に比べて、実績出費の方が大きくなっている。つまり想定したよりも、お金が出て行っているのだ。これはまずい状態だ！　大変だ！　・・これが普通の感覚だろう。そして、これがたとえば広報予算だとか電気代といった、定常的な出費なら、それは正しい。

しかし、これはプロジェクトなのだ。プロジェクトとは、達成すべきゴールがある、一過性の仕事である。だからそこには、『進捗』の概念がある。進捗が進んでいればいるほど、プロジェクトが早くゴールに到達するから、良いことだ。ところで、仕事が早く進んだら、そのぶん、出費も前倒しで出ていかないだろうか？　その場合、実績出費ACの線は、計画線PVより、左（上）に来るはずである。

となると、この図は、どう読み取るべきなのだろうか。出費が予定よりもかさんだ、まずい状態というべきなのか。それとも、仕事が予定よりも早く進んでいる、良い状態なのか？

答えは、「分からない」、である。この図の2本の線だけでは、プロジェクトの現状が良いのか、まずいのか、区別できない。穴があくほどこの図をにらんで見たって、判断はできない。なぜなら、この図には、「費用」と「進捗」の情報が、混ざっているからだ。その二つを区分するために助けとなるデータがなければ、正しい判断はおぼつかない。

では、その二つを区分するためのデータとは何か？　それは、「その時点までに完了しているアクティビティの予算額を累計した金額」＝「出来高」と呼ばれる量だ。これを英語で、Earned Value= EVという。

出来高（EV）と実績出費（AC）は、何が違うか。実績出費は、すでに完了しているアクティビティに使った、現実の金額の累計だ。だが、出来高は、予算額の累計である点が異なる。たとえば、あるアクティビティは100万円でできるだろうと計画していたが、現実には120万円かかってしまった。EV=100万で、AC=120万である。

しかしEVの線は、元の計画線（PV）も異なる。なぜなら、タイミングが異なるからだ。元の計画では、当該アクティビティは5月15日に完了する予定だった。だが実際には6月1日に完了した。そうなると、PVには5/15に計上されるが、EVには6/01にならないと計上されない。

　　　　　　　　費用　　タイミング

計画線（PV）　　予定　　予定

出来高（EV）　　予定　　実績

実績出費（AC）　実績　　実績　　

そこで、図に3本目の線として、出来高EVの線を描き加えて見たところ、次の図のようになったとしよう。EVの線は、計画線PVよりも下側に来ている。これから、何がわかるか。

出来高EVが、計画線PVよりも小さいということは、

　「すでに完了したアクティビティの予定出費累計」＜「計画上では完了しているはずだったアクティビティの予定出費累計」

であることを示している。言い換えると、このプロジェクトは、予定よりも進捗が遅れているのだ。

さらに、出来高EVは、実績出費ACよりも小さい。これは、

　「すでに完了したアクティビティの予定出費累計」＜「すでに完了したアクティビティの実績出費累計」

を意味する。つまり、見積もっていたよりも大きな費用が出ていっているのだ。

まとめると、こうなる：本プロジェクトは、予定よりも進捗が遅れており、かつ、予定よりも費用がかかっている。だから、非常にやばい状況のプロジェクトなのだ！

非常にまずい状況にあることは、最初の2本の線だけでは、判別できなかった。これがわかったのは、3本目の出来高EVの線を描き加えて、比較したからだ。このように、出来高Earned valueという指標を使って、プロジェクトの進捗とコストについて予実管理する手法の体系を、Earned value management system = EVMSと呼ぶ。

上の表に示したように、EVとPVとを比較すると、両者とも費用は同じなので、タイミングの差＝進捗の差が検出できる。ここで

　SV = EV - PV

を、「スケジュール差異」schedule varianceと呼ぶ。SVは値が大きいほど、良い。マイナスだったら遅れていることを示す。

また、EVとACを比較すると、両方ともタイミングは同じなので、費用の差だけが検出できる。つまり

　CV = EV - AC

は、「コスト差異」cost varianceと呼ばれる量で、これも大きいほど良い。マイナスは、赤字を示す。

スケジュール差異SVも、コスト差異CVも、出来高EVを比較の軸にしている点を覚えておいてほしい。だから、この手法をEVMS（出来高マネジメント・システム）と呼ぶのだ。

EVMSは、WBS（Work Breakdown Structure）、PERT/CPM（クリティカル・パス法）と並んで、モダンPM理論における三本柱となっている。周知の通りプロジェクトの三大制約条件は、コスト・スコープ・スケジュールである。そしてEVMSはコストを、WBSはスコープを、PERT/CPMはスケジュールを、定量化しコントロールするための方法論なのだ。だから、この三つの概念と手法を理解し使いこなせるかが、プロジェクト・マネジメント能力のバロメーターになっている。

ただし、スケジュール差異SVは、実務的には、若干使いにくい点がある。なぜなら、SV＝EV-PVで、その単位は金額なのだ。現時点までにPVは1000万円になっているはずだった。だが現時点の出来高EVは700万円でしかない。だから進捗が遅れているわけだが、

　「プロジェクトはどれくらい遅れているのか？」

　「はい、300万円ほど、遅れています。」

・・じゃ、話がわかりにくい。そこで、実務の世界では、『進捗率』に換算して議論するのが普通だ。

　進捗率＝[現在のEV]／[完了時のEV]

たとえば上記プロジェクトの完了時のEV（ということは、とりもなおさず予算総額だが）が1500万円だったとしよう。EVが700万円なら、進捗率は700 / 1500＝46.7%、ということになる。計画線では、66.7%の進捗が達成されているはずだった。だが現実は46.7%しかない。遅れは、全体の20%ぶんに相当する・・この方が、はるかに直感的で分かりやすい。

という訳で、EVMSによる進捗のコントロールは、理屈の上でもすっきりしているし、現実にも計測しやすい、はずであった。

だが実は、EVMSには一つ、非常に厄介な弱点があった。そして、それを克服するために、「アーンド・スケジュール法」が考案されたのだった。長くなって来たので、続きは次回書こう。

（この項つづく）

書評：「超予測力」 フィリップ・E・テトロック＆ダン・ガードナー著

「超予測力」　フィリップ・E・テトロック＆ダン・ガードナー（Amazon.com）

「イタリアは今年末までに債務再編ないし債務不履行（デフォルト）をするか？」

「欧州の調査機関は、故アラファト議長の遺体から、通常より高濃度のボロニウムを検出するか？」

「ロンドンの金価格は半年以内に1oz $1,850を超えるか？」

「今後8ヶ月以内にエボラウィルスの発生を報告する国は何ヶ国にのぼるか？」

こうした未来予測に関わる問いは、経済や政治や環境に対して、いずれも重要な影響を与える問題だ。だから普通は、その分野の専門家に、回答をたずねる。だが、えてして専門家も、「可能性はありますが・・」といった曖昧な語尾をつけて、明言を避けることが多い。

専門家の未来予測が案外頼りにならない、という話だったら、「さもありなん」と感じるだけだ。ところが、こうした広い範囲に渡る問題について、各分野の専門家連中をはるかに上回る、正確な未来予測のできる人たちがいると聞いたら、驚かないだろうか。著者は、こうした『超予測者』が存在することを、初めて見出し、研究としてまとめた。その成果が、この本だ。

では彼ら『超予測者』は、どういう能力を持った、どういう職業の人たちなのだろうか。じつは、ほとんどが市井の無名の一般人だった。だが彼らは、いったい全体、その驚嘆すべき予測能力を、どのようにして身につけたのだろうか？

これは、未来予測についての本である。昨年、わたしは仕事の関係で、2030年頃をターゲットとした長期予測に関する本を、何冊も集める必要があった。公的機関・メディア・有名無名のシンクタンク・・さまざまな未来像を読んだが、本書はその中で、最も面白かった一冊である。

「企業経営者、政府高官から一般人まで、有効性や安全生の確認されていない得体の知れない薬なら絶対に飲まないが、こと予測については行商人が荷台から出してくる不老不死の薬と同じぐらい怪しいものでもさっさと金を払う」と、著者は言う。だが、それはこれまで、諸専門家による未来予測が言いっ放しで、だれも結果を採点し公平に評価しなかったからだ。

著者のテトロックは、意思決定に関わる社会心理学の研究者で、ペンシルバニア大学経営学部の教授だ。ノーベル経済学賞を受賞した、著名な行動経済学者ダニエル・カーネマンとも親交がある。彼が米国政府のIARPA（情報先端研究計画局）の資金を得て研究したテーマが、「未来予測能力の客観評価」であった。

周知の通り、米国のインテリジェンス・コミュニティ（CIA・NSA・DIAなど情報機関と関係者の総称）は、2002年に「サダム・フセインのイラク政府が大量破壊兵器を保有している」と報告した。CIA長官のテネットは、これを「スラムダンク」（確実）だ、とまで表現した。その報告を元に、アメリカはイラク戦争を起こした。だが知っての通り、戦争という大きな犠牲をはらってイラク全土を探したが、結局、大量破壊兵器保有の証拠は見つからなかった。

この結果、米国情報機関の官僚組織の威信は、根底から揺らいだ、という。2006年、政府内に「情報先端研究計画局」（IARPA）が発足する。略称はもちろん、インターネットの生みの親であるDARPAを意識してとったものだ。そして、アメリカ学術研究会議（NRC）に、情報分析に関する先端研究を依頼する。

彼らは、「チュニジア大統領は来月亡命するか？」「H5N1型インフルエンザで今後6ヶ月間に中国で10名以上の死者が出るか？」といった共通の予測問題に関する、複数研究者間でのトーナメントを提案した。それは2010年から4年間かけた、大規模研究プロジェクトであった。そして彼は一般人のボランティアを募って、普通の人の予測能力向上について調べようとした。だが、こころで驚くべき発見をする。

著者テトロックの研究チームに応募したボランティアの一人が、ダグ・ローチという初老の引退したプログラマだった。民間人の彼は、一切の機密文書を読める立場にないのに、豪華な執務スペースと給料をもらっているベテラン情報分析官たちさえ、全く太刀打ちできないほどの好成績を収めたのだ。彼の予測能力を示す「ブライアー・スコア」は0.14で、驚異的だった。

ちなみにブライアー・スコアBSの定義とは、次のようなものだ（英語版Wikipediaによる ）：

　BS =（予測確率 − 実測値）の2乗の平均値

ここで実測値は、発生したら1、発生しなかったら0とする。この定義では、スコアは小さいほど予測として優秀になる。百発百中の正解の場合、スコア＝0となり、逆にすべて外れた場合、スコア＝1である。五分五分（当てずっぽう）だったら0.25。

天気予報が降水確率30％と予測して、本当に雨が降らなかったら、その回のBS＝0.09だ。逆に外れたら、0.49になる。ただし、本書ではなぜか、上の定義を2倍した数値を使っている。だからダグ・ローチの年間スコアが平均0.14（上記の計算式なら0.07）というのは、百を超える難問に対し、次々正確に回答し続けたことを示している。

未来予測というのは、専門家でもしばしば間違える。たとえば有名な例では、2007年4月、マイクロソフト社CEOバルマーは、「iPhoneがいずれ注目に値するほどの市場シェアを取ることなどありえない。可能性ゼロだ」と予測した（p.69）。

どうしてこういう間違いをするのか。それは、専門家といえど、さまざまな判断へのバイアスが入るからだ。たとえば、自分の政治的信念だったり、経済学的な学説（仮説）である。強い信念を持つ人は、昔話のハリネズミに似て、主張もはっきりしているが、事実の変化をなかなか柔軟に受け入れない。

だから著者の調査によると、政治予測でも経済予測の分野でも、「（メディアでの）知名度と、正確さには逆相関が見られた。有名な専門家ほど、その予測の正確さは低かった」（p.102）。なぜなら、メディアは「ハリネズミ型」の、自説に固執するタイプの専門家を好んで使うからだ。

では、超予測者たちは、どんなタイプの人間で、どのようにして困難な問題の確率を推算するのか。彼らは聡明だが、知能テストでみると別に天才ではない。数字に比較的強いが、現代数学に精通している訳でもない。情報通でもニュースオタクでもない。つまり、知的だが、普通の人間なのだ。

ただ、彼らは予測問題に取り組む際に、複雑な問題を比較的取り扱いやすい小問題に分解する。たとえば

「故アラファト議長の遺体から、通常より高濃度のボロニウムを検出するか？」の問いを、超予測者のひとりであるフラックは、こんな風なステップに分解して考えた：

(1) 減衰の速いボロニウムを、本当に数年前の遺体から検出できる方法はあるのか？

(2) ボロニウム陽性の結果が出るほどアラファトの遺体が汚染されることがありうるか？

(3) イスラエルはボロニウムを保有ないし入手できたか？

(4) イスラエルは大きなリスクも厭わないほどアラファトの死を望んでいたか？

(5) イスラエルにはボロニウムをアラファトに守る手立てがあったか？

あるいは、フランスの風刺新聞社シャルリー・エブドがテロに襲われる事件があった直後、IARPAは「今後70日間にフランス、イギリス、ドイツ、など欧州主要8カ国でイスラム過激派によるテロは起こるか」という問題を出した。

これに対し、ログという超予測者は、こうした。まず

(1) 過去5年間で対象8カ国に何件のテロ攻撃があったか？

を調べて年平均1.5回という数値を得た。しかし

(2) 近年はISによる影響が増大し、件数は増大傾向にある

(3) ただ同時に、各所でセキュリティ対策が大幅に強化された

ここから、基準値の年間テロ件数を1.8とする。対象期間は70日だから、発生確率は34%となる、と推定した。

ただ彼は、この予測を仲間に公開し、チームメイトの意見も聞いている。もっと多くの視点を取り入れようとしたのだ。そして超予測者は、自分で立てた予測値を修正することを厭わない。そして、たとえネットで接触するだけのバーチャルチームであっても、超予測者にはチームが有効だった。彼らの「スーパーチーム」の予想は、予測市場のそれをも上回った（p.266）。経済学者がいう、「市場は何でも知っている」というテーゼより、超予測者たちの方が上手だったのだ。

ちなみに超予測者は37%とか4%とか、非常に目の細かい予測値を出す。「彼らの予測の、ゆうに三分の一は1%単位である」（p.191）。そして、その数値を、新たな情報を得るに従い、小刻みにアップデートしていく。これが超予測者に共通するやり方だ。

なお、「ただ一度だけの出来事に、本当に『確率』を言えるのか？　確率とはサイコロ投げのように、繰返し試行での割合をいうのではないか」と、疑問を感じる読者もおられるかもしれない。上記のようなケースでいう確率とは、ベイズ推計における『主観確率』である。ただ、主観だからいいかげんで理論化できない、ということではない。主観確率は「命題への信憑性」を0〜1の範囲で与える、という形をとり、その上にも厳密な確率理論を立てることができる。

一般にプロジェクトにおける確率推計（とくにリスク確率のアセスメント）では、主観確率を扱っている訳である。「このプロジェクトの受注確率は」と論じる場合、それはベイズ推計の議論なのだ。

わたしは以前、著書の中で、計画立案という仕事を次のような式で定義した：

　計画＝予測＋意思決定

計画を立てるには、その基礎として、予測が必要なのだ。ただ、砲弾の着地点予測と違って、ビジネスや市場の世界における予測問題は、複雑である。そして信念だの希望的観測だのが、まぎれこみやすい。だから、ちゃんとした未来予測の手法論を学ぶことが、絶対に重要だ。

だから、この本に価値があるのである。巻末にある「超予測者をめざすための10の心得」を読むだけでも、価値がある。実際、トーナメント参加者にこの心得を読ませたところ、その後1年間の予測の正確性が10%向上したという。

もちろん、どんな予測を立てても、絶対に当たる、ということはない。では、予測や計画など意味がないのか？　それについて、著者はアイゼンハワー元米国大統領の言葉を引用している（p.312）。軍人だった彼はかつて、こう語ったそうだ。

「計画は役に立たない。だが計画を立てるプロセスは絶対に必要だ。」

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

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

デジタル・トランスフォーメーション（略称DX）という概念が、今やビジネス界を席巻しています。最近発達の著しい『デジタル技術』をキーに、新しいビジネスドメインを開拓し、事業のあり方を変える、との意味で使われていることは、皆さんもご存知のことと思います。

そしてDXのための手法として、デザイン思考（Design Thinking）が注目されています。デザイン思考とワークショップ形式で衆知を結集し、アジャイル開発によってその成果をMVP（Minimum Viable Products）に結実します。これを核に、新しい価値を創出するのだ、という説明をよく聞くようになりました。これは従来の、「ITシステムは業務の効率化が目的」「システムはSIerが受託開発する」「開発プロジェクトはウォーターフォール型で遂行する」という常識から、相当に飛躍することを要請します。

そこで今回は、日本を代表するSI事業者である富士通のシニアフェロー・宮田一雄様をお招きして、同社におけるデジタル・トランスフォーメーションへの取り組みについてお話いただきます。宮田様は元・富士通ウェストの社長で、TOC理論によるクリティカルチェーン実践なども進めておられましたが、新たに本社で「デジタルフロント」ビジネスグループを立ち上げ、陣頭指揮をとられています。

同社が顧客のDXを支援する取り組みも興味深いものですが、同時に、天下の富士通さんが、従来の受託SI事業から転身（トランスフォーメーション）する試みとしても、非常に注目すべきと思います。

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

＜記＞

■日時：2019年5月21日（火）　18：30～20：30

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

　5F スペース：509AB

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

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

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

■講演タイトル：

「デジタル時代に対応する富士通の取組ご紹介

　～　デジタルイノベータの育成　～」

■概要：

　DXの潮流の中、富士通自身が新たな価値を創造しないと破壊されてしまうという危機感を強く感じている。

　お客様のDX推進パートナーとして認知されるために、2017年1月に社内出島としてデジタルフロントビジネスグループを設立して、社内のモード2人材を発掘して新たなデジタル人材の育成とビジネス開発に取り組んできた。

　2年間の人材育成の取組内容や生まれてきた成果と課題、そして今後目指す2階建て経営への展望を紹介する。

■講師：宮田 一雄（みやた かずお）

　富士通株式会社 シニアフェロー

■講師略歴：

　1977年富士通入社。SEとして銀行（信金・地銀）・証券・通信キャリアなど、数多くのお客様を担当。

SEとして、プロジェクトマネージャーとして、大規模SIのプロジェクトを数多く経験する。

　2011年に株式会社富士通アドバンストソリューションズ、2015年から株式会社富士通システムズ・ウエストの代表取締役社長に就任。ICT業界におけるプロジェクトマネジメントの問題改善のため、TOCやCCPM理論に基づいた取り組みを進める。2016年11月から富士通株式会社の執行役員常務に就任。

　デジタル社会に向けたビジネスの変革と人材育成を進め、2019年2月からMobilityビジネスを担当。

■参加費用：無料。

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

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

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

佐藤知一＠日揮（株）

感情のマネジメントとは、どういう事を指すのか

夜中に目が覚めて、しばらく眠れなくなった。仕事の多忙で、身体は疲れているはずだ。なのに、うまく眠れないまま、いつの間にか、ある問題状況について考え始めていた。最近起きた、ひどくイライラするトラブルだ。おかげで頭がさえて、さらに眠りから遠ざかってしまう。「夜中にそんな事を考えても、仕方がない」−−そう自分に言い聞かせてみたが、心はまたその悩みに戻って行く。そして堂々巡りの思考の中で、休息すべき時間が失われてしまう・・

こういう経験をしたことがない人は、うらやましい。働いていて悩みが全くない人は、滅多にいないだろうが、悩みに煩わされる程度は、人によって違うようにも思える。夜中に目がさえるような時は、起きている間も、いつの間にかその問題を考え続けている。ただ、考えるといっても、たいていは同じ場所を巡っているだけで、出口の見つからないことが多い。つまり、脳の中のある部分がずっとループしたまま回り続けていて、メモリやリソースを占有してしまっている感じだ。

とはいえ、わたし達の脳がコンピュータと違うのは、そこに『感情』というモードが伴うことだ。怒りだとか、不安だとか、恐れだとか。もちろん幸福という感情だってたまにはあるが、夜中に幸せすぎて目が冴えたという体験は、まだない。大抵は不快な、ネガティブな感情が伴っている。いや、逆かもしれない。感情的な問題がまずあって、それを解決したくて、知的な回路がぐるぐる回っている、という事なのだろう。

感情とは、なんだろうか。それは、マネージすることができるのだろうか？

自分は感情というものに対して、決定的に鈍感なのではないか。そう、疑い始めたのは、中年になってからだった。ずっと技術職だったから、理屈を通すことで仕事を回してきた。若いうちは、それで仕事を回せると思ってきた。

だが、プロジェクトというのは、複数の人間が協力し合って、共通の目的を達成する仕事である。人と協力するには、人の役割分担や能力も大切だが、人のモチベーション、その気分や感情も大切だ。信頼関係のないところに、良い仕事は生まれない。

自分はちゃんとチームを動かしているつもりなのに、「〇〇さん、あとで怒ってましたよ」「××君、ひどく疲れてがっかりしていたね」といった指摘を、人から受けることもたびたびあった。そして家族からも、他人の感情について鈍感だ、と思い知らされるに至って、これは何とかしなければ、という問題意識が生まれてきた。

先日、わたしが主催する「プロジェクト＆プログラム・アナリシス研究部会」で、『感情のマネジメント』という珍しいテーマを選んで講演してもらうことにしたのも、その問題意識からだった。アイシンク（株）の丸山奈緒子様に講師をお願いした。ところで驚いたことに、この回は過去最高の参加希望者があり、しかも初参加の方が多かった。このテーマに関心を持つ人が自分だけでないことに、あらためて印象付けられた。

以下、わたしが学んだことを、研究部会における丸山さんの講演資料「プロジェクトマネジャーが高めたい『感情マネジメント』スキル」をベースに、多少引用させていただくが、もちろん文責は筆者にある。

まず、感情とは何か、である。

当たり前だが、わたし達が抱える感情には、多種多様な種類がある。では、何種類に分けられるのか？　じつは感情というものは、基本的な分類基準さえ、世間的には確立していないのだ。自家用車にはどんな種類があるか、金融投資にはどんな種類があるのか、わたし達は大まかな分類の軸をあげることができる。だが、感情はそれができない。それくらい、近代的なわたし達の生活において暗黒大陸、ないし未開の沃野なのだ。

それでも、とりあえず感情にはポジティブとネガティブがありそうだ、というくらいは分かる。ネガティブ感情にしばしば悩まされると、上にも書いた。では、ネガティブな感情は、さらにどう区分できるのか？

わたし達は赤ん坊の時から、感情をもっている。知性や自我の前から、あるのだ。ただ最初は、未分化な状態にある。自分が成長していく過程で、少しずつ、「あんたは怒ってるの？」「うれしそうね」「ぼくはそれ悲しい」「さびしいな」などと、言葉で表現するようになる。名付けることによって、感情は対象化され、また自分でも気付きやすくなるものらしい。感情の分類と、感情の発達・分化は関係しているのだ。

そこで講演では、参加者に、自分が感じている感情を、言葉と数字を使って、表の形で書いて見るワークが出題された。直近の一週間を振り返って、自分はどんな時、どの感情を感じていたか。その強さは0-100%であらわすと、何％か？

単純なワークだが、これをやっていると、自分が毎日、いろんな気持ちを抱きながら過ごしている事に、あらためて気づく。それもプライベートだけではない。職場などの公的な時間でも、いろんな感情とともにいるのだ。

丸山さんによると、感情には、二つの重要な機能がある。一つ目は、自分自身への「信号」として、である。感情は、自分にとって重要な何かが起きていることを、知らせる。それによって、直接的具体的な行動を促す働きがある、という。たとえば、怒りは「戦え！」「相手を排斥しろ」という信号だし、恐れは「走れ、危険が迫っている！」 と自分に知らせてくれる。

もう一つは、他者との「コミュニケーション」を活性化する機能だ。感情は、他者に自分に関する副次的情報を伝えることで、他者とのコミュニケーション活性化のきっかけとなる。たとえば、悲しみは「助けて！」「わたしは傷ついています」と他人に訴えかける力がある。喜びは、「協力しよう」「再現しよう」 という気持ちを伝えてくれる。

ポジティブ感情には、「心身を回復する」ないし「注意と行動の範囲を広げる」働きがある。そして、ポジティブな感情は、その大きさ・深さよりも「頻度」が大切だという主張にも感心した。小さくても、頻繁に、自分に対してポジティブな感情のストロークを蓄積する。それがストレスを軽減するのだろう。

講演はさらに、ネガティブ感情を受け入れる、というテーマに進む。ネガティブな感情も、適度であれば、自分にメリットをもたらす。不安は、慎重さや準備、予防策のきっかけになるのだ。しかし、不安感情が過剰だと、デメリットが目立つようになる。パニックになる、他のことが手につかない、などの状態に陥るからだ。

そして、自分のネガティブ感情に「応対戦略」を考えるワークを、皆で行った。二人一組になって、それぞれ、自分がしょっちゅう悩まされるネガティブ感情をとりあげ、それに「あだ名」をつけるのだ。このとき、ちょっとコミカルなキャラづけになるような名前を考えるのがいい、という。

自分の場合は『怒り』だな、とわたしは思った。じつは気が短いので、つまらぬことでもすぐ怒ってしまう。とくに馬鹿げた、筋道の通らない話をされると、ついカッとなり、それが攻撃的な口調となって出てしまう。これで何度、損をして痛い目にあったことか。では、なんてあだ名をつけようか。

よし、「イカール大帝」にしよう、と決めた。ご存知の通り西洋史には、カール大帝という、英雄だが戦争好きな君主が出てくる。それのもじりだ。イカール大帝が登場すると、しょっちゅう、あちこちでケンカをやらかして、まずい事態を引き起こす。自分の中にいるのだから、そんなに偉大な存在ではないけれど、暴君なのだ。では、どんな時に現れてくるのか。この人と、どう付き合ったらいいか。それを考えて、相方に説明し、一緒に相談する。

これはなかなか興味深い体験だった。何より、自分が前からとらわれている感情を対象化し、しかもコミカルに擬人化するところがいい。そうすると自分にとって、何とか応対可能な相手だという感じがする。あだ名をつけるというアイデアが、卓抜だ。さすが専門家はだてに専門家ではないな、と思った。

それと同時に、こうした研修講演にはワークが必須なのだ、と気づいた。聴いて、知った気になるだけでは、自分の行動に結びつかない。身に着けるには、練習が必要なのだ。ただ、実りあるワークのためには、ある程度、自分の感情を人に晒せるような、相互に信頼感のある場づくりが必須である。

今回は、本来1日かかる研修コースの内容を、丸山さんを拝み倒して、わずか1時間半に凝集してもらった。ただ、明らかにこれだけで十分ではない。だから、自分自身で感情に気づくエクササイズを、日常で繰り返す方がいい。そのためにも、日誌による「ふりかえり」の習慣は有益だろうと思う。

ところで、以下は個人的な感想ないし疑問だが、はたして感情とは「マネージ」「コントロール」するべき対象なのだろうか？

感情のマネジメントという考え方が広まった背景には、EQという概念の普及も関係しているらしい。EQは、80年代後半に米国のメイヤーとサドベイが提唱したもので、IQ（知能指数）にヒントを得た用語であある。彼らは、「感情をうまく管理し、利用することは、知能である」と主張する。

優秀なリーダーは、自分の感情を把握・コントロールする能力と、他者の感情を知覚する能力が優れている、という研究があり、彼らの主張はこれに基づいている。つまり、ビジネスの成功には、知的なIQと、感情のEQが必要だ、という主張である。まあ、ある意味、いかにも「ビジネスの成功＝社会的理想」とする米国的な考え方ではある。

ところで、日本語には「知情意」という言葉がある。知性、意思、感情という、心の働きの主要な3つを表した言葉だ。この三つについて、上記のEQのような考え方では、意思に基づいて知性を働かせ、その知性によって感情をマネージする、という風にとらえられる。つまり、

　意思＞知性＞感情

という優越関係にあるようだ。ただ、本当に感情とは、自分（自我の持つ意思・目的）が利用すべき資源にすぎないのか。暴れん坊だからコントロールすべき、家畜のような存在なのだろうか？

感情は、じつは自分の一部ではないのか。知性や意思と対等な、自分自身を作り上げる構成要素ではないか。そういう風にも、わたしには思える。感情の働きは、じつは自分の生に意味や価値を与えるのではないか。

人間は、なぜかしらないが、感情を共有したがる生き物である。丸山さんはこのことを、感情には「伝染性」がある、と表現された。そしてまた、感情には「流れ」があり、それはお金の流れと同様に重要だ、という経営者もいる。興味深い考えだ。

そして、感情は身体とかなり直接、結びついている。負の感情が肉体的な不調を呼び起こすことも、よくある。身体だって、自分の一部であって、単に「自分の所有物」ではあるまい。所有物みたいに思って暮らしていると、そのうち、身体の反乱によって痛い目にあう日が来る。同じように、感情をただ「マネジメント」の対象として、上から目線で考えるのは、いささか一方的だと感じるのだ。

「プロマネの仕事は技術をリードすることだ、だから優秀な技術者がやればいい、と信じている組織が世間ではほとんどです。だが本当は、感情とリスクのマネジメントがその8割以上なのではないかと、参加した皆さんもきっと思われるようになるはずです。」--研究部会の案内文に、わたしはそう書いた。

夜、目覚めて眠れず困る時間をすごす代わりに、自分の中の感情に気づき、自分を支える一部として認め共存することが必要なのではないか。そして、他者の感情をも、同じように尊重することが大切なのではないか。これが、理詰めで世の中を渡ろうとしてきたわたし自身の、最近の本心である。

BOM/部品表に関するセミナー講演のお知らせ（6月18日・東京）

お知らせです。

来る6月18日(火)に、BOM/部品表に関する有償セミナーを行います。場所は東京・新宿です。

ご承知のとおりBOM/部品表の構築と保守は、製造業にとって古くて新しい問題です。わたしは2004年に「BOM/部品表入門」を上梓しましたが、この本は発刊後15年経っても、いまだに現役です。昨年も増刷され累計1万部を超えたばかりか、中国語版もかなり売れています。

それはしかし、BOMのマネジメントに関わる根本の問題が、多くの企業で、未解決のまま長く残っている事を意味します。とくに近年は、

　・新製品開発・投入のサイクルが早くなったことと、

　・製造のサプライチェーンが国境をまたいで海外に伸びたこと、

　・企業買収や提携が進んでいること

などの要因が相まって、BOMの維持運用を難しくしています。

ともあれ、近年製造業でも多少は情報化投資の余裕が出てきたことと、データ・サイエンスや統合データ・マネジメントに関心が集まったことで、ふたたび注目されているのでしょう。また過去15年間に、この分野でたしかに進展もありました。たとえばBOP（Bill of Process＝工程表）概念の普及や、海外を中心としたPLM（Product Lifecycle Management）ソフトウェアの発達などが挙げられます。

わたしは最近、有償セミナー講師をいささか控えてているため、このテーマで講演するのは2年ぶりとなります。今回はとくに、著書に詳しく書いた量産型の製造業だけでなく、BOMを扱いにくい個別受注生産における知恵にも光を当てて、「自分で考え身につく」セミナーを目指します。

この問題に関心のある方のご来聴をお待ちしております。

＜記＞

日時：　2019年6月18日(火)　10:30～17:30

テーマ：　「BOM／部品表の基礎と効果的な構築・活用ポイント　～演習付～」

主催：　日本テクノセンター

会場：　〒163-0722　東京都新宿区西新宿二丁目7番1号

　　　　　小田急第一生命ビル22F

セミナー詳細：　下記をご参照ください

　　　　　→詳しい開催案内

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

　よろしくお願いします。

　　　　　　　　　　　　　　　（佐藤知一）

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生産を導入しても、自社のサプライチェーン特性に合わない場合が多いばかりか、むしろ製造現場が混乱疲弊するばかりだ、という認識を持っていただきたい。そして、それを財界の中で広めてほしい。

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

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

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