Comments
Description
Transcript
AllFusion Process Modeler 手法ガイド
AllFusion Process Modeler ® 手法ガイド r7 本書及び関連するソフトウェア プログラム（以下「本書」）は、お客様への情報提供のみを目的とし、Computer Associates International, Inc.（以下「CA」）は本書の内容を予告なく変更、撤回することがあります。 CA の事前の書面による承諾を受けずに本書の全部または一部を複写、譲渡、変更、開示、複製することはでき ません。本書は、CA が知的財産権を有する専有の情報であり、アメリカ合衆国及び日本国の著作権法並びに 国際条約により保護されています。 上記にかかわらず、社内で使用する場合に限り、ライセンスを受けるユーザは本書の、合理的な範囲内の部数 のコピーを作成できます。ただし CA のすべての著作権表示およびその説明を各コピーに添付することを条件と します。ユーザの認可を受け、本ソフトウェアのライセンスに記述されている守秘条項を遵守する、従業員、法律 顧問、および代理人のみがかかるコピーを利用することを許可されます。 本書のコピーを作成する上記の権利は、本製品に対するライセンスが完全に有効となっている期間内に限定さ れます。いかなる理由であれ、そのライセンスが終了した場合には、ユーザは CA に複製したコピーを返却する か、あるいは複製したコピーを破棄したことを文書で証明する責任を負います。 準拠法により認められる限り、CA は本書を現状有姿のまま提供し、商品性、特定の使用目的に対する適合性、 他者の権利に対する不侵害についての黙示の保証を含むいかなる保証もしません。また、本書の使用が直接ま たは間接に起因し、逸失利益、業務の中断、営業権の喪失、業務情報の損失等いかなる損害が発生しても、CA は使用者または第三者に対し責任を負いません。CA がかかる損害について明示に通告されていた場合も同様 とします。 本書及び本書に記載された製品は、該当するエンドユーザ ライセンス契約書に従い使用されるものです。 本書の制作者は Computer Associates International, Inc. です。 本 書 は 、 48 C.F.R.Section 12.212 、 48 C.F.R. Section 52.227-19(c)(1) 及 び (2) 、 ま た は 、 DFARS Section252.227.7013(c)(1)(ii)、または、これらの後継の条項に規定される「制限された権利」のもとで提供されます。 © 2005 Computer Associates International, Inc. 本書に記載された全ての製品名、サービス名、商号およびロゴは各社のそれぞれの商標またはサービスマーク です。 目次 第 1 章: アクティビティとプロセス モデリングの紹介 AllFusion PM 手法ガイドについて ....................................................................................................................1-1 対象となるユーザ.........................................................................................................................................1-1 アクティビティおよひプロセス モデル.................................................................................................................1-2 アクティビティ モデリング テクニック ...................................................................................................................1-4 構造化分析設計..........................................................................................................................................1-5 アクティビティ モデリングおよひビジネス システム エンジニアリング ................................................................1-5 第 2 章: IDEF3 プロセス記述獲得手法 IDEF3 モデルの構文およひセマンティクス .......................................................................................................2-2 IDEF3 モデル ..............................................................................................................................................2-2 ダイアグラム .................................................................................................................................................2-2 作業単位（UOW:Unit of Work）/アクティビティ ..........................................................................................2-3 リンク.............................................................................................................................................................2-4 ジャンクション ...............................................................................................................................................2-8 レフェラント .................................................................................................................................................2-14 アクティビティの分解..................................................................................................................................2-15 IDEF3 プロセス記述獲得の構築......................................................................................................................2-16 シナリオ、スコープ、およびビューポイントの定義.....................................................................................2-16 アクティビティとオブジェクトの定義 ...........................................................................................................2-16 順序付けおよび同時並行性 .....................................................................................................................2-17 アクティビティ、ジャンクション、およびオブジェクトの詳細ドキュメント .....................................................2-17 目次–iii 第 3 章: IDEF0 機能モデリング手法 IDEF0 の概要..................................................................................................................................................... 3-1 IDEF0 モデル構文およびセマンティクス........................................................................................................... 3-2 IDEF0 モデル.............................................................................................................................................. 3-2 アクティビティ............................................................................................................................................... 3-3 境界およびインタフェース（矢印）............................................................................................................... 3-4 トンネル...................................................................................................................................................... 3-12 アクティビティおよびアクティベーション.................................................................................................... 3-13 IDEF0 アクティベーションを説明するための IDEF3 モデルの作成............................................................... 3-14 IDEF0 モデルの構築 ....................................................................................................................................... 3-15 ダイアグラム............................................................................................................................................... 3-15 作成者と読者のサイクル ........................................................................................................................... 3-17 モデルの構築............................................................................................................................................ 3-18 ビューポイント ............................................................................................................................................ 3-18 スコープ ..................................................................................................................................................... 3-19 システムの命名（アクティビティ） ............................................................................................................... 3-19 主な ICOM の定義 ................................................................................................................................... 3-20 アクティビティとダイアグラムの番号付け .................................................................................................. 3-21 ダイアグラムから親アクティビティへのリレーションシップ（境界および階層）.......................................... 3-21 幅優先モデリングと深度優先モデリング .................................................................................................. 3-22 終了時点の判断........................................................................................................................................ 3-22 その他の IDEF0 ダイアグラム ................................................................................................................... 3-22 第 4 章: データ フロー ダイアグラム 概要 .................................................................................................................................................................... 4-1 DFD モデルの構文およびセマンティクス.......................................................................................................... 4-2 アクティビティ............................................................................................................................................... 4-2 外部エンティティ.......................................................................................................................................... 4-3 矢印（データ フロー）................................................................................................................................... 4-3 データ ストア................................................................................................................................................ 4-4 分岐と結合 .................................................................................................................................................. 4-4 DFD の構築........................................................................................................................................................ 4-5 オブジェクトの番号付け .............................................................................................................................. 4-6 目次–iv AllFusion Process Modeler 手法ガイド 第 5 章: アクティビティ べースの原価計算およびパフォーマンス メトリクス アクティビティ ベースの原価計算.......................................................................................................................5-1 アクティビティ べースの原価モデル............................................................................................................5-1 シミュレーション...................................................................................................................................................5-3 ソースと宛先.................................................................................................................................................5-4 キュー ...........................................................................................................................................................5-4 ファシリティ ...................................................................................................................................................5-4 シミュレーションの例 ....................................................................................................................................5-5 シミュレーション実験の管理 ......................................................................................................................5-11 第 6 章: アクティビティ モデルとデータ モデルの統合 データ モデリングの概要....................................................................................................................................6-1 エンティティと属性 .......................................................................................................................................6-1 リレーションシップ ........................................................................................................................................6-2 カーディナリティ ...........................................................................................................................................6-3 識別リレーションシップと非識別リレーションシップ ....................................................................................6-4 オプション リレーションシップ ......................................................................................................................6-5 カテゴリ.........................................................................................................................................................6-6 データの用途......................................................................................................................................................6-7 矢印のルール ..............................................................................................................................................6-7 エンティティと属性のルール........................................................................................................................6-8 統合プロセス .....................................................................................................................................................6-10 用語集 索引 目次–v Chapter 1 アクティビティとプロセス モデリングの 紹介 AllFusion® Process Modeler（以降、AllFusion PMと表記します）によるプロセス モデ リングにようこそ。 AllFusion PM 手法ガイドについて 本書、手法ガイドでは、アクティビティおよびプロセス モデリングについて簡単に説 明し、AllFusion PM でサポートされている、3 つのアクティビティ モデリング テクニッ ク - IDEF3（プロセス記述獲得手法）、IDEF0（機能モデリング手法）、およびデータ フロー ダイアグラム（DFD） - について紹介します。 アクティビティをモデリングすると、システムの重要なアクティビティ同士のリレーショ ンシップを理解するために役立ちます。本書のアクティビティ モデリング テクニック の説明では、常に、単純なボックスと矢印の構文を使用します。ビジネス プロフェッ ショナルは、最小限のトレーニングを受けることで、アクティビティ モデルについて 学び、検討することができます。 アクティビティ モデルを作成するには、ほかのどのような伝達形態の場合でも同じで すが、忍耐とスキルとが必要です。経験を積むことがとても重要ですし、慣れないう ちに行うアクティビティ分析プロジェクトや予測は、控えめなものにする必要がありま す。それでも、まだ目に見えない重要な対象について人に伝達するための王道は、 努力を継続することです。行動しましょう。 対象となるユーザ 本書の主要な対象ユーザは、ビジネス戦略をサポートするためのプログラムおよび アクティビティの開発を担当される方です。これらのアクティビティを自動化するため のコンピュータ システムの開発者から、これらのアクティビティを正常に実行するた めの担当者までを含みます。 アクティビティとプロセス モデリングの紹介 1–1 アクティビティおよびプロセス モデル アクティビティおよびプロセス モデル どの会社でも、複雑に絡み合ったビジネス機能つまり、アクティビティおよびビジネ ス プロセスによって原料を最終製品に変換します。会社が成功するかどうかは、適 切なアクティビティを特定し、設計し、実行する能力が競争相手よりも優れているか どうかに大きく依存します。したがって、アクティビティは、組織の核心です。 アクティビティおよびプロセスを言葉で説明すると、通常、長くて複雑な文章になり、 理解しにくくなります。しかし、会社で行うアクティビティをよく理解しないと、新しいア クティビティを効果的に設計したり、既存のアクティビティを理解したりできません。 正確な形式でアクティビティを記述し、余分な情報を排除して、重要な情報の明確 化と組織化を行うためにはテクニックが必要です。これによって、アクティビティを効 果的に分析、設計、および実装できます。 アクティビティおよびプロセス モデル（または、単にアクティビティ モデル）では、構 文を使用し、厳密なモデル開発プロセスを適用することによって、情報のフィルタリ ングと構造化を行います。アクティビティ モデルは、会話型言語をフィルタリングお よび構造化するための、洗練された公開形式と組み合わされた、拡張された形式の 句読法であると考えることができます。 アクティビティ モデルでは、システムをアクティビティのコレクションとして扱います。 システム内の各アクティビティによって、オブジェクトまたはオブジェクトのコレクショ ンが変換されます。アクティビティ モデルでは、ボックスなど専用のグラフィックで表 現することによって、アクティビティを強調します。アクティビティには、通常、アクティ ビティで実行する内容を示す動詞または動詞と直接目的語のラベルが添付され ます。 次の図に示すように、ラベル付きのボックスはアクティビティを表します。 アクティビティと、ほかのアクティビティを含む、そのアクティビティの環境とのインタ フェースは、矢印を使用して記述します。アクティビティの概念は、これから議論す る各種モデリング テクニック同士で比較的似ていますが、矢印の意味や、ボックスと 矢印の接続の意味は、モデリング テクニックごとに異なります。 1–2 AllFusion Process Modeler 手法ガイド アクティビティおよびプロセス モデル 前の図で、矢印は、インタフェースによる環境とのアクティビティを表します。プレゼ ンテーションで使用するスライドの場合同様、アクティビティ モデル ダイアグラムで は、同時に公開する詳細情報のレベルを制御します。モデルをダイアグラムに分割 して、サブジェクトの詳細を段階を追って公開することにより、対象となるユーザがそ のダイアグラムを理解するための「明確さ」と、そのダイアグラムに関連する情報すべ てを確実に含めるための「スコープ」とをうまく両立できます。 前の図でアクティビティ ボックスは、システムの境界を表します。このボックスを詳細 に見ると、ボックスの内部を見ることになり、ほかのボックスが見えます。これらのボッ クスには、さらに、それぞれ 子 ボックスがある場合があります次の図に、アクティビ ティの階層リレーションシップをグラフィカルに示します。 アクティビティとプロセス モデリングの紹介 1–3 アクティビティ モデリング テクニック 次の図では、さらに階層表示形式を省略し、アクティビティ階層の一部分を概略形 式で示します。 アクティビティ階層 Quill ビジネスを運営する 生産計画を立てる コンポーネントの在庫を管理する 生産のスケジュール調整を行う 期限切れのコンポーネント部品を廃棄する 製品を組み立てる マザーボードを装着する 組み立てる 構成する 最終テストを実行する トラブルシューティングと修理を行う 出荷用の注文を準備する アクティビティ モデリング テクニック 本書では、機能モデリング手法 IDEF0、プロセス記述獲得手法 IDEF3、および データ フロー ダイアグラム (DFD)の 3 つのアクティビティ モデリングテクニックにつ いて説明します。 IDEF0 は、元々、構造化設計技法（SADT®）と呼ばれ、1960 年代後半にマシンと人 間との比較的複雑なシステムで用いる工学領域として、SofTech, Inc.によって開発 さ れま し た。1970 年 代後半に 、米 国空 軍がICAM（ Integrated Computer-Aided Manufacturing）プログラムの一部としてSADTの大部分を採用すると（この課程で IDEF0 と命名）、このテクニックは、米国国務省（DoD: Department of Defense）にお けるアクティビティ モデリング テクニックの標準として急速に広まりました。 1993 年、IDEF ユーザ グループ（現在の SEE： Society of Enterprise Engineering） が、NIST（National Institutes of Standards and Technology）と共に、米国政府および 同盟国のすべての民生部門および軍事部門で使用する IDEF0 標準文書の作成を 引 き 継 ぎ ま し た 。 こ の 標 準 は 、 連 邦 情 報 処 理 標 準 （ FiPS:Federal Information Processing Standards）の 183 号として発行されています。 使用する原理が多少異なるものの、大部分共通する DFD テクニックは、ソフトウェ ア開発プロジェクトでの構造化設計（および後には構造化分析）のテクニックとして 普及してきました。データ フロー ダイアグラムは、さまざまな面で IDEF0 モデルに 似ており、IDEF0 分析モデルに続く、詳細設計モデリングに使用できます。 IDEF3 は、米国空軍アームストロング研究所の資金を受けたプロジェクト専用に開 発されました。IDEF3 は、問題の専門家によるプロセス記述を記録するためおよび、 アクティビティの順序と同時並行性が重要な場面でのプロセス モデルを設計するた めのテクニックです。IDEF3 は、FiPS に採用されていません。また、FiPS で IDEF3 に関する議論も行われていません。しかし、IDEF3 は、IDEF0 アクティビティ モデリ ングを補うプロセス モデリングとして米国防総省で広く使用されています。 1–4 AllFusion Process Modeler 手法ガイド アクティビティ モデリングおよびビジネス システム エンジニアリング 構造化分析設計 システムの分析および設計に使用する、一種の形式的方法（プロセス）を構造化分 析設計と呼びます。構造化分析プロジェクトを使用しないでアクティビティ モデルを 開発することは可能ですが、アクティビティ モデルを構築する場合の通常の文脈を 理解することは重要です。構造化分析では、アクティビティ モデルのほかに情報モ デルも使用します。情報モデルでは、データおよび状態遷移図（STD）をモデル化 します。状態遷移図では、システムの時間依存の動作をモデル化します。 構造化分析設計では、最適なソリューションを設計するために、現在のシステムを 徹底的に分析する必要があるとされています。このプロセスの中で、大量のデータ を収集し、分析します。情報を収集するためには、調査対象のシステムに関する知 識を豊富に持つドメイン エキスパートに対して、アナリストが面談する方法が従来か ら行われています。その後、ドメイン エキスパートは、アクティビティ モデルを構築 することを学び、ドメイン エキスパートから聞き取った情報をより正確に記録するた めに IDEF3 などの新しいアクティビティ モデリング テクニックが開発されました。し かし、構造化分析設計においてアナリストが中心的な役割を演じることにほとんど変 わりはありません。 通常はまず、現在の状況を表すモデル（AS-IS モデル）を開発します。その後、この モデルを使用して、設計モデル（TO-BE モデル）を開発します。AS-IS モデルは、 提案された設計によって、実際に改善されるかどうかを確認するために TO-BE モ デルと比較するためのベンチマーク としても使用します。 TO-BE モデルは、提案されたシステムを設計するための指針としてのほかに、容量 計画、予算計画、およびリソース収集のためにも使用します。プロジェクト実装計画 を立てるためにも、両モデルを使用します。プロジェクト実装計画では、AS-IS 状況 から TO-BE 状況にシステムを変換する方法を指定します。 AS-IS モデルを開発するかどうかは、その利益と開発に費やすコストおよび時間とを 比較して決定する必要があります。ビジネス文献は、問題点を解決するために構築 中のシステムの例で一杯です。このような問題点の明確化には AS-IS モデルが役 立ちます。一方、コンピュータ システムの構築時によくあるように、問題全般がよく理 解されている場合、AS-IS モデルを作成するコスト効果はわかりにくくなります。 アクティビティ モデリングおよびビジネス システム エンジニアリング 企業の戦略はアクティビティによって実装されるため、アクティビティ モデリングはビ ジネス システム エンジニアリングにおける、重要なコンポーネントです。アクティビ ティを実行することによって、最終的には特定の戦略の成否が決まり、会社の成否 が決まります。 経営戦略は、企業の長期にわたる広範な将来像を示すことによって、市場という荒 れ狂う海で企業の舵をとるための羅針盤であると考えることができます。戦略はアク ティビティによって実装されます。したがって、アクティビティ モデルは、企業のロー ド マップとして機能し、将来像を実現するためにその局面で企業が取る行動を決定 するために役立ちます。 アクティビティとプロセス モデリングの紹介 1–5 アクティビティ モデリングおよびビジネス システム エンジニアリング 簡単に言えば、経営戦略では、4 つの主な分野をカバーします。 ■ 企業が業務の対象とする市場セグメント。 ■ この市場セグメントに企業が投入する製品およびサービス。 ■ この市場セグメントにアクセスするために使用する、販売チャネルおよびマーケ ティング チャネル。 ■ 戦略を実行するための企業のアクティビティおよびプロセス。 企業が業務の対象とする市場セグメントによって、ほかの問題の軽重が決まるため、 市場セグメントを決めることが最も重要です。市場の正確で最終的なリストは、戦略 の策定を通じて変化しますが、対象とする市場を大幅に変更すると、ほかの重要な 決定事項が無効になってしまう場合があります。 これらの市場を対象とするための一般的な戦略には、コスト リーダーシップ、差別化 価値、および市場スコープの 3 つの側面があります。企業は、対象のセグメントに、 最も安価に提供し、製造工程の効率化によって利益を得ることで、コスト リーダとし て生き残ることができます。2 つ目のアプローチは、コストを考えず、最高の価値を 対象の市場に提供することによって実現されます。両方のアプローチを組み合わせ ることもできます。企業は、小さなすきま市場のみに的を絞ったり、絞り込んだ戦略 で複数のすきま市場を対象としたり、共通の戦略で幅広い市場を対象とすることも できます。 対象の市場に直接到達できない場合は、チャネル、つまり仲介業者を使用します。 仲介業者は、地理的な近さなどによって、対象のセグメントによりよくアクセスできま す。市場セグメントが異なれば、必要な再販業者の種類も異なります。企業は、市 場にメッセージを伝えるためにも、さまざまなチャネルを使用します。 企業は、戦略を実現するために実行するアクティビティを、特定および設計する必 要があります。戦略開発のこの重大な手順の中で、アクティビティ モデルは不可欠 な役割を果たします。アクティビティは、企業の目的に合うように設計する必要があり ます。また、予想される価値とコストとを比較する必要があります。アクティビティのコ ストなど、アクティビティおよびプロセスの設計時に判明した内容によって、ほかの戦 略決定が変更されることがよくあります。 たとえば、特定の対象セグメントの顧客が、ある製品を使用するためには、広範なト レーニングが必要な場合があります。このとき、適切なトレーニング プログラムを開 発するための充分なコストを顧客に転嫁できない場合があります。このような状況が あれば、その市場セグメントでの企業の戦略に大いに影響します。 戦略の開発と実装は、それ自体、分析と設計の対象となるプロセスです。自社の戦 略に新しい活力をより効率的に与え、新しい機会に投資し、新しい競争の脅威に対 抗することができる企業は、長期にわたって競争優位を維持する可能性を高めるこ とができます。 1–6 AllFusion Process Modeler 手法ガイド アクティビティ モデリングおよびビジネス システム エンジニアリング 競合戦略の継続的な見直しと再活性化とを行わない企業は、やがて競争で遅れを 取っていることに気づくことになります。これは、1980 年代に米国企業で起きたこと です。この時期に、「リエンジニアリング革命（Reengineering the Corporation）」の著 者であり、企業管理の権威である Michael Hammer と James Champy は、企業に改 革、現在の商慣行の廃棄、および新しい商慣行の作成の必要性を説き始めました。 ビジネス プロセス リエンジニアリングは、既存の戦略を廃棄し、前述のようにアクティ ビティ モデリングを使用するための、戦略開発および実装のプロセスです。 ビジネス アクティビティをサポートするために、コンピューティング技術への依存が 高まるにつれて、多様化する業務ユーザおよびコンピュータ システム専門家の間で、 アクティビティに関する情報をやり取りする必要性も増しています。コンピュータ シス テムの専門家が、正しく機能するソフトウェアを予算の範囲内で継続的に供給でき ない場合を、通常、「ソフトウェア クライシス」といい、主に 4 つの根本原因が組み合 わさって発生します。 ■ 指定のシステム要件を満たせない ■ システム設計が不充分または不正確 ■ システム パフォーマンスが不充分 ■ 人間とシステムのインタフェースを適切に使用できない ソフトウェア開発を正しく行うためには、コンピュータ システムでサポートするアクティ ビティとプロセスを完全に理解することが非常に重要です。コンピュータ システムが 社会に普及するにつれて、ソフトウェア クライシスが起きた場合のコストが上がりま す。情報技術を業務の必要に合わせてよりよく調整することは、会社経営者にとっ ての最優先事項なのです。 アクティビティとプロセス モデリングの紹介 1–7 Chapter 2 IDEF3 プロセス記述獲得手法 IDEF3 は、プロセス記述獲得手法です。IDEF3 の主な目的は、順序付けした一連 のイベントおよび関連する任意のオブジェクトで、ドメイン エキスパートが状況を記 述できる、構造化手法を規定することです。 IDEF3 は、構造化分析設計の一部としてデータを収集するために適した技術です。 一部のプロセス モデリング テクニックと異なり、IDEF3 では、厳密な構文やセマン ティクスによって、不完全なシステム説明や一貫性のないシステム説明の捕捉が停 止されることはありません。モデルの作成者（アナリスト）が、プロセス記述のギャップ を埋めるために、ドメイン エキスパートによる前提条件とともに、独自の前提条件を 随所に設定する必要もありません。図 2-1 に、IDEF3 によるプロセス記述の例を示しま す。 図 2-1 IDEF3 のプロセス記述 IDEF3 は、プロセス設計手法としても使用できます。IDEF3 モデリングは、IDEF0 モ デリングの補足となります。IDEF3 モデリングは、シミュレーションによって高度な分 析を行うための設計モデルを構築する有望な方法として、しだいに受け入れられて きています。シミュレーションは、通常、設計中のシステムのパフォーマンスを判定 するために使用されます。シミュレーションについては、「アクティビティ ベースの原 価計算およびパフォーマンス メトリクス」の章で説明します。 IDEF3 プロセス記述獲得手法 2–1 IDEF3 モデルの構文およびセマンティクス IDEF3 モデルの構文およびセマンティクス このセクションでは、IDEF3 モデルの構文およびセマンティクスについて説明します。 IDEF3 モデル IDEF3 モデルは、ビジネス シナリオをベースにして構築します。ビジネス シナリオ によって、アクティビティつまり指定の設定でのプロセスの順序がおおよそ決まりま す。シナリオではモデルの目的とスコープとを記述しますので、メイン アクティビティ には、動詞、動名詞（ing で終わる動詞）、または動詞と直接目的語（動詞句）で、適 切な名前を付けることが重要です。たとえば、「Process Customer Order（顧客の注 文を処理する）」、「Implement New Design（新しい設計を実装する）」、「Develop Customer Response Profile（顧客応答プロフィールを整備する）」などをシナリオ名と します。 モデルのビューポイントは、文書化する必要があります。通常は、プロセス記述を行 う担当者の役割または肩書きを記述します。 モデルの目的（モデルで解こうとしている質問の内容）、スコープ（何をモデルに包 含し、何をモデルから除外するのか）、およびユーザ（モデルの構築で対象とする ユーザ）を理解することも大切です。 その後に、IDEF3 モデルのビジネス プロセスを定義する、オブジェクトの説明、構 文、およびセマンティクスを続けます。 ダイアグラム 本書で説明するほかの各アクティビティ モデリング テクニック同様、 ダイアグラムは IDEF3 モデルの基本編成ユニットです。モデルをほかのユーザに公開する場合、ま たはほかのユーザがモデルを参照する場合、ほかの多くの設計モデルの場合同様、 IDEF3 モデルでのダイアグラム編成が、いっそう重要になります。この場合、モデル 作成者は、各ダイアグラムに含める情報を把握し、ダイアグラムの読者にとって、そ のダイアグラムが理解しやすく、明快であるようにする必要があります。 2–2 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス 作業単位（UOW:Unit of Work）/アクティビティ すべてのアクティビティ モデリング テクニック同様、作業単位（UOW）とも呼ばれる、 アクティビティは、モデルの中心的なコンポーネントです。IDEF3 ダイアグラムでは、 角が直角なボックスでアクティビティを表します。IDEF3 ダイアグラムでは、動詞また は動詞句（動詞と直接目的語）と固有の ID 番号とでアクティビティを識別します。 動詞句の名詞部、つまり直接目的語は、通常、アクティビティへの主な入力（たとえ ば、「データを収集する（Gather Data）」）、アクティビティの主な出力（たとえば、「本 を書く（Write Book）」）、またはシステムの名前（たとえば、「ビデオ店を運営する （Run Video Store）」）です。モデリング処理の間には、他の名詞のほうが適切になり、 名詞を変更したり、動詞をより正確な動詞に置換する場合があります。アクティビ ティを新規作成すると、固有の番号が割り当てられます。後でアクティビティを削除 しても、番号が再使用されることはありません。 IDEF3 ダイアグラムでは、図 2-2 に示すように、通常、アクティビティ番号の前に、親ア クティビティの番号を表示します。 図 2-2 基本 IDEF3 アクティビティおよび名前の番号付け IDEF3 プロセス記述獲得手法 2–3 IDEF3 モデルの構文およびセマンティクス リンク リンクは、アクティビティ同士の重要な制約リレーションシップを示します。IDEF3 のリ ンクはすべて一方通行です。矢印はアクティビティ ボックスのどの辺からでも開始お よび終了できますが、IDEF3 ダイアグラムでは、通常、左辺から開始し右方向へ伸 ばしますので、リンクは、通常、アクティビティ ボックスの右辺から開始し、左辺で終 了させます。3 種類のリンクを次の表に示します。 グラフィック リンク名 用途 時間的先行 ソース アクティビティは宛先アクティビティの開 始前に完了する必要があります。 オブジェクト フロー ソース アクティビティの出力が、宛先アクティビ ティの入力になります。このことは、宛先アク ティビティを開始する前にソース アクティビティ を完了する必要があることを示します。 リレーショナル ソース アクティビティと宛先アクティビティの間 の制約リレーションシップは、リレーショナル リ ンクの各インスタンスに対するユーザ定義であ る必要があります。 先行リンク 先行リンクは、宛先アクティビティを開始する前にソース アクティビティを完了する必 要があることを示します。先行リンクは、IDEF3 ダイアグラムで、ソース アクティビティ から宛先アクティビティ（トリガされるアクティビティ）を指す矢じりのある矢印で表示さ れます。リンクには、そのリンクが存在する意味をダイアグラムの読者が理解できるよ うに、ラベルを付ける必要があります。通常、1 つのアクティビティが完了すると、もう 1 つのアクティビティのアクティベーションが有効になるか起動されます（図 2-3）。こ の例では、プロジェクト チームの提案を実装する前に、管理者が承認する必要があ ります。 図 2-3 アクティビティ 1.1 とアクティビティ 1.2 の間の先行リンク 2–4 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス オブジェクト フロー リンク アクティビティ間に時間的先行リンクを使用する一般的な理由の 1 つに、ソース アク ティビティで作成されたオブジェクトが、宛先アクティビティで必要な場合があります。 オブジェクト リンクは、矢じりを 2 つ持つことによって、一般的な時間的先行リンクと 区別されます。このリンクには、リンクに沿って移動するオブジェクトをはっきりと識別 できる名前を付ける必要があります。オブジェクト フロー リンクでも、先行リンクと同 じ、時間に関するセマンティクスがあります。つまり、オブジェクト フロー リンクの始 点となるアクティビティは、オブジェクト フロー リンクで指し示すアクティビティを開始 する前に完了する必要があります（図 2-4）。この例では、組み立てられた部品が、 ソース アクティビティで作成されるオブジェクトです。部品は、塗装の前に組み立て る必要があります。 図 2-4 アクティビティ 1.1 とアクティビティ 1.2 の間のオブジェクト フロー リンク リレーショナル リンク リレーショナル リンクは、時間的先行およびオブジェクト フローを意味しない、リレー ションシップを示します。リレーショナル リンク自体による制約がないため、各リレー ショナル リンクでその意味を定義する必要があります。 並列するアクティビティ間のリレーションシップを示すために、リレーショナル リンクを 使用することもできます。図 2-5 は、タイル用またはブロック用ののこぎりのような水 冷式のこぎりを起動するプロセスの一部を示します。「ブレード モータを始動する」と 「水ポンプを始動する」の間に、特別なリレーションシップが示されています。矢印の ラベルを使用すると、リレーションシップの性質を記述できます。もっと詳細な説明 は、補足テキストとして記録できます。 図 2-5 リレーショナル リンク IDEF3 プロセス記述獲得手法 2–5 IDEF3 モデルの構文およびセマンティクス リレーショナル リンクを使用する一般的な場合は、先行リンクの特別なケースです。 これは、アクティビティ同士の代替時間リレーションシップです。次の 2 つの例のうち、 最初の例は通常の時間的先行リンクです。2 番目の例では、時間的先行リンクで示 唆された、最初の例の 2 つのアクティビティの開始時間と終了時間のリレーション シップが、垂直の棒で示されています。この例では、左から右に時間が経過するの に伴って、「プロジェクト チームの推奨を承認する」が終わった後で、「推奨を実行 する」が開始されます。 図 2-6a 時間的先行リンク 図 2-6b 図 2-6a のアクティビティにおけるアクティビティのタイミング 図 2-7a の 2 つのアクティビティ間の代替時間制約を図 2-7b に示します。この例で プロジェクト チームは、「プロジェクト チームの推奨を承認する」が終了する前に、 「推奨を実行する」を開始します。リレーショナル リンクを図 2-7a に示します。 図 2-7a リレーショナル リンク 2–6 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス 図 2-7b 図 2-7a のリレーショナル リンクについての、想定される時間的制約の一例 アクティビティをリレーショナル リンクで接続する場合、時間的制約を明確に文書化 することが重要です。想定される別の時間的制約を図 2-8b に示します。図 2-8a に 示す例に適用した場合、プロジェクト チームは「プロジェクト チームの推奨を承認す る」アクティビティの開始後に「推奨を実行する」を開始しますが、「プロジェクト チー ムの推奨を承認する」が終了する前に、「推奨を実行する」を終了します。 図 2-8a リレーショナル リンク 図 2-8b 図 2-8a のリレーショナル リンクについての、想定される時間的制約の別の一例 図 2-7b と図 2-8b の時間的制約は、いずれも可能ですので、正確な解釈を文書化 する必要があります。ここでいう「正確」とは、より効果的なプロセスにつながるアナリ ストの見解による解釈を意味するのではなく、文書化対象の状況を的確に反映する 解釈を意味することに注意してください。 IDEF3 プロセス記述獲得手法 2–7 IDEF3 モデルの構文およびセマンティクス ジャンクション 1 つのアクティビティが完了すると、ほかの複数のアクティビティが可能になる場合 や、1 つのアクティビティを開始するには、複数のアクティビティが完了するのを待つ 必要のある場合があります。ジャンクションは、プロセス フローを分配または統合し、 プロセス分岐を記述するために使用します。 ■ ■ ファンアウト ジャンクション - プロセス フローを分配します。1 つのアクティビティ の完了が、ほかの複数アクティビティのアクティベーションの原因になります。 ファンイン ジャンクション - プロセス フローを統合します。1 つ以上のアクティビ ティの完了が単一アクティビティのアクティベーションの原因になります。 3 種類のジャンクションの概要を次の表に示します。 グラフィック 名前 関数 アクティベーション ルール AND ジャンクション ファンアウト AND ジャンクションに接続されている すべての宛先アクティビティは、常に アクティベートされます。 ファンイン AND ジャンクションに接続されている すべてのソース アクティビティは、常 に完了する必要があります。 ファンアウト 排他 OR ジャンクションに接続されて いる 1 つのかつ 1 つだけの宛先アク ティビティがアクティベートされます。 ファンイン 排他 OR ジャンクションに接続されて いる 1 つのかつ 1 つだけのソース ア クティビティは完了する必要がありま す。 ファンアウト OR ジャンクションに接続されている 1 つ以上の宛先アクティビティがアク ティベートされます。 ファンイン OR ジャンクションに接続されている 1 つ以上のソース アクティビティは、完 了する必要があります。 排 他 OR ジャンクション OR ジャンクション 2–8 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス ファンイン ジャンクションおよびファンアウト ジャンクションを図 2-9 に示します。 図 2-9 IDEF3 ダ イ ア グ ラ ム に お け る フ ァ ン ア ウ ト ジ ャ ン ク シ ョ ン （ J2 ） お よ び ファンイン ジャンクション（J3） AND ジャンクション AND ジャンクションでは、接続先の各宛先アクティビティが常にアクティベートされ ます。次のアクティビティを開始するには、AND ファンイン ジャンクションに接続さ れているすべてのアクティビティが完了する必要があります。図 2-10 では、「火事を 検知する」が完了すると、「アラーム音が発生する」、「消防署に通知する」、および （AND）、「防火装置が作動する」がアクティベートされます。この 3 つのアクティビ ティが完了すると（かつその場合にのみ）「火事イベントを記録する）」がアクティベー トされます。 図 2-10 AND ジャンクション 排他 OR ジャンクション 排他 OR ファンイン ジャンクションおよびファンアウト ジャンクションに設定されてい るアクティビティは、アクティビティの数に関係なく、1 度に 1 つだけがアクティベート されます。したがって、排他 OR ファンイン ジャンクションに続くアクティビティを開始 する前には、1 つのアクティビティのみが完了します。 IDEF3 プロセス記述獲得手法 2–9 IDEF3 モデルの構文およびセマンティクス ジャンクションのアクティベーションルールがわかっている場合、ジャンクション レ フェラント内のジャンクションの詳細（説明）か、ファンアウト ジャンクションから始まる 矢印にラベルを付けることによって、ルールを記録する必要があります（図 2-11）。 図 2-11 では、排他 OR ジャンクションを使用して、「コース聴講を処理する）」と「履 修コースを処理する」が同時にアクティベートされることがないことを示しています。 学生は、必須科目を受けるか、科目を監査するかのいずれかを行うことができ、両 方はできないため、2 つのアクティビティの 1 つ（のみ）が「学生のステータスをチェッ クする」によってアクティベートされます。 図 2-11 排他 OR ジャンクション OR ジャンクション OR ジャンクションでは、AND（すべて）および排他 OR（1 つのみ）では記述できな いアクティベーションの組み合わせを記述します。リレーショナル リンク同様、OR ジャンクションは､本質的にユーザ定義です。図 2-12 では、OR ジャンクション J2 に よって「小切手を確認する」と「現金払いを勘定する」のいずれかまたは両方がアク ティベートされます。「小切手を確認する」は顧客が窓口係に小切手を渡すとアク ティベートされます。「現金払いを勘定する」は、顧客が窓口係に現金を渡すとアク ティベートされます。顧客が小切手と現金を窓口係に渡すと、両方がアクティベート されます。 図 2-12 OR ジャンクション 2–10 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス 同期ジャンクションおよび非同期ジャンクション AND ジャンクションと OR ジャンクションの例では､ファンアウト ジャンクションによっ てアクティベートされるアクティビティの開始と終了のリレーションシップについて触 れませんでした。これらの例のアクティビティは非同期でした。つまり、同時に開始、 終了する必要がありませんでした。一方、並列するアクティビティの開始または終了 （またはその両方）は同期する必要がある場合があります。つまり、これらのアクティ ビティは同時に起きる必要があります。この動作をモデリングするためには、同期ア クティビティを使用します。同期ジャンクションの適切な解釈を次の表に示します。 グラフィック & O X タイプ ファン 説明 AND フ ァ ン アウト ジャンクションからファンアウトするすべてのアク ティビティを同時に開始します。 AND フ ァ ン イン ジャンクションにファンインするすべてのアクティ ビティを同時に終了します。 OR フ ァ ン アウト ジャンクションからファンアウトする 1 つ以上のア クティビティを同時に開始します。 OR フ ァ ン イン ジャンクションにファンインする 1 つ以上のアク ティビティを同時に終了します。 排他 OR フ ァ ン アウト 排他 OR ファンアウト ジャンクションに接続され ているアクティビティの 1 つのみがアクティベート されるため、他のアクティビティとの同期はありま せん。 排他 OR フ ァ ン イン 排他 OR ファンイン ジャンクションに接続されて いるアクティビティの 1 つのみが完了するため、 他のアクティビティとの同期はありません。 IDEF3 プロセス記述獲得手法 2–11 IDEF3 モデルの構文およびセマンティクス 同期ジャンクションでは、ジャンクション ボックスの中に垂直な棒が 2 本示されます。 非同期ジャンクションの場合、棒は 1 本です。 レース競技の多くでは、通常、スタータがピストルを鳴らすと時計が動き始め、参加 者は同時にレースを始める必要があります。そうでなければ、レースは公平な競技と みなされません。 この例を、同期 AND ジャンクションを使用して図 2-14 に示します。 図 2-14 同期ジャンクション 同期ジャンクションの場合、モデル作成者は、同時性制約の許容範囲を示す必要 があります。許容範囲とは、アクティビティが開始または終了する時間が互いにどの 程度接近しているか必要があるのかを示します。また、同期ファンアウト ジャンクショ ンは、対応するファンイン ジャンクションとペアにする必要はありません。もちろん、 レースの例のように、同時に開始されたアクティビティは、同時に終了するとは限りま せん。ここでの見どころは、明らかに非同期な終了です。アクティビティは非同期に 開始され、同期して終了することもあります。 2–12 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス ジャンクション ペア ダイアグラムでは、ジャンクションをペアにする必要があります。つまり、各ファンアウ ト ジャンクションにはペアになるファンイン ジャンクションが必要です。ただし、ジャ ンクションの種類が同じである必要はありません。図 2-15 では、AND ファンアウト ジャンクションが、OR ファンイン ジャンクションと対応付けられています。AND ジャ ンクション（J1）は、図 2-10 の場合と同じ意味に解釈されます。「火事を検知する）」 が完了すると、「アラーム音が発生する」、「消防署に通知する」、および（AND）、 「防火装置が作動する」がアクティベートされます。OR ジャンクション（J2）は、次のよ うに解釈されます。「アラーム音が発生する」、「消防署に通知する」、「防火装置が 作動する」のいずれかが完了すると、「火事イベントを記録する」がアクティベートされま す。 図 2-15 2 種類のジャンクション組み合わせの例 - AND ファンアウト ジャンクションおよび OR ファンイン ジャンクション ジャンクションの組み合わせ ジャンクションを組み合わせると、より複雑な分岐ルールを作成できます（図 2-16）。 ジャンクションを組み合わせる場合は、文書の目的をはっきりと理解し、そのジャンク ションを組み合わせることによって、ダイアグラムが明確になるのか、わかりにくくなる のかを第一の判断基準として、慎重に行う必要があります。ジャンクションの構造が 複雑な場合、アクティビティ ボックスの中に入れ子できます。 図 2-16 ジャンクションの組み合わせを示す IDEF3 ダイアグラム IDEF3 プロセス記述獲得手法 2–13 IDEF3 モデルの構文およびセマンティクス レフェラント レフェラントは、プロセス記述の別の部分を参照する専用のシンボルです。重要な 部分に読者の関心を向けるためにダイアグラムに追加します。次の表に、レフェラン トの種類の一覧を示します。 レフェラントの種類 用途 オブジェクト アクティビティで使用する重要なオブジェクトを示すために使用 します。 GOTO （必須ではなく）通常は、同じダイアグラムでのループ処理（一連 のアクティビティの繰り返し）を実装する場合に使用します。各ア クティビティがすべて同じダイアグラムに存在する場合、開始アク ティビティに矢印を引くことによってループ処理を記述することも できます。GOTO レフェラントでは、ジャンクションも参照できま す。 UOB（動作の単位） ループ処理なしで、ほかのアクティビティのインスタンスを含める ために使用します。たとえば、「現金払いを勘定する」アクティビ ティが 1 つのプロセスで複数回発生する場合、最初の「現金払い を勘定する」をアクティビティとして作成し、以降では UOB レフェ ラントを記述することができます。自動化されたツールを使用する 場合、通常この種類のレフェラントを使用する必要はありません。 NOTE ダイアグラムにあるグラフィックに関連する重要ではあっても一般 的な情報を記録するために使用します。この点において、NOTE レフェラントは、注釈をテキストでダイアグラムに直接記録する代 わりになります。 ELAB（詳細） グラフィックについて詳しく説明するために使用します。詳細レ フェラントは、通常、ジャンクションの分岐理論を記述するために 使用します。 レフェラントは、アクティビティ同様、ボックスで記述されます。レフェラント名には、通 常、オブジェクト、GOTO など、レフェラントの種類と ID を含めます。オブジェクト レ フェラントを図 2-17 に示します。 図 2-17 オブジェクト レフェラント 2–14 AllFusion Process Modeler 手法ガイド IDEF3 モデルの構文およびセマンティクス 重要なオブジェクト/アクティビティ リレーションシップを図 2-18 に示します。 図 2-18 アクティビティへのオブジェクト レフェラント アクティビティの分解 IDEF3 のアクティビティは、分解して、より詳細を表現できます。IDEF3 手法では、 アクティビティを複数回分解できます。つまりアクティビティは、複数の子を持つこと ができます。これによって、単一のモデルで、複数の代替プロセス フローを記録で きます。 複数分解されたモデルでアクティビティを正しく追跡するには、番号付けスキーマを 拡張して、アクティビティ ID と親アクティビティ ID のほかに、分解番号も含める必要 があります（図 2-19）。 図 2-19 分解番号を含むアクティビティ ID IDEF3 プロセス記述獲得手法 2–15 IDEF3 プロセス記述獲得の構築 IDEF3 プロセス記述獲得の構築 このセクションでは、テキスト ベースのプロセス記述から、IDEF3 ダイアグラムを構築 するプロセスについて説明します。このプロセスには、モデル作成者（通常はアナリ スト）と、プロセス記述の提供元になる、1 人以上の問題の専門家が関わっているも のとします。 シナリオ、スコープ、およびビューポイントの定義 問題の専門家にプロセス記述の用意を頼む前に、目的のシナリオおよびモデルの スコープについて記録し、どの程度まで詳細におよび広く記述する必要があるのか を専門家が理解できるようにする必要があります。その専門家が通常システムに関 わる場合のビューポイントとは異なるビューポイントを使用する場合は、ビューポイン トも明確かつ丁寧に説明する必要があります。 モデル作成者が改まって面接し、専門家に指針を示さないと、専門家が充分な説 明を作成できない場合があります。レポートする専門家が面接に当たって用意する のと同様に、モデル作成者も、一連の質問を用意する必要があります。 アクティビティとオブジェクトの定義 問題の専門家は、通常、対象のシナリオを説明するテキストを口述します。文書が すでに存在し、現在のプロセスを理解するために役立つ場合もあります。記述され た情報であるのか、口述された情報であるのかに関わらず、情報を分析して品詞に 分解し、プロセスを構成するアクティビティ（動詞および動詞句）およびプロセスに関 連するオブジェクト（名詞および名詞句）の候補リストを特定します。このプロセスは 簡単に思えますが、少なくとも英語では、動詞の形を取る形容詞などが存在し落と し穴になります。たとえば「test procedure」の場合、「テスト」は「procedure」を記述す る形容詞（テスト プロシージャ）であるのか、動詞（プロシージャをテストする）である のかが不明です。 問題の専門家が参加している状況で、グラフィック モデルを作成できる場合があり ます。情報収集が終了してからグラフィック モデルを作成すれば、ダイアグラムの書 式設定を行っている間に参加者の集中力が途切れるのを避けることができます。 IDEF3 モデルは、別々のチームが同時に開発できるため、IDEF3 では、すべての モデルでアクティビティに番号付けを行うための簡単なスキーマがサポートされてい ます。各モデル作成者に、異なる範囲のアクティビティ番号が割り当てられ、独立に 作業できます。次の表に示すアクティビティ ID は、各モデル作成者に、大きなブ ロックで割り当てられています。この例で、Tom は、元々割り当てられた番号を使い 果たし、2 つ目のブロックを割り当てられています。 2–16 AllFusion Process Modeler 手法ガイド IDEF3 プロセス記述獲得の構築 モデル作成者 IDEF3 番号の範囲 Tom 1-999 Lynn 1000-1999 Dan 2000-2999 Tom 3000-3999 順序付けおよび同時並行性 面接が終わりダイアグラムを作るとき、モデル作成者は、ダイアグラムの階層、たとえ ば、単一のダイアグラム ページに詳細をいくつ含めるのかなどについて、決定する 必要があります。アクティビティの順序や同時並行性が明確でない場合は、（未完 成のダイアグラムを参照しながら）専門家に再度面接して、足りない情報を補足しま す。ただし、リンクがないことによって示唆される暗黙の同時並行性と、専門家の説 明で明確に示されている明示的な同時平行性とを区別することは大切です。 アクティビティ、ジャンクション、およびオブジェクトの詳細ドキュメント IDEF3 では、さまざまな方法で情報を捕捉できます。たとえば、ジャンクションの組 み合わせを使用して、込み入ったジャンクション ロジックを、グラフィカルに記述でき ます。同じ情報を、詳細レフェラントを使用して捕捉することもでき、ジャンクション定 義の一部として捕捉することまでできます。これによって、モデル作成者は、（専門 家の目の前でダイアグラムを構築している場合など）その時点で最も便利な形式で 情報を捕捉できます。ただし、必要に応じてモデルを再編成し、プレゼンテーション に適した形式にすることが重要です。詳細ジャンクションの組み合わせはダイアグラ ムで広い場所を占め、ジャンクションの階層を使用するとアクティビティの配置が複 雑になるため、プレゼンテーション形式の選択がモデルの編成に大きな影響を与え る場合がよくあります。 IDEF3 は、設計モデルの構築にも使用でき、このため IDEF0 およびデータ フロー モデリングに続く処理で使用できます。IDEF3 設計モデルの構築プロセスについて は、「IDEF0 機能モデリング手法」の章の「IDEF0 アクティベーションを説明するため の IDEF3 モデルの作成」を参照してください。 IDEF3 プロセス記述獲得手法 2–17 Chapter 3 IDEF0 機能モデリング手法 IDEF0 の概要 IDEF0 アクティビティ モデリング は、システム全体を、関連する一連のアクティビ ティまたは機能として分析するためのテクニックです。機能のみに着目する点が重 要です。システムの機能（動詞で表現）は、機能を実行するオブジェクトとは独立に 分析されます。システムの機能のとりまとめを新しく設計するプロセスの中で行うこと は可能ですが、その作業を分析の一部分とすることは不適切であり、場合によって は誤解につながるという考えが背景にあります。機能のみに着目することによって、 意味の問題を、実装の問題から明確に分離できます。 図 3-1 典型的な IDEF0 ダイアグラム IDEF0 は、分析および論理設計に適したテクニックです。したがって、IDEF0 は通 常、プロジェクトの初期段階で使用します。通常は、IDEF0 の前に、IDEF3 モデリン グによってデータを収集し、AS-IS プロセス モデリングを行います。IDEF0 モデリン グを使用する分析では、IDEF3 モデルおよびデータ フロー ダイアグラムを使用した 設計プロセスのアウトプットを入力できます。 IDEF0 機能モデリング手法 3–1 IDEF0 モデル構文およびセマンティクス IDEF0 モデル構文およびセマンティクス このセクションでは、IDEF0 モデル構文およびセマンティクスについて説明します。 IDEF0 モデル IDEF0 では、少数のグラフィック（IDEF0 で使用するシンボルはボックスと矢印の 2 つのみ）を厳密で洗練されたプロセスと組み合わせることによって、最終的なモデル の品質を高めるようにモデルを作成します。 IDEF0 の手順は書籍を出版する場合の手順と、少し似ています。一連の IDEF0 モ デルを印刷してバインダに閉じ、目次、用語集など、書籍に似たコンポーネントを付 けることがよくあります。IDEF0 ではこの手順を「キット」と呼びます。 IDEF0 の最初の手順では、モデルの目的、つまりモデルで答える一連の質問を特 定します。書籍の序文で目的を記述するのと同様に、モデルを記録する過程では、 質問を列挙する必要があります。質問を要約したものである目的の説明を、しばし ば記述します。 モデルのスコープは、詳細情報の幅と深度を意味します。この情報は、書籍の序文 に通常含まれる情報に似ています。回答する質問を一覧にするだけでは不充分で す。モデルの読者、そして実際にモデルを作成する担当者が、回答に要求される 詳細度を理解する必要があります。 想定するユーザも特定する必要があります。どのようなユーザを想定するのかが、モ デルに含めることのできる詳細さのレベルや、モデルに含める必要のある詳細さの レベルに、大きな影響があることがよくあります。質問について何がユーザにとって 既知であるのかを考慮し、ユーザが質問を理解するために必要な背景や技術情報 について考慮し、どの言語およびスタイルが最適であるのかを考慮します。 モデルでシステムを考察する観点をビューポイントと呼びます。選択したスコープを 網羅し、目的を満たすことのできるビューポイントを選択します。いったん選択した ビューポイントは、1 つのモデルで最初から最後まで一貫する必要があります。必要 であれば、別のビューポイントからシステムをモデリングする別のモデルを作成しま す。顧客、納入業者、店舗経営者、編集者などをビューポイントとします。 3–2 AllFusion Process Modeler 手法ガイド IDEF0 モデル構文およびセマンティクス アクティビティ アクティビティは、機能、プロセス、またはインプットをアウトプットに変える変換と呼 ばれることもあります。IDEF0 では、システムを一連の階層化した（入れ子の）アク ティビティとしてモデリングするため、定義する最初のアクティビティはシステム自体 を記述するアクティビティ、つまりコンテキスト アクティビティです。コンテキスト アク ティビティはボックスで記述し、名前を付けます。 IDEF0 でのアクティビティ名は、通常、単一の動作動詞と、モデルのビューポイント からアクティビティの目的を明確化する、一般的な名詞で構成します。名詞をさらに 修飾するために、形容詞を使用することもあります。アクティビティ名は、モデルで指 定されたビューポイントから観察したシステムを、正確に反映することが重要です。 アクティビティ ボックスを図 3-2 に示します。アクティビティは、動詞と直接目的語で 適切に名付けられています。「manufacturing（製造の）」という単語は、「business （ビジネス）」を修飾する形容詞として機能します。 図 3-2 IDEF0 アクティビティ ボックス IDEF0 は、システムを、一連の階層化した（入れ子の）アクティビティとしてモデリン グすると説明しました。アクティビティは、構成アクティビティに分解（分割）できます。 以下の図を参照してください。IDEF0 ではシステムをボックスとして定義するため、 分解は、ボックスの中を覗き込んで、そのボックスがほかのボックスで構成されてい るのを観察することに当たります。分解は通常、トップダウン モデリングであると言わ れますが、これは誤りです。機能の分解は、アウトサイドイン モデリングであると考え たほうが正確です。アウトサイドイン モデリングでは、たまねぎの皮をむいて中身を 参照するように、システムの外側の層をはがすことで内部の詳細を参照します。 IDEF0 機能モデリング手法 3–3 IDEF0 モデル構文およびセマンティクス ノード インデックス形式にした、アクティビティ階層の一部を、以下に示します。 Quill ビジネスを運営する 製品を販売/マーケティングする 広告を行う 注文を受ける 電話に出る 一般的な情報を提供する 価格票を FAX で送信する 注文を記録する クレジットを確認する 注文の処理状況を提供する 価格情報を提供する 文書を作成する 作業伝票を用意する 構成を設計する ベンダおよびコンポーネントを特定する 規格を作成する コンポーネントを指定する 構成をテストする ベンダを承認する 生産計画を立てる コンポーネントの組み立てを依頼する 作業伝票を発行する コンポーネントの在庫を管理する 生産計画を立てる 期限切れのコンポーネント部品を廃棄する 境界およびインタフェース（矢印） 使いやすくするためには、アクティビティの説明を最小限にすると同時に、アクティ ビティで作成するオブジェクトの説明およびアクティビティで使用または変換するオ ブジェクトについての記述を説明に含める必要があります。 IDEF0 では、 コントロール と メカニズム もモデリングします。コントロールとは、イン プットの変換方法を制御するオブジェクトですが、アクティビティによって、それ自体 は変換されないオブジェクトです。メカニズムとは、インプットを実際にアウトプットに 変換するオブジェクトですが、アクティビティによって、それ自体は変換されないオ ブ ジェクトです。 IDEF0 ダイアグラムで捕捉する情報のカテゴリの頭文字が ICOM です。ICOM は、 4 種類の矢印を表します。 ■ I - Input（インプット）。プロセスで消費するものです。 ■ C - Control（コントロール）。 プロセスの実行に対する制約です。 ■ O - Output（アウトプット）。 プロセスの結果です。 ■ 3–4 M - Mechanism（メカニズム）。 プロセスを実行するために使用し、それ自体は 消費されないものです。 AllFusion Process Modeler 手法ガイド IDEF0 モデル構文およびセマンティクス 4 種類の矢印およびその矢印をボックスのどの辺に接続するのかを図 3-3 に示し ます。 図 3-3 IDEF0 アクティビティの各種矢印および矢印を接続する辺 アクティビティが常に動詞または動詞句であるのに対して、矢印は常に名詞です。 矢印は、人間、場所、物、概念、またはイベントを表します。IDEF0 において、矢印 は、一方の端に矢じりのある線で表されます。線には、矢印名のラベルが付けられ ます。アクティビティ同様、矢印も、名前だけでは、読者がそのモデルを理解するた めに不充分です。正確で役に立つモデルを構築するには、各矢印の定義をテキス トにすることが重要です。 インプット矢印 アクティビティで消費または変換し、アウトプットを作成するための物質または情報を インプットと言います。インプット矢印は、常に IDEF0 アクティビティ ボックスの左辺 に入れます。何も変換したり変更したりしないアクティビティが存在するため、 イン プット矢印はオプションです。インプットのないアクティビティの例として「経営陣が意 思決定を行う」があります。この場合、さまざまな要因を分析して決定を下しますが、 どの要因も変換、消費されることがありません。 コントロール矢印 アクティビティを実行する方法、タイミング、および条件や、作成されるアウトプットを コントロールによって管理します。コントロールによって、アクティビティの実施が制 御され、目的のアウトプットが作成されるため、各アクティビティには、コントロール矢 印が 1 つ以上必要です。コントロール矢印は常に IDEF0 アクティビティ ボックスの 上辺から入れます。 コントロールは通常、ルール、規制、ポリシー、手順、標準などの形をとります。コント ロールは、実際に変換されたり、消費されたりしないで、アクティビティに影響します。 ルール、規制、ポリシー、手順、または標準を変更することがアクティビティの目的で ある場合があります。この場合、変更対象のルールなどの情報を含む矢印がイン プットになります。 IDEF0 機能モデリング手法 3–5 IDEF0 モデル構文およびセマンティクス コントロールはアクティビティへのインプットの特別な形です。インプット矢印にすべ きなのかコントロール矢印にすべきなのか不明な場合があります。このときは、はっ きりするまで、コントロール矢印にしておきます。データ モデルとプロセス モデルと を統合すると、はっきりする場合があります。「アクティビティ モデルとデータ モデル の統合」の章を参照してください。 アウトプット矢印 アウトプットとは、アクティビティによって作成される物質または情報です。各アクティ ビティには、アウトプット矢印が 1 つ以上必要です。定義可能なアウトプットが作成さ れないアクティビティをモデリングしてはいけません（モデルに含めるとすれば、少な くとも、詳細説明の候補として扱う必要があります）。 非製造業の場合、アウトプットは通常、アクティビティによって何らかの加工が行わ れたデータです。矢印のラベルの前に修飾語句を付けて、アウトプット データが インプット データとどのように異なるのかを示すことが重要です。たとえば、「Admit Patients（患者を受け付ける）」アクティビティは、インプットとアウトプットの両方が 「patient data set（患者データ セット）」になります。適切に修飾した場合、インプット 矢印は「raw patient data（原患者データ）」、アウトプット矢印は「verified patient data （受付済み患者データ）」のようになります。 メカニズム矢印 メカニズムとは、アクティビティを実行するリソースです。重要な人物や機械、または アクティビティを実行するために必要なエネルギーを提供し、その向きを決める設備 などがメカニズムです。モデルの目的を実現するために不要な場合、アクティビティ でメカニズム矢印を使用する必要はありません。 矢印インタフェースの組み合わせ アウトプットとインプット、アウトプットとコントロール、アウトプットとメカニズム、アウト プットとコントロール フィードバックの 5 つの基本的な矢印インタフェースの組み合 わせがあります。 アウトプット矢印とインプット矢印の組み合わせは、もう 1 つのアクティビティに先行 するアクティビティを表します。図 3-4 で、「リソースを調達する」は「リソースを変換す る」に先行する必要があります。 図 3-4 アウトプット矢印とインプット矢印の組み合わせ 3–6 AllFusion Process Modeler 手法ガイド IDEF0 モデル構文およびセマンティクス アウトプット矢印とコントロール矢印の組み合わせは、アクティビティの優先度を表し ます。この場合、1 方のアクティビティが、他方でインプットをアウトプットに変換する 方法を制御するため、他方に優先します。 図 3-5 では、承認された計画が、提案を 実装するための指針となります。実装することによって提案そのものは変更されませ んので、「承認された計画｣は、「推奨を実行する」に対するコントロール矢印として 記述されています。 図 3-5 アウトプット矢印とコントロール矢印の組み合わせ アウトプット矢印とメカニズム矢印の組み合わせは、一方のアクティビティのアウト プットがもう一方のアクティビティを実行する手段になることを意味します。図 3-6 で は、「部品を組み立てる」前に、部品を一時的に固定する器具（ジグ）を作る必要が あります。 図 3-6 アウトプット矢印とメカニズム矢印の組み合わせ コントロール矢印とインプット フィードバック矢印の組み合わせは、通常、優先度の 低いボックスから優先度の高いボックスに対するフィードバックが存在する場合を表 します。アウトプット矢印とコントロール フィードバック矢印の組み合わせの例を図 37 に示します。フィードバックは、「プロジェクトのパフォーマンス評価」のアウトプット、 つまりプロジェクトのパフォーマンス評価です。プロジェクト パフォーマンスの評価が、 「プロジェクト計画を開発する」アクティビティにフィードバックされます。このプロジェ クトで判明した内容を反映して、将来のプロジェクトをよりよく管理するためです。「プ ロジェクトのパフォーマンス評価」は、「プロジェクト計画を開発する」によって変換さ れないため、「プロジェクト計画を開発する」のコントロール矢印になります。 IDEF0 機能モデリング手法 3–7 IDEF0 モデル構文およびセマンティクス 図 3-7 アウトプット矢印とコントロール フィードバック矢印 アウトプット矢印とインプット フィードバック矢印の組み合わせは、通常、改定サイク ルを記述する場合に使用します。アウトプット矢印とインプット フィードバック矢印の 組み合わせの例を図 3-8 に示します。 図 3-8 アウトプット矢印とインプット フィードバック矢印 廃材を原料として再利用できる場合にもアウトプット矢印とインプット フィードバック 矢印の組み合わせを使用します。この例としては、ビンの製造工程があります。製 造工程で壊れたビンは、そのまま溶かし直して、他のビンとして再作成されます。 分岐と結合 1 つのアクティビティのアウトプットをほかの複数のアクティビティで使用する場合が あります。実際のところ、IDEF0 は、システム内のアクティビティの相互依存を視覚 化するためのツールとして最も役立ちます。IDEF0 では、矢印を、分岐（分割）およ び結合（マージ）できます。矢印の分岐と結合のみを示すダイアグラムの例を図 3-9 に示します。 3–8 AllFusion Process Modeler 手法ガイド IDEF0 モデル構文およびセマンティクス 図 3-9 矢印の分岐または結合のみを示す IDEF0 ダイアグラム 分割または結合された矢印の意味は、結合または分割を行う矢印セグメントに熟考 した名前を付けることによって明確化します。図 3-10 で、「ポリシーと手順」コント ロール矢印は、分割されていますが、名前が変更されていません。「ポリシーと手 順」矢印は分割されて、アクティビティ 2 とアクティビティ 3 の両方を制御します。つ まり、両方のアクティビティでインプットをアウトプットに変換するための指針として「ポ リシーと手順」を使用します。 図 3-10 「ポリシーと手順」はアクティビティ 1 で作成され、アクティビティ 2 および アクティビティ 3 で使用される 図 3-11 では、分岐した矢印のうち一方の名前が変更され、「ポリシーと手順」の一 部のみがアクティビティ 2 で使用されることを示しています。矢印を分割して分岐先 の名前を変更する場合、元の矢印の一部であることを新しい名前に反映する必要 があります。アクティビティの階層が機能の分解を表すように、矢印の分岐は、デー タの分解を表します。 IDEF0 機能モデリング手法 3–9 IDEF0 モデル構文およびセマンティクス 図 3-11 1 つのセグメントのみ名前変更された分岐矢印 データ分解のもう 1 つの例を図 3-12 に示します。IDEF0 ダイアグラムでは、矢印の ラベルと線とのつながりを明確化するために、この例にあるようなジグザグ線をよく使 用します。 図 3-12 3–10 2 つの明確に区別した名前のセグメントに分割された矢印 AllFusion Process Modeler 手法ガイド IDEF0 モデル構文およびセマンティクス 図 3-13 では、アクティビティ 1 とアクティビティ 2 のアウトプットいずれにも「不用材 料」という名前を付けることが示されています。 図 3-13 1 つのみの名前に矢印をマージする例 図 3-14 では、個々のコンポーネントおよび束ねられた結果を明確に特定するラベ ルが各矢印セグメントに付けてあります。 図 3-14 マージする個別の矢印に対する適切なラベル付け コール矢印 現在のモデルをモデルの読者がより理解できるようにするために、ほかのモデルや モデル内のほかのダイアグラムを参照する場合や、それに似た機能を実行する場 合にコール矢印を使用します。たとえば、図 3-15 で、「テストと較正」は、テストと較 正について記述したもう 1 つのモデルの名前です。モデルは、複製するのではなく そのまま参照されます。これをコールと呼びます。コール矢印では、同じモデルにあ るほかのダイアグラム、より正確に言うと、ダイアグラムの親アクティビティを参照先と することができ、ほかのモデルにある個別の子アクティビティを参照先とすることもで きます。この方法によって、異なるデータに対して似た機能を実行する、機能的な 重複を、モデル内で適切に記述できます。 IDEF0 機能モデリング手法 3–11 IDEF0 モデル構文およびセマンティクス 図 3-15 コール矢印 トンネル ダイアグラムでの詳細レベルを制御するには、矢印を束ねます。親ダイアグラムに （表示するほど重要でないため）表示されないこともある矢印であり、ほかの矢印と 束ねられない矢印の場合、システムに向かってその矢印が入ってくること、またはシ ステムから出て行くことを示すためにトンネルが使用されます。たとえば、図 3-16 の 「MRP System（MRP システム）」は、このダイアグラムでの重要なメカニズムですが、 モデルのほかの場所では使用されません。このメカニズム矢印を含めることによって 親ダイアグラムが見づらくなる場合、代わりにトンネルを使用します。 図 3-16 メカニズム矢印 MRP System のトンネルの例 親アクティビティに向かう矢印や親アクティビティから出る矢印にトンネルを使用する こともできます。この場合、矢印と子アクティビティとのリレーションシップが定義され ていないことを示します。図 3-17 のトンネルは、「プロシージャ」矢印が、「構成を設 計する」の分解でも「生産計画を立てる」の分解でも、詳細化されていないことを示 します。 3–12 AllFusion Process Modeler 手法ガイド IDEF0 モデル構文およびセマンティクス 図 3-17 「構成を設計する」および「生産計画を立てる」でのプロシージャ矢印のトンネル アクティビティおよびアクティベーション ドリルで穴を開け、旋盤で加工し、えぐり出しを行い、押し抜きを行う工程がある場合、 毎回の機械操作でこれらすべてを行うことは通常ありません。通常は、このアクティ ビティの一部を実行します。たとえば、木材は通常ねじで組み立て、金属はボルト やびょうで取り付けますので、ドリルで穴を開ける処理は木材の場合と金属の場合と で異なります。ねじ穴は、ねじ頭を木材に埋め込むために、通常、皿型になってい ます。ボルトが皿型であることはまれです。モデルを分解すると、ドリルで穴を開ける アクティビティや、ボルトで留めるアクティビティなど、個別のアクティビティを作成で きます。代わりに、これらのアクティビティを別々の IDEF3 モデルとして作成すること もできます。別々にすると、シミュレーションによって、ドリルで穴を開ける、ボルトで 留めるなどのアクティビティを評価する場合、特に便利です。 上記 2 つの方法に代わる簡単な方法として、アクティベーション テーブルがありま す。このテーブルには、各アクティビティのアクティベーションに対応する、さまざま なインプット、コントロール、アウトプット、およびメカニズムの組み合わせを記述でき ます。アクティベーションは、インプットとコントロールの値およびリソース要件に固有 の構成をいいます。アクティベーション テーブルの例を以下に示します。各アクティ ベーションには、そのアクティビティで一意な名前が付けてあり、各種矢印の値が示 してあります。矢印の値の組み合わせは、アクティベーションごとに一意である必要 があります。つまり、2 つのアクティベーションで、どの矢印についても同じ値を持つ ことはできません。 アクティベーション名 多額の現金 少額の現金 矢印名 矢印の値 現金 >$500 現金計数機 必ず 1 現金 <$500 現金計数機 必ず 0 前記の表のアクティベーション情報では、このアクティビティのコントロール矢印の内 容が明確ではありません。たとえば、この銀行は、$500 を超える額の現金の場合に 現金計数機を使用する必要があるというポリシーを持っていると考えることもでき ます。 IDEF0 機能モデリング手法 3–13 IDEF0 アクティベーションを説明するための IDEF3 モデルの作成 IDEF0 アクティベーションを説明するための IDEF3 モデルの作成 IDEF3 モデルを IDEF0 モデルから構築すると、リーフレベル アクティベーションを 記述できます。リーフレベル アクティベーションとは、分解されていないアクティビ ティ、つまり、子アクティビティを持たないアクティビティです。この方法で IDEF0 モ デルを使用する場合、作成者は、各アクティビティのインタフェースのアクティベー ションを入念に文書化する必要があります。「預金口座を処理する」アクティビティ の、さまざまなアクティベーションを次の表に示します。代わりに、複数の IDEF3 モ デルを構築し、アクティベーション モデルを派生させることもできます。 アクティベーション名 小切手のみ 現金のみ 矢印名 矢印の値 入金 =$0.00 小切手 >$0.00 預け入れ =小切手の合計-返金 返金 なし 現金引き出し =返金 現金計数機 必ず 0 窓口係 必ず 1 入金 >$0.00 小切手 =$0.00 預け入れ =現金合計-返金 返金 なし 現金引き出し =返金 現金計数機 入金が$500 を越える場合、必ず 1 その他の場合、必ず 0 現金および小切手 現金および小切手 窓口係 必ず 1 入金 >$0.00 小切手 >$0.00 預け入れ =小切手合計+現金合計-返金 返金 なし 現金引き出し =返金 現金計数機 入金が$500 を越える場合、必ず 1 その他の場合、必ず 0 窓口係 3–14 AllFusion Process Modeler 手法ガイド 必ず 1 IDEF0 モデルの構築 IDEF0 モデルの構築 このセクションでは、モデル構築プロセスについて、より詳細に定義します。 ダイアグラム 図 3-18 に、境界を含めて典型的な IDEF0 ダイアグラムを示します。境界は、はっき りしたヘッダとフッタで構成されています。上にある境界要素（ヘッダ）は、作成中モ デルの進行状況を確認するために使用します。下にある境界要素には、ダイアグラ ムの ID と系図が示されます。 図 3-18 典型的な IDEF0 ダイアグラムおよび境界領域 IDEF0 機能モデリング手法 3–15 IDEF0 モデルの構築 次の表に上側の境界要素（ヘッダ）の内容を示します。 フィールド 3–16 用途 使用場所 従来、コール矢印によってこのダイアグラム（より正確には親 のボックス）が呼び出されているすべての場所を記述するため に使用されています。 作成者、日付、および プロジェクト ダイアグラムの作成者、作成日付、およびダイアグラムが作成 されたプロジェクトのタイトルを記述します。プロジェクトのタイ トルは、プロジェクト内でダイアグラムを追跡するために使用し ます。改定日は、ダイアグラムの最終変更日です。 ノート 1 2 3 4 5 6 7 8 9 10 ダイアグラムを手動で編集する場合、モデルの読者は新しい ノートをダイアグラムに加えるたびに、線を引いて番号を消し ます。 ステータス ステータスは、このダイアグラムの承認状況を示します。レ ビューと承認の手順を踏んで、正式な発行プロセスを実施す る場合に、このフィールドを使用します。 作業中 新規ダイアグラム、大きな変更、または既存ダイアグラムの作 成者（編集者）の変更のいずれかを示します。 ドラフト このダイアグラムが読者達の承認できる一定のレベルに達し たことを示します。審査委員会による審査を受けられる状態で す。 推奨 ダイアグラムおよびダイアグラムのサポート テキストの審査お よび承認が終わったことを示します。以後、変更されることは ないものとみなされます。 発行 ダイアグラムは、最終印刷および発行ができる状態です。 読者 読者達の名前です。 日付 読んだ日付です。 コンテキスト 親ダイアグラムにあるアクティビティ ボックスの関連の概要を、 このダイアグラムの親ボックスを強調表示にして示します。親 ボックスのノード 番号も示します。コンテキスト ダイアグラム （先頭のダイアグラム）のコンテキスト フィールドは「TOP」とし て、モデルでそのダイアグラムに親ダイアグラムがないことを 示す必要があります。 AllFusion Process Modeler 手法ガイド IDEF0 モデルの構築 次の表に下側の境界要素（フッタ）の内容を示します。 フィールド 用途 ノード このダイアグラムのノード番号は、このダイアグラムの親アクティ ビティ ボックスのアクティビティ番号と同じです。 タイトル 親アクティビティ ボックスの名前です。 番号 C-番号とも言います。このバージョンのこのダイアグラムの一意 な ID です。したがって、ダイアグラムのバージョンを新しくするた びに、新しい C-番号を使用します。C-番号は、通常、プロジェク トのモデル作成者間で一意にした作成者のイニシャルおよび連 番になった一意の ID で構成します。たとえば、JDM001 のように なります。C-番号は、同じプロジェクトで再使用しません。 番号 発行時に、C-番号を標準的なページ番号に置き換える場合が あります。ダイアグラムを置き換える場合、通常、置き換え前のダ イアグラムの C-番号をかっこで囲んで JDM002 (JDM001)のよう に、新しいダイアグラムの C-番号に含めます。これによって、モ デルにあるすべてのダイアグラムの完全な改定履歴が提供され ます。 作成者と読者のサイクル 書籍の出版での著者と編集者のサイクル同様、IDEF0 ダイアグラムでは、通常、レ ビューと編集を行って、正確さの検証と品質の向上を行います。 レビューに出せる段階になった作成者は、通常、レビューアごとのキット（フォルダ） を用意します。レビューアは、モデルをレビューし、ダイアグラムまたは関連するテキ ストにコメント（ノート）を追加します。コメントを加えられたダイアグラムが作成者に戻 され、作成者は修正を行います。異論がある場合、グループの意見を一致させるた めに、コメントの加えられたダイアグラムをほかの読者に配布できます。 公式レビューと承認には、ステータス フィールドを使用します。ダイアグラムのバー ジョン管理と履歴管理には番号フィールドを使用します。大規模プロジェクトでは、 通常、ライブラリアンを配置して、プロジェクトの規模に応じた多様なレベルの制御 を行います。 IDEF0 機能モデリング手法 3–17 IDEF0 モデルの構築 モデルの構築 目標や目的を明確にすることなしに、モデルを作成することはできません.目的の記 述では、以下の質問に答える必要があります。 ■ なぜこのプロセスをモデリングするのか。 ■ このモデルで何を表現するのか。 ■ モデルの読者は、モデルによって何ができるか。 目的を記述することによって、モデリング チームは、モデリングの初めから終わりま で集中して作業できます。目的を記述しないと、モデリング セッションがあてどなくさ まようことがあります。 目的は、たとえば次のように記述します「各作業員の仕事を特定し、トレーニング マ ニュアルを作成するために必要な詳細度まで、各仕事の関連を理解する。」 一連の質問に解答するためにモデルを構築します。質問は、前もって作成しておく 必要があり、モデルの目的を記述するための基礎となります。たとえば以下のような 質問を作成します。 ■ 現場監督の仕事は何か。 ■ 機械工の仕事は何か。 ■ 仕上がった製品を検査するのは誰か。 ■ 部品組立品を検査するのは誰か。 ■ 組立部品は工場内をどのように移動されるか。 ■ 各手順でどのツールが必要か。 ビューポイント モデリング セッションでは、異なるビューポイントの担当者を含めることが重要です が、モデルは単一の具体的なビューポイントから作成する必要があります。その他 のビューポイントは、「説明専用（FEO: For Exposition Only）」ダイアグラムに短く記 述することがよくあります。 このダイアグラムは、プレゼンテーション用にのみ使用し ます。 ビューポイントは、目的に合わせて、慎重に選択する必要があります。前述の機械 工場の例では、異なる仕事相互の関係を現場監督のみが観察しているため、現場 監督の観点からモデルを作成する必要があります。 1 つのモデルで最初から最後まで単一のビューポイントを維持することが大切です。 ビューポイントは職位や部門であるか、または現場監督、溶接工などの職務である 必要があります。目的を記述することと同様、進路を定め、継続的に再構築するた めには、具体的なビューポイントが必要です。 すべてのアクティビティを詳細に記述するためには、異なる観点から複数のモデル を構築する必要がある場合があります。 3–18 AllFusion Process Modeler 手法ガイド IDEF0 モデルの構築 スコープ アクティビティ モデルを作成する利点の 1 つは、システム全体および個別のコン ポーネント アクティビティのスコープが明確になることです。モデリングの間にスコー プを多少変更することはあっても、モデリングの方向性を示すためには、スコープが 持続される必要があります。目的を記述する場合同様、スコープを定義しておかな いと、モデルがどの時点で完了するのかを判定できません。これは、モデルの作成 が進むにつれて、モデルのスコープも拡大される傾向があるためです。 スコープは、幅と深度という 2 つの要素で構成されます。モデルの幅によって、作業 の外枠を定義します。深度によって、アクティビティを分解する詳細さのレベルを定 義します。 スコープを正確に定義するために、多くの IDEF0 モデリング作業では、モデルのコ ンテキスト ダイアグラムの作成に時間をかけます。コンテキスト ダイアグラムの上の レベルにダイアグラムを作成して、このシステムが属する、より大規模なシステムまで 検証する場合もあります。コンテキスト ダイアグラムに対する変更は、いずれも配下 のダイアグラムに分解されるため、コンテキスト ダイアグラムは、モデル全体を参照 する場合のアンカーであり中心点として働くため、コンテキスト ダイアグラムの作成 にはより力を入れる価値があります。 スコープを記述すると、どの素材をモデルに含めないのかもはっきりします。 システムの命名（アクティビティ） まずモデルの目的を定義し、次にモデルのビューポイントを決定し、最後にモデル のスコープを特定するという順序で作業することをお勧めします。コンテキスト ダイ アグラムに表示されるアクティビティ名でスコープの内容を要約します。このアクティ ビティは、モデルで最上位のアクティビティです。 コンテキスト アクティビティには、モデルのスコープの記述と一貫する、動作を表す 動詞の動詞句を設定する必要があります。このため、「顧客サービスを管理する」、 「申請を処理する」のように広い意味を持つ動詞句が、ラベルとして使用されます。 モデリングの最初の 1、2 日目には、モデルのスコープが多少ふらつくことがありま す。目的とビューポイントは、開始時点から固定されている必要があります。異なる ビューポイントから問題を説明するために、任意の時点で、FEO ダイアグラムを作成 できます。 常に、モデルの目的、ビューポイント、およびスコープを定義することから開始するこ とが重要です。これらを厳密に定義することは、モデリング作業全体にとって非常に 重要ですので、充分に時間を費やす価値があります。モデルの目的、ビューポイン ト、およびスコープは、モデリング プロジェクトの終わりまで、プロジェクトの指針とし て継続的に参照します。 IDEF0 機能モデリング手法 3–19 IDEF0 モデルの構築 主な ICOM の定義 IDEF0 ダイアグラムで矢印を作成する順序を考える場合、まずアウトプット矢印を作 成してから、インプット矢印を作成し、その後でメカニズム矢印およびコントロール矢 印を作成すると簡単です。各アクティビティは特定の機能のために存在し、各機能 には通常、簡単に特定できるアウトプットがあります。アクティビティのアウトプットを 確定するのが難しい場合、ビジネス プロセスを改良する余地があることを示している 場合があります。 アウトプットの定義 アウトプットを特定する場合、考えうるシナリオがある限りのアウトプットを、モデルに 取り込むことに留意することが重要です。つまり、業務で発生する可能性のある状 況であれば、その状況の可能性を示すためにモデリングする必要があります。モデ ルの作成経験が浅い場合、アクティビティの否定的な結果をモデリングし忘れがち です。たとえば、「車の運転試験を実施する」アクティビティでは、試験に合格した 運転者がアウトプットとして作成されることは確かですが、合格しなかった志願者用 のもう 1 つのアウトプット矢印も存在すると考えられます。否定的な結果は、フィード バック矢印として使用されることが多く、すべてのアクティビティで否定的な結果を 考える必要があります。同様に、不確実な矢印についてもダイアログに含め、その 矢印をモデルに含めるべきかどうかを業務の専門家が決定できるようにすることも 重要です。 インプットの定義 アウトプット矢印を作成し終えたら、インプットについて考えます。アクティビティに よってインプットが明確に変換または消費されてアウトプットが作成されます。製造 業では、原料がどのように変換または消費されてまったく異なるアウトプットが作成さ れるのかを簡単に示すことができます。一方、情報産業では、当初、インプット デー タがまったく変換も消費もされないように見えることがあります。インプット矢印とアウ トプット矢印の名前が完全に同一であることは、ほとんどありません。この場合は、通 常、このアクティビティが業務にほとんど価値を追加しないか、アウトプットの名前が 不適切であるかのいずれかです。これを解決するためには、形容詞を使用して矢 印の名前にある名詞を修飾し、アクティビティを通じて実行される変換の内容を示 すようにします。たとえば、インプットには、「raw patient data（原患者データ）」のよう な名を付け、対応するアウトプットには、「verified patient data（受付済み患者デー タ）」のような名を付けます。形容詞 raw と verified によって、patient data を修飾し、 変換の内容が明確化されています。 メカニズムの定義 アウトプット矢印とインプット矢印を作成し終えたら、アクティビティで用いるメカニズ ム、またはリソースを考えます。メカニズムには、人、機械、コンピュータ システムな どが含まれます。たとえば、「部品を作成する」アクティビティには、通常、ドリルのよ うな何らかの機械が必要です。「車の運転試験を実施する」の場合は、試験監督が 試験を実施します。病院の例では、しばしばコンピュータ設備などほかのメカニズム を使用しながら、事務員または看護職員がデータを確認します。 3–20 AllFusion Process Modeler 手法ガイド IDEF0 モデルの構築 コントロールの定義 最後に、アクティビティを調整する、コントロールを追加します。コントロールはしばし ば、ルール、規制、ポリシー、手順、標準などの形をとります。どの IDEF0 アクティビ ティにも、コントロールが 1 つ以上必要です。インプットとアウトプットの関係がはっき りしない状況の場合、デフォルトとして、コントロールとして扱う必要があります。コン トロールは、アクティビティに対するインプットの一形態です。 コンテキスト ダイアグラムが完成し、安定したら、以下の点を確認します。 ■ モデリングするビジネス アクティビティがダイアグラムによって要約されているか。 ■ コンテキスト ダイアグラムは、記述されているスコープ、ビューポイント、および 目的と一貫しているか。 ■ 矢印は、アクティビティにとって適切な詳細さであるか。目安としては、1 つの種 類の矢印を 6 本までとします。 ■ モデルは、ワークグループのコンセンサスを得ているか。 アクティビティとダイアグラムの番号付け すべての IDEF0 アクティビティに番号を付けます.任意の長さのプレフィックスを使 用できますが、通常はすべてのモデルで「A」を使用します。プレフィックスに続けて、 番号を指定します。ルート アクティビティの番号は、通常「A0」です。 各アクティビティで同じプレフィックスを使用します。番号を使用してアクティビティの 詳細度を表します。A0 アクティビティを分解すると、A1、A2、A3…になります。A1 を分解すると、A11、A12、A13…になります。A11 を分解すると、A111、A112、 A113…になります。分解のレベルごとに、順序を示す桁が 1 つずつ追加されます。 最初のレベルだけは例外で、A0 を分解しても A01、A02、…とはならず、A1、A2、 …となります。 ダイアグラムから親アクティビティへのリレーションシップ（境界および階層） より詳細に記述する必要がある場合、アクティビティを分解します。アクティビティを 分解するときは、アクティビティのライフ サイクルを考慮します。これによって、子アク ティビティ候補のリストを作成できます。たとえば、「クッキーを作る」ノードのライフ サ イクルには、「材料を集める」、「バターを塗る」、「生地を焼く」などがあります。 IDEF0 機能モデリングでは、子ダイアグラムの境界が、親アクティビティの境界であ ることを理解することが大切です。両者は一致します。このことは次の結果になりま す。すべての作業は、リーフ アクティビティつまり最下層のアクティビティで実行され ます。構造化プログラミングでの階層と異なり、上のレベルのアクティビティは、子ア クティビティのコントローラではありません。子は、親そのものをより詳細に表示したも のです。CEO が実行するアクティビティは、作業員が実行するアクティビティと並列 の関係にあります。 IDEF0 機能モデリング手法 3–21 IDEF0 モデルの構築 親ダイアログで対応する矢印が存在する位置を示すために、各子ダイアログの境界 矢印の終わりに ICOM コードが配置されます（図 3-19）。ICOM コードは、一貫性検 査として機能し、子ダイアグラムでの矢印の順序が親ダイアグラムでの順序と異なる 場合に便利です。ICOM コードは、I、C、O、または M の 1 文字と、親のアクティビ ティ ボックスでの上から下の順または左から右の順で、この矢印の位置を示す番号 で構成されます。たとえば、I1、C1、O1、M1 のようになります。 図 3-19 ダイアグラムの境界に表示される ICOM コード 幅優先モデリングと深度優先モデリング モデルを作成するには、幅優先で、つまり各ダイアグラムをできるだけ詳細化してか ら分解して作成するか、深度優先で、つまり最初にアクティビティ階層を特定してか ら矢印を作成してアクティビティを接続することによって作成するかのいずれかの方 法があります。一つのモデルの構築で両方のテクニックを使用することも、もちろん 可能です。矢印を記述すると、矢印によって新しい洞察が構造に加わるため、アク ティビティの階層が多少変更されることもあります。 終了時点の判断 ダイアグラムの目的を記述するときには、その IDEF0 モデルで解答する質問の種 類を示す必要があります。モデルによってこれらの質問に解答できるようになれば、 モデルはその目的を満たすため、完成したと考えられます。第 1 レベルの分解を行 う場合、ダイアグラム内のアクティビティがモデルのスコープに入っていることを確認 します。アクティビティを分解する前に、アクティビティの深度がモデルの目的を満た すために充分であるかどうかを確認します。また、IDEF0 では、アウトプットとイン プットの先行矢印によってダイアグラムが統制されている場所にのみ進む必要があ ります。必要に応じて、IDEF3 モデルを使用して、詳細プロセスをモデリングできま す。 その他の IDEF0 ダイアグラム コンテキスト ダイアグラムと分解ダイアグラムのほかにも、モデルの構築とプレゼン テーションに使用できる IDEF0 ダイアグラムがあります。 3–22 AllFusion Process Modeler 手法ガイド IDEF0 モデルの構築 ノード ツリー ノード ツリーは、モデル全体を概観するダイアグラムです。「Quill ビジネスを運営す る」のノード ツリー例の一部を図 3-20 に示します。トップ ノードは、通常、コンテキス ト ダイアグラム アクティビティに対応し、その下にモデル全体の階層を構築します。 ただし、トップ ノードには任意のアクティビティを指定でき、その子を使用したツリー が構成されます。アクティビティのモデリングでは通常、何度も見直しを行いますの で、安定バージョンを作成するためには、ノード ツリーを何度も作り直すと考える必 要があります。コンテキスト ダイアグラムに記した、目的、スコープ、およびビューポ イントは、よりどころとするアンカーとして使用できます。これらの記述を参照しない で作業を進めると、ノード ツリーはいつまで経っても安定しません。モデルをノード ツリーとして考えると、各分解を接続するフローを考慮することなく、機能の分解に 集中することができます。 図 3-20 グラフィカルなノード ツリーの一部 IDEF0 機能モデリング手法 3–23 IDEF0 モデルの構築 FEO ダイアグラム 説明専用（FEO: For Exposition Only）ダイアグラムは、ほかのビューポイントや、従 来の IDEF0 モデリング構文では明確にサポートされていない詳細を説明するため によく使用されます。FEO ダイアグラムでは、モデルにある重要な点または部分を 強調するために、IDEF0 のどのルールおよびガイドラインでも破ることができます。 モデルの異なるビューポイントを示すためだけに FEO ダイアグラムを作成する場合 は、当然、IDEF0 のルールと規約に従う意味があります。 アクティビティを同じレベルの兄弟アクティビティから分離するために FEO ダイアグ ラムを使用することもできます。この場合は、単一のアクティビティのダイアグラムを 作成し、コンテキスト ダイアグラムのように、ダイアグラムの境界に接続する矢印を作 成します。まとめ役が機能のインタフェース（矢印）に関する情報を収集していて、変 更を簡単に反映するためには分解ダイアグラムが複雑になりすぎる場合に、この方 法を用いると便利です。 図 3-21 単一のアクティビティを分離し、矢印が接続されている FEO ダイアグラム 3–24 AllFusion Process Modeler 手法ガイド IDEF0 モデルの構築 FEO ダイアグラムのそのほかの一般的な用途を以下に示します。 ■ 子アクティビティ用の代替コンテキスト ダイアグラム。この種類の FEO ダイアグ ラムを使用すると、 アクティビティに対する環境（コンテキスト）の変化の潜在的 な影響を検討できます。 ■ ほかのダイアグラムをすべてのアクティビティを含めてコピーし、矢印について は選択したアクティビティに接続されている矢印のみをコピーしたダイアグラム。 この種類の FEO ダイアグラムを作成すると、選択したアクティビティとダイアグラ ムにあるほかのアクティビティとの相互作用が強調されます。 ■ ほかのダイアグラムをすべてのアクティビティを含めてコピーし、矢印について は、親アクティビティの主要アウトプットを直接表す矢印だけをコピーしたダイア グラム。この種類の FEO ダイアグラムを使用すると、主要なインプットが主要な アウトプットにどのように変換されるのかが強調されます。 ■ ■ 1 つ深いレベルのさまざまなビューポイント。この種類の FEO ダイアグラムを使 用すると、重要な利害関係者によるモデリング対象システムの観点を検討でき ます。 ほかのダイアグラムをすべてのアクティビティを含めてコピーし、矢印について は、特定の点を強調する矢印のみをコピーしたダイアグラム。この章の図 3-9、 3-16、3-17、および 3-19 は、説明に合わせて特定の点を明確化するために一 部の矢印とアクティビティが削除されているため、すべてこの種類の FEO ダイ アグラムの例です。 IDEF0 機能モデリング手法 3–25 Chapter 4 データ フロー ダイアグラム 概要 IDEF0 と同じように、データ フロー ダイアグラム（DFD: Data Flow Diagram）では、 オブジェクトのパイプラインで接続されたアクティビティのネットワークとしてシステム をモデリングします。データ フロー ダイアグラムでは、貯蔵タンクとして機能する データ ストア、およびモデリングしているシステムの境界の外側にあるオブジェクトと のインタフェースを表す 外部エンティティ もモデリングします。典型的なデータ フ ロー ダイアグラムを図 4-1 に示します。 図 4-1 典型的なデータ フロー ダイアグラム 制約リレーションシップを表す IDEF0 の矢印と異なり、DFD での矢印は、データな どのオブジェクトが、アクティビティからアクティビティに流れる、つまり移動する様子 を示します。データ ストアおよび外部エンティティと組み合わせてフローを表すこと によって、DFD モデルでは、システムの物理的な特徴の一面をよりよく表現できま す。つまりデータ フローによってオブジェクトの移動を表し、データ ストアによってオ ブジェクトの保管を表し、外部エンティティによってオブジェクトの調達と配布を表し ます。 データ フロー ダイアグラム 4–1 DFD モデルの構文およびセマンティクス データ フロー ダイアグラムは、元々、ソフトウェア アプリケーションを開発するため に作成されたため、この目的で使用することが一般的です。例で使用してある独特 のボックスは、Gane & Sarson DFD メソッドを開発した、Chris Gane および Trish Sarson が採用したものです。アクティビティは、角の丸いボックスで表されます。この 章の内容は、アクティビティをバブルとも呼ぶ円で表す Yourdon/DeMarco DFD メ ソッドにも当てはまります。Yourdon/DeMarco DFD メソッドは、Edward Yourdon およ び Tom DeMarco によって開発されました。 DFD モデルの構文およびセマンティクス 相互連結するアクティビティとしてシステムをとらえる IDEF0 と異なり、データ フロー ダイアグラムでは、システムを名詞で理解します。コンテキスト データ フロー ダイア グラムは、しばしば 1 つのアクティビティ ボックスと複数の外部エンティティとで構成 されます。アクティビティ ボックスの名前には、通常、「羽軸コンピュータ ビジネス シ ステム」のようにシステムの名前を付けます。典型的なデータ フロー コンテキスト ダ イアグラムを図 4-2 に示します。 外部エンティティが加わっていますが、「IDEF0 機能モデリング手法」の章で説明し た、単一のビューポイントからモデルを構築すること、および目的とスコープをはっき り定義しておくことという基本要件に変わりはありません。 図 4-2 典型的なデータ フロー コンテキスト ダイアグラム アクティビティ DFD でのアクティビティは、入力を出力に処理または変換する機能を表します。 DFD では角の丸いボックスで表されますが、DFD でのアクティビティは IDEF0 およ び IDEF3 でのアクティビティと同じ意味です。IDEF3 でのアクティビティと同じく、 DFD でのアクティビティには、入力と出力がありますが、IDEF0 のようなコントロール 矢印とメカニズム矢印はサポートされていません。 Gane および Sarson の DFD の一 部で実装されているように、IDEF0 で言うメカニズム矢印は、リソースとしてモデリン グし、ボックスの下部に記述します（図 4-3）。 4–2 AllFusion Process Modeler 手法ガイド DFD モデルの構文およびセマンティクス 図 4-3 Gane および Sarson のデータ フロー ダイアグラムの例 外部エンティティ 外部エンティティはシステムへの入力を提供するか、出力を受け取るか、またはそ の両方を行います。1 つの外部エンティティで、たとえば、供給業者として入力を提 供し、たとえば、顧客として出力を受け取ることができます。外部エンティティは、影 付きのボックスで表し、通常、ダイアグラムの縁に記述します。1 つのダイアグラムで は、1 つの外部エンティティ（たとえば、顧客）を、複数回使用できます。複数回使用 しないと、ダイアグラムを横切る長い線を引くことになり、ダイアグラムが見づらくなっ てしまうのを防ぐことが主な目的です。 図 4-4 外部エンティティの例 矢印（データ フロー） システムの 1 つの部分から別の部分へのオブジェクトの移動（フロー）は、矢印で記 述します。ボックスの各辺が意味を持つ IDEF0 と異なり、DFD のアクティビティ ボッ クスの各辺に特別な機能はないため、アクティビティのどこからでも矢印を引くことが できます。DFD では、2 つのアクティビティの間、アクティビティと外部エンティティの 間、および 2 つの外部エンティティの間の、コマンドと応答の協調した対話を表すた めに、両方向矢印も使用します。「Quill コンピュータ ビジネス システム」と「顧客」と の協調的なやりとりを表す両方向矢印を図 4-5 に示します。 データ フロー ダイアグラム 4–3 DFD モデルの構文およびセマンティクス 図 4-5 アクティビティと外部エンティティを接続する両方向矢印 データ ストア フローが移動中のオブジェクトを表すように、データ ストアは静止しているオブジェ クトを表します。製造業でのシステムの場合、製造過程の製品を蓄積しておく、工場 に散在するキューのような場所がデータ ストアに当たります。データ加工システムの 場合は、以降の処理のためにデータを保持するすべてのメカニズムがデータ ストア に当たります。典型的なデータ ストアを図 4-6 に示します。 図 4-6 データ ストアの例 分岐と結合 DFD の矢印は分割（分岐）できます。分岐した矢印セグメントには、フローに沿って 運ばれるデータの分解を示すためにラベルを付け直すことができます。3 つの矢印 に分割される顧客情報矢印の例を図 4-7 に示します。 図 4-7 データの分解を示す分割矢印 4–4 AllFusion Process Modeler 手法ガイド DFD の構築 矢印をマージ（結合）して、集約オブジェクトを形成することもできます（図 4-8）。 図 4-8 矢印をマージして集約オブジェクトを形成する例 DFD の構築 DFD は、IDEF0 に似た、従来の、構造化分析設計のアプローチを使用して構築で きます。現在使用している実際のシステムをモデリングするためには、まず、現在の 物理モデルを構築します。次に、現在のシステムに不可欠な要件をモデリングする ために、現在の論理モデルを作成します。この後、システム案で不可欠な要件をモ デリングするために、新しい論理モデルを作成します。最後に、実装する内容をモ デリングするために、新しい物理モデルを作成します。 ソフトウェア設計で、しだいに人気を集めている別のアプローチとして イベント パー ティショニングがあります。イベント パーティショニングでは、システムをモデリングす るために複数の DFD を構築します。最初に、アクティビティのコレクションとしてシス テムをモデリングする論理モデルを構築し、システムで行う必要のある内容を文書 化します。 次に、環境モデルで、外部エンティティからのイベントに応答するオブジェクトとして システムを記述します。環境モデルは、通常、システムの目的の記述、単一のコン テキスト ダイアグラム、およびイベント リストで構成されます。コンテキスト ダイアグラ ムは、システム全体を表す単一のボックスと、システムと相互作用する複数の外部エ ンティティ、つまり環境とで構成されます。 最後に、システムで各イベントを処理する方法をモデリングするために 動作モデル を作成します。このモデルは最初、環境モデルで特定した 1 つのイベントへの応答 を 1 つのボックスで表した、単一のダイアグラムにします。イベント間で記憶しておく 必要のあるモデル データにデータ ストアを追加します。ほかの要素を接続するため にフローを追加し、環境モデルとダイアグラムとが一貫していることを確認します。 データ フロー ダイアグラム 4–5 DFD の構築 モデルをプレゼンテーション用に書式設定し直すためには、通常、クリーンアップ処 理が必要です。親ダイアグラムを作成して簡素化するにはアクティビティを集約し、 より明確にするにはアクティビティを分解します。 オブジェクトの番号付け DFD のアクティビティ番号には、たとえば、プレフィックス、親ダイアグラム番号、およ びオブジェクト番号を含めます（図 4-9）。オブジェクト番号によって、ダイアグラムに あるアクティビティを一意に識別します。親ダイアグラム番号とオブジェクト番号とに よって、モデル内の各アクティビティを一意に識別します。 図 4-9 DFD のアクティビティ番号のコンポーネント ダイアグラムでオブジェクトが配置されている場所によらず、各データ ストアや外部 参照名に一意の番号が割り当てられます。 各データ ストア番号には、プレフィックス D および一意のストア番号を含めることが できます（図 4-10）。 図 4-10 DFD データ ストアの番号付け 同様に、各外部参照には、プレフィックス E および一意の外部参照番号を含めるこ とができます（図 4-11）。 図 4-11 DFD 外部参照の番号付け 4–6 AllFusion Process Modeler 手法ガイド Chapter 5 アクティビティ ベースの原価計算およ びパフォーマンス メトリクス アクティビティ モデルは、ほかのモデリングの基礎として使用できます。たとえば、ア クティビティ ベースのコスト モデルでは、製品を組み立てるためのコストが、製品を 組み立てるアクティビティおよび製品の原料と関連付けられます。 シミュレーション モデルを作成する基礎としてアクティビティ モデルを使用すること もできます。シミュレーション モデルは、時間に依存するシステムの変動を調査する ために使用します。シミュレーション モデルは、たとえば、新しいシステムのスルー プット率、つまり一定期間にシステムが製造するオブジェクトの量を予測するためな どに作成します。 アクティビティ ベースの原価計算 アクティビティ ベースの原価計算（ (ABC）は、アクティビティのコストを取得して分析 するためのテクニックです。ABC では、原料、労働などリソースのコストを取り込み、 このコストをさまざまなアクティビティに割り振ってから、このアクティビティをコスト オ ブジェクトと呼ぶさまざまなシステム出力に割り振ります。従来の原価計算では、少 量生産品の原価が実際よりも低めに見積もられ、大量生産品の原価が実際よりも高 めに見積もられる傾向があるのに対し、ABC では、製品の製造に関わる各アクティ ビティを実行するための原価に基づいて、個々の製品を作るための原価がより正確 に計算されます。 アクティビティ ベースの原価モデル ABC はアクティビティ ベースですので、ABC システムの設計には企業の運営が正 確に反映されます。ABC システムを実装するためには多額の費用がかかる場合が あるので、会社にとって負担の大きなコストに的を絞ることが大切です。 次の表では、リソース（メカニズム）のコストをアクティビティおよび製品ごとに記録し ています。「ドリルで穿孔する」アクティビティには、「穿孔盤」と「穿孔盤オペレータ」 の 2 つのリソースが必要です。製品 A には、各リソースが 4 単位必要です。製品 B には 6 単位必要です。 アクティビティ ベースの原価計算およびパフォーマンス メトリクス 5–1 アクティビティ ベースの原価計算 アクティビティ名 製品 A リソース 製品 B 名前 原 価 （ドル） 数量 合計（ドル） 数量 合計（ドル） 穿孔盤 $06.75 4 $27.00 6 $40.50 穿孔盤オペレータ $02.50 4 $10.00 6 $15.00 旋盤 $01.20 5 $06.00 5 $06.00 旋盤オペレータ $02.50 5 $12.50 5 $12.50 えぐり道具 $12.45 3 $37.35 9 $112.05 えぐり道具オペレータ $10.50 3 $31.50 9 $94.50 押し抜き機 $01.00 1 $01.00 2 $02.00 押し抜き機オペレータ $50.00 1 $00.50 2 $01.00 鋲打ちツール $00.50 9 $04.50 9 $04.50 鋲打ちツール オペレータ $02.50 9 $22.50 9 $22.50 アーク溶接機 $14.85 1 $14.85 2 $29.70 アーク溶接機オペレータ $09.50 1 $09.50 2 $19.00 レンチ $00.01 19 $00.19 19 $00.19 クルー $01.50 19 $28.50 12 $28.50 ねじ回し $00.01 12 $00.12 12 $00.12 クルー $01.50 12 $18.00 12 $18.00 くぎ打ち銃 $10.00 0 $00.00 1 $00.10 クルー $01.50 0 $00.00 8 $18.00 接着銃 $00.10 6 $00.60 8 $00.80 接着工 $01.50 6 $09.00 8 $12.00 操作 機械加工 ドリル穿孔 旋盤 えぐり出し 押し抜き 組み立て 鋲打ち 溶接 ボルト締め ねじ止め くぎ打ち 接着 製品ごとの総費用 $233.61 $436.96 前の表では、リソースを製品に関連付けるために次の式を使用しています。 リソース原価 × 量 = 製品のリソース原価 この式は原価作用因として知られています。製品を、通常、コスト オブジェクトと呼 びます。主要な組織単位、たとえば「部」を、通常、コスト センタと呼びます。 5–2 AllFusion Process Modeler 手法ガイド シミュレーション 製品の総費用に占める原材料（入力）コストの割合が非常に大きい場合、前の表に 似た表をもう 1 つ作成すると、各製品のアクティビティごとに原材料のコストを追跡で きます。 同様に、コントロールを使用するためのコストが、アクティビティのコストの非常に大 きな割合を占める場合、どの IDEF0 を使用してコントロールについて検討するのか のコストが必要です。前の表に似た表をもう 1 つ作成します。 最後に、アクティビティが失敗した場合のコストを理解することが重要な場合がありま す。これは、アクティビティの失敗が、大きなコストを意味する場合です。たとえば、 廃棄物（スクラップ）が出たり、やり直しの必要が生じたりすることがあります。これら のコストを、製品に対して正確に加算する必要があります。前の表に似た表をもう 1 つ作成します。 別々の表を作成するほかに、前の表に行を追加して、リソース、入力、コントロール、 および出力を混在させ、情報を捕捉することもできます。 階層的なアクティビティ モデルでは、リーフレベル アクティビティ、つまりそれ以上 分解されていないアクティビティのみにコストが振り分けられます。親アクティビティ のコストはリーフレベル アクティビティのコストの合計になります。 シミュレーション シミュレーションとは、時間の関数として発生するシステムの変化を調査するために 使用するモデリング テクニックです。時間の経過とともにシミュレーションが進むに つれて、実際と同じようにシステムがシミュレートされ、関連する統計情報が収集さ れます。 アクティビティ モデルをシミュレーションすると、統計関連の変化がイベントに関連 付けられます。実際のシミュレーションは、1 つのイベントから次のイベントへと時間 に合わせて移動することによって実行されます。このようなシミュレーションは、一般 的に、離散事象シミュレーションと呼ばれます。 シミュレーションは、通常、オペレーションズ リサーチと関連付けられます。オペレー ションズ リサーチは、限定されたリソースでのアクションの最適（最良）のコースを決 定しようとする意思決定の科学です。しかし、実際のシステムの多くでは、システム の目的や制約を定量的に表現することも、数学的に表現することも困難です。これ に対して、シミュレーションでは、複雑になることの多い数式ではなく、洗練された論 理的リレーションシップで結合した基本的なモジュールのコレクションとして、対象の システムをモデリングします。数理モデルと比較して、シミュレーション モデルでは、 通常、目的や制約をより柔軟に定義できます。 シミュレーション モデリングには、2 つの顕著な短所があります。1 つ目は、わずかな 点が出力に大きく影響する場合があることです。このため、かなりのコストを費やして、 モデルを詳細化する必要があります。2 つ目は、高速なコンピュータ システムを使 用しても、シミュレーションを実行するために非常に時間がかかることです。 アクティビティ ベースの原価計算およびパフォーマンス メトリクス 5–3 シミュレーション シミュレーション モデルとアクティビティ モデルとは、相乗的な関係にあります。アク ティビティ モデルを変換すると、シミュレーション モデルのスケルトン（未完成版）が できます。シミュレーション モデルによって、いくつかのシステムのパフォーマンスを ずっとよく理解できます。その結果、通常、元のアクティビティ モデルに変更が発生 します。 以降では、シミュレーション モデルの主要コンポーネントについて説明します。 ソースと宛先 ソースでは、入力の到着をモデリングします。概念的には、データ フロー ダイアグラ ムの外部エンティティに似ています。到着間隔（到着と到着の間の時間）は、通常、 normal(平均、 標準偏差)のような統計的分布として、数式で記録されます。 宛先も外部エンティティに似ていますが、シミュレーションでは、通常、情報収集デ バイスとしての役割を務めます。宛先では、システム内でのオブジェクトの移動に関 連する情報を捕捉します。この情報には、オブジェクトを入力から出力に変換する ための総時間、出力を作成するための総コストなどを含めることができます。 キュー シミュレーションには、ほかにも DFD と共通する構成概念、データ ストアがあります。 シミュレーションでは、キューと呼びます。キューは、処理待ち状態の 1 つ以上のオ ブジェクトをモデリングするための手段です。アクティビティの実行に必要な時間を、 アクティビティ サイクル時間、または継続時間 と言います。アクティビティの継続時 間は、反復ごとに異なる場合があり、その結果、出力が変動します。たとえば、通常 は同じ時間かかる 2 つのアクティビティを考えます。先に実行するほうのアクティビ ティが、後で実行するアクティビティよりも早く終了する場合があります。この場合、 未完成品がキューに蓄積されることになります。 シミュレーションでは、キューの動作をコード化する必要があります。キューは、たと えば、最後に入れたアイテムを最初に取り出すスタックとして使用できます。この方 法を後入れ先出し法（LIFO: Last-in First-out）と言います。これとは異なり、待ち行 列では、通常、先入れ先出し（FIFO: First-in First Out）が基本です。キューからアイ テムをランダムに取り出したり、ほかの何らかの方式に従って取り出すこともできます。 IDEF0 モデルや IDEF3 モデルのシミュレーション時には、入力およびコントロール ごとにキューが想定されます。 ファシリティ ファシリティには、システムのアクティビティをモデリングします。ファシリティという用 語は、シミュレーションが製造業に起源することを反映しています。製造業では、作 業台（通常は専用の機械）でアクティビティが実行され、1 つのステーションから次の ステーションに組み立てライン形式によって製造中の製品が移動されます。処理時 間は、数式で（通常、統計的に）記録されます。また、リソース（メカニズム）で使用す るルールが指定されます。 5–4 AllFusion Process Modeler 手法ガイド シミュレーション シミュレーションの例 この例では、銀行の窓口業務をモデリングします。各種取り引きを実行するために 必要なアクティビティの組み合わせが異なる場合に、どのように窓口係を配置すると 最良なのかを、理解することを目的とします。この銀行には、以下に概要を説明する 5 つの窓口業務があります。 口座への預け入れ 1. 小切手の入金の場合、小切手を確認し、預金を記録します。 2. 現金の入金の場合、現金を数えて、現金箱への保管を記録し、現金を現金箱 に入れます。 3. 現金による多額の預け入れの場合、現金計数機を使用します。 4. 現金を顧客に返却する場合、現金箱から現金を取り出し、数えてから顧客に渡し ます。 5. 出金額を記録します。 6. 領収書を顧客に返します。 図 5-1 口座への入金 口座からの出金 1. 口座残高を確認します。 2. 現金箱から現金を取り出し、数えて、顧客に渡します。 3. 出金額を記録します。 図 5-2 口座からの出金 アクティビティ ベースの原価計算およびパフォーマンス メトリクス 5–5 シミュレーション 口座から口座への振込み 1. 振り込み元口座の残高を確認します。 2. 出金額を記録します。 3. 入金を記録します。 4. 領収書を顧客に返します。 図 5-3 口座から口座への振込み 銀行小切手の発行 1. 引き出しの場合、口座残高を確認します。出金額を記録します。 2. 現金取引の場合、顧客の取り引き状況を確認し、小切手を確認し、現金を数え ます。 3. 小切手を印刷して、発行します。 図 5-4 を見ると、銀行小切手代の支払い方法に基づいて、取り引きの種類を概ね 2 つに分けられることがわかります。口座からの引き落としと、現金払いです。OR ジャ ンクションで示されていることからわかるように、ユーザは、現金、小切手、またはそ の両方で支払うことができます。3 種類の現金取引を実行するための総時間（およ びコスト）が大きく異なる場合、シミュレーションを正確にするために、すべてのケー スをモデリングすることが重要です。法人顧客の口座の取り引きに要する時間が、 個人口座の場合と比べて大幅に異なる場合、これについてもモデルに組み込む必 要があります。 図 5-4 銀行小切手の発行 5–6 AllFusion Process Modeler 手法ガイド シミュレーション 口座の新規作成 この例では、口座の新規作成について、明示的にモデリングされていません。代わ りに、式が使用されています。すべてのアクティビティを同じ詳細度までモデリング する必要はありません。重要なのは、モデルの目的を満たすために充分な詳細度 でモデルを作成することです。 重要なシミュレーション変数を表形式で以下に示します。次の表は、アクティビティ を実行するために必要な各リソース（IDEF0 メカニズム）です。 使用可能な 数量 1 分あたり のコスト MTBF ダウンタイム 窓口係 3 $0.20 0 0 現金計数機 1 $0.05 Normal (6000,25) Normal (16,3) リソース名 前の表で MTBF は、平均故障間隔（Mean Time Between Failure）を表します。 MTBF は、故障で使用できないことのあるリソースが存在する場合の記録に使用し ます。ダウンタイムは、そのリソースを使用できない時間が通常どの程度であるのか を示します。数日間にわたるアクティビティをシミュレーションする場合のように、各 窓口係の実働状況をもっと正確にモデリングする必要がある場合、リソース カレン ダを使用して実働カレンダを記述できます。 統計分野では、特定の現象の確率を記述するためにいくつかの定式が作成されて います。たとえば、金曜日の正午から午後 1 時までに、ある銀行の窓口を訪れる顧 客は平均何人でしょうか。平均（mean）は、図 5-5 で、各曲線分布の 3 つの頂点に よって表現されています。誤差の範囲、つまり、各サンプルの値の距離を標準偏差 と言い、各曲線の幅で表されます。確率曲線は図 5-5 に示した正規分布のほかに も多数あり、それらによって多様な状況を記述します。図示した場合、それらの確率 曲線は、図 5-5 の図形とかなり異なります。 図 5-5 平均値が等しく、標準偏差が異なる 3 つの確率正規分布 アクティビティ ベースの原価計算およびパフォーマンス メトリクス 5–7 シミュレーション これらの確率式は、シミュレーションの核心です。統計の確率式は、アクティビティの 実行時間の範囲を表すためのほかに、到着間隔や、リソースの可用性を表すため にも使用できます。シミュレーション エンジンが実行されると、シミュレーションを実 際に実行するソフトウェアで、これらの式を利用して、アクティビティ実行時間、到着 率、およびリソースの可用性が割り出されます。 次の表に示すように、各アクティビティの実行時間は、統計の確率式によって表され ます。たとえば、「小切手を確認する」と「現金払いを勘定する」は、正規分布になる ように分散され、実行に平均 0.5 分かかります。0.5 は、式にある最初の値です。アク ティビティが、常に 0.5 分で実行されるわけではありません。0.5 分は単なる平均で す。まれな場合を除いて、取り引きは 0.4 分から 0.6 分の範囲で終わることもわかり ます。式の 2 つ目の値、つまり標準偏差を、平均値に加算すると 0.6 が得られ、平 均値から減算すると 0.4 が得られます。 注: 次の表で CCM は、現金計数機（Cash-counting Machine）です。 アクティビティ名 リソース名 リソースの数量 時間 「小切手を確認する」および「入金を記録す る」 窓口係 1 Normal(.5,.1) 現金による少額の入金を数える 窓口係 1 Normal(.5,.5) 現金による多額の入金を数える 窓口係 CCM 1 1 Normal(1,.5) 「現金箱への入金を記録する」および「現 金箱に入金する｣ 窓口係 1 Normal(1,.5) 現金箱から出金する 窓口係 1 Normal(.3,.1) 現金による少額の返金を数える 窓口係 1 Normal(.5,.5) 現金による多額の返金を数える 窓口係 CCM 1 1 Normal(1,.5) 顧客に渡す 窓口係 1 Normal(.3,.1) 出金合計額を記録する 窓口係 1 Normal(.3,.1) 顧客に領収書を返却する 窓口係 1 Normal(.3,.1) 顧客の口座へ入金する 1 顧客の口座から出金する 口座残高を確認する 窓口係 1 Normal(.5,.3) 現金箱から出金する 窓口係 1 Normal(.3,.1) 現金による少額の返金を数える 窓口係 1 Normal(.5,.5) 現金による多額の返金を数える 窓口係 CCM 1 1 Normal(1,.5) 顧客に渡す 窓口係 1 Normal(.3,.1) 出金合計額を記録する 窓口係 1 Normal(.3,.1) 窓口係 1 Normal(.5,.3) 顧客の口座から口座に振り込む 出金口座の残高を確認する 5–8 AllFusion Process Modeler 手法ガイド シミュレーション アクティビティ名 リソース名 リソースの数量 時間 出金を記録する 窓口係 1 Normal(.3,.1) 入金を記録する 窓口係 1 Normal(.3,.1) 顧客に領収書を返却する 窓口係 1 Normal(.3,.1) 口座残高を確認する 窓口係 1 Normal(.5,.3) 出金を記録する 窓口係 1 Normal(.3,.1) 顧客のステータスを確認する 窓口係 1 Normal(.3,.1) 小切手を確認する 窓口係 1 Normal(1,.5) 現金を数える 窓口係 1 Normal(.5,.5) 小切手を印刷および発行する 窓口係 1 Normal(1,.5) 新規口座を開く 窓口係 1 Normal(15,6) 銀行小切手を発行する 到着（ソース）は、2 つの方法のいずれかでモデリングできます。1 つは、顧客の種 類ごとに別々の到着ノードをモデリングする方法、もう 1 つは、到着ノードを 1 つに し、異なるアクティビティの種類を確率によって表す方法です。いずれの表現方法 にも、複雑さまたは正確さにおける長所があります。ここでは、各取り引きごとの確率 を設定した単一のノードで到着を表すことにします。 まず、到着率を Normal (1.2, 0.3)で定義します。この式は、何らかの取り引きを行う 顧客が 1.2 分おきに到着することを意味します。時間によって到着率が変わる場合 は、リソースの可用性を定義したときと同じように、到着率とその到着率が有効な時 間帯とからなる表を作成できます。 以下の表によると、すべての取り引きのうち 40%（.4）が、預け入れです。このうち、 小切手のみによる預け入れが半分、30%が少額の預け入れ、20%が多額の預け入 れです。ほかの種類のアクティビティについての確率も同様な値で示してあります。 アクティビティ ベースの原価計算およびパフォーマンス メトリクス 5–9 シミュレーション 総合アクティビティの種類 詳細な種類 確率 .40 顧客の口座へ入金する 小切手のみ .50 少額の入金 .30 多額の入金 .20 .25 顧客の口座から出金する 少額の出金 .75 多額の出金 .25 顧客の口座から口座に振り込む） .15 銀行小切手を発行する .15 出金 .80 現金 .20 .05 新規口座を作成する キューの動作を定義するためにモデル作成者は、物理的な実装についていくつか の選択を行う必要があります。たとえば、総合アクティビティの種類ごとに独自の キューを設けるのか、キューを 1 つだけにするのか、またはその中間の形態にする のかです。ここでは、キューは 1 つであるとします。 キューの動作を記述した次の表では、キューの収容能力を無制限にしています。た だし、キューの収容能力を制限することは、キューが長すぎるために顧客を失うこと がないかどうか、つまり行列が長すぎて待たないで帰ってしまう顧客がいるかどうか を調査するために便利な場合があります。 キュー名 動作 収容能力 到着キュー FIFO 0 最後に、重要な各コンポーネントについて、どの情報を記録するのかを特定する必 要があります。監視する出力変数としてどの変数を選択するのかは、構築するモデ ルの目的によって変わります。このモデル例の場合に最もはっきりした測定項目は、 行列にいる顧客の待ち時間および待ち行列（キュー）の長さです。ただし、平均と標 準偏差を記録するだけでは不充分です。キューのサイズと待ち時間が時間によって どのように変化するのかを知る必要があります。 図 5-6 では、キュー1 を使用するプロセスがキューの伸長に追いついていませんの で、キューはしだいに長くなります。キュー2 のサイズは、一定の範囲内で変化して います。この範囲が許容できない場合、つまり、キューが長くなり過ぎることがたびた びある場合、原因を理解するためのさらなる分析が必要です。ピーク期間の負荷に 追いつくためには、リソースをよりよく割り当てるための仕組みが必要です。キュー3 （および、キュー3 に関連するアクティビティ）は、サプライヤとコンシューマとがスケ ジュールをさらに調整できる場合に、削除の候補となります。 5–10 AllFusion Process Modeler 手法ガイド シミュレーション 図 5-6 3 つのキューの時間によるサイズの変化 ここでは、負荷を処理するために最小限の窓口係と現金計数機の数を特定しようと しているため、この場合、リソースのコストも重要です。無効原価（何もしていないリ ソースのためのコスト）を計算するためには、窓口係が各種類の取り引きを行ってい た時間のほかに、各リソースが遊休状態になっていた時間も知る必要があります。 窓口係が現金計数機での処理が終わるのを待っていた時間も取り込む必要があり ます。これらの情報はすべて、結果を計算するためのシミュレーションに式を作成す ることによって記録します。 シミュレーション実験の管理 シミュレーションは、複数回実行します。より正確なパフォーマンスの表現を得るた めに、同じモデルを複数回シミュレーションすることがあります。また、同じモデルを 基に、現金計数機の個数など、1 つの変数を操作しながら実験を複数回実行します。 次の表では、最少人数の窓口係からシミュレーション実験の実行を始めて、窓口係 を 1 人ずつ増やしています。次に、現金計数機の個数を増やし、もう一度シミュレー ション実験を実行してその効果を調査しています。窓口係の人数と現金計数機の 個数がともに 4 になるまで、窓口係と現金計数機の数、または両方を増やしながら このプロセスを繰り返しています。 アクティビティ ベースの原価計算およびパフォーマンス メトリクス 5–11 シミュレーション 5–12 実験 窓口係 現金計数機 1 1 1 2 2 1 3 2 2 4 3 1 5 3 2 6 3 3 7 4 1 8 4 2 9 4 3 10 4 4 AllFusion Process Modeler 手法ガイド Chapter 6 アクティビティ モデルとデータ モデルの 統合 データ モデリングの概要 アクティビティ モデルで、オブジェクトによって接続されたアクティビティのコレクショ ンとしてシステムをとらえるように、データ モデルでは、リレーションシップで接続さ れたオブジェクトのコレクションとしてシステムをとらえます。データ モデルとアクティ ビティ モデルとは統合でき、関連するアクティビティ モデルを統合するために役立 ちます。モデルを統合すると、統合したモデルで（名前使用の）一貫性や網羅性を 確認できるため、この仕組みは重要です。複数の類似したアクティビティ手法が存 在するように、データ モデリング手法も複数存在します。IDEF1X と情報工学（IE: Information Engineering）がよく使用されます。 エンティティと属性 データ モデルは、アクティビティ モデル同様、ボックスと線で表記します。ボックス は、簡単に理解できます。ボックスの先頭に、対象とするオブジェクトの名前を一覧 にします。オブジェクトをエンティティと呼びます。エンティティ名は常に名詞です。 エンティティの属性をボックス内に記載します。属性は、エンティティの具体的なプ ロパティです。属性名も名詞です。属性名では、エンティティをより詳細に記述しま す。 データは通常、名前の付いた 1 つ以上の列のある一連の行であり、ちょうどスプレッ ドシートのように記述します。例として、｢顧客｣エンティティを考えます。それぞれの データをそれぞれ 1 つのフィールド、つまり属性に格納します。たとえば、名前、都 市、州などが属性名になります。1 つの顧客インスタンスを 1 つのデータ行に格納し ます。行全体のコレクションをテーブル、または エンティティ と呼びます。この例の ｢顧客｣は、エンティティ名です。 アクティビティ モデルとデータ モデルの統合 6–1 データ モデリングの概要 エンティティ名（顧客）はエンティティ ボックスの先頭に配置します（図 6-1）。エン ティティ｢顧客｣は複数の顧客を表しますが、エンティティ名は常に単数です。また、 エンティティ名は通常、常にすべて大文字で記述します。エンティティの属性が、 ボックス内に一覧表示されます。属性は、水平の線によって、プライマリ キー属性と、 属性の 2 種類に分けられていますプライマリ キー属性は、エンティティ ボックスで 線より上のプライマリ キー エリアと呼ばれる部分に表示されます。一方、属性は、エ ンティティ ボックスで線より下の非キー エリアに表示されます。1 つのエンティティで は、プライマリ キー属性の 1 組で、エンティティの 1 つのインスタンス、たとえば 1 人 の顧客を一意に特定する必要があります。プライマリ キーとして適当な属性の組み 合わせが簡単に見つからない場合、単独で ID として機能する属性を追加すること がよくあります。この例を図 6-1 に示します。プライマリ キー属性は、顧客 ID として あります。属性名は常に単数形にし、通常、最初の文字を大文字で記述します。 図 6-1 データ モデル エンティティ リレーションシップ エンティティ同士は、リレーションシップで関連付けます。たとえば、顧客からの注文 すべてについての情報を格納する｢注文｣というエンティティがあるとします。リレー ションシップ動詞句｢出す｣で｢顧客｣と｢注文｣を関連付けます（図 6-2）。このリレー ションシップは、「顧客が注文を出す」という文として読むことができます。リレーショ ンシップ動詞句は、単数形にし、すべて単数形で記述します。 図 6-2 のリレーションシップを、通常、親対子リレーションシップと言います。1 人の 親に子が複数いることがあるように、1 つの親、ここでは｢顧客｣が、複数の｢注文｣を 行います。｢注文｣エントリには、顧客 ID 属性も表示されています。親エンティティの プライマリ キーが、リレーションション シップに伴って子エンティティに移動します。 これによって、注文を行った顧客が特定できます。子エンティティでは、移動された 属性を、まとめて、外部キーと言います。 6–2 AllFusion Process Modeler 手法ガイド データ モデリングの概要 カーディナリティ ところで 1 人の｢顧客｣は、｢注文｣を何回まで行うことができるでしょうか。この例の場 合、おそらく「可能な限り」です。カーディナリティでは、リレーションシップに含まれ る子および親の数ついて記述します。まだ注文していない顧客は、実際に顧客とい えるでしょうか。答えが「はい」なら、｢出す｣リレーションシップは、「1 人の顧客が 0 回以上の注文を出す）」と読めます。このリレーションシップを図 6-2 に示します。 図 6-2 1 対 0 以上のカーディナリティ 答えが「いいえ」なら、｢出す｣リレーションシップは、「１人の顧客が 1 回以上の注文 を出す」と読めます。このカーディナリティをもう 1 方から区別するために、リレーショ ンシップの子側にあるボールの横に、大文字の「P」が表示されます。この例を図 6-3 に示します。 図 6-3 1 対 1 以上のカーディナリティ 1 対 0 または 1 のリレーションシップ カーディナリティの場合は「Z」が表示されます。 個数がはっきり決まっているカーディナリティの場合は、その数が表示されます。 アクティビティ モデルとデータ モデルの統合 6–3 データ モデリングの概要 識別リレーションシップと非識別リレーションシップ 図 6-2 の｢注文｣エンティティで、｢顧客 ID｣は、ただの属性として表示されています。 しかし、親のプライマリ キー属性を子のプライマリ キーの一部とする必要がある場合 があります。この例を図 6-4 に示します。｢商品項目｣のプライマリ キーは、実際に、 ｢注文｣エンティティの｢注文 ID｣と｢製品｣エンティティの｢製品 ID｣という、外部キー のみで構成されています。｢商品項目｣エンティティ ボックスの角は、このエンティ ティのプライマリ キーがほかのエンティティに依存していることを強調するために、 丸くなっています。｢注文｣と｢商品項目｣のリレーションシップおよび｢製品｣と｢商品 項目｣のリレーションシップは、親エンティティのプライマリ キーが子エンティティの 個々のインスタンスを識別するために機能しているため、識別リレーションシップと 呼ばれます。識別リレーションシップは、非識別リレーションシップと区別するために 実線で表示されます。非識別リレーションシップは破線で表示されます。 図 6-4 識別リレーションシップと非識別リレーションシップ 6–4 AllFusion Process Modeler 手法ガイド データ モデリングの概要 オプション リレーションシップ 識別リレーションシップは、常に必須です。つまり、子エンティティの各インスタンス は、親エンティティのインスタンスの 1 つと関連付けられている必要があります。関連 付けないと、子のプライマリ キーの一部または全体が null、つまり値を持たない状 態になります。一方、非識別リレーションシップの場合は、子の各インスタンスを親の インスタンスに関連付ける必要のない場合があります。このようなリレーションシップ は、オプション的なリレーションシップであり、リレーションシップの親側の端のひし形 で示されます。 オプションの非識別リレーションシップの例を図 6-5 に示します。サイズが小さいた めビンに入れる製品もあれば、入れない製品もあります。図 6-5 のリレーションシッ プは「0 または 1 つの製品が 0 または１つのビンに入っている」と読めます。最初の 「0 または 1 つ」は、リレーションシップの親側の端にひし形があり、このリレーション シップがオプションであることが示されているためです。2 つ目の「0 または 1 つ」は、 リレーションシップの子側の端に「Z」が表示されているためです。 図 6-5 オプション リレーションシップ アクティビティ モデルとデータ モデルの統合 6–5 データ モデリングの概要 カテゴリ データ モデリングでは、親対子リレーションシップに加え、カテゴリ リレーションシッ プもサポートされています。カテゴリ リレーションシップは、サブタイプ/スーパータイ プ リレーションシップ、または階層リレーションシップとも呼ばれます。単純なカテゴ リを図 6-6 に示します。｢販売可能な項目｣エンティティには、｢製品｣と｢サービス｣の 2 つのサブタイプがあります。これらのエンティティのプライマリ キー属性は同一で すが、キーでない属性が異なっています。まさに、このような状況のためにカテゴリ があります。2 本線が下に引かれた丸は、カテゴリ リレーションシップを示します。カ テゴリ リレーションシップに名前はありません。カテゴリ リレーションシップでは、代わ りに「である」という名前が暗黙で想定され、サブタイプ、カテゴリ リレーションシップ （である）、スーパータイプと読むことができます。たとえば、図 6-6 のリレーションシッ プは「製品は販売可能な項目である」と読むことができます。 図 6-6 コンプリート カテゴリ 実際のところ、図 6-6 はコンプリート カテゴリの例になっています。すべてのサブタイ プが判明していて、ダイアグラムに表示されています。しかし、他方では、いくつか のサブタイプがわからない場合や、いくつかのサブタイプを含める必要がない場合 があります。この場合は、インコンプリート カテゴリを使用します。インコンプリート カ テゴリでは、丸の下の線が一本になります。個々のインスタンスがどのサブタイプに 属するのかは、ディスクリミネータ属性で特定します。親の任意の属性をディスクリミ ネータにできます。 6–6 AllFusion Process Modeler 手法ガイド データの用途 データの用途 アクティビティ モデルでは、エンティティの単一の属性、エンティティとその属性の 一部または全部、または複数のエンティティとその属性の一部または全部に、矢印 を直接マッピングできます。同じ矢印名が 1 組の同じ属性およびエンティティをマッ ピングするため、アクティビティと矢印とのインタフェースは、その特定のアクティビ ティによって使用または作成されるオブジェクトを表します。これらデータを表す矢 印の場合、アクティビティでは、エンティティと属性の個別インスタンスを使用および 作成します。 矢印のルール データをアクティビティで随意に使用することはできません。IDEF0 モデルの 4 種類 の矢印では、作成、検索、更新、削除の 4 つの操作だけを行うことができます。操作 のルールの概要は以下のとおりです。 ■ インプット矢印は、その機能で、アウトプットに変換するオブジェクトまたは消費 するオブジェクトを表します。データを変換するには、必ず取得する必要があり ます。アクティビティ モデルのインプット エンティティは、更新または削除される 必要があります。実際、この条件によって、矢印が実際にインプットであるのか、 それともコントロールであるのかを特定できます。インプット データがアクティビ ティによって作成されることはありません。 ただし、アクティビティで同じエンティ ティのインスタンスを新規作成することはできます。このインスタンスは、アウト プット矢印に記述されます。 ■ コントロール矢印は、正しいアウトプットを作成するために必要な条件を表しま す。データでアクティビティを制御するには、データを取得する必要があります。 コントロール データがアクティビティによって作成、更新、または削除されること はありません。 ■ アウトプット矢印は、アクティビティによって作成または変更（またはその両方）さ れたオブジェクトを表します。更新されたデータを表すアウトプットの場合、その アウトプットは、対応するインプット矢印によって提供されたデータを含んでいる 必要があります。作成されたデータをアウトプット矢印で表すこともできますが、 検索または削除されたデータを表すことは、通常、ありません。 削除（廃棄）さ れたデータを表すアウトプット矢印をモデリングすることはできますし、またモデ リングする必要がある場合があります。 ■ IDEF0 のメカニズム矢印は、 アクティビティを実行するために使用される手段を 表します。メカニズム矢印は、 開発するデータ モデルの要素と対応しません。 ただし、組織のサポート アクティビティをモデリングした、別のデータ モデルの 要素と対応することはあります。 アクティビティ モデルでインプット矢印とした矢印が、データ モデルとの統合によっ て、コントロールであると判明する場合があります。その逆もあり得ます。 アクティビティ モデルとデータ モデルの統合 6–7 データの用途 エンティティと属性のルール エンティティおよび属性を使用するためのルールもあります。このルールの概要を 操作ごとに以下の表に示します。エンティティに対する操作と属性に対する操作と では、小さな違いがあります。エンティティに対して実行可能な操作の頭文字が CRUD です。属性の場合は IRUN です。「データの用途」という代わりにこれらの用 語を使用することがよくあります。 エンティティ 属性 違い 作成 挿入 作成できるのはエンティティのみです。属性値は、その属 性のオーナ エンティティに挿入します。 取得 取得 なし 更新 更新 なし 削除 NULL 字化 文 エンティティ インスタンス（行全体、つまりレコード）のみが 削除できます。属性を削除すると、実際には、値がないこ とを示す NULL が属性値に設定されます。 作成/挿入 エンティティ インスタンスを作成すると、新しい行が 1 行データベースに追加されま す。データベース管理システム（DBMS）に格納するためにレコードは、一定の要件 を満たす必要があります。データ エンティティとデータ エンティティが関連している ことがよくあるため、あるエンティティのインスタンスを追加するには、別のエンティ ティのインスタンスも追加する必要がある場合があります。この追加のエンティティ イ ンスタンスも、対応するすべての要件を満たす必要があります。トランザクションを完 了するためには、複数のエンティティにインスタンスを挿入する必要のある場合もあ ります。 たとえば、挿入されたエンティティがコンプリート サブカテゴリにある総称的な親の 場合、カテゴリ メンバの 1 つにインスタンスを挿入し、カテゴリのディスクリミネータ値 によってどのサブカテゴリを特定するのかを正確に示す必要があります。挿入され たエンティティが、インコンプリート サブカテゴリにある総称的な親の場合、カテゴリ のディスクリミネータの値に応じて、カテゴリ メンバの 1 つにインスタンスを挿入する 必要がある場合があります。依存している子エンティティにインスタンスを挿入する 場合に、外部キー属性の値が、親エンティティのどのインスタンスの値とも一致しな い場合、まず、その値を含んでいるインスタンスを親に挿入する必要があります。 特にリレーショナル DBMS など、DBMS によっては、状況に応じて、ほかのエンティ ティにインスタンスが自動的に追加されたり、レコードの追加が拒否されることがあり ます。この情報は、情報モデルに記述される場合があり、参照整合性と呼ばれます。 個別のビジネス状況に合わせて、DBMS の動作を適切に指定する必要があります。 6–8 AllFusion Process Modeler 手法ガイド データの用途 属性には、特有のルールがあります。いくつかのフィールドは必須であり、値が設定 されている必要があります。少なくとも、エンティティのプライマリ キーに含まれてい る属性、および必須リレーション シップからの外部キーは、これに当てはまります。 プライマリ キーは、単一の行を一意に識別する 1 組の属性であり、この行をほかの テーブルに関連付けるために使用します。外部キーは、ほかのテーブルのプライマ リ キーにこの行を関連付けるための 1 組の属性です。さらに、どの属性もデータ型 が決まっているため、その型に適した値である必要があります。たとえば、DATE 型 の属性には、有効な日付の値を格納する必要があります。 属性によっては、特定の値または値の範囲に、さらに制限されていることがあります。 これは、通常、属性のドメインと呼ばれます。たとえば、性別属性のドメインは男と女 で構成されます。外部キー属性の場合にも同様な制限があります。属性の値は、関 連付けられているエンティティにある値と一致する必要があります。 取得 データ取得に関する特有のルールはありません。モデルを作成する場合、取得した という印を付ける先は、一般的に、エンティティの個別の属性ではなく、エンティティ のほうにします。これは、取得するための印をエンティティの属性のサブセットに付 けない限り、そのエンティティの属性すべてが取得されるという考えを基にしていま す。このアプローチの長所は、用法を設定する作業が短縮されることです。このアプ ローチの短所は、重要な用途情報が隠され、データの用途について適切な分析を 行うことができない可能性があることです。データに用途を記録する作業が完了した かどうかを判断しにくくもなります。 更新 エンティティ インスタンスの更新時に、更新されたレコードは、新規レコードに対す る要件と同じ要件を満たす必要があります。プライマリ キーも更新する更新は、行を 削除してから新しい行を追加することに似ています。（プライマリ キーのルールの 1 つとして、キーを新しくすると、実際は、インスタンスが新しくなるというルールがある ためです。これによってオブジェクトが作成されてから削除されるまでを関連する情 報を失うことなく追跡できます。） 属性には、特有のルールがあります。エンティティ インスタンスの更新時に、各属性 は、（値が変更されて）更新されるか、（値がなくなって）NULL 文字化されるか、影 響がないかのいずれかになります。更新された属性の値は有効である必要がありま す。つまり属性のドメインに含まれている必要があります。属性が NULL 文字化され た場合は、「作成/挿入」で説明したように、NULL 文字化がデータベース スキーマ で許可されている必要があります。 アクティビティ モデルとデータ モデルの統合 6–9 統合プロセス 削除/NULL 文字化 レコード追加時に、ほかのレコードも追加する必要があることがあるように、レコード の削除時にほかのレコードも削除する必要があることがあります。特にリレーショナ ル DBMS など、DBMS によっては、ほかのエンティティにあるインスタンスが自動的 に削除されたり、削除すると参照整合性が失われるときに削除が制限されたりしま す。レコードの新規作成時と同じく、個別のビジネス状況に合わせて、DBMS の動 作を適切に指定する必要があります。 属性には、特有のルールがあります。行を削除すると、その属性値はすべて削除さ れます。個別に指定する必要はありません。行を削除しないで、個々の属性の値に NULL を設定することもできます。NULL は「値がない」ことを意味します。 データ使用レポートの提示 データ使用レポートは、しばしばマトリクス形式で作成されます。属性名を行にして マトリクスの左に配置し、エンティティまたは属性名を列にしてマトリクスの上に配置 します。行と列の交点に、対応するデータの用途（CRUD または IRUN の文字）が 表示されます。このようなレポートは、類似マトリクスと呼ばれます。 統合プロセス アクティビティ モデルを構築する場合は、まず、モデルの目的、つまりそのモデルを 構築する理由を理解する必要があります。モデルの目的は、一般的に、一連の質 問に答えることです。アクティビティ モデルをデータ モデルと統合するときは、モデ ルの目的の一部としてこの事実に注意することが大切です。この事実を文書化して おくと、モデリング チームはこの問題を記憶にとどめることができ、モデル同士に重 大な不一致が発生するのを防ぐことができます。 最初の手順は、（まだ実行していないのであれば）モデルで使用する名前を論理的 にして、標準化することです。たとえば、顧客という単語は、どのアクティビティ モデ ルやデータ モデルで使用される場合であっても、同じ意味を表す必要があります。 この手順は困難を伴い、重大な影響を及ぼすため、モデル構築作業を連携される 必要があります。 「モデリングを実行した後で」モデルを統合することは実質的に不可能です。さまざ まなモデルでの名前の標準化は、モデリング プロセスの一部として実行することが 理想的です。このことは、統合するモデルの種類に関係なくあてはまります。一方、 モデリング チームは、指定のアクティビティ モデルで使用されている名前が、選択 したビューポイントから見たシステムを正確に表していることを確認する必要がありま す。同音異義語（綴りと発音が似ていて意味が異なる 2 つの単語）やその他の関係 を正確に叙述するには、クロスリファレンスを作成します。各モデルを同時に開発す る必要があるわけではありません。むしろ、実行済みの作業の結果を再利用できる ように、モデルの開発順序を調整することが必要です。 6–10 AllFusion Process Modeler 手法ガイド 統合プロセス 2 つ目の手順では、データ モデルのエンティティおよび属性を、アクティビティ モデ ルの矢印と関連付けます。アクティビティ モデルが充分詳細な場合、矢印のいくつ かにはエンティティと同じ名前になります。場合によっては、属性と同じ名前になりま す。すべての矢印ではないものの、大部分の矢印でデータ モデルの複数のエン ティティを統合できます。特に、（コンピュータ システム モデルに対する概念として の）ビジネス モデルのアクティビティ モデルの場合に、このことが言えます。矢印を 束ねると、さらに大きな集合体になります。主に、並行する複数の矢印の数を減らし て、ダイアグラムをすっきりさせる目的で矢印を束ねます。 最後に、一番下のレベルのアクティビティを分析し、矢印に沿ってエンティティに流 入するデータおよびエンティティから流出するデータに対して、データの操作内容 を設定します。 もちろん、データの用途を特定する前に、すべての矢印をエンティティや属性に関 連付けることは、不可欠ではありませんし、実用的でもありません。実際のところ、 データの用途を設定する過程で、そのアクティビティ モデルに関連する、不足して いるエンティティ、属性、矢印が特定されることがよくあります。 データ モデルとアクティビティ モデルを並行して開発し、比較的統合されている場 合、アクティビティ階層の各レベルでこれらの手順を実行できます。こうすると、モデ ル構築工程の最後になって重大な誤りが見つかる可能性が少なくなります。一方、 明らかにこの作業には追加のコストがかかりますので、追加のコストと恩恵とを量りに かける必要があります。 アクティビティ モデルとデータ モデルの統合 6–11 用語集 A-0 コンテキスト ダイアグラム FEO モデル内の最高位のアクティビティを表すダイアグラム。 コンテキスト ダイアグラムは、目的、スコープ、および ビューポイントに関して調査中のプロセスの境界を表し ます。 「説明専用」（FEO）ダイアグラムは、さまざまなビューポ イントを示すため、または IDEF0 構文によって明示的に サポートされていないその他の機能詳細を強調するた めに、プロセスの一部を説明するツールとして使用しま す。FEO には補足説明のテキストで注釈を付けることが できますが、IDEF0 ルールでは必要ありません。 A0I3 トップレベル ダイアグラム IDEF3 モデル内の最高位のレベルを表すダイアグラム。 最上位ダイアグラムは、オブジェクト、ファクト、説明、お よび制約に関して、調査中のワークフローの境界を表し ます。 ABC アクティビティ ベースの原価計算。アクティビティのコス トを捕捉し、分析するためのテクニックです。作業センタ のコストが識別され、アクティビティに割り当てられます。 通常、親アクティビティは関連するすべての子アクティビ ティのコストを統合します。 AS-IS モデル ビジネスまたは組織が現在どのように機能するかを示す モデル。 BPX AllFusion ERwin Data Modeler にエンティティと属性情 報をエクスポートするために使用される AllFusion PM ファイル形式です。 CRUD データベース エンティティのインスタンスに対して実行 できる処理の頭字語（Cretae（作成）、Read（読み取り）、 Update（更新）、および Delete（削除））。 DFD データ フロー ダイアグラム（Data flow diagram）。データ 処理システムのグラフィカルな表現（フローチャート）で あり、システム内のデータおよびこのデータを処理また は変換するアクションを記述します。 Go-To レフェラント（IDEF3） 複数ページにわたるダイアグラムを可能にし、ダイアグラ ム間のループやダイアグラム内における前の UOW へ のループバック（戻り）をサポートするレフェラントです。 参照されるプロセスの完了に続いて開始される UOW ま たはジャンクションを示します。 ICOM IDEF0 モデル内に取り込まれる情報のカテゴリ（Input （入力）、Output（出力）、Control（コントロール）、または Mechanism（メカニズム））の頭字語です。ICOM は、原 料から完成品までや、消耗品リソースと消費されないリ ソース、機械、およびアクティビティを抑制するルールま で、アクティビティに影響するさまざまなオブジェクトを表 します。「アクティビティは、コントロールを受けた状態で、 メカニズムによって入力を出力に変換します。」 IDEF0 一連の相互に関係するアクティビティと各アクティビティ に必要な情報やリソースとして、ビジネス ファンクション のグラフィカルな説明をサポートするモデリング手法。 IDEF0 モデルは、機能を記述し、再構成することによっ て、効率と効果を向上することを目的としています。 IDEF1X エンティティ、属性、およびエンティティ リレーションシッ プなど、論理データ構造のグラフィカルな説明をサポー トするモデリング手法。 IDEF3 システムまたはビジネスで何を実行するのかをグラフィカ ルに説明できるプロセス モデリング手法です。IDEF3 に は、プロセス フロー ネットワーク ダイアグラムとオブジェ クト ステータス遷移ネットワーク ダイアグラムの両方の開 発についてのルールがあります。 用語集–1 IDL インプット IDEF0 モデル データのインポートおよびエクスポート用 の標準的なファイル形式です。 IDEF0 アクティビティ ボックスの左側に入る矢印で、出 力を生成するためにプロセスによって変換または消費さ れる材料または情報を表します。 IRUN データベース エンティティの属性上で実行できるアク ション（挿入、読み取り、更新、および NULL 文字化）の 頭字語。 Note レフェラント（IDEF3） インタフェース データまたはオブジェクトが渡される共有されている境 界。つまり一方から他方へデータまたはオブジェクトを 渡すことを目的とした 2 つ以上のモデル コンポーネント 間の接続。 ワークフロー オブジェクトに関連する追加の情報です。 OSTN ダイアグラム 個別のプロセスまたはワークフローを介してオブジェクト の状態をモデリングするために使用する Object State Transition Network ダイアグラムの頭文字です。 TO-BE モデル エンティティ データベース テーブルの論理表現。エンティティは、 AllFusion PM または AllFusion ERwin Data Modeler で 作成できます。 オブジェクト（IDEF3） IDEF0 アクティビティ ボックスの右側から出る矢印。アク ティビティによって生成される材料または情報を表しま す。 UOW プロセスに参加する物理的オブジェクトを一覧す る IDEF3 詳細ドキュメントのセクション。UOW のオブ ジェクト説明では、オブジェクトの種類が（プロセスを実 行する）エージェントであるのか、プロセスによって変更 されるオブジェクトであるのか、プロセスを開始させるたり プロセスによって変換されることなくプロセスに関係する オブジェクトであるのか、またはプロセス中に作成または 破壊されるオブジェクトであるのかを定義する必要があ ります。 UOW オブジェクト レフェラント（IDEF3） プロセスが将来どのように動作するかを示すモデ ル。 アウトプット Unit of Work（作業単位）の IDEF3 頭字語。（動作の単 位とも呼ばれる）UOW では、ワークフロー モデル内の システムまたはビジネスで実行されるプロセス、アクショ ン、決定、またはその他のプロシージャを記述します。 （ビデオ店の例におけるビデオ テープなど）UOW 内の 特定のオブジェクトまたはリレーションの関連を強調する ためのレフェラントです。 オフページ参照 UOW レフェラント（IDEF3） UOW の定義を複製せずに事前定義済みの UOW を示 すレフェラントです。これによって、事前定義済みの UOW のもう 1 つのインスタンスが、（ループ バックなし で）プロセスの特定のポイントで発生していることを示し ます。 1 つのアクティビティからモデル内の別のダイアグラム内 の関連付けられたアクティビティへの参照（プロセス番 号 2.4 とプロセス番号 5.3.3 との間など）です。 親アクティビティ 2 つ以上のサブプロセスを含む子ダイアグラムに分解さ れるアクティビティ。 アクティビティ データやリソースを処理または変換するアクションを説 明する動詞句です。たとえば、Process Orders（注文を処 理する）や Run Video Store（ビデオ店を経営する）など です。IDEF0 モデルは非効率なアクティビティ（コント ロールまたは出力、あるいはその両方を持たないアク ティビティ）を強調し、これによってビジネス プロセスのリ エンジニアリング作業を支援します。 また、IDEF3 アクティビティは振る舞い単位または UOW とも呼ばれ、システムまたはビジネスで実行されるプロセ ス、アクション、決定、またはその他の手順を説明します。 DFD アクティビティはデータを処理または変換するアク ションを表します。 用語集–2 AllFusion Process Modeler 手法ガイド 外部参照 データのソースまたは宛先であるが、データ フロー ダイ アグラム（DFD）のスコープ外にある場所、エンティティ、 人、または部署です。外部参照は「債務勘定」のように 会社の内部の場合もあれば、「ベンダ」、「銀行」のように 外部の場合もあります。これは、Gane および Sarson の 表記法における外部エンティティの概念に似ています。 カラー パレット 一連の関連するダイアグラム内で色の使用を標準化す る、AllFusion PM 内で定義されている一連の色です。 機能ファンクション コントロール矢印 何を実行する必要があるかを説明した動詞または動詞 句によって識別されるアクティビティ、プロセス、または 変換（IDEF0 ボックスでモデル化）。 アクティビティが実行されるかどうか、またはいつ、どのよ うに実行されるかについてアクティビティへの制約（ルー ル、規制、ポリシー、手順、標準など）を表す、IDEF0 ア クティビティ ボックスの上辺から入る矢印です。コント ロールとしてモデルされているデータまたはオブジェクト は機能によって変換されません。コントロール矢印は IDEF0 ボックスの上辺に関連付けられます。 境界線矢印 アクティビティとダイアグラムの境界に走る矢印。 コール矢印 モデル ライブラリ内の関連付けられたモデルまたは既 存のモデルを参照する IDEF0 ダイアグラム上の矢印。 コール矢印は、アクティビティ ボックスの下辺から出て、 ダイアグラムの最下部の境界まで延びる、一種のメカニ ズム矢印です。 作成者 子ダイアグラム 四角いトンネル 1 つの親アクティビティ内の 2 つ以上のサブプロセスを 示すダイアグラム。子ダイアグラムは分解ダイアグラムと も呼ばれます。 未解決矢印を表わすために使用されるシンボルです。 未解決矢印は、親ダイアグラム内に対応する参照がな い境界矢印を子分解内に作成するか、子分解内に対 応する参照がない境界矢印を親ダイアグラム内に作成 した場合に発生します。これは、別のダイアグラム上で 矢印を続けるか（これを解決する）、または関連ダイアグ ラムで矢印をオフのままにしておくか（これをトンネルす る）をモデル作成者に表示する役割を果たします。 キット レビューアのコメントを介してモデルのフィードバックを 収集するための方法として使用される IDEF0 モデルの 印刷済みダイアグラム、サポート テキスト、および用語 集のコンプリート セットです。また、ダイアグラム枠の最 上部セクションです。 結合 IDEF0 矢印セグメント（使用するソースからの）が 1 つ以 上の他の矢印セグメントとマージし、1 つの矢印セグメン トを形成するジャンクション。矢印セグメントの意味を束 ねることを意味します。 コンテキスト ダイアグラム モデル内の最高位のアクティビティを表すダイアグラム。 コンテキスト ダイアグラムは、目的、スコープ、および ビューポイントに関して調査中のプロセスの境界を表し ます。 AllFusion PM ダイアグラム、または元の IDEF0、IDEF3、 または DFD ドキュメントにアクティビティ、矢印、データ ストア、または外部参照情報を入力した人、部署、また は事業の名前です。 ジグザグ線 矢印名を IDEF0 ダイアグラム内の矢印記号に関連付け るために使用できる小さいギザギザの線です。これはモ デル ノートをダイアグラムのコンポーネントに関連付ける ためにも使用できます。 ジャンクション プロセスの分岐を示す IDEF3 構造。AND、OR、および EXCLUSIVE OR 条件を表すためにさまざまな種類の ジャンクションを使用でき、関連するアクティビティ同士 のタイミング（開始または完了の同期または非同期）をさ らに強調できます。 ジャンクション レフェラント（IDEF3） アクティビティを完了するための実際のコストの一部とな る、定義済みの事業単位、機能、または条件（労働力、 材料、製造、管理、オーバーヘッドなど）です。 特殊な制約セットをジャンクションに関連付けるレフェラ ント。つまり、追加のファクト、制約、またはジャンクション の動作方法を説明する決定ロジックが含まれているジャ ンクションに詳細説明を関連付けます。 子ボックス スコープ コスト センタ 子ダイアグラム上のボックス。 コンテキスト ファンクション（またはダイアグラム上の一連のファンク ション）が動作する直接的な環境。 モデルが網羅するサブジェクトの幅（外側縁）および深 度（詳細のレベル）。 ステータス IDEF0 モデル、ダイアグラム、アクティビティ、または矢 印の現在の完了状態。標準的なオプションは、作業、ド ラフト、推奨、発行などです。 用語集–3 サブプロセス データ フロー より大きなプロセスに関連して発生するプロセス。 データ フロー ダイアグラムのシンボル間を結ぶ矢印で あり、データの流れを示します。各矢印にはソースと宛 先の両方が必要です。IDEF0 矢印（ICOM）とは異なり、 DFD 矢印はアクティビティのどの側面にも出入りできま す。 消去 未使用のアクティビティ、データ ストア、外部参照、また は矢印名をモデル ディクショナリから削除する AllFusion PM アクションです。 詳細レフェラント（IDEF3） ジャンクションの詳細を追加するレフェラント。ジャンク ションについての追加のファクト、制約、および決定論 理を説明できます。 制約（IDEF3） プロセスを開始、継続、または終了するために満たす必 要のある条件など、UOW プロセスに対する制限要因に ついての条件を一覧にした IDEF3 詳細文書のセクショ ンです。通常、制約とは、UOW の実行前、実行中、また は実行後に UOW に影響する要因、または実行するた めに常に存在する必要のある要因や存在してはならな い要因を説明することによって、アクティビティをバインド したりその発生を抑制する UOW についてのファクトで す。 データ フロー ダイアグラミング ビジネスまたは組織内の情報の移動と処理を表すため に使用される手法。通常はアプリケーションの分析と設 計に使用されます。 データ ストア データベース テーブルまたは AllFusion ERwin Data Modeler エンティティとの間のデータの流れを示すため に DFD で使用する表現です。 トンネル矢印 意図的に省略した矢印を示すシンボルです。（意図的 に省略した矢印とは、親ダイアグラムにあっても子分解 には表示しない矢印や、子分解にはあっても親ダイアグ ラムには表示しない矢印を指します。）明確化するため には矢印を省略できます。 内部矢印 説明（IDEF3） テキストによる UOW の説明を格納する IDEF3 詳細ド キュメントのセクションです。この説明は、次に、その UOW に対する用語集エントリとして使用されます。オブ ジェクト、ファクト、および制約リスト内の情報を詳述しま す。 ダイアグラムにあるボックスに両端（ソースと使用）が接 続されている入力矢印、コントロール矢印、または出力 矢印です。 ノード番号 ダイアグラムの親アクティビティの数に対応したダイアグ ラム番号。 測定単位 アクティビティの存続期間または頻度を計算するために 使用される単位。測定単位は、時間とコストの情報につ いて指定されます。 ソース アクティビティ、矢印、データ ストア、または外部参照に ついての情報を提供した人、部署、またはビジネスの名 前です。 ノード ツリー ダイアグラム IDEF0 モデルの階層ダイアグラム、またはアクティビティ およびアクティビティ間のリレーションシップ（親対子、兄 弟）を示すモデルの一部。ノード ツリーを使用するとモ デル全体を概観できます。ノード ツリーでは、階層の最 上位に、コンテキスト ダイアグラム アクティビティに対応 するノードが表示され、そのコンテキスト アクティビティを 分解した複数レベルの子分解によってツリーのそのほ かの部分が構成されます。 存続期間 アクティビティを完了するために必要な時間の長さ（平 均時間）。 ダイアグラム IDEF0、IDEF3、または DFD モデルの一単位。アクティ ビティの詳細を表す IDEF0 モデルです。IDEF0 モデル は、コンテキスト、分解、ノード ツリーおよび説明専門 （FEO）の基本の 4 種類のダイアグラムで構成されます。 ファクト（IDEF3） プロセス中のオブジェクト間で維持されるオブジェクト プ ロパティとリレーションシップなど、UOW または UOW に 参加するオブジェクトについての表現を一覧した IDEF3 詳細ドキュメントのセクション。UOW についてのファクト には、期間、頻度、コストなどの UOW プロパティも含め ることができます。 ファンイン 1 つのプロセスへの複数の処理パスの結合または集合 を説明するジャンクション。 用語集–4 AllFusion Process Modeler 手法ガイド ファンアウト メカニズム矢印 複数の代替処理パスへのプロセスの分割または分散を 説明するジャンクション。 アクティビティを実行するために使用される人、マシン、 またはその他の消費できないリソースを表す IDEF0 アク ティビティ ボックスの下部に入る矢印。コール矢印の特 別なケースも含みます。 番号 C ダイアグラムを一意に識別し、その履歴を追跡するため に使用される年代順の作成番号。 C-number は、ダイア グラムの個別のバージョンを指定するための詳細参照 情報として使用できます。 目的 プロセスがなぜ調査中なのか、モデルが何を示している か、そして読者が何をモデルで実行できるかの説明。 ビジネス ファンクション モデル 業務によってどのようなアクティビティが遂行されるかを 説明するために使用される用語。IDEF0 ではアクティビ ティと ICOM をサポートする表記法を介したビジネス ファンクションのモデリングをサポートできます。 ビジネス プロセスまたはビジネス ファンクションを十分に 説明するために必要な一連のダイアグラムとサポート テ キストまたは用語集。モデルは、定義済みのスコープ、 目的、およびビューポイントを持ちます。 ビジネス プロセス モデル ディクショナリ 業務でアクティビティをどのように実行するのかを説明 するために使用される用語です。IDEF3 では、先行条 件およびアクティビティのタイミングを記述できる表記法 を用いて、ビジネス プロセスのモデリングが支援されま す。 モデル内の IDEF0 または DFD オブジェクトの名前、ス テータス、作成者、定義、注釈、ソース、色、およびフォ ントをなどの情報を格納する AllFusion PM 構造です。 ビューポイント プロセス モデルを開発するための基礎および視点とな る、役職、部署、または役割（部長、現場監督、機械工 など）です。 頻度 アクティビティがその親アクティビティのオカレンスごとに 発生する平均回数。 矢印 IDEF0 ダイアグラムの矢印は、アクティビティの Input（イ ンプット）、Control（コントロール）、Output（アウトプット）、 または Mechanism（メカニズム）（ICOM）を表します。 IDEF3 では、矢印はアクティビティ間の順序または優先 （実線で描画）、リレーションシップ（破線で描画）、また はオブジェクト フロー（実線の両方向矢印で描画）を表 します。DFD では、矢印はアクティビティ、データ ストア、 外部参照間のデータの流れを表します。 矢印関連 分解 モデル化されたファンクションをそのコンポーネント ファ ンクションに分割すること。 IDEF0 矢印に設定される、エンティティまたは属性、ま たはその両方の CRUD データまたは IRUN データです。 矢印セグメント 分解する アクティビティをその合成手順またはサブプロセスに分 割すること。 矢印の一部分を表します。分岐した矢印（分割された矢 印）の先端、中央、または末尾です。 矢印スタブ 分解ダイアグラム 親アクティビティの 2 つ以上のサブプロセス（兄弟アク ティビティ）とそれらに関連付けられている矢印を示すダ イアグラム。分解ダイアグラムは子分解とも呼ばれます。 不完全なオフページ リファレンスまたは未解決矢印の 存在を示すために AllFusion PM で描画される矢印の 部分です。 ユーザ定義プロパティ 未解決矢印 相当する参照が親ダイアグラム内にない子分解内の境 界線矢印、または相当する参照が子分解内にない親ダ イアグラム内の境界線矢印。 ユーザ定義プロパティ（UDP）は、業務固有の情報をア クティビティまたは矢印に関連付けるためにモデル作成 者が作成します。AllFusion PM では、さまざまな種類の UDP がサポートされています。たとえば、組織に関する 情報や自動化のレベルについての情報などを格納する ためのプルダウン リスト、マルチメディア参照を設定する コマンド UDP、重要な成功因子などの情報を格納する ためのテキスト リストなどがあります。 用語集–5 類似度マトリックス リンク システム分析とシステム設計に役立つテーブルで、1）モ デル内の矢印、2）モデル内の矢印に関連付けられたエ ンティティと属性、および 3）各矢印の IRUN または CRUD 割り当てを一覧します。 IDEF3 矢印です。先行リンク（実線矢印）は、オブジェク トのフローやアクティビティ間の先行など、アクティビティ （UOB）間の重要な制約リレーションシップを表します。 リレーショナル リンク（点線矢印）は、アクティビティ間の リレーションシップを示します。オブジェクト フロー リンク （両方向矢印）は、オブジェクトの 2 つのアクティビティ への参加を強調表示します。 リーフ コーナ 関連する分解ダイアグラムがないことを示す、IDEF0 ア クティビティの左上隅にわたって対角線上に描かれる線。 レフェラント ループ、オフページ参照、ジャンクションに対する制約、 またはプロセス フロー ダイアグラムとオブジェクト状態遷 移ダイアグラム間の参照をサポートするために IDEF3 で使用される外部参照です。 用語集–6 AllFusion Process Modeler 手法ガイド 索引 英数字 ABC. 「アクティビティ ベースの原価計算」を参照 AS-IS モデル, 3-1 CRUD, 6-8 C-番号, 3-17 DFD. 「データ フロー ダイアグラム」を参照 FEO ダイアグラム, 3-18, 3-19, 3-24 ICAM, 1-4 ICOM, 3-22 IDEF0, 1-4, 3-1, 4-1 IDEF3 と併用, 2-1, 3-14 アクティビティ, 3-3 アクティベーション, 3-13, 3-14 インタフェース, 3-4 階層, 3-21 境界, 3-4 先行, 3-6 フィードバック, 3-7, 3-8 優先度, 3-7 キット, 3-2, 3-17 コンテキスト, 3-16 作成者と読者のサイクル, 3-17 スコープ, 3-2, 3-19 ダイアグラム, 3-15 FEO, 3-18, 3-19, 3-24 境界, 3-15 コンテキスト, 3-3, 3-19 ステータス, 3-16 ノード ツリー, 3-23 ビューポイント, 3-2, 3-19 目的, 3-2, 3-19 モデル ビューポイント, 3-18 モデルの構築, 3-18 矢印, 3-5 アウトプット, 3-4, 3-6, 3-20 インプット, 3-5, 3-20 コール, 3-11 コントロール, 3-4, 3-5, 3-20, 3-21 束ねる, 3-8, 3-12 テーブル, 3-4 トンネル, 3-12 名前, 3-5 分岐と結合, 3-8 メカニズム, 3-4, 3-6, 3-20 ユーザ, 3-2 IDEF1X, 6-1 IDEF3, 1-4, 1-5, 3-1, 3-22 IDEF0 と併用, 2-1, 3-14 UOW, 2-3 アクティビティ, 2-3 順序, 2-17 同時並行性, 2-17 番号, 2-3, 2-15 分解, 2-15 アクティビティ 番号, 2-16 オブジェクト フロー リンク, 2-5 時間的先行リンク, 2-4, 2-6 シナリオ, 2-2, 2-16 ジャンクション, 2-8, 2-17 AND, 2-9 OR, 2-10 組み合わせ, 2-13 同期, 2-11 排他 OR, 2-9 非同期, 2-11 ファンアウト, 2-8 ファンイン, 2-8 ペアリング, 2-13 スコープ, 2-2, 2-16 説明, 2-5 ダイアグラム, 2-2 ビューポイント, 2-2, 2-16 ユーザ, 2-2 リレーショナル リンク, 2-5 リンク, 2-4 レフェラント, 2-14, 2-17 IDEF0 ダイアグラム ノード番号, 3-17 索引–1 Integrated Computer-Aided Manufacturing, 1-4 外部キー, 6-2 IRUN, 6-8 カテゴリ, 6-6 インコンプリート, 6-6 コンプリート カテゴリ, 6-6 NULL 文字化, 6-10 SADT, 1-4 UOWUOW, 2-3 キュー, 5-4 境界矢印, 3-22 経営戦略, 1-5 あ 原価作用因, 5-2 アクティビティ, 1-2 IDEF0 での定義, 3-3 アクティベーション, 2-9, 2-10, 3-13, 3-14 親, 2-3 階層, 5-3 境界, 1-3 継続時間, 5-4 子, 1-3 先行, 3-6 データの用途, 6-7 同時並行性, 2-17 名前, 2-3, 3-3 番号, 2-3, 2-15, 2-16, 3-21 フィードバック, 3-7, 3-8 分解, 2-15 並列, 2-5 ボックス, 1-2, 3-3 モデリング, 1-4, 3-1 モデル, 1-2, 1-5 矢印の関連付け, 6-7 優先度, 3-7 リーフレベル, 3-21, 5-3 アクティビティ 順序, 2-17 アクティビティ ベースの原価計算, 5-1 エンティティ, 6-1 インスタンス, 6-1 更新, 6-9 削除, 6-10 作成, 6-8 取得, 6-9 使用ルール, 6-8 ボックス, 6-1 親アクティビティ, 2-3 更新, 6-9 構造化設計技法, 1-4 構造化分析設計, 1-5, 4-5 コスト オブジェクト, 5-2 コスト センタ, 5-2 さ 削除, 6-10 作成, 6-8 作成者, 2-1, 2-16, 3-16, 3-17 シナリオ, 2-2, 2-16 ビューポイント, 2-16 シミュレーション, 5-3 MTBF, 5-7 宛先, 5-4 キュー, 5-4, 5-10 ソース, 5-4, 5-9 データ フロー ダイアグラム, 5-4 統計的確率, 5-7 統計的標準偏差, 5-7 統計的平均, 5-7 ファシリティ, 5-4 モデル, 2-1 取得, 6-9 情報モデル, 1-5, 6-1 スコープ, 2-2, 2-16, 3-2, 3-19, 4-2 制約, 2-5, 2-7 挿入, 6-8 か カーディナリティ, 6-3 外部エンティティ, 4-1, 4-3 索引–2 AllFusion Process Modeler 手法ガイド 属性, 6-1 NULL 文字化, 6-10 更新, 6-9 取得, 6-9 使用ルール, 6-8 挿入, 6-8 プライマリ キー, 6-2 ま 目的, 3-2, 3-18, 4-2 た AS-IS モデル AS-IS, 1-5 TO-BE モデル TO-BE, 1-5 データ ストア, 4-1, 4-4, 5-4 データ フロー ダイアグラム, 1-4, 3-1, 4-1 アクティビティ, 4-2 番号, 4-6 イベント パーティショニング, 4-5 外部エンティティ, 4-1, 4-3 番号, 4-6 ダイアグラム コンテキスト, 4-2 データ ストア, 4-1, 4-4, 5-4 番号, 4-6 データ フロー, 4-3 矢印, 4-3 分岐と結合, 4-4 データ モデル, 6-1 ドメイン エキスパート, 1-5, 2-1 トンネル, 3-12 な ノート, 3-16 ノード ツリー, 3-23 ノード番号, 3-17 モデル AS-IS, 1-5, 3-1 TO-BE, 1-5 アクティビティ, 1-2, 1-5, 3-1, 4-2 シミュレーション, 2-1, 5-3 情報, 1-5 ダイアグラム, 1-3 データ, 6-1 プロセス, 2-1 や 矢印, 1-2 アウトプット, 3-6 データ使用ルール, 6-7 アクティビティの関連付け, 6-7 インプット, 3-5 データ使用のルール, 6-7 コール, 3-11 コントロール, 3-5 データ使用ルール, 6-7 データ フロー, 4-3 トンネル, 3-12 分岐と結合, 3-8, 4-4 メカニズム, 3-6 データ使用ルール, 6-7 ユーザ, 2-2, 3-2 は 容量計画、 モデルの使用目的, 1-5 容量計画、 モデルの用途, 2-1 ビジネス機能, 1-2, 3-1 予算計画、 モデルの使用目的, 1-5 ビジネス システム エンジニアリング, 1-5 ビジネス プロセス, 1-2 ら ビューポイント, 2-2, 3-2, 3-18, 4-2 プロセス モデル, 2-1 離散事象シミュレーション, 5-3 分解, 1-3, 3-21 IDEF3, 2-15 リソース 収集、 モデルの使用目的, 1-5 ベンチマーク, 1-5 リレーションシップ, 6-2 オプション, 6-5 親対子, 6-2 カーディナリティ, 6-3 索引–3 カテゴリ, 6-6 サブタイプ/スーパータイプ, 6-6 識別, 6-4 非識別, 6-4 必須, 6-5 リンク. 「矢印」も参照 索引–4 AllFusion Process Modeler 手法ガイド IDEF3, 2-4 オブジェクト フロー, 2-5 時間的先行, 2-4, 2-6 リレーショナル, 2-5 類似マトリクス, 6-10