プロセス・アーキテクチャ

プロセス・アーキテクチャ|solution of eXmotion

プロセス・アーキテクチャ

ソフトウェア開発におけるQCDを達成するために、それぞれのプロジェクトに合ったプロセスを定義して順守することは有効な手段と言えます。しかし、いざプロセスを定義しようとしても、何をどう決めて良いのか迷う事も多いのではないでしょうか。ここでは、シンプルで理解しやすいプロセスの表現方法として多くの企業で活用されているPFD(プロセス・フロー・ダイアグラム)を活用しつつ、効果的にプロセスを定義する方法について説明します。

【プロセス・アーキテクチャ】PFD(プロセス・フロー・ダイアグラム)とは

PFDはDFD(データ・フロー・ダイアグラム)を改良したプロセスの表現方法であり、「プロセス」と「成果物」の連鎖を「フロー」でつないで表現します。3つの要素で構成され、手軽に作成できるため、最近では多くの企業で活用されています。プロセスには「プロセス定義書」、成果物には「成果物定義書」を作成し、曖昧さを取り除くことができます。

PFDを作ることにより、プロセスと成果物が明らかになることで、関係者間で開発の進め方について合意することができます。また、ムダなプロセスや作業範囲が見えるようになり、より良いプロセスを検討できるようになります。すなわち、開発の状況に合わせて、より良いプロセスに変化させていくことが可能になるのです。

しかし、ただPFDを書けば、開発の問題が解決されるわけではありません。PFDを書くことで、新たに発生する問題もあります。

【プロセス・アーキテクチャ】PFD(プロセス・フロー・ダイアグラム)によるプロセス表現

【プロセス・アーキテクチャ】PFD(プロセス・フロー・ダイアグラム)活用における問題点

実際の開発現場で、PFDを適用した際、問題になりがちなことをいくつか紹介します。

【プロセス・アーキテクチャ】作成したPFD(プロセス・フロー・ダイアグラム)が正しいか判断できない

開発現場では、プロジェクトの要件が暗黙のまま進められていることが良くあります。PFDとプロジェクト要件の関係が希薄な状況ではPFDの正しさを確認することが難しくなります。例えば、開発期間が短いため、既存の成果物を極力使うようにする場合と、既存成果物の品質も向上することを目的とする場合では、プロセスは大きく異なります。

成果物の観点では、入力と出力の成果物は明確ですが、中間成果物は曖昧な状態のままプロセスを設計することがあります。このような状態でもPFDの正しさを確認することが難しくなります。

【プロセス・アーキテクチャ】スケジュールとPFD(プロセス・フロー・ダイアグラム)が合っていない

多くの開発現場では、これまでの経験を元にガントチャートが先に作られ、タスクと成果物の関係が後になってつながっていないことが判明して手戻りになることもあります。これはPFDとプロジェクト要件からスケジュールに落としていないことが問題です。

【プロセス・アーキテクチャ】PFD(プロセス・フロー・ダイアグラム)だけでは理解できないことがある

PFDだけでは、PFD内で表現した成果物間の関係がわからなかったり、成果物の要素間のトレーサビリティがわからないなどの問題があります。また、最終的に完成する仕様書の体系がわかりにくいといった問題もあります。

【プロセス・アーキテクチャ】PFD(プロセス・フロー・ダイアグラム)によるプロセス表現

これらの問題を解決するには、プロセス・成果物を複数の視点(関心事)で定義し、正しさを確認する必要があります。そこで、「プロセス・アーキテクチャ」という考え方が役に立ちます。

【プロセス・アーキテクチャ】プロセスと成果物を複数の視点で定義した「プロセス・アーキテクチャ」

「プロセス・アーキテクチャ」では、プロセス・成果物の関心事を5Wの観点で以下のように5つの成果物を定義します。そのうち、「プロセスの要件」は他の4つのすべてに関係することから、プロセス・アーキテクチャ「4+1ビュー」となります。これにより、プロセスや計画の正しさが確認できるだけでなく、成果物間のトレーサビリティも確保できるようになります。

【プロセス・アーキテクチャ】プロセスと成果物を複数の視点で定義した「プロセス・アーキテクチャ」

【プロセス・アーキテクチャ】【Why】を定義する

プロセスを定義する前に、まずは、プロジェクト自体の要件を明らかにする必要があります。これは、開発のすべての活動のゴールを決めるための要件になります。プロジェクト要件が明確になっていないと、プロセスが定義できないだけでなく、プロジェクトが本来目指すべき方向を見誤って、やり直しが必要になったり、プロジェクトが混乱してしまいます。プロジェクト要件の書き方は、特に決まりはありませんが、下図のようにリスト化するのが一般的です。USDMに精通していればUSDMで書くことで、より正確に記述できます。

【プロセス・アーキテクチャ】【Why】を定義する

【プロセス・アーキテクチャ】【What】 プロセスを定義する

このプロジェクトで何をするか"What"を定義する際に、プロセス側面で作成するのがPFD(プロセス・フロー・ダイアグラム)です。どのようなインプットに対して、何をして、その結果どんな成果物が作成されるのか、というつながりを明確にした図です。プロセスは階層表現が可能で、全体から詳細を表現できます。

【プロセス・アーキテクチャ】【What】 プロセスを定義する

プロジェクトで作成する成果物の論理的な単位、成果物の属性、成果物間の関係を記載するものが成果物関係図です。それぞれの成果物のつながりを関係として記載したもので、成果物のトレーサビリティが明らかになります。どの成果物が、他のどの成果物に影響を与えるのかを知ることができます。

成果物間の静的な関係を表現する図を使う事が一般的で、オブジェクト図やクラス図、ER図などで表現します。

【プロセス・アーキテクチャ】【What】 成果物のつながりを示す

【プロセス・アーキテクチャ】【Where】成果物がどこに配置されるのかを示す

作成する成果物が、公式ドキュメントとしてどこ"Where"に配置されるかを記載するのが公式ドキュメント配置図です。プロジェクトの要件において、必要とされる公式ドキュメントに対して、成果物を割り当てます。このプロジェクトが終了した後、成果物を保守していく上でも、この情報が役に立ちます。

包含関係を表現するために、パッケージ図を使い、成果物関係図で示した成果物が、公式ドキュメントを示すパッケージのどれに包含されるかを記載します。

【プロセス・アーキテクチャ】【Where】成果物がどこに配置されるのかを示す

【プロセス・アーキテクチャ】【When・Who】誰がいつ実施するかを明確にする

PFDでプロセスを明らかにしたら、プロジェクトの要件とあわせて、具体的にプロジェクト計画を作ります。これで、実際にプロジェクトを進めるための具体的なプランができます。

プロジェクト計画は、日程とタスク、それを実施する人が明確になっていることが必要です。ガントチャートが一般的です。

【プロセス・アーキテクチャ】【When・Who】誰がいつ実施するかを明確にする

【プロセス・アーキテクチャ】プロセス・アーキテクチャを定義するPFD

プロセス・アーキテクチャを定義するためのPFDは以下のようになります。

【プロセス・アーキテクチャ】プロセス・アーキテクチャを定義するPFD

既存のプロセスを見直したり、新たな開発のプロセスを明らかにするときは、プロセスの正しさ、成果物間の関係の正しさが作業効率や成果物品質を左右します。プロセス・アーキテクチャの考え方を身に付けてプロセスを自由にデザインし、効率的でムダのない開発プロセスを手に入れましょう。

【プロセス・アーキテクチャ】コンサルタントが教える成功の秘訣

【プロセス・アーキテクチャ】コンサルタントが教える成功の秘訣|エグゼクティブコンサルタント・斎藤 賢一【専門分野】車載機器、USDM要求開発、XDDP、レガシーシステムの可視化と改善、MDD、SPI、SASD

プロセス定義は「やること」にフォーカスしがちで、なぜそのプロセスが必要なのか、作成した成果物は後工程でどう使われるか、といった配慮が欠けることがあります。PFDだけでも十分プロセスの正しさは議論出来ますが、成果物の関係を図で表現することで、不要な成果物や成果物のモレに気づきやすくなります。

また、ALM(Application Lifecycle Management)ツールで成果物を管理するときには、成果物関係図で成果物の属性と成果物間の関係を明らかにすることで、ツールへの取り込みからトレーサビリティ管理までスムーズな移行ができるようになります。

エクスモーションでは現場の改善を進めていく上での「プロセス改善の設計図」としてプロセスアーキテクチャを活用しています。

【プロセス・アーキテクチャ】関連サービス

【プロセス・アーキテクチャ】実開発への適用支援

【プロセス・アーキテクチャ】プロセス診断サービス

既存のプロセスを調査し、As-Isプロセスを表現したPFDを作成します。別途、ヒアリングにより得られたTo-Beプロセスを表現したPFDを作成し、As-Isプロセスの課題とその解決方法を提示します。

【プロセス・アーキテクチャ】プロセス・アーキテクチャ導入支援

プロセス・アーキテクチャを導入するための教育やサンプルづくり、レビュー等を組合せ、プロジェクトや組織にフィットするプロセスにしていくための支援をします。

【プロセス・アーキテクチャ】サービスに関するお問い合わせ

【プロセス・アーキテクチャ】pagetop

  • solutuin of eXmotion menu | エクスモーションのおすすめするソリューション
  • 組込みソフトウェア開発の現場を支えるソリューション
  • MATLAB / SimulinkモデリングによるMBDモデルベース開発(オートモーティブソリューション)
  • 「機能安全」規格「ISO26262」に基づいた「機能安全」ソリューション
  • システムアーキテクチャ設計には全体最適な視点が必要
  • 「USDM」による「要件定義」と「要求仕様化」
  • 既存資産の解説書
  • レガシー救済プロジェクト
  • 「レガシーシステム」の可視化
  • レガシーリファクタリング
  • プロセスアーキテクチャ
  • 「派生開発」に特化したプロセス「XDDP」導入支援
  • MBDモデルベース開発(UML+オブジェクト指向モデリング)
  • プロダクトライン開発(SPL)
  • ソリューションカタログダウンロード