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

お知らせ:スマート工場関連のセミナー2件(2/22 および 3/14)

お知らせです。2月22日と3月14日に、スマート工場と生産マネジメントに関する1日セミナーの講師を務めます。どちらも主に製造業の方を対象に想定していますが、生産系システムにかかわるITエンジニアの方にも、自信を持ってお勧めできる内容となっているつもりです。また3月のセミナーはPDU対象講座ですので、PMP(Project Management Professional)資格に関心ある方にもお勧めです。


1. 【納期遅れを起こさない生産統制のポイント(大阪府工業協会主催 2月22日 9:45~16:45)

久しぶりに大阪で、納期遵守をテーマとした生産統制に関する1日セミナー(有償)を行います。主に受注生産型の工場における、納期短縮のための生産計画と統制(コントロール)について、理論・事例と演習を含めてお話しします。

人手不足が深刻化している昨今、多くの企業が納期問題に直面しています。しかし、生産性の向上はそう簡単ではありません。また、せっかく高価な最新鋭機械を導入したのに、なぜか稼働率が上がらない、リードタイムも短縮できない、という悩みもしばしば聞きます。それも当然です。生産リードタイムは、個別の機械だけではなく、生産システム全体のパフォーマンスで決まるからです。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門」をお読みになった方はご承知の通り、わたしは生産活動の仕組み全般を『システム』としてとらえるアプローチをとっています。その上で、生産システムをより良く運用するにはどうすべきか、仕組みを設計するためには何に留意すべきか、を考えます。こうした『システムズ・アプローチ』は、決して大企業だけでなく、むしろ中堅中小でも有効な方法です。

なお、ここでいうシステムとは、別にコンピュータのことを指している訳ではありません。とはいえ最近は、生産管理システム・ERPや、製造実行システムMESなどが普及期にあり、そうしたITツールを活用して、製造マネジメント業務をどうデジタル化していくかが、ポイントになっています。本セミナーでは、そうしたIT面についても解説します。従来の現場改善コンサルタントの講義に、飽き足りない気持ちでおられる技術者の皆さんのヒントになると信じております。

<記>

日時: 2022年2月22日(火) 9:45~16:45

テーマ: 「納期遅れを起こさない 生産統制のポイント
     ~ 工程管理担当者の実務能力の強化 ~」

主催: 公益財団法人 大阪府工業協会

会場: 大阪府工業協会研修室
     大阪市中央区本町 2-6-12 サンマリオン NBFタワー4F
     (市営地下鉄御堂筋線「本町」駅9番出口より徒歩4分)

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


2. スマート工場 構想企画人材 育成セミナー(エンジニアリング協会主催 3月14日 9:30~17:15)

わたしは4年前から、(財)エンジニアリング協会で『次世代スマート工場のエンジニアリング』研究会を組織し、活動を続けてきています。その中の「人材教育分科会」では、スマート工場実現に必要な教育カリキュラムを開発し、多くの製造業の皆様に貢献すべく、公開セミナーを有償で提供することになりました。今回の内容は、昨年夏にトライアル実施した半日セミナー「スマートファクトリー実現のための必要な知識を学ぶ」を、さらに充実させ、1日コースに仕立てたものです。

主な受講対象者として想定しているのは、工場の中堅リーダー層です。とくに突然、上層部から「工場をDX化しろ」と言われたが、何から手をつけたら良いか分からない、と悩んでいる方々に、自社のスマート工場実現のためのロードマップが描けるようになっていただくことを、目指しています。スマート工場を作るプロジェクトのリーダーを育てることが、コースのねらいです。そのためPMP研修向けのPDU単位も発行します。

ご承知の通り、人材不足問題は、スマート化やいわゆる製造業DX化において、しばしばネックとなっています。その理由の一つは、スマート工場が「工場全体をシステムとしてとらえる」視点を必要とするのに、現実の企業組織は縦割りになっていて、全体の関係やトレードオフが見えにくいからです。また、スマート化の利点やROIが説明しにくい、という問題も抱えています。

本来は座学とグループ演習を交えた3日間程度のカリキュラムを考えていたのですが、コロナ禍の続く現状を踏まえ、今回は1日のオンラインセミナー形式でご提供することにいたしました。その分、圧縮され中身の濃い講義となる見込ですが、ぜひこうした問題に自分で取り組んでみたいとお考えの皆様のご来聴をお待ちしております。

講師は、ゴールシステム・コンサルティングの渡辺薫氏(元・日立製作所)、日本電気の岡野美樹氏、そして小生というメンバーです。これだけの講師陣はなかなか揃えられないと自負しております。

<記>

日時: 2022年3月14日(月) 9:30~17:15
 事前登録制、オンライン形式。

講演者と内容:(敬称略)
  1. 本セミナーのプロジェクトマネジメント観点 ・・・ エンジニアリング協会技術部・川村 武也
  2. スマートファクトリー実現のための必要な知識を学ぶ ・・・ 講師:渡辺 薫(ゴールシステム・コンサルティング)
  3. システムとしての工場~その機能とデータの流れ ・・・ 講師:佐藤 知一(日揮ホールディングス)
  4. スマートファクトリー ユースケース・プロジェクト事例紹介 ・・・ 講師:岡野 美樹(日本電気)
  5. 自社の課題整理と質疑応答 ・・・ 全講師

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

以上、スマート工場の話題にご関心を持つ方の、ご来聴を心よりお待ちしております。


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


# by Tomoichi_Sato | 2022-01-25 22:56 | 工場計画論 | Comments(1)

生産管理システムは生産を管理できるか

今回は前回に引き続き、本サイトにおけるPMと並ぶもう一つの重要なテーマ、SCMに関係する問題を考えてみよう。生産管理システムは生産を管理できるか、という問題である。

何度も繰り返していることだが、管理とマネジメントは違う。日本語の「管理」という言葉は、英語では3種類の異なる概念をカバーするような、いささか曖昧な多義語である。おおむね、
 管理≒Management + Control + Administration
であると理解しておいた方が良い。

逆に英語には、「経営」という便利な言葉がない。新米の中間管理職の仕事も、巨大な企業のCEOの仕事も、同じ”Management”になってしまう。どちらの言葉もある種、奇妙な偏りがあるようだ。

それで、今回の記事では、「生産管理システム」とは工場の生産活動全般をマネジメントするシステムではない、という結論を導くつもりである。じゃあ何をするシステムかって? それをこれから論じるのだ。

最初にちょっと、工場の組織を考えてみよう。これは企業により、またその工場によって、バラバラだろう。だが、とにかく最低限共通することがある。それは、「工場長」がいることだ。英語では”plant manager”という。日本では工場とプラントを区別する傾向があるが、英語ではどちらもプラントplantである。

工場長は生産部門の総責任者だ。つまり生産を管理することが、工場長の仕事である。である以上、生産管理システムは工場長の仕事を代行してくれる。あるいは、少なくとも補佐してくれるツールである。したがって工場長は毎日、生産管理システムの画面を眺めながら暮らしている・・と言うことで、よろしいか?

え、よろしくない? 事実と違う? それは何故だろうか。だって生産を管理するシステムじゃないのか。

工場長の仕事とは、工場マネジメントである。工場をマネジメントすると言う仕事は、例えば次のような要素からなっている:
  • 人事・組織づくり
  • ルール・ビジョン・KPI目標の設定
  • 予算計画とコントロール
  • 設備投資などの判断

つまり、中長期的な仕組みづくりと運営が、工場長の仕事なのである。月々の、あるいは毎日の、工場の操業運営の仕事は、下の部門に任せている。で、このような機能は、普通の生産管理システムはカバーしないらしい。

では、工場長の下には、どのような部門が並んでいるのだろうか。大まかにいって、製造部門、生産管理部門、資材購買部門、生産技術部門、あたりが共通するだろう。実際にはそれぞれが、部だったり課だったり、あるいは係だったり、組織階層のレベルはバラバラかもしれない。ともかくこの4種類の機能組織が、比較的多くの工場に共通している。とりあえず以下の記述では、それぞれが部単位で存在しているとしよう。

製造部門の仕事とは、製造を実行することである。つまり部品を加工したり、組み立てたり、検査をしたり、原料や出来上がった製品を搬送したり、梱包出荷したりする。製造業のQCDでいえば、主に品質に責任を持つ部門だ。

(なお、検査セクションが製造部門から独立して、品質管理部門となっているケースもしばしばある。だがこの場合も、品質に責任を持つのは品質管理部門だけかと言うと、そうではなくて製造部門と品質管理部門の協力によって、初めて品質が守られるのだ)

次の生産管理部門の仕事は、製造部門や資材購買部門に対して、計画し指示を出すことである。自分では、ふつう手を動かす(=製造や検査作業に直接従事する)ことはしない。QCDでいえば、主に数量とD(納期)に責任をもつ部門である。

資材購買部門の仕事は、文字通り原料・資材の発注と入荷・保管を受け持つことだ。いわゆる外注加工の手配なども、この部門が受け持つことが多い。QCDでいえば、主に部品資材のコストに責任を持つ部門である。

生産技術部門の仕事は、製品の設計情報をもとに、その作り方(工程・手順・製造仕様)を考え、生産設備の設置・改善・保守を行うことである。QCDには直接関わらないが、実際には作り方によって、品質もコストもリードタイムも、かなり影響される。主に生産量と生産性に責任を持つ部門だと言っていい。

ちなみに、工場組織というものは、工場の規模・サイズと共に、少しずつ専門分化していく(組織は一般にそうだ)。小さな町工場には、製造部門しかない。あとは社長がいるだけだ。しかし、それが少し大きくなり、機械や工程が増えて中堅に近づくと、生産管理部門が独立してくる。そして、資材購買部門も独立するだろう。だが生産技術部門が独立するのは、それなりの規模になってからである。

さて、生産管理システムとは何かというと、じつは上記4部門のうち、生産管理部門の日々の定常的オペレーションをサポートする道具なのである。

では、生産管理部長の仕事とはどんなものだろうか。

ここでちょっと、レストランの仕事を想像してみて欲しい。あなたはレストランのオーナー経営者だ。あなたは普段は、入り口に近いレジ係の後ろに座って、店内のすべての状況をつぶさに見ている。お客の入りはどうか。なごやかに満足して食事しているか。

ウエイターやウェイトレスなどのフロア係は、てきぱきと仕事をしているか。厨房は湯気の立ったおいしい料理をタイムリーに提供しているか。テイクアウトやお土産用の調理品は、ストック切れしていないか。

厨房に対してお客様の注文を伝える仕事は、フロア係のチーフである。お客様が次々にやってきては、いろいろな種類の料理を注文する。ウエイターやウェイトレスは、それを伝票に書き込んで、厨房のカウンターに持ってくる。

すぐ出せる料理もあれば、時間のかかる料理もある。でもお客様には、なるべくちょうど良いタイミングに揃えて出したい。だからどの料理を何個、どの順番で作るべきかを厨房に支持するのは、そこそこ大きなレストランではとても大事な仕事である。

レストランのフロア係が厨房に指示を出す仕事。それがまさに、生産管理部門の仕事なのである。大事なのは料理の種類と数量、そして順番(納期)である。テイクアウト用のストック品の在庫も、見ていなければならない。また材料品切れのメニューは、注文をお断りしなければならないから、厨房の中の材料にまで、注意が及ぶ。

レストランのたとえでは、厨房=製造部門、だと思えばいい。そして生産管理部門とは、営業(顧客注文)と製造現場とをつなぐ、インタフェースの役割を果たしているのである。

レストランの場合、「オムライス2人前!」と厨房に頼めば、後はコックが作り方も知ってるし、材料も手配して取り出し、カット・下ごしらえから、加熱・調味・盛り付けまで、自分たちで全部段取りよくやってくれる。出来上がったお皿をカウンターからとって、配膳すれば終わりである。つまり、注文から、製品の完成まで、たったひとつの指示ですむ。

しかし普通の工場はそうはいかない。製造部門は多くの場合、加工・組立・検査・塗装等の工程ごとにチームに分かれている。したがって工程ごとに、別々の指示を出さなければいけない。そしてそれらの指示は、段取りよく互いにコーディネーションされている必要がある。中身のチキンライスもできない内に、外側のオムレツだけ焼いたら、包むものもなくただ皿の上で冷めていってしまうからだ。

じっさい、(わたしはまだ見たことがないが)チェーン店のセントラル・キッチンなどは、食材の洗い・皮むき、カット、下ごしらえ、焼き物・揚げ物、調味盛りつけなど、たぶん工程毎にセクションが分かれているに違いない。そして、分業したチームの間を、中間製品の食材が行き交っている。だから、必ず生産管理担当者がいるはずだ。

いいかえるなら、普通の生産管理部門の仕事とは、
  • 製品の販売数量と納期と在庫量から、正味必要な生産数量の計画を立てる
  • 計画に従い、加工・組立・検査・塗装等の工程別に製造指図を出す
  • 製品に必要な資材や外注の発注依頼を出す
  • 製品と資材部品のストック在庫数量を見て引当をかける
  • 製造の進捗を現場と確認する
  • 製造実績を集計し、コストを計算する

などの要素からなる事が分かる。

ちなみに2番目の、工程別の指図を出す仕事を、「工程展開」と言う。工程展開のためには、BOP=Bill of Processes(工程表)のマスタ情報が必要である。またその次の、部品別の購買依頼を作る仕事を、「部品展開」という。部品展開のためには、BOM=Bill of Materials(部品表)のマスタ情報がいる。この二つのマスタ情報は、普通、生産技術部が用意する。

当たり前だがこうした部品展開や工程展開の作業は、製品の種類が多く、入れ替わりが速く、製造工程が複雑になればなるほど、手間がかかる。

だから生産管理担当者にとっての夢とは、
 「○日までに製品▲を100個作ってね!」
と言っておけば、あとは全部製造部が考えてやってくれる、と言う世界である。

これは、製造現場が優秀なら、生産管理(という独立した職務)はほとんど不要だ、ということを意味している。逆に、製造現場に全て任せて、中身はブラックボックス化していると言ってもいい。

逆に、生産管理担当者の悪夢とは、どんな状況だろうか。顧客の要求納期は毎日変更、品質は不出来で資材は欠品、設備は故障続き・・・といったていたらくでは、計画が成り立たない。まあそこまでいかなくても、現場が何をどの順序でやっているのか、さっぱり見えない、というのも生産管理担当者の悩みである。そこで現場を見て回る、「進捗追っかけマン」なる奇妙な職種が生まれたりする。

生産管理部門の成績をはかるモノサシ(KPI = Key performance index)は、何だろうか。生産管理の仕事とは、いわば需給を調整することにある。営業部門からきた需要(注文)と、製造部門による供給を、ぴったり合うように、品種とタイミングをすり合わせるのが生産管理の一番の役割である。つまり、カッコいい言い方をすれば、「工場内のサプライチェーン・マネジメント」が生産管理部門の仕事なのだ。

それはまあ、QCDのうち、D(納期)を守ることだ、と思えるかもしれない。だが、納期は守るが、工場の原材料倉庫にも営業倉庫にも、余計なストック在庫がジャブジャブある状態で、納期だけ守りましたといっても、あまりほめる人は多くあるまい。納期と在庫量は、ある意味、コインの表裏の関係にあるからだ。

すなわち、需給がぴったり一致した状態とは、余計な在庫もなければ、バックログ(受注残=マイナス在庫)もない事を意味する。つまり、累積需給曲線(流動数曲線)を各品目について描くと、需要線と供給線がぴったり重なることが、理想状態である。そこからのズレは、余分なストック在庫か納期遅れを意味する。

そうはいっても、需要は(日本の製造業の現実では)めまぐるしく変化するし、供給サイドだって思わぬ事が起きるから、馬に乗って動く標的を矢で射るような、難しい仕事ではある。

ともあれ、これが「生産管理」のコアの仕事である。生産管理部門はコストも集計するだろうが、資材価格は購買部門が握り、労務費は製造部門に委ねている(たぶんほぼ固定費)から、差配できる範囲は限られていて、レポーティングの役割が主だ。

そこでようやく、生産管理システムって何?、の問いに答えることができる。生産管理システムとして最低限、必要なアウトプットとは、
  • 受注(需要)数量と納期
  • 在庫量と引当
  • 製品別の生産指示
  • 部品の発注依頼
  • 部品入荷実績と製品の生産実績
  • コスト集計
などに関する数表と帳票、ということになる。

ただし、これは製品の作り方が完全にブラックボックスの場合で、工程別に指示が必要な場合は、さらに
  • 工程別の製造指図と実績
が必要になるだろう。

そして、上記を支えるためには、マスタデータとして、
  • 部品表(BOM)
  • 工程表(BOP)
が必要になるはずである。それらを支える、品目マスタや工順(工程)マスタもいるはずだ(個別性の強い生産形態ではマスタが作りにくいので、略されるケースもあるが)。

QCDのうち、Q=品質関連の機能は? じつは、ここにはない。「製品××を、○日までに△個、合格品質で作ってね」というのが、生産指示だからだ。

もちろん、ソフトウェア・パッケージという商品はその性質上、機能をどんどん付加していく傾向がある。したがって、今日市場で「生産管理システム」という名の下に売られているソフトは、もっといろいろな機能をカバーしている。品質データも、少しは入っているかも知れない。

ただ、本当の意味での厨房の内側、つまり製造業務の中の話は、あまりカバーしていないかもしれない。製造オペレーションでは、いわゆる「4M」が大事になる。Man(作業者)、Machine(製造設備)、Material(製造対象物)、そしてMethod(手順・レシピ)である。

このうち、製造対象物は、量としては把握しているだろうが、個品やロットの識別となると、難しくなる。現場での専用端末などが必要になるからだ。生産管理システムの多くは、オフィス用途で、サーバとPC端末というアーキテクチャが基本だ。現場にPC端末を置いて入力するのは、いろいろな制約があって、使いにくいことが多い。こうした領域は、製造実行システム(MES = Manufacturing Execution System)の出番になる。

ということで生産管理システムは、生産管理部門の仕事を、カバーしてはくれる。だが、非常に広範な活動の集合としての『生産』自体を、マネジメントしてくれる魔法の杖では、今のところないのである。


<関連エントリ>
 →「なぜ生産管理システムはちゃんと機能しないのか」 https://brevis.exblog.jp/23748681/ (2015-10-07)

# by Tomoichi_Sato | 2022-01-18 12:58 | サプライチェーン | Comments(0)

プロジェクト・マネジメント・システムは存在しうるか

明けましておめでとう。本年も当サイトを通じて、皆さんとマネジメント・テクノロジーについて一緒に考えていこうと思う。どうぞよろしく、お付き合いいただきたい。

さて、年初なので、少し基本的な問いを考えてみよう。プロジェクト・マネジメント・システムは存在するのか、しうるのだろうか、という問いである。

マネジメント・システム」という言葉には普通、二種類の用法がある。方式・体系としてのマネジメント・システムと、ITとしてのマネジメント・システムである。前者の類例には、「品質マネジメントシステム」などがある。いわばルールと手順の体系であって、それ自体は全てを紙ベースで進めても構わない。

わたしがここで問題にするのは、後者である。つまり、プロジェクトをマネジメントしてくれるソフトウェアは存在しうるか? との問いだ。この問いに答えるには、プロジェクト・マネジメントとは何か、あるいは、プロジェクト・マネージャーの仕事とは何なのか、を考えねばならない。

プロマネの仕事の中心には、「決めること」がある。したがって、少なくともプロジェクト・マネジメントの重要な要素として、何らかの「決断」があるはずだ。

今の世の中には、データさえ蓄積できれば、AI・アナリティクスで自動判断できるようになる、という楽観的な信憑がある。したがって、将来はAIがプロマネのかわりに判断してくれるようになる——のだろうか? ちょうどAIによる自動運転が、人間を車の運転から解放してくれるように。

そういった将来像を描く人もいるだろうが、とりあえず、まだそれは現実ではない。では現時点でのプロジェクト・マネジメント・システムとは、何をするのか。プロマネの判断を「助けてくれる」のだろうか? そして将来的には、自動判断に発展する可能性を持つものなのだろうか。そんなシステムは存在しうるのか。

別にわざわざ、そんな問題を立てる必要は無い。現にお前さんの働く会社だって、プロジェクト・マネジメント・システムを持っていると、言っているじゃないか。そんなご指摘が、読者の間から聞こえてきそうである。

ごもっとも。日揮のPMS(Project Management System)については、Webサイトでも情報を公開している。

このPMSはどのようなITシステムなのだろうか。本システムは主に、プラント系のプロジェクト向けに作られている。プラント系プロジェクトは普通、EPC (Engineering=設計, Procurement=調達, Construction=建設)の3フェーズ(3業務)からなっている。そこで日揮のPMSも、
  • Engineering Management System
  • Procurement Management System
  • Construction Management System
の大きな3つのサブシステムと、それを取り巻く周辺システム群からなっている。

そしてそれぞれが、プラント系プロジェクトを動かす主要素である、「設計文書・図面」「資機材」「建設工事作業」について、いわばマスターリストを保持し、それらにまつわるコスト・スケジュール・リソース等の、データを集約する機能を持っている。

(ただし、今ウェブサイトを見てみたら、英語の説明の図はちょっと内容が古いなぁ。直してもらわなければ。連休明けにやらなければいけない仕事が増えてしまった・・)

日揮のPMSは、長い歴史があるため、ほとんどが自社製(一部パッケージベース)の作り込みである。

では、このシステムがあるため、日揮のプロマネは大船に乗ったような気分で、着実に心配なく仕事ができるのか? 自分は要所高所の判断だけを下し、後はシステムが皆を采配して仕事を進め、結果として納期も守り、利益も上がるのか。そうだ、と答えたいところだが、現実は全然違う。

現実のプロジェクトはリスクの塊である。プロジェクトとは、最初に労力や資金を投入して、最後に価値あるアウトカムや利益を得る、一種の賭けなのである。プロマネの仕事とは、プロジェクトをマネジメントするとは、上手に賭け(仮説)を仕立てて、人々をそれに向けて動かし、見事にその果実を得ようとするところにある。

マネジメントは管理ではない。このことは何度か、このサイトでも書いた。英語のマネージManageとは、御しがたいものを、自分の意図や目的に沿うように動かすことである。暴れ馬を乗りこなすイメージだ。英語で、I can manage my car.といったら、その人の車には何か問題があるのだな、ときいた人は思う。

仕事におけるマネジメントの概念の中核には、「人を動かす」「人に働いてもらって目的を達する」という意味がある。自分自身で手を動かして、具体的な成果物を作ることは、マネジメントではない。成果物を作ること自体は立派な仕事で、それがなければプロジェクトは前に進まない。だがマネジメントとは、そうした仕事を方向付けし、組合せ、采配して、総体として機能し価値ある成果をインテグレーションすることにある。

もちろん、日揮のプロマネはPMSがなかったら、仕事にならない。そうでなければ10万点を超える図面や仕様書、100万点近い資機材を、どうやってコントロールするのか。ただ、それはプロジェクト・マネジメントにとって必要条件だが、十分条件ではないのだ。PMSがあればプロマネが不要になる訳ではない。

(あなたが製造業の人なら、たとえば考えてみて欲しい。生産管理システムは生産をマネジメントしてくれるのか? 工場長は不要になるのか? もちろんそんな事はない。生産管理部長が不要になることだって、まったくない)

そもそも、プロマネの仕事とは何か。プラント系プロジェクトの枠を離れて、少し一般化して考えてみると、以下のような要素からなることが分かる:

  • プロジェクトをデザイン(計画)し、
  • 組織とルールと手順をつくり
  • ゴール・目的・目標などビジョンを示して
  • チーム員を引っ張り
  • 人に仕事をアサインし、指示を出し
  • ステークホルダを説得してプロジェクトに協力してもらい
  • リスクを予知して事前対策を講じ
  • 途中途中で進捗やコストや中間成果物の品質を確認し
  • 外部環境変化や内部状態の変化から生じる問題を検知・分析し
  • 予測と価値評価を行い
  • 適切な決断を下し
  • プロジェクトの着地点を見据えて皆をモチベートし
  • プロジェクトの成果物や所産をアウトプットを、適切なアウトカム(運用や価値など)につなげ
  • 経験からの学びをLLとしてまとめる

こうした職務を進めるのための要件をまとめると、5つくらいに集約できそうだ。

1. 価値観が必要

決断を下すためにも、人にビジョンを示して引っ張るためにも、何が価値あることなのかについての基準をしっかり持つ必要がある。え? 企業活動ならば、利益を最大化することで、すべては尽きるはずって? そうだろうか。たとえば、実績づくりや人財成長など、非金銭的価値はどうするのか。これらも含めて、決断が必要なのだ。

2. プロジェクト・デザインの能力が必要

プロジェクト初期における計画や組織づくりにおいては、全体の仕事をどのように分割し(あるいはモジュール化して)、どこを誰にやってもらうのが適切かを考える仕事がある。妙な切り方をするとインタフェースが増えて、トラブルの原因になる。手配可能なリソースには限界もあるし、適性もある。こうした仕事(Work framingとも呼ぶ)は、一種のデザインに属する。デザインは本質的に、サイエンスとアートの中間領域にあって、センスを要求される。

3. 対人的なコミュニケーション能力が必要

プロマネはその時間の半分を、人とのコミュニケーションに費やす、とよく言われる。マネジメントが人を動かす仕事である以上、ある意味で当然なのだろう。それも、相手はチーム員だけでなく、社内外の種々のステークホルダ達である。したがって人を動かすといっても、単なる命令ではなく、説得とリーディングが要求される。おまけに、人と人の間には、どうしても面子や好き嫌いといった、ヒューマン・ファクターが大きくからむ。何を言うか、だけでなく、誰を通じてどう言うか、までが賢慮の範疇である。

4. 予測(あいまいさ=リスクを含む状況下で)の能力が必要

プロジェクトはリスクのかたまりであり、また現状把握それ自体も案外難しく、曖昧さの残る状況で、先を見通さなくてはならない。もちろん、誰しも100%先のことが分かるはずはない。ただ、洞察力は、環境変化への適応性を高める上で、必須である。

5. 結果を引き受ける責任感(覚悟)がある

うまくプロジェクトをデザインし、先を見通し、価値観を持って人を説得したとしても、そのプロマネが最終的な結果を、良し悪しを含めて引き受ける責任感が必要だ。そうでなければ、そうでなければ、誰がプロマネの言うことを聞くだろうか?

以上、どうみても、この5つの要件全て、機械化・自動化は困難だろう。賭けたっていいが、10年、いや100年たっても、AIではできっこない。そのような意味では、プロジェクトをマネジメントしてくれるシステムは、存在しないと言っていい。

では、現実のソフトウェアは何ができるのか、何をさせるべきか。それについては、IT分野の人たちは、様々な業務型システムでの経験から言えることがあるはずだ。

普通は、まず記録(実績)系の機能からスタートする。

プロジェクトで言えば、まず受発注からだ(日揮でもそうなっていた)。企業として、外部企業とのインタフェース記録を残す必要があるからだ。入出金については、会計ソフトがある前提としても、モノの入出荷の実績は(ものを扱うプロジェクトならば)必須だろう。

さらに記録と言う面では、情報(ドキュメント)の登録保管、人の実績工数(タイムシートからの集計)なども機能として欲しくなる。

実績系のつぎは指示(計画)系の機能が来る。

プロジェクトと言えば、実行予算計画が必要だ。また、モノの種類と数量に関する指示(計画)が、加工や移動にともなって、ほしくなる。

さらに、人のかかわる作業=アクティビティに関する指示(ワークオーダー)へと、機能面の要望は進むだろう。とくに、モノに関わる現場的作業だけでなく、設計等の知的作業についても、計画と指示の必要性が出てくる。

ところが、実は日本ではこれが難しい。まず、日本の商習慣のために、顧客や外部からの変更要求が多い。もう一つ、日本では働く人がおおむね優秀なので、自分から指示を待たずに動いてくれる。それはとても大事でありがたいことだが、逆に指示する側が、多少曖昧で大雑把でも、仕事が動いてしまう。これはアジアを含む海外ではあまり期待できないことだ。

おまけに実際の遂行段階で、問題が生じると、計画していなかった作業が頻繁に発生する(設計変更対応等はその良い例である)。こうした問題があるために、ざっくりとした工程計画だけ立てて、詳細は現場で担当者同士が、別のExcel表などを使って調整したりする。

こうなると、現場にいちいち確認しないと、進捗の途中経過が見えなくなる。負荷も余力も分からない。だから納期も見えない、という状況になりがちだ。

まあ日本では工場ですら、細かな製造指図がなく、現物中心で動いていたりする国である。「それで動いているんだから何が問題なんだ」と大勢の人が思い込んでいる。結果として、後で振り返って分析しようにも、詳細なデータが何も履歴として残っていない状況になる。

だからこそ、今後はオフィスワークを含む指示(オーダー)の概念や、それを可視化するチケットが重要になるはずである。

実績系・指示系と進化してきたら、さらにはデータ保守・交換・分析系の機能に進むだろう。マスタデータの保守、外部システムとのI/F、そしてデータ蓄積などである。

ただし、この3つは、実績形が完全に終わってから指示系に進む、といった形ではなく、ある程度重なり合いながら、機能を少しずつ充実化していくのが普通だろう。

以上が、今の世の中における、プロジェクト・マネジメント・システムの有り様である。プロジェクトをマネジメントしてくれるシステムは存在しない。今後も多分存在しないだろう。プロマネの決断をサポートする数値やデータを、提供してくれる機能はあると思う。いわば実行コントロール系の機能である。

だが、それは船の航海にたとえれば、GPS付きの操舵システムのようなものだ。船の現在位置、速力、これまでの航路や、積荷の上げ下ろしは、正確にわかる。だが空模様と海象をにらみながら、船団を率いて航路を決めていく任務は、常に船長という人間に残されているのだ。


<関連エントリ>
 「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ (2017-12-18)

# by Tomoichi_Sato | 2022-01-10 15:24 | プロジェクト・マネジメント | Comments(0)

クリスマス・メッセージ:フェアな社会を裏付けるもの

Merry Christmas !


世界最古の成文法であるハンムラビ法典には、有名な「目には目で、歯には歯で、つぐなえ」という条項がある。“目には目を”、という言葉には、復讐のニュアンスが強いので、まるで報復を推奨する法律のように思える。だが、実は逆である。

この条文が意味しているのは、もしも何らかの傷害を受けて、自分が仮に片目を失ったとしても、相手の片目以上の報復をしてはいけない、という制限だ。これを『同害報復』原則と呼ぶ。

ハンムラビ王が同害報復を明文化したのは、報復のエスカレーションが実際には中東では多かったためだろう。自分が受けた被害以上に、相手に復讐する。日本でも「倍返しだ!」という言葉で有名になったドラマがあるが、古代の中東では、倍返しどころか「7倍返し」くらいが珍しくなかったのかもしれない。いや、古代どころか現代でも中東で紛争が絶えないのは、人間の復讐心というものが、なかなか制御しきれないからだろう。

借りたものは、返す。貸したものは、返してもらう。その時は、同等のもので返済するのが、フェアな感覚というものだ。まあ、当然のことだろう。モノの貸し借りだったら、文字通り同じモノが、借りてと貸し手の間を行き来する。もちろん、そうできない場合もある。クリスマス・プレゼントの交換なども、その一例だ。そんなとき、あまり価値に不釣り合いがあっては、気まずい。

「フェアである」とはどんな事かを、最近考えている。

もしかすると、その一番根底にあるのは、「貸し借り」の感覚だったのかもしれないと、思う。現在のビジネス取引は、商品と支払いが引き替えで、売りと買いが同時に成立する。だが、昔の取引は(特に物々交換は)相手に渡すのと、相手から受け取るのに、時間差があったはずだ。その間は、「貸し借り」の関係ができる。でも、その貸し借りの一時的アンバランスな状態は、ほぼ等価のものを返すことで解消する。これを支えるのは、人間が持っている、損得に関する原初的な欲求だと思う。

交換』の概念もまた、おそらくここに始まる。あるモノと別のモノが、交換可能であると互いに思えること。それが交換の基礎である。農民と山の民が、薪とお米を交換するとき、まったく別種の用途に使う別種のモノが、お互いにほぼ等価に見えなければ、交換とか交易は成立しない。

そこで、交換価値というものが、使用価値とは別に生じる。さらに、交換価値の指標として、貨幣(権利の表象)が生まれるのだろう。貨幣それ自体に、絶対的な価値はない(だから為替相場が上下しうるし、インフレも起きる)。ただ、貨幣という汎用的な交換価値を表す道具が普及して、市場と市場原理なるものが、ようやく成立するのだ。ここでは貨幣で等価であることが、2者間のフェアな交換を表す。

貸し借りはまた、「約束」の感覚のはじまりでもある。

二人の個人が、貸し借りについて約束をしたとしよう。でも、貸し借りだから、一時的なアンバランスが生じる可能性がある。その場合、個人間の約束を相手が果たすという保証は、どこにあるのか? 交換でも実は同じで、たとえば実物の引き渡しと代金の支払いのタイミングが異なることは、よくある。商品を先に渡して、あとで相手が支払ってくれると、確信できるのか?

むろん、「彼は約束を守る人だ」という『信用』が、ある意味では、保証することもある。個人間のちょっとした貸し借りは、そのレベルで済む。なじみの酒場で、ツケで飲むのも(まだやったことはないが)、その類いである。

しかし、もう少し大きな約束事になると、もっと具体的な、頼れる手立てが欲しくなる。ここで、個人間の約束に、外部からの強制力をあたえる、『』(おきて)とか、法とか呼ばれるものが登場する。それは組織・社会と共に、誕生してくるのだ。約束を破る者、個人間でフェアに振る舞わない者は、組織や社会からなんらかの罰を受ける。これが強制力だ。

欧米、とくに英米法の概念では、
 契約=約束+強制力
という風に理解することができる。契約は単なる約束(合意)よりも強いものだ。

ところで、単なる交換の場合は、1:1の関係だけを考えれば良かった。しかし、組織や社会が成立すると、1:Nの関係も生じてくる。たとえば、学校の先生が特定の生徒だけを「えこひいき」したら、、子どもだって、フェアじゃない、と思うだろう。あるいは、会社での昇進や給与の査定だって、そうだ。組織では、1:Nの関係でも、フェアであることが、要求されるのだ。

先生とか上司は、組織の中で一定の権力をもっている。『権力』とは、掟を定める権限と、価値を配分する権限を表す。給与は貨幣的な価値だし、成績評価は学業的な(進学を左右する)価値だ。だが、彼らはそのような権力をフェアに行使することが、求められる。そのためのルール=掟も、ふつうは定める。つまり、社会的強制力(権力)自体も、乱用を防ぐ仕組みが必要なのだ。

個人間の貸し借り・約束から始まって、交換と市場メカニズム、そして組織・社会におけるルールまで、世の仕組みは発達してきた。どのレベルでも、フェアであることが要求され、またそれを支える方法が作られている。では、これで、フェアな社会が成立するだろうか?

そうは限らない。それは植民地に暮らす人びとを考えてみれば、分かる。植民地には市場もある。貨幣もある。法律だって、もちろんある。王権だって、あるかもしれない。たとえばローマ帝国の支配下にある国々。「皇帝」とは王の上に立つ王、という意味で、「帝国」とは諸王国の上に支配するスーパー国家である。それぞれにローカルな王がいて、伝統的な掟も生きている。だが王の上にローマの総督がいて、王権を監視・制限している。税金を課し、あるいは労働を徴用する。

植民地に真の自由はない。それはいつの時代も同じだ。社会の上層部にいるのは、支配国側の人間、あるいは彼らに媚びへつらう連中だけだ。その国の人間は、まともな職業・地位に就けない。その国に生まれた民族だというだけで、差別的な待遇を受ける。まことにアンフェアである。

つまり、たとえ社会に法律があったとしても、それが「冷たい法の支配」だ、という状態もあり得るのだ。

別に、ことは植民地に限らない。たとえば独立国だが、その社会では、過度の実力主義が支配原理だったとする。過度の実力主義とは、つまり、「運も実力の内」という通念が支配する社会である。富める者はますます富み、乏しい者はますます貧しくなるような仕組みが、市場原理を通じて制度的に固定化される。最初にちょっと運が良ければ益々富み、最初に運が悪ければ、ますますいじめられる社会だ。両者の溝は深く、下からは簡単に這い上がれない。そういう世の中は、フェアとは呼べないように思う。なぜなら、自分の意思の力が届かない社会、能力も努力も認められない社会だからだ。

そんな社会では、フェアな扱いへの要望が静かに堆積し、発酵して、次第にアンフェアな扱いをされた事への怒りに転化・沸騰していく。大勢の人に対するアンフェアな扱いが長く続くと、社会に怒りの感情が充満する。無意識に、攻撃性が高まる。そして組織や集団が不安定になり、世が荒れる。

では、そうした「冷たい法の支配」に欠けている、足りないものは、何なのか。

答えは簡単だ。暖かい「情け」の気持ちである。人生にはいろいろな運・不運がある。そのこと自体は、どんな社会になっても、かわらないだろう。だが、わずかな運の天秤の傾きが、その人の人生の苦労を長らく規定するような制度は、あまりフェアでない、と我々は感じる。そういう場合には、なんらかの手助けとなるように、法や仕組みが運用されるべきだ。そうでない社会は、「情けない社会」である。

なお、「情け」という大和言葉をつかったが、古代中国人なら「徳」と呼び、西洋人なら「愛」という言葉を使うかも知れない。いずれにせよ、それは、他者に対しても、自分自身と同じように大事にしようという気持ちである。

自分が他人の立場だったら、どう感じるか。自分と他人を、交換してみる。そこで等価に扱うのが、フェアである。いや、こんな理詰めの説明では少しずれてしまう。フェアであることは、(理屈の問題ではなく)気持ちの問題なのだから。

もちろん、ここでわたしが言っているのは、権力者が情け深くあるべきだ、というような話ではない。約束やら取引やらに関わる一人ひとりが、そうした気持ちをもって、はじめて世の秩序に「魂がこもる」のではないか。

O・ヘンリーの『賢者の贈り物』は、ある貧しい夫婦の、クリスマスの物語だ。乏しい中を切り詰めて貯めた、わずかな金額を前に、若い妻デラは大好きな夫ジムに、何かプレゼントをしたいと考える。夫が唯一、誇りにしている父の形見の金時計のために、ちょうどいい鎖を買ってあげたい。だが彼女の持ち金では足りないのだ。彼女が売ることができる大事な持ちものが、たった一つあった。それは彼女の波打つ、豊かな金色の髪だった・・

クリスマスの贈り物を交換し合う、若い二人の物語は、青空文庫で読める。ごく短い掌編だから、ぜひ読んでほしい。ほんの数分で読める。そして彼らを、何故あえて作者は、「賢者」と呼んだのか、考えてみてほしい。

あるいはもう一組、若い夫婦の物語を紹介しようか。こちらは古代の中東の話だ。ローマ帝国治下の植民地、パレスチナの農村のことである。夫婦といっても、まだ婚約したばかり。ただ、この地の掟では、婚約したらすでに、夫婦と同等に扱われる。婚約は約束だが、強制力があるのだ。

男の職業は、大工だったらしい。だが彼は、若い許嫁(名前をミリヤムといった)が身ごもっていることに気がついた。もちろん、自分の子ではない。何ということだ。こんな状況では、男なら誰だって、はらわたがちぎれる思いになるに違いない。

この当時、姦通は重罪だった。相手の男と一緒に、石打ちの刑となる。事実上の死罪である。もちろん、彼はこのことを表沙汰にしても良かった。むしろ、宗教の掟では、そうすべきだった。

だが彼は、そうしたくなかった。情け深い人だったのだろう。かわりに、ひそかにミリヤムを離縁しようとした。すでに正式に婚約していたから、それを白紙に戻すとなると、おそらく金を払って役職者を買収しなければならない。彼はそこまで、腹を決めたのだ。

だがその夜、彼は不思議な夢を見る。夢枕に立った、神の使いから、「離縁してはいけない。その子は、神様の聖なる息吹で授かった子だ。大きくなって、この国の人びとを救う。ヨシュアという名前をつけなさい」と告げられる。彼は目覚めて、その言葉どおりに従う。ヨシュアは、「ヤーウェ(神)は救う」という意味の名前で、その地方の訛りではイェシューと呼ぶ。ギリシャ語ではイエスス。英語ではジーザス、日本ではイエスと普通、表記する。男の名はヨセフ。妻ミリヤムの名は、ラテン語ではマリアという。

男ヨセフの生涯については、あまり詳しい事は伝わっていない。ただ、その子イエスは大人になると、大工の職を継がずに、宗教改革者の道を選んだ。そして「目には目を」の掟が残るその地で、「報復はやめろ。 自分の仇だって大事にしろ。7の70倍も許せ」というような、常人にはほとんど不可能と思えるような事を、説いて歩いた。

ローマ帝国の苛烈な支配下にあったから、彼の弟子の中には、一気に革命を、グレート・リセットを、みたいな事を夢見た者もいたに違いない。だが、彼はそのような権力奪取の政治的・軍事的な行動は選ばなかった。それだけでは世は良くならないと、知っていたのだろう。かわりに、人々にも弟子たちにも、お互いを大事にすることを求めた。

彼が捕らえられる前の晩、弟子たちに最後に残した言葉は、「今後お前たちが、一番小さな者に対してする事が、すなわち、わたしに対してする事だと思え」というものだった。小さい、弱い者をいたわり、助けるならば、それは自分を助けることと同じで、逆に虐げ苦しめるなら、それは自分を苦しめるのと同じことだ、と言い残したのだ。

一番小さな者。それはまさに、父ヨセフが、妻マリアの宿していた子どもに対して、した事ではないか。ヨセフは彼を自分の子として、育てたのだ。ヨセフは情けを知る者だった。それがフェアな扱いだと、思ったのだ。人はただ正しいだけでは、十分ではない。そこにやさしさを込めてこそ、はじめて地は平和になると、彼もヨセフも、賢く分かっていたからだ。


<関連エントリ>
 
(2014-12-23)




# by Tomoichi_Sato | 2021-12-24 18:36 | 考えるヒント | Comments(1)

お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27)

年明けに開催する2件のイベントのお知らせです。

一つ目は「プロジェクト&プログラム・アナリシス研究部会」で、小川明彦様にRedmineを応用した「チケット駆動開発の解説」のご講演をいただきます(1/11夜)。

二つ目は1年ぶりの、BOM/部品表に関する1日セミナー(1/27、オンライン・有償)のご案内です。


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

プロジェクトは、単位要素的な仕事の集積である、というのがモダンPM論の基本的認識です。その要素的な仕事を『アクティビティ』と呼ぶのが、PMBOK Guideのお約束です。ただしIT業界ではアクティビティの代わりに『タスク』という言葉を使う習慣も強いため、お互いに会話する際は注意が必要でしょう(ちなみにPMBOKでは、ずっと細かな日常的課題・To doを「デイリータスク」と呼んでいます)。

いずれの名前で呼ぶにしても、プロジェクトとは「やるべき仕事」の集合であり、それはさらに、事前に計画可能な(プロジェクト計画書に含まれる)種類のものと、遂行途上で生まれてくる計画できないものに分かれます。これらをうまく、相互に協調した形で進められるかどうかが、プロジェクトの成否を決めていきます。

Redmineはチケット管理をベースとした、プロジェクト・マネジメントのためのオープンソースのソフトエウェアです。プロジェクト・マネジメントを標榜するソフトウェアは多数ありますが、「やるべき仕事」をチケットという仕組みで可視化し、コントロールしていく点がユニークです。

今回は、redmine.tokyo のアクティブなメンバーで、関西をベースとした「NPO法人 IT勉強宴会」でも活躍されている、小川明彦様に「チケット駆動開発」についてご講演いただきます。

Redmine自体はIT開発プロジェクト向けツール、とのイメージが強いですが、単なるチケットによるタスク管理を超えて、製造業などにおけるプロセス改善にまで視野を広げたお話を聴ける機会です。年明け早々ではありますが、皆様ぜひご参加ください。


<記>

■日時:2022年1月11日(火) 18:30~20:30 (オンライン形式)

■講演タイトル:
チケット駆動開発の解説~タスク管理からプロセス改善へ

■概要:
チケット駆動開発とは、チケットと言う仮想カードでソフトウェア開発のタスク管理を俊敏に行う開発手法である。日本ではチケット駆動開発を実践する為に、オープンソースのチケット管理ツールRedmineが広く使われている。昨今、高機能化したチケット管理ツールがとても便利なので、製造業などIT業界以外のタスク管理に適用し、プロセス改善を通じてDXを支援する事例も増えている。
本講演では、チケット駆動開発が生まれた背景と意義、プロセス改善へ発展した経緯と留意点について述べる。

■講師:小川明彦
 所属:redmine.tokyoコミュニティ
 
■講師略歴:
2001年に大学院(数学専攻)を卒業後、IT業界の受託側・発注側のプロジェクトマネージャとして務系Webシステムの企画提案/設計/開発/保守を経験してきた。ソフトウェア開発のプロジェクト管理に苦労した経験からアジャイル開発に興味を持ち、オープンソースのチケット管理ツールRedmineを使ってチケット駆動開発と言う開発プロセスを独自に探求している。現在は、PMOの立場で社内のプロジェクト管理の標準化や品質管理に従事している。
技術士(情報工学)、情報処理技術者(データベーススペシャリスト)、認定スクラムマスター。

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

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



次は、BOM/部品表に関する1日集中セミナー(有償)のお知らせです。

製造業のDXという言葉が、世間を賑わせています。それが何を意味するかは諸説紛々ですが、製造現場のデジタル化や自動化(機械化)を除外して、本社や営業所だけで考えられるものでない事だけは、確かです。顧客からの受発注や仕様・要望、そしてクレームなどを、どのようにスムーズに製造現場に伝えられるかが問われていますし、また逆に現場の進捗や納期・コスト見積情報を、いかに素早く顧客に返せるかも大事です。そしてサプライヤーへの発注手配も、品質・コスト・納期(QCD)と不可分の関係にあります。

これら情報をつなぐインテグレーションの中核となるのが、基準情報としての『BOM/部品表』のデータであることは、言うまでもありません。とくに最近は、「トレーサビリティ」(=追跡可能性)が、多くの製造業の分野で求められるようになりました。これもまたBOMデータと切っても切れない関係にあります。

製造業ならば、どの企業もBOMを持っています(そうでなければ材料が購入できないはずです)。しかし、BOMデータのマネジメント悩む会社は、少なくありません。BOMには、受注・製品設計・工程設計・購買・生産管理・製造・品管・物流・保全・サービス・会計と、数多くの部門が、いろいろなフェーズとタイミングで関わるからです。

相互につながっていない複数のシステムを抱え、その間のつなぎを、人間が手作業で行っているのが、多くの企業の現実です。しかしますます加速する多品種化と、頻繁な計画変更のため、「すり合わせ」能力も限界に近づいているのではないでしょうか。しかも日本のIT業界には、製造現場のITシステムに強い企業がとても少ない、という状況が困難に拍車をかけています。

では、どうすべきか。もちろん答えは、企業の生産方式やBOMの特性、そして現状システムのあり方に応じて、千差万別でしょう。しかし、共通の基本概念を理解し、BOM特有の各種テクニックを学んだ上で取り組まなければ、あまりにも非効率です。さらに近年では、BOP(Bill of Process=工程表)概念の普及や、先に述べたトレーサビリティ要求、そして製造実行システム(MES/MOM)の普及など、新しい進展もあります。

こうした事柄を理解しながら、自社のBOMデータのあるべき姿について、考えるきっかけにしていただければと願う次第です。BOM/部品表マネジメントに関心のある方のご来聴を、心よりお待ちしております。


<記>

(2) 「BOM/部品表の基礎と生産管理に効果的なBOM構築のポイント

日時: 2022年1月27日(木) 10:30〜17:30
主催: 日本テクノセンター

本セミナーでは、BOMの基本概念の再整理からはじめて、マテリアル・マスタの統一、BOMの応用テクニック、そしてBOM構築プロジェクトの進め方について、演習をとりまぜつつ、平易に解説します。特に、BOM構築の3つの難所について重点的に説明し、トレーサビリティに関わる課題などについても、詳しく述べます。一日セミナーですので、じっくりと学ぶには最適です。

なお講義はオンライン形式ですが、自分で考えて身につけていただくため、グループ演習形式も多少取り入れて進める予定です。もし可能であれば、マイクとカメラ付きの端末をご用意ください。

セミナー申込み: 下記をご参照ください(有償です)

以上、大勢の方のご参加をお待ちしております。


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

# by Tomoichi_Sato | 2021-12-19 18:31 | ビジネス | Comments(0)