- エンジニアの日常とキャリアの軌跡は、給与が 営業/マーケティング、研究開発、保守 のどの予算から出ているかに大きく左右される
- 営業/マーケティング予算のエンジニアリングはお金に近く、成果測定がしやすい一方で、スタックランキングや社内競争文化につながる可能性がある
- 研究開発予算はプロダクト組織の下で最も多くのエンジニアを雇用し、短期実験よりも四半期以上の長期的価値と資産化を重視する
- 保守予算はコスト最適化の対象として扱われ、sysadmin、古いシステムの運用、一部のプラットフォームエンジニアリング、社内ツール作業がここに該当することがある
- 自分の仕事がどの予算に属するかを知れば、成長業務の頻繁な変化、研究開発の長期投資、保守の低い優先順位をキャリア判断に反映できる
3つの予算がエンジニアリングの仕事を分ける
- ソフトウェアエンジニアリングの給与は、大きく 3つの予算 のいずれかから出る
- 予算の性質は、エンジニアの日常の働き方とキャリアの方向性に影響する
- この区分は、キャリアビジョンやポジショニングを考えるときに役立つことがある
営業/マーケティング予算: 測定可能な即時成果
- 成長組織に属するエンジニアリングは、結果を定量化しやすい
- 何かをすれば数値が上がる、という構造が比較的明確である
- この範囲には growth engineer、sales engineer、devrel のような役割が含まれる
- 既存プロダクトがより売れるようにし
- 人々に機能を知ってもらい
- 購入者がツールを業務フローに採用するのを助ける役割である
- 会社が期待するのは即時の影響である
- 利点は投資対効果を把握しやすく、仕事が直接売上につながる点である
- 測定しやすい分、人同士の比較もしやすくなる
- 従業員間のスタックランキングが生まれる可能性がある
- 一緒に問題を解く文化よりも、社内競争文化が強くなる可能性がある
- 仕事のリズムはおおむね短期中心である
- 次の実験
- 次の顧客
- 次のマーケティングの流行を追う形で続く
- 会社はこの予算に投入したお金が生み出す倍率を基準に価値を見ており、最適化を追求する過程で回転ドア効果が生じることがある
研究開発予算: 時間とともに積み上がる資産
- 研究開発、つまり R&D は最も多くのエンジニアを雇用する領域である
- 通常はプロダクト組織の下にある
- より大きな会社には、実際の研究組織や科学組織がある場合もある
- この範囲には product engineer、researcher、architect のような役割が含まれる
- 会社が販売するものを作る
- あるいは、うまく機能すれば会社が売れるかもしれない対象を探索する
- 会社が期待するのは、時間の経過に伴う成長である
- 環境は相対的に落ち着いている
- 既存ユーザーの維持と、新規ユーザーを引きつける機能とのバランスを見る
- 登録後に実利用へつながるアクティベーションを高める機能を作り、成長寄りになることもある
- 新しいプロダクトラインを探索し、研究寄りになることもある
- きちんとした研究部門がある会社では、数年間プロダクト化されないアイデアを扱う人たちもいる
- 研究開発は実質的に、異なる2つの予算が1つのカテゴリにまとめられた形である
- 開発と研究は異なるが
- 共通点は長期的な結果に焦点を当てることだ
- 関心を持つ最短の期間は四半期単位である
- エンジニアの作業は資産となり、今後数年間にわたって価値を提供するよう設計される
- 成果測定は難しいが、会社はこの仕事を投資と見なす
- プロダクトが良くなるほど、販売と維持率も良くなるという前提である
保守予算: 減らしたいコスト
- 保守はおおむね開発業務の中に吸収されてきた
- この予算が望むのはコスト最適化である
- sysadmin、古いシステムを運用し続ける人たち、ときには platform engineer がこの範囲に入る
- 会社はこの仕事を純粋なコストと見なし、最小化しようとする
- 多くの会社で保守の役割はプロダクト開発の中に広がっている
- 重要だと評価されにくい仕事だが
- 誰かが十分に不便を感じれば、結局処理されるという形である
- 会社は NFR、つまり非機能要件に対応する時間をエンジニアに与えることを、特別な福利厚生のように見せることもある
- スプリントごとに面倒な作業を処理する2日間を与える、といった状況がこれに当たる
- 社内ツールの構築もこの範囲に入ることがある
- 会社を運営するための管理者ダッシュボードはあるが
- 常に十分な優先順位を与えられるとは限らない場合である
予算上の位置がキャリア判断に与えるシグナル
- どの予算に属する仕事かが、エンジニアの日常経験を決める
- 成長業務は測定可能で変動が多い
- 研究業務はより落ち着いているが、結果は曖昧である
- 開発業務は価値があると見なされ、時間とともに積み上がる
- 保守業務はいつでも切られ得る対象として扱われる
1件のコメント
Hacker News のコメント
年収がどの予算項目から出ているかだけでなく、組織がソフトウェア開発をどう評価しているかも理解しておく必要があり、それはキャリアに大きく影響する
会社が開発時間を売るコンサルティング会社なら、顧客関係を築く能力と、そこそこのソフトウェアを素早く作る能力が評価される。ソフトウェア製品を売るプロダクト企業なら、ソフトウェアを作り運用する能力が評価される
ソフトウェアが一部含まれる、あるいはソフトウェアによって可能になる別の事業であれば、予算内で納品する能力が評価されるが、舞台の主役にはなりにくい
面白いことに、この区分は筆者が述べた3つのカテゴリーとよく対応している。コンサルティングは営業/マーケティング、プロダクトは研究開発、残りは保守に対応する
ソフトウェアスタートアップのシニアエンジニアだったときはスター扱い、ストックオプション、期待どおりのオフィス文化があったし、ITコンサルティング会社のシニアコンサルタントだったときは、良いPowerPointを作る営業担当者に近い存在でいる必要があった
請求可能時間を最大化しなければならず、プロジェクトを早く終わらせたり、最小限のコードで終わらせたりしてはいけなかった
今、自分がどこにいるかはだいたい想像がつくはず
これはパッケージ製品として買えるものではなく、たいてい複数のシステムを大幅にカスタマイズして無理やりつなぎ合わせた形で、そもそも一緒に動くよう設計されていない場合が多い
会社ごとにやり方も違う
私はこの仕事を楽しんでいるし、複数部門をまたぐシステム全体を考えるのが得意だ
問題を切り抜けるには社内政治に関する知識も必要で、まさにその点に私の価値がある
プログラマーとしても悪くはないが、プログラミングをキャリアにしてきた人の専門性には及ばない
他の2つの場合は、最小化または排除すべきコストになる
会社の中核製品を作っている場合にだけ、売上を生む資産になる
私もその失敗をして、会議に呼ばれて「どうなっていますか」と質問された直後に、「詳しいことは言わないでください」と言われた
3番で働くということは、退屈で忘れられる解決策を作ることであり、技術的には妥当でも政治的には自殺行為になる解決策を作ってしまうことがある
たとえばハードウェアメーカーで働くと、主役どころか尊重されることすら難しい
ソフトウェア人材はコストであり、できれば払いたくないコストとして扱われる
期限どおり予算未満で納品しても目立つのではなく、むしろ関心の外へ消えていく
現代の技術文化において、保守が常にリストの最下位に置かれ、予算を削られ、まともな予算をもらえないと言われるのは理解しがたい。
20年にわたり複数の会社でそうした話を聞き続けてきたが、ほとんど同意したことはない。
会社は市場に出す新機能を求めているが、同時にサービスがきちんと動くことも望んでいる。
レイオフや採用凍結の際にも、SRE 的な組織のほうが研究開発組織よりよく持ちこたえるのを見てきた。
ただし、ある会社では新しいものを作り続け、既存のものを保守することには報酬を与えない文化に変わり、社内ツールの継続的な移行、相次ぐ廃止、中途半端なマイグレーションが続いた。
プロダクトを作った人たちが昇進したあと次のポートフォリオ仕事へ移ると、新しく輝いていたものもすぐ放置され、新しいチームがまた代替品を作る。
6年の間に、ある社内ツールが4回も新しい社内ツールに置き換えられ、ユーザーは4つのツールに分散した。
単なる実行の失敗とも言えるが、ビジネスが保守を価値あるものと見なさないと言う文化は非常に有害で、自滅につながる。
開発者が新機能を追加するたびにディスク容量に1,000ドルを使い、10,000ドルの新規売上を生むとしよう。
システム管理者は大型ファイルサーバーを購入し、新しいサーバー1台が500,000ドルだとする。
官僚的な組織では、システム管理者が開発者にディスク容量の費用を社内請求し、新しいファイルサーバーが必要になったときにはすでに資金が用意されている。
うまく運営され、官僚的でない組織では、経営陣が500,000ドルの請求書は500万ドルをもたらすプロジェクトを可能にするものだと理解し、喜んで支払う。
運営のまずい組織では、500,000ドルは高すぎるし特定のプロジェクトに紐づいていないという理由で経営陣が拒否反応を示し、システム管理者は次に1,000ドル分のディスク容量が必要な人に500,000ドルを払えと言い、相手は断る。
結局、システム管理者は要求を拒否し、ログの保存期間を7日から3日に減らすよう開発者を説得することになり、いつの間にか経営陣はシステム管理者について悪いフィードバックを耳にするようになる。
説明された環境は、むしろビジネスが保守を価値あるものと見ていなかった現実のように見える。
「保守が最下位」という言葉は、そうすべきだという処方ではなく、実際に起きていることを描写している表現に近い。
なぜそうなのか、別のアプローチのほうが事業にとって良いのかまでは筆者は分析していないが、正しく動き品質が高いことを価値あるものと考えるなら、当然違う結果を望むことになる。
ただし、そのように行動する会社がごく少数なら、利害の調整に関する理由がある可能性は高い。
顧客に保守を売ることはできず、売れるのは機能だけだからだ。
開発者の立場でも、保守は避けたい仕事だ。
履歴書に保守を華やかな項目として書くのは難しく、誰もが成果やリリースしたプロジェクト、そしてモダンな技術を見たがる。
顧客が求める水準でサービスを動かし続けることは、誰にとっても優先度が高い。
障害のせいで顧客が離れるほど SRE を削りたい会社はない。
しかし SRE は伝統的な会社における運用、つまりサービスを提供するなら避けられない機能に近く、できるだけ先送りされる保守とは違う。
この観点での保守とは、技術的負債の削減、社内ツールの改善、実験の反復時間の短縮のようなもので、こうした仕事はプロダクトへの影響に比べて過小評価されがちだと思う。
この文章は後者を扱っており、3番のカテゴリに行くのはキャリア上の自殺だと言っている。
「昇進しなければ退場」タイプの人でなければ、3番で時間を過ごすことも考えられる。
もちろんソフトウェアは使われた瞬間に古びるので、自分は2番にいると思っている人たちも、実際には時間の大半を3番で過ごし、ごく小さな一部だけを2番に使っているのかもしれない。
それでも予算は年に一度、多くても数回しか配分されないため、その時点で2番に分類される場所にいるなら、依然としてより良い位置にいる。
「営業/マーケティング」と「研究開発」は会社の年次報告書で見かける分類だが、保守はそのような形では出てこない。
会社の財務諸表を読んでみるとよい。
「売上原価」や COGS、「一般管理費」、M&A のような一時費用の項目が見えるはずで、それぞれの項目は異なるダイナミクスを持ち、会社ごとにも違った働き方をする。
自分のいる業界のビジネス構造を理解することも重要。
このスレッドの中でも、ある会社がソフトウェアエンジニアリングを「価値あるものと見ていない」と判断するケースが多いが、売上総利益率が70%のソーシャルメディア企業と、15〜20%程度の自動車・航空会社を比較するのは単純すぎる。
ある業界がエンジニアをより多く採用し、より多く支払い、より多くのグッズや福利厚生を提供できるのは当然だ。
同じ会社の中でも、ある製品群や機能は長期投資を受け、ある製品群は他よりマージンが高い。
予算によって、ソフトウェア製品に使えるお金は大きく変わる。
エンジニアは自分の仕事を考えるとき、会社の財務も一緒に見るべきだ。
会社は慈善団体や教会ではなく、キャッシュフロー、売上、長期戦略と製品開発コストのバランスを取らなければならない事業体だ。
この記事も良いが、patio11 の記事もコストセンターとプロフィットセンターにうまく分けて説明している。
なぜプロフィットセンターに関わるべきなのかを説得力を持って語っており、読んでいないなら他にも良い内容が多い。
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
ルール2は、そのプロフィットセンターの中で、継続的な収益性と信頼できる形で結びつく役割を担うこと。
直接お金を稼いでいなければならないわけではないが、自分が仕事を止めるとお金に直接影響が出ることが明確であるべきだ。
少し別の話だが、Swizec が数年前に書いた Serverless Handbook は非常に有用に読んだし、長年にわたって彼の思慮深く洞察に富んだメールニュースレターを楽しんできた。
彼は「やりながら学ぶ / 公開しながら学ぶ」陣営にしっかり立っていて、学ぶ過程を共有するのがとても上手い。
フォローや購読を強くおすすめする。
歴史的に、ソフトウェアエンジニアリングは IT機能の一部であり、ITは会計から始まった
機械が行う以前は、「コンピューター」は文字どおり誰かの職務だった
今日でも多くの事業では、会計が依然としてソフトウェアの主な推進力であり、予算の出どころでもある
実際には4つの予算カテゴリがある
1番目は研究開発で、通常は特別な税務処理や税額控除が適用される
2番目は営業／マーケティングで、プリセールスエンジニアや、ときには導入作業も含まれる
3番目は保守で、バグを直し、通常は特別な税務処理や控除の対象ではない非研究開発コード作業を行う開発者たちである
4番目はホスティングサービス、PaaS、SaaSにおける 運用で、通常はソフトウェアエンジニアの給与がある程度含まれる
どの予算からお金が出ていて、どんな仕事をしているのかによる税務上の影響を理解することは非常に重要で、規模が大きくなるほどはるかに複雑になる
利益センター対コストセンター モデルのほうがよいと思う
理想的には、すべての部門が売上とコストの両方に責任を持つ
測定できないなら、それはKPIの問題である
KPIがコスト中心に設定されてミスアラインすることはあるが、だからといってその部門自体がコストセンターになるわけではない
ただ、研究開発の区分が追加されたのはよいと思う
保守中心のチームも保守コストを下げるために研究開発をすべきで、優れた営業チームが営業利益を高めるために研究開発をするのと同じだと思う
それぞれ異なる洞察を与え、補完し合える
私が在籍した会社で、グロースエンジニアリングの給与がマーケティング予算から出ていたところはなかった
「保守予算」というものも別にはなく、すべて単純に研究開発／エンジニアリングだった
チームや役割によって期待値が大きく異なることはあり得るが、それは予算の問題ではなく、会社が目標をどう追跡するかに依存する
今お金を稼いでいるか、長期的な価値を作っているか、既存製品の中で徐々に沈んでいるかの3つのうちどれかである