導入ベンダーから見るアシストの業務（2）

真下：続いて、今回のプロジェクトにおいて、IPSさんとアシストの役割分担はどのようにされたのかお聞かせください。

IPS：はじめに全体最適を行うためにアシストさん側でToBeの業務フローのパターンを確定させることをしていただきました。
相当数の個別最適な業務がありましたが、受注業務はこの形、発注業務はこの形、というように業務ごとに統一したパターンを作っていきました。これをプロジェクト内ではバリューチェーンと呼んでいます。
次に取扱商材について、ライセンス販売、サービス販売、チケット販売など大きな分類を行い、それぞれどのフローでどういった業務の流れを使うか決めていきました。
これがアシストさんの一番大きな役割になります。作成された業務フローを受けてIPSは、SAPで用意されているプロセスの中から、どの業務フローにどれが合いそうなのかを提示しました。
いくつかあるSAPのプロセスについて、それぞれの特徴を説明し、商材や業務フローに使うプロセスを決めていくというキャッチボールを行っています。
ウォーターフォールの場合は基本設計ではっきりと決めてしまうのですが、今回はアジャイルスタイルをとっていますので、実際にプログラムを組んで動かすプロトタイプ検証を実施しました。検証の結果、業務に合わない、問題が発生することが想定される、と指摘されることがあります。課題として挙がった点についてはもう一度振り返って、例えば、ここは統合した方がいいのではないか、ここはパターンとして分けるべきなのではないか、といったキャッチボールしながら決めているという役割分担になっています。

真下：IPSさんが過去に担当されたお客様と比較したNEXISプロジェクトの特徴についてはいかがでしょうか。例えば、プロジェクトの進め方としてアジャイル前提だとべンダーとしてはやりにくいとか、率直に本音で伺えればと思いますがいかがでしょうか。

IPS：アジャイルだからやりにくいというのはありません。

プロジェクトのコントロールをどうするかだと思います。アジャイルの場合、先ほども話があったように、一度作ってみて「もっとこうしようよ」などの議論を重ねて 着地点に到着するというのは良いと思います。

ただ、これが続くうちに、プロジェクトメンバーは「後で変えられる」という意識になってしまいます。“仕様をどこで凍結するのか”という意識がすごくおろそかになりやすくなるため、その点をどう対策するか考えておく必要があります。アジャイルを採用する際にプロジェクトのコントロール、つまり仕様凍結はどこでどうするのか、という明確な決まりをプロジェクト発足時に持っていないと難しいことになる、ということを今回のケースで勉強しています。

岡田：プロジェクトの後半になればなるほどステークホルダーがどんどん増えてくるんですよね。教育のフェーズになると、参加するメンバーもどんどん増えます。後から参加したメンバーのプロジェクトに対する思いや考えは、プロジェクト発足当初から参画しているメンバーとはどうしても温度差が発生してしまいます。今はそこが大きな課題だと感じています。

駒形：プロジェクトとしては、いままで全体最適で進めてきて、教育の時期になって実際に現場で業務を担当されている方が入ってくると思います。その方々から既存システムとの違いに対する違和感が上がってくるということでしょうか。

岡田：はい、今、その狭間にいる状況です。

IPS：ウォーターフォールアプローチであれば「決まったことです」と言えるじゃないですか。プロジェクト側から「無理です」と胸を張って言えるのです。今回のようなアジャイルアプローチの場合、「決まったことです」と言えるポイントを厳格にルール化する必要があったと思います。
アジャイルによって、決定を後に延ばせるイメージを皆さんふわっと持ってしまっています。われわれとしては「ここで決まりだよね」と思って「その点は仕様凍結です」と言っても、「でも今回の手法はアジャイルだよね」となり、合意形成が図りにくいです。

岡田：プロジェクトとしては、そこを打開するために林（プロジェクトオーナー、執行役員経営企画本部長）、石倉（PMO）、柳（販売領域リーダー）、小牧（会計領域リーダー）と私（岡田：PM）と沖（PM補佐）からなるプロジェクト全体の意思決定会議をスタートさせました。
本来はプロジェクトマネージャーのレイヤーで意思決定を行おうとしたのですが、5月に業務改革センター※が新設されました。それにより、組織として決めるべきことなのか、システムの仕様として決めることなのか、を議論していく中で、そもそも今の現状の業務の課題を吸い上げて最終的に仕様凍結を判断する会議体が必要であるという結論に至りました。
林が座長で沖が副座長という形に、柳と小牧を交えた上で、最終的な意思決定をしていこうと考えています。
会計と販売、それぞれのリーダーが会議体に参加していますが、会計チームと販売チームがそれぞれバラバラで動いているところがあります。間をうまくつなげようという目的で、石川（システム部長）、沖、石倉と私が、それぞれで重要課題とされたものに関して、方向性、議論の論点を整理して、意思決定会議に送る体制（通称：のりしろさん）としています。
それを今やらないとプロジェクトとしてずるずる行ってしまって、最終決定が延び延びになってしまう懸念があります。また、As-Is回帰じゃないですが、それこそAMIS（現行の販売管理システム）2が出来てしまうのではないかという危機感がプロジェクトメンバーにはあります。

※）業務改革センター
従来、各部門に点在していたバックオフィス業務を本センターに統合。お客様からの受注処理、仕入先への発注処理を一手に担う部門であり、今回導入するSAPの主な利用者

IPS：仕様を決める中で最後まで残っている課題は大物なわけですよ。難易度が高かったり、他の部門が絡んでいたり、関係者が多いのが最後まで残るのです。簡単なものはすぐに解決していくわけです。
そうした時に業務に携わる人たちは「今の方法でやってもらえれば間違いがない」とどうしてもなるのです。そうするとAs-Is業務を焼き直してくる仕様になるのです。気持ちはすごく分かります。関係者が多い中で「こう決めました」と今までと違うやり方に舵を切ることは難しく、「今やれることをできるようにしてください」というのが一番安全なわけです。お客様、仕入先にも迷惑が掛からない。経理に対しても今と同等のサービスなので、楽にはならないかもしれないけれど迷惑は掛からない。そのような考えで、どうしても現状維持の方向で議論が進むというのはよく理解できます。

岡田：そうならないために設けた会議体です。
元々プロジェクトを始めた時は、「パッケージ（SAP）の機能に合わせて業務自体を整流化していきましょう」ということがプロジェクト全体の根底としてあり、コアメンバーは長く接しているので理解しながら動いています。しかし、ステークホルダーがどんどん増えていくと、As-Is回帰の問題が顕著になってきます。その中で最終的に整流化の観点や業務の標準化の観点を軸にしたときに、どう仕様を決定するか、それぞれの課題を解決するためにどうするべきかという議論を会議の中で行い、業務改革センターと本プロジェクトの双方のオーナーである林から組織面、プロジェクト面、それぞれに対して発信し、浸透を図ろうという方針です。

真下：今回はアシストの希望で始まったと思いますが、アジャイルでの構築はIPSさんにとって初めてのプロジェクトですか。

IPS：この規模においてアジャイルでプロジェクトを進めますと標榜して行ったのは、私にとっては初めてです。

基本的にウォーターフォール型はきちんと仕様を決めて進めます。その上で業務フローをSAPのプロセスでプロトタイプ評価しましょう、ということはウォーターフォール型のプロジェクトでも普通にあることです。その結果、もちろん揺れ戻しが発生し検証を繰り返すことはありますが、SAPはプロセスがパッケージとして決まっているので、今回のように何回も回すことはあまりないです。

とはいえ、極端に言うとそれを高速回転で様子を見ながらディスカッションして作り上げていきましょうというのがアジャイルの正体だとしたらそこに違和感はありません。
その期間をどれくらい取って、何回、回すかのシナリオの設計だけちゃんとすればよい話です。「いつ決めたものを最終とするか」というルールの決めが弱かったのが今回の問題だったと思います。

駒形：ウォーターフォールでプロトタイプ検証をすることもあるということを考えると、IPSさんようなSAPベンダーからすると、仕様がなかなか固まらない中で進めているアジャイル的なやり方というのはやりづらい部分はありますよね。

IPS：そうですね。先ほどからお話ししている「仕様をどこで固めるか」という合意をプロジェクトの初期段階でどうルール化しておくかということ。そこだけがあればよかったですね。
ウォーターフォールの場合、プロトタイプ検証は、普通2回ぐらいあります。1回で終わることはありえなくて、1回検証して意見を頂いて、次にその意見を反映したものを見て確定させるといった具合に、2回検証してその時点で決めたもので仕様確定です、ということをプロジェクト計画の中で合意しておくわけです。
そのため、「2回目はしっかり見ないとだめだぞ」という意識がありユーザー側もすごく真剣になります。今回はアジャイルだから何回もオッケーとなると、どこで決めなければならないかという責任を薄くしてしまう可能性があるやり方だったかなと思うので、そこの決め方の厳格なルールを事前にどう用意するかが、アジャイルで推進する上でのポイントだと感じています。

真下：アジャイルで仕様を決めるのにプロトタイプを回す回数はどれくらいが適当でしょうか。

岡田：回数の問題というよりは、各チームが言っていることの整合性をいかに取るかが大事です。各チームがそれぞれの視点で課題を挙げてくるので、販売系で問題になっていることに対応しようとすると、会計チームからは「いやいや、ちょっと待ってよ」となることがあります。その点を全体俯瞰で横串を通せていない点が大きな課題だと考えています。

IPS：アシストさんの業務の特徴として前回 お話しした、最終的に経理が尻拭いをしているという状況があります。販売管理を改革することでそれを解消することを目標の一つにしていますが、経理側には過去の経緯から「販売管理側がどうするのかを決めてくれないと自分たちは動きようがない」という受身的な考えがあるように感じます。プロジェクトとしては、全体最適を考えて販売管理はこうあってくれという主張を経理にも期待するのですが、経理以外のプロセスが関わる課題がきたときに「いいよ、決めてくれればやるから」となってしまっています。
今起こっていることはそういうことで、「言われたとおりにやるから決めて」という受身的な立場になりつつあるという状況です。これを全体最適の目線からどうあるべきかを決めましょう、という本来のプロジェクト発足の時の志に戻さなければいけない、そこの難しさですかね。

岡田：そこは各チームのメンバーだと難しいと思うんですよ。
全体最適という観点で見ると、プロジェクト全体を俯瞰して見られるメンバーで体制を組む必要がありますが、これまでは各チームのメンバーは個人の視点で物事を受け止めたり発言をしていたりしていました。それが5月に業務改革センターという形で業務全体を俯瞰していく必要がある組織が立ち上がったことで徐々に自分事として、自分たちが何をするかという観点でプロジェクトに携わるようになってきています。

IPS：昨年はまだ人ごとのようにとらえているメンバーがいました。「誰がするか分からないけれども」という枕言葉があって、「こうした方がいいんじゃないですか」、「そうなった場合は銀行口座からこうした方がいいんじゃない」という個別最適に寄っていく流れだったように思います。ところが５月に業務改革センターができて具体的に自分が何をしないといけないかが見えてきました。実際7月以降、メンバーに対して教育をスタートしないといけないとなってくると、しっかり自分に落とし込まないといけないし、自分も意見を受ける立場になってきます。それぞれの内容をしっかりと理解しなくてはいけないという意識になってきているのは確かに感じます。

岡田：SAPのリリース前に業務改革センターが立ち上がったことで、SAPを利用する人が、物事を議論して意思決定していく過程に自分事として参画することができるので、出来上がるものの粒度や納得感がまったく違うと思います。

駒形：先ほど、IPSさんからアシストは個別最適の権化で極端な個別最適が進んでいるところに、SAPを導入するための難易度が高いという話をお聞きしました。他社のFit to Standardの適応率はどの程度でしょうか。

IPS：私の感覚ですがコロナ前と後でだいぶ違っていると感じています。IPSは10社ぐらいのプロジェクトに並行して携わっていますが、コロナ明けくらいからはFit to Standardを意識しているお客様がほとんどです。コロナ前までも、もちろんFit to Standard、SAPのプロセスに合わせますとおっしゃっていましたが、問題が発生した時に、仕方ないからアドオンしようという考えが残っていました。直近、私が関わった3つ、4つのプロジェクトではそれが極端に減ったように感じています。

駒形：それはなぜでしょうか。

IPS：今後成長するにあたり、追加開発が必要になる個別最適は弊害になると分かったからだと思います。

駒形：それを経営者が分かってきたということですか。

IPS：そうですね、経営者同士で情報交換をされている方が多いので、導入する前に、「こういうところが問題だった」という話を聞く機会が増えたからだと思います。

色々なお客様の話をお伺いしても、「Fit to Standard」という言葉が出てくるようになり、特に2020年くらいからその傾向が顕著だと感じています。現在のシステムをスクラッチで作っているお客様では、システムの運用保守ができる人がいなくなり、ブラックボックス化していることが多いです。また、スクラッチでない場合でも、パッケージに個別最適用のアドオンを大量に作成してしまい、次の移行の足かせになることもあります。そのため、次のシステムを導入する際には、極力作り込まない方針を取る企業が増えています。作り込む場合でも、今回のアシストさんのように、Salesforceなどの周辺パッケージとの組み合わせでカバーしようと考える企業が増えてきたように思います。

駒形：Fit to StandardはSAPからすると今言い始めたことではなく、ECC6.0やR/3の時から言っていましたが、当時のお客様の話を聞いていると、ほとんどのユーザーがかなりのアドオンをしており、何のためにSAPを入れたんだという話が多くあったと思います。それがようやくこのタイミングに来て、本来のSAPのコンセプトに合わせて実装しようという話になったということでしょうか。

IPS：2018年に発表された2025年の崖という経産省のDXレポートが2019年～2020年に話題になり、それによってIT人材の不足について大きな危機感を持つ経営者が増えたのだと思います。少人数でカバーするには生産性向上、効率化、標準化が必要である。生産性の向上のために標準化しないといけない。人がいなくなるから属人化だと、業務の継続性が保てない。それらのことに危機感を持つ企業が多くなったので、標準化を目指してFit to Standardの方向に進んでいるのではないかと感じています。

皆さん学びましたよね。2000年代はアドオンが当たり前でしたからね。

ベンダー側もその頃はアドオン増やすとお金をもらえましたしね（笑）。ただ、アドオンが多過ぎると失敗するということをベンダー側も学びました。そのため、プロジェクトの当初から「アドオンはしない、ということを方針としてください」と2010年くらいからベンダー側がしきりに言うようになりました。そういう業界の啓蒙活動の影響も大きいと思います。いざ導入しようという場面で、失敗事例をトップのマネジメントの方が勉強するようになっています。アドオンすると失敗するんだ、ということを学んだのだと思います。アシストさんのアドオンの状況を見ると、2年前の夏にTo-Beの業務フォローを作ったときに、継続保守契約の処理や帳票などで、アドオンが必要になるという話をしていました。その頃と比べて、現在アドオンが増えているかというと増えていません。あとはSalesforceやBlackLineなどの周辺システムを活用してSAPに盛り込むのでなく、そちら側で吸収しようという考えできれいに整理されています。

真下：ECC6.0からS/4HANAに更改するユーザーのケースを聞かせてください。このタイミングでDXを推進するため、業務改革のために、ECCの資産もゼロクリアして再構築されるユーザーがいる一方で、ECC6.0の資産をそのまま移行するストレートコンバージョンを選択するユーザーも相応の割合でいると思います。その理由はなぜだと思いますか。

IPS：今困っていないから、現状維持、プラスちょっと良くなったらいいな、くらいの考えだとストレートコンバージョンの方を選ばれるお客様が多いかなと思います。

真下：IPSさんの肌感覚的に割合的にはどちらが多いですか。

IPS：コンバージョンを選択される方が多いと思います。

真下：困っていない、というのは業務が最適化されている、というわけでもないですよね。

IPS：業務が回っているということですね。 業務はマニュアルではなく、人で動いているということです。これは日本の会社の特徴ですね。欧米によくある、基準に沿って決められた作業をちゃんとこなしましょう、というのと日本は異なります。書籍で読んだのですが、SAPの導入には日本と日本以外では期間もコストも倍くらい日本の方がかかっているそうです。

何かこだわりがあるのか、捨てられないのかわかりませんが、暗黙知とされているプロセスをどうしても織り込まないとならないことが多いです。なぜそれが必要なのかということに対して、今やっているからという理由がほとんどです。例えば、取引先から電話で「今すぐこの商品を持ってきてくれ」と言われて、2時間後に赤帽やバイク便を使って届ける、というサービスをしている企業です。これは顧客サービスの一環で、これをしないと取引先を失う、ということでやっているのですが、今のご時世でいうと、そのサービスは過剰サービスじゃないですか。働き方改革うんぬんと言われている中で受けてはいけない依頼です。欧米などは多分やらないですよ。でも日本の会社はそれを受けている。ということは標準系の仕事のやり方に対してプラスアルファがないとそのサービスが維持できない、ということになります。それをシステムで実現しようとするとアドオンになる。そのサービスは本当に自社にとって有効なサービスなのか？ということをあまり議論していないですね。それをしないと負ける、取引先を失うと言っているのですが、実証はされていないですよね。感覚的な部分が多いです。そういうサービス提供側の意識が日本においてSAP導入を難しくしている要因の一つではないでしょうか。導入する前に業務の標準化もそうですけれど、お客様に提供しているサービスを再定義する必要があると思います。その結果、「これを続けることがわれわれの生き残る道です」ということであれば、その会社のスタンダードとしてやればよいと思います。


（３）へ続く
（本記事は2024年10月に行ったインタビューをもとに執筆しています）