組み込み開発におけるアジャイル事例 · 2013-05-24 ·...

Copyright(C) 2013 OGIS-RI Co., Ltd. All rights reserved.

組み込み開発におけるアジャイル事例 KELK様ソフトウェア開発プロジェクト

～組み込み分野のアジャイル開発適用ノウハウ～

株式会社オージス総研

組み込みソリューション第一部

マネジャー阿左美勝

Ver 1.4 1


はじめに

• アジャイル開発にどんなイメージをお持ちですか？

– 一部のお客様や開発者は、縛りの少ない、楽な開発をイメージしている

• あいまいな要求でも開発着手（発注側）

• 包括的なドキュメントよりも動くソフトウェアが重要（開発側）

• 計画に従うよりも変化への対応が重要（開発側）

• アジャイルに対する「ゆるい」イメージを払拭したい

– 条件がそろうと、とても効率の良い開発が可能

• できるメンバーによる短期開発の実現

プラクティス

原則

価値今回は、小規模な組み込みソフトウェア開発に、アジャイルのメンタル面を適用した事例を紹介します

2


目次

• プロジェクト概要

• アジャイル開発の適用動機

• 成功に向けた取り組み

– 製品を知る

– 目的の共有と変化への対応

– チーム一丸となって

– 順次達成

• まとめ

3


プロジェクト概要

• プロジェクトゴール – 3kwのケミカルサーキュレータから144kwの

純水加熱装置にいたるまでの10程度の製品種別カテゴリ、100機種以上もある「温調機」シリーズ製品の「共通フレームワーク基盤」を開発し、お客様が自分たちで派生開発を進められる状態

温調機の一例

4

• お客様

– 株式会社KELK （ http://www.kelk.co.jp ）

• 株式会社小松製作所のグループ企業。半導体製造装置に搭載される高精度温調機器の分野において圧倒的なシェアを有するリーディングカンパニー

• 事業内容：

ペルチェ素子(温調・熱電発電)の開発/製造/販売

ペルチェモジュール等を用いた温調機器製品の開発/製造/販売

4

http://www.kelk.co.jp/


アジャイル開発の適用動機

• プロジェクトの難しさ

– 当初の見積では約1年間かかるプロジェクトを、約半年という短期間で仕上げる

• 機種に応じた共通/変動の切り分けには、製品に精通したドメインエキスパートが必須

– 明確な完遂基準がない

• 通常の製品開発はソフトウェアが機能要件を満足すれば完了

• お客様が自立して派生開発する状態を目指すためには…

お客様の巻き込みが不可欠・短期間の開発・ゴールは製品リリースではなく、お客様が自立して派生開発する状態

その克服には？

5


成功に向けた取り組み

背景

製品を知る

目的の共有と変化への対応

順次達成

チーム一丸となって

Ｗｉｎ！

お客様の巻き込みが不可欠・短期間の開発・ゴールは製品リリースではなく、お客様が自立して派生開発する状態

6


製品を知る

• 開発者は製品を知ろうとするスタンスが大切

– 参画初日に初期メンバー3名が、現物の温調機を見せていただくよう依頼しお客様が快諾

• いくつかの温調機を見学したが、純水加熱装置は感動もの

• 装置動作の様が、今でも鮮明に残っている

– 製品カタログを見たり、お客様から開発対象をヒアリングしたりするだけでなく、現物自体に関心を持つことが重要

• お客様の安心感、当社に対する信頼にもつながる

• お客様は製品を良く知った開発者が開発することを期待

– メーカーの方は自社製品に思い入れ・愛着を持っている

• 親（開発者）と子（製品）の関係に近い

製品を知る


順次達成


7



• チーム内で目標を共有し続けた

– プロジェクトの目標はモノ（ソフトウェア）の完成ではない

– 共通フレームワーク基盤を作り、それをお客様が利用できる状態をつくり上げること

メンバーの目線を常に一段高いところに保った

• 変化が発生し対応が必要なときは…

– 常に、高い位置の目標に立ち返ってみんなで議論し判断した

– この開発では、モノとしてのソフトウェアは目的達成手段の一つでしかない

製品を知る


順次達成


8


費用対効果のパターン

• リソースに合わせてゴールを変動

or

• ゴールに合わせてリソースを変動

リソース（人、時間）

ゴール

← 今回はこちら

9


プロジェクト指向のマインド

1. 当社の進捗報告

2. プロジェクトへの影響把握

3. 対策の検討

4. 成果物の変更検討

5. 決定

6. 実施

すり合わせ

時間開始

• 限られたリソースの中でプロジェクトの成果物としてのゴールは常に変動

• それをお客様と共有し続け、当社の問題でも、お客様の問題でもなく、プロジェクトの問題を皆で議論

このときに垣根を作らない！

朝令暮改（朝令夕改）と言って騒がない！

10



• お客様管理層も含めチーム全員が、日々Face-to-Faceですり合わせながらソフトウェアの最適解を具体化していった

• リーダー・設計者・実装者等のロールを随時行き来した

– 個人の役割区分は曖昧

• 組み込みでは、ハードウェア・ソフトウェア担当の垣根を無くし、一緒に課題解決することが早道

– ソフト屋が回路図を見てハード屋に質問するなど、ハードウェアの領域へも踏み込んでいった

製品を知る


順次達成


11


Face-to-Faceのすり合わせ環境

12

モデル

お客様席

当社メンバ席

ホワイトボードが大活躍

お客様席と当社メンバ席の真ん中に打ち合わせスペース


順次達成

開発ロードマップ（温調機「高温機」プロジェクトの大日程）

混沌の立ち上げ期実装量産の多忙期

活動ロードマップ

お客様の信頼を獲得すべく、設計の具体化に注力。お客様と作るべきモノのイメージをすり合わせる日々。

他パートナーとInterface洗練

大粒度の役割分担から全体構成と振る舞いを方向付け

成果提示の模索期

複数の部分モジュールを深堀しつつ、全体⇔部分の整合性も合わせて確認

実装完遂する能力がある事を示す。設計を実装に落とし込むだけでなく、実行環境上の性能・効率面も評価し提示する。

当社の付加価値を出すべく、共通化・保守の良さをお客様開発メンバーが共感できる形に仕上げる。

ハード基板入手総合テスト完了

お客様開発メンバーと一緒に開発

派生開発のためのドキュメント作成＋レビュー

作成都度、ハード基板（チェッカー）で動作確認

コーディング規則勉強会参加（30分/週）

総合テスト開始基本動作確認完了

実行環境（OSとMPU）のリソース効率やコンパイラ特性を調査し、実装を最適化

2011/12 ～ 2012/1末（2ヶ月間）

2012/2 ～ 4末（3ヶ月間）

2012/5 ～ 6末（2ヶ月間）

製品を知る


順次達成


13


組み込み特有の実機動作の遅延を克服

• 組み込みでは、ハード基板（チェッカー）が無いとシステム上の動作確認ができない

– エンタプライズのように早期の継続的統合と継続的デリバリできない背景が、実現への不安を助長する

– ハード基板上の動作が不安を確信に変える

• プロジェクトの雰囲気ががらりと変わる

• 一度デリバリ可能なソフトウェアを確立してしまえば、プロジェクトが軌道に乗る

• ソフトウェアがハード基板上で、難なく動くコツは準備にあり

– 単体テストとシナリオベースの結合テストで、PC上の継続的テストを着実に進めておく

14

スムーズに移行

ハード基板 PC

PC上でソースコードを論理検証しておく仕込みが有効


進め方のコツ

KELK様オージス総研

お客様

ヒアリング

当社メンバー

一般解を作成全体設計（一般解）

各種ドキュメント閲覧

現行製品・チェッカー知る

全体設計（最適解）

一般解をベースにしてすり合わせ、合意形成しながら一緒に最適解を導き出す

メーカ内部メンバーは現行設計に対する思い入れが強く、既存構成を壊すことに躊躇しがち一般解の提示は外部支援ならではのメリットです

15


初期の目的共有にモデルが有益

• お客様のヒアリング内容を要求図にして視覚化

– お客様の懸念事項をどの辺りで解決予定か、ノートで注記を加える

– お客様に要求図の見方を全く説明せずとも、瞬時に理解し議論可能な状態へ

• これが初期の目的共有と、お客様の懸念払拭に大きく役立った

16


しっかりしたアーキテクチャを作り、それを崩さない

• 変更を許容するためには設計に芯が必要

– 大粒度の役割分担をパッケージング • レイヤとパーティションによる分割とInterfaceによる疎結合

– 上位レイヤが意思決定した状態駆動に応じ、下位レイヤが動作するアーキテクチャを採用

• 現行ソフトウェア・現場の状況から状態遷移の把握と整理が今回のソフトウェアのキモであると判断

• 設計変更が必要になるとアーキテクチャを基準に検討

– アーキテクチャを崩していないか？

– アーキテクチャを変えたくなった場合、安易な変更をしようとしていないか？

結果的にアーキテクチャが変わることはなかった

17


アジャイルとモデリングの相性は抜群

• 対話（話や文章）だけでなく、構想を描いた設計図を活用し、双方の解釈を同じレベルにする

18

お客様当社

対話＋モデル

ソースコード

: A : C

: E

1: 2:

C

A

D

B

1..n1 1..n1

E

1

1..n

1

1..n

UseCase#1

user

UseCase#2

SysMLやUMLのモデル

• 単なる設計図ではなく、すり合わせを通じて把握した課題の解決策をモデルに込める

• 現時点で判断できないことは、モデルに不明点を可視化＋仮決めして進める

開発上流で品質を確保し、高品質の実装に貢献

ホワイトボードの手書きモデルで十分に意思疎通が可能


短い開発サイクルの実現

• サイクルは1日～5日程度

– 要件定義～設計～実装～テスト

– ロジック部分は、CppUnitによる単体テストで動作保証

– ハードウェア制御は、基板＋チェッカーによる検証

ハードウェアを含めた結合を継続的に実施

• メトリクスを計測し、ソフトウェアの成長を把握

– 短いサイクルによりソフトウェアが日々変化する

– メトリクス計測によって予想外の方向にソフトウェアが成長していないことを把握した

• ROM/RAM, スタック使用量

• 実行速度

• MISRA-C++ による静的チェック

変化を把握できている安心感

19


支援後の運用（お客様の声）

• 「共通フレームワーク基盤」がレイヤ毎の担当者アサインを可能にし、チームワーク重視の派生開発体制へと変革

20

Before After


支援後の成果（お客様の声）

21

成果 Before After

ソフトウェア品質アップ

品質確保のウエイトが担当者一人に偏りがち

機能追加の際、複数の担当者の目で品質確保

開発期間の短縮機能毎に属人化しており、シリアル開発せざるを得ない

レイヤ毎のパラレル開発による開発効率アップ（操作パネルの機能追加時に工期半減）

チーム開発力アップ

まとめ役が全機能の開発に深く関与

一人一人が担当レイヤに責任感を持つ

開発チーム内の横連携が希薄になりがち

機能追加の際、各レイヤ担当者が能動的にコミュニケーション


プロセスやツールよりも個人と対話

包括的なドキュメントよりも動くソフトウェア

契約交渉よりもお客様との協調

計画に従うよりも変化への対応

製品を知る


順次達成


開発プロセスや会議体ありきではなく、お客様との日々のFace-to-Faceの議論の中ですり合わせながら機種開発の最適解を具体化していった

他プロジェクト状況によるお客様の忙しさ、当社外の要員が開発している別モジュールの進捗状況を見ながら、適時、目的に最短到達する計画を相談・見直しした

当社がどこまで対応する/しないの契約的な線引よりも、お客様と協調しインクリメンタルにゴールを目指した

実装に必要な最低限の設計ドキュメントのみ作成し、動くソフトウェアの早期リリースに注力した（現物主義）ドキュメントはお客様が有効利用でき、継続的なメンテナンスができる最小限の保守ドキュメントを作成した

アジャイル開発宣言（4つの価値）とマッピング http://agilemanifesto.org/iso/ja/

22

まとめ

http://agilemanifesto.org/iso/ja/


まとめ（アジャイル開発からの学び）

• 適用条件

– アジャイル開発は「お客様の関与度合い」と「プロジェクトの性格」を選ぶ

• 製品に精通したお客様の積極的な参画が必須

• Ｒ＆Ｄやプロトタイピング時期に有効

– プロジェクトのコンセプトは共有の上、その具体化を合意形成（その時点の最適解を仮決め）しながら進める

• 成功条件

– アジャイル開発は「人」を選ぶ

• ゴールイメージを共有し続けられるメンバー

• 開発目標に向かい能動的に動けるメンバー

• お客様と成果物をこまめにすり合わせ・合意形成できるメンバー

23

組み込み開発におけるアジャイル事例 · 2013-05-24 ·...

Documents