「それ、本当に必要ですか？」— ソリューション先行を脱却し、意図から設計するアーキテクトの思考法
アーキテクトの役割は、利用部門から依頼された「解決策」をそのまま実装することではありません。表面的な要求の背後にあるビジネス上の意図（Intent）を理解し、真に価値のある解決策を導き出すことが求められます。本記事では、2026年1月に開催されたArchitect Dreamin’ Americasのワークショップ「Solving for Intent: Architects Are Not Order Takers」（ファシリテーター：Walter Spinrad - CTA、Louise Lockie - Salesforce MVP）の内容をもとに、具体的なシナリオを交えてこの考え方を解説します。
なぜ「ソリューション先行」が問題なのか
利用部門から「フィールドを作ってほしい」「フォームを作ってほしい」といった具体的な実装案が提示されることは珍しくありません。しかし、この実装案をそのまま要件として扱うと、納品が完了してからズレに気づき、手戻りや不満が発生するケースはありませんか？
ワークショップでは、次のような問いかけがなされました。
「依頼されたとおりに作ったのに、後になって『これじゃなかった』と気づいた経験はありませんか？」
この問題の根本原因は、要件と解決策が混在したまま会話が進んでしまうことにあります。利用部門が語る言葉は一見それらしく聞こえますが、実際には「何を実現したいか（意図）」と「どう実現するか（解決策）」が区別されていないことが多いのです。
Intent-Driven Architecture（意図志向アーキテクチャ）とは
ワークショップで提唱されたのは、Stated Requirement → Identify Underlying Intent → Business Outcome という3段階の思考モデルです。
Stated Requirement は｢利用部門が要求してきた解決策｣､
Identity Underlying Intent は｢その要求の背後にある本当の目的・課題 の識別｣､Business Outcome は｢達成すべきビジネス成果と測定指標の設計｣にフォーカスしています｡
この流れに沿って会話を再構成することで、表面的な機能実装ではなく、ビジネス価値に直結した設計が可能になります。
ここからはワークショップでディスカッションしたケースをストーリー仕立てで紹介いたします｡
ケース1： ERP統合 —「夜間同期でいい」と言われたけれど
ある日届いた依頼
営業部門のマネージャーから、こんな依頼が届きました。
「Salesforceとレガシー ERP を統合して、営業担当が注文履歴を見られるようにしてほしい。夜間バッチで同期すれば十分です。」
一見シンプルな要件です。夜間バッチなら実装コストも抑えられますし、すぐに着手できそうです。しかし、私たちは一度立ち止まって考えることにしました。
なぜ「夜間同期で十分」と判断したのでしょう？ 営業担当は注文履歴を見て、具体的に何をしたいのでしょう？
現場に足を運んでみると
私たちは営業チームのオフィスを訪ねました。すると、営業担当者たちは頻繁に電話対応に追われていました。
「お客様から『注文した商品、今どこにあるの？』って問い合わせがすごく多いんです」
ある担当者はこう話してくれました。
「ERPにログインすれば出荷ステータスは見られるんですけど、Salesforceで顧客対応しながら別システムを開くのは手間で…。結局お客様をお待たせしてしまうんです」
なるほど。彼らが本当に欲しいのは「注文履歴」だけではありませんでした。注文登録から出荷、配達までの一連のステータスを、顧客対応の最中にすぐ確認できることだったのです。
さらに深掘りすると
カスタマーサポートチームにも話を聞いてみました。
「正直なところ、お客様が一番気にしているのは『いつ届くか』なんです。履行時間が短くなれば、問い合わせ自体が減るはずなんですが…」
ここで視点が変わりました。可視化は単なる「情報提供」ではなく、遅延の早期検知、SLA監視、顧客への事前通知につながる可能性があります。つまり、問い合わせが来る前に顧客へ状況を伝えられれば、顧客満足度向上と業務負荷軽減の両方が実現できるのです。
意図に沿った設計へ
当初の「夜間バッチで注文履歴を同期」という要件は、実は氷山の一角でした。本当に解決すべき課題を整理すると、次のような選択肢が見えてきます。
単なる文脈情報としての表示で十分なのか
リアルタイムに近いステータス更新が必要なのか
顧客への自動通知まで視野に入れるべきか
これらの判断なしに「夜間同期」という解決策に飛びつくと、せっかく統合しても「結局リアルタイムで見たかったのに」という不満が残ります。何のために必要で、どう使うのかを起点に要件を組み立てることで、手戻りのない設計が可能になります。
ケース2： 承認プロセス —「3層で回して通知を送る」は本当に必要か
届いた要件書
ある日、営業推進部門からこんな依頼が来ました。
「20%超の割引を承認するカスタム承認プロセスが必要です。3階層の管理者に回して、各ステップでメール通知を送ってください。」
承認プロセス、3階層、メール通知。要件としては明確です。Salesforceの標準機能でも実装できますし、すぐに設計に入れそうです。
でも、ちょっと待ってください。本当の要件は何なのでしょう？ なぜ承認ワークフローを3層も重ねる必要があるのでしょう？
私たちはプロジェクトオーナーであるCRO（Chief Revenue Officer）とCFO（Chief Financial Officer）に質問してみることにしました。
経営層との対話で見えてきたこと
「率直に言って、粗利が下がっているんです」
CFOはこう切り出しました。
「調べてみたら、平均で約20%のディスカウントが常態化していました。成長軌道も不透明で、このままでは利益が出ないんです」
CROも続けます。
「営業は数字を作るためにどんどん値引きしてしまう。でも、売上が伸びても利益が残らなければ意味がない。だから承認プロセスで歯止めをかけたいんです」
なるほど、「承認プロセスが欲しい」の背後には「無意味な値引きを防ぎ、利益を守りたい」という意図がありました。
しかし、疑問は残ります
私たちはさらに質問を重ねました。
「承認が却下されることはありますか？」
「…正直、ほとんどないですね。一度申請されると、なんとなく通ってしまう」
「工程ごとのメール通知は、誰がどう使っていますか？」
「うーん…通知が多すぎて、正直あまり見てないかもしれません」
ここで問題の構造が見えてきました。3層の承認と大量のメール通知は、実際には機能していないのです。それどころか、営業担当者の中には「20%を超えると面倒だから19%で出そう」と考える人も出てきている、という話も聞こえてきました。
本当に解決すべき課題は何か
整理すると、利用部門が抱えている課題は「承認プロセスがない」ことではありませんでした。
問題は売上（revenue）なのか、プロセス（process）なのかが切り分けられていない
3層は過剰で、2層で足りる可能性がある
工程ごとのメール通知はノイズを増やし、かえって見られなくなっている
閾値を回避する望ましくない学習行動（19%に寄せる）を誘発している
リードタイムが短い案件では、申請・承認が追いつかない
意図に沿った設計へ
「承認プロセスを作る」という解決策から一歩引いて、ビジネスの健全性を守るガードレールという観点で設計を考え直すことにしました。
検討すべき問いは次のとおりです。
通知頻度・階層数・承認の是非を「目的から逆算」して本当に必要か再点検する
閾値（20%超）の該当件数を数値化し、発生する承認メール件数と工数を試算する
承認ルールが営業プロセスに摩擦を生んでいないか検証する
割引の定義自体を明確にする（単純な20%オフか、条件付きか、固定閾値か）
最終的に、3層の承認プロセスをそのまま実装するのではなく、「悪い取引を未然に防ぐフィルター」としてのガードレール設計を提案することになりました。
実践のためのフレームワークとメソッド
ワークショップでは、以下の3つの問いを常に持つことが推奨されました。
「この機能はどんな問題を解決するのか？」
「誰が、どのように恩恵を受けるのか？」
「うまくいったかどうか、どうやって測定するのか？」
その上で､以下の5つの実践的なアプローチが提案されました｡
1. 「要件整理」と「解決策検討」を分ける
クライアントが要件と解決策を同時に語るのは自然なことです。ファシリテーターとして「まず何を実現したいか整理しましょう」と誘導し、フェーズを分けることが重要です。
2. Play Back（言い換え反復）で意図を引き出す
相手の要望を自然な会話の中で複数回言い換えて返し、相手にも言い返してもらいます。3〜4回の反復でキーワードが出てきて、want（欲しい）とneed（必要）が分離して見えることがあります。
3. 成功の定義と測定を初期に決める
KPI/KPOを明示しないままプロジェクトを進めると、「完成したが効果不明」で終わってしまいます。「何が変わったら成功か」を関係者と合意してから設計に入ることが大切です。
4. 小さく始めて育てる
初期設計で全てを盛り込まず、本当に必要な範囲に絞って開始し、運用しながら拡張します。「誰が所有するか」「誰が入力するか」「誰が利用するか」を明確にして不要な追加を防ぎましょう。
5. 現場観察を怠らない
上層部だけでは実態が分かりません。たらい回しや拒否があっても、ミドルや現場と直接つながって観察機会を取りに行くことが必要です。用意したUIが使われず別経路で処理されているような「回避行動」に気づくことが重要です。
まとめ
アーキテクトは「オーダーテイカー（注文を受ける人）」ではなく、「アウトカムオーナー（成果の責任者）」 であるべきです。アーキテクトの役割は、利用部門から依頼された「解決策」をそのまま実装することではありません。アーキテクトの本来の役割である、Translator（翻訳者）、Challenger（挑戦者）、Systems Thinker（システム思考者）の三つを意識して､背後の意図の翻訳に挑戦し、全体最適を考えるようにしましょう｡
なお､ワークショップの締めくくりには、次のような呼びかけがありました。
「今月中に、ひとつの要件に挑戦してみてください。より良い成果のために、要件を問い直すことをコミットしましょう。」
振る舞いを一度に大きく変える必要はありません。小さなアップデートを積み重ねて､意図から設計するアーキテクトの思考法を体現していきましょう！