こちらは フリュー Advent Calendar 2024の２日目の記事になります。
みなさんこんにちは！ピクトリンク事業部の盛岡です。今年は２日目ですが、相変わらずポエムのような記事になります。
今回の記事ですが、いわゆるIC職の定義についての話です。
最近よく目にしているスタッフエンジニアと、弊社の仕組みについて整理したいなと思っていたので書いていきます。
フリューでのエンジニアキャリアパスについて
まずは弊社でのエンジニアが目指せるキャリアパスを少し整理してみたいと思います。
簡略化していますが、上図のようにフリューではエキスパート制度というものがあります。
マネージャーラインに乗らないキャリア形成が可能な、いわゆる専門職になります。 プリントシール機の画像処理に携わるメンバーもいれば、企画職やIT系のアーキテクト職までも同じエキスパートとして定義されています。
(今年エキスパートの面々がTech Talkを行ってますので、興味があれば参照ください)
スタッフエンジニアとは
日本では昨年から今年にかけてスタッフエンジニアに関する本が２冊発売されました。
本記事の詳細は以下の書籍に寄るところになります。
https://www.amazon.co.jp/dp/429607055X
https://www.amazon.co.jp/dp/4814400861
内容を読み進めてみるにつれて、ソフトウェアエンジニア職に限って考えてみても
- フリューでのエキスパート職が重なっている部分もある
- フリューでのエキスパート職が目指すところと若干ズレが生じている部分もある
- 上記ズレの箇所をフリューでも担う人が必要になっている
みたいな感想を抱きました。以下そのあたりを記載していきます。
4つの役割
書籍ではスタッフエンジニアはただの役割ではなく、「個人の役割と行動とインパクトの、そしてそれらすべてに対する組織の認識の総体」と呼んでいます。
その上でスタッフエンジニアの典型として４つのパターンがあり、それぞれ以下のような特徴になります。
- テックリード
与えられたチームをアプローチや実行に導く。最も一般的なアーキタイプであり、課題の着手と遂行において1つのチームまたは複数のチームを率いる。
- アーキテクト
重要分野において方向性や質、あるいはアプローチに責任を負う 。企業内の特定の複雑な技術分野において成功に導く任を追う。
- ソルバー
任意の複雑な問題を深く掘り下げ、前進する道を切り開く。会社幹部が重要と認め、かつ明確な解決策が抜けているか、もしくは実行する際のリスクが極めて高い問題にあたる。
- 右腕
補佐役として会社幹部の関心を代表し、幹部の能力と権限を借りて複雑な組織の運営にあたる。最も数が少ない。このレベルの懸案となる問題は、ビジネス、技術、プロセス、人、文化などの複数の事柄が関連していて純粋に技術的なものは少ない
フリューエキスパートとスタッフエンジニアの比較
スタッフエンジニアは、「テックリード」や「アーキテクト」での活躍が多いとされていますが、弊社のエキスパート職は若干毛色が違います。 4つの役割のうち、どれに近いかというとソルバーの役割が期待されていることが多いと感じます。これが前述の重なっている部分となります。
また、フリュー全社的なエキスパート職の位置付けと、WEBサービス部門であるピクトリンクを運営するエンジニアでは若干位置付けが変わります。ピクトリンクのエキスパートメンバーは世間一般に近い印象であり、最近ではアーキテクト方向での役割を期待される場面が多いと感じます。加えて、テックリードとしてのキャリアパス設計も必要とされていると感じます。
ここからはソフトウェアエンジニア職に絞って話を続けたいと思います。
リーダーという役職
ソルバーやアーキテクトは技術で引っ張っていくということが分かりやすい職種かと思います。ではスタッフエンジニアでは一般的な、テックリードとはどうあるべきでしょうか？ またフリューでもキャリアパスが描けそうでしょうか？
ピクトリンクの開発ではチーム開発が基本であり、昔からチーム内でリーダー職というものがあります。
リーダー職の次のステップは、プレイングマネージャーという形を取りつつマネージメントへのキャリアパスを形成することが多いポジションでした。しかし、スタッフエンジニアの仕事や求められることを照らし合わせていくと、リーダー職の先に「テックリード」として、プロジェクトを成功に導く役割を担い続ける選択肢もあっても良いのではないか思ってきました。
実際フリューの中でも、主にプリントシール機の開発いおいてはリーダー職を担っているメンバーが、製品開発をリードし高い役職に付く風潮はあります。
スタッフエンジニアの仕事
スタッフエンジニアの仕事とは本質的にはどういうものでしょうか。書籍を参考にすると以下のようにまとめられそうです。
- 技術的に問題解決を行う
- 技術的な方向性を決める
- マネージメントではなくリーダーシップを取る
また、技術的という記載にはなってはいますが、専門知識を貯めて専門的なアウトプットを個人で行う人というより、「ソフトウェア開発プロダクトに関して専門知識を用いて "あらゆること" を実施する」という役割が期待されていると感じます。
役職が上がって期待される具体的な役割は、組織の中で複数のプロジェクトが絡み合っているような状況の中でも全体を成功に導いて行けるようなリーダーシップを取る、みたいなイメージです。
※DALL-E3による「複数のプロジェクトからなる難しい製品を成功に導く人」の図
これはフリューのリーダー業務を超えている節も見受けられますが、エキスパート職の業務として定義していく価値は感じます。
技術的な分野でも、単純な課題解決はだんだんとAIに置き換わる未来も見え始めています。世界有数の技術で勝負しているわけではない一般的な企業、特にWEB系の開発組織内では様々なコラボレーションを行いプロダクトを成功に導く、エンジニアをリードするような動きを行ってくれる人たちの重要性は増しそうです。
組織に入り、組織を引っ張る
少し以外に感じるかもしれないですが、スタッフエンジニアが所属する組織は上位(複数部署を束ねる事業体の直下)のこともあれば下位(開発チームの中)のこともあるみたいです。
開発チームの中に居て一緒に解決したり、大きな組織での技術的な意思決定をサポートするという上に下にの活躍が期待されるのだろうと想像しましたが、大変なポジションと感じます。
※スタッフエンジニアA〜Dのレポートラインに正解は無いが、上位の下の方が組織的な背景は理解しやすい
スタッフエンジニアの課題感
事業における複数プロジェクトを成功に導き、上位的な課題を解決することでステップアップが期待されるスタッフエンジニアですが、キャリアを積み重ねていくと、「自分の仕事を管理・評価出来る人が居なくなっていく」というところに行き着くこともあるみたいです。
実際弊社でもこの"悩み"を持っているエキスパートやマネージャーは存在していて、多分世界中の企業でも起こっていると考えます。
この課題の解決策は何かあるのでしょうか？
解決するのはとても難しく、組織体によって取る選択肢は違うことになると考えますが、書籍の中でも色々なアクションプランの提案はあります。(書籍Aの4章や書籍Bの9章を参照してもらえればという記載にとどめておきます)
ただこの課題や悩みは、結局はマネージャー職でも同じようなことは有り得そうです。キャリアを重ねていくと、最終的に現れてくる課題要素は、組織設計や会社方針というところまで含んでくることになってきそうです。
まとめ(結局は...)
マネージャーとスタッフエンジニアを行ったり来たりすることで、良いスタッフエンジニアスキルが形成されることも多いという話もあります。また、スタッフエンジニアとして組織に認知されるために政治的な活動も必要になるでしょう。
結局はマネージャーやビジネスマンとしてキャリア形成していくのと何ら変わらないような印象を持ち、キラキラした世界を想像していると少ししょんぼりする気持ちも出たりします。
ただ、書籍Bの中であった「どうかソフトウェアに真剣に取り組んでください」という言葉に少し救われた気がします。
結局は良いものを作り上げることでしか、ソフトウェアエンジニアは評価されないのではないでしょうか。 「ソフトウェアを作りたい」とエンジニアの道を志してから、 コーディングしていれば良かった段階から離れていくことがあっても、ソフトウェアを作り上げるためにやるべきことは深く広いと感じます。
良いソフトウェアを作り、良いソフトウェアのキャリアを築いてください。そして良いソフトウェア業界を築きましょう。
それでは、明日以降もアドベントカレンダーをお楽しみください！
