南野 洋一
2004/5/6

　今回は、あるプロジェクトでいっしょになった山田さん（女性＝仮名）の話をしましょう。彼女の第一印象は、「特に目立つこともなく、指示された業務を黙々と実行に移しているような方」といったところ。次にまとめるような人物でした。

　このときのプロジェクトは、メンバー10名を複数のチームに分けて業務を進めていきました。当初、私と山田さんは別チームだったため分からなかったのですが、同じチームになった際に問題が顕在化しました。

　チーム内では役割を分けて、効率的に作業を進められるようにします。最初の作業分担は、プロジェクトやチームが置かれている全体の状況を説明したうえで行いました。ここまで問題はありませんでした。

■最初の問題

- PR -

　しかし、次の場面で問題が起こりました。あるチームからヘルプ要員依頼の相談があったのです。このチームでは、定例の日時報告書を作成しています。そのため毎日決まった時刻に、ツールを使って基礎データをサーバからダウンロードしています。相談の内容はこうでした。

　「通常はチーム2名で問題ないが、2人ともミーティングなどで不在になる可能性がある。その場合だけ、ツールを使ってデータだけでもダウンロードして作業の一部を代行してほしい。その後の報告書作成はチームのメンバーで行うので」

　依頼を受けた私はチームのメンバーと、山田さんにお願いしました。しかし、以下のような言葉でこの依頼は拒否されました。

　「なぜ、私が行うのか。私にはいまのチームとしてのミッションがある。あなた方は2名いるのだから、どうにかなるはずである。もし、私に依頼をするのであれば、背景や目的を詳しく説明願いたい」

　結局、ここまでいわれると、依頼する気持ちも薄れ、そのときには説明する時間もなく、もともとのメンバー2名で業務を回すことになりました。

■周りの目

　この出来事のあと、ほかのメンバーたちは山田さんに仕事を依頼しなくなりました。もちろん当初の計画したとおりの仕事はあります。しかし、時間の経過とともに、ちょっと手伝ってほしいという作業が発生してきます。こうした作業を山田さんに相談しなくなりました。先の出来事は、回りに人がいる中でのことだったため、誰もがその場面を目撃していたからです。

　結果として、単独の作業分担を任されることが多くなりました。実作業に入るまでに説明に時間が掛かり過ぎるため、プロジェクトのメンバーが、このような状況であれば少々大変でも自分で行った方がまし、との考えるようになってしまったからです。

■私のとった行動

　山田さんの仕事への考え方は、そのプロジェクトのメンバーには合いませんでした。ただ、合わないだけであれば良いのですが、彼女がいるためにプロジェクト全体の雰囲気が悪くなり、メンバーのモチベーションも下がってきたようにも見受けられてきました。実際メンバーの数名に話を聞いたところ、私が思っている状況と同様の回答でした（こうした印象に関することは、独り善がりになることを避けるため、メンバーにさりげなくヒアリングを行うことが必要でしょう）。

　結局、彼女に行ってもらった業務は、主にプロジェクトに関係する会議に出席してもらい、情報収集を行ってもらうことを依頼しました。具体的には会議に出席しプロジェクトメンバー宛てに議事メモを作成し送付すること、およびプロジェクト側から参加している会議に報告や連絡を行ってもらうことです。仕事はしっかりと行う方です（少し完璧主義のところがあり、また時間が掛かりますが）なので、大きく会議のポイントは外さずまとめてくれるだろう、と考えたのです。

　結果的に無難にまとめてもらえたので、この対処は良かったと思っています。しかし、彼女の今後のスキルアップを考えると、私から直接彼女に厳しく指導を入れるべきだったのかもしれないとも思います。私はこのとき、プロジェクト自体が忙しかったために、説得・指導を行うところまで行動に移せなかったのも理由ではあります。

■分析

　彼女は、銀行系システム子会社出身というバックボーンを持っています。ここで2つポイントがあるように思われます。

1. 直接、エンドユーザーと会うことはなかった
2. 組織としての成熟度が高く、スケジュールや個々人の役割が明確に決められていた（つまり与えられた仕事のみを行っていた）

　すべての銀行系システム会社がそうだとは思いませんし、置かれている立場で異なるでしょう。

　しかし、このような前提があるメンバーと共にプロジェクトを進める場合は、プロジェクト開始前に一度じっくりと話をしておいた方が良いでしょう。その方がプロジェクト開始後が楽ですし、余りにも文句が多いようであれば、体育館裏でビシッといって、さっさとリリースさせてしまいましょう。その方がプロジェクトが円滑に回ります。

-

まとめると

　よく、「この人とは相性が合う、合わない」といったことをいいます。今回のテーマである人間関係は結局のところ自分自身のスキルの一つとなるのではと思います。

　本質的に合う・合わないはともかく、仕事を進めていく（プロジェクトを推進していく）上で、できるだけ幅広い方々（メンバー、リーダー）との打ち解けられる能力が必要になります。

　私が心掛けているのは、相手の中に一部でも尊敬できる部分（仕事上はもちろん、生活習慣であっても）を見つけられれば、どうにかなって行くのではと思います。

　そうした上で、新規のプロジェクトに参画されたり、また転職をされたりしたときに良い感じで入って行き、周りからの受入も早いと思います。

　ここまで書いて、人との付き合い方というのは、親が子供に対して教えることなのかも知れないと思い始めています。学校に入ると、「教師と波長が合う・合わない」というのが出てきます。それまでに、基本的な生活習慣と共に教えなければならないのかなぁ、と思っています。

第2回へ

point! コンピテンシーの前提は職務分析である SEの職務をチームとして考えるのも1つの方法である コンピテンシーの危険性にも注意を払う必要がある ■要約 　コンピテンシーとは「高業績者の行動特性」である。これは特定の職務ごとに決定され、どんな人がその職務で優秀な成績をあげているのかを特性的に列挙したものといえる。コンピテンシーは、その職務で必要な知識やテクニカルなスキルを通常除外して考える。職務によっては知識や技能が重要で無視できないことも少なくないからだ。ただ、もともと採用基準だったので、昇進決定の基準にはしやすい。 　情報システム部門のスタッフの業務を考えると、他部署との連携が多いようだ。ゆえに、コミュニケーション能力は必要と考えられる。同時に業務の流れを把握し、それをシステムにする仕事をしている。そのため、それに応じた幅広い知識、とりわけシステム関連の知識が問われることになる。ただ、業務知識やテクニカルなスキルは通常コンピテンシーには含まない。 　ここで難しい問題がある。心理学者のC・G・ユングが考えた外向−内向という分類などにもあるが、じっくり考えるのが得意な人はあまり活動的ではないし、活発に動き回り社交的に振る舞う人はあまり思考をめぐらすのは得手ではない。そのため、SEを採用する際にどちらがいいかは一概にいえない。ただ、たった1人で業務が完結するわけではないので、チーム数人でお互いが補完関係になって部門として業務を行えれば問題ないという考え方が、最近では米国の人事管理でも重視されてきている。 　一方、人材採用の実務などにコンピテンシーを活用する場合、“ディレールメント（キャリア上の脱線）”に注意すべきだ。

本記事へのご意見をお寄せください

managemail@atmarkit.co.jp

profile

南野 洋一（みなみの よういち） ITコンサルタント。前職で1993年から社内システムをノーツやオラクル、SAPを用いて構築を行う。当時はバブル経済が崩壊した時期で人員削減が行われる中、BPRを主眼においた仕組み構築に取り組んだ。 その後、システムコンサル系の企業に移り、製造業中心にSCM導入に従事。社内改革業務に取り組んでいる。ときには人材不足気味な中堅企業の情報システム部門の雇われマネージャを務めている

■記事の「要約」がメールで読めます■ 記事の「要約」を毎週水曜日にメールでお届けしています。 下の「＠IT情報マネジメント メールマガジン」からお申し込みください。 サンプルを見る