「これだけ」モデリング – Part 2/2

Satomi Joba February 20, 2015 2 Comments

平鍋

「モデリングしてますか？」

今回は、前回の続き「これだけモデリング」ですが、アジャイル開発の中で、もっとモデリングを使おうという話をしていただきます。「これだけモデリングは、アジャイルを加速する」という事で、山岸さん、よろしくお願いします。

山岸さん

皆さん、こんにちは。メソドロジックの山岸です。
今日は、「これだけモデリングは、アジャイルを更に加速する」というテーマで、お話をさせていただきます。

アジャイルとモデリング

最近、アジャイルが非常に盛んになっておりますが、そうした中で「アジャイルは、ドキュメント削減するんでしょ、だからモデリングやりません」という混乱が散見されており、そこが随分違うなと、私は思っています。
アジャイルといっても、最近のアジャイルの話題は、エンタープライズにどう適用するか、です。アジャイルというと、スプリントのサイクルのところに話がフォーカスされる、つまりプロダクトバックログを作ってから以降の話、という事です。

ただ、エンタープライズというのは、色んなシステムが複雑系を成しているというか絡み合ったもので、且つデータの移行などの複雑なもので、対象も複雑な業務なわけです。

スプリント以前のモデリング

ですから、一定のリズムでアウトプットを出していくというようなスプリントのサイクルに入るまでの所、つまり、バックログを積むまで、にやっておかなければいけないことが、沢山あるんです。

実際に、1番重要なのは「業務を正確に把握する」というところですね。そこで、モデリングは非常に有効に働くと私は思います。

スプリントに入ると、非常に高速になるわけですが、そこに至るプロセスをできるだけ素早くやっていくという部分は同じだと思うのですが、業務を更に素早く把握しようとするとモデリングの力を借りざるを得ない訳ですね。

モデリングによって、先ずちゃんと地図を描いておくこと、それからエンタープライズの場合、システムを長期に渡ってメンテナンスしていくという意味では、やはりアーキテクチャを、きちんと設計した上でスプリントのリズムに入っていかなければいけない。
という事で、この辺りは、モデリング無しで素手でやれるような領域ではないと考えています。

更に業務を正確に手早く把握するためには、モデリングの力を十分に活かさないと、まず難しいでしょう。

スプリント中のモデリング

実際のスプリントに入ると、設計者と実装者は変わりませんから、同じメンバー間のコミュニケーションを高める、という意味では、わざわざUMLで設計書を描いて、それをベースにコーディングする、というような情緒なサイクルではなく、「素早くやる」という事であれば、全体の構造をちゃんと理解した上で、それを時々見る、ということで、最初の段階でモデル化したものを参照しながらという事になります。

また「コミュニケーションを活性化する」という事は、アジャイルの中で非常に重要なわけですが、言葉より伝わる、というモデリングは、スケッチとしてあるわけですよね。いくら言葉で言うよりも、お互いが共通理解しているノーテーションで描いた方が、よっぽど早く伝わる。その方がよっぽどアジャイルだ、という話が、1つあります。
そういうところで、モデリングを使うと、更にスピードが加速する事ができます。

リリース後、運用準備のモデリング

それから、リリース後、エンタープライズというものは、ずっと使い続けて進化し続けますから、次の開発者に委ねていかなければいけないくらい寿命が長いものですね。ですから、その所では、設計の重要な情報というのをモデルのようなものを使って、保守していかなければならない。

「エンタープライズアジャイル」という領域でも、アジャイルをより加速するというポイントで、モデリングを設計する必要があると考えています。

要求獲得のためのダイアグラム

それで、実際に何を使うのかというと、業務の要求獲得というか要求開発のためのモデリングというのは、簡単に言うと、この3つですね。

つまり、そもそもその業務で何をするのか、それが、どういうもので構成されて、それがどう動くのかを、表現するという事が、ここで必要となるいう事ですね。

そして、実際には、何をするのかっていうと、ユースケース図で表現しますし、誰がどうやって、という部分は業務フローで表現します。何で構成されているかは、概念クラス図で描くという事が基本になります。その場合も、ここに挙げましたような限られたノーテーションを出来るだけシンプルに使って表現する事が非常に重要です。

: 「これだけ」概念クラス図

: 「これだけ」ビジネスユースケース図

: 「これだけ」業務フロー図

関わる人に「残像」として残るモデリング、これがベスト

という事で、ここで重要なところは、あくまでも「業務理解のためのモデリング」という事で、抽象度を上げすぎて、”そもそも”みたいな話をしても、業務の特徴を表すことはできませんので、やはり、一定の業務イメージとか具体イメージを表現できるレベルにしておかなければいけないという事です。

それから、概念モデルを、そのまま設計モデルや、トレーサビリティを維持したままデータモデルやクラスの実装言語の設計モデルに持っていこうという考え方は、あまり考えない方がいいと思っています。

つまり、設計時には、様々な概念が入ってきますので、ここで表現したような概念レベルのモデルを無理やり繋いでメンテナンスしようとすると、すごく余計なエネルギーが開発者にかかってくると考えられます。

ですので、「使い捨てていい」と、逆に言うと、このモデルを作る過程で色んな情報が引き出されますし、それを作る過程で、関わった人が共通の理解を進めていく、むしろアウトプットよりもプロセスが重要なわけですね。
で、そのプロセスを経ると、必ず関わった人の心の中に残像が残りますので、むしろその”残像を頼りに”、次の図の伝達設計やプラス設計といったところを進めていけば、それで十分だと考えています。むしろそれが、ベストな事だと思っています。

「これだけ」モデリングで、曖昧な部分を排除する

実際の現場で、こうしたモデリングをしながら業務の理解や要件定義を行うと、皆さんスゴクすっきりした感覚を持てると思います。(具体的な感想は、右スライド参照)
それは、言葉だけで話をしている時というのは、皆、個々の勝手なイメージを持ちながら話をしてて、本当にディープなレベルで共通の認識ができているのか、非常に危ういところがありますよね。それが、実際に目に見えるようなモデルの形式で、指をさしながら具体的に話を詰めていき、一つのモデルが出来上がったという事は、曖昧な部分が排除されて、皆が一つのイメージを共有したという事になります。その後のシステム開発における手戻りは、非常に少なくなると思います。

アジャイル開発には、アジャイルな「これだけ」モデリングを