子会社データホライゾン会計システム導入PJの紹介

はじめに

こんにちは、DeNA IT本部IT戦略部コーポレートオペレーショングループの小瀧です。今回、私が過去にPMとして携わりましたDeNAの子会社であるデータホライゾン（DH）の会計システムを移行したプロジェクトを紹介させて頂きます。企業のシステム統合に携わっている方や、非IT部門との連携に課題を感じている方にとって、きっと役立つ内容になっていると思います。

プロジェクトの概要と背景

本プロジェクトは2023年3月に開始され、2024年10月に完了しました。DHの会計年度が7月に始まるため、2024年7月には新しい会計システムでの本運用が開始されました。

DHの会計システムを切り替える主な背景には、以下の2点があります。

DHの既存会計システムの保守期限が迫っており、新バージョンへの更新か他システムへの移行を検討する必要があったこと。
DeNAの子会社であるDeSCが既にDeNAの会計システムを使用しており、DHも同じシステムを導入することでDHグループ全体の管理業務の効率化が期待されたこと。

私はプロジェクトのPMを担当しつつ、財務会計システム、作業時間集計システム、原価計算システムの移行担当でもありました。固定資産管理システムは同グループの別の担当者が、管理会計システムは経営管理部管理会計グループリーダーが担当しました。

苦労したこと

プロジェクトでは、以下の取り組みが行われました。

WBSの作成と計画策定
移管対象システムのスコープ定義
現行運用（AsIs）の整理と移行に伴う課題の明確化
DH専用機能の開発
検証環境の準備
DHの検証サポート
マスタ等、本番環境設定
既存システムから移行先システムへのデータ移行のサポート

プロジェクトを進める上で、特に以下の点で苦労したのでご紹介します。

1. プロジェクト組成期間を設けずにプロジェクトが開始されていたこと

本プロジェクトはDHの会計システム導入を目的とした経理領域のプロジェクトであり、経理領域以外にも広報・IR、HR、セキュリティ、内部統制・監査と複数の分科会に分かれておりました。全体に対するPMI体制図は引かれておりましたが、各分科会の領域単位で更に細かい体制図や役割分担までは明確になっていない状態でした。私が経理領域分科会(会計システム導入PJ)にアサインされたのはキックオフも済んでおり、何回か定例が実施された後でした。プロジェクトを推進する担当(PM)が不在で、上手く進んでいないためPMとして入ってほしい。という背景でアサインして頂きました。定例にはDH/本社経理担当がメンバーとしてアサインされておりましたが、現行業務に対してどこまでをシステム移行のスコープとするか等の調整はされておらず、プロジェクトを進めながら実現可能な範囲のスコープを定義していくことになりました。 DHは子会社のDPPヘルスパートナーズ、ブリッジも抱えており、3社それぞれのスコープをシステム単位、さらには機能単位で定義する必要がありました。

例えば、財務会計領域の移行先システムのNetSuiteは稟議、発注、債務、債権と機能が分かれており、当初は3社すべてが全機能を利用する要望を頂いておりました。しかし、稟議機能を使用するためには稟議規定をDeNAに合わせるために作り直す必要があったりすることが分かったため、結果として3社のうち2社のみがNetSuiteを利用し、稟議・発注機能は使用しないことになりました。

スコープの定義をしつつ会計システム導入・本運用開始までの全体計画の策定をプロジェクト開始後に実施しました。

2. 普段気にしていなかった運用の背景やシステムの細部に渡った仕様に対する理解不足

DHの現運用（AsIs）に対してシステム移行後のTobeを理解してもらうためには、DeNAシステムの仕様と運用について細部に渡って理解している必要がありました。例えば、原価計算システムを移行する場合、原価計算の詳細な仕様や運用を理解していなければ、DH経理担当への説明やAsIsとTobeの比較・課題の整理を正確に実施するのが難しくなります。DHへの説明をしていく中で「このときはどうなるか」「なんでそうなっているのか」と質問を頂いて、自分の中で確かに、そのときはどうなるのだろう。なんでそのような仕様・運用なのか。と思うときが多々あり、自分自身にとっても仕様や背景を更に理解する機会にもなりました。

3. 原価計算システムの移行について

DeNAの原価計算はROME Portalというスクラッチで開発したシステム内の1機能として存在します。原価計算は会社単位で独自の計算ロジックがあるため、DeNAとDHでも原価計算の計算方法の違いが課題となりました。内容をよく紐解き、DHの運用変更のみでは踏襲できない課題に対して専用の開発・改修を実施して解決しました。

共通費配賦の扱いの違い: DeNAでは原価計算実施後の管理会計処理の一次配賦で消耗品や経費などの共通費を配賦しています。しかし、DHでは管理会計処理の前の財務会計の原価計算でこれを実施していました。この課題に対応するため、DH専用に原価計算の改修を行い、DHの場合は共通費配賦を原価計算で同様に実施できるようにしました。
会計部門の粒度の違い: DeNAの部門は人事部門と会計部門で管理が分かれてます。原価計算含めた会計業務は会計部門で管理しております。DeNAの会計部門は「会計部門コード（1）：人事部門コード（1）」で管理されているのに対し、DHの会計部門は「会計部門コード（1）：人事部門コード（N）」の粒度で集計されていました。この課題を解消するため、既存の会計部門に対して配賦元部門を集約するためにDH専用のマッピング機能を開発しました。
社員コスト(給与仕訳)の仕訳算出方法の違い: DeNAでは社員コストの仕訳を部門単位で算出・投入していましたが、DHでは管理職の間接プロジェクト工数を算出し、その分の管理職コストを配下の部門に含めて計算した結果の仕訳を元に原価計算で配賦していました。この課題を解消するためにDH専用の「給与仕訳作成機能」を開発し、移行前と同等の社員コストの仕訳を作成させることができるようになりました。

これらの対応により、DHの既存の原価計算結果と移行後の原価計算結果の差異を許容範囲内に抑えることができました。

プロジェクト成功のために心がけていたこと

最終的にはスケジュール通り会計システムを移行して本運用を開始することが出来ました。最後にプロジェクトを成功させるために心がけていたことを2点紹介します。

1つ目：自身の成果を求めることよりもDHの方々を助ける・力になりたい一心と人情で対応をしていたことです。DHの経理部門の方々は自分たちの会計システムを移行させるために本気で取り組んでいることが行動や表情からとてもよく伝わっていました。また、DH経理、本社経理を含むプロジェクトメンバー全員がどんな依頼に対しても協力して頂き、些細なことでも困った時には私を信頼して助けを求めてくれたからこそ、私自身「DHのためにも何が何でも成功させてやる。絶対に諦めない。」という強い気持ちで最後まで対応することができました。
2つ目：週次の定例会議では、順調なことよりも、うまくいっていないことや困っていることを優先して報告してもらうことです。PMとして問題やトラブルは自分事として捉え、プロジェクトメンバー間で協力を仰ぎながら、解決するまで対応を繰り返すことで障壁を全て取り除いたことで移行先システムで本運用を開始させることが出来たと思ってます。

このプロジェクトの経験を活かして

このブログの執筆準備と平行して今度は子会社アルムの会計システム導入プロジェクトのPMを担当させて頂くことになり、プロジェクトキックオフ前のプロジェクト組成対応を進めています。今回のプロジェクト経験から、本格的なキックオフの前に「プロジェクト組成期間」を設け、準備を十分に行うことの重要性を学びました。プロジェクトの目的・目標の明確化、スケジュール策定のためのスコープ・方針の定義、体制・役割・責任範囲の明確化、コミュニケーション計画の策定。プロジェクト組成期間は、その後の成否を大きく左右する非常に重要なフェーズです。プロジェクトを成功に導くために、主要なポイントを抑えて事前に調整・確認・整理してからキックオフをスムーズに迎えたいと思います。