理想的な上司と部下の関係とは――部下の育成方法：何かがおかしいIT化の進め方（17）（3/4 ページ）

[公江義隆，＠IT]

部下への動機付けは管理者の重要な役割
――自己管理を体験させて、知識は自分で習得させる

　いわゆる知識やハウツーは説明しやすい。やっている方も教えているという気持ちになりやすい。しかし、これらは、他人から説明してもらうのと、自分だけでやるのを比べてみると、その結果にそれほど大きな差は生じない。上司は適当な参考書を示す程度でよいはずだ。流行のeラーニング対象の問題でもある。

　何よりも、自分の仕事に必要な知識は自ら習得していくものだということを、具体的な形で、部下に認識させることが大切なのだ。しかし、すべて本人任せ・自己責任というわけにはいかない。独学・自習の最大の問題点は“途中での挫折”である。環境を整え、“部下の行う自己管理”を管理者として指導することが上司の役割になる。　最初に必要となるのは、部下をやる気にさせる＝やりたいと思わす・やらないと困ることになると感じさせるなど、やる必要性を理解させること、つまり部下への動機付け（モチベーション）である。部下の動機付けは上司の大切な役割の1つである。

　また、講習会に行かせるなどして学習を始めるきっかけを作り、さらに、当人に目標設定をさせる、現在の状況を確認させる、結果の評価をさせるなど、そのプロセスの途上の適切なタイミングでの一連の管理活動が上司の役割として大切になる。現在の状況や結果などは、上司が直接に確認したり評価するのではなく、まず当人に分析させて、その結果を聴き、質問をして、その結果の評価をして必要な指示をする。

　口だけで「PDCAが大切だ。PDCAをやれ」といっても、具体的に「何を、いつ、どのようにやればよいのか？」という問題は、当人にはなかなか分からないのが普通だ。自己管理のやり方を短期に身に付けさせるには、具体的なケースの中での指導が必須だ。OJTの重要な一面でもある。OJTの要件は、「適切なテーマを与える」「適切な役割を与える」「その中で適切なアドバイス・評価を行う」ことである。

　このような指導のために、上司は自らの経験を振り返り、目標設定はどんな形で設定するのがよいか、途中のチェックはどんな時点でどのようにするか、結果はどうとらえるかなどを、いま一度頭の中で整理してみていただけないだろうか。これが部下の指導の原点になると思う。

コーヒーブレーク

　「分かったか？」と訊いても、分かっていない人は「自分の分かった部分がすべてだ」と思って「分かった」と答える。しかし、その答えは当てにならない。また、「何が分からない？」などと訊かれても、相手にすれば、分からないときには、そもそも何が分からないかがよく分からないから答えられない。質問の仕方も大切だ。部下に評価の結論を訊いては駄目だ。具体的な内容で訊かないと正しい情報は返ってこない。相手のいったことを評価するのが上司の仕事だ。

　システムテストの後で「大丈夫か？」と訊けば、「大丈夫です」と部下は答えざるを得ない。そのまま本番スタートしてとんでもないことになっていたら、それは聴いた側の訊き方にも問題がある。

　管理者の責任は結果責任（成果責任）である。「部下が大丈夫といったから」「テストは気を付けてやるよう、いつも口が酸っぱくなるほどいっているのに」などといういい訳は、自らの判断力や、リーダーシップのなさを管理者自ら吹聴していることになる。

必要・有用な上司や周囲のサポートとは
――全体・基礎を教え、概念理解の相手をする

　上司や周囲は何も教えなくてもよいかといえば、そうではない。知識に類することであっても、総論なしで各論の理解をしようとすると大変苦労するものだ。

　“情報システムの開発の方法”といった内容が広範なものであっても、その中の個々の手法を個別に勉強するという方法でも、作業はできるようにはなる。例えば、ERD（Entity

Relationship Diagram）に関する机上の勉強をすれば、ERD作成の作業はできるようになる。

　しかし、“なるほど”と感じられるのは随分先のことになってしまう。あるいは、永久に“なるほど”と感じられる機会はないままで終わる人がいるかもしれない。これでは能率も仕事の質も上がらない。DFD（Data Flow Diagram）だ、ERDだ、データの正規化だ……などと別々に勉強したものについて、相互の関連付けを把握したり、これらのバラバラの“個”の集まりからシステム開発の方法の全体を理解しようというのはなかなか大変なことである。　最近の世の中の傾向として、どの分野でも細分化が進み、全体把握ということが大変難しい世の中になってしまった。書店の棚には、細分化された個々の分野の専門書は数多く並んでいるが、システム設計概論、情報システム開発概説などといった、広く全体について基本的なことや、本質を書いた入門書を見付けるのに大変苦労する。

　全体構造の概要や体系、基礎や本質を理解しておけば、部分や各論・詳論の理解は速い。一方、各論ベースのハウツーやマニュアル頼りでは、真の理解に手間取り、また応用力や創造力は育ちにくい。

　「全体や、基礎の理解のために適当な参考書を探して与える」「適切な全体についての概論の講習会があれば参加させる」といったことが必要になる。こんなことができない場合には、「時間を割いてでも“全体の概要や体系”を教える機会を設ける」ことを、上司の仕事の1つとして検討いただけないだろうか。

コーヒーブレーク

　その昔、社内で科学技術分野の問題の数理的な分析や解決のサポートを仕事にしていたことがある。持ち込まれる課題は、種々雑多な分野に及ぶ。そのたびに、その分野について一から勉強できる入門書が必要だった。当時、「女子大の教科書がいいよ」といって、某有名女子大出身の才媛である部下からヒンシュクを買ったことがある。いまなら、セクハラだと大問題になるのかもしれない。当時の女子大には、有名大学を退官された優れた先生が多くおられた。こんな先生が書かれた、基礎や本質を中心に、難しいことをやさしく説明した分厚くない本があった。

　最近は、昔からあるやさしいことでも、新しく難しい高度なことのようにいう人が増えたような気がする。この方がビジネスになるのだろうか。