ページ最後部の業界事例に紹介のように、整備システム周りの現実課題は多く、整備システムが重要の証にもなっている。

• 整備部門はシステム部門あるいはシステム会社の理解にフィットする細部要求機能を整理できないあるいは大きな時間を要する。
• 業務担当により機能要求レベルがバラバラ（業務や組織が異なるためレベル統一性に欠ける）
• システム部門あるいはシステム会社は整備部門の実務機能ニーズの細部まで汲み取れないあるいは理解に大きな時間を要する。
• 実務担当者とシステム担当者の相互知識がコンピュータおよびDB土俵上で噛み合わない。
  → 上記の現実は航空会社自身でも分かっているため、大きなM/ H と1年以上にもおよぶ長い期間をかけてのシステム仕様とりまとめと、開発会社一体で要件定義を行っている状況がある。

• 要求機能／機能要件のまとめまで手が回らない。
• 大手航空会社のシステムレンタルはできれば避けたい
• 海外パッケージ等を検討しても、導入判断がむずかしい。

• 実業務へのフィット性に欠ける面は否めない
• 年次のカスタマイズ機能強化等でコストが嵩む
• 将来を含めて自社系によるプログラム改編を行えない

大手航空会社へ整備システム納入の大手SIヤーのプロジェクトマネージャと話す機会があったが、整備システム開発は整備業務とシステム/DBの両方に精通していることが重要であると述べていた。整備情報システムは、Phase�Vに至るまで度重なる機能強化を行っているが、この過程でも正にこのことが実感された。整備業務フィットのための、開発過程でテーブル設計の変更を伴う補正フィードバック量が想定外の状況を経験している。要件定義やテーブル設計の原則固定では細部改善は進まないし、フィードバック補正は業務を知らないと円滑に遂行できない。整備情報システム�Wは、開発当初から10年かけて今日の機能構成に至っている。 整備情報システム�Wは、システム開発並びにユーｻﾞｰ併用の総合テストマニュアルを特徴としている。テストマニュアルは実業務対応構成のため、ユーザーレベルの第2の要件定義書の目的を兼ねている。これにより、ユーザーは要求機能や要件定義書等の文書レベルでは見落とされがちの細部システム機能を、実業務レベルで総合確認できる。 基本製品がベースとなるため短期間で対応可能 自社慣用語や自社整備規則用語へ一致させるためのバイリンガル用語マスタを装備
（日本語はもとより、英語・中国語等の母国語対応可能／切替運用） 【設計部】
・ユーザー単位のリリース
・「詳細・機能要件定義書＋テーブル定義書」による
　プログラムコーディングでシステム完成
・「総合テストマニュアル」がユーザー要求仕様確認から
　納入検収に至るまでユーザー要件定義書の
　役割を果たす
・年次事業計画等に沿って発生する自社要件を逐次追加設定可能
・要求にそった開発支援

【プログラム部】
・ユーザー単位のリリース
・「総合テストマニュアル」がユーザー要求仕様確認〜納入検収に至るまでユーザー要件定義書の
　 役割を果たす
・要求機能確認〜カスタマイズ対応
・運用定着フォロー
・端末ライセンスフリー（社内全端末）

【オープンソ−ス】
・設計部とプログラム部の一体導入時に適用
・プログラム著作権譲渡／任意改編が可能（自社用途限定）
・Access VBA + SQL Server プログラムソースをベースに Oracle/Java 等への任意改編利用も可能

〔経緯状況〕
整備情報システム�T：ソースコード非開示
整備情報システム�U：ソースコード開示のみ
整備情報システム�W：上記の通り

構成		導入選択
		�@設計部 +α	�Aプログラム部
設計部	機能要件／詳細定義書	○
	DBテーブル定義書	○
	総合テストマニュアル	○	○
	バイリンガル用語マスタ	○
	事業者要件対応	△
	開発支援	△
プログラム部	カスタタマイズ対応	△	△
	実行プログラム	△	○
	操作マニュアル	△	○
	運用定着フォロー対応	△	○

○：標準納入アイテム 　　　△：オプション