<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[Vault Meshyx]]></title>
  <link>https://vaultmeshyx.com/</link>
  <description><![CDATA[Vault Meshyxは東京・渋谷のコンサルティングファームです。初回ヒアリングから48時間以内に提案書を提出。戦略立案から現場定着まで一貫して伴走します。]]></description>
  <language>ja</language>
  <atom:link href="https://vaultmeshyx.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[48時間以内に提案書を出すための思考法]]></title>
    <link>https://vaultmeshyx.com/notes/48-hour-proposal-method.html</link>
    <guid>https://vaultmeshyx.com/notes/48-hour-proposal-method.html</guid>
    <description><![CDATA[「提案書が出るまで3週間かかる」という経験をしたことがある経営者は少なくないはずです。Vault Meshyxでは、初回ヒアリングから48時間以内に初期提案書を提出することを原則としています。これは単なるスピード競争ではなく、「早く仮説を出して、早く修正する」というサイクルを回すための設計です。]]></description>
    <pubDate>2026-07-28</pubDate>
  </item>
  <item>
    <title><![CDATA[担当者が変わるたびに失われるもの：引き継ぎコストの正体]]></title>
    <link>https://vaultmeshyx.com/notes/consultant-handover-problem.html</link>
    <guid>https://vaultmeshyx.com/notes/consultant-handover-problem.html</guid>
    <description><![CDATA[コンサルティングプロジェクトの途中で担当者が変わった経験はありますか。「前の担当者はこの背景を知っていたのに」「また最初から説明しなければならない」という状況は、クライアントにとって時間とエネルギーの無駄です。Vault Meshyxがプロジェクト開始から終了まで担当者を変えない理由を、具体的に説明します。]]></description>
    <pubDate>2026-06-10</pubDate>
  </item>
  <item>
    <title><![CDATA[大きな計画より小さな実験：2週間で検証する戦略の作り方]]></title>
    <link>https://vaultmeshyx.com/notes/small-experiment-strategy.html</link>
    <guid>https://vaultmeshyx.com/notes/small-experiment-strategy.html</guid>
    <description><![CDATA[「半年かけて中期経営計画を作ったが、市場が変わって使えなくなった」という話を、複数のクライアントから聞いてきました。計画の精度を上げることに時間をかけるより、小さな実験を速く回す方が、多くの場合で良い結果につながります。Vault Meshyxが2週間単位の実験を優先する理由を説明します。]]></description>
    <pubDate>2026-05-05</pubDate>
  </item>
  <item>
    <title><![CDATA[デジタル化が「使われない」で終わる3つのパターン]]></title>
    <link>https://vaultmeshyx.com/notes/digital-transformation-failure-patterns.html</link>
    <guid>https://vaultmeshyx.com/notes/digital-transformation-failure-patterns.html</guid>
    <description><![CDATA[「Salesforceを入れたが、営業チームが使ってくれない」「Notionで情報共有を始めたが、3ヶ月で誰も更新しなくなった」。こういった話は、デジタル化支援の現場で頻繁に耳にします。ツールの問題ではなく、導入の設計の問題です。よくある失敗パターンと、それを防ぐ方法を整理します。]]></description>
    <pubDate>2026-04-14</pubDate>
  </item>
  <item>
    <title><![CDATA[シリーズA前に整えておくべきKPIの設計：基本と落とし穴]]></title>
    <link>https://vaultmeshyx.com/notes/startup-kpi-design-basics.html</link>
    <guid>https://vaultmeshyx.com/notes/startup-kpi-design-basics.html</guid>
    <description><![CDATA[シリーズAの調達を目指すスタートアップが「KPIを整理したい」と相談に来るケースが増えています。多くの場合、問題は「KPIが多すぎる」か「投資家向けのKPIと経営管理用のKPIが混在している」かのどちらかです。この記事では、KPI設計の基本と、よくある落とし穴を整理します。]]></description>
    <pubDate>2026-03-18</pubDate>
  </item>
</channel>
</rss>
