車載システム開発プロジェクトの現状

システム開発の多層化と複雑化

図1は、車両・システム開発のレイヤーを図示したものです。最上段の「車両要求」を実現するため、各種システムで役割分担する設計を行い、そこからユニット設計のために、各ユニットに要求を出します。それぞれの担当範囲として「自動車メーカー」「Tier1」「Tier2」とありますが、最近は自動車メーカーが下位のユニット設計を行ったり、Tier1サプライヤーが車体開発に進出したりと、いわゆる水平分業体制になってきており、システム開発の多層化と責任分担の複雑化が進んでいます。

また、現在はさまざまな部品にソフトウェアが搭載されるようになり、多くの部門が新たにシステムを開発するようになりました。そのため、システム開発に関わる組織・企業の複合化が顕著になっています（図2）。

図3は、自動車開発の「システムズエンジニアリング化」についてまとめたものです。システムズエンジニアリングとは、システムの実現を成功させるための複数の分野にまたがるアプローチおよび手段を指します。左のV字開発プロセスを例に見れば、自動走行要求を満たす「駆動・制動・操舵」「運転支援」「高精度地図」などのシステムを組み合わせ、さらに「目的別システム」「アプリ・クラウド連携」といった新たな拡張要求を積み上げています。また右の図は、システム・機能・関係組織の増加による整合界面の増加を示しており、結果として分散組織で分担開発するプロジェクトマネジメントや検証の重要性が高まる状況になっています。

品質確保に必要な４領域

図4は、プロダクトとプロセス、それぞれの品質を向上するためのValidation（妥当性確認）とVerification（検証）をまとめたものです。図右上の「プロダクトのVerification」（仕様通りに作っているかの検証）はベリサーブが従来から取り組んできた業務ですが、最近では同左上の「プロダクトのValidation」（要求を実現できる仕様であるかなどを確認）の重要性が高まっています。
そのためには「プロセスのValidation」（同左下、目的を実現できるプロセスであるかなどを確認）や、「プロジェクトのVerification」（同右下、プロセスを手順通りに実施しているかの検証）を併せて行う必要があります。これが、ベリサーブがたどり着いた品質確保に必要な4領域で、これら全てが満たされないと手戻りや不具合が生じることになります。

プロジェクトタイプの分類

プロセス状況とプロジェクトタイプ

以前、ベリサーブ主催のセミナーにおいて聴講者アンケートを取ったところ、現状として「開発プロセスが整備されている／されていない」にかかわらず、「困っている」という回答が大半を占めました。私がこれまでに見た現場の事例を分類したところ、整備されているプロセスに対し「古い」「分かりづらい」といった声がある他、新たにプロセスを整備することへの懐疑があるなど、異なる課題があることが明らかになりました（表1）。プロセスの在り方については、部門・チーム・個人によって考えが異なるため、組織や人数が大きくなるほど意見がまとまらない状況が発生します。

組織・プロセス形態による差異

組織・プロセス形態による差異もまた、プロジェクトマネジメントの在り方に大きく関わります。図5の「石垣型」「レンガ・ブロック型」分類は、日本とアメリカ・シリコンバレーそれぞれの組織特性の違いとして、しばしば紹介されるものです。

黄色の線で囲まれている楕円（だえん）や四角が各要員の業務領域を表します。石垣型では、目的に対する体制や要員数を定義し、各要員の能力に合わせて役割をアサインします。一方、レンガ・ブロック型では目的に対するプロセスやジョブを定義し、それらに合わせて要員をアサインするのが特徴です。日本的な組織構成と言われる石垣型と、欧米的なレンガ・ブロック型、それぞれにメリット・デメリットがあり、単純に優劣を語ることはできません。日本の伝統的な企業では、石垣型のまま連携を強化した組織を作り上げ、企業文化に昇華している例もあります。大切なことは、欧米で生まれた標準プロセスを適用する場合、組織の形態や現状を意識し理解した上でなければ、十分な効果が発揮できないということです。組織構造と課題を見極めた上で対策を検討・適用することが重要です。

プロジェクトマネジメントの課題に対応した事例

ここからはベリサーブの事例を基に、プロジェクト運営レベルとそのステップアップについて説明します。取り上げるのは、分担・分散開発の体制でシステム設計を行っている自動車メーカーに対して、プロセスのValidationとプロジェクトのVerificationという2領域で支援した際の事例です。

まず、プロジェクトの運営状況を理解しやすくするため、運営のレベルを便宜的に0～4までの5段階に分類します（図6）。

新規システムやプロジェクトの立ち上げ時、支援を必要とする開発現場のほとんどはレベル0、1からスタートします。以下は、お客様から多く相談が寄せられる0～2の各レベルからのステップアップ事例です。

この段階では主に、リファレンスプロセス（関係者で共有された標準プロセス）が整備できるよう支援します。

課題抽出と対策立案

課題分析は三つのステップで行います。まずは問題や課題、要望といった事象を洗い出し、システム開発全体をカバーするプロセスの枠組み（Automotive SPICEなど）にマッピングします。次に、事象の背景や経緯を確認し、原因の分析と、対策を講じる領域の特定を行います。最後に、対策を実行するためのプロセスの構築や仕組み作りの計画を立案します。

開発プロセスフローの作成

現場へのヒアリングなどを通じて開発プロセスの現状を調査し、課題への対策を踏まえた上で、新たなフローの全体像（開発プロセス概要）を作ります。その際、主要業務間の関連や実施のタイミングが見えるようにするのがポイントです。次に、開発プロセス概要で定義した業務区分別に、作業の流れや各業務のINPUT・OUTPUTを理解しやすい形で明記し、プロセスを詳細化した詳細業務フローを作成します。

この段階ではリファレンスプロセスを運用する仕組みの整備について支援します。

共通・汎用プロセスの運用

会議のファシリテーションや議事録作成、課題一覧の管理、情報の一元管理（各チームへの状況ヒアリング）、期日監視など、比較的一般的な業務支援を行います。これら汎用的な運用支援はどの運用レベルに対しても必要ですが、運用レベルが低い現場においては高い効果が得られる傾向があります。

作業概要／ガイドライン／手順書の作成

プロジェクトで実施する作業の一覧や目的、成果物との関連性を俯瞰できる資料、ガイドラインや詳細な作業手順書を作成します。作業領域ごとにこれらの資料を作成することで、組織標準が作られていない石垣型組織でも各領域の作業を標準化しやすくなります。

教育プログラム作成／教育事務局／運用・改善

リファレンスプロセスに関する資料や、テストに関連の深い「システム開発」部門などに存在する資料を基に、教育資料を作成します。その後、それらの資料を使い、教育事務局として新規参画メンバーに対する「集合教育」を実施することで、メンバーのプロセスに対する理解の底上げを図ります。

この段階ではプロセス運用のシステム化を進め、適切に管理された状態を目指します。

プロジェクト状況／課題の見える化

残された課題の分類・分析や進捗状況のサマリーなどの可視化、DR（デザインレビュー）の指摘内容分析、業務負荷の分析・管理を行います。

プロジェクト運用効率化・業務改善

期待される取り組み効果

このような支援により実施された対策によって得られた効果の例を挙げていきます。

１．組織・グループ別の課題が見えてくる

プロセスの標準化に取り組むこともできないような「忙しすぎる」組織においては、課題が見えづらくなっています。このような組織が抱える問題も課題分析などを通して見えやすくなります。

２．課題領域を絞り込める

対策の実施前はQCDの「品質」と「成果物納期」がともに良くない状況だったのが、レビューの仕組み改善などにより品質の網羅性が高まったケースがあります。つまり課題が「期限」に絞り込まれた（課題を寄せることができた）ことになります。

３．プロセス運用支援チームによるトレーナー的活動で、開発者の負荷が軽減できる

トレーナー的活動では、主に次の工程・組織への移行断面での課題の取りまとめや対策の推進支援を行います。

４．標準規格への適合が容易になる

プロセスが整備されると業務エビデンスをトレースしやすくなるため、標準規格への適合が容易になります。

５．関係する会社・組織間で、それぞれのプロセスの差異が埋めやすくなる

他社・他組織のプロセスと差異がある場合でも、相違点を可視化し、整合方法の検討・運用が可能になります。

おわりに

ここまで見てきた対策は、決して全てのケースに対応するわけではありませんが、課題に対して偏りの少ない適切な分析を可能とするために、ひととおりを検討範囲とすることは重要です。また、組織の階層や役割の垣根を越えた課題に対応するには、第三者による客観的・俯瞰的な課題の「見える化」が有効です。最後に、多くの方は過去の経験の延長で今日の業務を行うため、新たに整備したプロセスがプロジェクトでの日々の経験として定着するよう業務に活かすことが重要です。以上を踏まえながら、プロセスの妥当性とプロジェクト運営のレベルをステップアップしていくことをお勧めします。

この記事をシェアする