SAP S/4HANA導入の道のり　～会計編1～

駒形：1つめの質問として、NEXISにおけるSAPシステム開発と、従来のスクラッチ開発の違いについて教えてください。
SAPはパラメーター設定をメインに実装していくというのが特徴であると聞きますが、今回、アシストではどのように開発に取り組んでいるのでしょうか？

岡田：設計はSignavioというツールで行っています。
会社の業務プロセスごとに業務フローをSignavioで描いて、その業務フローをもとにパラメーターをSAP上に設定してもらい、設定済み環境でユーザーが実際の画面や挙動を見ながら要件や機能を詰めていく、といったプロトタイプ検証を行う形をとっています。
実際の画面や挙動を確認して、どう実装していくべきなのか、どういった点を改善する必要があるかということをベンダーとすりあわせるところが実質的なシステム開発にあたります。

駒形：なるほど、Signavioで設計したものをSAPで実装、その環境でプロトタイプ検証を行うのがNEXISプロジェクトの開発スタイル、ということですね。

Signavioを使ってどのようなことをされたのか、もう少し詳しくお願いします。

岡田：まず、Signavioで事業や業務全体のAs-Isを描画し、そのAs-Isをみんなで眺め、整理しながら、このあたりの業務がごちゃごちゃだから整理しないといけないね、あるべき姿としてはこんな感じになるはずだよね、といった議論を重ねました。その流れでアシストではおおよそこんなTo-Beモデルになるだろう、もしくはこんなTo-Beにしていかなきゃいけないよね、というところを次にSignavioでTo-Beとして描画していきました。ちなみに、この初期のTo-Beモデルを材料として、ERPパッケージを選定しました。

※）アシストが抱える業務面、システム面の課題について ～後編～

真下：To-Beモデルを材料にSAPを選定したのですね。
もう少し具体的にTo-Be作成作業過程といったものをご説明いただけますでしょうか。

石倉：はい、先ほどお話ししたSAP選定前にTo-Beとして落とし込んだものは業務機能（L4）です。
この業務機能をもとに、実際の業務を単位作業（L5）に落としていったものが、SAPでの実装の対象になるものです。
今回の導入では、SAP実装ベンダーであるIPS社（※）提供のテンプレートEasyOneを利用しています。
実装ベンダーの選定は、ERPを検討する段階で並行して行っていました。
検討の結果SAPが選定された際に、実装ベンダーをIPS社に決めたのは、このテンプレートの存在も大きいです。

※）IPS社：https://ips.ne.jp/

テンプレートには標準的なSAPプロセスや業界特有の業務がある程度反映されているので、その設計情報を読み解きつつ、その中で自分たちの業務に当てはまる部分を選択し、なければ追記していく形でモデル化していきました。
最終的に設計情報は全てSignavio化する予定です。ちなみに実際の議論や作業ではStrap（※）というツールも併用しています。

※）Strap：https://product.strap.app/

駒形：ベンダーのテンプレートを活用されているということですね。
そのSignavioで描かれたTo-Beをもとにプロトタイプ検証を行うのでしょうか？

岡田：To-Beとして定義された情報とプロトタイプでの検証ポイントをまとめたものをもとに、IPS社がSAPのパラメーター設定を行います。
その結果が、SAP上で画面や業務フローが動くプロトタイプとしてアシスト側に提供されます。
提供されたプロトタイプをIPS社とアシストで検証しながら修正をかけていく、というイメージです。

駒形：それが今進めてられているプロトタイプ検証という作業ですね。
プロトタイプですぐに詳細な業務プロセスが決まるものでしょうか？

石倉：先行している財務会計（ステージ0.5（※））に関して言えば、都合3回プロトタイプ検証を回しました。
設定してきてもらったものをもとに実機でプロトタイプ検証を行って、自分たちが想定していた動きと違うなど、意図と違う部分のすり合わせを行い、それに沿ってIPS社にパラメーター修正等をしてもらいました。
1回目はおおざっぱにSAPで実現していく場合のフローを確認していくような感じで、2回目は1回目では後回しにしていたところや、曖昧になっていたところなどを潰したもので実施し、その結果をまた持ち帰ってもらいました。
それを設計に反映し、3回目でさらに細かくほぼ業務的な動きをしているものをベースに仕上げていくという流れです。

※）アシストでは現在、販売管理システムと会計システムの2つののシステムが連動して稼働しており、再構築では先に会計をSAPに置きかえ、その後に販売管理をSAPに置き換える（「SAP S/4 HANA導入プロジェクトの軌跡。まずは概要です。」参照 ）。そのため一時的に既存の販売管理のデータをSAPの会計に連動させて運用するステップを踏むこととしており、この状態をステージ0.5と表現している。

真下：検証はどのくらいの間隔で行ったのでしょうか？

岡田：プロトタイピングの間隔は、平均するとおおよそ2週間くらいだったと思います。並行して、SAP標準やテンプレートだけではカバーできないところの洗い出しと対策検討なども行っていましたので、まったく同じ間隔で実施したわけではありません。

駒形：最初に質問したスクラッチ開発のような開発工程は、このプロセスにはないように思いますが、従来の「スクラッチ開発」との違いは他にもありますか？

石倉：大きな違いは、従来のIT部門や「ベンダー中心」の開発ではなく、「ユーザーが中心」ということですね。
複数のスクラムチームで活動していますが、財務会計チームには経理のメンバーが入っていますし、チームリーダーであるプロダクトオーナー（以下PO）も経理です。

今回、かっちりとした仕様書を実装ベンダーには出していません。
仕様書どおりに作ってください、出来上がったらチェックします、というやり方でなく、現場を中心に、重要なところから実装を進めていく手法を採りました。
アジャイル開発ベースでSAPを実践しようと思うと、次のような流れとなり、まとめると、おおまかには3つの作業になると思います。

この作業を繰り返して、徐々に業務の形ができてくるイメージです。
「スクラッチ開発」でイメージするようなプロセスはどこにもないんですね。

真下：確かに従来の「スクラッチ開発」とは大きく違いますね。
アジャイルやスクラムの話がでましたが、今回はアジャイル開発の中でもスクラム開発手法を採用されたのですね。

岡田：今回のNEXISプロジェクトでは、プロジェクト全体をアジャイルで運営しています。
その具体的な方法論として、スクラムを採用しました。
アシスト内で情報システム部門をはじめとした各部門での小規模なスクラムの取り組みはありますが、プロジェクト全体として採用したのは初めてではないでしょうか。
先ほど少し話がでたように計画段階からスクラムを推進していますので、各業務単位にスクラムチームを編成し、チームビルディングとしてインセプションデッキ合宿なども行ってきました。

真下：どのようなスクラムチームがあるのでしょうか？

岡田：スクラムチームは業務分野ごとに存在します。具体的には、財務会計チーム、発注チーム、受注・請求チーム、管理会計チーム、システム基盤チーム、アプリチーム、レポートチームです。
あとは、設計のSignavioチーム、プロジェクト運営のための事務局などでしょうか。
業務系のチームには、PO（ユーザー部門代表、チームリーダー）とPO補佐（主としてラインマネージャー）に、SM（チーム運営やシステム基盤チームとのつなぎ）が1名以上います。

駒形：システム基盤チーム、アプリチームというのはどのような役割を担っているのでしょうか？

石倉：システム基盤チームは、ユーザー環境設定、データ準備等インフラを担当しています。
今回、NEXISでは、SAP S/4HANA Cloudのユーザー環境等のアプリケーションインフラをIPS社に支援していただいていますが、将来的にはアシストで巻き取っていきたいと考えていますのでそこを見据えて活動しています。
あとは、周辺システムなどとのインターフェース周りに対応してくれています。

岡田：アプリチームは、Salesforceのシステムである扇子（営業システム）からSAPへの連携など主としてSalesforce開発を担当します。
また、レポートチームは今後の帳票開発を担当することになると思います。

真下：その全体を統括するのがPMの岡田さんですね。
アジャイル開発に取り組んでいく上でのご苦労などを教えてください。

岡田：PMとしては、IPS社との調整が一番の仕事ですが、IPS社への依頼内容の変更･調整に加え、各チーム横断的なスケジュールや進捗管理など、ウォータフォール系とは違うアジャイルならではの負荷がかかってきています。

駒形：他にアジャイルで進める上で、プロジェクトとして重視した点はありますか？

石倉：SAP実装ベンダーとの関係性でしょうか。
ERP検討の1つのポイントとして、実装ベンダーとアジャイル開発という方針をプロジェクト開始前から握っておくことができるか、という点がありました。

岡田：複数のSAPベンダーと面談させていただいた中で、IPS社と出会えたのがSAPにGOサインがでた理由の1つだと思います。
IPS社とはおおよその作業範囲を合意していますが、柔軟に対応してもらうことも同時に合意しています。
今でも、アシストのアジャイル開発方針に沿った見積作成やタスク管理など、都度すりあわせつつ一歩一歩進めている感じです。

駒形：アシストは普段ベンダー側ですが、今回ユーザー側として具体的にIPS社とはどんな風に進めていますか？

岡田：構築を進める中でIPS社の役割として定義した部分でも、アシストで巻き取れるもの、例えばユーザー教育はアシストで巻き取っています。
代わりに当初は見えていなかったもの、例えば環境周りの支援を厚めにIPS社にお願いしています。

真下：IPS社との調整に加え、チーム間調整となかなか大変そうですね。
ところでIPS社からは何人くらいプロジェクトに参加しているのですか？

石倉：今は、財務会計は4人前後、あとはロジ（受注、発注）に3名前後、データ移行他システム関係で3名前後でしょうか。
方針検討やタスクの調整などについては、必要に応じてIPS社の役員も議論に参加してくれています。
このあと、ロジの本格化に加え、管理会計も始まるので増えると思います。

駒形：なるほど。アジャイルの各チームに合わせてIPS社も動いているのですね。

真下：話が少し変わりますが、さきほどIT主導ではなく、ユーザー主導で進めているというお話がありましたが、そのあたりの補足をいただけないでしょうか。

岡田：システムは現場に定着してこそ意味があると考えています。
そう考えると、その業務プロセスを一番知っている人がプロセスの定義に関わるべきです。
それなしで、ある時唐突に「これを使ってください」といっても納得いかないでしょうし……。

真下：ユーザー主導にすると、現在の業務プロセスに流される危険性はないでしょうか？

岡田：そのためにSignavioでTo-Beを定義するところから、現場のユーザーにも入ってもらっています。
さきほど話に出たインセプションデッキ合宿で、可能な限りSAPの標準やテンプレートにあわせていこう、という方針は共有済みです。
実際に業務フロー検討も、まず標準プロセス＋IPS社のテンプレートを学習して、それを正としよう、ということを合意した上で行っています。

真下：As-Isに流されずに、標準を意識しているということですね。

石倉：そのとおりです。
ただ、AS-ISの業務は標準プロセスやテンプレートにないからといってまったく不要というわけではないのです。
As-Isは、言ってみれば、これまでの知恵の蓄積であり、お客様のための現場の工夫が詰め込まれているものという側面も持っています。
そのため、それらをどう生かしていくのかという視点も大事だと思っています。
これまでの工夫や現在進行形の問題や課題も勘案しつつ、すりあわせながら進めていけるのも、現場の皆さんを主力に進めているアジャイルならではの良いところです。
RFPを出した後は現場はほとんど関与せず出来上がりを待つのみ、といったウォーターフォールではこうはいかないと思います。

ここまで、どのような体制でどのようにプロジェクトを進めているかをお話しいただきました。
後半では実際の工夫点や利用ツールをお話しいただきます。