Updates

新着情報

コラム

なぜソフトウェアアーキテクチャ設計が重要か：車載開発における品質要求と設計の考え方

はじめに車載ソフトウェア開発に関して、ソフトウェアアーキテクチャ設計の重要性と難しさについて、日頃から感じていることについて記述します。Automotive SPICE v4.0 のソフトウェアアーキテクチャの仕様化に関する記述Automotive SPICE v4.0 の 「SWE.2 ソフトウェアアーキテクチャ設計」 では、ソフトウェアアーキテクチャの仕様化に関して以下の２個の基本プラクティス（BP）が規定されています。ソフトウェアアーキテクチャ設計とはソフトウェアアーキテクチャ設計は、エンジニアが実施すべき重要な作業であり、具体的には製品に必要な品質をバランスよく実装するために、すべての品質特性を考慮し、ソフトウェア全体をどんな構成にするか、どのようなメカニズムで動作させるかを設計する作業です。ソフトウェアに対する要求には大別して以下の２つのカテゴリーがあります。 機能要求 ：ソフトウェアが実現するべき機能（振る舞い）を規定したものです 非機能要求：包括的な用語であり、具体的には機能以外の品質要求や制約事項等が該当します非機能要求は機能以外のすべて要求を包含すると考えれば、概ね 「非機能要求＝品質要求」 と考えても良いでしょう。一般的に、非機能要求という言葉はあまり使われていませんが、Automotive SPICE では、あえて非機能要求という言葉を使っています。非機能要求に関しては、以下の記事も参考にしてください。 Automotive SPICE 4.0 における非機能要件の考え方ISO/IEC 25010：System and software quality models では品質を以下の８個の品質特性で定義しています。一般的に、ソフトウェア開発プロジェクトでエンジニアがまず最初に着目するのは、どんな機能（機能要求）を開発するかという事だと思います。機能要求はソフトウェアに要求する機能やサービスなので、利害関係者は明確に要求し、エンジニアは優先的に要求内容を確認すると思います。しかしながら、品質要求は抽象的な記述や省略されるケースもあるため、この場合はエンジニアが善意をもって開発する製品（ソフトウェア）に実装すべき品質要求定義し、利害関係者と合意しておく必要があります。車載ソフトウェア開発におけるアーキテクチャ設計に対する課題ソフトウェア工学では、開発要求を総合的に分析して、ソフトウェア全体の構造（静的側面）や動作/アルゴリズム（動的側面）を決定して、ソフトウェアアーキテクチャ設計書を作成し、そのソフトウェアアーキテクチャの上で要求された機能を実現していくことが求められています。SDV時代になってソフトウェア規模は巨大化しており、高品質ソフトウェアを開発するためのソフトウェアアーキテクチャの重要性は増大しています。しかしながら、車載ソフトウェア開発では、母体とするソフトウェア全体に対するアーキテクチャ仕様書がないケースが見受けられます（システム制御仕様書がソフトウェアアーキテクチャ設計書代わりに参照されているケースもあります）。信頼できるソフトウエアアーキテクチャ仕様書がない環境では、開発者は要求機能毎に個別ソフトウェアを設計するスタイルにならざるをえないというのが、車載ソフトウェア開発の現状課題のひとつではないでしょうか？。Automotive SPICEの要求に答えるために、無理やりソフトウェアを構造化しているような取り組みも見受けられます。ソフトウェアアーキテクチャ設計に関しては、以下の記事も参考にしてください。 Automotive SPICE 4.0 SWE.2 ソフトウェアアーキテクチャ設計とは？ 日本と欧米におけるソフトウェア開発アプローチの違い以下にアーキテクチャ設計事例（課題のあるアーキテクチャ設計事例と改善事例）を紹介します。ソフトウェアアーキテクチャ設計の事例紹介１（動的側面） 要求機能 ECU は空き状態で起動信号を受信したら機器１、２、３を起動する すべての機器の起動が成功した場合は緑ランプ点灯し、運用中状態にする 起動失敗機器がある場合、障害表示と赤ランプ点灯し、運用中状態にする 要求通りソフトウェア実装した、よくある事例 要求機能の順序通りにソフトウェア動作を設計する 複数機器をシーケンシャル起動する制御方式を採用する 筆者見解 この処理方式では３つの機器に対して順次起動するので、各機器に起動信号送信から応答信号を受信するまで、ECUでは計３回の機器起動待ち時間が発生するので、信号A 受信からランプ点灯までのレスポンスタイムが長くなるというデメリットがあります 要求機能に記載内容をそのまま上図のように単一タスクで実装すれば、ソフトウェアアーキテクチャを意識せず、要求機能を簡単にソフトウェアで実現できます ECUは、この単一タスク実行中（３回の機器起動待ち時間を含めて）は、他の処理を実行できません（タスク実行中のため、他の信号受信等のタスクはすべて待ち合わせになります） プロトタイプや PoC（Proof of Concept：概念実証） 開発では、正常機能の動作確認優先で、開発コスト削減/期間短縮のために動的側面を考慮しないケースでは、この処理方式でも問題ないでしょう 性能品質を考慮したソフトウェアアーキテクチャ設計の事例 信号A 受信からランプ点灯までのレスポンスタイムを短縮する 複数機器をパラレル起動する（機器起動待の発生箇所を１回にして待ち期間を短縮） パラレル制御を実現するアーキテクチャ（例：状態遷移モデル）を採用する 各機器からの起動完了信号をランダム受診時の処理を考慮する 起動 NG 受信、起動完了信号タイムアウトした時の処理を考慮する 筆者見解 ３つの機器を同時に起動して、一番起動時間の長くかかる機器からの応答を待ってランプ点灯できるので、ECU 待ち時間は、最大1/3 に短縮できるという大きなメリットがあります（ECU 自体の処理時間は起動待ち時間に比べて非常に短いため無視している） ３つの機器に対して処理を並行実施して応答待ちする必要があるため、これらの信号受信を並行処理するためにソフトウェアアーキテクチャが複雑になります ECUが起動待ち状態でも、他の信号受信やタイムアウト等発生時のタスクが実行可能です。 商用ソフトウェア開発では、エンドユーザの使い勝手や「性能を重視する必要があるので、レスポンスタイム短縮という品質（性能効率性）の実装は非常に重要ですソフトウェアアーキテクチャ設計の事例紹介２（静的側面） 要求機能例 信号 A を受信したら、処理 1、処理 2、処理 3 を実施する 信号 B を受信したら、処理 4、処理 5、処理 6 を実施する 信号 C を受信したら、処理 7、処理 8 を実施する ソフトウェアを単純構造化した、よくある事例 信号A、信号B、信号C 受信時のタスクを個別に順次作成する 各処理のかたまりを関数にして、「タスク群」と「関数群」に分離する 筆者見解 タスク群と関数群に分離して、見かけ上はソフトウェアを構造化しているように見えますが、実質的にはタスク中に各処理 BOX を、関数形式で埋め込んだだけです タスクで制御するデータと関数で制御するデータは、階層化されていません（すべての関数はタスク固有なので、タスクと関数でデータを階層化する必要性もありません） すべての関数はタスク固有処理となるため、ソフトウェア部品としての再利用性はありません 同じような処理が、複数の関数に存在してしまうことで、機能追加/変更時に影響範囲が発散する可能性が高いため、保守性に課題があります プロトタイプ開発/PoC 開発でのソフトウェアアーキテクチャを考慮しないケースでは、このような構造化でも問題ないでしょう 再利用性やデータ構造化を考慮したソフトウェアアーキテクチャ設計の事例 信号 A、B、C を受信時の処理１～８を総合的に分析し、共通処理/機能を抽出し、それらを４個の共通関数（W、X、Y、Z） にまとめ、定義する 共通関数で処理できない固有部分はタスク側で処理する 受信信号毎の処理差分を、関数側で制御できるように、タスク群と関数群間のインタフェース（共通関数の入出力パラメータ）を定義する タスク側で制御するデータと関数側で制御するデータを分離（階層化）する 筆者見解 タスク固有部から関数CALL時に、固有情報を入力パラメータとして引き渡すことで、共通関数化しているため、タスクと関数が階層化（構造化）されています。 タスク制御するデータと関数制御するデータは分離（構造化）されています 共通関数は独立したソフトウェア部品として、再利用性が高くなっています 個別タスク側の機能追加/変更と、共通関数側の機能追加/変更が、独立して実施できるので機能追加/変更の影響範囲が局所化され、保守性が高まっています 商用ソフトウェアでは、将来の機能追加/変更時の響範囲が局所化や保守性を重視し、個々の要求毎に逐次ソフトウェアを開発するのではなく、類似する要求を総合的に分析し、どのようなソフトウェアアーキテクチャにすべきかを決定する必要がありますソフトウェアアーキテクチャ設計における留意点個々の要求機能毎に逐次ソフトウェアを開発するのではなく、要求の集合ととらえて俯瞰し、どのようなソフトウェアアーキテクチャにすべきか決定する必要があります。参考までに、静的側面のアーキテクチャとして、AUTOSAR のレイヤー構造図とアプリケーションソフトウェアの構造図の事例を紹介します。さいごにAutomotive SPICEのSWE.2は、ソフトウェア工学をマスターしたエンジニアがソフトウェアを開発する際に、当然実施しているはずの活動や成果物を要求しているだけです。 ソフトウェア要求に基づいて、適切なソフトウェアアーキテクチャを採用している ソフトウェア全体の構造（ソフトウェア構成図 etc.）を設計する（静的側面） 外部インタフェース、コンポーネント間インタフェースを設計している（静的側面） ソフトウェア全体構造上での、ソフトウェア動作（シーケンスチャート、状態遷移図/遷移表 etc.）を設計している（動的側面） 上記のソフトウェアアーキテクチャ設計を文書化している運用実績のある既存ソフトウェアを母体として機能変更/追加する場合、あまりソフトウェアアーキテクチャを意識しなくても詳細設計を実施できることもありますが、既存ソフトウェアアーキテクチャが理解不十分だと、機能変更/追加に対する適切な追加/変更箇所の特定や影響範囲分析は困難です。また、Automotive SPICEの要求に答えるためだけに、ソフトウェア工学に基づかないアーキテクチャ設計（＝名ばかりのアーキテクチャ設計）を作成しても、利用価値がありません（誰も参照しない）。ソフトウェア工学に基づいた、信頼できるソフトウェアアーキテクチャ設計書を整備・更新しておくことは、追加/変更箇所の特定や影響範囲分析やソフトウェアの保守作業を効率化し、設計品質向上に大きく貢献します。ソフトウェアアーキテクチャ設計の重要性を認識し、要求された機能だけに着目するのではなく、他の機能要求や実現すべき品質要求もバランス良く考慮した上で、アーキテクチャを重視したソフトウェア開発を心がけてください。（海農 公宏）

コラム

Automotive SPICE アセスメント受審の心得　～ 知っておきたい、アセッサーが見ている5つのポイント ～

はじめにAutomotive SPICE アセスメントを初めて受けることになった時、多くの方が不安に感じることがあります。 「アセッサーからどんな質問をされるのだろうか」 「作業成果物はすべて揃えただろうか」 「記載不備を指摘されそうなところはどこか」 「説明担当者は何を準備すればよいのか」私自身が2025年当社へ転職する前は、車載部品メーカーのシステム開発部署 SEPG として組織プロセス改善活動に奮闘しており、アセスメントを受ける側の準備に日々悩んでいました。当時、Automotive SPICE コンサルタントからアセスメントの直前に教えていただいた受審の心得について、今も強く記憶に残っていることがあります。現在はアセッサー側の視点から多くの現場を見る中で、「評価されるポイント」と「準備が不足しがちなポイント」には明確な傾向があることにも気づきました。本コラムでは、Automotive SPICE PAM (Process Assessment Model) には記載されていないものの、初めてアセスメントを受ける方に知っておいていただきたいいくつかのポイントをご紹介します。１．アセッサーが見ているのは「成果物」だけではないAutomotive SPICE では、各プロセスで期待されるアウトプットや活動が定義されています。そのため、受審準備では、 「必要な作業成果物やプロセス文書が存在しているか」 「指定された記載項目が含まれているか」に意識が向きがちです。一方でアセッサーが確認したいことは、それだけではありません。本当に確認したいのは、「その成果物がどのような開発活動によって作られ、実際の開発現場で活用されているのか」という点です。例えば、要求仕様書が存在しても、 「誰がレビューしていつ承認されたか」 「その要求仕様書が次フェーズの設計へどのように繋がったか」 「要求仕様や設計書が変更されたときにどのように影響分析したか」つまり、これらの How をアセッサーへ説明できなければ、プロセスが有効に実施されていることを伝えることは難しくなります。さらにアセッサーは、プロセス文書の改版履歴も重要な確認対象としています。「そのプロセス文書がいつ作成され、どの程度の頻度で更新されているか」を見ることで、そのプロセスが一時的な準備物ではなく、継続的に運用されているかを判断します。この改版履歴は、プロセスの定着度を測る一つの指標であると同時に、その後のインタビューで確認すべきポイントを見極める材料にもなっています。２．「60秒ルール」－ 必要な情報へアクセスできる準備アセスメント準備で特に印象に残った助言の一つが、「指定されたドキュメントを60秒以内に提示できる状態にしておく」というものでした。これは、Automotive SPICE のプラクティスとして明文化されているものではありません。しかし、アセッサーとの限られた時間の中では非常に重要なポイントになります。例えば、「SYS.2 の要求分析結果を確認できますか？」と依頼された際に、「少々お待ちください」という沈黙の状況が続くと、アセッサーは成果物の存在だけでなく、プロジェクト内でその成果物が認知されているか、開発現場でどの程度管理・活用されているかを深掘りすることになるでしょう。もちろん、すべてを暗記する必要はありません。重要なのは、 「どこにあるか」 「誰が管理しているか」 「関連成果物とどのようにつながっているか」を見せながら説明できる状態にしておくことです。リファレンスリストを準備する「60秒ルール」を実現するための有効な手段として、リファレンスリストの整備があります。これは、Automotive SPICE の各プロセスで要求される成果物と、プロジェクトで実際に作成している成果物を対応付けた一覧です。成果物が格納されているリポジトリ情報のリンクを整理しておくことで、アセッサーからの依頼に対して即答できるようになります。このリストの作成には、Automotive SPICE への理解がある程度必要ですが、単なる準備資料にとどまらず、自分たちの活動とモデルとの対応関係を整理するうえでも大変有効です。構成品目一覧から説明できる状態にするもう一つの実践的な方法として、成果物を単体で探して提示するのではなく、「構成品目一覧」から辿って説明する方法があります。例えば、プロジェクトの構成品目一覧を表示し、紐づいたリンクから対象の成果物を提示することで、「どの成果物がどの位置づけで管理されているのか」を説明することができます。この方法の前提として、構成品目一覧が適切に整備・運用されている必要はありますが、単に成果物を提示するだけでなく、構成管理の観点も含めて説明できる点が大きなメリットです。結果として、このような説明ができる状態にしておくことは、SUP.8（構成管理）の観点からも評価されやすくなります。リファレンスリストのような整理された資料だけでなく、日常のSUP.8運用の仕組みをそのまま使い説明できることが理想です。３．「できていない」と自己判断しない重要性他にも、当時教えていただいた重要なポイントがあります。それは、「Automotive SPICE の用語で実施していないからといって、”できていない”と自己判断しない」ということです。実際の開発現場では、Automotive SPICE のプラクティス名やアウトプット（情報項目）名とは異なる、企業固有の名称や現場の呼び方で活動していることがあります。例えば、 要求レビュー 設計検討会 品質確認会議 不具合分析会など、現場独自の活動の中で Automotive SPICE が求める活動を実施しているケースがあります。そのため、アセッサーから質問された際には、「Automotive SPICE の SYS.2 のシステム要求の構造化という活動は実施していません」とすぐに回答するのではなく、「名称は異なりますが、見積検討会という活動で要求の構造を確認しています」というように、自分たちの開発活動との対応関係を説明することが大切です。４．アセスメントは「試験」ではなく「開発活動の確認会」初めてアセスメントを受ける方ほど、 「正解を答えなければ減点される」 「指摘されないようにしなければならない」というネガティブな心境になりがちです。しかし、アセスメントの本来の目的は、できている・できていないを単純なものさしで判定することではありません。アセッサーは、 「開発プロセスが Automotive SPICE の意図した建付けで機能しているか」 「リスクを早期に発見できる仕組みになっているか」 「チェック機構と改善活動が連動している状態か」を確認しています。説明担当者に求められるのは「完璧な回答」ではなく、「自分たちの開発活動をアセッサーに正しく説明すること」です。５．準備の差がアセスメントの結果を左右するアセスメントは組織やプロジェクトにとって重要なイベントであるにもかかわらず、十分な準備が行われていないケースが少なくありません。例えば、アセッサーからレビュー記録の開示を求められた際に、 参加者が2名のみ 実施時間が15分程度 指摘事項がゼロといった記録を見せられることがあります。もちろん、それ自体が必ずしも問題とは限りません。しかし、アセッサーの視点では「本当に有効なレビューが行われているのか」という疑問につながります。また、事前に説明担当者が回答の予行演習（リハーサル）を実施している組織は意外と少なく、結果として説明が不十分になってしまう傾向が見受けられます。一方で、アセスメントの要求事項を理解するための勉強会や、想定問答を準備している組織では、インタビューが非常にスムーズに進む傾向があります。このように、アセスメントの結果は「準備の質」に大きく依存します。単に成果物を揃えただけでは、十分とは言えません。 説明の一貫性 成果物の選定 想定問答の整理といった観点で事前準備を行うことが非常に重要と言わざるを得ません。おわりにAutomotive SPICE アセスメントでは、PAM に記載されたプラクティスを理解することはもちろん重要です。一方で、初めて受審するチームにとって重要なのは、 必要な情報へ素早くアクセスできること 自分たちの開発活動を現場の言葉で説明できること 十分な準備を行い、自信を持って受審に臨むことです。本記事で紹介した内容はPAMに明示されているものではありませんが、実際のアセスメント現場では非常に重要なポイントです。アセスメントは「試験」ではなく、自分たちの開発活動を確認し、より良いプロセスへつなげる貴重な機会でもあります。これから初めて Automotive SPICE アセスメントを受審される方にとって、本コラムが少しでも参考になれば幸いです。弊社では、開発現場に伴走できる経験豊富なコンサルタントが在籍し、みなさまのお困りごとに対応しております。今回のコラムで取り上げた内容は、Automotive SPICE トレーニングや入門教材でもカバーしています。関心をお持ちの方は、ぜひ弊社までお問い合わせください。（越智功）

コラム

エンジニアリングチーム（開発組織）の成長とスキル開発　～成長する開発組織に必要なものは「個人」と「チーム」の両立～

1. 「成長したい」と「時間がない」のあいだでエンジニアとして仕事に取り組む中で、「継続的に成長すること」の重要性を感じている方は多いのではないでしょうか。技術の変化が速い領域において、学び続けることは避けて通れません。一方で、現実には日々の開発業務、障害対応、スケジュールへの追従といった目の前の作業に追われ、自己研鑽の時間を十分に確保できていないという状況も広く見られます。その結果、「成長の必要性は理解しているが、実践が難しい」という状態が生まれます。このギャップは個人の問題というより、開発組織全体に共通する構造的な課題と捉えるべきものとも考えられます。2. 個人の努力だけでは乗り越えられない壁スキル開発は、これまで個人の主体性に委ねられる側面が強くありました。自ら学び、試し、成長する—この姿勢自体は非常に重要です。しかし、個人の努力に依存した成長にはいくつかの限界があります。まず、学習への投資には個人差が生まれやすく、チーム内にスキルのばらつきが生じます。その結果、特定のメンバーに業務が集中しやすくなり、属人化のリスクが高まります。また、個人が獲得した知識やノウハウが共有されなければ、チーム全体の能力向上にはつながりません。さらに、せっかく学んだ内容も実務で活用する機会がなければ定着しにくく、学習の効果が十分に発揮されないケースも見られます。3. チームとして成長している状態とはでは、「チームとして成長している状態」とはどのような状態を指すのでしょうか。一つは、特定の個人に依存せずに開発が進められる状況です。誰かが不在でも業務が滞らないことは、知識やスキルがチームに分散・共有されていることの表れです。また、分からないことを気軽に相談できる関係性や、レビューや対話を通じて知識が自然に広がる環境も重要です。こうした状態では、個人が学んだことがチームに還元されやすくなります。さらに、経験の浅いメンバーが新しい技術や役割に挑戦できる機会があることも、チームの成長にとって不可欠です。 こうした状態は、次のような要素によって支えられており、これらが適切に組み合わさることで、個人の成長とチームの成長が相互に作用する状態が生まれると考えられます。＜チームの成長を促進する主な要素＞・学習機会が継続的に提供されていること・知識や経験がチーム内で共有される仕組みがあること・新しい役割や技術に挑戦できる機会が用意されていること・挑戦に伴う失敗が許容される心理的安全性が確保されていること・成長の方向性や期待値がある程度明確になっていること 4. 成長のための施策がうまく機能しない理由多くの組織では、研修や勉強会、スキル定義など、スキル開発を目的としたさまざまな施策が導入されています。しかし、それらが現場の実感として「意味のあるもの」として機能しているかというと、必ずしもそうとは限りません。その背景には、いくつかの共通した要因があります。まず一つは、「目的と手段の分離」です。研修やスキル定義が“何のために存在するのか”が十分に共有されていない場合、それらは単なる形式的な活動になりがちです。その結果、受講や記入そのものが目的化し、実際の成長につながらない状態が生まれます。次に、「業務との関係の弱さ」が挙げられます。学習した内容が日々の業務で活用される見通しが立たない場合、人は自然と優先順位を下げます。特に納期や品質に責任を持つ現場においては、直接成果に結びつかない活動は後回しにされやすいという現実があります。さらに、「一律性」も課題となります。エンジニアのキャリア志向やスキルレベルは多様であるにも関わらず、画一的な内容を一斉に適用しようとすると、誰にとっても中途半端なものになりやすくなります。その結果、主体的に取り組む動機が弱まり、「やらされ感」が強まります。これらの要因が重なることで、本来は成長を支援するはずの施策が、現場にとって負担や形骸化した活動として認識されてしまうことがあります。5. 自律性を尊重した成長の仕組みづくりこうした課題を踏まえると、スキル開発を機能させるためには、研修や育成制度といった個別の取り組みを増やすこと自体が解決になるわけではありません。重要なのは、それらの取り組みをどのような意図で設計し、どのように連動させるかという点です。特に鍵となるのが、個人の自律性との関係です。自律性とは、単に「自由に任せる」ということではありません。組織としての方向性や期待値をある程度示しつつ、その中で個々人が選択できる余地を持たせることが重要です。例えば、スキルの全体像や成長の方向性を可視化した上で、どの領域をどの程度深めるかは個人に委ねる、といった考え方です。このように「枠組み」と「自由度」を両立させることで、納得感のある成長につながります。また、学びと実務のつながりも重要なポイントです。新しく習得した知識や技術を試せる場がなければ、学習は一過性のものにとどまりがちです。プロジェクトの中で新しい役割に挑戦できる機会や、小さな改善活動に取り組める環境を整えることで、学びを実践へとつなげることができます。さらに、評価や役割との関係も無視できません。日々の業務成果だけでなく、知識共有や育成への貢献といった行動が適切に認識されることで、個人の取り組みは継続しやすくなります。このように、個人の自律性を尊重しながらも、組織として成長の方向性や機会を設計していくことが、スキル開発を持続的なものにするための重要なポイントとなります。6. 組織が担うべき「成長の土台づくり」個人の自律的な成長を支えるためには、それを下支えする「土台」が必要です。この土台は、単一の施策で成立するものではなく、複数の仕組みが連携することで初めて機能します。 具体的には、次のような施策が考えられますが、これらは組織として整備すべきものです。＜スキル開発・チーム成長を促すための主な施策＞・スキルマップの可視化（成長の方向性や現在地の理解を支援）・トレーニングカリキュラムの整備（基礎から応用までを体系化し段階的に学べる設計）・OJTによる実践的な育成（実務と学習の接続：業務を通じたスキル定着）・メンター制度（個別の相談や成長支援の強化）・学習支援制度（学習機会へのアクセス向上：書籍購入や研修参加などの後押し）・ナレッジ共有の仕組み（チームへの還元促進：レビュー・勉強会・ドキュメントなど） ここで重要なのは、「施策単体の良し悪し」だけではなく、「組み合わせ」です。例えば、研修だけが整備されていても、それを実務で試す場がなければ効果は限定的です。逆に、挑戦機会があっても基礎的な学習支援が不足していれば、取り組める人は限られます。また、ナレッジ共有の仕組みがあっても、それが評価や期待と結びついていなければ、継続的な活動にはなりにくいでしょう。このように、個々の施策は相互に補完し合う関係にあります。組織としての役割は、それらを全体として設計し、「自然に成長が生まれる状態」を作ることにあります。7. おわりに：成長を「個人任せ」にしないためにスキル開発は個人の主体的な取り組みによって成り立つ側面を持ちながらも、それだけに委ねてしまうと、組織としての成長には限界が生じます。個人の努力と、チームや組織による支援、この両方がかみ合ったとき、はじめて持続的な成長が可能になると考えます。成長は「個人で頑張るもの」でも、「組織から与えられるもの」でもなく、両者の相互作用によって実現されるものであり、その視点を持つことが、これからのエンジニアリング組織において、より一層重要になっていくのではないでしょうか。 （佐藤崇）

コラム

日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（前編）　〜　生産性向上と品質維持に向けた提言　〜

１．なぜ、車載ソフトウェア開発にDRBFMが使われているのか日本の車載ソフトウェア開発では、DRBFM（Design Review Based on Failure Mode）が当然のように使われている。これは筆者にとって、驚き以外の何ものでもない。そもそもDRBFMは、「機械部品」の設計変更や環境変化に伴うリスクを洗い出すために生まれた手法である。「ボルトの径を変えた」、「材質を変えた」、「使用条件が変わった」。そうした物理的な変化点を起点に、摩耗や破断といった実体のある故障モードを徹底的に深掘りすることに、その本質的な価値があった。 ではなぜ、その手法がソフトウェア開発に使われ続けているのか。なぜ「コード一行の変更」を、「機械部品の設計変更」と同じ発想で扱わなければならないのか。この問いに、工学的に納得できる明確な説明を聞いたことがない。実際の開発現場では、今もなお多くの技術者が相当な時間と労力をかけてDRBFMを実施している。「故障モードを〇〇個出せ」「もっと深掘りできるはずだ」「宇宙線によるビット反転が起きたらどうするのか」。そうした指摘が飛び交い、現実にはほとんど起こらない事象まで含めて、延々と議論が続く。DRBFMは、本来の「変更点に着目した検討」という枠を超え、起こるかどうか分からない最悪事象を列挙する儀式になってしまっているのではないだろうか。 あまりに負担が大きいため、「ここまでやる必要が本当にあるのだろうか？」と疑問を投げかけると、返ってくる答えは、ほぼ決まっている。「上司の指示だから」、「会社のルールだから」。そこには、技術的な必然性よりも、慣習や前例を優先する空気が色濃く見て取れる。技術革新のスピードは年々加速し、開発は急速にグローバル化している。各国のエンジニアが分業し、並列に開発を進めることが当たり前になった現在、このような開発スタイルを続けていて、本当に日本製品の優位性は保てるのだろうか。ソフトウェアが車の価値を決め、ソフトウェアの開発スピードが競争力の源泉になるSDV時代において、「ソフトウェアの変更点を人間が集まって延々と深掘りする」という方法論は、生産性・品質の両面で限界に達していると筆者は考えている。問題は、個々の技術者の能力や意識ではない。前提としている開発思想そのものが、すでに時代と乖離し始めているのである。 本コラムで扱おうとしているテーマは、いわば「触れてはいけない」とされがちな領域である。日本の車載ソフトウェア開発において長年 “当たり前” として受け入れられてきたDRBFMを、工学的・構造的な視点から問い直すことは、少なからず反発を招く話でもある。しかし、この違和感に目をつぶり続けたままでは、議論はいつまで経っても現場の苦労話や精神論に留まり、何も変わらない。そこで今回は、この問題に正面から踏み込むため、あえて前編・後編の二部構成という形を取ることにした。 前編では、なぜソフトウェア開発においてDRBFMがここまで重く運用されるようになったのか、その技術的背景と、日本特有の開発文化・構造を整理する。現場で起きている「無限の深掘り」による疲弊が、個々の技術者の問題ではなく、どのような前提の上に生まれているのかを明らかにしていく。そして後編では、視点を一度外に移し、世界では同じ課題にどう向き合っているのか、なぜDRBFMがソフトウェア開発で使われていないのかを見ていく。その上で、この先どの地点を目指すべきなのかを考えたい。これは手法の是非を問う話ではない。日本の車載ソフトウェア開発が、これからも競争力を持ち続けるために、何を疑い、何を変えるべきかを考えるための議論である。 ２．DRBFMは本来ハードウェアの手法だった — メカ開発の成功体験が生んだミスマッチ前章では、ソフトウェア開発の現場でDRBFMが儀式化し、技術者を疲弊させている実態を見てきた。では、なぜそもそもこのような違和感が生じるのか。その答えは、DRBFMという手法のルーツにある。DRBFM（Design Review Based on Failure Mode）は、その名の通り「故障モード」を起点として設計変更のリスクを洗い出す手法である。そして重要なのは、この手法が機械部品を中心としたハードウェア開発のために生まれたという事実だ。 ハードウェアの世界では、DRBFMは極めて合理的に機能する。ボルトの径を細くした、材質を変えた、使用温度範囲が広がった。そうした「変化点」から、摩耗、クラック、破断、漏れといった物理的な故障モードを因果関係として追っていくことができる。部品は実体を持ち、力の流れや劣化のメカニズムも説明可能だ。この世界では、「どこまで深掘りすべきか」は明確であり、深掘りそのものが品質向上に直結する。 一方、ソフトウェアはまったく異なる性質を持つ。ソフトウェアには摩耗も劣化もない。故障の正体は、ほぼ例外なく設計ミス、すなわちバグである。「なぜ壊れたのか」を物理現象として説明できるハードウェアと違い、ソフトウェアの不具合は論理の誤り、前提の勘違い、仕様の曖昧さ、考慮漏れといった人間の思考に起因するものだ。 この本質的な違いを無視したまま、ハードウェア由来のDRBFMをソフトウェアに適用すると、問題が生じる。物理部品のDRBFMでは意味を持っていた「深掘り」が、ソフトウェアでは行き場を失うからだ。変数の型変更、条件分岐の追加、タイミングの微調整など、こうした変更点から「どの段階まで故障モードを掘り下げるべきか」を、物理的な根拠なしに決めることはできない。結果として、ソフトウェアDRBFMでは次のような現象が起きる。論理的にはあり得るが、確率的には極めて低い事象までが同列に扱われる。最終的には「宇宙線によるビット反転」や「OSの内部不具合」といった、設計者が制御不能な領域にまで議論が及ぶ。ハードウェアであれば「そこから先は部品設計や材料特性の問題」として切り分けられていた議論が、ソフトウェアでは切り分けられないままDRBFMの中に押し込まれてしまう。 本来、こうした問題の解決はソフトウェアアーキテクチャの役割である。エラー検知、フェイルセーフ、リカバリーの設計によって、「起きても安全に処理できる」状態を構造として担保するべき領域だ。しかし、アーキテクチャという抽象的な仕組みへの信頼が十分に確立されていない場合、その代替として「とにかく心配事を洗い出す」DRBFMが肥大化していく。ここで強調しておきたいのは、DRBFMそのものが悪いわけではない、という点である。DRBFMは本来、ハードウェア開発において大きな成果を上げてきた優れた手法だ。問題は、その成功体験をほぼ無批判にソフトウェアへと移植し、本質的な違いを考慮せずに運用してきたことにある。ソフトウェア開発におけるDRBFMは、ハードウェアの作法をそのまま当てはめた結果、生まれたミスマッチの産物と言える。そしてこのミスマッチこそが、現場で語られる「終わらない深掘り」「何のためのレビューなのか分からない」といった違和感の正体なのである。 では、なぜ日本の車載ソフトウェア開発では、このミスマッチを抱えたままDRBFMが使われ続けてきたのか。次章では、その背景にある日本特有の設計文化と意思決定構造について掘り下げていく。 ３．なぜ日本の車載ソフトウェアではDRBFMが生き残ったのか － すり合わせ文化とハード主導の設計思想前章で見てきたように、DRBFMは本来ハードウェア開発のための手法であり、ソフトウェア開発と相性が良いとは言えない。それにもかかわらず、日本の車載ソフトウェア開発では、DRBFMが長年にわたって当然のように使われ続けてきた。この背景を説明するために、「DRBFMの優劣」や「現場の努力不足」に話をすり替えてはいけない。ここで問うべきなのは、なぜ日本の開発現場では、この違和感を抱えたままでもDRBFMに頼らざるを得なかったのかという点である。ハード屋とソフト屋の「共通言語」としてのDRBFM日本の自動車メーカーでは、長年にわたってハードウェア中心の開発が行われてきた。品質保証、設計審査、意思決定の枠組みも、その多くはハードウェア開発で成功した方法論をベースに構築されている。その中でDRBFMは、「変更点に着目してリスクを洗い出す」という分かりやすい思想を持つ、極めて都合の良い共通言語だった。メカ設計者にも、電気設計者にも、そしてソフトウェア設計者にも、「今回どこを変えたのか」「それによって何が起き得るのか」を同じフォーマットで説明させることができる。本来であれば、ソフトウェアの機能や品質は要求仕様書やアーキテクチャ設計書を通じて説明されるべき存在だ。しかし、それらのドキュメント文化が十分に整備されていない環境では、DRBFMが部門を超えた意思疎通のための代替手段として機能してしまう。結果として、DRBFMは品質手法というよりも、「みんなが理解できる説明の形式」として定着していったのではないか。意思決定層がハード出身であるという構造的問題もう一つ無視できないのが、意思決定層のバックグラウンドである。日本の自動車開発において、開発責任者や品質保証部門の多くは、長年ハードウェア開発に携わってきた人たちである。彼らにとって、DRBFMは「品質を作り込むための正統な手法」であり、それによって数多くの成功体験を積み重ねてきた。一方で、ソフトウェアアーキテクチャや自動テスト、CI/CDといった概念は、必ずしも直感的に理解しやすいものではない。その結果、意思決定の場ではどうしても、「目に見える」「議論できる」「紙に書ける」DRBFMが重視される。ソフトウェア側が「アーキテクチャで担保している」と説明しても、それが完全には信用されず、「ではDRBFMで確認しよう」という結論に落ち着きやすい構造が生まれてしまう。「ネジ一本」と「コード一行」を同列に扱う設計変更思想車載ソフトウェアが問題をさらに複雑にしているのは、ソフトウェアがすでに車の中核機能を担っているという事実である。ブレーキ、ステアリング、パワートレイン制御など、「走る・曲がる・止まる」の多くがソフトウェアによって制御されている。このため、「ネジ一本を変えること」と「コード一行を変えること」を同じ重みの「設計変更」として扱わなければ危険だ、という考え方が強く根付いた。安全を最優先するという点では、この思想自体は理解できる。しかしその結果、ソフトウェア開発が本来前提としている「アーキテクチャによる影響範囲の局所化」、「テスト自動化による回帰検証」、「反復的な変更を許容する開発スタイル」といった要素が十分に考慮されないまま、「変更したのだから徹底的に不安を潰すべきだ」という発想だけが肥大化していった。 リコールコストという「恐怖」が生んだ過剰な保守性このような構造の背景には、車載開発特有の“恐怖”もある。一度市場に出た製品で不具合が見つかれば、数百万台規模のリコールにつながり、企業に甚大な損失をもたらす。この失敗コストの大きさが、「万が一を見逃すより、やり過ぎる方が安全だ」という判断を正当化してきた。そしてDRBFMは、その「やり過ぎ」を制度として固定化するための、極めて都合の良い枠組みだった。結果としてDRBFMは、リスクを減らすための工学的手法というよりも、 これだけやったのだから大丈夫だと言える材料 誰か一人の判断にしないための責任分散装置としての性格を強めていったのである ここまで見てきたように、DRBFMが日本の車載ソフトウェア開発に生き残ったのは、偶然ではない。文化、組織、意思決定構造、そして恐怖――それらが絡み合った結果として、DRBFMは“必要不可欠なもの”に見える存在へと変質していった。そしてこの構造の帰結として、現場には「どこまで深掘りすれば終わるのか分からない」DRBFMが残ることになった。 次章では、その象徴的な姿である「無限深掘り」という地獄について、さらに踏み込んでいく。 ４．ソフトウェアDRBFMが生む「無限深掘り」という地獄前章までで見てきたように、DRBFMは本来ハードウェア開発の文脈で成立してきた手法であり、日本の車載ソフトウェア開発では、その前提が十分に吟味されないまま持ち込まれてきた。その結果として現場に現れるのが、多くの技術者が口を揃えて語る「終わらないDRBFM」、すなわち無限深掘りという状態である。この無限深掘りは、単なる運用ミスや一部現場の暴走ではない。ソフトウェアという対象と、DRBFMという手法の組み合わせがもたらす構造的な帰結である。ハードウェアDRBFMとソフトウェアDRBFMの決定的な違いハードウェア開発におけるDRBFMでは、「深掘り」は品質向上に直結する行為だ。ボルトの径を細くする、材質を変える、使用条件を厳しくする。そうした変化点から、応力集中、疲労、破断といった故障モードを因果関係として追っていくことができる。物理現象に基づくため、「どこまで掘れば十分か」という判断にも、経験則や工学的裏付けが存在する。 一方、ソフトウェアにはこのような「物理的な終点」が存在しない。条件分岐の変更、変数型の変更、タイミング調整といった変更点から不具合を想像することはできるが、その連鎖は理論上いくらでも続いてしまう。ハードウェアDRBFMでは、「そこから先は現実的に起こらない」と線を引ける。しかしソフトウェアDRBFMでは、「理論上は起き得る」という一言で、議論を次の階層へ進めることができてしまう。この違いこそが、ソフトウェアDRBFMを終わりのない作業へと変質させる最大の要因である。 なぜ「何段階まで深掘りするのか」が決まらないのかソフトウェアDRBFMが最も苦しいのは、「どこで止めるべきか」を判断する共通基準が存在しない点にある。ハードウェアであれば、材料強度、設計マージン、規格といった形で、深掘りを打ち切るための工学的根拠が共有されている。しかしソフトウェアでは、「アーキテクチャで影響は限定されている」「この層でフェイルセーフする」といった説明が、必ずしもレビューの場で十分な納得材料として機能しない。結果として、「ではそれが壊れたらどうなるのか」「もし検知できなかったらどうするのか」という問いが繰り返され、議論は自然に次の階層へと進んでいく。問題は、この問い自体が論理的には正しいことだ。完全に間違っていないがゆえに、誰も「そこまでで十分だ」と言い切ることができず、深掘りを止める責任を取りたがらない。こうしてDRBFMは、不安が完全になくなるまで続けるべき検討へと変質していく。 宇宙線・ビット反転問題が象徴する「議論の暴走」ソフトウェアDRBFMの象徴的なトピックとして、しばしば持ち出されるのが「宇宙線によるビット反転」である。車載環境においてソフトエラーが実際に発生することは事実であり、この現象そのものを否定することはできない。しかし、この話題がDRBFMの場に登場した瞬間、議論の性質は変わる。それはもはや「今回の設計変更による影響」を検討する場ではなく、「このシステムは絶対に壊れないと言えるのか」という問いへとすり替わる。 ビット反転が起きたらどうするのか。 検知できなかったらどうなるのか。 検知機構自体が壊れたらどうなるのか。これらの問いは理論上いくらでも連鎖し、しかも設計担当者が直接制御できない領域へと踏み込んでいく。にもかかわらず、それらがDRBFMという枠組みの中で同一平面に並べられることで、現場には「どこまで考えれば許されるのか分からない」という疲弊だけが残る。 本来アーキテクチャで解決すべき問題まで、DRBFMに押し込めている現実ここで本来問われるべきなのは、役割分担である。宇宙線やランダムエラーへの対処は、個別機能のDRBFMで毎回検討すべき話ではない。それはプラットフォームやアーキテクチャの責務として、一度決めた前提のもとで扱われるべき問題だ。ソフトウェア開発が本来前提としているアーキテクチャによる影響範囲の局所化、テスト自動化による回帰検証、そして反復的な変更を許容する開発スタイルが十分に信頼されていれば、DRBFMが無限に深掘りされることはない。しかしその前提が共有されていない、あるいは信用されていない場合、あらゆる不安がDRBFMという一枚の表に集約される。アーキテクチャで扱うべき話も、運用ルールとして決めるべき話も、最終的には「DRBFMで説明してください」という形で押し戻されてしまう。こうしてDRBFMは、本来の役割である「変更点に着目した設計レビュー」を超え、あらゆる不確実性を一度の会議で解消しようとする万能装置になってしまう。結果として残るのは「終わらせたという安堵感」と引き換えに失われた膨大な時間だけである。  ここまで見てきたように、ソフトウェアDRBFMが「無限深掘り」という地獄に陥るのは、現場の技術者が未熟だからでも、真面目さが足りないからでもない。それは、ハードウェア起点で生まれた手法を、性質の異なるソフトウェアに適用し続けてきた結果として、ほぼ必然的に生じた現象である。DRBFMは本来、変更点に着目して設計上のリスクを洗い出すための手法だった。しかし日本の車載ソフトウェア開発では、アーキテクチャや工学的な前提への信頼が十分に共有されないまま、あらゆる不安をDRBFMという一つの場に集約しようとしてきた。その結果、DRBFMは「設計レビュー」ではなく、「起こり得るすべてを想像し尽くすための儀式」へと変質してしまったのである。 重要なのは、これはDRBFMそのものの是非を問う話ではない、という点だ。問われているのは、日本の車載ソフトウェア開発が、ソフトウェアをどのような工学対象として捉え、品質と安全性をどのレイヤーで担保するのかという前提そのものである。前編では、日本の車載ソフトウェア開発の内部構造に目を向け、なぜDRBFMがここまで重く運用され、現場を疲弊させる存在になったのかを整理してきた。では、同じ「ソフトウェア」という技術を扱いながら、世界はこの問題にどのように向き合ってきたのだろうか。なぜ車載以外のソフトウェア開発では、DRBFMのような手法が品質保証の中心に据えられることはないのか。そして日本の車載ソフトウェア開発は、この先どの地点を目指すべきなのか。 後編では視点を一度外に移し、グローバルなソフトウェア開発の前提や設計思想を踏まえながら、DRBFMを前提としない品質保証がどのように成立しているのか、そしてDRBFMと距離を取るための現実的な道筋について考えていく。 （日吉 昭彦）

コラム

Automotive SPICE 能力レベル３とは何か？　ー それは「プロセスの話」だけではない　（後編）

前編では、能力レベル3の本質が「プロセス定義」だけではなく、People・Process・Technology を通じて組織として改善が回り始める状態にあること、そしてAutomotive SPICE（以下、A-SPICE）の文脈では、なぜその本質が見えにくくなってきたのかを整理してきた。前編はこちらから。後編では、その理解を前提として、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、さらにそれが事業運営や競争力とどのようにつながっていくのかを考えていく。 ５．レベル３はゴールではないーレベル４・５が示す世界能力レベル3は、組織として改善を回し始めるための重要な節目である。しかし、それは決して到達点ではない。むしろ、改善がようやく自律的に回り始めた状態に過ぎない。レベル3に到達した組織では、改善はもはや個々のプロジェクトの工夫に依存するものではなく、組織の仕組みとして回り始める。標準プロセスやプロセス資産が整備され、プロジェクトはそれを前提として運営され、実績は組織に還元される。前編で見てきたのは、まさにこの状態であった。しかし、改善が回り始めることと、組織がどこへ向かって進んでいるかは別の問題である。能力レベル3の段階では、関心の中心は依然として「やり方」にある。どのプロセスを使っているか、標準は守られているか、改善活動が実施されているかといった点が議論の主軸になる。 能力レベル4・5の世界では、この関心の置きどころが変わる。ここで重要なのは、改善がより高度になることではない。組織の視線そのものが変わるという点にある。この視線の違いは、データの使われ方に最も端的に現れる。能力レベル3までにおけるデータの扱いは、主として過去を振り返るためのものである。どのプロセスがうまく機能したのか、どこに問題があったのかを確認し、現状を把握するために用いられる。このデータの使い方は、自動車で言えばバックミラーを見る行為に近い。過去に何が起こったかを確認し、その結果をもとに現在の状況を判断する。 一方、能力レベル4に進むと、データの意味合いが変わる。レベル4では、プロジェクトやプロセスの実行結果が定量的に捉えられ、ばらつきが管理される。品質、工数、納期といった指標が過去の実績と結び付き、組織として「予測可能な状態」に近づいていく。ここでの特徴は、データが単なる記録ではなく、意思決定の材料として使われ始める点にある。この段階でのデータの役割は、バックミラーではなくナビゲーションに近い。過去の実績をモデル化することで、将来どのような結果が起こり得るのかを見通し、その上で進路を選択するために使われる。 さらにレベル5では、そのデータを用いて、組織としてどこを改善すべきか、どこに投資すべきかが議論されるようになる。改善は「現場の工夫」ではなく、組織として選択される活動になる。この段階では、改善テーマがプロジェクトの中だけで完結することはほとんどない。 重要なのは、ここで求められているのが「高度なプロセス技法」ではないという点である。レベル3まではプロセスの設計や運用が議論の中心だったのに対し、レベル4・5では、組織の視線がプロセスそのものから事業成果へと移っていく。改善はもはや目的ではなく、事業を成り立たせ、競争力を維持・強化するための手段として扱われるようになる。 この意味で、能力レベル3をゴールとして捉えてしまうと、組織は改善のやり方を洗練させるところで立ち止まりやすい。一方、能力レベル3を通過点と捉えた組織は、その先で「改善を何のために行うのか」という問いに直面することになる。次章では、この視点の違いが、実際の組織ではどのような差として現れるのかを、具体的な経験をもとに見ていく。 ６．20年後を語る企業と、目の前を語る企業能力レベル4・5が示している本質が、手法や技術の高度化ではなく「組織の視線の向き」であるとすれば、その差はどこに最もはっきりと現れるのだろうか。その一つの答えは、組織が何を語っているか、もう少し言えば、どれだけ先の話をしているかにある。筆者が北米のあるCMMIレベル5企業を訪問したのは、今から20年以上前のことである。先進的なプロセス改善の現場を見る機会を得て、多くの示唆を受けたが、今でも強く印象に残っているのは、プロセスそのものではなく、そこで交わされていた会話の内容である。 その企業では、SEPG（Software Engineering Process Group）に属する人材が、プロセスの話と同じ熱量で、事業の話をしていた。彼らが語っていたのは、「次のプロジェクトをどう回すか」ではなく、「この事業を10年後、20年後にどういう姿にしたいのか」という問いだった。プロセス改善は頻繁に話題に上ったが、それは決して目的ではなかった。改善は、商品競争力をどう高めるか、市場でどのポジションを取るのかといった議論の中に自然に組み込まれていた。プロセスは、事業の意思を実現するための手段として語られていたのである。興味深かったのは、こうした議論を主導していたSEPGのメンバーの多くが、経営学やビジネスの素養を持っていた点である。中にはMBAを取得している人材もおり、プロセスと事業の話を行き来しながら議論することが、ごく自然なこととして行われていた。 一方で、筆者がこれまでに見てきた多くの組織では、状況はかなり異なる。そこでは、SEPGはプロセスを定義し、維持し、評価対応を行う組織として位置づけられることが多い。語られる話題は、「このプロセスで問題はないか」「監査に耐えられるか」「定義が最新か」といったものが中心になる。もちろん、こうした活動自体が無意味なわけではない。前編で述べた通り、能力レベル3までの世界では、これらは不可欠な役割である。しかし、その状態に留まる限り、組織の議論はどうしてもプロセスの内側に閉じてしまう。 ここに、能力レベル3とレベル4・5の間に横たわる大きな断層がある。能力レベル3では、改善は回っている。しかし、その改善がどこへ向かうためのものなのかは、必ずしも明確ではないことが多い。改善は改善として正当化され、「なぜそれをやるのか」という問いは後回しにされがちになる。これに対し、能力レベル4・5の組織では、改善は常に別の問いと結び付けられている。「それは事業にどう寄与するのか」「競争力の源泉になるのか」「投資する価値があるのか」。プロセス改善は、こうした問いに答える一つの選択肢として扱われる。 この違いは、組織文化にも強く影響する。目の前のプロジェクトや、直近の評価結果を語る組織は、通常、改善の視野も短期に留まる。問題があれば対処するが、その積み重ねがどこへ向かうのかは共有されにくい。一方、長期の時間軸で話をする組織では、改善は最初から「積み上げていくもの」として位置づけられる。ここで注目すべきなのは、この差がプロセス技術の巧拙から生まれているわけではないという点である。多くの場合、違いを生んでいるのは、誰が改善を語っているのか、そして何の文脈で語っているのかである。能力レベル4・5に到達した組織では、改善を語るSEPGが、同時に事業の文脈を語ることができる。逆に言えば、改善の議論がプロセスの範囲に閉じている限り、組織は能力レベル3の先に進むことが難しい。 次章では、この問題を個々の人材の能力論としてではなく、組織構造や役割設計の問題として捉え直す。なぜ多くの組織は能力レベル3を維持できず、再びレベル1・2に戻ってしまうのか。一方で、なぜ一度能力レベル4に到達した組織は、その水準を下回ることがほとんどないのか。その違いを考えていく。 ７．プロジェクトフォーカスから、いつ抜け出すのか第6章では、能力レベル4・5に到達した組織の姿を見てきた。そこでは、改善は単なるプロジェクトの成果や品質向上としてではなく、組織や事業の言葉として語られていた。改善は、個々の善意や努力に委ねられる、いわゆるボトムアップ的なものではなく、経営の意図として位置づけられ、組織全体に引き受けられるべき営みとして扱われていた。 では、なぜ多くの組織は能力レベル3に一度は到達したように見えても、それを維持できず、再びレベル1・2に戻ってしまうのか。一方で、なぜ一度能力レベル4以上に到達した組織は、その水準をほとんど下回らないのか。この違いは、個々の人材の能力や現場の頑張りによって生じているものではない。能力レベル3の段階では、フォーカスはすでにプロジェクトから組織に移っている。標準プロセスは整備され、改善活動も行われている。「やっていない」わけではない。それにもかかわらず、能力レベル3は不安定になりがちで、維持されにくい。問題は、改善そのものの量や手法ではなく、改善とどう向き合ってきたか、その向き合い方にある。 日本の組織は、長年にわたり、課題が顕在化してから対処する「課題解決型の改善」に強みを持ってきた。品質問題が発生すれば徹底的に原因を究明し、個別のプロジェクトとしては高い完成度に持っていく。その力は、世界的に見ても極めて高い水準にあった。一方で、A-SPICE や CMMI に代表されるプロセス改善モデルに対して、世界で確立されつつあるベストプラクティスを、そのままの形で学び、自分たちの事業に引き直して引き受けるという向き合い方は、必ずしも強くなかった。これらのモデルは、もともと欧米の研究者が日本の製造業、とりわけ生産方式とカイゼンを徹底的に研究し、曖昧になりがちなノウハウや暗黙知を理論化・形式知化しようとした試みから生まれている。言い換えれば、CMMI や A-SPICE は、「日本のやり方を否定するためのもの」ではなく、日本の強みを世界基準で捉え直し、誰もが再現できる形にするためのグローバル標準として発展してきたものである。 しかし日本では、それらのモデルはしばしば評価対応や要求対応の道具として理解され、プロジェクト単位で真面目に適用されてきた。課題解決型の改善が得意であったがゆえに、目の前の問題に対応することに重心が置かれ、外部で積み重ねられてきた改善の知を、経営として引き受け続けるという営みは、必ずしも中心的な関心にはなりにくかった。その結果、改善は「できる人」「頑張る人」に依存しやすく、組織として守られるものにはならない。忙しさや人事異動、環境変化が起きれば、優先順位は下がり、能力レベル3の状態は容易に崩れてしまう。これは、改善が個人の姿勢や努力に委ねられ、 組織としての役割や責任として設計されていないことを意味している。 一方、能力レベル4以上に到達した組織では、改善は善意や努力に委ねられていない。改善は事業を回し続けるための前提条件として位置づけられ、経営の意思と役割の中に組み込まれている。だからこそ、一度その段階に入ると、元の状態に戻ることがほとんどない。日本の経営者が将来を考えていなかったわけではない。むしろ、日本の自動車産業は長年にわたり、世界的に見ても高い競争力を維持してきた。ただし、その成功体験があまりにも強かったがゆえに、ソフトウェアという分野において世界の最先端がどこまで進んでいるのかと、正面から向き合う必然性が見えにくかったという側面は否定できない。 能力レベル3が維持できない理由は、手法やプロセスが足りなかったからではない。グローバル標準として確立された改善モデルと、経営としてどこまで真剣に向き合い、それを自分たちの事業として引き受ける覚悟があったかどうかにある。 こうした違いを分けているのは、時間でも経験年数でもない。プロジェクトフォーカスから抜け出せるかどうかの分岐点は、経営層が A-SPICE のようなプロセス改善モデルを、評価対応ではなく、事業と組織を設計するためのグローバルスタンダードとして理解し、組織的な活動を自ら主導するかどうかである。 その前提に立った瞬間、能力レベル3は「分からない概念」ではなく、「組織の振る舞い」として認識できるようになる。 ８．このままで、本当にいいのか？ここまで、能力レベル3とは何か、そしてそれがなぜ分かりにくかったのかを見てきた。能力レベル3は、プロジェクトをうまく回すための段階ではなく、プロジェクトを素材として、組織としての仕事の仕方を設計し、学習を回し始める状態である。そして、その正体はプロジェクトの中では決して見えない。それでも、これまで多くの組織はプロジェクト中心の見方に留まり続けてきた。それは誤りだったからではない。組込みソフトウェアが長らく“無償に近いもの”として扱われ、製品価値の中心がハードウェアにあった時代には、その立ち位置で事業が成立してきたからである。 しかし、状況はすでに変わっている。Teslaを見れば分かるように、ソフトウェアは機能の集合体ではなく、事業そのものになりつつある。ADAS、そしてSDVの世界では、製品価値や競争力はソフトウェアによって定義される。ソフトウェアは価値として問われ、有償化の時代に入りつつあり、欧米との直接競争も、もはや避けられない現実である。この環境において、プロジェクト単位での対応を積み重ねるだけで十分なのか。評価要求に応え続けるだけで、事業としての競争力は維持できるのか。ここで問われているのは、やり方ではなく立ち位置である。 能力レベル3はゴールではない。それは、レベル4・5で事業を回すための最低限の土台に過ぎない。能力レベル3を「分からない概念」のままにしておくのか。それとも、組織として引き受け、次の段階へ進む準備を始めるのか。これは評価の都合や一部のプロジェクトの事情で決まる話ではない。組織としての意思決定を伴う選択である。 このままで、本当にいいのか。この問いに、今すぐ明確な答えが必要なわけではないかもしれない。しかし、プロジェクト中心の見方を続けるのか、それとも組織として仕事の仕方を設計する立場に立つのか。その選択を意識しないまま進むことだけは、避けるべきだろう。能力レベル3とは、何かを新しく付け加えた結果として得られる到達点ではない。どこに立って仕事を見るのか、その視点を選び直したときに、あとから振り返って「そこにあった」と気づく状態に過ぎない。答えは、モデルや評価の中にはない。組織自身の選択の中にしか存在しない。 （日吉 昭彦）

コラム

Automotive SPICE 能力レベル３とは何か？　ー それは「プロセスの話」だけではない　（前編）

１．はじめにAutomotive SPICE（以下、A‑SPICE）の能力レベル3という言葉から、多くの組織が思い浮かべるのは「組織標準プロセスの整備」や「標準化されたやり方が定義されている状態」ではないだろうか。実際、能力レベル3はそのような文脈で語られることが多い。しかし、それは能力レベル3がもたらすの“結果の１つ”であって、“本質”ではない。能力レベル3が本来問いかけているのは、プロジェクト依存のやり方から脱却し、組織として仕事の仕方を意図的に設計し、再利用可能な形で運用できているか、という一点に尽きる。そしてこれは、決して個々のプロジェクトの努力だけで到達できるレベルの話ではない。 本来、能力レベル3はプロセス改善モデルの中で、組織としての力を高めていくために、改善を継続的に推進できる状態を指している。プロセス定義は、そのために不可欠な手段の一つではあるが、目的そのものではない。改善を通じて組織力を引き上げるという狙いがあってこそ、プロセスは意味を持つ。にもかかわらず、A‑SPICEの文脈では、能力レベル3が「プロセスを整備したかどうか」という見えやすい側面で捉えられがちであった。その背景には、A‑SPICEがサプライヤー評価モデルとして使われてきた歴史や、プロジェクト中心で読まれやすい構造がある。 本稿では、まず能力レベル3の考え方を起点として、レベル2との決定的な違いを整理し、PPTトライアングル（People・Process・Technology）が示すレベル3の本質を確認する。その上で、なぜA‑SPICEの文脈では、この本質が見えにくくなってきたのかを整理する。なお、本稿は前編として位置づけ、能力レベル3の理解と、その誤解が生まれた背景までを扱う。  ２．能力レベル２との決定的な違いー 「守る」から「設計する」能力レベル2と能力レベル3の違いは、しばしば「標準プロセスがあるかどうか」や「組織で統一されているかどうか」といった表層的な比較で語られる。しかし、それでは能力レベル3の本質を捉えたことにはならない。 能力レベル2までの世界では、プロセスの主語はあくまでプロジェクトである。計画を立て、進捗を管理し、レビューを行い、成果物を管理する。つまり、「決められたことを守れているか」「管理が回っているか」というプロセスの状態が焦点となる。言い換えれば、決められたことを守れているか、が問われる世界である。この段階では、プロジェクトマネージャの力量や、プロジェクト固有の流儀が大きな影響を持つ。うまく回っているプロジェクトは確かに存在し、成果も出る。しかし、それは「そのプロジェクトがうまくいった」という事実に留まり、なぜうまくいったのかが組織として説明できるとは限らない。 能力レベル3で起きるのは、この問いの変化である。 そのプロセスは、誰が何を意図して設計したのか なぜそのプロセスが選ばれているのか プロジェクトごとの違いを踏まえ、どのようにテーラリングするのか 組織として、プロセスをどのように進化させていくのかここで初めて、プロセスは「守るべきルール」ではなく、「意図を持って設計され、使いこなされ、変えていく対象」として扱われるようになる。 レベル3とは、プロセスを単なるルールやチェック対象として扱う段階から、組織の知的資産として扱う段階への転換である。プロセスを通じて、組織としてどのような仕事の仕方を選び、どのように改善していくのかを考え、実行できる状態に移行することを意味している。能力レベル2が「プロジェクト運営を安定させる状態」だとすれば、能力レベル3は「組織としての仕事の仕方そのものを設計する状態」であり、質的に異なる段階なのである。この違いを理解せずに能力レベル3を目指すと、「決め事を増やす」「文書をそろえる」といった活動に陥りやすい。しかしそれは、レベル2の延長線上でできることに過ぎず、レベル3が本来求めている転換点を越えたことにはならない。  ３．プロセスだけでは組織は変わらないーPPTトライアングルが示すレベル３の本質CMMIの世界では古くから、能力レベル3を説明する際に PPTトライアングル（Process・People・Technology） が語られてきた。これは今でも、能力レベル3の本質を的確に突いた考え方である。能力レベル3を「組織標準プロセスを整備する段階」と理解してしまう組織が多い理由の一つは、プロセスという要素が最も目に見えやすく、説明もしやすいからだ。しかし、第2章で述べたように、能力レベル3が目指しているのはプロセスそのものではない。組織として仕事の仕方を設計し、継続的に進化させていく力にこそ本質がある。その前提に立つと、「プロセスだけでは組織は変わらない」という現実が見えてくる。 PPTトライアングルは、CMMIなどのプロセス改善のノウハウとして広く知られるようになったが、その考え方自体は新しいものではない。起源をたどれば、リービットのダイヤモンド・モデルに行き着く。リービットのモデルは、組織を「仕事」「人」「技術」「組織構造」という要素の相互作用として捉え、どれか一つだけを変えても、組織は意図したとおりに変わらないことを示したものである。PPTトライアングルは、この考え方をプロセス改善という実務の文脈で簡潔に整理し直したものだと理解できる。 ここでは、PPTを構成する People・Process・Technology の三要素を取り上げる。ただし、これらを独立した要素として説明する意図はない。三つは相互に影響し合いながら、組織としての仕事の仕方を設計・進化させていくための要素である。  Peopleもっとも重要でありながら、もっとも変化に時間がかかる要素が「人」である。ここで言う「人」とは、単に人数を指すものではない。作業を遂行するためのスキルや技術力、その使い方、さらにはそれを支える文化や価値観を含めた概念である。能力レベル3で問われる「人」とは、プロセスを守るための存在ではない。実際の作業を確実に遂行するために必要なスキルや技術力を備え、それを継続的に向上させていくことが求められる。人の能力が高まれば、より高度なプロセスや技術が必要となり、その結果としてプロセスも変わっていく。人の成長は、プロセス改善の前提条件である。 Processプロセスは固定的なルールではなく、人の能力や使われる技術を前提として設計され、必要に応じて見直されるべきものである。誰が何を意図して設計したのか、なぜそのプロセスが選ばれているのかが説明できなければならず、常に改善の対象として意識されていなければならない。人や技術の成熟なしに、プロセスだけを高度化することはできない。 TechnologyTechnology は、QCD や生産性を向上させるために、設計・実装・テストといった開発活動をどのように支えるかという観点で捉える必要がある。設計やテストに関する新しい技術の導入、使用するツール類の選択、開発環境の整備は、いずれも成果に直結する重要な要素である。重要なのは、技術やツールを単に導入することではなく、人のスキルや能力、そしてプロセスの設計と整合した形で活用されているかという点である。新しい技術の導入は、必要とされるスキルや作業の進め方を変え、結果としてプロセスの見直しを促す。この意味で Technology は、People や Process とは独立した要素ではなく、組織として成果を引き上げていくための重要な構成要素である。適切に選択・活用された Technology は、人とプロセスの力を増幅し、QCD や生産性の継続的な向上を支える。 このように、People・Process・Technology は独立して存在するものではない。どれか一つの軸だけが伸びても、組織全体としての成果（QCDや生産性）は頭打ちになる。三つの要素が相互に影響し合いながら、スパイラル的に伸びていく状態を作って初めて、組織の力は継続的に向上していく。 能力レベル3における組織とプロジェクトの関係能力レベル3においては、改善が組織として回り始め、その結果として、組織とプロジェクトの役割分担と関係性が具体的な形を取るようになる。組織は、標準プロセス、プロセス部品、テンプレート、ツール、テーラリングガイド、そしてプロセス実績データベースといったプロセス資産ライブラリを整備し、プロジェクトに提供する役割を担う。プロジェクトは、これらの標準プロセスや過去の実績データを参照しながら、プロジェクトの特性に応じたプロジェクト用プロセスを設計し、それを前提としてプロジェクト計画を作成する。プロジェクトは設計したプロジェクトプロセスに従って運営され、その結果として得られた実績データが、再び組織のプロセス実績データベースに蓄積されていく。この組織とプロジェクトの間で回るPDCAこそが、能力レベル3における改善の実体である。改善はプロジェクトの中だけで完結するのではなく、組織によって集約され、次のプロジェクトに活かされることで、組織全体としての能力が高まっていく。  帰結として現れるプロセス定義の変化このような前提でプロセス改善が継続的に行われていくと、プロセス定義の在り方そのものも変わってくる。改善が一過性ではなく、PPTの3要素が組織的に回り始めると、プロセスは単なる手順書の集合では維持できなくなる。どの作業がどの目的を持ち、どの成果に結び付いているのか、そして変更がどこに影響するのかを、組織として把握できる形が必要になるからである。その結果として、プロセス定義は必然的に、いわゆるプロセスモデリングに基づいた、よりフォーマルな形へと移行していく。ここで言うプロセスモデリングとは、業務や開発における作業の流れや役割、成果物、相互関係を構造的に表現し、変更や改善の影響を組織として把握・管理できるようにすることを指す。具体的な文書化の考え方やテクニックについては、弊社コラム「プロセスモデリング  〜 プロセス文書化のテクニック」も参照していただきたい。重要なのは、プロセスのフォーマル化そのものが目的なのではなく、改善を継続可能なものにするための自然な帰結として現れる点にある。レベル3におけるプロセスモデリングは、成熟の証明ではなく、改善が組織の中で本当に機能し始めた結果だと言える。  ４．なぜ、この誤解は生まれたのかーAutomotive SPICEという枠組みが生んだ構造的なズレ前章までで見てきたように、能力レベル3は本来、People・Process・Technology を通じて組織としての力を高めていくための入口であり、単なるプロセス定義の段階ではない。しかしA‑SPICEの文脈では、能力レベル3が「組織標準プロセスを整備する段階」として理解されるケースが少なくなかった。この誤解は、特定の組織や個人の理解不足によって偶然生じたものではない。A‑SPICEというモデルがどのような目的で設計され、どのような文脈で使われてきたかを振り返ることで、その背景は構造的に説明できる。サプライヤー評価モデルとして使われてきたA‑SPICEA‑SPICEは、欧州OEMがサプライヤーを評価するための枠組みとして発展してきた。その主眼は一貫して、OEMに影響を与える開発リスクの可視化と低減にある。評価の対象となるのは、あくまで進行中、あるいは予定されているプロジェクトであり、プロジェクトが安定して遂行されるかどうかが最重要関心事であった。この文脈において、能力レベルは「将来に向けた組織変革の成熟度」を測る尺度というよりも、プロジェクトをどの程度安心して任せられるかを判断するための指標として受け止められてきた側面がある。 プロジェクト視点で読み取られた能力レベル３こうした文脈の中では、能力レベル３は自然と、 プロジェクト間で共通に使えるものがあるか 標準化されたプロセスが存在するかといった観点で理解されるようになる。これは、プロジェクトの安定化という目的に照らせば合理的な読み方であり、誤りと断じることはできない。ただし、この理解はプロジェクトを中心に据えた解釈であり、第3章で述べた「People・Process・Technologyを意図的に育て、組織力を高めていく段階」という能力レベル3本来の姿とは、焦点が異なっている。このズレが積み重なった結果、能力レベル3は次第に「組織標準プロセスを整備した状態」とほぼ同義に扱われるようになっていった。 組織としての改善が前面に出にくいモデル構造もう一つ見逃せないのが、A‑SPICEのモデル構造そのものである。A‑SPICEは、開発や管理に関するプロセスを中心に構成されており、人材育成、インフラ整備、測定・分析、継続的なプロセス改善といった組織的活動は、前面には現れにくい構成になっている。CMMIなどのプロセス改善モデルでは、「組織標準プロセス定義」、「組織プロセス改善」、「組織トレーニング」、「測定と分析」といったプロセスが組織プロセス群として定義されている。一方A‑SPICEでは、唯一「PIM.3（プロセス改善）」プロセスが選択されているだけで、「やるべき活動がわからない」という状態になりやすい。このため、能力レベル3を目指す組織の多くが、 まずプロセス文書を整える プロジェクトでそれを使っていることを示すというアプローチに集中し、People や Technology、さらには改善を回すための組織的な仕組みが必要だという発想に至るのは容易ではなかった。なお、組織系プロセスが欠落していることの詳細については、A-SPICEの成り立ちや他のプロセス改善モデルとの比較という観点から、弊社の別コラム「Automotive SPICEの活動を効率良く進めるために」で詳細を整理しているので、併せて参照していただきた。。 誤解は「間違い」ではなく「帰結」であるこうして見てくると、A‑SPICEにおける能力レベル3の理解は、誰かが本質を取り違えた結果として生まれたものではなく、A‑SPICEがサプライヤー評価モデルとして設計され、プロジェクトを中心に使われてきたという背景の中で、自然に形成されてきた理解だと言える。問題は、その理解が固定化され、「能力レベル3＝プロセス定義」というイメージだけが残ってしまった点にある。本来、能力レベル3は、People・Process・Technologyを意図的に育て、組織としてQCDや生産性を継続的に高めていくための出発点に過ぎない。あらためてレベル3の意味を問い直すここまでが、本稿（前編）で整理してきた内容である。能力レベル3を到達点として捉えるのか、それとも次の段階へ進むための入口と捉えるのか。その違いは、改善活動の進め方だけでなく、組織がどこを向いて変わろうとしているのかを映し出す。続く後編では、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、そしてそれが事業運営や競争力とどのようにつながっていくのかを考察し次のテーマを取り扱うつもりである。後編はこちらから。 レベル3はゴールではない ― レベル4・5が示す世界 20年後を語る企業と、目の前を語る企業 プロジェクトフォーカスから、いつ抜け出すのか このままで、本当にいいのか （日吉昭彦）

コラム

制御仕様書という怪物　～　世界標準とプロセスはズレているのに何故品質は良いのか？　～

１．初めに － Automotive SPICE と制御仕様書「制御仕様書」。筆者にとって、長年自動車業界に向き合ってきた中でも、とりわけ扱いに困る存在である。Automotive SPICEと正面から向き合おうとした瞬間、この文書は必ず行き場を失う。Automotive SPICEの成果物として当てはめようがない。かといって、「これは間違っている」「不要だ」と一刀両断できるほど単純でもない。内容そのものは決して無意味ではなく、むしろ多くの現場で実際に機能してきた歴史がある。だからこそ厄介なのである。 Automotive SPICE の成果物に、日本の「制御仕様書」をきれいに当てはめられた人は、果たしてどれくらいいるだろうか？SYS.2なのか、SYS.3なのか？あるいは、SWE.1なのか、SWE.3なのか？ 真剣に考えれば考えるほど、どれにも完全には当てはまらない。そして一度は「今回はこれでいこう！」と割り切ったはずの整理が、時間を置くと再び蒸し返され、同じ議論を繰り返すことになる。筆者にとって「制御仕様書」とは、できることならなるべく触れずに済ませたい、そんな難物だった。 一方で、日本車の品質が世界最高水準にあることに異論を唱える人は少ないだろう。この事実を踏まえると、制御仕様書を単純に「悪者」として片付けることにも、強い違和感を覚える。 当てはめられない成果物でありながら、品質は高い。この一見矛盾した状況の背景には、日本独自の開発文化と、その象徴ともいえる「制御仕様書」の存在があるのではないか？そう考えるようになった。 本コラムでは、これまで業界内でもあまり正面から語られてこなかった、ある種「アンタッチャブル」な領域に踏み込み、制御仕様書を起点として日本の車載ソフトウェア開発の実態を整理し、筆者なりの見解を述べてみたい。その性質上、通常のコラムよりも記述は長くなってしまった。しかし、それは論点をぼかさず、背景・因果・限界まで含めて整理しようとした結果でもある。本コラムが、制御仕様書や Automotive SPICE に違和感を抱いてきた読者にとって、考えるための材料となれば幸いである。 ２．制御仕様書に感じる違和感の正体本題に入る前に、日本の多くの車載開発現場で作成されている「制御仕様書」とは、具体的にはどのような内容を含んでいるのかを整理しておきたい。筆者がこれまで目にしてきた制御仕様書には、多くの場合、以下のような内容が一つの文書の中に同時に記載されている。 実現したい要求 車両またはECUとしての振る舞い 制御ロジックや状態遷移 ソフトウェアが実装すべき内容 例外処理やフェイルセーフの考え方全体を通して見ると、「このシステムを、このように作ってほしい」という意図を記述した文書のように見える。また、作成者は必ずしもソフトウェアやハードウェアの専門技術者とは限らず、プロジェクト全体の取りまとめ役や、制御・車両側の担当者であるケースも少なくない。 ここまでは理解できる。しかし、筆者が根本的な違和感を覚えるのは、これらの内容が制御仕様書として提示された結果、ソフトウェア技術者が、その記述通りに関数設計を進めてしまう点である。本来であれば、要求を受け取った上で、ソフトウェアの専門家が、ソフトウェアとして最適な構造を検討し、機能をどう分割し、どこに配置するかを設計すべきである。ところが制御仕様書が詳細に書かれているほど、「まずは書かれている通りに作る」という流れが生まれやすくなる。 この違和感について、実際に現場の担当者に問いかけたことがある。その際に帰ってきた答えは、次のようなものだった。 「制御仕様書がないとソフトウェアが作れない。」 「制御仕様書があれば、その通りにソフトウェアを作るだけだ。」この言葉は、制御仕様書が果たしている役割の大きさと同時に、問題の核心を端的に表しているように感じられた。 筆者の視点では、制御仕様書とは、システム全体としての機能的な振る舞いを記述した文書であり、ソフトウェアをどのように実装するかを直接指示するものではない。言い換えれば、制御仕様書はソフトウェアへ割り当てられる前段階の「システム的な振る舞い」を定義しているものと捉える方が自然ではないかと考えている。その意味では、制御仕様書に記載されている内容は、ソフトウェアへ割り当てられたシステム要求として理解することも、一つの解釈である。もし、その振る舞いの検討段階からソフトウェアの専門家が深く関与し、処理概要や構造上の制約を織り込んだ上で記載されているのであれば、また異なる評価も成り立つだろう。 興味深いことに、この制御仕様書に対応する明確な英語名称を、国際標準や各種規格の中で見つけることはできなかった。類似する文書は存在するものの、日本で一般に使われている制御仕様書と同じ役割・粒度を持つ成果物は見当たらない。このことからも、制御仕様書はグローバルな視点で見ると、かなり特異な存在であることがうかがえる。そしてこの問題は、特定の企業や組織の事情というよりも、日本の車載開発に広く共通する構造的な特徴であるように思われる。 この違和感を起点として、次章では、そもそもなぜ制御仕様書がこのような形で発展してきたのか、その歴史的背景を掘り下げてみたい。 ３．制御仕様書が生まれた歴史的な背景制御仕様書が現在のような姿になった背景について、筆者は「開発文化の欠陥」ではなく、歴史的な必然性として捉えるべきだと考えている。車載開発は、その長い歴史の大部分において、メカニカルとワイヤー、油圧を中心とした世界で成立してきた。その時代では、システムの振る舞いは、物理的な構造と機械の動きによって実現されており、設計者とって重要だったのは、「入力と出力の関係」や「状態遷移」、「メカとワイヤーを通した制御の流れ」といった点に集約されていた。このような世界においては、システム全体の振る舞いを一貫した形で記述することが合理的であり、それを担う文書が必要とされた。制御仕様書は、まさにこの文脈の中で生まれたものだと推測できる。 やがて、制御の実現手段としてソフトウェアが導入される。しかし、当初のソフトウェアは、あくまでメカニカルとワイヤーによる制御を置き換える手段として捉えられていた。制御対象の本質が変わったわけではなく、実現手段が変わったにすぎない、という認識が支配的だったと考えられる。そのため、「要求と設計を厳密に分ける」「抽象度の異なるレイヤーを明確に定義する」といったソフトウェア工学的な思考は、当時は開発の中心的なテーマではなかった。重要なのは、システムとして意図した振る舞いを、確実に実現できるかどうかであり、そのための記述として、従来の制御仕様書の枠組みがそのまま踏襲された。結果として、制御仕様書には、 システムとしての振る舞い 制御ロジック 実装上の注意点といった内容が次第に積み重なっていった。これは設計上の誤りというよりも、既存の思考様式の中で、新しい技術を取り込んでいった結果であると理解する方が自然である。このように捉えるならば、制御仕様書とは、メカニカルと制御工学が主導してきた時代に培われた現場の知恵と経験が凝縮された成果物だと言える。現在の視点から見れば整理不足に映る部分もあるが、それは当時の前提条件のもとでは、極めて合理的な選択だった可能性が高い。 この歴史的背景を踏まえることで、制御仕様書を単なる「古い慣習」や「是正すべき悪習」として扱うことの危うさにも気づかされる。問題は、過去の選択そのものではなく、前提条件が大きく変化した現在において、その役割を再定義できているかどうかにある。 次章では、この歴史的背景を踏まえ、日本と欧米で開発アプローチがどのように分岐していったのかを見ていく。 ４．欧米との決定的な分岐点日本と欧米のソフトウェア開発の違いは、技術力の優劣によるものではない。筆者は、開発の重心をどこに置いてきたかの違いが、その後の進化の方向性を分けたと考えている。欧米では比較的早い時代から、ソフトウェアが製品開発の中核として位置付けられてきた。制御対象が同じであっても、それをどのように記述し、どのように分解し、どのように責任分担するかという点に、強い関心が向けれらていた。その結果として、次のような考え方が段階的に定着していく。 要求（What）と設計（How）を明確に分離する 成果物と責任範囲を明文化する 大規模ソフトウェアを前提とした抽象化とレイヤー化 プロセスの妥当性によって品質を担保するという発想これらは単なる開発手法の違いではなく、不確実性をいかに制御するかという思想の違いでもある。 この背景には、欧米の社会構造や文化的要因が強く関係していると考えられる。多民族・多文化社会においては、個々人のバックグラウンドや価値観が異なることが前提となる。その中で協働を成立させるためには、暗黙の了解ではなく、明文化されたルールや契約が不可欠となる。すなわち、 役割を明確にし 責任範囲を定義し 成果物によって合意を形成するという開発スタイルが、社会的にも合理性を持っていた。 一方、日本では、状況は大きく異なっていた。車載開発の中心には、あくまで車両性能があり、その品質は実車評価や現場での調整によって作り込まれてきた。設計と評価、開発と調整は明確に分断されるものではなく、むしろ密接に結びついていた。成果物の境界を厳密に切るよりも、「同じものを見て同じ理解を持つ」ことの方が重要だったのである。その結果、日本では制御仕様書という形で、要求、設計意図、制御ロジック、注意点が一つの文書に集約されていった。一方、欧米では同じ情報を、レイヤーごとに分解し、それぞれ異なる成果物として管理する道を選んだ。 重要なのは、どちらも各々の前提条件においては合理的な選択だったという点である。日本は「現場で品質を作る」道を、欧米は「プロセスで品質を保証する」道を歩んできた。その違いが、制御仕様書のあり方や、成果物の構成として表れただけだと整理できる。弊社では、「日本と欧米におけるソフトウェア開発アプローチの違い」というコラムを掲載しているので、こちらも参考にしていただきたい。 次章では、このような背景を踏まえた上で、なぜ日本の車載開発が結果として高い品質を維持してきたのか、その因果関係を整理していきたい。 ５．なぜ日本製品は高品質なのか？ここで一度、日本の車載開発が高い品質を維持してきた理由について、因果関係を整理してみたい。日本の多くの開発現場では、要求と設計が明確に分離されておらず、制御仕様書に多くの情報が集約されている状況が、今も一般的に見られる。この状況は、グローバルスタンダードの開発プロセスに照らせば、抽象度が揃っておらず、成果物の境界も曖昧で、工学的・プロセス的には未成熟に見えることは否めない。しかし重要なのは、この構造が必ずしも品質低下に直結してこなかった、むしろ逆の結果を生んできたという点である。 制御仕様書という形で、実現したい要求、システムとしての振る舞い、制御ロジック、例外時の考え方までが一つの文書に集約されることで、関係者が共有する文脈は極めて強固なものになる。設計、実装、評価に関わるメンバーが、同じ前提条件のもとで議論を行いやすくなるのである。その結果、設計段階では、「これは正しい動きか？」、「もっと良い方法論はないか？」あるいは「ここでエラーが発生したらどうすれば良いか？」といった検討が、要求・設計・実装を横断した形で行われやすくなる。議論の焦点は、「仕様に書いてあるから正しい」という形式的な妥当性ではなく、「実際の振る舞いとして妥当かどうか」に置かれる。さらに日本の開発では、机上で仕様を完結させるよりも、実際に動かして確認することが重視されてきた。実車や実機を用いて挙動を確認し、問題があれば調整する。必要であれば、仕様そのものを見直す。この一連のプロセスが、暗黙の前提として開発サイクルの中に組み込まれてきた。このような反復的な確認と調整の積み重ねによって、日本の品質は次第に作り込まれてきたと言える。 つまり、日本の品質は、 設計段階で完全性を保証することによって守られる品質ではなく 現場での確認、修正、潰し込みを通じて形成される品質として形成されてきたと言える。 このアプローチは、想定外事象や実使用条件への耐性を高めるという点で大きな効果を発揮してきた。ただし、この品質形成メカニズムは、すべての条件下で普遍的に有効というわけではない。開発対象の規模拡大、ソフトウェアの複雑化、開発スピードへの要求の高まりといった環境変化の中で、このやり方が新たな制約やリスクを生み始めていることも事実である。 次章では、日本方式がこのようにして高品質を実現してきた一方で、なぜ現在、その強みが限界やリスクとして現れ始めているのかについて整理していく。 ６．日本方式の限界とリスク日本の車載開発の方式が、長年にわたり高い品質を実現してきた事実は揺るがない。しかしその一方で、開発環境が大きく変化した現在、この方式が将来に向けてどのような限界やリスクを内包しているのかを冷静に見つめ直してみたい。 文書構造の限界抽象度の異なる情報が混在することで、成果物の役割や責任範囲が曖昧になりやすいという構造的な限界を持つ。特に、レイヤー分離を前提とするグローバル標準に基づく開発プロセスでは、この曖昧さは整合性の低さとして表面化する。その結果： グローバルな分業開発が進めにくい 成果物の責任範囲が不明瞭になる 変更に対する影響の把握に時間を要するといったリスクが顕在化しやすい。これは、国境を超えた多拠点共同開発が世界的に常態化した現在、無視できない制約条件となってくる。 属人性というリスク日本方式の品質は、現場の判断力や調整力、すなわち「人の力」に大きく依存してきた。経験豊富な技術者が、状況を読み取り試行錯誤を重ねながら最適解を導き出す。このアプローチは、過去において大きな成果を生んできた。一方で、この構造は属人性が高く、再現性に乏しいという本質的な課題を抱えている。要員の変更によって判断基準や暗黙知が失われやすく、品質や進め方にばらつきが生じる可能性をはらむ。また、海外拠点や外部パートナーに同様の開発文化を展開することは容易ではない。個人や特定チームの力量に依存する開発モデルは、プロジェクト規模の拡大や組織の分散化に対して脆弱であり、スケールしにくい構造を持つ点がリスクとなる。 アーキテクチャの弱さによる長期的な技術負債のリスク制御仕様書に多くの情報を集約するスタイルでは、個々の制御ロジックを理解するうえで有効だが、ソフトウェア全体を構造として設計・管理することが難しくなる。抽象化やレイヤー化、インタフェースが曖昧になったまま開発が進むと、結果として： アーキテクチャの重要性が意識されにくい プラットフォーム化が進まない ソフトウェア資産の共通化・再利用が困難になるといった状況が生まれやすい。その結果、短期的には大きな問題がなく見えても、長期的には技術負債として蓄積され、将来の変更・拡張時に大きなコストを生むリスクが高まる。また、初期段階でアーキテクチャを確定できない場合、発生し得ない事象にまでDRBFM等の対策工数を割くことになる。一方、スコープを限定し、例外処理が構造化された設計を実現できれば、品質を担保しつつ開発時間を大幅に削減できる。 開発工数の増大と開発期間の長期化という現実的リスクもう一つのリスクとして、開発工数の増大と開発期間の長期化が挙げられる。この問題の本質は、仕様が十分に明確化されないまま開発が進み、後工程ですり合わせによる検討や調整を繰り返す構造にある。多くの現場では、要求や仕様が抽象的な状態で検討や実装に入ることが少なくない。その結果： 不明確な行間や解釈の違いを、すり合わせで解消する 実装してから課題に気づく 実際に動かしながら仕様そのものを調整していくといった進め方が常態化しやすい。このプロセスは最終的な品質向上には寄与するものの、仕様検討と実装・評価が混在した反復作業となり、工数が限りなく膨らむ原因となる。 さらに、ソフトウェアアーキテクチャが十分に設計されていない場合、この傾向は顕著になる。アーキテクチャが不適切であると： 変更の影響範囲の見極めに時間がかかる 修正のたびに広範囲は確認と修正が必要となる 本来不要な検討や後戻りが発生するといった状況が生じ、検討・調整に要する時間が増大する。開発スピードが競争力の重要な要素となっている現在、これらの制約はグローバル競争という観点で、品質とは別の次元で無視できない経営・技術的リスクとなりつつある。 ７．これからのあるべき姿では、これまで見てきた課題に対して、どのような方向を目指すべきなのだろうか。少なくとも、「これまでの日本方式を捨て、欧米方式に全面的に置き換える」という単純な発想は現実的ではないだろう。日本方式は多くの課題を内包しつつも、高い品質を長年にわたって実現してきた。その強みを切り捨てることは、合理的な選択とは言い難い。一方で、ソフトウェアが製品価値の中核となった現在、ソフトウェア工学に基き、仕様や設計を階層化し、構造として管理していくことが不可欠であることも明らかである。これまで述べてきた内容は、日本の車載ソフトウェア開発の「実態」を整理したものであり、理想論ではない。実際、日本の製品開発においても、車載分野以外を見れば、ソフトウェアを中心とした高度なシステム開発や、IT系ソフトウェアでは、従来からソフトウェア工学に基づく開発手法が導入されてきた。特に、日常的にグローバル競争にさらされている事業領域においては、もはやそれが当然の前提条件となっている。 筆者自身も、日本方式と欧米方式を完全に統合した「唯一の正解」を提示できるわけではない。しかし、少なくとも一つの方向性として以下の考え方は共有されるべきだと考えている。まず、ソフトウェア工学に基づいたプロセスと成果物を、製品開発の前提条件として明確に位置付けることである。特にソフトウェアにおいては、製品のマスターとなる要求仕様書や設計書が存在しなければ、保守、機能拡張、再利用は著しく困難になる。グローバルなリソース活用や多拠点開発においても同様である。現在の製品開発では、新たにスクラッチからソフトウェアを開発するケースはむしろ少なく、多くは既存製品に対する拡張や機能追加である。マスターとなるドキュメントは、プロジェクトごとに毎回に作り直すものではない。一度整備されていれば、その後の改版工数は相対的に小さく抑えられる。 その上で、派生開発や機能追加の局面において、日本方式の強みを意図的に活用するのである。具体的には、追加する機能に対して、その制御の流れを記載した「変分仕様書」を作成する。これは従来の制御仕様書に近い形態を持つが、重要な違いとして、修正部分を「変更前」と「変更後」という形で明示的に記述する点が挙げられる。変更内容は常にマスタードキュメントの差分として取り扱われ、プロジェクトの完了までに、その差分をマスタードキュメントへ反映（改版）していく。こうすることで： マスター文書による構造的な整理と再利用性 変文仕様書による現場主導の調整力と具体性を両立することが可能になる。「変分仕様書」を導入したプロセスや、具体的なドキュメントの例については、次の機会で紹介する。 最後に、視野を広げて歴史を振り返りたい。携帯電話、液晶テレビ、通信制御システム、通信サービスなど、日本がかつて世界をリードしていたにもかかわらず、世界標準の流れに乗り切れなかった製品・技術は少なくない。その多くは、国内での成功体験に安住し、構造的な変化への対応が遅れた結果、競争力を失っていった。 自動車産業は、日本にとって極めて重要な事業領域である。だからこそ、同じ歴史を繰り返してはならない。そのためには、「日本方式か、欧米方式か」という二項対立ではなく、強みを理解した上での意識的な再設計が求められている。この課題に対して、単独の正解は存在しない。しかし、問題を正しく認識し、共に改善の方向を探り続けること自体が、最も重要な第一歩であるはずだ。ご不明点、ご質問、ご相談事項あれば弊社ホームページのお問い合わせからご連絡ください。 （日吉昭彦）

コラム

Automotive SPICEは守っているのに、なぜ機能しないのか　― WhatとHowの混同から読み解く設計思想 ―

Automotive SPICE（A-SPICE）は、車載ソフトウェア開発におけるプロセス能力を評価するためのアセスメントモデルです。当社では先日、「ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために～」というコラムの中で、SPICEを含む複数の枠組みを用いながら、開発組織をどのように評価し、改善につなげていくかを整理しました。また、これまでのコラムでも、「ドキュメントが作られているが活用されていない」「プロセスが形骸化している」といった課題が現場で起きやすいことを指摘してきました。 しかし、それらは“現象”としては共有されているものの、なぜ起きるのか、どうすれば防げるのかまでは十分に整理されていないケースも少なくありません。本コラムでは、これらの前提を踏まえたうえで、A-SPICEを「評価モデル」として説明するのではなく、「なぜその評価項目が定義されているのか」という観点から読み直します。言い換えると、A-SPICEを「評価のための枠組み」としてではなく、「開発で問題が起きやすいポイントを示した設計思想」として捉え直す試みです。現場でよく聞かれる、「やるべきことはやっているはずなのに、なぜかうまくいかない」という違和感を、この観点から整理していきます。 A-SPICEは「What」を定義するモデルであるA-SPICEはアセスメントモデルであり、「何ができているべきか（What）」を定義しています。例えば、 要求が適切に管理されていること レビューが実施されていること トレーサビリティが確保されていることといった状態が評価対象になります。一方で、A-SPICEは「それをどのように実現するか（How）」までは規定していません。 問題の本質：WhatをそのままHowにしてしまう現場でよく起きるのが、このWhatをそのままHowとして標準プロセスに落とし込んでしまうケースです。例えば、「レビューを実施する」という評価項目に対して、「レビューを実施する」という手順だけが定義される。一見すると問題はなさそうですが、ここには重要な抜けがあります。 具体例：レビューが“機能しない”ときに起きていることあるプロジェクトで、レビューは確実に実施されていました。チェックリストもあり、記録も残っています。しかし、後工程で仕様の解釈違いによる不具合が繰り返し発生していました。レビュー記録を見てみると、指摘の多くは 表記ゆれ 記述の抜け 軽微な整合性といったものでした。一方で、 前提条件の認識が揃っているか 想定しているユースケースが一致しているか 例外時の振る舞いが明確かといった観点は、レビューの中でほとんど扱われていませんでした。つまり、レビューは「実施されている」が、認識のずれを検出する仕組みとしては機能していなかったのです。これは、「レビューを実施する」というWhatに対して、「何を確認するのか」というHowが設計されていなかったことに起因します。 なぜ“認識のずれ”は起きるのかでは、なぜこのようなことが起きるのでしょうか。その背景には、人の認知の特性があります。本コラムで扱っている問題は、操作ミスのような単純な誤りではなく、仕様や前提の解釈違い、思い込み、見落としといった“認識のずれ”によって生じるものです。人は、書かれていない前提を無意識に補完して読みます。そのため、同じ文章を読んでも、前提や経験によって解釈がずれることがあります。本来、レビューやトレーサビリティといった活動は、こうした認識のずれを早期に検知し、修正するための仕組みです。しかし、その意図が共有されないまま形式だけが定義されると、「なぜやるのか」が抜け落ち、本来検出すべき認識のずれを見逃してしまいます。 なぜ再現性が生まれないのかこのWhatとHowの対応が曖昧なままでは、プロセスの再現性を確保することも難しくなります。同じ「レビューを実施する」という定義であっても、何を確認するのか、どのような観点で見るのかが人やプロジェクトごとに異なれば、結果は大きくばらつきます。つまり、「プロセスが定義されている」だけでは不十分で、「同じ結果を再現できる状態になっているか」が重要です。WhatとHowが適切に接続されていない状態では、プロセスは存在していても、安定した成果にはつながりません。 A-SPICEを「地図」として読むA-SPICEの評価項目は、単なるチェック項目ではありません。開発の中で問題が起きやすいポイントに対応して整理されています。 要求 レビュー トレーサビリティこれらはいずれも、認識のずれや思い込みが入り込みやすい地点です。その意味でA-SPICEは、アセスメントモデルであると同時に、「問題が起きやすい場所に印をつけた地図」として捉えることもできます。このように読むことで、「レビューを実施する」ではなく「どの前提が食い違いやすいのか」「トレーサビリティを確立する」ではなく「どの因果関係が切れやすいのか」といった問いに変わり、具体的な改善につながります。 問題が起きやすい地点から手当てする地図があるなら、すべてを同じ力でなぞる必要はありません。重要なのは、自分たちの現場で問題が起きやすい地点を見極め、そこから手当てすることです。例えば、 レビューの観点をあらかじめ定める（例：前提条件が明確か、ユースケースが具体化されているか、例外時の振る舞いが定義されているか） 要求を構文化し（例：EARSなどを活用する）、条件や例外を明示する 変更時に設計・テストまで影響を追う範囲を明確にするといった工夫は、認識のずれが入り込みやすいポイントに直接効きます。大きな仕組みを一気に導入する必要はありません。問題の芽を先に潰すことが重要です。 まとめA-SPICEはアセスメントモデルであり、「何ができているべきか（What）」を定義しています。一方で、それをどのように実現するか（How）は各組織に委ねられています。評価項目をそのまま作業として定義するだけでは、活動は形式化しやすく、プロセスの再現性にもつながりにくくなります。重要なのは、「なぜその項目が求められているのか」を理解し、自分たちの現場に合わせてHowを設計することです。どの工程で認識のずれや思い込みが入り込みやすいのか、という観点でA-SPICEを読み直すことで、問題が起きやすいポイントを把握し、改善の優先順位を見極めることができます。もし、 レビューが機能していないと感じる 要求の解釈が揺れてしまう 変更の影響が追いきれていないといった課題がある場合、それはプロセスが不足しているのではなく、WhatとHowのつながりが十分に設計されていない状態かもしれません。当社では、A-SPICEの評価項目をそのまま適用するのではなく、現場の実情に合わせて「どのように実現するか（How）」を整理し、運用できる形に落とし込む支援を行っています。どこから手を付けるべきかお悩みの際は、ぜひご相談ください。（安部宏典）

トップ新着情報コラム

Contact Us

お問い合わせ

お客様のニーズに応じて、最適なサービスを展開しております。
まずはお気軽にご相談ください。

お問い合わせフォームはこちら