ホーム » Educe Club Newsメールマガジンバックナンバー » 『Educe Club News』【第7号】母国語

Educe Club Newsのバックナンバー


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 『Educe Club News』【第7号】母国語
                            発行:2012.4.23
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 このメールマガジンは、教育エンジニアリング研究所及びアイボスのサービス
をご利用いただいたことのある皆様、各社が主催・共催したセミナー等にご参加
いただいた皆様、各社の担当者が名刺交換させていただいた皆様にお送りしてい
ます。
 皆様には、今後も継続的にメールマガジンをお送りさせていただきたいと思い
ますので、ぜひご愛読くださいますようお願い申し上げます。
 メールマガジンの配信停止、配信先のメールアドレスの変更につきましては、
お手数ですが文末のご案内をご覧ください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 皆さん、こんにちは。

 本メールマガジンでは、人材育成や教育研修に関するテーマを中心に、人材育
成・教育研修についての最新トピックス、弊社の提唱する「教えない教育」の理
論や実践方法、教育研修の品質(効果)の測定・評価、OJTの活性化等、人材育
成プロフェッショナルの皆様に、役に立つ情報を配信していきます。

 また、将来的には本メールマガジンをメンバー(読者)相互の情報交換の場と
するとともに、いずれはメンバーがFace to Faceで、これからの人材育成や、教
育研修のあり方や方法等について議論し、助言し合い、相互研鑽するコミュニテ
ィ『Educe Club』に成長させたいとも考えています。

 本メールマガジンは、無料で月1回を目処にお届けしていく予定ですので、
末永くお付き合いいただきますよう、よろしくお願いいたします。

                       『Educe Club News』事務局


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 目 次
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ■ 『Educe Club News』
 ───────────────────────────────────
 【1】 母国語
 ───────────────────────────────────
 【2】 「指示待ち族」がはびこる企業(NO2)
 ───────────────────────────────────
 【3】 アイディアのヒント-「境目」
 ───────────────────────────────────


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 【1】 母国語
                教育エンジニアリング研究所 木村 利明
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

“正しい日本語ができないITプロフェッショナルに注意せよ!”
これは、「プロジェクトマネジメント学会」が日経コンピュータ(2004年1月)
上に発表した記事のタイトルです。
「ITプロジェクトでは“言語スキル”を持った人材が以前にもまして重要に
なっている。その“言語スキル”とはプログラミング言語のスキルではなく、
一般的な国語力や思考力のことだ」 というのが、その趣旨です。

記事(内容)を要約してみます。

■ もともと「要件定義」では、顧客の要件を正確に理解し要求仕様書に書き
上げることが求められる。当り前のことだが、要件を正しく理解するためには、
読む・聞く・話すといった能力が欠かせない。正しい仕様書を作成するには、正
しい日本語を書く能力が必要なのだ。

■ オブジェクト指向が進展するなかで、設計者個々人の能力差が、ますますそ
の設計品質に直接反映されるようになってきた。顧客の仕様を正しく理解できて
いる担当者は、オブジェクトのクラス名一つとってもどんな役割をするのかがわ
かるような名前をつけるが、正しく理解できていない担当者は、他人から見て
さっぱり意味のわからない名前をつけがちだ。

■ 設計には、顧客の要件を抽象化できる能力や論理的な思考能力が大きく影響
する。オブジェクトを抽出してクラス名をつける…たったそれだけのことでも
「言葉」が非常に重要な役割を果たすのである。

 どうやら、C言語を知っているとかJavaでプログラムを組んだ経験があるとい
うことが、イコール仕事ができるということにはならないということがはっきり
してきた…ということですね。
 MDA(Model-Driven Architecture)やMDD(Model-Driven Development)も
「初めにモデルありき」を謳っていますし、UML(Unified Modeling Language)
は「設計=言語」であることをその名前自体が示しています。
 つまり、いまどきのIT技術者はモデリングができなければなんともならん(仕
事にならない)わけです。

モデリングは「業務やシステムを抽象化すること」と定義されています。そし
て、その抽象化とは「個々の概念をより高い概念で一般化すること」であり、
 「複雑な状況や処理を単純化して他の人間に理解し易いように置き換えること」
を意味します。
 抽象化の能力はもともと人間に備わっているものですが、それは、人間が「言
葉」を操る生物だからです。つまり、「抽象化能力=言葉の力」であり、それが
弱い(“言語スキル”の低い)人間には、当然のことながらモデリングはできな
い…すなわち、ITの仕事は任せられない…ということになりますね。

 コンピュータの黎明期、クヌース(Donald Ervin Knuth)という人が“コンピ
ュータ技術者にとっての最大の資質は何ですか?”という質問に対して、たった
一言“母国語である”と答えています。
 日本人ならば、日本語できちっと「話す」「聞く」「読む」「書く」ことがで
きることが大切である…と言っているわけで、今になってみると、本質的かつ非
常に深~い、含蓄のある答えであったことが分かります。
 ちなみに、数学者・情報工学者であるクヌースさんは、当時から「アルゴリズ
ムの大家」と呼ばれていましたが、後に「文芸的プログラミング」というプログ
ラミングスタイルを提唱したことで有名です。なんとなくですが、さもありなん
…という気がしますね。

 これらのことを人材育成面で捉えると…「即戦力」という名のもとに、ただプ
ログラミング言語を教え込んだり、流行(はやり)のツールの使い方を覚えさせ
たりしていますが、果たしてそれで真に必要な教育になっているのですか?…と
いう強烈なアンチテーゼにつながります。

 むろん、その人がそれまでの人生で培った(培ってこなかった)「母国語」能
力が一朝一夕でなんとかなる(劇的に向上する)とは誰も思わないでしょう。
それでも、表面的な知識・技術よりもその方が大切なんだということは、教育の
場(OffJT&OJT)で常に伝え続け、知らしめていく必要があります。
 IT業界の50%(二人に一人!)が「エントリー」レベルという実態(以前のメ
ルマガでお伝えしました)は、そうしたことを怠ってきたツケが回ってきている
ことを如実に示しているのではないでしょうか…。

 古(いにしえ)の中国に「文は人なり」というシンプルな言葉があります。人
として成熟すれば文も実るという意味ですが、逆な見方をすれば、拙劣な文しか
書けない人間は成熟していない(未熟なまま)ということになりますね。
いまさらながらですが、IT技術者だって同じことです。
 私は、「熟達化」(仕事ができるようになる/人が成長する)とはどういうこ
とか…そういう根源的なところから、皆さんと一緒に、教育内容やカリキュラム
を考えていきたいと思っています。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 【2】 「指示待ち族」がはびこる企業(NO2)
                教育エンジニアリング研究所 幸村 英志
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 もう、すっかり記憶からなくなっているとは思いますが、前回(2011年11月号)
は企業の中にはびこる「指示待ち族」の状況について記載しました。
 今回はそのような中でサラリーマン生活を送ってきた私にとって、少なくとも
私の部下だけはそうならないで欲しいと願いつつ、実践してきたことを記載する
ことで、やってきたことに対して浮かび上がるもう一つの問題について記載しま
す。

<私なりのKKDによる新人教育>

 私の部署に新人が配属されたとき、まず最初に質問する項目がありました。
それは、「自分の管理下で仕事をしたい」または「私の管理下で仕事をしたい」
のどちらで仕事をしたいかという質問でした。勿論、今まで仕事をしたことのな
い新人ですから、与えられた仕事を自ら積極的に行う意志があるかどうかの確認
のために行っていました。

 なぜ、このような質問をしたかと言うと、一つは、いちいち他人の仕事に対し
てあぁだこうだと言うのが面倒だという性格が過分に働いていたのと、私の昔の
上司は、箸の上げ下ろしまで口を挟んでくる人であったことの反動もあったのか
も知れません。
 もう一つは、仕事とは自分の考える範疇で自ら進んでやった方が面白いからと
常々考え、そう行動してきた私の経験によるものです。
 その経験から得たことは、判断に悩む問題の発生とか、問題が輻輳し始めた状
況で、常に自分の考えで行動するということは、その結果に対して自分が責任を
取るしかなく、他に転嫁することができないということです。従って、万が一失
敗しても、次に失敗しないようにするためには何をすればよいかを自然と考える
ので、知らず知らずのうちにPDCAを回すようになって、その経験が血となり、肉
となっていった経験があるからです。

 話を戻します。そういう質問をした場合に決まって同じ回答が来ます。
それは、最初入社したときの意気込みからも当然「自分の管理下で仕事をしたい」
を選ぶものです。当時の私の経験では、配属されたばかり新人は「私の管理下で
仕事をしたい」を選ぶ人は全くいませんでした。
 でも、今まで仕事をしたことのない新人ですから、そう決めたのだから、全部
自分でやりなさいと丸投げ(ソフト業界では必ず否定的な意味で使用します)す
るわけでなく、自分で管理するための方法論をOJTで教え込んでいくわけです。
そこで教えるのはあくまでも「方法論」であって、その仕事を「具体的にどうや
るか」は自分で考えさせるように仕向けていました。

 このような指導方法を1年ほどやっていくと、この仕事のやり方に馴染む人と
馴染まない人にだんだん色分けされてきます。そこで馴染んでいる人は、ほっと
いても自ら仕事をするので問題ないのですが(ただし、時々暴走監視は必要)、
馴染まないものに対しては、なぜ自分で仕事が管理できないかを質問するように
していました。その質問に対して、なかなか本音は露呈しませんが、話の端々か
ら私なりに推定するとどうもそれは、「言われたことをやるだけの方が楽だから」
という考え方を持っているようでした。

 そのような人達に対しては、結果論から言うと、「自分で仕事ができない人達」
という括りにしてそれ以上の指導は行わずに、結構細かいレベルまで指示してい
ました。
 つまり、ある意味では見捨てたということになります。

<企業におけるもう一つの問題>

 以上のように、私は私なりに「指示待ち族」を防止するため、というよりは、
私なりの「仕事のやり方」を一方的に指導してきましたが、私がやってきた指導
方法はその良し悪しを判断する基準すらなく、単なる経験によるもので、部下の
特性すら考えずに指導を行っており、かつ、その結果のフィードバックもろくに
行わず、実施してきたことになります。
 こういう状況が私だけの経験であれば、問題ないのですが、大小はあっても、
同じような状況に陥っている中間管理職は多いような気がします。

 大概の管理職における部下の育て方は、私がやってきたように、その管理職が
今まで培ってきたことをベースに部下はどうあるべきかを考え育てているのでは
ないかと考えられます。
 これは、大方の管理職は系統的な教育理論を教えられているわけでもないので、
仕方なく自分の経験による指導方法しか見いだせていないからではないでしょう
か。

 しかし、上司を選べない部下にとってはある意味博打のようなもので、酷い上
司、たとえば、絶滅危惧種のようなひたすら根性論を振り回す人の部下になった
日には、育つどころか会社を辞めてしまうような状況に陥ってしまうことがあり
ます。

 経営者の方々は、よく管理者に必要な能力の一つとして、「部下の育成」を挙
げています。しかし、育成を行うために必要なベースとなる理論を知る機会を与
えずにそれを要求していると、必ずKKDなものとなってしまいます。
 もうそろそろ、部下の育成も理論に沿ったやり方を確立する必要があることを
認識する必要があるのではないでしょうか?

 最後に、弊社はそういった教育カリキュラム(「人材育成プロ」養成プログラ
ム OJTトレーナー向け)をご用意していますので、ご興味を覚えましたら是非
弊社までご連絡ください(最後は宣伝でおわりましたがご容赦ください)。

・OJTトレーナー研修 モデルカリキュラム
http://www.iboss.co.jp/service/curriculum-ojt.html


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 【3】 アイディアのヒント-「境目」
                 教育エンジニアリング研究所 和田 靖広
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 多くのものごとには「境目」が存在します。時間的、あるいは空間的に連続し
た変化を、何らかの形で定義したいと思ったときは、それをそのまま捉えるわけ
にはいきませんから、どこかで境目を作って区別しなければなりません。その境
目は元々誰かが決めた、あるいは作ったもので、それを多くの人が共通化して取
り扱うことで、問題解決やさらなる進歩へとつなげることができます。

 コンピューターもご存じの通り、境目で区切られた情報、いわゆるデジタル情
報によって論理的に処理する必要がありますから、連続した変化を取り扱う場合
は、とにもかくにもまずは区切らなければ始まりません。
 このとき、コンピューター用語として、その区切る工程を「デジタル化」や
「A-D変換(アナログ-デジタル変換)」と言い、その際に区切りの判断となる境
目のことを「スレッショルド」と呼びます(Threshold:閾値[いきち])。

 そう言えば、「デジタル人間」なんていう表現があって、私が学生時代だった
1980年代には「新人類」なんて言葉と一緒によく言われるようになりました。80
年代と言えば、コンピューターが世の中に少しずつ現われ始めた時代です。そう
いった時代の変化に尻込みをする大人が、臆することなく変化を受け入れる若者
に対して、ついでにコンピューターの持つ論理的で冷やかなイメージも付け加え
て、やっかみ半分で羨望していたような気がします。これもまた、時代がスレッ
ショルドを超えたために世間がそう反応したということなのでしょうね。

 前置きが少し長くなりましたが、今回は普段あまり意識することのないスレッ
ショルド、すなわち境目について、あえて考えてみようと思います。これは、特
にコンピューターの世界に限った話ではなく、現実世界でも同様に考えることが
できます。
 境目の部分に着目して考えてみると、私は大きく分けて以下の4種類の状態が
あるのではないかと考えています。

[1]あまり違いがないか、穏やかに変化する状態
 例:23時59分と0時00分、川の上流と下流、ハマチとブリ、満腹と別腹

[2]境目の前後で急激に変化する状態
 例:崖っぷち、トンネルを超えた先、大事な結果の発表前と発表後、
  昨日の友は今日の敵

[3]境目の前後、双方の要素が入り乱れ、不規則で不安定な状態
 例:海と川の汽水域、幕末の和洋折衷建築、壊れかけのレディオ、
  飛んでイスタンブール

[4]境目付近のみ、前後の要素とは異質なものが現われている状態
 例:クリームソーダのアイスとソーダの境目、雨が降ってきた直後の匂い、
  白熱電球が切れる瞬間、東京と大阪に対する名古屋の食文化

 これらの4種類の状態をそれぞれ分析したり、互いの関連性を調べたり、エン
トロピー観点やら、ホメオスタシス観点やらをなんやかんやしたりするのは、他
の機会にゆずるとして、そんな変化の母とも言える「境目」には、どうにも惹か
れてしまうところがあるんです…よね?(笑)。

 ここで、特にエンジニアという職業でこれを考えてみると、新しいものを作り
続けなければならないという使命がありますから、そのために常に考えることを
必要とします。不満を解消させるためのアイディア、改良するためのアイディア、
独自性を持たせるためのアイディア、常識を覆すためのアイディアなどです。し
かし、アイディアが天から勝手に降って湧いてくるわけではないので、うんうん
と考えては日が暮れ、途方に暮れるのです。

 よく「柔軟な思考力を持つことは重要だ」と言われます。これは研修の受講者
や新入社員だけに限らず、講師や上司でも同じことです。しかし、そう言われて
も「よし、私は今から柔軟人間だ」と宣言したところで、すぐにそうなるもので
はありません。ストレッチ運動と同じく、日ごろから自身の思考を引っ張ったり、
縮めたりすることが重要です。

 それでは、どこからその柔軟な思考力を養うネタを持ってみたらいいでしょう
か?

 一つの方法としては、いろいろな本や資料を読み、先人たちの知恵や発想を参
考にしながらインスピレーションを得たり、さらにその先を想像したりするのも、
もちろん大事な方法だとは思います。
 もっと手軽で簡単な方法としては、自然界や、現実社会の中で容易に見つかる
「境目」に、そのヒントとなる断片がいっぱい落ちているのではないかと考えま
す。それらの断片を観察したり、組み合わせたりしていくうちに、新しいアイデ
ィアが浮かぶことがあるかもしれません。また、それを続けることによって、変
化に対して柔軟に対応できる、あるいは新しい変化を厭わなくなる力を身に着け
ることに繋がる、結果的にそれが「前進力」にも繋がるのではないかと思います。

 最近、いいアイディアがなかなか浮かばないなぁとお考えの方は、とりあえず
身近にいくつも存在する「境目」を挙げてみて、考察してみるのはいかがでしょ
うか。

 柔軟さといえば、最近すっかり体が硬くなってしまい、あぐらすらかけなくな
ってしまっている自分に今気付きました。可及的速やかにストレッチが必要です
が、あんまり無理をすると「グキッ」という境目が現われてしまうので、ほどほ
どにしておきます。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 【『Educe Club News』バックナンバー】
 これまでに配信した『Educe Club News』のバックナンバーは、アイボスの
Webサイトでご覧いただけます。
 http://www.iboss.co.jp/merumaga/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

メールマガジンタイトル :『Educe Club News』

発行元:『Educe Club News』事務局
     株式会社教育エンジニアリング研究所(http://www.eelab.jp/)
     株式会社アイボス(http://www.iboss.co.jp/)
連絡先:『Educe Club News』事務局(株式会社アイボス内)
     〒103-0014 東京都中央区日本橋蛎殻町1-36-3 東洋ビル6F
     TEL 03-6661-9975 / FAX 03-3668-4775

 ※本メールの配信停止・アドレス変更をご希望の方は、
  お手数ですが、educeclub@iboss.co.jp までご返信ください。

このメールマガジンの内容を許可なく転載することを禁じます。
転載を希望される場合は、発行元までお問い合わせ下さい。

 Copyright(C)2011-2012 Education Engineering Laboratory, Inc.
                         All Rights Reserved.
 Copyright(C)2011-2012 ibos, Inc. All Rights Reserved.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━