人気ブログランキング |

カテゴリ:プロジェクト・マネジメント( 154 )

お知らせ:浜松でプロマネ育成研修セミナーを開催します(3月11日・18日)

来る3月に、NPO法人浜松ソフト産業協会が主催する

 「プロジェクトマネージャー育成研修」

の講師を務めます(静岡大学大学院事業開発マネジメントコースと浜松信用金庫が協賛予定)。
 これは11日と18日の土曜日二日間にわたって開催される研修セミナーです。わたしはその初日を担当し、

 「モダンPM論への誘い — プロジェクトをマネジメントする『技術』とは何か

と題して、プロジェクト目標の設定(ミッション・プロファイリング)、WBSの作り方、アクティビティの構成要素、プロジェクト組織と役割、そしてリスク・マネジメントなどについて講義する予定です。また関ものづくり研究所の関伸一氏によるプロジェクト・ケーススタディを加え、PMに必須な基本的スキルを1日できちんと身につけられるよう、演習を交えた実践的なレクチャーを行うつもりです。

 二日目は静岡大学の八巻直一名誉教授による、PERT手法(スケジューリング)の実際などに関する研修です。

 場所は静岡県浜松市の浜松情報専門学校 6階実習室です。
  (静岡県浜松市中区中央3丁目10-31)
 定員は20名で、有償ですが、実践的で役に立つ内容となっています。

 昨年も浜松で同じタイトルのプロマネ育成研修を行いましたが、今年はさらにバージョンアップした内容になっています。なお主催はソフト産業協会ですが、内容は必ずしもIT分野のプロジェクトだけに限らず、技術リーダーを目指すエンジニアの方全般に役立つよう考えております。

 単なる資格試験のためのお勉強ではなく、本当に実務に役立つプロジェクト・マネジメントの基本を身につけたいと考えている方、上記URLにある案内パンフレットの申込先にて受け付けしております。定員が限られておりますので、お早めにお申し込みください。積極的なご来聴をお待ちしております。

  佐藤知一

by Tomoichi_Sato | 2017-02-05 18:50 | プロジェクト・マネジメント | Comments(0)

プロジェクト・コミュニケーションのベーシック(2) ~ ドキュメント・インデックスを作る

前回の記事「プロジェクト・コミュニケーションのベーシック ~ 情報のトレーサビリティを確立する」で、英語で言うCommunication Managementとは、日本語的感覚でいう「コミュニケーションの管理」ではなく、むしろ『情報伝達のマネジメント』に近い、と書いた。だから、伝達のトレーサビリティ確保が大事になる、と。

今回はその続きである。だがもう一歩進んだあり方として、「ドキュメントのインデックス化」の話をしたいと思う。ドキュメントのインデックスとは何か? 簡単だ。それはプロジェクトが作成する文書・図面類をリスト化して、多少の属性を付加したものである。「ドキュメント・リスト」と呼ばれる場合もある。

なあんだ、そんなのならいつでも作ってるよ。そういって、ドキュメントが保存されているサーバのプロジェクト・フォルダから、ファイルのリストを印字して持ってくる人がいる。ファイル名の他に、作成日、更新日、ファイルサイズ、種類などの属性が並んでいる。--これのことでしょ?

全然違うのだ。そんなリストは、プロマネにとってどんな行動の契機も与えない。そのファイル・リストを見たら、まだ出来上がっていないドキュメントが何と何か、分かるだろうか? どの図面が予定よりはるかに遅れて作成されたのか、問題発見の手がかりになるだろうか。誰を応援したり督促したりすべきなのかの、判断材料になるだろうか? なるまい。

プロジェクト・マネージャーという職種は、最初に計画を立て、実行段階ではその計画からの逸脱をチェックしながら、問題をつぶしたり変更を追いかけたり、決断を下したりして、なるべくプロジェクト全体の生み出す価値を高めていくのが仕事である。だから問題発見のツールをいろいろ持っていて、そのセンサー感度を上げる仕組みが必要だし、問題解決のためには、何がいつどこで起きたのかを、正確にさかのぼってたどれる道具が必要なのだ。

ドキュメント・インデックスは、そのためのツールである。これ自体は、単純な表になっている。プロジェクトで作成しなければならないドキュメントを、すべて、重複も漏れも落ちもなく、計画段階であらかじめリストアップしておく。そして、各ドキュメントは、誰が担当で作成するのか、WBSのどのアクティビティで作成するのか、したがっていつ作成される予定なのかを、あらかじめ決めて書いておく。

つまり、ドキュメント・インデックスは、初期段階では「まだ存在していない文書の属性付きリスト」なのである。ファイル名のダンプリストじゃ役に立たないことは、おわかりだろう。それは「すでに存在している文書のリスト」を示すだけだ。あるいはもう少し高級な、いわゆるContents Management System風のリストも、役に立たない点では変わりない。そうした道具立ては、存在しているファイルの『在庫管理』には有用だろう。だが、まだ存在しない、これから作成すべきドキュメントについてのコントロールには、あまり役に立たない。

ドキュメント・インデックスというは次のような構造をしている。持つべき主な属性は、以下の通りだ:
e0058447_22301426.jpg

(1) ドキュメントのID
(2) ドキュメントの名称
(3) ドキュメントのリビジョン番号
(4) プロジェクトNo.およびWBS No.
(5) 発行目的
(6) 作成者・検討者・承認者
(7) 発行予定日
(8) 発行実績日
(9) ドキュメントを構成する電子ファイルのリスト

すべてのドキュメントは、ユニークなIDを持っていなければならない。これは当たり前のことだ。従業員番号のない社員がいてはいけないのと同じである。何かをトラッキングしたりコントロールするためには、IDがいる。これは情報システムの世界では常識であろう。(それなのに、自分が仕事をする段になると、設計文書をタイトルだけで『管理』して平然としているシステム・エンジニアがいたりするのは若干、謎である)

ドキュメントにはリビジョン番号があるのは当然だが、WBSの中のどのアクティビティで作成されるものかを示すことも(当然ながら)大事である。誰が担当で、いつ出来るのかは、それによって決まる。作られたら、次にどこのアクティビティで利用されることになるのかも、注意しなければならない。かつて「仕事の最小単位--アクティビティの構造を学ぶ」にも書いたように、文書(情報)はアクティビティのアウトプットであると共に、次のアクティビティのインプットともなるからだ。

ちなみに、わたしの勤務先では、ドキュメントのIDは、種類を示すコードと、それを作成するアクティビティのWBS No.を元にして構成している。一つのアクティビティから複数のドキュメントが作られるのが普通だから、後ろに連番をつける。かつ、それを電子ファイルの命名規約にもしている。ついでながら、仕事のプロセスを示すFunctional WBS (F-WBS)は標準的なコード体系にしたがっているため、どのプロジェクトでも、たとえばポンプの設計図書は同じF-WBS No.を持っている。だから、ドキュメント番号やファイル名称を見ただけで、「これはポンプの調達仕様書だな」と分かる仕組みになっている。

それから、インデックスには、何のために発行されるのかという目的がいる。つまり、顧客に出す承認用(For Approval)だとか、顧客からOKをもらった施工用(For Construction)だとか、あるいは据付工事後の最終納品版(As-Built)といった区別である。もちろん、顧客に気に入られないと、承認用を2回も3回も出し直し、という事態だってありえる。だからリビジョン番号と発行目的は、1対1にはならないのである。ちなみに「発行」という用語は、英語のIssueの翻訳だが、耳慣れないと思う人もいるかもしれない。これは、正式版として社内関連部署や顧客や外注先に対して配布する作業を意味している。「出図」という言い方をする企業もある。

作成者・検討者・承認者の項目は自明だろう(スペースの関係で一つにしているが、実際には別々にするのが普通だ)。

そして何よりも大事なのは、「発行予定日」と「発行実績日」である。プロジェクトの計画段階で、ドキュメント・インデックスを作る際に、個々のドキュメントの発行予定日を記入しておく。これは、プロジェクトのマスター・スケジュールに合致していなければいけない。そして、遂行段階に入って、実際にどんどんドキュメントが作成されるようになったら、それぞれの実績日を記入していくのである。

この予定日と実績日があるから、プロマネは問題を事前に検知したり、メンバーに上手に督促したりすることができるようになるのである。「今週、発行予定のドキュメントはこれとこれです。担当者はもし何か問題を抱えているようなら教えてください。支援します。」といった風に、週次のミーティングでいう訳である。

そして実際に発行されたドキュメントは、必要とする関連部署(下流側のアクティビティに関わる部門)や外部ステークホルダーに送付するとともに、プロジェクトのセンター・ファイルに保管する。情報伝達のトラッキングが必要になったら、プロマネは(あるいは、もう少し大規模なプロジェクトの場合は、専任のライブラリアン役の担当者が)、そのセンター・ファイルと、インデックスの履歴をチェックする。これがドキュメント・コントロールの仕事である。わたしが勤務先でこのようなやり方を初めて知ったときは、その見通しと効率の良さに舌を巻いたが、わたしの先輩達はどうやら何十年か前に米国の同業者達のやり方に学んだらしい。

またこうしたデータがあると、横軸に日付をとって、縦軸に発行予定ドキュメント数の累計をプロットしていけば、S字カーブが得られる。これに実績の線を書き加えれば、プロジェクト全体の遅れや進み具合が一目瞭然になる。一般に、設計作業の進捗は目に見えにくく、把握しづらい。ドキュメント・インデックスは、その進捗を可視化するためのツールになるのである。

e0058447_22311024.jpg
わたしの業界では(海外の大規模プロジェクトは特に)進捗に応じて顧客が支払う契約が多い。このとき、設計の進捗を、発行されたドキュメントの数で測るのである。全体で100部の図面やドキュメントを作成する予定であり、現時点では45部が発行済みだから進捗45%、といった計算である。単純だが、分かりやすい。むろん、図面には情報量の大小があるし、ドキュメントだって厚いのも薄いのもある。だからそんな進捗計算なんかナンセンスだと、いえないことはない。だが、今日までに100部作成する予定なのに、まだ10部しか出来ていなかったら、やはり何かおかしいと判断するきっかけにはなる。測れないものは、マネジメントできない。もし設計をマネージしたいのなら、設計の進度を測る何らかの仕掛けが必要なのだ。

最後は、そのドキュメントを構成するファイルのリストである。本文はWordだが添付資料はExcelの表です、といったものはよくある。こうしたセットを、ひとつの「ドキュメント」として扱うのである。だから、個別のファイル単位にしか属性を扱えないCMSみたいなツールは、ちょっと不便だということになる。

と、ここまで読んだ読者の方は、二つの疑問を持たれるかもしれない。

Q1: 本当に最初の段階で、プロジェクトが作成すべきドキュメントを全部もれなく洗い出せるのか? 途中でどんどん増えてしまったりするのではないか。
Q2: ドキュメントの発行予定日なんて、そんな初期に決められるはずがない。

このような疑問は、プロジェクトの「初期の段階」という理解にズレがあるために生じると思われる。まさかプロジェクトの初日に、ドキュメント・インデックスを作れる訳はない。プロジェクト計画がある程度進んで、WBSが作成され、マスター・スケジュールが出来上がったタイミングでなければ、もちろん作ることはできない。それはすなわち、プロジェクトの全体像の目鼻がついた段階だ。目鼻とはつまり、成果物の構成(Product-WBS, P-WBS)がだいたい決まり、かつ、それを作るまでのプロセス手順(F-WBS)が見えて、アクティビティ・マトリクスができた時点である。
(アクティビティ・マトリクスとWBSについて知りたい方は、拙著「世界を動かすプロジェクトマネジメントの教科書 〜 グローバルなチャレンジを成功させるOSの作り方」参照のこと)

もちろん、プロジェクトの遂行途上で、インデックスにドキュメントを追加せざるを得なくなったり、あるいは削除(キャンセル)することもあり得る。追加は、当然ながらユーザの意向でスコープの増加があった場合、そして当初の見積が不足していた場合の二つがある。だから、この両者は区別できるようにしておかなければならない。そしてプロジェクトが完了したときに、自社理由で増えた分と、外部理由で増えた分が、それぞれどれだけあったかを調べ、次にドキュメント数を見積もるときには、どう教訓(Lessons Learned)を生かしたら良いかを、考える材料にするのである。こうしたことをしない限り、見積の精度など向上する訳がない。

そして、ドキュメント・インデックスを作る理由は、まさに自分たちの予測能力を高めるためにあるのだ。ドキュメント・インデックス作成というのは、プロジェクトのマスター・スケジュールなどと似ていて、プロジェクト全体を表す一種の『モデル』なのである。プロジェクトという複雑な、かつ見通しにくいシステムをモデリングする事。これこそが、プロジェクト・マネジメントの中心技術でなくて何だろう? 最終形を見通さぬまま、なりゆきでドキュメントを積み上げていっただけでは、最後に手元に残ったリストを見ても、次に生かすのは至難の業だ。経験から学ぶためには、自分が何を見通して、何を見通せなかったかを、後から追えるようなトレーサビリティが必要なのである。


<関連エントリ>

by Tomoichi_Sato | 2016-10-12 23:37 | プロジェクト・マネジメント | Comments(2)

「プロジェクト&プログラム・アナリシス研究部会 (2016年10月21日)開催のお知らせ

プロジェクト&プログラム・アナリシス研究部会」2016年の第5回会合を、下記の要領にて開催いたします。今回は研究部会WGのメンバーとの検討をもとに、久しぶりにわたし自身が講演いたします。この問題に関心をお持ちの方のご来聴をお待ちしております。

<記>

■日時:2016年10月21日(金)18:30~20:30
■場所:三田キャンパス・北館会議室2(1階)(定員:28)】
 キャンパスマップ・【1】

■講演タイトル:「プロジェクト・マネジメントの教育に対する新しいアプローチ

■概要:

受注型プロジェクトに多く携わる企業では、プロマネの育成はつねに重要な課題です。PMP資格の取得奨励などを進めても、なかなかそれだけでは実効性が上がりません。片や、自発型プロジェクトを進めるべき企業や官庁などでは、「プロジェクトをマネージするには技術がいる」という意識すら薄く、結果として幾多の失敗事例がメディアをにぎわす状態が続いています。

本講演では、“教育とは自己成長を支援するプログラムである”という認識に立ち、企業内や大学での教育に携わってきた経験を元に、エンジニアがPM能力を高めるための新しいアプローチについて提案します。今回の内容は、当研究部会の中で自主検討してきた「PM教育WG」の途中経過報告でもあり、参加者による積極的なディスカッションを期待します。

■講師: 佐藤知一(さとう ともいち)
日揮(株)勤務、静岡大学客員教授、東京大学・法政大学講師、工学博士・PMP

■講師略歴:
 1982年4月 日揮株式会社入社
 1985年10月~1986年9月 米国East-West Center 環境政策研究所 研修派遣
 2001年5月~2002年4月 仏Technip社との電子調達サイト Operation Manager
 2010年6月 「リスク確率に基づくプロジェクト・マネジメントの研究」により学位取得
 2016年9月~ 現職(日揮株式会社 グローバル戦略室)に至る
〔受  賞〕日本経営工学会論文賞(2009)

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

会場の人数に上限があるため、参加を希望される方は、できましたら前日までに三好副幹事までご連絡ください(連絡先は学会HP参照)。

以上、よろしくお願いいたします。


佐藤知一@日揮(株)

by Tomoichi_Sato | 2016-10-08 09:36 | プロジェクト・マネジメント | Comments(0)

プロジェクト・コミュニケーションのベーシック 〜 情報のトレーサビリティを確立する

英語のCommunication と、日本語の「コミュニケーション」という言葉には、微妙なニュアンスの違いがある。わたし達が会話で「コミュニケーションが良くなった」などと語る場合、ふつうは双方向の意思疎通を意味している。「前の課長は向こうが一方的に命令してくるだけだったが、今度の課長はちゃんとコミュニケーションができるよな」という風に。もっと柔らかい言い方をすれば、『ふれあい』みたいな、感情面での同調というニュアンスを含む。

ところが英語のCommunicationは、原則として情報の伝達を意味している。それは、たとえ一方向でも成立する。だから、TV局が電波で大勢に向けて一方的に情報を発信する様な仕組みを、英語ではMass Communicationとよぶ。これは日本語でマス・コミュニケーションとなり、いつものように発音しやすい4文字言葉化して「マスコミ」になった(口頭では、コミュニケーションではなく「コミニュケーション」と発音する人がほとんどだ)。

PMBOK Guide(R)が、プロジェクトの10個のマネジメント知識エリアの一つとして、Communication Managementを入れたのはとても卓見だったと思う。だが、これを「コミュニケーション管理」と、ベタな日本語のニュアンスで捉えてしまうと、本質がずれてしまう。じゃあ赤提灯にいって酒でも飲んで、メンバー同士の「コミニュケーションを良くしよう」みたいな発想になりがちだ。だが、それではプロジェクト・コミュニケーションの半分も捉えていないことになる。

PMBOK Guide(R)は元々、大規模なプロジェクトのことを念頭に置いて作られた。だから、全員が顔見知りでない状態で、どのように知識・情報を確実に他者に伝達するか、ということが問題意識のベースにある。そこで「コミュニケーション計画」のような概念が出てくるのだ。そして実行段階は、「インフォメーションの配布」ということになる。英語のCommunicationは、一方向の配布がベースだからだ。どこにも“飲みニュケーション”みたいな話題の入る余地はない。この英語はむしろ、「情報伝達のマネジメント」と訳した方が、日本の読者にはピンときたと思う。

プロジェクトにおいてコミュニケーションが重要なことは、いまさら言うまでもないだろう。ただ、これほど我々にとって分かりにくく、つかみ所のない領域もない。PMBOK Guide(R)があげる10の知識エリアは、(全体を統合するProject Integration Managementを除くと)大きく二つのカテゴリーに分けられる。

A. スコープ、コスト、スケジュール(タイム)、品質
B. 人的資源、調達、リスク、ステークホルダ、コミュニケーション

上記のカテゴリーAは、いわゆる「ハード・スキル」に属する知識エリアである。つまり、定量的・計数的な管理技術として、かなり確立している分野である。そして、WBS、EVMS、CPM(クリティカル・パス法)、SQC(統計的品質管理)などの手法が開発されている。1950年代のクリティカル・パス法の発見が、モダンPMの誕生をうながした、という歴史も頭に入れておきたい。

そして「ハード・スキル」の特徴は、技術的手法論とツールが発達しているために、座学で習得が可能なことだ。むろん本で読んだり講義で聴いたりしただけでは不十分だ。自分で練習し実践してみないと、使いこなすレベルには達しない。しかし、知識を得ることによって、入門者は相当程度にレベルアップできる。なんとなく、自分にもできそうだ、と感じさせてくれる。

ところが上記カテゴリーBの方は、どちらかというと「ソフト・スキル」に近い面が強い。ソフト・スキルとは、日本語で『人間力』みたいな言葉を使いたくなるような、属人性の高い技能である。人を使う、業者を使う、危険を予知する、利害関係者とうまくやりあう、人に何かを伝達する・・。こうした能力にも、もちろん頼るべき原理原則はある。だからPMBOK Guide(R)でも苦心惨憺して、プロセスだのツールだのを説明している。だが、それを読んで、「うん、これなら俺もできそうだ」と感じる読者は希だろう。

プロジェクトにおけるコミュニケーション(情報伝達)の最大の目的とは何か。それは、次の二つに集約できる。

(1) 必要な知識・情報を、必要な人たちに、必要なタイミングで、最新の内容で伝える
(2) 伝えたことを確認し、トレーサブルにしておく

こうしたことは、PMBOK Guide(R)には明記していない(あの本は全体としてプロセス志向で記述しており、あまり目的志向には書かれない)。しかし、たとえばエンジニアリング業界ではもう何十年も前から、欧米を中心に、世界的にこの目的に従うやり方を守ってきた。

(1)についてはあまり説明の要はないだろう。上の表現はあえて、ジャスト・イン・タイムの「必要なものを、必要な量だけ、必要なタイミングで供給する」という言い方を真似て書いている。必要な情報のみを伝達し、余計なことで膨らまさない。必要な(そして正当なアクセス権限のある)人たちだけに、それを伝える。そして遅滞なく必要なタイミングで伝える。いずれも、当たり前のことだ。ちなみに、文書や図面情報の内容が最新であることがすぐ分かるように、リビジョン番号を明記することなどは、今時どこの業界でもやっているはずだ。

(2)の方は、しかし、業界によってはあまり常識化していないと思う。とくに「伝えたことを確認する」というのは、いささか欧米流に感じられるだろう。かの国々では『発信者責任の原則』でビジネス文化が動いており、相手に伝わるよう、ちゃんと伝えるのは、発信者側の責任だからだ。だからこそ、相手が分かったかどうか、自分から確認する。

ところが、わたし達の社会は『受信者責任の原則』で暗黙のうちに動いている。伝わらない・分からないのは、メッセージを受け取った側の、理解する努力が足りないからだ、ということになっている。分からないのは恥だから、質問も返さない。逆に「一度しか言わないからな!」と偉い人が怒鳴ったりする。こういう土壌を持った社会に、「コミュニケーション・マネジメント計画を立てましょう」などといっても、何のことやら、である。

トレーサブルという言葉には、多少注釈が必要かもしれない。「トレーサビリティ」という用語は、誰にも分かりやすいように選んだもので、わたしの勤務先では、「トラッキング可能」という方が通じるだろう。いずれも、後からさかのぼって、どういう経緯で今どこまでたどり着いているかを、明らかにできるという意味だ。ちょうど牛肉トレーサビリティと同じように、である。

このためには、すべての情報の伝達に、ユニークなIDをふることが必要になる。それは、わたし達の業界では、何十年も前の紙の時代から、実践してきたことだ。たとえば顧客に公式なレターを発信する。あるいはベンダーに仕様書を送付する。ベンダーから逆に承認図が上がってくる。これを協力会社の関係部署に送付する。こうした伝達行為はすべて、IDをふって、リストに記録する。たとえば、

T-YOC-ABC-0012

といった具合だ。最初の一文字は伝達の種類を表す(TならTransmittalで、書類の送付状である)。次に、発信者-受信者、を表すコードが来る。関連するステークホルダはすべて3文字の略号をつけるのがわれわれの慣例だ。最後は連番である。だから上記のIDは、

「YOCからABC社への書類送付状の12番目のもの」

という意味になる(YOCというのはYokohama Operation Centerの略で、わたしの勤務先の本社のことである。建設現場もあるためこういう表記をするのだ。どうでもいいけど)。これを連綿とリストに記帳していく。その書類送付状には、添付された一連の仕様書や図面の番号とリビジョンが記載されているはずだ。紙の時代だったら、この送付状は複数枚つづりになっていて、受け取った側は受領サインを記入して、返送する。こうして、受領確認が行われる。現代ではもちろん、こうした手続きはすべて電子化されているが、エッセンスは同じである。

だから仮に、後になってABC社と追加交渉でもめたときにも、「T-YOC-ABC-0012でこの図面はあなたに何月何日に送っていて、そちらも受信確認を返しているではないか」という風に証拠立てられる。言った・言わないの無駄な議論を省けるだけではない。情報を受け取った側も、お互いがそれを注意深く取り扱うようになる。

書類送付状ではなく、単純な文章による伝達(昔ならレター、今ならeメール)も、同様である。IDをふっておき、発信した内容、受信した内容は、プロジェクト・チームとしてセンター・ファイルしておく(これも昔なら紙、今ならデータベース)。チーム員はいつでも、それを探せるようにする。こうしたセンター・ファイルをきちんと持っているならば、少なくともそのプロジェクト・コミュニケーションは及第点であるといえよう。

そしてこういう手続きに従って、すべてのやりとりをトレーサブルにしておくよう、新入社員の時から習慣づける訳だ。これがわたしのいう、組織の「OS」の一部を形成していく。こうしたベーシックな行動習慣をチーム員みなが持って、はじめて、プロジェクト・マネージャーの能力が本来の仕事に生かせるようになるのである。


by Tomoichi_Sato | 2016-09-25 12:43 | プロジェクト・マネジメント | Comments(0)

マネジメントの仕事・地位・パワーを混同してはいけない

ある朝、目が覚めると、あなたはノルウェー国王になっていた。いったいどうしてこんな事になったのか。あなたは自分の名前も、生まれ育った日本の町も経歴も、全部ちゃんと覚えている。なのに、ノルウェー国王になったつい最近のいきさつだけは、すっぽりと記憶から落ちている。

呆然としながらも身支度を終え、質素ながらも立派な朝食を食べて人心地ついたあなたの前に、宰相がやってくる。彼は礼儀正しくあなたに挨拶をすると、いくつかの紙の束を取り出して、あなたの前に置く。「国王陛下。これが本日、発布いただきたい法律と政令です。どうか、ご署名ください。」

念のために言っておくと、北欧の国ノルウェーは、完全な民主主義国家である。法律は国民の選出した議員が国会で決める。だが、すべての法令は、国王の名前で公布するしきたりになっているときく。宰相があなたにサインを求めてきたのは、そのためである。あなたの前には、法令書類一式と、国王用の立派なペンが置かれている。

さて、ここで問題である。あなたは、法案にサインして交付することにした。あなたのしている事は、マネジメントだろうか?

・・これは、わたしが大学の授業でプロジェクト・マネジメントを教える際に、学生に問いかける質問の一つである。プロジェクト・マネジメントの講義であるから、最初はまず、プロジェクトとは何か、そしてマネジメントとは何か、について、簡単にレクチャーするところからはじめる。プロジェクトとは、(1)終わりのある仕事であり、(2)複数の人間が協力する必要があり、(3)失敗のリスクがともなうような種類の仕事である、とまず説明する(これはPMBOK Guideの”A project is an endeavoir …"という抽象的な定義を、わかりやすく言いかえたものだ)。

ついで、マネジメントとは多義語だが、その中核にある原義は、

 「人に働いてもらって、目的を達成する事」

だと教える。人を動かすことがマネジメントであって、自分の手を動かして何かを産出することは、(それ自体は尊い仕事だが)マネジメントとはよばない。

他に二つ、マネジメントとして大事な要件がある。それは、先読みとリスクテークを含む「決断」を必要とすることだ。不確実な状況下で決断しない人、決断できない人、先延ばしにする人は、マネジメントに向かない。また、計画を立て、現実との差異から学ぶことも、マネジメントに必須の仕事だ。 計画立案と現実の統率は「マネジメント」の車の両輪である 。だから、

「人を動かせない・決めない・見通せない・学ばない上司やボスに、皆さん方は将来、出会うかもしれません。だが、その人がたとえ立派な役職についていようとも、そういう人の仕事ぶりは『マネジメント』からはほど遠いというべきです」

という話をしてから、上記の質問をするのである。ある朝気がつくと、あなたはノルウェー国王になっていた。さて、法案にサインし交付するあなたの仕事は、マネジメントか? と。

こういう聞き方をすると、マネジメントではないと思います、と答える学生がほとんどだ。なぜ? とわたしは聞き返してみる。たいがいは、こう答える。
「だって、人を動かしている訳でもないし、自分で決断している訳でもないでしょう。」

でも念のため、わたしは意地悪く質問を重ねる。・・そうかなあ。法律を定めたっていうことは、ノルウェーのすべての人がそれにしたがって動くということじゃない? つまり、人を動かしている訳だ。それにあなたは、自分の意志でペンを取って、サインすると決めたんでしょ?

「でも、法案にサインしない、っていう選択肢はないんだとしたら、それは決断とは言えないと思います」

その通りだ。ノルウェー国王には、こんな法案は気に入らないから、別のものを持ってこい、と議会に命じる権限はない。拒否権はないのだ。それに、法律が人を動かすのは事実としても、それは国王が意図した目的のために作られる訳でもない。だから「人を動かして目的を達する」ことにはならない。

念のためにいうと、ノルウェー国王は、元首である。国内で、彼(彼女)よりも偉い人はいない。人々の上に立つ、トップリーダーだ。だが、人の上に立つということと、マネジメントをする事とは、まったく別である。この単純な事実を理解してもらいたくて、わたしはこんな変な質問を学生にするのだ。

というのは、「管理職の地位に就く」ことと、「マネジメントの仕事をしている」ことを、人はしばしば混同するからだ。何らかの地位にあるのは、英語で言えば to be 〜である。しかし、マネジメントをするのは、英語なら to do 〜だ。イコールにはならない。

さらにいうなら、マネジメントは、管理職になるよりずっと前から、たいていの人に必要となる仕事なのである。「人に働いてもらって目的を達成すること」である以上、入社後まださほど年数もたたない若手技術者が、仕様書を書いて外注先に発注し、仕事をしてもらったら、明らかにこの人はマネジメントをしている訳である。あるいは、同僚や先輩の協力を得て店を決め、得意先との楽しい飲み会をセットし幹事の仕事を全うできたら、マネジメントの初歩をしているのだ。いや極端に言えば、朝の食卓でお母さんに「そこのお塩とって」と頼んで、お塩をとってもらったら、その瞬間は母親をマネジメントしたのだ。

もっとも、「立っている者は親でも使え」の諺にしたがって、母親にお塩とってと頼んだら、「何いってるの、あんたが自分でとりなさいよ、この不精者!」と逆襲される可能性は多々ある。あなたには、母親を動かす『強制力』がないからである。上長はふつう、部下に命じて動かす強制力を持っている。なぜなら上司には、部下の査定と予算承認の権限があるからだ。部下が著しく不従順ならば、査定で給料を抑えたり他部門に飛ばしたりすることも可能だ。発注書だって管理職の判子がなければ普通は効力を持たない。

こうした強制力のことを、英語ではパワー(Power)とよぶ。いいかえれば、『権力』である。管理職は部下に対する権力を持っている。とくにアメリカ英語は簡潔かつ即物的だから、権力を持つ人のことをパワフル(Powerful)だと表現する。かつて黒人女性としてはじめて国務長官の地位に就いたライス女史のことを、有名誌が「世界で最もパワフルな女性」と表現したが、これは単に彼女がエネルギッシュであることを述べただけではない。実際に世界で(米国大統領を除けば)もっとも権力を持っていて、他国を否が応でも動かせる立場にいることを意味したのである。

さて、世の中のたいていの組織は、地位についてピラミッド型の階層構造を持っている。どうしてこういう形の組織が生まれるのか、本当にこうした位階秩序は合理的なのか。この問題については、ノーベル賞を受賞した経営学者ハーバート・サイモンをはじめ、多くの研究と説明があるが、ここでは省こう。ともかく、上に行けば行くほど椅子の数は少なく、職位が上の方が名誉も大きいとされている。人間には生まれ持った競争心があるから、組織人はつねに、上に行きたいという気持ちを抱いて働くことになる。

昇進への欲望をモチベーションにして、人を働かせるという方策は、たいへん良くできた仕掛けであって、これまで十分な効果をあちこちで示してきた。昇進もなく、将来への希望も全くない職場だと、どれくらい仕事の質や効率が落ちるか、容易に想像できると思う。

しかし、このような仕掛けには、まずい点が一つある。それは、地位・権力(=パワー)と、「人を動かし、見通しを持って計画し決断して、目的を達成していく」仕事(=マネジメント)とが、混同されやすい点である。くどいようだが、地位・権力は、"to be" とか "to have” で表現するもので、マネジメントは “to do”で語るべきものだ。

だが、管理職という地位・権限と、マネジメントという職能を等号で結びつけてしまったがゆえに、
「マネジメントは管理職がするもの」
「管理職だからマネジメントしているはず」
「自分は技術者だから(管理職じゃないから)マネジメントは関係ない」
といった誤解と錯覚が、あちこちで無限に増殖していく。

マネジメントは一種の専門的な技量であり、それをきちんと行うためには専門的技術(「管理技術」)を学ぶ必要がある、というような認識は、出世街道とピラミッドからなる組織図からは生まれにくい。まして、「プロジェクト・マネージャーとは、マネジメントという仕事を専任で引き受ける、一種の『役割』(Role)である」という概念など、非常に縁遠くなる。

プロマネとは一時的な(=有期性の)役割である、というのは、現代PM理論の世界では常識的な概念だ。ちょうど演劇で、今回の芝居ではこの人が国王役、と決めるように、そのたびごとに決める役割である。そして、いったん役割が決まったら、たとえそのプロマネが自分より年下であろうが、技術的には自分の方がずっと知識があろうが、最終的にはプロマネの計画や判断に従って動いていく(むろん、途中で意見のやりとりはあるだろう、当然だが)。なんとなれば、プロジェクトの最終的成果、価値への責任はプロマネが負っているからだ。責任を負うから、権限も委ねる。「権限=責任」の等式の両辺は一致させる。そのかわり、マネジメントのための管理技術の体系を学ばせる。これがまあ、現代流の(あるいは西洋流の)PM理論の考え方である。

ここでは、マネジメントをする「個人」と「ポジション」と「管理技術」が、それぞれ独立している(DB技術風にいうと、独立したエンティティになっている)。ところが、出世街道ピラミッド型の組織論で、すべてのマネジメントをまわそうとすると、
「優秀な個人」←→「上の立場・権力」←→「マネジメントの仕事」
という風に、ひとつながりになってしまう。

ここからさらに派生して、「部下を動かすのが上司の権限」=部下を不合理にいじめて上司風を吹かせるのも有能なる自分の特権の一部、と合点するパワハラ不心得者さえ、一定数、出現する。

ピラミッド型組織で、このような不都合を防ぐには、どうしたら良いのか。解決策は、二つある。一つは、管理職位ごとに、きちんと細かくルールを設定することだ。どういう人間ならばその職位につけるのかという、能力による品質基準(Qualification)。その職位がなすべき機能と権限の範囲。そして機能が要求する技術・知識・スキル。こうしたことを、個別に設定する。これを、ガバナンスとよぶ。

ただし、この処方箋の困難な点は、社内ルールを制定する権限もまた、上位職者が握っていることだ。だから「マネジメントには独立した管理技術がある」なんて意識がこれっぽっちもない方々が経営層に多い場合、こうしたルール制定は不可能だろう(そんなルールを敷いたら、まず自分たちが真っ先に不適格になってしまう)。本当は株主がガバナンスを要求すべきなのだ。だが、利益が出て株価が高ければ、あとは興味のない株主も多い。

もう一つの方策は? それは、「外を見る」ことである。自社のありようは自社のありようとして、外ではどうなっているのか。目前のライバルだけでなく、広く視野を世界に求めて、世の中ではどうしているのかを、学ぶ。これは日本企業が、これまで以上に海外と接するようになった今日、むしろ日々得られる体験でもある。

その昔、咸臨丸にのって米国を視察してきた勝海舟に、江戸城で幕府の重役がたずねた。かの米国と我が国の違いは何かと。海舟は、人間のすること古今東西同じもので、アメリカとて別に変わったことはありません、と答える。しかしそれでも何かの違いはあるであろう、と繰り返したずねた重役に対し、
「さよう、少し眼につきましたのはアメリカでは、政府でも民間でも、およそ人の上に立つものは、皆その地位相応に利口でございます。この点ばかりは、全くわが国と反対のように思いまする」
と答えた。するとご老中が目を丸くして、「この無礼もの。控えおろう!」と怒鳴ったという(「氷川清話」による)。

わたし達は勝海舟ほど剛胆ではあるまい。だが、米国の実情が彼のいう通りかどうかはともかく、他者を見て改めて我を振り返る、というのはわたし達に共通した特性である。勝自身、さまざまな身分の浮沈をくりかえし経験した人間であった。だからこそ彼には、地位と職務の違いが見えていたのである。

追記:
e0058447_18202730.jpg

ネットで検索すると、現在のノルウェー国王ハーラル5世は、この方である。Wikipediaによれば、なんでもノルウェー生まれの国王は、500年ぶりらしい。ときには自国の言葉もしゃべれない他所者を国王に招いたりするヨーロッパの人たちの王室感覚というのは、よく分からないものである。国王というのも、あるいは一種の『役割』なのだろうか・・?
by Tomoichi_Sato | 2016-08-11 18:21 | プロジェクト・マネジメント | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会 (2016年7月14日)開催のお知らせ

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

今回は、グローバル企業のマネジメントのあり方・手法そして人材について、ドイツ系企業の日本社長であるへレウス株式会社・土屋淳様にご講演いただきます。 土屋様は元々技術者で機能性材料の開発等に携わられましたが、日本企業を振り出しに、その後、米国企業・ドイツ企業の経営者を経験され、
「欧米のグローバル企業といっても、いろいろな違いがある。その中心にはエトス(納得感)のあり方の差がある。実はグローバル化は外資企業にとっても難しい」
という趣旨の論文を昨年『化学工学』第11号・12号に発表されています。

実際のグローバル・ビジネスの世界で活躍中の経営者から、具体的で臨場感のあるお話が聞ける、またとないチャンスです。ぜひご参加ください。


<記>

■日時:2016年7月14日(木) 18:30~20:30

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

■講演タイトル:
グローバル人材に求められるもの

■概要:
日本企業、米、独外資系企業での経験、体験から、グローバルビジネスにおいて相互理解のための総合的なコミュニケーションスキルの重要性を言及する。コミュニケーションによって得られる納得感こそが組織の価値向上のために不可欠な要素であり、違う文化を背景に持つ者同士が同じベクトルを向くことができると思う。

■講師:土屋 淳(へレウス株式会社・代表取締役社長)

■講師略歴:
1952年生まれ。 1981年東京大学工学部合成化学科博士課程卒業、工学博士
職歴:1981-1984 米国国立研究所
    1984-2002 三菱化学 (1989-2000年米国駐在)
    2002-2006 米国企業 Rohm and Haas Japan 取締役
    2007- ドイツ企業 Heraeus Japan 代表取締役社長

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

参加を希望される方は、確認のため、できましたら当日までに佐藤までご連絡ください。なお会場には定員があるため、場合によってはお断りせざるをえないケースも考えられますので、ご了承ください。


佐藤知一@日揮(株)
by Tomoichi_Sato | 2016-06-29 18:37 | プロジェクト・マネジメント | Comments(0)

講演のお知らせ(6月16日)

直前のお知らせで恐縮ですが、今週の木曜日・6月16日の夜に、OR学会サプライチェーン戦略研究部会に招かれて、

海外プロジェクトへのシステムズ・アプローチ ー 理論・技法・展望

と題する講演を行います。
これは基本的に、この3月に東京工業大学CUMOT「ストラテジックSCM講座」でお話しし、好評をいただいた発表のアンコール講演です。ただ、先週フランスのリールで開催された、国際的PM標準を比較評価するGAPPS Thought Leadership Forumの参加報告などもおりまぜて、大学での講義とはまたひと味違った雰囲気のものにするつもりです。

ご期待ください。

<記>

題目:海外プロジェクトへのシステムズ・アプローチ ー 理論・技法・展望
講師:佐藤 知一 (日揮株式会社 経営戦略室 室長代行、静岡大学 客員教授)
日時:2016年6月16日(木) 18:30から20:30まで
場所:青山学院大学 総研10階18会議室

・会場アクセス・講演要旨は下記ホームページをご参照下さい。
 http://scsr.jp/

・参加希望者は、前々日正午(6月14日正午)までに下記から事前申し込みをお願いします。
 http://scsr.jp/form.html
by Tomoichi_Sato | 2016-06-12 17:57 | プロジェクト・マネジメント | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会」(5月27日)開催のお知らせ

** お知らせ **
本日(5/27)の研究部会は、昨日までにすでに当初の想定をはるかに超えた参加申込があり、会議室の定員を大きく上回る満員の状況になりました。
大変恐縮ですが、事前連絡なしの当日参加はお断りせざるをえなくなりましたので、ご了承ください。


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

今回は、プロジェクトの納期を劇的に短縮するCCPM(クリティカルチェーン・プロジェクト・マネジメント)の手法について、実際に導入して成果を上げた大和ハウス工業株式会社の松山竜蔵様にご講演をお願いすることにしました。

CCPMとは、「ザ・ゴール ― 企業の究極の目的とは何か」などの著者であり、TOC理論で有名な故ゴールドラット博士の提案した、画期的な方法論です。納期を短くするために各アクティビティの所要期間の見積手法を見直したり、個別期限を撤廃したりするやり方はそれなりに知られています。しかし、そうしたテクニック以上に、プロジェクト・チーム員のモチベーションを上げるためのいろいろな工夫が大事になります。

IT部門の基幹業務でCCPMを実践しておられる松山様から、その勘所を教えていただきますので、ぜひご期待ください。

<記>

■日時:2016年5月27日(金) 18:30~20:30

■場所:慶応大学 三田キャンパス・北館・会議室3(地下1階)

   アクセス http://www.keio.ac.jp/ja/access/mita.html
   ※キャンパスマップの【1】になります

■講演タイトル:
クリティカル・チェーン法を機能させるマネジメント

■概要:
CCPMはPMBOK第5版でも、タイム・マネジメントの技法として取り入れられていますが、一般的になかなか実行することが難しいと思われています。せっかくCCPMでバッファをとったスケジュールをプランニングしても、実行の段階であっという間にバッファは使い果たされ、納期が守れなくなっていき、何でCCPMの効果が出なかったのかと振り返った時に、契約の問題や評価の問題があって、クリティカル・チェーンにリソースが集中できないからだ、ということも言われます。

もちろん契約の問題がないわけではないでしょうが、それよりもまず、アグレッシブな計画がアグレッシブなものとして実行できるような、メンバーが意欲的にチャレンジできる残日数のアクティブな管理の方法について考えてみたいと思います。

■講師: 松山竜蔵 (大和ハウス工業株式会社)

■講師略歴:
大和ハウス工業で本社・事業所の経理を歴任。2010年4月から会計分野へのSAP導入プロジェクトのプロジェクトリーダ。

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

 参加を希望される方は、確認のため、できましたら当日までに佐藤までご連絡ください
by Tomoichi_Sato | 2016-05-27 09:11 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントの目的とは何か

中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。

今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。
「この中で、現在プロマネの仕事をされている方はいらっしゃいますか?」

手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに来る必要がないし、第一、忙しくて聴きに来る暇もないだろう。わたしは受講者の方に申し上げた。

「すると、ここにいる過半数の方は、SE的な仕事をメインにされているソフトウェア技術者だと思います。じゃあ、もう一つおうかがいします。今やっている仕事が楽しい人、手を上げてください。今の仕事が楽しくて楽しくて仕方がない人は?」

結果はご想像に任せよう。少なくとも、全員からはほど遠かった。「つまり、楽しくない仕事をしている人が、結構いらっしゃる訳ですね。では、今の皆さんの状況を打破するためには、どうしたらいいでしょう? 充実した、面白い仕事をするためには? ——たしかに皆さん、勉強熱心でいらっしゃる。しかし、あるレベルに達したら、そこから先はソフトウェア技術だけでは、充実した仕事はむつかしいのです。」そう、わたしは続けた。

「たった一人でプログラムを書いて、世界を転換させる、そんな夢を抱いて業界に入った人もいるでしょう。ただ、それで成功する人は、たぶん百万人に一人。それ以外の人は、他人と協力して、チームで仕事に取り組まなければなりません。そして面倒なユーザを説得し、上司を動かして、目的を達する必要があるのです。一つの目的のために、人を動かす技術。それがプロジェクト・マネジメントです。良い仕事をしたければ、プロジェクトの動かし方を知るべきなのです。」

仕事を良く理解したければ、仕事の『なぜ』=目的をしっかり把握する必要がある。プロジェクトとは、一つの目的のために、チームを動かして進める仕事だ。プロジェクトの目的とは、たいていはシステムなどの成果物と、そのアウトカムである。そこは、はっきりしている。

では、プロジェクト・マネジメントという仕事の目的はなんだろうか。

え? それはプロジェクトの目的と同じじゃないか。つまり成果物としてのシステムだよ——という答えは、じつは答えになっていない。もしそうなら、コーディングやテストという仕事が、プロジェクト・マネジメントの内部になければいけないことになる。もしかりにチームがプロマネ抜きでちゃんと仕事を果たして、システムを納品したら(理屈の上では可能だ)、プロジェクト・マネジメントの役割は何なのか? いや、理屈の上どころか、チームの足を引っ張る無能なプロマネだって、実在する。じゃあ、上手なプロマネと下手なプロマネの違いはどこから生まれるのか。有能なプロマネは何に奉仕し、無能な奴は何に失敗しているのか?

答えは簡単だ。プロジェクト・マネジメントの目的は、プロジェクト価値を最大化することなのだ。

え、それだけ? ——そう。それだけだ。この目的を分かっているプロマネは、良い成果物が短期間にできるよう、チームの目標を明確化し、チームが働きやすい場や状況を作り上げ、問題を適時解決していく。ときには余計な管理で手間取らせないよう、手出しを控えたりする。逆のプロマネは・・言わなくてもお分かりだろう。

以上。

ま、ここで終わりにすれば、最近やたら長い傾向にあるわたしの記事の中では、画期的に短いエントリになるな。そうすれば省エネだし、地球環境にも優しい(?)かもしれない。が、ちょっとだけ補足を付け加えることにする(だから長くなるのだが・・)。

前々回の記事によれば、生産マネジメントの目的は、「生産の仕組み(生産システム)をつくり、活かし、進化させ、それによって働きがいを創出すること」だった。だったらPMだって、「プロジェクトの仕組みをつくり、活かし、進化させ、働きがいを創出する」という風にならないのか? 生産とプロジェクトはある意味、兄弟ではないか。そう感じられる読者もおられるかもしれない。

だが、そうではないのだ。プロジェクトを立ち上げ、場や組織を作るのは、プロジェクト・マネジメントの目的ではなく、「本来業務の一部」である。チーム作りは、手段に過ぎない。レンガを積むことは、レンガ職人の仕事の目的ではないことを思い出してほしい。本来業務は、仕事の目的ではない。

そして、プロジェクトはその定義上、一度限りの仕事であり、プロジェクト組織は一過性のものなのだ。生産マネジメントは永続的な仕事だが、プロジェクト・マネジメントは一過性の仕事である。そこが根本的に違う点である。

じゃあ、進化させるのは? つまり、プロジェクトで得た知見や教訓を、他のプロジェクトの改善に結びつけること。もっと別の言い方をすれば「組織のプロセス資産」の強化だ。これはPMの目的ではないのか?

あいにく、知見やL&Lや組織の資産は、プロジェクトの波及効果(アウトカム)の一部である。良いアウトカムを生み出すことは、プロジェクト価値を高めることの中に、すでに含まれている。という訳で、プロジェクト・マネジメントの目的は、生産の場合より、ずっとシンプルな文章で表現できるのである。

もともとプロジェクト・マネジメントは、直接の成果物を生み出さない、「間接業務」である。だからもし、プロジェクト・マネジメントに全体の1割のコストがかかり、それが全体に対し1割以上の価値向上をもたらさなかったら、そんな作業は引き合わないのだ。

ただし念のため書いておくが、価値(Value)とは、利益(Profit)とイコールではない。ここを間違える人は、受注型ビジネスの業界に多い。プロジェクトの価値とは、受注金から原価を差し引いた値だろ、と。だが、それだけではないのだ。価値は、金銭的価値と、非金銭的価値とからなっている。受注型プロジェクトではたしかに、利益という金銭的価値はとても大事だ。だが、たとえば、その顧客やその分野での実績を得られたとか、プロジェクトで人が育ったとか、そうしたお金に換算しにくいアウトカムもまた、プロジェクトの価値の一部なのだ。

だから、「プロジェクト・マネジメントの目的はプロジェクト価値を最大化することだ」という定義は、すなわち「価値とは何か」という大きな問題を考えることを、プロマネに要求しているのだ。金銭的価値、そして複数のお金に換算しがたい価値があるとき、どれをとるのか、どれを優先するのか、そうした問いに、自覚的なプロマネは答えなければならない。

もともとマネジメントが決断能力を持つためには、価値観が必要である。「決断」はマネジメントの中心にある行為だ。そして、何が「良い」状態であり、どうなれば「価値が高い」かが明確でなければ、適切に「決める」ことはできない。ただし残念ながら、現在のプロジェクト・マネジメント理論には、こうした適切な価値論が欠けている(唯一、英国OGCのガイドライン"Management of Value"だけが、この問題への一つのアプローチを与えていると思う)。

もう一つだけ付け加えておこう。それは「プロジェクトは見えないシステムである」ということだ。プロジェクト価値の向上は、その見えないシステムの設計や運転からもたらされる。そこがこの仕事のむつかしさなのだ。

現代プロジェクト・マネジメントの考え方は、1950年代の『クリティカル・パス法』の誕生とともに生まれた。これはプロジェクトというものを、複数のアクティビティ(要素作業)から構成されるシステムととらえた、システムズ・アプローチの産物であった。つまりモダンPMとは、「プロジェクト=システム」という視点の上に立っているわけだ。

それ以前までは(つまり古代のピラミッド建設や万里の長城の時代から20世紀初頭の帝国覇権主義の時代まで、えんえん数千年にわたって)、人間はプロジェクト全体を「かたまり」としてしか見ていなかった。大きなかたまりのまま計画したり操作しようとしたりしてきたが、決してうまくいかなかったのだ。デュポン社の化学プラント建設スケジュールや、ポラリス潜水艦ミサイルの納期の予測のために、クリティカル・パスやPERTの手法が開発されてはじめて、人類はやっとプロジェクトに対する科学的理屈を手に入れたのである。
e0058447_22533899.jpg

ところで、プロジェクトをシステムとしてみた場合、生産システムや交通システムなどとは歴然とした違いが一つある。それは、「実在」か「過程」かの違いだ。

生産システムは、空間的にも実在しているし、それに属する機械や人間も目に見える。永続的な仕組みである。しかしプロジェクトは、同じシステムではあるが、目に見えない。全体が同時に実在している訳ではないからだ。個別の瞬間には、その時点で走っているいくつかのアクティビティが動いているだけで、全体像を「見る」ことはできない。

たまにIT産業の方から、「プラント・エンジニアリングの業界はうらやましいですね。プラントが出来ていく姿は目に見えますから。ソフトウェアは目に見えないから大変なんです」といわれることがある。どういたしまして! それはものごとを表層的に見ているだけである。現場に組み上がっていくプラントは目に見えるかもしれないが、結果でしかない。プロジェクトの成否を決める大事な部分は、その現場に資材を届けるサプライチェーンであり、工事図面を作成するエンジニアリング・チェーンである。こうしたアクティビティは世界中に散らばっているし、よく目にも見えないのだ。

プロジェクトは目に見えないシステムである。それは(哲学者のホワイトヘッド風にいうならば)永続的な「実在」ではなく一過性の「過程」である。それを設計し運転していくのが、PMである。途中で後戻りできない。だから大変なのだ。

そして、プロジェクトは人間をその構成要素として含む「第二種のシステム」である。機械的な構成要素だけからなる「第一種のシステム」は、科学法則だけで予測可能だ。だが、自分で勝手に判断する人間を含む第二種のシステムでは、予測や制御がはるかにむずかしい。そして、だからこそ面白いのだし、上手くいった場合には価値が高いのだ。プロジェクトは放っておくと混沌に陥りやすい。それを束ねて、ある目的成果物やアウトカムを生み出す。放置した場合と統合した場合の価値の差が、プロジェクト・マネジメントの良否を測る尺度である。

価値観と、システムズ・アプローチの視座。これの二つが、プロジェクト・マネジメントの目的、すなわちプロジェクト価値の最大化を実現するために、必要なのである。こういうことは、輸入版のPM教科書にはあまり書いていない。いや、じつをいうと、わたしがこのことに気がついたのも、ほんの数年前のことだった。それまでは自分でもうまく言語化できていなかったのだから、いつも偉そうなことを書いているわりには、お恥ずかしい次第だ。

言葉にすること。それはマネジメントの第一歩である。マネジメントとは(少なくともその中核の意味は)人を動かすことにある。人を動かすには、テレパシーが使えない限り、言葉で伝えるしかない。だから言語化はとても大事なのだ。そして動かすべき「人」の中には、じつは未来の自分も含まれる。いや、正直にいうと、未来の自分ほど、動かしがたく、迷いやすく、忘れっぽい存在はいない。だから目的の言語化とは、何よりもぶれない自分自身への、道しるべなのである。

<関連エントリ>
 →「見えない壁に突きあたった中堅エンジニアが学ぶべき、三つのこと」(2016-04-04)
by Tomoichi_Sato | 2016-05-25 22:56 | プロジェクト・マネジメント | Comments(1)

お知らせ:プロジェクト・マネジメントの一日研修セミナーを行います

研修講演のお知らせです。

新著『世界を動かすプロジェクトマネジメントの教科書』発刊を記念し、来る6月16日に、日本テクノセンターで

プロジェクトを成功させるための実践的マネジメント技法とそのノウハウ ~演習付~

と題する1日研修を行います(有償です)。

周知の通り、産業構造の変化や競争激化に伴い、プロジェクト的な業務の比率は業界を問わず高まっています。受託システム開発や建設分野に限らず、製造業の新製品開発や個別受注生産、そして新サービスや海外事業の展開など、多くの場面で「一度限りのチャレンジ」=プロジェクトのより良いマネジメントが求められています。

本講座では、プロジェクト・マネジメントがカバーすべき主要な機能について解説します。とくに、プロジェクトの成功をしばる三大制約条件であるスコープ・コスト・スケジュールと、それらをコントロールする技法であるWBSEVMSPERT/CPMについて、演習を交えてしっかりと学びます。また「海外型プロジェクト」の特性と進め方に関しては、講師自身の長年の経験に基づく実践的な解説を行います。

ただし、プロジェクトの成功はプロマネ個人の知識レベルや、スキルだけでは決まりません。組織がもつ思考と行動習慣(いわば組織の「OS」)に応じて人を動かすことが大切だからです。たとえば、

 ・計画がきちんと立てられず、行き当たりばったり
 ・だれが何を決めるのかわからず、意思決定が遅れる
 ・以心伝心・暗黙の了解で動いて、言葉にしない
 ・契約感覚に乏しく、地雷を踏んでしまう

といった項目に、もし一つでも思い当たることがある方、そして中小規模のプロジェクト実務に携わっていながら世間のPM標準では満たされぬ思いを感じておられる方々には、ぜひ受講していただきたいと願っております。単なる外国の教科書の解説ではなく、実践的で身につく知識とスキルを学べる講習ですので、とくにこれから海外系のプロジェクトに取り組もうとされる方に、おすすめします。

お申し込みは案内サイトから行えます。大勢の方のご参加をお待ちしております。

佐藤知一
by Tomoichi_Sato | 2016-05-08 21:13 | プロジェクト・マネジメント | Comments(2)