<   2014年 09月 ( 7 )   > この月の画像一覧

あなたは、どう考えるの?

「佐藤さん、すみません、ちょっとご相談があるんですが・・」

若手社員が机の前にやってきて、顔を上げたわたしに、いいにくそうな声でぼそっときり出した。わたしが、ITリッチなプロジェクトをやっていた時代のことだ。

--なあに? 何か、いい話かな?

「いえ、あの・・。例の中間在庫ロットなんですが、どうしようかと悩んでいまして。」

--そこは新しいコード体系を使おうって、先週の打合せで決めたじゃないか。

「そうなんですが、注文書のシステムで、ちょっと困ったことが見つかりまして。あのままでは、番号がかち合ってしまう可能性があると分かったんです。」

彼は仕様書の該当箇所をわたしに見せて、問題を詳しく説明する。なるほど、先週の打合せでは、この点を見落としていたらしい。

--つまり、このまま進めば、ユーザに運用を変えてもらって、少しだけ手間が増えるのを我慢してもらうか、さもなければシステムの設計変更をするか、二つに一つです、という訳かな。大勢のユーザに文句を言われるか、開発会社から追加費用を請求されるか、どっちかしかありません、と。

「・・まあ、そういうことです。どうしたらいいでしょうか?」

そこでわたしは、いつものセリフをぶつけた。

--あなたは、どう考えるの

その場で部下が、自分の考えを言ってくれれば、もちろん、それでよし。内容について議論できる。部下の考えがまとまっていない場合は、「少し考えてから持ってきてごらん」と、いったん突き放すことにする。

しばらくすると、「佐藤さん、こう思うんですが。」といってくるので、そこからは議論に付き合い、一緒に考えることにする。たとえ、途中こちらがヒントをだし、リードをしても、「一緒に考える」雰囲気が大切だ。そうすれば相手は、打合せ結果を「自分が考えたこと」として、モチベーションをもって働いてくれる。

わたしはこのようなやり方を、自分自身が駆け出しの頃の、上司から学んだ。わたしが同様に、問題を抱えて、こまって上司のところに行くと、彼は決まってためいきを一つついてから、こう言う。

「それで、オタクはどうしたいんだよ?」

(その人は有名私学の出身で、そのころはまだ珍しい『オタク』という二人称を使う人だった)

わたしが、何も自分でアイデアをもっていないと、「考えてからもってこいよ。」といわれて、対話は終わってしまう。なにか解決策や提案を持っていけば、(もちろんたいていは技術的にケチョンケチョンに叩かれるのだが)とにかく前には進める。

だから、問題が生じても、まずは自分で答えを考えてから、相談に行く姿勢がいつの間にか身についた。それは、そのあと、自分が直接、顧客と接して動かなければいけないキーパーソン・レベルになってからも、とても役に立った。だからわたしも、人を使う立場になると、自然とその真似をするようになってきたのだ。

ただし、ときおり、まったくこちらの指示に依存する姿勢の若手も現れる。「少し考えてから持ってきてごらん」と突き放しても、こういうケースではたいてい、すぐにギブアップしてくる。自分で考えて突破しようという思考体力というか、基本的なスタンスが足りないのだ。おまけに、わたしは冷たい上司だと思われてしまう。そうなると、今度は問題が発生しても、わたしに報告せずに自分一人で抱え込むようになる。そして火が噴くまで、こちらが気づかない危険性が増す。

そういうときは、しかたないので、論点を整理しつつ、もう少し踏み込んで、最初から一緒に考えてやることにしている。その若手社員も、そのタイプだった。一緒に問題構造を図解したホワイトボードの前で、彼は言い出す。

「佐藤さん、従来の品番コードの頭に、取引先の略号を3桁つける、という手はどうでしょうか?」

--そりゃダメだ。そんな抜け道を造ったら、工場内のロットを物流システムで統一的に管理するという、全体の設計思想が歪んでしまう。それに、3桁なんて、どうせすぐパンクするよ。

「それじゃ、どうしたらいいでしょうか?」

 設計思想を大事にしろ、というのも、上で述べた昔の上司から学んだことだった。ただし彼は、設計思想という言葉の代わりに、『設計のスタンス』という呼び方をしていた。その方が、顧客に対してスムーズで、通りやすいからだろう。設計のスタンスを曲げると、あとで追加修正が難しくなり、いきおい全体が温泉旅館の建て増し的な、ゴチャゴチャしたものになっていってしまう。そうなれば結局、運用しづらく保守もコストがかかる。そういう理由をつけて、その上司は顧客の要求を押し戻したりしていた。

 どうしたらいいかたずねてきた若手社員に、わたしは、再びくりかえした。

--あなたは、どう考えるの?

さっきと同じ文句だが、問うていることは、じつは違う。今度は、どれを選ぶかたずねているのだ。目の前のホワイトボードには、結局とるべき方策は三つしかないことが、明らかになっている。

・今までの設計方針を押し通し、運用側で一手間かけてもらう
・システムを一部、変更する
・彼の言う、一種の変則的な抜け道をつかう

三番目は、コスト追加もユーザの不興を買うこともないが、設計思想が歪むので、わたしが賛成しなかった。選ぶなら、一番か二番目しかない。

『考える』という行為には、一般に二つのフェーズがある。問題の答えを探すことは、その主要な部分である。しかし、答えを見つけたあとにもう一つ、問題が生じる。それは複数の答えの中から、良いものを決めることである。

われわれ技術者が直面する問題は、数学のようにたった一つの正解がでてくる場合は少ない。ふつうは複数の解決案があり、しばしば、どれも帯に短したすきに長しと見える状態になる。その中から、どれかを決めなくてはいけない。よく、迷っている人が、「考え中です」と言ったりするように、考えるという行為の第2フェーズは、じつは決めることなのだ。だから、二番目の「あなたは、どう考えるの?」は、

--あなたは、どれを選ぶべきだと思うのか?

と言いかえてもいい。

そして、この問いに答えるためには、『価値観』が重要になるのである。どのような価値観を持って、それを選ぶのか。たとえば、コストと顧客満足が両立しない場合、どちらをより重視するのか。どのような状況のときには、コストを犠牲にしても顧客満足を確保すべきなのか。逆に、どのようなときは、顧客の不興を買っても、コストを選ぶべきなのか。そして、そもそも、“顧客の満足”とは、ほんとうは何をさしているのか。

そして、わたし達は、価値観をしっかり立てて、それに従って何かを決める態度が、しばしばとても弱い。とくに受注ビジネスではその傾向が強いように感じられる。多くは、“ご無理ごもっとも”で顧客要望をなんでも聞き入れてしまって、結局自分のコストと時間で帳尻を合わせている。そのような要望を受け入れることが、相対する顧客のミクロな局所最適にはつながっても、顧客組織のマクロな便益には反してしまう場合、ほんとうに顧客満足優先の価値観に立脚するならば、あえて反論し説得しなければならないはずだ。だが、そう振る舞える技術者は少ない。へたをすると、顧客の些末な要望を聞き入れて、曲芸のような設計を実現することに、自分の職人的プライドをかけたりするような逆立ちが、まかり通る。

まあ、もっと敷衍すれば、わたし達自身、それこそ学校を選ぶときも、就職先を選ぶときも、自分の価値観というより、世間的な評価や周囲のすすめなどにしたがって、何となく選んでしまう。まわりと合わせることが最大の美徳であるこの社会に育って、何か独自の価値観を樹立せよ、という方が無理があるのかもしれない。だが、われわれがビジネス社会で成長するためには、その無理をなんとか通す必要があるのだ。

ところで、ここまで読んだ読者の中には、そんなことを部下にたずねるのはおかしい、決めるのは上司の責任だ、と思う方もいらっしゃるかもしれない。たしかにその通りだ。部下が○○がいいと思います、と言ってきても、わたしは××を選ぶかもしれない。かりに○○を選んだとしても、その結果おきる事は、もちろんわたしの責任であり、まちがっても「部下がそうしろと言ったので」などという言い訳は通用しない。

だとすると、なぜ、若手社員に「あなたは、どう考えるの?」などと聞くのか。理由ははっきりしている。彼に、上司の視点でものを考える訓練をしてもらいたいからだ。上司の視点で考えるとは、必然的に、自分の狭い責任範囲をこえて、全体感を(あるいはせめて多少は広い範囲を)考えた上で、『価値評価』する作業を求めている訳だ。そのような思考訓練は、他者の立場・価値観を推測するスキルにつながり、やがては顧客に対する説得力・交渉力につながっていく。少なくとも、かつての上司がわたしに求めたのは、そうした能力だったにちがいない。

ホワイトボードの前で、まだ迷っている若手社員に対して、ともあれ助け船を出すことにした。

--とりうる選択肢に対してさ、それぞれProsとConsをあげて表にしてみな。

ProsとConsとは、「賛成すべき点」「反対すべき点」の意味で、つまり長所と短所である。彼をうながして、ホワイトボードに簡単な表を作らせた。そして、それぞれの項目に、◎○△×を記入してもらった。

「ええと、こうなりました。」

e0058447_19322410.gif


--どれがいい?

「記号を足し算してみますと、えー、1が一番良さそうですか・・?」

このようなPros/Consの表は、非常に単純に見えるだろうが、フェーズ2の「考える」=「決断する」行為では、案外有効である。頭の外側に見える化することで、見ている全員が、なんとなく納得感をもつからだ。

--うん。少し頭が整理できただろ? ただし本当は、こういう表を作った場合はね、どこかに×がある選択肢は、もうその時点で原則的には不採用なんだ。ノックアウト条項というんだけどね。

「・・じゃあ、2も3も失格ですか。」

--そう言いたいところだけれどね。でも、いまは感覚的に○×をつけているわけで、あまり厳密じゃない。ところで、2の選択肢についてだけれど、納期も遅れる可能性があるのかな?

「はい。追加変更のボリュームによると思いますが。」

--そうだな。じゃ、いつまでに決めなくてはいけないかのな? 開発会社に聞いてみてくれないか?

「それは聞きました。半月以内に決めてくれ、というんです。でも、この議題は、来週のお客さんとの会議で、もうアジェンダにあがっていまして・・」

--だったら、わたしがお客に電話して、来週のアジェンダを組み替えてもらおう。再来週まで時間を作るから、もう少しだけ考え直して見なよ。今、決めるのはやめることにする。コード重複がどれくらいの頻度で起きそうか、まず調べること。」

「はい。わかりました。」

彼は席に帰っていった。わたしの中のカンでは、(根拠も何もないのだが)この問題は何か、技術的な逃げ道があるような気がしたのだ。でも、それを考えるのには時間がいる。

わたしの職場には、

 「決めないリスクより、決めるリスクをとる

という格言がある。決断を先延ばしにしても、普通あまりいいことはないのだ。だが、担当者の彼に、考える時間を作ってやることが、現時点では優先度が高いと、わたしは考えた。それは、カンであり、賭けである。だが、考えるために一番大事なリソースは、「考える時間」なのだ。わたしが自著『時間管理術 (日経文庫)』でも強調したように、タイム・マネジメントの最大の目標は、集中して考える時間を確保することなのだ。

わたしの賭けの結果が、どうなったかは、あえて書くまい。わたしが、かつての上司ほど、カッコいいマネージャーではないことは正直に認めよう。だが、わたしの中には、かつて教わったいくつもの原則が生きている。それを、もっと後ろの世代にも伝えることが、少なくともわたしの使命であろう。

だから、今もこんな文章を書いているのである(笑)。


<関連エントリ>
 →「わたしが新入社員の時に学んだこと」 (2010-05-01)
 →「設計思想(Design Philosophy)とは何か」 (2012-03-26)
by Tomoichi_Sato | 2014-09-28 19:40 | 考えるヒント | Comments(0)

イノベーションのもう一つのジレンマ

数年前、「知的創造の現場―プロジェクトハウスが組織と人を変革する」という本の出版企画にかかわった。これは米国MITのビジネススクール教授でイノベーション研究の専門家であるトマス・アレンと、ドイツをリードする著名な建築家グンター・ヘンという、異色の組合せによる共著の本で、製品開発プロジェクトの組織設計とオフィスの作り方に関する最新の研究と実践例を述べたものだった。非常に重要なテーマであるにもかかわらず、日本では本書が注目されないばかりか、このようなテーマと問題意識が欧米にあることすら知られていないので、わたしの勤務先が監訳する形で訳書を出すことになった。

e0058447_16342838.gif

さて、翻訳作業がそれなりに進んだ段階で、訳書のタイトルをどうしようかと議論になった。原題は"The Organization and Architecture of Innovation"という、格調高くもアカデミックなフレーバーの漂う題である。ところで出版社の編集の方いわく、「この頃は、多少長くても読者の問題意識にズバリと刺さるようなタイトルがはやる」とのことだった。たとえば、当時売れていた本に、『スタバではグランデを買え』などがある。なるほど。それともう一つ言われたことは、「イノベーション」という言葉はすでに手垢がつきはじめているという意見だ。陳腐化しやすいので、タイトルそのものには使いたくない、とのことだった。

あれこれ悩んだあげく、皆で選んだのが『知的創造の現場―プロジェクトハウスが組織と人を変革する』というタイトルだった。「イノベーション」がダメなら、せめて「プロジェクト」という言葉を入れたい、それがわたし達の希望だった。だが、これが読者に”刺さる”タイトルだったかというと、かなり微妙だ。我々エンジニアには、まだ十分なマーケティング・マインドが足りない、ということかもしれない。

ところで、著者の一人トマス・アレンは、ちょっと変わった経歴を持つ学者だ。彼はもともと、ロッキード社のリサーチ・エンジニアだった。「リサーチ・エンジニア」という職種名自体、日本ではあまりポピュラーではないかもしれない。研究開発に携わる技術者という意味だ。「研究開発に携わる科学者」ではない点に注意してほしい。

わたし達の社会では、「科学技術」というような言葉があって、両者を一緒くたにする傾向があり、特にお役人にそれが強いが、科学者と技術者とは全く別のものである。科学者の動機は、科学自体に内在する知的興味にある。有益であれ何であれ、興味深い知識・知見を、人類にとって積み重ねることができれば、それで科学者は満足する。そのかわり、そこには理屈が通っていなくてはいけない。

ところが技術者はまったく違う。技術では具体的な成果が得られるかどうかが勝負だ。たとえそれが製品開発のような不確実性の高い分野であっても、である。そして良い結果が出れば、理屈に多少不明な点が残ってもそれでいい。そこでは集団的な、組織的な経験・知見の集合がものをいう。科学者が原則として個人で評価される(その当否は別として)のに対し、技術力は一種の組織力である。

聞くところによると、リサーチ・エンジニアだったトマス・アレンは、MITの経営大学院であるスローン・スクールで製品開発のマネジメントを勉強しようと思ったらしい。しかし、そこの教授にについて色々と質問しても、製品開発は非常に漠とした難しいテーマで、専門家はほとんどいない、という状況だった。そこで彼は一念発起し、こうなれば自分が専門家になる以外ない、と研究の道に踏み込んだという。まだ70年代ごろの話だ。

製品開発に専門的研究が無かったのも、無理はない。そもそも新製品開発はどこの企業でもマル秘事項であり、成功しても失敗しても外に出る情報はほとんどない。そんな中、アレンは色々な苦心をして事例調査と研究成果を積み上げて行く。

彼の業績の一つとして知られるのが、「研究開発における組織内コミュニケーションの重要性」の研究である。発明とは、すでに知られている要素の組合せである事が多い。その場合、組織内でいろんな知識を持ったもの同士が意見をかわし、「気づき」を生み出すチャンスが重要になる。だから、組織の構造と、その内部でのコミュニケーションの質・量に注目したのだ。

彼が発見したのは、ある意味あっけないほど単純な法則性だった。それは、コミュニケーションの量は、その二つの部門(あるいは二人の個人)の物理的な距離に依存するという事実である。近くにいれば、会話量が多い。遠ければ、少ない。彼によると、二つのチームが50m以上離れていると、(たとえ組織図の上では同一部門であろうと)ほとんどコミュニケーションがなくなってしまう。多分、週に一度とか月に一度の公式な会議などでは顔を合わせるだろうが、それ以外のやりとりは滅多にない。

そんな馬鹿な、電子メールってものがあるだろ。そんなのは昔の話だ、とお思いだろうか? もちろん、アレンはそれについても調べている。そして結果は同じだった。電子メールは、顔を合わせる機会のない相手には、あまり発信されないのだ。だから、組織図の上だけでなく、実際の配置においても、組織設計はよく考えねばならない。

--このアレンの研究は、日本ではほとんど注目されなかったようだ。初期の著書の翻訳は1冊出たが、あまり売れたふしもない。無理もない。なにしろ、マネジメントは科学の対象である、とは夢にも思わぬ人が大半なのだ。

しかし、ドイツではこれに注目した。自動車メーカーのBMW社がその筆頭である。BMWでは、新製品開発と生産の距離を縮め、技術の共有をはかりつつ、なお製品開発の効率を上げるにはどうしたら良いかを考えてきた。そこで建築家のグンター・ヘンの登場である。彼はアレンの問題を、建築面から解決する方法を考えた。そして、建築空間の中に人の流れる「軸」(spine)を作るとともに、そこでの人と人の偶然の出会いが増えるようなデザインを考えたのだ。

また、彼は組織と組織を隔てる壁の一部を素通しのガラスにしたり、ロー・パーティションを使って、違う階の人も顔が見える(在席がわかる)ように工夫した。こうして完成したBMWのプロジェクトハウスProjekthausは、専門技術者たちが作りかけの新車のモックアップのそばで出会いやすくなっており、同社のコミュニケーションは質的に大幅に向上したという。彼らはまた、同じような発想を工場にも取り入れて、新しい画期的なレイアウトを実現してきている。

もともとイノベーションには二重のジレンマがある。その一つはクリステンセンが指摘した「破壊的イノベーションのジレンマ」で、ベストセラーになった『イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき』に詳しく書かれている。破壊的イノベーションは当初、むしろ最先端よりも劣った技術として登場する。そしていつの間にか主流の持続的イノベーションの力を奪って行くのである。

もう一つはプロジェクト・マネジメント上のジレンマである。イノベーションは定義上、それまで誰も知らなかったものを生み出す行為だ。では、そのようなイノベーションを含む新製品開発というプロジェクトを、計画したりコントロールしたりすることは本当にできるのか。なりゆきまかせ風まかせ、では企業としてこまる。しかし、最初からすべてを見通して、WBSやCPMのネットワーク・ダイアグラムなんて作れるのか? どう見たって無理ではないか。

わたし自身も、新製品開発プロジェクトに関わった経験がわずかながらある。一番悩んだのは、スコープとスケジュールのジレンマであった。新製品開発は本質的に不確定要素が多い。したがって、スケジュールの要所要所に、バッファーを用意して、予期しない変化から納期を守る必要があると考えた。ところが新製品開発には市場をいかに早くつかむかが大事で、競合相手もあるから、できるだけバッファーを削って納期を早めたい。営業政策上、リリースの時期は外部に事前に公表する必要がある。最後は、製品の機能をとるかスケジュールをとるか、というトレードオフに何度も直面することになった。

これは、受注型プロジェクトのマネジメントとは随分異なる。受注ビジネス型企業では、赤字か黒字かは天と地ほどの差がある。たとえ1万円でも赤字は赤字である。しかも契約納期がある。だからジレンマはほとんどの場合、コストとスケジュールの間にあった。スコープはそもそも契約条件だから、これを勝手に変える訳にはいかない。ところが新製品開発では、1万円を惜しんで製品の大事な機能を削ったら、愚か者と言われる。予算枠はあるが、それはゴムのように多少伸縮可能なのである。ただ、機能はつけ加えたい、しかし納期は遅らせたくない、おまけにあとから機能を追加・削除したら、あちこち変更管理の手間が生じる。それをどうするか。

したがって、製品開発と受注業務とでは、マネジメントのスタイルも価値基準も変えなければいけない。この観点が、現在のPM論では抜け落ちているようなのだ。

そこで今週26日(金)の「プロジェクト&プログラム・アナリシス研究部会」では、新製品開発の専業である(株)iTiDコンサルティングの蟹江氏を招いて、『製品開発競争に打ち勝つスケジューリング』のお話しを聞くことにしたのである 。とくにスケジューリング技法の話が興味深い。PMBOK Guide(R)では、納期短縮のテクニックとして、CrushingとFast trackingの二種類のみがあげられている。しかし氏によると、実際の短縮技法は7~8種類に分類できるという。慶応大学システムデザイン・マネジメント研究科での特別講義の一部を、無料で聞けるチャンスでもある。ぜひ、製品開発に苦労しておられる製造業・サービス業の諸賢にご来聴いただきたい。

え? 宣伝くさいオチの付け方だって? そういわれてもあえて反論はしない。ただし、研究部会は自分の金儲けでやっている活動ではない。参加費も無料だし、わたしも純粋にボランティアで運営している。スポンサーであるスケジューリング学会が、この活動に多少なりとも価値を認め、続けてもいいかなと判断してくれるよう、「参加して良かった」と感じる方が大勢こられることを期待しているだけである。--「なんでわが社は(わが業界は、わが国は)画期的な新製品が出ないんだ!」とビール片手に叫ぶよりは、多少なりともマネジメント・テクノロジーの一端に触れて感じる方が、金曜の夜の過ごし方としては楽しいはずである。


<関連エントリ>
 →「(書評) "The Organization And Architecture of Innovation" by T. Allen and G. Henn」 (『知的創造の現場―プロジェクトハウスが組織と人を変革する』の原書)
by Tomoichi_Sato | 2014-09-21 16:36 | プロジェクト・マネジメント | Comments(0)

書評:「マエストロ」 さそうあきら

e0058447_018767.gif

新装版 マエストロ(1) (アクションコミックス版)

マエストロ : 1  (Kindle版)


マンガの書評を書くのは本当に久しぶりだ。でも、この「マエストロ」全3巻は、夏休みに読み直して、やはり傑作だとあらためて感じたので、取り上げることにした。

不況で、日本屈指の名門交響楽団が解散する。行くあてを失った音楽家達が、謎の老人指揮者・天童のもとで少しずつ集まり、オーケストラを再結成する。演奏曲目は、「運命」と「未完成」だ。最初は不信と疑惑と、お互いへの反目に満ちていた音楽家集団が、しだいに天童の不思議な音楽づくりに引き込まれ、だんだんと一つにまとまっていく。だが、ある日、スポンサー企業から彼に関する驚くべき噂がもたらされ・・

これは、音楽と、音楽を演奏する人びとを描いたマンガである。そして、音楽を愛するすべての読者にとって、とても興味深く面白い物語となっている。念のためにいうけれども、別に「クラシック音楽ファン」だけでなく、すべてのジャンルの音楽ファンに、おすすめできる。どんな種類の楽器であれ、あるいは歌であれ、それに触れたことのある人、それを楽しんで聞いたことのある人なら、この物語のいくつものエピソードに、身をつまされ、あるいは引き込まれる思いがするだろう。

この話は、全体としてもストーリーの軸があるが、オーケストラの演奏家一人ひとりのエピソードをオムニバス形式のように積み上げて作られている。オーボエ、クラリネット、ホルン、フルート、ピッコロ、ヴァイオリン、チェロ、ティンパニ・・皆が、それぞれのシーンでは主役だ。ファゴット奏者は「地味だけれど、針に糸を通すような微妙な仕事なんだ」と独白し、トランペット奏者は「オーケストラで吹くのは、森の中で走り回るようなものだ」と若手を諭し、傲岸なホルン奏者は「歯は音楽家の命じゃのぉ」と指揮者の天童にからかわれる。それぞれの楽器が、どのような難しさと、苦労と、喜びがあるか、順番にソロを回して唄わせるのだ。まるで良くできた「オーケストラのための協奏曲」ではないか。

音楽家の物語を描くマンガは、これまで他にもあった。しかし、音楽を描くマンガというのは、表現としてはとても大きな挑戦である。何といっても、紙から音は出ないのだ。構図と、コマ割りと、漫符と、キャラの動きから、音楽のリズムや調和やドラマチックな変化を描かなくてはならない。マンガは基本、絵である。絵で音楽を表す--たとえばマネの有名な絵「笛を吹く少年」から、あなたは音楽を聴きとれるだろうか? 正直、わたしには何も聞こえない。むしろせめて、クレーの抽象画の方に、よほど和声を感じるほどだ。

さそうあきらというマンガ家のキャリアについては、よく知らない。正直、表紙の絵だけ見ると、あまり絵の上手なマンガ家という印象は受けないだろう。率直にいって、マンガ的な観点からは、あまりうまい絵描きとはいえない。背景を含めて全体に絵が白っぽいし、キャラの顔もときどき不安定だ。だが、ときおりこの人は、若いときに古典的な『絵画』の勉強をした人かもしれないと感じさせる構図がある。そして、あまりウェットな情念の湿り気を感じさせない、ニュートラルで乾いた画風なので、かえってこのような荒唐無稽な話にぴったり合っている。

そう。荒唐無稽であるということは、マンガという表現形式の持つ最大の美点である。そして、さそうあきらは、その美点を最大限に活かす話作りをする。前作の『神童』などもそうだったが、この話は、落ちついて考えると妙に都合の良すぎる偶然が多い。天童の指揮者天才ぶりを示す眼力(聴力)もそうだ。だいたい、「運命」と[未完成」だけの演奏会プログラムなど、そもそも成立しようもないだろう。

もちろん、作者はそんなこと承知の上で書いている。でも、この二曲だけをクローズアップすることで、わたし達はいろんなことに気づかされるのだ。「運命」交響曲の第2楽章、アンダンテの変奏曲の歩くようなテーマの終わり近くで、なぜメロディは急に立ち止まるのか。あるいは「未完成」の第一楽章、突如ヴァイオリンだけが、他のすべての楽器の沈黙の中で、数小節だけ悲痛な歌をかすかに奏でるのはどういう意味か。そこに、ちょうどぴったりのエピソードが重なってくる。だから良い意味で、荒唐無稽を話作りに活かしているのだ。

それにしても、オーケストラのメンタリティというのも面白い。この話の主人公は別に指揮者の天童ではない。天童(通称「ジジィ」)はむしろ、トリックスター役である。全体としては、コンサートマスターである第一ヴァイオリン奏者の香坂が、ナレーターに近い役柄を引き受けている。その香坂が、第1巻の最初の方で、

 「指揮者はオーケストラのだねっ。」

と大声で言うのである。招かれざる指導者としてやってきて、勝手な指示を出し(出したつもりになり)、しかも演奏が良ければ賞賛は全部、指揮者が持っていってしまう。まことに不条理な仕組みである。

それでも彼らがプロの音楽家として演奏を続けるのは、やはり何より音楽を愛しているからだ。彼らの、音楽の美に対する強い(しかし、めったにしか満たされない)憧れ。その失望と葛藤、だがやはり残る綿々とした愛情--そうしたものが、この話を通して、よく伝わってくる。だからこそ、第2巻のおわり、香坂が、ちょっと三枚目的なヒロイン役のあまね(フルート吹き)に対して語りかける、

 「なあ、あまね・・・それでも--
  この世で一番美しいものは 音楽だ

という夜の水上のシーンこそ、この話の中で描かれる、最も映像的に美しい絵なのである。
by Tomoichi_Sato | 2014-09-19 00:24 | 書評 | Comments(0)

プロジェクト・マネジメントの理論は科学たり得るのか 〜 EDEN PM Seminarに参加して

8月下旬に、フランスのリール市で開催されたPM研究の国際セミナー "EDEN PM Seminar" に参加してきた。招待を受けて1時間ほどの講演をし、また他の発表を聴きながらPM理論の専門家達とネットワーキングを深める、楽しい4日間だった。わたし自身は2008年、2009年につづき、3回目の参加である。

EDEN PM Seminar は、EUの資金援助をえて、毎年夏に開催されるセミナーだ。会場はフランスのSKEMA Business School経営大学院が提供している。SkemaはPM専門の大学院(博士課程)を持ち、欧州のPM研究のメッカといわれている。このセミナーにも、欧州を中心に、米国・中東・アフリカ・南アジアなどから多くの参加者があった。セミナーを実質的に仕切るのは、長年International Journal of Project Management誌の編集長を務めるR. Turner教授である。

e0058447_16142418.jpg


今年のテーマは、「Challenging Projects」。難しいプロジェクトの計画・遂行・評価をめぐって講演発表と議論がかわされた。わたし自身は、「Projects in Distant Terrains: Arctic, Deserts, and Rain Forests」と題して、わたしの勤務先が関わってきた遠隔地プロジェクト(アルジェリアの砂漠、パプアニューギニアの熱帯、そして北極圏)のケーススタディ分析と考察について報告し、好意的なフィードバックを多くの方から得た。ただし自分の講演の内容説明は別の機会にゆずることとし、今回はもっぱら、他の講演を聴いて考えたこと、感じたことなどを述べてみたい。

面白い発表はたくさんあったが、たとえばNASA(米国航空宇宙局)のRoger ForsgrenとEd Hoffmanの2人による「Projects in Difficult Terrains at NASA」をあげておこう。NASAはある意味、プロジェクト・マネジメントの育ての親であり、現在のPMの概念や手法論の多くがここから巣立っている。Dr. Forsgrenの講演は、地球外環境という極限領域における機材設備の設計や、乗組員の保護方法といった技術論を語るもので、エンジニアリングの観点から非常に興味深かった。-100℃から+100℃に数分程度でかわる温度、宇宙線、真空、荷電(宇宙空間にはプラズマが飛んでいる)、そして飛来する宇宙のゴミdebrisなどから、どうやって機材を守るかといった話である。地球外探査のVoyagerなど、その過酷な環境を、もう36年間も航行しつつ、いまだに地球に信号を送り続けている。たいしたものだ。

ちなみに彼によると、NASAは2025年までに火星に人を送り込みたいと計画している。航続期間は年単位であり、それだけの長きにわたり乗員が暮らせるような宇宙船の仕様を考えなければならない。また、とくに火星からの離陸と帰還が大きな課題である。それゆえ、会場からは「装備を軽くするために、NASAは乗員にone way ticketを渡す考えもあると聞いたが」との質問が出た。片道切符、つまり火星からは戻れないという条件で希望者を募る、という意味である。そうすれば装備はずっと簡単になり、実現可能性も高まる。広い米国には、それでも希望者はいるだろう(ジュール・ヴェルヌの「月世界旅行」はまさに帰還を考えない飛行の話だった)。しかし、「倫理的観点から、それは行わないだろう」との回答だった。

しかし、Dr. Hoffmanの話の方は、もっと含蓄に富むものだった。Dr. Hoffmanは、見かけはいかにも気のいいアメリカ人のおっさんだが、なんとNASAのChief Knowledge Officer(CKO)である。その彼のテーマは「Projects in Hostile environments」で、この『敵意に満ちた環境』として、彼は4つをあげる。まずは、Rough neighborhoods、つまり友好的でない隣人・国家。次がTyrants、つまり専制君主的なボスである。ここらへんから話はぐっと人間くさくなる。ある種の毒性のあるリーダーシップtoxic leadershipを発揮する連中がいて、彼らは部下に対して、"you are working for me, not for you."という態度で支配をはじめるのである。

3番目に、彼は「プロジェクト 対 組織」という対立の問題をあげる。NASAも役所であり、プロジェクトという一時的なチームと、永続的な組織との間にはしばしば緊張関係がある。そのよい例が、ゴダード宇宙センターの科学者Mather博士が発案したCOBE Projectであった。COBEは宇宙マイクロ波の背景放射を関するするための人工衛星であるが、この計画はスペースシャトル「チャレンジャー号」の爆発事故による影響で、NASAの中でキャンセルされてしまう。

しかし、そのときのプロマネは、「俺の仕事は解決策を見つけることだ My job is to find a solution.」と宣言し、なんと英国など他の国の宇宙機関からこれを打ち上げるべく活動をはじめる。結局、COBEは最終的には米国から打ち上げられることになり、その観測結果が宇宙ビッグバンを実証して、Mather博士はノーベル賞を受賞するのだが、これは、このときのプロマネの組織をこえた使命感がなければ実現しないものだった(この一部顛末は"The Very First Light"という本になってまとめられている)。Hoffmanが4番目にあげたのは文化的衝突 culture clash であった。

とはいえ、NASAの宇宙の話を聞いているとSF少年に戻ったみたいで、ワクワクと楽しい。それにひきかえ、地上でのプロジェクトは困難が多く、楽しいばかりではない。たとえば、途上国における援助プロジェクトである。ここでは、今回の発表の中でも秀逸だったDr. Lavagnon Ikaの「世銀の監督はプロジェクトに影響を与えるか? Does World Bank project supervision influence project impact?」を紹介しよう。Dr. Lavagnon Ikaはアフリカのベニン出身で、現在はカナダのオタワ大学で働く優秀な若手PM研究者である。

彼はまず、世界における国際援助の統計をざっと紹介した上で、「果たして国際援助というのは機能しているのか?」と問題を投げかける。そして、"Aid is part of the problem and even is the problem”という途上国側の意見 (Moyo, Zambia出身)を紹介する。経済学的な実証研究からみて、マクロ経済学的には、国際援助額とその国の成長との間には相関が見られない。ただしミクロ経済学的な、プロジェクトレベルでは、たしかに有効性は確認されることが多い。ここには、マクロとミクロの矛盾があるのである。


そこで彼は、世銀のSupervisor制度について、215ものプロジェクトを対象にサーベイ研究を行うのである。世銀は自分が融資したプロジェクトに対して、Supervisor制度をもうけている。彼らは、プロジェクトの成功のためのカギ(Critical success factor)として、以下の5つを考えている。
- Monitoring
- Coordination
- Design
- Training
- Institutional environment

ところでDr. Ikaは、最近のPM理論のトレンドにしたがって、プロジェクトの成功を、『遂行上の成功』と『インパクトにおける成功』に区別する。「上手に遂行できた(予算や納期を守った)」ことと、「プロジェクトが良い効果を生んだ」ことは別だと考えるのである。この二つは、残念ながら日本では、まだきちんと区別されずにごっちゃに論議されがちである。

その上で、彼は調査分析の上で、世銀のProject supervision制度は、『遂行上の成功』はたしかに促すが、『インパクトにおける成功』はもたらしていないことを明らかにするのである。Supervision制度は、プロジェクト全体費用の 3%-5% を占めている。金額にすれば、かなり高額だ。だから、とくにプロジェクト計画段階におけるsupervisionをもっと充実させるべきだ、というのが彼のリコメンデーションである。

プロジェクトには、直接の成果物(output)と、それが生みだす結果(outcome)、そして、プロジェクトがもたらす効果・影響(impact)がある。それは短期・中期・長期的なプロジェクトの評価に対応する。こうした視点が、世銀をはじめとする海外援助にはまだ欠けている、というのが彼の問題意識であった。日本のPMコミュニティでの議論を思い返すにつけ、同じ思いを、わたしも感じた。

さて、このEDEN PM Seminarには、最新のPM研究の成果報告と別に、もう一つの柱がある。それは、SKEMA Business Schoolで学ぶ博士課程の院生(PhD Candidate)が、並みいる世界のPM研究者達の前で、学位論文の最終発表と審査を行ったり、博士研究の提案(Proposal)をしたりするのである。これを聴いていると、欧米におけるプロジェクト・マネジメント理論の研究がどのような形で、いかなるレベルで行われているかを目の当たりに見ることができる。

たとえば、以下はLynn Keeysという院生の研究提案のスライドからとったものである。研究パラダイムとしてはConstructivism(構築主義)をとり、コンセプトとしては「企業の持続的発展(SD)戦略から、プロジェクトのSD戦略の創出」をかかげ、理論として「創出的戦略(Emergent Strategy)」に依拠して、以下、モデルの提案、方法論と研究戦略、具体的研究方法・・という風に続く。

e0058447_16244247.jpg


これを見ると、欧米(とくに欧州)の研究では、方法論を重視し、博士課程の院生はそれを徹底的に叩き込まれることが分かる。「これこれを調べてみました。するとこんな結果になりました。だから自分はこう考えました」では、全然研究として認められないのである。わたしは前回、アメリカ人の院生が、自分の所属するデミング賞認定機関の過去データを分析して、品質改善プロジェクトについて研究提案をしたのを覚えている。たしかにそれだけのデータがあれば、かなり面白い分析ができるだろう。しかしそのときは、会場にいた大御所のLynn Crawford教授から、「あなたはどんな理論的枠組みでそれを分析しようとするのか」と問いかけられ、うまく答えられずにコテンパンにやられるのを目撃した。

なぜ、単に事実を報告し分析するだけでは研究としてダメなのか。それは、プロジェクト・マネジメント研究、いやマネジメント研究一般の根幹に関わる問題である。プロジェクトというのはその定義上、本質的に一回限りであり、同じものは二度とない。同じものが何度も繰り返されるなら、それはプロジェクトではなく「定常業務」になってしまう。そして、多くの人間が関わる作業であり、その報告も基本的に言葉を通じてなされる。数字はあるだろうが、言葉の説明も必須だ。

このような条件で、プロジェクト・マネジメント研究が科学的な客観性を保つためには、どうすべきなのか。単に観測事実を論評するなら、評論家、いや街場の居酒屋トークと何も違いがないことになる。それが研究であるためには、そして他の人にも普遍的に役立つためには、自身の研究スタンスや、その限界について、きわめて意識的でなくてはならないのである。わたしは今回、オイル・メジャーで働くエチオピア出身の院生に声をかけられて、研究のアドバイスを求められたが、彼の研究ノートにも、こうした方法論がびっしりと記述してあった。

そして、このような思考の態度を身につけることが、ドクターの学位を得ることの意味なのだろう。Skemaで博士号をとろうとしている院生達は、ほぼ全員、社会人である。修士課程を出て、そのまま博士に進んでいる院生は一人も見かけなかった。そして、ほぼ全員が、中年である(^^;)。これは、プロジェクト・マネジメント研究という分野の特徴なのだろう。学士か修士でいったん、社会に出る。そしてプロジェクトに従事する。だが、年月を重ねるうちに、しだいに内なる問題意識が強まってくる。そうして、もう一度きちんと考え直してみたいと、大学に通い始めるのだ。電子工学の研究なら、20代前半でまったく問題ない。だがプロジェクトでは、自分がマネジメントにかかわった経験年数がものをいう。

言い忘れたがSkemaでは、PMの博士号は、遠隔地で働きながらとることができるシステムである。限られた回数の集中講義は必要なようだが、あとは指導教官たちとやりとりしながら研究を進められる。今回もフランス以外の国から大勢の院生が集まっていた。欧州からも、北米も、南米も、アフリカ、中東、南アジア、中国などから、皆が学位取得の情熱を持って参加している。この人達は、別に全員が大学の先生になろうと思っている訳ではない。じっさい、Seminarで講演する側の人間も、(わたし自身を含めて)実務社会で働いているものが約半数である。今回、パキスタンでPM協会を立ち上げて会長を複数期つとめたDr. Khalid Khanと知り合い、何となく意気投合した(同じ化学工学出身だったのだ)が、彼も働きながらSkemaで学位を取った人だった。

e0058447_16263353.jpg

(SKEMA Business Schoolの内観)

なぜ、彼らは、自身がプロジェクト・マネージャーとして忙しく働きながら、なお、博士研究までしようとするのか。別に大学教授になろうという訳でもないのに。それはたぶん、二つの理由があるのだろう。一つには、彼ら自身が持つ、使命感である。何とかプロジェクト・マネジメントというものを良くしたいとの使命感。もっとプロジェクトの成功率を高めたいという、強い熱意。

もう一つは、おそらく社会の側にある。欧米、あるいは植民地として欧米の影響下にあった国々もそうなのだろうが、こうした地域では、博士号を持った、つまり高度に知的なリソースをもった人材を、それなりに遇する制度があるのである。研究職だけでなく、ビジネス部門や行政職でも、そうした人々を活用する仕組みがあるらしいのだ。

ひるがえって、わたし達の社会ではどうか、とつい思ってしまう。日本にはあいにく、そもそもプロジェクト・マネジメントの博士課程を持つ大学は存在しない(わたし自身は化学システム工学という専攻科で、「ほんとに化学と無関係な、マネジメント研究でもいいんですよね?」と指導教授に念を押しながら学位を得た)。社会人博士も、通常は、週に1,2回、大学に通う必要がある。そして、企業では、博士号を持っている人は研究所勤めが普通である。だから、マネジメントの研究で学位を取ろうというモチベーションが、きわめて得にくい。その結果として、「プロジェクト・マネジメント理論が科学たり得るためには、どうしたらいいか?」といったレベルの議論ができる場所も、極めて限られている。

わたしはこのような現状を、とても残念に思う。研究というのは、すべて科学や医学や工学といった、製品開発に直接結びつく「実学」であるべきで、Management Scienceとかマネジメント・テクノロジーとかいった分野があろうとは思いもよらない、という知的風土に、わたし達は育った。そして、そのこと自体が、我々の社会のブレイクスルーを阻害しているのではないか。まあ、そうした大げさな問題をわたしがすぐ解決できるとは思わないが、せめて自分が主催する研究部会くらいは、こうした問題のフレイバーだけでも議論できる場所に育てたいのである。

もちろん、今だって、たとえばそれこそ仏Skemaに遠隔入学するという手段はある。現時点では、残念ながら日本人の院生はゼロだった。主要大国でゼロなのは、たぶん日本だけだろう。こういう現状を何とかしたいと、わたしも微力ながら思うのである。そして、プロジェクト・マネジメントの実務に日夜苦労していて、この状況を何とか変えたいと願う人が、知的な出口を見つけ出せる世の中になってほしいのだ。


<関連エントリ>
 →「プロジェクトにとって成功とは何か ~ESC Lille PM Seminarより」(2008-09-05)
 →「知識労働、肉体労働、そして『感情労働』」(2011-08-19) (Constructivism「構築主義」について)

(追記:今回のSeminar参加にお声がけいただき、講演機会を得るチャンスをくださったSkema客員教授の田中弘氏に改めて感謝します)
by Tomoichi_Sato | 2014-09-14 16:32 | プロジェクト・マネジメント | Comments(3)

お知らせ:ITmedia/MONOistに『実は穴場!? 製造業が米国に工場を設置すべき8つの理由』を公開しました

製造業の技術者向けコンテンツを配信しているWebメディア「ITmedia/MONOist」に、生産の海外展開と工場立地に関する連載記事(4回シリーズ)の第3回目を公開しました。

今回は、日本企業の工場進出先として実は非常に適地であるアメリカについて、解説しました。

・実は穴場!? 製造業が米国に工場を設置すべき8つの理由とは
http://monoist.atmarkit.co.jp/mn/articles/1409/08/news003.html

このシリーズは、TPMコンサルタントとして海外で長らく活躍してこられた田尻正治氏との共著です。
工場の海外展開に関心のある読者の方々のご来読をお待ちしております。

参考:
<第1回記事>
・生産の海外展開に成功するカギ――工場立地を成功させる20の基準とは?
http://monoist.atmarkit.co.jp/mn/articles/1406/16/news003.html
<第2回記事>
・「工場立地」面から見たアジア各国の特性と課題
http://monoist.atmarkit.co.jp/mn/articles/1407/17/news002.html


日揮(株) 佐藤知一
by Tomoichi_Sato | 2014-09-09 22:41 | 工場計画論 | Comments(0)

受注型ビジネスにおける業務量の予測法

前回述べたように、ビジネスの基本形態は大きく、見込型受注型に分かれる。別の言い方をすれば、「Push型」と「Pull型」という風にも考えられる。市場の需要に対するスタンスが、前者の見込型では、自分から需要を想定して事前準備(生産)し、市場に対して"Push"していくのに対し、後者では実際の顧客の注文を起点として、製品やサービスをつくり提供していく、受け身("Pull")的な動きをする訳である。もちろん、別にどちらがよい、わるい、という事ではない。市場と製品の性質にしたがって、適不適があるだけである。客の注文を聞いてから魚を釣りに行く料理屋はないし、先にプラントを建ててから買い手を探すエンジニアリング会社もありえない。そして住宅のように、建売と注文住宅が共存するような市場も存在する。

ところで受注型ビジネスにおいては、見込型ビジネスに比較して、一点、難しいところがある。それは、先々の受注量(=業務量)が予測しづらい点である。製品やサービスを生みだすためには、人員や設備や原材料・金型等をあらかじめ手配する必要がある。急に受注が増えたからといって、人も設備も、今日頼んで明日からすぐ増やせるものではない。人の採用にはかなりの時間がかかり、教育もしなければならない。かりに外部からの派遣に頼るとしても、やはりアレンジし面接して適性を評価して、とやっているうちに、すぐ数週間たってしまう。設備・金型などの増強も同様である。手配するのに数週間から数ヶ月、ときには1年以上もかかることがある。

だから、受注が年間を通じてきわめて安定しているような理想的ケースは例外として、受注型ビジネスを営むたいていの企業は、先々の業務量をなんらかの形で想定した上で、要員や設備の手配計画、すなわち『リソース計画』を立てている。このリソース手配計画は、ふつう3ヶ月とか半年に一回行われ、向こう1年~2年程度の期間をタイム・ホライズンとして見るような計画である。したがって、生産計画や生産スケジューリングなどよりはずっと単位とする時間軸が長いが、予測にもとづく計画であることに変わりはない。

では、この業務量予測を、どのように行うべきか。これはいうまでもなく、すでに受注して抱えている業務量(受注残の分)と、これから受注するつもりの業務量(受注予想の分)の合計になる。受注ビジネスでは、この二つをしっかりとウォッチしていかなければならない。既受注分の業務量予測は、技術・製造部門の責任範囲である。そして新規受注の予想はむろん、営業部門の責任範囲になるのが普通だろう。

既受注分は、すでに受注し確定しているんだから、今さら何を「予測」するんだ、などと問うなかれ。予測は必要なのである。たとえば1億円の案件を3ヶ月前にすでに受注していたとしよう。全体の工期は6ヶ月で、約束の納期は3ヶ月後である。半分は済んだ勘定である。したがって、残る業務量は5千万円分だ、などと計算できないことはすぐわかる。まず、仕事は毎月均一のペースで進む訳ではない。最初は基本設計があり、それから詳細設計や購買手配があり、後半になると製造・テストなど大幅な力仕事になる。だから、時間が半分たった時点での進捗率が50%ということは、普通はない。オーダー別の個別スケジュールを見た上で、あとどれくらい仕事量が残っているかを計算しなければならない。

おまけに、仕事なんて予定どおりはなかなか進まぬ。当初のスケジュールでは3ヶ月後に作業の40%までが進むはずだった--でも、顧客の度重なる変更要求や、それにつられて起きた設計のミスなどで遅れが生じ、実際は32%しか進んでいません。業務量はまだ68%残っている。しかも、このままで行けば納期を5週間は遅れてしまいそう・・などという事態がよく起きるではないか。そうしたことを、(かりにここまで細かく数値化はしないとしても)適時勘案し、受注残の業務量を「予測」する必要があるのである。それはまさに、工程管理者の仕事である。

では、営業部門が担当すべき、受注予測の分はどうか。

わたしが想像するに、多くの企業では、「見込案件リスト」を営業部門がまとめているはずである。案件リストには、それぞれ案件別に、顧客名、案件名、案件内容、受注金額(想定)、受注確度、受注時期、営業担当者、などが並んでいる。これをExcelで作っている会社もあるだろうし、もっとスマートなところは、SFA(Sales Force Automation)とかCRM(Customer Relationship Management)と呼ばれる種類のソフトウェアでデータベース化しているかもしれない。

そして、この案件リストは、まず「受注確度」によって、ABCランク、あるいは松竹梅、呼び方は何でもいいが、ランク別にソートされるだろう。Aランクは「受注確実」とか「必注」と考えられている案件である。Cランクは「とれないかもしれないなあ」となかば諦めている案件で、Bランクはその中間領域に属する。このような案件別の受注確度の評価も、必ず営業部門はしているはずだ。

その上で、営業部門の責任者が、Aランクの表は真剣に、Bランクはそれなりに、Cランクはまあ適当に、じっくり眺めた上で、案件ごとの受注確度などを個別に推定・調整し(いわゆる「鉛筆を舐め」て)、最終的な受注量を推定する、という手順である。受注確度についても、担当者の評価とは別に、営業トップの査定があり、大事な案件の場合は、担当者をてこ入れしたり支援しながら、受注確度を上げるよう努力を払う。とにかく、普通の企業の営業部門は受注金額が最大の評価指標である。だから、この作業は定期的に、かつ真剣に行われる。そこで最大限に活かされるのが、営業トップのエキスパートしての経験と判断である。

ところが。

わたしがたまたま知っている欧米系企業の中には、これとはかなり違うやり方で、受注量予測をしているところがある。彼らのやり方は、どんな方法か。

「見込案件リスト」を集成し、それが予測のベースになるところまでは、もちろん同じである。だが、その先の手法が、ぜんぜん違う。彼らは、個別案件の受注予測額を次のような数式で評価する。

受注予想額 = 案件想定金額 × 受注確率
      = 案件想定金額 × (案件実現確率 ÷ 競合社数)

ここで案件実現確率は、次のようなステップで決められている。
 (1) 構想段階 10%
 (2) 事業化検討(Feasibility Study)段階 25%
 (3) 基本設計段階 40%
 (4) 投資決定(Investment Decision)段階 70%
 (5) 引合い・入札段階 80%
 (6) 金額交渉段階 90%
 (7) 受注決定 100%
このように、案件の実現する確率を、その案件が顧客内部でどのような段階まで「成熟」しているかで、自動的に推定するのである(ただしここに掲げたのは一例であり、段階や数字は企業により異なる)。

案件実現確率から受注確率を導く際は、ごく単純に、競合相手が1社ならば50%、相手が2社ならば33%、4社競合ならば25%、という風に考える。自社を含めてN社の競争ならば1/Nの確率である。ウチが有利だとか、相手が強そうだとか、競争に裏がありそうだとか、そういったいわゆる「営業マル秘情報」は一切加味しない。

そして、リストにある全案件に、上記の数式を機械的に当てはめて計算し、受注推定時期に応じて、四半期ごとに積み上げて行く。それが彼らの経営計画の基礎数値となるのである。直近の業務量負荷計画は、この数字を用いる。

このようなシステマティックな、しかし機械的な予測方法には、違和感を感じる向きも多いと思う。そこには営業マンたちの持つ、生々しい情報や経験に裏打ちされた判断が、ほとんど取り込まれないからだ。前述の通り、普通の日本企業の場合は、営業案件リストを見ながら、営業部門の責任者たちが、なるべく蓋然性の高い受注予測をつくって、業務量負荷計画のベースとする。ここの工夫が一切、数字に反映されないことになってしまう。

それではなぜ、このような方法を彼らはあえて取るのか? そこには、基本的な考え方の差があるからだ。それは、重要な仕事のプロセスを、属人性に頼る形でデザインすべきかどうか、の差である。上に書いたような方法をとる企業は、経営資源(要員は大事な経営資源だ)のベースを決めるような仕事について、誰もが客観的に説明可能なやり方をすべきだと信じている。そして、そうしなければ、まず株主が納得しないはずだ、とも考える。

なんでこのような数字で経営計画を立てたのか? と株主にたずねられたとき、「セールス担当副社長のジョン・某の長年の経験と勘で・・」では通らない。なぜなら、ジョン・某が来月、急にライバル会社に転職したら、誰がこの会社のリソース計画を裏書きするのか。--まあ、こんな問答は極端としても、彼らには“業務プロセスは誰がやっても結果の品質にむらがないようにすべき”という発想が強いのだ。この点、“品質は熟達した職人がつくる”と無意識に考えている多くの日本企業とは、ずいぶん違う。

また、計画のベースとなる予測数値に、個人や部署の「思い入れ」だとか「やる気」だとかいった主観的願望を入れるべきではない、という思いもある。これもまた客観性の担保である。

さらに、上記のような計算方式をとることで、リソース計画を審議するマネジメント層の議論のあり方が、まったく変わってくることに注意してほしい。彼らは、過去の推計値と実績値を比較分析することで、たとえば
「(4)投資決定段階にある案件の実現確率は、40%よりも45%とする方が、事実をより正確に反映するようだ」とか、
「直近2年間の案件履歴を見ると、わが社は(4)段階から(5)段階に至る間に、相当数の案件がリストから消えてしまう。これはすなわち、引合い入札前の事前審査対応に何か問題があるのではないか」
といった議論をする訳である。他方、“個別案件鉛筆舐め方式”では、どうしても案件単位の議論、それも願望や情熱を含めた議論に終始しがちだろう。

むろん、機械的計算方式をとるからと言って、個別の営業局面での仕事に大きな違いがある訳ではない。彼らだって営業情報は必死になってとっている。どこが競合相手なのか、自社はどれくらい有利なのか。失注したら、どこが勝ったのか、なぜ自分たちは勝てなかったのか、どれくらい値差があったのか、なんとかして探り出そうとするのは、我々と同じだ。営業マンの査定方法まではわたしは知らないが、やはり受注額がモノサシになる点に違いはないだろう。ただ、その査定にしても、
「ジェームズ君。計算式で言えば君の今期の受注額予測は40万ドルだったが、実績は46万ドルと上回っているな。昨年同時期に比べると絶対額は減ったとはいえ、その分の努力は評価できる」
くらいの会話は成立しそうな気がする(ま、ここは想像である)。

念のため言っておくが、わたしはすべての欧米企業が上記のようなやり方をしている、などというつもりもないし、まして日本の受注ビジネス型企業が明日から全員真似すべきだ、などとも思ってはいない。まさにそれこそ「経営判断」で決めるべきである。ただ、繰り返しになるが、重要な業務プロセスを属人型でやるか客観型ですすめるかは、大きな思想の違いである。属人型の場合は、人を育てる(ないし、素質のある人を選抜する)しかない。客観型の方は、それを技術として継承し改善していく事が可能である。それがすなわち、わたしの好きな用語で言えば、「マネジメント・テクノロジー」となる訳である。

ともあれ、受注型ビジネスの企業においては、業務量の予測とリソース手配計画という重要な仕事があることは頭にとどめておいていただきたい。

え? そんな「リソース計画」などという小洒落たものはない? --それってあれですか。「手前どもは身の丈にあった以上の注文は受けるな、という先代からの方針でして」という、老舗らしいディセンシーあふれる経営方針ですか。あ、違うと。「とれてもいない仕事の心配なんかしてどうなる。とれてから考えればいい! 人が足りなきゃ外に丸投げしたっていい。やり方なんて仕事についてくる」が、社内の合い言葉ですか? そりゃたいへん失礼いたしました。それなら、ここに書いた話なんて、みんな忘れていただいて結構です。


<関連エントリ>
 →「基本的フレームワークで4種類のビジネスモデルを理解する」 (2014-08-30)
 →「進捗管理とは何か?」 (2012-02-26)
by Tomoichi_Sato | 2014-09-07 19:32 | サプライチェーン | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会」(2014/09/26) 開催のお知らせ

「プロジェクト&プログラム・アナリシス研究部会」の2014年第5回会合を、以下の要領にて開催いたします。

今回は、製品開発プロジェクトのスケジューリングについて、この分野の専門家である(株)iTiDコンサルティングの蟹江淳様にご講演をお願いすることにしました。

新製品開発では、納期短縮と変更管理を両立させることが、プロジェクト・マネジメント全体の急所になります。納期を短くするためには複数の作業を平行に進める必要がある。 しかしそうすると変更が生じた時のインパクトが大きくなる--この矛盾を、どのように克服するか。自動車業界をはじめ、多くの企業に対し、製品開発の専門的コンサルティングの実績をお持ちの蟹江様から、その勘所を教えていただきますので、ぜひご期待ください。

<記>

日時: 2014年9月26日(金) 18:30~20:30
場所: 慶応大学 三田キャンパス・北館・会議室3(地下1階)
    アクセス http://www.keio.ac.jp/ja/access/mita.html
    ※キャンパスマップの【1】になります

講演タイトル: 「製品開発競争に打ち勝つスケジューリング」

概要:
 顧客ニーズの変化は激しく、開発途中の企画変更が当たり前になりつつあります。 一方で、開発スピード競争は留まるところを知らず、納期の前倒しも頻発しています。 本講演では、自動車業界を中心に広まりつつある、開発競争力強化に不可欠な変更対応とスピード開発を両立するプロジェクト・スケジュールリング手法と納期短縮の8つのワザをお知らせします。

講師: 蟹江 淳 (株式会社iTiDコンサルティング)

講師略歴:
 早稲田大学商学部卒業。大手ITシステム会社にて、セールスエンジニアとして電機・通信企業を中心とした製造業の支援に従事後、iTiDコンサルティングに参画。 大手自動車メーカーや自動車部品メーカーに対する開発効率化、開発期間短縮の実績多数。 コンサルティングに加え、DSM(Design Structure Matrix) Conferenceにおける海外講演、慶應大学大学院SDM研究科附属SDM研究所特別講座講師等を通じ、精力的に製造業の開発力向上に取り組んでいる。

参加費用: 無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(\1,000)は免除されます。

参加を希望される方は、確認のためできましたら当日までに佐藤までご連絡ください。

以上
by Tomoichi_Sato | 2014-09-01 19:01 | プロジェクト・マネジメント | Comments(0)