移行方針と社内浸透について

真下：今回、ビッグバン導入ではなく、販売系と会計系を分けてリリースすることにした理由を教えてください。

岡田：リリースの方式についてはプロジェクトで多くの議論が交わされ、意見が割れた部分でした。最終的に分けてリリースすることに決めた理由として大きいのは、アシストは12月末が決算期で1月から新たな1年が始まることを考えたときに、販売系と会計系を同時にGo Live（リリース）をするのは大きなリスクを伴うであろうと考えたからです。また、従来からシステム的にAMIS（販売管理）とSMILE（会計）が完全に分断されていたことも理由の１つになります。ただ、分けたことによるデメリットも発生していて、元々想定していたよりもタスク数が増えたり、同時に決定できるはずの事項が決定できなくなったりしました。
ビッグバンと分割リリースのメリット・デメリットを考慮した結果、今回はビックバン方式ではなく、まずは会計からリリースを行うことにしました。1年間の決算データをSAPに正確に入力できるようにすることを最も重要な目標としました。

沖：人手不足の問題もありました。ビックバン方式を採用するとそれなりの人員の確保が必要となります。その場合、社内の人員だけではなく外部の人員も必要となりますが、ベンダーも十分な人員確保をできる自信がないという状況でした。これらを考慮した結果、部分的に進める方が良いと判断しました。他社もビックバン方式を採用しているケースは少なく、先に会計を立ち上げて、その後に販売や生産管理を立ち上げるという進め方をしている事例が多いとの情報も参考にしました。

駒形：他社でもビックバン方式を採用することが少ない理由は人員確保の問題が大きいのでしょうか。

沖：それもありますが、まず独立したシステムを構築することでSAPの習熟度を上げてから、次のシステムに取り掛かりたいという思いもあるのではないでしょうか。

真下：議論を重ねた結果、リソースなども含めて考えると分けるしかなかったということなのでしょうか？

沖：結果的にはそうです。

駒形：ビックバン方式を見送ったことによるデメリットについて、他にもありましたら教えてください。

岡田：ビックバン方式で一斉にリリース場合、販売管理から会計まで全てを連携した状態で設計が可能です。しかし、見送ったことで、会計＋AMIS（販売管理）の段階（※1）と、販売管理から会計までをSAPで行う段階における2段階（※2）の業務とシステムの設計が必要となりました。

※1）プロジェクトでは、Stage0.5と呼んでいます
※2）プロジェクトでは、Stage1.0と呼んでいます

真下：設計が2回必要になるということは、やはり分割することによりトータルコストは増えてしまうのでしょうか。

岡田：普通に考えれば増えてしまいます。そこをできるだけ抑えるように必死に頑張ったため、余計に大変になってしまいました。

駒形：先ほどの沖さんの話によると、ビックバン方式を採用すると人員の増強が必要となるため、リソースやコストはビックバン方式の方が多くなるのでしょうか。

沖：時期をずらすことで、人員リソースを割り振ることができます。結果、全体のコストは一緒でそれを分散させているということです。

真下：元々経営陣からはビックバン方式で行うようにとの指示はありましたか。

沖：特にありませんでした。

岡田：全社に及ぶ影響を最小限として、安全にリリースをさせるようにとの指示はありました。

真下：Stage0.5に関しては経営陣からの指示どおりに安全にリリースできたのですね。

沖：2024年1月の処理は無事完了したので良かったです。しかし、Stageを0.5と1.0に分けた結果、Stage0.5を優先する必要が出てきました。これにより会計担当は、まずリリースに向けての取り組みに注力しなければならず、Stage1.0の業務が少し滞ってしまうという問題が生じています。立ち上げを優先してそちらに集中すると、どうしてもStage1.0の業務が後回しになってしまうのは避けられませんでした。

真下：具体的にどういった処理でしょうか。

沖：今回1月にリリースしたのは会計の部分です。これにより決算は可能な状態となりました。しかし、まだ債権債務処理や販売管理と関わる部分の会計処理は残っており、これらについて、決定しなければならない事項が多く存在します。そうしたものが後回しになってしまい、今後、短期間で決定しなければならない状況となっています。

駒形：会計に集中しなければならない上に、債権債務などの他のタスクも存在し、まだ手がつけられていないとのことですが、これが後工程に大きな影響を及ぼす可能性はあるのでしょうか。

沖：そうですね。影響が出るという想定のもとで、ベンダーと再スケジュール設定を進めているところです。

駒形：その影響により、当初の予定と比べて何ヵ月間ぐらい遅延が発生してしまいそうといった想定はありますか。

岡田：リリースのタイミングは期初でなければなりません。そのためアシストの場合、9月を逃すと、次のリリースのタイミングは1月となります。現在は2024年9月に間に合うように、リカバリープランをベンダーと一緒に検討しているところです。

※）アシストは12月決算の1－4月、5－8月、9－12月の3期制

駒形：当初の予定は何月だったのでしょうか。

岡田：当初の予定も９月でした。

駒形：それでは遅延は発生しないということですね。

岡田：遅延を防ぐために、今、全力を尽くしています。2025年1月のリリースになると、決算時期と重なってしまうため、全社に影響を及ぼすリスクが発生する可能性が高くなります。特に現場スタッフが最も多忙な時期となるため、このタイミングでのリリースは避けたいと思っています。そのため、プロジェクトとしては何とか2024年8月にリリースを決定し、2024年9月に切り換えることができるように様々なリカバリープランを検討しています。

真下：具体的にどんなリカバリーを行うのでしょうか。

岡田：会計チームからも一部のメンバーに参加してもらうとか、プロジェクト開始当初に考えていたスケジュールを組み換え、先に決定しなければならない項目と後からでも問題ない項目にタスクを分けることをベンダーと進めています。

真下：2024年9月に間に合わせるために何かを後回しにするとか、ここは1.5として先送りにしようなどの検討をしているということでしょうか。

岡田：現在、具体的に開発しなければならない箇所や追加が必要な個所について優先順位を決めるなどを検討しているところです。今回、アジャイル手法でプロジェクトを運営していたことが、有効に働いていると思います。2024年9月のリリースまでに必要な機能を優先して、各チーム動いているところです。

真下：アジャイル手法の方が、ウォーターフォール手法と比べて融通が利くということでしょうか。

岡田：はい。リカバリーは比較的行いやすいと感じています。ウォーターフォール手法の場合、全ての計画を立案後、順次実行して行くため、今回のようにプロジェクト進行中に問題が発生した場合のリカバリーは、基本的にコストを追加するか、期限を延長するか、機能を削るといった選択肢になり、スケジュールやタスクの組み換えを行うことは非常に困難です。

駒形：なるほど。それでは、現在行われているスケジュールの再編成などは、アジャイル手法を採用していたからこそ可能だったということでしょうか。

岡田：はい。そのとおりです。アジャイル手法では、各チームを適切にコントロールしながら、ベンダーも含めてスケジュールを組むことができます。しかし、それぞれのチームが独立して動いており、横の連携は難しいと感じる部分はあり、アジャイル手法のメリットでもありデメリットでもあると実感しました。

駒形：横連携を適切にコントロールするために重要となる部分は何でしょうか。

岡田：チーム単位での課題管理やミーティングの場を適宜設けることでコミュニケーションを増やしていくことはもちろん、その上でスクラムマスターやPO（プロダクト・オーナー）も含めた関係各所間の横連携を強化し、アシスト社内の打ち合わせを増やすことで情報連携を密にしていきます。これにより、どこのチームがどのような課題を進めていくべきかを明確にすることが重要なのだと思います。

駒形：課題管理を行うために活用したツールはありますか。

岡田：チームによってはBacklogを使ったりしてたようですが、全体としては、特に課題管理専用のツールは使わずに、スプレッドシートで行いました。

沖： 当初はツールを使っていたのですが、思うように課題管理ができませんでした。更新が形骸化してしまい、チームごとの課題がうまく連携できなかったのです。

沖：現在、会議がとても増えています。やり方を模索しながらやっていることも原因の1つですが、何か良いやり方を考えないと、今後、行き詰ってしまう可能性があると懸念しています。

岡田：特にアシスト側では、プロジェクトのコアメンバーが複数のチームに参加しているため、プロジェクトのリソース的な問題があると感じています。

真下：現在のプロジェクト体制は、一般的に考えると人員は多いのでしょうか、少ないのでしょうか。

沖：プロジェクトの一員としては少ないと感じますが、一般的かどうかと言われるとわかりません。

岡田：コアメンバーは不足していると感じます。様々なタスクの実行や事項の決定を同じメンバーが複数のチームで行っている状況です。

真下：一般的にはプロジェクトのコアメンバーは、兼務はしていないかもしれないですね。

岡田：兼務しない方が適切だと思います。しかし、兼務していることで無理をしてでもキャッチアップできている部分はありますね。

真下：なるほど。NEXISプロジェクトに参画しているメンバーは、本プロジェクト専任ではないですよね。

沖：ほぼ専任の人と、兼任している人の両方がいます。

岡田：事務局と呼ばれているメンバーはほぼ専任です。システムチームは、既存システムの運用保守も行っているので専任ではありません。あとは現場のプロジェクトメンバーも兼任です。

沖：プロジェクトを進行していく中で、調査や棚卸しなどは、専任にする方が効率的だと感じました。

岡田：質問の内容からはそれてしまうかもしれませんが、この規模の全社プロジェクトになると、情報の粒度差をすごく感じます。多くの社員から「そもそもNEXISって何をしているのか全くわからない」とか、「今後、どう変わるのかわからない」という声をもらいます。プロジェクトのコアメンバーであれば当然理解していますが、それを全社員に浸透させることは、結構難しいことなのだと思います。

真下：全社員への周知はシステムの稼働直前に実施するので、まだプロジェクト進行中の現時点では、仕方がないことなのかなと思ったのですが違うのでしょうか。

岡田：稼働開始直前だと遅すぎますね。新しいシステムをいかに違和感なくリリースするか、ということはプロジェクト目標の1つです。どのようなシステムを入れるときでも同じだと思いますが、特に今回のような基幹システムとなると、数回の告知で全社員に理解してもらうのはとても難しいと思います。そのため、じわじわと浸透させて、理解を深めてもらう必要があると感じています。

真下：どれくらいの期間が必要になりそうだと考えていますか。

岡田：プロジェクトで社内周知方法を検討した結果、一部の社員に対して2024年5月頃から教育を開始しました。これに先立ち、2024年2月からは、社内向けにNEXISプロジェクトの取り組みを紹介するブログ配信を開始しました。各ブログごとにプロジェクトから社内に伝えしたいテーマを設定して情報発信することで、徐々に理解を深めてもらう活動を進めております。

駒形：現在構築中のSAPシステムを直接操作するのは、経理部門や業務改革センター（※3）など一部の人々に限られると認識しています。そのため、営業職や技術職の社員など、社員の大半は直接操作しないので、そこまで理解を深めなくても良いのではないでしょうか。

※3）アシストでは今回の基幹システムの刷新を機に全社最適の視点で組織の再編を行いバックオフィス部門を新設しました（2024年5月）

岡田：直接操作を行わなくても、業務内容が変わるため、理解をしてもらう必要があると考えています。

真下：業務改革センターに所属しない社員の業務も変わるのでしょうか。

岡田：はい。変わります。今回、業務の整流化を実施して、社内で重複して行っていた業務を単純化、かつどの役割でどの業務を実施するかということを明確にしました。営業部門と業務部門の方で重複して担っていた発注のような業務は業務改革センターに一本化されますし、請求処理業務などは範疇外となります。そのため、なぜ変更するのか、どこが変更するのか、を把握してもらう必要があります。理解を深めていただくためにも、新しい基幹システムの全容について全従業者に理解してもらう必要があると考えています。

真下：確かにそうですね。営業部門からすると、これまで行っていた業務範囲が狭まるという単純な話ではないのですね。

岡田：そのとおりです。そうなることによって業務内容や目標設定に変化が生じます。また、分析するためのレポートにも変更が発生すると想定しています。

沖：営業はこれまで、営業アシスタントに「これをやっておいて」と直接口頭で頼むだけで、注文書を受け取り、請求書を作成し、メーカー発注をするという一連の業務をスムーズに進めることができていました。しかし、今後は業務改革センターで業務を行うことになるため、受注したら「受注しました」という伝票を業務改革センターに出す、という業務が発生します。そのためスピード感が落ちるのではないかと懸念の声があがっています。システムを理解してもらえれば、これは避けられない事情なのだと理解してもらえると考えていますが、そうでなければ懸念が残り、システム変更に対する抵抗感につながる可能性があります。

駒形：そういえば、以前、見積もり作成する際には事前にマスターがなければ作れない、と説明いただきました。このような見積もりを作成する必要が生じた場合、マスターの作成依頼をした翌日でないとデータが反映されず、見積もりの提出が遅れ、その後の様々な処理に遅延を引き起こしてしまう、といった事象が発生する可能性があるということですね。

沖：そのとおりです。それらも含めてシステムを理解してもらわないといけません。

岡田：会社全体の業務量を考えると最適化が進むので、バックオフィスの処理量や人件費、工数といった部分は削減あるいは最適化されます。これを理解してもらうことが必要だと考えています。

真下：会社として正しい方向に進んでいるが、スピード感が少し遅くなってしまうデメリットが生じてしまう。これはある程度、仕方がないことなのだということがとてもよく理解できました。

沖：デメリットをどこまで許容するのか、そしてSLA（サービス品質保証）をどこに設定するのかということです。

駒形：たしかに工程を理解せず、突然変更部分だけを聞かされたら、遅くなるというところに焦点が当てられてしまい、抵抗感を示す人が出てくる可能性が高いですね。

岡田：何をやるにも根気強く説明する必要があります。そのため、早い段階から徐々に情報の差を埋めていくことが重要だと考えて取り組んでいます。アシストは1,000人規模の企業なので、全員に理解してもらうことは非常に難しいです。そのため、プロジェクトメンバーは多くのミーティングを重ね、頭を悩ませ、最適解を探していますが、そのプロセスはユーザーには見えません。「将来こうあると良いよね」とプロジェクトで検討した結果を理解してもらい、その効果を出していくことに協力してもらうためにも思考の転換が必要です。そのため、できるだけ早く説明を進めていくことが重要だと考えています。

沖：しかし、まだ情報を出せていないので、早く情報を出してほしいと催促されている状況です。

真下：とても大変だということが理解できました。2024年9月に間に合わせるためのリカバリープランを立てつつ、2024年5月には教育も開始するということで、まだまだ多忙な状況が続きますね。

真下：周辺システムやツール、サードパーティ製品の選定ポイントについて、また、アシスト取り扱い製品の採用状況について聞かせてください。まず、SAPにはConcurという精算システムがありますが、アシストがConcurを採用しなかった理由を教えてください。

沖：検討のタイミングと高価だったことが理由です。Concurを検討していた時期はまだSAPを導入する前です。当時、社内にはSAPに対する抵抗感がありました。

真下：それから時を経て、SAPを導入することが決まったタイミングでConcurの再検討は行わなかったのでしょうか。

沖：そのタイミングでは、費用がかさむことになるので再検討することは難しかったです。

岡田：現在進行中のSAP導入プロジェクトでは今後、社内のイニシャルコストと導入後の人件費の増加などが発生すると想定しているため検討はしませんが、これらが落ち着いたら再検討する可能性はゼロではありません。

真下： Concurは楽楽精算（現在利用中の精算システム）と同じ領域だと理解していますが、あっていますか。

沖：立替えと支払い処理の領域になります。精算システムは最近入れ替えたところなので、今のタイミングでConcurを再検討となると、またサービスが変わることになるので難しいですね。

真下：仮に再検討する場合、どのような効果が考えられますか。

沖：SAPのマスターとの連携に対する親和性が高いなどの理由が考えられます。

真下：なるほど。しかし、連携の仕組みを作ってしまえば十分対応できるのではないでしょうか。

岡田：連携の仕組みを作った場合、どちらかのシステムがバージョンアップなどで変更が発生すると、それに対する検証工数が発生します。仕様変更が原因で連携がうまくできなくなり、トラブルが発生する可能性もあります。このようにそれなりのメンテナンス工数が必要となるため、会社としてどこまでやるかの検討が必要です。

沖：まずは、現在の楽楽精算を使った構成で運用し、やはりConcurに変更する方が効果的だとなれば検討することもあり得ますが、特に問題が発生しなければ今のままでもよいと思います。

真下：現在、SAPのまわり（アシスト取り扱いのSAP周辺ツールの拡販を行うプロジェクト）では、SAP関連製品の販促活動を行っておりますが、アシストの取り扱い有無に関わらず、どのような観点でツール導入の判定をされているのかを教えてください。設計段階では「Signavio（業務プロセスのモデリングツール）」を使われたと聞いていますが、その他にどのようなツールやサービスを活用されたのでしょうか。

沖：アシスト取扱製品ですと機能テスト自動化ツールの「UFT One」です。

真下：UFT Oneを導入することは決定ですか。

岡田：2023年末までシステムチームが検証を行っていました。その結果、使用可能な領域は十分にあると判断し、その領域を見極めるために2024年1月に購入済みです。

真下：UFT Oneは既に別のシステムで導入済みですが、そこのライセンスを流用しないのですか。

沖：障害の切り分けなどが難しくなるので、ライセンスサーバーは分ける方が良いと判断しました。なお、UFT Oneは画面操作中心に利用します。データ入力などの操作が必要な場面のテストで利用することを考えています。

岡田：今回のプロジェクトでの業務テストは、ユーザー教育の一環で、実際に画面イメージに触れてもらい想定した業務フローどおり業務を処理できるか、という観点で人手でテストしてもらうことを計画しています。

駒形：なるほど。SAPへデータが投入された後、正しくデータが連携されているかというところは、システム化されている部分なのでツールを使ってなるべく省力化したテストを行い、画面周りが正しく動作することの確認や使い勝手に関する部分のテストは、ユーザーが実際に業務を行ってみながら自分の手でテストしてみてください、という使い分けですね。

岡田：そのとおりです。後者に関しては単純なテストというよりは、使ってもらうための教育も含めているので、使い分けをしています。

駒形：Stage0.5でも当然テストは実施されていたと思います。その時ではなく、なぜ今、テスト系のツールを検討されているのでしょうか。

岡田：当時はテスト項目がそこまで多くなかったことと、社内のリソースが足りなかったことが理由です。

駒形：社内のリソースが足りず、ツールを覚えてまでテストの自動化に取り組めなかったということでしょうか。

岡田：そうですね。リリースするためのスケジュールが優先だったのでどうしても対応できませんでした。

沖：ほとんど追加開発していないので標準機能だけだったのも理由の1つですね。

真下：システム規模、業務数や画面数などの観点では、Stage0.5（会計）とStage1.0（販売）でみると、Stage1.0の方が大きいのでしょうか？

沖：何倍も大きいです。Stage0.5では、FI（会計）モジュールの標準機能の部分とBlackLine（クラウド型決算業務支援サービス）との連携くらいしかありませんでしたが、Stage1.0はSalesforceで作り込む部分と、SalesforceとSAPの連携、BlackLineとの連携、楽楽精算との連携、と全てのシステム間の連携が必要になるので規模が大きくなります。

真下：複数のデータの流れができるので、システムテストの自動化が必要になるということですね。

沖：はい。障害時の分界点を把握しておかないと対応が困難になります。

岡田：テスト業務の工数削減をしていかないとプロジェクトが行き詰まる可能性も高くなります。

駒形：SalesforceとSAPのデータ連携はDataSpider（アシストが取り扱うデータ連携ツール）ですか。

沖：はい。アシストではデータ連携については全てDataSpiderで実装しています。

駒形：SalesforceとSAPは密連携せずに、DataSpiderを介しているとの理解であっていますか。

沖：はい。接続するためのAPIは提供されていますが、APIには制約があり、思うようにやりたいことが実現できない場合があります。そのため、Salesforceとのデータ連携は全てDataSpiderを介して接続する仕組みにしました。今回のSAPもDataSpiderを使っています。

駒形：アシスト以外のSAPユーザーはここまで徹底してデータ連携ツールを利用しているのでしょうか。API連携を多く活用している気がするのですが実情はどうでしょうか。

岡田：一般的にSAPを使っている他社はOData連携を最初に検討するのではないでしょうか。ODataはHTTPを使って連携するオープンなプロトコルで、SAP側でコネクションがあるのでAPI連携に近い感覚で利用しやすいと思います。

真下：ODataを使ったABAPを作成しデータ連携するイメージでしょうか。

岡田：はい。

真下：DataSpiderも考え方は同じですよね。

沖：はい。SAPだけに特定されるのではなく、いくつか連携先がある場合はDataSpiderを使った方が一元管理できると考えています。

真下：Qlik（アシストが取り扱うBIツール）のSAPアクセラレーター（SAP連携モジュール）は利用しないのでしょうか。

沖：データの見える化領域に関する検討はまだ先です。まずはシステムが安定して稼働することが先決です。

真下：では、当面の間の情報活用は現行のVertica（DWH専用データベース）を使った仕組みを継続して利用するということですね。

沖：最終決定はしていませんが、基本方針はそのとおりです。 Snowflake（クラウドネイティブのデータプラットフォーム）をどうするかというところを検討したいのですが、まだプロジェクトが進行中なので新しいツールを使った検討はできないというのが現状です。

駒形：Verticaは老朽化してきたのでRedshift（クラウド型DWH専用データベース）を利用しようという話題はありますか。

沖：はい、Verticaのサーバーは現在、データセンターに設置しているオンプレミス環境なので、クラウド化の検討が必要だという話題はあります。

真下：アシストがデータ活用系で利用しているサーバーは、全部オンプレミス環境なのでしょうか。

沖：QlikはOracle Cloud Infurastructure（OCI）上に導入しています。WebFOCUS（エンタープライズレポーティングツール）とVerticaはサーバーをデータセンターに設置しているのでオンプレ環境ですね。

駒形：今後、これらの情報系システムも変わっていくことになりそうですね。

沖：はい。今後、将来的なことを考えるとSnowflakeを中心にしていくことになるのではないかと予測しています。

岡田：プロジェクトとしてもNEXISのリリース後、社内の業務効率化のためのデータ連携とお客様向けのSalesforceを軸にした仕組みの拡充などを企画フェーズから開始する予定です。

真下：アシストがクラウドネイティブの会社になるのももうすぐですね。

沖：そうですね。知らぬ間に切り替わっていますね。セキュリティ面でもゼロトラストの環境が2025年に完成予定なので、そうなるとZscaler（クラウド型セキュリティサービス）をベースとする仕組みに変更になりますしね。

駒形：周辺ツールを選定される中でここだけは外せない、というポイントはありましたか。

沖：絶対外せないという観点があったというよりも必要に応じて選んだものが多いです。BlackLineやEnable Now（eラーニング、ユーザードキュメント、アプリケーションヘルプなどを作成できるツール）はまさにそうですね。

駒形：やはり、SAP系の製品の方が良いのでしょうか。

沖：ものによると思います。BlackLineは、業務に密接に関連してくるのでSAP系の製品の方が良いのではないか、と考えています。業務フローはSignavioを利用していますが、SAPに買収される前から利用しているのでSAP系にこだわっているわけではありません。

真下：よく理解できました。複数回にわたり、色々とお聞かせいただきありがとうございました。