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