NEXISプロジェクト カットオーバー遅延の要因に迫る

真下：まずは今回の延期の理由について教えてください。

沖：理由は大きく5つあります。1つはSAP側の受注と購買の要件定義が遅れたことです。
要件定義が遅れたことによって、マスター系を確定させるのが遅くなりました。
当初はSAPの品目マスターを「正」にする予定でしたが、いろいろな要件を詰めていく中で扇子（Salesforceの営業支援・見積管理システム）側を「正」にせざるを得ないという決断をしました。
これに伴い、当初はSAPから扇子にマスターを送る想定をしていたので手戻りが発生しました。

2つめは業務オペレーションが固まりきらずにシステム仕様決定が遅れたことです。SAP側の開発はギリギリ間に合うスケジュールでした。しかし、扇子の開発は、SAPの仕様にあわせて開発を行うため、SAPのシステム仕様決定遅れが扇子に影響を与え、結果システム全体のリリースに影響がでました。扇子側の開発がSAPの開発に引きずられて遅れるということになりました。

3つめは業務オペレーションの習熟度です。習熟度が全体的にまだ低い状態です。プロジェクトに参画していただいている方の理解は進んでいるのですが、全体的な習熟度は足らない、というのが現状です。

4つめはAMIS（既存の販売管理システム）からのデータ移行です。これがとてつもなく大変です。SAPのデータ構造は正規化されており、会計データを作るためにその前工程のデータはこうあるべきと決められています。そのデータをきちっと入れてあげれば、きれいに流れる仕組みです。一方、既存のAMISはシステム制約が少なく、柔軟にデータ登録が可能です。同じ意味を持つデータが様々なテーブルの項目に保存されています。例えば、AMISの商品マスターに登録されている商品の伝票をデータ移行した際に、商品コード不一致でエラーがでました。これは、マスター登録している商品が存在するにもかかわらず、違う商品コードを使って伝票を作成していたことによるエラーです。伝票を複写して作成する場合に、複写後にマスターを引当直しておけば起きないエラーですが、商品マスターを引当せずに商品名称のみ変更したためこのエラーが発生しています。AMISは商品マスターにデータがあろうがなかろうが伝票を自由に作れて、そのデータで業務処理が行えます。データ値を確認しないとわからないエラー対応はプロジェクト進捗に大きな影響を与えました。

5つめは、日付問題です。SAPでは、収益認識基準で決めた日付が重要となります。アシストの場合、使用権許諾は、納品日、プロダクトサポートは、プロダクトサポート開始日などの定義をしています。この日付データのAMIS上での特定が難しかったことが問題となりました。この受注は納品日やサポート開始日が5月になっているけれど、確定したデータかどうかの判断が難しく、「どうやって移行するのか」方式を決定するのに時間を要しました。様々なデータの精査をしながら、「何をもってこれは売上が確定するのか？」という点を探すのにすごく時間がかかりました。今までがある意味自由でなんでもできるがゆえにきちっと決めようとした時に、データのばらつきが大量に存在し、大変苦労しました。

花田：AMISの自由度が高いということは以前から現場の社員含めてわかっている人が多いと思いますが、想定以上に高かったということですか。

沖：はい、想定をはるかに上回っていました（笑）

真下：遅延した理由として、

とお話しいただきました。

以前、アシストの導入ベンダーであるアイ・ピー・エス（以下IPS）社にインタビューした時に（詳しくは導入ベンダーから見るアシストの業務（１） ～（3））、コンサルタントの方がSAPのプロジェクトを進めていく上で一番大事なこととして、要件と仕様の確定、マスターの確定、そしてトレーニングとまさに今回の遅延理由に当てはまることをあげていました。まさしく今回そこが引っかかってしまったということでしょうか。

沖：はい。見事、教科書通りに引っかかりました（笑）

真下：それだけ大変だということですね。マスターについてですが、やはりSAP内に持つのが王道だと思いますが、アシストの業務プロセスを考えた場合、それはどうしてもできなくて、扇子側でマスターを持たざるを得なかったということですか。

沖：そうですね。営業側からは見積もりの柔軟性が欲しいという要望が強く、SAPに持たせると柔軟性は削がれることになります。SAPと扇子側で2つ持つ、という話になると二重管理になってしまうため扇子側を「正」とするしかないという最終判断となりました。

真下：マスターを扇子側に持つという結論になったのは、現場に押し切られたということですか。

沖：見積もり対応はスピーディに行わなければならないという前提に対して、マスターがボトルネックになって遅れてしまうことは避けるべきという判断をしました。

真下：その結論にいたるには、結構な時間をかけて決めたのですか。

沖：はい、やはりSAPのカチッとしたマスターで進めたいという思いはプロジェクト側にはありました。その前提でプロジェクトも進めていたので、検討には時間をかけました。

花田：習熟度についてですが、どういった部分が要因となったのですか。

沖：業務オペレーションにもいろいろなパターンがあります。スタンダードな処理であれば習熟度は問題ないのですが、スタンダード以外のオペレーションについての定義やトレーニングが足りていなかったということです。

花田：パターンごとの習熟度が低いというのは、パターンが多すぎて洗い出しができなかったってことではなく、「こういうパターンの時はどう処理するのか」ということを皆さんがうまく理解できていなかった、ということですか。

沖：そうです。日付というのがSAPでは重要視されており、月次処理は決められた日付に基づいて動きます。扇子の注文からSAPの受注にわたって、受注から購買請求にその日付が渡ります。アシストではあまりそういうのを意識していなかった。 そういったところの理解度を高めることにも時間を要しました。

真下： 今回リリースが延期されましたが、SAP側の実装はほぼ完了していると聞いています。

沖：はい。2024年10月の時点で完全に終わっており、購買と受注のテストも実施しました。

真下：つまり、SAPではなくフロント部分の扇子側の開発が間に合わなかったということでしょうか。

沖：そうです。先ほど、お伝えした通り、SAPのシステム仕様が固まらないと扇子の仕様が決まらないため扇子の開発着手が遅れる結果となりました。

花田：カットオーバーを延ばすことを決めたのはいつ頃ですか。

沖：IPSさんの開発が終わるのが9月を越えそうだということがわかったところで、そこから扇子側の開発に着手すると間に合わないという判断になりました。
また、アジャイル開発のためシステム全体管理が甘くなり、結果としてシステム全体の整合性をとったテストに時間を要した部分があります。これもまさしく教科書に書いてあるアジャイルの失敗例の一丁目一番地のところに書かれていることです。なかなか難しいですね。この辺りはやってみないとわからないですね。

花田：以前のインタビューでアジャイルだからこそ遅れをなんとか吸収できるという話を伺いましたが、いい面もあれば、ユニットで動くので全体像が見えづらくなるところが露見したということですね。

真下： 今回、会計領域は予定通り稼働しました。

沖： はい、Stage0.5と言われているSmile（会計パッケージ）の置き換えですね。

真下：今回の遅延は従来のAMISが個別最適の塊でデータもバラバラだったということが響いたということでしょうか。

沖：そうですね。 会計業務について今までは経理部の担当者がAMISのデータを受け取ってExcelで変換してSmileに投入していました。その投入先がSAPに変わっただけなので、基本的なSAPの機能さえちゃんと押さえておけば、今までと同じ手順でできるというのがStage0.5です。それがStage1.0になると、今度は上流の伝票がSAPから流れてくる形に変わります。受注伝票、購買伝票、請求伝票がそれぞれ正しくできないと売上の会計処理ができないので、当然販売領域ができないと会計も影響を受けることになります。

真下：もともとの稼働予定の2025年1月は年度初めということで、こだわっていたと思うのですが、今回9月リリースになることによって、難しい部分はありますか。

沖：決算をどうするかというところですね。 年度の切り替えだったら非常にわかりやすいですが、年度の途中になると期で締めた決算をやらないといけない、というところですね。そこの難しさは会計側にはあると思います。

真下：ちなみに今回9月の予定ですが、例えば9月に変わるのと10月で変わるので違いはありますか。

沖：10月はできないですね。 期で締めないといけないので（アシストは1－4月、5－8月、9－12月の3期制をとっています）。 今までは期単位の決算で経理部が手作業で頑張っていた状態です。そのため、期が変わるタイミングでないと切り替えは難しいですね。

花田：今回このカットオーバーが延びたことに対して導入ベンダーのIPSさんの関与度合いは変わってきますか。

沖：はい。体制を強化していただくことになり、より、サポートを手厚くしてくれます。習熟度を上げるためのサポートに力を入れていただきます。

真下：話は脱線してしまいますが、アシストが取り扱っている負荷テストツールであるLoadRunner（現製品名：OpenText Professional Performance Engineering）について聞かせてください。以前、Rise with SAPを採用したお客様から、導入前にサイジングを行い、インフラの構成は決まっているのでLoadRunnerは必要ないという話を聞いたのですが、今回、アシストはなぜ使ったのでしょうか。

沖：アシストはリモートワークの比率が50％なので、自宅からVPN経由でアクセスする際のパフォーマンス確認をしたかったのです。どちらかというとSAP自体というよりネットワークの遅延が発生しないかどうかという目的で利用しました。
結果、ネットワークの問題はなかったのですがSAP側のシステム設定がうまく機能していないことがわかりました。

真下：では、やってよかったのですね。アシストに限らず他のRise with SAPユーザーでも同様のケースはニーズがありそうということでしょうか。

沖：VPNで接続して利用するケースがある場合には意味があると思います。特にグローバルで利用されるユーザーは負荷テストは実施した方がいいと思いますね。

花田：話を戻します。今回の延期について、改めて振り返ってこうすべきであったなど、 もし時間が巻き戻せたら変えたいと思うような点はありますか。

沖：要件確定でしょうね。決められた期間で判断ができると全体のスピードは上がったと思います。

花田：具体的にはどのような場合でしょうか。

沖：要件のパターンが明文化できていませんでした。 皆さんの頭の中にはあるのですが、第三者がわかる状態にはなっていないケースが散見されました。それを準備しておくだけでもだいぶ違ったのかなと思います。

花田：なるほど。目に見える形になっていればよかったということですね。あとから「実はこう思っていたのに」とか言われることもあったのですか。

沖：「こういう場合はどうなるんですか？」と問われて、「えっ？そのパターンって何ですか？」と初めて知るパターンが出てくることはありましたね。Signavio（業務フロー可視化ツール）で業務フローを作ったので、だいぶカバーはされていましたが、それでもやはり「このパターンは？」というのは後から出てきたというのは事実です。

真下：例えばどのような部分で仕様確定がなかなか決まらなかったのでしょうか。

沖：例えば、項目確定のケースでは、後からこの項目がないと困るというのが出てきました。 それだけでも単純に画面の項目を1つ追加するだけではありません。その項目が受注伝票から購買伝票にコピーされている場合は、コピー処理もまた改修しないといけません。また、それを一覧レポートで画面に出しています、となったら今度はレポートの改修をしないといけません。単純に項目を1つ追加するだけでもいろいろな箇所に改修が入ってしまいます。そういう意味の決め事をもう少し早くできれば良かったと思います。

真下：今回はなかなか話しづらい内容もあったかと思いますが、赤裸々に語っていただきありがとうございました。プロジェクト遅延のあるあるをお聞きできたので、これから導入に携わるお客様には参考になったのではないかと思います。