元 組込み系システム開発エンジニアの いとけん です。今はクラウドのシステム開発をスクラムで行っています。
この記事では、ずいぶん昔に私が組込み系システム開発のソフトウェア開発リーダーを行っていた時の経験が、今思えば割とスクラム的だったので、どんな特徴があったのか、どんな条件だったら組込み系のシステム開発でもスクラムが上手く回せそうか、そのあたりを改めて振返ってみたいと思います。
組込み系システム開発で良く使われる用語の解説を含めながらのため、前置きが長いです。。。知ってるよ！というところは読み飛ばしてくれると幸いです。
組込み系システムとは「特定の機能を実現するために製品や装置に組み込まれるコンピュータシステム」のことを指します。例えば、テレビや冷蔵庫、自動車や医療機器、近年ではIoT機器など、身近なもの殆どに入っています。端的に言うと、製品専用のハードウェア(以下、HW)を持っていることが特徴になります。
今でこそ出荷後にソフトウェア(以下、SW)更新ができる製品も増えてきましたが、基本的には出荷後の更新は難しいので、出荷後に不具合が出ないよう細心の注意をして開発を進めます。
(製品によっては、市場に出回った製品を回収し、SW更新をしてからお客様にお返しします。お客様にご不便もかけ、かつ人件費も膨大にかかります。)
また、多品種少量生産の製品においては、1つのベースモデルを作ったら改造＆改造で新製品を開発(派生開発)していきます。あわせて、開発期間も短くしたいので、HWとSWの同時開発(コンカレント開発)がしばしば行われます。その他にも、一般的なシステム開発のように開発途中に機能追加や変更が行われたりすることも当然あり変更管理が必要です。
ちなみに「組み込み」だったり「組込み系」だったり、英語で「エンベデッド」と書いたり、公式な所でも余り統一されていません。
私は長年、自動車向けの組込みSW開発を担当していたので、それを例にとって派生開発に求められる要求を整理してみようと思います。
完成車メーカー(以下、メーカー)は、色々な車種を世界中で販売していて、車種ごとにグレード(高級、廉価など)も存在する、多品種少量生産システムです。そして、新車の発売時期はまちまちなため、開発現場としては企画段階のモデルから生産直前のモデルまで、開発工程もまちまちになります。
また、自動車は数多くの部品(情報機器も無数に組み込まれています)から成り立っているので、数多くの部品メーカー(以下、サプライヤ)がメーカーに部品を納めています。いわゆる”系列”に属さない企業もサプライヤとして多数参加しているので、1つのサプライヤが複数のメーカーの製品を作ることも良くあります。そのため、メーカーとサプライヤ同士が協業して、仕様調整や結合試験、試作車での性能試験を行って改良していくことも多々あります。
サプライヤ自身も、開発を高速化するためコンカレント開発を行い、HWとSWの間で複数回の結合試験を行う必要も出てきます。
これらを、効率よく管理しながら開発するために、派生開発には以下のような要求が出てきます。(私は、サプライヤの立場で開発に参加していたので、その目線で)
- 各国の法規制や規格への対応などは、メーカーを跨いで共通で開発したい
- メーカー毎の標準仕様は、メーカー単位で共通化したい
- 開発初期(企画検討段階)でも開発後期(生産直前)でも、然るべき品質を保持したい
- メーカー・サプライヤ間、コンカレント開発向けの機能限定リリースもタイムリーに行いたい
派生開発は、当初は単純に母体とするSWをどれにするかだけ特定し、それをベースに差分開発を行っていましたが、だんだん混乱をきたすようになってきました。
そこで出てきたのが、ソフトウェアプロダクトライン(Software Product Line:SPL)開発という考え方です。簡単にイメージで書くと、以下のような感じです。
単純に、以前開発したモデルを母体にして、新しい機能を追加したり、要らない機能を削除したり、他から移植したりしながら開発します。これから開発するモデルの母体の選定は、類似性の高さ(≒開発費の小ささ)のみなので、無秩序に枝葉が伸びていきコントロールが難しくなります。
とくに、(テストされて品質が一定水準を超えている)既に製品化されたモデルを母体にする時は良いですが、充分な開発期間が取れないため開発中のモデルを母体にする時は、不具合修正版の横展開がコンフリクトするなど、開発が混乱してきます。
開発モデルの進化(樹形図)は、広葉樹のように広がっていき、移植なども発生するため、樹形図がスパゲッティ化していきます。
複数の製品で共通で使用され、かつ仕様の変化が小さい部分からコンポーネント単位で部品化します。
例えばカーナビであれば、ルート検索エンジンやアンプ制御機能、デバイスドライバなどが該当し、標準仕様のAPIをシステムに提供する形で部品化されます。これらが上手くいくと、これらを利用するミドル層・アプリ層の一部も部品化されていきます。
このように部品化されたコンポーネントをSPLでは「コア資産」と呼びます。
コア資産自体も、製品群の成長と共に成長していきますが、基本的には一直線に(複数の製品の機能を包含した状態)成長していきます。製品の最終リリース前などで、関連の無い機能を入れたくない等で枝分かれはしますが、すぐメインにマージされる形で管理されます。従って樹形図は針葉樹のようになります。
一方で、複数の製品の機能を包含した状態になるため、ソースコードが複雑になりがちという欠点も持っていて、製品ごとにどのように機能を制御するか等の設計ポリシーが重要になります。つまり、「製品群(≒プロダクトライン)」という目線での開発戦略を持つことになります。
前置きがとーーーっても長くなりました。やっと本題です。
私が担当していたSWコンポーネントは、全ての製品で使用され各メーカーや周辺機器ごとに同じ機能を提供するにも動作シーケンスが異なる、コア資産に当たるものでした。5個のメーカーに跨った20車種程度、対応する国や地域も含めると40機種ぐらいの同時開発でした。開発期間中にも、機種が増えていくなどしていたので、具体的に何機種だったかまでは覚えていません。
各製品開発チームから五月雨に発生する要求仕様を、各製品ごとの目的のリリースに向けて機能実装していきます。前述のとおり、企画検討フェーズから結合試験フェーズ、出荷直前(工場生産)フェーズの製品まであります。その結果、コンスタントに週に2-3回はリリースを行わなければならない状態でした。
チーム体制は、以下の図の通りです。
ロール名はスクラムに置き換えて記載しています。(当時はスクラムをやろうと意図していないので、スクラムに無いロールも登場しています)
当時、私が行っていたプロジェクト運営を、各スクラムイベントになぞらえて紹介します。
- スプリント期間：
1ヶ月。我々のお客様(サプライヤ)とは、1か月ごとの契約だったためです。(但し、リリースは月に10回以上です)
1ヶ月というスプリント期間は長めですが、暦と契約とスプリントが一致するのでチームにリズムを生みやすく運営しやすかったです。スプリントとリリースの回数を一致させない形での運営だったため、長めのスプリントでも成立していたのかもしれません。(あくまでも計画のサイクル) - スプリント計画：
月末に来月の計画(リリース計画と実装機能および作業)の精査と合意を行っていました。当時は、PO(お客様)とSM(私)の2名で行っていて開発チームは関わっていませんでした。
ここは、月ごとの顧客との契約と直結していたためリーダーが行う(責任を取る)必要がありましたが、スクラムでやると宣言＆合意できていたら変えられたかもしれません。合意できていたらメンバーを巻込んだ方が納得感が出るため良かったと感じています。 - リファインメント：
要件管理/変更管理として行っていました。見積りと作業定義/完了基準の定義(Doneの定義)を、SM(私)とTL(自社)の2名で行い、リリースイベントと実装機能をリストで管理していました。月中での仕様変更の依頼も余程の緊急でない限りは、来スプリントに回します。今スプリントに入れる場合もその工数分の機能実装は来スプリントに回します。
こちらは契約に関係なく、メンバーを巻込んだ方がメンバーに”当事者意識”を持ってもらえただろうし、技術者の育成面でも良かったと感じています。一方で、ポリシーを持った開発戦略という面ではテックリードに頼るため、テックリードに与える(公式・非公式な)権限のバランスが難しそうです。 - デイリースクラム：
前日夜に作業日報メールを開発者から貰い、当日早朝にSM(私)が作業依頼とリカバリー策を提示していました。正しい報告を求めていたので、遅れたりトラブルでも叱ることはせず、誰がいつ助けにいくよ！といった感じでやってました。
最初のうちはぎこちなかったものの、どんどん本音で事実を報告してくれるようになったので、心理的安全性は保たれていたと思います。(思いたい！) - スプリントレビュー：
とくにやってなかったです。週に2-3回もリリースがあり、リリース後に各製品プロジェクト側からの不具合指摘が無ければ OK な感じです。 - レトロスペクティブ：
とくにやってなかったです。今おもえば純粋にやっておけばよかったな。。。と思います。
スプリントが1カ月と長めで月初に起きたことを忘れてしまうことも多いと思うので、毎週or隔週でやるのが良いと思います。
どうでしょうか。
当時はスクラムをやろうという意識も知識も持たずやっていたので、ヒエラルキカルなチームでしたが、スクラムでやると宣言＆合意できていれば、もっと自律的なチームを作れたんじゃないかなと思います。
スクラム開発自体は、できそうです。が、工夫がいること・できないことも見えてきました。
- 顧客は誰なのか：
真の顧客は車を買ったコンシューマですが、開発中にフィードバックを貰えることは時間軸的に無理ですし、メーカーの意向も大きいです。コア資産開発の立場としては「与えられた仕様」を「目的のリリース」に「適切な品質」で届ける以上のアプローチは難しいと感じています。各製品開発チーム側の立場だったら、メーカーを顧客と見立てることができるかも知れません。 - ドキュメントは減らない：
自動車など安全性の問われる組込みシステムの場合、近年では何らかの規格の認証を取る必要があります。メーカーやサプライヤの品質保証部門が構築した認証取得プロセスに則る必要があり、ドキュメントの軽量化や削減は難しいでしょう。 - 1スプリントに入らないものもある：
HWとSWのコンカレント開発が行われることが多いので、HWの完成を待つなどが発生します。
従って、要求(仕様)が確定し設計は先に実施しておくけど、HWを入手するまで実装はしない、、、などのコントロールが必要になります。 - やっぱりテストはつらい：
組込みシステム開発では、製品の試作機や計測機器、GUIツールを使ったテストが多いことで自動化が難しく、テストに明け暮れることがあります。CI/CDツールとRPAを組み合わせた自動化や、試作機側にデバッグ機能を事前に仕込んでおき結合テストも自動化するなどの工夫が必要そうです。 - テックリードは必要：
SPLでは、下方互換や多機種同時対応のため、どうしてもソースコードが複雑になりがちです。
かつ、コア資産には設計の安定性(ポリシー)が無いとプロジェクトが混乱するため、対象コンポーネントの責務(スコープ)や、製品プロジェクト側の仕様やその背景を理解している技術者が、設計をコントロールしていく必要があると思います。 - 技術者スキルに合わせた計画が必要：
1つの小さな機能を数日間で設計～実装～テストまで終わらせる必要がありますが、若手技術者が全て自力で対応するのは困難です。従って、若手であれば「詳細設計⇒レビュー⇒実装⇒レビュー⇒テスト⇒レビュー」、中堅技術者であれば「基本設計⇒レビュー⇒詳細設計＆実装＆テスト⇒レビュー」とするなど、スキルに合わせた計画が必要です。(これは組込み特有…じゃないですけどね)
組込みシステム開発の場合、本当の顧客(利用者＝コンシューマ)が時間軸的にも商流的にも離れていることが多いため、スクラム開発「だけ」でビジネスアジリティを上げるのは難しいと思います。
しかし多品種同時開発を実現するためにSPLを導入したことにより、SWコンポーネントは「漸進的に成長」し「タイムリーにデリバリー」されるものになりました。結果として組込みシステム開発もスクラムの要素を多分に持つようになったため、工夫は必要なもののスクラムを導入することで実現できることも増えていると思います。私が経験したのはコア資産部分でしたが、コア資産以外でも仕様変更が多かったり同時開発といった場合には、活用できると思います。
当時の私は止むに止まれず気が付いたらスクラムっぽくなっていましたが、みなさんも簡単なスクラムイベントからトライしてみてはどうでしょうか。
