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

鉄道車両情報管理装置におけるソフトウェア開発プロセス改善
伊丹事業所　技術第１部　車両情報システム第２課　藤原　祐貴、 崎山　智代システム開発課　井筒　啓満
鉄道車両情報管理装置におけるソフトウェア開発プロセス改善
特集論文
１．まえがき
当所では、鉄道車両搭載機器の情報を統合制御し、機器監視、制御、乗務員支援を行う、車両情報管理装置（以下、TCＭＳ（Train Control and ManagementSystem）のソフトウェア開発を行っている。電鉄各社では、より快適な車内つくりや安全性の向上、メンテナンスの効率化を常に図っており新車投入後の車両改造が多く、それにともないソフトウェア改造の機会が多い。そのため当所のソフトウェア開発は派生開発が中心で行われている。近年ＴCＭＳは、高度な機能を求められるようになり、ソフトウェアは次第に複雑となってきた。また電鉄各社からは納期の短縮要求や、ＴCＭＳが障害に陥った場合、電車が止まるなど社会的影響が大きいことから従来以上の高い品質を強く求められるようになってきた。一方、開発現場では長年の改変積み重ねによりプログラムは複雑化・肥大化する中、従来の開発手法から脱却できず工数だけが増大していた。客先のニーズに応えるには大幅な品質向上及び効率化が必要であり、そのためには抜本的品質改善が必要であった。そこで当所では、２０１５年下期より派生開発特有の「短納期」や「部分理解」といった問題に合理的に対応する方法として提供された開発アプローチであるＸＤＤＰ（eXtreme DerivativeDevelopment Process）を導入し試行を行った。現在ではＴCＭＳの開発スタイルに沿うよう、伊事版ＸＤＤＰを確立させ品質向上に大きな成果を上げることができた。本稿では、従来の問題点を伊事版ＸＤＤＰの構築によってどのように改善できたか、また効率化に向けての改善活動について紹介する。
２．従来のソフトウェア開発の問題点
２．１　品質データからみた問題従来は、ソフトウェア品質を向上させるべく様々な対策を講じたためソフトウェア開発工数は肥大化する一方であった。しかし多数の対策を講じているにも関わらず、障害の件数や手戻りの工数は減少傾向にあるものの撲滅には至っていない。また、障害はソフトウェア設計フェーズで作り込まれているものが多く、そしてその要因は図１に示すように「流用元ソフトウェア仕様の理解不足」や「流用時、影響範囲の検討不足」が大半を占め、従来の改善策では効果は少なかった。図１．障害要因内訳２．２　インプット資料の問題ソフトウェア設計へのインプット資料は、１システムにつき多く分冊されており、図２に示すようにそれぞれの仕様書と紐付けられているが、多くの仕様書から関連を整理することに時間を要していた。図２．システム仕様書体系（注１） 要求文から要求を分割・階層化し、要求仕様・理由・説明をセットにして、表形式で仕様書を記述・管理すること。12鉄道車両情報管理装置におけるソフトウェア開発プロセス改善また、図３に示すように変更箇所がまとまっておらず変更箇所の確認が困難であることや、システム仕様書には要求及び変更理由の記載がなく結果のみが記載されるため、なぜ変更するのかが不明であり、システム設計者の意図と齟齬が発生していた。図３．システム仕様書の変更箇所２．３　受注フェーズ内の問題（1） 既存ソフトウェアの解析が困難ＴCＭＳの開発当初は、現在よりも開発規模が小規模であったため、ソフトウェア設計後、設計書作成と同時にソースコードへ追加や改造を行う場合があった。そのためソフトウェアドキュメントの内容が局所的であったり、漏れが発生しやすく、開発が複雑化・大規模化していく中で、図４に示すように開発者はソフトウェア全体像を理解できないまま変更箇所のみを仕様書化することとなり、変更漏れや変更方法の誤りが発生していた。図４．従来のプログラム仕様書（２） ソフトウェア設計書の検証が不十分ソースコードとの対応をとりながらソフトウェア設計書を作成しているが、変更点が多く管理が不十分であった。また図５に示すようにデザインレビューの実施タイミングや回数も不適切であった。図５．従来のソフトウェア開発プロセス（3）非効率なプログラム変更作業同一の改造工事内で、仕様書を受領するつど局所的にプログラムを変更していた。図６に示すように同じ担当者が同じプログラムファイルを何度も開けてプログラムを変更することがありムダや誤りが多く発生していた。図６．従来のプログラム変更プロセス３．ＸＤＤＰの導入３．１　ＸＤＤＰとはXDDPとは、「変更」に特化した「派生開発」のためのプロセスモデルで、３つの成果物（図７、以下ＸＤＤＰ３点セット）となる変更要求仕様書（以下USDM（UniversalSpecfic Description Manner）（注1））、トレーサビリティマトリクス（以下TM）、変更設計書により、モレ・ミス・ムダを防止でき、そして３つの成果物作成後に一斉にコーディングを行うことで効率化が図れるのが特徴である。そしてＸＤＤＰを導入することによって期待される効果は以下のとおりである。① ＵＳＤＭでは要求と仕様を形式化することにより、要求仕様の抜けや漏れ、矛盾などの問題点を見つけやすくする。② ＴＭではＵＳＤＭで定義した仕様に対するコードをマトリクス表で対応付けることにより、変更仕様に対する影響範囲を把握することができ、変更箇所の抜けや漏れを防ぐ。③ 変更設計書では変更箇所に対してどのような変更をするのかを設計し、それをもとに有識者と綿密にレ13鉄道車両情報管理装置におけるソフトウェア開発プロセス改善ビューすることによりミスを防ぐ。図７．ＸＤＤＰ３点セット３．２　ＸＤＤＰの活用当所では、２．２項で述べたインプット資料の問題についてはＵＳＤＭを活用することにより、変更箇所をモレなく抽出でき、変更理由を記載することでシステム設計者の意図と齟齬なく要求と仕様を明確にできると判断した。また２．３項で述べた受注フェーズの問題については、ＵＳＤＭとＴＭを活用することにより変更する全体像が把握でき影響範囲を見渡すことができる。そして変更設計書で変更内容を具体化することによりレビューやテストがよりきめ細かく実施できると判断しＸＤＤＰの活用を進めた。一般のＸＤＤＰは、要求定義から組合試験までをスコープとしているが、「伊事版ＸＤＤＰ」では受注範囲にあるソフトウェア設計から組合せ試験をスコープとし、３．１項で述べたＸＤＤＰの特徴をもとに、ＸＤＤＰ３点セットの内のＵＳＤＭ及びＴＭをＴCＭＳのソフトウェア開発に最大限活かせるようカスタマイズして、「伊事版ＸＤＤＰ」を構築した。第一に変更点一覧の全体概要をシステム要求、変更概要の記載内容をなぜ変更が必要なのか、または何を実現したいのかといった理由とし、次にシステム仕様書の内容をシステム仕様（ソフトウェア要求）と捉えるようにした。それを図８に示すように階層化して整理・明確化するようにした。そしてこの要求と仕様をもとにソフトウェア仕様を設計することにした。この手順により散らばったシステム仕様をＵＳＤＭへの記載でシステム要求からソフトウェア仕様までを一環して把握することができ、レビューでの変更モレや影響範囲の検討モレへの気づきを強化することが可能となった。図８．伊事版ＸＤＤＰのＵＳＤＭＴＭでは図８のＵＳＤＭに図９で示すようにテスト観点を追加することにより、観点に応じた組合せ試験設計を行うことができ、組合せ試験の網羅性を高めた。図９．伊事版ＸＤＤＰのＴＭ３．３　伊事版ＸＤＤＰの導入結果伊事版ＸＤＤＰを構築し運用した結果、組合せ試験以降の１案件あたりの障害件数が、同規模の案件と比較すると大幅に削減することができた。また、障害除去状況についてみても、図１０に示すように従来では検出できず試験フェーズまで持ち込んで刈り取っていた障害が、ソフトウェア設計で刈り取ることができるようになった。これはソフトウェア設計段階でシステム仕様の不明点が明確にできてきたことから、システム設計者への問合せや、システム仕様の理解不足、思い込み、勘違いによる手戻りが減少したことによるものである。（注２） フロントローディング化率の略。システム開発におけるフロントローディングを定量的に示すために用いている指標　FL化率＝ 設計・製作工程の摘出誤り件数÷全工程の摘出誤り件数）14鉄道車両情報管理装置におけるソフトウェア開発プロセス改善図１０．４岳グラフ比較その結果、２０１７年度完了の適用工事４０件（適用率約５０％）についてＦＬ化率（注2）は平均８７％の結果を得ており、目標値の８０％を大幅にクリアすることができた。図１１はその適用工事（一部抜粋）のデータである。図１１．伊事版XDDPの適用評価一例また、下流フェーズでの手戻り時間が減り、ソフトウェア開発全体の時間が短縮されたことで、変更内容の再確認や組合せ及びシステム試験などに時間を費やすことができたため、出荷後障害の削減につながったと言える。ただし、２０１７年度の適用率が約５０％であること、一部案件では目標値が未達成であったため、今後適用拡大するとともに精度を高めて改善に取組んでいく。４．ＵＳＤＭを利用した大規模案件への展開４．１　ＵＳＤＭ形式のソフトウェア設計書の確立３項で述べたように、当所では「伊事版ＸＤＤＰ」を構築し、派生開発を対象として「変更点」に着目しソフトウェア設計品質を高めてきた。しかし、２０１８年に客先の主力路線への新車投入にあわせて、大規模なＴＣＭＳの新規案件が予定されていたため、当所ではこの新規案件についても「伊事版ＸＤＤＰ」を適用して従来型のソフトウェア開発プロセス（ソースコードベースの作り込み）から脱却し、ドキュメントベースの品質作り込みを行うべく、一からＵＳＤＭを利用したソフトウェア設計書を確立してソフトウェア開発を進めた。進め方は図１２で示すように各ＳＴＥＰに分けてＳＴＥＰ毎に作業を行った。ＳＴＥＰ１： 流用元ソースコードから実装仕様を表現する。ＳＴＥＰ２： 実装仕様から機能仕様に変換する。ＳＴＥＰ３： 要求と仕様を分離してＵＳＤＭで記述し、ソースコードのトレースを取る。ＳＴＥＰ４： システム仕様書から要求を抽出し、異なる要求をＵＳＤＭに反映する。ＳＴＥＰ５： 抽出した要求をもとに仕様を変更し、ソースコードの変更要否を可視化する。図１２．新規案件への適用手順次にシーケンス図を作成し、機能のインプット・アウトプットを明確にするとともに、図１３に示すようにＵＳＤＭに記載した要求仕様と紐付けを行うことで、機能の動作の中のどの部分が作成したシーケンス図に該当するかをわかりやすく表現した。15鉄道車両情報管理装置におけるソフトウェア開発プロセス改善図１３．ソフトウェア設計書４．２　大規模案件への適用結果今回の新規案件と同規模の過去案件を従来型で行った場合のＦＬ化率を比較した結果、６４％から８６％（図１４）へと大幅に改善することができた。これは要求仕様を可視化し、ソフトウェア設計を行い、ドキュメントベースでレビューを行ったことによる結果である。また、今回の新規案件では現地流出障害は、大規模案件にもかかわらず軽微なもの１件のみであり、品質を大幅に向上することができた。図１４．４岳グラフ比較②５．さらなる改善に向けて５．１　ソフトウェアプロダクトライン開発ソフトウェアプロダクトラインとは、対象とする製品群の共通部分と差異を把握し、その共通部は再利用し、差異を効率的に開発するための手法である。これは、個々の製品開発での最適化ではなく、系列製品の開発全体での最適化を狙った開発パラダイムで個々の技術の枠を超えた、総合的な取り組みであり、以下の効果が見込まれる。① 開発工数・期間の短縮による短期での製品の市場投入② 製品品質の向上４項で述べたＵＳＤＭ形式でソフトウェア設計書を記載することで、同種類の異なった製品において、ソフトウェア仕様を比較し差異を明確にすることができ、以下に示すプロダクトライン開発の道が拓けるようになった。例えば、電鉄会社では様々な車形の電車を開発しており、それに対応するソフトウェアは全て異なる。しかし、異なる車形でも基本的な考え方は各電鉄会社にあり、共通機能が少なからず存在している。したがって図１５に示すように機能毎に車形を横並びにして比較し、共通部と可変部、固定部を切り分け、共通部を資産として再利用を行うことで効率化を図っていく。図１５．共通部・可変部の明確化５．２　ソフトウェアプロダクトラインの手順新規案件でＵＳＤＭ形式で要求と仕様を明確にし、ソフトウェア仕様からソースコードまでを管理することができた。これらを利用して図１６に示すように各ＳＴＥＰに分けて、ＳＴＥＰ毎に作業を行う。図１６．プロダクトライン開発手順ＳＴＥＰ１： 車形毎の同要求と比較を行い、仕様の差異を抽出する。ＳＴＥＰ２： 同要求の仕様を共通部・可変部を明確にする。執筆者紹介藤原　祐貴 フジワラ　ユウキ2008年入社。主にＴＣＭＳのソフトウェア開発に従事。現在伊丹事業所技術第１部車両情報システム第２課。崎山　智代 サキヤマ　トモヨ1998年入社。主にＴＣＭＳのソフトウェア開発に従事。現在伊丹事業所技術第１部車両情報システム第２課グループリーダ。井筒　啓満 イヅツ　ヒロミツ1998年入社。主にＴＣＭＳのソフトウェア開発に従事。現在伊丹事業所技術第１部システム開発課グループリーダ。16鉄道車両情報管理装置におけるソフトウェア開発プロセス改善ＳＴＥＰ３： ソフトウェアアーキテクチャの共通部・可変部を明確にする。ＳＴＥＰ４： 共通部をコア資産として蓄積する。ＳＴＥＰ５： コア資産として要求仕様とソースコードは共通のソフトウェア設計書に記載する。上記ＳＴＥＰ１から５を繰り返し行い、コア資産として蓄積していく。現在新規案件をもとに図１７に示すように他の車形について、継続して試行中である。図１７．同様機能の車形比較で共通部・可変部の導出６．むすび本稿で紹介したＸＤＤＰを導入したことで、当所のソフトウェア開発プロセスが、ソースコードベースの作り込みからドキュメントベースの品質作り込みの文化に変貌をとげ、品質優先のプロセスに変わった。これにより品質が大幅に改善された。今後、ドキュメントとソースコードの資産化を行うことで、品質向上に加え効率化にも成果が出るよう進めていく。さらにソフトウェアの資産化には、システム設計での共通化を図ることが重要と考える。今後システム設計部門とより一層の連携を深め、システム設計からのＸＤＤＰの導入とソフトウェアプロダクトライン開発を積極的に提案し実現させる。