129.CAD/CAMはVR

129.CAD/CAMはVR秘伝の図


－「ソフトウェア開発にTPS適用を可能とする方法論」のお話をお聞きして－

はじめに

　2019年12月に、東京大学のものづくり経営研究センター（Manufacturing Management Research Center 以下MMRCと略す）の統合型ものづくりとITシステム研究会にて、株式会社ニュートリの代表取締役の新木廣海氏より「日本のデジタルマニュファクチャリングのありかたについて」副題「ソフトウェア開発にTPS適用を可能とする方法論」というお話をお聞きいたしました」。
　新木廣海氏は1968年にトヨタ自動車に入社後、直ぐに 複合自由曲面NC加工プログラムTINCA のソフトウェア開発に従事し、1975年に実用化、さらにWS/PCベースのCAD/CAMの開発・普及に務めるなど終始、自動車のCAD/CAM開発に携わってこられました。トヨタ自動車を退社後、株式会社ニュートリを設立し、代表取締役をされています。株式会社ユートリの事業内容はソフトウェアの開発、製造、販売、保守、コンサルティング、研修およびプロセス構築の受注です。注１）

　私は以前外資系IT企業に勤め、製造業営業部のSEとして、生産管理・CADソフトの販売・導入にかかわっていました。その時トヨタ自動車は自前のソフトをつくって持っているので売れないという話をお聞きしたような記憶があります。その後、どうなったかも知りたくて興味深くお話をお聞きしました。
　今回はその時のまとめと、その後感じたことをまとめました。

注1) 株式会社ニュートリ社は2007年12月10日に設立された会社で、株式会社ニュートリ社のホームページ(http://newtre.co.jp/ （2019/12/11　アクセス）)に組織概要、製品情報、コンサルタント情報、ソフト開発業務とTPS（Toyota Production System）注2) についての情報が掲載されています。株式会社ニュートリの製品やサービスの具体例・詳細等をお知りになりたいときには、こちらをご参照ください。

１ 現在の発想・実装に至る経緯

　新木廣海氏は1968年にトヨタに入社して、前述のように 複合自由曲面NC加工プログラムTINCA の開発に携わり、その後ワークステーション型CAD/CAM（Caelum）の開発、さらに協調作業用CAD（Caelum XXen）を開発するまでの経緯をお聞きしました。メインフレーム時代からワークステーション時代を経てPC時代に至るまでの時代を跨っての開発の歴史です。

　トヨタに限らず日本の自動車メーカ各社は、CAD/CAMの開発に傾注しました。1980年後半から自動車メーカに限らず多くの製造業では、以前の紙に書く設計から、ディスプレイを使った設計が行われるようになりました。1990年代後半から、欧米の自動車産業企業もCAD化・EWS(Engineering WorkStation)化・PC化を進め、日本のCADとの競争が激しくなりました。1993年にはCAD/CAMシステム開発・販売のための、株式会社トヨタケーラムが設立されました。

　グローバル・ボーダーレスの時代の到来と共に各自動車メーカーは、パートナーを世界各地に求めるようになります。とくに自社に無い技術を組み込んだ部品を必要とする場合は、グローバルにパートナーを求めます。その場合、データインターフェースが同一であれば、設計を容易に依頼することができます。すなわちデータインターフェースが同一の会社は世界のどこにあっても、チームを組むことができるようになるわけです。しかし、そのためには、自社にも共通した仕様（インナーフェース）をもったCADソフトが必要となります。こうして欧米のCADメーカーは欧米部品メーカーとのデータ互換性をセールスポイントとして日本に売り込みを図り、海外実績のない日本のCADメーカーは苦戦する時代になりました。ただ、欧米のCADは、ドラフターから転じたモデラー用のCADとなっているため、摺り合わせ型の設計を行う日本の製造業の設計者には、操作が難しく使いにくいものでした。 日本の設計者は、構想設計・詳細設計・不具合対応など、自身でCADを操作していたため（日本には設計者を支援するドラフターという職種はなかった）、国産CADに比べるとCAD操作に手数が多く、時間がかかりました（後には日本でもモデラーを）。こうなると、日本のものづくりの能力も落ちてくる懸念が出てきます。

　そこで、トヨタケーラムでは、欧米CADのデータ互換性というセールスポイントを凌駕するために、日本のものづくりの特長を活かした協調作業環境CADシステム（Caelum XXen）を開発することになりました。同一データの画面を見ながら、共同して設計できるようになることを目的として、とのことでした。これが実現すれば、グローバル時代に備えて世界の複数の箇所の設計者が場所に関係なく、並行して設計ができるようになります。合意をとるときは同時にやることが必要ですが、日本とアメリカとヨーロッパといった時差を違うところで、設計を引き継ぎながら行えるようになると、各人は所定勤務時間に仕事を行っていても、24時間連続して設計を継続することもできます。また、摺り合わせをしながら、一つの製品のいくつかの部品を分担して設計すれば、これも、設計期間を短縮できます。大手家電メーカーに採用され、欧州・中国・日本間での協調作業環境が実現したそうです。しかしながら、欧米のCADメーカーのデータ互換性というセールスポイントには抗しきれず、遂には敗れ去ったそうです。

　しかしながら、協調作業環境CADシステム（Caelum XXen）の開発に当たっては、複合自由曲面NC加工プログラムTINCAのソフトウェア保守・改善以来、新木廣海氏が追求してきたTPSの考え方（ソフトウェア部品表、先行導坑と一個流しの考え方など）を採り入れ、ソフトウェア開発/保守工数の低減・期間短縮・品質向上に成功したそうです。注2）

注2) 　TPSとはトヨタ生産方式のことです。
図表1に「トヨタ生産方式の概要」をまとめました。この図は石川秀人、「最新トヨタ生産方式の基本と実践がよーくわかる本」、秀和システム、2017、 p4にある「トヨタ生産方式の概要」図をもとに、大野耐一、「トヨタ生産方式」、ダイヤモンド社の第1章ニーズからの出発と第2章トヨタ生産方式の展開 の記事を参考にして、私の感じたことを描いたものです。終戦後日本の生産性がアメリカの8分の1とか9分の1になっていることに気づかされ、これでは製造業としてやっていけない。日本人は何か無駄なことをやっているのだろうと考え、「ジャスト・イン・タイム」と「自働化」を二本柱にして「徹底した無駄の排除」を行ったことがトヨタ生産方式の出発点だったそうです。これはムダを見つけ、改善のニーズを明らかにして、「人づくりとムダの排除」を行い、企業体質の強化をはかる方式です。

vbl-cdcmvr01.jpg

図表１　トヨタ生産方式の概要図

石川秀人、「最新トヨタ生産方 式の基本と実践がよ～くわかる本」、秀和システム、2017、p4にある「トヨタ生産方式の概要」図をもとに、大野耐一、「トヨタ生産方式」ダイヤモンド社の第1章ニーズからの出発 と第2章トヨタ生産方式の展開の記事を参考にして作成

　当時の日本の自動車産業の少品種大量生産では、アメリカのようなマーケットの大きいところで、人件費の安い国の自動車メーカーと戦うのは難しい状況になり、日本の自動車産業は多品種少量生産に向かいだしました。このため、大量生産のためだけでなく少量生産・試作・保守が重要になってきました。TPSの考え方が従来以上に注目されるようになりました。


vbl-cdcmvr02.jpg

図表2　開発設計での一個流し

出 典　株式会社ニュートリ社のホームページ(http://newtre.co.jp/)のNewprocess のスケジュール管理を参照して作成

　そこで重要になってきたのは、短納期です。そのため図表2 開発設計での一個流し にあるように、設計→作成→テスト→総合テスト→不具合があれば作成に戻り、OKであれば検収され、リリースされます。このやり方では始めた時の仕様に合った製品になっているかどうかが重要になります。この最初の仕様に不具合が見つかれば、改めて次の世 代の仕様が検討され、次のリリースに向けて設計に入ります。この仕様検討の時期がすり合わせ型と同じく経験と学習の機会です。そのうえ、常に次の仕様が回ってくるため各部門の負荷（資源）の使用状況は平準化されます。こうして毎月でも新しい製品のリリース（バージョンアップ）を行うことができます。ただし、このためには製品のバージョンによってどの部品が使われているかを管理し、不都合があった時にどの部品を修正もしくは交換すればよいかがすぐわかることが前提となります。すなわちハードウェア・ソフトウェアにかかわらず、製品や部品のバージョン管理が必要となります。いわゆる部品表ですが、ハードウェアに関しては多く適用されていましたが、ソフトウェアに関しては、部品表を作成するには、ハードウェアに比べて変更が多く、部品表にその変更を追随させるには、余りにも繁雑となるため、適用されてきませんでした。（独シーメンスが2018年に発表した「ソフトウェア部品もまとめて管理できるPLM」では、ソフト部品のバージョン管理も可能となっているようです。）

　このモジュラー型設計は、海外の製造業では普通に行われている方法で、自働化が進むとそのサイクルが短縮されていきます。これがTPS モジュール型の特徴です。これが実現するためには、設計段階のデザインやプランの段階で総合テスト（最終段階）に実現するものを詳細に規定しておくことが必要になります。ここまだは決まっていないが、良きに計らえとか、途中で環境が変わったから設計を修正するといったことは、許されないというコミットメントを守る文化が重要となります。（TPSで行われている現場での仕事のやり方の改善とは違います。設計仕様はいわば外部仕様です。）

　ただ、TPSは生産現場の改善方式であり、CAD/CAMの開発・保守プロセスにTPSを適用することなど想定すらされませんでした。CAD/CAMの開発では自動車のボディーや機能部品のモデリングや金型加工のための工具経路作成のアルゴリズムに焦点が当たっていました。しかし、新木廣海氏は、CAD/CAMの開発・ 保守プロセスにTPSを適用することを行っていたのです。

2　Newtreが開発・実装してきたこと

　ソフトウェア開発にTPS適用を可能とするためにNewtreで開発し、提案していることは以下の3つの項目です。

2.1　部品化・モジュール化

　この方法論の一つとして、Newtreは、図化可能な分かりやすいネットワーク型データ構造"N_ASP" をソフトウェア開発用ツールキットとして提案しています。"ASP(Associative Structure Package)" は、元々ケンブリッジ大学のC.A.Lang &J.C.GrayがCAD用に考案したものでレスポンスのよさが要求されれるCAD/CAM 用のオンメモリーデータ構造で、Newtreは、これをC,C++で大幅に機能拡張をして、"N_ASP"としたものです。ヒストリー型UndoRedoも可能でレスポンスを要求される組み込みソフトなどに適しているとNewtreは提案しています。Newtreでは、この"N_ASPツールキット"上に、2.2で述べる"PRA"や2.2の"AspCad"を実装しています。

　"N_ASP"は、図表3 ASPの構成要素 にあるように、エレメント、アソシエ―ター、リングスタートの3種からなり、それらの関係はアッパーリング、ローアーリング、アソシエーティブリングの3種で表現しています。この表現方法は、部品構造だけではなく、組織とスキルと要員の構造化や列車と停車駅と通過時間の表現にも使えると例を挙げて説明されています。

vbl-cdcmvr03.jpg


図表3 ASPの構成要素

出 典　株式会社ニュートリ社のホームページ(http: //newtre.co.jp/)の製品情報を参照して作成

　これは、私が昔売り込みを行っていた、2次元CADの時代とは大きく変わっています。当時は、紙と鉛筆と定規を使って製図を行っていたものを、ディスプレイとキーボートとマウスに置き換え、最終的には設計図を印刷する道具でした。それが今や3次元のデータとなり、必要に応じて見る位置を変えて表現できるようになっただけではなく、エレメントの意味合いや関係までも表現できるようになったのです。こうしていまやこの表現方法は、部品構 造だけではなく、組織とスキルと要員の構造化や、列車と停車駅と通過時間の表現にも使えると例を挙げて説明されています。すなわちこれはものモノだけでは無くコトの見える化にも使える素晴らしい情報の整理方法です。

　"PRA"の "N_ASP"による構造設計図をまとめて表示した画面を見せていただきましたが、非常に複雑になり見ても直感的に内容を理解することはできませんでしたが、"N_ASP"を使う開発当事者達にとっては、構造設計図を図化できることは、見える化であり、知の共有化に繋がることと考えられます。処理方法のシ ステム化も同時に行って、見たい情報を抜き出す方法も確立しておけば、便利で迅速な判断に役立ちます。このためにはVR( Virtual Reality)のような判断しやすい仕組みが必要であり、これがNewtreの売りのように感じた次第です。

2.2プログラムの見える化・知の共有化

　Newtreは、"プログラムの見える化・知の共有化"のための重要なToolとした"PRA"を開発し、提案しています。

　PRA とはN-ASP（New-Associative Structure Package：新版ASP のこと）をベースにしたN-ASP_SingleDS_Toolkitで開発された汎用ソフトウェア開発・保守支援パッケージです。PRAは、C++で記術されたprogram構造を解析するprogramで、大きく分けて以下の5つの機能があります。
①　NewtreTreeStructure(NTS)と称するmain/WndProcなどをTopにしたTreeStructureを作成する機能
②　NewtreCrossreference Table(NCT)と称するDLLなどのCrossReferenceTableを作成する機能
③　同種の2つのPRAのDS間の差異分析をするNewtreStatusInspector（NSI）機能
④　作成されたNTS・NCTのDSの正順・順逆のTree構造、NSIの差異対比構造などの内容を表示・編集する機能
⑤　関数・変数などを変更した場合、mainまで遡って、どのcommandに影響が及ぶかを調べ表示する機能。これが実現すれば表示されたCommandのみをTestすればよくなります。

・これらNTS,NCT,SIをApplication開発・保守環境の中に組み込むことにより、開発中または、保守段階にあるアプリケーションのプログラム構造の「見える化」が可能となり、開発・保守の品質向上・効率化が図れるそうです。
・またApplication開発・保守環境がN- ASP_TripleDS/DoubleDS_Toolkitであれば、PRAやAspCad(後述）がhelp機能として付属しているため、より一層効率的な利用が可能であるそうです。

　株式会社ニュートリのホームページの製品情報には以下、①～④にあるような表示例が載っています。ご興味のある方はそちらをご参照ください。注1）
①　PRAで作成されるいくつかの代表的な正順Tree、逆順TreeのSampleの表示例。
②　画面に触れば、EditWindow表示とDisplayView表示が交互に表示される。
③　プログラムの見える化・知の共有化（C,C++のprogram解析ソフト）のための部品表の自動作成、正順・逆順で構造を表示。
④　部品・モジュール(N-ASP)の見える化（描画用）。注3）

2.3 部品・モジュール(N-ASP)の見える化

　"N_ASP"は2.1で述ましたように図化可能なデータ構造をもっており、ソフトウェア設計段階でデータ構造設計図を手書きし、これを開発チーム全員が共有化し開発を進めることができます。しかしながら、実装されたソフトウェアの構造が設計図通りにできているかを確認するためには、Dumpしたデータを読み取って図化する作業が必要です。これはプログラマーにとって手間のかかる作業でdebug時のネック工程になっていました（N_ASP以外のデータベースパケージでも同じです）。

　Newtreは、ソフトウェア開発用ツールキットである"N_ASP" を使って実装したソフトウェアの構造を会話的に描画する"AspCad"を開発し、提案しています。"AspCad"は、"N_ASP" を使って実装したソフトウェアのデータ構造をInputし、その構造を会話的に描画する機能を持っています。
　レイアウト処理は人に任せ、会話的な描画・レイアウト変更を可能にするために Move・Undo/Redo・Deleteなどの修正機能を充実しています。
　これらの機能により、"AspCad"のデータ構造の見える化が図れ、プログラマーにとって大幅な手数の削減になっています。
　このような見える化は、従来にないもので、ソフトウェアの開発にTPS適用を可能とするための必要条件に繋がっています。

注3）20131017コンソーシアム第3分科会議事録である『ソフトウェア開発にTPS適用はなぜうまくいかないか？：日本の強みを活かしたソフトウェアづくり　発表者：新木廣海様（株式会社ニュートリ 代表取締役）、(http://newtre.co.jp/sample/images/20131017%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B7%E3%82%A2%E3%83%A0%E7%AC%AC3%E5%88%86%E7%A7%91%E4%BC%9A%E8%AD%B0%E4%BA%8B%E9%8C%B2%20%E6%9C%80%E7%B5%82%E7%89%88.pdf)　』の図5には以下のような「図表4 トヨタ生産方式(TPS)の適用可能性分析図」 が載っています。

vbl-cdcmvr04.jpg


図表4　トヨタ生産方式(TPS)の適用可能性分析

　参 照　株式会社ニュートリ社のホームページ　コンサルタント情報より


　上図の生産現場はよく言われるトヨタ生産方式の誕生した分野で、いろいろなところで使われています。ただし同列の下側にあるように、伝統芸術の分野は不得意といわれています。

　可視性については生産現場では機械設備・作業・ものといった現物であり、設計・生産準備でも図面・製造物といった生産現場ほどではないにしても現物に近いもので可視性の高いものでした。使われている道具は生産現場では機械設備であり、設計・生産準備では、従来の手書き図面や実寸の実物モデルでしたが、図面品質・モデル品質の精度不十分が難点でした。そこに1980年代にCAD/CAM/PDM/VR といったソフトウェアツールが導入されはじめました。設計者・生産準備技術者の使用する端末は、WS・HIifhtEndPc. といった専用端末で事務系の端末とは少し違ったものを使うのが普通でした。

　その結果、見える化・知の共有化が進み、設計品質が大幅に向上しました。
　すなわち設計・生産準備の現場では、仕事がスムーズに流れ、生産性も上がってきたわけです。このようにして市販のプロセス管理ソフトで使える情報も容易に得られるようになり、進捗管理にもTPSの考えを取り入れることも可能になり、リードタイムを大幅に短縮できました。このような条件下、TPSは設計・生産準備のエリアまで浸透することができました。

　ところがソフトウェアの分野については、他の分野の持つ可視性や道具などといったものとの共通性は非常に少なく、現場感覚はあまりありません。このため「2Newtre が開発・実装してきたこと」に書かれているTPSの特徴を生かすやり方は、設計・生産準備の分野にまでには使えても、ソフトウェアの分野にまでには行き届いていないのが現実です。注4）

注4）ソフトウェアの認証・ソフトウェアト管理についてはほかにも下記のような資料がありました。　
・「航空機装備品ソフトウェア認証技術イニシアティブ」http: //www.aero.jaxa.jp/about/hub/sobihin/pdf/sobihin.pdf（2019/2/17　アクセス）や「航空機装備品ソフトウェア認証技術イニシアティブによるSW支援が始まる」という新聞発表　biz3.co.jp/wp/wp- content/uploads/2018/11/Biz3_magazine_201807_konishi.pdf（2019/2/17　アクセス）にその概要が載っています。
・国産の民間航空機搭載用ソフトウェア開発への道、http: //www.masc.co.jp/techf/documents/ObjectivesAndToolInDO178C.pdf （2019/12/14　アクセス）
・20190314_第1回航空機装備品認証技術オープンフォーラム～ソフトウエア認証への取り組みと課題～_住友精密工業（http: //www.aero.jaxa.jp/publication/event/pdf/event190314/sobihin04.pdf （2019/12/22　アクセス）
・「ソフトウェア部品もまとめて管理できるPLMシステム、独シーメンスが発表」、
https://dcross.impress.co.jp/docs/news/000378.html、DIGITAL X編集部、2018年2月21日（2019/12/19 アクセス）　
・「ソフトウエアプロダクトライン開発（SPLE）_再利用の秘訣　～ バージョン地獄で苦しんでいませんか？ ～」（https://www.fuji-setsu.co.jp/event/et2013.html（2019/12/21アクセス））にソフトウェアのバージョン管理の難しさとその解決方法についての資料がありました。ご参考までに。

3　なぜ日本のソフトウェアは世界に後れを取ったか

　このような、CAD/CAMの現状についてお話をいただいた後、日本のソフトウェアが世界に後れをとった理由として次の3つ説明をいただきました。
①　現地・現物・「見て触って確認しないと信用しないと」といった日本のものづくりの良さにこだわり、見えないソフトウェアを軽視してきた。
②　情報処理部門は、他部門、設計・生産準備・生産現場から孤立していた。
③　1985年の労働者派遣法で、ソフトウェア技術者は専門性が高い職種とされ、ソフト開発は派遣社員に頼るか、外注頼みとなってしまった。　

　その結果、ソフトウェアの社内技術者が育たず、自社で仕様決定したり、外注価格を見積もったり、検収する能力がなくなってしまいました。そのためソフトウェア開発・保守プロセスの変革も 進まず、ソフトウェアの原価低減の方法は外注価格の低減要求のみとなり、また逆にあまり原価を意識すると品質不良を起こしかねない状況となったのです。さらに、本来プロセス 変革を主導すべきソフトウェア業界の開発費用の見積もりは開発に要する人件費（マンアワー×時間単価）で開発者のスキルは考慮されていないのが実情です。こうして何をいくらで開発するかに終始し、いかに開発すべきは追及しない業界になってしまいました。

　欧米の軍需品・宇宙機器開発業界はソフトウェアもハードウェア並みにプロセスの規定を設けているが、日本では個人のスキルアップやその支援が中心となり、チーム活動としてのプロセス支援がない状況です。このため日本のソフトウェア業界は不十分な欧米追従となり、中国やインドにも抜かれる状況になったということです。

　ソフトウェアは複数のプログラムからなり、各々のプログラムは数多くのサブルーチンを含んでいます。そのサブルーチンの中にもサブルーチンが含まれるという階層構造で作られます。いくつかのサブルーチンは複数のサブルーチンの中でも使われます。これは自動車がいくつかの取り外しのできる組み立て部品からなっており、その組み立て部品がさらに小さな組み立て部品からなっているというハードウェアと同じです。ソフトウェアも管理台帳を作って管理しています。 ここでは、このソフトウェアの構造に合わせて作る管理台帳を部品表と呼んでいます。またハードウェアでいえばある部品が不良で壊れれば、それを使っている組み立て部品も不良になります。同じことがソフトウェアでも起きるために、不良ソフトを呼び出しているソフトもチェックできる仕組みが必要なわけです。すなわち、ソフトウェアの部品表が必要なわけです。おうおうにしてこのような波及を避けるためにサブルーチンの名前を変更して派生サブルーチンにすることがあります。こうなると、このソフトウェアがほかで使われている場合の不良を事前にテストできなくなってしまいます。さらに派生サブルーチンができるとどれが本来のソフトかが分からなくなり、次の不良が見つかった時には追跡不足になります。このような体制で作られたソフトウェアを使用している製品はエラーを完全に除去できない不良品となってしまいます。
　また、「日本初のジェット旅客機MRJには数多くのソフトウェアが動作しているが「日本製のソフトウェアは1行も搭載されていない。」 という実情があるとのお話がありました。その大きな原因はソフトウェアの認証にあり、民間航空機の構成機器は米国ではFAA、欧州であればEASAからの認証が必要で、そのためにはDO-178Cという規格に準拠して開発する必要があるが、日本でその規格への対応が普及していなかったため、MRJへの採用の検討がなされなかったということでした。1918年に日本でも「航空機装備品ソフトウェア認証技術イニシアティブ」が発足したとの報道があり、ようやくソフトに注目が行き始めたという状況です。注2）注3）

　これらは、日本のソフトウェアに関する無関心、もしくは社会的関心の不足を感じさせるお話です。思えば私自身も、1970年位から、CADの販売、部品表の販売、さらに新システムの導入・開発に係わっていましたが、自分が担当したシステムの開発に係わった時に、ソフトウェアの台帳に開発ソフトの階層的部 品表を作成しようと思ったことはありませんでした（ソフトウェア仕様書はグループ分けし、バインダーに保管していました）。現在は「ソフトウェア部品もまとめて管理できるPLM、独シーメンスが発表」にあるように、日本でもソフトウェアの部品表管理が行われるようになってきているようです。注3）　
　航空機のような、一つ間違えると大変なことになる場合は、ソフトといえどもここまで品質を重要視する必要があったと、改めて思い知らされました。

　例えば、当時のシステム開発の例を挙げると、ある時、海外の世界最大の競合企業が日本でも製品の発売の発表を行い、会社の将来が危ぶまれた時に取られた対策です。商品が故障した時に、その会社は24時間以内に修理用品を現場に供給し、その商品がユーザーの仕事に及ぼす被害を最小限にする仕組みを実現するためのオンライン補給部品システムを作った時の話です。
　海外のメーカーが海外から補給部品を輸入すると数日はかかり、その機械の使用できない期間は1週間くらいになります。したがって、日本市場で競争相手が日本企業である場合、日本の会社と同じ仕組みを作ろうとすると海外のメーカーは、いかに強力であっても、いつ使われるとも分からないすべての修理用品の在庫を国内の何か所かに持つ必要があり、まだ売り上げの少ない参入時期であっては、とても実現できませんでした。このような海外メーカの弱点を突いて、国内の会社のやることは、まだ導入事例の少ない全国のサービス拠点と生産工場をつないだオンライン補給部品システムの構築でした。　
　当時はこのための大型コンピューターを発注してから納入されるまでに1～2 年かかる時代でした。システム開発の期間は十分ありましたが、システムに必要な機能の概要は決めることはできたものの、ソフトウェアの仕様は全くできていませんでした。このような状況ですから、大型コンピューターの受注後お客さまと相談しながら、実現可能な方法を決めて開発を始めることになりました。今でいえばアジャイル開発です。このような状況でしたが、当時のオンラインシステムで何がどのように可能なのか（当時は日本ではじめてつかうようなソフトウェ ア機能についても）調べながら、お客様の了解を得て、できる範囲でアプリケーションソフトウェアを作成し、どうにかハードウェアの導入期限までに、ソフトウェアの開発を完了しました。その後海外の、競合企業は日本での売り上げをそれほど伸ばすことはできませんでした。プロジェクトの目標は達成できたわけです。今やそのシステムを開発した企業は、サービス機能を売り物した製造業として、世界で活躍しています。

　しかし、この当時のソフトウェアの開発は大変でした。プログラムの仕様書を書き、コーディングし、それをカードにパンチするのは主に昼の時間、テストはバッ チの定常業務処理が終わった後の24時過ぎから夜明けまでという状況でした。このため月に200時間くらい残業することもあり、上司から注意するよう、きつく言われたこともありました。当時の製造業の生産現場ではこのようなことも許されていたようで、お客様から特にクレームはいただきませんでした。今ではとても許されることではありません。

　そのころの私の主な仕事は開発されたプログラム作成からテスト結果の検証、並びにエラーの処理の相談に乗ることでした。プログラム仕様書の数が増えてきた時、テストしてエラーが発生すると、どこが原因かを聞かれることが多くなってきました。幸い私は、ほとんどのプログラム仕様書に目を通していましたの で、それはあのバインダーのこのプログラムといえるコトもありました。するとお客様サイドにスーパープログラマーが居て、きちんと修正してくれました。そのうち、スーパープログラマーがプログラム仕様書の整理・格納方法を知るようになり、仕様書のありかを知るようになると、私はプログラミングテストの現場から離れることができるようになりました。
　今となってみると、私の仕事は今ならソフトウエアシステムの部品表管理の人間版であったわけです。今回のお話を聞きながら、システムの部品表を自動作成するような仕組みが非常に役に立つことは、直感的に理解できました。「魚眼マンダラで一枚に」で情報の分析に使ったマインドマップは、単純な構造のアイデアを 一つにまとめたアイデア部品用のビジュアル版だったようです。

　そしてTPSの得意分野の条件としては、下記4条件
・目に見える
・繰り返し作業
・機械化がある程度進んでいる
・工程内で品質が織り込める
を満たすことができます。

　ただTPS方式を採用するといっても、仕事の改善の進め方は、図表5 現場の自働化の考え方 にあるように生産現場の改善とはとは少し違ったものになります。社風・風土・下地に変革意識のあることがTPSによるプロセス変革を進めるため前提で、作業・工程・設備改善の活動の結果が、良い結果を生み出し、さらなる「意識改革」に至り、良いプロセス変革の循環に至るとのことです。この循環メカニズムは、ソフトウェアの分野でも生産現場の改善や設計・生産準備分野と同じです。しかしながら、最初の段階である社風・風土・下地に変革意識のないところには、なにも生み出すことはありません。そういう意味では、経営 TOPに変革意識があるかどうかがポイントですとの話がありました。

vbl-cdcmvr05.jpg


図表5　自働化の考え方

出 典　株式会社ニュートリ のホームページ　ホワイトカラーの業務改革はITからを参考に作成

　すなわち、現場の作業そのものの改善を目指すのではなく、事務所現場の作業そのものの改善をいきなり目指すのではなく、現場の仕事をまず自働化するITシステムを改善もしくは開発することから始まると言っておられます。新しいITシステムを使って仕事を行うことにより、標準化が進み、作業が改善され、それが工程を改善することになるわけです。

　ソフト開発・保守業務のプロセス変革においては、PRA（Program Relation Analyzer）の使用により、ソフトウェアの部品表、PDM（ProductData Management）を作成することができます。これがソフト開発・保守現場の仕事をまず自働化することになります。残るのは、スーパープログラマーでなくてもシステムの問題を理解できるような仕組み作り、すなわち「見える化」とそれに対応できるプログラマーの訓練です。こうして「見える化」ツールを用意し、それを使えるプログラマーの育成ができれば、自動車製品開発プロセスへのTPS 適用を参考にして、ソフトウェア開発保守プロセスにTPSを導入できそうです。注4）

　こうして、日本のソフトウェアが世界に追いつくためには
・欧米のプロセスを学び、抜本的なプロセスを構築すること
・プログラミングは、技術者の基本技術として人材を育成する
・プログラマーの外注依存から脱出し、機械設計者・電気設計者並みに処遇を充実させる必要があります。

　このためには
①　機械化・自働化　Visual Studio/Google/AI等をさらに充実させる。
②　見える化・知の共有化　PRA(もしくは相当品)でプロダクトモデルを作成するプロセスモデルを作成する。
③　プロダクト/プロセスモデルで開発/生産部品表を運用する。
④　AspCad相当の図化機能を強化する。
⑤　部品化・モジュール化としてPRA/AspCadを持つツールキットを用意する。
⑥　これらを使って、ソフトウェア情報の自働化・形式化を行う体制を構築する。
⑦　さらに欧米のプロセスを学び、且つ日本の強みを生かせるようプロセス変革を行う。
⑧　プログラミングは技術者の基本技術と考えて多くの人が学ぶようにし、少なくとも情報処理部門要員には必須とする。
⑨　プログラマーの処遇を改善し、機械設計者・電子技術者並みとし外注依存から脱却する。
といったことが必要となります。

おわりに

　以上、今回発表をいただいたお話の中から、私が関心を持った事柄を中心にまとめました。
　はじめにも書きましたが、30年から40年くらい前に自分の専門として行っていたことなので、どのように変わっているかを知るいい機会と思ってお聞きしていましたが、今やグローバルでITの時代、モノ作りも随分変わっていることを感じさせられました。例えば、ハードの部品表と組み合わせてソフトの部品表も作ることなど、大変新鮮に感じられました。さらに、オンラインの適用業務の試験を行っている時に多くのプログラムの中から修正するプログラムを見つけ、どう変えるかといった質問に応えるための苦労は大変だったことも思い出しました。今やハードウェアもソフウェアトも統合した部品表を使えば問題点も容易に見つけ出せるようになり、修正可能な時代を迎えていることを知りました。今回はモノづくりプロセスの変革経験をソフトウェアづくりに活かす話でしたが、これからのソフトウェア重視の時代は、ソフトウェア一般についても実施すべきことであり、そのためのソフトウェアも出てきていることを知りました。注4）

　また、お話をお聞きしながら、よく理解できないので質問も控えてしまいました。家に帰り、よく理解できなかった言葉をネットで検索してみました。すると、一番の原因は専門用語もしくはローマ字の3文字熟語が理解できていないことでした。講演者や講演に参加されている人達には常識である単語が私には分かっていなかったのです。しかし、インターネットや、文献を参照しても、まだしっくりこないことがいくつか残っていました。しかし、時間がたつと、世の中は変わります。やはりTPSで言っているように今後も現場を見ること・体験することが重要であることを感じさせてくれたお話でした。

　先に挙げた、「このための」の9つの条件の中にはまだまだ難しいことが含まれているような気がしました。例えば「⑧のプログラミングは技術者の基本技術と考えて多くの人が学ぶようにし、少なくとも情報処理部門要員には必須とするとか、⑨のプログラマーの処遇を改善し、電子技術者並みとし外注依存から脱却する」といった活動を広げる必要があると思います。そして、多くの関係者にITが、これからの世界に及ぼす影響を知っていただく必要があります。そのためには「図表4　自働化の考え方」にあるように、「CAD/CAM/PDM」といったツールを使って行う「IT改善」の前」、「社風・風土・下地作り」に変革意識を持たせることが必要なわけです。この時の 「CAD」より広い意味をもつコト設計(Computer Aided process Design)、「CAM」はコトのモデル設計(Computer Aided process Modeling)、「PDM:」は工程のモデル設計(Process Design Modeling )にも使えるの作成ツールを意味することになります。こうなればCAD/CAM/PDMはモノづくりの道具だけではなくコトを仮想現実（Virtual Reality）として表現する道具となります。

　そのためには、プログラマーが行っていることをもっと容易にできるようにして「ホワイトカラー」に浸透させる必要があるような気がしました。さらに今回私が 苦労したような専門用語や3文字熟語を使うことをやめるか、多くの人が日常見ている表現になるよう普及させること（生涯学習）が必要と感じました。3次元CADであればレンダリング図の表示、飛行機のコックピットに表示される情報のように、目的に応じた表現形式で見られることが必要です。⑧や⑨で取り上げ られた対策は、そのための準備に必要なことです。

　こうして馬に乗れない人でも少しの訓練で車になら乗れるようになったように、新しいことに自ら挑戦する人材育成（よくないと思ったことが混じっていても、上 から言われた事を忠実に実行するだけではなく、自分の価値観にあった行動をする人材とか、当人のやりたいことをやりたいやり方を提案できる）を行い、わかりやすく・楽しく使える「CAD/CAM/PDM」を開発できれば、おのずと普及するように思えるのですが。やっぱりこれはまだまだ先の話でしょうか（笑い）。

余談
　今回のセミナーに参加しはじめて会社勤めをした時の、「辛かった時」のことを思い出したのですが、なんと今やそれが「楽しい思い出」のように思えます。新木さん、ありがとうございます。
　今、「辛い思い」をされている方もそれは将来「楽しい思い出」になるかもしれませんよ。頑張りましょう。

参考文献
新木廣海、「日本コトづくり経営」、日経BP社、2005
中沢孝夫・藤本隆宏・新宅純二朗、「モノづくりの反撃」、ちくま新書、2016
飯塚悦功、「日本のモノづくり2.0－進化する現場力―」、日本経済新聞出版社、2008
柴田友厚、『「日本のモノづくりを支えたファナックとインテルの戦略「工作機械産業」50年の革新史』、光文社新書、2019
国産の民間航空機搭載用ソフトウェア開発への道、http:：//www.masc.co.jp/techf/documents/ObjectivesAndToolInDO178C.pdf （2019/12/14　アクセス）
旅客機のコックピット「もしパイロットが気を失い素人が操縦することになったらどうすればいいか」を本物パイロットが「Microsoft Flight Simulator」でマジ解説　（https://gigazine.net/news/20160219-emergency-piloting/） （2020/01/10　アクセス）

略語・言葉
FrontLoading：製品製造やシステム開発のプロセスにおいて、初期工程（フロント）に重点を置いて集中的に労力・資源を投入して後工程で発生 しそうな負荷（仕様変更など） を前倒することで、品質向上や納期短縮を図る活動をいう。 ... 後工程のことを早期に考えるという意味で、源流管理やコンカレント・エンジニアリングと密接に関係する
PRA ：Program Relation Analyzer
Loanwolf：一人で行動する人　一匹狼
PRA： Program Relation Analyzer


2020/01/14
文責　瀬領　浩一