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

スペシャリストか、ジェネラリストか?

わたしが就活をしたのはもう大昔のことだが(当時は「就活」なんて言葉はなくて、みんな「就職活動」といっていた)、エンジニアリング業界志望だったので、今の勤務先のライバル会社も当然、訪問した。そのときたしか先方の人事部長さんと会ったのだが、自分の会社には「42歳定年制」という仕組みがあると言われていたのを今でも覚えている。

当時はどこの会社も定年は55歳だった。ところが、その会社では42歳になったとき、退職するか、勤務を続けるかを選び直すことができるという。「42歳くらいになると、自分が会社で将来どこまで行けるかが漠然と分かるようになる。そのとき、独立して自分の道を選び直せるように会社も支援する」ことが制度の意図だと、たしか説明されたと記憶している。

現在その会社のホームページにいっても42歳定年制では検索にかからないから、すでにその制度はないのかもしれない。しかし、この説明は長く記憶に残った。

「まだ歳も、四十であれば面白き」という江戸時代の川柳がある。40歳というのは、自分はすでに若くないと自覚するときである。世に出て職に就き、それなりに生きてきた。ただ、自分の能力や境遇、そして行く末もなんとなく想像できるようになる。それはまた、迷いの時だ。今までのルートをまっすぐ歩むか、別の道を行くか、思案のときということだろう。

42歳というと、昔はそろそろ課長になろうという年齢だ。主任や係長は経験し、人を使って仕事をする立場に近づく。そのとき、技術系ならば専門技術の現場から離れて、管理職という名のジェネラリストであることを求められる。それでいいのだろうか。技術への未練もある。自分はまだ本当のプロとはいえないのではないか。スペシャリストの道を続けるのか、ジェネラリストの道を選ぶのか、選択を迫られるというわけだ。

キャリア関係のウェブサイトを見ると、スペシャリストかジェネラリストか、などという問いがけっこう出てくる。若い人、とくに技術系の人には、ジェネラリストという職種はピンとこないし、よく分からない。ジェネラル工学なんて言う学科も大学になかったし。だから憧れる人は少ない。

結果として、若手社員のほとんどは、スペシャリストを目指す。

ところで、そんな職種だって、一人前のプロになるにはだいたい10年かかる。医師も、弁護士もそうだ。業界で一流の相手とそれなりにやりあえるまでには、15年かかるという人もいる。しかし、早く専門技術を身につけたい若者には、その時間がもどかしく感じられる。はやく業界に通じるプロになりたい、いざというときは転職しても拾ってもらえるようになりたい。このままでは技術を深掘りするどころか、会社的な雑用ばかりだ、という不満の声もきこえることがある。

そうやってスペシャリスト志向をもつエンジニアにとって、ジェネラリストという言葉が頭に浮かんでくるのは、専門分野を何年間か走ってきて、「はたしてこのままでいいんだろうか?」という迷いを感じたときだ。42歳というのは一つの曲がり角なのだろうが、もっと前から感じる場合もある。どちらを選ぶかは、本人の適性によって決めるべきだ、みたいなアドバイスをキャリア関係のサイトなどは書いている。

ところで、本当に組織はジェネラリストを求めているのだろうか? 求めているとしたら、組織内にどれくらいの比率で必要としているのだろうか?

これは、組織によっていくつかのタイプに分かれるだろう。ある種の組織では、専門家を(種類も人数も)多数抱え、それをごく少人数のスーパー・ジェネラリストがマネージする。中央集権的な形態だ。オーケストラと指揮者の関係と言ってもいい。ジェネラリストの比率は数%以下だ。こういう組織では、権限が集中しているので、即断即決。いろいろなことが機敏に決まる。ただし部下に権限がないので、組織横断的な中規模問題、たとえば品質問題などへの対応に手間取るという弱点がある。お分かりだろうが、米国企業にはこうしたタイプをよく見かける。

これに対比するような書き方をするなら、日本企業の多くは、もっとジェネラリスト比率が高い。社内にミニ・ジェネラリストを多数抱えて、各人が隣接部門とコーディネートする、分散協調型の組織である。コンセンサス(合意形成)型なので、変化に対する意思決定が遅いという弱点がある。そのかわり、現場改善はまあ、得意だ。全体を見通す大局観のある人材がいないため、大規模なシステム作りはへたと言ってもいい。

まあ、現実には両者の間にいろいろなバリエーションがある。とくに、日本の官庁や、官庁に準ずる組織形態をもつ企業では、幹部候補のエリートを、2〜3年単位でいろいろな部署に回す習慣がある。当然ながら、一つの専門知識やスキルを身につけることはできない。最初からジェネラリストとして育てるのである。そして早い段階から管理職ポジションについていく。こういう組織では、そうしたキャリア職種と、ノンキャリア職種がくっきり分かれている。ノンキャリアは局所的には異動があっても、基本は同じ職種を続けていく。キャリアの人数比率は少ない。そういう意味ではまあ、アメリカ型の中央集権に近いと言えなくもない。

ただし、アメリカ型の組織と日本型の官庁組織は、大きく異なる点が一つある。先ほどアメリカ型で采配をふるう人材は「スーパー・ジェネラリスト」だ、という言い方をしたが、じつはそれは正確ではない。正しくは彼らは「マネジメント人材」であり、米国流の考え方では、マネジメントというのはスペシャリティー(専門職)の一種なのである。だからビジネススクールみたいな学校で集中的に学ぶことができるし、学ぶべきだと考えられている。日本流の考え方では、特定の専門分野を持たないジェネラリストであることと、マネジメントができるということが、どこかでごっちゃにされている。

たとえていうならば、オーケストラの指揮者はジェネラリストなのか、専門職なのか、ということだ。最初はビオラを弾き、それからフルートに異動させ、第一バイオリンでコンサートマスターを経験させれば、指揮者になれるだろうという考え方は、たしかにちょっと奇妙である。

だが、ふつうの日本企業の話に戻そう。たとえばある程度、同一分野で経験を積んだエンジニアには、少しずつ隣接する周囲の業務分野も理解させ、ミニ・ジェネラリストにしようと仕向けるようなところも多い。だが、当のエンジニア達はこうしたプレッシャーに、しばしば反発を感じる。それは技術屋の看板を外して、管理職として生きろ、と言っているようなものだ。

たしかに昭和のように、年齢別人口ピラミッドが正三角形で、職位のピラミッドと相似形だった時代なら成り立った策だろう。しかし、今はミドルになっても管理職のポジションがたりないし、仮になっても部下がいなかったりする。おまけに終身雇用だってゆらいできている。だから、専門技術の現場から遠ざかることの代償が「ちょっと出世」では、納得できなくなっているのだ。しかも年齢ピラミッドがゆがんでいるせいで、42歳どころか、もっと若い時分からジェネラリスト圧力がかかるようになってきた。

では、中堅のエンジニアはどうすべきなのか。それを考えるには、エンジニアにとって、「出世」以外に本当に望ましい報償は何か、を問い直す必要がある。それは、「技術屋として面白い仕事をする」ことではないだろうか?  仕事それ自体が、報酬である。なぜなら、技術が好きだから、そして技術が面白いから、エンジニアを選んだ人がほとんどだからだ。

でも、「面白い仕事」とはどんな事だろうか。それは当然ながら、今の仕事のあり方を変えるようなインパクトを持つ何かを、作り上げることだろう。それは魅力的製品かもしれないし、画期的設備やシステムかもしれないし、あるいは業務プロセスそれ自体かもしれない。ただし、それは専門的技術領域を深掘りしていくだけで実現できるのだろうか?

著名なシステム・コンサルタントであるジェラルド・ワインバーグは、かつて成功したシステムと不成功に終わったシステムを比べて、「成功のほとんどすべてが、少数の傑出した技術者の働きに依存していることに気づいた」と書いている。そうした技術者たちは、理工学部出の純粋エンジニアでもなければ、経営学科出のよくあるMBAでもなかった。『問題解決型リーダー』というべき存在であり、彼らに共通する特徴は、他人を動機づける能力、組織化する能力、そして独創的アイデアへのこだわりであった、と書いている(「スーパーエンジニアへの道―技術リーダーシップの人間学」)

このことは、いいかえると、本当に面白い仕事をしたければ、アイデアだけでなく、他人を動かす能力をもて、ということになる。それは、「隣接業務を知るミニ・ジェネラリストになれ」とは、ちょっと違うことなのだ。

してみると、中堅技術者にとって、選ぶべきキャリアの道は、専門分野に職人的にこだわり続けるのか、あるいは、他人を巻き込んで新しい仕事を作る道を選ぶのか、二つに一つということになる。後者の場合、面白いことにワインバーグは、上に述べた能力は、あまり技術分野にかかわらず適用可能だという。そして、適切な気づきとトレーニングがれば、自分で伸ばせるとも書いている。

もしかするとわたしは、こういう事ではないかという仮説を持っている。どんな専門分野でも、かなり深掘りして突き詰めると、汎用的な方法論の地下水脈に行き当たるのではないか。そして、いったんそれを手にすると、井戸の壁を抜けて、水脈沿いに、いろいろな場所に行けるのではないか。絵にすると、前々回の「T字型人材像」に通じるのだが、ただし上下が逆で、垂直に底までいくと急に水平に広がる姿である。これこそ、いわゆる「一専多能」といわれる人材像ではないか。
e0058447_2346838.jpg

ただ、このような水脈を掘り当てるには、専門をそうとう掘り下げる時間と努力が必要ではないのか? いや、実はもう一つ別の道があるのだ。それは、一カ所をある程度掘り下げ、何となく達成感ないし行き詰まりを感じたら、別の場所(専門分野)にうつって、あらためて縦堀りしてみる道である。そうしてみることで、「三角測量」的に、元いた技術的専門の距離感や制約が見えるとともに、共通に使える道具立てがあることを気づけるのだ。それはわたし自身の経験でもある。

世界を動かすプロジェクトマネジメントの教科書」にも書いたように、わたしは39歳のとき、思い立ってそれまでの設計専門部を離れ、海外プロジェクトの分野に転出した。それはわたしにとって大きな転機だったが、同時に、自分がそれまで何を学んできたかを再認識する機会でもあった。ずいぶん遅い転身ではある。だが、(この点だけは日本の終身雇用制の長所だと思うのだが)専門能力が低いからといって、会社はすぐにはクビにせずに使い続けてくれるのだ。こうした転身は、たぶん米国では難しいチャレンジだったろうと思う。

ちょうどここまで書いたところで、畏友・渡辺幸三氏がBlog「設計者の発言」に、『適用分野と実装手段の組み合わせ戦略』http://watanabek.cocolog-nifty.com/blog/2016/04/post-01b8.html という面白い記事を書かれているのを読んだ。ITの世界で、適用対象の業務分野と、実装技術の縦横の軸で、技術者がどのような戦略をとるべきかを論じている。これはちょうど、音楽で言えば「レパートリーの幅」と「楽器の幅」に対応しているともいえる。最初は楽器になじむまで、ずっと一つのジャンルで修練を続ける。それから、別のレパートリーにトライしてみる。そうするとある時点から急に、楽器の使い道が、そして他人とのハーモニーの仕方が見えてくる。そうすると急に、技術的な自由度が増すのだ。

それは決して、何でも屋の「ジェネラリスト」になることではない。一専多能の「問題解決のスペシャリスト」になる道なのである。


<関連エントリ>
 →「組織のピラミッドはなぜ崩壊したか」 (2010-09-16)
 →「見えない壁に突きあたった中堅エンジニアが学ぶべき、三つのこと」 (2016-04-04)
by Tomoichi_Sato | 2016-04-18 23:54 | ビジネス | Comments(0)

企業のミッション・経営理念を日米比較する

まずは、ちょっとクイズからはじめよう。下の文言は、ある会社の経営理念である。

e0058447_2257185.jpg

これはどこの会社のものだろうか? 答えは下の方でかくが、見る前に少しだけ考えてみていただきたい。
・・思いつきましたか? では、第二問。次のスローガンと企業理念は、どこの会社のものか。

世界人類との共生のために、真のグローバル企業をめざす○○○○」
 企業理念 :
  世界の繁栄と人類の幸福のために貢献すること
  そのために企業の成長と発展を果たすこと

これをぱっと見て、いや、たとえ三度繰り返し熟読してみても、どこの企業のものか推測するのは難しいだろう。どこの会社でも、当てはまりそうな気がするからだ。世界人類とかグローバルとか、言葉は大上段だから、中小零細企業ではあるまい。だが、表だって社会との「共生」を目指さない、つまり社会と敵対的であろうと公言する企業がいるだろうか? グローバルをめざす日本企業は、今や過半数だろう。成長と発展だって、どの会社だって望むはずである。この標語と理念なら、ほとんどすべての大企業に当てはまりそうだ。わたしの勤務先だって、あてはまるとおもう。

最初の問題の答えは、「三洋電機(株)」である。2008年に経営が立ちゆかなくなり、2009年にはパナソニックに買収された同社は、法人格としてはまだ存続しているが、実質的には従業員ゼロだときいている。残念ながら、“なくてはならない存在”でありつづけることはできなかったのだ。同社で一所懸命に働いていた人々にとって、今はさぞ無念な言葉だろうと想像する。

第二の問題の答えは、あえて書かない。誰もが知っている、とても立派な企業である。だが、この標語と理念で、この会社がどういう会社か、分かる方は少ないと思う。気になる方は、まあ、ネットで調べればたぶんわかるのではないか。誤解しないでいただきたいが、わたしはこちらの会社を批判するつもりなど、全くない。たぶん、あれほどまでに優秀で差別化された製品を作り続ける同社にとっては、もはや理念の上で差別化する必要などなかったんだろうな、と想像するだけだ。

少し前のことだが、わたしは企業理念やミッション・ステートメントについて少し興味を持って、調べてみたことがある。上の二つは、そのときに見つけた例である。調べるにあたっては、

ミッション・経営理念 社是社訓―有力企業983社の企業理念・行動指針」社会経済生産性本部・編集   (Amazon.com)
世界最強の社訓―ミッション・ステートメントが会社を救う」パトリシア・ジョーンズ、ラリー・カハナー著  (Amazon.com)

の2冊の本を参考にした。前者はタイトルにもあるごとく、983社(ほぼ日本企業)をカバーし、後者は米国企業約40社を調査しカバーしている。ただし出版年次は、日本の方が2004年、米国は原書の出版が1995年で、いささか古い。したがって、すでに現状とかわっている会社もあるし、最初の会社のケースのように、会社自体がすでに消滅している例も含まれている。

ただ、そのように歴史の荒波にもまれた(?)結果を見ることで、気づくこともあった。最大の発見は、日本と米国では企業理念やミッション・ステートメントのあり方が、随分違うということだ。内容が違うのはもちろん当然だが、「あり方」が違うのだ。

日本企業の社訓・経営理念 は、大きく三つのパターンに分かれるように思えた。すなわち、(1) 古き創業者の語録、(2) カタカナの並ぶ広告代理店作成風、(3) 主に社員に語りかける訓示的な言葉、の三種類である。 古き創業者の語録は、しばしば毛筆や旧仮名遣いでなされていて、内容もじつに品格高く、高邁である。たとえば、会社設立の目的が

「一つ、真面目なる技術者の技能を、最高度に発揮せしむべき自由闊達にして愉快なる理想工場の建設」

にはじまり、経営方針には

「一つ、経営規模としては、むしろ小なるを望み、大経営企業の大経営なるがために進み得ざる分野に、技術の進路と経営活動を期する」

と書いた、東京通信工業(株)の設立趣意書などはその典型の一つだろう。これを敗戦の翌年である昭和21年に書いた創立者・井深大氏の理想主義にはまことに敬服する。ましてその後の同社の道のり(社名をソニーと変更した)を考えると、感銘深いものがある。しかし、ここまで高踏派ではない創業者ももちろん多数いたようで、もっと町の商人的な、分かりやすい、つまり平凡なレベルの言葉遣いも多い。

(2)については、はっきりいってわたしの趣味ではないので、ここではあえて紹介しない。バブル時代、CI=コーポレート・アイデンティティづくりが流行ったが、結局は広告代理店にロゴマークとスローガンづくりを依頼しました、みたいな印象が強かった。おまけにカッコいいつもりの外来語の多用。(いや、お前のサイトだってカタカナ言葉だらけだろ、というご批判はもちろん承知の上だが^^;)。

(3)のカテゴリーでは、とくに「お客さま」「信用」「品質」「社会への貢献」が、比較的多く使われる言葉である。ここらへん、いかにも日本企業らしいなあ、と感じる。とにかく、比較的短く、情緒に訴えかけるものが多い のも特徴だ。

これに比較して、米国企業のミッション・ステートメント は長く、構造的で、理屈っぽい。主たる文章に、補足説明のパラグラフが並ぶ 例が多い。たとえば、こんな感じだ:

Mission :
 われわれは、クライアントにはすぐれた価値を、スタッフには輝かしい成功を、オーナーには卓越した業績をもたらすべくつとめる

クライアントへの責任
・われわれは、クライアントの成功こそわれわれの成功であると考え、彼らのために献身する。
・われわれは、彼らのニーズを理解し、現実的な助言、効果的な施策、革新的な製品開発など、すぐれた価値を提供することで、つねに彼らの期待を上回るべくつとめる。
・またわれわれは、つねに最先端のメソッドとノウハウを提供すべく継続的な研究を進める。

これは老舗の技術コンサルタントArthur D. Little社のステートメント(の一部)だ。たいへん立派なものである。「米国では会社は株主の所有物で、経営はただ株主利益だけを目的として進められる」と解説されることが多いが、これを読む限り、同社はそう単純には規定していない。会社はクライアント(顧客)と、従業員と、オーナー(株主)の三者に、それぞれもたらすべきものがある、と考えている。

米国の文章は、その多くに、主力の商品・サービスが分かる言葉が入っていることも特徴だ。「自分たちは何者であるか」を、明確に定義する点に主眼があるのだろう。用語で言うと、
- 「顧客の満足」
- 「価値」
- 「社員(スタッフ)」
- 「適切な価格」
などが多く使われる言葉である。 日本と比較すると、信用・品質のかわりに価値や満足がきている点がまあ、面白い。

ジョーンズとカハナーの著書は、単に各社のステートメントを集めただけではなく、実際に各社のキーパーソンに対してインタビューを行い、そうした文章が設定されるまでの過程を取材しているので、非常に興味深い。起草や決定プロセスも様々だ。ただ、これを読むと米国企業では、’80年代にはじめてミッションを文章化したところが多いことに気づく(同書は1995年刊行)。日本でCIとスローガンづくりが流行りはじめたのは前述の通り’80年の終わり頃だが、米国はその約10年先を走っていたわけだ。しかし逆に言うと、’70年代までは米国企業でも、ほとんどはミッション・ステートメントを持っていなかったことになる。

なぜ、米国企業は経営理念だとかミッションだとかの文章を、’80年代に必要とするようになったのか?

ここから先はわたしの推論だが、その理由は、不況と多角化戦略の進行が背景にあると思われる 。米国はいうまでもなく、1945年の第二次大戦終結以後、ずっと経済成長のレールをばく進していた。「GMの利益はアメリカの利益」といわれたのは’50年代のことだ。それが、’60年代終わり頃から少しずつ変調を来し、はっきりと曲がり角にさしかかったのは’70年代半ばのことだった。

それを象徴する出来事は、オイルショックと、ベトナム戦争の終結(敗北)だった。ニクソン大統領が金ドル交換停止を宣言し、ドルの威信がゆらぎはじめたすぐ後のことだ。これによって、安価な石油をガブ飲みする大量消費型の生活(アメ車がその象徴)に、ブレーキがかかることになった。

いわゆる「経営コンサルティング会社」が米国で急速に発展するのも、この時期である。成長が鈍化し、不況に突入したとき、企業は何よりも人員整理と経営の立て直しを迫られた。

その結果とられた方策はなんだったのか? それは、企業買収による多角化であった。M&Aはごく普通の企業戦略ということになった。だが、その結果として、複合的な企業グループが誕生した。いいかえると、「何の会社なのか分かりにくくなった。」

その典型は、長距離バスの代名詞だったグレイハウンド社の歴史に見ることができる。サイモンとガーファンクルの名曲「アメリカ」にも登場する同社のバス事業が、停滞期に入って以降、同社は買収による多角化に打って出ることになる。WikiPediaから引用しよう。

「グレイハウンド社は・・1970年代には巨大な多角化経営企業となり、アーマー精肉会社からダイアル石鹸会社、トラベラーズ・エクスプレスの為替事業、MCIバス製造会社、さらには航空機の貸し出しまで手がけるようになっていた。」(https://ja.wikipedia.org/wiki/グレイハウンド_(バス)) 他に、わたしの記憶に間違いが無ければ、電池のデュラセルも買収していたはずだ。

このような会社が、いったい何をしたい企業なのか、戦略は何なのか、誰も説明できないだろう。もちろん株主にだって分かるまい。だから、’80年代に入ると、あらためて企業自身によるポジショニングの宣言が必要になったのだ。ちょうど米国の経営学も、ポーターらのポジショニング戦略論の全盛時代に突入していた。

では、日本の企業は?

日本企業がバブル時代にアメリカの流行を追いかけたことは、すでに述べた。ただし日本の場合は、むしろ「多角化のために」CIを導入したケースが多い。このころ企業はこぞって、名前から「建設」「観光」など業種を表す語尾をとって、「○○コーポレーション」などのモダンな(?)社名に変更した。昭和の泥臭い創業者社訓から、無味無臭な平成流「経営理念」への転身が行われたのである。

だがバブル景気は長く続かなかった。その後20年以上にわたり、企業は景気低迷時代を過ごすことになる。その間、企業の経営理念の文章はどう変化したか? モダンだがどこの会社にも共通するような優等生的な文章、という点で、あまり大きな変化はなかったように、わたしには思える。それはつまり、差別化も個性化も、十分には希求されなかったことを示している。

わたし達が「理念」やら「哲学」やら「ミッション(使命)」やらの明文化を求めるのは、わたし達が中途半端に豊かになってしまったからである。お爺さんが山に芝刈りに、おばあさんが川で洗濯をする農家に、ミッション・ステートメントは必要なかった。戦後の闇市から東京オリンピック頃までの、誰もが生きるのに必死な時代には、理念なしでも商品を作れば片端から売れた。

その後、成長した経済が曲がり角にきて立ち尽くしたとき、自分で進む方向を決めるために、はじめて哲学や使命が切実になったのである。それはファッションでお隣の先進国がやっているから自分も、といったものではなかったはずだ。言葉というのは、思考を伝達するための道具である。他者に対しても、自分に対しても。言語化することで、わたし達は自分を強化できる。「言葉を大切にする」ということが、組織の『OSレベル』の能力だと繰り返し書いているのは、このためである。

わたし達の社会はもう一度、誰にでも当てはまる優等生的な文章は忘れて、自分の頭で理念を練り直すときにきていると思う。自分が誰か、他とはどこが違うか、何をめざしているのかを、あらためて訴えかけるべきだ。そしてその説明の中心には、必ず「価値」論がくるはずだと、わたしは強く信じている。
by Tomoichi_Sato | 2016-03-27 22:58 | ビジネス | Comments(2)

ユーザ側の『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)