突然ですけど、皆さんの会社では業務システムって何を使ってますか？基幹システムと呼べるものは導入済みですか？

大企業・中小企業は当たり前、イマドキはスタートアップでも個人事業主でも何かしらの「○○システム」と呼ばれる製品やサービスは使っているんじゃないでしょうか。今日はそんなシステムにまつわる個人的な考え方を書いていきます。

業務システムってなに？

当社はお客様の資産運用を手助けする業務をメインとしていますが、そのときに必要なものとしてまずお客様の状況を把握する顧客管理システムや、限られた時間で最高のパフォーマンスを発揮できるように従業員向けに営業支援ツールが必要です。

業種によっては、例えばものづくり企業であれば在庫管理システムや生産管理システムが必要でしょう。またそれを売るため（周知するため）にマーケティングツールやサプライチェーンマネジメントが必要になります。販売管理システムや仕入管理システムがその一端を担います。

どの会社でも共通しているのは、労務管理する勤怠システムだったり、意思決定を明文化する承認システムや、会社として正式な最新の情報を管理する文書管理システムなどがあります。

このように、どんな業種業態であれ仕事をする上では多種多様なシステムを利用する（または利用したほうが良い）時代になっています。

基幹システムってなに？

じゃぁ基幹システムってなんでしょう？「経営に欠かせないシステム」なんて言われたりしますが、IT用語辞典によると…

基幹系システムとは、企業や官公庁などの情報システムのうち、事業や業務の中核に直接関わる重要なシステムのこと。または、全社で共通して利用される、その組織全体の基盤の一部となるシステム。

IT用語辞典 e-Words 基幹系システム 【 mission-critical system 】

だそうです。ここで注目するべきは全社で共通して利用されるってところ。

例えば製造業で材料を買ってきて何かモノを作って売る会社の場合に、仕入管理システムと生産管理システムと在庫管理システム、また販売管理システムや会計システムがバラバラの状態だったらどうでしょうか。（情報の分断化）

それらの情報がバラバラのままだと、どれだけ売ったか（売れるか）わからないし、どれだけ作れば良いかわからないし、なのでどれだけ材料を仕入れたら良いのかわからない…。

それはマズイので情報をつなげようとするんですが、システムがバラバラなので情報連携に時間がかかったり必要な情報が連携されてなかったりで、経営層からすれば「だから今月の利益は（来月の見込み利益は）なんぼやねん！！」となるわけです。

そうならないために『会社の情報をちゃんとつなげましょうね』っていうのが基幹システムなわけです。経営層が全て把握できるくらいの会社規模であれば不要かも知れませんが、ある程度の規模（＝それぞれで部門ができるくらい）になれば必須と言われています。

ちなみに最近は基幹システム＝ERP（Enterprise Resource Planning ）と表現することもありますが、これはその名の通り会社の資産（つまり「ヒト・モノ・カネ」）を管理できるツールのことで”結果的に”基幹システムレベルになるというものです。 あと、やっぱり会社は会計が基本なので会計システムスタートで基幹システムになることも多いです。

スクラッチ開発の終わり

さて、会社にはいろんなシステムが必要ですが、じゃぁそのシステムって誰が作るんでしょう？

社長？社内の人？ITベンダーさん？Amazonで買う？

企業の多くは SIer 任せ

SIer＝ITベンダーはそれら業務システムというものを多くパッケージとして備えており、開発力もあるので「貴社のビジネスに合わせてカスタマイズしますよ！」と謳ってきます。実際、導入してみたら業務が加速し導入コストに見合った実績をあげられることが多いです。

社内に情報システム部門があるような会社であれば SIer と協力してよりビジネスにマッチした開発導入や運用保守までスピード感を保ったままできるかも知れません。

ただ、特に中小企業の多くは情報システム部門がないか、あっても”システムのプロ”がメンバーにおらず SIer に任せっきりなことも多いんじゃないでしょうか。勘違いして欲しくないのは、それはそれで悪いことではないです。が、少なくとも業務システムを導入する上で『自社のビジネスはこうなんだ！』と完全に理解した人が作らないといろいろ問題が起きますよ、と…。

そこ、ほんとにカスタマイズ必要？

ようやく本題に近くなってきた。
私は長らく、いわゆる ITベンダー＝SIer で多種多様な企業のシステム開発を行ってきました。主に製造業が多かったので、PLM や PDM といった製造に関わるシステムや生産管理システムなど、パッケージ製品をカスタマイズしたりフルスクラッチ（＝ゼロから作る）開発をやってきました。

導入する前には必ず『どんなシステムに作り上げるか』いわゆる要件定義が発生しますが、そこでほぼ確実に言われるのが…

「うちは特殊だから」

いやいやいや！そんなことない！そんなことないですよっっ！！と心のなかで叫びつつ、要件定義をまとめていくわけです。

これは日本企業の良いところでもあり悪いところでもあると思っているのですが、企業には文化ってのがあるんです。あと、私世代の開発者は完全にノーシステムだった部分に導入するというよりリプレースが多いため、それまでのやり方を崩したくないってのもあります。

「普通の製造管理方法じゃない」「だからパッケージそのままでは導入できない」 うん、言いたいことはすごくわかります。そして実際に完全に同じ企業なんかありません。でもシンプルに考えたらどの企業もやってること同じじゃない？と思ったわけです。（※個人の感想です）

日本企業と欧米企業のシステムに対する考え方の違い

海外企業のシステムを導入するときに、はっきりと日本企業との考え方の違いを体感しました。それは…

• 日本企業・・・会社のやり方、業務フローにシステムを合わせる
• 欧米企業・・・会社のやり方、業務フローをシステムに合わせる

もちろん全ての企業が…ってわけじゃないですけど、海外は業務フローぶっ壊します。新しいシステムで良いと思えばそれまでのやり方を全面的に移行します。なので、システムはノーカスタマイズ（少しの設定変更）で稼働します。

一方、日本企業は先の文化の話もあり、今の業務フローをできるだけ踏襲し維持しようとします。なのでシステム導入の際に会社のやり方に合わせたカスタマイズが必要になります。

カスタマイズだらけになったら…

勘違いして欲しくないのは、決してスクラッチ開発やカスタマイズを否定しているわけではありません。企業にとってそれが最適な場合も多くあります。ただ、カスタマイズされたシステムにはデメリットがあることも理解しなくてはいけません。一例として…

• 開発コストが膨大になる
• 他システムとの影響範囲が大きくなる
• バージョンアップがすぐにできない

などなど。特に個人的に問題だと思っているのがバージョンアップがやりにくい点だと思います。

新機能が追加された新しいバージョンが発表されても、今の環境をゴリゴリにオリジナル化しているためストレートにバージョンアップができず、他システムと連携している部分も見直して…また開発コストこんなにかかるの？そんな予算ないよ！→ 結果、何年、何十年も前のシステムがいまだ現役で稼働せざるを得ない…
（そういうのって結局保守料金で高額支払ってるんでリプレースしたほうが良いんですけどね、あ、個人の感想です）

なのでできるだけカスタマイズしないシステム導入、かつ必要であればそれまでの業務フローを見直してでも効果が出るものを選定するようにしています。

SaaSの登場

いよいよ本題です！いや前置き長過ぎましたね…

クラウドの普及とともに2010年頃から爆発的に増えてきた SaaS（Software as aService ）の考え方は、それまでのシステム開発を抜本的に変えるものでした。

今まではサーバーを買ってソフトを作って提供していたのが、最初から全部コミコミなんです。最近流行りのサブスクリプションモデルが主流で、基本的にはイニシャルコストもかからず使う人のライセンス料金を支払うだけ。

「え～ずっと費用発生するじゃん」と思うかも知れませんが、これまでのオンプレ型システム導入の場合は高価なサーバー費用が最初にかかるし、何よりバージョンアップや数年後リプレースするときにまた高額な費用が発生します。

それが SaaS であればサーバー管理などしなくて良いのでハードウェア保守も発生しない、かつ常に最新のバージョンを利用することができます。

そして一番の違いは、そのバージョンアップ頻度にあります。これまでの仕組みだと開発者側は新しいものを作るときに「どんな機能を実装すべきか」「どんな利用をされているか」ログなどを導入企業からもらって分析して作る必要がありました。

それがSaaS提供会社の場合はクラウドで利用されているわけですから、リアルタイムに需要がわかり、かつ提供してみたらリアルタイムで反響がわかるわけです。なので”進化”のスピードが全然違います。

長いものには巻かれろ戦略とは

ここでようやくタイトルが登場です。

ではいざ「次のシステムはSaaSで導入するぞ！」となっても、もちろん何でも良いわけではありません。最初の話で、それぞれ業務システムを SaaS 化したところで情報がバラバラであれば意味ないのです。

情報がバラバラにならないためにはどうすれば良いか？やっぱり基幹システム？その前にできることがあります。

それは、シェアのある有名な SaaS を利用すること、です。

…急に抽象的な表現になってしまいました。

市場でシェアがあるシステム＝他のシステムはそこに連携しようとします。自社のシステムを使ってもらうために「あ、もちろん○○と連携できますよ！」というスタンスで開発するはずです。

当社が導入しているシステムは…

業務効率化には高度なシステム化が必須であり、当社は代表の考えもあって、良くなるならこれまでの業務フローをぶっ壊してもシステム化を進めるスタンスです。

日進月歩どころのスピードではない進化を見せるテック業界で生き残るためにはそれ相応の進化をする SaaS システム、それをフル活用できる周辺システムが潤沢なこと、また使う人が全力で使えるシステムを導入する必要があります。

そこで当社では2018年終わり頃から営業支援ツールと顧客管理システムとして Salesforce を導入し、社内の情報連携基盤として Office365 を使用しています。

今年から一部の業務で電子契約をするために DocuSign も導入しましたが、もちろん Salesforce と連携できますし、Office365 では常に最新版の Officeアプリや Power Platformを利用することができます。

業務をできるだけシンプル化して全てをシステム化することで無駄を排除し、より生産性の高い業務やより良い顧客提案にアタマを使ってもらう時間を確保するのが目的です。

デメリットもある

この「長いものには巻かれろ戦略」とは「シェアのある有名なソフト使おうぜ！」ってことなんですが、もちろん懸念すべき事項もあります。それはプラットフォーム依存になることです。

先ほど列挙したシステムは全てアメリカ製であり、まぁそれは良いんですけど、SaaSの良さである「どんどんバージョンアップしていくぜ！」についていける環境を作る必要があります。

例えば Office365 でバージョンアップが発生して普段から使っている Teams の画面が突然変わったら…？社員から「ここにあったボタンが無くなってるんだけど！！😡」とクレーム問い合わせが絶えないでしょう。#情シスあるある

その程度ならまだ良いですけど、Salesforce なんかで抜本的に見た目が変わった場合、業務に支障をきたすこともあるかも知れません。結果、バージョンアップできず…という SaaS のメリットが活かせない場合も…。

でもそこは情シス部隊がアタマ張ってなんとかする部分なわけであります。どんどん進化する SaaS についていく業務改善を常に提案し、実務部隊を巻き込んで改革していくのが本来の業務となるべきです。

まとめ

気付けばすごい長文になってしまった…。ここまで読んでいただいた方、本当にありがとうございます！

システムのサイクルはかなり短くなっています。昔は10年、5年スパンでシステムを導入し、保守切れ間近でリプレースを検討する…というスピード感だったのが SaaS の登場によって”常に”新しいやり方を模索することができるようになりました。

今の時代、正直「5年間業務フローを変えない」というのは、どんな業界でも全くついていけないと思います。

今は最新のこと、かつそれが現時点で最適であったとしても常に良いものを模索し、振り返ったときに「あれ？このやり方って古くない…？めんどくさくなってない…？」とならないようDXしていきましょう！

↓Tiwtter始めました！