Comments
Description
Transcript
コンサルタントが教える成功の秘訣
eXmotion Solution Guide Vol.4 「開発の現地化」が示唆するものとは 今、日本の製造業では「開発の現地化」が加速しています。 これまでは、自動車産業に代表されるように、世界で販売する製品の開発は国内中心でおこなわれ eXmotion Solution Guide るのが一般的でした。しかし、コスト競争力や現地ニーズへの対応などが動機となり、今や、従来のよ うに国内で世界を見て開発する手法から、現地で開発する体制への転換、すなわち「開発の現地化」へ の移行が猛スピードで進んでいます。円高や少子化による国内マーケット縮小という情勢を受けて、こ 2012 の動きは今後もより一層加速しそうな勢いです。 現地での開発と言えば、従来は製造工程が主でした。しかし、今進みつつある動きは、商品企画か らデザイン・設計、そして試作・評価にいたるまで、つまり製品開発の全工程に対する開発委譲です。 もちろん組込みソフトウェア開発も例外ではありません。すでに一般化しているオフショア開発は 開発委譲の一例ですが、こちらは言ってみればソフトウェア開発における製造工程の委譲に過ぎません。 「開発の現地化」が進むことで、ソフトウェアで実現すべき要求や仕様を決めたり、基本的なアーキテ クチャを設計するといったような、従来「聖域」として国内で実施されてきた上流工程についても、海 外への委譲が進んでいくでしょう。そしてその際には、まずは既存のソフトウェアに含まれるさまざま な知見を現地のエンジニアに伝承し、以降はそれをベースに現地で新たな機能を盛り込んでいく、とい う2段階の手順で進められていくことが想定されます。 そうなったとき、真っ先に懸念されるのは、現在のソフトウェアに関する要求や仕様、そして設計 といった上流成果物の曖昧さです。現物を動かしながらボトムアップに作り込むこれまでのやり方では、 成果や知見の多くが暗黙知として放任され、明示的に共有されることはありませんでした。 このようにして作られたソフトウェアの内容を現地エンジニアへ伝承することの困難さは容易に想 像がつきます。かといって、暗黙知を理解している数少ないエンジニアが、毎回現地に赴いて長期にわ たり伝承するのは非現実的です。結果的に「開発の現地化」もソフトウェア開発の局面で大きく暗礁に 乗り上げてしまうでしょう。 これを防ぐためには、まずは既存のソフトウェア資産を紐解き、そこに埋もれている要求や仕様、 そして知見といったものを棚卸しすることです。ソフトウェアに関する暗黙知を無くすことこそが、あ らゆる改善に向けた第一歩につながります。 とはいえ、ボトムアップで開発された上に、暗黙知ベースの追加・修正が繰り返されたことで、も 03 ソリューションガイドブックの歩き方 05 モデルベース開発（オートモーティブソリューション） 13 要求の定義と仕様化 09 17 21 23 27 31 機能安全ソリューション 既存資産の解説書 プロダクトライン開発 XDDP による派生開発 レガシーリファクタリング モデルベース開発（UML＋オブジェクト指向） 33 34 イージーオーダートレーニング 品質診断ツール eXquto 35 お客様からのメッセージ 37 About us コンサルタント紹介＆会社案内 はや開発者の手に負えないモンスターとなってしまったソフトウェアに向き合うことは、正直、大変な 労力を伴いますし、素手で挑むのは危険な作業です。 今回のガイドブックでは、この大変な作業に直接役立つ実践的技術を集めてみました。いずれの技 術も私たちがこれまで現場で実践してきて、その効果を確信しているものばかりです。組込みソフト ウェアの暗黙知をなくし、さらなる改善を行うために、ぜひ参考にしていただければ幸いです。 本文書に記載された文章、画像、及びその他のコンテンツを許可なく複製、転載、引用する事を禁じます。 Copyright (c ) 2012 eXmotion Co., Ltd. All rights reserved. MATLAB 及び Simulink は The MathWorks, Inc. の登録商標です。 その他記載されている会社名、システム名、製品名は一般に各社の商標または登録商標です。 なお、本文および図表中、 「™」 、 「® 」は明記しておりません。 CONTENTS 2012年5月 株式会社エクスモーション 社員一同 1 2 eXmotion Solution Guide Vol.4 ソリュー ション ガ イドブック の 下流工程の秩序化で 着実に品質を高める き方 あなたの組織はどこにいますか？『開発力』チェック！ 開 発 現 場 の 状 況 改善の キーワード このソリューションガイドブックは、組込みソフトウェアの開発現場で起こって いる問題を解決するための ソリューション を集めたものです。 一口に 組込みソフトウェア開発の問題 といっても、対象としている製品や現場 の状況、開発者のスキル、外部環境など、さまざまな側面を持っているため、すべ てを解決できる 万能ソリューション などはなく、個々の問題に適したものを選ぶ 必要があります。 まずは、以下のYes-Noチャートを使って、皆さんの組織の「開発力」がどのよう な状態かを確認してみましょう。簡単な質問に答えるだけで、どの状態にいるのか が分かります。 そして状態がわかったら、右の図から皆さんの状態に最適なソリューションを探 してください。 混 沌 成熟 改革 Yes 改善 No 混沌 3 おススメソリューション 展開 技 術 共通化されたルー ルがほとんど存在 せず、混沌とした 無秩序状態です。 多忙ゆえに、混沌 から脱却するため の検討にも時間が 割けず、さらに多 忙さを増すという 悪循環が起きてい ます。 秩序の導入 コード改善 モレ・ミス・ムダ の排除 ︵ 業 自 界 動 特 車 化 ︶ 改 革 改 善 既存資産を使って、 無理・無駄のない 開発を実現 設計の可視化で、 上流工程の 品質向上を実現 同系列での 生産性の高い 開発を実現 肥大化し、複雑度 を増していくソフ トウェアに対し、 抜本的な改善を施 すのはリスクと考 え、下流工程を中 心に徐々に秩序化 を図る活動を実施 しています。 ソフトウェア構造 の抜本的な見直し を決意し、開発の 上流工程から大々 的なリフォームを 行った状態です。 ソフトウェア構造 の可視化による生 産性・品質の向上 が出始めている状 態です。 ソフトウェア構造 の改革に成功し、 新たな開発スタイ ルが定着していま す。改革の恩恵を 享受し、同系列に おいて高い品質と 生産性を実現して いる状態です。 秩序の定着 設計改善 モデリング 差分開発 アーキテクチャ 構築 要求の定義と仕様化 p17 既存資産の解説書 レガシーリファクタリング p31 多系列にわたる 生産性の高い 開発文化の定着 展開で実践された 取り組みが多系列 に適応され、組織 全体が大規模・短 納期の開発におい ても、人に依存せ ず、高い品質と生 産性を維持した開 発が行える、いわ ゆる最終ゴールと なる状態です。 知識の共有化 部品化再利用 モデルベース開発 （UML＋オブジェクト指向） p21 p23 成 熟 展 開 p13 p27 プ ロ セ ス 同系列の開発生産性 向上を目指す 上流工程からの 見直しで更なる 品質向上に着手 多系列の開発生産性 向上を目指す プロダクトライン開発 XDDPによる派生開発 p5 p9 モデルベース開発 （オートモーティブソリューション） 機能安全ソリューション 4 モデルベース開発 オートモーティブソリューション 車載ソフトの開発現場は、ハイブリッド化・EV化などのような新たなパワートレ インへの転換や、ISO 26262 の規格化など、大きな変化を迎えています。 これを受け、MATLAB / Simulinkによるモデルベース開発の導入など、生産性と品 質を向上させる取組みが進みつつあり、大きな成果を発揮しています。 モデルベース開発を導入することで得られるメリットは大きいが… 今、車載ソフトの開発現場では、 MATLAB/ Simulink によるモデルベース開発（以下、 MBD）が急速に普及しつつあります。その主な理由 は、MBDを導入することで、従来開発に比べて、生 産性と品質へのメリットが得られる点にあります。 たとえば、MBDで使用されるツールである、 MATLAB/ Simulink には、数多くの部品が用意され ており、これらをつなぐことで簡単にモデルを作る ことができます。作ったモデルは、すぐその場で動 きを確認できるため、モデルで記述した制御仕様の 検証が容易になり、早期の品質確保が可能となりま す。 更に、作ったモデルをそのまま実車に持ち込んで 動作検証を行ったり、モデルからオートコード（自 動コード生成）することにより実装工数を大幅に削 減するなど、MBDの導入により多くのメリットを享 受することができます。 MATLAB/Simulinkでカバーできるのは、「ソフトウェア詳細設計」以降 MATLAB/ Simulink で作成するのは、実装を前提 とした制御モデルです。一般的なV字プロセスに当 てはめると、「ソフトウェア詳細設計」で作られる モデルに相当します。そのため、それよりも前の段 階で混入した問題については、何の手当てもできま せん。 例えば、要求の段階でどんな問題が混入されてい ようと、それに応じたモデルを作成することしかで きません。要求のヌケモレや矛盾、誤解釈があった 場合、それをそのまま引き継いだモデルが作られま す。 また、Simulink モデルは、先行開発においては、 制御仕様の正しさを確認するために効力を発揮しま す。しかし、「動かすこと」を重視して作られてい るために、それまでの開発の経緯が残っていなかっ たり、モデルの構造については、あまり注意を向け られていないようなケースもあります。 このようなモデルは、量産開発にそれを引き渡し ても、モデルの意図が み取れず、理解するのが困 難なため、以降の機能追加や派生開発まで考慮する と、保守性の面で大きな問題となりえます。 eXmotion Solution Guide Vol.4 MATLAB/Simulinkモデルの品質向上には、上流工程での検討が有効 これまで述べてきたように、これからは単に動く だけでなく、要求に則り、開発者にとって分かりや すいモデルを作ることが重要になってきます。 このような品質の高い MATLAB/ Simulink モデ ルを開発するためには、下図にあるV字モデルの上 流工程における「ソフトウェア要求定義」と「ソフ トウェアアーキテクチャ設計」の2つの活動が重要 になります。さらに、 MATLAB/ Simulink モデルを 作成する「ソフトウェア詳細設計」においてもモデ ルを分かりやすくするための活動が可能です。 また、これら３つの活動には、その段階に応じて 早期に検証を行う事も有効です。 「要求定義」でモデルが満たすべき 「要求」 「品質」 「制約」 を明らかにする Simulink モデルの保守性を低下させる一因として、 「目的」「要求」「仕様（手段）」に分けて段階的 「要求」が暗黙知であることがあげられます。 に詳細化しながら形式化することが有効です。階層 この状況で開発されたモデルには「仕様」のみが 化により、モデルの目的や意図は「要求」を、設計 書かれており、機能要求や品質要求、設計制約など 方針は「仕様」をそれぞれ参照すればよくなり、モ デルの可読性が格段に向上します。詳細は、P13 に が十分に反映されません。 これを解決するためには、既存の「制御仕様」を ある「要求の定義と仕様化」をご覧ください。 MATLAB/Simulinkだけではカバーしきれない範囲 システム ソフトウェア 総合・結合テスト ソフトウェア 要求定義 要求検証 ソフトウェア アーキテクチャ設計 ソフトウェア 詳細設計 ソフトウェア 実装 ソフトウェア アーキテクチャ検証 ソフトウェア 単体検証 ソフトウェア ソフトウェア 総合テスト ソフトウェア 結合テスト ソフトウェア 単体テスト 実装検証 マイコン 実装 コンサルタントが教える成功の秘訣 ソフトウェアの設計手法には、オブジェクト指向だけでなく構造化設計など の手法も存在します。また、モデリング言語( 表記方法) を考えても、一般的な フローチャート/状態遷移表/UML/ SysML、ツール独自のSimulink/SCADE 、車 両制御固有のAUTOSAR/EAST -ADLなど、十分すぎるほど存在します。世間の 動向やツールに翻弄され、導入以前より開発効率が低下した経験をお持ちの方 もいらっしゃるのではないでしょうか。 開発対象や現場の置かれた状況により、「どの設計手法・モデリング言語を 採用すべきか」の共通解は残念ながら存在しませんが、分かりやすくメンテナ ンスしやすい、バグのないソフトウェアを早く作るという目的は変わりません。 エクスモーションは、お客様の状況や抱える課題を把握し、数多くの選択肢 の中から、最適なソリューションを提案し、実践しています。 5 シニアコンサルタント 三輪 有史 6 モデルベース開発 オートモーティブソリューション eXmotion Solution Guide Vol.4 「アーキテクチャ設計」のポイントは「レイヤ」と「ドメイン」による分割 要素技術調査に心血を注ぎ、手段レベルのまま放置 さらにドライバの運転機能に応じて、機能レイヤ されたモデルは、情報をまとめきれず、全体的に抽象度 には「判断」、手段レイヤには「認知」と「操作」、 が低いため、下図左側のモデルのように要素間の入出 そして部品レイヤには「デバイス」といった「ドメ 力関係が複雑で、処理の複雑化を招きやすくなります。 イン」を割り当てることで、互いに疎な構造からな これに対し、 うまくアーキテクチャを設計できると、 るモデルを構築することが可能になります。 また、メトリクスは、ISO26262 の要求事項に対 して 、 詳細設計で求められる、簡潔性、可読性や 分かりやすさ、堅牢性、修正のしやすさ、試験性等 の品質改善にも利用できます。 弊社では、 MATLAB/ Simulink モデルのメトリク ス測定ツールを提供しています。詳細は、34ページ をご覧ください。 下図右側のモデルのように要素間の入出力が簡潔で、 なお、開発対象の規模、最適な設計手法、開発者 処理も簡潔になり、各要素の役割も明確で、理解しやす のスキル等に応じて、他のモデリング言語の併用も く変更しやすいといったメリットが得られます。 有効です。たとえば、「レイヤ」や「ドメイン」と アーキテクチャ設計のポイントは、「レイヤ」と いったレベルでの設計には、UMLの活用が効果的で す（31ページの「モデルベース開発（UML＋オブ 「ドメイン」による分割がカギになります。 ジェクト指向）」をご覧ください）。 車両制御ソフトウェアは、抽象度に応じて機能／ 手段／部品の３つの「レイヤ」に分割できます。 「単体検証」は、シミュレーション検証の自動化がカギ MBDでは、ツール等を使った検証手段は充実し ているのですが、それらを場当たり的に使っている だけでは十分な成果物が残りません。また、テスト ベクタや報告書をその都度つくるのも非効率的で、 ヌケモレも発生しやすくなります。 これらの問題は、MATLAB/ Simulink やカバレッ ジ計測ツールなどと連携する自動化ツールを導入す ることで解決できます。テスト仕様書やテストハー ネス、テスト結果報告書などの自動生成が可能にな ることで、再帰テストが楽になり、十分なエビデン スを残すことができます。また、テスト仕様書の入 力に要求仕様書を利用することで、ISO26262 で重 視される要求と実装のトレーサビリティも満たすこ とが出来ます。 カバレッジ測定 → テスト結果報告書作成 「詳細設計」では、モデルメトリクスを活用 「ソフトウェア詳細設計」はMATLAB/ Simulink モデルを開発する工程にあたります。ここで有効に なるのがモデルのメトリクスです。基本的な考え方 はコードメトリクスと同じで、ソースコードではな くモデルを静的に解析し、定量的な値を測定します。 具体的には、サブシステム内のブロック数、サブシ ステム内の処理の複雑度を計測した経路複雑度、伝 播信号の表示率、コメント率などがあります。 メトリクスはソフトウェアの品質と密接な関連性 を持つため、メトリクス値を評価することで、品質 7 上の問題が特定可能になります（次ページ上図）。 このように開発したモデルに対し、定期的にメト リクスを測定することにより、 ・品質改善（問題箇所の特定） ・品質のモニタリング（品質劣化防止、改善効果の 可視化） ・品質のベンチマーキング（品質基準の策定、複数 モデルの品質を比較 ） などを通じて、モデルの品質向上に向けた活動を行 うことができます。 エクスモーションが提供するサービス モデルベース開発 実践型支援＆スキル アップ支援 モデルベース開発の品質向上のカギとなる「ソフトウェア要求定義」と 「ソフトウェアアーキテクチャ設計」を短期間で実践するために、コンサ ルタントが直接お客様の開発現場にお伺いし、実際の製品開発に適用する ことで、着実に成果を残す実践的な支援を行っています。実際の成果物を お手本にしたスキルアップを同時に行うと、さらに効果的です。 Simulinkモデルの シミュレーション検証 MATLAB/Simulink やカバレッジ測定ツールなどと連携する自動化ツールを 導入し、シミュレーション検証をより楽に開発に取り入れるお手伝いをし ます。 Simulinkモデル リファクタリング支援 保守性が下がったSimulink モデルの問題点を明らかにし、品質改善を目的 としたリファクタリング（設計改善）の計画作成と実施、評価までを一括 してお手伝いします。 www.exmotion.co.jp/ [email protected] ☎ 03-6722-5067 8 例えば、システムを構成する部品に故障が発生し た場合でもそれを検出して危害を回避、軽減するた めの工夫を導入することで安全を確保できます。 ISO 26262 は自動車分野向けに策定された機能 (Part 5) (Part 6) ハードウェア開発 ソフトウェア開発 (Part 4 9 節) 安全妥当性確認 (Part 7 6 節) 運用計画 (Part 7 5 節) 生産計画 安全規格で、自動車の電気/電子システムにどのよ うな安全機能を組み込むか、その安全機能を実現す るためにどのような手順で開発や管理を行うべきか を体系化したものになっています。 つまり、自社の製品が安全面が十分に考慮して開 発されたことを示したり、組織が機能安全を考慮し た開発が行える能力があることを示すためのガイド ラインとして使用できる規格であると言えます。 （１）製品に関する安全のコンセプトを決める （２）プロセスを定義しそれに従った開発を行う （３）開発時のミスを防止する成果物を作る （４）安全性を示すために成果物を管理する コンサルタントが教える成功の秘訣 (Part 4 10 節) 機能安全アセスメント (Part 4 11 節) 製品リリース (Part 7 6 節) 運用、保守、廃棄 （１）製品に関する安全のコンセプトを決める ■コンセプトフェーズで行うこと 上で、危険な事象や安全を確保するための方針を検 討することになります。例えば「アクセルポジショ ISO 26262 Part 3 のコンセプトフェーズでは、 対象の製品を理解し、製品のハザードの識別や発生 ンセンサの入力信号が実際よりも大きい値になる」 しうる危害を検討、安全を確保するための方針を決 と考えるのではなく「ドライバ要求加速度を実際よ りも大きく認識する」というように考えることで、 定するといったことを行います。 この段階では製品のアーキテクチャや詳細設計が アクセルペダルによって要求される加速だけでなく、 決まっていないため、個々の部品の故障や、安全を クルーズコントロール時のようにアクセルペダルを 確保する技術といった具体的なことは考慮せず、あ 操作しない場合の加速についても包括的に検討でき くまで車両レベルの挙動を検討する必要があります。 るようになります。 しかし、ものごとを具現化する設計・実装のよう ■抽象的な思考が求められる な作業に慣れている人は、抽象的に思考することが つまり、コンセプトフェーズでは、製品の構成要 苦手な場合があるので、抽象的にものごとを捉える 素や製品に発生する故障を論理的、抽象的に捉えた ための訓練が必要になってきます。 コンサルタントが教える成功の秘訣 機能安全というと、特別厳密な作り方や基準が求められているように思われ る方も多いのではないでしょうか。しかし、実際には、設計根拠の論理的な説 明が必要だったり、トレーサビリティをきちんと取ったりなど、一般の開発に おいても要求されていることが多くあります。このような基本的なことをきち んと実施することは、組織あるいは個人のスキルアップの機会になる、と前向 きに捉えて、チャレンジしていただきたいと思っています。 エクスモーションでは、これまでさまざまな技術の導入と支援を実施してき ました。その中で、機能安全にも生かせる実践的なノウハウを数多く持ってい ます。また、現場ごとの状況に合わせた提案も得意としております。ぜひ、私 たちにお任せください。 コンセプトフェーズ (Part 4) システム開発 (Part 8) 支援プロセス （３）開発時のミスを防止する 成果物を作る (Part 7 5 節) 生産 に従って開発を行う場合にすべきこと ISO 26262 では、自動車向けの製品に対して機 能安全を実現するための活動の流れを全安全ライフ サイクルとして示しています（次ページの図を参 照）。全安全ライフサイクルで示されている活動を 行うために開発組織が実施すべきことを大きくまと めると次の4つになります。 9 (Part 3 7 節) ハザード分析とリスクアセスメント とは？ 安全とは、製品が使用される環境において許容で きない危害を発生させるリスクがない状態のことで すが、機能安全とは機能的な工夫を付加することに よってこの安全を確保することをいいます。 ISO 26262 (Part 3 5 節) アイテム定義 (Part 3 6 節) 安全ライフサイクルの開始 (Part 3 8 節) 機能安全コンセプト 自動車の電気/電子システムを対象とした機能安全規格ISO 26262 のPart 1 から Part 9 が2011 年11月に正式に発行されました。安全性のための設計技術が重要に なるのはもちろん、上流から下流まできちんと正しいプロセスで安全に作られたも のであることを説明できる技術も必要になります。 機能安全とは？ISO 26262 （１）製品に関する安全の コンセプトを決める (Part 2 5 節∼7節) 機能安全の管理 製品開発 ∼ISO26262への対応∼ （２）プロセスを定義し （４）安全性を示すために それに従った開発を行う 成果物を管理する 製品 リリース後 機能安全ソリューション eXmotion Solution Guide Vol.4 ISO 26262 に従った開発を行おうとした場合、論理的に妥当な検討結果を導 くために、例えば、ハザード分析をHAZOPなどの手法を用いて実施するなど、 今まで行ったことのない技術を導入する必要が出てくる場合があります。 しかしいざ導入しようとした場合、どのように行えばよいか、どのくらい時 間をかけ、どのくらい詳細に行えばよいか戸惑うことが多いと思います。 コンサルタント 小坂 優 エクスモーションは、難しい技術をそのままお客様にお渡しするのでなく、 実用的な技術と組み合わせたり、我々の中でひと手間かけることにより、簡単 に導入していただけるよう工夫することをモットーとしています。 ISO 26262 への対応だけでなく、様々なシーンで新たな技術の導入が必要な 場合は、ぜひ私たちにご相談ください。 シニアスペシャリスト 藤倉 俊幸 10 機能安全ソリューション eXmotion Solution Guide Vol.4 ■ソフトウェアアーキテクチャ設計 （２）プロセスを定義しそれに従った開発を行う ■トップダウンのアプローチになる 他者に対して、安全面を十分に考慮して開発した ことを示したり、その組織が機能安全を考慮した開 発を行える能力があることを示したりするためには、 その根拠を論理的に説明できる必要があります。そ のため、ISO 26262 でも上流工程で決めた安全要求 を設計、実装まで落としていくというトップダウン での開発方法が規定されています。 一方、開発現場では、具体的な仕様を検討する中 で安全機能を検討していくようなすり合わせ型の開 発が行われている場合が多く、上流工程の成果物を 作成できていないために、安全性の根拠を十分に示 せないことが懸念されます。 ■組織に合った開発プロセスを定義する ISO 26262 では、Part 4 からPart 6 でシステム開 発、ハードウェア開発、ソフトウェア開発で実施す べきことが規定されており、Part 8 で構成管理や変 更管理、検証といった支援系のプロセスに関するこ とが規定されています。 しかし、ただ規格に規定された内容に合わせてプ ロセスを定義すればよいわけではなく、そのプロセ スに従うことで開発がより良くなることが大事です。 また、ISO 26262 に従うために既存の開発方法を大 きく変えてしまいたくなるかもしれませんが、それ では開発が回らなくなってしまうため、既存の開発 方法で良い部分はそのまま流用し、不足している点 や改善の必要な作業を検討することが賢明です。 ■プロセスに従った開発を行うには 開発プロセスは開発者が行うべき作業の手順を表 したものですので、自分が行うべき作業をどのよう に行うかを理解するためにも開発者自身で考えるべ きです。自分で決めた開発プロセスなら、その作業 の意図や目的を理解しているため、そのプロセスに 問題点があることが分かれば継続的に改善すること ができ、形骸化しにくくなります。 また、プロセス検討の専任チームが開発組織の標 準プロセスを定義する場合であってでも、対象のプ ロジェクトに合うように標準プロセスを修正（テー ラリング）するのは作業を担当する開発者自身が行 う方が、プロセスに対する理解が深まり、プロセス に沿った開発も行いやすくなります。 既存のプロセス ISO26262対応プロセス FMEA実施 3-5 アイテム 定義 安全面の対策内 容の決定 • どこが違うか？ • 流用できる成果物は？ • どのように移行すべきか？ 3-7 ハザード 分析とリスク アセスメント アーキテクチャ設計では、ソフトウェアコンポー ネントの凝集度や結合度といった一般的なソフトウ ェアの設計品質が重視されます。これを実現するた めには、UMLのようなモデリング技術も有効な解の ひとつです。 ■ソフトウェア詳細設計 最近ではMATLAB/ Simulink を活用したモデル ベース開発が行われることも多くなってきています が、Simulink モデルに関しても、品質を意識して開 発することで、保守しやすいものにすることが今後 の開発効率を上げるためには重要です。 P5 の「オートモーティブソリューション」の記事 詳細設計に関しても P5 の「オートモーティブソ にもアーキテクチャ設計のポイントが書かれていま リューション」の記事にポイントが書かれています。 すのでご参照ください。 （４）安全性を示すために成果物を管理する ■安全が実現されているか検証する 安全に関する要求が正しく実現されているかを確 認するためには、設計レビューや開発されたシステ ムのテストを行う必要があります。品質を確保する ためには充分なレビューやテストを実施しなければ なりませんが、非常に多くの工数がかかってしまう ので効率よく行える仕組みが必要になります。 ソースコードに対するテストは既存のテストツー ルを用いて自動化することができます。また、モデ ルベース開発の場合でもシミュレーション検証を自 動化するツールを導入することで、テストを効率化 することができます。 成果物のトレーサビリティ ハザード 製品が安全であることを示すためには、決定した 安全に関する方針が製品の設計、実装に正しく反映 されている必要があります。しかし、これを確認す るためには成果物のトレーサビリティを確保できる ように、要求管理ツールや設計のモデリングツール、 構成管理ツールなど開発のライフサイクルを管理す るためのツールが必須であると言われています。 ただし、ツールをそのまま導入するだけでは、定 義した開発プロセスに合わない部分も多く、思った ような効果が得られないので、開発プロセスに合う ようにツールをカスタマイズすることを検討しなけ ればなりません。 機能安全要求 安全ゴール 意図せず 加速する ■トレーサビリティが重視される 意図せず加 速しないよ うにする 意図せず加速する原因とな る故障を検出した場合、 モータを停止し、エンジン だけで走行する 技術安全要求 電流センサを2つ設置する ２つの電流センサの値を比較 し、値が大きく異なる場合は 異常が発生しているとする。 ・・・ 3-8 機能安全 コンセプト レビュー （３）開発時のミスを防止する成果物を作る ■成果物の品質を向上する機会と捉える 規格では成果物に含むべき情報や品質に関する規 定が記載されています。ソフトウェア開発に限って もソフトウェア要求仕様書やソフトウェアアーキテ クチャ設計書など様々な成果物を作成しなければなり ません。 しかし、規格に書かれているから作らなければ ならないというスタンスではなく、開発の質を高めた り手戻りを減らしたりするためにはどのような成果 物を作るべきか、という観点を持つことが必要です。 11 ここでは、ソフトウェア開発における成果物の品 質を向上するための情報をいくつかご紹介します。 ■ソフトウェア要求仕様書 要求を正しく把握して定義するには、USDMのよう に要求を階層化して表現する手法が有効です。階層 的に定義することが、成果物間のトレーサビリティ 確保の最初のステップとなります。 要求や仕様をどのように定義すればよいかは P13 の「要求の定義と仕様化」の記事をご参照ください。 エクスモーションが提供するサービス コンセプトフェーズ 検討支援サービス アイテム定義書の作成やハザード分析の実施、機能安全コンセプトの成果 物の作成などのコンセプトフェーズの作業をお客様と一緒に行いながら、 コンセプトフェーズで必要とされる技術、手法の導入をご支援します。 開発プロセス導入 支援サービス お客様の組織構造や既存の開発プロセスを考慮し、ISO 26262 のPart 3 ∼ Part 6 を実施する開発プロセスをどのようにすればよいかをご提案します。 成果物作成サービス 要求仕様書の作成や設計書、テスト仕様書など、ISO 26262 に準拠するた めに必要となる成果物を作成します。 ALMツール カスタマイズサービス 要求仕様書やSimulink モデルといった開発成果物のトレーサビリティの確 保や、変更管理、構成管理などを実施するために、PTC社のIntegrity など のALMツールをお客様の環境に合わせてカスタマイズします。 www.exmotion.co.jp/ [email protected] ☎ 03-6722-5067 12 eXmotion Solution Guide Vol.4 要求の定義と仕様化 ソフトウェア開発の最上流工程である要求定義で誤りがあると、いくらその後の 設計が正しく行われたとしても、やり直しが必要となります。一般的に、不具合の 発見が遅れるほど、それを解決するための工数が多く発生すると言われ、上流での 問題を早く解決することが、生産性を上げるための重要なポイントと言えます。 開発現場には 要求 はなく、製品スペック か 制御方法や機能の仕様 しかない 一般的な組込みソフトウェアの開発現場では、要 求と言われるものはほとんど記述されていません。 あるものと言えば、製品スペックか、タイミング チャートなどの制御に関する細かな仕様や機能の仕 様を記載したものだけです。そのため、その仕様が どのような要求に対応したものなのか、仕様にヌケ モレがないかが判断できません。その結果、仕様の 不備がソフトウェアに不具合として混入してしまい ます。 その実態を示しているのが、経済産業省の主導で 実施されている「組込みソフトウェア産業実態調 査」です。2010年度の組込みソフトウェア産業実 態調査報告書では、ソフトウェア開発の中で発生し た不具合のうち53％は設計以前の工程（システム要 できます。ここで、仕様の作成は設計工程の作業だ と考える方もいるかもしれません。しかし、本来な ら設計は仕様が決まっていなければ開始できないは ずです。なぜなら、仕様とは要求を実現するための 13 ■ボトムアップから要求を作り出す 一般的な要求抽出のやり方としては、利害関係者 へのインタビューや自社製品や競合他社の製品調査 などが挙げられます。このようなやり方は 要求の 源泉 からたどっていくという意味でトップダウン と呼ばれます。しかし、この方法では あるべき姿 を一からあぶり出すことができる反面、今ある仕様 を網羅することに対しては不安が残ります。 詳細な仕様がすでにある場合には、ボトムアップ からスタートする方法も有効です。詳細な仕様から ：トップダウンの流れ ：ボトムアップの流れ なぜ組込みソフトウェアの開発現場では要求が記 述されないのでしょうか？それは組込みソフトウェ アの開発では量産開発の前に先行開発や要素技術開 発が行われることが多く、そこで決められた仕様や 成果物を基に量産開発が行われるためです。また、 量産開発でも設計、実装を行いながら仕様を決めて いくといったやり方で開発が進むため、ソフトウェ アを統合してテストするまで仕様の矛盾やヌケモレ が発見されないという問題も発生します。 先ほどの組込みソフトウェア産業実態調査報告書 でも、不具合の62%が実装以降で発見されるという 結果が出ています。 システムの具体的な動きや制限を表したもので、設 計とはその仕様をどのような構成で実現するか、そ れらの構成要素がどのような役割をもち、構成要素 間でどのような相互作用をするかを検討する工程だ からです。 また、ソフトウェアコンポーネント設計の工程に 入るとコンポーネントごとに担当者や部署が分かれ ている場合も多いため、各担当者がコンポーネント の設計を行いながら仕様を決めてしまうと、ひとつ の機能の実現に関係する複数のコンポーネント担当 者の間で、コミュニケーションミスが発生しやすく なり、それが不具合につながってしまいます。 マインドマップなどの情報を整理する手法を使って 仕様の背景にある要求を抽出していきます。 もし、仕様が書かれていない場合は既存資産から 仕様を起こす作業を行います。詳しくは P23 の 「 XDDPによる派生開発」をご参照ください。 抽出した要求を基に既存システムや先行開発の担 当者にヒアリングし、抽出した要求が正しいか、他 に隠れた要求が無いかを確認します。 要求 チャタリング するから 求∼詳細設計）で混入した不具合であることを示し ています。 先行開発や要素技術開発の仕様から要求を抽出する 仕様の目的や意図を明確にしたり、仕様の矛盾や ヌケモレを発見するためには、先行開発や要素技術 開発の仕様を量産開発でそのまま使うのではなく、 量産開発で対応すべき項目も加味した上で要求を抽 出・定義し、それらと先行開発や要素技術開発の仕 様を基に、改めて量産開発のための仕様を検討して いく必要があります。 また、設計、実装を開始する前に仕様を充分検討し、 この段階で仕様を決定してしまうことで、仕様の矛 盾やヌケモレによる手戻りを最低限に抑えることが 要求を抽出するにはどうしたらよいか？ 仕様 整理が ポイント 要求確認 資料 ( ﾏｲﾝﾄﾞﾏｯﾌﾟ等) ■品質要求の重要性 制御仕様や機能仕様には、システムのふるまいに 関することや設計制約などは記載されていますが、 品質に関する要求は記載されていません。しかし、 品質要求はその製品に対してユーザが持つ印象に大 きな影響を与えるので、よい製品を開発する上で品 質要求を把握することはとても重要なことです。 品質要求には使いやすさなどの製品のユーザに関 係する品質と、保守性などの開発者に関係する品質 があります。ユーザに関係する品質は営業からの要 望やユーザクレームが関係するため重視されやすい のですが、開発者に関係する品質は見落とされがち 既存の 仕様 チャタリングの影響を考慮し、 ON/OFF スイッチが押下され たことを判定する。 スイッチ 信号 50ms 押下判定 です。しかし、開発者に関係する品質要求は、開発 の効率や工数に大きな影響を与え、最終的にはコス トやリリースに影響を及ぼすので、これらの要求も 忘れずに定義しなければなりません。 機能性 信頼性 品質特性 (ISO/IEC 9126) 使用性 ユーザ視点 の品質 効率性 保守性 移植性 開発者視点 の品質 コンサルタントが教える成功の秘訣 私が関与した開発現場では、開発のインプットとして具体的な制御方法につ いて細かく記載したものしかありませんでした。そのため、仕様の妥当性が分 からず、今の設計構造にも問題があるのではないかという不安を抱えていまし た。そこで、細かい制御仕様を抽象化して要求を出し、その要求をブレークダ ウンする形で仕様を定義するようにすることで、要求を満足するのに十分な仕 様であることを把握でき、設計構造を見直すこともできるようになりました。 良い要求仕様を作るためには、 要求 と 仕様 を切り離す必要があります。 そのためには、制御仕様を抽象化して要求を得ることが必要です。しかし、長 年細かな制御仕様に慣れている開発者の方には抽象化が難しいようです。その 分野こそエクスモーションの強みです。ぜひ、お任せください。 コンサルタント 高橋 久憲 14 要求の定義と仕様化 eXmotion Solution Guide Vol.4 要求を仕様化するにはどうしたらいいか？ ■仕様は開発者への作業指示 ＜クルコンの始動＞ 要求 下図はクルーズコントロールシステムの要求と仕 様の例を表したものです。システムの「目標スロッ トル開度を算出」という要求の具体的な実現方法と して、「目標加減速度と実スロットル開度を用いて 2次元テーブルから目標スロットル開度を決定す る」という仕様を導出しています。 下位要求 メインSWが押されたらその時 点の走行速度で定速走行を行う 仕様 メインSWが押されたことを 認識する 現在の速度を取得し、範囲内で あれば希望速度として設定する 希望速度から目標スロットル開 度を算出、その値になるように モータを駆動する ▲▼SWが押されたら、 定速走行の速度を調整する 対象が提供すべき 機能・サービスの概要 機能・サービスを実現するため に必要な振舞いの記述 ■仕様のヌケモレを防ぐには 要求を基にして仕様を作成しても、ただ思いつい た仕様を書いていくというやり方では仕様のヌケモ レを防ぐことはできません。 作成した仕様をレビューすることでヌケモレを検 出する方法も有効ですが、レビューは多くの工数を 必要とする手法であり、レビューだけでヌケモレを 防止するのでは効率的とはいえません。 仕様を作成する段階でヌケモレを防止する仕組み を導入すれば、最初から品質の高い仕様を作成する ことができ、レビュー工数も削減することができま 観点 現在の速度と希望速度の差を算 出して、その値から目標加減速 度を決定する 目標加減速度と実スロットル開 度を用いて2次元テーブルから 目標スロットル開度を決定する ・・・ 振舞いを実装する際の 作り方の指示 す。 ヌケモレを防止する仕組みとしては、時系列分割、 構成分割、状態分割、共通分割という思考のフレー ムワークを用いることが有効です。これは、要求か ら仕様を導出する過程で、例えば「構成の視点で要 求を分割するとどのような仕様が導出できるか？」 と考えることで、適切な仕様を導出する手法です。 説明 時間的な順序を持たない「機能」や「構成」に着目して仕様を導出する 状態分割 すでに見えている「状態」に着目して仕様を導出する 共通分割 時間軸に沿った動作・処理に着目して仕様を導出する 複数の要求や仕様に共通する部分を切り出す 要求と仕様をUSDM で階層化して表現する 要求を抽出したり要求から仕様を導出したりして も、それらを適切にまとめることができなければ、 開発に有効な成果物にはなりません。 適切に要求と仕様をまとめ上げる方法のひとつに USDMという方法があります。USDMは主に自然言 語を用いて要求と仕様を階層化して整理するのが特 徴です。派生開発プロセスの XDDPでも変更要求仕 様の記述方法として採用されています。 15 クルコンを使わない状況では、動作しないように機能をOFFできるようにする必要がある。 クルコン用のON/OFFスイッチはハンドルに付いており、ドライバが運転しながら操作することができる。 ＜ON/OFFスイッチの押下判定＞ 要求 ACC.01.01.01 スイッチのチャタリングの影響を考慮し、ON/OFFスイッチが押下されたことを判定する。 説明 チャタリングとは、スイッチが押されたときに発生する微細な機械的振動によって、電気信号のオン/オフが細かく切り替わる現象のこと。 理由 ＜押下判定＞ 要求と仕様を対応付けることで、その仕様がどの 要求を実現するためのものなのか、全ての要求がヌ ケモレなく仕様まで具現化されているかを確認する ことができます。 また、USDMでは機能仕様や制御仕様では扱わな い保守性などの品質要求も記述することができるた め、開発者への「設計方法に関する作業指示」も要 求仕様書に含めることができます。 チャタリングによって誤判定しないようにするため。 SP.ACC.001.01 ON/OFFスイッチの信号が「オン」である状態が50[ms]以上継続した後に「オフ」に変化した場合、ON/OFFスイッチ押下判定を「オン」にする。 SP.ACC.001.02 ON/OFFスイッチの信号が「オフ」であるか、「オン」が50[ms]以上継続しないで「オフ」に変化した場合は、ON/OFFスイッチ押下判定を「オフ」 にする。 要求の定義と仕様化が特に必要なケース 要求の定義と仕様化はどんな時も重要な工程です が、特に必要性の高いケースを３つご紹介します。 まず、開発対象の製品が派生開発である場合が挙 げられます。派生開発では変更管理のプロセスをう まく回すことが大切ですが、USDMを用いて変更要 求仕様書を作成することで、変更の実施前にどのよ うに変更するかを明確にでき、間違った方法で変更 することを防げます。 次に、既存のソフトウェアのリファクタリングを 行う場合が挙げられます。リファクタリングでは、 実施前と後でソフトウェアの振る舞いが変わってい クルコンユニット ないことを確認するために元の仕様を明文化しなけ ればなりません。そこでUSDMを活用できます。 最後に、機能安全に対応する場合です。その際に も、要求仕様とシステム要素との対応付けが求めら れるので、予め要求仕様を明確にしておく必要があ ります。そこで、 USDMのフォーマットを拡張し、 各要求仕様とシステム要素の関係を下図のようなト レーサビリティマトリクス（要求仕様システム要素 トレーサビリティマトリクス：RSSETM ）で示すこ とで、要求仕様をヌケモレなくシステム要素に割り 当てることができます。 要求と仕様 ＜クルコンの始動＞ 要求 ON/OFFスイッチ E/Eシステム ミリ波レーダー ECU ACC.01.01 クルコンがOFFの時にドライバがON/OFFスイッチを押下した場合、クルコンをONできる 理由 説明 クルコンを使わない状況では、動作しないように機能をOFFできるようにする必要があ クルコン用のON/OFFスイッチはハンドルに付いており、ドライバが運転しながら操作す ることができる。 ＜ON/OFFスイッチの押下判定＞ ソフト 要求 ACC.01.01.01 理由 説明 ＜押下判定＞ また、これらのフレームワークは仕様を導出する 場合だけではなく、上位要求から下位要求を導出す る場合にも用いることができます。 構成分割 時系列分割 理由 説明 仕様とは前述の通り要求を実現するためのシステ ムの具体的な動きや制限を表したものです。これは 開発者への「どのように作るか」という作業指示と 言い換えることもできるので、開発者が設計・実装 するのに十分な詳細度で記載する必要があります。 上位要求 ACC.01.01 クルコンがOFFの時にドライバがON/OFFスイッチを押下した場合、クルコンをONできる条件が成立していることを判定し、クルコンをONにする。 スイッチのチャタリングの影響を考慮し、ON/OFFスイッチが押下され たことを判定する。 チャタリングによって誤判定しないようにするため。 仕様を チャタリングとは、スイッチが押されたときに発生する微細な機械的振 動によって、電気信号のオン/オフが細かく切り替わる現象のこと。 SP.ACC.001.01 ON/OFFスイッチの信号が「オン」である状態が50[ms]以上継続した 後に「オフ」に変化した場合、ON/OFFスイッチ押下判定を「オン」に する。 SP.ACC.001.02 ON/OFFスイッチの信号が「オフ」であるか、「オン」が50[ms]以上 継続しないで「オフ」に変化した場合は、ON/OFFスイッチ押下判定を 実現するユニットに 割り当てる ○ ○ ○ ○ 「オフ」にする。 エクスモーションが提供するサービス 要求仕様書作成 サービス 要求仕様書を作成したいのに作成する工数が取れないといったお客様に向 けて、エクスモーションが制御仕様書や機能仕様書などの既存資料の調査 や開発者へのヒアリングを行って要求仕様書を作成します。 お客様自身で要求の定義や仕様化のスキルを身につけたい場合も、エクス モーションが作成した要求仕様書をお手本として学習できますので、技術 導入の最初のステップとしてもお勧めです。 要求仕様書作成手法 導入支援サービス 要求の定義や仕様化に必要な知識や技術の教育を実施したり、開発プロセ スに要求定義の工程を組み込むための検討をすることで、お客様の組織へ 要求の定義と仕様化のための技術を導入するお手伝いをします。 USDM実践 トレーニング 要求の定義と仕様化の基礎的な方法を身につけて頂くため、USDMで要求 仕様書を作成する演習を中心としたトレーニングを実施します。 www.exmotion.co.jp/ [email protected] ☎ 03-6722-5067 16 既存資産の解説書 ∼埋もれた知識の共有化∼ 混沌とした開発現場では、実にさまざまな問題が起こりますが、その多くは『使 えるドキュメント』がないことに起因します。開発者は開発プロセスに従って、必 要なドキュメントを作りますが、その後、誰も見ぬまま情報が古くなり、『使えな いドキュメント』になってしまいます。なぜなのでしょうか？ 「使えるドキュメント」がないことが引き起こしている問題 組込みソフトウェアの開発現場では、生産性や品 質の問題が日々深刻さを増しています。その原因は いろいろと考えられますが、『使えるドキュメン ト』がないことが原因の一つであることは、想像に 難くありません。ここでは、その典型的な問題が起 こっている派生開発を例に、どんな問題があるのか を説明します。 しく悪化し、生産性の低下につながってしまいます。 以下に『使えるドキュメント』がない開発現場で よく見られる現象をピックアップしてみました。 皆さんの開発現場は、いくつ当てはまりますか？ ・ドキュメントを作成する人のスキルの問題 17 思考力・図解力・文章力などのスキルが求められま す。それらのスキルは、プログラミングや要素開発 などの開発スキルとは異なり、一般的には開発者が 苦手としている分野です。そのため、たとえ育成し たとしても、満足できるレベルまで到達するために は、かなりの期間と費用を必要とします。 では、ただ時間があれば、「使えるドキュメン ト」が書けるのでしょうか？ このように、「使えるドキュメント」を作成する ためには、ここで挙げた２つの問題に取り組む必要 がありますが、開発者をそのまま「使えるドキュメ ント」の作成者にアサインすることは、現実的な解 とは言えません。 ドキュメント化されず、担当者の頭の中に埋もれて しまい、いつしか忘れ去られてしまうのです。 ■ドキュメントを作成する人のスキルの問題 「使えるドキュメント」を作成するためには、重 要な情報を見極め、分かりやすく伝わる形にする必 要があります。そのためには、抽象化能力・論理的 「解説書」とは何か？ エクスモーションでは、ここで言う「使えるド キュメント」のことを「解説書」と呼んでいます。 「解説書」とは、開発対象にとって重要なポイント を分かりやすく伝えるドキュメントの総称です。 その製品の特徴であったり、背景となっている仕組 みの解説が中心となります。それらは、一度作成す れば、長い間参照されるものとなります。そのため、 一度作ることに大きな意味があるのです。 解説書は、その目的や読者によ り、複数のドキュメントで構成さ れます。右図はその一例です。 XX YY ZZ … ECU ECU ECU システム概要 協調制御概要 制御概要 制御設計書 データ定義 「解説書」に書かれる内容は、 定数定義 Simulink モデル コンサルタントが教える成功の秘訣 なぜ「使えるドキュメント」は開発現場にないのか？ ・開発工数・優先順位の問題 結果として、その時の製品をリリースするための 最低限のドキュメントを作るだけで精一杯になりま す。それには、合意した「結果」だけが書かれ、そ の根拠や背景については触れられません。つまり、 リリース後の派生開発で本当に必要とされる知識は 解説書全体として記載する内容 は、ユーザーズマニュアルレベル の要求仕様と、その実現手段であ るソフトウェア構造やソースコー ドとを段階的に結びつけるもので あり、開発対象によらず共通です。 しかし、ドキュメントの構成、各 ドキュメントの記載内容や記載方 法は、それぞれ異なります。 派生開発では、最初の製品を開発した時に、ほと んどの大きな課題を検討し、その結果としてアーキ テクチャが構築されます。しかし、そこで残される のは、検討のために開かれた会議の議事録（あれば 上等）と、検討の結果構築されたアーキテクチャと その説明だけとなってしまいます。その後の派生開 発においては、最初の製品を開発した時と同じメン バ構成で行われるのは稀で、メンバの多くは入れ替 わります。投入された新しいメンバには、検討の結 果構築されたアーキテクチャドキュメントや設計ド キュメント（それらはすでにコードと乖離している …）と、ソースコードだけが与えられます。その人 達は、与えられたものを元に、現行の仕様を理解し しようと試みますが、結果的に理解することは難し く、時間の制約の中で場当たり的な対応を繰り返し てしまいます。その結果、いつの間にか保守性は著 では、なぜ「使えるドキュメント」が開発現場に ないのでしょうか？その原因は、次の2点に集約さ れます eXmotion Solution Guide Vol.4 ■開発工数・優先順位の問題 近年のような激しい競争が強いられる経営環境に おいては、いち早く多くの市場を獲得することが最 優先の経営課題となっています。そのため、「どこ よりも早く製品をリリースする」ために、開発者は 何よりも、製品自体の作り込みを優先させられます。 現場で必要とされている解説書は、開発対象や現場が置かれている状況など によりまちまちです。そのため、本当に「使える」解説書は、機械的なやり方 で導出することは難しく、現場の声を吸い上げて「仕立て」ていく必要があり ます。つまり、良い解説書を作るためには、お客様の本質的な要望を理解し、 開発対象の何が重要かを見極め、それを分かりやすく伝えるスキルが必要とな ります。 エクスモーションでは、お客様のご要望をお聞きし、それに合った表現方法 や進め方をコンサルタントが見極めて、ご提案いたします。また、作成中は、 担当者の方に繰り返しレビューして頂きながら、内容の正確さや分かりやすさ を高めていきます。そのようなプロセスを経て作り上げる解説書は、どのよう な開発対象であっても、きっとご満足いただけるものと自負しております。 シニアコンサルタント 小浜 宗隆 18 既存資産の解説書 eXmotion Solution Guide Vol.4 『制御設計書』 「解説書」は 暗黙知 を関係者で共有するためのドキュメント ここでは、解説書のサンプルを2つ紹介します。 一つは、製品全体システムに関わる「システム概 要」で、もうひとつは、あるモジュールにフォーカ スした「制御設計書」です。 ■システム概要 下図にある「システム概要」は、ソフト・ハー ド・企画・品質保証など、さまざまな背景を持つ関 係者が読み手になります。そのため、ソフトウェア 工学の範疇にある（例えばフローチャートやモデル などの）アイテムにこだわらず、必要に応じてイラ ストやグラフなどの表現方法も活用し、読み手への 情報の伝わりやすさを第一に考えて記述することが 必要となります。 また、ユーザーズマニュアルに記 載されているような、専門知識を持たない人でも理 解できるレベルの内容から、内部の構造であるシス テム構成までを、思考の過程を妨げないよう、関連 付けを明確にしながら、段階的に詳細化・局所化し ていきます。こうすることで、ソフトやハードの専 門知識を持たない関係者に対しても、深い理解を促 すことが可能となります。 『システム概要』 誰が「解説書」を作るべきか…？ 解説書を具体的に見ていただくと、こんな疑問が 出てきたかもしれません。 誰が「解説書」を書くべきか…？ 解説書に記載している内容は、比較的一般的な知 識に基づくものもあれば、高い専門知識に裏付けさ れたものもあります。そのため、やはり開発者自身 が作成するのが適しているのか、というように思わ れるかもしれません。ただ、前述のように、開発者 がドキュメントの作成時間を捻出することは難しい うえ、「使えるドキュメント」の作成スキルと開発 スキルは異なります。 ■制御設計書 右ページにある「制御設計書」は、システムを構 成する一部のモジュールを対象範囲とした「解説 書」です。このドキュメントの想定読者は、そのモ ジュールの派生開発の担当者です。 一般的に、派生開発で引き継がれるのは、実際に 動かすことのできるコードやモデル、そして機能仕 様や要求一覧です。しかし、コードやモデルと機能 仕様や要求一覧の間には大きなギャップがあります。 要求や機能は実現手段を選びません。その要求や 機能に対して、制約やその他の理由により意思決定 がなされ、多くの選択肢の中から一つの実現手段が 選ばれます。それが、今のコードやモデルの構造と なるのです。しかし、従来の設計書では、その「意 思決定がなされた根拠」がまるまる抜け落ちている のです。そのため、引き継いだコードやモデルを、 品質よく保守していくには、かなりの「経験」と 「想像力」を必要とします。しかし、派生開発は新 規開発に比べて 簡単 だと判断され、若手社員や外 19 部社員に任すケースがほとんどです。そのため、ソ フトウェアの品質は派生する度に悪くなり、いつの 間にか手のつけられない状態になってしまうのです。 ここでは、実際に 架空のシステム ではあります が、具体例を元に「解説書」を説明しました。これ で、一般的な「設計書」と「解説書」の違いがご理 解いただけたかと思います。 ところで、「解説書」に書かれている内容は、ド キュメント作成者が考え出したものではありません。 それは、最初の開発の時に検討会の資料としてその 都度つくられ、担当者のPCのHDDに残されたもの であったり、検討会の中でホワイトボードに直接か かれた画像として残されたものであったり、ベテラ ン社員の頭の中にある暗黙知だったりします。その 暗黙知を関係者の間で正しく共有することが、ソフ トウェアひいては製品開発全体の生産性や品質の向 上につながります。 そこをカバーできるのが、開発現場主体で活動し ている、コンサルタントの存在です。 エクスモーションのコンサルタントは、お客様の 開発現場で、お客様と一緒になって問題解決にあた ります。そのため、組込みソフトウェアの経験が豊 富にあり、どんなシステムでも、多少の時間をかけ れば、ある程度専門性の高い知識であったとしても 理解することができます。また、そもそも「抽象 化」「整理整頓」はコンサルタントのコアスキルで あり、得意分野です。その両方を兼ね備えているか らこそ、かゆい所にまで手が届くドキュメントを作 ることができるのです。 一方で、開発者は専門家に解説書作成を任せてし まうことで、本来の開発業務に専念することができ ます。更に、いったん「解説書」が完成すると、最 良のドキュメンテーションのお手本を得ることがで きるのです。お互いが、お互いの得意分野に専念し、 協力し合うことで、最高の成果を残す。まさに「 は 屋に任せろ」というわけです。 皆さんも、一度、解説書の作成を検討してみては どうでしょうか？ エクスモーションが提供するサービス 解説書作成サービス 「派生開発の生産性が低い」「保守品質が悪化して収拾がつかない」と いった問題は、開発者がそのシステムを本質的に理解していなかったり、 関係者の間で認識がずれていることが原因の一つと言えます。エクスモー ションでは、埋もれている知識を発掘し、お客様の開発システムに合わせ た最適な「解説書」の構成のご提案と作成を致します。 「抽象化」「整理整頓」の専門家である我々が作成した「解説書」は、永 く使われるとともに、最良の教科書となりえます。 思考整理トレーニング 「抽象化」「整理整頓」の基礎力を上げるには、自分の考えを整理する必 要があります。本トレーニングは、思考を整理するためのいくつかの方法 を、演習を通じて学びます。思考の癖は、1日では直りませんが、最初の 一歩を踏み出すには、良いきっかけとなります。 www.exmotion.co.jp/ [email protected] ☎ 03-6722-5067 20 eXmotion Solution Guide Vol.4 プロダクトライン開発 それぞれの製品毎に開発を進める従来のソフトウェア開発は、いわば『製品（単 体）の開発』です。これに対してプロダクトライン開発は、『製品群の開発』とい うアプローチを採ります。この視点の違いが、製品毎の重複開発をなくし、ムダの ない、生産性の高い製品開発を実現する となります。 個別最適から全体最適へ、開発の方法が変わります 現在の組込み機器は、多くの製品バリエーション を抱え、なおかつ、短い周期でのバージョンアップ が行われています。そのような環境において、ソフ トウェアの開発現場では、派生開発、あるいは再利 用開発という方法で、この厳しい状況を何とか乗り 切っているというのが現状です。 ればなりません。 この二つの方法は、いわば「個別最適」の視点で 開発を行っている、ということが言えます。各バー ジョンを残すことで、製品固有の変更を容易に行う ことができますが、複数バージョンに共通な追加や 変更はそれぞれで実施しなければならず、変更箇所 派生開発の典型（下図左上）は、新製品の開発時 ×バージョン数だけ実施する必要があります。更に、 や旧製品のバージョンアップ時に、元となる製品の 変更箇所が複数バージョンにわたることで、漏れや 資産（コード等）をコピーしていきます。その結果、 ミスが起こりやすくなります。 メンテナンスする資産が枝葉のようにどんどん増え この「個別最適」の視点を「全体最適」に転換す ていきます。 るのが、ソフトウェアプロダクトライン（SPL）開 一方、再利用開発（下図右上）では、複数の製品 間で再利用される資産を作りますが、各製品は特定 のバージョンの資産に依存しています。このため、 全ての製品をメンテナンスするためには、結局、再 利用資産の全てのバージョンをメンテナンスしなけ 発と言えます。SPL開発では、最新バージョンから 全ての製品を導出するため、メンテナンス対象の バージョンが１つで済み、前述のような変更の漏れ やミスを防ぐことができます。 既存資産を洗練・進化させて、ムダなくムリなくプロダクトライン開発へ移行 「SPL開発に移行する」というと、大きな変革が 必要と思われがちです。確かに、価値観を「個別最 適」から「全体最適」にシフトする必要があります し、これまでになかった作業が発生することもあり ます。しかしながら、過去に開発した資産を全て作 り直す必要はありません。それらを活用しながら、 比較的低いコストで移行することも可能です。 まず、SPL導入前にメンテナンスされていた複数 のバージョンを一つに統合し、再利用資産のベース を作ります。この時、資産のどの部分が共通で、ど の部分が異なるのか、アーキテクチャ構造はどの程 度共通なのかといった観点で、既存資産を精査しな がら統合していきます。 統合が終わると、資産中の製品間の違い（可変 性）に相当する部分をカスタマイズして、統合前の 製品が容易に導出できるようにします。 その後の新製品開発では、新しいバージョンから 全ての製品が導出できるように、資産をバージョン アップさせていきます。これで、製品群開発のムダ を大きく削減できます。 このように書くと簡単に思えるかもしれませんが、 実際には時間のかかる作業となります。そのため、 SPL開発に移行する前に、現状と目標値（あるべき 姿）をしっかりと把握し、段階的な移行計画を立て ることが重要です。 製品バリエーション この時点で、これまでに発生した可変性が 容易に実現・利用できるようになる g 【進化】 統合した資産から各製品が容易に 導出できるよう、設計を改善 【導出】 d f f e e e d d d d c c c c b b b b a a a a b a 1 c 【SPLE導入前】 複数に分岐した資産を維持管理せねば ならず、効率的な開発ができない 2 【統合】 複数ある資産を、 １つの資産に統合 3 4 5 将来的な可変性を予測し、より多くの製品 バリエーションを容易に導出できるよう、 設計を改善 時間 コンサルタントが教える成功の秘訣 SPLは非常に幅の広い工学体系で、製品戦略から開発技術、プロセス、組織編 成までを含みます。このため、成功のための勘所を捉える事が難しいという面 もあります。 とはいえ、その基本は「技術をベースとした製品群開発の効率化」です。ど のような技術を用い、それらがどのように作用することで効率化が実現される のかをよく理解することが、偏見や誤解なくSPL開発を成功させるための近道 と言えます。 SPLの技術を学ぶ際には、「スコーピング」「可変性管理」「バインディン グ」の３つのキーワードに着目すると、より効果的にポイントを押さえること ができるでしょう。 21 シニアコンサルタント 山内 和幸 22 eXmotion Solution Guide Vol.4 派生開発モデリング XDDM XDDPによる派生開発 派生開発における失敗やトラブルの原因は、変更仕様のモレやミスによる手戻り、 影響範囲の特定が不十分であることによる不具合がほとんどです。それを未然に防 ぐのが『XDDPによる派生開発』です。 XDDP は、ソフトウェアの「派生開発」に特化したプロセスです 現在のソフトウェア開発においては、新規開発は ほとんどなく、既存コードに機能追加や変更を行う 『派生開発』が多くなっています。 一般的に、変更や追加は仕様レベルでエンジニア に伝えられることが多く、また、納期も短いことか ら、変更仕様をそのままコードで実現してしまいま す。その結果、変更箇所以外の仕様が漏れたり、変 更箇所以外の不具合による手戻りの連続により、工 数が増大するとともに、エンジニアも疲弊してしま います。 これまで、ソフトウェア開発技術は欧米を中心と して発展し、新規開発を対象としていましたが、派 生開発に特化した唯一のプロセスが「XDDP」です。 XDDPは変更や追加に必要最低限のドキュメントと プロセスが定義されており、派生開発を効率よく進 めることができます。 「3 つの成果物」により、モレ・ミス・ムダを防止します XDDPの特徴は『3つの成果物』による、ミス・ モレ・ムダの防止です。この3つの成果物を完成さ せるまでは、絶対に実装をしません。完全なるフロ ントローディングを行うことにより、手戻りによる ムダを排除することで、派生開発の問題を未然に防 ぐのです。 ■USDMで仕様のモレを防ぎます USDMは要求と仕様を形式化するツールです。派 生開発における変更要求仕様や追加機能要求仕様を USDMで記述することにより、要求仕様の抜け漏れ や矛盾などの問題を見つけやすくなります。 変更要求 Why どう変更したいのか なぜ変更したいのか 仕様 What 何を何に変更するのか ■TMで変更のモレを防ぎます トレーサビリティマトリクス（TM）は、USDM で定義した仕様に対する、コードの対応箇所を示し た対応表です。このマトリクスにより、変更仕様に 対する影響範囲を把握することができ、変更箇所の ヌケモレを防ぐことができます。 ■変更設計書で、各変更をきちんと設計します 変更設計書は、変更箇所に対してどのような変更 をするのかを設計し、明文化したものです。これを 有識者との間できちんとレビューすることにより、 対応のミスを防ぐことができます。 変更箇所の特定 Where どのソースの、どの関 数を修正するのか 変更設計 How どのように修正するのか 変更 要求 仕様 ①変更要求仕様書 （USDM） 23 Universal Specific Description Manner 行：変更要求仕様と 列：ファイルの交点 ②トレーサビリティ・ マトリクス （TM） 実 装 派生開発では、変更や機能追加を実現することが 優先され、「設計」がおろそかになりがちです。ま た、工数が限られていることもあり、「とりあえ ず」と設計は後回しにして、実装が先行してしまい ます。その結果、開発初期の設計思想が崩れ、崩れ たところに変更が入り、設計品質低下の一途を っ ていきます。設計品質が低下すると、変更時の工数 も増大して負の連鎖をひきおこします。 更範囲における設計が『派生開発モデリング :XDDM 』です。 設計品質の低下を防ぐには、変更や機能追加時の 設計をモデルによって「見える化」し、あるべき設 計の姿を定義することが必要です。この設計を実現 することで設計品質を保つことができます。この変 ■既存資産から仕様を抽出する「スペックアウト」がその後の開発を左右します XDDPでは変更仕様書を記述する前に、既存資産 を調査して仕様を抽出する「スペックアウト」とい う作業を行います。既存資産として仕様書がメンテ ナンスされていればスペックアウトは容易ですが、 仕様書がなかったり、古くて現状と合っていない場 合、ソースコードから仕様を理解して抽出するとい う作業が必要になります。 ソースコードから仕様を抽出する際、変更要求か ら想像できる変更箇所の「あたり」を付けて、部分 的にソースコードを理解していきます。その時、単 にソースコードを眺めるのではなく、 行われている 処理から設計図をおこします。作成する設計図は調 査対象の特徴によって異なりますが、ドメインに合 った最適な図のみを必要な部分だけ作成します。 この作業によりソースコードから処理の目的を理 解し、詳細な仕様を理解します。理解した仕様は変 更要求仕様書における既存の仕様「Before 」として USDMに記述します。スペックアウトでの 「Before 」の抽出が漏れてしまうとその後の変更仕 様も漏れてしまい、手戻りの原因になります。 ■XDDMは、変更要求における変更設計要件を明らかにします スペックアウトで「Before 」の仕様が明確になっ たら、変更要求を現状の設計に対してどう実現する のが良いかを検討します。設計検討が行われずに進 めると、本来は違う関数で処理したほうがいいはず なのに別の関数で実装されたり、あるいは、1つの 関数を2つに分割したほうが、独立性が良くなるの に、大きな1つの関数のままになったりしてしまい ます。その結果、変更を重ねるたびに設計品質が低 下していきます。 コンサルタントが教える成功の秘訣 XDDPを導入する上で多くの人がつまずくのが、最初の一歩となる『変更要求 仕様書（USDM）』のところです。USDMでは、要求を階層化しグルーピング していくのですが、どんな粒度や視点で階層化やグルーピングするのか、初心 者の方はずいぶん悩まれるようです。 要求の階層化は、「スペックアウト」で正確に仕様を抽出し、その仕様から 構成や時系列の視点で要求を定義、整理します。ここで、スペックアウトを行 うには設計技術が必要となります。この仕様化技術と設計技術のコツさえ掴ん でしまえば、後はスムーズに進むのですが、この段階でつまずくと、XDDPの 導入はうまくいきません。 エクスモーションでは、仕様化技術、および、設計技術をベースにXDDPの導 入を支援するサービスを行っております。 ③変更設計書 シニアコンサルタント 斎藤 賢一 24 XDDPによる派生開発 このような設計品質低下を防止するには、変更要 求仕様書における「After 」をイメージし、この変更 範囲において本来あるべき姿の設計「スコープゴー ルモデル：SGM」を定義します。次に、既存の設計 をそのSGMにするにはどうすればよいかを検討する 変更基本設計（チェンジベースラインデザイン eXmotion Solution Guide Vol.4 ： CBD）を行います。 この結果を「設計変更要求」 と して変更要求仕様に追記し、TMで他のモジュールへ の影響を確認します。このあるべき姿の設計である SGMを実現することで設計品質を保つことが可能に なります。 ■製品系列の仕様とアーキテクチャ設計を「変更要求仕様」として扱います SPL化の変更要求仕様は、製品の共通部分の仕様 と製品個別の仕様を明らかにする必要があります。 そこで、フィーチャーモデルで定義した可変性を USDMの要求と仕様にマッピングします。これによ り共通部と可変部の階層構造をUSDMで定義できま す。 また、アーキテクチャ要求についてはSPLアーキ テクチャのスコープゴールモデル：SGMを定義し、 USDM記述の「After 」を定義します。これにより、 XDDPの効果であるモレ・ミス・ムダを省きながら SPL化が実現できます。 <<enumeration>> 注文状況 属性 - 新規 :Integer - 梱包済み :Integer - 出荷済み :Integer - 配達済み :Integer - 終了 :Integer 在庫 +注文状況 + + + + + カタログ記載価格 :number カタログ番号 :string 原価 :number 書名 :string 著者 :string 注文 +品目 + + + 出荷指示 :String 注文番号 :String 日付 :Date + 未払いの注文をチェック() :void ア カウン ト + + + + + クローズ済み :Boolean メールアドレス :String 請求先住所 :String 配達先住所 :String 名前 :String + + + + + + アカウントクローズを記録() :void アカウント詳細を取得() :void アカウント詳細を読込() :void ユーザーを認証する(String, String) 新規アカウント作成() :void 新規アカウント詳細を登録() :void +アカウント 取引 +アカウント +履歴 + + 注文番号 :String 日付 :Date + + アカウント履歴を読込() :void 終了していない注文を読込() :void 品目 + 数量 :Integer +買い物かご 買 い物 か ご フィーチャーモデル による可変性分析 - 買い物かご番号 :String + + + + 商品を削除() :void 商品を追加() :void 新しいかごを作る() :void 注文を処理() :void プロダクトライン アーキテクチャ SPL変更要求仕様 XDDP からSPL へ XDDP 導入によくある問題 XDDPは変更・機能追加時のプロセスであり、そ 同様に、SPL化に向けた変更要求を定義することで、 れ以上でもそれ以下でもありません。変更要求は機 XDDPを活用して確実にSPLの道を歩むことができ 能的な要求もあれば、作りに関する要求もあります。 ます。 ■XDDPを活用し、段階的にSPL化します 大規模な既存システムを一気にSPL化するには多 大な労力と工数がかかります。また、SPL化の間、 ビジネスを止めるわけにもいきません。このような ことから、なかなかSPLに取り組めないというのが 現状です。 そこで、部分的な派生開発により、段階的にSPL 化することが現実的です。SPL化も派生開発の変更 要求ととらえ、「ある部分において、製品共通部分 と固有部分とに分離してほしい」という要求を定義 します。その要求に対しXDDPの変更要求仕様を定 義することで、部分的なSPL化が可能になります。 これをコンポーネントやモジュールに対して段階的 に行うことで、確実なSPL化が可能になります。 XDDPを導入する際によくある問題として、まず、 現状の問題を明らかにせずにXDDPに飛びついてし まい、効果が出ないといった問題があります。 XDDP導入にあたっては、現状のプロセスの問題点 を明らかにし、XDDPによる改善をイメージできる ようになってから導入する必要があります。 また、実際にXDDPを実践してみると、要求や仕 様をどう分割していいかわからず、途方に暮れるこ とがあります。仕方なく、思いついた要求と仕様の みを記述し、先に進むことで、仕様のモレに後にな って気付くことがあります。 次に、スペックアウトが十分できていないまま、 さらに、大規模だからといって端からあきらめて あいまいな状態でUSDMを記述することがあります。 しまい、TMを省略することがあります。これによ このような状態では変更要求仕様として不十分であ り、変更の影響による不具合が後になって見つかる るため、実装でモレや勘違いに気づき、手戻りする といったことが見受けられます。 エクスモーションが提供するサービス プロジェクト導入計画 作成 最終的にすべてのコ ンポーネントがSPL 化される XDDP実践トレーニング XDDPスタートダッシュ 支援サービス USDMサンプル作成 レビューセッション XDDPを活用し、段階的 にSPLへ移行 XDDP実践トレーニング 学習パート 実践パート www.exmotion.co.jp/ 25 ことになります。 現状のプロセスの問題点を明らかにし、その問題 を解決するプロセス、計画をご提案します。 演習中心のトレーニングです。 部分的にスペックアウト、USDM、TMのサンプ ルを作成します。お客様は、このお手本を元に、 変更要求仕様定義を進めることができます。 「書いてレビュー」の繰り返しで導入効率アップ とスキルアップが可能となります。 XDDPのポイントを効率よく把握できます。 実践的な演習によりコツをつかむことができます。 [email protected] ☎ 03-6722-5067 26 eXmotion Solution Guide Vol.4 ←ツリーマップ 専有面積の大きさが要 素の大きさを、色が要 素の複雑さ示す。 大きく複雑な関数は、 改善の対象となり得る。 レガシーリファクタリング ↓パッケージ依存関係 パッケージ( ディレクト リ) 間の依存の度合いと 方向性を把握できる。 これは、まだ良い方の図。 もっと複雑なものになる と、クモの巣状になり、 一つ一つの線が見えない ほどになる。 つぎはぎだらけになったレガシーコードの維持管理は、組込みソフト共通の問題 です。全てを捨てて作り直すことは無理でも、少しでも改善して今より良くしたい という気持は、誰もが持っているのではないでしょうか。この要望に応える技術が リファクタリングですが、実施するには多くのリスクが立ちはだかります。 長期間にわたる保守により劣化したコード…分かっているけど手が出せない 現在の組込みソフトウェア開発の現場は、多くの 製品バリエーションと短い周期でのバージョンアッ プに追われています。長期間、保守されてきたコー ドは、多くの人が追加修正し、今では「なぜこう なっているのか？」誰も説明できないコードも数多 くあります。今のコードを使い続けるべきか、一度 捨てて再構築するのか…グローバルに競争が激化し た今の経営環境では、再構築を選ぶ余地はなく、大 規模あるいは小規模なリファクタリングを続けなが ら、少しずつコードを改善し、状況も改善していく …それが唯一残された道と言えます。 しかし、リファクタリングへの一歩を踏み出すの は、容易なことではありません。その理由としては、 次の3つがあげられます。 ・開発に忙しく、時間が取れない ・リファクタリングするためのノウハウがない ・検証に不安がある 確かに、これらの問題を解決しないと、改善のつ もりが逆に大やけどを負ってしまう可能性も捨てき れません。 失敗のリスクを減らし、安全にコード改善する。 手当たりしだい始めるのではなく、今回ご紹介す 方法で、大規模・小規模なリファクタリングを進め てはいかがでしょうか。 まずは問題を把握することから始まります リファクタリングを始めるには、まずは、対象の ソフトウェアの状況を知る必要があります。その際 には、担当者の主観だけを頼りにするのではなく、 工学的な方法で問題を可視化することで、客観的に 状況を把握することができます。そこで把握したこ とが、リファクタリングBeforeの姿となります。 問題を可視化するには、次の方法が有効です。 ・定量分析 ・構造解析 では、それぞれについて少し解説しましょう。 ■定量分析 定量分析とは、分析対象を複数の観点から数値化 し、それを元に分析する方法です。ソフト品質に着 目した「ソフトウェア・メトリクス」を使うことが 主流です。これは、例えて言うなら、健康診断で血 27 液の成分を定量分析した結果を使って、健康状態を ざっくり把握するのと同じです。 しかし、これだけでは「問題があるかもしれな い」ことしかわかりません。更に、状況を把握する ためには、より具体的でかつ分かりやすい方法を導 入する必要があります。 ■構造解析 構造解析とは、対象ソフトウェアのプログラム構 造やモジュール構造を明らかにして分析する方法で す。これは、血液の成分検査と同様に例えて言うな ら、レントゲン検査のようなものでしょうか。 レントゲン検査では、X線が透過しやすいものと、 透過しにくいものがあるという性質を利用して、透 過しにくいもの（骨や肺）の状態を可視化します。 分析対象の「解析すべき点」のみを抽出して可視化 する方法です。 定量分析や構造解析には様々なものがあり ますが、ここではそれぞれ1つずつ例を示しま す。 上図は、要素の規模と複雑度を「ツリー マップ」という可視化手法で表現したもので す。「ツリーマップ」は、二次元平面上の領 域を入れ子状に分割することによって、木 （ツリー）構造のデータを効率的に可視化す る手法です。規模が大きく複雑な要素が、ど こに、どのくらいあるのかが視覚的・直観的 にわかり、リファクタリング対象を選ぶのに 役立ちます。 右図は、構造解析によって得られた「パッ ケージ依存関係」を図式化したものです。 パッケージ( ディレクトリ) 間にどんな依存関 係があるのか、依存関係の多さと複雑さはど うか、循環依存が生じていないか、などを解 析することができます。 コンサルタントが教える成功の秘訣 品質が低下したレガシーコードの保守に頭を悩ませる開発現場のエンジニア は、みなさまざまな問題認識を持っています。問題を改善していくためには、 現場での困りごとを発生させる要因となっているソフトウェア設計上の問題を、 客観的事実による裏付けとともに明らかにしなければ、大きな改善効果は望め ないのではないでしょうか。 レガシーリファクタリングのサービスでは、ソースコードの調査と現場エン ジニアへのヒアリングを通し、設計の問題点を把握することからスタートし、 ソフトウェア構造のあるべき姿を設計する支援や、リファクタリングを進める ためのプロセス設計・運用の支援まで、ソースコードの改善をトータルに支援 いたします。 レガシーコードの品質にお困りの方は、ぜひ私たちにご相談ください。 スペシャリスト 玉木 淳治 28 レガシーリファクタリング eXmotion Solution Guide Vol.4 問題は局所化できるか？製品としての成熟の度合いは？…それが分かれ目です 問題が把握できると、次は、どのようにリファク タリングを進めていくかを決めます。把握した問題 は、その方針を決める上で重要なファクターとなり ます。 しかし、それだけではありません。その製品を開 発するために、どの程度の投資をしていくかによっ ても、リファクタリングの方針が変わります。 製品への投資は、製品のライフサイクル（下表の 左列を参照）により、おのずと決まったり、戦略的 に決められます。レガシー資産を活用し、リファク タリングが検討されるのは、成長期の後期∼衰退期 です。その各期になされる投資と、レガシー資産が もっている問題の状況により、以下のリファクタリ ングのなかから、進め方が決められます。 ■「機械的」な設計改善リファクタリングとは 下図は、グローバルデータによるモジュール間結合の問題を、「機械的」に設計改善する例です。意味 論に踏み込まず、凝集度と結合度だけに着目することで、このように改善できます。 ←把握した問題 グローバルデータを介し て、各モジュールが複雑 に結合している。 グローバルデータの変更 が、広範囲に影響を及ぼ すことが分かる。 AS-IS ・局所的なコードベースリファクタリング ・意味論まで踏み込んだ、広範囲な設計改善リ ファクタリング ・機械的に実施する、広範囲な設計改善リファク タリング 問題が分散し広範囲にわたる 導入期 製品が市場に導入されたばかり。 機能が大きく変わる時期。 製品自体の位置付けも、変わる可能 性あり。 成長期 （前期） 製品が市場に認知され始め、市場に おける製品の位置づけがほぼ決まる。 各社、差別化を図り、機能の追加・ 淘汰が激しい。 成長期 （後期） 意味論まで踏み込んだ、広範囲 市場獲得のための競争が激化。 な設計改善リファクタリング 製品ファミリはどんどん増やされる。 （場合によっては、思い切って 成長期後半では価格競争が繰り広げ アーキテクチャの再構築をして られる。 も良い） 成熟期 製品の普及が行き渡り、生き残りが はっきりする。 製品ファミリが徐々に整理され、定 番ブランドのみが生き残る。 意味論まで踏み込んだ、広範囲 な設計改善リファクタリング 衰退期 代替製品の登場や、飽きられること で、市場が縮小していくが、根強い 顧客層のために製品リリースは維持 する。 機能追加はほぼないが、互換性は求 められる。 機械的に実施する、広範囲な設 計改善リファクタリング ←問題点の整理 グローバルデータと、ア クセスしているモジュー ルを分類し、水平方向 （赤の破線）、垂直方向 （青の破線）に分割する。 一つのグローバルデータ に、複数の意味を持つ部 分（緑の波線）があるの で、それも分類する 問題が局所的である レガシー資産の活用を考える必要がない ←目指すべき姿 整理した考え方に基づき、 モジュール構成を変更。 意味が混在しているグ ローバルデータは、二つ に分割する。 TO- BE 局所的なコードベースリファ クタリング 広範囲な設計改善リファクタリングとは、いったいどのようなものか？ 一般的に「リファクタリング」とは、ここでいう 局所的なコードベースリファクタリングのことを指 します。しかし、レガシー資産の品質の状況によっ ては、問題は局所的な範囲にとどまらず、広範囲に リファクタリングをすることになります。局所的な ものと違い、コードレベルの詳細度でいきなり始め るのではなく、設計レベルで改善を検討していきま す。 「意味論に踏み込む」場合、アーキテクチャを形 成しているそれぞれのモジュールの意味を考えたう えで、本来あるべき形に改善していきます。 一方、「機械的」な場合は、モジュールの意味を 考えず、機械的に「凝集度」を高め「結合度」を下 げる方向に、設計を改善していきます。 前者は、今後の保守開発において人が関与する余 地が大きく、理解性を上げることが保守品質の確保 ■「意味論に踏み込む」 と 「機械的」の違い につながる場合に有効です。後者は、今後の保守開 同じ「広範囲な設計改善リファクタリング」でも、 発においては、移植や少しの手直しだけを計画して 「意味論に踏み込む」場合と「機械的」に実施する いる場合に有効です。 場合では、やるべきことが大きく変わります。 29 ■広範囲な設計改善はフルテストが必要、 そのために 「要求の定義と仕様化」 をすること 局所的なリファクタリングは、要素のインターフェイスを変えないため、変更箇所に対するブラック ボックステストを行うことで機能の互換性が保証できます。一方、広範囲な設計改善では、設計改善後に 一度フルテストをして、求められている要求と仕様を満足していることを確認する必要があります。 網羅的なフルテストを実施するためには、満たすべき要求と仕様をモレなく定義することが前提になり ます。要求と仕様をヌケモレなく記した文書がない場合には、リファクタリングと併せて、USDMなどを 使用した要求の定義と仕様化をしっかりと行なう必要があります。 エクスモーションが提供するサービス ソースコード診断サービス ソフトウェア・メトリクス解析やアーキテクチャ構造解析などによって、 ソースコードの品質を多面的に診断し、設計・実装上の問題点の抽出と 改善へのアドバイスを行います。 レガシーリファクタリング ソースコード診断による問題の把握から、あるべき姿への改善まで、設 計技術支援とプロセス設計によって、レガシーコードの改善を総合的に 支援します。 要求仕様書作成サービス 要求仕様書を作成したいのに作成する工数が取れないといったお客様に 向けて、エクスモーションが制御仕様書や機能仕様書などの既存資料の 調査や開発者へのヒアリングを行って要求仕様書を作成します。 www.exmotion.co.jp/ [email protected] ☎ 03-6722-5067 30 eXmotion Solution Guide Vol.4 モデルベース開発 なぜ、開発現場に定着するのが難しいのか？ 前述にもある通り、UMLが正式に標準化されて14年もの歳月が流れていますが、開発現場に定着してい るとは言えません。なぜ、このような状況に陥っているのでしょうか？ UML＋オブジェクト指向 1997 年にUMLがOMGで採択されてから、14年が経ちました。組込みソフトウェ アの開発現場にも、UMLによるモデル開発が適用され始めましたが、まだまだ定着 したとまでは言えないようです。しかし、上流工程を重視するこの技術は、特に、 新規でアーキテクチャを構築する時には欠かせないものです。 組込みソフトウェアには、丈夫で長持ちするアーキテクチャが必要 現在の組込みソフトウェア開発の現場は、多くの そのため、新規にソフトウェアを構築する時には、 製品バリエーションと短い周期でのバージョンアッ いかに丈夫で長持ちするアーキテクチャを構築する プに追われています。一度アーキテクチャを作れば、 か、という点が、重要なポイントとなります。 短くとも5年、長ければ20年近くもそのアーキテク では、丈夫で長持ちするアーキテクチャとは、ど チャを使い続けます。 のように作ればよいのでしょうか？ 「抽象化」により、丈夫で長持ちするアーキテクチャを みなさんは、UMLやオブジェクト指向という技術 について、どのような印象をお持ちでしょうか？難 しいといった声も聞こえてきますが、実は、UMLや オブジェクト指向自体はそれほど難しくありません。 それよりもむしろ、難しいのは対象となるシステム の知識を整理することです。 UMLやオブジェクト指向は、その整理したものに 対して、整頓するための観点を与えたり、その結果 を可視化して、レビューし易くする、といった手助 けをしてくれます。 特にオブジェクト指向で強力なのは『抽象化』と いう概念です。 オブジェクト指向における抽象化とは、物事の大 事な部分だけを取り出して、本質的な構造や振舞い をモデル化する、ということです。そうすることに より、時間が変化しても変わらない普遍的なものと、 そうでないものが明確となり、時間軸での劣化を防 ぐことが可能となります。そのため、長持ちする アーキテクチャを構築するのに向いている、という ことが言えます。 コンサルタントが教える成功の秘訣 客様の中には、抽象化されたモデルを、なかなか理解できない方がいらっしゃい ました。そのような状況において、抽象化はお客様にとって、むしろ足かせにな りかねません。 エクスモーションでは、お客様の目的や理解度に合わせて、どこまで抽象化す ればよいか、お客様に確認しながら進めていきます。例えば、「このような変更 に対応できるようにしたいので、ここまで拡張性を設けます」といったように、 ションがサポートいたします。 31 間経過により変わるものと変わらないものを区別し て分離しているかどうか、という点です。組込みシ ステムでは ハードウェアや制御方法 は変化しやす く、その システムが達成するミッション は、あま り変化しません。自動販売機で言うと、 商品販売 という仕事がそれにあたります。 ■良いお手本を使って人材を育成 長年、手続き指向で開発を続けていた人が、いざ、 これは、よい お手本 が開発現場に存在しないこ オブジェクト指向で開発しようと思っても、なかな とが一つの原因と言えます。組込みの開発現場は、 かその 手続き的な発想 から切り換えることができ 開発そのものが企業独自のノウハウであり、競争力 ません。 の源泉となっています。そのため、いくらいいモデ ルができたとしても、外部には公開しません。その 例えば、下図の左側のモデルは、 手続き的な発 結果、たまたま良いモデルを作れた企業はどんどん 想 のまま作られたクラス図です。一方、右側のモ 良い方向へ、そうでない企業は、モデルから離れて デルは、オブジェクト指向的な発想にのっとって 作ったモデルです。この二つのモデルの違いは、時 いく、といった二極化が起こっているのです。 しかし、なかなかここにフォーカスしてモデルを 作るのは難しいようです。 「良いお手本を見て理解を深める」「開発の実践 以外にモデルを書く機会を増やす」「繰り返しモデ ルを書く」ことが、モデリングスキルを向上させる ために必要です。そのようにしてスキルのある人材 を増やすことが、開発現場への定着につながるので す。 取り扱う問題のレイヤ別に パッケージ化し、それぞれ の依存度を低くしている 「システムデータ」の構造に全てが依存 要求に変更があると、全てを見直す必要 がある 自動販売機の「商品販売」 という目的に即したモデル <目的> 自動販売機 代金 入金 入金確認 … 貨幣識別 商品選択 … … … 釣銭計算 システムデータ + 投入金額 + 選択商品 + 商品金額リスト[10] + 商品個数リスト[10] 商品販売 釣銭排出 自動販売機でなくとも、 通用するモデル - 金額 例えば、店頭販売であっても 同じモデルとなる 1 制御仕様 排出制御 商品の種類 - 名称 - 価格 0..1 1 販売 -/ 販売額 0..1 0..1 -/ お釣りの額 1 金庫 -/ 総額 1 1 物理仕様 商品別在庫 - 数量 1 1..n 金額別金庫 - 金額 - 数量 <手段> ものごとには、複数の見方があります。例えば、円柱も四角柱も、横から見 ればどちらも長方形ですが、上から見ると、円と正方形の全く違う形に見えま す。分析とは、ものごとが持っている複数の見え方の、どの側面にフォーカス してみていくか、ということを決めることです。ものごとをどの側面で見るか によって、その解法は当然違ってきます。「どの側面から見ると、どのような 解法になり、それは適切なのか」といったように、複数の観点を比較しながら、 最良の分析を見つけていく、そこが難しくも、面白いところです。 ですが、その抽象化が逆に問題になることもあります。私がこれまで関わったお して、その後の作業もスムーズに取り組めるようなモデルづくりを、エクスモー ■良いお手本が現場にない コンサルタントが教える成功の秘訣 オブジェクト指向によるモデル開発では、「抽象化」は非常に有効な概念です。 そのような構造になった背景も合わせて解説することも大事です。お客様が納得 ■初心者が自己流で超えられない壁 シニアコンサルタント 八坂 浩司 エクスモーションのコンサルタントは、まさに、このような分析作業を得意 としています。モデリングの良いお手本づくりに、この強みを活用していただ ければ、時間的・費用的に十分メリットのあるモデルベース開発を実現できる と確信しています。 エグゼクティブコンサルタント 井山 幸次 32 イージーオーダー eXmotion Solution Guide Vol.4 eXmotion Quality Assesment Tool トレーニング イージーオーダートレーニングは、お客様の実際の開発対象を例題や演習に取り入れることで、 より実践的なスキルアップを狙ったトレーニングです。 次のような悩みをお持ちのお客様におススメするトレーニングです。 • 一般的なトレーニングでは、実用化との間にギャップがある • 結局、トレーニングしてもその場限りで終わってしまう イージーオーダートレーニング 理論 レディメイド部分 理論と練習の部分は、 これまで充分実績のある、既製 のものを活用します。 練習 演習の題材は、お客様の実際の 開発対象を使って行います。 実施スタイルは以下の2種類よ り選べます。 演習スタイル or 受講生のこれまで学習したことを 元に 自分たちの開発対象で考え る ことで、より実践的な理解が図 れます 解答例はあらかじめ作らず、その 場で、受講生と講師が一緒になっ て問題に取り組みます 講師が問題に取り組むプロセスを、 体験することができます 講師のやり方を 真似 し、 考えるより慣れる ことで 学習効果を高めます 費用は標準的なトレーニングと同じです （オーダーメイドにかかる費用は発生しません） 費用＆進め方の詳細についてはお問い合わせください 33 QAC連携 C 言語用 品質診断ツール 主な機能 品質の定量化 スコープ別評価 品質特性別評価 コードクローン解析 アーキテクチャ構造解析 Simuink® モデル用 品質診断ツール ワークショップスタイル 事前に開発対象のお話を伺い、問 題と解答例を作ります Check Point eXqutoシリーズは、開発者の日常的な品質向上活動を支援するツールです。 ソースコード、Simulinkモデルを静的解析して得られるメトリクスを使って、 ソフトウェアの設計・実装品質の良し悪しを診断します。 オーダーメイド部分 総合演習 トレーニングでは、受講生だけで 演習に取り組みます シリーズ 問い合わせ先 株式会社 エクスモーション 主な機能 品質の定量化 スコープ別評価 品質特性別評価 モデルクローン検出 製造元 販売・サポート www.exmotion.co.jp 03-3279-0771 株式会社 エクスモーション 株式会社 東陽テクニカ ソフトウェア・ソリューション [email protected] www.exmotion.co.jp [email protected] / 03-6722-5067 34 お客様からのメッセージ エクスモーションの使命は、お客さまの開発現場に、実践的な技術を提供し続けることです。 ここでは、私たちが支援してきたお客さまから寄せられた、エクスモーションへのメッセージを掲載いたしました。 お忙しい中、ご協力いただいたみなさまには、この場を借りてお礼申し上げます。どうもありがとうございました。 これからも、みなさまのご期待にお応えできるよう、よりいっそう頑張っていきたいと思います。 （掲載は順不同） 株式会社ケーヒン 佐々木様、柴様、山本様 パナソニック ファクトリーソリューションズ株式会社 矢吹様 当社の商品に搭載されているソフトウェアが大規模化、複雑化しているため、短期間で高品質なソフトウェア開発の実現に苦心し ています。 その中でこれらの問題を改善するためにエクスモーション様と一緒に新しいアーキテクチャの構築を目指しています。 当社の現場に入り込んでいただき、現場目線で提案をしていただく取り組み姿勢に信頼感が湧きます。また、高いモデリング技術 を持ったエクスモーション様と一緒に仕事ができ、非常に勉強になっております。 これからもソフトウェア開発における様々なコンサルティングを期待しています。 富士重工業株式会社 櫻井様 弊社では、自動車開発向けにカスタマイズしたモデル開発のトレーニングを利用しました。 上流工程で考えを整理してモデルに落とし込むという方法は、日頃の量産開発で「着実に作り 込む」ことだけに注力しがちなわれわれにとっては、非常に新鮮なものでした。 考えを整理するためのウォーミングアップとして取り組んだ「思考整理トレーニング」では、「目から鱗」といった多くの気付き がありました。これからは、われわれの開発もより上流工程へとシフトしていくことが想定されており、その意味でも、上流工程の 一連の開発を体験できたことは今後に向けて有効だったと考えています。 エクスモーション様には、ソフトウェア開発の品質向上に向けて協力を 頂きました。 開発・設計者とは別の視点（第３者視点）で、見落としている改善箇所の指摘、提案を頂いています。コンサル業務だけでなく、 現場支援業務があるのはエクスモーションの「強み」だと思います。 客観的な診断だけでなく、細かな技術支援や気づきを与えてくれる事を期待しています。 セイコーエプソン株式会社 株式会社ホンダロック 田中様、谷口様 セイコーエプソンでは、モデリングやSPL等の先端技術を積極的に取り入れながら、 魅力ある製品を創り出せるエンジニアの育成に力を入れています。 エクスモーション様には、モデリング／SPLに関する教育、および弊社内のソフトウェア設計技術の体系化について支援をお願いし ました。 サービスの内容の充実度はもちろん、実案件の開始前に何度も打ち合わせを行ない、こちらのニーズをしっかりと把握した上で支 援して頂けました。また、教育受講後に現場の技術者とのディスカッションの場を設けて頂いたことがとても印象に残っています。 これらのおかげで、私たちが本当に望んでいるものを提供して頂けたと感じています。 株式会社デンソー 株式会社デンソークリエイト 宇都宮様 加藤様、田中様 エクスモーションのコンサルティングは、コンサルタントの方が同世代で、 いわゆる「先生」的でないため、議論が活発化し、当初の想像以上にエキサイティングな活動になりました。また、指導の仕方が押 しつけではなく、ホンダロックのやり方に合わせてもらったことで、現場レベルに沿った実践的な活動になったと感じています。今 回の活動を通じて、自分たちの製品仕様について、あらためて見直すことができたのは大きな成果でした。 ちょうど先日、欧州の自動車メーカーの仕様を見る機会があったのですが、支援してもらったものと同じような技術が使われてい るのを見て、自分たちの活動の意義と正しさを再確認しました。 三菱自動車工業株式会社 梶岡様 日々スピードが求められ、じっくり考えてモノ作りすることが難しくなっている 現在において、全体をしっかり俯瞰して質の高いアーキテクチャやシステムを作ることのできるエクスモーションさんのスキルは、 とても貴重だと思っています。 また、技術だけにとどまらず、ビジネスと技術をつなぐ領域まで踏み込んでもらったり、一般論ではなく現場で開発者と一緒に なって問題解決にあたるなど、その実践的な姿勢には本当に助かっています。 これからも、ぜひいろいろな面での支援を期待しています。 金田様、酒井様、高橋様 今回サポート頂いた渡辺様と三輪様は、ホームページに記載されている 『エクスモーションのこだわり』を実践されており、組織としての練度の 高さがうかがえました。当然、結果も我々の期待を上回るものでした。 （金田様） 状況・問題点などをデータやファイルとして渡し、回答・解決案をもらう コンサル形式でなく、こちらへ来社して頂き、共同作業を行いながら問題 解決・提案をして頂けました。そのため、肌で実施内容を体感でき、良い 経験となりました。（酒井様） デンソークリエイトでは、ソフトウェアプロダクトラインの技術習得に力を入れ ており、この分野を熟知しているエクスモーションさんに実践面での支援をお願い しています。 現場での適切なアドバイスはもちろんですが、プロジェクトの状況変化に臨機 応変に対応してもらえる点も、非常に助かっています。 新しい手法の導入を担当する者は、常に実務への落とし込みをどうすれば良いか悩んでいます。 例えば、要求工学の本を読んでも、数万におよぶ要求を効率的に分析し管理する方法は書いてありません。このような課題は、大小 数え切れないくらい日々生まれています。 エクスモーション様には、どのような難問でもレスポンス良く解決策を複数提案頂きました。頭のもやもやが瞬く間に晴れていく という貴重な体験をすることができました。（高橋様） 日産自動車株式会社 株式会社メタテクノ 小幡様、島田様 現場で一緒に作業をしながらわれわれの課題を共有してもらい、そこから 解決の糸口を見つけるという、極めて実践的な活動を推進してもらいました。 問題に対して形式的に答えを出すのではなく、ボトムアップでじっくりと 問題に向き合い、裏付けのある提案をいただけたことが、とても印象に 残っています。 一方、開発効率アップにつながる有効なツール類を極めて短期間で作り 上げてもらいました。（小幡様） 一般的な知識を収集することはさほど難しくありませんが、われわれが 現場で日常行っているような実業務に、それらを当てはめていくことは、とても困難な作業です。 今回、まさにそれを実施してもらい、われわれの現場に合った具体的なスタイルを構築して頂けました。また、提案してもらった ソリューションに対する説明が明快で、その提案能力とプレゼン能力の高さに感心しました。（島田様） パイオニア株式会社 35 eXmotion Solution Guide Vol.4 大森様 パイオニアでは、中堅エンジニアのスキルアップとして、 エクスモーションさんのトレーニングコースを利用しました。当初予定していた内容に加え、日頃多忙な中でなかなか出来ない参加 者個々の技術に対する棚卸しなども実施していただきました。 また、派生開発に特化したXDDPというプロセスについてのトレーニングも盛り込んでいただきました。製品が毎年モデルチェンジ を繰り返すため、度重なる派生開発に追われている弊社にとって、このフロントローディングの技術習得ができたことは大きなメ リットですし、現在進めている開発効率向上に役立つと思っています。 演習課題も、カーナビやカーオーディオといった弊社の開発対象に合わせていただき、受講者からも好評でした。 小黒様、橋詰様 我々のグループでは、これまで、このような外部サービスを受けたことはありませんでしたが、実際に利用してみて、当初の想定 以上の効果を実感できました。自分たちだけで取り組んでいると、それが正しいのか間違っているのかの評価が出来ず、その不安感 が活動の推進力を削いでしまうものですが、今回はコンサルティングを通じて「これで大丈夫！」と背中を押してもらい、大きな自 信が生まれました。また、このような外部サービスを活用することは、自分たちの世界に閉じこもりがちになるわれわれにとって、 非常に良い刺激になりました。 頻繁な日程変更にも真 に対応し、熱心に指導してくれた コンサルタントの方の姿勢も印象的でした。 筑波大学 追川様 上流はオブジェクト指向を使ったモデルを構築し、それをコードに落として リアルタイムOSやハードウェアへ搭載する。更に、形式手法を用いた先端技術 で検証する。このように、高品質なソフトウェアの作成手法と実現化手法を、上流から下流だけでなく、技術の幅も広げて教えても らえるのはエクスモーションさんならではだと思っています。 名古屋大学 森様 NCES人材育成プログラム 我々は、形式検証に関する社会人教育カリキュラムを開発するに当たって、 エクスモーションさんのコンサルタントである藤倉さんにお力をお借りしました。その結果、論理学や設計学など、最も基礎的なと ころからはじめて、最後には形式検証のプラクティカルな使い方まで学習できるカリキュラムを作ることができました。 プラクティカルな使い方を示して頂けるのは、実務で手法を実際に使い、今も手を動かして新たな手法に関して研究を続けておら れるからだと感じます。この実践性がエクスモーションさんのサービスの魅力だと思います。 36 eXmotion Solution Guide Vol.4 コンサルタント コンサルタント Yoshikazu Kono コンサルタント 河野 喜一 お客様と一緒に製品開発のあるべ き姿を検討し、効果を実感しなが らステップアップできるプロセス 改善を支援いたします。 自動車 形式検証 機能安全 Koji Yasaka シニアコンサルタント 八坂 浩司 開発現場と管理者の両方が納得す る確実なステップアップをご支援 致します ソースコード中心の改善 / Simulink モデルの作成・改善 / UML モデルの作成・改善 / ソフトウェアプロダクトライン開発に向けた総合的支援 など 自動車 プロセス改善 ソースコード改善スキル / UML モデリングスキル / ソフトウェアプロダクトラインの実践スキル など シニアスペシャリスト シニアコンサルタント 品質診断ツール 機能安全 37 38