Updates

新着情報

コラム

Automotive SPICE 能力レベル3とは何か? ー それは「プロセスの話」だけではない (前編)

1.はじめにAutomotive SPICE(以下、A‑SPICE)の能力レベル3という言葉から、多くの組織が思い浮かべるのは「組織標準プロセスの整備」や「標準化されたやり方が定義されている状態」ではないだろうか。実際、能力レベル3はそのような文脈で語られることが多い。しかし、それは能力レベル3がもたらすの“結果の1つ”であって、“本質”ではない。能力レベル3が本来問いかけているのは、プロジェクト依存のやり方から脱却し、組織として仕事の仕方を意図的に設計し、再利用可能な形で運用できているか、という一点に尽きる。そしてこれは、決して個々のプロジェクトの努力だけで到達できるレベルの話ではない。 本来、能力レベル3はプロセス改善モデルの中で、組織としての力を高めていくために、改善を継続的に推進できる状態を指している。プロセス定義は、そのために不可欠な手段の一つではあるが、目的そのものではない。改善を通じて組織力を引き上げるという狙いがあってこそ、プロセスは意味を持つ。にもかかわらず、A‑SPICEの文脈では、能力レベル3が「プロセスを整備したかどうか」という見えやすい側面で捉えられがちであった。その背景には、A‑SPICEがサプライヤー評価モデルとして使われてきた歴史や、プロジェクト中心で読まれやすい構造がある。 本稿では、まず能力レベル3の考え方を起点として、レベル2との決定的な違いを整理し、PPTトライアングル(People・Process・Technology)が示すレベル3の本質を確認する。その上で、なぜA‑SPICEの文脈では、この本質が見えにくくなってきたのかを整理する。なお、本稿は前編として位置づけ、能力レベル3の理解と、その誤解が生まれた背景までを扱う。  2.能力レベル2との決定的な違いー 「守る」から「設計する」能力レベル2と能力レベル3の違いは、しばしば「標準プロセスがあるかどうか」や「組織で統一されているかどうか」といった表層的な比較で語られる。しかし、それでは能力レベル3の本質を捉えたことにはならない。 能力レベル2までの世界では、プロセスの主語はあくまでプロジェクトである。計画を立て、進捗を管理し、レビューを行い、成果物を管理する。つまり、「決められたことを守れているか」「管理が回っているか」というプロセスの状態が焦点となる。言い換えれば、決められたことを守れているか、が問われる世界である。この段階では、プロジェクトマネージャの力量や、プロジェクト固有の流儀が大きな影響を持つ。うまく回っているプロジェクトは確かに存在し、成果も出る。しかし、それは「そのプロジェクトがうまくいった」という事実に留まり、なぜうまくいったのかが組織として説明できるとは限らない。 能力レベル3で起きるのは、この問いの変化である。 そのプロセスは、誰が何を意図して設計したのか なぜそのプロセスが選ばれているのか プロジェクトごとの違いを踏まえ、どのようにテーラリングするのか 組織として、プロセスをどのように進化させていくのかここで初めて、プロセスは「守るべきルール」ではなく、「意図を持って設計され、使いこなされ、変えていく対象」として扱われるようになる。 レベル3とは、プロセスを単なるルールやチェック対象として扱う段階から、組織の知的資産として扱う段階への転換である。プロセスを通じて、組織としてどのような仕事の仕方を選び、どのように改善していくのかを考え、実行できる状態に移行することを意味している。能力レベル2が「プロジェクト運営を安定させる状態」だとすれば、能力レベル3は「組織としての仕事の仕方そのものを設計する状態」であり、質的に異なる段階なのである。この違いを理解せずに能力レベル3を目指すと、「決め事を増やす」「文書をそろえる」といった活動に陥りやすい。しかしそれは、レベル2の延長線上でできることに過ぎず、レベル3が本来求めている転換点を越えたことにはならない。  3.プロセスだけでは組織は変わらないーPPTトライアングルが示すレベル3の本質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におけるプロセスモデリングは、成熟の証明ではなく、改善が組織の中で本当に機能し始めた結果だと言える。  4.なぜ、この誤解は生まれたのかーAutomotive SPICEという枠組みが生んだ構造的なズレ前章までで見てきたように、能力レベル3は本来、People・Process・Technology を通じて組織としての力を高めていくための入口であり、単なるプロセス定義の段階ではない。しかしA‑SPICEの文脈では、能力レベル3が「組織標準プロセスを整備する段階」として理解されるケースが少なくなかった。この誤解は、特定の組織や個人の理解不足によって偶然生じたものではない。A‑SPICEというモデルがどのような目的で設計され、どのような文脈で使われてきたかを振り返ることで、その背景は構造的に説明できる。サプライヤー評価モデルとして使われてきたA‑SPICEA‑SPICEは、欧州OEMがサプライヤーを評価するための枠組みとして発展してきた。その主眼は一貫して、OEMに影響を与える開発リスクの可視化と低減にある。評価の対象となるのは、あくまで進行中、あるいは予定されているプロジェクトであり、プロジェクトが安定して遂行されるかどうかが最重要関心事であった。この文脈において、能力レベルは「将来に向けた組織変革の成熟度」を測る尺度というよりも、プロジェクトをどの程度安心して任せられるかを判断するための指標として受け止められてきた側面がある。 プロジェクト視点で読み取られた能力レベル3こうした文脈の中では、能力レベル3は自然と、 プロジェクト間で共通に使えるものがあるか 標準化されたプロセスが存在するかといった観点で理解されるようになる。これは、プロジェクトの安定化という目的に照らせば合理的な読み方であり、誤りと断じることはできない。ただし、この理解はプロジェクトを中心に据えた解釈であり、第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年後を語る企業と、目の前を語る企業 プロジェクトフォーカスから、いつ抜け出すのか このままで、本当にいいのか (日吉昭彦)

コラム

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

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

コラム

問題解決管理プロセスと変更依頼管理プロセスを両立させるために

はじめにシステム開発/ソフトウェア開発は、一度作って終わりであることはまずありません。日々発生する不具合やトラブルへの対応と、顧客からの変更要求の対応や将来を見据えた改修の積み重ねによって支えられています。その中核を担うのが「問題解決管理プロセス」と「変更依頼管理プロセス」です。Automotive SPICEでは、支援プロセス「SUP.9」と「SUP.10」として定義されています。似ているようで役割の異なるこの2つを正しく理解し、連携させることが、システム開発/ソフトウェア開発プロジェクトの混乱と疲弊を避ける鍵となります。今回は「SUP.9」と「SUP.10」を両立させるヒントをお伝えします。 問題解決管理プロセスと変更依頼管理プロセスのおさらい問題解決管理プロセス:再発を防ぐための“根本治療”問題解決管理プロセスの目的は、単なる不具合対処や障害復旧ではありません。表面化した不具合や障害の背後にある真の原因(根本原因)を特定し、再発を防止することにあります。場当たり的な対応を繰り返していると、「同じ不具合が何度も起きる」「現場が疲弊する」といった悪循環に陥りがちです。問題解決管理は、なぜ起きたのかを構造的に分析し、恒久対策を設計するためのプロセスと言えるでしょう。それゆえ、SUP.9:問題解決管理プロセスでは、「問題が他のシステムや関係者に影響がある場合に通知」して、類似問題の発生を抑制したり、「データを収集&分析し、傾向」を把握することで再発防止策を講じることが期待されています。変更依頼管理プロセス:リスクを制御しながら前に進む一方、変更依頼管理プロセスは、システムやソフトウェアの変更を秩序立てて、安全に、確実に実施するための仕組みです。変更は、改修や価値創出に不可欠ですが、同時に新たなリスクも伴います。影響範囲の評価、承認フロー、実施計画、リリース後の確認といったステップを踏むことで、「適切に変更を実装する」と同時に「良かれと思った変更が別の問題を生む」事態を防ぎます。それゆえ、SUP.10:変更依頼管理プロセスでは、「変更する作業成果物や他の変更依頼との関連を含めて分析」し、「実装前に、分析結果とリソースの利用可能性に基づいて優先順位を付け、承認」することが期待されています。 混同されがちな2つのプロセス開発現場では、「問題が起きたから変更する」「変更したら問題が起きた」という事象が発生すること、また、「どうせ変更するなら手続きは共通化したい」という理由から、両者が混同されることがあります。しかし本来は役割が異なります。 問題解決管理:なぜ問題が起きたのかを突き止める 変更依頼管理:対策や改善を、リスク管理しながら実装するつまり、問題解決管理の“アウトプット”として検討された対策が、変更依頼管理プロセスに引き渡される、という関係が理想です。仮に、両プロセスを共通の手続きに押し込んでしまった場合、原因分析や再発防止策の検討が、変更内容の検討と混同され、本来、問題解決管理でやるべき目的が希薄になる可能性が高まります。その結果、「問題」が「単に、作業成果物を変更するイベントの1つ」という誤解が生じ、「再発を防ぐための“根本治療”」ができなくなってしまいます。 成熟した組織が実践していることSUP.9とSUP.10をSUP.8:構成管理プロセスと合わせた関係図は以下になります。不具合や障害などの問題が発生した場合、その情報を問題管理データベースに登録後、内容を調査し、原因や影響を分析します。原因が、自分たちの開発対象であれば、変更する必要がありますが、テスト環境や関連する他システムに起因する場合もありますので、変更の必要がないケースもあります。原因&影響分析の結果、変更が必要な問題であった場合、変更依頼管理票を起票し、その情報を変更管理データベースに登録し、変更管理していきます。問題管理と変更依頼管理を別々のデータベースとして管理していきたいのは、繰り返しになりますが、その役割が異なるからです。 問題解決管理:なぜ問題が起きたのかを突き止める 変更依頼管理:対策や改善を、リスク管理しながら実装する例えば、JIRAのようなチケット管理システムで両者を実現する場合でも、登録したい情報(フィールド)は異なりますので、チケットタイプは別々に定義して管理していきます。これらの情報は、単に、今起きている問題や変更への対応だけを考えると、「面倒だから記録したくない」「修正すれば良いので、適当な文章で書いておけば良い」など、疎かな活動になりがちです。しかしながら、我々のお客様でも「情報が正しく書けていないため、後になってみても、状況を理解できない」というような声を聞きます。特に、問題対処に変更を重ね、変更した箇所に更に問題対処を加えるソフトウェア開発では、記録する情報の正確性が重要となります。これら両プロセスをデータは、関連づけること、どの問題が、どの変更によって解消されたのか。逆に、どの変更が新たな問題を生んだのかを明らかにしておきます。こうした可視化が、組織の学習速度を高めます。変更依頼管理に基づき、実際に作業成果物に変更を加えていく場合は、SUP.8:構成管理プロセスの仕組みを利用することになるのです。 おわりに車載開発に限らず、システム/ソフトウェア開発では、問題解決管理プロセスは“守り”、変更依頼管理プロセスは“攻め”と表現されることがあります。しかし実際には、どちらも組織を前進させるために欠かせない車の両輪です。トラブルに強く、かつ変化を恐れない組織を目指すために、今一度この2つのプロセスの関係性を見直してみてはいかがでしょうか。 内山哲三

コラム

ソフトウェア開発組織をどう評価するか ~エンジニアリングチーム全体を評価し、組織改善につなげるために ~

はじめにソフトウェア開発組織の改善を進めるうえで、 「何をもって良い組織と言えるのか」、「改善の効果をどう測るのか」は常に悩ましいテーマです。組織のエンジニアリングチームは「うまくいっているのか」,「何がボトルネックなのか」を感覚だけで語ることの限界を感じたことはないでしょうか。ソフトウェア開発は個人プレーではなく、プロセス・ツール・人の協働によって価値を生み出すチームスポーツと言ってもよく、改善の単位も「個人」ではなく、エンジニアリングチーム全体で捉える必要があります。 本コラムでは、開発組織評価の代表的な枠組みである、以下のの3つを取り上げ、 それぞれの役割と、どう組み合わせて活用すべきかを解説します。 SPICE(プロセス成熟度) DORAメトリクス(デリバリーパフォーマンス) SPACEフレームワーク(人とチームの状態) 評価の前提:目的は「管理」ではなく「改善」最初に確認しておきたいのは、 評価は人やチームを序列化するためのものではないという点です。評価の目的は、 現状を正しく理解する(チームの強みと弱みの理解) 課題やボトルネックを可視化する(課題/ボトルネックの特定) 改善施策がチームにどのような影響を与えたかを確認する(効果を検証) エンジニア同士やマネジメントとの対話を深める(建設的な対話を促す)といった、継続的改善を支えることにあります。この前提を共有しないまま指標だけを導入すると、数字を守ること自体が目的化し、現場の疲弊を招きかねません。 SPICE:プロセス成熟度の評価SPICE(ISO/IEC 330xx) は、ソフトウェア開発プロセスの能力(Capability)を評価する枠組みです。要件定義、設計、実装、テストなどの工程が一定の成熟度レベルで統制されているかを測定します。SPICEで評価できること プロセスが標準化・管理されているか 組織内で再現性のある開発が実現できているか 継続的改善が文化として根付いているかSPICEの成熟度レベル(例) レベル 1:実行されているが管理されていない レベル 2:管理され、最低限のプロセスがある レベル 3:織標準プロセスが定義されている レベル 4:プロセスが定量的に管理されている レベル 5:プロセス改善が組織的に推進されているSPICEで利用できる具体的な評価指標の例プロセス運用に関する指標 要件レビュー実施率 変更管理プロセス遵守率 リスク管理票の更新頻度 プロジェクト計画の逸脱率(進捗・工数など)品質管理に関する指標 工程別の手戻り件数(要件→設計・設計→実装 など) レビュー指摘の再発率 テスト計画と実績の乖離率SPICEの指標は、プロセスが安定して回っているかを確認する際に非常に有効です。一方で、SPICEは人の心理的状態やチームの疲弊まではほとんど扱いません。 DORAメトリクス:デリバリーパフォーマンスの評価DORA(DevOps Research and Assessment)は、開発チームのパフォーマンスを測定するための指標群です。Google Cloud が主導する大規模調査に基づいており、“高いパフォーマンスを出すチームが共通して持っている特徴”として知られています。DORAの4つ主要指標(Four Keys) デプロイ頻度価値をユーザにどれだけ頻繁に届けられているか 変更リードタイムコード変更が本番環境に届くまでのスピード 変更失敗率リリース後に発生する障害の割合 復旧時間(MTTR)障害発生時の復旧までの時間DORAで使える具体的な評価指標の例 自動テスト実行率 CI/CD パイプライン成功率 プルリクエストの平均レビュー時間 リリースごとのバグ発生率これらは、スピードと安定性を同時に捉えられる点が特長です。 SPACE:人とチームの「状態」を可視化SPACEフレームワークは、Microsoft Research や GitHub などの研究者によって提唱された、 開発者生産性を多面的・人間中心に捉えるための枠組みです。SPACEの5つの観点 S:Satisfaction and Well-being(満足度・幸福度) P:Performance(成果・品質・価値) A:Activity(活動量) C:Communication and Collaboration(協働) E:Efficiency and Flow(効率性とフロー)SPACEの特徴SPACEは「この指標を使うべき」という規範的モデルではありません。組織のコンテキストに応じて、適切な指標を選び、組み合わせて使います。特に重要なのは、以下のような、DORAやSPICEでは見えにくい側面を補完できる点です。 数値改善の裏でエンジニアが疲弊していないか コミュニケーションが滞っていないか 割り込みが多く集中できていないのではないかDORA・SPACEだけでは測れない評価の視点(補足)フロー全体を見る指標 サイクルタイム WIP(仕掛かり作業数) フロー効率これらは SPACE の Efficiency and Flow を具体化したものです。チームが「どこで詰まっているか」を明確にします。 技術的健全性 技術的負債の増減 静的解析違反数 依存関係の陳腐化短期的な成果には表れにくいものの、 将来のパフォーマンスに大きく影響する要素です。 SPICE・DORA・SPACEの使いわけ組織/チームの改善では、SPICE・DORA・SPACEを必ずしも同時に評価する必要はありません。重要なのは、「いま何を知りたいのか」に応じて使い分けることです。①DORA:「何が起きているか」を知る改善の出発点として有効なのが、DORAメトリクスです。・リードタイムが長い・デプロイが滞っている・障害対応に追われているといった、チームの成果としての状態を客観的に把握できます。ただし、DORAが示すのはあくまで「結果」であり、なぜそうなっているかまでは分かりません。②SPACE:「チームの状態はどうか」を確かめるDORAで気になる結果が見えたら、次に見るべきは チームの状態です。SPACEフレームワークを使うことで、・無理をして改善していないか・コミュニケーションは機能しているか・集中して開発できているかといった、数値に表れにくい側面を確認できます。SPACEの役割は、改善がチームにとって健全かどうかを見極めることです。③SPICE:改善を「再現できる仕組み」にする最後に問うべきなのが、「このやり方は、チームの力として定着するか?」という点です。SPICEは、以下のような、チームを支える土台を評価します。・やり方が個人に依存していないか・プロセスが暗黙知になっていないか・改善が継続できる仕組みになっているか④改善では「流れ」で使うSPICE・DORA・SPACEは、次の順で使うと分かりやすくなります。改善後は再び DORA を確認し、この流れを繰り返します。   おわりに組織/エンジニアリングチームの評価は“目的”ではなく、“組織を強くするための手段”です。また評価指標は、エンジニアリングチームを縛るためのものではなく、チームと向き合い、より良くするための共通言語です。SPICE、DORA、SPACEを適切に組み合わせて得られた情報をもとに、 「なぜこうなっているのか」 「何から改善すべきか」  「人は無理をしていないか」を対話して共有化することが、重要です。評価を武器にするのではなく、 学習と改善を支える補助線として使うこと。それが、健全で持続可能なソフトウェア開発組織につながると考えます。 (佐藤崇)

コラム

同じ失敗を繰り返さないプロジェクト管理 ─ 再発防止の実践ポイント

■なぜ、あの失敗は何度も起きるのか?開発プロジェクトの合間に、こんな会話を耳にすることがあります。「この前も同じような問題があったよね?」「気を付けていたつもりだったけれど…また再発してしまった」こうした状況は決して珍しくありません。多くの開発現場では、重大な問題が発生した際に「過去にも似た状況があった」と振り返るケースが少なくないと言われています。もちろん、プロジェクトで起きる問題の形や影響はさまざまで、個別の技術的課題や外的要因によるトラブルも存在します。それでもなお、現場を振り返ると、同じような状況や判断の迷いが重なった結果として問題が再発しているケースが見受けられます。では、なぜ似たような失敗は繰り返されてしまうのでしょうか。 ■同じ失敗が起きる主な要因とは?ある車載ECU開発プロジェクトでの出来事です。当初のプロジェクトの目的は「画面表示の起動時間を短縮する」ことでした。ところが開発途中で、「起動時にロゴアニメーションを入れたい」「警告メッセージの表示仕様も変更したい」「診断ログも取得できるようにしてほしい」といった要望が追加され、チームは「せっかくなら対応しよう」と順次取り込みました。しかし、誰も「起動時間短縮が最優先なのか、それとも新機能追加なのか」を明確に整理しないまま進めたため、「あるメンバーは表示品質を優先」「別のメンバーは起動速度を優先」「別の担当は診断要件の網羅性を重視」と、目指すゴールが少しずつズレた状態で開発が進んでしまいました。その結果、統合テストの段階で「起動時間が目標を満たさない」「ログ取得時に表示が遅延する」といった問題が同時に発覚し、大きな手戻りが発生しました。さらに、スケジュール遅延の兆候は早い段階で見えていたにもかかわらず、「どの時点で誰に相談するか」「何を優先的に削るか」が決まっていなかったため、対応は常に後手に回りました。このような問題は以前にも何回か起きていたようです。 同じ失敗が繰り返される背景には、・目的と優先順位が共有されていない・問題発生時の動き方が決まっていないといった構造的な要因が背景にあるケースは少なくありません。目的が揃わないまま進めると、メンバーごとに判断基準がばらつき、問題が起きても対応の優先度や対処方針が統一されません。さらに、初動対応やエスカレーションのルールが明確でない場合、対応は場当たり的となり、問題の影響が拡大しやすくなります。その結果、納期や目先の対応を優先した暫定対処で収束させてしまい、根本原因が解消されないまま次のプロジェクトへ持ち越されます。そして同様の条件が重なったとき、類似したトラブルが再び発生する可能性が高まります。 ■成功するプロジェクトが共通して実践している取り組み前述の例のように、失敗の原因は個人の注意不足だけでなく、目的の共有不足や優先順位の不明確さ、問題発生時の対応ルールの欠如といった“進め方の仕組み”に起因しています。では、同じ状況に直面しても手戻りを最小限に抑え、着実に成果を出し続けるチームは、どのような工夫をしているのでしょうか。私の経験を基に、実際に効果のあった取り組みの一例をご紹介します。 1. 要求分析と優先順位決定プロセスを機能させる要求が増え続けること自体は珍しいことではありません。問題は、優先順位を判断する基準や変更時の意思決定プロセスが明確でない場合、チーム内で判断軸がばらつくことです。成功している組織では、 最優先事項を判断する基準を定める 要求変更時に影響範囲(品質・性能・日程)を確認する 優先順位を見直す意思決定ルールを設けるといった仕組みによって、要求分析プロセスが機能する状態を維持しています。例えば、変更要求が出た際に「最優先目標に影響しないか」を確認するチェック項目を設けるだけでも、判断のばらつきを抑えることができます。 2. 問題の早期解決を支える支援・エスカレーションの仕組みプロジェクトは計画通りに進まない状況が発生することを前提に運営する必要があります。重要なのは、問題が顕在化した際に 誰が・どの段階で・どこへ相談するのか が明確になっていることです。とある組織では、進捗管理・課題管理・リスク管理といった基本的なプロジェクト管理プロセスは整備されています。そのうえで、現場だけでは判断が難しい状況に備え、経験豊富なPMや技術リーダーが横断的に支援する仕組みを設けています。現場ではこれを通称「駆け込み寺」と呼んでいます。この仕組みの目的は属人的な助言ではなく、 進捗遅延や品質リスクの早期検知 判断に迷う局面での意思決定支援 問題対応の優先順位整理 組織としての対応方針の統一といった、プロジェクト運営プロセスを補完・強化することにあります。このような支援体制は大掛かりな組織でなくても導入可能です。例えば、 PM経験者が週1回相談枠を設ける リスク顕在化時の相談ルートを明文化する 重要課題をレビューする横断ミーティングを設けるといった小さな仕組みから始めることもできます。 3. 振り返りを“教訓化”につなげる仕組み振り返りの重要性は多くの現場で理解されています。しかし実際には、「事実の整理で終わってしまう」「個人の反省に留まる」「次のプロジェクトに活かされない」といったケースが少なくありません。効果的な振り返りを行う組織では、 結果の整理 原因の特定 再発防止策の決定 次回の実行ルールへの反映をセットで行います。例えば、再発防止策をチェックリストや標準手順に反映し、次プロジェクト開始時に確認する仕組みを設けることで、経験を組織の資産として蓄積できます。 ■あなたのチームでは、同じ兆候が起きていませんか?失敗の再発は偶然ではなく、進め方の仕組みに起因することが少なくありません。そして、その仕組みを整えることで、同じ問題が繰り返される可能性は大きく減らすことができます。ここまでお読みいただき、「自分たちの現場にも当てはまる」と感じられた方も多いのではないでしょうか。例えば、次のような兆候は見られませんか?☑ チーム内の意思疎通に不安がある☑ 課題が何度も再発し、改善が定着しない☑ プロジェクト管理が“実態と合っていない”と感じる☑ 組織としてのプロセスを整えたいが、どこから手を付けるべきかわからないもし一つでも思い当たる点があれば、それは個人の努力ではなく、仕組みを整えることで改善できる余地があるというサインかもしれません。 「自社ならどこから手を付けるのが最短か」を整理したい場合は、1~2週間のクイック診断からご支援することも可能です。小さく始めて、現場に無理なく定着させる改善をご一緒に進めていきます。まずは、現状の困りごとや課題をお聞かせいただくだけでも構いません。 ご相談・お問い合わせはこちらから→https://www.bgarage.co.jp/contact/ (長澤克仁)

コラム

構成管理の基本の「き」 ~当たり前なことが難しい~

はじめに システム開発/ソフトウェア開発の現場では、日々多くの変更が行われています。機能追加、バグ修正、設計変更。。。そのすべてがソースコードやドキュメントに影響を与えます。この変化の連続を“管理された状態”に保つための仕組みこそが 構成管理(CM) です。今回は、Automotive SPICEのプロセスの1つである、SUP.8:構成管理の基本について、IEEEなどの国際標準も交えて解説します。 なぜ構成管理が必要なのか 構成管理がうまく機能していない現場では、こんな光景がよく見られます。 “誰が”“いつ”“どこを”“なぜ”変更したのか追跡できない 昨日の動くバージョンに戻したいのに、戻せない ドキュメントと実物が噛み合わず、レビューで混乱 変更したつもりが、別の人の作業で上書きされていたこれらはすべて、生産性と品質を静かにむしばむ“構成管理不足”のサインです。構成管理の目的は一言でいえば、変更の見える化と安定した開発の継続です。 構成管理の主要な4つの活動 1.構成識別(Configuration Identification)まず管理対象となる作業成果物を明確にします。この管理対象を構成品目(Configuration Item:CI)と呼びます。ソースコードはもちろん、設計書、テスト仕様書、ビルド手順書など、作業成果物すべてが対象となり得ます。どこまでを管理するのか最初に決めておくことが、とても重要です。Automotive SPICE v4.0では以下のように解説しています。 構成品目とは、単一の実体として構成管理の対象となる作業成果物または作業成果物一式を指す。 構成品目は、システム、ハードウェア、およびソフトウェアのすべての文書を含むシステム全体から、単一のエレメントまたは文書に至るまで、複雑性、規模、および種類が異なる場合がある。  選定基準は、単一の作業成果物または作業成果物一式に適用してよい。また国際標準である、IEEE 828「IEEE Standard for Configuration Management in Systems and Software Engineering」では、以下のように定義しています。 構成管理のために指定され、構成管理プロセスにおいて単一のエンティティとして扱われる作業成果物の集合体。 構成品目は、その複雑さ、規模、種類が多岐にわたる場合があり、ハードウェア、ソフトウェア、ドキュメントをすべて含むシステム全体から、単一のモジュールやマイナーなハードウェアコンポーネントまで多岐にわたる。プロジェクトの範囲や、標準資産の再利用の考慮等によって、構成品目は様々ですが、必ずしも「1ファイル=1構成品目」である必要がないことは上記からも理解できると思います。「単一の実態として扱われる作業成果物の集合体」が構成品目となります。 2. 構成制御(Configuration Control)構成管理の根幹となる活動は、変更手続きを管理し、変更を追跡することで、製品の構成が常に正確に把握されるようにすることです。構成制御は、ベースラインを完全に識別し、そのベースラインに対して行われたすべての変更を追跡することによって実現されます。Automotive SPICEではベースラインを以下のように定義しています。 1つまたは一連の作業成果物および生成物の一貫性が保たれ、かつ完成した状態であることを識別している。 次のプロセス段階および/または納入のためのベース。 一意であり、変更されてはならない。少しわかりづらいので、再びIEEE 828を参照してみましょう。以下のように定義しています。 正式にレビューされ合意された仕様または製品であり、その後は以降の開発の基礎となり、正式な手順を通じてのみ変更可能である。  媒体を問わず、構成アイテムのライフサイクル中の特定の時点で正式に指定及び確定された、構成アイテムの正式に承認されたバージョンである。 ソフトウェアベースラインとは、ソフトウェアライフサイクル中の特定の時点で正式に指定され、確定されたソフトウェア構成アイテムの集合(1つまたは複数)である。開発ライフサイクルのある時点(たとえば、要件が確定した時点や統合テストを始める時点)で、正式の合意された製品目一式がベースラインであり、以降の開発工程や納入の基となるものです。好き勝手に変更していけないのがベースラインであり、適切にベースライン(構成品目の集合体)を作成&更新していくことが構成管理の根幹となります。この適切な作成&更新を行うためには、正式な変更手順だけではなく、構成品目を格納する「ライブラリ」も重要となります。皆さんの中には既に、作業成果物の格納場所として、Git や Subversion などのツールを利用している方もいると思いますが、国際標準であるIEEE 1042「IEEE Guide to Software Configuration Management」で述べているライブラリの概念が基本となっています。   ダイナミックライブラリ(プログラマーズライブラリとも呼ばれる): 新規作成または変更されたソフトウェアエンティティ(ユニット/モジュール、データファイル、および関連ドキュメント)を格納するために使用されるライブラリ。 これは、作業担当者がコード開発で使用するライブラリで、そのユニットを担当する作業者は、いつでも自由にアクセスできます。 これは作業者の作業スペースであり、作業者によって管理される。 管理ライブラリ(マスターライブラリとも呼ばれる): 現在のベースラインを管理し、それらに加えられた変更を制御するために使用されるライブラリ。 これは、統合のために生成された構成品目のユニットとコンポーネントが保持されるライブラリ。 通常は検証後にエントリが認められる。 作業者やその他のユーザーが使用するために、コピーを作成できるが、このライブラリ内のユニットまたはコンポーネントへの変更は、責任部署(構成制御委員会または委任された権限を持つ機関)の承認が必要。 スタティックライブラリ(ソフトウェアリポジトリとも呼ばれる): 一般利用のためにリリースされた様々なベースラインをアーカイブするために使用されるライブラリ。 これは、運用のためにリリースされた構成品目一式のマスターコピーが保管されるライブラリ。 これらのマスターのコピーは、要求する組織に提供される場合がある。 3. 構成ステータス記録(Status Accounting)構成管理下にある構成品目(作業成果物)に関する重要な情報を記録し、管理者と作業者に報告し、「構成品目が今現在どんな状態か」を共有することが、この活動の目的となります。IEEE 828では、構成品目のステータス情報は、以下のことに役立つと述べています。 ある期間における、プロジェクト作業の結果を把握し、とある時点での完了見込みを把握する。 例:要件の数と実装済みの数を比較することで、これまでの進捗状況を把握できる。  開発中の製品の安定性と機能の完成度に関する状態を把握する。 例:機能またはコンポーネントに対して、実装済みおよび保留中の変更の数は、安定性または変動性を示している。 構成品目の管理(構成管理活動自体)を検証する。 必要に応じて、外部コンプライアンス監査の要件(例:SOXなど)を満たす。「構成ステータス記録」は、構成管理活動自体を監視するプロジェクト管理機能でなく、あくまで構成品目(作業成果物)の状態を監視するものであることも理解しておく必要があります。 4. 構成監査(Configuration Audit)「管理されているはずの状態」が、本当に実態と一致しているかを確認する仕組みです。 ドキュメントの記載と成果物が一致しているか 承認フローが守られているか リリース物は正しい構成か監査は厳しいものではなく、「間違いが積み重なる前の安全装置」というイメージです。 構成管理はツールではなく「文化」Git や GitHub、Azure DevOps、Subversion などのツールは SCM を支える重要な存在ですが、ツールを導入しただけでは構成管理ができたとは言えません。大切なのは、そのツールを使って一貫したルールとプロセスを回し続ける文化があるかどうかです。例えば: ブランチ戦略をチームで統一する コードレビューをルール化する 変更理由を残す習慣をつける リリース手順を標準化するといった取り組みが、SCMの“文化”を育てます。 さいごに構成管理は、「開発を安定させるための基盤であり地盤」です。目立たない活動ですが、これがしっかりしているチームはトラブルに強く、改善サイクルも回しやすくなります。地盤が安定していれば、どんな大きな建物(=プロジェクト)でも安心して積み上げることができます。  内山哲三 

コラム

プロセス改善コンサルティング、成功と失敗の分かれ道

Automotive SPICEやCMMIに準拠したプロセス改善を積極的に取り組む設計現場が広がってきている反面、改善の必要性を感じながらも、「本当にコンサルを入れるべきなのか」「また期待外れに終わってしまうのではないか」そんな迷いを抱えていらっしゃる方も多いのではないでしょうか。実際、私たちがこれまでご相談を受けてきた中でも、次のようなお声を耳にしてきました。「過去にコンサルを入れたが、やることだけが増えて楽にならなかった…」「立派な資料は残ったが、現場のやり方は結局変わらなかった…」「コンサルに頼ると、自分たちの力が育たない気がする…」これらは、決して珍しい意見ではありません。そして同時に、「コンサルティングサービスがうまく機能しなかった典型例」でもあります。■見過ごされている2つの「ズレ」プロセス改善コンサルティングが失敗する背景には、主に以下のようなズレが潜んでいます。 ズレその1:目的の不一致「レベル認証を取れればいい」のか、「自律的な改善ができる組織にしたい」のか——この目的が、依頼部門と開発現場で共有されていないケースが非常に多いのです。依頼部門:「認証取得をきっかけに、組織を変えていきたい」開発現場:「とにかく早く認証を取って、元の業務に戻りたい」こうした認識のズレがあると、現場の協力が得られず、形だけのプロセスで終わってしまいます。 ズレその2:アプローチの不一致コンサルティングには、大きく分けて2つのアプローチがあります。【代行型】改善作業を代行し、短期間で認証取得を目指す【伴走型】課題や施策を現場と一緒に整理しながら進め、組織にノウハウを残すどちらが優れているということはありません。問題は、目的に合わないアプローチを選んでしまうこと、そしてこの選択を曖昧にしたままプロジェクトを始めてしまうことです。 失敗の本質は、「誰が悪い」という話ではありません。目的や期待を関係者間ですり合わせる——このステップが抜け落ちたままプロジェクトが始まってしまうことにあるのです。 ■「ズレ」を解消したことで現場が変わった事例では、これらのズレを解消すると、現場はどう変わるのでしょうか。実際の事例をご紹介します。 【依頼時の状況】ある設計現場からご相談をいただいた際、次のような課題を抱えていらっしゃいました。・問題は発生してから初めて共有される・進捗会議では「今どうなっているか」の報告に終始する・遅延や手戻りの原因が、毎回「想定外」「人手不足」で片付けられる・設計者からは「レビュー準備だけで工数を取られる」「成果物のトレーサビリティ維持が負担」という声が出ていた過去にもコンサルを入れたことがあったそうですが、「立派な資料は残ったが、現場のやり方は結局変わらなかった」とのことでした。 【目的の共有】まず私たちが行ったのは、依頼部門と開発現場の責任者の方々と、次の点を時間をかけて対話することでした。「今回の目的は、認証取得だけですか? それとも組織を変えることですか?」結果、「認証取得はあくまで通過点で、現場が自律的に改善を続けられる力をつけたい」という明確な目的を、全員で共有できました。加えて、今回のコンサルの期待として、「なぜこのプロセスが必要なのかという考え方を現場に残してほしい」、「プロジェクトが終わった後も、自分たちで改善を続けられるようにしたい」という期待があることも共有することができました。 【アプローチの選択】目的と期待が明確になったことで、私たちは伴走型コンサルティングを提案し、具体的な進め方について合意しました。・プロセス文書は一緒に作る(現場の実態を反映させる)・「やらされ感」ではなく、「なぜ必要か」を理解しながら進める・ノウハウを組織に残すことを最優先する 【結果】プロジェクトでは、解決策の提示だけでなく、「どのタイミングで、どんな兆候が出ていたのか」「本来、どこで意思決定すべきだったのか」などを、現場の方と一緒に整理しました。その上で、・進捗とリスクを一目で把握できる形に整理し・「問題が起きてから」ではなく「起きる前に気づく」視点を共有し・これまで個人の経験に頼っていた判断を、プロセスとして定義していきました。すると、同じメンバー・同じ工数でも、現場からは「次に何を確認すべきかが分かるようになった」、「認証取得後も、このやり方を続けていけそうだ」といった声が出るようになりました。その結果、手戻りによる追加工数が約3割削減され、プロジェクトの予測精度も向上しました。このような伴走型の支援にご興味がある方、または「自社の状況ではどのアプローチが適しているか知りたい」という方は、ぜひお気軽にお問い合わせください。 ■まずは2つの問いから始めてみましょうコンサルを活用することは、決して自分たちの力を否定することではありません。重要なのは、「何のために」「何を期待して」コンサルを入れるのかを明確にすることです。まず、この2つの問いについて考えてみてください。 問1:皆様の目的は何ですか?まずは認証を取得することが最優先ですか?それとも認証取得をきっかけに、組織を変えていきたいと考えていますか? 問2:コンサル後の姿をイメージできていますか?認証が取れたら終わりですか?その後も自分たちで改善を続けたいですか? もし1つでも不明確な答えがあれば、まずはその整理からご一緒させてください。私たちは、いきなり解決策を押し付けることはいたしません。認証取得の目的は何か、社内の関係者間でその目的は共有されているか、どのようなアプローチ(代行型/伴走型)が適しているか——これらを一緒に考えるところから始めます。目的が明確になれば、コンサルティングサービスは確実に組織の未来を変える力になります。 ▼プロセス改善コンサルティングに関するお問い合わせはこちら(ご相談ベースでも構いません)https://www.bgarage.co.jp/contact/ (長澤克仁)