2010年7月29日(木)のプライベートセミナー『ETの開発現場で求められている人材像と育成方法』の資料です。 講演者：岡島幸男 http://sec.tky.esm.co.jp/2010/06/29/private_seminar10/

1. 組込みソフトウェア開発に対する弊社の取り組み事例 2010/7/29 株式会社 永和システムマネジメント サービスプロバイディング事業部 組込みグループ

2. 2 組込みソフトウェア開発に対する思い 私たち永和システムマネジメントは，オブジェクト指向開発, Agile開発などへの取り組みを，金融や医療，WebなどのICT分野で実践し成果を挙げてきました． 私たちは，ICTの開発現場で培ったこれらの技術をETに適用することで，複雑化・短期化する組込み開発の現場をよりよくします． さらに私たちは，ICTとETの技術を融合することで新しい価値を生み出し，お客様のイノベーションに貢献することを目指します． ICTの技術をETに適用することで，ETの開発をよりよくします． それが私たちのビジネスミッションです．

3. 実績 ET系開発 コミュニティ活動 執筆（連載多数） Linux系開発 ETロボコン Standard (Confort/Body) Data Processing (Infotainment) Real time (Power Train) Safety (Chassis) ETでは自動車業界を中心に3年以上、LinuxではFSを中心に10年以上 3

5. プラットフォーム化・コンポーネント化に対する知見※JasParWebサイトより 制御系アプリケーション（ITS系）の開発・評価 レガシーアプリを整理し、新プラットフォームへ移行 プラットフォームおよびツール開発 RTEと呼ばれる共通化レイヤの設計・開発・評価 アプリとBSW（OSやCAN/FR）とのインタフェース

8. 非常に大きな標準化仕様(AUTOSAR）に準拠して、実用性評価を行うこと

9. 仕様の複雑さや関連チームの多さから、実現すべき機能範囲や最適化すべきポイントが不明で、開発計画の精度が見込めない

10. 対策：スクラム手法の採用による優先度ベース開発

11. 仕様ホルダがプロダクトオーナ（PO）となる。POが、機能仕様に関する優先順位付けを行い、 開発チーム側で見積もりを行う

13. 開発期間については、中間リリースを含め、大体上手くいった。作りすぎ、考慮しすぎの抑制に効果があったといえる

14. 一方、他社製モジュールとの結合テストや機能テストは（スクラム的ではなく）全体スケジュール駆動となり、上手くいかず大変だった特に、作り過ぎ・考慮しすぎなどの無駄を省くことができたのが大きい

15. 8 スクラム手法のツール バーンダウンチャート 理想線 実績線 「あとどれだけで終わるのか」、だけに注目する

16. 9 スクラム手法のツール タスクボード バグや要望対応など、発生ベースのタスクをバーンダウンとは別に管理

17. 10 スクラム手法のツール キーワードは「見える化」 バーンダウンチャートや、バックログ一覧などはハードディスクではなく、壁に

18. 11 スクラム手法のツール KPT（ケプト）ふりかえりの例 Keepしたいこと、Problemなこと、Tryしたいこと。3つの切り口で改善を促す

19. 課題 知見がない仕様(AUTOSAR）に関する開発であったため仕様の理解に時間がかかる リアルタイム制御系のミドルウェアで品質の維持を求められる 対策：ＴＤＤ（テスト駆動開発）手法の採用 ①テスト駆動による仕様の明確化 仕様の曖昧箇所を洗い出すために、テストコードベースで開発を実施 ②API仕様を網羅したテストスイート（テストセット）の準備 作成したコードで、API仕様を網羅したテストスイートを構築。合わせて、仮想環境を活用して、レポジトリベースの最新ビルド構築＆自動テスト＆テスト結果通知機構を実現（継続的インテグレーションの適用） 12 事例２（テスト駆動開発） 対象：車載用基盤ソフトウェアのミドルウェア開発

20. 13 事例２（テスト駆動開発） 対象：車載用基盤ソフトウェアのミドルウェア開発 結果、成果 ①のおかげで、少なくとも仕様や動作のグレー部分は比較的早期に検出できた。（グレー部分は、実装仕様として開発側で規定することで対応。超充実したリリースノートで補完） ②のおかげで、ドラスティックなリファクタリングを躊躇なくできた。動作速度を改善するため、実装アーキテクチャを大幅に見直し（ほぼ作り直し）をしたが、デグレは「0件」で済んだ 仮想環境は、HW依存ミドルなどは、スタブを作ることで実現。モジュール仕様が、それほどHW依存していないこともありほとんど問題はなかった。 テストケースを網羅したテスト資産は、後々まで役にたつことを実感

21. 課題 （お客様の）ソフト内製化に伴い、業務全体の見直しが必要 ソフトに関するノウハウが失われ、設計方法やプロセスを再構築する必要がある 対策：UMLの採用によるソフト仕様の見える化 現場での改善提案（UMLの採用によるソフト設計の見える化） 要求分析から、基本設計まで、幅広くUMLを導入 シーケンス図、アクティビティ図、コンポーネント図などを主に利用 （UMLではないが）DFD（データフローダイアログ）も活用（データの流れの整理に有用） ※ 単にUMLの図を一通りそろえるだけでなく、目的に沿った記法の活用が大事。 14 事例３（UMLによる見える化） 対象：車載ECUソフト開発の支援業務

22. 15 事例３（UMLによる見える化） 対象：車載ECUソフト開発の支援業務 結果、成果 お客様からは、UML・DFDとも分かりやすいとの評価 お客様自身もUMLのユーザーとなり、ドキュメント標準への盛り込みに向け前進 詳細設計以降のフェーズに向け、どのようにUMLなどを適用できるかは今後の検討課題 UMLなどのオブジェクト指向技術は組込み開発でも利用可能だが、現場に合わせたカスタマイズ・チューニングが肝要