heyの上杉です。
この記事はhey Advent Calendar 2021 の23日目のものです。

私はテクノロジー部門と呼ばれる、アプリケーションの開発・運用を行う部署でお仕事をしています。人事制度が整っていくに従って、私たちの部門ではエンジニアリングマネージャーと呼ばれる役割、他部門においてはマネージャーの職域定義が今後の課題になってくることがわかってきました。

はじめに

マネージャーはどのようにあるべきか。
定性的な観点でよく語られることがあります。一方でその明確なスキルセット、限定するのならばハードスキル(後述します)に関しては意外と議論されていないことに気づきました。

私は企業のマネジメント領域における専門家ではありません。どこかですでに学術的な議論が存在し、定石がある気もします。もしくは企業ごとに独特で、決して一般化できる領域ではないかもしれません。この記事は社内でマネジメント経験が豊富な数人の方と話してみた感覚をもとに書かれています。

主に読者として想定したのは、インターネットサービス提供企業に勤める、エンジニア、エンジニアリングマネージャー、その他の部署のマネージャーといった方々となります。

この記事は私からの提案です。「違うんじゃないか」「この知識じゃ足りない」「その通り」「なるほど！」などとご自身の経験と照らし合わせて批判的に楽しんでいただけますと幸いです。

背景

企業の拡大や、組織内に新たな組織を作る際にマネージャーは必要な存在です。エンジニア組織も例外ではありません。

私はいくつかのインターネットサービスを提供する企業でソフトウェアエンジニアとして働いたのち、エンジニアリングマネージャーとして仕事を行うことになりました。エンジニア組織は職人組織と言えます。進歩が非常に速い分野である上に、コンピュータサイエンスやプログラミング言語など、広く深い知識やスキルが必要な領域です。職能を身につけるためには、高い集中力と多くの時間、そして知識を更新し続ける不断の努力が必要です。

エンジニアがマネージャーになる際、非常に強いプレッシャーを感じることになります。
「自分の今まで身につけた知識やスキルが無駄になるのではないか」または、「マネージャーの仕事の業務範囲、必要なスキルや知識とはなんなのか」など多くの不安や疑問がつきまといます。

これは切実な問題です。私がかつて新人のマネージャーとして仕事を始めた頃、エンジニア以外の部署のマネージャーとお話しする際に、強く知識不足を感じました。

マネージャーの知識の枠組みを作る試み

ここで議論したいのは、知識の細かな内容ではなく、マネージャー特有で必要な知識の枠組みに関してです。

現状の問題点

私たちエンジニアリングマネージャーはエンジニアとしての能力を発揮する傍ら、マネージャーとして活躍することを求められます。
その職域や能力の定義は不明瞭であり、主にピープルマネジメントの能力として語られることが多くなっているように感じます。ピープルマネジメントは人間の性質に寄り添い、組織で事をなすためには必要な能力であることに疑問はありません。しかし一方で、ピープルマネジメントのような能力は知識としての定義が難しく、曖昧な能力でもあります。

「うまくやれば良い」
マネージャーとして必要な能力はこれです。
巷にあふれる、良い「1 on 1の仕方」だとか、すごい「リーダーシップ」の方法など、大切なのは十分承知なのですが、こういったスキルだけでマネジメントは成り立つのでしょうか？
私はこれだけではマネジメントとして能力を獲得していくあたって、十分とは言えないと考えます。

マネージャーとしての仕事は定義が難しい

マネージャーとしての仕事は定義が難しいです。
また、各企業によっても期待役割が不明瞭であったり、違いがあるため、「いかにしてマネージャーを目指すべきか」「マネージャーになったがうまく機能しない」などがあったり、また採用時に「マネージャーのスキル要件がない」であったり、転職などを考えたときに「マネージャーとして業務をしていたが履歴書に書けるようなポータブルな能力がない」となったりします。

ここでは定性的な「雰囲気でがんばれ」ではなく、「〇〇の能力に欠けているからその知識の獲得が必要」といったような、コミュニケーションや思考ができる状態が、能力の獲得につながるであろうという狙いがあります。あくまでも実務者としての目線から、マネージャーのスキルをソフトスキルと、ハードスキルとに分割し、知識の枠組み作りを試みます。

マネージャーの仕事

以下は、ミンツバーグによるマネージャーの役割(直訳するなら経営上の役割が正しいかもしれません)を後述する書籍、Understanding and Managing Organization Behavior からの引用を翻訳したものです。

フィギュアヘッド(Figurehead)

将来の組織の目標と目的について、従業員にスピーチを行う。新しい本社ビルをオープンする。顧客や供給業者と対応する際に従業員が遵守すべき組織上の倫理ガイドラインや行動規範について言及する。

リーダー(Leader)

部下に直接命令を出す。組織の人的、財務的資源の利用に関して意思決定を行う。組織目標の遂行のために従業員を動員する。

リエゾン(Liaison)

異なる部署や世界の様々な部署のマネージャーの業務を調整する。新製品を生産するための資源の共有のために、様々な組織と提携関係を結ぶ。

モニター(Monitor)

様々な部署やマネージャーのパフォーマンスを評価し、パフォーマンス改善のために是正処置を取る。(業界や社会で生じている変化をウォッチし、それが組織に影響しないかを検討する)

ディセミネーター(Disseminator)

組織や組織のメンバーに影響を与える組織内外の変化について組織のメンバーに情報を提供する。

スポークスパーソン(Spokesperson)

新製品の販売を促進する新規の広告キャンペーンを立ち上げる。組織の将来の目標を公衆に伝えるためにスピーチを行う。

アントレプレナー(Entrepreneur)

新製品を開発するための新規プロジェクトに組織の資源を投じる。新規顧客を獲得するために組織の世界的展開を決定する。

ディスターバンス・ハンドラー(Disturbance handler)

組織が直面する環境危機のような外部の問題や、ストライキのような内部の問題に対処するために組織の資源を素早く動員する。

リソース・アロケーター(Resource allocator)

組織の様々な部署間で組織の資源を割り当てる。予算及びマネージャーや従業員の給与を設定する。

ネゴシエーター(Negotiator)

争議を解決するために、或いは長期契約や合意に達するために、対立する供給業者や販売業者、労働組合や従業員と話し合う。

マネージャーのスキル

前章で見てきたように、マネージャーの仕事は非常に多いです。これをスキルとして分類すると大まかには以下のようになります。

• コミュニケーションのスキル

• 現状の把握をし判断する

• 資源(ヒト・モノ・カネ)のアロケーション

一行で書くならば、
「情報の収集を行い、状況を把握し、資源の配置を計画、決定する。」

上記を行うことがマネージャーのスキルと仮定します。

ソフトスキルとハードスキル

ソフトスキルとハードスキルの境界を考えるのは非常に難しいです。ここではまず、ソフトスキルを定義することで、ハードスキルとは何かの境界を探ります。

ソフトスキル

Indeedのサイトには以下のようにあります。

またasanaのサイトには以下のようにあります。

主に対人関係スキルやアティチュードなどが、ソフトスキルと言えそうです。
例えば、以下のようなものです。

説明責任能力, 適応力, 細部への注意力, 協調性, コミュニケーション能力, 対立解決能力, 創造性, クリティカルシンキング, 心の知能 (EI), 共感力, 柔軟性, 革新性, リーダーシップ, 1 on 1、整理力, 根気強さ, 対人スキル, 問題解決能力, 責任感の強さ, 自己認識力, 戦略的思考スキル, チームワーク力, タイムマネジメント, よい勤労態度

諸説あり、その区切りは明確ではありません。

ハードスキル

しかし、なんとなく見えてきました。
この記事ではマネジメントスキルが、「情報の収集を行い、状況を把握し、資源の配置を計画、決定する。」と仮説しましたので、そこから前節のソフトスキルを引いたものが、ハードスキルになりそうです。

上記より、この記事はマネジメントにおけるハードスキルを以下のように定義します。

組織の他職種における専門性や仕事を理解できる能力

この定義であれば、マネージャーとしての責務を果たすために、ソフトスキルと組み合わせることで、他職種の方と、自職種(エンジニア)のプロフェッショナルとして十分な議論ができそうです。

ここでのポイントは、専門的な各職種の仕事を、マネジメントとして薄く広く知っておくということです。

エンジニアリング/開発のための知識

今回の試みはタイトルにある様に「(エンジニアリング)マネージャーに必要な」スキルとしての定義です。エンジニアとしてのスキルも当然エンジニリングマネージャーのスキルにあたります。

しかしここではソフトウェアエンジニアとしてのスキルを除外して議論を進めます。

除外するスキル項目としては

• コンピュータサイエンス

• セキュリティ

• QAの知識

など、加えて隣接する

• プロジェクトマネジメント

• プロダクトマネジメント

も除外して考えます。

これらの知識は体系があり、習得には非常に高いハードルがあります。したがって専門職としてのラベルがつけられます。
プロジェクトマネジメントのスキルは、どの職種でも必要なマネジメント能力と言えるかもしれません。しかしここではエンジニアのスキルとして扱い、マネージャーの職能からは除くこととします。

（エンジニアリング)マネージャーのハードスキル

前章までの議論で、マネージャーのハードスキルの輪郭が見えてきました。
一旦ここで、整理の意味も込めてこの記事における、フォーカスする領域を図示してみます。

おおよそ焦点が定まったところで、具体的な項目について考えていきます。

この記事におけるハードスキルの定義は
組織の他職種における専門性や仕事を理解できる能力
でした。つまり、他職種の仕事を理解できるだけの基礎知識が、ハードスキルそのものと定義できます。(他方ソフトスキルによって十分に運用可能になると考えます)

この記事ではMBAで利用されている教科書やカリキュラム、社内の数人の有識者との議論から、以下の7つの知識領域をマネージャーのハードスキルと考えました。

1. マーケティング

マーケティングは顧客満足を軸に「買ってもらえる仕組み」について考えます。後述するセールスとは異なり、継続的に成長していくために、いかに顧客のニーズを満たすかという活動です。

2. セールス

セールスは「自社の商品やサービス」を出発点とます。事業は商品やサービスを販売することによって成立・継続します。セールス部門は「商品・サービス」からスタートし「売上をいかに上げるか」を考えます。

3. アカウンティング

アカウンティングは経済活動を映す鏡と言えます。ステークホルダーに対して説明責任を果し、意思決定の礎となります。主に実務としては管理会計の知識が必要と考えます。

4. ファイナンス

財務の役割は、企業価値の最大化のために、どのような投資対象にどのくらい投資するか、どのような手段で必要な資金を調達するか、を判断し実行することです。

5. 組織(採用、人事、労務、構造、組織変革などを含む)

組織のマネジメントは、企業の目的と、生活維持や自己実現など個人の目的とをうまく適合させ、競争優位を目指しています。人・組織のマネジメントを理解し身につけるには、人間の性質を知る必要があります。

6. IT（テクノロジーマネジメントを含む)

企業の競争優位を確立するためには、ITを企業に導入し、意思決定や戦略遂行活動の質やスピード、正確性、効率性を高めることが必要です。

7. サービスマネジメント

サービス事業を成長させるには、サービスの改善以外に、新市場への進出やサービス・ラインナップの増強、サービス事業の多角化などがあります。新市場は、拠点展開と顧客層拡大に分かれます。
「ラインナップ増強」は、既存の顧客に異なるサービスを提供を意味し、「多角化」は異なる顧客に異なるサービスを提供するアプローチとなります。

補足

ここでは、経営戦略に関する知識や法律知識に関してはハードスキルとして記述しませんでした。

経営戦略は、先に紹介した知識の総合であるという認識からです。また経営戦略に含まれる領域として、ハードスキルと定義できそうな観点は、アントレプレナーシップや、グローバルマネジメント、経済学の領域などです。

法律に関しては、薄く広く全領域に関わってくる部分や、もしくは知財や訴訟など極めて専門性の高い分野でもあり、判断に迷いました。インターネット分野においては、プライバシポリシーの扱い方など法的な知識は非常に役立ちます。しかしここでは「お金のまわり方」という観点で項目としては外しました。知財を扱うサービス企業の場合、法律知識の習得が必要になります。

参考情報

この記事を書くにあたって、主に下記の書籍を参考にしました。

• グロービスMBAマネジメントブック

• グロービスMBAマネジメントブック2

• グロービスMBAミドルマネジメント

• Understanding and Managing Organization Behavior

• A Preface to Marketing Management

まとめ

マネージャーには非常に多くのハードスキルが必要なことを見てきました。加えて各専門分野領域の知識(私の場合エンジニアリング)も身につけていく必要があるわけですから、学習も一朝一夕にはいきません。

現代の企業は、多様な専門家が協働して成り立っています。マネージャーはその支柱となる存在です。こういったスキルの外観を把握することは、他職種に対する興味や尊敬につながります。お互いの専門性を尊敬しつつ、自分の強みを活かし、高レベルな議論を行うことで、仕事を楽しめるようになりますし、質の高いアウトプットを出せるようになります。

繰り返しますが、私はこういった分野における、専門家というわけではありません。故にこの記事には拙い部分や、未整理な部分も多く、議論は不足しています。この記事を社内での議論のきっかけとしていただけると幸いです。