※この記事は 2025年02月12日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
Tebikiの畑中です。
このブログポストは、スタッフエンジニアについての私見を、Tebikiのプリンシパルスペシャリストの目線から語ったものである。
Tebikiのスタッフエンジニア
Tebikiのエンジニアは、キャリアの途中から自身のキャリアパスを選択できるようになっている。 1つがマネジメント職で、もう1つがスペシャリスト職である。 マネジメント、スペシャリストという表現は、主語によって様々であり、やや相応しい表現ではないと思われる読者もいることと思う。ここでは、マネジメント職は主にピープルマネジメントに責任を持つことを意図し、スペシャリスト職は、ピープルマネジメントには責任を持たないことを意図するといった程度で受け取って欲しい。
Tebikiのマネジメント職は、エンジニアリングマネージャーと呼ばれる役割を志すキャリアである。続いて、Tebikiのスペシャリスト職は、ソフトウェア開発業界においてインディビジュアルコントリビューター（以下、IC）、スタッフプラス、プリンシパルなどと呼ばれる役割を志すキャリアとなる。
ソフトウェア開発業界において、エンジニアリングマネージャーへの注目度や、その役割の重要性は十分に語られている一方で、IC、スタッフプラス、およびプリンシパルといった役割については、十分に語られているとは言い難い。それでも近年、書籍スタッフエンジニア、書籍スタッフエンジニアの道が出版され、認知が進みつつある役割であり、彼らの存在価値や、具体的な役割について模索している企業は多いのではないかと思う。
そこで、このエントリでは、Tebikiのプリンシパルスペシャリストとしての私見を共有したいと思う。（以下、わかりやすいようプリンシパルスペシャリストはスタッフエンジニアと表記する。）
このエントリはTebikiのプリンシパルスペシャリストとしての私見である
スタッフエンジニアとは。その役割の曖昧性
Tebikiのように、マネジメント職とスペシャリスト職といった、表現は違えど、エンジニアのキャリアを2つに分岐している組織は多いのではないかと思う。そのため、スタッフエンジニアの役割は、よくエンジニアリングマネージャーの役割と比較される。
Tebikiの考えでは、エンジニアリングマネージャーはピープルマネジメントに責任を持ち、スタッフエンジニアはテックマネジメントに責任を持つ。ピープルマネジメントとは、組織活動と個人のキャリアを融合し、モチベーションとエンゲージメントを高め、組織をバランスさせ、チームの成果を引き出すこと。私はそのように考えている。
それでは、テックマネジメントに責任を持つとは、具体的にどのようなことだろうか。
スタッフエンジニアとICの違い
スタッフエンジニアと IC は、組織によって異なる意図を示すかもしれない。Tebikiにおいては、スタッフエンジニアと IC を以下のように考えている。
ICは個人による技術貢献 スタッフエンジニアと IC は、マネージャーとの対比で「部下を持たない」という表現をされることがある。Tebikiにおいてもそうだ。
部下という表現には様々な意図が含まれるが、ここではスタッフエンジニアやICが、レポートラインの集約点とならず人事評価を行わないという意図だと思って頂きたい。Tebikiにおいては、レポートラインの集約点に存在するのはマネージャーであり、多くの組織においても、人事評価はピープルマネジメントの一部とされ、マネージャーの責務であることが多いだろう。
IC は、その名の通り、個人の技術貢献によって組織に価値をもたらすことが責務だと考えている。イメージとしては研究職に近く、深い専門性を持ち、個人あるいは少数で解決の難しい技術課題を解決することや、組織に非連続的な技術進化をもたらすような振る舞いである。
スタッフエンジニアはリーダーシップによる技術貢献 一方、スタッフエンジニアの責務は、技術領域でリーダーシップを発揮することであると考えている。テックマネジメントに責任を持つとは、技術領域において、実現したい世界を語り、組織を巻き込み、そこにたどり着くことだ。
スタッフエンジニアの役割はなぜ曖昧なのか
スタッフエンジニアの役割は、リーダーシップであるという話をしたが、依然としてその役割は曖昧なままである。 その理由は、スタッフエンジニアが向き合う課題を一般化することが難しいからだと考えている。
組織のフェーズによって役割が大きく異なる そもそも、所属する組織の規模やフェーズによって、社員の役割は大きく異なる。創業時、エンジニアであるなら、個人でプロダクトを開発することに加えて、ピープルマネジメントからテックマネジメントまで、全てを1人のエンジニアが担うといったこともあるだろう。その後、組織の規模拡大に応じて、役割は別々のメンバーへと引き渡される。
私は過去に、複数の組織でエンジニアリングマネージャーを務めていた。ピープルマネジメントは、エンジニアリングとはかけ離れた専門分野であると感じた。簡単であるとはとても言えない。 ピープルマネジメントは、エンジニア組織に限らずどの集団にも存在する。目的とするのは主に人の成長であり、人の成長に対するアプローチには、目標設計、コーチング、フィードバックなど、一般化されたアプローチが存在している。各個人と向き合い、信頼を積み重ねていく過程を一般化することはできないものの、エンジニアリングマネージャーの責務を設計する側が参照可能なリソースは多く存在する。（週に1度以上の1on1を実施すること！のような）
一方、テックマネジメントを考えてみよう。 テックマネジメントが対象とするのは、ビジネスの成功である。この論には、ややアンフェアな印象を受けるかもしれない。ピープルマネジメントも最終的な目的はビジネスの成功じゃないかと。しかし、ピープルマネジメントはあくまで人の成長を目的、ゴールとしたものでなくてはならない。そうでない限り、人と信頼関係など築けるはずがない。
強調しなければいけないのは、テックマネジメントが達成しなければいけないことは、技術的な正しさや成功ではなく、ビジネスの成功である。ビジネス上の優先度に沿ったソフトウェア特性を判断し、それを組織を挙げて実行することがテックマネジメントの目的だ。ビジネス上の優先度に沿った技術的な意思決定には、一般化されたアプローチはなかなか存在しない。ピープルマネジメントも同じだと感じるかもしれないが、ここにはスタッフエンジニアの責務を設計する側が苦労するポイントがある。
人の成長は思いの外わかりやすい一方で、技術がビジネスに与えるインパクトはわかりにくい。このことが、スタッフエンジニアの役割を曖昧なものとしていると考えている。
リーダーシップとは曖昧なもの ビジネス上の優先度に沿った意思決定には、一般化されたアプローチはなかなか存在しない。この論は、リーダーシップに一般解は無いという結論とほぼ等しい。組織設計とその実行もリーダーシップに含まれるが、状況に合わせた戦略的なものほど一般化が難しい。（一部、チームトポロジーが一般化したとも言えるが） 採用計画策定プロセスとその実行などもそうだろう。そもそもケースバイケース、曖昧なのである。
リーダーシップは、組織のフェーズによって大きく考え方と実行プロセスが変化する。逆にそうであるなら、スタッフエンジニアの役割について、組織のフェーズごとに一定の傾向を導くことが出来るのではないかという思いもある。そこで、続いては、Tebikiのプリンシパルエンジニアの具体的な役割や、個人的に備えておくべきだと感じるマインドセットについて紹介する。
Tebikiのスタッフエンジニアが求められること
Tebikiがどのようなビジネスを展開しており、どのような人々が働いているかについては、ここで多くは語らない。そういった内容は、別途興味がある方のみにお伝えするとして、ここでは簡単に触れるに留める。
Tebikiは、製造や物流などの現場での技能伝承を支援する動画マニュアルプラットフォーム「tebiki現場教育」と、現場データの記録と分析を支援する現場分析プラットフォーム「tebiki現場分析」を開発・運営している。創業7年目のスタートアップ企業で、従業員数は百数十人程度の規模となっている。
私は2024年の1月に入社し、入社以来プリンシパルスペシャリストというロールで働いている。入社から1年は現場分析サービスでプロダクト開発を行い、現在は動画マニュアルサービスでプロダクト開発を行っている。
そんな私が組織に求められていることはなんであろうか。
求められることを考えるのは自分自身
そもそも、自分が何を求められいてるのかは自分で考える必要がある。 強いて言えばそれが求められていることになる。
Tebikiのプロダクトフェーズにおいて、プロダクト開発に参画し、いちメンバーとして進行を合わせて開発を進めることは大前提となる。一方で、それだけでは自分の価値を最大化できているとは言い難い。拡大を続ける組織には、社内で誰も目を向けていない重要な技術課題というものが必ず存在している。それらを見つけ出し、方針を打ち出し、組織を巻き込み、達成に向けて実行するのがスタッフエンジニアだと考えている。プロダクト開発がメインプロジェクトなのであれば、重要なサブプロジェクトを見つけ出し、そこにオーナーシップを持つ必要がある。
見つけ出したサブプロジェクトが本当に重要なものであるかは、検証しなければいけない。私の場合は、プロポーザルを書いて公開し、関係者にレビューしてもらうことで検証している。
サブプロジェクトは、頭がフレッシュな出社後90分〜120分の間に進めるようにしている。メインプロジェクトとサブプロジェクトに振り分けるリーソスバランスの感覚は、この1年でなんとなく身につけたものであり、人それぞれのやり方があるだろう。
埋もれた重要な技術課題を自ら見つけ出すこと、見つけた課題にリソースを割く手段を自ら作り出すことの2点は、スタッフエンジニアの責務の1つだと考える。
エンジニアのロールモデルになる？
書籍スタッフエンジニアの道に、「7章 今はあなたがロールモデル」という章がある。（Tanay Reilly 著, 島田 浩二 訳, 2024） 《参考文献》Tanay Reilly 著, 島田 浩二 訳. スタッフエンジニアの道 優れた技術専門職になるためのガイド. オライリー・ジャパン, 2024, 401p.
こんなことを言うと傲慢な奴だと思われるかもしれないが、私自身はこれまでのキャリアにおいて、他人に自身のロールモデルを見出したことはなかった。そもそも、どうなりたいといったビジョンを持っていなかったし考えたこともなかった。単にその時やるべきだと思ったことを選択してきたに過ぎない。実は、それは今でも変わらない。一方で、この人たちと一緒に働きたいと思うことはあった。そう思わせる理由はその人それぞれにあるような気がする。一緒に働くことで学びを得られるような人や、単にコミュニケーションが心地よいという人も。
同書には、「他の人があなたと一緒に働きたいと思うかどうかが、成功の指標です。」とも述べられている。 《参考文献》Tanay Reilly 著, 島田 浩二 訳. スタッフエンジニアの道 優れた技術専門職になるためのガイド. オライリー・ジャパン, 2024, 447p.
ロールモデルになるということがどういうことなのかは、実際まだよくわからない。しかし、一緒に働きたいと思ってもらえるような仕事をしないといけないなとは思う。これはスタッフエンジニアに限らず皆そうだろうけど。
Tebikiスタッフエンジニアの評価軸
Tebikiのスタッフエンジニアは、求められていることなどなく、自分で考える必要があると書いた。ではスタッフエンジニアの人事評価はどうすればよいのだろうか？
結論から述べると、スタッフエンジニアは、技術がビジネスの成功にどれだけ貢献したかをまとめ、評価者に認めさせる必要がある。
非連続的な組織の成長をもたらす
Tebikiは、半期に1度の人事評価がある。前回の評価では、1点だけ今後の期待値が与えられた。それは、「非連続的な組織の成長をもたらすこと」だ。
これだけ見ても十分に分かる通り、スタッフエンジニアを評価することはとても難しい。非連続的な組織の成長とはなんだろうか？それを考えるのがスタッフエンジニアであり、またそれを認めさせるのもスタッフエンジニアの仕事となる。私はこの期待値に対して、以下のロジックを組み立てて実行している。
非連続的な成長とは、成長曲線の角度を変えるものである
成長させる対象は、私が知覚した最も重要であると考える事項
最も重要であると考える事項を見つけたら、重要性を検証する
ある程度の重要性が組織に認められたなら、それを実行する
これを繰り返す。
私には、このイテレーションを半年スパンでいくつも実行することはできない。時間がかかるので、最も重要なことを選択し検証することが重要だと考えている。中長期的な視点で毎日コツコツと地道に積み上げ、いずれ大きなインパクトを出す。今はこのやり方がマッチしていると信じて、日々の仕事をしている。
スタッフエンジニアとして重視していること、備えておくべきマインドセット
以下は蛇足と感じられる内容かもしれない。興味がある方だけにお伝えする。私がスタッフエンジニアとして重視していることをまとめてみた。
顧客価値から考える
テックマネジメントの対象はビジネスの成功であると書いた。ビジネスの成功とは、顧客の成功のことだ。 何をするにせよ、顧客の課題解決に繋がりが感じられないものは受け入れられない。プロダクトマーケットフィットを探索する必要のあるフェーズならなおさらそうだ。
Tebikiのプロダクト開発は、プロダクトオーナーが起点となっている。プロダクトオーナーは、顧客の課題をユースケースとして整理する。このユースケースを深く理解するところから開発が始まる。具体的に提供する機能や、UI/UXについても、エンジニアとデザイナーが一緒になって議論する。メインプロジェクトは比較的顧客目線に立って思考しやすい領域である。
一方、スタッフエンジニアが選択するサブプロジェクトには、一見、顧客課題に繋がりが感じられないものが存在する。セキュリティ課題はまだわかりやすいが、パフォーマンス課題や、ソフトウェアアーキテクチャー課題など、重要性を理解させるのが難しい課題もある。しかし、それらも顧客課題を軸に論理展開しない限り、受け入れられるものではない。
文章で伝える
最も重要であると思ったことを、サブプロジェクトとして開始するには、検証が必要であると書いた。どのように検証するかというと、プロポーザルとしてドキュメントを書き、それを公開するのだ。
私は、何か人に情報を伝えたいときは、必ずドキュメントを共有するようにしている。これにはいくつか理由がある。
リアルタイムコミュニケーションには瞬発力が要求される
ドキュメントはオープンである
ドキュメントは残る
私は、リアルタイムコミュニケーションが得意ではない。判断をするには深い考察が必要であり、時間が必要になる。そのため、結局事前にドキュメントにまとめるか、持ち帰ることになる。また、ドキュメントならフィードバックに対するレスポンス内容も熟考できる。その場で瞬時に判断できることも無くはないだろう。しかし、コミュニケーションの軸足はドキュメントにある。
ドキュメントに感じる良い点は、コミュニケーションスタイルだけでなく、オープンであり、履歴が残ることがある。当たり前だ。 私の場合、Slackもリアルタイムコミュニケーションとして位置づけている。そのため、仕事をしている間はメンションが無ければ見ない。こんなことを書くと、気難しい人に聞こえてしまうかもしれない。しかし、一番重要なことにリソースを割くというのは、そうでないものをシャットアウトするということだ。
見ないと困ることはドキュメントにした方がよい。Slackの履歴は、30日程度で消えてしまう方がヘルシーであると思う。
人の話をよく聞く
雑談にしても何しても当てはまる。人の話はよく聞いた方が良い。 相手の話をよく聞くという行為は、最大限のリスペクト表現だと思う。
特に、ミーティングに参加している人は、それぞれが多かれ少なかれ考えを持って臨んでいる。（そうでない場合は参加する必要がないので退席してよい。） 議論の終着点云々はさておき、そもそものスタンスとして、自分と意見が一致するしないに関わらず、相手の考えをフェアに受け取る必要がある。話を途中で遮ったり、リスペクトを欠いた反応をするべきではない。
そうは言っても人間同士の相性は存在する。感情的になりそうなら、相手が2歳児だった頃を想像してみると良い。どういうわけかこれには効果がある。
フィードバックをする
実際のところ、人の話をよく聞くだけではフェアじゃない。自分の考えも伝えた方が良い。言いづらいことにこそ本質が含まれていることがある。
落ち度を指摘されることを気持ちが良いと思う人はあまり居ないはずだ。相手が嫌がることをするのは気が引ける。というか興味ないし。面倒だ — しかし、果たして本当にそうだろうか？相手が本当にフィードバックを求めているとしたら？結局のところ、自分が嫌われたくないことを正当化する理由はたくさん見つかる。
個人的にフィードバックをする際に注意していることがいくつかある。
感情的にならないこと（淡々と伝えること）
お互いが認知している事実に対して伝えること
自分の意見として伝えること
感情的になった方が良いこともあるかもしれないが、私の場合はあまりそうは思わない。おそらく、私が他人から感情をぶつけられると対処に困るからだろうと思う。そのため、私の場合はなるべく淡々と伝えるよう心がけている。
それから、お互いの認識が合っていない状態でのフィードバックも伝わり方がすれ違う傾向にあると思う。 ベタな例を出すと、遅刻の常習犯に、遅刻はしないでくださいと伝えるのはすれ違う。ルールだから守って欲しいというのもややすれ違う。認知が揃った事実に基づくフィードバックは、例えば以下のようなものだと思う。（実際に私が過去に伝えたフィードバックでもある）
「あなたが遅刻したことで、チームはいつも10分待つことになっています。具体的な不都合はないかもしれません。一方で、待たせとけばいいやと思っているなら、それは改めた方が良くないですか？」
最後は、私はこう思いますというスタンスを重視している。「普通そうですよね？一般的にそうですよね？みんなそうですよね？」ではなく、私はこう思います。（当然ながら、なぜならみんなそう言ってるからと続けてはダメ）
言わなければいけないと思ったことを言わないことは、自分に嘘をついていることになる。それに慣れてしまうと、その嘘を正当化するための理由を作り出さねばアイデンティティを維持できなくなる。そうなる前に、勇気を出して言った方が良いと考えている。特にチームでは、リスペクトを持って言いたいことを言い合える関係を作りたい。
メンタルを整える
スタッフエンジニアは、重要な技術課題を見つけ出し、それが必要であることを組織に理解させ、実行し、成果を認めさせる必要があると書いた。これは、与えられた目標を追いかける辛さとはまた違ったプレッシャーを生み出すようだ。成果が見えるまでに時間がかかるし、自分には存在価値があるのだろうかと不安にもなる。周囲からは、仕事が出来て当然と思われていることだろう。これらのことは、シンプルにメンタルに迫る。
やや大げさに書いたが、スタッフエンジニアに限らず、サラリーマンのメンタルは様々なことで削られるようだ。そこで、日頃からメンタルを整えることが重要になる。特に特別なことは何もないのだが、私の場合、以下の習慣がメンタルヘルスに効果がある。
生活リズムを安定させる 毎日同じ時間に寝て、同じ時間に起きる。それだけのことだが、習慣を維持するためのベースとなる。 私の場合は、6:00頃に起床し23:00頃に就寝する。平日、土日祝であっても基本変わることはない。例外はあるが、月に1度あるかないかくらいだろう。自分の生活リズムを一定に保つことで、その他の習慣が驚くほど身につく。
朝にジョギングをする 6:15くらいから外へジョギングに出かける。仕事が休みの日は時間に余裕があるのでウォーキングをしている。コースは決まっている。ここで10,000歩を稼ぐ。距離にすると8〜9kmくらいになり、時間にすると大体75〜80分程度になる。
耳の帯域が空いているので、ポッドキャストを消化する良い時間になる。 また、頭の中には、実は気になっていることが多く残っていたりする。悩みとでも言おうか。朝の空白の時間は、悩みを消化する良い時間にもなる。絡まった糸を解きほぐすような感覚。分かる人には分かると思う。
出かけないことを正当化する理由（寒い、気分じゃない、眠い）が見つかった場合は、素直に出かけない。なんだかんだで年の三分の一から半分くらいの頻度になっている。
自己肯定感を高める 仕事以外で、今日も頑張ったなと思えることをすると自己肯定感が高まる。私の場合、以下がそれにあたる。
筋トレをする
学習を続ける
筋トレは、手軽かつフィードバックを確実に得られる、自己肯定感を高めるおすすめメソッドだ。私の場合、誕生日に可変式ダンベルを購入し、自宅で週に2回、1回90分（大体20:00〜21:30の間）の筋トレを続けている。半年くらいやれば確実に見た目に現れる。
学習については、何かスキルを身につけることを目的としていない。単に自己肯定感を高めるためと割り切っている。毎日本を読んだり、毎日1ユニットだけ English Grammer in Use を解いたり。とにかくなんでも良い。 続けてみて感じたことだが、この程度の学習では正直何も身につかない。だからと言って、がっかりする必要はない。学習は心の栄養となる。
他にもあるが蛇足なので書かない。
おわりに
Tebikiのスタッフエンジニアとして、私見を書かせて頂いた。最後まで読んで頂きありがとうございます。
他社で活躍されているスタッフエンジニアの方には、また違った価値観をお持ちの方もいることだろう。私のエントリもそれらの1つとしてカウントして頂けるとありがたい。
最後に、Tebiki 社では、共に働くメンバーを募集しています。 やりたいことはたくさんあるので、是非話を聞きに来てください。お待ちしています。 Tebiki株式会社 の全ての求人一覧 Tebiki株式会社 の全ての求人一覧です。herp.careers
