<   2018年 03月 ( 3 )   > この月の画像一覧

POPとは何か、MESとはどこが違うのか

工場見学が趣味である。いや、趣味というのは言い過ぎかも知れないが、とても好きなことは確かだ。昨年から思うところあって、いわゆる組立加工系の工場について、機会があれば業種を問わず見学して歩いている。国内外あわせてすでに1ダースを越えたから、平均すると一月に1ヶ所は訪問している勘定だ。むろん、工場の改善指導をしているプロのコンサルタント諸氏には及びもつかないが、まあそれなりに見ている方ではないか。

工場見学に行ったら、何を見るべきかについては、すでに記事も書いた(「超入門:上手な工場見学の見方・歩き方https://brevis.exblog.jp/21898734/ 2014-04-16)。とくに製造現場を歩いているときは、できるかぎり、現品票を見ることにしている。

現品票とは何か。それは、工場の中を行き来している部品・材料などの現品に添付されて回っている紙の帳票のことである。なお、機械加工系では、加工対象の物品のことを「ワーク」Workとも呼ぶ。英語のworkは仕事・作業の意味が強いが、仕掛品のことをWork in Process(略称WIP)と呼んだりもする。そこで以後、この記事の中では、現品とか物品という代わりに、ワークということにする。現品票とは、工場内でワークに添付されている紙の帳票のことである。

ワークはそれぞれが個別だから、現品票もそれに1対1でついている必要がある。ただしワークが小さな部品である場合や、ロット単位でずっと流れていく場合は、複数個のワークに1現品票のこともある。ただ、その際は、複数個のワークが、通い箱や台車などに入っていて、物理的にワンセットで動かなければならない。そうしないと、ワークと現品票の対応関係が崩れてしまうからだ。

現品票とは、ワークについて「これは何か」を示す名札のようなものだ。小学校の新入生につける名札と思えばいい。高井戸小学校・1年4組・佐藤知一、という風に(たしか1年のときは4組だったと思う・・違っているかも知れないが)。現品票には、少なくともそのワークの品目コード・品名が表示される。

そして、通常は、そのワークが使用される『製造オーダー』の番号と付帯情報も示される。もっとも、日本では生産関係の用語に統一がないため、企業によっては製造オーダーではなく「製番」「製造指図番号」と呼んだりする。付帯情報とは、製造作業の納期、必要数量、製作図面の番号、どの最終製品に使われるか、どの工程(作業区)で使用されるか、等々だ。ちなみに、トヨタ生産方式で使われる「かんばん」も現品票の一種である。

工場内には多種多様なワークが流れている。それに対して、一対一で現品票を発行し添付するのは、手間とコストがかかる。ただ、それをやらないと、目の前のモノが何なのか、本来どこに置くべきか、いつまでに使用されるのか、等々が、「良く知っている担当者」以外の人には分からなくなってしまう。だから、すべてのワークに現品票がついているかを見ると、その工場のマネジメント・レベルがすぐ判断できる。

そして、現品票にバーコードがついているかどうかも、大事なポイントだ。

現品票には、人間に必要な情報は印字してある。では、バーコードは何に使うのか? 答えは、POPに使うのだ。

POPとはPoint of Production、すなわち「生産時点情報管理」の略称だ。ふつうは、それを支えるITシステムのことを指す。流通業界、たとえばコンビニでは、お客が買い物をすると、レジで商品のバーコードをスキャンして、品目・数量を確認し、金額を計算する。この時点で、購入情報はレジを通して吸い上げられる。この仕組みをPOS(Point of Sales)=「販売時点情報管理」という。そしてバーコードリーダと通信機能のついているレジを、「POSレジ」と呼ぶ。

POSシステムが表れる前は、商店は、一日が終わって棚の残量をチェックするまで、販売数量を知る方法がなかった。その時点で翌日の仕入れ数量を決めるのでは、遅すぎる。だからPOSという概念が現れた。

同じように、従来多くの工場では、一日が終わって作業者が「製造日報」を記入するまでは、何がどれだけできたのか、把握する方法がなかった。これでは、短納期化した注文に追いつくことが難しい。そこで、流通業界を真似る形で、POPシステムを導入する工場が現れるようになったのだ。

POPシステムでは、現場の作業者が新しいワークに対する作業に着手するとき、現品票のバーコードをスキャンする。また、作業が完了したときも同様に、スキャンする。これによって、作業区単位(ないし機械単位)に、どのワークを、いつ着手/完了したかを、システムがリアルタイムに把握する。

POPの目的は、大きく三つある。一つめは、個別オーダーの進捗把握である。受注生産では通常、個別の注文(オーダー)ごとに、納期と数量が決まっている。生産管理担当者は、製品単位の「生産オーダー」を、部品展開(工程展開)して、各部品ごとの「製造オーダー」に展開する。この時点で、各工程ごとの数量と期限が決まる。そして、これを製造現場に指図として送る(これを「差し立て」ないし「ディスパッチング」とよぶ)。と同時に、それぞれの部品に対して「現品票」を発行し、現品に添付させるのである。

したがってPOPシステムを利用して、予定した製造作業の期限に対し、きちんと完了の信号があがってきているかをチェックすれば、進捗状況が把握でき、遅れがある場合は検知できる。現品がどの作業区にあるかについて、ラフな所在管理もできる。

二番目の目的は、作業時間の計測である。着手・完了時刻を取得している訳だから、作業時間を計算するのはたやすいし、従来の日報に比べて、正確だ。作業時間が分かると、賃率をかけることで、個別オーダーのコストの集計・管理ができるようになる。すると、オーダー単位の利益が計算できるし、また次の見積にも基礎データとして役に立つ。

三番目の目的は、生産性の把握だ。こちらも作業時間の計測が基礎になるが、さらに機械単位ないし作業者単位に、どれだけの生産数量ができたかを集計し、生産性を比べることができる。もしも標準工数が決まっているのならば、作業区別の負荷と余力も推算することができる、という訳だ。

POPシステムの概念は決して新しいものではない。図は、わたしが1992年に、中小企業診断士の受験参考書のために描いた、手書きの図(笑)である。日刊工業新聞社「工程管理ハンドブック」を参考に作図した。今から26年も前の話なので、「ホスト・コンピュータ」などと書いてある。今ならPCサーバとかエッジサーバと書くところだろう。
e0058447_13494289.jpg

ちなみに、POPに隣接する概念として、SOPおよびデジタル屋台の支援システムがある。SOP(Standard Operating Procedure=標準作業指示書)とは、適正な作業を行い品質を保つ目的で定める、作業の詳細な手順指示である。これは医薬品製造や食品製造などの分野で広く用いられる。これを電子化し、現場の作業者に端末経由で示し、それにしたがって確認記録を入力することで、製造作業をガイダンスする仕組みを、この分野ではよく用いている。とくに医薬品はGMP(Good Manufacturing Practice)の法的要請があり、適正な作業記録が義務づけられるからだ。

デジタル屋台とは、組立工程における一種のセル生産の仕組みである。ちょうど屋台のように、作業台を一人1台ずつ与え、台の周囲に部品供給用の引き出しやラックを置く。そして、作業台にはモニターを設置して、作業者に対して組立作業をワンステップずつ、3D的に図解して示すのである。とくに組立の部品点数が非常に多いケースや、個別受注で組立手順が毎回少しずつ違うケースに有効である。

さらに、作業者が部品棚から正しい部品を正しい個数取り出したか、とか、適正なトルクでネジを締めたか、といった点までセンサーでモニタリングすることも行われる。現在、静岡大学客員教授の関伸一氏が、2000年代にローランドディージー社で見事なデジタル屋台システムを作り上げ、広く知られるようになった。この事例では、作業者一人ひとりの生産性を測定し、自分の能力アップを実感できる仕組みにして、作業者のモチベーション向上に大いに貢献したという。

SOPもデジタル屋台も、必ずしも現品票とバーコードを活用するとは限らないが、作業時間を計測しているので、いろいろと付加的な機能を持てる点で共通している。

このようにメリットの大きいシステムであるにもかかわらず、日本の全ての工場に常識的に普及しているかというと、決してそうでもない(だから毎回、工場見学のたびに現品票とバーコードをチェックしているのである)。技術的には、25年前から存在し、ある意味、もう枯れた技術である。なのに、なぜ普及しないのかについては、ここではあまり深入りしないが、大きく3つの要因がある。一つめが、こうした製造現場のIT化投資に関する経営側の無理解、二つめが現場作業者のもの言わぬ抵抗、三つめは生産管理(とくに生産計画)担当部門の力量不足である。(さらに4番目をつけ加えるなら、現場に強いITエンジニア不足もあるが)

ところで、この1〜2年ほど、少し潮目が変わったかな、という感じを受けている。IoT技術の進展と、スマート化・AIブームなどの影響で、再び製造現場のIT化の遅れが問題視されるようになった。今回は特に、深刻な人手不足問題が追い打ちをかけている。自動化を進めないと、受注をさばききれない、という状況があちこちに生じたのだ。その結果、たとえばわたし自身も、MES(Manufacturing Execution System=製造実行システム)に関する問合せを受けるようになってきた。MESの話題なんて、この15年間、特定業界以外の人はほとんど誰も口にしなかったのに。

MESが何かについては、別に解説記事も書いた(「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 https://brevis.exblog.jp/25991822/ 2017-08-19)ので、ここでは繰り返さない。ただ、POPとMESの関係だけは整理しておこう。簡単に言うと、POPとはMESの第一歩である。

そもそも、組立加工系の工場におけるMESの機能要素は、7種類くらいに分けることができる(世間的にはMESA Internationalの「11機能」を列挙するのが通例だが、あれはプロセス系も混ざり込んで分かりにくいので、自分流に整理し直した)

(1) 詳細な工程(作業)展開と指示発行(SOP含む)
(2) 機械設備の高度な連携制御(DNC含む)
(3) 製造プロセスのモニタリング
 →これは、機械・人の状態監視と、ワークの所在・数量・移動の把握に、さらに区分できる
(4) 製造オーダーのトラッキング
 →これも、進捗と完了予測、そしてトレーサビリティ機能に区分できる
(5) 品質と製造パフォーマンスの計測
 →すなわち、品質・リードタイム・生産性の計測と分析である
(6) 製造資源の維持・保守
(7) 製造技術情報(製作図面・BOMを含む)の共有・検索

逆に、MESでは通常、対象外となる機能もある。すなわち、
(8) 通常の制御系機能
(9) 調達・コスト管理機能

POPは、上の機能リストで言うと、(1)と(3)を部分的にカバーしている。つまり、MESのサブセットという訳だ。もちろん、別に上の機能全てをカバーしなければ、MESと呼んではいけない、というつもりはないし、工場によって必要な機能のセットは異なるだろう。そこはもちろん、IT化の手間と効果、そしてコストの見合いで決めるべき事柄だ。一般に、対象業務の規模が大きくなり、コントロールすべき物事の数が増えたら、IT化の効果が出やすい。

さらにいうなら、市販の生産管理システム・パッケージや、ERPパッケージにも、ある程度POP的な機能が実装されている場合が多い。現代では、選択肢はいろいろあるのだ。ただ、生産管理やERPが、どちらかというとコスト管理目的に傾斜しがちであるのに対し、単体のPOPやMESは、製造プロセスの円滑なマネジメントが主目的であるという違いはある。それに応じて、現場に要求される作業も微妙に変わってくるだろう。

わたしの個人的な意見としては、最初から製造現場に細かなコスト管理の仕組みを持ち込むよりも、まずは製造が遅滞や不良なく円滑に進むことを、優先すべきではないかと思っている。ここは異論のあるところかもしれないが、もしも納期遅延や生産性に悩んでいるのなら、単体のPOP構築からはじめてみるのが、賢い選択ではないだろうか。

<関連エントリ>
 →「超入門:上手な工場見学の見方・歩き方https://brevis.exblog.jp/21898734/ (2014-04-16)
 →「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 https://brevis.exblog.jp/25991822/ (2017-08-19)

by Tomoichi_Sato | 2018-03-21 14:56 | サプライチェーン | Comments(1)

書評:「小水力発電が地域を救う」中島大・著

小水力発電が地域を救う」 (Amazon)

最近読んだ中で、最も面白かった本だ。わたしはあまり新刊書を批評しない(というか、読んだけれど書評を書けずに溜まっている本が沢山ありすぎる^^;)。だが、この本はできる限り多くの人に読んでもらいたいので、あえて順番を飛び抜かして取り上げよう。

タイトルを見ると、本書はたんに再生可能エネルギーの一分野である「小水力発電」を紹介し、宣伝するだけの目的に思えるだろう。だが著者は、この一見地味な技術について、もっと広いパースペクティブ(ほとんど文明論的な視野)に立って、日本社会に与えうるポテンシャルを論じる。いやあ、頭の良い人が書いた本は面白いなあ、と読みながら久々に感じた。お勉強のできる人や知識の豊富な人は、たくさんいる。だが、広い視野からものごとを多面的にとらえて考えられる人は、滅多にいないのだ。

著者は、全国小水力利用推進協議会の事務局長。経歴を見ると、’85年に東大の物理学科を卒業するが、その後は官庁や大企業にいかず、ベンチャー企業をへて、2005年に非営利の協議会組織を立ち上げ、リードしてきた人だ。

思い出してみると、2005年頃と今では、再生可能エネルギーをめぐる状況は、まったく変わってしまっている。その供給量も価格競争力も、世界的にここまで進むとは、誰も思わなかったろう。日本では2011年にFIT(固定価格買取制度)が制定され、以来とくに太陽光発電がブームになった。

だが、わたし達が最も古くから利用してきた再生可能エネルギーは、水力なのだ。日本は気候と地形に恵まれ、水力利用の適地だという事情もある。だが、著者が指摘するように、ヨーロッパの産業革命も、じつは水力からはじまった。アークライトの水力紡績機は、ジェームズ・ワットの蒸気機関よりも先に現れ、機械工業化の火付け役となったのだ(p. 150)。

水力発電のメリットとは何か。それは、発電量が安定していることだ。太陽光が、日周変動を不可避的に持つことはいうまでもない。では、風力発電はどうか。じつは、風力の発電量は、風速の3乗に比例するという物理法則がある(流体の動圧=運動エネルギーは流速の2乗に比例し、かつ発電の能力はタービンを通過する風量に比例するから)。大気乱流のスペクトル分布を考えれば、風力発電がいかにブレやすいか容易に想像がつく。

水力発電も風力発電も、基礎原理的には同一だ。なのに、発電量の安定度が違うのは、水力は発電機のタービンの前に、堰・ダム・水路などのバッファーをたっぷり持っているからだ。さらに、天からふる降雨量を、山それ自体が平準化して流出してくれる。本書が対象とするのは、1000 kW未満の小水力だが、それでも全国の開発可能量(経済性を考慮した数量)は数千箇所、合計100万kW程度と見込まれている(p.21)。ほぼ原発1基分である。これだけあれば、足下の山間地の需要はおおむね満たすことができる、という。

ただし、第8章「歴史の中の小水力発電」に詳しく書かれているように、日本には小水力発電が育ちにくい不幸な事情があった。現在、小水力発電を計画しようとすると、肝心の水車を、欧州やアジアから買ってこなければならない。発電用水車を安価に製造できるメーカーが、日本にほとんど無いからだ。なぜ、この技術大国で、水車程度を作れる企業が存在しないのか。それは、そもそも市場がなかったからだ。

戦前の日本では、水力発電事業を行う鉄道会社や自治体も、それなりに沢山あった。しかし、「戦争に伴う挙国一致体制を築くため、小水力も含めて、発電所・電気事業は日本発送電という国策会社に統合されてしまいます。そして敗戦後も、元に戻すのではなく、(沖縄を除く)9社の電力会社に分割再編することになり、地域の小水力発電所もその電力会社に帰属することになりました」(p.158)

地域独占となり、経済成長で巨大となった電力会社にとって、「戦前から引き継いだ小水力発電所はコストパフォーマンスがわるいため、だんだんと廃止され」ていった(p.159)。たとえば東電管内の山梨県では、300kW以下の発電所は廃止の指示が出た。こうなると、機器を製造するメーカーも生きていけなくなってしまう。

ところがヨーロッパでは事情が違った。もともと歴史的には、日本も欧州も、大都市向けの大規模水力の開発と、村落向けの小水力の増加が並行して進んでいた。だが敗戦国ドイツでさえ、小水力発電所の統合は行われなかった。今でも村営の発電所が多数残って、馬鹿にならない量の電力を安定供給している。かくして、今でもドイツやイタリアに、安価で優秀な水力機器メーカーが生き残っているのである(p.159-161)。

ただ、歴史の面白いところは、このような状況にもかかわらず、民間が自由に水力発電事業を営める形態が、ほんの一筋の水脈のように、残ったことだ。それも、なぜか中国地方に残っていた。織田史郎という人物のおかげだった。彼は中国電力の前身にあたある中国配電会社の役員だった。彼は、戦後まだ残っていた「無点灯地区」(電気の来ない村)では、自力で発電事業をやればいいと考えた。そして将来、配電線が村に届いたら「電力会社に電気を売って、地域振興の財源にすればいい」とまで見通した(p.164)。

こうして彼らの働きかけにより、「農山漁村電気導入促進法」が1952年に制定される。織田の努力が実り、中国地方には最盛期には200ヶ所もの小水力発電所があった。事業主体は農協や漁協、土地改良区などだ。水力発電設備は寿命が長いから、今も50ヶ所が事業を続けているという。ただ、全国的には衰退していく。「その原因を一言で言えば『挙国一致体制で国策会社に統合した』ことにつきます」、と著者は書く(p.167)

しかし、まだ「促進法」自体は生き残っている。これを活用する形で、この10年ほど、全国にぽつりぽつりと、地域振興をかねて小水力発電が復活しはじめた。その代表例は、第1章に詳しく書かれている岐阜県郡上市石徹白(いとしろ)地区の事例だ。岐阜市出身で一時は外資系コンサル会社に勤めていた平野彰秀氏が、一種のUターン(正確にはIターン)をし、地域づくり協議会として、マイクロ水力、ミニ水車をつくっていく。ついには発電目的の農協を組織し、125kW出力の発電所を建設するのである。

「FIT制度が始まった今は、小水力発電に良い時代です」と著者の中島さんは書く。「農産加工品などの市場開拓は簡単ではありません。ところが、小水力発電の電気は、FITのおかげで必ず売れるという利点があります」(p.47)。

石徹白の取り組みの原動力になったのは、じつは小学校が廃校になってしまうかも知れない、という危機感だった。「小学校の存続は、地域が存続するかどうかの先行指標と言っても過言ではありません。子育て環境の悪化で若い夫婦がいなくなるだけでなく、子どもたちの帰属意識が薄れ、高校・大学を卒業した後戻ってくる動機が弱くなるからです」(p.38)-- このように、過疎に悩む限界集落にとって、発電事業による収入の確保は、地域の生き残りのカギになりうる。

そればかりではない。日本の里山では、農業用水路の維持保守が、死活的に重要だ。しかし近年の農業人口の減少により、一人あたりの維持費用負担が高くなり、ますます離農が増えるというダウンスパイラルが、あちこちに起きている。そこで、農業用水路を活用した小水力発電と、それに伴う現金収入は、農業それ自体を維持する上で重要なのだ。

ここで、農業用水路の『空き断面』を活用した水力発電、という新ビジネスモデルが、にわかに登場する。空き断面とは、水路の余裕となる流量だ。農業用水は田植えなどの時期を除くと、じつはかなり流量を絞っている。10の容量があっても、1の水量しか流れていない状態は珍しくない。そこで、ここに10の水量を流して、9の分は発電に使うのだ(p.57)。発電に使った後の水は、農地ではなく川に戻す。こうした話は、本書を読むまでまったく思いもかけなかったアイデアで、とても面白い。

もう一つ、なるほどと思ったのは、「山村の土建会社は小水力発電で生き残れ」(第3章)だ。近年、地方の小規模な土木業者たちはつぎつぎと廃業している。しかし、山村ではいったん大雨や災害が起きると、土建業者が対応してくれない限り、ライフラインが復旧しない。だから地方の土建会社は必要なのだ。ところで小水力発電所の建設と運営は、土木技術の固まりである。だから公共事業の減った今日、土建会社にとって良い副業になる。

おまけに土建会社の経営者は、当たり前だが経営感覚に優れている。発電所の設置と運営は、やはり経営感覚のある人がいるかどうかが、成功の鍵なのだ。第3章には、富山県の土木経営者だった、故・古栃一夫の獅子奮迅の働き(当時は監督官庁の、言いがかりに近い無理解があり、それと闘った)が、いきいきと描かれている。

というわけで、本書は具体事例をふんだんに盛り込みつつ、地方活性化のために小水力発電事業がいかに有用かを、多面的かつ客観的に書いている。副題に「日本を明るくする広大なフロンティア」とあるが、地方の山村を明るく事こそ、著者(ご本人は都会生まれだと書いているが)の強い願いなのだ。

その信念は、序章と終章によく表れている。序章で著者は書く。「日本の山の木材の価値を死なせてしまったのが、1964年の木材輸入自由化でした。海外から木材を安く輸入できるようになったため輸入材が急増し、日本の林業は壊滅状態になってしまったのです。このことは山村から主要な価値が失われたことを意味していました。(中略) 木材が燃料であり建築材であった20世紀の半ばまでは、ものの価値と言う意味で見れば、山は価値の流れの上流にあったのです。ところが山は、価値の流れの下流、しかも最も末端になってしまったのです。こうして、山村から人がどんどんと里へと移動し、過疎化が進んだわけです。」(p.14)

このような流れを止め、できれば逆転させる力となりたい、というのが著者の望みなのだろう。今日風のグローバリズムの観点に立てば、そんな経済効率の低い辺境地域などうち捨てて、人口は都市に集中させ、そこに資源を集中させる方が効率的だ、という結論しか出てこない。だが、著者の意見は違う。

「町育ちの人ばかりになると、社会が脆くなります」(p.177)

効率性は脆弱性と裏表の関係にある。効率性の高いシステムは、冗長性が乏しく、外部条件の変化に対して脆弱になる、と著者は指摘する(同頁)。このテーゼは、わたしが最近ずっと考えている、システムに固有なトレードオフの問題と同じで、その点でもとても共鳴してしまった。

小水力発電事業は、たぶんわたしの勤務先のビジネス領域には重ならない。多くの読者にとっても、同じだろう。だが、それでも、日本の地域の文化が生き生きと存続することを願うならば、一人でも多くの人にこうした活性化のビジネスがあり得ることを知ってほしいと思う。


by Tomoichi_Sato | 2018-03-14 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)