設備保全システムは作れる
結論、設備保全システムは「作れる」と思います。最近はローコード/ノーコードを使いながらカジュアルに自社内でシステム開発をすることもできますし、外部のソフトウェアベンダーに開発をお願いすることもできると思います。自社の解決したい課題を要件に落とし込みながら、何かしらの形でシステムとして具現化することはできると思います。
ただ、そのシステムが「使える」かは全くの別問題です。システム開発の歴史は、多くの悪戦苦闘、挫折を乗り越えながら進んできました。その過程の中で市場全体としては、自社開発によるスクラッチ型から、外部の事業者が提供するパッケージ型のシステム活用に進んできており、上記の問いかけはこの大きな流れに逆行する形に見えるため、その意思決定には慎重を要します。
自前で使えるシステムを作るのがなぜ難しいのか？
なぜ「使える」システムを作るのが難しいのか。一言で言うと、「使う人と作る人が異なるから」です。システム開発は、当然のことながら何かしらの課題を解決するために行う訳ですが、課題を知りつつシステムを作れる人が社内にいることは極めて稀なので、課題を知ってる人とシステム開発ができる人の協業が自ずと必要になります。
この協業の過程で両者が相互に理解を深めながら「使える」システムとして昇華させていく必要があるのですが、それには多くの時間を要します。仕様を決めたらハイ出来上がり、というほど簡単ではなく、開発に着手した後も細かな点でのすり合わせや試行錯誤が必要です。「神は細部に宿る」と言われますが、細かい部分への拘りが最終的な使い勝手を決めるのです。
スクラッチで開発をする場合、大前提としてこの難しいプロセスをやり切る能力を持った人材を確保することが必要となります。自社内で開発するだけでも複数部署を跨いだコミュニケーションが必要になりますし、外注するとなると更に難易度は増します（スクラッチ開発を受託するソフトウェアベンダーは、設備保全に関する知見を持ち合わせていないことが普通です）。
また、何よりももったいないのは、目の前に課題が存在するのにシステムが出来上がるまでその課題解決に着手できず、機会損失が生まれ続ける点です。
ずっと使えるシステムにするために
数年待ったのに結局使えないものが出来上がってしまった…とご相談をいただくことも多いのですが、とはいえ、一旦はある程度使えるシステムが出来上がったとします。ただ、これで終わりではありません。システムは使えば使うほど、より高次の課題を解決するために必要な機能要望が出てきます。常に作り続け、常に改善し続けることが重要で、そのためには組織として大きなコミットメントを必要としますし、開発を外注している場合には、アップデートのたびにそれなりの規模の投資をし続ける必要があります。仮に追加の機能開発をしないと決めたとしても、規制の変化やセキュリティ対応、技術の進展に応じて何かしらの開発は求められますし、当然のことながら保守運用費用は発生し続けます。
パッケージ型のクラウドシステムは常に費用が発生し続ける点で一見するとコスト高の様に感じられるかもしれませんが、スクラッチ型の開発に必要な、
- 使えるシステムが開発できるか分からない不確実性
- 開発が完了するまで発生し続ける機会損失
- 中長期にわたって投資をし続ける高いコミットメント
を考慮に入れた時に、内製化に舵を切るべきかは慎重に考えるべきだと考えます。特に設備保全業務は専門性が高いため、現場が満足のいくものが出来上がる可能性は高くありません。
そもそも、クラウド型のパッケージシステムは、スクラッチ型の開発に発生しがちな上記の問題を踏まえながら、
- 他社が使っているシステムが既に存在していること
- いますぐに使いだすことができ、機会損失を最小化できること
- 雪だるま式の投資を必要としないTCO(Total Cost of Ownership)の低さ
から市場に受け入れられ、システム利用のスタンダードとなりつつあります。
システムの開発・導入はまさに中長期的な視点を持ち合わせながら行う意思決定であり、システムを利用していく間で発生するコストはもちろんのこと、そのシステム開発の不確実性や課題を放置することによる機会損失なども考慮に入れながら検討をしていく必要があると考えます。
岡部 晋太郎 株式会社M2X 代表取締役CEO
東京大学卒業後、総務省にてIT政策の企画立案を担当。その後、外資系コンサルティング会社のボストン・コンサルティング・グループに入社し、製造業における中長期の戦略立案、DX等を担当。メンテナンスの重要性と可能性に惹かれ、2022年に株式会社M2Xを創業
