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