要求開発の"見える化"とは

ビジネスを"見える化"するモデル・ストラクチャ

要求開発は、ビジネスを"見える化"してITに繋げるための方法論として、要求開発方法論(Openthology)を提供しています。「Vol.7 要求開発方法論オーバービュー」でも説明しましたが、要求開発方法論にはモデルがあります。

ここでは、要求開発方法論を使って、"見える化"を行うためのモデルについてもう少し詳しく説明していきましょう。

要求開発方法論のモデル

モデリングには、形式化・標準化されている記述様式を使用するのが理想的です(矢印や四角の意味を一度学習することで、誰でも理解可能なモデルが書けるからです)。このような標準化された図の代表的なものがUML(Unified Modeling Language)で、要求開発方法論におけるモデルは、基本的にはUMLを使っています。

UMLは、正式には「統一モデリング言語」とよばれる、ソフトウェア工学におけるオブジェクト指向開発のために標準化された仕様記述言語です。UMLを使うことで、誰もが同じルールでモデルを書くことができます。しかし、あくまでソフトェア開発におけるモデル標準であるため、ビジネス戦略など、UMLで表現できないものは、他の図式を使用しています。

また、UMLをすべてしっかりと覚える必要もありませんので、心配しないでください。要求開発におけるモデリングは、ビジネスパーソンがすんなり覚えられる程度のシンプルさを保っておりますので、書き方や考え方を覚えるのはそんなに大変ではありません。

ページトップへ

 

要求開発方法論のモデルのビュー

さて、「Vol.9 "見える化"とは」でモデルの視点について書きましたが、要求開発方法論で"見える化"する際に、どのような視点があるのでしょうか。ここで、「Vol.7 要求開発方法論オーバービュー」の中で説明したモデル・ストラクチャの図(図1)をもう一度見てみましょう。

この図の中に説明されている「戦略ビュー」、「サービスビュー」、「情報ビュー」、「プロセスビュー」が、それぞれ「視点」なのです。以降の説明では、視点のことをビューと呼びます。

図1 モデル・ストラクチャ
図1 モデル・ストラクチャ

ページトップへ

 

[目的と手段の連鎖]を表す、要求開発方法論のビュー

要求開発方法論では、方法論という取組において新たなチャレンジを行いました。それは、従来の方法論にはなかったビューの捉え方です。ビューによって[目的と手段の連鎖]を表すことにチャレンジしたのです。

僕は、これが見事成功したと考えています。 いや、要求開発方法論がこれからどんどん使われていくほど、このビューを採用した要求開発方法論の本領が発揮されると確信しています。

従来のソフトウェア工学における方法論のモデルには「静的モデル」「動的モデル」「状態モデル」といったようなビューがありました。僕もこれを基本としてビューの採用を図ろうと最初は思いましたが、これではHow(手段)しか表せないのでは?もしくは、モデリングを行う人がHow(手段)に着目したモデリングをしてしまっているのでは?ということに気が付きました。

そこで、「もっと価値を強調するためのモデリング」を行うためのビューのあり方を、根本から考えてみようと思ったのです。最初(Version 0.6)に採用したのが、サービスビューを目的とした、情報ビューとプロセスビューの関係です。

図2 サービスビュー、プロセスビュー、情報ビュー
図2 サービスビュー、プロセスビュー、情報ビュー

Version 0.6の時代、モデル・ストラクチャ図に「ビジネス戦略」という言葉は、明確なビューという形式では盛り込まれていませんでした。しかし、Version 1.0策定の際に、方法論策定を手伝ってもらった株式会社豆蔵・安井氏の提案で、ビジネス戦略におけるBSC戦略マップを採用しました。これがversion0.6のビジネス戦略の領域に大きなインパクトを与えることになり、サービスビューの上にビジネス戦略ビューを置くという構造が完成しました。

こうして2段階の[目的と手段の連鎖]が作られたのです。いや、もっと言うと、ビジネスとITという階層もありますので、複数段階の[目的と手段の連鎖]をビューとして表現していることになります。

図3 モデル・ストラクチャによる[目的と手段の連鎖]
図3 モデル・ストラクチャによる[目的と手段の連鎖]

拡大画像

ページトップへ

 

なぜ要求開発は新しいのか?

「要求開発はどこが新しいのか?」このことを知り意識することで、さらに要求開発の強みが発揮されます。しっかりと理解して意識してくださいね。

要求開発方法論では、[目的と手段の連鎖]をビューで表しているため、"見える化"する対象を戦略的に絞り込みやすくなっています。いままでの方法論では、これができませんでした。その結果、ビジネスの"見える化"を行うプロジェクトで、多くの時間を要して沢山のモデル図を書いてしまったわりには、なんの成果もだせないという結果になることも頻繁にあったのです。

たとえば企業が採用しているSOA(Service Oriented Architecture:サービス指向アーキテクチャ)や、日本政府が電子政府(e-japan)で採用しているEA(Enterprise Architecture)、あるいは、ビジネスモデリングも含まれている反復型開発で著名なラショナル統一プロセス(RUP:Rational Unified Process)などでは、手法や方法論が確立できていません。これらを使っていきなりビジネスプロセスを業務フローとして"見える化"しようとすると、対象の絞り込みが十分ではなく、大量の業務フローを作成してしまうことになるのです。

要求開発方法論では、ビジネスプロセスはプロセスビューに該当しますので、ビジネス戦略→プロジェクト戦略→サービスと絞り込んだ後に"見える化"する対象を決めます。その結果、無理無駄のないスピーディな"見える化"が可能となり、ドキュメントの爆発を防ぐことができるのです。

旧来の手法の欠点・盲点は、このような"見える化"プロジェクトの最適化ができないということなのです。そもそもモデルのビューが、手段(How)としての"見える化"しか確立していない、あるいは、手段的に"見える化"を使ってしまうため、その目的がはっきりできずに対象領域が拡大し、結果として、大量の見"見える化"ドキュメント(業務フローなど)を作成してしまうことにつながっていたのです。

僕は、他のビジネスモデリング方法論との違いは何と聞かれたら、かならずこのことを説明します。プロジェクトの最適化と、戦略的な絞り込みができる手法が組み込まれた方法論が、要求開発方法論なのです。

要求開発方法論では、図4で示すように、複数段階の[目的と手段の連鎖]を表す戦略的なモデリング方法を取ることで、対象を絞り込み、無理無駄のないスピーディな"見える化"を実現しているのです。

図4 目的と手段によるモデリング対象の絞り込み
図4 目的と手段によるモデリング対象の絞り込み

拡大画像

ページトップへ

 

要求開発方法論モデル・ストラクチャの本質

このような経緯で発展してきた要求開発方法論のモデル・ストラクチャですが、実はこの考え方には、なんらかのサービスや価値を提供するための本質的な考えが備わっていると思うのです。

どんな小さなことでも、この4つのビューは有効に使えます。図5を見てください。この図では、問題を捉える本質的なビューを表しています。図4とは異なり、矢印がサービスから3方向に出ています。なんらかのサービスを提供する際に、「その戦略は?」「その手順は?」「その情報の構造は?」というビューを含めましょうというわけです。

この見方は、サービスを捉える("見える化"する)ことの本質なのではないでしょうか?先に挙げたSOAにおいても、今後このような手法が徐々に確立されてくるでしょう。その際には、おそらく要求開発方法論のような4つのビューを持つことになると思います。もしかすると要求開発方法論がSOAの方法論に採用されるかもしれませんね。

図5 4つのビューの本質
図5 4つのビューの本質

拡大画像

さあ、次は現状モデルと次期モデルの考え方について説明します。


  • ※掲載されている製品・サービスは、掲載当時のものです。
  • ※掲載されている社名および製品名は、各社の商標または登録商標です。

ページトップへ