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

「プロジェクト&プログラム・アナリシス研究部会」(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)

わたしはなぜ、「プロジェクト管理」という言葉を使わないのか

旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから(Miso soupとよばれる)、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。

汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる(eat)という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。

わたし達が言葉を翻訳をするときは、自国の文化にある似たものや、似た概念を対応づけている。だがスープと味噌汁に見るように、翻訳は近似でしかない。時には、けっこう違うことに注意が必要だ。

わたしは、このサイトでは原則として「管理」という言葉を使わないことにしている。拙著『世界を動かすプロジェクトマネジメントの教科書』でも書いたように、わたしのモットーの一つは、言葉を大切にする、である。だから、このサイト内では、二つの原則に従うことにしている。第一に、このサイト内では、用語はできるかぎり整合性・一貫性を持った使い方をする。第二に、そうはいっても、世間での使い方からあまりかけ離れないようにすること、の二つだ。

以前も書いたが、日本語の「管理」に対応する英単語は三つある。
  • マネジメント(management)
  • コントロール(control)
  • アドミニストレーション(administration)
なお日本語では、「管理・監督」と並べて使うことも多い。「監督」の英語は、supervision, superintendenceなどだ。

英語では、これらは別の概念である。これを全部、「管理」と一括りに呼んでしまうと、どれのことをいっているのか、分からなくなる。それでは、言葉を大切にしているとはいえない。

ちなみに英語の”manage"には、「荒馬を乗りこなす」といったような語感がある。自分の意思ではなかなか動かない相手を、なんとか自分の目的にあうよう、使いこなす感じだ。

これに対し、”control"は、自分の意思の通りに動く対象について行う、もっと精度の高い行為である。たとえば機械を制御する、自分の思った方向や速度に持って行く、というように。あるいは、個別にきちんとチェックし記録する、という風に。だから、品質管理はQuality controlだし、在庫管理はInventory control、原価管理はCost controである。空港における入国管理官の仕事はパスポート・コントロールであって、これを「パスポート・マネジメント」といったら変だ。入国窓口担当官が、個別の旅行客のパスポート発行に、すごく裁量を持っている感じになる。

そして"administration"は、執務環境を整えるとか、事務手続きをするイメージである。総務的・行政的・庶務的な仕事といってもいい。あるいは、銀行や役所などの窓口業務と言えるだろうか。よくsystem administration(略称シスアド)と呼ばれる仕事があるが、ユーザを登録削除したり記憶領域をバックアップしたりメンテナンスしたりというのが内容だ。ある米国人が”housekeeping type of work”といっていたが、とても感じが出ている。

では、「プロジェクト管理」とは、一体このうち、どれに相当するのか?

わたしの働く業界では、大規模なプロジェクトになると、プロマネ一人では面倒見切れなくなるため、プロマネをサポートするスタッフ達からなるPMT(Project Management Team)が必要になる。このPMTの中には、
  • Project Manager
  • Project Controller (Project Control Manager)
  • Project Administrator
という役職が、それぞれ存在する。

Project Manager(PM=プロマネ)はもちろん、プロジェクトの成果に対して最終的な判断を下し、その責任を負う人物である。これに対し、Project Control Manager(PCM)は、プロマネの立てた戦略を元に、プロジェクトの詳細な計画を立案し、WBS・スケジュール・予算配分などを決め、その計画通りに遂行が行われているかをチェックする。もしコストや進捗について、予実の差異が生じて問題だったら、是正策を考え、プロマネに進言する。つまりプロマネが将軍だとしたら、PCMは参謀役である。Project Adminは、それに比べて、プロジェクト・チームの配員や執務環境のケアをしたりする、まあ総務課長的な役割だ。

これらを全部、「プロジェクト管理」といってしまうと、どの職の仕事を指しているのかわからなくなってしまう。もちろん、小さな規模のプロジェクトでは、プロマネがControlもAdminの仕事も兼ねるし、もっと小規模なら設計などの実務も片手間でやるだろう。ただ、それはConrolやAdminの仕事の要素がなくなる、という意味ではない。

で、日本語の「管理」概念(あるいは語感)は、三つの英語を全て包含するかというと、そうではなくて、もう少し狭い。

たとえば、何か大事な物品をあずけて、「ちゃんと管理しておいてくれ」という場合、それはモノをちゃんと保管し、位置や状態を把握しておくことを意味する。つまり「管理」とは、誰かや何かを、自分の指示下に置いて、細かく動かすことである。言いかえれば、コントロール下におくイメージだ。

同じように、部下を管理する、とは、部下の一挙手一投足を指示し把握することを、通常、意味しがちだ。それは部下の自由度を奪うこと、ないし、上司の権力(強制力)を誇示することにも、通底している。こういう「管理」とは、上官の指示で突撃する兵卒に対して使う言葉のニュアンスをもっている。実際、少なからぬ組織では、軍隊式が「管理」の暗黙のモデルになっているようだ。

逆に、「管理」という言葉は、目上や対等な相手については、使わない。「ステークホルダー(たとえば顧客主や官庁)を管理しておけ」、とはあまり言うまい。この点、英語のManageとは違う(ご存じの通り、PMBOK Guide第5版からは、"Stakeholder Management"という章が付け加わった)。このように、日本語における管理概念は、とてもタテ社会的な序列感覚に裏打ちされている。したがって、『管理』という語に反発心を感じる人も、現場には多い。
e0058447_00064885.jpg
さらに言うと、日本語の「管理」は語義が広いとは言え、英語のManagementの全領域をカバーしきれていない。たとえば「マネジメント・サイクル」という概念がある。Plan-Do-Seeのサイクルを回すことである(PDCAのデミング・サイクルの方が日本の製造業ではポピュラーだが)。あるいは、計画・組織化・統率という、ファヨールのプロセスでもいい。

仕事をきちんと回すとは、このサイクルを動かすことと同じである。であるからには、
  • ろくな計画も立てずに行き当たりばったり獲物を追いかけたり
  • フォーメーションや役割分担も考えずに自分が真っ先に走り
  • 終わったことについて記録もとらずふりかえりの反省もしない
  • もちろん標準化も考えず、改善も変革もしない
…こんな「突撃型」上司を持った日には、下の人間はたまらない訳である。これではマネジメントをしているとは、言えない。なのに、マネジメントの仕事をきちんと教育せぬまま、『管理職」につけて、部下を管理する権力を与えてしまう組織を、しばしば見かける。

ちなみに、知的な職種でも、『管理』という言葉をカッコいい、と感じる人は多いらしい。昔、中小企業診断士の勉強をしていたとき、教科書や教科書に、管理・管理のオンパレードで驚いたことがある。経営基本管理・販売管理・仕入管理・財務管理・労務管理・生産管理・・あらゆる項目名に管理がついていた。それどころか、労務管理のテキストを読んでいたら、「労務管理の管理」という章があって、頭が痛くなった。なんだそれ? である。

その説明によると、労務管理という仕事について、計画→統率→評価のプロセスを回せ、と書いてある。これ、英語ならHuman resourceに関する仕事のManagement cycleを回せ、と表現するだろう。だが、この先生の頭の中では、「労務管理」とは労働者への指示命令のことだけを指すらしい。だから「労務管理」の管理、などという、屋上屋を架す用語が出てくるのだ。こういうのは管理中毒と言うべきだろう。

だが、もっとこまるのは、『管理過剰症候群』という病気だ。この病気にかかった人や組織は、何かうまくないことが起きると、「管理を強化しろ」という。業績が不振になったり、プロジェクトがうまくいかなかったりすると、上位職の管理者が、事細かにプロマネや現場に指示を出し、報告を要求する。そして、ありとあらゆる判断に、承認手続きを義務づけ、現場の裁量を奪う。事細かに目標値や制約条件を設定し、押しつける。これによって、現場の暴走を止め、プロマネの無能力を補正するつもりなのだ。だが、結果としてプロマネは報告義務に追われ、落ち着いて考える時間を持てなくなりがちだ。

たいていの場合、トラブルに陥ったプロマネに対して必要なのは管理ではなく、支援であろう。プロマネの悩みとは、いつも相場が決まっている。それは、お金がないか、人が足りない、なのだ。だが部門の壁や、プロジェクト独立採算制の制約にはばまれて、こまっている。だから、会社の側は、そこをどうにかしてやる必要があるのではないか。仮にもし、それでもプロマネが無能力だったなら、それはそもそも、任命した側に責任があることになる。

マネジメントとは、適切な裁量を持たないとできないことを、管理過剰症候群の人達は忘れている。裁量とはすなわち、(わたしの好きな用語で言うと)『自由度』だ。いいかえると、自分で決められる、ということ、自分が自分自身の主人であることである。これが自由の意味だ。

適切な自由度を与えることで、はじめて現場の様々な環境変化に、自在に適応できるようになる。日本語の「管理」には、あいにく、この「適切な自由度」の感覚が足りない。だが、自由度を与えないと、現場の者に責任感が生まれない。責任感のある仕事をしてもらいたかったら、「管理」するだけでは不十分である。そうでなければ、どうして創意などというものが生まれるだろうか。

名著「自由を子どもに」 を書いた小児科医の松田道雄は、次のような意味のことを述べている。保育や教育という仕事は、いつの間にか、子どもの「管理」になってしまっている。子どもたちに問題が生じると、もっと管理を強化しろと、親も社会もいう。それほどまでに、今の大人は管理に自信を持っているのだ。だが、そのこと自体が、まさに子ども達を不幸にしているのに気がつかないのだ、と。

松田道雄がこの本を書いたのは、今から44年前の1973年だった。わたし達はそれ以来、少しは進歩しているのだろうか。もし仕事に責任感と創意を求めたかったら、まず「管理」を見直すことから、はじめるべきではないだろうか?


<関連エントリ>
 →「マネジメントと管理はどこが違うか」 http://brevis.exblog.jp/10625203/(2009-07-15)

by Tomoichi_Sato | 2017-12-18 06:04 | プロジェクト・マネジメント | Comments(0)

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

各位:

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

新年第1回は、久しぶりに製品開発、とくに研究開発におけるプロジェクト・マネジメントについて、キユーピー(株)の元常務取締役・研究所長であった和田義明様に、ご講演いただきます。

ご承知の通り、企業におけるイノベーションの創出活動、とくに研究という仕事は、まだ誰も知らないものを生み出すことにあります。他方、マネジメントとは計画を立て、明確な目標イメージを持って統率していく行為です。誰も知らない目標に向かって、一体どのように組織をマネージすべきなのか? ここに研究開発マネジメントの本質的な難しさがあります。

今回は、実際の研究開発の実務を長年リードしてこられ、さらに研究開発の方法について博士号を取られた和田様から、R&Dのマネジメントについて実戦的なお話を伺う予定です。ぜひご来聴ください。


<記>

■日時:2018年1月25日(木) 18:30~20:30

■場所:三田キャンパス 研究室棟B会議室(1F)
 ※キャンパスマップの【10】
 (いつもの北館とは別の場所ですので、ご注意ください)

■講演タイトル:
企業における研究開発の活性化策(プラットフォームとブーストゲート法)

■概要:
 研究開発を活性化してイノベーションにつなげることを目的に、キユーピー㈱研究所にて取り組んだ手法を紹介する。具体的には、組織力を高めるプラットフォーム・マネジメントと、研究を事業につなげるブーストゲート法である。その方法、効果、事例について紹介する。

■講師:キユーピー㈱ アドバイザー 和田 義明

■講師略歴:
【学歴】
 1978年 東京農工大学農学部農芸化学科卒業
 2012年 東京農工大学専門職大学院技術経営研究科修了
 2014年 東京農工大学大学院工学府応用化学専攻博士後期課程修了
    博士(学術)
【職歴】
 1978年 キユーピー㈱入社(以後工場、研究所、マーケティング部門勤務)
 2000年 同社研究所部長
 2006年 同社執行役員品質保証本部長
 2009年 同社取締役研究所長
 2012年 同社常務取締役(ファインケミカル事業、研究開発本部、品質保証本部、商品開発本部、知的財産室管掌)
 2017年 同社取締役退任
【現在役職】
 キユーピー㈱アドバイザー
 上海海洋大学客員教授
 中央大学、関西大学、千葉工業大学非常勤講師
 東洋食品工業短期大学非常勤講師兼テクニカルアドバイザー
 国際プロジェクト・プログラム・マネジメント学会評議員
 タマゴ科学研究会理事、日本能率協会食品安全部判定委員

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

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

佐藤知一@日揮(株)

by Tomoichi_Sato | 2017-12-15 00:48 | プロジェクト・マネジメント | Comments(0)

プロジェクト計画のロジックとは何か 〜 やはりExcelで工程表を書いてはいけない (2)

前回の記事「ダイレクト・ガントチャート方式の問題点」http://brevis.exblog.jp/26231556/ で、世間ではそもそも「WBS」とか「Activity」という概念のレベルで、誤解や混乱があると書いた。

たとえば、WBS=「ガントチャートの線表に引いた線の集合」だ、と理解している人達を、よく見かける。ためしにネットで、「WBS スケジュール」の2キーワードで検索をかけてみると、よくわかる。上位の検索結果に、こういう説明が出てきたりする:

「WBSとはプロジェクトのスケジュール管理に使われるツールの1つ。作業工程を分解して示したものと、それをスケジュールにしたものを合わせてWBSと呼ぶことが多い」

この説明など、残念ながら逆立ちしている。WBSはスケジュール管理用のツールでもないし、もちろんガントチャートの線も含まない。WBS(Work Breakdown Structure)とは、プロジェクトのスコープを階層的に分解したものを指す。スコープを単位作業の集合として構成し管理番号を付番したもので、つまりスコープ管理用のツールなのだ。まずWBS作成が先にあって、最後にガントチャートや予算表ができる訳なのだから、逆立ちなのである。(なお、たまたまGoogle検索で上位にヒットしたので、上記サイトをやり玉にあげさせていただいたが、全体としては平易で良い記事が多いと思う。だからこそ、こうした誤解が残念なのだ)

ついでにいうと、タスクとアクティビティという用語も、しばしば混乱して使われているようだ。プロジェクトのWBSを構成する要素作業は、「タスク」とよぶのか、「アクティビティ」とよぶべきなのか?

世界で最も広く普及しているPM分野の標準書「PMBOK Guide」では、一貫して、プロジェクトの要素作業を”Activity"とよんでいる。これが、世界的な共通語である。ただ、わたしの知る限り、日本のIT業界では、プロジェクトの下位要素を「タスク」とよぶ人が非常に多い。まあ、一種の業界慣習(?)なのだろうか。むろん習慣に従うのは自由だが、外の人と話すときには、自分たちが方言を使っていることを意識しておいた方が良い。

ちなみにPMBOK Guideでは、タスクという用語は、"Daily task”の形で出てくる。日々の細かな宿題、課業である。すなわちTaskとは、To Doリストとか課題管理表で追いかけるべき、細かな作業を指す。

しかし、Activityは違う。これはプロジェクトを構成する単位作業で、ある意味、プロジェクトの縮小版であり似姿だ。Activityは、通常、完了条件を持つ。つまり、アウトプットとしての成果物がある。あるいは、ある状態になったら完了していい、との条件がある。

たとえば、要件定義というActivityは、『要件定義書』という成果物を生み出したら完了する。あるいは、テストだったら、試験完了の状態になれば終わる(まあ普通はテスト報告書も作成するけれど)。つまりActivityというのは、プロジェクトと同じく一過性の仕事なのである。じゃあ、週次ミーティングは何なのか? WBSには入れないのか? との疑問が浮かぶかもしれない。それはDaily taskです、というのが答えだ。

Activityには、必要なインプットがある。インプットは、部品・材料といったモノの場合もあるし、情報の場合もある。さらにActivityには、それを遂行するためのリソース(経営資源)も割り当てなければならない。つまり担当者であり、機械やツールであり、作業場所である。こうしたものは作業中は占有するが、終われば開放されて、別の仕事に使える。リソースは、Activityで消費されてしまうインプットとは性質が異なる。

そして、各Activityはその内容・種類に応じて、作業量(BoQ=Bill of Quantity)を推算しなければならない。これがコストやスケジュールのベースとなるからだ。

プロジェクトのWBSを構成する全Activityについて、そのインプット、アウトプット(完了条件)、リソース、そして作業量(BoQ)をまとめた表を、Activitlyリストとか、WBS Dictionaryとよぶ。たとえていうならば、WBSとは、日本全国を50都道府県に分解し、さらに各県を市町村に分割し、マネジメントしやすい自治体の単位に表示した、お仕事の地図のようなものである。この地図帳には、WBS Dictionaryという統計表がついている。これが、プロジェクト・マネジメント計画の土台なのだ。単なるスケジュール管理用のツールではないことが、お分かりいただけたと思う。

さて、「ダイレクト・ガントチャート方式」の問題点に話を戻そう。いうまでもなく、ガントチャートは、チームメンバーや顧客・外部協力会社とのコミュニケーション上、必須の道具である。PERT/CPMの計算に使うActivity Network線図など、誰も見たくないだろうし、見てもよく分かるまい。わたしの勤務先でも、PERT/CPMの計算の後、必ずガントチャートを作成して、プロジェクト・チームに配布する。それを元に、キーパーソン同士による「総合工程会議」を開いてレビュー・議論し、完成するやり方をとっている。

だが、頭の中にWBSもActivityリストもないまま、いきなりガントチャートの線表を書き始める「ダイレクト・ガントチャート」方式は、全然別物だ。アウトプットとしての線表は共通だが、背後にきちんとしたスケジューリングのロジックがないため、これをスケジュール管理用に使うのは、けっこう危険である。まあ「ロジック・ガントチャート」方式と「ダイレクト・ガントチャート」方式は、アウトプットの線表だけ見ると似ているので、両者の違いを知らない人が多いのかもしれない。

では、プロジェクトのロジックとは何か?

狭義には、Activity間の依存関係やスケジュール上の制約条件を示したものを指す。たとえば、あるActivityのアウトプットが、他のActivityのインプットやリソースになる場合、両者の間に先行→後続という、依存関係が生じる(Finish to Startの略でFS関係とよぶ)。あるいは、ペンキ塗装のように、あるActivityが開始してから一定日数後に、別のActivityを開始できることがある。これをStart to Startの依存関係とよぶ(略してSS)。

こうしたロジックは、Activity Networkを組むベースとなるだけではない。あるActivityが予定から変化(遅れた・早く完了した)場合に、他のActivityにどう影響するかの予測を、可能にする。

なお、スケジュール・ロジックは広い意味では、Activityの所要期間の推定根拠(何で決まるか)も含む。つまり、作業量(BoQ)と、投入リソース量と、生産性である。所要期間は、以下の式で計算する。

所要期間=作業量÷(生産性×投入リソース量)

リソースが人間の場合は、所要期間=作業量÷(生産性×人数) になる。作業量は、ソフトウェア開発の場合なら、たとえばFunction Point(FP)だとか画面帳票数だとかLOC(コード行数)などのパラメータで測ることが多い。

かくして、WBSを構成する各Activityについて、作業量(BoQ)と投入リソース量と生産性から、所要期間が決まる。もっとも中には外部調達機器の納期のように、外から与えられる所要期間も無論ある。

そして、ロジックを元にActivity Networkを組んで、はじめてクリティカル・パスがわかり、プロジェクト全体工期が計算できるのである。全体工期がわかって、はじめてプロマネの工数を積むことができる。だから、計画立案は必ず、スコープ→WBS作成→スケジュール計画→コスト見積の順番になる。

ところが、ダイレクト・ガントチャート方式は、途中を中抜きして、いきなりスコープからガントチャートを作ってしまう。家を建てるのに、土台や柱の骨組み抜きで、壁を立て屋根を乗せているようなものだ。途中で倒れなかったら、まあ幸運である。

e0058447_23224980.jpg
e0058447_23231505.jpg
ダイレクト・ガントチャート方式をとる人には、しばしばもう一つの問題がつきまとう。それは、ガントチャート上に、フロートを表示しないことである。フロートとは、そのアクティビティがどれだけ遅れると、プロジェクト全体の納期に影響を与え始めるかを表す数値だ。無論、クリティカル・パス上のアクティビティのフロート日数はゼロである。

たとえば4月開始で、実質の所要期間は3ヶ月のActivityがあるとしよう。ただし、並行する別の作業があるために、8月末までに完成すればいい。このとき、本来ならば3ヶ月間の実線と、2ヶ月分の余裕日数(フロート)を表す点線を、横に並べて引くべきだ。

だが4月から8月末まで、5ヶ月分、バーの実線を引いてしまうケースが多いのである。ロジックをよく理解していない人は、フロートの概念があいまいだからだ。こうすると、そのActivityの正味の所要期間が見えなくなってしまう。

こういう線をあちこち引いたガントチャートを見て、さて、プロジェクトの最長の経路(見かけ上の最長経路)をクリティカル・パスだと判断したら、当然おかしなことになる。クリティカル・パスとは、フロートを差し引いた正味の経路長が最大のものを指す。プロジェクトの全体工期を制約する最長の経路である。プロマネは、納期を守るために、クリティカル・パスが遅れないよう、注意を集中すべきだ。だが、フロートが見えないと、間違ったAcitivityに注意を向けたりしかねない。

ちなみに、プロジェクト・マネジメントという特殊なActivityについても、注意を向けておきたい。これをWBSにいれていない大企業を、見かけたことがある。思わず、「プロジェクト・マネジメントはしないんですか」、と口走ってしまった(苦笑)。もちろん、プロジェクト・マネジメントには確実に工数がかかるので、見積に必要である。プロマネだけでなく、書類事務などが多い場合は、アシスタントもつける必要もある。だからWBSに無いのはおかしい。

ただしプロジェクト・マネジメントというActivityは、固有の成果物と、固有の所要時間を持たない点が特殊だ。その期間は、プロジェクトのクリティカル・パスの長さに依存する。
だからガントチャートでは、省略されることも多い。うっかり線を引くと、それがクリティカル・パスみたいに見えてしまう。だが、WBSの一部である。このように、WBSとガントチャートは、一致しない点がある。

以上、ダイレクト・ガントチャート方式を批判してきたが、じつはわたし自身、直接ガントチャートを引くことがある。それは、身近で数人が関わる程度で、期間も数週間程度のごく小規模なプロジェクト的業務の場合である。役割分担を決め、やる事とタイミングを決めたら、あとは走りながら考える。必要に応じて、微調整していく。その程度で十分な仕事が、確かにある。え? 線表は何で引くかって? もちろんExcelでだ(笑)

無論、きちんとWBSを作りプロジェクト計画を立てるべき仕事もある。当たり前だが、規模によって、マネジメントのやり方は変えなければならない。3人のお客様を呼ぶパーティーと、300人のお客様を呼ぶパーティーでは、段取りから何から全て違うのだ。あるいは、先ほどの家を建てるアナロジーでいうと、犬小屋なら地面にすぐ壁を立て屋根を乗せても大丈夫だ。だが普通の木造家屋では、そうはいかない。そして10階建てのビルなったら、そもそも材料も構造も変える必要がある。

つまり、規模とマネジメント手法の相関が大事なのである。少しでも複雑化した仕事、規模の大きなプロジェクトでは、それに見合うやり方を選ばなければならない。なぜなら、小さなスケールの仕事で「分かっている」と思ったやり方が、通用しなくなるからだ。本格的なやり方を知った上で、小さな場合には適時省略する、のは構わない。だが、本式のやり方を知らないのでは危うい。

現在のPMBOK GuideやPMP試験の問題点は、ここにある。プロジェクトの規模や複雑性によって、適切なマネジメントのやり方を選ぶべきだ、という事をハイライトしていない。たとえ規模は変わらなくても、海外プロジェクトは、パートナーやステークホルダーと契約関係が、複雑性を増大させる。なのに国内と同じ簡略化した進め方が通用すると思ってはいけない。規模が大きくなったり、プロジェクト構造が複雑化したら、より精度の高いプロジェクト計画が必要なのだ。

ちなみに、上に挙げた図の中で、点線で囲まれた部分は、わたしの主催するプロジェクト&プログラム・アナリシス研究部会が開発中の、初級者向け研修コースのカバー範囲である。わたし達の研修プログラムの最大の特徴、他との違いは、PMにおける「システムズ・アプローチ」の涵養にある。受講者には最初に手を動かして、ロジック・ネットワークを作成してもらう。それを通じて、「プロジェクトとはActivityからなるシステムであり、そこには独特のロジックと動力学がある」という感覚を得てもらうことがポイントだ。ここが身につかないと、どこを簡略化すべきか、分からない。

Excelで工程表を書くべきではない、というのは、こうしたロジックが磨かれないからだ。それは、本当はツールの問題ではない。MS ProjectでもPrimaveraでも、やろうと思えば「ダイレクト・ガントチャート方式」は可能だ。まずいのは、ツールではない。ツールを使う条件、使える範囲を知らずに、いつでも使うことだ。

知らないことは、別に恥ではない。知ろうとしないことが、恥なのである。


<関連エントリ>
→「ダイレクト・ガントチャート方式の問題点」http://brevis.exblog.jp/26231556/ (2017-12-02)
→「仕事の最小単位ーーアクティビティの構造を学ぶ」 http://brevis.exblog.jp/13992804/ (2011-01-16)



by Tomoichi_Sato | 2017-12-10 06:21 | プロジェクト・マネジメント | Comments(4)

ダイレクト・ガントチャート方式の問題点 〜 やはりExcelで工程表を書いてはいけない (1)

このほど、自分で「マイ・ベスト・セレクション」なる本を編んでみた。過去17年間に書いてサイトに公開した数百の記事の中から、自分が気に入っているベスト12を選んで、ePub形式の電子書籍をつくってみたのだ。まあ書籍といっても、素人のつくった手製(手編み?)の本で、いってみればβバージョンではある。ベスト・セレクションの中には、アクセス数の多かった記事も入れたが、目立たないけど愛着のある記事も選んだ。多少は文章に手を入れたつつも、なるべく発表当時のスタイルを残している。

ところで、わたしのサイトには、アクセス数で言うとダントツ1位の記事がある。「Excelで工程表を書いてはいけない」(http://brevis.exblog.jp/9052344/)という、2008年11月24日の記事だ。もう9年前の記事だが、いまだに毎週のBlog記事ランキングのトップに位置し続けている。

そして、実を言うと、これほど評判のわるい記事もない。それは、コメント欄を見ていただければ分かる。当サイトのコメント欄は、明らかに広告宣伝と分かるもの以外は原則、消さないことにしている。コメントの8割以上が、まあ、ぼろくそな批判である。

批判の主旨は、「お前はExcelを批判しているが、かわりの提案をしていない」というものが多い。たしかにその通りで、これは批判者の方が正しい。「Excelのかわりにこのツールを使えば大丈夫だよ」というソリューションを書いていないから、記事の前半で提起した問題意識が、後半で腰砕けになっている、という風に読める。かわりにわたしは、「自分で考えましょう」みたいな書き方をしているからだ。

しかし、そんなに程度の低い記事だったら、なぜあっという間に忘れられてしまわなかったのか。なぜいまだに、毎日かなりの数の閲覧があるのか。そして、なぜ皆、Excelのかわりを求めて読みに来て、回答が書かれていない、と怒って帰って行くのか? −−もちろん、Excelで描く工程表が、やはり不便だからだ。

では、わたし自身は、実際の仕事では何を使っているか。

わたしは現在、経営企画部門におり、プロジェクトのライン部門は5年前に離れている。ライン部門にいた時は、じつはPrimavera Project Planner(略称P6)をつかっていた。Primavera P6は、いわゆる大規模なエンジニアリング系プロジェクトでは、ほとんど国際的な標準ツールになっている。

今でもわたしは、ちょっと込み入ったプロジェクトのスケジュールを考えるときは、Primaveraを使いたくなる。それだけ便利だからだ。

ただし、これはプロのツールである。

プロとは、"Project Control Manager”とか"Schedule Engineer"とか呼ばれる職種・ポジションの人達を指す。そもそもこういう職種自体、多くの業種には馴染みがないと思う。大規模プロジェクトをつねに遂行している組織でなければ、こういう専門職種は必要ないからだ。ちなみにプロジェクト・マネジメントはゼネラリストの仕事だと思っている人が多いが、じつは、スケジュール、コスト、品質、ドキュメントなどの要素別に専門分化している、プロマネのためのスタッフ職種があるのだ。米国PMIには資格試験まである。

それはともかく、Primaveraというソフトウェアは、きちんとトレーニングを受けなければ、使えないし、使っても意味がない(出力の意味が読み取れない)。値段は1本約30万円。まあ、プロの道具としては安いとわたしは思う。

参考までに、Primaveraの画面の一つ(典型的なガントチャート表示と、各Activityの属性を示すサブペイン)のスナップショットをつけておく。Primaveraでは、Activityには自由にカテゴリーと属性を定義でき、その順にソートしたりフィルタリングしたりできるようになっている。もちろん、リソース負荷山積みによるヒストグラム表示なども、よく用いる。
e0058447_09063235.png
では、それほど大きくない、もっと日常的なプロジェクトを組む場合、わたしは何を使うか? −−じつは、Excelで工程表を書くことが多い。

なんだBlog記事の主張と矛盾してるじゃないか! とお怒りの読者もいるかもしれない。いや、だが元の記事を、よく読んでほしい。別にわたしは、ガントチャートを画くのにExcelを使うこと自体がわるい、といっているわけではない。「Excelで工程管理してはいけない」と書いているのだ。

『工程管理する』とはどういう意味か。それはもちろん、工程(日程とかスケジュールと読み替えても良いが)の計画とコントロールである。

  • プロジェクトのスタートにあたり、工程表(ガントチャート)を作成し、定期的にアップデートすること
  • 進捗上の問題を検知し、対策を立てて問題解決をすること
  • それによって、プロジェクトの最終納期を目標通り収まるようコントロールすること、そして
  • 社内・社外の関係者に、先々の予定を立て準備できるようにすること

これが工程管理だ。そして、こういうひとまとまりの仕事を、Excelの絵1枚だけで済まそうとすると、相当に苦労するよ、と申し上げているのである。

2008年に書いた問題のサイト記事では、Excel工程管理について、とくに実行段階に入ってからのトラッキングとアップデートが大変だと書いた。しかし、もう一つの問題があることに、最近気がついた。それが、「ダイレクト・ガントチャート方式」である。

3ヶ月ほど前のことになるが、研究会仲間のY氏からメールをもらった。Y氏は、問題プロジェクトの火消しのために、海外に駐在されているところだった。この時期、わたしは「プロジェクト&プログラム・アナリシス研究部会」の仲間とともに、新しいPM教育のプログラムを作成していた。それに際して、Y氏がコメントを送ってくれたのである。

わたしたちのつくった研修カリキュラムでは、最初にプロジェクトのWBS構成と、アクティビティを表すカード数十枚を、受講者に配る。受講者はグループを組んで、各アクティビティのインプットとアウトプットを見ながら、アクティビティ間の順序関係(ロジック)を理解する。そして、アクティビティ・カードを模造紙の上に並べて、ロジック・ネットワークを作成する。ここは手作業で、ワイワイ言いながら、結構時間のかかる部分だ。その上で、PERT/CPMの計算をして、余裕日数(フロート)=0となるクリティカル・パスを見つけ、納期を予測する、という段取りになっている。

コンピュータソフトを使わず、あえて紙の手作業、それもグループ単位の演習にしたのは、言葉にして話し合う方が、より頭に残りやすいからである。

そしてこの演習では、プロジェクト計画立案の本来のプロセス(の一部)を、順を追って理解してもらうことに主眼がある。本来のプロセスとは、

(1) スコープ定義
(2) WBSの作成
(3) Activityリスト(WBS辞書)作成 →アウトプット(成果物)とインプットの定義
(4) ロジック・ネットワーク作成
(5) クリティカル・パス法(PERT/CPM)計算
(6) スケジュールの決定
(7) コスト見積

という流れである。このプロセスをきちんとやるのは面倒で、時間がかかるが、計画の精度が高まり、うっかりした見落としがなくなる。

ところで、Y氏はメールの中で、しばしば現実には「ダイレクト・ガントチャート方式」が行われている、と指摘された。ダイレクト・ガントチャート方式とは、プロマネがプロジェクト計画をつくる際に、WBSやアクティビティ・ネットワークを作成せず、いきなりスケジュール・ガントチャートを描き始めるやり方である。

「プロマネのハンドリングでさばける範囲であれば、Activity Networkを作成するより、ダイレクトにガントチャートを作成する方が負担にならない」とY氏は指摘する。しかし、「その範疇を超えた、(より規模の大きな)プロジェクトに対して、Activity Networkとクリティカルパスの概念を理解していないプロマネが、ガントチャートでマネジメントしようとすると、失敗プロジェクトに陥る。」−−これがY氏の経験から見た観察であった。

ちなみにY氏は、「ソフトウェア業界ではActivity Networkを作っていないケースが非常に多い」とも書いている。これは、そうだろうと感じた。いや、わたしの見るところでは、その前にそもそも、「WBS」とか「Activity」という概念のレベルで、誤解や混乱があるのである。

(この項続く)


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