プロジェクト計画のロジックとは何か 〜 やはり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(2)

ダイレクト・ガントチャート方式の問題点 〜 やはり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)

メーリングリストの登録受付を開始します

読者各位:

以前、本サイトの新着記事を配信するメーリングリストの予告をいたしましたが、ようやく設置の準備が整いました。

メールアドレスの登録フォームは、姉妹サイトである
 「マネジメントのテクノロジーを考えるhttp://mgt-technology.info
のトップページ左側サブメニューにある、「ニュースレター登録フォーム」をクリックすると開きます。
そこから、メールアドレス、氏名、所属を登録してみてください。
登録確認メールが発信されるはずです。

このメーリスは、Benchmark Emailというサービスを利用しています。今後、新しい記事はまず、こちらから発信していくつもりです。

なお、メーリングリストに登録いただいた方から、先着20名様に、わたしがこのサイトの記事から選んだ、

 『モノサシを疑え 〜 マイ・ベスト・セレクション

の電子ブック(ePub形式)を、お名前入りでさし上げます。
大勢の皆様の積極的なご登録を、お待ちしております。


佐藤知一

(追記:おかげさまで、先着20名の枠は1日を待たずに一杯になりました。
 早くお申し込みくださった方々には電子書籍を順次お送りさせていただきます。
 記事のメール配信自体は、いつ登録されても有効です。
 また、メールのみでの情報発信やご案内も考えておりますので、ぜひよろしくご登録ください。)


# by Tomoichi_Sato | 2017-11-28 22:56 | ビジネス | Comments(0)

『生産統制』の三つの課題

3年ほど前から、大阪府工業協会のご依頼で、『生産統制』をタイトルにした1日セミナーを行っている。といっても、メインのテーマは納期遵守とリードタイム短縮であり、内容的には生産の計画と統制の両面を含んでいる。いや、話としては、むしろ計画面での話の方が、ウェイトが大きい。というのも、受注生産における納期遅れの問題は、無理な受注や計画が起点となることが多いためだ。

部品材料も手配してある。ちゃんと能力的に無理のない計画も立てた。必要な図面もある。それなのに製造が遅れました・・というような事は、日本の優秀な製造現場ではあまり起きない。機械が老朽化してチョコ停が多かった、人手が足りなくて作れませんでした、という事象が起きることはあろう。だが、そうだとしたら、そうした現実を無視した生産計画の方に、ムリがあるのだ。適切な指示手配を出したのに、統制(コントロール)がきかずにモノが作れないような会社は、そもそも今までの競争に生き残れていないだろう。

計画・指示の方向と、実績・統制の方向は車の両輪である。製造業では、この二種類の方向の情報が行き交っている。生産の計画と統制は、英語で言えば、PlanningとControlである。この二つは、より大きな概念であるManagementの機能に含まれる。

ところで、「生産統制」という用語・概念をはじめて学んだのは、今からもう25年も前、中小企業診断士の勉強をしているときだった。生産管理の教科書に、生産計画と生産統制が並んで書かれていた。そして、今でも覚えているが、生産統制の3つのポイントは、(1)現品管理、(2)進捗管理、(3)余力管理、だと習った。診断士の一次試験は暗記物だから、そのままオウム返しに記憶したのである。ネットで「生産統制」と検索すると、今もこの3つのキーワードがすぐに上がってくる。

だが、不思議に思うのだが、なぜ、この3つなのか? 計画を立て指示を現場に出した後、生産管理担当者としてやるべきことは、他にもあるではないか? 誰がこのような「生産統制」の教科書的概念を決めたのか? 米国から輸入したのだとは、思えない。「現品」などの用語が英語的でないからだ。

英語で生産統制に相当するのは、Production ControlないしShop Floor Controlであろう。しかし、アメリカの生産管理の本、たとえば手元にあるK. Sheikh著”Manufacturing Resource Planning II”の該当する章を見てみても、そんな3大ポイントは見当たらぬ。かわりに、APICS(米国生産在庫管理学会)の辞書にある6項目、すなわちオーダーの優先付け、仕掛品の数量把握、といった事柄が紹介されている。

もう一つ、「生産統制」に関して不思議なことを指摘しよう。それは、「生産統制部門」が企業には存在しないことだ。もし教科書がいうように、生産計画と生産統制が生産管理の二本柱だとしたら、それに相当する部門(課なり係なり)があるはずだ。実際、生産計画の担当部署はいろいろな会社に存在する(課や係ですらなく、担当者一人の場合もあるが)。しかし、いろんな機会に多くの人にたずねたが、生産統制と名のつく部署があると答えた方は一人もいなかった。

もちろんそれは、単に名前の付け方の問題だ、という見方もあろう。工程管理部門とか、工務部門とか、あるいは単に「追っかけマン」などが、専門職として存在する企業は、たしかにある。でも、もしそうだとしたら、教科書の用語の方が、現実に寄り添うべきではないのか。どうして誰も使わない用語が、いつまでも資格試験には通用するのか。

だが、話を元に戻そう。製造業には、指示と報告の二つの情報の流れがつねに存在する。計画を立て、指示を出すことは、未来方向についての情報であり、現場への流れである。進捗や実績を報告するのは、現在や直近の過去についての情報であり、現場発の情報である。では、そのその後半について、やるべき仕事の全体像は何だろうか。わたしは、大きく分けて3つあると考えている。
e0058447_00573210.jpg
第一は、トラッキングである。具体的にいうと、タスク(作業)とモノと情報のトラッキングだ。一番大切なのは、指示された作業が、その通り行われたかを、逐次おいかけて確認することである。ちなみに『トラッキング』とは、移り変わっていく物事を、逐次追いかけることを指している。「逐次」とわざわざ書いたのは、作業のプロセスが大事だからだ。製造業は、決して「結果オーライ」ではない。モノさえできあがれば、あとはどうでもいい、という訳にはいかないのだ。

ただし、指示のトラッキングを行う前提条件は、まず、指示が現場に対して明示されていることである。製造オーダー(あるいは「製造指示」、「指図書」、「仕掛けかんばん」等、呼び方は何でも良いが)が、現場に対して出されていなければ、そもそも追いかけようがない。

指示が出されていない所なんてあるの? と思われるかもしれないが、現場に対しては、ざっくりしたバーチャートの工程表が示されるだけで、あとは班長の裁量で着手したり中断する、という職場も実はけっこう存在する。もちろん、現場にも裁量や自由度を持たせることは、責任感という意味からも大切だろう。だが、現場の班長にきかないと、どの注文がいつできるのかサッパリ分からないようでは、それこそ「統制がとれていない」状態である。作業指示の統率と現場の自由度とを両立させるためには、現場の着手・中断の裁量範囲を決めるとか、指示の完了期限をタイム・バケット付きで与えるといった方針が必要である。

トラッキングの対象は、しかしタスク(作業)だけではない。そもそも現場は、モノ(ワーク)と情報(製作図面・仕様書)がそろっていないと、製造ができない。そこで、工場内における、仕掛品を含めたモノのトラッキングが重要になるのである。つまり「現品管理」である。もちろん、工程の中間にどれだけ仕掛かり(ワーク)が滞留しているか、といったことも、つかんでおくべきである。無論、これはなかなか簡単ではない。が、ともあれ、工場内における、モノの位置と流れの交通整理が大切なのだ。

わたしが工場見学に行く際、いつも注目しているのは、工場内の物品にきちんと『現品票』が添付されているかどうかである。そして、そのモノが何なのか、どの製造オーダーのためのモノなのか、どの顧客向けなのか、そして本来あるべき定位置はどこなのか。そういったことが現品票に明示されているかどうかを調べる。出庫や使用予定が2ヶ月も前のモノが、通路脇に無造作に置いてあったりしたら、この工場は何かおかしいな、と分かる。

図面や仕様情報についても同じである。個別受注生産の形態では、製造着手時点で詳細設計が固まりきっていなかったり、途中で設計変更が生じることが、ままある。その場合、現場に正しい最新版の図面が配布されているか、の追いかけが必要だ。つまり情報のトレーサビリティである。

ところで、こうした追っかけのために、どのような管理番号の方式(トラッキングのためのキー)をとるかは、企業によってまちまちだ。たとえば受注生産形態ならば、日本ではしばしば製番管理方式が用いられる。作業指示に、製番(受注番号)が付番される訳である。

しかし、繰り返し性の高い生産形態や、内示とかんばんによるプル型生産の場合は、製番よりも流動数管理の方式が適している事が多い。流動数管理は別名、「追番管理」ともいい、零戦の生産で有名な中島飛行機が発祥だともいわれている。製品・部品に連番をとって、累積生産数量を追っていく方式である。いずれの方式でも、モノの管理番号としては、シリアル番号が用いられる。

さて、三つのポイントの2番目は、製造資源の状態のモニタリングである。「指示と作業」は一過性の物事であり、経過をたどって消えていってしまう。だから追いかけの対象になる。しかし製造資源、すなわち人とか機械設備とか治具・金型などは、永続的である。一つの作業が終わったら、別の作業に向かうことができる。そこで、どれだけの資源が利用可能なのか、その能力はどれほどかを、モニタリングしておく必要がある。

「人」に関しては、多くは日報単位の把握が行われている。それは半日とか1日遅れの情報であり、致し方ない面もあろうが、リアルタイムなモニタリングとはほど遠い。まあ人は組織の中にいるので、上長がつねに監視・統率しているはずだから、それでいいと考えられてきた。また、小うるさく管理されたくない、という感情面の配慮もあろう。

しかし機械設備に関しても、じつは組立加工系の多くの現場で、状態はよく把握できていない(プラントや半導体など、高度に自動化された工場は除く)。もちろん、機械のそばにいて使っている担当者は、状態は見てわかっている。しかし、生産管理側から見ると、それこそ、工場の扉を閉めて、建屋の外に一歩出たら、もう中の機械が動いているのかと待っているのかさえ、分からないケースがほとんどである。立派なマシニングセンタでさえ、PLCが外部に持っている通信インタフェースは、この21世紀にRS-232Cのままだったりするのである。だからこそ、機械のモニタリングは、IoT技術が一番試されている部分なのである。

ツール・金型・治具も製造資源だが、こちらになると、モニタリングはもっとあやしくなる。管理番号(ID)さえついているかどうか、心許ない。こうした金型類も、状態と履歴の把握が必要だし、それが結構なコストセーブにつながる可能性がある。

そして、電力や用水や圧縮空気などの用役も、一種の製造資源であり、その供給状況(使用状況)と原単位の把握はしておく方が良い。

三番目のポイントは、製造ラインあるいは工場全体の生産パフォーマンスの測定である。つまり、工場の実力を、モノサシを当てて測る仕事だ。指示した仕事もした、資源の状態も把握した、だが全体としての実力の程を評価しなければ、改善改良を考えることができない。

パフォーマンスの測定は、端的にはQCD(品質・コスト・納期)の達成水準であろう。ただし、工場には普通、品質管理部門があって品質を専門にチェックしている。またコストについては、生産着手時点にはもう、だいたいのコストは決まってしまっているものだ。だから生産管理の視点からいえば、納期並びに進捗の測定が中心となる。だから、納期遵守率の概念などが大事になる。そして昨今、納期遵守率を左右する最大のポイントは、生産能力と負荷(あるいは余力)レベルであろう。

とはいえ、工場にはQCD以外にも、在庫量だ生産性だリードタイムだ労働安全統計だ、とモノサシがいっぱいある。その全てを、なかなか同時には満たせない。そこで、どの尺度を重視して工場を運営するかは、その企業の「コアの競争力」を、どうとらえるかにかかっている。ここがけっこう、あいまいな工場が多い。

以上、「生産統制」の観点から3つのポイントをあげた。こうした作業を支援するITシステムの仕組みは、MES(製造実行システム)と呼ばれる。とくにUpper MESとよばれる仕組みの機能領域である。

ただ、生産管理においては、上記の3つの作業で生産の実態を把握することが、最終目的ではない。生産実態に付随する問題発見と解決こそが、生産のコントロールの一番の目的なのである。そして、上記のリストをふりかえってみると、中でも、能力負荷と余力の判定が一番難しい、と感じられる。多品種を切り替える工場での「能力」について、定義も理屈も明確になっていないことが多いのだ。
 
このままではUber的な工場の「余力取引」だとか、Industriy 4.0だとかの対応など、どこの国の話だ、ということになってしまいかねない。だからこそ、日本の製造業が今一段の飛躍を遂げるためには、生産のコントロールのレベルを上げるMESが重要になってくるはずなのである。いや、それよりもっと前に、そもそもこうした複雑で広範にわたる生産管理という仕事の全体像をきちんと理解して、「生産管理を統率する」人材こそ、日本の製造業には必要なはずなのだ。

なぜ、世の中には、単なる入門書・教科書より一歩奥の、実務家のために役立つ情報源が少ないのか。理由は不明だが、ニーズは明らかだ。さればこそ、わたしのこのサイトが、そのささやかな一助となることを願って、こうして書き続けているのである。


<関連エントリ>
 →「IoT時代のMESをもう一度考え直す 〜 (3) MESの未来像とは」 http://brevis.exblog.jp/26026181/ (2017-09-04)

# by Tomoichi_Sato | 2017-11-23 00:59 | 工場計画論 | Comments(0)

PM理論に関する講演のお知らせ(12月8日)

来る12月8日(金)の夜、東京・東麻布の日本プロジェクトマネジメント協会で、講演を行います。

先月、わたしは米国シカゴで開催されたProject Management Institute (PMI) Global Conference 2017に参加し、講演発表を行ってきました。ご存じの通りPMIは世界最大の影響力を持つプロジェクト・マネジメント専門職団体で、その世界大会はPM分野の最新状況を反映しています。

今回の講演では、まずPMI世界大会2017にみる北米PM界の潮流を概観します。その上で、わたしが行った発表『Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions』(「リスク基準プロジェクト価値RPVとアクティビティの貢献価値に基づく意思決定」)の内容を、そのままご説明します。

リスク基準プロジェクト価値(RPV)は、わたしが提案した意思決定のための尺度で、文字通りリスクを勘案したプロジェクトの価値を数字で表したものです。これを用いると、プロジェクトを構成する各アクティビティの貢献が計算できるばかりでなく、コスト対リスクといったトレードオフ状況下における意思決定を、客観的にサポートする基準を導出することができます。

このRPV理論は、わたしが自分の学位論文の中ではじめて提案し、研究・発展させてきたものです。理論的な内容のため、これまでは学会論文誌や大学講義、ならびに海外でのみ、発表してきました。今回、はじめて普通の民間の場を借りて、お話しする機会をいただきました。そこで具体的なケース事例を交えて、できるだけ分かりやすく解説させていただくつもりです。

この講演は、どなたでも参加できます。大勢の方のご来聴をお待ちしております。

<記>

日時:12月8日(金) 18:00〜

場所:日本プロジェクトマネジメント協会 「PMAJ Networking」
   〒106-0044 東京都港区東麻布一丁目5番2号 トウセン東麻布ビル7階

講演タイトル:
「PMへのシステムズ・アプローチと、『リスク基準プロジェクト価値(RPV)』理論の応用」

要旨:
 モダンPMの手法は、1950年代の米国で、プロジェクトを『アクティビティのネットワークからなる一種のシステム』と認識した事にはじまる。以来、PERT/CPM、WBS、EVMSなどの定量的技法が開発され普及してきた。しかし今日のPM論の枠組みには、まだ意思決定に資する価値論が欠けているように思われる。演者は数年前から、『リスク基準プロジェクト価値(RPV)』という指標を用いた、独自の理論的枠組みを研究してきた。本講演では、10月末に米国シカゴのPMI世界大会に発表した内容を中心に、ケース事例への応用と今後の課題について展望する。

講師プロフィール:
 日揮株式会社・グローバル戦略室長代行。博士(工学)。中小企業診断士。
 ながらく国内外の製造業のプラント計画、生産システム構築と、プロジェクト・マネジメントに従事。現在は経営企画部門で戦略立案に携わる。
 そのかたわら、近年はプロジェクト・マネジメント手法の改善・体系化と教育に力を注ぎ、「リスク確率に基づいた新しいプロジェクト・マネジメント」の研究開発にも取り組んでいる。
 静岡大学客員教授、東京大学・法政大学非常勤講師。

参加申込みは、以下のURLからお願いします。


佐藤知一@日揮(株)


# by Tomoichi_Sato | 2017-11-16 22:10 | プロジェクト・マネジメント | Comments(0)

天の時・地の利・人の和と、プロジェクト

プロジェクトに関わる仕事をずっとしていると、プロジェクトの成否はプロマネの手腕やチーム員の努力だけでなく、「天の時・地の利・人の和」とでも言うべき要因によって左右されがちだ、と感じることがある。いわば、プロジェクトの出発点における環境条件である。こうした環境がプロジェクトのパフォーマンスにどのような影響を与えるのか、まだ十分に解明されていないように思う。

たとえば、「天の時」である。

プロジェクトのスタートするタイミングは、さまざまな形でパフォーマンスに影響する。端的には、マーケットの状況だ。市場全体が活況を呈しているかどうか。受注型プロジェクトの場合なら、契約金額が上昇気味かどうか? これは、プロジェクトの採算性にとって重大である。また、外部に発注するリソースや資機材の値段が上がりつつあるか、どうか。これも採算に影響する。

自社が好調か、それとも苦しい時期かも大きな要因だ。苦しい時期だと、どうしても無理して仕事を取りに行く姿勢が強まる。当然、予算は厳しくなる。

こうした全体的な市況は、プロマネ自身が勝手に選べるものではない。まったく同じ前提条件ではじめても、スタートする時期が好況期で売り手市場なのか、あるいは不況期で買い手市場なのかによって、結果は相当異なるだろう。途中で市況が急変することだって、ある。わたしは10年近く前、あるビッグ・プロジェクトの見積をしていたが、途中でリーマンショックが深刻化し、プロジェクト自体の成立が急に危ぶまれたことを思い出す。そうなると、億の単位でかかる見積費用が、パーになってしまうのだ。たまったものではない。

次の、「地の利」とは何か。

プロジェクトを遂行する上で、立地的な優位性があるかどうか、の意味が第一だ。プロジェクトを遂行したり成果物を納入する場所の近くに、自社の拠点があるかどうか。これは、ふつうプロマネが自分で決められる条件ではない。海外プロジェクトの場合は、そこに支社や合弁相手がいるかどうか。いるとして、その能力はどうか。あるいは、日本から出かけていかなければならないのか。これらは大きな違いを生む。たまたまわたしは今、この文章をジャカルタの空港で書いているが、多くの日本企業がすでに存在していることも、ある種の地の利であると考えられる。

地の利は、より象徴的には、競合状態が厳しいかどうか、を表す。たとえ市況は好調期、現地に拠点があろうとも、競合相手が5社も10社も現れるようでは、レッド・オーシャンそのものである。勝ち抜くのは、かなり厳しい。

では「人の和」は、プロジェクトにとって、何を意味するか。

もちろん、それはまず、プロジェクト・チーム自体の協働意識を、そのまま表す。だが、そこはプロマネがある程度は醸成できるし、しなければならない。

しかしさらに掘り下げると、適切なメンバーがアサインされているか、という問題になる。メンバーがプロマネの固定的な部下であるような組織では、まあ、これは問題になるまい。が、機能型組織やマトリクス型組織では、複数の部門からメンバーをアサインしてもらわなければならない。とくに製造業ではライン部門長の権限は強大だ。プロマネが好きに人を集められる訳ではない。

もっと言うと、プロマネ自身の任命が適切か、ということもある。これはPMO的な視点から言っているのだが、「あのプロジェクトの最大のリスク要因は、XXさんがプロマネをやっていることだ」という笑えない冗談も、生まれたりする。良い仕事は、チームワークから生まれる。ぎくしゃくしたチームから、優れた仕事が生まれる可能性は、少ない。

しかし、人の和に関する、より深刻な問題は、外部のステークホルダにある。たとえば顧客(発注者)、ユーザ、協力会社、ベンダー、監督官庁、地域住民などである。とくに顧客は重要だ。受注型プロジェクトで、訳の分からん顧客に当たって、苦労した経験のあるプロマネは多いだろう。顧客と和の気持ちを持って、適度に緊張した関係を続けられるかどうかは、プロジェクトの成否を大きく左右する。

このほかに、かなり大事な要素として、プロジェクト・スポンサーの能力をあげたいところだ。スポンサーとは、経営層に近い上級管理者で、プロジェクトに予算枠を与え、プロマネを任命する権限を持つ人のことである。「スポンサー」のかわりに「プロジェクト・オーナー」と呼ぶケースもある。

プロジェクト・スポンサーは、プロマネの後見人であり、相談相手でもある。この人が、プロジェクトに理解があり、適切に経営層を動かせるかどうかが大事だ。大事なのだが、そもそも日本企業では「スポンサー」の役割が存在していなかったり、十分に認識されていない場合が多い。そうなると、「人の和」に、重大な欠落があることになる。

(余談だが、拙著『世界を動かすプロジェクトマネジメントの教科書』は、海外企業と合同でプロジェクトを始めることになった製造業を舞台に、主人公の若手技術者が、プロマネもスポンサーも誰だか曖昧な状況下で、なんとか成功させようと懸命に奮闘する物語である。つまり、あれは和を尊しとなす日本企業で、じつは機能的な「人の輪」が欠落している問題を扱っている)

元々、天の時・地の利・人の和とは、「天の時は地の利に如かず、地の利は人の和に如かず」という孟子の言葉から来ている。これが日本では、戦国時代に兵法の判断条件として、流布されるに至った。人の和が一番大事だと、孟子はいう。だが、戦国大名ならいざ知らず、現代のプロマネにとっては、上記の通り自分の力だけで人の和を作り上げることはできない。まして天の時や地の利は、所与の条件、としか言いようがない。

こうした要素は、環境としてプロジェクトに影響を及ぼす。ここで環境とは、「プロマネの意思では短期間に変えられないものごと」を意味する。

プロジェクトの成否は、受注時点で半分以上が決まっているーーそう言ったら、読者諸賢は、オーバーだと思うだろうか。だが、これに近い実感を、受注型プロジェクトに長年従事する実務者は、少なからずもっている。受注の時点で、天の時・地の利がもう決まっている。人の和も、かなり重要な部分が定まってしまっている。残された自由度の中で、プロマネは奮闘をはじめなければならない。

問題は、プロジェクトの採算が結果として悪化した時に、その原因のうち、環境因子による部分と、プロマネに起因する部分が、それぞれどれだけあるか、客観的な評価が難しいということだ。もちろん、「半分以上が環境」というのは、感覚論にすぎない。これについて定量的な分析を、あいにくわたしは見たことがない。

「プロジェクトの結果・採算は、全てリーダーであるプロマネの責任」、という結果責任の原則をとる企業は多い。これは、プロマネに責任感を持たせて育てるためには、良い指針である。プロマネがいつも責任回避的、あるいは他責的な人間では、会社はこまってしまう。

しかし、だからといって、プロジェクトの最終的な損益金額だけで、プロマネたちを、
 「貴方は今期2千万円の黒字を出したからA評価」
 「お前は今回、5百万円の赤字を喫したからC評価」
と、単純に査定していいだろうか?

それはあまり賢明ではない、と、わたしは考える。個別の案件の結果は、短期的な環境因子に左右されやすいからだ。プロ野球の一流バッターだって、打率は3割台である。1打席ごとの結果は、その時の状況に左右されやすい。能力の査定はある程度、長期的に見るべきだ、というのがわたしの意見である。ただ人事の査定は、半年ないし一年ごとに行わざるを得ない。数プロジェクトの平均打率を計算していては、間に合わない。では、どうするか。

わたしの提案は、プロマネの査定を行う前に、「プロジェクトの評価」を組織として公式に行うべきだ、というものである。会社として
  • プロジェクトの成果物、
  • 達成した金銭的価値、
  • 非金銭的な達成(人材の成長や実績レコードの確立など)、
  • 出発時点での環境条件、そして
  • 今後への教訓など
を評価し、記録する。このとき、損益の数字だけでプロジェクトを評価しないことが大切であろう。

その上で、出発点から到達点までの、プロマネの貢献を考量する。それが査定のベースとなるべきである。たとえプロジェクトの最終評価が低くとも、出発点での環境条件が厳しい場合は、その分を勘案する。

そのためには、プロジェクトの出発時点で、『案件のプロファイリング』を行う必要がある。市場環境(天の時)・競合状況(地の利)・顧客特性と組織メンバー(人の和)などを、プロファイリングして事前評価しておくのである。別に5段階評価程度でもいい。このような作業は、営業段階における受注戦略・案件選別においても有用だろう。営業部長の胸先三寸にすべてを任せるより、少なくとも公平に思える。

念のために書いておくが、上記のようなことを、わたしの勤務先がすべて実践しているから真似た方がいい、というような話をしているのではない。そうではなくて、環境条件の重要性に目を向けて、各社でそれを評価するようにしたらどうか、と提案しているのだ。また、そういう問題に定量的に取り組む研究者が、できれば現れてほしい。

その上で、厳しい環境条件が揃っている場合は、組織として積極的にプロジェクトの支援を行う。そうして、プロジェクトが倒れないように支える。そういう仕組みが必要だろう。

支援で人を出すと、その人件費のぶん、採算がさらに悪化する。すると、プロマネ自身は赤字をおそれて、支援を遠慮するかもしれない(問題を抱え込んで、上に報告しない可能性さえある)。しかし、放置したら会社としては、もっと赤字が膨らむ。それを防止することが、全体としては重要だ。

会社がプロマネを任命して、「プロジェクトは結果が全てだ」「あとは死ぬ気で頑張ってこい。」というのは、以前も書いたようにレベル1のマネジメントである。それで良い場合もあるが、いつでも正しい訳ではない。適切なマネジメントの仕組みを作るのは、会社の側の仕事である。

またプロマネの側も、本当に良い仕事をしたければ、人の和をつくり、地の利を整えた上で、天の時を待つだけの忍耐力が必要だということになる。それを昔の人は、「人事を尽くして天命を待つ」と言った。

それだけの謙虚さが、わたし達には必要なのだろう。気合や根性よりも、天の時への謙虚さが。


<関連エントリ>
→「マネジメントのレベル0からレベル2まで」(2017-09-22) http://brevis.exblog.jp/26064558/








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

お知らせ:プロジェクト・マネジメントの一日研修セミナーを行います(12月4日)

東京での研修講演のお知らせです。
来る12月4日に、日本テクノセンター(東京・新宿)で


と題する1日研修を行います(有償です)。

本講座では、プロジェクト・マネジメントの主要な技術について解説します。とくに、プロジェクトの成功をしばる三大制約条件であるスコープ・コスト・スケジュールと、それらをコントロールする技法であるWBSEVMSPERT/CPMについて、演習を交えてしっかりと学びます。とくにプロジェクトの基礎となるWBSの作り方については、他にあまりない実戦的なテクニックをお伝えします。また「海外型プロジェクト」の特性と進め方に関しても、講師自身の長年の経験に基づく実践的な解説を行います。

ただし、プロジェクトの成功はプロマネ個人の知識レベルや、スキルだけでは決まりません。組織がもつ思考と行動習慣(いわば組織の「OS」)に応じて人を動かすことが大切だからです。たとえば、

 ・計画がきちんと立てられず、行き当たりばったり
 ・だれが何を決めるのかわからず、意思決定が遅れる
 ・以心伝心・暗黙の了解で動いて、言葉にしない
 ・契約感覚に乏しく、地雷を踏んでしまう

といった項目に、一つでも思い当たることがある方に、ぜひ受講していただきたいと願っております。単なる外国の教科書の解説ではなく、実践的で身につく知識とスキルを学べる講習ですので、とくにこれから海外系のプロジェクトに取り組もうとされる方に、おすすめします。また、中小規模のプロジェクト実務に携わりつつも、世間のPM標準では満たされぬ思いを感じておられる方々にも、身のある内容だと自負しています。

本研修の内容は、拙著『世界を動かすプロジェクトマネジメントの教科書』とも連動しています。著書はストーリー仕立てになっていますが、研修では背後にある原理とセオリーなどについてもきちんと解説いたします。

お申し込みは案内サイトから行えます。大勢の方のご参加をお待ちしております。


佐藤知一

# by Tomoichi_Sato | 2017-11-06 21:24 | プロジェクト・マネジメント | Comments(0)

PMの世界はどこに向かうのか 〜 PMI世界大会2017に参加して


1. PMI世界大会とは

米国で10月28日から30日まで開催された、PMI Global Conference 2017 https://www.pmi.org/global-conference/about というカンファレンスに参加してきた。PMIはProject Management Instituteの略で、ご存知の方も多いと思うが、米国発・世界最大のプロジェクトマネジメント専門職団体である。全世界に40万人以上の会員を擁し、通称「PMBOK Guide」(正式名称"A Guide to Project Management Body of Knowledge")と呼ばれるPMの標準書を制定、さらにProject Management Professional(略称PMP)という資格試験認定制度を有している。世界で最も影響力の大きなPM関連団体だ。

そのPMI Global Conference(長いのでPMI世界大会と略そう)は、今年はシカゴで開催された。約3千人が参加する、大規模なカンファレンスである。ベンダーの展示会も併設されている。世界大会の名にふさわしく、60カ国から参加者があったという。みたところ、聴衆は北米、南米からの参加者が多い。他に中東、インドからの参加者も多少眼についた程度か。

ただ意外だったのは、中国人がほとんどいなかったこと。今どき、どこの分野の技術展示会でも大勢の中国人をみかけるものだが、不思議と少なかった。また韓国人らしき人や、東南アジア・アフリカからの参加者も少なかった。ちなみに日本からは、数名の参加者があったようだ(PMI日本支部の方とは、挨拶を交わした)。わたし自身、この大会に参加したのは、はじめてである。2コマ、合計2時間ほど、講演発表をした。その内容については、後で触れよう。

わたしは個人資格で、自費で参加した(発表申込みの事前審査をパスすると、大会参加費約15万円は無料になるが、旅費宿泊費は負担が必要)。日本人の発表者は、他にはいなかったと思う。だが日本にはPMI日本支部・PM学会・日本PM協会という大きな団体が三つもあるのだから、もっと競い合って米国で発表したらどうかと思うのだが。
e0058447_12501480.jpg
(PMI世界大会2017 基調講演の風景)

2. セッションの構成

今回の大会では、全部で100以上のセッションがある(https://www.pmi.org/global-conference/program-schedule)。10以上の部屋で、並行して進んでいく。そしてセッションは基本的に、どれも1時間以上の長さがある。

PMI世界大会は、いわゆる学会風のカンファレンスではない。ふつう学会となると、発表時間は15-30分程度だし、アカデミック・スタイルで論理的に、堅苦しくしゃべらなければならない。しかしPMIの大会は、もっとずっと自由である。講演者が聴衆に語りかける感じだ。分類としては、Educational Session(教育セッション)が中心で、その他に、展示会の出展者によるベンダーセッションがある。

教育セッションは、さらに5種類に分かれる
  • Analyzing and Process Improvement(プロセスの改善)
  • Communication and Teamwork(コミュニケーションと組織)
  • Decision Making and Problem Solving(意思決定と問題解決)
  • Enhancing PM Skills(PMスキル向上)
  • Influencing and Business Strategy(ビジネス戦略と働きかけ)

こう並べてみると分かる通り、セッションの話題はPMのソフト・スキルが中心であり、ハード・スキル系の講演は少なかった。ちなみにハード・スキルとは、技術・知識として確立されており、座学などで習得が可能な能力を指す。PMの分野でいえば、WBSやCPM・EVMSなど、理論やツールに関する事柄だ。だが、こうした話題の発表はほとんどなかった。

他方、ソフト・スキルとは、交渉力や問題解決力など、もっと属人的な技能である。日本だと「人間力」などと一括されがちな能力だ。こちらがどうやら、米国PM界の現在の関心の寄せどころらしい。人間心理などにも関わりが深い。ちなみに米国には「行動科学」「社会心理学」などの流派の心理学がけっこう旺盛である。それは最近の「行動経済学」などにもつながっているし(今年のノーベル経済学賞も行動経済学者だった)、経営学にも取り入れられている。その影響が PM分野にも、かなり流れ込んでいる感じだ。

大会では同時に、"PMI Project of the Year”の発表とポスター・セッションが行われた。毎年行われる数々のプロジェクトの中から、最優秀プロジェクトを選んで表彰するものである(わたしの勤務先は2002年に、サウジアラビアのプロジェクトで受賞した)。今年の候補者は、優勝のHanford Double Shell AY-102 Recovery Project(放射性廃棄物の漏洩回収プロジェクト)のほか、シアトル市のUniversity Link Light Rail Extension(郊外型公共交通システム建築プロジェクト)、Gahcho Kué Mine Project(北極圏でのダイヤモンド採掘施設建設プロジェクト)などである。こうしてみると建設系のプロジェクトが多いのに、大会のセッションには建設関係の話題がきわめて少ないのは不思議である。

ちなみに、本大会のセッションは、よく日本などで行われるような産業別・分野別などの分類にはなっていない。業種を越えて共通の話題を取り扱う、という方針なのだろう。なお、この秋には、遅れていた
PMBOK Guide第6版がやっと出版された訳だが、この解説セッションなどはなかった。


3. わたしの講演発表

わたしの講演タイトルは、"Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions"である。長さは1時間。日曜日に1回行い、さらに月曜日午後にアンコール講演を行った(アンコールの実施は、事前に事務局からの要望で決まっていた)。

内容は、わたしが近年ずっと取り組んできた、「リスク基準プロジェクト価値(RPV)」理論の概要と、ケーススタディの応用例である。今日のモダンPMには、価値論が欠けている、というのが、かねてからのわたしの課題認識である。意思決定はプロマネの主要な仕事であり、何かを決めるためには、複数の選択肢の中から、ベストなものを選ぶ必要がある。ベストなもの、とはすなわち、「プロジェクトの価値を最も高めるもの」という意味だ。

だが、どんな選択肢にも、不確実性とリスクが付随しているのが、プロジェクトの世界である。では、リスクを伴うプロジェクトの価値とは何で定義されるのか。また、プロジェクトを構成する一つひとつのアクティビティ自体は、そのプロジェクト価値に対して、どのような貢献をするのか。こういった問題を、RPV分析という手法で定量化できる、というのが、わたしの理論的枠組みである。

この上で、たとえば二つの選択肢AとBがあり、AよりもBの方が余計にコストがかかるが、そのかわりBの方が、プロジェクト全体に与えるリスクが小さい場合、どちらをとるべきか、数字で比較評価できるような方法を提示する。このようにして、プロジェクト意思決定に客観性のある基準を確立する、というのがわたしの講演発表の主旨である。さいわい講演は2回とも、好意的な反応を多くの方から(とくに実務者から)いただいた。

なお、今回の発表内容は、来る12月8日(金)夕刻に、東京神谷町の日本プロジェクトマネジメント協会(PMAJ)が開催する「PM Networking」で詳しく再演する予定である(もちろん日本語で)。PMAJ非会員も自由に参加できるので、近いうちに本サイトでもご案内するつもりだ。
e0058447_12500077.jpg
(講演発表のスライドの前で)


4. 他のセッション内容

わたし自身が聴けた中で、ほかに印象に残ったセッションを、いくつかご紹介しよう。

全体のオープニング・セッションでは、Sir Tim Berners-Leeの講演があった。89年にスイスの物理学研究機関CERNで、はじめてWorld Wide Webとhttpを開発した人だ。これは20世紀後半の最大の発明だったと思う。最後に彼は、AIが将来、裁判で人を刑務所に送り返すか放免するかを決めるようになる可能性もある、と予測。だがその時には、Accountabilityが大切になるし、裁定の理由を説明できなければいけないだろう、との意見には感心した。

もう一人のキーノート講演者・Nicholas Epleyシカゴ大教授の "Mindwise: How We Understand What Other Think, Believe, Feel, Want”もなかなか興味深かった。Epley教授はまさに行動科学者で、マスコミにも頻出する有名人である。彼はさまざまな心理学実験から、わたし達人間が、いかに他人と理解し合えていないかを説明する。にもかかわらず、わたしたちは、「他者に理解してもらっている」と過剰に自信を持っていることが、実験から証明できる。このギャップこそが、われわれのコミュニケーションに横たわる最大の問題点だ、というのが彼の解説である。

一般講演の中で一番面白い、と個人的に感じたのは、Andy Silberというコンサルタントによる、"Adaptive Project Management: Leading Complex and Uncertain Projects"という講演だったかも知れない。Silberは、ハードウェア製品開発プロジェクトの専門家である。彼は縦軸に複雑性、横軸に不確実性をとって、プロジェクト方法論を分類していく。まず左下に「最小限の計画」を位置づける。つまり出たとこ勝負だ。縦軸の不確実性とは、プロジェクトの規模をある程度、表す。だから、左上に「ウォーターフォール」をとる。大規模な建設プロジェクトが、その好例だ。そして、クリティカル・パスはPMの重大な関心事となる。

一方、彼は右下に「アジャイル」をおく。アジャイル開発は、要求仕様の不確実性に対応する、良い方法だ。ただし、これはITプロジェクトの一部にしかうまく適用できない。同じ製品開発でも、ハード系になると、長納期の部品調達などにプロジェクトが引きずられるからだ。そこで彼は、右上の象限に、 "Adaptive PM"をおく。ハードの製品開発がここに位置づけられる、というのはなかなか良い。
e0058447_12502596.jpg
Adaptive PMでは、"Replan often"(しょっちゅう再計画)という漸進的なアプローチをとる。この点では、アジャイルに似ている。しかし長納期部品などクリティカル・パスにもフォーカスする必要がある。そこで、フェーズ化されているが、フェーズを一部やり直しながら進める方法をとる、という。これによって進む方向をアジャストしていくのだ。これを通称「刺身モデル」という。なかなか面白い。そして、今回聞いた中で、これが一番、ハードスキル的な話だった。

他にも、Brian Clausenという人の"Design Thinking”の講演、Andy Kaufmanの"Decision making”の講演、
人間類型を用いた"Business Chemistry”の解説、パワポを使わずにプレゼンしようという講演、そして米国企業で働くインド人による、異文化の問題の講義など、興味深い講演が多かった。


5. PMIは、そしてPMの世界はどこに向かうのか

今回のPMI世界大会でのセッション全体をみると、Agile関連の話題がわりと多い印象である。また、Design Thinking(デザイン思考)もいくつか眼についた。

これは結局、プロジェクト・マネジメントにおける”How”(コストやスケジュールなどをいかに計画しコントロールするか)の問題から、”What”(プロジェクトで何を生み出すか)に、関心が移行していることを示しているように思われる。別の言い方を借りれば、"Do things right”から、"Do right things”へ、ということである。

わたしは2003年に、ボストンでProject Worldというカンファレンスに参加したが、その時はハード・スキルや方法論の話が多かった。そして、非常に勉強になったという記憶がある。分野も、医薬品もあればITも防衛産業もある、という感じだった。ただし当時はまだ、米国全体で、Program以上の上位概念への関心が薄かった。

それから12年後、2015年のProject World Bostonは、かなり様変わりしていた。まず、BA(Busines Analyst)団体の大会との共同開催だった。これは、もはやIT ProjectがPM界の主体となったことを示している。その流れは、PMIによるBusiness Analysisの標準制定などの動きにも通底している。

察するに米国では、ハード・スキルの教育普及はおそらく一巡したのだろうと考えられる(その点、日本とはまだ事情が違う)。そして、ソフト・スキルに関心が移ったのだ。

こうした変化は、米国の経営学の歴史の流れをなぞっている、ともいえる。ちょうど100年前、米国でテイラーが「科学的管理法」を提唱したとき、それはハード・スキル中心だった。それはフォード・システムなど自動車産業での応用に結実していった。しかし、1930年前後の有名な「ホーソン実験」以後は、モチベーション理論へと経営学の焦点が移っていく。すなわち、リーダーシップなどソフト・スキルへの注目である。日本風にいえば、理系的な経営工学から、文系的な経営学へのシフトだった。

そして'80年代以降は、金融工学への傾斜があった。つまり、経営における関心事が、
 科学→人の心→お金
という風に、アメリカではシフトしていったのである。

米国におけるPMの分野でも、科学から人の心へ、という方向性が感じられる。CPMやEVMSなど、技術とツールは整った。プロマネもPMBOK Guideで知識を得て、PMPの資格も取った。だが、プロマネの悩みは、あまり解決されていないのである。ハード・スキルの普及によって、プロジェクトの短期的な成功率は上昇した(これは米国IT分野の統計が示している)。だが。望んだアウトカムは得られていない。そのもどかしさ・不満感が、伝え聞くようなPMIの会員数の伸び悩みにつながっているのではないか。

もう少し問題をさかのぼると、PMBOK Guideの枠組みとその限界に突き当たる。PMBOKは周知の通り、「プロセス」を中心にして、プロジェクト・マネジメントの仕事を整理した。それはじつに見事な体系化だったと思う。また、とくに初期のPMBOKは、受注型プロジェクトを無意識に前提としていた。つまりScopeは顧客からSOWで与えられていて、かなり固まっている、という前提である。これは防衛宇宙産業やエンジニアリング産業では確かにその通りだが、そうでない種類のプロジェクトも世には多い。

プロセスとは、How(いかに)を記述するものだ。だが、本当にプロセス中心アプローチで、望む成果が得られるのか。それが今の多くの人の悩みなのではないか? そこでデザイン思考やアジャイルなど、Whatを明らかにする技法に脚光が当たっている。だがWhatを掘り下げていくと、そもそも、何を目的とし、何を価値としてプロジェクトをやっているのか(Why)の問題に突き当たる。

 How→What→Why

こう考えていくと、現在のPM理論のパラダイムには、大きな革新が必要だと分かる。そして、そのブレイクスルーとなるのは価値論であろう、というのがわたしの信条である。当然ながら、これには異論もあろう。だから、そういったオープンな議論ができる場を、わたしは作りたいのである。


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

書評:「ビルマ万華鏡」 土橋泰子・著


著者の土橋泰子氏は、外務省研修所ビルマ語講師で、おそらく日本きってのビルマ語・文化理解者の一人と思われる。彼女は1954年(昭和29年)に大阪外語大に入学し、在学中にラングーン大学に留学する。まだ「大学なんか行くとお嫁のもらい手が無くなる」などと言われていた時代だった。しかも当時、日本の国には外貨がほとんどなかったため、外貨持ち出し制限により、海外旅行や留学はたとえ自費でも国の許可が必要だった。

ましてビルマは第二次大戦中、日本が戦争で大変迷惑をかけた国でもある。そんな相手国から、招待を受けて留学した人は、著者が初めてだったろう。さいわいビルマはデリケートで優しい文化をもった国である。対日感情は一般に決してよくなかったと思われるが、それを直接本人にぶつけるような人はいなかった。だからこの本は、その楽しかったラングーンでの、女子学生寮時代の思い出からはじまる。

大学は厳格な教育だったし、ビルマ文学はかなり高い完成度を持っているので、勉学は苦労だったようだが、皆がおかずを持ち寄って、車座に分け合う寮の生活は楽しそうだ。「持っているものは何でも人と分け合う、これがビルマではもっとも大切なルールです」(p.40)という。

ところで、本のタイトルにもなっている「ビルマ」という国名について、著者は最初にこう書く。

「ミャンマーという国名は、あの国がよんできた正式の国名で、いわば文語体的呼称です。そして元々、口語体で自国を呼ぶときは、バマーといっていたのです。19世紀、英国がミャンマーを植民地支配したとき、それが『バーマ』(Burma)と発音され、日本に伝わって『ビルマ』になったというわけです。

(中略)イギリスとか、インドとかいう呼称も日本人だけの呼称ですから、日本式にビルマといっても別に構わないというのがわたしの立場です。ミャンマーと呼べば現政権支持(出版当時は中国寄りの軍事政権)、ビルマなら現政権非支持という考えの方もおられるようですが、そのような政治的意味はないことを予めおことわりしておきます。」(p.4)

ビルマBurmaをミャンマーMyanmarに呼び直してくれ、と世界に要請したのは軍事政権だ。だが、それは「ジャパン」といわずに、これからは「ニッポン」と呼んでくれ、というのに等しい、という訳だ。だが、それが瞬時に政治的記号に読み替えられてしまう点に、この国が現在いる立ち位置の難しさがある。

本書はしかし、政治や外交面での解説みたいなことはほとんど略し、著者が自分の目で見て知り、我が身で体験・実感した文化面のことがらを書いてくれている。ビルマの古典文学からはじまって、ことわざ、信仰、価値観、歳時記、料理、民族(ビルマは多民族国家だ)、服飾、度量衡・・と、きわめて具体的で幅広い。また2000年代に入ってから訪れた秘境・ナガ丘陵の旅行記も、とても印象的だ。

ちなみにビルマ人には名字が無く名前だけだが、その名前は生まれた日の曜日に従ってつけられる、といった習慣は、聞かないと分からないが、なかなか面白い。なお、ビルマ出身で国連事務総長になったウ・タント(U Thant)氏という方がいたが、この人の名前の最初についている「ウ」は男性の尊称を表す(女性の尊称は「ドォ」)。また、Thantの最後のtは読まないので、この人の名前はじつは「タン」さんなのである。

その、ウ・タントことタン氏は、東西冷戦とベトナム戦争の’60年代に、国連で平和のために尽力する。ちょうど著者も60年代にニューヨークに夫君と一緒に赴任していたため、知遇を得たという。だが、あいにく故国でネ・ウィン大将が、軍事クーデターを起こす。ただしNYで国連事務総長をつとめる彼だけは、軍事政権も逮捕・投獄することができない。かくして、反体制派を支援する立場になって奔走しつつ、病魔に倒れた彼の晩年の姿を描写して、本書は終わる。

軍事政権が民政移管を決め、にわかに東南アジア最後の新市場として注目を集めるミャンマーだが、お金や人口や経済成長といった数字だけを通してこの国を見るのではなく、血の通った人たち、それも高い文化を持った人達の国として、立体的に理解するために、とても良い入門書である。この国に関心を持つ全ての人に、広くお勧めする。


# by Tomoichi_Sato | 2017-10-24 23:31 | Comments(0)

マネジメント・テクノロジーを考える場にようこそ

このほど、新しく「マネジメントのテクノロジーを考える」というサイトを立ち上げた。

新サイトの目的は、マネジメント・テクノロジーのための情報源とすることである。そのために、2000年4月からずっと開設運営してきたわたしのサイト「革新的生産スケジューリング入門」のコンテンツを、全面的に移行した。SCM・BOM・PM・ITなどに関わる数百の記事がある。これに加えて、個人的に書いてきた「気まぐれ批評集」なども移してある。

このサイトは、近いうちに、マネジメント・テクノロジーを学ぶコミュニティのためのプラットフォームとして、拡張していきたい。現在、わたしが主宰している『プロジェクト&プログラム・アナリシス研究部会』の「PM教育分科会」では、世に類例のない新しいタイプのPMトレーニングを開発中である。これに関連するフォーラムや、e-Learningなどを今後、立ち上げたいと考えている。とはいえ、こちらはまだ構想段階なので、現時点ではわたしの個人コンテンツ集の体裁になっている。

新サイト開設に伴い、さらに二つほどやろうと思っていることがある。

第1に、本サイト(brevis.exblog.jp)の最新の記事を届けるために、メーリング・リストをはじめるつもりだ。これにより、いちいち見に来なくても、新しい記事がお手元に届くことになる。

もう一つ。過去に書いた数百の記事の中から、マイ・ベスト・セレクションを選んで、電子書籍化することを考えている。もちろん、メーリング・リストに登録してくださった方々には、先着順で無料進呈するつもりである。詳しい案内は、また後日させていただこう。

ところで、タイトルに使った『マネジメント・テクノロジー』という言葉は、一般用語ではない。世の中には「固有技術」「管理技術」の区分があるが、後者のカタカナ版というつもりで使っている。管理技術のままでも良いのだが、「管理」という日本語は英語のManagementよりも曖昧性が高い上に、その高圧的なニュアンスを嫌う人も少なくない。そこで、英語風に言いかえたのである。

元々この言葉は、わたしの勤務先の同僚・秋山聡氏が使い始めたもので、わたしもお借りして使わせていただいている。だから、Googleなどで"Management technology”と検索しても、そのものズバリのサイトは、なかなか出てこない。○○マネジメント技術、たとえばdata management technologyといったものはヒットする。また、Management of technology(MOT=技術経営)関連のサイトは、いくらでもある。だが、わたしの意図するマネジメント・テクノロジーは、技術の経営とは全く異なる概念だ。

マネジメントという言葉は多義語だが、その中核には「人を動かす」という意味がある。人に働いてもらって、あるいは、人と一緒に動いて、共通の目的を達する。このための技術を、マネジメント・テクノロジーと呼ぶ。

人が働く場合は、通常、それにともなって情報や物のやりとりがある。したがって、物の数量、品質、置き方、動かし方、などにかかわる技術も必要だ。情報やデータのインプット、伝達、蓄積、処理などの技術も大切になる。

そしてもちろん、お金に関わることがら、つまり見積や予測、集計にも技術がある。また、時間に関わること、所要期間の見積、集計、納期の予測も技術の対象だ。なによりも、人の集団としての組織を、どうデザインし、統率し、成長させるかという大きな難しい課題もある。

こうした事柄に関する技術は、分野・業種にかかわらず共通性が高い。たとえば在庫理論はマネジメント・テクノロジーの一種だが、在庫しておく対象が、石炭だろうがPCだろうが、共通に使える。最近流行の言葉に、<競争領域>と<協調領域>という用語があるが、共通性の高いマネジメント・テクノロジーは、後者に属するといえるだろう。

ただし、こうしたマネジメントに関する知恵は、従来バラバラに存在していた。在庫理論、会計学、品質工学、情報システム、人材開発・・という風に。

大事なことは、そこに「システムズ・アプローチ」という心棒を通すことだと、わたしは考えている。時間・品質・在庫・コストなどの項目は、バラバラに存在し、バラバラに管理できるものではない。製造業のQCDをみれば分かるとおり、品質とコストと納期は、互いに関係している。品質を上げようとするとコストがかかり、低コストでやろうとすると納期が延び、と言う風に。互いに制約し合っていると言ってもいい。

その一番わかりやすい例が、プロジェクト・マネジメントだ。現代のPM理論は、1950年代に米国で生まれた。プロジェクトを、単位作業(Activity)のネットワークで構成される「システム」だ、と考えたときにモダンPMの理論と手法が誕生した。だから、上に述べたわたし達のPMトレーニング・カリキュラムでは、プロジェクトを「システム」だと実感することに重きを置いている。

そもそも、マネジメントの能力は、生まれつきの才能でもないし、「気合い」だけで増大する物でもない。技術(テクノロジー)によって増大する、という思想が、わたし達のよりどころである。ただし、人が持つ能力は、かなり移転可能な部分と、どうしても属人的な部分に分かれる。これを、ハード・スキルとソフト・スキルと呼ぶ。

ハード・スキルとは、技術と理論を中心とした、座学で習得しやすい能力である。これに対し、ソフト・スキルとは、問題解決や交渉力といった、繰り返し練習によって身につく能力である。

そして、この両者を支える思考と行動習慣の体系を、OSとよんでいる。2年前に上梓した拙著『世界を動かすプロジェクト・マネジメントの教科書』では、この考え方に立って、以下のような「S+3K」がOSとして大切だ、と表現した。

 S: システムズ・アプローチ
 第1のK: 言葉を大切にする(言語化)
 第2のK: 契約と責任を重んじる(契約責任制)
 第3のK: かならず計画を立てる(計画重視)

ちなみに第2・第3のKは、とくに海外プロジェクトで重要になる要素だ。しかし、PMの観点だけでなく、より一般的に、システムズ・アプローチを内部から支える要素をあげると、以下の3点を大切にする態度になるのではないか:

  • 言葉
  • ロジック(論理・法則性)
  • 記憶(経験・歴史)

これはたとえば、あなたが上司や顧客としていだきたくない人物像を考えると分かる。まず、言葉をぞんざいに扱う人たちは、正直、あまりありがたくない。言っている意味が通じない人、意味内容がすぐ変わる人、逆に、狡猾に言葉をすり替える人などなど。

二番目にこまるのは、ロジックを無視する人だろう。1+1を、3とか5にしろと主張する人。仕事のパターンや傾向、法則性を無視する人。そして何でも「気合いと根性」だけで押し切る人たちだ。つまり、論理を「面倒くせぇ」で片付ける人である。顧客として上司として、あまりお相手をしたくないタイプである。貴方の周囲でも、見かけることはないだろうか。

そして敬遠したい三番目のタイプは、記憶しない人たちである。つまり、過去の過ちをすぐに忘れる(忘れたふりをする)人、約束や主張をしょっちゅうクルクル変える人、記録を軽視し、なんでも記憶と印象だけに頼る人。こういう人達は、できればリーダーに戴きたくない。

さて、前述のPMトレーニングについては、すでに6月と9月の2回にわたり、研究部会の内部でボランティア受講者を募り、改良を加えてきた。順調にいけば来年初頭あたりから、お披露目できるだろう。そして、これはわたし達が考える、「マネジメント・テクノロジーとしてのPM」の最初のカリキュラムになる予定である。

このコースは、プロジェクト・マネジメントの「初級者を対象とする」というつもりで設計し、参加者を募った。ところで、最近気がついたのだが、この「初級」「中級」という概念自体、もう少しきちんと定義すべきだったようだ。たとえば世間のPM資格試験では、プロジェクト実務経験年数や時間数などに準拠しているが、はたしてそれは妥当なのか?

分科会の中で議論するうち、わたし達はもっと別の定義の方が、ふさわしいと気がついた。それは、以下のような簡単なものである。

マネジメント・テクノロジーにおける初級者とは、自分でなんとか実行することができる人を指す。言われたことをそのとおり実行する場合も、自分で考えてやってみる場合もあるだろう(もちろん、言われてもできない人は、入門以前である)。

これに対し、中級者とは、他人に教えることができる人を指す。すなわち、自分の関わるマネジメントの手順・技術について、言語化でき、また元となる理論や定石を理解しており、それを実例と共に伝えられる人である。

そして上級者とは、新しいやり方を開発できる人である。
e0058447_07504975.jpg
このように定義してみると、いろいろなことがすっきりする。たとえば、何年間、いや何十年間も、実務経験を積んでいても、人を教えることをせず、ただ「俺の背中を見て育て」という人は、まだ初級者なのである。その人の中で、やり方が言語化・定式化されていないからだ。その人自身は、マネージャーとして高い能力を、あるいは持っているかも知れない。だが、その技能が個人に属するだけなら、組織はその人のレベルを超えることはなくなる。

つまり、個人のテクニックは、いくら積み上げても、移転・共有可能な「テクノロジー」にはならないのだ。シニア世代の引退を控え、あちこちの職場で若手への「技術移転」が課題となっている。しかし、そもそも移転可能な形になっていないままでは、誰が受け取れるだろうか?

教えることは、じつは自分も学ぶことだ。教えるのが一番、勉強になる。それは多くの人が経験したことだと思う。もしかするとわたし達の社会は、年を経た、ベテランの、しかし初級者ばかりでできているのかもしれない。

せめてわたし達は、はやく中級者になろう。


# by Tomoichi_Sato | 2017-10-20 08:21 | ビジネス | Comments(2)