前回の記事
連載の構成
- この記事は、マネジメントについて一人で考える Advent Calendar 2022の連載記事です
- 1記事目から読んでいただいても良いですし、気になる記事から読んでいただいても問題ありません
- 全25回分の構成は、次の通りです
- 第1〜6回：ドラッカーの『マネジメント』を中心に解説します
- 第7〜13回：『図解人材マネジメント入門』を中心に解説します
- 第14〜22回：『エンジニアのためのマネジメントキャリアパス』を中心に解説します
- 第23〜25回：私の経験談を中心に、まとめに入ります
スペシャリストは実際どうなのか
- 以前の連載記事でも書いた通り、現在マネージャーを担わせてもらっている前までは、スペシャリストとして勤務していました
- どちらも経験しているからこそ書ける、ITエンジニアのスペシャリストって実際どうなの？を書いていきます
"技術が好き"じゃないと大変
- だいたいの感情は "技術が好き"じゃないと大変 に集約されます
- まず、会社の看板を背負う感覚はいちエンジニアよりは当然増します
- 社外登壇の自己紹介で「XXX社のリードエンジニアです」と言う際、プレッシャーがすごいです
- 基礎的なことを聞かれて知らなかったら会社の看板に泥を塗ってしまうのではないか、と考えたりします
- 最新情報のキャッチアップも大切です
- スペシャリストを任命される方の場合、だいたいが趣味レベルで技術情報のキャッチアップをしています
- 困難な課題に直面した際、新たな知識の吸収が必要です
- 仕事の中で困難な課題に直面した際、あらゆる技術を調べたり試す必要が出てきます
- これらに義務感を覚えるのか、それともワクワクできるか？という適性は大きいでしょう
マネージャーと比べてどうなのか
- 正直に言ってしまうと、役割を全うし続けるハードルはマネージャーよりも高く感じます
- 理由は2点です
- 陳腐化のしやすさ
- マネジメント知識は陳腐化しづらいため、一度学んだ知識や経験は長く活用できます
- 対して技術は陳腐化が早く、情報のアップデート間隔が短いです
- もちろん、コンピュータサイエンスの知識やプログラミングの知識は一生活かせるでしょう
- しかしフレームワークやアーキテクチャが日進月歩で変わりゆく世の中です
- キャッチアップを疎かにすると、数年で枯れた技術しか使えないスペシャリストになってしまう恐れがあります
- キャッチアップにかける時間
- 陳腐化のしやすさと関連し、情報のアップデートや学習が重要になります
- ライフステージの変化により、若い頃のようにプライベートの時間が自由に使えなくなってくることも多いでしょう
- キャッチアップの時間を自由に割けなくなった場合、過去の経験で役割を全うする必要が出てきます
- 陳腐化のしやすさ
- なお後述しますが、そもそも1人が担い続けるべきか？には疑問があるので、役割を全うし続ける必要性が無いという見方もできます
ただし魅力も十分
- 結局 "技術が好き"じゃないと大変 に戻ってくるわけです
- 技術が好きで、ついつい技術トレンド追ったりプログラミングしちゃう、という方には天職でしょう
- 偏見でしょうが、マネージャーよりもスペシャリストの方が生き生きと働いている方が多く感じます
- また、プログラミング自体に魅力を感じる場合は、経験を重ねるごとにどんどんスケールアップするイメージです
- 動かなかったコードが動いたり、書いたコードで課題解決できたり、綺麗なコードがちゃんと動いた時のやりがい等
- これがスケールアップして、自分の書いたコードだけじゃなくチームの書いたコードになったり、100人規模のシステムが1万人、100万人規模と任せられるようになる等
- 技術がとにかく好きだったり、システムに関わる人を幸せにしたい、スケールさせたいと感じる人にはぜひオススメしたい役割です
いちエンジニアとスペシャリストで何が異なるのか
- では、いちエンジニアとスペシャリストは実際何が異なるのでしょうか？
- マネージャーは明らかに担う業務がガラッと変わりますが、熟練エンジニアとスペシャリストは、一見すると線引が見えづらい場合もあります
- これは会社によって大きく異なるでしょう
- そのうちの1個の考えとして、連載第3回で紹介した考えを引用します
マネージャーの上司となりうるか
- 専門家＝スペシャリスト、マネジャー＝マネージャーと読み替えてください
逆に専門家は、マネジャーの上司となりうるし、上司とならなければならない。教師であり教育者でなければならない。自らの属するマネジメントを導き、新しい機会、分野、基準を示すことが専門家の仕事である。この意味において、彼らは自らのマネジャーよりも、さらには組織内のあらゆるマネジャーよりも高い立場に立つ。
引用：マネジメント[エッセンシャル版] - 基本と原則
- この意識と実態の有無が、スペシャリスト足り得るかを分ける1つではないでしょうか
- マネージャーはマネジメントに時間を使うため、技術にばかり集中できません
- つまり技術面においては、スペシャリストがリーダーとして引っ張る必要があります
企業によって、また企業内のチームによって、テックリードの役割は多少異なるでしょうが、「tech lead」という呼称からも分かるように、これは専門のスキルとリーダーシップとが共に求められる役割であり、多くの場合「ひとりが長期に渡ってつく職位」というよりはむしろ「複数の人が順次一時的にそのすべてを担う職責群」なのです。
引用：エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- こちらでも、技術に限らずリーダーシップが言及されています
- それら素質のある方が任せられ、全うできる役割ではないでしょうか
求められるスキルは
-
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイドにおいて、次の4点が挙げられています
- アーキテクチャを把握していること
- チームプレイの大切さを心得ていること
- 技術的な意思決定を主導すること
- コミュニケーションの達人であること
- 1個だけ補足するなら、連載第3回で"専門家は専門用語を使いがちなので、翻訳するのがマネージャー"と言っていたはずなのに、コミュニケーションの達人じゃないといけないの？という矛盾についてです
- そもそも著者も書かれた時代背景やシチュエーションが異なるので多少の矛盾は出てくるでしょうが、違和感少なく補足してみると
- 対ITエンジニアは少なくともスペシャリストの仕事
- 対ITエンジニア以外の翻訳は、場合によってはマネージャーが担う
- という分担でしょうか
- そもそもマネージャーに対してさえコミュニケーションが通じないなら翻訳のしようがないです
- チームメンバー、マネージャー、社外向けアウトプットを考えると、ITエンジニアという職種内でのコミュニケーション能力は不可欠でしょう
- そもそも著者も書かれた時代背景やシチュエーションが異なるので多少の矛盾は出てくるでしょうが、違和感少なく補足してみると
終わりに
- 会社や組織によって定義がバラバラのスペシャリストについて考えてみました
- 次回はもはやマネージャー業務の一環として当たり前になりつつある、1on1について考えてみます
次の記事