来る2月20日(木)に、2020年の「プロジェクト&プログラム・アナリシス研究部会」第1回会合を開催します。今回は、PM教育のためのゲームを開発された、日立ドキュメントソリューションズの岡田様にご講演いただきます。プロジェクト・マネージャーの人材不足にはどこも頭を痛めており、優れたプロマネの育成研修は焦眉の急です。プロマネに必要とされる知識とスキルの幅はけっこう広く、身に付けるのは簡単ではありません。当研究部会でも3年ほど前から「PM教育分科会」を組織して、独自の研修カリキュラムを開発してきました。限られた時間内に、PMのソフトスキルとハードスキルの両面を伝えるのは、至難の技です。日立さんのアプローチのユニークな点は、モノポリー的なカードゲームを元に、主にソフトスキルにフォーカスした問題解決力の教育を組み込まれた点です。教育における「ゲーミフィケーション」の効果は、最近つとに指摘されていますが、短時間に集中して考える取組みとして興味深いものです。ファシリテーターによる丁寧な指導も、実践的な価値を高める工夫のようです。プロマネの育成について悩んでいる多くの方に、役立つ内容になると期待しております。開催日の直前のご案内になってしまい恐縮ですが、ぜひご来聴ください。■概要:プロジェクトの現場において、プロジェクトマネージャは発生する問題やリスクに対して限られたリソースの中でその都度適切な意思決定を行うスキルが求められる。これらのスキルは実践訓練などを通して習得できるものであるが、習得には多くの体験を経る必要があり時間を要す。そこで、ゲームを通してチームでプロジェクトを模擬体験する実践訓練手法を開発した。ここで得られるスキルは、プロジェクトマネジメント分野に限らず、ビジネス全般に必要なソフトスキルであると考える。講演では、プロジェクトマネジメント分野以外への展開可能性や、ゲーム中の振る舞いによるプロジェクトマネージャの特性評価の取り組み、ゲームの臨場感向上のためのデジタル化/ゲーム空間の開発に関する取り組みを紹介する。建設管理、および建設管理システムの運用・高度化業務を経て、2014年より日立ドキュメントソリューションズへ移り、プロジェクトマネジメント支援業務の取り纏めに従事。ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。以上、よろしくお願いいたします。問題より仕事の進捗(しんちょく=進み具合)を何で測り、どう数値化するか。これはいつも悩ましい問題である。「プラント・エンジニアリング会社のように、物理的に目に見えるモノを作っている分野は、数量が測りやすいからいい。ソフトのように目に見えない成果物を作る仕事は、進捗管理がとても難しい。・・こういう意味のことを、IT業界の方から何度か言われたこともある。いえいえ、どういたしまして。プラント・エンジニアリングのプロジェクトでは、設計業務だけで18ヶ月〜24ヶ月もかかる。この間、膨大な図面や仕様書が生成されるが、プラント予定地では1年後にやっと、基礎工事のための穴掘りが始まる程度だ。設計作業の進捗をどう捉えるかは、同じように悩ましい。具体的なものづくりに携わっている企業だって、進捗をタイムリーに正確につかむのは難しい。同時並行に進む作業が多いし、その負荷の大小だって、様々だからだ。「プロジェクトマネージャ」という種目がある。IPAの試験制度の中でも、いわゆる「高度」に分類される資格の一つだ(一応、わたしも持っている)。10本のプログラムからなるシステムを完成させるプロジェクトがある。1本のプログラムを完成させるには1人月の工数がかかると見積もられた。各プログラムの開発作業は、設計(20%)→コーディング(50%)→テスト(30%)のプロセスからなると推定された。現時点での進捗率を求めよ・・という問題である。このシステム、ほぼまったく同一規模のサブシステム・プログラム10本からなっていて、なおかつ、その間のインタフェースも結合テストもいらないらしい。ありそうにない、不自然なシステムだが、まあ試験問題だから文句を言っても仕方がない。10個のタスク(アクティビティ)があり、それぞれが設計・コーディング・テストの3段階からなるから、全部で30個のサブタスク(サブ・アクティビティ)から構成されたプロジェクトだ、ということになる。進捗率を問われている訳だから、なにか基準となるモノサシが必要だ。全部で10本のプログラムを作らねばならない。15日たった現時点で、できあがったのは3本だけだ。これはこれで、シンプルで分かりやすい尺度である。これをかりに『完成数基準』と呼ぶことにしよう。ところで、別の考え方もありうる。プログラムが完成まで至っていなくても、設計やコーディングがそれぞれ終わっているのなら、一定の進捗があったと言えるはずだ。その進捗率は、どう測るのか。それは、工数によるウェイトがいいと思う。15日たった現時点で、設計は10本とも完了している。設計の工数はそれぞれ0.2人月と見積もられている。コーディングは6本完了だ。1本あたり0.5人月だから、3人月分の仕事が終わっている。これは3本×0.3人月で、0.9人月分。合計、5.9人月分の仕事までは進んだ訳だ。この考え方を、『見積基準』と呼ぼう。いやいや、よく考えてみよう。工数の見積なんて、いつでも大した精度がなく、あてにならないものだ。ウェイトをつけるなら、実際に掛かった工数を重みにすべきではないか。表によれば、設計には合計2.5人月、コーディングには4.0人月かかり、テストにも1.5人月使っている。するならば、進捗率=70%が妥当ではないか。この考えを、『実績基準』と呼ぶことにする。(実績基準)さて、あなたなら、どれを選ぶだろうか?上の3つの計算例でも分かる通り、進捗には、さまざまな定義が可能である。決め事の問題であって、その点で原価管理にも似ている。原価にも、様々な計算手法がありえる。その中から、どれを選ぶかは、企業のマネジメント方針次第なのである。『進捗率』を数字で計算する以上、合理的かつ整合的な算定方法として、皆が合意できることが条件になる。50だから、あと50日かかる計算になる。このプロジェクトは、あと35日必要だと言えるだろうか?進捗管理の目的は、きれいな進捗レポートを作ることではない。進捗率を測る最大の目的は、完了日を予測するためにある。完成数基準は分かりやすく単純だが、この目的のために有用だろうか?考えてみてほしい。横軸にプロジェクト開始からの日数を取り、縦軸に進捗率をとって、グラフにプロットするとする。このプロジェクトが理想的に進めば(=つまり、各プログラムが予定通り並列に開発されると)、29日目までは完成数=ゼロである。30日目に、10本のプログラムが全部、同時に完成する。進捗率のグラフは、ずっと0%のまま29日目までx軸にはりついていて、30日目にいきなり100%になる。理想的にプロジェクトが進むと、完了時点が予測できなくなるような基準は、役に立つだろうか。逆に、実績基準の計算:7.0/10=70%は、どうか?いま仮に、現在までにトータルで9人月かかったとすると、90%進捗、ということになる。これは明らかに不合理である。予算消化率で進捗率は測れない。これまで、どれだけ頑張ったか、どれだけ工数や予算を使ったか、で進捗を測ってはいけないのだ。この点はよく覚えておいてほしい。世間の人は、ここを誤解しているケースが非常に多いからだ。進捗率は、今までどれだけ頑張ったか、ではなく、あとどれくらい仕事が残っているかで測るべきなのだ。あとどれくらい仕事が残っているのか。それは、未完了の仕事(コーディング4本とテスト7本分)を見る必要がある。4.1人月だと見積もられている。全体が10人月分の仕事量だったのだから、41%残っている。したがって、見積基準の計算:5.9/10=59%が正解らしい、とわかる。実を言うと、この当時、経産省主導の資格試験は、正解を公表していなかった(もっと後には公表するようになったが)。上に述べたのは、あくまでも佐藤の推測した回答である。これが正解だろうと思う。System)の標準的な手法だからだ。EVMSは、モダンPMの技法の三本柱の一つだ。EVMSでは、進捗率を次のような方法で定義する。出来高をProject全体の価値で割ったものを進捗率と定義するこの問題では、完了したサブ・アクティビティの価値(見積もられた工数)の合計は5.9人月だった。59%になるのである。いいかえると、EVMSの進捗率計算は、見積基準なのだ。さきほど、完成数基準で進捗率のグラフをプロットすると、値がずっとゼロのままで、使い物にならなと書いた。逆に言うと、進捗率計算の主目的が完成日予測にあるのならば、理想的な進捗の指標とは、グラフがちょうど直線で進んでいくような形だろう。これならば予測は、かなりやりやすい。これに対してEVMSの進捗カーブの形は、通常、もう少しS字カーブ型になる。プロジェクトの最初はゆっくりと立ち上がり、やがては活況に入ってぐんぐんと進捗があるが、最後の方になるとまたカーブが寝て、ゆっくりとした収束になる。プロジェクトの一番初期と、一番最後の頃は、EVMSの進捗率から完了日予測を正確にするのは難しい。両端の時期を除けば、まあまあ予測には使える。いうこともあって、EVMSの進捗率計算は広く使われている(少なくとも欧米では)。EVMSの進捗率によるコントロールは、万能ではない。この点についてはすでに何度か記事も書いたので、ここでは繰り返さない。舶来の手法で、試験問題にも繰り返し出されると、なんだかそれが『正解』だと思い込み、暗記してそのまま従うような風潮が、わたし達の社会には無い訳でもない。繰り返すが、進捗率計算というのは、いろいろな定義が可能なのである。少なくともそれが合理的で整合的である限りは、各社がいろいろと工夫して使っていい。一つ言えることは、「過去こんなに頑張りました」という事をベースにして計算してはいけない、という点だけだ。これまでの努力を言いたい気持ちは、もちろんわかる。それをきちんと、ステークホルダー達に説明する必要もある。それは過去に属することだ。言ってみれば、タクシーメーターの料金なのである。ここまで、これだけ走り、料金換算でこれだけかかりました。タクシーメーターをいくら懸命に見つめても、この先いつになったら目的地に到着できるかは、分からない。進捗の指標にはならないということだ。進捗コントロールというのは、もっと未来志向の行為なのである。Comments(1)エンジニアリング・チェーンのマネジメントと、生産技術というボトルネック(前回記事「エンジニアリング・チェーンをゆるがす『個別性の罠』とは」から続く)エンジニアリングという仕事は基本的に、毎回毎回のプロダクトがすべてユニークであり、個別的な一過性の仕事です。それが創造的であればあるほど、「標準化とカイゼン」からなるPDCAアプローチが、とりにくくなります。いう個別的な仕事をマネージするとは、業務を「予見(計画)可能にし」、「再利用可能(繰返し可能)にする」、の2つの事から成り立ちます。以下、具体的にご説明しましょう。業務の全体像を予見できるようにすること個別的な業務を予見可能にするとは、どういう意味でしょうか。『個別性の罠』にとらわれないためには、ユニークな業務であっても、その行き先をある程度、予測できるようにすることが必要です。望ましい形に進むよう、計らう必要があります。それは端的に、その業務がいつぐらいまでかかり、どれくらいの費用を要し、どんな工数を必要とするのかを、つかむことです。そのためには、業務のボリュームや作業の構成を考え、全体の工期・工数・コストなどを、見積もる能力をつける訳です。それに応じた体制や予算、人のアサインなどを決めていきます。計画していくということです。業務を「計画可能にする」といってもいいでしょう。これによって、いわば野放しの「野獣」を、通常の仕事の体制や予算の中に、取り込めるようにしていきます。次に、その業務を繰り返し可能にすること次にすべきは、個別性・一過性の業務の結果を、繰り返し(再利用)可能にすることです。仕事の成果物を出し終えたら、ほっとして一息つき、それから一件書類をどこかの机かサーバのフォルダにしまって、あとは忘れてしまう。次に似たような仕事が来たら、「えーと、前にやったあの仕事はどうだっけ」とファイルをひっくり返して探す・・こういう状態では、再利用可能とは言えません。設計に関わる仕事の場合、結果としての仕様書や図面だけでは再現するのに不十分です。「なぜこういう形になったのか」が分かるよう、検討の方針や前提条件、そして途中の計算書なども、合わせて保存される方が望ましいことは、皆さんご承知のとおりです。この部分がしばしば、ないがしろにされがちです。できるなら、ちゃんと一件書類としての保存のフォーマットと必要なコンテンツのリストを決め、インデックスをつけて、マスターファイルに保存すべきでしょう。設計の成果物だけでなく、どれくらいの期間と工数がかかったのか、体制や担当者は誰だったのかといった、業務のパフォーマンス面でのデータも必要です。このようなところまで持ち込めば、標準化に繋げられるようになります。業務を標準化できれば、PDCAとカイゼン文化に接続できるのです。野獣だったものを「家畜」にできる訳です。ところで、初めてチャレンジする一過性の仕事なんて、本当に「計画」できるのか、という疑問があるかもしれません。当たって砕けろ、まずは走り始めてみて、それから必要に応じて考えたらいいじゃないか。それが現場力というものだ、という考えもけっこう、強いと思います。製造業は中期経営計画があり、年間や半期の予算計画があり、月度の生産計画やら販売計画やらがあって、という風に「計画づくし」ですが、こうした計画類はある種、サイクリックなルーチンワークです。ルーチンにはまらないものが出てくると、突然、計画立案の手を止めてしまう。現場力という名の「出たとこ勝負」に走ってしまう。これは計画という仕事のプロセスや手順を、よく知らないから起きるのです。一過性の仕事の計画立案というは、次のような6つのステップを踏んで進めるべきものです。何をなすべき仕事なのかを明確にする。