business-literacy

ビジネスリテラシー

始める前に

まず、EM に関するコンテキストを確認します。.agents/em-context.md が存在する場合は、読み込んでください。

.agents/em-context.md が存在しない場合は、詳しいアドバイスをする前に、まず最低限のマネージャープロフィールを尋ねて保存してください。役職／肩書き、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項が必要です。

特定の人物が会話の中心となっており、.agents/reports/[name].md が存在しない場合は、詳しいアドバイスをする前に、まずその人物の最低限のプロフィールを尋ねて保存してください。役職／レベル、在籍期間、強み、現在の課題または成長領域が必要です。

会話の中で、後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。安定した事実やパターンを保存し、推測、一時的な不満、未解決の解釈は保存しないでください。

回答スタイル

最初の回答は簡潔で役に立つものにしてください。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 可能性の高い診断または推奨事項を最初に述べます
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大 2～3 件します
• 次に取るべき具体的な行動を示し、必要に応じてマネージャーが使える正確な言い回しを提示します
• 関連するフレームワークには簡潔に触れますが、すべての要素を説明しないでください
• 詳細版は、直接的な回答をした後でのみ提案します

---

このスキルの使い方

• 会議で聞いたビジネス用語の意味を知りたい → よく出てくる用語
• エンジニアリングの取り組みをビジネスの言葉で説明したい → 実践での活用
• ビジネスリーダーや P&L オーナーからの信頼を築きたい → ビジネスインパクトの 3 つの層

---

回答の基本構成

EM 向けにビジネス概念を説明するときは、実務に役立つ回答にしてください。

1. 平易な定義： 財務用語を並べずに、その用語を説明します。
2. EM が気にかけるべき理由： ロードマップ、人員配置、信頼性、コスト、優先順位との関連を示します。
3. エンジニアリングの観点からの説明： エンジニアリングの取り組みが、その指標をどう改善または保護できるかを示します。
4. 例文： EM がビジネス関係者に使える言い回しを示します。
5. 注意点： 指標が誤解を招いたり、操作されたりする可能性がある箇所に触れます。

関係者向けの依頼では、エンジニアリング上の要望をビジネスの観点から簡潔に表現して締めくくります。

---

これが重要な理由

ビジネス用語を理解していなくても、エンジニアは成功できます。しかし、エンジニアリングマネージャーにはできません。影響力を持ち、関係者を説得し、ロードマップの策定に関わりたいのであれば、リーダーシップが使う言葉を話す必要があります。

こうした用語を理解することは、チームをより効果的に支援することにもつながります。エンジニアリング上の判断をビジネス成果（利益率、顧客維持率、CAC）に結び付けられれば、「このリファクタリングが必要です」から、「これによりホスティングコストが 15% 削減され、粗利益率が向上します」へと説明を変えられます。

---

よく出てくる用語

収益

ARR（年間経常収益） — サブスクリプションによる年間総収益です。SaaS 企業の中心的な指標です。リーダーシップが「ARR は 500 万ドルです」と言うとき、これを指します。

MoM（月次成長率） — 前月から翌月への成長率です。MoM 成長率 10% は非常に優れた数値です。

TAM（獲得可能な最大市場規模） — ターゲット市場を 100% 獲得した場合に得られる総収益の可能性です。投資規模を正当化するために使われます。

コスト

COGS（売上原価） — 製品の提供に直接結びつくコストです（ホスティング、インフラ、サードパーティ API など）。SaaS では、エンジニアリングチームが COGS に直接影響を与えます。

粗利益率 — (Revenue - COGS) / Revenue です。SaaS では、70～80％が健全な水準です。60％を下回る場合、顧客の支払額に対して提供コストが高いことを意味します。エンジニアリング上の意思決定が財務に表れるのはここです。 サードパーティ API への依存を減らすこと、インフラコストを最適化すること、効率を高めることは、いずれも粗利益率の改善につながります。

OpEx（営業費用） — 生産に直接結びつかない継続的なコストです。給与、賃料、マーケティング費用などが該当します。

CapEx（設備投資） — 長期的な価値をもたらす大規模な投資です。新しいデータセンターの構築は CapEx、毎月の AWS 請求額は OpEx です。

バーンレート — 会社が1か月あたりに消費する現金の額です。バーンレートが高く、収益が少ないと、事業を継続できる期間は限られます。

純利益率 — あらゆるコストを差し引いた後に残る利益です。ほとんどのスタートアップは、何年も純利益率がマイナスです。

EBITDA — 金利、税金、減価償却費、償却費控除前利益です。資金調達の影響を除いた収益性の指標です。成長後期の企業でより重視されます。

顧客

CAC（顧客獲得コスト） — 顧客1人の獲得にかかる平均コストです。マーケティングに10万ドルを費やして100人の顧客を獲得した場合、CAC は1,000ドルです。

LTV（顧客生涯価値） — 顧客との取引期間全体で得られる平均収益です。健全なビジネスでは、LTV は CAC の3～5倍が望ましい水準です。そうでなければ、成長に多くのコストがかかります。

解約率 — 一定期間内に失った顧客の割合です。気づかないうちに事業をむしばむ要因です。月次解約率が5％の場合、年間で顧客の約46％を失うことになります。

顧客維持率 — 解約率の逆です。純収益維持率（NRR）が100％を超える場合、既存顧客の利用拡大が解約による減少を上回っています。

GRR（売上総維持率） — 拡大分を除き、前年の収益のうちどれだけを維持できたかを示す割合です。

NPS（ネットプロモータースコア） — 「どの程度、当社を他の人に勧めたいと思いますか？」という質問に対するスコアです。9～10は推奨者、7～8は中立者、0～6は批判者です。

事業の健全性

デフォルト・アライブ — 資金調達をやめた場合、現在の収益成長によって現金が尽きる前に黒字化できるかを示します。できない場合は「デフォルト・デッド」です。

競争優位性 — 模倣を難しくする要素です。高度な技術、ネットワーク効果、独自データ、ブランドなどが該当します。エンジニアリング上の意思決定、特にデータやプラットフォームに関する判断は、競争優位性を築くことも損なうこともあります。

AARRR（パイレーツメトリクス） — 獲得（Acquisition）、活性化（Activation）、維持（Retention）、紹介（Referral）、収益（Revenue）です。成長のどこで課題が生じているかを診断するフレームワークです。顧客維持率が20％なら、獲得に資金をつぎ込んでも、穴の開いたバケツを満たすだけです。まずその穴を塞きましょう。

---

実践での活用

技術的な作業を提案するときは、ビジネス上の価値に置き換えて説明しましょう。

• 「このレガシー API から移行する必要があります」ではなく、「この API には年間4万ドルかかっており、障害の最大の原因になっています。これをなくせば粗利益率が向上し、顧客の解約も減らせます」
• 「プラットフォームに投資すべきです」ではなく、「現状では新機能の追加に2週間かかります。プラットフォームに投資すれば2日に短縮でき、顧客が価値を実感するまでの時間を短縮して CAC を直接改善できます」

ロードマップを見直すときは、ビジネス上の問いを投げかけましょう。現在、AARRR のどの段階が最も弱いでしょうか。まずはそこに投資しましょう。

---

ビジネスへの影響をもたらす3つのレイヤー

実際にビジネスへ影響をもたらすエンジニアリングマネージャーは、難易度が上がる順に、通常次の3つのレイヤーに取り組みます。

レイヤー1 — プロダクト： あなたとチームは、機能がどのように使われているか理解していますか？ 誰もが確認できる、機能の利用状況を示すダッシュボードを用意しましょう。プロダクトのAARRR指標を把握しましょう。リリースされても誰にも利用されない機能がもたらす影響はゼロです。

レイヤー2 — ビジネスの経済性： チームの仕事を、ビジネスが財務面で重視することに結び付けられますか？ チームが支援する事業領域の損益（P&L）を担うマネージャー、つまり「GM」を見つけましょう。話をして、相手が何を重視しているのか、チームの仕事がそれにどう結び付くのかを確認しましょう。それに答えられるようになったら、技術的な議論にビジネス指標を使い始めましょう。「年間12万5,000ドルのコストを削減できます」は、「インフラが改善します」では勝てない場面でも、相手を納得させられます。

レイヤー3 — 業界／ドメイン： ドメインの専門家と信頼感のある会話ができるほど、自社が事業を展開する業界を理解していますか？ 多くのエンジニアリングマネージャーはドメインに関心がなく、そのため非技術系のリーダーから過小評価されます。

ドメイン知識には3つのレベルがあります。

• レベル1（受動的）： 用語を知っていること。何度も耳にするのに十分理解できていない業界特有の用語は、あなたの信頼性を損ないます。毎週10～15分、業界のコンテンツ（記事、ニュースレター、LLMのチューター）に時間を使いましょう。講師のようにドメインを説明するよう頼んでみましょう。
• レベル2（共有）： 学んだことを共有すること。関連する記事と自分の考察を、同僚やPMがいる共有チャンネルに投稿しましょう。あなたがドメインに関心を持っているのを見た人は、あなたを仲間として扱うようになります。
• レベル3（当事者）： 業界を自分自身で実際に経験する具体的な方法を1つ見つけましょう。顧客に同行する、自社プロダクトを実際のユーザーとして1か月使う、あるいは（本気で取り組むなら）ドメインの認定資格を取得する、といった方法があります。ドメインを知っていることと実際に経験することの隔たりが、真剣に受け止められるか、ただ容認されるかの違いです。

---

さらに詳しく

フレームワークの出典を知りたい場合、元の記事を読みたい場合、またはこのスキルのトピックについてさらに詳しい背景を知りたい場合は、references/sources.mdを読んでください。出典となった記事（リンク付き）と書籍の一覧が記載されています。

---

関連スキル

• working-with-pm — PMはこの言葉を頻繁に使います。理解しておくと、真のパートナーになれます
• roadmap-planning — 技術的負債やプラットフォームの作業を優先してもらうには、ビジネス上の根拠が必要です
• developer-productivity — エンジニアリング指標（DORA、ベロシティ）をビジネス成果に結び付ける方法
• influence — ビジネスに精通することで、ポジショニングの第3段階（信頼されること）に直接つながります