#3299 オモチャからわずか25年で汎用大型機を消滅させつつあるパソコンという怪物 May 23, 2016

<更新情報>
5/25　0時30分　92年に書いた文書で確認し、ラボ検査システムとして導入したUNIXマシンであるRS6000の条を追記
　　　　　1時　HP-67, HP97画像追記、<余談>追記

　1970年代から1990年代にかけて、25年ほどのパソコンの性能アップの状況を整理して、koderaさんのブログへコメントしました。

　koderaさんは（東大工学部機械工学⇒大学院工学系研究科機械工学専攻⇒）富士通でコンピュータの開発をしていた方です。富士通の後、シャープでワープロ「書院」の開発も担当しました。「書院」はベストセラーだった富士通の「OASIS」の後に出てきて、ずいぶん売れました。
　koderaさんはメーカ内部の事情をいろいろと書いてくれています。今書き残しておかないと、あの時代に開発の仕事に携わった人がこの世から次々とおさらばしていますので、その時代に生きていた人でないと書けない泥臭い話も含めていろいろなことがわからなくなります。大学生は研究開発志向が強い人が多いようですから、実際の開発現場がどのようなものであるか、参考になれば幸いです。コンピュータ開発をめぐる製造メーカ側の内部事情はkoderaさんのブログをお読みください。

　わたしは1979年から1999年までさまざまなタイプのコンピュータのユーザでしたから、ユーザ側から見た20年年史を語りたいと思います。
　産業用エレクトロニクスの輸入商社へ1979年に入社するとすぐに逆ポーランド記法の科学技術計算用プログラマブル・キャリュキュレータ（HP社製、HP67とプリンタ付のHP97）とCOOLというダイレクトアドレッシング言語で動くオフコン（三菱電機）でプログラミングを独習し、1980年にコンパイラ言語の汎用小型機（三菱電機）のプログラミング言語（PROGRESSⅡ）もマスターしました。IBMのRPGⅡと同種の言語でした。最初に独習したのが科学技術計算専用の言語、次に事務系のアッセンブラ級の原始的な事務系言語と事務系コンパイラー言語を学んだということになります。事務系の言語は3日間の講習に行かせてもらいました。仕事上必要に迫られて修得したプログラミング言語は三つ。
　①逆ポーランド方式の科学技術計算用言語
　②COOL：　三菱電機のオフコン用言語　12桁の数字によるダイレクトアドレッシング
　③PROGLESSⅡ：三菱電機汎用小型機用のコンパイラー言語
　90年代半ばにパソコン用言語の「C++」を学びたかったが、仕事上の機会がありませんでした。
*HP67, HP97画像
HP-67

HP-97

（入社して、電卓を使って統計計算をして経営分析をしていたら、1ヵ月後に社長が米国出張から戻ると机の上にHP67がありました。秘書に訊くと「社長がebisuさんにって、仰ってました」との返事。この計算機はカードにプログラムやデータが記録できます。標準の統計計算は頭の部分にROMのスロットが二つあって、そこに統計アプリROMを差し込みます。統計アプリと数学アプリを使っていました。HP97は入社して2.5ヶ月後に社長が米国出張で買ってきてくれました。HP97は当時の価格で22万円もしましたから、ずいぶん気前の良い社長でした。作成したプログラムや入力データをプリントアウトしてチェックできるので、ずいぶん楽になりました。「5ディメンション25ゲージの経営分析用レーダーチャート」に使う数値を計算するのに丸1日かっていましたが、この計算機のお陰で30分で完了、オフコンのプログラミングに手を出す余裕やシステム開発関係の専門書を十数冊読む余裕が生まれました。）

　産業用エレクトロニクス輸入商社へ入社してすぐに、メンバーが役員と部長そして課長2名の6つの委員会に属して、そちらの仕事をほとんど一人でやっていました。財務委員会、資金投資委員会、長期計画委員会、収益見通し及び経営分析委員会、為替対策委員会、電算処理委員会の6つ。利益重点営業委員会だけメンバーではありませんでしたが、為替レートの変動に合わせて円定価表を作成・四半期ごとに改訂するというシステム化課題が明確になっていたので、メンバーの営業課長のE藤さんとわたしの仕事になっていました。
　これらの7委員会の目的は、具体的なデータ分析をして、会社の強みと弱点を洗い出し、財務体質と利益構造を変革する具体的な提案をオーナ社長の関さんにすることでした。3番目までの委員会は社長自ら委員長として指揮しました。20代後半にこういう大きな仕事を課題を明確にして担わせてくれた関周社長に感謝です。大きな仕事をいくつもこなすチャンスがあったので、仕事のスキルが飛躍的に上がってしまったのです。
　この会社では6つの委員会の仕事と予算編成と予算管理がわたしのルーチン業務でしたが、1年後にはコンピュータの管理とシステム開発の仕事が追加されました。月のうち半分くらいは終電で帰宅という状態でしたが、大きな仕事を一人でいくつも任され、スキルがガンガン上がっていくので楽しかった。
　1984年に規模が10倍ほどの企業である国内最大手の臨床検査センター、SRLへ東証Ⅱ部上場準備要員として転職し、当時国内最大クラスの汎用大型機（富士通、買い取り価格10億円、1台は買取、1台はレンタル、計2台。3MegaのMM増設に5000万円）を使って、仕事の半分くらいの時間を投入して統合システム開発をしました。1984年末まではシステム開発が仕事の半分でした。残りは予算編成と予算管理、そして大きな費目のコストカット提案がわたしの業務でした。
　その後の大きなシステム開発は、千葉の臨床検査子会社のラボシステム開発に親会社の関係会社管理部として1992年に関わったのが最後です。仕事の精度と生産性を4倍に上げることで簡単に黒字転換できました。受付･報告系にIBMのAS400（IBMのRDBマシン、システム38の後継機である、ユーザー部門に使い勝手の良いマシンである）とラボ検査系にRS6000（IBMのUNIXサーバー）を使用しました。ラボシステムはRDBマシンでは無理、検査機器とのインターフェイスや制御をやるにはUNIXマシンが最適でした。それまで1台のホストコンピュータによる処理だったのを、2台の汎用小型機で用途別に分散処理に替えました。
　（資料：1992年8月20日付けRef.#SM(I)-303）

　この後のシステム関係の仕事は1990年代後半に帝人との臨床治験検査合弁会社でシステム部門がわたしの管理下にあっただけで、仕事の指示はしましたが、取締役ですからわたしが実務を担うことはなくなっていました。このときには業務用パソコンを数台をラックにマウントする形のサーバー・コンピュータを使用してました。ディスクもテラバイト単位でした。イントラネットが整備され、パソコンが業務の中心にありました。
　職位が上がるのは権限が大きくなってやりたいことがやれるので、うれしいことではありますが、マネジメントが仕事の主体になり、実務を直接担当できなくなるという寂しい話も裏側にはあります。仕事上の役割が違ってしまいます。サーバがパソコン中心のシステム構成になったところからは、わたしはシステム開発や管理の実務にタッチしておりません。ずっとやっていたかった。SRL八王子ラボで購買課でシステム管理と機器購入担当、その後の89年に学術開発本部スタッフとして開発部（製薬メーカとの検査試薬の共同開発及び共同開発業務の標準化担当、米軍との母体血によるトリプルマーカ検査（MoM値：出生前診断検査）システム開発、慶応大学病院と出生前診断産学共同プロジェクトのコーディネイト（製薬メーカ2社に3種類の検査試薬各々3000テスト分を無償提供してもらいました。））、学術情報部（海外のお客様のラボ見学案内担当及び臨床病理学会との臨床検査項目コード標準化に関する産学共同プロジェクト）と精度保証部（米国制度管理基準CAPライセンス関係業務お手伝い）の三つの部門それぞれの仕事を担当していましたが、本音は一度自分の手で検査業務をしてみたかったのです。でも、やらせてもらえませんでした。入社してすぐに、2年間全社予算編成を統括していたので、現場の仕事をさせてくれません、東証Ⅱ部上場準備要員としてとくにシステム開発能力に期待して35歳のわたしを雇ったのですから、当然といえば当然ですが、臨床検査業の会社で検査を自分の手でやらないとわかった気がしなかったのです。原価計算システムでそれまでの学説をひっくり返すような画期的な利益思考のシミュレーションシステムを構想していましたから、3ヶ月ごとに4種類の検査部門で検査業務をやってみたかったのです、機会がありませんでした。

　1984年当時は富士通の汎用大型機はCOBOLで動いていましたが、外部仕様書やプログラミング仕様書を書き、新しい事務フロー・デザイン、つまり外部設計をしただけで、COBOLでコーディングをやる機会がありませんでした。SRLにはシステム開発に失敗して使えなかったDECの最新（1984年当時）ミニコンも2台あったし、腕を磨くために自分でプログラミングをしていろいろ試してみたいことがありました。事務用の言語では統計計算処理が絡むシステム開発に使い勝手の点で限界を感じていました。だからC言語でDECのミニコンを使ってみたかったのです。汎用大型機の事務用言語で処理したデータを使って、経営分析用の統計計算処理をミニコン側でやる、そういう処理系を考えていました。結局は、パソコンの性能アップで、ラックにマウントされた数台のサーバの並列処理で全部のデータ処理が扱えるように（1990年代後半）変わってしまいました。
　1984年の統合システム開発は、わたしが会計システムと支払管理システム、固定資産管理システムの3つの外部設計と実務設計を担当し、内部設計とプログラミングはNCDさんへ委託。当初はCOBOLでつくったシステムを翌年（1985）にEASY-TRIEVEという簡易言語で書き直しました。そちらの方が処理時間が短縮できました。プログラミング効率がよいだけでなく、マシン語にコンパイルしたときにコンパクトになるような高性能の言語だったようです。実際にバッチ処理時間が短縮できました。
　84年4月に開発をスタートさせ、12月から本稼動した統合システムは、以前からあった業務システム、ラボシステム（臨床検査サブシステム）に、新たに原価計算システム、購買在庫管理システム、販売管理（請求）システム、予算サブシステム、会計システム、支払いシステム、固定資産管理（投資案件と予定減価償却費シミュレーションも含む）システムを構築し、これら9個のシステムがインターフェイスするものでした。後ろの3システムと会計情報システムと各システムとのインターフェイス仕様書作成もわたしの担当でした。1週間で書き上げました。
　当時はまだパソコンが仕事で使えるほどの性能ではなかったので、汎用大型機でのバッチ処理システムでした。ワープロ専用機が出て4年目くらいのことです。最初のころのワープロ専用機はA4版が縦に表示できるもので、1980年ころ200万円もしていたのです。10年で1/20に価格が下がったことになります。1980年当時は順番待ちで営業事務に使っていました。お客様への見積書や提案書作成用でした。わたしは使わせてもらえず、手書きで文書作成をしていました。四半期ごとの経営分析レポートも、さまざまな統計グラフも、納期管理システムの外部設計書も、外貨決済と為替予約を含む外国為替管理システム仕様書も、何から何まで手書きで資料をつくっていました。
　経営分析の計算業務は1979年から科学技術計算用のHP67とHP97を使って統計計算プログラミングをしてました。標準偏差を利用したモデル計算に基づく、5ディメンション・25ゲージのレーダチャートも手書きでした。この2台の計算機がなければ仕事量は半分以下だったでしょう。この経営分析システムはSRLで関係者管理部へ異動したときに、EXCELに載せ替えました。子会社や買収対象の臨床検査会社の評価に使いました。じつに強力でした。
　富士通のワープロ専用機OASISを自費購入して仕事に使い始めたのが1990年ころのことです。生産性が上がって、文書作成量が5倍くらいに増えました。思いつくままにタイピングしてから後編集（あとへんしゅう）できるので、構成を考えずに書き進めるからだろうと思います。タイピングしているうちに全体の構成が頭の中でまとまりだします。
　20歳中ころに修士論文にドイツ語文献を引用するために、ドイツ製かスイス製のオリンピア*という欧文タイプライターを購入してタイピング・トレーニングをしたことがあったので、10本指で高速タイピングが可能でした。90年に41歳、20代の人が「ebisuさんどうしてそんなに速いのですか？」と吃驚（びっくり）していました。同じくらいの年頃に人は左右1本指でキーを叩くような人までいましたから。ビリヤードや珠算と同じで、こういう手の技は基本に忠実なトレーニング（毎日30分ほど、3ヶ月くらい）やるのが、効果的です。いまでは高校でタイピングのトレーニングをしているようです。ワープロ検定というのがある、便利になりました。

*OLIMPIA　typewriter　画像　⇒これです！頑丈なタイプライターでした、見た目の堅牢性と色とフォルムの美しさからインテリアとして小道具に使えます。
http://www.mbok.jp/item/item_339311138.html


　思いつくままに書いているので話が前後して申し訳ありません、それぞれに年を入れておくので、時間軸を行ったり来たりするのはご寛恕ください。
　最初にパソコンに出会ったのは1979年でしたが、コモドール社製のもので、まるでオモチャでした。キーを押すと、いくつか持ち上がって元に戻らないような代物でした。産業用エレクトロニクス輸入商社の技術部の中臣さんという課長に教えてもらいました。画面にコマンドを表示させて、数十ステップのプログラミンをするだけ、こんなものは20年たっても仕事では使えないと思いました。国産のワープロ専用機のキーボードは実に性能が良くて、キーに不具合なんで起きたことがありませんでした。日本製品はメカニカルな部分は比べ斧にならないほど品質がよかった。
　でも、会社の技術部にはHP社のマイクロ波計測器制御用の高性能パソコンが何台も転がっていました。双方向のインターフェイスバス（GPIB）が標準装備で150～200万円ほどしていました。4色プロッターが200万円でした。ほしかったのですが、80年ころは買ってもらえませんでした。

　そのころからCPUの速度とMM（Main Memory）に使われていたROMやRAMの集積度が2年で4倍に指数関数的に上がっていたのですが、ハードウェアの高性能化に対応したソフトが開発されて、WORDやEXCELが出てきて、ワープロ専用機が15年後に消滅するとは、誰も考えられなかったでしょう。指数関数的な変化はどこかで人間の想像力の限界を振り切ってしまうようです。その変化はこれから30年間、想像を絶するほど人工知能の性能をアップしてしまうでしょう。ハードウェアの性能アップとソフトウェアの性能アップと、ビッグデータが「三種の神器」となっていますが、もっと強力なアイテムがこれから30年間のうちに現れます。それが何かを人間の知能が予測することができない。人類が滅亡しかねないほど怖いことになります。

　koderaさんは富士通と第五世代コンピュータ開発技術研究組合で実際の議論に加わっていた人です。面白いですから、このころのコンピュータの加速的な性能アップに興味がある方はkoderaさんのブログをお読みください。
　米国にはスティーブ･ジョブスやビル･ゲイツに匹敵する有能な人たちが輩出していましたし、日本でも似たような状況がありました。でも、結果が違います。koderaさんはその原因にも言及しています。

　記事のタイトルをリストアップしておきます。クリックするとkoderaさんのブログへジャンプします。

　ebisu先生への返信


　スモールビジネスコンピュータ登場前夜の状況
　

　自分の記事が面白い

　システム工学は説得工学

　新任課長と新任研究部長の思い出

　書きたいことは２ケタ上

　新しい事業部長

　シャープの独身寮の思いで　

　オフィスオートメーション機器開発時代

<余談>
　産業用エレクトロニクス輸入商社時代から、自分が発信した文書は管理番号を振り、発信日付を付して、日付順にファイルしてあります。それは臨床検査会社SRLへ入社してからも同じですから、必要のある都度、ファイルから取り出して確認できます。
　SRL時代の分だけで8cmの暑さのファイルが6冊ほどあります。産業用エレクトロニクス時代の発信文書はほとんど棄ててしまいました。


　　　　　 70%　　　　　　　20%　　　　　　
　

コメント 6

　私はアプリの天才、今はなき中村洋四郎元富士通のシステム開発部隊の責任者に請われて、アプリの時代が来る、統合経営システムをしてみろと言われて富士通に入社しました。
　なお、余談ですが、中村さんは私に本の再販を許可した直後、完成品を届けようとした日の数日前にお亡くなりになってしまいました。予定通りに、実際より１月早かったら直接届けられたのに。宿命だったのでしょう。
　それから50年近く、中村さんがなくなった今、スマホもWindowsもアプリが命の時代になりました。日本はアプリは遅れました。何かと言えば儲かるゲームばかりです。私は50年近く、アプリから内側に入っていき、行き詰まりまたアプリに戻りつつありました。この風潮が嫌いです。本当のアプリで各人が勝負して欲しいから。
　でも、今はアプリを開発する技術もノウハウも私では足りません。できるのは要求仕様と事業提案だけになりました。
　でも学校人は誰も私の提案や要求など聞いてくれませんでした。一生懸命に10年ずつやった女子大でも高校でも。要するに自業自得、信用されなかったのです。中村さんの言う通りにしなかった罰でしょう。
　アップルもスマホも我が世の春のアプリの時代なのに私は何もできませんでした。わから仕方なしに高校生や大学生のために、悪戦苦闘していた時代の本をリライトしています。実技ができる鈴木さんのお蔭です。
　今日も昔のUNIXの素晴らしい研究者の先生に二人で本を売り込んできました。大学で40年しているのです。その先生に鈴木さんは気に入られたようです。
　偶然ですが、その大学は鈴木家のお近くです。天は味方してくれたのかも。今後は彼は就職支援で大学を訪れるようです。
　これからはなりゆきなど、ebisu先生のこのブログに書いてくれそうです。当方は何もしないでも話は進みそうです。あり難いものです。南無阿弥陀仏。
by tsuguo-kodera (2016-05-23 16:56) 

koderaさん

中村洋四郎さんは1970年代前半に、アプリの時代が来ると予想し、経営統合システムの構築を提案していたのですか。10年ほど早すぎましたね。
当時の日本にはその分野の専門家がいません。わたしがいくつかのサブシステムを開発して、経営統合システムが見えてきたのが1982年ころでした。

そのころは日本にはまだ会計情報システムを扱った専門書すらありませんでした。
簿記知識や業務知識をフル動員して、会計情報システム、給与情報システム予算管理システム、納期管理及び仕入れ処理システム、為替管理および外貨決済システム、円定価表システムなど、2年間で個別に開発したシステムを統合するつもりでした。1983年、産業用エレクトロニクス輸入商社での話です。
1984年に転職して業種の異なるSRLで担当することになりました。ついていました。
そのときでも、使えた専門書は米国で出たばかりの会計情報システムに関する600ページほどの本だけでした。
当時は日本ではまったく研究されていません。
無理ないことだったのです。

コンピュータシステムは理系のテリトリー、会計や原価計算、購買在庫管理も文系の専門分野の仕事でしたから、両方の専門知識のある人材がいなかったのです。
米国は公認会計士に理系出身者が少なくありませんから、経営情報システム開発に必要な人材がたくさんいます。

文系・理系にわけている教育システムがそもそも時代遅れなのです。
文系大学へ進学する人に数Ⅲ履修を認めなければ、経営統合システムのようなアプリ開発を担える人材が育たないと思います。

1984年に開発した統合システムは作りこみですが、パッケージ化を意識していました。
輸入商社向けパッケージシステムは必要なサブシステム開発を経験済みでしたから、業種の異なる臨床検査業向けのパッケージシステムとあわせれば、統合経営システムの汎用パッケージ開発が可能だと考えていました。だから、利益志向の強いシミュレーションシステムを含んだ原価計算理論の研究をしていたのです。

この分野では日本は決定的に遅れをとりました。必要な人材がいなかったからです。

1980年代半ばに、統合システム開発の別会社を立ち上げる提案をすべきでした。輸入商社向けパッケージと臨床検査業向けパッケージ販売で3年位食いつないでいるうちに、強力な汎用パッケージの開発は可能だったでしょう。
日本市場で海外勢に遅れをとることはなかったのだろうと思います。
理系と文系がクロスオーバする分野はたくさんありますから、両方の領域を自在に行き来できる人材育成を学校教育の場でやるべきです。高校からですね。
7～8時間授業で文系と理系が相互乗り入れができるような選択科目メニューを設定すればいい。
公立高校でできないなら、私立高校が先駆的にやればいい。
by ebisu (2016-05-23 22:46) 

　中村師匠が10年ほど前に言っていたことを思い出しました。ERPはドイツにやられた。追いつくのは難しいと。彼はSE会社の良い統合システムが難しいからでしょうが、富士通系の流通関係の、数多のSE会社のために、富士通常任顧問になっていた中村さんが講演会に使っていた資料を頂きました。
　私は私のブログで「中村」さんについてはたくさん書きました。中村で検索してもたくさん出てきます。私は時々、時間のある時に通して読んでいます。私はハラハラドキドキして、今でもわくわくしてきます。ボケ防止に良いのでしょう。
　その中で、「中村洋四郎さんの構想」に書いたように、学校の要求条件にすぐ転用できると思いました。
http://nimuorojyuku.blog.so-net.ne.jp/2016-05-22-1
言いすぎて、顎が疲れました。でも今でも思っているのです。いろいろプレゼン資料も作り、指も頭も疲れました。でも、今でもブログを書いています。その要点は、再利用の仕組み、パッケージ企画の仕組み、人材育成の仕組み、プロジェクトマネージャー発掘の仕組みです。
　私はこの資料を参考にせず、理事長に提案するための企画案を作成して渡したあとに資料整理中にこの資料の凄さに気が付きました。本当なのです。私の要求条件と中村さんの流通SE会社へのアドバイスは瓜二つだったのです。
　流通SEと学校教育は製造に比べて比較的容易だと二人は考えていたのかもしれません。トヨタの製造管理や生産管理を学んできて、富士通にさえ導入するのは中村さんは難しいと考えていたのでしょうが。私は富士通の全工場を調査したことがありました。止める前の1年間。2名の富士通顧問のお方とともに旅行三昧したのです。
　私はシャープ時代、製造と保守のシステム開発で2度ほど外部の技術者としてオブザーバーで関与したことがありました。見事な失敗を見てしまいました。でも、その失敗は外部には出ませんでした。プロジェクトと計算機センターで情報は止められていたようです。
　まとめです。製造システムに比べたら教育システムは簡単でしょう。地域の学校がいくつか集まっただけでできる範囲だと今でも思っているのです。

by tsuguo-kodera (2016-05-24 04:35) 

koderaさん

ERP:Enterprise Resource Planning

面白いところへ話題が飛びました。
生産現場の生産性向上が中心にある仕組みですね。それと人･物･金に関する情報が結合する。
各々の業務の精度が飛躍的に上がると同時に、単純化が達成されてしまいます。ベテラン社員がやっていた業務が、非正規雇用の仕事に代替されてしまいます。

1990年ころから非正規雇用が増えだしたのは、労働法制の緩和だけが原因ではなかったようです。コンピュータシステム導入によって、熟練社員の仕事が単純化され、入力仕事やシステムのメンテナンスに替わって行ったことが背景にあります。

産業用エレクトロニクスの輸入商社にいた1979～1983年に、②科学技術計算用プログラマブル・カリュキュレータを使って開発した経営分析ツール、③受注算管理・納期管理・仕入管理・外国為替決済管理システム、④四半期ごとの円定価表システムをそれぞれ独立に開発しました。
オフコンの①経理システムが1978年に導入済みでした。

業務精度がコンピュータシステムを導入することで飛躍的に上がりました。たとえば、③のシステムによる外貨決済予測と為替予約、そして円定価表システムを為替レートの移動平均値で連動させることで、為替差損の発生がゼロになりました。どんなに相場が変動しても業績に影響させないようにできました。安定して、売上高の1％強の為替差益がだせました。
営業事務の生産性が3倍くらいになりました。それぞれの営業マンが為替レートがいくらになるか勝手に見積もって、見積書を作成していたのです。外へ営業に出ずに、事務所で見積書を作るのに時間の半分以上を費やしていました。これが3ヶ月ごとに出力される円定価表システムで解消されました。営業の生産性が2倍以上になりました。そして、NECの横浜工場と府中工場へ同じマイクロ波計測器を売るのに、見積書の価格が違っていることがクレームとなっていました。横浜営業所と東京営業所で所長も担当者も異なるので、見積もり金額が違っていたのです。定価のない状態でした。それも④のシステムで解消されました。
④のシステムと③のシステムを組み合わせることで、会社が製品販売戦略を定価表に反映させ、売上総利益率を15％アップしました。これは売上高経常利益率に絶大な影響を与えたのです。円高になれば大幅なマイナス、円安になればプラスで為替変動に業績が影響されていたのですが、10％前後の売上高経常利益率を安定して確保できるように変わりました。
上場要件がクリアできたので、この会社はそのご店頭公開しましています。

1991年に千葉の臨床検査子会社の生産システムを開発しましたが、ラボの生産性が4倍にAS400ともう一台汎用小型機を使用したシステムでした。業務処理システムとラボシステムの統合で果たした生産性アップです。

1984年に開発した多数のサブシステムのインターフェイスによる統合システムも、生産性アップに寄与しました。
とくに事務系の仕事の精度が飛躍的に上がると同時に単純化されました。業務システムの方は84年に富士通のその当時最大クラスの汎用大型機導入でOSがらみのトラブルが起きて半年ほど、本社部門から応援の人員を貼り付けて、並行してマニュアル処理することで凌ぎました。トラブルもあのときはお祭り騒ぎ。売上高経常利益率が12％あった会社ですから、人とお金には糸目をつけず、わっしょいわっしょい、問題を解決してしまいました。

結論です。ERPシステムは統合システム開発分野で日本で先端を走っていたユーザー企業とメーカが組めばドイツと勝負できたでしょう。人材はユーザ企業の現場にしかいませんでした。

産業用エレクトロニクスの輸入商社を辞めた1984年3月ころにオービックのSEから、輸入商社向けの統合パッケージシステム開発に誘われたことがあります。20社ほど販売可能な商社を抱えているという話でした。輸入商社で開発した3つのシステム、強力な経営改善効果のある3システムを統合すればいいだけの仕事でした。SRLへ転職して、4月から統合システムの一部を担当することに決まったいたので、お断りしました。
あれは輸入商社の業績を一変させるほど強力なERPでした。

この手の経営改革アプリの開発は、システム仕様書が書けて、その業種の業務と必要な専門知識に精通している人間が核になって初めて開発が成功します。
ベースは学校教育ですが、文系コースで数Ⅲ履修や物理履修ができるような仕組みをつくれば必要な人材を量産できます。koderaさんのご意見では比較的簡単にできるようです。

＞製造システムに比べたら教育システムは簡単でしょう。地域の学校がいくつか集まっただけでできる範囲だと今でも思っているのです。

教育システムについては1985年に書いた提案書「臨床診断支援システム事業化構想」でNTTデータ通信事業本部とミーティングをした折に、臨床診断支援システがそのまま臨床医育成用教育システムに転用できることに気がつきました。米国では医療分野でビッグデータを使った臨床診断システムや、人工知能を利用した診断システム、人工知能の病理学分野への応用が始まっています。
『ロボットの脅威　人の仕事がなくなる日』マーティン･フォード著　松本剛史訳　日経新聞出版社
この本の「第6章　医療という難問」に事例がいくつも載っています。

製造システムについては、業種によって事情がまったく異なるので業種ごとにアプリを作成する必要があります。たとえば、自動車生産会社であるトヨタの生産システムを臨床検査業のSRLに移植するのは不可能です。同様に輸入商社への移植も無理です。業種業態で生産システムが異なります。
業種ごとの生産システム・アプリケーションはそれぞれの業界のトップ企業が開発済みでしょう。
あとはこれらをまとめて眺められる「メタ・システム」の視点をもった、特別なSEを10人も揃えたら、十分のような気がします。問題は起業する冒険的な人材ととそれにお金を出す冒険的投資家が日本には存在しないことのようですね。どこかで、koderaさんが言及していました。

教育については別の問題を提起しました。
日本の高校教育システム、こちらは「制度」という意味のシステムですが、どこかの私立高校がやればいいのです。7～8時間授業で対応できます。すでにそういう授業携帯の私立高校がいくつもあるようですから、組み換えを行うだけでやれます。
文系・理系がクロスオーバーする領域の問題を扱える人財育成に有益なことがわかれば、その学校の偏差値が上がるでしょう。私立高校の営業戦略としては強力です。
私立高校で実績が出たら、トップクラスの公立高校へ徐々に波及していくでしょう。
by ebisu (2016-05-24 10:16) 

管理人様、koderaさん、Suzukiです。
高尚なお話の中、駄文を失礼いたします。
本の発刊につきまして、中村様にご報告が間に合わなかった事、全て私の進め方に問題がありました。一生忘れられないことでした。
想像力の欠如でした。
無い経験を埋め合わせるには、もっと想像力を働かせて問題に対処しなければなりませんでした。それを今までの思い込みとマンパワーで挑んだのが失敗の元だと思っています。
人と人とのお付き合いは、その時その時の判断の繰り返しです。
バドミントンでいえば、シャトルを打ち合う時の一打のように。
koderaさんの想像性の開発は、その一打を後悔しない一打にするために必要な教えだと思います。
その中には捨てるという、一番難しい判断も入っています。
今回の取り返しのつかない一件で、その大切さを改めて考えました。
by Akira Suzuki (2016-05-26 11:52) 

Suzukiさん

koderaさんとは、メーカとユーザという異なる立場から、1970年代からのコンピュータ発達史を眺め、お互いに昔語りを楽しんでいるだけです。

中村洋四郎さんの本はsuzukiさんが手がけたのですか、良い経験になったようですね。

「創造性＋想像性」開発、このふたつが揃えば鬼に金棒です。
関係する人々の心情を慮るというのは日本の伝統的価値観でもあります。
「気配り」「気働き」というのがそれですね。響きのよい言葉です。
仕事で何かに躓くと同時にそこから何かを学べたら幸せです。
あせらず仕事にじっくり取り組んでください。

by ebisu (2016-05-26 15:58)