肥大化しブラックボックス化した
基幹システムへの処方箋
中山 日本でもアジャイル開発の活用が広がっています。当社が実施した「PwC 2024年 DX意識調査 ‐ITモダナイゼーション編‐」によると、2023年を機にアジャイルの活用が加速し、現在の普及率は70％を超える結果となりました。しかしながら、それを基幹システム刷新に適用している事例は少ないのが現状です。今回アジャイル開発を適用した決断の背景を教えてください。
山口 当社の事業課題は多岐にわたります。一例ですが、流通事業であれば、商流や商品構成、商品カテゴリーなどの頻繁な変化への対応、家具事業では、オフィスづくりに関わるデザインから導入までの営業リードタイム改善、文具事業では、日々目まぐるしく変化する世界情勢に対応する貿易管理の向上などがあります。これらの課題に対し、システムには高い俊敏性と柔軟性が求められます。最初に要件を定義して3年後に完成するといった従来型のウォーターフォール開発では、事業環境の変化に対応できないと考えました。
デジタル統括部門 執行役員 部門長
山口善生氏
佐野 「大規模システム・基幹システムは従来型のウォーターフォールで、顧客接点などフロントのシステムはアジャイルで開発すべき」と考える方が多いようですが、それは正しいとはいえません。
ウォーターフォール型の開発では、ある機能の要不要を要件定義段階で判断するのは容易ではありません。また、IT側が「不要」と考えても、業務側の合意は得られないのが普通です。アジャイルの場合、たとえば開発が進んで8割の業務が移行可能になった段階で、「本当に残り2割も開発して業務を移行する必要はあるのだろうか」と立ち止まることができる。そして、2割分の投資とビジネス効果を天秤にかけて、最後まで開発するか、8割でよしとするかを判断すればいい。効果の小さい開発にはストップがかかるので、無駄な開発は抑制され、基幹システムはスリムな状態を保つことができます。
山口 当社のシステムは、肥大化も問題でしたが、そもそも長年の改修を経てブラックボックス化してしまっていました。そのため、どんな「隠れ仕様」が出てくるかわかりませんし、実際に少なくない数の「隠れ仕様」が出てきています。このような状況でウォーターフォールの要件定義を行っても、いつまで経っても完了できない可能性が高いです。たとえ要件定義をしたとしても、すべての要件をプロジェクト初期段階で網羅することは不可能に近く、後々大きな手戻りが発生しかねません。そこで、ブラックボックスを前提とし、自分たちでその中身を深く掘ってひも解きながら、一歩ずつ前進するやり方を選びました。このプロセスは「業務がわかるIT担当者」「ITがわかる業務担当者」を育てるうえでも重要です。
佐野 アジャイル開発の代表的なフレームワークであるスクラムでは、「透明性」「検査」「適応」が重要な考え方です。たとえば、隠れた仕様が出てきてそれに対応する場合、リリース時期や予算などにどのような影響が出るか見える化（透明性）を行い、どの機能のビジネス価値が大きいか判断し優先順位を決め（検査）、その対応をどのように実施するのが効率的かを精査（適応）します。その都度優先順位を確認し開発の順番を変え、またチームとしての改善を実施することにより、結果としてビジネスに価値のある機能から開発ができます。ブラックボックス化していることが多い基幹システムの刷新こそ、アジャイル・スクラムを活用することでリスクが低くなるといえます（図表1）。
図表1 アジャイル・スクラムの活用で、課題への早期対応が可能
山口 さらに今回は密結合化していたシステムを調達、物流、販売などのドメイン単位に分割し、疎結合化しています。これにより、一斉切り替えではなく順次リリースが可能です。すでに、一部の移行は完了しサービス提供を始めました。初期リリースでは想定していなかった課題も出ましたが、その経験が次のリリースへの教訓となっています。もし、一斉切り替えを選択していたら、直面する課題もより大きなものになっていたかもしれません。今後順次リリースを重ね、2026年秋にはすべての基幹システムを入れ替える予定ですが、このようなアプローチを取ることでリスクが低減できています。
今泉 当社システムのブラックボックス化や、初期リリース時の課題に直面し、あらためて、リスクを取ってアジャイル開発にトライしてよかったと思いますね。
