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

プロジェクト&プログラム・アナリシス研究部会」(3月28日)開催のお知らせ: 満員になりました

(大変恐縮ですが、下記の研究部会は大勢の方から参加申込みがあり、満員となりました。なお、予約なしに当日の参加はできませんので、ご了承ください)


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

今回は、JAXA・宇宙航空研究開発機構のチーフエンジニア室長である岩田隆敬氏をお招きして、JAXAのプロジェクトマネジメントについてご講演いただきます。

ご承知の通りJAXAは日本の宇宙開発の中心団体です。「はやぶさ」の例を見れば分かるとおり、宇宙開発は技術的難易度の点でも、また天体条件その他の環境制約の厳しさの点でも、チャレンジングな仕事の極致といえるでしょう。その難しさを克服するため、米国のNASAは1960年代以降、アポロ計画という「プログラム」、その下の個別ロケット・ミッションの「プロジェクト」という概念の元、さまざまな管理技術を開発しました。宇宙開発分野は、いわばモダンPMの育ての親なのです。

日本版のNASAともいえるJAXAもまた、我が国のプロジェクト・マネジメントの頂点の姿を示すと言っても過言ではありません。トップクラスのプロジェクト遂行はどのようなものか、興味深い話が聞けると思います。年度末のお忙しい時期とは思いますが、ぜひご期待ください。


<記>
■日時:2017年3月28日(火) 18:30~20:30
■場所:研究室棟B会議室(研究室棟1階)※定員:36名
 ※キャンパスマップの【10】
  (いつもの建物とは別ですのでご注意ください)

■講演タイトル:「宇宙航空研究開発機構(JAXA)のプロジェクトマネジメント

■概要:
人工衛星やロケットのような宇宙システムは、大規模かつ複雑、高価で、新規開発要素が多い上に、極限環境を飛行することを特徴とする。世界の宇宙機関の事業の大部分は、こうした宇宙システムの開発を中心に据えたプロジェクトで構成されており、宇宙機関は、プロジェクトを確実に遂行するために、開発の段階的実施、フェーズ移行審査、文書によるベースラインの明確化等といった共通のマネジメントを取り入れている。本講演では、宇宙航空研究開発機構の例を取り上げて、プロジェクトマネジメント推進の背景や、体制・仕組み、開発プロセス、審査、進捗確認、計画変更、スコープ設定、人材要件・育成、知識蓄積・継承などについて、紹介する。

■講師: 宇宙航空研究開発機構(JAXA) チーフエンジニア室長 岩田隆敬様
■講師略歴:
岩田隆敬(いわたたかのり)
・東京大学航空学科宇宙工学コース卒業、同大学院航空学専攻工学修士
・米国Stanford大学大学院航空宇宙学科M.S.(Master of Science)、
  Ph.D.(Doctor of Philosophy、主専攻:航空宇宙工学、副専攻:電気工学)
・宇宙開発事業団(現、宇宙航空研究開発機構(JAXA))入社
 ・陸域観測技術衛星(ALOS、「だいち」)プロジェクト
   高精度な姿勢軌道制御系、恒星センサ、GPS受信機や、大型の太陽電池パドル
   系、及び、地上の高精度指向決定システムの開発から運用までを主担当
 ・研究開発本部誘導・制御グループ長
   誘導・制御技術の研究開発とプロジェクト連携を指揮
   恒星センサ、GPS受信機や、GCOM-W1、ALOS-2、SPICAの姿勢軌道制御系
   開発を担当
 ・統合追跡ネットワーク技術部参与・計画マネージャ
   衛星の追跡管制の統括、予算要求、将来計画を担当
 ・現在、チーフエンジニア室室長
   プロジェクトの独立評価、PM/SEの体制・ルール/標準の維持・推進、研究開発
   マネジメントの推進を担当
・専門: 航空宇宙工学(特に、航法・誘導・制御・ダイナミクス)
・PMP

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

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


以上、よろしくお願いいたします。
佐藤知一@日揮(株)

by Tomoichi_Sato | 2017-03-03 23:56 | プロジェクト・マネジメント | Comments(0)

Pushで教育し、Pullで成長する

子どもがまだ小さかった頃、よく「きかんしゃトーマス」を一緒に見た。このイギリス製の人形劇は、どうやら英国社会を引き写しているらしく、階級制になっている。機関車はおおむね真面目で勤勉だが、彼らに引かれて走る客車はいつも適当な連中で、機会があればサボることを考え、しょっちゅう脱線事故などの面倒を引き起こす。つまり機関車(Engine)は、技術者(Engineer)のような中産階級を連想させ、客車はすぐにストやサボタージュをする労働者階級を思わせる、という具合だ。
あるとき主人公のトーマスが、例によって客車にトラブルを起こされ、手を焼いていた。すると、となりの線路をゴードンという機関車がちらとトーマスを横目で見て、「人生は勉強だな」といって通り過ぎるシーンがあった。きかんしゃゴードンは中年男を思わせる横柄なキャラなのだが、この台詞はなぜかぴったりと役にはまっており、見ていたわたしと連れ合いはその後しばしば、小さなトラブルに遭遇するたびに「人生は勉強だな」と言い合って笑ったりした。

人はいくつになっても成長できる。逆に言えば、人は一生、学び続けなければならない。ゴードンの名台詞はこのことを表している。ところで、英国のコンサルタントであるMarcus Buckinghamの説によると、人間の学習スタイルには、「分析型」、「行動型」、「観察型」の三つのタイプがあるのだそうだ。それによると、
・分析型は事前の学習時間を十分とる
・行動型は早く未経験の環境に置く
・観察型は手本になるベテランの傍らで、仕事を俯瞰的に見ながら模倣させる
というのが、それぞれOJTのやり方としてふさわしいらしい。このことは、稲山文孝氏の「アプリ開発チームのためのプロジェクトマネジメント」http://brevis.exblog.jp/24117407/ という本で読んだ。

なるほど、とは思ったものの、上記の3タイプはあくまで英米人の類型かな、とも感じる。わたし達の社会なら、このほかに「感情型」だとか「競争型」とかを付け加えたくなる。感情型は好きな人を手本にして感性や情に訴えて学ばせる、「競争型」は試験を課して成績で競わせる、と言う具合だ。

まあ人間の類型論は医学・心理学から社会学まで、いろいろなバリエーションがある。だが、学びという点で見ると、大きく「受動型」と「能動型」に二分できるのではないかと、よく感じる。というのは、この区分は、育成・訓練におけるマニュアル整備の是非の論議に、しばしば登場するからだ。マニュアル論議といういうのは、仕事について伝えるべき一切合切、なるべくすべてをマニュアル化すべきか、という論争である。いや、親切すぎると相手の「学び」が働かなくなるのでは、という疑念や、緊急時対応はどこまでマニュアル化できるか、といった疑問もこれに近い。マニュアルがないと対応能力が下がる。しかし、あまりすべてをマニュアル化すると、今度は「想定外」に対応できなくなるパラドックスが生じる。

こういう議論では、どうも意見に世代間ギャップがあるな、とわたしは感じている。おじさん世代(わたし自身を含む)にとって、知識は稀少資源だった。わたしが社会人になった頃は、パソコンというものすら存在していなかった(きっと日本昔話みたいに聞こえるだろうなあ)。知識はほぼ全て、紙の中にあった。そして、知識情報は自分の個人的資産として「囲い込む」(机の中にしまっておく)ものだった。人が知らないことを知っているのが、自分の優位性だ——そういう感覚が強かった。

その時代、「技術は盗むもの」と信じられていた。教えすぎてはいけない、と。教えなくても優秀な人は、自然に身につけるものだ。何より、生まれつきのセンスが一番大事で、あとは「やる気」、気持ちの問題だ。つまり、自分から知識を取りに行く(Pull型)の態度が主流だったのだ。

ところで、このような態度は時代とともにかわっていく。若い世代(定義は難しいがバブル時代以降か)にとって、知識は世界に氾濫しているものだ。知識はネットでふんだんに流通している。あとは自分で好きに探せばいい。知識は他者から与えられ(Push型)、選び取るものになった。情報整理とフィルタリングの感度が自分の優位性だ、と感じているのではないか。

このギャップは、世代間で知識情報を伝達する「教育研修」において、重大な影響を与える。シニア世代は、若手が取りに来るのを待っている。若手は逆に、シニアが教えてくれるのを待つ。つまり「教育のデッドロック現象」が起きているのだ。こうなると、組織的な「学び」が働きにくくなる。それは、同じような間違いやトラブルを繰り返す原因になるだろう。

このところPMの教育について、ずっと考えている。マネジメント能力の育成は、知識教育だけではまったく不十分だと、わたしは思う。そもそもマネージャーとは、教育すべきものなのか、それとも自己成長なのか? 「俺の背中を見て育て」というおじさん世代にとって、マネジメント能力は自分から取りに行く(盗む)のが当然という考え方が強い。おまけにその世代は、マネジメントの仕事を伝達可能な形で言語化していないことも多い。

もちろん、マネジメントの能力には、言語化できる部分とできない部分がある。つまり属人的なソフト・スキル(技能)の部分と、軽量化し伝達可能なマネジメント・テクノロジー(技術)の部分とがある。そして後者は、先ほど述べたマネジメントの「マニュアル化」の議論につながりがちだ。どこまでマニュアル化できるのか、またマニュアル化すべきなのか?

こうした育成をめぐるPushとPullの議論が混乱する理由は、いろんなレベルの知識情報をごっちゃに話していることにある。そこで知識のレベルを「基本」と「応用」に分けて考えてみよう。

(1) 基本レベル

仕事に必要な基本的知識は、伝える側=先輩が、受け手=後輩に教えこむべき(Push型伝達)ものだろう。そうでなければ、組織として効率がわるすぎる。基本レベルとはつまり、テクニカルで伝達可能な知識やハード・スキルである。そして、そのためには知識に関するPushのシステム(仕組み)を作り上げる必要がある。つまり、教科書化・マニュアル化する訳である。あるいは昨今ならば、 ITツール(e-Learning)も活用することになる。

システム(仕組み)である以上、教える側の体制も構築しなければいけない。なぜなら、「人に教える」こと自体が学びにもなるからだ。組織としては、それを評価褒賞にも組入れる必要がある。

(2) 応用レベル

これに対し、応用的な知識やスキル(主にソフト・スキル)は、受け手が自分から学びに行く(Pull型)べきものである。そうでなければ、能力として本当には身につくまい。そのためには、Pullの知識獲得のための態度・思考習慣(OS)を持つことが必要だ。また、応用レベルは一般にマニュアル化に向かない。範囲が広く例外事象が多いため、教科書・マニュアルでカバーするには効率がわるすぎるからだ。

そこで中心になるのは、学ぶ事自体の面白さだ。身につけば、仕事の幅を広げるのに役に立つ。いや、直接すぐに役に立たなくても、いつか役に立つ潜在的可能性があればいい。そして応用レベルの問題には、必ずしも正解はない。だから、自分の頭で考え、自分のスタンスや価値観を持つ態度が求められる。


以上の二つのレベルのあり方は、ちょうど、学校教育でも実現されている。小中学校の基本レベルは、義務教育であり、先生が生徒に知識をプッシュで教え込む。子どもの側は、なんでこんなことを覚えなけりゃならないのか、などと疑問を持つこともあるが、そこは問答無用ということになっている。これに対し、大学・大学院というところは、(本来は)応用レベルを学ぶ場所だ。そこではいちいち、手取り足取り、教えたりしない。自分の頭で考えて、レポートや卒論などにまとめることが要求される。

ただし、(1)の基本レベルと、(2)の応用レベルを結ぶために、大事なことがある。それは、基本レベルを教える過程の中で、同時に「自分で学びに行く態度」を育てなければならない、ということだ。これがあるからこそ、応用レベルで自ら成長していけるのだ。そのためには、教え手が見本(モデル)となって示す必要がある。質問されたら、誠実に答える姿。難しい問い(つまりよい質問)に対しては、必ずしも全知ではない姿。そして自分も新たに学んだ、学べて面白い、という姿を、見せること。これがあってはじめて、基本レベルの生徒にも「学ぶ態度」が少しずつ身についていくのだ。
e0058447_23012569.jpg
しかし現実を見ていると、どうやら「学ぶ態度を教える」ことが、ミッシング・リンクとなって 欠けていることがある。そうなると、基本レベルから応用レベルに壁を越えてジャンプできない。学校教育でも、高校から大学へはジャンプがある。これにつまづくと、昔なら五月病にかかった。今は、大学自体がPush型中心の、手取り足取りやたらと面倒見のいい(?)教育に、重心を移してきている。そうなると今度は、社会に出たときがジャンプになってしまう・・

そこで大切になるのが、知識のナビゲーター(水先案内人)を組織の中にたてることではないだろうか。まだ十分にPull型の「学ぶ力」が身についていない人を、知識のある場所や、よく知っている先達に適切に導く役柄だ。わたしのこの小さなサイトも、及ばずながらマネジメント・テクノロジーへの水先案内役をしているつもりだ。

もう一つ。これもわたしの仮説だが、Pull型を習慣化し身につけるのは、一人の意思だけでやるのはしんどい。そこで、上級レベルへと学ぶ人のためのコミュニティがいるのだ。その証拠に、だから大学はゼミ方式になっているではないか。

思うに、Push型の教育は、ビジネス化できる。世に沢山、予備校だとか塾だとか資格学校だとかがあるのを見れば明らかだ。ところが、Pull型の成長は、ビジネスになりにくい。「学びに行く態度」を教えるには、マンツーマンの部分が必要であり、マスプロ教育の大量生産に比べるといかにも効率がわるいからだ。

それと同じことで、今の世間のPM教育には「応用」への道筋が欠けているように感じられる。基本レベルは、たとえばPMBOK Guide(R)でカバーできる。そこには有用な知識情報がライブラリ化されている。そしてPMP資格のための教育プロバイダーも多い。だが、本当は「PMBOK以降」への準備が同時に必要なのではないか。PMPは出発点に過ぎない。PMBOK以降も自分で考え、学び続けるための方法と場所がいるはずだ。だからこそわたしは、研究部会の仲間とともに、PMを学ぶためのオルタナティブな仕組みを構想しているのである。

最近、職場の大先輩が語っていたのだが、仕事はあるところから面白くなる、という。最初のうちは覚えることも多いし、担えるのは小さな役割に過ぎない。しかし基本レベルをマスターして、うまく先に進めると、Pushで与えられた専門の枠を超えて、周囲も巻き込んで大きな仕事をつくれるようになる。そして複利計算的に、自分を拡大再生産できるようになる。学ぶ能力自体が資産になるのだ。この大先輩は、基本から応用にジャンプするための、Pullで学ぶ力を身につけたからだろう。

学ぶ力とは、潜在的な能力をみずから獲得するための力である。すなわち学ぶ力とは、能力を得るための能力だ。それを身につけることは、単なる「即戦力」などの教育よりも、ずっと大切なことなのだ。

「教育の目的は、自分たちが聡明ではないことを教えることである。」(アラン・ケイ)


<関連エントリ>
 →「学ぶ時間をどうつくるか」http://brevis.exblog.jp/24292367/ (2016-04-10)


by Tomoichi_Sato | 2017-02-20 23:04 | プロジェクト・マネジメント | Comments(0)

契約音痴は、まだ続いている

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


<関連エントリ>
 →「契約なんかこわくない」(2008-07-17)



by Tomoichi_Sato | 2017-02-13 23:00 | プロジェクト・マネジメント | Comments(0)

お知らせ:浜松でプロマネ育成研修セミナーを開催します(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)