みなさまこんにちは。WHIの営業部門に所属している夏目通伸と申します。
「『エンタープライズアーキテクチャ』大手企業・法人だからこそ描きたい、価値創造の設計図」では、25年にわたりHuman Capital Management（以下HCM）領域のシステム再構築に携わってきた私自身の経験、共に学ばせていただいたお客様のお声や事例を基に、エンタープライズアーキテクチャを軸とした提言をしていきます。HCMシステムの再構築を検討・実行されるみなさまにとって、お役に立つような情報提供ができれば幸いです。
第3回の本記事は、「人事業務設計への向き合い方」がテーマです。前回までの記事で触れた通り、エンタープライズアーキテクチャ（以下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におけるビジネスアーキテクチャとしての「人事業務の勘所」
今回のコラムでは、人事業務に携わる方（人事システムのユーザー）にとって、人事業務の要件とは何かを考えたいと思います。まずは、過去に当社のブログでもお示しした私の持論から、人事業務の特性を大きく2つの勘所に分けてみます。
勘所①：「正解して当たり前」で「間違えたら大目玉」な領域
これに該当するのは、たとえば月例給与や賞与、退職金といった報酬の支払い、労基法や労働安全衛生法に則った労務管理、それらに必須なデータや業務処理です。法令や規程など、定められたルール（＝正解）に準じ、正確な処理が求められる領域です。最近は Operational Excellence という言葉をよく見聞きしますが、まさにこれを追求することが価値になります。
第1回のコラムでご紹介した「人事データの三次構造」でいうと、第一次・第二次人事データといった人事業務の根底を支える必須データは、この業務領域で扱われます。ITのチカラが大きく期待される領域と言えるでしょう。
勘所②：「正解がない」が「企業競争力のためには立ち止まっていられない」領域
これは、タレントマネジメントや人的資本経営の文脈で語られるような、永続的にクラフティングしていく業務を指します。たとえば、従業員の能力開発やキャリア形成、組織エンゲージメントの向上といった取り組みです。これらは明確な「正解」が定義されていない場合が多く、常に試行錯誤を繰り返し改善・改革が必要で、そのプロセス自体が価値となります。
「人事データの三次構造」でいう第三次人事データは、時として人事業務の領域を超え、経営のためにも利活用されるデータです。その活用にも、「正解がない」中で業務に従事する方が主体的にプロセスを具体化し、データ活用の動機付けを行う業務設計が求められます。
©2025 Works Human Intelligence 夏目
前回も触れたように、日本の業務は非常に複雑性が高いという「所与の条件」があります。その複雑性を強みと捉えながら不断の価値創出に取り組むことは、日本の企業にとって避けて通れない道だと言えるでしょう。
同時に、その複雑性が、報酬支払業務、およびその根拠となる勤怠管理や人事評価などの業務にも、少なくない影響を与えているのは事実です。それゆえ、従業員を多く抱える歴史のある企業にとって、その正確性や生産性を担保するために、一定のIT投資を行うのは必然です。
今後、より重要性を増す「人」という資本。これをいかに活かすか。それと同時に、その処遇をいかにうまくオペレーションできるか。現在、そしてこれからの人事業務に向き合う者に等しく問われる、経営課題と言えます。
業務遂行を支えるITインフラストラクチャが、業務変革の足かせにならないために
ここで改めて、EAの目的をおさらいしておきましょう。第1回のコラムで述べた通り、「企業の戦略的目的を達成するために、業務を最適化し、テクノロジー戦略とビジネス戦略とを連携させる」ことでした。ここで重要なのは、ビジネス戦略は常に変化していくものであるということです。
上述した勘所①の領域における「正解」は、法改正や社会情勢の変化といった外的変化によって変わることもあれば、企業内部の制度改定といった内的変化に合わせて企業が変える場合もあります。「正解」、つまり正しい結果を担保する業務領域に、どれだけのリソースを投じるべきなのか。内的/外的変化への対応を前提にした経営アジェンダとして取り扱う必要があります。
また、勘所②の領域にはそもそも「正解」というものがありません。現在、またこれからの人事業務にとって、あるべき人事業務は常に変化するという前提を強く認識すべきです。
そのような変化の時代において、人事業務の遂行を支えるツールであるはずのシステムが、かえって変革の足かせになってしまうケースをよく見聞きします。システムの構築や運用維持の活動を進める中で、当初の投資目的から逸れてしまう話も少なくありません。その最たる理由は「要件定義への向き合い方」にある、というのが私の持論です。
要件定義とは、いつ、誰が、何を、何のために定義するものなのか？
そもそも要件定義とは、いつ（When）、何のために（Why）、行われるのでしょうか。取り立てて明文化されていないかもしれませんが、おおよそ世の中の定説としては「システム再構築に際し、その前段として行われる工程」だと認識されているでしょう。しかし、果たしてこれは正しいのでしょうか？
もちろん、エンタープライズシステムを再構築するという活動は、決して小さくない投資を必要とします。何のために投資するのか、そのROIはどう高めるのか、という計画を、投資判断の基準としてあらかじめ設定することは必然です。一方で、再構築したシステムに必要な要件の全量を、再構築時にすべて出すことなど果たして可能なのでしょうか。
あくまで私見ですが、「変化への対応を前提に、陳腐化せず、業務を阻害しないシステム」が、真の要求（Wants）であるべきです。これこそがDX時代を生きるみなさまにとっての、根源的かつ普遍的な要件（Needs＋Wants）であるはず。そう、私は考えています。
具体的に企業がDXの推進により持続的な企業価値の向上を図っていくためには、以下の4点が重要である。
①新たな価値創造に不可欠な経営資源としてデジタル技術を捉え、DX戦略を描くこと
②デジタルの力を、効率化・省力化を目指したITによる既存ビジネスの改善にとどまらず、新たな収益につながる既存ビジネスの付加価値向上や新規デジタルビジネスの創出に振り向けること
③ビジネスの持続性確保のため、ITシステムが技術的負債となることを防ぎ、計画的なパフォーマンス向上を図ること
④必要な変革を行うため、IT部門、DX部門、事業部門、経営企画部門などが組織横断的に取り組むこと
引用：経済産業省 デジタルガバナンスコード3.0（2024 年 9 月 19 日 改訂）
https://www.meti.go.jp/policy/it_policy/investment/dgc/dgc3.0.pdf
経済産業省が公開しているデジタルガバナンスコード3.0でも、「ビジネスの持続性確保のため、ITシステムが技術的負債となることを防ぎ、計画的なパフォーマンス向上を図ること」と明言されています。
つまり要件定義は、刹那的活動ではなく永続的に行われる必要がある活動であるということです。
次に、誰が（Who）、何を（What）、行うものなのでしょうか。
これも取り立てて明文化されていないかもしれませんが、持論も込めて言語化すると、
「システムの発注者であるユーザーが、その提供者であるITベンダーに対する要求事項を明文化すること」だというのが、世の中の認識でしょう。というのも、それが、ウォーターフォール型のシステム構築手法を支える、ベンダーにとってのビジネスモデル構造に他ならないからです。オーダーを受け、それに呼応するITシステムを構築し、ユーザーに納品し検収を受ける。この活動において、要件定義は、双方にとって合理的な方法論なのです。
あわせて、「仕様凍結」についても言及しておきたいと思います。引き続き私見ではありますが、この考えは「システム切替までをシステム再構築活動とする」という前提に立っています。しかし、価値創出のために終わりのない業務改善や改革を支えていけるシステムが、現在および未来の人事業務にとって不可欠なのは自明です。クラフティングしながら変化に対応し、自ら変革を期する。構築費用を最終化させるための仕様凍結とは別に、アジャイル的な業務改革思想においての「仕様凍結」とは何なのか、についてもぜひ考えておきたいものです。
「Fit to Standard」が目指すもの
SaaSとしてITシステムを手にすることがより一般的になってきた昨今では、要件定義への認識も変わりつつある。ベンダーの一員である当社に身を置く私としての考えであり、当社もその認識の変化について重視しています。
「Fit to Standard（以下F2S）」という言葉、みなさまも見聞きされたことがあるのではないでしょうか。要件定義にかかわるユーザー・ベンダー双方にとっての考え方として、F2Sが一定の認知を得ていることは、昨今のDX人口に膾炙すると言って良いでしょう。しかし「つまりこういうことである」という定義がない類のワーディングであることも事実でしょう。あくまで持論ですが、F2Sの定義について言語化してみました。
＜考え方＞
・F2Sは打ち出の小槌でも万能の剣でもない。
・F2Sは目的そのものでもない。目的達成のための錦の御旗とすべき、いわば思想である。
＜期待効果＞
・パッケージ/SaaSの標準機能の活用
- BPRの実行（業務効率向上、システム陳腐化リスクの極少化）
- コストダウン（イニシャル/ランニングコストの低減、投資コストの透明性向上）
- 永続性向上（個社カスタマイズ領域の低減による製品アップデートの最大享受）
特に経営目線で考えれば「F2Sで行くべきだ」となってしかるべき、理想的な内容です。
しかしプロジェクトの現実としては「言うは易し、行うは難し」であることが少なくないようです。読者のみなさまも、様々な記事で目になさっているのではないでしょうか。
F2Sの効果を最大化させる要諦
私見ですが、理想の実現を阻む課題要素として、以下のポイントがあると考えています。
課題①スタンダードというベンチマーク対象を何にするか、その理由は何か、が曖昧
課題②スタンダードを受け入れる業務と、こだわりを持つ業務とのメリハリが利いていない
課題③今の業務はこうしている、という易きに流れる要件出しをしてしまいがち
課題①に対して、私には明確なアンサーがあります。それは、当社製品である統合人事システム「COMPANY」こそが、スタンダードであり、スタンダードでなくてはならない、という矜持です。これは次回以降で深めていくこととし、今回の記事では②と③について詳しく触れていきます。
課題②③についてみなさまに提言したいのは、How駆動型の思考にご注意をということ。
Operational Excellenceを期する領域では、F2Sは非常に有効なアプローチです。
その業務を満たす機能の操作性が、ユーザーにとって受容可能かどうか、を評価ポイントにすべきです。ぜひ「使い勝手」という判断基準を過度に重視することを疑ってみてください。
人間は慣れる動物です。使い慣れている道具に顕在化した不満が無ければ、新たな道具に変えることを億劫に感じてしまうものです。一方で、ひとたび新たな道具に変えてしまえば、そしてその道具が不便なものでなくモダンな技術のものであれば、人間は「なんでアレに固執してたんだろう」と、慣れていくもの。それは、これまでの人類史で幾度となく証明されています。
ITインフラストラクチャへの投資判断基準として「ユーザーにとっての使い勝手」を評価する場合は、まず投資対効果と持続可能性を優先軸とすべきです。そのうえで、期待メリットを損なわないレベルの使い勝手かどうか（慣れたら使える、生産性を損なわない程度であるか）、見極めねばなりません。
How駆動型の思考に陥らないために ～ドリルと穴～
マーケティング学者のセオドア・レビット氏が述べた、ある有名な言葉があります。
「人々が欲しいのは1/4インチ・ドリルではない。彼らは1/4インチの穴が欲しいのだ (People don’t want quarter-inch drills. They want quarter-inch holes.)」
あけるべき穴は何なのか（What）、何のためのものなのか（Why）を考え定義するのが業務設計です。How（手段）を積み上げた要件をベンダーに求めるまえに、実現すべき業務を定義することこそが、ユーザーが行うべき重要な行為です。しかし往々にして、その定義をスキップして、業務の遂行手段であるITインフラストラクチャの機能を、ユーザーが求めがちになる。
第1回・第2回で触れたEAの考え方になぞらえると、設計方向のベクトルが逆になってしまうことで、EAのトレーサビリティが損なわれるという構図が、それです。世の中の要件定義活動において知らず知らずのうちに生じていて、定義すべき要件の誤謬を招いてしまっている可能性があると私は考えています。
効率化の歩み、価値創出の歩み、にメリハリを
担保すべき正解値、およびそれを成立させる業務を遂行するための具体的なやりざまを、スタンダードなプラクティスにベンチマーキングする。前述した勘所①、つまり「Operational Excellence」を追求する業務領域については、これを強く意識しましょう。そしてユーザーは、そのスタディの結果であるToBe業務を受け入れられるか、を評価の軸にしましょう。「今と違う」という事実を把握したところで思考を止めてはなりません。今との違いが、果たして課題なのか？と問うていく意識が肝要です。
一方、勘所②のような「新しいトレンドの波頭に乗っていくタイプの業務領域」では、一定の機能要件定義が避けられません。なぜならば、ベストプラクティスと言えるような手段が、未だマーケットに存在していないであろう業務領域だからです。仕様凍結を必要としないアジャイル型の要件定義を、ユーザー主導で繰り返し実施しましょう。
クラフティングとOperational Excellence ～DX時代の指針～
あるべき業務を描き、その実現・遂行のために必要な手段や打ち手を定義する。これは、変革を期するチェンジマネジメントそのものであり、企業を成長させる中で、繰り返し行うべき「クラフティング活動」です。
この「クラフティング」という言葉は、経営学の巨匠ヘンリー・ミンツバーグ氏が提唱した理論から引用しています。彼の理論では、アート（直感・洞察・創造）、サイエンス（情報・分析）、そしてクラフト（現場・経験）の3つをバランスよく組み合わせ、実践していくことが重要だとしています。あるべき人事業務を模索し、描き、追い求め続けていく。これは、人事パーソンにとっての「終わりのない旅」だと言えるでしょう。
新たな価値を創出するための、たゆまぬ歩みである業務変革。この経営アジェンダにユーザー自ら向き合うことが、持続可能な変革のための要諦であり、その活動の成否を左右するキーファクターなのです。そのためには、要件定義を繰り返し行える状態であることが、現在のDX潮流における前提条件である、と肝に銘じる必要があります。決して変化を厭ってはいけません。変化に柔軟な対応ができるITインフラストラクチャを選び、変化への阻害要因を一つでも少なくしていきましょう。
以下、2つのユーザー企業様の事例記事をご紹介します。こちらのお客様のほかにも、たくさんの事例が当社ホームページ上に掲載されています。みなさまにとってのベンチマーク対象となる・すべき事例から、ぜひヒントを得てみてください。
日本貨物鉄道株式会社（JR貨物）様
1. デファクトスタンダードの標準パッケージを羅針盤に、業務改革を推進
2. 将来の不確定な要件変化もユーザー自身により変更対応
3. 人事管理、給与計算、勤怠管理、各種申請、タレントマネジメントまで、
グループ展開を見据えた人材統合データベースを構築
株式会社西友様
1. 人事領域のシステム一元化による人財データ基盤の構築
2. ベストプラクティスを取り入れた業務改革
3. 人事関連事務作業の効率化と従業員の利便性向上
業務システムの刷新を、単なる「入れ替え」で終わらせない
生成AIの台頭には目を見張るものがあります。これに代表されるように、テクノロジーの進化はまさに日進月歩です。それゆえに、システムユーザーのみなさまには、How駆動型の要件定義の考えから早々に脱却し、モダンなツールを積極的に受け入れていただきたいと思います。単に「今までと違う」という理由で拒絶するのではなく、ぜひ、永続性というメリットを損なわないだけのUX（ユーザーエクスペリエンス）であるか、という視点でシステムを評価してください。
そして、永続的なシステムに必要な要素として重要なのは、「永続化が約束されたデータ構造」です。これからの人事業務は、これまで以上に、データによって支えられます。永続化されたデータなくしてDXは成しえず、AIの活用も絵に描いた餅になります。
パッケージソフトウェアによるシステム開発の最大のメリットは、まさにこの「データの永続化」にあると言えるでしょう。Works Human Intelligenceの統合人事システム「COMPANY」がなぜ多くの企業に選ばれ、長く使い続けられているのか。その理由の一端は、間違いなくここにあります。
次回、第4回のコラムでは、EAにおけるデータアーキテクチャの重要性について、さらに掘り下げていきたいと思います。
では、次の記事でお会いしましょう。最後までお読みくださりありがとうございました。
