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

書評:「哲学入門」 戸田山和久

哲学入門」 (Amazon)
哲学入門」 (honto)

今年の前半で読んだ本の中で、一番面白かった1冊。何よりも、文体がいい。

「『哲学入門』って本を書いてて忙しいんだよ、といったら、妻は『あんたいつの間にそんな偉そうな本を書く身分になったのよ』と答えた。じつにその通り。確かに偉そうだ。どうせ偉そうなんだから、ついでに言ってしまう。本書は、哲学の中核にみなさんをいきなり誘い込むことを目論んでいる。わっ、言ってしまった」

これが冒頭の一文である。このスピード感で、新書版とはいえそれなりのボリュームを疾走していく。なかなか楽しい。

著者の言う哲学の中核の問題とは、「ありそでなさそで、やっぱりあるもの」だという。それは、「意味」「機能」「情報」「表象」「目的」「自由」「道徳」、そして「人生の意味」——などだ。これが、各章の表題になっている。

いずれも、わたし達が日常よく使う言葉で、その意味だって、よく分かっているつもりである。だが、じゃあ「意味」ってどういう意味なんだ、と問われると、立ち止まって、説明にぐっと詰まったりする。かといって、「意味」という言葉や概念をうち捨てて、それで日常生活や知的作業が成り立つかというと、たしかにそうもいかない。

著者はこれらの概念の意味を、しかも、神だとか世界精神だとかいった、高邁な天下り的概念を用いず、純粋に唯物論的に、かつ発生的(進化論的)に、そして生物学や脳科学などの最新科学の成果を援用しながら、解き明かそうという。その意気や良し、ではないか(元々、著者の戸田山和久氏は科学哲学の研究者である)。

そして本書には、いわゆる有名な西洋哲学史の有名人たち、プラトンもデカルトもヘーゲルもニーチェもウィトゲンシュタインも、ほぼ一切、出てこない(これも著者が序で宣言している)。代わりに、デネット、ミリカン、ドレツキといった、現代哲学の最前線で活躍している研究者たち(読むまで誰一人知らなかった)の仕事が紹介され、また精緻に批判されている。いいねえ。

もっとも、一箇所だけ、カントの名前が傍証風に出てくる。「有名な『純粋理性批判』は、感覚を入力するとニュートン力学を出力するシステム(主観)を想定して、(中略)どんな構造(アーキテクチャ)をしているはずかを考えた本だ。」(P.271)。つまり、機能から構造へさかのぼる逆問題をカントは解いたのだ、という。これは秀逸な指摘だ。この一文を読んだので、もうカントの本自体は読まなくても良いかな、って気分にさせてくれる(笑)。

ついでにいうと、末尾のあとがきで著者は、「哲学とは概念工学である」と規定する。これも出色の概念規定だと思う。分かりやすく、使い勝手の良い、世の役に立つような、新しい概念をデザインすること。これが哲学の役割、機能である。つまり(わたし流にリフレーズすると)、哲学とは概念を用いた世界のシステム・モデリングなのだ。

モデリングなので、そこには客観性・正確性の他に、美的なバランス感が必要になる。サイエンスとアートの両面が必要になる。ここも、面白い。

なお「概念工学」は、20世紀英米哲学の主流だった分析哲学の方法論である「概念分析」とは、少し違う。その点も第2章「機能」で、結構詳しく論じている。まあ、要求分析でAs-Isをいくら分析したって、To-Beの良いデザインは自動的には出てこない、って感じかな(少し違うかも知れんが・・)。

そもそも哲学は、言葉を用いた世界のモデリングなので、ある意味、言葉にこだわっているし、言葉にしばられてもいる。だから本書の第1章は、「意味」から始まるのだろう。意味を理解するとは何なのか。

しかも、意味を(神とかイデアなどの超越的エージェントを持ち出さずに)唯物論的に、説明しなければいけないのだ。「アンドロメダ星雲」という画面上の文字の並びと、230万光年離れた星雲との間に、何か物理的な相互作用がある訳でもない。それだと「言葉がモノを意味するのに230万年もかかってしまう」(P.15)。

そこで本書は、チューリング・テストと、「中国語の部屋」の検討から始まる。「中国語の部屋」は哲学者ジョン・サールが1980年に提案した思考実験である。

部屋の中に、英語しか分からぬ人がいる。彼は中国語は分からないが、漢字の形は識別できる。そして、部屋の中には英語で書かれた分厚く完璧なマニュアルがあって、「こういう漢字のインプットがあったら、こう漢字のアウトプットを出せ」との指示が並んでいる。さて、彼は中国語を理解していると、言えるのかどうか?

(この問題は、AI研究の自然言語処理でも有名だ。実際、最近Microsoftが巨額投資をして話題のGTP-3 など、まさに、適当な質問文をインプットすると、いかにも自然で良くできた一連の文章をアウトプットしてくれる。Microsoftはこれを、ローコード開発の推進のために使うという。ユーザが要件を言葉で入れると、Power Appsのソースコードを吐き出してくれる。じゃあ、GTP-3はユーザの自然言語やプログラミング言語を「理解」しているのか?)

著者はサールの議論を再検討して、言語の処理が、そのシステムの問題を解決し、生存を助ける場合に限って、意味理解と言える、と考える。「意味という概念が、目的といった概念と密接な関係を持つ」(P.64)と論じる訳だ。さらに認知科学の検証を経て、生物哲学者ルース・ミリカンの「目的論的意味論」(2007年)を紹介する。ここで、進化や機能の概念と結びついてくるのだ。だから、次の第2章は必然的に、じゃ「機能」って何だ、ということになっていく。

そして第3章は「情報」である。意味→機能→情報、ときたら、まるきりITエンジニアの世界だなあ。この章では、今や古典的な、シャノンの情報理論(1948年)の定義からはじまる。そして認識哲学者フレッド・ドレツキの、条件付き確率を用いた情報内容の定義:
「信号rが、対象sは状態Fであると伝える ⇐⇒ rという条件のもとでの『sがFである条件付き確率』が1である」
を紹介する。

(ちなみにわたしはここで、途中で失われた情報量=「エキヴォケーション」の概念を、はじめて知った。例によってエントロピーと同様、対数で定義する)

哲学という学問には原則として、実験による検証がない。以前、友人の心理学者・北村英哉氏にP&PA研究部会で講演してもらったとき、「心理学は哲学と違って、ちゃんと実験で検証する」という意味のことを強調しておられた。(「実験哲学」という流派もあるが、内容はアンケート哲学である)

ただ、そのかわり(?)哲学の検証では、奇想天外な設定による「思考実験」がたびたび、登場する。先ほどの「中国語の部屋」もその一つだし、デイヴィッドソン(1987)が提案した「スワンプマン」なんてのもそうだ。あやしげな沼のほとりを訪れたら、なんたる不思議か、落雷が沼のガスに作用して、その人の分子レベルのレプリカが生まれてしまった・・これがスワンプマンである。

スワンプマンには過去の歴史がない。経験もない。進化の経緯もない。ただ、物理的条件は本物と全く同じだ。じゃあ、スワンプマンは全く同じ心理状態にあるのか。同じ意味を共有できるのか。

ドレツキは、「解釈者」を情報の定義から除外することで、この問題を解決しようとする。そして因果的世界を「情報の流れ」として解釈してみせる。ただ、快適なテンポで進んできた本書は、第4章「表象」のあたりで、少しダレてくる。というか、どうも哲学の表象概念が、わたしの目からは、あまりに西洋的偏りに満ちていて、問題設定に疑問が残る、というべきかもしれぬ。

しかし、科学哲学者ダニエル・デネットが登場して、生物を「ダーウィン型」「スキナー型」「ポパー型」とカテゴリー分類してみせるあたりから、また面白くなる。ダーウィン型は遺伝子で適応度(生存する能力)が決まってしまう。スキナー型(スキナーは米国の行動科学者)は、試行錯誤と学習ができる。つまりAIでいう強化学習の能力があるのだ。

そしてポパー型(ポパーは反証可能性を科学進歩の根幹とした哲学者)は、頭の中で事前にシミュレーションをする能力を持つ。ここから目的手段推論を経て、「自由」は存在するのか、そして「道徳」とは、という問題に移っていく。

著者の後半の議論はいささか、デネットの進化論的な見方に頼りすぎている感じが無くはない(著者自身もそう思ったのか、一応批判もしているが)。だが唯物論・自然主義の立場から、なんとかして最後の「人生の意味」論まで、たどり着こうとする思考の射程距離の長さは、敬服に値しよう。また、巻末の読書案内も、とても充実している。

くりかえし書いていることだが、現代のITというのは西洋哲学の非嫡子である。そしてITエンジニアは、いや、エンジニア一般も、哲学を、多少自分流でも良いから、学ぶべきだと思っている。哲学は、真理に至る方法論を研究する学問で、モデリングの道具として言語を使う。だが、哲学から派生した諸概念は、わたしたちの社会制度と世界観を、非常に強く規定している。

わたし達が世界を理解したいとしたら、そして世界をより良くしたいと少しでも思うなら、道具としての哲学を知っておくべきなのである。


<関連エントリ>


# by Tomoichi_Sato | 2021-08-14 20:36 | 書評 | Comments(0)

お知らせ:次世代スマート工場関連の講演を3つ行います(8/26, 9/16, および8/18)

本サイトでも何度か書いていますが、(財)エンジニアリング協会の傘下で、3年前から『次世代スマート工場のエンジニアリング』研究会を組織し、幹事を務めて活動を続けてきています。現在、1省庁・2団体・3大学・20数社から50名ほどの参加会員を得て(オブザーバー参加含む)、「事例調査」「技術開発」「人材教育」の3分科会体制で進めています。

また、わたしの勤務先は、この4月から「ネクストファクトリー・ソリューション部」という新部門を立ち上げました。これまではエンジニアリング会社と言っても、石油・化学プラントや医薬品工場など、プラント系の色彩が強い印象だったと思います。しかし、もう少し一般的な意味での工場(ディスクリート系)にも、幅広く取り組むことをアピールしていきます。わたし自身、こちらの部門にもアドバイザーとして参画しています。

こうした活動が交錯し共鳴関係を生んだのかも知れませんが、この夏から秋にかけて、スマート工場づくりと、MESをはじめとする製造情報システムに関する講演をいくつか行うことになりました。まずは、今月・来月に予定している3件について、お知らせします。いずれもオンライン形式で、原則無償です。


1. 人材育成セミナー:「スマートファクトリー実現のための必要な知識を学ぶ」(8月26日 9:00〜12:30)

上記「次世代スマート工場のエンジニアリング研究会」の人材教育分科会は、スマート工場実現に必要な教育カリキュラムを開発し、多くの製造業の皆様に貢献したいと考えております。今回は、そのためのトライアル講義という位置づけで、そのため無償で提供することになりました。

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

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

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

日時:2021年8月26日(木) 9:00〜12:30
 (昼休みにかかる時間帯で申し訳ありません)
 事前登録制、参加無料。

講演者と内容:(敬称略)
1.挨拶 ・・・ 研究会主査 松川 弘明 (慶応大学 理工学部 管理工学科 教授)
2.スマート工場入門「はじめの一歩」 ・・・ 講師:渡辺 薫(ゴールシステム・コンサルティング)
3.スマートファクトリー実現のためのアーキテクチャを学ぶ ・・・ 講師:佐藤 知一(日揮ホールディングス)
4.スマート工場 取組み事例紹介 ・・・ 講師:岡野 美樹(日本電気)

ウェビナー紹介サイト


2. 【スマート工場の実現に向けたDELMIA活用Webinar】(9月16日 13:30~17:00)

昨年に引き続き、製造業向け情報システムの分野をリードしている(株)エスツーアイさんが主催し、世界有数のMESベンダーでもあるダッソー・システムズさんが協賛されるセミナーで講演を行います。エスツーアイさんは地元・愛知県で長年、製造業に向けて、製品設計・BOM/PLM・MESなどのソリューションを実装してこられた、有力SI企業です。

そこで、ITソリューションの詳細については、エスツーアイさんとダッソー・システムズさんにお任せし、わたし自身は、「スマート工場実現のための三つの変革」と題し、 自動化、グリーン化、そして情報の統合化という課題について、お話しします。

日本の製造現場が直面する上記三つの変革は、いずれも重要かつ喫緊のものですが、経営層と現場の距離感のために、上位から明確な方針が下りてこない例も見聞きします。技術論とマネジメント戦略論のスキマに落ちてしまいそうなこの三つの課題、どう取り組んだら良いか、ぜひ一緒に考えてみたいと思います。

日時:2021年9月16日(木) 13:30~17:00
 事前登録制、参加無料。

講演者と内容:(敬称略)
1.オープニング
2.スマート工場実現のための三つの変革 ~ 自動化、グリーン化、そして情報の統合化 ・・・ 講師:日揮ホールディングス 佐藤 知一
3.DELMIA Aprisoによる製造プラットフォーム構築~海外事例編~ ・・・ 講師:ダッソー・システムズ DELMIA事業部  阿部 洋平
4.工場DX推進に求められるMOM基盤と原価管理 ・・・ 講師:エスツーアイ ソリューション推進センター 村瀬 太一

ウェビナー紹介サイト


3. 【スマート工場への変革ロードマップを描く ~ 製造業向けコンサルティングの新しい視点】(8月18日 19:00~20:30)

こちらは、中小企業診断士を中心とした研究会組織である「生産革新フォーラム」(略称:MIF研)の定例会講演です。わたしは20年以上もこの研究会のメンバーとして活動してきていますが、いつも新しい学びがあり、面白い場だと感じています。例年は必ず2回、工場見学会を行うのですが、あいにく昨年も今年もひらけずにいるのは残念です(会員が主催した「バーチャル工場見学」は行いましたが)。

このMIF研は、コンサルタントを中心とした組織ですので(わたしのような企業人も会員にいますが)、そちらの視点からスマート工場へのロードマップを考えてみるつもりです。実際に最近の会の活動を見ると、製造現場におけるデータ活用やデジタル技術においては、大手中堅企業の工場も、中小企業に負けず劣らず(?)困っている実態が見えてきています。「日本の製造現場は世界一」という神話は、だれがふりまいているのでしょうね。

ということで、オンライン開催ではありますが、クローズドな場でもあり、本音に近いカジュアルなお話しもできると思います。なお、この会は東京都中央企業診断士協会・中央支部の下にありますが、診断士でない方も一応、会の主旨にご賛同いただければ参加できます。年会費5,000円です。

日時:2021年8月18日(水) 19:00~20:30(Q&Aと討議を含めると〜21:00ごろの可能性あり)

講演者と内容:
1.スマート工場への変革ロードマップを描く ~ 製造業向けコンサルティングの新しい視点 ・・・ 講師:日揮ホールディングス 佐藤 知一

研究会紹介サイト


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


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


# by Tomoichi_Sato | 2021-08-07 11:32 | 工場計画論 | Comments(0)

優先番号法(ディスパッチング・ルール)とは何か

日本企業は、ボトムアップ型で、現場に大きな権限を与えている、という言い方をよく聞く。「現場力」という言葉も使われるし、企業の強さは現場カイゼンから生まれるとか、三現主義(現場・現物・現実)を大切に守っているから、といった解説も多い。

もっとも、こうした言い方をそのまま受け取るには、少しばかり留保が必要ではないかと、わたし自身は感じている。日本の製造現場に真面目で優秀な人が多いのは、もちろん事実だ。そういう人達は自主性を持って働き、自分自身で問題解決する能力もある程度、持っている。だから、労働者をロボット並みに扱う、米国流のトップダウン型とは、異なるマネジメント・スタイルになるというのも、もっともな話である。

だが、逆に言うと、現場の優秀さや自主性に頼って、いろいろな点で「現場依存・現場丸投げ」になっている面もある、と感じることも少なくない。それはたとえば、次のようなことである:

(1) 製作図面や製造仕様書の完成度の低さ(2D-CADに手書きの修正でも現場は受け取ってくれる)、
(2) 標準作業手順書SOP=Standard Operation Procedureの不在(改善が日常的に行われるという理由で、作られない)
(3) 生産スケジュールの変更が多く、生産管理システムの予定とは別に、現場側で着手順を決めている

こうした習慣は、生産のフレキシビリティを上げている面も、たしかにある。だが実は、製品設計や生産技術や生産管理の仕事が、十分に標準化・デジタル化されずに、現場の人間系に依存している事をも、示している。だから製造業のいわゆる「DX」が、ちっとも進まない遠因にもなっている。

そして、日本のマザー工場を海外に展開しようとした際には、現場側の能力を期待できないため、こうした習慣すべてが、かえって足かせとなるのだ。

いや、それどころか、今や日本国内だって絶望的に人手不足である。工場で働きたい人を見つけるのは、至難の業になってきている。そんな時代に、工場の人達が、言われたとおりに無言でよく働き、優秀であることを期待して、業務を回すのはずいぶん危ないことである。

じゃあ、欧米流のトップダウンで、管理者がすべてを決めて、労働者に指示命令を下すべきだというのか? 働く側はロボットのように、ただ言われたことだけをやれ、と?

——という反論も聞こえそうだから、念のために書いておく。わたしは、前回の記事にも書いたとおり、全てをスケジューリングする必要はない、という考えである。

どうもこの種の議論をすると、トップダウンかボトムアップか、白か黒か、みたいな論調になりがちだ。だが、現場で働く人の「シビルミニマム」やモチベーションのありかをどうするか、という事と、標準や指示を作って下ろすかどうかは、別問題であろう。

オーケストラや合唱団は、指揮者のタクトにあわせて楽譜通りに演奏すると、自主性やモチベーションを失うのだろうか? 俳優は、演出家の指示に従って、台本通りのセリフをしゃべると、ロボット並みになるのだろうか? 逆に、脚本家は集団のモブシーンで、一人ひとりの動きを全部いちいち書いておくべきなのか? 常識で考えれば、どれも答えはNOであろう。

スケジューリングの話題に戻そう。前回の記事で、APS(生産スケジューラ)の適用には、二つのパターンがある、と書いた。生産計画担当者が、全部を細部までスケジュールするやり方と、現場側にある程度の裁量を残すやり方だ。

後者の場合、生産スケジュールでは、ある程度の幅というか枠を決めておき、その枠内では現場側に判断を任せる。典型的な例は、タイム・バケットを1日単位としておき、各工程(作業区)単位の個別オーダーは、その日のうちに終わるならば、着手順を現場のチーフが決められる、といった形だ。

個別オーダーの正味作業時間は、たとえば数十分とか、せいぜい数時間である。だから1日の中で複数のオーダーを処理できる。ただ、標準リードタイムは1日で設定しておく(つまり、朝10時に出来上がろうが夕方5時に終わろうが、次工程に運ばれるのは翌日だ)。そして、1日の中での順番は、現場が決めていい、とする。

現場側には、機械やツールや人手など、いろいろな生産要素の都合から、やりやすい順番というものがある。それを生産スケジュールで、ガチガチにしばられるより、裁量範囲を残してもらう方が生産性が上がるのである。

このようなやり方は、生産順序が全工程で決まっているフローラインよりも、ジョブショップ型の生産方式で求められることが多い(生産方式の種類については、「ライン、ショップ、セル 〜 生産方式を理解する」 2021-05-15 を参照のこと)。

ただし、こうしたやり方には短所がある。一つ目は、全体リードタイムが長くなりがちなことだ。

どんなに短い正味作業時間のオーダーも、リードタイムを1日に設定するわけだから、1つの工順が5工程から構成されたいたら、全体では必ず、5日以上かかってしまう。もしかしたら、その材料を終わった順にすぐ次工程に回せば、1日で済むかもしれないのに、5日かかるのである。だから、受注から出荷までの生産リードタイム(サイクルタイム)が、本来よりも、かなり長くなってしまう。それは競争力の面から見て、ハンディである。

出荷までのサイクルタイムが長くなるということは、工場の中に滞留する仕掛品が増えてしまうことを意味する。これが2つ目の短所だ。工場の中に仕掛品があふれると、どうしても、モノ探しが始まる。それを避けたかったら、所在管理が必要になる。途中で在庫棚に搬送して入出庫する手間が増える。物を探したり、棚まで運んで出し入れする時間は、付加価値には一切、貢献しない。単にコストが増えるだけだ。

そして3つ目の問題点。それは、溜まっているオーダーの中から、着手順を決める判断基準が、実はその工程(作業区)の都合だけで決まっていて、工場全体のことを考えていない、ということだ。着手可能なオーダーの中には、納期ギリギリのものや、すでに遅れているものもあるかもしれない。だが、その工程のやりやすい順番では、後回しになるかもしれない。着手待ちのオーダーが、それでも1日で片付く量の範囲内だったらいいが、もっと滞留が増えたときは、明らかに全体としてはまずい判断になってしまう。

いいかえると、現場の着手順の判断が、局所最適になっていて、全体のベストを考えていないのである。とはいえ、各作業区のリーダーには、工場全体の状況など見えないのだから、それを責めるのは酷なことだ。

この時に役に立つ知恵がある。それが優先番号法である。各工程ごとに、滞留中の待ち状態のオーダの中から、順番付けをして着手(デイスパッチ)していく。ディスパッチング・ルールとも言う。

優先順位付けの指標として、最小作業時間順、最小スラック(納期余裕)順などが用いられている。 そして、この分野に関しては、昔からスケジューリング研究者が、様々な研究や数値実験を行ってきた。その結果、最小スラック順が、平均的に最もパフォーマンスが良いことが、知られている。

「スラック」とは納期までの自由度、あるいは余裕日数を意味する。プロジェクト・スケジューリング分野ではFloat日数とも呼ぶ。すなわち、次の式で決まる量である。

 スラック(自由度) = 納期までの日数―所要製造日数

納期までの余裕がないオーダーから、先に着手せよ。まあ、ある意味で、当たり前のことを言っている。

ただ、この「当たり前」を製造現場で実現するためには、工夫が要ることが多い。つまり、スラック(自由度)の「見える化」の仕組みを作る必要があるのだ。

たとえば、「着手可能リスト」を工程(作業区)ごとに作成する。あるいは、納期余裕率を信号色(青・黄・赤)などを使って表示する。たとえば、青:自由度>67%、黄色:66%>自由度>34%、赤:33%>自由度 などである。

さらに、現品票にも、納期と、工順ごとの所要日数を印字する。仮置場書には、到着順ではなく納期順に置く、などなど。現場でものを見たときに、すぐ、その納期余裕が分かり、かつ、いろいろ溜まっている中から、最小の余裕日数のものを、すぐ取り出せるようにしなければならない。

そして、こういう時にこそ、まさに工場におけるデジタル技術の出番であろう。紙の現品票(一度出力したら変えられない)をRFIDとスマホやタブレットで置き換える、とか、アイデアはいろいろとあり得よう。

全てをスケジューリングする必要はない。ただ、生産スケジュールの中で、現場側に委譲された着手順の判断は、ある一貫した方針に従うことが望ましい。そして、デジタル技術はそのために、役立つ使い方があるのだ。

デジタル技術は、とても便利な道具だ。だが、どこでどういう時に使うかに、知恵がいる。言い古されたセリフかもしれないが、ITは使い方(Know-how)よりも、しおどき(Know-when)の方が、もっと大事なのである。


<関連エントリ>
  (2021-05-15)
  (2021-07-25)


# by Tomoichi_Sato | 2021-08-03 23:12 | サプライチェーン | Comments(0)

全てをスケジューリングする必要はない

前回の記事で、日本企業はしばしば、過剰に計画したがる傾向がある、と書いた。その主な理由は、先にお金の出入り(予算)を押さえておきたいためと、リスクに対する不安があるためだ。研究開発や業務改革などは、スコープ自体が柔らかくて、行うべきアクションの内容や仕事量が精度よく見積もれないのに、過剰な細部まで先に決めたがるのである。

似たような事情は、プロジェクト・スケジュールや、生産スケジュールにおいても起こり得る。そもそもスケジューリングとは計画作業の一部だから、まぁ当然と言えば当然である。

この傾向は、日本よりも計画重視の傾向が強い米国発で、日本に持ち込まれたのかもしれない。もともとPERT/CPMなどのプロジェクト・スケジューリングの手法は、1950年代に、アメリカで開発されたものだ。

実は同じ頃、生産スケジューリングの理論においても、アメリカで重要な発見がなされた。それは、ジョンソン法と、ジャクソン法と呼ばれる手法だ。いずれも、RAND研究所における発見である。RAND研究所は米軍系列のシンクタンクであり、当時の作戦研究(OR = operations research)のメッカでもあった。

これについては、かつて拙著「革新的生産スケジューリング入門」で触れたことがあるので、以下その第3章から少し引用させていただこう。


「今日はまず、ジョンソン法の話から始めましょう。

ジョンソン法は、生産管理の本などには必ずのっている、古典的なスケジュ ーリング理論の手法です。ある意味では古典的理論の成果といってもいいでしょう。

今、2段階の工程からなる製造過程を考えます。ジョンソン法は、この2段階の工程に複数の生産オーダーが出ているとき、どういう順序でやれば全体の作業期間が最短になるかを教えてくれます。具体的には以下の手順で順序付けを行います。

(1) 未決定の生産オーダーのうち、工程作業時間が最短のものを選ぶ。
(2) その作業が第一工程なら未決オーダー群の着手順の最初に、また第二工程なら最後に割付ける。
(3) そのオーダーを、未決オーダー群から削除し、(1) に戻る。

こうして未決オーダー群がなくなったら終了です。
全てをスケジューリングする必要はない_e0058447_22520262.jpg
この例では、2つの工程の加工の順序が決まっていますが、製造作業の内容によっては加工の順序を逆にしてもいいものがあります。そのような工程を、ランダム・ショップと呼びます。工程の順序が決められていて変えることができないものは、フロー・ショップと言います。ジョンソン法はフロー・ショップの順序付け手法ですが、これをランダム・ショップに拡張したものがジャクソン法です。

ジョンソン法の考え方を、自由度という観点から解釈するならば、作業時間の最も短いものから順に端に置いていくのですから、『自由度消費が最小になるような順序で着手順を決めよ』ということになります。

さて、このジョンソン法の成り立つ条件は、次のようなものです。
・すべてのタスクの作業時間が確定していること(1点見積り)、かつその見積りどおり変動なく実行できること
・すべてのタスクの納期が同じであること、ないし納期(の優劣)は気にしないこと
・すべてのタスクが着手可能であること (EPST = Earliest possible start timeが同じ)
・タスクが後から次々飛びこんできたりしないこと
・2工程であること (3工程以上には簡単に拡張できない)

このように条件をならべてみると、ジョンソン法が実務上使える範囲はきわめて限られていることがわかります。数学的に最適性が保証されているので理屈としては面白いですが、実用上の価値はほとんどないといっていいでしょう。」


金字塔的な古典理論に、実用的価値がない、などと書いたためかはわからないが、本書は出版当時、スケジューリング学会からは、必ずしも好評ばかりを得たとは言えなかった。スケジューリングの研究者たちは、スケジューリング問題を数学的な最適化の枠組みで解きたい、と言う問題意識を持っているからだ。

しかしわたしは同本の中で、「スケジューリングは最適化の問題ではない」とまで主張したので、議論を呼んだ訳だ。最適化の問題でなければ、一体何なのか。それは、動的な適応制御である。次々に入ってくる注文、時々刻々と変わる生産現場の状況、あるいはサプライヤーの納入、こうした外乱や変動にどれだけ上手に適応しながら、生産していくかを考えるのがスケジューリングだ。

そのためには最適化し過ぎてはいけない。最適化しすぎると、ちょっとした変更に対しても、計画全体がもろくなってしまう。変更の影響範囲が広がるし、再計算にも時間がかかる。むしろスケジュールの中に一定程度の自由度を残して、外部環境や内部状況の変動にうまく適応できるようにするべきだ。——これが同書で主張した私の基本的なスタンスである。

もともとスケジューリング問題は、いくつかの視点から分類 することができる。

機械群における最適な製品生産順序を求めるスケジューリング手法は、対象となる製造オーダの条件があらかじめ全て決められている静的問題と、オーダがつぎつぎ飛び込んでくる動的問題に分類される。

また、作業時間が確定的なものと、確率的なものがある。さらに工程数および加工順序に関して、いくつかに分類される。加工順序が決まっているものをフローショップ、加工順序が製品により前後しうるものをランダムショップと呼ぶ。これら問題の種類により、用いるべき解決手法が異なるのだ。

さらに、スケジューリングそれ自体に、多目的性がある。スケジュールを評価する指標として代表的なものは、
・最大滞留時間(総生産時間):全作業が終わるまでの時間
・最大納期遅れ:製品のうち納期に最もに遅れた時間
・機械の平均稼働率:機械群の稼働率の平均値
などがあり、スケジューリング問題の多目的性を示している。

こう考えてみると、古典理論におけるジョンソン法は、すべてのオーダーがあらかじめ与えられていて、かつ作業時間は確定的で、しかも評価指標は最大滞留時間を一番短くすること、と言う問題を解いていることがわかる。おまけにフローショップで、2工程の工場に限る。とても制約が多い。

だから、実際にジョンソン法を用いて生産スケジュールを動かしている会社というのは、少なくともわたし自身は日本で見たことがない。

古典理論は数学的な最適性が保障されているが、現実にはあまり使えない。そこで90年代以降出てきたのが、APS(Advanced planning and scheduling)と呼ばれるソフトウェア群だ。最適解は保障されないが、少なくとも現実的な規模の問題を、短い時間で解くことができる。

では、この道具を用いれば、あらゆる製造現場の問題を解決することができるか? なかなか、そうはいかないのだ。

マスターデータの整備の手間が大変だ、と言う事はよく指摘される。それ以外に、私は2つボトルネックがあると思っている。

その1つは、生産の実績進捗を、なかなかリアルタイムに把握して、次のリスケジューリング時にフィードバックできないと言う問題。もう一つは、そもそも作業時間自体にある程度、ムラや幅があって、計画の精度が上がらない問題だ。

後者は例えば、なかなか品質が安定しない製造工程や、作業者の技量に大きく依存してしまう工程などで顕著である。工場と言うところは、同じものを同じペースで確実に製造できる、と思い込んでいる人も多い。そういう人は、半導体の後工程などを勉強すると良い。もう昔の話だが、Intel Pentium CPUなど、初期の良品率は10%すらなかったと言う。

そこまで特殊な例を出さずとも、多くの製造現場では、作業時間のブレに結構悩んでいる。そういうところで、すべてを細部までスケジューリングしようというのは、必ずしも得策ではない。

ではどうすべきなのか? APSベンダーの人に聞くと、APSの適用には、概ね2つのパターンがあると言う。1つ目は、計画者が全部を細部までスケジュールするやり方。この場合、スケジュールを現場におろして、現場は単純にその指示に従うということになる。

もう一つのやり方は、現場側にある程度の裁量を残すやり方だ。例えば、タイム・バケットを1日単位で集約し、1日の中の各オーダーの着手順については、現場側の裁量に任せる。こうすれば、作業時間に多少の伸び縮みがあっても、1日の中で収めることさえできれば、現場のやりやすい順序で仕事を流すことができる。

このように、全てを細部までスケジューリングするばかりが、ベストな方法とは限らない。頭のいい計画者がいて、現場は全員、そのロボットのように動く、というイメージは、英米や中国のような中央集権的経営思想の強い国には向くかも知れない。だが、少なくとも日本では、必ずしも受け入れられないだろう。また、作業時間のブレを考えた場合、現実的でもない。

だからといって、現場側にあまりに裁量を残しすぎるのも、いささか心配がある。というのも、製造現場はしばしば縦割り組織になっており、必ずしも各職場が「全体最適」を意識して判断してくれるとは限らないから。

そこで、このような時に役に立つ知恵が必要になる。その一つが、優先番号法である。だが、また長くなってきてしまったので、これについては項を改めて、また書こう。




# by Tomoichi_Sato | 2021-07-25 23:14 | サプライチェーン | Comments(0)

プロジェクトを計画しすぎてダメにする方法

「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」

たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画(いわゆる「予算」)、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。

だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登ったかで進捗率を測ることもできる。しかしイノベーションは、行き先も地図も定かならぬ旅路(ジャーニー)である。大きな方向性はあるだろうが、実際には小刻みに、道を探りながら進むしかない。

にもかかわらず、とくに国などの公的資金が入るような研究開発などでは、「計画しすぎ」の弊害が見受けられるように思える。研究開発には最低でも数年単位の時間がかかる。しかし国の予算は年度単位だ。だから年度ごとに、達成すべき目標をあらかじめ定めてから、始める。そして異様に細かな経費記録や詳細な経過報告が求められる。

このような考え方の底には、「研究開発に携わる研究者という連中は、自分たちの興味のおもむくまま、勝手に好きなことをやりたがるものだ」という信憑だか不信があるのだろう。たしかに、 大企業の中央研究所というお堀の中に住む人の中には、技術を具現化して利益を生み出すより、学会誌に論文を何本出すかに情熱を集中するタイプも、いることは、いる。実用よりも、真理探究の知的好奇心が、行動基準なのだ。

なので、そういう、いわば「ネコ型」の研究者の首に鈴をつけるために、大部な計画書の作成が義務づけられ、詳細な(しかも文章記述中心の)進捗報告の書式が定められる。計画書の提出で研究費が配分され、進捗が遅れると鞭打たれる。こうすれば集団で一つの目標を追いかける「イヌ型」の行動をとるはずだ、と思うのであろう。これが研究開発型プロジェクトを「管理」しがたる側の、ロジックである。

だが、技術開発というのは、未知に挑む仕事だ。途中で、大きなやり直しも生じやすいものだ。なのに、こういう官僚的な管理システムの中では、最初に決めた目標に向かって、計画で決めた通りのペースで進むことが求められる。途中でうまくいかないことが明らかになっても、大きく方針転換したり、中止する決断を、誰もしない(官僚組織でそんな事を決めれば、責任を追求されるからだ)。

かくて、数年後には意味の乏しい成果しか得られぬと分かっているのに、延々と無駄金を投じるような研究開発が進んだりする。公的資金が絡まなくても、官僚的体質の大企業では、似たようなことが起こりがちだ。

研究開発以外でも、新事業開発や業務改革といった分野のプロジェクトも、同様の問題を抱えるケースが少なくない。新事業の開発は、(同業ライバルのまるっきり真似をするのでない限り)どんな答えが出てくるか、あらかじめ決められない。業務改革プロジェクトもしかり。在庫削減だの省人化だの、KPI的な目標は先に与えられるかも知れないが、方法は誰もよく分からない。それなのに、詳細な計画を立てろと言われる。

だったら、計画なんて一切、立てなければいいではないか。まず動いてみて、考える。必要なのは、現場力。それで何が悪いのか? 誰か困る人がいるのか?

もちろん、時間が無限にあり、お金も使い放題、人も好きなだけ動員できるなら、それもありだろう。だが組織が抱える経営資源は、お金も人も有限だ。それは、なるべく有効に使いたい。これが、経営者の論理である。急にお金がいると言われたって困る。当期利益や来期予測から大きく外れたら、株主からも叱られる。

経営管理側が、プロジェクトチームに計画を要求する主な理由は、資金調達、つまりお金の出入りを予定したいからだ。でも、それだけではない。上に書いたとおり、実行者側に対する一種の不信感がある場合、どうしても詳細な計画を作らせ、説明させ、なおかつ実行段階に入ったら、進捗確認で尻をたたいて、都度モニタリングしたい、と考えがちだ。

ところが実行者側は、プロジェクトの初期段階ではそんなに詳細な計画なんて立てようがない、と考えている。仮に立てたって、その通りに進むはずがない。ここにギャップがある。

このギャップは結局、プロジェクト計画は誰のためにあるのか、何を目的として作るのか、という認識のズレから来る。

本来、プロジェクト計画は、プロジェクトの実行主体(現場側)が、必要なアクションの特定と、リソース(特に人と予算)のニーズを明らかにする目的で作るものだ。それにより、実行の当事者が、自分たちの進め方をある程度、イメージアップする。別の言い方をすれば、プロジェクト計画とは、モデル作りなのである。プロジェクトがどう進むか、どう進めたいか、に関するモデリングだ。

モデルとは、一種の近似である。全ての細部にわたって正確なモデルを作ることはできない。ただ、重要な部分だけは、ある程度精度良く、おさえたい。それが良いモデルだ。そして良いモデルができると、外部環境の変化などのイベントに、どの程度影響されるのか、どこが弱いのか、などのシミュレーション的検討にも使える。

つまり、プロジェクト計画というのは、実行主体が、頭の中で様々なシミュレーションを行って、いろいろな環境変化にも対応できるようにするために作るのだ。だから、前回の記事で説明したように、最後に「リスク・アセスメント」が来るのである。

ところで、プロジェクト計画は、実行主体(とくにプロマネ)が、外部のステークホルダ(利害関係者)に対する説明にも使う。そのステークホルダとしての最初で最大の説明相手が、じつは経営管理層なのである。そして、管理する側は、「プロジェクト計画とは、自分たちへの説明文書だ」と考える。ここが誤解の始まりだ。

とくに、実務内容を指導できない「管理者」は、計画の中でも、コストとリスクの項目しか、見ようとしない。だが実際にはコストは、プロセスの結果で決まる。プロセスとは、アクション(PM用語ではActivity)の連鎖である。アクションの連鎖が、品質とスケジュールを決め、結果としてコストが定まる。プロセスを支えるのは、人や設備などのリソースからなる「体制」である。

だから本当にコストを「管理」しかかったら、アクションを指導し体制を指示することが必要だ。だが、技術の中身が分からない管理者は、任命したリーダーの「資質」と、結果としてのコストだけしか口を出せる範囲がなくなる。あと、口を出せるのは、「リスク」であろう。

ただ、それは管理者としての、一種の責任逃れの本能から見たリスク評価になるケースが多い。プロジェクトのリスクの評価は、本当は、問題解決能力と表裏一体だ。自分がすぐに解決できる問題は、普通リスクとは言わないからだ。

結局、管理側が現場から遠く、その仕事の内容を良く理解できないまま、口だけだそうとするから、計画過剰になるのだ。それも、自分では計画を立案できない。現場側に計画を立てさせて、足りなそうな点を批評するだけだ。かくて、管理過剰に陥るのである。計画しすぎてダメにするのは、つまり管理しすぎてダメにすることの一部なのだ。

では、どうしたら良いか。

この問題の背景には、経営管理側と実行者側との認識のギャップがある。そこで、簡単ではないが、このギャップを埋めなければならない。そのためには、「プロジェクト・ガバナンス」の原則と、「スコープが固まるタイミング」について、両者がともに理解するべきである。

「ガバナンス」という言葉は一般に、「マネージャーをマネジメントする」意味で使われる。プロジェクト・ガバナンスとは、つまり、プロマネをどう経営層がマネージするか、いいかえると、どんな権限を委譲するか、に関する決め事である。

たとえば英国のPM標準「PRINCE2」が推奨するように、スケジュール・コスト・スコープ・リスクなどに関して、権限と許容度を設定しておく。たとえばプロジェクト・レベルでは1ヶ月以内まではプロマネの裁量とし、それ以上になる場合は、スポンサーやステアリング・コミッティに上申して裁可を仰ぐ、といった決まりを作る。このように、現場側にある程度の自由度を残し、かつ、野放図にならぬよう制限をつけるのだ。

もう一つの「スコープが固まるタイミング」については、とくに自発型プロジェクトで重要になる。というのも、研究開発・新事業開発・業務改革など、自発型プロジェクトの多くは、最初はかなり「ソフトな」スコープでプロジェクトが開始する。そして、ある程度検討が進んで、何をどうすべきかかなり明確になった段階で、はじめて、残りの仕事が「ハードな」スコープとして見えてくるのである。

この事情はIT開発プロジェクトも似ていて、初期の段階ではスコープは非常に柔らかい。それが、要件定義を完了すると、ようやく作るべきシステムの規模や機能詳細が見えてきて、コストやスケジュールを、精度よく予測できるようになるのである。

この事情を、わたしはよく魚の形にたとえる。初期の検討はまだ、魚の顔の鼻先をみているようなものだ。それが、基本設計や要件定義を進めると、しだいに目や口の位置が見えてくる。そして、エラの形まで分かるようになったら、あとはどれくらいの体が後ろについているかが、推定できるようになる。そうなれば、計数管理ができるようになる。
プロジェクトを計画しすぎてダメにする方法_e0058447_23240562.jpg

だから、経営層が詳細な(コスト的)計画を求めるタイミングは、魚の頭がかなり見えてくる時まで、待つべきなのである。

およそ、自発型プロジェクトの多くは、非常に柔らかなスコープからスタートする。その初期は、コストやスケジュールで管理するのではなく、プロジェクトの生み出す成果物の「前向き品質」(魅力品質)と、技術リスクの検討に集中すべきである。だから、初期のプロジェクト計画は、当面のアクションとリソースについてカバーする範囲で十分だ。

もし進捗を見たければ、数量ベースではなくマイルストーンで見ていく。あるいは、アジャイルのようにiterationベースで見ていく。この段階で使うコストは、どうせ知れている。だから遂行の効率性よりも、生み出す有用性を高める努力の方が、ずっと大切になる。

そして、ある程度進んだら、プロジェクトの中に、かなり固まったスコープの部分が見えてくる。そこではじめて、計数管理に基づくベースライン計画を作り直すのである。初期の段階でも、この段階でも、プロジェクト計画で使うステップは、共通している。だが、目的とフォーカスが違うのである。

計画は、必ず必要だ。だが、物事は決して計画通りに行かないからこそ、我々の対応能力を高めるために、計画づくりの作業が必要なのである。


<関連エントリ>


# by Tomoichi_Sato | 2021-07-18 23:32 | プロジェクト・マネジメント | Comments(0)