人気ブログランキング | 話題のタグを見る

工場はコストセンターか? そしてIT部門はコストセンターか?

先週の9月1日(木)に開催したオンライン・シンポジウム『工場スマート化のための製造実行システム”MES” ― 広がる導入と実例に学ぶ活用方法』には、おかげさまで大勢の方にご参加いただけた。まずは深くお礼を申し上げたい。昨年10月に続き、MESをテーマとする2回目のシンポジウムで、ほぼ一日という長丁場だったにもかかわらず、たくさんの来聴者があったことは、この主題に対する関心の高さを示すと思われる。

わたしは(財)エンジニアリング協会「次世代スマート工場のエンジニアリング研究会」の幹事という立場で、今年の企画に関わった。昨年はどちらかというと、MESベンダーさんによる最新の製品情報提供が中心だった。そこで今年はよりユーザ側に立ち、具体的な先進事例を中心に、活用のベストプラクティスを紹介したいと考え、プログラムを組んだつもりだ。

幸い、どの講演も非常に中身の濃いもので、ねらいはある程度達したと思う。でも、反省点もあった。全体に時間が短かったのである。本当は各講演に、もっとお話しいただきたいポイントがあったと思うのだが、十分伝わりきれなかったように感じる。

そこで、当日もアナウンスしたが、今回の参加者を対象に、オンライン形式の「MESに関するQ&Aセッション」を別途、企画しようと思っている。参加者の方々にはアンケートにご協力をいただき、その返礼という形で今回の講演資料をお送りしている(9/06より順次送付予定)。その資料を読み込んでいただいた上で、ディスカッションする機会を作りたい。

ちなみに当日はわたし自身も、経産省製造産業局の松高課長補佐のご講演に続いて、基調講演をさせていただいた。だが、時間の関係でスキップせざるをえなかった箇所があった。そこで、本サイトで補足しておこうと思う。それは下記のスライド「MES/MOMの提供価値」の、第1行目に書いている箇所だ。すなわち、

工場はコストセンター。品質と納期を守って、コストダウンを果たせ」

が日本の普通の経営感覚だろう、という点だ。だが、まさにこの意識が、今の製造業の問題を、ひどく難しくしているのである。
工場はコストセンターか? そしてIT部門はコストセンターか?_e0058447_11310872.png

  • 日本の工場は投資不足である

これは月刊誌「工場管理」で連載開始した記事「ゼロから始める新工場づくり」にも書いたことなのだが(記事はこちらからダウンロードできる)、とにかく日本の工場は投資不足である。

どこの工場に行っても、20年前、30年前の古い設備を、保守しながら使っている。その努力には頭が下がるが、現代では欧米どころか中国・東南アジアの工場でさえ、もっと最新鋭の機械を入れ、空調だってちゃんと入った建物の中で使っている。ましてIT面の投資不足については、言うに及ばず、である。

 投資不足
  → 老朽化・生産性低下
   → コスト競争力不足
    → 利益が得られない
     → ますます投資不足 →・・

という悪循環がそこでは起きている。そしてこのサイクルの根源にあるのは、「工場はコストセンター、コストだけで管理するべし」という経営の通念にある、と言いたかったのだ。


  • コストセンターという概念

「コストセンター」とは、元来は会計用語であり、かつ、中立な(価値判断を含まない)概念のはずであった。収入がなく、費用だけが集計される部門単位を、英語でCost centerと呼ぶ。「原価中心点」と訳されているが、皆カタカナでコストセンターとよんでいる。

コストセンターの対義語は、「レベニューセンター」で、収入のみが集計される部門だ。だが、こちらの用語は殆どの人が知らない。なぜなら多くの人は、コストセンターの反対は『プロフィットセンター』だと信じこんでいるからだ。

プロフィットセンターという概念は、じつはP・ドラッカー(日本では神格化されている経営学者)が提案した。プロフィットセンターは、収入も費用も集計される部門単位と、理解されている。まあ収入のみで費用が一切発生しない部門など現実世界では存在しないので、世の中の部門はプロフィットセンターかコストセンターのどちらか、ということになる。

ところが、この概念はドラッカーの意思を離れて、一人歩きをし始める。中立だったはずの会計概念が、経営論の世界では、いつのまにか、

プロフィットセンターはコストセンターよりも偉い

という話に変化していく。会社の中では、収益を生まぬコストセンターのマネジメント(部門長)は、発言力が弱い。結果として、コストセンターの所属では出世できない、などの傾向が生じてきた。


  • 「コストセンター=重荷論」の登場

こうした経営論の文脈では、コストセンターの評価尺度は、コストである。コストセンターとは、コストに管理責任を持つ部門である。コストだけが財務KPIとして集計されるのだから、コストが安ければ安いほど、ほめられる。

そして、コストセンターは価値を生み出さない、と考えられるようになった。あるいは「付加価値」を生み出さない、という言い方をされることもある(日本では価値と付加価値をちゃんと区別する人は、残念ながら少ない)。なので、コストセンターのプロフィットセンター化を、などと提言するコンサルタント諸子も、あちこちにいる。

いずれにせよ、企業にとって、価値を生み出さぬコストセンターは重荷である。だから軽ければ軽いほどよい。できれば切り離したい、という理屈が生まれる。これを「コストセンター=重荷論」とよぼう。

切り離すと行っても、日本では従業員の首を簡単に切れないから、まずは子会社化する。それによって給与水準を下げる。また、子会社から提供される物品・サービスには、何らかの価格(移転価格)をつけるが、それは原価+アルファ程度にとどめる(原価の数字は親会社にも見えている)。そのアルファが子会社の利益分になる訳だが、何せコストダウンが使命の会社なのだから、これは可能な限り薄くする。

このために、子会社は十分な内部留保を持てず、自分だけの判断では投資ができなくなる。現場の事情もろくに知らない親会社が、財務諸表のP/Lの数字だけをみて、投資判断することになる。これが、製造子会社となった多くの日本の工場で、起きていることなのだ。


  • 「コストセンター=重荷論」の犠牲者たち

こうしたコストセンター=重荷論は、日本の高度経済成長期には見られなかった。この議論がはびこるのは、長い不況に突入する90年代以降である。ついでにうとERP(とくにSAP)が、この「コストセンター=重荷論」を強めたという風に、筆者は見ている。だがこの話をし始めると長くなるので、別の機会に触れよう。

ともあれ、「お前たちはコストセンター」と名指しされ、重荷論のくびきを負わされた代表的部門が、以下の4つであった:
・生産部門(=工場)
・IT部門
・研究部門(R&D)
・物流部門

工場の投資不足のサイクルについてはすでに述べたので、例として、2番目のIT部門に対し、この重荷論がいかに作用したかを見てみよう。いいかえると、日本企業のIT投資不足はいかに生じたのか、いや、もっというと、なぜ日本のIT業界がダメになってきたのか、の経緯である。

昔はどこの企業内にも情報システム部門があり、かつ、それなりに内製化もしていた。開発も運用も自社でやっていたのだ。ところが、90年代頃から、「ITはコストセンターだから切り離せ」で、情報子会社化されるようになってきた。

それでも本社内には、情報企画的な仕事は残った。まあ、当然である。業務は変化していくし、その業務変革をすすめるためには、ITツールが必要だからだ。という訳で、いつのまにか本社内に、ITエンジニア風の視点を持つ人間が増えていった。だが増えると目立ってくるので、「いつのまに何で増えたんだ」「こいつらも子会社に移せ」とあいなった。

これを2〜3回繰り返すと、IT企画や要件定義の仕事など、こわくて誰も近づかなくなる。業務プロセスを情報とデータの観点から切り取って、改革を考える人間は、ユーザ企業からいなくなった。

情報子会社の方は、どうなったか。なにせ「コストセンター」だから、人件費切り下げが、会社の管理目標だ。優秀な人間が長く居続けるだろうか? 我こそは、との気概があり、腕に覚えのある人間は、ユーザ系企業から、IT専業に移っていく。

だがIT専業の業界は、大手ITゼネコンが仕切る、多重請負構造だった。一括請負というSIビジネスは、発注者のプロジェクト・マネジメントのレベルが高くなければ、受注側にリスクがしわ寄せされるだけで、決して儲からない。で、その発注側は誰か? 先ほど述べた情報子会社である。ここに高いPMのレベルを期待できるだろうか。

そこに、突然という感じで、欧米発のAIブームが来た。IoT・スマート工場ブームも来た。その後は、DXブームだ。

DXブームに火をつけたのは、欧米の大手ITベンダーと、外資系コンサルティング会社の面々である。カッコいいので、経済メディアも大いにかついだ。メディア産業は元々、ヒットとブームには抵抗できないのだ。

その結果が、今日である。誰もどこにも、新しいデジタル技術を業務の中核に取り込んだグランドデザインが存在しない。グランドデザインが不在だと、何をしたら良いのか分からないので、できそうなところからちょっとだけPoCと称して手をつけてみる。支払い能力の多少ある大企業は、外資系コンサルに「戦略プラン」を外注する。おかげで今やマッ○○ゼーもボス○○もアク○○○○も、バブル状態で人員急増、報告書の品質が心配される状況と相成った。情報化の現場自体は、置いてきぼりである。

本来ならば、社内および情報子会社にしかるべき人材を育て、あるべき業務の姿を作るために粛々とITシステムを構築し回していなければいけないはずなのに、IT投資に回るはずのお金は、高額なコンサルフィーとして消えていく。あるいは彼らのプランに従い、大枚はたいて入れたERPは、「世界標準のベストプラクティス」だそうだが、オペレーションの現実に合わないので、山のようなアドオンを追加して運用している始末である。業務プロセスとITの双方に精通した人間が居なければ、そうなるのも必定であろう。

これが、「コストセンター=重荷論」のもたらした帰結である。いったい、なぜこうなったのか? どこで間違ったのだろうか? この問題に答えるのは簡単ではないが、それでも次回、考察してみよう。

<関連エントリ>
 →「コストセンターとは何か」 (2013-03-11)

# by Tomoichi_Sato | 2022-09-04 11:50 | ビジネス | Comments(1)

「プロジェクト&プログラム・アナリシス研究部会」(9月15日)開催のお知らせ

わたし達は、感情を持つ動物です。当たり前のことを言っているようですが、わたし達は普段、理性的に考え、合理的に判断しているつもりで生きています。ビジネスの中では経済合理性が求められ、プロジェクトは価値を生み出す組織体の活動である、と。だから仕事は、好き・嫌いとか、楽しい・面白くないとかいった「主観的」なことで左右されるべきではない、との建前の中で働いているはずです。

おまけに人間は、社会的動物でもあります。つまり生きて行くには、他者との協力を必要とするのですね。そのためにサルや渡り鳥や蜜蜂よりも、はるかに複雑な協力のための組織を作り上げます。でもその中で、お猿さんそこのけのマウンティング合戦が繰り広げられるのも、ご承知の通り。あの人にならついて行ってもいい、とか、アイツの下にだけは絶対になりたくない、とか。

こうした言わば『ヒューマン・ファクター』が、プロジェクトの設計と運営をはなはだ面倒にしていることは、周知の通りです(もちろん、そうした事自体を楽しむことのできる高度な「人事能力」をもつプロマネも、たまにはいますが)。でも人間が、言われたことだけをやる、感情を持たぬロボットのような存在でないからこそ、チームに思いもよらぬ創造性をもたらすこともある訳です。主観性と創造性は、ある意味コインの裏表の関係にあたりますから。

今回は、昨年広島に開学したばかりの、叡啓大学・ソーシャルシステムデザイン学部学部長である保井俊之先生に、「ウェルビーイング」すなわち『心の幸せ』を中心に据えたプロジェクト・マネジメントについてご講演いただきます。保井先生はPMI日本支部の理事でもあり、PM論に通暁された方ですが、ながらく金融庁で働くかたわら、地域おこしと社会イノベーションの実践に関わってこられました。佐藤も、保井先生のお招きにより、慶応大学大学院のSDM(システムデザイン・マネジメント)学科で、プロジェクトのリスクについて講義をもたせていただいたことがあります。

当研究会ではご承知の通り、数年前から感情をテーマとした講演を、いろいろな分野の専門家の方にお願いしてきました。プロジェクト・マネジメントにおいては、理系的なハード・スキルも重要ですが、人間の感情や欲求の構造に着目した、ソフト・スキルの理解も必須だと考えるからです。ただ、後者はともすると、通俗的なリーダーシップ論や、居酒屋風の経営談義に陥りがちです。そうではない、客観的で体系的な近年のウェルビーイング研究成果をふまえた、ユニークなPM論を学べる機会になるはずです。

大勢の方のご参加を期待しております。


<記>

■日時:2022年9月15日(木) 18:30~20:30 (オンライン開催)

■講演タイトル:
ウェルビーイング(心の幸せ)中心のプロジェクト・マネジメント:
 創造性、業績及び働きがいの同時追求のセオリー

■概要:
本年は、日本におけるウェルビーイング元年といわれます。心の幸せを表す主観的ウェルビーイングは、創造性・業績及び働きがいに高い相関を持ち、これからのプロジェクト・マネジメントに不可欠の要素として近年、急速に注目を浴びています。この講演では、ウェルビーイングの基礎概念から平易に説明し、プロジェクトマネジメントにおける効用をわかりやすく説きます。

■講師:保井 俊之 様
(広島県立叡啓大学ソーシャルシステムデザイン学部学部長・教授、慶應義塾大学大学院システムデザイン・マネジメント研究科付属SDM研究所上席研究員、PMI日本支部理事)

■講師略歴:
1985年東京大学卒業。財務省及び金融庁の主要ポストを経て、政府系地域活性化ファンドの地域経済活性化支援機構(REVIC)常務、中南米向け国際金融機関の米州開発銀行(IDB)の日本他5か国代表理事を歴任。慶應SDMで2008年の開学以来教壇に立つ。国際基督教大学より博士(学術)。米国PMI認定PMPかつPMI日本支部理事。2021年4月より日本初のソーシャルシステムデザイン学部を擁する広島県立叡啓大学の初代学部長。地域活性学会理事兼学会誌編集委員長、日本創造学会評議員。ウェルビーイング学会監事。専門は、社会システムデザイン、社会イノベーション、主観的ウェルビーイング論及び幸福学、金融、公共政策、対話理論及び地域活性化など。


■参加希望者は、三好副幹事までご連絡ください。後ほど会議のリンクをお送りいたします。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 
以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


# by Tomoichi_Sato | 2022-08-27 12:54 | プロジェクト・マネジメント | Comments(0)

引き継いだプロジェクトの状況を把握するために、必要な事とは (+1日セミナーのお知らせ 9/29)

あなたは、ある進行中のプロジェクトを、プロマネとして急遽引き継ぐことになった。前任者は事情で職場を去り、引き継ぎはゼロに等しい。

あなたがまず、やるべき事は何だろうか?

まずはプロジェクト・チームの部屋に行き、前任者のプロマネの席に座ってみる。周囲のメンバーはあなたを、怪訝そうな、あるいは不安と好奇の混じった目で見ている。

とりあえずは皆を集めて、ミーティングを開く。席上であなたは、前任者が都合でプロジェクトを離れざるを得なくなったこと(それは皆も知っていたが)、自分がその役割を引き受けたこと、まだ様子が分からないから皆に教えてもらいながら前に進みたいこと、心配しないでこれまで通り職務に邁進してほしいこと、などを伝える。そしてあなたからはじめて、順に時計回りで自己紹介をしてもらう。だが、親しい人間は残念ながら一人も居なかった。

席に戻って、小さなため息をつく。ともあれ、プロジェクトの状況を知らなければならない。でないと、何についても決断は下せないのだ。でも、プロジェクトの状況を知るとは、具体的にはどこからどう、手をつけたら良いのだろう? 何が分かれば、「このプロジェクトの状況は大体分かった」と言えるのだろう?

あなたはもっと小さなプロジェクトのリーダーをやったことはあった。また、その時の体験から、少しはプロジェクト・マネジメントについても知っておく必要があるなと感じて、手の空いたときに勉強もしてみた。そこで、プロジェクトで一番大事なのは、スコープ・コスト・スケジュールの三要素だ、と学んだ。

コストは、もちろん原価のことだ。プロジェクトが守るべき予算は決まっている。それを超えることは原則、許されない。またスケジュールはいうまでもなく期間で、これも完了期限が決まっている。とくにこのプロジェクトの場合は、会社単位のイベントに紐づけられているので、期日の縛りは大きい。つまり、コストもスケジュールも、守るべき制約条件なのだ。

では、スコープとは何か。スコープとは制約条件なのか? あなたは勉強した内容を思い出してみる。スコープとは、プロジェクトが果たさなければならない責任範囲を示す。「スコープが増えた」といったら、それは責任範囲が、つまりやるべき仕事が増えたことを意味する。

ただし、コストは円単位で、スケジュールは日数の単位で、計量化することができる。じゃあスコープは? これは数値化するのが難しそうだ。ただ、増減や大小は比較できる。だからまあ、制約条件だと言えなくもない。

とにかく、まずはスコープ・コスト・スケジュールを知らなくてはならない。あなたの前任者は、一応「プロジェクト・マネジメント計画書」という書類を作って本社に登録してあったが、中身を見ると、完了期日と予算枠の金額以外は、ひどく抽象的なことしか書いていない。これで会社はよく承認したな。

ともあれ、スコープ=責任範囲を知るには、どうしたらいいか? そのためには、このプロジェクトが生み出すべき成果物、アウトプットは何なのかが、分かれば良いはずだ。何を作れば、このプロジェクトは終わることができるのか? 

そう。プロジェクトとは、終わりのある仕事なのだ。プロマネたる自分の任務とは、この仕事が無事に終わるよう、頑張ることだ。だからまず、ゴール地点の姿を理解しなければならない。

あなたはチームの中でもチーフ格にみえたメンバーに、成果物の全体像が分かる資料がないか、たずねた。すると、「プロジェクト開始時点にもらった仕様書です」という書類をすぐに出してくれた。あなたはざっと目を通してみる。うーむ、こんなものを作るのか。

それは一種の、環境モニタリング・システムだった。複数地点に計測器を配備し、継続的にCO2排出その他の環境負荷データを収集、専用サーバに記録保持する。SDGsとカーボンニュートラルが重視される今日、重要な仕組みだ。

ただ、そうなると、現地での設置作業や調整なども必要になる。成果物としてのハードやソフトを作って、誰かに渡したらお仕舞い、という訳にはいかない。関係者との調整作業も必要だ。成果物づくりに関わる以外の仕事もそれなりにある、ということだ。おまけに技術的に見ても、従来やったことのない機能を含んでいるようだ。つまり、技術開発要素があるのだ。だから試験も必要だ。

ともあれ、いつまでに、何を、いくら以内で作って動かさなければならないかは、分かった。ゴール地点の姿は、少しは見えてきたようだ。
引き継いだプロジェクトの状況を把握するために、必要な事とは (+1日セミナーのお知らせ 9/29)_e0058447_11432109.jpg
だが、これでプロジェクトの状況把握が終わった訳ではない。今、プロジェクトはどこの地点にいるのかが分からなければならない。つまり、進捗と出費の実績を把握する必要があるのである。

プロジェクトの工程表を探したが、あなたの前任者は、線が4本引いてあるだけの、非常にラフな線表しか残していなかった。いやはや。予算表も、探したけれど見つからなかった。一体何を、マネージしていたのだろう?

仕方がないので、あなたはプロジェクト・チームのメンバーと、グループ毎に面談することにした。ところがこのミーティング、状況把握の目的のはずが、技術の問題や人間関係の問題を訴える場になっていき、毎回、決めたりなだめたりしなければならない事が、あなたの前に積み上がるばかりである。

数日後、元のオフィスに戻って上司をつかまえる。状況報告をして、方針やアドバイスをもらいたいと思ったからだ。だが、他にトラブル案件を抱えているらしい上司は見るからに多忙で、「後はよしなに」というだけだった。

まいったな。こういうとき、プロジェクト・マネジメントの標準では、何と何をおさえるべき、と書いてあるんだっけ? あなたは、昨年買ったが、読まずに積ん読になっていた『PMBOK Guide』第7版をめくってみた。何なに、プロジェクト・パフォーマンスには8つの領域があるって? これかな?

その8領域とは、ステークホルダ、チーム、開発アプローチとライフサイクル、計画、プロジェクト作業、デリバリー、パフォーマンス計測、不確実性、の8つだった(ちなみにあなたは、英語版を入手して読んでいたので、上記の用語は日本語訳とは一部合致していない)。

うーん、何だか分かったような、分からないような・・ステークホルダやチーム員の把握が大事なのは当然だろう。だが計画はメロメロだったし、プロジェクト作業の把握って? それにパフォーマンス計測が別にあるのか。心配なのは設計の品質なのだが、それは計測できるのかな。なんだか頭がぐらぐらしてきた。

10日ほど過ぎ、飛び石連休がやってきた。あなたは、以前知り合った、別の会社のベテラン・プロマネを訪ねることにした。自分の仕事の内実を話すのは恥ずかしかったが、せめて何かアドバイスをもらえないかと思ったのだ。

もちろん技術面の詳細や予算枠など、社外の人には話せない部分もあった。が、とにかく自分が曖昧ながら把握したプロジェクトの状況を、あなたはその大先輩に説明してみた。そしてPMBOK Guideも参照してみたが、適用の仕方がよく分からなかった、とつけ加えた。するとその先輩は、意外な事を質問してきた。

「あなたは自分のプロジェクト・チームに、誰を配員するかについて、権限はあるんですか?」

——いえ、ありません。それは上の人間が決めることです。

「チーム員の人事的な査定はするんですか?」

——いえ、それもしません。僕は彼らの直属の上司ではありませんから。参考意見を聞かれることはありますが。

「じゃあ、あなたは予算の枠内で、発注先を選んで、自分の権限で発注できますか?」

——発注には上司の承認が必要です。文房具とか小さなツール類は別として。

「なるほど、そうですか。だいたい分かりました。あなたは人事権、つまりアサインメントや人事評定の権限もなく、発注先を自分一人で選んで発注書を切れる訳でもない、と。」

——はい。

「そしてスコープ(成果物の機能範囲)も、コアの技術も事前に決まっている。最終期限も決まっている。できるのはスコープの若干の調整と、人とタスクのアサイン配分によるスケジュールの調整だけだ、と。そういう理解でいいですね。」

——その通りです。それでは何かまずいでしょうか。

「いいえ。ただ、もしそうなら、あなたはプロジェクト・チームの実務レベルのリーダーではあっても、『プロジェクト・マネージャー』とは呼べないですよ。マネージャーというからには、プロジェクト目的の達成に責任を負う訳です。その責任を果たすには、当然ながら権限が必要です。権限なしに責任はない。PMBOKは、マネジメントのための標準体系です。あなたの仕事がマネージャーでないなら、適用できる訳がないと、思いませんか?

——たしかに、しばらく前までは会社ではプロジェクト・リーダと呼んでいました。でもその後、マネージャーという呼び方に変わったんです。

「呼び方がどうであれ、中身が変わらないなら同じですよ。」

——でも、僕はプロジェクトの達成には責任を持っていますよ。

「良い心がけです。では、教えてください。あなたのプロジェクトの目的は何ですか?」

——目的は、環境モニタリングシステムを作って、立ち上げることです。

「それはゴールに過ぎません。つまりプロジェクトの完了条件です。お伺いしているのは目的です。」

——・・目的って、ゴールじゃないんですか?

「違います。マラソン競技の目的は、42km離れたゴール地点にたどり着くことだと思いますか? 長距離走をやる人間なら、ゴールにはたいてい、入れます。大事なのは、なぜマラソンに参加したかです。それと同じで、なぜ環境モニタリングシステムが必要なのか、それでどんな良いアウトカムが生まれるかを、考えなければなりません。それが目的というものです」

——うーん・・そうですか。でも、自分が仮にマネージャーでなく単なる実務リーダーだとしても、プロジェクトの状況を把握しなければならない事に代わりはありません。いったい、何と何をおさえたらいいか、教えていただけませんか。

「そうですね。そういう時、PMの実務では、7つ道具というか、整理すべき図表が7つほどあるんです。まあ、8つの場合もありますが。それによって、あなたのおっしゃった、スコープ、コスト、スケジュールの他に、組織やリスクなどを含めて、プロジェクトの現在位置を総合的に把握できるようになります。」

——それを、ぜひ教えてください。

「いいですよ、多少説明に時間はかかりますが。ただ、その前にもう一つ、念を押しておきたいことがあります。ゴール地点と、現在位置が分かったとして、それからどうします?」

——それから、って・・そりゃゴールへの道を邁進するのみです。他に何をするんです?

「あなたは前任者からの引き継ぎもなしに、見知らぬプロジェクトに放り込まれました。会社も、今のプロジェクトの状況を把握できていないでしょう。だとしたら、全速力で残りの道を邁進する前に、もう一つ考えるべき事があります。それは、本当に今のままプロジェクトを続ける価値があるのかどうか、です。

——続けるか、どうか・・?

「そうですよ。現在位置とゴールとの距離が分かったら、いつ、たどり着けるのか、それまでどれくらい労力がかかるかも、想定できるはずです。その上で、ゴールで得られる価値と、この先にかけなければならない労力やコストを比較するべきです。それが明らかに不釣り合いなら、プロジェクトは中止すべきでしょう。

——それを、僕が決めるんですか?

「いえいえ。決めるのはあなたの上司であり、会社です。ただ、あなたはご自分のアセスメントを報告する訳です。プロマネは一般に、自分に付託されたプロジェクトを途中で止める権限はありません。ですが、もうこれ以上、努力する価値がないと考えられるなら、率直に報告すべきです。」

——・・そんなの、前代未聞です。ギブアップ宣言じゃないですか。クビになりかねません。

「すでに失敗が見えているプロジェクトを止めなかったら、それは経営の失敗になります。経営の失敗の方が、ずっと被害が大きいのです。別にあなたの今のプロジェクトが失敗だと言っているのではありませんよ。一般論として、です。」

——もちろん、分かりますけれども、ただ・・それって自分の仕事なのかな。

「プロジェクト・マネジメントの目的って、何だと思います?」

——え? プロジェクトの目的と同じじゃないんですか。

「違います。プロジェクト・マネジメントの目的とは、プロジェクトの価値を最大化することにあるのです。」

——プロジェクトの価値を最大化、ですか・・

「プロジェクトの価値には、金銭で測れる部分と、人材育成や顧客の信頼など、無形の価値があります。ですから、単なるコスト計算だけで決められるものではありません。ともあれ、仮にもし人員や費用を追加投入することで、それを上回る価値増大が期待できるなら、追加すべきですし、自分に権限がないのなら、会社に理解を求めるべきです。逆に、万が一プロジェクトを継続することで、かえって価値を毀損するならば、止める勇気を持つ方が良いのです。

——プロマネって、そこまで考えるべきものなんでしょうか。

「まあ現実には、ここまでできる人は少ないでしょうね。ただ、プロジェクトとは価値創出のための活動であることを忘れないでください。そしてプロジェクト価値を総合的に判断することは、現場で最も情報の集中している、プロマネにしかできないことなのです。」


◇- — -◇- — -◇- — -◇- — -◇

ここからは、お知らせです。来る9月29日(木)に、久しぶりにプロジェクト・マネジメントに関する1日セミナーを行います。上に書いた、プロジェクトの状況を把握するための、PM「7つ道具」をはじめ、プロマネが身につけるべき基本的なスキルと技術について、時間をかけて解説します。

オンライン形式ですが、グループ演習などもできる限り取り入れて、具体的な学びにつながるセミナーにしたいと考えています。遠隔地の方も参加しやすいと思いますので、ご検討ください。


プロジェクトを成功させるマネジメント技法とその実践ポイント」(9月29日)

日時: 2022年9月29日(木) 10:30 ~ 17:30
主催: 株式会社日本テクノセンター
セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます)

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

佐藤知一@日揮ホールディングス(株)


# by Tomoichi_Sato | 2022-08-20 11:56 | Comments(0)

MES(製造実行システム)を理解したいエンジニアのために 〜 この6編の記事で全体像が必ず分かる

前回もご案内したとおり、来る9月1日(木)に、MES=Manufacturing Execution System(製造実行システム、ないし製造管理システム)に関する、総合的なシンポジウムを開催する。

工場スマート化のための製造実行システム”MES” ― 広がる導入と実例に学ぶ活用方法
 (参加申込み: https://www.enaa.or.jp/seminar/57017

主催は(財)エンジニアリング協会で、わたしが幹事を務める『次世代スマート工場のエンジニアリング研究会」が企画立案している。オンライン形式で、参加無料である。幸いにも、すでに200人を超える申込みをいただいているようだが、まだ受付中なので、興味がある方はぜひご参加いただきたい。

◇- — -◇- — -◇- — -◇- — -◇

このシンポジウムは製造業の実務に携わる方を、主な対象として想定して、講演プログラムを依頼してきた。ところで、いまさらだが、これは本当に正しかったのだろうか? というか、想定として十分だったのだろうか、という疑問が頭に浮かんできた。IT業界にいるエンジニア達も、MESシンポジウムの聴衆として考えるべきだったのではないか?

というのも、この種のシステムを構築する仕事は、通常、製造業の中だけで内製することは難しいからだ(よほどの大企業は別として)。当然ながら、外部のITエンジニアの力を借りる必要がある。良く知られているように、わたし達の社会では、ITエンジニアの7割はIT業界にいて、ユーザ企業には3割しかいない。その3割の人員も、殆どは本社にいて、人事・財務・販売そしてITインフラ系などの業務に従事している。

昨年10月に同じ(財)エンジ協会で行った、MESに関する第1回シンポジウムでのアンケート結果を見ても、工場にMES導入をリードする部署が見当たらない、という回答が、製造業からの参加者の81%を占めていた。普通この種の大がかりな、複数部門をまたぐシステムの導入を主導するのは、IT部門と考えられる。いいかえると、製造現場にIT部門がありません、という回答が8割以上、ということだ。

(ちなみに昨年のMESに関するアンケート結果は、今年のシンポジウムでも簡単にご紹介する予定だが、詳細なレポートは経産省のHPから見ることができる。『令和3年度 省エネルギー等に関する国際標準の獲得・普及促進事業委託費』という、いささかその中身を想像しにくいタイトルの報告書で、後半部分のP.22からアンケート結果が示されている)

工場にIT部門がないから、製造のデジタル化が進まないのか、それとも製造現場にデジタル化のニーズが乏しかったから、工場にIT部門がないのか。卵と鶏のような問題ではある。むろん、会社の規模にもよるだろうが、昨年の参加者は比較的大企業が多かった。だから、やはり製造系のITを引き受けるITエンジニアは、工場側には足りないのだ。

もちろんMESの普及は、IT業界にとっても重要なビジネスチャンスである。ただ、これまで製造現場というのは、IT業界にとって敷居が高かった。まず、業務が複雑で、分かりにくい。それも業界・業種による違いが大きい(人事や財務などは比較的、業種を超えて業務の共通性が高い)。しかも、PLCやらロボットやら、いわゆる制御系とも、お付き合いしなければならない。おまけに、遠い(工場はたいてい大都市ではなく地方にある)。

それはしかし、逆の面を見ると「参入障壁が高い」のだから、早くマーケットに入り込んで橋頭堡を確保してしまえば、過当競争で値下げ合戦、みたいな状況を避けられるはずである。

そこで、もし製造業の外で働くITエンジニアで、この分野に興味がある方がおられたら、ぜひ9月1日のシンポジウムにもご参加いただけたら、と願っている。ただ、そのためには、MES=製造実行システムというものについて、少しは事前に予習ができると良いだろう。

そのために新たな解説記事を起こすことも考えたが、じつは当サイトでは、MESに関する記事を、過去それなりの分量で書いてきた。その中から、MESの位置づけや概要に関するエントリを6つ、選んでダイジェストを紹介することにしよう。いわば、多忙なITエンジニア向けの、「これだけ読めばMESの概要が分かる」6編である。


  • 製造現場の業務を理解する2編

まずは、業務を理解できないとITの話は始まらない。そのために、まず読んでいただきたいのが、次の2本の記事である


このエントリでは、工場長の仕事、ならびに工場を構成する各部門(製造/生産管理/資材購買/生産技術など)の仕事について解説している。主題との関係上、生産管理部門の仕事をとくに詳しく書いているが、それはまさにMESと関係が強い部分なので、読んでみてほしい。

なお、文章だけだと各部門の流れやつながりが分かりにくいと思うので、念のために図をつけておこう(本図は上述の経産省への報告書p.102でも引用している)。
MES(製造実行システム)を理解したいエンジニアのために 〜 この6編の記事で全体像が必ず分かる_e0058447_17485113.jpg

2. 「『生産統制』の三つの課題」 (2017-11-23)

生産管理という仕事は、生産計画と生産統制の二本柱からなる(と、日本の生産管理学の教科書には伝統的に書かれている)。その割に、「生産統制」という言葉は、あまり製造業の実務では使われていない言葉だし、生産管理部の下に、「生産統制課」なるセクションがある会社は見たことがない。

ただし英語で、生産計画=Production planningと、生産統制=Shop floor controlと対応づけてみると、ずっと話は分かりやすくなる。PlanningとControlはセットだからだ。海図に航路の線を引く。これがPlanningである。実際に船を操舵して、航路の通り運行する。これがControlである。Planを持たずに海に出るのは無茶だし、操舵せずに船がまっすぐ進むと思うのは素人である。

そしてMESとは、非常に簡単に言ってしまうと、生産統制のためのシステムなのだ。まあ市販のMESパッケージには計画系の機能もあるのだが、日本ではあまり使われない(理由を書くと長くなるので別の機会に譲ろう)。ともあれ、Shop floor controlでは、(1)モノと情報のトラッキング、(2)資源モニタリング、(3)パフォーマンス計測が重要である、ということを書いている。


  • MESの位置づけと三層モデルを理解する2編

3. 「MESとは何か」 (2011-06-02)

ということで、10年以上前の記事になるが、まずはそのものズバリ「MESとは何か」である。MESの位置づけを理解するためには、1990年代にAMR Researchが提唱した、「三層モデル」の説明を省く訳にはいかない。もともとMESは、このモデルの第1層と第3層をつなぐ『ミッシング・リンク』として定義されたからである。

MESのないスマート工場なんて考えられない」というのが、わたし達研究会の理解だ。それは、この真ん中をつなぐ第2層の仕事を、現在は人間系が担っているために、データが蓄積されないからだ。

三層モデルはその後、ISA-95という標準規格制定活動の中で、Purdue Modelと呼ばれる5層モデル(Level 0〜4まで)に置き換えられていく。MESはそのLevel-3を担うもの、と位置づけられる。

ちなみにISA-95(S-95とも略称される)は、MES=Manufacturing Execution Systemという言葉ではなく、MOM=Manufacturing Operation Management、という用語を使っている。このため欧米でも、MESとMOMという、二つの言葉が使われていて、若干、分かりにくい現象を起こしている。

本来、S-95の立場では、MOMはMESより広義である(MESは製造のみだがMOMは品質・在庫・保全管理もカバーする)、とされる。だが先にMESの名前でパッケージ商品が生まれ、それが機能を拡張してきたので、必ずしもこの概念規定通りにはなっていない。なので、昨年も今年も、シンポジウムでは基本的に、MES/MOMと併記することにしている。


このエントリは、実は昨年10月の第1回MESシンポジウムのお知らせ記事なのだが、個人的に愛着があるので、ここに取り上げさせていただいた。上記2の記事では、生産統制に3つのエレメントがある、と書いたが、その後でもう一つ、追加すべき事があるのに気がついた。それが、「モノの作り方」に関する情報、すなわちレシピと、SOP=Standard Operation Procedureである。

従来の生産管理システムでは、このレシピやSOPなどの粒度の情報はマスタとして持てなかった。かつ、制御システムだけでも、やりにくい。しかも、レシピやSOP(もっと広くいうとBOP=Bill of Processes)は、設計業務と深くつながっている。大量見込生産を旨とする米国と異なり、日本では少量多品種・設計変更多発だから、ここの部分をいかに人間系からデジタルに置き換えていくかが、重要な課題なのである。


  • MESの主機能と構成を理解する2編


わたしが2000年に、共著で「MES入門」(工業調査会:版元倒産のため絶版)を書いたとき、すでにMESは4業種で広く使われていた。その4業種とは、半導体・医薬品・石油化学・自動車(最終組立ライン)である。そして、それ以外の一般的な産業にも広まるだろうと期待して、本を書いたのだ。

だが、そうはならないまま、過去20年間が過ぎた。その普及のボトルネックは、製造現場の制御機器・デバイス類との通信にある、というのが本エントリの主題である。そして、IoT技術の登場が、この問題を解決するだろう、と、(5年前に)書いた訳だ。

だがそれにとどまらず、この記事では、新しい仕組み・システムが普及するときは、どのようなパターンがあり得るかについても論じている。この視点から、今後のMESの再普及を占ってみるのも面白いだろう。


このエントリは、5の続きである。この記事では、いわゆる「MESの11機能」と呼ばれるリストの解説から始まる。この11機能は、MESA Internationalという米国の団体が発祥の地だが、正直、分かりにくい。これが分かりにくいために、MES全般が分かりにくくなってしまった面さえある。

本エントリでは、なぜ、このような分かりにくさが生じたのかについて、プロセスとディスクリートという製造の二大分野を、一緒に標準に取り込もうとしたからだ、と分析した。そして、ARC Advisory Groupの最近のレポートで(といっても2017年のレポートだが)、Upper MES/Lower MESという新概念を導入したことを、前向きに評価した。実際、この区別は、とくにディスクリート系のMESを理解する上で有用と思われる。


以上、これら6本のエントリをお読みいただければ、MES/MOMに関わる全体像が、それなりに俯瞰できるはずである。もちろんそのためには、ERPだとか、データモデルだとかいったものが、ある程度分かっている必要があるが、そこはまあ、ITエンジニアだったら敷居は低かろう。そこを踏み越えれば、あなたは今、MES/製造実行システムの玄関口に立っているのである。


# by Tomoichi_Sato | 2022-08-12 18:02 | 工場計画論 | Comments(0)

お知らせ:MESに関するシンポジウムを9/01に開催します

MES(製造実行システム)なるものが最近、急速に普及している、と聞く。工場での製造のマネジメントにかかわる仕事を、見通しよく・素早く・楽にしてくれるそうだ。「スマート工場化」の流れにも合致して、現場の生産性向上に貢献するらしい。

ただ、具体的にどんな仕組みなのかが、今一つ分かりにくい。製造現場の事情に明るい「デジタル人材」は社内に少ないし、参考になる情報も限られている。誰に相談したら良いだろうか?

・・こんな風に思い悩んでおられる、製造業や関連産業の皆様のために、(財)エンジニアリング協会「次世代スマート工場のエンジニアリング研究会」は、9月1日にシンポジウムを企画しました。

タイトルは、『工場スマート化のための製造実行システム”MES” ― 広がる導入と実例に学ぶ活用方法』。オンライン形式で、参加費用は無償です。

本シンポジウムは午前・午後1・午後2の3部からなり、総勢14名の講演者によって、事例中心の実践的な報告・紹介が行われます。業種も機械・食品・電機・半導体など幅広く、国内・海外の最新ユースケースや、中小企業の動向、そして国際標準の動きなども解説される予定です。

当研究会では昨年10月にもMESの製品紹介を中心とした半日シンポジウムを開催しましたが、今年はユーザ側の具体的事例を中心に、さらにパワーアップしたイベントといたします。

開催案内と参加申込みはこちらのページです:
 エンジニアリング協会HP https://www.enaa.or.jp/seminar/57017


・・さて、普通のお知らせならここで終わりなのですが、小生は本プログラムの仕掛け人なので、各講演のポイント・聴き所を、当サイトの読者の皆さんだけに内緒で教えてしまいましょう(内緒ですよ、ホント)。

10:00- 「開会挨拶/シンポジウムの狙い」は、慶応義塾大学管理工学科教授・松川弘明先生(当研究会主査で、日本経営工学会の前会長でもあります)のオープニング・アドレス。日本の生産物流とSCMの権威である松川先生から、ピリッとしたお言葉をいただけるはずです。

10:10- 「基調講演」は、経済産業省の製造産業局より講師をお招きする予定です。「ものづくり白書」を担当する部署でもありますから、日本のものづくりの実力と課題について、オーバービューをお話しいただけると期待しています。

10:20- 「基調講演 昨年のシンポジウム成果報告ほか」は、野村総研の藤野直明氏・藤浪啓氏と、わたしとで分担し、昨年実施した『MES導入動向調査』(←METI報告書の後半部分)の結果などについてお話しします。

10:40- 講演A「食品工場におけるMESの機能概要と導入事例」をお話しいただくのは、現在M2 Technology(株)社長で、博士(工学)の松本卓夫様です。松本様は前職で、国内最新鋭の大規模な乳製品工場・物流センターを構築されたプロマネです。MESと製造ラインの制御システムのアーキテクチャについても、独自の考えを披露いただけるはずです。

11:20- 講演B「日立が考えるスマート工場実現のためのデータ・システム活用」。日立製作所の大みか工場は、世界経済フォーラム(ダボス会議)がマッキンゼー社と協力して選定した、世界の「Lighthouse(灯台)工場」に、日系企業として唯一入っている旗艦工場です。吉田秀信様に、とくにデジタルの面を語っていただきます。

13:00- 講演C「『スマートファクトリ』から『ものづくりDX』へ」は、工作機械メーカーの雄、オークマ(株)の領木正人副社長による、本社工場「Dream Site」実現の取組のご紹介です。 領木様はわたしの尊敬する論客で、同社のDream Siteは機械加工組立系スマート工場のトップランナーの一つと信じます。

13:40- 講演D「国内製造業における生産システム投資動向」は、(株)日本政策投資銀行の産業調査部で、ずっとスマート工場を追いかけておられる佐無田啓様のご講演で、主に中堅・中小企業の投資動向と、金融機関から見たポイントなどをお話いただける予定です。

14:00- 講演E「生産設備メーカーから見たMES」は、知る人ぞ知る製造ラインビルダー業界の雄・平田機工(株)の神田橋嗣充様による、主に海外のMES論です。同社は半導体・自動車・電機の3分野で、世界トップクラスの製造業に、工場の生産設備ライン一式を設計・納品して来られました。その目から見たMES像、個人的にも大変期待しています。

14:40- 講演F「中小製造業におけるクラウド型MES導入事例」は、Rockwell Automation Japanの鈴木聡による、主に米国における組立加工系でのMES活用事例のご紹介です。自動化と制御分野に強い同社による、製造管理・MES系ソフトウェアの事例を聞ける予定です。

15:00- 講演G「設計・製造・オートメーションにわたるシーメンス自社工場適用事例」は、ドイツにある同社のErlangen工場での取組紹介です。同社はMESベンダーでもありますが、個別受注生産の制御システム製造にMESを適用するには、どんな知恵が必要だったか。独Industry 4.0の牽引役であるシーメンスの工夫をご覧ください。

15:30- 総括講演「生産システムDX化の鍵を握るMES国際標準の概要と動向」は、全体の締めにふさわしく、エンジ協会でも活躍中の国際標準化コンサルタント出町公二様に、MES/MOMの国際標準ISA-95を解説いただきます。

ということで、当分野に通暁した第一線の講師陣をお招きし、全3部構成・1日がかりのシンポジウムをオンラインで提供します。全体を聞いていただいても、興味ある部分だけに参加いただいてもかまいません。アンケートに回答いただいた方には講演資料を共有いたします。

自分で書くのも何ですが、内容のレベルには自信あり、です。唯一少しだけ心配なのは、盛りだくさんすぎて、時間が足りなくなりそうな事でしょうか。その場合、佐藤のムダなしゃべりは早く切り上げ(笑)、招待講演にできるだけ時間を回すつもりです。ともあれ、製造現場のデジタル化と情報化のコアとなる、「MES/MOMシステム」の導入構築に関心をお持ちの方に、役立つ場を提供する所存です。

ぜひご参加ください。


佐藤知一@日揮ホールディングス(株)


# by Tomoichi_Sato | 2022-08-04 23:24 | Comments(0)