プロセスモデリング ～ プロセス文書化のテクニック
前回のコラム（プロセスとは何か？）では、開発プロセスについて考察し、プロセスを文書化する際のヒントと注意点についてお伝えしました。今回は、プロセスを文書化する際のモデリングのテクニックについてご説明いたします。
プロセス文書は、どのような用途で使われるのか？
簡単に言うと、プロセスは２種類の使われ方に分類されます。
- 「組織標準プロセス」 として全プロジェクトがプロセスを使う場合
- このケースでは、扱う製品や開発ライフサイクルの異なるプロジェクトが、標準プロセスを自分のプロジェクト用にテーラリングして使用することになります
- このため、プロセスは各プロジェクトの用途に合わせた柔軟な選択や、つなぎ合わせが可能な形式で表現することがポイントです
- プロセスはフォーマルな形式で文書化される必要があり、Automotive SPICE 能力レベル３で求められるプロセス状態にもっともフィットした形式と言えます
- 「プロジェクト内のルール」 として同じプロジェクト内でプロセスを使う場合
- このケースは、同じプロジェクト内の業務フローや作業手順をプロジェクト内で共有する使い方です
- このプロセスを他のプロジェクトが使用することはありませんので、プロジェクトの中で自由な方法で文書化すればよく、形式的な制約もありません
プロセスモデリングの考え方
ここでは、フォーマルな形式でプロセスを文書化していく場合に有効な「プロセスモデリング」の考え方をご紹介します。
プロセスは、３つのレベルを用いて定義すると、プロセスの組み換えや、その後発生する改善が容易にできるとされています。すなわち、次のような３階層に分けることを念頭にプロセスの各要素を定義していくことが推奨されます。
- 抽象的なレイヤー
プロセスモデリングでは、Universal Process Modelと表現され、上位レベルの概要を提供し、方針を具体的に表現するレイヤーです。
例えば、「すべての作業はベースラインに統合される前にインスペクションを受けること」のように、基本方針を定義することになります。 - 現実的なレイヤー
プロセスモデリングでは、Worldly Process Modelと表現され、上位レベルの方針を実現するための手順を確立するレイヤーです。
具体的には、作業者の作業順序をガイドし、作業に必要な条件と結果を定義し、詳細な手順や成果物のテンプレートなどは、適宜下位レイヤーの文書を参照することになります。
例えば、「いつ、だれが、どのようにSQA監査を実施する」のような作業レベルの手順を定義することになります。 - 詳細なレイヤー
プロセスモデリングでは、Atomic Process Modelと表現され、極めて詳細な手順を確立するレイヤーです。
成果物を作成する手順やテンプレートなどが該当します。
例えば、「アーキテクチャ設計の設計技法」、「アーキテクチャ設計書テンプレート」などを定義することになります。
プロセスアーキテクチャ設計の事例
プロセスモデリングの考え方を参考に作成したプロセスアーキテクチャ設計の事例をご紹介いたします。
本事例では、４階層のプロセスアーキテクチャを設計しましたが、手順はおおむね次の通りです：
- プロセスの階層を決定する
- 各階層で作成するプロセス文書を決定する
- プロセス文書のフォーマットを決定する
- プロセス文書を作成する
- 作成したライフサイクルにプロセス部品を当てはめプロセスを作成する
ここで注意していただきたいのは、プロセスアーキテクチャはプロセスの静的な構造であるということです。プロセスの動的な側面では、ここで作成したプロセス文書（アクティビティ、タスク、プロセス資産など）をプロセス部品として捉え、プロセスは部品を連結して作成するという前提に立っているということです。
この考え方は、いわゆるオブジェクト指向のアプローチを踏襲しています。OMG（Object Management Gruop）から、SEPM（Software and System Process Engineering Metamodel）が発行されているので、興味のある方は参照してみてください。
さいごに： Automotive SPICE 能力レベル２のプロセス文書
今回は、Automotive SPICE 能力レベル３で必要となるフォーマルな形式による組織標準プロセスの作成に焦点をあてて説明してきました。最後に、Automotive SPICE 能力レベル２で求められるプロセス文章の形式について簡単に触れておきます。
能力レベル２の要点は、計画的に作業を進めることです。作業の計画を立てるには、何らかのプロセス文書は必要でしょう。しかしながら、今回説明したような部品を結合してプロセスを作成するようなことは求めていません。どのような形式であろうと、作業ルールがプロジェクト内に周知できるレベルの文書があれば問題ありません。最初から難しいレベルを求めず、まずは必要最低限のルールを決めて、計画的な作業ができる環境を整えてください。
（日吉 昭彦）