本稿では、特定の製品や方法論の是非を論じるのではなく、エンタープライズ・アーキテクチャにおける設計思考の前提について考察する。

「もっと具体的なイメージを示してほしい」

「何を聞けば、どのようなアウトプットが得られるのかを教えてほしい」

「SaaSなのだから、もはや設計は不要ではないか」

エンタープライズ・アーキテクチャ（EA）を議論する場において、スピードと確実性を重視する立場から、こうした声が挙がることは少なくありません。いずれも一見もっともであり、現場感覚としても非常に理解できる主張です。

しかし、戦略実行の“OS”そのものを設計する局面において、安易な「具体化」の前倒しは、意思決定のスピードを上げるどころか、将来の選択肢を自ら閉ざす結果を招きます。それは後戻りや再設計を頻発させ、結果として変革全体を硬直化させる——EAの議論において、しばしば指摘される失敗パターンの一つです。

ここで言う設計とは、全体を一様に具体化していくことではない。まず意思決定の構造を定め、その上で投資判断の優先順位に基づき、ROIの高い領域から戦略的に価値を刈り取っていくための前提を設計する行為を指している。

エンタープライズ・アーキテクトが、あえて抽象度の高い「型」や「ルール」の議論にこだわるのは、設計を先送りしたいからでも、具体から逃げているからでもありません。

それは、特定の製品・組織・プロセスに早期に縛られることなく、将来にわたって戦略の選択肢を保持するための、意図的かつ戦略的な設計行為です。

EAにおける抽象性とは、曖昧さではありません。

企業の文脈と意思決定の自由度を最大化するための「戦略的余白」そのものなのです。

---

1. 「具体」は、記載されていない未来への判断を奪う

具体化の最大のリスクは、「そこに書かれていることが全てである」という錯覚を生む点にあります。

上流フェーズで、将来発生するすべての課題や組織変化を予見することは不可能です。にもかかわらず、最初から細部まで定義しすぎると、設計図に書かれていない事態が起きた瞬間に、立ち戻るべき原理原則を失います。

抽象的な「型」を定義するとは、まだ見ぬ課題に直面した際の“判断のモノサシ（境界条件）”を先に用意することに他なりません。

---

2. 「抽象」こそが、全体最適への影響力を保持する

個別機能や画面設計の議論は、必ず部分最適の引力に引きずられます。

EAの成果物が本当に拘束すべきなのは、単一プロジェクトではなく、後続するすべての投資判断・実装判断です。そのためには、詳細ではなく「構造」にフォーカスし、全体に影響が及ぶ論理だけを合意しておく必要があります。

この軸があるからこそ、後から出てくる要望に対して、

「それは我々のアーキテクチャに適合するか？」

という、感情や声の大きさに左右されない高度な判断が可能になります。

---

3. 企業の文脈（Context）に合わせた「さじ加減」を設計する

抽象化は、決して一律のテンプレートではありません。

どこまでを「型」として固定し、どこからを現場の裁量として開けておくのか。この「さじ加減」こそが、企業文化や戦略的優先順位、すなわち企業固有の文脈（Context） です。

標準化すべき領域と、差別化のために余白を残す領域。

この境界線を設計することこそが、企業固有の文脈を構造として定義する、アーキテクトが提供できる付加価値の高いアウトプットです。

---

EAは、不確実な未来に備えるための「経営の余白設計」である。

抽象を語ることは、実務から距離を取ることではありません。

むしろ、個別の要件や現象に反応する前に、企業がどのような状態を実現したいのか、そのために共通して満たされるべき機能や構造は何かを見極める行為です。

私たちが設計対象とするのは、目の前の「課題」そのものではありません。

複数の事象や要望の背後に横たわる、組織として再現性をもって機能させたい構造的な在り方です。

その視点に立ったとき、問われるのは「特定のツールで何ができるか」ではなく、どのような経営・業務の骨格に対し、どのような実装基盤を選択するかという意思決定です。

「具体」は、特定スコープに対して即効性のある解をもたらします。

一方で「抽象」は、将来の変化を内包できるアーキテクチャそのものを形づくります。

まず、組織として守るべき「型」を定める。

その上で、状況に応じた具体を柔軟に載せていく。

この考え方を前提に基盤を設計・活用することで、ServiceNowは、単なる業務効率化ツールを超え、経営の意思と現場の実行を接続するための基盤として捉えることが可能になります。

その結果、企業戦略は短期の最適化に留まらず、時間軸の先においても有効性を保ち続けます。

---

＊なお、本稿に記載されている内容は、執筆者個人の経験と見解に基づくものであり、ServiceNowの公式見解や製品方針を示すものではありません。