<   2007年 12月 ( 3 )   > この月の画像一覧

Chirstmas メッセージ--運命共同体として

私の勤務先は70-80%が海外向けの仕事だ。20年以上前に入社したときから、この比率はあまりかわっていない。ずっと、世界市場で直接の競争を生き延びてきた。しかし、仕事のやり方はそれなりに変わってきたと思う。一番の変化は、海外企業との共同プロジェクトが増えたことだ。昔は一社単独で元請けになり、国内や海外のメーカー・工事業者をつかうやり方だった。いまでは半分以上のプロジェクトが、海外のエンジニアリング会社との共同遂行で行われている。

こうなった理由はいろいろある。プロジェクトの規模が大きくなりすぎて、単独で請け負うにはリスクが大きくなりすぎたのも一因だ。プラントの値段はこの10 年間で2倍以上にはね上がり、1案件2000億円以上のジョブが珍しくなくなってしまった。それ以外に、日本人エンジニアのマンアワー単価が高いため、南欧や中進国の比較的安価な会社と組んで価格競争力をねらう、という面もある。

こうした海外企業との共同プロジェクト遂行におけるリスク因子については、今年の初めにプロジェクトマネジメント学会誌に同僚の秋山氏と論文を書いたので、興味のある方は読んでいただきたい。そこで私たちが強調したのは、「文化の差は主要な問題ではない」ということだった。

カルチャー・ギャップが主要な問題でなければ、何が問題なのか。それは、一口で言うと『フォーメーション・デザイン』である。もう少し具体的に言うと、相互の協力関係をいかに契約とスコープ分担に反映させるか、という問題だ。

同一プロジェクトを共同遂行するときに大事なことは、参加する会社が利益共同体の関係になり、同じ方向を向くことだ。全員が同じボートに乗って、利益の浮沈をともにする。そのためには、内部で利益背反がおこらないよう、協力関係の仕組みを最初にうまく設計する必要がある。

共同遂行には一般に、ConsorciumとJoint Ventureの二種類がある。Consorciumは、お互いが別々の財布を持ち、分担を切り分けて遂行する。いわば独立採算制だ。この方式は単純でよいが、残念ながら、プロジェクト遂行の途中で発生した境界線上の問題は、互いに押し付け合いになりがちだ。パートナーが損をしても、自社が得をすればよい--こんな風潮が許されると、プロジェクトは難関を乗り切れなくなる。

そこで生まれたのが、Joint Venture(J/Vと略す)による、profit/loss shareの考え方だ。これは、複数の会社がプロジェクトで共通の財布をもち、得をしても損をしても、お互いにシェアしましょう、という仕組みである。J/V体制の元では、プロジェクトに問題が発生した場合、たとえ原因がどちら側にあるにせよ、それを解決するために協力して動くようになる。皆が一つの方向を向くのである。つまり、真の利益共同体になるのだ。

最初にこのJ/Vによるprofit/loss shareの契約方式を知ったとき、ずいぶん感心した。なるほど、これが欧米流の大人の考え方というものか、と思ったものだ。実際にJ/Vを遂行するとなると、いろいろと方式や思惑など面倒なセットアップがあるのだが、それでも複数の会社を一つの利益共同体にすることのメリットには代え難いと感じる。

ところで、私が生産スケジューリングやサプライチェーン・マネジメントの分野に取組み出してから常々思うのは、この方式を一つの会社の中でも使ってみたらどうか、ということだ。なぜなら、製造業ではしばしば、部門間がちっとも利益共同体として働かないからだ。生産と販売、需要と供給を同期化することがサプライチェーン・マネジメントの根幹である。それなのに、たいていの会社では、この両者は仲が良くない。なぜか? それは、両者が別々のモノサシで、いわば別会計で動いているからだ。そこで、つねに問題の押し付け合いが生じてしまう。 Consorciumと同じだ。

それならば、営業と生産がJoint Ventureと同じように、Profit/Loss shareを取り決めればよいはずである。売価から、仕入れた値段を差し引いた、会社で産み出した付加価値総額を、営業部門と生産部門がシェアする。比率は50:50でもいいし、40:60でもいい。それは社内の取り決めである。営業が高い値段で販売できたら、その利益を工場も甘受する。だから技術部門は客先のニーズや悩み(ペイン)をうまく解決できるような製品機能を工夫する。また、工場が生産性を上げたら、営業も成績がアップする。そこで、営業は無理な割込み注文をとって生産計画や購買手配を混乱させない。そう動ければ、ベターではないか。

いや、そもそも会社というのは、そういう風に動くはずのものではなかったか。それなのに、なぜ営業はシェアと売上高ばかりを追い、工場はサプライヤーに単価低減/短納期の無理難題を押付ける存在になってしまうのか? なぜ、問題を、自分のいるサイロの外側に投げ出すだけでこと足れりとしてしまうのか。

それは、「自分たちは利益共同体である」という基本的な事実を忘れて、部門業績ばかりを追いかけるからである。また、それを促すような、評価基準や成果主義がはびこるからである。これを断ち切るには、一度ためしに、各部門から人を出して、部門横断的な小さなプロジェクトを進めてみると良い。プロジェクトの成果は、参加者全員の成果とする。そうしたら、部門間で経費の押し付け合いをしている暇はなくなる。互いに、相手の立場で考えることができるようになるはずだ。そう。同じボートに乗った仲間ならば、みな運命共同体なのだ。

さて、ここまで考えてみて、気づいたことがある。それは、私たちの地球もまた、運命共同体ではないか、ということだ。それを、目に見えもしない地表の境界線で分断して運営して、本当に皆が満足し納得できるのだろうか。

今年、日本はまた「記録的な気象異常」をあちこちで記録した。それは日本ばかりではなく、今年ばかりでもない。私たちは今、ちっぽけなボートに一緒に乗っていて、その船には何かきなくさい煙が立ちこめはじめている。もう一度言おう。私たちは、同じ船に乗っている。運命共同体なのだ。ならば、世界がひととき活動を休めて平和を願うこの季節に、さまざまな国に住む人々が、分断されずに、同じ目的を目指して生きるにはどうすべきかを、せめて考えたいと願うのである。
by Tomoichi_Sato | 2007-12-22 23:51 | サプライチェーン | Comments(0)

良いWBS、わるいWBS

先日、プロジェクトマネージャ合格論文集 改訂版(齋藤登志勝・編、リックテレコム刊)の読者の方からご質問があった。内容は、小生の執筆した論文で「・・・WBSを成果物(サブモジュール)中心ではなくプロセス中心に構成した・・・」と記載しているが、WBSの構成を変更した意図がわからない。WBSの構成変更のメリットは何か? というご質問である。

これはとても良い質問だと思うので、ここに取り上げさせていただこう。ここには、WBS(Work Breakdown Structure)構築の中心課題があるからだ。最近WBSという用語・概念が業種の枠を超えて広まったのは、とても良いことだと思っている。しかし、その結果(?)、奇妙なWBS、不思議なワークパッケージを見かける機会もでてきたように感じる。この論文では、その点をやんわり取り上げたつもりだった。

WBSは、誰でも作れる。プロジェクトを種々の作業の階層構造に展開することは、ちょっと頭が働く人間ならば、可能である。しかし、時計を部品に分解していくのとちがって、展開のやり方には、いろいろなアプローチがありううる。つまり良いWBSも、わるいWBSもありうるのだ。後者を作ってしまうと、その後のプロジェクト・コントロールが混乱しがちになる。

米国PMIは"Practice Standard for Work Breakdown Structures"というモノグラフを出している(2001年刊)。本文がたった18頁で、付録が58頁もある、珍しい本だ。本文では、WBSの説明として、PMBOK Guideを引用して、"A deliverable-oriented grouping of project elements"だと書いている。このまま訳すと、『プロジェクト要素の、成果物指向によるまとめ上げ』ということになる(ちなみにPMBOK Guide第3版では"A deliverable-oriented hierarchical decomposition of work")。

前の「WBSのつくり方」にも述べたように、WBSへの分解は大別して、成果物中心と、プロセス中心の方法がある。両者は一長一短あり、成果物中心は“もれなく・重複なく”ワークを数え上げるのには適している(いわゆるMECEな展開だ)。後者はWBSのマスタを作りやすいという長所がある。そして、PMIの本は前者を推薦しているように見える。しかし、この本の付録にあげられた、数々のプロジェクトのWBS例では、必ずしも、いや、ほとんどがそうなっていない。たとえばAppendix OにはSoftware Implementationの事例がついているが、Level 1をリストアップすると、
1 Project Management
2 Product Requirements
3 Detail Software Design
4 System Construction
5 Integration & Test
という具合だ。私が本の論文に書いた事例とよく似ている。でも、いったい何故こうなのか?

じつは、このモノグラフの本文第4章には、WBS作成上の留意点がいろいろと説明されている。その一つに、「WBSが作業間のロジカルな依存関係を十分規定していること」という要件がある(ロジカルな依存関係が何かについては、『ロジック・ネットワーク・スケジュールとは何か』を参照してほしい)。また、「すべての作業は、見積・配員・スケジュール・予算化が行われ、コントロールされなければならない」とも書かれている。WBSを作成する目的はプロジェクト・スコープを、コントロール可能な作業要素に分解することにある。このとき、WBSはあくまでも、枝葉だけではなく木や森が見えるようになっていなければならないことを、この節は告げている。

これはすなわち、コストやスケジュールの進捗実績情報を集計していくときに、WBSの構造にしたがってロールアップされるということだ。だとしたら、プロマネであるあなたは、基本設計→詳細設計→実装、という方向で進捗やコストを見たいのか。あるいは、画面モジュールA・画面モジュールB・帳票モジュールC、という風に見たいのか、ということに帰結してくる。

もしも大規模なシステムを開発していたら、基本設計の全体性integrityが固まらないうちに、いくつかのモジュールの詳細設計に進むことなど、普通は許さない。そんなことをしたら、あとで設計の手戻りの危険性が高くなる。だから、プロセス中心のWBSが望ましいのだ。これが、パッケージソフトのマイナー・バージョンアップ程度の仕事なら、ばらばらにモジュールに手を入れてもかまわないだろう。だから、成果物中心WBSでもまったく問題ない。

ちなみに余談だが、中国のオフショア開発で私が経験した事例では、個人がそれぞれ決められたスコープの縄張りの中で(他人は一切お構いなしに)猛スピードで突っ走っていく仕事のやり方だった。これがその会社だけの慣習なのか、あるいは中国全体に共通するマネジメント・スタイルなのか、即断は避けたい。しかし、このような状況では、個人別にモジュールを渡し個人単位にWBSを切って進捗を稼いでいたら、統合テストがめちゃくちゃになるのは目に見えている。

PMIのモノグラフの付録は、実務家が集まってワークショップ形式で作り上げたものだ。だから、おのずからコントロールの方向性が定まっているのだろう。それは、たまたまかもしれないが、プロセス指向がメインだった。とくに、目に見えないものを作り上げるプロジェクトでは、最初はなかなか航空機の部品表のように構造は決められない。したがってプロセス指向にならざるをえないのである。WBSの良しあしが、プロジェクトを左右する--ここが、プロジェクトマネジメントの難しさでもあり面白さでもあるのだ。

(末筆ながら、本参考書の編著者である齋藤登志勝先生は本年11月、若干42歳の若さで急逝された。人柄・能力・経験、いずれの点でも惜しまれてあまりある人材だった。先生のご冥福をお祈りしたい)
by Tomoichi_Sato | 2007-12-12 22:51 | プロジェクト・マネジメント | Comments(3)

(書評) "The Organization And Architecture of Innovation" by T. Allen and G. Henn

The Organization And Architecture of Innovation: Managing the Flow of Technology

イノベーション、すなわち革新的なアイデアを生み出すための組織と空間をどうデザインすべきかを論じた、画期的な本である。著者は、米MITスローン校(MITのビジネススクール)教授のであるAllenと、ドイツの指導的建築家Hennの二人で、このユニークな組合せが本書の性格を見事に物語っている。彼らはこれまで誰も手をつけなかった、組織構造と空間構成がイノベーションに与える影響について、緻密なデータと実績をもとに論じる。本書の知恵をうまく生かせば、知的生産性を倍にすることさえ、おそらく夢ではないだろう。

その実証例が、本書にも紹介されているBWM社の開発センターProjekthausや、シュコダ社の工場である。自動車工場のレイアウトなら日本がトップだと信じる人は、2本の製造ラインの中央部に管理部門を並べたチェコの工場や、オフィスの中をアセンブリーラインが貫通しているドイツの工場などを、日本の自動車業界トップが最近さかんに見学に行っていることを知るまい。その理由はまさに、労働生産性だけでなく知的生産性がものづくりの企業で重要問題となってきたからだろう。

イノベーションとは未知なるものの創造であるのに、それを産み出すプロセスをデザインできるのか? 誰しもそう疑問に思うにちがいない。その答えは『気づき』(awareness)と『コミュニケーション』にある。未知なるものを計画することはできないが、創造のきっかけを作り出すことはできる。そのための主要なツールが、組織構造のデザインと空間のデザインである。大学・企業・研究所など、イノベーションを求める機関はたくさんあるが、これまで組織と空間が知的創造性に大きな影響を与えるという問題意識は希薄だった。

(これは余談だが、近年、世界規模で医薬品企業の大合併が進行している。その目的はR&D組織を統合して知識を共有し、新薬開発のイノベーションを加速することにあったはずだ。しかし調べてみると、米国FDAへの承認申請は決して10年前に比べて増えていないという。単なる人と予算の足し算だけでは、知的生産性を加速することはできないことの証左になっている)

著者の一人Allenは元々ロッキード社の開発エンジニアだった。彼は製品の研究開発という手つかずで困難な分野を対象に、長年地道な調査を行ってきた。組織構造が企業内のコミュニケーションに影響を与えるだろうことは、だれしも容易に想像がつく。しかし彼は、空間構成とコミュニケーションの頻度に着目して、“50m理論”ともいうべき法則性を見いだす。それは、同一部署に属していても、物理的空間距離が50m以上離れた二人は、事実上コミュニケーションをとらない(たとえeメールでも)という事実である。

Allenによると、コミュニケーションには三つの種類がある。Coordination(調整)・Information(情報伝達)・Inspiration(ひらめき)の三つだ。このうち、イノベーションの決め手となるのは『ひらめき』であり、それは『気づき』のきっかけによって生まれる確率が決まる。組織や空間デザインはこれを左右することで、知的生産性を拡大もするし低下させもする。しかし企業の上級管理者達は、この事実にあまりにも無頓着である。

Allenはさらに、製品開発における組織のあり方について、機能別組織・プロジェクト組織・マトリクス組織の類別と特性を述べる。本章は、私がこれまで読んだプロジェクト組織論の中でもっとも優れた説得力のある解説であった。後半ではさらにHennが、建築的観点から空間構成に必要なspine(脊索)の概念と実例を説明する。美しい建築写真が並ぶが、本書は建築家向けの本ではない。むしろ、建築家が論理性ぬきで美的外観を追う愚を戒め、設計の背後には科学的法則に基づく論理が無くてはならないとの主張がある。

これは、イノベーションを求めながらそれを果たせずにいる今日の我々の盲点を教えてくれる、真に創造的な本である。英文は比較的易しい。また、近々邦訳がダイヤモンド社から出版される予定である。研究開発やものづくりにたずさわる、すべての知的職業の人に強く推薦する。
by Tomoichi_Sato | 2007-12-04 00:00 | 書評 | Comments(0)