Updates

新着情報

コラム

構成管理の基本の「ほ」　～構成管理の要ベースライン／ブランチ／マージを正しく理解する～

はじめにDXやアジャイル開発が進展するなかで、多くの企業がGitやAzure DevOps、GitHubなどの構成管理ツールを活用しています。しかし、ツールを利用していても、「ベースライン」「ブランチ」「マージ」という基本概念を十分に理解していないために、手戻りや品質事故を招くケースは少なくありません。本稿では、過去のコラム「構成管理の基本の「き」～当たり前なことが難しい～」に引き続き、構成管理の中核をなす3つの考え方について解説します。 ベースラインとは何かベースラインとは、一言で言えば「正式に承認された基準点」です。システム／ソフトウェア開発では、 要件定義書 基本設計書 詳細設計書 ソースコード テスト仕様書などが特定の時点で確定し、「この版を正式版として扱う」と決定された状態を指します。例えば、要件定義が完了した時点で「Version 1.0」としてベースライン化すると、その後の変更はすべて変更管理プロセスを経て実施されます。 ベースラインの主な目的は以下の3つです。 変更点を明確にする基準となる版が存在するため、「何が変わったのか」を客観的に把握できます。 品質を保証するレビューや承認を経た成果物を固定化するため、品質が確認された状態を維持できます。 トレーサビリティを確保する障害発生時に「リリースされたどの版で障害発生したのか」を追跡できるようになります。 ベースラインがないプロジェクトでは、「最新版がどれかわからない」という事態が頻発し、品質問題の原因となります。成果物をベースライン対象とするかどうかを判断する決定要因は、その成果物の情報が、プロジェクトにおいてライフサイクル上の過去のベースライン状態へ戻して、そこから再び開発し直したり、再統合をする際に必要となるかどうかによります。 ブランチとは何かブランチ（Branch）は、ベースラインから派生した作業用の分岐です。道路に例えるなら、高速道路の本線から伸びる側道のようなものです。ブランチを利用することで、マスターとなるベースライン内の成果物に影響を与えず、新しい機能開発や不具合修正を進められます。ブランチを利用する理由例えば、製品バージョン1.0がテスト中の状況を考えます。同時に、「新機能開発」「緊急障害対応」「次期バージョン開発」を進める必要がある場合、単一のソースコードでは管理が困難になります。そのため、main├─ new_feature-A├─ Gen_X└─ hotfixのように作業内容ごとにブランチを分けます。ブランチのメリット 並行開発が可能複数の開発者が独立して作業できます。 リスクを低減できる開発途中のコードを本番環境に混在させる必要がなくなります。 変更管理がしやすい機能単位で変更履歴を追跡できます。近年ではGit FlowやGitHub Flowなどの運用モデルが広く採用され、ブランチ戦略そのものが開発プロセスの重要な要素となっています。 マージとは何かマージ（Merge）とは、分岐したブランチの成果を統合する作業です。ブランチで開発した機能を本流（マスタ）へ取り込むことで、成果物として正式版として利用可能になり、他プロジェクトへの転用等が可能な状態になります。マージで発生する課題マージは単純な結合作業ではありません。複数人が同じ成果物を修正している場合、変更競合が発生します。これを「コンフリクト（Conflict）」と呼びます。コンフリクトが起きた場合は、どちらの変更を採用するかを判断しなければなりません。良いマージのためのポイント 小さく頻繁に統合する長期間ブランチを放置すると差分が大きくなり、マージが困難になります。 コードレビューを実施するマージ前に内容を確認することで品質を向上できます。 自動テストを活用するマージによる不具合混入を防止できます。 ベースライン・ブランチ・マージの関係この3つは独立した概念ではなく、一連の流れとして機能します。 つまり、 ベースラインが基準を作る ブランチが変更作業を可能にする マージが変更を統合するという役割分担になっています。そして、マージ後に新たなベースラインを設定することで、次の開発へ進みます。 「ベースライン」「ブランチ」「マージ」を活用した事例は以下のようになります。 この例では、おおよそ以下のように活用しています。 マスターラインで正式なベースラインを作成し、次期バージョン用の開発ラインのブランチを作成する 開発ラインから、必要に応じて、機能追加や機能変更を並行開発するための開発ブランチ１＆２を作成する マスターラインの不具合対処するため、緊急対応するためのブランチを作成し、対応完了＆承認後にマージする レビューを経て、品質保証されたものを、開発ブランチから開発ラインにマージする リリースが認められたものを、開発ラインからリリース用のブランチを作成する リリースされたものをマスターラインにマージし、新しいベースラインを作成する さいごに構成管理は単なるバージョン管理ではありません。組織として成果物の品質と整合性を維持するための重要な仕組みです。 ベースラインは「公式な基準点」 ブランチは「安全な作業領域」 マージは「成果物の統合」という役割を理解することが重要です。プロジェクトの規模が大きくなるほど、この3つの適切な運用が、生産性と製品品質に直結します。構成管理ツールの機能を使いこなすだけではなく、その背景にある構成管理の考え方を理解することが、変化に強い開発組織への第一歩となるでしょう。 内山哲三

コラム

プロジェクト管理トレーニングを「良かった」だけで終わらせない、3つの仕掛け

プロジェクト管理トレーニングやAutomotive SPICE教育を実施しても、現場の行動がなかなか変わらない。車載システム・ソフトウェアの開発現場では、こうした悩みを抱える管理者や改善推進メンバーの方も多いのではないでしょうか。せっかく時間とコストをかけて実施するトレーニングです。できることなら、知識の習得だけで終わらせず、現場での行動変容や成果創出につなげたいものです。今回は、なぜトレーニング後に現場が変わらないのか、そして教育効果を現場へ定着させるために必要なことについてお伝えします。 ◇「トレーニングは良かった。でも現場は変わらなかった。」Automotive SPICEやプロジェクト管理のトレーニングを受講したエンジニアが職場へ戻ると、気づけば以前と同じ仕事の進め方に戻っている。そんな経験はありませんか。トレーニング受講直後のアンケートでは、受講者から・「内容が分かりやすかった」・「新たな気づきがあった」・「業務に役立つ知識を得られた」といった前向きな評価が並びます。しかし数か月後になると、現場では大きな変化が見られない。結果として、・「トレーニングの効果が見えない」・「教育投資が成果につながらない」・「また単なるトレーニングイベントで終わってしまった」という声が聞かれるようになります。 ◇現場が変わらないのは、受講者の問題ではないこのような状況になると、「学んだことを実践しなかったのではないか」「受講者の意識が低かったのではないか」という話になりがちです。しかし、多くの場合、受講者個人の問題ではありません。トレーニングで学んだ内容を現場で試す機会がなく、周囲も同じ考え方や共通言語を持っていない環境では、行動を変えることは容易ではないからです。たとえば、プロジェクト管理トレーニングでリスク管理やスコープ管理の重要性を学んだとしても、実際のプロジェクトで活用するきっかけがなければ、その知識は定着しません。また、受講者が新しい考え方を持ち帰ったとしても、・上司が同じ概念を理解していない・チーム内で共通認識がない・実践を振り返る場がないという状況では、学びを継続的な行動へつなげることは難しくなります。車載システムやソフトウェアを含む自動車開発の現場では、品質問題への対応や開発スケジュールの遵守が優先されます。そのため、新しい取り組みを試そうとしても、目の前の業務に追われて従来のやり方へ戻ってしまうケースは少なくありません。つまり、現場が変わらない原因を個人に求めるのではなく、学びを定着させる仕組みの有無に目を向けることが重要なのです。 ◇トレーニング効果の定着に必要なのは「仕掛け」プロジェクト管理トレーニングを実施しても現場が変わらない理由は、受講者の問題ではなく定着の仕組みにあります。Automotive SPICE教育にも通じる、現場で使える3つの仕掛けを解説します。 ① トレーニング直後に小さく試せる実践の場をつくる学んだ知識は、できるだけ早く現場で使うことが重要です。例えば、・WBSを見直す・スコープを整理する・リスク一覧を作成する・ステークホルダーを洗い出すといった小さな取り組みでも構いません。知識を実際の業務へ適用することで、「知っている」が「使える」に変わります。 ② 管理職も同じ共通言語を持つ受講者だけが学んでも、現場での実践につながらないことがあります。たとえば、受講者がスコープ管理やリスク管理の考え方を学んでも、上司やプロジェクトマネージャーがその考え方を理解していなければ、日常業務の中で活用する機会は限られてしまいます。そのため、管理職向けにも同じ概念を理解する機会を設けることが重要です。必ずしも受講者と同じ内容をすべて受ける必要はありません。管理職向けの短時間セッションや事前説明会を通じて、現場で使う言葉をそろえるだけでも効果があります。例えば、日常のレビューや進捗確認の場で、・「スコープは明確になっているか」・「リスクは可視化されているか」・「この報告から何を判断するのか」といった会話ができるようになると、トレーニングで学んだ内容が現場に定着しやすくなります。 ③ 定期的な振り返りの場を設ける人は学んだ内容を時間とともに忘れてしまいます。そのため、「1か月後」、「3か月後」、「半年後」といったタイミングで実践状況を確認し、振り返る機会を設けることが重要です。取り組みの成功事例や課題を共有することで、知識が経験となり、組織に定着していきます。 ◇私たちが目指すのは「受講前後で成長を実感できるトレーニング」先日、ある企業様向けにプロジェクト管理トレーニングを実施しました。このトレーニングでは、プロジェクト管理に必要な6つの要素について講義を行うだけでなく、実際の業務を題材としたワークショップも実施しました。ワークショップでは、実際の開発プロジェクトを想定して、スコープの整理やリスクの洗い出し等をグループで検討し、受講者同士で議論をする場を設けました。各自が自身のプロジェクトに置き換えて考えることで、一方的に知識を受け取るのではなく、「自分ならどう活用するか」を深く考えていただくことができました。受講者からは、・「スコープ管理をする中で、やることとやらないことを明確にする重要性を学べた」・「各種報告は義務ではなく、自身の判断精度を高めるためのものであることを理解できた」といった声をいただいています。私たちが大切にしているのは、講師から受講者への一方通行の座学ではありません。受講者の皆さまと一緒に考え、議論し、気づきを得ながら学ぶことです。そして、受講前と受講後で何が変わったのかを実感できるトレーニングを提供することです。 ◇トレーニングを「イベント」で終わらせないために教育の目的は、トレーニングを実施することではありません。現場の行動が変わり、プロジェクトの成果につながることです。もし、・「Automotive SPICE教育を実施しているが定着しない」・「プロジェクト管理スキルを向上させたい」・「トレーニング効果を現場改善につなげたい」・「開発組織の共通言語を作りたい」そんな場合は、まずはお気軽にご相談ください。私たちはトレーニング単体ではなく、現場への定着までを含めて一体で設計します。「またトレーニングが無駄になった」と感じる前に、教育を成果へ変える仕組みづくりを一緒に考えてみませんか。 ▼プライベートトレーニングラインナップはこちらから→https://www.bgarage.co.jp/service/training/ ▼ご相談・お問い合わせはこちらから→https://www.bgarage.co.jp/contact/ （長澤克仁）

コラム

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

５．車載以外のソフトウェア開発では、なぜDRBFMは使われないのか前編（こちらからご参照ください）では、日本の車載ソフトウェア開発の内部構造に焦点を当て、DRBFMがなぜ重く、そして終わらないプロセスとして運用されるようになったのかを見てきた。では、このような運用は、ソフトウェア開発全体に共通するものなのだろうか。結論から言えば、そうではない。車載以外のソフトウェア開発において、DRBFMはほとんど使われていない。これは欧米だけの話ではない。日本国内においても、Webサービス、業務システム、モバイルアプリケーション、さらには通信機器や一般的な組み込み分野において、DRBFMが品質保証の中心に据えられることは稀である。この事実は重要である。問題は、DRBFMが「普及していない」ことではない。むしろ、そもそも必要とされていないことにある。 車載以外のソフトウェア開発では、ハードウェアに起因する不確実性を、個々の変更レビューの場に持ち込まない。どこで何を扱うかという責任は分けられており、その前提の範囲で設計と検証が行われる。そのため、ある変更点からすべての影響を展開し続ける必要はない。議論は一定の範囲で止まり、それ以上は別の仕組みや責務に委ねられる。言い換えれば、一つの変更に対して、システム全体の成立まで人間が背負い続ける構造にはなっていないのである。 また、多くのソフトウェア開発では、変更は例外ではなく前提である。機能は継続的に追加・修正され、修正による影響は分割して扱われる。このような環境では、「変更のたびにすべての故障モードを列挙する」という方法論は成立しない。仮にそれを徹底すれば、開発そのものが止まってしまう。したがって、変更は小さく扱われ、その影響は段階的に確認される。一度の変更にすべてのリスクを集約するという発想そのものが選択されない。 もちろん、車載以外の分野でも品質を軽視しているわけではない。むしろ、DRBFMとは別の方法で品質を担保している。たとえば、アーキテクチャによって影響範囲を局所化し、自動テストによって継続的に影響を確認し、実装と検証を分離し、問題が起きた場合には迅速に検出・修正できる仕組みを整える。こうした、よりシステム化された方法が前提として存在している。ここには、ソフトウェア開発における重要な前提がある。それは、人間が事前にすべてを想定することはできないという前提である。したがって、「起こり得ることをすべて洗い出す」のではなく、「起きたときに制御できるようにしておく」という考え方が採用される。これは、DRBFM的な発想とは大きく異なる。 以上を踏まえると、車載以外のソフトウェア開発でDRBFMが使われない理由は明確である。 議論は一定の範囲で止まる 変更は分割されて扱われる 品質は個別の検討ではなく、仕組みで担保されるこのような前提が成立しているため、「変更点からすべての故障モードを洗い出す」というアプローチ自体が成立しにくいのである。つまり、DRBFMは単に「使われていない」のではない。そもそも必要になる文脈が存在しないのである。 ここで一つ、整理しておきたい。車載以外のソフトウェア開発が特別なのではない。むしろ、車載ソフトウェア開発の方が、異なる前提の上に成り立っているのである。本来どこかで止まるはずの議論が止まらず、分割されるはずの問題が一箇所に集まる。その結果として、すべての不安がDRBFMに集約されていく。言い換えれば、DRBFMが必要なのではなく、DRBFMで受け止めるしかない構造になっているということである。 ６．DRBFMは「工学の欠如」を埋めるための応急処置だった— なぜDRBFMは“原因”ではなく“結果”なのか第5章で見てきたように、車載以外のソフトウェア開発では、DRBFMという手法はほとんど使われていない。これは単なる手法の違いではなく、開発の前提そのものが異なることを示している。では逆に問うべきである。なぜ車載ソフトウェア開発では、DRBFMが必要とされ続けてきたのか。この問いを手法の優劣として扱ってしまうと、本質を見誤る。DRBFMは問題の原因ではない。それが必要となる構造の中で生まれた結果である。 要求の変更意図が失われるまず見なければならないのは、要求の扱いである。車載開発では、OEMから要求仕様書のアップデート版が頻繁に送付されることが多い。しかしその際、どこが変更されたのか、なぜ変更されたのか、その変更がどの範囲に影響するのか、といった情報が提供されないまま要求仕様書一式として送付されるケースが少なくない。本来であれば、要求の変更は、前バージョンとの差分を明示した「変更依頼文書」として提示されるべきである。その中には変更の目的、変更点、想定される影響範囲が明確に記述されている必要がある。しかし現実には、そのような情報が整備されないまま、更新版の要求のみが送付される。その結果、開発側では新旧要求を突き合わせ、差分を取り、どこが変わったのかを後から解釈する作業が発生する。しかしこの時点で、すでに重要な情報は失われている。それは変更の意図である。変更理由が分からなければ、その変更がどこまで影響するべきものなのか、どこからが想定外の振る舞いなのかを判断することが難しくなる。結果として、影響範囲は保守的に広く見積もられ、検討範囲は自然と拡張されていく。 設計として影響範囲を説明できない次に問題になるのが、設計側の責任である。本来、変更の影響範囲は設計によって限定されるべきである。つまり、その変更がどの機能に影響し、どのインターフェースを介して波及し、どの範囲で収まるのかを、設計として説明できる状態が求められる。そのためには、アーキテクチャ設計書や詳細設計書が整備されていることが不可欠である。これらの設計情報が存在してはじめて、影響範囲を論理的に説明することができる。しかし、それらが不十分な場合、影響範囲の判断は人の経験や勘に依存せざるを得ない。そうなると、「なぜそこまで影響しないと言えるのか」という根拠を明確に示すことができず、検討範囲を意図的に絞り込むことが難しくなる。ここで重要なのは、要求の意図が不明確なことと、設計で影響範囲を限定できないことは、別々の問題であるという点である。要求の意図が失われている状態は上流の問題である。一方で、それを前提に設計を成立させることはサプライヤー側の責任である。しかし現実には、この二つが重なってしまう。変更の意図が分からないため影響範囲を広く見積もり、さらに設計としてその範囲を限定・説明できないため、検討はますます広がっていく。こうして、「どこまで確認すれば十分か」を論理的に示せない状態が生まれる。その結果、念のため確認する、一応すべて見る、全体で問題がないことを保証する、という判断が積み重なり、検討は際限なく拡張されていく。これは前編で見た「無限深掘り」の構造そのものである。 DRBFMは設計で閉じられなかった問題を受け止めているこの状況において、DRBFMは何をしているのだろうか。それは、単なる品質手法というよりも、設計で限定・整理できなかった問題を受け止める場として機能している。変更点を列挙し、起こり得る影響を広く洗い出し、関係者同士で確認する。こうした活動は、本来であれば、要求で整理されるべき情報、設計で限定されるべき範囲、構造で制御されるべき影響を、会議によって補完している状態に近い。設計として説明できない。影響範囲を限定できない。要求の意図も不明確である。このとき最後に残る根拠は、「全員で確認した」という事実である。その意味で、DRBFMは設計の代替であり、トレーサビリティの代替であり、境界定義の代替として機能している。だからこそ、負荷がどれほど大きくても簡単にやめることができない。DRBFMは、品質を支える最後の防衛ラインになってしまっているのである。 DRBFMは合理的な帰結であるここで見方を変える必要がある。DRBFMは非効率であり、現場を疲弊させる。これは事実である。しかし、それだけではなぜDRBFMが使われ続けているのかを説明できない。変更の意図が分からない。影響範囲を限定できない。根拠を説明できない。この状態で品質を確保しようとすれば、人間が可能な限りリスクを洗い出す以外の方法が残されていない。その意味で、現在の前提のもとでは、DRBFMは合理的ですらある。問題はDRBFMそのものではない。DRBFMでしか品質を支えられない状態にあることが本質である。手法を変えるだけでは、この構造は変わらない。むしろ、DRBFMを単純に削減すれば、品質を支える手段そのものを失うことになりかねない。本当に問うべきなのは、なぜ変更の意図が共有されないのか、なぜ設計で影響範囲を限定できないのか、なぜその範囲を説明できないのか、という開発の前提そのものである。では、これらの前提をどのように変えていくのか。車載以外のソフトウェア開発では、なぜこの問題を構造として解決できているのか。次章では視点をさらに外に移し、DRBFMに依存しない開発がどのように成立しているのかを見ていく。 ７．欧米の車載ソフトウェア開発はどうなっているのか－工学として扱うことで成立している世界第5章では、車載以外のソフトウェア開発ではDRBFMがほとんど使われていないことを見てきた。そして第6章では、その理由が手法の違いではなく、ソフトウェアを工学として扱えているかどうかにあることを整理した。それでは、欧米の車載ソフトウェア開発はどのような状態にあるのだろうか。結論はシンプルである。ソフトウェアを工学として扱う前提が成立しているため、DRBFMに依存する必要がないのである。 設計が影響範囲を説明できる欧米の車載ソフトウェア開発では、設計が単なる構成図ではなく、システムの振る舞いと影響の範囲を説明するための基盤として機能している。要求と設計の関係が整理され、機能ごとの責務と境界が明確に定義されているため、変更や検討が生じた場合でも、その影響がどこまで及ぶのかを設計として説明することができる。ここで重要なのは、経験や感覚に依存するのではなく、構造として根拠を示せることである。どこまで評価すべきか、なぜその範囲で十分なのかを、設計として説明できる。だからこそ、すべてを見直すという状況が発生しにくい。これは、日本の現場でしばしば見られる「どこまで見れば十分か分からない」という状態との大きな違いである。 分析は設計と論証の中で機能する欧米の車載ソフトウェア開発では、品質や安全性は個別の検討の積み重ねだけで担保されるのではなく、設計結果を論証する枠組みの中で扱われる。ISO 26262に代表されるように、安全要求を定義し、それを設計として実装し、その成立を論証するという体系が前提となっている。この中で、FMEAやFTAといった分析は当然実施される。しかし、それらは単独の活動として完結するものではなく、設計と論証を成立させるための材料として位置付けられる。重要なのは、分析そのものではなく、分析結果が設計と論証の構造の中でどのように機能しているかである。この前提のもとでは、分析はその場限りの検討として消費されることはない。設計の中に取り込まれ、境界や振る舞いとして固定され、その後の判断の前提として機能し続ける。ここで見落としてはならないのは、設計に対する考え方そのものの違いである。欧米のソフトウェア開発では、問題が発生したときに「なぜそれが起きるのか」を無限に掘り下げ続けることよりも、どう振る舞うべきか、どう実現するかに焦点が置かれる。もちろん原因分析は行われる。しかし、それは掘り続ける対象ではなく、設計を成立させるための入力として扱われる。その結果、議論は原因を網羅的に洗い出す方向ではなく、設計によって影響を制御する方向に収束する。不具合の可能性を会議で洗い出し続けるのではなく、設計として安全に制御できる状態を作る。この考え方が自然に成立しているのである。 設計が成立している世界では何が違うのか設計がこのように機能している場合、不安やリスクが発生しても、それが無制限に広がることはない。影響が及ぶ範囲と収まる範囲があらかじめ定義されているため、検討は自然とその中で完結する。つまり、影響範囲が設計として限定され、その根拠を説明でき、検討すべき範囲があらかじめ定義されている。この前提が成立している限り、不安を網羅的に洗い出す場そのものが必要になりにくい。したがって、DRBFMは排除されたわけではない。単に、主役として必要になる場面が存在しないのである。設計として影響範囲を限定できず、その根拠も説明できない場合、検討は人間の確認へと引き戻され、その受け皿としてDRBFMが必要になる。一方で、設計としてそれが成立している場合、検討は構造の中で完結する。欧米では特別なことをしているのではない。ソフトウェアを工学として扱っているだけである。そして、その前提が成立しているとき、DRBFMに依存しない開発が自然に成立する。次章では、この前提を踏まえ、DRBFMをどのように使い分けるべきかという現実的な問いに踏み込んでいく。 8. それでもDRBFMを全否定しない理由（使いどころを再定義するか）ここまで述べてきた通り、DRBFMの問題を解くために最初に取り組むべきことは、DRBFMそのものの改善ではない。まず必要なのは、影響範囲を説明できるアーキテクチャを作り、ソフトウェアを工学として扱える状態に近づけることである。しかし、それはDRBFMを完全に不要にするという意味ではない。むしろ重要なのは、DRBFMを「常に実施する品質保証プロセス」から、必要な場面で使う補助的なリスク検討手段へと位置付け直すことである。 まずソフトウェア開発の方法論を取り入れる日本の車載ソフトウェア開発でまず進めるべきなのは、ソフトウェア開発の方法論を本格的に取り入れることである。要求の変更を正しく扱い、変更の影響範囲を設計として説明し、差分を局所的に管理する。こうした考え方なしに、DRBFMだけを軽くしようとしても、根本的な解決にはならない。この点で、XDDPのようなソフトウェア向けの派生開発プロセスは参考になる。XDDPは、変更要求、変更設計、影響範囲を整理し、派生開発における混乱を抑えるための考え方である。DRBFMのように心配事を広げていくのではなく、変更を構造的に扱い、影響を限定していく方向を持っている。もちろん、XDDPを導入すればすべてが解決するわけではない。重要なのは、特定の手法名ではなく、変更をソフトウェア工学の枠組みで扱うことである。DRBFMの前に、まず設計と変更管理を成立させる。この順序を間違えてはならない。 それでもDRBFMが価値を持つ場面その上でなお、DRBFMが価値を持つ場面は残る。たとえば、プラットフォーム変更のように設計の前提そのものが変わる場合である。既存のアーキテクチャや過去の実績が、そのまま使えるとは限らない。このような場面では、関係者の知見を集め、想定外の影響を広く検討することに意味がある。また、これまでにない新規機能を導入する場合も同様である。既存の設計に収まらない新しい振る舞いが入る場合、影響範囲を設計だけで完全に説明しきれないことがある。さらに、安全クリティカルな領域では、設計として説明できていても、追加的なリスク検討が求められる場合がある。こうした場面では、DRBFMのような多面的な議論が有効に働く余地はある。つまり、DRBFMが価値を持つのは、設計や通常の変更管理だけでは扱いきれない不確実性が残る場面である。 「全部やる」から「必要なところだけやる」へ問題は、DRBFMが存在することではない。問題は、それが本来の使いどころを超えて、あらゆる変更に適用されていることである。設計で説明できることまでDRBFMに流れ込めば、議論は重くなる。検討範囲の境界が曖昧になり、完了条件も見えにくくなる。その結果として、現場は「念のため」の検討に追われる。これから必要なのは、DRBFMをやめることではない。DRBFMを必要なところだけに戻すことである。通常の派生開発や局所的な変更は、アーキテクチャ設計、変更管理、テスト、トレーサビリティで扱うべきである。一方で、設計前提そのものが変わる変更や、安全上の不確実性が大きい変更については、DRBFMで補完する価値がある。このように位置付け直せば、DRBFMは開発全体を覆う重い儀式ではなくなる。設計の代替ではなく、設計で扱いきれない領域を補う手段として機能するようになる。 DRBFMを本来の役割に戻すDRBFMは不要なものではない。しかし、ソフトウェア開発全体を支配する手法でもない。まずはアーキテクチャを成立させる。次に、XDDPを含むソフトウェア開発の考え方を取り入れ、変更を構造的に扱えるようにする。その上でなお残る不確実性に対して、DRBFMを使う。この順序が重要である。DRBFMを先に考えるのではない。ソフトウェア開発を工学として成立させることが先である。その状態に近づくほど、DRBFMの適用範囲は自然に小さくなる。そしてそのとき初めて、DRBFMは本来の価値を取り戻す。すべてを確認するための儀式としてではなく、設計だけでは扱いきれないリスクに向き合うための補助的な手段として。DRBFMを完全に捨てる必要はない。しかし、DRBFMに依存し続ける開発からは脱却しなければならない。DRBFMがなくても成立する設計を目指し、その上で、本当に必要な場面にだけDRBFMを使う。その方向へ進むことが重要である。ただし、このような使い分けを実現するためには、単にDRBFMの運用ルールを変えるだけでは不十分である。必要なのは、ソフトウェアを工学として扱い、設計で説明できる領域を広げていく開発文化そのものへの転換である。では、日本の車載ソフトウェア開発は、何を残し、何を捨て、どの方向へ変わるべきなのか。最終章では、この問題を単なるDRBFMの是非ではなく、日本の車載ソフトウェア開発が世界で戦い続けるための課題として整理したい。 9. 変えなければ、世界では勝てないここまで見てきた通り、DRBFMの問題は、単なる手法の話ではない。DRBFMそのものが悪いのではなく、日本の車載ソフトウェア開発が、長い間ソフトウェアを「工学として設計する対象」として十分に扱い切れてこなかったことが、本質的な問題である。設計で説明すべきことがDRBFMに流れ込む。アーキテクチャで限定すべき影響範囲を、会議の中で洗い出そうとする。要求管理やトレーサビリティで扱うべきことまで、人間のレビューで補おうとする。そこに、日本の車載ソフトウェア開発が抱えてきた構造的な弱さが表れている。つまりDRBFMは、問題の原因というよりも、そうした開発文化を映し出す一つの象徴なのである。 この問題は、DRBFMだけに閉じた話ではない。筆者が以前から問題視してきた「制御仕様書」も、同じ根を持っている。詳しくは、こちらのコラム「制御仕様書という怪物」を参照してほしい。本来であれば、要求、アーキテクチャ、詳細設計、テスト、安全論証は、それぞれ異なる役割を持つべきである。要求は何を実現すべきかを示し、アーキテクチャは責務と境界を定義し、詳細設計は実現方法を具体化する。テストはそれらが成立していることを確認し、安全論証はその根拠を示す。ところが現実には、それらの境界が曖昧になり、一つの巨大な仕様書や、一つのレビュー会議に多くの責任が押し込まれてしまう。制御仕様書には、要求も設計も実装都合も検証観点も混在する。DRBFMには、変更点の確認も、影響範囲の推測も、安全上の不安も、責任分散のための確認も入り込む。どちらも、本来は分けて扱うべきものを分けられなかった結果として生まれた、巨大な受け皿である。問題の本質は、帳票でも会議体でもない。ソフトウェアを分解し、構造化し、説明可能にする設計文化が十分に根付いてこなかったことにある。 だからといって、日本の品質文化をすべて否定する必要はない。変化点に敏感であること、安全に対して妥協しないこと、関係者の知見を持ち寄り、リスクを見逃さないようにすること。これらは、日本のものづくりが持ってきた強みであり、ソフトウェア開発においても失ってよいものではない。しかし、捨てるべきものも明確である。手続きの量が品質を保証するという考え方、帳票を厚くすれば安心できるという発想、人間が集まって議論すれば設計の弱さを補えるという期待。これらは、ソフトウェアが大規模化し、複雑化した現在では、もはや通用しない。人間の知見は重要である。しかし、それは設計を補うために使われるべきものであり、設計そのものの代替にしてはならない。すり合わせを捨てる必要はない。だが、すり合わせを主役にしてはならない。主役は、アーキテクチャであり、要求管理であり、トレーサビリティであり、テストであり、安全論証である。その上で、人間のレビューやDRBFMが補助的に機能する。この順序を取り戻すことが重要である。 自動車は、もはやメカ中心の製品ではない。車の価値は、確実にソフトウェアによって決まりつつある。この時代に、ソフトウェアをハードウェア開発の流儀で扱い続ければ、競争力は確実に低下する。開発速度は上がらない。変更に弱い。現場は疲弊する。優秀なソフトウェアエンジニアにとって魅力のある開発環境にもなりにくい。品質を守ろうとしてプロセスを重くした結果、変化に対応できなくなるのであれば、それは本末転倒である。これから必要なのは、品質を軽視することではない。むしろ逆である。品質を守るためにこそ、開発を工学化しなければならない。アーキテクチャによって影響範囲を説明し、要求と設計をつなぎ、テストで検証し、安全性を論証する。その上で、なお残る不確実性に対して、人間の知見を活かす。DRBFMも、その文脈の中で使われるべきである。DRBFMを完全に捨てる必要はない。しかし、DRBFMに依存し続ける開発からは脱却しなければならない。DRBFMがなくても成立する設計を目指し、その上で、本当に必要な場面にだけDRBFMを使う。その方向へ進まなければ、日本の車載ソフトウェア開発は、グローバルな競争の中で次第に厳しい立場に置かれていくだろう。変えるべきなのは、品質へのこだわりではない。品質を支える方法である。 DRBFMを続けるか、やめるか。本質的な問いは、そこではない。問うべきなのは、自分たちの開発が工学に向かっているのか、それとも儀式に向かっているのかである。設計で説明できない不安を、これからも会議で埋め続けるのか。それとも、設計で説明できる領域を増やし、DRBFMを本来の使いどころに戻していくのか。これは、単なる開発プロセスの話ではない。日本の車載ソフトウェア開発が、これからも世界で戦っていけるかどうかの話である。DRBFMは、日本独特の開発文化が生み出した産物である。そしてその存在は、私たちがまだソフトウェアを十分に工学として扱い切れていないことを映し出している。 だからこそ、変えなければならない。あなたの現場は、工学に向かっているだろうか。それとも、儀式を続けているだろうか。（日吉昭彦）

コラム

役割名ではなく行動を定義する ― 責任割当てを機能させる方法

はじめにAutomotive SPICEのアセスメントを行っていると、GP2.1.4（Assign Responsibility）は比較的達成しやすいプラクティスに見えます。組織図があり、役割一覧があり、RACI表も整備されている。Project Manager、Quality Assurance Manager、Configuration Managerといった役割も定義されている。そのため、多くの組織は「責任の割当てはできている」と考えます。しかし、インタビューを進めると次のような声を耳にすることがあります。「Project Managerを任されていますが、実際には何をすればよいのでしょうか。」「Configuration Managerになったのですが、どこまでやれば責任を果たしたことになるのでしょうか。」役割は存在しているのに、その役割を担う本人が何を行うべきか分からないのです。これは決して珍しい話ではありません。むしろ多くの組織が直面する共通の課題ではないでしょうか。責任割当ての落とし穴責任割当てに関する要求の目的は、プロセスを確実に実施するための体制を構築することです。ところが実際には、 役割名だけ定義して満足してしまう RACI表を作って終わってしまう 責任者を任命すればプロセスが回ると思ってしまうという状態に陥ることがあります。確かに役割定義書やRACI表は有効な手段です。しかし、それらはあくまで責任を可視化するための仕組みに過ぎません。本当に重要なのは、割り当てられた責任が実際の行動として機能していることです。役割名が存在することと、その役割が期待どおりの活動を実施できることは同じではありません。「誰が責任者か」より「何を行うか」Automotive SPICEでは、多くのプロセスで役割が定義されています。しかし、 毎週何を確認するのか どの指標を見るのか どのタイミングで介入するのか 何を判断するのか 問題が発生した場合に何を行うのかまでは明確に規定されていません。そのため、役割名と責任範囲だけを定義すると、担当者それぞれの経験や力量に依存した運用になりがちです。結果として、同じProject Managerでも人によって活動内容が大きく異なり、プロセスの再現性が失われます。責任者を置くことが目的ではありません。プロセスが継続的かつ安定的に運用されることが目的なのです。Managerだけの話ではないこの課題はManager役割だけに当てはまるものではありません。例えば、 Reviewer Author Verifier System Architect Change Control Board Configuration Librarianといった役割についても同じです。レビュー担当者であれば何を確認するのか。Verifierであればどの証拠を確認し、どの基準で合否を判断するのか。役割名だけでは十分ではなく、期待される行動を明確にすることが重要です。今回は分かりやすい例としてManager役割を取り上げますが、本質的な考え方はすべての役割に共通しています。同じ役割でもプロセスによって期待行動は変わるさらに見落とされやすいのが、同じ役割であっても担当するプロセスによって期待される活動が異なることです。例えばProject Managerの場合、MAN.3では、 計画策定 進捗監視 リスク管理 是正処置が中心となります。一方でSUP.9では、 問題解決状況の監視 問題分析結果のレビュー エスカレーション判断などが主な活動になります。つまり、「Project Manager」という役割だけでは必要な行動を定義できません。どのプロセスにおいて、どの責任を担うのかを明確にしなければ、期待されるマネジメント行動は見えてこないのです。TSPに学ぶ役割の考え方こうした状況を考える際に参考になるのがTSP（Team Software Process）です。TSPではPlanning Manager、Quality Manager、Process Manager、Support Managerなどの役割が定義されており、それぞれに具体的な責務や確認事項が設定されています。つまりTSPは肩書を与えるだけではなく、「何を行うべきか」まで明確にしているのです。この考え方で見ると、Manager役割とは成果物を作る人ではありません。成果物が作られる仕組みを維持し、監視し、改善する人です。そのためManager役割の本質は、 実施状況を監視する 状況を評価する 問題を判断する 是正を促すことにあります。行動を具体化する例えばProject Managerであれば、 計画と実績の差異確認 スケジュール遅延の兆候把握 リスクレビュー 未解決課題の監視 是正処置の指示といった活動が考えられます。Configuration Managerであれば、 構成品目登録状況の確認 ベースライン設定状況の確認 変更要求処理状況の監視 構成監査結果の確認などが該当します。重要なのは、「構成管理に責任を持つ」と書くことではありません。何を確認し、何を判断し、どのような条件で行動するのかまで明確にすることです。行動を明確化する仕組みを作るこうした具体化を実現する方法として、役割説明書は非常に有効です。例えば、 役割の目的 確認する内容 使用する指標 参加する会議 レビュー対象 判断事項 実施頻度 エスカレーション条件などを整理します。ただし、必ずしも役割説明書という成果物である必要はありません。組織によっては、Role Description、RACI、Procedure、Work Instruction、チェックリストなどに分散して定義してもよいでしょう。重要なのは文書の名前ではなく、期待される行動が誰にでも分かることです。役割間連携も重要実際のプロセスは、個々の役割だけで成立するものではありません。Project Manager、Quality Assurance Manager、Configuration Manager、System Architect、開発担当者など、多くの役割が連携しながら運営されています。そのため、 誰が入力するのか 誰がレビューするのか 誰が承認するのか 誰が監視するのかを明確にすることも重要です。RACI表やスイムレーン図は、その関係を可視化する有効な方法です。責任割当てを機能させるために責任を割り当てることは重要です。しかし、それだけではプロセスは機能しません。本当に必要なのは、割り当てられた役割が何を行うのかを具体化することです。そして、その内容が引継ぎ可能なレベルまで整理されていることです。役割名を定義するだけではプロセスは改善しません。「誰が責任者か」だけでなく、「その役割は何を確認し、何を判断し、誰と連携し、どのように改善を促すのか」まで明確にする。それこそが責任割当てを形骸化させず、ASPICEのプロセスを実際に機能する運営モデルへ発展させる第一歩ではないでしょうか。 （佐野忠）

コラム

技術が伝わらないのはなぜか 　── 技術継承（前編）：なぜ技術が現場に残らないのか ──

ソフトウェア開発の現場で、近年よく聞かれるようになった言葉があります。「若手が育たない」「技術継承が進まない」「同じ問題が、何度も繰り返される」これは単なる人材や教育の問題ではありません。本質は、開発の進め方そのものにあります。技術継承が進まない理由としては、人材不足、教育不足、外注依存、技術の高度化など、様々な要因が指摘されています。しかし、それだけではこの問題の本質を説明することはできません。その背景として、現場によっては、要求仕様書や設計書といったドキュメントが十分に整備・活用されていないケースが少なくありません。形式上は存在していても、実際の開発では参照されず、「あるだけのドキュメント」になっている場合も見られます。このような状況では、技術が継承されないのは当然とも言えます。一方で、開発環境や開発プロセスが整備され、ドキュメントも一定程度整っているように見えても、それが必ずしも「技術の理解」や「継承」につながっているとは限らないケースもあります。では、なぜこのような状況が生まれているのでしょうか。 本コラムは前後編で構成しています。前編では、技術継承が進まない要因を整理し、後編では、AI時代も見据えた上で、どのようにこの課題に向き合うべきかを考えます。本編ではまず、この問題を人材や教育の観点ではなく、開発の進め方やプロセスの運用という観点から整理します。 かつて、技術は「自然に」継承されていた筆者がソフトウェア開発に携わり始めたのは、今から40年ほど前になります。当時のソフトウェア開発現場では、一人の開発者がシステム全体に関わることは珍しくありませんでした。要求分析から設計、実装、テストまでを一貫して担当することも多く、自分が設計した内容がどのように振る舞い、どのような問題につながるのかを、実感として理解することができました。ここで重要なのは、当時の開発者が特別に優れていたということではありません。システム全体の構造と因果関係が、個人の認知の中で把握できる範囲に収まっていた、という点です。設計の意図や判断は、日常的な会話やレビューの中で説明され、暗黙のうちに共有されていきました。結果として、技術は「教えるもの」であると同時に、「関わることで自然に身につくもの」として継承されていたと考えられます。 なぜ今は同じことができないのか現在の開発現場では、この前提が大きく変わっています。システムの大規模化・複雑化、機能単位への細分化、分業化の進展、派生開発の常態化――こうした変化により、個々の開発者が関わる範囲は限定され、システム全体を見渡す機会は大幅に減少しました。さらに近年では、実装の多くをサプライヤに委託し、自社は管理や調整を中心とするケースも増えています。このような開発体制では、プロジェクトに関わっていても、技術的な判断そのものに直接関与する機会が限られます。その結果、自分の作業が全体のどこに位置付くのか分からない、前提条件が共有されないまま作業が進む、なぜその設計になっているのか説明できない、といった状況が生まれています。これは個人の能力に帰属させるべき問題ではなく、技術的な判断に関与しづらい開発の進め方やプロセスの運用のあり方によるものです。 文書はあるのに、技術継承が進まない理由ドキュメントが十分に整備されていないこと自体が課題となるケースもありますが、それだけではこの問題は説明しきれません。「昔と違って、今はドキュメントがあるはずだ」という指摘もあります。確かに、要求仕様書や設計書、テスト仕様書といったドキュメントが整備され、形式上は揃っている現場もあります。しかし、実際には十分に活用されていなかったり、派生開発の積み重ねによって、全体像が見えにくくなっているケースも少なくありません。ただし、こうした問題だけで、技術が継承されない理由をすべて説明できるとは言えません。では、技術が継承されない本質的な理由はどこにあるのでしょうか。その理由は次の点にあります。文書には「何を作るか」は書かれている一方で、「なぜそうしたか」が十分に残されていないためです。例えば、同じ性能問題に対して、・キャッシュを入れる・非同期処理にするといった複数の解決策が考えられる場面で、ここではキャッシュを採用したとします。しかし、・なぜそれを選んだのか・なぜ他の選択肢は採用しなかったのかといった前提が残っていなければ、後続の開発者はその判断を再度検討することになります。その結果、同じ検討が繰り返され、知見は蓄積されません。例えば設計書には、処理の流れやインタフェース仕様、状態遷移といった内容は記載されています。しかし、・なぜこの構成を選んだのか・他の選択肢はなぜ採用されなかったのか・どのような前提条件で判断したのかといった設計判断の背景は、記録されないままになりがちです。技術は成果物だけでは継承されません。継承されるのは、設計判断の理由や前提が残っていてこそです。どれだけ文書が整っていても、判断の理由や前提が残っていなければ、それは再利用も学習も難しくなります。 プロセスの中で、判断が十分に活かされていないもう一つの問題は、設計や仕様に関する判断が、開発プロセスの中で十分に活用されていない点です。多くの開発プロセスでは、要求定義や設計といった各工程ごとにレビューが定義されており、どの工程でどのような確認や判断を行うかについては整理されています。しかし実際の運用では、レビュー自体が形式的に行われていたり、レビュー対象が多く、限られた時間の中で、十分に議論できないまま進むこともあります。また、レビュー記録も決定事項のみが残され、その判断に至った背景や議論の過程までが記録されていないケースも多く見られます。このような状況では、レビューの場で判断は行われているものの、その内容が技術として蓄積される形にはなっていません。その結果、「誰が」「どこで」判断したのかは分かっても、「なぜその判断になったのか」が分からない状態になります。結果として、判断が個人の経験に依存し、同じ検討が何度も繰り返されるといった非効率が発生します。これは、判断を深く扱い、結果だけでなくその背景までを残す運用になっていないことによるものです。 レビューはなぜ機能しなくなったのか本来、レビューは技術継承において重要な役割を持っていました。過去のレビューでは、なぜこの設計にしたのか、前提条件は妥当か、他に選択肢はなかったのか、といった判断そのものを問い直すことが重視されていました。しかし現在では、記述の抜けや規約への適合、形式の確認といった観点に重きが置かれることが多く、レビューは「品質確認の場」としては機能していても、判断を共有・継承する場としては十分に機能していないケースが増えています。つまり、決定結果は確認されていても、「なぜその判断に至ったのか」が共有されないまま進んでいると言えます。その結果、判断は行われていても、それが技術として蓄積されにくくなっています。 まとめ技術が継承されなくなった原因は、個々の努力や教育だけで解決できる問題ではありません。現場によっては、そもそもドキュメントが十分に整備・活用されていないという課題を抱えているケースもあります。そのような状況では、技術が継承されないのも当然です。しかし、本質的な問題はそれだけではありません。設計判断が十分に言語化・共有されず、それを残すことを前提として開発プロセスの中で扱われていないことにあります。技術継承とは、単に知識を伝えることではなく、設計判断を「どう残し、再利用できる形にするか」という問題です。現在の開発は、「技術を蓄積する構造」というよりも、「判断が残らないまま進む構造」になっている点に課題があります。もし、同じ議論が何度も繰り返される、設計の意図が分からない、全体像を掴みにくい、といった状況がある場合、それは、開発の進め方やプロセスの運用に起因している可能性があります。この問題は、個々の工夫だけでは解決しにくく、開発の進め方そのものを見直す必要があります。次回は、これからの開発において技術継承をどのように実現していくのか、AIの活用も含めて、「判断をどのように扱い、残していくか」という観点から整理します。（安部宏典）

コラム

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

はじめに車載ソフトウェア開発に関して、ソフトウェアアーキテクチャ設計の重要性と難しさについて、日頃から感じていることについて記述します。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. おわりに：成長を「個人任せ」にしないためにスキル開発は個人の主体的な取り組みによって成り立つ側面を持ちながらも、それだけに委ねてしまうと、組織としての成長には限界が生じます。個人の努力と、チームや組織による支援、この両方がかみ合ったとき、はじめて持続的な成長が可能になると考えます。成長は「個人で頑張るもの」でも、「組織から与えられるもの」でもなく、両者の相互作用によって実現されるものであり、その視点を持つことが、これからのエンジニアリング組織において、より一層重要になっていくのではないでしょうか。 （佐藤崇）

トップ新着情報コラム

Contact Us

お問い合わせ

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

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