我が社における生産技術の進化と品質技術の深化

＊技術統括部 MSS技報・Vol.22 48
我が社における生産技術の進化と品質技術の深化
Evolution of manufacturing technique and enhancement of quality in our company
若宮 正男＊　Masao Wakamiya
前身の時代を含め会社設立半世紀という節目を迎え、既刊のMSS技報から見たわが社の生産技術の進化と品質技術の深化について述べる。生産技術の進化については、過去のMSS技報を整理しその技術がどう変遷してきたか、また背景にある基盤技術は何かを整理した。品質技術の深化については、MSS技報20号で「品質への取り組み」としてまとめており、その引用および最近の取り組みについて記した。
　The turning points of the half century incorporation procedures including the time of past aregreeted, and evolution of the manufacturing technique of our company which saw from the MSStechnical report of the previously published book, and enhancement of quality technology aredescribed. As for the base technology where arranged the past MSS technical report and thetechnology has changed how about evolution of manufacturing technique or which serves as abackdrop, something was arranged.　About enhancement of quality technology, "Approach on Quality" is summarized by the MSStechnical report No.20, and it described about quotation and the latest measure.
1．まえがき
　MSS技報は1989年に創刊され、2010年の発行をもって21号となった。会社設立（1962年）から遅れること27年間のブランクがあるが、その間の生産技術については、現在ほど急速な動きは無いという前提で、創刊号に掲載された論文を起点とし、基盤技術、ソフトウェア開発技術、プロセスの変遷をたどっていく（2.1項）。また、当社のソフトウェア開発を支える生産技術（2.2項）、最近の取り組み（2.3項）を紹介する。　品質技術の深化については、MSS技報20号に「品質への取り組み」（1）としてまとめており、その引用を中心に品質システムへの取り組み（3.1項）、品質基盤システムの構築（3.2項）、最近の取り組み（3.3項）を紹介する。2．生産技術の進化2.1　MSS技報から見る技術の変遷　MSS技報は前号の21号までで164編の論文を掲載してきた。これらの論文よりその技術がどう変遷してきたか、基盤技術、ソフトウェア開発技術、ソフトウェア開発プロセス中心にまとめた。尚、これらの整理結果は当社が関わっている技術の一端であり、必ずしも全てではないことに留意されたい。【基盤技術】　基盤技術を語る前に、もっと基本的な話をする。MSS技報創刊の1989年は手書きの原稿であった。その後、パソコンの普及でワープロが当然のようになった。また、コミュニケーション手段についても、私が入社（1986年）した頃は、電話か直接出向いて会議形式であった。1980年代後半から電話回線によるパソコン通信 サービスが普及し、1990年代にはインターネットの普及にあわせて、MSSでも電子メールが一般化してきた。最近では、2009年頃にPC画面の共有が可能な社内TV会議システムを導入し、複数拠点に渡る会議で用いることが多くなっている。　さて、基盤技術について、過去のMSS技報をたどっていくと、ほぼ次の３つのキーワードに集約される。　・シミュレーション技術　・数理解析技術　・ソフトウェア開発技術　これに、事業分野の技術（いわゆるドメイン技術）が加わって、当社の生産活動を支えている。図１に宇宙・　49【ソフトウェア開発技術】　表１にソフトウェア開発技術に関わる論文を抽出した結果を示す。全８編で全体の約５%と多くはなく、さらに14号（2002年度）で漸く記事として掲載されている。このうち、50%が開発環境、フレームワーク、開発言語関連、残り50%はプロジェクト管理となっている。【ソフトウェア開発プロセス】　1990年代までのソフトウェア開発は、システム検討を行い、それに基づいて設計し、コーディングし、試験航空分野の業務に従事している部門の基盤技術及び関連技術を示す。これらを見ると基盤技術の上に航法・誘導、軌道力学、画像処理、熱・構造・制御等の知識・経験を加えて成り立っていることがわかる。当社は官公庁、独立行政法人、財団法人、大学、企業を主要取引先としている。即ち、独自技術をベースにした製品開発というより、主要取引先と一体となって開発することにより技術習得していった。図１に示した関連技術についても、主要取引先を広げる中で徐々に拡大していったものである。シミュレーション技術ソフトウェア開発技術数理解析技術基盤技術航法・誘導軌道力学推定・同定航法・誘導通信解析音響解析熱・構造・制御品質工学流体解析システム開発ロボット運動学画像処理輸送系航法・誘導全般　●月面着陸航法誘導解析　●･･ ･･●　地球観測衛星軌道解析●　月・惑星遷移　観測軌道解析●　実時間軌道推定システム設計・開発････ ･･●　恒星センサ高精度姿勢決定検討●　測位解析●　衛星観測画像処理アルゴリズム開発●　月面模擬画像生成●　回線設計解析●　衛星間、衛星―地上局間干渉・歪解析･･ ････ ･･●　JEM音響解析●　射点近傍音響解析●　柔軟構造制御シミュレーション●　衛星溶融解析●　宇宙機姿勢制御解析････キネマティクス解析　●････ ･･ダイナミクス解析　●大雨洪水警報システム　●天気図解析システム　●ロケットタンク挙動解析　●故障診断（田口メソッド）　●････図１　基盤技術及び関連技術（宇宙・航空分野の業務に従事している部門の例）表１　ソフトウェア開発技術に関わる過去のMSS技報掲載論文掲載号発行年月論文タイトル要旨（キーワード）14号2002/12 インテリジェントWebサービスの標準化に向けて・インテリジェントWebサービス・次世代Web構築処理言語MASKと実行環境ATOMS・オブジェクト間通信連携プロトコルSOAP（Simple Object Access Protocol）15号2004/3 ソフトウェア見積技術ファンクションポイント法の動向・FP法（ファンクションポイント法）・ソフトウェア見積技術17号2006/7 生産性向上ツールを有効活用したチーム開発事例の紹介・生産性向上ツール、情報共有、チーム開発スキル・EA（Enterprise Architect）、Eclips、CVS、PukiWiki17号2006/7 EVM（Earned Value Management）の基礎・プロジェクトマネジメント・獲得価値マネジメント・進捗管理18号2007/3 Sambaを利用した開発環境構築の事例・Samba、Subversion・ソース、ドキュメント管理19号2008/3 プロジェクトファシリテーションの紹介～身近なプロセス改善～・プロジェクトマネジメント・プロジェクト・ファシリテーション・見える化、変化への対応、プロセス改善・バーンダウンチャート、ソフトウェアかんばん、KPT（Keep/Probrem/Try）19号2008/3 工程管理手法CCPMの適用事例紹介・工程管理、CCPM（Critical Chain Project Management）・TOC（Theory of Constraints；制約条件の理論）20号2009/10 開発言語の変遷（アセンブラからJavaまで）・開発言語（アセンブラ、高級言語（Fortran、COBOL、C、Ada、C++、Java））・統合開発環境MSS技報・Vol.22 50る。ハードウェア製品開発を主としていない当社にとって、シミュレーション技術は設計結果の妥当性を検証するための重要な手段である。ただ、ここで言うシミュレーション技術とは、単純にダイナミクスモデルを構築して時間積分を行うというものではない。例えば深宇宙の解析では様々な惑星のエフェメリスや重力場のデータを適切に用いてシミュレーションを行わなければならない。また、溶融解析では構造物を部品に分解して材質や形状特性にあわせたモデル化、配置等を考慮してシミュレーションを行わなければならない。即ち、数学、物理の知識やドメインの知識を持ったシステムエンジニアリングの基礎があってこそ可能となる。　一方で、ソフトウェアの開発技術も重要である。ソフトウェアの大規模化、短工期化に対応するためにも、生産性向上ツールを有効活用することが増えてきている。統合開発環境、フレームワークを活用したソフトウェア開発実績は表１に論文が掲載されるよりもっと以前からあるが、多くは図２に示すように、生産性向上ツールを開発ライフサイクルに適用したものである。2.3　最近の取り組み　図３にプロセス改善および品質システムロードマップを示す。このうち、生産技術を進化させる現在の取組みとして、プロセス改善に関わる２件（組織ベースの対応、個人/チ－ムベースの対応）について紹介する。⑴　Automotive-SPICE（組織ベースの対応）　欧州の車載メーカがSPICEをベースに定めたソフトウエアプロセスモデル。ソフトウェア開発に関する要件がより具体化されており、当社改善のガイドと成り得ること、取引先の要望対応などで、2008年度より取り組み始め、2011年２月にレベル３を達成した。⑵　PSP/TSP（注2）の社内展開（個人/チ－ムベースの対応）　PSPは、CMMI（注3）を開発した、米国カーネギーメロン大学のSEI（注4）が新たに開発した手法で、各技術者が自身の生産性や品質を自ら認識し、それぞれが改善を行し、不具合があれば解消するという流れであった。すなわち要求されたものを納期（D）までに納めることが主であった。勿論、この開発の流れは今日も変わらないが、近年はソフトウェアが大規模化、短工期化してきており、それとともにバランスを取ったQCD（Q-品質/C-コスト/D-納期）達成が必須となってきている。従って、バランスを取ったQCD達成に向けて、開発管理すなわちプロジェクトマネジメントに焦点が当たっている。　さて、当社における仕事の進め方に関する規定がどのように変遷してきたかは、MSS技報20号「品質への取り組み」でまとめており、一部再掲する。⑴　MSS開発標準　MSSにおける仕事の進め方を示した規定としては、1979年3月に「MSS開発標準（MSSにおける仕事のやり方）」が初めて制定された。⑵　技術標準　1985年3月に「技術標準作成要領」が制定され、以後、当社における仕事のやり方は「技術標準」を制定して進めることになった。本社で制定する標準を「技術（社）標準」、事業所で制定する標準を「技術（所）標準」ということでスタートした。⑶　プロジェクト管理ハンドブック　1993年４月に「プロジェクト管理ハンドブック」として「システム開発作業標準」が本社から発行された。全ライフサイクルの作業工程、作成文書、審査、プロジェクト管理について折畳式（蛇腹式）の１枚の紙に記述されたもので、この内容は現在でも通用するものである。⑷　SW-CMM　3.1項のCMMI対応規定に示す。⑸　iCoPS（Information and Communication systemsProcess Standard）　情報システム開発プロジェクト向け電シ本共通の標準プロセス。特徴としては、以下のものがあげられる。当社では2006年４月より技術（社）標準として登録し、全社共通の標準に位置付けている。　①PMBOKやSLCPなどの国際標準に準拠　②上流プロセスに着目して、留意事項を明記し組織的な支援/監査プロセスを設定　③QCD+R（Risk）に関する定量的管理を実装する基盤を提供　④各組織でのベストプラクティスを厳選して要覧化。2.2　MSSのソフトウェア開発を支える生産技術　2.1項でMSS技報から抽出した基盤技術を紹介したが、この中でもキーとなるのはシミュレーション技術であ試験Eclipse要求分析 設計 製作CVSEAPukiWiki図２　開発ライフサイクルと生産性向上ツールの対応例（3）（注1）（注１）　【Eclipse】統合開発環境、【EA】Enterprise Architect、　　　　 UMLモデリングツール、【CVS】バージョン管理シ　　　　ステム、【PukiWiki】Wiki（WikiWikiWeb）クロー　　　　ンの一つ51⑵　CMMI対応規定　ISO9001の対応とは別に、関西事業部は米CMU/SEI（カーネギーメロン大学ソフトウェア工学研究所）がまとめたCMMに対応した規定の整備を2001年度から開始した。途中若干の紆余曲折はあったが、鎌倉事業部QMSをベースとしてCMMIに必要な部分を追加する形で規定を整備し、2005年２月にはSEIよりSW-CMMレベル４の認定書を得ている。なお、関西事業部はQMS全社統合に向けて、ISO9001の認証も2009年2月に取得している。3.2　品質基盤システムの構築　品質基盤システムの構築について少し詳しく述べる。⑴　背景　当社のQMSは2000年度以来各事業部がそれぞれで認証を取得していたが、「経営改善の効率化」、「品質改善の効率化」、「プロセス資産の蓄積」他を目的に、2009年度に統合を達成した。次のステップとしては、効率化に向けた課題に取り組んでおり、品質・生産性指標の収集・評価のための統一した仕組み作り即ち、品質基盤システムの構築もその一つである。⑵　 課題　⑴背景に示した課題のうち、品質・生産性指標のための収集・評価の統一した仕組みについて、現状は、システム/ソフトウェアのライフサイクルにおける品質・生産性にかかわるメトリクスの収集については、各事業部でまちまちであった。また、各事業部においては、品質、生産性データは現場技術部門で個々のプロジェクトうプロセスを提供する。約２週間のトレーニングにより、自らの課題を発見・改善し、世界基準での一流ソフトウェア技術者に「変身」することを目指している。TSPは、PSPエンジニアおよびTSPメンバトレーニングを受けたメンバで構成され、自律的にチームを運営するプロセスを提供する。　当社は2010年度より全社導入に向けて本格的に取り組み始めており、国内での早期導入グループに入っている。3．品質技術の深化3.1　品質システムへの取り組み　既刊のMSS技報で「品質への取り組み」をまとめており、一部再掲する。⑴　ISO9001 品質システム　1995年頃からグローバルスタンダードとしてのISO9001に基づく仕事のやり方がEU（ヨーロッパ）を中心に広まり、2000年に鎌倉事業部及びつくば事業部は認証を取得した（1994年版のISO9001）。ISO9001は「品質マニュアル」をトップレベルの文書とする「品質システム」文書体系を要求しており、鎌倉事業部とつくば事業部は技術（所）標準からISO9001要求に基づく事業部別「品質システム」に移行した。2000年度2001年度2002年度2003年度2004年度2005年度2006年1979～ 度 2007年度 2008年度 2009年度 2010年度 2011年度 2012年度 2013年度 2014年度 2015年度ISO9001対応ISO9001：2000年版対応品質マネジメントシステム（QMS)規格対応認証取得▲▲統合QMS認証取得(2009/12)社長QC診断品質基盤システムQC相互診断基盤ツールMSS開発標準(仕事のやり方）1979制定/1981改訂システム開発標準(プロジェクト管理HB)1993制定iCoPS iCoPS(2007年度版)標準プロセス▲技術標準作成要領（1985)技術（社）標準/技術（所）標準全社マネジメントレビュー△認証更新iCoPS(2011年度版)i-DoCK(iCoPS健康診断）△QMS/ISMS　同時審査▲品質保証規定（社規6301)に統合PSP/TSP▲CMMI Automotive SPICE(関事）ギャップ分析▲ギャップ分析 ▲レベル３達成(2011/2)関事BUの取組みSW-CMM(関事）▲ギャップ分析▲レベル４MSS白書ISMS/QMS統合マネジメントレビューSLCP,PMBOK準拠▲技術（社）標準化(2006)CMMI診断方式を採用▲自己診断化▲品質理念規則（社規3100)▲品質改善活動計画書の書式統一事業部主体のQMS（鎌事＋東事)事業部主体のQMS（つく事）事業部主体のQMS（関事）統合QMSJISQ9100追加要求対応社長品質方針▲鎌事認証取得(2000/3)▲つく事認証取得(2000/10)▲K&M認証拡大(2005/4)関事認証取得(2009/2)△JISQ9100認証取得　(2012/9)△QMS/ISMS　統合審査JISQ9100：2009年版対応ISO9001：2008年版対応図３　プロセス改善および品質システムロードマップ（注２）　【PSP】Personal Software Process、【TSP】Team　　　　 Software Process（注３）　【CMMI】Capability Maturity Model Integration　　　　（能力成熟度モデル統合）（注４）　【SEI】Software Engineering Institute（ソフトウ　　　　 ェアエンジニアリング研究所）MSS技報・Vol.22 52　②現場部門においては、基盤システムのデータを分析し、各部門の品質、生産性を容易に把握することができるようになり、部門、あるいはプロジェクトの品質、生産性にかかわる指標の設定や、品質計画に活用できるようになった。⑷　効果　この基盤システムの活用により、品質、生産性データの「見える化」が進み、プロジェクトから経営層までが同じデータを見てそれぞれの作業を進めることが出来るようになった。3.3　最近の取り組み　図３のロードマップに示したように、品質システムの更なる深化を目指して、２件の取り組みを行っている。⑴　QMSの高度化　JISQ9100追加要求への対応を進めており、2012年度認証取得を目指している。⑵　QMS＆ISMS統合化　課題として、複数のマネジメントシステムが存在しており、マネジメントシステムを維持・改善していくためには、内部監査、外部審査等、多くの労力を要する。これらを解決するために、マネジメント要求事項の共通部分の統合化を図り、さらに内部監査、外部認証の一元化につなげる。（図４参照）が記録、収集していた。このような状況において、具体的には以下の課題があった。　①会社単体としての品質能力、生産性を客観的に確認したり、事業部横通しでのデータを比較したりすることが困難である。　②部門ごと、あるいはビジネスユニットごとに全体を俯瞰して確認することが難しく、さらにプロセス改善推進部門（EPG）や品質保証部門（QA）、品質管理部門（QC）からも確認しにくい状態である。⑶　内容1）　品質に関わる全社基盤システムの構築　このような状況を改善するため、全社で収集する情報を統一し、かつその情報を一元管理するために、基盤システムを構築した。基盤システムの目的をまとめると以下の通りである。　①プロジェクトマネージャ/リーダへの支援　・プロジェクトの立ち上げ、管理計画策定の際、類似プロジェクトの情報を閲覧でき、プロジェクト管理計画の精度向上を支援する　・プロジェクト完了時に、プロジェクト完了報告書の作成を支援する　②部門管理者への支援　・プロジェクトの状況を把握し、問題の把握、リソースの再配置などの対応策立案を支援する　③ プロセス改善推進部門（EPG）、品質保証部門（QA）、品質管理部門（QC）への支援　・現在実施中の個々のプロジェクトのQCDRを確認し、プロジェクトの見通しに係わる支援を行う　④コーポレートへの支援　・事業全体をさまざまな角度（部門別、業態別など）からS/W生産力の分析、全社事業計画の構築を支援する。2）　全社基盤システムの活用事例　この全社基盤システムの構築により、全社において、統一された品質、生産性データが収集できるようになり、品質、生産性データの「見える化」が大きく前進することとなった。品質、生産性データの「見える化」に係わる事例としては以下のようなものがある。　①品質、生産性データを収集、分析し、当社全体としての品質、生産性の情報を確認できるようになった。この情報は、2010年度より「白書」として会社経営層に提示することができるようになった。（表２参照）Q I 他マネジメント要求事項の共通部個別要求事項統合化対象凡例Ｑ：QMS（品質）他：EMS（環境）I ：ISMS（情報セキュリティ）図４　統合化対象表２　品質基盤システムで収集したデータの分析例分析内容図表総プログラムライン数（実績）ヒストグラム基本統計量総工数（実績）出荷後不具合数全検出不具合数上流工程検出不具合数工期（実績）総プログラムライン数（実績）vs 出荷後不具合数散布図箱ひげ図基本統計量総プログラムライン数（実績）vs 出荷後残存誤り密度（件/KL）上流工程累積誤り検出率の分布ヒストグラム基本統計量完全流用率 vs 上流工程累積誤り検出率散布図53　上記９つの項目には、運用を含めシステムを理解した上での設計および妥当性評価の重要さ、計画や定量的把握、QCD+Rを含めプロジェクトを適切に管理すること他、ソフトウェア開発で重要なすべての要素が含まれている。即ち、これらを実現するための手法は発展してきたが、本質は変わっていない。　さらに付け加えるなら、生産技術（品質含む）は当社の重要なコアコンピタンスのひとつであり、これは過去からの学習と繰り返し繰り返しの改善が必要になる。そのベースとなる技術を維持するためにも過去の資産を管理し、常にそれを出せるようにしておくことが大切である。当社も近年のソフトウェア市場への対応で抜本的生産性向上を掲げているが、ミクロで見るとその一歩は現在の技術の延長線上にある小さな進歩でしかない。すなわち、過去を振り返り未来を予測することを愚直に繰り返すことが、先（将来）を見据えた技術の進化に繋がる。　発想のベースは目にすることから始まる。まったく形の無いところ（無）から何か（有）を創り出すことは出来ない。種（シード）は必ずある。過去の資産を蓄積し、それを有効活用することが本来の意味においてコアコンピタンスな技術を獲得することになる。参考文献⑴　MSS技報20号論文（品質への取り組み）⑵　MSS技報3号論文（技術者育成について）⑶　MSS技報17号論文（生産性向上ツールを有効活用したチーム開発事例の紹介）執筆者紹介若宮　正男1986年入社。技術部門配属、主として将来宇宙機の搭載ソフトウェア開発・飛行解析業務に従事。2007年より、スタッフ部門（現技術統括部）に異動、全社の品質・生産性等に携わる活動を推進。4．むすび　MSS技報の創刊号から技術をキーワードとして整理しながら、本稿を執筆した。キーワードを整理していて思ったことは、ソフトウェア開発技術で重要なポイントは昔も今も大きくは変わっていないということである。　一例を挙げる。以下はシステム工学について、1990年発行のMSS技報より抜粋したものである。（2）　システムエ学と云えばシステム解析のためのツールである数学理論の体系のように思う人が多いがそれは本質には程遠い。少し、乱暴かも知れないが次のような事柄のほうが本質的概念をよく表していると言える。⑴　目的優先主義である。（上位システムをよく知る）⑵　全体システムの中での位置づけを知る。（他との機能的、物理的インタフェースを知る）⑶　システムの運用、使われ方を考える。⑷　何かを行うに当たっては、必ず計画を立て、それに準拠して実行する。計画段階に、全ての要素を洗いだし、全体を通じて矛盾の少ないシナリオを作成する。⑸　初めからは100 点を狙わず、暫定案で開始し、一二回の繰り返しによって精度を得る。⑹　使えるデータや理論を有効に活用する。シミュレーションを多用する。⑺　初めに出来栄えの評価方法を考える。⑻　極力、物事を定量的に評価し、決断する。⑼　性能、費用、時間、リスク等多次元に亘る事柄について常に最適のバランスを考える。