基幹システムのリプレースをした話 #2
（少し間が空いてしまいましたが、こちらの続きの内容です。）
新しいシステムの導入やリプレースに際して、
ある程度の要件が固まり、実際にシステムを選定するフェーズに入ったら
下記を念頭に置いておくといいかも知れない。
（※市場にある製品を選定する、という前提なのでスクラッチ開発する場合などはこの辺の話は無視してください）
全ての業務を完璧にシステム化できるなんて思わない方がいい。
サービスの開発思想を聞いておくと、中長期的に自社にマッチするかが分かる
順番に説明していく。
1. 全ての業務を完璧にシステム化できるなんて思わない方がいい
（特に基幹システムにおいては）システム検討するからと言って
全ての業務プロセスをシステムに置き換えられるものを探そう、なんて考えない方がいい。
もちろん部分的な作業をシステム化する（例えば稟議システムだけを導入する）という話であれば、この限りではない。
が、大抵のシステム導入においては
システムに乗せきれない領域が存在するはずだ。
例えば私が以前にZACからfreeeプロダクトに基幹システムを入れ替えたときは、下記のような事案が発生した。
▼発生事案
<要望>
freee販売で案件別に原価を管理したいのだが
「案件(大カテゴリ)」 例) 某企業のSNS広告
「案件(小カテゴリ)」 例) 商品AのSNS広告、商品BのSNS広告
といったのような形で案件情報を作ることはできるのか？
<結論>
機能的に上記のような属性をつけて案件情報を作ることは不可能。
運用でカバーする案として
<大カテゴリ>を洗い出し001~999で付番、
<小カテゴリ>を洗い出し001~999で付番、
freee販売の案件登録時に使用できる「案件コード」の中に
「一意の取引先コード4桁 + 大カテゴリ3桁 + 小カテゴリ3桁」にという属性情報を持たせる形で実装。
<採用理由>
最終的な案件別の予実分析をする際に
freee販売からcsv形式で案件別に売上、原価、粗利のデータを吐き出す作業が発生する。
その際に「案件コード」を何かしらの関数でスプリットし、
あとからどの3桁が何のカテゴリと対応するかをLookupできれば一旦の運用はできそうだったから。
といった具合だ。
こういった「地味に痒いところに手が届かない」ケースが必ずしもないとは限らないため、「どのように運用でカバーするか？」という視点が大事になる。
個人的にfreeeを導入したときは「7割くらいは要件に合っていて期待どおりの運用ができそう、でも3割はルール固めて、運用でカバーしないとけないな」と思ったのが正直なところだ。
2. サービスの開発思想は一応聞いておく
もしかしたら全サービスに当てはまらないかも知れないが、
大抵のサービスはユーザーの声を反映させて、
どんどんサービスをアップデートしていくものだ。
で、そのアップデートがどういう優先順位で行われるかというと、
それは開発側の思想に依存しているものだ。
例えばfreeeの場合は
「統合させていく」ことがサービス開発のコンセプトにあった。
会計と人事(労務)を統合する、会計と契約業務を統合する、
といったように、全ての業務が最終的には会計に行き着く形で、システムが統合されていく、というのが彼らの開発思想だった。
奇しくも、ZACは”あらゆるモジュールを統合した1つの基幹システム”であったために、このfreeeの思想はすごく魅力的であった。
（中長期的には「より使いやすくなるんだろうな」というイメージを持つことができたからだ）
なんだかんだ色々説明したが
システム検討していたときには10~20ほどのサービスを見ていたので、
つまるところ可能な限りたくさんのサービスを見て、聞いて、知ることは
一定、大事かもしれない。
ただ、たくさん見れば見るほど
「もっとフィットするサービスがあるのではないか？」
という気持ちが生まれてくるのも事実だと思う。
もし「もっと他にないか？」という気持ちが生まれてきたときには
↑の話を参考になれば嬉しい。