みなさまこんにちは。Works Human Intelligence（以下、WHI）の営業部門に所属している夏目通伸と申します。
「『エンタープライズアーキテクチャ』大手企業・法人だからこそ描きたい、価値創造の設計図」では、25年にわたりHuman Capital Management（以下HCM）領域のシステム再構築に携わってきた私自身の経験、共に学ばせていただいたお客様のお声や事例を基に、エンタープライズアーキテクチャを軸とした提言をしていきます。HCMシステムの再構築を検討・実行されるみなさまにとって、お役に立つような情報提供ができれば幸いです。
第4回の本記事は、「AI活用時代におけるデータ設計のポイント」がテーマです。前回までの記事で触れた通り、エンタープライズアーキテクチャ（以下EA）の考え方においては、それぞれのアーキテクチャの位置関係がとても重要なポイントです。
EAのうち、データアーキテクチャは、ビジネスアーキテクチャとアプリケーションアーキテクチャとの間に位置付けられています。その位置づけと関係性を意識するにあたっての観点について、持論を交えてご説明していきます。ぜひ最後までお付き合いください。
2001年当社の前身会社へ入社。勤怠管理プロダクト（COMPANY 就労・プロジェクト管理）の発売と共に導入支援コンサルタントに従事、累計約40案件を担当。その後プロジェクトマネージャーとして35案件を担当。2014年から2018年まで自社人事部にて採用業務に従事したのち、営業本部に異動。以降、様々な案件支援の他、お客様との対談コンテンツ公開、ブログ記事の発信などスペシャリスト職として活動している。
▼執筆活動
・「報われるプロジェクト」をスタートさせる前に
・大手企業のHRシステム導入 3つのKFS ～Key Factor for Success～（前編）
・大手企業のHRシステム導入 3つのKFS ～Key Factor for Success～（後編）
・永続的なプロジェクトのKey Factor・タッチダウンミーティングとは？
▼セミナー活動（一部抜粋）
・COMPANY Forum 2023 お客様対談 （古河電工様）
・COMPANY Forum 2024 お客様対談 （オープンハウスグループ様）
・当社主催セミナー登壇 など
目次
EAにおけるデータアーキテクチャの「位置」
前回のコラムの結びで「これからの人事業務は、これまで以上にデータによって支えられる」と提言しました。DXという言葉が市民権を得た今日、当コラムをお読みのみなさまにもこの視点は共感いただけるでしょう。
それと同時に、新たな価値を創出するための、たゆまぬ歩みである業務変革を永続的に行っていくためには、要件定義を繰り返し行えることが肝要です。そのためには、How駆動型要件定義の考え方から早々に脱却すべきだ、ともお伝えしました。
今回のコラムでは、AI時代の人事業務に携わる方（人事システムのユーザー）にとって、「どのようにデータを扱うか」というHowを考える前に、「どのようなデータを保持すべきなのか、それはなぜなのか」というWhat＆Whyから考えたいと思います。
この観点から、これまでにお示ししてきたEAの図を改めて確認しておきましょう。
©ケイプラス・ソリューションズ 田中康氏
EAの中心にデータアーキテクチャが位置することの意味
EAにおいて、データアーキテクチャはその中心に位置し、ビジネスアーキテクチャとアプリケーションアーキテクチャの間に挟まれる配置になっています。データアーキテクチャがこの2つをつなぐように存在する理由を紐解くため、まずはビジネスアーキテクチャとアプリケーションアーキテクチャの役割から整理してみましょう。
ビジネスアーキテクチャとは、業務の構造を定義することです。業務それぞれのGoalは何か、なにが満たされればその業務は成立したと言えるのか。すなわちその構造定義において重要なことは、どのようなデータをアウトプットする必要があるのか、その目的は何か、という「目的的な」成果物の定義です。
アプリケーションアーキテクチャとは、成果物の生成に必要なプログラムやメソッドを設計し実装することです。いわば目的を達するための手段の定義です。
その間に位置するデータアーキテクチャは、ビジネスアーキテクチャの目的を担保しつつ、アプリケーションアーキテクチャが提供する手段によって、必要十分に絶え間なく利用できることが求められます。だからこそEAでは、企業内部の機能構造である各アーキテクチャの設計を「機能定義と関係定義」だと定義しているのです。 (第1回コラム参照）
文章で書くと、至極当たり前のことなのですよね。ところが、システム再構築プロジェクトの活動においては、残念ながらこの当たり前が実現しないことも少なくありません。
How駆動型の要件定義～システム設計に潜む脆弱性
ソフトウェアプロジェクトに関する様々なレポートを読むにつけ、決してその成功率が高くないのはみなさまもご承知のとおりだと思います。個々のレポートによって、その数値に多少のばらつきこそありますが、総じて「失敗原因の大半は、要件定義の工程に起因する」と、というのが私見です。
業務用ソフトウェアの業界に身を置いてきた私自身の25年の経験のなかで、ソフトウェア工学や要求工学を学術的に修められた方々から教わったことも踏まえると、プロジェクト成功の阻害要因となりうる脆弱性は、おおよそ次の5つだと言えるでしょう。
・目的が不明瞭なまま示された要件の曖昧性
・要件と仕様の不整合
・プロジェクト中の要件変更
・要件と実利用（つまり運用）との乖離
・目的に見合う成果物を生成するために必要になる投入データの欠落・不足
データ設計とアプリケーション設計とに「隔たり」を生まない
この観点を考えるとき、いつも私にはとあるメタファーが浮かびます。それは、山の両側から掘り進めるトンネル工事です。
とりわけエンタープライズなシステムであれば、業務は複数名に役割分担されているでしょうし、ベンダー側のアプリケーション開発も分業になるという所与の条件があるわけです。How駆動型要件定義の危うさは、誰も悪気がないのに、トンネルを両方向から掘るような活動に陥りやすい構造にあります。要件定義の時には、この脆弱性を強く意識したいものです。
何よりも欠かせないのは、データの整合性を確保することです。つまり、業務目的を果たすために必要なデータと、アプリケーションの仕様から生まれるデータとのズレを無くす必要があるということ。 そのためには、目的からデータを定義し、それを提供する手段を要求する、というトレーサビリティの向きを強く意識せねばなりません。
データアーキテクチャの設計は「誰のもの」か
では、ユーザーは、データベースの設計にまで責任を持つ必要があるのでしょうか。その答えはNoです。そもそも設計とは、ユーザーの要求を実現するベンダーの技術力にほかなりません。データベースの設計はアプリケーションの提供元に委ねてしかるべきものです。
AI時代に加速するデータ管理／活用の内製化
ただし、「なぜそうしたデータアーキテクチャになっているのか」をシステムユーザーが理解すること／理解できることは、とても重要です。いまや、AI Agentを「業務を共にするアクター」として活用するのが当たり前になりつつあります。これからの時代、ユーザーにとって読みやすく、業務に利活用しやすいデータは欠かせないものだからです。
事実、当社における最近の営業提案活動を俯瞰してみると、業務プロセスをシステムごとアウトソーシングしている顧客が、データを自社活用できる提案を求める傾向がとても強くなっています。
日本の知的労働力人口は、今後増えることはないでしょう。限られた人材をどのような仕事に配置し育成していくのか。人とAIとをどう共存させシナジーを出すのか。このコラムをお読みくださっているみなさまの多くが向き合わねばならないテーマです。それを自律的に考え実行していくためには、データ活用のイニシアチブを内製することはきわめて合理的であり、その機運は必然です。
データはまごうことなき経営資源
経営戦略と目標から、それを支える人事業務を定義する。そのために必要な人事データを定義し、その活用手段までを一気通貫的に構築する。エンタープライズ組織には、このプロセスを自らの技術と位置づけ、それを自律的かつ持続的に高めていくことが求められます。そのためには、データアーキテクチャを「これからの重要な経営資源」と再認識することが欠かせません。
何を内製化し、何をアウトソースするか。その目的は何か。法人の未来を描き実現させるための創造性と戦略性に満ちた人事業務を、誰が担うのか。現在の人事業務のうち、機械やAIが代替しうる業務は何なのか。代替しても支えられる業務プロセスへどう変革するのか。そのためにどのような教育・育成・人員配置を行うのか。
ビジネスプロセスとITインフラストラクチャの設計・実装・保守について定義することを目的とし、企業の戦略的目的を達成するために業務を最適化して、テクノロジー戦略とビジネス戦略とを連携させる。EAの活動と目的において、そのど真ん中に位置するのがデータです。データを経営資源として改めて認識し、循環させ活用させていく。それを支える人事業務が経営に寄与します。
AI活用時代のデータアーキテクチャに向き合うために
AIを活用するにあたっても、「どう活用したらいい？」「どんなツールがAIと相性が良い？」といった、How駆動型の思考に陥っているシーンが見られます。手元の手段から試したくなる気持ちはわかりますが、EAのトレーサビリティの方向から見ると、その思考は逆方向です。
あくまで、思考・設計のスタートは業務（ビジネスアーキテクチャ）からです。それからその業務において必要とされるデータを考える。EAにおけるWhatのアーキテクチャを飛び越えて、Howの検討から入らないようにしてください。
AI活用のアウトカムを左右する「3つの観点」
ひとつのアプローチとして、AIをツールと見るのではなく、業務を担うアクターだと捉えてみましょう。業務遂行の観点から、AIにどのような仕事をさせるのか。その仕事をさせるための資源として、どのようなデータが用意されると良いのか。設計視点で考えてみると、次の3つの観点が重要だと言えます。
1つ目の観点は「標準化されたデータ構造」です。AIは、特定の人間ではありません。行間を読んだり、顔色を見たり、状況に応じて工夫したり、という人間ならではの柔軟性を期待してはいけません。それを期待するとしたら、詳細なプロンプトが必要になり、AIに任せるメリットが損なわれます。彼らにとって可読性の高いデータは、標準化されたデータです。
2つ目の観点は「新鮮なデータがおのずから集まるデータフロー」です。定期的に「データ入力を督促せよ」というプロンプトを実行することこそできますが、AIは基本的に、手元に届けられたデータを食べて仕事をします。データが新鮮であるかどうかを含め、内容の良し悪しを判断するのは彼らの責任ではありません。
3つ目の観点は「データ管理のイニシアチブ」です。法人の人事業務というミッションクリティカルな仕事を任せたAIは、基本的に外回りはできません。彼らが安心して取り込めるデータをデータレイクに集めておく必要があります。そもそもどのようなデータを集めるか、データの収集にどれだけコストをかけるか、はAIの管理者である人事パーソンの責任です。
以上の3つの観点を、それぞれワンセンテンスでまとめます。
・可読性の高い標準化されたデータ構造を保持し続けられること
・タイムリーに活用するために常に新鮮に保持し続けられること
・自法人のビジネス戦略・目標に資するデータ管理を内製化すること
EAから見る、「COMPANY」のデータアーキテクチャがもたらす価値
統合人事システム「COMPANY」によってもたらされるEAデータアーキテクチャは、この3つの観点のすべてを高次に満たしています。正しくは、WHIが「COMPANY」のコンセプトを愚直に貫いてきた30年間の歩みにより、AI活用時代に求められる3つの観点を満たした存在になっている、というべきでしょう。
2025/2/13開催 当社セミナー資料より抜粋
①標準化されたデータベース
大規模法人向けという製品の特性上、「多様なパターン」への対応を前提条件としつつ、正確かつ高い生産性で業務プロセスを遂行させること。これが、ミッションクリティカル領域に等しく求められるビジネスアーキテクチャの共通性です。「COMPANY」は、日本の商習慣に最適化したアプリケーションとして、法や税制の改正にも対応しながら、標準機能を常に育ててきました。その結果、すべての顧客に提供され業務で活用されるデータベースの構造も、標準化されました。
②履歴化されたデータベース
月例給与や勤怠管理、昇格昇給、賞与、退職金、といった日本ならではの計算処理には、歴史と共に積み重ねられたルールが存在します。いつ、どのような条件を満たすと、どのようなルールが適用されるのか。この複雑なロジックを標準機能で対応するために必要だったのが、データベースのすべてを履歴構造にすることでした。「COMPANY」では、データの基準日を宣言することにより、特定の時点でのデータを一元的に利用できる価値が生まれています。完全に履歴化されたデータベースの構造こそ、「COMPANY」の優位性を裏打ちするノウハウの結晶なのです。
③永続化されたデータベース
「COMPANY」のコンセプトに「ノーカスタマイズ」があります。一見するとこれは、カスタマイズできないという制約に思えるかもしれませんが、我々はカスタマイズが要らない標準機能の豊かさこそが顧客への価値最大化につながると信じ、30年間貫いてきました。制約ではなく、むしろ、秩序です。この秩序こそが、すべての顧客にシングルソースのアプリケーションを提供するという、現在の価値を生み出しました。同時に、すべての顧客に同一のデータ構造を提供できることにも繋がっています。その結果、「COMPANY」のデータベースは、まごうことなき永続化されたデータベースになっているのです。
「ルールさえあれば、それが明文化されてさえいれば、AIがキチンとやってくれる。」そうした業務構造を支えられる要諦は、処理機能を搭載するアプリケーションアーキテクチャだけではありません。アプリケーションアーキテクチャとビジネスアーキテクチャをつなぐ、データアーキテクチャにもあるのです。
最後に、「COMPANY」のデータアーキテクチャの価値を端的にまとめておきます。
・標準化されたDB設計～ミッションクリティカルで複雑な業務を、生産性高く正確に～
・履歴化されたDB設計～基準日時点での情報検索を、社員IDをキーに業務横断的に～
・永続化されたDB設計～日本の業務が求める成果物の担保を、標準機能で永続的に～
最終回となる第5回のコラムでは、EAにおけるアプリケーションアーキテクチャの重要性を掘り下げながら、EAの全体を俯瞰視する意義についてまとめていきます。「中の人」としての視点から、EAの思想を高い次元で実現している「COMPANY」の真価にも触れ、全5回の連載を総括します 。
では、次の記事でお会いしましょう。最後までお読みくださりありがとうございました。
