営業担当者主導で基幹システム刷新プロジェクト、社内巻き込み業務DXを推進

　トップダウンで始まった基幹システム刷新プロジェクトのメンバーは、2018年にIT戦略推進プロジェクト室へ集められました。初期メンバーは、営業部門から1人、管理部門から1人、情報システム部門から1人の3人でのスタートでした。 選ばれた理由について橋本氏は、「営業担当として日々、基幹システムにアクセスし、情報を入力したり参照したりしていた。他部署より基幹システムを使いこなしていたからこそ、知見を活かせると上層部が指名したのではないか」と、自身がメンバーになった経緯を振り返ります。 　そもそも、刷新した基幹システムはどんな役割を担うのか。商空間のプロデュースを主事業とする同社の場合、全国で案件が動いています。ゼネコン業務と違い、比較的工期の短い内装や設備工事が主体です。さらに案件は工事と契約が複数に分かれ、複数の入金先が存在する場合もあります。これらの情報を案件ごとに一元管理し、案件情報や取引先情報を取り扱う管理システムになります。 　これまでの基幹システムはさまざまな問題を抱えていました。1つは、パッケージの機能が業務に合わない点。「旧システムは市販のパッケージをベースにしていた。標準的な機能を備える半面、当社の業務に馴染まない機能も少なくなかった。使いにくいといった声もあり、案件情報をきちんと入力しない従業員もいた。主事業のデータを収集、一元化し、システムにため込んだ情報を価値あるものとして活用できる仕組みが求められていた 」（橋本氏）といいます。

　さらに、人事や会計など部門が独自にシステムを導入していたため、基幹システムと連携するには手入力が一部で必要でした。無駄な項目が多く、基幹システムにデータを入力してもその情報が活かされないという問題も顕在化していました。管理部が確認・承認した申請書をシステムに手入力するといった重複作業も散見され、基幹システムを刷新することが喫緊の課題となっていました。 　これらの問題点の背景の一部には、旧基幹システムの内部統制強化を優先して設計したことが考えられます。 「旧基幹システムの導入は2009年。当時は内部統制の強化が世間的に叫ばれていた。そのための機能を拡充し、監査や押印などの手間がかかる機能も含まれていた。こうした点を見直す必要もあった」（橋本氏）といいます。

　刷新プロジェクトは2018年1月にスタートしました。実際に旧基幹システムの問題点を聞いても、経費精算システムだけリニューアルすれば、APIあるいはCSVで手入力部分を取り込めたのではないか。なぜシステム自体を刷新する必要があったのかという素朴な疑問がわきます。この点について橋本氏は、「私自身、旧基幹システムを使用する上で何ら不満はなかった。しかし2018年に刷新プロジェクトをスタートさせた際、現行アセスメントとして大規模なアンケートを実施したところ、案件情報の入力について改善を求める社員が多いことが分かった」と経緯を振り返ります。

　この現行アセスメントは営業の繁忙期である2月から4月くらいまで実施。大変時間のかかる大掛かりなものだったといいます。「まずは会社にあるシステムというシステムを調べ、どう連携しているのか、どう繋がっているのかを洗い出した。刷新が必要なのかも含めて全社員にアンケートを取ったり、本部長や営業の一般社員の中から抜粋して百数十人くらいヒアリングしたりした。その結果、私が刷新の必要性に懐疑的だったのは、会社を知らなかったからだと判明した」（橋本氏）といいます。「振り返ると、徹底した現行アセスメントをしていなかったら、結果として刷新までもっと時間がかかっていたかもしれない」（原田氏）と振り返ります。 　システムを刷新するにあたり、市販のパッケージを使わずスクラッチで開発した点も特徴的です。標準的な機能を網羅するSaaSを選択するケースが増える中、スクラッチ開発を選択した点について橋本氏は、「刷新前のパッケージは当社の業務に馴染まないところが一部にあった。そのため、新たにパッケージを導入しても当社の業務フローと乖離するのではと考えていた」と指摘します。原田氏も、「パッケージを当然検討した。しかし業種の特性により、パッケージがなじまない領域もある。いろいろなERPを検討したが、どうしてもシステムに合わせなければいけないという問題点を解消するため、自分たちの業務フローにシステムを合わせられるスクラッチが最適と判断した。必要な部分だけを残し不要な部分は徹底してそぎ落とす、割り切ったシステムを開発できるメリットを優先した」といいます。 　新システムでは、ジョブ管理システムと呼ぶシステムを新たに用意しました。これは案件情報を取り扱う同社事業の中枢となる基幹システムを組み込んだもの。さらに、勤怠・経費、人事・会計、経営管理はSaaSを利用し、API連携やファイル連携で繋げています。「スクラッチでいろいろな機能をすべて作るのは望ましくない。中枢となる基幹システムの開発は最小限にとどめた。機能を膨らませば膨らますほど、トラブルが発生したときの影響範囲を特定しにくくなるなどの理由からだ。経費管理、人事・会計、勤怠・経費などの機能はSaaSを使えばよいと考えた。今後の業務拡大、新たなデータ連携も想定し、外部のクラウドやシステムと連携する柔軟性にも配慮した」（原田氏）と、新システムのメリットを説明します。 　この新システムの開発期間は2年 。ベンダーとの良好な関係を重視し、課題管理ツールを元に1万5000以上のタスクを終わらせてから稼働に至りました。「アンケートを元に要件定義と機能一覧に取り組んだところ、機能は1000で収まらなかった」（原田氏）と話すように、膨大な作業量のため、開発にはかなりの時間がかかり、最終的には2020年7月に本稼働となりました。 　実際のテスト期間は半年、その後修正に3カ月かかりました。2019年10月ごろから12月ごろまで修正しながらテストにこぎつけ、2020年1月もテストしつつ、2月～3月には一部社員の間で並行稼働させ、4月から6月にかけて不具合を修正し終えて7月からの稼働を迎えたのです。社員への説明会実施のタイミングで緊急事態宣言が発出されたため、新システムのマニュアルと動画を配布することで凌ぐことになりました。

　新システムで、基幹システムを組み込んだジョブ管理システムに用いるのはAmazon Web Services（AWS）。Microsoft Azureと比較し、費用・柔軟性・拡張性を考慮した結果、AWSを採用しました。新システムはスクラッチで作り上げたシステムと、パッケージシステムを自動連携させています。スペース社内で重視されているのは、現時点で当該案件の利益がどれくらい出ているのか。勤怠や社員が動いた工数などの経費精算は毎日行われる性質上、ジョブ管理システムにアクセスしたら誰でも利益をチェックできるよう、経費は1時間に1回、勤怠は30分に1回の頻度で自動連携しています。 　業務フローに必要な項目のみ入力するよう絞り込まれた新システムと、旧システムを使いジョブに対する実測テストをした結果、削減効果は次のようになりました。トータルで換算すると、作業工数は22％削減しています。
・営業部門の登録申請：書類出力不要、ワークフローが簡略されたため作業工数42％削減
・管理部門の承認：書類出力を管理部に移管したことなどを受け、作業工数66％ 増加 　経費については、トータルで47％の削減効果が出ています。
・営業部門の登録申請：交通費検索機能等により作業工数42％削減
・管理部門の承認：精算登録の簡略化により作業工数74％削減 　「経営層や刷新プロジェクトメンバーは、この削減効果について満足している。今後5年間で得られるROI（投資効果）についても話しているところ。何より大切なのは、作って終わりではないということ。カットオーバー以降の改善に取り組むことが大事だ。システムをどう使いこなすか、情報の活用方法について説明を重ね、社内で議論していく取り組みが必要だと考える」（橋本氏）と指摘します。 　原田氏も同じ考えです。「社員の問題意識はとても高い。どんどん使いこなしてもらい、使いにくい点をヒアリングして、自分たちの 本当の価値を生み出せる形へとシステムを変えていくことが重要だ。部分的に見れば刷新の効果は削減率にあらわれているが、削減率の見える化が、基幹システム刷新の目的ではない。業務プロセスを改善し効率化を図る にはどうすればいいのか、さらに効率化によって空いたリソースを使うか、当社のクライアントとどう共有するかなど模索しなければならない点は多々ある。社内で新たな着想を支援する体制を構築することが、目指すべき刷新の目的と考える」（原田氏）といいます。