基幹システムのリプレースをした話 #1

最近当社では基幹システムをリプレースした。

大枠としては
これまではZacというクラウドERPシステムを利用していたが、
今年の8月より（主に会計システムで有名な）freeeのプロダクトを幾つか同時導入し、
・Zacで対応していたことをカバー
・Zacで対応しきれていなかった部分を対応できるようにした
というのがざっくりな内容だ。

今回、初めて基幹システムのリプレースという一大プロジェクトを終え、
色々と気づいた点や、学べたことが多かったので
幾つかパートに分けて残そうと思う。

1. 検討フェーズ

検討フェーズにおいて特に難しかったことは
要件定義と検討システムの理解をすることだ。

▼要件定義について

そもそも今回システムをリプレースする話になったのは
Zacの運用において、下記のような問題が顕在化したからだ。

• 稟議WFが適切に機能していない
  →各業務における稟議プロセスが、適切に運用されていない。統制が取れていない。

• 事業領域の拡大、ビジネスモデルの変化に合った予実管理の必要性
  →Zacが案件予実の管理に強い一方で、弊社のIP事業の予実管理にはめっぽう弱いという欠点。

• Zac→弥生会計にバルクで数字をインポートすることによるトレーサビリティの欠如
  →科目ごと、取引先ごとに、詳細に数値を追うことができない。故に異常値などに気づきづらい。

他にも沢山あったが、先ずは上記のような問題点を洗い出すことから始め、
- 既存システムの運用における問題点は？
- その問題が起きている原因は？
- 本来はどうあるべきか？どういう動きをしたいか？
を整理するところから着手した。

例えば上記の例に当てはめると、

「稟議WFが適切に機能していない」

▼既存システムの問題点
　- 経路設計における柔軟性の欠如、承認者が固定的で融通が効かない

▼問題の原因
　- 社内的に縦・横兼務（本部長兼部長・本部長兼任など）がある
　- 社内的にA部門のメンバーの申請をA部門長、B部門長に承認をもらう等のケースが発生する。
　- システム的に上記2点を考慮して、経路を組むことが不可能。

▼本来のあるべき姿
　- 縦・横兼務は中長期的に解消する前提で、現状必要とされている承認者の承認を得られるWFの設計をする。
　- 経路に柔軟性が有り、例えば1つの申請フォームに対してn個の経路を組み込めるような形でWFを組む

といった感じに整理ができると思う。

まずはこうやって今顕在化してる問題を起点に1つ1つリスト化することで
「どういう要件があるのか？」
「どの要件が本当にmeetすべきものか？」
が見えてくる。

（この辺がリスト化されるとこの要件はどの領域の話か？という点もカテゴライズされてくるので一石二鳥だったりもする）

ちなみに僕がこれをやったときは15~20個くらいの大小さまざまな問題点が出たが、最終的には↓くらいコンパクトにして上申した。

次回は検討フェーズにおけるシステム選定について、検討候補のシステムをどう理解していったかについてまとめようと思う。