(4)プロジェクトコンテキストについて

コンテキストに基づいたクライテリアの生成をしようとするときの、プロジェクトコンテキストってどんな情報が使えるかな？について。まず基本となるのは、アセスメント計画における情報収集になると思います。下記のアセスメントデータでうまく表現できるといいですね。

アセスメントデータ

事業背景	（当プロジェクトはｃｃｃｃ向けｐｐｐｐを開発するｘｘｘｘプロジェクトである。ｘｘｘｘにおいてはAutomotive SPICEレベル２の達成が目標である。また、今後の事業におけるコア技術／製品として展開される。）
製品の説明	（適用分野、特性、特徴など）
ライフサイクル段階	（試作、量産、開発完了など）
開発期間	2023/xx – 2023/xx
人員数	ｘｘ名（プロジェクトまたは組織の人員数）
開発ツール	(例:Stages, JIRA, MATLAB/Simulink, QAC, GitHub)
安全特性	☒ISO 26262:2018 2nd (自動車機能安全)ASIL ☐A,☐B,☐C,☐D ☐ISO 21448:2022 (SOTIF:意図した機能の安全性)
セキュリティ特性	☐ISO/SAE 21434(自動車のサイバーセキュリティ)

---

それで、たとえば次のようなコンテキストパターンを想定してみます。

・カメラ画像認識モジュール,PoC,基本機能の動作実証,Agile,スプリント期限優先

・ディスプレイユニット, Bluetooth-I/F, Cybersecurity(CS), OTA

・EV用回生ブレーキシステム,ASIL-D,MATLAB,主力製品

これを基本パターン（？）として、エクセルベースでクライテリア準備しといて変更要因分の差分修正をするとかでなんとかならんだろうか。んーそれじゃ無理そう。と何年も思っていたわけです。

実際アセスメントでは、頭の中で「こういうプロジェクトだから、このプロセスではここが重要リスクだな」とか考えながらインタビュー＆評定するんですが、それを全部文書化したりデータ化したりするのは無理だよね。どうやってもぶれるし。アセスメントの最初と最後じゃ感じ方が違うこともままあるし、いちいち説明したら矛盾が出るし。時間は無いし。アセッサーの裁量権限なんだからいらんこと説明しないでだまっとこ。と（ていうかそうしかできんわ人間だもの）

デンソークリエイトさんが、プロセスの組み換え（テーラリング）をパラメータ使ってやってるという取り組みをずっとされてて、NSPICEでも発表されていますね。いや、発表はいつもカッコよく聞こえるんだけど、実際運用するのはそりゃ大変だろうなと思っています。どえりゃーえらいわほんと。

Series Navigation

<< (3)アンケートデータ(Fact)(5)クライテリアクライテリアクライテリア！(Fact) >>