これだけモデリングとは
**「これだけモデリング」**とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。
デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。
そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。
- エンタープライズアジャイル時代のリーンモデリング（slideshare）
これだけモデリングとは、
- 誰が？ ー 情報システム部門の人（と開発の人が共に）
- いつ？ ー システム開発の前段階、すなわち「要求開発」の場面で
- 何のために？ ー 要求の引き出しと共通理解を作るために
- 何を使って？ ー UMLから選んだ「少数の図」と「少数の記法」で
- どうする？ ー モデリングする（可視化して、整理して、理解して、合意する）
というものです。UMLは13種類も図がありますが、全部使う必要は全くありません。
クラス図、シーケンス図、アクティビティ図、ユースケース図を使って、システムの３つの側面を記述します。
- 何をするか ー サービスモデル(ビジネスユースケース)
- 何がどうあるか ー 静的モデル(概念クラス図)
- どう動くか ー 動的モデル(シーケンス図、アクティビティ図)
これだけモデリングの原則
これだけモデリングで大切なことは、
- 書き過ぎないこと。
- 使い捨てでもよい、と割り切る。
- 無理にトレーサビリティを取ってメンテしようとしないこと。
- 抽象的すぎるモデルを描かないこと。（アナリシスパターンを描いてはだめ）
です。山岸さんの言葉で言うと
「関わる人の頭の中に残像として残る程度の共通理解を得る」
こと、全体の見通しをよくすること、がちょうどいい加減なのです。業務からシステムに落としてく全体の図の感じはこのようになります。
図の拡大はこの資料を見てください。
- エンタープライズアジャイル時代のリーンモデリング（slideshare）
アジャイルと「これだけモデリング」
山岸さんは、要求開発の立場から、アジャイルにこんなことを言われていました。
アジャイルにはイテレーションがある。回っている大縄跳びに入るには、入る前に覚悟を決めたり、２、３回トントンとその場で飛んでみたりしないと、いきなりは入れない。その最低限の準備が必要なのだ。
なるほど、と思った次第です。山岸さんは、特にシステムが大きくなると、「素手で（モデリングなしに）」開発に挑むなどというのは、かなり無謀に思う、とのこと。もったいない、と。アジャイルであるかどうかに関わらず、「ペイする」分量のモデルという加減が必ずある、とぼくも思っていて、ぼくの書いた「アジャイル時代のモデリング」(Modeling in the Agile Age)では「維持し続けるモデル」を Keep モデル、「書き捨てるモデル」を Temp モデル、と呼びました。山岸さんの「これだけ」モデリングと共通の考え方は、モデル、という成果物自体よりも「モデリング」という活動に価値を見ている点でしょうか。参加者が手を動かして「自分のもの」としてモデリングすること。これが大事なんですね。
（参考）アジャイル開発におけるモデリングの位置づけと KEEP モデル/TEMP モデル
その他の参考（アジャイルとモデリング）
Slideshare より関連するスライドを紹介します。
- エンタープライズアジャイル時代のリーンモデリング（今回の中心資料）