「あるべき姿」の設計からベンダー選定まで、上流工程の勘所

建設業の基幹システム刷新は、もはや老朽化対応や保守の負荷軽減だけを目的にした取り組みではありません。AI活用やデータドリブン経営を見据える今、システムを単に「入れ替える」のではなく、業務そのものをどう変え、経営の意思をどう実装するかが問われています。本鼎談で登場する3名が口をそろえるのは、構想策定から業務要件定義、ベンダー選定に至る上流工程の質が刷新の成否を決めるということ。建設業特有の実務を踏まえながら、あるべき姿の描き方と、ぶれない判断軸の持ち方を掘り下げます。

参加者

豊島 久美子
PwCコンサルティング合同会社 シニアマネージャー

藤野 真治
PwCコンサルティング合同会社 マネージャー

尾崎 駿介
PwCコンサルティング合同会社 シニアアソシエイト

※法人名・役職などは対談当時のものです。

刷新の「動機」を見極める――リプレイスで終わらせないために

豊島：
建設企業が基幹システム刷新に踏み切る背景には、大きく2つの動機があります。1つは、今後の事業展開を見据え、必要な経営指標を継続的に把握できるようにしたいという経営視点の課題です。もう1つは、手入力や目視確認が多く残る現場業務を見直し、業務効率を高めたいという実務視点の課題です。

実際のご相談でも、この2つの動機のいずれかから始まるケースが多いのですが、特に業務効率化を目的とする場合は、現場に手作業や重複作業が多く残っていて、「そこを何とかしたい」という切実な声が起点になっています。

藤野：
豊島さんが指摘した「業務効率化」の先に、もう一段の期待があると感じています。刷新を単なる効率化で終わらせず、データ活用や業務の高度化につなげたい、と。実際、ゼネコンやプラント建設業者などでも、業務のあり方をどう変えるかという議論とセットで刷新が検討されるケースが増えています。

尾崎：
だからこそ重要なのが、刷新プロジェクトの「入り口」です。基幹システム刷新は、システムだけを入れ替える取り組みではありません。業務のあり方まで踏み込み、広い視野で全体最適を目指せるかどうか。ここが、リプレイスと業務改革の分かれ目です。プロジェクトの初期段階で、「業務をどう変えるのか」「何を最適化するのか」という問いを立てられるか――私はそこが分岐点だと感じています。

「あるべき姿」を描く――構想策定と業務要件定義

豊島：
リプレイスで終わらせないためには、大きく2つの方向があります。1つは、刷新を機に現行業務そのものを見直し、大きく変えること。もう1つは、経営層が求める指標や判断材料を、構想段階からシステムに織り込むことです。

前者では、例えば工数を大幅に削減するなど、業務そのものをどう変えるかを具体化することが求められます。もし明確なイメージがない場合でも、他社事例や進め方を踏まえて、自社にとって現実的な選択肢を描いていくことができます。

後者では、経営層が把握したい指標や、将来の経営判断に必要となる情報を、構想段階から明確にしておく。ここを後回しにすると、刷新の方向性がぶれる原因になります。そのため、早い段階から経営層にも議論に参加してもらい、できるだけ広い関係者を巻き込みながら構想を固めていきます。

尾崎：
構想策定を支援する際、とりわけ上流工程では2つの点を重視しています。

1つ目は、新しいシステムで実現したい「あるべき姿」を明確にすることです。クライアントの課題認識と私たちの見立てをすり合わせながら大方針を定め、その上で「何を実現したいのか」を業務要件として漏れなく整理します。

2つ目は、その内容をベンダーに正確に伝えることです。上流で定めた構想や要件が曖昧なままだと、提案内容に引っ張られ、本来目指していた姿からずれてしまいかねません。だからこそ、判断の軸を先に固めておくことが鍵になるのです。

図表1：基幹システム刷新の進め方

パッケージか個別開発か――システム選択とベンダー選定の判断軸

豊島：
システム刷新で繰り返し論点になるのが、既存アプリケーションを活用するのか、スクラッチ開発を選ぶのかという判断です。人材が潤沢であれば個別開発という選択肢もありますが、今のようにシステム人材が限られる環境では、保守にどこまで人手を割くのかを慎重に考えなければなりません。基幹システムの保守に貴重な人材を固定化するよりも、AIなど新しい技術領域へ人材を振り向けるほうが、中長期的には企業の変化対応力を高めることにつながります。

藤野：
一方で、スクラッチ開発の場合、クライアント側に相応の負荷を求めます。また、仕様の全体像が見えにくく、システムに関するナレッジが社内に蓄積されにくいという課題もあります。

一方、既存アプリケーションには、建設業の実務に合わないケースがあるのも事実です。特に原価管理領域ではその傾向が強く、既存製品を使う場合でも、ベンダーとの丁寧な協議は欠かせません。

その前提として重要なのは、構想策定と業務要件定義の段階で、何を重視するのかを固めておくことです。要件を盛り込みすぎれば、結果的にスクラッチ開発に近づきます。だからこそ、自社の業務をどこまで合わせるのか、あるいは譲れないことは何なのかを整理した上で、ベンダーと向き合う必要があります。

尾崎：
既存アプリケーションを選ぶ際、営業提案をそのまま受け入れ、十分な比較検討をしないまま決めてしまうケースは少なくありません。しかし本来は、複数の選択肢を同じ基準で見極めることが不可欠です。

また建設業ではコスト比較が重視されがちですが、システム開発は価格だけでは判断できません。安価な理由にも、高価な理由にも意味があります。重要なのは、価格の裏側にあるメリットや制約まで含めて比較することです。ベンダー選定でまず確認すべきなのは、「建設業向け」とされるアプリケーションが本当に自社に合うかどうかの見極めです。ひとくくりに建設業といっても、専門工事業者、サブコン、ハウスメーカー、ゼネコンでは実務が大きく異なります。そのため、RFP（提案依頼書）を提示した段階で要件が合わず、ベンダーが辞退することもあります。こうした手戻りを避けるには、初期段階で適合性を見極めることが重要です。

豊島：
私たちは多くのベンダーとプロジェクトを進めてきた経験から、各社の特徴や導入時に起こりやすい課題を把握しています。そうした知見を元に、選定時の見極めを支援できることも強みの1つです。

藤野：
クライアントへの助言にあたっては、特定の製品やベンダーを一方的に勧めるのではなく、各選択肢の特徴、メリット、制約を客観的に整理し、クライアントが自社に合うものを判断できるよう支援することを重視しています。

ベンダーにはそれぞれ得意領域や提案の方向性があり、それが必ずしもクライアントの要件と一致するとは限りません。だからこそ基準になるのは、上流工程で整理した「自社が本当に必要とする要件」です。要望に対して難色が示された場合も、その要件を土台にしながら、どこまで歩み寄れるかを調整していく必要があります。その「交渉の土台」をつくるのが、先ほど尾崎さんが話した上流工程（初期段階）の役割なのだと思います。

豊島：
ベンダーにRFPを提出する際には、できるだけ同じ粒度で回答してもらえるよう調整します。それでも各ベンダーの回答には差が出るため、同じ基準で比較できるよう比較表を作成し、クライアントが重視する要件に照らして判断できる状態を整えることが欠かせません。

尾崎：
プロジェクトが進むほど、クライアントはベンダーに依存せざるを得なくなりがちです。だからこそ早い段階から間に入り、少し先を見据えて交渉や調整を行うことに価値があります。

豊島：
その意味でも、選定時に要件や見積もりの前提を丁寧に確認しておくことは重要です。ベンダーによっては、RFP回答後に要件定義を経て再見積もりを行った結果、当初の価格が変わることがあります。

後から「なぜ価格が変わったのか」「どこに責任があるのか」が論点にならないようにするためにも、選定段階で前提条件を明確にしておくこと。この点は、改めてお伝えしたいところです。

プロジェクトの精度を高める、建設業の土地勘

尾崎：
私たちのチームには、建設業での原価管理の実務経験者や、建設業会計を長く担当してきたメンバーがいます。建設業の実務と内部事情に精通したメンバーが支援できることは、大きな強みです。

例えば「JV出資金」や「社内JV」といった建設業特有の用語や実務は、業界知見、いわゆる「土地勘」がなければその説明から始める必要があります。それはクライアントにとって時間のロスになるだけでなく、ベンダーに要件を正確に伝える上でも不利に働きます。

建設業に対する土地勘を持つメンバーと、基幹システム刷新を支援してきたコンサルタントがチームを組むことで、業務課題の整理からシステム要件への落とし込みまで、ワンストップで支援できる。ここに、私たちが入る意味があると考えています。

藤野：
建設業務を細部まで知り尽くしている必要はないとしても、一定以上の知見は不可欠です。加えて、基幹システム刷新では業務だけでなく、システムに対する理解も求められます。

また、構想策定から要件定義、ベンダーとの調整までの流れに通じていることも重要です。PwCの支援チームは、業務とシステムの双方を理解した上で、上流工程を一貫して支援します。

図表2：数字で見る建設・住宅業界における実績と支援体制

豊島：
ここまで、基幹システムの刷新に関し、建設企業が押さえておくべき上流工程のポイントと、私たちPwCコンサルティングの支援のあり方を話してきました。後編では、ベンダーが関与してくる「下流工程」の難所と、導入後の「チェンジマネジメント」について議論していきましょう。

後編はこちら