※ UML、Unified Modeling LanguageはOMG（Object Management Group）の商標です

※ 記載されている社名、製品名は各社の商標または登録商標です

株式会社オージス総研

モデルベース開発導入を通じて、ソフトウェアの品質向上に繋がる改善のコツが掴めた！

日本電子株式会社様の事例より

2

目次目次

１．開発の背景

２．開発の内容

３．成果

４．まとめ

※ UML、Unified Modeling LanguageはOMG（Object Management Group）の商標です

※ 記載されている社名、製品名は各社の商標または登録商標です

１．開発の背景

4

開発製品の概要開発製品の概要

電子顕微鏡

観察する対象に電子（電子線）をあてて拡大する顕微鏡

今回の開発対象は、電子顕微鏡のハードウェアを制御するファームウェア

5

開発する上での難しさ開発する上での難しさ

製品のバリエーションが多い

市場のニーズに応じて複数のシリーズ製品を展開しており、製品ごとの仕様（電子銃、レンズ系、検出器、試料ステージ）の違いに対応する必要がある

製品のライフサイクルが長い

保守が長期に渡り、その間頻繁に発生する客先個別要求への対応が必要

6

現状の問題点現状の問題点

システムが小規模だった頃のやり方をひきずった従来型の開発

機種毎に存在するソースコード·それぞれが個別にバージョンアップされていく 納期遅延が慢性化

保守や拡張が困難

多機種を少人数で掛け持ち

·複数機種を並行開発·リーダも複数プロジェクトを兼務

知識が属人化

·ドメイン知識は個人に埋没·設計書はあるが実装と乖離

→作った人しかわからない新メンバ加入時の障壁にも・・・

→機種展開を繰り返すうちに、似て非なるソースコードが増殖

→リソースの競合、詰め込みスケジュール

→見通しを立ててソフトウェアを追加・修正できない

7

今回の開発の狙い今回の開発の狙い

目標ソフトウェアの品質を向上する

少人数・短期間での多機種展開を実現する

施策オブジェクト指向/UMLによるファームウェアの見える化

再利用可能なソフトウェアプラットフォームの構築

テスト工程における論理検証の自動化

トレーニング受講や勉強会の実施による開発者のスキルアップ

開発プロセスの改善（開発ツールの活用、ガイドラインや規約の整備、プロジェクト管理）

繰り返し型開発の導入とeUML（組み込みUML）の適用

※ UML、Unified Modeling LanguageはOMG（Object Management Group）の商標です

※ 記載されている社名、製品名は各社の商標または登録商標です

２．開発の内容

9

開発の概要開発の概要

体制開発リーダ：日本電子様 1名開発メンバ：日本電子様 4～6名コンサルタント：OGIS 1名

開発期間試作納品まで17ヶ月、量産リリースまで12ヶ月

既存システム（C言語）の規模

実ステップ数：78Kステップ

総ステップ数：102Kステップ

10

取り組みの内容取り組みの内容

ファームウェアの見える化

論理検証の自動化

開発者のスキルアップ

業務ドメインとソフトウェアプラットフォームの分離

ガイドライン・規約によるルール化

プロジェクト状況の可視化

11

ファームウェアの見える化ファームウェアの見える化

モデル上で機能と構造をじっくり整理

「なぜそのようにしているのか？」を追求

まずはドメインとサブシステムで大中区分し構成を検討機種で共通、固有の部分の見極め

必要な部分に限定してオブジェクト指向で開発CとC++のハイブリッド型

製品A

製品AA

製品AAA

製品A・・・

製品A・・・

製品A・・・

12

業務ドメインとソフトウェアプラットフォームの分離業務ドメインとソフトウェアプラットフォームの分離

汎用的なプラットフォームを並行して開発

ソフトウェア構成、及び、要員を業務ドメインから分離その分野に長けた精鋭メンバを専任化し、高機能で再利用性の高いメカニズムを作成

業務ドメインの分析・設計工程と並行開発し、開発効率アップ

アーキテクチャメカニズム設計・実装

業務ドメインチーム

プラットフォームチーム

要求分析 分析 アーキテクチャ設計

設計 実装

アーキテクチャメカニズムをインポート

13

論理検証の自動化論理検証の自動化

テスティングフレームワーク（CPP-Unit）を用いた回帰・自動テストを実施

ユニットテストを利用した回帰テスト

フレームワークにより、複数テストの実行、テストの簡易化、形式統一を実現

テストコードでパラメータ範囲や実装ロジックの確認を自動化することで、開発者の負担を削減

テストコード

PCPC上で簡単に検証可能上で簡単に検証可能

TestCase<<CPPUnit>>

ATestA

被テストクラス テストクラス

Failure!

14

開発者のスキルアップ開発者のスキルアップ

ニーズ・レベルに合わせた教育メニューを実施

開発開始前に・・・『オブジェクト指向分析・設計トレーニング』で作業イメージを理解・把握

分析力強化に・・・OGIS社内で効果検証された『モデリング勉強会』で分析力を向上

設計力強化に・・・『デザインパターン勉強会Part1』で、組込みでよく使われるパターンを学習

Part2では応用力を磨き、設計バリエーションを広げる

他チームのメンバも参加し、学習の輪が広がる！学習の輪が広がる！

15

ガイドライン・規約によるルール化ガイドライン・規約によるルール化

初めての作業（オブジェクト指向開発、ツールやソフトウェアプラットフォームの利用）の効率を向上

学習作業前に規約・ガイドラインを説明

ここでしっかり作業イメージを作っておくことがポイント

「なぜそうするのか？」を各人が理解した上で作業に臨む

体験実際に作業してみる

始めはコンサルと一緒に作業し、一通り体験する

その都度コンサルがチェックし、作業中の疑問を解消

作業してみた結果をフィードバック実際に作業して気づいたことをルールに反映する

ルールも人も進化し、着実に作業が効率化する振り返り

16

プロジェクト状況の可視化プロジェクト状況の可視化

「目標の明確化」+「繰り返し」で見通しの良い開発

作業のブレイクダウンと積み上げ形式でスケジュール

近いマイルストーンごとに『手が届く目標』を決める

イテレーション毎の反省会で課題を抽出し、次の活動へつなげる

早期のイテレーションでなるべく早く骨格を作ることで、今後の作業とそれに要する期間が見通せるようになる

要求分析 分析 アーキテクチャ設計

設計 実装

反省会

※ UML、Unified Modeling LanguageはOMG（Object Management Group）の商標です

※ 記載されている社名、製品名は各社の商標または登録商標です

３．成果

18

×設計書と実装の乖離

×複雑な対象をすぐに設計

【従来】

◎UMLによるドキュメント化

【現在】

ケースツールの活用により、モデルと実装が一致

◎モデルを使って分析

！現場が感じた具体的な効果（開発者の声）

『出来上がったモデルから共通部分を切り出すことも可能になるので、開発効率の向上が期待できそう』

UMLによるファームウェアの見える化UMLによるファームウェアの見える化

理解及び変更が困難機種毎に似て非なるソースコードが増殖

設計書はあるがあてにならない

動かす前に品質が分かる機種共通・変動の見極めに貢献

『なぜそうするのか？が分からない部分があることに気づけた』

19

×アーキテクチャメカニズムを一から設計

【従来】

◎汎用性の高いアーキテクチャメカニズムを構築

【現在】

同一実行環境・制約における再利用が可能に

！現場が感じた具体的な効果（開発者の声）

製品ごとのメカニズム整備されたものはない

『ファームならではの手の届きにくいテストをOSラッパーを使ってWindows上で行えたのは便利だった』

OS部分がラップされ、Win32環境でのテストが容易に

『多機種展開やシミュレータ作成の開発生産性の向上に期待している』

業務ドメインとソフトウェアプラットフォームの分離業務ドメインとソフトウェアプラットフォームの分離

20

×実機で初めてバグが見つかる

【従来】

◎PC上での自動テスト

【現在】

動かす前に簡単に論理検証が可能パラメータ範囲チェック、ロジックチェックの自動化で更に簡単にテストが可能

◎ユニットテストを利用した回帰テスト

！現場が感じた具体的な効果（開発者の声）

ケアレスミスも実機で発見

機能追加時のバグ混入を防止

論理検証の自動化論理検証の自動化

×実装品質を確保するのが困難ソースコードレビューはやっているが・・・

『機能追加時に全機能の再テストを自動で行えるので、従来の機能に影響を与えていないかすぐ分かる』

『テストの自動化によりテスト結果が瞬時に分かるので楽になった』

『多くのテストパターンでテストできるようになった』

21

×スキルアップの機会がない

【従来】

◎勉強会を運営し、学んだ知識を実践で活用

【現在】

分析力モデルで品質を見極める力設計手法を数多く身につける品質の高い実装

！現場が感じた具体的な効果（開発者の声）

開発者のスキルアップ開発者のスキルアップ

先人のやり方をなんとなく踏襲

開発者のモチベーション低下

『現場の実践における成功体験が次のモチベーションになる』

『開発チーム全体の技術レベルの底上げが実現できた』

『設計レビュー時に一から説明しなくて済むようになった』

22

×ガイドライン・規約がない（もしくは形骸化している）

【従来】

◎ガイドライン・規約が整備され、活用されている

【現在】

作業ガイドラインツール利用ガイドラインモデリング規約、コーディング規約個人のノウハウも蓄積された

！現場が感じた具体的な効果（開発者の声）

ガイドライン・規約によるルール化ガイドライン・規約によるルール化

『ガイドラインにより迷わず作業を進めることができた』

『新メンバ加入時に活用できる』

『他の開発者が作成したモデルやソースコードが理解しやすくなった』

23

×勘と納期で決まる見積もり

【従来】

◎繰り返し+積み上げ方式の見積もり

【現在】

予定と実績比較し、見積精度が向上マイルストンごとに目標を立てるのでメンバの意識あわせが容易に

！現場が感じた具体的な効果（開発者の声）

妥当性がチェックされず、スケジュール遅延が慢性化

プロジェクト状況の可視化プロジェクト状況の可視化

×個人の作業状況・進捗が不透明複数プロジェクトを掛け持ちしており、何をやっているかわからない

『日程の遅れが目で見て分かるので目標を達成しようとする意識が高まった』

『問題が早期に発見できるので早めの対処が可能だった』

24

品質測定結果品質測定結果

測定方法

弊社標準のケースツールによりソースコードの品質を測定

測定結果

新システムは総じて品質が高い結果となった

元々旧システムの品質がさほど悪くなかったため、劇的な改善は見られなかった

新システムで信頼性が向上した予想されるバグの数をパスや語彙数（C++は語彙数のみ）から判断

020406080

100

機能性

信頼性

保守性

テスト容易性

理解容易性

再利用性

新旧

※ UML、Unified Modeling LanguageはOMG（Object Management Group）の商標です

※ 記載されている社名、製品名は各社の商標または登録商標です

４．まとめ

26

当初目的に対する評価当初目的に対する評価

今回の取り組みにより、ソフトウェアの品質向上に繋がった！モデルベース開発、テストの自動化、開発者のスキルアップが達成できた

多機種展開のベースとなるソフトウェアが構築できた！再利用可能なアーキテクチャメカニズムの構築、ガイドライン・規約によるルール化が達成できた

27

お客様の声お客様の声

『今回の取り組みでは、オブジェクト指向を中心とした新しい開発手法を取り入れ、ソフトウェアが新しくなっただけでなく、技術者のスキルもあげることができた』

『今後開発する製品のベースとなるソフトウェアが構築できたことに十分な成果を感じている』

『今回開発したソフトウェアをベースとし、さらなる新製品の開発を行い、今回の取り組みの目標を達成させたい』

今回の経験を活かし、現場で改善活動を継続中

28

コンサルタントのコメントコンサルタントのコメント

『できるところから少しずつ“見える化”する』いきなりシステム全てを再構築しない。小さな範囲で成功体験を繰り返し、改善の輪を広げていくことがポイント

『個人任せでなく組織でルール化することが大切』規約・ガイドラインの周知徹底が、個人品質のばらつきを防ぐ

『人の品質を上げることがソフトウェアの品質向上に繋がる』

トレーニング、勉強会、そして実践でスキルアップできる環境が、エンジニアのモチベーションアップを促進

技術・プロセス・組織の3本柱をバランスよく改善することが大切

※ UML、Unified Modeling LanguageはOMG（Object Management Group）の商標です

※ 記載されている社名、製品名は各社の商標または登録商標です

おわり

～モデルベース開発導入を通じて、ソフトウェアの品質向上に繋がる改善のコツが掴めた！～

日本電子株式会社様の事例より

株式会社オージス総研