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

プロジェクトの《心配》を捕捉する

リーダーはつらい。

そう思っている人がどれほど多いかは、正確には知らない。いやいや、リーダーであることは、素晴らしい、ぜひ、人の上に立つべきだ。リーダーシップを発揮して、人を動かそう——わたし達の社会は、そんなメッセージに満ちている。人間は生まれつき競争心を持っているし、この世は競争原理でドライブされている。だからみんな、リーダーを目指すべきだ、リーダーの地位は喜ばしい、という事になっている。

でも、はたして本当にそうか。

リーダーは心配の多い仕事である。一介のエンジニアから、リーダーのポジションに上がると、自分自身の技術のこと以外に、面倒見なくてはいけないことが増える。部下や後輩や外注先の仕事ぶり、彼らの能力や勤務状況、すぐに進歩し変転していく技術の通用力、そして顧客の要求や機嫌など・・。これらを見極めた上で、WBSを決めスケジュールの線表を引き、そして費用や納期の交渉までしなくてはならない。

顧客も納期も自分の部下の顔ぶれも、自分で選んだものではない。え？　見積提案書をつくったのは自分だろうって？　だが、どうみても無理筋な納期要求をしてきている顧客案件を、厳しい競争環境下で取ってきたのは営業だ。だが、彼らは注文書を受け取ったら、さっさといなくなる。外注先も、上司が過去の経緯で決めてしまった。自分がのぞみ通りに絵を描いたのは、テクニカルな部分を除くと、極めて小さい。

・・というような事例は、まあ珍しくない。だから、中間管理職に昇格したとたんメンタルをやられたとか、プロジェクト・リーダーをやらされそうになったから会社をかわった、といった話も耳にすることになる。

なお、わたしはここまで（前回の記事を含めて）あえて、「プロジェクト・リーダー」という言葉を使ってきた。わが国の、とくにIT業界では、この用語が一般的だからだ。本サイトの以前からの読者は、わたしが「プロジェクト・マネージャー」の呼称を一貫して使ってきたことを、ご存じかも知れない。PMBOK Guide(R)でも、そうなっている。マネージャーとリーダーは、本当は違う。マネジメントとリーダーシップも、相当に違う。

だが、英語では異なった意味になるマネージャー、リーダー、コントローラー、アドミニストレータの４つの語は、日本語ではみんな『管理者』と訳される。日本の方がそうした概念については大ざっぱであり、英語のような緻密な区分をしない。

ただ、面白いことに、プロジェクト・リーダーの上に「プロジェクト管理者」がいる組織図は、よく見かける（「プロジェクト責任者」の場合もある）。どう違うのか。どうやら職位が違うらしい。前者のリーダーは現場で汗をかく人だが、後者は部長クラスで、キックオフと中間レビューミーティングくらいしか、顔を出さない。どういう「責任」をとってくれるかも、今ひとつ定かではない。

「責任」という言葉は、じつは問題やトラブルと密接な関係がある。「あのプロジェクトは素晴らしい成功だったが、その責任は彼にある」、という言い方は誰もしない（もちろん英語でもない）。責任がある、責任を取る、といった場合、なんらかの望ましくないトラブルが生じたケースに限られる。だから、責任者というのは、プロジェクトの《心配事》を、前もってケアすべき立場にある。つまり、前回の記事に書いた「危険予知」である。

さて、ここでもう一つ、英語と日本語の言葉の違い、あるいは概念の違いについて、ふれなければならない。それがリスクriskという語である。

リスクとは、危険だろうか？

ふつう、危険の反対概念＝安全、だと考えられている。安全とは、危険がないこと、すなわちリスクがない状態だ、と。

ところが、国際標準の世界では、そうは考えない。安全の定義は、「受入不可能なリスクがないこと」（ISO/IEC Guide51）とされているのだ。つまり、安全な状態とは、受入可能なリスクが、いろいろと残っている状態のことを指すである。何だそれ？

じつは、日本語の「危険」に相当する英語は、ハザードHazard、ペリルPerril、リスクRisk、デンジャーDangerと、４つある。彼らは、これを使い分けている。

たとえば、救命具なしにボートを漕ぎ出すのはリスキーRiskyだが、嵐の海にボートを漕ぎ出したらデンジャラスDangerousだ、という。リスクはまだ可能性の段階だが、デンジャーはほぼ確実に危険である。

ちなみに、ハザードは危険源という訳語を、JISでは採用している。たとえば高圧電流の通電が、ハザード（危険源）だ。普通、それは防護や絶縁をする。しかし絶縁不良で漏電、となるとペリルに「昇格」する。そこに人が近づいたり可燃物があったりする可能性があると、さらにリスクになる。そして・・

繰り返すが、リスクは可能性の状態にある。そしてリスクには、大小がある。これを洗い出して、対策を考えるのが、リスク・アセスメントである。対策とは、必ずしもリスクを除去することではない。リスクが「受入可能」な状態にすることも、リスク対策である。

別な言い方をすると、絶対安全はない、という見方を、ISOなどを決めた人びと（ほぼ欧米人）は取っているのだ。安全か危険か、白か黒か、という風に世の中を見ない。現実世界には、大小様々なリスクがあって、自分にとって許容可能な範囲はどこかを考え、その領域を広げる努力をしよう、とするのである。これを、Risk-based Approachという。日本語の訳は、まだない。

リスク・アセスメントで使う主要な道具が、Risk Breakdown Structure(RBS)であり、その結果をリスク登録簿に書き込む。

Risk Breakdown Structureとは、プロジェクトのリスクが生じるエリア（源泉）を階層的にブレークダウンした図で、WBSの階層表現図に、ちょっと似ている。最上位にプロジェクト全体のリスクがあり、それを、たとえば外部リスク・技術リスク・組織リスク・マネジメントリスクなどに分解し、さらに外部リスクは市場環境・天候気象・公衆衛生などに分解してある。そして、その単位で考え得るリスク項目を洗い出すのである。まあ、リスクの源泉つまり危険源（ハザード）の分解なので、本当はHBSとよぶべきだろう。

洗い出したリスクは、リスク登録簿（Risk Registry）に記録する。リスク登録簿は、シンプルな表である。整理番号、リスク項目（説明）があり、さらに、発生確率、影響度、リスク点数（スコア）、優先度の欄が並ぶ。そして、その右側にはリスク対応戦略（分類）、そして具体的な対応策と、そのリスクをケアする責任者の欄がある。実務ではもう少し欄を追加することもあるが、これが最大公約数だろう。

リスク・アセスメントは、プロジェクトのリーダーが一人で作ることも可能だが、できればキーパーソンを入れて複数人で行うのが望ましい。一人だとどうしても、見方が限られる。ことなる視点から、「あれもありうる」「これもあるんじゃない」とやりとりする方が、ベターだ。そして、リスク登録簿を完成させる。

このリスク洗い出しと対策議論のプロセスによって、参加者の脳内でさまざまなシミュレーションが行われ、その一部は言語化されていく。じつは、ここが非常に大切なのだ。というのも、「幽霊見たり枯れ尾花」という諺があるとおり、人を一番消耗させるのは、見えない物事への心配・不安なのである。

リスク登録簿とは、そうした心配事を捕捉した、いわばプロジェクトの心配事リストである。それが言語化され、具体的に見えてくれば、個々のリスク事象の発生確率や影響度自体は変わらなくても、自分の側の検知能力や対応能力が上がるのだ。

だから、できあがったリスク登録簿は、プロジェクト・メンバー、および上位管理職（つまり「プロジェクト管理者」「責任者」）とに共有することが大事である。もちろん本当は、プロジェクト責任者こそ、このリスク・アセスメントのセッションに、一緒に参加すべきなのだ。

なお、あえてちょっとだけ、余計なことを書こう。それは、「リーダー」と「責任者」の関係についてだ。わたしは、多くのプロジェクト・リーダーの悩みは、実はその上司である管理者なり責任者レベルが果たすべきマネジメントの不足を、下のリーダー層で補おうとして生じているのではないか、と思っている。いいかえると、戦略レベルの不足を、戦術レベルで何とか挽回しようとしている。あるいは、将校の不在を、下士官が補おうと、無理しているから、悩みが深いのではないか。

わたしは「プロジェクト＆プログラム・アナリシス研究部会」をかれこれ、10年も続けてきたし、その中で「プロジェクト懇話会」も開いてきた。プロジェクトの運営に悩む人達の話も、それなりに聞いてきたが、多くの事例では、出発時点からムリがあって、さらに上司が支援を十分していない、と感じられた。それは契約条件だったり、顧客の性質だったり様々だ。ともあれ、会社組織がプロジェクトに必要な手当てをしないまま、現場リーダーに遂行を丸投げしている印象を、しばしば持つのである。

上司たる「責任者」のマネジメントがなぜ、ちゃんと機能しないのか。上司が多忙すぎるのか、他にトラブルを抱えて火消しに回っているのか、それともマネジメントという職務をちゃんと教育していないのか。理由は定かではない。ともあれ、「責任者」が責任を果たしていないように思えた。この人達が、プロジェクトの心配を事前に捕捉しておいてくれれば、現場のリーダーがあんなに消耗しなくてもよかったはずなのだ。

でも、どうやら、こうした組織構造は、一朝一夕には、なおらないかもしれない。だとしたら、現場を率いるリーダークラスが、せめて実務に役立つリスク・アセスメントの進め方を、身につけて欲しいと思っている。だから、（前回の繰り返しになるが）11月16日と23日の二日間コースで、プロジェクト・マネジメント研修を組むことにしたのである。

研修セミナー名称：

「プロジェクトマネジメント研修　～リスクマネジメント編～」

日時：11月16日・23日 各10:00～17:00

講師

　 八卷 直一氏（静岡大学工学部 名誉教授）

　 佐藤 知一氏（日揮(株) 博士(工学)/静岡大学 客員教授）

　 串田 悠彰氏（(株)未来生活研究所 博士(工学)）

参加申込み：

https://www.hamanako.jp/info/0146.html

なお、最後に、一つだけつけ加えたい。リスク・アセスメントで重要なのは、言うまでもなく、リスク対策の立案である。ところで、実際にやってみると分かるのだが、現在のPMBOK Guide(R)にあげられている、4種類のリスク対応戦略（回避・転嫁・軽減・受容）だけでは、なんだか十分ではないのだ。

そこでこのセミナーでは、リスク発生の構造にまで立ち戻って、必要な対応戦略をもっと充実させている。ただ、そのためには問題事象の原因分析まで、理解する必要がある。おまけにPMBOKの枠組みを超えてしまう。このため上記の研修では、PMP試験対策としてのPDUは発行していない。その点をご了承いただければ幸いである。

＜関連エントリ＞

　「危険予知：プロジェクト・リーダーに必須の能力として（11月16/23日・PMセミナーのお知らせ）」 (2021-10-10)

危険予知：プロジェクト・リーダーに必須の能力として（11月16/23日・PMセミナーのお知らせ）

KYという流行語が、かつてあった。「空気が読めない」とか「空気読めよ」の略で、調べてみると2007年の「新語・流行語大賞」にノミネートされている。

この言葉が流行る前は、じつはKYは労働安全分野の略語だった。『危険予知』の略である。「KY活動」などとも使う。KYが「空気読めない」の意味で流行してしまった後は、あえて「KYK」とよんだりもしているらしい。まあ、地味なおじさん用語では、ネットやJKの影響力に勝てないし。

本サイトの読者で、労働安全に関心のある人は、正直あまり多くないと思う。だから「KY活動」だって、初耳かもしれない。製造業や建設業の現場では、危険を伴う作業を行うので、事故やケガが起きがちだ。いわゆる労災である。そこで雇用者に、労働安全のための監督義務を課している。

労働安全の分野では、「度数率」というモノサシで、安全を測る。これは労働時間100万時間あたりの労働災害の発生件数で、人は年間2000時間近く働くから、ざっくり言って500人規模の事業所で、年間何回くらい災害が起きるかを示している。まあ1〜2程度の数値と思えば良い（全産業平均で1.8程度）。

そして、度数率を下げるために取組をする訳である。労働災害の原因は、本人や周囲の「不安全行動」（これくらい大丈夫だろう、と考えて行うリスキーな行動）であることが多い。そこで安全衛生活動として、4S活動（整理・整頓・清潔・清掃）などと並んで、「危険予知（KY）活動」を行うのである。

典型的なKY活動は、たとえばミーティングで、作業の状況を示すイラストや図面を見せたり、実際の動作をしてみせたりしながら、どこに危険があり得るかを話し合う。そして重点項目や指さし確認などの対策を皆に理解してもらうのである。これをやることによって、危険性（＝可能性）が皆の意識の中に、視覚的イメージとして植え付けられるので、それなりに災害防止の効果がある。

危険予知活動は、リスクアセスメント活動の一環であり、その現場レベルでの取組とも言える。じつは日本では2006年に、労働安全のためのリスクアセスメントが法律で導入された。法的な枠組みなので、経営者が主導し、管理職レベルの安全管理者を任命し、推進チームを組織して、職場におけるリスクを評価することになっている。

だが、こうした取組は、現場レベルできちんと実装され、皆の行動習慣に落とし込まれなければ、効果は上がらない。そしてまあ、ここのところが難しい。なぜなら現場とは、納期だの売上だの利益だのといった、別のモノサシでドライブされることが多いからだ。

そしてこれは、オフィスで行うプロジェクトでも同様なのである。PMBOK Guide(R)などを見ると、プロジェクトでは計画段階でリスクアセスメントを行うのが良い、と書いてある。またSIなどの受注型プロジェクトでは、見積提出段階で、一応のリスク評価がなされることとも多いだろう。会社としても、あまりリスキーな、赤字覚悟の仕事は受けたくないからだ。

だが、実際のプロジェクトの現場では、しばしば避けるべき問題が発生する。オフィスだからケガや事故は滅多にないだろうが、病気で倒れるとか、メンタルで休みがちになる人が出て、チームの戦力が落ちる。また疲れや不注意で、品質が低下する。結果として納期が遅れ、赤字に陥るなど、残念ながら珍しくない話だ。

もちろん、プロジェクトを率いる立場になったら、誰だってこうした出来事は避けたいと願う。そのためには、やはりプロジェクトの開始時点で、実際に働くキーパーソン達を巻き込みながら、より具体的なリスクアセスメント、すなわち一種の危険予知活動を行うのが望ましい。

ところが、プロジェクトにおけるリスク・マネジメントは、案外、ガイダンスとなる良い教科書や手本が少ない。その理由は、製造現場の労働安全などと違って、プロジェクトが非定型業務だからだ。毎回、顧客も作るモノも道具立ても違う。プロジェクトには、何らかのチャレンジ的な要素が、必ずある。すべてのチャレンジを、未経験だからリスクと認定して回避したら、プロジェクトが成立しない。

そもそも、深刻な問題はたいてい、二つ以上の原因が重なって起きる。たとえば「冒険的な行動」と「危険な環境」といった組合せだ。だが、トラブルが起きて原因分析をする際、どちらを根本原因とみるべきかについて、じつは判断基準のない組織が多い。こういう企業では、過去に起きたトラブル事例などのLessons Learned（教訓）が、なかなか次に活かしにくくなっている。

「熱気球の浮上、または原因分析のシステムズ・アプローチについて」(2016-06-15)より再掲

また、リスクの洗い出し方法も問題だ。「このプロジェクトで考え得るリスクを出してください」というと、『納期遅延のリスク』などと言う人が、よくいる。だが、納期遅延は結果事象でしかない。何かの理由があって納期が遅れるのであり、それを防ぎたかったら、結果ではなく原因にしたがって、リスクを洗い出す必要がある。たとえば「不慣れなツールによる生産性の低下」とか、「海外調達の機器の納期が不安定」とかいった風に。

しかも、海外調達の機器の納期が不安定だとして、それがプロジェクト全体の工期に影響を与えるかどうかは、それがスケジュール上のクリティカル・パスに乗っかっているかどうかにも依存する。つまり、リスクを評価するためには、プロジェクトの全体像を理解していなければならないのである。

おまけに、プロジェクト・リスク・アセスメントでは普通、リスクの優先度を、

　【発生確率】×【影響度】

で評価する。そう、教科書に書いてある。だが、プロジェクトは毎回個別で、発生確率は統計で得られないことも多い。それに、そもそも、無理な価格や納期で受注したプロジェクトの場合、それ自体がリスク源ではないか。あるいは任命されたプロジェクトのリーダーが頼りなかったら。いずれも確定した事実で、すでに確率＝100%である。じゃあリスクと見なさなくても良いのか？　等々。

こういう風に、実際に現場で適用しようとすると、悩んでしまう事があまりに多い。

そこで、プロジェクトを率いる立場になった人達を対象に、プロジェクト・スケジューリングとリスクアセスメントを柱とした、二日間のトレーニングコースを、下記の通り実施することにした。これは、わたしが関わっている「プロジェクト＆プログラム・アナリシス研究部会」のPM教育分科会で開発した、最新のカリキュラムでもある。

主催は浜松ソフト産業協会なので、セミナー開催地は従来、浜松だった。しかし、幸か不幸か、今年はzoomによるオンライン形式で行う。そこで、全国からご参加いただけることになった。有償で、かつ休日に開催するセミナーなので、個人参加には多少ハードルがあろうかと思うが、もし職場のOKが出るようなら、そしてプロジェクトのスケジュール計画やリスクアセスメントの能力を伸ばしたいと思われるなら、ぜひご参加いただきたい。

＜記＞

研修セミナー名称：

「プロジェクトマネジメント研修　～リスクマネジメント編～」

日時：11月16日・23日 各10:00～17:00

講師

　 八卷 直一氏（静岡大学工学部 名誉教授）

　 佐藤 知一氏（日揮(株) 博士(工学)/静岡大学 客員教授）

　 串田 悠彰氏（(株)未来生活研究所 博士(工学)）

参加申込み：

https://www.hamanako.jp/info/0146.html

＜関連エントリ＞

　→「リスクに対する新しいアプローチ」 (2010–09-01)

　→「熱気球の浮上、または原因分析のシステムズ・アプローチについて」 (2016-07-19)

現場のセンサーデータ取得から、製造マネジメントデジタル化までの、意外な道のり

最初にちょっと、お知らせです。

製造実行システム（MES）に関するオンライン・シンポジウムが、10月7日(木)午前9:00-12:30に、(財)エンジニアリング協会「次世代スマート工場のエンジニアリング研究会」の主催で開催されます。内外の有力ベンダー5社による最新の製品と事例紹介等に加えて、わたしも最初に基調講演「実務者の目線から見たMESの重要性」をお話しします。

参加申し込みは、10月4日(月)一杯までになります。製造とデジタル化・IT技術に関心を持つ皆様のご参加を、心からお待ちしております。

申込みサイトURL:

https://www.enaa.or.jp/seminar/52299

※※※

私の働くプラント・エンジニアリング業界では、中東の仕事が結構多い。ところでご承知の通り、中東イスラム諸国では、お酒はご法度であり、なかなかおおっぴらにアルコール飲料を手に入れることができない。

しかし、一日過酷に働いた後、夜に1杯ひっかけてリラックスしたくなるのは、人情だ。酒が手に入らないのなら、自分で作りたい、と思う人たちが出ても不思議は無い。中東ではぶどうジュースはいくらでも手に入るし、イーストだって探せばある。

だから宿舎でこっそり、ぶどうを醸造しようと瓶に詰める人が後を絶たない。もちろん売ったり飲んだりするのが許されないのだから、酒を密造するのも法律違反だ。でも飲みたい。それも、単なる醸造酒では満足できず、もっと強い酒が欲しいと、蒸留に手を出す人まで現れる。

醸造酒は、水とアルコールの混合物だ。アルコールの方が沸点が低いので、温めるとアルコールが先に蒸発する。その蒸気を取り出して冷やし、再度液体に戻すと、最初よりもアルコールの濃度が高まる。これが蒸留の原理である。

ポットに原料の醸造酒を入れて加熱し、出てきた蒸気の成分を調べると、アルコールの含有率は連続的に変化する。アルコールが先に蒸発して、ポットに最後に残るのは水分ばかりになるから、蒸気は次第に薄くなるわけだ。

実は、エンジニアたちが昼間、一生懸命建設しているプラント類も、同じ原理で動いている。石油や化学などのプラントでは、混合物の原料を分離するのに、連続蒸留装置が使われる。プラントの写真を見ると、背の高く太い円柱のようなものがいっぱい立っているが、あれが蒸留塔である。

連続蒸留なので、温めた原料が次々に投入され、沸点の差によって、軽い留分が上から、重い留分が下から連続的に取り出される。とは言え、外気温等の変動によって、出てくるプロダクトの組成は常に微妙に変化し続ける。

プロセス産業で働く人間は、それが当たり前のことだと思っている。流体は任意の比率で混合する。それに従って、品質特性も変化する。それも時系列的に、連続的に変化するのだ。モノはきちんと管理しないと、勝手に混ざり合ってしまう、と。

これは機械や電子部品などのように、固体の製品を作っている工場の人たちとは、ずいぶんと違う見方だろう。この分野の部品や製品は、一つ一つバラバラ(ディスクリート)な存在であり、それぞれが品質特性を持っている。一旦出来上がったモノの品質特性は、急に変わったりはしない。

つまりディスクリートな固体の世界では、個別のものが識別可能であり、必要ならばシリアルナンバーやロットナンバーを付番することができる。それら個物に属性がぶら下がっていて、その属性値は時間的に変動したりはしない（経年劣化等を除けば）。

他方、流体を扱うプロセスプラントの世界では、物には具体的な境界がない。そこで配管の中の流れ(ストリーム)に属性がぶら下がっており、しかもその属性値は時系列的に変化すると考える。

いってみれば、プロセスとディスクリートの世界では、物と属性に関する概念データモデルが、根底から異なるのだ。このような違いがある以上、例えば製造を司る製造管理システムを考えた場合にも、両者のデータ構造はおのずから相当異なるだろう、と言うことが理解出来よう。

もしもあなたが電子機器や機械を扱う分野のエンジニアなら、部品や製品などモノの属性を記録する履歴テーブルは、シリアルナンバーやロットナンバーを主キーとして、測定した性能値や重量、サイズ等の属性値が並ぶイメージを考えるに違いない。

ところがプロセスプラントのエンジニアは、配管のストリームナンバーごとに、時刻をキーとして、測定した温度・圧力・流量などの属性値が並ぶイメージを持つ。

プラントでは要所要所に、温度計・圧力計・流量計といったセンサー類が、多数配置されている。プラントはセンサーの塊だと言っても良い。これらセンサーは、制御系ネットワークを介して、中央制御室にあるDCSなどの制御システムにつながっている。DCSは1秒周期にこれら何千と言うセンサーの値を読み取って、必要な計算を行い、バルブやポンプモーターなどに指示を下していく。

制御型システムにとっては、センサーからの値は計算やチェックで使ってしまえば、後は用がない。だからふつう一日とかせいぜい1週間程度の履歴データを保持するだけで、捨てていってしまう。

でもプラントの製造オペレーションをマネジメントする立場にある人間にとっては、過去1ヵ月間なり、あるいは1年前なりといった履歴データを参照したい。

そこで、Historianと呼ばれるシステムが登場する。制御システムが現場センサーから得たすべての履歴情報を、長期間にわたって記録し、あるいは分析・計算・画面表示するソフトウェアだ。これは制御システムよりも上位にある、製造実行システムMESのレイヤーに位置づけられる。

プラントにおける運転改善や、故障予兆診断といった取り組みも、ほとんどはこのHistorianのデータをもとに行われる。つまりMESの領域の仕事なのである。

これは固体を扱うディスクリート型の分野とは、大いに違う点だろう。ディスクリート系工場では、半導体工場や、自動車の最終組立ラインのようにMESが入っている工場はまれである。何よりも現場にある機械類は、スタンドアローンで動いているものが大半であり、また手作業の介在も多い。

そこで設備稼働の時系列データを取るためには、何とかして機械制御のPLCに、通信インタフェースを追加するか、あるいはセンサー類を後から外付けで設置するしかない。しかしこうして取得したリアルタイムデータも、MES層（ISA-95のLevel-3）が存在しないために、まとめて受取る先がいない。

やむなく個別に無線通信などを経由して、エッジサーバーやクラウド上のIoTデータ蓄積プラットフォームにあげていくことになる。

もちろんそれはそれで、それなりに有用だろう。「現場にセンサーを設置して、データをクラウドに上げ、AIで分析するのが製造業DXだ」と信じておられる方も、少なからずいらっしゃるようだから、あえて批判するつもりはない。

しかし機械の稼働状況がわかったとして、その機械がどの顧客向けの何の物品を削っていたのか、その品質がどうだったのかが、紐付けられないと、本当の意味のQCDの改善には結びつかないのではないか。

それを結びつけるためには、個別の機械の動作が、どの製造オーダー(製造指図)の作業手順（SOP）に従って働いていたのかが、記録され、紐付いていないといけない。これもまた、MESの仕事なのだ。

たいていの工場では生産管理システムが動いており、製造指図書もそこからプリントアウトされている。ふつう製造指図書には複数の作業が、加工順序(工順)に従って並んでいる。

だが実際の着手日時や作業の順序は、現場側の裁量に任されたり、工程計画担当者が別途、Excelでガントチャートを引っ張って、現場に指図したりしている。だからどの機械が何月何日何時何分に、どのロットナンバーのものを削っていたのかは、現場に行って調べないと誰もわからない。

これが日本の製造オペレーションマネジメントの現状である。それでちゃんと製品ができて、客先に納められているんだから、それでいいじゃないか?　もちろんその通りである。

だが、気まぐれな顧客の需要変動、次々と降りかかってくる設計変更、納品後に見つかった品質問題のバックトレース・・こうした問題への対応を、工場スタッフの人間系の努力だけで回していくのは、そろそろ限界ではないだろうか。

わたし達の研究会で「次世代スマート工場」を考えた際に、ポイントとなったことの1つが、ディスクリート系におけるMESの必要性である。現場に設置できるセンサーとIoTの技術は、その重要なイネーブラーであろう。

ただしそれは、データ蓄積基盤につながって、AIで分析できるだけでは、まだ片道通行で不十分なのだ。指示系や品質系のMESデータとつながって、初めてQCDの予測に役に立つことになる。

もちろん、データの基本的構造が違うのだから、プロセス分野のMESにおけるHistorianをそのまま持ってきても、あまり役に立たない事は想像に難くない。あくまで生産方式の特性に従って、こうしたシステムを設計していかなければならない。

それでは、この分野で先陣を切って製品を開発してきたIT企業は、この問題に、どう取り組もうとしているのか。そうした観点からも、内外の複数のベンダーが集まった、このようなMSのシンポジウムは非常に貴重な機会だと期待している。

幸い、緊急事態宣言に伴う日本の「禁酒法時代」も、9月いっぱいで、一段落ついたようだ。製造マネジメントの仕事への過重な負荷を、人間系の頑張りだけで何とか支えてきた製造業の人たちが、少しでもワークライフバランスを取り戻し、できれば勝利の美酒で1日を終えられるように、この分野の進展を望む次第である。

＜関連エントリ＞

　
(2021-09-17)

時間を可視化するために(2) 完了よりも着手を見よう

前回の記事「時間を可視化するために」 (2021-09-20)では、ガントチャート上のイナズマ線や、組立中のワークの位置を動かしていくことによって、作業の進捗を「見える化」する工夫を紹介した。

しかし実際には、稼働や進捗率の可視化だけでは、本当の意味での納期問題の発生を、タイムリーに把握できないと述べた。多くの場合、納期遅れが発生する原因は、担当者の能率が悪くて作業が遅れるためではなく、手待ちが生じるためだからである。

そして、手待ちが生じると、プロジェクトの工期は単純な足し算にならない。

ここで、簡単なシミュレーションをやってみよう。図のように、前工程と後工程の2段階からなる仕事を考える。前工程は、並行する３つのアクティビティからなる（1a, 1b, 1cと名付けておく）。後工程は、1つのアクティビティからなる。各アクティビティの平均所要日数は、全部、同じだとしよう。

ただし、アクティビティが着手してから完了するまでの所要日数には、普通ばらつきがある。ここでは単純に、実際の所要日数はサイコロを転がして、出た目の数で決めることにする。2の目が出たら、2日かかるとする訳だ。サイコロの目は１から６まであるから、平均値＝(1+2+3+4+5+6)/6 = 3.5日になる。

どの工程も平均値は3.5日なのだから、全体での合計は、3.5 + 3.5 = 7日になるはずだ。そう思って、サイコロを転がし、シミュレーションを1000回、やってみた。

結果はどうなったか。意外にも、全体の合計日数の平均値は、7日ではなく、8.5日(！)になってしまった。最初の推定よりも、2割以上も延びた訳だ。もしも納期7日で約束していたら、相当に顧客に頭を下げなければならないだろう。

ちなみに、前半の工程の完了日の平均は、3.5日ではなく、5日だった。下の図が、その結果を集計したグラフである。

前工程が、単純に１つのアクティビティだけだったら、完了日の分布は、文字通り1日〜6日まで、均等でフラットなグラフになっていたはずだ。そして平均値は3.5日になる。だが、前工程は、3つの並列アクティビティからなっており、実際の完了日は、３つの中の最長の日数で決まってしまう。Activity 1aと1bが頑張って作業を1日でおわらせても、もし1cが６日かかったら、前工程の完了は、6日になるのだ。

そして、前工程全部が終わらないと、後工程は着手できない。1aと1bのアウトプットはできあがっているのに、1cが遅れたために、２は着手を待たなければならない。どこか1箇所が遅れると、他の作業の頑張りが、ムダになってしまう。

合流のあるアクティビティ・ネットワークの場合、全体の合計日数（の平均値）は、各アクティビティの平均値の合計にはならないことが、お分かりいただけたと思う。理由は、手待ちが発生するからである。

（数学的には、正規分布する複数の変数から、その最大値を取ったものの分布系は、正規分布ではなくβ分布になる。1950年代にPERT/CPMを考案した人達が、アクティビティの所要日数をベータ分布と仮定したのは、こんなところに根拠があったのだろう）

では、実際の仕事では、どんなケースが相当するか。たとえば設計の場合は、上流側から（あるいは客先から）入るべき情報が来ない。製造の場合、必要な部品や製作図がそろわない。こうした理由で、しばしば手待ちが発生する。

ところが、働いている人間はたいてい真面目で賢いから（少なくとも日本の場合は）、手待ちが発生しても、その間、なんらかの仕事を自分で作り出す。それは多少の念入りな準備作業かも知れないし、あるいは全然別の仕事を先食いすることかもしれないが、「ヒマであくびをしている状態」を避けるものだ。

そして、一番まずいのは、このような「仮の仕事」「先食い」なのである。なぜなら、手待ち問題の発生を分からなくしてしまうからだ。だから、単に進捗を見える化するだけでは、なかなか真の解決に至らない。

ちなみに、もともと「見える化」はトヨタ用語である。だが、トヨタの「見える化」は、主に異常検知のためにある。それがムダや、解決すべき問題の存在を明らかにするからだ。そして、異常を検知するためには、何が正常であるかの基準が必要になる。だから標準なくして改善なし、という格言もある訳だ。

トヨタでは、たとえばコンベヤを利用した組立ラインでは、作業者の「作業域」を決めている。そして、ワークが自分の作業域に来ないと、作業が着手できないようになっている。それまでは、「手待ち」状態である。手待ち発生というムダが明らかになるよう、「見える化」されるのである。

逆に作業が止まったとき（あるいは他を止めざるを得ないとき）には、「アンドン」を上げて、ライン全体に知らせる、というのもトヨタのやり方だ。昔、読んだ話だが、ある技術者が勉強のため、トヨタの工場のラインに入って、実際に自分で作業をしてみた。ところが、回りの技能員に比べて、自分はどうしても仕事が遅れてしまう。

彼はやむなく、昼休みを早く切り上げてラインに戻り、午後に作るべき分を、先に作ることにした。生産の足を引っ張り、回りに迷惑をかけないためだ。ところが、そうしていたところを、工場に紹介してくれた人に見つかり、かえって彼は叱られたという。「それは『作りすぎのムダ』です。それは決してやってはいけません」

じゃあ、どうしたらいいのですか、と問い直すと、返ってきた答えは、「アンドンを上げて、作業が間に合わないことを知らせてください」と言われたという。文章には書かれていなかったが、おそらくその場合、ラインの班長などが入って、応援するなり問題解決をするのだろう。

問題が発生したら、必ず支援と解決の手立てを講じてもらえる、という状況を作ることが、進捗問題の可視化の必要条件である。そうでなければ、誰が遅れなど報告するだろうか。「問題が起きたら、その作業をやっている奴が悪い」という無言の圧力がかかる組織文化では、問題はつねに抱え込まれて、可視化されなくなる。

話を戻すと、ふつう進捗のモニタリングや可視化を行う際には、アウトプットの登録/入庫や、作業の完了報告などを、把握することが多い。それはそれで必要だ。だが、じつは完了だけでなく、作業の着手の報告が大事なのである。より正確に言うと、仮作業や先食いを除いて、真に「作業が着手可能になった」ときの着手報告が必要なのだ。

そしてこれが、なかなか難しい。なぜなら、着手報告を上げるためには、「作業指示」が明示されている（その作業に識別可能なオーダーNo.が発行されている）必要があるからだ。トヨタ系の工場ならば、それこそ「かんばん」が一種の作業指示として機能するから、ある意味、これはやりやすい。

ところが、多くの現場では、作業指示はないか、あってもかなり粒度の粗い指示なので、日々の着手をコントロールし切れていない。そこで作業者がモノの在庫や施工図の到着などをベースに、自分で作業順序を決め、着手する。

まして、オフィスで行う設計業務のようなプロジェクト的仕事では、作業の指示（オーダー）という概念自体が乏しい。たとえば読者諸賢は、プロマネや上司から、何か作業を命じられたとき、「ワーク・オーダー」の紙切れをもらったことはあるだろうか？　プロジェクトIDと、オーダーNo.とが記載され、やるべき作業の簡潔な記述と、必要なアウトプットとインプットと、期限日が規定されている、紙切れだ。

おそらく、あるまい。いや、紙でなくて電子伝票でも良い。こういう仕組みを完備しているオフィスは、滅多に見たことがない。オフィスでの知的作業はすべて、融通無碍、あうんの呼吸で行われ、着手日も手待ち状態も記録されぬ、「暗闇行軍状態」がわたし達の日常である。

こうした環境では、手待ちの発生も不明だし、その結果、生産性も、ちゃんと測ることが難しくなる。生産性が分からなければ、リードタイムの推定も困難で、だから納期は予測不能、という事態に陥るのだ。

キャパシティ（能力）も生産性も、ふつうは単位時間あたりの数量で測る。そして、仕事を頼む側は、相手の負荷を知りたい。今、どれだけのタスクを抱えているのか。今、使っているその時間は、誰のための仕事に紐づいているのか。もちろん頼まれる側だって、期限の切迫度を知りたい。可視化するなら、こうした面まで、見えるようにするべきであろう。

そのためには、「オーダー」や「チケット」の仕組みが必要なのだ（チケットは、ヘルプデスク・サービスなどでよく使われる仕組みであり、オーダー＝指示の一形態である）。

そしてオーダーやチケットには当然ながら、着手と、正味所要時間と、完了の記録が必要になる。その入力を個人の負担にさせないためには、デジタル技術を駆使すべきであろう。バーコードでも、カメラでも、PC操作記録でも何でもいい。そのために最新の技術があるのだ。

わたしが、エンジニアやオフィスワーカーにむけて、To Do List（タスク・リスト）と日誌を使いこなそう、と訴え続けてきたのも、その一環である。タスク・リストこそ、ある意味、自分に対するワークオーダーの明確化だからだ。

わたし達にとって、一番貴重で稀少なもの、それは時間である。誰でも、人生は一度だけで、限りがあるからだ。だからこそ、時間の使い方のマネジメント＝時間管理が大事なのである。だが、その目的は、決して時間に吝嗇になることではない。このサイトでは何度も書いたが、時間管理術の一番の目的は、「考える時間」を生み出すためにあるのだ。

なお、時間管理術については、最近、沢井製薬「サイエンスシフト」というサイトに、3回にわたって入門的な文章を書かせていただく機会があった。拙著『時間管理術』（日経文庫）の前半のエッセンス部分を書いたものである。もしご興味があれば、こちらもぜひご覧いただきたい。

時間管理術(1)　時間をあなたの味方にするために

https://scienceshift.jp/timemanagement-01/

時間管理術(2) タスク・リストの使い方

https://scienceshift.jp/timemanagement-02/

時間管理術(3) ミーティングを時間どろぼうにしないために

https://scienceshift.jp/timemanagement-03/

＜関連エントリ＞

　 (2021-09-20)

時間を可視化するために

ガントチャートの「イナズマ線」については、ご存じの方も多いと思う。スケジュール計画を立て、工程表をガントチャートの形で図にしたら、あとは一定期間ごとに、そこに各作業の進捗状況を書き込むのである。

下図は4つのアクティビティからなる簡単なプロジェクトの例だ。企画調査とコンセプト検討は、第4週から始めて6週で終わり、予算確認とレポート作成は7週からはじめて9週の初めに完了する計画だった。ところで、現在は第7週の初めだが、コンセプト検討がまだ終わっていない。事情で着手が1週遅れたからだった。一方、予算確認は1週先行して、すでに完了している。

言葉にするとこんなゴチャゴチャした記述になるが、イナズマ線で描けば明快だ。イナズマ線は、各アクティビティの進捗率にしたがって、50%進捗ならば、作業を表すバーの真ん中に点を、67%ならば作業バーの2/3の場所に点を打ち、それらの点を、縦に線でつなげるのである。このとき、すでに完了したアクティビティについては、100%の点ではなく、現在日付のところに点を打つ。

こうすると縦にジグザグの、稻妻に似た線ができるので、イナズマ線という（英語では単純にProgress lineとよぶことが多い）。イナズマ線が、現在日付（Time now）よりも左に凹んでいるアクティビティは、遅れを意味し、右に出っ張っている部分は、予定よりも先に進んでいることを示している。こうすると問題発生部分が目に見えやすくなるので、定期的なプロジェクトの進捗ミーティングなどで、問題解決に向けた話し合いができる。

作業の進捗というのは、はたの目に見えにくいものだ。だが進捗が遅れると、納期に影響する。だからガントチャートのイナズマ線は、時間を可視化する工夫だと言える。いや、むしろイナズマ線を引かないガントチャートなど、実際の役にはほとんど立たないと言ってもいい。もちろんイナズマ線を「読む」ことのできないプロジェクト・マネージャーは、プロマネの名に値しない。

もともとモノや人は目に見え、五感で知ることがたやすい。他方、時間は目に見えない。でも時間的な制約や納期をもつ仕事は多い。だから、動きや働き、過程や進捗などを、なんらかの位置に変換して、時間を可視化するための工夫が必要になるのである。

ところで、この『進捗の可視化』を、工場における組立工程にうまく応用している例を、見たことがある。数年前、日立製作所の大みか工場を、ご厚意で見学させていただいた。この工場は、電力制御システムなどを製造しており、金属製のキャビネットの中に、電子回路や電源装置、そしてケーブルなどを組み付けていく。細かな部品が多い上に、毎回個別に受注して設計するタイプの製品なので、納期管理も難しい。

ちなみに以前、本サイトでは生産方式を「フローライン型」「フローショップ型」「ジョブショップ型」「セル型」の4種類に分類した。だが、実は第5の種類として、

　「ドック型」

というのがある。これは、製造対象のワークが工場の中を移動するのではなく、同じ位置にずっと置かれたまま、加工作業や組立作業を行うタイプである。造船業のドックなどが、その典型で、船はドックの中で次第に完成形になっていく。航空機などもそうだ。

大みか工場のような、比較的大きく重量もある制御盤などの工場でも、ふつうは組立エリアにキャビネットの箱を据え付けて、その中に部品を組み付けていく。つまり「ドック型」生産方式なのである。しかし、なにせ箱の内部に組み付けていくのだから、外から見ても作業の進捗度が見えにくい。

ところが、この工場では、キャビネットを固定位置に据え付けてはいなかった。キャビネットを移動可能なキャスター台の上に置いて、そこで組み立てていく。そして、組立作業の進み具合に応じて、キャスター台の位置を、組立エリアの出口（出荷口）に少しずつ、移動させていくのである。そのためにキャスターにはたしか、移動用のガイドワイヤーがつなげられていたと記憶する。

こうすると、組立エリアの中のどの位置にあるかを見ると、その組立の進捗度がすぐに分かる。ちょうど、ガントチャートのイナズマ線をひく位置のようなものだ。わたしが見たのは少し前で、今もやられているかどうかは不明だが、とても巧みな、面白い工夫だと思った。さすがは日本企業で唯一、世界経済フォーラムWEFの選定するスマート工場（”Lighthouse”）に認定されるだけのことはある。

もっともこのやり方は、組立エリアにそれなりに広い面積を必要とするので、どこの工場でもすぐに真似できる方法ではない。それに本物の船だったら、それこそドックの中を移動する訳にもいかないので、対象が限られているのも事実だ。だが、面白い工夫であることにかわりはない。

わたしは、自分のエンジニアリングの業務にこれを応用したらどうなるかと、夢想してみた。工場づくりのエンジニアリングの仕事は、3D-CADを使って設計するのが基本である。そして、この3D-CADの進捗状況が分かりにくい。社内では3D modelの完成度について、標準的なメジャーメントの取り決めがある。だが、それでも分かりにくいのである。それは3D-CADがコンピュータの「サイバー空間」にあって、目に見えにくいからだ。

そこで、3D-CADのデータが集約される部門の担当者、つまりプラント系なら配管設計、建屋系なら建築設計の担当者が、少しずつ、席を移動していくのはどうだろうか。

「うーん、中村君は出口に近い、あの位置か。北米向けの案件は順調に進んでいるようだな」

「おや、伊藤君は先月からずっと、あの席のままじゃないか。中東向けの案件は設計で問題が生じているらしい」

と、すごく話が分かりやすくなるのではないか・・

だが、わたしはこの「妙案」を、会社に提出することはしなかった。まず、そんな風に人がまばらに座るような、贅沢なオフィススペースの使い方は、とてもできない。だがそれ以前に、3D-CADの完成の遅れは、その担当者自体の問題と言うよりも、その担当者（設計データを集約してCADにインプットする役割）に対する、上流側各部門の遅れが影響しているはずだからだ。

下流側の結果で問題を検知しても遅すぎる。その上流側も遅れを「見える化」しなければ、素早い打ち手はとれない。だが、上流側設計部門の全てのオフィスを、同じように「位置ずらし方式」レイアウトにするなど、経営から見たら論外であろう。

んじゃあ、人が物理的に場所をずらす代わりに、デジタル画面に進捗を表示したらどうなの？　そう。もちろん、それくらいは取り組んでいるのだ。設計業務の進捗をEVMS的に定量化し、くどいくらいの頻度で測り、レポーティングする仕組みは、社内にできあがっている。グラフにもなっている。だが、それでもプロジェクトに遅れが発生するのは、なぜなのか？

それは、稼働や進捗率の可視化だけでは、ある問題をタイムリーに把握できないからだ。それは、手待ちの発生である。

（この項つづく）

＜関連エントリ＞

　(2021-05-15)