funnel-flow-architecture について
成長・マーケティングチーム向けに、対象者、段階、流入経路、ツールを横断するコンバージョンファネルを設計する手引きです。ツールとナーチャリングを連携させ、各セグメントの次の行動を定めます。
主な機能
- 01対象者と段階のセグメント化
- 02流入経路の振り分け
- 03ツールとファネルの対応付け
- 04ナーチャリング設計
- 05ツール間のデータ連携
活用シーン
- 01ファネルの新規設計
- 02成果が伸びない成長施策の監査
- 03セグメント別ファネル経路の設計
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ rampstackco/ claude-skills --skill funnel-flow-architectureインストール後、Claude Code で/funnel-flow-architectureを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
README.mdreferences/architecture-anti-patterns.mdaudience-and-stage-segmentation.mdcommon-funnel-architecture-failures.mdcross-tool-data-flow-patterns.mdentry-point-architecture-patterns.mdfunnel-iteration-discipline.mdfunnel-measurement-patterns.mdnurture-sequence-architecture.mdtool-to-funnel-mapping.md詳細
ファネルフローのアーキテクチャ
オーディエンスと段階に合わせて、複数のツールをまたぐコンバージョンフローを設計する、シニアグロース担当者向けの実践ガイドです。ランディングページからリードマグネット、ナーチャリングシーケンス、オファー、高度なファネルへとつなげます。ツールを集めるだけでなく、ファネルのアーキテクチャを構築するための手法です。
多くのグロースプログラムでは、アーキテクチャを考えずにツールが増えていきます。チャットボット、計算ツール、クイズ、リードマグネット、ニュースレター登録フォーム、デモのCTA。それぞれのツールは単体では機能しますが、連携していません。訪問者はどれか1つのツールを利用して離脱し、その後の幅広いナーチャリングシーケンスには決して入りません。ファネルは、つながりのないツールの寄せ集めになっています。
成果を積み重ねるグロースプログラムは、別の方法を取ります。ファネルを意図的に設計するのです。異なる入口から、それぞれに適したナーチャリングシーケンスへとつなげます。段階ごとに異なるCTAを設定します。セグメントごとに異なるツールを使います。それぞれのツールは単独で存在するのではなく、より大きなアーキテクチャの一部です。
このスキルは、他の5つのグロースツール関連スキル(lead-magnet-design、calculator-design、quiz-and-assessment-design、multi-step-form-design、chatbot-flow-design)を統括するアーキテクチャスキルです。それらのスキルが個々のツール設計を掘り下げるのに対し、このスキルでは視野を広げ、ツール同士をつなぐアーキテクチャによって、各ツールの効果を積み重ねられるかどうかを扱います。
ツールを連携させたファネルの効果が積み重なる様子も、分断されたファネルの寄せ集めがビジネスへの効果を生まないままエンゲージメント指標だけを伸ばす様子も見てきた、シニアグロース担当者の視点で解説します。ツールを集めることとファネルを設計することの違いについて実践的かつ明確な見解を示し、チームのグロースプログラムに必要なのが新たなツールではなくアーキテクチャである場合は、率直に指摘します。
このスキルを使う場面:ファネルをゼロから設計するとき、各ツールは個別に機能しているのにコンバージョンが伸び悩むグロースプログラムを監査するとき、複数の接点でオーディエンスのシグナルを捉えるツール間のデータフローを設計するとき、またはどのセグメントにどのファネル経路が適しているかを判断するときです。
このスキルの対象範囲
このスキルでは、複数のツールをまたぐファネルアーキテクチャを扱います。グロースツール関連スキルの違いは次のとおりです。
lead-magnet-design、calculator-design、quiz-and-assessment-design、multi-step-form-design、chatbot-flow-designは、このスキルで設計するファネルアーキテクチャの内部で機能するツールです。それぞれ、個々のツール設計を掘り下げます。content-distributionは、コンテンツをオーディエンスに届ける方法を扱います。このスキルでは、コンテンツにたどり着いたオーディエンスが何をするかを扱います。experiment-designは、ファネルの変更を検証します。このスキルではアーキテクチャを設計し、experiment-designではそれをテストします。landing-page-copyは、ページ単位のコピーを扱います。このスキルでは、ページをまたぐアーキテクチャを扱います。- **
funnel-flow-architecture(このスキル)**は、オーディエンスと段階に応じたセグメンテーション、入口のアーキテクチャ、ツールとファネルの対応付け、ナーチャリングシーケンスのアーキテクチャ、ツール間のデータフローを扱います。
対象読者:SMBおよびミッドマーケット企業のグロースマーケティング責任者、プロダクトマーケティング責任者、マーケティングディレクター、クライアントのファネルアーキテクチャを手がける代理店、グロースプログラムをゼロから設計する創業者です。
対象外:個々のツール設計(姉妹関係にある5つのグロースツール関連スキルで扱います)、コンテンツ配信の仕組み(content-distributionで扱います)、A/Bテストの手法(experiment-designで扱います)、ページ単位のコピー(landing-page-copyで扱います)。
サイロ型ファネル vs キッチンシンク型ファネル vs マッチ型ファネル
要となる考え方です。
サイロ型ファネル。 各ツール(チャットボット、計算ツール、リードマグネット、クイズ)が独立しています。連携した導線はなく、ユーザーは1つのツールを利用して離脱し、より広範なナーチャリングシーケンスに入ることはありません。ツールが孤立しています。コスト:各ツールへの投資が相乗効果を生みません。1つのツールを利用したオーディエンスが次のステップにつながらず、チームにはツールがあってもアーキテクチャがありません。
キッチンシンク型ファネル。 全員に同じファネルを使います。オーディエンスや流入経路にかかわらず、同じナーチャリングシーケンスを配信します。SMBにもエンタープライズにも同じメールが届きます。新規訪問者にもファネル下部の訪問者にも同じCTAを表示します。すべてのセグメントでコンバージョン率が平均的な水準に後退します。コスト:ファネルは平均に最適化され、十分に対応できるセグメントはなく、下流のコンバージョンは一様に低くなります。
マッチ型ファネル。 ファネルのアーキテクチャをオーディエンスとステージに合わせます。流入経路ごとに異なるナーチャリングシーケンスへ誘導し、ステージごとに異なるCTAを表示し、セグメントごとに異なるツールを提供します。各ツールは単独の成果物ではなく、より大きなアーキテクチャの一部です。コスト:事前の設計には相当な労力がかかり、メンテナンスも必要ですが、セグメントごとの下流コンバージョンは大幅に向上します。
判定基準です。最近サイトを訪れた人を1人選んでください。その訪問者がどのセグメントに属し、どの流入経路を使い、どのナーチャリングシーケンスに参加していて、次にどのCTAが表示されるのかをチームが説明できますか?できるなら、マッチ型ファネルです。「ほかの全員と同じフローを受けた」という答えなら、キッチンシンク型ファネルです。「計算ツールを使ったけれど、次に何が起きるかは分からない」という答えなら、サイロ型ファネルです。
オーディエンスとステージのセグメンテーション
基盤となる考え方です。
原則。 ファネルのアーキテクチャは、オーディエンスとステージのセグメンテーションから始まります。セグメンテーションがなければ、すべての訪問者が同じ経路をたどり、ファネルを適合させることはできません。
オーディエンスの軸。
- 企業規模または購買者のタイプ。 個人、SMB、ミッドマーケット、エンタープライズ。
- 業界または業種。 ヘルスケア、金融、小売、テクノロジー。
- ユースケース。 オーディエンスが達成しようとしていること。
- 役職。 創業者、PM、マーケター、エグゼクティブ、IC。
- 流入元。 有料トラフィック、オーガニック、紹介、パートナー。
ステージの軸。
- 認知。 ブランドやトピックを知ったばかりの段階です。
- 検討。 選択肢を積極的に評価している段階です。
- 決定。 具体的な選択肢の中から選ぼうとしている段階です。
- 顧客。 すでに顧客であり、継続的な関係にある段階です。
交差。 オーディエンス x ステージによって、ファネルのアーキテクチャが対応するマトリックスができます。検討段階にあるエンタープライズのPMは、認知段階にあるSMBの創業者とは異なるセグメントであり、それぞれに異なる経路が必要です。
セグメンテーションの進め方。 まずは3~5つのオーディエンスと3つのステージから始めます。マトリックスは9~15のセルになります。一部のセルでは同じ経路を共有し、独自の経路が必要なセルもあります。大切なのは、全員をオーディエンスとして扱うのではなく、セグメントを意識的に定義することです。
詳細はreferences/audience-and-stage-segmentation.mdを参照してください。
エントリーポイントのアーキテクチャ
訪問者がどこから訪れ、どのように誘導されるか。
原則。 ファネルアーキテクチャでは、エントリーポイント(訪問者がどこから訪れるか)をセグメントと経路(次に何をするか)に対応付けます。
一般的なエントリーポイント。
- 有料広告のランディングページ。 訪問者は広告経由で訪れます。関心度が高く、広告で約束された内容に特化しています。
- オーガニックコンテンツページ。 訪問者は検索やコンテンツの発見を通じて訪れます。認知段階または調査段階にあります。
- 直接アクセス。 訪問者はURLを入力するか、ブックマークから訪れます。リピーターであることが多いです。
- 紹介。 訪問者はパートナーや口コミ経由で訪れます。有料広告経由よりも関心度が高い傾向があります。
- ソーシャル。 訪問者はソーシャルメディアの投稿経由で訪れます。認知段階または興味段階にあります。
- ツール経由。 訪問者は計算ツール、クイズ、チャットボットから直接訪れます。
エントリーポイントからの誘導。
- 各エントリーポイントには、想定されるセグメントと段階があります。
- エントリーポイントで最初に利用できるアクションは、想定されるセグメントと段階に合致している必要があります。
- エントリーポイントによって、その後に利用するツールや一連の流れが異なる場合があります。
具体例。 「B2B SaaSの価格設定」に関する有料広告経由で訪れた訪問者は、検討段階にあり、価格情報を探している可能性が高いです。ランディングページではそのニーズに応える必要があります(明確な価格、比較、計算ツール)。次のステップとして提示する内容も、検討段階に合ったもの(デモ、営業担当者への相談)にします。同じ訪問者でも、「B2B SaaSの価格設定戦略」に関するオーガニックブログ記事経由で訪れた場合は、認知段階にある可能性が高いです。ランディングページでは学びを提供する必要があります(価格設定戦略を詳しく解説)。次のステップとして提示する内容も、認知段階に合ったもの(コンテンツの購読、フレームワークの入手)にします。
詳細は references/entry-point-architecture-patterns.md を参照してください。
ツールとファネルの対応付け
どのツールがどのエントリーポイントに対応するか。
原則。 グロースツールキットの各ツールには、ファネルアーキテクチャ内での役割があります。ツールは、特定のエントリーポイントから訪れる特定の段階の特定のセグメントに対応します。
対応付けの例。
- リードマグネット。 認知段階から検討段階への移行に対応することが多いです。獲得したメールアドレスを使って、ナーチャリングの流れにつなげます。
- 計算ツール。 検討段階に対応することが多いです。選択肢を評価している対象者は、特定の決定を裏付けるために計算ツールを利用します。
- クイズ。 設計によって、どの段階にも対応できます。コンテンツマーケティング向けの認知クイズ、製品のマッチング向けの検討クイズ、プランの選択向けの意思決定クイズがあります。
- 複数ステップのフォーム。 意思決定段階または見込み顧客の選別段階に対応することが多いです。フォームで条件を満たした意向を把握します。
- チャットボット。 複数の段階にまたがって対応します。意図を認識して適切に誘導することで、どの段階にも対応できます。
ツールとセグメントの適合性。 ツールは、その価値提案に合致するセグメントに対応する必要があります。個人事業主向けの計算ツールでは、エンタープライズの購入者向けとは異なる入力と出力が必要な場合があります。同じ計算ツールで両方に十分対応することはできません。
ポートフォリオ型のアプローチ。 チームでは、異なるセグメントに対応する複数のツールを用意することがよくあります。アーキテクチャでは、各ツールを対応する特定のセグメントと段階に割り当てます。
詳細は references/tool-to-funnel-mapping.md を参照してください。
ナーチャリングシーケンスのアーキテクチャ
セグメントごと、ステージごとに設計します。
原則。 ステージの異なる各セグメントには、それぞれ異なるナーチャリングシーケンスを用意します。シーケンスは、オーディエンスの状況とステージに合わせます。
ステージごとのシーケンスの違い。
- 認知シーケンス。 教育的で、幅広い価値を提供し、ブランドを構築します。オファーを含める場合も、控えめにします。
- 検討シーケンス。 比較を重視し、具体的な価値を示し、製品との適合性を伝えます。デモまたはトライアルへのCTAを含めます。
- 決定シーケンス。 自信を高め、リスクを軽減し、緊急性を促します。購入または確約を直接促すCTAを含めます。
オーディエンスごとのシーケンスの違い。
- エンタープライズ向けのコンテンツ(ホワイトペーパー、事例、ROI分析)は、中小企業向けのコンテンツ(テンプレート、すぐに得られる成果、同業者の推薦コメント)とは異なります。
- 役割ごとに訴求の仕方を変えます(創業者向けのコンテンツではビジネス成果を重視し、IC向けのコンテンツでは実務の深さを重視します)。
- 業界ごとに事例と言葉遣いを変えます。
何でも詰め込んだシーケンスの失敗。 全員に同じシーケンスを使います。誰にでも送れるよう汎用的にすると、誰にも十分に響かず、コンバージョン率は一様に低迷します。
対象に合ったシーケンスの成功。 セグメントとステージに特化したシーケンスを用意します。オーディエンスは、ブランドが自分たちの状況を理解していると感じ、コンバージョンが積み重なっていきます。
詳細はreferences/nurture-sequence-architecture.mdをご覧ください。
ツール間のデータフロー
ツールからツールへコンテキストを引き継ぎます。
原則。 オーディエンスがファネル内であるツールから別のツールへ移るとき、オーディエンスのシグナルも引き継がれます。チャットボットでの会話コンテキストが計算ツールのデフォルト値に反映され、計算ツールの入力内容がリードマグネットのシーケンスに反映され、クイズの結果がデモリクエストの入力欄にあらかじめ入力されます。
ツール間のデータフローパターン。
- IDの引き継ぎ。 ログイン、オプトイン、メールアドレスによる特定など、どの時点でオーディエンスが特定されても、そのIDをツール間で引き継ぎます。
- コンテキストの取得。 あるツールからの入力内容(計算ツールの値、クイズの結果、フォームの送信内容)を、次のインタラクションに反映します。
- セグメントのタグ付け。 各インタラクションでオーディエンスにセグメント情報をタグ付けし、以降の振り分けに反映します。
- シーケンスとツールの連携。 メールシーケンスには、オーディエンスのセグメントに合った特定のツールへのリンクを含めます。
ツールがサイロ化する失敗。 各ツールが独自のデータを取得し、ツール間でデータがまったく連携されません。ユーザーが計算ツールを開くとチャットボットでの会話が忘れられ、リードマグネットを開くと計算ツールへの入力内容が忘れられます。
ファネルを統合する成功。 データが流れます。オーディエンスは一貫性のある体験を得られ、ブランドはオーディエンス固有のジャーニーに合わせてコンテンツとオファーを提供できます。
詳細はreferences/cross-tool-data-flow-patterns.mdをご覧ください。
ファネルの測定
測定すべきものと、ノイズになるもの。
原則。 ファネルの測定では、ツールの品質だけでなく、アーキテクチャの品質を明らかにします。
アーキテクチャレベルの指標。
- ツール間コンバージョン。 ツールAを利用したオーディエンスのうち、その後ツールBを利用する割合はどれくらいですか?
- シーケンスからツールへのコンバージョン。 ナーチャリングシーケンスの登録者のうち、後続のツールを利用する割合はどれくらいですか?
- セグメント別の後続コンバージョン。 プログラムの主な目標(トライアル、デモ、購入)に至るコンバージョンを、セグメントごとに測定します。
- ファネルステージの進行。 オーディエンスが、時間の経過とともに認知から検討、決定へと進む割合はどれくらいですか?
ツールレベルの指標。
- ツールごとのコンバージョン率(各ツールのスキルで説明)。
アーキテクチャレベルとツールレベルの違い。 ツールレベルの指標からは各ツールが機能しているかどうかがわかり、アーキテクチャレベルの指標からはツール同士が連携して機能しているかどうかがわかります。どちらも重要ですが、見落とされがちなのはアーキテクチャの測定です。
詳細はreferences/funnel-measurement-patterns.mdをご覧ください。
ファネルの継続的改善の指針
再設計すべきとき、改善すべきとき。
原則。 ファネルのアーキテクチャは、改善を重ねることで効果が積み上がります。一方、絶えず再設計するとその効果は失われます。どちらが適切かを見極めることが重要です。
改善すべきとき:
- 特定のツールの実績が基準値を下回っている。
- 特定のセグメントのコンバージョン率が、同種の他のセグメントより低い。
- ファネル内の特定の遷移で離脱が発生している。
- 特定のコホートで、シーケンスへのエンゲージメントが低下している。
再設計すべきとき:
- オーディエンスの構成が根本的に変化した。
- 製品またはサービスの戦略が変わった。
- 競争環境が大きく変化した。
- 改善を何度も繰り返しても期待した結果が得られず、アーキテクチャに問題があると考えられる。
絶え間ない再設計の落とし穴。 絶えず再設計するチームは、アーキテクチャの効果が積み上がる恩恵を得られません。再設計のたびに学習がリセットされ、何も蓄積されません。
アーキテクチャを固定する落とし穴。 一度も改善しないチームは、オーディエンスや市場の変化に伴ってアーキテクチャが劣化していくのを見過ごします。
適切なバランス。継続的に改善し、再設計はまれに、意図をもって行います。
詳細は references/funnel-iteration-discipline.md を参照してください。
アーキテクチャのアンチパターン
ファネルのアーキテクチャのように見えて、コンバージョンを低下させるパターンです。
サイロ化したファネルのパターン。 ツールが孤立し、アーキテクチャがありません。
何でも詰め込むファネルのパターン。 全員に同じファネルを使います。
過剰にセグメント化されたファネル。 セグメントが多すぎて維持できず、実際には区別できていません。
メンテナンスされないファネル。 アーキテクチャを一度設計したまま見直さず、劣化が積み重なります。
ツール主導のアーキテクチャ。 オーディエンスと段階ではなく、ツールを軸にアーキテクチャを構成します。オーディエンスに役立つかどうかにかかわらず、ツールごとにファネルを設けます。
指標を考慮しないアーキテクチャ。 測定を行わないため、どこで効果があり、どこで効果がないのかを診断できません。
単一ツールのファネル。 1つのツール(計算機だけ、チャットボットだけなど)に依存するため、そのツールの実績が振るわない場合に対応できません。
引き継ぎが機能しないファネル。 ツールは個別には機能していても、ツール間の移行がうまくいきません。
詳細は references/architecture-anti-patterns.md を参照してください。
フレームワーク:ファネルフローアーキテクチャに関する12の検討事項
ファネルアーキテクチャを設計または監査するときは、以下の12項目を確認してください。
- サイロ型でも、何でも詰め込む型でもなく、対象に合ったファネルを構築します。 アーキテクチャはオーディエンスと段階に合わせます。各ツールは独立した成果物ではなく、アーキテクチャの一部です。
- オーディエンスと段階のセグメントを定義します。 3〜5のオーディエンス × 3段階が、アーキテクチャの対象とするマトリックスです。
- エントリーポイントのアーキテクチャをマッピングします。 各エントリーポイントから、想定されるセグメントと段階へ振り分けます。
- ツールとファネルの対応関係を文書化します。 各ツールは、特定の段階にいる特定のセグメントに対応します。
- セグメントごとのナーチャーシーケンスアーキテクチャを設計します。 シーケンスはオーディエンスと段階に応じて変えます。全員に同じシーケンスを適用しません。
- ツール間のデータフローを統合します。 コンテキストがツール間で引き継がれ、オーディエンスが一貫した体験を得られるようにします。
- アーキテクチャレベルの指標を追跡します。 ツール間のコンバージョン、シーケンスからツールへのコンバージョン、セグメント単位の下流コンバージョンを追跡します。
- ファネルの反復に規律を持たせます。 継続的に改善し、再設計は意図的に行い、両極端を避けます。
- ツールポートフォリオのバランスを保ちます。 異なるセグメントに対応する複数のツールを用意し、特定のツールに過度に依存しません。
- オーディエンスとの適合性を正直に見極めます。 ブランドが実際に対応できるセグメントにアーキテクチャを合わせます。適合しないオーディエンスは除外するか、別の経路に振り分けます。
- 保守の責任者を明確にします。 アーキテクチャの担当者を定め、四半期ごとのレビューを予定に組み込みます。
- 拡張計画を定義します。 新しいツールを追加する際は、アーキテクチャ内での位置づけを明確にします。新しいツールは、見栄えのために追加するのではなく、必要性を示して採用されるべきです。
このフレームワークの成果は、時間とともに効果が積み上がり、オーディエンスと段階のセグメントに合致し、ツール間のデータフローを統合し、測定可能な下流コンバージョンを生み出すファネルアーキテクチャです。
必要なデータを入手できない場合
このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、承認される出力は、情報の不足を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを記載します。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足を明記すること自体が、完全な回答です。
参考ファイル
references/audience-and-stage-segmentation.md- 基礎となる資料です。オーディエンスの軸、段階の軸、それらの交差マトリックスを説明します。references/entry-point-architecture-patterns.md- 訪問者の流入経路と振り分け方法を説明します。一般的なエントリーポイントとその振り分けについて解説します。references/tool-to-funnel-mapping.md- どのツールがどのエントリーポイントとセグメントに対応するかを説明します。references/nurture-sequence-architecture.md- セグメントと段階ごとのシーケンスの違いを説明します。適合するシーケンスによる成果も紹介します。references/cross-tool-data-flow-patterns.md- IDの引き継ぎ、コンテキストの取得、セグメントのタグ付け、シーケンスとツールの統合について説明します。references/funnel-measurement-patterns.md- アーキテクチャレベルとツールレベルの指標を説明します。測定すべきものとノイズの見分け方を紹介します。references/funnel-iteration-discipline.md- 改善と再設計のタイミングを説明します。継続的な再設計と、アーキテクチャを固定してしまう落とし穴を避ける方法を紹介します。references/architecture-anti-patterns.md- ファネルアーキテクチャに見えて、コンバージョンを低下させるパターンを説明します。references/common-funnel-architecture-failures.md- 診断と改善策を含む9つ以上の失敗パターンを紹介します。
まとめ:ファネルは寄せ集めではなく、アーキテクチャです
成長プログラムの成果を積み重ねられるのは、ファネルを意図的に設計しているプログラムです。ツールを集めるのではありません。ツールを一つずつ最適化するのでもありません。設計するのです。
エンゲージメントを生み出すツールと、ビジネスの成果を生み出すファネルを分けるのが、アーキテクチャです。チャットボット、計算ツール、クイズ、リードマグネット、複数ステップのフォームは、それぞれツールです。どれもファネルではありません。それらを連携させるアーキテクチャこそが、ファネルです。
それが基準です。基準に満たないのは、各ツールが孤立したサイロ型ファネルと、誰に対しても同じ導線を用意する何でも詰め込み型ファネルです。基準を上回るのは、オーディエンスと段階のセグメンテーションに基づいて、流入経路の振り分け、ツールとファネルの対応付け、ナーチャリングシーケンスの設計、ツール間のデータ連携、アーキテクチャレベルの測定を行う、セグメントに合ったファネルです。
まとめ:ツールを連携させることで、ファネルは投資に値します
成長ツールキットの各ツールには、構築と維持のための投資が必要です。ツールが連携すれば投資の効果は積み重なり、サイロに分断されていれば投資の効果は薄まります。アーキテクチャとは、連携を実現するための規律です。
効果が積み重なる仕組みです。訪問者がやってきます。アーキテクチャは、流入経路と観察可能なシグナルに基づいて訪問者を振り分けます。最初に接するツールは、その訪問者のセグメントと段階に合ったものです。訪問者が生み出したデータは、次に接するツールに活用されます。参加するシーケンスは、訪問者の状況に合っています。やり取りのたびに、ブランドのオーディエンスに対する理解が深まり、各ツールの貢献が他のツールの貢献と相まって効果を積み重ねていきます。
迷ったときは、次の点を確認してください。プログラム内の各ツールは定義されたセグメントと段階に対応しているか、ツール同士でデータとコンテキストを共有しているか、チームはアーキテクチャを1枚の図で説明できるか、そしてツール単位の指標だけではなく、アーキテクチャレベルの成果を測定しているか。これらすべてに「はい」と答えられるなら、そのファネルは真のアーキテクチャです。一つでも「いいえ」があれば、その部分がプログラムのツール同士の連携を妨げている箇所です。