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

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

• 最新講義
  • 進捗率にはいろいろな定義が可能である （2012/03/04）
• プロジェクト・マネジメント
  • プロジェクト制の要件
  • プロジェクト・マネジメントとはどういう仕事か
  • センス、キャリア、資格　―　マネジメント能力を左右するのはどれか
  • プロジェクトにとって成功とは何か　〜ESC Lille PM Seminarより
  • PMO（プロジェクト・マネジメント・オフィス）の命運　〜ESC Lille PM Seminarより(2)
  • プロジェクトにおけるタスクの価値を計算する
  • プロジェクト貢献価値の理論
  • プロジェクト・マネジメントは組織としての能力である
  • プロジェクト・マネジメントにリーダーシップ論は要らない
  • プロマネのハードスキルとソフトスキル
  • プロジェクト・コミュニケーションに必要な３つの能力
  • サービス、『感情労働』、そしてプロジェクト・マネジメント
• プロジェクト・スケジューリングd
  • 生産スケジューリングとプロジェクト・スケジューリングの違い
  • プロジェクト・タイム・マネジメントのベーシック
  • Excelで工程表を書いてはいけない
  • マイルストーンは中点で測れ
  • ＷＢＳのつくり方
  • 良いＷＢＳ、わるいＷＢＳ
  • 仕事の最小単位−−アクティビティの構造を学ぶ
  • 仕事の最小単位（２）−−アクティビティのパフォーマンスを測る
  • アクティビティの問題を解決する二つの方法
  • なぜ、人を追加すると納期に遅れるのか？
  • 所要時間の見積り−−時間と期間の差
  • パフォーマンス基準時間の概念
  • ベーシックとしての時間分析
  • 期日つき督促の矛盾と『学生シンドローム』
  • 早期着手かジャストインタイムか
  • 時間のムダとり−−スケジュールのサバを切り捨てる
  • バッファー・マネジメントとは何か
  • 外注のスケジュール・コントロール
  • 予定と実績の間のミッシング・リンク
  • ロジック・ネットワーク・スケジュールとは何か
  • イナズマ線と二重線 -- 工程表のアップデーティングとは何か
  • StartとEnd -- タスク間の依存関係
  • 進捗率にはいろいろな定義が可能である
  • 進捗率の計算と図的表現法
  • 進捗を把握する３つの方法
  • 役割（Role）としてのプロジェクト・マネージャー
• プロジェクト・リスク・マネジメント
  • リスク・マネジメントは本当に可能か
  • リスクに対する新しいアプローチ
  • 「リスク」という言葉に伴う不確実性
  • 戦略的プロジェクトとリスク・プレミアムの原理
  • 営業活動という名前のプロジェクト　−　そのリスクとリターンを考える
  • マトリクス組織の情報セキュリティ
  • 契約なんかこわくない
  • 契約なんかこわくない（２）　契約を設計する
  • 契約なんかこわくない（３）　契約の論理の根底にあるもの
  • 「責任」には三つの意味がある
    

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

プロジェクト制の要件

ソフトブレーン（株）の会長・宋文洲氏はいつだったか、持論のプロセス・マネジメントに関連して、「プロセスは線路で、プロジェクトはそこを走る個別の電車である」と言われたことがあった。これはなかなか面白い喩えだと思う。プロセスはいったん路線を引いたら固定して変わらないが、プロジェクトは運転手も、乗せている客も毎回違う。行き先だって変わることもある。“だからプロセスの設計が重要なんだ”というのが宋さんの立論である。

しかし、これはある意味では例外的なケースだとも考えられる。通常の製造業においては、まず「プロジェクト」という仕組み自体が確立していない。製品開発や受注生産といった個別の『案件』は、たとえば

企画→設計→試作→生産技術→購買→製造→物流、

という複数の機能部門の中を、上流から下流に向けて流れていくケースがほとんどだ。言いかえれば、縦割り組織の中をバケツリレーのように受け渡されていくわけだ。普通の電車の運転手は終点まで変わらないが、縦割り組織のメーカーは、ひと駅ごとに運転手が交替する鉄道に似ている。

むろん、それでずっとうまく行っているならば、何の問題もない。しかし、製品開発や個別受注生産は、複数の機能部門が関わり合う、クロス・ファンクショナルな活動である。業容を拡大したり、短納期化を進める状況下で、複数の案件が並行して進むとき、ボトルネックの作業負荷を誰が調整するのだろうか？　部門を統括する上級マネジメントか？　しかし、個別の案件で設計と購買の鞘当てが起こるたびに、いちいち事業部長が介入して調整するわけにもいくまい。

たとえば、既存の部品を転用すれば、早くできるのは分かっているが、しかしオーバースペックで高いものにつく。今回用に注文し直せば安く上がるが、とうぜん手配に時間がかかる。製品出荷の早さ（納期）をとるか、製品コストを取るか。製品開発は常にトレード・オフに直面するものだ。決断には責任がともなう。誰がそのリスクをとるのか？

答えは明らかだ。プロジェクト・マネージャーが必要なのである。納期とコストの双方に最終的な責任をもつ、プロマネが判断すべきだろう。そして、そのためには、社内でまず『プロジェクト制』の確立が必須になる。バケツリレーがこんぐらがって、もう限界に達したな、と思ったら、それはプロジェクト制を導入すべき時期なのだ。

プロジェクト制、というと、なぜだかすぐ「社長直属プロジェクト」を想起する人が多い。しかし、ここではそんな、“社運を決する一大プロジェクト”だけを考えているのではない。始まりがあり、明確なゴールがあって、複数の部署の人間が協力して成し遂げなければならない仕事（しかも失敗の可能性もある仕事）は、「プロジェクト」として公式に扱おう、と決めるのだ。

プロジェクト制の要件はいくつかある。まず第一に、プロジェクト・マネージャーの指名である。プロマネに、品質・納期・予算（QCD）に関する最終的な権限と責任を与える（人事権までは与える必要はない）。

予算に責任を持つためには、プロジェクト予算体系を確立しなければならない。これを支える仕組みとして、プロジェクト番号制が望ましい。プロジェクト番号をキーとして、日報による社内人件費把握や、外部費用のプロジェクト別把握ができなければならない。

誰をプロジェクト・マネージャーに任命すべきかも、悩ましいところだろう。企画部門かもしれないし、設計部門かもしれないし、生産技術部門から出すのがいいかもしれない。タスクフォース（「工務店」型）組織か、マトリクス（「置屋」型）組織かによっても、答えは違う。だが、いずれにせよ、プロジェクト・マネジメントに関する基礎的なトレーニングは必須だろう。固有技術と、管理技術は違うからだ。この点を忘れると、プロジェクト制など、すぐに絵に描いた餅になってしまう。

スムーズな製品開発や個別受注生産にとって、「プロセス」は必要条件だが、十分条件ではないのだ。最後まで決定に責任を持つ「運転手」＝プロジェクト・マネージャーが望まれる

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

プロジェクト・マネジメントとはどういう仕事か （2008/04/22）

もうだいぶん前のことになるが、大学の後輩にあたる留学生から、会社訪問の希望があった。彼は東南アジアの出身で、良家の子弟である。いずれは国に帰って立派な職に就くのだろうが、しばらく日本企業でビジネス経験を積みたい、との希望らしい。ついては、私の勤務先の国際プロジェクト部門で働きたいという。

私の勤務先はエンジニアリング会社で、プロジェクト・マネジメントを専門に受け持つ部門がある（念のため書いておくがPMOとは別である）。その部門には、プロジェクト・マネージャー達や、プロマネの卵であるプロジェクト・エンジニア達が配属されており、国内外のプロジェクトを切り盛りしている。彼はそこで少しの間、仕事を学びたいというのだ。

で、どれくらいの期間を考えているの？　そうたずねたら、彼は「1年間です」という。私はため息をついて、答えた。「1年では短すぎる。5年とはいわないけれど、せめて3年くらい働いてくれないと、君も仕事を覚えられないし、会社の側も給与に応じたアウトプットを期待できないよ。」そう説明したが、彼は1年という希望をどうしても譲らない。20代前半の人間にとって、1年は永遠の半分くらい長い時間に思えるのだろうか。結局その話はお流れになった。

電話を切って、つくづく思った。“海外プロジェクトのマネジメント”という仕事を、彼はずいぶんかっこいい仕事だと想像しているのだろうな。私は今、この文章をまさに海外プロジェクト現場の宿舎で書いているが、実際のそれは、まさに交通整理と雑用の集積だ。ひどい渋滞の交差点の真ん中で、一日中、汗をかきかき腕を振り回す警官を見て、彼は“大勢のドライバーたちを指揮・指導するかっこいい仕事”と思うだろうか。

乗客や荷物を運ぶドライバー達は、たしかに何らかの付加価値創造に貢献している。しかし、コーディネーションを任務とする警官自身は、何物も作り出さないのだ。接触事故を処理し口げんかを仲裁し、ひどいときには自分で荷物を担いで運ぶ。本署にすわって若い交通警官達を采配している部長は、たしかにかっこいいマネージャーに見えるかもしれないが、仕事の本質は同じである。

私はプロジェクト・マネジメントという仕事を矮小化しすぎているだろうか？　IT業界では、国際標準としてPMBOK Guideの勉強と摂取が盛んだ。今から10年前には、「ぼくはプロジェクト・マネージャーなんかにされるのが嫌で、前の会社を辞めました。」という人がいたのだから、まあ隔世の感かもしれない。その人はシステム技術屋としての本分を捨てて、そんな雑用係にされるのはまっぴらごめん、と言っていたのだ。

ところで、この人の言う「雑用」と、わたしのいう「雑用」では、意味が少し違うことにお気づきだろうか？　わたしは、顧客への納品物製作という直接作業（価値創造）につながらないものを雑用と呼んでいるのに対し、この人は、自分の技術的興味や満足につながらない仕事を雑用と呼んだのだ。この人にとって、データベース設計書作成やコーディングは楽しい仕事で、マニュアル作りやテストや顧客への報告は雑用だ。しかし、わたしの定義では、コーディングとマニュアル制作こそが直接作業であって、設計書などは雑用なのだ。ただ、その設計書はコーディングやデバッグの生産性を上げるから、雑用でも必要なのである。

PMPの有資格者が２万人を超えようという今日では、プロジェクト・マネージャーは「かっこいい仕事」にいつの間にか昇格した。交通警官などとはとんでもない。むしろオーケストラの指揮者か、映画の監督にでもたとえられる職種と思われているようだ。

ところが、その映画の世界には、『助監督』という職種があって、これがまさに雑用係なのだ。クルーのロケの切符を手配したり、宿舎を予約したり、俳優たちの用事をきいたり、とにかく何でも屋である。多くの映画監督はこれを経験しており、キャリアパスの一種になっている。

助監督の任務の中には、会社で言えば「総務」みたいな種類の仕事がある。配車や掃除や機材運びなどの雑用である。この種の仕事を、『アドミニストレーション』とよぶ。

また、助監督の仕事の中には、スタッフ間の都合や意見を調整したり、主張がかみ合わない場合は“とりあえずA案で進めますけど、天候がダメな場合どうするかは任せてください”みたいに判断をあずかったりする役割がある。この種の仕事を、『コーディネーション』と呼ぶ。

そして、撮影予定をスケジューリングしたり予算と出費の勘定をしたりといった、表やリストで追いかけるのに適した雑用がある。これを『コントロール』と呼ぶ。

プロジェクト・マネージャーの仕事とは、すなわち『アドミニストレーション』・『コーディネーション』・『コントロール』の三つの領域を包含した、采配の仕事である。とくに『コントロール』は数字化しやすいので、PERT/CMPだのEVMSだのといった技術手法が発達している。これらは一般に“管理技術”とよばれるものだ。データベース設計だとか応力計算といった“固有技術”とは別の領域である。「技術的なこと以外は雑用」と考えるエンジニアは、じつは管理技術というものの存在を理解していないのである。

とはいえ、プロジェクトは人間の集団がすすめるものであって、プロマネの仕事の中核には“人を動かす”という行為がある。これは技術論だけでは、なかなかうまくいかない。そこで、もっと属人的な『ソフトスキル』が必要となるのだ。

プロジェクト・マネジメントとは、こういう仕事である。しかも映画とは違って、世間に名前の出るケースはまずまれだ。それでも、なかなか面白い。かの留学生君が実際にやってみたら、どういう感想をもっただろうかと、ときどき考えることがある。あなたはやってみたいですか？　

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

センス、キャリア、資格　―　マネジメント能力を左右するのはどれか （2011/11/26）

ある女声合唱の演奏会で、わたしの所属する男声アンサンブルが、2曲ほど手伝うことになった。相手はプロのソプラノ歌手が主宰し、指揮する女声合唱団である。本番の数週間前、相手方との打合せにいった。これまで別々に練習してきたが、本番までに何回か合同練習が必要だ。それに、演奏会当日の段取りも確認しなくてはならない。相談すべき事柄は多い。

打合せの席でお互いに自己紹介し、議題に入ると、相手方から資料数枚が配られた。その資料を見て、わたしは驚いた。当日までに準備しなければならないこと、当日の手順とタイムテーブル、担当すべき係と受け持つ人の名前、費用について、などがきちんとワープロで整理されて書かれている。そして、その資料を作った女性が説明をはじめた。「今日、決めておかなくてはならないことは、○○と○○と○○です」穏やかな口調だが、進め方はとてもてきぱきしている。じつに感心してしまった。

その打合せ資料は、演奏会に関わる仕事のスコープ・スケジュール・予算・そして体制がきちんとカバーされている。つまり、マネジメントの要点をすべておさえているのである。作成した女性は落ち着いた身なりの方だが、とくにばりばりのキャリアウーマンにも商売人にも見えない。主婦だろうか。「彼女は女性にしておくのはもったいないんです、こう言っちゃなんですけれど」と、主宰される声楽家の先生は笑いながら言われた。わたしはマネジメントが男性向きの仕事だとはべつに思わないけれど、生まれつきのマネジメント・センスってあるんだなあ、とあらためて感じた。

別のある日。とあるプロジェクトのキックオフ・ミーティングに顔を出した。チーム・メンバーとしてではなく、アドバイザーとして呼ばれたのだ。ソフトやハードを作るのではなく、どちらかといえば企画コンサルティングに近いプロジェクトであった。チーム・リーダーが前に出て資料を配付し、皆に説明する。本プロジェクトの背景と意義、めざすべきゴール、そしてトップや行政からの期待、等々。

しかし、わたしはがっかりしてしまった。キックオフの資料には、やるべきアクティビティも、全体のスケジュールも、概略予算も、遂行体制図も役割分担表も、何もないのだ。たしかに、ものづくり的なプロジェクトとちがって、明確なスコープを定めにくい、難しい仕事だ。だがこれでは、飛び上がったものの、どこに着地するかわからぬ飛行船のようではないか。リーダーは、立派な大学を優秀な成績で卒業し、以来、高度な技術分野でずっとキャリアを積んできた技術者だ。だがプロジェクト・マネジメントというものをどう考えているのか。疑問符が繰り返し頭の中にわいた。

さらに別のある日。とある協業相手の会社からメールがとんできた。半年足らずのプロジェクトの説明資料である。添付ファイルを開けてみると、10数ページにもわたる立派なプロジェクト・マネジメント計画書がついている。さらに末尾にWBSが添付されていた。その一部をあげると、こんな感じである：

　・・・　・・・　・・・
2.3 ソフトウェア詳細設計
　2.3.1 制御システム詳細設計
2.4 中核部品調達
　2.4.1 調達要求書（RFP）作成
　2.4.2 引き合い・発注
　2.4.3 サプライヤー承認図のレビュー
　・・・　・・・　・・・

一目見て、部下が言った。「ダメですね、こいつら。プロジェクトのこと何にもわかっちゃいない。素人ですよ。」わたしも、ためいきをついて、同意した。「うーん、困ったね。なんでもPMPの資格を持ってる人が計画を作ってると聞いたんだけど・・」

WBSのどこがダメか、おわかりと思う。2.3「ソフトウェア詳細設計」のサブ・アクティビティとして、2.3.1「制御システム詳細設計」がただ一つだけあげられている。ところで、WBSというのは、

　（親アクティビティのスコープ）＝Σ（全サブ・アクティビティのスコープ）

という形で分解すべきものである。これを『100%ルール』と呼ぶ人もいる（子ども全員で親を100%カバーしなくてはいけない）。そうしないと、コストや必要リソースを集計した時に、要素がどこかに消えてしまうからだ。

上記のWBSでは、「制御システム」は親の「ソフトウェア」のすべてをカバーしているわけではなさそうだ。注意すべき代表例が上げられているだけだろう。逆に、もし「ソフトウェア詳細設計」＝「制御システム詳細設計」だったら、そもそもbreakdownする必要がないのである。こうしたことは、WBS作成のイロハに属する。口さがない部下が「素人だ」と断じたのは、そのためであった。

（とはいえ、この程度のことさえ理解せずに、PMPの資格が取れてしまうとしたら、あの試験にはいささか問題があるということになる。名刺に「PMP」とれいれいしく刷っている身としても、これはやや困る）

それにしても、ここにあげた三つの例を考えてみると、マネジメントに一番役に立たないのは『資格』であり、次に役に立たないのは『学歴』『キャリア』で、一番役に立つのは、持って生まれた『センス』だということになりはしないか。だが、果たしてそれで良いのか？　本来は逆の順であるべきだろう。持って生まれたセンスを教育や仕事の経験が磨き、それを資格が保証する、というのがあるべき姿のはずだ。しかし多くの企業では、キャリアも資格も固有技術・知識として頭の表層に残るだけで、管理技術としてのマネジメントは「センス」のみで進められている、らしい。

最初の合唱団の例を思い出してほしい。指導する声楽家はリーダーである。そして、単に歌の練習を繰り返す間はそれだけで十分だった。でも、演奏会にはマネジメントの仕事が生じる。マネジメントは、何か新しいことに挑む時に、あるいは過去の繰り返しでは先がない時に、必要となるものだ。ちょうど新製品を作ったり、業務や組織を改革したりする時に。それ自体は、必ずしも華々しいものではないかもしれない（演奏会で脚光を浴びるのは指揮者やソリストだし、新製品で賞賛を受けるのはデザイナーだ）。でも、上手にやることが望まれる。そのマネジメントの仕事を、キャリアでも資格でもなく、皆が持って生まれたセンスだけでやっているのだとしたら　――　たしかにまあ、わたし達の社会が泥沼から脱出するのに時間がかかるのも無理のないことである。

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

プロジェクトにとって成功とは何か　〜ESC Lille PM Seminarより （2008/09/04）

8月17日から22日までの一週間、フランスのリールで開かれた"EDEN Project Management Seminar"に参加してきた。リールはベルギー国境に近い北フランスの古都で、フランドルの入口に位置する商業都市だ。そこに、Ecole Superieure de Commerce de Lille（略称ESC Lille）という、フランスでも有名なビジネススクールがある。ESC Lilleは、欧州におけるプロジェクト・マネジメント研究のメッカともいうべきセンターであり、そこで毎夏開催される"EDEN Project Management Seminar"は、実務家とアカデミックな研究者が各国から集い、最先端の研究報告や情報交換を行う場となっている。

私は今回、日本プロジェクトマネジメント協会理事長でESC Lille教授でもある田中弘氏のご紹介により参加招待を受け、最近の研究テーマであるRisk-based Project Value Analysisについて発表した（写真）。リスクの伴うプロジェクトにおいては最適予算が存在する、という講演内容は好評をもって迎えられたと一応感じたが、その話はまた別の機会にしよう。今回は、そのEDEN PM Seminarで聞いた内容の中でも、とくに面白かった講演をいくつか紹介したい。

ちなみに、世界のPM関連団体といえばProject Management Institute（PMI）が唯一最大で、標準といえば"PMBOK Guide"（A Guide to PM Project Management Body of Knowledge）第3版がグローバル・スタンダードであるかのように思っている人が、我が国（とくにIT業界）では多いようだ。しかし、このセミナーに集う人々の顔ぶれと意見を見れば、それは誤解であることがわかる。PMIは米国発の団体だが、欧州にはそれより古くからInternational Project Management Association（IPMA）が設立され活動している。そしてPMIの学術雑誌"Project Management Journal"の編集長Christoph Bredilletと、欧州を代表する論文誌"International Journal of Project Management"の編集長J. Rodney Turnerが、二人ともESC Lilleの教授であることを見れば、このセミナーの層の厚みが想像できるだろう。

前置きはこれくらいにして、まず、英Middlesex大学Darren Dalcher教授の"The Success School in Practice"という講演を紹介しよう。

元々実務家としてのキャリアをもつDalcher教授は、英国のプロジェクト・リスクマネジメント関係の諮問委員会のメンバーらしく、かかわった実例の中から、"プロジェクトにとって何が成功なのか"という根本の問題をあらためて問い直す。たとえば、彼自身が関わった２つのITプロジェクトで、Ａ：片方は納期も予算も守ったが、成果物はろくに利用されなかったケースと、Ｂ：納期も予算も超過したがシステムは13年間にわたり使い続けられるケースを紹介する。いったい、Ａ・Ｂどちらのプロジェクトが成功といえるのか？　

この問いは一見単純に見えるが、案外奥が深い。納期も予算も超過したら失敗だ、とプロマネなら答えるだろう。よく、「ITプロジェクトは７割が失敗といわれている」と語る人が多いが、実はこの数字は米国Standish Groupが発表している統計資料によっている。

その一方、顧客満足が最大価値であるから、システムを使ってもらった方が成功だ、と答える人もいる。経営論を学んだ人に多いような気がする。しかし、システム開発を受託する企業は慈善事業でなく、営利でビジネスを動かしているはずである。だとしたら、赤字を出して成功というのは、自社の経営戦略とマッチしないことになる（もっとも、ハード販売が利益の源泉でソフト構築は無償でも良い、というのが戦略なら別の話だが）。

さらにDalcher教授は、有名な英仏海峡のEuro Tunnel事業をとりあげる。大陸と英国を海底トンネルで結ぶこのプロジェクトは、予定の6倍の予算超過を引き起こした。旅客数は当初予想の1/3、いったんは倒産状態に陥る。巨額の借金棒引きにより、開通後14年後の今年になって、ようやく単年度黒に転じた事業である。彼は、これがプロジェクトとして成功か失敗かを問う。あなたの意見はいかがだろうか？

聴衆の意見はさまざまに割れた。納期やコストの点では明らかに失敗だ。ビジネスとしてもかなりの難点がある。トンネルは不法移民の移動手段にもなってしまった。しかし！　トンネルのおかげで、ロンドンと大陸は非常に近く、便利になった（何しろリールからロンドンまで列車に座っていけるのである）。英仏両国の記念碑的協力事業となった。また、難工事だったかもしれないが、あの海底トンネルは技術としては偉大な成果ではないか・・・。

結局その答えは、誰にとって、どのような尺度で測るかに依存する。プロジェクトは、遂行を請負うプロマネの視点、発注当事者の視点、利用者等のステークホルダの視点、そして事業を取り巻く社会の視点がある。これに応じて、成功には次の4レベルがある、というのがDulcherの定義である。

レベル1　Project Management Success：納期・コスト・品質（スコープ）が守れること
レベル2　Project Success：プロジェクトの成果物に価値が認められること
レベル3　Business Success：プロジェクトがビジネスの成功をもたらすこと
レベル4　Future Ptential：プロジェクトが将来への可能性を生み出すこと

ふつうプロジェクトの成功は階層的にレベルを上がっていくと考えられる。しかし、それは必ずしも必須条件ではない。というのは、小さいレベルでは失敗だが、上のレベルでは成功というケースもあるからだ。たとえば、最初の二つのプロジェクトの例では、Ｂはレベル1では失敗だが、レベル2では成功だったわけである。ユーロトンネルの場合は、レベル1〜3まではことごとく失敗であった。しかし、レベル4の視点に立てば、成功と呼ぶことができる。そして、米Standish Groupが発表している「プロジェクト成功率統計」は、レベル1の成功率を示しているにすぎないことが分かるだろう。

私自身、受託プロジェクトの遂行をビジネスとするエンジニアリング業界に身を置いているため、どうしてもレベル1の狭い視点に限られる傾向があったようだ。そうした意味で、本講義はまさに目を開かれた思いであった。読者諸賢も明日からは、“頑張ってプロジェクトを成功させろ！”と号令されたら、「誰にとっての、どのレベルでの成功ですか？」と問いかけるといいかもしれない。あるいは、レベル0（Activity Success）というのを考えてみるのも面白いだろう。各アクティビティの担当者は過労でボロボロになったのに（レベル0＝失敗）、プロマネは納期通り利益を上げて昇進・栄転した（レベル1＝成功）、という風に。

さて、この講演でも分かるように、欧州では、より広いコンテキストからプロジェクトをとらえる思考様式を持っている。また社会との調和を重視しようとする点も、欧州的思考の特徴だ。これに対して、一般に米国では、明確に決められた枠組みの中で、量的にはかりやすい尺度でビジネスや物事を評価したがる。だからStandish Groupのようにレベル1に着目するのだ。プロジェクトの成功の判定に、両者のスタンスの差がくっきりと出てくる点が面白い。

このように、EDEN Project Management Seminarでは、興味深い発表が他にもいくつもあった。今回は長くなってしまったので、それらについては、次回紹介しよう。

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

PMO（プロジェクト・マネジメント・オフィス）の命運　〜ESC Lille PM Seminarより(2)

前回に引き続き、8月にフランスのリール大学院ビジネススクール（ESC Lille）で行われたEDEN Project Management Seminarでの話題を紹介しよう。

ケベック・モントリオール大学のMonique Aubry教授が行った、"Making sense from PMOs through a multi-phases and multi-methods program of research" という研究発表はなかなか衝撃的だった。M. Aubryはカナダのベテラン研究者として学会では有名だが、何年かかけて継続的にPMO（Project Management Office）組織の実態調査を実践している。その結果の一部はすでにProject Management Journal（PMI発刊の学術誌）に発表されているが、それを概括した講演である。じつをいうと、私自身、昨年秋からエンジニアリング会社の中の一種のPMO組織に属することになり、その点でも興味深い話であった。

さて、Dr. Aubryによると、PMOという組織は2000年以降ポピュラーになり、さまざまな業種の企業・公共機関に生まれてきた。しかし、その機能や役割にはバラエティが多いという。そればかりでなく、数年間隔の調査の間に、目標や位置づけ、職務機能などが大きく変化するのが常であり、消滅している場合も多いという。彼女は、"PMOという組織はhigh mortality rate（高死亡率）であり、その平均寿命は2年程度である"と述べている。

この原因については、研究者らしく慎重な態度で「分析中」としている。が、PMO組織とは、プロジェクトに関するガバナンスの確立を共通使命としている。そのPMOが抱える、社内改革ならびにガバナンス確立という使命と、現実の組織がもつ変化への抵抗性の間の矛盾が原因であろうことは想像に難くない。PMO自体、永続的な組織ではなく、ガバナンス・システム構築という目標を達成したら解散すべきものだ、という考え方はあるだろう。しかし、わずか2年足らずでそのゴールを達成できる企業ばかりではないはずだ。

Seminarでは他にもPMO設立に関する事例研究発表があったが、PMOとは、作るのは易く、使命達成するのは難しい組織である、ということがうかがわれる。

もうひとつ、今度は日本人の発表をご紹介しよう。日本人と言っても、ギリシャの会社Consolidated Construction Company（CCC）の顧問をしておられる石倉氏の講演である。CCCは中東でも指折りの巨大建設工事会社だが、その立場から、中東における11のエンジニアリング・プロジェクトの現況を分析し、欧米コントラクターと日本コントラクターの違いを分析している（社名は明記されていないが、私の勤務先も明らかに含まれているようだ）。

評価軸は、建設マネジメントのパフォーマンス、設計・調達（E&P）のパフォーマンス、そして従業員満足度（Employee satisfaction）の3つの切り口で採点する。「顧客満足度」ではなく「従業員満足度」が入っている点が、いかにも多国籍建設会社である。多くの国から労働者を集めてプロジェクトを進めなくてはいけない企業にとって、従業員のパフォーマンスは死活問題だからである。

さて、石倉氏の調査によると、欧米コントラクターよりも日本のコントラクターのパフォーマンスには明瞭な差がある。むろんジョブ毎の差はあるが、3つの評価軸いずれでも日本は欧米を上回っており、とくにその差はE&Pのパフォーマンスで著しい（百点満点で日本75点vs.欧米59点）。"端的に言って、工事に必要なときに、必要なマテリアルと図面を供給できる能力の点で、大きな違いがある"という解説があった。

石倉氏はさらに、これをHackman & Oldhamのモチベーション・スコアリング手法を用いて分析し、現場に対してより大きなautonomy（権限委譲）とfeedback（発言力）を与えていることによるモチベーションの差があるのではないかと結論している。

ところで、すこし仏のセミナーで垣間見た、世界のPM標準化団体の動向について記しておこう。現在、世界のPM団体としては米国のProject Management Institute（PMI）が圧倒的な勢力を誇っており（会員数20万人以上）、またその標準書である"PMBOK Guide"（A Guide to PM Project Management Body of Knowledge）第3版が唯一のグローバル・スタンダードであるかのように、我が国（とくにIT業界）では受け取られている。

しかし、欧州やアジアでの情勢を見てみると、それは少し偏った理解である。例えば英国にはPRINCE2（PRojects IN Controlled Environments）という標準が'96年から存在しており、APM Groupが認定試験を実施している（今回のSeminarにはAlan Harpham会長が参加し講演している）。日本PM協会の田中理事長の解説によると、PRINCE2は“PJは放っておけば失敗する性質のものである”という認識が根底にあるらしい。したがって、プロジェクトの状況に応じて適用すべき手法を決める、との考え方に立っている。この試験は英国以外でも実施されている。

また、欧州には国際団体International Project Management Association（IPMA、本部スイス）があり、欧州各国およびインド・中国・韓国などのプロジェクト・マネジメント団体が参加している。IPMAはICB（IPMA Competence Baseline）と呼ばれる、PM資格認定制度の水準を統一するためのコンピテンシー標準を制定・発行している。IPMAは国別の文化・風土を尊重し、各国が独自の要件を追加変更することを認めている。こうした点が、PMBOK Guideこそ万国共通のスタンダード、と考える米国PMIとのスタンスの違いであろう。

欧州のPM関係者は、米国に比べると、プロジェクトを広い視点（事業の将来価値や社会との関わり）から見るという特徴がある。PMIが最近、Program Managementの標準を制定したのも、これに対応する動きのように感じられる。

現在、ISOではISO 21500と呼ばれる新しい標準を制定するためにISO/PC 236というWGを立ち上げている。これは英国標準局(BS)の提案になるものだが、内容は上述PRINCE2とは別のものである。ただし実質的にはPMIがこの動きに先制して参加し、方向性を主導しつつある現状であるという。

いずれにせよ、プロジェクト・マネジメントの世界は標準化・手法・理論のいずれの面でも急速に動いている。今回のセミナーでは、日本からの参加者は私を含め３人だけだった。国内にいるだけでは分かりにくい、世界の潮流を肌に感じるためにも、もっと多くの人がこうした集まりに参加するべきだと私は信ずる。

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

プロジェクトにおけるタスクの価値を計算する （2006/11/18）

米国PMIがまとめたプロジェクト・マネジメント知識体系の標準"PMBOK Guide"の普及にともない、日本でも次第にアーンドバリュー管理システム（EVMS）が使われるようになってきた。進捗とコストを同時におさえながら、プロジェクトのコントロールをする上では、非常に有用なツールである。日本にも『出来高』という立派な言葉と概念があったのだが、それをマネジメントの技術として普遍化・活用できなかった。日本のビジネス文化の弱点かもしれないと思うと、ちょっとくやしい気もする。

ところで、EVMSが広まるにつれ、なんとなく進捗はアーンドバリューで測ればすべてOK、という理解も広まってしまったようだ。舶来の理論をそのまま鵜呑みにしたがる風潮も、またわれらが文化の弱点かもしれない。以前、「アーンドバリュー分析の落とし穴」（『コンサルタントの日誌から』2002/10/20）などにも書いたとおり、EVMSは用法を心得て使うべきであり、決して万能の手法ではない。

EVMSの最大の弱点は、じつは製品開発型のプロジェクトに適用しようとする際に、うきぼりになる。ためしに、きわめて単純な例を考えてみよう。いま、発明家（技術者）と実際家（セールスマン）が二人でガレージカンパニーをはじめようとしている。発明家は、20万円ほどの部品を組み合わせて、100万円相当の機械と同等の機能を持つ新装置を作れる画期的アイデアを考案した。実際家は、それができたら自分が買い手を捜してやろう、ともちかける。つまり、この二人の事業は、「製造」と「販売」の２タスクからなる、きわめてシンプルな製品開発プロジェクトである。

ただ、発明家が実際にその装置を組み上げられるかどうかは、まだフィフティ・フィフティの見込みだ。一方、セールスマンは、もしその装置ができあがれば、９割方は買い手を見つけられる自信がある。製造タスクのコストは20万円。販売タスクのコストは、まあ電話代や交通費が多少かかるだろうが、ほぼゼロとしよう。

さて、ここで問題である。いま、ぶじ発明家が装置を組み上げることに成功した。つまり第１の製造タスクは完了したわけだ。ではプロジェクトの現時点の進捗率はいくつか？　あなたはどう考えますか？

アーンドバリュー分析の立場から言うと、プロジェクトの進捗率とは、その時点までに完了したタスクの価値の合計を、全タスクの価値の総計（＝つまりプロジェクト全体予算）で割った数値である。では、この場合はいくつか。プロジェクト全体のコストは20万円だ。そして、完了したタスクのコストも20万円だった。したがって、最初のタスクしか終わっていないのに、進捗率は100%になってしまう！　はたしてこれで良いのだろうか？

はっきりしていることが一つある。それは“これでは働いている人間の実感にあわない”ということだ。実感に合わない尺度では、人をマネジメントすることはできまい。いや、問題は販売経費をゼロとしたことだ、と思う人もいるかもしれない。しかし、では販売経費をかりに千円としようか。そうしたら、進捗率は20÷20.1＝99.5%となる。少数以下を切り上げると100%だ。これではなんら解決になるまい。EVMSによる進捗計算を製品開発プロジェクトに無反省に適用すると、いかに問題かおわかりになっただろうか。

この問題の本質はどこにあるのか。それは、「タスクにかかる費用を『タスクの価値』と見なす」というアーンドバリュー分析で広く用いられる前提にある。これは言いかえれば、費用のかからないタスクは価値が低い、と考えていることになる。一般に知的作業は人件費のみだからコストが小さい。それにひきかえ製造や建設や量産はコストが大きい。つまり、力仕事の方が価値が高いと評価されるわけだ。EVMSはアメリカ国防省の調達プロジェクトにおいて発達したから、コスト基準でタスクの価値をはかる考えがしみついてしまっているようだ。

コスト基準がだめだとすると、“二人の協力によるプロジェクトなのだから、半分終わったら50%と考えよう”といった解決法もあろう。しかし、これはマネジメント理論による解決というより、政治的決着というべきだ。製造作業が２人がかりだったらどうするのか。セールスに５人かかったらどうか。声の大きいタスクの方が勝つような進捗率計算など、マネジメントシステムの役には立つまい。それでは、どうすべきだろうか。

答えだけ先に言おう。『貢献価値の理論』を用いれば、タスクの真の価値を計算することが実はできる。そして上記の例では、進捗率＝81.8%となるのだ。製品開発プロジェクトは、いや一般に全てのプロジェクトは、複数の人間が協力して、一度限りの目標を達成するための、リスクを伴う活動である。そこではリスク基準による貢献価値の理論が活きてくる。その考え方と具体的計算方法については、次回書こう。

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

プロジェクト貢献価値の理論

EVMSを製品開発型プロジェクトに単純に適用しようとすると、意外な困難に見舞われる。前回それを、単純なガレージカンパニーの例題で考えてみた。いま、発明家（技術者）と実際家（セールスマン）が協力し、まず発明家が20万円の材料費で100万円相当の新装置を製作する。成功確率はフィフティ・フィフティ。つぎに実際家が買い手を捜す。９割方の確率で成功するだろう。この、２タスクからなるシンプルな製品開発プロジェクトで、「製造」タスクが成功裏に完了したとき、進捗率はいくつと算定すべきだろうか？

通常のアーンドバリュー分析は、タスクのコストをその価値と考える。「販売」タスクのコストがほとんどゼロのため、このままでは進捗率＝100%という答えになってしまいそうだ。この困難を避けるためには、タスクのもつ真の『価値』を算定しないといけない。しかし、それでは真の価値とは、いったい何か？

ためしに、この問題をもっと単純化してみよう。タスクをたった一つ、「製造販売」にしてしまう。かかる費用は20万円。失敗するリスク確率は、100%−50%×90%＝100%−45%＝55%となる。もし、このプロジェクトがうまくいけば、収益は100万−20万＝80万円の価値を生み出す。

ところで、この単純化プロジェクトがはじまる時点では、まだ100万円の売上は確実ではない。売上の期待値は、100万×45%＝45万円にすぎない。一方、失敗しても部品代20万円は確実にかかる。したがって、プロジェクトの期待価値は、45万−20万＝25万円だったのである。言いかえると、この「製造販売」タスクの成功は、25万円のプロジェクト価値を、80万円の価値に増大させたわけだ。差し引き、80万−25万＝55万円の価値増大に貢献したことになる。

これを別の言い方で表現すると、タスクの貢献価値とは、そのタスクの開始時点で期待されるプロジェクトの収益（＝価値の期待値）と、そのタスクの完了時点での価値の期待値の差分で表現される。そして、価値の期待値とは、各タスクのもつ失敗のリスク確率と、タスク遂行に伴う費用ならびに収入（キャッシュフロー）で決まるのだ。

では、最初のように「製造」「販売」の２タスクからなるプロジェクトではどうなるか、計算してみよう。プロジェクトの期待価値は次のようになる。
「販売」完了時点：100万−20万＝80万円
「製造」完了時点：100万×90%−20万円＝90万−20万＝70万円
「製造」着手時点：100万×90%×50%−20万円＝45万−20万＝25万円
したがって、
「販売」タスクの貢献価値＝80万−70万＝10万円
「製造」タスクの貢献価値＝70万−25万＝45万円

両方のタスクの貢献価値を合計すると、55万円となって、さきほど計算した１タスクのプロジェクトの貢献価値と同じになることがお分かりいただけるだろう。

さて、これで準備はできた。いま、「製造」が完了して「販売」の開始時点になった。すると、進捗率は、まさにアーンドバリュー分析の教えるとおり、その時点までに達成した価値を、価値の合計で割ることで得られる。それは、
45万円÷55万円＝81.8%
となる。

よろしいだろうか？　タスクの価値とは、そのタスクの前後で増えるプロジェクトの期待収益であらわされるのだ。そして、価値は、タスクのリスク確率（失敗確率）に依存する。上の例を見てほしい。「製造」の方が「販売」よりもずっと貢献価値が大きい。これは、「製造」の方がリスク確率が大きい、すなわち“難易度が高い”からである。難しい仕事ほど、価値が高いのだ。当たり前に思える常識を、貢献価値の理論は数式で証明してくれる。

ちなみに、上の例で「販売」のリスク確率を失敗ゼロ、としたらどうなるか。「販売」の貢献価値もゼロになることは、すぐ分かると思う。失敗するリスクの全くないタスクは、必要かもしれないが、貢献価値はゼロなのである。

実際のプロジェクトでは、タスク数は２よりもずっと多いし、並行するタスクも存在する。こうした複雑な系でも、貢献価値を計算する手法は構成可能だ。詳しくはProMAC 2006の拙論文を見ていただきたい。

それにしても、もう一度、上の例をよく考えてみてほしい。従来の経営論では、しばしば「製造」はコストセンターで、「販売」がプロフィットセンターと扱われてきた。そして、プロフィットセンターの営業部門の発言力が、どんどん増していった。しかし、貢献価値を比較したら、コストセンターであるはずの製造部門の方が、より大きな価値を生み出しているのだ。どちらが経営上重要であるか、明らかではないか。

そしてまた、貢献価値の理論は、従来は評価の困難だった、企業内のバリューチェーンや、複数企業をまたぐサプライチェーンの適正付加価値の計算も可能にしてくれるのである。それもこれも、「リスク確率」の概念をキャッシュフロー分析に取り入れたからである。貢献価値の理論の威力が、少しでも納得いただければ幸いである。

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

プロジェクト・マネジメントは組織としての能力である （2008/06/02）

プロジェクト・マネジメントという言葉は、この１０年間でずいぶん普及した。それと同時に、誤認識や誤解もある意味で増えたと思う。そのひとつが、リーダーシップとの混同だろう。そもそも会社によっては、そもそもプロマネと呼ばずにプロジェクト・リーダーと呼ぶところもある（ＩＴ系企業に多いような気がする）。リーダーとは課長ないし係長相当の役職を示しているに過ぎないのだが、「リーダー」という言葉からリーダーシップを連想するのは、ほんのひとまたぎの距離だ。

ここから、プロジェクトの失敗はリーダーシップの欠如に原因する、という判断が生まれてくる。そうなると、“じゃあ、有能なリーダーをもってくれば解決する”、あるいは“リーダーシップの強い人物を任命すれば成功する”との短絡した結論が出てくる。リーダーシップ論だけではプロジェクトの失敗は救えない、という話は前にも書いたので、ここでは繰り返さないが（「プロジェクト・マネジメントにリーダーシップ論は要らない」 2007/07/09 参照）、日本のＩＴ産業には、なんだか英雄待望論みたいな気分が漂っているらしい。

もともと、「マネジメント」managementという概念自体が、日本人にとってわかりにくい。それなのに、“わかりにくい”という事態が意識されていないので、もっと始末に終えないのだ。たとえば「サプライチェーン」という言葉をだったら、対応する日本語がないから、“何じゃそりゃ？”とたいていの人間は思う。分かりにくさが意識されるから、誰しもよく理解しようと注意が働く。でも、「マネジメント」は“管理”とか“経営”という日本語が堂々と(?)ひかえていて、読めば分かったような気がする。そして、管理者の「人間力」の問題なのだな、などと思われてしまう。

実際は、プロジェクト・マネジメントの能力は、マネージャー個人だけの能力ではなくて、組織としての能力である。この点が理解されないので、議論がいつも空回りしてしまうのだ。プロジェクト・マネジメント能力には、上位構造・中位構造・下部構造の三階層がある。そしてこれらはピラミッド状になっている。頂点に位置するのは、ＰＭ個人の能力であり、具体的にはハード・スキルとソフト・スキルからなっている。

しかし、上位構造としてのＰＭ個人の能力は、じつは中位構造によって支えられている。中位構造は、「プロジェクト遂行手順・ＷＢＳ体系などの標準」、「プロジェクト・マネジメント・ツール（情報システム）」、「過去の実績データベース」の３要素からなっている。そして、これら中位構造は、下部構造としての「組織体制・権限関係」の上に成り立っているのだ。図にすると、次のような関係である。

いいかえると、プロジェクトに向いた適切な組織体制や権限委譲の仕組みがないと、プロジェクト標準やＰＭソフトや実績データが構築されないし、こうした道具立てがなければ、いかに優秀なプロマネといえど、実力を発揮しようがないのだ。優秀なプロマネを社外から引き抜いてくればＯＫ、あるいは最新機能のＰＭソフトウェアを買ってくればＯＫ、なんて簡単な話ではないことは、この図をじっと見ていればわかるはずだ。ここでいう中位構造・下部構造とはすなわち、PMBOK Guideの「組織のプロセス資産」の中身なのである。

プロジェクトを中心としたビジネスを成長させる原動力は、最近の経営学の流行の言葉で言えば『能力構築競争』である。そして、組織の能力をはかるベンチマークが必要なのであろう。この種のものとしては、PMIの開発したOPM3があるが、これはちょっと大掛かりすぎる。CMMIはＩＴ業界向けだが少し方向性が違う。もう少し簡便な、かつ業界をまたいで使えるものが必要だと私は考えている。こうしたモノサシがポピュラーになれば、なにせ横並びがお好きなこの国のことだから、あっという間に広がるだろうに。

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

プロジェクト・マネジメントにリーダーシップ論は要らない （2007/07/09）

昨年、国内最大手のシステム・インテグレーターのPMOの方から依頼されて、そこの社内PMセミナーで講演する機会があった。どういう話をしようか、少し迷ったのだが、その冒頭で、私はこう切りだした。「プロマネを選ぶときに、リーダーシップの有無を最初に問題にするのはおかしいと思います。少なくとも、私の業界ではそういうことは議論になりません。」

ご承知の通り、私はエンジニアリング会社に勤務して、プラント系のプロジェクトとSI系のプロジェクトの両方を経験してきた。二足の草鞋をはき、両者を子細に比べてみて気づいたのは、技術的な要素が大きくちがうにもかかわらず、プロジェクト遂行のストラクチャーがずいぶん似ているということだ。いずれも受託型のビジネスである。スコープと納期とコストが主要なコントロール対象である。元請け−下請け構造で複数業者が関わっている。個別受注・個別設計である（とはいえ、客先の要件はじつは業種によってかなり共通している）。納品物は生産財であって、客先はそれを受け取って自分のビジネスを運転しなければならない・・・

それにもかかわらず、エンジ業界とSI業界の人々のプロジェクト・マネジメント論議は、驚くほどちがう。その違いの一つが、リーダーシップ論だと思う。リーダーの資質とは何か。それは育成できるのか。PMOはそれをどう支援すべきか。こうした論点がくりかえしトピックに現れてくる。

しかし、ちょっと考えてほしい。あなたが航空会社を選ぶとき、機長のリーダーシップを気にするだろうか。「ご安心ください。当社のジャンボ・ジェット機のパイロットは、リーダーシップに優れた統率力ある人材を選んでいます。」などと広告されていたら、なんだかかえって不安にならないだろうか？

ジャンボ・ジェット機の操縦が易しい仕事だとは、決して思わない。しかし、リーダーシップだけで飛行機が飛ぶわけではない。われわれがパイロットに期待するのは、まず専門的教育を受けていること、ついで飛行実務経験だろう。機長のリーダーシップなどというものは、何か非常事態が起こった際に、迅速・的確かつ勇気ある決断ができるかどうかが問われるときのみ、真に重要になる。だが私はそんな事態は、あまり頻繁に予想したくないのだ。

同じようなことが、プロジェクトにも言える。少し前になるが、IT分野の雑誌にPM特集があって、その見出しの一つが「プロの火消し人集団」だった。だが、果たしてプロの火消し屋が何人もいるような組織は正常だろうか？　あなたが工場を見学に行ったとき、「ご安心ください。わが工場には、専任の消防隊が3班もおります。」と胸を張られたらかえって心配になるにちがいない。あなたはその職場で働きたいと思うだろうか？

念のためにいっておくが、私は別にプロジェクト・マネージャーにリーダーシップが全く不要だ、などと主張しているのではない。それが真っ先に議論されるのはおかしい、と言っているのだ。リーダーシップは、いざというときのために必要だ。そして、不思議なことにある一定規模以上のプロジェクトでは、かならずそういう危機が訪れる。私の知っているベテランのプロマネは、「さすがの俺も、今回はもうダメか！　と思うことが必ず２回来る。」と言っていた。リーダーシップは、そうした危機を乗り越えるためには、たしかに必要である。だが、危機を乗り越えるときは、プロマネだけでなく、プロジェクト・スポンサーやエンジニアリング・マネージャー、コントローラー達が一丸となって解決に動いていくものだ。プロマネ一人が背負うべきものではない。

それでは、なぜリーダーシップ論がSI業界では優先されがちか。それは、SIプロジェクトは『失敗率が高い』という信念、ないし神話があるからではないか。失敗確率が高ければ、たしかにリーダーシップの心配も高まろう。大西洋をはじめて横断する機長には、たしかに操縦技術以上に、強いリーダーシップがいるだろう（もっともリンドバーグには部下の副操縦士はいなかったのだから、誰に対するリーダーシップかと問われると答えられまい）。

プロジェクト・マネジメント技術とは畢竟、プロジェクトのリスク確率との闘いの技術である。PMBOK Guideのプロジェクトの定義（A project is a temporary endeavor undertaken to create a unique product or service）に、なぜ『リスク』の語が入っていないのか、私は常々疑問に思っている。もしあなたが、ジャンボ・ジェットの運行をプロジェクトだと思えないとしたら（上記の定義にはぴったり合っている）、それは、そこに失敗のリスクをほとんど感じないからだ。だから、プロジェクトの定義には「リスクをともなう」という一語が追加されなければならない。

と同時に、ビジネスの技術というものは、プロジェクトのリスクを低減して、だれもそれがプロジェクトだと感じないようにしむけていくべき存在だ。それが、プロジェクト・マネジメントのハード・スキルと呼ばれるものなのである。

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

プロマネのハードスキルとソフトスキル

「ハードスキル」と「ソフトスキル」という用語をはじめてきいたのは、2003年のことだったと思う。米国で参加した会議におけるPMコンサルタントの講演で、この区別を知った。プロジェクト・マネジメントに携わる人間のスキルを、「ハード」と「ソフト」に二分する思考方法は、そのときまで私の中には無かった。

米国の思考法は、つくづく「分けていく」思考法だな、と思う。分類し、分析し、分業する。全体を部分に細分化して、それぞれの特徴・特性を多面的に把握する。そして目的合理性の見地から、それらを使い分け、組み合わせていく。だから道具立ては専門分化したツールの集合体になる。PMBOK Guideの構成を思い出してほしい。まるでゴルフバッグに入ったクラブの束みたいだ。あるいはナイフとフォークを何本も並べるフルコースの食事のようだ。（これに対し日本人は最初から最後まで一膳の箸だけですませる。最小限の道具だけで何でもできるよう、自分の側があらゆるスキルを駆使するのが日本のスタイルだろう）

さて、そのスキルだが、プロジェクト・マネジメントの理論や手法やツールなど、形式化された知識を使いこなせる能力、これを「ハードスキル」とよぶ。一方、問題解決や交渉やモチベーションアップなど、非定型な（主に対人的な）技能を「ソフトスキル」という。

当然ながら、良いプロジェクト・マネージャーには、この双方のスキルが必要である。では、これらはどう習得すべきか？　習得の面からいうと、両者は全く異なる。ハードスキルは本や座学で学べる。しかしソフトスキルは、持って生まれたセンスを経験の蓄積の中でみがいていくしかない。前者はコンピュータなどの仕組みに乗せやすいが、後者はなかなか仕組みにのせにくい、といってもいい。

と、こう書いていくと、“だからソフトスキルを充実させる方が重要な課題で・・”とつながりそうに思えるかもしれない。しかし、私は今のところ逆だと考えている。ソフトスキルは、部下を持ち中間管理職の立場になったら、誰でもその必要性に気づく。プロジェクト的職種だろうが、そうでなかろうが、あまり関係がない。だから世の中の本屋には、リーダーシップ論や人心掌握術や処世訓があふれかえっているのだ。だれもがこの問題について悩んでいる。つまり、だれもがこの問題を認識している訳だ。

ところが、プロジェクト・マネジメントのハードスキルに関しては、その存在すら知らない管理者がいまだに圧倒的に多い。問題を認識していなければ、改善の対策などあるわけがない。さすがにIT系企業ではCMMiだとかPMBOK GuideだとかITILだとか、毎年あの手この手でおどかされているから、うすうすその存在については気がついている。しかし、それ以外の業種・職種ではどうだろうか。製造・生産技術・研究開発・マーケティング・経営企画・サービス・・・あらゆる分野で非定型な「プロジェクト」は存在する。中には企業の短期・中期の命運を左右する大きなプロジェクトもある。にもかかわらず、こうした世界のプロマネたちは、「プロジェクト管理に理論がある」という基本的なことさえ知らずに仕事をしているかもしれないのだ。まるで、海図も測量器具も知らずに航海に出る船長のように。怖ろしいではないか。

たとえば、12ヶ月スケジュールのプロジェクトがあったとしよう。今、開始してから3ヶ月たった。当初の計画では、現時点までに600万円の出費が予想されていた。ところで、実際の出費は500万円だった。このとき、「このプロジェクトはコストを予定内におさえているから安心だな」とプロマネが判断したら・・それは決定的に間違っている。プロジェクトのコスト管理は、定常業務と同じような予実対比で見てはいけない。これがアーンドバリュー分析（ＥＶＭＳ）の教えである。

ＥＶＭＳに限らず、ＷＢＳコード、アロウアンス、クリティカル・パス、トータルフロート、ＴＲＭ、マイルストーン、ドキュメント・インデックス・・・これらプロジェクト管理の基本的な理論や手法はみな、ハードスキルの範囲だ（とはいえ、適当に選び出したこれら用語がすべてカタカナの外来語であるということ自体が、この国のビジネス文化を象徴しているなあ）。

幸い、ハードスキルは短期間で一通りの知識を学べる。学んだ知識を実践力にかえていくためには繰り返しが必要だが、その機会は実務にいくらでもころがっている。だからこちらの方が優先課題だ、と私は言うのである。そのためにはまず、プロマネ、ならびにその上にいる上級管理職が、ハードスキルの存在を知らなければならない。

私の知っている米国人は長らく金融関係でシステム開発にたずさわっていたが、中年になってからこうした理論を学び、「あと１０年早くこれを学んでいたら、あれほど苦労せずにすんだのに！」と痛感したという。彼はのちに、独立してＰＭコンサルタントとなり、こうした知識の普及活動に従事することで、大勢の人が自分と同じような無駄な苦労を避けられるように貢献している。

前回、私は『誰のための生産管理？』（「タイム・コンサルタントの日誌から」2007/05/06）で、人間不在の管理論を強く非難した。しかし、今回はまったく逆のことをあえて書いている。人間論を排除したＰＭ論が必要なのだ。リーダーシップ論も人格論も部下の掌握術も、いらない。まず、ハードスキルを学ぶべし！

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

プロジェクト・コミュニケーションに必要な３つの能力 （2009/03/02）

一般にプロジェクト・マネージャーの働く時間の４割は、コミュニケーションに使われている、としばしばいわれる。いや５割以上だ、との説もあり、私の実感はこちらに近い。とにかく、プロジェクト・マネジメントというのは、朝から晩までかなりの時間を、何らかのコミュニケーションに費やしている。メールを読み、メールに答え、社内で打合せし、顧客や発注先と会い、会ったらその結果を打合せメモにしてまた発信する。そのかたわら上司の質問に答え、会社に報告書を出して、というわけで、朝から晩までずっとコミュニケーションに追われている感じである。

「プロマネ」という社内肩書きはついていないが、個別受注生産の設計部門や、あるいは品種の多い製造業の開発部門・生産技術部門の技術者なども、おそらく似た事情だと思われる。エンジニアと名乗って仕事はしているが、自分で計算したり図面を書いたりする時間はちょっぴりで、大半の時間を顧客や社内との連絡調整につかっている。多くの場合、図面や計算は専任の担当者や協力会社にまかせざるをえないし、事実まかせきりになっているようだ。

このように、設計・技術部門の多大なマンアワーを費やしている「コミュニケーション」作業であるが、それでは、その内容・レベルはどうとらえるべきなのだろうか。プロジェクトにかかわる人々の能力や生産性を問うならば、当然、その作業の重要な要素であるコミュニケーション能力を測り、その効率を改善しなければならない。しかし、「コミュニケーションの生産性」とは、いったい何なのだろうか？　PMBOK Guideなどには、９つの領域の一つとしてコミュニケーション管理があげられている。しかし、具体的に何をどうマネジメントしたらいいのか、抽象的すぎて読んでも歯がゆいと思う人は多いだろう。

このことを考えるためには、私たちが一口で「コミュニケーション」とよんでいることがらの中身を、少し立ち入って調べてみる必要がある。ＭＩＴのトマス・アレン教授は、近著「知的創造の現場―プロジェクトハウスが組織と人を変革する 」で、彼の長年の実測研究結果をまとめて、いわゆるコミュニケーションには、三種類の別の機能のことがらがまざっていると書いている。その３つとは、
●インスピレーション
●インフォメーション
●コーディネーション
である。これらはどう違うのだろうか。

インスピレーションとは、日本語で言えば「ひらめき」である。互いに会話する中で、ふとした気づきがおき、それが形になってくるプロセスだ。誰にも経験はあると思う。話をしているときに、ふとアイデアを思いつく。このときの会話は、とくに確とした目的のない、雑談めいたやりとりの場合が多い。ただ、何らかの問題意識をめぐる雑談なのだろう。たとえば、「あのモジュールの設計はどうやろう」とか、「この客に買ってもらうにはどんな説明がいいのか」といった漠とした問題意識だ。こうした背景を共有する何人かが、ほとんど偶然に集まって、ちょっとしたおしゃべりをする。その中でひらめきが生まれてくる。

だから、インスピレーション＝ひらめきを活性化させたかったら、似たような問題意識を持つもの同士が、偶然出会えるような場所や時間が必要だ。そう、アレンは推奨する。これは、壁とドアで仕切られた個室だけの米国式オフィスではむずかしい。だからチーム員を一つの部屋に放り込むとか、廊下にカフェコーナーを設けるとか、日本式の大部屋にするとかいった工夫が必要になる。こうしたひらめきの生産性は、アウトプットであるアイデアの質や量によって測ることになるだろう。

次のインフォメーションとは、「お知らせ」である。あることを知っている者が、そのことを知らない相手に情報を伝達する。上意下達の命令、下からの報告、ことなる部署間での伝達、客先や外注先への通知、そして発注−−こうしたものは、みなインフォメーションである。そして、インフォメーション＝お知らせは、その情報を必要とするどれだけ多くの人が、十分な知識レベルに達したかで効果が測られる。つかった時間や労力を分母にとり、知らされた情報量や受け手の数を分子にとって生産性が定義できる。つまり、早い話が時間あたりに伝達したビット数である。

ちなみに、コミュニケーションとは、日本語でのイメージと違い、英語では一方通行的な概念である。誰かが誰かに一方的に伝えること。これをcommunicationとよぶ。だから、放送局のアンテナから全国のＴＶセットに電波を配信する仕組みを、mass communication＝マスコミと呼ぶのだ。

英語の概念では、コミュニケーションは基本的に発信者側に伝達の責任がある。相手が分かるように表現し、相手に伝わるように渡し、かつ相手が受け取ったかどうか確認する。まさに通信技術そのものである。日本人のように、コミュニケーションは双方向で、かつ受け手の側に理解責任がある、という感覚ではない（むろんこれは両者をわざと図式的に対比した言い方であり、現実には日米ともその中間に広い領域があるが）。

さて、第３の種類は、コーディネーションである。Coordinationという英語は、ordinate（座標軸）をあわせる、という意味である。ばらばらになっている方向性をあわせるのだ。何の方向性か？　それは、それぞれの話者の考え方の方向性である。皆のベクトルを一致させると言ってもいい。日本語で表現するなら、「折り合い」をつけるといおうか。

そして、このコーディネーション＝折り合いこそが、ビジネス・コミュニケーションにおける最大の難物、時間消費の元なのである。なぜなら、コーディネーション＝折り合いとは、その場の集団による意志決定にほかならないからだ。

プロジェクトにおいて、インスピレーション・インフォメーション・コーディネーションが、それぞれどの時期にどれだけの割合になるか、私の経験を示してみたのが次の図だ。仕事のごく初期は、ほんの数人でアイデアをふくらませる段階だ。だから「ひらめき」が主体になる。しかし、仕事が広がりをもってくると、メンバーを増員していくことなる。この新参の人たちは従来の背景を知らないから、説明して理解してもらう必要が出てくる。また、アイデアの結果は次第に設計その他の成果物として形になってくる。これも共有する必要がある。こうして、情報伝達のためのインフォメーションが次の主役になる。

しかし、さらに仕事が発展して、会社の様々な機能部門を動かして進める段階になると、こんどは各部の人間の目的意識や行動規範の違いが目立ってくる。ホワイトカラーはみな、一家言ある人たちだ。そして、互いに自分なりの仮説や憶測や流儀をもっている。同じ目的のために働いているのだが、それを達成するための方法や、状況認識にいろいろ違いが出てくる。同じ企業内ならまだしも、これが顧客や関係会社との折り合いとなると、もっと大変だ。

しかも、プロジェクトには、つねに不確実がつきまとっている。誰も先のことは分からない。だから、ＡがいいかＢがいいか、判断が分かれてくる。でも、この判断の差というのも、しょせん「55% vs. 45%」程度の確信度の差でしかないのだ。それを、「いや、そんなこと俺は聞いていない」「あのミーティングには呼ばれていなかったから」などと言い合うのが、会社員の常らしい。とにかく、皆の発言を一度は聞いておかなければならない。これは知識の問題ではなく、じつは感情の問題なのだから。

このようにして、最盛期にはコーディネーション＝折り合いのために、ひたすら時間が消費されていくのである。浪費と言ってもいい。アウトプットは、というと、別に合意書とか議事録とかの数ではなく、要は互いの感情がいかに静まったか、互いのメンツがいかに立ったか、であるから、これほど生産性の測りにくい営為はない。

では、コーディネーション＝折り合いの消耗さを減らすにはどうしたら良いのか？　皆で飲みに行くしかないのか？　そこに生まれたのが、ひとつの実際的な解決法である。それは、「プロジェクト・マネージャー」という役割の人間を置いて、最終的にはこの人の決断にしたがって動こう、という決めごとだ。そのかわり、プロジェクトの結果に対する最終責任も、この人が負う。これは上司部下の問題ではなく（なぜなら、ことなる部署間での折り合いなのだから）、役割＝ロールの問題である・・・これが、プロジェクト・マネジメントの基本的な考え方なのだ。

そして、プロジェクト・マネージャーはベターな判断をするために、できるかぎりすべての情報を知っておかなくてはならない。そのためには、プロマネを頂点としたツリー型のインフォメーション・ルートを構築しなくてはならない。こうして、大勢の人間が55%対45%の言い争いをするかわりに、誰か一人（別に全知全能でもなんでもない人間）が始めから終わりまで責任を持って仕事を見る、という仕組みが生まれたのである。そんなわけで、組織全体のコミュニケーションの浪費を減らすために、プロマネは今日も朝から晩までメールとミーティングに追われるのである。

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

サービス、『感情労働』、そしてプロジェクト・マネジメント （2011/08/18）

「経済のソフト化」が言われ、「サービス・サイエンス」という新学問が提唱される今日においても、肝心な「サービス」の定義や中身はなかなか定まらない。なぜ、サービスをめぐる議論はかくも混乱するのか。前にも書いたとおり、サービス業とは「リソース提供ビジネス」であり、物質的なリソースあるいは人間系リソースの利用権・占有権を売るビジネスではないか。通信インフラや鉄道輸送などの物質的リソースについての機能は工学的に明確なはずである。また人間系リソースの提供にしても、知識労働（弁護士や通訳など）ないし肉体労働（整体師や溶接工やら）の役割は明瞭なはずであり、多くは資格制度も付随している。

それなのに、なぜかしばしば、ノードストローム（米国の高級百貨店＝物販業）やディスニーランドや銀座の高級マダムの接客術みたいな要素が、サービスをめぐる議論の俎上にのせられる。お客様の「おもてなし」や、要望への「気づきの心」が声高に求められるのはなぜなのか。

そこには従来見過ごされていた、あるきわめて重大な種類の労働が関わっているからである。それは『感情労働』である。

感情労働という概念は、'70年代アメリカにおいてConstructivismと呼ばれる社会学研究の中で提唱された（Constructivismは「社会構成主義」ないし「社会構築主義」と訳される）。口火を切ったのはホックシールドいう学者で、その仕事は『管理される心―感情が商品になるとき』という著書にまとめられている。感情はふつう、それが喜びであれ悲しみであれ、私生活において適切に表出し、互いに贈り合うことで、人間関係を円滑に成り立たせる機能を持つ。つまり、感情とはプライベートな社会関係において必要不可欠な資源（リソース）なのである。ところが現代社会では、この感情が商品化され、仕事の領域でも使われる。サービス業の従事者は、その仕事の一環として感情を制御することや、顧客に「感情の贈り物」を提供することを求められる。これが「感情労働」である。

ホックシールドが研究対象とした一例は、航空会社のフライト・アテンダントだった。業務としてひんぱんに感情操作を求められるこの職種では、労働強化は労働者の情緒障害と自己疎外を招く、とホックシールドは警告した。彼女の研究に続いて、ショット、ケンパーなど気鋭の社会学者達が、感情の社会学とも言うべきこの分野に入ってくる（ここらへんの事情については、中川伸俊氏の「社会構築主義と感情の社会学」という論文−以前はネットで公開されていたが現在はリンク切れになっている−によって勉強させてもらった）。

ところで、何でわたしがConstructivismなどを勉強しているかというと、プロジェクト・マネジメント研究に関係するからである。毎年夏に欧州の主立ったPM研究者が集まるEDEN PM Seminarという会議があり（今年もちょうど今週、仏Lilleで開催中）、3年前にそこで知ったからだった。欧州のPM研究は、方法論を徹底的にやるのが特徴で、ただ単にアンケート調査やケース・スタディをしてみたらこういう結果になりました、というだけでは研究と認められず、いかなる理論的枠組みで、なぜこのような方法をとったのかが厳しく問われる。そこに登場するのがConstructivismやPositivismやCritical Theoryといった理論で、様々なプロジェクト（それ自体は各々ただ一度限りの社会現象である）を、どう把握し分析するかの導きとなるのである。日本の、実務的だがある意味ナイーブなPM研究との違いに驚かされる。

話を元に戻すが、感情は人間が「生まれつき自然に」持つのではなく、社会的に訓練され構成されるものである、というのがConstructivismの立場だ。そして、社会的場面に応じて、適切に感情を表出／制御するべく、人々を動かしていく（たとえば社長による深刻な訓話の最中に笑い出したりしない、といったように）。これを社会の『感情規則』と呼ぶ。

そして、世の中には、感情を相手に応じて制御しなければならないタイプの労働がある。これが感情労働なのである。ホックシールドはフライト・アテンダントを研究したが、その著書の翻訳者である石川准氏は、看護師の感情労働を例に挙げている（わたしの長年の友人である彼は、全盲の社会学者であり、また天才的プログラマーでもある）。たしかにナースの仕事は、知識労働もあり肉体労働でもあるが、同時に絶え間ない感情制御を伴う労働でもある。看護師たちは感情を酷使されている。と石川氏は言う。ちなみに看護師には喫煙者が多いと言われているが、喫煙の害を誰よりもよく知っているはずの彼女たちが喫煙に向かうのは、このような仕事のストレスが生むのかもしれない。

感情労働には、感情を抑える仕事と感情をつくる仕事の両方が混じっている。これを職業的に求められる職種は、CAやナースだけではない。たとえば、俳優もそうだ。そして、あらゆる業種をまたいで、広く感情労働が必要な職種がある。営業職だ。

セールスの現場はまさに、感情労働のかたまりである。相手にあわせ、相手を不快にせず、しかも相手を自分に都合良く誘導しなくてはならない。そのために必要な感情の制御はかなり高度なスキルであるし、またそのことが営業マンの消耗とストレスの原因ともなっている。

セールスマンの感情労働を見事に描いたマンガに、業田良家の「ゴーダ哲学堂」がある。「オレってまるで、ロボットじゃん」と、その登場人物は言う。実際彼の姿はスーツを着たロボット風に描かれている。理不尽な客のワガママにぶつかると、彼は「感情制御装置」のキーパネルをとりだし、『笑』のスイッチを押しては「ハッハッハッハッ。冗談きついなぁ店長さん。」と笑顔を作り、『哀』を押して「かんべんしてくださいよ〜〜。」と泣き落としにかかるのである。ただ、『怒』のボタンはひどく小さく、押しにくいようにできている。そして、「感情全テノボタンヲ、強ク激シク、毎日ツカワナケレバイケナイ」と独白するのである。

以前「新しい販売マネジメント思想こそ、競争力再生の要点である」に書いたように、現代日本の成熟市場においては、営業とは顧客ニーズの創出と供給側のコントロールを同時に行う“きわめて高いインテリジェンスを求められる仕事”になっている。それに加えて、この感情労働だ。今日の競争力のかなりの部分が営業にあるにもかかわらず、これをリードする思想は成熟していない。その理由は、「感情労働」という知識労働でも肉体労働でもないあたらしいカテゴリーの概念を、きちんと認識していないためである。概念がないから、教育訓練の方法論もない。パフォーマンスの尺度もない。これで改善をマネジメントできる訳はない。

そして、もう一つ、感情労働が重要な役割を占める職種がある。それがプロジェクト・マネージャー職だ。わがままな顧客と感情をすり合わせ、疲弊したチーム員を慰撫し、居丈高なくせに不安そうな上司には、信頼感を持たせる。これら感情を素早く切り替えて表出し、なおかつ計画やら報告やらにも気を配らなければならない。プロマネが世にも大変な職種である理由は、このような感情労働のレイヤーが、他者にも自分にも見えていない（だからその報償も得られない）ことにあるのではないか。

わたしは、知識労働も肉体労働も感情労働も、別に上下や貴賤はないと考えている。社会学者達は「商品化される心」というタイトルからみて、感情労働にネガティブな視線をなげかける傾向があるようだが、どんな労働だって、それが過重で無報酬だったら、人を壊していってしまうと思う。一定のニーズが社会の中にあるのだから、感情労働にもちゃんとした地位を与えればいい。感情労働に問題があるとしたら、人がそれを認識しないまま、当然のサーヴィス（無料）として「感情」のリソースを浪費してしまう点にある。プロマネ達がみんな疲弊してしまわないためにも、マネジメント業務の中に感情労働のスキルと価値があることを、皆もっときちんと意識すべきだと思うのである。

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

プロジェクト・スケジューリング

生産スケジューリングとプロジェクト・スケジューリングの違い

スケジューリングという言葉がカバーする範囲は広い。拙著「革新的生産スケジューリング入門」にも問答の形で書いたが、学校の授業時間割の決定、交通機関の時刻表の決定、病院の看護士勤務順の決定（「ナース・スケジューリング」）、スポーツの試合順を決めるスケジューリング、さらにコンピュータでのジョブの優先順位を決めるＯＳレベルの技法など、様々なタイプの問題がある。

拙著では、まず「パーソナル・スケジューリング」からはじめて、「プロジェクト・スケジューリング」で基本概念を説明し、「生産スケジューリング」に進む、という順番で解説している。同じ生産スケジューリングでも、組立加工系生産・プロセス生産・切替型連続生産などの生産特性によって、業種ごとにかなりの違いがあることも説明した。

ところで、最近はプロジェクト・マネジメントへの関心が急速に高まってきた。そこで、生産スケジューラを専門にするＡＰＳベンダーにも、プロジェクト・スケジューラの案件や問い合せが増えてきているようだ。そこで、疑問が一つ心に浮かぶ。はたして同一のツール、同一の論理で両者をまかなえるだろうか？

考えてみると、航空機・船舶・大型産業機械などの一品受注生産は、両者のちょうど中間に位置しているように見える。いわゆる重工メーカーの世界である。工場の生産工程はもちろんある。しかし、個別の製品（案件）ごとに、設計・材料調達・引渡しなど複雑な日程表を決めなくてはならない。リスクもある。あきらかにプロジェクトの特性をもっているのだ。

こうした業界では、カンバン方式による単純なプル型生産管理など使いようがない。しかし、かといってふつうのＭＲＰは適用しにくい。なぜか？　それは、最初にＢＯＭが存在しないからだ。製品のＢＯＭは、基本設計・詳細設計を経て、はじめて確定される。へたをすると、試作テストなどを通さないと、ＢＯＭは確定しないかもしれない。

この点では、ＡＰＳも同じ弱点を持つ。固定リードタイムのＭＲＰと異なり、ＡＰＳは製造の実作業時間を見積もるが、その基準になるのはあくまでもＢＯＭと工順（ルーティング）のマスタ・データだ。一品受注生産では、そのマスタ・データが、計画策定時点で確定していないのだ。言いかえるならば、ＡＰＳは原則として、見込み生産ないし繰返し受注生産の業種でないと使えないことになる。

では、ＡＰＳのＢＯＭ・工順の中に、設計作業や購買作業・製造作業などのタスクを登録したらどうだろうか？　ＰＥＲＴ／ＣＰＭ技法で必要なタスク間の依存関係なども、ＡＰＳでは柔軟に定義できるから、うまくスケジュールを計画立案できそうな気がする。

ところが、そう簡単には行かないのだ。理由は、３つある。まず、タスクの所要期間見積がむずかしい。製造工程ならば、工程のサイクルタイムと処理数量をベースに、前段取りや後段取りなどを加えて時間を見積もることができる。しかし、人間の行なう設計作業では、こうした基準数量が定義しにくいから、いきおい全部が固定リードタイムになってしまう。製造作業のタスクも、ＢＯＭがなければ、やはり固定リードタイムとせざるを得ない。これでは、何のためにＡＰＳを使っているのだか分からなくなってしまう。

もう一つは、制約条件を意識する方向の違いだ。プロジェクト・スケジューリングは、単一の案件をベースに、それぞれ独立に行なうのがふつうである。クリティカル・パス、すなわち時間方向（横方向）の制約が主題なのだ。他方、生産スケジューリングは、複数の生産オーダーをまとめて計画立案する。それを定期的にくり返していく、ローリング・スケジュールが特徴である。つまり、生産スケジューリングでは、複数のオーダーが工場の生産リソースをとりあう、縦方向の制約をつよく意識する。問題へのアプローチも、解くための戦略も異なってくる。

そして、最大の違いは、進捗管理のあり方である。スケジューリングは進捗把握の基準線（ベースライン）として、本来の意味がある。進捗把握と統御をしないのなら、スケジューリングを行なう価値などない。単に餅を絵に描いているにすぎないのだから。

さて、生産スケジューリングは物（マテリアル）で進捗を計れる。その進度は非常に明確である。現場に行って数を数えれば、誰もが議論の余地なく同意できる。ところが、いわゆるプロジェクト・スケジューリングでは、設計・企画・外注など、人間主体のソフトな行為の進捗度をつかみにくい。アウトプットが物ではなく情報だからだ。情報の精度や完成度は、機械には判別できない。計量化しやすいのは、輸送や現場工事などのように物量で計れるタスクだけだ。

このように、生産スケジューリングでは物（マテリアル）を中心として、タスクをきちんと計量化する。プロジェクト・スケジューリングでは、タスクと物量には「ゆるやかな関係」があるに過ぎない。だからこそ、プロジェクトの進捗管理では、“見える化”の努力が非常に大きな意義をもつのである。

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

プロジェクト・タイム・マネジメントのベーシック

スケジュールという英単語は、もともと『一覧表』とか『箇条』という意味に近い。箇条書き、の箇条である。そこから転じて、主に米国で時間割や予定表の意味に使われるようになったときく。これをtime scheduleという。だから、PMBOK Guideの初版を作った人たちが、９つの知識領域の中で時間軸上のマネジメントのことを、スケジュール・マネジメントなどと呼ばずに、タイム・マネジメントと呼んだのは、本来の英語感覚からすると元に戻ったわけである。

その、プロジェクトにおけるタイム・マネジメントの基本は何だろうか。大きく７点ほどあげることができる。

(1) プロジェクト全体のタイム・スケジュールの目標、すなわち納期を達成するために、スケジューリングの仕組みを確立し、その水準を維持すること。

(2) プロジェクト組織を構成する各機能単位（グループ）に対して、成果物単位での「完了目標日」を含んだ詳細スケジュールを示し、またそれを保守すること

(3) すべてのスケジュールを、そのアクティビティのＷＢＳレベルの如何にかかわらず、ＣＰＭ（Critical Path Method＝クリティカル・パス法）による詳細なネットワーク・スケジュールの中での位置関係を明らかにし、また影響範囲を追跡可能とすること

ここまでの３点は、Plan-Do-Seeのマネジメント・サイクルの中で、Planすなわちプロジェクト計画段階の作業に属する。いわゆるスケジューリングと呼ばれる領域である。教科書的には、(2)のＷＢＳの列挙や(3)のクリティカル・パス法にもとづいたネットワーク・スケジュールを作成が、よくハイライトされる。しかし、一番大事なのは(1)、すなわち、タイムキープするための体制と仕組みの確立である。

そして、たいていの実務では、マスタ・スケジュールを立案してガント・チャートを書き終えると、その時点で安心してしまいがちである。そのあと、そのガント・チャートは一度も見なおされなかったりする。しかし、本当のタイム・マネジメントはこの後からはじまる。

(4) 進捗度とパフォーマンスの記録をとり、それをレポーティングすること

これが、Plan-Do-SeeのDoの部分の中核である。記録し、報告する。これをみな、面倒くさがって怠る。そして、ひとたび問題が発生すると（しかもプロジェクトでは必ず、つねに問題は発生する）、それはプロマネに気づかれぬまま、担当者の胸の内に隠微に広がりはじめる。それを防ぐためには、

(5) プロジェクトの状況をモニタリングし分析して、各アクティビティがプロジェクト全体の要求するスケジュールに合致するよう保証すること

(6) プロジェクトのスムーズな遂行を可能にするような、健全なマネジメントの決定がよってたつべき基準を提示すること

(7) プロジェクトの主要やマイルストーンや完了日に影響する潜在的問題を早期に予見すること。そうした問題はマネジメントや最終顧客が先手を打って防げるように、きちんと報告されること

というSeeにかかわる部分の作業が必要になる。こうしたこと全体が、プロジェクト・タイム・マネジメントである。その中心は、(4)進捗とパフォーマンスの計測、にある。この計測が正確かつ迅速に行なわれるプロジェクトは、ちょうど正確なGPSを積んで運航する船のようなものだ。今どこにいて、どれだけの速力で、どこに向かっているかがつねに把握できている。非常に安心である。

むろん、たとえGPSを積んでいても、海に嵐が発生するのは防げない。すなわちリスクの顕在化である。しかし、待避路をとるのは早く確実になる。これが、タイム・マネジメントのベーシックなのである。

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

マイルストーンは中点で測れ

プロジェクト・スケジューリング立案作業の第一歩は、いうまでもなくＷＢＳ（Work Breakdown Structure）の作成である。成果物スコープとプロジェクト・スコープを、もれなく・重複なくカバーするタスク（アクティビティ）をすべて拾い上げる。それらを階層的に構成し、整理番号をつけたものがＷＢＳだ。スケジューリングは、ＷＢＳを構成するアクティビティの所要期間を見積り、また、それらアクティビティ間の論理的な着手順序や依存関係を決定して、ロジック・ネットワークに落とし込む（ここは何らかのソフトウェア・ツールを利用することが多い）。その上で、クリティカル・パスを求めると、それがプロジェクト全体の工期となる、という訳である。

通常はさらに、クリティカル・パス上の主要な達成点に、「マイルストーン」を設置する。これは後の進捗管理を分かりやすくするための工夫だ。ここまでは教科書的な常識の話で、誰もが知っていることだろう。

さて、問題は各アクティビティの所要期間の見積だ。これの精度がいい加減だと、プロジェクトの納期も信頼度が落ちるばかりか、コスト見積の精度もあやしくなる。したがって、過去に類似プロジェクトの経験があれば、当然そこから実績期間のデータを集めてきて、参考にすることになる。むろん作業量の大小に違いはあるだろうから、作業量の基準となる値（ＢＯＱ）を比較する必要がある。ＢＯＱというのは、たとえば、テスト件数であるとか、コンクリート打設m3だとか、端末設置台数とか、業務プロセスのシナリオ数とか、そのアクティビティの仕事量を代表する指標である。プログラミングなら、ファンクション・ポイントを用いることも多いだろう。

過去のアクティビティと現在計画しているアクティビティのＢＯＱの比が２倍なら、所要期間も２倍になるだろう、と一応考える。ただし、これでは単純すぎるわけで、実際には投入要員数と生産性で補正して所要期間を計算するわけだ。

ところが、この「過去のアクティビティ実績期間」というのがくせ者なのである。というのも、実はアクティビティの着手時点と完了時点というのは、正確につかむのが案外むずかしいからだ。たとえば、「９０％シンドローム」という言葉を聞いたことがあると思う。「プロジェクトの期間の９割で進捗率は９０％に達し、その後また同じ期間をかけてようやく１００％に達する」（つまり当初計画の1.8倍の期間がかかる）という、ジョーク混じりの法則である。どんな仕事でも、最後の詰めの部分は効率がわるい。だから、アクティビティの進捗率のグラフを描くと、「Ｓカーブ」になって最後はかなりなだらかな上昇になる。

全体の９０％まではすんなり到達するが、最後の１０％にずっと時間がかかる理由は、二つある。一つは、「１００％地点」が正確に見えていなかった、というケースだ。製品開発の基本設計とか、情報システムの要件定義などの“ソフトな”仕事では、よくある。しかし、もっとしばしばお目にかかる理由は、仕事も９割を超えると、むしろ「残存問題箇所の修正モード」に入るからだろう。これはソフト的か、力仕事的かにかかわらず、起こりうる。ほぼ終わりが見えた時点で、ふつうは残件リスト（英語ではPunch Listとよぶ）を作成し、それをつぶすモードになる。この残件つぶしに、思ったより時間がかかるのだ。だから、「実質的に終わり」の時点と、「公式に終わり」の時点にかなりの開きが出てしまう。

期間がとらえにくいもう一つの問題点は、着手時点にある。プロジェクトの上流側の作業が遅れている場合、下流側の担当者は、しばしば「できるところから先に手をつけて」準備作業に入ることが多い。上流側が終わっていないので、下流側で手をつけられる箇所は当然限られている。だから、チョロッと手をつけては待ちになり、またちょっとやっては待ちになる。こうして生産性の上がらない期間が最初にできてしまう。あるいは、ＴＯＣ理論で言う「学生症候群」で、最初はサボっていて、タスクの締切近くにならないと真剣に作業しない、というケースだってあるだろう。

このように、過去の実績期間データというのは、案外そのままは使えないものが多いのだ。それでは、どうするか？

ここで使うテクニックが、「中点で測る」方法である。アクティビティのＢＯＱの５０％を達成した時点を、マイルストーンとして内部管理用に記録しておく。そして、マイルストーン間の期間を比較の尺度としてつかうのである。むろん、期間の半分の時点を記録するのではなく、達成率５０％になった時点を記録するのである（いわずもがなと思うが、念のため）。

このようにすると、先行して着手したり、あるいは最後のダメ詰めで時間をとられたりした際の影響を受けにくい。いわばＳカーブの傾斜の大きなときに測るわけであり、精度も比較的ぶれない。複数のプロジェクトを比較するときも、５０％時点を中心に並べると見やすく、分かりやすい。

無論、このためには、作業量見積の基準となるＢＯＱをうまくみつけておく必要がある。人間の標準作業や生産性評価が重要となるのは、このためなのである。

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

Excelで工程表を書いてはいけない

さる8月、翔泳社主催の「PM Conference 2008」に招かれて講演をした。テーマはプロジェクト・コントロールの技法論で、私が長い間、エンジニアリング業界とIT業界の二足のわらじを履いてきた経験から、両者の比較を論じたものだった。最近のIT業界における「プロジェクト・マネジメント」の認識の普及進展はめざましいものがある。これに対して、エンジニアリング業界は過去10年以上、EVMSの徹底化以外とくに主立った進歩はない。にもかかわらず、両者の違いはいまだ歴然としたものがあり、それはとくにプロジェクト・コントロールの基本であるWBSやコントロール・リストなどの使い方で明瞭だ、というのが論旨だった。

ところで、この講演の中で、「工程表のガントチャートをExcelで書いてはいけない」と強調した点が、どうも多くの聴衆の注意を引いたらしい。終わってからのアンケートでも、そこに関する感想が少なくなかったし、講演後、直接私のところに質問に来られた方もいた。“じゃあどうしたらいいんだ?”“何か良いツールはあるのか?”というのが率直な疑問らしい。

Excelでガントチャートを書きたくなる理由は、私もよく分かる。まず、事実上すべてのPCにのっており、誰でも読み書きできる。縦横に罫線があり、ガントチャート作成に便利に思える。お絵描きの道具がそろっていて、すぐに矢印を引ける。担当者の名前や作業量なども表に書き込める。必要なら、さらに引出し線だの注釈だの好きなコメントを書いていける。実に便利である。

にもかかわらず私が、Excelで工程表を書いてはいけない、と説明したのには三つの理由がある。第一の理由は、クリティカル・パスが見えないことだ。プロジェクトの出発点から、全作業の完了までの経路の中で、時間的に最長の経路をクリティカル・パスとよぶ（日本語では「隘路」だ）。プロジェクト全体の納期は、このクリティカル・パスの長さに等しい。したがって、プロジェクトの納期短縮を図りたかったら、どこがクリティカル・パスになっているかを見つけ出して、それを短くすることを考える必要がある。

コスト＝原価管理の世界では、プロジェクトのコストは、すべてのアクティビティのコストの足し算になる。大小を問わずどのアクティビティで1円節約しても、全体予算の1円節減に直結する。だからコスト・マネジメントでは、基本的にすべてを軽重なく公平に見ていく必要がある。ところがスケジューリングの世界では、クリティカル・パスの長さだけがプロジェクト全体の期間を決める。非クリティカルなアクティビティについていくら期間短縮の努力を払っても、全体には何の影響もでない。そこでタイム・マネジメントでは、重要な管理対象と重要でないものが峻別される。これがマネージャーにとって最も大きな違いだろう。

Excelで工程表を書いてしまうと、ここが見えなくなってしまう。「だったら太線にしたり、赤く表示したらいいじゃないか」というのは浅知恵というものだ。クリティカル・パスは、作業が進むにつれて（その進捗や遅延にしたがい）しばしば他の経路に移ってしまうことを忘れている。このため、潜在的にクリティカル・パスになりやすい経路を、「サブクリティカル・パス」と呼んで、最初から注意しておく必要がある。CPMの技法論でいえば、フロート日数＝ゼロの経路がクリティカル・パスになる。そこで、フロート日数が（たとえば）2週間以内の経路をサブクリティカルとして認知しておく、などの工夫がいるのだ。Excelの線表では、このフロート日数が見えてこない。

第2の理由は、先行作業が遅れた場合の影響範囲がわかりにくい、ということだ。実際問題として、プロジェクトというのは遅れるものなのである。これは、最初に作成する工程表が「ターゲット日程」を表しているものである以上、当然のことだ。そこで、実務上問題となるのは、前方の作業が遅れたとき、後ろの方のアクティビティが着手するのはいつになるのか、という点だ。これはとくに、担当者や担当部署が異なるときは悶着のタネだ。ところが、Excelの線表というのは、一つの線を延ばしたら、後ろにつながる線を全部、自分の手で書き直さなくてはならない。当然、ここにはミスが入り込む可能性も出てくる。

3番目の理由は、スコープの追加や、WBSの変更に対応した修正が面倒であることだ。これは第2の理由とも通じるが、部分的な修正が全体の変更につながる、というのがプロジェクト・ネットワークの性質である。これを、書き手がすべて自分の頭の中で追いかけなくてはならない。そして、追加変更は、プロジェクトに宿命的について回るものである。

結局、Excelで書いたガントチャートは、ロジック無き「絵」にすぎないのだ。プロジェクトの工程表とは、背後にロジック・ネットワーク・スケジュールを持っていなければならない。ここが根本的な認識のズレなのである。Excelで工程管理してはいけない。私の主張は、この点にある。

じゃあ、工程表どんなツールで描いたらいいのか？−−こういう質問が出てくる点が、まあいかにもIT業界らしいな、と感じてしまう。こちらは考え方の話をしたつもりなのに、いつの間にかツール論になっている。ツールとはさみは使いようだから、上記のことさえ忘れなければ、別にExcelを使うこと自体がわるいわけではない。まあ、不便だが。

それでも、何かのツールを推奨しろ、という話になると、ちょっと困ってしまう。Microsoft Projectは誰もがまず思いつく製品だろうが、いくつか理由があって、私はMS Projectはあまりおすすめしない。たとえば後続のアクティビティをすぐに見つけにくい、だとか、アクティビティ数が増えていくとひどく重くなるとか、は機能的問題だからまだしも、Forecastという概念がないとか、プロジェクト全体の締切というものがクリティカル・パスの長さとは別に規定されているとか、概念自体に違和感を感じる。

米国でのある調査でも、MS Projectはもっとも多く購入されているが、もっとも使われていないプロジェクト・マネジメント・ソフトだという結果が出ている。そもそも、この製品を出しているMicrosoft自体、自社の主力製品をリリースする際、期日変更や早期パッチの常習犯になっていないだろうか。自社のプロジェクトをきちんとマネジメントできない会社の製品を、私はあまり信用したくない。むろん、ツールは使いよう次第。現在この製品で十分うまく仕事を回している人に対してまで、使うのをやめろと主張するつもりはない。限界を知った上で、ツールを使い倒すのが、プロの仕事というものだろう。

じゃあ、そういうおまえ自身は何を使っているのか？　そういう質問もあるだろう。私自身は、二つの製品をほぼ毎日使っている。一つは、Primavera Project Planner（略称P3）だ。これはエンジニアリング業界では事実上の世界標準であり、海外のほとんどの顧客から、これを使え、と指定される。P3は、いわば超高級Microsoft Projectであり、とくに1,000以上のアクティビティからなるプロジェクト計画では、ほぼこれ以外に使い物になるソフトはないと言っていい。

そのかわり、これは「プロの使う道具」である。機能が多く、スキルが必要だ。どうしても、スケジュール・コントロール専門職のツールになってしまう。おまけに、世界中で広く使われているVer. 3は英語版だ。最新のVer. 6は日本語も通るが、高くて重くて人気がない。しかも、Primavera社は先月、とうとうOracle社に買収されてしまった。この先、旧バージョンがどうなっていくかは誰にも分からない。いずれにせよ、日本国内での仕事で、かつアクティビティ数が50から100程度の工程表には、P3はおすすめではない。

ちなみに、私がもう一つ使っているのは、ソフトブレーン社の「e工程マネージャー」である。これは、かつて企画段階に私自身が参画した製品なので、私が使っているのは当然だし、ここで何か言っても宣伝にしか聞こえないだろうから、あまり詳しく述べるつもりはない。Ver. 3になってだいぶん良くなったが、改善すべき課題はまだ多いと私自身は感じている。

それにしても、どんなツールが良いのか？　という問に対しては、こう答えるしかない。まず、あなた（の会社）は、それにいくら払う用意があるのか。数万円か、数百万円か？　それはつまり、プロジェクト・マネジメントの向上にいくら価値を認めるのか、という問いかけである。プロジェクトの失敗で数千万の赤字を出した経験のある企業は少なくない。なのに、プロマネに数万円の工程表作成の道具代を配ればどうにかなるだろう（これだってあわせれば百万にはなるだろうが）、という楽観的なポリシーで運営されているとしたら、“グッド・ラックを”というのが唯一の回答かもしれない。それが「ツール」と言えるのかどうかは自信がないが。

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

ＷＢＳのつくり方

ＷＢＳは、「仕事のＢＯＭ」である。私は最近、そう説明することにしている。プロジェクトという、始まりと終わりがある仕事の全体像を表現するには、それを構成している仕事の部分品ひとつひとつに分解して、どういう構成になっているかを示すのが一番分かりやすい。それがＷＢＳである、と。

ＷＢＳはWork Breakdown Structureの略である。プロジェクト・マネジメントで使う用語だ。このWorkという英語はいささか多義語で、仕事（人の作業）のこともさすが、加工対象物（モノ）のことをも意味する。そのせいかどうかしらないが、ＷＢＳの作り方には従来、二通りの考えがあった。

まず、ＷＢＳは人の作業の構成表である、とする考え方がある。システム開発プロジェクトという仕事は、「要求分析」「設計」「実装」「テスト」「移行作業」などとブレークダウンしていく。「設計」はさらに「基本設計」「詳細設計」「実装設計」に分けることもできるだろう。これはある意味で、仕事の進む順序＝プロセスを表現しているとも言える。別の例で言えば、製品開発プロジェクトという仕事のＷＢＳは、「製品企画」「市場調査」「設計」「試作評価」「量産準備」というわけだ。

もう一つの流儀は、ＷＢＳを、プロジェクトの成果物の構成にしたがって作るやり方だ。在庫管理システムの開発ならば、「入出庫機能モジュール」「保管機能モジュール」「棚卸機能モジュール」「マスタ管理モジュール」といったサブシステム別にブレークしていく。入出庫機能モジュールは、さらに「入庫」「出庫」「返品」といったサブモジュールに分けられるかもしれない。これはまさに、成果物の構成部品表をイメージしているわけで、ＷＢＳは仕事のＢＯＭ、という表現にぴったり来ると感じられるかもしれない。

ところで、後者のやり方では、一つまずいことがある。それが何か、おわかりだろうか。

成果物単位にＷＢＳをつくると、成果物全体に共通の作業が、抜け落ちがちになる弱点がある。たとえば、典型的な例は「プロジェクト・マネジメント」というタスクがそれである。プロマネの仕事は、ふつう、どれか個別のモジュールには従属しない。あるいは、製品設計ならば、「製品企画」や「市場調査」などもそれである。

前者の方式を、Functional WBS (F-WBS)と呼び、後者をProduct WBS (P-WBS)と呼んで区別することがある。そして、両者の間には、長い論争の歴史があった。

最近、Gregory T. Haugan著「ＷＢＳ入門」（翔泳社・刊）という本が出版されて話題になったが、著者はP-WBSの流派の人だ。彼は長らく米国国防総省の調達対象となるような航空宇宙産業のプロジェクト・マネジメントにタッチしてきた人だから、作るべきモノが最初から明確になっている世界の人だ。航空機は胴体と主翼と尾翼とエンジンからなり・・という風に。

その彼も、この問題点は意識しており、「ＷＢＳでは『プロジェクト管理』を必ずプロジェクト直下の第１階層に置け」という意味のことを書いている。これは一種の現実的な妥協策であろう。もっとも、F-WBS流儀で仕事の構成を作る人たちの中でさえ、ときどき『プロジェクト管理』のタスクが置き忘れられていたりする。だから、これは本質的な弱点とは言えないかもしれない。

私の目から見ると、P-WBSの本当の弱点は、「ＷＢＳのマスタを作りにくい」ことにある。ＷＢＳはプロジェクトのＢＯＭだと考えられる。そして、ＢＯＭは普通、マテリアル・マスタの中から選び出された品目の組合せによって構成される。生産管理の世界では、マテリアル・マスタがまずあって、それからＢＯＭができるのだ。ならば、ＷＢＳを作る場合だって、"Work"のマスタから選び出して組み合わせるべきだ。

成果物は個別プロジェクトでみな異なる。だから、その要素のマスタというのは想像しにくい。しかし、仕事のプロセス自体は、開発対象が在庫管理システムであろうが受発注システムであろうが、大筋にかわりはない。したがって、要素業務のマスタがつくりやすいのである。

要素業務のマスタが作れると、どういう利点があるか。それは、仕事の標準的なデータベースを作れることを意味している。すなわち、プロジェクト計画に置いて最も重要な、工数見積や期間見積に、過去のデータが活かせるということなのだ。これが、F-WBSを用いた場合の最大のメリットなのである。

Haugan氏の「ＷＢＳ入門」の最大の問題点も、そこにある。この著者は、ＷＢＳにマスタが必要であり、それは構築可能だという認識がない。いや、彼だけではない。じつは米国PMIは、そのものずばり"Work Breakdown Structure"というPractice standard（モノグラフ）を出版しているのだが、この中にも、ＷＢＳのマスタという考え方が欠落している。

ＷＢＳを作るならば、マスタが必要である。そうでないと、ＷＢＳの作り方は、プロマネ各人の恣意性にまかされてしまう。このことは、広く理解されるべきであると、私は考える。

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

良いＷＢＳ、わるいＷＢＳ

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

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

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

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

前の「ＷＢＳのつくり方」にも述べたように、ＷＢＳへの分解は大別して、成果物中心と、プロセス中心の方法がある。両者は一長一短あり、成果物中心は“もれなく・重複なく”ワークを数え上げるのには適している（いわゆるMECEな展開だ）。後者はＷＢＳのマスタを作りやすいという長所がある。そして、PMIの本は前者を推薦しているように見える。しかし、この本の付録にあげられた、数々のプロジェクトのＷＢＳ例では、必ずしも、いや、ほとんどがそうなっていない。たとえばAppendix OにはSoftware Implementationの事例がついているが、Level 1をリストアップすると、

1 Project Management
2 Product Requirements
3 Detail Software Design
4 System Construction
5 Integration & Test

という具合だ。私が本の論文に書いた事例のケースとよく似ている。でも、いったい何故こうなのか？

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

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

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

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

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

（末筆ながら、本参考書の編著者である齋藤登志勝先生は本年11月、若干42歳の若さで急逝された。人柄・能力・経験、いずれの点でも惜しまれてあまりある人材だった。先生のご冥福をお祈りしたい）

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

仕事の最小単位−−アクティビティの構造を学ぶ （2010/01/16）

「マネジメント」という行為の、最も原初的な定義は“人に働いてもらう”ことである。人に働いてもらうことで、自己の、あるいは共通の目的を、達成する。自分自身で手を動かして自己の目的を達成することは、マネジメントとは呼ばない。単に作業とか行為と呼ばれる。

あなたがもし食卓で母親に「ねえ、そこのお塩とって。」と言って手渡しもらったら、あなたは、その瞬間だけは、母親をマネジメントしているのである。母親に働いてもらって、自分の目的を達したからだ。でも、何も言わない前に、母親が気を利かせて塩をとってくれたら、もちろんマネジメントしたことにはならない。そもそも、座っているだけで目の前に夕食が出てきたとしても、たぶんそれは母親が自発的に調理をしてくれたのであって、自分がわざわざ命令を下してやらせている行為ではない。はっきりした依頼や指示や命令の有無が、マネジメントと、自発的な協調行動との境界線になる。

「はっきりした依頼」とは何だろう？　まずは、具体的な作業の内容である。なにかをとってもらうという行為は、大げさに言えば輸送の作業である。輸送であるからには、対象物（荷物）、現所在地、そして送り先が必要になる。“そこ”にある“塩”を“（自分の手元に）”とって、という事項を最低限伝えなければ、相手は動きようがない。

それが何かを作る作業だったら？　たとえば玉子を焼いて欲しいとき、具体的に言うべきことはなんだろうか。まず、欲しいアウトプットを正確に伝えなければならない。目玉焼きなのか、厚焼きなのか、錦糸玉子なのか。卵１個分か２個分か、はたまた100個分なのか。味付けは濃いめか薄めか。つまり、アウトプットすべきマテリアルの種類・数量・品質属性を指定するわけである。

ついで指示すべきは、いつまでに欲しいのかである。今すぐなのか、夕食の時でいいのか、あるいは３日後のパーティの時の話をしているのか。つまり納期を指定するわけだ。

さらに、インプットを指定してやる必要があるだろう。材料である。相手が母親ならば、どこに何があるか全て承知している。しかし、アパートを訪ねてきた友人に依頼するときは、「卵は冷蔵庫にあるし、油と調味料は食器棚の横に」と教えてやらなければなるまい。自分で支給できないときは「来るときコンビニで買ってきて」と、相手による調達を頼ることになる。

アウトプットと、納期と、インプット。これだけでいいだろうか？　大事なものが、まだある。『リソース』である。リソースというのは、作業を完遂するために必要な道具や場所や用役のことを指す。フライパンはどこ？　あ、それは流しの下だ。ガスレンジは？　えーと、電磁調理台しか無くてね・・

インプットとリソースの違いは、インプットが作業に使われて無くなる（アウトプットに転換する）のに対し、リソースは作業が終わったら解放されて元に戻ることだ。フライパンもガスレンジも、消えて無くなりはしない。ただし多少減耗する。そしてリソースは、作業中には占有される。つまり、いってみればリソースというのは化学反応における触媒のようなものなのである。

（念のため、注。ここでいうリソースとは、あくまで生産管理やプロジェクト・マネジメントでいう用語であり、「生産資源」などと訳されることもある。資源工学の世界で言う、海の底に眠っているかもしれない利用可能な物質やエネルギー類とは異なる）

リソースの中で、最も重要な種類のリソースは「人」である。作業に必要で、作業中は占有され、作業が終わったら解放される。これを英語で、Human resourceという。直訳すると人的資源だが、リクルートの場面では人材とか人財とか訳され、本社上層の会議室の中では要員・労働力などと呼ばれたりする。作業を終えて解放したときは多少減耗しているので、再生するためには、休ませたり眠らせたり食事をとらせたりお酒を飲ませておだてたりしなければならず、けっこう手間暇のかかるリソースである。

それでもまあ、ある局面では稀少な価値ももたらすことがあるので、大事にしなければならない。君でなきゃダメなんだ、君の作ったのを食べたいんだ・・・。「君の作る味噌汁を毎朝飲みたい。」−−などという陳腐な文句が、いまどき意図した通り機能するかどうかは知らないが、リソースの指定はたいていの場合、重要である。

アウトプットと、インプットと、リソース。そして納期（これはもう少し一般化して、「完了条件」と言ってもいい）。これで完璧だろうか？　じつは、マネジメント上、とても大事なことが抜けている。それは情報である。「指示情報」と「報告情報」のやりとりが必要だ。

指示情報とは、これまで列挙してきたアウトプット・インプット・リソース・完了条件などの伝達である。さらに、必要に応じてはレシピ（つまり設計情報ないし作業手順情報）も渡してやらなければならないかもしれない。もっとも、家族や、同一組織内では、お互いに了解している事項が多いので（これを「コンテキスト・レベルが高い」と形容する）、アウトプットと完了条件だけ指定すれば、あとはくだくだ言わなくても通用するはずである。

報告情報とは、完了時、ならびに（必要に応じ）途中途中で、作業がどういう状態であるか、アウトプットはどうなっているかを、指示した人＝マネジメント主体に対して伝達するための情報である。誰かに働いてもらっているとき、終わったのか終わっていないのかも分からず、どういう状態にあるのかもさっぱり把握できていないのでは、「マネジメントしている」とは到底言えない。「お塩とって」のように、目の前で一瞬にて終わる作業ならば別だが、海を離れたところにいる誰かに２ヶ月かかる仕事をしてもらう際は、報告情報をもらわなければ困ってしまうだろう。

なお、ここまではインプットもアウトプットも物（マテリアル）である場合を記したが、作業の種類によっては、統計分析や企画書作成のように、インプットもアウトプットも情報やデータとなる場合もある。この場合、作業インプットとしての情報・データと、指示情報とは区別して理解すべきである。

ところで、指示／報告情報に関連して一点注意したいことがある。マネジメントにおいて、上記のアウトプット・インプット・リソース・完了条件を指定して依頼した場合は、原則として、依頼を受けた側がどのような手順で進めるか（すなわち相手の業務の「内部プロセス」）については、途中でいちいち口をはさまない。小姑のように、箸の上げ下ろしまでいちいち指示をしてはいけない。マネジメントというのは、際限のない命令-服従関係とは異なる。ある仕事のまとまりを、他者に指示したら、その内部には立ち入らず、相手の権限範囲とする。相手が自発的に改善できる領域を与える。これがマネジメントにおける「仕事の最小単位」の意味である。

プロジェクト・マネジメント理論において、この仕事の最小単位を『アクティビティ』と呼ぶ（「タスク」と呼ぶこともある）。ＷＢＳを作っていくとは、プロジェクト全体を、このようなアクティビティに階層的に分解していく過程を指している。アクティビティはいくらでも下位のサブ・アクティビティに際限なく分解可能だが、適切なレベルでとどめておく（最下位レベルのアクティビティを「ワーク・パッケージ」とも呼ぶ）。

そして、各アクティビティの、アウトプット・インプット・リソース・完了条件・指示情報・報告情報を明確に文書で規定しておく。できればリスト化し、あるいは辞書のようにデータベース化しておくと良い。そして誰でも必要に応じてアクセスできるようにしておく。

このような形でアクティビティを定義しないまま、共通経験の乏しい（コンテキスト・レベルの低い）海外子会社や外注先に仕事を依頼したって、うまく仕事がマネジメントできるわけがない。オフショア開発を上手に進めたかったら、自社の求めるアクティビティをきちんと規定するところから、まず始めるべきなのである。

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

仕事の最小単位（２）−−アクティビティのパフォーマンスを測る（2010/01/26）

アクティビティが『お仕事の最小単位』であり、マネジメントの基本部品であることは前回の説明でご理解いただけたと思う。このアクティビティは、ときに「タスク」と呼ばれることもある。わたしも以前はタスクという呼び名の方を使うことが多かった。だが、プロジェクト・スケジューリング（特にＰＥＲＴ／ＣＰＭ）の理論では伝統的に「アクティビティ」の語が用いられてきたこと、さらにPMIのPMBOK Guide(R)が、activityよりもっと細かな日々の雑務を"daily task"と呼んでいることなどを考え合わせて、このように語法を変えることにした。

ちなみに生産スケジューリングの分野では、アクティビティという語はあまり使われず、ほぼ同じ概念が「タスク」とか「オペレーション」とか、あるいは「オーダー」と呼ばれたりする。もっとも、プロジェクト・マネジメント理論では仕事を中心に、そのインプットとアウトプットとして材料や成果物がある、と捉えるのに対し、生産スケジューリングでは逆に、材料や成果物など（つまりマテリアル）が視点の中心で、その材料を成果物につなげる媒介としてタスク／オペレーションを考える伝統が強かった。つまりモノが主役で作業は脇役な訳である。わたしはこのような物質中心の思考を転換したくて、あえて作業を抽象化した「工順」という概念を中心に据えようとしてきた。

それはさておき、アクティビティに話を戻そう。「人に仕事をしてもらう」がマネジメントの基本であり、その指示する具体的実体がアクティビティである。アクティビティには、必要とするアウトプット・インプット・リソース・完了条件があり、それを明確にして指示を出すわけだ。ところで、その結果として、アウトプットが出てくれば、それだけでOKだろうか？　単に仕事をしてもらうのは必要最低限なことだが、できればちゃんと仕事をしてもらいたいと思わないだろうか？　でも、「ちゃんと」した仕事と、不手際な仕事とは、どこが違うのか。

それを決めるためには、仕事の手際を評価する尺度をもたなければならない。つまり、マネジメントにおいては、アクティビティのパフォーマンス指標が必要なわけである。

アクティビティの評価尺度として、誰もが真っ先に思いつくのはコストであろう。どれだけ低コストで結果を出せるか。たとえば、プロジェクト・チームの立ち上げのために、作業用PCと机を10台ずつ用意する作業をサービス部門に頼むとする。どれだけ費用がかかるかは、たしかに重要なモノサシである。

しかし、コストさえ安ければそれでいい、と考えるほどあなたは単純ではない。もう一つ大事なものがある。それは納期だ。プロジェクト・ルームはなるべく早く立ち上げたい。社内の購買部門にはコストのみが優先事項だと信じている連中も多いけど、たかがPCの価格ネゴに半月かけて納品が1月後では、肝心の仕事が立ち上がらなくなってしまう。つまり、コストと並んで重要なアクティビティのパフォーマンス指標は、『時間』なのである。

コストと時間。少なくともこの二つは、アクティビティを測る必須の尺度となる。つまり、マネジメントはこの2軸を中心に仕事を導く必要がある。

ところで、コストにいったん話を戻すと、費用を考える場合、そのアクティビティを指示する先が、自社なのか、外注先なのか、あるいは自社でも別部門なのかで異なってくる。ここでは一応、自社を前提に考えよう。では、自社のアクティビティのコストとは、本当は何を指すのか。

たとえば、あなたが自分のプロジェクトのテスト工程の一部を、他の部署の誰かに臨時に頼むケースを仮定しよう。ハードウェアのモジュールを10台ほど、出荷前の最終立会検査までに、事前に調整・テストしておかなければならない。計200以上の調整・テスト項目はリストにまとまっており、要領書も作成済みだ。でも追い込みの時期は忙しいので、力仕事に手助けを頼むわけだ。この仕事を、他部門に依頼する。このとき、コストとは何だろうか。

原価管理の考え方では、原価は材料費・経費・そして労務費（人件費）からなる。材料（インプット）として必要なモノは10台のハードウェア・モジュールだが、これは支給するので費用はゼロだ（すでに製造アクティビティで計上済み）。試験器も会社の備品として持っている。問題は隣の部門の人件費である。

人件費のコスト化は、会社の取り決めにも依存する。本社の人件費は全部、一般管理費として丼勘定の中においている企業も、いまだにとても多い。こういう会社では、誰がどれだけ労力をかけようと、見かけ上は「タダ」である。他方、ホワイトカラーの時間をかなり細かく集計している企業もある。後者の場合、サービス部門の人件費も、その作業時間に単価（賃率）をかける形で集計される。

あなたの会社は、とても先進的で（あるいは、とてもケチで）、各人がどのプロジェクトのどのアクティビティで何時間使ったかを、タイムシート上ですべて把握していると仮定しよう。そうすると、これでテスト作業に借り出された人たちの時間数が分かるから、賃率をかけると人件費が計算できる。ちなみに、日本企業のホワイトカラーの賃率は1時間数千円から1万円程度の間が多い（給料の差よりも、オーバーヘッドの乗せ方の基準で大きく差が出る）。

あなたの依頼したテスト項目を全部こなすのに必要な時間は、延べで約100時間だった。二人がかりで1週間ちょっとの作業量である。慣れている自分達がやれば、もっと手早かったのに、とあなたは思う。でもとにかく、2人の人的リソースを、実働で7日近く占有したのである。

必要なリソースの量。これがアクティビティの第3の評価指標なのである。単位は（リソース数）×（時間）で通常は測られる。そして、これに単価をかけると、リソースの費用になる。一方、投入できるリソース量を決めると、アクティビティ遂行に必要な所要期間のベースになる。つまりリソース量は、コストと時間という、2つの主要なパフォーマンス指標をつなげるパラメータとなっているわけだ。

コスト（Cost）、時間（Time）、リソース量（Resources）。仕事の最小単位をアクティビティと呼ぶかわりに、これら三大指標の頭文字をとって、石油メジャーのShellなどでは最近『ＣＴＲ』と呼んだりしている。名は体を表す、面白い言い方である。どこを着目すればいいか、初級マネージャーにとっても明確である。そして、一つの仕事が終わるたびに、これら指標を計測し、前回述べたようなアクティビティの辞書に実績を記録してデータベース化していくのである。ここまで実現できたら、まあ「マネジメント・システム」と呼んでも良いだろうが。

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

アクティビティの問題を解決する二つの方法 （2011/05/13）

マネジメントとは「人に仕事をしてもらう」ことであり、その仕事の最小単位を『アクティビティ』と呼ぶ、ということはすでに何度か書いた。アクティビティを規定する要素としては、アウトプット、インプット、リソース、完了条件（納期）、そして指示情報と報告情報がある（「仕事の最小単位−−アクティビティの構造を学ぶ」参照）。また仕事をちゃんと動かすために、コスト（Cost）、時間（Time）、リソース量（Resources）の3種類を、基本的なパフォーマンス指標として用いるべきことも説明した（「仕事の最小単位（２）−−アクティビティのパフォーマンスを測る」）。

さて、仕事をマネジメントするためには、もう一つ必須の事柄がある。それが問題解決である。どんなお仕事にも、問題の発生する可能性はつねに存在する。アクティビティで問題が発生した時、頼まれた側がすべて自分で即刻解決できればベストだ。だが、そうも行かない場合も多い。問題発生時に、それを解決することは依頼者（指示者）にとって欠くことのできない能力である。これは逆を考えてみれば分かる。自分が仕事上で何か困った事態におちいった時、相談に行っても何も決めてくれず何も助けてくれないような上司がいたら、その人は「管理者として無能」だと言いたくなるだろう。

ところで、仕事上の問題解決には二種類の方法があることをご存じだろうか？　それが、「技術的解決法」と「マネジメント的解決法」である。この区分は、会社ではあまり教えてくれない−−というか、多くの企業では、アプローチに二種類あることを自覚していないのである。

技術的解決とは何だろうか。それは、問題事象に対して、ツール（道具）やメソッド（技法）を用いて対応することである。設計上の不具合ならば修正する。問題の原因が不適切なツールや技法から生じた場合は、それを変更あるいは改良する。たとえ外生的な問題、たとえば材料の急な値上がりの場合でも、廉価な材料への変更や加工方法でのカバー等で影響を押さえ込むのが、技術的解決である。

ではマネジメント的解決とは何か？　それは上述したコスト・時間・リソース量の調整、ならびに情報（コミュニケーション）の整理によって、問題事象がアクティビティのゴールや目標に影響を与えないよう押さえ込むことを指す。この説明ではちょっと抽象的だろうから、具体例を挙げて説明しよう。

アクティビティの担当者が困った顔をしてプロマネに報告に来た。ある装置を組み立てて客先現場に据え付けるアクティビティである。サプライヤーが納品してきた装置用主要部品の材質が指定と違っているのだという。客先の指定は金属材料だったが、実際に納品されたものは樹脂製だったことに今の段階で気づいた。その部分の再製作をサプライヤーに問い合わせたところ、素材の購入から手配しなければならないので2ヶ月かかるという。

この装置自体は、プロジェクトが納める全体システムのコアではなく周辺部分に過ぎないが、現場に設置してデータを集めることによって、コア部分の設計情報に利用することになっていた。だから、このアクティビティが遅れると、プロジェクト全体の納期遅れが生じてしまう。どうしたらいいか、という相談だった。

プロマネは、発注条件がどうなっていたかを担当者に質問した。調べてみたところ、さらに困ったことが判明した。担当者の作成した発注仕様書でも全般に金属製を指定していたのに、サプライヤーから提出された承認図には『樹脂製』と明記されているのだ。図面をレビューした時に、それを見落としたまま承認してしまったらしい。これではサプライヤー側だけのミスとは言えなくなる。再製作を指示したら追加費用も要求してくるにちがいない。

さて、あなたがマネージャーだったら、どう考えるだろうか？

この時まずプロマネがとった行動は、後続するコア部分の設計アクティビティに、追加で人を増員すると宣言したことだった。これにより、設計期間が2週間程度は短縮できる見込だった。無論、金属部品再製作に必要な2ヶ月には足りないが、担当者が少し落ち着いて考える時間は得られた。プロマネは、客先が金属製を指定した意図は何かを、担当者にたずねた。答えは、強度と耐摩耗性でしょう、というのが担当者の意見だった。

翌日、担当者はプロマネのところに解決案を持ってやってきた。強度について文献を調べてみたところ、実際の運転温度では当該樹脂は金属に負けないことが分かった。そこで樹脂部品を表面加工することで、耐摩耗性を上げる。これで客先を説得できないか、と。

プロマネの答えはこうだった。サプライヤーには、金属での再製作を指示しろ。2ヶ月かかってもいい。金額については、自分が交渉しよう。同時に、樹脂加工の案を顧客に説明しに行く。当面、樹脂製で受け取ってもらう。そして2ヶ月後に金属部品ができて来たら、あらためてそれに取り替えさせてもらう。むろん客先には無償でだ。これなら、最終的には要求通り金属製が手に入るのだから、なんとか納得してくれるだろう。

さて、担当者がプロマネに連れられて客先にいき、樹脂製の強度と耐摩耗性の話を説明したところ、相手に「わかった。じゃ、それで納めていい。」と言われて、問題はあっさり解決してしまった。金属部品の再発注の必要もなくなった（プロマネは、この追加費用はサプライヤーと折半に持ち込む交渉をするつもりだった）。

このストーリーを見ると、最終的には「樹脂の表面加工」という技術的解決で、問題は解消したかのように見えるかもしれない。しかし、それ以前に、
・後続アクティビティに要員（リソース）を追加配置する
・そのことによって2週間という余裕時間を作る（これは問題解決のために充てられた）
・サプライヤーの追加発注に費用を準備する
・顧客へのコミュニケーション／説得に筋道をつける
といった、マネジメント的解決を積み上げて、問題の外堀を全部埋めていったことに注目してほしい。

問題の種類や大きさによっては、マネジメント的解決だけで切り抜けられることもある。材料値上げ問題を、契約交渉で解決するなどは、その例である。

ついでながら、プロマネは原因となる事実関係は明らかにさせたが、責任については一言も追求しなかった。責任追及ゲームを始めてしまうと、コミュニケーションや感情がこじれて、問題解決までかえって時間がかかってしまう。いずれにせよ、ミスはいつでも生じうるのだ。そのリスクへの対応のために、時間や予算に予備（コンティンジェンシー・リザーブ）をとっておくことは、非常に大事なマネジメント的解決態度である。

問題に直面した時に、技術的解決を志向するか、マネジメント的解決を探求するか、いずれのアプローチもあり得るし、両者を複合的に使えれば一番良い。だが、技術者という種族は、（なまじ自分の技術に自信があるために）つい技術的解決のみを頭に思い描きがちである。むしろ専門的知識のない人の方が、マネジメント的解決を思いつく。そして、マネジメント的解決というのは、専門分野の如何に関わらず、案外汎用的に使える知恵だということは覚えておいていいだろう。

「技術的バックグラウンドの強い人ほど、どんな問題も技術的に解決しようとしてしまう」とG・ワインバーグは指摘している。技術的に解決できない問題をマネジメントが解決できる場合もあるのである。そのことを、技術畑の出身者は、もっと理解しておくべきではないだろうか。

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

なぜ、人を追加すると納期に遅れるのか？

「遅れているプロジェクトに人を追加すると、もっと遅れてしまう」という言葉は、名著『人月の神話』を書いたBrooksの警句だ。Brooksは1960年代のはじめに、IBMで伝説的な汎用機SYSTEM/360のためのOSである、OS/360を開発したプロジェクト・マネージャーだった。彼が後にNorth Carolinaの大学に移って著した『人月の神話』（Mythical Man-Month）は、ソフトウェア開発のプロジェクトがいかにリスクが高いものであるかを詳しく書いた古典である。

プロジェクトが遅れそうだからといって新たに人を追加しても、その新規要員の教育・知識習得のための立ち上がりの時間がかかるのは、周知の事象だ。しかし、そればかりか、プロジェクト・メンバーが増えると、ふつうはその数の自乗に比例して、要員間のコミュニケーションの時間が増えてしまうため、思ったほど工期短縮には寄与しないとBrooksはいう。

しかし、プロジェクト・スケジュールがある特殊な条件を満たすと、コミュニケーションの因子を抜かしても、要員増が全体スケジュールの延長をもたらすことがある。その特殊な条件とは、(1)要員は多能工で、どのタスクでも担当可能である、(2)要員の手待ちが発生したら、その時点で着手可能なタスクにすぐ着手する、(3)タスクの遂行は途中で中断してはならない、の３点である。いかにも当たり前に思われるこれらの条件下で、いかにしてパラドックスの事象が起こるのか、拙著「革新的スケジューリング入門」の第２章に例示した、下記のアロー・ダイアグラムでPERT/CPMの手法をつかって検討してみることにしよう。

要員２人の場合に、各人の着手すべき作業をガント・チャートの形にすると、下記のようになる。工期は全部で４１週である。

ところで、要員が３人の場合に、同じくガント・チャートを作成すると、次のようになる。つまり、工期は全部で４９週かかり、２人の時よりも延びてしまうのだ。

なぜ、このような現象が起きるのか？　図でわかるとおり、このプロジェクトには、大きくわけて３つのパスがある。図の上段の機器の概念設計から外注製作までのパス、中段のコンテンツ企画から印刷までのパス、そして下段の広告企画・制作のパスである。そして、クリティカル・パスは、図中で赤く示したＡ→Ｅ→Ｉのパスで、合計４１週かかる。これはまさに、２人で実現した工期である。これ以上、いくら人間を投入しても、プロジェクトの工期は短縮されないのだ。

それどころか、人間を３人に増やすと、皮肉なことに、２人の場合は並行して分担することができたタスクＤとタスクＥを、同じ人間が連続して担当せざるを得なくなる。なぜなら、他の２人は「手待ちを許さない」という上記(2)の条件により、別のタスクがすでに入っているからだ。

もう一つ、もっと逆説的な現象がある。このプロジェクトの各タスクの所要期間を、すべて１週ずつ短くしたとしよう。そうすれば、当然プロジェクト全体の工期も短縮するはず−−である。だが、下のガント・チャートを見ていただきたい。そうはならないのだ。工期は全部で４５週になるのである。

これも、「手待ちを許さない」着手ルールのせいである。そもそも、プロジェクトの工期を短縮するには、並列して作業可能なタスクは、極力並行して進めることが鉄則である。PMBOK Guideでいう「Fast Tracking」という技法は、クリティカル・パス上の直列（Finish-Start関係）に並んだタスクを、並列（Start-Start関係）に変えることによって、工期短縮をはかっている。

じつは、上記の例でこの並列作業をするには、要員が着手可能なタスクをあえて置いておき、意図的に手待ち状態で待ち受けていなければならないのだ。

人間を追加投入すれば作業の工数が短縮するというのは、そのタスク群に並列性が高い場合である。そして、並列性を確保するためには、リソースをあえて待たせておける判断が必要なのだ。しかし、多くの組織では、この判断ができない。「稼働率アップ」などのモノサシに動かされて、ローカルな効率を上げようとすると、プロジェクト全体のパフォーマンスを下げる結果になる可能性があることを、管理者は肝に銘じておくべきであろう。

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

所要時間の見積り−−時間と期間の差

スケジュール計画立案の中心は、時間の見積だ。これから行なわなくてはならないタスク（課業）の所要時間をどう見積もるか。この正確さが、計画全体の信頼性を決めるといっても過言ではない。

タスクの時間見積には、一点見積と、三点見積法がある。一点見積とは、文字通り、作業時間を一点で見積もる方法だ。たとえば、「外部インタフェース設計」というタスクがあったとして、その作業時間は３週間、というたった一つの値を、いきなり見積もる。それが過去のデータを整理して求めた値だろうと、あるいは経験者が“エイヤー”で決めた値であろうと、最初から一点で答えを求める方法が、一点見積だ。生産計画手法としてのＭＲＰが、ＢＯＭ（部品表）に付随してもっている標準リードタイムは、その典型だ。

それに対して、三点見積法は、確率的変動に基礎をおいている。同じ作業を繰り返し行なっても、所要時間にはいろいろな幅がでる。そこで、所要時間の「最善値（＝最短期間）」「最悪値（＝最長期間）」「最頻値（＝その期間でおわる頻度が最も高い値）」の三種類の数字を見積もる。そして、
　推定所要時間＝（最善値＋最悪値＋４×最頻値）÷６
という式によって、所要時間を求める。

三点見積法は、ＰＥＲＴの歴史とともに生まれた。その背景には、所要時間はさまざまな外的要因によって変動するため、確率的にしか定まらないという思想がある。しかも、その変動の形は、平均値のまわりに対象に分布する正規分布ではなく、プラス側（右側）にダラ下がりとなる、非対称な分布だろうと考える。その一つのモデルとしてベータ分布を用いると、上記の式が得られるのである。

しかし、この二種類の時間見積法には、ともに欠点がある。それは、総所要期間と純作業時間の区別が十分にされていない点だ。

総所要期間（elapsed time）とは何か。それは、タスクにとりかかってから、それが完了するまでの、全体の期間だ。「総所要期間＝終了時刻−開始時刻」と定義してもよい。一方、純作業時間（duration）とは、作業者がそのタスクを完遂するために、本当にそれにかかわっている時間だ。前者は後者よりも、通常長い。総所要期間≧純作業時間となるのが普通だ。

それでは、なぜその両者に差が出るのか。プロジェクト・マネジメントの教科書的ガイドブック「PMBOK Guide」では、コンクリートの養生作業を例にとって、実質２日間のdurationで終わるはずの作業も、金曜日に始めたら週末の二日間の休日のために月曜日いっぱいかかり、実質４日間のelapsed timeになるかもしれない、などと説明する。これは、カレンダー日数と、終業日数の違いから来る、単純な例だ。

しかし、差異の本当の原因は、じつは作業者のマルチ・タスキングから来ることが多い。作業者が複数のプロジェクトのタスクに従事しているとき、おのおののタスクに着手から完了までつねに没頭できるケースはまれである。往々にして、別のプロジェクトの用件の邪魔が入り、作業を中断したりスイッチしなければならない。このために、総所要期間≧純作業時間となるのである。

かりに一歩譲って、マルチタスクによる割り込みや時間の分散がなく、担当者がつねに一時に一つのプロジェクト・タスクに従事したとしても、総所要期間≧純作業時間　となる場合がある。それは、その担当者の決済箱にたくさんのタスクが入ってきて、処理待ちの行列を作っているときである。

これはちょうど、大病院は３時間待ち・３分治療だ、という皮肉と同じ現象である。一人一人の患者に対する医師の作業時間は３分だ。決して複数の患者をマルチタスク的に並行して診ているわけではない。しかし、大勢の待ち行列のために、患者の側から見ると作業期間は３時間になってしまう。

プロジェクトにもこれと同様の事象がおこる。特定の繁忙部署やボトルネック工程の前には、長い行列ができている。ＰＥＲＴ／ＣＰＭの弱点は、ここだ。クリティカル・パスは純作業時間ではなく、総作業期間の長さで決まる。しかし、この例のような状況では、一つのプロジェクトの中だけを見ても、クリティカル・パスは定まらない。かといって、『平均滞留率』のような曖昧な指標にたよるのも、ありがたくなかろう。

プロジェクト・スケジューリングにも、複数のプロジェクトを同時に計画し、うまく優先順位法や山崩しのできるツールが求められているのは、このためなのである。もっともその場合でも、プロジェクト間のトレードオフは、計画者の判断が必要になるのであるが。

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

パフォーマンス基準時間の概念 （2009/07/17）

オフショア開発が米国のIT業界で広まりはじめたのは、いまから10年ほど前のことだったと思う。当時私は、米国の制御システム・インテグレータをつかって、メジャーオイル向けに工場のDCSとMESを納入する仕事をしていた。私のグループはMESを担当し、隣の部の同僚たちはDCSを担当して、それぞれ仕様をとりまとめ、同じ米国のインテグレータに詳細設計と実装をさせるやり方をした。彼らはMESの方は米国内のサブベンダーをつかってとりまとめ、一方DCSの制御ソフトはインドの子会社をつかって開発していた。とはいえ、彼らにとってもインドのリソースを使うのは初めての挑戦だったらしく、おかげで納期の面でも品質の面でもかなり苦労をさせられた。

その2，3年後、私はフランスの会社と共同で電子調達サイトの仕事をしていた。こちらの方は、米国の最大手ERPベンダーが基本テクノロジーの提供者だった。シリコンバレーの本社で相手のディレクターと何度か話し合ったが、彼が「インドをつかえ。」としきりに強調していたのが印象に残っている。このころはちょうど米国のITバブルが崩壊した直後で、米国に出稼ぎに来ていたインド人技術者がかなり本国に帰っていた時期だったと思う。このころ、我々の会社も、社内システムを作るために、インドのIT企業をつかってオフショア開発をはじめていた。ちなみに、'90年代後半にはすでに、エンジニアリング業界ではプラントの詳細設計業務をアジアの子会社にやらせるようになっていた。

それからさらに3年後、私は中国に子会社をもつ日本のIT企業と一緒に、システム開発のプロジェクトを進めることになった。日本企業の間で中国でのオフショア開発がブームになり始めたのは、ちょうどその頃ではなかったか。中国人はチーフ・クラスでもなかなか英語が通じず通訳・翻訳経由となるので閉口したが、近くて時差がほぼないため会議がやりやすい（あるいは現地に乗り込みやすい）というのはメリットだった。

オフショア開発やオフショア設計にはいろいろなパターンがある。が、発注形態の面で見ると、大きく2種類に分けられる。一括発注（ランプサム契約）と、工数精算（マンパワー・サプライ契約）だ。海外のSIerに仕様を与えて、できた製品を受け取るのは、前者のやり方だ。海外子会社に設計や実装段階の仕事を分業させる場合は、後者の形態が多い。両者の最大の違いは、マネジメントの責任、とくに工数管理の責任が、発注側にあるのか受注側にあるのか、にある。

一括発注の場合は、いうまでもなく、工数管理の責任は受注者側にある。最初に、仕様と金額と納期を決めたら、あとは品質をみたす製品を納期通りにおさめる責任は相手側にある。見積を間違えて大勢を追加投入するハメになっても、受注側は自己負担するしかない（発注側に仕様変更等の不手際がない限り）。この点、発注先にしっかりとしたマネジメント能力がありさえすれば、一括発注はある意味で気楽だと言えるだろう。そして大事なのは相手側のマネジメント能力を評価する手法ということになる。

一方、工数精算の場合は、マンパワーの追加投入の事態が生じたとき、責任は主に発注者側にあると考えられる−−受注者側によほどの非効率がない限り。そう。そしていつもトラブルの種になりがちなのは、この効率の問題なのである。

マンパワーの効率とは何だろうか。それはすなわち、人時あたりの生産性である。同じ仕事を、Aさんがやったら1時間かかり、B君がやったら3時間かかる、としよう。このとき、AさんはBさんの3倍の生産性があることになる。

生産性とは、（前にも書いたが）次の式で定義される（等幅フォントで見てください）。
　　　　　　産出量
　生産性＝−−−−−
　　　　　　投入量

同じ産出量（成果物）に対して、投入する人時が3倍になったら、生産性は1/3になる。きわめてシンプルな式である。

では、海外子会社に分業で仕事をさせるとき、必要な人時はどう見積もるのか？　当然、生産性の概念が必要になる。このとき、日本の親会社でやれば 500人時ですむはずの仕事を、その子会社でやるときは、生産性が（たとえば）0.5倍なので1,000人時の工数がかかるだろう、という計算になる。この上さらに、子会社の進捗コントロールやコミュニケーションのために、親会社側で必要になる「マネジメント工数」が加算される。それでも、『給料の高い日本人』を使うよりはずっと安い、浮いた時間はもっと高度に知的な作業につかえる、という計算が成り立つから、海外との分業を選んでいるはず、なのだと思う。

これが成り立つためには、二つの条件が必要だ。まず、子会社の生産性の測定方法。そして、「最善の生産性でやったらxx人日かかる」という、工数見積の基準である。これをパフォーマンス基準時間の概念と私は呼んでいる。

SEやプログラマの生産性は人によって3倍以上も違う、という話をIT業界ではよく聞く。この業界の人が好きな話題らしい。そうかもしれないな、と私も思う。ところで、その個人別生産性の具体的な数表を、私は一度も目にしたことがない。ウチの会社では、生産性の個人差は最大4.7倍もありました、というような定量的な話をついぞ聞かないのである。まあ、これは私の見聞の範囲が限られているからかもしれない。たいていのまともな会社は生産性についてきちんと測定していて、ただ社外秘だから出せないだけなのだろう。

ところで、基準となる工数見積の方は、どうだろうか。上の式を見てほしい。これを計算するためには、産出量（作業量）を測る尺度＝ＢＯＱが必要である。産出量がこれこれで、基準生産性がこの値だから、基準工数は何人時になる、という計算になる。これは、実装だとかテストといった「力仕事」の場合、計算しやすい。だが詳細設計やデザインの場合、それなりの工夫が必要である。

そして、よく見かける間違いは、ここにマンニング計算を用いてしまうことだろう。マンニングというのは、縦に職種、横に週や月の並んだ表を作って、“だいたいこの時期は何人が必要になるはずだから〜”と数字を入れ込んで人時を集計する方法である。これでは、作業量の基準として工数をとっていることになってしまう。だから、マンニング計算は体制表のチェックには有用だが、工数見積の根拠にはならない。工数を作業量と生産性に分解する。工数自体は仕様で決まるため、簡単には変えられない。だが、生産性は向上させることができ、それが競争力の源泉となる。

こんな当たり前のことをわざわざ書いているのは、生産性という概念が、製造現場を離れると、忘れられやすいからである。デザインは非定型的な仕事なので見積もれません、みたいな主張が、すぐ現れてくる。だが、見積もれない仕事に、企業は給料を払える訳はない。もし競争力を向上したいのなら、多少強引にでも時間と生産性を測るべきなのだ。測れないものは、カイゼンできないからである。

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

ベーシックとしての時間分析 （2009/09/28）

私たちは時間の上に住んでいる。誰にも平等に、1日24時間が与えられ、週に7日、年に12ヶ月が与えられる。資産や所在地や名望など、他のありとあらゆるビジネス上の前提条件とは違って、そこにはハンデも優劣もない。

したがって、私たちが何ほどかを競争で得たければ、まず時間の使い方で競うしかない。ところが、これほど無頓着になされているものも珍しい。経営資源を「人・モノ・金」と三つにくくるのは、誰がはじめたか知らないが広く浸透していて、事実、人やモノや金の使い方には、皆ずいぶん気をつかっている。それに比べて、時間の使い方に対する注意は格段に落ちる。たぶんそれは、時間が目に見えないからだ。

経営工学（あるいは、その基盤であるインダストリアル・エンジニアリング＝ＩＥ）が、テイラーの『科学的管理法』の論文から始まったことは周知の通りだ。今からちょうど100年前、工場の主任技師だった彼は、労働者による重い荷物の運搬作業に対し、ストップウォッチによる時間計測を手段にして、適切な休息と労働のバランスによって生産性が飛躍的に向上することを見出した。同じ8時間という労働（拘束）時間の中の使い方をかえることによって、劇的な改善が可能になったのだ。それは号令や叱咤やインセンティブ等よりも、はるかに効果的だった。だから、彼はこれを、自信を持って「科学的管理法」と名付けたのだ。

テイラーの流れをくむＩＥ技術者たちは、その後も工場の現場作業に対して、ストップウォッチを武器に取り組みつづけ、地味ながら立派な成果を上げつづけた。さらに人間動作を詳細に分解して、標準動作による生産性予測や改善もできるようになった。今日、まともな工場ならば、ＩＥ技術者による作業設計と不断の改善活動を定常的に行っている。

しかしながら、日本の製造業の多くの企業では、生産性のボトルネックはすでに製造現場から、設計や管理を中心とするオフィスワークに移っている。にもかかわらず、オフィスワークにおける作業時間分析は、あまり行われているのを見たことがない。不思議ではないか。

いや、我が社はタイムシートをつけている。何月何日に、どの仕事で、何時間働いたかはすべて正確に把握している−−そう反論されるかもしれない。しかし、それでは不十分なのだ。時間分析には、目的別の分析と、様態別の分析と、そして機能別の分析があることを、多くの人は理解していない。タイムシートは、目的別の時間集計には使えるだろうが、様態や機能の分析にはすぐには使えない。

目的別の時間分析とは何か。それは、「その作業時間」が、どの顧客・案件・段階向けの作業かを見るための手段だ。A社向け・Zシステム納入・テスト段階−−これが目的別の分類である。気の利いた企業なら、作業段階別にＷＢＳやコード番号を設定しているかもしれない。例えば、テスト段階の中でも「テスト要領書の作成」まで把握できるようになっている。でも、これでは時間の使い方の“結果だけを知る”ことしかできない。いわば、タクシーが、どの客を連れて、どの目的地まで行き、何ｍを走ったかだけを記録しているようなものである。

もし時間の使い方の内実を知りたければ、様態別の把握をしなければならない。たとえば、同じオフィスワークでも、会議に出席していたのか、設計書を書いていたのか、メールを読んでいたのか、電車で移動していただけなのか、いろいろな様態がある。終日会議に出席しているばかりの人や、一日の半分以上は移動時間の人が、生産性に貢献すると期待できるだろうか？　会議も移動も、必ず『目的』はある。どの案件・どの客先かは（たぶん）明確である。でも、それはタクシーが渋滞の中につかまっているようなものではないか。だとしたら、高速か、一般道か、裏道か、どんな道をどれだけ通ったかの分析が必要なのだ。

そして、様態別の分析だけでも、まだ生産性を考えるには十分ではない。なぜなら、仕事に使う時間の中には、プロダクト（成果物やアウトプット）に直接結びつく部分と、そうでない部分が混ざっているからだ。たとえば机に向かって設計作業中だとする。ところで、以前もらった資料のファイルをさがして、サーバの中をあちこち検索したとしよう。ある目的のために仕事をしている時間であることに間違いはない。だが、そうした探し物の時間は、実際には生産性に何も貢献していない。あるいは、上流部門から来た要件設計書に間違いが見つかって、設計がやり直しになり、残業したとしよう。あきらかに設計活動の時間だ。だが、ちっとも生産的ではない。こうした時間は、タクシーが道を間違えて引き返したり、地図が無くてうろうろしている時間とかわりがない。

製造現場では、「正味時間」という概念を大事にする。部品を加工したり、組み付けたりして、モノに付加価値を与える作業の時間である。旋盤でワークを削っている時間は正味時間だ。一方、治具が無くて探しに行ったり、加工図面の到着を待つ間に機械の掃除をしている時間は、正味時間に入らない。無論、材料の入荷待ちやロット待ちも、正味時間外だ。そして、工場での改善のポイントは、いかに無駄な待ち時間を無くして、正味時間の比率を上げるかにある。念のために書くが、正味時間の比率はせいぜい数％から、よほど優秀な工場で20%程度である。あとはほとんどが、付加価値に貢献しないムダ時間なのだ。

同じようなことをオフィスワークで知るためには、目的別タイムシートではなく、様態別・機能別の時間集計が必要になるのである。むろん、こんな細かな作業記録を、毎日毎日タイムシートにつけることなど不可能だ。だから、サンプリング期間を区切って（例えば1日とか1週間とか）、職場全体で調査をかける必要がある。そうしてはじめて、本当の意味で「付加価値生産性」向上のための基礎データができるのである。そのために、どのようなフォームやツールがいるのか、知恵と工夫のポイントでもある。

とはいえ、もしかしたら、タイムシートそれ自体、目的別の時間集計にも使えない状態だということも考えられる。タイムシートが残業集計や給与計算に直結している場合である。いや、もちろん直結してもいい。だが、そこにみなし年俸制やら「サービス残業」やらがひそんでいると、もはやタイムシートは監督官庁へのアリバイ資料にすぎず、ビジネスの改善の基礎データにもならなくなるだろう。そんな状態は、ごく例外的な事象だと信じたいものであるが。

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

期日つき督促の矛盾と『学生シンドローム』 （2009/11/15）

『督促』というのは嫌われる言葉だ。される側にとってはうるさいばかりか迷惑千万に感じられ、する側だって楽しくない。この言葉を『催促』と言いかえてみても、もちろん同じだ。鬱陶しいものであることに変わりはない。

「督促する」を英語ではexpediteという。ところで、私の働くエンジニアリング業界には、Expeditorという専門職種がある。日本語に直訳すれば、「督促者」だが、この恐ろしげな名前の人たちは何をする人たちなのだろうか。まさか鞭を持ってオフィス内を歩き回り、人を後ろから怒鳴りつけるのだろうか。

実際には、エクスペダイターは、外注先の工場を定期訪問し、その進捗状況をコントロールする仕事をしている。日本語での名称も、「工程管理」という、もっと受け入れやすい穏和な(?)肩書きをつかう。

エンジニアリング会社は、客先のために工場を設計し、機械や資材を調達し、建設工事を管理することが仕事である。そして、工場に使う産業機械や資材はほとんどが個別仕様による発注品だ。作るメーカーの側から見れば、設計作業を伴う個別受注生産品（英語で言えばETO＝Engineer to Order）ばかりである。こうした品目は、受注したらひょいと製品倉庫の棚から出して発送するような見込生産品と違い、納期が長くかかる。いや、標準納期すら存在せず、毎回、受注のたびに個別に納期を設定せざるを得ない。

しかも、受注してからすぐに工場で作り始めるわけではなく、まず設計部門で設計し、外形や重量や機能構成を「承認図」の形でまとめて、いったん発注者に提出し、承認を得る必要がある。それから部品表（ＢＯＭ）と製作図面の出図にうつる。これだけで２，３ヶ月はあっという間に経ってしまうのが普通だ。部品表にしたがい、主要材料を手配し、納入されるのを待つ。工場側の生産計画にスケジュールを載せる。それからやっと、工場で材料を刻みはじめるのである。さらに組立があり、出荷前性能検査があり、塗装梱包されてようやく出荷となる。

これだけのプロセスを経て進む作業である。まさか発注書を切ったあとは目をつぶって待っていれば、納期の日に、目の前に自動的に製品が忽然と現れる、などと期待する方がどうかしている。ましてエンジニアリング会社の調達先の7割以上が海外メーカーである。Amazonで本を1冊買うのとは訳が違うのだ。

そこでExpeditor＝工程管理の専門家の必要が出てくる。彼らは、発注先の工場を定期的に訪問する。そして、設計工程や生産工程が予定通り進んでいるかをモニターするのである。メーカーの設計部門が必要とする仕様書や技術図書の最新版が、全てそろっているかどうか（しばしばエンジ会社から営業部門に渡してもタイムリーに技術部門に渡っていかない）、技術上の懸案事項が残っていないか、主要部材は発注したか、工場はちゃんと製造能力に余裕を持っているか、検査要領の手はずは整っているか、等々をくりかえし確認するのである。

このプロセスはある意味で、外注先ではなく社内の他部門に仕事を依頼した時も、同じはずである。製造依頼ばかりとは限らない、設計の依頼でも、なんらかの検討の依頼でも同じである。スケジュール通り仕事を進めたければ、相手側の内部の進捗についても、モニターしていく必要がある。そして問題が発生していれば、タイムリーにそれを検知し、都度解決していかなければならない。むしろ、同じ社内であるほど、「発注書」や「契約書」が存在しないだけに、気をつけなければいけないはずだ。

ということは、社内の他部門に対しても、工程管理の仕事が必須ということになる。しかし、他部署の内部プロセスに口を差し挟むのは、現実にはなかなか困難である。そこで、妥協案として、依頼事項に提出期限をつける、という方法が普通は採用される。この日までにやって下さいね、よろしく、と頼むわけだ。

しかし、この方法には一つ、大きな欠点がある。それは、期限を自分の都合だけでは決められないことだ。相手側の事情も含めて、社内調整が必要になる。こちらは月末までにほしい。でも、相手は他の通常業務もあるので、来月中旬でないと約束できない、等々といった話し合いである。

そして、いったん両者の間で期限が合意されたら、成果物はその期日より前に届けられる可能性は極めて低くなるのが、現実だ。なぜなら、そこに『学生シンドローム』が働き始めるからだ。

学生シンドロームとは、小説『ザ・ゴール』の著者で、制約理論（ＴＯＣ）の創始者であるエリヤフ・ゴールドラット博士が言い出した言葉である。彼は、夏休み最後の日にならないと宿題に手をつけない学生達を引き合いに出して、人はいったん将来の期日を与えられると、すぐにそのタスクに着手しないで、ぎりぎりまで後回しにしがちである、という。それでも期日に間に合えばいいじゃないか、と依頼を受ける側としては当然思うだろう。しかし、いったん期日を設定してしまうと、学生シンドロームのために、それより前に仕事が終わる可能性は極めて小さくなるのである。

期限にはもう一つ問題がある、とゴールドラット博士はいう。期限を設定する時に、依頼を受ける側は、約束をほぼ守れるように、それとなく期間にサバを読んで長く言いがちになる点である。2週間でたぶんできるな、と内心思っても、それを万が一守れなかったら責められる、じゃあ4週間といっておけば安心だろう、となる。

かくして、社内で複数部門を巻き込んだ仕事（つまりプロジェクト型の仕事）をやろうとすると、あちこちに水増しされた社内期日が設定され、全体工程が長くなってしまう結果になるのである。部分的な期限をつけたが故に、全体が長くなる矛盾が生じるのだ。

では、この問題を解決するにはどうしたらいいか。彼はそこで、あっと驚く解決策を提示する。だが、長くなってしまったので、続きはまた書こう。

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

早期着手かジャストインタイムか （2009/11/23）

期日を決めた督促には、副作用がある。それが『学生シンドローム』と呼ばれる現象である、と前回書いた。学生シンドロームとは、期日ぎりぎりになるまでタスク（アクティビティ）に着手しないで放っておきがちになる、人間の性（さが）みたいな事象である。

もう一つ、人間には悲しい性がある。それは、怒られるのが恐いためにサバを読みがち、という傾向である（・・どうでもいいが、この「性（さが）」って言葉をくりかえし使っていると、なんだか昼のメロドラマの解説みたいになってくるな）。

期日を約束しても、それを守れないと、相手に（そしてたぶん上司にも）怒られる。怒られたら、うれしくない。今度の査定に響くかもしれない。だったら遅れなければいいだろ！、というのは上司の側の論理である。現実にはいろいろな割り込みやトラブルや掛けもち仕事があるじゃないですか。だったら、10日で終わりそうな仕事でも、「20日かかります」とサバを読んで申告しておけばいいか。そうだ、そうしておこう・・

こうして、異なる部署間の期日の約束事には、しばしば余裕日数（サバ）が入り込んでくる。期日は依頼する側が一方的に決められないしきたりだ（当然だが）。タスクを請け負う側の都合や自己申告にあわせる必要がある。

ほぼ同じ種類のタスクを繰り返した場合でも、着手から完了までの所要期間には、いろいろな幅（ばらつき）が出てくるものだ。なぜ、タスクの所要期間に幅が出るのか。理由はさまざまである。ほかとの掛け持ち仕事（マルチタスキング）のために、一部の時間しかさけない、というのが最もありがちな理由であろう。急な割り込み、というのもよくある話だ。必要なインプットの情報や材料の到着が予定より遅れる（上流側の遅れの影響を受けた）、というケースだってある。というわけで、ホワイトカラーの仕事というのは、工場で部品を旋盤で削る仕事と違って、数量×単位時間あたり生産性＝所要期間、みたいなスケジューラ的計算は成り立たないのである。と、広く信じられている。

さて、そこで問題です。作りすぎのムダを排除する「ジャストインタイム」（JIT）については、このサイトの読者なら誰もが聞いて知っておられると思う。JIT生産では、作りすぎによる在庫のムダをさけるため、必要な時になるまで作らない。つまり、ぎりぎりまで待って着手することを良しとしている。

その一方で、できることは先に着手するべし（「今日できることを明日に延ばさない」）というポリシーも、よく耳にする。じっさい、『学生シンドローム』を避けるには、後回しにするな、可能ならすぐ着手すべし、と主張したくなる。

では、この二つの指針は、どちらが正しいのか？

この問いかけは、拙著「革新的生産スケジューリング入門―“時間の悩み”を解く手法」でも書いた問題である（第1章『いつ宿題をやるか−−最早着手と最遅着手』参照）。スケジューリング理論では、ＥＰＳＴ（Earliest Possible Start Time：最近ではESとも略す）とＬＰＳＴ（Latest Possible Start Time：LSとも略す）という二つの重要な概念があるが、前者は「着手可能になった時点ですぐに」、後者は「納期に遅れずに済むぎりぎりの時点で」仕事を始める日時、をそれぞれ指すのである。だから、上の問いかけは、こう言い直すこともできる：仕事はLPSTで着手するのが正しいのか、EPSTで着手するのが正しいのか？

この問題が生じるのは、EPSTとLPSTの日時が異なるからだ。EPST=LPSTならば、どちらかを選ぶ意味はなくなってしまう。ではEPST=LPSTとなる状況とは？　それは、クリティカル・パスに乗っているアクティビティである。あるいは、ボトルネック工程にある作業である。これらのタスクでは、上記の問題に悩んでいる余裕はない。最速で仕事をするしかないからだ（ジャストインタイムが徹底している工場では、ほぼ全ての工程がボトルネックに同期化されるよう設計されている）。

問題は、EPST<LPSTとなる場合である。LPST-EPSTのことを『フロート日数』と呼ぶわけだが、つまりフロート日数のある仕事はどちらが正しいか、ということになる。で、どちらだろうか？

こうした質問を受けたら、反射的に考えるべき事がある。それは、“「正しさ」とは、何のモノサシで測るかによってちがう”、ということだ。

もし「仕掛り在庫低減」がモノサシの場合、当然ながら最遅着手（JIT生産）が正しい答えである。ただし、これできちんと仕事を回していくためには、当然ながら所要期間のばらつきをかなり小さくできている、という前提条件がついている。それなりの作業習熟度（成熟度）が要求されるのである。

逆に、一刻も早く製品ないし成果物を出荷することがモノサシの場合、当然ながら最早着手が正しい答えになる。そして、各タスクは可能なかぎり早く完了させる。完了したら、すぐ次のタスクにバトンタッチさせる。実際には早く終わったのに、報告しないでおくようなことはさせない（なぜそんな事が起きるかといえば、「サバを読んで期日を約束しておいたため、現実は早く終わったのだが、ここで正直に報告すると、次回から短い期日を約束させられるだろう」などと憶測する“頭の良い”人たちが出てくるからだ）。

ついでにいうと、納期遵守が受注後の唯一のモノサシの場合も、最早着手が正解ということになる。これは、じつは顧客に怒られたくない営業部門の場合の論理である。その結果、仕掛り在庫という社内のコスト＝利益率低下は不問にされるわけだ。営業部門の目標は売上高であって、利益率は工場の責任である、と考えているような組織では、こうして「早く早く」のかけ声が社内を駆け巡る、という状態になりがちなのである。

ということで、つい寄り道をして、ゴールドラット博士の「画期的な解決法」について書くつもりが、今回もまた書けなかったようだ。続きはまた、ということで。

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

時間のムダとり−−スケジュールのサバを切り捨てる （2009/12/07）

締切（納期）のある仕事をする時には、できるだけ早く着手するべきか、あるいはぎりぎり間に合うタイミング（ジャスト・イン・タイム）に着手するのが正しいのか。その答えは、スケジューリングが何を主目標とするかによって違う、と前回書いた。もし顧客が納期遅れを嫌うのみならず、予定より早く納品されることも好まないような場合、あるいは、自社内の仕掛在庫や作りすぎのムダを極小化したい場合は、ギリギリのタイミングで作るのが正しい。しかし、早く出荷すればするほど競争に有利な場合や、成果物が情報のように保管場所をとらず材料の仕入れも無い場合などは、最早着手が望ましい、ということになる。つまり、ケース・バイ・ケースなのである。

「正しい答えはどれか？」という問いをビジネスで出された場合、あわてて答えを出さずに、まず、“正しいとは、誰にとって（あるいは、どのモノサシにとって）の話だろうか？”と逆に自問すべきである。私たちは学校時代から「正解はどれですか」という出題に慣れすぎている。正解がただ一つだけあると、みな思い込みがちだ。だが、ふつうの社会には、望ましい答えが場面に応じて複数ある。なぜなら、企業活動はさまざまなトレードオフ関係で満ちているからだ。「短期的利益 vs. 長期的安定性」はその一例だし、「在庫低減・対・リードタイム短縮」もそうだ。いや、複雑な協働システムでは、トレードオフが本質的に付随すると言ってもいい。隠れたトレードオフを見抜けるかどうかが、マネジメントの能力として問われている。

そうしたトレードオフを見逃す危険性は、「納期設定」という行為自身にも内在している。他者に早く仕事をしてもらうためには、納期を示して合意する必要がある。しかし、いったん納期の合意ができてしまうと、その相手は納期に間に合うようにギリギリまで着手しないようになる。納期より前に完了する可能性は逆に減ってしまう。これを『学生シンドローム』と呼ぶわけである。だからといって、納期無しで仕事を依頼したら、いつまでたっても完了しない可能性がでてくるだろう。

学生シンドロームが生じるのは、（スケジューリング理論の用語でいうと）フロート日数を持つアクティビティに限られる、と前回書いた。フロートとは余裕日数のことである。納期マイナス作業期間、と考えても良い。しかし、正確にいうと、もう一つのケースがある。それは、作業期間自体に余裕が隠されている場合である。「サバを読む」と俗に言うが、合意された賞味作業期間の中に、サバ（ムダ）が入ってる。そのようなケースは、アクティビティの作業期間に大きな幅（ばらつき）があるときに起きやすい。

もともと、どんなアクティビティでも、必要な正味作業期間にはばらつきがある。それが3週間±1日、といった程度の幅なら、かなりばらつきが小さいと言えよう。しかし、最短で1日、最長で3週間、平均で1週間、といった状態だと、必要な期間の読みが難しい。このようなときに、サバが入り込むのだ。納期を約束する側に立てば、平均で1週間と言っても、ときには2週とか3週かかることもあるのを知っている。3週間かかるケースは全体の10%くらいだとしても、「作業の納期はいつにしますか」と聞かれたら、「3週間後」と答えたくなるだろう。平均値は1週間なのに。

もちろん、平均値の1週間を納期で約束してしまったら、どうなるか。2回に1回は、納期に遅れる可能性があるわけだ（正確に言うと、平均値ではなくメディアン＝50パーセンタイル値で、半々となる）。いずれにしても、それではメンツ丸つぶれである。そこで、安全確実な90パーセンタイル値の3週間をオファーすることになるのである。こうして、平均すると2週間のアイドルタイムが、プロジェクトの中に発生してしまう。

どうしてこうなるのか。根本原因は、企業内において「納期遅れは罰せられるのに、納期より早く完了しても報酬が与えられない」という事にある。すなわち、納期確約についての評価が非対称で、遵守時の報酬体系が無いからなのである。これは外注や購買においてもしばしば同じだ。

ということは、もし仕事を早く進めたいなら、「早く終えたら得をする」という環境や約束をつくることが大事だとわかる。と同時に、納期を決める時は、安全確実な90%値ではなく、平均の50%値をもとに基準を設定すべきなのである。とうぜん「遅れたら罰する」方は、少し弱める必要がある。

90%値と50%値の関係は、ばらつきの分布の形に依存するので、一概には言えない。分布の統計を取って変動係数（σ/μ）が分かれば少しは判断の参考になるし、あるいは最小値・最大値・平均値の組でもいい。ただ、90%値は50%値の3倍程度になりがちだ、と考える人も多い。

このことを根拠に、プロジェクトの納期設定のあり方に全く新しい思想を持ち込んだのが、ＴＯＣ理論の創始者ゴールドラット博士だ。彼は、クリティカル・パスに属するアクティビティの所要期間は、すべて50%値で設定しろ、と主張する。むろん、そんなことをすれば、プロジェクト全体が納期を達成しない確率が50%になってしまう。そこで、彼は適正な日数分をプロジェクト末尾において、「プロジェクト・バッファー」とし、これで納期達成率を上げるべきだ、と主張する。

そのバッファー日数であるが、通常の90%値で計算した納期（たとえば10ヶ月だったとしよう）から、50%値で計算した納期（こちらは4ヶ月だとする）を引いた差の半分をとれ、というのが彼の提案である。この例では(10-4)÷2＝3ヶ月である。で、結局、全体では4+3＝7ヶ月の工程とするのである。これがＴＯＣ理論で言う「クリティカル・チェーン・プロジェクト・マネジメント」の根幹のアイデアである。

ゴールドラット博士の思想を、私流に言いかえると、次のような手順になる。

（１）冗長な部分をみつける
（２）それを捨てる（正味分のみにする）
（３）必要最小限の冗長性を付け加える

これは、実は情報理論やデータ通信で行っている技法と全く同じだということがおわかりだろうか。情報から冗長な部分を見いだし、それを取り去る（情報圧縮）。そして最小限の冗長性をあえて付加する。これは外乱・ノイズから情報を守るための技術なのである。

同じ考え方は工程（スケジュール）にも、そしてコストにもつかえる。というか、使わなくてはならない。これが、マネジメント・テクノロジーというものの典型的な姿なのである。

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

バッファー・マネジメントとは何か （2010/07/31）

プロジェクトの計画作業は大きく二段階に分かれる。前半はスコープ定義で、プロジェクトを構成するアクティビティを洗い出し、達成すべき仕事の範囲全体を網羅しカバーする。このアクティビティを階層的に構成して整理番号を付番したものがＷＢＳである。後半は、各アクティビティに必要なリソース・時間・コストを見積り、アクティビティの順序（論理的関係）にしたがって、ロジック・ネットワークを作成する。これがプロジェクトのタイム・テーブル（工程表）のベースとなる。これがスケジューリングである。

プロジェクトを表すアクティビティ・ロジック・ネットワークの始点から終点までを結ぶさまざまな経路のうち、最長のものをクリティカル・パスと呼ぶことはよく知られている。プロジェクト全体の所要期間（工期）は、クリティカル・パスよりも短くすることはできない。ここまではまあ、ある意味で基本である。

さて、プロジェクトの期限ないし納期設定を考える時、そこに自由度がある場合と、外部から制約条件として与えられる場合がある。受注ビジネスの中で生きている人は、「納期とは客先から与えられた制約条件だ」と考えることが多いだろう。契約によっては、納期遅延に対してペナルティ条項がついていることもある。そうでなくとも、納期に遅れたら信用を失い、次の受注機会には不利になる、と考えられる。

一方、新製品開発のように、自社が発案した自発型プロジェクトでは、納期はある程度、自ら設定できる。なお、英語では自発型プロジェクトをInternal Project、受注型プロジェクトをExternal Projectと呼んで区別する。ただし、自発型であっても、新製品の納期が展示会やフェアーなどの期日にしばられることはある。あるいは、対外発表の時期が、上からぽーんと鶴の一声のように下りてくることもあろう。いずれにせよ、自発型の場合、納期に多少の自由度があるケースが多い。

さて、自分が納期を設定できるときは、クリティカル・パスの長さで決めるべきだろうか。たとえば、クリティカル・パスの長さが120日ならば、納期は120日と宣言して良いだろうか。答えは、NOである。なぜなら、クリティカル・パスの長さとは、プロジェクトが達成可能な『最短の期間』だからだ。計画段階ですべてを見通すことはできない。いろいろと予期せぬ事やらミスやらが、途中で生じてくるものである。こうした外乱・内乱(?)によって、スケジュールというのは常に遅れていく可能性がある。そこで、クリティカル・パス長に、最小限の適切な余裕日数を加えて、納期を設定する方が安全である。この、意図して追加した余裕日数のことを、「バッファー」と呼ぶ。

余裕日数としての「バッファー」と、PERT/CPM技法でいう「フロート日数」は、ときどき混乱して使われるので、注意が必要である。PERT/CPMのフロートは、そのアクティビティが遅延したときに、プロジェクト全体の工期に影響を与えるまでの日数を言う。フロートが5日とは、そのアクティビティが5日以上遅れたら、プロジェクトの納期が遅れてしまう事を意味する（厳密にはフロートにはFree FloatとTotal Floatの二種類があるが、説明は省く）。そして、クリティカル・パス上のアクティビティはすべてフロート＝0日である。フロートとは個々のアクティビティに付随する属性値だと理解してほしい。

これに対してバッファーとは、特定のアクティビティにぶら下がる性質のものではない。あくまで、全体のプロジェクト・マネジメントの観点から、意図して置かれるものである。「時間のムダとり−−スケジュールのサバを切り捨てる」でも説明したとおり、適正なスケジューリングにおいては、（１）アクティビティ所要期間の冗長な部分をみつける、（２）それを捨てる（正味分のみにする）、（３）プロジェクト全体に必要最小限の冗長性を付け加える、という、ちょうど情報理論と類似した手続きを行う。このステップ（３）がバッファーなのである。バッファーは生産管理で言う、意図した在庫配置に相当する。

それでは、このバッファーを、アクティビティ・ネットワークのどこに配置すべきなのか。たとえば全体工程120日のプロジェクトに15日のバッファーを追加するとして、それはどこに置くべきか。細かく分割して、すべてのアクティビティに公平に配分したら、という考え方もあり得よう。いや、クリティカル・パス上のアクティビティだけに個別配分する、という案もある。だが、これらはあまりおすすめできない。前にも書いたが、バッファーには加法性が成り立たず、1日のバッファーを15個持つよりも、15日のバッファーを一箇所にまとめておく方が、ずっと安全なのだ。

じゃあ、まとめて最初か最後に置くのはどうか？　最初にバッファーを置く、というのは、言いかえると、プロジェクトがスタートしてから15日間は、何の作業にも着手しない、ということになる。これではバッファーとしての意味がない。したがって、プロジェクトの最後にまとめて置く、というのが正解となる。これを、「プロジェクト・バッファー」とも呼ぶ。

さて、プロジェクトを遂行していく上で生じるさまざまな遅れにより、このプロジェクト・バッファーは次第に消費されていく運命にある。そこで、プロマネは残りのバッファー日数をウォッチして、あと何日までなら納期に影響がでないか、常に見ていくことをお勧めする。このように、計画段階で上手にバッファーを配置設定し、実行段階でそれをウォッチし続けることを、CCPM技法では「バッファー・マネジメント」と呼んでいる。

この目的のために実行段階でしばしば使用されるツールとして、横軸にプロジェクトの経過日数（割合）をとり、縦軸にバッファー日数の消費（比率）をとって定期的にプロットする手法（バッファー・トレンド・グラフ）がある。理想的に言うならば、プロジェクトの進行割合に比例して、バッファー日数が消費されていく、という形になる。開始後40日たったらバッファーは5日消費され、開始後80日では10日消費されている、という具合だから、プロットされた点は斜めの直線になるだろう。しかし、現実はなかなかそうはいかず、ジグザグの線になる。

グラフ上で点が上の方に来る状態は、プロジェクトの進行に対してフロートの消費が著しく大きいことを意味している。そこで、グラフに原点を通る2本の線を書いて、プロット・エリアを3つに分け、下からグリーン・イエロー・レッドに分けることがよく行われる。信号の色である。プロットされた点が下の方、つまりグリーン・ゾーンなら安全、中間のイエローなら注意、上の方のレッドなら危険、という訳である。要注意から危険領域に入ったら、さまざまな対策を施して安全側に戻るようマネジメントする必要がある。

このようにCCPM技法では、プロマネが個別のアクティビティ全てを進捗管理するなど無駄な労力であって、クリティカル・アクティビティとバッファー日数だけをきちんとコントロールしておき、あとの精神的余力は他の重要な事に取っておくべきだと考える。そうはいっても全体の進捗率計算が必要だが、この「プロマネの注意は重要な事だけに向けるべき」というのは、とても良い提案だと私は思っている。

（なお、フロートのあるパスにおけるバッファーの置き方や、受注型で納期が外から与えられる場合のバッファーの考え方、さらに納期要求が実行可能期間より短いときにはどうすべきか、など関連する問題もあるが、長くなってしまったのでまた稿をあらためて書くことにしたい）

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

外注のスケジュール・コントロール

カミカゼ・タクシーという言葉があるなら、その運転手にこそふさわしい呼び方だった。ある外国企業とジョイント・ベンチャー・プロジェクトを始める打合せのために、我々は空港からタクシーを拾ったのだった。目的地まで何分かかるかたずねたら、運転手は答える代わりに猛スピードで走り出した。高速道路を時速１２０km以上で飛ばしながら、混み合う車の列を、ほんの１０cm間隔ですり抜けて走る。

「寿命が縮むかと思ったよ。」目的地について、助手席からふらふらになって降りた営業部長はそう言った。「ガイドブックには約４０分って書いてあったが、たった１５分で来たものな。」

初顔合せの相手と組んでプロジェクトを始める時の気分は、初めての外国でタクシーに乗る時の緊張に、少し似ている。道は分からず、言葉はロクに通じず、しかも荷物も時間も相手に任せきるしかない。ひどい回り道をされて、余計な運賃を請求されるケースも多い。かのカミカゼ運転手は、最短経路を最短の時間で運んでくれて、メーター通りしか請求しなかったのだから、まだ良心的な部類だったと思うべきだろう。

私の勤務先・日揮はエンジニアリング会社だが、プロジェクトの８割近くが海外向けである。国も場所も毎回異なるため、初顔合わせの相手とパートナーを組んだり、初めてのベンダーから重要な資材を買ったりしなければならないことが多い。相手を選ぶときは会社が定めた手順に従い、慎重にも慎重を期するし、契約書や調達仕様書には成果物も納期も品質も支払い条件も、事細かにしばりを入れている。

だが、それでも、予定通りに満足すべきアウトプットが出てくるかどうか、勝手に余計な回り道をされて、追加の手間や費用が発生しないか、ひやひやしながらつき合わなければならない。相手に支払うコストや役務のスコープは、状況を見て増減できる。しかし、時間はいったん失ったら二度と戻ってこない。身柄をあずけてタクシーに乗るのと、同じ気分なのだ。

気心の知れた相手と、くり返し同じ種類の仕事をする時と比べて、初顔合わせのプロジェクトでは、過去の経験値がない分、プロジェクトの進め方に注意が必要となる。では、初顔合わせの相手とのプロジェクト・スケジュールを立案する時は、どうやって期間（納期）の見積をすべきだろうか？

答えは簡単で、相手に聞くしかないのだ。−−タクシーと同じである。旅行ガイドブックには目安の時間が書いてあるだろうが、混雑状況次第でいくらでも変わりうる。自社内で仕事をやる場合や、系列企業に発注する場合は、「これこれの期間内でやってほしい」と依頼することができる。しかし、未知の相手と初めて組む場合、過去の経験値の蓄積がないから、向こうの納期回答をまず聞く必要がある。

大事なのは、この時の聞き方である。単に納期をたずねるだけでは不十分だ。必ず、結果に至るプロセスをたずね、そのステップごとに工期を分解して聞く。そして、どこでチェックポイントを入れるか、考えてみる。

たとえば、エンジニアリング業界で資機材を調達する場合、ベンダーに発注書を出してから、納品まで腕組みをして待っているようなことは絶対にしない。資機材のほとんどが個別受注生産品であるため、発注の後にも、
　（１）キックオフ・ミーティング
　（２）設計図面の提出と承認
　（３）主材料の購買手配
　（４）工場での製造開始
　（５）工場立合い検査
　（６）工場出荷
　（７）納入先到着
といったマイルストーンを定めて、それぞれの予定期日をたずねる。このように分解すると、従来経験した類似のケースから見て、相手の見積の妥当性を部分的には検証できるようになる。

無論、こうした方法をとっても、相手の納期回答を完全に信頼して良いものか、確証はできない。そこで、初顔合わせの相手を選ぶときは、納期だけでなく、相手のスケジュール管理能力自体を評価する必要が出てくるのである。

たとえば、「チーム員は毎日、工数実績と進捗を記録していますか」という質問をしてみる。日報や週報を、勤怠管理の一環として、記録させている会社は多い。しかし、たいてい実態は、週１回まとめて書き込むだけだ。実績工数の集計結果が出るのは月１回だったりする。しかも進捗状況までは記録していないケースが多い。理由は、進捗の測り方（業務プロセスやＷＢＳ）が標準化されていないからだ。

これでは、プロジェクトが今どこまで進んでいるのか、あとどれだけ工数（費用）が必要なのか、リアルタイムに把握できない。たとえて言えば、たまにメーターを見るだけのタクシーの客と同じで、なりゆきまかせだ。これで予定通りプロジェクトが完了したらおなぐさみである。

ところで、最近はＧＰＳとカーナビを積んだタクシーも増えてきた。自分の位置がリアルタイムに把握でき、到着時刻も見積もりやすい。ならば、現代のホワイトカラーが集まって進めるプロジェクトだって、ＧＰＳ的な仕組み＝進捗マネジメント・ソフトウェアが必要だと、そろそろ気づくべきだろう。

ただし、いかに精密なＧＰＳを積んでいても、偶発的な渋滞が起こるのを防ぐことはできない。プロジェクトでは必ず、計画外のリスク事象が起こる。プロマネはそれを事前に察知して、『渋滞』を避けるよう進路を変える能力を持たなければならない。

そこで、私は、初顔合わせの相手から見積をもらったときに、上記とは別に、相手のプロマネに対して、必ずこう質問することにしている：

　「あなたのスケジュールのクリティカル・パスは何ですか。そして、スケジュールのリスク要因は何と何ですか？」

これに満足に答えられない相手とは、原則として仕事をするべきではない。たとえ仕事をするとしても、こちら側がスケジュール・コントロールにかなり工数を割かなければならないだろうと、覚悟して実行予算を決める。

理由は明らかだろう。クリティカル・パスとリスクを読むこと−−これがスケジュール管理能力の最大のポイントだからである。

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

予定と実績の間のミッシング・リンク

今、米国で最も広く使われているプロジェクト管理ソフトウェアは何か？　−−答えは、"Excel"である。これは少し前にBostonで行なわれたProject Worldのカンファレンスで聞いた答えだ。ついでにいうと、Microsoft Projectとは、米国で最も売れており、かつ最も使われていないソフトウェアだ、とも聞いた。

MS Projectは私の勤務先でも（使いたければ）使えるが、あまり好まれていない。その理由は色々だ。ユーザ・インタフェースは親切なようでいて、一貫性がない。マウスのドラッグで工程表のガントチャートを簡単に書けるのは便利だが、どうも妙に親切すぎて、おかしな事をしばしば、しでかしてくれる。メニュー階層も分かりにくいし、印刷設定も不可思議である。

しかし、もっと根本の所で、プロジェクト・マネジメントのプロの目から見ておかしな部分がある。たとえば、MS Projectにはタスクやプロジェクトの予定終了日以外に、「期限」を設定できる。この二つは何が違うのか？　またプロジェクトの終了日をずっと後ろにずらすと、何とクリティカル・パスが消えてしまう。「クリティカル・パス」というのはプロジェクトの開始から終了までの経路の中で最長のものを指す、というのが定義である。だとしたら、このソフトは、クリティカル・パスの意味を知らないのだ。

しかし、もっとも問題なのは、じつは別のところにある。MS Projectには、スケジュールの開始／終了日付が、「予定」と「実績」の二つしかないのだ。これでは困る、と、プロジェクト・マネジメントのプロである同僚たちは言う。予定と実績の間に、プロジェクトの世界ではもう一つ必要なものがあるのに、MS Projectをはじめとする多くのプロジェクト管理ソフトには、それが欠けている。そのミッシング・リンクとは、「見込み＝forecast」である。

見込み日（forecast date）とは何か。これは、「現在のままでゆくと、開始日・終了日はこの日付になる」と判断された結果だ。今、設計のタスクを遂行中だとしよう。予定では、３月の１ヶ月間で設計完了のはずだった。つづく実装作業は、４月１日から開始の予定である。これらは「予定日」だ。ところが、設計は３月１０日になって、ようやく開始した。そしてまだ完了していない。だから、実績開始日は3/10で、実績終了日はまだ無い。しかし、開始が１０日遅れたのだから、作業ボリュームにかわりがないとしたら、設計が終了するのは、４月９日の「見込み」（forecast）である。実装開始の見込み日は、４月１０日になる。

プロジェクトは複数の人間が協同する作業である。下流工程の担当者は、自分のタスクが本当はいつ着手できる「見込み」なのか分からないと、困ってしまう。だからforecast dateは必須なのだ。これが、プロジェクト・マネジメントのプロの感覚である。

ところが、少なからぬ企業で、この「見込み日」の概念が、なぜか活用されていない（単に知らないだけなのだろうか？）。では、そうした会社では、現実を予想するのに、どうしているか。

答えは簡単だ。計画をそのたびごとに変更していくのだ。設計の着手が遅れたら、設計の予定日付も変えてしまう。こうして、何回も計画を更新していくから、計画の履歴管理が必要だ、などという要求が出てくる。しかし、この調子で計画をどんどん変更していったら、結局のところ、実績は常に計画と一致することになる。これで本当に進捗管理といえるのだろうか？　

計画のベースラインとは、めったなことでは変えないのが、プロフェッショナルのやり方である。では、変わりやすい現実にどう追随していくか。そのためにこそ、見込み日（forecast date）が必要なのだ。

ちなみに、生産スケジューリングの世界には、普通Forecast dateなどない。いらないのだ。なぜなら、製造現場の作業は精度が高いので、たいていはスケジュールどおり仕事が進んでいく。見込み日の概念がいるのは、ホワイトカラーだけだ。ホワイトカラーの仕事は、製造現場よりも精度が低い。だから、計画通り進まないのが当たり前になっている。精度が低い人たちが、不思議なことに、なぜか給料はたくさん貰っている。まあこれは余談だが。

ところで、見込み日を運用するに当たって、きわめて重要なことが一つある。それは、“見込みは誰が決められるのか”という問題である。よく、プロマネが進捗会議で担当者に対して、「その仕事はいつ終わる見込み？」と聞いたりする。この質問が意味を持つのは、回答者が『正しく予測できる能力・態度を持っている』という時に限られる。パートナー企業との共同プロジェクトや、海外ベンダーとのプロジェクトなどでは、この条件はかなりの留保つきでないと、適用できない。担当者が見込みを正しく答えられると言うのは、一企業の中だけで成り立つ、性善説だと考えるべきである。

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

ロジック・ネットワーク・スケジュールとは何か

昨年『時間管理術』を執筆していたとき、エクササイズ２「『できる人』の仕事ぶりを見て学ぶ」の節で、時間管理の上手い人の条件の一つに“スケジュールのバーチャートを必ず引いている”と原稿に書いた。そうしたら担当の編集者の人から、「こんな人は普通いませんよ。」とコメントされてしまった。結局、そのフレーズは削除することにした。

そうか、そんな人は普通いないのか。それが私の率直な感想だった。というのは、私のまわりで仕事のできる人は、“そんな人”ばかりだからである。仕事の相談をしたら、内容の後に、必ず段取りを決めて、バーチャート（ガント・チャート）を描かないと安心できない。そんな人の多いエンジニアリング業界で、私はそれなりの年数働いてきた。しかし、経済新聞社の編集局の人の感覚の方が、たぶんずっと普通だろう。

ところで前にも書いたとおり、最も多くのプロマネが使っているPMツールは、実はExcelなのだという。Excelで何をやっているかというと、タスクリストの管理やコストの集計といいたいところだが、一番ポピュラーなのはたぶんガントチャートによるスケジュール作成だろう。私も、あちこちの会社のプロジェクトで、Excel丸出しの線表をよくみかける。何せExcelの作図機能はある意味、融通無碍だから、Microsoft Projectなどではかけないような注釈やら色分けやらを駆使できるというわけだ。

それがわるいと非難するつもりは毛頭ない。全然ガントチャートを描かないよりは、描いて計画のベースラインとするほうが、ずっと良い。しかし、それで十分だとは言えない。バー・チャートだけでスケジュール・コントロールするのは危険なのだ。なぜなら、単なる線表には、ロジックが無いからだ。プロジェクト・コントロールには、ロジック・ネットワーク・スケジュールが是非とも必要なのである。

ロジック・ネットワーク・スケジュールとは何か。それは、全タスク（アクティビティ）間の論理的順序依存関係をきちんと定義したスケジュールである。基本構造の設計が決まらないと、主要部品の購買に着手できない。主要部品の購買が完了しないと、組立工程に着手できない−−こうした順序関係のロジックである。これをきちんと定義していくと、結局プロジェクトのスタート点からゴール点まで、全体として網目のような図表ができる。これをプロジェクト・ネットワーク・ダイアグラムとよぶ。

そして、プロジェクト・ネットワーク・ダイアグラムができると、隘路（クリティカル・パス）が定まる。つまり、本当の納期が見えてくるわけだ。そして、あるアクティビティの着手日や期間を変更したら、後続のアクティビティにどう影響するかも、すべて論理的に決まるし、自動計算もできる。これがロジック・ネットワーク・スケジュールなのである。ちょっと、次の図を見てほしい。

単純なガントチャートでは、なんとなく階段型にタスクがつながっていると、それらがすべて時系列的におこるのかな、と見えてくる。しかし、実際には図の下のようになっているのかもしれない。この場合、Bの期間が長くなっても、Cの開始には影響しない。Excelで線表を引いているだけでは、AやBに変更を加えた際、後の方をすべて手で直さなければならないばかりか、どこをどう直せばいいのか、すぐに判断できない。タスク数が10や20ならそれでもいいだろうが、50や100を超えたらもうお手上げである。また、各タスクに必要なマンパワー資源を見積もって、その積算を行う、などといった計画作業にも、ロジック・ネットワーク・スケジュールは必須である。

（余談だが、エンジニアリング業界でロジック・ネットワーク作成する際は、Microsoft ProjectではなくPrimavera Project Plannerというソフトが国際的なデファクト標準として使われている。ただしこれはプロの使う道具であって、コントロール対象のタスク数が100-200以下の規模だと、かえってお荷物という気がしなくもない）

いずれにせよ、優れたプロジェクト計画を作るためには、ガントチャートは必要条件に過ぎず、ロジック・ネットワークの定義が十分条件であるということを忘れるべきではあるまい。

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

イナズマ線と二重線 -- 工程表のアップデーティングとは何か （2012/02/19）

先日、拙著『時間管理術』を読みました、とおっしゃる方にお会いした。たいへんありがたいことである。ところで、その方が「一番勉強になったのは、スケジュールの工程表の上にイナズマ線を引くことでした、これで進捗の状況を見える化するというのは知恵ですね」と言われたので、こっちの方がちょっとびっくりしてしまった。この方の会社では、工程表を一度作成したら、それをそのまま、何の追記もアップデートもせずにずっと使い続けるのか、と思ったからである。

念のため書くと、先方は日本人なら誰もが知る一流企業で、業界ではトップ3に入る会社だし（ただしエンジニアリングや製造業ではなくサービス業だが）、その方だって立派な学歴と経験をお持ちだ。そして、プロジェクト的な、非定型的業務にずっと従事されている。だから意外だったのだ。

工程表は、航海士にとっての海図に似ている。工程表もつくらずにプロジェクトをはじめるのは、海図を持たずに航海に出るようなものだ。この方の会社は少なくとも、きちんと工程表をつくって仕事を進めておられる。ただ、どうやらそれを、そのまま最後までアップデートしないまま、使い続けるらしい。ちょうど、海図をもって航海に出るが、その海図に自船の現在位置や進路・速度を一切記入しない航海士のようなものだ。そもそも、工程表のアップデーティングという概念自体をご存じなかったらしい。

工程表というのは、単なる静的な図表ではない。ここでいう「静的」とは、一度作成されたら、基本的にそれで完成しそのまま参照され続ける種類の文書や情報を指す。たとえば契約書・発注書だとか、プロジェクトCharterなどは静的な文書である。他方、必要に応じて、適時改訂されていくべき種類の文書や情報は「動的」なカテゴリーに属する。プログラムのソースコードや詳細設計書などは典型的に「動的」なものだ。一度作成しただけで完了することは、まず無い。レビューや承認やテストや最終納品のたびに、内容が改訂され次第に最終形に近づいていく。

工程表もこのような意味で「動的」な図表なのである。ただし工程表は、必要時の「改訂」ではなく、定期的に「追記・更新」されていく点で、設計書などとは異なっている。ちょうど海図に船の位置と速度を毎日書き込んでいくように、スケジュールの現状を追記していく。これを『アップデーティング』と呼ぶわけだが、海図と違うのは、船の位置は一点で示されるが、プロジェクトの場合WBSのそれぞれのアクティビティ毎に位置を示す必要があることだ。いわば、プロジェクト工程表とは、船団全体を表示した海図のようなものなのである。

この工程表における現在位置と速度の代表的な表示方法が「イナズマ線」表記だ。これはガントチャート上に、ある時点における進み具合を示す縦線を書き込む方法である。各アクティビティの進捗度に応じて、50%進捗ならば横線のちょうど半分の位置の点を、70%進捗なら7/10の位置の点を選んで、縦につなげていくと、稲妻状の折れ線ができあがる。すでに完了したアクティビティは、単にまっすぐに縦線を引っ張る。すると、予定以上に進んでいるアクティビティは、右側に出っ張り、遅れているものは左側に引っ込むから、どこが進んでどこが遅れているかすぐに目で見て分かる長所がある。

プロジェクトでは、定期的に工程表にイナズマ線を追記していく。プロジェクト全体のスパンに応じて適切な間隔（毎週とか毎月とか）で書いていくわけだ。そうすると、工程表のガントチャート（横線中心）に、次第に縦線が加わっていって、格子状になっていく。プロジェクト最後になってふり返ると、どこが遅れどこがうまく進んだかを、マクロに見てぱっと判断できる利点がある。

スケジュールのアップデーティングには、もう一つ「二重線」と呼ばれる記法もある。これは、ガントチャートの各アクティビティに、計画線と実績線の２本の線を上下に重ねて引いて表現する方式だ。計画線は、着手予定日から完了予定日までを線で結び、実績線は、実際の着手日から実際の完了日までを結ぶ。ただし本日時点でもまだ完了していないタスクは、継続を示す短い点線を右に書くか、あるいは完了見込日までの横線にする（わたしはこの方が好きだ）。見込み日（Forecast date）とは、「現状のままでゆくと、終了日はこの日付になる」と予測／判断された結果である。

二つの方法には一長一短がある。イナズマ線は進捗のマクロな傾向が見やすいが、遅れたアクティビティが実際にいつ着手したのか分かりにくい。二重線の方は実績をつかまえるには便利だが、定期的に書き加えても経過が分かりにくい。ただ、いずれの場合でも、出発時点での元の計画との対比を主要な目的としている点は共通だ。プロジェクトはなかなか計画通りには進まない。それは経験的事実である。だからこそ、工程表を静的な情報として捉えずに、定期的にアップデートして予実対比していく必要があるのである。

ところが、「見込み日」の概念を知らない企業は世の中に多い。そうした会社では、現実を予想するために、計画のベースライン自体をどんどん変更してしまう。設計の着手が遅れたら、設計の予定日付も変えていく。しかし、この調子で計画を毎日変更していったら、最後に振り返って見たとき、実績は常に計画と一致していたことになる。これで本当に進捗管理といえるのだろうか？　計画のベースラインとは、めったなことでは変えないのが、プロフェッショナルのやり方なのである。

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

StartとEnd -- タスク間の依存関係

生産スケジューリングやプロジェクト・スケジューリングの世界では、仕事を細かなタスクにわけて、そのタスク間の前後関係について制約条件を定義することが多い。たとえば、先行タスクＡが終わらないと、後続タスクＢを始めることができない、などのように。こうした定義付けを、「タスクの依存関係」という。

タスクの依存関係の定義においては、ふつう、各タスクの開始（Start）時点および終了（End）時点での関連性に注目する。そして、たとえば、先行タスクのEndが後続タスクのStartにつながるのであれば、これをEnd-Startの関係（略称“E-S”）の依存関係と呼んだりする。

もっとも、ときどき、タスクの途中で他のタスクに分岐したり合流したりする図を見かけることがあるが、これはあまり良いやり方とは言えない。タスクというのは、それ自体が完結した作業単位であるべきで、もし途中で分岐したり合流したりするのであれば、本当はその点の前後でタスクを分割して定義すべきだったのだ（こうした例は、工順をうまく整理できていない生産スケジューリングでよく見かける）。

タスクの依存関係は、基本的には S-S、E-S、E-E、S-Eの４種類である。この中でもっともよく使われるのは、上述したE-SすなわちEnd-Start関係であろう。また、Start-Startも、比較的よく使われる。たとえば、建物の壁材を張るタスクと、壁の下塗りをするタスクを考えればいい。壁材を張り始めたら、その作業が建物全体に完了するのを待たずとも、すぐに下塗りにとりかかることができる。これがS-S関係である。逆に、最終引き渡しのタスクと、プロジェクト・マネジメントのタスクなどは、前者が終わると後者も（ほぼ）自動的に完了となるので、End-End関係になる。

ところで、一番分かりにくいのは、Start-End関係だろう。これが使えるようになると、スケジューリングのモデリング入門編は済んだ、と言ってもいいほどだ。

Start-End関係は、単純に考えると、先行のタスクが開始すると後続のタスクが終了する、という、ひどく変てこな依存関係のように見える。むろん、こんな馬鹿な話はない。「先行・後続」というタスクの順序を、考えなしに適用するから誤解を生むのだ。これを、タスクＡの開始とタスクＢの終了が関係づけられていると理解すれば、もっと明快だろう。

もっとも、“タスクＢが終わってタスクＡが開始するのならば、通常のEnd-Start関係とどこが違うのだ”という疑問も出るかもしれない。そうではないのだ。これは、“タスクＡが開始しなければ、タスクＢが終わることができない”と読むべきなのである。言いかえれば、後続が開始することが先行の完了の条件なのである。

具体例を挙げよう。たとえば、既存システムを運用しながら、新システムを導入するプロジェクトを考えよう。新システムが開発され、実運用がはじまって、はじめて旧システムは運用を終了することができる。決して、この逆の順序ではないことに注意してもらいたい。後続がはじまる前に、先行タスクを勝手に終わることはできないのだ。

生産スケジューリングの場面ならば、たとえばこうだ：後続の工程（機械）が利用可能になるまでは、前工程に仕掛品をずっと保管しておかなければならない。これもStart-Endだ。あるいは、夜シフトがはじまらない限り、昼シフトは終わることができない、など。隙間を空けずに何かを運用しなければならない系では、しばしばStart-End関係のお世話になることになる。

タスクの依存関係については、E-SやS-Sに付随して、タイム・ラグを規定したりすることもある（たとえば8時間以上たたないと後続が開始できない、など）。あるいは、S-SとE-Eを同時に満たす必要があったり、いろいろとバリエーションが存在する。

高機能のAPSになればなるほど、タスクの依存関係については柔軟なモデル化が可能になる。とはいえ、高機能なAPSがいつでも良いわけではない。高機能なものは、それなりにマスタデータの完全性を要求されるし、運用やチューニングの手間もふえるし、なにより高価である。「問題の身の丈」にあったツールを選べるよう、モデル化の工夫を凝らす方が経済的に引き合うことが多いのである。いつでも「ツールは使いよう」なのだから。

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

進捗率にはいろいろな定義が可能である （2012/03/04）

ＩＴ業界の人からときどき聞く発言の一つに、「ＩＴプロジェクトではクリティカル・パス法なんか使えない」という主張がある。わたしはスケジューリングとかタイム・マネジメントの分野で長く仕事をしてきたが、こういう主張をＩＴ分野以外できいた覚えがない。ＩＴ業界人は知的な人が多いと思うが、自分達の仕事を“特殊な仕事”だと考える傾向も強いように思われる。無論ある意味では特殊な分野かもしれないが、だとしても1日の作業のあとに2日の作業をした場合、合計3日かかるのは、どんな仕事でも共通ではないか。なぜＩＴ業界の人だけ、“ウチの分野は1+2=3の算数が成立しない”といった意味のことを言いたがるのか？　当初はとても不思議に感じた。

しかし、話しあっていく内に、次第にＩＴ系の人たちの抱える不満、ないし問題がすこしずつ分かるようになってきた。クリティカル・パス法はいうまでもなく、プロジェクト全体を複数のアクティビティにブレークダウン（ＷＢＳ化）し、各アクティビティの期間と順序依存関係をもとに、全体の工期を推定する手法である。これ自体は非常に論理的な、いわば算法の世界だから、不服を申し立てる人はいない。問題は、そのアクティビティ所要期間の見積にあるのである。10日間のアクティビティＡ（たとえば設計）の後に20日間のアクティビティＢ（たとえば実装）をやった場合、全体で30日かかる、と、そこまではいい。難しいのは、設計が本当に10日で終わるのかどうか計画時点で誰も自信を持って見積もれないし、スタートして5日後に設計進捗率＝50%になってもちゃんと10日で終わるか不明だし、9日目になって前提条件がひっくり返り「さらに10日かかる」状態になるかもしれない、という点だ。こうした不確実性があるから、「ＰＥＲＴ／ＣＰＭなんか使えない」という不満が出てくるという事らしい。

ここでの問題を解きほぐすと、実は三種類の別の悩みが混じっていることが分かる。第一は、そもそも計画時点で期間見積をすることが難しいという点。第二に、途中の進捗状況から完了の『見込み日』を推定することが困難である、という点。そして第三が、途中でリワーク（手戻り）によるリスクがある点である。このサイトでは、第一の期間見積の精度向上については「マイルストーンは中点で測れ」ですでに論じたし、第三のスケジュール・リスクについては「時間のムダとり−−スケジュールのサバを切り捨てる」でも書いている。そこで、今回は二番目の『進捗率』の信頼性問題について考えてみよう。

情報処理技術者試験に「プロジェクトマネージャ」がある事は、ＩＴ業界のかたならご存じだろう。経済産業省の認定資格である。その2004年度の秋季に、進捗率に関するこんな問題があった（以下、筆者が一部改変して引用）：

• 10本のプログラムからなるシステムを完成させるプロジェクトがある。１本のプログラムを完成させるには１人月の工数がかかると見積もられた。
• 各プログラムの開発作業は、設計（20%）→コーディング（50%）→テスト（30%）のプロセスからなると推定された。
• 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった。現時点での進捗率を求めよ
  　　　　　　完了数（本）　予定工数（人月）　実績工数（人月）
  　設計　　　　　１０　　　　２．０　　　　　　２．５
  　コーディング　　６　　　　３．０　　　　　　４．０
  　テスト　　　　　３　　　　０．９　　　　　　１．５

なかなか面白い問題である。読者諸兄だったら、どう考えられるだろうか？

問題文には書いていないが、この10本のプログラムは、互いにまったく独立で、相互に連関はなく、作業は完全に平行に進める事ができるらしい（そんなプロジェクトばっかりだったら誰も苦労しないさ、というような批判は置いておく）。

進捗率の計算としては、ぱっと考えて三種類の方法がありそうだ。
（１）完成数基準。最後まで完成した本数の比率を、進捗率とする。つまり
　　３／１０＝３０％
（２）予定工数基準。問題文に工数見積の情報があるのだから、きっとこれを使うのだろう。すでに完了した作業の予定工数から計算する。
　（２．０＋３．０＋０．９）／１０＝５９％
（３）実績工数基準。いや、すでに消費した実績工数のデータで計算すべきだろう。
　（２．５＋４．０＋１．５）／１０＝７０％

あいにく当時の経産省系の試験はすべて、正解が公開されなかった。だから出題者がどれを念頭においたのかは分からないが、ここで推理してみよう。

念のためにいうが、進捗には、さまざまな定義が可能である。これは決め事の問題であって、その点では原価管理に似ている。同じ会社の同じ製品といえど、いろいろな原価の計算が可能である。原価にただ一つの正解は無い。進捗率も同じだ。しかし少なくとも、合理的な算定方法として合意できることが条件であろう。

完成数基準の計算：３／１０＝３０％、はどうだろうか。これはこれで単純至極な定義であり、問題はないように思える。しかし進捗管理の目的は、「この仕事はいつ終わるのか」を知る事であった。１５日目に進捗率３０％ならば、完成まで５０日かかる計算だから、あと３５日必要と言えるだろうか？　そうではなさそうである。そもそも、もしこの仕事が理想的な並列で進んだとしたら、ずっと完成本数＝０で、最終日にいきなり１０本完了、ということになる。横軸に時間、縦軸に進捗率をとってグラフを描いたら、ずっとゼロ％のままで、最終日に100％になる。このようなグラフを用いて、進捗管理（すなわち完了の予測）ができるだろうか？　完成数基準の進捗率はシンプルで分かりやすいが、こうしたケースでは進捗管理には向かないのである。

では、実績工数基準はどうか。この手法の問題点は、すでにお気づきのかたも多いだろう。もし仮に、現在までに9人月かかったとすると、進捗率は90％ということになる。12人月かかったら、120％進捗（？）になってしまう。これは明らかに不合理である。「予算消化率で進捗率は測れない」のであった。

だとしたら、消去法で、『予定工数基準』がこの問題の正解らしいと分かる。でも、なぜこれが正解なのか？　それは、“進捗はあとどれくらい仕事が残っているか”で測るのが原則だからである。現時点で、残っている作業の工数は、コーディングが４本、テストが７本であった。ということは、２＋２．１＝４．１（人月）、すなわち全体の４１％の仕事が残っている訳だ。だから進捗率５９％が正解なのである。ちなみに、この計算方法は、全部で３０個のサブ・アクティビティ単位における完成数基準で、重みづけに計画工数をつかったものだと説明することができる。そして、これこそ、アーンドバリュー・マネジメント・システム（ＥＶＭＳ）の考え方そのものであった。この問題は、だからＥＶＭＳの理解を問うのが目的だったらしい（ＥＶＭＳで完了までの期間をどう推計するかについては、長くなるので別の機会に述べよう）。

進捗率とか原価という概念は、案外危険な概念である。それは数字で示されて、分かったような気になりやすい。しかし、これらは人為的な尺度であって、いろいろな測り方ができ、目的に応じて使い分けなければいけない。間違った使い方をすれば、かえってミスリードなだけである。精度を議論するなら、その定義に立ち返って議論しなければならない。よく「製造業や建設業はモノが出来ていくから、進捗が目に見える」などと言う人がいるが、ことはそれほど単純ではない事を知るべきである。

そして、もう一点。アクティビティの期間にばらつきがあり、推定にリスクがともなう現象は別にＩＴ業界だけに限ったことではない。リスクの無いプロジェクトなどというものはない。これは共通の問題であり、共通の知恵が使えるのである。もちろんＩＴプロジェクトだけはリスクが極端に大きいのだ、と言えば言えよう。でも、だとしたら、ＰＥＲＴ／ＣＰＭを批判するだけでなく、それに代わる定量的な理論と手法を、なんとかして考案すべきであろう。そして、ＩＴ業界の人たちには、それをできるだけの知性と能力があると期待したいのである。

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

進捗率の計算と図的表現法

製造業における進捗管理は、ふつうロットやワーク単位に行われる。どれだけの量をいつまでに作らなくてはならない、との予定に対し、現時点ではこれこれの数量までできている、というモニタリングを、各工程ごとに、ロットやワークの状況から計算する。全工程がロット・フォア・ロットで流れる場合やフロー・ショップの場合は、最終製品レベルで個々の生産オーダーの進捗率を計算することも簡単だ。

しかし、ふつうのジョブ・ショップ型組立加工業では、話はもう少し複雑だ。共通部品をロットまとめして製造したりするので、最終製品の生産オーダー単位での進捗率計算は簡単ではなくなる。とくに大型の産業機械では、詳細設計がすべて終わらぬ時点で部品製造が始まったりするので、設計を含めた進捗を考えなければならない。

一品個別受注生産の場合は、受注から設計・資材調達・製造・検査・納品までの一連の流れを、一つのプロジェクトとしてとらえることができる。したがってプロジェクト進捗管理の技法がフィットしやすい。プロジェクト進捗管理では、プロジェクトを構成する全てのアクティビティおよびマイルストーンにウェイトを設定して、進捗度を計算する。

ただし、ウェイトの設定には金銭つまり費用が用いられることが多いが、注意すべき点が一つある。費用基準だと購買や製造に比べて設計や検査作業のウェイトが小さくなりすぎるのである。そこで、設計完了や検査終了といったマイルストーンに大きなウェイトを配布して、全体のバランスをとることが望ましい。

このプロジェクトの進捗度を図で表現する方法の一つに、「トレンドチャート」がある。トレンドチャートは横軸に工期、縦軸に出費をとって予定対実績を２本の線で表示する。拙編著「情報処理技術プロジェクトマネージャ完全合格対策」（2002年度版・125ページ）に解説があるので参照してほしい。

ところで、これに関して最近ある読者から質問のメールをいただいた。それは、『あるマイルストーンで計画と実績を比較して、実績が計画よりも右側に来ていたら、それは予定よりも進捗が上がっていると解釈すべきではないか（他の参考書はそう書いてあった）』というものだ。

これは、よくある誤解である。おそらく横軸の「工期」という言葉が誤解の元なのだろう。これはただ単純に、プロジェクト開始時点から経過した時間をあらわす、と読めばいいのだ。たとえば、プロジェクト開始から6ヶ月後に、詳細設計完了というマイルストーンが予定されていたとする。これに対して、実績は6.3ヶ月かかったのだとしたら、明らかに作業は遅れているわけだ。

おそらく、他の参考書の執筆者は、これを「横軸＝進捗率」と誤解してしまったのではないのだろうか。そして6ヶ月目の進捗率が6.3なのだから、これは予定よりも進んでいる、と解釈したのだろう。しかし、トレンドチャートの点はマイルストーン通過点を意味しているのだから、その理解は間違いである（もし横軸の「工期」を進捗率と同義と解釈したら、各マイルストーンの実績値は予定された位置に必ず縦に並んでしまうはずで、グラフとしては役に立たなくなってしまう）。

なお、アーンドバリュー分析でも、横軸に時間・縦軸に出費のグラフを作って、進捗と出費の両方を表すグラフを作る。こちらについては、同書421ページを参照されたい。

トレンドチャートでは、マイルストーンをきちんとこまめに定義しておかないと、実績が遅れているのか進んでいるのかがわかりにくくなる。これに対してアーンドバリュー分析では、マイルストーン定義の有無にかかわらず、任意の時点で予定と実績の進捗を比較することができる。そのかわり、グラフの中の線が３本になってしまうので、読取りに多少のスキルが必要になる。どちらを使うかは、目的と効果の観点から判断して選ぶべきであろう。

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

進捗を把握する３つの方法 （2010/06/14）

言葉の通じぬ、見知らぬ土地でタクシーに乗った。こちらの告げた目的地を、運転手は分かったんだか分からないんだか曖昧な態度のまま、車を発進させる。しばらく乗ったところでやはり不安になり、「もう半分くらいは進んだのかな？」と口にしてみる。すると、隣に乗っていた若い部下が気楽そうに答えた。「もう、2/3くらいまで来ていますよ。」「なんでわかるの？」「だって、メーター見てください。空港からだいたい30ユーロくらいって、言われたじゃないですか。もう20ユーロ分、走ってますもん。」

進捗を把握するのは、簡単なように見えて、案外むずかしい。それは、私たちが『進捗とは何か』を、本当には良く理解していないからだ−−こう言ったら驚かれるだろうか。無論、このタクシーの例のように、目的地に向かっているかどうか分からないときに、メーターだけ見て進捗を測るのが無意味な事は、誰でも分かるだろう。では、次の例はどうだろうか。

まだ戦後間もない昭和25年、国会で「北海道開発法」が成立した。敗戦で海外の植民地をすべて失った日本に、ただ一つ残されていた未開の沃野が、じつは北海道だったのだ。この法律に伴って、「北海道開発庁」という役所が設立される。その北海道開発庁が中心となって、2年後の昭和27年に、北海道開発の『第一次五カ年計画』が開始する（余談だが、五カ年計画という名称はなんだか社会主義国を連想させる）。

その『第一次五カ年計画』は、農業・畜産奨励・土壌開発（機械力による客土）・道路・河川・港湾整備・・・を含む壮大な国家的プロジェクトであった。予算は、国費だけで８００億円。半世紀以上前の金額だから、現在に直せば１兆円を超えるだろう。

ところで、それから5年経った昭和32年に、著名な物理学者でエッセイストでもある中谷宇吉郎博士（当時北大教授だった）が、文藝春秋に爆弾論文を発表する。「北海道開発に消えた八百億円　−　われわれの税金をドブに捨てた事業の全貌」（昭和32年4月号）という、きわめてショッキングなタイトルのその論文で、中谷先生は、人口・農業統計などの数字を詳細に調べ、「人口増加・食糧増産・農家戸数の増加は、・・・いずれも達成率０であった」と断ずるのである。

この論文のおかげで、北海道開発庁は上を下への大騒ぎになったらしい。北海道開発庁（なぜかこのお役所の主要機能は霞ヶ関にあった）では、翌月、さっそく文藝春秋誌に反論を掲載する。開発庁の高官が書いたこの論文には、「開発計画は順調に進展している」と書かれている。なぜなら、「過去の年度で順調に予算を消化してきたからだ」・・・。

この論法が、タクシーに乗った後輩社員と同じく、おかしいのに気づかれただろうか。過去にどれだけお金を使って事業を進めて来ようが、目標に一歩も近づいていなかったら、進捗はゼロである。タクシー・メーターをいくらにらんでも、進捗が分からないように。

たしかに開発庁だって努力はしてきたにちがいない。そのこと自体について、異論はない。だが、進捗と、過去の努力は関係がないのだ。なぜなら、進捗とは、これまでどれだけ仕事をしたかではなく、「これから先、どれだけ仕事が残っているか」で測るべきものだからである。

それなのに、進捗の議論となると、タクシー・メーターを見ることばかりに集中するきらいが、ときどきある。メーターをどれだけ精度良くしようが、リアルタイムで1円単位まで測ろうが、それは（コスト管理には資するかもしれないが）進捗管理には関係ないのである。

あるいは、「使った費用」のかわりに「使った時間」で測りたがる誤解も、後を絶たない。10日間でおわるはずの仕事がある。今、8日目だ。だから進捗は8割です−−これが間違いであることも、説明の要はないと思う。こんな論法が通用するのなら、9日目は9割、10日目には10割になる。10日目でも仕事が終わらなくて、11日目に突入したら、進捗は何割になるのか。11割か？

考えてみるとこれが馬鹿げていることは誰にも分かる（はずだ）。だから、実際の進み具合は、担当者にたずねてみるしかない。かくして、プロジェクト・マネージャーは週次ミーティングでチーム員や関係者を集めて、各人に「どこまで進みました？」と訪ねたりする。プロマネはその答えを持って机に戻り、Excelの計算表か何かに数字を入れて全体の進捗率を計算する。有名なプロジェクト・マネジメント・ソフトウェアにもたいてい、『Progress %』を入力する機能がついている。まあ、一番ポピュラーなやり方であろう。

だが、こうした問答で返ってくる進捗率が、“タクシー・メーター的な進捗率”でないという保証は何もない。さらに担当者のサバ読みなども紛れ込みやすい。だから、「率」で質問する方法は、私自身はあまりお勧めしない。

では、何で測るべきなのか？　もし進捗を定量的に測りたいのだったら、やるべきことははっきりしている。「残りの仕事量」を定量化することである。それを、全体像と比べて、あと何割残っているかを計算する。だが、これは繰返し性の高い業務では可能だが、個別性の高いプロジェクト的業務では、決してたやすくない。

そのことを理解した上で、次に思いつく方法は、率の代わりに、各人に『残日数』（完了まであと何日かかるか）を申告させる方法であろう。「これが進捗管理の唯一正しい方法だ！」と力説される大学の先生に、あるセミナーでお目にかかったこともある。でも、はたしてそうだろうか。これが進捗管理として信頼できるためには、各担当者が、残日数について信頼に足る見積能力を持っている、という前提がある。これは、成熟度の高い組織ではあり得るかもしれないが、すべての会社に当てはまるとは、到底言えない。だって、プロマネ自身、上司に同じ質問をたずねられたとき、希望的観測を述べたりすることもあるではないか。

これとよく似た方法として、『完了見込日』を答えさせる方法もあるが、問題点は同様である。仕事にはまり込んでいる担当者に、客観的状況把握を期待するのは難しいと、私は思う。もしやるのなら、むしろ各担当者をマネージしているリーダーか、あるいはPMOに、完了見込日を推測させる方がベターかもしれない。しかしこうなると、「上は俺たちのいうことを信用していないのか」との感情的反発もあり得るし、手間もかかるという何点があるだろう。

残る、第3の方法がある。それは、「マイルストーン」を活用する手法である。プロジェクトのプロセスを計画時点で検討し、要所要所にマイルストーンを（できればそのクリティカル・パス上に）配置する。そして、そのマイルストーンに、進捗率を当てはめるのである。その率は、EVMSで用いるようなコスト基準（残るアクティビティのコストの比率）でも良いし、あるいは別の何らかの基準で決めても良い。とにかく関係者全員が、各マイルストーンについて、ある程度納得し合意できる進捗率を、定めておく。そして、そこを通過した時点で、“何％を達成”と公表するのである。

もしプロジェクトが大きければ、それを各アクティビティについても定義しておく。設計書作成のアクティビティならば、「設計条件の整理」→「設計計算」→「図面の作成」→「設計書本文の作成」→「検討・承認」といった標準的な内部プロセスがあるはずである。それぞれに対して、内部進捗率を10%・30%・60%・80%・90%・100%といった具合に取り決めておく（組織内部で合意する）。そして、週次ミーティングで質問するときは、「何％か」を聞くかわりに、「今どこのステップか」をたずねるのである。これならば、回答者の主観やサバ読みを、少しは排除しやすい。

いずれにせよ、繰返し業務と違って、プロジェクトは個別性が高い。これはすなわち、見通しにリスクが伴っており、「終わってみないと本当はどれだけの仕事量だったか分からない」ことを意味している。すなわち、プロジェクト的な進捗管理には、かならずリスクに伴う精度の問題が付随することを忘れるべきではない。この問題には「正解」は存在しないのだ。あるのは、「納得感を持てる」方法のみなのである。

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

役割（Role）としてのプロジェクト・マネージャー

世の中には、名刺に書きやすい資格と、そうでない資格がある。『弁護士』だとか『医学博士』だとかは、名刺に書くと箔がつくし、押し出しもきく。『技術士』や『不動産鑑定士』はそれよりやや専門的で地味な印象だが、その道の人は誰もが知るプロフェッショナルである。これに比べて、『漢字検定１級』とか『囲碁５段』とかは、知識レベルの深さでも資格取得の難易度の点でもひけをとらないはずだが、なぜか名刺に書く人は少ない。不公平なことである。

私が持っている（そして参考書も書いている）『プロジェクトマネージャ』というのもまた、名刺に書きにくい資格だ。なぜなら、この名称では、取得資格なんだか社内組織上の職位を表わしているんだか、区別がつかないからだ。げんに私も名刺には記していない。

せっかく資格を取っても名刺に載せられないとさびしいので、もう少し注釈をつけて書こうかと考える向きもあろう。すると、『経済産業省認定　情報処理技術者プロジェクトマネージャ』ということになるが、ずいぶん長くて場所ふさぎだ。おまけに名刺交換の時に、自己紹介の目的にかないにくくなる。「じつは私は経済産業省認定情報処理技術者プロジェクトマネージャでして」「ほう。あなたは経済産業省認定情報処理技術者プロジェクトマネージャの資格をお持ちですか。そういえば昨日も別の経済産業省認定情報処理技術者プロジェクトマネージャの女性にお会いしましたが、この方がなかなか美人でしてな・・」これでは、いつまでたっても話の本題に入れそうもない。

世の中に『社長』とか『課長』とかいう名前の資格制度があったらおかしい。それなのに、情報処理試験制度がこのような名称を選んだのは、想像するに、二つ理由がある。まず、プロジェクト・マネージャーが専門職であるという認識があったのだろう。たしかにある意味ではそうだ。マネジメントが専門職なのか管理職（総合職）なのかは、議論の余地があるはずだが。

もう一つは、プロジェクトが時限的な営為である以上、ＰＭもまたパーマネントな（永続的な）職位ではあり得ないはず、という理解があったのではないか。社長や課長は、永続的な職位である。個人単位ではいつかはその職を去るだろうが、管理対象はゴーイング・コンサーンを旨とする企業組織である。何かの目的を完遂したら解散、というプロジェクト組織とは異なる。

おそらく、この２点に、従来型の企業組織がプロジェクト・マネージャーという職業を位置づける際の居心地のわるさ、困難さが集約されているように思う。ＰＭとは職位（＝地位・特権）なのか、職種（＝専門性）なのか？　また永続的な部門の管理者なのか、それとも部門長に管理される者なのか？　そもそも、若いＰＭは、自分より先輩の専門職チーム員に、指示を出す権利があるのか？

こうした混乱は、プロジェクト組織の本質を理解していないから起こる。じつはＰＭとは職位でもなく職種でもなく、役割（Role）なのだ。役者が劇で役割を演じる、あるいはサッカーでアシストとシュートの役割を分担するように、プロジェクトという限られた目的の中で、最終的な意志決定の責任をになう「役割を負っている」のがＰＭなのである。プロジェクトが終わって、ＰＭの任を降りたら、つぎは誰か別のＰＭの下で、別の「役割」につくかもしれない。それはＰＣＭ（プロジェクト・コントロール・マネージャー）やＥＭ（エンジニアリング・マネージャー）という「役割」かもしれない。

プロジェクト・マネジメントは専門技能である。この点はいくら強調しても強調しすぎることはない。しかし、たしかに（２年も３年も続く巨大プロジェクトは例外として）ＰＭという一時的な役割を職位のごとく名刺に書くのは、おかしい。それならば、専門技能の持ち主である人々を、どう呼ぶべきなのか。

我々の業界では、『プロジェクト・エンジニア』と呼んでいるが、ちょっとそっけない職種名称だ。ＰＭＩの"Project Management Professional"（PMP）とか、ＰＭＣＣの"Project Management Specialist"（PMS）などの名称の方が、ずっと気がきいている。

名称はどうあれ、この『プロジェクト・エンジニア』は、ＰＭになるための主要なキャリア・パスだ。最初は雑用じみた調整役からはじめて、しだいにＥＭだとかＰＣＭを経験し、やがてはＰＭの役割を担えるようになっていく。

より多くの業界において、名称はどうあれ、プロジェクト・マネジメントの専門職種が認知され、適切な「役割」を与えられるようになっていくことを、私は切に望んでいる。

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

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

リスク・マネジメントは本当に可能か （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）

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

たとえば、人に「最近遭遇したリスク事象の例を挙げてください」と質問したとしよう。たいていの場合、返ってくる答えは「発注先が納期を一月半も遅らせてきたんです」とか「先月自転車で事故りまして」といったものだ。これらは実際に起きてしまったトラブル事象、すなわち『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は明確に対称型のリスク概念で書かれている。これはやや不思議に感じられるが、あるいは標準制定の途上で、金融学系の人々の影響が強かったのかもしれない。

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

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

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

戦略的プロジェクトとリスク・プレミアムの原理 （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万円近くなる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

契約なんかこわくない

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

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

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

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

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

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

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

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

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

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

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

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

契約なんかこわくない（２）　契約を設計する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

契約なんかこわくない（３）　契約の論理の根底にあるもの

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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