Skip to content

Category: Agile

匠Methodで目指す「ビジネスエンジニアリング」(その2:解説編)

匠Methodで目指す「ビジネスエンジニアリング」(その2:解説編)です。

Advertisements

【対談】「これだけ」モデリング – Part 1/2

「これだけモデリング」は、なぜうまれたか - 対談その1。 UMLの仕様を全部使ってモデリングするなんて、無理。モデリングという「活動」を通して参加者に「残像」を残すことが重要。

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

「モデリングしてますか?」 今回は、前回の続き「これだけモデリング」ですが、アジャイル開発の中で、もっとモデリングを使おうという話をしていただきます。「これだけモデリングは、アジャイルを加速する」という事で、山岸さん、よろしくお願いします。   皆さん、こんにちは。メソドロジックの山岸です。 今日は、「これだけモデリングは、アジャイルを更に加速する」というテーマで、お話をさせていただきます。  アジャイルとモデリング 最近、アジャイルが非常に盛んになっておりますが、そうした中で「アジャイルは、ドキュメント削減するんでしょ、だからモデリングやりません」という混乱が散見されており、そこが随分違うなと、私は思っています。 アジャイルといっても、最近のアジャイルの話題は、エンタープライズにどう適用するか、です。アジャイルというと、スプリントのサイクルのところに話がフォーカスされる、つまりプロダクトバックログを作ってから以降の話、という事です。 ただ、エンタープライズというのは、色んなシステムが複雑系を成しているというか絡み合ったもので、且つデータの移行などの複雑なもので、対象も複雑な業務なわけです。  スプリント以前のモデリング ですから、一定のリズムでアウトプットを出していくというようなスプリントのサイクルに入るまでの所、つまり、バックログを積むまで、にやっておかなければいけないことが、沢山あるんです。 実際に、1番重要なのは「業務を正確に把握する」というところですね。そこで、モデリングは非常に有効に働くと私は思います。 スプリントに入ると、非常に高速になるわけですが、そこに至るプロセスをできるだけ素早くやっていくという部分は同じだと思うのですが、業務を更に素早く把握しようとするとモデリングの力を借りざるを得ない訳ですね。 モデリングによって、先ずちゃんと地図を描いておくこと、それからエンタープライズの場合、システムを長期に渡ってメンテナンスしていくという意味では、やはりアーキテクチャを、きちんと設計した上でスプリントのリズムに入っていかなければいけない。 という事で、この辺りは、モデリング無しで素手でやれるような領域ではないと考えています。 更に業務を正確に手早く把握するためには、モデリングの力を十分に活かさないと、まず難しいでしょう。  スプリント中のモデリング 実際のスプリントに入ると、設計者と実装者は変わりませんから、同じメンバー間のコミュニケーションを高める、という意味では、わざわざUMLで設計書を描いて、それをベースにコーディングする、というような情緒なサイクルではなく、「素早くやる」という事であれば、全体の構造をちゃんと理解した上で、それを時々見る、ということで、最初の段階でモデル化したものを参照しながらという事になります。 また「コミュニケーションを活性化する」という事は、アジャイルの中で非常に重要なわけですが、言葉より伝わる、というモデリングは、スケッチとしてあるわけですよね。いくら言葉で言うよりも、お互いが共通理解しているノーテーションで描いた方が、よっぽど早く伝わる。その方がよっぽどアジャイルだ、という話が、1つあります。 そういうところで、モデリングを使うと、更にスピードが加速する事ができます。  リリース後、運用準備のモデリング それから、リリース後、エンタープライズというものは、ずっと使い続けて進化し続けますから、次の開発者に委ねていかなければいけないくらい寿命が長いものですね。ですから、その所では、設計の重要な情報というのをモデルのようなものを使って、保守していかなければならない。 「エンタープライズアジャイル」という領域でも、アジャイルをより加速するというポイントで、モデリングを設計する必要があると考えています。  要求獲得のためのダイアグラム それで、実際に何を使うのかというと、業務の要求獲得というか要求開発のためのモデリングというのは、簡単に言うと、この3つですね。 つまり、そもそもその業務で何をするのか、それが、どういうもので構成されて、それがどう動くのかを、表現するという事が、ここで必要となるいう事ですね。 そして、実際には、何をするのかっていうと、ユースケース図で表現しますし、誰がどうやって、という部分は業務フローで表現します。何で構成されているかは、概念クラス図で描くという事が基本になります。その場合も、ここに挙げましたような限られたノーテーションを出来るだけシンプルに使って表現する事が非常に重要です。  関わる人に「残像」として残るモデリング、これがベスト という事で、ここで重要なところは、あくまでも「業務理解のためのモデリング」という事で、抽象度を上げすぎて、”そもそも”みたいな話をしても、業務の特徴を表すことはできませんので、やはり、一定の業務イメージとか具体イメージを表現できるレベルにしておかなければいけないという事です。 それから、概念モデルを、そのまま設計モデルや、トレーサビリティを維持したままデータモデルやクラスの実装言語の設計モデルに持っていこうという考え方は、あまり考えない方がいいと思っています。 […]

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

モデリングしてますか? 今日は、メソドロジックさんにお伺いして、山岸さんが提唱されている新しいコンセプトである、「これだけモデリング」について、お話をしていただきたいと思います。 それでは山岸さん、どうぞよろしくお願いいたします。 こんにちは、メソドロジックの山岸です。今日は「これだけモデリング」という話を、短い時間ですが簡単にご説明させていただきます。    モデリングの威力はすごい。しかし,これだけ役立つのに、なぜ使われていないのか? 私は、20年前にブーチ法というものに出会って、モデリングを知ったのですが、それから今まで自分が関わったプロジェクトでは、大体モデリングをやってきたという経験があります。今となっては、モデリングせずにプロジェクトをやるのは、素手で戦っているというような感じで、非常に違和感があり、凄く野蛮な気がします。 UMLが出てきて既に15年以上経っていますが、これだけ役に立つものなのに、なぜか意外に使われていない、という事に驚きを感じています。 というのは、モデリングが、どれくらい役に立つものか、という事が、あまり分かってないんじゃないのかというのも1つですし、あとは、導入のハードルが高いと思ってる人が多い。あるいは、使い方が間違ってるんじゃないかと思われる時もあります。 要は、かけてるコストに対して、ちゃんとしたリターンを得てないのではないかと思います。コストパフォーマンスを十分取れてないから使わない。今まで(モデリング)無しでも、物が作れているかどうかは、ともかくとして、無しで作っちゃってる、という技術があります。あえてここでモデリングを勉強して、更に、今までやってない作業を加えてプロジェクトを回す事に対して、皆さんは、あまりメリットを感じないかもしれませんね。加えて、最近のアジャイルブームで「ドキュメントを書かない」という流れの中でモデリングもやらないみたいな混乱、もあると思います。 私が思うに、「場に合わせて、適切なレベルでモデリングをする」というのは、非常に効果が高いと思います。 それを、皆さんは、今日この場でお勧めしたいと思います。  モデリングが根付かない理由 悪い例からお話しますと、そもそも皆、生真面目にやりすぎている。UMLは13種類のダイアグラムがあるんですけど、それに対して、それぞれの図の表記に困ってしまっていて、「それを逐一勉強した上で、プロジェクトに取り掛かろう」とか、どのレベルの詳細度まで描くか、をあまり考えないで“やたら”描いてるという事が、多々見られるわけですね。 やはり「小難しくし過ぎてる」というのは、一つあると思います。 非常に細かいレベルまで表記方法にこだわって描いていくことや、抽象度をすごく上げて、”そもそも”というレベルのモデルを描いても、描いたモデルは、返って伝わらなくなりますね。 私は、よく英語に例えるのですが、”一番通じるレベル”があって、例えば国際語としての英語というのは、必ずしもネイティブのような英語を喋ってても、他の国の人には伝わらないわけですね。なので、“このレベルで使うと、1番よく伝わる“というレベルがあるんですよね。そして、モデリングしてきた人は、誰が取り決めたわけではないけれど、一様に”このレベル”という感覚が、共有できてると思っています。 ですから、そのレベルのものを習得して、逆にそれ以上のものは使わない、というような、そういう“ほどいい使い方”を、皆さんにお勧めしたいと思っています。 そもそも、そういう風に生真面目にやったり、難しくしすぎちゃうのは、何のためのモデリングをしているのか、という所を見失っているケースが多いですね。  モデリングの目的を明確にして、自分たちの「ほどよい」レベルを見つけよう モデリングの目的は、大きく幾つかあると思っています。 1つはやはり、「物を理解するため」にモデリングするという事ですね。 理解についても「全部を理解する」と「複雑な詳細を理解する」という、理解のためのモデリング。それから「伝達するため」、「記録するため」そういった目的もあります。 他の言い方をすると、スケッチとしてのモデル、設計書としてのモデル、プログラム言語としてのモデルなど、色々なレベルの使い方もあります。 それから、扱い方にしても、描き捨てるのか、中間生成物として使っていくのか、最終成果物として残すのか、あるいは保守資料としてメンテナンスまでするのか、そういったものが分類としてありますね。 ですので、今、モデリングをしようとする時に、どういう目的で、何のために、どの程度描いて、この先どう扱うのかというところを決めると、おのずと”ほどよいレベル”というのが定まってきます。  UML13種図のうち、4図だけ使えばいい 図としては大体このくらい知っていればいいでしょう。13種類あるうちの4つを知ってればいい。 ただし、図を使うシーンがあります。他えばクラス図だと、概念クラス、設計クラス、データ設計図など。クラス図だけれど、使うシーンによって使い方が違います。こういう所を意識して、黄色く塗ったあたりを、特に皆さんには必ず習得して欲しいですし、ここに挙げたところが標準的に使っていただければいいんじゃないかと思っています。 あとは、各ダイアグラムにしても、細かく色んなノーテーションがあるので、ダイアグラムごとに「この程度のノーテーションを使いましょう」というお勧めなレベルもあります。 […]