日本の将来－－－４．変化への対応例(３)

前回の「３）深夜の自動オペレーション」から続く。

４）次期システム開発の体制つくり

「紺屋の白袴」に陥ったシステム部門の改善は、深夜オペレーションの無人化だけではなかった。最も大きな改善が必要だったのは、システム開発の方法だった。

ＳＥ(システム・エンジニア)の育成

今から４０年も昔の当時、システム開発担当者の第一要件は、プログラミングができることだった。実際にシステム開発に所属する社員の学歴を見ると、大卒と高卒、専門はさまざまだったが、共通事項はプログラマミングができることだった。そこには、ＳＥとプログラマーの区別もなく、プログラマー＝ＳＥとの誤解があった。

そこで、ＳＥに必要な要件として、プログラミングだけではなく、次の３つの能力を身に付けるように指導した。プログラミングは技能の問題、次の３つは応用力の問題、前者は学校教育で十分、後者は学校ではなく実務で身に付ける能力である。

ａ．コンサルタントとしての能力

　現状分析と実行可能な解決法を提案すること

　コンピューターの利用部門が何をシステム化したいのかを聞き出すことが大切である。このため、ＳＥの要件として、インタビュー(聞き取り＝ヒアリング)の能力を重視した。人に接するのは苦手、画面に向き合うのは得意、それではプログラマーは務まるがＳＥは務まらない。

　また、インタビューの相手は、社内の業務担当者だけでなく、時には関係会社の人々とのインタビューもある。特に、外注先の人々に対する横柄な口のきき方は論外、しかるべき礼儀をわきまえるように指導した。

ｂ．エキスパートとしての能力

　ハード、ソフト、データ通信、それぞれの技術とコストに精通すること

　技術的な知識だけでなく、ハードやソフトの実勢価格、システムの規模と開発コスト、期待メリットを推定できるコスト感覚をＳＥに求めた。CheapnessとEconomyの違いを理解するエンジニアを育てたかった。【参照：３）利益管理、グローバル工場－－－機能の階層（６）(2012-03-11)】

ｃ．業務改善の旗振り役としての能力

　業務改善の阻害要因を一つずつ合理的に克服すること

　業務システムの開発は、単に手作業の機械化ではない。システム＝体系＝ルールであり、新システムは仕事のやり方を改善するために開発する。したがって、ＳＥは業務改善を利用部門に浸透させる旗振り役である。この能力は、関係者に対する説得力と熱意でもある。

以上、ａ、ｂ、ｃの実地訓練は、クリーン・コンピューター作戦に続く次期工場システムの開発で実践した。

ＳＥにとっては、プログラミング言語の知識・経験は必須であるが、プログラミングだけがＳＥの仕事ではない。そこで、ＳＥからプログラミング作業を切り離した。

ＳＥの最も大切な仕事はシステムの設計である。その設計内容をシステム仕様書として、概要設計書、ファイル関連図、コード表、プログラム説明書などに展開する。このうち、プログラム説明書をプログラマーに渡して、プログラムの作成を依頼する。

プログラム説明書にもとづいて作成するプログラムは、だれがどこで作っても同じである。当時は、プログラムの外注はまれであったが、外注に耐えるしっかりとしたシステム仕様書づくりをＳＥの目標にした。

プログラマーの育成

プログラミング作業を担当するプログラマーの希望者を社内で募集、アメリカのプログラマー適性検査(日本語版)で７人の候補者を選び、電算室に異動した。なぜか７名はすべて女性だった。もちろん、クリーン・コンピューター作戦の一環として、教育はコンピューター・メーカーの入門コースから上級コースへと進み、社内の実機訓練を交えてプログラマーを育成した。幸い、非常に優秀なプログラマーが育ち、システム開発とメンテナンスの効率が著しく向上した。

優秀なプログラマーは、ＳＥの質の向上にも貢献した。たとえば「あの人のプログラム説明書は甘い」とか「変更が多い」とか、さまざまな意見が女性プログラマーから出るのでＳＥもそれなりに努力した。

これはクリーン・コンピューターを終えた後の話だが、ＳＥの質の向上でシステム仕様書の内容も充実し、プログラミングの外注が可能になった。今日では当り前の話だが、プログラミングの外注により電算室のシステム開発能力はさらに向上した。あれから４０年、歳月は一瞬のうちに過ぎ去り、日本のオフショア(Offshore＝海外の)外注先は、東南アジア諸国からアフリカに広がった。(ただし、筆者はアフリカ、たとえばルワンダの開発現場を見たことがない)

技術管理課の設置

システム開発を効率的に進めるために、技術管理課を新設し、次の５つの項目を目標にした。

１．システム開発手順の標準化と品質管理

２．データベース管理ソフトなど、新しい技術の評価と導入

３．外部教育やセミナーによる計画的な社員教育

４．プログラマーへの仕事の割当てと作業管理

５．データ通信網の管理とオンライン化の促進(O/L画面やバーコードでデータの即時処理)

ここで特記すべきことは、この頃から電話回線を管理する社内の縄張りが変化し始めた。従来は、電話回線の契約と社内電話機の配置は総務部門の管轄だった。しかし、電話回線による通話(電話機)とデータ通信(コンピューターやワークステーション)が複合するにつれて、総務部にもコンピューターの知識が必要になり始めた。同時に、社内の電話交換機も電磁式から電子式に変化し始めた。

ここで、話題はクリーン・コンピューターから離れるが、ＩＴ(Information Technology：情報技術)について筆者の見聞を紹介する。

７０～８０年代のアメリカでは、多くの企業はシステム部をＩＳ(Information Systems Department＝情報システム部)と呼んでいた。しかし、９０年代半ばにはシステム部門名がＩＳからＩＳ＆Ｔ(IS & Technology)に変わり始め、いつの間にか、ＩＳ＆ＴからＩＴが派生した。それは、次のような時代の変化を反映している。

８０年代：大型汎用コンピューターを使ってコボル(言語)の大型システムを開発・・・名刺の部門名＝ＩＳ

９０年代：クライアント/サーバー型システムにより大型システムをダウン・サイジングした時代・・・ＩＳ部門はデータ通信技術の知識と実績を強化した。技術(Technology)を強調するため、部門名のＩＳにＴ(Technology)を付加・・・名刺の部門名＝ＩＳ＆Ｔ

２０００年代：ＩＳ＆Ｔからいつの間にかＩＴと言葉が派生・・・ＩＴとＩＳ＆Ｔの違いはよく分からない。

【参照：５）９０年代のアメリカ、日本の将来－－－２．日本と欧米との比較(２)(2013-08-10)】

次回、「５）社内外との人事交流」に続く。

日本の将来－－－４．変化への対応例(２)：クリーン・コンピューター作戦

４．変化への対応例（１）から続く。

（４）クリーン・コンピューター作戦

１）最小限のオペレーション

クリーン・コンピューター作戦は、システム部門の大掃除(クリーニング)を意味する作戦、約１年にわたって実施した。その目標は、現行システムの棚卸と整理統廃合、さらに仕事のやり方を変更して次の時代に備えることだった。

当時、システム部門の仕事は、システムの開発と開発したシステムの運営だった。このうち、新規開発はすべて凍結した。

他方、システムの運営のうち、システムの利用部門からの業務データ受付、データ入力、システム・オペレーション(運転)、出力配布は通常とおりとした。しかし、現行システムのメンテ(メンテナンス)は必要最小限にした。もちろん、日常業務に支障をきたさないように、事前に利用部門と話し合った。

２）現行システムの棚卸と文書化

会社の成長とともに次々と開発したシステムは、いわば雨後の竹の子のような状態になっていた。当然、システム開発はプログラム作成に追われ、システム仕様書の作成はおろそかだった。システム仕様の大部分は開発担当者の頭の中、いわゆる属人的なシステムだった。

現行システムの棚卸と文書化の目的は、雨後の竹の子の整理統廃合と属人的なシステムからの脱却だった。属人的なシステムの前提になる終身雇用は、労働環境の変化をよそに永続するとは思わなかった。

整理統廃合のために、現行システムをリストアップした。各システムのモジュール(機能単位)別に、開発時期、担当者、プログラム言語、大きさ、仕様書の完成度、現在の不具合点、近い将来に予想する大きな業務変更を調査した。なお、システム仕様書は、概要設計書、ファイル関連図、コード表、プログラム説明書、操作手引書などの書類である。

さらに、各システムが稼働するコンピューターに関する項目もチェックした。

◇ハードとＯＳ(オペレーティング・システム：基本ソフト、例=パソコンのWin.７や８)のライフサイクル(寿命)

　・・・コスト・パフォーマンスを改善した新機種/新ＯＳの評価。新旧システムの互換性をチェック

◇プログラミング言語のライフサイクル

　・・・アセブンラーやコボル、その他特殊言語の将来性。

　　　現在では、アセンブラー(６０～７０年代の言語)やコボルを知る人は高齢化とともに激減している。

このリストで、システムを１）当分変更せずに運営するシステム、２）次期工場システムに吸収するシステム、３）現行のまゝ手を加えずにできるだけ早く新システムに切り替えるシステム、に分類した。

これら３つの分類のうち、１）に該当するシステムを対象に、優先順位の高い順にシステム仕様書の整備を進めた。

仕様書の日本語は、執筆者以外の人が読んで理解できる文章、率直な(Straightforward)短文、１文章８０文字以内を目安にした。また、数千行にわたるプログラム(コボルやアセンブラー言語)は長くても１０００行以下、できれば５００行程度に分割した。日本語文章とコンピューター・プログラムの短文化は、開発した人以外の人が効率的にシステムをメンテできるようにするためだった。【参考：筆者のコメント、１．「文章力の基本」阿部 紘久、グローバル化への準備－－－英語と他の言語（５）2013-01-10】

クリーン・コンピューター作戦で一番厄介なシステムは、一見、最先端に見えるオンライン・リアルタイムの在庫管理だった。この頃は、リアルタイム制御にはアセンブラー言語のプログラムが必要だった。しかも、旧世代の磁気コア・コンピューター(レンタル費＝850万円/月)で稼働するシステムだった。

３～４年で技術革新が進む７０年代半ばでは、６０年代半ばのハードは典型的なレガシー・システムだった。この磁気コアの製品は、メーカーでも足手まとい、修理が困難なため「さわらぬ神にたたりなし」とばかり本体の移設にも細心の注意を払った。【参照：図４　コアアレー(Core Array：磁気コアの配列)、グローバル化への準備－－－コンピューターの知識（２）2012-07-25】

この在庫管理システムの再開発を８２年にようやく終えて、新しいシステムに置き換えた。博物館入りするような６０年代の磁気コア・コンピューターは、８０年代のＬＳＩ(大規模集積回路)の時代まで実在した。

この例のように、コンピューター・システムではコスト・パフォーマンスの良い新型機に乗り換えようとしても、ソフトが足を引っ張ることがある。間もなく社会情勢が激変する少子高齢化の時代では、コンピューター・システムの扱いには十分に注意したい。少子化の中、日本語の仕様書を理解し、かつ、コンピューター言語に明るい人材が、その時代の現行システムのメンテと新規開発を担う。その人材はだれか？人間か機械か、大きな課題である。

３）深夜の自動オペレーション

事務所や工場のシステム化を推進するシステム部門は「紺屋の白袴」に陥ることが多い。

たった２台の汎用コンピューターの２４時間オペレーションに十数人のオペレーターが必要だった。深夜から翌朝までの第３直は２～３名、少なくともこの当直を無人にしたかった。

オペレーターを１人に削減することは可能だが、深夜の１人当直には抵抗があった。２人ならば、もし１人にトラブルがあっても、他の１人が助けを呼ぶこともできる。このため、１人当直はダメとした。

試行錯誤の末に、警備保障システム(室温管理と自動消火と侵入防止)の導入で深夜のオペレーションを無人化した。

その方法は、古い技術的な話になるのでここでは省略する。しかし、最大の難問は、磁気テープとディスクパックの取り換え、および高速プリンターへの紙の補給だった。いずれも、単純作業だが無人化には苦労した。

方法論はさておき、その時代の利用可能な技術を応用すれば、かなりの自動化は実現できることを学んだ。もちろん、安全性と経済性の評価もクリアーした。また、コスト削減以上に人材の有効活用の観点も忘れてはいけない。(例：オペレーター⇒プログラマー)

なお、余談になるが、当時の工場では、単純作業の自動化では５００万円という目安が頭の中にあった。作業者１人を削減する自動化機器(ロボット)が５００万円以下であれば検討に値するという意味だった。この５００万円は、作業者１人の賃金、時間外、諸手当、ボーナス、退職金、福利厚生費、その他経費を年間コストに換算した平均値だった。

ただし、実際のケースでは、新規投資のライフサイクルを通して経済性、運用性、技術的実用性(Economic、 Operational & Technical Feasibilities)を検証する。もちろん、運用性と技術的実用性では安全性と信頼性も検討する。原子炉の話になると、机上の空論も多く疑問がある。

また、５００万円の話に戻るが、この論法では１人１分間のコストは約４０円になる。１０人が１時間会議したとき、そのコストは１０ｘ６０ｘ４０＝２４,０００円、会議後に皆で今の会議はその価値があったか？と冗談を言い合った。

次回、「４）次期システム開発の体制つくり」に続く。