{{item.title}}
{{item.text}}
{{item.text}}
文具・事務用品やオフィス家具などで知られるプラスは、「みんなのDX」を掲げてデジタル時代を見据えた企業変革に取り組んでいる。その実現のために、基幹システム刷新をアジャイルで実施することを決定。一般的に基幹システム刷新にアジャイルは向いていないとされているが、この決断の背景には何があるのか、進行中の取り組みで示され始めた効果と課題について深掘りし、これらが企業変革にどう結びつくかを探る。
文具・事務用品およびオフィス家具のメーカーとして、また法人向け流通サービスなどの事業で知られるプラスは現在、全社的な変革に取り組んでいる。「みんなのDX」を掲げて部門間の壁を克服し、「ONE PLUS」を実現しようとしているのだ。社長みずから陣頭指揮を執り、アジャイル開発を基幹システムに適用して「ONE PLUS」を実現しようという野心的なプロジェクトが進行中だ。プラスと一体となってこの取り組みを支援しているPwCコンサルティングの中山裕之が、プラス代表取締役社長の今泉忠久氏と、プロジェクトの中心人物である執行役員デジタル統括部門長の山口善生氏に話を聞いた。
(左から)中山 裕之、山口 善生氏、今泉 忠久氏
中山:
通常、基幹システム刷新は、ハードウェアやソフトウェアのサポート切れをきっかけに、IT部門主導で取り組むことが多いです。しかしプラスは、社長みずからが先頭に立ち、「みんなのDX」という名称で全社改革に取り組んでいます。その狙いと背景を教えてください。
今泉:
当社には家具、文具、流通という事業に対応する3つのカンパニーがあります。それぞれの事業特性が異なるため、業務プロセスも独自に進化し、基幹システムや顧客マスターも別々になっています。各カンパニーの文化の違いもあり、カンパニー間での顧客の取り合いのようなことも起きていました。2020年の社長就任を機に、このような状況を打開するために、全社的な変革に取り組もうと決意したのです。キーワードは「ONE PLUS」です。カンパニー制のメリットもあるものの弊害も出てきており、その原因の一つが基幹システムでした。基幹システムこそ業務部門とIT部門が一体となって刷新する必要があり、「みんなのDX」という名称にしました。
プラス 代表取締役社長 今泉 忠久氏
中山:
ONE PLUSに向けた全社的な変革がまずあって、その重要な要素として基幹システム刷新があったわけですね。
今泉:
基幹システムは、その組織の思想を表すものだと考えています。ONE PLUSの思想を浸透させるうえでも、まったく新しい基幹システムが必要です。単にシステムを刷新するだけでなく、企業カルチャーを変えなければならないと考えました。カルチャーは全社員でつくるもの。そこで、社長直轄の形で2020年8月にDX(デジタル・トランスフォーメーション)を本格化し、アジャイル開発による基幹システム刷新のプロジェクトを2021年にスタートしました。
新基幹システムのコンセプトは「俊敏性」「柔軟性」「ローコストオペレーション」です。環境変化や事業の必要性に応じて、素早く対応できる「アスリート体質」のシステムと組織を目指しています。
中山:
現在どのような課題を抱えているのでしょうか。
今泉:
当社のビジネスは社会変化の影響を受けやすい面があります。コロナ禍以降、在宅勤務が増えたことでオフィス需要が大きく変わるなど、業界自体の変化も激しい。それに伴って、システムに対する変更要件も出てきますが、実際はその一部しか対応できず、多くが先延ばしで積み残されています。またITコストも高止まりしていて、なかなか新たな取り組みに予算もリソースも割けない状況です。
中山:
一般的に、IT予算の多くが現状維持に費やされていて、新規投資は限定的だといわれていますが、プラスではいかがでしょうか。
山口:
当社ではIT予算の8割以上が現状維持に費やされ、新規投資は2割以下です。社長の今泉からも強く言われていますが、今回の刷新を通じてこの割合を逆転させたいと考えています。そのため、クラウドネイティブ技術や自動化ツールなど最新のテクノロジーを最大限活用して刷新を行っています。
今泉:
カンパニー制が原因で、個別にシステムが開発され、結果として基幹システムが肥大化しています。今回の刷新でシステムをスリム化して、本当にビジネスに価値のある機能に絞り込みたい。また、ITの現状維持に費やされているコストの削減も大きな目的の一つです。そのため、開発の内製化にも積極的に取り組んでおり、今回の刷新を通じてデジタル人材も育成したいと考えています。ただ、すべてを内製化しようとは考えていません。当社自身でシステムをコントロールできるようにすることが目的ですので、主要な役割は自社社員で対応し、必要に応じてITベンダーにも協力をいただく方針です。
中山:
日本でもアジャイル開発の活用が広がっています。当社が実施した「PwC 2024年 DX意識調査‐ITモダナイゼーション編‐」によると、2023年を機にアジャイルの活用が加速し、現在の普及率は70%を超える結果となりました。しかしながら、それを基幹システム刷新に適用している事例は少ないのが現状です。今回アジャイル開発を適用した決断の背景を教えてください。
山口:
当社の事業課題は多岐にわたります。一例ですが、流通事業であれば、商流や商品構成、商品カテゴリーなどの頻繁な変化への対応、家具事業では、オフィスづくりに関わるデザインから導入までの営業リードタイム改善、文具事業では、日々目まぐるしく変化する世界情勢に対応する貿易管理の向上などがあります。これらの課題に対し、システムには高い俊敏性と柔軟性が求められます。最初に要件を定義して3年後に完成するといった従来型のウォーターフォール開発では、事業環境の変化に対応できないと考えました。
プラス デジタル統括部門 執行役員 部門長 山口 善生氏
中山:
「大規模システム・基幹システムは従来型のウォーターフォールで、顧客接点などフロントのシステムはアジャイルで開発すべき」と考える方が多いようですが、それは正しいとはいえません。
ウォーターフォール型の開発では、ある機能の要不要を要件定義段階で判断するのは容易ではありません。また、IT側が「不要」と考えても、業務側の合意は得られないのが普通です。アジャイルの場合、たとえば開発が進んで8割の業務が移行可能になった段階で、「本当に残り2割も開発して業務を移行する必要はあるのだろうか」と立ち止まることができる。そして、2割分の投資とビジネス効果を天秤にかけて、最後まで開発するか、8割でよしとするかを判断すればいい。効果の小さい開発にはストップがかかるので、無駄な開発は抑制され、基幹システムはスリムな状態を保つことができます。
山口:
当社のシステムは、肥大化も問題でしたが、そもそも長年の改修を経てブラックボックス化してしまっていました。そのため、どんな「隠れ仕様」が出てくるかわかりませんし、実際に少なくない数の「隠れ仕様」が出てきています。このような状況でウォーターフォールの要件定義を行っても、いつまで経っても完了できない可能性が高いです。たとえ要件定義をしたとしても、すべての要件をプロジェクト初期段階で網羅することは不可能に近く、後々大きな手戻りが発生しかねません。そこで、ブラックボックスを前提とし、自分たちでその中身を深く掘ってひも解きながら、一歩ずつ前進するやり方を選びました。このプロセスは「業務がわかるIT担当者」「ITがわかる業務担当者」を育てるうえでも重要です。
中山:
アジャイル開発の代表的なフレームワークであるスクラムでは、「透明性」「検査」「適応」が重要な考え方です。たとえば、隠れた仕様が出てきてそれに対応する場合、リリース時期や予算などにどのような影響が出るか見える化(透明性)を行い、どの機能のビジネス価値が大きいか判断し優先順位を決め(検査)、その対応をどのように実施するのが効率的かを精査(適応)します。その都度優先順位を確認し開発の順番を変え、またチームとしての改善を実施することにより、結果としてビジネスに価値のある機能から開発ができます。ブラックボックス化していることが多い基幹システムの刷新こそ、アジャイル・スクラムを活用することでリスクが低くなるといえます(図表1)。
図表1:アジャイル・スクラムの活用で、課題への早期対応が可能
山口:
さらに今回は密結合化していたシステムを調達、物流、販売などのドメイン単位に分割し、疎結合化しています。これにより、一斉切り替えではなく順次リリースが可能です。すでに、一部の移行は完了しサービス提供を始めました。初期リリースでは想定していなかった課題も出ましたが、その経験が次のリリースへの教訓となっています。もし、一斉切り替えを選択していたら、直面する課題もより大きなものになっていたかもしれません。今後順次リリースを重ね、2026年秋にはすべての基幹システムを入れ替える予定ですが、このようなアプローチを取ることでリスクが低減できています。
今泉:
当社システムのブラックボックス化や、初期リリース時の課題に直面し、あらためて、リスクを取ってアジャイル開発にトライしてよかったと思いますね。
中山:
PwCコンサルティングではDXに取り組む際の考え方として、“プロジェクト思考”から“プロダクト思考”への転換を提唱しています(図表2)。
従来、基幹システムなどの業務アプリケーションは「業務を支援するツール」という位置づけでした。そのため、業務側の要件に対応できるシステムを一定期間内に構築する「プロジェクト型」で実施していました。プロジェクト終了後、これらのシステムは時間の経過とともに陳腐化し、数年後に大規模な刷新が必要となる事態に陥っています。
しかしながら、デジタル技術が進化し、市場変化も激しい時代においては、基幹システムも「収益に貢献するプロダクト(製品)」であるという考え方にシフトする必要があります。このような考え方に基づけば、システムは利用者に価値を提供し続ける必要があり、そのために継続的改善を続けることが求められます。今回のプロジェクトも、新基幹システムを「ビジネスに貢献するプロダクト」と位置づけ、今後も継続的に発展していくことを前提としていると認識しています。
図表2:プロジェクト思考”から“プロダクト思考”への転換
今泉:
おっしゃる通りです。今回のプロジェクトは「コア」「ネクスト」「ドリーム」という3つのフェーズに分けており、システムを日々成長させることを想定しています。現在は「コア」の段階で、既存システムからの移行がメインですので、まだビジネスに貢献するプロダクトと胸を張って言える状況ではないかもしれません。ただし、その次のフェーズである「ネクスト」は、顧客に価値を提供するために、これまでやりたかったけれど諦めていたことを実現しようと考えています。ビジネスに貢献するための製品のような位置づけで、システムが進化していくことを期待しています。そして、「ドリーム」では顧客を驚かすようなアイデアを実装する計画となっています。「ドリーム」フェーズが社内に定着すれば今回の改革は成功だと考えています。
中山:
プロダクト思考に転換するためには、業務部門とIT部門が一体となって取り組むなど、組織と人材のあり方も変えていく必要がありますが、プラスではどのように進めていますか。
今泉:
将来的には、各事業にデジタル人材を配置し、IT部門が彼らを支援する形を目指しています。ただ、人材育成も時間がかかります。そのため、まずは事業カンパニーに所属していたデジタル人材を、デジタル統括部門に集約しました。そのうえで、タイミングを見ながらカンパニーに戻していくような方法を考えています。
山口:
デジタル人材を増やすために、既存メンバーの育成だけでなく、スキルを持つ人材を数十人規模で採用しています。育成の観点では、従来事業ごとに属していたメンバーを、事業横断のドメイン単位(調達、物流、販売など)に分割したこともポイントかと思います。たとえば、以前文具事業に所属していたデジタル人材が家具事業に配属されれば、文具だけでなく家具事業の物流も知らなければなりません。さらには、調達や販売の知識も身につけようと思うでしょう。事業ごとで蓄積されたノウハウを共有し、サブドメインごとにアジャイルで開発を行うことで、メンバーが多くの経験を積むことができています。その結果、デジタル人材の育成が着実に進んできています。
ただ、みんなのDXという観点でいえば、現状は100点満点中の25点というところでしょうか。みずからすべてをコントロールするためには、少なくとも50点程度の能力が必要です。2〜3年のうちにその水準に引き上げたいと思っています。
PwCコンサルティング 執行役員 パートナー 中山 裕之
中山:
デジタル人材の育成という観点では、プラスが人事評価制度を見直していることも注目すべきです。企業が育成した人材が十分に評価されず退職してしまった、という事例は少なくありません。今回プラスはデジタル分野における「求める人材」の定義を見直し、その人材が報われるような人事評価制度に改定しようとしています。ここまで踏み込んだDXに取り組んでいる企業は限られ、今回は社長みずからがリードしているからこそできることです。あらためてDXは経営者が覚悟を持って取り組むことが重要であると再認識しました。
今泉:
私自身、みんなのDXはITのプロジェクトではないと思っています。ONE PLUSを目指す企業変革であり、同時に人材育成でもある。だからこそ、社長である私が深くコミットしなければならないと考えています。
中山:
プラスでは、基幹システム刷新でアジャイルを活用し、かつ社長みずからが先頭に立って全社改革を実現しようとしています。このような事例は、世界的に見ても珍しいと思います。基幹システム刷新は多くの企業で直面するテーマですが、ほとんどがIT部門主導です。基幹システム刷新こそが経営の重要テーマであると掲げ、プラスのように長期的な視点で人材育成も含めて取り組むことが大事だと思います。
我々もこの壮大な挑戦をともにできることに感謝しつつ、今回の変革が成功となるよう全力で伴走していきますので、引き続きよろしくお願いします。
※本稿は、DIAMOND ハーバード・ビジネス・レビューに掲載されたPwCのスポンサードコンテンツを一部変更し、転載したものです。
※法人名、役職、インタビューの内容などは掲載当時のものです。
{{item.text}}
{{item.text}}
{{item.text}}
{{item.text}}