ある女声合唱の演奏会で、わたしの所属する男声アンサンブルが、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」とれいれいしく刷っている身としても、これはやや困る） それにしても、ここにあげた三つの例を考えてみると、マネジメントに一番役に立たないのは『資格』であり、次に役に立たないのは『学歴』『キャリア』で、一番役に立つのは、持って生まれた『センス』だということになりはしないか。だが、果たしてそれで良いのか？ 本来は逆の順であるべきだろう。持って生まれたセンスを教育や仕事の経験が磨き、それを資格が保証する、というのがあるべき姿のはずだ。しかし多くの企業では、キャリアも資格も固有技術・知識として頭の表層に残るだけで、管理技術としてのマネジメントは「センス」のみで進められている、らしい。 最初の合唱団の例を思い出してほしい。指導する声楽家はリーダーである。そして、単に歌の練習を繰り返す間はそれだけで十分だった。でも、演奏会にはマネジメントの仕事が生じる。マネジメントは、何か新しいことに挑む時に、あるいは過去の繰り返しでは先がない時に、必要となるものだ。ちょうど新製品を作ったり、業務や組織を改革したりする時に。それ自体は、必ずしも華々しいものではないかもしれない（演奏会で脚光を浴びるのは指揮者やソリストだし、新製品で賞賛を受けるのはデザイナーだ）。でも、上手にやることが望まれる。そのマネジメントの仕事を、キャリアでも資格でもなく、皆が持って生まれたセンスだけでやっているのだとしたら —— たしかにまあ、わたし達の社会が泥沼から脱出するのに時間がかかるのも無理のないことである。 プロジェクト・スケジューリングの理論では、日程表の中に書き込む要素を、アクティビティとイベントに大別する。アクティビティは明確な始まりと終わりを持った出来事で、生産スケジューリングにおけるタスクにほぼ相当する。一方、あるプロセスが何らかの達成点に到達する瞬間をイベントとよぶ。たとえば、「卒業式」はアクティビティだが、「卒業」はイベントである。
イベントの中でも特に重要な意義をもつものが、マイルストーンである。マイルストーンはプロジェクト・スケジューリングで大事な役割をはたす。たとえば、基本設計完了だとか、製品の工場出荷などはしばしばマイルストーンとして扱われる。通常、マイルストーンは、そこを通過したら仕事が後戻りをすることはない。仕事のプロセスの逆止弁のような役割を果たす。プロマネにとってはほっと一安心でき、また気持ちをリフレッシュできるタイミングである。 そこで、プロジェクトの進捗度管理において、マイルストーン達成日時の予定と実績を対比して、とどこおりなく仕事が進んでいるかをチェックする方法がある。マイルストーンの予実をリストアップしたものをマイルストーン管理表と呼ぶ。プロジェクトのガント・チャートを書く場合は、マイルストーンはしばしば☆印や旗印などで図中に表記される。 ところで、通常の教科書に書かれているアーンドバリュー分析（EVMS）の手法では、このマイルストーンはうまく組み込まれていない。最近普及の著しいアーンドバリュー分析は、プロジェクトを構成するすべてのアクティビティの予算(PV)と完成出来高(EV)・実際費用(AC)を対比して、進捗率およびコストの予実を把握する手法だ。そのベースとなるのはアクティビティの予算である。しかしイベントやマイルストーンには、予算を割り当てようがない。したがって基本設計が承認されようが製品が工場を出荷しようが、出来高はほんのちょっと（対応するアクティビティの予算分だけ）上がるのみである。気分的にメリハリのないことおびただしい。 そんなのは単に感情的な問題に過ぎないじゃないか、と考えるのは浅慮である。じつは、マイルストーンの達成とは、通常なんらかの不確定性・リスクが大きく下がる瞬間でもあるのだ。設計が固まる、製品がトラックに積み込まれる、これらの瞬間を重要だと人間が感じるのは、その時点において設計変更や納期遅延のリスクが完全に遠のいたからなのである。通常のEVMSでは、この意義をハイライトすることができない。 そこで、現実のプロジェクト進捗計算でしばしば採用されるのは、アクティビティ以外にマイルストーンにも何らかの重みを与える手法だ。基本設計承認では、アクティビティとは別に5%の進捗率アップを計上する、という風に行う。EVMSとマイルストーン管理表の折衷的な方法で、理屈の点ではあまり美しくないが、実務上の納得感を与えることができる。 受託型のプロジェクトでは、実際問題として、支払い条件にマイルストーンをからめて設定することが多い。プロジェクトのキックオフで20%、設計完了で40%、製品出荷で80%、検収完了で100%、といった風に、マイルストーン毎に支払いを行う契約である。必然的に、マイルストーン管理表の手法に近づいていく（EVMSだって、もとは「出来高払い」という支払い慣習に根ざして生まれた）。 その際にマイルストーンの設定において注意すべきことは、クリティカル・パスを構成するアクティビティの後ろにマイルストーンを置くことだ。そうすれば、マイルストーンの遅れがすなわちプロジェクト全体の遅れに直結するので、注視する意味が出てくる。フロート（余裕日数）を持つアクティビティ上に置いたのでは、プロジェクト全体の進捗の指標にならない訳だ。 とはいえ、そもそもアーンドバリュー分析は、プロジェクトのスコープが明確で、WBSを最初からきちんと組み立てることができるような「ハードな」種類のプロジェクトに適している。研究開発初や新製品開発のように、最初の段階ではスコープも納期もあいまいな種類の「ソフトな」プロジェクトでは、むしろ最初からマイルストーンで把握していくほうが適切である。 このように、EVMSとマイルストーンを適切に使いわけたり、あるいは適度に併用したりすることは、理論を知らない結果と言うより、現実的なプロジェクト・マネジメントを理解している証しだ、と考えるべきだろう。 5年前に日経文庫から『時間管理術
 』を上梓したとき、出版社が帯につけた惹句（注目をひくための宣伝のフレーズ）は、「自分のスケジュールを“見える化”せよ！」だった。帯の文句は著者が知らないところで決められる。でも、これを見たとき、正直に言って、やれやれと思った。“見える化”はトヨタの発明した用語で、あまり関係のないわたしが勝手に使いたい言葉ではなかったからだ。当時、たまたま学会の委員会関係で、トヨタ自動車の銀屋技監をはじめ何人かの方ともおつきあいがあった。自分の著書が出たので早速贈呈したのだが、挨拶の中で「この“見える化”という言葉は出版社が勝手に書いた惹句でして・・」と妙な言い訳をしたのを覚えている。わたしはトヨタ独特の用語や概念を、自分のサイトなどであまり使わないことにしている。第三者が尻馬に乗ってはしゃいでると思われるのは、しゃくにさわるからだ。それにトヨタ系列以外の会社が、（自分との違いを深く考えぬまま）トヨタの真似をするのは、決して賢いことではないと思っている。だから「あなたの会社にトヨタ生産方式が向かない５つの理由」などというエントリーも書いたが、この文章は我がささやかなサイトの中では、飛び抜けてアクセス数が多かった。上司から「トヨタを見習え」と指示されて苦労している人が、けっこうたくさんいる証拠なのだろう。 ところで最近、5年ぶりにまた本を書いている。そのテーマが、じつはジャスト・イン・タイムなのである。「生産革新フォーラム」の友人達と準備中のこの本は、早ければ12月に上梓される予定だが、仮のタイトルを「『JIT生産』を卒業する本 ～トヨタの真似だけでは儲からない」という。つまり、考えずにトヨタの真似をしてはいけない、がサブテーマだ。 誤解しないでほしいが、わたし達はトヨタ生産方式やジャスト・イン・タイムを批判しようとしているのではない。需要と供給を一致させる「ジャスト・イン・タイム」の思想はサプライチェーン・マネジメントを先取りしていて見事だし、有用だと思う。また、トヨタ生産方式はトヨタグループにおいては最善の仕組みであろう。ただし、別の業種業態の企業が、前提条件の違いも考えずに、かんばん方式やらアンドンやら、道具立てだけを導入したって、うまくいかない。だから自分の立ち位置を分析した上で、ジャスト・イン・タイムの本来の目的を実現するための、（トヨタ流とは違う）様々の定石を紹介しようとの意図で書いている。 ところで、そうは言いながら、わたし自身が最近、トヨタ用語についうっかり乗って、踊らされてしまったことがある。冒頭にも書いた“見える化”である。これをプロジェクトに適用しようと、最近あれこれ試みていたのだが、どうも根本的な勘違いをしていたらしいことに気がついたのだ。 いうまでもなく、プロジェクトというのは状況が把握しにくい（見えにくい）代物である。プラントは目に見えるからいいだろ、とよくIT業界の人に言われるが、それは実物を建設する段階に入ってからのことで、そんなのは後期の話である。初期から中期にかけて設計段階や調達段階での進捗や品質状況は、やはり分かりにくいのである。それでも、なんとか種々のテクニックで進捗や費用を数値化して、予実対比することはしている。 問題は、PERT/CPMやEVMSなどで計数管理しにくいエリアである。具体的に言えば、コミュニケーションとリスク（イシュー）だ。こうした、プロジェクトの深層に位置するマネジメント・エリアの把握は、非常に困難である。それをなんとかしよう、グラフ化して見える化してみようと、調査やらアンケートみたいなことを試みた。 たとえば、自分が消費している時間の何割がコミュニケーション仕事で使われているのか、また何割は追加変更や手戻りなどの想定外の仕事に使われているのか、を集計してみたのである。ちなみにエンジニアリング・プロジェクトでは、一般に30%近くが変更や手戻りで浪費されている、と言われている。わたしはこの通説の正確な出典を知らないが、あるいは米国Constrcution Industry Instituteあたりなのかもしれぬ。ともかく、予定外の仕事にどれだけ時間を割いているのかを“見える化”しようと思ったのである。 しかし、3割なんてとんでもない。結果は意外なほど小さかった。じゃあ、わが勤務先は別格に生産性の高い職場なのか？ あいにく、そうとは思えぬ。つまり回答者達は、どんな追加変更やリワークが起きようが、「予定外」とは捉えなかったのである。どこかにボタンの掛け違いがあったらしい。わたしはあわてて、もう一度原典に当たることにした。つまり、トヨタ生産方式における“見える化”の意義を調べ直したのである。 もともと“見える化”は、トヨタ生産方式における改善手法とともに有名となり、世に知られるようになった概念である（本家に遠慮して、「可視化」と呼ぶ人も多い）。ところで、本家トヨタにおける“見える化”の概念とは、次のようなものであった（宮崎洋 他：「見える化」実践のポイント、三菱総合研究所所報、Vol. 57, 134-155 (2008)を参考にさせていただいた）： (1) 異常管理を“見える化”の中心に据えている トヨタでは正常な業務の中で異常を顕在化させる仕組みを「見える化」と呼ぶ。一番いい例が「アンドン」で、工場の生産ラインで機械の故障等が起き、ある工程がストップ状態になった際に、「アンドン」を灯して皆に分かるようにする。 言いかえるなら、作業結果や状況を示す値それ自体ではなく、あくまで正常値や目標との「ギャップ」を見える化するのが本家トヨタ流である。そのためには、このギャップは異常、と判断できる「標準・基準」が必要となる。 (2) 自律分散型管理とワンセットになっている "自律"とは、「自らやっていることの正否を判断する機能と権限を有すること」である。これができない現場で「見える化」しても意味がない。そして、問題を解決できるのが自律である。だから、問題発生と同時に、解決・改善状況も「見える化」するようにすべきである。 (3) あくまで目的達成の手段である 目的を明確に説明できない「見える化」は、トヨタにおける見える化とは根本的に異なる。「見える化」は会社の方針管理とKPI目標にはっきり結びついているし、アクションにつながらなくてはならない。 (4) 情報を取りに行くのではなく「目に飛び込んでくる」状態を作る だから、何かを調べて集計グラフや図表にして、それで「見えました」ではダメなのだ。 このように、トヨタの“見える化”は、会社全体のマネジメント意識と密接に結びついている。だから自社において実現する場合も、本来の目的意識を忘れないように取り組まなければならないことが分かる。 ・・と。それはいい。 しかし、「正常を異常と区別できる」ことが重要と明言されているが、わたし達の場合、ここが問題であった。「正常」とは、つまり「標準動作」である。くりかえし、同じ動作・操作ができること。これが標準である。“標準なくして改善なし”もよく知られたトヨタの標語だ。 ところが、プロジェクトというものはその定義上、本来ユニークな、一回限りのものなのである。プロジェクトにおける標準とは、何だろうか。たしかにレンガ積みだけ延々繰り返す「万里の長城プロジェクト」なら、標準作業も設定できるだろう。しかし、たいていの現実のプロジェクトでは、そうではない。少なくとも、一番知りたい設計・調達段階の標準とは何なのか。そして、何が異常なのか。そもそも個別の環境変化に対応できることこそ、プロジェクト・マネジメント能力なのではなかったか？ という訳で、この問題は（少なくともわたしは）まだうまく解決できないでいる。むろん我が職場では、設計でイシューが発生するたびに机の上にアンドンを灯す、という風には「見える化」できないだろう。アンドンと同時に、ライン全員が手を止め、問題解決のために走ってきて必要な手を打つ、というのもありそうもない話だ。トヨタの生産ラインではこれが出来るのである。それは、作業の繰り返し性が高いからだ。だが、毎度ユニークな世界に生きているプロジェクト屋のわれわれは、まだしばらく頭をひねらなければいけないらしい。 Sさん。前回は、仕事の指示に最低限必要な4つの情報についてお知らせしました。それは「アウトプット」・「インプット」・「リソース」・「完了条件」の4つでした。今回はそれとは別の角度から、リーダーとして理解しておくべき事を書きたいと思います。
Sさんは、Action Listという道具をご存じですか。これはプロジェクト・チーム内で共有する、一種のTo Doリストです。プロジェクトで、必要なActionが発生したら、期限と担当者を決めてリストに記入します。そして、毎週の定例ミーティングなどでステータスを追いかけるのです。「課題管理表」という名前で、顧客と共有する使い方をしているところもあるでしょう。呼び方は会社により様々です。Action Listは典型的には、以下のような表になっています。 番号 アクション内容 記入日 期限 担当者 ステータス －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ １２ マニュアル制作会社に連絡 ７月１７日 ８月３０日 佐藤 完了 １３ Ｃ社に開発機を貸し出す ８月１１日 ９月１０日 田中 － １４ 営業部長にタイミングを相談 ８月１８日 ９月１５日 中村 － ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ これ自体は変哲もない道具ですし、広く使われています。ただ、このAction Listを見るたびに、わたしは思い出すことがあります。あるIT系企業のX社と共同で製品開発プロジェクトをやっていた時のことです。X社側は体制をかためるために、新たに一人、経験者を雇ってソフト開発チームのリーダーにすることにしました。Kさんというのが、彼の名前です。30代だったでしょうか。前は準大手のSIerにいて、X社に転職してきたそうです。 Kさんの初仕事は、週次のミーティングで挙がった作業項目をAction Listにまとめる仕事でした。ところが、数日後にメールで送られてきたAction Listを見て、思わずわたしは部下と顔を見合わせため息をついてしまいました。その表は、Microsoft Wordの表機能で作られていたのです。 「ダメですね。これじゃ、使えないや。」わたしの部下は気短に言い捨てました。 「うん。・・ちょっと、うまくないかもね。」と、わたし。 なぜそう思ったか、おわかりでしょうか。Action Listは、わたし達が想定していた事と、現実の要求事項の間のギャップを調整するための道具です。だからプロマネやリーダーは、毎日これを眺めて暮らすことになります。その時、Action項目は全体でいくつあり、その中で未完了の項目はどれくらいあるのか、また一番期限に遅れているのはどれか、誰が一番多く抱えているのか、などを必ず気にかけるはずなのです。 ところが、Wordの表では、こうした数の分析がすぐにはできません。ということは、このK氏は、そうした見方に気を回したことが一度も無かったらしい事を暗示しています。普通だったら、こうした表はExcelその他、データ処理のしやすい道具で作るでしょう。 Actionの中には重いのも軽いのもあるのに、単純に数なんかかぞえる意味なんかあるのか？ そう反論する人もときにいます。でも、そういう人だって、お宅は何人家族ですかと聞かれて、“大人も赤ん坊もいるのに、そんな質問に意味はない”とは答えますまい。日本の経済成長率はOECDの順序で何番目か、という質問に、“大国も小国もあるのにナンセンス”と言うでしょうか。 もしActionの手数に違いがあるというのなら、ABCとか松竹梅でもいいから、重みをつけて加重計算すれば良いだけです。問題は、自分のプロジェクトの状態やパフォーマンスについて、数値化しようという意識が少しでもあるかどうかなのです。 数字はいつも見ているさ、だって予算もスケジュールも工数も、しょっちゅう確認しているし、上からうるさく言われるじゃないか－－K氏だって、聞けばこう反論してきたかもしれません。ところで、それは顧客や上司から要求されるから見ていたのでしょうか。要求がなくても、自分から測ったでしょうか。 測れないものはマネジメントできません。何かの状況をつかみたかったら、そして向上させたかったら、それを測るためのモノサシと基準が必要です。「あと少しです」「頑張っています」「出来は良いですよ」－－こうした『言葉による形容』では、主観による比較から抜け出せず、検討しても決着がつきません。何かをどうにかしたかったら、改善や変革をしたかったら、対象を数字で測る習慣をつけるべきです。測りにくい対象でも、多少強引にでも数値化するマインドこそ、マネジメント・テクノロジー化への第一歩なのです。 そして、どのような時にはどのモノサシを選ぶべきか、その精度はどの程度の粗さか、それで何を見たいのか、つねに意識していかなければなりません。 K氏は残念ながら、一月ちょっとでその会社を辞めていきました。穏和な性格で頭もそれなりにいい人です。上司との折り合いその他、いろいろ事情もあったのだとは推察しました。彼は辞めていく時、わたしにだけメールを送ってきました（別の会社だから、かえって言いやすかったのかもしれません）。その中で彼は、憤懣やるかたないという調子で、「私の仕事は、工程表をつくるという事だったというのです！」と書いていました。 しかし、「当たり前じゃないですか。それが貴方の仕事ですよ」というのが、読んだわたしの感想でした。SE上がりのK氏は、開発プロジェクトのリーディングを、設計の指導か何かのように考えていたのでしょう。工程表作りなど、本筋とは無縁な管理的雑用だと。でも、それは勘違いです。それはちょうど、映画の助監督に採用された人が、現場の段取りやキャストとの調整をわきにおいて、脚本のストーリーばかりに首をつっこむようなものです。デザイン（What）とマネジメント（How）は別物であって、小さなプロジェクトではチーフ・デザイナー自身がリーダーを兼務することもありますが、それは脚本兼監督みたいなもの。デザイナー＝リーダーが、本来の姿だと思うのは誤解です。 工程表作りは、立派なHowのプランニングです。そして、現実のスケジュールがプランからどれだけずれているかを測って監視していく。遅れたら原因の問題をつきとめ解決していく。これがリーダーに求められるマネジメントの仕事です。Sさんも、これから自分が仕事をリーディングしていかれる際は、「何をもってこの仕事のパフォーマンスを測ろうか」という視点を心にとめておかれるよう、おすすめいたします。
「経済のソフト化」が言われ、「サービス・サイエンス」という新学問が提唱される今日においても、肝心な「サービス」の定義や中身はなかなか定まらない。なぜ、サービスをめぐる議論はかくも混乱するのか。前回も書いたとおり、サービス業とは「リソース提供ビジネス」であり、物質的なリソースあるいは人間系リソースの利用権・占有権を売るビジネスだ。通信インフラや鉄道輸送などの物質的リソースについての機能は、工学的に明確なはずである。また人間系リソースの提供にしても、知識労働（弁護士や通訳など）ないし肉体労働（整体師や溶接工やら）の役割は明瞭なはずであり、多くは資格制度も付随している。
それなのに、なぜかしばしば、ノードストローム（米国の高級百貨店＝物販業）やディスニーランドや銀座の高級マダムの接客術みたいな要素が、サービスをめぐる議論の俎上にのせられる。お客様の「おもてなし」や、要望への「気づきの心」が声高に求められるのはなぜなのか。 そこには従来見過ごされていた、あるきわめて重大な種類の労働が関わっているからである。それは『感情労働』である。 感情労働という概念は、'70年代アメリカにおいてConstructivismと呼ばれる社会学研究の中で提唱された（Constructivismは「社会構成主義」ないし「社会構築主義」と訳される）。口火を切ったのはホックシールドいう学者で、その仕事は『管理される心―感情が商品になるとき  』という著書にまとめられている。感情はふつう、それが喜びであれ悲しみであれ、私生活において適切に表出し、互いに贈り合うことで、人間関係を円滑に成り立たせる機能を持つ。つまり、感情とはプライベートな社会関係において必要不可欠な資源（リソース）なのである。ところが現代社会では、この感情が商品化され、仕事の領域でも使われる。サービス業の従事者は、その仕事の一環として感情を制御することや、顧客に「感情の贈り物」を提供することを求められる。これが「感情労働」である。ホックシールドが研究対象とした一例は、航空会社のフライト・アテンダントだった。業務としてひんぱんに感情操作を求められるこの職種では、労働強化は労働者の情緒障害と自己疎外を招く、とホックシールドは警告した。彼女の研究に続いて、ショット、ケンパーなど気鋭の社会学者達が、感情の社会学とも言うべきこの分野に入ってくる（ここらへんの事情については、中川伸俊氏の「社会構築主義と感情の社会学」という論文－以前はネットで公開されていたが現在はリンク切れになっている－によって勉強させてもらった）。 ところで、何でわたしがConstructivismなどを調べているかというと、プロジェクト・マネジメント研究に関係するからである。毎年夏に欧州の主立ったPM研究者が集まるEDEN PM Seminarという会議があり（今年もちょうど今週、仏Lilleで開催中）、3年前にそこで知ったからだった。欧州のPM研究は、方法論を徹底的にやるのが特徴であるらしい。日本の、実務的だがある意味ナイーブなPM研究との違いには、心底驚いた。ただ単にアンケート調査やケース・スタディをしてみたらこういう結果になりました、というだけでは研究として相手にされない。いかなる理論的枠組みで、なぜこのような方法をとったのかが、厳しく問われるのだ。そこに登場するのがConstructivismやPositivismやCritical Theoryといった理論で、様々なプロジェクト（それ自体は各々ただ一度限りの社会現象である）を、どう把握し分析するかの導きとなる。 話を元に戻すが、感情は人間が「生まれつき自然に」持つのではなく、社会的に訓練され構成されるものである、というのがConstructivismの立場だ。そして、社会的場面に応じて、適切に感情を表出／制御するべく、人々を動かしていく（たとえば社長による深刻な訓話の最中に笑い出したりしない、といったように）。これを社会の『感情規則』と呼ぶ。 そして、世の中には、感情を相手に応じて制御しなければならないタイプの労働がある。これが感情労働なのである。ホックシールドはフライト・アテンダントを研究したが、その著書の翻訳者である石川准氏は、看護師の感情労働を例に挙げている（わたしの長年の友人である彼は、全盲の社会学者であり、また天才的プログラマーでもある）。たしかにナースの仕事は、知識労働もあり肉体労働でもあるが、同時に絶え間ない感情制御を伴う労働でもある。看護師たちは感情を酷使されている。と石川氏は言う。ちなみに看護師には喫煙者が多いと言われているが、喫煙の害を誰よりもよく知っているはずの彼女たちが喫煙に向かうのは、このような仕事のストレスが生むのかもしれない。 感情労働には、感情を抑える仕事と感情をつくる仕事の両方が混じっている。これを職業的に求められる職種は、CAやナースだけではない。たとえば、俳優もそうだ。そして、あらゆる業種をまたいで、広く感情労働が必要な職種がある。営業職だ。 セールスの現場はまさに、感情労働のかたまりである。相手にあわせ、相手を不快にせず、しかも相手を自分に都合良く誘導しなくてはならない。そのために必要な感情の制御はかなり高度なスキルであるし、またそのことが営業マンの消耗とストレスの原因ともなっている。 セールスマンの感情労働を見事に描いたマンガに、業田良家の「ゴーダ哲学堂  」がある。「オレってまるで、ロボットじゃん」と、その登場人物は言う。実際彼の姿はスーツを着たロボット風に描かれている。理不尽な客のワガママにぶつかると、彼は「感情制御装置」のキーパネルをとりだし、『笑』のスイッチを押しては「ハッハッハッハッ。冗談きついなぁ店長さん。」と笑顔を作り、『哀』を押して「かんべんしてくださいよ～～。」と泣き落としにかかるのである。ただ、『怒』のボタンはひどく小さく、押しにくいようにできている。そして、「感情全テノボタンヲ、強ク激シク、毎日ツカワナケレバイケナイ」と独白するのである。以前「新しい販売マネジメント思想こそ、競争力再生の要点である」に書いたように、現代日本の成熟市場においては、営業とは顧客ニーズの創出と供給側のコントロールを同時に行う“きわめて高いインテリジェンスを求められる仕事”になっている。それに加えて、この感情労働だ。今日の競争力のかなりの部分が営業にあるにもかかわらず、これをリードする思想は成熟していない。その理由は、「感情労働」という知識労働でも肉体労働でもないあたらしいカテゴリーの概念を、きちんと認識していないためである。概念がないから、教育訓練の方法論もない。パフォーマンスの尺度もない。これで販売をマネジメントできる訳はない。 そして、もう一つ、感情労働が重要な役割を占める職種がある。それがプロジェクト・マネージャー職だ。わがままな顧客と感情をすり合わせ、疲弊したチーム員を慰撫し、居丈高なくせに不安そうな上司には、信頼感を持たせる。これら感情を素早く切り替えて表出し、なおかつ計画やら報告やらにも気を配らなければならない。プロマネが世にも大変な職種である理由は、このような感情労働のレイヤーが、他者にも自分にも見えていない（だからその報償も得られない）ことにあるのではないか。 わたしは、知識労働も肉体労働も感情労働も、別に上下や貴賤はないと考えている。社会学者達は「商品化される心」というタイトルからみて、感情労働にネガティブな視線をなげかける傾向があるようだが、どんな労働だって、それが過重で無報酬だったら、人を壊してしまうと思う。一定のニーズが社会の中にあるのだから、感情労働にもちゃんとした地位を与えればいい。感情労働に問題があるとしたら、人がそれを認識しないまま、当然のサーヴィス（無料）として「感情」のリソースを浪費してしまう点にある。プロマネ達がみんな疲弊してしまわないためにも、マネジメント業務の中に感情労働のスキルと価値があることを、皆もっときちんと意識すべきだと思うのである。 9月から10月にかけて、３〜４回ほど講演の機会をいただきました。
直近で決まっているのは次の2件です。関西での講演もありますので、ご興味のある方のご来場をお待ちしております。 １ PMI日本支部 9月度 法人スポンサー連絡会 「大規模プロジェクトにおける問題発生の構造と“気づき”について － PMOの立場から」 （40分） 9月14日（水）午後 場所：株式会社三菱総合研究所 4階大会議室 内容： エンジニアリング会社の遂行する海外プロジェクトにおいて、問題発生の早期把握は死活的に重要である。問題の発見と報告は、担当者・PM・PMOの3つのレベルで重層的に行われるが、「責任感ゆえの抱え込み」「心理学的なジョハリの窓」などが障壁となることもある。プロジェクト問題発生の構造と機序を解説し、“気づき”と“見通し”のある組織運営への課題について取り組みを述べる。 ２ スケジューリング・シンポジウム2011 （スケジューリング学会主催） 「リスク確率に基づくプロジェクト価値評価 － その理論と応用」 （120分） 9月24日（土）午後 場所：大阪工業大学 内容： DCF法のNPVに代表される従来のプロジェクト評価手法は、計画時点での静的な評価が中心であり、かつプロジェクトを内部構造を持たぬ「点」のように扱ってきた。演者は数年前より、プロジェクトの内部構造を反映した動的評価方法として、リスク基準プロジェクト価値（RPV）による分析フレームワークを提案してきた。本講演ではRPVの意義と計算法を説明し、さらにプロジェクトに最適予算が存在することとその求解法、評価精度の検討、ならびにプロジェクト・ネットワークの最適設計などについて解説する。 スケジュール計画立案の中心は、時間の見積だ。これから行なわなくてはならないタスク（課業）の所要時間をどう見積もるか。この正確さが、計画全体の信頼性を決めるといっても過言ではない。
タスクの時間見積には、一点見積と、三点見積法がある。一点見積とは、文字通り、作業時間を一点で見積もる方法だ。たとえば、「外部インタフェース設計」というタスクがあったとして、その作業時間は３週間、というたった一つの値を、いきなり見積もる。それが過去のデータを整理して求めた値だろうと、あるいは経験者が“エイヤー”で決めた値であろうと、最初から一点で答えを求める方法が、一点見積だ。生産計画手法としてのＭＲＰが、ＢＯＭ（部品表）に付随してもっている標準リードタイムは、その典型だ。 それに対して、三点見積法は、確率的変動に基礎をおいている。同じ作業を繰り返し行なっても、所要時間にはいろいろな幅がでる。そこで、所要時間の「最善値（＝最短期間）」「最悪値（＝最長期間）」「最頻値（＝その期間でおわる頻度が最も高い値）」の三種類の数字を見積もる。そして、 推定所要時間＝（最善値＋最悪値＋４×最頻値）÷６ という式によって、所要時間を求める。 三点見積法は、ＰＥＲＴの歴史とともに生まれた。その背景には、所要時間はさまざまな外的要因によって変動するため、確率的にしか定まらないという思想がある。しかも、その変動の形は、平均値のまわりに対象に分布する正規分布ではなく、プラス側（右側）にダラ下がりとなる、非対称な分布だろうと考える。その一つのモデルとしてベータ分布を用いると、上記の式が得られるのである。 しかし、この二種類の時間見積法には、ともに欠点がある。それは、総所要期間と純作業時間の区別が十分にされていない点だ。 総所要期間（elapsed time）とは何か。それは、タスクにとりかかってから、それが完了するまでの、全体の期間だ。「総所要期間＝終了時刻－開始時刻」と定義してもよい。一方、純作業時間（duration）とは、作業者がそのタスクを完遂するために、本当にそれにかかわっている時間だ。前者は後者よりも、通常長い。総所要期間≧純作業時間となるのが普通だ。 それでは、なぜその両者に差が出るのか。プロジェクト・マネジメントの教科書的ガイドブック「PMBOK Guide」では、コンクリートの養生作業を例にとって、実質２日間のdurationで終わるはずの作業も、金曜日に始めたら週末の二日間の休日のために月曜日いっぱいかかり、実質４日間のelapsed timeになるかもしれない、などと説明する。これは、カレンダー日数と、終業日数の違いから来る、単純な例だ。 しかし、差異の本当の原因は、じつは作業者のマルチ・タスキングから来ることが多い。作業者が複数のプロジェクトのタスクに従事しているとき、おのおののタスクに着手から完了までつねに没頭できるケースはまれである。往々にして、別のプロジェクトの用件の邪魔が入り、作業を中断したりスイッチしなければならない。このために、総所要期間≧純作業時間となるのである。 かりに一歩譲って、マルチタスクによる割り込みや時間の分散がなく、担当者がつねに一時に一つのプロジェクト・タスクに従事したとしても、総所要期間≧純作業時間 となる場合がある。それは、その担当者の決済箱にたくさんのタスクが入ってきて、処理待ちの行列を作っているときである。 これはちょうど、大病院は３時間待ち・３分治療だ、という皮肉と同じ現象である。一人一人の患者に対する医師の作業時間は３分だ。決して複数の患者をマルチタスク的に並行して診ているわけではない。しかし、大勢の待ち行列のために、患者の側から見ると作業期間は３時間になってしまう。 プロジェクトにもこれと同様の事象がおこる。特定の繁忙部署やボトルネック工程の前には、長い行列ができている。ＰＥＲＴ／ＣＰＭの弱点は、ここだ。クリティカル・パスは純作業時間ではなく、総作業期間の長さで決まる。しかし、この例のような状況では、一つのプロジェクトの中だけを見ても、クリティカル・パスは定まらない。かといって、『平均滞留率』のような曖昧な指標にたよるのも、ありがたくなかろう。 プロジェクト・スケジューリングにも、複数のプロジェクトを同時に計画し、うまく優先順位法や山崩しのできるツールが求められているのは、このためなのである。もっともその場合でも、プロジェクト間のトレードオフは、計画者の判断が必要になるのであるが。 アクティビティが『お仕事の最小単位』であり、マネジメントの基本部品であることは前回の説明でご理解いただけたと思う。このアクティビティは、ときに「タスク」と呼ばれることもある。わたしも以前はタスクという呼び名の方を使うことが多かった。だが、プロジェクト・スケジューリング（特にＰＥＲＴ／ＣＰＭ）の理論では伝統的に「アクティビティ」の語が用いられてきたこと、さらに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などでは、仕事の最小単位をアクティビティと呼ぶかわりに、これら三大指標の頭文字をとって、最近『ＣＴＲ』と呼んだりしている。名は体を表す、面白い言い方である。どこに着目すればいいか、初級マネージャーにとっても明確である。そして、一つの仕事が終わるたびに、これら指標を計測し、前回述べたようなアクティビティの辞書に実績を記録してデータベース化していくのである。ここまで実現できたら、たしかに「マネジメント・システム」と呼んでも良いだろう。
「マネジメント」という行為の、最も原初的な定義は“人に働いてもらう”ことである。人に働いてもらうことで、自己の、あるいは共通の目的を、達成する。自分自身で手を動かして自己の目的を達成することは、マネジメントとは呼ばない。単に作業とか行為と呼ばれる。
あなたがもし食卓で母親に「ねえ、そこのお塩とって。」と言って手渡しもらったら、あなたは、その瞬間だけは、母親をマネジメントしているのである。母親に働いてもらって、自分の目的を達したからだ。でも、何も言わない前に、母親が気を利かせて塩をとってくれたら、もちろんマネジメントしたことにはならない。そもそも、座っているだけで目の前に夕食が出てきたとしても、たぶんそれは母親が自発的に調理をしてくれたのであって、自分がわざわざ命令を下してやらせている行為ではない。はっきりした依頼や指示や命令の有無が、マネジメントと、自発的な協調行動との境界線になる。 「はっきりした依頼」とは何だろう？ まずは、具体的な作業の内容である。なにかをとってもらうという行為は、大げさに言えば輸送の作業である。輸送であるからには、対象物（荷物）、現所在地、そして送り先が必要になる。“そこ”にある“塩”を“（自分の手元に）”とって、という事項を最低限伝えなければ、相手は動きようがない。 それが何かを作る作業だったら？ たとえば玉子を焼いて欲しいとき、具体的に言うべきことはなんだろうか。まず、欲しいアウトプットを正確に伝えなければならない。目玉焼きなのか、厚焼きなのか、錦糸玉子なのか。卵１個分か２個分か、はたまた100個分なのか。味付けは濃いめか薄めか。つまり、アウトプットすべきマテリアルの種類・数量・品質属性を指定するわけである。 ついで指示すべきは、いつまでに欲しいのかである。今すぐなのか、夕食の時でいいのか、あるいは３日後のパーティの時の話をしているのか。つまり納期を指定するわけだ。 さらに、インプットを指定してやる必要があるだろう。材料である。相手が母親ならば、どこに何があるか全て承知している。しかし、アパートを訪ねてきた友人に依頼するときは、「卵は冷蔵庫にあるし、油と調味料は食器棚の横に」と教えてやらなければなるまい。自分で支給できないときは「来るときコンビニで買ってきて」と、相手による調達を頼ることになる。 アウトプットと、納期と、インプット。これだけでいいだろうか？ 大事なものが、まだある。『リソース』である。リソースというのは、作業を完遂するために必要な道具や場所や用役のことを指す。フライパンはどこ？ あ、それは流しの下だ。ガスレンジは？ えーと、電磁調理台しか無くてね・・ インプットとリソースの違いは、インプットが作業に使われて無くなる（アウトプットに転換する）のに対し、リソースは作業が終わったら解放されて元に戻ることだ。フライパンもガスレンジも、消えて無くなりはしない。ただし多少減耗する。そしてリソースは、作業中には占有される。つまり、いってみればリソースというのは化学反応における触媒のようなものなのである。 （念のため、注。ここでいうリソースとは、あくまで生産管理やプロジェクト・マネジメントでいう用語であり、「生産資源」などと訳されることもある。資源工学の世界で言う、海の底に眠っているかもしれない利用可能な物質やエネルギー類とは異なる） リソースの中で、最も重要な種類のリソースは「人」である。作業に必要で、作業中は占有され、作業が終わったら解放される。これを英語で、Human resourceという。直訳すると人的資源だが、リクルートの場面では人材とか人財とか訳され、本社上層の会議室の中では要員・労働力などと呼ばれたりする。作業を終えて解放したときは多少減耗しているので、再生するためには、休ませたり眠らせたり食事をとらせたりお酒を飲ませておだてたりしなければならず、けっこう手間暇のかかるリソースである。 それでもまあ、ある局面では稀少な価値ももたらすことがあるので、大事にしなければならない。君でなきゃダメなんだ、君の作ったのを食べたいんだ・・・。「君の作る味噌汁を毎朝飲みたい。」－－などという陳腐な文句が、いまどき意図した通り機能するかどうかは知らないが、リソースの指定はたいていの場合、重要である。 アウトプットと、インプットと、リソース。そして納期（これはもう少し一般化して、「完了条件」と言ってもいい）。これで完璧だろうか？ じつは、マネジメント上、とても大事なことが抜けている。それは情報である。「指示情報」と「報告情報」のやりとりが必要だ。 指示情報とは、これまで列挙してきたアウトプット・インプット・リソース・完了条件などの伝達である。さらに、必要に応じてはレシピ（つまり設計情報ないし作業手順情報）も渡してやらなければならないかもしれない。もっとも、家族や、同一組織内では、お互いに了解している事項が多いので（これを「コンテキスト・レベルが高い」と形容する）、アウトプットと完了条件だけ指定すれば、あとはくだくだ言わなくても通用するはずである。 報告情報とは、完了時、ならびに（必要に応じ）途中途中で、作業がどういう状態であるか、アウトプットはどうなっているかを、指示した人＝マネジメント主体に対して伝達するための情報である。誰かに働いてもらっているとき、終わったのか終わっていないのかも分からず、どういう状態にあるのかもさっぱり把握できていないのでは、「マネジメントしている」とは到底言えない。「お塩とって」のように、目の前で一瞬にて終わる作業ならば別だが、海を離れたところにいる誰かに２ヶ月かかる仕事をしてもらう際は、報告情報をもらわなければ困ってしまうだろう。 なお、ここまではインプットもアウトプットも物（マテリアル）である場合を記したが、作業の種類によっては、統計分析や企画書作成のように、インプットもアウトプットも情報やデータとなる場合もある。この場合、作業インプットとしての情報・データと、指示情報とは区別して理解すべきである。 ところで、指示／報告情報に関連して一点注意したいことがある。マネジメントにおいて、上記のアウトプット・インプット・リソース・完了条件を指定して依頼した場合は、原則として、依頼を受けた側がどのような手順で進めるか（すなわち相手の業務の「内部プロセス」）については、途中でいちいち口をはさまない。小姑のように、箸の上げ下ろしまでいちいち指示をしてはいけない。マネジメントというのは、際限のない命令-服従関係とは異なる。ある仕事のまとまりを、他者に指示したら、その内部には立ち入らず、相手の権限範囲とする。相手が自発的に改善できる領域を与える。これがマネジメントにおける「仕事の最小単位」の意味である。 プロジェクト・マネジメント理論において、この仕事の最小単位を『アクティビティ』と呼ぶ（「タスク」と呼ぶこともある）。ＷＢＳを作っていくとは、プロジェクト全体を、このようなアクティビティに階層的に分解していく過程を指している。アクティビティはいくらでも下位のサブ・アクティビティに際限なく分解可能だが、適切なレベルでとどめておく（最下位レベルのアクティビティを「ワーク・パッケージ」とも呼ぶ）。  そして、各アクティビティの、アウトプット・インプット・リソース・完了条件・指示情報・報告情報を明確に文書で規定しておく。できればリスト化し、あるいは辞書のようにデータベース化しておくと良い。そして誰でも必要に応じてアクセスできるようにしておく。 このような形でアクティビティを定義しないまま、共通経験の乏しい（コンテキスト・レベルの低い）海外子会社や外注先に仕事を依頼したって、うまく仕事がマネジメントできるわけがない。オフショア開発を上手に進めたかったら、自社の求めるアクティビティをきちんと規定するところから、まず始めるべきなのである。
今週、幕張で開催されるプロジェクト・マネジメント関係の国際学会「ProMAC 2010 Tokyo」において、10月14日（木）午後に、
"Risk-based Project Value: Analysis on Budget Overrun and Progress Measurement" のタイトルで講演発表を行います（英語）。 ご興味のある方は、よろしくご来聴ください。 < 前のページ次のページ >
|
 by Tomoichi_Sato 検索
カテゴリ
著書・姉妹サイト
以前の記事
最新のコメント
最新のトラックバック
お気に入りブログ
ブログパーツ
ファン
 |
