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

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

プロジェクト&プログラム・アナリシス研究部会」の2018年第5回会合を開催いたします。

当研究部会は2012年の12月に、4人の講師を招き、半日を使ってミニ・シンポジウムを開催しました。今回は、その時の講師の中で最も人気が高く反響の大きかった森茂利氏に、久しぶりにご講演いただきます。

森さんはリクルート社での長年の経験を起点に、現在はフリーのコンサルタントとして、主にサービス業のビジネス開発と組織づくりの仕事に関わっておられます。ところで、新しいサービスの開発とは、どのように進むものなのでしょうか? 周知の通り『独自の製品、サービス、所産を創造するために実施される有期性の業務』というのが、プロジェクトの一般的定義です。そして新製品開発だとかITシステム開発のように、成果物としての実質を作り出すプロジェクトについては、多く語られています。

しかし、目に見えず、顧客の利用と同時的にしか存在しえない「サービス」を開発していくプロジェクトの進め方、マネジメントのあり方は、当然かなり異なるはずです。とくに今回は、IT企業における事例をとりあげ、請負体質から脱却し、自らのビジネスをいかに創り上げていくかを、語っていただきます。またIT企業における営業のあり方には、さまざまな問題点が見受けられますが、森さんは営業・マーケティング改善のプロでもあり、その面でも、《お悩み解決》のヒントを多く聴けるはずです。

大勢の皆様のご来聴をお待ちしております。

<記>

■日時:2018年11月27日(火) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
5F スペース:509AB
(いつもの慶応大学三田キャンパスとは場所が違いますのでご注意下さい!
 JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
「IT企業 請負体質からの脱却
 〜 AIに振り回されず、お客さま起点で人材育成とサービス化推進中」

■概要:
50年続いているIT開発企業は、これまでずっと請負体質のままで商いを継続。しかし二代目社長になった年、次の成長にむけて、自立型企業への変革を一人に賭けた! この三年半の動きをお伝えします。

■講師:フリーエージェント、《稼げる力と強い組織創り》エヴァンジェリスト
森茂利(もり・しげとし)

■講師略歴:
名古屋工業大学卒
78年 リクルート入社
85年 ネットワーク起ち上げ事業に参加 技術系マネジャーとしてデータ・ 
   スーパーコンピュータ・音声サービスの技術支援部隊を統括
03年 ソフトブレーンに主席コンサルタントとして入社
15年 ソフトブレーン退社 独立コンサルタントとして、現在に至る

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

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


佐藤知一@日揮(株)


by Tomoichi_Sato | 2018-11-11 21:30 | プロジェクト・マネジメント | Comments(1)

海外プロジェクトの質的変化と、成功体験の罠

わたしが3年前に技術評論社から上梓した『世界を動かすプロジェクトマネジメントの教科書』は、製造業で働く若手エンジニアを主人公にした、ストーリー仕立ての本である。基本的な内容は、東大の大学院で教えている「プロジェクトマネジメント特論」の講義資料をベースにしているのだが、淡々とした記述のテキストなど、誰も興味をひかれないだろう。それにわたしは、対話形式の文章を書く方が、なぜか筆が進みやすい。

そこでこの本では、ある日突然、プロジェクト・マネジメントを急に学ばなくてはならなくなった若手技術者を、主役に立てることにした。それが、中堅製造業の製品設計部門に働くエンジニア、小川君である。彼の会社の社長は、出張先のとある新興国の企業経営者と意気投合し、共同でその国向けの製品開発プロジェクトをはじめることを、決めてくる。

しかしご承知の通り、製造業の組織というのは、営業・設計・生産技術・資材・製造・・という風に、機能別に縦割りになっている。製品開発プロジェクトは、これら全ての部署が、大なり小なり関わってくる。では、この海外企業との共同プロジェクトは、いったいどの部署の誰がリードするのか? 一般に、日本の製造業では、プロマネが所属すべき部署が、明確でないことが多い。小川君の会社もそうだった。

プロジェクト・マネージャーが誰なのかも不明なまま、結構な労力とリスクをはらむはずの、新プロジェクトは滑り出す。小川君自身はまだ、プロジェクト・マネージャーを張れるような職位ではないし、その経験もない。だが、会社のこの状況に危機感を抱いた彼は、久しぶりに会った大学時代の大先輩・広田氏に、プロジェクト・マネジメントの考え方を教えてほしいと頼み込む。

海外プロジェクトの経験に長けた広田氏は、何度かに分けて、小川君に基本をレクチャーしつつ、プロジェクトの状況を確かめ、アドバイスしていく。だが、海外通を任ずる常務、腰の引けた部長、妙に強気な課長などの上司の下で、プロジェクトを前に動かそうとする小川君に、つぎつぎと難題がふりかかってくる・・この本は、そういう話だ。

新製品開発という仕事それ自体は、製造業にとって珍しいことではあるまい。何度もそれを繰り返して、企業は成長してきているはずである。それなのに、海外企業との共同プロジェクトということになると、急に勝手が違ってくるばかりか、上手く回らなくなることが多い。それをたいていの会社は、言葉(英語)の壁だとか、技術基準の違いだとか、異文化のせいだとかにしたがる。

しかし、そこにはもっと本質的な、プロジェクト・マネジメント上の違いがあるのである。そして、多くの日本企業は、それを知らないまま、見えない壁のようなものに突き当たっているのだ。

図を見てほしい。横軸は、スコープの固さを示している。右側は自発型プロジェクトの世界で、スコープは自分で調整可能である。左側は受注型プロジェクトで、スコープは外部から与えられる。左に行けば行くほど、スコープは「固く」なる。自社の製品開発は、自分がかなり自由に決めることができるから、図では右側の領域にある。
e0058447_22584297.jpg
縦軸は、プロジェクト組織の規模・複雑さを示す軸だ。上は大型、下は小型プロジェクトの領域を意味する。ただし「規模」といっても、予算金額などで測ったのでは、プロジェクトの分野や種類によってかなり差が出てしまい、イメージが伝わりにくい。そこで図ではあえて、「小型プロジェクト」を、同じ行動習慣を持つ同士の協力、「大型プロジェクト」を行動習慣の異なる他社との協力、と注釈をつけた。

そうなると、従来の新製品開発は、図の右下の領域に位置づけられる。自社系列内で完結する場合もあるだろうし、サプライヤー等の他社と協力する場合もあるだろうが、それでも慣れた同士による国内プロジェクトである。

ところが、ほぼ同じ内容での製品開発プロジェクトも、小川君の会社のように、慣れない初めての海外企業と一緒にやることになると、図での位置が変わってくる。まず、海外企業との協力の場合、お互いの責任分担を文書化・契約化して、きっちり決める必要が出てくる。つまり、スコープがけっこう「固く」なるのである。

他方、これまでの慣れた同士の協力関係と違い、慣れない相手とは、コミュニケーションの言語やチャネルからはじまって、いろいろ目に見えない摩擦や障壁が生じがちだ。だからプロジェクト組織の規模・複雑性が,有意に上がることになる。

かくして、ほぼ同じ内容の筈の新製品開発プロジェクトが、図上でかなり左上にずれてしまう。そして、この図では、左上に行けば行くほど、専門的なプロジェクト・マネジメントが必要とされてくるのである。右下のエリアは、身内同士の阿吽の呼吸で進む領域であって、まあいってみれば、ジャズバンドのような世界である。誰かリーダーのもつ、気合いやリーダーシップで進めることができる。

ところが左上の領域は、いわばオーケストラの世界であって、数多くの演奏家(専門職種)と、指揮者(プロマネ)がいて、整然とことを進めなければいけない。各人がバラバラに動いたのでは、意味のある成果は出てこないのだ。スコープ制約が固く、かつ組織規模が大きい仕事とは、そういう存在だ。それなのに、プロジェクト・マネジメント技術もろくに知らぬまま、「気合いと根性」だけで海外プロジェクトをはじめたら、途中で現場が苦労の嵐に巻き込まれることになる。

これが、今、わたし達の社会のあちこちで起きている問題なのだ。そして、多くの若手エンジニア達が、さんざん苦労している。そういうことを、霞ヶ関の新進気鋭の官僚達にも知ってほしい。そう思って、レクチャーでは、前回も述べたように、スコープの話を主にしたのだが、さて、短い時間でどこまで伝わるかは、定かでない。そこで、あえて念押しとして、もう一枚、図を用意した。

e0058447_22595509.jpg
こちらの図は、左右がある意味、逆になっており、右に受注型プロジェクト、左に自発型プロジェクトを置いてある(不統一で申し訳ない)。上の欄に、(強い)←→(弱い) と書いてあるのは、スコープに対する主導権である。自発型の方が、当然ながらスコープの主導権が強い。受注型では、発注者の承認をもらわなければ、スコープ・チェンジが認められない。

こちらの図の上下は、買い手か売り手かという、商取引の立場になっている。取引では通常、お金を出す側の買い手(顧客)の方が強く、売り手の方が立場が弱い。

そして、この図表の4象限に、日本の海外ビジネスのあり方と変化を集約してある。

まず、高度成長期の’70〜80年代は、左下にある。この時代、衣料品にはじまり、家電・カメラ、そして自動車など、消費財の輸出で日本が伸びた時代であった。優秀・高品質な製品力と、円安による競争力に支えられ、大きく世界に進出していった。自分は売り手だからやや立場は弱いが、どこに何を売るかは自分で選ぶことができた。この時期は、「売ってあげる」型の輸出ビジネスだった、といえる。

それが'80年代後半~90年代前半のバブル時代に入ると、さらに勢いをかって、盛んに海外不動産を買ったり、企業買収・工場建設・営業所開設などのラッシュが続いた。舞台は欧米や豪州など先進国だ。そして自分が買い手で、かつ、自発型プロジェクトである。いわば最強の立場にあった時代だ。

ところがバブルがはじけ、不況の2000年代に入ると、海外調達・部品製造外注・オフショア開発などが、海外ビジネスの中心になってくる。まだ、立場は買い手だ。だが相手地域はアジア・中進国にシフトする。そして現地に行った技術者たちは、本社や日本国内の顧客からの勝手な指示に困惑しつつ、内心、OKY(「お前が来てやって見ろ」)と歯噛みしながら仕事をしていた。

そして2010年代。政府は「日本の新成長戦略」をとりまとめ、新興国に対するインフラ・システム輸出が、成長力回復の切り札だ、と位置づける。しかし、日本のものづくりの成果を海外に持っていくという事は、売り手で、受注型のプロジェクトを遂行することを意味する。すなわち、「買って下さい」型の輸出ビジネスになる、という訳だ。

わたしは長年プラント・エンジニアリング業界に働いてきた身として、それがいかに弱い立場であるかを知っているし、その中でいかに立ち回るべきかも、少しは承知しているつもりだ。そのための有力な武器の一つが、専門的なプロジェクト・マネジメント技術なのだ。だから、それについて本も書き、あちこちで講義したり宣伝したりして回っているのである。

繰り返しになるが、日本の海外プロジェクトは、バブル期頃までの、強い立場・先進国相手・売ってあげる型から、2000年以降の、弱い立場・新興国相手・買って下さい型へと、シフトしてきてきた。ところが、世の中にはまだ、バブル期までの過去の『成功体験』を、自らの栄光の記憶として抱えているシニア・マネージャー層がけっこう、残っている。

だが、彼らの成功体験はもう、賞味期限切れで、今の時代には使えないのである。昭和の古きよき時代はもう、とっくに終わったのだ。そして、そんな過去の成功体験にしがみついていると、現実がよく見えなくなってしまう。そのことを、日本の中枢にいる人たちにも、伝えたいのだ。昭和世代のわたしがこんなことを言うのはおかしいかも知れないが、これからわたし達の社会を担う層の人たちに活躍の場を残すためには、過去の成功体験の記憶を一度リセットして、新しい目で日本と海外を見るべきだと思う。


<関連エントリ>
 →「プロジェクトのスコープには硬軟がある」 https://brevis.exblog.jp/27558796/ (2018-09-20)
 →「海外プロジェクトの変化と、契約意識という不可視のハードル」 https://brevis.exblog.jp/18516049/ (2012-07-30)


by Tomoichi_Sato | 2018-09-29 23:12 | プロジェクト・マネジメント | Comments(0)

プロジェクトのスコープには硬軟がある

先月のことだが、霞ヶ関のある有力省庁に呼ばれて、プロジェクト・マネジメントについて1時間ほどの簡単なレクチャーをしてきた。聴衆は、製造業を所轄する部局の、若手中堅の官僚20人弱である。先方からは『ビジネスで成功を勝ち取るプロジェクトマネジメントとは』という、いささか大げさなタイトルを頂戴したが、いかんせん1時間弱でしゃべれる事は限られている。

短い時間でプロジェクト・マネジメントのエッセンスを紹介するなら、何を話すべきか。相手にもよるが、わたしはスコープとWBSの概念の話をすることにしている。プロジェクトにおいて、日本人は概して、計画軽視だ。与えられた目標や暗黙の目的意識のもとで何となく走り出し、人を集め、あとは各人の努力と互いのすり合わせで進めていく。「現場重視」「歩きながら考える」の習慣が、とても強い。

欧米人と一緒に仕事をした経験のある人なら、彼らはまず、全体の計画を立てるところからはじめる習慣が強いことを、ご存じだろう。計画を立てずに走り出すことは、まるで地図を持たずに旅に出るようなもので、心配になるらしい。プロジェクト・マネジメントという概念も、PMBOK Guideのような標準書も、このような文化の元で生まれ育った。

計画力と現場力は、車の両輪で、どちらが弱くても真っ直ぐちゃんと走れない。ただ、自分たちが何に弱いかは、そこに強い相手と組んだり闘ったりしないと、なかなか気づかないものだ。たまたまわたしは、海外プロジェクトを中心としたビジネスをする企業にずっと勤めてきたので、ある程度は両方を知っている。

とくに、日本は製造業の影響力が大きいので、「QCD」、すなわち品質・コスト・デリバリー(納期)の制約については、多くのビジネスマンが常識として肌身で知っている。しかし、現代プロジェクト・マネジメント(モダンPM)の柱は、

 QCD+S

の4つなのである。4番目のSは、『スコープ』の頭文字だ。いや、海外の文献などを読むと、品質は当然の前提としてQを抜かし、SCDの3つがプロジェクトの柱だ、という言い方が多い。スコープは、モダンPMの第一の柱、最大の制約条件なのだ。事実、PMBOK Guideを見てもらえれば分かるように、10の知識エリアの記述順は、最初に統合マネジメント、次がスコープとなっている。

そして、スコープの具体的表現手法として、WBSがある。これはプロジェクト・マネジメントの基礎となる手法で、60年代頃から整備されてきた。だが、この一番肝心なスコープとWBSの概念が、日本では良く理解されていない。

プロジェクトは、何らかの成果物やサービスを生み出すための営為である。ただ、プロジェクト全体は大きいし,出発時点ではもやっとしていて、それを全体として扱うのはやりにくい。そこで西洋人は、彼らの思考習慣である"Structured Approach” にしたがって、大きな問題を小さな部分問題に分割していく。つまりプロジェクト全体を、やらなければならない具体的な個別の要素作業に、階層的に分解するのである。

この要素的作業を『アクティビティ』とよぶ(日本のIT業界では「タスク」ということが多いようだが、PMBOK Guideは昔からActivityという用語で統一している)。そしてプロジェクト全体のスコープ(仕事の責任範囲)を、アクティビティ(タスク)の集合として捉えるのである。まあたとえて言えば、日本全土を、都道府県に分け、さらに県を地形に従い市町村に分割するようなものだ。そのようにして、全体のエリアを、統括可能な部分に分けて地図を作る。

わたしのレクチャーでは、簡単なプロジェクトの例をとって、それを構成するアクティビティの洗い出しを10分ほどの演習で体験してもらった(さすがに優秀な人たちが多く。通常の社会人相手のときより倍近い早さで進んだ)。そして、次は洗い出したアクティビティを、紙の上で階層的に図示してもらう。これだけでも、気づかなかった抜け漏れや作業のアンバランスなどが、気づきやすくなる。

スコープとはプロジェクトのなすべき責任範囲のことであり、それをアクティビティに階層的に分解して、管理番号を付番したものがWBS(=Work Breakdown Structure)である。これは仕事のスコープの見取り図、地図に相当する。WBSこそはプロジェクト・マネジメント計画の出発点であり、その出来不出来によって、その後のマネジメントの成果を大きく左右する。

WBSの一例を、図に示す。これはわたしの勤務先の得意とするプラント・エンジニアリング系のプロジェクトについて、WBSの骨子を示したものだ。本当はもっとずっと詳細なのだが、骨格を理解してもらうのが目的なので、枝葉はばっさり切ってある。
e0058447_23493235.jpg
なお、ここに示したWBSの構成は、Functional-WBS(略称F-WBS)とよばれる種類のもので、主に仕事の機能のプロセスを主体としたものだ。他に成果物の構造にしたがったProduct-WBS(P-WBS)もあるのだが、話が複雑になるのでここでは省略する。

このWBSには、とくに時間の概念はないことに注意してほしい。まだ、ガントチャートは、ない。この後、それぞれのアクティビティの作業量を見積り、割り当てるリソースの量を決めて必要な期間を推定し、さらにアウトプットとインプットから生じる関連性(他のアクティビティとの依存関係)を考慮して、初めてガントチャートが作成可能になる。

日本ではガントチャートのことをWBSだと誤解したり、スコープを明確化する前に、いきなり線表を描き始めたりする『ダイレクト・ガントチャート』方式の人が少なくないが、それでは成功するはずのプロジェクトだってうまくいかない。こうしたことを、日本の中枢を担う若手官僚に分かってもらいたかったのである。

さて、ここから先は、PMBOK Guideにあまり書いていない、大事な話になる。それは、プロジェクトはスコープのあり方に応じて、二種類に分けられ、それに応じてマネジメントの力点も変わる、ということだ。

どういうことかというと、プロジェクトはスコープが『ハード』なものと、『ソフト』なものに分類可能なのである。ハードなスコープとは、プロジェクトのなすべき責任範囲がかなりかっちりと規定されているタイプのものだ。これに対して、ソフトなスコープは、プロジェクトの範囲が、途中でかなり変わりうる(自分で変えうる)タイプである。

なお、プロジェクトについての”Hard”, “Soft"という用語は、2000年頃から欧米のPM研究論文などに現れるようになってきた。ただし、これは別にコンピュータのハードとソフトの話をしているのではないので、注意されたい。鋼鉄製の橋を架けるのはハードなスコープで、木の吊り橋はソフトだ、という話でもない。あくまで、なすべき仕事の領域・範囲の変わりやすさ、硬軟をいっている。

簡単に言うと、自社が自らの意思ではじめる「自発型プロジェクト」、たとえば製品開発や社屋新設などのプロジェクトは、スコープがソフトな場合が多い。他方、誰か顧客から請け負う「受注型プロジェクト」は概して、スコープがハードだ。スコープがふにゃふにゃして曖昧だったら、そもそも見積ができないから、契約が成立しない(無論、単価契約とか派遣契約にすれば別だが、その場合はプロジェクト・マネジメントの責任を受注側は負わない)。

スコープがかっちりと固まっている受注型プロジェクトにおいては、プロマネは通常、コストと納期を、よりシビアにコントロールすることが求められる。したがって、ハード・スコープのプロジェクトを沢山遂行する組織においては、プロマネにより権限が与えられなければならない。権限がなく、判断もできずに、責任など負えないからだ。マネジメントの主眼は、スケジュールとコストになる。

(ただし余談だが、日本のIT企業の方の話を聞いていると、プロマネにはコスト管理の権限がなく、ただ与えられた予算と人員の中で、スケジュールをなんとか守る事が求められているケースが多いようだ。これはわたしのような他の業界人からは、奇妙に見える。コストの権限が上司が握ったまま、納期と品質の責任だけを問われるのでは、まるで後ろ手にしばったパン食い競争みたいで、ずいぶんだと思うのだが)

さて、ところで、自発型プロジェクトは受注型とかなり違う。たとえば新製品開発を考えてみよう。予算を満たし納期を守っても、できあがった製品に魅力がなければ、プロジェクトは失敗だ。したがって、プロマネは何よりも、ユーザにアピールする品質(「前向き品質」)を上げるべく、スコープを調整することになる。この種類のプロジェクトでは、プロマネは管理・監督よりも、創造の役割を強く求められる。

だから、ユーザを惹きつけないと成立しない、いわゆる『SoE』(Systems of Engagement)では、アジャイル開発などの手法に価値が出てくるのだ。アジャイルでは、スコープを動的に入れ替え、調整して進んでいく。しかし、設計図通りに橋梁を建設するようなプロジェクトには、アジャイルは使えない。スコープがハードだからだ。

さて、スコープについて、一般的教科書にあまり書いていないことまで説明したのは、理由がある。せっかく霞ヶ関まで行って、日本の製造業や貿易政策を担う省庁の人たちに聞いてもらうのだから、もう一つ、説明しておきたいことがあったからだ。

それは、海外プロジェクトの進め方に関する留意点、彼我の違いについてである。日本企業とその製品群は、70年代頃から、世界を席巻した。自動車、家電、カメラ、パソコン等、あげればきりがない。高度成長期とはまた、日本企業の国際化・グローバル化の進展でもあった。——そういう風に、マスコミをはじめ、多くの人たちが思っている。

だが、その思考には、意外と大きな大きな罠がひそんでいるのだ。そして、それが『スコープ』の硬軟の概念と、密接に関係しているのである。

(この項つづく)


<関連エントリ>
 →「ダイレクト・ガントチャート方式の問題点 〜 やはりExcelで工程表を書いてはいけない (1)」 https://brevis.exblog.jp/26231556/ (2017-12-02)
 →「Structured Approachができる人、できない人」 https://brevis.exblog.jp/18336958/ (2012-07-08)


by Tomoichi_Sato | 2018-09-20 23:54 | プロジェクト・マネジメント | Comments(0)

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

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


今回は、元フジテレビ海外特派員、テレビ静岡会長で、現在は一般社団法人静岡アジアパシフィック協会理事長の曽根正弘様に、メディアから見た世界の転換点と、その取材とについてご講演いただきます。


ご存じの通り、現在のマスメディアは時間的な媒体であり、とくにTVの場合は取材におけるリアルタイム性の高さが求められます。そして、対象とするのは、繰り返しのない一過性の出来事で、かつライバルとの激しい競争もあります。
そのような現場を抱える中、どのような形で世界的な出来事にかかわり、それをレポートしているかについて、貴重な体験をベースにお話しいただきます。


他では聴けない、興味深いご講演は、暑い夏の夕べ、一服の清涼剤となるはずです。

大勢の皆様のご来聴をお待ちしております。


<記>

日時:2018831日(金) 18302030

場所:慶応大学三田キャンパス

 北館会議室21階)(定員:28

 https://www.keio.ac.jp/ja/maps/mita.html

 キャンパスマップ 【1


講演タイトル:

タイトル「TV特派員が現場で見た世界の転換点」


概要:

フジテレビ特派員としてモスクワ、ワシントン、ニューヨーク、ロンドンと転任する中で、東西冷戦の終結、ソ連のクーデターに端を発する体制崩壊を千載一遇の機会を生かして現場レポートをすることができた顛末を語る。


講師:一般社団法人 静岡アジアパシフィック協会

理事長 曽根正弘(そね・まさひろ)


講師略歴:

略歴:

静岡県出身

1964年早稲田大学卒、()フジテレビジョン入社。

1970-71 米国ミシガン大学、MITに短期留学。

1982-85 モスクワ特派員・支局長。

1989-90 ワシントン特派員・支局長、FCI報道担当副社長。

1990-94 ロンドン特派員・支社長。

1994-98 フジテレビ総合調整局長、社長室長、取締役国際局長

1998 ()テレビ静岡移籍

1998-2017 同社専務取締役、代表取締役社長、会長、相談役、顧問

(この間、静岡商工会議所情報文化部会長、静岡交響楽団理事長、静岡市

 行財政改革推進審議会会長ほか兼職多数)

現在:()TOKAIホールディングス社外取締役、東京音楽大学特任教授、

 静岡県ニュービジネス協議会統括副会長ほか。


参加費用:無料。

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

 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。



佐藤知一@日揮(株)



by Tomoichi_Sato | 2018-08-18 17:58 | プロジェクト・マネジメント | Comments(0)

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

各位:

「プロジェクト&プログラム・アナリシス研究部会」の2018年第3回会合を開催いたします。

今回は、ギルドワークス(株)代表の市谷聡啓様に、アジャイル開発プロジェクトについてご講演いただきます。

2001年に米国で「アジャイルソフトウェア開発宣言」が発議されてから、すでに17年がたち、アジャイル開発は日本のIT業界でも、かなり広く認められる手法となりました。とくに開発・実装の仕事に直接関わる人たちからは、大きな期待が寄せられています。またPMIが昨秋発表した「PMBOK Guide」第6版は、「Agile Practie Guide」との合本の形で発売され、米国のプロジェクト・マネジメント分野でも重要性が増していることが分かります。

しかし、多くの利点にもかかわらず、現実のアジャイル開発は様々な障壁やチャレンジに直面し、また不振なプロジェクトの事例を耳にすることも出てきました。その理由にはソフトウェア技術的な面から、日本におけるIT業界の構造・慣習の面まで、いろいろあるようです。IT業界がたまさか活況を呈し、人手不足も語られる今日、アジャイル開発の賢い進め方について、この分野でエヴァンジェリスト的に活躍される市谷様からお話を伺います。ご期待ください。


<記>

■日時:2018年6月7日(木) 18:30~20:30

■場所:場所:三田キャンパス 研究室棟B会議室(1F)定員:36名
※キャンパスマップの【10】
HPの下部にキャンパスマップがございますので、ご確認ください。

■講演タイトル:
アジャイル開発の実際

■概要:
 改めてアジャイル開発とは何か。そして、日本の現場ではどのように実践されているのか。
プロジェクト、プロダクト開発の運営の観点から、アジャイル開発の実際についてお話ししたいと思います。

■講師:ギルドワークス株式会社 代表・株式会社エナジャイル 代表   市谷聡啓(いちたに・としひろ)

■講師略歴:
 サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、ギルドワークスを立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。著書に「カイゼン・ジャーニー」、訳書に「リーン開発の現場」がある。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら当日までに三好副幹事までご連絡ください。

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

佐藤知一@日揮(株)

by Tomoichi_Sato | 2018-05-19 18:49 | プロジェクト・マネジメント | Comments(0)

プロジェクトの成功と、アウトカム

「自分がチャレンジする予定のプロジェクトでは、ゴール到達から成功失敗の判断まで半年かかることになっていますが、このような目標設定は適当ですか?」

今回は、この質問を取り上げよう。例によって、大学でプロジェクト・マネジメントの講義をしていた時、学生から出てきた問いである。そして、とても良い質問だ。

このときの講義のテーマは、「ミッション・プロファイリング」だった。この用語は、PMBOK Guideには出てこないので、なじみのない読者も多いかとは思う。プロジェクトにおけるミッション、すなわち使命を、その目的・ゴール及び目標(=成功基準)などの観点から、分析・定義し文章化する作業である。その結果がプロジェクト・チャーターになる。

授業では特に目標設定の大切さを学生に教え、修士論文や就活を題材に、プロジェクトとしての目標を考える、簡単な演習を入れている。さらに、自分がこれから将来関わるであろうプロジェクトの内容を考えて、そのゴール・目的・目標を、簡単なプロジェクト・チャーターの形に書かせている。上記の質問は、その中から出てきたものだ。

この学生はどうやら、新しい技術を使った製品開発のプロジェクトにチャレンジしようと考えているらしい。プロジェクトがゴールに到達し、すなわち製品が無事に開発完了しても、それが本当に世の中に受けられるかどうか、売れて経済的にペイするかどうかは、その後半年ぐらいしないとわからない。そういう状況下で、プロジェクトの成功基準は、どのように考えるべきか?

この質問を見て、私は3月に日経ビジネスオンラインが発表した、あるITプロジェクトの調査結果を思い出した。
プロジェクト失敗の理由、15年前から変わらずhttp://business.nikkeibp.co.jp/atcl/opinion/15/100753/030700005/?P=1
という記事で、著者は日経コンピュータの元編集長・谷島宣之氏である。サブタイトルに、「1745事例を調査、成功率は52.8%」とある。簡潔ながら要点をついた、良い記事であると思うので、読まれることをお勧めする。

この記事によると、日経コンピュータ誌が2003年に行った第一回の調査や、その後、数年おきに行われた調査結果から見て、日本では明確にITプロジェクトの成功率が上がってきていると言う。それ自体はとても重要で、良いニュースだ。「成功率が上がった理由の一つはプロジェクトにおける定量管理の普及だ」と記事は書いている。また、「失敗理由の筆頭はシステムの『要件定義が不十分』」というのも、うなづける内容である。

ところで、この記事における「プロジェクトの成功」とは一体どのように定義されているのだろうか? それは、「品質、コスト、納期の3点を順守できたか」である。品質をスコープに読み替えると、つまり『鉄の三角形』を守ることができたか、と問うている訳だ。

実は、この日経コンピュータ誌と同様な調査を、米国ではStandish Groupという調査会社が'90年代から継続的に行ってきた。1994年以来、3年おきに発表された調査レポートでも、プロジェクトの成功率が問われ、そして徐々にあがってきている。それはプロジェクト・マネジメントの普及による成果だと解釈されている。ちなみに、Standish Group の定義は次のようになっている。

Successful: completed on time, on budget, with all specified features.
Challenged: completed and operational, but over-budget, over time and with fewer features than specified.
Failed: the project is cancelled before completion or never implemented.

すなわち、品質・コスト・納期を計画通り満足して終わった「成功プロジェクト」と、完了したが 3 大制約条件を満たせなかった「困難なプロジェクト」、そして中断終了した「失敗プロジェクト」のクラスがある。2003年の調査では、成功プロジェクトの比率は34%だった。同じ2003年の日経コンピュータ誌調査では、日本の成功率は約27%だったから、日本は米国の後を追いかけている訳だ。

それはともかく、ここで問題にしたいのは、プロジェクトの成功を、コスト・品質・スケジュールの3点で定義していいのかということだ。それはいわば、プロマネ視点から見た成功、と言うことに過ぎない。鉄の三角形と言う大きな制約条件を満たした。それ自体は立派なことだ。だがプロジェクトとは、その成果物が価値を生み出して、初めて意義があるのではないか。

どんなに立派なシステムを開発しても、ユーザがちっとも使ってくれなかった。そういう事例は、しばしば起きる。立派な地方空港を建設したが、閑古鳥が鳴いている事例もある。「仏作って魂入れず」とは、まさにこのような状況だ。

プロマネの視点から見た、プロジェクト・マネジメントの成功だけで、プロジェクトの出来不出来を判断していいのか? ここが問われている。新製品の完成後、世に受け入れられるかどうかは、半年ぐらい経ってみないとわからない、という最初の学生の質問は、まさにこの点をついているのだ。

そこで必要となるのが、アウトプットとアウトカムの区別である。アウトプットとは、プロジェクトが直接生み出す成果物である。それは情報システムだったり、橋だったり地方空港だったりする。

では、アウトカムとは何か? それはプロジェクトの成果物を活用することでもたらされる、変化である。情報システムで生み出される、新しい業務プロセスかもしれない。橋がかけられたことで生じる、地域交通の活性化かもしれない。地方空港のもたらす、新しい経済効果かもしれない。
e0058447_22495408.jpg

図を見て欲しい。プロジェクトとは、インプットとして資機材等何らかのマテリアル、そして情報を受け取って、何らかのアウトプット=成果物を生み出す活動である。プロジェクト起動のトリガーとなるのは、何らかのオーダーなり受注であろう。プロジェクトを遂行するには、人々あるいは道具といったリソースが必要である。また、様々な要求事項や制約条件もあろう。途中段階や最後でのレポートも必要だろう。

アウトプットを生み出せば、プロジェクト自体は完了する。しかしビジネスとしては、その先に大事なステップがある。それは成果物を活用して、アウトカムを生み出すことだ。

このような構造を考えると、プロジェクトにはざっくりいって、2種類の成功があると考えられる。それは短期的成功と長期的成功だ。

プロジェクトの短期的成功とは、効率よくアウトプットを生み出すことである。プロマネ視点での成功といってもいい。これに対し、長期的成功とは、プロジェクトが価値あるアウトカムをもたらすことである。

英語ではよく、"do things right" と "do right things"という言い方で、この2つを区別する。Do things rightとは、ものごとを正しく(上手に)やること。Do right thingsとは、正しい(良い)ものごとを行うことを意味する。効率よく上手にやることが大切だが、価値あるものを作り出すことの方が、もっと重要だ。

これに関連して、KPIとKGIという言葉もあげておこう。KPI(Key Performance Indicator)とは、いうまでもないが、仕事のパフォーマンスを測るための主要なモノサシである。企業活動全体なら、売上高とか利益だとか総資本回転率といった尺度だ。何かをマネジメントしたかったら、対象を計測して数値化し、それを計画や過去の類似実績や標準値と比較し、改善活動を促していく。これが定石である。プロジェクト・マネジメントの場合ならば、進捗率だとか総工期などがあげられる。EVMS(Earned Value Management System)の中にも、CPI(Cost Performance Index)とかSPI(Schedule Performance Index)などの尺度が内蔵されているのは、ご存じの通りだ。

KGI(Key Goal Indicator)という言葉は、最近になってマーケティング、とくにWebマーケティングの分野で耳にするようになった。KPIが、途中のプロセスのパフォーマンスを表すのに対して、KGIはゴール=結果の(たとえば顧客の購買率などの)よしあしを直接示す、という風に使われる。

もしこれを、KPIはアウトプットに関するモノサシで、KGIはアウトカムに関する尺度だ、と解釈できるなら、上に述べた説明とちょうど合致する。ただ、KGIはそれを支える複数のKPIのツリー状になっている、という解説も見受けられるので、必ずしもそうもいいきれない。まあ、Webマーケティングとプロジェクト・マネジメントという異なる分野での概念なので、違っていても当然かも知れないが。

いずれにしても大事なことは、プロジェクトの成功・不成功は、そのプロジェクトが完了した時点だけでは必ずしも決まらない、と認識することだ。あるいは、プロジェクトの価値は、そのプロジェクトだけを見ていても定まらない、と言いかえても良い。もしもその「プロジェクト」が、単にアウトプットを出すまでの射程距離を指すのなら、ということだが。そしてプロジェクトの成功を本気で心配するならば、「プロジェクト後」をケアしなければならない訳だ。だから、「ユニークな製品、サービスあるいは所産」を創造するまでをプロジェクトの範囲と考えると、プロジェクトの価値論はそこから抜け落ちてしまうことになる。

仏を作って魂を込めたいならば、プロジェクト後のアウトカムの活用まで面倒見なければならない。また、活用しやすいアウトプットの要件を、最初に定義し設計することからはじめなければいけない。ここが肝要なのだ。「与えられた要件とSOWから、コスト・納期・品質の制約内で、成果物を効率よく生み出す」ことがプロジェクト・マネージャーのスコープだとすると、魂を入れる仕事は、その外側、ないし上位にある。

プロマネの上位にあって、プロジェクトの価値を本当に作り上げるのは、じつは『プログラム・マネジメント』の仕事である。プロジェクトを起動し、プロマネを任命し、途中途中でプロマネを助け、評価し、成果物を受け取り、それを元に組織能力を変えていくのも、プログラム・マネジメントの仕事だ。完成しても価値を生まない、意味の無いアウトプットを作ろうとしている問題プロジェクトに中止を命ずるのも、プログラム・マネジメントだ。

そういう意味で、わたしたちの社会で本当に足りていないのは、プログラム・マネジメントの方なのである。そこの欠落を、プロジェクトのレベルで何とか解決しようともがいているプロマネが、あまりにも多い。それはとくに、要件定義から成果物構築までの段階を、ほとんどすべて外部にアウトソースしてしまう、IT分野に著しい傾向なのかも知れぬ。

多くの人は、「プログラム」とは同時に複数のプロジェクトを束ねたものだ、と理解しているようだ(米国PMIの定義)。しかし、わたしは、たとえ単一プロジェクトでも、プログラム・マネジメントは成立するし、必要だと考えている。プログラムとは、組織が新しい能力を獲得して成長するために行う活動の仕組みである(英国MSPの定義)。つまり、組織としての成長への経路を、一歩一歩進んでいくのが、プログラム・マネジメントだ。だから、もしもプログラム・マネジメントを日本語で強引に表すなら、『成長行程管理』という言葉が適切かも知れないと、夢想するのだ。あるいは、『戦略行程管理』の方が受けるかな?


<関連エントリ>
 →「プロジェクトにとって成功とは何か ~ESC Lille PM Seminarより」 https://brevis.exblog.jp/8567708/ (2008-09-05)
 ・・10年も前の記事ですが、今回の話の原点は、ここにあります。


by Tomoichi_Sato | 2018-05-07 23:21 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントの能力は何で決まるか



先週からまた、大学で行う週一回のプロジェクト・マネジメントの講義が始まった。準備にはそれなりに手間がかかるが、それでも、授業自体は楽しい仕事だと思う。わたしはなるべく、大学の講義をインタラクティブにやろう、と心がけている。単なる一方的な講義形式では面白くないし、自分が学生だった頃のことを思い出してみても、そうした授業で頭に残った事は少ない。

教育とか研修は、それを受けた後で、自分自身の行動が変わらなければ、ほとんど価値がない。学びとは、自分の能力を高めるために行うものだ。単に知識が増えただけで、自分の行動に変化がなければ、何かを学んだことにはならない。だから、せめて授業の間は、なるべく学生に考えてもらい、また、手を動かしてもらうようにしている。インプットだけでなく、何かアウトプットしてもらうことで、相手の理解も測れるからだ。

そしてもちろん、一番良いのは、質問をしてもらうことである。ただ、授業中に「何か質問ありますか?」と問いかけても、学生が手をあげてくる事は、ほとんどない。他の皆の前で、何か質問を口に出すことには、心理的な抵抗があるらしい。私たちの社会におけるコミニケーションには、「受信者責任の原則」とも言うべき暗黙のルールがあるらしく、理解できないのは、受け手の側の理解力が低い(=頭が悪い)せいだ、と判断されかねないからだろう。

仕方がないので、わたしは講義の際、毎回必ず「出席シート」の紙を配り、そこに授業で感じた質問や、コメントを書いてもらうことにしている。こうすると、無口な学生たちもそれなりに、色々と質問を書いてくれる。こうして出た質問は、次の週、授業で極力回答するようにしている。

中でも、いい質問だなぁ、と感じる問いに対しては、「今週のGood Question賞」を与えることにしている。良い質問は、教える教師にとって、何よりもうれしい報酬である。質問が出るという事は、教え方に足りない点があったことを示しているし、特に良い質問は、教師のものの見方に、新しい光を投げかけてくれるからだ。良い質問は大抵、答えるのがやや難しい質問だし、それを考えることで、むしろ教師を育ててくれるのだ。

さて、先週のプロジェクトマネジメント講義の第一回目のテーマは、「プロジェクトとは何か? マネジメントとは何か?」だった。まぁ要するに、全体へのイントロダクションである。プロジェクトの定義を説明し、それを自己流に敷衍する。さらに「マネジメント」なる言葉の意味の中核には、「人を動かす」ということがあると説明した。

さて、帰り道に出席シートを読んでいると、次のような質問に出くわした。なかなか面白い質問だと思う。読者諸賢だったら、この問いにどう答えられるだろうか?

「マネジメントの能力は、どう見極めるのが良いのでしょうか。単にプロジェクトの成功・失敗だけで評価するなら、プロジェクトの難易度に差があるので、不公平だと思いました。それとも『結果がすべて』なのでしょうか?」

とても良い視点からの質問だ。プロジェクトを扱ういろいろな企業の経営者に、そのまま問いただしてみたい気持ちにもなる。プロジェクトは一つ一つが固有の、その場限りの、時限的な取り組みだから、難易度に差があるのも当然である。この学生はちゃんと、その本質を理解している。その上で、この問いを投げかけている。

「プロマネは結果が全て」という決めつけ方に、わたしはずっと反対してきた。それは、個々のプロジェクトを取り巻く環境の違い、難易度の差をまるで無視した、ものの言い方だからだ。以前も書いたが、プロジェクト・マネジメントの能力は、いわば確率的な能力である。プロ野球の選手だって、一度限りの打席の結果だけで能力を判定したりはしない。何試合分か、ないしはシーズン全体の打率(ヒットの確率)で、能力を測るのである。

「優秀なプロマネなんかいない。運の良いプロマネがいるだけだ。」という言葉を、最近、ある大先輩から聞いた。一種の逆説であろう。優秀なプロマネさえ連れてくれば、どんなに難しい大規模プロジェクトでも、うまく収まるはずだ、といった思い込みに警告を発する言葉だ。

そもそも、プロジェクト・マネジメントの能力とは、プロマネ個人の能力だけで決まるものなのだろうか? このような思い込みは、世間でかなり根強い。

こうした信憑は、さらに3種類に区分することができるように思う。第一は、プロマネの能力は、その人の人柄や根性、あるいは頭の回転の速さで決まるという考え方である。「あの仕事がまとまったのは、プロマネの彼が根っから優秀だからだよ」と言うわけだ。つまりプロジェクト・マネジメントの能力は、プロマネの資質で決まるとの信憑である。

もしこのような考え方が正しいのだとしたら、会社がプロジェクトマネジメントの能力を向上するには、どういう対策が必要だろうか? 資質はある意味、生まれつきのものである。である以上、生まれつき優秀な人間を、プロマネの座につけるかどうかで、ビジネスの成否が決まってしまう。逆に言えば、だめなプロマネ達は、もう一度生まれ変わるしかない、ということになる。まことに身もふたもない結論だ。だが、これで能力向上の処方箋と言えるだろうか?

第二の考え方は、「プロジェクト・マネジメントの能力はプロマネの知識で決まる」というものである。こちらの方が、能力は生まれつきだと言うよりは、多少救いがある。知識ならば、本や研修から得ることができるからだ。十分な知識があるかどうかは、ペーパーテストなどの試験で検証可能だ。そして実際、PMP (Project Management Professional)の資格試験などは、こうした論理でてきあがっているように思う。そうでなければ、パソコンの端末に向かって何時間も、ひたすら4択問題を答えさせる、などという資格審査の方法を思いつくだろうか。

しかし本当に、プロジェクト・マネジメントの能力を、知識だけで判断して良いのだろうか? 知識量と記憶力では、人間はコンピュータにかなわない。だとすると、いずれプロマネの仕事は、AIが人間を駆逐することになる。そして人々は、ただコンピュータの指示に従って、仕様書を書いたり、構築結果をテストしたりするだけの身分になる。・・これで本当に、全てのプロジェクトは、成功するようになるだろうか? この考え方は、いささか疑問に思える。

となると、プロジェクトマネジメント能力は、プロマネ個人のスキルである、ということになる。資質でもなく、知識だけでもない、と。これが三番目の考え方である。スキルとは身体化された技能で、かつ、ある程度まで属人的なものだ(「あの人のスキルはすごい」というが、「あの会社は高いスキルを持っている」とは、普通言わない)。

スキルは身に付けることができる。なおかつ、スキルを身に付けるには、練習が必要である。ここが単なる知識取得と違う点だ。そのためには、実地練習の場を作る必要がある、ということになる。練習の場とは、言い換えれば、失敗しても、傷つかずにすむ場所である。そうした場を作り、提供できるかどうかが、エンジニアのPM能力の向上のカギになると言うことだ。

ところで、ここまでは、PM能力はプロマネ個人の能力だけで決まる、と言う立場の議論だった。これに対し、いや、プロジェクトのパフォーマンスは、プロマネとチーム員の能力で決まるはずだ、という見方もありうる。つまり、組織としての能力ということである。わたしは、どちらかということこの意見に組する。

ただ、この考えも、2種類に区分できよう。よくありがちな見解は、「組織の能力は、構成員の能力の足し算である」、との考えだ。これは、能力ある人間を揃えれば、自動的に組織のパフォーマンスもよくなる、という、単純な足し算の論理である。オリンピックなどで、トップチームのスタープレイヤーばかりを集めた「ドリームチーム」を作れば最高だ、という話がでるが、この延長上の発想だと思う。

では、この考え方からは、どのような能力の向上策が導かれるだろうか。各人の能力はまちまちである。となると、良いプロジェクト運営をしたければ、ベストなメンバーを選ぶしかない、ということになる。つまり社内での人の取り合いを、推奨するわけだ。でも、これでは企業全体のパフォーマンス向上にはつながるまい。

そしてドリームチームが必ずしも最高でないのと同じように、組織もまた、単なる能力の足し算では決まらない。そもそも能力といっても、いろいろ種類がある。プロマネに求められる能力と、チーフ・デザイナーに必要な能力と、品質管理責任者の能力は異なる。こうした別々の能力が、適材適所に生かされるよう構成配置し、かつ問題を速やかに検知して対処するのが、そもそもプロマネの仕事ではないか。つまりマネジメント能力とは、「能力に関する能力」、ないし「能力を活かす仕組みづくりの能力」なのである。

そうした仕組み(システム)を、組織の全員が理解・共有し、皆がその中で安心して働ける状態になっていること。だから、毎回書いていることだが、プロジェクト・マネジメントにはシステムズ・アプローチが大切なのである。そして、システムズ・アプローチから生み出されたWBSやCPM・EVMSといった技術が重要になる。

つまり、プロジェクト・マネジメント能力は、組織が共有する技術で決まる、というのがわたしの考えだ。技術は本来、蓄積・移転可能なものだ。その技術をもとに、仕組み(システム)を作る。無論、プロマネ個人のスキルも、もちろん必要である。ただ、それだけで十分条件にはならない。組織の構成員一人ひとりが、その思考と行動習慣(=組織のOS)を共有すること。これが能力向上の処方箋である。
e0058447_23385319.jpg
ここに書いたようなことは、別にわたしの独創ではない。落ち着いて順序立てて考えれば、誰でも思いつくことだ。もちろん、見解の差はあるだろう。「やっぱり人間の能力は、生まれつきの差だろ」と信じるのは自由だ。だが、そこから、どういう帰結が生じるかも、考えてみてほしい。

もしも仕事のパフォーマンスを左右する能力が、リーダーやプロマネ個人に付随する能力だけで決まるのだとしたら、企業の成長力は、優秀な人間の頭数で制約されることになる。優秀な人間は限られていて、急には育たない。したがって、このような思想に立つ限り、ビジネスをスケールアウトすることはとても難しいーーこれが道理である。

わたし達の社会は、こんな個人依存の考え方を、もう20年この方、続けてきた。その間、海の外の競合相手は、仕事のシステムを作ることで、成長とスケーラビリティを実現してきたのだ。今やその差は、歴然としつつある。

わたし達に必要なのは、仕事に関する基本的な概念について、思い込みや常識をいったん置いて、ロジックを見直してみることではないだろうか。それは、上に述べたように、大学生にだって発問できるのである。知識を勉強することだけで十分ではない。良い質問を考える事こそ、はるかに価値があるのだ。


<関連エントリ>
 →「マネジメントとリーダーシップはどう違うか」 https://brevis.exblog.jp/24082343/ (2016-01-25)
 →「天の時・地の利・人の和と、プロジェクト」 https://brevis.exblog.jp/26170090/ (2017-11-12)


by Tomoichi_Sato | 2018-04-08 23:48 | プロジェクト・マネジメント | Comments(0)

スコープ・組織・スケジュール・コストの間の依存関係 〜プロジェクト・インテグレーション・マネジメントのもう一つの顔

うーむ、長いタイトルだな(笑)。そもそも、「プロジェクト・インテグレーション・マネジメント」という用語自体が長い。カタカナで23文字もある。PMBOK Guideの邦訳版のように「プロジェクト統合マネジメント」としても、14文字だ。しかしこれ、”PIM"とかって3文字略語にしても通じないだろうし、致し方ないだろうな。

前回の記事にも書いたが(「プロジェクト・インテグレーション・マネジメントと『鉄の三角形』」https://brevis.exblog.jp/27102305/)、現在のPMBOK Guideには、PMに必要な10のマネジメント知識エリアが列挙されている(初期の頃は9個だった)。そしてその中核となるのが、「プロジェクト・インテグレーション・マネジメント」(ああ長い^^;)である。それは、他の9個の領域のマネジメントを統合する。そして、他の9個の領域には、とくに順序はなく、対等だということになっている・・PMPの試験対策的には。

しかし、もちろんそんな事は嘘である。9つの領域:スコープ・スケジュール・コスト・品質・人的資源・コミュニケーション・リスク・調達・ステークホルダーエンゲージメント、の間には、実務上、明確な軽重があり、そして順序に関する依存関係がある。なぜそういうことをPMBOK Guideがはっきり書かないのか、わたしにはよく分からない。だが、9個のマネジメント領域の間をどう調整していくかこそ、「インテグレーション・マネジメント」の一番大事な機能である。こうしたことを知らないと、プロマネの実務上、明らかに不便だ。だから、ここにそれを記しておこうと思う。

まず、プロジェクトを取り巻く様々な制約条件の内、もっとも広く存在し、そして強くしばられるものは、「スコープ」(役務範囲)と、「予算」と、「納期」の三つである。そこで、これを『鉄の三角形』と呼ぶことは、前回も書いた。言いかえるなら、プロジェクト遂行において、プロマネがつねに意識の上位においておかなければならないのは、スコープ・スケジュール・コストの3つである。そして、だからこそ、PMBOK Guideはごく初期の版の頃から、この3領域が最初の方におかれてきたのだ。

もちろん、プロジェクトにはいろいろな種類があるし、個性や取り巻く状況も様々だ。だから、納期制約のないプロジェクトもあるし、予算を気にしなくてもいいプロジェクトだって(うらやましい限りだが)希には存在する。逆に人的資源(つまり配員)の制約が一番きついとかいうケースだって、あるだろう。ただ、もっとも多くの場合、上記の3つが主要な制約条件なのである。

ちなみに、受注型プロジェクトと違い、自発型プロジェクトの場合は、スコープ制約よりも品質(ないしプロダクトの性能)制約の方が優先される場合も多い。とくに新製品開発などではそうだろう。また、納期制約や予算枠も、受注型より弱い場合がある。でも、通常は「スコープ・コスト・スケジュール」または「品質・コスト・スケジュール」が、プロマネにとって主要な関心事項なのである。

(なお、品質とスコープの間には相補的関係があるのだが、この話をしていると長くなるので、別に書くことにする)

そもそも、上に掲げた9つの要素のうち、プロジェクトの目標や制約になり得るのは、スコープ、コスト、スケジュール、品質の4つである。これらは、仕事のパフォーマンス指標と言っていい。人的資源は制約にはなり得るが、それ自体が目標になることはない。逆に、リスクとは基本的に、目標の反対概念であって、あまり歓迎されざる環境的要素である。そして、それ以外の、コミュニケーション、調達、ステークホルダーエンゲージメントなどは、目的と言うよりは手段に関することである。

ということで、上に掲げた9つの領域は、
(1) 主要な領域: スコープ、コスト、スケジュール
(2) それに準じる注意領域: 人的資源、品質、リスク
(3) 上記を支える補助的領域: コミュニケーション、調達、ステークホルダーエンゲージメント
という風に層別することができる。

これらは、互いにいろいろな形で関係し合っている。それを認識し、うまく調整・統合するのがインテグレーション・マネジメントだ、という訳である。主要とか補助的とか分類したが、補助的だからといってコミュニケーションとかステークホルダー・エンゲージメントをおろそかにすると、結局は品質やリスクを経由して、大事なお金と納期にはね返ってくる。

とくに、これらの要素間の関係性を意識しなければならないのは、計画作成段階である。プロジェクト・マネジメント計画書の策定において、間違った順序で進めると、とんでもない計画が生まれてしまう。

プロジェクトの計画立案において、まず真っ先に着手しなければならないのは、スコープ定義である。「スコープ」の制約とは、「役務範囲」のことだと、上で書いた。役務範囲とは契約用語だが、とにかく「やらなければいけない責任範囲」を意味する。言いかえると、プロジェクトを構成する必須の作業(Activity)の集合を指す。

といっても、契約書にリストがあって、「これこれのActivityを全部実行せよ」などという形で、制約が与えられることはない。普通、もっと大まかな形で、受発注者の間の責任範囲が指定されるだけだ。では、どうやって「こんな注文を出されたらスコープ外なので追加です」などと主張できるのか?

じつはスコープは2段構造になっている。まず、成果物のスコープ(プロダクト・スコープ)がある。これは、プロジェクトの成果物がどのような特性を持ったもので、およそどのような構成になっているかを示したものだ。契約書に規定されるのは、主にこちらである。たとえばPCのセットが成果物ならば、CPUとボードと筐体とモニタとキーボード、といったモノのスコープが列挙される。

この成果物スコープを、すべて算出するための作業(Activity)を拾い出す。その結果うまれるのがプロジェクト・スコープだ。つまり、プロジェクト・スコープとは、Activityの集合である。通常それは、階層的に構成され管理番号を付番されたWBS(Work Breakdown Structure)の形で表現される。WBSはスコープの表現形で、ベースラインとも呼ばれる。

そしてこのWBSが、その後の計画作業の主要なベースとなる。

まずは、WBSを構成するそれぞれのActivityを、誰が責任を持って遂行するかを考えなければならない。これは、かつて「WBSはプロジェクト組織を規定する」(https://brevis.exblog.jp/19096066/ 2012-10-24)に書いたとおりである。「誰が」といっても、別に個人の名前まで全て決める必要はない。計画段階では、職種と大まかな人数を考えればいい。それがプロジェクト・チームの組織図と役割となる。

そして、Activityに割り当てた人数と、その仕事に必要な作業量、そして一人あたりの生産性から、各activityの所要期間が推算できる。また、各Activityのアウトプットとインプットを明らかにすると、Activity間の依存関係(Aが終わらなければBが開始できない、など)が分かる。それをもとに、プロジェクト全体の中での、Activityのつながり(ロジック・ネットワーク)を作る。そうすると、クリティカル・パスが計算でき、プロジェクトの全体工期も見えてくる。これがスケジュール計画である。

かくして、動員する人数、各Activityの期間、それに付随する工数と、外部費用などをWBSの構造に従って積み上げることによって、プロジェクトの実行予算計画ができる。全体をまとめると、次のようなステップで、プロジェクト計画は立案されるのである。

まあ、より細かく言うと、コスト計画の後でリスク・アセスメントをやって対策を考え、それによってスケジュールやコスト計画の内容に戻って修正するとか、あるいは品質計画や調達計画も必要な場合が多いとか、いろいろある。だが、大筋で言うと、スコープ・組織・スケジュール・コストの4つの柱をおさえなければ、プロジェクトの計画を作ったとは言えない。
e0058447_23542395.jpg
逆に言うと、スケジュール計画が見えないまま、コスト推算や予算計画を立てても、意味が無い。また、プロジェクトの組織や人数が決まらぬ段階で、スケジュールは計画できない。そして、組織はWBSがなかったら決まらない。WBSはスコープ定義がなければ作れない。こういう順序でしか、計画立案はできないのだ。

ところが、現在のPMBOK Guideでは、なぜかこうしたプロジェクト計画立案の流れが、明確に書いていない。かわりに、プロジェクト・インテグレーション・マネジメントの章の説明によると、「プロジェクト・マネジメント計画書は、スコープ・スケジュール・コスト・品質・・等の「補助的マネジメント計画」とベースラインを、インプットにせよ、と書いてある。まるで、各領域の計画を独立に別々に作っておいて、最後にバインダーでまとめれば計画書ができあがる、といわんばかりだ。

もちろん、そんなおかしな事はない。こういう書き方になっているのは、「段階的詳細化」にしたがって、プロジェクト・マネジメント計画書を何度か作り直しブラッシュアップするはずだ、という考え方が背景にあるのだ。そして、コスト見積が、WBSのベースラインをインプットとする、といった依存関係も、確証を細かく見ていくと書いてある。だが、全体としては、9つの領域が平等に、並列に、そしてあまりお互いに関係なく成立するような印象を受ける書き方だ。これは、とてもミス・リーディングな説明ではないかと思う。

ちなみに念のため、2000年に発行された、古い「PMBOK Guide 第2版」を見直してみたら、なんのことはない。Project Integration Managementの章に、ちゃんと計画立案の流れ図が描いてあるではないか。
e0058447_23552464.jpg
作業の分割の仕方は、わたしの5ステップと多少違って、より詳細だが、大筋としての流れは似ている。というか、実務的にはこういう順序でやるしかないのだ。そして、こういう図がある方が、全体の関係がずっと分かりやすいと思うのだが。

PMBOK Guideがなぜ、こうした図をやめてしまったのか、正確な理由は知らない。ただ、9つの領域を独立に並列に扱ったのでは、プロジェクト・インテグレーション・マネジメントにならない、ということはもっと強調されるべきだと思う。

そして、このことは、むしろプロジェクトを発注する側の責任者に、ちゃんと理解してほしいと思うのだ。発注者が、あとから思いついたようにいろんな注文を出し、スコープを変更しておいて、しかしコストも品質も納期も「元のままでやってくれ」、と言ってくるケースを、しばしば目にしてきた。だが、そんなことはプロジェクト統合の原理から言って、不可能なのだ。プロジェクトの要素は互いに絡み合い、関係し合っているのであって、一つだけを勝手にかえることはできない。そういう基本的なことを、わたしは多くの発注者に理解しておいてほしいと思う。

わたしは機会があって、ときどきPMの教育研修を手伝うこともあるし、また自分が主査を務める研究部会などで他の業界のPMの方々と話すこともある。そうした中でしばしば痛感するのは、多くの受注側のプロマネの苦労が、発注者側のプロジェクトへの無理解に起因しているという事実である。とくにIT分野で、この傾向は強いのではないか。

発注者はもっと、プロジェクトの性質を理解してほしい。何か変更を要求するにしても、せめてリーズナブルな要望の形でだしてもらいたい・・こう感じているプロマネが、いかに多いことか。これは、とても残念なことである。そして、はっきりいってIT業界の損失でもあると思う。

プロジェクトは、9つもの要素が複雑に関係し合った、一種のシステムである。だから、システムズ・アプローチをもって扱わなければならない。こういう理解を、もっと多くのユーザ企業の情シス部門が知ってほしいと願うのである。






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

プロジェクト・インテグレーション・マネジメントと「鉄の三角形」

プロジェクト・マネジメントの世界で最も広く普及している標準書PMBOK GuideⓇには、ご存じの通り以下のような、10の知識エリアが規定されている。

・プロジェクト・インテグレーション (Project integration)
・スコープ (Scope)
・スケジュール (Schedule)
・コスト (Cost)
・品質 (Quality)
・人的資源 (Human resource)
・コミュニケーション (Communication)
・リスク (Risk)
・調達 (Procurement)
・ステークホルダー・エンゲージメント (Stakeholder engagement)

各知識エリアは、それぞれが”xx Management"と題されている。つまりQuality ManagementとかCost Managementといったたぐいだ。もっとも上記10個には多少の変遷があり、最初は9個だった。途中からステークホルダー・マネジメントが追加され、さらに最新版ではステークホルダー・エンゲージメント・マネジメントにかわった(ステークホルダーは外部の利害関係者なので、プロマネが直接はマネージできないためだろう)。またスケジュール・マネジメントの用語も、第5版まではタイム・マネジメントだった。

PMBOK Guideには、PMをプロフェッショナルな職域として確立しようとした、先達の叡智がつまっている。中でも一番偉かったのは、最初に「プロジェクト・インテグレーション・マネジメント」なる領域をおいたことだと思う(日本語版では「プロジェクト統合マネジメント」と訳されている)。プロジェクトという複雑な活動の集合を、一種のシステムとしてとらえ、そのIntegrityを保つ必要があるという問題意識から、この概念が生まれたのだろう。ちなみにIntegrityという英語には、全体性、統合性、整合性などのほかに、誠実さ・品位といった意味もあり、非常に高い価値が込められている。

ところで、プロジェクトのインテグレーション・マネジメントというのが何を指しているのか、ここが意外と分かりにくい。

PMOBK Guideはプロセス中心の記述になっていて、Project integrationの中には5つのプロセスが定義されている。(1)Project charterの作成、(2)プロジェクト・マネジメント計画書の作成、(3)プロジェクト作業の指揮・マネジメント、(4)プロジェクト作業の監視・コントロール、(5)統合変更管理、(6)プロジェクトやフェーズの終結、の6つである。

このうち、(1)と(2)は立ち上げフェーズと計画フェーズでの、いわば全体計画立案作業なので、明確だろう。遂行フェーズに入ると、プロジェクトのマネジメントとコントロールを行う。どちらもプロジェクトの全体が対象だ。

ただ、マネジメントとコントロールの二つが、別々のプロセスになっているのは、英語ではmanagementとcontrolがレベルの違う概念として、区別されるからだ(「わたしはなぜ、「プロジェクト管理」という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ 参照のこと)。実際、大規模プロジェクトでは、両者はプロジェクト・マネージャー(PM)とプロジェクト・コントロール・マネージャー(PCM)という風に、職種が分かれて分担する。もちろん、PMはPCMの上位職である。

さて、問題は『統合変更管理』(Integrated change control)である。日本語訳では「管理」となってるが、原語はContorlであることに注意してほしい。これはいったい何をするのか。

PMBOK Guideはプロセス中心、つまり手続き主義の記述になっている。そして「変更要求」だとか「承認済み変更要求」だとかが、インプット/アウトプットに出てくる。

米国流のプロジェクト遂行では、発注者と受注者の間で、変更要求Change Requestと変更指示Change Orderが、やりとりされる。通常は受注者から変更のリクエストが提出され、発注者がそれを審査・承認して正式なオーダーを切る。オーダーには変更作業の詳細と共に、追加費用や納期延長が記載されている。もちろん現実には、提出から承認までの間に、「これは高すぎるだろ」と値切られたり、「これは追加じゃないはずだ」と言われて押し問答したり、といった交渉がはさまるのだが、そういう商慣習のプロトコルを知らないと、ここら辺の記述は分かりにくい。

また、自社内で完結する自発型プロジェクトの場合も、予算権限を持っているプロマネと、社内のステークホルダとの間で、似たようなやりとりが行われる。だからPMBOK Guideでは「承認済み変更要求」という用語になっているのだろう。

ところで、どうしてこれに、あえて『統合』という修飾語がついているのか? 何かの事情で仕様の追加や変更等が必要になり、それで予算が増えるなら予算追加要求、納期が延びるなら納期変更要求、それだけの話ではないか。

ところが、そうではないのである。

プロジェクトを取り巻く制約条件には様々なものがありうるが、通常、その中でも
• Scope(役務範囲)
• Cost(予算)
• Schedule(納期)
Project の三大制約条件である。まあ、だからこそPMBOK Guideでは最初の方の章に、この3つのエリアがあげられている。

ところで、この三大要素を図にすると、三角形で表される。三角形は、知っての通り、他の2辺に影響を及ぼさずに1辺だけをかえることができない。どれか、ある要素を変更するには、他の要素の変更も必要になるのだ。
e0058447_15161741.jpg
たとえば、何か仕様上の追加が必要になったとしよう。その場合、作業(Activity)が増える訳だから、スコープの1辺が長くなる。この場合、
・期限(スケジュール)を延ばして作業を完了
・人員(コスト)を増やして作業を完了
のいずれかが必要になる、という具合だ。

図を見てほしい。三角形の底辺であるスコープを長くすると、どちらかの斜辺を同時に長くせざるを得ない。いや、しばしばあることだが、スケジュールとコストの両方が増大したりする。

似たようなケースとして、遅れつつあるプロジェクトで、納期を間に合わせる工夫が必要だとしよう。その場合、
・人員を追加して(=コスト追加)、仕事を完了する
・スコープを減らして、期限までの作業量を減らす
のいずれかの方策が必要になる。

あるいは、予算内(コスト)で終わらせる場合ならば、こうなる:
・残業などはせず、プロジェクトの納期を延長する
・スコープを減らして、コストを削減する

プロジェクトには、変更がつきものである。だが、その影響範囲や必要性を考える際には、コストならコストだけ、スケジュールならスケジュールだけでは、判断できない。プロマネは、上述のように、つねにスコープ・コスト・スケジュールの3辺を制約条件として意識しながら、変更をコントロールしなくてはならないのだ。だから、「統合」変更管理 Integrated change control と呼ばれるのである。

英国の初期のPM研究者マーティンは、1970年頃、Scope/Cost/Scheduleからなるこの三辺を、「鉄の三角形」と名付けた。鉄の三角形は、プロマネをとじこめる束縛、あるいは牢獄のようなものだ。プロマネは、とくにプロジェクトの中盤以降、つねにこの三角形の制約条件と戦い続ける。なにか予期せぬ事が起きても、なんとかしてこの三角形の内部で解決すべく努力する。どれか一辺でも破ると、三角形全体の形が変わってしまう。

プロジェクトの成功には、いろいろな定義が可能だが、一番短期的に測りやすいのは、「スコープ・コスト・納期が、当初の予定通り完遂できた」である。外部コンサルタントなども、よくこの指標を用いる。それはつまり、鉄の三角形の内部で完結できたか、を問うている訳だ。

そして、逆に言うと、プロジェクト・マネージャーが首尾良く仕事を完遂するためには、スコープ・コスト・スケジュールのいずれについても、判断し実行する権限を持たなければならない。プロマネは結果に責任を持て、とか、プロマネは結果が全てだ、といった標語をよく耳にする。だが、もしも組織がプロマネにそうした仕事ぶりを期待するなら、それなりの権限を与える必要がある。

「ウチの会社ではプロマネは進捗管理係でしかない」とか、「○○業界のプロマネは、コスト管理の権限がない。発注権は、その上の部課長級が握っている」といった話を、ときどき耳にすることがある。それなりの理由があって、そうした慣習ができあがっているのかも知れない。だが、3辺に対する権限もなしに、3辺の結果責任だけを問われるのは、フェアなマネジメントのやり方ではないと、わたしには思えるのである。


<関連エントリ>
「わたしはなぜ、『プロジェクト管理』という言葉を使わないのか」 https://brevis.exblog.jp/26270824/ (2017-12-18)

by Tomoichi_Sato | 2018-02-25 15:45 | プロジェクト・マネジメント | Comments(0)

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

各位:

プロジェクト&プログラム・アナリシス研究部会」の2018年第2回会合を開催いたします。

今回は、グローバルプロジェクトデザイン・ジャパン代表取締役の池大様に、プロジェクトデザインについてご講演いただきます。

企業が新しい製品をつくるにあたって、何の設計図も青写真も持たずに、いきなり実現に向けて走り出すことは稀でしょう。必ず最初にデザインという行為があるはずです。それでは、プロジェクトを開始する場合はどうでしょうか。たしかに今日、多くの組織では、WBS・スケジュール・予算等を含む「プロジェクト計画書」くらいは作ると思います。しかし、「適切なデザイン」という視点で、プロジェクトづくりに向かうケースは、まだ少ないのではないでしょうか。

デザインには、つねにサイエンスとアートの両方の要素があります。プロジェクト・マネジメントの分野でも「デザイン思考」が 注目を集めつつある今日、プロジェクトのデザインはいかなる行為であるべきか。この問題について、東大とMITのコラボレーションによる共同研究と研修プログラムのキーマンとなっている池様から、最新の潮流についてお話を伺います。ぜひご来聴ください。


<記>

■日時:2018年3月23日(金) 18:30~20:30

■場所:慶応大学三田キャンパス 北館会議室2(1階)(定員:28)
キャンパスマップ 【1】

■講演タイトル:
「多様化、不確定の時代に対応するプロジェクトデザイン」

■概要:
 現在の社会は、複雑化、多様化、不確定に向かっています。その中でプロジェクトは関係者の多様性を受け入れ、変化に柔軟に対応する必要があります。今回は、東京大学とMITのコンソーシアムであるグローバル・チームワーク・ラボも採用しているプロジェクトデザインと言う考え方についてご紹介します。

■講師:グローバルプロジェクトデザイン・ジャパン 代表取締役  池大(いけ・だい)

■講師略歴:
 前職はアクセンチュアでシステム運用保守方法論およびツールの日本国内の責任者を務める。25年以上IT業界に従事し、多くのプロジェクトにSEおよびコンサルタント、PMとして参加。
 リスクマネジメント協会会員 Certified Risk Manager

 参考Url:

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら当日までに三好副幹事までご連絡ください。

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

佐藤知一@日揮(株)

by Tomoichi_Sato | 2018-02-21 12:30 | プロジェクト・マネジメント | Comments(0)