はじめに
こんにちは。今回は、カスタマーサポートプラットフォームとして世界的な成功を収めている Intercom が公開しているエンジニアリング原則についての記事、「 Shaping the solution to maximize customer value（顧客価値を最大化するための『ソリューションの具体化』） 」を取り上げます。
「エンジニアは仕様書通りにコードを書くのが仕事」「ビジネスサイドが決めた要件に対して工数を見積もるだけ」……もしあなたのチームがそんな空気感なら、この記事は強力な処方箋になるかもしれません。
Intercom のエンジニアリング部門を牽引したリーダーが語る、「言われたものを作る」から「解決策（ソリューション）を形作る」へのシフトについて、その背景と要点を解説します。
1. 著者はどんな人物か
この記事の執筆者である Levent Ali 氏は、テック業界におけるエンジニアリング・リーダーシップの文脈で非常に注目すべき人物です。
経歴のハイライト
Levent 氏は、Intercom にて Director of Engineering（エンジニアリング・ディレクター） を務めました。特に Intercom のロンドンオフィスの立ち上げに尽力し、チームを 4 年間で 15 倍の規模に成長させた実績があります。
また、Intercom の主力機能の一つである「Custom Bots」や、AI カスタマーサポート機能「Fin」など、自動化ソリューションの開発をリードしました。
現在の活動
Intercom を離れた後は、2024 年 10 月より欧州発の急成長 HR テック企業である Personio に参画し、引き続きエンジニアリング組織のリーダーとして活動しています。
評価される理由
彼が評価される最大の理由は、「 技術とプロダクトの境界線を溶かすリーダーシップ 」にあります。単に技術的に優れたシステムを作るだけでなく、「顧客にとっての価値」をエンジニア自身が理解し、デザイナーや PM と同等の視座でプロダクト開発に関わる文化を構築する手腕に定評があります。
2. なぜこのブログが執筆されたのか（背景の考察）
この記事が Intercom のブログで公開された背景には、「 開発組織の文化こそが競争優位性である 」という強いメッセージがあります。
一般的に企業規模が大きくなると、PM が要件を決め、エンジニアが実装するという「分業（サイロ化）」が進みがちです。しかし、Intercom のようなプロダクト主導型（Product-Led）の企業にとって、その分業はスピードとイノベーションを殺す要因になります。
Levent 氏は、Intercom がなぜ高品質なプロダクトを高速でリリースできるのか、その秘密が 「Shape the solution（ソリューションを形作る）」 という原則にあることを対外的に示し、優秀なエンジニアを惹きつける（採用広報）と同時に、業界全体の開発スタンダードを引き上げようとしたのだと考えられます。
3. 記事の要点解説
記事の中で語られている重要なポイントを 3 つに整理しました。
① 「交渉」ではなく「共創」を
多くの現場では、PM が要件を出し、エンジニアが「それは実装が難しい」と突き返すような「 交渉（Negotiation） 」が行われがちです。しかし、Levent 氏はこれを否定します。
エンジニアが最初からプロセスに関わることで、「なぜその機能が必要か」を深く理解し、デザイナーや PM と共に解決策を「 共創 」する姿勢こそが、高いパフォーマンスを生むとしています。
② エンジニアは「コストの番人」である
ここで言う「コスト」とは単なる開発費だけでなく、「 システムの複雑化 」や「 将来の運用負荷 」も含みます。
非技術職のメンバーには見えにくい「その機能を作ることによる負債」を最も理解しているのはエンジニアです。だからこそ、エンジニアは「その価値に対してコストが見合わない」と判断した場合、建設的に NO を突きつけ、より効率的な代替案（トレードオフ）を提案する義務があるのです。
③ 職域を超えたオーナーシップ（Custom Bots の事例）
記事内で特に印象的なのが、 「Custom Bots」開発時のエピソード です。
当時、最適なデザイン案を作るにはデザイナーの手が足りず、プロジェクトが遅延する危機にありました。そこで、エンジニアが「デザイナーが空くのを待つ」のではなく、自らプロトタイプを作成して提案を行いました。
「それは私の仕事ではない」と言わず、エンジニアがデザイン領域に踏み込んでボトルネックを解消したこの事例は、「ソリューションを形作る」という原則が単なるスローガンではなく、実務で機能していることを証明しています。
さいごに
Levent Ali 氏が提唱する「 Shape the solution 」は、エンジニアに対し「コードを書く以上の役割」を求めています。それは一見負担が増えるように思えるかもしれませんが、実際には「納得感のない仕様」に振り回されるストレスを減らし、自分たちが生み出す価値に誇りを持つための最短ルートです。
「 私たちは仕様書の実装者ではなく、顧客の課題解決者である 」
このマインドセットを持つことこそが、強いプロダクトチームを作る第一歩なのだと感じさせてくれる記事でした。