優秀なエンジニアと優秀なチーム、日本企業が欲しいのはどっち？：ITエンジニアのチームリーダーシップ実践講座（16）（2/2 ページ）

[エディフィストラーニング 上村有子，＠IT]

大切なのはチーム全体の評価

　学生時代の成績などは、自分一人の頑張りに比例します。つまり、自分への評価です。これは自分にとっても周囲の人にとっても、非常に分かりやすいものでした。では、チームの評価とは何でしょうか？

　サッカーや野球、バレー、バスケットなどの団体競技を経験したことがある人なら、チーム活動の意義を体得しているかもしれません。しかし、チームの評価など考えたこともないという人も多いのではないでしょうか。上司からの評価に納得できない人もいるでしょう。そんなときは、自分がどれだけ目標を達成できたかだけではなく、チームの評価を考えてみましょう。

　企業は個人で成果を積み上げていくところではありません。個人レベルの小さな成果でも、積まないよりは積んだ方がマシかもしれませんが、それでは大きな飛躍は期待できません。企業では、積み重ねる「足し算」の成果ではなく、加速度的に拡大する「掛け算」の成果が求められるのです。

　例えば、企業が永続的に繁栄していくには、新しい人材を採用し、後継を途絶えさせることなくつなげていく必要があります。入ってきたばかりの人は、当然スキルも経験も未熟で、即戦力にはなりません。配属先のチームのメンバーが、責任を持って後継者の育成をしなければならないのです。

　現場が忙しくて満足な育成ができないのであれば、人事サイドでの集合研修が必要になるでしょう。その教育コストは誰が負担しますか？ その企業の先輩です。先輩が成果を上げて、コストを間接的に負担します。一時的に負担をしてでも、後継者の育成は必要なことだからです。

　普段現場で仕事をしていると、目先のことに気を取られ、将来へ投資する視点が失われがちです。「組織への投資」なんて経営トップが考えることで、自分たちエンジニアには無関係な話と思っていませんか？

　職場の環境や置かれた状況を視野を広げて見てみると、自分一人では何もできないことが分かります。あるいは、長期的なスパンで見てみましょう。やはり自分一人では何も動かないことが分かります。チームで動いて、まとまった成果を残していくことが必要なのです。できたかできなかったかの評価はチーム単位のものが重要視されることに、おのずと気付くでしょう。

特定の人しかできない仕事はチームのリスク

　エンジニアにありがちな勘違いの一つに、「この仕事は自分しかできない」があります。確かに、明日からすぐに同じレベルであなたの仕事を誰かが引き継げるかというと疑問です。しかし、あなたにしかできない仕事など、世の中そうそうありません。もしそんな仕事が皆さんの身近にあるのなら、それはチームがリスク管理できていないことに他なりません。

　専門性が高いのは誇らしいことですが、個人技・職人技のみを競うようなチームは方向転換が必要です。スキルをシェアし合う、情報をチーム内で共有するなど、リソースの偏在がないよう気を配るべきでしょう。「メンバーが均一になれ」という意味ではありません。個性や強みはそれぞれ尊重し、活用すべきですが、それを自分一人で囲い込んではいけないという意味です。スキルや情報が特定の人だけの特権になり、それが極端になると、チーム活動がほころびる原因になります。

スキルをシェアし合うことが大切

　例えば、「ベテランエンジニアが自分にしか分からないやり方で仕事をした」としましょう。プロジェクトの納期などのやむを得ない理由はあるでしょうが、長期的に見ると、決して望ましい姿ではないはずです。

　必要な引き継ぎはされていますか？ 後々、正常にメンテナンスできますか？

　また、早く仕事を終えたい一心で周囲が話を合わせたりご機嫌をとったりしてしまい、勘違いしたベテランがだんだんワガママになっていくという話もよく聞きます。

　そうなると現場はチーム活動どころではなくなります。プロジェクトが一段落したとき、チーム内の人間関係は元に戻りますか？ そんな人とは、もう二度と一緒に仕事をしたくないと思うのではないでしょうか？

ソフトウエア開発は「工学」

　米国から「ハッカー」という言葉が日本に入ってきたころ、伝説的な天才プログラマーがもてはやされました。一匹オオカミ的な存在の彼らに憧れるエンジニアも多いでしょう。しかし日本ではなかなか、同じようにはいきません。

　米国は組織文化と個人文化がはっきり分かれており、自分はどちらに属する人種なのかをおのおのが自覚しています。個人文化で生きたい人には、それにふさわしいコミュニティ、つまり受け皿がちゃんと用意されています。日本にはそのような受け皿はありません。

　仕事でのソフトウエア開発は、サイエンス（科学）でもアート（芸術）でもなく、エンジニアリング（工学）です。研究室で好まれそうな凝りに凝ったやり方や、人がまねできないようなユニークなやり方ではなく、実利に見合ったやり方、チームに利益をもたらすようなやり方が求められます。このように私は思います。

ポイント

独走よりもチームワーク

　次回、最終回は「協力の効能」を説明します。

「ITエンジニアのチームリーダーシップ実践講座」バックナンバー

• それは連帯責任ではありません――チームが助け合ってはならないとき
• 優秀なエンジニアと優秀なチーム、日本企業が欲しいのはどっち？
• 正しいライバルを持つべき理由
• 仕事の評価＝質×量÷？――「時は金なり」をメンバーに周知する
• 演繹法を駆使してメンバーを納得させる
• 論理思考を会話に応用する
• 情報交換スキルを高めるテクニック
• チームの立ち位置を見える化する「関係マップ」
• 会議の質を高めるために、リーダーが仕掛けるポイント
• 5つのプロセスで進める、効果的な会議ファシリテート
• 思考の癖を把握して効果的に評価する（後編）
• 効果的に指示するためのタイプ分け法（前編）
• 自分の性格や思考の癖を把握しよう
• リーダーは、目的ではなく目標を示せ
• リーダーは「分かりやすい人」であれ
• チーム活性化のために、リーダーが果たすべき役割
• 「業界で生き残る」チームに必要な条件とは？

筆者プロフィール

上村有子

エディフィストラーニング インストラクター。外資SIer、証券会社を経て2000年に野村総合研究所入社。現在、情報化戦略、コンプライアンス、ビジネスコミュニケーション領域のコース開発、講師。専門分野はBA（ビジネスアナリシス）、コミュニケーション。