見出し画像

基幹システム刷新やらないとやべぇ!

2025年の崖」という言葉をご存じでしょうか?

カスタマイズを重ねたレガシーシステム化の進行に、エンジニア不足が重なりシステム保守費用が高騰。その結果、企業がシステム的な旧弊を打破できずに、業務基盤の維持が困難になるというものです。

弊社が生業としている工作機械の製造販売では、調達、加工、製造、販売まで一貫してシステムが業務に深くかかわっています。

一般的な工作機械1台は数万点の部品で構成されていると言われます。物流の受入部品数は1日単位で千点を超え、さらに、30程ある機種を月ごとに変種変量生産しているとなると、システム無しでは管理できないというのは容易に想像がつくのではないでしょうか。

弊社ではこのようなシステムのことを基幹システムと呼んでいます。現在使用しているものは10年以上前に導入したものです。

自分が入社する前のことですが、補助金利用のためにしっかりとした検討がないまま導入が進んだそうです。ベースとなる設計や生産の考えは何も変わらず、基幹システムの入れ替えが短期で行われました。そういう意味では、設計や生産の考えの根幹は何十年も変わっていないことになります。

その間に工作機械の生産の在り方は大きく変わりました。以前は単純な機構の3軸機を大量に作るだけ。何も複雑なことを考えなくても、使用する部品種類は少ない。似たような仕様の機械が並ぶので、納期変更の対応も楽に行えていたのです。そして、設計と製造のシステムも標準品を大量に作るような製造のモデルを想定していました。

今の工作機械はどうでしょうか?自動化のトレンドもあり、機械自体の仕様も高度で多様になっています。カタログの裏には大量のオプションリスト…。主軸仕様、ATC仕様、APC仕様、クーラントスルー仕様、自動計測仕様、熱変位仕様、切り屑処理仕様…。

同じ機種が隣に並んでいても、中身はまるで違います。1つの仕様の違いとそれらの組合せが掛け算で働き、部品表の種類を膨大にしているのです。こうなると、部品の共通化、中間品の取り扱い、原価計算、仕様や納期の変更はシステム上で工夫しないとうまく回りません。

そして、いままで使い続けている弊社の基幹システムは工作機械の仕様が複雑化していく流れに完全に置いて行かれていました

一度確定してしまうと納期が変更できない。
機種共通の部品表にシステムが対応してしない。
標準仕様構成から足し引きする考えのオプション部品表。

このようなシステム上の制約の中、なんとか複雑な生産状況に対応するために様々な部署が独自のカスタマイズをしたり、他のソフトやシステムを各部署で入れて機能を補完したりということが続けられてきました。結果的に会社全体の中に数多くのシステムが存在し、お互いに複雑に絡みあうものになっていたのです。まさにDXの問題でよく聞くレガシーシステムを体現しています。

日本では、レガシーシステムや技術的負債(Tech Debt)と形容される、古くなったITシステムがDXの早期実現の大きな壁になるからです。最悪の場合、これを理由にDXプロジェクトが頓挫することもあります。  
レガシーシステムは、過去20~30 年の間に、都度発生した業務要件を実現するために、機能のつぎはぎが繰り返され、複雑化・老朽化していった歴史を持っています。

黒川通彦; 平山智晴; 松本拓也; 片山博順.
『マッキンゼーが解き明かす 生き残るためのDX (日本経済新聞出版)』
日経BP. Kindle 版.
pp.153-154

例えば、以下の点のようなことが問題としてありました。

  • 本来共有できるものが共有できていない

  • 独自のやり方がどんどんエスカレートする

1つ目は顧客情報や工程の進捗がいくつかのシステムで分散されて独自管理されているようなことです。

営業は修理の情報が知りたい。でも、それはカスタマーサポートの管理するシステムに見に行かないと分からない。
組立は加工の進捗を見たい。でも、加工のシステムに見に行かないと分からない。

このような状況であるあるなのは、要望として「○○の情報をみれるようにしてほしい」という声が出ると、相手側は「△△のシステムに入れば見れる。アクセス権もXX本部に渡しているはずだ」となります。

すると、「あのシステムは自分たちにとっては使い勝手が悪いので、こっちのシステムで見れるようにしてくれ。製番と紐づいてボタンを押すとリンクで飛べるようにしてくれ」とカスタマイズにつながり、操作画面内にはボタンだらけになるわけです。

ベテランしか使い方が分からない画面。属人化も進行します。

2つ目については、カスタマイズにカスタマイズを重ねて、独自のやり方を各部署が突き詰め続けるという悪循環が発生していると思いました。

弊社の社員は400人と所帯も大きくなってきており、ある意味で事業部制のような形で各部署が自部署の利害を基準に物事を考えるようになってきています。

例えば、改善のためにシステムの何かを変えようとしたとき、他の部署のシステムも巻き込んで大きく変わってしまうという状況だとします。もし、自分たちの効率化のために他本部に少し手間を要求するとしたら、どうなるのか。

「俺たちの手間が増えるのは嫌だ」
これで検討は終わりです。そして提案側も嫌がる他本部を説得するのは大変面倒な訳です。

会社全体で見て、1の手間を掛ければ、2の効率化が達成できて、差し引き1のプラス効果があるはずなのに上手く行かない。

するとどうなるかというと、自分達の守備範囲だけで何とかしようと自部署に別のシステムを新たに導入したり、元のシステムにカスタマイズを施す。これはシステムのサイロ化と呼ばれる現象です。

こうなると、その部署のやり方というのが確立してしまい、後戻りができないくらいに突き進んでしまいます。実際、前からその考えでやっているからという理由で、世の中の杓子定規で見れば異端なことをしてしまっているということはかなりありました。

一方、使い勝手に関しては社内から不平不満の嵐です。本当に誰もシステムについて良いことを言っている人はいません。そして、クレームを聞く人達は「○○さんが無理やり入れたやつだからなぁ」と引退した責任者の名前を言うばかりでちっとも改善に進むことはありませんでした。

これを放っておくと大変なことになる。時間がたてばたつほどあるべき姿に戻すコストが上昇し改善が難しくなるばかりだ、と私は心配していました。

そんな時、松浦機械では長年務めていた常務2名が同時に勇退し、執行役員制に移行しました。全本部に新役員を迎えて新しい松浦機械を目指そうとする今こそが最高のタイミングだ。全本部に関わるシステムを根本から見直し、全社最適を目指すのは今しかない、と考えて、基幹システム刷新のプロジェクトを開始させました。

あらゆる書籍には「システムを業務に合わせるのではなく、業務をシステムに合わせることが重要である」と共通して書かれています。

当たり前ですが、カスタマイズだらけだったレガシーシステムを標準形に置き換えるのは簡単なことではありません。いままでのやり方が変わるというだけでも人は拒否感を示すものです。

弊社はERPやPLMはパッケージ製品を購入する前提です。そのパッケージ製品の標準機能で賄えない部分を、元のシステムの機能に変更をベンダーに加えてもらい実現します。このカスタマイズで実現する機能がかなり多いというのが現状です。

カスタマイズについては本当に注意が必要だと考えます。レガシーシステムはカスタマイズによって容易に生まれるからです。

人月単価をベースにしたビジネスを展開する多くのSIerにとって、収益の大きな源泉となるのは設計・開発工程においてプロジェクトに配属する大量のエンジニアであり、そのボリュームを左右するのはカスタマイズの規模と複雑性です。SIerのビジネスの性質上、技術的に実現可能な限り、カスタマイズ要件が多ければ多いほど、また複雑であればあるほど潤うという構図のため、カスタマイズ要件を能動的に抑え込む力学が働かないのです。

黒川通彦; 平山智晴; 松本拓也; 片山博順.
『マッキンゼーが解き明かす 生き残るためのDX (日本経済新聞出版)』
日経BP. Kindle 版.
p.159

パッケージ製品に対してカスタマイズを極力抑えて標準仕様のものを使用するメリットは何が考えられるでしょう。

よく言われるメリットは業務の標準化です。パッケージ製品は世の標準的な業務に合わせて作られているはずなので、複雑になってしまった業務フローを標準にすることが出来ます。

この標準化ということが将来のために効いてくると思うのです。

ネットと調べると以下のようなことがメリットで紹介されています。

  • システムのバージョンアップでの検証作業の難易度が下がる

  • ブラックボックス化/属人化を避けられる

今回のプロジェクトで実感したのですが、過度なカスタマイズはリスキーなものです。

実際に基幹システムはいくつかの独立したシステムから構成されますが、システムの連携は行われます。1つのシステムでカスタマイズが行われると、連携する別のシステムもカスタマイズが必要になることが多い。その結果、システムがどんどん複雑なものになっていきやすいと感じました。また、カスタマイズありきの機能を存続させることで、システム更新の度に、独自の機能を設計する多額の費用と時間がかかり続けることも心配です。

今回の基幹システム刷新を通じて、今までの業務を断捨離して標準パッケージに業務フローを合わせます。会社としてのポリシーを変えるだけでも、カスタマイズが不要になるケースもあるはずです。その上で、ビジネス価値が高い要件、競合との差別化につながる要件に対してのみ、アドオンやAPIでの柔軟性の高い個別の機能実現を行うことが理想です。

最終的には実現するための費用と効果を合わせて話をしないと皆納得しないものだと思います。しかし、ぱっと調べてもあまり標準化のメリットというのは理解させにくいものではあるなぁというのが本音です。

標準の形に変えるという改革自体にお金がかかるというジレンマもあります。コストを抑えるためにコストを掛けるということですね。

どういうことかというと、今までの考え方で作成された部品表や品目情報の長年の蓄積があります。それらに対して、新しい考え方のもと標準の形に組み替えらればいいのですが、あまりにも量がありすぎて、短期的に修正するのはとても難しいわけです。

そうなるとどうなるかというと、古いものは従来のやり方でできるようにシステムで対応、新しく開発したものから新しい考え方とシステムを適用する、ということを考えます。製品の世代交代によって、いずれ全てが置き換わっていくということです。システムとしては2つのやり方に対応が必要なので、システム開発工数が余計にかかります。まだもらっていませんが、正直、見積もりを見るのが怖いです。

ここから導入コストを下げるやり方は簡単。新しいやり方に変えるということなんて諦めて、今までのやり方を踏襲し続ければいいのです。

しかし、この安易な選択が冒頭の「保守費用が高騰。その結果、企業がシステム的な旧弊を打破できずに、業務基盤の維持が困難になる」ということではないでしょうか?

”古き”から”新しき”への移行をサポートするコスト。
これは未来への投資です。はっきりとした費用対効果を見出せないようなものである気がします。

ヒアリングを行いながら要件定義を行っているのが今の段階でまだまだ道半ばです。しかし、会社の今後の方向性を決める重要な時だと感じています。

経営層にお願いして2023年度の1年間は自分の出張は最小限に抑えて、基幹システムプロジェクトを含む社内業務に集中することにしました。

海外出張は今年は1回だけ。毎週2,3回の打合せにはなるべく出るようにしています。これは全て全社最適の業務フローとシステムを見定め、レガシーシステムのしがらみから脱却するためです。

システムベンダーからは「第2の創業と考えてください」と言われています。会社の将来のため何とかしたいです。


このnoteを800文字程度にぎゅっと内容を凝縮した私のコラムが松浦機械製作所の広報誌、マツウラNEWS!にて掲載されております。


このコラム以外にも、弊社の社長コラムやユーザーインタビュー、最新の松浦機械の活動も紹介していますので、もしご興味あればそちらも読んでいただければと思います。

また、私のDX推進の日々や工作機械の話をかなりカジュアルにTwitterにて発信しています!もしご興味ありましたらぜひフォローお願いします!

最後まで読んでいただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか?