岸和田製鋼に行ってきた③ まず取り組んだのはデータモデルと要件定義

f:id:itkisyakai:20191112160340j:plain

お客さま第一——しかし設計変更があると大変

2012年に経済産業省が公表した電炉業再編の指針「金属素材競争力プラン」をきっかけに、岸和田製鋼は事業基盤の再整備に着手した。そのときのウエイトは基幹系ITシステムの見直しより、圧延工程の更新によって製品(鉄筋)の種類を拡充すること、配送・配車の最適化で顧客(発注者)満足度を高めることにあったように思われる。

事業改革を進めていくなかで、ITシステムの硬直性が目につくようになった。その原因を探って行くと、営業、調達、生産、出荷、経理といった部門間で、スムースなデータ連携ができていないことが見えてきた。

鉄筋の受発注と清算は鉄の総量(トン)で行われる。しかし実際は、発注者から渡された設計図をもとに、強度(耐荷重や耐震性)を考慮して、営業部門が直径何ミリの鉄筋を何本、補強するフック/フープ、アプセット溶接などを算出する。発注者との擦り合わせでOKが出たら、それをトン数に換算する——というプロセスを経る。

ちなみにアプセット溶接とは、継手端面を突き合わせて圧力を加えて通電し、電気抵抗により発生した熱で接合させる溶接法のこと。「突合せ抵抗溶接法」ともいう。

同社が受注した建造物の設計が一部変更されたとする。当然、鉄筋の種類、本数、加工方法が変わる。営業部門が「お客さま第一」なのは当然として、しかし工場の現場は生産計画を簡単に変更できない。加工工程、積載・配送計画も修正が必要になる。そのようなわけで、営業部門と生産部門は何かとぶつかることが少なくない。

f:id:itkisyakai:20200113140723j:plain

フックとフープ、アプセット溶接(岸和田製鋼の資料から)

それでも「お客さま第一」であることに変わりはないので、結局は生産・加工工程が無理をして納品する。生産工程の無理とは、作業の手戻り、工場就業者の残業、事務作業の重複などを意味している。しかもITシステムが出力するレポートは、前日営業終了時点の「結果」でしかない。

——これではリアルタイム経営はできない。

鞠子重孝社長の思いが行き着いたとき、つまり2015年のこと、松村栄一氏がシステム刷新の責任者として岸和田製鋼に入社したわけだった。

前回の文末に示した「IT基本方針」(①向こう20年間のITの変化にも対応できるシステム基盤とする ②標準化とOSSOpen Source Softwareの採用でTCO(Total Cost of Ownership)を低減する ③ビジネス環境の変化に的確・迅速に対応できる拡張性、柔軟性を備える)——は、松村氏が鞠子社長をはじめ、営業部門、生産部門、品質管理部門、出荷・配送部門、経理部門などにヒアリングし、意見交換しながら形成した共通認識を、IT用語で表現したものと言い換えることができる。

ベースに米国留学以来35年の親交

松村氏が岸和田製鋼に入社するに当たっては、ちょっとしたエピソードがある。はるか以前、松村氏が米国サンフランシスコ大学に留学していたとき、鞠子重孝氏も米国で岸和田製鋼の後継者として経営学を学んでいたのだ。2人は35年来、個人的な親交関係にあった。

鞠子社長は当然、松村氏がIT関係の仕事に従事していることを知っていたので、

——ITベンダーから総額約6億円の見積もりがきているのだが、君ならいくらでできるだろうか?

と声をかけた。

——そうですね、わたしならその半分で開発できるかもしれません。

——じゃぁ、検討してくれ。

このような会話が交わされたのは2013年か2014年だったか。

松村氏は東京に本社を置く独立系ソフト会社でプロジェクト・マネージャを務めていた。

——そこで勤務していたソフト会社が次期システムの概要設計を受注するかたちにして、実質的に自分が岸和田製鋼のコンサルタントとして出入りするようになりました。

このときの基幹系システムは、IBMのミッドレンジコンピュータ(オフコン)AS/400をホストとするバッチ処理システムだった。最初に稼働してから約30年、ハードウェアは定期的に更新してきたが、法制度の変更や機能拡張のたびにプログラムを修正・追加してきた。

よく例えに使われるのは、建増しを重ねてきた木造2階建ての旧館と鉄筋コンクリート5階建ての本館、10階建ての新館が、渡り廊下と地下通路でつながっている老舗旅館だ。プログラムはスパゲティ状態で仕様書も詳細なメンテナンスの履歴も分からない。AS/400の寿命を考えると作り直すしかないのだが、サーバーをオープン系にリプレースしたり、現行システムをクラウドに乗せ変えるだけでは意味がない。

「"これから"を見通したとき、開発に時間がかかったのではビジネスチャンスを失います。営業や生産の現場からニーズが上がってから半年後に、やっとシステムができたのでは市場の変化に一般的に応えられません」

アジャイル開発が注目される所以だ。

「それと、ITシステムの専門家は運用後の費用を見逃しがちです。企業が投入するIT予算の8割が保守・運用に使われている。それを圧縮するにはオープンソース(OSS)を活用するのが一つの方策だと考えました」

そのようにして策定した「IT基本方針」を、誰がどのように具体化していくか。

「概要設計は作りました、あとはご随意に、では済まないじゃないですか」

ITエンジニアとしての意地が動いた、というべきだろうか。

要件定義でSVOを明確にする

メトロを退職し、岸和田製鋼に入社した松村氏は「IT基本方針」に基づいてデータモデルの整理と正規化、要件定義の再設定からスタートした。データモデルの整理と正規化は、全社共通・唯一のデータベースを構築するのがねらいだ。

部門ごとに構築されたデータベースはあくまでも管理のためのデータベースだ。個々の部門にとっては"最適"かもしれないが、部門間でデータを共有することができず、経営者や管理者が時宜よく判断するエビデンスとして機能しない。

データベースを唯一にすれば、真のERP(統合型経営資源管理)が実現する。それだけでなく、状況変化への対応力に柔軟性・機敏性を持たせることができる(下図)。手間と時間がかかる作業だが、これだけは社内のパワーでやり遂げなければならない。

f:id:itkisyakai:20200114130256j:plain

もう一つのテーマ「要件定義の再設定」に、松村氏は「PEXA」を使うことにした。

PEXAは「ペクサ」と読み、東京・用賀に本社を置くアトリス(安光正則社長)というソフト会社が開発・販売しているシステム設計のための方法論とツールがワンセットになったパッケージだ。

「東京のソフト会社に勤めていたときから、PEXAを知っていました。ただ、名前を知っていた程度で、製造業の基幹システムに適用できるかどうか、自信があったわけではありません」

と松村氏は言う。

では、なぜPEXAの採用に踏み切ったのか。 

「ITを利用してTCOを削減する、つまり理想的には保守費用ゼロにする手段を考えたとき、PEXAはOSSを取り込んだ設計ができるのが魅力でした」
同社のシステムで最も大きなウエイトを占めているのはデータベースだ。ここにOSSのPostGress(ポスグレ)を採用できれば、運用コストは格段に低減する。
「PEXAで要件定義を固めていくと、SVOが確定して行きます。業務処理システムとエンベデッド・システムでは質が違うので一律には言えませんが、SVOが明確になればコーディング・レスでシステムが作れるかもしれません」
Sは主語(誰が)、Vは動詞(どうする)、Oは対象(何を)だ。
アトリスの安光正則氏に尋ねると、
——PEXAの「SVOステートメント」のことですね。
という答えが返ってきた。
データを正規化し、要件定義をきっちり策定しておけば、短期間でサービス・インができるだけでなく、機能を追加するのも容易になる。しかもデータベースを動的に管理できるので、経営者や管理者が「いま」知りたいこと、処理したいことにシステムが応えられるようになるというわけだ。 

松村氏はアトリスとともに、岸和田製鋼の全業務プロセスを俯瞰図にする作業に取り掛かった。

次回「コーディング・レスで基幹システムを全面刷新」 ⬇️

http://itkisyakaiessay.hatenablog.jp/entry/2020/01/21/%E5%B2%B8%E5%92%8C%E7%94%B0%E8%A3%BD%E9%8B%BC%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%9F%E2%91%A3_%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%83%BB%E3%83%AC%E3%82%B9

アクセスカウンター