人気ブログランキング |

<   2020年 08月 ( 4 )   > この月の画像一覧

お知らせ:BOM/部品表とPMに関するオンライン講演を行います(9月10日・9月17日)

えー、前の記事では「この項続く」と書いたばかりですが、ここでスポンサーからお知らせです(笑)。
9月に2件のオンライン講演を行います。前者はエンジニアリング・チェーンとPLMに関する話題(無料)で、後者はスケジューリング学会シンポジウム(有償)でのプロジェクト・マネジメントに関する研究発表です。

実はつい最近、拙著『BOM/部品表入門』の増刷が決まりました。おかげさまで累計1万2千部です。2004年に上梓した一種の専門書が、16年後まで現役で売れ続けているのはとてもうれしいこですが、逆にそれだけBOM関係の情報のニーズが高いのだろうなと想像します。結局、設計から製造への機能的な橋渡しに悩む企業が多いからでしょう。同書の中国語版も売れ続けていますので、悩んでいるのは海を隔てた向こう側も変わらないようです。

今年の『ものづくり白書』でも、「サプライチェーン」と「エンジニアリング・チェーン」が生産で合流する、という概念の説明が出てきます。サプライチェーンは物づくりの順番に従い、受発注から始まって、生産計画→生産→流通・販売→保守・アフターサービス、とつながっていきます。これに対して縦軸は、研究開発→商品企画→製品設計、という製品開発の「エンジニアリング・チェーン」がぶつかり、両者が『生産』で合流します(より正確に言うと、製品設計の後には、工程設計→試作→量産準備→がはさまってと生産につながる訳ですが)。

エンジニアリング・チェーンを統合的に支えるソフトウェアは、PLM(Product Lifecycle Management)と呼ばれます。現時点では、その主力製品は欧米製です。複数部署をまたいで、データ中心に業務プロセスを統合する取り組みは、欧米製造業の方が先を走っているのでしょう。その統合の要は部品表/BOMデータベースで、その中にE-BOM→M-BOMが整合性をとって格納される姿になっています。

ところが現実には、PLMソフトの導入と、 SCM/生産管理系との統合は、なかなか一筋縄ではいきません。もともとPLMは、量産型の製造業を念頭に置いて作られたからです。他方、日本の多くの企業は受注生産、とくに個別性の強い受注設計生産の形態に取り組んでいます。こういう状況下で、BOMのあるべき姿について、皆が頭をひねる必要が出てきている訳です。

ここで登場するのが、設計という業務にまつわる「個別性の罠」です。どんな設計作業でも、つねに一度限りの営為です。これをどうマネージするかに、多くの組織が悩んでいます。

そして、そこで鍵となるのがプロジェクト・マネジメント(PM)の技術です。プロジェクトは、つねに個別性との戦いです。そこでは繰り返し型業務における、お得意の「PDCAによるカイゼン」が、うまく働かないからです。そうした意味で、製造業におけるPMの有用性は非常に高まっています。

しかし、現代のPM手法にも大きな課題があります。とくにプロジェクトが大規模化すると、「崩壊現象」と呼ぶべき事象が、ときおり起きるのです。人員を追加しても生産性が上がらず、いわゆるデスマーチ状態に陥って、いつ全体が終わるか誰も見えない、そういう状況です。モダンPM理論は、EVMSとかクリティカル・パス法などの技法で、プロジェクトの先行きを予測・計画していきます。しかし、それが機能しなくなる状況が生じるのですから、今の理論にはまだ、足りていない部分が残っている訳です。

2つのセミナーはテーマも内容も異なりますが、ここに述べたような問題をめぐって、皆さんと一緒に議論できればと思っています。関心のある方のご来聴をお待ちしております。


<記>

(1) 「BOM/部品表とエンジニアリング・チェーンのマネジメント」

日時: 2020年9月10日(木) 13:30 ~ 16:45(小生の講演は13:35~14:35の時間帯です)
テーマ: 「BOMで改善! 中小企業の設計効率を上げる業務改革」
主催: エスツーアイ(株)+ダッソーシステムズ(株)
セミナー詳細: 下記をご参照ください(無料、定員なし)
  なお、セミナータイトルには「中小企業」と書いてあるのですが、中堅あるいは大企業の方も歓迎です。
  むしろBOMマネジメントの問題は、ある規模以上の組織の方が難しい面がありますので。


(2) 「プロジェクトのコスト超過と崩壊現象のシミュレーション」

日時: 2020年9月17日(木) 14:30~15:45
主催: スケジューリング学会 「スケジューリングシンポジウム2020」
    オーガナイズドセッション「プロジェクト・マネジメントの教育と実践をめぐって」講演(1)
概要:
プロジェクトの完了日予測と、完了時点でのコスト予測は、プロジェクト・マネジメントにおける重要な課題である。従来、完了日はPERT/CPMのクリティカル・パス分析と、各アクティビティの進捗から計算してきた。また完了時点のコスト予測(Cost EAC)はEVMS手法により推定した。これらの手法はいずれも確定的予測であって、リスクと不確実性を反映することが難しい。他方、プロジェクトの実践現場においては、大きな納期遅れとコスト超過を伴う「崩壊現象」が、時おり生じることが知られている。本発表では、プロジェクトのアクティビティ・ネットワークにおける遅延とコスト超過の連鎖反応のパターンについて、シミュレーションを元に考察する。

シンポジウム詳細: 下記をご参照ください(有償です)


以上、よろしくお願いします。
               (佐藤知一)


by Tomoichi_Sato | 2020-08-27 22:25 | サプライチェーン | Comments(0)

設計の知恵を、リアルな価値に変えるために 〜 問題の所在

エンジニアだったら誰もが、「自分の出した知恵で、評価されたい」と思うだろう。優れたアイデアを出せば、それが高く評価される。逆に、つまらぬ設計しかできない者は、たいして評価されない。世の中は、そういう風であってほしい、と感じている人は多いはずだ。

評価という言葉には、いろいろな意味がある。同僚や周囲からリスペクトされるのも、評価だ。新しい重要な仕事のリーダー格に取り立てられたり、昇進するのも、評価だ。もちろん、給料やボーナスに反映されるのも、評価だ。ともあれ、優れた知恵を出したら、尊敬され、リーダー役に抜擢され、ちゃんと経済的にも報われるべきだ。つまり、良い設計の知恵は、リアルな価値に、ちゃんと具現化されてほしい。

だが、そうあってほしいと感じる人が多いのだとしたら、それは逆に、世の中はそうなっていない、という事の証拠であろう。自分の身の回りを見る限り、あんまりそうなっていないな、なんとも世の中アンフェアだ。それが多くのエンジニアの実感ではないか?

*** *** ***

「SIer」という業態は、本当に将来性があるのか、という質問を、SI業界の人に会うたびに、何年も前からするようになっている。説明の要はないと思うが、SIとはシステム・インテグレーションSystems Integratrionの略で、ITシステムの受託開発ビジネスを指す。そしてSIer(エスアイヤーと読む)は、それを業としている会社のことだ。将来性があるのかという質問は、もう少し今風に表現するなら、『サステイナブルなビジネス』なのか、ということだ。

こういう質問をすると、SI業界の人はたいてい、苦笑いしたような表情になって、「そうですねえ・・」と言葉を探す。「もちろんですよ!」という希望と自信にあふれた答えがかえってくることは、まずない。「正直、将来性は無いんじゃないでしょうか」と、ぼそっとつぶやかれることもある(もちろん会社の会議室ではなく、懇親会の席上であったりはするが)。そういう状況だから、優秀な若手人材も、なかなか集めにくいという問題が生じる。

ITとかデジタル技術とかいうのは、時代の先端をゆく技術分野である。そして知恵のカタマリであるはずのシステムを作っている。なのに、なぜ、将来性があるかという質問に、前向きな答えが来ないのか。なぜ有能な若手にそっぽを向かれるのか? それは、受注型プロジェクトで金を稼ぐ、この業界の構造ないし行動習慣に問題があると、多くの人が認識しているからだ。

日本のIT業界の特徴は、ITエンジニアの大半(約7割)が、ITベンダー側に属していて、ユーザ企業側にはそれほどいない事である。これについては、元日経コンピュータ編集長の谷島宣之氏が『ソフトを他人に作らせる日本、自分で作る米国』 という興味深い本を著して以来、広く知られるようになった。つまり、企業内の業務システムの殆どは、自社内で作るのではなく、外部のIT企業に作らせるのである。そこで、ITシステム開発(システム・インテグレーション)は、受注型プロジェクトとして遂行されることになる。

別に内製ではなく外注でもいいじゃないか、大規模なシステム開発プロジェクトなんて、普通は何年に一回しか無い。その時のために、ITエンジニアを大勢、社内に抱えておくのはもったいない。――そういう意見だって、もちろんあるだろう。

ついでにいうと、上述の谷島宣之氏の著書によると、米国では日本と逆に、ITエンジニアの7割がユーザ企業にいて、自社のシステム開発プロジェクトに携わっていると書かれている。それはそのとおりだが、米国では企業間の転職が多く、プロマネ職種の人達も、渡り鳥のように案件単位であの会社からこの会社へと、わたっていくことが少なくない。ある意味、彼らだって「外の人」なのである。

だから、日本のSI分野の問題は、内製か外注かにあるのではない。実は、「設計で知恵を出しても、ビジネスとして評価されにくい」点に、根本原因があるのだ。エンジニア個人の評価が、最終的にはポジションや給料で決まるように、企業の評価は、利益を出したり、継続的に良い条件で仕事をもらえるか、という点で測られる。つまり、ビジネスとしてのサステナビリティである。

今日のITシステムの開発は、ふつう「要件定義」段階と、「実装」段階とで、契約フェーズを分けて、進められる。これは、たとえば製造業やエンジニアリング産業における、「基本設計」と「製造・構築」に相当すると思えばいい。当然ながら、要件定義(=基本設計)段階は、全体に占める割合は小さい。そして実装(=製造・構築)段階は、はるかに金額が大きくなる。まあ、一桁くらい違っても不思議ではない。

ちなみに、現在の業務系システム開発の多くは、まるきりゼロからプログラムコードを書く、いわゆる「スクラッチ開発」をするケースは多くない。しばしばパッケージ・ソフト、ないし開発フレームワークがあって、それをベースにFit & Gap分析などをしながら、要件定義を進め、コンフィギュレーションやアドオンで実装をする、というスタイルだ。

「要件定義書」が出来上がり、それを核とした提案依頼書(RFP=Request for Proposal)がワンセット揃ったら、複数のSIerに競争見積を出す、というのが今の主流のスタイルだ。

要件定義段階は、いわゆる「準委任契約」で進められる(これは製造・エンジニアリング産業における「実費償還契約 Reimbursable contract」とほぼ同じだが、日本のIT業界はなぜか、準委任という民法用語を好んで使う)。だから受注側に赤字リスクは小さいが、金額も小さいので、旨味が少ない。

ビジネス的に売上が大きくなり、かつ、うまくやれば利益も大きくなるのは、実装段階の一括請負契約である。だからSI業界では、要件定義はある意味、「海老で鯛を釣る」ためのエビであって、本当の狙いは、実装というタイを釣り上げることにある。

SI業界は「人月商売」、と揶揄されることもある。人月(man-month)とは、作業量の単位だ。これに単価をかければ、すなわち売上額になる。だから、なるべく受託側としては要件定義段階で、開発に要する規模=人月を大きくした上で、実装の仕事を一括請負型プロジェクトで受託し、そこで売上と利益を確保したい、という思考習慣が強い。

もちろん発注側としては、それではたまらないので、同じスコープ(役務範囲≒作業量)ならば、なるべく単価の安いところに発注しようと考える。だから複数のSIerに引合いを出し、価格競争に持ち込もうとする。そして受託側は、単価を下げるために、たとえばオフショア開発などの比率を上げて価格競争力確保にいそしむ、ということに相成る。

以上のプロセスの、どこに「知恵を価値に変える」部分があるだろうか。要件定義段階で良い基本設計をして、少ない労力で開発できたり、運用保守のコストが低減できたりしたとして、それはどこで誰が評価してくれるのだろうか?

図を見てほしい。これは経産省の『ものづくり白書』2020年版の、第1部第1章3節に掲げられた図だ(ちなみに、今年の「ものづくり白書」は例年以上に、面白い)。
設計の知恵を、リアルな価値に変えるために 〜 問題の所在_e0058447_19171340.png

これは製造業におけるものづくりのプロセスを例に取っているため、横軸は「企画→製品設計→工程設計→製造」となっている。読者諸賢は、SIその他、ご自分のよく知っている分野に置き換えてみてほしい。

ともあれ、仕事のプロセスの進展とともに、設計の自由度は減っていき、逆に出来上がるアウトプットの品質・コストはどんどんと確定度が上がっていく。そして、設計段階で品質・コストの8割が決まる。設計の終わりをどこに置くのか、8割という数字が妥当かどうかは議論の余地があろうが、この傾向自体に反論する技術者は少ないだろう。

だから、製品のコストと品質の殆どを決める設計段階で、知恵を出すことが重要なのだ。そして、そこで出した知恵こそが、利益や、リカレントな受注という、ビジネス上のリアルな価値に直結してほしい。それが、エンジニアの共通の願いである。

ここまで、SI業界を俎上に上げて、人月ボリューム志向のビジネス慣習が、いかに設計の価値を阻害し、最終的には優秀な人材の離反を招いているか、論じてきた。SI業界の読者の中には、不快に思った方もいるだろう。じゃあ、お前のいるエンジ業界はどうなんだ。あるいは、製造業や、他の業界はどうなんだ、と。

実は、その問題構造は通底している、というのがわたしの認識である。プラント・エンジニアリング業界のプロジェクトのあり方は、意外なほど、SI業界のあり方に似ている。だから、わたし達も実は、よく似た悩みを抱えている。

そして製造業、とくに日本が得意とする部品・素材業界も、やはり設計の知恵をリアルなビジネス価値に結びつける点で、悪戦苦闘しているように思える。部品・素材業界は、多くは受注ビジネスだ。顧客である自動車会社や電機会社の要望する特性・品質の材料部品を、個別の要求に応じて設計し、毎月の注文に応じて生産している。つまり、同じようにB2Bビジネスをしている訳だ。

そして、製品の企画・設計段階から、ユーザ企業に呼ばれて、いろいろ要望を出され、対応するために知恵を絞って、部品材料を設計提案する。もちろん試作もする。でもって、めでたく採用かと思った段階で、購買部門が出てきて、他社との価格競争に巻き込まれるのだ。設計の知恵は、ようするに価格競争というレース場への、入場券でしかない。こういう事例を、ときおり耳にする。

このような状態が、あちらの業界でもこちらの業界でも生じているのだとしたら、誰が喜んでエンジニアなどという職種になりたがるだろうか? 知恵を出しても、会社の利益にもならず、当然、自分の評価にもつながらない。

経済団体やら識者らが、ときおり、日本の技術力の低下について、嘆くことがある。まあ、世のおじさん達の頭の中では、未だに日本は「技術一流、政治三流」みたいな信仰が残っているらしいが、技術の現場で走り回っている若手中堅の実感とは、相当に開きがあるだろう。今、日本のIT技術が、世界で超一流と思っているITエンジニアって、どれだけいるだろうか?

本来、経済団体などは、そういう業界構造やビジネス慣習を改革するためのイニシアチブを取るべき立場にあるはずだ。だが、どうやら、日本の技術をめぐる、根本問題の所在に気づいていないらしい。

では、問題の在り処を理解したとして、具体的には、どうすべきか。

システム開発の外注をやめて、全部内製化し、それもアジャイル開発でMVP(Minimal viable product)を短期間にローンチし、UI/UXを磨いてユーザをひきつけ、新しいビジネスを切り開けばいい、というのが、現在出回っている回答の一つだ。いわゆるデジタル・トランスフォーメーション(DX)戦略である。

なるほど、確かに、設計や実装におけるアイデアを、すぐにビジネス価値につなげられる方法である。ただし、このやり方、万能ではない。まず、すべての業務システムがアジャイル開発に向いている訳ではない。また、とくに、B2B業界でのカスタマーとの関係のあり方を考えると(←まさにこの点が、上述した問題の根本原因なのだ)、カッコいいUXだけでビジネスを引きつけられる訳でもない。

では、どうしたら良いのか。他に何か、良い知恵はないのか。長くなってきたので、わたしの業界における一つの取組み、『競争的基本設計』(Competitive FEED)について紹介した上で、この問題の出口について考えてみることにしよう。

(この項続く)


<関連エントリ>


by Tomoichi_Sato | 2020-08-22 20:18 | ビジネス | Comments(0)

『佐藤、お前は傲慢だ』 〜 あるいは、経験から学ぶことの困難ついて

「佐藤。お前は傲慢だ。」

−−随分昔、上司のSさんに言われた。言われたが、自分がなぜそんな事を言われるのか、よく分からなかった。

たしかその時、わたしは顧客の要求事項について、Sさんに説明していた。客先は、こことここを、こうしてほしい、と言ってきています。でもそれって、元の設計の方針とは少し、ずれてきています。客先の意図と背景を推測すると、実はこれこれこういう要望事項が、隠れているんじゃないでしょうか。だとしたら、顧客の真のニーズに合わせた開発をするべきでしょう。

「顧客が『欲しい』と口で言うことを、ただ実現するよりも、顧客が自分でも気づかない真のニーズを満足させることが、設計者の使命だと思います。」

という意味のことを言ったら、Sさんに

「佐藤。お前は傲慢だ。」

と叱られたのだ。上司に言われたので引き下がったが、内心わたしは納得していなかった。顧客が欲しがる解決手段(How)としての「ウォンツ」ではなく、顧客が何故それを必要とするのか(Why)を示す「ニーズ」にフォーカスすべきだ、と、今でも思っている。

しかし、その時、Sさんがわたしに諭した「お前は傲慢だ」という指摘は、それでも正しかったのだ。ただ、それが分かるまでには20年以上の時間が必要だった・・


この文章を書いている今日は、8月15日、いわゆるお盆の日だ。終戦記念日でもあり、西洋キリスト教社会では、聖母被昇天の祝日(≒聖母マリアの命日)でもある。先祖を追悼し、昔のことを想う日だ。なので、ここにいささか恥ずかしい、自分の反省の記録を書いておく。

2週間前の日曜日である8月2日、本来わたしは演奏会のステージに立って、合唱を歌っているはずだった。曲目はJ・S・バッハ『マタイ受難曲』。指揮は佐々木正利(声楽家・岩手大学教授)、演奏は「佐々木バッハセミナー合奏団および合奏団」。だが、周知の通り、現下の状況では、とても合唱演奏会を開ける状況にない。わたし達は涙をのんで、演奏会の中止・延期を決めた。

この合唱団の母体となったのは、毎年夏に、池袋・目白にある「自由学園明日館」で4日間に開催される、「佐々木バッハセミナー in 明日館」 というセミナーの参加者だ。このセミナーは後援団体のない自主セミナーで、中心となるTさん・Kさん・Tさんらが、佐々木先生をお迎えし、2002年から毎年手作りで開催してきた。曲目は、佐々木先生のご専門であるバッハの声楽曲がほとんど。わたしも一応、運営スタッフの末席にいるが、大したことはしていない。
『佐藤、お前は傲慢だ』 〜 あるいは、経験から学ぶことの困難ついて_e0058447_15043391.jpg
自由学園明日館(本館)

このサイトの読者諸賢は、合唱、ことにバロック時代の合唱曲など、興味のない方がほとんどだろう。だからくだくだしい説明は省略するが、多作家だったバッハの作品の中でも、「マタイ受難曲」は最高峰とされている。長大で(演奏すると全部で3時間半くらいかかる)、編成も大きく(二重合唱でオーケストラも二手に分かれる)、名曲のほまれも高いが、演奏技術面でも難曲かつ大編成なので、簡単には演奏できない(費用が相当にかかるからだ)。

だが、バッハの音楽を好む人にとっては、「一生に一度はチャレンジしてみたい」大曲でもある。それは「バッハセミナー in 明日館」の面々も同じだ。とはいえ、わずか3日半のセミナーで、全部を仕上げるのは不可能だ。そこで、段階的なアプローチをとった。まず2017年夏は、マタイの第1部。翌2018年夏に、第2部を、それぞれセミナーで勉強する。その上で、2019年から希望者を募り合唱団組織を作って、月2回の練習を続け、2020年夏に、全曲演奏会を行う、というプロジェクトである。

ところでその第一歩、2017年の夏のセミナーで、わたしはとんでもない経験をした。ゲネプロの舞台の上で、自分のソロの箇所で、立ち往生したのだ。

ゲネプロというのは本番直前の総練習をさす。セミナー最終日の、事実上の仕上げ段階だ。それなのに、自分が歌うべき箇所を、わたしは歌えなかった。それも、長い曲ではない。全部でわずか、7小節である。でも、歌えなかったのだ。緊張であがって歌えなかった、のではない(そんな可愛らしい年齢ではないよね)。拍の長さを、数え間違えたのだ。

わたしは合唱が趣味だが、別に歌がうまいわけでもないし、声量があるわけでもない。この明日館の夏のセミナーで、ソリストとして舞台に立つのは、たぶん7年ぶり、2度めだったと思う。ちなみにセミナーでは、器楽演奏家はプロの方をお願いするが、歌のソリストは毎回、参加者の中から希望を募り、オーディションで決めることになっていた。希望者が多い場合は、1曲を分割し、リレーして歌い継ぐ。ただ参加者は上手な歌い手が多く、それでも競争は厳しい。わたしはあえて、ソロは希望してこなかった。

でも3年前、セミナーの始まる初日に、家を出る前、連れ合いに「今年はテナーのオーディションを受けようと思う」と告げた。第1部には20番という、比較的短いテナーソロ(合唱のオブリガードつき)があり、そこなら歌えそうに思ったのだ。すると連れ合いは、「度胸だけじゃなく、ちゃんと猛練習しなきゃ恥ずかしいわよ。このごろ、仕事は度胸だけで乗り切っているでしょ」と言い返してきた。図星なところがあってドキリとした。

2017年度のセミナー参加者は、過去最高の103人。自由学園明日館の講堂は、F・L・ライトの流れをくむ名建築で文化財だが、このときばかりは狭く見えた。これじゃソリストへの競争は厳しいな。だが不思議なことに、20番のソロの希望者はわたしを含む2名のみで、佐々木先生は「時間がもったいないから」オーディションは省いて、当選ということになってしまった。

セミナー3日目に、器楽とソリストの合わせ練習が始まる。わたしが分担する箇所は7小節。歌詞なんかワンセンテンスで、「わがイエスのそばで、わたしは目覚めています」だけだ。だが、なぜか、わたしは間違えてしまい、恥ずかしい思いをした。第25小節目(楽譜の印のある箇所)で、シの♭(ドイツ音名でB)を、八分音符で6個半分の長さ、伸ばさなくてはいけない。それを、短く切り上げてしまったのだ。
『佐藤、お前は傲慢だ』 〜 あるいは、経験から学ぶことの困難ついて_e0058447_15102412.jpg
その日の午後には、器楽演奏者が全員揃い、舞台配置で再度練習があった。伴奏してくれるのは、チェロ・田崎瑞博氏、オルガン・能登伊都子氏、といった当代一流の演奏家たちである。それなのに、また切れ目を間違えてしまい、2回やり直してもダメ、3度目の正直で、ようやくなんとか通った。家に帰ってピアノで曲をさらい直した。気づきはもちろんあったが、音型自体は単純なのだ。なのに、なぜ間違えるのか?

そして最終日。午前10時からのゲネプロでも、自分のソロの部分を見事に間違えてしまった。今度は逆に、1拍遅れた(伸ばしすぎた)のだ。その後のダメ出しで、お願いしてもう一度やらせていただき、ようやく成功。しかし単なるまぐれで、薄氷だったことは、自分でわかっていた。

本番前のお昼休みの時間に、講堂の裏でもう一度、一人で練習をしなおした。昨日のリハの録音を聞きかえしているうちに、自分のどこが間違えていたのか、ようやく少しずつ分かってきた。練習の時、肝心の25小節に入ると、なぜか器楽が妙に遅くなったように、いつも感じていた。だが、もちろんプロがそんな事をするわけがない。実はその前の23〜24小節の、メリスマ(早い動きの箇所)で、焦ってしまい、自然に自分の側のテンポが早くなっていたのだ。だから音を伸ばす25小節目に入ると、オケが遅くなったように感じたのだった。

ようやく原因がわかった。だとしたら23〜24小節を、ちゃんと正しいテンポで歌えるようにするしかない。昼休みの残りの時間、たぶん20回以上、その箇所を録音とともに繰り返して歌った。

本番の修了演奏会では、幸いなことにソロの部分も、指揮する佐々木先生の顔だけを見ながらテンポをおっていたおかげで、ちゃんと歌い通すことができた。本当にラッキーだった。天の助けだと思った。

あの日の修了演奏会の後の打ち上げパーティのことは、はっきり覚えている。明るい盛夏の午後だった。明日館本館の、ライト自身が設計した食堂に皆が集まって、おいしい食事と飲み物を取りながら、互いに感想を述べるのだ。そして何人もの人に、「ちゃんと歌えて良かったですね」「アルトは皆、数を数えて応援していましたよ」などと声をかけられ、ありがたく感じるとともに、顔から火が出そうな気がしたのだった。

さて、興奮がぬけた翌朝、もう一度、冷静に考え直してみた。Q1:なぜ、わたしはあの簡単な箇所で伸ばし間違えたのか?

答えは、A1:その直前の小節で歌い急ぎすぎたからだ。

ではなぜ、Q2:前の小節で歌い急いだのか? 答えは、A2: 指揮のテンポや器楽の音に注意が向かなかったからだ。

では、Q3: なぜ、指揮や器楽に注意が向かなかったのか? そんなの、音楽演奏の基本じゃないか、とわたしの中の声がいう。もちろん、そうなのだ。でも、A3: あそこは細かい動きの続くメリスマの箇所だった。

なるほど。だが、Q4: なぜ、メリスマで急いだのか。そのメリスマの箇所はそんなに難しかったのか? −−そう言われると、やや答えに窮するのだ。だって、バッハはメリスマの作曲家と言っても過言ではない。彼のカンタータや受難曲は、長大で困難なメリスマが山のように詰まっている。その中で、この20番など、平均的なものでしかない。

だとしたら、答えははっきりしている。A4: 練習が足りないからだ。

普通なら、ここで自問自答は終わる。だがわたしは、もう一歩だけ先の扉を押した。

Q5: だったら、なぜ練習が足りないのに、お前はソロのオーディションにエントリーしたのか?

A5: 自分が傲慢だからだ。

ここで初めて、わたしは本当の答えを得たように思った。あの歌がちゃんと歌えなかった根本原因は、自分が傲慢だったからなのだ。

曲のオーディションに受かるかどうかなど、結果に過ぎない。大事なのは、自分が納得できるまで練習したかどうかなのだ。それをせずに、ノリで受けるだけだとしたら、それは、誠実に準備してきた他の人達を侮辱することになる。わたしがしたのは、そういうことだった。「佐藤。お前は傲慢だ。」という元上司のSさんの声が、そのとき耳に蘇った。

わたしはその月、すぐに尊敬する声楽家の門を叩いて弟子入りし、歌の勉強を一からやり直すことに決めた。今までも、発声指導の先生についたことはあった。だが長い間、合唱が趣味だと言いながら、ちゃんと歌を習ったことがなかった。それがそもそも、怠惰なのだ。

翌2018年夏のバッハセミナーで、わたしは再び、「マタイ受難曲」第2部の34番、短いテナーのソロに応募した。わずか10小節のレチタティーヴォだ。2人で分け合うことになり、わたしの割当は前半6小節だった。本番当日は風邪気味で、十分な出来ではなかったが、少なくとも今度は間違えずにちゃんと歌えた。その1ヶ月半くらい前から、家でずっと繰り返し練習してきたからだ。家族は(またその曲か、いい加減にしてほしい)という顔をしていたが、我慢してもらった。

それに、歌の先生についたことで、少しは進歩もあったようだ。自分では何が変わったのかよく分からないのだが、佐々木先生からは練習時に、「知一さん、例年に比べて声が出るようになったな。」といわれた。それが一年前のつぐないに思えた。

これでわたしの、短い思い出語りは終わりだ。まことに無様な失態から、ようやくひとつの学びを得たということだ。

それにしても、「お前は傲慢だ」と上司に言われてから、20年近くたって、やっとその意味が分かるとは。これは、「学び」の深さと、難しさを示している。わたしのような自惚れの強い人間が、何かを学ぶには、痛い思いをしなければ、きっかけを得られないらしい。

おまけに、学ぶためには、乗り越えなければならない障害、ないし敵がある。

学びの第一の敵は、傲慢なのだ。傲慢だったら、何も学ぶ必要はないと、うぬぼれる。それでも、たまたま運が良ければ、あまりひどい失態を経験せずにすむ。あるいは、自分の失敗を見ないふりして、生き続けることも、できるだろう。

ただ、それでは、周りが迷惑だ。わたし達の社会は、互いに支え合いながら、できあがっている。どこかに傲慢な人間や組織があると、その負荷を周囲が担っていくことになる。傲慢な人間たちは学ばないから、同じような失敗を何度でも繰り返す。繰り返しつつ、糊塗していく。そのツケは、結局、社会の周囲に回されていく。

わたし達の社会は、わたし達の父祖が苦労して築いてきたものだ。傲慢さは、それを蝕む。もし、わたし達が先人たちの魂に何か感謝を示したいのなら、まず、謙虚になって、「わたし達は経験から学びます」と誓うべき事であるはずなのだ。


<関連エントリ>


by Tomoichi_Sato | 2020-08-15 15:18 | 考えるヒント | Comments(0)

欠品を起こさないための在庫手配入門(3)――安全在庫を確保する


前回は、営業所の在庫手配において、「物理的にはそこに存在しているが、近い将来出荷用に予約されている」状態の在庫品、すなわち『引当て』の考え方を説明した。手元にある総在庫量の内、自由になるのは、したがって、まだ引当されていない分である(もちろん不良品はないという前提)。これを未引当在庫量、ないし有効在庫量という。

 [有効在庫量] = [総在庫量] − [引当済み在庫量]

工場の部品在庫などでも、すでに製造オーダーが切られていて、使用予定が決まっている分は、「引当されて」いる状態にある(たとえ仮にまだ、資材倉庫の棚にあっても、近い内にピッキングされて製造現場に払い出される)。だから、MRP(Material Requirement Planning)の資材所要量計算では、各品目について

 [総所要量] − [有効在庫量] = [正味所要量]

という計算をする決まりになっている。この正味所要量から、さらに子部品の総所要量へと、部品表(BOM: Bill of Material)にしたがって展開していく計算を、MRPの部品展開という。

さて、営業所にいるあなたの場合は、できあがった製品在庫だけを相手にしているため、部品展開だの製造オーダーだのといった話は、関係がない。純粋に、現時点での有効在庫量を元に、先々顧客から入るであろう注文の数量(需要量)と、本社から補充供給される予定の数量(供給量)から、在庫量の推移を考えればいい。

あなたは、担当する製品Xについて、現在庫量が24日分、そして来月初に18日分の供給予定があることを知っている(なお、1ヶ月は平均20営業日とする)。だが、現在庫量のうち、11日分はすでに引当されていて、有効在庫量は実質13日分だ。

引当済みの分は、一週間後、すなわち5営業日後に出荷される予定になっている。ということは、今月の需要を1ヶ月分=20日分とすると、そのうち11日分はもう引当済みだから、残る20-11=9日分の需要を、賄えれば良い。手元には13日分の有効在庫があるから、なんとか今月は乗り切れそうだ。今月末の在庫は13-9=4日分まで減少しているだろう。だが、来月の月初には、先月手配した18日分の追加供給があるから、月初在庫量は4+18=22日分ということになる。来月末まで、なんとかもちそうだ。

ただしこのままでは、来月末の在庫は22-20=2日分しか残らない。再来月の早々には、欠品が起きる可能性がある。だから本社に今日、生産依頼をかける必要があると、あなたは判断した。納期は2ヶ月なので、今日頼めば再来月の頭には届く。そこで、製品Xの需要は比較的安定しているという先輩の経験知にしたがい、発注から納入までのリードタイム日数分、すなわち40日分(数量でいうと200個)を、本社に依頼しようとした。

ところが先輩はあなたに、「それだけじゃ、足りないんだ」という。

――なぜですか。200個あれば、次の補充までの2ヶ月間の需要には間に合う計算です。

「計算上は、な。だが世の中、計算通り行くとは限らないんだ。月の需要量が100個と言っても、それは平均だろ。もっと売れる月もある。あまり売れない月もある。たくさん売れたらどうする。たちまち欠品するじゃないか。たくさん売れたら自分が困るような営業所じゃ、ビジネスにならない。」

――てことは、もっと多めの生産依頼をかけろ、ってことですか?

「とりあえずは、な。2ヶ月分ってのは、いわば最低必要な基準の数量だ。それじゃ欠品が起きる可能性があるから、それにゲタを履かせるべきだ。安全在庫ってやつだな。」

――分かりました。それじゃ、いくつ上乗せすればいいですか?

「いちいち聞かずに、自分で調べて考えてみろよ。」

先輩はそう言い残すと、客先まわりに出かけてしまった。あなたは例の、累積需給曲線を描いて考えてみる。需要を表す線は、毎日平均的に売れていく場合、右上がりの 45度の直線になる。横軸も縦軸も、おなじ日数単位だからだ。どの品種をとっても、この図の描き方に従えば、右45度の線になる。それが、この図の利点だ。

欠品を起こさないための在庫手配入門(3)――安全在庫を確保する_e0058447_20481848.jpg
だが、先輩の言うことも分かる。たしかに、多く売れる月もあれば、あまり売れない月もある。売れ行きの良いときは、線の傾きはきつくなるし、逆に、売れ行きが芳しくないときは、傾きは緩やかになるのだ。傾きが急になると、供給線とぶつかってしまう。需要線が供給線を上回るときは、欠品の発生を表す訳だ。欠品を起こさないためには、本社に手配する生産依頼の数量を増やして、供給線を需要線からもっと離す必要がある。

では、どれくらい離せば良いのか? 自分一人では、見当もつかない。仕方なく、あなたは過去1年間の製品Xの出荷量を調べてみることにした。といっても、販売管理システムには、個別の受注オーダーと出荷実績しか残っていない。しかたなく、全部をリストアップして印刷し、手元のExcelに転記して、月ごとに集計してみた。結構めんどくさい仕事だったが、次のような数字を得た。

月  出荷量
  1  89
  2  41
  3 147
  4 122
  5 101
  6 123
  7  70
  8  83
  9 126
 10 114
 11  82
 12 102

ウーン。この先どうすれば良いのかなあ。ともあれ、数字を眺めてみると、たしかにずいぶんバラツキがあることは分かった。安定した需要だ、なんて先輩はいっていたが、一番多い月は、147個も売れている。平均のほぼ5割増しだ。逆に少ない月もある。一番売れなかった月は、41個で、平均値からは6割減だ。ちなみにExcelで平均値を見ると、ちょうど100個になった。まるで作った問題みたいだ(笑)。

だとすると、最大値の147個から見て、ざっくり50個ほど、余裕を見て「安全在庫」をもっておけば良さそうに思える。でも、これって、過去1年分の数字を見ただけの結果だ。それで十分と言えるのか? あなたはだんだん意地になって、先輩の鼻を明かしてやりたいような気持ちになっている。ただ、じゃあ過去3年分を調べるかというと、あんな面倒くさい作業はもう嫌だ。何か、もっとうまい方法はないのだろうか?

あなたは、ネットで検索してみた。すると、安全在庫の計算式というのを見つけることができた。なんとかコンサルタントの日誌から、というようなタイトルのサイトだったが、そこには、発注点管理の場合の適正在庫量は、次の計算式で求める、と図が示されてあった。

 適正在庫の発注点 = 基準在庫量 + 安全在庫量
 
 基準在庫量=手配から入手までのリードタイム期間分(L)
 安全在庫量(安定需要の場合)=
  サービス率:95%    1.65 × 需要量の標準偏差 × √L
  サービス率:99%    2.33 × 需要量の標準偏差 × √L
欠品を起こさないための在庫手配入門(3)――安全在庫を確保する_e0058447_20532252.jpg

手配から入手までのリードタイム期間分(L)、ってのは、2ヶ月分だな。それが基準在庫量になる、と。あなたが考えていた事はそこまでは正しかった訳だ。ただ、安全在庫量のところにある「サービス率」って何だっけ? 以前、先輩が何やら口にしていた気もするが、これも調べてみると、「サービス率とは、顧客の要求に応じて製品を出荷できる割合。欠品率の逆。」と書いてある。

すると、サービス率が95%というのは、欠品する確率が5%ということなのだな。サービス率99%は、欠品率1%だ。どっちが良いのだろう?

2ヶ月分ずつを発注するんだから、まあ平均すると2ヶ月に一度、発注手配をかけるわけだ。すると、サービス率95%なら、20回に1回、欠品が起きる。つまり40ヶ月=3年と4ヶ月に1回ずつ、という訳だ。これがサービス率99%だと、100回に1回、つまり200ヶ月に1回だ。それって18年弱だ・・そんなに先まで、この営業所にいないよな。そもそも、製品Xだって、そんな先まで売れてるかどうかあやしい。じゃあ、95%でいいや。これでも3年は持つわけだから、立派なもんだ。

あとは、需要量の『標準偏差』かあ。聞いたとこはあるけど、どうやって求めるんだっけ。・・えーと、なになに、「標準偏差は、ExcelのSTDEVA関数で求めれば良い」か。親切なサイトだなあ。

言われたとおり、Excelで過去1年分のデータを選択して標準偏差を計算してみると、28.9個という数字になった。それに、1.65をかけて、さらにリードタイム期間の2の平方根をかける、と。2の平方根は、SQRT(2)だな。結果は、67.5個となった。まあ端数は繰り上げて、68個が、適正な安全在庫量ということだ。需要量の平均は1営業日に5個だから、3週間分よりちょっと少ない程度の量だな。

あなたは外回りから戻った先輩に、今月は268個の生産依頼を本社にかけます、また今後(再来月以降)は、在庫量が268個を切ったら、200個ずつ手配をかけることにします、と伝えた。先輩は「わかった」とだけ答え、特にそれ以上、何も言わなかった。サービス率や標準偏差について、聞かれたら説明しようと思っていたので、あなたはちょっと拍子抜けだった。だが、ともあれ宿題は一つ果たしたのだ。

ただ、こういう作業を担当する全部の品種についてやらされたら、たまらないな、とも思った。こういうのは、販売管理システムか何かの中で、自動的に計算してほしい。コンピュータなんだから、さ。この式は、どんな品種にも、当てはまるんじゃないか。それが安定した需要である限り(そして安定需要かどうかだって、コンピュータで計算できるはずなのだ)・・


以上が、欠品を起こさないための在庫手配の顛末である。なお、もう少しだけ注記を付けておく。

(1) サービス率について:

需要量には上限がないので、あたりまえだが、サービス率=100%ということは、理論上ありえない。だから、99% とか95%とか、実用的な目標値を設定することになる

(2) 安全係数と需要変動のパターンについて:

上の式に出てくる1.65とか2.33という数字は、『安全係数』と呼ばれる。これは統計学的に言うと、正規分布において、標準偏差のn倍の領域内の面積比率に対応している。だが、世の中の需要パターンが、正規分布に従うとは限らない。だから本当は、まず過去の出荷量の変動パターンをきちんと分析して、正規分布に近い場合にのみ、使うべき係数である。

たとえば、もっと間欠的な需要(つまり、数ヶ月おきにポツリポツリと出ていくような製品)の場合、上の式の安全係数を当てはめると、在庫が大きくなりすぎる傾向がある。その場合は、別の計算式(ここでは省くが)を使ったほうがいい。

(3) 計画手配時の安全在庫について:

上に説明したのは、「不定期・定量発注」で、発注点方式の在庫手配を行う場合の計算方法である。毎月、定期的に行う「定期・不定量発注」方式の場合は、先の期間の需給量を予測して、計画手配を行うことになる。この場合にも安全在庫の考慮は必要だが、上の式を機械的に適用してはいけない(安全在庫がかなり多くなってしまうはずだ)。計画手配を行う品目は、売れ筋商品の場合が普通だし、季節性を伴うケースもあるだろうから、より深刻な在庫過剰を招く。

同様に、MRPなどの計画生産を行っている工場での部品資材在庫にも、適用すべきではない。この問題については、機会があれば、また別に解説することにしよう。

ともあれ、心に留めておいていただきたいのは、上に述べたような考え方は(在庫理論としては初歩に属するが)、どんな業種のどんな品目にも当てはまる汎用的な式だ、という事である。このような方法論を、『マネジメント・テクノロジー』とわたしは呼んでいる。

マネジメント・テクノロジーの領域は、どんな業界の、どんな会社でも共通に当てはまる。いわば協調領域の知識である。あなたの会社が知らなければ、あなたの会社は見えない損をしている。しかし、ライバルも知らないだろう、と思ってはいけない。少なくとも、海外の有力なライバル企業は、よく知って活用していると想像したほうが良い。日本にはまだ、マネジメント・テクノロジーを教える大学は少ない。だが、欧米では確立した分野だし、中国やアジアの優秀な人材は、そうした国々に留学し、現代的な手法を学んで帰ってきているのだ。

我々だって、気合と根性の「竹槍時代」を卒業し、もう少しモダンの時代に飛び込むべきときが来ているはずである。


<関連エントリ>
 (2020-07-20)
  (2020-07-26)


by Tomoichi_Sato | 2020-08-05 21:12 | サプライチェーン | Comments(0)