カテゴリ:ビジネス( 190 )

ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ

昨年のことだが、あるIT系コンサル兼調査会社の主催するカンファレンスに出席した。参加者は大手企業や官庁などのITリーダーばかり40〜50人ほど。「ITリーダー」というのはやや微妙な表現だ。主催者側は本当は「CIO」の参加を期待したのだろうが、実際の参加者の大多数は、情報システム部長さん達だったので、こういう言葉を使ったらしい。わたしはCIOでも情報システム部長でもないが、まあ現在は社内の中期的な情報戦略をつかさどる立場なので、この場に混ぜていただいた。

わたしが参加したセッションは二つ。「グローバル企業のITガバナンス」と、「IT人材の育成」をテーマにしたものだった。円卓を10数名で囲んでディスカッションする形式で、コンサルタントが議論をファシリテートする。なかなか興味深い試みだったと思う。同席したのは、自動車会社が3社、大手通信業者、大手製造業、外資系メーカー、エネルギー企業、航空会社などなど。わたしの勤務先など、この中ではかなり小ぶりな方である。なお、呼ばれたのはユーザ側企業ばかりで、いわゆるIT専門のベンダー企業はいない。

グローバル化した日本企業が、海外子会社を含めたITガバナンスと統制をどう行うか、というテーマも意外な苦労話が多くて面白かったが割愛する。今回は、ユーザ企業のIT部門長さん達が、部門内の人材育成にどう取り組んでいるか、という話の方を紹介したい。

ま、紹介したいと書いたが、じつは「IT人材の育成に、これといった決め手はないですね」というのが参加者の共通した感想なので、紹介すべき妙法はとくにないのである(^^;)。みな似たような苦心を重ねているんだな、と互いに確認し合えただけだ。どういう苦心かというと、『人材のミスマッチ』である。

なにせユーザ企業なので、IT部門に所属するITエンジニアといっても、元からそれを志望して会社に入る例は少ない。ただ配属された以上は、それなりに能力とキャリアアップが求められるし、また自らも志向するのがサラリーマンというものだ。そこで、エンジニアとしては専門技術を求めて、ITのスペシャリティを深めよう、それで評価されよう、としていく。それはITインフラ系であったり通信系だったり、データベースやWeb技術、パッケージの知識だったりする。

しかし、ユーザ系企業が情報システム部門に本当に求めているのは、もっと別の能力なのだ。それはエンドユーザー業務を理解し、IT技術をテコにして、それを改革していく提案能力である。開発フレームワークだのクラウド並列処理だのは、専門のITベンダーや情報子会社のプロに任せておけばよい。それよりも、最新の技術を応用すれば、ライン業務をどう変えることができるかの知恵を、会社の側は期待しているのである。ITスペシャリストとして生きたい部員の側と、業務改革のリーダーを期待する経営側の期待がミスマッチを起こしている。それが今の問題なのだった。

(もっとも、上記の話はシステムの開発や修正改善を主に外部委託する企業の話で、内製志向の強い会社には必ずしも当てはまらない。ただその会合にきていた20社弱の内、ネット専業の企業を除くと、極力内製する方針の会社は1社のみだった)

また、多くの企業の悩みは、そうした情報システム部員が、「ユーザから要求されたものを作ります」という受け身の姿勢に留まっていて、業務側への提案や踏み込み姿勢が足りない、という点であった。ここは個人の資質にもよるとは思うのだが、とにかく消極的である、提案能力が足りない、というのが不満点らしかった。

では、かくいう部門長さん達ご自身はどうなのだろうか。みな、一応の業績を上げてきたからこそ、大企業の部長までなられた訳だろう。それなりに業務側への踏み込みも、提案能力もおありに違いない。そう思って話を聞いているうちに、分かったことが一つあった。部長さん達の中には、ずっとIT畑一筋の人もいれば、途中からIT部門に配属になった人もいた。ただ多く共通している点は、何か大規模なシステムの改革や、あるいは企業自体の合併などもっと大きな改革に立ち会って、そこで頑張って力を発揮したことだった。

かりに情報システム部長職というのが、ユーザ企業におけるITエンジニアの到達点だとしよう。この点にたどりつける人は、たまたま大規模システムの作り直しや、業務改革の波にぶつかった人だ。その中で業務の知識も得たし、開発プロジェクト・マネジメントの全体像も実感をもって身につけることができた。ユーザと交渉し押し切ったこともあろう。だが、そうした大きな変革は、毎年ある訳じゃない。ふつうは、よくて5〜7年に一度という程度ではないだろうか。 10年に一度かもしれない。では、そういう「大波」に立ち会えなかった技術者達はどうしたらいいのか?

これが米国のように、IT技術者の流動性の高い社会ならば話は別だ。米国は日本よりもずっと内製志向が高いが、そのかわりIT分野はエンジニアの転職も多い。昨年わたしはボストンでPMとアナリストのカンファレンスに出席したが、そこで話した感じでは、3,4回の転職歴の持ち主はザラだ。大きなプロジェクトがあると会社は人を集める。それが終わると、また機会を求めて別の職場に移っていく。こうして、しょっちゅう業務システムをつくる技術と経験を得る、という感じだ。だが、日本でITエンジニアだけ急に転職市場が増えるとは、考えにくい。

議論を聞いているうちに、わたしは、ユーザ企業の側がなんだか無い物ねだりをしているような気がしてきた。ユーザ企業はIT技術を活用して、社内業務を改善したり、あたらしい市場へのリーチを広げたりしたい。それはいいのだが、じゃあ業務を改善する主役となるのは、情報システム部門のITエンジニアであるのか、それとも業務部門側のユーザであるべきなのか? ユーザ側で業務に詳しい人のことを、SME (Subject Matter Expert)とIT分野では呼んだりする。つまり業務エキスパートである。業務をイノベーションし、新しい業務を設計するのは、ユーザ側の業務エキスパートなのか、ITエンジニアなのか? 本当はユーザ側がイノベーションをリードし、IT側がサポートする、というのが正しい姿ではないだろうか?

これは、逆の面から考えてみると分かりやすい。つまり、改革後の新しい業務システムができあがったとき、そのシステムのオーナーシップは誰が持つべきか、という視点である。それはユーザ側であるべきだと、わたしは思う。情シス側がオーナーシップを持つのはおかしい。新しい家を建てたら、所有者は住民である。まさか建築家がオーナーにはならない。その新しい家が、住む上でまだ不都合だったら、補修や改良工事もする必要がある。その判断は、オーナーである住人がするべきだ。工事にかかるお金と、その改良で得られる便益を比べて、判断するのだ。これを工務店の側がやったらおかしい。

である以上、わたしは情報システム部門のエンジニアが、IT技術のプロとして控えめであることは、けっしておかしな姿だとは思わない。建築家だって弁護士だって医師だって、優秀な人はむしろ謙虚で控えめではないか。ただしプロとして主張すべきことは、断固として主張する。筋がおかしいことは指摘する。でも、「あんたは住み方をこう変えるべきだ」なんて押しつけがましいことは言わない。

業務を変える視点を持つべきなのは、むしろ業務ユーザ側の人間なのである。彼らが、このご時世、最新のIT技術を使えばもっと効率の良い、あるいはイノベーティブな業務の仕方に変えられるはずだ、と発想し、リードしていくのが、本来の正常な姿ではないか。違うだろうか?

今のIT技術者への期待論を見ていると、まるで建築士に、「何でも良いからカッコいい家を作ってよ」とそっくりかえって言い放つ住人の姿のようだ。自分がどんな暮らしをしたいのかも言えないくせに、提案だけを求める。そして、出てきた図面を見ると、「こんな値段じゃ高すぎるよ!」と、必ず文句をつける。そんな施主ばかりだから、日本には良い建築が増えないのだ。いや、話題がそれた。

こうした視点から見ると、わたし達の社会では、むしろユーザ側におけるITの教育が不足しているように思われる。まあ、ユーザ全員がITに詳しくなる必要はない。ただ、10人に一人で良いから、IT的なセンスのあるユーザがいた方が絶対、組織にとって有用なはずである。

ここでいう「IT的なセンス」とは、別段パソコンに詳しいとか、Excelのマクロが器用にかける、といったことは意味していない。むしろ、システムで得られるデータの分析と問題抽出、解決の仕組みのデザイン、要件の確定、といった能力が肝要なはずである。

こう考えてみた結果、ユーザ側の(仮称)『ITイノベーター』に必要なスキルと能力は、大きく分けて6つのエリアからなるのではないかと、今のわたしは思っている。それは以下のようなものだ。
e0058447_2159095.jpg

1. 要件定義(業務デザイン)の能力

業務フローを理解・作成し、ありたい姿を構想できる設計能力。これが第一だ。さらにいえば、データ処理機能の理解や、コード(ナンバリング)設計のセンスまでカバーできれば、もっといい。ユーザ側はいろいろな業務要求をもっているものだが、その「要求の品質」を確保する能力が大事である。そのためには、短期・中長期な要求をバランスさせ、部門・全体の両方の視点から、考えなくてはならない。

2. システムのもたらす価値評価の能力

情報システムがもたらす価値を評価できる能力が、ユーザには絶対に必要だ。これは、結局オーナーシップをもつのがユーザ側だからである。その価値が、ウン千万円の開発投資や運用コストに見合うかどうかを判断し、経営層にアピールするのもユーザ側である。ITコストを見積もる作業は、ITエンジニア側の仕事だ。ただITコストの概算感覚とか、開発スケジュールの推定感覚とかがあると、もっと素晴らしい。

3. 開発プロセスにおけるユーザ側リーディング能力

開発プロジェクトは山あり谷ありである。その間、ユーザ側の代表として、他のユーザを引っ張ってもらわなければならない。そのためには、開発プロセスへの基本的な理解や、ユーザ・インタフェースの構想・デザイン案の評価能力が、どうしても必要である。

4. 業務へのシステム展開とチェンジ・マネジメントの能力

まさにこの部分こそ、情シス部門のITエンジニアにはできない仕事である。「チェンジ・マネジメント」自体はかなり広い概念だが、新業務運用のための組織化や、新業務手順のマニュアル作成などは、その仕事の一部になる。むろん、ユーザへの教育トレーニング実施もリードしてもらわなくてはならない。

5. データ分析・活用能力

情報システムには、すぐに膨大なデータが蓄積されていく。このデータは(今時のバズワードであるビッグなんとかを持ち出さないまでも)「宝の山」であるはずだ。そのデータを集計し、傾向分析する能力は、ユーザ側においてとても大切である。手法としてはExcelの散布図だって、十分なケースが多い。だが、「データを読む目」はもってほしい。そして、その中から、さらなる改善課題を抽出したいのである。

6. 共通能力

これはユーザ側だけに限ったことではないが、自社の経営戦略・事業戦略の理解、デザイン思考、問題解決力、そして説得力・交渉力などは、誰にも必要なスキルである。


こうしたことを、従来ITエンジニアばかりに要求し、ユーザ側には「日々の業務多忙に埋没」を許してきたことこそ、多くの組織が今日直面している問題の根底にあるのだ・・といったら大げさに過ぎるだろうか。だが、「ITをテコにした業務の改良・改革」は、ユーザ側のITセンスを持ったイノベーターと、IT部門側でプロの経験と力量をもったパートナーとの、二人三脚の仕事であるべきだと、わたしは信ずるようになった。

だから問題なのは「情シス部門の人材の育成」だけではない。むしろ、「ユーザ部門におけるITイノベーターの育成」こそ急務なのではないか。はやく適性のある者を選んで、スキルや技術を身につけさせていかないと、組織が環境変化についていけなくなってしまう。もっとも育成と言っても、世を見渡した限り、あいにくIT分野では情報技術者向けの育成カリキュラムしか、研修セミナーでも書店でも見当たらない。どこか先進的な大学かどこかが、ユーザ部門のIT能力向上のコースを開発してくれないものかと、切に願っている次第である。なければ、いっそ世に浄財を求めて自分で私塾でもつくろうか(^^)

<関連エントリ>
 →「品質とは(本当は)何だろうか - (2) 応答」 (2012-04-24)
by Tomoichi_Sato | 2016-03-06 22:04 | ビジネス | 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)

変わりたいですか?

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

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

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

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

昨年の秋に久しぶりに上梓した新著は、『世界を動かすプロジェクトマネジメントの教科書』という、まあそれなりに気宇広大な、というかちょっと大げさな(笑)タイトルがついている。このタイトルは出版社からいただいたもので、執筆の段階では、副題にある『チャレンジの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)

学会発表のお知らせ 2件

9月に学会での講演と発表を2件行います。片方は海外プロジェクトに関する概論的な展望講演で、来週、札幌で行います。もう一件はスケジューリングに関する理論的な研究発表で、月末に東京で行います。


(1)展望講演:「海外プロジェクト・マネジメントにおけるシステムズ・アプローチ         ~理論・技術・展望~」

化学工学会第47回秋期大会 講演番号J117
http://www3.scej.org/meeting/47f/index.html
日時:2015年9月9日(水)14:20~15:00
場所:北海道大学 札幌キャンパス 工学部N棟3F

概要:現代のプロジェクト・マネジメント理論は、1950 年代にデュポン社が開発したクリティカル・パス法に始まります。それは、プロジェクトをActivity 群からなる『システム』と捉えたアプローチの産物でした。本講演では、その後の PM 理論の発展を概観するとともに、現状の課題、ならびにプロジェクト評価に関する最新の研究について紹介します。

本講演は、部会シンポジウム「情報統合とモデリングアプローチ」の一環です。


(2)「プロジェクトにおけるスケジュールと費用のトレードオフを考える

スケジューリング学会「スケジューリング・シンポジウム2015」
http://www.scheduling.jp/symposium/2015/
日時:2015年9月27日(日) 16:30~
場所:青山学院大学 青山キャンパス 17号館3F

概要:コストとスケジュールはプロジェクトのパフォーマンスを測る二大指標ですが、両者にトレードオフが生じた場合、意思決定は一般に難しい問題となります。現在のPM理論では、コストとスケジュールが独立な指標と考えられ、互いを関係づける定量的で適切な方法がなかったためです。仮に、たとえプロジェクト全体の納期にペナルティがかかっているケースでも、殆どのアクティビティはPERAT/CPMでいうフロート(余裕日数)を持っており、期間の延長が直接、コスト超過に結びつきません。
本報告では、わたしが近年研究を続けている「リスク基準プロジェクト価値(RPV)分析」の理論的フレームワークを応用して、新しい評価尺度を提案し、スケジュール問題のコスト評価問題を理論的に解決します。
なお、わたしは15:30からのこのセッションの座長も務めます。


いずれも学会のため参加費がかかりますが、関心のある方のご来聴をお待ちしております。
by Tomoichi_Sato | 2015-09-02 08:51 | ビジネス | Comments(0)

人を使うということのオーバーヘッド

なんだかひどく忙しい。そう、あなたは感じている。やらなければならない仕事が山のようにたまってしまった。このままでは期限までにアウトプットが出せそうにない状況だ。自分の下に誰かつけてもらって、やるべき仕事量を分担して進めるしかない。

あなたは上司に窮状を訴え、一時的な手助けのために、なんとか若手を一人つけてもらえることになった。この部に入ったばかりの、まだ右も左も分からない新米だ。しかし贅沢を言っていられる状況ではない。周りも皆、忙しいのだ。儲かってもいないのに、ウチはなぜこんなに忙しいんだ?  あなたは独り言をつぶやきつつ、そもかくその新米を席に呼ぶ。頼みたい仕事を説明するためだ。

頼む仕事は、比較的単純だ。あなたが作ったExcelシートに条件の数字をインプットして、何種類かケーススタディをしてほしい。あなたは、ある案件の原価と収支を計算して、売価や条件を関連部門に連絡しなければいけないのだが、その計算の一部を新米に頼む訳だ。本当は、必要な資材数量や外注価格も調べて、インプットの数字も作ってほしいのだが、それには過去の実績を調べたり、関連部署に問い合わせたりしなければならず、ある程度経験がなければこなせない。だから自分で以前作成した計算用シートへのインプット作業だけを頼む訳だ。とはいっても、検討すべき条件にバリエーションがいろいろあるため、ケーススタディの数もけっこう多い。だから、そこだけでも分担してくれれば少しは助かる。

・・と、思ったのだが、何なんだこの新米。端末で表を見せて説明してやっても、眠たそうな顔をしているだけで、分かったのか分からないのか不安だ。質問もしてこない。打てば響くように、即、作業に向かってくれるのを期待していたのだが、心許ない。「分かった?」と念を押しても、「はあ・・」と頼りなげに答えるばかり。いったん席に戻ったが、しばらくするとまたあなたのところに来て、「それで、インプットのデータはいつそろうんですか?」という。まだ全部はそろわないから、できている基本ケースから着手してくれと言ったじゃないか。すると次は、「このセルに入力しても、結果がすぐ出ないんですが。」という。だからそこはマクロを呼び出すんだよ。

あなたは内心、舌打ちをしながら、しかたないので指示書を書くことにする。インプット諸条件の表(まだほとんどは空欄だが)、Excelの入力セルとマクロの起動、出すべきアウトプットとケーススタディの諸条件。ケーススタディ数は、結果によってはさらに増減する可能性がある。ともあれ最低限のケース条件を決めて、その新米に渡した。指示書を作成するだけで、2時間以上もかかってしまった。これじゃ何のために手助けを入れてもらったのか、わからない。

半日後、新米が最初の計算結果を持ってきた。あなたは数字をちらっと見るが、なんだか変だ。表の入力欄を追いかけてみると、案の定、インプットの場所を間違えている。自分でチェックもできないのか!とあなたは叱って、もう一度やり直しを命じる。その後もまごまごして、結局、最初の答えが出たのは夜になってからだった。あなたが自分でやれば、たぶん1時間以内に終わるはずの仕事だったのに、指示書を作りアウトプットをチェックしていたおかげで、二人で半日、つまり1人日もの工数がかかってしまった。

教訓1:人を増やしても、生産性はすぐには上がらない。指示や教育に必要な余計な手間(オーバーヘッド)が生じるためである。

明くる日の夕方、あなたは数ケースの計算結果を新米から受け取る。ところで、横並びの表を見ているうちに、原価に関しては期待した傾向が出ていないので、少し疑問に思う。中身を再度、一つひとつ追いかけていくと、新米の間違いに気づく。計算ミスではない(そもそもExcelなんだから)。だが原価計算に関して、配賦の考え違いをしているのだ。使えない奴だなあ! あなたは内心、毒づく。人事部も、もっと戦力になる人間をとってくれよ。だいいち、大学でもっと即戦力になるよう、教育すべきじゃないの?

(ここでちょっと一言。大学で、ほんの少しだが教えている立場から弁明しておきたい。学校で教えておくべきことと、企業で社内研修で教えるべき事の線引きは、どこが適当だろうか? 答えは簡単である。社会において共通性の高い、汎用的な知識・スキルは学校で教え、企業ごとに違う、個別化されたスキル・能力は企業内で育てるべきなのだ。たとえば簿記の知識などは汎用的だ。だから会計や簿記教育のコースが成立する。しかし、原価の基本原理はともかく、配賦となると、企業ごとに違う。経営方針を反映しているからだ。

「即戦力」という言葉が、企業内業務の個別性を含んだところまで意味するなら、それを学校教育に求めるのはおかしい。逆に、学校教育に多くを期待したいなら、自社内の業務をなるべく社会や業界の標準にあわせていく必要がある。むろん後者は、多数の企業が同じマインドで協力しなければ実現しないわけだ。

この関係はちょうど、情報システムにおける手作りとパッケージ利用の違いに似ている。業界で共通性の高い仕事は、パッケージソフトが存在するし、それに任せておけばいい。他方、他社とは差別化した業務は本来、競争力の源泉だ。当然ながらそれをサポートするパッケージソフトなど、世の中には存在しない。

問題は、競争力の源泉でもないのに、他社とは違う個別化された特殊業務が、あちこちに存在していることだ。それは確実に生産性の足を引っ張っている。そういう状態に無自覚なまま、「即戦力」だとか「クラウド活用」だとか叫んでも無意味であると思う。だが話がそれたので元に戻そう)

ともあれあなたは、自社の原価に関する配賦基準を説明し、計算のやり直しを命じる。正しい答えが出てきたのは3日目になってからだった。今度からこの種の計算は、ちゃんと指示書をマニュアル化しとかないとまずいなと、あなたは思う。Excelももうちょっと表を分かりやすく作らねば。バカでも間違えずにインプットできるようにしないと、あぶない。

教訓2:人を使って効率が上がるのは、より標準化・定型化された業務である。個別化され臨機応変が要求される業務は、他人に外注するにはあまり向かない。

さて、あなたはいくつかのケーススタディの結果を携えて、企画会議に臨む。その場で議論が発展し、さらに検討すべきことが出てきた。あなたは自分の部署に戻り、新米に指示しなければいけない。口頭で背景を説明し、指示書を改定・追加するわけだが、ひどく面倒な作業に感じる。最初から、新米君も一緒に会議に連れて行けばよかったのか。少なくとも、こんな二度手間は不要になるはずだ。

だがその三日後、次なる企画会議に新米を参加させてみると、2時間の会議の中で、かれに関係ある話題は5分ちょっとで、あとの時間はぼおっとして座っているだけだということが分かった。ただ、その話題がいつ出てくるかが、なかなか事前には読めないのだ。しかも会議に参加している間は、確実に新米君の作業が止まってしまう。

だが、少なくとも会議に出させたおかげで、あなたがなぜこんなケースを追加したのか、どういう結果がほしいのか、了解はさせられたと思う。つまり、仕事の「コンテキスト(文脈)」を新米君にも共有させたのだ。しかし、やっかいなことに、コンテキストを理解したらしたで、こんどは新米が「こうすべきじゃないでしょうか?」などと言い出すようになった。お前さんの中途半端なアイデアなんぞ、期待しとらんのよ。いわれたことだけ、きちんとやってくれ。あなたは、そう言いたくなるところを、ぐっと飲み込んで、ただ聞き流すことにした。

そうこうするうちに、ようやく企画も方向性が決まってきた。あなたが彼にやらせたケーススタディも20を超えたが、やっとミスが減ってきた感じだ。企画会議でも、少しはぴりっとした顔つきになってきた(思いつくアイデアは相変わらず的外れだが)。いろいろ忍耐もしたが、少しは育ったかなと思う。「育成とは忍耐だ。」と先輩が言っていたセリフを、あなたは何となく思い出す。

・・というところで、思わぬ展開があった。この案件自体が、海外生産で対応することになったのだ。競争力を出すため、という命題なのだが、おかげで原価計算から何から、全部やり直しである。しかしトップの指示だから、しかたがない。あなたは、この新人にやらせた計算作業を、今度は海外子会社にやらせなければならない。となると、まずExcelの表も指示書も、英語に翻訳する必要がある。それはまだ我慢できるとしても、あの、多部門を巻き込んだ企画会議のドタバタを、こんどは子会社と繰り返すのかよ、とあなたは思う。案件の企画というのは、クロス・ファンクショナルな、相互調整と交渉の仕事である。やるべきケーススタディの条件も、すべて最初から決める訳にはいかない。20のケースを決めて、まとめて「計算してくれ」と依頼するなら、まだしも楽だ。だが、結果を見ながら条件を微調整して、といった進め方を、言葉も働く時間帯も違う相手と、うまくできるだろうか。

案の定、企画の仕切り直しは当初の倍以上の期間がかかってしまった。とにかく海外子会社あてだと、何を頼むにも一から十まで事細かく説明し文字にしないと伝わらない。いや、文字に書いたって、あちこちで誤解と混線が生まれるのだ。結果が出るまで任せきりにできないから、途中経過も逐一チェックし、軌道修正をかけてやらなければならない。本当にこんな事やっていて、コストダウンにつながるの? むしろエンジニアの手間が増えるばかりじゃないの。何せ相手は、話のコンテキスト(文脈)を共有していないのだから。

教訓3:コンテキスト(文脈)を共有しない海外相手の作業外注は、同じコンテキストを共有する日本人同士より、余計なオーバーヘッド(手間)が倍以上かかる。

コンテキスト・レベル」というのは、アメリカの文化人類学者E・ホールが言い出した概念だ。社会の中でのコミュニケーションにおいて、どれほどお互いがコンテキスト(文脈)を共有しているかに関する、無意識の前提である。ハイ・コンテキストな社会では、お互いが「言わずと分かる」以心伝心・暗黙の了解が、コミュニケーションの基本的スタイルになる。ロー・コンテキストな社会では、すべてを言語化して伝えないと分からないはずだ、というコミュニケーション・スタイルが基本になる。ホールは調査の結果、アメリカ先住民はハイ・コンテキストだが、白人社会はロー・コンテキストであるという意味のことを述べている。アメリカに比べて北欧社会はもっとロー・コンテキストだ、とも。

先日、訪日したスペインのPM学者Dr. Javier Pajaresさんと話していたら、同じヨーロッパ内でもコンテキスト・レベルに差があり、たとえばスペインに比べてドイツはずっとロー・コンテキストだが、旧ソ連のCIS国家はかなりハイ・コンテキストに思える、と言われていた。国際会議で、たまたま旧CISの教授が、ドイツ人の教授と、1対1の会食を希望した。他人のいない場所で、本音で話したいことがあったらしい。しかし、それを遠回しな形でしか伝えなかったために、ドイツ人はPajaresさんをはじめ、知人のイタリア人やら誰やらをみんな呼んでいたので、やってきた旧CISの教授はびっくりしてしまったという。「ドイツ人に何かを伝えたかったら、そのものズバリを言わなきゃダメだよ。ドイツ人にとってYesはYes、NoはNoなんだから」というのが、彼の解説であった。

何度も書いていることだが、「人に働いてもらって目的を達すること」が、『マネジメント』という行為の中核である。人を動かすのだから、テレパシーでも使えない限り、言語化して伝えなければならない。ただし、その手間は、相手と共有する文脈、そして相手がよって立つ文化のコンテキスト・レベルに依存する。日本は非常にハイ・コンテキストな社会である。だから、あまり事細かく言語化しなくても、下にいる人間は、上の意向を忖度(そんたく)して動く。

このやり方に慣れていて、これがそもそも当然であると思っている人が、いったん国境を越えると、あまりに指示に手間がかかるといって驚くことが多い。驚くだけならまだしも、怒ったりあきれたり、さらに「相手はバカだ」と思ったりする。そうなると、ビジネス的コミュニケーションのはずが、感情的なやりとりに転化してしまう(ここに、人種的偏見が微妙に影響したりするから、ますます始末におえない)。そうなったら協力的仕事などうまくいくはずがない。

でも、落ち着いて考えてみると、わたし達の普段の仕事でも、コンテキストを共有しない相手とか、世代が離れていて感覚の違う相手とかだと、やはり大小の違いはあれど似たようなギャップがあるはずなのである。それに気づいて、落ち着いて対処できる態度が身についているかどうかが、じつは大事なのだ。

どんな業界でも職場でも、仕事量には山と谷がある。そして個人の能力にも限界がある。それを超えて仕事量を柔軟に増大したければ、他者を使うときの原理と、コミュニケーションに必要なスキル・態度を身につけなければならない。そして、人を使うときには、それにともなう手間=オーバーヘッドが余計にかかるのだ。一人を二人に増やしたって、生産性は2倍にはならない。3割か、よくてせいぜい5割増し程度だ。それを8割増しくらいに持って行くためには、きちんとした標準化等の準備が必須である。

あいにく、わたし達は、そうしたことをあまりきちんと教育されていないようだ。少なくともわたし個人は、人の使い方を体系立てて教わったり、コーチングを受けた記憶がない。だが、「人を使う」という行為は、課長やマネージャーの地位に就くはるか以前から、実務では必要になる。とくに海外とやるときは、組織的な習慣化(=OS化)が望ましい。だから「世界を動かすプロジェクトマネジメントの教科書」みたいな本を書いた訳だが、たとえ国内とやるときだって、相手が社内にいるときだって、最低限、知っておかなければいけないことがあるのだ。上にあげた3つの教訓などは、その代表例だろう。こうした集合的な知恵とスキルを、わたし達はもっと組織内で蓄えるべきではないかと思うのである。
by Tomoichi_Sato | 2015-08-23 14:52 | ビジネス | Comments(0)

YesとNoのゲーム - コミュニケーションを教えるということ

最初に、『Yes/No』ゲームについて説明しよう。Q&A(質疑応答)ゲーム、ともいう。4、5人ずつのグループでやるゲームだ。大人でも、子供でも、むろん学生でもできる。

ルールはとても簡単である。出題者は、何か具体的で、目に見えて手で触れる、形のあるもの(人でもいい)の名前を紙に書いて、隠しておく。回答者はグループに分かれて、順番に、出題者に対して1つずつ質問をしていく。このとき、質問についてのルールが2つある。一つ目は、質問は必ず、相手が「Yes」か「No」か、または「どちらでもありうる」の三種類のどれかで答えられるような質問であること。二つ目のルールは、誰かが既にした質問を繰り返してはいけないこと。基本はこれだけだ。

たとえば、出題者が「ビーチボール」という答えを用意していたとしよう。質問する側の最初のグループが、
「それは食べられるものですか?」とたずねる。答えは「No」だ。
二番目のグループは、「それはどこの家にもあるものですか?」と聞いてみる。出題者は「うーん、Noかな。」というだろう。
さらに三番目のグループが、「手で持てる大きさのものですか?」と質問し、「Yes」の答えを得る・・といった具合である。こうして順番に質問を浴びせていき、最後に、「それはビーチボールですか?」とたずねて「Yes」の答えを得た班が勝利者になる。

「それは何ですか?」「それはどうやって作るものですか?」といった質問ではなく、必ず「Yes/No/どちらもありうる」で答えられる質問、というところがミソだ。このように、答えの選択肢が限定されている質問のことを、コミュニケーション論の分野では、Closed Questionと呼ぶ。他方、「それは何?」のように答えに限定がない質問は、Open Questionという。このゲームは、いいかえると、有限の数のClosed Questionをつかって、どれだけ早く正解に絞り込めるかを競うゲームだといってもいい。

むろん、このとき、他の班の質問と答えも利用していい。というか、利用しないと、競争に勝てない。しかもルールの二番目、「同じ質問を繰り返してはいけない」が厳然としてあるので、他の班の質問をちゃんと聞いていなかったら、失格になる可能性がかなり高くなる。

わたしはこれを、大学でプロジェクト・マネジメントを教える講義の中で、何度か演習に使ってみた。そして、非常に効果があるという実感を得ている。学生から毎回提出してもらう出席シートでの反応も、概して良い。ゲームとして面白いだけではない。何となく、コミュニケーションの勉強になったという実感があるのである。

「コミュニケーション」はプロジェクト・マネジメントの中核にあるスキルだ。そもそも『マネジメント』という言葉の中核的な原義は、「人に仕事をしてもらって目的を達すること」である。他の人を動かすのには、テレパシー能力でも持っていない限り、言葉にしてコミュニケートする必要がある。「言葉にして伝えること」は、マネジメントの第一歩なのだ。だから、PMBOK Guide(R)などでも、コミュニケーションは10個の知識エリアの一つに組み込まれている訳だ。

ちなみに、IT技術の分野でも、もっとも重要視されるスキルは「コミュニケーション」である。IPA(情報処理推進機構)のアンケート調査によると、IT企業と教育機関とが重視したい教育項目のトップは、ともにコミュニケーション能力だという(次表参照)

IT企業が重視してほしい教育 トップ5
(1) コミュニケーション能力 61.2%
(2) 問題解決能力 42.6%
(3) 文章力・文章作成能力 30.7%
(4) チームワーク・協調性 25.5%
(5) プログラミング技術 22.2%

教育機関が重視している教育 トップ5
(1) コミュニケーション能力 59.4%
(2) 問題解決能力 29.3%
(3) チームワーク・協調性 24.7%
(4) 文章力・文章作成能力 20.1%
(5) プログラミング技術 19.2%
 (情報処理推進機構 IT人材育成本部編「IT人材白書2013」p.41より抜粋して引用。マルチアンサーなので合計は100%を超える)

どちらも、「プログラミング技術」は第5位にすぎない点が面白い。コーディングの能力より、まず人と話し合える能力を、というわけだ。3位の「文章力・文章作成能力」も、コミュニケーション能力の一部だと考えれば、その重要性はもっと高いことになる。

(ついでながら、「プロジェクト・マネジメント」はIT企業側で7位・11.7%、教育機関側で11位・8.8%しか重視していない。どうやらPMの知識教育は、IT業界ではろくに期待されていないらしい)

なお、上の数字と、新卒採用時に重視する観点(同書 p.83)を比較すると、さらに面白い。

「新卒採用時に重視する観点」
(1) コミュニケーション能力 75.9%
(2) 主体性・積極性 63.7%
(3) チームワーク・協調性 40.1%
(4) 潜在能力・成長可能性 29.3%
(5) 社風との適合性 22.5%
(6) ITに関する技術力 22.3%

「ITに関する技術力」については、入社後習得・育成が可能であると考えられているためか、「コミュニケーション能力」等の資質的な項目よりも下位に位置づけられる結果となっている(p.83)。つまり、「コミュニケーション能力」、「主体性・積極性」、「チームワーク・協調性」などは入社後の習得・育成が可能でないと企業は考えているわけだ。

これほど期待されているにもかかわらず、わたし達の社会では、うまくコミュニケーションができない場面をしばしば見る。また、どうやったらコミュニケーションのスキルを高められるかについて、社会的な合意もないようだ。本来、学校教育の場では「国語」がその任に当たっているはずだ。だが、わたし自身の記憶を振り返っても、現国・古文・漢文の三教科を通して、自身の的確な意思疎通能力を鍛えられたという実感がない。なにか美的な、文学鑑賞能力を問われた記憶はある。漢字の書き取りもずいぶんやらされた(今やワープロを使っているのでほとんど忘れたが^^;)。だがリアルタイムの、切実な意思疎通を、上手にできる教育をうけたとは思えぬ。

コミュニケーションには大雑把にいって二種類のモードがある。おしゃべりモードと切実モードだ。おしゃべりモードは、対話自体が目的のようなもので、何かを伝達することは副次的である。ところが仕事上のコミュニケーションや、日常生活でもある種のコミュニケーションでは、「これをどうしても伝えたい」という切実モードが主体になる。伝達媒体は、対面の会話のこともあるだろうし、メールや、あるいは文書の場合もあろう。ただし文書やメールでうまく伝わらないときは、結局、対面での説明に持ち込まざるをえないから、結局、会話での伝達が一番ボトムラインになるのだ。

ところが、この対話的なコミュニケーションが、教えるのも学ぶのも、案外難しい。時間と手数がかかる上に、相手によって会話の筋道がかわり、再現性が低いから、一定の型を真似ればすむ訳にはいかない。ペーパーテストができないから、教室でのマスプロ的な教育カリキュラムにも乗りにくい。

対話的なコミュニケーションにおいて大事なのは、相手の話を聞きながら、同時に考えることである。聞くことと考えることが、同時にできなくてはならない。そして、相手が知っていることと自分が分かっていることのギャップを、常に意識する必要がある。説明とは、両者の間にある知識・認識のギャップを埋める行為だからだ。

このトレーニングのために、最初に述べた「Yes/Noゲーム」が有効なのである。このゲームにおいては、
→注意して聞く
→聞いたことを覚えておく
→同時に考える
の三つのことをリアルタイムに実行しなければいけない。しかも、勝つためには、それを数人の仲間と一緒にやらないといけないのだ。

もっとも、「Yes/Noゲーム」のルールを説明すると、そんな効率の悪いClosed Questionでは、いくら質問を重ねても、正解に到達するには際限もなく時間がかかるのではないか、と批判する学生があらわれる。だが、実際にやってみると分かるのだが、大学生レベルの知的能力をもっていれば、普通の出題ならだいたい20問以内に正解にたどり着く。Closed Questionという道具は、賢く使えば、かなり効率よく相手を追い込むことができるのだ。

そして、これができる人は、交渉が上手な人である。交渉(ネゴシエーション)こそ、プロマネに求められる能力の中でもトップクラスのものだろう。人を説得し、動かすことこそ、PMの仕事なのだから。そして交渉においては、きわどい局面ではOpen Questionは役立たない。価格交渉で「じゃあ結局いくらまで払っていただけますか?」などと問うても、相手がまともに答えてくれるはずはない。このとき、「でも、何か得るものがなければ、お互いに帰れませんよね?」「やはり納期よりも金額ですか?」「それって、たとえばベンツ1台より高いですかね?」・・といった風に、相手の刃を避けつつ、鎧の隙間を狙っていく能力が必要だ。むろん、笑顔や声色やボディランゲージも、巧みに取り入れながらだ。

こうした交渉の基礎的能力づくりとして、Yes/Noゲームは有用なのである。このゲームについては昔からなんとなく知っていたが、あらためて学んだのは、英語教育家として著名な故・中津燎子氏の著書(「英語と運命」)からだった。本来このゲームは子どもの教育用だが、わたしはあえて学生相手に試してみた。

試してみて驚くのは、ルールの二番目、「他と同じ質問を繰り返してはいけない」を破って失格になる者が、ときどき現れることだ。なぜか。他人の発言を、よく聞いていないのだ。上の空で聞き流して、自分の中だけで考えている。これでは良いコミュニケーションができるわけはない。そして、おかしなことに、こうした傾聴の態度・姿勢は、初等中等教育では、ちっとも訓練されていないのだ。つまらぬ教師の話を聞き流すのは、分からんでもない。だが、聞き流したら即、失敗となるゲームの場で、なぜ集中して聞かないのか。

「相手の話を聞いていない」人は、わたし達のビジネスの場でも、しばしば出会う。何を話しても、どうしても聞いてくれない。自分の側の論理だけを、一方的に繰り返す。その相手が権力があったり、顧客だったりしたら、もうお手上げに近い。だが、その相手だって、最終的には聞かないことで損をしているのだ。当然だろう。この世は取引と協力、ギブ・アンド・テイクでできている。テイクしかしない人と、誰がまともな関係を取り結ぶだろう? だれが本当の情報を奏上するだろう?

Communicationという英語は、本当は「伝達」という意味で、一方向にむかった動詞である。相手に着実に伝えること。これがCommunicationなのだ。そして、伝えるためには、逆説的なようだが、聞く耳を持たなければならない。日本ではなぜか「コミュニケーション」は双方的で、だからお互いに責任のない、ふわふわしたもののように理解されがちだ。それはおしゃべりモードの場合だけである。わたし達が何かマネージしたければ、切実モードのコミュニケーション・スキルを身につけるしかないのだ。


<関連エントリ>
 →「書評:『英語と運命』 中津燎子・著」(2014-06-08)
by Tomoichi_Sato | 2015-08-02 10:48 | ビジネス | Comments(0)

OSを持つ、ということ

海外の外注先とトラブルが発生した。発注書で決めていた納期が守れそうもないというのだ。我々から彼らにインプットすべき仕様情報が不正確だったし、予定より遅くなったせいだ、と彼らは、いう。こちらから見ると、彼らが出してきた設計承認図や仕様書の品質が低く、かなりコメントをつけてやり直しさせる必要があった。おまけに、両者共通の悩みとして、われらがエンドユーザーである顧客がぐずぐずとなかなか決めず、リサイクル的コメントをつけてくる問題があった。だが、まだ設計の中盤なのに、じりじりとスケジュールが遅れていった。このままだと、下流工程の仕事にも影響が出かねない。

担当者は、プロマネに相談にいくつもりだった。だが、彼のチームのベテランは、それを制した。そのベテランは別プロジェクトに従事していたが、担当者のことはよく面倒を見ていた。
「いったい何を相談に行くんだ?」
--このままだと2ヶ月近く遅れそうです。下流部門の仕事に影響がでそうなので、まずは報告に行きます。それで、どうすればいいか相談しようと思います。
「報告ってお前、対策案はあるのか。」
--いえ。だから相談しようかと。
「そんな相談があるか。相手は忙しいプロマネだぞ。お前が、対策案をいくつか考えて、中ではこれが一番良いと思うので、これで行きたいと思います。ご承認お願いします、って持って行くのが筋だ。」
--・・はい。
「そもそも、スケジュール遅れの原因は何なんだ?」

担当者は、上に書いた事情を説明した。こちらのインプットの遅れ、向こうの低品質、エンドユーザの不決断。それで、外注先の設計作業の生産性が落ちたんじゃないかと。

「ずいぶん曖昧だな。これまで何度も使ったことのある外注先だろう? 向こうの品質だって分かっているし、ウチのやり方だって慣れているんじゃないのか。この顧客とだって、はじめてじゃない。何かもっと別の原因があるはずだ。」
--何でしょう?
「それをつかむのがお前の仕事だろ! 根本原因が分からなかったら、この先でまた同じ遅延問題が何度もぶり返すぞ。外注先に行って自分で見てこい!」

出張から帰ってきた担当者は、ベテランに報告した。

--あの外注先は、コストダウンのために、今回から一部の設計業務をインドに再外注していることが、行ってみて分かりました。それがうまくコントロールできていないんです。
「やっぱりか。今回急に崩れたのは、何か原因があると思った。それで、どういう対策がある?」
--向こうのマネジメントと話し合ってみたんですが、二通りしか策はないようです。つまり、向こうに時間を与えてちゃんとやらせるか、それとも依頼した仕事の一部をこちらが引き取るか・・

これはまあ、10年以上も昔に経験したことである。上の会話は分かりやすいようにレンダリングしたが、実際にはこんなにテンポよく進んだ訳ではなく、数週間以上かかり、いったりきたりした結果である。でも、全体の雰囲気はつかめたと思う。このベテランが担当者に諭したのは、二つのことだ。

・自分の中に対策をもたずに、上に相談に行ってはいけない。たとえ自分の案が不完全でも(その可能性は高いが)、自分はこうしたい、という意思を持って行くこと。

・問題が起きたら、応急的な対処だけでなく、その問題の根本原因をきちんと調べなくてはいけない。さもないと同じようなトラブルがまた発生する。

最初の点については、以前も「あなたは、どう考えるの?」(2014-09-28) に書いたことだから、ここではこれ以上、繰り返さない。二番目の点は、問題解決における基本的な態度についてだ。

そもそも問題解決とは、次のような4つのステップを踏む必要がある。
(1) 問題の直接原因と影響範囲をつかむ
(2) 問題の波及を止める(応急措置)
(3) 問題の根本原因をしらべる
(4) 再発を防止する

このうち(3)(4)は、忙しいさなかには同時にできないかもしれない。だが、再発の可能性があるうちは、やはり根本的な解決が必要だから、放置はできない。上のベテランは、このことを指摘した訳だ。一度トラブルを乗り切ったと思っても、似たようなことが再三起きる。それは最初の原因解明が不十分だったからだ。

そして、何よりも大事なことは、上の4つのステップが自分の中で言語化されて、いつでも反射的に取り出せるようになっていることである。トラブルに遭遇し、問題事象に巻き込まれたら、この4つのステップが頭に思い浮かぶこと。それが『OS』化された姿なのだ。

問題解決には、とたえばRoot Cause AnalysisとかLogic Treeとか、いろいろな技法がある。有名なKJ法やブレーンストーミングだって、問題解決技法として登場した。だが、これらはいずれもツールであり、計算機にたとえればアプリケーション・ソフトに相当する。こうした技法を活かすかどうかは、じつはその下のレイヤーにきちんとOSが動いているかどうにかかっている。

OSとは、組織化され体系化された思考態度・行動習慣の集合である。それは個人レベルでも持ちうるし、組織内で共有するものでもある。組織内で、先輩から後輩に必ず受け継がれ、ブラッシュアップされていく仕組みができていれば、それは組織のOSと呼べるだろう。ただし、きちんと伝達され、受け継がれていくためには、(当たり前だが)それが言語化されていなければならない。そうしないと意識の層に上がってこないからだ。単なる職場の慣習で、後輩は先輩の背中を見て覚えるのみ。学ぶも学ばぬも、その当人次第、という状態ではOS化されているとはいえない。

OSがどういうものかは、OSがない状態を考えてみれば分かる。たとえばトラブルが起きる。それに対処する。そしてまた、次のトラブルが起きる。また対処する。つまり、外部からのインパクトやイベントに振り回され、必死に適応するだけの状態になる。つねに受け身で、後手後手の行き方、イベントドリブンな仕事のしかたになる。自分で先を見通せなくなる。

別の例を挙げようか。よく工場の製造現場では「5S」とよばれる標語が壁に貼ってある。5Sとは「整理・整頓・清掃・清潔・習慣化」の略だ(「習慣化」のかわりに「しつけ」という語が使われている場合もある)。5Sというのは、組織化され体系化された態度・習慣の集合で、典型的なOSである。何か材料を加工するとか部品を組み立てるといった作業や、そのための工具装置の操作は、アプリケーションである。このアプリがきちんとスムーズに動くためには、5SというOSが確立していることが望ましい。5Sが働いていないと、しょっちゅう材料のモノを探し回らなければいけないし、作業動線がぎくしゃくして怪我をしやすいし、機械は清掃不足で故障しやすくなる。だから、工場では口やかましく、5Sの徹底ということがいわれるのだ。

同じ事は、本当はオフィスワークでもなされていなければならない。あなたは書類がどこにあるか探し回ったことはないだろうか? そもそも設計書や提案書に、すべてファイリングNo.は発番されているだろうか? サーバの中を電子ファイルを探し回ったことは? あるいは床に変なモノが置いてあるおかげで、つまずいたことはないだろうか。飲み物をこぼしてPCや書類をダメにしたことはないだろうか? なぜ知的なるオフィスでは、そういう習慣は不要だと信じられているのか。

もう一つだけ、例を挙げる。わたしの勤務先では、顧客や発注先や誰とであれ、打合せを行ったら必ず議事録(MOM = Munites of Meeting)を書く。議事録には、打合せ内容、出席者、決定事項、アクション事項と期限、などが簡潔に記載されている。それをプリントアウトして、出席した客先や業者に、「たしかにこの通りの内容で間違いない」と確認のサインをもらう。後になって、言った・言わないのくだらない水掛け論を防止するためだ。

とくに客先との打合せMOMは表現に神経を使うので、1時間の打合せの議事録作成に1時間以上かかるのはザラだ。非常に面倒くさい。しかし、少なくともわたしの勤務先では、面倒だからといって省略する者はまずいない。むしろ、議事録がないと落ち着かない気分になるだろう。それが言葉を大切にする『記録重視』のOSとして、習慣化されているからだ。会社に入って、最初にしつけられる作業の一つでもある。

(以前書いたかも知れないが、何年か前、わたしは専務によばれて30分ほど製品開発プロジェクトについて相談した。わたしが席に戻るか戻らないかのうちに、当のその専務からメールが入ってきた。開けてみると、「さっきの打合せの結論はこれこれだったよな。」という、3行ほどの念押しの内容だった。腕利きのプロマネ上がりの専務は、忘れっぽい佐藤に頼らず、自分でMOMを書いてよこしたのだ^^;)

OSとは何か。それは、自分が行う行動を、毎回個別の、単独の行為として終わらせずに、繰り返し可能なシステマティックな行動習慣とする仕組みだ。トラブルが起きたら、「問題解決」の思考ルーチンを立ち上げること。打合せを持ったら、「記録」の行動ルーチンを回すこと。モノを生み出したら、「整理」のルーチンに入れること。

それは思考や行動の抽象化とも言えるだろう。標準化といってもいい(ただし「標準化」というと、全然別の杓子定規なものを連想する人もいるから、わたしはあまりOSの説明にはつかわない)。ともあれ、いったん身につけたら、いつでも、ほぼ同じレベルで繰り返せるようにすること、それによってムラなく効率よく実行できるようにすること。これがOSの力だ。

そういう意味では、「5S」の最後の用語は「しつけ」とするよりも、「習慣化」の方が適当だ。「しつけ」ではなんだか、働いている大人をまるで子ども扱いしているかのように感じる人もいるだろうし。

ただし。世の中の物事には、つねに両面がある。すぐれたOSを持つことは良いことだし、組織がOSを確立する事は、とても大切だ。だが、いったんOSが確立してしまい、パターンやルーチンができあがると、人はしばしば、なぜそのシステムが生まれたのかを深く考えなくなる。とにかく習慣だから、そうするんだ、と考える(深いレベルでは思考停止する)可能性が高くなる。おまけに、組織のOSをバージョンアップしようとなると、途方もなく大変な労力がかかる。みんな、習慣化しているからだ。

それでも、OSレベルの仕組みは非常に大事である。このサイトのテーマは「計画とマネジメントの技術ノート」で、ずっとEVMSだのAPSだのといったアプリケーション・レベルの話題をくわしく紹介してきた。しかし、最近わたしは、おおくの職場で抱えている問題はもっと深層の、OSレベルの問題ではないかと感じることが多くなってきた。それはとくに、いったん自分たちの得意な土俵の外に出たとき、顕著になる。

わたしは現在、海外プロジェクトのマネジメントをテーマとした新著を準備中だ。その本の中でも、知識や技法レベルだけではなく、OSレベルの思考・行動習慣について、あらためて光を当ててみたいと思っている。

<関連エントリ>
 →「あなたは、どう考えるの?」(2014-09-28) 
by Tomoichi_Sato | 2015-06-24 23:41 | ビジネス | Comments(0)

講演のお知らせ(7月1日)

直近のお知らせになり恐縮ですが、7月1日(水)午後3時30分より、東京・神谷町で下記の通り講演を行います。

サプライチェーンのグローバル化に伴い、海外プロジェクトに取り組む製造業が増えていますが、どこに難しさがあるのか、その成功要因は何かについて、ポイントをしぼってお話ししたいと思います。

なお、主催者の「ものづくりAPS推進機構」(略称APSOM)は、わたしも理事を務める団体で、生産スケジューリングを中心とした製造業の情報化と相互連携のための標準化規格策定と普及を目的とした団体です。
  http://apsom.org/index.html

今回の総会は、「新産業革命『つながる工場』と日本のものづくり」をテーマに、話題のインダストリー4.0に関する基調講演なども行われます。
この問題に関心のある方のご来聴を期待しております。


<記>

ものづくりAPS推進機構 総会講演会

プロジェクトの価値とリスク
  ~グローバル・サプライチェーン構築のために理解すべき原理


 日時: 7月1日(水) 15:30~16:15
 場所: 機会振興会館 B3F 研修1号会議室
     〒105-0011 東京都港区芝公園3-5-8
      http://www.jspmi.or.jp/kaigishitsu/access.html     TEL TEL:03-3434-8216

 参加費用:講演聴講のみは無料、懇親会参加の場合は3,000円
 参加申込み:下記のURLからお申し込みください。
      http://apsom.org/contact/application.html


以上
by Tomoichi_Sato | 2015-06-22 18:30 | ビジネス | Comments(0)

ハイ・パフォーマンス・チームへの道のり

チーム(組織)のパフォーマンスは何で決まるか、という問題を、このところずっと考えている。

組織の業績はリーダーで決まる、というのが現在、世に広く受け入れられている言説である。言説というより、最も分かりやすい直感というべきかもしれない。ひいきのスポーツ・チームがリーグでこのところ連勝している。監督がかわったばかりだ。だから新しい監督が良いのだ。あるいは、隣国の巨大メーカーは、オーナー経営者が超優秀な人材を本社に集めて、近頃なかなか業績がいいらしい。かたや、昔から製品を買ってきた国内の巨大電機メーカーが、何年間もひどい不振にあえいでいる。ならば、これは経営者がわるいにちがいない・・

どんなに長期的な業績であれ短期的な戦績であれ、あるいは数十人のチームから十数万人の組織まで、すべてリーダーの性格や良し悪しだけで、決定的に決まる。これが世間に流布する受け取り方だ。この方法にはいくつかの利点がある。まず、単純明快で受け入れやすい。また、リーダーだけを見ればいいので、分析方法として手軽である。リーダーの顔写真さえあれば、直観的に判断できる。他人の顔を見て好き嫌いを直観的に判断する能力は、誰でも幼児の頃からもっていて、万人が使え、とくに必要な予備知識もいらない。顔写真に加え、出身校や略歴に関するもあれば、完璧だ。これでほぼすべての属性は説明できてしまう。

もっともこの方法、多少の限界もある。一つ目は、業績結果はうまく説明できるが、業績予測にはあまり使えないことだ。また同じリーダーの元で、業績のアップダウンがあったりV字回復したりする現象は、説明がつかなくなる(まあ、そういう場合は「女房役」の人材の良し悪しで補足説明する方法もあるが)。

さらにもう一つ。多少なりとも組織の長やリーダーになって、かつ、思わしい業績を上げられなかった経験のある人間たちは、この方法の適用に慎重になる。自分が課長に昇進したとき、あるいはチームのキャプテンになったとき、すべての戦績が自分のせいとされるのは、いささか不本意である。この程度の手勢でどうしろというのだ? あの市場環境では、むしろ善戦した方ではないか。

むろん、中間管理職なら、自分の上司や経営者のせいにもできる(だからリーダーによる説明法はすたれない)。しかし世に中間管理職は数多いので、中には、業績はリーダーだけでなく、組織をとりまく環境や、組織が持っている要員、設備や技術などもけっこう重要ではないか、と考える人も出てくる。

まず、組織の要員のコンピテンシーについて見てみよう。リーダーの性格や能力だけでなく、チーム員の能力が高くなければ、良いパフォーマンスは発揮できまい。監督がいかに有能でも、選手陣があまりにオンボロでは、勝ちようがない。まあたしかに、前期最下位のおんぼろチームを新任の監督が率いて、見事に優勝する例もまれにある。めざましい例だから、皆の注意を引き、記憶に残る。しかし、そうでない例の方が現実にはずっと多いのだ。むろん、人を育てるのも監督の大事な役目ではあろうが、さすがに人は1日2日では育たない。

ついでながら、コンピテンシーというのは、そのポジションが要求する機能を果たす能力を意味する。すなわち、同じ人間でも、与えられた役目によってコンピテンシーはかわるのだ。優秀なピッチャーに、捕手をやらせたらどうなるか、考えてみれば分かる。ポジションを離れた、抽象的な『能力』レベルを議論してもナンセンスなのだ。よく、「優秀な人は何をやらせても優秀」という言い方をする人もいるが、じゃあ日本代表チームのポジションをばらばらにシャッフルしたら、チームの戦績がどうなるか想像してもらえばいい。つまり各人固有の能力と、適材適所な配員のかけ算が、コンピテンシーを生み出すのである。「リーダーの能力」というのも、その意味ではコンピテンシーの一部である。

個人個人のコンピテンシーと並ぶ、もう一つの大事な要素は、組織が利用可能な資源(資産)だ。具体的には、設備や道具などのハードウェア、そして技術や知識といったソフトウェアなど。設備や道具は個人の能力を増幅してくれるし、技術力や知的財産で優位に立つ、という業績の出し方もある。

さらにチームや組織をめぐる外部環境も、リーダーにとって大事である。ビジネスならば、市場環境全体が成長しているのか低迷しているのか、競合状態は厳しいのか、法制度や政策はどうなのか、といったことが、業績に影響を及ぼす。これらは自分たちだけではどうにもならない。無風状態と台風の中では、誰も同じようには走れないのだ。

人間の能力、組織の資源、そして外部環境。組織のパフォーマンスを決める因子は、もう他にはないだろうか? 

まだある。それは、システムとしての『組織のデザイン』である。ここでいっているデザインとは、単なる組織図のようなスタティックな絵を作ることではない。チームを、どんな機能をもつポジションから構成するか。各ポジションに対し、どんな仕組みで指示し統制するか。そして、各ポジションにどんな権限を与え、その働きをどう評価し改良していくか。これが「システムズ・アプローチによる組織デザイン」だ。このサイトで繰り返し書いてきたように、目に見えにくいシステムを、どう理解し設計するかが、管理技術=マネジメント・テクノロジーの肝である。工場ならば、人の働きとモノの動きからなる生産システムのデザインであり、知的成果物をうむプロジェクトならば、人と知識情報の動きからなるプロジェクト・フォーメーション・デザインがそれにあたる。むろん、こうしたデザインは、設備・道具・技術など有形無形の資産と密接な関係にあるし、成員のコンピテンシーにも大きく影響されよう。

それでも、「いや、やはりリーダーの役割は大きい」という声があるかもしれない。だって、組織のデザインも、リーダーのすべき仕事なんだから。まあ、それには一理ある。しかし組織の構造は、ルールや慣習によって決まっている部分も大きい。野球チームの9つのポジションを、監督は自由にかえられるだろうか? そうはいくまい。会社組織だって、法律上要求される部分はかなり多いのだ。もう一つ。リーダーの無能ゆえに、組織のパフォーマンスが急速に落ちるケースは、たしかにときどき見かける。こういうときは、たしかに「組織はリーダー次第だな」と感じることもある。ただし、お城でもどんなものでも、作り上げるには大勢の努力と長い時間がかかるが、壊すときにはあっという間だ。リーダーは、組織がダメになるときにはその「功績」が目立つが、徐々に組織が成長していくときには、リーダー個人の影響は必ずしも見えにくいことが多いのだ。

話を戻すと、組織デザインの一番プリミティブな形は、単なる個人の寄り集まりである。小学生が校庭でやる休み時間のサッカーのように、みながワッと団子のようにボールに群がる。役割分担も何もない。この「団子状態」から一段上がると、一応、ポジションと役割分担のあるチームになる。監督さんの指示と号令の元、皆が一応の機能的な動きを志す。ただし、監督がいなくなると、バラバラで集団機能が果たせなくなる。運転手のいない車のようなものだ。こうした「機械的な仕組み」からさらに一段上がると、組織の成員一人一人が、自分で考えながら、他者と連携し、パスを回してゴールを目指していく「有機的なシステム」になる。リーダーもいるが、全員が成果に対する当事者意識(オーナーシップ)を持っている。この有機的なあり方こそ、高いパフォーマンスを生む組織の姿なのである。

そして、このような有機的な組織を維持する上で大切なのは、働いている人々の気持ちのあり方=マインドセットである。それは仕事へのモチベーション(当事者意識)であり、また、集団としての思考と行動習慣(わたしが組織のOSと呼ぶもの)でもある。たとえば、命じられたからやっているのか、自分から自発的にやっているのか。それが最終的に楽しいからやっているのか、それをしないと後が怖いからやっているのか。こうしたことは、個人個人のコンピテンシーにダイレクトに影響する。また、以前『なぜなぜ分析は、危険だ』などでも紹介したように、組織が「ミスは個人の責任だ」「ミスは罰しなければ直らない」といった、性悪説的価値観を持っていたりすれば、当然ながら猜疑と情報隠蔽がはびこるようになる。

ところが、最もやっかいなことは、このマインドセットは、チーム(組織)のパフォーマンスの結果に影響を受けるのである。業績が良ければ、人々のモチベーションも上がる。モチベーションが上がれば、効率もさらに上向く。逆に業績が落下していくと、みなが「それは俺のせいじゃない」と考えはじめる。すると、人間関係はギクシャクして、さらにダウン・スパイラルにはまっていく。ここには、正のフィードバックが働くのだ。正のフィードバックが働く系は、ご存じの通り、安定化が難しい。

以上の関係を図示すると、次のようになる。組織のパフォーマンスを決める因子は大きく4つ。下から順に、(1)外部環境、(2)組織の持つ資源(技術等)、(3)組織のデザイン、(4)人のコンピテンシーだ。人のコンピテンシーは、マインドセットに影響される。ところがこのマインドセットのある部分は、組織のパフォーマンス結果から正のフィードバックを受ける。まあ、もっと要素を細かくすることも可能だし、厳密に考えればマインドセットの影響力は、組織デザインの中の評価基準のあり方に左右されたりもするが、ここでは複雑になりすぎるので略した。この図は、一種のモデルである。モデルは、多少の細部に目をつぶっても、本質的な要素をとらえることが重要だ。それが、モデルに対するリテラシーである。
e0058447_23205542.gif


そして、わたし達の社会の産業成長の軌跡を考えると、面白いことが見えてくる。第二次大戦後の10-15年ほど、産業の復興を後押ししたのは、復興政策や朝鮮特需という「外部環境」であった。この時代は、とにかく働けば結果は出た。次の高度成長の15年間は、設備投資や技術導入の時代であった。重化学工業の発展は、「組織の持つ資源」が後押ししたのだ。だが、1970頃になると、曲がり角に達した。

その後、ごく一部の企業だけは、「組織デザイン」にボトルネックがあることに気がつき、トヨタ生産システムなどの『仕組み』の工夫をはじめた。しかし、大多数は新しい外部環境を求めて輸出に走るか、あるいは電子・情報など新しい技術に賭けることで業容を広げようとした。それなりの努力もあり、また幸運な追い風もあって成功を収めたが、95年頃のバブル崩壊以降になると、打つ手を見失っていった。

その時に、システムズ・アプローチによる組織のデザインに向かえば、まだ間に合ったろう。だが、自分なりの生産システムを考える代わりに、「カンバン方式」という道具を真似る勘違いが横行した。さもなければ、システムは飛び越して、管理職に対して「リーダーなんだからリーダーシップを発揮して、何とか問題解決しろ」と号令する向きもあった。管理技術のテクニカルなソリューションを飛び越して、精神論にいきついた感じである。あるいは個人の能力を求めて、『グローバル人材』なる偶像を追いかける、といった次第だ。

高いパフォーマンスという山の頂上へは、二つの道程がある。一つは、
 技術・設備 → 組織デザイン → 人の能力、
という尾根伝いのルートだ。最後の登坂には、マインドセットの助けを得る。もう一つは、
 技術・設備 → (精神論) → 人の能力、
という垂直ルートだ。どちらも高みには上れるだろう。後者の方がルートは分かりやすい。だが、高いリスクをもつ。

もちろん前者だって、決して楽な道のりではない。とくに、マインドセットという見えざるものが、やっかいだ。技術は左脳の論理で制覇できるが、モチベーションは右脳の感情との協調作業だからだ。ただ、これを掌中にしなければ、たぶん頂上は極められないはずなのだ。


<関連エントリ>
 →『なぜなぜ分析は、危険だ』(2014-04-26)
by Tomoichi_Sato | 2015-06-02 23:24 | ビジネス | Comments(2)

忙しいそば屋とヒマなそば屋 ~ 経済性工学とは何か、それは原価管理とどう違うのか?

技術屋は数字に強い、といわれている。たしかに数字アレルギーで電卓もさわれないような人は、技術的な設計作業には向かないだろう。技術で扱う数字は、仕様や長さや物性に関わるもので、kgだとかcmだとかいった物理単位系で測られる。わたし自身は(正直に言うと)けっこう粗忽な人間で、ときどき計算間違いもするが、さすがに数字が苦手だと思ったことはない。

しかしある意味で、「技術屋は数字に弱い」とも言える。少なくとも、数字に追われ、数字を見ながら生きている。こちらの『数字』は、コストに関する数字であり、単位は円やcentで測られる。物理単位系の数字は指先で自在にさばくエンジニアが、通貨単位の数字には頭を下げねばならない。通貨単位の数字は経営者の武器であり、その番人は財務や会計のプロ達だ。

通貨単位の数字は、判断に使われる。いや、物理単位系の数字だって判断には使うのだが、それは技術的な判断である。そのサイズじゃこの内径に収まらないとか、こちらの方が動力は少なくて済む、といった判断だ。それに対し通貨単位の方は、『経営判断』用である。この製品よりあの製品の方が原価が安いから生産を優先しようとか、東南アジアで作る方が人件費が有利だから国内工場は縮小しようとか、そういった判断だ。そうした数字を目標に掲げられ、あるいは横目で見つつ、技術屋は仕事をしている。

ところで、この経営判断用の数字を、きちんと技術屋の手中に取り戻そう、少なくとも技術屋の理解できるものにしよう、との目的を掲げた学問が存在する。『経済性工学』と呼ばれる学問分野だ(英語ではEngineering Economicsという)。経済性工学の基礎を知っているかどうかで、わたし達はずいぶん、経営数値に対するスタンスがかわってくる。

一例を挙げよう。これは経済性工学の古典的な教科書である、千住鎮雄・伏見多美雄著『新版 経済性工学の基礎―意思決定のための経済性分析』(日本能率協会マネジメントセンター)の例題をもとに、一部わたしが改変した問題だ。

ある観光地にそば屋があった。名物はもりそばで、この一品種しか作っていない。売値は1杯500円。もりそばの材料費は1杯150円だ。また、おしぼり代(業者に頼んでいる)が15円かかる。人件費と、諸経費(光熱費・店舗家賃等)は固定費だが、月間の平均販売数量で割って計算すると、それぞれ1杯あたり100円と75円になる。差し引き、1杯あたりの利益は、 500 - (150 + 15 + 100 + 75) = 160円ということになる。

さて、ある忙しいシーズンのこと。一人のお客さんがやってきてそばを注文したのだが、おしぼりを使い終わったときに、店の裏で飼っていた犬が店に入ってきたため、犬嫌いのお客は店を出て行ってしまった。ただし、この客のそばはまだ作り始めていなかった。このとき、店はいくら損をしたことになるか?——これが第1問。第2問は、同じ日に今度は店員が粗相をして、そばを一杯落としてしまい、作り直すことになった。そのとき、店はいくら損をしたことになるか? そして第3問。今度は閑散期に、また店員がそばを落としてしまった。今度は、いくらの損になるだろうか?

念のために注記しておくと、そば屋は一種の製造業である(販売もしている)。材料を加工製造し、販売して、利益を得ている。そばを落としたことは、製造の品質不良を意味する。犬でお客を逃がしたことは、(おしぼりを営業経費と考えれば)失注を意味している。

数字を整理すると、こうなる:
売価   500円
材料費  150円
おしぼり  15円
人件費  100円
諸経費   75円
利益   160円

答えを見る前に、ちょっとだけ考えてみていただきたい。とくに第2問と第3問に注意。なぜ、まったく同じ失敗について、わざわざ季節をかえて質問しているのだろうか?

ともあれ、順に考えてみよう。第1問。

おしぼり代の15円を損しただけ、と思うかもしれないが、正解ではない。この場合はすでに注文を受けていて、見込み客ではなく実際の顧客になっていた。犬さえこなければ、500円の売上を得たはずだ。ただし材料費150円には手をつけていなかったから、損にはなっていない。とすると、経済性工学では500 - 150 = 350円が損だった、と考える。

第2問。これも、材料費の150円だけを損した、と答えるのは正しくない。これは繁忙期のことだった。客は次々に来て、作るはしから売れていく。だとすると、そばを2個つくり、2人に売れたはずの時間内に、作り直しをしたおかげで1人分しか売上を得なかった。だから、500円の損失になる。

そして第3問。閑散期にそばを落として作り直したら、どうなるのか。この場合、店はがらがらで、たまにしか客は来ない。だから、倍の時間をかけたって、売上が減るわけではない。単にそばの材料費150円を損しただけになる。いや、へたをしたら毎日、材料を余らせて捨ててるのかもしれない。もしそうなら、損はゼロ円である。

なんだか奇妙だって? そう感じるかもしれない。じつは、経済性工学が教えるところは、普通の会計学とは違うのだ。その違いは、第2問と第3問の差に表れている。会計学では、その月が忙しいか暇かなんて、誰も問わない。

同じ金銭的数字を扱いながら、なぜ経済性工学は会計学と違うのか。それは、目的が違うからだ。会計学は基本的に、会計が適正に行われることを保証するために発達してきた。納税のためにも、また投資家への情報開示のためにも、正しい数値の集計と扱いが行われること。ところが経済性工学とは、経済的に有利な方策を比較評価し選択するために生み出された理論で、先々の意思決定の支援が目的である。

いいかえると、会計学は過去の金銭出納の分析報告に主眼があるのに対し、経済性工学は未来の意思決定に資することを目指している。したがって経済性工学では、つねに比較論が意識され、比較の対象をどこに置くかが問題になる。

繁忙期の場合、つねに製造を続け、作ったはしから売れていく状態が、比較の基準となる。製造資源(店員やそばをゆでる釜など)は稼働率100%のフル回転で働いている。大量見込生産状態といってもいい。製造資源が少しでもロスをすると、それは売上のロスに直結する。ところが、閑散期の場合は違う。閑散期は基本的に、製造資源が余っている。釜の中はたいていお湯だけで、店員はあくびをしている。こういう状態の時に、ロスが生じたからといっても、その分、見込顧客の売上を失うわけではない。不況期の受注生産と似た状況である。だから失うのは、外部に直接出ていく材料費だけだ(人件費や諸経費は、最初に書いたとおり固定費だから、売れても売れなくても変わらない)。

そして、気がつかれたかもしれないが、この例題における経済性工学の答えには、材料費やおしぼり代などの、変動費の分だけしか計算に出てこない。じつは1杯あたりの人件費や諸経費は、固定費を販売数量で割り戻して計算した値、いわば振り返りの(retrospectiveな)値である。だから、これから先の意思決定を考える場合は、あまり縁がないのだ。

ちなみに、上の三つの問いは、TOC(制約理論)のスループットの考え方を使えば、もっと直接的に答えられる。ただし千住・伏見『経済性工学』は1982年が初版で、ゴールドラット博士がスループット会計を言い出して普及するよりも、ずっと前に書かれていたことには注意してほしい。日本人にも独創的な学者はいるのだ。(ただし、そういう先駆性は国内ではあまり知られず、海外から輸入された学説の方が脚光を浴びるというのも、いかにも日本的ではある)

話がそれたので戻すが、繁忙期にこの店が失った金額は、会計学(原価管理)でいうコストではない。では、何なのか。それは『機会損失』である。英語で言うとOpportunity costだ。機会損失は普通、個別工程の製造原価よりもずっと大きい(そば屋の例をみればわかる)。品質不良や段取り替えで工程の生産能力を止めると、非常に高くつく。だから本当の経営判断は、機会損失を勘案して、行わなければならない。会計課が報告してくる製造原価の数値だけに頼って判断しては、いけないのである。

ところが機会損失は、会計の財務諸表には決して現れない。会計の数字は現実に立脚した数字、つまり事実起きたことの数字であるのに対し、機会損失は「つり逃した魚」の大きさを示す数字だからだ。

逆に、ある状況下では、売上や製造原価ではなく、変動費だけで判断すべきときもある。比較のための評価尺度は、目的と基準状態によって変わる。こうしたことを、技術者は知っておくべきである。そうしないと、他人から与えられた数字に、無条件に従ったり、踊らされたりする可能性がある。

前回わたしは、工場で製造マンが現場を離れてモノ探しに行くようなムダを批判した。しかし、より正確に言うと、これが直接のムダ(損)となるのは、この製造工程が『繁忙状態』にある場合に限られる。もし、この工程の稼働率が5割とか7割程度だったら、製造マンの生産性が下がったからといって、企業全体の損にはつながらない。

むろん、だからといってムダを放置していいという訳ではない。生産性を上げれば、製造マンが別の工程と掛け持ちにできるかもしれないし、少なくとも、もし繁忙状態になった場合に全体の足を引っ張るリスクを下げることはできる。ただ、ムダ取りの優先順位は、繁忙状態でなければ(=ボトルネック工程でなければ)少し下がることになる。ムダを取っても、直接は製造原価は下がらないだろう。リスクが(つまり機会損失の可能性が)下がるのみだからだ。

わたしは技術系の人にも、もう少し経営数値に強くなってほしいと思う。そのためには、経済性工学=Engineering Economicsを少しは勉強するべきだ。そのための初歩的な本だってある(たとえば伏見多美雄「おはなし経済性分析」など)。金銭の数字は、だれか得意そうな他人に計算してもらえばいい、という姿勢のままだと結局は、そのブラックボックスの数値に操られる結果に陥るだろう。

ただし、経済性工学を正しく使うためには、もう一つ、自分たちの生産システムの『基準状態』を見る能力が必要だ。基準状態は、自分の担当、自分の部署だけを見ていては、必ずしも分からない。全体像と、あるべき姿のイメージが必要だからだ。大局観と、適切な評価尺度の選択。そうした事柄を非技術部門や経営層に対しても説明・説得し、積極的にプロモートできるようになって、はじめて真の意味で技術者が主導権を得ることが可能になるのである。
by Tomoichi_Sato | 2015-05-18 21:52 | ビジネス | Comments(0)