【Column】なぜ、私たちは「抽象」から入るのか 〜具体の罠を避け、企業の「文脈（Context）」を設計するために〜

[mineko]

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

「もっと具体的なイメージを示してほしい」
「何を聞けば、どのようなアウトプットが得られるのかを教えてほしい」
「SaaSなのだから、もはや設計は不要ではないか」

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

しかし、戦略実行の“OS”そのものを設計する局面において、安易な「具体化」の前倒しは、意思決定のスピードを上げるどころか、将来の選択肢を自ら閉ざす結果を招きます。それは後戻りや再設計を頻発させ、結果として変革全体を硬直化させる——EAの議論において、しばしば指摘される失敗パターンの一つです。
ここで言う設計とは、全体を一様に具体化していくことではない。まず意思決定の構造を定め、その上で投資判断の優先順位に基づき、ROIの高い領域から戦略的に価値を刈り取っていくための前提を設計する行為を指している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私たちが設計対象とするのは、目の前の「課題」そのものではありません。
複数の事象や要望の背後に横たわる、組織として再現性をもって機能させたい構造的な在り方です。

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

「具体」は、特定スコープに対して即効性のある解をもたらします。
一方で「抽象」は、将来の変化を内包できるアーキテクチャそのものを形づくります。

まず、組織として守るべき「型」を定める。
その上で、状況に応じた具体を柔軟に載せていく。

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

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

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

[tiagomacul]

(日本語)

「エンタープライズ・アーキテクチャ（EA）における『抽象化』の役割についての非常に優れた洞察です。多くの組織は、まず『判断基準』を定義することなく、目の前の『具体的』な課題（チケットや画面設計など）を解決しようとする傾向があります。

本文で指摘されている通り、抽象化は実践の欠如ではなく、再現可能な構造を作り出すことです。ServiceNowのエコシステムにおいて、これはカスタマイズの『継ぎはぎ』を作るか、それとも弾力性のあるプラットフォームを構築するかの分かれ道となります。全体に影響を与えるロジックに集中することで、ツールを単なるレガシープロセスのデジタル置き場にするのではなく、戦略の原動力にすることができるのです。

現代のアーキテクトに課せられた挑戦は、まさにこのバランスを設計することにあります。つまり、コアとなる部分は標準化し、差別化が必要な部分には自由度を持たせるという設計です。」

Excelente reflexão sobre o papel da abstração na Arquitetura Empresarial (EA). Muitas vezes, o erro das organizações é tentar resolver o 'concreto' (o ticket, a tela) sem antes definir o 'padrão de julgamento'.

Como o texto bem pontua, a abstração não é falta de prática, mas sim a criação de uma estrutura reproduzível. No ecossistema ServiceNow, isso é a diferença entre criar uma 'colcha de retalhos' de customizações e construir uma plataforma resiliente. Ao focar na lógica que afeta o todo, permitimos que a ferramenta seja o motor da estratégia, e não apenas um repositório de processos antigos digitalizados.

O desafio do arquiteto moderno é justamente desenhar esse equilíbrio: padronizar o que é core e dar liberdade onde há diferenciação

ENGLISH

Excellent reflection on the role of abstraction in Enterprise Architecture (EA). Organizations often make the mistake of trying to solve the 'concrete' (the ticket, the screen) without first defining the 'judgment standard.'

As the text correctly points out, abstraction is not a lack of practicality; rather, it is the creation of a reproducible structure. In the ServiceNow ecosystem, this is the difference between creating a 'patchwork quilt' of customizations and building a resilient platform. By focusing on the logic that affects the whole, we allow the tool to be the engine of strategy, rather than just a repository of digitized legacy processes.

The challenge for the modern architect is precisely to design this balance: standardizing what is core while providing freedom where there is differentiation."

[mineko]

Thank you for your thoughtful and well-structured comment.
You’ve articulated exactly what I hoped to convey: abstraction is not an escape from reality, but a deliberate way to design judgment criteria and structural boundaries before solutions are chosen.

As you noted, in the ServiceNow ecosystem this distinction directly determines whether we end up with local, short-term optimizations or a platform that remains resilient and strategically relevant over time.

I strongly agree that the role of the modern enterprise architect lies in consciously designing this balance—not at the solution level, but at the level of decision criteria and structural intent. Standardizing what must remain stable, while preserving flexibility where differentiation truly matters, is ultimately a question of how decisions are framed and constrained. This is a theme I intend to continue exploring, particularly from the perspective of decision-making and context design.