このページの本文へ

ここから本文

テクノロジー

技術レポート:アーカイブ

Category:カーエレクトロニクス

車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善

車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善

ガソリンエンジン制御用コントロールユニット(以下、ECU)は車載制御装置のひとつであり、三菱電機(株)姫路製作所の主力製品である。当所ではECUに搭載するソフトウェアの開発を行っている。ECUのソフトウェア開発は、要求・スプリント(繰り返し開発の単位)・実車評価の一連のサイクルを繰り返し、制御仕様を作り込むアジャイル開発を採用している。(図1参照)特徴として、スプリントの大半は小規模(着手後、約2~4週でリリース可能な作業量)であること、月間約15本のプログラムを作成していること、複数機種を並行で開発し機種間で流用開発を実施していることが挙げられる。アジャイル開発は、開発途中でもカーメーカーの要求に応じて柔軟な仕様変更に対応可能となる反面、詳細な要件が固まらない段階での見積りも多く、工数超過の一因となってきた。本稿では、アジャイル開発において関係者の納得感を醸成しながら、ソフトウェアの見積り精度向上に結び付けた取り組みを紹介する。

車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善[PDFファイル]

参考情報:

  • この技術レポートは、当社が展開する自動車機器事業のカーエレクトロニクスソリューションに係る技術について著述されたものです。
  • カーエレクトロニクスソリューションは、姫路事業所三田事業所が提供しています。
車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善
1. まえがき
ガソリンエンジン制御用コントロールユニット(以下、ECU)は車載制御装置のひとつであり、三菱電機(株) 姫路製作所の主力製品である。当所ではECUに搭載するソフトウェアの開発を行っている。ECUのソフトウェア開発は、要求・スプリント(繰り返し開発の単位)・実車評価の一連のサイクルを繰り返し、制御仕様を作り込むアジャイル開発を採用している。(図1参照)図1. ECU用ソフトウェア開発の概要特徴として、スプリントの大半は小規模(着手後、約2~4週でリリース可能な作業量)であること、月間約15本のプログラムを作成していること、複数機種を並行で開発し機種間で流用開発を実施していることが挙げられる。アジャイル開発は、開発途中でもカーメーカーの要求に応じて柔軟な仕様変更に対応可能となる反面、詳細な要件が固まらない段階での見積りも多く、工数超過の一因となってきた。本稿では、アジャイル開発において関係者の納得感を醸成しながら、ソフトウェアの見積り精度向上に結び付けた取り組みを紹介する。
2. 課題
2.1 現状分析現状を把握するため、過去1年間のスプリントにおいて、見積り工数と実績工数がどのようになっているかを分析することとした。図2に結果を示す。見積り工数と実績工数がつりあう実線に対し、おおむね上部に分布していることから、見積りが過少傾向にあることが分かる。また、見積りが大きく外れているスプリントも散見され、対策が必要なことが分かる。図2. スプリントごとの見積り工数と実績工数の分布課題を特定するため、過去1年間のスプリントの中から、見積り誤差率(注1)が±25%を超えた81件を対象として傾向分析を行った。その結果をパレート図(図3)に示す。図3の結果から、以下の傾向が判明した。(1) 過去の実績値から生産性を算出しスプリントに当てはめると、実績値と見積り結果が乖離していた ( 図3( a) = 全体の30%(25件))(2) スプリントの途中で要件が変わり、ソフトウェアの開発規模が変化していた車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善姫路事業所 技術第2部 技術第2課繁田 展史(注1 ) 見積り工数ー実績工数       実績工数72車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善一般論文 ( 図3( b) = 全体の22%(18件))(3) 見積り工数にスプリントの特色を反映できていなかった(図3 (c)+(d)+(f) = 全体の35%(28件))図3. 見積り乖離の要因別分類2.2 課題一覧以前から類推見積りを使用してカーメーカーの要求を基に工数見積りを実施してきたが、十分な見積り精度を得ることができなかった。2.1節で分析した結果から、下記2件の課題を特定した。(1) 要件定義が不十分 (2.1節(2)に対応)詳細な要件を固めない状態でソフトウェア開発に着手すると、仕様設計以降の工程で抜けや漏れが発覚し、当初見積り以上の開発規模となっていた。そのため、ECU用ソフトウェアの開発特性に合わせた要件定義手法の構築が必要である。(2) 過去データに基づいた工数見積りが不十分 ( 2.1節(1()3)に対応)熟練者の経験知(暗黙知)をベースに類推見積りを実施してきたが、能力の高い熟練者の経験がベースとなるため工数が少なくなる傾向があった。そのため、過去のデータやスプリントの特性に応じた根拠のある工数見積りを実施する必要がある。3. 見積り手法改善への取り組み改善内容を説明する前に、ソフトウェアの見積り技法の説明を行う。見積りにはソフトウェアの大きさを見積る規模見積りと、規模をベースに作業に要する時間を見積る工数見積りが存在する。これまで当所で実施していた見積り手法は、規模見積りと工数見積りを一括りにしており、大きな問題となっていた。前述の課題も、2.2節(1)は規模見積りに関するもの、2.2節(2)は工数見積りに関するものであることから、この2つの課題を改善することで見積り精度の向上が期待できる。以下で、各々について記載する。3.1要件定義プロセス改良による規模の早期確定アジャイル開発の目的は、価値のあるソフトウェアを早く継続的に提供することにある。そのためには、カーメーカーの要求に応じて、開発途中でも柔軟な仕様変更に対応する必要がある。これを行うには、カーメーカーと一体になり優先順位を相談しながら開発を進めることが重要である。そのためには適切な要件定義と、それに基づく定量的なメトリクス(規模尺度)を導き出し、共有することが重要となる。この目的を実現するために、以下の改善を行った。(1) カーメーカーの要件分析を実施する手法の統一これまで要件分析を行う手法は担当者に一任していたが、抜け漏れが多く粒度も一様ではなかった。また、このような資料をレビューしても十分な成果が得られなかった。そのため、U S D M( U n i v e r s a l S p e c i f i c a t i o nDescribing Manner)(注2)を使用して分析を行うように手法を統一した。このとき、粒度の課題を解決するために、USDMの記載方法に関するガイドラインを作成した。以下にガイドラインのポイントを記載する。⒜ 3.1節(2)で説明する規模メトリクスが定義できるレベルまで細分化すること⒝ 背景をしっかりと記載すること⒞ 同じ階層で分割・詳細化した内容を合わせると、その上の階層に記載した内容(特に背景の内容)が全て実現できていることこの工程においては、カーメーカーの要求を綿密に分析することよりも、他に抜け漏れがないかを確認し全てのタスクを洗い出す(あいまいさをなくす)ことが重要である。(注2 ) 派生開発プロセスにおいて要求を仕様化する方法。73車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善(2) 規模見積りメトリクスの設定次に3.1節(1)で実施した要件定義結果から、カーメーカーと共有できるメトリクスを導き出す必要があった。一般的に、LOC(Lines of Code)・ドキュメントページ数・FP(ファンクションポイント)数といったメトリクスが存在するため、ECU用ソフトウェアの開発特性に合わせて適切な指標を選択する必要があった。表1に検討に使用したメトリクスとその特徴を示す。表1. 代表的なメトリクスとその特徴精度向上にFP数を使用することもあるが、カーメーカーに十分普及している手法ではなく関係者の納得感が得られるまでには至らなかった。また、LOCについてもソフトウェアの内部構造を意識することがないカーメーカーと共有するには扱いにくくハードルが高かった。以上のことから、メトリクスにはドキュメントページ数(具体的には、外部仕様書のページ数)を採用することとした。設計者のスキルによりページ数が増減するという弱点はあるが、アジャイル開発の特徴である変化への対応を重視し、カーメーカーと協調しながら頻繁に優先順位を見直す開発スタイルにおいては、関係者で容易にイメージが共有できるドキュメントページ数が最適な指標であった。(3) 具体的な規模見積りの例前述の3.1節(1)(2)より、規模見積りは以下手順で行うように定めた。⒜ USDMを使用して要求を分解する( 図4参照)⒝ USDMの項目のそれぞれで、外部仕様書の変更ページ数を見積る( 図4参照)⒞ カーメーカーの要求と変更ページ数を記載した資料を作成し、スプリントで実装するボリュームをカーメーカーと調整する( 図5参照)⒟ 上記⒞の調整結果を受けて、最終的なスケジュール(納期)を決定する図4. USDMの一例図5. 調整会で使用する資料の一例3.2 定量的な工数見積り手法の構築(1) 工数見積りモデルの選定2章で述べたとおり、これまでは工数の見積りに類推見積りを使用してきたが、熟練者の経験知が外れることもあり課題となっていた。その一方で、熟練者による経験知も見積りに必要な要素である。一例を挙げると、難易度・変更するモジュールのインタフェースの複雑さ・担当者の熟練度などがあり、これらは定量的に表すには難しいものと言える。これは、ソフトウェアを扱うのは人であり経験知に依存する領域が残るためである。以上のことより、過去の実績値から算出した生産性に対し、熟練者の経験知を用いて補正するハイブリッドの見積り手法が必要との結論に至った。そこで、経験知(勘)を見える化する見積り手法であるCoBRA法をベースに、見積りモデルを構築することとした。CoBRA法は係数モデル見積り手法のひとつで、経験豊富なプロジェクトマネージャ等の見積り熟練者の経験・知識を抽出し、それを変動要因として定義・定量化することで、透明性と説明性が高い見積り(コストマネジメント)を実現する方法である。工数を算出するための演算式を図6に示す。図6. CoBRA法の見積り工数算出式74車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善(注3 ) 2つのデータの直線的な大小関係が一致している程度 (値が大きいほど、相関関係が強い)3.1節で規模を算出できているため、残りの生産性とコスト変動要因(ΣCOi)を求めることでCoBRA法の適用が可能となる。(2) 生産性の算出CoBRA法では、最初にコスト変動要因を定量化し、過去の実績工数を使用して生産性を算出する。   生産性=    実績工数      (1)       規模×(1×ΣCOi)しかし、式(1)では熟練者の設定したコスト変動要因で生産性が変化することになるため、関係者の納得感を得ることができなかった。そのため、以下の式(2)で生産性を算出した後、コスト変動要因を設定するように見直した。コスト変動要因の設定については3.2節(3)で述べる。   生産性=    実績工数      (2)       外部仕様書のページ数式(2)の結果はスプリントの特色に合わせて変わってくるため、プロジェクトで蓄積している過去1年間のデータを回帰分析し、設定することとした。分析した結果を図7に示す。全てのデータを使用した図7の(a)では相関係数(注3)は0.76となり、現時点でもそれなりの相関関係があることが分かる。ここで、回帰式の精度を更に上げるために、スプリントの特色(新規開発の割合が高いスプリントと、流用開発の割合が高いスプリント)で分けることとした。その結果を図7(b)(d)に示す。それぞれ相関係数が、0.89・0.70となり、流用開発の割合が高いスプリント(図7(d))の方がバラつきの大きいことが分かる。次に精度を上げるために外れ値を除外する。直観的に大きく外れているものを除外する方法も考えたが属人性が出るため、平均値から±標準偏差の範囲に収まらない約32%のデータを除外することとした。その結果を図7(c)(e)に示す。相関係数はそれぞれ0.92・0.96となり、かなりの精度を得ることができたため、このときの生産性を採用することとした。(除外したスプリントは単純に生産性のみで見積ることができないため、3.2節(3)で説明するコスト変動要因を使用して吸収する)当所では生産性を2か月ごとに見直している。また、見直しの度に値が大きく変動することを避けるため過去1年間の移動平均を使用することとした。図7. 外部仕様書ページ数と実績工数の相関関係75車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善(3) コスト変動要因の抽出実際のソフトウェア開発は、3.2節(2)で説明した生産性どおりに進むことは少なく、様々な変動要因が存在する。そのため、当プロジェクトに内在する変動要因を整理しリストを作成することとした。CoBRA法ではブレーンストーミングで開発プロジェクトに介在する多種多様な要因を抽出し、変動要因として定義する方法が説明されている。当所では、ブレーンストーミングに加えて見積り誤差率が±25%を超過したスプリントに対し、その理由を蓄積することとした。具体的には、スプリント担当者が工数超過した理由を記載できるよう所内のフォーマットを改訂するとともに、これを変動要因リスト(図8参照)に登録し、積み上げるようプロセス化した。図8. 変動要因リストの例次に、抽出した変動要因から変動要因の定量化(係数化)を行う必要がある。CoBRA法では、熟練者のアンケートを基に係数を設定する方法が説明されている。具体的には、複数の熟練者が影響度合いを最小値・最頻値(最も可能性が高い値)・最大値の3段階で係数化し、この結果を持ち寄って設定するという方法である。当所ではレビューに加えて変動要因リスト(図8参照)に登録した見積り値と実績値のデータを検証することで、係数の妥当性を検証し設定することとした。なお、変動要因の妥当性については、3.2節(2)で述べた生産性を見直すタイミング(2か月ごと)に合わせて検証するようにプロセス化した。(4) 具体的な工数見積りの例3.2節(1)~(3)で述べた見積りを支援するため、工数見積りシートを作成した。(図9参照)図9. 工数見積りシートの例当所における見積りは、このシートを使用しながら以下手順で行うように定めた。⒜ 規模に外部仕様書のページ数を入力する⒝ 変動要因(難易度・モジュールの複雑さなど)に 応じて変動要因の係数を設定する (図9では、見積り担当者が難易度を中としたときの例 を示している)⒞ 生産性・規模・変動要因から、工数を見積る⒟ 工数見積りシートを関係者でレビューする (図9の実例をレビューする場合、難易度を中としたこ  とが適切か、見積り工数の112.5人hrが適切かを関  係者で協議し、関係者の納得感を得ることが目的となる)76車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善4. 改善効果本章では、本稿で述べた改善効果について、定量的な側面と定性的な側面を記載する。4.1 開発規模見積り(1) 定量的効果見積り誤差率が±25%を超えたスプリントの件数を36%削減できた(2) 定性的効果⒜ 規模を早期確定し見える化することで、カーメーカーとの調整が容易になった (カーメーカーの管理職から優れた手法であると評価 された)⒝ 要件定義工程において、担当者による成果物のバラつきが少なくなった⒞ 要件の抜けや漏れに早期に気づけるようになった4.2 工数見積り(1) 定量的効果⒜ 見積り超過工数を40%削減できた⒝ 総見積り誤差率(注4)が35%から23%に改善できた(2) 定性的効果⒜ 見積り根拠を説明しやすくなり、見積りに対する納得感が上がった( 見せる化)⒝ 変動要因リストから、自組織の弱点が見えるようになった5. むすび当所においてアジャイル開発を適用している目的は、変化への対応を重視しカーメーカーと協調しながら価値のあるソフトウェアを早く継続的にリリースすることで、カーメーカーの競争力を引き上げることにある。しかしながら、これまでは変化への対応手法が暗黙的(属人的)・定性的になっていたため、見積り精度が低いばかりか関係者の納得感も高くなかった。本稿で紹介した手法を適用し様々な定量化を行うことでカーメーカーを含む関係者の納得感を上げるとともに、ソフトウェアの見積り精度を向上することができた。以上の取り組みを一言でまとめると、アジャイル開発の特徴である変化への対応を迅速に行うためには、関係者の暗黙知をなるべく早く形式知に変換し、かつ、この変換を何度も素早く繰り返すことが重要ということである。本稿で紹介した手法が暗黙知を形式知化するアプローチのひとつとして参考になれば幸いである。最後に、本活動に当たり多くのご助力をいただいた関係各位に深く感謝申し上げる。特に、三菱電機(株) 姫路製作所 制御機器第一製造部の方々に多大なるご助言を賜ったこと厚く御礼を申し上げる。参考文献(1) CoBRA研究会:CoBRA法入門 - 「勘」を見える化する見積り手法-、株式会社オーム社(2011)(注4 ) 総見積り誤差率= Σ|見積り工数−実績工数|%                Σ 実績工数執筆者紹介繁田 展史 シゲタ ノブフミ2004年入社。主に車載システムのソフトウェア開発に従事。現在、姫路事業所技術第2部技術第2課副課長。77車載制御装置のソフトウェア開発における要件定義プロセス及び見積り手法の改善