複数のアプリケーションをまとめて、強固かつ機能的な統合システムの構築を～キュービックの考えるERPを中心としたDX戦略-DX担当者のための勉強会- 経革広場

多くの企業では現在、人が担ってきた作業をシステム化することを期待されて、数多くの業務アプリケーションを導入した結果、そのシステムが独立した状態で存在していたり、システム同士を人が連携させたりするといったことが起きています。そこで、勤怠管理や顧客管理、請求書発行など、あらゆる企業活動に対応した機能を有するERP（Enterprise Resource Planning：統合基幹業務システム）に従来から注目が集まっていました。

今回は株式会社CUEBiC（キュービック、以下キュービック）の後藤康成氏と管智彰氏をお招きして、ERPを中心に据えた、キュービックのDX戦略についてお伺いしました。

社内DXを強力に推進するキュービックの体制

後藤氏：キュービックは2006年に設立され、社員が今178名、インターンと業務委託さんを入れると400名近い人員構成の企業です。140名ぐらいいるインターンと一緒に事業を作っていく会社の形態をとっているのが特徴です。エンジニアリングチームは、年齢構成からしても割とバランスの良い構成になっているチームです。職種の内訳はDXエンジニア、DXスペシャリストで20%ぐらい、他にアプリケーションエンジニア、SREと言われているサーバーサイド系のエンジニアを擁しています。

社内組織はメディア開発、プロダクト開発、サーバー系を中心に担うSRE、コーポレートIT、DX戦略というチームの5つに分かれています。DX戦略チームはより本格的に社内のDXに取り組もうと2022年の10月に立ち上げられたチームで、ERPの保守運用を中心とした役割を担いつつDXツールの開発運用、SaaS系の導入支援、社内の基幹システムを使ったメディアのトラフィックや売上高の成果収集といったところも行っています。

DXの計画導入は2021年から導入を進めています。昨年までにDXの推進運用あたりの骨格がしっかりとできてまいりました。2023年に関しては、グループ企業を含めた形でのDXの推進運用ということで、DX戦略に則って効果的なコスト削減や生産性の向上といったところを目標に、社内のDXを本格的に進めていってます。

–多分採用のポジションにも関連するかなと思うんですけども、キュービックさんにおけるDXスペシャリストとDXエンジニアの違いって何でしょうか。

管氏：基本的には、エンジニアリングを伴う業務を担当するメンバーと、企画・要件定義や業務プロセスの設計等、直接エンジニアリングが伴わない業務を担うメンバーでポジションを分けています。しかし、将来的にはそうした境目はなくなっていくと思っています。

半分野良状態のSaaSと、同期も統制も取れてないマスターデータばかりだったERP導入前

管氏：はじめに断っておきますが、私自身はERPの専門家ではありません。10年以上ERPから離れていました。そのうえで、いくつか言い訳をさせてください。

まず、ERPはすごく高価なERPのソフトウェアを買ったり、すごく高価なコンサルティングをお願いしたりしなくても、ある程度簡単に、安価に実現できるかもしれません。もちろん全てのERPに分類されるようなソフトウェアを咎める意図はございません。、時と場合によっては、すべての機能が一気通貫で用意されているERP的なソフトウェアを導入することが、いまもなお強力なソリューションになることがあると思っています。ただ現代において、あらゆる状況・あらゆる企業でERPを導入することがベストであるとは言い切れないのもまた事実です。

スタートアップの会社ならあるあるだと思うんですけれども、ERP導入前は、あるSaaSだと登録されているマスタ情報が別のSaaSだと登録されていなかったり、異なる情報が登録されていたりな、無秩序に導入された業務アプリケーションで各種マスターデータが同期・統制が取れていない状態で、導入したSaaSを横断して何かを分析するのが困難な状況でした。

こうした課題を解決するべく、2021年にCUEBiCではERPの導入を以下の計画でスタートしました。SaaSで担っていたアプリケーションをERPに集約すると同時に、組織や従業員、取引先等々各種マスターデータも集中管理するようにしました。ERP機能を持たないいくつかの機能については引き続きSaaSを利用し、マスターデータを自動で連携できる仕組みの構築を考えていました。

一方、ERPの維持にかかるコストはかなり高額です。最近だと比較的安価なものやオープンソースみたいなものがありますが、一般的にはそのようなプロダクトではなく高額なライセンス料、保守運用にもそれなりの人手がかかるERPを使うケースがほとんどです。こうした製品は、用途によっては、支払う金額の割に合っているとは言えないかと思います。。

利用部門の皆さんにしてみたら、正直、ERPって使いづらいですよね。業務アプリケーションとしてERPを使っている方にとっては、使いやすい・見やすい・分かりやすい最近のSaaSに慣れているかと思います。また、ERPの保守運用の担当者は、こうした業務でモチベーションを維持することは困難です。

つまるところ、マスターデータがちゃんと管理されてること、これを軸にしてさまざまな社内の活動がデータとして可視化されて経営判断の材料にできること、ついでにいろんな業務アプリケーションをちゃんと使えれば、それでいいのではないか。

具体的には、上記の図のように計画しました。バックオフィス系の業務アプリケーションは全部、サポートが充実していて、使いやすい市販のSaaSを利用します。データはiPaaSやETLで連携させます。

そのうえで（1）マスターデータは集中管理させさまざまな業務アプリケーションと常に同期。（2）重要な経営指標は、上の各種サービスからさまざまなデータを吸い上げて加工・表現。（3）コストを掛けるまでもないけど必要なアプリケーションや、オリジナリティの強いアプリケーションは内製で開発。（1）～（3）までをローコードのWebアプリケーション開発ツールで構築するという仕組みにしました。高額なERPは一旦排除して、ERP単独で具現化しようとしていたことをSaaS＋ETL＋ローコード開発ツールという組み合わせで実現しようと計画を立てている真っ最中です。

こうしたの計画を実現することで、いくつかのメリットが生まれます。まず、現在の我々のERPの年間の維持コストは楽観的に見積もった場合2割程度になる見込みです。

実際にERPを利用される皆さんにとっては、市販のSaaSだとカスタマーサクセスも親切丁寧で、習得も早く、利用開始までの期間を圧倒的に短縮できます。

一方で、システム部門のマネージャーの皆さんにとっては、自分たちで課題を吸い上げてサクサク解決していくという仕事にあたれるほうが、メンバーのモチベーションを維持できるんじゃないかなと。

キュービックの目指すERP（的なもの）の構成は、ガートナーさんから2019年ごろ発表されていた「ポストモダンERP」という考えにとても近いものと捉えることができます。。「ポストモダンERP」とは、ERPを利用しながら不足した機能は外部サービスを組み合わせるというものですが、わたしたちがやろうとしていることは、それをさらに極端にしたものといえるかもしれません。

DXを推進する、社内メンバーのモチベーション維持のために

–複数のSaaSを組み合わせることで、ERP的な機能を実現していこうとするところが肝かなと思ったんですけども、キュービックさんとしてSaaSを選ぶ判断軸があれば教えていただきたいです。

管氏：APIの有無が大きな判断軸の一つになります。ユーザー、従業員、マスター、組織の登録みたいなものが各SaaSありますけど、先ほどのマスターデータを中心にした各SaaSに対してAPIとの連携を行っているので、マスターを変更するだけでアカウントの管理を各SaaSが自動的にできるようになります。組織変更があると結構大変なんですよね。SaaS群もそれに対応しなきゃいけなくて。これまで各担当部門がCSVファイルをアップロードして整えていたんですが、APIを通じて自動的にアップデートや組織変更にも自動対応が可能です。この実現により、工数削減、担当部門の負担を少なくすることを期待しています。

–SaaSが独立した状態で存在しているのは、正直Excelで管理してるのとそこまで業務のインパクトって変わらないので、確かにSaaSの組み合わせはすごく重要なポイントですよね。あとERP的なもの、キュービックさんの構成でいくと、IT部門のモチベーションの維持が結構面白いなって思いました。モチベーションの維持って、具体的にはどんなことを考えておられるのでしょうか。

管氏：ローコードの開発ツールを使ってERP的なものを実現すること、小粒な業務アプリケーションで目の前の問題をサクサクと解決していくといったところが、モチベーションの源泉にできるのではと感じています。古い話で大変恐縮ですけど、10年以上前にわたしがERPを担当していた頃は、会計だとか購買、在庫管理、物流といったさまざまなビジネスの機能を担うことが、社内システム担当者の花形というか、モチベーションの源泉になっていました。

キュービックにおいては、現時点ではそうした機能が必要ないため、ERPの保守運用や改善に担当者を縛ることよりもモチベーションの維持がしやすいんじゃないかなと考えています。

実はこれ、まだプロジェクトを始めておらず、これからまさに始めようとしているところです。。例えば先ほどの小粒なアプリケーション開発の場合、昔から起きていたとおりExcelマクロ、Lotus Notesだったり、最近ならkintoneで作ったアプリなど、アプリ開発の民主化と統制をどうすべきなのかなど、これから対処すべき課題はたくさんあると思います。