工程表に「プログラミング」の文字がない
岸和田製鋼の新「KCTS(KISI-Con-Total-System)」は2016年12月に本番稼働した。
「基本設計からサービス・インまで18か月でした」
と松村氏は言う。
資料から1年半の工程(下図参照)を探ると、
●2015年7月から10月まで、ハードウェアの選定と並行して、As-Is、To-Beの分析、概念モデルの策定(要求分析フェーズ1)
●同年8月から12月まで各業務のヒアリングとシーケンス図(Sequence Diagram)の作成、対象マテリアルの確定(要求分析フェーズ2)
が行われた。
2015年の11月から翌2016年の3月が「設計フェーズ」だった。各業務シーケンス図から抽出される業務手続きをモデル化し、それぞれにデータ構造を定めていく。手続きの名称、製品や取引先の表記、システムが扱うコード、データの長さや空き(空白)の位置などだ。
それと並行して画面設計が進められた。画面を作るには、自ずから「項目」や「適用」を設定しなければならない。縦・横で入力エリアを決め、そこにルール(禁則も含む)を埋め込んでいく。これが「詳細設計・開発フェーズ」ということになる。
画面が出来上がったら、現業担当者に実際のデータを入れて使ってもらう。むろん画面の機能テストだが、「入り口」に不備があったらシステムは適正に動作しない。逆に「入り口」のテストがOKなら、データベースは円滑に更新することができる。データ構造はすでに設計されているし、業務とデータの関係、業務と業務の連携もシーケンス図で確定しているためだ。
フェーズごとの作業期間でいうと、画面設計と作成、テストが2015年12月から2016年7月まで、丸8か月と最も長い時間を要している。テストでOKが出た業務から業務全体のシステムテストを行った「テストフェーズ」が20166年5月から10月、導入準備やデータ移行など「導入フェーズ」が同年6月から12月となっている。
よく見ると、システム構築に必須の「ソフトウェア」ないし、「プログラミング」「コーディング」の文字がないことに気がつく。シーケンス図、データ構造、画面設計で「誰が」「なにを」「いつ」「どうする」が確定しているので、プログラム・モジュールを組み合わせるだけで機能が出来上がっていくわけだ。
「コーディング・レスでシステムを全面刷新したことになりますね」
と村松氏は言う。プロトタイプ手法やアジャイル手法が比較的容易に適用できるWebアプリケーションや情報系システムならともかく、重厚長大型企業の基幹システムがコーディング・レスで構築できるというのはちょっと驚きだ。
先行リリースした部署の残業時間が減った
ここまでの記述だと、岸和田製鋼の「脱オフコン」プロジェクトはスムーズに進んだように思われるだろう。松村氏は多くの語らないが、ご他聞にもれず、同社でも様ざまな課題、問題、障害があったに違いない。
例えば従来のシステムに慣れている社内の人たちから、「なんでシステムを変えるのか理解できない」「操作手順が変わるのはイヤだ」「分かんな〜い」といった声が上がったのではないか。社内の抵抗や反発をどう収斂させるかは、システム関係者共通の課題だ。
その解決策として、社長以下、経営幹部からのトップダウンは反感を抑え込むことはできても、場合によってはIT担当者が恨みを買うことになりかねない。最も効果的なのは、現業の各部門にアーリーアダプターを配置し、彼・彼女たちの行動が無言の説得力を発揮する方法だ。
実際、その手法を意識していたか、していなかったかは別として、岸和田製鋼(ないし松村氏)もよく似た手順を踏んでいる。2016年の7月、製鋼部門の金属業務部に先行的に新システムをリリースし、評価してもらったのだ。その評価には、システム(画面)の操作性ばかりでなく、残業時間や社内外関係先との事務効率など、経営・顧客・従業員の視点を盛り込んだ。
操作に習熟していた旧システムと比べると、新システムの操作性は分が悪い。しかし金属業務部の残業時間は新システムのサービス・インから2〜3か月後に減少し始め、6か月後の前年同月比は、同部の就業者1人当たり15時間以上の圧縮(削減)となっていた。
総合すると、「使い勝手は悪い(慣れていないため)けれど、効率はいい」という評価だった。バッチ処理からリアルタイム処理になったため、システムの受付終了を待つことなく次の業務(処理)に移れるのだ。
新システムの改善と現業部門の習熟度で、操作性・使い勝手は向上する。リアルタイム処理で他部門との連携が円滑になれば、電話やメールでの確認が減る。現業の同僚が「新システムで残業時間が減った、業務ストレスがなくなった」と評価したのだから、他の部門があえて反対する理由がなくなった。
各業務のシーケンス図から全体を俯瞰する
技術的な問題もあった。
一つはシステム刷新に着手する前段階で、戦略指針に「OSSを標準採用」と謳ったものの、どのような開発手法、開発フレームワークを使うかだった。COBOL系ないしウォーターフォール型のCASEツールや設計手法はあるが、Java/オープン系となると、コレというものがなかなか見つからない。
ただし、繰り返しになるが、この課題はPEXAを評価する過程で解決した。PEXAで要件定義し、「SVOステートメント」を確定させることができれば、PEXAがJavaプログラムを生成してくれるのだ。
「もう一つ、大前提となる問題がありました。それは、どこまでシステム化するかでした」
と松村氏は言う。As-Isをシステム化するのは当然として、ヒアリングで出てきた帳票の要望をどこまで新システムでカバーするか。
様ざまな帳票というのは、各種の統計レポート、契約の前段階で使用する資料、経営会議向け資料などだ。いずれも基幹業務のデータが関係する。
「社長と相談して基幹システムの範囲を決めました。レポートや資料は基幹システムのデータをCSVで出力し、エンドユーザーがExcelで作れるようにしたんです」
その判断の基礎となったのが、前出のシーケンス図だ。
言うまでもないことだが、シーケンス図は業務フローと業務手続きを時間軸で表記したもので、UML(Unified Modeling Language)で一般的な「業務の見える化」手法とされる。岸和田製鋼ないし電炉製鋼業でどのような仕事がどのような手続きで進められているか、現業担当者のヒアリングを通じて整理していく。
営業、生産(製鋼・圧延)、原料調達、品質管理、倉庫・出荷、フック/フープ加工、配送・配車、経理といった業務ごとにシーケンス図を作成する。それぞれがどのような位置関係にあって、どのような情報が受け渡され、あるいは共有されているか。それが分かれば全体の俯瞰図を作ることができ——実際は業務シーケンス図と俯瞰図は同時進行で策定されていくのだが——基幹システムがカバーすべき範囲が明確になるというわけだ(下図)。
【続きは→】岸和田製鋼に行ってきた⑤ DXの前に済ませておくべき6つのこと