<   2016年 01月 ( 6 )   > この月の画像一覧

魚心あれば水心 − 最適なペアを決めるマッチング・アルゴリズムの話

Apple初期にMac OSを開発した中心メンバーに、アンディ・ハーツフェルドという伝説的なプログラマがいた。Appleを退社後、独自にSwitcherというユーティリティ製品を開発するのだが、これはシングルタスクだったMacOS上で、複数のアプリを同時に動かせるという独創的なソフトだった。ところで以前、彼のインタビューをよんでいたら、彼が人生で最初に作ったプログラムが、高校のダンスパーティーの男女ペアを自動算出するものだったと書いてあり、笑ってしまった。世界中どこにいたって、魚心と水心の組み合わせは、つねに揉め事の種なのだ。

男女のお見合いから、研究室の配属、そして就活の就職先選びまで、世の中には「求める側」と「与える側」の組み合わせ問題に満ちている。あるいは、デマンド側サプライ側、と言いかえてもいい(男女のどっちが供給側かはともかく)。その典型は、サプライチェーンであろう。需要と供給をどうマッチングさせるのが最適なのか。最適とは、ここでは「お互いに満足度が高い」という風に規定しておこう。

「部分最適から全体最適へ」というのは、SCMの標語でもあった。では、最適なマッチングを具体的に決めるには、どうしたら良いのか? こうした問いに答える研究分野があることを、恥ずかしながらわたしはつい最近、初めて知った。

それを学んだのは昨年11月に、沖縄で開催された経営情報学会に参加したときである。たまたま「マーケットデザインとその周辺」というオーガナイズドセッションに講師として呼ばれ、そこでご一緒した大阪大学の安田洋祐先生と、電通大の岩崎敦先生から、「マッチングメカニズム」論の初歩と、ゲール=シャプレイ・メカニズムとよばれる仕組みのお話しをきくことができた。さらに、こうした研究の業績によって、シャプレイ教授は2012年にノーベル経済学賞を受賞したこともうかがった。そこで今回は、その時の印象的な講義をふりかえりながら、おさらいのために少し一緒に勉強してみたい。

ゲール=シャプレイ・メカニズムとは、マッチング問題を解くための基本的なアルゴリズムである。マッチング問題は、パーティでの男女の組み合わせに象徴されるように、デマンド側とサプライ側が互いに相手への好みを持つ場合に、より満足度の高い組み合わせは何か、という問題だ。ゲール=シャプレイ(GS)メカニズムは、その最適解を生成する手順である。

ここで、まずマッチング問題の前提を少し整理しておこう。まず、何らかの場があって、そこに
- デマンド(需要)側
- サプライ(供給)側
が同数いる。ここでは仮に、男の子がデマンド側で、女子がサプライ側としておこう。それから、誰もが相手に対する好みの順番(『選好順序』)をもっている。が、それは相手側には直接、分からない。また、この選好順序は、ジャンケンのような循環順序ではない、とする。満足度は数値化できないかもしれないが、とにかく優劣は決められるのだ。そして、他に特段の制約条件はない、とする。つまりお金持ちの子が最初に相手を選べるとか、貧乏人はペアを組めない、といった例外はもうけない、フェアな世界だとする。

GSメカニズムの基本的手順は、以下の通りである:
 デマンド側が、自分にとって最高順位のサプライ側にマッチングを申し込む
 サプライ側は、自分にとって最高順位のデマンドを「キープ」し、あとは拒否する
 デマンド側は、拒否されたら次の順位のサプライ側にマッチングを申し込む
 サプライ側は、より選好順位の高いデマンドが来たらキープ相手を変更する
 デマンド側がすべて受け入れられた状態になったら完了
この手順が最後まで行き着いたら、結果は自動的に最適状態になっていることが、数学的に証明されている。最適状態とは、どのペアを取り替えても、これ以上満足度の増える組み合わせが存在しない、というほどの意味だ。

非常に単純・明快な手順ではないか?

ゲールとシャプレイは、「大学入学と結婚の安定性」(1962)という、ちょっとふるった名前の論文で、最初にこの研究成果を明らかにした。この問題は、学問の地図でいうと、経済学という大国の中の、ミクロ経済学州にある、ゲーム理論という大都市の中に位置する。そこには数学国出身の賢そうな人々が多く住んでいる。わたしのように化学工学という小国出身で、今はプロジェクト・マネジメント論というもっとマイナーな地方都市にうつり住む者にとっては、縁遠い土地柄である。ま、自分が知らなかったことへの妙な良い訳はともかく、50年も前の知見を、今ようやく学んでいる訳だ。

このGSメカニズムは、現実の制度への豊富な適用事例をもっているのも特徴だ。たとえば日本では、2003年度から、臨床研修医を病院へ配属するためのマッチングの仕組みとして実際に使われている。また、 早稲田学院から早稲田大学の各学部への配分メカニズムも、そうなのだという。もっとも、わたしはGSメカニズムの仕組みをきいて、思わず触媒表面上の活性点で起きている分子レベルの化学反応メカニズムを連想してしまった。とういことは、自然界でも、これに似た仕組みがあちこちで動いているように思える。さすがである。

なお、マッチングが1対Nで、定員があったりする場合、GSメカニズムは次のような手順になる。
2 サプライ側は、定員まで「キープ」し、あとは拒否
4 新たにデマンド要求があった場合、サプライ側は選好順序に従って「キープ」を入れ替える

ところで上記の手順、きいてしまえば当たり前な内容、にも思える。どこが独創的なんだ? 数学的な証明はたしかに簡単じゃなさそうだけれど、普通、こうしてるじゃないか?

ところが普通は、上記のGSメカニズムとは、ちょっとだけ違うことをやっているのである。そして、そのちょっとだけの違いが、大いなる影響を生み出しているのだ。

世の中で普通にやられているのは、希望順位優先方式とよばれる方法である。別名を、「ボストンメカニズム」ともよぶ。ここでは、就活生の企業への就職を例にとって説明しよう。簡単のため、世の中に学生は全部で5名、企業は3社だけとする。世の就職関連業者がきいたら泣き出しそうなほど、シンプルな社会である。 学生の名はA・B・C・D・Eで、成績もこの順番である。企業はX社、Y社、Z社とする。なお、X社は大企業なので、募集定員は3名である。YとZ社は1名ずつだ。

希望順位優先方式(ボストンメカニズム)では、次のような手順で、就職者を決める。
1 全学生の第1希望において定員を満たすまで、企業は成績順に内定を決める
2 内定されていない学生と、定員の残る企業で、次の希望順位について1を繰り返す
シンプルだし、現実に、ほとんどのケースではこのようなマッチングが行われている。

だが、この手順ではまずいことが起きるのだ。それを「戦略的選好」とよぶ。

いま、学生の就職したい企業の順番(選好順序)は、以下のようだったとする。
Aさん、Dさん、E君:  X>Y>Z
B君、Cさん: X>Z>Y

ボストンメカニズムを適用すると、こうなる。
第1ラウンド:全員がX社を志望する。そこでX社は上位3名の、A・B・Cの採用を決め、内定を出す
第2ラウンド:DさんとE君は、第二志望のY社に志願を出す。Y社は、成績が上のDさんを内定する
第3ラウンド:E君がZ社に内定して、完了。
この結果、E君は、自分の希望順位では最低のZ社に就職することになる。

それが競争原理・弱肉強食のこの世の宿命だろう、って? ところが、である。E君はここで奸計を思いつく。彼は内心を隠して、自分の選好順位は「Y>X>Z だ」という風に振る舞うのである。

するとどうなるか? 上記の手順をあてはめると、こういう結果になる(読者の皆さんも紙の上で、ご自分で追いかけてみてほしい)。
X社:Aさん、B君、Cさん
Y社:E君
Z社:Dさん
おわかりだろうか? E君は次善のY社に就職し、正直だったDさんが割をくうのだ。

つまり、希望順位優先方式(ボストンメカニズム)は、嘘に弱いのだ。嘘をついた者が得をして、正直者が損をする。これを「戦略的選好」の問題とよぶ。この例では、嘘をついたことによる利得は所詮たいしたことが無いが、もっと深刻な例だって考案することができる。このような制度設計をしてはいけないことは、社会的に明らかだろう。

ところがGSメカニズムでは、「本音を言う」のが最適戦略になるのだ。ためしにGSメカニズムで上の例を追いかけてみると、E君が本音を言おうが嘘をつこうが、結果としては
X社:Aさん、B君、Cさん
Y社:Dさん
Z社:E君
となることを確かめてほしい。

GSメカニズムでは「戦略的操作」(つまり嘘)は有効にならないことが、数学的に保証されている。なぜ、その違いが生まれるかというと、GSメカニズムでは「仮にキープ」するが、後になってひっくり返すことを認めているからである。つまり、『内定取り消し』が公式に許容されているのだ。ボストンメカニズムでは、決定は先着順であった。ここが違うのである。

もっとも、GSメカニズムにも、弱点が無い訳ではない。たとえば、意図して嘘をつく訳ではないが、自分の選好順位とは反する選択をするような、非合理な人間が出てくると、うまく機能しなくなる。好みに反する選択をするとは、すなわち、自分が何を志望し、何をしたいのか、自分でもよく分からない人たちである。

いや、若い内には、そもそも自分が本当に何をしたいのか、何に向いているのかなど、自分でも分からないのが当たり前なのだ。いわゆる「自分探し」である。そして、むしろ周囲の方がよほど客観的に、向き不向きを見抜いていたりする。しかし、当たり前のことだが、いつまでも「仮決め」でふらふらしていると、肝心のパーティーでダンスが踊れなくなる。誰とも踊らないうちに、歳をとってしまうだろう。それに魚心あれば水心、一緒に踊っている内に、相手への選好順序がせり上がったりするのも、人間の心理なのだ。

ゲール=シャプレイのアルゴリズムはすばらしい数学的成果である。だが、それは各人の選好順位が固定したものだという前提の上に成り立つ、一種のスタティックな最適化手法だといえよう。わたし達が現実からいろいろなことを学び、それによって価値観が変化していくような、ダイナミックな場合の最適なメカニズムデザインは、まだまだこれから考え抜いていかねばならないのだ。


参考
安田 洋祐:「経済学で理想のパートナーを探そう! ゲール=シャプレーアルゴリズムを合コンのマッチング問題から考える」 東洋経済オンライン 
上田 俊(九州大学):「ゲーム理論 アドバンスドトピック
by Tomoichi_Sato | 2016-01-31 20:32 | 考えるヒント | Comments(0)

講演のお知らせ:「生産スケジューリングの基礎とリードタイム短縮」(3月24日)

3月に、生産スケジューリングとリードタイム短縮をテーマとした研修講演を行います(有料です)。

わたしは長年、エンジニアリング会社で国内外の工場・プラント作りに関わってきました。また、それなりに数多くの工場も見てきましたが、しばしば疑問を感じるケースがありました。「なぜ、こんな所に在庫を持つのだろう?」「ここを工夫すれば、もっと効率よく、かつ楽に仕事ができるはずなのに」「どうしていらないモノはたくさんあるのに、必要なモノは欠品しがちなのか?」

それは端的に言うと、生産活動の仕組み=『生産システム』の基本デザインに問題があるからです。生産活動のシステム・エンジニアリングが欠けているのです。むろん、ここで言うシステムとは、コンピュータのことではありません。情報系も一要素ですが、むしろ働く人々と、機械設備と、それを包む建築空間のことをいっています。その生産システムは、さらに自社を取り巻くサプライチェーンの特性に応じて、適切な機能構成を選ばなくてはなりません。単に、業績の良い他社の物真似をしても、生産形態が違えば役に立たないのです。

このサイトに何年か前、「あなたの会社にトヨタ生産方式が向かない五つの理由」という記事を書いたのは、そうしたことを訴えたかったからです。さらに、これをふくらませた形で、中小企業診断士仲間との共著「“JIT生産”を卒業するための本」第5章に、生産システムの考え方を詳しく説明しました。この講演を引き受けたのは、これをより多くの方に直接、お伝えしたかったからです。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理・原則に関する体系的な理解を重視しています。そのため、生産システムをより良く運用するにはどうしたらいいか、より上手に設計するためには何に留意したらいいを考える『システムズ・アプローチ』をとります。したがって業種分野については、わりと間口を広くとってお話しできる点が特徴です。年1回行っているこの講演も5回目になりますが、今年はさらにバージョンアップしてお届けするつもりです。

普通の現場改善コンサルタントの講義に、飽き足りない気持ちでおられる技術者の皆さんのヒントになればと思っています。

生産スケジューリングの基礎とリードタイム短縮のポイント 〜演習付〜」(3月24日)

日時: 3月24日(木) 10:30-17:30
主催: 株式会社日本テクノセンター
     http://www.j-techno.co.jp
会場: 株式会社日本テクノセンター研修室
     東京都新宿区西新宿2-7-1 小田急第一生命ビル22F
     (都営地下鉄大江戸線「都庁前」駅または丸ノ内線「西新宿」駅)

生産計画とスケジューリング、リードタイム短縮について、事例と演習を含めてお話しします。

セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます)
     http://www.j-techno.co.jp/seminar/ID54JQV6P41

関心のある大勢の方のご来聴をお待ちしております。
by Tomoichi_Sato | 2016-01-27 23:51 | サプライチェーン | Comments(0)

マネジメントとリーダーシップはどう違うか

大学でプロジェクト・マネジメントを週1回教えていることは前にも書いたが、授業は毎回必ず、前回の復習と、学生から出た質問への答えからはじめることにしている。出席シートに質問欄を設けて、そこに気になったことへの質問をかいてもらうのだ。むろん授業でも最後に「質問は?」ときくのだが、だいたいの学生はなぜかその場では質問せずに、紙に書いてくる。

いろいろ出た質問の中から、いつも「本日のBest Question」を選出し、その質問者の名前を明示してほめることにしている。良い質問を考えることは、単に回答を考えるよりも、ずっと価値があるからだ。一般に、マネジメントの問題には正解がない。正解がない中で、自分で考えて決めていかなくてはならない。これは、たくさんの正解を覚えてどれだけ早く答えるかを競ってきた東大みたいなところでは、とくに大切だ。

さて、「マネジメントとは何か」という授業をやった後で、面白い質問があった。印象に残っているので、ここに引用させてもらおう。(以下引用)

Managementの再現性の取れなさ、うさんくささがずっと気になっています。『君にもできるプログラミング』と『君にもできるプロジェクト・マネジメント』という2冊のタイトルを並べてみると、後者の本に頼りなさを感じます。どうして理論が組み立てられているのに、現実の組織はこんなにもうまく機能せず、有能なリーダーはこんなにも稀なのでしょうか? (引用終わり)

とても立派な質問である。本日のBest Question賞にふさわしい内容だ。皆さんなら、どう答えられるだろうか? わたしの答えを読む前に、ちょっとだけ考えてみていただきたい。

わたしが話したのは、こんな内容だった:

「能力には一般に、確定的な能力と確率的な能力があります。成果が確実なものと、成果が環境その他の条件に左右されやすいもの、といってもいいでしょう。プログラミングというのは、前者に属します。知識を得て、一度できるようになったことは、次も必ずできる。ところが、マネジメントというのはそうではない。

それはたとえば、『航海術』というタイトルの本を考えてみれば分かりやすいと思います。教科書を読んで知識を得たからといって、つねに無事に航海できるとは限らない。天候、海象、航路、同乗する乗組員のスキル、船の状態など、さまざまな要因によって左右されます。たとえ同じ路線だろうと、まったく同じ行路をたどることはないでしょう。

では航海術などという本は役に立たないか? そんなことはない。船を操るためには、船の構造、操舵、エンジンの仕組み、海洋の物理、気象、地理と海図の読み方などなど、知るべき航海術の基本がいろいろあります。小さなボートなら、見よう見まねでもなんとかなる。だがちゃんとした大きさの船になったら、センスと勘だけでは正しく動きません。プロジェクト・マネジメントも同じです。」

さて。後半の「有能なリーダーはこんなにも稀なのでしょうか」という質問には、ちょっと注意が必要だ。この質問は、「有能なマネージャーはこんなにも稀なのでしょうか」ではないからだ。マネジメントをする人をマネージャーと呼ぶ。マネージャーが無能なのは、無能な船長が航海術の基本を知らないのと同じで、たぶんマネジメントの基本を知らないのだ。マネジメントは、学ぶことのできる能力だからだ。

だが、リーダーシップは能力だろうか?

『リーダーシップ』は多義語で、経営学でも定義はまちまち、確定した共通定義はない。ただ、リーダーはふつう、同種の人間集団の中から現れ、リーダーシップとは同格の仲間を導くことをいう。

たとえば、少年野球チームのキャプテンは、リーダーである。そして監督がマネージャーだ。リーダー(キャプテン)はいろいろなことを提案したり決めたりするだろう。そして仲間を引っ張るだろう。ところで最終的な指令権も責任も、監督の方にあるのだ。あるいは、オーケストラでいえば、コンサート・マスター(しばしば第一ヴァイオリンの主席奏者)がリーダーで、指揮者がマネージャーである。自主運営面では、コン・マスが皆を引っ張るだろう。しかし演奏では指揮棒に従うのだ。

マネジメントでは、会社の上司部下の関係を思えば分かるとおり、命令が出たら下は従わざるを得ない。もし命令に従わなかったら、懲戒とか減俸とか、あるいはクビを覚悟しなければならない。つまり、マネージャーは部下に対して強制力があるのだ。

ところがリーダーシップの特徴は、フォローする側が主体的に従う点である。チーム員がキャプテンに従うのは、従わないと後が怖いからというより、そうした方が良いと自分で思うからだ。つまり、リーダーが発揮するのは影響力なのである。だが、影響力というのは、能力なのか? 他人が、自主的に判断する結果を、左右できる「能力」というのは、なんだか自己撞着ではないか。

マネジメントとリーダーシップには、もう一つ重要な相違点がある。マネジメントは「システム化」できることだ。ISO-QMSの「品質マネジメントシステム」を見ればよく分かる。ISO9000を好きか嫌いかはさておき、あれが一つの体系(システム)であることに異論を持つ人はいないだろう。そして、このような「システム」は、それに関わる大勢の人たちを組み入れ、いわば束縛する。品質マネジメントシステムは、決して品質管理責任者だけの仕事ではない。

同じように、プロジェクト・マネジメントのパフォーマンスも、決してプロマネ一個人だけで決まるものではない。プロジェクト・マネジメントは組織の能力なのである。組織の中に、どれだけ標準的手順が整備され、ツールが構築され、過去のデータベースが蓄積されているかで、プロジェクトの成否は大きく変わる。

ところが、リーダーシップは基本的に個人に属するもので、「システム化」はそぐわない。

このように見てくると、マネジメントとリーダーシップは、似たような概念のように見えても、じつは随分と違う種類のものだと分かるだろう。異なるレイヤーに属するといってもいい。

ただ、そこには共通するものがある(そうでなければ、両者がしばしば一緒にされる訳がない)。それは、「人を動かす」という部分である。マネジメントも多義語だが、その中核ないし原義は「人に働いてもらって目的を達すること」だ。そしてリーダーシップも、行き先を仲間に示して導くことであり、人を動かす点が共通している。その力の源泉が、強制力なのか影響力なのかが違うのである。むろん、アメと鞭の強制力だけは誰にとっても鬱陶しいから、マネージャーもリーダーシップ的な影響力の行使を期待されるのだろう。図にすると、こんな感じだ。
e0058447_093270.gif

ところで、マネジメントとリーダーシップを調べたり論じたりする際に、注意すべき事がある。それは、米国ではマネジメントよりもリーダーシップの方が、ずっと高尚でポジティブに受け取られる傾向が強い点だ。だから米国では、「マネージャーであるより、リーダーであれ」といったたぐいの警句や格言が、とても多い。「リーダーは方向性を示す。マネージャーは示された方向性を実現するだけ。」とか、とにかくこの種の言い方はきりがないほど氾濫している。

米国以外の、英国を含む欧州ではあまりこうした傾向が強くないところを見ると、どうやら、これは米国特有の、文化的なバイアスらしい。これがなぜ生まれたのかは、わたしには定かではない。ただ、米国の経営学は世界で指導的地位にあるから(つまり「リーダー」だから)、その「影響力」は他の国の経営学にも時々見られる。とくに、米国からの学問成果の直輸入を尊ぶ国で、それは著しい。

もう一つ。マネジメントは、基本的にマネージャーが第一に持つべき職能である。ところが、リーダーシップは、必ずしもリーダーだけが体現すべきものではない。リーダーシップ概念が多義語ながらも包含しているもののなかには、
・自発的な強い意思を持つ
・他者を動かし、世界を変えられると信じる
・ゴール地点を決めて人を導く
といった思考と行動の習慣がある。

こうした部分は確かに有益だし、それはリーダーの地位にいなくても、いや、集団を構成する全員が、身につけるべきことだとも言えるだろう。自主性を持つこと、変化への意思を持つこと、人を動かす能力を持つことは、生きていく上で誰にも必須のスキルだからだ。とくに、市場経済も企業組織も巨大化し二極分化が進む今日、「その他大勢」として生きる我々にとって、とても重要だ。マネジメント能力がいわば航海術だとすれば、人々のリーダーシップはエンジンなのだ。風雨の激しいときは、しっかりしたエンジンが必要である。

では、そのようなリーダーシップを、教え育てることはできるのか? わたしはできると思うし、本当は初等教育の時から必要だと思う。それも、すべての人に対して必要だろう。世間では、リーダーシップ教育は、傑出したリーダー候補だけに授ける「帝王学」みたいな意味づけをしがちだが、それは違うと思う。(まあ、「世の中には生まれつき少数の優秀な人間と、命じられて動くだけの多数の馬鹿がいる」、という信念の人は同意するまいが)

ただし、リーダーシップのトレーニングは、知識伝授的な教育ではむずかしい。知的能力だけの問題ではないからだ。また、点数付けによるランキングにもなじまないだろう。つまり、今の学校教育(≒受験教育)の枠組みにははまりきれない、ということだ。

では、どこで、誰がやるのか。それは公的な教育システムの外側、共同体とか、私塾とか、そして社会の組織の中でやるしかない。リーダーシップはソフトスキルの典型であり、その育成には手間と時間がかかる。

でも、通常は組織の中のフォロワーの立場にいても、全員がきちんとリーダーシップを持ち、いざというときはリーダーにかわってチームを引っ張れるようなチームこそ、本当に高いパフォーマンスを出せる組織だろう。そういう場所では成員は、決して無責任な決断も発言もしないだろう。つねに「自分がリーダーだったら」という視点で考えることができるからだ。スーパーリーダーがその他大勢を動かす組織よりも、各人が自律的に動ける組織こそ、わたし達の組織文化にフィットするのではないかと、わたしは思うのである。


<関連エントリ>
 →「新任リーダー学・超入門(2) マネジメントとリーダーシップというコトバに気をつけよう!」(2011-06-13)
 →「リーダーシップを浪費する組織」 (2012-12-16)
by Tomoichi_Sato | 2016-01-25 23:57 | ビジネス | Comments(3)

プロジェクト・コスト・コントロールの中級編:実績コストACをいつ計上するべきか?

前回、プロジェクト・コスト・コントロールの入門編として、費用を正確に把握するためには、社内におけるプロジェクト制の確立と、WBSに基づいた実行予算の設定が重要である、と書いた。そこで今回は、現実のプロジェクトにおける、実績コストACの定義と、将来発生コストETCの推定方法について書こうと思う。というのは、この両者はいずれも、標準的な教科書に書かれている公式だけでは、十分に捕まえられないからだ。

まず、コスト・コントロールと言う仕事の目的を再確認しておこう。それは完成時のコストを、実行予算の枠内に収めることである。完成時の予測金額EACは、実績コストACと将来発生コストETCの合計で表される(EAC = AC + ETC)。実績コストが予定より超過している場合には、まだ手元に残っていて自由度のある予算残額をうまく用いて、今後の出費を抑える手段を講じる必要がある。つまり、早めで上手なお金の使い方を決めるということだ。早めに生きたお金の使い方をして、問題発生を先に予防しておけば、後で問題が生じてから慌てて対策するよりも少ない金額ですむ。

さてプロジェクトのコストを構成する費目は、大きく次の要素からなる。
1 社内人件費(労務費)
2 材料購入費
3 外注費
4 その他直接経費
5 間接経費
この分類は製造業の原価管理に準拠しているが、多くの業界で同じだと思う。

上記のうち、2番目から4番目までは外部費用である。したがって実績コストACは企業の経理部門で、確実に捉えられるはずのものだ。だから、世の中によくあるプロジェクト・コスト・コントロール用の情報システムでは、会計システムからのインターフェイスでこうしたデータを持ってくるような設計になっている。

ところがここには問題がある。実は、外部コストには3つの発生時点があるのだ。発注時、検収(請求)時、支払時の三つである。英語ではそれぞれ、Committed cost, Incurred cost, Paid costという。そしてこれら3つの時点の金額は、異なる可能性がある。

例えば何か機材を購入するときのことを考えてみればわかる。発注書を切った後で、仕様変更を行ったために、検収(請求)金額が変わる。あるいは、検収時点で納品物に齟齬が見つかり、支払い金額がさらに変更になる。こうした事はプロジェクトではよくある話だ。ではこれら3つの金額のどれが実績コストACにあたるのか?

おまけに、支払い自体、何度かに分かれる場合もある。発注書を切る時点で、着手時に1割の前渡金をわたして、納品時に残額というのも、しばしばある話だ。さらに、途中に支払いのマイルストーンをもうける場合もある。

ちなみに会計的には普通、注文時ではなく、検収をもって買掛金に計上する。逆に言うと、発注時にはまだ金額や役務内容は確定していないと考える訳だ。ただし、プロジェクトのキャッシュフロー的には、請求を受けたときではなく、実際の支払時に変化が生じる。

さらにいうと、発注時の前渡金はキャッシュフローに影響するが、会計的には原価ではない(対応する役務提供がないから)。受注側からも、売上計上はできないのである。

ついでながら、費目の中には、そもそも発注という行為自体ががない費目もある。たとえば、日頃つきあいのある業者から材料を購入する場合など、電話で注文して、いきなり納品書と請求書が来るのが普通だ。常駐派遣の人件費もそうだろう。いちいち毎月、発注書を切るわけではない。ただ、こうした費目には、検収行為はある。

さらに、発注も検収もなく、いきなり支払行為のみの費目も存在する。交通費・通信費など「その他直接経費」と呼ばれるもののほとんどはそうだ。さらに、社内人件費もこれに似ている。いずれも、実際に費用が発生した後でないと、把握できない。

え、頭がだんだん混乱してきた? まあ、そうかもしれない。だが、こうした現実のややこしい姿を理解した上で、実績コストACの適切な定義は何かを決めておかないと、実際のプロジェクト・マネジメントの役には立たなくなってしまう。だから中級編なのだ。

この種の問題を考えるときは、目的にさかのぼって確認する方がいい。コスト・コントロールの目的は、経理(会計)だろうか? それとも、キャッシュフローの管理だろうか? もちろん違う。完成時のコストを予算に収めることである。そのためには、予算に関する『自由度』の観点が必要になる。

予算の自由度の観点からいうと、発注書を切ってコミットしてしまったら、他にはもう使えないのだ。である以上、じつは一番早い発注段階で実績コストACをつかみ、計上するのが、目的にかなうということになる。もちろん、そのためには、発注予定との差異を検知できるように、コスト・ベースラインも発注時点での線を引いておく必要がある。

ところが、市販の多くのコスト・コントロール・システムは、発注時ではなく、検収時に実績コスト発生と定義している。これは、会計システムとのインタフェースの都合でそうなっているにすぎないと思う。おまけに世の中の文献でも、これに準じて検収額 Incurred costをACと定義してるものが多い。そこでこれ以降は、世の大勢にしたがい、検収額をACとして話を続けよう。

次なる課題は、今後発生するコスト(ETC)をどうやって推測するかである。

プロジェクトのアーンドバリュー法(EVMS)を解説した本では、たとえば、次の式が出てくる。

 ETC = BAC - EV

ここでBACとはBadget at Completion、すなわち実行予算での完成予定額を示し、EVとはEarned Value、すなわち出来高をいう。EVは、少し古い教科書ではBCWP(Budgeted cost of work performed)と書いてある場合もある。

例を挙げる。ここに元々、100万円で終わるはずの仕事があった(BAC = 100)。ところが実際にやらせてみると、今現在までにかかったコストは50万円だった(AC = 50)としよう。で、現時点の進捗は40%だ。つまり100万円の仕事の内、40万円分の仕事しか出来高は上がっていない(EV = 40)。そこで、今後発生するコストは、100 - 40 = 60万円だろう、というのが上の式である。

ただし。もし今までやってきた40万円分の仕事と、まだこれからやらなければならない60万円分の仕事が、まったく独立したWBS要素で、やる人も別で、これまでの実績とは関係ないというなら、それでもいいだろう。しかしもし同じ人や業者で行うとしたら、これまで40万円分の仕事を仕上げるのに、50万円かかってきた訳だ。だったら、今後も同じような調子で進むんじゃないか、と考えるのが現実的な感覚だろう。

ここで、コストパフォーマンス・インデックス(CPI)を、CPI = EV/ACで定義する。上の例だと、40/50 = 0.8だ。つまりこれまでの仕事ぶりは、当初考えていたより、8割程度の生産性しか上げられなかった。だとしたら、今後も同じ調子で、60万円分の仕事も、実際には60/0.8 = 75万円かかると見た方がいい。

 ETC = (BAC - EV)/CPI

これが、たぶんより現実的な推算式だ。と、たいていの教科書には書いてある。

しかし、上の式は、じつは適用対象に限定があるのだ。それは「スコープが柔らかい費目」だけに該当する。ここが中級編のポイントである。

スコープが柔らかいとは、どういう意味か。それは、コミット(発注)した時点で作業量の全体が明確ではなく、途中で増減があり得る種類のアクティビティであることを示す。逆に「スコープが堅い費目」とは、コミットの時点で、作業量の全体像がかなり明確なアクティビティである。

スコープが柔らかい費目の代表例は、実費償還契約(準委任、あるいはBQ精算など)による外部費用である。あるいは、設計などの社内人件費もこの部類に属する。こうした費目では、時間の経過とともに作業が進捗していき、少しずつ費用ACが確定する。図の左を見てほしい。たとえ最初に何らかの見積があり、それにしたがって発注(コミット)したとしても、その後、少し時ずつ作業が進み、順次、実績コストが上がってくる。
e0058447_21451232.gif

以前書いたように、『進捗』とは「あとどれだけ仕事が残っているか」で計測する。進捗とともに、残る作業量はより明確となり、それに相当する発注残額は減っていく。ただ、生産性の問題などで、検収した実績コストが予定より増えてしまうのは良くある話だ。いずれにせよ、このケースでは、EAC=検収額+発注残額 で推計される。検収額は確定したコストで、発注残額は比較的確実な将来コストである。

こうした費目では、コスト・コントローラーは、発注時には予定総額ないし上限を決めて発注すること、実績コストの発生をリアルタイムにつかむこと、そして進捗を精確に計測するため主要なメトリクスとあわせて把握する、などのテクニックが要求される。

他方、スコープが堅い費目では、別の見方をしなくてはならない。こうした費目では、作業が完了したときに、いきなり全体の検収額が上がってくることになる。途中のACはゼロなのだ。だから、あらかじめ、コミットした発注額に対して、この先に発生するかもしれない追加費用を、リスク項目ないし潜在的追加としてリスト化し、追いかけておく必要がある。図の右側にあるとおり、このケースでは、発注額Committed costは一種の確実な将来コスト Firm ETCである(まだ実績ACは上がってきていないから)。時間の経過とともに、潜在的追加もふえていくかもしれない。そして最後になって、当初の発注額に対して、追加金額(approved change)が決まる。

図では、会計的な実績コスト(Actual Cost)と、確実な将来コスト(Firm ETC)、そして不確実な将来コスト(Uncertain ETC)を色分けで区別している。だが、どちらも着目しているのは、それらの合計である完成予定額EACである。仮にもし、ACを検収額ではなく発注額で定義したとしても、単に色分けが変わるだけで、潜在的追加をきちんと把握しなければ全体が分からないことにかわりはない。

おわかりだろうか。長々と論じてきたが、ACとETCの区別などというのは、相対的なものである。それはコントロールの目的に応じて決めればいいのだ。大事なのは、完成予測における不確実な項目を、どうやって整合性をもって把握するかの方なので、ここをきちんと仕組み作りできてはじめて、中級レベルになるのである。


<関連エントリ>
 →「プロジェクト・コスト・コントロールのベーシック」(2016-01-11)
by Tomoichi_Sato | 2016-01-17 21:48 | プロジェクト・マネジメント | Comments(0)

プロジェクト・コスト・コントロールのベーシック

プロジェクトのコスト・マネジメントは、計画段階の仕事と遂行段階の仕事に大きく分けることができる。前者はコストの計画=プランニングの仕事で、具体的にはコスト見積および予算設定である。そして遂行段階の方は「コスト・コントロール」とよばれる。

このサイトを以前からよんでおられる読者の方はご存じかもしれないが、わたしは『管理』という日本語は基本的に使わない。かわりに、『マネジメント』とか『コントロール』といった、英語をカタカナ書きにした言葉を使うことにしている。カタカナ言葉の氾濫は好きではないが、管理という語が多義語で、あまりに曖昧な使われ方をするので、コミュニケーションで誤解を生みやすいためだ。誤解というのは、お互いに違うことをいっているのに、それぞれがちゃんと理解したと勘違いすることである。誤解はたんに話が通じないことより、始末に負えない。通じていないのは、その場で両者が分かるが、誤解は両者が気づかずに進んでしまうからだ。たとえば「原価管理」といった場合、片方はCost Managementというつもりで話し、他方はCost Controlの意味で理解する、といった具合だ。

英語でControlというと、何かの仕組みや対象を、きちんとチェックしたり意図したとおりに正確に動かしたりする、という意味になる。技術系の日本語で言うと『制御』に近い。たとえば工場の検査工程の仕事は、設計通りにモノが製造されているかをテストする仕事で、Quality Controlとよばれる。あるいは、空港で到着客のパスポートをチェックする仕事は、Passport Controlとよばれる。

一方、Manageという英語の動詞にはどこか、暴れ馬を乗りこなす、といったニュアンスがある。御しがたい相手を何とか従わせる、という風にである。なので、マネジメントという仕事の中には、計画や制御以外に、先読みとかリスク・テークとか決断と交渉といった行為が重要な要素となってくる。入国管理係官の仕事をPassport Managementと呼ばないのはこのためで、係官に個別にリスクテークや入国判断などしてもらってはまずいからだ。マネジメントというのは、コントロールの上位概念である。Quality Managementといえば、設計から品質検査までを含む品質の全体像を、なんとか思い通りにしていくことを意味する。

そしてコスト・コントロールとは、コストを意図したベースライン(実行予算)の中におさめていく仕事である。計画通りに収まるよう、モニタリングしながら制御していく。これがコスト・コントロールの目的である。ついでにいうと、英語のCostの方は、「原価」でほぼ誤解が無い。

実行予算の枠内にコストをおさめるためには、二つのことが必要だ。まず、現時点までにいくらのコストを実際に使っているのか。そして、このままでいくと、プロジェクトが完了する時点での最終的なコストはいくらになるのか。これを、コストの費目ごとに把握する。

月ロケットか何かにたとえるならば、現在位置の計測と、着地点の予測である。着地点はロケットの場合、発射時点でかなりの部分が決まる。しかし、航行途上でも大気圏の状況やらエンジンの燃焼具合などで、それなりに予定した航路からの変動がある。そこで、元々ねらった地点に進路をもどすべく、制御するのである。プロジェクトも同じで、コストの着地点は、最初の計画(=コスト見積)の良し悪しで、かなり決まってしまう。しかし、遂行途上でもいろいろな変動要因がある。すなわち、工夫の余地があるということだ。

ここで念のために書いておく。プロジェクトのコスト(原価)とは、つまり、かかる費用のことだ。受注金額(プライス)のことではない。コスト・コントロールのベースラインとなる数値というのは、プロジェクト計画において決めた、実行予算の内訳となる費目別の数値である。

こんな当たり前のことを書くのは、ときにこの両者が混同されているケースを見かけるからだ。たとえば費目の内の、外部発注の比率を議論するとしよう。いろいろな過去のプロジェクトの実績データを掘り出してきて、あのケースでは何%だったとか、比較する。この時の基準は、費用総額に対する比率を議論する必要がある。受注金額に対する比率であってはいけない。なぜなら、受注金額は販売戦略に応じて、意図的に上乗せしたり値引きしたりすることがあるからだ。ある成果物を作るのに、外注コストが6千万円だった。ただ、全部で費用は1億円かかった。だから外注比率=60%となる。かりにこの成果物を1億2千万円で売ることに成功しようと、競合のためやむなく9千万円の赤字で受注しようと、外注比率にかわりはない。

これはつまり、プロジェクト・マネージャーはコスト総額に責任を持ち、セールス側は販売金額に責任を持つ、という責任分担を意味する。そして、

 利益 = 販売金額 − コスト総額

なのだから、利益確保はプロマネと営業の共通目標であることを意味する。かりにやむなく9千万円で赤字受注をしたとしても、計画時点のコスト見積の総額である正味原価(Net Cost)は1億円であり、プロマネは1億円以内での達成に責任を持つべし、ということである。かりに社内組織の都合で、プロマネが営業マンを兼ねている場合でも、正味原価と販売価格は区別して考える。そうしないと、後々でコスト分析をして次の見積をするときに、基準となるデータが混乱してしまう。

プロジェクト・コスト・コントロールの仕事は、たった一つの式で表現することもできる。それは次の式だ。

 AC + ETC = EAC

ここで、ACとはActual Costの略で、すでに使った実績コストを表す。ETCはEstimate to Completeの略で、これから完了までに必要だと予測されるコストである。そしてEACとは、Estimate at Completionの略で、完成時点での予想金額を意味する。これらの略号は、今日の現代PM理論で標準的に通用している用語だ。

コスト・コントロールの仕事とは、上の式にあるように、三つの要素からなる。まずACすなわち実績出費を把握すること。つぎに、これからの出費であるETCを推定すること。そして着地点であるEACを計算し、元の目標であった実行予算の枠内に収まらなければ、対策を考えて講じる(普通はETCを下げる方策をとる)ことの三つだ。

ACの把握のためには、組織の出費がきちんと記録されていること、それがプロジェクト単位に仕分け可能になっている必要がある。つまり『プロジェクト制』が確立していることが望ましい。もちろん、どんな企業でも、経理と納税の義務がある以上、出費の記録はとられているはずだ。ただ、どの出費がどのプロジェクトの原価に対応しているかを、区別できるようになっている必要がある。外注先企業に案件Aも案件Bも案件Cもいっしょくたに発注、検収もどんぶり勘定、では、コスト・コントロールができている状態とは言えない。

かりにプロジェクト単位での出費の把握が可能でも、それが迅速に行われないと、やはりコスト・コントロールの役には立たない。日本企業では「月締め」の慣習が強いので、新春まだ松の内の注文も、1月末の注文も、翌月の2月15日頃にまとめて請求され、それが経理部門のチェックを終えて技術部門にフィードバックされるのは2月25日頃、なんて状況は珍しくない。費用が発生してから、実質的にそれが計上把握されるまで、平均1ヶ月くらいかかる。もしプロジェクト全体工期が6ヶ月程度なら、1/6 = 16.7%程度の遅れである。あなたは1日に4時間ずつ遅れていく時計で仕事を計測したいだろうか?(笑)

社内コスト、とくに人件費の把握も、コスト・コントロール実現のための次なるハードルだろう。当たり前だが、関係する社員全員が、きちんと精確にタイム・シートを記録している必要がある。それも、皆がタイム・シートを記入するのが月1回、庶務の担当者に尻をたたかれて慌てて入力、では上と同じだ。タイム・シートには、プロジェクトを識別する番号と、WBSコードが記入されていなければならない。

WBSコード? そんなのがタイム・シートに必要なの? ——はい、そうです。プロジェクト・コスト集計は、通常、計画時点で作ったWBSがベースになる。プロジェクト全体を作業(Activity)の集合体に分け、それを階層的に構成したものがWBS(Work Breakdown Strucuture)である。WBSそれぞれの作業に必要な費用を見積って、全体の実行予算が設定される。この予算額に対して、実際の出費と今後の出費予定がいくらになるのかを、それぞれの作業に対して予測する。それを集計したものがプロジェクト全体コストの着地点になるのだ。

つまり、プロジェクト・コスト・コントロールにおいて、WBSとはコストのロールアップ(集計)構造を示すのである。(→「WBSはコスト見積の基準を規定する」 2012/10/31 参照のこと)。である以上、何野誰夫君が1月第2週にプロジェクトAに使った32時間は、モジュールXの実装Acitivityの仕事なのか、それともインタフェースYの内部設計のActivityの分なのか、対応関係が分からないといけない訳である。

そうしない限り、「このプロジェクトAの時、内部設計と実装にかかった工数の比率は25:47%だったっけ?」という会話が、あとでできなくなるということだし、「要件定義以前と結合テスト以降を除いて、設計と実装についていうと、モジュールXは結局いくら工数がかかることになるのかなあ」という予測が不能になってしまう。

ところが会社というのは不思議なところで、何野誰夫君の32時間の内、残業割増分がつく残業部分は何時間だとか、彼の給料が毎月何円だとかいったお金の細部にはこだわるくせに、32時間が結局どのような仕事に費やされたのか、それは元々何時間分で見積もっていた仕事なのか、といったことはないがしろにされがちだ。お金にこだわるくせに、仕事の内容にはこだわらない。これでマネジメントだのコントロールだのができるはずはない。はっきり言って、プロジェクトの実務の世界では、個人別の給与や残業割り増しなど、どうでもいい。時間あたりの平均単価による標準原価で十分なのである。それより、100時間で終わるはずの仕事が200時間になるかどうかの方が、はるかに重要なのだ。

著書「世界を動かすプロジェクトマネジメントの教科書」https://gihyo.jp/dp/ebook/2015/978-4-7741-7625-3 にも書いたとおり、予算と進捗のコントロールというのは、ある意味で、プロジェクトを引っ張っているリーダーに対し、カーナビを提供する仕事にたとえられる。カーナビは、車のドライバーが運転に集中できるよう、位置測定や走路計算などの補佐してくれる。だからわたしの業界などでは、「コスト・エンジニア」という専門職が存在しており、大規模プロジェクトではプロマネの下に専任のコスト・コントロール・マネージャーというポストを置く。

そして、すべてのプロジェクトにおける見積・実行予算と、その実績データは、コスト・エンジニアリング部門に集約される仕組みとなっている。それが、次のプロジェクトの正確な見積のベースとなるのである。コストの話をすると、とくにIT系では見積手法の話題に関心が向かい、ファンクション・ポイント法だCoCoMoモデルだという議論になりがちだ。それも大切だが、1 Function Pointが、自社の組織では何時間の工数になるのかを推計する基盤は、自社の実績データしかない。より良い見積をしたければ、より適切な実績把握の仕組みを、まず考えるべきなのである。


<関連エントリ>
 →「WBSはコスト見積の基準を規定する」 (2012/10/31)
by Tomoichi_Sato | 2016-01-11 13:00 | プロジェクト・マネジメント | Comments(0)

変わりたいですか?

変わりたい、と思ったことはおありだろうか? 今の自分から脱皮したい、殻を割って変わりたい、“あの人は変わったね”と他者からいわれたい、と切実に思ったことは?——わたし自身は、もちろん何度もある。年の初めにあたって、今年こそは、と決心したことも一度や二度ではない。もしかしたら、新年にあたり、同じような抱負や希望を考えた人も多いのではないかと思う。

では、「あの人は変わったな」と感じた経験はあるだろうか? 他人を見て、ああ、あの人は以前と比べて随分変わった、そんな風に思ったことは? その場合、ふつうは外見とか職位とかの変化ではなく、内面やふるまい方のちがいを指すはずだ。髪型を変え新しい衣服を着たって、あるいは新しい名刺を振り回したって、それで他人から変わったと思われることは少ない。むしろ、話す内容が変わったとか、ふるまい方が随分ちがうとか、そうしたときに人は変化を感じる。

もちろん、「あの人は変わったな」にも裏表の両面がある。良い変わり方と、まずい方への変化だ。「アイツも変わっちまったなあ」には、あまり感心しない響きがある。でも、「アイツは変わったなあ、見ちがえたよ」なら、良い変化に違いない。だれだって、良い方に変化したい。

それはつまり、成長したい、ということだ。

昨年の秋に久しぶりに上梓した新著は、『世界を動かすプロジェクトマネジメントの教科書』という、まあそれなりに気宇広大な、というかちょっと大げさな(笑)タイトルがついている。このタイトルは出版社からいただいたもので、執筆の段階では、副題にある『チャレンジのOS』という仮のタイトルで呼んでいた。プロジェクト・マネジメントでは、知識(コンテンツ)や技法(アプリケーション)なども大切だが、その底にある思考体系や行動習慣(OS)のレイヤーが一番重要だ、という考えを多くの方に伝えたかったからだ。

人が成長するには、新しいことにチャレンジしなければならない。チャレンジだから、成功することもあるが失敗の可能性もある。しかし失敗を怖れ、守りに入るだけでは、人は成長できない。ちょうど、スキーやスケートは、転ばずには上達できないように。

絶対転ばないためには、滑らないことだ。滑らなければ、うまくなるわけはない。だから、転ぶことを覚悟で滑ってみるしかない。ただ、へたに転ぶと怪我をする危険がある。だから、スキーやスケートでは、最初に安全な転び方を徹底的に教える。そして転んだら、なぜ転んだのか、どんなときに転びやすいかを考える。これがスキーやスケートを学ぶための「OS」の大事な一部である。

成長とは、能力を得ることである。できなかったことが、できるようになる(できる確率が上がる)ときに、人は成長を実感する。では、成長するためのカギとは何か。小さな子どもは、放っておいても無我夢中で成長する力がある。なのに大人になると、その勢いが薄れる。ならば、大人にとっての『成長ホルモン』とは何なのか。

ついでにいうと、わたし自身はもう、けっこういい歳にもなったので、部下や後輩の成長にも同じくらいの関心を持たねばならない立場だ。そこで必須なものは何なのか?

これに関して、新著を出す半年ほど前になるが、ある方からメールで質問をいただいたことがある。その方は職場における育成について研究をしておられ、たまたまこのサイトに2年前に書いた「プロジェクト・マネジメントの教育について」(2014-01-27)をよんでメールを寄せられた。質問は、「『入職後、人が成長する』ということの定義をどうすればよいのか、『自分でふり返ってみて《成長した》と思えること』とは、いったい何を見ているのでしょうか?」というものだった。そこで、ふりかえりをかねて、その時に書いた返事を、少し長くなるが引用してみたい。

----------------

メールどうもありがとうございます。拙サイト、楽しんでよんでいただければ何よりです。

さて、ご質問の件ですが、成長という言葉は、「成長ホルモン」に代表されるように、非常に幅広い分野で様々に使われています。したがっておっしゃるように、研究を進められる際には『成長』なる語で何を意味しているか、明確にする必要があります。

わたしの場合、サイトにも書きましたように、成長とは能力を増大することだと考えています。今ある能力を伸ばすこと、あるいは新しい能力を獲得すること、です。

では『能力』とは何か。能力とは、「意識・無意識に期待された成果を、繰り返し達成できる度合い(または成功の確率)で測られる」、と定義しています。能力の中には数学的能力のように確定的で、つねに再現可能なものもありますが、確率的なものもあります。

たとえば昨日はヒットを打てた。今日の試合では打てなかったけれど、今シーズンを通せば2割5分の打率になっている。これが今の能力です。昨シーズンは1割9分だった。だから自分は能力が高まり、成長したと言えるわけです。あるいは、これまでホームランを一度も打てなかった人が、はじめてホームランを飛ばした。これも成長かもしれません(まぐれ当たり、という可能性もありますが)。

もう少し堅苦しくいうと、能力とは、ある資源の状態(比較的長期的・永続的な状態)を表します。その資源を構成する諸要素資源の組織化の度合いと、それを動かす制御系統の働きが、目的に合致して整合的かつ緊密である状態を示します。また、その状態がつねに維持保守され新陳代謝・再生されていることも補足的条件です。こう定義すると、チームや組織としての能力も考えることができます。ちなみにHuman resourceという言葉があるように、人間は典型的な資源の一種です(経営工学的には)。

個人の能力を構成する要素としては、知識・感覚(センス)・身体的スキル・創造性などがあります。一人前のプロフェッショナルには、このいずれもが必要なことはおわかりでしょう。またこれ以外に、個人の能力を向上する手立てとして、「技術」があります(ツールやシステムは技術に属します)。通常、これらの要素は組み合わさっており、たとえば医師ならば「内視鏡という技術と、それを使いこなすスキル、そして検査に関する知識」がバランスして、はじめて能力が発揮されます。そうなることで『成長』が実感できるのです。

そして、他者の能力を高める方法として、知識の伝達と、技術の移転があります。ちなみに知識は、さらに辞書的知識と経験知に分けることもできます。この中で、他者が言語的に伝達可能なのは辞書的知識だけです。これ以外の要素であるセンスやスキルや創造性は、自分で主体的に獲得するしかありません。ですから、あとは環境と練習台を提供して、自発的に『学ぶ』ことを助けるしかありません。そのためにプログラムや場や報酬系が必要なことは、サイトに書いたとおりです。

というわけで教育では、教える側の努力と、育つ側の「学ぶ力」のかけ算によって、成立します。ただ、一点注意すべき事は、職場では先輩の側が、たとえ職務面では高い能力を持っていたとしても、「教える能力」がないと、ちゃんと伝わらない点です。わたしはエンジニアですが、技術訓練は受けたものの、「教える能力」の訓練は受けた記憶がありません。ここがボトルネックになって、育成がうまく進まないケースは、案外多いのではないかと思っています。

----------------

相手が研究をされている方だったので、つい理屈っぽくカッコつけて書いてしまったきらいはあるが、いいたいことは二つである。
「成長とは自分の能力、すなわち成果の達成度合いが高くなること」
「他者を育成するには、知識の伝達と技術の移転が必要だが、とくに後者は学ぶ側の主体性が大切」

である以上、自分が変わりたい・成長したいと願うなら、誰かによって「変えてくれる・育成してくれる」と受動的に白馬の王子の助けを待っているだけでは、決して実現しないわけだ。同様に、何か知識を「知る」だけでは変われないことが分かる。知ったらそれを、練習し試してみる場が必要なのだ。この『』というのは、空間的な場所の意味もあるが、むしろ励まし合う仲間とか環境という面が大きい。転んでも助け起こしてくれる、そういう場である。

以前書いた記事を補足しまとめると、自分が成長するためには、以下の7つのことが必須であるとわかる。

1 優れた先生につく、あるいは良い手本やロールモデル(なりたい姿)を見つける
2 学ぶための姿勢や習慣を身につける(=チャレンジのOS)
3 対象とする専門能力について、基本的な原理原則の知識を得る
4 繰り返し練習し、あるいは真剣勝負にチャレンジする
5 自分の経験(失敗を含む)から学ぶ
6 互いに応援しあう仲間と良い環境を得る
7 学びの途中で、まだ成果の出ない自分を支える、報奨系を持つ

まあ、世にある道場とか運動部とかは、こうしたことを無意識に知っていて、サポートする仕組みなのだろう。ただ、そうした場も、競争意識が強すぎたり精神主義になりすぎたりすると、十分には機能しなくなる。

ひるがえって、企業の場はどうか?

一番むずかしいのは、4の練習の場を提供することだろう。練習には、失敗がつきものである。だがOJTと称して、実地の場しか与えないと、仕事で失敗させることができなくなる。失敗する前に先輩や上司が手を出してしまうか、ないしは失敗しそうな仕事はそもそも任せなくなるか、二つに一つだ。そうでなくとも、OJTではちょうど良い機会に、ちょうど育成に向いた仕事が来るとは限らない。

わたしが、自分の主宰する「プロジェクト&プログラム・アナリシス研究部会」で、新しくPMの自己育成のためのツールを共同で作ろう、と発案したのはこのためである。プロジェクトの状況を把握・分析し、その評価・シミュレーションを行い、自分の決断を複数人との協業の中で検証できるツール。まだ漠然とした構想の段階でしかないが、こうした道具立てと場を、研究部会で持てたらいいと思うのだ。

これまで、研究部会では外部講師を招いて、ためになる知識を勉強してきた。それはそれで大事だから続けていくが、もっと参加者にとって実質的な、実になること、成長のきっかけになれること——そんな機会を少しでも提供できる場にしたいと思う。

・・これが今年の、わたしの抱負の一つなのでした。


<関連エントリ>
 →「プロジェクト・マネジメントの教育について」(2014-01-27)
by Tomoichi_Sato | 2016-01-04 11:36 | ビジネス | Comments(0)