“カッツの3能力”、“カッツ理論”というものをご存知でしょうか?
マネージャーに必要なスキルを三つに大別したもので、ハーバード大学のロバート・カッツ教授が1955年に提唱しました。
非常に有名な理論のため、その紹介サイトや解説書には事欠かないですが、有名であるが故に、どうしても一般論的になりがちです。
もっといえば、エンジニアは“カッツの3能力”をどのように理解し、どう活かせば良いのかが、具体的に紹介されている資料は少ない、と感じていました。
そこで今回は、エンジニアに重点を置いて、“カッツの3能力”を具体的に見ていきたいと思います。
ということで、“カッツの3能力”で指摘されている能力を1つづつ見ていきたいと思います。
まず1つ目の能力は“テクニカル・スキル”になります。
“テクニカル・スキル”とはカッツ理論によると、“特定業務を遂行するために必要なスキル”と紹介されていますが、エンジニアにとっての“テクニカル・スキル”とは、文字通り、エンジニアとしてのテクニカル・スキルです。
具体的に言えば、プログラミング・スキルであったり、デザインパターンやフレームワークの知識、基盤設計能力やシステムテストの計画能力などもあります。
もう少し乱暴な言い方をすれば、担当者として仕事を任せてもらうために必要なスキルと言えるのかもしれません。
独立を考えているのであれば、最低限、自分のコアスキルといえる分野においては、上位者の指示がなくても単独で仕事を進められる程度のスキルは必要でしょう。
また、今まで日本のエンジニアはどちらかというと、“ある分野に特化したスペシャリスト”タイプが多かったですが、近年は、フルスタックエンジニアという言葉が話題になるように、コア分野以外においても活躍できる“ジェネラリスト型のエンジニア”が好まれる風潮があります。
コアスキルはコアスキルとして知識を深めるのも大事ですが、コアスキル以外の周辺スキルにおいても、知識を深める必要性が増しています。
“ヒューマン・スキル”とはいわゆる対人能力です。
もう少し具体的に言えば、コミュニケーション能力や交渉力、プレゼン力、働き掛けるスキル、それからリーダーシップ力などになっています。
システム開発においては、プロジェクトマネージャーを筆頭とした開発に携わる要員だけでなく、発注者(クライアント)やシステムの利用者(ユーザー)など、さまざまな関係者が登場します。
その様々な関係者と上手くやっていくためには、それ相応のコミュニケーション能力が必要です。
エンジニアの中には「コミュ障(コミュニケーション障害)だからエンジニアになった」と、自嘲半分で口にする方がたまにいますが、私に言わせればコミュ障はエンジニアになれません。
独立を考えるエンジニアであれば、チームリーダーとしてメンバーをまとめたり、あるいは上流工程にアサインされて、クライアントの担当者との打ち合わせに参加するなどの経験を持っている方も多いでしょう。
もちろん、それら現場での“ヒューマン・スキル”も重要ですが、独立を考えているのであれば、現場で使う“ヒューマン・スキル”だけにしか意識が向いていないと、少々、辛いことになるでしょう。
なぜならば、独立してフリーランスとなると、自分で仕事を取ってくる必要が出てくるからです。
仕事を得るために必要な“ヒューマン・スキルスキル”は営業的なものであり、エンジニアが案件の最前線で使われる“ヒューマン・スキルスキル”は、重なる部分も一部あるでしょうけれど、おそらく異なったものとなるはずです。
どうやれば現場に入れるか、もっといえば案件にアサインしてもらえるか、という観点に立った時、もっとも必要となる“ヒューマン・スキルスキル”は人脈を広げるためのスキルでしょう。
あるいは、仕事を紹介してもらったり、面接で有利に立てるように資格を取得するなどのセルフブランディングを行うスキルも大切になります。
“コンセプチュアル・スキル”とは、概念化能力とも言いますが、抽象的に物事を考えることができる能力です。
あまり、ピンとこない方が多いと思うので、さらにかみ砕いていえば「物事の本質を見抜き、似た事例で得た知見を応用して活用できる能力」とでも説明すれば良いでしょうか。
ロジカルシンキング(論理的思考)、クリティカルシンキング(批判的思考)、多面的視野、知的好奇心、俯瞰力、先見性などが“コンセプチュアル・スキル”の具体的な発揮例となっています。
ロジカルシンキングや知的好奇心、先見性などは、システム案件の現場でも必要と良く言われるスキルですが、“ヒューマン・スキルスキル”のときと同じで、やはり、待ちの姿勢でも仕事を得られるサラリーマンと、積極的に仕事を取っていく必要があるフリーランスでは、スコープが異なります。
案件内でエンジニアとしての“コンセプチュアル・スキル”はもちろん必要ですが、案件以外のところ、どうすれば仕事を得られるか、案件にアサインしてもらえるか、という部分についても、“コンセプチュアル・スキル”を発揮させる必要があります。
すでにご紹介した通り、 “テクニカル・スキル”、“ヒューマン・スキル”、“コンセプチュアル・スキル”という3つのスキルはいずれも重要なスキルです。
しかし、敢えて、独立したエンジニア向けに3つのスキルを重み付けすると、 “ヒューマン・スキル”が一番重要で、“コンセプチュアル・スキル”、“テクニカル・スキル”の順に重要度が下がるように感じています。
“テクニカル・スキル”が一番じゃないの? と言われそうですが、いくらエンジニアとしてのスキルが高くても、“ヒューマン・スキル”が低くてうまく人間関係を築けず、有り体にいえば嫌われ者になっていた人に対して、契約改定時に「つぎも来て欲しいので、ぜひ、契約を更改しましょう!」と声をかけるクライアントはいるでしょうか?
また、“テクニカル・スキル”というのは、3つのスキルの中で、もっとも向上させやすいスキルになります。
プログラミング能力などのITスキルの多くは、基本的には学校の勉強と同じで、知っているか、知らないかの問題であることがほとんどです。
ウィザードと呼ばれるような天才エンジニアの仲間入りを目指すためにはセンスが絶対に必要ですが、普通に業務で使う分には、センスはあまり重要ではありません。
もちろん、知らないよりも知っている方が良いに決まっていますが、その気になれば、未経験のプログラミング言語を使うことになっても(“コンセプチュアル・スキル”を駆使して、他の言語の経験を生かしながら)、現場で知識を習得して、活躍することだって可能なのです。
そのため、“ヒューマン・スキル”、“コンセプチュアル・スキル”、“テクニカル・スキル”の順にしています。
さらに敢えて、この三つのスキルの重要度を数値で表すとすれば“ヒューマン・スキル”50%、“コンセプチュアル・スキル”30%、“テクニカル・スキル”20%といったところでしょうか。
今回は独立を目指すエンジニアの方を主なターゲットとして、“カッツの3能力”についてみていきました。
カッツ理論は素晴らしいものですが、あくまで理論でしかありません。
実際の生活や業務に役立てるためには、カッツ理論について理解を深めつつ、実体験に基づくナレッジへと昇華していく必要があります。
この記事が、そのきっかけになると幸いです。
3つの質問に答えるだけで、フリーランスエンジニアとしての単価相場を算出します。 スキルやご経験にマッチする案件もあわせてご紹介いたしますので、気軽にご活用ください! ※単価相場の算出に個人情報の回答は必要ございません。