ビジネス・モデリングなどのモデリングを始めてはみたものの,なかなか上手くモデリングできない…そんな悩みを持っている方も多いと思います。そこで,今回はモデリングを上達させるための「モデリング・リファクタリング」という方法をご紹介します。
モデリング・リファクタリングとは
「モデリング・リファクタリング」とは筆者が考えた造語です。(すでに誰かによって提唱されているかもしれませんが)筆者が発明したものではなく,モデリングに慣れている方なら自然とやっているようなテクニックです。
もともと「リファクタリング」というのは,小さなプログラム(例えばクラス)を作るときに,プログラムの外側の仕様(使われ方)は変えずに,中身の構造だけを変えることです。
なぜそんなことをするかというと,とりあえず仕様は満たしていたとしても,中身が汚い設計のままでは,変更に弱く,保守性も悪いからです。そこで,小さなプログラムを作ってから,中身の構造をきれいにするということを行います。
最初から完ぺきな設計ができればいいのですが,人間はなかなかそうはいきません。そういうときは,とにかく作ってから少しづつきれいにするというアプローチを行うと,結果的には良いコードができあがります。
このアプローチには良い副作用があります。汚いコードを少しづつきれいにしていくと,きれいな設計をするセンスが身に付くので,次回からは,いきなりきれいなコードを書けるようになったりします。
モデリング・リファクタリングは,これと同じことをモデリングを行うときもやってみようというものです。要求開発のコンサルタントをしている筆者も,最初からいきなりかっこいいモデルが作れるわけではありません。モデルをちょっと作ってみて,「なんかここはいやな“におい”がするなぁ」というところを少しづつ直していくと,だんだんモデルがきれいになっていくという感じです。周囲を観察していると,モデリングに慣れている人は大体そうやっているみたいです。
今回は,モデリング・リファクタリングの実例を業務フロー(アクティビティ図を使っています)を例にとって説明してみたいと思います。
不吉なにおいとリファクタリング・カタログ
リファクタリングでは,いつどこをリファクタリングすべきかという条件が「不吉なにおい」としてまとめられています。コードを見て,不吉なにおいを見たら,その解決策(リファクタリング)を実施するとコードがきれいになっていくというわけです。
そこで,ここで行うモデリング・リファクタリング(業務フロー改善)のための「不吉なにおい」と「リファクタリング・カタログ」を作ってみました(表1,表2)。下記のリファクタリング過程で利用します。ときどき参照しながら読み進めてください。
表1●モデリング・リファクタリングの「不吉なにおい」
絵巻物 |
業務フローが絵巻物のように長く,細かく,複雑に記述されており,業務フローが複雑すぎてよくわからない。第三者はもちろんのこと,本人もわからないケースもある |
(リファクタリング) |
範囲の明確化,目的の明確化,ハイパーリンクの導入,分岐の削除,ダイヤグラムの分割,マインドマップの導入 |
ボーダレス |
範囲や目的が不明確なため,業務フローの範囲が絞り込まれておらず,あいまいで,なんでもかんでもダイヤグラムに盛り込まれており,複雑で第三者が理解できない |
(リファクタリング) |
範囲の明確化,目的の明確化,マインドマップの導入 |
多くの分岐 |
業務フローに多くの分岐が含まれており,複雑で第三者が理解できない |
(リファクタリング) |
分岐の削除,ダイヤグラムの分割,ハイパーリンクの導入 |
情報過多 |
ノートなので,必要以上の情報が一つのダイヤグラム上に記載されており,業務フローが大変見にくくなっている |
(リファクタリング) |
情報過多の解消 |
目的の忘却 |
自分やメンバーが何のためにこのダイヤグラムを書いていて,どう使うのかがわかっていないことに気がついた |
(リファクタリング) |
目的の明確化 |
目的語レス |
アクティビティに目的語が無いため,何をやっているのかがよくわからない |
(リファクタリング) |
目的語の導入(名前変更),マインドマップの導入 |
データレス |
アクティビティで使うモノやデータ,帳票,台帳が明確でないため,何をしているのかが判別できない |
(リファクタリング) |
オブジェクトフローの導入 |
システムの喪失 |
システム化のプロジェクトや既存システムを扱っている業務フローで,どの部分でシステムが使われているのかさっぱりわからない。また,システムでどんなデータを扱うのかもよくわからない |
(リファクタリング) |
システムレーンの導入,オブジェクトフローの導入 |
詳細な手段 |
アクティビティが細かすぎて,業務フローが複雑になったり,読みにくくなったりする |
(リファクタリング) |
ハイパーリンクの導入 |
ローカルヒーロー |
第三者がその業務フローを見てもさっぱりわからないような専門用語で構成されている。また,書いた本人は理解できるが,第三者には大量の説明が必要である |
(リファクタリング) |
目的語の導入,名前の変更 |
暗黒時代 |
ダイヤグラムを作成している途中に,どう書いていいかわからなくなる |
(リファクタリング) |
マインドマップの導入,目的の明確化 |
表2●モデリング・リファクタリングの「リファクタリング・カタログ」
名前 |
目的の明確化 |
要約 |
業務フローを書いている目的が不明確であるために,不要な情報が盛り込まれていたり,必要な情報が抜けているため,まず目的を明確化する |
理由 |
目的が不明確なため,不要な工数,必要な工数が抜けたりする |
手順 |
ダイヤグラムを作成する前に,何のために書くのか,これを書いてどのように使うのか,といったゴールをメンバーで共有する |
名前 |
範囲の明確化 |
要約 |
業務フローに盛り込むべき範囲が不明確で,一つの業務フローに盛り込まれている範囲が大きい。よって範囲を絞り込む |
理由 |
業務フローが複雑過ぎて,第三者が見てもさっぱり理解できない。本来範囲に盛り込む必要のない部分にまで工数がかかってしまう |
手順 |
ビジネスユースケースを作成して,業務フローの範囲を絞りこむ |
名前 |
分岐の削除 |
要約 |
業務フローに必要以上の分岐が含まれおり,業務フローが複雑で鳥瞰図としての性質を失っている。不要な分岐を削除したり分離したりする |
手順 |
分岐部分の記述が,業務フローで必要か判別し,必要であればノートや「定義」での記述に切り替える。非常に重要な分岐の場合,ダイヤグラムを二つに分ける |
名前 |
ダイヤグラムの分割 |
要約 |
業務フローに必要以上の分岐が含まれている場合で,その分岐が業務にとって非常に重要で削除できない場合にダイヤグラムを分割する |
手順 |
分岐ごとにダイヤグラムを1枚づつ作成する |
名前 |
ハイパーリンクの導入 |
要約 |
業務フローに複雑な分岐や,細かいステップのアクティビティが含まれており,図が複雑になっている。ハイパーリンクを使って図を分割する |
手順 |
細かい部分を一つのアクティビティにまとめ,その中身を別のダイヤグラムに記述し,ハイパーリンクを貼る |
名前 |
目的語の導入 |
要約 |
アクティビティの意味がよく読み取れない。第三者が見たら何のことかわからない。理由は目的語の欠落であるので目的語を追加する |
手順 |
アクティビティの名前を変更する。目的語を意識する |
名前 |
名前の変更 |
要約 |
アクティビティやオブジェクトの名称がダイヤグラムを描いた本人しかわからないようになっているため,第三者がわかるものに変更する |
手順 |
第三者が見てわかるという観点で名前を変更する |
名前 |
システムレーンの導入 |
要約 |
どの部分がシステム化されるか,もしくは,システム化されているのかがよくわからないため,システムレーンを追加する |
手順 |
システムレーンを追加し,システム化されシステムで動く機能を明確にする |
名前 |
オブジェクトフローの導入 |
要約 |
アクティビティだけが書かれており,そのアクティビティが行うことや前提条件(必要な書類やデータなど)が明確でないためオブジェクトフローを導入する |
手順 |
オブジェクトフローを導入し,アクティビティで使用する帳票や台帳やモノ(商品)などを明示する |
名前 |
情報過多の解消 |
要約 |
ノートが非常に多く書かれており,業務フローで表すべきではない情報まで詳細に記入されて,ダイヤグラムが見にくくなっているためダイヤグラム上の情報を少なくする |
手順 |
ノートを削除し,「定義」に移動させる |
名前 |
マインドマップの導入 |
要約 |
業務フローを書き始めるときに,いったい何から書き始めていいやらわからない状況なので,マインドマップで発想し整理する |
手順 |
マインドマップにより,やりたいことを整理する |
名前 |
色の導入 |
要約 |
ダイヤグラムで強調したい部分がよくわからない。図をさらに見やすくしたいときに色をつける |
手順 |
アクティビティやオブジェクトフローや特に目を引きたいノートに色を付ける。色をつけるときにはルールを決めておく |
では,モデリング・リファクタリングを実際に行ってみましょう。