<   2013年 03月 ( 6 )   > この月の画像一覧

「リスク確率に基づくプロジェクト・マネジメントの研究」を出版しました

わたしが2010年6月、東京大学に提出した博士論文「リスク確率に基づくプロジェクト・マネジメントの研究」が、静岡学術出版からDVDの形で出版されました。

プロジェクト価値分析とリスク評価を統合した、マネジメントのための新しい理論的フレームワークを提案したもので、全7章から構成されます。

イントロダクション--どのような研究がなされなければならないか
第1章  リスク基準プロジェクト価値
第2章  プロジェクトの最適予算
第3章  リワークと不完全な遂行
第4章  プロジェクト意志決定への理論的応用
第5章  エンジニアリング・プロジェクトにおけるケーススタディ
第6章  まとめと展望

とくに第1章は論文の中核となる「貢献価値」の理論を述べたもので、「リスク確率」という概念を用いると、プロジェクトを構成する個々のActivityが、全体の価値に対してどれだけ貢献しているかが計算できてしまうというロジックを説明しています。「コロンブスの卵ですね」と、東大の論文審査会で評された部分です。

ちなみに、わたしの調べた限り、東大で「プロジェクト・マネジメント」一般を主題に真っ向から研究した博士論文は、これが最初です。

工学系の論文ですので、数式もいろいろ出てきますが、それほど高度なものはありません(せいぜい学部生レベルの数学です)。たぶん論文としては、かなり読みやすい方だと思います。

価格は税込み840円です。Amazon.comからも購入できます。
 リスク確率に基づくプロジェクト・マネジメントの研究 【知の偉産シリーズ】理工00005

プロジェクト・マネジメント論にシステム工学を適用する方法に興味がある方、プロジェクトの選択・評価・撤退の基準を学びたい方、著者が能力不足でやり残した問題に挑戦したい方、「なーんだ、東大の学位論文といってもこの程度か」と冷やかしてみたい方、皆様ぜひお手にとって見てください。


佐藤 知一
by Tomoichi_Sato | 2013-03-28 21:30 | プロジェクト・マネジメント | Comments(0)

納期が延びる要因を指標化する - スケジュールのDRAGとはどんな尺度か

久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。

いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の6つの作業項目(アクティビティ)のみからなると考える。

1. 基本設計  (推定所要期間=20日)
2.1 ハード調達 (推定所要期間=35日) 先行作業:基本設計
2.2 設置調整  (推定所要期間= 5日) 先行作業:ハード調達
3.1 詳細設計  (推定所要期間=10日) 先行作業:基本設計
3.2 ソフト開発 (推定所要期間=20日) 先行作業:詳細設計
4. 総合テスト (推定所要期間=15日) 先行作業:設置調整、ソフト開発

さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネットワーク・ダイアグラムで表す流儀にはいくつかあるが、ここでは一番広く用いられている図法を使う。Precedence Diagramなどと呼ばれているもので、作業項目を四角形で表し、その順序関係を矢印で示す。

e0058447_2364470.gif


(図1 作業項目の順序を示すネットワーク・ダイアグラム)

ただし、ここでちょっとした約束事がある。四角形の中心に作業項目の名前を書き、その下に所要期間の値を書く。それ以外に、左上・左下・右上・右下に、それぞれ小さな欄を置いておく。ここに、あとで数値を計算して記入するのである。記入するのは、以下のような項目だ。

左上:Early Start (ES=最早着手日)
右上:Early Finish (EF=最早完了日)
左下:Latest Start (LS=最遅着手日)
右下:Latest Finish (LF=最遅完了日)

これらはそれぞれ、「最も早く着手できる日」、「最も早く完了できる日」、「最も遅く着手できる日」「最も遅く完了できる日」、の意味だ。この4つは、スケジューリングにおける最も基本的な概念であるから、覚えておいてほしい。

さて、頭のいい人なら、図1をちょっとにらんだだけで、全体の納期がいつになるか計算できてしまうだろう。しかし、ここでは一応説明のために、愚直に手順を追っていくことにする(それに、どんな頭がいい人でも、作業要素が50個も100個も並んでいたら、やはりすぐには答えが出るまい)。

まず、最初の作業(「基本計画」)からはじめて、順に後ろの作業の日程を考えていく。基本設計の最早着手日を、0日とする。最早完了日は20日だ。後続するハード調達の最早着手日も20日になる。その最早完了日は20+35 = 55日、という具合に、前から後ろに順に計算していく。このような手順を、「フォワード・スケジューリング」という。

ところで、最後の「総合テスト」には、設置調整とソフト開発の二つの先行作業があり、異なった最早完了日がある。どちらをとるべきか? --いうまでもない。「総合テスト」は両方がそろわなければ着手できないのだから、遅い方(数字の大きい方)の最早完了日を,自分の最早着手日として記入する。

ルール1:複数の先行作業がある場合は、その最早完了日の大きい(遅い)方をとって、自分の最早着手日とする

こうして、全作業項目のESとEFが計算できた。これが図2だ。これを見ると、総合テストは最も早くても75日たたないと完了しないことが分かる。これが全体の納期だ。ただし、話はまだつづきがある。

e0058447_23142952.gif


(図2 最早着手日と最早完了日)

次に、最後の作業項目から逆順に、最遅完了日と最遅着手日をさかのぼって計算していく。これをバックワード・スケジューリングとよぶ。後続の最遅着手日を、自分の最遅完了日に記入し、そこから所要期間を引き算して、自分の最遅着手日を求める。

ここでまた、「基本設計」のように複数の後続作業のあるものがでてくる。ハード調達の最遅着手日=20日、詳細設計の最遅着手日=30日だ。この場合、ハード調達は遅くても20日にはスタートしなければ間に合わないのだから、基本設計の最遅完了日は20日になっていなくてはならないことがわかる。

ルール2:複数の後続作業がある場合は、その最遅着手日の小さい(早い)方をとって、自分の最遅完了日とする

この結果、すべての作業項目の4つの箱がうまった。さて、ここで、左上=左下、となっている作業項目を拾い出す。これは、“最も早く着手できる日=遅くてもその日にスタートしないと間に合わない日”になっている、まったく日程的余裕のない作業だ。このような作業のならびを、『クリティカル・パス』と呼ぶ。日本語では、隘路という。図3では、そのクリティカル・パスを赤い矢印でマークした。

e0058447_2393173.gif


(図3 全体の日程とクリティカル・パス)

ちなみに、左上<左下、となっている作業項目は、着手に日程上の余裕があるわけだ。たとえば詳細設計は、20日に着手可能だが、30日に着手しても間に合う。この余裕を、英語で"Float"と呼ぶ。

ルール3:「最遅着手日-最早着手日」の値がFloat(余裕日数)を表す

クリティカル・パスとはすなわち、Float=0日となっている作業項目の系列のことだ。そして、お仕事の全体納期は、クリティカル・パスの長さに等しい。これを短くしない限り、納期は早まらない。逆にいえば、Floatのある作業項目は、それ自体をどんなに頑張って早く仕上げても、全体の納期には何も貢献しないことになる。だから、プロマネは、かならず何がクリティカル・パスかをしっかり把握して、管理を底に集中させなければならない。

スケジューリングの世界で一番特徴的なことは、このように「大事な作業」と「大事でない作業」がくっきり分かれることである。これは、コスト管理の世界と全く異なる。コストはすべて足し算の世界で成り立っている。だから、どこかの作業項目で1円でも安くすれば、全体が1円安くなる。しかし、スケジューリングの世界では、Floatをもつ作業項目をいくら頑張ったって、何の足しにもならないのである。

さて、ここまではある意味、基礎だ。ところで、では、「大事な作業」は、“どれくらい大事”なのだろうか? ここで、DRAGという指標が出てくるのだ。

DRAGとは、ある作業項目が、全体の納期をどれだけ後ろに押し下げているかを示す尺度である。たとえば、Floatをもつ作業項目は、DRAGはゼロになる。上の例では、詳細設計やソフト開発はDRAG=0になる。他方、クリティカル・パスに乗っていて、しかも並行する作業のないもの、たとえば基本設計や総合テストは、その所要期間全部がDRAGになる。その所要期間分、納期を押し下げているからだ。そして、これらの要素は、その所要期間を短くすればするほど、納期は早くなる。

問題は、クリティカルだが、他にも並行する作業のある項目だ。たとえばハード調達や設置調整である。これらに並行する詳細設計→ソフト開発の系列は、10日のFloat日数を持っている。そこで、たとえばハード調達を5日短縮すれば、5日だけ、10日短縮すれば、10日だけ、全体納期が短くなるが、それ以上短縮すると、逆に並行する系列の方にクリティカル・パスが移ってしまうため、もはや納期には貢献しなくなる。その限界が10日なのである。そこで、ハード調達のDRAG=10日になる。

設置調整の方は、そもそもが5日の所要期間しかない。並行する系列のFloat:10日よりも短い。だから、5日まで減らせば、その分は納期が前に倒れる。設置調整のDRAG=5日だ。

整理すると、以下のようなルールになる:
(1) Float日数を持つ項目は、DRAG=0日
(2) クリティカル・パス上にあり、かつ他に平行作業がない項目は、DRAG=それ自体の所要期間
(3) クリティカル・パス上にあり、平行作業がある項目は、DRAG=その並行作業系列のFloat日数
(4) ただし、その所要期間自体が平行作業のFloat日数要理小さいときには、DRAG=それ自体の所要期間

この結果を図示したものが図4だ。

e0058447_23114944.gif

(図4 DRAGの値)

DRAGの値が分かると、何か得るところがあるのか? あるのだ。DRAGは、その作業項目が、どれだけ納期を押しているかを直接表す。逆に、納期を早めたかったら、DRAG値の大きな作業項目をまっ先に攻めるべきである。その重要度が、一目瞭然になる。

DRAG値はある意味、その仕事全体が、どれだけ並列性から外れているかの尺度でもある。仕事を早めたかったら、独立した部分に分けて並列にすすめるしかない。これはどんな仕事でも(ピラミッドの建設でも、コンピュータ内部の計算プロセスでも)適用できる真理である。DRAGは、どこに並列性から外れた部分があるかを明確に示す。

まあ、この例はたった6個かそこらの作業項目だから、DRAGなど計算しなくてもじっと考えれば、攻めるべき箇所は分かる。しかし、これが60個だったら、あるいは600個だったら、もう目では分かるまい(ちなみに、わたしの勤務先で扱うスケジュールでは、Activity数=600個は少ない方である)。

むろん、DRAGにせよ、クリティカル・パス法にせよ、批判しようと思えばいろいろと限界はある。静的な分析にすぎないとか、作業項目の所要期間がそんな1点見積で正確に見積られるか、とか、リソースの負荷上限が考慮されていない、などなど。ただ、忘れてはいけないことがある。それは、スケジューリングとは元々、様々な仮定をおいて作成した近似モデルに過ぎないということだ。モデルとはつねに単純化を伴うものである。だが、単純化することで、見えやすくなる事もあるのだ。シンプルな道具は、使い所を知った上で、シンプルに使えばきちんと威力を発揮する。スケジューリング手法も同じで、いつ、どう使うかが知恵なのである。

さらにいうと、DRAG指標はさらにコストを加味すると、さらにぐっと使い勝手を増す。しかし、いつものように長くなりすぎた。それについては項をあらためてまた書こう。
by Tomoichi_Sato | 2013-03-25 23:18 | 時間管理術 | Comments(0)

ガバナンスの最適設計を考える

少し前のことだが、メディア系のWebサイトを見ていたら、部下の使い方に関するなかなか興味深い記事を見つけた。著者は外資系経営コンサルティング会社の人で、自分が初めて部下を使う立場になった時に、放任し過ぎたり指示しすぎたりして失敗したという話だった。結局適切に仕事を委譲しながら、成功した時は部下の手柄にし、失敗した時は自分が責任を取るようにすることで、最終的に部下のモチベーション高め、いい企画を量産できるようになったという。“量産された経営企画”なんて受け取って、はたしてクライアントは嬉しいのかという問題はさておき、部下のマネジメントの仕方という点では賛同できるところの多い記事だった。

ただし読んでいて少し疑問に思ったこともあった。そもそもマネジメントの本来の原義は、「人を動かして目的を達すること」である。部下の使い方は、その意味でマネジメントの基本中の基本である。その著者は金融業界出身で経営コンサルタントに身を転じ、 MBAの資格も取っていた。にもかかわらずマネジメントの基本については、何も知らななかったということになる。マネジメントの基本を知らない人が、なぜ他人の会社経営については助言できると思えるのだろうか?

ここ何回か、ガバナンスの問題について続けて考えてきた。ガバナンスとは、ある程度の自立性を持つ相手を、自分の利害関係に沿った形で動かすための仕組みである。子会社を動かす場合がその典型だし、社内の組織や部門を動かす場合もその一つである。マトリクス型組織の中で、いろいろな機能部門をプロマネが動かす仕組みを、プロジェクト・ガバナンスとよぶこともある。自分の部下だけで完遂できる中小規模のプロジェクトと違い、クロス・ファンクショナルな仕事では、どうしても直接の命令権の及ばぬ部門にも動いてもらわねばならぬ。

先にあげた、部下をどう動かすかという問題も、ガバナンスとかなり共通した面がある。もちろん個人と組織では大分違うわけだが、自由放任だけでも厳格な指示命令だけでも、なかなかうまくいかない点は共通している。では、適切なガバナンスのあり方とは、どのようなものなのだろうか。

このサイトでは、まず、ガバナンスには3つのレベルがあるという話を書いた(『ガバナンスと自由の3つのレベル』)。3つとは、中央集権型承認型、そして可視化型である。ガバナンスの強さはこの順に弱くなる。そして、さらに外側に自由放任型が来る。いろいろなガバナンスのあり方は、この類型ないし尺度のどこかに定置できそうだ。

その次には、国と地方自治体のガバナンスの関係について書いた(『ネストする地名の謎』)。明治に成立した近代日本のガバナンス体制は、国が都道府県に自治権をあまり与えぬ中央集権型であった。その手段として、恣意的な合併や、名称の操作なども利用した。このような制度設計は官庁・民間問わず、その後の日本の組織に大きな影響を与えたに違いない。

さらにそこから派生する話題として、コストセンターとプロフィットセンターの区別について考えてみた(『コストセンターとは何か』)。コストセンターとはお金だけかかって、何も生みださぬ組織であるかのように誤解されている。しかし経営学的に考えれば、コストセンターとはコストとサービスレベル(品種・納期など)に対して管理責任を持つ組織である。サービスレベルがきちんと定義されないと、コストセンターはただただコストダウンを要求されるだけの、自律性のない組織になってしまう。

さらに言うと「コストセンター子会社」という呼び方は、会計学的には間違いだ。この言葉は多くの場合、親会社からの収入に100%依存している機能子会社のことを、暗に指している。そして外販比率が高くなると、子会社は「プロフィットセンター」と呼んでもらえるようだ。プロフィットセンターになりさえすれば、少しは格が上がり、親会社からのうるさい干渉をはねつけやすくになる、と理解している向きも多い。「コストセンター」の用語を、このように妙に差別的な意図で使うのはおかしいと思うが、世の中に横行しているのは事実である。

では、これら一連の考察から見えてきたものはなんだろうか? なぜ「コストセンター」論と、一見無関係なガバナンスのあり方が、一つながりのものとして意識されるのか。そもそも企業ガバナンスの原義が、「企業経営の方向性を、株主の利害に一致するよう保証する仕組み」であるならば、子会社の株主は親会社なのだから、どこまで口をはさんでもかまわぬ、適切な限度など無い、という結論になりはすまいか。

ここで問題となるのが、中央集権型ガバナンスの限界ないし短所である。短所は二つあった。まず、あらゆる判断が上位の決定に委ねられるわけだから、上位側の情報処理能力がかなり高くなければいけない。かつてフセイン大統領時代にイラクに住んでいた研究者から聞いた話だが、生活上の、アパートの不都合か何かを知人にこぼしたところ、「だったら大統領府に直接かけあえばいいじゃないか」と言われたという。これを聞いて、独裁者というのはひどく忙しいものだな、と思った。あらゆる細かな問題や雑事が上がってくるのである。ナポレオンの睡眠が3時間だったというのも、たぶん寝ているヒマがなかったのではないか。

中央集権型のもう一つの欠点は、現場の問題の解決に時間がかかることだ。はるか上までお伺いを立てるのだから、当然だろう。だから、比較的平穏で、問題の少ない職場や業界ならばいいだろうが、リアルタイム性の高いトラブルが頻発する組織では、中央集権型ではやっていけなくなる。情報のパイプだって輻輳し、詰まってしまうだろう。

そこで考案されたのが、Management by Exception(「例外による管理」)だった。これは、「異常時が発生したときだけ報告を上にあげ、上位側が問題解決に乗り出す」方式だ。異常がないときは、報告はあまり小刻みには上げない。そうすることで情報の輻輳を避け、上位側が本来業務に集中できるようにするのである。逆に言うなら、通常でのガバナンス・レベルは、少し下げることになる。

ところで、問題解決について言うなら、どんなに優秀な上位管理者でも、分野的な得意不得意はあるはずだ。自分が経験しよく知っている事象なら解決できるが、自分から縁遠い分野では、うまく指示できにくい。ここにもう一つのポイントがある。つまり下位側の問題解決力がどれだけあるか、である。もし下位側の自己管理能力が高い場合は、方向性と状況だけを見えるように指示し、内容は任せてしまう方が現実的となる。

以上をまとめたものが、図に示した4類型である。ここでは子会社へのガバナンスの問題として表現している。縦軸は、その子会社業務の、上位側(本業)から見た重要性、あるいは本業とのシナジーである。横軸は、子会社の自己管理能力だ。これは、外販比率と置きかえてもいい。というのは、自己管理能力は「プロフィットセンター」としての自立経験を通して培われるからである。

e0058447_22484417.gif


左上の象限は、本業から見た重要性が高く、かつ子会社の自己管理能力が低い場合。当然、細部まで指示命令を下す「中央主権型ガバナンス」になる。ところで、親会社(内販)依存だが重要性が低い、左下の象限は、「承認型ガバナンス」(例外による管理)が現実的である。問題発生時には上位側が入り込んで解決せざるを得ない。

右上の象限はこれに対し、外販比率が高く、自己管理能力の高い子会社で、かつ本業ともシナジーの高い分野を示す。こちらは「可視化型ガバナンス」で、業務の進捗状況をモニタリングできるようになっていればいい(問題は自分で解決できる)訳である。最後に残った右下の象限は、シナジーも低く、外販中心の分野。ここはもう「自由放任型」になる。そのかわり、投資も自分で負担してくれ、ということなる。

このように整理してみると、最初にあげたガバナンスのレベル0~レベル3が、どれもぴったりはまる位置があるようだ。何もかも中央集権や自由放任ではなく、どのタイプにはどれを当てはめるのが適切か、軸が分かったように思う。

ところで、現実には問題が一つだけ残っている。それは「自己管理能力」の評価が、上位側と当事者ではちがう、という問題だ。人間の世界でも、子どもの側はもう自立したつもりなのに、親はいつまでも世話を焼き小言を言いたがる、という例は多い。上位側がいつまでも下位側の能力を過小評価すると、いつまでも中央集権型ガバナンスから抜け出せず、その結果、組織全体として非効率が生じる可能性がある。

そういう意味では、自己管理能力≒外販比率、と図示したが、これは本当はフェアではない。先に述べたように、本来は内販100%のコストセンターでも、サービス・レベルをきちんと定義できれば、自律的な管理ができるのである。自己管理能力は、コストセンターとしての達成経験等によっても、培われるはずだ。だからガバナンスの設計においては、組織の自己管理能力をたえず再評価する仕組みが必要だということが分かるのである。
by Tomoichi_Sato | 2013-03-18 22:57 | ビジネス | Comments(0)

コストセンターとは何か

コストセンターというのは奇妙な用語である。多義的だ、とか、意味が確定しにくい、とかいう訳ではない。コストセンターとは「費用だけが集計される部門単位」という定義が明確にあり、その点では、ほぼゆらぎがない。にもかかわらず、この用語は様々な価値判断や感情的評価を込めて使われている。ネットをちょっと調べてみれば分かるが、「もうコストセンターとは呼ばせない!」とか、「コストセンターからプロフィットセンターへの脱皮を」といった風に、ネガティブな意味合いで使われることが多い。あるいは「所詮コストセンター子会社だから」とか。いったい費用だけが集計される会社とは、どういう意味だろうか。収入がない会社が存在するのか?

もともと「コストセンター」とは、会計学から発した言葉だった。日本語では「原価中心点」という、いささかぎこちない訳語があてられている。意味は先ほど紹介したとおり、費用集計の部門単位である。企業の中には部門がたくさんあり、どこでも費用が発生するから、コストセンター(つまり中心点)がたくさんある、ということになる。なんだか幾何学的にはヘンな気もするが、まあ気にせず通り過ぎることにしよう。たとえばSAPの導入コンサルだったら、コストセンターは主にこうした会計的意味で、会社の組織定義のプロセスで使っているはずだ。

これに対となる用語がある。それは収入だけが集計される部門単位で、こちらは「レベニューセンター」と名付けられている。ところが、現実にはどんな仕事だって、人が動けば(最低でも人件費は)発生する。特許収入のように座っていればお金が流れ込んでくる種類の仕事でも、最低限の知財事務は必要なはずである。だから、純粋なレベニューセンターは実際の会社には存在しない。

そこで、コストも収入も発生し集計される部門単位が登場する。これを「プロフィットセンター」と呼ぶ約束になっている。

さて。ここまでは会計学(とくに原価管理)の概念である。会計学の特徴として、きわめて厳格に定義されているが、価値判断からは中立だ。会計士は、この製品は好ましいだとか、あの部門はアホだとかは言わないのである(少なくとも表では)。ではなぜ、コストセンターという語に、価値と感情がからみつくことになったのか。それは、会計学に隣接する別の学問、経営学の世界にこの語が取り込まれたからだ。経営学では(とくにサイエンス志向のあまり強くない経営学者の間では)、用語は厳密性より「説得力」が求められる。まして経営学のさらなる隣接地、経営コンサルやメディアの分野では、概念の「物語性」が最大の価値となる。

さて、経営学の分野ではマネジメントが主題である。そのため、部門をマネジメントする際に、その部門の性格、ならびに管理目標が問題になる。そこで、コストセンターは費用だけが集計される部門であり、費用で管理するべきだし、プロフィットセンターは収入と費用の両面で(つまり収入-費用=利益で)管理すべきだ、という見方が誕生する。

ちなみに、営業機能と開発・製造機能の双方を併せ持つ「事業部制」という仕組みを発明したのは、GMの社長スローンだったと言われている。それまでのGMは、開発・製造・販売・・と機能別に縦割り型の部門が、すべての車種を面倒見ていた。彼はそれを変えて、製品ファミリごとに、開発から販売まで自己完結・一気通貫で動く組織をつくった。この事業部は製品ごとの特性に応じて意思決定も資源配置も迅速に行えたため、大きな成功をおさめた。おかげでGMも成長したし、彼の名はMITのビジネス・スクールの名前に残った。このような事業部は、まさに収入と費用の両方を自己管理できるという意味で、プロフィットセンターと呼ぶにふさわしい。

ところで、用語というものは流通していくうちに、しばしば本来の意味から離れていく。いつの間にか、事業部制をとらぬ通常の企業でも、営業部門は収入を集計するから「プロフィットセンター」で、製造や物流や研究開発部門は(そして人事経理など本社部門も)、「コストセンター」と呼ばれることになった。これは、元の会計学的な意味では正しい。しかし、経営学的には正しいだろうか? 製造をコストだけで管理する--それはどういう意味だろうか。

コストだけが部門の評価尺度と言うことになれば、向かう方向は必然的に「コストダウン」しかなくなる。コストは小さいほど良い。だから、コストセンター部門は必要かもしれないけれど、会社から見れば重荷でしかない、一種の必要悪である、という事になってしまった。このような見方は、コストセンター部門の子会社化による切り離し、という動きにつながり、'90年代後半から加速していく。その典型は物流子会社であろう。また工場の製造子会社化も広く行われるようになった。その背景には、わたしが以前から指摘している「サプライチェーンにおける生産から販売へのパワーシフト」があった。

ところで、よく考えてみてほしい。コストセンターを子会社化するというのは、その対象部門に「売上が立つ」事を意味する。そうでなければ会社として成り立たない(税務署だって認めまい)。工場を製造子会社化する場合、営業部門はそこから製品を価格付きで仕入れる事になる。今まで一つの会社だったときには意識されなかったモノの途中段階の値段が、急に浮上してくる。これを「移転価格」と呼ぶ。

この移転価格はどうやって決まるのか? 本社の販売側は「安ければ安いほどいい」から、製造原価で出せと要求するかもしれない。しかしそれでは利益ゼロで、子会社の経営が成り立たぬ。他方、原価よりずっと高い価格をつけたらどうなるか。本社側のマージンがその分減少する(無論、減った分は子会社に計上されるが、連結決算ではプラスマイナス・ゼロになる)。だからここは駆け引き、交渉になるのだが、まあ通常は本社の立場の方が強い。本社としては、製造原価とまでは言わぬ、子会社だって間接部門を維持し研究開発だって少しは必要だろう、だから原価+販売管理費の分までは負担しよう、と言うはずだ。

だが、もし子会社が100%親会社への内販だけでビジネスをしていたら、これはつまり会社として内部留保も成長余地もないことを意味する。あなたがこのような「コストセンター子会社」の経営者だったら、どういう将来展望を描き、どうやって従業員のモチベーションを高めるだろうか? ずいぶん難しい課題ではないか。

そうなると、残された道はただ一つ、親会社以外への外販比率を高めて、そちらで儲けていくしかない。だが、これは口で言うほどたやすいことでない。それは世の中に数多くある物流子会社を見ればよく分かるはずだ。営業人員だって不十分な機能子会社に、どうやって顧客を捜してこいと言うのか。一部の例外を除けば、多くは内販に頼っている現状がある。こうした会社は会計的にはプロフィットセンターだが、親からは相変わらずコストセンターと呼ばれている。

話を少し戻す。かりに子会社ではなく社内の機能部門だったとしても、コストというものは、本当にそれ単体で管理できるものなのだろうか? コストのみに責任を持つ組織というが、ここには何か欠けている要素がないだろうか?

コストの高低を言う場合、大事なことがある。それは、比較のベースである。製品コストならば、数量と、品質と、納期があってはじめて、比較可能になる。クラウンとカローラを比較して、カローラの方が安いといってよろこぶ愚か者はいない。また、同じものを作るにしても、1個作るのと100個作るのでは、当然値段は違ってくる。自分が外からモノを買うときを考えればすぐ分かる。

いいかえるなら、「コストだけに管理責任を持つ組織」では、マネジメントとしては全くの片手落ちである。いわば借方に対する貸方、つまり方程式の等号の反対側に、管理項目がなければならない。製造のようにマテリアルを供給する機能の場合は、品質・納期になる。物流のようにサービスを提供する機能の場合は、誤配率に代表される物流品質ということになる。言いかえるなら、サービス・レベルである。つまり、コストセンターは、サービス・レベルとコストに大して管理責任を持つ組織であるはずなのだ。品質が高ければ、コストもそれなりにかかる。納期が正確なら、それなりに費用もかかる。これが道理というものだ。もちろん数量も大事なコストの因子だ。だが、数量はむしろ需要側(販売側)が責任を持つべき項目であろう。

繰り返すが、経営学的にコストセンターをとらえるならば、サービス・レベルを規定した上で、コストを管理目標としていかなければならない。そうしてこそ、初めて他社との比較も意味を持ってくるのであり、また適正な移転価格レベルについても議論可能な状態となるのである。

(追記)英語版Wikipediaによれば、「プロフィットセンター」という用語をマネジメントの世界に最初に取り入れたのはドラッカーだったらしい。しかし彼は後にこの用語がおかしな意味で一人歩きしたのを見て後悔し、「企業内にあるのはすべてコストセンターだ。唯一プロフィットセンターと呼ぶべきは、不渡りでない小切手を切ってくれる顧客である」と述べている。
by Tomoichi_Sato | 2013-03-11 23:07 | サプライチェーン | Comments(1)

「プロジェクト&プログ​ラム・アナリシス研究​部会」 3月定例会(3/30)のお知らせ

プロジェクト&プログラム・アナリシス研究部会」の3月例会は、 「関西IT勉強宴会」との共催によるシンポジウム形式で、 『製造業における情報化プロジェクトをめぐって』をテーマに、 日本の製造業のメッカの一つ、静岡県浜松市で開催いたします。

「プロジェクト&プログ​ラム・アナリシス研究​部会」 は、小生が主査を務めるオープンな研究会です。スケジューリング学会の下に位置していますが、学会員でなくても、どなたでも自由に参加できます。

よろしくご参集ください。

<記>

日時: 3月30日(土)13:00-17:00
場所: 「アクトシティ浜松」 研修交流センター・第52研修交流室
    〒430-7790 静岡県浜松市中区中央3-9-1  
    JR浜松駅に隣接したコンプレックスのDゾーン、「楽器博物館」の上階です。

セッション内容:
    下記の4講演を、各々45~60分程度の時間枠にて行います
    (順序は変わる可能性があります)

(1) 「求む!上流工程技術者
       Salesforce.com 佐野初夫 様(関西IT勉強宴会)
現代のノンプログラミングツールを概観した上で、今のシステム技術者にはプログラム技術より上流工程技術が求められていることを示す。

(2) 「『仕様書で動く生産管理システム』の開発事例報告
       ディービーコンセプト 渡辺幸三 様(関西IT勉強宴会)
個別事情に合わせて設計と実装を繰り返す「スクラッチ開発」は、 開発側の負担が重い上に投資リスクも大きく、複雑な生産管理システム向けには無謀と言うべきだろう。 他方、「パッケージ導入」も大量のアドオンやブラックボックス化のため、事業を変化・発展させることが難しい。 そこで私が提唱するのは、生産管理システムの「モデルシステムの無償ライブラリ」である。 基本設計と業務マニュアルと仕様書がセットになっており、そのまま動作する。 カスタマイズしやすい業種・業態別ライブラリを叩き台とすることで、 導入プロジェクトのリスクやコストは大幅に軽減される。 この方法の優位性、ならびにBOMプロセッサをはじめとする生産管理システムの基本動作について説明する。

(3) 「3D-CADデータの一気通貫とIT活用でものづくり力向上を!
       関ものづくり研究所(元・ローランドDG) 関伸一 様(招待講演)
3D-CADやCAEの進化とともに、フロントローディングと言う名のもとに設計・開発部門に仕事が集中してきているが、 それでいいのだろうか?むしろ設計・開発者の負荷を減らし、 新製品開発と言うクリエイティブかつ付加価値の高い仕事に集中し、競争力を向上すべきことを、 ローランド DG時代に手がけたデジタルセル生産を例に解説する。

(4) 「製造業のプロジェクトにおけるボトルネック ~BOM/部品表の問題~
       日揮(株) 佐藤知一(P&PA研究部会)
今日の製造業は情報システムなしでは回らない。 しかし日本の製造業は、新製品開発のスピード化、受注生産形態へのシフト、 国境を越えた分業等に対し、管理の仕組みが追い付いていない。 そこに共通するボトルネックはBOM/部品表の問題である。 本講演では受注生産のメーカーならびにエンジニアリング会社の事例を通じて、その解決の方向性を考える。

懇親会:
   講演会終了後、懇親のため宴会を開催します。ぜひあわせてご参加ください。
   場所:「マインシュロス
     〒430-8691静岡県浜松市中区中央3丁目8番1号
     TEL: 053-452-1146  会場より徒歩2分
   料金:\5,000 (飲み放題)

参加費用:
   シンポジウムは無料です。
   ただし浜松までの交通費、ならびに懇親会費用は各自ご負担願います。
   ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(\1,000)は免除されます。

参加を希望される方は、人数確認のため、できれば前日までに 研究部会主査 にご連絡ください。 ※懇親会に参加される方はアンケートに参加として下さい

(なお関西IT勉強宴会の方は、従来通りATNDより申し込みをお願いします)
http://atnd.org/events/37178

以上
by Tomoichi_Sato | 2013-03-07 20:24 | プロジェクト・マネジメント | Comments(0)

ネストする地名の謎

京浜急行は、東京の品川から横浜を通って横須賀半島まで向かう私鉄である。東京都横浜を結ぶ鉄道路線は何本もあるが、その中で一番海沿いを通っている。だから何となく車内にどこか潮の香りのするような、庶民的な電車だ。軟弱な地盤の線路上を、かなり高速で運転するから、車内は結構揺れるのでも知られている。駅の名前も、「青物横丁」「鮫洲」「新馬場」「梅屋敷」「六郷土手」と、いかにも昔から人々が住んできた地域を表す地名が並んでいて、“○○が丘”とか“××学園”といった、私鉄不動産部の誰かが机の前で考えたような浅はかなネーミングとは、一線を画している。

その京急に、「神奈川」という駅がある。横浜駅から一つだけ東京よりに戻ったところにある、地味で目立たない駅だ。駅前にはわずかな商店街が並ぶのみで、特急はおろか急行さえとまらず、とまるのは各駅停車だけである。人口900万人を擁する、日本で2番目に大きい(人口の点で)県の名を代表するには、あまりにも小さな駅だ。どうしてこんな小さな町の地名が、県名に使われているのか? 誰が見たって、この県を代表する第一の都市は横浜市である。だったら、なぜ「横浜県」にならなかったのか。

横浜より神奈川の方が古いからさ、という答えも考えられる。神奈川は、古くから東海道の宿場町であった。江戸時代の末期まで、横浜は多少の漁民が住む寒村に過ぎなかった。それが、幕末に、江戸幕府が米国の砲艦外交に屈し開港を決めて以降、貿易港としてみるみる発展していった。外国人たちも居住して、ハイカラな土地になっていく。その場所は、今の横浜市中区のあたりである。そういえば中区生まれのある知人は、「中区以外は横浜じゃないじゃん」と豪語(?)していた。でも、横浜が廃藩置県当時小さすぎて県名に使われなかったとしても、鎌倉とか小田原とか、古くて立派な町は他にもあったではないか。なぜ「鎌倉県」や「小田原県」でなく、一介の宿場町が広大な県名に使われたのか?

ちなみに、本来の神奈川宿の地名は、かろうじて、横浜の区政の中に名前を残した。おかげで、わたしの家の住所は「神奈川県 横浜市 神奈川区」である。東京の人に「お住まいはどちらですか?」とたずねられ、「神奈川です」と答えると、「神奈川のどちらですか」と必ず問い返される。「横浜の神奈川です」というと、ますます相手は怪訝な顔をするだけだ。階層構造的に分析すると、最上位の神奈川の下に、レベル2の横浜がきて、その下のレベル3に再び神奈川が来る。自己再帰的なネストとなった、非常に奇妙な地名構造である。住所を記入するたびに、なぜこんな命名になっているのだろう、といつも不思議に思っていた。

その謎は、ある日、とつぜん解決した。子ども向けの「日本の歴史」という絵入りの本に答えが書いてあったのだ。それは、現在の神奈川県(とくに東半分)が幕府の領地だったことに関係している、らしかった。もっといえば、明治維新の時、官軍側だったか幕軍側だったかで、その地名の運命が決まってしまうのだ。

日本の県の中で、県名と県庁所在地名が一致するところをあげるてみよう。たとえば、

鹿児島県(鹿児島市)
山口県(山口市)
高知県(高知市)
佐賀県(佐賀市)

これらは「薩長土肥」の藩閥で、明治政府の中心をなした藩だった。忠勤藩とも呼ばれた。ほかに、福岡県(福岡市)、広島県(広島市)、岡山県(岡山市)、福井県(福井市)などはみな忠勤藩だ。

他方、最後まで朝廷に抵抗した東北・北陸の「奥羽越列藩同盟」の諸藩はどうなったか。
盛岡  →岩手県(岩手郡)
仙台  →宮城県(宮城郡)
米沢  →山形県(山形市)
久保田 →新潟県(新潟市)
会津  →福島県(福島市)

みごとに、県名から古い藩の名前が消されている。高崎藩(→群馬県)、松本藩(→長野県)、川越藩(→埼玉県)、姫路藩(→兵庫県)、松山藩(→愛媛県)などの朝敵藩も同様だ。岩手、宮城、群馬などは、1ランク格下の郡の名前が県を代表することになった。山形、新潟、福島などは県名と市の名が一応一致しているが、これらは廃藩置県のプロセスの中で、隣接する朝敵藩を吸収して県となっていった。だから、小田原も、東の神奈川県に吸収されてしまう。

例外もある。徳川御三家のひとつ、和歌山は今も県名に残っている(あとの水戸と名古屋は県レベルの名前になれなかった)。だがこれは、孝女和宮が和歌山藩主の長男家茂に降嫁して「忠勤藩」扱いになっていたことと関係しているらしい。

このような、命名による土地への懲罰を決めたのは、長州藩出身の井上馨だったらしい。周知の通り、明治維新は誰か一人の傑出したリーダーによって率いられた行為ではなく、大勢の元勲や志士たちによってなされた。その結果、明治政府は、内部でのリーダーたちの争い、そして旧藩主たちの不服従といった問題を抱えていた。だが、西南戦争で西郷が戦死、大久保が暗殺され、木戸が病没した後、権力を握って明治国家のガバナンス体制を設計し完成したのは、大久保の跡を継いだ伊藤博文と仲間や側近たちだった(井上もその一人である)。

廃藩置県は、中央集権型ガバナンスを確立するための第一歩であった。それも、最初は300以上も藩があったため、統治が大変だったらしい。もしあなたが会社の社長で、子会社が300もあったら頭痛がしてくるにちがいない。すぐに合併と吸収で整理し、数を減らそうとしないだろうか。彼らがやったのはそれだった。そして、その仕上げの過程で、命名権を政治的に活用して敵味方の賞罰を与える、というのが井上の発想だった。映画「千と千尋の神隠し」の中で、相手を支配するために相手の名前を奪って忘れさせる、というシーンが出てくるが、まさにこれである。いかにも「今清盛」と呼ばれ権勢をふるった人間らしい発想だろう。

それはともあれ、中央政府から県令を派遣して「子会社」たちから自治権を奪い、中央に従属せざるを得ないようにした体制は、ある程度成功したらしい。今でもかなりの程度、それは続いているからだ。さすがに今では、神奈川県知事は選挙で決まるし、わたしも投票できる。しかし今でも財政の多くの部分は国からの補助に頼っている。「三割自治」と揶揄されてきたゆえんである。国は県をコストセンターとしか見ていない。地域が自立してプロフィットセンター=価値を生みだす源泉となることは想定していないかのようだ。

そしてもう一つの問題がある。前回も指摘したように、中央集権型ガバナンスをとった時には、上位側にはかなりの情報処理能力が要求されることだ。そうでなければ、とくに問題が生じたときに処理がパンクする。それも、右肩上がりの高度成長時代はいい。増えるお金が問題を隠してくれるからだ。今のように社会の乱高下が激しい時に、中央政府は地方の問題に真面目に対処できる余裕はあるのだろうか? だから急行電車が神奈川の駅を通過するたびに、わたしは決まって不安におそわれるのである。
by Tomoichi_Sato | 2013-03-04 22:22 | 考えるヒント | Comments(0)