要求開発にて”「これだけ」モデリング”

これだけモデリング！というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。

情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。

これだけモデリングとは、

• 誰が？　ー　情報システム部門の人（と開発の人が共に）
• いつ？　ー　システム開発の前段階、すなわち「要求開発」の場面で
• 何のために？　ー　要求の引き出しと共通理解を作るために
• 何を使って？　ー　UMLから選んだ「少数の図」と「少数の記法」で
• どうする？　ー　モデリングする（可視化して、整理して、理解して、合意する）

というものです。UMLは13種類も図がありますが、全部使う必要は全くありません。

クラス図、シーケンス図、アクティビティ図、ユースケース図を使って、システムの３つの側面を記述します。

• 何をするか　ー　サービスモデル　▶︎ビジネスユースケース
• 何がどうあるか　ー　静的モデル　▶︎概念クラス図
• どう動くか　ー　動的モデル　　　▶︎シーケンス図、アクティビティ図

を書きます。ポイントは、

• 書き過ぎないこと。
• 使い捨てでもよい、と割り切る。
• 無理にトレーサビリティを取ってメンテしようとしないこと。
• 抽象的すぎるモデルを描かないこと。（アナリシスパターンを描いてはだめ）

です。山岸さんの言葉で言うと

「関わる人の頭の中に残像として残る程度の共通理解を得る」

こと、全体の見通しをよくすること、がちょうどいい加減なのです。業務からシステムに落としてく全体の図の感じはこのようになります。

なお、当日は実習ということで astah* を使ってこんなお題をグループで書いてみました。

グループモデリングに熱中する依田さん、高崎さん、平鍋の三人。モデリング経験者の討議は楽しい。

ちなみに、ぼくもアジャイルの立場から「アジャイル時代のモデリング」(InfoQ)という記事を書いています。

アジャイルにはイテレーションがある。回っている大縄跳びに入るには、入る前に覚悟を決めたり、２、３回トントンとその場で飛んでみたりしないと、いきなりは入れない。その最低限の準備が必要なのだ。