技術体系・業務体系はEAの翻訳機だ――システム移行から経営判断まで使い倒す作り方

社内ITのEA（エンタープライズアーキテクチャ）推進をやっていると、必ず直面するのが「技術体系」と「業務体系」の整備だ。作ろうとは思っているけど、どこから手をつけていいかわからない。関係者の合意が取れない。そんな声をよく聞く。今回は、現場で実際にやってきた経験をもとに、独断と偏見で語っていく。

そもそも技術体系・業務体系がないと何が起きるのか

まずここを押さえておきたい。技術体系・業務体系がない状態でシステムの話をすると何が起きるか。

業務側では、業務プロセスを描くときに粒度がバラバラになる。人事で言えば、勤怠管理と給与支払いは別の機能なのに、担当者によって切り方が変わってしまう。粒度がバラバラになると、機能の重複が生まれ、データの整合性が取れなくなり、システム開発もしにくくなる。じわじわと技術的負債が積み上がっていく構造だ。

技術側では、「なぜこの技術スタックが選ばれているのか」が説明できなくなる。ネットワークひとつとっても、ローカルネットワークなのかモニタリング用なのか、区分けの基準がなければ選定理由が属人的な感覚論になってしまう。

技術体系・業務体系とは、いわば「共通言語」だ。これがないと、議論は常に感覚レベルで止まる。データに落とし込んで初めて、誰もが参照できる共通の土台になる。

体系づくりの進め方――まずExcelから始めていい

正直に言う。最初はExcelで十分だ。

どういう管理をしていくのかが見えていない段階で、いきなりツールを入れようとしても失敗する。まずExcelで業務体系・技術体系のたたき台を作り、管理の形が見えてきてからツールに移行するのが現実的な順序だ。

ただし、ツールへ移行するときは重要な原則がある。ツールのスタンダードな入れ方に合わせることだ。自分たちの運用に合わせてツールをカスタマイズするのではなく、ツールが想定しているデータ構造・管理方法に自分たちを合わせる。これを間違えると、ツールを入れたのに結局Excelと変わらない、という状態になる。

グローバル展開を考えると、この原則はさらに重要になる。同じデータを同じ基準で見られる状態を作ることが、組織をまたいだITガバナンスの前提条件だ。我々の現場ではServiceNowを使っているが、ツールは何であれ考え方は同じだ。

APQC・SAP・TOGAFを「たたき台の正当性担保」として使う

技術体系・業務体系を作るとき、ゼロから考える必要はない。APQC（業務体系の参照モデル）・SAP（業務プロセスの標準）・TOGAF（EAフレームワーク）といったグローバルスタンダードを活用するのが賢いやり方だ。

ただし、これらをそのまま使えるかというと、そうはいかない。自社の業務には自社特有の言い方や区分けがある。参照モデルをそのまま当てはめようとすると、現場から「これうちの会社に合ってない」と言われて終わりだ。

参照モデルの正しい使い方は、たたき台を作るための正当性の担保だ。ゼロから作った場合と何が違うか。「なんとなく作った体系」ではなく「APQC・TOGAF等のグローバルスタンダードを参考に作った体系」と言えることで、社内説得のコストが格段に下がる。EAが推進力を持つためには、外部の権威を上手く借りることも戦略のひとつだ。

業務体系と技術体系、どちらから手をつけるか

これも現場でよく聞かれる。答えは技術体系からだ。

理由は2つある。

技術体系はIT部門だけで進められるからだ。TOGAFやSAPのリファレンスを参考にしながら、システムの技術的な分類・標準を整理していく。業務部門の合意を待たずに自走できる。
技術体系の整備が業務体系づくりへの巻き込みの入口になるからだ。「こういうシステムの可視化ができています」と見せることで、業務部門が「じゃあうちの業務との紐付けもやってみようか」と動き始める。いきなり業務体系の合意を取ろうとするより、ずっとスムーズだ。

実際、技術体系の整備には約1年かかった。業務体系はざっくりの構造は作れても、正式な承認まで至るにはさらに時間がかかる。これが現実だ。完成を目指すのではなく、使える部分から使い始めるスタンスが正解だ。

技術体系・業務体系の真価は「システムと業務の紐付け」にある

技術体系と業務体系を別々に作っても、それだけでは半分だ。本当の価値は両者をシステムと紐付けることで生まれる。

例えば、給与支払いという業務に対して、どのシステムが関わっているかをすぐに示せるか。業務要件定義のフェーズでは当たり前にやっているのに、システム稼働後の課題分析フェーズになると、この紐付けが抜け落ちることが多い。体系として整備されていれば、「この業務課題に対してどのシステムが影響するか」が即座に出せる。

システム移行の場面でも威力を発揮する。移行先システムがどの業務機能をサポートしているか、既存システムのどの機能が移行先でカバーできないかが明確になる。これによって、移行要件の議論を「感覚」ではなく「データ」で進められるようになる。機能の重複整理も、体系を見ながら議論できる。

紐付けの作業自体は正直しんどい。しかしここを乗り越えた先に、本物の可視化がある。

経営層への説明は「翻訳機」という言葉で伝える

経営層や事業部門に技術体系・業務体系の価値を説明するとき、私はこう言っている。

「事業方針とシステムをつなぐ翻訳機です」

組織再編や事業方針の変更があったとき、そのシステムへの影響がどれだけあるかをパッと示せるか。これができる組織とできない組織では、意思決定のスピードが全然違う。経営レベルの方針から、どのシステムにどんなインパクトがあるかを、データとして説明した上で提案できる。それがEAとして技術体系・業務体系を整備した先にある姿だ。

IT部門が「言われたことをやる部門」から「方針に対して先回りして提言できる部門」に変わる。その武器が、技術体系・業務体系の整備だと思っている。