いわゆる“ひとり情シス”として、製造業の基幹システムを3年ほどかけて全部開発した。基幹システムは商品の受注、加工、出荷に至る流れを管理する。ここに他のシステムをつないでいった。
例えば、顧客情報やクレーム情報など、日常の業務で扱う情報の管理ツールを用意し、基幹システムと共通のコードを用いることでマスター情報を連動させている。生産管理システムはもともと別につくっていたが、工程番号を介して製品の構成情報を共有させ、現場で品質を容易に管理できるようにした。
自分が設計し開発した基幹システムが中心にあるので周辺のシステムやツールをスムーズにつなぐことができた。
とはいえ、もともとはプラスチック加工メーカーの技術開発者であり、ITの仕事をしていたわけではない。プログラミングは学生の時に独学でかじった程度で、システム設計のトレーニングを受けたこともない。
メーカーに入ってから特定の問題を解決するツールの開発はたびたびやっていたが、個別最適を目指す単発のプログラムを集めたところで全社の業務の流れを支える基幹システムにはならない。
基幹システムをつくり直したいが、やり方が分からず悩んでいるとき、書店で1冊の本を見つけた。読了して目からウロコが落ちる思いがした。この本に背中を押されて基幹システムをつくる挑戦を始め、苦労はしたもののなんとか達成できた。その経験を今回お伝えする。
ひとり情シスを勧めるつもりはない。継続性を考えたら1人だけで作らないほうがよいに決まっている。だが多くの中堅・中小企業が情報システムをなんとかしようとすると、ひとり情シスかそれに近い状況にならざるを得ないのが実情だろう。
基幹システムの内製であれば積極的に勧めたい。社内の人間によるシステム開発の一番の強みは、現場の利用者に近い、業務に近い、ということだ。組織体制やルールなど社内の事情を知っているので自分から担当者に質問できるし、現場が望む以上の解決策を考え出せる。
事業会社からすると内側からつくり上げる方が良いシステムができる。開発者にとっても内側にいたほうがつくりたいものをつくれる。
基幹システムをつくり直したいがやり方が分からない
1999年、中堅のプラスチック加工メーカーに入社し、技術開発担当として働き始めた。製品ごとに異なる原料構成や加工条件を一つひとつ記録し、管理する仕事だった。ところが製品は数百以上あり、製品の数だけExcelファイルが用意され、使用する原料が変わる度にそれぞれのExcelファイルを修正しなければならなかった。
