鉄道車両用空調制御装置のソフトウェア開発におけるプロセス改善

鉄道車両用空調制御装置の鉄道車両用空調制御装置の一般論文
ソフトウェア開発におけるプロセス改善
ソフトウェア開発におけるプロセス改善
長崎事業所 技術第 2 部 ファームウェアシステム課

鉄道車両用空調制御装置のソフトウェア開発におけるプロセス改善
長崎事業所 技術第 2 部 ファームウェアシステム課
１．まえがき１．まえがき

長崎事業所

技術第2部

峯本 秀樹、太田 雄幸
峯本 秀樹、太田 雄幸

ファームウェアシステム課

２．車両空調システムの概要
峯本 秀樹、太田 雄幸
２．車両空調システムの概要

２．１ 空調装置
鉄道車両用空調装置（図1）は三菱電機㈱長崎製作
１．まえがき
２．車両空調システムの概要
２．１ 空調装置
鉄道車両用空調装置（図1）は三菱電機㈱長崎製作
所の主要製品である。鉄道車両用空調装置（以下、空所の主要製品である。鉄道車両用空調装置（以下、空鉄道車両用空調装置（図1）は、三菱電機㈱長崎製作所の主2.1
空調装置
通勤電車を例に、車両内機器の構成を図2に、冷調装置）は、空調制御装置と装置に組み込まれた制御要製品である。鉄道車両用空調装置（以下、空調装置）は、
通勤電車を例に、車両内機器の構成を図2に、冷調装置）は、空調制御装置と装置に組み込まれた制御
ソフトウェア（以下、空調制御ソフトウェア）で制御してい空調制御装置と装置に組み込まれた制御ソフトウェア（以下、 凍サイクルの概念を図3に示す。
通勤電車を例に、車両内機器の構成を図2に、冷凍サイク
凍サイクルの概念を図3に示す。
フトウェア（以下、空調制御ソフトウェア）で制御してい空調制御ソフトウェア）で制御している。
ルの概念を図3に示す。
る。
。
近年、空調装置は市場が拡大し、快適性の追求により、
近年、空調装置は市場が拡大し、快適性の追求によ
近年、空調装置は市場が拡大し、快適性の追求によきめ細かい制御が要求されるようになってきた。
、きめ細かい制御が要求されるようになってきた。
また、鉄道車両には、通勤電車、特急電車、新幹線や豪、きめ細かい制御が要求されるようになってきた。
また、鉄道車両には、通勤電車、特急電車、新幹線
華列車など様々な種類があり、それらの車両特性に合わせまた、鉄道車両には、通勤電車、特急電車、新幹線
た制御が要求されてきた。
や豪華列車など様々な種類があり、それらの車両特性
や豪華列車など様々な種類があり、それらの車両特性
このため、空調制御ソフトウェアは種類が多く、仕様がに合わせた制御が要求されてきた。
に合わせた制御が要求されてきた。
複雑化している。
このため、空調制御ソフトウェアは、種類が多く、仕様
このため、空調制御ソフトウェアは、種類が多く、仕様が複雑化している。
が複雑化している。
図２．車両内機器の構成
図２．車両内機器の構成
図２．車両内機器の構成

図１．鉄道車両と空調装置の外観
当所は、空調制御装置のソフトウェア開発を担当している。空調制御ソフトウェアの開発では、ベースとなる標準

図１．鉄道車両と空調装置の外観

図１．鉄道車両と空調装置の外観
ソフトウェアがあり、種類ごとに仕様変更や追加を行う派
生開発を行っている。

当所は、空調制御装置のソフトウェア開発を担当して本稿では、2章で空調装置についての説明を行い、3章～
当所は、空調制御装置のソフトウェア開発を担当して6章で空調制御ソフトウェア開発プロセスの課題と対策を述いる。空調制御ソフトウェアの開発では、ベースとなる標いる。空調制御ソフトウェアの開発では、ベースとなる標べる。
準ソフトウェアがあり、種類ごとに仕様変更や追加を行う
準ソフトウェアがあり、種類ごとに仕様変更や追加を行う
派生開発を行っている。
派生開発を行っている。
本稿では、2章で空調装置についての説明を行い、3
本稿では、2章で空調装置についての説明を行い、3章～6章で空調制御ソフトウェア開発プロセスの課題と章～6章で空調制御ソフトウェア開発プロセスの課題と対策を述べる。
対策を述べる。

図３．冷凍サイクルの概念図
図３．冷凍サイクルの概念図
図３．冷凍サイクルの概念図
空調装置は、室内送風機（図2①、図3①）、室外送風機（図2②、図3②）、圧縮機（図2③、図3③）により構成される。
空調装置は、室内送風機(図2①、図3①)、室外送空調装置は、室内送風機(図2①、図3①)、室外送
その他には、車両に設置される暖房ヒーター（図2④）、ライ風機(図2②、図3②)、圧縮機(図2③、図3③)により構風機(図2②、図3②)、圧縮機(図2③、図3③)により構
ンフローファン（図2⑤）、ダンパ（図2⑥、図3⑥）がある。
成される。その他には、車両に設置される暖房ヒータ
暖房ヒーターは、車両の床や座席下に設置される。ライ成される。その他には、車両に設置される暖房ヒーター(図2④)、ラインフローファン(図2⑤)、ダンパ(図2⑥、
ンフローファンは、天井内に設置される線状の扇風機で、ー(図2④)、ラインフローファン(図2⑤)、ダンパ(図2⑥、
空気のかくはんや涼感を与える役目がある。ダンパは、外
図3⑥)がある。
図3⑥)がある。
気の取り込み量を調節する。
暖房ヒーターは、車両の床や座席下に設置される。
暖房ヒーターは、車両の床や座席下に設置される。
空調装置では、冷凍サイクルの原理により、冷房を行っ
ラインフローファンは、天井内に設置される線状の扇ている。圧縮機により圧縮した冷媒ガスを循環し、室外送ラインフローファンは、天井内に設置される線状の扇風機で、空気のかくはんや涼感を与える役目がある。
風機により車内の熱を車外に排出し、室内送風機により車風機で、空気のかくはんや涼感を与える役目がある。
ダンパは、外気の取り込み量を調節する。
内に冷風を吹き出し、冷気を発生させている。
ダンパは、外気の取り込み量を調節する。
空調装置では、冷凍サイクルの原理により、冷房を
空調装置では、冷凍サイクルの原理により、冷房を行っている。圧縮機により圧縮した冷媒ガスを循環し、行っている。圧縮機により圧縮した冷媒ガスを循環し、室外送風機により車内の熱を車外に排出し、室内送
室外送風機により車内の熱を車外に排出し、室内送風機により車内に冷風を吹き出し、冷気を発生させて風機により車内に冷風を吹き出し、冷気を発生させて
いる。
56いる。

空調制御ソフトウェアの構成を、図4に示す。
電源基板

２．２ 空調制御ソフトウェア

鉄道車両用空調制御装置のソフトウェア開発におけるプロセス改善
CPU 基板

通信基板

入出力基板

空調制御ソフトウェアの構成を、図4に示す。
２．２
空調制御ソフトウェア

CPU 基板通信基板

２．２ 空調制御ソフトウェア
2.2 空調制御ソフトウェア
空調制御ソフトウェアの構成を、図4に示す。

通信基板

空調制御ソフトウェアの構成を、図4に示す。
空調制御ソフトウェアの構成を、図4に示す。

電源基板
入出力基板
CPU 基板

図５．空調制御装置の外観

入出力基板

電源基板

電源基板

３．ソフトウェア開発プロセスにおける課題
図５．空調制御装置の外観

空調制御ソフトウェアの開発は、図6で示すように設
図５．空調制御装置の外観

計部門、製作部門、品管部門に分かれている。当所は
図５．空調制御装置の外観
図５．空調制御装置の外観
３．ソフトウェア開発プロセスにおける課題
製作部門を担当しており、設計部門からシステム仕様書
３．ソフトウェア開発プロセスにおける課題を入手し、それを基にソフトウェアを製作している。
３．ソフトウェア開発プロセスにおける課題

３．ソフトウェア開発プロセスにおける課題
空調制御ソフトウェアの開発は、図6で示すように設

空調制御ソフトウェアの開発は、図6で示すように設計部

計部門、製作部門、品管部門に分かれている。当所は門、製作部門、品管部門に分かれている。当所は製作部門
空調制御ソフトウェアの開発は、図6で示すように設
空調制御ソフトウェアの開発は、図6で示すように設製作部門を担当しており、設計部門からシステム仕様書を担当しており、設計部門からシステム仕様書を入手し、計部門、製作部門、品管部門に分かれている。当所は計部門、製作部門、品管部門に分かれている。当所はを入手し、それを基にソフトウェアを製作している。
それを基にソフトウェアを製作している。
製作部門を担当しており、設計部門からシステム仕様書
製作部門を担当しており、設計部門からシステム仕様書

図４．空調制御ソフトウェア構成図を入手し、それを基にソフトウェアを製作している。
を入手し、それを基にソフトウェアを製作している。

図６．空調制御装置の開発体制

空調制御ソフトウェアは、①外部インタフェース、②温
図４．空調制御ソフトウェア構成図

度制御、③機器制御、④故障判定、⑤故障記録により構成される。

図４．空調制御ソフトウェア構成図
図４．空調制御ソフトウェア構成図
図４．空調制御ソフトウェア構成図

このソフトウェア製作において、以下の問題が顕在化してきた。

図６．空調制御装置の開発体制
図６．空調制御装置の開発体制
図６．空調制御装置の開発体制

図６．空調制御装置の開発体制(1)システム仕様書の記載内容に粒度の差
このソフトウェア製作において、以下の問題が顕在化し空調制御ソフトウェアは、①外部インタフェース、②温

このソフトウェア製作において、以下の問題が顕在化
以下に空調制御の流れを説明する。
空調制御ソフトウェアは、①外部インタフェース、②温 (2)てきた。
空調制御ソフトウェアは、①外部インタフェース、②温変更による影響範囲の漏れ
このソフトウェア製作において、以下の問題が顕在化

度制御、③機器制御、④故障判定、⑤故障記録により空調制御ソフトウェアは、①外部インタフェース、②温
このソフトウェア製作において、以下の問題が顕在化
度制御、③機器制御、④故障判定、⑤故障記録により してきた。
度制御、③機器制御、④故障判定、⑤故障記録により構成（1）
システム仕様書の記載内容に粒度の差してきた。
(3)(1)
開発期間の不足構成される。
度制御、③機器制御、④故障判定、⑤故障記録によりシステム仕様書の記載内容に粒度の差してきた。
される。 構成される。
（2）(1)変更による影響範囲の漏れシステム仕様書の記載内容に粒度の差(1)外部インタフェースからの入力情報により冷房か暖以下に空調制御の流れを説明する。
構成される。
これらの問題により、手戻りが増加し、その改善が急(2)変更による影響範囲の漏れ
以下に空調制御の流れを説明する。
(1)
システム仕様書の記載内容に粒度の差
以下に空調制御の流れを説明する。
（3）(2)開発期間の不足変更による影響範囲の漏れ
房か（空調運転モード）を決定する。
以下に空調制御の流れを説明する。
務となった。
これらの問題により、手戻りが増加し、その改善が急務(2)
変更による影響範囲の漏れ(3)
開発期間の不足(3)開発期間の不足(1)外部インタフェースからの入力情報により冷房か暖房か
外部インタフェースからの入力情報により冷房か暖(2)温度制御で車内温度と目標温度のかい離により冷(1)外部インタフェースからの入力情報により冷房か暖 (3)
（1）
となった。
開発期間の不足
これらの問題により、手戻りが増加し、その改善が急
これらの問題により、手戻りが増加し、その改善が急
このため、以下の課題を解決する必要があった。
(1)
外部インタフェースからの入力情報により冷房か暖房か（空調運転モード）を決定する。
（空調運転モード）を決定する。
房か（空調運転モード）を決定する。
暖房の強さ（運転能力）を決定する。

このため、以下の課題を解決する必要があった。
これらの問題により、手戻りが増加し、その改善が急務となった。
務となった。
このため、以下の課題を解決する必要があった。
務となった。
このため、以下の課題を解決する必要があった。

(2)温度制御で車内温度と目標温度のかい離により冷（2）
房か（空調運転モード）を決定する。
(2)温度制御で車内温度と目標温度のかい離により冷暖房の温度制御で車内温度と目標温度のかい離により冷(3)機器制御で空調運転モード及び運転能力に基づ

強さ（運転能力）
を決定する。
暖房の強さ（運転能力）を決定する。
(2)
温度制御で車内温度と目標温度のかい離により冷暖房の強さ（運転能力）を決定する。
暖房の強さ（運転能力）を決定する。
(3)機器制御で空調運転モード及び運転能力に基づき、室内送風機や暖房ヒーターといった空調装置（3）機器制御で空調運転モード及び運転能力に基づき、室内(3)機器制御で空調運転モード及び運転能力に基づ

このため、以下の課題を解決する必要があった。

送風機や暖房ヒーターといった空調装置を構成する機器を構成する機器を制御する。
き、室内送風機や暖房ヒーターといった空調装置(3)機器制御で空調運転モード及び運転能力に基づき、室内送風機や暖房ヒーターといった空調装置を制御する。
を構成する機器を制御する。
(4)空調装置の各機器の状態監視を行い、故障と判き、室内送風機や暖房ヒーターといった空調装置を構成する機器を制御する。
（4）空調装置の各機器の状態監視を行い、故障と判定した時(4)空調装置の各機器の状態監視を行い、故障と判を構成する機器を制御する。
定した時は、対象機器を停止する。
(4)空調装置の各機器の状態監視を行い、故障と判は、対象機器を停止する。
定した時は、対象機器を停止する。

(4)空調装置の各機器の状態監視を行い、故障と判(5)故障記録で故障発生時のトラブルシューティング（5）故障記録で故障発生時のトラブルシューティングや空調
定した時は、対象機器を停止する。
(5)故障記録で故障発生時のトラブルシューティング
定した時は、対象機器を停止する。

や空調制御状態の把握を目的としたデータの記録や空調制御状態の把握を目的としたデータの記録(5)制御状態の把握を目的としたデータの記録を行う。
故障記録で故障発生時のトラブルシューティング(5)故障記録で故障発生時のトラブルシューティングを行う。
を行う。 や空調制御状態の把握を目的としたデータの記録や空調制御状態の把握を目的としたデータの記録
空調制御装置の外観を図5に示す。空調制御ソフトウェア

を行う。

を行う。空調制御装置の外観を図5に示す。空調制御ソフトウ
は、CPU基板に実装され、入出力基板、通信基板の制御を空調制御装置の外観を図5に示す。空調制御ソフトウ行っている。
ェアは、CPU基板に実装され、入出力基板、通信基板

空調制御装置の外観を図5に示す。空調制御ソフトウ

空調制御装置の外観を図5に示す。空調制御ソフトウの制御を行っている。
ェアは、CPU基板に実装され、入出力基板、通信基板

図７．従来のソフトウェア製作の課題

図７．従来のソフトウェア製作の課題

図７．従来のソフトウェア製作の課題

ェアは、CPU基板に実装され、入出力基板、通信基板

図７．従来のソフトウェア製作の課題
図７．従来のソフトウェア製作の課題

ェアは、CPU基板に実装され、入出力基板、通信基板の制御を行っている。

の制御を行っている。
の制御を行っている。

57

鉄道車両用空調制御装置のソフトウェア開発におけるプロセス改善(1)システム仕様書の改善と変更点の正確な抽出
製作部門は、設計部門から入手したシステム仕

システム仕様書からXDDPの成果物への展開イメージ

様書と、派生元のシステム仕様書を基に、変更点を図８に示す。また、XDDPの成果物及び記述内容を表を抽出する。設計部門と製作部門、共に担当者を１に示す。

（1）システム仕様書の改善と変更点の正確な抽出

製作部門は、設計部門から入手したシステム仕様書と、増員したことで、システム仕様書の記載内容に粒システム仕様書からXDDPの成果物への展開イメージを図8に示す。また、XDDPの成果物及び記述内容を表1に示す。

派生元のシステム仕様書を基に、変更点を抽出する。設

度の差が現れ、仕様の要求意図を読み違える問計部門と製作部門、共に担当者を増員したことで、シス題が生じ、製作部門で正確に変更点を抽出できず
テム仕様書の記載内容に粒度の差が現れ、仕様の要求意
漏れが発生していた。これを防ぐために、システム
図を読み違える問題が生じ、製作部門で正確に変更点を仕様書の記載内容の改善と変更点の正確な抽出
抽出できず漏れが発生していた。これを防ぐために、システム仕様書の記載内容の改善と変更点の正確な抽出がが課題である。
課題である。
(2)変更点に対する影響範囲の網羅（2）変更点に対する影響範囲の網羅
仕様が複雑化しており、機能間の関係が複雑に仕様が複雑化しており、機能間の関係が複雑になり、1なり、１つの変更点に対するソフトウェアの変更箇

つの変更点に対するソフトウェアの変更箇所は複数箇所

所は複数箇所に及ぶようになった。また、変更やに及ぶようになった。また、変更や追加を繰り返したこ

追加を繰り返したことで、ソフトウェア構造が複雑化とで、ソフトウェア構造が複雑化し、熟練者以外では変し、熟練者以外では変更によって影響を受ける機更によって影響を受ける機能を正確に抽出できなくなっ

図８．システム仕様書からXDDPの成果物への展開

能を正確に抽出できなくなってきた。このため、変てきた。このため、変更前に動作していた機能が、変更

図８．システム仕様書からXDDPの成果物への展開
表１．XDDPの成果物の記述内容

更前に動作していた機能が、変更後は動作しなく後は動作しなくなる場合が発生するようになった。これなる場合が発生するようになった。これを防ぐためを防ぐために、影響範囲を正確に網羅することが課題でNo.

ある。 に、影響範囲を正確に網羅することが課題である。

No.

成果物

11

変更要求仕様書
変更要求仕様書（3）ソフトウェア開発期間の短縮(3)ソフトウェア開発期間の短縮
ソフトウェアの製作期間は、過去に比べて短くなって
ソフトウェアの製作期間は、過去に比べて短くなっきており、受注規模や案件の増加により、複数の案件がてきており、受注規模や案件の増加により、複数の輻輳することがある。このため、ソフトウェア製作にお案件が輻輳することがある。このため、ソフトウェア
いて、手戻りによるロスを削減し、短い工程で完了する製作において、手戻りによるロスを削減し、短い工ことが課題である。

程で完了することが課題である。

2

2
3

成果物

・どこを変更するか
・具体的にどのように変更するのか

マトリクス・他に変更する箇所がないか
・どのように変更すれば目的を達成でき

変更設計書

・具体的にどのように変更するのかると考えているか

変更設計書

・どうやって確認するか
・どのように変更すれば目的を達成で４．ソフトウェア開発プロセスの改善方針
４．ソフトウェア開発プロセスの改善方針

きると考えているか
・どうやって確認するか

今回、開発プロセスに派生開発の要求に合ったXDDP

今 回Derivative、 開 発 プ ロDevelopment
セ ス に 派 生 開Process）
発 の 要を導入し、求に合った（eXtreme
XDDP(eXtreme Derivative Development Process)を導
開発プロセス及びその成果物を見直すことで、3章で挙げた
入し、開発プロセス及びその成果物を見直すことで、3課題の解決を図った。
4.1

・何を変更するか
記述内容
・なぜ変更するか
・何を変更するか・どういう仕様をどのような仕様に変更
・なぜ変更するかするか
・何を変更すればよいと考えているか
・どういう仕様をどのような仕様に変更

トレーサビリティ するか・どこを変更するか
・何を変更すればよいと考えているか
マトリクス・他に変更する箇所がないか

トレーサビリティ
3

記述内容

表１．XDDPの成果物の記述内容「変更要求仕様書」（図8（1）、表1 No.1）は、客先要求（「要求」）と「何のために変更するのか」「何を期待しているのか」「変更要求仕様書」(図8(1)、表1 No.1)は、客先要求（「目的」）を明確にし、「要求」を実現する視点でソフトウェア（「要求」）と「何のために変更するのか」「何を期待してをどのように変更するか（「仕様」）を導き出す。また、「要求」

いるのか」（「目的」）を明確にし、「要求」を実現する視点と「仕様」を階層関係で表す。これにより、客先要求からソ章で挙げた課題の解決を図った。
XDDPの特徴

でソフトウェアをどのように変更するか（「仕様」）を導き出
フトウェアへの展開イメージが明確になり、変更漏れや変XDDPとは、派生開発に特化した開発アプローチであり、４．１ XDDPの特徴

す。また、「要求」と「仕様」を階層関係で表す。これによ更誤りを防止する効果がある。

短納期及び全体を理解して取り掛かることが困難といった派生開発特有の問題に対して、合理的に対応する方法である。

XDDPとは、派生開発に特化した開発アプローチであXDDPでは、変更漏れや変更誤りを防止するため、以下り、短納期及び全体を理解して取り掛かることが困難との3つの成果物を作成する。

いった派生開発特有の問題に対して、合理的に対応す（1）変更要求仕様書る方法である。
（2）
トレーサビリティマトリクス

XDDPでは、変更漏れや変更誤りを防止するため、以（3）変更設計書
下の3つの成果物を作成する。

り、客先要求からソフトウェアへの展開イメージが明確に「トレーサビリティマトリクス」（図8（2）、表1 No.2）は、
なり、変更漏れや変更誤りを防止する効果がある。
「仕様」に該当する箇所や変更箇所の関連性から影響範囲を抽出する。さらに、「仕様」と後述する「変更設計書」
を関連付「トレーサビリティマトリクス」(図8(2)、表1
No.2)は、「仕けることにより、影響箇所（他の変更箇所）の抜け、思い込様」に該当する箇所や変更箇所の関連性から影響範囲
みによる無関係な箇所の変更、「要求」の解釈誤りを防止するを抽出する。さらに、「仕様」と後述する「変更設計書」を効果がある。

関連付けることにより、影響箇所（他の変更箇所）の抜け、「変更設計書」（図8（3）、表1 No.3）は、具体的な変更方法

思い込みによる無関係な箇所の変更、「要求」の解釈誤を記述する。また、変更に伴う試験内容も記述する。

りを防止する効果がある。

(1) 変更要求仕様書「変更設計書」(図8(3)、表1 No.3)は、具体的な変更(2) トレーサビリティマトリクス

方法を記述する。また、変更に伴う試験内容も記述す(3) 変更設計書58

る。

されるようになった「変更点一覧」を適用し、従来の開発る。

プロセスを以下のようにした。改善後の開発プロセスの
鉄道車両用空調制御装置のソフトウェア開発におけるプロセス改善
されるようになった「変更点一覧」を適用し、従来の開発

４．２ XDDPの成果物導入方針

比較を図10に示す。
プロセスを以下のようにした。改善後の開発プロセスの比較を図10に示す。

４．２ XDDPの成果物導入方針

XDDPの3つの成果物について、以下の方針で本ソフ
4.2 XDDPの成果物導入方針
トウェア開発に適用した。

XDDPの3つの成果物について、以下の方針で本ソフ

XDDPの3つの成果物について、以下の方針で本ソフト「変更要求仕様書」と「トレーサビリティマトリクス」を同トウェア開発に適用した。

ウェア開発に適用した。
一様式で表現するとさらに効果的であるため、「変更点「変更要求仕様書」と「トレーサビリティマトリクス」を同「変更要求仕様書」と「トレーサビリティマトリクス」を同管理マトリクス表」として作成し、適用を行った。「変更要一様式で表現するとさらに効果的であるため、「変更点一様式で表現するとさらに効果的であるため、「 変更点管理
求仕様書」部は、「要求」と「仕様」を階層関係で表し、マトリクス表」として作成し、適用を行った。
「変更要求仕様
管理マトリクス表」として作成し、適用を行った。「変更要「要求」の目的、または理由を記述する「目的」欄及びそ書」
部は、「要求」と「仕様」を階層関係で表し、「要求」の目的、
求仕様書」部は、「要求」と「仕様」を階層関係で表し、の補足説明を記述する「説明」欄がある。「トレーサビリ「要求」の目的、または理由を記述する「目的」欄及びそティマトリクス」部は、機能を定義し、「仕様」がどの機能る「説明」欄がある。
「トレーサビリティマトリクス」部は、機の補足説明を記述する「説明」欄がある。「トレーサビリに影響するかを明示する。
または理由を記述する「目的」欄及びその補足説明を記述す
能を定義し、「仕様」がどの機能に影響するかを明示する。

ティマトリクス」部は、機能を定義し、「仕様」がどの機能
変更点管理マトリクス表の適用イメージを図9に示す。
変更点管理マトリクス表の適用イメージを図9に示す。
に影響するかを明示する。

変更点管理マトリクス表の適用イメージを図9に示す。

図１０．改善後の開発プロセスの比較(1) システム仕様書、変更点一覧レビュー
図１０．改善後の開発プロセスの比較
図10．改善後の開発プロセスの比較

変更点のチェックプロセスを新たに設けた。このプ
ロセスでは、開発案件と派生元案件のシステム仕（1）(1)システム仕様書、変更点一覧レビュー
システム仕様書、変更点一覧レビュー

図９．変更点管理マトリクス表への適用イメージ

様書に加え、変更点一覧を入手する。入手した資変更点のチェックプロセスを新たに設けた。このプロ
変更点のチェックプロセスを新たに設けた。このプ料のレビューを実施し、ソフトウェア開発に着手する。
セスでは、開発案件と派生元案件のシステム仕様書に加ロセスでは、開発案件と派生元案件のシステム仕変更点一覧には、開発案件と派生元案件の差異のえ、変更点一覧を入手する。入手した資料のレビューを様書に加え、変更点一覧を入手する。入手した資他、変更理由及び変更内容が記載されている。
実施し、ソフトウェア開発に着手する。変更点一覧には、料のレビューを実施し、ソフトウェア開発に着手する。
開発案件と派生元案件の差異の他、変更理由及び変更内(2) 変更点抽出
変更点一覧には、開発案件と派生元案件の差異の容が記載されている。
このプロセスでは、開発案件と派生元案件のシステ
他、変更理由及び変更内容が記載されている。
（2）
変更点抽出
ム仕様書を参照し、変更点一覧をもとに変更点をまた、「変更設計書」については、既に運用していたソフト

また、「変更設計書」については、既に運用していたソウェア変更仕様書、及びソフトウェア試験仕様書が表1に示
図９．変更点管理マトリクス表への適用イメージ

フトウェア変更仕様書、及びソフトウェア試験仕様書がす記述内容に対応していたため、そのまま適用した。

表１に示す記述内容に対応していたため、そのまま適XDDPの3つの成果物と空調制御ソフトウェア開発の様式
また、「変更設計書」については、既に運用していたソ用した。
の対応について、表2に示す。
フトウェア変更仕様書、及びソフトウェア試験仕様書がXDDPの3つの成果物と空調制御ソフトウェア開発の表１に示す記述内容に対応していたため、そのまま適表２．XDDPの成果物と様式の対応
様式の対応について、表2に示す。
用した。
No.
XDDPの成果物
空調制御ソフトウェア開発での様式

このプロセスでは、開発案件と派生元案件のシステム
(2)
変更点抽出
抽出する。また、抽出した変更点に対し、ソフトウェ仕様書を参照し、変更点一覧をもとに変更点を抽出する。
このプロセスでは、開発案件と派生元案件のシステ
アの変更箇所及び変更内容を検討する。さらに、

1変更要求仕様書
変更点管理マトリクス表
XDDPの3つの成果物と空調制御ソフトウェア開発の表２．XDDPの成果物と様式の対応
トレーサビリティ
変更点管理マトリクス表
No.2
XDDPの成果物
空調制御ソフトウェア開発での様式
様式の対応について、表2に示す。
マトリクス

1

3

変更要求仕様書
変更設計書

また、抽出した変更点に対し、ソフトウェアの変更箇所

ム仕様書を参照し、変更点一覧をもとに変更点を変更に対する影響箇所も確認する。
及び変更内容を検討する。さらに、変更に対する影響箇抽出する。また、抽出した変更点に対し、ソフトウェ(3) 変更点管理マトリクス表所も確認する。

変更点管理マトリクス表
ソフトウェア変更仕様書

アの変更箇所及び変更内容を検討する。さらに、(2)の検討結果を変更点管理マトリクス表に反映す（3）
変更点管理マトリクス表

ソフトウェア試験仕様書

2

表２．XDDPの成果物と様式の対応
トレーサ
ビ リ テ ィ 変更点管理マトリクス表No.

XDDPの成果物
マトリクス

13

変更設計書
変更要求仕様書る。
変更に対する影響箇所も確認する。
（2）の検討結果を変更点管理マトリクス表に反映する。

空調制御ソフトウェア開発での様式(4)
変更点、変更方針レビュー(3)
変更点管理マトリクス表（4）
変更点、変更方針レビュー

ソフトウェア変更仕様書
変更点管理マトリクス表

５．ソフトウェア開発プロセスの改善

変更点及び変更方針の妥当性をレビューする。
変更点及び変更方針の妥当性をレビューする。
(2)の検討結果を変更点管理マトリクス表に反映すソフトウェア試験仕様書

2

5.1
3

トレーサビリティる。
製作部門での設計作業開始後、システム仕様書が変更さ
製作部門での設計作業開始後、システム仕様書が(4) 変更点、変更方針レビュー
れた場合は、随時、上記（1）～（4）を繰り返す。
変更された場合は、随時、上記(1)～(4)を繰り返す。
変更点及び変更方針の妥当性をレビューする。

変更点管理マトリクス表開発プロセスへのXDDP導入
マトリクス

５．ソフトウェア開発プロセスの改善

変更設計書

ソフトウェア変更仕様書

変更点管理マトリクス表及び設計部門で新たに作成されソフトウェア試験仕様書

また、システム仕様書において、章構成の統一及び図や
また、システム仕様書において、章構成の統一及びるようになった「変更点一覧」を適用し、従来の開発プロセ
５．１ 開発プロセスへのXDDP導入

表現方法の改善など記載方法の改善も行われた。

スを以下のようにした。改善後の開発プロセスの比較を図

図や表現方法の改善など記載方法の改善も行われ製作部門での設計作業開始後、システム仕様書がた。
変更された場合は、随時、上記(1)～(4)を繰り返す。

５．ソフトウェア開発プロセスの改善

10に示す。

変更点管理マトリクス表及び設計部門で新たに作成

また、システム仕様書において、章構成の統一及び５．１ 開発プロセスへのXDDP導入

図や表現方法の改善など記載方法の改善も行われた。

変更点管理マトリクス表及び設計部門で新たに作成
59鉄道車両用空調制御装置のソフトウェア開発におけるプロセス改善(4)「要求」の範囲が広い場合、「要求」の範囲を狭め

５．２ 変更点管理マトリクス表の改善
5.2 変更点管理マトリクス表の改善
開発プロセスの見直しに併せて、図9で示した変更点ることで、より詳細な検討ができる。今回、「上位要求」と「下位要求」の2階層の構成とすることで、「要（4）「要求」の範囲が広い場合、「要求」の範囲を狭めることで、求」の漏れを無くすようにした。
より詳細な検討ができる。
今回、「上位要求」と「下位要求」

開発プロセスの見直しに併せて、図9で示した変更点管理
管理マトリクス表に対して、以下の改善を実施した。変の2階層の構成とすることで、「要求」の漏れを無くすようマトリクス表に対して、以下の改善を実施した。変更点管にした。
６．開発プロセスへのXDDPの導入による効果

更点管理マトリクス表への展開イメージを図11に示す。
理マトリクス表への展開イメージを図11に示す。

６．開発プロセスへのXDDPの導入による効果
開発プロセスにXDDPを取り入れ、変更点一覧及び開発プロセスにXDDPを取り入れ、変更点一覧及び変更
変更点管理マトリクス表を追加することで、以下に示す
点管理マトリクス表を追加することで、以下に示す効果を効果を確認できた。
確認できた。

(1)
システム仕様書に記載された仕様の意図が明確（1）
システム仕様書に記載された仕様の意図が明確に理解でに理解できるようになり、設計部門及び製作部門
きるようになり、設計部門及び製作部門による変更点の相互チェックも可能となることで、変更点の抽出漏れがによる変更点の相互チェックも可能となることで、減少した。

変更点の抽出漏れが減少した。

（2）変更理由を明確に記述し、それを理解した上でソフト(2)
変更理由を明確に記述し、それを理解した上でウェア製作を行うため、変更内容と影響範囲の誤りが減

ソフトウェア製作を行うため、変更内容と影響範少した。

（3）開発プロセスに「変更点抽出」とそのレビューを追加し、囲の誤りが減少した。
妥当性をレビュー後、後工程へ移行するようにしたこと(3)
開発プロセスに「変更点抽出」とそのレビューをで、問題の早期発見が可能となった。これにより、手戻追加し、妥当性をレビュー後、後工程へ移行する

りするロスが減り、工期短縮が図れた。

ようにしたことで、問題の早期発見が可能となった。これにより、手戻りするロスが減り、工期短縮
が図れた。

７．むすび

派生開発の要求に合ったXDDPを取り入れ、開発プロセスの見直しを行うことで、派生開発で抱えていた問題を解
図11．変更点管理マトリクス表への展開イメージ
図１１．変更点管理マトリクス表への展開イメージ

７．むすび決することができた。変更点管理マトリクス表、ソフトウェ
ア変更仕様書及びソフトウェア試験仕様書内に試験結果を（1）変更点一覧に記載された項目を「変更点」とし、変更点管記入したソフトウェア試験成績書を他部門とのレビューの派生開発の要求に合ったXDDPを取り入れ、開発プ

理マトリクス表へ追加した「変更点一覧」欄へ展開する。
(1)変更点一覧に記載された項目を「変更点」とし、変審議資料としており、引き続き運用していく所存である。

また、変更点一覧に記載されている「変更前（派生元）の
更点管理マトリクス表へ追加した「変更点一覧」欄
内容」と「変更後（開発案件）の内容」の差分を「要求」としへ展開する。また、変更点一覧に記載されているて変更点管理マトリクス表へ記載し、「変更点」と紐付け「変更前（派生元）の内容」と「変更後（開発案件）る。さらに、「要求」に対するソフトウェアの変更内容（「仕の内容」の差分を「要求」として変更点管理マトリク様」）を記載する。これにより、関連性が明確になり、変更点の抽出漏れをチェックできる。
ス表へ記載し、「変更点」と紐付ける。さらに、「要求」（2）設計部門が提示する変更点は、システム全体を対象としに対するソフトウェアの変更内容（「仕様」）を記載ているため、必ずしもソフトウェアに変更が入るとは限する。これにより、関連性が明確になり、変更点のらない。
「変更有無」欄を追加し、ソフトウェアの変更有
抽出漏れをチェックできる。
（○）
無（×）を記載することで、製作部門や品管部門での試験の要否を明示できる。
(2)設計部門が提示する変更点は、システム全体を対（3）トレーサビリティマトリクス欄には、機能を定義し、ソロセスの見直しを行うことで、派生開発で抱えていた問
最後に、ソフトウェア開発プロセス改善にあたりご協力

題を解決することができた。変更点管理マトリクス表、ソ

いただいた関係者の方々に深く感謝申し上げる。

フトウェア変更仕様書及びソフトウェア試験仕様書内に試験結果を記入したソフトウェア試験成績書を他部門と執筆者紹介のレビューの審議資料としており、引き続き運用していく所存である。

峯本

秀樹

ミネモト

ヒデキ

1992年入社。主に空調制御システムの最後に、ソフトウェア開発プロセス改善にあたりご協力
ソフトウェア開発に従事。現在、長崎事
業所技術第2部ファームウェアシステム
いただいた関係者の方々に深く感謝申し上げる。
課。
太田

雄幸

オオタ

タケユキ

象としているため、必ずしもソフトウェアに変更が入1997年入社。主に空調制御システムのるとは限らない。「変更有無」欄を追加し、ソフトウェ

ソフトウェア開発に従事。現在、長崎事

フトウェアの変更で影響がある機能に「●」を記入する。
また、ソフトウェア変更仕様書及びソフトウェア試験仕アの変更有(○)無(×)を記載することで、製作部門
様書内の項番を併記し、対応を明確にすることで、変更
漏れや試験漏れをチェックできる。
や品管部門での試験の要否を明示できる。

(3)トレーサビリティマトリクス欄には、機能を定義し、ソフトウェアの変更で影響がある機能に「●」を記入 60する。また、ソフトウェア変更仕様書及びソフトウェ

業所技術第2部ファームウェアシステム課。