はじめに
エンジニアとしてのキャリアを考える際、「受託開発（クライアントワーク）」と「自社開発（プロダクト開発）」のどちらに身を置くかは、非常に大きなテーマです。
今回取り上げるのは、Intercom のブログに掲載された Ian Carey 氏による記事 『Making the transition from consultant to product engineer（コンサルタントからプロダクトエンジニアへの転身）』 です。
多くのエンジニアが「コードを書く仕事なら、中身はだいたい同じだろう」と考えがちですが、著者はその認識を否定し、両者の決定的な違いを「オーナーシップ（当事者意識）」の観点から鮮やかに描き出しています。本記事では、彼の実体験に基づく洞察を解説し、なぜこの視点が現代のエンジニアに必要なのかを考察します。
1. 著者はどんな人物か
経歴のハイライト
著者の Ian Carey 氏は、現在のプロダクトエンジニア職に就く以前、長年にわたり 「コンサルタントエンジニア」 としてキャリアを積んできた人物です。
彼の経験は多岐にわたり、極めて大規模なコンサルティングファームから、クライアントワークを中心とする小規模なソフトウェアハウスまで、様々な規模の組織で受託開発に従事してきました。「固定価格（請負）」と「タイム・アンド・マテリアル（準委任）」の両方の契約形態における、エンジニア特有のプレッシャーや葛藤を深く理解しています。
現在の活動
現在は、カスタマーメッセージングプラットフォームを提供する Intercom にて、プロダクトエンジニアとして活躍しています。外部のクライアントのためではなく、自社の顧客とプロダクトのために技術を行使する立場へと転身しました。
評価される理由
彼が評価される（そしてこの記事が説得力を持つ）理由は、単に技術力の高さを語るのではなく、「 ビジネスモデルがエンジニアの働き方や心理にどう影響するか 」を言語化している点にあります。
受託開発の現場で生じる「早さ・安さ・品質」のトレードオフや、技術的負債が生まれる構造的な問題を、実体験に基づいて冷静に分析できる視座を持っています。
2. なぜこのブログが執筆されたのか（背景の考察）
この記事が執筆された背景には、大きく分けて 2 つの意図があると考えられます。
① 「コードを書く仕事」の解像度を上げるため
冒頭で彼が述べている通り、外から見ればエンジニアの仕事はすべて「黒い画面に文字を打つ作業」に見えます。しかし実際には、コンサルタントとプロダクトエンジニアは「全く別の職業」と言えるほど異なります。この認識のギャップを埋め、特に受託開発に疲弊しているエンジニアに対して「別の道（プロダクトエンジニア）」の魅力を伝える意図があります。
② Intercom への採用ブランディング
記事の最後でも触れられていますが、これは Intercom の採用活動の一環でもあります。
しかし単なる求人広告ではなく、「当社はエンジニアに『オーナーシップ』を求め、その代わりに『品質へのこだわり』と『製品への発言権』を保証する」という 企業文化の表明（カルチャーデック） としての役割を果たしています。技術力だけでなく、マインドセットが合う人材を惹きつけるためのフィルタリングとしても機能していると言えるでしょう。
3. 記事の要点解説
著者は、コンサルタントとプロダクトエンジニアの違いを以下の 3 つの観点から対比させています。
① 「早い・安い・良い」のジレンマ
-
コンサルタント時代：
プロジェクトには常に「早い・安い・良い」の三角形が存在しますが、ビジネス側（クライアント）は「早くて安い」を求めがちです。その結果、エンジニアは「良い（品質）」を犠牲にせざるを得ず、技術的負債が積み上がります。固定価格契約では「早く終わらせる」プレッシャーがかかり、時間精算契約では「説明責任（やった感）」のための作業に追われます。 -
プロダクトエンジニア時代：
「早さ」と「技術的負債」のトレードオフは依然として存在しますが、外部契約の縛りがないため、 「便宜のために品質を犠牲にする」ことはほぼありません 。長期的なプロダクトの成長が目的であるため、品質への投資が正当化されやすい環境です。
② オーナーシップ（当事者意識）の有無
-
コンサルタント時代：
作っているシステムは自分のものでも自社のものでもありません。時には自分が同意できない機能や、興味のない機能を作らなければならず、自分自身が「価値ある貢献者」ではなく「請求可能なリソース（商品）」のように感じてしまう疎外感があります。 -
プロダクトエンジニア時代：
自分の仕事に対して極めて高いオーナーシップを感じることができます。納期や予算の契約に縛られず、 「どう作るのがベストか」「プロダクトはどうあるべきか」 を考える自由と責任があります。
③ 役割の定義
-
コンサルタント時代：
仕様通りにモノを作る「実装者」としての側面が強くなります。 -
プロダクトエンジニア時代：
単なるエンジニアではなく、 「プロダクトパーソン」 であることが求められます。デザイナーが決めたものを作るだけでなく、エンジニアリングの知見を活かしてデザインや仕様そのものに意見を出し、プロダクトを改善していく役割を担います。
結論：
Ian 氏は、これら全ての根底にあるのは 「オーナーシップ」 だと結論づけています。自分が所有していると感じるものに対して、人はよりケアをし、反復的な改善を続けようとします。この責任感こそが、プロダクトエンジニアの醍醐味なのです。
さいごに
Ian Carey 氏の記事は、単なる職種紹介にとどまらず、エンジニアが「何のためにコードを書くのか」という根源的な問いを投げかけています。
もちろん、コンサルティング業務には「様々な技術に触れられる」「ドライに技術提供に徹することができる」というメリットもあり、どちらが優れているという話ではありません。しかし、もしあなたが「自分が作ったものに愛着を持ち、長期的に育てていきたい」と感じているなら、彼のようにプロダクトエンジニアへの転身を検討する価値は大いにありそうです。
自分のキャリアが「請求可能なリソース」になっていないか、それとも「プロダクトへの貢献」になっているか。この記事をきっかけに、一度立ち止まって考えてみてはいかがでしょうか。