<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="/assets/xslt/atom.xsl" type="text/xsl" media="screen" ?>
<feed version="0.3"
      xml:lang="utf-8"
      xmlns="http://www.w3.org/2005/Atom"
      xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>タイム・コンサルタントの日誌から:B5 プロジェクトの価値とリスク</title>
  <category scheme="http://brevis.exblog.jp/i30/" term="B5 プロジェクトの価値とリスク" label="B5 プロジェクトの価値とリスク"></category>
  <link rel="alternate" type="text/html" href="http://brevis.exblog.jp" />
  <modified>2025-12-31T11:05:38+09:00</modified>
  <author><name>Tomoichi_Sato</name></author>
  <tabline>タイム・マネジメントとSCM専門家のエッセー・批評・考察集</tabline>
  <generator url="http://www.exblog.jp/">Excite Blog</generator>
  <entry>
    <title>プロジェクトは不安定性な存在か</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/30230523/" />
    <id>http://brevis.exblog.jp/30230523/</id>
    <issued>2023-01-24T06:14:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2023-01-24T06:14:50+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[PM教育に関する、二つの問い<br />
<br />
<br />
プロジェクト・マネージャーの教育について、ときどき社外の方から相談を受けることがある。こうしてプロジェクト・マネジメントについてBlogで書いたり、あるいはPMをテーマとした研究部会を主催したりしているからだろう。「社内のプロマネをどう育成したら良いか」だとか、「ちゃんとPMの方法論を勉強したいのだが、PMBOK Guideを読むだけで良いのだろうか」といったご相談である。前者は主に、社内のPMO的な立場の方が多く、後者は個人単位の自己啓発を考えておられる方だ。<br />
<br />
<br />
前者のような問いに対するお応えの仕方は、様々なパターンがあり、ときには先方の社内研修などを引き受けることもある。後者のような問いだったら、たとえば「基礎知識として、PMBOK Guideくらいは一応お読みになってもいいと思いますが」とは申し上げている。<br />
<br />
<br />
だが、PMの勉強としてPMBOKで十分かというと、答えはNOだろう。PMBOKは教科書風の第6版 にせよ、かなり改変され簡略化された第7版にせよ、あらゆる種類のプロジェクトに適応可能なように、非常にジェネリックな記述をしてあるため、自分の仕事に展開応用するには、カスタマイズのための知識が必要だ。<br />
<br />
<br />
それに、率直に言うが、プロジェクト・マネジメントというスキルを身につけるには、本を読んで知識を得るだけでは足りない。自分で考える訓練が必要で、だからPMPの資格試験でも実務経験を必須としているのだ。<br />
<br />
<br />
学びに必要な時間と期間<br />
<br />
<br />
当たり前だが、マネジメント業務の中核には、決断を下す、人を動かす、問題を解決する、などの仕事がある。だから意思決定能力、コミュニケーション能力、体系的な思考能力などが必須になる。これらは良い先生や手本となる人について学ぶ方が良い。<br />
<br />
<br />
ということで、個人的な学びに対しては、このサイトでもときおり告知している、日本テクノセンターや浜松ソフト産業協議会主催の、有償セミナーなどをご案内することもある。1日ないし2日間のコースだ。でもわたし自身としては、より多面的に、かつインタラクティブにすすめるために、もう少し時間がほしい。大学のPM講義では1学期間・全15コマ（1コマ90分）を教えるが、本音ではそれくらいのペースが必要だと思う。<br />
<br />
<br />
ちなみに、わたしが静岡大学でプロジェクトマネジメントの講義をはじめて、今年で7年になる。教えているのは大学院・総合科学技術研究科工学専攻の「事業開発マネジメント」コースである。<br />
<br />
<br />
このコースは通称、MOT (Management of Technology＝技術経営)と呼ばれる学科で、言ってみれば『理系向けのビジネススクール』のような位置づけのカリキュラムになっている。同様の学科は全国の国公立・私立大学に20あまり存在し、その多くが2000年代に設置されたものだ。<br />
<br />
<br />
文化系のビジネススクールと同様に、MOT学科は主に社会人向けの大学院という位置づけであるため、土日や平日夜間の授業が中心になっている。わたしの「プロジェクト・マネジメント」科目は、1学期分・15コマだが、浜松キャンパスまで平日夜に毎週通うことは難しいため、月1回・土曜日に4コマを集中講義するスタイルで行っている（秋学期で10月〜1月までに4日間、最後の日だけは3コマ分）。<br />
<br />
<br />
受講生の多くは社会人なので、講義する側も楽しい。わたしはこれまで、法政大学の学部3年生と、東京大学の大学院生に対しても、1学期間のPMを、それぞれ10年近く教えた。それはそれで面白かったが、学生や院生は、人と一緒に働いた経験が少ないし、その苦労もあまり知らない。でも社会人を2年でも3年でも経験すると、プロジェクトがずっと身近な問題と感じられるようになる。なのでPM能力の必要性も、身にしみて分かる。<br />
<br />
<br />
学びの場において大切なのは、同じ意欲や問題意識をもった仲間の存在だ。何かを勉強すると言っても、社会人の場合は忙しいし、費用面の制約もある。だから仲間がいる方が、ずっと脱落しにくくなるのだ。そして、教える方もずっとやりがいが出る。<br />
<br />
<br />
プロジェクトの不安定性について<br />
<br />
<br />
先週末は、静岡大学での今年度の最後の講義日だった。そこで受講生の方と議論したトピックを一つ、紹介しよう。まさにちょうど、PMBOK Guideがカバーしていない論点であった。それは、プロジェクトの安定性に関することだ。<br />
<br />
<br />
プロジェクトは、意思決定の連続である。プロジェクトの始まりの日から完了の日まで、プロマネはたえず、様々な決断を迫られる。設計はAでいくかBにするか。ツールはXを選ぶかYにするか。発注先はN社がいいかM社がベターか。客先に追加を要求して揉めるべきか、我慢して見かけは平静な関係に続けるべきか・・<br />
<br />
<br />
一つひとつの決断において、分かれ道があり、結果がプラスになったりマイナスになったりする。プロジェクトの採算を指標にした場合、黒字が増えたり減ったりする。それは言ってみれば、沢山の分岐のあるネットワークを通過していくようなものだ。あるいは、もっと卑近な例にたとえると、パチンコの玉が、並んでいるピンの列の間を、左右に転がり落ちていくようなイメージかもしれない。<br />
<br />
<br />
しかし、だとすると、プロジェクトの結果というのは、ある平均値の回りに、適度な分散を描く正規分布的な形になりそうなものである。ななめの格子状に並んだピンにパチンコ玉を上から落とせば、結果はそうなる。左右の分岐確率に違いがあっても、二項分布になるはずだろう。<br />
<br />
<br />
ところが、実際にはそうならないのだ。わたしは勤務先で、プロジェクト・マネージャーが毎月出してくるMonthly PM Reportをレビューする仕事を何年もやったが、むしろ、プロジェクトは良い方とわるい方に、二極分化していくのである。<br />
<br />
<br />
良い方のプロジェクトは、レポートを見ると、先月はこんな風に客先と合意できた、翌月は発注先も適切なところを選定できた、翌々月は設計が予定より早く終わりそうだ、という具合に、良い出来事の報告が続いていく。<br />
<br />
<br />
ところが、逆のパターンもある。まずいプロジェクトでは、先月も客先から強引なクレームをもらった、翌月はサプライヤーの品質でトラブルが起きた、翌々月は現場への動員が予定より遅れた、という具合に、苦しいことばかりが続くのだ。こうなると、レビューする側でさえ、PMレポートを開けるたびに、ため息をつくことになる。<br />
<br />
<br />
現在のモダンPM論に足りないもの<br />
<br />
<br />
その仕事を続けるうちに、わたしは、プロジェクトとは山上のボールのようなものだと、感じるようになった。谷間に置いたボールは、左右どちらの方向から力を受けても、元の位置に戻るような性質がある。安定なのだ。しかし、山の上に置いたボールは、左右どちらかからちょっとでも力を受けると、逆の方向に転がり、いったん転がりはじめると、その方向に加速度をつけて進んでいく。<br />
 <br />
<center><img src="https://pds.exblog.jp/pds/1/202301/24/47/e0058447_06122774.png" alt="_e0058447_06122774.png" class="IMAGE_MID" height="335" width="500" /></center><br />
<br />
<br />
プロジェクトも同じだ。良いプロジェクトは良い結果の方向へ、まずいプロジェクトは困難な結果の方向へ、二極分化していく。不思議なことに、PMレポートには、今月は良い、翌月はまずい、翌々月は良い、という風に、良し悪しの間を行き来するものは無かった。どちらかに偏っていくのだ。<br />
<br />
<br />
これはつまり、プロジェクトという対象が、制御工学的なダイナミクスの点では、不安定であることを示す。では、どのようなメカニズムで、それは不安定になっていくのか。安定にするには、どうしたら良いのか。今のところ、このような観点からプロジェクト・マネジメントを論じた研究や指南書は、見た記憶がない。もちろんPMBOK Guideにだって、書いてはいない。<br />
<br />
<br />
わたしの勤務先では、IT Grand Plan 2030という長期的なIT技術開発のロードマップを発表している。その中では、「プロジェクトデジタルツインの構築とシミュレーション(将来予測) 」という項目も、目指すべき目標として謳っている。これはつまり、プロジェクトのシミュレーターを作って、その着地点（完了期日と完成コスト）を予測しようという構想だ。ちょうど台風の進路予報のように、プロジェクトの経路と着地点を予測する。ただしそれは台風の予報円のように、幅を持った予測になるだろう。<br />
<br />
<br />
これを実現するには、プロジェクトのダイナミクスを予測できるためのモデリングが必要である。そして、それはプロジェクトの本質的な不安定性も、再現できなければならないはずだ。<br />
<br />
<br />
だが今のところ、PM分野における着地点予測手法は、EVMS的なモデルがベースにあるから、基本的に確定的なものだ。せいぜい、ちょっと乱数シミュレーションを付加した程度のものである。こんなモデルを何万回動かしたしたところで、平均値の回りに正規分布する安定な結果しか出てこないのは、見えている。<br />
<br />
<br />
おわかりだろうか。現在のPM論には、何か大事な部分が欠けているのである。<br />
材料科学に携わる人たちは、「第一原理計算」という方法論を使う。これは固体の性質を、量子力学の原理（波動方程式）に基づいて計算する手法である。あいにく、PMの世界には、まだ第一原理も、そのダイナミクスを表す方程式も存在していない。<br />
<br />
<br />
プロジェクトは人間同士の営みであり、数理モデルが万能だとは思わないが、それでも参考にはなる。わたし達がプロジェクト・マネジメントに悩むとき、そして世の中の知識体系や教科書を勉強しようと志すとき、じつはまだ、これは第一原理さえ確立していない分野なのだ、と肝に銘ずるべきではないだろうか。<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
→「EVMSとアーンド・スケジュール法の弱点　～　プロジェクト予測のミクロとマクロ」 (2019-06-10)<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>コストセンターは本当に価値を生まないか？</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/30095850/" />
    <id>http://brevis.exblog.jp/30095850/</id>
    <issued>2022-09-11T12:36:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2022-09-11T12:36:14+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[コストセンターの貢献とは何か<br />
<br />
<br />
<br />
前回の記事「工場はコストセンターか？　そしてIT部門はコストセンターか？」   (2022-09-04)では、『コストセンター』という会計概念が、『プロフィットセンター』と対比されるうちに、いつのまにか組織と経営戦略を歪めていった経緯について説明した。その根底には、「コストセンターは価値を生まない」という信憑があった訳だ、だが、はたして、この考え方は正しいのか？　まず、そこから検討していこう。<br />
<br />
<br />
最初に、ごく簡単な例を考えてみる。あるところに、発明家（技術者）と実際家（セールスマン）がいた。二人は以前からの知り合いだが、発明家の方は最近、画期的なアイデアを思いついた。わずか20万円ほどの部品を使って、すばらしい価値を持つ新製品を作れるという。<br />
<br />
<br />
セールスマンの方は、もしそんな製品が本当にできるのたら、自分が買い手を捜してやろう、ともちかける。そんな新製品だったら、100万円の値段をつけても、売れるだろう。かくて、二人はスタートアップ・カンパニーを設立することにした。この二人の事業は、「製造」と「販売」の２アクティビティからなる、きわめてシンプルな製品開発プロジェクトである。<br />
<br />
<br />
ただし、発明家は、本当にその新製品を組み上げられるかどうか、初めての試みだけに、五分五分の見込みだという。他方、セールスマンは、もし製品ができさえすれば、９割方は買い手を見つける自信がある。製造のコストは20万円だ。販売のコストは、電話代や交通費が多少かかるが、ここでは無視してゼロと仮定しよう。<br />
<center><img src="https://pds.exblog.jp/pds/1/202209/11/47/e0058447_12175971.gif" alt="_e0058447_12175971.gif" class="IMAGE_MID" height="99" width="500" /></center><br />
<br />
<br />
お分かりの通り、新製品の製造を担当する技術者は、完全なコストセンターである。お金を使うだけだ。これに対し、販売を行うセールスマンは、収入を得るので、プロフィットセンターと考えられる。<br />
<br />
<br />
さて、ここで問題である。新製品が首尾良く出来上がり、それが100万円で顧客に売れたとしたとしよう。このとき、二人の貢献は、どちらがどれだけ大きいだろうか？<br />
<br />
<br />
(1)技術者の方がずっと貢献が大きい<br />
(2)セールスマンの方がずっと貢献が大きい<br />
(3)二人の貢献はほぼ同じである<br />
<br />
<br />
<br />
<br />
貢献価値を計算する<br />
<br />
<br />
<br />
わたしはこの問題を、大学のプロジェクト・マネジメントの講義の最後の方で出題し、皆の意見を問うことにしている。学生院生たちの答えは、いつもだいたいバラバラである。企業人に聞いても、見解は分かれる。<br />
<br />
<br />
ところで、この問題は、見解だの価値観だので答えるべきではない。ちゃんと、数字で答えが出るのだ。二人が100万円の収入を得た際（原価が20万円かかったから利益は80万円だ）、各人のフェアな取り分が計算できる。以下、どのように考えるかを説明しよう。<br />
<br />
<br />
彼らのプロジェクトは、２つのアクティビティからなる。第1のアクティビティは新製品製造で、最初にかかるコストは20万円。そして失敗のリスク確率は50%である。第2のアクティビティは販売で、コストはゼロ、失敗のリスク確率は10%だ。成功すると、100万円の収入がある。<br />
<br />
<br />
さて、仮に今、プロジェクトが真ん中の段階まで到達したとしよう。発明家は20万円使って部品を買い、無事に新製品の組立と試験に成功した。万歳！　さて、この時、彼らのビジネスの金銭的価値は、いくらだと考えることができるか？<br />
<br />
<br />
まだ、売上の100万円は手にしていない。ただ、販売のリスク確率は10%、いいかえると成功確率は90%である。ということは、彼らのビジネスの収入の期待値は、100万円 × 90% ＝ 90万円だ、と考えることができる。他方、20万円のコストは、すでに使ってしまった。だから、彼らのビジネスの価値は、プロジェクトの中間地点では、70万円である（知財の価値は？ と思う人も居るだろうが、現時点では発明家もまだ真の成功要因が分からないのだから、ゼロ査定としておく）。<br />
<br />
<br />
では、彼らがスタートアップを始めた当初、つまりプロジェクトの開始時点では、どうなのか。売上の期待値は、100万円ではない。90万円ですらない。新製品製造の成功確率は50%なのだから、100万円 × 90% × 50% ＝ 45万円、にすぎない。だが、プロジェクトの最初に、20万円コストは突っ込む必要がある。<br />
ということで、最初の計画段階では、彼らのビジネスの金銭価値は45 - 20 = 25万円なのだ。それが、途中段階では70万円に、そして最終段階では80万円に、増大していくのである。<br />
<br />
<br />
完了時点：100万 － 20万 ＝ 80万円<br />
途中時点：100万 × 90% － 20万円 ＝ 90万 － 20万 ＝ 70万円<br />
着手時点：100万 × 90% × 50% － 20万円 ＝ 45万 － 20万＝ 25万円<br />
<center><img src="https://pds.exblog.jp/pds/1/202209/11/47/e0058447_12204147.gif" alt="_e0058447_12204147.gif" class="IMAGE_MID" height="61" width="500" /></center><br />
<br />
<br />
そして（ここからが大切なのだが）、「新製品製造」アクティビティは、彼らのプロジェクト価値を25万円から70万円に押し上げた。「販売」アクティビティは、70万円を80万円にした。つまり、<br />
<br />
<br />
「販売」アクティビティの貢献価値 ＝ 80万 － 70万 ＝ 10万円<br />
「製造」アクティビティの貢献価値 ＝ 70万 － 25万 ＝ 45万円<br />
<br />
<br />
であるから、発明家の貢献の方が、セールスマンよりも、ずっと大きいという計算になる。二人のフェアな分け前は45:10、すなわち約65万円と15万円なのである。<br />
<br />
<br />
<br />
<br />
バリューチェーンにおける貢献価値とリスクの関係<br />
<br />
<br />
<br />
お分かりだろうか。「コストセンター」だと考えられた新製品製造の方が、「プロフィットセンター」である販売よりも、価値への貢献が高いのだ。<br />
<br />
<br />
そして、このような結果になった主な原因は、リスク確率にある。新製品製造の方が、ずっと失敗の可能性が高い。すなわち、「難易度が高い仕事」なのである。<br />
<br />
<br />
それは、このリスク確率の設定を変えてみれば分かる。たとえば、数値を正反対にしてみよう。製造自体は比較的簡単で、失敗のリスクは10%だとする。だが、そんな新製品を買ってくれる顧客を見つけるのは難しく、セールス失敗のリスク確率は五分五分、50%とする。<br />
<br />
<br />
同じような計算をしてみると、こんどは、以下のようになる。<br />
<br />
<br />
完了時点：100万 － 20万 ＝ 80万円<br />
途中時点：100万 × 50% － 20万円 ＝ 50万 － 20万 ＝ 30万円<br />
着手時点：100万 × 50% × 90% － 20万円 ＝ 45万 － 20万 ＝ 25万円<br />
<br />
<br />
完了時点と着手時点のプロジェクト価値は同じだが、途中時点での価値が大きく変わった。この結果、貢献はセールスの方がずっと大きくなる。<br />
<br />
<br />
「販売」アクティビティの貢献価値 ＝ 80万 － 30万 ＝ 50万円<br />
「製造」アクティビティの貢献価値 ＝ 30万 － 25万 ＝  5万円<br />
<br />
<br />
つまり、一般にリスク確率の大きいアクティビティ、難易度の高い仕事を仕上げて成功させた部門の貢献価値が、高くなるのである。それは、コストセンターであるかどうかには、関わらない。ビジネス収入の期待値は、バリューチェーンをさかのぼる程、小さくなるが、各段階での高低差こそ、各機能・各部門の価値貢献を示すのだ。<br />
<br />
<br />
（ついでに言うと、失敗のリスク確率を0%と設定すると、その貢献価値もゼロになる。つまり、誰がやっても必ず成功する作業は、特段の価値はなく、それこそどこかにアウトソースすれば良い、ということになる）<br />
<br />
<br />
<br />
<br />
リスクと「価値」は誰がどう決めるのか<br />
<br />
<br />
<br />
ここまでの議論の要点は、『リスク確率』にある。リスクの存在を認めたからこそ、アクティビティの貢献価値が出てくるのだ。<br />
<br />
<br />
しかし現在の会計基準には、リスクの出番がない。財務諸表を見ても、「リスク」だの「期待値」といった項目は、どこにも出てこない。なぜなら、リスクとは将来の可能性を示すのに対し、会計とは現実に起きたことの記録だからだ。<br />
<br />
<br />
たしかに有価証券報告書には、事業リスクについて何やら定性的な説明文章がつくが、それはおおむね外的環境に関することだ。定量評価は原則、しない。まして内部の業務プロセスについて、リスクがあるなどとは、書かない。そんな事を書けば、「ちゃんと経営してるのか」という突っ込みが来るからだ。<br />
<br />
<br />
だが製造の現場、設計開発の現場、ITの現場、物流の現場では、もちろん様々なリスクが存在している。それは数値化されていないかも知れないが、現場で働く者の実感である。<br />
<br />
<br />
もちろん、プロフィットセンターであるはずのセールスの現場にも、リスクが存在する。その最大のものは、「失注のリスク」である。顧客がつねに三者相見積をとるようだったら、互角な競合相手とたたかって受注できる確率は、1/3しかない。失敗のリスク確率は、67%である。<br />
<br />
<br />
だが、こうしたリスク確率は、ふつう定量化されないし、財務部に報告されもしない。そうなると、社内的には「何となく」ムードで主観的評価が行われやすくなる。<br />
<br />
<br />
もしあなたが、営業畑出身の役員なら、セールス現場の難しさは実感しているから、その難易度は高いと思うだろう。それに比べ、設計やITの難しさは、分からない。人は、経験したことがないものは、適切に評価できないからだ。<br />
<br />
<br />
あなたが設計畑出身の経営者なら、工場は図面に出したものを作るだけ、物流は言われたとおりに物を運ぶだけ、と思うかもしれない。そんなところにリスクがあってたまるか、そこは価値を生まないコストセンターだ、と。<br />
<br />
<br />
そう思う人間が多いのは、理由がある。なぜなら、製造の技術は成熟しているからだ。かつての高度成長期に、機械設備を導入し大量生産を実現するには、高度な技術が必要だった。だがもう、そういう時代は（一部の業界を除いて）終わっている。<br />
<br />
<br />
製造だけではない。ITや物流もそうである。いずれも、うまく動いて当たり前。問題がおきれば「責任者が無能」とされた。かくて、こういった部門は、一括して価値を生まないコストセンターとよばれ、さっさとアウトソースすべき重荷と考えられるようになったのである。<br />
<br />
<br />
・・では、そのような「コストセンター部門」は、本当はどのようにマネージすべきなのか。コスト以外に、適切なKPIがあるとすれば何なのか。コストセンター部門に求める能力べきとは何か。そういった事を論じるつもりだったが、例によって説明が長くなりすぎた。この問題について、次回考えよう。<br />
<br />
<br />
<br />
<br />
<br />
なお、上に述べたリスク確率と貢献価値の問題については、いろいろと浮かんでくる疑問もあろうと思う。完全にビジネスが中断するリスクしか述べなかったが、ある程度成熟した技術分野では、それはリワーク（再作業）のリスクに転化するのが普通であり、結果はコスト超過やスケジュール遅延としてはね返ってくる。もしこれらの理論的な側面にご興味があるならば、小生の学位論文である「リスク確率に基づくプロジェクト・マネジメントの研究」（AmazonでDVDとして購入可能）を参照いただきたい。<br />
<br />
<br />
また、実は当サイトでも以前、似た趣旨で論じたことがあった。だが、もう12年も前のことなので、あらためて書きおこした次第である<br />
<br />
<br />
＜関連エントリ＞<br />
「見えないパワーシフト　－　生産から販売へ」  (2010-11-14)<br />
<br />
<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>第5のリスク対応戦略を考える</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/29761622/" />
    <id>http://brevis.exblog.jp/29761622/</id>
    <issued>2021-11-27T23:36:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2021-11-27T23:36:42+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[皆さんはギリシャ神話に出てくるカサンドラの物語をご存じだろうか?　カサンドラはトロイアの王子パリスの妹で、予言の能力を持っている。しかし彼女には、アポロンの呪いがかかっていて、誰も彼女の予言を信じない、という状況にある。 <br />
<br />
<br />
有名なトロイア戦争は、王子パリスが、スパルタ国王の王妃で絶世の美女ヘレネーを、故国トロイアに連れ帰ったことから始まる。カサンドラはこの事件が、トロイアの滅亡を招くと予言するが、残念ながら誰もそれを信じない。 <br />
<br />
<br />
カサンドラは、トロイの木馬を市民たちが受け入れたことに対しても、破滅を招くと警告する。しかしこの時も誰も信じず、結局トロイアは敗北する。そしてカッサンドラ自身も、ヘレネーの双子の姉クリュタイムネストラの手にかかって命を落とすのだ。 <br />
<br />
<br />
どんなに正確に未来を予見できても、人々がそれを信じて対応行動を取らなければ、何の価値もない。危険を予知しても、避けられなければ、もはや運命と言うしかない。ギリシャ神話は運命論の色調が強いが、カサンドラの話は、これをよく示している。 <br />
<br />
<br />
さて、以前もちょっと書いたことだが、リスクマネジメントの研修をする際に、私が必ず最初にする質問がある。それは、 <br />
「あなたは世の中に、運・不運があると思いますか?」 <br />
という問いである。 <br />
<br />
<br />
多くの人は、「あると思う」と答える。そこで私は言葉を継ぐ。「もし世の中に運・不運があるのなら、リスクマネジメントなんて、意味があると思いますか？」 <br />
<br />
<br />
運・不運があると答える人の比率は、3·11以後、とくに今回のパンデミック禍以来、かなり増えてきている。当然だろう。自分の意思だけでは左右できない、大きな世の中の出来事が、自分の仕事や生活に降りかかって影響を及ぼしてくる。そういう経験を私たちはしてきた。 <br />
<br />
<br />
それなのに、運・不運という、いわば人生観や世間知のレイヤーの概念と、近代的なはずのマネジメントや経営論の問題意識が、結びついていないのだ。そこでわたしは、運・不運という言葉を、「外乱」という、制御理論的な言葉に置き換えてみる。そうすると理科系的教育を受けてきた人は、少しだけ両者につながりを見つけられるようになる。 <br />
<br />
<br />
逆に言うと現代の経営学は、パフォーマンス的な成果が、環境条件の変化にいかに依存するか、との視点が弱いのかもしれない。ビジネスの成果は、リーダーや経営者の意識的な努力や能力によって、達成可能だ。そういう信念が、アメリカ流経営学の背後にある。なぜなら、自らの能力と努力によって、学問的競争に打ち勝ってきたと信じる人たちが、ビジネススクールで経営学者をやっているからだ。 <br />
<br />
<br />
「運・不運などない。どんなことも、自分の意思と能力で達成することができる」と考える人達にも、わたしは同じ質問を投げる。「もしもあらゆる事が『やる気』で達成可能なら、リスクマネジメントなんて、学ぶ意味はないですよね？」 <br />
<br />
<br />
プロジェクトにおけるリスクマネジメントとは、わたし達の行動能力が、環境変化や外乱によって毀損されないよう、対応をとることである。対応には、事前的な対策と、事後的な対応があり、この2つは車の両輪である。外乱と書いたが、実際にはリスクの源は、外部から降りかかることもあるし、プロジェクトチームの内部に発生するものもある。 <br />
<br />
<br />
そしてもし、わたし達が予言する能力を持ち、全てを予見できれば、リスクは存在しないことになる。もちろん中には、自分たちでは対応しきれないような、リスク事象もあり得るだろう。だが全てを予見するとは、自分側の行動の予見も含むはずである。自分が対応しきれない環境変化は、受け入れるしかない。それはある意味で確定した事実であり、リスクではない。リスクとは不確実な、すなわち予見し難い事象の可能性だからだ。、 <br />
<br />
<br />
リスクとは自分の行動能力が毀損される事象の可能性である。これがプロジェクトマネジメントにおけるリスク理解の原則だ。自分が目的に向かって主体的に進むための行動能力を毀損される。そのために目標を達成できなくなる。あるいは活動自体を、断念せざるをえなくなる。こうした可能性を最小化するために、プロジェクトのリスクマネジメントはあるのだ。 <br />
<br />
<br />
プロジェクトとは、自分が何らかの成果物を生み出したり、何らかの状態に到達するために、主体的に行動するものだ。現状のままで良いなら、変化したくないなら、プロジェクトはいらない。プロジェクトとは行動である。正確に言うなら、複数の人が協力して行う活動だから、互いに強調された行動の集合と言っても良い。 <br />
<br />
<br />
これに対して、守りのリスクマネジメントと言うべきものもある。それは、何らかの資産とか資金とか、人びとの健康とか、ITシステムとか、知的財産とか、あるいは環境といったものを、外乱から守るのが、守りのリスクマネジメントである。変化しないためのマネジメント、変化を嫌うための防備である。 <br />
<br />
<br />
この2つの指針や性格が異なるのは、当然のことだ。 <br />
<br />
<br />
なお、リスクを考える際には、リアルタイム性の概念が重要になる。なぜならリスクマネジメントは、ある種の適応行動だからだ。 <br />
<br />
<br />
リアルタイム性とは何か。これについては、以前このサイトでも説明したことがある。元は2000年刊行の「MES入門」第3章に書いた内容だが、リアルタイム性とは、対象系の時定数よりも、有意に速い反応（行動能力）のことである。 <br />
<br />
<br />
例をあげよう。住宅街の中を時速30キロで運転していたら、道の10mほど前方を、ベビーカーを押した若いお母さんが横切ろうとした。もちろんこの程度だったら、十分にリアルタイムによけることができる。だからこれは、リスクではない。 <br />
<br />
<br />
ところが、住宅街の中の夜道を60キロで飛ばしていたら、物陰から小学生の男の子が、ぱっと走り出てきた。これは避け切れない可能性が高い。リスクである。 <br />
<br />
<br />
両者の違いは何かと言うと、自分の車が、リアルタイムによけきれるかどうかだ。リスク源を検知してから、緊急避難行動をとって、間に合うかどうか。時速60キロだと、10m走るのに、0.5秒もかからない。これが前方の歩行者と、自分の車を含めた系の時定数だ。 <br />
<br />
<br />
系の時定数は、対象だけでなく、自分の側の速度や俊敏性、すなわち自分の行動能力に依存している。世の中には客観的なリスク事象と言うものはない。ある事象がリスクかどうかは、自分の側の反応速度ないし対応能力に依存しているのだ。 <br />
<br />
<br />
したがって、 自分の対応能力を上げることが、リスクマネジメントにおいて重要な要素になっていると分かる。 <br />
<br />
<br />
プロジェクト・リスクマネジメントに関する現在の標準書や教科書が述べているリスク対応戦略について、わたしが不満を感じのは、この点だ。回避・転嫁・軽減・受容の4種類が、戦略としてあげられているが、ここには自分の側の対応能力を上げる、という視点が欠けている。しいて言えば軽減戦略の中に含まれる訳だが、あまり明示的ではない。だから、対応策を考える際のガイダンスとして使いにくい。 <br />
<br />
<br />
「あのプロジェクトの最大のリスクは、プロマネが某さんだってことだよ」——こういう言い方が成り立つのは、対応能力の側に不安があるからだ。プロマネはもう決まってしまっているので、そこに不確実性は無い。確率100%だ。 <br />
<br />
<br />
では対応能力を上げるとは、具体的にどんなことなのか。そのためには問題発生時の対応行動のプロセスを考えてみればいい。具体的には5段階になるだろう。 <br />
<center><img src="https://pds.exblog.jp/pds/1/202111/27/47/e0058447_23330587.png" alt="_e0058447_23330587.png" class="IMAGE_MID" height="474" width="500" /></center><br />
<br />
<br />
１　検知 <br />
　問題事象を検知する。場合によっては、事象それ自体ではなく、その前兆を検知する。なんだかポワンとするな、と感じて熱を測ってみる。うーむ、37度以上ある。これが検知である。検知のためには、何らかのモニタリング手法と、測定ポイントが確立していなければならない。 <br />
<br />
<br />
２　予測 <br />
　原因を特定し、事象の展開を予測する（場合によっては自分自身の行動予測も含まれる）。熱がちょっとあるから、風邪かもしれない。喉がひりひりして、鼻もつらい。お腹の調子も少しおかしい。まさかとは思うが、コロナ感染だろうか。いつもの風邪なら、布団をかぶって一晩寝れば、だいたい熱は収まるのだが。 <br />
<br />
<br />
３　決断 <br />
　取るべき選択肢を洗い出し、評価して、どれをとるか決定する（決断はプロマネの重要な仕事だが、組織内では権限範囲を決めてメンバーにも委譲しているはずである）。今日ははずせないミーティングがあるな。しかし熱があるからには、やはり職場には出られない。リモートで会議に参加しようか。いや、ここは医者に行って診てもらうことにして、発熱外来のある医療機関を探そう。 <br />
<br />
<br />
４　伝達 <br />
　選んだ決断を、チームメンバーに伝達する。プロジェクトは複数の人間が協力して進める活動だから、人にも動いてもらわなくてはならない。自分一人の病気とは言え、休むことは職場に伝える必要があるし、しばらく自分の仕事をカバーしてもらわなければならない。家族にも熱があるから、接触を控えるよう、伝えなければ。 <br />
<br />
<br />
５　行動 <br />
　伝達された決断に従い、組織内の各担当者が仕事上で実際の行動に移す。医者にいって検査と診察を受け、もらった薬をとりあえず飲んで半日寝たら、幸い夜には平熱に戻った。まだ鼻と喉がつらいが、明日は落ち着きそうだ。疲れが溜まっていたのかもしれない。休めと体が言ったのかな・・ <br />
<br />
<br />
検知→予測→決断→伝達→行動、をスムーズに動かすためには、良い組織づくりが必要である。検知した情報を上に伝える事と、決断・指示を各担当者に伝える事では、双方向のコミニケーション能力が大切になる。 <br />
<br />
<br />
一番クリティカルなのは、3番目の迅速な決断である。そのためには、各人の権限範囲がはっきりしている必要があるし、プロジェクトチーム自体が会社から任された責任範囲も明確になっていなければならない。もちろんプロマネその人の決断能力も問われる。だがしばしば、プロマネの権限範囲を狭めておいて、かつ、プロマネが相談できるスポンサーも不明確な組織があるのである。 <br />
<br />
<br />
とは言え、決断・伝達・行動は、リスク対応策と言うよりは、本来あるべき組織作りと言えないこともない。そこで対策として重要になるのは、検知能力と予測能力を向上することになる。 <br />
<br />
<br />
検知には、モニタリング手法と測定ポイントの確立がいる。そして予測のためには、過去のデータや経験値・教訓（L&amp;L）へのアクセス、ならびに簡単なシュミレーターなどが必要になる。これらを合わせて、わたしは「監視」戦略と仮に名付けている。 <br />
<br />
<br />
たとえばプロジェクトで外部から購入する資機材について、予算設定時よりも高い見積がでてきたら、報告をすぐ発信するようにルール化する。あるいは、その原料相場自体が高騰してきている事を、ニュースアラートで知るよう設定する。こうしたことが監視戦略の対応策である。 <br />
<br />
<br />
市場価格それ自体は外部環境で、自分たちでコントロールすることはできない。それでも早めに検知できれば、打つ手を考えられる。 <br />
<br />
<br />
あるいは、外注した業者の品質問題や進捗遅れなども、なかなかコントロールしがたい。しかし定期的にミーティングをもってウォッチしておけば、早めに問題を検知できる。また過去のその業者の納期パターンも参考にできれば、もっと良い。こうしたモニタリングの仕組みも、リスク対応策の一つだ。 <br />
<br />
<br />
実際のリスクアセスメント・セッションをやってみると、こうした監視型の対策が、けっこう多く出てくる。従来の分類で言うと「軽減」になるが、軽減戦略はリスク事象の発生確率を抑えたり、影響度を下げるために冗長化・頑健化するイメージが強い。だが予見（＝検知＋予測）能力をあげる事も、俊敏な対応を可能にする点で、有用なリスク対応戦略なのである。 <br />
<br />
<br />
ギリシャ神話のカサンドラは完璧な予言能力を持ちながら、誰もそれを信じなかった（「伝達」が機能しなかった）ために、トロイアのリスク対応能力はまったく機能しなかった。カサンドラがアポロン神に呪いをかけられたのは、もともと彼女が、言い寄ってきたアポロンの心変わりを予見して拒絶したからだ。 <br />
<br />
<br />
予知するだけは危険は防げない。トロイアの対応能力を超えた悲運を見通したとき、彼女は覚悟を決めたはずだ。そこでわたしは、かつて人生の師と仰ぐＲ先生から聞いた言葉を思い出すのである。リスクマネジメントについて得々と語るわたしに、R先生はこう言われたのだ。 <br />
<br />
<br />
「君は覚悟を決めて、それを選ぶのか。覚悟してやらないものは、戦略ではない。たとえ裏目と出ても、その結果を自分で引き受ける。そういう覚悟ができる人のことを、真の大人というのだよ。」——一体わたしは、本当の意味で自分を大人と呼べるだろうか。予見と成熟について考えるわたしの耳の底に、いつもこの声がよみがえるのである。 <br />
<br />
<br />
<br />
<br />
＜関連エントリ＞ <br />
「R先生との対話　－　戦略を語る前に必要な『勇気』」  (2012-05-06) <br />
<br />
<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>Risk Breakdown Structureとは何か</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/29737407/" />
    <id>http://brevis.exblog.jp/29737407/</id>
    <issued>2021-11-04T23:32:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2021-11-04T23:32:24+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[米国のアポロ計画は、1961年5月に、ケネディ大統領が演説の中で、「60年代中に人類を月に送る」と宣言して始まった。じつは当時、宇宙技術の点で、米国は仮想敵国ソ連に大幅に遅れをとっていた。ケネディ演説の直前の4月、ソ連のガガーリン飛行士がボストーク1号に乗り、人類初の有人宇宙飛行を実現した。彼のセリフ「地球は青かった」は、名言として今も広く知れ渡っている。 <br />
<br />
<br />
ケネディ大統領が60年代中に（つまり、それから8年7ヶ月以内に）有人月面飛行をする、と宣言したとき、米国の多くの専門家は、「そんなこと不可能」と感じていたらしい。しかし、一見不可能に見える未来像を示して、大勢の人を引っ張るタイプの楽観的リーダーシップは、当時の米国社会ではうまく作用した。1969年7月、アポロ11号は3人の宇宙飛行士を乗せて、月に向かって旅立つ。 <br />
<br />
<br />
アポロ11号というプロジェクトに、費用を全部でいったいいくら使ったのか、正確にはよく分からない。とりあえず、アポロ宇宙船とサターンロケットのみの費用は、約830億ドル（現在価値）という数字は調べることができた。これだけで軽く10兆円である。まあ、冷戦下における国家の威信をかけたプロジェクトである。10兆円なら安いのかもしれない。 <br />
<br />
<br />
ところでプロジェクト・マネジメントの感覚でいうと、費用とスケジュールは、プロジェクトのパフォーマンスを測る二大指標である。受注型プロジェクトだったら、約束の納期を守り、受注金額を下回るコストで仕上げられれば、利益が出る。自発型プロジェクトだって、結果を早くだし、出費も抑えれば成功と言える。 <br />
<br />
<br />
では、費用とスケジュールが両立しないときは、どうすべきか？ <br />
<br />
<br />
端的な例は、発注先が2社あって、A社に発注すれば費用は安いが納期がかかり、B社ならば高いけれども納期が短い、という場合だ。プロジェクト・マネージャーは、どちらに発注すべきか、決断しなければならない。品質その他の条件は、同じだとする。あなたなら、どちらを選ぶか。 <br />
<br />
<br />
答えは、いろいろあり得るだろう。だが、もしこれがアポロ11号のプロジェクトだったら、答えは明白だ。費用がかかっても、納期が短い方を選ぶはずである。なぜなら、アポロ計画全体の目標が、「60年代中」という時間設定だからだ。打ち上げ予定は1969年7月。ケネディ大統領の公約までに、残されたフロート日数は5ヶ月を切る。だとしたら、納期が遅れるリスクの方が、費用が超過するリスクよりも重大だ。これが判断の基準である。 <br />
<br />
<br />
プロジェクトのリスクとは、プロジェクトが目標を達成できなくなる事象の可能性である。プロジェクト目標は、もしかしたら複数あるかもしれない。成果物の性能や、納期、あるいはコストなどだ。もちろん、ある種のプロジェクトでは、納期やコストが目標から外れる場合もある。もし仮に、金に糸目をつけないプロジェクトなら、コスト超過リスクなどというものは存在しなくなる。 <br />
<br />
<br />
アポロ計画に予算枠があったかどうかは知らない（たぶん国家予算だからあったのだろう）。だが、コストよりも時間的目標の方がはるかに重要だった。プロジェクトの目標設定は、何をリスクと考えるかに対して、基本的な指針、枠組みを与えるのである。言いかえるならば、「客観的なリスク」などというものは、ない。リスクとは、人びとが設定したプロジェクトの目標を元にして、洗い出すべきものなのだ。 <br />
<br />
<br />
Risk Breakdown Structure(RBS)とは、リスク洗い出しのために、リスク・アセスメント・セッションで利用されるツールの一つである。 <br />
<br />
<br />
RBSは、リスク源を階層的に表示した図である。WBS(Work Breakdown Structure)やOBS(Organization Breakdown Structure)などと同じく、一番上のレベル(Level-0)には、プロジェクト・リスクの全体をおく。そしてその下に、第一階層、第二階層、と分解された要素が並んでいく。例を示そう。 <br />
<center><img src="https://pds.exblog.jp/pds/1/202111/04/47/e0058447_23274429.png" alt="_e0058447_23274429.png" class="IMAGE_MID" height="256" width="500" /></center><br />
<br />
<br />
この図では、第一階層に、「外部リスク」「技術リスク」「組織リスク」「プロジェクト・マネジメント・リスク」が並んでいる。そしてその下に、たとえば外部リスクなら「市場環境変化」などの要素がぶら下がる。リスク・アセスメントの参加者は、この図を見ながら、たとえば市場環境変化に起因して生じる、リスク事象を考えていくのである。 <br />
<br />
<br />
もちろん、この図がいつも正とは限らない。客観的リスクというものが存在せず、リスクはプロジェクト実行主体の目標設定に従うのだから、RBSは本当は、プロジェクトごとに作成するべきである。とはいえ、まあプロジェクト種類毎に、組織内にテンプレートくらいは持っているのが望ましい。 <br />
<br />
<br />
ちなみにRBSは、PMBOK Guideでは、どう説明されているだろうか。 <br />
<br />
<br />
ためしに、手元にある最新版のPMBOK Guide 第7版（2021年7月発行）を見ると、こう書かれている： <br />
「潜在的なリスク源（Potential sources of risks）を階層的に表示した図」（拙訳、英語版P.187）<br />
<br />
<br />
この説明は、Section 4 - Models, Methods and Artifactsの下、4.6.4「階層図」のところに、WBSやOBSなどと一緒に並んでいる。ただし、上記のワンセンテンスの説明があるだけで、図はついていない。ずいぶんそっけない扱いである。これだけ読んでも、プロマネたる読者は、どうしたら良いか分からないだろう。 <br />
<br />
<br />
（なお、すでにご承知の方も多いと思うが、プロジェクト・マネジメント分野の事実上の世界標準であったPMBOK Guideは、今回の第7版で抜本的な変革を行っている。本のメイン部分は”The Standard for Project Management”となり、PMBOK Guideは後半に追いやられ、10個のマネジメント知識エリアも消失している。この変化についてはいずれ項を改めて論じたい） <br />
<br />
<br />
ところで、わたしはPMBOK Guide 第2版（2000年発行）をまだ持っていて、ときどき参照のためひっくり返す。というのも、第2版はコンパクトながら、ある意味モダンPM論のエッセンスを凝縮していて、分かりやすいからだ。・・ということを、実はわたしの勤務先で昔、学んだのである。 <br />
<br />
<br />
で、そのPMBOK Guide 第2版には、RBSそれ自体は登場しない。かわりに、リスク分類（Risk categories）という用語がある。説明は、こうである： <br />
<br />
<br />
「プロジェクトに良きにつけ悪しきにつけ影響を与えるリスクは、洗い出して分類整理することが可能である。リスク分類は明確に定義し、当該産業や応用分野において共通するリスク源を反映していなければならない。」（英語版P. 131） <br />
<br />
<br />
具体的には、こんな説明が続く。 <br />
<br />
<br />
・技術上、品質上、性能上のリスク — 未検証の技術や複雑な技術、非現実的な性能のゴール、利用している技術や業界標準に対するプロジェクト中の変更など <br />
<br />
<br />
・プロジェクト・マネジメント・リスク — 時間やリソースの割当が不十分なこと、プロジェクト・プランの品質が不適切なこと、プロジェクト・マネジメント技法の乏しさ <br />
<br />
<br />
・組織リスク — お互いに矛盾するコスト・時間・スコープの目標、プロジェクト間の優先順位付けの欠如、予算が不十分だったり中断すること、組織内で他のプロジェクトとリソースの取り合いが生じること <br />
<br />
<br />
・外部リスク — 法律や規制などの変化、労働問題、オーナー側の優先順位付けの変化、カントリー・リスク、気候など。とくに不可抗力リスクとは、地震、洪水、内乱などで、リスク・マネジメントよりも危機管理（Disaster recovery）を必要とする。 <br />
（以上、拙訳） <br />
<br />
<br />
お分かりの通り、ここにあげられている4種類の分類は、ほぼそのまま、上の図の第一階層に対応している。というか、図はPMBOK Guide 第3版以降に登場するRBSを参考に、少し改変して作成したからだ。第3版のRBSは、第2版の上述の説明を継承し、敷衍して作ったものになっている。 <br />
<br />
<br />
わたしが変えた部分は、第2階層以下である。というのも、上の説明は（そして第3版以降のRBSも）、何だか奇妙だからだ。 <br />
<br />
<br />
プロジェクトのリスクが、外部リスクと内部リスクに分かれる、というのは良い。内部リスクが、さらに技術・組織・PMに分かれるのも、まあ良いとしよう。しかし、技術リスクの下にある性能リスクというのは、リスクの発生源だろうか？　むしろ影響の及ぶ結果＝目標値の方ではないか（ちょうど「納期遅延リスク」のように）。非現実的な性能のゴールは、技術に起因するリスクだろうか？　ゴールを設定したのは自分たちなのだから、それはむしろ計画設定の不適切さ（つまりPM）に起因するはずではないか。 <br />
<br />
<br />
繰り返すが、RBSは単なるリスク分類ではない。リスク源の階層分類なのだ。だから技術に起因する要素としては、むしろ「複雑さ」（これが増えると不整合が生じやすくなる）、「サイズ」（大きすぎたり小さすぎたりすると困難性が増す）、「新規性」（技術の未成熟さを表す）などを置いたのである。 <br />
<br />
<br />
他の項目も同様である。外部リスクの「外部」とは、プロマネの計画やコントロールが及ばない範囲を指すはずだ。だとしたら、その中に、自分で選ぶはずのサプライヤーや下請け業者によるリスクが来るのは奇妙だ。もちろん、外部リスクの中に「不可抗力リスク」を置くのもおかしい。これは契約条件に依存するからだ（だから第3版からはなくなっている）・・ <br />
<br />
<br />
お分かりだろうか。RBSはある意味、単純なツールだ。だが、その単純なツールでさえ、論理的に詰めていくと、いろいろと奇妙な点が出てくる。それはなぜかというと、 <br />
<br />
<br />
　・リスクの発生場所（発生源）と、リスクが発現する所（結果）を区別する <br />
　・ある事象がリスクかどうかは、プロジェクトの目標設定に依存する <br />
<br />
<br />
という原則が十分理解されないまま、自分のなれたデフォルトのビジネス感覚を当てはめがちになるからだ。 <br />
<br />
<br />
そういう意味で、リスク・アセスメントできちんとリスクを洗い出すには、それなりのトレーニングが必要だということになる。だからこそ、前々回の記事でも紹介したように、わたし達の研究部会でも研修プログラムに組み入れることにしたのである。 <br />
<br />
<br />
現代のプロジェクト・マネジメント技法は、60年代の米国アポロ計画を通じて、非常に発展した。PMの用語のほとんどがカタカナ英語なのは、それに依るところが大きい。そして、アポロ11号についてリスクを考えるなら、未経験の環境における機材の故障・トラブル、人間の誤操作、機材の誤設計・製造不良、離着陸時の気象不良、そして未知の事象との遭遇などなど、いくらでもあげられるだろう。 <br />
<br />
<br />
だが、プロジェクトはつねに、新しい挑戦の要素を含む。だからプロジェクトを進める事とリスクをテイクする事は、表裏一体の関係にある。そこが、安全や知財やセキュリティのリスク・マネジメントと異なる点なのだ。プロジェクト遂行における最大のリスクは、機材の故障でも未知との遭遇でもない。リスクという概念を良く理解せずに、なんとなくプロジェクト計画を進めることなのである。 <br />
<br />
<br />
<br />
<br />
＜関連エントリ＞ <br />
「危険予知：プロジェクト・リーダーに必須の能力として（11月16/23日・PMセミナーのお知らせ）」  (2021-10-10) <br />
「危機なんて、ほんとに管理できるのか？」  (2020-03-08) <br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>プロジェクトの《心配》を捕捉する</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/29717641/" />
    <id>http://brevis.exblog.jp/29717641/</id>
    <issued>2021-10-17T21:39:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2021-10-17T21:39:15+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[リーダーはつらい。 <br />
<br />
<br />
そう思っている人がどれほど多いかは、正確には知らない。いやいや、リーダーであることは、素晴らしい、ぜひ、人の上に立つべきだ。リーダーシップを発揮して、人を動かそう——わたし達の社会は、そんなメッセージに満ちている。人間は生まれつき競争心を持っているし、この世は競争原理でドライブされている。だからみんな、リーダーを目指すべきだ、リーダーの地位は喜ばしい、という事になっている。 <br />
<br />
<br />
でも、はたして本当にそうか。 <br />
<br />
<br />
リーダーは心配の多い仕事である。一介のエンジニアから、リーダーのポジションに上がると、自分自身の技術のこと以外に、面倒見なくてはいけないことが増える。部下や後輩や外注先の仕事ぶり、彼らの能力や勤務状況、すぐに進歩し変転していく技術の通用力、そして顧客の要求や機嫌など・・。これらを見極めた上で、WBSを決めスケジュールの線表を引き、そして費用や納期の交渉までしなくてはならない。 <br />
<br />
<br />
顧客も納期も自分の部下の顔ぶれも、自分で選んだものではない。え？　見積提案書をつくったのは自分だろうって？　だが、どうみても無理筋な納期要求をしてきている顧客案件を、厳しい競争環境下で取ってきたのは営業だ。だが、彼らは注文書を受け取ったら、さっさといなくなる。外注先も、上司が過去の経緯で決めてしまった。自分がのぞみ通りに絵を描いたのは、テクニカルな部分を除くと、極めて小さい。 <br />
<br />
<br />
・・というような事例は、まあ珍しくない。だから、中間管理職に昇格したとたんメンタルをやられたとか、プロジェクト・リーダーをやらされそうになったから会社をかわった、といった話も耳にすることになる。 <br />
<br />
<br />
なお、わたしはここまで（前回の記事を含めて）あえて、「プロジェクト・リーダー」という言葉を使ってきた。わが国の、とくにIT業界では、この用語が一般的だからだ。本サイトの以前からの読者は、わたしが「プロジェクト・マネージャー」の呼称を一貫して使ってきたことを、ご存じかも知れない。PMBOK Guide(R)でも、そうなっている。マネージャーとリーダーは、本当は違う。マネジメントとリーダーシップも、相当に違う。 <br />
<br />
<br />
だが、英語では異なった意味になるマネージャー、リーダー、コントローラー、アドミニストレータの４つの語は、日本語ではみんな『管理者』と訳される。日本の方がそうした概念については大ざっぱであり、英語のような緻密な区分をしない。 <br />
<br />
<br />
ただ、面白いことに、プロジェクト・リーダーの上に「プロジェクト管理者」がいる組織図は、よく見かける（「プロジェクト責任者」の場合もある）。どう違うのか。どうやら職位が違うらしい。前者のリーダーは現場で汗をかく人だが、後者は部長クラスで、キックオフと中間レビューミーティングくらいしか、顔を出さない。どういう「責任」をとってくれるかも、今ひとつ定かではない。 <br />
<br />
<br />
「責任」という言葉は、じつは問題やトラブルと密接な関係がある。「あのプロジェクトは素晴らしい成功だったが、その責任は彼にある」、という言い方は誰もしない（もちろん英語でもない）。責任がある、責任を取る、といった場合、なんらかの望ましくないトラブルが生じたケースに限られる。だから、責任者というのは、プロジェクトの《心配事》を、前もってケアすべき立場にある。つまり、前回の記事に書いた「危険予知」である。 <br />
<br />
<br />
さて、ここでもう一つ、英語と日本語の言葉の違い、あるいは概念の違いについて、ふれなければならない。それがリスクriskという語である。 <br />
<br />
<br />
リスクとは、危険だろうか？ <br />
<br />
<br />
ふつう、危険の反対概念＝安全、だと考えられている。安全とは、危険がないこと、すなわちリスクがない状態だ、と。 <br />
<br />
<br />
ところが、国際標準の世界では、そうは考えない。安全の定義は、「受入不可能なリスクがないこと」（ISO/IEC Guide51）とされているのだ。つまり、安全な状態とは、受入可能なリスクが、いろいろと残っている状態のことを指すである。何だそれ？ <br />
<br />
<br />
じつは、日本語の「危険」に相当する英語は、ハザードHazard、ペリルPerril、リスクRisk、デンジャーDangerと、４つある。彼らは、これを使い分けている。 <br />
<br />
<br />
たとえば、救命具なしにボートを漕ぎ出すのはリスキーRiskyだが、嵐の海にボートを漕ぎ出したらデンジャラスDangerousだ、という。リスクはまだ可能性の段階だが、デンジャーはほぼ確実に危険である。 <br />
<br />
<br />
ちなみに、ハザードは危険源という訳語を、JISでは採用している。たとえば高圧電流の通電が、ハザード（危険源）だ。普通、それは防護や絶縁をする。しかし絶縁不良で漏電、となるとペリルに「昇格」する。そこに人が近づいたり可燃物があったりする可能性があると、さらにリスクになる。そして・・ <br />
<br />
<br />
繰り返すが、リスクは可能性の状態にある。そしてリスクには、大小がある。これを洗い出して、対策を考えるのが、リスク・アセスメントである。対策とは、必ずしもリスクを除去することではない。リスクが「受入可能」な状態にすることも、リスク対策である。 <br />
<br />
<br />
別な言い方をすると、絶対安全はない、という見方を、ISOなどを決めた人びと（ほぼ欧米人）は取っているのだ。安全か危険か、白か黒か、という風に世の中を見ない。現実世界には、大小様々なリスクがあって、自分にとって許容可能な範囲はどこかを考え、その領域を広げる努力をしよう、とするのである。これを、Risk-based Approachという。日本語の訳は、まだない。<br />
<br />
<br />
リスク・アセスメントで使う主要な道具が、Risk Breakdown Structure(RBS)であり、その結果をリスク登録簿に書き込む。 <br />
<br />
<br />
Risk Breakdown Structureとは、プロジェクトのリスクが生じるエリア（源泉）を階層的にブレークダウンした図で、WBSの階層表現図に、ちょっと似ている。最上位にプロジェクト全体のリスクがあり、それを、たとえば外部リスク・技術リスク・組織リスク・マネジメントリスクなどに分解し、さらに外部リスクは市場環境・天候気象・公衆衛生などに分解してある。そして、その単位で考え得るリスク項目を洗い出すのである。まあ、リスクの源泉つまり危険源（ハザード）の分解なので、本当はHBSとよぶべきだろう。 <br />
<br />
<br />
洗い出したリスクは、リスク登録簿（Risk Registry）に記録する。リスク登録簿は、シンプルな表である。整理番号、リスク項目（説明）があり、さらに、発生確率、影響度、リスク点数（スコア）、優先度の欄が並ぶ。そして、その右側にはリスク対応戦略（分類）、そして具体的な対応策と、そのリスクをケアする責任者の欄がある。実務ではもう少し欄を追加することもあるが、これが最大公約数だろう。 <br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202110/17/47/e0058447_21300220.png" alt="_e0058447_21300220.png" class="IMAGE_MID" height="95" width="500" /></center><br />
リスク・アセスメントは、プロジェクトのリーダーが一人で作ることも可能だが、できればキーパーソンを入れて複数人で行うのが望ましい。一人だとどうしても、見方が限られる。ことなる視点から、「あれもありうる」「これもあるんじゃない」とやりとりする方が、ベターだ。そして、リスク登録簿を完成させる。 <br />
<br />
<br />
このリスク洗い出しと対策議論のプロセスによって、参加者の脳内でさまざまなシミュレーションが行われ、その一部は言語化されていく。じつは、ここが非常に大切なのだ。というのも、「幽霊見たり枯れ尾花」という諺があるとおり、人を一番消耗させるのは、見えない物事への心配・不安なのである。 <br />
<br />
<br />
リスク登録簿とは、そうした心配事を捕捉した、いわばプロジェクトの心配事リストである。それが言語化され、具体的に見えてくれば、個々のリスク事象の発生確率や影響度自体は変わらなくても、自分の側の検知能力や対応能力が上がるのだ。 <br />
<br />
<br />
だから、できあがったリスク登録簿は、プロジェクト・メンバー、および上位管理職（つまり「プロジェクト管理者」「責任者」）とに共有することが大事である。もちろん本当は、プロジェクト責任者こそ、このリスク・アセスメントのセッションに、一緒に参加すべきなのだ。 <br />
<br />
<br />
なお、あえてちょっとだけ、余計なことを書こう。それは、「リーダー」と「責任者」の関係についてだ。わたしは、多くのプロジェクト・リーダーの悩みは、実はその上司である管理者なり責任者レベルが果たすべきマネジメントの不足を、下のリーダー層で補おうとして生じているのではないか、と思っている。いいかえると、戦略レベルの不足を、戦術レベルで何とか挽回しようとしている。あるいは、将校の不在を、下士官が補おうと、無理しているから、悩みが深いのではないか。 <br />
<br />
<br />
わたしは「プロジェクト＆プログラム・アナリシス研究部会」をかれこれ、10年も続けてきたし、その中で「プロジェクト懇話会」も開いてきた。プロジェクトの運営に悩む人達の話も、それなりに聞いてきたが、多くの事例では、出発時点からムリがあって、さらに上司が支援を十分していない、と感じられた。それは契約条件だったり、顧客の性質だったり様々だ。ともあれ、会社組織がプロジェクトに必要な手当てをしないまま、現場リーダーに遂行を丸投げしている印象を、しばしば持つのである。 <br />
<br />
<br />
上司たる「責任者」のマネジメントがなぜ、ちゃんと機能しないのか。上司が多忙すぎるのか、他にトラブルを抱えて火消しに回っているのか、それともマネジメントという職務をちゃんと教育していないのか。理由は定かではない。ともあれ、「責任者」が責任を果たしていないように思えた。この人達が、プロジェクトの心配を事前に捕捉しておいてくれれば、現場のリーダーがあんなに消耗しなくてもよかったはずなのだ。 <br />
<br />
<br />
でも、どうやら、こうした組織構造は、一朝一夕には、なおらないかもしれない。だとしたら、現場を率いるリーダークラスが、せめて実務に役立つリスク・アセスメントの進め方を、身につけて欲しいと思っている。だから、（前回の繰り返しになるが）11月16日と23日の二日間コースで、プロジェクト・マネジメント研修を組むことにしたのである。 <br />
<br />
<br />
研修セミナー名称： <br />
「プロジェクトマネジメント研修　～リスクマネジメント編～」 <br />
<br />
<br />
日時：11月16日・23日 各10:00～17:00 <br />
講師 <br />
　 八卷 直一氏（静岡大学工学部 名誉教授） <br />
　 佐藤 知一氏（日揮(株) 博士(工学)/静岡大学 客員教授） <br />
　 串田 悠彰氏（(株)未来生活研究所 博士(工学)） <br />
<br />
<br />
参加申込み： <br />
https://www.hamanako.jp/info/0146.html<br />
<br />
<br />
<br />
<br />
<br />
なお、最後に、一つだけつけ加えたい。リスク・アセスメントで重要なのは、言うまでもなく、リスク対策の立案である。ところで、実際にやってみると分かるのだが、現在のPMBOK Guide(R)にあげられている、4種類のリスク対応戦略（回避・転嫁・軽減・受容）だけでは、なんだか十分ではないのだ。 <br />
<br />
<br />
そこでこのセミナーでは、リスク発生の構造にまで立ち戻って、必要な対応戦略をもっと充実させている。ただ、そのためには問題事象の原因分析まで、理解する必要がある。おまけにPMBOKの枠組みを超えてしまう。このため上記の研修では、PMP試験対策としてのPDUは発行していない。その点をご了承いただければ幸いである。 <br />
<br />
<br />
<br />
<br />
＜関連エントリ＞ <br />
　「危険予知：プロジェクト・リーダーに必須の能力として（11月16/23日・PMセミナーのお知らせ）」  (2021-10-10) <br />
<br />
<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>リスク回避的な行動傾向は、どういうメカニズムで生じるのか</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/29375217/" />
    <id>http://brevis.exblog.jp/29375217/</id>
    <issued>2021-01-17T14:48:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2021-01-17T14:38:10+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[今、ここに二つの壺がある。左のツボには、白い碁石だけが入っている。右の壺には、白黒に種類の碁石が同数だけ入っていて、よく混ざり合っている。 <br />
<br />
<br />
さて、あなたが左の壺に手を入れて石を一つ取り出し、それが白い碁石だったら、1万円もらえる。つまり、確実に1万円だ。あなたが右の壺に手を入れて一つ取り出し、それが白い碁石だったら、あなたは2万2千円もらえる。黒い碁石だったら、何ももらえない。いわば、半々の賭けである。 <br />
<br />
<br />
あなたは左の壺を選びますか、それとも右の壺を選びますか？ <br />
<br />
<br />
たぶん、多くの人は、左の壺を選ぶと思う。わたしも同意見だ。もちろん、決める際に、一瞬は頭を働かせるだろう。左の壺は1万円得られる。右の壺で得られる金額の期待値は、1万1千円になる。だから期待値で言えば、右のほうが少し高い。それでも（その日の気分にもよるだろうが）、たぶん左を選ぶ。 <br />
<br />
<br />
つまり、多くの人は「確実」を好むのである。少なくとも、ほぼ同等の結果が期待されるときには、賭けよりも確実を望ましいと感じる。だが、なぜそう感じるのか？ <br />
<br />
<br />
この問題に取り組んだ研究者は、けっこう古くからいる。18世紀、つまり今から300年近く前に、スイスのダニエル・ベルヌーイは、人間は金銭的な額そのものではなく、その金額に対する主観的な価値にもとづいて判断するのではないかと考えた。この主観的な価値は、現在の経済学では『効用』Utilityと呼ばれる。 <br />
<br />
<br />
横軸に金額を取り、縦軸に効用をとると、その関数形は直線的ではなく、おそらく上に凸のカーブになると思われる。つまり、主観的な価値は、増え方が次第に緩やかになっていく（経済学的な用語を使えば、限界効用は逓減していく）。そして、複数の状態がありえて、それぞれに確率が見積もれる場合は、確率で重み付けした効用が（つまり効用の期待値が）、判断基準になる。 <br />
<center><img src="https://pds.exblog.jp/pds/1/202101/17/47/e0058447_14305604.jpg" alt="_e0058447_14305604.jpg" class="IMAGE_MID" height="443" width="500" /></center><br />
図を見てほしい。赤いカーブの線が、効用を表している。横軸1万円のところの高さが、左の壺を選んだときの効用である。右の壺を選ぶと、半々の確率で、ゼロと2.2万円の結果が得られる。その状態は、ゼロの効用値と、2.2万円の効用値のちょうど中間の点にくる。 <br />
<br />
<br />
ところで、効用は上に凸のカーブのため、横軸2.2万円のところの高さは、1万円の値の2.2倍よりも小さくなる。だから、右の壺を選ぶ「賭け」で期待できる効用は、1万円の確実な効用よりも小さくなってしまう。このために、多くの人は、リスクのある賭けを回避して、確実を選ぶのである。 <br />
<br />
<br />
ちなみにベルヌーイは、効用の関数形を、金額の対数だと考えた。たしかに対数関数は、ずっと上に凸だ。そして、これは、音量などの感覚信号の強さと、その主観的な影響をしらべたフェヒナーの法則にも合致する（ウェーバーとフェヒナーによる、この法則の発見は19世紀だが）。 <br />
<br />
<br />
対数ということは、つまり差ではなく、比で感じる、という意味だ。1万円が2万円に増えるときのありがたみの方が、2万円が3万円に増えるときのありがたみよりも強い。なぜなら、前者は2倍だが、後者は1.5倍に過ぎない。同じだけのありがたみは、2万円が4万円になったら、感じるだろう、と。 <br />
<br />
<br />
ちなみに、人間のリスク回避的な傾向を説明するためならば、別に対数関数でなくても、上に凸な関数ならば（つまり「限界効用逓減の法則」が成り立てば）、どんな形でもいい。だから今の経済学は、ベルヌーイの対数法則には依拠していない。 <br />
<br />
<br />
限界効用逓減の法則については、別の有名な問題を使っても、説明される。昔、どこかの大学の経済学部で出された試験問題だそうだが、 <br />
<br />
<br />
「街で売っているオレンジには、『普通』と『上等』の、二種類の商品種がある。ところで、オレンジの産地であるフロリダと、大消費地であるニューヨークを比べると、ニューヨークの方が、上等の品種の売れる比率が高い。これはなぜかを説明せよ」 <br />
<br />
<br />
この問題を見て、「都会であるニューヨークの人たちのほうが、所得レベルが高いから贅沢なんだろう」など単純に答えると、間違いになる（まあ、放っておくと、メディアやネットでは今でもこうした「解説」が流通しそうだが）。 <br />
<br />
<br />
実は、ここで価格と「効用」の関係を考えなければならない。オレンジは、産地フロリダからニューヨークまで運ぶと、当然ながら輸送費がかかる。その分、販売価格に反映しなければならない。ところでオレンジ1個あたりの輸送費は、普通だろうが上等だろうが同じ金額になる。かりに、元の産地フロリダでの価格が、「普通」は1個2ドル、「上等」が3ドルだったとしよう。ここに運賃が、たとえば1個あたり50セントかかる。するとNYでの価格は、普通が2.5ドル、上等が3.5ドルになる。 <br />
<br />
<br />
期待効用逓減の法則から考えると、NYでの価格差は、フロリダでの価格差よりも小さく感じられる。つまり、消費地での「上等」オレンジの方が、産地よりも、コストパフォーマンスが高く見えるのだ。だから、上等の売れる比率が大きくなる。こう、答えなければ、経済学での正解とは言えない。 <br />
<br />
<br />
なお、複数の状態があったときには、その効用の確率的な期待値で決まるという考え方（期待効用仮説）を打ち立てたのは、「ゲーム理論」の創始者である物理学者フォン・ノイマンと経済学者モルゲンシュテルンだった。現代経済学の「期待効用理論」は、この前提からできあがっている。 <br />
<br />
<br />
ところで、3百年前のベルヌーイは、上記の効用の考え方を用いて、損害保険というビジネスがなぜ成り立つのかも、考察した。彼の対象は、当時の大きな問題であった、輸送船の沈没に伴う保険だった。外航船が沈没すると、商人は積み荷と財産をすべて失う。シェイクスピア「ベニスの商人」にも出てくるリスクである。 <br />
<br />
<br />
損害保険というのは、基本的に、損失が出たら保証してくれる代わりに、保険代金を支払う。かりに船の10隻に1隻が沈没するとしよう。保険会社は、船荷の金額の10%以上を保険料としてもらわなければ、割に合わないはずである。海上保険会社が成立し、損害保険ビジネスが成立している訳だから、単純な期待値としては、支払う側が損をする。それなのに、なぜ保険にカネを払うのか？ <br />
<br />
<br />
理由は、損失のインパクトが、保険をかける側と引き受ける側で違うからである。たとえば1000万円分の損失は、資産総額1200万円しか持たない人と、資産10億円の人とでは、全然違う。当然ながら、前者のほうが、ずっと効用からみたインパクトが大きい。 <br />
<br />
<br />
ベルヌーイは、だから、小さな資産しか持たぬ商人がリスク回避のために保険をかけ、大きな資産をもつ商人が、その保険を引き受ける仕組みが成り立つのだ、と説明した。いいかえると、リスクを抱える普通の人たちから、お金が少しずつ富豪に集まる構図になる訳だ。 <br />
<br />
<br />
そして、余談だが、おなじ傾向が、COVID-19をめぐるワクチン問題に対しても、当てはまるのだろう。 <br />
<br />
<br />
わたしは以前から、なぜワクチンに皆があれほど期待を寄せるのか、疑問に思っていた。コロナウィルスというのは変異が多く、一つのワクチンを開発しても、効かない新種の出る可能性が常に残る。じっさい、おなじコロナウィルスであるインフルエンザにはいろいろな型があって、毎年流行が変わり、予防接種をしても効かないケースがけっこうあるではないか。 <br />
<br />
<br />
しかも、ワクチンの対象者は人口の全員だから、日本だけで1億2千万本からのワクチンを用意しなければならない。それくらいならば、COVID-19に感染して発症した患者を、有効に治療する治療法の開発に集中するほうがいい。感染者数は今日現在でも30万人に過ぎない。この人達が重症化しないような治療薬や治療法を開発するほうが、ずっと経済的ではないか。感染してもちゃんと治るのなら、安心して街を歩ける。 <br />
<br />
<br />
じっさい、インフルエンザに対しては、わたし達はそうしている。インフルエンザは、日本では診断書ベースで毎年3千人が亡くなっている深刻な病気だ（WHOの計算手法では1万人ということになっている）。それでも、わたし達がインフルエンザをあまり深刻に恐れていないのは、すでにタミフルを始めとする治療薬が発達しているからだ。 <br />
<br />
<br />
発熱して医者にかかっても、その場の検査でインフルかどうかはすぐ判別でき、薬をもらうと、多くはごく短期間で治まってしまう。インフルが怖いから電車に乗らない、職場にも行かない、という人は滅多にいない。そして、COVID-19の重症化を抑える効果のある医薬品も、すでに複数の候補があるのだ。 <br />
<br />
<br />
それなのに、なぜ、皆ワクチンの話ばかりするのか。それは一種の保険だから、なのかもしれない。米ファイザー社のワクチンは、有効度が95%だそうだ。つまり、ほぼ確実に近い印象である。 <br />
<br />
<br />
年末に、医療関係者と話したら、その人は「ワクチンは決して100%万全ではないし、副作用だってゼロではあるまい。それは分かっているけれども、患者に接する立場として、まず自分たちが接種を受けてみるしかないのだろう」と、非常にリアリスト的な見方をしていた。しかし、多くの人は、もっとふわっとした期待を込めているように思われる。 <br />
<br />
<br />
それは、わたし達の社会の多くの人にとって、『リスク最小化の原理』で行動することが身に染み付いているからなのだろう。不確実な状況下では、損失リスクを回避する方向を選ぶ人が多い、ということだ。 <br />
<br />
<br />
有効な治療法をはやく確立すること、そのために専門の治療体制を各地に作ることが急務であるし、結局はずっと経済的だと思う。感染症の専門医が、「今こそ治療法の開発に集中すべき大事な時期だから、感染症病棟を患者で溢れさせるようなことはしないでほしい」と、昨年TVで発言していたことも思い出す。 <br />
<br />
<br />
だが、いつもは社会的にコスト・コンシャスな経済学者も、あまりこういう趣旨で発言する人がいないように感じられるのは、なぜだろうか。まあ、カーネマンが「ファスト＆スロー」で指摘したように、経済学者も結局は人の子、経済価値だけで判断するわけではない、ということかもしれない。 <br />
<br />
<br />
そして、期待効用理論に対しても、批判や反証がある。長くなってしまったので、これについては稿を改めて、別の機会に、また書こう。 <br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
　→「リスクに対する新しいアプローチ」  (2010-09-01) <br />
　→「安全と危険の境目をはかる」  (2011-04-21) <br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>お知らせ：TOCシンポジウムでプロジェクト・マネジメントに関する基調講演を行います（11月30日 13:00-14:00）</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/29269464/" />
    <id>http://brevis.exblog.jp/29269464/</id>
    <issued>2020-11-21T00:43:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2020-11-21T00:43:52+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[またまた、お知らせです(^^) <br />
<br />
<br />
TOC（Theory of Constraint）という考え方について、聞いたことのある方も少なくないと思います。イスラエルの科学者・故ゴールドラット博士が提唱したマネジメントに関する理論で、『制約理論』とも訳されますが、最近はTOCと略称で呼ぶ方が一般的でしょう。 <br />
<br />
<br />
TOCはサプライチェーン・マネジメント、プロジェクト・マネジメント、スループット会計、思考プロセスなど、幅広い分野に対する手法を提供しています。とくに90年代に、サプライチェーン・マネジメント分野に与えた影響は大きく、『全体最適』の思想や、生産スケジューリングのアルゴリズムなどにも、そのインパクトを見ることができます。 <br />
<br />
<br />
かくいうわたし自身も、1998年に出版した共著『サプライチェーンマネジメントがわかる本』（SCM研究会・編）の中で、ゴールドラット博士のTOCを、思考プロセスも含めて簡単に紹介しました。これは、まだ邦訳書のなかった当時としては、かなり早い紹介文だったと思っています。 <br />
<br />
<br />
ゴールドラット博士にはどこか教祖的な魅力があるらしく、TOCを実践に移す人たちのコミュニティは、日本でも着実に成長し、博士の没後も続いています。今年の「TOCシンポジウム」はコロナ禍の影響を受けてオンライン開催形式ですが、それなりに大勢の方が参加されると思います。 <br />
<br />
<br />
たまたまお声がけいただき、わたしも今年は基調講演をさせていただくことになりました。ただ、わたし自身はTOCについては素人ですので、得意の知ったかぶりは避けて（笑）、自分自身が考え出したプロジェクト・マネジメントに関する理論について、あえてお話するつもりです。そのエッセンスは、2010年に東大に提出した学位論文に書いている内容ですが（「リスク確率に基づくプロジェクト・マネジメントに関する研究」静岡大学出版・参照のこと）、今回はその後10年間の発展も含めて、できる限り分かりやすい形でご説明するつもりです。 <br />
<br />
<br />
最近は直前のご案内が多くて恐縮ですが、多くの方のご来聴をお待ちしております。 <br />
<br />
<br />
<br />
<br />
＜記＞ <br />
<br />
<br />
「TOCシンポジウム＆TOCインダストリーフォーラム 2020」 <br />
<br />
<br />
講演タイトル「リスク確率に基づく価値評価とプロジェクト・マネジメントの提案」 <br />
<br />
<br />
日時：　2020年11月30日(月) 13:00〜14:00 <br />
主催：　日本TOC推進協議会 他 <br />
<br />
<br />
講演概要： <br />
　プロジェクト・マネジメントの目的は、「プロジェクトの価値を最大化すること」にあります。また、プロジェクト・マネージャーの仕事の中核には、つねに「決断」があって、複数の選択肢の中から、プロジェクトの価値が最も大きくなるものを選び取っていく必要があります。 <br />
　それでは、あなたの関わっているプロジェクトは、現在、具体的にいくらの価値があるのでしょうか？　そして、プロジェクトを構成する各アクティビティは、全体の価値に対し、いくらずつ貢献しているか、ご存知ですか？　典型的なトレードオフ状況、たとえば、値段が高いが品質の良い外注先Aと、安いけれど品質に問題含みの外注先Bから、どちらかを選ぶ時、判断基準はありますか？ <br />
　本講演では、リスク確率に基づくプロジェクトの価値評価と、そのマネジメントについて解説します。さらにサプライチェーンの中での中間製品の価額決定や、生産部門と販売部門の貢献度の比較、そしてフロート日数を1日消費することは、いくらのコスト増に相当するのかといった問題を、全く新しい視点から解決します。 <br />
<br />
<br />
申込み：　下記をご参照ください <br />
    http://www.j-toc.jp/event/symposium2020.html <br />
<br />
<br />
以上、よろしくお願いいたします。 <br />
<br />
<br />
<br />
<br />
佐藤知一＠日揮ホールディングス（株） <br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>敗北から何を学ぶか　〜　その2・結果よりもプロセスに学べ</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/28507685/" />
    <id>http://brevis.exblog.jp/28507685/</id>
    <issued>2019-08-07T23:12:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2019-08-07T22:55:24+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[－－敗北から学ぶために必要な方法にも、いくつかある。ここでは4つぐらいあげようか。<br />
<br />
<br />
まず第一に、勝敗の結果だけではなく、プロセスと中間目標を設定しておく。本当はこれは、戦う前に、やっておく必要がある。その上で、個別の戦局や、あるいは全体における達成度を吟味する。<br />
<br />
<br />
「どういうことですか？」<br />
<br />
<br />
－－つまりさ、ローマは1日にしてならず、というだろう。たとえば何でもいいけど、大学受験を例に取ろうか。難関の名門校に入りたい、と。そうしたら、受験科目のどれが得意か、どう勉強するのか、予備校には行くのか、考えるだろう？　また、模試を複数回受けるとして、現役1回目は何点くらい、2回目は何点、と想定して、直前模試でA判定になればいいはずだ。<br />
<br />
<br />
こう言う風に、単なる勝ち負けだけでなく、プロセスと中間目標を設定する。そして、途中途中で、目指した通りに進んでいるか検証する。うまくなければ軌道修正する。仮に現役では合格できなくても、もう一度チャレンジするべきか、考え直す。そして反省点を翌年の試験に生かそうとするだろう・・それなのに、受験生のときにはできていたことが、ビジネスマンになるとすっかり忘れてしまうとしたら、奇妙なことだ。<br />
<br />
<br />
「確かにそうですね。でも、その中間目標というのは、実際にはどう立てたらいいんでしょう。ビジネス上の戦いは、受験ほど単純じゃありません。偏差値の表もなければ、予備校の模擬試験もありませんし。」<br />
<br />
<br />
－－もちろんだ。だから2番目に大切なことは、適切な戦略を選んでから、中間目標に落とし込むと言うことだ。<br />
<br />
<br />
「戦略を選ぶ、ですか？　戦略って、毎回個別に考えるものかと思っていました。」<br />
<br />
<br />
－－もちろん、そうさ。そうだけれども、戦略にはある種の定石ないしパターンがある。まあ、戦略論は多岐に渡るから、ざっくり簡単なパターンに絞って説明することにしようか。<br />
<br />
<br />
たとえば市場における競争戦略は、その会社の立場によって異なる。チャンピオンの戦略と、挑戦者にとっての戦略と、ニッチプレイヤーの戦略は異なる。あなたのところの会社は、チャンピオンかな、それとも挑戦者か、ニッチプレイヤーなのかな？<br />
<br />
<br />
「えーと・・あまり考えたことがありませんでした。今回の戦いに限って言うと、トップ企業じゃないから、チャレンジャーかなぁ。」<br />
<br />
<br />
－－なるほど。どんな業界も大体、少数のトップ企業と、それに次ぐチャレンジャーたちと、多数の小さなニッチプレーヤーからなる、いわばピラミッド構造になっている。<br />
<br />
<br />
業界のトップ企業は、その規模を生かして、製品もフルラインナップを揃えているし、営業ネットワークもあるし、物量を生かしてローコストで大量生産ができる。だから最終的には価格競争に持ち込んで、顧客を囲い込む。これを『コストリーダーシップ戦略』という。戦争に例えるならば、正面攻撃の戦術といってもいい。<br />
<br />
<br />
「はい。」<br />
<br />
<br />
－－一方、チャレンジャーたちは、正面から価格競争を挑んでも、勝てそうもない。そこで普通は、『差別化戦略』を考える。大手が販売する製品とは、かなり異なった特徴のある製品を売り出して、価格とは別の面で顧客に訴求する。側面攻撃の戦術と言っていいだろう。<br />
<br />
<br />
「確かにある意味で、僕らが戦う上でとっていた方策は、差別化を志向したと言ってもいいかもしれません。意識してやったわけではありませんが。」<br />
<br />
<br />
－－なるほど。そして大多数の、中小零細規模のプレイヤーたちは、ある狭い局地的範囲内のみに、自分たちの持てる経営資源を集中して、そのニッチなマーケットだけは死守しようとする。例えば顧客との長いつながりで商売を続けている、地方の老舗の商店を考えればわかるかな。あるいはごく特殊な製品のみを扱う、その分野でのみ全国的に名の知られている企業なんかも、これに近い。いわば局地戦、ないしゲリラ攻撃の戦術だ。これを『集中戦略』という。<br />
<br />
<br />
そしてこの3つの戦略ごとに、立てるべき方策も、中間目標も異なっている。<br />
<center><img src="https://pds.exblog.jp/pds/1/201908/07/47/e0058447_22472150.jpg" alt="_e0058447_22472150.jpg" class="IMAGE_MID" height="201" width="500" /></center><br />
「なるほど、そういう風にロジックを持って考えると、中間的な目標も立てやすいですね。」<br />
<br />
<br />
<br />
－－ただしね、ここに挙げたのはパターンに過ぎないから、実際には具体的に何をどうするかを考えないと、戦略の名に値しない。戦略とは、固有名詞が入って初めて、役に立つものだ。<br />
<br />
<br />
たとえば第二次大戦中、ドイツ軍に占領されたフランスを奪還するために、連合軍が作戦を考えるとしよう。その時、側面攻撃しよう、フランスの大西洋岸から上陸だ、だけでは戦略とは呼べない。具体的に、カレーを攻めるのか、ノルマンディーから上がるのか、それとも別の攻略ポイントを探すのか。具体的な地名と、時期と、兵力と、方法がなければ、戦略にならないし、準備もできない。わかるだろう？<br />
<br />
<br />
「たしかに。」<br />
<br />
<br />
－－もしも、あなたの会社がチャレンジャーで、差別化戦略を志向するなら、どのような訴求点を持つべきか。どの程度他社を引き離すべきか。それによって得られる金銭的なアドバンテージはいくらぐらいか・・といったことについて仮説を立て、目標設定して、検証していくんだ。<br />
<br />
<br />
戦略とは仮説だ。「こう戦えば、きっと勝てるはずだ」という仮説だ。だがしばしば、仮説には間違いがある。だから途中途中で検証しながら進む必要がある。人間は誰だって、自分たちが有利であると言う思い込みにとらわれやすく、そこから間違った仮説が生まれやすい。したがって、仮説を文字に残しておくことがとても重要だ。<br />
<br />
<br />
「でも、方針というのは、いったん書面にすると、仮説どころか、絶対化されやすいですが。」<br />
<br />
<br />
－－そうだね。だから、3番目に大事なのは、戦いを始める前に、状況を客観的・数値的に分析しておくことになる。たとえばマーケットの戦いならば、敵は誰と誰で、どういった商品を揃えていて、どんな販売チャンネルを抱えているのか。これまでの売上高や、受注確率はどれくらいなのか。顧客はどんなセグメントからなっており、どういう好みを持っているのか。こうしたことを事前に分析しておかなければいけない。<br />
<br />
<br />
「具体的には、例えばどんなことですか?」<br />
<br />
<br />
－－そうね。例えば営業における受注競争なら、過去の勝率はどうだったのかという事さ。もしも自社の平均的な勝率が約3割で、今期の受注目標が10億円だったら、最低でも合計33億円以上の可能性のある競争案件を、営業リストに載せなければ、目標は達成できない。また、既存顧客には強いのか、大型の案件には弱いのか、といったことも分析の対象だ。<br />
<br />
<br />
「それってでも、案件ごとに条件が違うと思います。確率なんか言われても、個別の現場担当として役に立ちません。問題はむしろ、勝敗の質じゃないか、って感じるのですが。」<br />
<br />
<br />
－－勝敗の質ね。そう言いたい気持ちはわかるよ。でも、あなたは製造業の人だから、あえて尋ねるけれども、じゃあ不良品はモノの質が低く、良品はモノの質が高い、と言えるだろうか。むしろ、検査結果にデコボコがあって、予測し難い点に、問題があるのではないか。つまりモノの質ではなく、プロセスの質を上げるべきではないか。<br />
<br />
<br />
同じように、個別の戦いの勝ち負けだけが問題なのではなく、勝敗が予見し難いことが問題ではないのか？　そうなると、自社の体制や人材も、前もって適切に準備できないだろう。それはやはり、プロセスの問題なのではないか？<br />
<br />
<br />
「つまり、事前にもっと計画しておけ、ってことですね。でも、ウチのボスは、『どうせ計画した通りには現実なんか運ばないんだから、計画を立てるなんて時間の無駄だ。現場を見て状況に応じて考えればいい』と、つねに言っています。」<br />
<br />
<br />
－－もちろん現場を見て考えるのは、いつでも大切だ。しかし、計画抜き・現場判断、というやり方が通用するのは、ごく小さな戦局か、あるいは自社がリーダーで、戦い全体を自分たちの思惑通りに運んでいるときに限る。連合軍がノルマンディーに上陸するか、カレーに上陸するかを、現地を見て決められると思うかい?　上陸する兵士や機材を動員するのに、数カ月はかかる。上陸地点によって、必要な装備も違うだろう。数字に基づいた計画がいるんだ。<br />
<br />
<br />
第二次大戦の英雄だった米国のアイゼンハワー大統領は、「計画通りに現実は動かない。しかし計画を立てるプロセスは絶対に必要だ」と言っている。君の上司との違いがわかるよね。<br />
<br />
<br />
「たしかに、違いはありますね。」<br />
<br />
<br />
－－計画のための情報収集と分析は、分担を分けた方が良い。なぜなら分析は、総合的な情報を集めて行うべき仕事だからね。個別の情報入手した時点で、勝手にローカルな分析を行って解釈した結果を、中央に集めたりするのはあまり良いやり方ではない。データ収集には、必要ならば第三者の知恵を借りることも、するべきだろう。市場調査会社とか、コンサルタント、エージェントといった人たちだ。<br />
<br />
<br />
そして、戦いの中間の要所要所で、データを集めて状況を分析し、戦略を補正する。ターゲットとすべきセグメントが間違っていることもある。あるいは顧客の要求を読み間違えることだってある。それを一つ一つ、データによって検証する。ときには、撤退を考えなくてはならない場面もある。<br />
<br />
<br />
前に「マジックナンバー＝5」という話をしたのを覚えているかなあ。対等だと思った勝負に5連敗したら、もう対等だという仮説は捨てたほうがいい、という数学的法則だ。こういう判断は、データを積み上げないと出てこない。<br />
<br />
<br />
「データを集め、数字から学ぶ、ってことですか。確かに、ウチに一番欠けていたのはそこかもしれません。」<br />
<br />
<br />
－－そして最後の4番目は、戦いが終わったら、根本原因（Root cause）の分析を行うことだ。Root causeの定義とは、「論理的に見つけられる基本的原因で、かつ、マネジメントによって解決可能であるもの」だ。<br />
<br />
<br />
表面的に、客が悪いんだとか、運がなかったとか、不況や円高などの環境のせいにしては、いけない。それは自分たちには解決可能でない。だから根本原因に選んではならない。選ぶなら、なぜ客筋をきちんとアセスしなかったのか、なぜ為替リスクのヘッジを怠ったのか、運不運で決まるような案件に、なぜ大きな勝負を賭けたのか、を問題にすべきだ。<br />
<br />
<br />
「リーダーの責任というのは、どうなるんです？」<br />
<br />
<br />
－－根本原因分析をするときに気をつけるべき点は、「責任追及の場にしない」ことだよ。もし責任追及が主目的だったら、誰もが自分をかばって、本当のことを言わなくなる。本当のことがわからなかったら、根本原因分析なんて、どんな意味がある？　<br />
<br />
<br />
根本原因分析の最大の目的は、同じ種類の間違いを繰り返さないこと、つまり再発防止にある。そのために、自分たちの仮説や行動に足りなかった点は、どこかを明らかにする。そして教訓を文字に残す。<br />
<br />
<br />
敗北などのトラブル事象を、リーダーとか誰かの責任、で説明してしまうと、対策はその人間をポストからはずす、しかなくなる。じゃあ、他の人間をそのポストに据えたら、同種の間違いは決して起きない、と言えるのか？　それに、失敗したら責められる、という組織では、だれが新しい創造的な仕事に挑戦するだろうか。<br />
<br />
<br />
「ふー。結構大変ですね。とくに、勝負の前にやっておくことが多いですし。・・これ、ウチでやりきれるかなあ。」<br />
<br />
<br />
－－まあ、わたし自身だって、正直言って、いつも全部はできていなかったさ。ただ、こうすべきだったと思うから、偉そうに聞こえたかもしれないけれど、あえて喋らせてもらった次第だ。<br />
<br />
<br />
「でも、自分のところは、計画立案能力も弱いし、データ活用も、からきしダメです。片方だけでも大変なのに、両方なんて到底無理かな。」<br />
<br />
<br />
－－でもないさ。計画とデータ活用は、じつはワンセットの能力だから。<br />
<br />
<br />
「そうなんですか？」<br />
<br />
<br />
－－うん。計画を立てない組織には、ちゃんとした「ふり返り」もない。客観的なふり返りを知らない組織は、後で活用するためにデータを蓄積する、と言う姿勢もない。最初に用意しないまま、あとになってからデータを分析しようとするのは、予算も立てずに決算だけするようなものだ。<br />
<br />
<br />
「その財務の喩えは、よく分かります。計画とふり返りが、データ蓄積の基本なんですね。」<br />
<br />
<br />
－－計画とは、いいかえれば具体的なアクションの塊だ。そして計画を立てられないようなビジョンは、夢と言う。夢を見ているだけでは、現実は近づかない。<br />
<br />
<br />
夢に近づきたかったら、まず事実と経験から学ばなければ。たとえそれが、痛い経験であってもね。昔の人も言ったじゃないか、「過ちて学ばざる、これを過ちと言う」ってね。<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
　「失敗の無限ループから抜け出すマジックナンバー『5』」 https://brevis.exblog.jp/15454723/ （2011-09-15）<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>敗北から何を学ぶか　〜　その1・学ばないための5つの方法</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/28488149/" />
    <id>http://brevis.exblog.jp/28488149/</id>
    <issued>2019-07-28T19:48:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2019-07-28T19:48:22+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[久しぶりに会った年下の知人が、なんだか元気のない顔している。理由を尋ねてみると、数カ月間打ち込んで懸命にやった仕事が、見事にライバル会社にかっさらわれたのだそうだ。勝負に打って出たが、負けてしまった。疲れて意気消沈し、他の事にもあまり手がつかない。気がつくと、失った仕事のあれこれを考え、頭の中が堂々巡りの状態だという。 <br />
<br />
<br />
「まったく参りました。早く忘れて気分を切り替え、次の仕事に取り掛からなければと思うのですが、何か良い方法は無いでしょうか? 」 <br />
<br />
<br />
－－どうだろう。本当に早く忘れるのが一番良いことなのかな。必ずしもそうではないと思うけど。 <br />
<br />
<br />
「なぜですか?  同じところで足踏みしてたって、先には進めません。職場の先輩にもそう言われましたが。」 <br />
<br />
<br />
<br />
<br />
彼の言葉を聞くまでもなく、職場の皆がそう言いたい気持ちは、もちろんわかる。敗北は早く忘れて、次の一歩を考えろ。Don’t cry over spilt milk. 英語にもそんな感じの諺があるではないか。過去をいつまで振り返っていても仕方がない・・。 <br />
<br />
<br />
だが、それなりの年数、受注ビジネスに従事し、入札にも何回も関わってきた（そして、残念ながら負けた経験も少なくない）わたしは、少しだけ違う意見を持っている。敗北を忘れるためには、その前に、失敗経験からの「学び」を、ちゃんと記録しておく方が有用だ。そんなふうに、最近は考えている。 <br />
<br />
<br />
もっともわたし自身は、この何年間かプロジェクトの現場を離れて、企画部門に働いているので、必ずしも自分があるべきと思う通りに、仕事ができているわけではない。だが、自戒と反省を込めつつ、わたしは彼に答えた。 <br />
<br />
<br />
<br />
<br />
－－だって、将来、全く同じでは無いかもしれないけれど、似たようなビジネスにまた君の会社がチャレンジしたくなる可能性もあるだろう?　だとしたら、今回の教訓をちゃんと記録して、共有しておいた方が良いはずだ。 <br />
<br />
<br />
「・・うーん、まあそうかもしれません。ただ、自分ではもう二度と御免だ、と言う気持ちですが。」 <br />
<br />
<br />
－－もちろんわかるよ。何も今日すぐに、とは言わない。少し気持ちが落ち着いて、でも具体的なディテールを忘れない内に、早めに取り組むことをお勧めする。 <br />
<br />
<br />
「といっても、一体何を学ぶんですか?　ビジネスは結果が全て。今回は、武運拙く負けた。でも結局、負けは負けじゃないですか。」 <br />
<br />
<br />
<br />
<br />
（ビジネスは結果が全て。よく聞く言葉だ。勝ちか、負けか。1か0か。確かにそこからは、何も学びようがない。だが本当にそうなのだろうか?） <br />
<br />
<br />
<br />
<br />
－－もしもビジネスが、サイコロを転がして、出る目を当てるだけのようなゲームだったら、前回「1」が出ても、今回は何の目が出るか全くわからないのだから、結果からは学びようがないね。じゃあ君も、今回はサイコロのようにまったくの偶然で、勝敗が決まったと言うのかい? <br />
<br />
<br />
「いや、そうは言いませんよ。ですが、偶然の要素は大きいんじゃないかな。偶然というか、自分ではどうしようもない環境要因ですかね。」 <br />
<br />
<br />
－－なるほど。自分も受注競争に負けた後は、よくそう考えていたものだ。だけどね、ひと月経ち、三月経ち、頭も冷静になってから振り返ると、やはり負けた時は、『負けるべくして負けたのだ』と、考え直すことが多かった。よく、ラッキーによる勝利はあるが、偶然のアンラッキーによる敗北はない、と言われるのは、根拠のないことじゃない。 <br />
<br />
<br />
「でもそれって、論理的に矛盾していませんか?　偶然による+100があるのなら、偶然による− 100もある。そういう風に思えるのですが。」 <br />
<br />
<br />
－－じゃあ、野球の世界で言う『 1点差の負けは、監督の責任』って諺は聞いたことがあるかな。大差で負けた時は、戦力自体に大きな差があるか、あるいは勝敗の大きな流れみたいなものに左右されて、抗いがたい。明らかに自分たちのリソースや、技術や体制に問題がある訳だ。だが、僅差での負けは、ちがう。マネジメントの判断ミスによるものなのだ。 <br />
<br />
<br />
「そうかなぁ。どうしてですか？」 <br />
<br />
<br />
－－どんな勝負事やスポーツでも、チャンスが巡ってくる時というのが、あるだろう?　それも、2つ3つ、続けてやってきたりするものだ。なぜだか知らないけどね、まるでエレベーターみたいに団子になってやってくることが多いのさ。（「なぜエレベーターは（そして仕事も）、一度にまとまって来るのか」 https://brevis.exblog.jp/27699308/ 参照のこと） <br />
<br />
<br />
「そういうことは、あるかもしれません。」 <br />
<br />
<br />
－－その時に、良い判断ができる監督は、最初のチャンスでうまくアドバンテージを掴んだら、それをさらに次のチャンスで増幅する。ちょうど、賭け金を増やしていくようなものかな。ところが判断の悪い監督は、賭け金を増やすことを怠る。逆に、チャンスを失うと、次の賭け金を増やしたりする。君は、連続するチャンスに上手く乗ることのできる判断能力を持つ人と、一つ一つをバラバラにしか判断しない人と、どちらが、より信頼できる監督だと思う? <br />
<br />
<br />
「それは、ちゃんと賭け金を増やす判断のできる監督でしょう。」 <br />
<br />
<br />
－－だよね。しかし、負けた直後には、自分ではなかなかわからないものだ。自分自身がその渦中にいて、事態を客観的に見る余裕がないからだ。とくに貴方みたいにリーダーの立場だったら、なおさらだね。しばらく経ってから、ようやく振り返って、やはり負けるべくして負けたのだと悟ることになる。 <br />
<br />
<br />
「うーん。では、どうしたら良いのですか？」 <br />
<br />
<br />
－－そうだね、まず敗北したときの振り返りで、やってはいけないことをあげよう。5つ位あるかな。 <br />
<br />
<br />
<br />
<br />
失敗に学ばない5つの方法 <br />
<br />
<br />
<br />
まず第一。誰かのせいにしてはいけない。顧客のせいにしてはいけない。上司のせいにしてはいけない。無能な部下や同僚や、勝手な営業のせいにしてはいけない。誰かのせいにした途端、思考がそこで止まってしまう。それでは学びにつながらない。 <br />
<br />
<br />
顧客が馬鹿だった、は禁句にする。賢い顧客なら、貴方の会社が勝ち、馬鹿な顧客だったら、あなた以外の会社が勝つ。もし本当にそうなのだったら、あなたのビジネスモデル自体が、根本から間違っていることになる。 <br />
<br />
<br />
「どうしてですか?」 <br />
<br />
<br />
－－世の中にはね、会社の門前に、いわば見えない行列ができて、その中から自分の好ましい顧客の仕事だけを、選び取って受注していくような会社だって存在するんだよ。貴方がもし、馬鹿な顧客の仕事を取ろうと、ライバル会社と競争しているのだったとしたら、賢い顧客からのみ選ばれるようなビジネスモデルをめざさなければいけない。そうだろう? <br />
<br />
<br />
「・・反論しにくいですね。」 <br />
<br />
<br />
－－ちなみに、敗北は誰かの責任だと考えて、悪者探しを始める代わりに、全員の気合が足りなかった責任だと考えて、総懺悔するというのも、もちろん学びには通じない。だって、負けるたびに総懺悔しているのであれば、毎回、全く同じ反省内容になってしまうわけだからね。 <br />
<br />
<br />
2番目。敗北に別の名前をつけてはいけない。たとえば、一番極端な例をあげると、戦前の大本営発表のように、敗退を「転戦である」と 言い換えたりする。これも良くない。ひどいときには、戦いなどそもそもなかった、と強弁する。 <br />
<br />
<br />
「もしも負けていないのなら、学ぶ必要など全然ないですものね。」 <br />
<br />
<br />
－－その通りだ。人間は、だれでも心の中に、見てはいけない・触れてはいけないアンタッチャブルな思考停止の領域を持つと、全体として思考能力が低下する状態に陥りやすい。これは断じて避けなければいけない。 <br />
<br />
<br />
3番目は、競争の制度やルールが悪いと批判することだ。 <br />
<br />
<br />
「だめですか。僕は今回、そこのところにけっこう不満があるんですけれども。」 <br />
<br />
<br />
－－競争のルールやあり方そのものに、問題がある場合は結構多いし、それは改善していかないと世の中全体が良くなっていかないよね。しかし不公平なのは、相手側にも同様なんじゃないか。それとも、完全にフェアで公正な競争だったらば、君の会社が必ず勝って、不公平なルールだったら君のライバルが必ず勝つ、と言うようなゲームなのかな？　だとしたら、そんな勝負の土俵に上がらないとビジネスが続けていけないこと自体に、問題があると言えるだろう。 <br />
<br />
<br />
「うーん・・」 <br />
<br />
<br />
－－4番目は、『結果が全てだ』と考えて、途中のプロセスを考えないことだ。勝敗の結果は、すべてプロセスの積み上げによって決まる。野球だってサッカーだって、序盤、中盤、終盤戦があって、それぞれ布陣や作戦を変えるものだ。いや、試合が始まる前から、様々な準備や情報収集がある。ビジネスだって同じだろう? <br />
<br />
<br />
「そうかもしれません。」 <br />
<br />
<br />
－－これが競争入札なら、顧客の案件察知という準備段階から始まって、顧客要求の理解と読み込み、見積設計、サプライヤーへの引き合い、納期とスケジュールの計画、コスト積算、リスクのレビュー、提案書の作成、魅力あるプレゼンテーション…と言う具合に、様々なステップからなっているプロセスだ。 <br />
<br />
<br />
こうした作業一つ一つを、万全に積み上げてこそ、ようやく勝利が手に入る。このプロセスのどこまでがうまく進んだのか。どこでつまずいたのか。どこら辺から、戦況がおかしくなったのか。それを知ることこそ、次の学びにつながるんじゃないか。 <br />
<br />
<br />
「戦況の変化かあ。潮の変わり目は、たしかにあの辺りだったかもしれないなあ・・」<br />
<br />
<br />
そして5番目は、敗北後の総括や情報収集を怠ること。客観的で正確な情報把握ができなくては、どんな反省をしても、意味のない無駄なものになってしまうからだ。たとえば入札だったら、技術面と価格面と納期と、どこで負けたのか。競争相手とどんなに開きがあったのか。こうした情報を取ってこなければならない。 <br />
<br />
<br />
ただ現実には、ここが1番難しい。ここは組織の行動習慣（いわばOS）が、問われる部分だ。特に顧客や競合相手の情報収集に対しては、営業部門の力が必要にある。だが、負けた仕事はすぐに忘れて次の仕事にかかるべし、と言う部門方針だと、ここが機能しなくなってしまう。 <br />
<br />
<br />
それと、上位マネジメントの姿勢も大切だね。現場に対して十分な支援をしなかったくせに、末端のリーダーだけ責任を負わせて査定を下げる、みたいな状態で、うまく『学び』が働くわけがない。最初に言ったように、誰かのせいにして終わり、だったら何も学ぶ必要はないのだから。 <br />
<br />
<br />
「・・なるほど。やっちゃいけない、『べからず集』みたいなものは、多少わかりました。じゃぁ具体的に、敗北から学ぶには、何をどうしたらいいのでしょうか?」 <br />
<br />
<br />
（この項つづく） <br />
<br />
<br />
<br />
<br />
＜関連エントリ＞ <br />
　「トラブル原因分析を、責任追及の場にしてはいけない」 https://brevis.exblog.jp/22555315/ （2014-11-09）<br />
<br />
　「なぜエレベーターは（そして仕事も）、一度にまとまって来るのか」 https://brevis.exblog.jp/27699308/ （2018-12-05）<br />
<br />
<br />
<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>プロジェクトの成功と、アウトカム</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/27261886/" />
    <id>http://brevis.exblog.jp/27261886/</id>
    <issued>2018-05-07T23:21:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2018-05-07T22:57:59+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[「自分がチャレンジする予定のプロジェクトでは、ゴール到達から成功失敗の判断まで半年かかることになっていますが、このような目標設定は適当ですか？」<br />
<br />
<br />
今回は、この質問を取り上げよう。例によって、大学でプロジェクト・マネジメントの講義をしていた時、学生から出てきた問いである。そして、とても良い質問だ。<br />
<br />
<br />
このときの講義のテーマは、「ミッション・プロファイリング」だった。この用語は、PMBOK Guideには出てこないので、なじみのない読者も多いかとは思う。プロジェクトにおけるミッション、すなわち使命を、その目的・ゴール及び目標（＝成功基準）などの観点から、分析・定義し文章化する作業である。その結果がプロジェクト・チャーターになる。<br />
<br />
<br />
授業では特に目標設定の大切さを学生に教え、修士論文や就活を題材に、プロジェクトとしての目標を考える、簡単な演習を入れている。さらに、自分がこれから将来関わるであろうプロジェクトの内容を考えて、そのゴール・目的・目標を、簡単なプロジェクト・チャーターの形に書かせている。上記の質問は、その中から出てきたものだ。<br />
<br />
<br />
この学生はどうやら、新しい技術を使った製品開発のプロジェクトにチャレンジしようと考えているらしい。プロジェクトがゴールに到達し、すなわち製品が無事に開発完了しても、それが本当に世の中に受けられるかどうか、売れて経済的にペイするかどうかは、その後半年ぐらいしないとわからない。そういう状況下で、プロジェクトの成功基準は、どのように考えるべきか?<br />
<br />
<br />
この質問を見て、私は3月に日経ビジネスオンラインが発表した、あるITプロジェクトの調査結果を思い出した。<br />
「プロジェクト失敗の理由、15年前から変わらず」 http://business.nikkeibp.co.jp/atcl/opinion/15/100753/030700005/?P=1<br />
という記事で、著者は日経コンピュータの元編集長・谷島宣之氏である。サブタイトルに、「1745事例を調査、成功率は52.8％」とある。簡潔ながら要点をついた、良い記事であると思うので、読まれることをお勧めする。<br />
<br />
<br />
この記事によると、日経コンピュータ誌が2003年に行った第一回の調査や、その後、数年おきに行われた調査結果から見て、日本では明確にITプロジェクトの成功率が上がってきていると言う。それ自体はとても重要で、良いニュースだ。「成功率が上がった理由の一つはプロジェクトにおける定量管理の普及だ」と記事は書いている。また、「失敗理由の筆頭はシステムの『要件定義が不十分』」というのも、うなづける内容である。<br />
<br />
<br />
ところで、この記事における「プロジェクトの成功」とは一体どのように定義されているのだろうか?　それは、「品質、コスト、納期の3点を順守できたか」である。品質をスコープに読み替えると、つまり『鉄の三角形』を守ることができたか、と問うている訳だ。<br />
<br />
<br />
実は、この日経コンピュータ誌と同様な調査を、米国ではStandish Groupという調査会社が'90年代から継続的に行ってきた。1994年以来、3年おきに発表された調査レポートでも、プロジェクトの成功率が問われ、そして徐々にあがってきている。それはプロジェクト・マネジメントの普及による成果だと解釈されている。ちなみに、Standish Group の定義は次のようになっている。<br />
<br />
<br />
Successful: completed on time, on budget, with all specified features.<br />
Challenged: completed and operational, but over-budget, over time and with fewer features than specified.<br />
Failed: the project is cancelled before completion or never implemented.<br />
<br />
<br />
すなわち、品質・コスト・納期を計画通り満足して終わった「成功プロジェクト」と、完了したが 3 大制約条件を満たせなかった「困難なプロジェクト」、そして中断終了した「失敗プロジェクト」のクラスがある。2003年の調査では、成功プロジェクトの比率は34%だった。同じ2003年の日経コンピュータ誌調査では、日本の成功率は約27%だったから、日本は米国の後を追いかけている訳だ。<br />
<br />
<br />
それはともかく、ここで問題にしたいのは、プロジェクトの成功を、コスト・品質・スケジュールの3点で定義していいのかということだ。それはいわば、プロマネ視点から見た成功、と言うことに過ぎない。鉄の三角形と言う大きな制約条件を満たした。それ自体は立派なことだ。だがプロジェクトとは、その成果物が価値を生み出して、初めて意義があるのではないか。<br />
<br />
<br />
どんなに立派なシステムを開発しても、ユーザがちっとも使ってくれなかった。そういう事例は、しばしば起きる。立派な地方空港を建設したが、閑古鳥が鳴いている事例もある。「仏作って魂入れず」とは、まさにこのような状況だ。<br />
<br />
<br />
プロマネの視点から見た、プロジェクト・マネジメントの成功だけで、プロジェクトの出来不出来を判断していいのか？　ここが問われている。新製品の完成後、世に受け入れられるかどうかは、半年ぐらい経ってみないとわからない、という最初の学生の質問は、まさにこの点をついているのだ。<br />
<br />
<br />
そこで必要となるのが、アウトプットとアウトカムの区別である。アウトプットとは、プロジェクトが直接生み出す成果物である。それは情報システムだったり、橋だったり地方空港だったりする。<br />
<br />
<br />
では、アウトカムとは何か?　それはプロジェクトの成果物を活用することでもたらされる、変化である。情報システムで生み出される、新しい業務プロセスかもしれない。橋がかけられたことで生じる、地域交通の活性化かもしれない。地方空港のもたらす、新しい経済効果かもしれない。<br />
<center><img src="https://pds.exblog.jp/pds/1/201805/07/47/e0058447_22495408.jpg" alt="_e0058447_22495408.jpg" class="IMAGE_MID" height="277" width="500" /></center><br />
<br />
図を見て欲しい。プロジェクトとは、インプットとして資機材等何らかのマテリアル、そして情報を受け取って、何らかのアウトプット=成果物を生み出す活動である。プロジェクト起動のトリガーとなるのは、何らかのオーダーなり受注であろう。プロジェクトを遂行するには、人々あるいは道具といったリソースが必要である。また、様々な要求事項や制約条件もあろう。途中段階や最後でのレポートも必要だろう。<br />
<br />
<br />
アウトプットを生み出せば、プロジェクト自体は完了する。しかしビジネスとしては、その先に大事なステップがある。それは成果物を活用して、アウトカムを生み出すことだ。<br />
<br />
<br />
このような構造を考えると、プロジェクトにはざっくりいって、2種類の成功があると考えられる。それは短期的成功と長期的成功だ。<br />
<br />
<br />
プロジェクトの短期的成功とは、効率よくアウトプットを生み出すことである。プロマネ視点での成功といってもいい。これに対し、長期的成功とは、プロジェクトが価値あるアウトカムをもたらすことである。<br />
<br />
<br />
英語ではよく、"do things right" と "do right things"という言い方で、この2つを区別する。Do things rightとは、ものごとを正しく（上手に）やること。Do right thingsとは、正しい（良い）ものごとを行うことを意味する。効率よく上手にやることが大切だが、価値あるものを作り出すことの方が、もっと重要だ。<br />
<br />
<br />
これに関連して、KPIとKGIという言葉もあげておこう。KPI（Key Performance Indicator）とは、いうまでもないが、仕事のパフォーマンスを測るための主要なモノサシである。企業活動全体なら、売上高とか利益だとか総資本回転率といった尺度だ。何かをマネジメントしたかったら、対象を計測して数値化し、それを計画や過去の類似実績や標準値と比較し、改善活動を促していく。これが定石である。プロジェクト・マネジメントの場合ならば、進捗率だとか総工期などがあげられる。EVMS（Earned Value Management System）の中にも、CPI（Cost Performance Index）とかSPI（Schedule Performance Index）などの尺度が内蔵されているのは、ご存じの通りだ。<br />
<br />
<br />
KGI（Key Goal Indicator）という言葉は、最近になってマーケティング、とくにWebマーケティングの分野で耳にするようになった。KPIが、途中のプロセスのパフォーマンスを表すのに対して、KGIはゴール＝結果の（たとえば顧客の購買率などの）よしあしを直接示す、という風に使われる。<br />
<br />
<br />
もしこれを、KPIはアウトプットに関するモノサシで、KGIはアウトカムに関する尺度だ、と解釈できるなら、上に述べた説明とちょうど合致する。ただ、KGIはそれを支える複数のKPIのツリー状になっている、という解説も見受けられるので、必ずしもそうもいいきれない。まあ、Webマーケティングとプロジェクト・マネジメントという異なる分野での概念なので、違っていても当然かも知れないが。<br />
<br />
<br />
いずれにしても大事なことは、プロジェクトの成功・不成功は、そのプロジェクトが完了した時点だけでは必ずしも決まらない、と認識することだ。あるいは、プロジェクトの価値は、そのプロジェクトだけを見ていても定まらない、と言いかえても良い。もしもその「プロジェクト」が、単にアウトプットを出すまでの射程距離を指すのなら、ということだが。そしてプロジェクトの成功を本気で心配するならば、「プロジェクト後」をケアしなければならない訳だ。だから、「ユニークな製品、サービスあるいは所産」を創造するまでをプロジェクトの範囲と考えると、プロジェクトの価値論はそこから抜け落ちてしまうことになる。<br />
<br />
<br />
仏を作って魂を込めたいならば、プロジェクト後のアウトカムの活用まで面倒見なければならない。また、活用しやすいアウトプットの要件を、最初に定義し設計することからはじめなければいけない。ここが肝要なのだ。「与えられた要件とSOWから、コスト・納期・品質の制約内で、成果物を効率よく生み出す」ことがプロジェクト・マネージャーのスコープだとすると、魂を入れる仕事は、その外側、ないし上位にある。<br />
<br />
<br />
プロマネの上位にあって、プロジェクトの価値を本当に作り上げるのは、じつは『プログラム・マネジメント』の仕事である。プロジェクトを起動し、プロマネを任命し、途中途中でプロマネを助け、評価し、成果物を受け取り、それを元に組織能力を変えていくのも、プログラム・マネジメントの仕事だ。完成しても価値を生まない、意味の無いアウトプットを作ろうとしている問題プロジェクトに中止を命ずるのも、プログラム・マネジメントだ。<br />
<br />
<br />
そういう意味で、わたしたちの社会で本当に足りていないのは、プログラム・マネジメントの方なのである。そこの欠落を、プロジェクトのレベルで何とか解決しようともがいているプロマネが、あまりにも多い。それはとくに、要件定義から成果物構築までの段階を、ほとんどすべて外部にアウトソースしてしまう、IT分野に著しい傾向なのかも知れぬ。<br />
<br />
<br />
多くの人は、「プログラム」とは同時に複数のプロジェクトを束ねたものだ、と理解しているようだ（米国PMIの定義）。しかし、わたしは、たとえ単一プロジェクトでも、プログラム・マネジメントは成立するし、必要だと考えている。プログラムとは、組織が新しい能力を獲得して成長するために行う活動の仕組みである（英国MSPの定義）。つまり、組織としての成長への経路を、一歩一歩進んでいくのが、プログラム・マネジメントだ。だから、もしもプログラム・マネジメントを日本語で強引に表すなら、『成長行程管理』という言葉が適切かも知れないと、夢想するのだ。あるいは、『戦略行程管理』の方が受けるかな？<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
　→「プロジェクトにとって成功とは何か　～ESC Lille PM Seminarより」 https://brevis.exblog.jp/8567708/ （2008-09-05）<br />
　・・10年も前の記事ですが、今回の話の原点は、ここにあります。<br />
<br />
<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>PM理論に関する講演のお知らせ（12月8日）</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/26178825/" />
    <id>http://brevis.exblog.jp/26178825/</id>
    <issued>2017-11-16T22:10:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2017-11-16T22:10:24+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[来る12月8日(金)の夜、東京・東麻布の日本プロジェクトマネジメント協会で、講演を行います。<br />
<br />
<br />
先月、わたしは米国シカゴで開催されたProject Management Institute (PMI) Global Conference 2017に参加し、講演発表を行ってきました。ご存じの通りPMIは世界最大の影響力を持つプロジェクト・マネジメント専門職団体で、その世界大会はPM分野の最新状況を反映しています。<br />
<br />
<br />
今回の講演では、まずPMI世界大会2017にみる北米PM界の潮流を概観します。その上で、わたしが行った発表『Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions』（「リスク基準プロジェクト価値RPVとアクティビティの貢献価値に基づく意思決定」）の内容を、そのままご説明します。<br />
<br />
<br />
リスク基準プロジェクト価値（RPV）は、わたしが提案した意思決定のための尺度で、文字通りリスクを勘案したプロジェクトの価値を数字で表したものです。これを用いると、プロジェクトを構成する各アクティビティの貢献が計算できるばかりでなく、コスト対リスクといったトレードオフ状況下における意思決定を、客観的にサポートする基準を導出することができます。<br />
<br />
<br />
このRPV理論は、わたしが自分の学位論文の中ではじめて提案し、研究・発展させてきたものです。理論的な内容のため、これまでは学会論文誌や大学講義、ならびに海外でのみ、発表してきました。今回、はじめて普通の民間の場を借りて、お話しする機会をいただきました。そこで具体的なケース事例を交えて、できるだけ分かりやすく解説させていただくつもりです。<br />
<br />
<br />
この講演は、どなたでも参加できます。大勢の方のご来聴をお待ちしております。<br />
<br />
<br />
＜記＞<br />
<br />
<br />
日時：12月8日(金)　18:00〜<br />
<br />
<br />
場所：日本プロジェクトマネジメント協会　「PMAJ Networking」<br />
　　　〒106-0044  東京都港区東麻布一丁目5番2号  トウセン東麻布ビル7階<br />
<br />
<br />
講演タイトル：<br />
「PMへのシステムズ・アプローチと、『リスク基準プロジェクト価値（RPV）』理論の応用」<br />
<br />
<br />
要旨：<br />
　モダンPMの手法は、1950年代の米国で、プロジェクトを『アクティビティのネットワークからなる一種のシステム』と認識した事にはじまる。以来、PERT/CPM、WBS、EVMSなどの定量的技法が開発され普及してきた。しかし今日のPM論の枠組みには、まだ意思決定に資する価値論が欠けているように思われる。演者は数年前から、『リスク基準プロジェクト価値（RPV）』という指標を用いた、独自の理論的枠組みを研究してきた。本講演では、10月末に米国シカゴのPMI世界大会に発表した内容を中心に、ケース事例への応用と今後の課題について展望する。<br />
<br />
<br />
講師プロフィール：<br />
　日揮株式会社・グローバル戦略室長代行。博士（工学）。中小企業診断士。<br />
　ながらく国内外の製造業のプラント計画、生産システム構築と、プロジェクト・マネジメントに従事。現在は経営企画部門で戦略立案に携わる。<br />
　そのかたわら、近年はプロジェクト・マネジメント手法の改善・体系化と教育に力を注ぎ、「リスク確率に基づいた新しいプロジェクト・マネジメント」の研究開発にも取り組んでいる。<br />
　静岡大学客員教授、東京大学・法政大学非常勤講師。<br />
<br />
<br />
参加申込みは、以下のURLからお願いします。<br />
     http://www.pmaj.or.jp/activity/pm_networking_5.html<br />
<br />
<br />
<br />
<br />
佐藤知一@日揮（株）<br />
<br />
<br />
]]></content>
  </entry>
  <entry>
    <title>お知らせ：PMIのPodcastでわたしのインタビューが公開されました</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/24298893/" />
    <id>http://brevis.exblog.jp/24298893/</id>
    <issued>2016-04-13T07:20:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2016-04-13T07:18:54+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[お知らせです。<br />
<br />
米国PMI（Project Management Institute）のPodcastシリーズ「PM Points of View Podcast: Advances In PM II - Beyond the PMBOK®」の最新の回で、わたしがインタビューを受けて話しています。内容は、わたしの博士論文のテーマである『リスク基準プロジェクト価値』（Risk-based Project Value）のイントロダクション的紹介です。<br />
<br />
Podcastは、iTunesで“PMIWDC”で検索するか、あるいは下記のURLから入手可能です<br />
https://www.pmiwdc.org/pm-pov/2016/04/advances-in-pm-part-2<br />
<br />
このシリーズは、PMIのワシントンDC支部のKendall Lott氏が中心になって作成しているもので、PMOBK Guide® の枠を超えて最新のPM理論や手法を紹介するものです。PMIはいうまでもなく、全世界で40万人以上の会員を擁する、世界最大のプロジェクト・マネージャーの団体です。<br />
<br />
この回では、わたし以外に、<br />
Mike Hannan : 「the lean, single tasking PM」について<br />
Joe Sopko :  「Managing Successful Programs (MSP)」のアプローチについて<br />
のお二人のインタビューによる解説が含まれています。どちらも非常に興味深いものです。<br />
<br />
わたしの部分は18分弱、全体で約1時間で、これを聴くことによって1 PDUが取得できます（登録方法についてはPodcastの中で説明しています）。<br />
<br />
下打合せなしで、いきなりのSkypeインタビューだったため、たどたどしい英語でしゃべっていますが（ちょっと言い訳^^;）、わたしがお伝えしたいエッセンスが見事な編集によってくくり出されています。BGMの使い方もえらくカッコいい。他の二人の内容も素晴らしいので、最新のPMの進歩について関心を持つ方々に、おすすめします。無料です。]]></content>
  </entry>
  <entry>
    <title>クリスマス・メッセージ：平和のレジリエンシー</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/23978191/" />
    <id>http://brevis.exblog.jp/23978191/</id>
    <issued>2015-12-20T13:59:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2015-12-20T13:58:43+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[Merry Christmas !!<br />
<br />
<br />
以前、社内のPMO（Project Management Office）にいた頃は、毎月、社内のプロジェクト・マネージャーから上がってくるPMレポートをレビューするのが仕事の一部だった。レポートは形式が決まっており、最初にナラティブな文章による状況報告がある。それからスケジュール・進捗・リスクなど各種の計量的なステータスがついている。<br />
<br />
このレポートは本来、プロマネが、自分の後見人であるプロジェクト・スポンサーを経由して、経営層に提出するものだ。そして上の人は助言をつけて返す。だが同時に、ラインの横にいるPMOにも配布し、PMOがレビュー・コメントを行う。その目的は、縦のレポーティング・ラインだけでは見逃されそうな予兆や問題点をウォッチするとともに、別のプロジェクトで発生している問題点などをプロマネにフィードバックして、対応策を社内的に共有・横展開することにある。さらに、社内のプロジェクトに関する実績データをPMOが集積する目的もある。同じようなことは、わたしの業界内では広く行われている。<br />
<br />
ところで、PMOとしてレポートを読んでいるうちに、気がついたことがある。それは、プロジェクトは二種類に分かれやすい、ということだ。どんどん良くなっていくプロジェクトと、だんだん悪くなっていくプロジェクトである。いい方のレポートを読むと、前々月は設計でこういう進展があった、前月はこうして問題を事前に防止できた、今月はサプライヤーにうまく発注できて予算を抑えられた、という具合に、毎月明るいニュースが並ぶ。一方、まずい方のレポートは逆である。前々月は、こういう障害で設計が進まなかった、前月は思いもかけぬ問題が発生し対応に追われた、今月は発注先からのクレームで赤字がさらに膨らんだ、という具合で、毎月、読むたびにため息が出る。<br />
<br />
不思議なのは、良くなったり悪くなったり、というレポートがあまり無いことだ。前々月はよかった、でも前月はまずいことになった、今月はまた良くなった、といった風にアップ・ダウンのあるプロジェクトには、滅多にお目にかからない。これは一体、どういう訳だろうか？<br />
<br />
ひとつには、レポーティングに関する心理的態度というものも、関係するかもしれない。プロマネだって皆、会社員だ。普通は、なるべく良いことだけを上に報告したい。そうすれば上の覚えもめでたく、自己の評価も上がるだろう。だからしばらく良いレポートが続く。しかし、プロジェクトの途中で次第にトラブルが大きくなり、やがて増員などの面で、上の支援を仰ぐ必要が出てくる場合がある。危険性をアピールしないと本気にされない。そこからは問題レポートが続く、と。<br />
<br />
だが、PMOは文章だけでなく、計数的な部分もチェックしている。そして他の類似プロジェクトの実績値や、社内的な標準数値とも比較し、おかしなことが起きていないか見ている。最初の楽観的な文章と、後半の数値に齟齬があれば、PMOとして先に矛盾に気づく。自分も、そう心がけて仕事をしてきた。だとしたら、プロマネの心理的態度以外に、何か理由があるはずだ。<br />
<br />
わたしが次第に持つようになったのは、「プロジェクトのダイナミクス（動力学）は、本質的に不安定なものだ」という仮説だ。プロジェクトはある目標を目指して進められる、活動の総体である。納期や予算、スコープ（責任範囲）といった制約条件の中で、それを進めなければならない。そしてプロジェクトを構成する設計とか調達とかテストだとかいった活動（Activity）は、互いに連鎖し関連し合っている。つまり、プロジェクトというのは一種の動的システムであり、それを制御するのがプロマネの仕事だ。<br />
<br />
プロマネがきちんと計画を立案し、上手にチームをコントロールしていれば、諸活動はほぼ予定通り進んでいくだろう。ところが、人間はすべてのことは予期できない。予期せぬ問題が一部の活動で発生した際、それをうまく抑え込めないと、関連する活動間の調和を壊してしまう。するとその影響は伝播し拡大していって、さらに大きな問題となっていく。<br />
<br />
たとえばボールを凹んだ谷間の底に置いたとしよう。多少の外乱があってボールの位置がずれても、ボールはまた元の位置に戻っていく。これを「安定」な状態と呼ぶ。ところがボールを山の頂上に置くと、外乱でボールが左右どちらかに揺れた場合、元には戻らずに、左右どちらかの方向に加速度的に転げ落ちていく。<br />
<center><img src="https://pds.exblog.jp/pds/1/201512/20/47/e0058447_13335979.gif" alt="_e0058447_13335979.gif" class="IMAGE_MID" height="248" width="500" /></center><br />
プロジェクトとは、山頂に置いたボールのように不安定な存在だ、というのがわたしの仮説だった。ただし、まったくの不安定なシステムかというと、そうではない。ある程度の外乱の範囲内ならば、プロマネは乗り切っていける。そのときにカギとなるのが、予算でいえば予備費の存在、スケジュールでいえばバッファー（フロート日数）、さらに余裕ある遊撃手的な配員の存在だ。専門用語でいえば、Contingency Reserveである。<br />
<br />
予見しなかった問題が発生したとき、担当者やプロマネは、自分が持っている予備費やバッファー日数の範囲内で、遊撃手を動かして対応策をとることができる。いや、むしろ予算や時間に余裕があるときは、問題が起きる前に、予防的対策が打てるのだ。こうして、プロジェクトは良い方向に進んでいく。<br />
<br />
だが、外乱があまりにも大きかったとき、あるいは、出発時の制約条件がきつすぎて、プロマネの持つ予備費やバッファー日数や配員があまりに乏しいときは、発生した問題を抑え込めなくなる。そうすると負の連鎖反応が起きて、プロジェクトはもっと大きなトラブルに直面することになる。<br />
<br />
プロジェクトでは必ず問題が発生する、というのが長年このビジネスに関わってきたわたしの実感だ。どんなに最善の計画を立てても、思いもよらぬ外乱（あるいは、ミスなどの内発的問題）が発生する。これを乗りこえていくためには、なんらかの余裕・あそびが必要である。そして余裕に比べて外乱があまりに大きいと、コントロール可能な範囲を超えていって、プロジェクト全体が制御不能になる。ただ惰性で前に進むだけの存在になってしまう。ちょうど、金属製のバネのようなものだ。バネを引っ張ると、弾性の力で元に戻る。しかし、材料の「降伏点」を超える力をかけると、バネはぐにゃりと延びきってしまって、もう元には戻れなくなる。<br />
<br />
『レジリエンシー』という新しい言葉をあちこちで見かけるようになったのは、この数年のことだ。Resiliencyという英単語は翻訳しにくいが、「復元力」とか「抵抗力」みたいな意味を持つ。3.11の恐ろしい災害で東日本のサプライチェーンが寸断され、それが国内産業全体に少なからぬ影響を及ぼして以来、この概念が注目されるようになった。<br />
<br />
以前、統計数理研究所の丸山宏副所長によるレジリエンシー研究の講演を、自分の主宰する研究部会できかせていただいたところによると、<br />
「レジリエンシー ＝ Resistance（事前対策） ＋ Recovery（事後対策）」<br />
といった理解になるらしい。<br />
<br />
＜関連エントリ＞<br />
　→「稀な危機 vs ありふれた失敗－リスク対策の優先順位を考える」　（2013-10-14）<br />
<br />
トラブル事象が小さい内は、Resistance（事前対策）の方が費用が小さくすむが、あまりに大きな「想定外」のトラブル事象に対しては、もうRecovery（事後対策）を考える方が経済的である、というのが丸山博士の説明であった。それならば、どこかで最適な組み合わせがあるはずだ、との予測が成り立つ。<br />
<br />
その最適な組み合わせや、プロジェクトの「降伏点」は、プロマネが持っている予備費やバッファー日数などのContingency reserveから導き出せるのではないか、ということを当時は思った。<br />
<br />
しかし、その後わたしの考え方は、少しかわった。まず、プロジェクトの降伏点というのも、一点ではなく、多段階あるのではないか。いったんは大きく乱れても、また何とか復元する力が働くときもある。<br />
<br />
もう一つ。いったんはトラブルを経験しても、そのことが「人材が育つ」結果をもたらす事もあるのだ。むろん、それは程度にもよるだろう。だが、まったく問題を経験せずに、温室栽培か無菌培養のような環境下で育つより、ある程度の問題に否が応でも巻き込まれ、立ち向かった経験の方が、はるかに人は成長するのだ。むろん、トラブルが過酷すぎて、人をつぶしてしまうこともあり得る。ただ、そうした「人材の降伏点」は、決してその人が持つ資金だの時間だのといった、機械的なファクターだけで決まるのではない。<br />
<br />
では、何で決まるのか。それは、その人の持つマインドセットであり、また、その人を支えて協力する周囲の態度やマインドセットでもある。その周囲がちゃんとしていれば、問題経験はむしろ、人を育てるのだ。<br />
<br />
野口整体の創始者である野口晴哉氏は、「健康とは、風邪を引かないとか、病気にかからないことではない。健康とは、病気になってもちゃんと回復する力を身体がもっていることである」という意味のことを、たしか名著「風邪の効用」で書いていたと記憶する。この発言も、最初読んだときにはよく分からなかった。しかし、この頃、もしかしたら野口晴哉という人は、「健康」を、無病という静的な状態ではなく、「身体のレジリエンシー」という動的な感覚でとらえていたのかもしれないな、と思うようになった。<br />
<br />
プロジェクトというのは、人間がやる営為である。プロジェクトには確かに、費用や時間や生産性など、計数管理できる・計数管理すべきテクニカルな尺度がいろいろある。そして計画し事前対策できる範囲が大きい。だが、それと同時に、問題が起きたときに乗りこえていく力、火が吹いても消火していく能力として、やる人たちの目的意識がそろっていること、感情がメンバー間で共感されていること、などの面も大きい。テクニカルとマインドセットは車の両輪である。どちらが欠けていても、人々が一緒にやる仕事はうまくいかない。<br />
<br />
そして、日々の仕事から目を外に向けていくと、戦闘状態の続く西アジアでも、その他の地域でも、わたし達の社会はいろいろな問題によって挑戦を受けていることに気がつく。人々が争わず、お互いに事を荒立てずに暮らせれば、一番いい。しかし、たとえ一度は対立し火が噴いたとしても、それを短期間のうちに鎮火し、お互いに解決できる仕組みと能力を持つことの方が、ずっと現実的で重要だ。それはもちろん、兵器の数だとか予算だとかいった、テクニカルな尺度だけで測ることはできない。喧嘩をしても冷静に戻る能力、お互いの目標と感情を共感できる仕組み、が必要なのだ。<br />
<br />
たとえトラブルに巻き込まれても、人間がそこから学んで成長できると期待し、信頼を置くこと。難しいことだが、こうした態度をつちかうことこそ、世界がひととき静かになるこの季節、平和のレジリエンシーを高めるために、わたし達一人ひとりに求められることではないだろうか。]]></content>
  </entry>
  <entry>
    <title>お知らせ：雑誌「リスクマネジメントTODAY」に新国立競技場問題の記事を執筆しました</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/23824908/" />
    <id>http://brevis.exblog.jp/23824908/</id>
    <issued>2015-10-31T10:33:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2015-10-31T10:32:01+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[財団法人リスクマネジメント協会の発行する月刊誌「リスクマネジメントTODAY」 11月号に、<br />
<br />
　『プログラムマネジメントで競技場問題の混乱を解く　～ ロンドンにあって東京になかった成功要件』<br />
<br />
という記事を執筆しました。<br />
<br />
新国立競技場の建設プロジェクトは周知の通り迷走を続けた後に、リセットとなった訳です。<br />
この問題に対し、第三者委員会の検証報告書など公表された情報を元に、わたしがプロジェクト・アナリストとして分析した論文です。ロンドン・オリンピックにおける英国政府の取り組みなどと比較しつつ、この問題の根幹には、じつはプロジェクト・マネジメントの上位概念であるプログラム・マネジメントの不在がある、ということを論証します。<br />
<br />
ご注目ください。]]></content>
  </entry>
  <entry>
    <title>『プロジェクト・アナリスト』はなぜ必要か</title>
    <link rel="alternate" type="text/html" href="http://brevis.exblog.jp/22637237/" />
    <id>http://brevis.exblog.jp/22637237/</id>
    <issued>2014-12-09T22:48:00+09:00</issued>
    <modified>2025-12-31T11:05:38+09:00</modified>
    <created>2014-12-09T22:48:16+09:00</created>
    <author><name>Tomoichi_Sato</name></author>
    <dc:subject>B5 プロジェクトの価値とリスク</dc:subject>
    <content type="html"><![CDATA[わたしが「プロジェクト＆プログラム・アナリシス研究部会」を立ち上げたのは、3年半ほど前のことだ。2011年の5月、まだ東日本大震災と原発事故の余波がさめやらぬ頃で、毎日、小さな余震におびえ、計画停電という名の不便を皆が強いられていたときだった。スケジューリング学会会長（当時）の八巻・静岡大教授と、慶応大学の松川教授のご支援をいただいて、隔月に慶応三田キャンパスで勉強会を開く、今のようなスタイルに落ち着いたのはその年の秋頃だったと記憶する。第1回目は、発起人として、「リスク確率にもとづくプロジェクト評価と合理的意志決定の基準」という基調講演をした。内容は、その前年に出した自分の学位論文が中心で、数式だらけのOR的研究だが、なぜこんな研究部会が必要なのか、どうして長ったらしくて聞き慣れない会の名称をつけたのか、についても触れている。<br />
<br />
それは、『プロジェクト・アナリスト』という職種の確立が必要で、そのためにはプロジェクト価値分析手法の研究が喫緊の課題だと信じたからだ。<br />
<br />
設立趣意書には研究部会の目的として、次の三つの項目を挙げた：<br />
・プロジェクトと、その上位概念であるプログラムの、価値・スケジュール・リスクなどの客観的分析と評価手法を工学的に確立する<br />
・これにより、組織におけるプロジェクト／プログラムの意思決定に資するとともに、「プロジェクト・アナリスト」の専門職域を新たに構想する<br />
・現実のプロジェクト／プログラムの事例検討を行う。それを可能にするクローズドな場をつくる<br />
<br />
3年たった今、研究部会の活動を通して、これら目的の実現に少しでも近づいたかというと心許ないが、目指しているものは間違っていないと、今でも思う。プロジェクトには、第三者としての専門家であるアナリストが必要である。プロジェクトの上位概念であるプログラムにも、しかり。アナリストの仕事は、プロジェクトやプログラムの計画や遂行状況を客観的に分析し、その価値とリスクを評価し、進めるなり止めるなり（あるいは強化するなり）の提案をマネージャーおよび経営者層に対して、行うことだ。<br />
<br />
なぜ、第三者が必要なのか？　経営者と、プロジェクト実行の当事者であるプロマネがいれば、意思決定には十分ではないか。プロマネ以上に、そのプロジェクトの全体像について詳しく理解しているものがいるだろうか。経営者以上に、その組織における判断に適任な者がいるだろうか。だとしたら、なぜ、知識においてはプロマネに劣り、判断において経営者を超えられぬ第三者をつれてこなければならないのか。そう、思う人も多いだろう。<br />
<br />
その理由は、「プロジェクトは賭けである」からだ。大きな労力と、費用と、時間とを投資した賭け。それをやりぬくには、夢とパッションが必要だ。だから良きプロマネは、例外なしに情熱の人である。かりに見かけはクールで冷静でも、内なる確信と熱意を秘めている。そういう人でないと、大きなプロジェクトは、やり通せない。つまり、プロマネとは職業的楽天家であるということだ。<br />
<br />
そして『賭け』である以上、失敗するリスクもある。誰もが絶対成功するなら、それは賭けとは言わぬ。先の見えている、ただの日常業務に過ぎない。十分に見通せないから、リスクがある。<br />
<br />
リスクのある使命に、楽天家であることを職業的に義務づけられている人が任命されたら、どうなるか。答えは簡単である。「何とかやり抜きます」という発言だけが、かえってくる。「この仕事はやる意味がありません。止めさせてください」とは、口が裂けても、いえない。それはギブアップ宣言だからだ。つまりプロジェクト・マネージャーとは、自分で決して仕事を止められない職業なのだ。<br />
<br />
止める・止めないといった大げさな話でなくても、同じだ。プロジェクトがある段階まで進んだとしよう。いつ、その仕事は完成するのか。完成したときにコストは予定内に納まるのか。そう、経営者が問いかけたら、情熱を持ち自信家のプロマネほど、楽天的な答えを返す。大丈夫です、今はちょっと遅れているけれど、かならず予定通りに終わらせます。予算だって、きっとプラスにして見せます−−。もし同僚が、前の類似プロジェクトではこれこれのトラブルがあったから、同種のリスクに気をつけた方がいい、と進言したとしても、プロマネはこう言い切るだろう：「自分だったら、そんなドジは踏まない。」<br />
<br />
これが、有能で責任感の強いプロマネ達の危険性なのだ。彼らの元では、プロジェクトの問題は最後の段階にならないと表に出ない。能力の低いプロマネが、プロジェクトをひどい状況に陥れている場合、危険は誰の目にも見えて明らかだ。一日も早く交代させて、プロジェクトを立て直すか、いっそ中止させるべきだと、皆が思う。だが優秀なプロマネが多いほど、組織は大きなリスクという爆弾を抱え込むことになる。リスクの一部は押さえ込んでくれるかもしれぬ。だが全部は無理だろう。<br />
<br />
うまくいっていないプロマネを交代させ、意義の薄いプロジェクトをキャンセルするのは、本来、プロジェクトの上位に位置するプログラム・マネージャーの仕事だ。もし、そういう人が組織にいるならば、だが。しかしまあ、わたしの知る限り、ほとんどの日本企業には、そんな役職者はいない。民間企業のみならず、政府官庁にも地方公共団体に外郭団体にも、まず、いない。<br />
<br />
その結果、何が起こるのか。わたし達はもうそれを十分知っている。誰も使わぬ空港、誰も通らぬ高速道路が、それだ。民間企業の中にも、作ったが使われぬ情報システム、開発したが売れない新製品などがごろごろしている。それに投資したお金も労力も、まったくリターンを生まない。お金の使い方には、「生きた使い方」と「死んだ使い方」があるが、こうした失敗プロジェクトは明らかに後者である。後には借金が残るだけだ。<br />
<br />
だから、第三者による冷静なプロジェクト評価が必要なのである。そのための専門家を、企業も、官庁も、社会も、必要としているのではないか。<br />
<br />
わたしの働くエンジニアリング業界では、プロジェクト・マネージャー（PM）以外に、チームの中にプロジェクト・コントロール・マネージャー（PCM）という職種を置く。PCMはプロマネを補佐する立場で、プロジェクトの三大要素：コストとスケジュールとスコープについて、ベースライン計画を作成し、進捗と出費を集計し、予実管理を行う職種だ。通常、経営者に対する報告は、全体の責任者であるプロマネが行う。<br />
<br />
ところで欧米企業の中には、このPCMが直接、プロマネとは別に、経営者に報告をあげるシステムをとっているところがある。つまり、プロマネとPCMから、二重に報告を受ける訳だ。なぜこんな仕組みを作るのか。それは、計量管理の専門家であるPCMに、プロマネの情熱や主観のバイアスをはずした、客観的な状況報告をしてもらうためだ。こうして経営者は複眼でプロジェクトを見るのである。<br />
<br />
複数の視点から立体的に物事を見る。これは”Structured Approach”と呼ばれる態度の一例であり、欧米人はこのアプローチにたけている。とくにイギリス人は、客観的な第三者をつかってチェックするのが好きだ。一種の三角測量であろう（人によっては、いや、あれは英国文化の根強い人間不信が生み出した悪弊である、と主張するかもしれないが）。<br />
<br />
ただし、プラント業界におけるPCMには、欠けている面がある。それは、プロジェクトのコストは集計するが、ベネフィットは評価しない、という点である。今作っているプラントが、完成後、誰にとってどのようなベネフィットを生み出すのかは、PCMの職務範囲の外だ。だが、コスト（費用）を見てベネフィット（便益・効果）を見ないのでは、結局、経営判断において半面が抜けてしまうではないか。プロジェクトは賭けであり、投資である。だったら、投下費用に対するリターンがあって、はじめてその価値が測れるはずだ。<br />
<br />
念のために書いておくが、ベネフィットとは、プロフィット（利益）ではない。長年、受注型ビジネスの世界にいると、この両者の区別が分からなくなってしまいがちだが、それは最終ユーザーの視点を忘れてしまうからだろう。プロジェクトは、何らかの施設や仕組みを作るために実行される。もう少し抽象化した言い方をすると、プロジェクトは、組織がなんらかの『能力』を得るために行うのである。工場ならば生産能力を得る。新製品ならば、市場開拓能力を得る。ベネフィットとは、こうして得られた能力の価値を表している。<br />
<br />
では、通行料を取らない、普通の橋をかけるベネフィットは？　無料なのだから、何も価値を生み出さないではないか？　−−そんなことはない。交通工学によれば、地域間を行き来する交通量（トリップ数）は時間距離の2乗に反比例して増大する。橋ができて近くなれば、交通が増え、それは経済活動や通勤・通学などの社会的便益を生み出す。そしてそれは、きちんと計算できるのである。<br />
<br />
もちろん、プロジェクトの便益は、そうした金銭で換算可能なものばかりではない。プロジェクトを通して得られる経験値とか、人材の成長とか、無形の便益もいろいろある。それら便益を総合し、投下する費用・時間との対比を通じて、プロジェクトの価値が評価できるのである。そして、このようなプロジェクト価値評価を客観的に行う専門職として、『プロジェクト・アナリスト』が望まれるのだ。<br />
<br />
ところが、現在のプロジェクト・マネジメント学には、この価値評価理論が欠けている。せいぜいあるのは、金融工学におけるDCF法によるNPV・IRRとか、さらにCAPM理論やリアル・オプション理論だが、あいにくプロジェクトのダイナミクス（動力学）や内部構造までは、切り込む力が弱い。そもそも、金銭面しか測れない。だから、プロジェクト価値評価の研究が必要であり、それがために研究部会を立ち上げたのである。<br />
<br />
以前も書いたとおり、プロジェクトの成功を、「スコープ・コスト・スケジュールを満足させたか」だけで測ることに、わたしは基本的に賛成しない。それは成功の一部でしかない。本当の成功というのは、「プロジェクトが大きな価値を生み出すこと」であるはずであり、プロジェクト・マネジメントの仕事とは、「プロジェクト価値を最大化すること」でなければなるまい。プロジェクト・アナリストの仕事は、それを助けることなのである。プロマネの仕事を経営者の仕事にたとえると、プロジェクト・アナリストの仕事は証券業界のアナリストにたとえられる。自分でチームを統率し実行するのとは、別種の能力がそこには求められる。<br />
<br />
今、わたし達の社会は、経済の低成長に悩んでいる。GDPを押し上げるには、国内投資が必要である。民間企業が国内に投資しないので、公共投資がそれを引っ張るべきだという議論がある。経済成長とは、お金が貯まることではなく、お金が回ることだからだ。だが投資には、生きたお金の使い方と、死んだ使い方がある。車の通わない橋、旅客の来ない空港をいくら作っても、そんなプロジェクトには「価値がない」。しかし、現在の経済理論は、その区別を無視しているように思える。あるいは、うまく区別できずにいる。<br />
<br />
わたし達の社会が、投資を有効に行うためにも、プロジェクト・アナリストの職域確立が急務だと、わたしには思えるのである。<br />
<br />
<br />
＜関連エントリ＞<br />
　→「プロジェクト・マネジメントの理論は科学たり得るのか　〜　EDEN PM Seminarに参加して」（2014-09-14）]]></content>
  </entry>
  <supplier>
    <url>
      <excite>https://www.excite.co.jp/</excite>
      <exblog>https://www.exblog.jp/</exblog>
      <idcenter>https://ssl2.excite.co.jp/</idcenter>
    </url>
  </supplier>
</feed>
