CARTAで「事業をエンジニアリングする」とはどういうことか

こんにちは、CARTA ZERO CTOの河村（@r_kawaiimura）です。

昨年末、社内のエンジニアに向けて「事業をエンジニアリングするとはどういうことか」というドキュメントを書きました。社内で数多くの「いいね」をもらい、思いのほか反響があったので、対外向けに再構成してお届けします。

前提 - 想定読者とモチベーション

主な想定読者は、ソフトウェアエンジニアリングを生業とし、チーム内で技術的判断に影響を与える立場にあるエンジニアです。具体的には、特定の技術領域で頼れる存在として認識され、アーキテクチャ設計や技術選定に関与できるレベルを想定しています。

しかしキャリアのどの段階にいる方にとっても、エンジニアとしての北極星を確認する機会となるはずです。

CARTAのエンジニア組織には「事業をエンジニアリングする」という言葉があります。書籍『事業をエンジニアリングする技術者たち』でも掲げたこの考え方は、私たちのエンジニアリング文化の核にあるものです。しかし近年、この言葉が形骸化し、自らの中核が空洞化していないだろうか、と考えています。本稿では、その本質を問い直し、社内外のエンジニアが見つめ直すきっかけを提供します。

結論から言えば「事業をエンジニアリングする」とは、技術を操り、事業課題を解決し、価値を生み出し続けることです。それは短期的な売上を追うことではなく、長期的な事業進化のために価値を届ける「仕組み」を工学的に設計し、実装し、改善し続けることです。

導入 - あなたの前にある「見えない壁」

ソフトウェアエンジニアとして仕事をしていると、どこかのタイミングでこんな感覚に出会うことがあります。

技術力は上がっている。タスクも着実にこなせる。フレームワークの選定もできるし、パフォーマンス改善だって任せてもらえる。しかし、「自分はエンジニアとして成長しているのだろうか」という問いに、自信を持って頷けない。

もしその感覚に覚えがあるなら、あなたは今まさにある壁の前に立っています。そしてこの壁は、技術力を高めるだけでは超えられません。

壁の手前 - 「正しくやっている」のに何かが足りない

典型的なパターンを描いてみましょう。

朝、Slackでマネージャーからissueが割り当てられる。「ユーザーが商品を比較できる機能がほしい」という要望だ。あなたはそれを受け取り、技術的な実装方法を考え始める。ReactでUIコンポーネントを作り、バックエンドAPIを叩いて、データベースから商品情報を取得する。テストを書き、コードレビューを受け、デプロイする。機能はリリースされ、あなたは次のチケットに取り掛かる。

あるいは、「システムが遅い」という報告を受ける。あなたはプロファイラを回し、N+1クエリを発見し、eager loadingで解決する。パフォーマンスは改善され、あなたは満足する。

または、技術選定の場面。「新しいマイクロサービスを作るなら、GoかRustか」という議論になる。あなたはパフォーマンスベンチマークを調べ、エコシステムの充実度を比較し、チームの習熟度を考慮して、どちらかを選ぶ。

これらはすべてプロフェッショナルな仕事です。間違いなく価値があります。しかし、気づいているでしょうか。これらはすべて「与えられた問題を技術で解いている」のであって、「解くべき問題を自ら見定めている」わけではありません。

この二つの間にある隔たりこそが壁の正体です。私自身、長い間この壁の存在に気づかないまま、技術を使いこなすことがエンジニアとしての成長だと思い込んでいました。

CARTAではこの壁の向こう側にあるものを、「事業をエンジニアリングする」と呼んでいます。技術を操り、事業課題を解決し、価値を生み出し続けること。では、その具体的な中身とは何でしょうか。

エンジニアリングと本質 - エンジニアとは「問題を解く人」

結論から書きます。エンジニアの本質は「道具を使う人」ではなく、「問題を解く人」です。つまり技術を使うことではなく、技術を使って何を解決するかを考えることを意味します。

「Engineer」という言葉の語源を知っていますか？ラテン語の「ingenium」に由来します。これは「生まれ持った才能」「創意工夫」を意味する言葉です。中世において、エンジニアとは城壁を攻略するための攻城兵器を設計する者たちを指していました。彼らは与えられた制約の中で、知恵を絞り、創意工夫して問題を解決しました。

エンジニアリングとは、制約条件の中で問題を構造化し、トレードオフを理解し、最適解を設計・実装する営みです。

ここで重要なのは、「問題を構造化する」という部分です。与えられた問題をそのまま受け取るのではなく、その問題が本当に解くべき問題なのかを問い、問題をより小さな部分問題に分解し、それぞれの関係性を理解します。

例えば、「商品比較機能がほしい」という要望があったとき、表面的なエンジニアはそれをそのまま実装するでしょう。しかし、本質思考を持つエンジニアは問いかけます。

「なぜユーザーは商品を比較したいのか」
「比較することで何を意思決定しようとしているのか」
「比較機能がなければ、ユーザーは何に困っているのか」

深堀りの中でユーザーが本当に欲しいのは比較機能ではなく、「自分に最適な商品を見つける」という体験なのだと気づくでしょう。ならば、比較UIを作ることよりも、レコメンデーションアルゴリズムを改善する方が本質的かもしれません。あるいは、商品の説明文自体を改善する方が効果的かもしれません。

これがエンジニアリングです。

「事業をエンジニアリングする」とは - 技術と事業の両方を俯瞰し作る

事業とは、問題の集合体です。顧客が抱える問題、組織が抱える問題、市場が抱える問題。それらを解決することで価値を生み、対価を得ます。これが事業の本質です。

「事業をエンジニアリングする」とは、この問題の集合体に工学的アプローチで立ち向かうことを意味します。ビジネス課題を技術的制約と照らし合わせて分解し、実現可能性を見極め、スケールする仕組みを設計します。

ここで重要なのは、「コードを書く前の思考プロセス」です。

「事業をエンジニアリングする」エンジニアは、目標を聞いた瞬間に実装を考え始めません。まず目標そのものを分解し、本当に解くべき問題を見定め、技術的な実現可能性と照らし合わせます。場合によっては、目標の立て方自体に疑問を投げかけることもあります。

たとえば「MAUを10倍にしたい」という目標があったとしましょう。「機能を追加しよう」「UIを改善しよう」ではなく、まずMAUの構成を分解する。新規獲得・継続率・離脱率のどこにレバーがあるのか。システムは10倍のトラフィックに耐えうるのか。そもそも「10倍」はアーキテクチャの根本的な見直しなしに成立するのか——こうした問いを立てるところから始めます。

これらの判断に必要なのは、コーディングスキルだけではありません。システム思考であり、トレードオフの理解であり、技術と事業の両方を俯瞰する視点です。これこそが「事業をエンジニアリングする」ということです。

「価値を届ける」の誤解 - エンジニアの役割は売上を上げる「仕組み」を作ること

最近、こんな言葉をよく聞きます。

「エンジニアもビジネスを理解すべきだ」
「ユーザーに価値を届けよう」
「事業貢献を意識しよう」

一見、正しく聞こえます。しかし、この掛け声の下で危険なことが起きています。エンジニアが売上やコンバージョン率といった経営指標を直接追いかけ始めるのです。

ここではっきりさせておきましょう。エンジニア組織は、会計上の役割区分としてコストセンター¹です。

これは劣っているという意味ではありません。役割の違いです。売上を上げるのは営業やマーケティングの仕事であり、事業戦略を描くのは経営陣の仕事です。

エンジニアがやるべきは、彼らが定義した「何を届けるか」を、技術的に「どう届けるか」に変換し、確実に・効率的に・持続可能に実現することです。

直接売上を上げるのではありません。コストの対価として売上を上げる「仕組み」を作るのです。私たちが作る「仕組み」こそが、売上をより伸ばすための唯一のレバレッジなのです。

この境界を理解せず、エンジニアが経営指標に直接貢献しようとすると、本来のエンジニアリングが疎かになります。「とにかく機能を増やせばユーザーが増える」という短絡的な思考に陥り、技術的負債が積み上がり、システムの保守性が失われ、結果として開発速度が落ちます²。そして、経営層や営業から「もっと速く開発しろ」というプレッシャーに晒され、さらに品質を犠牲にする悪循環に陥るのです。

「価値を届ける」とは何か。それは、ビジネスサイドと共に定義した価値を、システムを通じて正確に届けるエンジニアリングのことです。システムの可用性を99.9%に保つこと、レスポンスタイムを100ms以下にすること、デプロイ頻度を週1回から1日10回に上げること、障害発生時のMTTRを30分以内にすること。これらはKPIダッシュボードには現れないかもしれませんが、事業を支える確かな価値です。

あなたが開発した機能が直接売上を生むことは少ないでしょう。しかし、あなたが設計したアーキテクチャが、事業の将来の成長を可能にします。あなたが書いたテストが、品質を保証します。あなたが改善したCI/CDパイプラインが、チーム全体の生産性を上げます。これがエンジニアの価値です。

コンバージョン率の改善も確かに重要です。しかし、それと同じくらい、コードレビューの質を高めることにも価値があります。A/Bテストの結果から学ぶことも大切です。しかし、モニタリング基盤を整備し、システムの健全性を可視化することも同等に重要です。

短期的な数値への貢献と、長期的な技術基盤の構築。どちらも必要ですが、後者を疎かにすると、前者もいずれ実現できなくなります。エンジニアリングの本質は、この両立にあります。

本質思考を持つエンジニアの5つの視点 - 優れたエンジニアの共通点

では、「事業をエンジニアリングする」ために必要な能力とは、具体的にどのようなものでしょうか。優れたエンジニアに共通する思考様式を5つ挙げてみます。

1. システム全体を見通す視座

部分と全体の関係性を理解し、局所的な変更が全体に及ぼす影響を予見する力です。

本質思考を持つエンジニアは、目の前のコードだけでなく、それが全体の中でどういう役割を果たすのか、他のコンポーネントとどう相互作用するのか、将来的にどう拡張されるのかを常に意識しています。

たとえば、データベースのテーブルを一つ追加するとき、クエリパフォーマンスへの影響、バックアップ戦略への影響、データ移行の複雑さ、これらすべてを視野に入れて判断します。こうした視野の広さが、日々の設計判断の質を左右します。

2. 本質を見抜く抽象化能力

「何が本質・偶然か」を見抜き、適切なレベルで構造を整理する力です。

似たようなコードを書いているとき、そこに共通のパターンを見出し、適切なレベルで抽象化します。過度に抽象化して複雑にすることもなく、重複を放置することもありません。このバランス感覚は、本質と偶然を切り分ける目から生まれます。

本質志向を持つエンジニアは、問題の本質的な構造を理解し、それを表現する最適な抽象化レベルを選択します。

3. トレードオフを明確に言語化する力

技術的な判断に伴うメリット・デメリットを、チームや事業のフェーズに照らして説明できる力です。

「このアプローチとこのアプローチ、どちらが良いか」という問いに対して、単に好みや新しさで答えることはしません。パフォーマンス、保守性、開発速度、学習コスト、それぞれの軸での位置づけを明確にし、今のチームや事業のフェーズにおいてどの軸を優先すべきかを説明できます。

技術的な判断には必ずトレードオフが存在します。それを言語化し、ステークホルダーと共有できることが、エンジニアリングの質を高めます。

4. 変更の波及を予見する能力

一つの変更がシステム全体にどう波及するかを見通し、見えないリスクを先回りして可視化する力です。

「この修正にどれくらい時間がかかるか」と問われたとき、コードを書く時間だけでなく、テストを書く時間、レビューを受ける時間、デプロイする時間、ドキュメントを更新する時間、関連するコードの調査時間、開発に付帯する工程すべてを含めた見積もりができます。ここでいう見積もりは単なる工数の見積りではありません。

そして、予想外の影響が出る可能性がある箇所を事前に特定し、リスクを明示できます。これは経験だけでなく、システムの構造を深く理解していることから生まれる能力でしょう。

5. 技術的負債の本質的理解

「動いているから問題ない」で終わらせません。動いているコードと良いコードの違いを理解しています。保守性、拡張性、テスタビリティ、これらの価値を認識し、短期的な実装スピードと長期的なシステムの健全性のバランスを取ります。

そして最も重要なのは、今日下す決断が、明日・来月・来年にどう影響するかを理解していることです。技術的負債は利息を生みます。それを返済するコストと、今それを負うことの価値を天秤にかけて判断できます。

これら5つの視点を持つエンジニアは、単にコードを書く人ではありません。事業の課題を理解し、技術で解決する人です。

あなたはこれらすべてを完璧に備えているでしょうか。おそらく、そうではないでしょう。それは恥ずべきことではありません。これらは一朝一夕には身につかないからです。しかし、意識することで、少しずつ近づくことはできます。次のセクションでは、その具体的な方法を見ていきましょう。

成長の方法 - エンジニアリングマインドの獲得

では、どうすればいいのでしょうか。

Whyから考える習慣を身につける。表面的な要求の奥には、必ず本質的な問題が隠れています。タスクを受け取ったとき、すぐに実装方法を考えるのではなく、「なぜこれが必要なのか」を問いましょう。その背景にある事業課題は何か、ユーザーのどんな問題を解決するのか、他のアプローチはないのか。この問いを繰り返すことで、本質に到達できます。

システム全体を俯瞰する視点を養う。全体像を知らずに施す変更と、全体像を知った上で施す変更では天と地ほどの差があります。自分が書いているコードが、どのレイヤーに属し、どのコンポーネントと連携し、どのデータフローの一部なのか、常に意識します。システムアーキテクチャ図を描く。データベースのER図を理解する。デプロイメントパイプラインを追う。こうした習慣が視野を広げます。

制約を味方にする思考を持つ。無限のリソースがあれば、誰でも問題を解決できます。「時間がない」「リソースがない」「技術的に難しい」、これらは制約です。しかし、制約があるからこそエンジニアリングは面白いのです。限られたリソースの中で最大の効果を出す、それがエンジニアの腕の見せ所です。

実装の前に設計で勝負する。書き直しは元のコードを書く時間の何倍もかかります。どういうインタフェースにするか、どういうデータ構造にするか、どういうエラーハンドリングにするか。紙に書く、ホワイトボードに描く、同僚に説明する。コードを書き始める前に、十分に考えましょう。

技術選定における判断軸を言葉にする。「新しいから」「流行っているから」「かっこいいから」で技術を選んではいけません。今のチームのスキルセット、事業のフェーズと戦略、システムの要件、運用の現実性、これらを総合的に判断します。そして、その判断をドキュメントに残しましょう。なぜその技術を選んだのか、何を優先したのか、どういうトレードオフがあったのか。これは将来の自分への贈り物になります。

これら5つの習慣に通底する、最も重要なことがあります。書くことより考えることに時間を費やすことです。

逆説的に聞こえるかもしれませんが、優れたエンジニアほどコードを書く時間は短いのです。なぜなら、考える時間が長いからです。問題を理解する時間、設計を練る時間、アーキテクチャを検討する時間。これらに十分な時間を使えば、実装は自然と短くなります。そして、その短い実装時間で書かれたコードは、何も考えずに書いた大量のコードよりも、はるかに価値があるのです。

結び - エンジニアとしての矜持

「事業をエンジニアリングする」とは、技術を操り、事業課題を解決し、価値を生み出し続けることです。それは短期的な売上を追うことではなく、長期的な事業進化のために価値を届ける「仕組み」を工学的に設計し、実装し、改善し続けることです。

そのためには、ソフトウェアエンジニアリングという学問と実践の中核をしっかりと身につける必要があります。システム思考、抽象化能力、トレードオフの理解、影響範囲の見積もり、技術的負債の概念。これらは一朝一夕には身につきません。しかし、日々の業務の中で意識し続けることで、少しずつ身につけていくことができるのです。

ソフトウェアエンジニアリングの本質を理解しないまま、なんとなくコードを書き、なんとなく機能をリリースし、なんとなく日々を過ごしているかもしれません。それは多くのエンジニアが一度は経験するであろうことで、恥ずべきことではありません。ただそのまま”なんとなく”を続けていくと、行き着く先は中途半端なエンジニアでしょう。

しかし、今日からそれを変えることができます。次のタスクを受け取ったとき、すぐに実装を始めるのではなく、一度立ち止まって問いましょう。「なぜこれが必要なのか」「本当に解くべき問題は何か」「より良いアプローチはないか」と。

コストセンターであることを恥じる必要はありません。むしろその役割を正しく理解し、プロフェッショナルとして全うすることに誇りを持ちましょう。あなたが書くコードは、直接的には売上を生まないかもしれません。しかし、あなたが設計するシステムが、事業の成長を可能にします。あなたが改善するアーキテクチャが、チームの生産性を上げます。あなたが積み上げる技術資産が、会社の競争力になります。

それが、エンジニアとしての矜持です。