<   2008年 04月 ( 3 )   > この月の画像一覧

プロジェクト・マネジメントとはどういう仕事か

もうだいぶん前のことになるが、大学の後輩にあたる留学生から、会社訪問の希望があった。彼は東南アジアの出身で、良家の子弟である。いずれは国に帰って立派な職に就くのだろうが、しばらく日本企業でビジネス経験を積みたい、との希望らしい。ついては、私の勤務先の国際プロジェクト部門で働きたいという。

私の勤務先はエンジニアリング会社で、プロジェクト・マネジメントを専門に受け持つ部門がある(念のため書いておくがPMOとは別である)。その部門には、プロジェクト・マネージャー達や、プロマネの卵であるプロジェクト・エンジニア達が配属されており、国内外のプロジェクトを切り盛りしている。彼はそこで少しの間、仕事を学びたいというのだ。

で、どれくらいの期間を考えているの? そうたずねたら、彼は「1年間です」という。私はため息をついて、答えた。「1年では短すぎる。5年とはいわないけれど、せめて3年くらい働いてくれないと、君も仕事を覚えられないし、会社の側も給与に応じたアウトプットを期待できないよ。」そう説明したが、彼は1年という希望をどうしても譲らない。20代前半の人間にとって、1年は永遠の半分くらい長い時間に思えるのだろうか。結局その話はお流れになった。

電話を切って、つくづく思った。“海外プロジェクトのマネジメント”という仕事を、彼はずいぶんかっこいい仕事だと想像しているのだろうな。私は今、この文章をまさに海外プロジェクト現場の宿舎で書いているが、実際のそれは、まさに交通整理と雑用の集積だ。ひどい渋滞の交差点の真ん中で、一日中、汗をかきかき腕を振り回す警官を見て、彼は“大勢のドライバーたちを指揮・指導するかっこいい仕事”と思うだろうか。

乗客や荷物を運ぶドライバー達は、たしかに何らかの付加価値創造に貢献している。しかし、コーディネーションを任務とする警官自身は、何物も作り出さないのだ。接触事故を処理し口げんかを仲裁し、ひどいときには自分で荷物を担いで運ぶ。本署にすわって若い交通警官達を采配している部長は、たしかにかっこいいマネージャーに見えるかもしれないが、仕事の本質は同じである。

私はプロジェクト・マネジメントという仕事を矮小化しすぎているだろうか? IT業界では、国際標準としてPMBOK Guide (R)の勉強と摂取が盛んだ。今から10年前には、「ぼくはプロジェクト・マネージャーなんかにされるのが嫌で、前の会社を辞めました。」という人がいたのだから、まあ隔世の感かもしれない。その人はシステム技術屋としての本分を捨てて、そんな雑用係にされるのはまっぴらごめん、と言っていたのだ。

ところで、この人の言う「雑用」と、わたしのいう「雑用」では、意味が少し違うことにお気づきだろうか? わたしは、顧客への納品物製作という直接作業(価値創造)につながらないものを雑用と呼んでいるのに対し、この人は、自分の技術的興味や満足につながらない仕事を雑用と呼んだのだ。この人にとって、データベース設計書作成やコーディングは楽しい仕事で、マニュアル作りやテストや顧客への報告は雑用だ。しかし、わたしの定義では、コーディングとマニュアル制作こそが直接作業であって、設計書などは雑用なのだ。ただ、その設計書はコーディングやデバッグの生産性を上げるから、雑用でも必要なのである。

PMPの有資格者が2万人を超えようという今日では、プロジェクト・マネージャーは「かっこいい仕事」にいつの間にか昇格した。交通警官などとはとんでもない。むしろオーケストラの指揮者か、映画の監督にでもたとえられる職種と思われているようだ。

ところが、その映画の世界には、『助監督』という職種があって、これがまさに雑用係なのだ。クルーのロケの切符を手配したり、宿舎を予約したり、俳優たちの用事をきいたり、とにかく何でも屋である。多くの映画監督はこれを経験しており、キャリアパスの一種になっている。

助監督の任務の中には、会社で言えば「総務」みたいな種類の仕事がある。配車や掃除や機材運びなどの雑用である。この種の仕事を、『アドミニストレーション』とよぶ。

また、助監督の仕事の中には、スタッフ間の都合や意見を調整したり、主張がかみ合わない場合は“とりあえずA案で進めますけど、天候がダメな場合どうするかは任せてください”みたいに判断をあずかったりする役割がある。この種の仕事を、『コーディネーション』と呼ぶ。

そして、撮影予定をスケジューリングしたり予算と出費の勘定をしたりといった、表やリストで追いかけるのに適した雑用がある。これを『コントロール』と呼ぶ。

プロジェクト・マネージャーの仕事とは、すなわち『アドミニストレーション』・『コーディネーション』・『コントロール』の三つの領域を包含した、采配の仕事である。とくに『コントロール』は数字化しやすいので、PERT/CMPだのEVMSだのといった技術手法が発達している。これらは一般に“管理技術”とよばれるものだ。データベース設計だとか応力計算といった“固有技術”とは別の領域である。「技術的なこと以外は雑用」と考えるエンジニアは、じつは管理技術というものの存在を理解していないのである。

とはいえ、プロジェクトは人間の集団がすすめるものであって、プロマネの仕事の中核には“人を動かす”という行為がある。これは技術論だけでは、なかなかうまくいかない。そこで、もっと属人的な『ソフトスキル』が必要となるのだ。

プロジェクト・マネジメントとは、こういう仕事である。しかも映画とは違って、世間に名前の出るケースはまずまれだ。それでも、なかなか面白い。かの留学生君が実際にやってみたら、どういう感想をもっただろうかと、ときどき考えることがある。あなたはやってみたいですか? 
by Tomoichi_Sato | 2008-04-22 23:29 | プロジェクト・マネジメント | Comments(0)

生産管理とはどういう仕事か

初めて会社に入って、配属の辞令をもらったときのことは、よく憶えている。ぼくらの会社では、新入社員は最初しばらく、本社で集合研修の日々が続く。皆で役員や先輩の話をきいたり、グループで討論したり、富士山の麓まで合宿に行ったり、工場見学に行ったり(エンジニアリング会社というのは工場作りが仕事のくせに、自分では工場を持たない)・・その間、みな自分がどの部署に配属になるのかは聞かされないのだ。それが一月近く続いた連休前のある日、初めて辞令の紙をもらい、所属の部署に挨拶に行く。

さて、自分の席に座って、与えられたのは仕事ではなく、問題だった。紙にきれいにプリントされた英文の問題が、図表もついて数十ページ。内容は、石油精製工場、つまり製油所の生産計画を立案する問題だった。ここで生まれてはじめて、生産計画という仕事に触れたのだ。

なぜ自分では工場を持たない会社のエンジニアが、生産計画を考えるのか。それは、工場の生産性を最大化するための必須の要素だからだ。工場は、原料を流し込んで、ボタンを押せば自動的に製品が出てくる場所とはちがう。製品の種類は何十とある。原料(原油)はじつは産地により性状が一定ではない。おまけに連産品といって、ガソリンもLPGもジェット燃料も、同時に一緒にできてしまう。マグロをバラしたらトロだけでなく赤身もカマもみんなとれてしまうようなものだ。どれか一種類だけ、つくると言うことができない(その比率はある範囲内でかえることができる)。だが、かえるためには装置の容量やランニング・コストも変わる。こうして、生産計画はいつのまにかひどく難しい問題になる。

その問題はうんうん唸りながら、二週間かけてやっと解いた。手計算だが線形計画法(LP)の手法も使う必要があった。制約条件がきつくて、実行可能な解を得るのが至難の業に思えた。しかし、おかげで、生産というものの構造がすっかり頭に入った。目的も、条件も、制約も。つまり、先輩たちが意図したとおりの教育効果があったわけだ。

生産管理とは、工場の生産性を最大化する活動のことだ。ところで、『生産性』とは何だろうか? この問題は、案外正しく答えられる人が少ない。こういう点が企業の不思議なところだ。目的が与えられているのに、その目的の正確な意味をよく知らないまま動いている。しかし、いわゆる経営工学やマネジメント理論では、生産性は単純・明快な定義が与えられている。それは、こういう式だ。

    [産出量]
生産性=--------
    [投入量]
    
実に単純である。ただし、どこにでも当てはまるよう一般化されすぎていて、生産の現場では誤解を生みやすい。

一番ありがちな誤解は、産出量は生産数量で、投入量は原材料数量である、という誤解だ。あるいは、産出量は生産金額、投入量は原価、という誤解もある。前者は、収率ないし歩留とよばれる量だし、後者は売上高原価率(の逆数)にすぎない。

正しい定義は、こうである:

    [付加価値額] [売上高-外部購入費用]
生産性=------------ = ----------------------
    [投入労働量]   [投入労働量]

これを正確には付加価値生産性と呼ぶ。分母の労働量は、従来は従業員数で示すのが通例だったが、最近はパートタイム・派遣工や工場内外注や偽装請負などがあって、正確な指標ではなくなってしまった。そこで、直接労働時間をとることもしばしば行われる。

付加価値とは、購入してきた材料を変形・加工・組立することによって生まれる。これを製造の直接作業とよぶ。生産管理の仕事とは、すなわち、直接工の人たちが、いかに無駄なく、効率よく仕事できるかをお膳立てし、サポートする仕事である。そのために、何をどの順序で作るかをきめ、それにしたがって材料や部品や機械や治具を供給し、作業の依頼を出し、トラブルがおきたらすばやく解決する。これが生産管理だ。

生産管理を「生産のマネジメント」だととらえると、なんだか偉そうな、立派そうな仕事に聞こえる。製造現場に命令・采配するような印象がある。それは誤解である。生産管理とは、高校の運動部のマネージャーのような存在だと思った方が良い。主役は、モノに加工を行って付加価値を生じせしめている直接工の人たちである。彼らがプレイヤーなのだ。マネージャーはプレイヤーが気持ちよくプレーできるように、雑用を承る役割である。

そうしたサポート的な役割なのに、なぜ、現場に指示や依頼を出せるのだろうか。なぜ、そもそもそんなサポート役が必要なのだろうか?

理由は二つある。第一に、「生産工場は大きなシステム」だからである。大きなシステムは、どこを押したら、どこがどう加速するのか、あるいは引っ込むのか、簡単ではない。工程・資源・要員・材料・スペースなどの要素が複雑にからみあっている。これをよく知った上で運転する人が必要なのだ。単に材料をどばどばと第一工程につぎ込めば生産性が上がるわけではない。

第二の理由は、第一ともからむが、要素が多くて、頭だけでは考えきれず覚えきれないからだ。だからITなどの道具を使って、何がいくつどこにあって、いつ使われる(使われた)かを計算する必要がある。この職種が分業の結果として生まれたのだ。

生産管理とは、そういう仕事である。あくまで、サポーターであり雑用係とも言える。生産管理部の人間は、付加価値を産出する仕事には実際にはタッチしない。つまり、ある意味では余計なスタッフなのである。しかし、彼らの仕事が、製造現場の生産性を向上させるなら、そこには意義が生ずる。200人の工場に、10人の生産管理部員がいたとして、その努力によって直接労働の生産性が5%以上あがれば、それは必要な仕事なのだ。ただ、それは主役ではないということを忘れてはいけない。
by Tomoichi_Sato | 2008-04-09 23:49 | サプライチェーン | Comments(1)

製造業の業務範囲とソリューションMAP

一般に企業のビジネスには、計画-実行-評価(Plan - Do - See)のマネジメント・サイクルがある。製造業における生産のマネジメントにおいては、このサイクルが
 (1) Plan 「生産計画」
 (2) Do 「製造指示・監視」(生産実行)
 (3) See 「実績報告」
にそれぞれ対応すると考えて良い。

なお、生産の実行がカッコの中に入っているのは、それが“マネジメント”の範囲に入らないからである。製造業の付加価値は、生産の実行、すなわち加工や組立などの「直接作業」によって生み出される。マネジメントは間接作業であって、それ自体では何も価値を生み出さない。しかし、直接作業である生産実行を、効率的に運営することを助けている。これによって、間接的に価値をもたらすのである(つまりマネジメントは生産現場を支える存在であって、「現場より上」の仕事ではない点に注意)。

生産のマネジメントには、年・半期単位のサイクル、月単位のサイクル、日単位のサイクルなどが存在する。これらサイクルは、「半期予算会議」「月次生産会議」「毎朝の工程会議」などの会議体によって回されることが多い。伝統的に日本企業は月給制であり、受発注も月締め決済が中心なので、月次が主となっている(米国は週給制であり、週次サイクルも重視されるが、日本では月またぎをきらう)。また日よりも短い単位で回すこともある。

製造業のマネジメントでは、あつかう情報の種類も量も多い。製品の品種も多く、部品点数はもっと多く、工程数も要員数も保管場所も多い。それぞれに、過去の実績と未来の予定が紐付いている。だから、手作業だけでこれを追いかけようとするとすぐにパンクする。そこでコンピュータによるシステムが道具として必要になるわけだ。

生産のマネジメントを支える情報システムのソリューションの位置づけを、上述の枠組みで考えると

 (1)計画系ツールとしてのSCMソフト(特にスケジューリング・ツールであるAPS)
 (2)現場実行系ツールとしてのMESソフト(製造管理ないし製造実行システム)
 (3)本社でのトランザクション管理および実績評価ツールとしてのERPソフト

に区分できる。これらは、Plan-Do-Seeのワークフローを形成していることが望ましい。

なお、製造業は固体製品を中心としたディスクリート系と、流体製品を中心としたプロセス系に大別することもできる。電機や自動車や食品は前者であり、ガスや化学や飲料は後者である。後者では人間より装置が製造の中心となる。そして、秒単位の制御が必要となる。これを統括するために、

 (4)制御システムとしてのDCSソフト

が必要となる(PC+PLCで実装するケースもある)。

さらにいうならば、生産に隣接する業務範囲として、物流および購買がある(会社によっては同一組織で動かされる)。そこで、これも図で示すことにしよう。
 (5)物流実行系ツールとしてのWMSソフト
 (6)購買伝達系ツールとしてのWeb-EDIソフト

これらを大まかにマッピングすると次の図ができる。これが製造業の業務範囲とソリューションのMAPの姿である。サプライチェーンに関連する情報システムの位置づけは、ほぼこの図でカバー可能であると私は考えている。
e0058447_2233611.gif

by Tomoichi_Sato | 2008-04-01 22:33 | サプライチェーン | Comments(0)