プロジェクトマネジメント ワンポイント講義

プロジェクト・マネジメント(PM)、タイム・マネジメント(時間管理術)、プロジェクト・スケジューリング、などの分野で理解すべき用語と概念を解説しています。



プロジェクト・リスク・マネジメント

リスク・マネジメントは本当に可能か (2010/08/11)

たまに人前で、プロジェクトのリスク・マネジメントについてお話しする機会がある(事業リスク・マネジメント、というテーマ名のこともあるが)。そういうとき、私が真っ先に聴衆の方にたずねる質問が二つある。最初の質問は、

「あなたは、リスク・マネジメントが本当に可能だと思いますか?」

という問いかけだ。そして、こう補足する。「マネジメントとは、自分がある程度知っている対象を、自分の目的のために動かして利用することを言いますね。ところで『リスク』とは、自分がよく知らない、予見しがたい事象を指す言葉です。では、自分が知らないものをちゃんとマネジメントできると、皆さんは信じますか? リスク・マネジメントという言葉は、言語矛盾だと思いませんか。ならば、リスク・マネジメントとは、一体何をマネジメントすればいいのでしょう?」

ちょっと虚を突かれた感じの聴衆の方に対して、次に放つ質問は、こうだ。

「では、皆さんは、運不運が存在すると思いますか?」

反応はいろいろだが、おおむね、“人生には運・不運はあると思う”との回答が返ってくる。“いや、運・不運なんて信じない”と答えた方は、これまでたった二人しかおられなかった。そのお二人とも、まだ20代そこそこの若さであったことを考えると、たいていの人は、ある程度の年齢になると、運不運はあるかもしれないな、と感じるということなのだろう。

それにしても、『運・不運』とは、いったい何のことを指しているのだろうか。

サイコロをころがしたら、出た目は偶数だった。ところが次にころがしたら、今度は奇数の目が出た−−こんなことは、別段だれも運不運だなどと思わない。単に、ごくありふれた偶然性がそこにあるだけだ。サイコロの博打で、最初は丁の目にかけて勝ち、次は半で敗れた。これだって、別に騒ぐほどのことではあるまい。そういう状態を指して、“人生には運不運があるよな”、などと誰も感慨にふけったりはしない。では、どのような事態を指して、人は運不運がある、と感じるのか。

たとえば、自転車に乗っていたと想像してほしい。ちょっと横風が吹いてくる。あるいは、前方で年配のご婦人が不注意にふらふら歩いている。こうした事象はありがちで、とくに驚くほどのことではない。風向きに応じてバランスを取ったり、歩行者をよけて走ったりするだけだ。十分、対処できる事象である。自動制御理論風にいえば、自転車という「システム」を運転するために、足ペダルの「動力」や、ハンドルの向きなどの「制御要素」をインプットする。システムの入力に多少の「外乱」(風や前方障害物)があっても、安定化制御をつづける能力を私たちは持っているのである。

ところで、この外乱が通常よりもずっと強いものだったら、どうだろう。あるいは、ずっと継続して続いたら。たとえば、急に風速30mの横風を受けたら、倒れずに走るのは上級者だけだ。ご婦人でなく小学生が、さっと物陰から飛び出したら、よけるのはかなり困難だろう。入ってきた外乱が、安定制御可能な上限を超えているのである。

私たちは、普段の生活においては、仕事上でもプライベートでも、それなりに繰り返し性のある安定した営為を続けている。天候や健康や渋滞や反目など、多少の外乱はあっても、対抗したり回避したり受け流したりして、生活を続けていける。しかし、自分の制御可能な限界を超えた、大きな事象がふりかかって、期待した状態から大きく外れてしまうことがある。勤務先が倒産したり、恋人にふられたり、受かるはずの試験に落ちたり、といった状況に陥ると、「これは不運だ」と人は思うのである。逆に他人が、思わぬ昇進を上司から勝ち取ったり、偶然うまい仕事のチャンスに恵まれるのを見ると、「あいつは運が良い」と思ったりする。

かくして、職を失うと同時に恋人にも去られる人間がいるかたわら、丁度うまく回ってきた仕事で楽に成功して昇進する者も居る。こうして、「幸運」や「不運」が片寄って連続して現れるとき、運不運はあるな、という感慨が生まれてくるのである。

おかしなことに、サイコロをふってみても、同じ目が何度も続けて出ることがある。純粋なランダムさではなく、中心からずれたかたよりが連続して生じることを、不思議と私たちは観測するのだ。これを称して、運不運と私たちは呼ぶ。

でも、ちょっと考えてみてほしい。私たちの住むこの世界が、ホワイトノイズ的な完全なランダム性の支配する場所だったら、私たちは耐えられるだろうか? 放映終了後のテレビスクリーンの画像のように、一切何のとりとめも脈絡もない、そんな予測不能な事態に私たちは耐えることが出来ない。

また逆に、一切が全て厳密な因果律の法則性にしたがう世界はどうだろう。それは、すべてが運命のように決まった、完全に予測可能な世界だ。そんな宿命論の下で、私たちは正気を保てるとは思えない。

つまり、私たちは、連続性がありながら、ちょっとランダム、という状態が一番居心地がよいのだ。ある程度の予測可能性がある。でもサプライズもある。つまりリスクもある。それが私たちの望む状態なのだ。

さてそれで。リスク・マネジメントという言葉は、それ自体が言語矛盾だ、と最初に書いた。では、何をマネジメントすべきなのか?

リスク・マネジメントに対する大きな誤解に、ときどき出会う。「リスク・マネジメントをすればリスクが減る、無くなる」という誤解だ。賭けたって良いが、そんな事ありはしない。私たちはどんなに手を尽くしたって、明日台風が日本に進路を向けることを防げはしないのだ。リスク・マネジメントとは失敗しない方法ではない。

また、リスク・マネジメント=危ないことに手を出さないこと、という誤解も多い。それは嘘だ。たしかに、何もしなければ、失敗もしない。しかし、ゴーイング・コンサーンである企業において「何もしない」はあり得ない。それは昨日と同じことを今日もやる、という意味である。それは消極的ながら一つの決断であって、とうぜんリスクをともなう。もし「環境変化に対して何もしない」のだとしたら、その方針自体がもはや、最大のリスクである。

リスクとは何か。その定義はさまざまだが、リスクの大きさを数式的に表現するならば、次のようになるだろう:

       可能性×影響度
リスク = −−−−−−−−−
        対応能力

おわかりだろうか。リスクの大きさは、その可能性(生起確率)と、影響度の積に比例する。リスク事象の生起確率は、低減できる場合もあるが、コントロールできない場合の方が多い。台風の進路のように。

ということは、私たちのなすべき方策は、「影響度」を小さくするか、ないしは「対応能力」を大きくするしかないのである。これがリスク・マネジメントの本質なのだ。

私たちは未知なるリスクそれ自体をマネジメントすることは、できない。私たちができるのは、リスクへのふるまい方をマネジメントすることなのである。それをどう学ぶべきかについて、これから数回に分けてノートを書いていきたいと思う。

→「革新的生産スケジューリング入門」にもどる

リスクに対する新しいアプローチ (2010/09/01)

少し前のことだが、あるコンサルタントの方から知恵を貸してほしいと依頼されたことがあった。公立の某研究機関に対して、要員教育の提案を出そうとしているところで、その中のリスク・マネジメントについて内容をどうすべきか悩んでいるとのことだった。客先担当者の要望は、「我々は公の予算で動いている以上、失敗することは許されない。そこで、所員達に失敗しないためのリスク管理を教えてほしい」という内容だ、という。どうカリキュラムを組むべきか、うまいアドバイスはないだろうか、と私は問われた。

私はちょっと困ったが、正直にこう申し上げた。「“失敗しない方法”は、私には思いつきません。失敗したくなければ、何もしない事しか方法はありませんね。でも、それでは研究所として成り立たないでしょう。およそ研究というのは知らないことを発見するためにやることですから、失敗しない研究などというものは、私には想像がつきません。」

それから、少し言葉を継いだ。「ただし、言えることが一つあります。大きな失敗を防ぎたかったら、小さな失敗を上手にして、そこから学ぶ必要があります。“上手に失敗する方法”だったらお教えするのを手伝うことはできます。」

−−でも、上手な失敗、ってどういう意味ですか、佐藤さん。
「えーとですね。たとえば、スキーとかスケートを学ぶとき、最初にインストラクターが教えるのは、“上手な転び方”なんです。ケガをしないよう、ひどく頭を打ったり体に衝撃が来ないよう、安全に転ぶ転び方があるんです。スキーやスケートは、上級者は転びません。でも、上達するまでの間は、必ず転びます。転ばずに上達する方法はないんです。そのとき、どう転ぶかが大事で、うっかり恐怖心が植え付けられてしまっては、もう先は望めません。だから、尻餅の付き方を最初に練習するんです。」
−−たしかに、柔道も最初は『受け身』の練習ですねえ・・。

その仕事は結局、取れなかった。誰か別に、売り込みの上手な人が「絶対転ばない方法」を売り込んだのかどうかは、定かではない。ただ、その仕事からわたしは一つ学んだ。それは、リスクに対する態度、アプローチには、大きく二種類あるということだ。

リスクに対する従来型のアプローチは、この某研究機関の客先担当者の態度に、典型的に表れている。「失敗は許されない」→これが中心テーゼである。だから可能な限りリスクを回避し、失敗を起こさぬ事を求める。『安全第一主義』と言ってもいい。

これに対して、新しいアプローチがある。これには、まだ適当な訳語がないので、英語のままRisk-based Approachとよぶことにしておく。こちらは、どんな行為にも失敗のリスクが存在することを前提に、なすべき事を考える、という態度を取っている。必ず失敗の可能性はある。それをベースに考えよう、とのアプローチである。

従来型のアプローチには、別名もある。それは『完全主義』であり、また『前例主義』である。失敗は許されないのだから、当然前例は成功していることになる。だから前例にならえばよい。これは論理の必然である。お役所だとか、大企業だとかは、こうした態度で仕事をしている人が非常に多い。このアプローチに従えば、人事評価においては必ず減点主義になる。なぜって、失敗しないのが当たり前なのだから、失敗があったら担当者個人がいけないのであって、そいつの減点になる。

これに対して、新しいRisk-based Approachは、日本語で別名を与えるなら『現実主義』になることは、お分かりになると思う。

まなび」についての方針も、両者ではずいぶん違う。従来型の安全第一主義では、“前例を学ぶ”が唯一最大の方法である。なぜなら前例は成功している(はず)だから。こうした組織では、訓詁学が発達する。そして、失敗は個人の無能力のせいということになる。他方、Risk-based Approachでは、大きく失敗したくなければ、小さな失敗を上手にする方法を学ぶ必要がある、と考える。

そして、両者はコストにおいても大きく異なる。従来型のアプローチでは、コストが際限なくかかる。なぜって、完全を求め、「絶対安全」が命題だからである。しかし、Risk-based Approachでは、そうは考えない。リスクに見合う最適なコストにおさめる−−これが思想である。コストには最適点がある、と考える。

日本企業の多くが、次第次第に高コスト体質となっていった背景には、従来型アプローチがあったのではないだろうか? 少なくとも、公的事業、あるいはそれに準ずるような事業(たとえば公共土木・鉄道・発電・通信・防衛・保健・公共システムなど)を主要市場としている企業は、技術的完璧主義につき合う中で知らず知らずのうちに、仕様が水ぶくれしていたのではないか? それを「世界最高水準の技術」などと自称して栄華を誇ってきたが(なにせ公共系は金払いだけは良いし、日本は人口が多いから市場も大きい)、いつのまにか背後のアジアから、『現実主義』をひっさげたライバル達に蹴落とされそうになっているのではないだろうか。

もちろん、こうした心配が杞憂であって、日本の多くの企業が果敢にリスクに挑戦しているのだと信じたい。信じたいが、しかし、「目をつぶって」どんなリスクも取る、というのは、現実主義とはもちろんほど遠い。目をつぶって全てを避けるのと、すべてを取るのは、どちらも現実を見ていない点では同根であろう。

では、Risk-based Approachとは具体的にどういうことをするのか? それについては手短には答えられないので、この場所でおいおい書いていくこととしよう。

→「革新的生産スケジューリング入門」にもどる

「リスク」という言葉に伴う不確実性 (2010/09/30)

ビジネスにおけるリスクを語る際、非常に厄介な事実が一つある。それは、「リスク」という語の定義がうまく定まっていないことだ。Aという人の語るリスクと、Bという人の受け取るリスクが同じ物事を指しているとは限らない。いや、違うことを言っている可能性の方がずっと高い。各人の理解にブレがある。リスクについて語ることは、それ自体がすでにリスキーな事なのだ。

たとえば、人に「最近遭遇したリスク事象の例を挙げてください」と質問したとしよう。たいていの場合、返ってくる答えは「発注先が納期を一月半も遅らせてきたんです」とか「先月自転車で事故りまして」といったものだ。これらは実際に起きてしまったトラブル事象、すなわち『issue』(問題)である。リスクという語は、本来は起きる前の可能性を指す概念のはずである。だから、「発注先の手際がまずくて納期に遅れそうになり、気を揉みました」とか「自転車のブレーキ不調でヒヤリとしました」という事象が本来の答えであるべきだろう。どこかに概念のいき違いがありそうだ。

こういうときに、近頃の人が頼りにしたがるのがWikipediaである。しかし、この稿を書いている2010年9月現在で、日本語版Wikipediaの「リスク」を見ても、各方面からの寄せ集め的な解説しか載っておらず、(書いた人には申し訳ないが)正直なんだかよく分からなくなる。英語版Wikipediaの"RISK"の方はもう少し立派にまとまっており、定義definitionのセクションには積分の数式まで登場してなかなか楽しめる(知的余裕のある人には)。でも、よく読むと「リスクという語にはいろいろな定義があり得る」と書いてあり、100%決定打とはなっていない。

じゃあ、学問的定義は? ところがリスクに関連する学会も、日本リスク研究学会(安全・環境系の人が多い?)・日本リスクマネジメント学会(経済学系でなぜか関西中心?)・リスクマネジメント協会(保険・法務の人脈が強い?)と複数存在している。そして、それぞれが資格制度や検定試験も行っているようだ。海外に目を向けると、米国に本部を持つThe Society of Risk Analysis (SRA)、Risk and Insurance Management Society (RIMS)などの国際的組織がある。とにかく「リスク業界」は百花繚乱なのである。リスクというテーマが、ビジネスの分野でもアカデミックの世界でも、めしのタネとして大勢の人を養っている事実に驚嘆すべきであろう。

電力中研の田邉朋行氏は、東大工学部での「社会技術としての化学技術」という講義シリーズの中で、種々のリスク定義におけるブレと共通点を解説しておられる(じつはわたしも同じシリーズでプロジェクト・マネジメントの講師を務めている)。これが実にうまくまとめられているので紹介すると、保険と金融という、隣接した業界においても「リスク」の概念は全く違っているのだという。

たとえば、保険実務においては、「ハザード」hazard、「ペリル」peril、そして「リスク」riskという言葉を使い分けている。たとえば“道にバナナの皮が落ちている”という事象発生の原因状況をハザードと呼び、“すべって転ぶ”という損害をもたらす事象をペリル、そして“けがをして入院”という結果としての損失をリスクと呼ぶ。あるいは、電線の絶縁不良はハザード、漏電がペリル、そして火災がリスク、という訳である。人はしばしば漏電も火災もごったまぜにしてリスクと呼ぶが、保険業界においては、事象の内部構造を三段階に分けて認識するわけである。

(念のためにいうと、火災が起きてしまったという事象はリスクではなく、結果である。火災が起きるかもしれない、という可能性をリスクと呼ぶわけだ)

ところが、金融業界における「リスク」の使い方は、まったく違っている。飛んでいる飛行機からパラシュート無しで飛び降りた場合、ほぼ確実に死亡する。だから、普通だったらリスクは非常に大きいと思うだろう。ところが金融工学では、リスクはほぼゼロと考える。ただ、リターンがマイナス無限大だ、と解釈するのである。金融理論では、リスクとは結果に対する不確実性を意味するからだ。

田邉氏の「技術リスク意思決定と法システム」によると、医療・環境学系でもリスクの定義はまちまちらしい。たとえばダイオキシンを論じる場合、物質としての毒性の強さと、その人の健康への影響度(これは濃度や摂取量によって決まる)をきちんと区別して論じないケースがある、という。

ただ、こうしていろいろな定義を並べて考えてみると、どうやらリスク概念には大きく分けると二種類あることがわかる。それは、保険業界・環境学などのように、望ましくないマイナス事象の可能性をリスクと呼ぶ分野と、金融理論に見られるように、マイナスの結果(脅威)だけでなくプラスの結果(好機)も含めてリスクと呼ぶ分野、との二種類だ。わたしは前者を「非対称型」、後者を「対称型」リスク概念と名付けて区別している。

では、一般的なビジネスの現場ではどうか? 生産管理や品質管理では、リスクはふつう非対称型の概念である。納期遅れや、在庫切れや、品質劣化をリスクと考える。ところが、プロジェクト・マネジメントの分野では、PMBOK Guideは明確に対称型のリスク概念で書かれている。これはやや不思議に感じられるが、あるいは標準制定の途上で、金融学系の人々の影響が強かったのかもしれない。

それにしても、なぜ対称型と非対称型の二つの見方が出てくるのか? それは、それぞれの分野におけるリスクの反対概念を考えてみると理解できる。医療・環境学では、「リスクの無い状態」とは、『安全』である。保険や法務や情報セキュリティなどの分野でも、理想は『安全』である。ところが、金融分野では、「リスクの無い状態」は『確実』を意味するのだ。かくして、無意識の内に、安全を考えるのか、確実を求めるのかで、リスクに対する態度は分かれる。その結果、両者の間でコミュニケーションは確実に混乱するのだろう(笑)。

それでは、ビジネスの現場におけるリスクは、どう定義するのが良いのか。ここでわたしの考え方を述べたいところだが、いつものくせで、寄り道がまた長くなりすぎたようだ。続きは、また書こう(→生産計画とスケジューリングの用語集『リスク』の項参照)。

→「革新的生産スケジューリング入門」にもどる

リスクとは目標の反対概念である(2013/09/08)

先週、プロジェクトマネジメント学会に招かれて、「海外プロジェクトのリスク戦略を考える」というキーノート・スピーチをさせていただいた。『リスク戦略』とは、1時間で語るには大きすぎるタイトルだが、こうしたテーマが望まれるのも、いよいよ日本企業や大学人の多くが、海外に目を向けざるをえないようになったからだろう。グローバル化の時代に遅れるな云々の、メディアによる各種ドライブも影響しているのかもしれない。

そうはいっても、不慣れな外国との商売は何かと怖い。だからリスクマネジメントなるものが必要だ−−そんな流れから、売上の85%が海外プロジェクトであるわたしの勤務先が、多少の興味を呼ぶのだろう。海外とのリスクについて、どんなことを考えているのか、ちょっと聞いてみようか。ということで、わたしなどが呼ばれたにちがいない。

限られた時間なので、講演では三つのポイントにしぼって話をした。第一に、リスクをおさえるには、事前計画と事後対応が車の両輪で、その両方の能力を組織で持つべきだ、というわたしの持論。二番目は、教科書や正解を盲信するのは危険であって、むしろ失敗にきちんと向き合って学ぶことが大切だということ。そして三番目に、リスクとは成功しない可能性なのだから、リスクマネジメントをしたいなら、プロジェクトの成功基準である『目標』を明確にするべきだ、という主張である。多少の例やクイズをおりまぜつつ、できるだけ分かりやすく説明させていただいたつもりでいる。

ところで、最後にあげたリスクと目標設定の関係については、来聴者の中にも意表をつかれた思いの方が少なくなかったようだ。プロジェクトには「どうなれば成功であるか」の目標設定が必要であり、その目標にネガティブな影響を与える可能性として、リスクをとらえる。この話が目新しく聞こえるとしたら、それはプロジェクトの成功と失敗の基準が、案外不明確であることを意味する。PM学会の参加者でさえそうなのだから、世間では認知されていないかもしれぬ。そこで本稿で、補足して少し説明することにする。

いま、あるプロジェクトを海外の顧客から受注した、としよう。しかし、そのプロジェクトでは、どうやら顧客要求事項が当初よりふくれる気配がある。理由は顧客にとっての市場環境の変化である。さて、これはリスクだろうか?

一つのポイントは、海外顧客であることだ。国内の、それも長年つきあいのある顧客ならば、お互いにあまり無理のあることは言わないのが暗黙の約束だ。しかし、契約ベースで事を決めたがる海外顧客には、(むろん相手にもよるが、通常は)暗黙の合意や阿吽の呼吸は通じない。では、仕事のスコープとコストが増大しそうなこの状況を、危険なリスクと捉えるべきか。

答えは、「必ずしもリスクとは限らない」である。それは、契約の条件によるからだ。もしもこれが一括請負契約、すなわち一定金額ですべての役務を請け負う契約なら、たしかに役務スコープ増大の可能性はリスクであろう。しかし、これが実費償還契約、すなわちかかったコストに一定の手数料をのせて払ってくれる契約なら、仕事量の増大はむしろ歓迎すべき事だ。なぜなら、売上と利益が増えることを意味するからである。

なあんだ、と思われただろうか。だが、もし最初の質問文で「リスクかも・・」という想いが頭をよぎったとしたら、それは、自分が一括請負契約のプロジェクト運営に慣らされすぎているのである。受注ビジネスでは、基本的に赤字は失敗と見なされる。受注金額が一定で、遂行コストが増大したら、赤字の可能性が増える。だからリスクだ、と考える。

ちなみに、米国のStandish Groupによるレポートは、IT分野のプロジェクトの成功率を継続的に調査しており、IT系プロジェクトの難しさを示す統計として、よく引用される。2003年版報告によると、調査対象となった米国企業の1万3,522のITプロジェクトのうち、成功したプロジェクトは34%にとどまった。彼らのレポートでは、コスト・仕様・スケジュールの三要素を、計画通り達成できたケースを「成功」と定義している。コスト・仕様・スケジュールはプロジェクトの代表的な制約条件であり、別名『鉄の三角形』Iron Triangleとも呼ばれる。仕様(品質)のかわりにScope(役務範囲)を入れる場合もあるが、実質的にはほぼ同じ意味だ。だから、鉄の三角形を破ってしまったら、それは不成功と考える訳だ。

<プロジェクトの制約条件: コスト・スコープ・スケジュールの「鉄の三角形」>

でも、これは果たして正しいのだろうか? 試しに、視点を受注者から発注者、すなわちプロジェクトに投資する側に移してみるといい。プロジェクト事業に投資するのは、何かの目的があるからだ。業務のプロセスを改善するとか、新製品を開発するとか、新工場を建設するとかいった事業は、必ずしもそれ自体が目的ではない。プロジェクトは、新市場を開拓したり競争環境を改善したりして、事業の継続と成長を目指す手段にすぎない。

たとえば新製品開発の場合、何よりも大事なのは納期=Time to Marketで、ライバルより少しでも早く製品を上市することが求められるケースが多い。必要ならばコストを使ってでも、納期を早める。この場合、コストは決してハードな制約条件ではない。かりに予定より3割多く費用を使っても、予定より2ヶ月早く完了すれば大成功、というプロジェクトも存在するのだ。

別の例を挙げるなら、アメリカのアポロ計画は、ソ連との宇宙開発競争を制することが最大の眼目であった。ケネディ大統領が成功の目標としておいたのは、「'60年代の内に人間を月に送る」ことだ。最大の目標値はスピード(時間)であり、最大の制約事項は安全性であった。そのために、アメリカは金に糸目はつけずにつぎ込んだ。そして実際、'69年にその目標を達成した。アポロ計画にとってリスクとは、まず打ち上げを遅らせるような要因であり、次にはロケットの安全性をおびやかす要因であった。コストは目標でも制約条件でもない。だから、コスト増の要因はリスクではないのだ。

目標値が、「成果物の性能」で規定されるケースも多い。新しい通信デバイスを開発する場合、コストも予定どおり、納期も予定どおり、しかし通信速度が目標を満たせなかったら、それは明らかに失敗である。こうした場合、最大のリスクとは,何よりも性能に影響を与える因子のことである。

プロジェクトの目標値が、コスト・品質(スコープ)・スケジュールの三要素以外の場合だってあるだろう。たとえば新規獲得顧客数だとか、顧客満足度だとか、在庫削減率とか。こうした目標値は、プロジェクトが狙う真の目的から導かれる。そしてリスクとは、その真の目的に近づくことを妨害する要因である。

だから、リスクマネジメントをきちんと考えたいのならば、

何のためにそのプロジェクトをやっているのか目的)」
どういう状態になれば、プロジェクトは成功したと言えるのか目標値)」

を、最初に明確にしなければいけない。この点を曖昧にしたまま、何となくプロジェクトをスタートさせたり、制約条件であるスコープ・コスト・スケジュールさえ満たせば成功である、などと漠然と考えるから、真のリスクを見落とすのである。

たしかに、受注型プロジェクトの場合、その目的は、とにかくさっさと手切れ良く仕事を終わらせて、利益を出すこと、というパターンが殆どだ。だからどうしても『鉄の三角形』の制約条件ばかりに目がいきがちになる。だが、制約それ自体は目標ではない。100m競争に出場して100mの距離を走るのは制約(要求事項)であって、目標値ではない。さすがにゴールまでたどり着けなければ明らかに失敗だが、ふつう、目標値としては、12秒台で走るとか、新しいフォームを試すとかいったことを掲げるだろう。そうして、結果を見て成功か失敗かを測るのである。

もっとも、仕事のスタートにあたって、目標値(=成功を測る基準)を明確にしない組織には、ひとつの心理的な傾向がある。それは、“失敗をひどく嫌う”傾向である。失敗するとひどく罰せられる。だから、失敗も成功も曖昧にしておく。せいぜい、抽象的な言葉だけで目標を設定する。そうすれば、終わってから言葉で言い抜けるのは可能である。数字で目標など設定しようものなら、成否は明らかになってしまう。

こういう組織は、自己の失敗経験から学ぶことができないのは明らかだろう。すべては成功であり、反省の材料ではないからだ。失敗が許されない組織とは、じつはもっとも生存のリスクが大きい組織なのである。

上にのべた講演では、かつてわたし自身がやってしまった、「納期も予算も仕様も満足させたが、ユーザーがちっとも使ってくれなかった」システム開発の経験を例に挙げた。恥ずかしい話である。だが、「使われなかったシステム」というのは、案外多くの会社にもあるのではないか。この場合、Standish Groupのモノサシでは、成功プロジェクトということになる。しかし、これは成功だろうか? 一番大事なリスクを見落としていたのだ、というのが、今のわたしの率直な反省なのである。

→「革新的生産スケジューリング入門」にもどる

『ポジティブなリスク』の正体をさぐる (2014/03/11)

リスクという言葉は、今日、非常に広く使われているが、じつはかなり多義的な概念である。そのため、「リスク」について人と話すとき、同じことをしゃべっているつもりで、けっこう理解がずれていることがある。「リスク学」ないし「リスク・マネジメント学」はまだ発展途上の学問で、あらゆる分野で共通した用語定義は、まだ確立していない。

しかし実務の世界では、今やリスクの話題を避けて通れない。リスク・マネジメントをコンサルティングの仕事にしている人たちも大勢いるし、資格認定制度も出現してきた(それも複数ある)。そしてプロフェッショナルを任ずる人たちは、たいがい“自分の流儀が普遍的に正しい”と主張したがる。だから、リスクの話を聴いた人は、ふうん、そんなものか、と理解する。とうぜん、誰から最初に話を聞いたかで、同じ会社でも違うリスク概念が共存することになる。その結果、「リスクについて語ること自体がリスキー」な状態になると、以前このサイトでも書いたとおりだ。

今回は、その中でも、最近はやりの「プラスのリスク」「ポジティブ・リスク」について論じてみよう。リスクというのは、結果に対するネガティブな可能性を言う、というのが普通の理解である。では、ポジティブなリスクとは何を意味するのか? タバコの火の消し忘れで火事が起きる、というのが普通のリスクだが、タバコの火の不始末のおかげで家が立派になる、なんて可能性があるというのだろうか?

この話を理解するには、“リスクの歴史”を考えてみなければならない。時計を少し巻き戻す。今から約20年前の1995年、阪神淡路大震災が日本を襲った。恐ろしい規模の災害は、日本経済にまだ多少は残っていたバブルの余熱を、完全に消し去るほどインパクトがあった。神戸を中心に、大企業も中小企業も被害にあった。このとき注目を集めるようになったキーワードが、「危機管理」だった。今ならば、BCP(事業継続計画)とかレジリエンシーとか呼ぶだろうが、当時は危機という言葉がビビッドだったのだ。

危機管理という用語が、しだいに「リスク・マネジメント」というカタカナ言葉に置きかわっていくのは、2000年頃からだろうか。なにせ、四文字熟語=オジンくさい、外来語=カッコいい、という淘汰の法則は、われらが文明開化以来、150年間を貫く潮流である。これは当然の流れだ。

ところで'90年代の後半、海外のリスク研究の主流は、安全・環境・医療・防災などの分野であった(Health Safegy & Environmentの頭文字をとって、HSEと略すことも多い)。こうしたHSEの分野では、基本的にリスクはネガティブ・リスクのみである。たとえば、1999年の安全に関する国際規格「ISO/IEC Guide 51:1999」では、リスクとは

 「危害の発生確率と危害のひどさの組合せ」

と定義されている。

ところが、2000年ぐらいを境目に、リスク・マネジメントの世界に、金融工学の影響が大きく及ぶようになる。2000年と言えば米国ではドットコム・バブルの時代である。そして企業買収がビジネスの花形のようになっていた。

金融の世界でのリスク概念は、安全・環境・医学などの分野とはかなり違う。金融では、原則として「リスク」と「リターン」が、ワンセットの概念になっている。たとえば、株に投資した場合を考えよう。株には値上がりの可能性も、値下がりの可能性もある。もともと、完全市場では商品価格はランダム・ウォークする、というのが経済学の理論だ。そのランダム・ウォークの程度の激しさ、ばらつきの強さを、リスクと考える。だから、暴落で手ひどい目にあうのもリスクだが、値上がりでウハウハ、というのもリスクなのである。

金融工学の影響は、経営学やビジネス論の分野にも大きく及んだ。この流れの中で、「リスクにはプラスとマイナスの両面がある」という思想が広まる。もう少し正確に言うと、「リスクとは不確実性のことであって、それゆえプラスにもマイナスにもばらつく」、となる。「だからマイナス・リスク(脅威)は避けて、プラスのリスク(好機)はつかめ」というような指針が出てくる。2009年に制定された、ISO 31000:2009の「リスク・マネジメント−原則と指針」では、

 「目的に対する不確かさの影響」

がリスクの定義とされる。明らかに、プラスもマイナスも含む書き方だ。同じISOの標準規格の間でも、10年間の間に、ずいぶん違ってきたことが分かるだろう。

リスクについての二つの態度を区別するために、本サイトでは、「リスクにはプラスもマイナスもある」と考える立場を『対称型リスク』概念とよび、「リスクはマイナスのみ」と考える立場を『非対称型リスク』概念と呼ぶことにしよう(「両側リスク」と「片側リスク」と呼ぶ人もいる)。金融分野では対称型、健康・安全などHSE分野は、非対称型でものを考える傾向が強い。

さて、ここから先はわたし個人の意見であるが、生産マネジメントやプロジェクト・マネジメントでは、どちらの立場で考えるべきなのか。ISO 31000の方が「新しい」から、あるいはISO/IEC Guide 51などはもう古くて「時代遅れ」だから、対称型をとるべきと単純に考える論者もいる。だが、ちょっと待ってほしい。両者の違いは、単なる思潮の新旧だけなのだろうか。

図を見てほしい。いま、仕事に関する何らかの成果指標に注目しているとする。速さでも、生産性でも、リードタイムでもいいだろう。これは、仕事に内在する問題や外乱のために、ばらつきが生じる。横軸は成果の尺度で、縦軸はその頻度である(図1)。現実には、こんなきれいなつりがね型の正規分布にはならないものだが、ここでは分かりやすく描いている。

リスクに対する「対称型」の立場とは、平均的な期待値を中心に、両側に対するばらつきをリスクととらえる(図2)。他方、「非対称型」の立場では、達成可能な最善値から逸脱する可能性を、リスクととらえる(図3)。つまり、この二つの立場とは、最善の状態と平均(普通)の状態、どちらを主眼と見るかの差だということが分かるはずだ。数学的な意味では、両者はほぼ等価に見えるだろう。

たとえば、外注制作を依頼する系列会社があったとしよう。100個を作らせると、早ければ4週間で上がるが、たいていは遅れがちで平均5週間かかり、ひどいと7週くらいかかとしよう。1週間あたりの生産性で見ると、平均値=20個、最善の値=25個、最低値=14.3個である。この工程のリスクを洗い出すときに、「対称型」の立場では、プラスのリスク(5個分)と、マイナスのリスク(5.7個分)がある、と考える。「非対称型」では、平均して5個分の生産性低下リスクがある、ととらえる訳だ。もちろん、どちらの立場でも、計画立案においては「標準値+リスク」で計画するから、数字的にはかわらない。

では、どちらの立場をとっても同じなのか? いや、そうではない。マネジメントにおいては、非対称型の立場の方が、ずっと有用なのである。それは、リスクがゼロになったときのことを考えてみれば分かる。

平均的な状態を基準にとって、そこからのばらつき(変位)をリスクととらえる場合、もし幸運にもリスクがなくなったら、達成される結果は、平均値でしかない。しかし、最善の状態を主眼として、そこからの逸脱をリスクととらえる立場では、リスクゼロとは、最善の状態を意味する。リスクを抑え込めば、最善の結果を得られる。これが「非対称型リスク」の見方なのだ。

非対称型リスクの立場では、リスク要因とは、最善の結果を妨げる可能性である。それを分析し、コントロールし、とりのぞこうとする活動は、必然的に改善指向になる。次回はもっと良い結果を得よう、そういう気持ちに人を導く。他方、平均的状態を基準に考えると、次もまた、その標準に留まる可能性が高い。

ここが、純粋に理論の世界である数学と、人を動かすためのマネジメント論とのちがいなのだ。だから、上の例では、週25個を目標値に設定し、結果が未達だったら、リスクの原因を分析して、改善のためのPlan-Do-Seeサイクルを回すようにするべきである。

もっとも、生産ではなく配当利回りのような金融収入的な項目なら、対称型でリスク分析してもいい。そうしたものは純粋に市場(外的条件)で決まり、自分達のコントロールや改善がおよぶものではないからだ。ただし、その場合は、リターンとセットで評価すべきである。

わたしは以前、対称型と非対称型の二つの立場を止揚するために、両者に共通するリスクの定義を提案した。それは

 「目指すべき目標値ないし理想状態から逸脱する可能性があり、かつ、その影響をリアルタイムに回避・抑制できないような事象(群)を、リスクと呼ぶ

というものだ。医学・環境学系の立場では「安全性」が理想状態であり、金融工学では「確実性」(=ばらつきゼロ)を理想状態ととらえる。そして、“何が理想状態(あるべき姿)なのかを、議論の出発点として明確に”してから、リスク・マネジメントを進めよう、と書いた。

リスク・マネジメントの目的は、リスク評価(アセスメント)を行って、事前に回避したり、リスクを小さくすることだけではない。それはやるべきことの半分に過ぎないのだ。事後のリスク要因分析をして、現実を理想に近づける努力が残りの半分である。リスク・マネジメントとは、わたしたちが現実を直視して、そこから少しでも学んで賢くなるために行うのだ。もちろん、ISOのような世界標準に対して、わたしの声は微力である。しかし、最善の状態を主眼として、そこからの逸脱をリスク要因として分析するほうが、仕事の改善と人の成長のためには役に立つと信ずるのである。

→「革新的生産スケジューリング入門」にもどる

稀な危機 vs ありふれた失敗−リスク対策の優先順位を考える (2013/10/20)

ジェッダから紅海に沿って北に向かう道を、わたし達は走っていた。空港で入国審査に手こずり、思った以上に時間がかかって遅れている。ドバイからジェッダに飛行するよりも長い時間を、パスポートコントロール窓口の行列に費やしてしまったのである。現場事務所に着いたら、「自分のスケジュール・リスクはマネージできないようですね」と皮肉を言われかねない。わたし達は、プロジェクトのリスク・アセスメントのセッションを開催するために、現地に向かっていたからである。おまけに、プロジェクトにおけるわたしの主な守備範囲は、スケジューリングとリスク・アナリシスであった。それが打合せに半日も遅れたんじゃ、面目丸つぶれである。

もっとも、同行している某国営石油会社のエンジニアにしてみれば、これは十分予見できたことらしい。彼の会社では、移動日には会議を入れるな、という内規があるという。飛行機の移動にはおもわぬ出来事がつきものだし、おまけにお役人の非効率は今に始まったことではないから、誠にごもっともである。クロアチアでのIPMA(国際PM協会)の世界大会(「プロジェクト・マネージャーが魔神に願うこと ―― 国際PM大会2013に参加して」参照)に出席した後、わたしは勤務先のプロマネ、ならびに顧客のエンジニアと合流し、中東を出張で回った。それが、7日間に乗り継ぎを入れて合計7回飛行機に乗る、というハードスケジュールだったため、「日本人はクレイジーだ」とあきれられた訳である。それでも我慢してつき合ってくれた彼には、大いに感謝した。

わたしだって、何も飛行機が好きでそんな日程を立てたわけではない。ただ、フライトや場所や費用の都合で、どうしてもそうなってしまったのである。彼が飛行機嫌いでなくてラッキーだった。世の中には飛行機が大嫌いな人もたくさんいる。前回ご紹介した自称"Lazy project manager"ことPeter Taylor氏もその一人であった。大西洋を橋で渡りたい、というくらいなのだ。

飛行機が嫌いな人は、落ちたらまずお陀仏だから、という直感があるのかもしれない。それはその通りである。いくら事故統計では飛行機より自動車移動の方がずっと事故の確率が高い、と言ってみても、人の心理は数字上の理屈を超えている。空気よりも重いものが空を飛んでいるのだから、どうしたって直感的には無理がある。おまけに飛行機事故は派手だ。新聞で大きな記事になりやすい。自動車事故は大小あれど、遺憾ながらありふれている。だからどうしても派手な方に注意が向く。

稀な危機と、ありふれた失敗。リスク・マネジメントではどちらを注視すべきか−−そういう問いを、わたしはときどきセッションで参加者に問いかける。ご承知だと思うが、標準的なリスク・マネジメントの進め方では、リスクの大小を、

 (与えるインパクトの大きさ)×(発生する頻度)

のかけ算で整理する。この目的のために、横軸に「インパクトの大きさ」(影響度)、縦軸に「発生頻度」をとった2次元のマトリクスをしばしば用いて説明する。

当たり前だが、右上の象限(A)にあたる部分は、「インパクトが大きく・かつ・頻度も高い」リスクのカテゴリーを表す。だから、リスク対策ではここが最優先になる。

逆に、左下の部分(D)は、「インパクトが小さく・かつ・頻度も低い」リスクである。こうした類は対策の優先度が一番低くなり、まあ無視しておくか、起きてから考えればいいじゃないか、という風になるあろう。それはそれで、経済合理性のある態度である。

問題は、左上の「インパクトは小さいが、頻度が高い」リスク(C)と、右下の「滅多に起こらないが、インパクトが大きい」リスク(B)との比較である。「ありふれたトラブル事象」と「希な危機的事象」の比較と言いかえても良い。たとえば、ありふれたトラブルの例は、設計ミス、資材価格上昇、などだ。他方、大地震、戦争、テロ等が、稀な危機のケースである。

わたし達がリスク対策にかけられる費用や時間は、有限である。両方ともに対策をたてられれば万全だが、どちらかを優先せざるを得ない場合も多い。その時、どちらを選ぶべきなのか。稀な危機か、ありふれた失敗か?

答えは簡単である。“どちらが過去から学びやすいか”を考えればよいのだ。ありふれた失敗は、過去にも似たようなことをたくさん経験しているはずである。一方、稀な危機事象は、稀なるが故に、滅多に遭遇しない。大地震や津波がそうしょっちゅう起きてもらってはこまる。

そうなると、過去の失敗に学びやすいのは、ありふれたトラブル(C)の方だと分かるだろう。こちらの方が、稀な危機(B)に比べて過去に学ぶ作業のコスト・パフォーマンスが高いのである。飛行機で移動するとき、注意すべきなのは墜落事故ではなく、ありふれた遅延なのである。そのことを、わたしはこの日、あらためて思い知らされたわけだ。

それなのに、いざリスク・アセスメントのセッションを開くとなると、しばしばテロや大地震といった派手な危機をあげたがる人が出てくるのはどうしてだろう? −−それは、前にも書いたように、そうした出来事がメディアに取り上げられ、記憶に残りやすいからである。設計ミスなどのありふれた失敗は、自分がそれでよほど手痛い目にでもあわない限り、記憶に残りにくい。いや、むしろ忘れやすい。できれば自分が不完全だったことなど忘れたい。そう、誰しも思う。

だとしたら、リスク・アセスメント・セッションの進行役など、ずいぶんありがたくない仕事である。人が思い出したくない過去の失敗を思い出させよう,というわけだ。しかし、それもやむを得ぬ。ありふれたトラブルというのは、たいていの場合、組織の内部環境に起因する『内部リスク』と呼ばれるものである。それに対し、稀な危機は外部から突発的にやってくる『外部リスク』がほとんどだ。外部リスクは目立つし、発生すればすぐ誰もが認識する。しかし、内部リスクというのは、じわじわと発生し、問題を悪化させて、気づいたときにはすでに手遅れになることが少なくないのだ。外部リスクを飛行機事故にたとえれば、内部リスクは生活習慣病のようなものである。

そう考えると、リスク・アナリシスの担当者は、人間ドックの医師みたいなものだ。リスク低減の処方くらいは書けるが、主体となってリスクを低減できる訳ではない。それができるのは、つねに仕事の「生活習慣」を作り出している自分達の方なのである。

(追記)
上に書いたのは、自分達が主体的にすすめるプロジェクトなどの事業におけるリスクの話である。つまり、便益を得るのも自分なら、リスクをテークするのも自分、というときの論理だ。自分の便益のために、他人や環境にリスクを晒すような、はた迷惑な場合とは理屈が違うので、誤解無きよう。

→「革新的生産スケジューリング入門」にもどる


戦略的プロジェクトとリスク・プレミアムの原理 (2010/10/31)

プロジェクトと戦略という言葉は、切っても切れない関係にある。戦略が何を意味するかについては諸説あるが、少なくとも戦略的に何事かを行うことは、同じ業務をルーチン的に繰り返すのとは違った側面を持っているはずである。つまり、特定の目的を持つ、時限的な営為なのだ。ということは、戦略がプロジェクトを生み出すケースは非常に多いわけだ。

ところで、プロジェクトとは失敗のリスクをともなう事業である。このことは、すでに何回も書いた。そして、戦略とは仮説に基づく一種の賭けであって、裏目に出る可能性もあることも前回書いた(「戦略シンドロームと改善病」2010/10/23参照)。では企業が、戦略的なプロジェクトに対して投資する資金は、どのように保証するのか? いいかえるなら、企業の投資行動に対する「保証料」(リスクのコスト)はいくらが妥当なのか。タダで賭けはできない。虎の子を賭けに使うなら、それに伴う見えない費用がある。今回は、それについて簡単に考えてみたい。

−−ある日、小学生の息子がやってきて、「お父さん、お金を1,000円、貸してくれない?」ときく。何に使うかを質問してみると、何やらゲームキャラクターのカードを買うとクジを引けて、珍しい景品がもらえるのだという。景品が当たったら、それを友達に2,000円で売る約束ができているらしい。つまり、 1,000円は息子にとって一種の投資なのである。うまくすれば、2,000円の収入を得るという寸法だ。

ただし、必ずクジが当たるとは限らない。ネットで調べてみると、どうやら当たりの比率を7割程度に設定しているらしい。わたしは息子の投資に、1,000円を貸すべきだろうか?

この息子の投資事業が失敗するリスク確率は30%である。そこで、事業の期待値を計算してみると、
 (1-0.3) x 2000 - 1000 = 400 (円)           ・・・(1)
とプラスになる。だから、投資の価値はありそうである。

しかし、ここでふと、息子に対して、「お金を借りると利子がかかる」ということを教えてもいいと思いつく。それでは、自分はいったいいくらの利子を息子に課すべきであろうか。もともとわたしの自己資金なのだから利子ゼロでも良いのだが、ちょっと考えてみよう。

かりに利子率をRとしてみる。息子がクジにあたったら、得た収入から、貸した元金の他にさらに1,000・R円を返してもらえる。その確率は70%である。一方、息子に1,000円を貸しても、クジが外れたら、息子は他に蓄えがあるわけではないから、借りを返済できなくなる。つまり、1,000円の融資額を失う場合の期待値は、失敗のリスク確率30%を乗じて、-300円である。

すると、貸し手としてのわたし自身のキャッシュフロー期待値が、マイナスにならないためには、
 (0.7)・1000・R - 300 >= 0
でなければならないはずだ。すなわち、利子率Rは
 R >= 300/700 = 0.429           ・・・(2)
これが、わたしが損をしないための条件である。結構高い。

つまり、わたしは(いや、たとえ誰であろうと)息子の事業にお金を貸す場合、1,000・R = 429 円以上の利子をつけないと、損をすることが分かる。その理由は、小学生の息子に担保能力がないからである。

さて、今度は息子の側に立ってみよう。この事業投資の期待値は400円だ。だが、利子を429円も課されてはマイナスになってしまう。したがって、残念ながらこのプロジェクトは成立しないのである。

一般に、失敗すれば全額を失うような投資額Cに対して、利子率Rを決める場合、プロジェクト失敗のリスク確率をrとすると、
 (1-r) RC > rC               ・・・(3)
が成り立たなければ、その費用を融資するものは居ないだろう。このとき、プロジェクトの期待値は
 (1-r)S - (1+R)C > 0            ・・・(4)
となっている必要がある。式(3)より、最低利子率Rは、
 R = r/(1-r)                  ・・・(5)
という、きわめて単純な基準が得られる。たとえば、リスク確率r = 20%なら、最低利子率Rは 0.2/(1-0.2) = 25%になる。rが10%なら、利子率Rは11.1%である。

なお、式(5)は投資額Cも収入Sも関係がなく、リスク確率rのみで決まることに注意してほしい。おまけに、利子とはいうものの、時間の項は出てこない。このプロジェクトが完了して収入を得るまでの時間は1日かもしれないし1年かもしれない。だが、それが成功裏に終わったら、元本Cを返済するのみならず、RCの金額を貸し手に払うのである。なぜなら、貸し手はその資金運用の自由度を下げて「失敗のリスクにさらしてくれた」からである。

経済学によると、利子とはマクロな資金市場における需給バランスと金融政策によって決まることになっている。そして、式(5)で現される項は、普通“リスク・プレミアム”と呼ばれる。お金を貸す場合は、通常の金利をベースにして、そこにリスク・プレミアムを上乗せして貸せ、と言われている。だが、経済学は利子という現象の値については議論するが、それがどのような原理に立脚しているのかは教えてくれない。

わたしは、実は式(5)の項こそが「利子」というものの本来的な起源ではないかと考えている。利子とは、失敗のリスク確率によって定まるのである。そこでこれを、これを「無担保投資の利子率の原理」と呼ぶことにしたい。

ご存じの通り、近世までのキリスト教、そしてイスラム教では現代でも、利息を取ることを禁じている。なぜなら、「お金がお金を生み出すのは自然法に反し、不正だから」という訳である。こうした宗教的テーゼには同調しないとしても、『利息』というものに対してなんとなく漠然とした違和感を感じている人は、現代でも多いのではないか。実はわたしも、長らくそう感じていた。

しかし、上記の(5)式に気がついたとき、目の前の霧が少し晴れたような気がした。別に金貸しの肩を持って、その仲間に入ろうという訳ではない。ただ、プロジェクトにリスクが不可避的に付随することは事実だ。そして、貸し手がそのリスクに対して中立であろうとするならば、最小限の利子が必要となるのは理論的必然だからである。

では、ある部門が戦略的な賭けを行って投資する場合の「貸し手」とは誰か。それはもちろんその企業自体である。そして、企業のトップ自身が投資を決める場合の「貸し手」とは、株主である。したがって、投資を行う部門は、直接の利得以外に(5)式に定められる金額を、企業・株主に対して負っていると考えられる。

なお、もし実行主体に担保がある、あるいは、プロジェクトの失敗時にも残存価値がある場合は、条件式(5)は少し緩和される。失敗時の担保価値(残存価値)の投資額Cに対する比率をαとすると、
 (1-r)RC >= rC - αC の条件より、
 R = r(1-α)/(1-r)   ・・・(6)
となる。たとえば、α=0.9 (担保価値は貸し金の90%)だったら、Rは式(5)の値の1/10になる。だから、住宅ローンのように十全な担保を設定できる貸し手は、あまりリスク・プレミアムRの評価に頭を使う必要がない。同じように、従来の日本の銀行融資は、もっぱら担保主義であった。だから、市場金利をベースに商談を決められたし、だからこそリスク評価の能力がさっぱり向上しなかったのだとも言えよう。

もっとも、上記の話を、ある一流企業の技術部門の人たちに説明したら、「そもそも失敗中断するかもしれない事業に会社が投資するなんてあり得ない」という反論があった。なるほど、そうかもしれない。しかし、その会社でも、結果がゼロになるかもしれない「賭け」に似た投資的行動が定常的に行われている部門が、二つあるはずなのだ。

その一つは、「研究開発」である。研究開発は、未知なる結果を探求して行われる活動だ。必ず成功するとは誰もわからない。

いや、かりにその企業にR&D部門が無いとしても、ほぼすべての会社に、最低もう一つ、定常的に失敗のリスクをともなう担保無き営為を繰り返す部署がある。それは「営業」である。営業はさまざまな案件を追うのが仕事だが、いつでも競争に勝って受注できるとは限らない。では、営業におけるコストとリスクのバランスは、どう考えるべきなのか? これについては、項をあらためて、また書こう。

→「革新的生産スケジューリング入門」にもどる

営業活動という名前のプロジェクト − そのリスクとリターンを考える (2010/11/07)

プロジェクト型の事業はふつう、初期には費用を使って、成功するとリターンを得るというキャッシュフロー構造をしている。言いかえれば、最初に投資が必要で、完了時に回収する仕組みである。受注型プロジェクトでも、最初は人件費や外部コストがかかり、成功裏の完了すると支払を得るわけだから、時間的な構造は同じである(会計的には「投資」扱いにならないとか、一部の「前払金」があり得るなど、細かな差違はある)。

いうまでもなく、多くのプロジェクトは失敗のリスクをともなっている。すなわち、初期の投資を回収できずに終わる可能性が(大小はともあれ)存在する。いま、プロジェクトの初期投資額をC、成功時の収入をSとし、かつ途中で中断失敗するリスク確率をrとすると、プロジェクトの生み出す価値の期待値は、非常に単純化して言うならば
 (1 - r)S - C       (1)
で表されることになる。これがプラスでなければ、そもそもやる意義はない。

さて、プロジェクトの投資主体が、自分では資金を持っておらず、また担保能力も有していない場合は、外部から資金調達しなくてはならない。このときは、貸し手の側から見ると、そのプロジェクト事業のリスクに応じて、一種の利子を要求することになる。貸し倒れの可能性があるからだ。利子は、最低でもデフォルト(=貸し倒れ)損失を上回るよう設定する必要がある。デフォルト状態に陥る確率は上記の通りrである。このとき、最低利子率Rは
 R = r/(1 - r)       (2)
となることを、前回説明した(『戦略的プロジェクトとリスク・プレミアムの原理』)。

無担保でお金を貸すようなことが世の中にあるわけ無い、とお思いだろうか? それが、あるのである。事業の将来収益自体を担保に取ることで、事前の担保無しで資金調達する手法だ。事業主体となる企業は特定事業目的の子会社(SPC)を作り、親会社の連帯保証無しで融資を求める。これをノンリコース・ローンと呼ぶ。プロジェクト・ファイナンスの分野の手法であり、海外の巨大エネルギー系プロジェクトなどで、ときどき用いられる。融資側は無論、プロジェクト事業のリスクについて詳細な評価をして利率を決める必要がある。世界でもこうした審査ができるのは、トップクラスの一部金融機関に限られる。日本では、東京ディズニーランドの事業を開始する際に、同様の手法がとられた事が知られている。

ところで、そんな大げさな話ではなく、どこの企業にも、失敗すると無に帰する投資事業が二つあるのである。その一つは、R&Dである。研究開発は、確かに投資だ。そして、必ず成功するとは誰にもわからない。まあ、失敗確率の低い「改善研究」だけに集中する企業はあるだろう。そもそもR&Dを持たない企業もある(米国には、経営者が引退前にボーナスを稼ぎたいがために、お金のかかるR&D部門を閉鎖してしまうケースさえある!)。

そして、もう一つ、もっと日常茶飯的に、非常に大きな失敗のリスクをともなう仕事がある。それは営業における案件の受注活動である。顧客がある案件の引き合いをかけてきた。ライバルのX社・Y社にも声がかかっているようだ。しかし売上低迷の折、ぜひともこの案件はものにしたい。御見積書にきちんとした技術提案書をつけて、ベスト・プライスでオファーしよう。こんな光景は今どき、どこの企業でも見られる。なにしろ、見込生産で製品を大量に作っておけば、端から売れていった時代はとうに終わっているのだ。

受注活動それ自体を、一つのプロジェクトと考える。これはある意味、ごく当然なことである。では、その収支はどうなっているのか。そしてそのリスクは?

そこで、ちょっと考えてみよう。今、受注金額1000万円クラスの案件があるとする。原価をざっと積んでみると700万円であった。うまく受注できれば、300万円の利益が出る。では、この案件の受注活動には、いくらまで営業費用をかけられるだろうか?

式(1)で言うなら、将来収益S=300万円である。一方、初期投資額C=営業費用になる(受注しなければ製造原価700万円もかからない点に注意)。では、失注確率rは? もし顧客が恒常的に3社合見積をとっており、かつライバルとの実力が拮抗しているなら、受注確率は1/3、失注確率r =2/3=0.67となる。単純に考えれば、(1)式がプラスになればいいのだから、
 (1 - 0.67)(300万) - C >= 0 すなわち、C <= 100万円
で、営業費用は最大100万円まで許されるように思うだろう。

ところが、この案件を失注したときのリスク費用がここには抜けている。リスク費用は、利率と投資額の積R・Cで表される。つまり、無担保投資の場合、式(1)は次のように修正しなければならない。
 (1 - r)S - (1 + R)C >= 0       (1')
これと、先ほどの式(2)を組み合わせると、次の条件式が得られる。
 C <= S・(1 - r)^2             (2)
ただし、^2は2乗の意味である。これに先ほどのS=300万、r =0.67を代入すると、
 C <= 33.3万円
という事になる。営業費用は、最大で33.3万円しか許されないのである。

ということは、何を意味しているのだろうか。勝率が1/3の賭け、いや、「受注活動プロジェクト」に投下できる費用は、粗利益の1/9以下にしなければならないということだ。上記の例では、製造原価に対する販売費比率は4.7%以下となる。それ以上費用をかけていると、企業全体では失注リスクのためにマイナスになってしまうのだ。では、あなたの会社の販売費比率は平均でいくらだろうか? そして失注確率は?

ちょっと待て、その論理はおかしい。会社が営業活動の費用に対して「利息」をチャージする意味など無いはずだ。なぜリスク中立であらねばならないのか? 営業部門の経費は固定費として予算化されているではないか。そもそも、営業費用などせいぜい電話代と交通費程度だから、個別案件に33万なんて使うわけも無い−−こう反論される方もいるかもしれない。しかし、それは営業部門の直接経費だけを見た場合である。受注生産の場合、見積を行うためには、必ず技術部門や生産管理部門の手伝いが必要となることを忘れてはいけない。技術提案書を作るには、ライン部門の人を動かさなければならず、その人件費は会社が負担しなければならないのである。

ちなみに33万円なんて、ちょっとしたクラスのエンジニアなら2週間以下の工数相当である。あっという間に使い切ってしまう金額だ。まして、製造部門が子会社だったら、どうか。あるいは、海を渡ったアジアの別会社だったら? その失注リスクは、誰が負担するのか。

しかし、見積に人件費を使うから、それを支払ってくれ、と要求しても、たぶん大方の営業部門の答えはNOだろう。「見積は無料に決まっている!」と営業本部長あたりに怒鳴られて終わりである。その結果起こるのは、製造部門の見えないコスト上昇だ。見積失注負担をどのように扱うかは、その企業の原価管理のやり方によって違うが、多くは不稼働損の形で原価差額に期末に繰り入れるだろう。つまり、ライン部門の人は誰も知らぬうちに、いつのまにか部門全体の単価が上がる形で処理されるのである。

こうして、「どうしてウチの製造部門は高コスト体質なんだ!」「だから仕事が取れないんだ!」と営業や本社が怒る状態が出来上がる。元はといえば、失注リスクに伴う見えないコストを、製造ライン部門につけ回した結果で起きたのに。

この問題を解決する方法はあるだろうか。少なくとも、わたしの思いつく答えは一つである。それは、「ムダな受注活動プロジェクトには工数を投下しない」ことだ。受注の見込のない案件には費用を使わない。案件の確度が高まるまでは人件費を投入しない。そして全体の受注確率を上げることである。(2)式では使って良い営業費用は受注確率の2乗に比例する。上記の例で、もし受注確率が1/2なら、C=75万円、確率が0.7なら、Cの上限は150万円近くなる。

受注確率を上げるとは、すなわち案件の状況を冷静に見て、無駄な戦いは省くということである。戦いを略すこと、これを戦略という。もう一度聞こう。あなたの会社の販売費比率は平均でいくらだろうか? そして平均受注確率は何%だろうか? こうした数字を、営業部門は客観的に把握しているだろうか。それこそが、高コスト体質改善の第一歩となるはずである。

→「革新的生産スケジューリング入門」にもどる

マトリクス組織の情報セキュリティ

わが国には、経済産業省が認定する正式なプロジェクト・マネージャーの資格がある。といっても、じつはIT業界の話だ。情報処理技術者試験の一つに「プロジェクトマネージャ」と呼ばれる種目があるのである。かつての「特種情報技術者」に相当する後継資格として、10年ほど前から設置されたものだ。最初は受験者が少なかったが、近年かなり増えてきている。

ところで、つい最近、その試験センターが、来年度よりプロマネ試験の時間と出題数を少しだけ増やす、と発表した。理由は、昨今の状況に鑑み、情報セキュリティ関係の知識を問う試験範囲を強化するためであるという。また、この秋に行われた試験でも、論文テーマの一つに機密管理が取りあげられた。個人情報漏洩に関わる問題が頻発している情勢では、当然の処置とも言えるだろう。

ところで、企業には、B2C型とB2B型の二種類がある。個人顧客を相手にしたB2Cビジネスでは、個人情報が最大の管理対象になる。小売業・製造直販業などがこれである。これに対して、企業間取引を主体とするB2Bビジネス(製造業・建設業・卸売業など)の場合は、個人情報を扱わないからセキュリティ対策は楽かというと、決してそんなことはない。取引情報=トレードシークレットが機密とすべき重要情報にあたる。漏洩の被害でいえば、金額ベースならばこちらの方が甚大かもしれない。

このB2B型ビジネスにおける情報セキュリティの問題については、今のところ重要な視点が欠けているように思われる。それは、マトリクス型組織における情報のアクセス・セキュリティである。従来のピラミッド型(縦型)組織とは、全く異なるポリシーが必要とされていることに、多くの人が気づいていないらしいのだ。

もともと、情報セキュリティ対策には3つの階層がある。1番目は、物理的なアクセス制限。計算機室に簡単に出入りできないようにする、端末に物理的なロックをかける、といった段階だ。2番目は、OS・ネットワークレベルでのセキュリティである。例えば通信における暗号化、OSやDBMSレベルでのセッション管理などがそれにあたる。

そして3番目が、アプリケーション・レベルでの情報アクセス制御である。誰がどの情報に対してRead/Writeの権限を持つべきなのかを、コントロールする仕組みである。そして、このアクセス制御の仕組みは、ふつうユーザのグループを単位として、行なう。アクセス権限は、ユーザの職位に比例して高くする、という風に考えられることが多い。つまり、平社員より課長の方が権限が高く、課長よりも部長の方がさらに権限が大きい、といった具合だ。そして、部署ごとにユーザがグループとしてまとめられる。

しかし、よく考えてほしい。会社の中で、部署を横断するプロジェクト・チームが結成されたら、このアクセス権の構造はどうなるだろうか。そして、それが二つ・三つと増えていったら。協力会社や有力顧客・ベンダーなどとのジョイント・ベンチャーになっていったら。こうした組織では、大なり小なり、機能別縦型部署と重なる形で、横串(クロス・ファンクショナル)な指示権限が生じるのだ。こうした形態を、マトリクス型組織という。

プロジェクト中心に仕事をするシステム・インテグレータや建設・エンジニアリング業界、そして広告・イベント業界、医薬品や電子情報機器の製品開発部門などでは、マトリクス型組織はほとんど定常的な姿である。

こうした組織においては、情報へのアクセス権は、プロジェクト中心になっていなくては困る。自分がアサインされているプロジェクトの情報にはアクセスできる。アサインされていないプロジェクトの情報はアクセスできない(望むらくは、存在さえも見えない)。こういうコントロールが望ましい。そうでなければ、安心してジョイント・ベンチャーの仕事に従事できるだろうか? 

また、自分が重要な役割を果すプロジェクトでは、情報へのアクセス権が高く、自分が端役でしかないプロジェクトの情報アクセス権は限られている、という権限構造が必要である。このためには、自分の職位とは独立したアクセス権のコントロールが必要なのだ。「個人」に従属する「職位」がアクセス権を決めるのではない。「個人」と「プロジェクト」をつなぐ『役割』に準じて、アクセス権が管理できなければならない。

 × 「個人」→「職位」(係長、課長)=アクセス権
 ○ 「個人」→「役割」(プロマネ、リーダ、メンバ)=アクセス権

現在、世の中にある多くのERPパッケージや、プロジェクト管理ソフトなどは、悲しいかな、この観点での情報セキュリティ管理機能が全く欠けている。だが、今や、どんな業種の企業も部門横断的プロジェクトと無縁ではないのだ。だれもがマトリクス組織の萌芽を抱いている。それなのに、情報セキュリティの面でこれに追いついているソフトウェアは少ない。

→「革新的生産スケジューリング入門」にもどる

組織におけるルールはいかなる機能を持っているのか (2014/01/15)

今からちょうど800年前の1214年のこと。英国王Johnはフランス南西部から海軍船に乗ってブリテン島に向かっていた。当時、英国は大陸本土のフランス側にも領地を保有しており、彼はそれを拡大する野心を抱いて大陸に兵を進めたのだが、あいにくフランス王(当時は領地は小さかった)の反撃に屈し、結局撤退を余儀無くされたのだ。ようやく帰り着いた彼を待っていたのは、貴族諸侯やロンドン市民からの批判の嵐だった。すでに大陸の領地はほとんど失われていた。残ったのは不名誉と、傾いた財政である。税金を課そうにも、彼の重税や放埓は、すでに皆が辟易していたのだ。

結局彼は翌年、臣下である貴族諸侯と、ある取り決めをかわし、文書化する。いわく、

* 王の一存では戦争資金のための税金を集めることができません
* 国王は議会を召集しなければなりません
* イングランドの国民は法と裁判によらなければ、生命や財産の自由をおかされません、等々。

これが有名な『マグナ・カルタ』、大憲章である。マグナ・カルタはその後、英国憲法の基礎となる。他方、John王の方は、暗君の代表例のように言われ、彼以降800年間、誰もJohn 2世を名乗った英国王はいなかった。

それにしても、John王はなぜ臣下に詰め寄られたのか? 時代は中世、そして彼は王様である。王は国家の最高権力者。ならば何をしても勝手ではないのか。

だが、彼の臣下たちはそう考えなかったのだ。王と交渉して、その要求をのませることに成功する。それも、口約束ではなく文字に書かせた。あとで「言った・言わない」の水掛け論にならないようにである。先月、全能の審判主を相手にネゴシエーションをした、ユダヤ民族の始祖アブラハムの事を書いたが(「クリスマス・メッセージ:折れない心をもつために」参照)、13世紀初頭の英国臣民たちは、王様を相手に交渉したのだった。しかもこちらは歴(れっき)とした史実である。

John王が生まれた頃、日本では平清盛が最高権力者だったが、誰も彼を相手にネゴをかけたり、法で縛ろうとした人間はいなかったろう。英国人ははるかに先進的で、民主主義的だったのだろうか? そう説明しても良いが、もう少し別の見方もありうると、わたしは考える。

マグナ・カルタは、王の名前で発行された取り決めの文書であり、つまりである。他の法よりも上位の規定なのでCharter(憲章)とか憲法とよばれるが、つまり国という組織の中のルールである。

それでは、ルールとはなんだろうか?

たとえば、(話は急に卑近になるが)品目マスタとか従業員マスタなどでは、ふつうコード体系と発番ルールが定められている。この発番ルールというのは、はたしてルールなのか?

もちろんである。ルールとは、人々が守らなければならない規定であり、かつ、違反した場合はなんらかの罰が与えられるものだ。つまり強制力のある規定である。国の法律は、明確に罰則規定がある。マスタの発番ルールの方は、ユーザがそれを守らないと、データ登録ができない、あるいは、あちこちのプログラムがエラーを起こすという罰(?)が与えられる。

マグナ・カルタは明文化された法だが、ルールは必ずしも明文化されているとは限らない。たとえばルールは、「習慣」「伝統」のかたちで存在する場合もある。それでも、破った者は仲間から白眼視されるとか、村八分にあうとかいった罰を受ける。また、逆に組織におけるルールには、報奨の仕組みが付随することも多い。それを守ると名誉(自尊感情)が与えられ、あるいは金銭的に報われる場合もある。このようにして、アメとムチで人に強制力を与えるのである。それは平民に対しても、権力者に対しても同様である。

ならば、権力ある人間に対するルールは、どのような効果を持つのか?

答えははっきりしている。権力ある人間が、その権力を自分の好き放題に、恣意的に運用することを防ぐのである。マグナカルタが規定したとおりだ。人間の組織は、ピラミッド型の階層構造をとる場合がほとんどだ。その中での地位の高さと、権限の大きさは比例する。ところが、この権限をあまり勝手に運用されると、組織とその構成員がこまるケースが出てくる。個人の好き嫌いだけで、けむたい奴を追放したり、財産を道楽につぎこまれたりしたら、組織の存続が危うい。そこで、これをルールで縛るのである。つまり、ルールとは人間を権力の横暴から守る仕組みでもあるのだ。

ビジネスで典型的に問題になるのは、むろん人の不公正な処遇である。だが、もう少し人目をひきにくい分野でも、ルールの欠如は、よく問題になる。たとえば製品開発プロジェクトである。新しい技術やアイデアにのめりこんで、労力をつぎ込んでみたが、なかなか実らない。そうしたとき、続けるのか止めるのかの基準ルールを持っていない企業は、案外多い。ルールがないため、決定権を持っているのが誰かによって、結果として製品開発のパフォーマンスに長期的に大きな差が出る。適切なルールが決まっていれば、誰が責任者のポジションにいても、それなりのレベルが保たれる。

言いかえれば、ルールは(権力を持つ)人の恣意性をしばり、その自由度を下げることで、組織の再現性を高める(誰がやっても似た結果になる)ことを目指している訳である。すなわち、<u>ルールには予見可能性を高める効果がある</u>のである。王の行動の予見性を高めること、組織の動向や行く末を予測しやすくすること−−これこそが、John王に要求をのませた臣下たちの望んだことではなかったか。

最近の米国で、企業ガバナンスがうるさく問われるのも、このためであろう。つまり、企業に対して融資する銀行や、株式市場における投資家たちが、その企業の行動や業績が予測可能な状態に置いておきたいからこそ、ルールをうるさく求めるのである。つぎ込んだ金を、経営者が勝手に采配したり蕩尽したりしないよう、縛りたいのだ。アメリカの経営論は「リーダーシップ論」が大好きで、英明な君主が国を治めるように企業を統治することを望んでいるのに、かたやその君主の手をガバナンスで縛りたいという、一見矛盾した要求を持っているのは、このためだ。

もちろん、ルールには良い面ばかりあるわけではない。それは意思決定のプロセスを複雑化し、手続きが面倒になり、結果として組織の変化のスピードを遅くするという働きも持つ。とっぴな行動が抑えられると、独創的な人材は生きにくくなるだろう。これが行きすぎると、減点主義ばかりがはびこる、いわゆる『大企業病』にいきつく。暗愚な暴君による権力の乱用も怖いが、その対極にある、ルールの牢獄も恐ろしい。どちらも結果として、組織の活力をなくすからである。

この問題を避けるためには、どうしたらよいか。ある人々は、「ルールはある程度ゆるやかに決めておいて、『弾力的運用』でまわしていけばいい」と主張する。運用や解釈変更でカバー、という訳である。だが、このやり方は、予見可能性を高める、という本来のねらいからはずれてしまう。

もう一つの方法は、ルール自体に、ルールを見直す基準をビルトインしておくことである。組織が本来そのルールを制定したときの意図や目標に照らし合わせて、順当に機能しているかを見直し、まずければ訂正する手順を決めるのだ。そのためには、決定を下すごとに査証や情報を残し、組織のパフォーマンスの視点から、それをバックチェック可能にしておく必要がある。こちらの方が手間がかかるが、予見可能性の点でも、また目的合理性の点からも、すぐれたやり方に思う。

組織内で、どこまでがルール化され整備されているかは、その組織のマネジメント・システムの成熟度を示していると言ってもいい。それが明確で、漏れや重複がなく、しかもある程度は柔軟であるようになっていること。これが、制度設計の要所であるはずである。

→「革新的生産スケジューリング入門」にもどる

契約なんかこわくない

ちょっと、考えてみていただきたい。あなたは、ある受託プロジェクトのプロマネだとする。受注前には顧客提示の要求仕様案を慎重に吟味し、複数の外注先にも引合した上で、顧客に見積金額を提示し、ネゴシエーションを経て無事受注に至った。ところが、スタート後半年たち、設計がほぼ終わった段階で、あらためて外注先に製造の見積を依頼したら、当初の予算の5割増の金額が出てきてしまった。理由は(例によって)仕様の増大と、昨今の原材料費高騰の影響である。3社引合いを出したが、いずれも同じような回答だった・・・

この状況の時、あなたならどうするだろうか?
(1)予算がないので、意中のベンダーに対し「指し値」で交渉する
(2)発注経験はないが、安いと評判の新規ベンダーをみつけて発注する
(3)中国企業に引合いを行い、オフショア製作にチャレンジする
(4)3社の中から発注先を選び、客先には追加予算を請求しない
(5)顧客に窮状を説明し、もっと追加予算をくださいと要求する

実際に人にたずねてみると、答えはまちまちだ。多いのは(4)か(2)で、(3)は最近、人気がない。属する業界や職種でもちがうのだろう。(1)という答えは口に出さないが、現実には指し値交渉はあちこちで見うけられる。昨今の偽装問題の根っこはここらへんにあるのかもしれない。

ところで先日、関西のあるワークショップでこの問いを出したところ、(5)という回答が思ったより多かったのでビックリしてしまった。関東人である私の身の回りでは、あまり出てこない発想だからだ。契約で金額が決められている限り、身勝手な「お願い」はできない(少なくとも自分はしたくない。営業の人が代わりにやってくれるなら別だが・・)。そういう関東武士の矜持(?)があるようだ。だが、どうやら大阪では文字通り『浪花節』がまだ生き残っているのかもしれない。ま、お互い長いつきあいやないか。

困ったら取引先が助けてくれるという関係は、「契約は契約ですから」という“水くさい”関係とはずいぶん違う。そういう浪花節だけでこの世が回っていくなら、ある意味でリスク管理などいらない。泣きつけばいいわけだ。そのかわり、義理人情は「無限責任の世界」でもある。そうした息苦しい世界には、住みたくても住めない時代を私たちは生きている。

さて、そこで冒頭の問題である。じつはこの問題には正しい答えがあるのだが、おわかりだろうか?

正しい答え−−それは、「とるべき選択肢は契約の内容による」である。もし、あなたの契約が、一括請負契約(Lump Sum Turn Key = LSTK Contract)だったら、(5)は普通、選べない。しかし、実費償還契約(Cost Reimbursable Contract)だったら、あなたは胸を張って客のところに行き、追加分を請求できる。

一括請負と実費償還は、受託プロジェクトにおける契約の、二大方式である。前者はいわば、「おまかせ」型であり、後者は「お好み」型である。寿司屋に入って、「おまかせ」で食べたら一定の料金だけ払えばよい。そのかわり、あなたは好きなものを勝手に食べるわけにはいかない。「お好み」なら、自分の側に自由度があるが、そのかわりかかった費用は相手側の手間賃を乗せて支払わなければならない。

実際にはこの両者の間にはさまざまなバリエーションがあるのだが、日本では圧倒的に一括請負契約が主流である。だから最初の問題を聞いたたいていの人は、無意識に(5)は避けるのである。一括請負ならば(5)の選択肢をとる権利はないからだ。

それでも、一括請負契約で(5)を主張できるようにするためには、契約書を設計するときに、明記しておかなければならない条項がある。私は今、意識して「契約を設計する」と書いた。契約の方式と内容を考えること−−それは、プロジェクト・マネージャーの最も大切な仕事の一つなのだ。それなのに、とくにIT業界では、「契約は法務か営業の仕事」「契約書なんて読んだこともない」などというプロマネが多すぎる。プロマネは技術者あがりで、契約やら法律はわからないから、人に任せてしまう。あんな日本語離れした変な文章、見るのもやだ、というわけだ。

浪花節だけでは成り立たぬ今日、契約は、あなたを顧客の気ままから守る、ほとんど唯一の有効な手段である。そして、契約の設計は、べつに法学部出身でなくてもできる。いや、やらなければならない。契約を知らないプロマネは、6割しか役に立たないといってもいい。そこで知っておくべき原則は、基本的に三つしかないのだ。だが、いつもの私のくせで、前段が長くなりすぎたようだ。契約書なんて別にこわくない。この続きは、次回書こう。

→「革新的生産スケジューリング入門」にもどる

契約なんかこわくない(2) 契約を設計する

あなたは、自分の仕事の契約書を、始めから終わりまで、真剣に目を通したことがおありだろうか。もしなければ、車のローンでも、不動産賃貸借でも、旅行保険でもいい、手近にある契約書を一つ、ためしに頭から全文読んでみることをおすすめしたい。実際に読んでみると、たしかに退屈だが、それほど理解困難ではないことに気がつかれると思う。少なくとも、法律の条文自体よりずっとわかりやすい。なぜなら、そこには構造と意図があるからだ。

契約書というものは、たいていの場合、構成が決まっている。まず最初に、契約の当事者の定義と、言葉の定義がおかれている。それから、契約の中心部分が、簡潔に記述されている。中心部分とは、権利と義務のバランスシートだ。たとえば、Aは製品何々をいつまでに納品する。Bはその代金をこれこれの手段でしはらう、といった形になっている。Aはひとつの義務を履行すると、それにみあう権利をBに対して得ることができる。義務と権利の間には、バランスシートの貸方と借方のように、一種の等式関係が成立する(そうでなければ両者は合意できない)。これを権利義務関係という。

ところで多くの場合、契約書本文には、権利義務関係の中心部分について、金額その他の具体的な詳細が、あまり書かれてない。たいていは「添付別紙を参照」という形になっている。これはなぜだろうか。もし契約書本文に金額や製品仕様の詳細条件などを書いてしまうと、多少の条件変更をしたくなった場合(そして変更は現実の仕事にはつきものであるが)、契約書自体を改訂して捺印手続きをやり直さなければならない。正式な契約書には、「印紙税」を示す収入印紙を貼らなくてはならず(これは法律で契約金額に対する%が決まっている)、契約書を作り直すとこの費用も発生する。そこで、詳細は別紙に定めることにして、別紙のみを増補・改訂していくやり方をとるのである。

さて、中心部分の記述のあとには、権利義務関係を補完するような周辺的な条項が並ぶ。そして、契約の発効・更新・解消の条項がある。手続き論の部分だ。さらにそのあとにはたいていの場合、不測の事態に関する記述がある。言いかえるなら、義務が免除になるような免責条項だ。そして契約書の最後には、必ず「仲裁条項」と呼ばれる項目がある。この契約をめぐって紛争がおきたときは、どのような仲裁手続きをとるのかを書くのである。そして添付資料のリストをつけて、署名欄で契約書はおわる。

こうして見てみると、契約書とは、我々のよく知っているものに似ていないだろうか? まず主要変数の宣言がある。ついで、中心部分の処理がある。ただし、その処理の詳細は、別紙を参照する形になっている。つまり「モジュール化」をはかって、内部変数の詳細はメインから隠蔽しておくわけだ。それから周辺処理があり、起動と終了手続きがあり、最後に例外(異常)処理がある。契約書というのは、意外にも情報システムによく似ているのだ。だから、システムが分かる人は、契約の設計もできるはずではないか。

契約の構造設計について、もう一度まとめておこう。契約はモジュール化を活用することによって、契約書本体をあまり重くしないようにする。契約に必要な事項は、用語定義、当事者の確定、対象事項の確定、権利義務関係の記述、発効・継続・解消手続き、免責事項、紛争解決、などからなる。金銭や技術の詳細については、別紙として添付する。

では、契約の設計思想で重要なことは何か。私は、三つの原則をあげたい。それは、「当事者は対等であること」、「自由度が責任範囲を決めること」、「強制力があること」の三つである。

第一原則の「当事者は対等であること」とは何か? これは、発注者と受注者は本来対等であって、その権利義務関係はバランスしていなければならないということだ。もう少し言うと、一方のみが義務を負うような契約はできるかぎり避けろ、という方針である(こうした非対称な関係を片務性とよぶ)。たとえば、「納期に遅れたらペナルティを課す」という条項を客先が出してきたら、「そのかわり納期より早く完了したらインセンティブをもらえる」という条項を対案として出す。これが対等であることの意味だ。

当事者は対等であるので、契約の内容については互いに意見を出し合うことができる。あいにく我が国では、「お客様は神様」という言葉に象徴されるように、力関係は一方的であることが多い。いや、欧米でだって、たいていはお金を払う方が力が強いのだが、彼らの頭の中では、“両者は対等”という原則がある。だから受注側も権利は主張する。私がわざわざこんなことを書くのは、「日本ではベンダーは奴隷と同じですか?」と欧米人が口に出して質問したくなるような状況が、ときどき存在するからだ。

さて、第二原則の「自由度が責任範囲を決めること」とは何か。これは、当事者は自分に許された自由度の範囲を超えて、無限に責任をとらされないようにすべきだ、という意味である。前回、「おまかせ」と「お好み」の寿司屋の話を書いた。「お好み」では製品の選択の自由度は買い手側にある。だから注文した結果が自分の好みに合わなかった場合、客は追加でお金を払って別のものを買い直さなければならない。逆に「おまかせ」の場合、客は出されたものを食べるしかない。そのかわり、代金は一定金額で納まるのである。むろん、出した寿司の品質が明らかに低ければ、寿司屋の側が責任をとって作り直す必要がある。

言いかえるならば、不確実性のリスクは自由度を持つ側が負担すべきだ、というのが第二原則である。さらに、免責条項の中の『不可抗力』として何をあげるかも、この原則から考えるべきだ。たとえば、原材料市況全体が急変して、(たとえば)平均指標が3割以上も上がったら、それは不可抗力として価格再交渉の条件としてあげておくべきかもしれない。むろん、相手が合意するかどうかは、分からない。しかし第一原則「対等」を思い出して、まず権利を主張してみるべきなのだ。

じつは契約の論理の根底には、「自分と相手は別の存在であること」との認識が横たわっている。自分と相手は他人であって、一心同体でも以心伝心でもないから、権利義務関係はできるかぎり明確化・文書化する、ということだ。また他人であるから、責任範囲には限界がある、ということでもある。

さて、つぎに第三原則「強制力があること」に進まなければならないが、また長くなりすぎたようだ。この続きは、さらに次回書こう。

→「革新的生産スケジューリング入門」にもどる

契約なんかこわくない(3) 契約の論理の根底にあるもの

契約はプロジェクト・マネージャーが設計するものであり、その設計においては三つの重要な原則がある、と前回説明した。それは、「当事者は対等であること」、「自由度が責任範囲を決めること」、「強制力があること」の三原則だ。

「当事者は対等であること」とは、発注者と受注者は本来対等な存在であって、権利義務関係は一方的なものにならないよう、主張することができるということだ。第二原則の「自由度が責任範囲を決めること」とは、当事者に許された自由度の範囲を超えて、無限に責任をとらされないようにすべきだ、という原則である。無限責任というものは、近代法の世界では存在すべきではない、と考える。いずれも、弱い立場に立たされがちな受注者を勇気づける原則である。

では、第三の「強制力があること」は具体的に何を意味しているのか? これは、「契約は約束なんだから、自分の言ったことは責任を持って守りましょう」という、ある意味で当たり前のことの宣言だ。発注者に、言ったことを守らせる。もちろん、受注者も守る(第一原則にある通り、両者は対等なのだから)。とはいえ、これはもう少し説明が必要だろう。

以前、「受注生産という名前の見込生産」(『生産計画ワンポイント講義』2008/07/09)で、発注書無しで材料を購入する業界がある、と書いた。内示はあっても正式な発注書はなく、金額は当月納入(使用)した量に応じて単価精算する。内示と現実がちがってサプライヤーに在庫が残っても、購入側は責任をとらない(その顧客向けの商品だから転売もきかないのだが)。よく考えてみると、J-SOX法と内部監査の専門家が目をむきそうな業界慣習である。だから今後もこのような慣習が生き残るかどうかは、わからない。

しかし、サプライヤーに一方的に不利に見えるこの慣習も、じつは裏面があるという。知り合いの営業マンは、その業界に入った頃のことを思い出して、こういう。「大量の資材を、口頭の指示だけで納める習慣にはたしかにビックリしました。でも逆に、『10万本もってきてくれ』という客先の注文に対して、『すんません、9万5千本しか製造が間に合いませんでした』といえば、『そうか、まあいいよ』でお客さんの方も済んだんです。」 つまり、不良で歩留が上がらなくても、泣きつけば許してもらえた、ということである。

何を、いつまでに、いくつ、いくらで納めてほしい←→はい納めます、という約束が発注書(&受注請書)と呼ばれる書類の正体だ。つまり、発注書とは約束と合意からなる契約文書にほかならない。発注書のない業界とは、発注側と受注側に契約が存在しない世界である。そこでは、受注者が無限責任を負う代わりに、発注者は多少の甘えも許してやる。さながら親子関係のように、自他の区別のない世界なのだ。

でも、そもそもなぜ契約などというものがあるのだろうか? 八百屋で大根1本を買うのに、誰か発注書を書くだろうか? だったら容器100万本を買うのにも、なぜ契約書など必要なのか?

その答えが、『強制力』なのである。合意(Agreement)と、契約(Contract)の違いとは、後者には強制力(Enforcement)があることだ。何に対する強制かって? それはむろん、約束を守れない事態におちいることを避けるための力だ。あるいは、約束が守れない事態に陥ったとき、できるかぎり修復できるように当事者が努力するための力だ。昔から多くの社会では、約束を人前で誓い、立ち会った人々に証人になってもらうことで、社会による強制力を保証してきた。約束を守れなければ、信用を失う。結婚式が人前での誓いの形式をとるのも、たぶんこの延長線上にある。結婚は両性の合意で成立するが、それを簡単にこわせないように、「固めの儀式」でenforceするのだ。

近代社会では、人前での誓いの代わりに、紙に記してそれを証拠立てる方式が広まった。西洋では、両者が紙に自分の印章で封蝋をつかってスタンプすることで、強制力が保証されるようになった。後には、透かし入りの上質紙(これをBondと呼ぶ)にサインすることにかわった。現在では、電子的記録でも正式な契約である。

むろん、口頭での合意でも、大根1本は買える。純粋に合法だ。しかし、容器100万本を口頭依頼で納めた後、代金が支払われなかったら、どうするのか? 「ほしかったのは90万本だった」と注文主が言い出したら、どこに強制力があるのか?

契約のない世界−−すなわち、従来の日本の少なからぬ業界では、「世間的信用」がそれを保証してきた。いや、保証するはずだった、と言い直すべきだろうか。「逃げも隠れもしない大店(おおだな)の暖簾」が、裏書きだったはずだ。納入業者を泣かせるようなことはしない。商売は相身互い。以心伝心、一心同体やないか。

おわかりだろうか。契約というのは、「あなたと私は別人です」という、自他を区別する“水くさい”関係認識の上に成り立っている。別人だから、互いに思いもよらぬ事態になりうる。そうなって困らないように、約束の内容を文書で記録にして、「強制力がある」ものにする。これが契約の第三原則なのである。

だから契約書では、たいてい最後の方に、「仲裁条項」を書く。これは、本契約に関して当事者間に紛争が生じた際に、誰に仲裁を頼むかを決める項目だ。普通は裁判所か公的調停機関である。少なくとも私の知る限り、海外の契約書では、どの国の法律を適用し、どこそこの裁判所に仲裁をゆだねる、という仲裁条項がある。強制力のためである。

ところが、私の経験では、日本の契約書には不思議なことにこの仲裁条項が無い。かわりに、「両者は誠意をもって解決に努力する」という『誠意条項』が書かれているのだ。誠意! まことに日本的で、結構なことだ。他人同士みたいな「水くさい関係」は、なるべく避けたいという“大人の知恵”なのだろう。そして、他人ではないから、発注者側は好き放題のことを言って、甘えてくる。自分の側で責任を持って行うべき義務は、都合良く忘れてしまう。そして、受注者に無限責任を求めてくる。−−やはり、日本における発注者と受注者の伝統的関係は、母子関係のようなものらしい。お互い他人でもないし、逃げることもできない。

とはいえ、長い伝統社会の、決まり切った仲間内での取引では収まりきれなくなった現代では、契約は避けて通ることのできぬ手続きなのだ。もしあなたがプロジェクト・マネージャーなら、そしてあなたの顧客が「あなたと一心同体と思える相手」でなかったら、契約をどうすべきか考えるべきなのだ。客先と打合せをしたら、合意事項を議事録に書いて(議事録は契約を補完するものと位置づけられる)、あとで「あのとき貴方はこうおっしゃいました」とやんわり詰めよるべきなのだ。

「自他は別の存在であること」が契約の根底である。自分と相手は他人であって、一心同体でも以心伝心でもない。そこで、権利義務関係はできるかぎり明確化・文書化しましょう、という考えが生まれてくる。また、他人であるということは、責任範囲には限界がある、ということで、第二原則にも通じている。もちろん、別人であるからには、両者は対等だ。これが第一原則である。ところが、日本の企業社会には、この自他分別の論理が抜けている。抜けたまま、形の上だけ契約風な紙切れを交わし、また「契約だから」といって勝手に関係を切るのにも利用している。

生産システムの−その目的と機能は何か」で私は、「日本の製造業が抱えている問題点を、非常に圧縮した形で表現するならば、『大量・見込生産の体制を残したまま、多品種少量の受注生産に移行しようとしている』ということになる。」と書いた。私はもう一つ、あえて書きたいことがある。それは、「日本の企業は契約の論理の根底にある、自他分別の認識を抜かしたまま、形の上だけ欧米企業のやることを真似ようとしている。それが、今日の社会のさまざまな矛盾を生んでいる」ということだ。偽装請負も、成果主義年俸制も、自社工場の分社化も、事後精算付き発注も、みな同じ根っこから発している。

今の日本の現実では、無限責任をとれるような永久的共存共栄関係はもはや存在しないのだ。それならば、自分の身を守るために、あなたも今日から契約書に強くなるべきである。

→「革新的生産スケジューリング入門」にもどる

契約音痴は、まだ続いている (2017/02/15)

10年ほど前のことになるが、プロジェクトマネジメント学会に呼ばれて「トワイライト・サロン」で講演を行ったことがある。テーマは「海外プロジェクトの共同遂行におけるリスク要因」で、海外の企業と組んで共同でプロジェクトを進める際に、どんなリスクが考えうるかと言う話だった。共同で組む場合、ジョイント・ベンチャーや、コンソーシアムなどいくつかの契約上のパターンがある。また、スコープをどう分担するかも問題だ。これらを考えた上で、最適なフォーメーションをデザインする必要がある。わたしは同僚のAさんと一緒に、来場者の前でこうした問題についての考え方をお話しした。

講演の後質疑応答の時間になって、幾人かの方が質問に立った。ところで、PM学会の参加者は昔も今も、ほとんどがIT業界の人たちである。話題も、IT開発系プロジェクトがなぜかデフォルトになってしまう。その中の1つは、プロジェクトがスタートしたしばらく後になって、顧客がいろいろ要求上の変更を持ち出し、設計が混乱しスケジュールが遅延する場合、どうすべきかと言う質問だった。これ自体はどこの業界でも起こりうる典型的な問題だ。そして、特効薬も正解もない。

正解はないが、状況に応じて、いくつかの選択肢を考え、プラスマイナスを評価して決める、というのがマネジメント問題の定石である。変更要求はコストにも納期にも影響を与えうるため、まずは顧客にそれを伝えて理解させる必要がある。ただ、その状況と伝え方次第で、対応策は変わりうる。一般論でいえる話ではない。わたし達は状況をより理解するため、質問者の方にいくつか質問を逆に返すことになった。どんな種類の成果物を作るプロジェクトなのか。規模はどれくらいか。技術的難易度はどうか、そして顧客の特性は。

こうした質問を重ねて、少しずつ全体像が分かってきた。だが、相手はいささかじれてきたのかもしれない。わたしが最後に「どんな契約条件だったのですか?」とたずねたら、「いや契約の問題なんかじゃないんです!」とほとんど金切声で叫んだ。しかたなく、わたしはそれ以上の議論をやめてしまった。

だが、もちろん、契約の問題なのである。おそらく顧客が最初に決めた一定金額以上の追加を払ってくれないから、この問題が生じているのだ。かかった費用をそのまま支払ってくれるならば、つまり今の用語で言う「準委任契約」ならば、むしろ相手が迷って要求をかえるたびに、自分の収入が増えるのだから、この質問者はむしろエビス顔だったに違いない。しかし、この人にとって、プロジェクトは技術の問題、ないし顧客の誠実さ、つまり信義の問題に思えたらしい。

今日のIT業界では、こんなこと言う人は随分減ったに違いない。要件定義と実装以降をフェーズ分けして別契約にすることは普通になったし、スコープや作業量が見積もりにくい場合は、一括請負ではなく準委任で契約することも、わりと当たり前の知恵となってきた。

今さらとは思うが解説しておくと、「一括請負契約」とは成果物を納入して一定の対価を得る契約のことである。「委任契約」は元々は民法の用語で、依頼人が弁護士などに法律行為の代行を依頼する契約である。「準委任契約」はそれに準じた形の契約で、ただ、依頼するのが法律行為ではなく、通常のビジネス上の行為である場合に用いられる。委任契約も準委任契約も、普通は働いた時間に応じて対価が支払われる。

長らく、わたし達の社会では、システム開発は一括請負契約がデフォルトであったようだ。これは元々、ソフトが計算機ハードウェアのおまけ扱いから出発したことや、元請けが計算機メーカーの場合が多かったという事情から来たのだろう。一括請負の方が、金額が最初に確定できるため、発注者側での予算措置がしやすいという面もあったに違いない。

だが、ITの世界では要求が不明確で、あとから変更の発生するケースが少なくない。一括請負の場合、途中の追加変更に対して、請負側は追加請求の権利を有する。だがお金を払う発注者の方が「お客様は神様」で、取引で有利な立場に立つことが多い。その結果、受託側が追加費用をもらえず、コストだけ負担する赤字プロジェクトが生まれる。最初の質問者のケースは、まさにこれだったのだろう。

ところで、長らくこのような状態が続くと、受託側のIT産業自体が弱ってきてしまう。そこで『カウンターベイリング・パワー』が働き、最近はIT業界の側が契約上で、いろいろな自衛手段を講じるようになった。その結果がフェーズ分けであり、また準委任契約の導入であった。これ自体は、ある意味、健全なことだ。

ところが世の中の振り子は、ときどき逆に振れすぎることがあるらしい。1月に開催された「プロジェクト&プログラム・アナリシス研究部会」では、コンサルタントの本間峰一氏を招いて『システムトラブル相談センターの概要と開設の背景』という講演をしていただいた。本間氏は一般社団法人アドバンストビジネス協会が開設した「システムトラブル相談センター」のキーパーソンでもある。いろいろなITプロジェクトのトラブルを見てこられたが、最近は逆にITベンダーに有利な契約のために、発注者側が難儀をするケースも出てきているという。

ここで問題になるのが、準委任契約のあり方である。一般に、IT開発の最初の要件定義と、最後の総合テストないし運用テストは、準委任契約で行われることが多くなった。最後のテストでは、かかる工数が発注者側の運用環境に依存するし、また既存のレガシーシステムとのインタフェース・テストなども含まれることが多い。だからここを準委任でやること自体は一見、適正なことに思われる。ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。

たとえば、瑕疵担保責任の所在である。実装は一括請負だが、ユーザにとって納品物を受け入れるかどうかは、最後のテストの結果を見て判断することになる。ところがそこは準委任契約だから、成果物に責任はありません、というケースがあるらしい。何かバグが見つかって直す必要があったら、ユーザがお金を払わなければならない。これでは実装の品質が低ければ低いほど、ITベンダーは収入が増えるというおかしなことになる。それに、納期の問題だ。準委任だから、完成義務はない、納期は保証しません、という。

もう一つ問題の所在となるのは、System Engineering Service(略称SES)とよばれる契約形態である。これはIT会社の元請けから、下請け会社にSEを配員してもらうために発注するサービスだが、準委任契約の業務委託になっている。しかし、その実態は派遣契約にきわめて近い。IT業界は知っての通り多重下請け構造なので、SESの再委託もある。準委任の準委任という訳だ。どこの誰に責任があるのかさっぱり分からなくなる。

ためしに質問してみた。「準委任契約というのは、プロフェッショナルなサービスを提供するための仕組みです。である以上、プロとして仕事の品質を保証する責任があるはずでは?」 だが答えは「そこが曖昧なんです」だった。

わたしは驚いた。海外プロジェクトの契約の常識から、あまりにかけ離れているからだ。わたしは数年前まで、あるプロジェクトで海外企業と実費償還契約のもとで足かけ3年半ほど働いた経験がある。実費償還(Cost Reimbursable)契約というのは、日本の準委任にほぼ対応する概念で、人件費や経費など、つかった費用に応じて支払いを受けるようになっている。

ところが、海外企業との実費償還契約というのは厳しいのだ。まず、プロジェクトへの配員は、顧客が経歴書を審査し、きちんとした経験・能力が認めることが条件だ。勝手に協力会社の人間をアサインするなど、もってのほか。また一旦、配員されても、仕事ぶりの質が低いと、欠格として解任(Disqualify)されてしまう。働いた時間に応じて対価が払われるが、毎週タイムシートを顧客に提出し、チェックと承認を受ける必要がある。出張も外出も、顧客の事前の承認がいる。

それどころかプロマネは毎週のミーティングで、消費したMan-Hour(人時)と、作成し提出した設計成果物と、進捗率計算を報告しなければならない。顧客はこれを元に、生産性をモニタリングする。生産性が低いと叱責され、キャッチアップ・プランを出させられる。契約にはスコープと成果物が明記され、全体の契約金額にも上限(Cap)が設定されている。追加変更にかかわる作業は全て、書類で申請し承認である。自分たちのミスで余計な人時やコストを浪費したときはどうするか、納期に遅れたらどうするか、等々、ことこまかに契約書で決まっている。これが、世界の常識なのだ。

契約というのは、発注者と受託者の間のリスク分担を決めるための仕組みでもある。だから、一括請負契約と実費償還(準委任)契約とは、あれかこれかの二者択一ではない。両者のあいだには、インセンティブやペナルティ、変更と単価精算など、様々なバリエーションと知恵が存在するのだ。全体として何らかの納品物にかかわるケースならば、納期条項も成果物の品質責任も、支払額の上限もついているのが当たり前というのが、わたしなどの感覚だ。

これに比べると、本間氏の説明で聞いた日本のIT業界の準委任契約は、ほとんど派遣契約も同然のゆるさである。いや、派遣の場合、二重派遣は違法になるが、SESだと何重にも委託できてしまうから、もっとまずいとも言える。ひどいケースでは、ITベンダー側の営業が、こうした契約をたてに上手く立ち回って、弱り果てた顧客からどんどん金を搾り取っているという。

こうした状況が不健全なのはいうまでもない。契約を盾にとれば、技術力の不足をごまかすことができると思うのは、明らかに間違いだ。契約を盾にとって信義にもとるようなことをするのは、契約の精神に反している。それに技術力がなければ、最終的に顧客の満足は得られない。顧客満足こそ、ビジネスの安定の最大の基盤ではないか。

ただし、誤解しないでほしいのだが、わたしはIT業界全般を責めているのではない。むしろ逆だ。IT開発プロジェクトの発注者の側が、あまりに契約について音痴であることが、問題の根本だと考えている。一括請負契約なのに、後からどんどん追加変更を言い出す、最初の質問者の事例も、その一端だ。また逆に、準委任だからといって、ベンダーに妙に有利な条件をのんでしまうのも、やはり問題だ。私たちの社会では、長らく信義則で動いていたので、契約について弱い人が多い。だから準委任契約というと、成果物責任がなく、たんに「善良な管理者の注意義務」(「善管注意義務」)があるだけです、という説明に納得してしまうのだろう。

米アリゾナ州立大のDean Kashiwagi教授はプロジェクトとアウトソーシングの専門家で、"Best Value Procurement”という方法論を創案し、数千もの顧客に対し成果を上げてきた。昨年フランスで会ったとき、彼は「外注に関わる問題の8割以上は、じつは発注者側の能力不足に起因している」と語っていた。彼の実践範囲はITに限った話ではない。だが、なかでもITプロジェクトは、どこの国でも、難しいのだ。ITの発注者側にこそ、よりきちんとしたプロジェクト・マネジメントの理解が必要なのだと、わたしも声を上げていうことにしよう。

→「革新的生産スケジューリング入門」にもどる

「責任」には三つの意味がある (2011/06/06)

震災の後の4月に、知人たちと話していた時のこと。話題はおのずから福島原発の事故処理のことになった。原因は何か、どうクールダウン処理すべきか、また地域への被害をどうするか。そのうち、一人がこう発言した。「東京電力は法規則どおり原発を建てて運転し、地震後も政府の指示どおり対応したんだから、全責任を負えというのは無理がある。」

しかし当然ながら反論・異論も相次いで、議論はホットになっていった。政府(省庁)の過去の責任はどうか。あるいは政治(閣僚)の責任の軽重はどうあるべきか、いや、そもそも電力会社の過失はどこにあったのか、等々。ただ、話しているうちに、当の発言者の論点は、地域への賠償問題だということがはっきりしてきた。国も共同責任で補償すべきか、プラントのメーカーは責任がないのか、ということだ。すると、この分野に詳しい同僚が一言、「原子力賠償制度は無過失責任ですよ。」と発言した。

無過失責任とは何か。それは過失であることが証明されなくても、賠償の責任を負うということだ、と彼は説明した。より正確には無過失賠償責任とも呼ぶ。原子力賠償の制度は世界的に、「無過失責任、電力事業者への責任集中」という原則で成り立っている。日本は国際条約には加盟していないが、国内法制度は同じ原理でできている。だから、今回の事故に限っては、被害者側が電力会社の過失を立証しなくても(実際問題としてそんなことは機密の壁に守られてほぼ不可能だ)、とにかく一社で全部を賠償しなくてはならないのである。

結局、この説明で議論はあっさり終わりになってしまった。むろん、電力会社の資金はどう調達するのかとか、それだけの支払能力が無かった場合はどうするのか、という法的技術的問題は残る。だが法律上の責任範囲は明確なのだった。

わたしたちの議論が紛糾したのは、『責任』という言葉が何を指すかが、人により文脈によりバラバラだったこためである。ちょうどこのころ、当の電力会社のトップが、「原発事故を沈静化するまで職務を全うするのが私の責任」というような発言をしていて、責任論議はさらに錯綜したのだった。だが、そもそも責任とはいったい何なのか。責任をとるとは、いったいどのような行為のことを指すべきなのか? ちょうど『リスク』という用語にまつわる多義性と同様に、責任という概念も、法学・経営学・哲学・倫理学などが入りみだれて、分かりにくい。そこで、少しばかり整理してみよう。

責任という語には、じつは三通りの意味がある。それは、責任の理由や、責任の大小ではなく、その「果たし方」についての区別である。

そもそも責任とは、ふつう何か困った問題が発生した時に問われるものである。「責任ある地位」という風に、ポジティブな文脈で使われることも、もちろんある。しかし、“彼は責任を問われて昇進した”といった用法はあり得ない。ポジティブな事象においては、普通、責任の代わりに貢献とか功績という語を用いる。貢献と責任は対になる概念だ。

もう一つ。責任とは、ふつう意志ともセットで使われる。当事者に、それなりの裁量範囲や自由意志があった際にのみ、責任を問われるのである。ただ言われたことをやっただけの人には、たいして責任はないはずだ。

もっとも、じゃあ意図せざる過失には責任がないのか、というと、そうではない。過失には「注意義務を怠った」という一種の意志があったと考えられるからだ。そもそも人間は完全ではなく、間違いをする存在である。だから、二重チェックやフェイルセーフといった仕組みを仕事に組み込んでおく必要がある。ある一担当者の単純な過失が、重大な事故を引き起こしたとしたら、それはそのような不完全な仕組みを設計して放置したことに対して、責任が問われるのである。

そして責任とは、問題が生じた際に、その問題を解決するために払うべき代償について、行為の当事者に対し義務づける概念である。その代償の払い方が、三種類ある。まず、失敗した行為を正しくやり直すこと(影響を与えた状況を復旧する作業も含む)。次に、その問題を招いたことに関して、処分・批判を甘受し、場合によっては地位や体面を失うこと。最後に、損害賠償など法的な義務を果たすことである。

これらの三種類の責任概念は、英語ではそれぞれ別の言葉で表される。それが、Responsibility, Accountability, Liabilityである。どの語も、-ability, すなわち『能力』であることを示す語であるのは注目すべきだろう。

Responsibilityとは、仕事の遂行に対する責任概念で、つまり仕事が途中で問題を起こして、思ったようにうまくはいかなくても、最後まで我慢してやり遂げる(その余分な労力と精神的苦痛は自分が引き受ける)こと、ならびにその能力を意味している。

Accountabilityは、「説明責任」とも訳される。この語が日本で知られるようになったのはそれほど古いことではない。この10年程度であろうか。Accountableとは、対外的な義務を引き受けるという語感がある。誰が訳したかは知らないが、「説明責任」とは苦心の訳語であろう。とはいえ、“国会であれだけ弁明したのだから、某々大臣は説明責任を果たした”などといった使われ方をみると、なんだか「説明という仕事の義務」みたいに誤解されている面もあるようだ。そうではなく、Accountabilityは、地位や体面という代償を払うべきことを意味している。だからむしろ「面目責任」と訳してはどうだろうか?

Responsibilityが、どちらかというと業務担当者レベルでの「責任の果たし方」であるのに対して、Accountabilityは監督義務を怠った、あるいは間違った判断・命令を下してしまった、という事実への、管理職レベルでの「責任の果たし方」を指している。そして、Liabilityは法的な賠償等の「責任の果たし方」である。(ただしWikipedia英語版などを見ても分かるように、英語圏においても上記3単語は明確に区別せずに使われることがある。責任という概念は、それだけ奥が深くてややこしい)

ともあれ、以上をまとめると、次のように言えるだろう。

遂行責任 Responsibility :仕事を最後までやり遂げる(労力と苦痛を引き受ける)こと

面目責任 Accountability :問題の原因を作ったことを認め、立場・面目の低下を甘受すること

賠償責任 Liability :他者にかけた迷惑を金銭等で償うこと

こうして整理してみると、大きな事故を起こした企業が、まちがった操作をした作業者だけを処分し、トップは“問題を収集するのが自分の責任”と公言したら、どこがどう間違っているか明確だろう。作業者には復旧作業の遂行責任があり、経営者には事態への面目責任があるのだ。そして、かりにそのトップが会社を辞めたとしても、企業は賠償責任を逃れない。−−といった具合に、これら責任概念の区別を飲み込んだ上で議論できれば、もう少しかみ合った実りある議論も可能になるのではないだろうか。

→「革新的生産スケジューリング入門」にもどる


→「革新的生産スケジューリング入門」にもどる
サイトマップ
このページの冒頭に戻る

(c) 佐藤知一
e-mail: tomsato@rio.odn.ne.jp