Windows Serverを中心に、ITプロ向け教育コースを担当

失敗は成功のもと

»

 月刊「Windows Server World」の連載コラム「IT嫌いはまだ早い」の編集前原稿です。もし、このコラムを読んで面白いと思ったら、ぜひバックナンバー(2006年7月号)をお求めください。もっと面白いはずです。

■□■

 そろそろ新人研修を終え、現場に配属された人も多いだろう。グローバルナレッジネットワークの田中淳子氏によると「新人に一番喜ばれるのは体験談、一番嫌われるのは自慢話」だそうだ。そこで、今月は筆者が実際に体験した失敗談を披露しよう。なお、先月も書いたとおり、筆者の本業はIT教育コースの講師である。そのことをふまえて読んで欲しい。

●電車を乗り間違えて遅刻した

 名古屋のお客様に、新人研修を行っていたときだ。2日目の朝、名鉄名古屋駅で電車を乗り間違えた。途中で気付いて電車を降りたが、戻る電車はしばらく来ない。あわててタクシーを捕まえようとしたが、駅前にタクシーがいない。数分後、無事タクシーに乗り客先へ向かった。

 客先に到着すると、人事部による朝礼は終わっており、受講生がおとなしく待っていた。事情を話すと「名鉄はしょうがないですよ」となぐさめられた。実は事前に「名鉄のホームは間違えやすい」と聞いていたのだが、2日目になって気がゆるんだようだ。

 ご存じのない方のために書いておくと、(当時の)名鉄名古屋駅は、同じホームから違う行き先の電車が発車する上、途中で車両を切り離して別々の目的地に向かう場合もあった。どうやら前の日と違う車両に乗ったので違う行き先に向かったらしい。

 ところで、普通、講師が遅刻すると、研修担当者は講師の会社にすぐ連絡するものである。しかし、あとで聞いても何も連絡はなかったという。おおらかな会社である。

 さて、このような場合、本来はどうすべきか。もちろん、まず客先に電話するべきだ。ただし、当時は携帯電話がなく、公衆電話から電話をすることで、さらに遅刻するというリスクがあった。携帯電話が普及した現在でも、圏外にいる場合は同じ問題がある。筆者自身は新人時代に「遅刻の可能性があるなら、さらに遅刻してでも連絡しろ」と教わったが、実際の判断は難しい。実はこのとき筆者は電話をしなかったが、いったん電車を降りた時点で電話すべきであった。反省している。

●しゃべりすぎで「もう結構」と言われた

 浜松で講習会を実施したときである。質問に対して丁寧に対応していたら「すみません、それ以上答えないでください」と言われた。あんまりたくさん言われても覚えられないのだという。

 当時、筆者は入社2年目くらい。持っている知識をすべて伝えるのが「良い」講義だと思っていた筆者は反省した。すぐに必要としていない知識は、言わなくてもいいどころか、言わない方がいいこともあるのだ。

 そういえば、筆者の同僚は「体調が悪いとは、意外に受講生の評価が高い」とぼやいていた。気持ちが悪いので、本当に重要なことしか言わないからだという。

 もちろん、お客様が必要としていることは伝えなければならない。しかし、必要以上の情報を出した場合、喜んでもらえる場合と、そうでない場合がある。これ以来、質問に対する回答は、受講者の表情を見ながら行うことにしている。

●相づちはよく考えて

 これは筆者の元同僚が起こした伝説の大失敗である。お客様先の教育担当者が「私なんか、もう年なので、新しい技術はなかなか覚えられません」と言ったところ「ええ、そうですねえ」と相づちを打ったらしい。

 さすがに筆者にはそんな失敗はないが、対応に困る質問はあった。「横山さんは、自分が講師に向いていると思いますか」と聞かれたのだ。聞きようによっては「あんたは向いていない」という意味になる。

 「どうなんでしょう、向き不向きは分かりませんが、この仕事は好きです」と答えた。これが模範解答かどうかは分からないが、どんな嫌味に聞こえても怒ってはいけない。だいたい、嫌味だと思っても、ほとんどの場合、相手は何も考えていないものである。

 筆者は、少しむっとした表情を見せてしまったかも知れない。反省している。こういうときは、できれば冗談で返したいものだ。

●アンケートの意味を良く考えて

 失敗談というほどでもないが、ぜひこの場を借りて書いておきたいことがある。講習会の評価アンケートでは、そのアンケートがどう使われるかを考えて書いて欲しい。

 時々いるのが「内容は期待通りでしたか」に対して最低評価をする人。ああ、期待はずれだったのかと落胆してコメントを見ると「期待以上でした」とある。そのコメントはありがたいのだが、アンケートは集計され、統計処理されることを理解して欲しい。満足したのなら遠慮せず、ぜひ高い評価をお願いしたい。

 最近では「講師の説明は分かりやすいか」という質問に「説明は大変よく分かったが、スピーカーの前に座ったため、大音量で聞きづらかった」と低い評価を付けられたことがあった。確かに、音量の調整は講師の責任だ。気配りが足りなかったことは反省する。けれども、内容が分かりやすかったのなら、素直に良い評価を付けて欲しい。スピーカーの問題も重要だが、それは設備の評価にしていただけると幸いである。

●最悪の評価をいただいてしまったとき

 さて、最後は結構深刻な失敗である。仕事の上では筆者の人生最大の失敗である。少し長くなるが背景から説明しよう。

 X Window Systemは、UNIXなどで広く使われているウィンドウシステムで、MIT(マサチューセッツ工科大学)で開発された。当時勤務していた(古き良き時代の)Digital Equipment社(DEC)は、IBMとともにXの開発プロジェクトの主要スポンサーであり、自社製品としてXをカスタマイズしたDEC Windowsを提供していた。当時Microsoft Windowsのバージョンは2.1で、まだ使いものにならず、Macintoshが一般に使える唯一のウィンドウシステムだった。しかし、Macintoshの開発環境は高価な上、ビジネス分野の実績はほとんどなかった。

 DECの主力開発プログラム言語はFortranであったため、XにもFortranインターフェイスがあった。Fortranという言語は、科学技術計算のために設計された言語だが、DECは言語仕様を大幅に拡張していたため、ビジネスアプリケーションでさえFortranで記述することがあった。ポインタも構造体もちゃんと使える。ただしXはUNIXで動作させることが多かったため、実際にはC言語を使うことが多かった。C言語はUNIXの標準開発言語である。

 そんなとき「X Window Systemプログラミング」という教育コースを筆者が実施することになった。1989年のことである。米国で開発されたテキストに含まれる言語は2つ。1つは英語で、もう1つはC言語であった。

 ところが、担当営業は何を思ったか「テキストはCだが、口頭でFortranについても補足する」という約束で、某重工系会社向けのコース実施を受注してしまった。その会社の標準プログラム言語はFortranだというのがその理由だ。問題は3点。(1)日本語のテキストがまだできていない、(2)Fortranのサンプルプログラムがない、(3)担当者(筆者である)は、ウィンドウプログラミングを知らない。

 (1)は、製本原稿をコピーしてバインダに綴じることで、印刷製本行程の分だけスケジュールに余裕を作って解決した。(2)は、Fortranを使う上での注意事項を口頭で説明することで了承してもらった。ところが(3)だけはどうしても解決しない。当時の筆者はウィンドウプログラミングの基本であるイベントループすら知らない素人である。テキストとサンプルソースコードだけではとうてい理解できない。テキストを見ながらなら、一応のプログラムは書けるのだが、その意味が全く分からないのである。しかも日程の問題で受講の機会がない。

 最終的に、プログラムのスタイルは理解したのだが、本質的な部分の理解が深くないため、説明に説得力が出ない。その結果、コース評価はさんざんなものであり、先方から担当営業にクレームが上げられた。こうして、当時の上司と一緒にお客様先まで謝りに行くことになった。

 どういう言い訳をしたのかは覚えていない。ただ、すべて上司が話をしてくれ、筆者はほとんど何も言わなかったことと、出されたアイスコーヒーの味だけは覚えている。上司は筆者を責めなかった。無理なスケジュールで準備させたことを知っていたからだろう。

 当時、筆者は自分の力不足を自分で責めた。そして、無理なスケジュールの仕事を受注した営業担当者を恨んだ。しかし、今考えると、本当に反省すべき点は、理解が進まなかった時点で上司に相談しなかったことだ。もし相談していれば、先行して勉強している他の講師や、他部署のエンジニアから、効果的な学習方法のアドバイスが得られたかもしれない。実際、後日先輩エンジニアのコースを受講することで、短期間で理解度は大幅に向上した。

●再発を防ぐには

 実は、この話を書くべきかどうか最後まで迷った。十数年も前の話であるが、同じ失敗が他の人で繰り返されていると思われると困るからだ。現在は、初めて実施するコースの前に、担当講師の知識チェックやレビュー(講義の一部を社員に披露し、全員で評価する)が随時行われているため、大きな問題は起きていないはずである。

 誰でも失敗することはある。失敗を恐れていては新しいことはできない。能力を伸ばすにはある程度の負荷が必要だ。当時、冷や汗をかきながらウィンドウプログラミングをマスターしたことは、後にMicrosoft Windowsを学習するときにずいぶん役にたった。

 開き直るわけではないが、組織に所属している場合は、1度の失敗で人生を失うようなことはほとんどない。ただし「誰かがフォローしてくれる」という甘い考えは捨てた方がよい。失敗の予防や失敗したときの対処は考えておく必要がある。

 もっとも新入社員の場合は、自分がどう対処すればよいか分からないだろう。どうしても上司や先輩社員に頼らなければならない。適切なフォローをしてもらうには、早めに危険信号を出そう。筆者の場合は、明確な危険信号を出さなかったことが最大の反省点である。

 組織で仕事をする場合、上司や先輩には常に現状の報告を行い、問題が起きそうになったら連絡し、必要に応じて今後の相談をすること。それが組織で仕事をする場合の鉄則である。と、NHKドラマでロッカーのハナコさんも言っていた。

 ただ、幸いなことに、若い頃の失敗は許容される範囲が広い。前向きな失敗なら、それほど責められないだろう。グローバルナレッジネットワーク設立当時、日本法人の社長をしていた住忠明氏はよく言っていた。「失敗しても命まで取られるわけではない」。そして、社員ミーティングの最後はいつもこの言葉だった。

Enjoy Business as a Game (ゲームのようにビジネスを楽しもう)

Comment(1)

コメント

Jitta

失敗と気がつくから、「失敗ではない状態」を知ることができ、その差から、成功への方法を学べるのだと思います。
しかし、いつまでも「学ぶ時間」ではない。失敗を失敗と認めることができるか。それが成長できるか(成長できているか)の差になるのですかねぇ?

コメントを投稿する