<   2009年 04月 ( 6 )   > この月の画像一覧

超入門・工程管理(3) スケジュールを実行可能にするための『7つの処方箋』

それでは、オフィスワークを主体とする工程管理を「実行可能性」の尺度にのせるための、7つの処方箋について説明しましょう。

まず、(1)計数管理に乗せにくい、という問題に対処する2つの方法です。

<処方箋A マイルストーンで追いかける

 数量ベースで進捗を測れないときは、マイルストーンで追いかける。これが工程管理の定石です。マイルストーンとは、スケジュール上の節目となるタイミングで、ふつうは最重要な経路(クリティカル・パス)上に置きます。受注設計生産の例でいえば、[設計レビューの通過] [承認図の提出] [長納期部品の購買手配] [全部品の納入]といった時点が典型的なマイルストーンです。そして、これらマイルストーンの予定日と、実績日を対比して進捗を見ていくのです。
 
<処方箋B 実績データを台帳化する

 ここでいう「実績データ」とは、もちろん工程(スケジュール)に関する実績です。中でも重要なのは納期実績ですね。実績データがあれば、少なくとも顧客要求納期が実行可能かどうかについて、考える手がかりができます。

 どこの企業でも、コストに関してはかなり細かな案件別実績データをとっています。しかし納期実績となると、急にあやしくなります。ひどい納期遅れの事例くらいは、関係者の記憶には残っているかもしれません。が、製品群別の納期遵守率や、季節別の納期遵守率となると、具体的にどうだったかさえ、集計されていないケースがほとんどです。

 さらにいえば、最終納品のタイミングのみならず、上記の各「マイルストーン」ごとに実績の着手日と完了日を記録し、どれくらいの作業期間が現実的だったのかをつねに参照できるようにすればベターでしょう。

次の二つの処方箋は、(2)外部に依存するプロセスが多い、という問題への対処法です。

<処方箋C バックワード計画でスケジュール責任日(Required Date)を明確にする
 
 「バックワード計画」とは、納期から必要日数を逆算し、マイルストーンの予定日を決めていく計画手法です。引き算で考える、これがバックワード・スケジューリングです(なお、フォワード・スケジューリングはこの逆で、開始時点から必要日数を足し算して納期を決める方法です)。

 バックワードでスケジュールを決めた場合、各マイルストーンの予定日は、ぎりぎりの期限、すなわち、それが守れないと最終納期も遅れてしまう日を意味します。これを、後工程へのスケジュール責任日(Required Date)とよんでいます。後工程が前工程に対して必要(Require)する日だからです。これを最初の日程計画で明確にし、各部門で認識することが大事です。

 なお、この責任日を決める際に、しばしばやりがちなミスがあります。それは、所要期間を(“安全のために”)長めにとって、前倒しに決めてしまうことです。責任感の強い、真面目な組織ほどこうしてしまいがちです。しかし、このようなサバ読みがあちこちで挟まると、「結局少し遅れても大丈夫じゃないか」という風に皆が思い始めて、スケジュールの実行可能性が絵に描いた餅になってしまいます。本当に必要な正味(Net)の期間で、責任日を決める。決めたら、それを是非守る。これが大事です。

<処方箋D プロアクティブな催促(Expediting)をする

 Expeditingという英語には、適切な日本語訳がありません(スケジューリングの分野では珍しくないことですが)。ここでは催促といっておきます。プロアクティブ(proactive)は“能動的に”ですが、こちらはカタカナ言葉として通用しはじめたね。受け身ではなく、自分から行動すること、問題が起きる前に事前に動くことです。受け身でない催促とは、着手日が近づいたら、事前に当事者に予告すること、また期日が近づいたら、リマインダーを出すことです。期日を過ぎてから、あわてて督促することは「プロアクティブな催促」とは言えません。
 
 とくに事前の予告は、製造部門や外注先・購買先に対して、準備のアクションをとってもらう点でとても有効です。ただし、この予告は正確でなければなりません。いいかげんな予告を次々出しては、後からすぐ変更したり取り消したりするようでは、だれも予告など信頼しなくなります。結果として、相手はリアクティブな「待ちの姿勢」になってしまうでしょう。実行可能な予告をして、それを守る。プロアクティブな行動は、他者をも能動的にするし、逆にリアクティブな行動は、他者を受動的な姿勢にしてしまう点に注意してください。

次の2つの処方箋は、(3)リワークのリスクがあることへの対処法です。

<処方箋E フロート日数を活用する

 バックワード計画では、物流→出荷→検査→製造→部品調達→詳細設計→基本設計、と工程を逆にたどり、本当に必要な正味(Net)の期間で納期から逆算してスケジュール責任日を決めます。そのとき、基本設計開始日と正式受注日との間に少し余裕日数がある場合、これを「フロート日数」と呼びます(スケジューリング理論では、厳密にはクリティカル・パスとの関係で3種類のフロートが定義されているのですが、ここでは分かりやすいように簡単に定義しておきます)。
 
 でも、もし受注日と基本設計開始の間の余裕がゼロだったり、逆にマイナスだったら? --こういう質問をよく返されます。もし、フロート日数がマイナスなら、それは「受注したときから既に納期遅れが確定している」ということを意味しています。御社で、フロート日数がマイナスの案件がたくさんあり、しかも、そのほとんどをなんとか納期に間に合わせているとしたら、そのときはたぶん「必要な正味(Net)の期間」が正しくないのです。安全をとって、長めの日数が入っているはずです。
 
 設計の手戻りや、最終検査での修正作業などの可能性があると、その分の日数を「安全のため」「経験的に」とりこんで、多めの日数設定にしがちです。リワーク(手戻り)がないと仮定した正味の期間と、リワークを前提にした長めの期間との差を、「アロウアンスAllowance」といいます。各部門で日程にアロウアンスを抱え込みはじめると、結局、スケジュール全体の精度が落ちてきます。それだけでなく、個別部門のアロウアンス日数を合計すると、Netで計算したフロート日数より、ほぼ確実に長くなるのです。
 
 これを防ぐため、NetとAllowanceの区別を皆が意識することが大切です。さらに、正味スケジュールで得たフロート日数を、工程上のボトルネックとなる箇所に、固めて配置するのが秘訣です。Kさんの会社の場合がどこかは分かりませんが、客先承認図や最終検査などに、よくフロートが置かれます。

<処方箋F Forecast Dateを共有する
 
 Forecast Date(見込日)とは、Plan(計画日)とActual(実績日)をつなぐ役割をもち、スケジューリングにおける中級テクニックの一つです。
 
 最初に実行可能な計画をたてたつもりでも、現実はいろいろな理由から、計画と乖離しがちです。計画からの乖離がおきると、下流工程部門は自分の仕事が実際にいつはじまるのか分からず、困ってしまいます。かといって、そのとき、あわてて計画を修正してしまうのは下手なやり方です。計画を現実に合わせ続けると、いつもふり返ってみたら現実とぴったりあった計画しか残りません。そうしたら、上記の処方箋Bは成り立ちませんね? 計画は計画としてできるだけ残し、事実と対比できるようにしておかないと、計画立案自体の改善につながりません。

 現実が計画から乖離しはじめた場合には、Forecast Date(見込日)が役に立ちます。現状から推定すると、着手/完了の日はいついつになるだろう、という予測値をForecast Date(見込日)と呼びます。これを部門間で共有することで、下流部門も自分達なりの予定が立てられるようになるのです。

さて、最後の(4)複数の部門がかかわっている、という問題こそ、製造業では一番根の深い問題です。これに対する回答が、7番目の処方箋です。

<処方箋G 設計部門がスケジュール・コントロールの責任を負う

 上述の処方箋A~Fに共通していることは、スケジュールのコントロールを担当する者が必要だ、ということです。それぞれの個別案件について、誰かがまとめて、受注から納品まで面倒を見る体制が望ましいのです。しかし、日本企業の縦割り組織が、しばしばその実現をはばむのも、ご承知の通りです。
 
 私は、受注設計生産の業態においてその任に一番ふさわしいのは設計部門ではないかと考えています。率直に言って、下流工程に位置する製造部門が、上流のプロセスを遠隔コントロールするのはけっこう難しいものです。かといって、営業や購買部門にそれを求めるのは無理でしょう。進捗管理という仕事は、ある程度、技術的なことがらについて理解や判断が求められるからです。
 
 そういうわけで私は、設計部門が、もう少し製造業におけるエンジニアリング・マネジメントの職能を確立し、その中で工程のスケジュール管理を進めることが望ましいと思っています。無論、これには権限の問題や、要員の向き不向き、組織論などさまざまな論点が絡みますので、どこにでも当てはまる解決ではないことは承知しています。しかし、適任の部署がいないということは、そういう機能や責任が不要である、ということを意味しません。むしろ、不況下で競争が厳しくなる今日において、より大きな意義が出てくると考えます。

Kさん。長々と書いてしまいましたが、もう一度くりかえします。工程管理で一番大切なことは、実行可能な計画を作って、それを守ること。守るとは、keepであり、protectであり、またcontrolでもあります。この7つの処方箋のうち、どれか一つか二つだけでも、与えられた2ヶ月という期間内に実行に移すのは、それなりの努力と全員の理解がいると思います。しかし、リードタイムのほとんどは待ち時間やムダ時間である、という事実を思い出してください。御社が、今後は納期を武器に、ぜひ受注を広げらていかれることを期待してやみません。
by Tomoichi_Sato | 2009-04-27 22:42 | サプライチェーン | Comments(0)

超入門・工程管理(2) オフィスワークの工程管理はなぜ難しいか


Kさん。“工程管理で一番大切なことは、実行可能な計画を作って、それを守ることです”--こうご説明しても、そんな言葉は当たり前すぎて、何の役に立つんだ、と疑問を感じられたかと思います。

しかし私の見聞きしているかぎり、少なからぬ業界で、近年、これとは逆のことがしばしば起きてきたのです。つまり、実行不可能な納期を請け合ってしまって、守れなくなる。あるいは、たぶん最初は可能だったはずの納期が、他のオーダーの割り込み等で、どんどんずれていく。ひどいときには、そもそも出荷がいつになるか答えられない。昨年夏までの原材料インフレの時期は、こうしたことが頻発しました。秋以降、一転して不況になると、納期の見積はさすがに正常化してきましたが、今度は安値競争になって、設計も製造も外注に出す、という。こうなると、どうやって工程を守るのか、逆に心配になってきます。

「守る」とは、自分自身が努力して個別作業のスケジュールを守る(keep)ことだけではありません。外乱や飛び込みからスケジュール表を守る(protect)ことも含まれています。守らなければ、納期を確約できません。納期を確約できないと、心配性の営業や上役や顧客から、さらに外乱や飛び込みの依頼を招くことになるのです。

くりかえしますが、私がここで問題にしているのは、製造業におけるオフィスワークを主体とした工程の管理です。製造業では伝統的に、工程のボトルネックは製造現場にあると信じられてきました。これは見込生産や、一部の繰返し受注生産の企業では、いまだに正しいでしょう。製品の設計(仕様)がすでに決まっていて、同じ材料を買って繰り返し作る場合、工程管理の仕事はほぼ製造現場だけのスケジュールを見ていればすみます。

ですが、多くの受注生産企業では、自社工場の現場以外の部分でリードタイムの大部分を使ってしまっています。その理由は、顧客からの注文の個別性が高まったこと(これは「製品にいろいろなオプションをつけて差別化し、高付加価値にしたい」という方針の生んだ結果)です。また、御社で行われている海外子会社からの部品輸入や、製造委託や、詳細設計作業の外注など、受注から製造までのプロセスが社内外で細分化されてきた結果でもあります。つまり、設計・調達(個別調達)作業が入るかどうかで、工程管理の事情は大きく分かれるのです。

そして、こうしたオフィスワーク主体の工程では、たとえスケジュール計画を立てても、その実行可能性を簡単に保証できない、という問題が生じます。計画上の納期は3ヶ月後です、といっても、技術も営業も(そして顧客も)疑心暗鬼でいるのです。そこで、どうしても確認・連絡・調整のやりとりが多くなる。そうするとコミュニケーションに手間をとられて、なおさら遅れていく。悪循環ですね。

このように、計画の実行可能性を検証することが困難になる理由は、大きく4つあると私は考えています。まず第1に、オフィスワークのスケジュールは計数管理に乗せにくい、という問題があります。次に、受注設計生産では、外部のプロセスの比率が高い、という事情があります。第3の理由は、オフィスワークでは手戻りによるやり直し(リワーク)のリスクが無視できない、という点です。そして、第4は、そもそも工程が複数の部門をまたいで遂行されるため、全体像や責任の所在がわかりにくいことです。以下、これらについて検討してみましょう。

(1)スケジュールを計数管理に乗せにくい

製造現場ではスケジュールについて計数管理ができます。部品の数量や機械の加工速度などから、「時間を読む」ことがたやすいのです。しかし、オフィスワークの工程は計数化が簡単ではありません。やろうと思えばできなくはないのですが、きちんと計数化するためには、設計業務や調達業務にたいする案件別タイムシートの記録からはじまって、乗り越えねばならない条件がいろいろあります。なまじ中途半端に計数化しようとして、設計図面枚数や部品数などを数えても、あまり役に立ちません。というのは、スケジュール上重要なものとそうでないものの区別が厳然とあり、その進捗状況は、予算消化と違って、単純な足し算で比率を決められないからです。

(2)スケジュールを外部に依存するプロセスが多い

詳細設計や部品調達、製造の一部などを外注することは、製造業でかなり広く行われています。そして、いったん工程を外に出すとなると、その段階のスケジュールは固定されてしまって、自社内で吸収できる自由度が減ってしまいます。とくに、一番困るのが顧客承認のプロセスでしょう。個別受注生産では、製造に入る前に、設計図や仕様書を「顧客承認図」として提出し、OKをもらってから先に進むのが世界的な慣習です。でも、承認図を提出したからといって、即座にOKがでるケースはめったになくて、翌日か、5日後、あるいは10日後にようやくGOサインがでます。この「待ち」の期間が読めなくて困るわけです。

(3)手戻りによるやり直し(リワーク)のリスクがある

さて、承認図を提出してからOKが出るまでの間、ぼおっと腕を組んで待っている訳にもいきません。それだけの納期は与えられないのがふつうです。そこで、しかたなく承認されるという前提で、部品調達や製作図作成の作業に移ります。ところが10日後、急に客先からコメントがついてやり直しになり、それまでの作業がムダになる--こんな可能性がつねにあります。あるいは、正式受注前に、主要な長納期部品を先行手配することも、まま行われると思います。これらの行為は、納期を守ることを意図して行われるリスクテークですが、そのスケジュール上のリスクが無視し得ないのです。

(4)複数の部門がかかわっているためスケジュールの責任が不明確

そして、スケジュールの実行可能性を判定しにくい最大の原因が、これです。営業部門・設計部門・調達部門・製造部門・品管部門・物流部門・・・いくつもの部門をまたいで、受注生産は遂行されます。おそらく部門の所在地も本社と工場とでばらばらでしょう。月1、2回の工程調整会議のようなものは、Kさんの会社でも行われていると思いますが、とてもこれでは間に合いますまい。まして、納期が遅れそうになった場合に、どの案件を先に処理して、どれを遅らせるのか。その調整は誰がいつやるのか。日本企業では、ここが不明確になったまま進んでいきがちです。

Kさん。製造現場の生産性は、着手時に全てのモノと情報がそろえば、必ず上がります。しかし、これらが十分そろわないまま、製造フェーズになだれ込まざるを得ない状況が起こりがちです。そして、その責任は、なぜか最下流部門である製造に帰せられる。これこそ先日、本社に呼ばれて役員の方に文句を言われたとき感じられた「理不尽」の正体ではありませんか。

では、どうしたらいいのか。私はオフィスワークを主体とする工程管理を、「実行可能性」の尺度にのせるために、7つの処方箋を提案したいと思います。

(この項、再度続く)
by Tomoichi_Sato | 2009-04-21 22:35 | サプライチェーン | Comments(0)

Web連載記事のお知らせ

技術評論社のWebマガジン「エンジニア・マインド」に、連載「タイム・マネジメントの心得」第12回 『まとめ―もっと「考えるための時間」を!』を掲載しました。どうぞご覧ください。
by Tomoichi_Sato | 2009-04-17 23:55 | 時間管理術 | Comments(0)

超入門・工程管理


Kさん、ご返事が遅くなり申し訳ありません。それにしても、生産管理についてのお尋ねからはじまって、在庫管理、調達管理、そして今回の工程管理と、まるではかったかのごとく生産マネジメントの入門編解説が並ぶことになるとは、私も思いませんでした。最初のメールで「4文字漢語がならぶ章立ての入門書は、あまりおすすめする気になれません」と書いたにもかかわらず、自分がそうなってしまったのはお恥ずかしいかぎりです。

それにしても、面倒なご事情、拝察します。担当営業部長が工場に怒鳴り込んできただけではすまず、Kさんと上司までが本社に呼び出され、常務さんにたっぷり油を絞られて、“2ヶ月以内に工程管理の改善を確約”させられるという事態になったこと、まことにお気の毒です。それも、文面から拝見するかぎり、工場でいろいろなオーダーの納期が遅れ出荷が混乱したことの元々の原因は、アジアの海外子会社からまちがった仕様の部品が遅れて届いたことにありそうです。おまけに、その仕様を連絡したのは本社設計部で、資材部が先発手配をかけた理由は営業からの緊急依頼のため、となると、けっして製造現場だけが責めを負うべき立場にもないように思われます。

とはいえ、Kさんが自省しておっしゃるように、現場側が、どの加工部品はどの顧客向けオーダー用で、どこまで進んでいて、遅れると何に影響が出るのかを、もっとタイムリーに判断できていれば、トラブルは多少は緩和されたのでしょう。そういう意味で、今回の事件をきっかけとして、改善の糧としたいというお気持ちは立派だと思います。

さて。その問題の『工程管理』ですが、具体的には何を指していわれているのでしょうか? といいますのも、「工程管理」に対応する英語は、おおざっぱに言って次の2種類があるのです。

(1) Process Control/Shop Floor Control
(2) Scheduling & Progress Control

前者は主に、現場での運転や作業コントロールをリアルタイムに行うことで、プロセス生産や自働機械・装置もの主体の現場における話です。「工程」という言葉で製造ライン設備というモノをイメージしていただければわかりやすいでしょうか。ツールとしてはMES(製造実行システム)の守備範囲になります。

一方後者は、タイム・マネジメントを切り口にした製造作業の流れのコントロールです。「工程」という言葉は『工程表=ガントチャート』に表されるように、時間的な順序をさします。常務さんが即刻改善せよ、と命じられたのはどちらの方を指しておられるのか。文面だけでは判然としないのです。

なお、ある種のジョブショップでは、両者がほぼ同一の意味になることもあります。このように「工程」という日本語は多義語であり、曖昧さを避けるため私はなるべく使わないようにしています。ちなみに、前者も後者も英語ではControlである点にご注意ください。前に書きましたとおり、私は「管理」という曖昧な日本語もできるだけ使わないようにしています。ということで、自分からはめったに工程管理とはいわないのですが、テーマとして与えられた以上、いたしかたありません。ここでは、問題発生時の事情をくみ取り、後者のScheduling & Progress Controlについてかくことにいたします。

では、まずはいつものように『そもそも論』から。工程管理の機能とは、理工学的に気どっていうと「生産システムの動的な適応制御」です。変化する市場環境に追随し、自己の状況と資源等の制約条件の中で、求められる生産のアウトプットを機敏にもたらすよう、生産システムを動かすことです。もうすこし分かりやすくかみくだいて表現すると、工程管理には三つの目的があります。第一は、納期を守る(あるいは短いリードタイムを実現する)こと、第二は、在庫(“できちゃった在庫”)や欠品を無くすことです。そして第三は、副次的な目的ですが、生産性を向上することです。

第三の目的については、すこし補足説明が必要かもしれません。生産性とは、投入した労働力あたりに産み出される付加価値のことです。が、どうしてこれが工程管理のおかげで上がるかというと、生産性を阻害する最大の要因が、手待ち・手戻り・余計な段取り、といったムダ時間にあるからです。「手待ち」は材料や図面がタイムリーに来ないこと、「手戻り」は作業に先行着手してしまった後からインプット情報がやってくること、「余計な段取り」は、Aという仕事をやりかけたらBをやれと指示されて生じる段取り替えで、すべて工程管理の失敗がもたらすムダです。こうしたムダは製造現場では目に見えて顕著ですが、じつは設計や調達においても、生産性を下げる大きな要因になっています。

目的が見えたら、目標も決めなければなりません。目的は理由や意図をあらわす言葉で、目標は達成の成否を測るモノサシですね。工程管理の目的が上記の三つである以上、目標は納期遵守率やリードタイム長さ、製造着手時の欠品率などで測るべきということになります。

では、工程管理のインプットとは何でしょうか。これは需要側情報(計画情報)と、供給側情報(進捗情報)の二種類が主なものです。前者は具体的には、進行中の基準生産計画(MPS)と、直近の需要(受注)変更情報です。MPSとは具体的にいうと、「どの製品を、いくつ、いつまでに作れ」という生産オーダーの集合で、ふつうは日別ないし旬別に生産数量(所要量)が並ぶ表になっています。月次生産会議などで決定されます。変更情報は、例のごとく、「明後日、急に100個持ってきてくれといわれた」とか「50個の注文がキャンセルになった」といった営業からのアトランダムな連絡です。

一方、進捗情報というのは、製造現場で今、何がどれだけ作られつつあるかのデータです。ふつう現場は製造オーダー(製造指図)で動いていますから、各作業区毎に、どの製造オーダーNo.は着手したとか完了したとか、指示量100個に対して97個しか良品ができなかった、といった報告が上がる仕組みになっているはずです。倉庫への入庫実績もその一部です。これらがきちんと正確に、しかも短時間内に上がってこないと、工程管理はレーダーも高度計もない飛行機を操縦しているようなもので、十分に機能しません。

では、工程管理のアウトプットは何か考えてみましょう。コントロールやマネジメントは自分ではモノを作り出しません。アウトプットは必ず「情報」になります。アウトプットその1は、生産計画よりも詳細な「生産スケジュール」ですね。作業区別・時系列での作業を示したものです。よくガントチャート形式で表現され、現場にはり出されたりします。それから、「製造オーダー」(製造指図)を現場に対して発行します。部品在庫の「出庫オーダー」も必要ですね。それから、調達部門への「購買オーダー」、外注作業区に対する「サービスオーダー」などがアウトプットです。すべてオーダー(指示情報)であることに注意してください。

工程管理のインプットやアウトプットの補助ツールとして、バーコードリーダやRFID、「かんばん」、そして紙の帳票などがあります。また、計画情報をもとに指示情報に展開するためのツールとして、MRPやAPSなどのソフトウェアが利用できます。こうした製造作業のスケジュール立案については、「革新的生産スケジューリング入門―“時間の悩み”を解く手法」を読んでみてください。部品表(BOM)とか工順とかバックワードといった、知っておくべき事柄の解説がのっています。スケジューラ・ベンダーさんが新人の教育に使っているという話もききますので、くわしくお知りになりたい場合は役に立つと思います。

しかし。ここまでのお話は、製造現場に限った「工程管理」の話題でした。が、Kさんの会社のケースはむしろ、製造段階に入る前をも含んだ、もっとスパンの長いタイム・マネジメントが求められているように思います。そして、この種の問題こそ、御社のみならず今日の日本の製造業に共通する悩みでしょう。なぜなら、自社の設計作業や、その設計結果にしたがった個別仕様品の調達がからむ場合は、製造部門だけではコントロールできなくなるからです。

その場合、オフィス部門をも含む工程管理で一番大切なことは、何でしょうか。それは、“実行可能な計画を作って、それを守ること”という一言なのです。(この項つづく)
by Tomoichi_Sato | 2009-04-14 23:31 | サプライチェーン | Comments(0)

マネジメント、はじめの一歩

半年ぶりに、また大先輩のR先生とお会いした。ある会合で一緒になった後、マネジメント論などを話しながらしばらく帰り道を同行させていただいた。

--R先生。結局、マネジメントって何なんでしょう。

「いきなりずいぶん短兵急な質問だな。どうした、会社でも首になりそうなのか。」

--いや、その点は今のところ、たぶんまだ大丈夫だと思いますが・・。この間、会社で若手に『生産管理入門』の講義をやったんです。その時に出た質問がずっと頭に引っかかっていまして。

「マネジメントとは何か、とでも聞かれたのかい。それでうろたえるとは君らしくないな。ぜんぜん講義になってないじゃないか。」

--そうじゃないんです。マネジメントとはPlan-Do-Seeのサイクルを回すことで、生産管理という仕事は、生産システムについてそれを行うことだ、と説明しました。あ、『生産システム』というのは、工場の人や機械やからなる生産の「仕組み」のことです。

「ふむ。多少異論はあるが、まあ、いい。それで?」

--“付加価値を生み出す直接作業を、サポートするための間接作業すべてが、生産管理である”という持論を、在庫コントロールや生産計画などの実例を挙げて説明したんです。そして、生産管理の価値とは、生産システムの効率性(付加価値生産性)や有効性(需要と供給の動的一致、端的には短リードタイム)といった性能向上に貢献することだ、とまとめました。つまり生産管理スタッフは製造現場をサポートするのが仕事で、命令する役割ではない、と。

「たしかに、そのとおりだ。」

--そうしたら、後輩から、こう質問されたんです。“現場の労働が付加価値生産性で測れることは分かりました。では、マネジメントの生産性は、どう測るんですか?”

「いい質問だ! それで、どう答えたね、講師の先生。」

--そこなんです。問題は。“マネジメントの機能は効率性向上や動的適応であって、直接のプロダクトはないのだから生産性は測れない”と答えたんですが、自分でも納得しきれないんです。

「私も納得できんな、そんな回答じゃ。だとしたら、マネジメントに上手も下手も無いってことになる。『測れないものは改善できない』という金言を教えたろ? 君は、マネジメント自体は改善できないものだ、と言っているに等しい。君の仕事はPMOじゃなかったのか。」

--そうなんです。だとしたら、プロジェクト・マネジメントの向上という、自分自身の仕事は意味がないことになってしまいます。

「何ともお粗末なPMOだな。首になる心配をするのも無理はないか(笑い)」

--冗談じゃないですよ。でも、それ以来、この問題が頭を離れません。生産性とはアウトプットを投入量(マンパワー)で割ったものです。マネジメントの価値が分かれば、その生産性も評価できます。では、マネジメントの価値とはいったい何か。

「君が中間管理職になるとき、何も教わらなかったのかね。マネジメントの、はじめの一歩を。」

--研修は、ありました。でも問題解決学やリーダーシップ論みたいな研修で、面白かった記憶はありますが、マネジメントの根本説明は、なかったように思います。Plan-Do-Seeのマネジメント・サイクルというのは、後になって中小企業診断士として勉強した言葉です。

「君はたしか設計部門育ちだったと思うが、すると設計の問題解決は学んだが、マネジメントとは何かを知らずに、管理職になったわけだ。じゃあ一つたずねるが、チーフ・デザイナーとマネージャーは、何がちがうと思うかね。」

--私の業界じゃ『リード・エンジニア』という言い方をするんですが、とにかくまあ、デザイナーは設計プロダクトを作ります。固有技術のチャンピオンですね。一方、プロマネは管理技術のプロです。

「そんな言いかえは答えになっとらん。じゃあ、野球チームのキャプテンと監督の違いは? リーダーシップが要るのはどちらだ。」

--ははあ・・キャプテンは自分でプレイをしています。監督はマネジメントしているだけですね。リーダーシップは、・・キャプテンの側かな?

「いいかね、マネジメントとは自分で球を投げたり打ったりすることじゃない。監督はピッチャーより速い球を投げられるか? ちがう。マネジメントとは、“人にやってもらうよう仕向けること”なのだ。だから、チーフ・デザイナーは、自分でエスキースを描いている間は、全然マネジメントなんかしてないことになる。なのに、ちょっと経験年数がたったからといって何の訓練も与えずにデザイナーを課長に任命して、それでマネジメントができると思っている。人を動かすすべを何か学んだのか? プレイイング・マネージャーしか知らない企業が日本には多すぎるのだよ。だからみな変化に弱いのだ。」

--うーん。でも、マネジメントって、管理職になって人を動かすことなのですか?

「馬鹿言いなさい。管理職という地位は、手段に過ぎん。人を動かすという目的を達成するための、手段にな。手段を目的と取り違えてはいかん。君の会社はマトリクス型組織だから、プロマネはチーム・メンバーの上司ではないだろう?」

--上司では、ありませんね。

「上司は部下を動かす際に『強制力』をもっている。人事考課の権限があるからな。しかし上司でない場合、マネジメントにおいては『影響力』を使うしかない。これを別名、リーダーシップという。リーダーシップというのは、基本的に同格の人間たちの中で、誰かが他者を率いるときに使う言葉だ。民主的なコミュニティの世界での用語だ。上司と部下は同格か? 監督と選手は同格かな? だからキャプテンにふさわしい言葉なんだ。」

--少し前、アメリカでエンジン故障に見舞われた航空機がハドソン川に不時着水した事件がありましたが、あのとき機長はリーダーシップを賞賛されました。あれはどうですか?

「乗客は機長の部下かね? 対等だろう、欧米の感覚じゃ。そして、急な環境変化において見事にそれを乗り切った。通常の飛行では、機長のリーダーシップなんて必要にならない。マネジメントが価値を生むのは、急に対処すべき事態が起こったときなのだ。」

--つまり、マネジメントというのは、平常時には価値はない、ということですか?

「正しくは、マネジメントはリスク回避の局面において最大の価値を発揮する、というべきだろう。だから、マネジメントの価値は、ある意味、『マネジメントが無かった場合どうなっていたか』という比較でしか測れない。ためしに、無能なマネジメントとはどんなものだか挙げてみなさい。」

--気づかない、決めない、見通せない、伝えない、学ばない・・・ですか。みんな否定形で、何かの不在ですね。たしかに。

「そうだろう? マネジメントというのは、何の変化もない時期には、むしろ余計なお荷物なのだ。ただ、変わりやすい環境ではとても大事になる。ちょうど哺乳動物にとっての脳のようなものだ。そして図体に比べて脳が小さすぎる恐竜は、気候変動で滅びた。」

R先生は、まだ花見には寒すぎる夜の都会の風景にむけて手を広げ、こういわれた。

「この激変の時代に、我々の社会を幸せにするのも不幸にするのも、マネジメントのあり方しだいなのだよ。」
by Tomoichi_Sato | 2009-04-07 00:11 | ビジネス | Comments(1)

論文発表のお知らせ

日本経営工学会論文誌に、論文(原著論文)が掲載されました
“Risk-based Value Analysis: A New Theoretical Framework for Project Management”,
J. of Japan Industrial Management Association Vol. 59, No. 6, pp437-442 (2009)

数年前からいくつかの学会で発表してきた、リスク確率にもとづくプロジェクトの価値評価に関する研究論文の一環です。
by Tomoichi_Sato | 2009-04-04 23:37 | プロジェクト・マネジメント | Comments(0)