【株式会社エムティーアイ様②】リプレイスプロジェクトの進行
株式会社エムティーアイ（東証第一部上場：9438）様は「ルナルナ」や「music.jp」などを扱う、コンテンツ配信事業として多くの有料会員数を誇る企業です。今回は全3回のうち第2弾となる、業績管理システムリプレイスプロジェクト（2018年/4月～）の進行事例を公開します
プロジェクト全体の目的とアプローチについて
システムリプレイスを実施するにあたり、プロジェクトの目的は「現行システムで提供される予算管理業務の実現」としました。
というのも、以前導入した業績管理システムプロジェクトのように、弊社側の要望を盛り込みすぎて、システムのバージョンアップに対応できないことやシステムのパフォーマンスやメンテナンスコストの増加とならないようまずは現行の機能維持が大切だ、との社内での検討結果からそのようなプロジェクト目的といたしました。
ただし、現状発生している業務の非効率箇所については都度プロジェクト内で議論の後、パフォーマンスや構築スケジュールに影響がないものなどを取捨選択し、新システムに適用していきました。
またプロジェクトアプローチについては、デルタウィンコンサルティング社（以下、DWC）と相談のうえ2つの方針をとりました。
1つ目はプロジェクトの構成を、「現行調査フェーズ」「要件定義フェーズ」「構築フェーズ」とし、要件定義前に作りこみとなっている実態を明らかにするため現行調査フェーズを設定しました。
2つ目はプロトタイプアプローチをとり、要件定義フェーズや構築フェーズにて要件を反映したプロトタイプを作り両社で検証することでお互いに空中戦にならず、かつ構築フェーズの後半になってイメージと違う、などとならないようリスクを排除する工夫を行いました。
現行調査フェーズについて
まず現行調査フェーズの目的ですが、要件前提の確認と要件自体の整理、としました。というのも、要件定義フェーズで要件を議論し、「これからどうしていくか」を話す前に、現状がどうなっているか当社とDWCが共通して理解する必要がありました。
その理由としましては、以下の3点が挙げられます。
【１】
管理会計は各社一見同じことをやっていても細かなレベルでは違いがありその詳細を共通認識としておくことがスムーズなリプレイスを進めるうえで大事だと認識していたこと。
【２】
現行の業績管理システム導入時から私が昨年担当になるまでに長い年月が経過しており、暫定対応と恒久対応を繰り返していたため、両者のシステム的な齟齬などが発生していないかリプレイスにあたり確認したかったこと。
【３】
システム運用の一部を外注している経緯もありリプレイスプロジェクトの全体や細部を把握する必要があったこと。
現行調査フェーズを終えた後の感想ですが、個人的には本フェーズをやってよかったと思っております。
逆にこのフェーズをやっていなければ、構築フェーズになっても、想定外の事象が発生し、ある意味要件定義が後続していた危険があったと思います。
そういう意味では、当社にとって現行調査フェーズは「地雷除去」フェーズとなったと思います。
リプレイスを急がれている方ほど、現行調査は実施することをお薦めします。
要件定義フェーズについて
要件定義フェーズの立ち位置は一言でいうと、「現状を踏まえたうえで、じゃあこれからどうしましょうか」
というフェーズだと思っています。要件定義フェーズで良かったことが2点あります。
DWCから既存の業績管理システムに詳しい方をプロジェクトにアサイン頂いたこと
一つ目は現行調査もそうですがDWCから既存の業績管理システムに詳しい方をプロジェクトにアサイン頂いたことです。そこで、既存システムと新業績管理システムであるAdaptiveとの両システムを知る方とFit&Gapの精査を行えたことで、こちらが「本当にそうか？」といちいち既存システムの検証や新システムの確認に大量の時間を費やさず論点の整理ができたと思っております。
現行業務の負の解消をセッションできたこと
また2点目はプロジェクトの目的の箇所でお伝えした現行業務の負の解消をセッションできたことです。
具体的にいいますと、業務上必要な対応として管理会計上の本社費配賦や実績データの仕訳一覧の各部への展開、KPI指標の多軸分析等をこれまで既存システムの外で行っていましたが、両社で協議し新システムへの移行が可能だと判断し、構築フェーズへ反映いたしました。
構築フェーズについて
構築フェーズは要件定義で決めた内容をひたすら作ることです。
やってみて思ったことは、プロトタイプアプローチでゴールとなるPLやそれに連携するサブシートなどを作っていたため大枠は把握していましたがデータ移行やアウトプット要件の整理をしているうちにやはり細かな要件整理が必要な論点が発生し、想定よりも少し工数がかかったかな、という印象を持ちました。
ただし、DWCが要件定義フェーズの方針にある意味“逃げず”に、構築フェーズで発生した論点の議論にとことん付き合って頂いたおかけで構築フェーズ後の試験運用や現場へのトレーニングで大きな想定外の事象など発生せずにシステムリリースが出来たと思っております。
逆にいうと、プロトタイプアプローチでふんわりしたままシステムリリースしていたら、後続の要件整理事項が次々と発生していた気がします。
リプレイスプロジェクト終了後、全体を通して
リプレイスプロジェクトを終えた今思うことは、Adaptiveという製品の良さへの実感とそれを導入する会社（DWC）の重要性についてです。
Adaptiveという製品の良さへの実感
まず1点目のAdaptiveへの製品の良さについて。既存システムはシステムといえど、Excelにアドインする形の入力画面設計にしていたためリプレイスにあたり、ExcelからAdaptiveの画面への移行がハードルがあるかと懸念していましたが、現場展開がスムーズだったばかりか積み上げ処理（※事例第一弾を参照）など無くリアルタイムに集計される仕様となり評判が上々です。
またメンテナスする側の意見としてはシステムにアドオンなどせず、すべて標準機能で設計したことにより、製品選定時の基準であるメンテナンスの属人化を防げる仕様に出来たと自負しております。
導入支援をする会社の重要性
次に2点目のシステムを導入する会社についてですが、一言でいうと、「当社の要件を理解し、実行に移せるか否か」がとても重要だと思いました。というのも、私個人としては国内で探せる管理会計製品はほぼ調べ、その製品を扱う各社との面談実施後、ある程度の絞り込みを経てRFIへの各社プレゼンを実施しました。
そこには、基幹システムや会計システムに詳しいベンダー、元コンサルティングファーム出身者や自社開発の製品を扱うベンダーなど様々でしたが、当社の特性である「組織変更が頻繁に発生する」「社内間取引が最下層度組織同士で発生する」などの要件を想定した提案や役員プレゼンを実施してくれる会社は本当に少なく、実際に役員プレゼンの評価でもDWCの提案内容が唯一、本当に当社の管理会計を高めるプレゼンだったとコメントがあったくらいです。
プロジェクト運営にあたり担当者として工夫したこと
リプレイスプロジェクトの主担当として工夫したのは、既存システムと新システムで運営上Gapがでそうな論点が発生した場合には各業務のキーマンとすぐに要件を議論し、システムへの適用方針を立てたことです。
私自身、業績管理システムの担当にあたる前は、実際に入力者側におりました。そこで、ユーザ側として想定される視点、また現在の経営企画としての視点の両観点で議論に望むことで、結果的に安定したシステムリリースにつなげられたと思います。
プロジェクトで苦労したことと、それに対する対応策
苦労した点は既存システムにしか無い機能要件の新システムへの適用や運用の検討です。
当たり前ですがリプレイスでは2製品が全く同じ仕様では無いため業務上クリティカルなところなどを優先的に検討し、新システムでの運用要件を決めました。
対応策として実施した事は、以下の2点です。
1つ目は「現場への影響度を計るため、必要な時にプロジェクトに現場の人間を入れ議論した」こと。
2つ目は「運用が大きく変わり、インパクトが大きそうな内容に関してはプロジェクト関係者やオーナーへの報告を丁寧に都度行っていた」ことです。
これから業績管理システム導入を行う読者の方へメッセージ
もし自身がもう一度製品選定を行うとしたら、RFIを各社に提出する前に「どんな管理会計を行いたいか」
を社内でとことん議論すると思います。
正直、いろいろな会社の管理会計製品を見ましたが予算のデータを収集するだけ、分析するだけでしたら少機能で安価なツールでも事足りるわけです。
各会社が様々な角度で提案してくる中、判断にブレないためには今後会社として行いたい管理会計の内容を定義し、それに照らし合わせる必要があります。
今回はリプレイスプロジェクトでしたので、既存システムには無い特徴を持つ製品などがあった場合には検証や検討が少し手間取りましたが、最終的には自社の管理会計ビジョンとの整合性に注視し、検討することで社内関係者への合意形成がスムーズに行けたと思います。
ちなみに、もう一度やり直したとしてもやはりAdaptiveとDWCを選ぶと思います。
特に今回のプロジェクトで、Adaptiveのファンになりました。
※次回は第3弾として、システムリプレイス後一定期間を置いた後、の影響や経営への効果についてインタビューを予定しております。
