鉄道車両情報管理装置におけるソフトウェア開発プロセス改善

特集論文

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善
伊丹事業所

技術第１部

１．まえがき

車両情報システム第２課 藤原 祐貴、崎山 智代
システム開発課 井筒 啓満
件数や手戻りの工数は減少傾向にあるものの撲滅には至っていない。
また、障害はソフトウェア設計フェーズで作り当所では、鉄道車両搭載機器の情報を統合制御し、機込まれているものが多く、そしてその要因は図１に示すように器監視、制御、乗務員支援を行う、車両情報管理装置「流用元ソフトウェア仕様の理解不足」や「流用時、影響（以下、TCＭＳ（Train Control and Management

範囲の検討不足」が大半を占め、従来の改善策では効果System）のソフトウェア開発を行っている。電鉄各社では、は少なかった。

より快適な車内つくりや安全性の向上、メンテナンスの効率化を常に図っており新車投入後の車両改造が多く、それにともないソフトウェア改造の機会が多い。
そのため当所のソフトウェア開発は派生開発が中心で行われている。
近年ＴCＭＳは、高度な機能を求められるようになり、ソフトウェアは次第に複雑となってきた。
また電鉄各社からは納期の短縮要求や、ＴCＭＳが障害に陥った場合、電車が止まるなど社会的影響が大きいことから従来以上の高い品質を強く求められるようになってきた。
一方、開発現場では長年の改変積み重ねによりプログ
ラムは複雑化・肥大化する中、従来の開発手法から脱却できず工数だけが増大していた。客先のニーズに応えるには大幅な品質向上及び効率化が必要であり、そのためには抜本的品質改善が必要であった。そこで当所では、
２０１５年下期より派生開発特有の「短納期」や「部分理解」といった問題に合理的に対応する方法として提供され

図１．障害要因内訳

２．
２ インプット資料の問題た開発アプローチであるＸＤＤＰ（eXtreme Derivative

ソフトウェア設計へのインプット資料は、１システムにつきDevelopment Process）を導入し試行を行った。現在で多く分冊されており、図２に示すようにそれぞれの仕様書とはＴCＭＳの開発スタイルに沿うよう、伊事版ＸＤＤＰを確立紐付けられているが、多くの仕様書から関連を整理するこさせ品質向上に大きな成果を上げることができた。とに時間を要していた。

本稿では、従来の問題点を伊事版ＸＤＤＰの構築によってどのように改善できたか、また効率化に向けての改善活動について紹介する。

２．従来のソフトウェア開発の問題点
２．
１ 品質データからみた問題
従来は、ソフトウェア品質を向上させるべく様々な対策を

図２．システム仕様書体系講じたためソフトウェア開発工数は肥大化する一方であった。
しかし多数の対策を講じているにも関わらず、障害の11

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善

また、図３に示すように変更箇所がまとまっておらず変更箇所の確認が困難であることや、システム仕様書には要求及び変更理由の記載がなく結果のみが記載されるため、なぜ変更するのかが不明であり、システム設計者の意図と齟齬が発生していた。

図５．従来のソフトウェア開発プロセス（3）非効率なプログラム変更作業
同一の改造工事内で、仕様書を受領するつど局所的にプログラムを変更していた。図６に示すように同じ担当者が同じプログラムファイルを何度も開けてプログラムを変更することがありムダや誤りが多く発生していた。

図３．システム仕様書の変更箇所

２．
３ 受注フェーズ内の問題（1）既存ソフトウェアの解析が困難
ＴCＭＳの開発当初は、現在よりも開発規模が小規模であったため、ソフトウェア設計後、設計書作成と同時にソー

図６．従来のプログラム変更プロセス

３．ＸＤＤＰの導入

スコードへ追加や改造を行う場合があった。
そのためソフトウェアドキュメントの内容が局所的であったり、漏れが発生しやすく、開発が複雑化・大規模化していく中で、図４に示３．
１ ＸＤＤＰとはすように開発者はソフトウェア全体像を理解できないまま変XDDPとは、「変更」に特化した「派生開発」のためのプ

更箇所のみを仕様書化することとなり、変更漏れや変更方ロセスモデルで、３つの成果物（図７、以下ＸＤＤＰ３点セッ法の誤りが発生していた。

ト）となる変更要求仕様書（以下USDM（Universal（注1）
Specfic Description Manner））、
トレーサビリティマトリ

クス（以下TM）、変更設計書により、モレ・ミス・ムダを防止でき、そして３つの成果物作成後に一斉にコーディングを行うことで効率化が図れるのが特徴である。
そしてＸＤＤＰを導入することによって期待される効果は以下のとおりである。
① ＵＳＤＭでは要求と仕様を形式化することにより、要求仕様の抜けや漏れ、矛盾などの問題点を見つけやすくする。
図４．従来のプログラム仕様書② ＴＭではＵＳＤＭで定義した仕様に対するコードをマ（２）ソフトウェア設計書の検証が不十分影響範囲を把握することができ、変更箇所の抜けやソースコードとの対応をとりながらソフトウェア設計書を作トリクス表で対応付けることにより、変更仕様に対する漏れを防ぐ。

成しているが、変更点が多く管理が不十分であった。
また③ 変更設計書では変更箇所に対してどのような変更を図５に示すようにデザインレビューの実施タイミングや回数もするのかを設計し、それをもとに有識者と綿密にレ不適切であった。
（注 １ ） 要求文から要求を分割・階層化し、要求仕様・理由・説明をセットにして、表形式で仕様書を記述・管理すること。

12

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善

ビューすることによりミスを防ぐ。

れを図８に示すように階層化して整理・明確化するようにした。
そしてこの要求と仕様をもとにソフトウェア仕様を設計することにした。
この手順により散らばったシステム仕様をＵＳＤＭへの記載でシステム要求からソフトウェア仕様までを一環して把握することができ、レビューでの変更モレや影響範囲の検討モレへの気づきを強化することが可能となった。

図８．伊事版ＸＤＤＰのＵＳＤＭ

ＴＭでは図８のＵＳＤＭに図９で示すようにテスト観点を追加することにより、観点に応じた組合せ試験設計を行う
図７．ＸＤＤＰ３点セットことができ、組合せ試験の網羅性を高めた。

３．
２ ＸＤＤＰの活用
当所では、
２．
２項で述べたインプット資料の問題についてはＵＳＤＭを活用することにより、変更箇所をモレなく抽出でき、変更理由を記載することでシステム設計者の意図と齟齬なく要求と仕様を明確にできると判断した。
また２．
３項で述べた受注フェーズの問題については、ＵＳＤＭとＴＭを活用することにより変更する全体像が把握でき影響範囲を見渡すことができる。
そして変更設計書で変更内容を具体化することによりレビューやテストがよりきめ細かく実施できると判断しＸＤＤＰの活用を進めた。

図９．伊事版ＸＤＤＰのＴＭ

３．
３ 伊事版ＸＤＤＰの導入結果

一般のＸＤＤＰは、要求定義から組合試験までをスコー

伊事版ＸＤＤＰを構築し運用した結果、組合せ試験以プとしているが、「伊事版ＸＤＤＰ」では受注範囲にあるソフ降の１案件あたりの障害件数が、同規模の案件と比較すトウェア設計から組合せ試験をスコープとし、３．
１項で述べると大幅に削減することができた。
また、障害除去状況につたＸＤＤＰの特徴をもとに、ＸＤＤＰ３点セットの内のＵＳＤＭいてみても、図１０に示すように従来では検出できず試験及びＴＭをＴCＭＳのソフトウェア開発に最大限活かせるよフェーズまで持ち込んで刈り取っていた障害が、ソフトウェ

うカスタマイズして、「伊事版ＸＤＤＰ」を構築した。

ア設計で刈り取ることができるようになった。
これはソフトウェ第一に変更点一覧の全体概要をシステム要求、変更

ア設計段階でシステム仕様の不明点が明確にできてきた概要の記載内容をなぜ変更が必要なのか、または何を実ことから、システム設計者への問合せや、システム仕様の現したいのかといった理由とし、次にシステム仕様書の内理解不足、思い込み、勘違いによる手戻りが減少したこと容をシステム仕様（ソフトウェア要求）と捉えるようにした。
そによるものである。
13

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善

４．ＵＳＤＭを利用した大規模案件への展開
４．
１ ＵＳＤＭ形式のソフトウェア設計書の確立
３項で述べたように、当所では「伊事版ＸＤＤＰ」を構築し、派生開発を対象として「変更点」に着目しソフトウェア設計品質を高めてきた。
しかし、
２０１８年に客先の主力路線への新車投入にあわせて、大規模なＴＣＭＳの新規案件が予定されていたため、当所ではこの新規案件についても「伊事版ＸＤＤＰ」
を適用して従来型のソフトウェア開発
図１０．４岳グラフ比較

プロセス（ソースコードベースの作り込み）から脱却し、ドその結果、２０１７年度完了の適用工事４０件（適用率約を利用したソフトウェア設計書を確立してソフトウェア開発５０％）についてＦＬ化率は平均８７％の結果を得てお（注2）り、目標値の８０％を大幅にクリアすることができた。図１１はその適用工事（一部抜粋）のデータである。

キュメントベースの品質作り込みを行うべく、一からＵＳＤＭを進めた。進め方は図１２で示すように各ＳＴＥＰに分けてＳＴＥＰ毎に作業を行った。
ＳＴＥＰ１：流 用元ソースコードから実装仕様を表現する。
ＳＴＥＰ２：実装仕様から機能仕様に変換する。
ＳＴＥＰ３：要求と仕様を分離してＵＳＤＭで記述し、ソースコードのトレースを取る。
ＳＴＥＰ４：システム仕様書から要求を抽出し、異なる要求をＵＳＤＭに反映する。
ソース
ＳＴＥＰ５：抽 出した要求をもとに仕様を変更し、コードの変更要否を可視化する。

図１２．新規案件への適用手順
図１１．伊事版XDDPの適用評価一例

次にシーケンス図を作成し、機能のインプット・アウトプット

また、下流フェーズでの手戻り時間が減り、ソフトウェアを明確にするとともに、図１３に示すようにＵＳＤＭに記載し開発全体の時間が短縮されたことで、変更内容の再確認た要求仕様と紐付けを行うことで、機能の動作の中のどのや組合せ及びシステム試験などに時間を費やすことができ部分が作成したシーケンス図に該当するかをわかりやすくたため、出荷後障害の削減につながったと言える。

表現した。

ただし、
２０１７年度の適用率が約５０％であること、一部案件では目標値が未達成であったため、今後適用拡大するとともに精度を高めて改善に取組んでいく。

14（注 ２ ） フロントローディング化率の略。システム開発におけるフロントローディングを定量的に示すために用いている指標
FL化率＝設計・製作工程の摘出誤り件数
÷全工程の摘出誤り件数）

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善することで、同種類の異なった製品において、ソフトウェア仕様を比較し差異を明確にすることができ、以下に示すプ
ロダクトライン開発の道が拓けるようになった。
例えば、電鉄会社では様々な車形の電車を開発しており、それに対応するソフトウェアは全て異なる。
しかし、異なる車形でも基本的な考え方は各電鉄会社にあり、共通機能が少なからず存在している。
したがって図１５に示すように機能毎に車形を横並びにして比較し、共通部と可変
図１３．ソフトウェア設計書部、固定部を切り分け、共通部を資産として再利用を行うことで効率化を図っていく。

４．
２ 大規模案件への適用結果
今回の新規案件と同規模の過去案件を従来型で行った場合のＦＬ化率を比較した結果、６４％から８６％（図１４）へと大幅に改善することができた。
これは要求仕様を可視化し、ソフトウェア設計を行い、ドキュメントベースでレビューを行ったことによる結果である。
また、今回の新規案件では現地流出障害は、大規模案件にもかかわらず軽微なもの１件のみであり、品質を大幅に向上することができた。
図１５．共通部・可変部の明確化

５．
２ ソフトウェアプロダクトラインの手順新規案件でＵＳＤＭ形式で要求と仕様を明確にし、ソフトウェア仕様からソースコードまでを管理することができた。
これらを利用して図１６に示すように各ＳＴＥＰに分けて、ＳＴＥＰ毎に作業を行う。

図１４．４岳グラフ比較②

５．さらなる改善に向けて
５．
１ ソフトウェアプロダクトライン開発
ソフトウェアプロダクトラインとは、対象とする製品群の共通部分と差異を把握し、その共通部は再利用し、差異を効率的に開発するための手法である。
これは、個々の製品開発での最適化ではなく、系列製品の開発全体での最適化を狙った開発パラダイムで個々の技術の枠を超えた、総合的な取り組みであり、以下の効果が見込まれる。
① 開発工数・期間の短縮による短期での製品の市場投入② 製品品質の向上
４項で述べたＵＳＤＭ形式でソフトウェア設計書を記載

図１６．プロダクトライン開発手順

ＳＴＥＰ１：車 形毎の同要求と比較を行い、仕様の差異を抽出する。
ＳＴＥＰ２：同要求の仕様を共通部・可変部を明確にする。
15

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善

ＳＴＥＰ３：ソフトウェアアーキテクチャの共通部・可変部を明確にする。
ＳＴＥＰ４：共通部をコア資産として蓄積する。
ＳＴＥＰ５：コア資産として要求仕様とソースコードは共通のソフトウェア設計書に記載する。
上記ＳＴＥＰ１から５を繰り返し行い、コア資産として蓄積していく。
現在新規案件をもとに図１７に示すように他の車形について、継続して試行中である。

図１７．同様機能の車形比較で共通部・可変部の導出

６．むすび
本稿で紹介したＸＤＤＰを導入したことで、当所のソフトウェア開発プロセスが、ソースコードベースの作り込みからドキュメントベースの品質作り込みの文化に変貌をとげ、品執筆者紹介質優先のプロセスに変わった。
これにより品質が大幅に改藤原善された。
今後、ドキュメントとソースコードの資産化を行うこ

2008年入社。主にＴＣＭＳのソフトウェとで、品質向上に加え効率化にも成果が出るよう進めていア開発に従事。現在伊丹事業所技術く。

祐貴

フジワラ ユウキ

第１部車両情報システム第２課。

さらにソフトウェアの資産化には、システム設計での共通化を図ることが重要と考える。今後システム設計部門とより崎山一層の連携を深め、システム設計からのＸＤＤＰの導入とソ1998年入社。主にＴＣＭＳのソフトウェ

フトウェアプロダクトライン開発を積極的に提案し実現させる。

智代

サキヤマ トモヨア開発に従事。現在伊丹事業所技術第１部車両情報システム第２課グループリーダ。
井筒啓満

イヅツ ヒロミツ

1998年入社。主にＴＣＭＳのソフトウェ
ア開発に従事。現在伊丹事業所技術
第１部システム開発課グループリーダ。

16