CRC（クラス責任協力者）モデリングの包括的ガイド
オブジェクト指向（OO）分析の基盤となる原則に基づき、本ガイドはCRCモデリングプロセスを概説する。CRCモデリングは、開発者とユーザーの間のコミュニケーションギャップを埋めるために設計された、非常に効果的で低技術的な手法であり、コードを書く前にビジネス要件が正確に特定され、理解されることを保証する。
1. 主な概念：CRCカードの構造
CRCモデリングは、3つの明確なセクションに分けられた標準のインデックスカードに依存している。各セクションはオブジェクト指向設計の核心的概念を表している。
A. クラス（カードの上部）
クラスは類似したオブジェクトの集合を表す。オブジェクトとは、システムに関連する人物、場所、物、出来事、概念、画面、またはレポートである。
-
命名ルール： 単数の語1つまたは2つを使用する（例：顧客、複数形は使わない（例：顧客たち).
-
例： 配送／在庫システムでは、以下のクラスが含まれる：在庫アイテム, 注文, 注文アイテム, 顧客、および表面住所.
B. 責任（左側の列）
責任とは、クラスが知っていることまたは行うこと.
-
知っていること（データ／属性）： 例： A 顧客 クラスは名前、顧客番号、電話番号を知っています。
-
行うこと（振る舞い／メソッド）： 例： A 顧客 クラスは製品を注文し、注文をキャンセルし、支払いを行うことができます。
C. コラボレーター（右カラム）
クラスが責任を果たすために、別のクラスから情報や支援が必要なときに協働が発生します。
-
例： An 注文 オブジェクトは「合計金額を計算する」責任を持っています。しかし、商品の価格や注文数量は知りません。そのため、最終的な合計を計算するには 協働 と 注文項目 （数量を知っている）および 在庫項目 （価格を知っている）と協働して、最終的な合計を計算しなければなりません。
2. CRCモデリングチーム
成功したCRCセッションには、プロセスがスムーズに進行し、ビジネスロジックを正確に捉えるために特定の役割が必要です。
-
ビジネス分野専門家（BDEs）： システムの実際の利用者（通常、4～5人の現場スタッフ）。日々のビジネス知識を持っています。 注意：経営幹部は一般的にCRCには適していません。上位のユースケースに適しています。
-
ファシリテーター： セッションを運営し、手法を説明し、関連する質問をし、カードの記入が正しいことを確認し、シナリオテストを主導します。
-
筆記係（Scribe(s)）：後方または側面に1～2人の人が座る。彼らは積極的にモデル化は行わないが、小さなインデックスカードに収まらない詳細なビジネスロジックやルールを記録する。
-
観察者：後方に座って参加せずに観察するトレーニーまたはステークホルダー。
3. 6段階CRCモデリングプロセス
ステップ1：チームを編成する
現場のBDEを4～5人、ファシリテーター1人、筆記係1～2人を集める。参加者が必要な時間を確保できるよう、経営陣の支援を確保する。
ステップ2：部屋の整理
-
書き込み可能な表面：ブレインストーミングやプロトタイピング用のフリップチャートまたはホワイトボード。
-
モデリングテーブル：BDEがカードを配置・移動できる、大きな中央のテーブル。
-
筆記係の席：視界が確保できるが、目立たない場所に設置された机。
-
備品：インデックスカード、マーカー、および柔らかくスポンジのようなボール（後にシナリオテストで使用）。
ステップ3：ブレインストーミング
評価せずにアイデアを出し合う。ファシリテーターはビジネスニーズを理解するために、オープンエンドの質問を投げかける。
-
例題：「このシステムは誰のためにあるのか？」「どのようなビジネスニーズをサポートするのか？」「どうすればより速く・安価に・より良くできるか？」「自動化できる単純な作業は何か？」
ステップ4：手法の説明
ファシリテーターは10～15分間、CRCの概念を説明し、壁に定義を明確に表示し、チームがいくつかの例カードを作成するのを指導する。
ステップ5：反復的なCRCモデリング
BDEはテーブルの周りに立ちまたは座り、反復的にモデルを構築する：
-
クラスを特定する：お金の流れを追跡し、レポートや画面を確認し、すぐに3～5つの主要なクラスを特定する。
-
責任を特定する：クラスが知っていること、行うべきことを尋ねる。
-
協力者を定義する：責任を果たすために必要な情報が欠けている人物を特定する。
-
カードを並べる： 重要なステップ。頻繁に連携するカードはテーブル上で近くに配置される。「忙しい」カードは中央に置く。カードを実際に動かすことで、チームは関係性や関連性を視覚化できる。
ステップ6：ユースケースシナリオテスト（「ボールトス」演習）
チームがシステムのワークフローを「演技」することで、モデルの正確性を確認する検証作業である。
-
シナリオを呼び出す：ファシリテーターがユースケース（例：「顧客が注文する」）を説明し、最初の責任カードを持っているBDEにソフトボールを投げる（例：注文).
-
責任を確定する：グループはそのカードがそのタスクを担当していることを確認する。そうでない場合は、カードを更新または新たに作成する。
-
ロジックを説明する：ボールを持っているBDEが、ステップバイステップのビジネスロジック（疑似コード）を記録者に説明する。
-
協働する：BDEが他のクラス（例：在庫アイテム）からの情報が必要な場合、そのカードを持っているBDEにボールを投げる。そのBDEが自身のロジックの部分を説明する。
-
ボールを戻す：タスクが完了すると、ボールは前の人物に投げ返され、最終的にファシリテーターに戻り、次のシナリオを開始する。
4. CRCがSDLCにどのように位置づけられるか
CRCモデリングは孤立したものではない。それは、要件から設計、コードへと進む「大規模な直列性」と、モデル間を繰り返し往復する「小規模な反復性」を持つ、広範なオブジェクト指向モデリングプロセスの一部である。大規模な直列性（要件から設計、コードへと移行する）および小規模な反復性（モデル間を往復する）。
-
詳細度：CRCは中間にある。まずは ユースケース と UIプロトタイプ、中程度の詳細へ移行するCRCモデル、最後に高精度の詳細へ進むクラス図.
-
成果物が成果物を駆動する：ユースケース図はユースケースによって記述され、それらはシーケンス図によって記述され、最終的にソースコードを駆動する。CRCモデルは直接クラス図作成に活用される。
5. 成功のためのベストプラクティスとヒント
-
議題を送信する：BDEが準備できるように、数日前に議題を配布する。
-
定義を表示する：部屋の前方に大きなCRCカードのレイアウトと定義をテープで貼る。
-
ドメイン用語を使用する：技術用語を避け、BDEが日常業務で使用する正確な言葉を使う。
-
低技術で済ませる：CRC用のツールは選択的である。インデックスカードは安価で持ち運びやすく、非常に効果的である。
-
プロトタイピングを想定する：会議中にフリップチャートに画面やレポートのスケッチを描くことで、ユーザーがシステムを視覚化しやすくなる。
-
複数日を計画する：大規模なシステムには複数の会議が必要である。これは通常で、必要不可欠である。
-
経営陣の支援を得る：コーディングの前にモデリングの価値を理解していることを確認する。
-
現場スタッフを対象にする：CRCは非常に詳細であり、日常的に使用するユーザーにとって最適であり、上級経営陣には向かない。
6. 優位性と課題
優位性
-
専門家が分析を行う：実際に作業を行う人々がモデルを構築する。
-
ユーザーの高い関与：積極的な参加は、ユーザーの満足度と所有感を高めます。
-
障壁を打破する：ユーザーと開発者が並んで作業する。
-
シンプルで脅威感のない：それはただのインデックスカードです。ユーザーは複雑なソフトウェアツールに圧倒されず、『機械』によって自分の仕事が自動化されると感じることもありません。
-
低コストで携帯性がある：数ドルで、トランクバッグに収まる。
-
スムーズな移行：プロトタイピングと完璧に連携し、直接形式的なクラス図へとつながる。
欠点
-
一部の開発者にとって脅威となる：一部の開発者は誤って、自分の技術的知識がユーザーのビジネス知識を上回ると信じている。
-
スケジューリングが難しい：4～5人の主要なユーザーを同じ部屋に集めるには、事前の計画が必要である。
-
カードの限界がある：インデックスカードの束は、大多数の組織にとって受け入れられる正式な納品物ではない。CRCは、形式的なユースケース、プロトタイプ、クラス図とともに補完される必要がある。
結論
アプリケーション開発の最終的な目的は、ビジネス問題を解決すること、新しい技術で開発者の知的好奇心を満たすことではない。CRCモデリングは、開発者がユーザーと協力して作業するよう強いる。とユーザーと協力するよう強いる。低技術的で、非常に協働的な環境を活用することで、コードが1行も書かれる前にも、ビジネス要件を正確に把握・検証・洗練できる。
