プログラムのステップ量でなく機能の数
LINUXサーバーで稼働した新「KCTS」の規模を数字で把握しておこう。
「2016年12月にサービス・イン(カットオーバー)した時点の機能は1863でした」と松村氏は説明する。
通常だとシステムの規模はプログラムのステップ数やライン数で示される。○○万ステップ、○○万ラインというのは、実質的にボリューム(量)なので、無駄/冗長なプログラムが含まれる。ところがKCTSはコーディング・レスなので、機能の数で示される。元々から無駄/冗長な機能は設計されていない。
その機能数の内訳はマスターメンテナンスを含めた画面が1158、CSVによるデータ取り込み機能が175、同データ出力機能が296、帳票が195、機器連携機能が39だ。
CSVによるデータ入出力機能は、第4回で説明した経営管理部門や営業部門が作成する各種レポート、資料とデータ連携を取るためのもの、帳票は固定伝票類(PDF)とExcelマクロによる自動演算処理をサポートしている。また機器連携機能はEDIをはじめ、生産実績や成分分析・品質検査機器のデータを取り込むためだ。
基盤となるデータベースは1583の機能を持ち、内訳は電炉製鋼業向け機能が728、鉄筋加工業向け機能が492、共通機能が363となっている(下図)。データ項目は1340テーブル・15214カラムだ。画面数とテーブル数がほぼ同期し、1テーブル当たり12〜13カラムということになる。
また先行して刷新した倉庫管理・運送・配車システムでQRコードを採用したことによって、トレーラーに棒鋼(鉄筋)を積載するとき、事前に「荷下ろし」計画を策定できるようになった。
「トレーラーの荷台を当社が用意し、トレーラーの駆動部が来たらその場で連結する。運送会社さんは積載時間を大幅に短縮できるし、当社にとっては迅速な配送が可能になるんです」
TCOは旧システム(AS/400ベース)の4分の1以下、季節変動を平準化した従業員の残業時間は概ね2割減、基幹システムに生産データや品質管理データが取り込まれるので、発注者ごとの製品トレーサビリティが実現した。
急がば回れ/備えあれば患い(迷い)なし
——すごいけれど、それは鞠子社長のトップダウンと、松村さんという優秀なプロマネがいたからできたことではないか。
になってしまっては、前後5回にわたって記事を書いてきた筆者も報われない。岸和田製鋼の事例から、「デジタル・トランスフォーメーション(DX)の前に済ませておくべきこと」を整理しておこう。
その1は、可変的要素を事前に確定しておくことだ。
岸和田製鋼は2012年に基幹システムのホストサーバー(30年使い続けてきたオフコンベースのアプリケーション)をオープン系サーバーに刷新することを決意した。しかし直ちに手を付けたのは製鋼・圧延設備の改修と製品の拡充だった。そのために岸和田製鋼は、結果として3年の年月をかけている。
システムを刷新したあとに生産ラインと製品を変更すれば、再び大幅なシステム改修に迫られる。二重投資を回避するだけでなく、システムの安定運用を確保するためにも、予想される可変要素を確定しておく必要がある。ことわざを引用すれば、「急がば回れ」ということだ。
第2は次期システムの目標を、経営の視点で策定したこと。
鞠子社長が掲げた「リアルタイム経営」を実現すべく、
①IT/ICTの技術革新に耐え得る柔軟性と拡張性
②長期的展望に立ったTCO(Total Cost Ownership)の低減
③ベンダー・ロックインからの離脱
——が骨子となった。
松村氏が立てたIT基本戦略のうち、オープン系サーバーとOSSの採用はもちろんだが、そもそも鞠子社長が松村氏を事実上のCIOとして招聘したことが、そのことを端的に物語る。松村氏を招聘したことが、ベンダー・ロックインから離脱する決定的な契機となった。
第3は、システム作りよりデータモデルと要件定義に時間をかけたことだ。
システム設計に入ってからサービス・インまで18か月のうち、半分に当たる9か月はシナリオドメイン、As-Is/To-Beの確定、概念モデル/業務別シーケンス図の作成、全体の俯瞰図、データモデルの作成などに充てられている。データモデルとシーケンス図が固まれば、プログラム作成は機械的に進めることが可能になる。
実際、KCTSはコーディング・レスで構築されている。「備えあれば患い(迷い)なし」と「始めよければ終わりよし」を足して2で割ったようなものだ。
IT発注・受注のあるべき姿が見えてくる
第4はPEXAという上流工程向けCASEツールを全面的に採用したこと。PEXAを開発・提供しているアトリス(安光正則社長、東京・用賀)は従業員50人ほどの小さなソフト会社だが、これまでも製薬会社や出版社など、大手SIerが"バンザイ"した基幹システムの後始末を引き受けてやり遂げた実績を持っている。
余談だが、製薬会社の基幹システムが難しいのは、新しい病理的知見や治療薬の臨床知見が1つ認定されるだけで、投薬の組み合わせ禁忌要件が激変するためだ。出版社の場合は煩雑な流通に加え、雑誌・新書・文庫・単行本など書籍の種類、出版社ごとに異なる再販・買切り・返本、例外の組み合わせがシステム化を困難にする。
そのような「組み合わせ爆発」を起こす基幹システムにも、PEXAは耐えることができた。シーケンス図を確定し、画面設計で項目と適用を設計できれば、PEXAのSVOステートメントでJavaプログラムが自動生成される。松村氏は「重厚長大型製造業の基幹システムに適用できるか自信はなかった」と語っているが、内心では「いける」と考えていたに違いない。
第5は新システムの評価を通じて、社内にアーリーアダプターを配置していった手法だが、これについてはすでに書いた。また新システムの評価に際して、経営・顧客・従業員の視点を重視したことも書いた。これにより松村氏ないしシステム部は、他の部門から「自分たちの仕事を楽にしてくれる」という信頼を得た。
現時点のオープン系KCTSはまだ「使い勝手がよくない」かもしれないが、「それでも仕事が楽になっている」という事実がある。この信頼感こそ、次のステップ、つまりDXへの足がかりになるに違いない。
もう一つ、意外に注目されていないのは松村氏が言う「ワンチーム」(発注者と受注者の関係)だ。筆者はこれを第6の要件に挙げておきたい。
この事例でいう発注者は岸和田製鋼、受注者はアトリスということになるのだが、岸和田製鋼のシステム部は2人(部長・松村氏と次長・西川勝和氏)しかおらず、外部のITベンダーからエンジニアを派遣してもらっていた。
今回のプロジェクトで松村氏は主にシステム設計と対外折衝、西川氏はデータやコード体系などシステム環境の整備と正規化を担当した。
「わたしはデータとコードの正規化、標準化にほとんどかかりっきりでした」と西川氏は語る。
2016年末までは並行してオフコンベースのシステムも運用していたから、とても開発の実務までは手が回らない。そこで詳細設計から画面設計、実装にいたるプロセスは、アトリスのエンジニアが松村・西川両氏と1つのチームを編成して、プログラム生成、テストを担当した。丸投げでも丸受けでもなく、一般的な委託・受託、委任・請負/派遣の関係でもない。
「製造業の基幹システムは、制御系の流れと事務管理の流れが同時進行で動く特徴があります。事務管理だけなら旧来のウォーターフォール型開発手法でいいのですが、岸和田製鋼さんの基幹システムは現場の方々に画面の推移を見てもらうため、アジャイル型開発手法を採用しなければなりませんでした。いろいろ例外的な措置で対応していただけた」とアトリスの安光社長は語る。
この関係は2019年/2020年の現在も続いていて、両者は新KCTSの機能改善と電炉製鋼業向けクラウドサービスの事業化に。共同で進める構えを見せている(下図)。それはITシステムの構築からスタートし、双方のビジネスモデルの変革に進展する可能性という意味で、新しい取り組みといっていい。
ITシステムの発注者と受注者がワンチームで責任と役割を分担する。ITエンジニアが少なすぎる発注者と、多勢のITエンジニアを抱え込んでいる受注者(ITベンダー)が、どのようなパートナーシップを結ぶのか。DXにとりかかる前に済ませておくべきことの1つだろう。(END)
電炉製鋼業向け基幹システム・クラウドサービス 構想図