S3000Lの構成管理

要約
情報の再利用の要は、部品化の粒度にありま
す。LSA の分野では、1970 年代からこの問
題に取り組んできました。先人たちの苦労に
耳を傾けてみませんか？
マメロジ代表本田博秀
LSA における
構成管理
情報の部品化は再利用を促進する
LSA における構成管理
訳者はじめに
「情報の部品化が再利用を促す。」
初めてこの言葉に触れたのは、2002 年の Arbortext 社ユーザ会で IBM 社が発表し
た”Taking advantage of XML to improve information”でした。OASIS グループに譲渡す
る一年前、当時 Arbortext 社の XML エディタに搭載した DITA を紹介したものです。
「再利用を促す」為に、“Separate content
from context for reuse” 「コンテンツを
文脈と分離せよ」とか、
“The topic is the smallest independently
maintainable unit of reuse” 「トピックは、
最小で独立して維持可能な単位」との事。
大変刺激的な内容でしたが、一体全体、そ
のトピックの実体は何？大きさは？とい
うのが、大きな疑問でした。
Figure 1
IBM 社発表資料からの抜粋
その後、Arbortext 社のビジネスを通じて、
ボーイング社の eMod, 米国 FDA による SPL, キャタピラー社の SIS/SMCS あるいは、航
空宇宙業界の標準化仕様 S1000D に関わる過程で、その疑問の原因が、情報の「粒度」と、
これを「特定する仕組み」だと痛感しました。欧米では、2000 年～2010 年の 10 年間で、
従来の DTP ベースの情報作成・配布から、再利用可能で、動的パブリケーションが可能な
XML ベースのシステムへの移行が実績を上げ、日本市場にも多く紹介されてきました。こ
れらは、正にこの粒度問題を克服した成功事例です。
私も一エンジニアとして、国内での XML ベースの情報部品化ソリューションに関わり、昨
今ようやく成果が得られています。その際、大きく役に立ったのが、
「如何にして粒度、す
なわち topic の大きさを決め、客観的に特定するのか? 」に関する、先人たちの知恵です。
ここで紹介する S3000L Issue1.1 の第四章は、公開文書化されている数少ない教科書で、
実装に活用しました。そのベースは古く、1976 年発行の MIL 規格です。
昨今、DITA 導入に関して、以下のような問題や懸念をよく耳にします。

部品化は進んだが、再利用は期待したほど進まない

結果的に、Copy&Paste でトピックの数が爆発的に増え、DTP 制作よりコスト高にな
っている

コンテンツ制作に必要な設計資料等の検索やリンクが適切に仕組めない
本書は、これらに対し解決策の一部を提示しています。すなわち、
1.
情報の粒度の決め方に、効果的な製品情報の分割方法がある
2.
分割方法は、利用者の視点により、機能分割、物理分割など複数発生する
3.
複数の分割で得た階層構造の相互参照を仕組む必要がある
4.
最終的には、一本化した製品階層構造を目指し、適切なコードシステムを構築せよ
といった内容です。
勿論、製品情報の階層化だけで適切な粒度が決まる訳ではありませんが、階層化により情報
の格納先が決定できます。DITA で言えば、トピックの格納先フォルダーが決定できるので、
ここを起点に再利用の促進が可能です。
尚、本書で翻訳する S3000L Issue1.1 の第四書は、
「LSA 構成管理」について記述している
もので、製品情報の階層化について多くの提案があります。対象が、重厚長大な製品（航空
機、船舶、軍用車両等）が多く、また読み手の対象が一般消費者でないなど、内容の多くが、
皆さんの直面する問題から乖離しているように思えるかもしれません。が、以下の点を読み
替えて頂くと、参考になる点も見えてくるかと思います。
顧客
S3000L の仕様を推進する母体が ASD と呼ばれる欧州の A&D コミュニ
ティであり、対象としている顧客は、NATO チームの各国防衛組織体。
契約者
大手航空機メーカ（ボーイング社、Airbus 社など）や、軍需産業機器を
取り扱うメーカ
部品供給者
部品メーカ (国内では、MHI, KHI などの重工各社)
プログラム
例えば「XX 地域偵察プログラム」というように、複数のプロジェクトに
よって、一つの目的を実現する行為。
プロジェクト
要求されたプログラムを実現する機能を担当。例えば「XX 地域偵察プ
ログラム」の「偵察機開発プロジェクト」や、
「偵察ネットワークシステ
ムの構築プロジェクト」等。
LSA
Logistics Support Analysis の略称。設計・製造と操作・保守サービス間
を繋ぐ活動全般。主に、保守サービスに必要な要素 (信頼性、部品在庫、
人スキル、流通、コスト等)を事前に分析し、適切なサービス計画を提示。
製品売上に比較し、保守サービス売上比率の高い製品 (航空機、船舶な
どの重厚長大製品や、コピー機などの事務機器等)では、サービス計画が
重要なファクターを占めている。昨今、その他の製品に関しても、サー
ビス部門の重要性を求めるトレンド(IoT の予防保全や、ISO26262 機能
安全等)で、LSA 的な活動が必要不可欠となってきている。
「訳者あとがき」では、実装に関する POC のアイデアについて触れています。再利用促進
の効果を事前に把握するためのパイロットの作り方の参考になさってください。
2016 年 10 月マメロジ代表
本田博秀
内容
LSA における構成管理........................................................................................................... 1
訳者はじめに .......................................................................................................................... 1
参照資料 ................................................................................................................................. 6
1
2
3
概要 ................................................................................................................................. 6
1.1
はじめに ................................................................................................................... 6
1.2
目的 .......................................................................................................................... 6
1.3
範囲 .......................................................................................................................... 6
構成管理の全般的な考察................................................................................................. 7
2.1
構成管理ルール ........................................................................................................ 7
2.2
構成制御 ................................................................................................................... 8
LSA プロセスにおける構成管理..................................................................................... 9
3.1
合意されたルールに則った階層化 ........................................................................... 9
3.1.1
用語の定義 ........................................................................................................... 9
3.1.1.1
製品/最終アイテム ............................................................................................ 9
3.1.1.2
製品バリアント識別子.................................................................................... 10
3.1.1.3
製品階層化 ...................................................................................................... 10
3.1.1.4
分割要素と識別子 ........................................................................................... 10
3.1.1.5
分割要素の改訂............................................................................................... 10
3.1.1.6
交換可能性に関する表現 .................................................................................11
3.1.1.7
部品 ..................................................................................................................11
3.1.1.8
適用（Applicability）に紐づいた製品 - 製品バリアントと構成の管理 .......11
3.1.2
製品階層のタイプ............................................................................................... 12
3.1.2.1
機能分割.......................................................................................................... 12
3.1.2.2
物理分割.......................................................................................................... 13
3.1.2.3
ゾーン分割による捕え方 ................................................................................ 13
3.1.2.4
装置／コンポーネントの取付け箇所と複数取付け ........................................ 14
3.1.2.5
機能分割と物理分割の混成手法 ..................................................................... 15
3.1.2.6
機能分割と物理分割の並行利用手法 .............................................................. 15
3.1.2.7
物理分割におけるファミリーの考え方 .......................................................... 16
3.1.3
3.1.3.1
製品階層化のための異なるアプローチにある背景 ........................................... 17
伝統的な LSA 製品階層化 .............................................................................. 18
3.1.3.2 PDM に基づいた製品階層化 .............................................................................. 19
3.1.3.3 S3000L における両方式の統合 ......................................................................... 19
3.1.3.4
システム内システムの分割 ............................................................................ 20
3.1.4
分割要素識別子（BEI）の活用 ......................................................................... 21
3.1.4.1
分割要素識別子（BEI）の書式...................................................................... 21
3.1.4.2
代替分割要素 .................................................................................................. 21
3.1.4.3
周辺装置アイテムの文書化 ............................................................................ 22
3.1.4.4
アイテムファミリーの識別 ............................................................................ 22
3.1.4.5
要求の統合化 .................................................................................................. 22
3.1.4.6
データ及び文章交換システムの確立 .............................................................. 23
3.1.5
分割要素識別子（BEI）の例 ............................................................................. 23
3.1.5.1
同族 BEI ロジックの無い分割 ....................................................................... 24
3.1.5.2
分割要素識別子（BEI）の基本的な書式 – 分割レベルの決定 .................... 25
3.1.6
3.1.6.1
分割要素改訂の目的 ....................................................................................... 27
3.1.6.2
適応性（Applicability） .............................................................................. 27
3.1.6.3
分割要素のタイプ ........................................................................................... 30
3.1.6.4
装置のタイプ .................................................................................................. 30
3.1.7
3.2
4
分割要素識別子（BEI）と関連コード .............................................................. 27
ソフトウェアに関する分割要素識別子（BEI） ................................................ 31
分割要素識別子 BEI - 構造の例............................................................................ 32
3.2.1
機能分割 ............................................................................................................. 32
3.2.2
機能と物理分割の混合 ....................................................................................... 33
3.2.3
相互参照（ハードウェアのみ）による物理および機能分割の併存 .................. 35
3.2.4
明示的な親子関係による物理分割 ..................................................................... 36
3.2.5
単一の物理的ハードウェアアイテムの一部としてソフトウェアを統合........... 37
3.2.6
複数の物理的ハードウェアアイテムの一部としてソフトウェアを統合........... 37
3.2.7
機能分割におけるソフトウェアの統合 .............................................................. 38
LSA における構成変更 ................................................................................................. 40
4.1
構成変更による影響の評価.................................................................................... 40
4.2
構成変更の原因／要因 ........................................................................................... 40
4.2.1
顧客からの変更要求 ........................................................................................... 41
4.2.2
設計変更要求 ...................................................................................................... 41
4.2.3
（許容範囲内の）製造上の設計からの逸脱..................................................... 42
4.2.4
部品供給元の変更............................................................................................... 43
4.2.5
サービス中の変更（サービスブリテン） ........................................................ 43
4.3
変更原因を起点に関係する LSA 変更に至る追跡 ................................................. 43
4.4
LSA プロセス実施中の構成変更手順 .................................................................... 44
4.4.1
一般的な局面 ...................................................................................................... 44
4.4.2
変更に伴う編集 .................................................................................................. 44
4.4.3
拡張された適応性の管理.................................................................................... 45
4.4.3.1
概要 ................................................................................................................. 45
4.4.3.2
製造シリアル番号と、フリートシリアル番号の考え方................................. 45
4.4.3.3
変更／基準の有効性 ....................................................................................... 47
4.4.3.3.1
例: 設計基準の適応性を LSA 適応性へ ..................................................... 47
4.4.3.3.2
例: 設計基準の適応性を IP/IPD 構成アイテム（CSN/ISN）適応性へ .... 48
4.4.3.4 MSN vs. FSN 適応性管理................................................................................. 49
用語解説 ............................................................................................................................... 50
訳者あとがき ........................................................................................................................ 54
POC の例 .......................................................................................................................... 54
参照資料
表 1
参照資料
章番号／文書名
タイトル
章 3
LSA ビジネスプロセス
章 13
ソフトウェアサポート解析
章 19
データモデル
S1000D
共通ソースデータベースによる技術パブリケーション国際仕様
S2000M
S2000M - 部材管理のための国際仕様
1
概要
1.1
はじめに
構成管理（CM: Configuration Management）は、異なる製品構成が正しく識別され、変更
管理を確実に施すための活動であり、製品の構造、システム、サブシステムおよび装置やコ
ンポーネントにおける物理的及び機能的な特性の実装履歴を記録します。
構成管理に注力することで、様々な決定事項や設計に関する修正が如何に行われたかを追
跡することができます。
構成管理は、製品を階層化した構造の最下位レベルから始めます。対象となる「もの」は、
製品要件、設計、製造、サポート及び変更要件に際し識別できる部位であり、製品の機能及
び操作や、ILS（統合的後方支援:Integrated Logistics Support）活動へ影響します。 ILS
の一部である LSA（後方支援解析:Logistic Support Analysis）は、プロジェクトのライフ
サイクル全域で構成管理プロセスを担います。
1.2
目的
本章は、製品の階層化を通じて LSA 構造を生成し、構成管理プロセスである LSA が製品
の構造化に重要な役割を担うことを示します。製品階層は、他の ILS 活動で利用する製品
構造の基本です。サンプルでは、サポートシステムと同様に製品の運用に必要な構成管理を
示しています。本章の内容は、特定のプロジェクト要件に沿って読み替えてご利用ください。
1.3
範囲
本章の対象者は、ILS 及び LSA 管理者ですが、同時に他の ILS 各領域のマネージャにも役
立つでしょう。対象とする内容は、LSA 構成管理ですが、LSA 自身が ILS プロセスのコア
部分であり、他の ILS 領域とその構成管理活動に大きく影響します。更に他の ASD
（Aerospace and Defense Industries Association of Europe）仕様と強く関連しており、ガ
イドラインやルールの多くが、他の ILS 領域にも適応できるでしょう。
2
構成管理の全般的な考察
構成管理は、全てのプロジェクト領域（例、設計、製造、ILS 等）で、正確で協調した製品
階層構造を提供します。また、製品を定義するベースラインを設定し、維持します。これら
のベースラインは、全ライフサイクル期間を通じて、必要に応じ開発され、採用されます。
構成管理は、プロジェクトの開始と共にスタートし、製品ライフサイクルの全フェーズを通
じ実施します。ILS は、初めから構成管理プロセスに含まれ、構成管理ルールの決定と確立
に関わります。
2.1
構成管理ルール
全プロジェクト領域で、正確に構成の変更追跡ができるように、明瞭な構成管理ルールを確
立する必要がありますが、これは、初期の幾つかのプロジェクトフェーズの中にあって、プ
ロジェクトレベルで行います。
マイルストーン計画は、契約者や顧客に提供が義務づけられたドキュメントに掲載される
タイムスケジュール付きのプロジェクトおよび設計マイルストールに従って立てる必要が
あります。マイルストーン及びドキュメントテーションの配布そのものも、構成制御の管理
下になければなりません。
効果的な構成識別子は、全ての他の構成管理活動に必要です。もし、この識別子および関連
する構成ドキュメントが正しく与えられないと、製品構成の変更制御や正確な記録・報告が
不可能になります。すなわち、監査による構成の検証ができません。
不正確で不完全な構成ドキュメントは、結果として欠陥製品、計画の遅れ及び高コストな保
守費用を生みます。主たる構成識別のルールを表 1 に示します。
表 2 構成識別ルール一覧（手順）
ルール
説明
構成アイテムの識別
アイテムの識別子は、設計構成を念頭に、S1000D や S2000M
（機能的及び物理的）
のような ASD 仕様に準じる必要があります。
例えば、S1000D
の標準番号システム（SNS）を機能構成及び物理階層に採用
できます。 S1000D 参照方。
機能構成と物理構成間の
同一アイテムでありながら、機能構成及び物理構成は異なる
関係
視点で扱います。したがって、両社の構成間に求められる管
理とリンクに応える必要があります。
設計と LSA 識別子の関係
設計構造と LSA 構造間で、変更追跡を確報するルールが必要
です。
ゾーンとアクセスパネル
ゾーンによる製品の構造化に伴って、アクセスパネルを識別
の識別
化する追加的な構成管理手法です。サンプルでは、如何に製
品を S1000D で定義されたゾーンで構造化するかを示しま
す。
バリアント及び代替アイ
バリアント及び代替アイテムの識別化ルールは、プロジェク
テムの識別
トの開始時点で必要です。同じ機能に対する異なる技術的解
決策を選別するのに重要です。
トップレベルの構成識別
プロジェクトの開始時点で、トップレベルの構成管理のタイ
プの確立が必要です。トップレベル構成管理は、製品バリア
ント及び他の様々な製品グループの識別に役立ちます。
適切な構成識別為のドキ
適切に構成を識別するためのドキュメント、例えば ASD 階
ュメント
層化ドキュメント、イラスト付き部品データ（IPD）など、は
プロジェクトの開始時に定義する必要があります。
2.2
構成制御
構成制御は、変更要求の評価、変更提言およびその後の承認／拒否を含みます。これにより、
ベースラインへの影響すなわち、後方支援や変更に伴うコスト、スケジュール、成果さらに、
関係企業とのインターフェイスなどに対し、事前に十分検討された変更が実施できます。
変更実施を要求された当事者は、その規模と変更そのもの特性などで対応が異なりますが、
プロジェクトを推進する顧客組織ならびに開発者が、その変更に対し適切なレベルにある
か否かという点が重要です。意思決定プロセスは、
「プロジェクト管理システム」全体の管
理と密接な関係にあります
3
LSA プロセスにおける構成管理
LSA は、プロジェクトの開始時点から構成管理プロセスに含まねばなりません。構成の基
礎部分は、製品階層の作成です。製品の構成を定義する際、ルールの確立が欠かせません。
このルールにより、全プロジェクト領域（設計製造、ILS 等）を通じ、製品構造に対するト
レーサビリティが確保できます。
確立したルールに従い、LSA は、複数の製品構成を保守する為の製品階層化の開発が必要
です。全 ILS 領域の為に、この製品階層が基盤となることが極めて重要です。
3.1
合意されたルールに則った階層化
体系的な製品階層化は、LSA のプロセスと提供に欠かせません。
-
システム、サブシステム、機能、ハードウェア及びソフトウェアコンポーネントに関し、
如何に製品を構造化するかについての明瞭な理解。更に、LSA プロセスに含まれる機
器（複雑なトレーニング装置やサポート装置）にも適応できること。
-
階層上のハードウェア要素と実際に製造されるハードウェア部品との明瞭な関係
-
階層上のソフトウェイ要素と実際に組み込まれるソフトウェアとの明瞭な関係
-
ユニークあるいは統合された識別子の割り当てを可能にする。これにより、構成の資源
を提供する設計部門と、LSA 及び後方支援活動とのインターフェイスが可能になる。
後者では、技術ドキュメント、物品調達、トレーニングあるいはサポート機器などを担
当している。
-
LSA 候補の選別のために、詳細化の適切な階層化レベル設定を可能にすること
-
製品バリアント及び製品構成に対する識別子の導入
-
製品階層の特定のバージョンに対し、対応する ILS 対象製品の的確なバージョングル
ープとの関係を構成管理で可能にする。製品階層化及びその ILS 製品がベースとする
ドキュメント、設計情報及び製品利用に必要な諸元値などのソースデータについても
同様に、構成管理で可能にする
製品の異なる階層化は、別目的に対し実施されています。多くのプロジェクトでは、製品デ
ータ管理（PDM）システムによって、製品の設計階層化を行うのが一般的です。同じ製品
に対し、LSA 階層化が実施されたり、同様に操作や保守データをフィードバックするため
の製品階層化が行われたりする場合があります。別目的での異なる階層化は、時として相互
のミスマッチを生み、製品に関連するデータの取り扱いで、相互のコミュニケーションが複
雑になります。
本章では、LSA の視点から製品の複数の階層化定義が必要になる状況と、LSA プロセスで
設計が定義した階層化を再利用する状況の双方について記述します。
3.1.1 用語の定義
3.1.1.1 製品/最終アイテム
製品（最終アイテム）は、システム、サブシステム、コンポーネント部品／構成要素及びソ
フトウェアの最終合成物です。
（例: 船、車、機械、飛行機や他の複雑な技術システム）
そ
の製品は、階層化されたあらゆる製品構成のトップレベルを表します。
3.1.1.2 製品バリアント識別子
製品バリアント識別子は、コードであり、製品バリアントをユニークに特定します。製品バ
リアント識別子は、全ての ILS プロセスで利用される別の識別子たとえば S1000D 仕様の
システム相違コード（SDC）などと連携して利用されることが望まれます。
3.1.1.3 製品階層化
製品の階層化は、製品そのものと階層化リストから成ります。階層リストには、例えば、ア
センブリ、サブアセンブリ及びコンポーネントが含まれますが、これらは分解・組立や交換
の対象となります。階層化の捉え方によって、構成要素がシステム、サブシステム、機能及
びゾーンとして階層を構築することもできます。製品階層化のタイプ毎のサンプルを 3.1.2
で説明しています。
LSA データベースにおいて、製品階層化に必要な深さは様々で、例えば、構成要素のサポ
ートあるいは製品化の要求に影響されます。ですが、階層化ルールとして、プロジェクト内
の分割要素識別子（BEI: Breakdown Element Identifier）の構文に従うのが望ましいでし
ょう。
3.1.1.4 分割要素と識別子
BEI は、製品階層化で定義される個別の分割要素（BE: Breakdown element）の識別子で
す。一つの BE が機能的あるいは物理的な複数の子 BE を含みます。物理的な BE の典型例
は、装着場所を示し、装置の部品として現実のハードウェアアイテムとして取り付けられま
す。
これらの BE 及び BEI は、技術ドキュメントや材料サポートのような他の後方支援活動と
協調する必要があります。更に、製品の設計／製造ビューと ILS ビューの間で出来るだけ
共通に利用できることが望まれます。
BEI は、様々な後方支援活動の部品であるアイテムをユニークに特定します。 3.1.2 では、
系統的製品階層化の異なるタイプを示します。このタイプによって、BEI の確立に異なる
ルールが適応できます。 3.2 参照方。
3.1.1.5 分割要素の改訂
分割要素の改訂（BER: Breakdown Element Revision）は、BE の新しいバージョンを定義
します。BER は、開発進捗状況（しばしば、設計イテレーションとして参照されます）と
連携します。BER の利用は構成管理をサポートし、とりわけ製品の設計変更と、LSA 解析
結果への影響を同調させる上で役立ちます。
ノート
BER と、階層化内の代替コンポーネントを記述するための手法を混同してはいけ
ません。代替コンポーネントには、例えば、MIL-DTD 1388-2B の代替後方支援
コントロール番号（ALC: Alternate Logistic Control Number）や、S1000D の分
解コードバリアント（disassembly code variant）があります。代替コンポーネン
トが必要となる状況とは、同じ場所の分割要素に、二つの異なる実装がある場合
で、例えば、複数のメーカによって異なる実パーツ（訳者注: 仕様と役割は同じ部
品の意）が提供されている。S3000L では、代替コンポーネントを部品（ハードウ
ェアまたはソフトウェア）に関する関連実装化の手法として扱っています。
3.1.1.6 交換可能性に関する表現
後方支援の活動エリアでは、装置やコンポーネントの交換について一般的に使われる用語
があります。表 2 を参照方。
表 3
交換可能アイテムに関する一般用語
用語
フル名称
内容
LRU
Line Replaceable Unit
製品のままの状態で、直接交換可能なユニット
SRU
Shop Replaceable Unit
製品のままでは交換できず、交換に際し、上位のコ
ンポーネントの取り外しが必要となる。
ノート
LRU や SRU の代わりに、LRI （Line replaceable Item）や SRI （Shop
replaceable Item）も、使われます。
3.1.1.7 部品
部品は、製品階層化により定義された BE の実際の具現物であり、ハードウェア及びソフト
ウェアの双方に使われます。
3.1.1.8 適用（Applicability）に紐づいた製品 - 製品バリアントと構成の管理
適用に紐づいた製品（しばしば、有効性（effectivity）とも呼ばれる）は、異なる製品バリ
アントの実装に際し、BE を構成する情報（下位の構造）に影響します。特定の製品バリア
ントに対し、製品階層上の任意アイテムの適用を制限する場合に使用します。BE とその適
応に関するサンプルを Para 3.1.6.2 で示します。
ノート
顧客と契約者間の構成管理の見解と構成管理の重要性については、双方で、明
確にしておく必要があります。
稼働製品の構成管理ツールとして、LSA データベースを利用するのはお勧めで
きません。例えば、顧客が実際に利用している製品に含まれる実部品情報に基
づく構成を LSA データベースに保存するといった行為です。※訳者注: LSA デ
ータベースでは、バージョン管理が無いかまたは不十分という点を指摘してい
ると思われる。
3.1.2 製品階層のタイプ
製品階層を、機能的分割と物理的分割として捉えることができます。両者のアプローチを図
1, 図 2 に示します。 LSA データベースでは、両手法とそのコンビネーション（いわゆる、
ハイブリッド製品階層）について実証する必要があるでしょう。
同じ階層や一つ上の階層あるいは、下位の階層にあるアイテム間の相互関係あるいは親子
関係は、採用する BEI や BE に実装される実部品によって様々です。製品階層化は、プロ
ジェクトの要件に依存しますが、推奨すべき以下の手法があります。
-
機能分割のみによる階層化
-
物理分割のみによる階層化
-
混成階層化。機能分割及び物理分割双方が一つの階層構造に同時に存在する（しばしば、
ハイブリッド階層と呼ばれます。
）
-
機能分割のみの階層と、物理分割のみによる階層の並行利用で、相互参照マップによる
連携
ソフトウェアについては特に注意が必要です。最先端の製品に、ソフトウェアは欠かせませ
ん。このことは、他の後方支援解析でも同様です。ロード可能なソフトウェアパッケージの、
インストール／アンインストールが保守の対象であれば、製品階層に統合する必要が出て
くるでしょう。ソフトウェアのハードウェアへの割り当ては、製品階層内に明瞭に示す必要
があります。ソフトウェアの変更がもたらす構成変更は、階層化とは別の問題です。ハード
ウェアに修正がなくとも、そのハードに統合されたソフトウェアへの変更は、製品階層内に
文書化される必要があります。
3.1.2.1 機能分割
機能分割は通常、製品そのものを分割木のルートにして開始します。製品の各機能に対し、
その主要な機能からサブ機能に必要な深さで分割していきます。ハードウェア要素は、機能
分割上に現れません。図 1 に単純な例を示します。
図 1
単純な機能分割
3.1.2.2 物理分割
物理分割も、機能分割同様、分割木のルートに製品レベルを置き開始します。通常、原則と
してアセンブリを利用して分割し、構造化すると言って差し支えないでしょう。
（訳者注: 上
位のアセンブリをユニットと表現する場合もあるが、これもアセンブリの一つとして扱っ
ている。
）図 2 では、二階層目に「タンクアッセンブリ」が配置され、その下位で「ラバ
ータンク」
、
「カバータンク」
、
「ドレインバルブ」及び「ブランキングプラグ」にサブ分割さ
れています。
図 2 単純な物理分割
3.1.2.3 ゾーン分割による捕え方
製品に対し定義されるゾーンの並びに沿って分割することをゾーン分割と呼びます。LSA
データベース内に確立されたゾーン分割の深さと構造は、設計や整備のための製品分割等
とは異なる方法です。
ゾーンの BE は、
（例: 定期的なゾーン別検査を）ある物理空間に着目して、そのゾーンに
対する保守を実施します。したがって、LSA データベース内では、物理分割による BE と
ゾーン分割による BE という分割木の各要素で、互いに連携できることになります。
3.1.2.4 装置／コンポーネントの取付け箇所と複数取付け
通常、取付け箇所は、物理製品分割時の主要な情報です。装置／コンポーネントを複数取付
けする場合、以下の異なる二点を考慮する必要があります。
-
数量付きで単一 BE 表現
例では、同じタイプのタンクが 3 つシステム内に使われています。図 3 の以下のタ
ンクでは、下位構造が同じです。このように対応する数量を情報として含めておけば、
単一の BE とすることで十分であるというケースも少なくありません。
図 3
-
分割手法 - 単純な親子主義
複数の分割要素:
各タンクを異なる要素として配置します。図 4 のこの手法では、取付け箇所に焦点が
あります。（例、取付けや取り外し作業が、取付け箇所に寄って異なるといった場合）
図 4
分割手法
- 拡張された親子関係主義
3.1.2.5 機能分割と物理分割の混成手法
広く利用されている製品分割アプローチで、単一の分割木の中に、図 5 のように機能的か
つ物理的景観が混在しています。一般的には、システム、サブシステムレベルに機能的な性
格を持ち、装置やコンポーネントに物理的な BE を配置します。それでもなお、システム
を明確な「機能」で表現せずに、共通の特徴を集合してとらえたコンポーネンの集まりとし
て（例、エンジンシステム等）表すことも出来ます。この場合、システムは、機能やコンポ
ーネントの集合として扱います。しかし、依然として明確な機能でもなく物理的なコンポー
ネントでもないシステム BE も存在します。
図 5
分割手法 – 機能分割と物理分割の混成手法
混成手法を採用する場合、まずは幾つかの基本的なシステムとサブシステム（推進システム、
電気系統、構造、油圧システム、燃料システム等）を製品の機能構造から導出すると効率的
に構築できます。システムの大きさに寄って、分割の深さは様々で、実際のハードウェア用
BE の割付け始める分割レベルも異なります。典型的な分割パスである、システム‐サブシ
ステム‐装置‐コンンボーネントは、常に正しいとは限りません。したがって、LSA の活
動対象となる分割レベルの位置も、システムによって異なります。
3.1.2.6 機能分割と物理分割の並行利用手法
機能分割及び物理分割を並行して確立することで、他の異なる分析目的を同時に満たすこ
とが出来ます。この場合、重要なことは、両分割間を効果的に連結する仕組みです。物理的
な BE は、機能的 BE に連結していなければなりません。
こ手法は、トラブルシューティング分析の良い基盤となります。機能分割に従って、トラブ
ルシューティングは、不具合機能の特定をすることになります。両分割の連携が取れていれ
ば、分析者は、機能分解の要素に紐づいた物理分解の要素を特定することが出来ます。同様
に、機能及び物理分割の並行利用で、ハードウェアを機能に紐づけることも出来ます。例え
ば、機能「燃料供給」図 5 で、燃料パイプのような典型的な要素を含んでいると同時に、
電源供給エレメントを含むことが出来ます。電源供給は、ハードウェアとしては全く異なる
エリアに属しているのですが、機能分割上は、「燃料供給」グループに含めることが出来る
のです。
異なる製品階層手法同志の相互参照は、S3000L に準拠する後方支援データベース構造で検
討する重要な課題です。
3.1.2.7 物理分割におけるファミリーの考え方
物理分割を詳細に実施するのは、尽力が必要ですが、これを軽減するため、可能であれば、
ファミリー構想を導入すると良いでしょう。これを採用するか否かを決めるファクターに
は、次のような点があります。
-
類似した共通の保守で扱えるアイテムは、ファミリー BEI 構想としてグルーブ化して
よい
-
標準交換部品は一つの BEI 構想でグループ化して良い。図 6 参照方。
図 6
交換部品グルーピングの考え方
ですが、単一 BEI として複数アイテムをグループ化したことを、LSA データベース内の適
切な個所に文書化しておきましょう。後方支援活動で必要な情報は、このグループ BE 内に
明記します。
3.1.3 製品階層化のための異なるアプローチにある背景
3.1.2 で記述したように、製品階層化は、異なる目的で作成されます。個々の階層化は、特
定の活動領域で定義され使われてきました。しかしながら、これらの階層化間の連携は、し
ばしば、取られていません。これにより、データ交換や異なる領域での経験の共有といった
点で問題が発生しています。例えば、
-
製品の部位を表現する BE は、異なる階層化では、時として異なる方法で定義さている
-
異なる階層化手法により、互いの類似点や相違点を特定することが困難という事態に
陥る
製品階層化の試みは、このように異なる要求によって営まれてきました。設計や開発の作業
領域では、例えば、技術的／後方支援的分析の運営をサポートする領域とは異なる製品階層
を採用しています。このような事から、それぞれ特定のビューとして製品階層の構造を視覚
化している訳です。S3000L の実装では、これを課題として捉え、可能な限り関係を明確化
すると共に柔軟性を確保する必要があります。製品階層化の主たる二つの手法を一つのデ
ータモデルに統合すること、すなわち両ソリューションを同時にサポートすることは、
S3000L の重要な狙いの一つです。
-
アプローチ 1:
伝統的 LSA の構造化された BEI（例えば、S1000D 仕様における SNS（標準番号シス
テム: Standard Numbering System）や、MIL-STD 1388-2B で示された LCN/ALC
構造、あるいは DEF-SAN 0060 等に類似）による製品の構造化。機能的かつ物理
的領域が一つの共通製品階層上に統合されている。階層化のレベルは、各要素に指定さ
れた BEI の書式によって暗黙に指定される。
-
アプローチ 2:
設計指向あるいは PDM ベースの製品階層化で、明確な親子関係を示す方法。この階層
化では、各 BE とハードウェアコンポーネントあるいはハードウェアコンポーネント
間の関係が軸になります。コンポーネントの識別子に、アプローチ 1 のように階層レ
ベルを表す書式を通常使いません。識別子には、階層要素を実際の部品などで表現する
名称が使われ、最下位レベルでは通常、部品名称が使われます。
この二つの基本的な製品階層化手法の相違を、以下の概要図 7 で示します。
図 7
製品階層化 – 伝統的 LSA 手法と PDM 手法
3.1.3.1 伝統的な LSA 製品階層化
伝統的な LSA による製品階層化は、暗黙の分割手法を使っています。暗黙の分割では、BE
の場所を該当の BEI の書式によって定義します。
（訳者注: 暗黙のうちに、階層レベルを表
すコード体系になっている意。
）現存する MIL-STD 1388-2B や、DEF-STAN 0060 など
の標準仕様のいずれかを利用して構築するこができます。これらベーシックな標準では、
LCN と呼ばれる BEI で各階層の要素を表現します。他のアプローチに、S1000D の標準番
号化システム（SNS）があります。
LSA プロセスの因果関係から言うと、設計フェーズでの製品階層化は、LSA 作業が開始
する前に完了している必要があります。これは、LSA が一旦開始さると、分割木に対し、
後で中間レベルを追加することが極めて困難になるためです。
もう一つの理由は、構造化された BEI の利用の結果、他の異なる製品間で、この BEI の
再利用が単純な方法では難しいという点です。
システムの二次・三次の請負業者は、一次請負業者の BEI 構想に従い、この分割木と協調
し、作業プロセスおよびドキュメント作成しなければなりません。結果として、提示され
た製品階層化の更新と維持への準拠には、多大な費用が必要となります。
ノート
伝統的な製品階層化構想では、設計改善に対応する BE の改訂を表現する手段
がありません。従って、設計変更に同期することが困難で、開発状態の推移に着
目した BE の改訂管理では、必要な変更トラッキングができません。
3.1.3.2 PDM に基づいた製品階層化
昨今の PDM システムでは、製品を構成する要素間を親子関係で明らかにします。従って、
対象とする分割要素に対し、何等かに意味のある名前付けをせずとも、階層化ができます。
ただし、親子関係を示すうえで、分割要素に対し以下の点を明らかにする必要があります。
-
その子要素に対する関係性
-
各親子関係の情報に、子要素の数と実装箇所を含むこと
ノート
ユニークな BIE が設計フェーズで定義される場合がありますが、
しばしば PDM
システムによって、ランダムコードが生成されており、
「意味のある」名前とは
呼べません。
分割要素（BE）は多くの場合、システム、サブシステム、ハードウェアおよびソフトウェ
アの各明細として定義されます。それ故、階層化のレベルは、アッセンブリ（ハードウェア
不部品）または、ソフトウェアパッケージ（ソフトウェア部品）に対応する要素までです。
アセンブリやソフトウェアパッケージは、順繰りに定義済み部材やアッセンブリ構造を持
つこともできます
明示的なこの製品分割のメリットは、すべての要素および部品が、他の実装場所や多くの他
の階層構造（異なる製品モデル等）で再利用可能であることであり、そのために新たな要素
の追加を必要としません。また仮に中間レベルに要素を必要とした場合でも、プロジェクト
の遂行に何等余計な作業を発生せません。
請負業者に対する製品分割と部品に関する情報交換はシンプルです。というのも、発注元の
契約者側の部分木が、そのまま請負業側の木のルートとして扱うことができるからです。
このことは、意味あり名前付けした要素を持つシステム（訳者注: 伝統的な SLM 機能分割
を指す）との情報交換に比較し、極めてコストを低く抑える効果があります。
3.1.3.3 S3000L における両方式の統合
S3000L データモデルではそれ自体、両方式を個別にサポートしているとは言いながら、実
際にはこれらの統合方式を推奨しています。これらを成就させるためには、各フェーズで以
下の事柄が重要です。
LSA の初期段階:
-
設計で定義された分割要素、分割要素名で、製品階層化を進める（ただし、設計変更を
追跡するためのバージョン管理用の識別子を導入すること）
-
LSA に必要な要素が必要となった場合、

最初に、設計で定義された製品構造に組み入れ可能か検討する

次に、設計がこの要素の追加が妥当と判断した場合、現行の分割と分離したブラン
チとして生成し、中間要素として、挿入しないこと。安易に挿入すると設計からの
変更時に分割管理が複雑になる。
-
設計で作成した製品階層構造に対し、新たに要素追加が必要となった場合、可能な限り、
請負業者が利用している BEI への影響を考慮して協調すること
-
アッセンブリ、サブアッセンブリおよび部品番号による部品コンポーネントには、分割
のポジションを示す名称を付加しないこと
LSA 分析結果の配布時:
-
製品自身から始め、系統的な名称システムを BE に適応し、必要な階層まで分割し名称
付けを行う。どの階層で分割を停止すべきかの指針は、その要素がハードウェアまたは
ソフトウェア部品に至った場合。
-
BEI を部品に割り振らない（部品番号を持つ実際の部品の意）
この手法は、LSA プロセス過程で必要な柔軟性と各 LSA 領域をまたいだ解決に役立ちま
す。
3.1.3.4 システム内システムの分割
システム内システムは、複数の分散した独立製品に含まれ、より上位の複雑なプロジェクト
の一部として機能するアプローチです。
（例えば、同じエンジンが、二つの異なる飛行機に
使われている等）
図 8 は典型的な例です。異なる二つのプロジェクトが同じ製品、この場合は飛行機のエン
ジンを使用しています。図では、単一で同一の現存する製品階層が両プロジェクトに取り込
まれています。
図 8 システム内システムの分割
3.1.4 分割要素識別子（BEI）の活用
製品分割を構造化するデータ要素に、BEI があります。BEI は、分割要素 BE をユニーク
に特定します。あるアイテムと他のアイテムとの関係が上位または下位であるとき、BEI 書
式（伝統的なアプローチ）によってか、または親子関係（PDM アプローチ）で、そのレベ
ルが示されます。
3.1.4.1 分割要素識別子（BEI）の書式
伝統的な製品階層化アプローチでは、異なる分割レベル間の関係を BEI 書式で定義します。
数値および文字タイプが各レベルを表します。BEI 書式は、できるだけ早い段階で確定す
る必要があります。プロジェクトのすべてのフェーズの開始時点では、適切な書式が提供さ
れねばなりません。各階層レベルのために必要な文字数以上の余分な文字を導入するのは
避けましょう。BEI 書式は、収納力、一貫性および十分な広がりを持ち、全プロジェクト構
造を番地付けできる必要があります。LSA 用 IT アプリケーション側の制限が、BEI の長さ
や書式に影響する場合は、制限内に収まるよう事前に考慮しておきましょう。
ノート
伝統的な LSA 製品階層化を利用するプロジェクトにとって、BEI 書式のいかな
る変更も、異なる LSA IT システムや関係する ILS 領域内で、広範な再作業を
強いることになります。ある階層レベルで、初期計画よりも多くの桁数を必要
とするといったリスクは、好ましくありません。この様な場合、初期段階から、
補助的な桁を用意して、プロジェクトの広範で発生する BEI 書式問題に備える
3.1.4.2 代替分割要素
ことができます。
伝統的な LSA 製品階層化を活用したプロジェクトでは、代替 BE を定義できるように対応
することになります。これらは、例えば旧来から利用されている MIL-STD 1388-3B の ALC
や、S1000D における分解コードバリアント 1（Disassembly Code Variant）の定義に類似
した内容になるに違いありません。
この種類の階層化では、果たすべき機能と、機能を実現するコンポーネントの違いを区別し
ないことから、いわゆる代替分割要素（MIL-STD 1388-2B の LCN/ALC や、S1000D の
分解コードバリアント）を導入する必要があります。MIL-STD 1388-2B 内では、ある代替
BE は、同一 LCN を使用しつつ代替 BE の実装を明示するために異なる ALC を使用しま
す。同一 LCN は、代替 BE が、製品分割上の同一実装箇所にあることを示しています。
代替 BE は、特定の実装箇所にあるアイテムを、例えば複数のメーカが提供するという事態
に対応する為に欠かせません。しかしながら、個々のメーカが提供するアイテムは（形状、
フィット、機能およびインターフェイスは、まったく同一ですが）、異なる後方支援上の考
慮を必要とします。S3000L では、この状況を示すための新たな BEI を必要としません。
製品階層の同じ位置に実装される代替アイテムは、異なるハードウェア（またはソフトウェ
ア）による異なる実体として組み込まれます。S3000L では、このような実装に 2 つの方法
で対応しています。
-
個別の BEI を持つ追加 BE の導入。異なる製品バリアントと連携し、製品に紐づいた
適応性（Applicability）で識別する。
-
単一の BE に対し、異なる部品（例えば、異なる製造メーカ提供）による実体として導
入。これらの部品は、必要であれば、異なる後方支援上の考慮を実証するために部品レ
ベルで、LSA の解析候補にもなる。
ノート
単一で全く同じ箇所に実装が可能な代替部品を実証の対象とするか否かを検討
する際、これらの部品が全て同じ形状、フィット、機能、インターフェイスおよ
び後方支援上の考慮であるならば、当該 BEI に対する後方支援データ解析で、
改めてこの代替部品を対象にする必要はありません。
3.1.4.3 周辺装置アイテムの文書化
LSA の主要な対象である製品／システムに加えて、装置アイテムの解析も必要です。これ
らの（特殊なタスクを含んでいる）装置アイテムは、BEI で特定される必要があり、それ自
身も BE や部品などから構成される製品階層を持っています。しかし、その BEI は、主た
る LSA アイテムの BEI ロジックに従う必要があります。
装置アイテム（補助製品: Enabling Products）の例では、以下が LSA アイテムです。
-
複雑なサポート機器（例: 試験装置、作業用プラットフォーム）
-
複雑なトレーニング機器（例: シュミレータ、トレーニングリグ）
3.1.4.4 アイテムファミリーの識別
類似アイテムに対する解析は、グループとして一括して行うことができます。このようなフ
ァミリーコンセプトは、作業量を減らし、類似した解析を繰り返すという事態を避けること
ができます。以下で、典型的なファミリーコンセプトの例を示します。
-
同じタイプの配線（例: 標準的な銅線、同軸、光ファイバー）がハーネス内に敷設さ
れていれば、互いにファミリーとしてグループ化する。これらのファミリーでは、ケー
ブル保守に関する標準的作業が設定できる。
-
同じ型の構造化された部品は、互いにグループ化する。これらのファミリーでは、標準
的な構造化された修理手順が設定できる。
-
製造メーカ毎のグルーピング。同じメーカから提供された類似タイプのすべての部品
は、グループ化する。メーカ自身が（例えば、適切な修理キットなどで）サポートする
保守コンセプトでこれらの部品の保守が実施できる。
3.1.4.5 要求の統合化
各 BE は、顧客と契約者の双方によって、後方支援活動の領域毎に特定できます。その際、
以下の事柄を考慮すると良いでしょう。
-
用語の一致
アイテム名（初期の設計文書などから派生する）は、変更せず、関連する後方支援領域
では、共通して利用すること。同一アイテムを異なる名称で利用することによる混乱を
回避できる。
-
後方支援の各領域間でのキーアドレスの一致
IT のキーアドレスは出来るだけ維持すること。異なる領域間でのスムーズな交流や相
互関係が保てる。その為にも、BE や部品を表す共通識別子は、すべての後方支援領域
だけでなく、設計部門や構成管理を含め最大限かつ広範囲にカバーできなければなら
ない。
-
標準番号システムを採用した分割要素の識別子
技術文書や設計などで使われる識別子には、SNS に対応した BEI を利用すると良い。
LSA の番号システムと他の技術的／後方支援領域は、識別子の利用で調和することが
望ましい。
3.1.4.6 データ及び文章交換システムの確立
共通キーとして、BEI および部品番号を利用する際、以下の要求に応える必要があります。
-
内部およびパートナー企業、顧客間で、関連する ILS 要素が、公認され交換すること
ができる
-
後方支援領域、設計および構成管理の各部門間で、より簡単にインターフェイスが取れ
ること
-
後方支援領域間で、データ比較を可能にすること。これにより、共通性とデータ品質が
保てる
-
すべの LSA 候補アイテムついて、機能的にかつまたは物理的に部位が指定できること
-
故障追跡がたやすいこと
-
LSA データベース（例: 後方支援領域、管理）に対し投入されるあるいは、そこから発
せられる報告書を施すこと。
-
データ交換を顧客、パートナーおよびサプライヤ間に施すこと
-
分割要素に対し、LSA 状態情報を施すこと
-
LSA かつまたは他の領域に関連する文書類を構築すること（技術仕様書、ハンドブッ
ク、概要書、図面および文書番号システム等）
-
CIL のような他の LSA 文章の構築を可能にすること
※訳者注 CIL: Candidate Item List は、LSA GC が作成する文書の一つで、契約者が
LSA の候補アイテムとして有力だと認める分割要素（BE）のリスト
3.1.5 分割要素識別子（BEI）の例
BEI のロジックでは、情報をいくつかのカテゴリで捉え、これを併合してコード化してい
ます。BEI の主要目的は、製品をトップから求める深さまで、レベル分割し階層化すること
です。これにより、関連する装置やコンポーネントを個別に表現することができます。BEI
書式に関するルールが欠かせません。これらのルールは、 LSA の GC （ Guidance
Conference : 指針協議）での合意が必要です。
※訳者注
LSA GC（指針協議）は、S3000L のプロジェクトの開始時点で作成される指
針書
を作成するプロセスを指す。
（S3000L 仕様書 Chap1.3 2.2 より抜粋）
3.1.5.1 同族 BEI ロジックの無い分割
製品分割は、構造化した BEI 書式を使わずに作成できます。各 BE は、その子供を特定す
るだけです。対象の子供 BE に関する情報は、子供要素の数と、可能ならその子供の実装箇
所を説明する文書です。
ノート
数量および実装箇所は、データの中にあって親と子の BE 間の関係に紐づいて
います。
表 4
明示的に分割したベーシックな表
アイテム名
BEI
部品番号
アイテムタイプ
親アイテム
数量
製品／最終アイテム
-
-
製品
-
-
燃料タンク
TF001
-
装置
製品
3
補助タンク
TF004
-
装置
製品
2
ラバータンク
TRT001
-
コンポーネント
TF001
1
タンクカバー
TC001
-
コンポーネント
TF001
2
ブランキングプラグ
TBP001
-
コンポーネント
TF001
1
ドレインバルブ
TV001
-
コンポーネント
TF001
1
バルブ 1
-
45-90F
コンポーネント
TV001
1
バルブ 2
-
45-90H
代替コンポーネント
TV001
1
フィルタ 1
-
27-12
コンポーネント
45-90F
1
本体
-
45-BB
コンポーネント
45-90F／45-90H
1
フィルタ 2
-
27-27
コンポーネント
45-90H
1
…
…
…
…
…
…
表 4 の分割構造を図 10 で示します。
図 10
構造化された BEI 書式を持たない製品分割
3.1.5.2 分割要素識別子（BEI）の基本的な書式 – 分割レベルの決定
BEI 書式の実装には、階層レベル化の表現について検討が欠かせません。BEI を簡易に総
括的に定義する必要があります。階層毎の桁数と、文字、数字および特殊文字の利用法の双
方について、各プロジェクトに対し適切に定義しなくてはなりません。必要な深さと広さへ
の配慮、読みやすさおよび将来予想される拡張などの角度から検討します。読み易さの向上
に、以下の工夫が必要です。
-
異なるレベル間は、ハイフンを利用すると良い
-
分割書式で、常にフルレンジの桁を利用するかまたは、当該レベルで BEI の後ろを削
るか決定しておくべき
表 5
BEI 読み易さの工夫
BEI（改良）
BEI
28000000000AAA
⇒
ハイフンを使い読み易く
⇒
28-000-000-000-A-AA
⇒
28 000 000 A
する
28000000A
⇒
空白を使い読み易くする
28-000-000-000-000
28-001-000-000-000
28
最後の階層レベルにあわ
28-001
28-001-001-000-000
⇒
せて読み易くする
28-001-001
28-001-001-002-000
28-001-001-002
28-001-001-002-001
28-001-001-002-001
シンプルな BEI 書式の例を図 11 に示します。
図 11
シンプルな BEI 書式の例
読み易さに加え、BEI に他の情報を連携させることもできます。図 12 参照方。
-
BE バリアント用コード
-
プロジェクト/製品用コード、例えば製品識別子。
図 12 拡張した BEI 書式の例
ノート
BEI 書式のコードによる定義は、S3000L 上で制約を受けません。図 11 のよう
に、すべてを数字で表現することは勿論可能ですが、図 12 のように接頭辞や接
尾辞によって BEI を拡張することで、他の情報と協調できます。この方法で異
なる BE バリアントを表現することが可能です。
JX-28-01-01-001-001-A と JX28-01-01-001-001-B は、同じ実装箇所の分割要素に位置しながら異なるバリア
ントを示しています。実装箇所は階層レベルとして、製品分割の番号システム
に現れる BEI の一部として示され、バリアントは接尾語で表現されます。
3.1.6 分割要素識別子（BEI）と関連コード
BEI を活用した機能的／物理的分割要素のコード化に併せて、他の補足情報が、製品コン
ポートを特定するために重要な役割を果たします。BEI と伴に以下に説明する情報を活用
することで、分析対象の製品の構造とアセンブリについて鉄壁な構想を得ることが出来る
でしょう。
3.1.6.1 分割要素改訂の目的
分割要素改訂子（BER: Breakdown Element Revision）は、開発の異なるステージを記録
します。特に、設計&開発フェーズにおいて、設計変更や重要な変更を余儀なくさせる幾つ
かの開発ステップは、技術解析／後方支援解析の結果や保守サポートに重大な影響を与え
るため、改訂子として表現する必要があります。BE の改訂は、伝統的な製品階層化では軽
視されていましたが、S3000L では、製品設計と後方支援領域の統合を適切に行う為に導入
されています。
ノート
BER は、同じ箇所に実装する代替ハードウェアコンポーネント（例えば、製造
元が異なる等）同士の識別に利用するためのものではありません。
（3.1.4.2 参照
方）
3.1.6.2 適応性（Applicability）
しばしば、異なる装置（例えば、製造メーカが違う等）あるいは、装置バリアント（同じ製
造メーカだが、オリジナルと改訂版の相違）が、製品内の全く同じ場所に実装される場合を
扱います。異なる BE とその BE に実装される部品実体に対して適応性を利用する際、BEI
または部品名が、製品の異なるバリアントとして指定されるので、装置／コンポーネントの
バリアント間を明確に区分することが出来ます。コンポーネントまたは部品のバリアント
を個別に扱うことで、次の二つの異なる状況を区別することができます。
-
状況 1:
単純な代替コンポーネント（形状、フィット、機能、インターフェイスおよび後方支援
上の考察が等しい場合。たとえば、異なるメーカらかの交換可能なコンポーネント）
-
状況 2:
修正された代替コンポーネント（形状、フィット、機能およびインターフェイスは同じ
だが、後方支援に関して異なる場合。例えば、異なるメーカからの同一タイプの装置／
部品だが、保守コンセプトが異なる）
一般的に、状況 2 の場合は、製品分割上に異なるアイテムを導入して、注意深く明示する必
要があります。これらのアイテムは、異なる BEI によって実現する BE として別々に表現
されるか、または、その代替として、単一で同じ BE だが異なる部品として実体化されま
す。いずれのケースでも、LSA 候補に対する異なる後方支援上の情報として明示すること
が可能で、前者は BEI で表現され、後者は、BE の実体として示されます。
（同一実装箇所
に対する異なる部品の実体化では、一般的に部品番号が使われます。
）
コンポーネントまたは部品のバリアント間を明確に区分したいという要求はそのまま、そ
の最上位階層である製品そのものに対しても、同様です（例えば異なる顧客用製品）
。厳密
に適応性を投入するのであれば、各コンポーネントおよび部品のバリアントは、製品バリア
ントに従って割り付けることが必要でしょう。
以下の例は、S3000L 製品階層化における、適応性の割り付け方式を示しています。まず、
分割は、PDM ベースの明示的な親子関係によって示し、適応性は、製品階層内にある製品
バリアントの適応性オブジェクトを使って表現されています。図 13 参照方。
続いて、同じ方式を伝統的な製品階層化手法でも示しています。
ノート
MIL-STD-1388-2B による伝統的な手法と比較すると、データ要素 ALC および
UOC への対応は、現在は、適用性とハードウェアまたはソフトウェアの実体化
で示されていることがわかります。
※訳者注: ALC （Alternative Logistic Support Analysis Control Number
Code）, UOC （Usable on Code）は、MIL-STD-1388-2B で定義される用語
で、前者は BEI に対する代替コードに類似した役割で、後者は、そのコードに
対する適応性を示している。
図 13 BEI と適応度の利用
例では、燃料トラック二種類の製品バリアントを示しています。
大きな違いは、異なるエンジンの搭載です。製品バリアント識別子 A00 で示されたトラッ
クバリアントには、BEI が A200 で指定されたガスエンジンが搭載しています。一方、A01
で識別された製品として表現されているトラックバリアントには、ディーゼルエンジンが
搭載されています。分割要素である「本体」と「トランスミッション」は、両方のトラック
バリアントに適応されています。図 13 で示す適応性の活用で、各製品バリアントの完全な
実体構造が簡易に示せます。表 6 も併せて参照方。
コンポーネントや部品の異なるバリアントを表現する場合は、ハードウェア（またはソフト
ウェア）要素の実体化によって適応性が認識できます。ガソリンエンジンに実装可能な 3 種
類の異なる燃料ポンプは、このポンプのバリアントであり、BEI の A20300 で示された燃
料ポンプ BE の実体を表しています。
ノート
現実のハードウェアまたはソフトウェア部品の各 BE は、対応する製品バリアントに連
携できます。これは、実装されているすべてのコンポーネントと、各製品バリアントの
対応付けが明確になっているからです。製品バリアントとの連携は、分割木のレベル毎
に指定できます。物理的及び機能的 BE もまた、部品とそのコンポーネントの末端に至
る部品と同様に、必要であれば、連携できます。製品階層木の例（図 13）では、ガソリ
ンエンジンのノードのみ製品バリアントに対応付けされていて、そのガソリンエンジン
に関する BE 以下の全てのアイテムに、そのバリアントが有効になります。
（派生手法）
表 6
図 12 に示した BEI と適応性の活用例
BEI
部品番号
名前
適応性
A00
-
-
トラックモデル A
製品バリアント
A01
-
-
トラックモデル B
製品バリアント
A200
GE01
ガスエンジン
A00 を適応
A201
DE01
ディーゼルエンジン
A01 を適応
A100
-
本体
A00,A01 双方適応
A300
-
トランスミッション
A00,A01 双方適応
A20300
-
燃料ポンプ
A00 を適応
FP-G1,FP-G2,FP-G3
燃料ポンプ
A00 を適応
-
燃料ポンプ
A01 を適応
FP-D1
燃料ポンプ
A01 を適応
製品
バリアント ID
A20301
次に伝統的な製品階層化で、同様に適応性の割り付けを示します。伝統的な BEI 書式であ
るシステム、サブシステムおよび装置の連携で表現しています。適応性は、製品分割内の製
品バリアントオブジェクトによって、連携が具現化します。図 14 参照方。
図 14
伝統的な分割による BEI と適応性の活用
バリアント（製品／最終品目とそのコンポーネント／部品）の指定と、適応性の活用は、
LSA GC において、契約者と顧客間で明確にしておく必要があります。
3.1.6.3 分割要素のタイプ
S3000L の製品階層化の理念では、分割要素 BE に異なるタイプが紹介されています。BE
の特殊化と呼ばれています。
-
ハードウェアまたはソフトウェア部品による BE
-
ゾーンによる BE
-
複数の BE を統合した BE （例: システム、サブシステムやアイテムファミリーなど）
3.1.6.4 装置のタイプ
BE に割り付けることのできる他の重要な情報に、対応アイテムの交換可能性と修理可能性
があります。これには、取得容易性と共に廃棄性も含まれます。表 7 と表 8 で、幾つかの
一般用語のプロジェクトでの使われ方を紹介しています。とは言え、典型的な後方支援用語
は、例えば LSA GC の合意の下で、用語集としての共通理解が欠かせません。
表 7
交換可能性の局面
用語
内容
直接交換性
製品のまま、直接交換可能なアイテム（既に 3.1.1.6 で説明した LRU
は、直接交換性を持つ代表的なもの）
非直接交換性
直接交換が困難なアイテム（親モジュールに組み込まれている）。交
換には、先に親モジュールの取り外しを必要とするもので、例えばエ
ンジンコンプレッサーは、エンジンを取り外した後に交換が可能。
（既
に 3.1.1.6 で説明した SRU は、非直接交換性を持つ代表的なもの）
交換不能性
最初から他と接続して、分離して交換が不可能なアイテム
交換可能性に加え、装置やコンポーネントが修理可能か否かを知ることが必要です。以下の
表で、この局面を示します。
表 8
修理可能性の局面
用語
内容
完全修理性
完全に修理可能なアイテム
部分修理性
部分的に修理可能なアイテム（不具合に依存）
修理不能性
修理が不可能なアイテム
（廃棄部品）
通常、修理可能性情報は、コンポーネント／部品に紐づいており、実体化に伴い明確になる
でしょう。幾つかのケースでは、
（訳者注: コンポーネントそのものの修理可能性とは別に）
BE の実装状況が原因で、組込んだコンポーネントの修理が出来ないということもあります。
アイテムが交換される、かつまたは修理されるべきかどうかの決定がまずあり、その上で、
その装置の交換可能性及び修理可能性が決まります。
※訳者注: LSA 領域にある信頼性解析などで、製品の稼働率や保守コストなど指標が定め
られ、LRU/SRU が決定され、その後、CM 側で交換／修理性を確認する流れの説明。
3.1.7 ソフトウェアに関する分割要素識別子（BEI）
一般的に、製品階層化で、ハードウェアと同様にソフトウェアアイテムを割り付けることは
可能です。しかし、製品分割の一部としてソフトウェアを扱う際は、特別な配慮が必要です。
物理的か機能的な製品階層化におけるソフトウェア要素の扱いについては、3.2.5、3.2.6 お
よび 3.2.7 で例示しています。
3.2
分割要素識別子 BEI - 構造の例
以下の例では、製品階層化を効率よく進める方法を示しています。この目的のため、3.1.2
のサンプルで割愛していた分割レベルと各分割要素の BEI を完成させます。さらに、ソフ
トウェアアイテムの統合についても例示します。
3.2.1 機能分割
最初の例（図 15 と表 9）は、単純な BEI 書式によるものです。トップレベルアイテム（ル
―ト）は、ある製品が実装する燃料システムを示しています。
図 15
機能分割、セパレータによる単純書式
表 9 機能分割、セパレータによる単純書式の一覧
BEI
アイテム名
アイテムタイプ
28
燃料システム
主システム
28-01
燃料貯蔵
機能
28-04
燃料配給
機能
28-04-01
タンク相互連携
サブ機能
28-04-02
エンジン燃料供給
サブ機能
28-04-03
燃料補給
サブ機能
28-04-03-01
圧力燃料補給
サブサブ機能
28-04-03-02
引力燃料補給
サブサブ機能
28-05
燃料注入
機能
28-06
制御・表示
機能
二番名のサンプル（図 16 及び表 10）は、拡張した BEI 書式による構造化の例です。トッ
プレベル（ル―ト）は、製品（車両 V1）に含まれる燃料システムです。最初の BE は、燃
料システムそのものです。BEI には、製品（V1）と分割タイプ（F=機能）を情報として含
みます。この場合、燃料システムは、第一レベルに位置します。
ノート
製品そのものは、第ゼロ階層にある象徴的なルートとして考えられています。
従って、最初の分割レベルが、製品分割の第一層となります。
図 16
表 10
機能分割、セパレータ付きの拡張書式
機能分割、セパレータ付きの拡張書式による一覧
BEI
アイテム名
アイテムタイプ
V1
車両 V1
製品
V1-F-28
燃料システム
主システム
V1-F-28-01
燃料貯蔵
機能
V1-F-28-04
燃料配給
機能
V1-F-28-04-01
タンク相互連携
サブ機能
V1-F-28-04-02
エンジン燃料供給
サブ機能
V1-F-28-04-03
燃料補給
サブ機能
V1-F-28-04-03-01
圧力燃料補給
サブサブ機能
V1-F-28-04-03-02
引力燃料補給
サブサブ機能
V1-F-28-05
燃料注入
機能
V1-F-28-06
制御・表示
機能
3.2.2 機能と物理分割の混合
次の例（図 17 および表 11）では、機能と物理分割の典型的な混合です。この分割では、
まずルートレベルは、機能／システム情報に使われます。分割がある程度の深さに至ると、
実際の部品を表す物理装置に代わります。機能情報は、分割が進むにつれ決まります。この
方法では、第一レベルで機能システムの BEI が定義され、次に第二レベルで、機能サブシ
ステムが決まる、以下同様に、機能を細分化していきます。ただし、複雑な製品では、どの
レベルで機能分割が終わり、そこから物理分割に移るかは決定できません。解析を目的に適
切な製品構造を求めるのであれば、既存の番号システム（例、S1000D SNS）を使用すると
良いでしょう。
※訳者注: S1000D は、現時点（2016/10）では、Issue4.1 が最新であり、Chapter 8 で、
SNS 仕様を定義していますが、第一レベルにシステム、第二レベルにサブシステムとして、
各対象の製品に対し、機能要素を指定しています。第三レベル以降は、導入者が自由に決定
することになっており、ここから物理階層を指定することも可能です。
図 17
表 11
混合分割、セパレータ付き拡張書式
混合分割、セパレータ付き拡張書式の一覧
BEI
アイテム名
アイテムタイプ
A1
飛行機 A1
製品
A1-28
燃料システム
主システム
A1-28-01
燃料配給
機能／サブシステム
A1-28-04
燃料貯蔵
機能／サブシステム
A1-28-04-01
内部貯蔵タンク
サブ機能／アッセンブリ
A1-28-04-01-03
タンク 03 後部
装置
A1-28-04-01-03-01
ラバータンク
コンポーネント／部品
A1-28-04-01-03-02
タンクカバー
コンポーネント／部品
A1-28-04-01-03-03
ドレインバルブ
コンポーネント／部品
A1-28-04-01-03-04
ブランキングプラグ
コンポーネント／部品
A1-28-04-02
補助貯蔵タンク
サブ機能／アッセンブリ
A1-28-05
燃料注入
機能／サブシステム
A1-28-06
制御・表示
機能／サブシステム
--------
--------
図 17 に示すように、機能 BE と物理 BE の境目が、必ずしも明確でない場合があります。
例えば、BE の A1-28-04-01 は、機能 BE であれば、内部用保存タンクですが、一方で、3
つの内部タンクを物理的なコンポーネントに持つアセンブリとも言えます。
3.2.3 相互参照（ハードウェアのみ）による物理および機能分割の併存
図 18 の例では、機能分割と物理分割の双方が全く異なる階層木になる場合を示していま
す。これら二つの領域間の効果的な接点を見出すには、LSA データベース内に、適切な相
互参照テーブルを用意して対処します。
図 18
機能と物理分割の併存利用
異なる階層木間の相互参照は、m:n 関係の構造を持ちます。すなわち、ある機能が、多くの
物理分割上の BE に接続している一方で、その物理上の BE の一つが複数の機能分割上の
BE に接続するということが起こります。図 19 参照方。
図 19
機能および物理分割間の相互参照の様子
3.2.4 明示的な親子関係による物理分割
他の分割方式に、親子関係に着目した手法があります。このケース（図 20 及び表 12）で
は、ハードウェアを階層的に分解し、親とそこに含まれる装置またはコンポーネントの関係
で示します。このタイプの分割は、PDM システムで良く使われています。BEI の書式に補
完的な情報を付加することは可能ですが、機能的な構成要素（SNS の様に、燃料システム
を”28”で表現する等）を、このタイプの分割手法で、機械的に用いることはありません。
図 20
親子関係手法による分割
このタイプの分割では、BE のキー情報は、例えば部品番号によって与えられ、BE の識別
子として使われます。機能的な構成要素を含むことはありません。各 BE 間の関係を暗黙的
に示すように部品番号が振られることはありません。単に、自分より一つ上の BE と自分自
身の数量に関する情報で構成されています。
表 12
親子関係州法による分割の一覧
アイテム番号
アイテム名
アイテムタイプ
親アイテム
数量
V1
車両 V1
製品
-
-
FT002-791
燃料タンク
アッセンブリ
V1
3
FT102-591-A
補助タンク
アッセンブリ
V1
2
ATF-009-G-21
ラバータンク
コンポーネント
FT002-791
1
G0135991
タンクカバー
コンポーネント
FT002-791
1
VG7-1206
ドレインバルブ
コンポーネント
FT002-791
1
G05H32110
ブランキングプラグ
コンポーネント
FT002-791
1
H63433-A
フィルタ
コンポーネント
VG7-1206
1
1205664
O-リング
コンポーネント
H63433-A
1
1205667
O-リング
コンポーネント
H63433-A
1
この明示的な分割で、コンポーネントの実装位置が重要な場合があります。それには、各位
置を明示的に示すため、数量を 1 として各々に BE を割り振って対応します。
3.2.5 単一の物理的ハードウェアアイテムの一部としてソフトウェアを統合
ソフトウェアパッケージをハードウェアに直接割り付けます。ソフトウェアパッケージへ
の BEI の割り当ては、分割コード化のルールに従って、対応するハードウェア傘下で行い
ます。コード化ルールに、ソフトウェアとして BE を示す特別な桁を使うこともできます。
図 21 の分割例 1 では、まず航行レーダーとその航行レーダーに組込まれた航行 SW パッ
ケージの各 BEI に、BEI 情報をベースに強く結び付けています。
BEI 書式の暗黙的な関係によって、航行 SW パッケージは、ソフトウェアの走行先である
航行ラダーにユニークに割り付けられています。
図 21
物理分割にソフトウェア BEI を割り付ける
図 21 の分割例 2 では、同様の分割ですが、ソフトウェアの BEI が異なっています。BEI
として、二けたの’SW’が使われています。他の分割レベルに変化はありませんが、この SW
パッケージへ、航行ラダーの一部として、やはりユニークな割り当てが行われています。
ノート
通常、ハードウェアまたはソフトウェア部品は、BE に結びついています。従って、
製品分割のソフトウェアまたはハードウェア要素である BE として、名前付けられ
ます。この場合、あえて特殊なコードが必要になることはありません。
3.2.6 複数の物理的ハードウェアアイテムの一部としてソフトウェアを統合
SW のインストールまたはローディングが、ハードウェア分割上の複数の物理デバイスに必
要な場合、SW に対するユニークな識別子を割り当てることが出来ません。代替手段として、
ソフトウェアコンポーネントの分割レベルを一つ上げて、割り当てる方法があります。図
22 参照方。
図 22
物理分割で複数流布したソフトウェア
ロード可能な航行 SW を、二つの異なる装置に対し、単一の手順でロードするような場合
があります。その SW は、単一のオブジェクトとして配布・インストールされるので、二つ
の部品に対し、物理的に分離できません。ソフトウェア上の分割はローディングプロセスが
担っており、個別のユニークな割り当ては不可能です。
この様なケースでは、航行システムの BEI を完全にするため、SW コンポーネントを一レ
ベル上げて、割り付けることが許されます。情報の欠落を防ぐため、すなわち SW が実際に
走行するコンポーネントを明確にするため、SW パッケージの BEI からの相互参照を、
（訳
者注: この例の破線で）航行レーダーと天候レーダーの双方に対し、明示しています。
3.2.7 機能分割におけるソフトウェアの統合
機能構造において、SW アイテムは、機能システムの要素かまたは、その SW が走行する分
割要素です。BEI の割り当てでは、SW アイテムの保守特性を考慮する必要があります。特
定のサポートが必要なアイテムであれば、単独の BEI を持ちます。例えば、その SW がロ
ーダブルなのか組み込み型なのかで BEI の仕組みが違ってきます。また、その SW アイテ
ムを主契約先が提供するものか、また、安全性やセキュリティ上の重要度などによっても異
なってきます。プロジェクトの早い段階では、これらの保守性に関する要求はそれほど重要
でありません。機能 BEI の割り付けの仕組みは、開発が進むに従って、固めていくことが
できます。
機能的 BEI 構造を開発する際、SW アイテムが、適切なレベルの階層で論理的にグループ
化され、かつ全ての対象となるソフトフェアに個別の保守を必要とするとき、これらのグル
ープ化アイテムには、しばしば限られた情報しか格納されません。図 23 の例では、アイテ
ム「フーリエ解析」と「署名」のグループ要素では、ほとんど LSA データを保持していま
せん。
LSA 全領域の情報は、最低レベルの階層にあるアイテムに対して記録されます。この様な
ケースで、SW は、ソフトウェア保守活動が遂行されるアイテムとして位置づけられます。
第 13 章を参照方。
※訳者注: S3000L 13 章は、タイトル「Software support analysis」として、ソフトウェア
の保守解析について記載しています。章の書き出しに、以下の記述があります。
「昨今の製品におい、ソフトウェア領域の重要性は増している。複雑なソフトウェアパ
ッケージによって、より多くの機能がサポートされ、あるいは提供されている。これま
では、製品のライフサイクル全体を通じ、製品保守を全うするため、その概念およびプ
ロセスは、ハードウェアコンポーネントに対し確立してきた。このハードウェアに向け
たゴール達成のための適切なツールが、LSA プロセスである。同様の要求がソフトウェ
アに対し起こっている。ハードとソフトは、ともに重要で、製品に期待される機能を支
えている。この様な事情から、ソフトウェア保守解析（SSA）を、適正なソフトウェア
保守コンセプト（SSA）を開発するために活用する。SSA は、コスト最適な SSC を確
立するために必要な全ての情報を顧客に提供することを目的に、ソフトウェアを解析す
るための手法である。ここには、全ての装置、工具、要員、ドキュメントおよびインフ
ラと必要な技術力さらにトレーニングが含まれる。
」
図 23
SW に関する機能的 BEI 構造
製品の寿命を通じて SW アイテムの機能面と物理面双方の保守が必要です。機能領域のソ
フトウェアアイテムと、そのソフトウェアが走行する物理領域の両領域間のリンクが欠か
せません。これは、物理的なハードウェアアイテムから機能的な製品分割への相互参照マッ
プと同じ手法です。
純粋な機能分割に SW BEI を割り付けるという要求は物理分割でも同じです。単一の機能
が一つの SW パッケージのロードで実装されるのであれば、ユニークな割り付けは可能で
しょう。一方、複数の機能がロードされるのであれば、物理分割で説明したと同様に、より
高いレベルに割り付ける必要が出てきます。
SW に関するもう一つの疑問は、その使用されるタイミングです。機能分割として利用する
場面と物理分割として利用する場面です。多くのケースで、SW は、システムまたはサブシ
ステムレベルの傘下の物理分割内に位置します（混合手法として説明した物理および機能
の一体化した構造）
。しかし、SW の修正目的の視点からは、分離した SSA データベースに
よる機能分割が好まれます。通常、システムやサブシステム傘下で、より高い分割位置には、
機能フレームワークが使用されますが、かならずしも機能分割の視点だけでは十分とは言
えません。
※訳者注: 実装上の利便性等から、複数の機能を一回の SW ローディングで賄う場合、関
係する物理分割要素と横並びの位置にソフトウェア要素を配置するのはごく自然です。が、
SW 保守の視点では、指定した機能にのみ改善が施されていても、他の機能と一体化した要
素として構成上の位置にあるのは、好ましくありません。機能を実装している装置に一対一
に組み込まれる SW のローディングと保守は、同じ分割単位にするのが望ましいが、困難
の場合、これらの文書化には十分に留意すべきでしょう。
4
LSA における構成変更
4.1
構成変更による影響の評価
適正な CM（構成管理）では、変更が、LSA に施される際の全てのインパクトを正しく評
価する必要があります。変更は、構成アイテムへのインパクトあるいは、サポートシステム
へのインパクトが考えられます。製品利用やサポート問題に対する変更のインパクトをコ
ントロールするには、以下を配慮しましょう。
-
LSA の各領域における変更の影響
-
サポート要素（代替部品、試験装置）に対する間接的影響
-
変更アイテムの事前・事後の移植性／互換性
-
変更に適応範囲がある場合、変更ドキュメントにこの点を明記すること
LSA およびその他の ILS 領域で、変更のインパクトを調べ、実施すべき活動を特定しなけ
ればなりません。
LSA は、ILS 領域の旗振り役という意味からも、プログラム変更委員会において ILS の重
要な調整を司ると同時に、LSA 内の異なる領域間の調整も行います。承認された変更がい
かなるものであっても、ILS にしっかりと反映されることが肝要です。
4.2
構成変更の原因／要因
CM プロセスに LSA が必要なのは、製品のベースライン構成変更に対応するためです。こ
の変化は、内部要因（例、サポート解析手法の改善等）による場合もあれば、外部要因（例、
設計変更、部品供給元の変更等）もあります。
構成変更をもたらす要因／資源には、以下のようなものが挙げられます。
-
顧客からの変更要求
-
設計変更要求
-
（許容範囲内の）製造上の設計からの逸脱
-
部品供給元の変更
-
変更の顧客注文（サービス中の変更）
特定の要因が特定の資源にリンクしているので、
関連する資源の管理が CM には必要です。
特定の変更は、通常、定義されたプロセスに従い、対応する活動を要求することになります。
LSA は、変更に対応する LSA 活動を特定するプロセスに加わり、変更の結果に対し、製品
の正しい LSA 構成を維持します。主要なビジネスケースの概要を以下に示します。
4.2.1 顧客からの変更要求
時として、製品への変更要求が、顧客から発生します。以下は、必要なプロセスです。
-
顧客起点の変更（COC: Customer Originated Change）要請の受付け
-
COC 管理

コスト予測によるインパクト分析。顧客からの変更要求は、その影響と変更を実施
するためのコストを決定するための分析が必要となる。

変更委員会活動。承認または拒否を諮る変更委員会を開催することができる。この
場合、委員会に対し変更が提示される。

決定と解決の通知。変更要請に対する決定事項は、顧客に対し通知されねばならな
い
-
COC 設計検証

設計部門に対し、分析を依頼する。変更要請は、分析にために設計部門で取り扱う。

関連した設計変更要請。設計部門が、設計変更が必要と判断した際、顧客の変更要
請と設計変更とのリンクを確立し、後に追跡出来るよう記録される必要がある。

設計部門のドキュメント収集。設計部門は、顧客要請を起点に、最終的に決定した
変更要請を得るために必要なドキュメント類を準備する。
4.2.2 設計変更要求
設計部門は、さまざまな理由から製品構成の変更を提案できます。変更の持つ性格から、次
の 3 つのグループに分けて適正化できます。
-
必須の変更（安全性）: このタイプの変更は、避けることのできないもので、製品の安
全に関わっている。変更せずに放置すると、製品利用で壊滅的な事態が生じかねない。
-
改善の為の変更 : 変更することで、製品の機能や保守性が改善される。
-
版の更新 : 顧客契約要件に基づき、新しく顧客向けバージョンの作成をもたらす変更。
変更追跡を維持するため、次に挙げるように、これらの変更に結びついている確かな局面と
いったものを検討し、その結果生じる活動が必要になります。
-
変更適応性。製品に関して変更を識別するための適応性（applicability）を用意する
-
設計構成コンセプト。一般論として、設計部門では、機能アイテムに対して、実現のた
めの構成を考える。機能アイテムは、製品に求められるある特定の機能要件に対応する。
これを単一で実現するのではなく、その同じ機能を、複数の異なる設計上の解決法（DS:
Design Solutions）で構成する。従って、一つの構成アイテムに対し、複数の DS があ
る。DS は、単独の装置であったり、装置グループであったり、または異なるアイテム
からなるアッセンブリで、相まって一つの機能を提供している。
設計変更 :

構成アイテムを作成する

構成アイテムに関する新しい DS の生成、変更および削除などを通じ、構成アイテ
ムを修正する
-
図面やモックアップの修正。いくつかのケースでは、変更が、新しい CI/DS を必要と
しない場合でも、アイテムの場所の変更が必要となったり（モックアップの変更）
、さ
らには、サポートアイテムに影響する場合がある（保守タスクの内容変更）
。
※訳者注: CI は Candidate Item の略で、代替部品や後継部品を指すと思われる。DS
は、Design Solutions で、部品を含めアッセンブリや装置そのものの設計変更により問
題解決を図るもの。
-
設計仕様書およびシステム説明書の変更。設計仕様書には、製品の機能説明が含まれる。
製品の構成への変更が機能変更を意味するのであれば、設計仕様書は、設計変更の影響
を受ける関係にある。
-
設計変更状態。設計変更を委任／実装するには、承認プロセスで追跡調査されねばなら
ない。LSA の視点で、状態を知り、適宜に活動することが重要となる。LSA は、全体
のプロセスで欠くことのできないので、変更プロセス全体の状態は、LSA の状態に配
慮しなければならない。その結果、LSA は、プログラム変更管理に対するフィードバ
ックを提供する役割を担う。
4.2.3 （許容範囲内の）製造上の設計からの逸脱
承認された製品構成のドキュメントは正しいが、製造上の問題が発生するような場合、「逸
脱または放棄」伝票を製造部門が発行して対処することがあります。それには、対処アイテ
ムが受け入れ可能であるか、図面や標準規格に準じるように多少の修正を加えることが必
要です。ただし、ライフサイクル上のプロセスを回避する目的で、逸脱または放棄すること
は望ましくありません。不適合を表す文章および評価が必要であれば、契約締結前に、これ
らを実施した上で合意する必要があります。
-
逸脱の要求
アイテムの製造工程に入る前に、仕様や図面からある一定の数のユニットまたは限ら
れた期間、一時的に要求仕様から逸脱した製造が必要な場合、顧客は製造担当の契約者
側からの要請に対し、許可を与えることができる。逸脱要求の許可なしに、既知の一般
的な問題にすり替えて、文書化を怠ってはいけない。
-
放棄の要求
部品供給やサービス提供において、契約要件への配慮を怠ってはならない。ただし、あ
るアイテムの製造が、仕様通りに行えない場合、その仕様の放棄または異なる製造への
許諾無くしては、顧客への提供が困難な場合がある。
4.2.4 部品供給元の変更
部品供給メーカから提供される装置に対する如何なる変更も、製品の構成に影響します。部
品供給元による変更は、その供給元からの装置に適応する為の装置やサポートアイテムに
影響します。
4.2.5 サービス中の変更（サービスブリテン）
ひとたび製品が稼働し、修正が盛り込まれれば、通常それは、サービスブリテン（SB）と
して紹介されます。
SB は、技術ドキュメントとして修正内容を記述し、いかに対処するか記載しています。そ
れは、関連する適用性で特定され、一旦その SB が承認されれば、設計変更として対処され
ます。
設計変更と SB の違いは、契約者からみて、その顧客により実施される SB 対策の情報は、
必ずしも知らされないという点です。それ故、そのような SB に関する適用性は、真の意味
の適用性とは異なる場合があります。
※訳者注: LSA の当事者では、
「顧客」は、製品の発注者であり、利用者です。この「顧客」
は、製品発注の仕様や性能に深く関わっています。
「契約者」は、この仕様・性能を実現し
提供する製品メーカです。一般市販製品に置き換えると、「顧客」は一般利用者であり、仕
様・性能はすでに確定している製品を購入し利用します。「契約者」は市販製品のメーカに
あたります。このように LSA では、
「特注製品」の発注・利用の視点で当事者を記載してい
ます。従って、この SB に関する記載を通常の市販品で比較すると、
「製造メーカが知りえ
ない現場の製品利用における修正活動がある。例えば、ディーラサイドで培い整備する SB
がありうる。
」という意味になります。「真の適応性」は、
「顧客」と「契約者」で共有され
ているまたは、
「契約者」が管理している「適応性」です。
4.3
変更原因を起点に関係する LSA 変更に至る追跡
変更の起点と LSA 変更との間の追跡は、以下によって行います:
-
変更要請の規準追跡
変更要請に際し、設計部門やその他の部門で活用している同じ規約を変更規準に使う
ことで、変更追跡が保証される。そうでない場合、LSA/ILS への変更認可に使われる
基準と、元の変更との間の関係を維持するための記録が必要となる。
-
設計構成アイテム vs. LSA 構成アイテム
設計部門が、LSA 構成とは異なる設計構成規約を利用している場合、双方の構成内に
あるアイテム間の連携を確立する必要があるが、それには、設計構成と、LSA 構成間
での追跡を保証するルールの生成が欠かせない。2.1 参照方。
4.4
LSA プロセス実施中の構成変更手順
4.4.1 一般的な局面
ある変更依頼が LSA に影響があり、基準として採用されると、この活動を保証するために
必要な後続の活動を開始する必要があります:
-
LSA への影響を適切に明示する
-
必要な変更を実施するための異なる仕事を明確化、スケジュールする。また、必要な資
源を明示する。
-
LSA に課せられた変更の実施が正しく行われているかをプログラムレベルで全構成管
理プロセスに対し、知らしめかつ、そのフィードバックを確保できる
※ここで言う”プログラム”については、「訳者はしがき」参照方。
-
LSA に対し何等影響しない変更依頼は、その判断の正当性を記録する必要がある。こ
うすることで、全ての変更依頼が、解析されていることを示し、変更追跡が正しく実施
されていることを保証する
4.4.2 変更に伴う編集
変更に伴う編集とは、認可された変更コードに従って、関係する全てのデータを編集するこ
とを指します。これは、変更が編集の要因であるとも言えます。変更に伴う編集を実施する
基本的な理由は以下の通りです:
-
設計、製造および部品供給元による実施される変更および顧客から変更要請を確実に
トレースするため。これにより、承認された変更の真のインパクトが明らかになる。
-
サポートシステムの如何なる部分に対し、その当事者に必要な変更を実施させるため。
これにより、適正な変更が実施できる
-
アイテムの適応性を明示するため（その部品が、適応性に依存しているか吟味が必要）
これらの実行するための基本的に方法は、操作上かつまたはサポートシステム上のアイテ
ムに対する如何なる変更についても、そのインパクトを明確にすることです。変更に影響さ
れるアイテムの明示および影響のタイプは、品質確保の目的から記録されます。起り得る影
響のタイプを、以下で一覧に示します。
表 13 影響のタイプ
影響のタイプ
内容
新規アイテム
変更は、新しいアイテムを必要とするかまたは、既存のアイテムに
対し、適応性の範囲を拡張する
削除アイテム
ほとんど場合、実際にアイテムを削除する意味ではなく、既存のア
イテムに対し、製品への適応性の範囲を狭めることで、変更に伴う
適応性の変化に対応する。この情報は、構成アイテムの適応性を取
得するために大変重要となる。
修正アイテム
変更に対し、追跡機能のみ要求され、何等適応性に影響しない場合
に使われる。例えば、基準に従い変更を施したが、そのタスクの前
後で、そのアイテムが属する製造ロット（ range of MSN:
Manufactured Serial Number）対する変化がない。影響および異
なる適応性が必要となったのは、その作業のコンポーネントであ
り、そのアイテムそのものでない場合。
（例、代替部品、作業手順説
明など）
LSA の運用システムに関する構成は、ILS/LSA にインパクトを与える設計変更の承認を通
じて、設計側の運用システム構成とリンクされています。この変更は、記録され、階層化に
よる分割要素の改訂識別子と関係付けが必要です。すなわち、新しい分割要素が作成された
か、あるいは削除されたか（例、分割要素の適応性に制限が入る）あるいは、適正性の範囲
が広がったかが明らかにされねばなりません。
分割要素の改訂、ハードウェア要素の実体化と製品バリアントを明確にする為の適応性、及
び元の設計構成上の識別子、これらの関係性を維持することで、LSA 構成の追跡を保証す
る方法を提供します。また同時に、BEI に対し新規の設計変更による影響の可能性を識別
子として表現する助けになります。
4.4.3 拡張された適応性の管理
4.4.3.1 概要
ある製品の構成は単一ではなく、異なるコンポーネントを持つことで相違する構成を表現
出来ます。それ故に、製品毎の実構成を知ること、あるいは逆に、構成の各アイテムの視点
で、そのアイテムを実際に実装している製品を知る必要が出てきます。このための手段とし
て、適応性の管理が用意されています。
4.4.3.2 製造シリアル番号と、フリートシリアル番号の考え方
顧客の視点に立てば、システムの対象は、操作と保守サービスです。最終的には、その操作
に関する情報は、運用している実製品に関して掻き集められます。製造シリアル番号（MSN）
は、この実製品を識別します。これは製品を特定するのに利用されます。各製品は、単独の
MSN を持っていなければなりません。それ故、MSN の範囲は、その中に実装されている
アイテムに対する適応性を識別する為の主要な情報として使われます。図 24 参照方。
図 24 MSN の使用例
フリートシリアル番号（FSN）は、他の可能性を提供します。フリートの概念は、二つの
コンセプト、顧客とバージョン、の組合せを基礎にしています。バージョンは、基本的には、
同じ構成を持つ製品の集合を示します。この集合は、同じタイプの任務あるは、同じ操作上
の特徴を共有します。あるバージョンに含まれる製品間でも、改善や改良といったことが原
因で、多少の違いが発生することがあります。顧客を更に製品に結合することで、フリート
を定義します。製品は、顧客+バージョン+バージョン内のランクで特定できます。図 25 参
照方。
図 25
フリートの例
MSN と FSN の対応付けの例を示します。
図 26 FNS （フリート）対 MSN
S2000M は、フリート番号付けによって適応性を定義し、
（顧客向け）サービスバージョン
（例、単座機、二人乗り機）とバージョン内のシリアル番号で識別します。
※訳者注: S2000M は、ASD-ILS 仕様の一つで、部材管理（Material Management）を
担当しています。イニシャルプロビジョニングと呼ばれる初期配備等で、正確に部品を特定
するため、フリート番号付けを利用しています。
製造計画で、MSN と FSN の番号は通常、重ならないようにしています。MSN の一番機
は、ある顧客向けですが、二番機は他の顧客に振られます。
4.4.3.3 変更／基準の有効性
変更要請は、すべての製品に適応されることもあれば、ある限られた範囲の製品に限定され
ます。この範囲には二種類の表現があります。
-
MSN 以上
変更を適応する最初の MSN。このアイテムは含まれる。
-
MSN 迄
変更を適応する最後の MSN。このアイテムも同様に含まれる。
変更／基準の適応性を表す他の可能な方法は、バージョンとそのバージョン内の範囲を提
供することです。変更／基準は、単一のバージョン／範囲を超えて適応することが可能です。
4.4.3.3.1 例: 設計基準の適応性を LSA 適応性へ
追跡管理のプロセスにおいて、基準が構成済みアイテムに対し如何に影響するかを見てき
ました。次の例で、これをアイテムに対する適応性の範囲という視点で明らかにしましょう。
-
最初のステップ: 基準 1 と呼ぶ最初の基準で、MSN を 0001～9999 の範囲で適応性
を持っていると定義する。
-
それを、新規の分割要素 A212101 のバージョンで、新ハードウェア要素の実体 P/N1
の生成に用いる。基準 1 は、シリアル番号の範囲内に適応可能とする。
-
A212101 の見かけ上の分割要素バージョンは、0001～9999 範囲の適応性を所持する
-
次に、既存の分割要素バージョンに対し、新しいハードウェア実体 P/N2 がバリアント
として生成し、適応性を 0020～9999 とする新しい基準が生成される。これらは新しい
ブロックのアイテムシリーズで同じ製品バリアントとして認識される。
-
結果として:

A212101 の分割要素バージョンでハードウェア要素実体 P/N1 は、0001～0019 の
範囲だけの適応性

A212101 の分割要素バージョンでハードウェア要素実体 P/N2 は、0020～9999 の
範囲だけの適応性
※訳者注: SLM の分割要素である A212101 は、見かけ上の適応性は、その実態であるハー
ドウェアの実装（設計上の適応性）とは独立に、0001～9999。P/N1 と P/N2 はシリーズア
イテムということなので、P/N2 は P/N1 の後継部品で、仕様・機能・フィットに違いがな
い状況を説明しています。
4.4.3.3.2 例: 設計基準の適応性を IP/IPD 構成アイテム（CSN/ISN）適応
性へ
IP/IPD （イラスト付き部品／イラスト付き部品データ）のアイテムを、CSN（カタログシ
ーケンス番号）と ISN（アイテムシーケンス番号）をベースに、適応性を求める例を示しま
す。図 27 参照方。
図 27
適応性の算定
※訳者注: パーツカタログの部品リストに掲載される部品について、その適応性の範囲を求
めています。MOD-1 と呼ぶ承認された変更で、ISN が 00A の部品が適応外となり、新た
に 05A の部品が適応になった様子を示しています。ここでは部品のシーケンス番号を利用
していますが、一般の市販製品では部品番号で表現することが多いと思います。CSN は、
パーツカタログのバージョンと対応していますので、第五バージョンのパーツカタログ上
の部品シーケンス 00A が 05A に置き換わり、その MSN が 0010～9999 の範囲になったこ
とを説明しています。
4.4.3.4 MSN vs. FSN 適応性管理
MSN または FSN は、製品または要素の変更が部品番号の変更を伴わないときに使われま
す。この様なケースでは、MSN または FSN は、異なる構成上の末端アイテム間の区別に
使います。例えば、ある飛行機上で、部品番号は変わらないが、異なる飛行機メーカを識別
する場合に、MSN や FSN が必要になります。このような装置のケースでも、装置の構成
が変更される場合は、装置の部品番号は変わります。そのため、UOC（Usable on Code: 製
品構成上で、製品やシステムあるいは装置に関する識別子で、分析作業で利用される。
）が、
異なる部品番号で識別される全ての装置のコンポーネントの適応性を示すために使われま
す。
MSN 適応性は、部品製造に紐づいています。そのライフサイクルを通じて変化しません。
通常、設計部門での適応性も、この方法で与えられますので、設計変更等を起因する基準は、
通常このタイプの適応性になります。
FSN 適応性では、S2000M 仕様のルールと定義を活用することを求めています。配布され
るべき部品情報のカスタマイズが容易になるという理由で、このタイプの適応性の利用が
推奨されています。
※訳者注: S2000M では、部品調達に際し、部品仕様を提示し、複数の部品メーカから提
供を受けるプロセスを定義しています。ここでは、発注側が部品番号を定義するため、上記
のように、同じ部品番号が異なる部品メーカで共有されるという事態が発生します。一般の
市販製品と異なり、S2000M の発注側は、NATO などの防衛組織体であり、製品への要求
が設計の細かな部分に至っています。
用語解説
ALC
Alternate LCN Code の略。MIL-STD-1388-2B 仕様の用語。
LCN の代替コードとして、後継部品、代替部品に使われる。
MIL-STD-1388-2B の Appendix C 参照方。
AIA
Aerospace Industries Associationの略で、米国航空宇宙工業会の
こと。アメリカの航空宇宙関連業者による業界団体で、主に
軍需・民需メーカ組織。
http://www.aia-aerospace.org/
ASD
AeroSpace and DefenCeの略称で、欧州の航空宇宙防衛産業の協
会名。SシリーズILSの推進元。S1000D/S2000M/S3000Lは、Sシ
リーズの構成仕様。
http://www.asd-europe.org/home/
http://www.sx000i.org/
ATA (A4A)
Air Transport Associationの略で、米国航空輸送協会のこと。ア
メリカの民間航空機サービス業者、航空機メーカによる輸送
サービス向け団体。
http://airlines.org/
BE/BEI
製品を機能的または物理的に分割し、階層構造化した際の各分割
要素(BE: Breakdown Element)と、他と区別するための識別子
BEI (BE: Breakdown Element Identifier)
CI
Candidate Item の略。代替部品や後継部品を指す。
DEF-STAN 0060
英国国防省の軍用規約。ILS に関する規定。
DITA
Darwin Information Typing Architectureの略。技術文書のコンテン
ツ製作に適したXMLデータ構造の名称。Darwinとは、進化論のダ
ーウィンのことで、このデータ構造が「派生」アイデアを持って
いて、現実のビジネス要求に適応しながら進化することを暗に示
している。米国IBM社で誕生し、現在は、OASISグループのテクニ
カルコミッティの一つとして、オープン規格として自由に利用で
きる。技術文書をトピックという小さな単位に部品化し、それを
組み立てて本やWebページなどを動的に作成させるマップ機能が
特徴。部品化されたトピックは、ビジネスシーンで必要な情報の
並びや内容にあわせて「派生」させることが出来るので、業務に
適した構造が利用できることと、コンテンツの書式がWebブラウ
ザ作成用の書式に類似していることから、初心者にも扱い易い。
http://dita.xml.org/
DS
Design Solution の略。機能を実現するための製造設計技術とし
て、機能を機能構成要素に分解し、現実の部材とマッピングし問題
解決を図る。特に設計変更時に、改変部分を特定する場合などに使
われる用語。
eMod
Electronic Maintenance and Operational Data の略。Boeing 社
のコンテンツ管理・デリバリィシステム。B767 に採用され、日本
国内の航空サービス会社では、部分更新などの対応で利用されて
いた。
ILS
Integrated Logistics Support の略。
システムのライフサイクルに関し、最大の効率と経済性を実現さ
せる全ての要素を統合的に支援する。即ち、保全計画、供給支
援、試験、包装／保管／輸送、作業員および訓練、必要な設備、
これらの運用データ、およびコンピュータ・システムなどの要素
を包含する。ILSシステムと言う場合は、これらの運用を管理す
るシステムを指す。
LCN
Logistic Support Analysis Control Number の略。 MIL-STD1388-2B 用語。
製品を機能的または物理的に分解し、トップダウンから木構造の
階層化 (LCN structure)した際、個々のノードを識別するための
コード。
MIL-STD-1388-2B の Appendix C 参照方。
LSA
Logistics Support Analysis の略。後方支援分析。より効率的なシス
テムにするために定量的に分析する手法。
(以下、MIL-STD-1388-1A より抜粋)
製品やシステムの保守性と他の ILS 活動の目的に応じて、これを
支援する過程で、定義や統合、トレードオフ、テストおよび評価な
どの逐次的なプロセスを利用して、システムエンジニアリングお
よび設計部門の一部として、システム／製品の導入プロセスにあ
って活用される、科学的・工学的手法により特定されたアプリケー
ション。
MIL-STD-1388-2B
米国国防省の軍用規格。表題は、
“DoD Requirements For A Logistic Support Analysis Record”。
兄弟仕様に、MIL-STD-1388-1A があり、こちらの表題は、
“Logistics Support Analysis”で、国防省が購入するシステムや装
備品に関し、そのライフサイクルを通じ、後方支援解析(LSA)の実
施を管理するための一般的な要求と必要なタスクの説明がある。
2B は、実際のレポートの具体的な仕様を提示している。
MSN
Manufacturing Serial Number の略。
製造シーケンス番号。製造メーカが、同一製品モデルに対し、通常
出荷順に割り振ったユニークな番号。この番号により、実機を特定
できる。
OASIS
Organization for the Advancement of Structured Information
Standardsの略語。OASISは、ビジネスにおける情報交換用技術
標準を作成する国際的な団体であり、XMLやSGMLなどの標
準技術をベースに活動している。組織でも個人でも参加する
ことができる。情報交換においては、国際的に統一された標
準の存在が非常に重要であり、不特定多数の個人や組織間で
の情報交換が実現する。そういった、既存のXML
やSGMLなどの標準技術の上で、実際のビジネスアプリケーシ
ョンに適合し、相互運用を実現するための標準を定める団体
として、OASISはある。前身は、SGML/Open。インターネッ
ト上の標準化団体としてはW3Cも存在するが、W3CはXMLや
HTMLのような、Webに関する基礎技術を扱い、OASISはその
上位のアプリケーション寄りの標準化を扱う。
https://www.oasis-open.org/
PDM/PDS
Product Development Management/Systemの略。製品開発システ
ム製品開発を最適化するためのツールで、一般に設計(CAD)／
製造(CAM)及びBOMの構成管理や変更管理を統合化したものを
指す。主に製造メーカによる製品ライフサイクルを担う。
S1000D
正式名称は、International specification for technical publications
utilizing a common source databaseです。共通ソースデータベー
スを介した技術パブリケーションの為の国際規格として、
ASD, AIA, ATAの３団体からなるTPSMGが、航空宇宙、地上、
海上の輸送機に対する包括的な仕様として規定している。
http://www.s1000d.org
S2000M
International specification for material management Integrated data
processing for military equipment の仕様コード名。防衛用製品に関
する資材管理を、統一的なデータ手続きを用い、これを電子的にデ
ータ交換することによって実現する機能仕様。ASD-STAN が標準
化を進める ILS の資材管理を担当。
http://s2000m.org/
S3000L
International procedure specification for Logistics Support
Analysis LSA の仕様コード名。後方支援解析の実装に必要なアプ
リケーション手引書。MIL-STD-1388 をベースにした、新規軍需
製品の支援手法を取り込んで、XML 技術で電子交換用に焼き直し
たもの。ASD-STAN が標準化を進める ILS の LSA を担当。
http://s3000l.org/
SIS/SMCS
SISは、Service Information Systemの略。米国キャタピラー社が
2000年代に提供していたサービス情報システム。製品情報を
様々な角度で検索して利用することが可能。検索には、プロ
ダクト構造、ドキュメント構造の2種類の構造からの閲覧に加
え、SMCSと呼ばれる同社の2,000種を超える全製品および製
品構成をユニークに特定するコードからも検索できた。CDROM媒体による電子マニュアルとして配布され、専用のソフト
ウェアにより、定期的に更新される情報を使った最新情報提
供システムとして定評があった。
現在は、Webサービスにリニュアルされている。
SMCSは、Service Management Code Systemの略。
SNS
Standard Numbering Systemの略。S1000DやS2000Mなどの
仕様で使われている標準採番システム。サービス情報を汎用
な構造で規定し、上流工程や部品メーカの設計・製造の構造
に依存しない。
SPL
Structured Product Labeling の略。米国FDAが、製薬の製品や施
設情報の電子交換のメカニズムとして規定したXMLベースの
標準規約。
UOC
Usable On Code の略。MIL-STD-1388-2B 用語。
製品に要求される様々な仕様をオプションやバリアントで表現す
る際、実際の運用やパブリケーションで対象になっている組合せ
を指定するための適応性を表現するもの。
MIL-STD-1388-2B 仕様の Appendix C 参照方。
訳者あとがき
本書のように、標準仕様を説明する文章の問題として、総花的に様々な読み手に情報を提供
するため、読み物として理解しにくい面があります。あるストーリーに沿って記載していな
いため、内容の重なりや隣接コンテンツの乖離などが、しばしば理解を妨げます。
はしがきで提示しました以下の手順は、私なりに読み解いた結果で、大よそこのように進め
れば、求める構成管理に適した製品分割が得られるのではないか? と捉えています。
1.
情報の粒度の決め方に、効果的な製品情報の分割方法がある
2.
分割方法は、利用者の視点により、機能分割、物理分割など複数発生する
3.
複数の分割で得た階層構造の相互参照を仕組む必要がある
4.
最終的には、一本化した製品階層構造を目指し、適切なコードシステムを構築せよ
たしかに、実務を通して、このプロセスを実施することで、成果を得ることができましたが、
本書が求めるように、設計部門からフィールド部門にまたがる情報連携を最初から仕組む
のは、大変骨の折れる仕事です。まず、小規模でのこれらの取り組みによる効果が見いだせ
るか? 以下にお勧めの方法を紹介し、あとがきと致したいと思います。お役に立てれば、幸
いです。尚、実際の POC の例などの具体的な内容 (DITA による再利用性の検証等) につ
いて、別の機会に譲りたいと思います。
POC の例
実施グループですが、製品マニュアルの制作企画部門が担当します。
用意するのは、既存の製品マニュアル 3 種で、パーツカタログ(部品カタログ、部品明細書
等）
、サービスマニュアル（ショップマニュアル、保守マニュアル、整備マニュアル等）と、
取扱説明書（運用マニュアル、運用手引書等）です。
以下は、概要手順です。
1
2
パーツカタログを本書にある物理分割とし
て活用する。物理分割は、PDS の eBOM/mBOM
を活用するよう指示されているが、パーツ
カタログは、これを具現化したもので、各部
品リストから、親子関係と数量が定義でき
る。
「3.2.4 明示的な親子関係による物理分
割」参照方。上位レベルは、製品を脱がす順
番で部品リストに至るように決める。
故障診断手順（通常は、サービスマニュアル
に記載）で、現象別に記載されたトラブルシ
ューティングから、機能分割のシステムと
サブシステムを決める。
現象別故障診断は、トップダウンに診断す
る手順であり、機能不良をキーに分析する
過程が、機能分解に利用できる。
製品の分解順に上位レベルを決める。図の
ように 3 階層が揃うとは限らない。
どの機能が失われたかで分解する。
3
サービスマニュアルの全最下層にある目次
を、1 の物理分割で得た部品リストに割り付
ける。目次が示す内容が、どの部品リストに
関係するかを判断する。これにより、相互参
照マップが作成できる。
「3.2.3 相互参照（ハ
ードウェアのみ）による物理および機能分
割の併存」参照方。
「構造作動」のような複
数の部品リストにまたがる目次は、各部品
リストにリンクする必要がある。
4
取扱説明書の全最下層を上記手順と同様に
部品リストに割り付ける。
ただし、取扱説明書の内容には、製品の機能
や特徴を説明するものが多々あり、部品リ
ストとの関係が明確でないか、あるいは出
来ない。この場合は、2 で作成した機能分解
のシステムまたはサブシステムに割り付け
る。
「3.1.2.6 機能分割と物理分割の並行利
用手法」参照方。また、製品そのものに関す
る内容(安全ガイド、PL 関係、使用環境条件
等)に関する目次は、リンクせずに置く。
5
3,4 で全ての割り付けが完成したら、2 の機
能分割と、3 の物理分割を併合し、統合した
製品階層構造に再構成する。「3.2.2 機能と
物理分割の混合」参照方。
ユニットとサブ機能の対応は、現象別故障
診断の原因系との突き合わせや、機能作動
の対応する機能との親和性で決めていけ
る。
6
最後に、コード付けをすることで、ナンバリ
ングコードが完成する。
ここで、手順 4 でリンクせずにある製品全
体を説明する目次は、S1000D の SNS に倣っ
て、
「共通ノード」に収納する。
S1000D の右図の例では、G- 一般車両が、製
品ノードに相当。その傘下の A～S は、説明
上は、第一階層レベルの先頭文字を使って
システム・系統を大分類しているが、第一階
層は、アルファベット+数字で定義してい
る。(例: A0～A9)
システムや系統は、機能のモジュール化に
対応していて、第一階層にシステム名=モジ
ュール名として現れることが多い。
これで、トピックを収納するフォルダーが完成します。あとは、格納するトピックを特定す
る情報種別を付加することで、トピック個々をナンバリングコード+情報種別で、ユニーク
に特定することができます。
再利用の肝は、トピックの客観的な特定の仕組みにあると指摘しましたが、ここまでで、そ
のための準備が出来上がります。
最後に、POC の指標を示します。
期待指標
概要
設計変更等に連携した製品テ
設計変更は、直接部品リストに現れます。上記の手順を
クニカルコンテンツの連携
通じて、部品リストには関連するドキュメントの目次が
紐づいていますので、どのマニュアルのどの部分を見直
すべきか即座に判明します。
コンテンツ制作者の為の元資
制作者は、担当する目次から、部品リストまたは、システ
料リンク
ム／サブシステムを特定できます。関連資料は、あらか
じめこの部品リストやシステム／サブシステムに連携さ
せることで用意に検索・閲覧ができるように仕組めます
コンテンツ制作者へのコンテ
コード化することで、制作すべき内容が明確になります。
ンツ制作内容の指示の徹底
制作企画グループは、可能な限り、ナンバリングコード
と情報種別を事前にドキュメント化し、制作ガイドとし
て提示することで、指示が徹底します。
再利用比率
部品リストを起点として、新規作成すべき目次と変更す
べき目次が明確になるため、再利用率を事前に予測する
ことが可能です。また、結果的に実際に実施した制作内
容と突き合わせることで、コードシステムの改善につな
がります。
更なる改善には、本文にある「代替要素」と「バージョン」をコード化し、適応性による
フィルタの利用が有効です。これにより、一層の部品化と再利用性の向上が期待できま
す。S1000D 仕様の DMC(Data Module Code)に、実装例がありますので、ご参照くださ
い。
終わり

Download Report